Modele cyklu życia oprogramowania

Wprowadzenie

Tworzenie oprogramowania nie jest sprawą prostą i nikogo, kto brał udział w dużym 
projekcie,   nie   trzeba   o   tym   przekonywać.   Czasy,   kiedy   jedna   osoba   zajmowała   się 
zbieraniem   wymagań,   analizą,   projektowaniem,   programowaniem,   testowaniem   i 
wdrażaniem   produktu   informatycznego   dawno   już   się   skończyły.   „Programowanie 
odkrywcze”   nie   jest   obecnie   dobrym   sposobem   budowy   jakichkolwiek   systemów 
informatycznych. Tworzone dziś systemy są po prostu zbyt skomplikowane, aby przez 
cały cykl życia tych systemów, mogła nad nimi panować jedna osoba. 

Rysunek  1. Programowanie odkrywcze

Trudności w budowaniu dużych systemów wymusiły, już wiele lat temu, konieczność 
usystematyzowania procesu wytwarzania systemów informatycznych. Stworzono więc 
modele   porządkujące   podejmowane   działania   i   stany   w   jakich   znajduje   się   produkt 
informatyczny. Obecnie zbiór modeli cykli życia oprogramowania jest niezwykle bogaty. 
Oczywiście wystarczy poznać tylko kilka kluczowych modeli, pozostałe są najczęściej 
hybrydami tych podstawowych.

Pojęcie modelu cyklu życia systemu informatycznego

Czym właściwie jest model cyklu życia systemu informatycznego (oprogramowania)? To 
szereg   wzajemnie   zależnych   od   siebie   etapów,   począwszy   od   ujawnienia   potrzeby 
budowy systemu informatycznego, prezentacji jego idei (budowę modelu), konstrukcję, 
wdrożenie,   użytkowanie,   przystosowane   do   ewentualnych   zmian   funkcjonowania 
(wynikających najczęściej ze względu na zmieniające się warunki otoczenia), a kończąc 
na   wycofaniu   z   eksploatacji.   Moim   zdaniem   najciekawsza   część   cyklu   życia 
oprogramowania związana jest z samym procesem wytwórczym kończącym się wraz z 
wdrożeniem systemu Ta część cyklu życia oprogramowania nazywana jest często cyklem 
wytwarzania oprogramowania.
Reasumując   każdy   model   cyklu   życia   oprogramowania   ma   na   celu   przedstawienie 
procesu   wytwarzania   oprogramowania,   który   prowadzi   do   stworzenia   działającego 
systemu spełniającego oczekiwania klienta.

Rafał Kasprzyk

Popularne modele cyklu życia systemu informatycznego

Najczęściej   wymienianymi   procesami   wytwarzania   oprogramowania   jest   model 
kaskadowy   (zwany   również   modelem   wodospadu   lub   liniowym)   i   model   iteracyjny. 
Terminy   te   często   są   nie   do   końca   poprawnie   rozumiane.   Bardzo   często   można   się 
spotkać z przekonaniem, że proces kaskadowy jest procesem przestarzałym, a jedynie 
słusznym  podejściem  jest  proces  iteracyjny.  Osobiście  ostrożnie  podchodzę  do  takiej 
oceny tych dwóch najpopularniejszych modeli wytwarzania oprogramowania. Uważam, 
że wybór procesu w znacznym stopniu zależy od charakteru projektu, a tym samym nie 
ma   jednego   słusznego   modelu   cyklu   życia   oprogramowania.   Co   więcej,   najczęściej 
okazuje się, że w praktyce najlepiej radzą sobie modele, które są modyfikacjami lub 
hybrydami procesów podstawowych. Przyczyna ich powstania związana jest bądź to z 
wadami   bądź   trudnościami   w   adaptacji   do   rzeczywistych   warunków   wytwarzania 
systemów informatycznych modelu kaskadowego. Zauważmy, że sam proces iteracyjny 
stanowi   swego   rodzaju   modyfikację   procesu   kaskadowego.   Inne   znane   i   popularne 
modele cyklu życia oprogramowania to model spiralny, model V, prototypowanie, i wiele 
innych.

Model kaskadowy

