Transformacja wymagań biznesu do działającej aplikacji

Napisanie kodu aplikacji jest łatwe, nawet bardzo łatwe, gdy programista dokładnie wie, co ten kod ma… robić.
Publikuję artykuł z IT Crew Blog

Okazuje się, że dokładana znajomość celu tworzonego oprogramowania, to wcale nie jest założenie oczywiste. Zgodnie z badaniami analityków zdecydowana większość zmian w aplikacji jest powodowanych przez niepoprawne lub nieprecyzyjnie opisane wymagania. W sposób obrazowy pokazuje to znany żart rysunkowy – „Projekt informatyczny jako budowanie huśtawki” (dla tych, którzy nie znają, historyjka ta ma własną stronę internetową: www.projectcartoon.com). Forma jest żartobliwa, ale treść, dla osoby biorącej udział w poważnych projektach, zbyt bliska prawdy, aby rzeczywiście rozbawić.
W wielu projektach zbyt mało uwagi jest poświęcone na zebranie początkowych wymagań, w efekcie czego, wielokrotnie poprawiamy kod, aby spełnić wymogi odbioru pracy. Czasem istnieją ku temu uzasadnione przyczyny:

• tworzymy zupełnie nowe rozwiązanie dla rynku i jego ostateczny kształt jest trudny do określenia na początku projektu,
• zakładamy z góry, że nie jest możliwe w 100% spełnienie wymagań i ostateczne rozwiązanie będzie kompromisem pomiędzy potrzebami, dostępnym czasem i budżetem, więc, po co tracić czas na analizę wymagań,
• nie mamy możliwości ustalenia wymagań z faktycznymi użytkownikami:
• użytkownicy nie mają czasu,
• w imieniu użytkowników wypowiada się kto inny,
• użytkownicy nie rozumieją formalnych sposobów zapisy wymagań,
• zakładamy, że początkowe wymagania zostaną i tak zmienione w trakcie projektu,
• (w tym miejscu możesz wpisać, dlaczego Twój zespół nie ustala precyzyjnie wymagań klienta na początku projektu),
• oraz wiele innych powodów...

Kolejnym wyzwaniem dla zespołów tworzących wymagania jest fakt, że w większości projektów wymagania ulegają większej lub mniejszej zmianie w trakcie pracy.
Aby przeciwdziałać tym, generującym ogromne koszty, przeszkodom opracowano już wiele metod i metodyk wspierających informatyków w zakresie zbierania i zarządzania wymaganiami. Kluczowe założenia, praktycznie wszystkich podejść, to:

1.Potwierdzanie treści wymagań przez zainteresowane strony. Czyli nie tylko analityk i użytkownik odpowiadają za treść wymagania, ale również mamy opinię sponsora projektu, programistów, testerów czy niezależnych konsultantów. Głównym celem tego założenia jest zapewnienie jednakowo rozumianej i akceptowanej potrzeby.

2.Powiązanie pojedynczego wymagania z innymi wymaganiami od niego zależnymi. Zapewnia to szansę poprawnego określenia zakresu zmiany, gdy taka się pojawi.

3.Określanie różnych atrybutów wymagań, nie tylko treści. Ułatwia to zarówno porównywanie wymagań jak i planowanie pracy w całym zakresie projektu.

4.Śledzenie stanu wymagania w trakcie całego procesu.

5.Powiązanie wymagań z innymi artefaktami projektowymi takimi jak: model, prototypy, kod aplikacji, przypadki testowe, aby łatwiej koordynować wysiłki przy poprawianiu aplikacji.

