Wymagania ? Zarządzanie wersjami

Pomijając ich warianty, stosowane są dwie metody (grupy metod) dokumentowania wymagań i zarządzania nimi. Zakładamy, że są to wymagania wobec produktu (rozwiązania) jaki ma dostarczyć jego dostawca. W BABoK (Business Analysis Body of Knowledge), wymagania te musi spełnić dostarczony produkt, jednak oczywiście rozliczany jest dostawca rozwiązania. Stosowane są trzy metody (grupy metod) specyfikowania wymagań: Specyfikacja wymagań funkcjonalnych i poza-funkcjonalnych (i warianty tej metody). Specyfikowanie tak zwanej "czarnej skrzynki" (przypadki użycia). Specyfikowanie tak zwanej "białe skrzynki" (przypadki użycia + model dziedziny systemu). Pierwsza i najstarsza metoda bazuje na założeniu, że zamawiający i…

Czytaj dalejWymagania ? Zarządzanie wersjami

Granice kontekstu i mikroserwisy

Nie raz już pisałem tu o architekturze (Architektura systemu) tym razem kilka słów o tym. Często jestem pytany o kryterium podziału dużego systemu na komponenty. Jednym z nich jest praktyka dążenia do minimalizacji złożoności interfejsów między komponentami jako konsekwencja dziedzinowego kryterium podziału . Złą praktyką jest natomiast dążenie do usuwania redundancji. Stosuje takie - komponentowe dziedzinowe - podejście, w różnej formie,  z powodzeniem od lat. Można je spotkać w różnych formach w literaturze, pierwszy raz spotkałem się z nim w 1999 roku. Obecnie mamy już dość dobrze wypracowane wzorce projektowe ale nadal…

Czytaj dalejGranice kontekstu i mikroserwisy

Dlaczego tradycyjne metody zarządzania nie działają w projektach internetowych?

Jest dość liczna grupa ludzi uważająca, że w Internecie nie obowiązują ani prawa fizyki, ani prawa ekonomii ani nawet zdrowy rozsądek. W kwestii inżynierii oprogramowania ludzie Ci straszą świat projektów "mitycznym wodospadem" jak kiedyś dzieci straszone były Babą Jagą. [dzień po napisaniu: po dyskusji - patrz treść pod tym wpisem - a autorem cytowanego tu artykułu, doszliśmy do wniosku, że nie różnimy się zbytnio w poglądach, jednak zbytnie uproszczenie treści miało  prawo wprowadzić mnie w błąd, jednak mój artykuł pozostanie w pierwotnej treści bo polemizuje głównie z pewnym mitem a…

Czytaj dalejDlaczego tradycyjne metody zarządzania nie działają w projektach internetowych?

Struktura organizacyjna jako system

Jeżeli jeszcze ktoś nie wyczuł podstępu to niniejszym informuję, że powyższy diagram to diagram klas notacji UML. Jego cechą jest to, że klasy zostały przedstawione z pomocą ikon, reprezentujących określone stereotypy. Zgodnie z UML, linie przerywane z grotem reprezentują związki użycia (grot wskazuje na użyty obiekt)), asocjacje z pełnym rombem to kompozycje (związek całość część). Czy taki diagram jest niezrozumiały dla biznesu? Mam także nadzieję, że tu widać wyraźnie, że modelowanie dziedziny systemu w postaci klas połączonych z pomocą prostych asocjacji itp., to nie model obiektowy a nieudolna atrapa bazy danych, która z paradygmatem obiektowym nie wiele ma wspólnego.

Czytaj dalejStruktura organizacyjna jako system
Krzywy Dom zaprojektowany przez Szczepana i Małgorzatę Szotyńskich
Krzywy Dom zaprojektowany przez Szczepana i Małgorzatę Szotyńskich

Jak wyceniać projekty IT?

Jak widać próba wyceny całego projektu już na samym jego początku to wróżenie z fusów, wykonawca przyjmie wartość bezpieczna dla siebie, a tak określony budżet i tak zostanie skonsumowany (co pokazuje praktyka, tak się składa oferty w przetargach publicznych, taka jest jakość większości zapytań przetargowych!). Wystarczy wydzielić etap projektowania (analiza i projektowanie to ok. 20% kosztu developmentu) i zawrzeć umowę na etapie co najmniej wstępnego projektu, wtedy "zawyżanie" (narzucanie zapasu na niewiedzę) spada dwukrotnie. Opracowanie kompletnego projektu przed wyceną prac developmentu to obszar bliski prawej części: estymacja kosztu z bardzo małym błędem.

Czytaj dalejJak wyceniać projekty IT?

Mega projekty czyli jak zjeść słonia

