W niniejszym rozdziale przedstawiamy kilka często stosowanych metodyk wytwarzania oprogramowania. Nasze rozważania oprzemy na definicji metodyki jako usystematyzowanym i zorganizowanym zbiorze technik objętych cyklem wytwórczym, którego produkty wyrażone są za pomocą odpowiedniej notacji. Warto jednak zauważyć, że sam opis metodyki nie stanowi metodyki jako takiej. Metodykę należy bowiem w odpowiedni sposób wdrożyć w organizacji wytwarzającej oprogramowanie oraz w konkretnym projekcie. Działania te obejmują wiele różnych aspektów, takich jak szkolenia, mentoring, wybór i instalacja narzędzi czy tworzenie odpowiedniej kultury pracy. Szczegółowe omówienie procesu wdrażania metodyki wykracza jednak poza zakres niniejszego podręcznika.

Wśród wielu istniejących i stosowanych metodyk, można wyróżnić dwie główne grupy: metodyki formalne i agilne (zwinne, ang. agile). To, która metodyka zostanie wybrana i które jej elementy będą kluczowe dla danego przedsięwzięcia, zależy od specyfiki danego projektu. Przegląd głównych cech obu grup metodyk, umożliwi zrozumienie idei stosowania metodyk agilnych i formalnych. Pozwoli to także poznać cechy wspólne i rozłączne obu grup. Warto jednak zauważyć, że większość współcześnie stosowanych metodyk stosuje cykl iteracyjny.

3.1. Co to jest metodyka wytwarzania oprogramowania?

W rozdziale 1 metodyka została przedstawiona jako połączenie trzech elementów: procesu technicznego, notacji oraz technik. W praktyce, zespoły projektowe potrzebują konkretnych wytycznych, które odpowiadają na podstawowe pytanie „jak należy to zrobić?”. Zespół powinien widzieć co należy wykonać, w jaki sposób oraz kto powinien za co odpowiadać. Opis metodyki zazwyczaj zawiera zatem pięć elementów: opis ról, opis czynności, opis produktów pracy, podział na dyscypliny oraz określenie cyklu życia (zazwyczaj ograniczonego do cyklu wytwórczego). Elementy te zostały zilustrowane na rysunku 3.1.

Rysunek 3.1: Elementy opisu metodyki

Większość metodyk definiuje role, które stanowią abstrakcyjne definicje pewnego zakresu obowiązków (zbioru czynności) wymagających odpowiedniego zakresu kwalifikacji. Role są wypełniane przez wyznaczone osoby lub grupy współpracujących ze sobą osób. Rola może być zatem wypełniana przez kilka (wiele) osób w ramach jednego projektu. Jednocześnie, każdy członek zespołu projektowego może pełnić kilka (wiele) różnych ról. Można powiedzieć, że osoba pełniąca w danej chwili konkretną rolę zakłada odpowiednią „czapkę”, którą zamienia na inną, kiedy wykonuje czynności kolejnej roli.

Role są odpowiedzialne za wykonywanie produktów pracy. Produkty pracy stanowią ostateczne lub pośrednie wyniki działań w projekcie, wykorzystywane do podejmowania innych działań. Produktem pracy może być dokument (np. wizja systemu, plan iteracji), model (np. model klas, model komponentów), element modelu (np. klasa, komponent), kod (np. pakiet lub klasa) lub element montażowy (np. plik bazy danych, plik wykonywalny). W celu lepszego zarządzania projektem, produkty pracy oraz wykonujące je role przydzielamy do dyscyplin. Należy podkreślić, że różne metodyki w różnym stopniu precyzują produkty pracy.  Niezależnie jednak od rodzaju metodyki, każdy dobrze zorganizowany projekt powinien posiadać określone ramy do tworzenia produktów.

Ważnym elementem definicji produktów pracy jest notacja używana do ich wytworzenia. Przyjęcie jednolitej notacji jest bardzo istotnym elementem zapewnienia jakości wykonywanych produktów. Umożliwia to łatwiejszą pracę w zespole, wspomaga kreatywność oraz ułatwia porozumienie między różnymi zespołami, częstokroć rozproszonymi geograficznie. Produkty pracy tworzymy używając narzędzi dostosowanych do używanej notacji. Kod oraz elementy montażowe tworzymy w zintegrowanych środowiskach deweloperskich (IDE, ang. Integrated Development Environment) oraz systemach zarządzania wersjami. Modele tworzymy w narzędziach wspierających modelowanie oprogramowania (ang. CASE, Computer Aided Software Engineering). Różnego rodzaju dokumenty i plany tworzymy w narzędziach do edycji tekstu oraz w dedykowanych środowiskach do organizowania pracy w projekcie (często zintegrowanych z narzędziami do zarządzania i wersjonowania kodu). Wiele współczesnych narzędzi funkcjonuje w środowisku chmurowym. W ten sposób możliwa jest praca grupowa w zespołach rozproszonych z możliwością pracy zdalnej.

