Koncepcja dostosowania aplikacji zarządzającej wymaganiami do

Włodzimierz WYSOCKI
Wydział Elektroniki i Informatyki, Politechnika Koszalińska,
Unizeto Technologies SA,
E-mail: [email protected]
Koncepcja dostosowania aplikacji zarządzającej
wymaganiami do potrzeb organizacji
1. Wstęp
Celem artykułu jest prezentacja koncepcji dostosowania aplikacji wspomagającej zarządzanie wymaganiami dla potrzeb organizacji. Na wstępie przedstawiono aplikację traktowaną jako wzorcową: Rational Requirements Composer (RRC). Następnie zaprezentowano aplikacje alternatywne (open source), które mogą być także wykorzystywane
przez organizacje. Na zakończenie wskazano na pomysł/koncepcję rozwoju aplikacji
alternatywnych w oparciu o model referencyjny aplikacji wzorcowej. Zasugerowano
podział aplikacji wzorcowej na funkcjonalności oraz wskazano na metody doboru funkcjonalności aplikacji wzorcowej. Prace podsumowują wnioski i kierunki dalszych badań
nad rozwojem aplikacji Open Source.
2. Charakterystyka aplikacji wzorcowej
Problem zarządzania wymaganiami staje się kluczowy dla potrzeb każdej organizacji.
Wiele z nich proces zarządzania wymaganiami traktuje jako powtarzalny proces z dobranymi zasobami ale dla wielu proces pozyskiwania wymagań jest wpierany za pośrednictwem dobranej dla potrzeb tej organizacji aplikacji. O tym czy organizacja wykorzystuje tylko powtarzalny proces czy też wspiera się aplikacją decyduje poziom
dojrzałości tej organizacji.
Zarówno jednak w pierwszym (zastosowania powtarzalnego procesu) jak i w drugim
zastawanie aplikacji organizacje stają przed problemem doboru właściwej aplikacji do
wsparcia zarządzania wymaganiami. W pierwszym przypadku jest to najczęściej aplikacja open source w drugim bazująca na doświadczeniu organizacji dobrana do potrzeb tej
organizacji aplikacja wpierająca. W obu przypadkach kierujący organizacją rozważają
takie jej dostosowanie aby spełniała ona stawiane organizacji cele. Poniżej zaprezentowano przykład takiej właśnie aplikacji, która z pewnością może spełniać wymagania
każdej z organizacji. Jej dobór wynika z doświadczeń w zarządzaniu wymaganiami
i znajomości rynku aplikacji wspomagających zarządzanie wymaganiami. Jest nią Rational Requirements Composer (RRC) w środowisku jazz.net produkcji IBM. Przyjęto
także że dla weryfikacji czy proponowana aplikacja jest wzorcowa będą z nią porównywane inne narzędzia dostępne na rynku. Ocenę tej aplikacji rozpoczęto od wsparcia
dla pracy zespołowej. RRC jest przystosowane do współpracy w zespołach, których
członkowie – udziałowcy i członkowie zespołu projektowego IT mogą być rozproszeni
po całym świecie. Pozwala to na wspólne wprowadzanie zmian i uzgodnienie jednako-
184
Włodzimierz Wysocki
wego rozumienia wymagań już na wczesnym etapie procesu. Następnym kryterium
oceny jest różnorodność sposobów, na jakie można odwzorować wymagania udziałowców. RRC pozwala na użycie wielu typów artefaktów:
•
•
•
•
•
•
•
dowolnie formatowane, dopracowane graficznie dokumenty tekstowe,
fragmenty interfejsu użytkownika,
diagramy nawigacji między ekranami,
scenorysy (storyboard),
diagramy procesów biznesowych,
diagramy przepływu,
diagramy przypadków użycia.
Rys. 1. Dekompozycja wzorcowej aplikacji Rational Requirements Composer
Fig. 1. Breakdown of reference application Rational Requirements Composer
Pod względem wspierania zarządzania wymaganiami RRC oferuje duże możliwości
analizowania, organizowania i zarządzania. Odbywa się to za pomocą atrybutów, kolekcji, znaczników, filtrów i dynamicznych widoków informacji. Raporty tworzone są na
podstawie standardowych szablonów lub według ustawień użytkownika. Umożliwiają
Koncepcja dostosowania aplikacji zarządzającej wymaganiami…
185
łatwy wgląd w stan projektu przez utworzenie specyfikacji wymagań, historii audytów,
raportu śledzenia zależności. Mimo zapewnienia rozbudowanych możliwości zarządzania wymaganiami dużych projektów informatycznych, aplikacja RRC wspiera także
zwinne podejście do zbierania wymagań. Umożliwia wykorzystanie metodologii Scrum,
planowania sprintów, wykorzystanie listy zaległości projektowych. Poziom sformalizowania wymagań zależy wyłącznie od użytkownika. Istotną składową częścią oceny
aplikacji jest powiązanie procesu zbierania wymagań z innymi fazami procesu wytwarzania oprogramowania. RRC łączy ze sobą działania fazy zbierania wymagań, implementacji, zarządzania zmianami i zarządzania jakością przez technologię zarządzania
cyklem życia przez współpracę na poziomie Collaborative Lifecycle Management.
Wymagania z RRC zostają powiązane z elementami pracy z Rational Team Concert
i testami z Rational Quality Managera. RRC pomaga dzięki tym powiązaniom odnaleźć
braki w implementacji lub testach wymagań.
Ważnym sposobem zmniejszenia możliwości wystąpienia błędów w wymaganiach jest
ponowne użycie części wymagań z projektu, który zakończył się sukcesem. Requirements Composer wspiera ponowne użycie zebranych, zweryfikowanych i zatwierdzonych wymagań. Porównywanie aplikacji wzorcowej z innymi aplikacjami wymaga
dekompozycji wzorcowej architektury na:
•
•
•
atomowe funkcjonalności,
usługi – grupujące spójne tematycznie funkcjonalności,
usługi złożone.
Dekompozycję można przedstawić za pomocą diagramów szkieletu SOMF – Service
Oriented Modeling Framework. Diagramy te przedstawiają tylko ogólną ideę dekompozycji. Dokładne odwzorowanie zarówno funkcjonalności, jak i wymagań niefunkcjonalnych wymaga opracowania ontologii. Dekompozycję aplikacji RRC i zintegrowanych
z nią narzędzi w środowisku jazz.net przedstawiono na rysunku 1. W przypadku, gdy
powstanie bardziej kompletne narzędzie do zarządzania wymaganiami, można go użyć
jako nowej aplikacji wzorcowej.
3. Prezentacja aplikacji alternatywnych
Na rynku istnieje wiele aplikacji typu open source. Te aplikacje wspierają różne aspekty
procesu zbierania wymagań. Wszystkie są jednak w pewien sposób ograniczone. Ograniczenia te przyjmują dwie postacie. W pierwszej narzędzie jest zbyt ogólne, jak np.
Wiki czy DRUPAL. Są to właściwie uniwersalne narzędzia do zarządzania treścią, których można użyć do zbierania i zarządzania wymaganiami, nie są jednak tak wygodne
jak narzędzia wyspecjalizowane. Autorzy pozycji [7] zalecają użycie otwartych, darmowych narzędzi do zbierania wymagań w małych projektach wytwarzanych w zwinnych metodykach. Wiki, fora dyskusyjne i blogi mogą służyć do wyławiania wymagań
przez współpracę z udziałowcami i wspólne opracowywanie scenariuszy przypadków
użycia. W średnich i dużych projektach zalecają zbieranie przez analityków wymagań
przy pomocy prostych narzędzi – papierowych kart do zbierania wymagań zwanych
„snow card”. Karty można segregować, przypinać do tablic, ścian w pokoju konferen-
186
Włodzimierz Wysocki
cyjnym. Po zebraniu większej ilości kart trzeba wprowadzić je do wyspecjalizowanego
narzędzia do zarządzania wymaganiami, które pozwalają na śledzenie zależności przez
cały cykl życia projektu.
Ograniczenia drugiego rodzaju dotyczą wyspecjalizowanych narzędzi. Polegają one na
tym, że te narzędzia są dostosowane do specyficznych wymagań niektórych organizacji
wytwarzających oprogramowanie.
Poniżej przedstawiono listę aplikacji typu open source do wspierania procesu zbierania
wymagań. Lista aplikacji została utworzona na podstawie informacji umieszczonych na
forach poświęconych zarządzaniu wymaganiami, projektami i programowaniu. Są to
aplikacje open source polecane przez użytkowników tych for.
Narzędzia uniwersalne
Wiki – możliwość definiowania struktury stron wg. atrybutów. Można zdefiniować
szablony wymagań, przypadków użycia, słowników. Posiada kontrolę wersji i publikację w PDF.
DRUPAL – uniwersalne narzędzie do zarzadzania treścią. Istnieje możliwość skonfigurowania go do wspierania zbierania wymagań, tworzenia szablonów dokumentów. Posiada wersjonowanie plików, możliwość publikacji w wielu formatach. Narzędzie posiada otwartą architekturę przystosowaną do rozszerzania za pomocą modułów. Wykorzystuje je Open Atrium - narzędzie do zarządzania projektami.
WordPress – popularny, łatwy w administracji system do zarządzania treścią, który można rozszerzać za pomocą mechanizmu wtyczek. Istnieją wtyczki do prowadzenia forów
internetowych, do prowadzenia blogów oraz do zarządzania projektami informatycznymi.
Fora dyskusyjne – darmowe fora dyskusyjne są dostępne w internecie. Jest również
dużo darmowych skryptów umożliwiających założenie forum dyskusyjnego na serwerze
organizacji. Przykładowo phpBB, punBB, bbPress.
Blogi – darmowe blogi są powszechnie dostępne w internecie. Do założenia bloga na
serwerze organizacji można użyć skryptów open source, lub wtyczek do popularnych
systemów zarządzania treścią. Popularne skrypty to Simple PHP Blog, Bloly Blog
Script, Wordsmith, b2evolution.
Narzędzia wyspecjalizowane
aNimble Platform - narzędzie do zarządzania wymaganiami, zaprojektowane aby uzyskać
pełne śledzenie zależności w cyklu życiu oprogramowania dla możliwości, wymagań, projektu, implementacji i testów. Interfejs użytkownika wspomaga tworzenie wymagań pochodnych, atrybutów wymagań. Posiada kontrolę wersji, zarządzanie projektem, raportowanie, zarządzanie testami. Otwarta architektura jest oparta o technologie Grails i DOJO.
Obszar roboczy aplikacji pozwala na współpracę w sieci w czasie rzeczywistym. Umożliwia zbieranie i organizowanie wymagań, śledzenie błędów i sprawdzanie stanu projektu. Wspiera tworzenie artefaktów w metodyce kaskadowej oraz zwinnych i Scrum.
Udostępnia historię i komentowanie artefaktów, definiowanie własnych artefaktów
i dołączanie własnych rodzajów pól, wyszukiwanie zawartości pól i dokumentów.
Koncepcja dostosowania aplikacji zarządzającej wymaganiami…
187
Zarządzanie projektami pozwala na zarządzanie pracą zespołu w czasie rzeczywistym.
Wspiera konfigurowanie szablonów artefaktów, widoków i danych odnośników, tworzenie własnych przepływów dla cyklu życia artefaktów.
Planowanie wydań i sprintów umożliwia tworzenie hierarchii projektów i artefaktów,
przypisywanie priorytetów, tworzenie szczegółowych raportów sprintów i wydań.
Zarządzanie testami opiera się o ścisłe zależności między wymaganiami a przypadkami
testowymi, wynikami testów i informacjami o błędach. Umożliwia śledzenie zależności,
przepływu, historii, komentarzy, dołączanie dokumentów, zrzutów ekranów i komentarzy do informacji o problemach.
UNICASE – narzędzie typu CASE zintegrowane ze środowiskiem deweloperskim
eclipse. Wspiera tworzenie artefaktów jako elementów jednolitego modelu w projekcie
wytwarzania oprogramowania. Artefaktami – elementami modelu są wymagania funkcjonalne, przypadki użycia, komponenty i diagramy UML. Jednolity model definiuje
zależności między elementami modelu przez połączenia, które umożliwiają śledzenie
zależności. Modele są zapisywane i wersjonowane na serwerze svn dostosowanym do
modeli. Możliwości UNICASE to modelowanie wymagań, modelowanie UML (przypadki użycia, diagram klas, diagram stanów, diagram komponentów, modele komunikacji), zarządzanie zadaniami i błędami, planowanie iteracji, wizualizacja stanu projektu,
pełne śledzenie zależności, zarządzanie zmianami, wersjonowanie, łączenie zmian.
JUCMNav – wtyczka do eclipse'a. Graficzny edytor, narzędzie do analizy i transformacji notacji wymagań użytkownika (URN). URN jest przeznaczony do wydobywania,
analizy, specyfikacji i walidacji wymagań.
JRequisite – narzędzie do zwinnego zarządzania wymaganiami zorientowany na modelowanie wizualne, nie tekstowe.
Requirement Heap – aplikacja sieciowa służąca do zarządzania wymaganiami i analiz
biznesowych. Pozwala na tworzenie graficznych dokumentów tekstowych, wspiera wersjonowanie. Umożliwia tworzenie wymagań, przypadków użycia, wywiadów i przypadków testowych. Zarządza wieloma projektami, podprojektami, wydaniami. Udziałowcy
i słowniki mogą być definiowani globalnie lub dla wybranego projektu. Projekty można
publikować jako pdf, eksportować jako arkusze xls lub csv.
4. Model referencyjny aplikacji wzorcowej
i koncepcja jego wykorzystania
Celem budowy modelu referencyjnego opartego na RRC było wskazanie kierunku rozwoju aplikacji do wspomagania zarządzania wymaganiami. Po prezentacji aplikacji open
source pojawia się pytanie na ile aplikacje te odzwierciedlają funkcjonalności RRC oraz
na ile są one zgodne z wymaganiami przedsiębiorstwa wykorzystującego aplikacje open
source. Aby to sprawdzić pojawiała się koncepcja budowy modelu referencyjnego i jego
wykorzystania. Koncepcja ta polega na wybraniu z aplikacji wzorcowej funkcjonalności
niezbędnych do wsparcia potrzeb organizacji. Wybór jest przeprowadzony przez maszynę
wnioskującą na podstawie reguł i parametrów podanych przez przedstawiciela organizacji.
Wybrane funkcjonalności są porównane z funkcjonalnościami zapewnianymi przez roz-
188
Włodzimierz Wysocki
budowywaną aplikację. Brak wybranych funkcjonalności w używanym aktualnie systemie
wskazuje kierunek rozwoju rozbudowywanej aplikacji.
Rys. 2. Koncepcja modelu doboru funkcjonalności
Fig. 2. The concept of an IT technology selection model
Zwykle organizacje potrzebują tylko części funkcjonalności oferowanej przez aplikację
wzorcową ze względu na ograniczone klasy projektów, które wytwarzają. Aplikacje
komercyjne są drogie i organizacje nie chcą płacić za możliwości, które będą rzadko lub
w ogóle nie wykorzystywane. Często organizacje wspierają się rozwiązaniami typu
open source, które są darmowe, jednak daleko im do poziomu wsparcia oferowanego
przez narzędzia komercyjne.
Organizacje wytwarzające oprogramowanie używają wielu narzędzi typu open source,
dostosowując je do własnych potrzeb. Dostosowanie odbywa się przez zmianę istniejących komponentów aplikacji przez modyfikację istniejącego kodu źródłowego.
W wielu aplikacjach jest zaimplementowany mechanizm wtyczek. W takim przypadku
możliwe jest dodawanie niezbędnej funkcjonalności przez utworzenie zintegrowanych
wtyczek. To rozwiązanie jest wygodniejsze w użytkowaniu, ponieważ wtyczka jest
osobnym bytem, nie trzeba zmieniać oryginalnego kodu aplikacji. Można, zatem uaktualniać aplikację do kolejnych, ulepszonych wersji.
Dostosowanie aplikacji odbywa się w następujących krokach:
•
•
•
•
przedstawiciel organizacji wytwarzającej oprogramowanie dostarcza parametry
projektów, które organizacja ma realizować,
maszyna wnioskująca na podstawie parametrów i reguł wybiera niezbędne funkcjonalności z modelu aplikacji wzorcowej,
wybrane funkcjonalności są porównywane z funkcjonalnościami wykorzystywanej
aplikacji open source. Funkcjonalności, których dotychczasowa aplikacja nie udostępnia są przedstawiane przedstawicielowi organizacji,
aplikacja open source zostaje rozszerzona przez implementację niezbędnych funkcjonalności.
Koncepcja dostosowania aplikacji zarządzającej wymaganiami…
189
Głównymi parametrami projektu są wielkość i wykorzystywana metodologia.
Metodologie zwinne kładą nacisk na krótkie iteracje i szybkie dostarczenie wartości klientowi. Wprowadza to wysoki poziom sprzężenia zwrotnego, regulującego proces wytwarzania. Udziałowcy są zaangażowani w proces i przepływ informacji jest dobry. W tych warunkach formalne dokumentowanie wymagań nie niezbędne. Wystarczy jedynie opracowanie
scenariuszy dla przypadków użycia. Często jedna iteracja zawiera implementację tylko
jednego przypadku użycia. Zwinne metodologie są stosowane tylko do małych projektów.
W projektach średniej wielkości wymagania są udokumentowane a cykl iteracyjny jest
dłuższy. Kilku analityków na raz pracuje z udziałowcami, więc jest potrzebne narzędzie
pozwalające na równoległą pracę w rozproszonym zespole z możliwością synchronizacji i śledzenia zmian. Komunikacja między analitykami a projektantami i deweloperami
odbywa się w większej części przez dokumentację, zatem jest potrzeba opracowania
dokładnej specyfikacji wymagań funkcjonalnych i niefunkcjonalnych.
Tab. 1. Wpływ parametrów projektu na artefakty procesu zbierania wymagań
Tab. 1. Influence of project parameters on essential artifact of requirement process
Parametry projektu
klient – administracja
państwowa
duże rozproszenie
systemu
niestandardowa
aplikacja
ograniczenia czasowe
duża ilość wymagań
projekt długotrwały
złożoność funkcjonalna
standaryzowany proces
projektowania
duży zespół
duże rozproszenie
zespołu
niedoświadczony
zespół
Niezbędne artefakty
analiza wartości dla klienta, obliczenie zwrotu inwestycji,
analiza ryzyka biznesowego, kryteria akceptacji, akceptacyjne przypadki testowe
analiza ryzyka, czynniki powodzenia systemu, scenariusze
aplikacji, model środowiska, wyznaczenie obszaru systemu, ograniczenia architektury
scenariusze aplikacji, testy integracyjne
analiza ryzyka biznesowego, kryteria testów integracyjnych, śledzenie zależności: potrzeby → wymagania, wymagania → specyfikacja systemu
analiza ryzyka, śledzenie zależności: potrzeby → wymagania, wymagania → specyfikacja systemu
zakres i ograniczenia, śledzenie zależności: potrzeby →
wymagania, wymagania → specyfikacja systemu
scenariusze aplikacji, śledzenie zależności: potrzeby →
wymagania, wymagania → specyfikacja systemu
kryteria akceptacji, artefakty koncepcji projektu
zakres i ograniczenia, scenariusze aplikacji, model danych,
śledzenie zależności wymagania → specyfikacja systemu
analiza ryzyka, scenariusze aplikacji, kryteria akceptacji
śledzenie zależności wymagania → specyfikacja systemu
analiza ryzyka
Włodzimierz Wysocki
190
W dużych projektach wszystkie wymagania są udokumentowane. Dokumentacje wymagań muszą być kompletne, ponieważ służą do wewnętrznej komunikacji w ramach projektu pomiędzy analitykami, projektantami, deweloperami, testerami i autorami dokumentacji. W dużych projektach stosuje się też często outsourcing oraz podział etapów projektu
na wielu wykonawców. Szczegółowa i formalnie poprawna dokumentacja jest warunkiem
zakończenia zlecenia. Tylko pełna i poprawna dokumentacja umożliwia przekazanie prac
do następnego etapu i kontynuację przez kolejnego wykonawcę.
Na podstawie artykułu [3] wyodrębniono listę parametrów projektu istotnych dla doboru funkcjonalności. W tabeli 1 umieszczono wartości parametrów projektu i odpowiadające im artefakty procesu zbierania wymagań. Lista niezbędnych artefaktów może zostać przekształcona przez model na usługi i funkcjonalności aplikacji wzorcowej.
5. Podsumowanie i kierunki dalszych badań
W artykule zaprezentowano koncepcję doboru funkcjonalności aplikacji zarządzającej
wymaganiami do potrzeb organizacji wytwarzającej oprogramowanie. Przedstawiono
aplikację wzorcową – najlepiej spełniającą wymagania i potrzeby klientów. Za taką
wzorcową aplikację autorzy uznali narzędzie IBM Rational Requirements Composer
działające na platformie jazz.net. Wymieniono i pokrótce opisano rozwiązania alternatywne – aplikacje open source do zarządzania wymaganiami. Wprowadzono koncepcję
rozszerzania funkcjonalności narzędzi open source w oparciu o aplikację wzorcową.
Podano zależności między parametrami projektów wytwarzanych przez organizację
a niezbędnymi do realizacji projektów artefaktami.
Artykuł przedstawia ogólną koncepcję użycia modelu referencyjnego do rozbudowy
narzędzi open source. Otwartą kwestią pozostaje sposób opisu aplikacji wzorcowej
i aplikacji open source tak, aby można było porównywać jakościowo ich funkcjonalności. Celowe wydaje się opracowanie i zastosowanie ontologii do opisu i porównania
aplikacji. Istotną częścią modelu wymagającą dalszych prac jest opracowanie bazy
wiedzy i reguł sterujących działaniem maszyny wnioskującej.
Literatura
1.
2.
3.
4.
5.
6.
Aybuke A., Claes W.(Eds.): Engineering And Managing Software Requirements, Springer 2005.
Bell M.: Service-oriented modeling (SOA): service analysis, design, and architecture.
Prentice Hall 2005.
Fernández M., Wagner D., Lochmann S., Baumann K., Carne A. de, Holger: Field study
on requirements engineering: Investigation of artefacts, project parameters, and execution strategies. Elsevier Science 2012.
Jones C., Bonsignour O.: The Economics of Software Quality. Addison-Wesley 2011.
Orłowski C., Sitek T., Dowgielewicz K., Wysocki W., Deręgowski T.: The structure of
knowledge resources supporting model of IT technologies' architectures. KES 2012.
Rational Requirements Composer.
http://www-142.ibm.com/software/products/pl/pl/rrc/
Koncepcja dostosowania aplikacji zarządzającej wymaganiami…
7.
8.
9.
191
Robertson S., Robertson J.: Mastering the Requirements Process. Second Edition. Addison Wesley Professional 2006
Service-Oriented Modeling Framework for Business & Technology.
http://www.modelingconcepts.com/pdf/SOMF_ANALYSIS_MODELING.pdf
Zielczynski P.: Requirements Management Using IBM Rational RequisitePro. IBM
Press 2008
Streszczenie
W artykule przedstawiono wzorcową aplikację do zarządzania wymaganiami - Rational
Requirements Composer. Zamieszczono listę narzędzi open source do zarządzania wymaganiami, które zostały w skrócie opisane. Autor opisuje ogólną koncepcję użycia
modelu referencyjnego do rozbudowy aplikacji open source w celu dostosowania jej do
potrzeb organizacji. Zastosowanie koncepcji zostało pokazane na przykładzie rozbudowy narzędzia do zarządzania wymaganiami.
The concept of adaptation requirements
management application for organization
Summary
The article presents a reference model for requirements management tool - Rational
Requirements Composer. It contains a list of open source tools for requirements management, which are briefly described. The author describes the general concept of using
a reference model for open source application development in order to adapt it to organization needs. Application of the concept is shown in the example of development tools
for requirements management.