Uszczegóławianie wymagań odkładamy "na ostatni moment". W ten sposób "kwartał po kwartale" doprecyzowujemy wymagania na kolejny etap i realizujemy go. Co zyskujemy? Nie wyrzucamy do kosza nadmiernie szczegółowej i rozległej dokumentacji wymagań, nie ponosimy koszów projektowania czegoś co może "wylecieć" z zakresu za pół roku z powodów np. zmian na rynku, możemy w dowolnym momencie zmienić kolejne planowane komponenty, usunąć jedne i opracować nowe bez ryzyka zbędnych kosztów. Pierwszy etap ma pewną cechę: tworzy jeden wspólny model wszystkich projektów dla danej organizacji o wdzięcznej nazwie Architektura Korporacyjna. Kolejne konkretne komponenty architektury IT to kolejne projekty, cechujące się umiejscowieniem w całości organizacji i wiarygodnym, spójnym z całością zakresem. Dlatego z reguły nie mają sensu: wdrożenia departamentowe oderwane od reszty (np. Dział Handlowy sobie funduje sam system CRM), projekty trwające dłużej niż trzy kwartały (ostatni kwartał to kolejne planowanie budżetu na kolejny rok czyli planowanie zmian), mega projekty ERPII czyli "all in one" dla firmy w ramach jednego projektu. Więc jak zjeść słonia by się nie udławić? Powoli i po kawałku...

Czytaj dalejMega projekty czyli jak zjeść słonia

Czym jest jakość oprogramowania… a może od czego ona zależy?

Coraz częściej utożsamiam analizę z projektem gdyż w sumie produktem analizy jest jakiś projekt czyli model tego co analizowano, model tego co rekomenduję by powstało. Analiza sama z siebie nie jest samowystarczalna (to znaczy samo analizowanie nie jest wartościowym produktem samym w sobie). Problemy z projektami obserwuje nie ja jeden. W każdym kolejnym projekcie staram się szukać przyczyn, zrozumieć problem i podjąć próbę rozwiązania. Problem w zasadzie jest znany. [...] Dalej mamy same dobre rady, z którymi trudno polemizować: Wysoka modularność, współpraca wielu niezależnych, lub luźno powiązanych elementów, możliwość wymiany małych części, lub tworzenie różnych wariantów tego samego modułu, to podejścia, które przyniosą nam wartość dodaną. Ludzie mający do czynienia z monolitami (układ: jedna wielka baza danych i do tego wielki serwer aplikacyjny) z reguły postrzegają podejście rozproszone (dziesiątki lub setki małych kawałków fruwających gdzieś w koło) jako trudniejsze, bardziej skomplikowane i przez to gorsze i bardziej ryzykowne. Takie spojrzenie to postawienie sprawy do góry nogami. I tu moim zdaniem autor ma 100% racji. Nie ma chyba nic gorszego niż uznanie, że "jeden wielki zintegrowany system" to zaleta tego Systemu, jest to jego największa wada.

Czytaj dalejCzym jest jakość oprogramowania… a może od czego ona zależy?

Prawo autorskie, szpiegostwo przemysłowe i projektowanie

Jak ustrzec się przed wyniesieniem z firmy tajemnicy jej funkcjonowania, tworzonej latami organizacji, procedur i procesów, reguł biznesowych? Jak zatrzymać w firmie wiedzę mino zamawiania oprogramowania, które siła rzeczy ja zawiera? Problem nie jest prosty. Sami prawnicy nie są między sobą zgodni co do tego, gdzie leży granica pomiędzy utworem literackim a szczegółowym opisem rozwiązania. Wydaje się, że kluczem jest to sposób tworzenia opisu tego co ma powstać. Standardem w IT jest opis wymagań, ten jednak z urzędu czyni autora oprogramowania także posiadaczem opisu logiki w nim zawartej, bo on jest autorem jej opisu. Wyjściem wydaje się zawarcie w umowie nie opisu wymagań na oprogramowanie a projektu oprogramowania. Metodą zdefiniowania granicy, za którą mamy nie utwór literacki (specyfikacje wymagań) a projekt wraz z algorytmami, jest metodyka MDA. Wtedy firma realizująca zamówione oprogramowanie tworzy dzieło zależne a zamawiający nie traci panowania nad tak powstałym produktem. Jest to sytuacja jaką znamy w branży budowlanej: developer dostaje projekt architektoniczny, i sam fakt, że postawił na jego podstawie obiekt nie daje mu żadnych praw do niego, gdyż wystarczająco szczegółowy projekt obiektu pozostaje dziełem projektanta a nie jego wykonawcy. Jednak zawsze, bo nie ma złotej reguły, wymaga to konsultacji i szczegółowego określenia zawartości dokumentacji, która ma stać się "opisem przedmiotu zamówienia".