Najstarszym   i   prawdopodobnie   najlepiej   znanym   cyklem   życia   oprogramowania   jest 
model wodospadu. Najpowszechniej spotykanym argumentem zachęcającym do użycia 
tego   modelu   jest   fakt,   iż   jest   on   dla   człowieka   najbardziej   naturalnym   sposobem 
rozwiązywania wszelkich problemów. W modelu kaskadowym, aby zbudować system 
informatyczny   należy   przejść   przez   kolejne   etapy,   których   realizacja   ma   zapewnić 
zakończenie   projektu.   Etapy   na   jakie   dzielony   jest   proces   wytwarzania   to:   zbieranie 
wymagań, analiza, projektowanie, implementacja, testowanie i wdrożenie systemu.

Rysunek 2. Model kaskadowy

Rafał Kasprzyk

W modelu wodospadu wyjście z jednego etapu jest równocześnie wejściem w kolejny, 
bez   możliwości   powrotu.   Kolejność   poszczególnych   etapów   jest   więc   sztywno 
narzucona. Analityk po stworzeniu modelu dziedziny problemu przekazuje wyniki swojej 
pracy projektantowi. Projektant, po stworzeniu projektu oprogramowania, w oparciu o 
wyniki etapu analizy, przekazuje go w ręce programisty, którego zadaniem jest jego 
implementacja.   Następnie   w   celu   zapewnienia   wysokiej   jakości   produktu,   kod   jest 
testowany,   a   dopiero   na   samym   końcu   jest   przekazywany   klientowi.   Tak   więc,   w 
procesie   kaskadowym   bardzo   istotna   jest   forma   przekazywania   wyników,   z   jednego 
etapu do drugiego. 
Modyfikacje   modelu   procesu   kaskadowego   zezwalają   na   powroty,   ale   możliwość 
wystąpienia takiej sytuacji powinna być minimalizowana. Oczywistym jest przecież, że 
podczas implementacji może wystąpić problem, który zmusi zespół do powrotu do etapu 
projektu lub co gorsza powtórnej analizy. Weryfikacja wyników poszczególnych etapów 
jest   więc   nieunikniona,   a   powroty   w   rzeczywistych   warunkach   praktycznie   zawsze 
występują.
Podstawowe cechy modelu kaskadowego niestety pokazują jednocześnie jego wady:

•

Uzyskanie produktu spełniającego oczekiwania klienta niezwykle silnie zależy od 
niezmienności wymagań, która jest przecież trudna do uzyskania.

•

Weryfikacja zgodności produktu z wymaganiami i jego użyteczności następuje 
dopiero w ostatnim kroku.

•

Próba dopasowania produktu do zmieniających się wymagań, powoduje znaczący 
wzrostu kosztów budowy systemu.

•

Kolejności wykonywania prac musi być ściśle przestrzegana, co niekoniecznie 
trzeba uważać za wadę. Warto jednak zauważyć, że większość osób preferuje 
znacznie mniej rygorystyczne procesy wytwarzania oprogramowania.

•

Wysoki   koszt   błędów   popełnionych   we   wstępnych   etapach   jest   bardzo 
charakterystyczną właściwością modelu kaskadowego. Przecież błędy popełnione 
na etapie zbierania i/lub analizy wymagań mogą być wykryte dopiero na etapie 
testów akceptacyjnych, bądź eksploatacji, a ich koszt o kilka rzędów wielkości 
przewyższać koszt błędów popełnionych podczas implementacji. 

•

Częstym   argumentem   podnoszonym   przeciwko   modelowi   liniowemu   jest 
zmarginalizowanie roli klienta w procesie wytwarzania oprogramowania. Długa 
przerwa   w   kontaktach   z   klientem,   z   którym   ściśle   współpracuje   się   podczas 
określania   wymagań,   pociąga   za   sobą   ryzyko   zmniejszenia   zainteresowania 
klienta produktem, podczas gdy nie bierze on udziału w procesie wytwórczym. 
Klient   „przypomina”   sobie   o   systemie,   który   w   końcu   był   przez   niego 
zamawiany, na etapie wdrażania, kiedy to jego wizja na temat funkcjonalności, 
jaką system powinien zapewniać może ulec istotnej zmianie.

