o modelowaniu procesów i systemów 

W zeszłym tygodniu na jednym ze spotkań dotyczącego projektu o dość sporej wartości dostałem pytanie: Dlaczego do większych projektów do zarządzania wymaganiami rekomenduję IBM Rational RequisitePro? Oponent argumentował, że to drogi produkt a wejście w niego ?spycha? w dość kosztowną platformę Rational. Pozornie miał rację. Otóż w przypadku małych firm i niewielkich projektów wystarczą narzędzia konkrecyjne takiej jak choćby plug-in do jednego z najbardziej popularnych narzędzi CASE Enterprise Architecta o nazwie RaQuest. Niestety wydajność i możliwości wspomnianego tandemu (EA i RaQuest) są dość ograniczone (co wiem z praktyki).

Osobiście lubię stosować RequistePro zwłaszcza przy większych projektach gdyż pozwala on na :

• zbieranie wymagań w Word, szybką ich akwizycję w repozytorium opartym na bazie danych (wizardy, pełna integracja z Word),
• możliwość pracy grupowej dzięki składowaniu wymagań w bazie danych (IBM DB2, Oracle, MS SQL Server),
• nadawanie priorytetów i powiązań pomiędzy wymaganiami,
• nadawanie atrybutów takich jak priorytet, status, stopień trudności, odpowiedzialność,
• poprawienie wymagań w Word (nawet przez osoby, które nie mają zainstalowanego narzędzia), które wymusza  podczas synchronizacji wymagań (już na jednoste z dostępem do RequistePro) do obligatoryjnego wersjonowania zmian,
• filtrowanie, sortowanie i porządkowanie wymagań,
• pełną integrację z narzędziami do modelowania (np.: Rational Software Modeler, Rational Software Architect) bez konieczności przełączania się pomiędzy narzędziami,
• szybkie i wydajne raportowanie (czasem z potrzebne jest narzędzie do raportowania: Rational SODA),
• zarządzanie wymaganiami także za pomocą interfejsu WWW (łącznie z raportowaniem),
• integrację z ClearQuest co pozwala na jeszcze bardzie skuteczne wersjonowanie wymagań (także tych które powinny znaleźć się w kolejnej wersji produktu) – co jest istotne z punktu widzenia kierowników projektu
• integrację z narzędziami do testowania takimi jak Rational TestManager – co jest istotne z punktu widzenia testerów
• i chyba jedno z ważniejszych: wsparcie techniczne i merytoryczne IBM lub jej partnerów ? co pozwala zaoszczędzić czas

Oczywiście narzędzie może nie jest tanie, ale daje tyle wartości dodanej i pomaga uniknąć tylu trudności, że wydane pieniądze zwracają się wielokrotnie. Zdaje się, że wyszła mi przesłodzona laurka. Na szczęście dla mnie to prawdziwe cechy aplikacji (sprawdzone osobiście w projektach). Jeśli ktoś chciałby się przekonać w praktyce ?na własne oczy? proszę o kontakt ? mogę zrobić prezentację możliwości narzędzia lub szkolenie.

Model to nic innego jak reprezentacja pewnej rzeczy lub systemu charakteryzującego się miedzy innymi tym, że model:

• jest podobny do modelowanej rzeczy lub systemu gdyż różni się pod względem skali lub zachowania
• można go weryfikować, gdyż jego zachowanie odpowiada zachowaniu oryginału
• można przewidzieć złożoność oryginału, gdyż ma zachowaną jego strukturę na odpowiednim poziomie złożoności

W związku z powyższym warto budować modele oprogramowania, gdyż dzięki nim możemy poznać zachowanie i strukturę docelowego produktu.

