o modelowaniu procesów i systemów 

MANEA jest to dodatek (plugin) do MANTIS BUG TRUCKER, który pozwala na dwukierunkową synchronizację wybranych wpisów z systemu MANTIS BT z repozytorium wymagań znajdujących się w Enterprise Architect firmy Sparx.

MANEA cechy:

• mapowanie, za pomocą Enterprise Architecta, wpisów i zgłoszeń na konkretne artefakty modelu aplikacji
• prowadzenie w systemie MANTIS dyskusji nad wymaganiami zapisanymi w Enterprise Architect
• umożliwienie szerokiemu gronu osób zgłaszania propozycji wymagań – tylko administrator wstawiając odpowiedni wskaźnik – tag EA-MANTIS może zezwolić na integracje wpisu z Enterprise Architectem
• możliwość zarządzania zgłoszeniami o błędach w oparciu o model wykonany w języku uml
• łatwość instalacji w systemie MANTIS gdyż MANEA to standardowy plugin,
• wsparcie dla repozytoriów błędów i modeli gromadzonych za pomocą bazy danych mysql

Wersja demo jest do pobrania ze strony www.manea.info

Zmiany w oprogramowaniu i modelach są nieuniknione. Poniżej kilka słów na temat jak je przedstawić w EA i jak je raportować.

Przyjąłem, że zmiany dotyczą zmian w istniejącym już oprogramowaniu.

Zmiana jest zgłoszona w dowolnej formie przyjętej w organizacji natomiast w Enterprise Architect jest reprezentowane jako wymaganie, zmiana lub defekt (problem)

Wszystkie wymagania i elementy, które mają znaleźć się w kolejnym wydaniu powinny dostać odpowiedni numer wersji, np.: 1.1

przeczytaj pozostałą część »

Wybór narzędzia CASE wspomagającego proces akwizycji i zarządzania wymaganiami jest trudny. Poniżej zamieszczam link do zestawienia cech wybranych narzędzi.

Zestawienie to jest tłumaczeniem badań jakie zostały opublikowane przez The International Council on Systems Engineering (INCOSE). Na stronach tej organizacji można znaleźć oryginał z bogatszą listą produktów.

?Złote reguły? to nic innego jak wykaz punktów, które zazwyczaj kontroluję podczas tworzenia przypadków użycia. Gdy mam już narysowany przypadek użycia sprawdzam czy:

• przypadek użycia zapewnia wartość aktorom,
• krótki opis zwięźle opisuje cel przypadku użycia,
• przypadek użycia jest kompletny i sensowny,
• wydarzenie rozpoczynające przypadek użycia jest jasne,
• sposób i czas zakończenia przypadku użycia jest jasny,
• stosowana terminologia jest jasna, a istotne terminy zdefiniowane w słowniczku lub podobnym,
• rozpoczęcie i zakończenie przepływu alternatywnego
  jest jasne a każdy przepływ alternatywny posiada jasne
  odniesienie do sposobu, w jaki się zaczyna i dokąd zawrócona jest kontrola po tym jak zostanie wykonany,
• przypadek użycia jest możliwy do zweryfikowania,
• wszystkie kroki są indywidualnie ponumerowane,
• aby uprościć długie i złożone przepływy zdarzeń, wykorzystywane są podprzepływy w postaci dekompozycji aktywności

Powyższy dekalog sprawdzanych parametrów pozwala na utrzymywanie w repozytorium projektu w miarę sensownych przypadków użycia.