Produkty pracy są wynikiem czynności wykonywanych przez role.  Czynności definiują zakres zadań dla odpowiednich ról w projekcie. Czynności korzystają z oraz tworzą produkty pracy. Opis czynności może zawierać różnego rodzaju wskazówki, techniki i instrukcje korzystania z narzędzi. W ramach konkretnej metodyki, czynności są wykonywane w ramach zadanego cyklu życia. Czasami definiowany jest odpowiedni proces w postaci diagramu pokazującego przepływ czynności w ramach np. pojedynczej iteracji.

3.2. Metodyki zwinne (agile)

Metodyki zwinne bazują na manifeście zwinności przedstawionym w rozdziale 1 („Wprowadzenie do inżynierii oprogramowania”). Wynikają z tego podstawowe cechy metodyk zwinnych: iteracyjność oraz koncentracja na technikach organizacji zespołu i współpracy z klientem. Bardzo istotną zasadą metodyk zwinnych jest częste dostarczanie działającego oprogramowania. Odbywa się to w stosunkowo krótkich cyklach (iteracjach) o jednakowej długości, trwających od około 2 tygodni do około 2 miesięcy. Przy tym, preferowane są cykle krótsze, np. od 1 tygodnia do 1 miesiąca. Dzięki temu na pierwszy plan wysuwa się zasada zapewnienia maksymalnej satysfakcji klienta. Klient ma możliwość ciągłej (w cyklach kilkutygodniowych) weryfikacji spełnienia swoich wymagań w stosunku do budowanego systemu. Klient jest również zachęcany do zgłaszania zmian, nawet na późnym etapie projektu. Dzięki takiemu podejściu zwiększana jest szansa na powstanie systemu dostosowanego do rzeczywistych potrzeb zamawiającego oraz o cechach innowacyjnych, zwiększających przewagę konkurencyjną.

Główną miarą postępu w podejściach zwinnych jest działające oprogramowanie. Mierzone są przede wszystkim jednostki funkcjonalności, które zostały w pełni zrealizowane i zaakceptowane przez klienta. Jednocześnie, dużą wagę przykłada się do zrównoważonego rozwoju oprogramowania. Tempo prac powinno być stałe, o co powinni dbać wszyscy uczestnicy projektu – deweloperzy, reprezentanci zamawiającego, a przede wszystkim – sponsorzy. Koncentracja na systematycznym dostarczaniu działającego systemu (działającego kodu) nie oznacza jednak braku działań w obszarze projektowania oprogramowania. Metodyki zwinne podkreślają, że dobrze zorganizowany zespół w naturalny sposób dąży do tworzenia dobrze zaprojektowanych systemów. Taki zespół ciągle zwraca uwagę na doskonałość techniczną, co przejawia się kładzeniem nacisku na tworzenie projektów architektonicznych oprogramowania. Takie projekty są ciągle doskonalone, czemu sprzyja ciągła kontrola jakości oraz ciągły pomiar efektywności prac deweloperskich. Jednocześnie, nacisk położony jest na tworzenie jak najprostszych rozwiązań technicznych, redukujących ilość pracy związanej z implementacją systemu.

Istnieje wiele metodyk zwinnych. Z najważniejszych warto wymienić Scrum, Extreme Programming. Metodyka Scrum została opracowana przez Kena Schwabera i Jeffa Sunderlanda w okolicach roku 1995. Oficjalna definicja metodyki („Przewodnik po Scrumie”) jest bardzo zwięzła. Doczekała się ona kilku aktualizacji (ostatnia w 2020 roku). W podobnym czasie co Scrum została również opracowana metodyka Extreme Programming (XP). Głównym twórcą tej metodyki jest Kent Beck, który w 1999 roku opublikował pierwszą książkę opisującą jej reguły. Nieoficjalną specyfikację metodyki XP można znaleźć na stronie extremeprogramming.org. Również w połowie lat 1990 powstała metodyka Crystal, stworzona przez Alistaira Cockburna. Ważną cechą tej metodyki (a właściwie – rodziny metodyk) jest skalowalność – kolejne „poziomy” metodyki są dostosowane do coraz większych zespołów, realizujących coraz większe systemy oprogramowania. Wraz ze wzrostem złożoności zespołu rośnie również poziom formalizacji wykonywanych w ramach metodyki czynności.

