1.1. Co to jest inżynieria oprogramowania?

Inżynieria oprogramowania zajmuje się inżynierskim podejściem do tworzenia oprogramowania. Inżynieria oprogramowania dąży do ujęcia działań związanych z budową programów komputerowych w ramy typowe dla innych dziedzin inżynierii. W szczególności, inżynieria oprogramowania stosuje wiedzę naukową, techniczną oraz doświadczenie w celu projektowania, implementacji, walidacji i dokumentowania oprogramowania. Inżynierię oprogramowania można podzielić na kilka zasadniczych dyscyplin. Dyscypliny te związane są z typowymi etapami działań inżynierskich w dowolnej dziedzinie inżynierii.

Dyscyplina 1: Wymagania

Systemy informatyczne realizują coraz bardziej złożoną funkcjonalność dla coraz większej liczby grup użytkowników. Stąd też bardzo istotne jest uzyskanie od tychże użytkowników (jak również od innych grup zainteresowanych systemem) wszystkich niezbędnych informacji dotyczących ich potrzeb.

Dyscyplina 2: Projektowanie

System oprogramowania wymaga projektu. Niezbędne jest określenie przez architektów, z jakich składników będzie się składał system.

Dyscyplina 3: Implementacja

Wykonanie (implementacja) systemu oprogramowania wymaga zachowania zgodności z projektem. System oprogramowania konstruowany jest poprzez pisanie programów w odpowiednich językach programowania. W zachowaniu zgodności z projektem mogą pomóc odpowiednie metody przekształcania projektu w kod systemu.

Dyscyplina 4: Walidacja

W przypadku systemów oprogramowania, wykrycie usterek jest bardzo złożonym problemem. Wynika to przede wszystkim ze złożoności i zmienności wymagań oraz złożoności systemów. Przede wszystkim należy sprawdzić, czy system został zbudowany zgodnie z potrzebami klienta i użytkowników. Należy podkreślić, że walidacja nie powinna być wykonywana dopiero po zakończeniu implementacji. Należy ją przeprowadzać jak najwcześniej, w celu zmniejszenia ryzyka niepowodzenia.

Dyscyplina 5: Nadzór

W trakcie budowy systemu oprogramowania też bardzo istotne jest przestrzeganie pewnych procedur i reguł postępowania. W tym celu zostały opracowane odpowiednie standardowe metodyki. Odejście od przestrzegania (lub po prostu brak) metodyk jest bardzo częstą przyczyną niepowodzeń projektów, w które wkrada się chaos organizacyjny.

Dyscyplina 6: Środowisko pracy.

Budując system oprogramowania powinniśmy bardzo uważnie podejść do budowy środowiska pracy. Bardzo istotny jest wybór narzędzi wspomagających projektowanie systemu. Podczas budowy systemu, niezbędne jest posiadanie narzędzi umożliwiających zarządzanie złożonym kodem (dobre środowisko zintegrowane oraz narzędzia do zarządzania konfiguracją i zmianami). Dobrze dobrane środowisko pracy ułatwia również rozbudowę systemu (tzw. ewolucja systemu).

1.2. Podstawowe problemy inżynierii oprogramowania

Typowe współczesne systemy oprogramowania składają się z setek tysięcy lub nawet milionów wierszy kodu w różnych językach programowania. Jest oczywiste, że takiej liczby elementów nie jest w stanie opanować nawet najbardziej uzdolniony programista. Konieczne jest zatem zastosowanie metod opanowania tej złożoności.

Złożoność i różnorodność systemów oprogramowania rodzi wiele problemów, które trapią projekty konstrukcji takich systemów. Różnorodne problemy dotykające współczesne systemy oprogramowania prowadzą do wielu niepowodzeń w budowie tychże systemów.  Z punktu widzenia uczestników projektu budowy oprogramowania można wyróżnić trzy kryteria warunkujące powodzenie. Kryteria te najczęściej określane są na etapie zawierania umowy na budowę systemu. W takiej umowie określa się wymagania odnośnie systemu, termin oddania systemu do użytku i koszt jego wykonania. Zatem można uznać, że projekt skończył się sukcesem, jeżeli:

• Projekt mieści się w budżecie,
• Projekt mieści się w ramach czasowych (termin zakończenia nie jest przekroczony),
• Dostarczony system spełnia rzeczywiste potrzeby klienta (zadowolony klient).