Spełnienie tych, dość oczywistych, założeń nie jest jednak w praktyce dużym wyzwaniem. Zacznijmy od punktu 1. Jak zapewnić, że właściwe osoby przeczytają i zaakceptują te wymagania, za które odpowiadają, jeśli przyjętym rozwiązaniem jest zapisanie wszystkich wymagań w jednym dokumencie? Taki dokument może mieć bardzo duże rozmiary, a praktyka mówi, że zapewnienie, iż wszyscy zainteresowani przeczytali uważnie cały dokument jest rzadko możliwe.
Pkt. 2, czyli informacja o powiązaniach między wymaganiami wymaga użycia innego sposobu niż tylko dokument. Często spotykane rozwiązanie to użycie w tym celu arkusza kalkulacyjnego. Niestety arkusz nie jest automatycznie związany z dokumentem, a synchronizacja zmian staje się newralgicznym elementem pracy, często stanowiącym wymówkę przed wprowadzeniem zmian na większą skalę.
Podobnie dla każdego innego postulatu znajdujemy różne wymówki, aby nie wypełniać ściśle jego zaleceń, chociaż wszyscy widzą korzyści płynące z przestrzegania postulatów.
Wspólną cechą tych wymówek jest to, że wypełnienie ich zajmuje mnóstwo cennego czasu, który może być poświęcony na bardziej produktywne zadania np. kodowanie (tylko czego, skoro nie wiemy, jakie są wymagania)
Sytuacja byłaby znacznie bardziej komfortowa, gdyby całą albo chociaż znaczącą część pracy, można było zautomatyzować i przerzucić na narzędzia.
Zanim jednak przyjrzymy się narzędziom, warto powiedzieć parę słów na temat procesu definiowania i zarządzania wymaganiami. Zwykle zakłada się, że jest to bardzo oczywiste i proste. Analityk „wyciąga” informacje od klienta (klientów, zleceniodawcy, sprawdza możliwości konkurencji), opisuje je w dokumencie (czasem uzupełnia diagramami różnego typu), zleceniobiorca sprawdza i potwierdza, że właśnie spełnienia takich oczekiwań się spodziewa, a dalej jest już prosto – deweloperzy budują rozwiązanie, testerzy sprawdzają i gotowe. Niestety taka prosta wizja nigdy tak łatwo nie działa. A to użytkownicy nie mają czasu na wywiady, a to zleceniodawca nie sprawdza wystarczająco dokładnie otrzymanego dokumentu, a to się okazuje, że na etapie dewelopmentu trzeba było pójść na jakiś kompromis z możliwościami sprzętu, natomiast testerzy skupiają się na testowaniu funkcjonalności aplikacji nie dbając o cele biznesowe. Do tego dochodzą nieporozumienia przy interpretacji zapisanych tekstów i mamy całkiem poważne kłopoty.
Ważne jest więc ustalenie konkretnego procesu powstawania wymagań i dokonywania w nich zmian uwzględniając występujące w organizacji problemy. Opracowany starannie proces musi być znany wszystkim jego uczestnikom, aby zapewnić możliwie szybką wymianę informacji w uzgodnionej przez proces postaci.
Jeśli takie opracowanie nie istnieje w firmie, lub też niedostatecznie uwzględnia problemy, jakie w organizacji się pojawiają można skorzystać z wieloletnich doświadczeń IBM Rational zebranych w propozycjach dobrych praktyk udokumentowanych w systemie Rational Method Composer. W RMC opisane są sprawdzone praktyki dotyczące całego procesu dostarczania oprogramowania, w tym oczywiście dotyczące zbierania i zarządzania wymaganiami.
Rysunek 1 pokazuje przykładowy opis z biblioteki opisujący jedną z ról w procesie definiowania wymagań. Biblioteka zawiera zarówno opisy procesów, ról, zalecanych narzędzi oraz innych elementów procesu, jak i gotowe do użycia wzory dokumentów.

Rysunek 1. Rola Analityka biznesowego opisana w Rational Method Composer

Narzędzia z rodziny Rational Requirements Definition and Mangment (RRDM) mogą pomóc w realizacji procesów i spełnieniu postulatów dotyczących zarządzania i definiowania wymagań obecnych w metodykach pracy zespołów deweloperskich. Aktualnie w rodzinie RRDM są trzy podstawowe narzędzia wspierające proces zarządzania wymaganiami:

• Rational Requirements Composer (RRC) –wsparcie dla definiowania wymagań,
• Rational RequistePro (RRP) –zarządzanie wymaganiami w projektach informatycznych dla małych i średniej wielkości zespołów,
• Rational Doors (Doors)– rozwiązanie do zarządzania wymaganiami w dowolnych projektach dla średnich i dużych zespołów.

Zadaniem RRC jest pomoc analitykom biznesowym i analitykom systemowym w uzyskaniu klarownej wizji potrzeb zleceniodawców i przekazanie tej wizji, w jednakowo interpretowanej formie do dalszego opracowania. RRC jest narzędziem stanowiącym pomost pomiędzy zleceniodawcami, a zespołem IT. Wymagania w RRC mogą być opisane w postaciach:

• Tekstowej – formatowany tekst może opisywać potrzeby zleceniodawców, może być pobierany z dokumentów w formacie .doc, .dot lub .rtf,

• Diagramów UseCase zgodnych z UML,

• Diagramów BPML,

• Tekstowych scenariuszy procesu biznesowego,

• Szkiców ekranu do dalszego opracowania,

• Przepływu informacji w ilustrowanego szkicami ekranów,
  a także zawiera szereg funkcjonalności wspierających pracę analityków, takich jak powiązania między artefaktami, słownik użytych pojęć i skrótów, mechanizmy zatwierdzenia pojedynczych wymagań, ustalenia typów zbieranych wymagań i struktury parametrów je opisujących, informowania zainteresowanych osób o zmianach wymagań lub innych artefaktów za pomocą emaili, tworzenia dokumentów z wymagań, przeszukiwania wg dowolnie wybranych parametrów czy możliwość dyskutowania w zespole treści wymagania (wyglądu ekranu, przebiegu procesu).
  Możliwe jest to dzięki temu, że RRC jest serwerem zapewniającym mechanizmy pracy zespołowej.
  Dzięki temu narzędziu znacznie łatwiejsze staje się spełnienie postulatów dotyczących zapewnienia jednakowego rozumienia wymagań (diagramy i rysunki ekranów znakomicie poprawiają ustalenie wspólnego punktu widzenia) czy potwierdzenia poprawności wymagań (zdecydowanie łatwiej jest wybrać istotne i możliwe od zatwierdzenia dla mnie wymagania, gdy nie muszę czytać całego dokumentu, a tylko te istotne dla mnie fragmenty), jak również określaniu dla każdego wymagania wybranych parametrów za pomocą ustalonego słownika czy ograniczonej skali wartości.
  Takie narzędzie jak Rational Requirements Composer z punktu widzenia zespołu IT jest znakomitym rozwiązaniem, gwarantującym powiązanie wymagań biznesowych z opisem technicznym różnych aspektów projektu od diagramów przypadków użycia po przypadki testowe. Przebieg opracowania wymagań może przykładowo może wyglądać następująco:

• Analityk biznesowy importuje do RRC dokument zawierający biznesową specyfikację wymagań.

• Analityk biznesowy wybiera w dokumencie akapity (zdania, miejsca) stanowiące podstawę do zdefiniowania formalnych wymagań biznesowych.

• Następnie wybrane fragmenty tekstu są poprawiane na drodze współpracy ze zleceniodawcą lub przyszłym użytkownikiem tak, aby stanowiły opis wymagania tj. nieprecyzyjne określenia (np. szybko, ergonomicznie, tanio) zamieniane są na dokładne informacje (np. poniżej 5 sek., projekt ekranu, kosztem nie większym niż 10gr.).

• Wymagania biznesowe parametryzujemy określając wymagane atrybuty np. priorytet realizacji, zakładany wpływ na działanie organizacji, zakładany koszt realizacji.

• Co najmniej dla wymagań o najwyższym priorytecie (a jeśli to możliwe również dla każdego innego) definiujemy ryzyka projektowe, które trzeba wziąć pod uwagę w trakcie dalszych prac.