Aby przybliżyć zasady rządzące metodykami zwinnymi opiszemy bliżej metodyki – Scrum. Rysunek 3.2 przedstawia cykl wytwórczy oraz podstawowe produkty metodyki Scrum („młyn”, nazwa pochodzi z terminologii gry w rugby). Pojedyncza iteracja (tzw. sprint) trwa zazwyczaj kilka (1-4) tygodni. W ramach sprintu postęp prac kontrolowany jest codziennie. Główną techniką kontroli postępów jest tzw. codzienne spotkanie młyna. Na początku sprintu definiowany jest tzw. rejestr sprintu (ang. Sprint Backlog), który jest na bieżąco aktualizowany i służy do kontroli wykonania zaplanowanych zadań. Efektem każdego sprintu jest przyrost produktu (ang. Product Increment), który może być w określonym zakresie używany przez klienta. Kolejne sprinty (a tym samym – przyrosty systemu) planowane są w ramach tzw. rejestru produktowego (ang. Product Backlog).

Rysunek 3.2: Cykl wytwórczy metodyki Scrum

Rysunek 3.3 pokazuje podstawowe role, produkty pracy i czynności metodyki Scrum. Jak można zauważyć, zakres definicji metodyki jest dosyć ograniczony i głównie koncentruje się na organizacji pracy zespołu deweloperskiego oraz planowaniu zadań. Metodyka definiuje 3 role – mistrz młyna (ang. Scrum Master), właściciel produktu (ang. Product Owner) oraz zespół deweloperski. Cały zespół w projekcie prowadzonym metodyką Scrum powinien liczyć kilka osób (do około 10). W jego skład wchodzi jeden mistrz młyna i jeden właściciel produktu. Metodyka nie wyróżnia bardziej szczegółowych ról w ramach zespołu deweloperskiego.

Rysunek 3.3: Role w metodyce Scrum

Zespół deweloperski powinien składać się z osób o różnych, uzupełniających się kompetencjach. Metodyka nie określa tych kompetencji, ale można uznać, że są to typowe kompetencje obejmujące wszystkie dyscypliny techniczne inżynierii oprogramowania (wymagania, projektowanie, implementacja, testowanie, wdrożenie). Zespół powinien sam się organizować i Scrum nie narzuca żadnych konkretnych ram organizacyjnych zespołu. Podstawowym celem zespołu jest zapewnienie odpowiedniej jakości kolejnych przyrostów produktu (włącznie z przyrostem końcowym). Podstawowe czynności wykonywane przez zespół deweloperski to zaplanowanie sprintu oraz wykonanie sprintu.

Planowanie sprintu polega na ustaleniu celu sprintu oraz szczegółowej listy zadań do wykonania w ramach sprintu, przydzielenie tych zadań do wykonania członkom zespołu oraz określenie harmonogramu ich wykonania. Rezultatem planowania sprintu jest rejestr sprintu. Rejestr ten stanowi ciągle aktualizowaną „tablicę” z zadaniami do wykonania oraz ich statusem. Zadania są definiowane w sposób szczegółowy i powinny dotyczyć wszystkich dyscyplin inżynierii oprogramowania (od wymagań do wdrożenia). Zadania powinny prowadzić do wykonania celu sprintu, czyli do zbioru cech produktu, które powinny zostać zrealizowane w ramach sprintu. Cechy produktu są wybierane do wykonania z rejestru produktowego, który omawiamy niżej.

Należy podkreślić, że planowanie sprintu jest czynnością ciągłą. Rejestr sprintu jest aktualizowany na bieżąco w miarę dokonywania oceny postępów prac. Istotnym narzędziem do kontroli postępów jest tzw. wykres spalania sprintu (ang. Sprint Burndown Chart). Wykres ten pokazuje w sposób graficzny liczbę zadań pozostających do wykonania. W ten sposób, zespół na bieżąco może śledzić tempo prac i oceniać możliwość ich wykonania w ramach sprintu.

