Wprowadzenie Pojęcie kontekstu projektu i diagram przypadków użycia jako narzędzie, nadal rodzi wiele pytań. Spowodowane jest to tym, że diagram przypadków użycia to najczęściej wykorzystywany diagram, najczęściej też "nielegalnie przeciążany"…
Bez tej formalizacji (ścisłe stosowanie zdefiniowanych pojęć, także tych z użytej notacji) próby modelowania procesów prowadzą najczęściej do powstawania monstrualnych ilości nieczytelnych diagramów (widywałem dokumentacje, gdzie było dla jednej firmy powstałe blisko tysiąc stron! Masakra). To kompletnie nieprzydatne dokumenty. Co jeszcze nam daje stosowanie powyższych definicji? Możliwość jednoznacznego "przejścia" (śladowanie) z modeli procesów biznesowych na modele przypadków użycia bo atomowy proces, zakwalifikowany do zakresu projektu jako wymagana usługa oprogramowania, to przypadek użycia, zaś procedura tego procesu to nic innego jak scenariusz tego przypadku użycia lub jak ktoś woli: user story. Z innej strony: jeżeli mamy wdrożona normę ISO9000, to modelując procesy biznesowe i "podpinając" do nich procedury z księgi jakości, szybko się przekonamy, czy nasze ISO to nie jest przypadkiem fikcja.
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…
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?
I tak mamy: 100% interfejsu użytkownika zamawia użytkownik (sam lub z pomocą specjalistów), 100% wymagań funkcjonalnych realizuje Model Dziedziny (projekt analityka-projektanta), 100% wymagań poza-funkcjonalnych realizuje developer (projekt i implementacja). Developer także implementuje model dziedziny z pomocą technologii jakiej używa. A jeżeli klient powie: nie mamy tych wzorów dokumentów i ekranów! To pierwszy sygnał, że nie ma podstaw do zamawiania jakiegokolwiek oprogramowania, bo najpierw trzeba "wiedzieć co się chce". Jak to zrobić? Tu kłania się analiza biznesowa: modelujemy procesy biznesowe, dla każdego z nich ustalamy wejście oraz efekt (produkt) czyli właśnie owe "wzory dokumentów". Po uporządkowaniu tego i upewnieniu się, że nie ma w tym bałaganu (powtórki, braki, niekonsekwencje, sprzeczności itp.) możemy pytać o gotowe oprogramowanie lub "zamawiać" jego wytworzenie. Produktem pracy analityka powinny być, poza modelami procesów bo one są narzędziem a nie celem, obiektowy model dziedziny czyli model tego jakimi informacjami i jak zorganizowanymi operuje organizacja, oraz to jak pracownicy tej organizacji chcą się komunikować z oprogramowaniem (źrodłem informacji jest jednak klient). Mamy czysty podział odpowiedzialności i łatwość rozliczenia projektu. Na czym polega haczyk? Klient nie może unikać odpowiedzialności za skutki swoich decyzji i udzielanych informacji. Ale też, co jest kluczowe: Analityk musi zrozumieć problem i zaproponować rozwiązanie. Jednak nie jest rolą analityka wykonanie oprogramowania! To "jak - technologia - ma to zostać zrealizowane" jest decyzją developera. Ma dużo pracy. Nie zapominajmy, że kod realizujący tak zwaną logikę biznesową to ledwie kilka procent całości kodu aplikacji, jednak nie zapominajmy także (programiści), że zła logika biznesowa dyskwalifikuje całe to oprogramowanie z prostego powodu: staje się nieprzydatne.