Bardzo często tak właśnie definiuje się produkt analizy wymagań: wymagania funkcjonalne opisują to co ma system robić. W dyskusjach (ile mam ich za sobą :)) z programistami przebija się teza, że analityk specyfikuje to „co” system ma robić, a oni już załatwią sprawę tego „jak” ma to robić. W czym problem? W tym, że lista funkcjonalności to test rozwiązania (dostarczonego oprogramowania) a nie wymagania!

Pytanie moje brzmi: A co to znaczy „Jak”?

Czym jest owo „jak”? Kodem programu, logiką na niskim poziomie, logiką na wysokim poziomie? Spójrzmy na taki problem, wymaganie: klient wymaga by system pozwalał na wprowadzanie treści dokumentów, przekazywanie ich innemu pracownikowi wg. definiowanych reguł. Wiemy już co system ma robić. Tego typu systemów obiegu dokumentów (tak się je często nazywa) są dziesiątki, różnią się od siebie nieraz bardzo. Dlaczego?

Bo powyższy opis „co” system ma robić to stanowczo za mało, tak na prawdę nie definiuje on niczego poza tym, w jaki sposób może zostać wykorzystywany. Przypadek użycia jest dosłownie „przypadkiem użycia systemu”, ale przypadków użycia jest nieskończenie wiele. Na ile sposobów wykorzystujecie posiadane oprogramowanie?

Każdego dnia pojawia się  jakiś nowy problem do rozwiązania i użytkownik programu będzie musiał się z nim zmierzyć. Skoro w toku analizy wskazano skończoną liczbę przypadków użycia, to czy daje to prawo by ktoś, np. programista, nie znający analizowanego biznesu, uzurpował sobie prawo do „projektowania i kodowania” tego Jak ten system będzie to robił? Do kodowania na pewno na prawo, ale czy do projektowania także? Czym jest tu to projektowanie i co jest projektowane? Czym jest OOAD ([[Object Oriented Analysis and Design]], ang. analiza i projektowanie obiektowe)?

Zacytuje po raz kolejny metaforę z książki [[Martina Fowlera]]:

Wyobraźmy sobie kogoś, kto chce napisać program symulujący grę w snookera. Problem ten może zostać opisany przypadkami użycia opisującymi powierzchownie cechę: „Gracz uderza biała kulę, która przemieszcza się z pewną prędkością, ta po określonym czasie uderza czerwoną kulę pod określonym kątem, uderzona czerwona kula przemieszcza się na pewna odległość w pewnym kierunku.” Możesz sfilmować setki tysięcy takich uderzeń, zarejestrować parametry każdego uderzenia i jego skutki. Jednak ta metoda i tak nie stworzysz nawet dość dobrej symulacji. Aby napisać na prawdę dobrą grę, powinieneś raczej zrozumieć prawa rządzące ruchem kul, ich zależność od siły i kierunku uderzenia, kierunku itp. Zrozumienie tych praw pozwoli Ci znacznie łatwiej napisać dobre oprogramowanie.

Jak nie trudno się domyśleć analiza wymagań nie może trwać w nieskończoność, powstanie mało takich opisów scenariuszy. Tak więc tradycyjne metody, zapis wywiadów, obserwacje, ankiety, nie mają prawa się sprawdzić bo w skończonym czasie na analizę zawsze będzie ich za mało a i tak będą chaotyczne (będzie to tylko część tego co może się wydarzyć i nie wiadomo, która to część bo nie znamy wszystkich).

Przypadki użycia stanowią bardzo mierne przybliżenie rzeczywistości.  Oddanie programu do użytku, realizującego tylko „konkretne scenariusze” i to w sposób „obmyślony” przez programistę, który nie potrafi grać w snookera a tylko słyszał od gracza jak się to robi, najpewniej skończy się zabawą w kolejne iteracje, prototypy itp. Taki program będzie coraz lepszy ale nadal nie dotknie nawet realizmu snookera.

Znacznie lepszym wyjściem jest stworzenie modelu stołu i kul wraz z ich zachowaniem się, reakcjami na uderzenia. Kto powinien to zrobić? Ktoś kto dość dobrze grywa i rozumie snookera, ale nie koniecznie mistrz tej gry, a także znający jednak fizykę ciał stałych (tego raczej nie zna dobrze mistrz snookera). Taki model to nie przypadki użycia (te są tylko przykładami zastosowania) a model obiektowy zawierający obiekty takie jak kula, kij itp.