Warto   nadmienić,   że   model   kaskadowy   mimo   swych   licznych   wad,   w   nieco 
zmodyfikowanej   postaci,   stał   się   standardem,   zalecanym   przez   Departament   Obrony 
Narodowej Stanów Zjednoczonych (DOD STD 2167), stosowanym przy wytwarzaniu 
systemów   informatycznych   dla   wojska.   Standard   ten   jest   ścisłą   realizacją   modelu 
kaskadowego „kierowaną dokumentami”. Na czym owa modyfikacja polega? Po prostu, 
każdy   etap   kończy   się   opracowaniem   szeregu   dokumentów,   które   z   założenia   są 
wystarczającą podstawą do realizacji kolejnych etapów. Dopiero akceptacja przez klienta 
dokumentacji zrealizowanego etapu pozwala na rozpoczęcie kolejnego.

Rafał Kasprzyk

Model iteracyjny

W modelu iteracyjnym wymagania porządkowane i dzielone są w mniejsze podzbiory. 
Każdy   taki   podzbiór   wymaganej   funkcjonalności   wymaga   przejścia   przez   etapy,   o 
których była mowa w modelu kaskadowym. Po zakończeniu każdej iteracji wybierany 
jest kolejny podzbiór wymagań do realizacji i ponownie przechodzimy przez wszystkie 
etapy wytwarzania oprogramowania. 

Rysunek  3. Model iteracyjny

Zauważmy, że takie podejście pozwala na szybka implementację przynajmniej części 
wymaganej funkcjonalności (tej o najwyższym priorytecie, lub też stanowiącej najwyższe 
ryzyko   niepowodzenia   realizacji).   Model   iteracyjny   pozwala   więc   na   bardzo   szybką 
weryfikację realizowalności wytwarzanego systemu i informację zwrotną od klienta, czy 
to co potrzebuje jest tym co otrzyma jako produkt procesu wytwórczego.

Praktyka   stosowania   procesu   iteracyjnego   zaleca   przed   rozpoczęciem   rzeczywistych 
iteracji   przeprowadzenie   swego   rodzaju   rozpoznania   wymagań,   w   celu   uzyskania 
ogólnego obrazu i zakresu projektu. Celem jaki przyświeca tym działaniom jest podział 
wymagań   na   właściwe   iteracje.   Takie   wstępne   działania   polegają   najczęściej   na 
stworzeniu ogólnej architektury systemu, a niekiedy nawet jego prototypu. 
Ciekawą zaletą modelu iteracyjnego jest możliwość przekazania systemu do wdrożenia, 
gdy   tylko   jakiś   rozsądny   podzbiór   wymagań   zostanie   zaimplementowany   i 
przetestowany. Jest to pożyteczne, co najmniej z dwóch powodów: wcześniej można 
uzyskać pewne korzyści (nie ma co ukrywać, że chodzi mi tu o korzyści finansowe) z 
wdrożenia  systemu, ale  również,  co w   dłuższej  perspektywie jest ważniejsze, można 
uzyskać w pełni obiektywne opinie na temat jego działania w rzeczywistych warunkach. 
Iteracyjne   podejście   pozwala   więc   na   prezentację   kolejnych   wydań   systemu,   które 
wzbogacane są o nową funkcjonalność, a wykryte błędy zostają usunięte.

Rafał Kasprzyk

Bardzo często można spotkać się z pojęciem procesu przyrostowego, ewolucyjnego lub 
spiralnego, które w praktyce są tym samym, co proces iteracyjny. Oczywiście na gruncie 
teoretycznym rozważa się różnice pomiędzy tymi procesami, ale nie są one wyraźne. W 
dalszej części artykułu przedstawiony jednak zostanie model spiralny, ze względu na 
częste odwołania się do niego w literaturze dotyczącej omawianego tematu.

Model kaskadowy i model iteracyjny – możliwe scalenie

Przedstawiony opis modelu kaskadowego i iteracyjnego został znacząco uproszczony, 
aby   czytelnik   uchwycił   podstawową   różnicę   pomiędzy   tymi   procesami.   Praktyka 
pokazuje, że oba procesy mogą podlegać bardzo wielu zaburzeniom.
Często   proponowanym   rodzajem   procesu   jest   tzw.   etapowy   cykl   tworzenia 
oprogramowania, które stanowi scalenie modelu kaskadowego i modelu iteracyjnego. 
Proponuje się w nim dokonać według modelu kaskadowego zbierania wymagań, analizy i 
projektowania, a następnie implementację i testowanie podzielić na iteracje. Wdrożenia 
można   natomiast   dokonać   po   zaimplementowaniu   i   przetestowaniu   całości   wymagań 
ponownie według modelu kaskadowego lub też wdrożenie może polegać na instalacji 
kolejnych wydań systemu, co zależy oczywiście od charakteru projektu i uzgodnień z 
klientem. Oczywistym jest, co już zostało wspomniane, że to drugie podejście wydaje się 
być z różnych przyczyn korzystniejsze dla twórców, jak i odbierających system.

