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 czekają. Pokażę na prostym przykładzie, proces od analizy przez wymagania aż do projektu dedykowanego oprogramowania. Całość będzie zgodna z fazami CIM/PIM (www.omg.org/mda). Projekt dziedziny, który powstanie będzie spełniał zasady SOLID projektowania obiektowego, projektowania przez kompozycje (zamiast dziedziczenia) (polecam artykuł Łukasza Barana) i DDD. Opis dotyczy każdego projektu związanego z oprogramowaniem, także gotowym np. ERP, CRM, EOD itp.
Korzystałem z opisu zasad gry w szachy zamieszczonego na WIKI:
Zasady gry w szachy ? prawidła regulujące sposób rozgrywania partii szachów. Choć pochodzenie gry nie zostało dokładnie wyjaśnione, to współczesne zasady ukształtowały się w średniowieczu. Ewoluowały one do początków XIX wieku, kiedy to osiągnęły właściwie swą bieżącą postać. W zależności od miejsca zasady gry różniły się od siebie, współcześnie za przepisy gry odpowiada Międzynarodowa Federacja Szachowa (Fédération Internationale des Échecs, FIDE). Przepisy te mogą się różnić w przypadku różnych wariantów gry, np. dla szachów szybkich, błyskawicznych czy korespondencyjnych. (Zasady gry w szachy ? Wikipedia, wolna encyklopedia).
To na co chcę zwrócić tu uwagę w szczególności, to metafora:
projektując (modelując) oprogramowanie dla człowieka, modelujemy narzędzie dla tego człowieka a nie jego samego.
Swego czasu pisałem, w artykule o nazywaniu klas, że oprogramowanie z reguły zastępuje dotychczasowe narzędzie człowieka a nie człowieka jako takiego. Druga ważna rzecz: aktor jest równoprawnym elementem systemu (tu systemem jest organizacja z jej ludźmi i używanymi przez nich narzędziami). No to zaczynamy.
Cel zamawiającego
Często projekt zaczyna się od pustej kartki, ale nie raz Zamawiający (sponsor projektu) ma już swoje wymagania, z reguły jest to jakaś lista w rodzaju:
Z reguły z listy wymagań (a potrafi mieć setki pozycji) nie wynika wprost cel sponsora, a jedynie to jak sobie on wyobraża rozwiązanie swojego problemu (wyobraźcie sobie powyższą listę bez skrajnej lewej i prawej kolumny). Wstępne uporządkowanie tej listy pozwala uznać, że wymaganiem jest wytworzenie programu do gry w szachy na tablet i smartfon. Pozostałe to pewne cechy tego „głównego” wymagania biznesowego.
Od dłuższego czasu przestałem na tym etapie używać pojęcia wymagań funkcjonalnych i niefunkcjonalnych. Na prawie każdym szkoleniu i większości projektów usłyszycie, że to kanon analizy wymagań, a ja – i nie tylko jak pokazuje literatura- uważam, że skoro sponsor projektu (tak zwany biznes) z reguły nie rozumie tych pojęć, to nie należy ich używać w dialogu z biznesem na tym etapie projektu, a tym bardziej żądać takiego podziału. No to kiedy? Zobaczycie pod koniec :). Nie znam przypadku, by zamawiający „biznes” poprawnie rozróżnił te dwie grupy wymagań albo potrafił samemu spisać „przypadki użycia”. A jeżeli jeszcze zażądamy podziału na FURPS to będzie „masakra”. Czy ma to robić od razu analityk? A po co skoro Zamawiający i tak tego nie zweryfikuje a jest adresatem tego dokumentu? Na tym etapie, powyższa lista, można poprzestać na uznaniu powyższej listy za „wymagania biznesowe” (czyli te, które wprost formułuje „biznes”).
You need to pay to see more.
Na zakończenie
Analiza i projektowanie obiektowe (ang. OOAD) to niejako „implementacja” klasycznej analizy systemowej. Nie ma ona nic wspólnego ze strukturalnymi metodami analizy i projektowania oprogramowania (czego wielu zdaje się nadal nie dostrzegać). Wygląda na to, że jest znacznie trudniejsza ale praktyka pokazuje, że daje znacznie lepsze rezultaty. Języki obiektowe to nie jakieś tam nowa nazwa klasy na podprogramy, a zupełnie nowy paradygmat programowania: musi być poprzedzany analizą i projektem. Jego zaletą jest to, że pozwala na odwzorowywanie, niemalże jak w grze, analizowanego i rozwiązywanego problemu, pozwala na przetestowanie pomysłu na program zanim powstanie choć jedna linia programu. Problemem i wyzwaniem na etapie analizy jest zrozumienie problemu, co mam nadzieję pokazałem.
Niestety wiele analiz dokumentowanych z użyciem notacji UML nie ma wiele wspólnego z OOAD, stanowią echa strukturalnych metod analizy i projektowania, stosowania baz relacyjnych już na etapie analizy (obiektowe narzędzia nie czynią projektów obiektowymi). Niestety błędy te popełniają nawet wykładowcy wielu uczelni i kursów.
Bardziej rozbudowany projekt, wraz z filmem o jego powstawaniu tu: Inżynieria oprogramowania z użyciem narzędzia CASE ? przykładowy projekt
Koszty
Są zależnie od składu zespołu developera i metody pracy. Ale zespół programista i tester, powyższe, robione metodą „agile”: czyli user story i od razu burza mózgów, „wsadzenie” do frameworka, kodowanie, testy, prototyp, testy u zamawiającego i kilka takich iteracji versus powyższe (to praca analityka tu moja, na jeden dzień). Porównanie kosztu musi każdy zrobić sam, ale z mojego doświadczenia wynika, że dojście do tego etapu (przemyślana i sprawdzona logika systemu) metodami burz mózgów i prototypowania – kolejne wersje kodu dla Klienta – to kilkukrotnie większy koszt i czas w porównaniu z opracowaniem powyższej analizy i projektu i wykonania poprawnego oprogramowania za niemalże pierwszym podejściem na bazie przemyślanego projektu (pisze na bazie wykonanych projektów, ale proporcje mogą być inne z innym zespołem). Na koniec statystyka pewnego developera (polecam cały wątek):
I started a company called Nascent Blue that specializes in MDD for application development. We have actually had the opportunity to compare MDD to traditional development side-by-side on large projects. Our client set up „the experiment” to collect the PM data for analysis. It was a large project with 5 teams. The results:
1. Our team was less than half the size of the other teams.
2. Our team produced more than twice the code of the other teams.
3. Our team achieved a 75% reduction in cost.
4. Our team achieved a 66% reduction in defect rate.
5. Our team was twice as fast (with half the size).
We have since gotten more efficient and more advanced, so I don’t know what the numbers are now.
We develop our own modeling tools (UML, ERD, and DSLs for UI and other things). We also have tools for ADM, so we can achieve similar productivity gains for re-platforming and re-architecture projects.
Literatura
Wyjątkowo podam zalecaną literaturę z nadzieją, że choć cześć tego uda się Wam analitykom, przeczytać. Sponsorom projektów polecam rozważny dobór analityków i projektantów :).
Kolejność troszkę przypadkowa (czyli z mojej półki i tylko część ;)):
1. Tytuł: Metody obiektowe w teorii i praktyce, Autor: Ian Graham, Wydanie: WTN, Warszawa 2004
2. Tytuł: Inżynieria Projektowania Strategii Przedsiębiorstwa, Autor: Lechosław Berliński, Ilona Penc-Pietrzak, Wydanie: Difin, Warszawa 2004
3. Tytuł: Inżynieria systemów informacyjnych, Autor: Paul Beynon-Davis, Wydanie: Warszawa, WNT 2004
4. Tytuł: UML. Inżynieria oprogramowania. Wydanie II, Autor: Perdita Stevens, Wydanie: Helion 2007
5. Tytuł: Strategie Konkurencji, Autor: David Faulkner, Cliff Bowman, Wydanie: Gebethner i ska, Warszawa 1996
6. Tytuł: Cybernetyka w zarządzaniu. Modelowanie cybernetyczne. Sterowanie systemami, Autor: Zdzisław Gomółka, Wydanie: Warszawa, Placet 2000
7. Tytuł: Modele referencyjne w zarządzaniu procesami biznesu, Autor: Tadeusz Kasprzak, Wydanie: Difin, Warszawa 2005
8. Tytuł: Teoria i Inżynieria Systemów, Autor: Czesław Cempel, Wydanie: Czesław CEMPEL, Poznań 2008
9. Tytuł: Business Inteligence, Autor: Jerzy Surma, Wydanie: PWN, Warszawa 2009
10. Tytuł: Architektura systemów zarządzania przedsiębiorstwem. Wzorce projektowe, Autor: Martin Fowler, Wydanie: Helion Gliwice
11. Tytuł: Head First Object-Oriented Analysis and Design, Autor: Brett D. McLaughlin, Gary Pollice, David West, Wydanie: Helion, Gliwice 2008
12. Tytuł: Projektowanie hurtowni danych. Zarządzanie kontaktami z klientami (CRM), Autor: Todman Chris, Wydanie: WNT, Warszawa 2003
13. Tytuł: Komponenty w UML, Autor: John Cheesman, John Daniels, Wydanie: WNT, Warszawa 2000
14. Tytuł: UML przewodnik użytkownika, Autor: Grady Booch, James Rumbaugh, Ivar Jacobson, Wydanie: WNT, Warszawa 2002
15. Tytuł: Inżynieria oprogramowania, Autor: Ian Sommerville, Wydanie: WNT, Warszawa
16. Tytuł: Projektowanie zorientowane obiektowo. Wzorce projektowe, Autor: Alan Shalloway, James R. Trott, Wydanie: Gliwice, Helion 2005
17. Tytuł: Wdrażanie strategii dla przewagi konkurencyjnej, Autor: Robert S. Kaplan, David P. Norton, Wydanie: PWN, Warszawa 2010
18. Tytuł: Wzorce projektowe, Autor: E.Gamma, R.Helm, R.Jonson, J.Vlissides, Wydanie: Helion, Gliwice 2010
19. Tytuł: UML w kropelce wersja 2.0, Autor: Fowler Martin, Wydanie: LTP
20. Tytuł: Analysis Patterns. Reusable Object Models, Autor: Martin Fowler, Wydanie: Addison-Wesley, 1997
21. Tytuł: Podstawy metod obiektowych, Autor: James Martin, James J.Odell, Wydanie: WNT, Warszawa 1997
22. Tytuł: Tworzenie architektury oprogramowania, Autor: Christine Hofmeister, Robert Nord, Dilip Soni, Wydanie: WNT, Warszawa 2006
23. Tytuł: Business Process Management, Autor: John Jeston, Johan Nelis, Wydanie: Butterworth-Heinemann, 2008 (Reprint 2009)
24. Tytuł: Requirements Analysis and System Design, Autor: Leszek A. Maciaszek, Wydanie: Addison Wesley 2001
25. Tytuł: Object-Oriented Construction Handbook, Autor: Heinz Zullighoven, Wydanie: Elsevier Inc. 2005
26. Tytuł: Stosowanie przypadków użycia, Autor: Geri Schneider, Jason P. Winters, Wydanie: WNT, Warszawa 2004
27. Tytuł: Porter o konkurencji, Autor: Michael E. Porter, Wydanie: PWE, Warszawa 2001
28. Tytuł: Strategie Konkurencji, Autor: Michael E. Porter, Wydanie: MT Biznes, Warszawa 2006
29. Tytuł: Michael E. Porter, Autor: Przewaga konkurencyjna, Wydanie: Helion, Gliwice 2006
30. Tytuł: Systems Analysis and Design with UML Version 2.0, Autor: Alan Dennis, Barbara Halley Wixom, David Tegarden, Wydanie: Second edition, John Wiley and Sons, Inc. 2005, USA
31. Tytuł: UML i wzorce projektowe. Analiza i projektowanie obiektowe oraz iteracyjny model wytwarzania aplikacji, Autor: Craig Larman, Wydanie: Helion, Gliwice 2011
32. Tytuł: Object-Oriented Construction Handbook: Developing Application-Oriented Software with the Tools & Materials Approach, Autor: Heinz Züllighoven, Wydanie: Morgan Kaufmann; 1 edition, October 13, 2004
33. Tytuł: Domain-Driven Design: Tackling Complexity in the Heart of Software, Autor: Eric Evans, Wydanie: Addison-Wesley
(zainteresowanych poznaniem opisanych metod analizy i projektowania zapraszam na moje szkolenia)
A na zakończenie cytat:
Moja rada dla osób zaczynających pracę w IT… zanim usiądziesz do komputera i zaczniesz programować czy konfigurować weź kartkę, pomyśl, napisz i narysuj co chcesz zrobić, pomyśl jeszcze raz, popraw, pokaż innym, spytaj ich o opinie, po raz kolejny pomyśl, jeszcze raz popraw i dopiero wtedy siadaj do komputera. (Zanim zaczniesz programować weź kartkę, pomyśl, napisz i narysuj co chcesz zrobić – Computerworld).
W sieci można znaleźć wiele takich i podobnych przykładów, tu jeden z nich który polecam. Powyżej opisywałem proces analizy biznesowej i projektowanie z użyciem trzech notacji (narzędzi), bo każde z nich powstało dla danego obszaru pojęciowego (osobno BMM, BPMN i UML). Poniżej przykład analizy (a raczej specyfikacji, autorka opisała treść dokumentu a nie jak powstawał) jednak co do zasady jest to „klasyczny” proces od opisu biznesu do specyfikacji aplikacji, dodam – bo tu to ważne – autorka korzystała wyłącznie z możliwości MS Office/Visio (Visio, poza pewnymi nieformalnymi bibliotekami symboli do tworzenia schematów blokowych, nie zawiera innych notacji niż UML):
Complete Business-Systems Analysis Model (UML Example) […] NOTE: The following example is the result of an analysis effort that was constructed with MS Visio and Word. (Complete Business-Systems Analysis Model (UML Example).
Bardzo dziekuję za ten artykuł. Jeszcze go szczegółowo nie skomentuję, bo do dobrego przetrawienia tak dużej ilosci skondensowanej wiedzy potrzeba go z kilka razy przeczytać. Na razie spraktykuję część sprzed „kości niezgody”. Wnioski ogólne pozwolę sobie potem umiescić w komentarzu.
Artykuł jest zdecydowanie ciekawy, niemniej jest jednocześnie zbyt ogólny by miał zastosowanie w praktyce, i zbyt szczegółowy bym wiedział gdzie dalej szukać odpowiedzi na pewne pytania.
Od nagłówka „Model dziedziny” artykuł przestał być dla mnie zrozumiały, ponieważ użyto pojęć których nie znam z definicji a nie ma tych definicji podanych w tekście.
Niemniej, źródło jest wartościowe jako początek poszukiwań.
Kolejna kwestia to taka, że nie widzę wartości w tak niskopoziomowej analizie. Diagram dziedziny i ilustracja Inicjacji gry są niezrozumiałe dla mnie jako laika i tak samo będą niezrozumiałe dla mojego klienta.
Nie wiem więc czemu dokładnie służą i co wnoszą.
Zabezpieczają przed ryzykiem wykonana przez developera złej (czytaj kosztownej w wykonaniu i w utrzymaniu) implementacji. Ten poziom „szczegółowości” chroni inwestora przed developerem (ten dokument jest dla developera a nie dla sponsora projektu, podobnie jak projekty architektoniczne zleca się w biurze architektonicznym nie wykonawcy).
Problemem większości projektów IT jest założenie, że tylko dostawca/wykonawca usługi ma wiedzę o tym jak to zrobić. Tezę tę forsują najczęściej własnie wykonawcy (developerzy), a problem polega na tym, że wykonawca dąży tu do sytuacji gdy sam sobie stawia wymagania a potem rozlicza ich realizację.
Artykuł wskazuje ryzyka a potem „właściwe postepowanie”. Przewrotnie odpowiem: to, że Pan nie rozumie „Od nagłowka…” znaczy, że nie powinien sam zlecać takich prac, bo nie ma Pan żadnej możliwości oceny czy to co Pan dostał jest tym co Pan zamówił.
Artykuł został uzupełniony o komentarz dot. wartości dodanej części projektowej, czyli przed czym chroni Zamawiającego druga część, ta której zamawiający nie rozumie.
Dodałem na końcu artykułu link do innej ciekawej przykładowej innej analizy, wykonanej w całości w UML (ograniczenie MS Visio).
Herezji krąży po sieci wiele, tu np. tylko trzeci diagram jest poprawny: http://stackoverflow.com/a/26203938
Odkopałem artykuł, ale do takich zawsze warto wracać. Mam pytanie o strzałki zwrócone wstecz na diagramie procesów biznesowych i „cofanie się w czasie”. Gdzieś wspominałeś, że taki zapis może mieć wątpliwe interpretacje w kontekście definicji procesu biznesowego (chronologiczny ciąg czynności). Czy ma sens modyfikacja diagramu i przypięcie do czynności „Przemieszczenie bierki” zdarzenia „Koniec rundy” zamiast bramki?
Na tym diagramie pokazałem także „procedurę” (pętla), stąd ta „strzałka wstecz”. Troszkę „na skróty” (skrót myślowy ;)) umieściłem na diagramie „jawnie” tę pętlę. W BPMN można to (konstrukcja pętli „do siebie”) zastąpić dedykowanym symbolem (aktywność oznaczona pętelką u dołu, element Loop w BPMN).
Można to podzielić na dwa procesy:
– inicjacja gry (wykonywa raz dla danej partii),
– przemieszczenie bierki (wykonywany „na żądanie” gracza aż do zakończenia partii).
Wtedy nie będzie tej „pętli” a model będzie także poprawny.