Czy taki model stworzy programista na bazie rozmów? Najczęściej nie! Co programista zrobi więc bardzo dobrze? Zapisze taki model w jakimś wybranym języku programowania ([[implementacja]]), zadba o to by możliwa była gra setek użytkowników, by możliwa była 24 godziny, siedem dni w tygodniu, wiele, wiele innych rzeczy ale nie model gry w  snookera.

Co najważniejsze: model taki nie może być żadnym uproszczeniem, gdyż odetnie to możliwość jego rozbudowy (nowe wymagania użytkownika, a te pojawią się na pewno) w przyszłości.

Inny przykład. Jeżeli początkowo projektujemy model pozwalający krawcowi projektować i szyć spodnie, nie powinniśmy projektować zamkniętej konstrukcji dwóch nóg, należy stworzyć model całego człowieka a w implementacji zawrzeć tylko jego część „od pasa w dół”. Będzie to pewien nadmiar ale jeżeli kiedykolwiek krawiec zechce poszerzyć ofertę o marynarki do tych spodni, będzie to proste rozszerzenie modelu a nie tworzenie go prawie od nowa. (tu kłania się DDD: ang. [[Domain Driven Design]] polegający na symulowaniu w projekcie OOAD bytów świata rzeczywistego).

Tak więc dokument wymagań to nie tylko przypadki użycia. Te są raczej testem poprawności rozwiązania, czy model jest poprawny (przypominam, że przypadki użycia, poza ich scenariuszami, zawierają stan początkowy i stan końcowy akcji użytkownika). Dokument wymagań to model (tu [[model dziedziny]]), który po zaimplementowaniu, będzie się zachowywał tak jak tego oczekujemy a przypadki użycia będą jedynie dowodem na to, że jest on poprawny. O czym tu mowa?

Jeśli model przypadków użycia to model tak zwanej czarnej skrzynki, to model dziedziny (bo tak się on nazywa) to tak zwana biała skrzynka. Tę białą skrzynkę także można przetestować. Jak? „Potraktować” ją przypadkami użycia (np. model kul i kija, kilka testowych uderzeń). Skoro mamy obiekty systemu (model, projekt rozwiązania), które reagują na bodźce, to znaczy, że możliwe jest „podanie” stanu wejściowego testowanego przypadku użycia modelu dziedziny i sprawdzeniu czy wytworzy on oczekiwany stan końcowy tegoż przypadku.

Model dziedziny to nie ten świat, o którym wielu myśli

Kolejna ważna uwaga: w oprogramowaniu nie projektujemy świata rzeczywistego (no chyba, że to będzie gra), projektujemy nasze narzędzia. Innymi słowy: w systemie nie modelujemy Dyrektora (on pozostanie żywy po wdrożeniu), modelujemy kartki papieru na jakich zachowujemy o nim informację w realnym świecie. Po co? By zamiast kartek użyć np. systemu kadrowo-płacowego, by wyliczył jego wynagrodzenie szybciej i bez błędów. Zły model (przypominam, system biznesowy to nie gra) zawiera klasę User, dobry model: UserInfo. Polecam książkę o metodyce analizy i modelowania [[Toold&Materials design]].

Narzędzia pracy

Tu niestety pojawia się pewna potrzeba: narzędzie. Czym ono jest? Notacja obiektowa UML. Po co to? Bo tworzenie i testowanie diagramów jest znacznie szybsze i tańsze (zrobi to analityk projektant) niż tworzenie wykonywalnego kodu zdatnego do testowania.

Dalej: oprogramowanie CASE. Czy jakikolwiek rozsądny fotograf dzisiaj pracuje nad zdjęciem cyfrowym z pomocą programu PaintBrusz? Edytuje poszczególne piksele „na piechotę”? Nie, korzystamy z PhotoShopa, Gimpa, itp. Jak nazwać wiec analityka, który modeluje z pomocą takich narzędzi jak PowerPoint a nawet Visio? Są narzędzia, pakiety CASE, zwalniające projektanta z  benedyktyńskiej pracy nad diagramami, może się skupić na treści. Aha: UML to nie generowanie programu, UML to analiza i modelowanie, to narzędzie dokumentowania swoich projektów. Dobry inżynier używa rysunku technicznego, w inżynierii oprogramowania jest to własne UML. Jak ktoś uważa, że UML jest bez sensu sam cofa się o dekadę w rozwoju.

Przykład