O ile rejestr sprintu służy do planowania jednej iteracji, o tyle rejestr produktu służy do planowania całego projektu. Za rejestr produktu odpowiada właściciel produktu. Określa on cechy produktu, ustala ich priorytety, a także planuje wydania (przyrosty produktu gotowe do użycia przez klienta w rzeczywistym środowisku). Metodyka Scrum nie definiuje w sposób jednoznaczny, czym są cechy produktu. Często przyjmuje się, że cechami produktu są historie użytkownika (ang. User Story), które są elementem metodyki Extreme Programming. Cechami produktu mogą też być przypadki użycia pochodzące z metodyki Unified Process (RUP i OpenUP). O historiach użytkownika oraz przypadkach użycia mówimy w rozdziale 8, a także sekcji 6.1. Ogólnie, przyjmuje się, że sprinty w metodyce Scrum powinny być sterowane cechami, które odpowiadają wymaganiom funkcjonalnym (funkcjonalności systemu). Cechami uzupełniającymi są cechy jakościowe (np. niezawodność, wydajność, użyteczność). Należy jednak podkreślić, że cechy jakościowe zazwyczaj przebiegają przez cały produkt (system oprogramowania), zatem nie jest możliwe przydzielenie ich realizacji do konkretnej iteracji (sprintu).

Ciekawą techniką służącą do szacowania pracochłonności i przydziału cech produktu do danego sprintu jest tzw. poker scrumowy (ang. Scrum Poker). Technika ta polega na dokonaniu wyceny cech systemu w formie sesji pracy grupowej. Zespół deweloperski wstępnie wybiera zestaw cech do oceny. Następnie, stosowany jest specjalny zestaw kart. Karty w zestawie posiadają odpowiednie liczby, które odpowiadają pracochłonności wykonania danej cechy. Często stosowane są ciągi liczbowe, które nie są liniowe (np. ciąg Fibonacciego – 1, 2, 3, 5, 8, 13, 21, 34, 55, …). Wynika to potrzeby podkreślenia, że liczby są szacunkowe, szczególnie podczas określania pracochłonności wykonania dla bardziej złożonych cech systemu. Podczas sesji pokera scrumowego, poszczególni członkowie zespołu deweloperskiego dokonują szacowania pracochłonności danej cechy poprzez wybranie jednej z kart. Następnie karty są jednocześnie odkrywane i odbywa się dyskusja. W trakcie dyskusji oceniane są wartości skrajne i podejmowana decyzja w drodze konsensusu. Efektem pokera scrumowego jest zestaw cech systemu z przypisanymi punktami. Na podstawie liczby punktów i wcześniejszych doświadczeń, zespół wybiera cechy, które jest w stanie zrealizować w kolejnej iteracji (sprincie).

Przedstawione powyżej czynności związane z planowaniem i wykonywaniem sprintów uzupełniają czynności dotyczące zapewnienia jakości. Właściciel produktu specyfikuje testy akceptacyjne, które mają na celu zdefiniowanie kryteriów ukończenia sprintu. Zapewnienie jakości produktu przez zespół deweloperski jest oparte na dążeniu do zakończenia wszystkich testów akceptacyjnych w sposób pozytywny. Innym sposobem zapewnienia jakości systemu przez zespół jest dokonywanie refaktoryzacji (ang. refactoring) kodu. Czynność ta pochodzi z metodyki Extreme Programming i ma na celu poprawę jakości struktury kodu, a przez to również – serwisowalności całego systemu.

Rolą kluczową w zapewnieniu jakości jest mistrz młyna. Jego zadaniem jest pomoc zespołowi w przestrzeganiu reguł metodyki. Mistrz młyna powinien stwarzać zespołowi warunki odpowiednie do poprawy efektywności pracy oraz poprawy jakości budowanego systemu. Mistrz młyna uczestniczy we wszystkich czynnościach zespołu deweloperskiego i właściciela produktu. Pomaga w stosowaniu odpowiednich technik pracy z zespole, planowaniu sprintów oraz całego projektu.