Na jednym ze spotkań z klientem otrzymałem pytanie: Czy przypadki użycia są jedyną formą specyfikacji systemu? Moja odpowiedź była jasna: NIE. Przypadki użycia są niewątpliwie pożyteczne dla specyfikowania systemów, ale nie pozwalają w pełni opisać wymagań. Przypadki użycia stanowią swoiste agregaty dla wymagań, pozwalają dokonać pewnej dekompozycji wymagań na poszczególne funkcje systemu. Niestety ich rola jest ograniczona wskazania roli jakie podejmą aktorzy w systemie a przecież bardzo często  wymagania pochodzą od ludzi, którzy nie zbliżą się do granic systemu. Co więcej wymagania poza funkcjonalnością obejmują aspekty techniczne (np.: interfejsy). Z moich doświadczeń wynika, że często aby w pełni wyspecyfikować funkcjonalność systemu trzeba poznać proces biznesowy czyli zbudować model biznesowych przypadków użycia za pomocą techniki odmiennej, ale zgodnej z modelem przypadków użycia. Oznacza to, że poza modelem przypadków użycia powstają inne artefakty (dokumenty) przede wszystkim takie jak wspomniany model lub inna dokumentacja procesów biznesowych oraz obligatoryjnie specyfikacja wymagań funkcjonalnych i niefunkcjonalnych.

Kilka dni temu pisałem a statycznej analizie kodu (Dwa słowa o statycznej analizie kodu).  W praktyce taka analiza nie jest trudna o czym można się przekonać stosując bardziej zaawansowane narzędzia do projektowania i implementacji. Jednym z lepszszch narzędzi jest Rational Software Architect. 

Środowisko Rational Software Architect  zapewnia narzędzie od wykonywania statycznej analizy kodu aplikacji. Zwiększa ona jakość finalnego produktu poprzez znajdowanie oraz dokumentowanie wad oprogramowania. Udostępnia ono również ogólną ocenę jakości oprogramowania a co więcej umożliwia ono weryfikację założeń poczynionych na etapie projektowania i specyfikacji wymagań. Code Review Tool udostępnia także możliwość weryfikacji odpowiednich interakcji pomiędzy oprogramowaniem a komponentami systemowymi.

przeczytaj pozostałą część »

W dzisiejszym świecie podstawowym kryterium oceny tworzonego oprogramowania jest jego niezawodność. To nie jest odkrywczy pogląd.  Jedną z techniki wspierającą proces wytwarzania oprogramowania, która istotnie zwiększa jego jakość i niezawodność jest statyczna analiza kodu źródłowego. Poprzez analizę statyczna rozumiem analizę struktury kodu źródłowego lub kodu skompilowanego bez jego uruchomienia. Analiza statyczna może odbywać się na etapie budowania aplikacji, ponieważ jej wyniki są dostępne już podczas kompilacji kodu źródłowego. Istnieje kilka metod analizy statycznej kodu. Są to:

• Wykorzystanie narzędzi wyszukujących takie konstrukcje w kodzie źródłowym, które można uznać za potencjalnie niebezpieczne z subiektywnego punktu widzenia.
• Formalne metody, opierające się na matematycznej definicji zachowania programu. Formalne metody wymagają zwykle opisywania aplikacji w języku aksjomatów.
• Obliczanie metryk kodu źródłowego. Dostarczają nam informacji o jakości kodu źródłowego na podstawie danych statystycznych.

Ponadto warto wspomnieć, że statyczna analiza programu pozwala na:

• zwiększenie wydajności i stabilności poprzez zasady oparte na dobrych praktykach,
• unikniecie typowych błędów podczas programowania,
• dostarczenie struktury do zarządzania standardami kodu.
• wymuszenie własnych zasad pisania kodu

Na koniec chciałbym przypomnieć, że dobry przypadek testowy to taki, który niesie duże prawdopodobieństwo wykrycia nowego błędu

Model Analizy Biznesowej opisuje realizację biznesowych przypadków użycia. Prezentuje jak pakiety biznesowe, pracownicy biznesowi i byty biznesowe współpracują ze sobą w celu wykonania biznesowych przypadków użycia.