1.3. Przyczyny problemów

Jak wynika z badań i obserwacji, problemy nie dotyczą tylko pojedynczych projektów, ale całego przemysłu dostarczającego oprogramowanie. W roku 1967 można było ten stan – za konferencją NATO na temat inżynierii oprogramowania – nazwać kryzysem. Trwanie tego stanu do dzisiaj należy jednak – za Rogerem Pressmanem – nazwać chorobą chroniczną. Można też połączyć te określenia i nazwać je chronicznym kryzysem oprogramowania (Wyatt Gibbs – Software’s Chronic Crisis, Scientific American, 1994). O chroniczności tej sytuacji świadczy również to, że klasyczna książka Freda Brooksa („Mityczny osobo-miesiąc”, 1975 r.) pozostaje nadal aktualna i wymagała jedynie krótkiego uwspółcześnienia w swym wydaniu jubileuszowym (1995 r.).

Jak jest przyczyna tego „chronicznego kryzysu”? Na to pytanie w zasadzie odpowiedź jest jedna: z braku panowania nad wyjątkowo złożonym produktem, jakim jest system oprogramowania. Kluczowymi punktami są tutaj wymagania użytkowników, architektura i kontrola jakości. Wymagań użytkowników dla jednego systemu są zazwyczaj setki. Co więcej, są one sformułowane najczęściej przez odbiorców w taki sposób, że można na ich podstawie zbudować kilka całkowicie różnie działających systemów i nadal być z nimi zgodnym. Dlatego bardzo istotne jest wykonanie analizy wymagań precyzyjnie określającej sposób funkcjonowania systemu. Co więcej, ten opis powinien być zrozumiały nie tylko dla użytkowników i analityków, ale również dla projektantów i programistów.

Drugą przyczyną choroby oprogramowania jest architektura, a raczej jej brak. Architektura jest takim elementem projektu, który zapewnia realizację wymagań użytkownika, zapobiega „radosnej twórczości” programistów i znacznie redukuje złożoność tworzonych modeli. Wreszcie kontrola jakości. Często kojarzymy ją z testowaniem. Rzeczywiście – niedostateczne testowanie to częsty grzech firm produkujących oprogramowanie. Równie poważnym grzechem jest jednak niedostateczna kontrola satysfakcji użytkowników.

Problemy, przed którymi stoi inżynieria oprogramowania wynikają często z zaniechania stosowania ogólnych zasad inżynierii. Dlatego bardzo ważne jest, abyśmy zidentyfikowali przyczyny problemów i zaczęli je aktywnie pokonywać stosując zasady wiedzy inżynierskiej z zakresu inżynierii oprogramowania.

Poniżej przedstawimy główne przyczyny problemów projektów konstrukcji oprogramowania.

1. Nieprecyzyjne specyfikowanie oprogramowania.
2. Zła komunikacja.
3. Brak projektowania architektonicznego.
4. Brak zarządzania złożonością system.
5. Bardzo późne odkrywanie poważnych nieporozumień.
6. Brak zarządzania zmianami.
7. Nieużywanie narzędzi wspomagających.

1.4. Najlepsze praktyki inżynierii oprogramowania

Coraz więcej organizacji wytwarzających oprogramowanie (chociaż nadal zdecydowanie zbyt mało) zaczyna stosować metody inżynierskie w produkcji oprogramowania. Jakie są zatem te metody? Jakie praktyki należy stosować, aby nie doświadczać symptomów „przewlekłej choroby”? Przedstawiamy tutaj zbiór najlepszych praktyk (ang. best practices) – sprawdzonych w praktyce zasad związanych z tworzeniem oprogramowania. Zasady te, zastosowane w połączeniu, uderzają w podstawowe przyczyny problemów i niepowodzeń procesu. Nazwa „najlepsze praktyki” wynika nie z faktu, że możemy zmierzyć ich poziom „dobroci”. Wynika raczej ze stwierdzenia, że są one najpowszechniej używane w organizacjach, które odnoszą sukcesy w produkcji oprogramowania. Najlepsze praktyki zostały zaczerpnięte od tysięcy takich organizacji i były stosowane w tysiącach projektów. Oto one:

·        Produkuj iteracyjnie, czyli oddawaj system w sposób przyrostowy.