Istotnymi czynnościami zapewnienia jakości pracy zespołu są spotkanie młyna oraz dokonanie retrospektywy. Spotkanie młyna powinno się odbywać codziennie. Jego celem jest przedstawienie postępu prac w dniu poprzednim oraz planów na dzień bieżący. Takie codzienne spotkanie umożliwia lepszą identyfikację problemów bieżących oraz umożliwia ciągłą ocenę tempa prac poszczególnych deweloperów. Co ważne, spotkanie powinno odbywać się na stojąco i trwać nie więcej niż kilkanaście minut. Podczas spotkania młyna nie dyskutuje się rozwiązań, a jedynie przedstawia problemy i ustala zadania do wykonania. Formuła szybkiego spotkania na stojąco ma sprzyjać zwięzłości wypowiedzi i podejmowaniu konkretnych decyzji.

Rozwinięciem codziennych spotkań młyna są spotkania retrospektywy. Spotkania takie organizuje się na koniec każdego sprintu. Ich celem jest ustalenie problemów w funkcjonowaniu zespołu w ramach danego projektu oraz wypracowanie rozwiązań. Członkowie zespołu wspólnie z mistrzem młyna zastanawiają się jakie elementy procesu wytwórczego działają prawidłowo, a jakie sprawiają problemy. W efekcie zespół podejmuje decyzje dotyczące tego, jakich czynności należy zaprzestać, jakie czynności należy zacząć wykonywać, a jakie kontynuować bez zmian lub z odpowiednimi zmianami.

Oprócz retrospektywy, na koniec każdego sprintu dokonuje się oceny sprintu. Podczas takiego spotkania zespół przedstawia postęp prac – co zostało osiągnięte w trakcie ostatnich kilku tygodni projektu. Często, taka ocena polega na przeprowadzeniu demonstracji nowych funkcjonalności budowanego systemu. Kluczowa jest tutaj obecność właściciela produktu, który jest w stanie ocenić jakość produktu (oprogramowania) z punktu widzenia potrzeb zamawiającego. Ocena sprintu dokonywana jest na podstawie oceny realizacji celów danego sprintu. W szczególności, oceniane jest spełnienie realizacji cech systemu przydzielonych do danego sprintu w rejestrze sprintu. Ważne jest, aby spotkanie oceny sprintu nie było zbytnio sformalizowane. Nie powinno ono odciągać zespołu od podstawowych działań deweloperskich., a jedynie umożliwić szybką ocenę postępów prac w projekcie oraz ocenę jakości dotychczas zbudowanego systemu z punktu widzenia jego przyszłych użytkowników.

3.3. Metodyki sformalizowane

Metodyki zwinne sprawdzają się w projektach realizowanych przez nieduże zespoły oraz realizowanych dla klientów akceptujących zasady zwinności. W szczególności, metodyki zwinne trudno jest stosować w projektach zamawianych przez instytucje stosujące formalne zasady zamawiania oprogramowania. W takiej sytuacji zalecane lub wręcz konieczne jest zastosowanie metodyki sformalizowanej.

W niniejszej sekcji skoncentrujemy się na przedstawieniu dwóch, bodaj najpopularniejszych metodyk sformalizowanych. Obydwie pochodzą z tej samej rodziny tzw. procesów zunifikowanych (ang. Unified Process). Oryginalną metodyką jest metodyka Rational Unified Process (RUP), opracowana przez firmę Rational, a następnie przejęta przez firmę IBM.

RUP jest metodyką bardzo obszerną i możliwą do zastosowania w bardzo szerokim zakresie dziedzin oraz rozmiarów projektów.

Cykl wytwórczy metodyki OpenUP przedstawia rysunek 3.4. Jak widać, jest on bardzo podobny do cykli wytwórczych metodyk Scrum i XP. Podstawową jednostką planowania w projekcie jest iteracja. Projekt dzielimy na kilka-kilkanaście iteracji trwających po kilka tygodni. Podział na iteracje dokumentowany jest w postaci planu projektu. Dodatkowo, wyróżniane są fazy projektu, które odpowiednio profilują (rozróżniają) przebieg iteracji w zależności od czasu. OpenUP (oraz RUP) wyróżnia cztery fazy: Rozpoczęcie (ang. Inception), Wypracowanie (ang. Elaboration), Konstrukcja (ang. Construction) oraz Przejście (ang. transition). Należy jednak podkreślić, że iteracje w metodyce OpenUP spełniają podstawową definicję iteracji. Każda iteracja kończy się wykonywalną wersją systemu (ang. Build). Wersja stanowi częściowy lub ostateczny produkt, który oddajemy klientowi do oceny. W ramach iteracji poszczególne role wykonują zadania, których rezultatem jest powstanie produktów pracy. Co kilka dni oddawany jest kolejny przyrost (ang. Increment) systemu, czyli zintegrowany i zainstalowany w środowisku testowym system. Harmonogram działań w ramach iteracji określa plan iteracji.