• Kolejny krok to określenie dla każdego wymagania biznesowego wymagań funkcjonalnych dla tworzonego rozwiązania, z zapewnieniem, że każde wymaganie biznesowe ma zaplanowany sposób realizacji lub informację, potwierdzoną przez zleceniodawcę, o rezygnacji z implementacji w tej wersji systemu.

Przy tym na każdym z etapów trzeba zadbać m.in. o utrzymywanie wspólnego słownictwa, potwierdzenie interesariuszy, że zapisy są zgodne z ich rozumieniem, zachowanie powiązań pomiędzy powstającymi artefaktami, ilustrowanie potrzebnych elementów formalnymi diagramami i wiele, wiele innych czynności.
Wykorzystanie standardowych procedur i wsparcie narzędzia pozwala wszystkie wcześniej wymienione postulaty zrealizować w praktyce. Ilustracja powiązań wymagania z różnego rodzaju artefaktami jest pokazana na Rysunek 2.

Rysunek 2. Powiązanie wymagań z innymi elementami opisu ułatwia zachowane spójności danych

Po kilku iteracjach analizy, gdy znaczna część wymagań spełnia już postulaty (przynajmniej częściowo) warto jest rozpocząć kolejne fazy projektu: projektowanie, programowanie i testy. W zależności od rodzaju aplikacji przygotowujemy w oparciu o wymagania formalny projekt albo zaczynamy tworzyć prototyp czy wybieramy jeszcze inną ścieżkę do budowy rozwiązania. Dobrze jest zagwarantować odrobinę stabilności każdej z zainteresowanych stron, czyli zapewnienie, że przekazane do dalszych prac wymagania nie będą natychmiast gruntownie zmieniane, a co najmniej, do tych jeszcze niepewnych wymagań określimy dodatkowe ryzyka. Dobrym rozwiązaniem jest stworzenie linii bazowej wymagań, na której będą się opierały dalsze prace czy przekazanie wymagań do systemu zarządzania wymaganiami takiego jak Rational RequisitePro (RRP) czy Rational Doors (Doors). Takie rozwiązanie zapewnia komfort pracy zarówno analitykom, gdyż mogą swobodnie zmieniać wymagania w swojej linii czy bazie, jak i wykonawcom, którzy mają do dyspozycji ustaloną w danym czasie wersję.

Główne zadania związane z zarządzaniem wymaganiami, jakie na siebie przejmują narzędzia to:

• Dbanie o określenie statutu poszczególnych wymagań,
• Zapewnienie dostępu wszystkim zainteresowanym do aktualnie opracowywanej wersji wymagań,
• Informowanie o zmianach, zarówno treści, jaki i wybranych atrybutów wymagań zainteresowanych danym wymaganiem czy rodzajem zmiany osób,
• Raportowanie w czasie rzeczywistym zmian stanu wymagań,
• Wersjonowanie wymagań w miarę dokonywanych zmian.

Dodatkowymi zadaniami, bardzo pomocnymi w trakcie prac są:

• Wizualizacja powiązań,
• Dostęp do wersji wymagań,
• Zapewnienie forum dyskusyjnego na temat konkretnych wymagań, tak, aby wszelkie ustalenia i potencjalne głosy były zgromadzone w jednym, łatwo dostępnym miejscu
• Łączenie wymagań z konkretnymi artefaktami projektowymi jak model, elementy modelu, kod źródłowy, przypadki testowe,
• Generowanie szkieletów artefaktów projektowych z treści wymagań np. przypadków użycia, przypadków testowych,
• Identyfikacja osób odpowiedzialnych w danym czasie za wymaganie, a także związanych w innym sposób z danym wymaganiem.

Istnienie i sprawne działanie dobrego procesu zarządzania wymaganiami zapewnia skrócenie czasu trwania projektów, a tym samym obniżenie kosztów poprzez zmniejszenie liczby iteracji, zdecydowanie poprawia zadowolenie odbiorców gdyż zachowane są ich priorytety, poprawia jakość zarówno produktu jak i pracy w zespole.

Zbigniew Zarzycki, Rational Specialist, IBM Polska