·        Stosuj architektury komponentowe, czyli panuj nad złożonością systemu, miej spójną koncepcję całości i określ ramy dla radosnej twórczości projektantów i programistów.

·        Stale kontroluj jakość, czyli sprawdzaj poprawność systemu od samego początku projektu.

·        Zarządzaj wymaganiami, czyli traktuj wymagania jak jednostki, które podlegają procedurom zarządzania.

·        Zarządzaj zmianami, czyli z góry załóż, że zmiany na pewno będą ciągle zgłaszane.

·        Modeluj wizualnie, czyli twórz diagramy opisujące różne aspekty systemu, gdyż dobry rysunek jest wart więcej niż tysiąc słów.

Powyższe praktyki koncentrują się przede wszystkim na procesie technicznym i odpowiednim ujęciu go w formalne ramy konkretnych działań w różnych dyscyplinach. Inne podejście do praktyki inżynierii oprogramowania zostało wyrażone w tzw. manifeście zwinnego (ang. agile) wytwarzania oprogramowania (agilemanifesto.org). Brzmi on następująco:

„Odkrywamy nowe metody programowania dzięki praktyce w programowaniu i wspieraniu w nim innych. W wyniku naszej pracy, zaczęliśmy bardziej cenić:

• Ludzi i interakcje od procesów i narzędzi,
• Działające oprogramowanie od szczegółowej dokumentacji,
• Współpracę z klientem od negocjacji umów,
• Reagowanie na zmiany od realizacji założonego planu.

Oznacza to, że elementy wypisane po prawej są wartościowe, ale większą wartość mają dla nas te, które wypisano po lewej.”

Manifest – sformułowany przez grupę znanych praktyków wytwarzania oprogramowania – koncentruje się na aspekcie organizacyjnym i konieczności „zwinnego” (stąd nazwa) dostosowywania się do zmieniających się w projekcie warunków. Należy jednak podkreślić, że podejście zwinne nie neguje stosowania odpowiednich czynności technicznych (proces, narzędzia, dokumentacja). Uważa ono jednak, że zdecydowanie ważniejsze są czynniki poprawiające współpracę w zespole i reakcję na zmiany. Bardzo istotnym elementem jest zapewnienie satysfakcji klienta poprzez umożliwienie mu wczesnego (w cyklach kilkutygodniowych) zapoznawania się z ciągle rozbudowywanym oprogramowaniem. Jednocześnie, w projektach zwinnych mile widziane są zmiany treści wymagań, tak, aby je dostosować do rzeczywistych potrzeb klienta. Takie zmiany najczęściej „wykuwają” się w codziennej współpracy zespołu deweloperskiego z przedstawicielami klienta. Główną miarą postępu w projektach zwinnych jest działające oprogramowanie, które jest stale weryfikowane przez klienta. Taka ciągła weryfikacja sprzyja również ciągłemu procesowi poprawy efektywności pracy zespołu.

Najlepsze praktyki znajdują odzwierciedlenie w metodykach wytwarzania oprogramowania. Metodyki mogą być mniej lub bardziej sformalizowane oraz mogą obejmować różny zakres obszarów (dyscyplin) inżynierii oprogramowania. Metodyki oparte na podejściu zwinnym, zazwyczaj koncentrują się na aspektach organizacji pracy w zespołach wytwarzających oprogramowanie oraz często dostarczają różnych technik w obszarze programowania czy testowania. Przykładami takich metodyk są Scrum i eXtreme Programming (XP). Metodyki zwinne najczęściej nie formalizują opisu produktów technicznych w projekcie. Metodyki sformalizowane proponują natomiast szczegółowe wytyczne dla różnych czynności w procesie wytwarzania oprogramowania. Przykładem takiej metodyki jest Rational Unified Proccess (RUP) oraz jej „lekki” wariant – Open Unified Process (OpenUP). Opis każdej metodyki możemy oprzeć na trzech zasadniczych elementach: notacji, technikach i procesie technicznym.

