Wprowadzenie Taksonomia diagramów UML Ten artykuł to kontynuacja wątku rozpoczętego wpisem o modelu dziedziny i diagramie klas, jednak inna jest intencja. Wśród wielu listów i pytań od studentów i pracujących już…
Dzisiaj żadnych technicznych mądrości 😉 […] Tak więc wymagania na oprogramowanie to minimalna liczba (specyfikacja) warunków, których spełnienie potwierdza przydatność tego oprogramowania do określonego celu. Oznacza to, że przede wszystkim należy określić cele! Jeżeli nie znajdziemy takiego oprogramowania na rynku, wtedy należy wykonać studium wykonywalności projektu dedykowanego oprogramowania.
Jak określać cele? Przypadek użycia, wymagana usługa systemu, to nic innego jak właśnie cel. Celem jest możliwość wystawiania dokumentów XXX, celem jest generowanie raportów kontrolnych wykonania planu produkcji i obciążenia maszyn. Jeżeli system jest duży, celem (jednostka opisu wymagań) jest wsparcie procesu obsługi zamówień (i opis tego procesu jako załącznik). Ale nie jest dobrym celem zakupu oprogramowania: “rozwijana lista kontrahentów na ekranie tworzenia nowej faktury” czy “możliwość wprowadzenia nazwy ulicy, kodu i nazwy miasta w kartotece klienta”.
Jak mam nadzieję widać, nie bardzo ma sens porywanie się na zakup “wielkiego pakietu zintegrowanego”, bo jak tu opracować w rozsądnym czasie i koszcie, specyfikację wymagań? Opracować listę celów wszystkich komórek organizacyjnych???? Jak zagwarantować jej niezmienność (zakres projektu), jeżeli taki projekt trwa np. pięć lat? Życzę powodzenia…
Dosyć często spotykam się z modelowaniem struktur organizacyjnych czy nawet ról w procesach, z pomocą diagramów przypadków użycia i hierarchii aktorów z użyciem dziedziczenia. Jest to moim zdaniem kompletne nieporozumienie i fałszywe.
Zawiłe diagramy struktur organizacyjnych w postaci aktorów dziedziczących po sobie (nie przytoczę tu żadnego, każdy taki jest w zasadzie zły), na których przełożony dziedziczy po podwładnym (lub podobne konstrukcje), są niemalże zawsze gruntu fałszywe. Studiowanie zakresów obowiązków pracowników firm jawnie pokazuje, że to nie prawda. Z zasady wielu menedżerów działów nie ma kompetencji swoich podwładnych, nie raz szef działu prawnego nie ma, i nie musi mieć, uprawnień radcowskich czy adwokackich, w wielu większych sekretariatach, upoważnienia do pewnych podpisów są przydzielane indywidualnie i szef (szefowa) nie ma tych wszystkich upoważnień. Szef kancelarii tajnej może mieć uprawnienia do informacji tajnej nadane przez ABW, których to uprawnień nie ma nie raz, jego przełożony. Przykładów na fałszywość dziedziczenia uprawnień w strukturze organizacyjnej można podać tak ogromną ilość, że dość częste stosowanie tej konstrukcji wydaje mi się niezrozumiałe. projektują oprogramowanie także, z reguły nieprawdą, jest dziedziczenie praw dostępu. Nie przypadkiem w praktyce stosuje metody macierzowe zarządzania prawami dostępu (niewydolne i nie prawdziwe w sensie biznesowym) lub kontekstowe (dużo lepsze).
Tak więc analiza organizacji i opracowanie jej modelu to trudna, praca, nie raz długa, ale nie powinny to opasłe księgi. Dobry model organizacji to właśnie broszurka, która odpowiada na pytanie “dlaczego”. Jeżeli wynikiem analizy są opasłe księgi to znaczy, że mamy jedynie dziesiątki nagrań kolejnych partii szachów a nie reguły tej gry… a wtedy nadal nie wiemy “dlaczego”.
Co ciekawe, każda organizacja ma, lub powinna mieć, taką instrukcję: jest to lista stanowisk (struktura organizacyjna) i reguły gry w postaci wewnętrznych zarządzań i procedur. Ale powinna ona być spójna i kompletna. Przypomnę, że każda organizacja jakoś funkcjonuje, a mało która ma mapy procesów biznesowych. Po co więc te modele procesów?
Wróćmy do wspomnianej na początku “piramidy”. Jej szczyt to cele, model biznesowy: chcemy grać w szachy i wygrywać. Jej najniższa warstwa to figury i reguły gry. Czym jest środkowa warstwa, czym są te modele procesów biznesowych? Dobry szachista ma pewne z góry przewidziane scenariusze, są to “gotowe” rozwiązania na pewne powtarzająca się sytuacje na szachownicy. One oczywiście nie są w stanie zastąpić szachisty, ale bardzo ułatwiają mu grę, raz przećwiczone i uznane za “dobre” i skuteczne scenariusze, stosuje zawsze gdy napotka “standardową sytuację”.
Organizacje także je mają, to właśnie procesy biznesowe, ale nie jest to recepta na pracę firmy, takiej nie jesteśmy w stanie stworzyć. Procesy biznesowe, te udokumentowane by służyły firmie, to wszystkie te przewidywalne, powtarzające się scenariusze, które stanowią tak na prawdę nasze organizacyjne know-how. Cała reszta to kompetencje naszych pracowników a tych nie modelujemy, z nich korzystamy.
Bardzo często spotykam się z projektami, w których użytkownicy narzekają na dostawcę oprogramowania, uważają że program nie całkiem spełnia ich oczekiwania (wymagania podpisali… ale to nie rozwiązuje tego problemu). Problem polega na często spotykanym podejściu: analiza wymagań tylko w postaci wywiadów i w konsekwencji niepełne zrozumienie specyfiki biznesowej oraz fakt, że developer ma skłonności do uproszczeń i “normalizacji”. Innym, moim zdaniem jeszcze gorszym podejściem, jest rozpoczęcie kodowania jeszcze w trakcie trwania wywiadów i tworzenie oprogramowania metodą codziennych, lub co tygodniowych spotkań z użytkownikiem opisującym kolejne aspekty systemu. Zbyt późne odkrywanie (a nie raz nawet niedostrzeganie tego), tego że pewne rzeczy są ‘tymi samymi rzeczami” ale w innych kontekstach, prowadzi do bardzo wielu problemów z implementacją. Ale po kolei.
Moimi klientami są firmy i instytucje, które już wiedzą że: ZARZĄDZANIE PROJEKTEM WE WŁASNYM ZAKRESIE JEST KRYTYCZNE: Integratorzy systemów mogą być cennym elementem cyfrowej transformacji, ale nigdy nie powinni mieć…
Opisując wymagania wyłącznie jako “czarną skrzynkę” nie wiem co dostanę. Większość developerów będzie dążyło do uproszczenia implementacji (ich koszt, nie raz brak wiedzy) by zaspokoić na minimalnym poziomie wymagania opisane przypadkami użycia. Nie raz klient słyszy “tu musimy to uprościć bo tak się nie da”, a zamawiający, nie mając kompetencji by polemizować z taką opinią, zgadza się i dostarczony system staje się zgniłym kompromisem opartym właśnie na “czarnej skrzynce” jako specyfikacji zamówień: “dostaliśmy dokładnie to co zamówiliśmy ale zupełnie nie to czego naprawdę potrzebujemy”.
Tak więc,
nie ma znaczenia fakt, że na pewno są na rynku developerzy znający problem, który opisałem i stosujący opisane tu rozwiązanie takich problemów. Jednak nawet cień ryzyka (a jest ono na prawdę duże), że dostaniemy bubla, daje zamawiającemu prawo do szczegółowego definiowania wymagań jako “białej skrzynki”, bo dzięki temu zamawiający dostanie “to czego potrzebuje a nie tylko to co zamówił”.
Kim więc jest dobry analityk?
Jest to projektant, który potrafi analizowaną organizację “rozłożyć na elementy składowe”. Tymi elementami są wzorce projektowe, elementy stosowanej notacji. Wynik analizy to nie “rysunek”. Jest modelem w postaci schematu blokowego (diagramu), na którym każdy element ma ściśle określone znacznie, konstrukcję i zasady wzajemnego łączenia.
Analiza Biznesowa to rozłożenie analizowanego “przedmiotu” na skończony zestaw elementów, który z określoną dokładnością zachowuje się jak analizowana organizacja. Jeżeli te elementy składowe mają także swoje odwzorowanie w kodzie programu, to wynik analizy staje się projektem tego oprogramowania.
Poziomy szczegółowości wymagań to:
cele biznesowe (produkty procesów biznesowych)
opis usług żądanych od oprogramowania (tu także formatki papierowe/ekranowe, przypadki użycia oprogramowania)
opis (projekt) wewnętrznej logiki biznesowej (wewnętrzne elementy składowe i scenariusze ich współdziałania)
