Pojawiła się oczekiwana wersja 11 pakietu CASE firmy Visual-Paradigm. Przede wszystkim rozwój produktu idzie w kilku głównych kierunkach: wsparcie dla wizualnego projektowania aplikacji (mock-up’y, kolejne ułatwienia w tworzeniu i integrowaniu modeli UML), stały rozwój wsparcia dla architektury korporacyjnej (to narzędzie pozwala tworzyć modele powiązane ze sobą, pozwala na prowadzenie analiz wpływu i wielu innych, wspiera także notację ArchiMate) oraz na prawdę bardzo silne wsparcie dla pracy grupowej. Co dzisiaj ogłasza producent:
Visual Paradigm International Limited today [16.12.2013] announced the release of Agilian (AG) 11.0, a Visual Modeling tool for Agile Modeler. In this release, Agilian introduces 49 new features and enhance usability of various types of diagrams.
What’s new in Agilian 11.0?
Supported ArchiMate Viewpoint
Use Case List
Actor List
Requirement List
Use Case Notes
Web wireframe
Android phone wireframe
Android tablet wireframe
iPhone app wireframe
iPad app wireframe
Desktop application wireframe
Plan and manage development activity with Tasifier
Nowe narzędzie wspierające proces analizy wymagań:
W moich oczach to narzędzie wysuwa się na czoło w tym segmencie. Koszt vs. użyteczność zostawia w tyle zarówno drogie produkty IBM (Rational Rose) jak i mało przydatne (nie trzymanie standardów) SPARX Enterprise Architect. Do tego produkt VP jest w ok. 80% spolszczony (prace trwają). projekty Rational Rose mogą być importowane, projekty SPARX EA tylko w części (EA nie respektuje w pełni standardu UML/XMI).
Oprogramowanie Visual-Paradigm to także wsparcie dla generowania kodu, inżynierii wstecznej (dokumentowanie kodu istniejącego), projektowania baz danych i mapowania ORM, całego procesu analizy i reinżynierii procesów biznesowych wraz z testowaniem modeli i symulacjami procesów.
BIO: Od roku 1991 roku, nieprzerwanie, realizuję projekty z zakresu analiz i projektowania systemów, dla urzędów, firm i organizacji. Od 1998 roku prowadzę także samodzielne studia i prace badawcze z obszaru analizy systemowej i modelowania (modele jako przedmiot badań: ORCID). Od 2005 roku, jako nieetatowy wykładowca akademicki, prowadzę wykłady i laboratoria (ontologie i modelowanie systemów informacyjnych, aktualnie w Wyższej Szkole Informatyki Stosowanej i Zarządzania pod auspicjami Polskiej Akademii Nauk w Warszawie. Oświadczenia: moje badania i publikacje nie mają finansowania z zewnątrz, jako ich autor deklaruję brak konfliktu interesów.
Od lat, podczas audytów i szkoleń, spotykam się z „dziwnymi diagramami” tworzonymi w celu… no właśnie. Ale po kolei…
Najpierw przypomnę, bardzo tu pomocne, pojęcie architektury korporacyjnej, która – śledząc literaturę przedmiotu – jest modelem (dokumentacją) wiążącym model biznesowy organizacji z jej zasobami informacyjnymi i infrastrukturą służącą do zarządzania informacją. Posiadanie takiego modelu ma sens nie tylko po to by, wiedzieć „co mamy” czy opisać wymagania na to czego „jeszcze nie nie mamy a potrzebujemy mieć”. Model taki pozwala analizować posiadane zasoby, ale także ocenić ich wpływ na działanie organizacji, wzajemny wpływ, przewidzieć reakcje systemu na nowe bodźce (lub awarie).
W artykule opisującym proces modelowania „od biznesu do projektu logiki systemu” opisałem przechodzenie od modelu procesów biznesowych, przez przypadki użycia do modelu dziedziny systemu (lub komponentów w przypadku złożonych systemów jak w artykule Przypadki użycia i granice systemu). Nie będę więc w tym miejscu powtarzał tych treści, ale pokaże przykłady.
Opisywane tu podejście wymaga przyjęcia standardowych definicji pojęć proces biznesowy i przypadek użycia oraz usługa systemu (tak zwana pragmatyka modeli, powinna być zawsze dołączona do dokumentów analizy). Dwie ostatnie są w UML praktycznie tożsame z procesem biznesowym (A use case is the specification of a set of actions performed by a system, which yields an observable result that is, typically, of value for one or more actors or other stakeholders of the system – czynność lub ich seria dająca jako efekt produkt mający wartość dla aktora, źr. UML 2.4.1. 16.3.6 UseCase). W efekcie zestaw diagramów opisujących organizację z jej systemem informacyjnym, tworzą Architekturę jak poniżej:
Usługa systemu (jego przypadek użycia) może wspierać jeden lub wiele różnych procesów biznesowych, jednak na poziomie procesów elementarnych (tych których już nie dekomponujemy), jeden proces „elementarny” może być wspierany wyłącznie jednym przypadkiem użycia (bo na tym poziomie powstaje jeden produkt). Przykładem jednej usługi wykorzystywanej w kilku procesach może być przypadek zwany CRUD (Create, Retrieve, Update, Delete, czyli Utwórz, Przywołaj, Aktualizuj, Usuń), taka usługa (przypadek użycia typu CRUD) może wspierać procesy: tworzenia, aktualizacji (w tym zmiany statusu) i usuwania dokumentów.
Usługi są realizowane przez określone komponenty (aplikacje), które są instalowane na konkretnych platformach. Z uwagi na to, że komponenty mogą współpracować (wymieniać między sobą dane) mają udokumentowane interfejsy.
Jak pokazać, które komponenty są wykorzystywane w określonych procesach?
Teraz przyszedł moment, w którym pojawiają się często niestandardowe diagramy „wymyślane” w celu „jakiegoś sposobu” na pokazanie związków pomiędzy biznesem (procesy biznesowe) a komponentami oprogramowania. Poważną wadą tych pomysłów jest przede wszystkim to, że są niestandardowe. Po drugie wymagają „ręcznego” wytworzenia, są pracochłonne, mnożą się dodatkowe strony dokumentacji, podnoszą jej złożoność i pogarszają zrozumiałość całości.
Jak sobie z tym poradzić? Tu nieocenione są właśnie dobre pakiety oprogramowania CASE. Poniżej prosty przykład:
Model procesu biznesowego (proces składa się z elementarnych procesów, każdy ma produkt):
Model przypadków użycia (zachowano nazwy z modelu procesów dla orientacji):
Przykładowa realizacja (scenariusz) wybranego przypadku użycia (na poziomie komponentów, tu celem jest specyfikowanie interfejsu czyli wywołań jednego komponentu przez drugi):
Jak teraz sprawdzić i pokazać związki pomiędzy procesami, przypadkami użycia aplikacji (usługami systemu) i komponentami (aplikacjami)? Zamiast tworzyć nowe sztuczne i niestandardowe diagramy znacznie lepiej jest pokazać to w formie macierzy nie psując np. modeli procesów nieformalnymi zapisami o systemach:
Gdyby potrzebne były bardziej wyrafinowane analizy zależności, możemy stworzyć, zamiast dwuwymiarowej macierzy, taki diagram:
I teraz sedno czyli co nam daje dobre narzędzie CASE? otóż powyższe macierze (takie i każdą inną) oraz model analizy wpływu, są generowane i aktualizowane automatycznie. Wystarczy opracować standardowe modele w BPMN i UML jak powyżej, wskazać związki pomiędzy elementami jako ich parametry (nie trzeba do tego celu tworzyć sztucznych diagramów) i skorzystać z możliwości automatyczne dokumentowania tych związków.
Uzupełnieniem powyższych modeli może być mapowanie dokumentów z diagramów procesów biznesowych na klasy (agregaty) reprezentujące je w oprogramowaniu (komponenty). Tu niestety nie widzę sensu mapowania na „dane w bazie danych” bo celem jest dokumentowanie miejsca przechowywania informacji (komponent) a nie implementacji (baza RDBMS, która jest jedną z wielu możliwych implementacji utrwalania).
Ważne jest by narzędzie bardzo dobrze wspierało specyfikacje notacji oraz metody weryfikowania spójności modeli takie jak śladowanie, podległość modeli, zależności „parent-child” i zagnieżdżanie.
BIO: Od roku 1991 roku, nieprzerwanie, realizuję projekty z zakresu analiz i projektowania systemów, dla urzędów, firm i organizacji. Od 1998 roku prowadzę także samodzielne studia i prace badawcze z obszaru analizy systemowej i modelowania (modele jako przedmiot badań: ORCID). Od 2005 roku, jako nieetatowy wykładowca akademicki, prowadzę wykłady i laboratoria (ontologie i modelowanie systemów informacyjnych, aktualnie w Wyższej Szkole Informatyki Stosowanej i Zarządzania pod auspicjami Polskiej Akademii Nauk w Warszawie. Oświadczenia: moje badania i publikacje nie mają finansowania z zewnątrz, jako ich autor deklaruję brak konfliktu interesów.
„Rozumiem, że lubi Pan pracować w photoshopie, ale uważamy że ten program jest za mało uniwersalny. Proszę pracować w MS Paint, będzie nam łatwiej edytować Pana pliki i wstawiać poprawki.” (za pomocą WYCIĘTE Z MEJLI (AD ABSURDUM): Rozumiem).
Dokładnie miesiąc temu u jednego z klientów usłyszałem analogiczny zarzut, który można by parafrazować:
„Rozumiem, że lubi Pan pracować w „modelerze” (mój CASE VP-Agilian), ale uważamy że ten program jest za mało uniwersalny. Proszę pracować w MS PowerPoint, będzie nam łatwiej edytować Pana pliki i wstawiać poprawki.”
No i cały czar prysł… to była duża korporacja z własnym, dużym działem developmentu… narzekają na duże koszty procesu wytwórczego oprogramowania… Nazywam to „kulturą korporacyjną MSOffice”.
Na koniec delikatnie przypomnę, że powstająca grafika czy opracowanie tekstowe, to dzieło jego autora (Ustawa o prawach autorskich), i nie można zgłaszać uwag do cudzego dzieła modyfikując je… za to można być autorem własnych uwag :).
Na zakończenie: z tego powodu także nie używam oprogramowania Enterprise Architect firmy SPARX, jest niekompatybilny w 100% ze specyfikacjami OMG, jest siermiężny i pracochłonny. wymaga wielu darmowych lub płatnych plug-inów by sprawnie z niego korzystać.
BIO: Od roku 1991 roku, nieprzerwanie, realizuję projekty z zakresu analiz i projektowania systemów, dla urzędów, firm i organizacji. Od 1998 roku prowadzę także samodzielne studia i prace badawcze z obszaru analizy systemowej i modelowania (modele jako przedmiot badań: ORCID). Od 2005 roku, jako nieetatowy wykładowca akademicki, prowadzę wykłady i laboratoria (ontologie i modelowanie systemów informacyjnych, aktualnie w Wyższej Szkole Informatyki Stosowanej i Zarządzania pod auspicjami Polskiej Akademii Nauk w Warszawie. Oświadczenia: moje badania i publikacje nie mają finansowania z zewnątrz, jako ich autor deklaruję brak konfliktu interesów.
Prawdę mówiąc „zabraniam” przynoszenia komputerów na moje szkolenia, wymagam papieru i ołówka. Powody są dwa:
Narzędzia CASE pomagają tylko wtedy gdy diagramów jest wiele i model jest złożony, na szkoleniach takich modeli się nie robi.
Narzędzia, w szczególności niektóre, płatają figle i szkolenie np. z zakresu analizy biznesowej ewoluuje w stronę szkolenia z obsługi narzędzia.… do czego nie dopuszczam :).
Napisze tu kilka słów jednak o narzędziach, bo dobrze jest jednak znać dobre i złe cechy swojego narzędzia.
Spotykam się nie raz z bardzo popularnym pakietem CASE (SPARX Enteprise Architect) na szkoleniach (ma go wielu kursantów i jest używany w wielu firmach) i u niektórych klientów. Pakiet ten jednak nie raz sprawiał pewne kłopoty. Nie znam zbyt dobrze tego narzędzia w obecnej wersji, wiem, że model przechowywany jest w relacyjnej bazie danych, ale niedawno trafiłem na coś, co wyjaśnia mi pewne „przygody z pakietem Enterprise Architect”. Przytaczam cały akapit z tego opisu, bo to w zasadzie jest to lista wad tego pakietu. Problemy z projektem, a konkretnie z jego integralnością mogą pojawić się…
…w następujących sytuacjach:
Z modelu korzysta wielu użytkowników, których połączenia sieciowe mogą być przerywane. Wystarczy, że jest prawdopodobieństwo, że ktoś bez zamykania projektu wypnie z sieci laptop lub zostanie zerwane połączenie VPN.
Model jest skonfigurowany z systemem kontroli wersji. W takim przypadku mamy do czynienia z wieloma operacji importu plików XMI. Zawartość takich plików może pochodzić z innego modelu a połączenie takich danych może skutkować utratą integralności na przykład w zakresie użytych stereotypów, czy relacji do elementów spoza pliku XMI.
Model bywa aktualizowany w oparciu o pliki XMI przy użyciu funkcji Import Package from XMI lub Batch XMI Import. Sytuacja jest analogiczna do powyższej.
Model jest zintegrowany z innymi aplikacjami/systemami, takimi jak HP Quality Center, Mantis itp.
Model jest wykorzystywany przez jednego użytkownika w postaci lokalnego pliku EAP, jednakże podczas wykonywania jakiejś operacji program EA lub system operacyjny uległ awarii.
Z powyższego opisu wynika, że z funkcji tej (kontrola integralności projektu) należy korzystać przede wszystkim w przypadku, gdy mamy do czynienia ze współdzielonym modelem, jak i w przypadku lokalnego projektu opracowywanego przez jedną osobę. Może tylko z tą różnicą, że prawdopodobieństwo wystąpienia niespójności jest wyższe w tym pierwszym przypadku.
Wszystkie powyższe sytuacje to efekt tego, że EA do pracy w grupie (samodzielnie także) musi pracować na relacyjnej bazie, na której praca ta odbywa się siła rzeczy on-line. Po drugie nie ma on narzędzia kontroli spójności projektu (danych w tej bazie) „w locie” więc można tworzyć „zły model” nie wiedząc o tym…
Dlaczego o tym pisze? Używam pakietu Visual-Paradigm (więcej o nim na końcu). Pakiet ten nie ma żadnej z tych wad, pracuje zawsze off-line na pliku XML i zniszczenie projektu jest mało prawdopodobne. Jeżeli zdarza się utrata integralności to raczej w sytuacji gdy użytkownik usuwa wybrane elementy modelu i zignoruje ostrzeżenie o powiązaniach tych elementów z innymi usuwają je ręcznie bez wbudowanej kontroli. Pakiet VP ma możliwość pracy z tak zwaną kontrolą składni „w locie” więc w zasadzie nie możliwe jest tworzenie „złego” modelu.
W przypadku pracy grupowej (z serwerem dedykowanym VP Teamwork Server lub Subversion, Perforce, ClearCase czy CVS.) uszkodzenie projektu także jest niemalże niemożliwe, bo tu także praca odbywa się off-line, a update projektu jest nie tylko transakcją, ale jak tylko zostaną wykryte konflikty pomiędzy aktualnym projektem na serwerze a projektem ładowanym na serwer (robi to serwer lub klient VP z dokładnością do obiektu na modelach) pokazywana jest lista konfliktów (nierozstrzygalnych automatycznie) z prośbą o reakcję.
Tak więc jeżeli ktoś z Państwa nie dokonał wyboru narzędzia CASE a planuje taki, warto przetestować dostępne na rynku produkty w warunkach nieco „cięższych” niż kilka diagramów… Poniżej kluczowe korzyści ze stosowania narzędzi CASE:
Make a pie. Estimate the % time you are spending on these five requirements activities: planning, eliciting, analyzing, documenting and reviewing. Does it look like this?
BIO: Od roku 1991 roku, nieprzerwanie, realizuję projekty z zakresu analiz i projektowania systemów, dla urzędów, firm i organizacji. Od 1998 roku prowadzę także samodzielne studia i prace badawcze z obszaru analizy systemowej i modelowania (modele jako przedmiot badań: ORCID). Od 2005 roku, jako nieetatowy wykładowca akademicki, prowadzę wykłady i laboratoria (ontologie i modelowanie systemów informacyjnych, aktualnie w Wyższej Szkole Informatyki Stosowanej i Zarządzania pod auspicjami Polskiej Akademii Nauk w Warszawie. Oświadczenia: moje badania i publikacje nie mają finansowania z zewnątrz, jako ich autor deklaruję brak konfliktu interesów.
Ostatni artykuł o procesie analizy i projektowania kończył się tak:
Po wykonaniu powyższego, otrzymamy kompletny model aplikacji w notacji UML. Będzie to właśnie model PIM. Wszelkie niejasności powinny zostać wyjaśnione. Pozostaje realizacja, model PSM, czyli opakowanie projektu ?technikaliami? (w tym realizacja wymagań pozafunkcjonalych) czyli tym co dają nam np. frameworki MVC i podobne. Oczywiście nie jest to ?trywialny problem?, ale w takim projekcie developer rozwiązuje problemy jakości systemu a nie logiki biznesowej systemu (podobnie jak inżynier budowlany, który ma postawić mocny i bezpieczny dom, bo jego funkcjonalność to problem mieszkańca i zadanie projektanta architekta). (UML Process czyli od biznesu do projektu logiki systemu).
Często dostaję pytania o ogólną, poglądową mapę takiego projektu by łatwo było ocenić czym jest opisywane śladowanie, jaka jest kolejność pracy i jakie modele powstają. Podjąłem próbę pokazania tego:
Kolejność pracy (kliknij by powiększyć):
Określenie celu biznesowego, powstaje dokument wyjaśniający jakie „biznesowe” korzyści chcemy (organizacja) osiągnąć, nie powinno być celem samym w sobie kupienie czegoś (np. systemu ERP), korzyści te powinny być wyrażone ostatecznie w pieniądzu (potrzebne do analizy rentowności projektu).
Kolejny etap to opracowanie modelu motywacji biznesowej, będzie to materiał do wypracowania Wymagań Biznesowych. Model ten zawiera przełożenie celu biznesowego na wymagane działania: taktykę i strategię jego osiągnięcia: raz jest to reorganizacja a raz nowy system ERP. Tu pojawiają się takie elementy jak analiza SWOT czy oddziaływania, analiza wykonywalności i oceny wpływu otoczenia na projekt. Powstają Wymagania Biznesowe (źródłem są strategia i taktyka osiągania celu biznesowego).
Następnie kolej na opracowanie modelu procesów biznesowych dla całej organizacji na poziomie opisującym kluczowe produkty (dokumenty i fakty). Zaczyna powstawać słownik pojęć i reguł biznesowych.
Kolejny etap to dekomponowanie procesów biznesowych „odpowiedzialnych” (powiązanych) za realizacje Wymagań Biznesowych, te procesy dekomponujemy (uszczegółowione modele) do poziomu czynności tworzących i zmieniających dokumenty i fakty. Dodajemy kolejne zidentyfikowane pojęcia i reguły. Na tym etapie możliwa jest optymalizacja procesów.
Jeżeli optymalizacja realizuje wymagania biznesowe projekt się kończy. Jeżeli okazuje się, że wymagania biznesowe wymagają np. technologii IT, projekt ma dalszy ciąg.
Określenie wymagań na oprogramowanie to wskazanie tych czynności w procesach, których wsparcie tą technologią pomoże zrealizować wymagania biznesowe. Po analizie powstaje na jej podstawie lista oczekiwanych usług oprogramowania, są to tak zwane przypadki użycia systemu. Każdy przypadek użycia ma określony stan początkowy, końcowy (ewentualnie dokument jaki ma powstać), cel biznesowy (uzasadnienie) oraz aktora czyli wskazanie użytkownika (a konkretnie roli jaką pełni w organizacji). Powstaje specyfikacja wymagań funkcjonalnych i poza-funkcjonalnych (jakościowych, np. takich jak wydajność czy niezawodność). Na tym etapie dysponujemy specyfikacją pozwalającą na szukanie gotowego oprogramowania na rynku oferującego tak opisane funkcjonalności. Elementem specyfikacji wymagań jest słownik pojęć i reguł biznesowych. Można dołączyć modele procesów.
Jeżeli nie znajdujemy produktu spełniającego wszystkie wymagania w 100%, decydujemy, które brakujące wymagania funkcjonalne jesteśmy gotowi wytworzyć specjalnie dla nas. Wymaga to utworzenia dla każdej takiej funkcjonalności (przypadku użycia, PU) specyfikacji w postaci opisu jej realizacji. Jest to projekt (dokument) zawierający tak zwany model dziedziny systemu czyli obiekty biznesowe i logikę ich współdziałania. Dla każdego PU powstaje diagram opisujący jak obiekty modelu dziedziny „realizują” (współdziałanie) każdy przypadek użycia (diagramy sekwencji).
Projekt ma trzy kluczowe etapy: audyt organizacji czyli jej poznanie i opracowanie modelu działania. Kolejny to Specyfikowanie wymagań na oprogramowanie. Ostatni etap analizy i projektowania to opracowanie modelu logiki jaką ma realizować zamawiane oprogramowanie. Cała ta dokumentacja zawiera know-how organizacji warty ochrony.
Na diagramie pokazano tak zwane „śladowanie” czyli kolejne wywodzenie elementów modeli z poprzedzających je ogólniejszych etapów analizy. Taka dokumentacja pozwala uniknąć kosztownego odkrywania potrzebnych funkcjonalności podczas dostarczania kolejnych wersji oprogramowania i przeprojektowywania go. Specyfikacja logiki systemu pozwala dokładnie sprecyzować jakie oprogramowanie jest zamawiane (co ma ono realizować i jak). Całość to opis know-how, który nadal zostaje przy zamawiającym (jest posiadaczem praw do tej dokumentacji bo wykonał ja sam lub zlecił niezależnemu analitykowi a nie dostawcy oprogramowania).
Skąd się biorą problemy
Przytłaczająca większość projektów to rozpoczęcie pracy od próby zebrania wymagam funkcjonalnych z pominięciem całej analizy biznesowej. Jedynym więc ich źródłem są przyszli użytkownicy, Ci jednak po pierwsze nie mają wiedzy o kontekście zaś ich cele są inne niż sponsora projektu. Nie mamy żadnego narzędzia pozwalającego sprawdzić zasadność każdego z tak zebranych wymagań ani tego czy są „spójne i kompletne”. W efekcie niespójności i brakujące wymagania odkrywany dopiero w trakcie projektu.
Metody zwane zwinnymi idą jeszcze dalej: prace deweloperskie są rozpoczynane są zanim powstanie kompletna specyfikacja, pojawiające się wymagania są natychmiast, z pominięciem ich modelowania i weryfikacji pomysłu, implementowane (kod to pierwszy model i weryfikacja). Ryzyko, że nowe, odkrywane w trakcie tego procesu, wymagania i metody ich implementacji będą niespójne czy wręcz sprzeczne jest ogromne co pokazuje praktyka: metody zwinne dają produkty nie raz po bardzo wielu iteracjach i najczęściej są kontraktowane umowami „czas i materiał”, bo w zasadzie inaczej się tym wypadku nie da. Deklarowanie terminów i budżetu wymagało by ogromnych narzutów na niewiedzę w momencie rozpoczynania pracy (co jest także powszechna praktyką).
Na zakończenie
Opisany proces jest zgodny z zaleceniami OMG.org (http://www.omg.org/mda). Audyt to etap CIM (standardowo [[notacja BPMN]], system pojęć i [[notacja BMM]], hierarchia struktury organizacyjnej, słownik reguł i pojęć) a projektowanie przypadków użyci i modelu dziedziny to etap PIM (Platform Independent Model, [[notacja UML]]).
Wykonanie takiej analizy jest pracochłonne i wymaga dużego doświadczenia, umiejętności analizy procesów biznesowych, projektowania obiektowego i dobrego narzędzia CASE, jednak modele te pozwalają także przeprowadzić analizy wpływu (zależności pomiędzy procesami, skutki i podatność na awarie oprogramowania itp.) oraz zredukować do minimum prawdopodobieństwo przekroczenia terminu i kosztów (statystyki wskazują na średnie przekroczenie kosztów o 60% i terminów o 200% projektów z niskiej jakości specyfikacji wymagań).
Praktyka autora wskazuje, że warto taką analizę przeprowadzić dla projektów, których budżet przekracza 50 – 70 tys, zł i większych, jej koszt jest zawsze znacznie niższy niż ryzykowane 60% budżetu. Paradoksalnie, w tych większych projektach, zbieranie wymagań i zarządzanie nimi metodami warsztatów i ankiet wymaga zaangażowania wielu pracowników po stronie zarówno klienta jak i dostawcy (np. [[sesje JAD]]), z reguły jest to większy koszt niż jeden analityk z opisanymi kompetencjami i narzędziami pracy, a otrzymany produkt – specyfikacja wymagań – niższej jakości (problemy spójności i kompletności).
BIO: Od roku 1991 roku, nieprzerwanie, realizuję projekty z zakresu analiz i projektowania systemów, dla urzędów, firm i organizacji. Od 1998 roku prowadzę także samodzielne studia i prace badawcze z obszaru analizy systemowej i modelowania (modele jako przedmiot badań: ORCID). Od 2005 roku, jako nieetatowy wykładowca akademicki, prowadzę wykłady i laboratoria (ontologie i modelowanie systemów informacyjnych, aktualnie w Wyższej Szkole Informatyki Stosowanej i Zarządzania pod auspicjami Polskiej Akademii Nauk w Warszawie. Oświadczenia: moje badania i publikacje nie mają finansowania z zewnątrz, jako ich autor deklaruję brak konfliktu interesów.
Kolejna godna polecenia książka na rynku. Nie miałem czasu by wcześniej ją opisać ale w końcu udało się. Ale od początku, wrócimy do niej.
To co najczęściej wzbudza brak zaufania to teza, że można przeprowadzić analizę i projektowanie oprogramowania „na papierze”. Programiści w większości uważają, że to nie możliwe (rok temu na stronach tego bloga burzliwa dyskusja z jednym z nich…). W większości przypadków podczas spotkań (konferencje, projekty itp.) z zespołami programistów słyszę: „czytamy wymagania, kodujemy od razu i tworzymy kolejne wersje aplikacji; inaczej się nie da”. W przypadku szkoleń, ostatniego dnia warsztatów najczęściej słyszę: „ooo, w ciągu jednego dnia [teraz] powstał kompletny projekt dziedziny systemu [chodziło o komponent], przetestowany i oczyszczony z wątpliwości, braku logiki i niespójności, do tego łatwy w dalszym rozbudowywaniu; to co zrobiliśmy teraz na diagramach UML w ciągu dnia, jako zespół tradycyjną metodą robilibyśmy co najmniej tydzień, biorąc pod uwagę kodowanie każdego pomysłu by go dać użytkownikowi do testów”. W zasadzie taki proces analizy i projektowania jest znany od lat jako Model Driven Architecture (MDA):
W czym problem? Nauczyć się pracować na modelach (abstrakcje systemu) a nie od razu na kodzie (a raczej poprzedzić kodowanie analizą i projektowaniem), nauczyć się wzorców projektowych i przede wszystkim obiektowego myślenia (paradygmatu) czyli analizy i projektowania. Wykonanie – implementacja na końcu a nie na początku (podobnie jak baza danych: w metodach obiektowych projektujemy utrwalanie na końcu!). Po drugie, niestety, nie raz słyszałem o dostawców: „nie mamy interesu w tym by projekt trwał krótko”, to jednak tylko argument za tym by nie zlecać im projektowania a tylko realizację.
MDA to trzy kluczowe etapy: CIM, PIM i PSM (szczegółowo opisałem w artykule o analizie). Interesuje mnie tu etap CIM (Computation Independent Model) i PIM (Platform Independent Model). Pierwszy to analiza biznesowa, nie ma ona nic wspólnego z oprogramowaniem, jej celem jest zrozumienie i udokumentowanie tego co robią przyszli użytkownicy systemu oraz wskazanie zakresu projektu dostarczenia oprogramowania. Drugi to PIM czyli opracowanie modelu logiki systemu bez względu na to w jakiej technologii powstanie, tu milczącym założeniem jest, że będzie to technologia obiektowa jednak język programowania może być dowolny.
Dużą zaletą tego podejścia jest to, że opracowanie modelu PIM jako Opisu Przedmiotu Zamówienia (OPZ) jest zgodne z PZP (Prawo Zamówień Publicznych) bo nie determinuje implementacji ale dokładnie opisuje oczekiwania. Uważam, że jest to najlepszy sposób tworzenia OPZ, bo nie pozostawia dowolności w kwestii funkcjonalności rozwiązania. Jaki mamy tu problem? Należy oddzielić projektowanie od realizacji czyli mamy dwa etapy projektu zamiast jednego, dwóch wykonawców (analiza i projektowanie oraz realizacja). Wady? Nie, korzyści bo wykonawca i tak musi jakiś projekt opracować, po drugie wycena na bazie projektu jest daleko mniej ryzykowna niż „wycena na bazie koncepcji”, zresztą skutki wszyscy obserwujemy na rynku. Ale wracamy do tematu :).
Proces od analizy do projektu
Dwa pierwsze (CIM i PIM) to pierwsze etapy procesu powstawania oprogramowania: Analiza Biznesowa i jej produkt oraz projektowanie rozwiązania i jego produkt. Między nimi ma miejsce określenie zakresu, którego produktem jest model przypadków użycia (od 2015 roku w UML 2.5.x ten diagram jest modelem uzupełniającym)
Analiza biznesowa
Zgodnie z zaleceniami opracowujemy model CIM czyli tworzymy model tego „jak działa biznes”. Produktem tego etapu są modele procesów biznesowych (raczej [[BPMN]] niż [[UML]]). Muszą się one jednak cechować ustalonym poziomem abstrakcji (nie powinny być zbyt szczegółowe) i muszą uwzględniać rozdział kompetencji pracowników (ich nie komputeryzujemy) od ich specyficznych dla danej organizacji i procesu (te będą wspierane przez nowe oprogramowanie). Dobrą praktyką jest poprzedzanie tego etapu (uzupełnienie go) o analizę i model architektury korporacyjnej. To jest ostatni gwizdek na wprowadzanie ewentualnych ulepszeń zarządzania (reinżynieria procesów) w organizacji. Kolejny etap to
Opracowanie modelu przypadków użycia
Przypadki użycia, usługi systemu dla użytkowników, to celowe interakcje użytkownika z systemem. Ich cechą powinna być kompletność, bo przypadek użycia to realizacja konkretnego celu biznesowego przez użytkownika. Poprawnie opracowany taki model pozwala mapować czynności z modelu procesów wprost na przypadki użycia (ale nie koniecznie jeden do jednego, przypadków użycia może być mniej, bo ta sama usługa systemu może posłużyć do realizacji kilku celów biznesowych, np. utworzenia danych jak i ich podglądu czy korekty, przykładem mogą być tak zwane [[CRUD]]«y) (kliknij tu by zobaczyć to na przykładzie narzędzia jakiego używam).
Każda czynność kandydująca na przypadek użycia powinna być opisana scenariuszem jej realizacji opisującym jak planujemy tę usługę zrealizować. Jest to tak zwany dialog użytkownik-system. Model przypadków użycia to także definicja zakresu projektu programistycznego (robimy to i tylko to).
Opracowanie modelu dziedziny
Specyfikacja usług systemu (przypadki użycia) to tak zwane wymagania funkcjonalne. Jest to stanowczo za mało by cokolwiek (w szczególności oprogramowanie) mogło powstać. Problem w tym, że samo stwierdzenie „system ma wciągać śmieci” nijak się nie ma do konstrukcji urządzenia jakim jest odkurzacz. Wymaganie pozafunkcjonalne, że „ma ich wciągać co najmniej 90%” także nic nie mówi o tym co na prawdę ma zostać wytworzone. Brakuje PROJEKTU.
Takim projektem jest model dziedziny, jednak nie jest to diagram klas na którym pokażemy, że np. istnieje związek logiczny brudnego dywanu z odkurzaczem! bo to jest tylko model pojęciowy (słownik pojęć). Model dziedziny systemu to model dziedzinowej logiki jaką należy odwzorować w oprogramowaniu. Owszem, jest to także Diagram klas UML, ale zupełnie inny niż tak zwany model konceptualny, który po prostu jest tylko słownikiem (i często jest mylony z modelem danych!).
Model dziedziny systemu to sedno analizy obiektowej. To model całej logiki biznesowej aplikacji: klasy, ich operacje i atrybuty. Nie powinien to być na pewno tak zwany [[anemiczny model dziedziny]] a niestety takie właśnie są one w większości projektów jakie widuję.
Na tym etapie, modelowanie dziedziny systemu, powstają „suche” klasy, bez metod i atrybutów (tak, bez atrybutów!). W projektach złożonych systemów, powstanie modelu dziedzinowego powinno być poprzedzone powstaniem modelu komponentów (także stosowny diagram UML), który jest pośrednią warstwą abstrakcji w takich projektach. W takim przypadku początkowo operujemy praktycznie tylko na klasach abstrakcyjnych i ich interfejsach (są to interfejsy tych komponentów).
Projektowanie realizacji czyli testowanie modelu dziedziny
Mając model dziedziny, czyli listę specjalizowanych „wykonawców” konkretnych prac, możemy przystąpić do testów scenariuszy przypadków użycia. Takim testem jest próba zrealizowania scenariusza przypadku użycia z pomocą obiektów modelu dziedziny. Na tym etapie powstaje diagram sekwencji (lub sterowania interakcją, przepływu interakcji) dla każdego przypadku użycia. Dobrą praktyką jest stosowanie tu diagramów przepływu interakcji. Służą one do modelowanie nietrywialnych przypadków użycia, przepływu scenariuszy alternatywnych, ekranów itp.
W trakcie tworzenia diagramu sekwencji projektowane są operacje klas (metody to ich realizacje). Diagram sekwencji opisuje dialog pomiędzy obiektami prowadzący do zrealizowania zadania, jakim jest cel przypadku użycia (jego stan końcowy). Dialog taki to nic innego jak wywołania operacji obiektów przez inne obiekty (lub własnych). Po opracowaniu diagramu sekwencji obiekty, które brały w niej udział „wzbogacą” się w projekcie o swoje operacje. Na tym etapie może się okazać, że pewne obiekty zmieniają swoje stany. Dla ich klas projektujemy diagramy maszyny stanowej. Jeżeli okaże się, że jakiś obiekt wykonuje nietrywialne zadania (obliczeniowe, złożony proces itp.), jego operację, która za to odpowiada, dokumentujemy z pomocą np. diagramu czynności – taki algorytm to Metoda danej Operacji. Za każdym razem sprawdzamy zgodność z oczekiwaniami użytkownika i uzupełniamy klasy o niezbędne atrybuty, w szczególności, jeżeli reprezentują one dokumenty czy formularze.
Projekt wykonany
Po wykonaniu powyższego, otrzymamy kompletny model aplikacji w notacji UML. Będzie to właśnie model PIM. Wszelkie niejasności powinny zostać wyjaśnione. Pozostaje realizacja, model PSM, czyli opakowanie projektu „technikaliami” (w tym realizacja wymagań pozafunkcjonalych) czyli tym co dają nam np. frameworki MVC i podobne. Oczywiście nie jest to „trywialny problem”, ale w takim projekcie developer rozwiązuje problemy jakości systemu a nie logiki biznesowej systemu (podobnie jak inżynier budowlany, który ma postawić mocny i bezpieczny dom, bo jego funkcjonalność to problem mieszkańca i zadanie projektanta architekta).
Poniżej produkty takiej analizy i projektowania w postaci diagramów (modeli), pierwszy to BPMN, pozostałe UML:
Larman w swojej książce opisuje niemalże identyczne podejście (tabela poniżej). Kluczową różnicą jest jednak źródło informacji pierwotnej. U Larman’a jest to model przypadków użycia i ich scenariusze. W porównaniu z modelem biznesowym, podlegającym testowaniu czy walidacji, całe ryzyko projektu spoczywa na jakości modelu przypadków użycia. Jeżeli powstały one jako efekt np. burzy mózgów, ankietowania pracowników zamawiającego czy tak zwanych sesji JAD ([[Joint Application Development]]), jest bardzo prawdopodobne, że całe ryzyko złej jakości takiego modelu (a jest ono bardzo duże jak pokazuje praktyka) zostanie przeniesione na projekt.
To jest właśnie problem nazywany „użytkownik nie wie czego chce”. Po to się robi analizy biznesowe by w końcu wiedział. Nie zmienia to faktu, że książkę Larman’a gorąco polecam każdemu projektantowi i programiście z ambicjami na metody obiektowe i wzorce projektowe.
Larman’s UML Process
Use Cases
Define user interaction with the system.
Underline nouns to identify concepts in the problem domain.
Conceptual Model
Use the underlined nouns from the use cases to create the concepts in the conceptual model.
Some of the nouns, if they identify simple data types, are used to create attributes of these concepts.
Create associations between the concepts.
System Sequence Diagram
Create system sequence diagrams for each use case scenario.
Each sequence event in the diagram corresponds to a user interaction with the system specified by the expanded use case.
System Contracts
Specify post-conditions for each system event in the system sequence diagrams.
Use the conceptual model to identify objects created, associations formed, and attributes modified.
Collaboration Diagram
Create a collaboration (or sequence) diagram for each system event in the system sequence diagrams.
Assign responsibilities to classes in the conceptual model to fulfill the post-conditions in the contracts.
Use associations from the conceptual model in conjunction with patterns (Expert, Creator) to assign responsibilities.
Class Diagram
Add methods and additional attributes which were discovered in the collaboration diagrams to the classes in the conceptual model.
Code
Create classes with their names, attributes and method signatures taken from the class diagram.
For each method on a class, use the collaboration diagrams to find the sequence of messages generated when the method is called and create at least one line of code for each message.
You can create several different views of the users» requirements. Each view provides a particular type of information. When you create these views, it is best to move frequently from one to another. You can start from any view.
BIO: Od roku 1991 roku, nieprzerwanie, realizuję projekty z zakresu analiz i projektowania systemów, dla urzędów, firm i organizacji. Od 1998 roku prowadzę także samodzielne studia i prace badawcze z obszaru analizy systemowej i modelowania (modele jako przedmiot badań: ORCID). Od 2005 roku, jako nieetatowy wykładowca akademicki, prowadzę wykłady i laboratoria (ontologie i modelowanie systemów informacyjnych, aktualnie w Wyższej Szkole Informatyki Stosowanej i Zarządzania pod auspicjami Polskiej Akademii Nauk w Warszawie. Oświadczenia: moje badania i publikacje nie mają finansowania z zewnątrz, jako ich autor deklaruję brak konfliktu interesów.
Strona używa plików cookie, aby zapewnić Ci wygodę przeglądania poprzez zapamiętywanie Twoich preferencji i powtarzających się wizyt. Klikając "Akceptuj wszystko", wyrażasz zgodę na użycie WSZYSTKICH plików cookie. Jednakże, możesz odwiedzić "Ustawienia plików cookie", aby zapewnić kontrolowaną zgodę.
Ta strona korzysta z plików cookie, aby poprawić wygodę podczas podczas przeglądania witryny. Pliko cookie, które są sklasyfikowane jako niezbędne, są przechowywane w przeglądarce, ponieważ są niezbędne do działania podstawowych funkcji witryny. Używamy również plików cookie stron trzecich, które pomagają nam analizować i zrozumieć, w jaki sposób korzystasz z tej witryny. Te pliki cookie będą przechowywane w przeglądarce tylko za Twoją zgodą. Możesz również zrezygnować z tych plików cookie. Ale rezygnacja z niektórych z tych plików cookie może mieć wpływ na wygodę przeglądania.
Niezbędne pliki cookie są absolutnie niezbędne do prawidłowego funkcjonowania witryny. Ta kategoria obejmuje tylko pliki cookie, które zapewniają podstawowe funkcje i zabezpieczenia strony. Te pliki cookie nie przechowują żadnych danych osobowych.
Wszelkie pliki cookie, które mogą nie być szczególnie potrzebne do działania witryny i są wykorzystywane w szczególności do gromadzenia danych osobowych użytkowników za pośrednictwem analiz, reklam i innych treści osadzonych, są określane jako niepotrzebne pliki cookie. Wymagane jest uzyskanie zgody użytkownika przed uruchomieniem tych plików cookie w witrynie.
Functional cookies help to perform certain functionalities like sharing the content of the website on social media platforms, collect feedbacks, and other third-party features.
Cookie
Duration
Description
__atuvc
1 year 1 month
AddThis sets this cookie to ensure that the updated count is seen when one shares a page and returns to it, before the share count cache is updated.
__atuvs
30 minutes
AddThis sets this cookie to ensure that the updated count is seen when one shares a page and returns to it, before the share count cache is updated.
bcookie
2 years
LinkedIn sets this cookie from LinkedIn share buttons and ad tags to recognize browser ID.
bscookie
2 years
LinkedIn sets this cookie to store performed actions on the website.
language
session
This cookie is used to store the language preference of the user.
lidc
1 day
LinkedIn sets the lidc cookie to facilitate data center selection.
na_id
1 year 24 days
The na_id is set by AddThis to enable sharing of links on social media platforms like Facebook and Twitter.
ouid
1 year 24 days
Associated with the AddThis widget, this cookie helps users to share content across various networking and sharing forums.
vc
1 year 24 days
The vc cookie is set by addthis.com on sites that allow sharing on social media.
Performance cookies are used to understand and analyze the key performance indexes of the website which helps in delivering a better user experience for the visitors.
Analytical cookies are used to understand how visitors interact with the website. These cookies help provide information on metrics the number of visitors, bounce rate, traffic source, etc.
Cookie
Duration
Description
at-rand
never
AddThis sets this cookie to track page visits, sources of traffic and share counts.
browser_id
5 years
This cookie is used for identifying the visitor browser on re-visit to the website.
CONSENT
2 years
YouTube sets this cookie via embedded youtube-videos and registers anonymous statistical data.
uid
1 year 24 days
This is a Google UserID cookie that tracks users across various website segments.
uvc
1 year 1 month
Set by addthis.com to determine the usage of addthis.com service.
Advertisement cookies are used to provide visitors with relevant ads and marketing campaigns. These cookies track visitors across websites and collect information to provide customized ads.
Cookie
Duration
Description
di2
1 year 24 days
AddThis sets this cookie on sites that allow sharing on social media. It is used to track user behaviour anonymously, to create usage trends that will improve relevance to their services and advertising.
loc
1 year 1 month
AddThis sets this geolocation cookie to help understand the location of users who share the information.
um
1 year 24 days
Set by AddThis for registering the user's sharing of content through social media.
VISITOR_INFO1_LIVE
5 months 27 days
A cookie set by YouTube to measure bandwidth that determines whether the user gets the new or old player interface.
YSC
session
YSC cookie is set by Youtube and is used to track the views of embedded videos on Youtube pages.
yt-remote-connected-devices
never
YouTube sets this cookie to store the video preferences of the user using embedded YouTube video.
yt-remote-device-id
never
YouTube sets this cookie to store the video preferences of the user using embedded YouTube video.
yt.innertube::nextId
never
This cookie, set by YouTube, registers a unique ID to store data on what videos from YouTube the user has seen.
yt.innertube::requests
never
This cookie, set by YouTube, registers a unique ID to store data on what videos from YouTube the user has seen.