Można   śmiało   postawić   tezę,   że   jednym   z   głównych   powodów   modyfikacji   modelu 
kaskadowego elementami charakterystycznymi dla procesu iteracyjnego     są względy 
finansowe, a nie jak by się mogło wydawać oczywiste zalety iteracyjnego podejścia do 
wytwarzania   oprogramowania.   Zauważmy,   że   wykonawca   żąda   pieniędzy   za   każdy 
wykonany etap. Z kolei klient, płacąc za wykonany etap, żąda wyników, które jest w 
stanie ocenić pod względem zgodności z wymaganiami (a często z jego niestety mało 
precyzyjną wizją wymagań). 

Model kaskadowy i model iteracyjny - ocena

Większość  specjalistów   zajmujących   się   wytwarzaniem  oprogramowania   w   podejściu 
obiektowym   nie   zaleca   procesu   kaskadowego,   który   –   nie   ma   co   ukrywać   –   był 
niezwykle   popularny   w   przypadku   stosowania   podejścia   strukturalnego.   Jest   wiele 
powodów niechęci do modelu kaskadowego. Bez wątpienia najważniejszą wadą jest fakt, 
ze w praktyce proces kaskadowy nie pozwala ocenić, czy projekt jest na dobrej drodze do 
realizacji.   Można   spotkać   się   z   sytuacją,   że   na   wczesnym   etapie   „ogłaszane   jest 
zwycięstwo” i zapomina się o harmonogramie. Niezwykle często powtarza się, że po 
zebraniu   wymagań,   a   następnie   dogłębnej   ich   analizie   praktycznie   prawdziwa 
„intelektualna robota” jest zakończona, a reszta to praca dla zwykłych „rzemieślników”, 
którą   może   wykonać   każdy.   Przejawem   takiego   postępowania   jest   wprowadzanie   do 
projektów nowych ludzi, od których wymaga się rozpoczęcia pracy nad systemem, po 
zapoznaniu się z dokumentacją etapu analizy. Nowi członkowie zespołu są zazwyczaj 
zupełnie   zagubieniu   i   trudno   zrozumieć   im   zasadę   działania   systemu.   Co   gorsza, 
najczęściej brak jest również porządnego projektu systemu i jego architektury (ale to już 
temat   na   kolejny   artykuł),   która   nie   jest     aktualizowana,   a   często   wręcz   się   o   niej 
zapomina.

Rafał Kasprzyk

W   odróżnieniu   od   procesu   kaskadowego,   model   iteracyjny   pozwala   na   rzeczywiste 
sprawdzenie  postępów   w   konstrukcji  systemu  i  poprawności  obranego  kierunku  jego 
budowy.   Konieczność   wielokrotnego   stworzenia   przetestowanego   i   zintegrowanego 
oprogramowania powoduje, że dostrzeżenie usterek w produkowanym oprogramowania 
jest dużo łatwiejsze. Moim zdaniem, model iteracyjny ułatwia również nowym członkom 
zespołu „odnalezienie się” w projekcie.   
Istotne   jest,   aby   każda   iteracja   dawała   wersję   systemu   możliwie   najbliższą   jakości 
produkcyjnej. Niezwykle ważne jest określenie długości iteracji. Ważne jest, aby iteracja 
miała   stałą   długość.   Dlaczego?   Ponieważ   właśnie   stała   długość   iteracji   wymusza 
regularne tworzenie kolejnych wersji systemu wzbogacanych o nową funkcjonalność. 

Model V

Rozwinięciem modelu wodospadu jest model V, charakteryzujący się rozbudowaną fazą 
testów. Model V jest jednym z najpopularniejszych podejść do procesu testowania. Testy 
mają   na   celu   weryfikację   i   walidację   poprawności   wykonania   każdego   etapu 
stanowiącego   cykl   życia   oprogramowania.   Dzięki   rozbudowaniu   sekwencji   etapów 
wytwórczych   o   testowanie   otrzymujemy   produkt   o   najwyższej   jakości,   spełniający 
wymagania klienta.

