napisane przez Michał Wolski | w kategorii zarządzanie wymaganiami, zwinne modelowanie
środa 19 sie 2009
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.
napisane przez Michał Wolski | w kategorii o inżynierii oprogramowania, teksty
poniedziałek 23 lut 2009
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.
napisane przez Michał Wolski | w kategorii o inżynierii oprogramowania, teksty, zarządzanie wymaganiami
piątek 20 lut 2009
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.
napisane przez Michał Wolski | w kategorii literatura, o inżynierii oprogramowania, teksty, wydarzenia
poniedziałek 15 gru 2008
Właśnie ukazał się jesienny The Rational Edge ezine (http://ibm.com/developerworks/ecma/campaign/er.jsp?id=376126&imid=68950291&end). Dla fanów RSA jest bardzo ciekawy artykuł, w którym Steve Arnold opisuje nowe cechy IBM Rational Software Architect for WebSphere Software 7.5, dotyczące modelowania i transformacji http://www.ibm.com/developerworks/rational/library/08/0926_arnold/index.html.
Natomiast mi, być może z uwagi na specyfikę projektu, którym się teraz zajmuje, najbardziej podobał się artykuł pt. “Handling Requirements Effectively on Agile Projects” (http://www.ibm.com/developerworks/rational/library/edge/08/oct08/rivera1/index.html), w którym można przeczytać o tym jak efektywnie zarządzać wymaganiami w projektach bazujących na Agile. Zapraszam do lektury.
napisane przez Michał Wolski | w kategorii o inżynierii oprogramowania, zarządzanie wymaganiami
środa 30 kwi 2008
Jakiś czas temu napotkałem ciekawe wyniki badań, które zostały opracowane w Polsce. Instytut Informatyki Politechniki Poznańskiej wykonał badania, w których celem było znalezienie odpowiedzi na pytanie: jaka reprezentacja wymagań: tekstowa, czy graficzna, jest lepsza z punktu widzenia stopnia zrozumienia przez osoby je czytające?
Jako reprezentanta podejścia tekstowego wybrano przypadki użycia. Natomiast dla notacji graficznej wybrano zapis BPMN, który przypomina UML, lecz jest tworzony z zamiarem opisu modeli biznesowych. Uczestnikami eksperymentu byli studenci 4-tego roku Inżynierii Oprogramowania oraz Gospodarki Elektronicznej.
przeczytaj pozostałą część »