Włodzimierz WYSOCKI Wydział Elektroniki i Informatyki, Politechnika Koszalińska, Unizeto Technologies SA, E-mail: wlodzimierz.wysocki@tu.koszalin.pl 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ąźródłowego. cych komponentów aplikacji przez modyfikację istniejącego kodu 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 uaktudostarcza parametry alniać aplikację do kolejnych, ulepszonych wersji. Dostosowanie aplikacji odbywa się w następujących krokach: przedstawiciel organizacji wytwarzającej oprogramowanie projektów, które organizacja ma realizować, maszyna wnioskująca na podstawie parametrów i reguł wybiera niezbędne funkwykorzystywanej cjonalności z modelu aplikacji wzorcowej, wybrane funkcjonalności są porównywane z funkcjonalnościami aplikacji open source. Funkcjonalności, których dotychczasowa aplikacja nie udoniezbędnycfunk- stępnia są przedstawiane przedstawicielowi organizacji, aplikacja open source zostaje rozszerzona przez implementację cjonalnoś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 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 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ół 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
190 Włodzimierz Wysocki 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. Aybuke A., Claes W.(Eds.): Engineering And Managing Software Requirements, Springer 2005. 2. Bell M.: Service-oriented modeling (SOA): service analysis, design, and architecture. Prentice Hall 2005. 3. 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. 4. Jones C., Bonsignour O.: The Economics of Software Quality. Addison-Wesley 2011. 5. 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. 6. Rational Requirements Composer. http://www-142.ibm.com/software/products/pl/pl/rrc/
Koncepcja dostosowania aplikacji zarządzającej wymaganiami 191 7. Robertson S., Robertson J.: Mastering the Requirements Process. Second Edition. Addison Wesley Professional 2006 8. Service-Oriented Modeling Framework for Business & Technology. http://www.modelingconcepts.com/pdf/somf_analysis_modeling.pdf 9. 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.