Rysunek  4. Model V

Model   V   podobnie   jak   klasyczny   model   kaskadowy   stwarza   bardzo   duże 
niebezpieczeństwo. Oczywistym jest przecież, że im później zostanie wykryty błąd lub 
niezgodność z wymaganiami, tym kosztowniejsza będzie naprawa. Dzięki temu, że każdy 
z   etapów   wytwórczych   kończy   się   różnego   rodzaju   przeglądami   i   inspekcjami 
prawdopodobieństwo   pojawienia   się   błędu   lub   niezgodności   z   wymaganiami   przy 
wdrożeniu i eksploatacji jest jednak dużo mniejsze niż w modelu klasycznym. Powoduje 
to znaczące obniżenie kosztów pielęgnacji systemu. Dodatkowo wynikiem każdego etapu 
wytwórczego są plany testów, które po zakończeniu zstępującego cyklu produkcyjnego 
(lewe ramię litery V) realizowane są wstępująco (prawe ramię litery V).

Rafał Kasprzyk

Model spiralny

Model   spiralny   jest   w   pewnym   sensie   próbą   formalizacji   podejścia   iteracyjnego   do 
wytwarzania   oprogramowania.   Główną   cechą   tego   modelu   jest   analiza   ryzyka 
występująca w każdej iteracji. Ciągłe monitorowanie i pomiar zmian, które poddawane 
jest krytycznemu spojrzeniu użytkownika umożliwia dokonanie analizy ryzyka. Pierwszą 
czynnością, która nie jest przedstawiona na rysunku obrazującym model spiralny, jest 
analiza   wymagań   wstępnych.   Jeżeli   wymagania   wydają   się   być   realizowalne   w 
założonym   czasie,   budżecie   i  przy  dostępnych  zasobach  (tzw.  zasad   trójkąta)   można 
przejść do planowania projektu i pierwszej iteracji.

Rysunek  5. Model spiralny

Właściwie kolejne iteracje mają postać „małych” wodospadów. Po każdej takiej pełnej 
iteracji dokonuje się przeglądu systemu. Jeżeli dane przedsięwzięcie wymaga dalszych 
prac wówczas  należy zaplanować kolejna iterację, a następnie przeprowadzić  analizę 
ryzyka realizacji kolejnego wydania. Model spiralny stanowi więc „obudowaną” wersję 
modelu wodospadu opartą o bieżącą analizę ryzyka.
Model spiralny można postrzegać jako cyklicznie powtarzane cztery czynności:

•

Planowanie   –   na   podstawie   wymagań   i   celów   wyznaczonych   przez   klienta, 
dokonuje  się  określenia  alternatyw   i  ograniczeń  oraz  planowania  iteracji  przy 
każdorazowym rozpoczęciu kolejnego cyklu spirali.

•

Analiza ryzyka – sprowadza się do oceny rozwiązań alternatywnych oraz próby 
identyfikacji   i   analizy   ryzyka   związanego   z   każdą   z   możliwych   alternatyw 
konstrukcji nowego wydania.

•

Konstrukcja  –   ma   postać   „małego”   wodospadu,  a   jej   celem   jest   wytworzenie 
kolejnego wydania systemu.

•

Ocena przez klienta – walidacja wydania i jego ocena z możliwością modyfikacji 
wymagań na system (możliwość wystąpienie modyfikacji wymagań powinna być 
minimalizowana). 

Rafał Kasprzyk

Główne   zalety   modelu   spiralnego   to   próba   minimalizacji   ryzyka   niepowodzenia 
przedsięwzięcia   oraz   ciągła   weryfikacja   produktu  przez   użytkownika,  co   ma   na   celu 
wytworzenie produktu w pełni satysfakcjonującego klienta.

Prototypowanie