W sieci pojawił się nowy blog o wymaganiach (http://owymaganiach.pl/). Cieszy mnie ta inicjatywa, Pana Jakuba Jurkiewicza – doktoranta na Politechnice Poznańskiej, gdyż w sieci jest mało zasobów na temat inżynierii oprogramowania a te zapowiadają się sensownie.    Z pierwszych wpisów polecam teksty o przypadkach użycia. Powodzenia

W Enterprise Architect jest dedykowany do gromadzenia wymagań element zwany ?Requirement?

Jest to bardzo komfortowa sytuacja, ale co zrobić gdy nie ma takiego elementu w danym narzędziu CASE?

przeczytaj pozostałą część »

Z nowym rokiem uzupełniłem kilka wpisów, które były niedokończone a które miały się ukazać w grudniu. Pierwsze dwa tygodnie były dość pracowite dla mnie.  Jedno z zadań z jakiego myślę, że wywiązałem należycie się to autorskie szkolenie zakresu gromadzenia i zarządzania wymaganiami w Enterprise Architect.  Dlaczego myślę, że wywiązałem się należycie. W testach z wiedzy przed i po szkoleniu widać progres u każdego z uczestników szkolenia. Ponadto w ankietach oceniających szkolenie otrzymałem dobre i bardzo dobre noty. Innym ciekawym przedsięwzięciem w jakim mogłem uczestniczyć to współpraca z polskim instytutem badawczym. Pomagałem im, i mam nadzieję, że w nowym roku także będę to robił,  w zakresie budowy architektury złożonego systemu (sprzęt + oprogramowanie) oraz zarządzaniem wymaganiami na ten system. Zadanie to jest tym bardziej ciekawe, że jest to jeden z ostatnich polskich instytutów z polską myślą inżynierską. To rzadkość  na polskim rynku, a dla mnie satysfakcja z pracy z rewelacyjnymi polskimi inżynierami, specjalistami w swojej dziedzinie, praktykami w każdym calu. W tym instytucie tworzą się na prawdę innowacyjne polskie produkty.

Przymiotnik polski powtórzyłem celowo kilka razy.

W trakcie szkicowania procesów biznesowych należy zdefiniować wspólne słownictwo, przy użyciu najpopularniejszych terminów i wyrażeń w zakresie problemu. Następnie należy konsekwentnie wykorzystywać wspólne słownictwo we wszystkich tekstowych opisach biznesu. W ten sposób, utrzymują Państwo spójne opisy tekstowe i unika się nieporozumień wśród członków projektu dot. stosowania i znaczenia terminów. Słownictwo powinno mieć formę słownika.

Aby znaleźć wspólne terminy w zakresie problemu, należy uwzględnić terminy stosowane w trakcie rozmowy, o co chodzi w biznesie. Warto skupić się na terminach opisujących następujące koncepcje:

• Obiekty biznesowe reprezentujące koncepcje stosowane w codziennej pracy organizacji. W wielu przypadkach, już istnieje wykaz tego rodzaju koncepcji.
• Obiekty świata rzeczywistego, których istnienia przedsiębiorstwo musi być świadome. Te obiekty występują w naturalny sposób i obejmują takie rzeczy jak: samochód, psa, butelkę, samolot, pasażera, rezerwację, bądź fakturę.

Każdym termin jest na ogół opisywany jako rzeczownik wraz z definicją. Terminy powinny być podane w liczbie pojedynczej, "zamówienie" oraz "zadanie", a nie "zamówienia" czy "zadania".

I na koniec oczywiste i najważniejsze: wszystkie zainteresowane strony powinny porozumieć się co do zdefiniowania terminów.

Jakiś czas temu na stronie Pana Kowalczykiewicza http://www.cs.put.poznan.pl/kkowalczykiewicz/ był ciekawy tekst na temat dobrych praktyk w inżynierii wymagań. Obecnie ta strona jest wyłączona. Z tego też powodu pozwalam sobie na publikację tego tekstu, który (co mnie zadziwia) miałem w swoim archiwum. Tekst ten został odrobinę przeformatowany.

Ian Sommerville i Pete Sawyer zaproponowali ciekawą metodę oceny i doskonalenia procesów inżynierii wymagań. Opiera się ona na wyodrębnieniu dobrych praktyk, czyli czynności będących pożądanymi elementami wzorcowego procesu inżynierii wymagań. Autorzy starali się przy tym objąć całość problematyki inżynierii wymagań. Dobre praktyki reprezentują więc następujące obszary działalności:

• dokument specyfikacji wymagań,
• pozyskiwanie wymagań,
• analiza i negocjacja wymagań,
• opisywanie wymagań,
• modelowanie systemu,
• weryfikacja wymagań,
• zarządzanie wymaganiami,
• systemy krytyczne.

Biorąc pod uwagę te kryteria wyodrębniony został podział praktyk na trzy grupy wg zaawansowania powiązanego z tymi kosztami i poziomem skomplikowania:

• praktyki podstawowe
• praktyki średniozaawansowane
• praktyki zaawansowane

Dobre praktyki stanowią podstawę do oceny poziomu dojrzałości procesów inżynierii wymagań w organizacji. Zakres wspomnianych dobrych praktyk opisałem w poniższych punktach:

Podstawowe dobre praktyki inżynierii wymagań

Średniozaawansowane dobre praktyki inżynierii wymagań

Zaawansowane dobre praktyki inżynierii wymagań

Każdy inżynier oprogramowania dobrze wie jak ważnym dokumentem jest Słownik w trakcie procesu wytwórczego oprogramowania a szczególnie w jego pierwszych fazach. Bez zrozumienia pojęć czy skrótów, którymi posługuje się klient z na pewno nie rozwiążemy jego problemu.

Enterprise Architect (EA) udostępnia nam funkcjonalność związaną z budową Słownika (menu Project > Documentation > Glossary?). W okienku możesz definiować listę terminów używanych w projekcie i kojarzyć z nimi opisy ich znaczenia jak również generować prosty raport zwany Słownikiem.

Jednak użytkownik tworzący model w EA z reguły korzysta z podręcznego elementu Notes do opisu znaczenia definiowanych elementów modelu. Jest on zwykle widoczny w trakcie pracy w EA i kojarzony z każdym elementem modelu a więc poręczniejszy niż okienko Słownika.

Jak więc wygenerować raport odpowiadający Słownikowi z notatek modelu? Jak się okazuje nie jest to trudne w EA. Rozważmy przypadek, że chcemy wygenerować Słownik z notatek wszystkich Aktorów w postaci: nazwa aktora i jego opis. W tym celu:

przeczytaj pozostałą część »

Enterprise Architect, moim zdaniem, nie jest najszczęśliwszym narzędziem do zarządzania wymaganiami. Nie jest też beznadziejny.

W projektach dla mnie ważne jest to jak wymagania są mapowane na konkretne przypadki użycia (PU). Pozwala to stwierdzić, które PU są bardziej złożone, wymagają większej uwagi i są ważniejsze dla klienta. Aby to stwierdzić trzeba zmapować PU z konkretnymi wymaganiami. W tym celu dodaję wymagania na diagram i łączę asocjacja z PU a jeśli diagram jest nieczytelny to związki dodaje w macierzy. Wygenerowanie macierzy?

przeczytaj pozostałą część »

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.