1. Proces techniczny organizuje techniki wykorzystywane w procesie wytwórczym w spójny ciąg czynności prowadzący do celu, jakim jest zbudowanie systemu na czas, w budżecie i spełniającego rzeczywiste potrzeby jego odbiorców.
• Proces techniczny pozwala zorganizować czynności cyklu życia oprogramowania.
2. Notacja dostarcza jednolitego języka dla porozumiewania się członków zespołu.
• Notacja pozwala na jednoznaczne dokumentowanie wszystkich decyzji podejmowanych w projekcie.
3. Techniki przedstawiają sposoby działania, które pokonują zasadnicze przyczyny niepowodzeń.
• Techniki zarządzania wymaganiami koncentrują się na formułowaniu celów projektu z punku widzenia odbiorców (klientów, użytkowników) oprogramowania.
• Techniki projektowania oprogramowania pozwalają panować nad złożonością systemów oprogramowania poprzez budowę ich planów architektonicznych i szczegółowych modeli kodu.
• Techniki programowania przedstawiają zasady formowania kodu oraz zarządzania kodem w ramach zespołów programistów.
• Techniki kontroli jakości dotyczą weryfikacji zgodności powstającego systemu z wymaganiami, czyli ściśle wiążą się z technikami zarządzania wymaganiami.

Jak pokazaliśmy w poprzednim rozdziale, zakończenie projektu informatycznego sukcesem nie jest łatwym zadaniem. Wytwarzanie oprogramowania można jednakże przedstawić jako powtarzalny cykl rozwiązywania poszczególnych problemów, prac technicznych i łączenia rozwiązań. Na podstawie doświadczeń zebranych na przestrzeni lat opracowano wiele modeli procesów wytwórczych oprogramowania, które przedstawiają różne cykle wytwarzania oprogramowania.

2.1. Dyscypliny cyklu wytwarzania oprogramowania

W procesie wytwarzania oprogramowania powstaje przede wszystkim system oprogramowania. Oprócz tego, w trakcie projektu konieczne jest wytworzenie innych produktów, takich jak instrukcja użytkownika, specyfikacja wymagań, dokumentacja projektowa, itd. Takie produkty uzupełniające (zwane także pośrednimi) powstają w wyniku różnych działań, które możemy podzielić na grupy nazywane dyscyplinami. Dyscyplina inżynierii wymagań stanowi spójny zestaw czynności, które są powiązane z zasadniczym obszarem działania w ramach projektu konstrukcji oprogramowania. Należy jednak zwrócić uwagę na to, że podział na dyscypliny nie oznacza podziału na etapy, czyli nie decyduje o uporządkowaniu czasowym wykonywania zadań w poszczególnych dyscyplinach.

Dyscyplina wymagań

W ramach dyscypliny wymagań powinniśmy w pierwszej kolejności zidentyfikować problemy, które może rozwiązać system oprogramowania, a także podjąć decyzję o budowie takiego systemu. Podstawą określenia potrzeb klienta wynikających z zadanego problemu jest specyfikacja wymagań. Głównym celem specyfikacji wymagań jest określenie zakresu i kształtu przyszłego systemu, który będzie realizował potrzeby klienta. W ramach proponowanego przez nas podziału, dyscyplina ta dzieli się na dwie zasadnicze dyscypliny składowe – analizę środowiska (np. biznesu) oraz analizę wymagań.

W ramach analizy środowiska opisujemy aktualny oraz docelowy stan środowiska (biznesu). Wykonywane jest to przy współpracy przedstawicieli klienta (osób zamawiających system lub ich reprezentantów).

Opis środowiska (biznesu) stanowi pierwszy zasadniczy produkt dyscypliny wymagań. Jest on opisem fragmentu świata, który jest obszarem działań danej organizacji wraz ze środowiskiem, w jakim ta organizacja (biznes) działa. Formułowanie takiego opisu polega na stworzeniu precyzyjnego i zrozumiałego modelu, który zawiera wszystkie elementy środowiska (biznesowego) oraz zasady oddziaływania ich na siebie. Model może opisywać tylko stan docelowy (po zbudowaniu systemu informatycznego), lub być uzupełniony o opis stanu aktualnego.

Kompletna specyfikacja wymagań wynika bezpośrednio z opisu biznesu i można ją porównać do piramidy. Na samym szczycie znajduje się wizja systemu, która dostarcza informacji na temat ogólnych cech systemu w ścisłym powiązaniu z potrzebami biznesowymi klienta. Zakres sytemu wyznaczają wymagania użytkownika w postaci uporządkowanego zbioru cech i funkcji systemu, które powinny być podstawą do zawarcia kontraktu. Wizja systemu i wymagania użytkownika tworzą wymagania zamawiającego, które są odzwierciedleniem rzeczywistych potrzeb zdefiniowanych przez biznes. Na najniższym poziomie piramidy są wymagania oprogramowania, które opisują szczegóły funkcjonalne komunikacji między użytkownikami i systemem, wszystkie wymieniane między nimi dane oraz planowany wygląd systemu.