Na pewnym forum pojawiło sie takie zadanie, weźmy sytuację biznesową (cytat):

Mamy portal dla klientów. Klientem jest firma, która kupiła nasz produkt. Każda firma ma utworzone kilka kont użytkowników. Na portalu prezentowane są nasze produkty i jakieś dodatkowe ekstrasy dla nich.

Przypadek użycia:

Użytkownik [po zalogowaniu się] widzi tylko takie produkty, które jego firma kiedyś zakupiła.

Dla porządku diagram Przypadków Użycia:

Jak widać, wymaganie funkcjonalne nie za wiele mówi, na tej podstawie może powstać nieskończenie wiele rozwiązań. Prosty scenariusz: użytkownik żąda oferty, system wyświetla ofertę składająca się z wcześniej kupionych produktów. To także nie pomaga, to test tego czy system zrobi to co chcemy. Czego nam potrzeba? Potrzebujemy modelu wnętrza, który zasymuluje „system”, informacje które posiadamy, i odpowie oczekiwaną „ofertą”. Taki model to właśnie model dziedziny:

To nasze „kule do snookera”. Ale czy to dobry model? Czy przykładowy bodziec (żądanie oferty) da oczekiwany rezultat? Sprawdźmy to na modelu:

Co tu mamy? To symulacja tego co zrobiłby (powinien) przyszły gotowy program. Testowanie i projektowanie to proces iteracyjny: jeżeli powyższy model (diagram sekwencji UML) nie da oczekiwanego rezultatu (stan końcowy przypadku użycia) należ go poprawić. Po co takie zabawy? Zwróćcie uwagę ile obiektów jest na modelu dziedziny, czy jesteśmy w stanie to sobie wyobrazić ze szczegółami w głowie? Takich obiektów w dużym systemie będą dziesiątki! Okazji do pomyłki, brakujący obiekt, brakująca informacja itp. jest wiele.

Po takich testach (weryfikacja rozwiązania polega na „potraktowanie” modelu dziedziny wybranymi lub wszystkimi przypadkami użycia) uzupełnimy wszelkie ewentualne braki modelu. Po co? By tych braków nie odkrywać na etapie kodowania, bo to jest nawet 100 razy kosztowniejsze!

Ważna informacja: powyższe diagramy to za mało. Wywołanie operacji klasy, w większości przypadków, wymaga podania parametrów, odpowiedź stanowi np. obiekt lub ich kolekcja albo np. plik XML (lub inny strukturalny). Struktury tych obiektów opisywane są na odrębnych diagramach. Tak więc początkowe

Użytkownik [po zalogowaniu się] widzi tylko takie produkty, które jego firma kiedyś zakupiła.

pokazane na powyższym diagramie sekwencji, polega na tym, że GUI zażąda od Logiki listę nazw produktów sprzedanych firmie, do której jest przyporządkowany zalogowany użytkownik. Żądanie to, po sprawdzeniu logiki praw dostępu itp., zostanie przekazane do repozytorium Informacje, które zwróci kolekcję obiektów spełniającą powyższy warunek. Jedna ważna rzecz: powyższe to nie „przypadek użycia” a reguła biznesowa: widzi tylko takie produkty, które jego firma kiedyś zakupiła. Przypadkiem użycie jest raczej usługa aplikacji Zarządzanie historia zakupów.

Mamy więc koncepcje rozwiązania (tak zwany model logiczny). Powyższe diagramy są tu uproszczone, wymagały by na pewno dopieszczenia ale ilustrują ideę obiektowej analizy i projektowania koncepcji rozwiązania. Realne projekty są oczywiście większe ale nie zapominajmy, że duże projekty dzieli się (powinno) na mniejsze (mikroserwisy). Model dziedziny dzieli się na obszary dziedzinowe, (moduły, podsystemy) by każdy z nich pozwalał na łatwe testowanie jak powyżej. Po drugie doświadczony analityk szybko wychwyci, które podsystemy można kupić na rynku (tak zwane ang.  COTS, Commercial of the Shelf), a które należy zaprojektować do wykonania. Systemy złożone projektuje się na pewnym wyższym poziomie abstrakcji (metodologia top-down), ale stale jest to model i jego testowanie. Ale to tylko (dla użytkownika aż) tak zwana logika biznesowa.

Programiści!