Rysunek 3.4: Cykl wytwórczy metodyki Open Unified Process

Podział projektu na cztery fazy jest cechą charakterystyczną metodyk zunifikowanych (RUP, OpenUP). Każda faza składa się z jednej lub kilku iteracji. Rezultatem fazy rozpoczęcia powinien być zdefiniowany zakres funkcjonalny systemu, czyli nacisk położony jest na działania w dyscyplinie wymagań. Przy tym, w fazie tej wykonywane są również czynności projektowe, implementacyjne i testowe. Efektem jest wstępnie zaimplementowana pierwsza – bardzo jeszcze niepełna funkcjonalnie – wersja systemu. Faza rozpoczęcia najczęściej składa się z jednej iteracji. W fazie wypracowania następuje stabilizacja („wypracowanie”) architektury systemu. Odbywa się to poprzez położenie nacisku na czynności projektowe (architektoniczne) i weryfikację rozwiązań projektowych poprzez implementację kolejnych wersji systemu. Faza wypracowania trwa najczęściej od jednej do trzech iteracji.

Faza konstrukcji jest zazwyczaj najdłuższa i składa się najczęściej z 3-7 iteracji. Przed rozpoczęciem fazy konstrukcji powinny być już rozwiązane najważniejsze problemy techniczne. W ramach tej fazy w kolejnych iteracjach powstają wersje systemu uzupełniane o kolejne przyrosty funkcjonalności. Iteracje fazy konstrukcji kładą nacisk na implementację systemu, jednak cały czas wykonywane są czynności w obszarach wymagań, projektowania, testowania oraz wdrożenia. Projekt kończy faza przejścia. W ramach tej fazy dokonywane jest uzupełnienie funkcjonalności systemu będące wynikiem ewentualnych zmian zgłaszanych przez klienta. W tej fazie szczególny nacisk położony jest na czynności w obszarze wdrożenia (instalacja produkcyjna, dokumentowanie, szkolenia). Mimo to, również ta faza zawiera czynności pozostałych obszarów, łącznie z implementacją i testowaniem, i kończy się kolejną – już ostateczną – wersją systemu. Rysunek 3.4 pokazuje również dwa wykresy opisujące profil ryzyka i profil wartości systemu. Profile te są charakterystyczne dla większości metodyk iteracyjnych.

Projekty prowadzone metodykami OpenUP i RUP są sterowane jednostkami funkcjonalności nazywanymi przypadkami użycia (ang. Use Case) systemu. Model przypadków użycia jest głównym produktem roli Analityka (patrz rysunek 3.9). Rola przypadku użycia jest podobna do roli historii użytkownika w metodyce XP. Planowanie strategiczne projektu odbywa się poprzez zarządzanie modelem przypadków użycia i poprzez przydział przypadków użycia do poszczególnych iteracji. Podobnie jak historia użytkownika, przypadek użycia stanowi nieduży, lecz kompletny fragment funkcjonalności systemu, stanowiący określoną wartość (biznesową) dla jego użytkownika.

Rysunek 3.5: Role podstawowe w metodyce Open Unified Process (1)

Metodyka OpenUP definiuje trzy grupy ról: role podstawowe, role wdrożeniowe oraz role pomocnicze (środowiska). W opisie metodyki pominiemy szczegółowy opis ról wdrożeniowych. Ogólnie, dotyczą one działań związanych z instalacją systemu w środowisku produkcyjnym, przygotowaniem dokumentacji dla klienta oraz szkoleń. Istotną rolą w tej grupie jest rola właściciela produktu, czyli reprezentanta klienta. Jest ona analogiczna do podobnej roli w metodyce Scrum.

Role podstawowe w metodyce OpenUP zostały przedstawione na rysunkach 3.5 i 3.6. Dodatkowo, wśród ról podstawowych wyróżnia się rolę Udziałowca (ang. Stakeholder) oraz tzw. Dowolna Rolę (ang. Any Role). Reprezentują oni osoby zainteresowane wynikami projektu i mogące uczestniczyć w większości działań z obszaru wymagań i projektowania oraz wszystkie osoby zgłaszające zmiany (np. zmiany wymagań).