Dyscyplina projektowania

W ramach dyscypliny projektowania dokonujemy syntezy problemu opisanego w ramach dyscypliny wymagań poprzez opracowanie „planów projektowych” dla systemu. Celem działań tej dyscypliny jest stworzenie modeli projektowych na różnych poziomach abstrakcji, na podstawie których zostanie zaimplementowany system.

Mając do dyspozycji opis środowiska biznesu i specyfikację wymagań można zdefiniować, jakich elementów fizycznych (np. serwer bazy danych, serwer aplikacyjny, maszyny klienckie, urządzenia mobilne) będzie potrzebował budowany system i w jaki sposób te elementy będą się ze sobą komunikować. Jest to najbardziej ogólny, fizyczny model architektoniczny. Nie definiuje on logiki działania systemu, która definiowana jest na poziomie architektury logicznej. Na tym poziomie definiuje się moduły wykonawcze (komponenty), z jakich będzie się składał budowany system oraz powiązania komunikacyjne (np. interfejsy) między tymi modułami.  Interfejsy, które są specyfikacją funkcji udostępnianych przez komponenty architektoniczne, pozwalają traktować moduły jako czarne skrzynki. Na tym poziomie abstrakcji nie skupiamy się na tym,  „co jest w środku” komponentów. Skupiamy się na tym, jakie funkcje komponenty spełniają.

Istotnym elementem modelu architektonicznego i zależnych od niego modeli szczegółowych są struktury danych, które służą do komunikacji poprzez interfejsy. Na podstawie słownika możemy zdefiniować tzw. obiekty transferu danych (ang. Data Transfer Object). Określają one „paczki danych”, które mogą być przesyłane między poszczególnymi komponentami systemu.

Kolejnym poziomem projektowania jest stworzenie szczegółowych projektów modułów. Na tym poziomie definiujemy konkretne szczegóły „czarnych skrzynek”. Dokładnie przedstawiamy strukturę oraz opracowujemy sekwencje wykonywanych operacji, których celem jest realizacja funkcji określonych w poszczególnych interfejsach komponentów.

Produktem projektowania jest zbiór spójnych modeli, które dostarczą szczegółowych informacji o składnikach systemu, który ma spełniać wymagania opisane w specyfikacji wymagań i funkcjonować w opisanym środowisku.

Dyscyplina implementacji

W wyniku działań objętych dyscypliną implementacji zostaje wytworzony kod (program) realizujący wymagania zdefiniowane podczas analizy i spełniający założenia projektowe, określone w modelach projektowych. Do wytworzenia działającego systemu wykorzystuje się zbiór technologii, które są zgodne z wymaganiami technicznymi i wpisują się w środowisko działania budowanego systemu.

Proces programowania wymaga odpowiedniego środowiska i organizacji pracy. Aby stworzyć system, który będzie prawidłowo funkcjonował w środowisku produkcyjnym klienta, należy takie środowisko zbudować również w wersji testowej (implementacyjnej). Duży wpływ na kształt środowiska implementacyjnego mają wymagania jakościowe i ograniczenia środowiska biznesowego.

Implementacja systemu oznacza implementację poszczególnych modułów (komponentów) zaprojektowanych w ramach dyscypliny projektowania. Każdy moduł może być realizowany niezależnie od pozostałych (przez różnych programistów), ale powinien poprawnie z nimi współdziałać.

Pożądaną cechą kodów źródłowych, oprócz oczywistej zgodności z modelami projektowymi i wymaganiami, powinny być: wspólna konwencja programistyczna, dobra dokumentacja i gwarancja poprawności działania potwierdzona dokumentacją testów jednostkowych.

Po implementacji sprawnie działających (przetestowanych) modułów i ich połączeniu, całość powinna przejść testy integracyjne. Tak sprawdzony kod systemu jest głównym produktem dyscypliny implementacji.

Dyscyplina walidacji (testowania)