Celem Modelu Analizy Biznesowej jest opisanie, jak wykonywane są biznesowe przypadki użycia. Model Biznesowych Przypadków Użycia opisuje to, co zachodzi między aktorami biznesowymi a organizacją i nie robi żadnych założeń o strukturze organizacji i nie prezentuje specyfiki procesów biznesowych. Model Analizy Biznesowej, konkretnie określa usługi świadczone przez organizacje (przywoływane przez aktorów biznesowych w trakcie wykonania biznesowych przypadków użycia), określa wewnętrznych pracowników biznesowych i informacje, które wykorzystują (byty biznesowe), opisuje ich strukturalną organizację w niezależnych jednostkach (systemy biznesowe, pakiety biznesowe) oraz określa, w jaki sposób wchodzą w interakcję w celu realizacji zachowania opisanego w biznesowych przypadkach użycia. Innymi słowy Modela Analizy Biznesowej wskazuje na to jak realizowane są funkcje organizacji.

W ramach WMB w Modelu Analizy Biznesowej wyróżnia się pracowników biznesowych automatycznych – systemy komputerowe lub oprogramowanie oraz nieautomatycznych ? ludzi.

Model Analizy Biznesowej jest używany przez interesariuszy i analityków procesów biznesowych, aby rozumieć, w jaki sposób obecnie działa przedsiębiorstwo, organizacja (model as-is) oraz, aby zanalizować wpływ zmian na przedsiębiorstwo (model to-be).

Model Analizy Biznesowej jest także stosowany celem wyprowadzania wymogów systemowe w oparciu o to, jak zautomatyzowane systemy – zautomatyzowani pracownicy biznesowi (zwykle intensywnie wykorzystujący oprogramowanie) – będą stosowani jako część procesów biznesowych. Architekci oprogramowania wykorzystują model, aby określić architekturę oprogramowania, które pasuje do organizacji i aby określić klasy w modelach analizy i projektu.

W ramach WMB Model Analizy Biznesowej może składać się z następujących elementów:

• systemy biznesowe (pakiety biznesowe) – reprezentujące strukturę organizacji.
• pracownicy biznesowi
• byty biznesowe
• relacje
• diagramy: klas i aktywności oraz pakietów

Warto także zamieścić opis tekstowy, który służy jako zwięzłe wprowadzenie do modelu.

Praca rozproszonego (względem lokalizacji) zespołu przy projekcie to już nie nowinka a standard pracy wielu firm. Zauważyli to już wielcy gracze na rynku jak choćby IBM, który oferuje platformę JAZZ, która ma pomóc w pracy właśnie takim zespołom projektowym.  A co ma zrobić szef projektu, który ma zarządzać projektem przy budżecie, który nie przewiduje zakupu nowych narzędzi?  W takiej sytuacji można wykorzystać coś bezpłatnego.  Ja polecam dotProject, który  jest w pełni darmową aplikacją, opartą o stronę WWW, służącą do zarządzania projektami online. dotProject oferuje szereg funkcji takich jak kalendarz, wykresy Ganta, kontakty. Funkcją, którą sobie cenię jest baza dokumentów, aplikacji lub innego rodzaju plików, opatrzonych komentarzem i przyporządkowanych do projektu. Warto wspomnieć, że dotProject jest dostępny także po polsku a do jego pracy wystarczy przeglądarka internetowa i połączenie sieciowe do serwera, na którym znajduje się aplikacja.

W ramach WMB w zakresie modelowania biznesowego proponuję tylko jedna rolę: analityk procesów biznesowych.

Analityk procesów biznesowych odpowiada za:

• tworzenie procesów biznesowych przez zarysowanie i ograniczenie modelowanej organizacji
• uszczegóławianie procesów biznesowych
• budowę dokumentacji

W WMB, analityk procesów biznesowych  odpowiada za budowę biznesowego przypadku użycia poprzez zarysowanie i ograniczenie modelowanej organizacji, na przykład, przez ustalenie, którzy aktorzy biznesowi i biznesowe przypadki użycia istnieją oraz w jaki sposób wchodzą w interakcje między sobą. Po określeniu funkcji organizacji analityk procesów biznesowych buduje realizację biznesowych przypadków użycia określając systemy biznesowe (elementy składowe struktury organizacji), pracowników biznesowych i bytów biznesowych. Modeluje także zachowanie systemów biznesowych, pracowników biznesowych i podmiotów biznesowych – określając ich obowiązki, działania, atrybuty, a także relacje po między nimi.