Model  prototypowania  jest kolejną próbą  radzenia sobie z  problemem identyfikacji i 
braku   stabilności   wymagań.   Prototypowanie   polega   na   budowaniu   kolejnych 
„przybliżeń”   systemu   do   momentu   aż   prototyp   stanie   się   dobrym   odzwierciedleniem 
wymagań.   Oceny   prototypów   i   kolejne   wersje   owych   prototypów,   w   sposób   bardzo 
naturalny prowadzą do identyfikacji wymagań. Zauważmy, że prototypowanie w tym 
przypadku pokrywa etap analizy wymagań i stąd często przedstawiany model określa się 
jako „prototypowanie wymagań”.  Cechą charakterystyczną „prototypowania wymagań” 
jest   budowa   „szybkiego   projektu”   bez   dbałości   o   jego   jakość   i   dostosowanie   do 
środowiska docelowego. Oczywiście możliwe jest szersze spojrzenie na prototypowanie 
tak, aby obejmowało ono również etap projektowania w celu weryfikacji efektywności 
przyjętych   rozwiązań.   Ten   rodzaj   prototypowania   określany   jest   mianem 
„prototypowania wytwórczego”.
Gdy klient dochodzi do wniosku, że prototyp spełnia jego oczekiwania wówczas istnieje 
duże prawdopodobieństwo, że wszystkie wymagania został poprawnie zidentyfikowane. 
Jest to sygnał dla twórców systemu, że można przystąpić do konstrukcji właściwego 
produktu zgodnie z modelem klasycznym wytwarzania oprogramowania, rozpoczynając 
od   etapu   projektowania.   Tego   typu   podejście   może   niekiedy   spotkać   się   jednak   z 
niezrozumieniem. Co gorsza wątpliwości mogą występują zarówno po stronie klienta, jak 
i na wyższych szczeblach zarządzania firmą wykonawcy. Często pojawiają się bowiem 
pytania typu: Dlaczego trzeba zaczynać wszystko od nowa „jeśli już prawie wszystko 
zrobiono”? Kolejną wadą prototypowania jest możliwość „przyzwyczajenia” klienta do 
funkcjonalności oferowanej przez prototyp, a która nie wynika bezpośrednio z wymagań 
klienta. Również projektant może „przyzwyczaić się” do rozwiązań zastosowanych w 
prototypie.   Reasumując,   model   prototypowy   musi   być   dobrze   rozumiany   przez   obie 
strony tj. zarówno twórcę systemu informatycznego, jak i klienta.

Rafał Kasprzyk

Rysunek  4. Model prototypowania

Rafał Kasprzyk

Planowanie predykcyjne i adaptacyjne

Wybór procesu wytwarzania oprogramowania bardzo silnie zależeć będzie od stabilności 
wymagań. Również sposób planowania jest uzależniony od stabilności wymagań. Przy 
założeniu, że wymagania, które zostały zebrane nie będą już się zmieniały, jak również 
klient   nie   będzie   dodawał   nowych,   zaleca   się   planowanie   predykcyjne.   Planowanie 
predykcyjne jest bardzo często narzucone w projektach rządowych i dla wojska. Trudno 
wyobrazić sobie tutaj inny sposób planowania, ponieważ mamy najczęściej sztywną datę 
zakończenia   i   kwotę   budżetu.   Ustalenia   pomiędzy   twórcą   systemu   i   zamawiającym 
muszą jednoznacznie precyzować, co właściwie jest do zrobienia, ile produkt finalny 
będzie   kosztował   i   kiedy   zostanie   ukończony.   To   dlatego   w   tego   typu   projektach 
możliwe jest wykorzystania procesu kaskadowego. Dla administracji nic przecież nie jest 
bardziej kłopotliwe niż brak jasnej wizji kosztu wytworzenia jakiegoś produktu i czasu 
jego realizacji. 
Powstaje jednak pytanie, czy projekty informatyczne mogą być w ogóle przewidywalne. 
Bez wątpienia w większości projektów można się spotkać z „chaosem wymagań”. Chaos 
polega   na   wprowadzaniu   zmian   do   wymagań   w   późniejszych   etapach   cyklu   życia 
oprogramowania. Zmiany takie praktycznie zawsze powodują konieczność przebudowy 
pierwotnie stworzonego planu projektu. Oczywiście można próbować walczyć z taką 
sytuacją.   Powszechnie   stosowanym   sposobem   radzenia   sobie   ze   zmianami   „życzeń 
klienta” jest zamrożenie na pewnym etapie zbioru wymagań. Powstaje jednak pewien 
problem. Zamrożenie wymagań powoduje ryzyku stworzenia produktu, który właściwie 
nie jest potrzebny klientowi już w chwili wdrażania.
Można   jednak   inaczej   próbować   podejść   do   problemu   zmieniających   się   wymagań. 
Zakładamy mianowicie, że „chaos wymagań” jest zjawiskiem nieuniknionym, a pełna 
przewidywalność to iluzja. Doskonale sprawdza się wówczas planowanie adaptacyjne, 
które   traktuje   zmiany   jako   coś   zupełnie   naturalnego.   Zmiany   muszą   być   oczywiście 
kontrolowane.   Ciekawą   rzeczą   jest   fakt,   że   w   przypadku   planowania   adaptacyjnego 
ciężko powiedzieć, że system jako całość rozwija się zgodnie z planem, a to dlatego, że 
taki plan ulega ciągłej modyfikacji. Oznacza to tyle, że plan służy raczej do możliwości 
oszacowania konsekwencji wprowadzenia zmian niż do przewidywania, kiedy system 
zostania   oddany   w   ręce   klienta.   W   przypadku   planowania   adaptacyjnego   można 
oczywiście na stałe określić budżet przewidziany na projekt i czas jego zakończenia, 
jednak   nie   można   przewidzieć   zakresu   wymagań,   które   zostaną   zrealizowane. 
Planowanie adaptacyjne wymaga ścisłej permanentnej współpracy zespołu projektowego 
z klientem, a zbiór wymagań może być dość elastycznie modyfikowany, rozszerzany, a 
niekiedy   zawężany,   oczywiście   wszystko   za   porozumieniem   obu   stron.   W   tego   typu 
projektach zastosowanie modelu kaskadowego z góry skazane jest na niepowodzenie. 
Plan   adaptacyjny   możliwy   jest   do   wykorzystania   jedynie   w   przypadku   zastosowania 
procesu   iteracyjnego   i   jego   licznych   modyfikacji,   z   których   niektóre   przedstawione 
zostały w artykule.