Nikt Wam nie odbiera chleba, macie dużo pracy: po pierwsze implementacja metod (algorytmów) poszczególnych obiektów (np. podaj nazwy produktów, które już raz kupiono), macie zadbać o to: system ma być bezpieczny, wydajny, działać zdalnie na telefonach komórkowych, ma być bezawaryjny itd. To wymagania poza funkcjonalne (lub w niektórych metodykach tak zwane ograniczenia).  Macie dziesiątki problemów technicznych do rozwiązania.

Ale proszę, nie udawajcie, że znacie się na zarządzaniu, marketingu, biznesie, sprzedaży, rynku, produkcji itp. bo to (poza pewnie istniejącymi wyjątkami) nie prawda, a projektowanie na zasadzie „wydaje mi się że rozumiem” to droga do porażki.

Powyżej struktura najczęściej używanego, w metodach obiektowych, wzorca projektowego. Można uznać to za założenia projektowe, tak wygląda „każdy” system (używających innych wzorców przepraszam). Powyższy diagram pozwala jednoznacznie przyporządkować odpowiedzialność za projekt: analityk projektuje warstwę Model, programiści całą resztą. Przypadki użycia, perspektywa obiektu User, także znajdą się w dokumentacji wymagań.  Co jeszcze powinna zawierać taka dokumentacja? Ewentualne oczekiwania użytkownika do interfejsu użytkownika (w końcu to zobaczy, i tylko to). wcześniejsze diagramy to model dziedziny i jego testowanie. Daleki jestem od narzucania wykonawcy, w dokumencie wymagań, pozostałych elementów oprogramowania ale model biznesowy to nie robota dla programistów!

Taki projekt jak powyżej pozwala na dokładną wycenę, oszacowanie pracochłonności. Mamy „opis przedmiotu zamówienia”.  Model dziedziny opisuje komponent Model, wymagania pozafunckjonalne pozostałą resztę.

Proszę, nie wmawiajcie swoim klientem, że poza user story i przypadkami użycia nie ma innych metod opisu wymagań, nie wmawiajcie, że nie ma standardów i że trzeba „próbować” się starać, bo to po protu nie prawda. To, że ktoś czegoś nie widział (nawet przez lata swojej pracy) nie stanowi żadnego dowodu na to, że to nie istnieje.

Tak więc specyfikacja wymagań funkcjonalnych bez takich testów i bez modelu dziedziny tak na prawdę o niczym nie mówi.  Czym to grozi? Tym, że zamawiający najczęściej dostanie to co chce (potrafi) dostarczyć dostawca a nie to czego potrzebuje.

Jak to wygląda dla systemów ERP?

Jeśli z analizy wyjdzie, że np. 3/4 wymagań mieści się w możliwościach gotowych rynkowych systemów (owe COTS) to się wybiera gotowy ERP (wybrane moduły) spełniający opisane wymagania (tylko przypadki użycia i model kluczowych obiektów biznesowych takich jak np. faktura VAT). I to jest właściwa kolejność. Co będzie jeśli zaczniemy od  wyboru gotowego systemu? Chyba nie muszę już odpowiadać…

Systemy ERP to złożone , wielomodułowe produkty. Czy jest sens specyfikowanie skończonej liczby oczekiwanych funkcjonalności (przypadków użycia) by wybrać taki system? Będzie ich nawet kilka tysięcy! Nie! Ani tego nie zweryfikujemy ani nie sprawdzimy podczas odbioru systemu (powodzenia w takich testach odbiorowych). Więc jak?

System ERP można wybrać na bazie projektu, tu tylko na nieco wyższym poziomie abstrakcji. Analiza firmy także polega tu na opracowaniu modeli procesów. Jednak w tym wypadku ich celem jest stworzenie raczej „modelu filozofii działania” firmy a nie projektowanie systemu od zera. Założenie: system na rynku istnieje, należy go jedynie wybrać z pośród wielu istniejących. Do tego potrzebny jest model dziedziny i koncepcja architektury a nie setki wymagań funkcjonalnych.

Najpierw dostawca systemu ERP i wykonana przez niego analiza przed wdrożeniowa czy może jednak najpierw analiza wymagań? Zadam to samo pytanie inaczej, coś z Państwa podwórka: najpierw analiza mieszkania i pomysł na meblowanie a potem jazda po sklepach i szukanie mebli, czy może najpierw dajemy sobie sprzedać meble a potem wciskamy je w nasze pokoje (plus osławiona ich kastomizacja)? Państwo sami musza podjąć decyzję, ryzyka opisałem. Powiem tylko tyle: warto zmierzyć dobrze mieszkanie, opracować pomysł, kupić na rynku to co pasuje,  a pozostałe zakamarki zlecić dobremu stolarzowi, który wpasuje meble i ładnie połączy je z już kupionymi.