Celem testowania w ramach osobnej dyscypliny walidacji jest sprawdzenie, czy zbudowany system oprogramowania spełnia wymagania określone w specyfikacji wymagań i działa poprawnie w środowisku biznesowym.

W odróżnieniu od testów przeprowadzonych w czasie implementacji, głównymi odbiorcami testów w ramach walidacji są przedstawiciele zamawiającego. Zwykle są to przyszli użytkownicy systemu, wytypowani i specjalnie przygotowani do nadzorowania i wykonywania czynności związanych z testowaniem. Poza sprawdzeniem poprawności integracji, które dokonywane jest przez osoby odpowiedzialne za infrastrukturę informatyczną organizacji, sprawdzana jest również zgodność z wymaganiami zamawiającego oraz szczegółowymi wymaganiami oprogramowania. Ogół tego typu testów nazywamy testami akceptacyjnymi (ang. acceptance test), gdyż są one warunkiem akceptacji systemu przez klienta.

Przeprowadzenie testów akceptacyjnych systemu wymaga planu testów. Zazwyczaj plan testów jest dokumentem powstałym na podstawie specyfikacji wymagań. Poszczególne testy ułożone są w odpowiedniej kolejności, która pozwala na prawidłowe sprawdzenie prawidłowości działania poszczególnych funkcjonalności systemu. Testy takie przypominają instrukcje postępowania przygotowane dla użytkowników systemu. Rezultatem jest powstanie kompletnych scenariuszy testów. Efektem wykonania konkretnego scenariusza testów jest potwierdzenie poprawności działania lub opis błędu.

Wynikiem dyscypliny testowania jest dokumentacja testów akceptacyjnych, która jest podstawą do zatwierdzenia systemu i przejścia do czynności objętych dyscypliną wdrożenia.

Dyscyplina wdrożenia

Wdrożenie systemu polega zasadniczo na przeniesieniu systemu do warunków środowiska produkcyjnego i przekazaniu go do właściwego użytkowania. Dyscyplina wdrożenia obejmuje czynności związane z instalacją systemu oraz umożliwieniem korzystania z systemu przez jego użytkowników. Głównym produktem dyscypliny wdrożenia jest zainstalowany system, działający w docelowym środowisku wykonawczym. Innymi produktami są np. dokumentacja dla użytkowników oraz dokumentacja techniczna.

Można wyróżnić kilka najbardziej popularnych strategii wdrożenia nowego systemu do środowiska produkcyjnego:

- Wdrożenie bezpośrednie – nowy system zostaje wdrożony od razu w całości. Jest to strategia niosąca często spore ryzyko.

- Wdrożenie równolegle – obok nowego systemu, przez pewien czas działa również stary.

- Wdrożenie pilotażowe – w pierwszej fazie, fragment nowego systemu lub cały system zostaje uruchomiony w jednej z jednostek organizacyjnych. Dopiero po sprawdzeniu poprawności tego wdrożenia, system zostaje wdrożony w pozostałych jednostkach.

- Wdrożenie stopniowe – strategia polegająca na wprowadzaniu w działalność organizacji kolejnych fragmentów nowego systemu, uniezależniając pozostałe obszary działalności od nowego systemu.

Istotnym elementem dyscypliny wdrożenia jest przygotowanie materiałów dla użytkowników oraz przeprowadzenie szkoleń dla przyszłych użytkowników. Efektem pomyślnego wdrożenia systemu jest działający system, sprawnie używany przez jego użytkowników.

Dyscyplina konserwacji

Czynności konserwacji, zwane także czynnościami utrzymania, stanowią zawsze ostatni etap w cyklu życia oprogramowania. Obejmują one zapewnianie poprawnego funkcjonowanie systemu w środowisku biznesowym. W trakcie pracy z systemem oprogramowania mogą zostać wykryte wcześniej nieznane defekty. Wymagana funkcjonalność lub cechy jakościowe systemu oprogramowania, które zostały zdefiniowane w ramach analizy wymagań, mogą ulec zmianie już po oddaniu systemu do użytku. Może zmienić się także samo środowisko i procesy biznesowe.  Wszystkie te sytuacje wymuszają podjęcie pewnych działań, które można podzielić na cztery grupy:

-     czynności naprawcze obejmujące usuwanie defektów oprogramowania;

