Dzisiaj co nieco o filozofii i przypadkach użycia. Dzielenie przypadków użycia na "rodzaje" zawsze budziło mój sprzeciw, w UML (w oryginale) mamy jedno pojęcie: "przypadek użycia systemu", gdzie systemem jest…
Wprowadzenie Na ten wpis pewnie wielu z Was czeka, tak przynajmniej sugerują listy do mnie i głosy na forach, a także potencjalni klienci. Ci, których niestety czasem krytykuję, także pewnie…
Wpadła mi niedawno w ręce książka: How to survive in the jungle of Enterpice Architecture Frameworks (autor Jaap Schekkerman, na Amazon.com dostępny fragment w tym spis treści).
Dla mnie po lekturze tej książki nasuwa się jeden wniosek: moda na TOGAF to marketing The Open Group. Są inne, moim zdaniem ani gorsze ani lepsze, “ramy” architektoniczne (książka opisuje ich wiele). Podtytuł książki mówi wiele: Creating or choosing an Enterprise Architecture Framework (Tworzenie lub wybór ram architektury korporacyjnej). W zasadzie wystarczy wziąć przytaczaną powyżej definicję AE i podjąć powyższą decyzję: stworzyć lub wybrać. Nie jest to – tworzenie – łatwe, większość więc wybiera gotowe, jednak to jedynie ramy dlatego i tak nie da się tu niczego zastosować jak recepty.
Pierwszym etapem analizy, bardzo trudnym, jest opracowanie modelu pojęciowego. Celem budowy tego modelu jest zrozumienie na poziomie komunikacji (tak zwany biznes z developerem -> zagwarantowanie jednoznaczności) oraz zrozumienie tego co jest przedmiotem projektu (modelując magazyn raczej planujemy oprogramowanie symulujące kartoteki magazynowe a nie produkty w magazynie). Ważne jest by na oprogramowanie patrzeć jak na narzędzie, bo ono nim jest. Oprogramowanie wspomagające zarządzanie magazynem, nie zastępuje tego magazynu i towarów w nim…
Tak więc oprogramowanie, nazwy w nim używane, muszą spełnić warunek zgodności ze “słownikiem biznesowym”: biznesowy słownik pojęć (zgodność z nim) to jest wymaganie.
Jeżeli jednak okaże (analiza) się, że zakup programu ma pomóc, to należy opisać wymagania jakie taki program musi spełnić (wymagania wobec produktu). Te wymagania są podstawą do wyboru gotowego, dostępnego na rynku oprogramowania, lub decyzji o napisaniu dedykowanego, jeżeli poszukiwania nie dadzą pozytywnego rezultatu (ale etap szukania gotowego powinien dla zasady mieć miejsce). Dedykowane rozwiązanie wymaga jego zaprojektowania, to można (zalecane) zrobić przed wyborem wykonawcy lub zlecić wybranemu wcześniej wykonawcy. Wariant drugi naraża nas jednak na utratę panowania nad projektem bo wykonawca będzie forsował metody budujące mu marże a potem sam sobie świadczy nadzór autorski. Wbrew pozorom, angażowanie audytora projektu, który nie jest autorem dokumentacji wymagań nie wnosi nic, a komplikuje cały proces: taki audytor może jedynie ocenić zgodność działań projektowych z dokumentacją wytworzoną przez (audytowanego) wykonawcę, a w przypadku sporu i tak tu “władzę” ma autor projektu a nie audytor.
I teraz: ogłoszenie przetargu na całość na początku tej drogi jest jak widać idiotyzmem bo nie mamy żadnej wiedzy by ocenić wynik pracy a dostawca żadnej by cokolwiek sensownie wyceniać. Pominięcie jakiegokolwiek z tych w/w opisanych etapów to podnoszenie ryzyka projektu, co mam na dzieję widać. Każde wymaganie może być zero jedynkowe na każdym z tych etapów, wystarczy chcieć i umieć. Owszem, można je dzielić na biznesowe itp… ale to tylko sztuczne podziały, po prostu podczas realizacji mamy już tylko etap i jego wymagania. (Nieudane wdrożenie systemu biznesowego – czyli uczmy się na błędach innych | LinkedIn).
I tylko tu pojawia się pytanie jak w filmie MIŚ: a może to faktycznie ma być drogie i nieprzydatne a ja zupełnie bez sensu jestem tym zdziwiony?
Tak więc programista implementuje logikę biznesową, tę musi jednoznacznie udokumentować analityk, oraz zapewnia uzgodnioną jakość (wymagania pozafunkcjonalne). Ma więc dużo pracy… ale nie powinien podejmować prób wpływu na implementowaną logikę biznesową.
Czyli np. “jako sprzedawca, dostaję od klientów zamówienia, na podstawie których muszę wystawiać faktury VAT”, do tego analityk doda, np. po analizie otrzymanej partii dokumentów, strukturę zamówienia i faktury VAT oraz “algorytm” wyliczenia podatków.
Jeżeli programista zaczyna “lepiej wiedzieć” od zamawiającego, forsując np. prostszą implementację, to znaczy, że przekroczył swoje kompetencje, sam sobie – jako developerowi – robi krzywdę psując to oprogramowanie bo klient i tak prędzej czy później na tych uproszczeniach “polegnie”. Rolą analityka są także ewentualne negocjacje z zamawiającym, uproszczeń lub rozwinięć tego opisu. Czy analityk może być “pracownikiem” dostawcy? Jak sądzicie?
Nie raz rozpisuję się na temat dokonań projektowych państwowego IT za publiczne pieniądze. Są tacy co zarzucają mi czepianie się i złośliwości. Powód jest jednak tylko jeden: sami proszą się…
Wprowadzenie Dwa lata temu cytowałem: Jakie są najczęstsze problemy w nieudanych projektach? [...] 83% projektów korzysta z dokumentów tekstowych oraz arkuszy kalkulacyjnych do przechowywania wymagań, 40% projektów korzysta z emaili do…