Czytaj dalejPrawo autorskie, szpiegostwo przemysłowe i projektowanie

Dostosowanie oprogramowania: kiedy?

Fowler pyta o to, o co wielu wielu informatyków: czy dostarczenie firmie kolejnych nowych możliwości, powinno się realizować poprzez napisanie (tworząc dedykowane) potrzebne nowe oprogramowanie, czy poprzez zakup gotowego oprogramowania. Ogólnie opinia, zalecane podejście przez Fowlera to: jeżeli proces wymagający wsparcia nowym oprogramowaniem, to proces kluczowy dla utrzymania konkurencyjności lepiej stworzyć oprogramowanie dedykowane do tego procesu. Jeżeli to jeden z procesów pomocniczych, efektywniej będzie kupić gotowe oprogramowanie i dostosowanie do niego procesu w firmie. Co ciekawe, podobnie jak ja, zaleca w przypadku gotowego oprogramowania dostosowanie się do niego a nie dostosowywanie oprogramowania do siebie.

Czytaj dalejDostosowanie oprogramowania: kiedy?

IBM CIO Study: 60% w chmurze za 5 lat

system ERP czy CRM, traci sens jako monolityczny pakiet a stanowi sobą pakiet usług z jakiego korzysta dane organizacja. drugorzędne znaczenie ma to czy użytkownik jest ich właścicielem, dzierżawca czy chwilowym użytkownikiem. Analiza Biznesowa tu polega na analizie i stworzeniu modelu organizacji, wskazaniu gdzie jakich usług wspierających działania się w niej oczekuje, wyszukaniu dostawców usług lub ich stworzeniu, integracji. Osobiście uważam, że kończą się czasy gdy sprzedawcy "atakują" rynek, wybierają sobie klientów i sprzedają im oprogramowanie. Zaczyna się era gdy to klient wybiera usługę i jej dostawcę. Sprzedaż oprogramowania będzie wyglądała podobnie jak sprzedaż w pasażu butików: dostawcy usług wystawią swoje usługi, a klient (projektant systemu) będzie się przechadzał i wybierał najlepiej mu pasujące. Podobnie jak teraz: budując dom, remontując mieszkanie zapraszamy projektanta wnętrz, ten znając oferty marketów budowlanych dobierze najlepsze wyposażenie, materiały i kolorystykę i kupi. Nadchodzi powoli koniec ery napastliwych sprzedawców i ich firm, koniec dyktatury developerów. Nadchodzi, powoli, era rynku usług.

Czytaj dalejIBM CIO Study: 60% w chmurze za 5 lat

Urzędnikom i ustawodawcy zawdzięczamy utratę 100 mln euro

Koszt analizy i opracowania to ok. 20% wartości implementacji i mieści się nie raz nawet w kwocie nie wymagające przetargu (co istotnie skraca czas całości). Po drugie mając projekt, wycena implementacji nie jest już wróżeniem z fusów z narzutem 200-500% na wszelkie niewiadome (powszechna praktyka wielu firm developerskich, z bożej łaski integratorów). Zlecenie całości (analiza, projektowanie, wykonanie) jednej firmie nie raz kończy się tak: Wykonawca został wybrany w trybie zamówienia z wolnej ręki, ze względu na ochronę praw wyłącznych firmy Sygnity SA. Wykonawca został wybrany zgodnie z prawem polskim, natomiast zastrzeżenia Komisji wynikają z faktu, że w owym czasie polskie prawo nie było dostosowane do unijnego

Czytaj dalejUrzędnikom i ustawodawcy zawdzięczamy utratę 100 mln euro

Sprawna Inżynieria Oprogramowania: Ekstremalna obiektowość

W projektach informatycznych najczęściej spotykamy: analityka wymagań (AW), analityka systemowego (AS), dewelopera w tym architekta systemu (D). W zasadzie trudno powiedzieć co jest produktem każdego z nich. Najczęściej AW dostarcza jakiś opis tego czego oczekuje klient, AS robi porządkuje to zrobił AW np. z pomocą przypadków użycia a D bierze to do ręki i musi zaprojektować i wykonać oprogramowanie. Jak widać, odpowiedzialność za to co powstanie jest rozmyta. Klient najpierw przekazuje swoje oczekiwania AW zaś otrzymuje produkt od D. Konia z rzędem temu, kto mi powie jak tego dokonać bez permanentnych iteracyjnych wyjaśnień i bombardowania Klienta pytania w rodzaju "co Państwo mieli na myśli pisząc...".

Czytaj dalejSprawna Inżynieria Oprogramowania: Ekstremalna obiektowość

Koniec treści

Nie ma więcej stron do załadowania