-     czynności adaptacyjne dostosowujące oprogramowanie do zmieniającego się środowiska;

-     czynności ulepszające wprowadzające nowe funkcjonalności i zmianę już istniejących;

-     czynności prewencyjne przygotowujące oprogramowanie do przyszłych modyfikacji.

W niektórych przypadkach wprowadzenie zmian w funkcjonującym systemie, może wymagać przejścia przez wszystkie dyscypliny, od wymagań do implementacji i wdrożenia.

2.2. Przegląd cykli wytwarzania oprogramowania

Przedstawione wyżej dyscypliny określają zakres czynności i produktów wykonywanych w typowym projekcie wytwarzania oprogramowania. Czynności te tworzą pewien ciąg, który powinien być wykonywany w określonej kolejności. Taki ciąg czynności nazywamy procesem wytwarzania oprogramowania. W dobrze zorganizowanym projekcie, proces ten przebiega zgodnie z dobrze określonym cyklem wytwórczym, który jest elementem całego cyklu życia oprogramowania. Cykl wytwórczy definiuje rozłożenie czynności z poszczególnych dyscyplin w czasie.

W większości współczesnych projektów stosuje się jeden z dwóch cykli wytwórczych: cykl wodospadowy (również nazywany kaskadowym) lub cykl iteracyjny. Cykle wytwórcze posiadają warianty, charakterystyczne dla różnych metodyk wytwórczych, które zostały opisane w kolejnym rozdziale. Cykl wytwórczy jest rodzajem przewodnika, który wskazuje kierunek, który należy obrać, aby osiągnąć zamierzony cel, ale nie pokazuje drogi, którą należy pójść. Szczegóły tej drogi w szczegółach określa natomiast metodyka.

Cykl wodospadowy

Koncepcja wodospadowego (ang. waterfall) cyklu życia oprogramowania, zwanego także kaskadowym lub klasycznym, została sformułowana już w roku 1970.  Główna ideą tego cyklu jest ujęcie dyscyplin wytwarzania oprogramowania w sekwencję dobrze wyodrębnionych kroków (faz lub etapów), które prowadzą do zbudowania systemu oprogramowania. Rysunek 2.1 przedstawia ogólny schemat cyklu wodospadowego. Kolejne etapy wykonywane są raz w trakcie trwania projektu i następują po sobie. Nazwa tego cyklu wynika z podobieństwa tego schematu do wodospadu lub kaskady.

Rysunek 2.1: Wodospadowy cykl wytwarzania oprogramowania

Jak wskazuje rysunek, poszczególne etapy „wodospadu” odpowiadają dyscyplinom cyklu życia oprogramowania przedstawionym w poprzedniej sekcji. Każdy etap dostarcza co najmniej jednego produktu, który podlega weryfikacji i akceptacji. Następny etap może się rozpocząć tylko po zakończeniu poprzedniego i wykorzystuje jego produkty jako punkt wyjścia. W praktyce jednak, sąsiadujące ze sobą etapy zazębiają się i przekazują nawzajem informacje. Oznacza to, że w ramach jednego etapu możemy wrócić do poprzedniego etapu (tzw. wodospad z nawrotami).

Cykl wodospadowy w naturalny sposób odzwierciedla proces rozwiązywania złożonych problemów. Wszystkie podejmowane czynności prowadzą od potrzeb użytkownika do gotowego systemu w jednym przebiegu przez poszczególne grupy czynności (dyscypliny). Umożliwia to łatwe zarządzanie zasobami (zespoły specjalistów, sprzęt). Przejście do kolejnych faz wymaga jednak zamrożenia wyników prac w fazach poprzednich. Wynika to z konieczności zachowania spójności produktów w ramach całego cyklu. Konieczność powrotu do poprzednich faz oznacza odejście od czystego cyklu wodospadowego.

Niestety, cykl wodospadowy posiada wady, które rodzą zasadnicze zagrożenia. Podstawowym problemem jest późna weryfikacja wyników prac. Problemy z realizacją wymagań klienta odkrywane są zazwyczaj dopiero w fazie testowania, a nawet dopiero w fazie wdrożenia. Zauważmy też, że istotnym czynnikiem jest tutaj subiektywizm oceny produktów. Na przykład, jakość specyfikacji wymagań możemy w pełni ocenić dopiero w fazie implementacji. Inną wadą cyklu wodospadowego jest niewielka elastyczność w radzeniu sobie ze zmianami (w tym – zmianami zakresu). Bardzo trudno jest stworzyć poprawną i kompletną specyfikację już na początku projektu. Rzeczywiste potrzeby klienta są często odkrywane lub zmieniane już w trakcie trwania prac nad systemem oprogramowania.