Rafał Kasprzyk

Podsumowanie

Badania prowadzone w 2003 roku w Stanach Zjednoczonych przez The Standish Group 
wykazały, że jedynie 34% wszystkich projektów informatycznych kończą się sukcesem. 
Niepowodzenie   są   najczęściej   spowodowane   brakiem   środków   finansowych   na 
kontynuowanie projektu (niedoszacowanie kosztów), stworzeniem produktu, który nie 
spełnia wymagań klienta lub zakończeniem procesu wytwarzania z bliżej nieokreślonych 
względów (często politycznych). 
Powodów porażki może być wiele, ale najczęściej wskazywane to:

•

brak rzeczywistego zaangażowania ze strony klienta

•

niejasno określone cele biznesowe

•

zbyt ogólnie sformułowane wymagania lub ich ciągła modyfikacja 

•

brak „właściciela” projektu

•

brak planu działania

•

brak narzędzi wspomagających wytwarzanie systemów informatycznych

Wydaje   się   więc,   że   rozważania   na   temat   procesu   wytwarzania   oprogramowania   są 
potrzebne,  ponieważ  twórcom  systemów   informatycznych zależy  na  tym,  aby  sukces 
jednego projektu, przekładał się na następny, aby był powtarzalny. Takie podejście daje 
możliwość  doskonalenia  procesu  wytwarzania  oprogramowania  poprzez  dokonywania 
pomiarów   i   oszacowań,   a   to   z   kolei   wpływa   na   polepszenie   jakości   produktu   i 
zadowolenie klienta.

Nie   wolno   zapominać,   że   proces   wytwarzania   oprogramowania   powinien   być 
wspomagany   przez   narzędzia   CASE,   które   oczywiście   wymagają   odpowiedniej 
konfiguracji na potrzeby danego projektu. Umiejętność wykorzystania tego typu narzędzi 
jest praktycznie warunkiem koniecznym powodzenia każdego większego przedsięwzięcia 
informatycznego.

Literatura

[1] Marin Fowler UML Distilled: A Brief Guide To The Standard Object Modeling 
Language, Pearson Education, Inc., 2004
[2] Stanisław Szejko Metody wytwarzania oprogramowania, MIKOM, Warszawa 2002
[3] Graham I. Inżynieria oprogramowania – metody obiektowe w teorii i praktyce, WNT, 
Warszawa 2004

Rafał Kasprzyk