A skąd brać te przypadki użycia?

Najgorsza metoda, bo nie poddająca się testowaniu (weryfikacji), to: wywiady, ankiety, warsztaty i podobne metody deklaratywne. Dostaniemy setki niespójnych wymagań, nie raz będących efektem wewnętrznych wewnętrznych negocjacji, rozgrywek (tak, niestety). Powstanie nieweryfikowalna lista na setki pozycji. Jak inaczej?

Analizujemy firmę, tworzymy jej model procesowy jak na diagramie powyżej. Model procesów testujemy z pomocą realnych dokumentów. Po takich testach, wybieramy na tym modelu te czynności, które uznamy za nasze wymagania. Praktyka pokazuje, że jest ich tak na prawdę dziesiątki a nie setki (są to logiczne czynności z ewentualnymi wariantami). Nie możemy się tu pomylić bo mamy przetestowany model procesowy firmy.  Jednak ten model także (podobnie jak modele UML) musi podlegać testom i formalizacji (najlepiej zastosować formalną, pozwalająca na testowanie, notację, np. BPMN – powyższy diagram). Bez tego, model procesów nie będzie lepszy od opisu słownego. Ale o tym już było 🙂 (i pewnie jeszcze będzie).

(więcej o przejściu z procesów na przypadki użycia: transformacja modelu procesów na model przypadków użycia)

Zamawiających nie stać na takie analizy jak powyżej.

Czyżby? Taka analiza to ok. 20% budżetu prac programistycznych i 50% czasu projektu. Bez niej jednak projekt płynie w user story, prototypy, odkrywanie wymagań w trakcie projektu, iteracje (Agile?), termin jest przesuwany kolejny raz. Klient płaci. Badania wykazują (i deklarują to także wykonawcy, czytaj poprzednie moje posty z cytatami, gorąco polecam blogi programistów i ich opinie o userach oraz analitykach i sprzedawcach ich firm!), że w konsekwencji kosztuje to  200% planu pierwotnego (typowy narzut dostawców oprogramowania, patrz diagram poniżej, bywa że narzucają nawet 500% na niewiedzę i niezrozumienie) !!!!!!

Powyższa metoda pozwala by projekt miał to co powinien mieć: dobrze określony zakres projektu (opis przedmiotu zamówienia) a na jego podstawie dobrze oszacowany budżet (rentowność!) i termin wykonania.

Nikt tego nie rozumie czyli kto i co czyta: adresaci dokumentów

Często innym, poza budżetem, argumentem przeciwko takim analizom jest zarzut: „Klient nie rozumie modeli ani diagramów więc po co je robić”. A kto powiedział, że Klient ma je czytać! Klient jest przede wszystkim źródłem wiedzy o własnej firmie, weryfikuje model procesów z pomocą analityka, ustala zakres projektu, sprawdza i potwierdza biznesowy opis swojej firmy i jej potrzeby. Potem zatwierdza ewentualne prototypy ekranów.

Ten zarzut niestety często stawiają także niekompetentni dostawcy, nie potrafiący nic innego poza eksperymentami, prototypami i zjadaniem budżetu Klienta: im więcej tym lepiej…

Modele procesów to narzędzie analityka, modele UML także ale te czyta wykonawca (jak wykonawca nie potrafi czytać UML to on ma problem, a nie analityk czy klient.!). To dokładnie tak jak z mieszkaniem: projektant wnętrz słucha klienta i pokazuje mu efekt pracy: wizualizację. Potem opracowuje dokumentacje techniczną dla stolarza, rysunki techniczne, nazwy materiałów. Tego klient faktycznie raczej nie rozumie ale nie dla niego są te dokumenty. Jednak dobry stolarz to twórczy inżynier, potrafiący wykonać projekt i nie wciska klientowi, tańszych materiałów, nie upraszcza finezyjnych zwieńczeń szafy bo po protu psuje.

Jak wiemy stolarze są różni dlatego coraz częściej projektanci wpisują do swoich umów tak zwany nadzór autorski nad realizacją. Ja także tak robię.

Dla zainteresowanych nieco więcej na ten temat na stronach MSDN:

http://msdn.microsoft.com/en-us/library/dd409376.aspx