Analityk (patrz rysunek 3.5) odpowiada za pięć produktów. Składają się one na pełną specyfikację wymagań budowanego systemu. Najbardziej ogólnym produktem jest wizja (ang. Vision), która opisuje cechy systemu bezpośrednio wynikające z potrzeb biznesowych klienta. Model przypadków użycia wykorzystuje graficzną notację języka UML. Zawiera on specyfikację przypadków użycia, aktorów (użytkowników i systemów zewnętrznych) oraz relacje między nimi. Każdy przypadek użycia opisywany jest w sposób szczegółowy poprzez definicję jego scenariuszy oraz scenopisów (opisów interfejsu użytkownika). Dodatkowo, tworzone są wymagania systemowe, które definiują cechy jakościowe, które najczęściej przebiegają przez cały system (np. użyteczność, wydajność, niezawodność). Dla wszystkich wymagań tworzony jest słownik (ang. Glossary), który ma na celu uchwycenie terminologii dziedziny problemu oraz lepsze porozumienie w zespole deweloperskim oraz z klientem.

Deweloper (patrz rysunek 3.5) w metodyce OpenUP łączy funkcje projektanta i programisty. Współpracuje on ściśle z Architektem, którego zakres obowiązków jest przedstawiony na rysunku 3.6. Podstawowym produktem pracy, opisującym całość systemu jest architektura techniczna. Definiuje ona m.in. podział systemu na komponenty, interfejsy między komponentami, przydział komponentów do konkretnych jednostek wykonawczych (architektura fizyczna) oraz przedstawia decyzje dotyczące stosowanych technologii (języków, bibliotek, platform programistycznych). Architekt współpracuje z projektantami, przydzielając im konkretne komponenty (podsystemy). Bazując na ogólnych decyzjach architektonicznych, projektanci opracowują szczegółowe plany dla poszczególnych komponentów systemu. Efektem jest powstanie projektu (ang. Design) systemu. Projekt zawiera definicję struktury komponentów (np. definicje klas, interfejsów) oraz dynamiki ich działania (np. opis dynamiki współpracy między obiektami).

Rysunek 3.6: Role podstawowe w metodyce Open Unified Process (2)

Deweloper odpowiada również za trzy produkty pracy z obszaru implementacji: Implementacja, Przyrost oraz Test deweloperski. Pierwszy z nich zawiera kod źródłowy oraz różne pliki pomocnicze (np. skrypty budujące przyrost). Drugi produkt to wykonywalna wersja systemu. Jest to główny produkt każdego projektu. Przyrost powinien być gotowy do zainstalowania w środowisku wykonawczym w celu przeprowadzenia testów akceptacyjnych przez testera. Test developerski odpowiada testowi jednostkowemu, który został omówiony w ramach opisu metodyki XP.

Na rysunku 3.6 przedstawiono również role Testera i Kierownika Projektu. Tester ma bardzo podobny zakres obowiązków, co tester w metodyce XP, zatem pominiemy tutaj jego szczegółowy opis. Kierownik projektu jest rolą wyraźnie wskazującą na bardziej tradycyjne podejście metodyki OpenUP do procesu wytwarzania oprogramowania. Jest to typowa rola zarządcza, która nie występuje w metodykach zwinnych w sposób jawny. Kierownik tworzy plan projektu oraz plany iteracji.

Role podstawowe uzupełniają role pomocnicze, dotyczące zarządzania środowiskiem pracy zespołu (patrz rysunek 3.7). Inżynier procesu spełnia rolę podobną do mistrza młyna w metodyce Scrum lub trenera w metodyce XP. Jego zakres obowiązków obejmuje wspieranie zespołu w dostosowywaniu metodyki OpenUP do rzeczywistych warunków w projekcie oraz w organizacji wytwarzającej oprogramowanie, a także wdrażanie metodyki do praktyki. Specjalista narzędziowiec wspiera zespół w instalacji oraz konfiguracji narzędzi (środowisko deweloperskie, narzędzia CASE, narzędzia do testowania itd.). Jego udział w projekcie jest kluczowy w pierwszych iteracjach, a potem polega na ciągłym administrowaniu narzędziami i zapewnianiu ich sprawnego użytkowania przez zespół.

Rysunek 3.7: Role pomocnicze (środowiska) w metodyce Open Unified Process