Wodospadowy cykl wytwarzania oprogramowania, mimo iż jest dosyć leciwy i posiada wiele wad, wciąż jest popularny. Powodzenie projektu realizowanego cyklem wodospadowym mocno zależy od stabilności i poprawności specyfikacji wymagań. Dlatego jest polecany do krótkich projektów, w których wymagania są dobrze określone i zrozumiałe, a ich specyfikacja jest w pełni przygotowana. W przypadku dłuższych projektów powinniśmy być pewni, że problem jest bardzo dobrze określony i nie będzie podlegał modyfikacjom.

Cykl iteracyjny

Podstawą dla stworzenia cyklu iteracyjnego była chęć eliminacji zagrożeń związanych z „zamrażaniem” produktów poszczególnych faz cyklu wodospadowego. Zagrożenia takie możemy wyeliminować przez wprowadzenie wielokrotnego przechodzenia przez powiązane ze sobą dyscypliny. To podejście jest główną cechą iteracyjnego cyklu wytwarzania oprogramowania. Ilustruje to rysunek 2.2.  Jak widzimy, cykl iteracyjny zachowuje podział na dyscypliny, ale czynności w ramach wszystkich dyscyplin wykonywane są wielokrotnie.

W projekcie planowane jest wiele iteracji, gdzie każda iteracja trwa zazwyczaj kilka tygodni (najczęściej od 2 do 6). Poszczególne iteracje rozpoczynają się od wyboru i wyspecyfikowania określonego zakresu wymagań, odpowiadającego przyrostowi funkcjonalności systemu. Następnie następują czynności syntetyzowania problemu – projektowanie, implementacja oraz testowane. Czynności te dotyczą zakresu wymagań wybranych do danej iteracji oraz ew. wymagań, które nie zostały prawidłowo zrealizowane w poprzednich iteracjach. Dokładnie testuje się funkcjonalność wykonaną w danej iteracji, a także przeprowadza się mniej dokładne testy funkcjonalności zrealizowanych wcześniej. Po zakończeniu testów i akceptacji ich wyników przechodzimy do kolejnej iteracji. W razie stwierdzenia błędów lub uwag kod klienta, odpowiednie zadania są przydzielane do kolejnych iteracji.

Rysunek 2.2: Iteracyjny cykl wytwarzania oprogramowania

Po zakończeniu pewnej liczby iteracji możliwe jest wdrożenie systemu. W niektórych projektach wdrożenie wykonywane jest tylko raz – po ostatniej iteracji. Najczęściej jednak planuje się wdrożenia pośrednie. Po ostatnim wdrożeniu następuje faza konserwacji, podobnie jak w cyklu wodospadowym.

Zastosowanie cyklu iteracyjnego nie daje oczywiście gwarancji na końcowy sukces procesu wytwórczego. Zwiększa jednak szanse na jego powodzenie, przy założeniu prawidłowego stosowania jego zasad. Wszelkie problemy odkrywane są po każdej iteracji. Jeżeli aktualny stan oprogramowania nie odpowiada rzeczywistym potrzebom, lub funkcjonalność nie została w pełni zrealizowana, możemy w naturalny sposób – zgodny z założeniami cyklu – przejść do fazy wymagań, a następnie do faz projektowania, implementacji i testowania.

Cykl iteracyjny pozwala na przyrostowe tworzenie systemu oprogramowania. Daje to możliwość ustalenia priorytetów dla określonych funkcjonalności systemu oraz kolejności ich wykonania i wdrożenia. Produkty poszczególnych faz nie muszą być zamrażane, przez co na koniec cyklu wytwarzania oprogramowania wszystkie specyfikacje i dokumentacje odpowiadają rzeczywistym warunkom.

Iteracyjny cykl wytwarzania oprogramowania najlepiej sprawdza się w projektach budowy średnich i dużych systemów oprogramowania, gdzie nie wszystkie wymagania są dobrze zdefiniowane, a nawet rozpoznane.

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