Jestem gorącym fanem blogów dobrych (tak sądzę, że są ;)) programistów. Dlaczego? Bo to oni się męczą z moimi projektami. O czym powinien pamiętać dobry analityk projektant? O dwóch rzeczach (zresztą o tym powinie pamiętać każdy): po pierwsze nie zapominaj kim jest Twój klient – mów do niego jego językiem, po drugie jak coś tworzysz dla swojego klienta to nie po to by on musiał to jeszcze raz po Tobie zrobić po swojemu.
Analitycy jako zasoby
W projektach informatycznych najczęściej spotykamy: analityka wymagań (AW), analityka systemowego (AS), dewelopera w tym architekta systemu (D). W zasadzie trudno powiedzieć co jest produktem dwóch pierwszych bo Deweloper oddaje działające oprogramowanie. Najczęściej AW dostarcza jakiś opis tego czego oczekuje klient, AS porządkuje to co zrobił AW np. z pomocą przypadków użycia a D bierze to do ręki i musi zaprojektować i wykonać oprogramowanie. Jak widać, odpowiedzialność za to co powstanie jest rozmyta. Klient najpierw przekazuje swoje oczekiwania AW zaś otrzymuje produkt od D. Konia z rzędem temu, kto mi powie jak tego dokonać bez permanentnych iteracyjnych wyjaśnień i bombardowania Klienta pytania w rodzaju „co Państwo mieli na myśli pisząc/mówiąc, że …”.
Od końca. By powstało oprogramowanie (zakładam na dziś, że metodami obiektowymi) musi powstać jego specyfikacja, projekt który dokładnie opisuje co mają zakodować programiści. Bez tego nie wiadomo ani co ma powstać ani ile to wymaga pracy. Aby powstała specyfikacja musi powstać opis logiki systemu bo tego właśnie oczekuje Klient. Aby ta logika powstała trzeba dokładnie zrozumieć to czego klient oczekuje, jako że oczekuje narzędzia wspomagającego zarządzanie jego firmą, należy tę firmę dokładnie opisac a wcześniej zrozumieć.
W czym problem? Mając trzy role w projekcie: AW, AS i D powstaje zabawa w głuchy telefon, która kończy się tym, że kontaktują się z Klientem wszyscy bo opis słowny wymagań z reguły jest nieprecyzyjny i niekompletny. AS na bazie tego opisu coś projektuje, D tworzy pierwszą wersje systemu. Klient to dostaje i zgłasza uwagi i oczekiwania, bo to tak na prawdę jego pierwszy kontakt z produktem. Proces ten zna każdy kto brał udział w takim projekcie (pozostałych przestrzegam przez takim podejściem).
Powyżej opisany bieg wydarzeń to zasobowe (silosowe) podejście do projektu: jak użyć ludzi o posiadanych kompetencjach.
Analityk i deweloper jako właściciele procesów
Jak należało się spodziewać, musiało to doprowadzić do szukania rozwiązania. Podobnie jak w zarządzaniu w innych obszarach, zaczynamy mówić o „procesie wytwarzania oprogramowania”. A skoro mowa o procesie to powinny się pojawić produkty poszczególnych pod-procesów, ich wykonawcy są wtórni wobec produktów. Najpierw definiujemy produkt potem wskazujemy odpowiedzialnego.
W procesie wytwarzania oprogramowania potrzebne sa trzy produkty:
- opis celu biznesowego i strategii jego osiągnięcia, jednym z narzędzie zapewne będzie jakieś oprogramowanie,
- projekt oprogramowania, należy je zaprojektować,
- wykonane (dostarczone) oprogramowanie.
Mamy więc trzy oczekiwane produkty czyli trzy procesy: analiza biznesowa, projektowanie, wykonanie (implementacja). Projekt jest ściśle powiązany z analizą biznesowa, gdyż powstaje na bazie niej i jej pełnego zrozumienia, nasuwa to wniosek, że jedna osoba powinna odpowiadać za projekt i dobrze jest jeśli będzie to autor analizy biznesowej. Jakie rozwiązanie jest więc skuteczne?
Tym rozwiązaniem wydaja się być:
- metody obiektowe analizy, projektowania i implementacji,
- podział procesu na dwa etapy i dwie role: opracowanie projektu logiki systemu i implementacja,
- [[wzorzec projektowy MVC]] i [[projektowanie metodą DDD]].
W dużym uproszczeniu:
- metody obiektowe pozwalają na używanie od samego początku tego samego sposobu opisu (modelowania) rozwiązania, które powstaje w miarę postępów analizy, zapis tego czego oczekuje Klient to Przypadki Użycia (czarna skrzynka) oraz Model Dziedziny (projekt – biała skrzynka),
- do tworzenia oprogramowania używa się obecnie najczęściej frameworków bazujących na [[wzorcu MVC]] dla którego [[Model Dziedziny]] zaprojektowany zgodnie z DDD, jest gotowym projektem logiki komponentu Model z MVC zaś Przypadki Użycia to wymagania na interfejs użytkownika opisany jak V w MVC (komponent C – kontroler – odpowiada za sterowanie aplikacją i realizację wymagań poza-funkcjonalnych).
Można wiec powiedzieć, że kierunek jest taki:
Tak więc z trzech, niejasno określonych ról tworzą sie dwie:
- Analityk Biznesowy, którego rolą jest dostarczyć wymagania funkcjonalne (przypadki użycia wraz z ograniczeniami) oraz Model Dziedziny,
- Deweloper, którego rolą jest dostarczenie oprogramowania implementującego tak określone Wymagania, Developer „ma” Architekta Systemu czyli projektanta implementacji.
Jest to „promowany” przez [[IIBA w BABoK]] proces i zakres kompetencji.
Teraz kolej na donosy z innego bloga, jest to blog programisty:
Jeff Bay proponuje w nim 9 reguł dotyczących tworzenia kodu (przykłady są w javie, ale większość reguł odnosić się może do w miarę dowolnego języka, szczególnie OO). Są to:
- Tylko jeden poziom zagłębienia na metodę
- Nie używaj słowa kluczowego else
- Opakowuj wszystkie prymitywy i Stringi (w klasy o specyficznej dla zastosowania nazwie)
- Używaj tylko jednej kropki na linię
- Nie skracaj nazw
- Pilnuj wszystkie encje by były małe
- Nie używaj klas o więcej niż dwóch polach
- Klasa której polem jest kolekcja nie powinna mieć żadnych innych pól (opakowywanie kolekcji w klasy specyficzne dla kontekstu wykorzystania)
- Nie używaj getterów/setterów/własności
(źr. Sprawna Inżynieria Oprogramowania: Ekstremalna obiektowość.)
Jeżeli uznać, że to wymagania w ogóle na projekt obiektowy to są to wymagania dla mnie: Analityka Biznesowego, na to jak ma wyglądać Model Dziedziny Systemu.
Po co to wszystko? Bo tu nie ma głuchego telefonu, produkt powstaje w pierwszej iteracji i każdy dokładnie wie za co odpowiada. Całość trwa krócej i jest mniej kosztowna.
P.S.
A tym jak taki produkt, Wymagania, powstaje pisałem już wcześniej, o tym jak się to implementuje niech piszą programiści 🙂
P.S. 2
Polecam także inne ciekawe spojrzenie na ten problem w artykule Analityk systemowy – łącznik dwóch światów. Tu faktycznie staje się problematyczne stwierdzenie kim jest, a kim nie, analityk systemowy. Być może Analityk Systemowy jest właściwszym terminem, jednak ja boje się tego, że powszechnie kojarzone z informatyką pojęcie „system” zaburza tak pojmowane znaczenie „analizy systemowej”, która nie koniecznie dotyczy systemów IT. Modelowanie biznesu (firm, organizacji) metodami znanymi z analizy systemowej ([[ogólna teoria systemów]]) jest chyba jednak analizą biznesową (tego biznesu), ale mogę się mylić…
O ile z niektórymi regułami z tych 9-ciu mogę się zgodzić o tyle niektóre z nich są kompletnie bez sensu. Dla przykładu tylko jeden poziom zagłębienia na metode.
niektóre znane algorytmy wymagają 2- lub 3-krotnego „zagłębienia” i rozbijanie ich na wiele metod nie ma za bardzo sensu.
To samo tyczy się obiektów domenowych z kolekcjami. OK, więc menadżer ma wskaznie do obiektu trzymającego listę podwładnych… i cała ta zabawa w jedną kropkę idzie wkibidibatri 😀
Trudno mi oceniać szczególnie te dotykające implementacji ale, hm.. niektóre zalecenia faktycznie są nieco hardcorowe. Ale z mojej strony:
– zagłębianie metod poza mną bo ich nie implementuję,
– else także poza mną,
– prymitywy poza mną,
– kropka także,
– za skracanie nazw potrafię zabić
– małe encje, owszem jestem za
– z tym jednym polem jako kolekcją to skłaniam się ku temu także, kolekcja sama z siebie jest „ważnym kawałkiem” i faktycznie odpowiedzialność za zarządzanie kolekcją powinna być wystarczającym zadaniem dla klasy, ja to nazywam jedna kuwetka służy do trzymania tylko jednego typu papierków,
– getterów/setterów także nie lubię,
Hm… tyle w kwestii głosu projektanta… który nie implementuje 🙂
Ja jako developer, projektant czy architekt aplikacji mam nieco inne spojrzenie na rolę MVC i DDD.
MVC traktuję jako czysto techniczny wzorzec architektur aplikacji. Widoki, owszem wynikają z wymagań (a ich sekwencja ze scenariuszy), ale pozostałe komponenty (C i C) są czysto techniczne. Kontroler jest mocno związany z technologią prezentacji i nie umieszczał bym w nim logiki aplikacji poza wysyłaniem sygnałów do modelu i ew. wybieraniem nowego widoku (ale to może zależeć od logiki biznesowej). Model w tym wzorcu ma również ujęcie bardzo techniczne – to co pobieramy z serwera (Encje, DTO) i to do czego delegujemy pracę (servisy apliakcyjne).
Natomiast to w samym DDD widzę wszystkie istotne z puntu widzenia analizy odpowiedzialności, o których piszesz przy okazji MVC i DDD. Bo DDD to dwie warstwy: Logika Domenowa i Logika Aplikacji. Logika Domenowa to nasz model biznesu zbudowany przy pomocy standardowych Building Blcoków (same Encje nie wysatrczą, dlatego BB jest ok 7). Natomiast Logika Aplikacji, która jest ponad Logiką Domenową może modelować: Use Casy (orkiestruje obiektami domenowymi) oraz jest odpowiedzialna za wspomniane wymagania poza-funkcjonalne.
Sklejając to razem: z punktu widzenia MVC, modelem jest warstwa Logiki Aplikacji DDD – czyli serwisy aplikacyjne i to co ich apli należy, czyli jakieś obiekty transferowe (chyba, że w prostych przypadkach pokazujemy model biznesowy wyżej i nie używamy obiektów transferowych).
Tak więc możemy dowolnie zmieniać technologię warstwy prezentacji (czyli kontrolery i widoku). Zatem jest ona pomijalna w analizie. Jeżeli Use casy są modelowane przez servisy Logiki Aplikcjai to klientem do tych servisów może być nawet aplikacja konsolowa (i o to zresztą chodzi w testowaniu behawioralnym zachowania modelu biznesowego).
Technicznie można podejść też inaczej do projektowania API Warstwy Logiki Aplikacji – Commandy i Qwereny z architektury CqRS. Ale to tylko inne ujęcie API od strony technicznej – z punktu widzenia analizy niewiele się zmienia.
Natomiast co do ról w projekcie to idealnie byłoby aby te role były grane przez jedną osobę (grupę osób, gdzie każda ma wszystkie role). Wówczas nie zajdzie nam zjawisko głuchego telefonu – chyba, że ktoś to rozszczepienie jaźni;)
Czy developer może rozmawiać wprost z klientem? To zależy który:)
W DDD mówi się głośno o różnych skillsetach jakie mają developerzy. W modelowaniu DDD preferowana jest inteligencja werbalna nad inteligencją algorytmiczną – chodzi tutaj o jasne, klarowne i eleganckie wyrażanie modelu (nie oszukujemy się, w biznesie nie występują zbyt często na prawdę trudne algorytmy).
Po pierwsze mogę tylko potwierdzić, że algorytmy w biznesie do skomplikowanych nie należą:). W kwestii logiki aplikacji, osobiście skłaniam się ku „nie eksponowaniu encji” jako czegoś specjalnego w Modelu. Klasa będąca Fakturą i klasa WystawiaczFaktur, ją tworząca z: Produktów, Kontrahenta, Składników podatkowych itp. (np. wzorzec Fabryka lub Prototyp) to dwie równoprawne klasy. Potrzebna jest trzecia klasa: SzafaNaFaktury. Przypadek użycia „Wystaw Fakturę” wywoła metodę nowa_faktura, która utworzy nowy agregat FakturaVAT, ten ma metody pozwalając ją wypełnić. Na koniec WystawiaczFaktur wrzuci FakturęVAT do SzafyNaFaktury (tu wzorzec repozytorium). Całość mieści się w Modelu z MVC, to zaś można umieścić w dowolnym frameworku. Tak to postrzegam. Analityk Biznesowy w zasadzie powinien stworzyć Model jak wyżej, dla pewności dla każdego przypadku użycia opracować scenariusz (diagram sekwencji) by zweryfikować poprawność Modelu: kompletność klas w modelu i ich odpowiedzialności, kompletność ich atrybutów i metod. To tak w telegraficznym skrócie moje postrzeganie „problemu”. Taki „produkt” analiz i projektowania wymaga już tylko implementacji…
Przeczytałem kilka postów z przełomu 2010/2011 i teraz rozumiem, że mam w głowie inną projekcję opisywanych ról oraz nieco inną projekcję MVC. Co w rezultacie powoduje, że mój poprzedni komentarz jest w sumie tylko niepotrzebnym szumem w sieci:)
Eeee bez przesady :), te role w zasadzie nie są nigdzie ściśle z definiowane stąd moje próby. Powyższe są oparte na produktach i procesie a nie na kompetencjach, które tu są wtórne.
Wszystko by było fajnie, gdyby autor nie popełnił podstawowych błedów i nie wykazał się zbyt ogólnym spojrzeniem na problem. Cytat „(komponent C ? kontroler ? odpowiada za sterowanie aplikacją i realizację wymagań poza-funkcjonalnych).” Z tego co pamiętam C w MVC zajmuje się własnie tzw. logika biznesowa a nie realizacja wymagań poza-funkcjonalnych.
Nie zgadzam się też z „By powstało oprogramowanie (zakładam na dziś, że metodami obiektowymi) musi powstać jego specyfikacja, projekt który dokładnie opisuje co mają zakodować programiści”. Sprowadza to programistów do roli „inteligentych maszyn do pisania”. Problem w tym ze takie podejscia trenowano od kilkunastu lat, probujac pozbyc sie inteligentych i drogich maszyn do pisania, patrz MDA. Zakonczylo sie to kilkoma ladnymi kleskami, w ktorych wielu z nas bralo udzial. Sprowadzajac role programistow do „tych co to dokładnie przepisuja to co stworzyli projektanci” tworzymy kolejny uklad „my analitycy/architekci” kontra „wy programisci”. Uwazam taki podzial rol za kompletna bzdure. Sam piszesz „Mając trzy role w projekcie: AW, AS i D powstaje zabawa w głuchy telefon, która kończy się tym, że kontaktują się z Klientem wszyscy bo opis słowny wymagań z reguły jest nieprecyzyjny i niekompletny.” Skoro te role i taki podzial rol powoduje tyle problemow to jaki jest sens ich istnienia i utrzymywania? Przytocze tu jedna z zasad metodologii Lean, „Eliminate waste”. Dla mnie jesli cos wprowadza tylko zamieszanie, i problemu komunikacyjne a na koncu i tak programista musi pogadac z klientem, to prosty sygnal ze te role w projekcie to tzw. „waste” wiec czas sie ich pozbyc. Problem z tym zwiazany jest jeszcze taki ze te role w projekcie sa czesto w firmach przekuwane na stanowiska, i tu sie zaczyna klasyczne „jestem analitykiem to juz nie moj problem, jestem architektem ja sie tym nie zajmuje”. Jesli nie jestesmy czegos w stanie zdefinowac, lub zdefiniowane role wprowadzaja kolejny narzut w procesie to czysty sygnal ze nalezy sie tego pozbyc. Oczywiscie to wszystko w kontekscie skali i klasy problemu (pozdrowienia dla Sławka). 80% procent projektów nie jest tak zlozonych, wielkich i przerosnietych aby potrzebowac takiego jasnego podzialu i wydzielenia rol.
Przyznaje się do pewnych uproszczeń, bez tego ten artykuł to materiał na książkę. Niewątpliwie bronię tezy, że potrzebny jest podział na etapy projektowanie i implementacja, wyznaczenie odpowiedzialności za etap. Ktoś powinien najpierw „zamknąć temat” czym jest faktura i jak się ją wystawia a dopiero potem pozwolić na implementację „wystawianie faktury”. Zabawa w fakturę metodą: może kolejny prototyp tego co zrozumiał programista” się spodoba klientowi, to właśnie droga donikąd. Bez tego mamy strasznie rozmytą odpowiedzialność, nie da się wszystkiego załatwić burzą mózgów.
Napisałem sam, że trzy rozmyte role AW, AS i D nie służą projektowi i zamieniam je na dwie AB i D (czy to lean?). Zresztą nie ja a są to zalecenia IIBA ).
Daleki jestem od zamiany programisty w maszynę do pisania. Problemów technicznych do rozwiązania podczas implementacji nie brakuje, ale będę bronił tezy, że nie jest rolą programisty udział w dyskusji o tym jak policzyć podatek VAT na fakturze. Tu programista nie ma nic do gadania bo to nie jego kompetencje i nie ten etap projektu.
Owe 80% Sławka jest także ważną informacją, ja piszę (tego faktycznie nie wskazałem) o projektach biznesowych, które być może są nudne dla programisty ale to chyba większość projektów na rynku.
Tu mamy namiastkę tego o czym piszę:
http://www.goldenline.pl/forum/2358572/powiazania-dwustronne/s/1#42942611
O M Goooosh!!!!!!!!!!!!!! Wiem, że ja jestem ciężki w obyciu ale jak mnie ktoś katuje takimi obrazkami to sie w sobie zamykam…
Wiecie co? Dajmy tym architektom rysować te ich diagramy, ludziki, kreski, przejścia i wogole cały ten ich juemelowy staf.. przecież każdy ma swoje zabawki i nie ładnie jest się śmiać z tego, że kolega ma je gorsze lub inne lub mniej trendi. Wszystko to pod jednym warunkiem, że nie beda pokazywać tego programistom tylko sie zbiorą w sobie, zapną pas i udźwigną ciężar pisania storyjek. Bo takie wymagania jak to co kolega Jarosław pokazał w poście, którego tutaj przytoczył to jest wszystko tylko nie coś na podstawie czego można pisać oprogramowanie.
Generować być może ale nie pisać…..
Przyjąłem do wiadomości. Czego Ci w tym (te diagramy) brakuje do napisania tego kawałka oprogramowania? Ale rozumiem, że UML nie jest Ci obcy? Bo jeśli tak to faktycznie marnujemy bity…
Oj Jarek P… przecież jak już się zostaje Architektem to nie po to, żeby dziubdziać w kodzie, nie? 😀 😀 😀
Oczywiście jest to pure evil, że takie rzeczy się wyrabia ale natura ludzka tak już nami kieruje, że często wpadamy w pułapkę „to nie moja działka”. Niestety prawda jest inna: moja, moja ci ona! bo jak nie to następne co jest „moje” to wina za to, że projekt poszedł w maliny.
Absolutnie nie polemizuję ze złożonością oprogramowania jako całości ani z tym, że dla inżyniera jest tam masa trudnej i fascynującej pracy. Jednak systemy dla biznesu to także wymagania funkcjonalne, te zaś są obsługiwane przez jedną tylko z wielu, warstwę systemu o nazwie „logika biznesowa”. Ona (obiekty biznesowe i ich logika) powinna być dana jako wymaganie, gotowy produkt. W życiu, poza kilkoma może wyjątkami, nie widziałem dobrego programisty, który byłby specem od zarządzania i marketingu. Dlatego uważam, że MVC/DDD to rozwiązanie tego problemu. Mogę wymagania, zamiast bełkotu prozą, oddać w postaci przetestowanej, gotowej do implementaci, warstwy Modelu Dziedziny. Wymagania poza funkcjonalne w rodzaju czas odpowiedzi, bezawaryjność, praca na wolnych łączach, poufność, 2000 jednoczesnych użytkowników itp. to problemy dla programisty inżyniera… czyż nie?
Zeby nie marnowac bit’ow, polecam http://www.infoq.com/presentations/Deliberate-Discovery oraz http://www.slideshare.net/ThoughtWorks/neal-ford-emergent-design-and-evolutionary-architecture.
Co do większości projektów IT na rynku, zastosuję prosta regułe, 20% projektów na rynku to 80% procent wydatków na projekty IT. Pozostałe 80% projektów świetnie sobie poradzi bez tych ról, lub wypełni ta pustkę w inny, bardziej optymalny i kreatywny sposob.
Bardzo ciekawe prezentacje, są o czymś czym się nie zajmuje analityk biznesowy: nie ma tam słowa o tym jak zebrać i udokumentować logikę biznesową… może dlatego, że to jednak nie jest praca dla inżynierów programistów…to powinni dostać, albo jak mawiają niektórzy: ktoś powinien postawić zadanie programistom? Robi to klient, jednak ten potrafi pisać „po swojemu” dlatego ktoś powinien postawić zadanie programistom w „ich języku”: Analityk potrafiący zapisać te biznesowe wymagania tak, by był to zapis jednoznaczny i testowany: np. UML.
„by był to zapis jednoznaczny i testowany: np. UML.”
w jaki sposób przetestować model zapisany np. w UML ?
Tu jest to opisane:
http://it-consulting.pl/autoinstalator/wordpress/index.php/2011/05/21/wymagania-opisuja-to-co-system-ma-robic/
Aby tu nie brnąć, zapraszam na moje „zbiorcze wyjaśnienia” tu: http://it-consulting.pl/autoinstalator/wordpress/index.php/2011/05/21/wymagania-opisuja-to-co-system-ma-robic/