See discussions, stats, and author profiles for this publication at: https://www.researchgate.

net/publication/229596276

Przegląd modeli cyklu życia oprogramowania

Article · October 2006

CITATIONS READS

3 2,953

1 author:

Rafał Karol Kasprzyk

Military University of Technology
86 PUBLICATIONS   216 CITATIONS   

SEE PROFILE

Some of the authors of this publication are also working on these related projects:

ABCDEF.Net - Advanced Big & Complex Data Exploration Framework using Networks View project

SAVE - State of the Art & Visionary Energetics View project

All content following this page was uploaded by Rafał Karol Kasprzyk on 08 July 2018.

The user has requested enhancement of the downloaded file.

 Inżynieria
oprogramowania
Przegląd modeli
Rafał Kasprzyk
cyklu życia oprogramowania
T
worzenie oprogramowania nie jest sprawą
prostą i nikogo, kto brał udział w dużym pro-
jekcie, nie trzeba o tym przekonywać. Czasy,
kiedy jedna osoba zajmowała się zbieraniem wyma-
gań, analizą, projektowaniem, programowaniem, te-
stowaniem i wdrażaniem produktu informatycznego
dawno już się skończyły. „Programowanie odkryw-
cze” nie jest obecnie dobrym sposobem budowy ja-
kichkolwiek 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.
Trudności w budowaniu dużych systemów wymu-
siły, już wiele lat temu, konieczność usystematyzo-
wania procesu wytwarzania systemów informatycz-
nych. Stworzono więc modele porządkujące podej-
mowane działania i stany w jakich znajduje się pro-
dukt informatyczny. Obecnie zbiór modeli cykli ży-
cia oprogramowania jest niezwykle bogaty. Oczywi-
ście wystarczy poznać tylko kilka kluczowych mode-
li, pozostałe są najczęściej hybrydami tych podsta-
wowych.
Pojęcie modelu cyklu życia
systemu informatycznego
Czym właściwie jest model cyklu życia systemu in-
formatycznego (oprogramowania)? To szereg wza-
jemnie zależnych od siebie etapów, w których podej-
mowane są działania, począwszy od ujawnienia po-
trzeby budowy systemu informatycznego, prezenta-
cji jego idei, konstrukcję, użytkowanie, przystosowa-
ne do ewentualnych zmian funkcjonowania (wyni-
kających najczęściej ze względu na zmieniające się
warunki otoczenia), a kończąc na wycofaniu z eks-
ploatacji. Będziemy zajmować się tylko tą częścią cy-
klu życia oprogramowania, która związana jest z pro-
cesem wytwórczym i w związku z tym nazywana jest
cyklem wytwarzania oprogramowania.
Każdy model cyklu życia oprogramowania ma na
celu przedstawienie procesu wytwarzania oprogra-
mowania, który prowadzi do stworzenia działającego
systemu spełniającego oczekiwania klienta.
Autor jest absolwentem Wydziale Cybernetyki Wojsko-
wej Akademii Technicznej, gdzie od roku zajmuje sta-
nowisko asystenta w Instytucie Systemów Informatycz-
nych. Pracuje w firmie ISOLUTION będąc odpowiedzial-
nym za przygotowywanie, prowadzenie i audyt szkoleń
obejmujących analizę i projektowanie systemów infor-
matycznych z użyciem notacji UML.
Kontakt z autorem: rafal.kasprzyk@wat.edu.pl
52 www.sdjournal.org
���������������� ������ ����������
��������� ������ ������
��� ����������
������
���
����������
������
Rysunek 1. Programowanie odkrywcze
Popularne modele cyklu życia
systemu informatycznego
Najczęściej wymienianym procesem wytwarzania
oprogramowania jest model kaskadowy (zwany rów-
nież modelem wodospadu, ang. waterfall) i model ite-
racyjny. Terminy te często są nie do końca poprawnie
rozumiane. Bardzo często można się spotkać z prze-
konaniem, że proces kaskadowy jest procesem prze-
starzałym, a jedynie słusznym podejściem jest proces
iteracyjny. Osobiście ostrożnie podchodzę do takiej
oceny tych dwóch najpopularniejszych modeli wytwa-
rzania 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 podstawo-
wych. Przyczyna ich powstania związana jest bądź to
z wadami bądź trudnościami w adaptacji do rzeczywi-
stych warunków wytwarzania systemów informatycz-
nych modelu kaskadowego. Zauważmy, że sam pro-
ces iteracyjny stanowi swego rodzaju modyfikację
procesu kaskadowego. Inne znane i popularne mode-
le cyklu życia oprogramowania to model spiralny, mo-
del V, prototypowanie, i wiele innych.
Model kaskadowy
Najstarszym i prawdopodobnie najlepiej znanym cy-
klem ż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 roz-
wiązywania wszelkich problemów. W modelu kaska-
dowym, aby zbudować system informatyczny nale-
ży przejść przez kolejne etapy, których realizacja ma
zapewnić zakończenie projektu. Etapy na jakie dzie-
lony jest proces wytwarzania to: zbieranie wymagań,
analiza, projektowanie, implementacja, testowanie i
wdrożenie systemu.
W modelu wodospadu wyjście z jednego etapu
jest równocześnie wejściem w kolejny, bez możliwo-
Software Developer’s Journal 10/2006
 Przegląd modeli cyklu życia oprogramowania
�����������������
�������
�������������
�������������
����������
���������
Rysunek 2. Model kaskadowy
ści powrotu. Zostaje zatem utworzona sztywno narzucona ko-
lejność poszczególnych etapów. Analityk po stworzeniu mo-
delu dziedziny problemu przekazuje wyniki swojej pracy pro-
jektantowi. Projektant, po stworzeniu projektu oprogramowa-
nia, w oparciu o wyniki etapu analizy, przekazuje go w ręce
programisty, którego zadaniem jest jego implementacja. Na-
stępnie w celu zapewnienia wysokiej jakości produktu, kod
jest testowany, a dopiero na samym końcu jest przekazywa-
ny klientowi.
W procesie kaskadowym bardzo istotna jest forma przeka-
zywania wyników z jednego etapu do drugiego. Niekiedy po-
jawiają się powroty, ale możliwość wystąpienia takiej sytuacji
powinna być minimalizowana. Oczywistym jest przecież, że
na przykład podczas implementacji może wystąpić jakiś pro-
blem, który zmusi zespół do powrotu do projektu lub co gor-
sza powtórnej analizy. Weryfikacja wyników poszczególnych
etapów jest więc nieunikniona.
Podstawowe cechy modelu kaskadowego niestety poka-
zują jednocześnie jego wady:
l Uzyskanie produktu spełniającego oczekiwania klienta
niezwykle silnie zależy od stabilności wymagań, która jest
przecież trudna do uzyskania.
���������������
�������
���������������
�������
Rysunek 3. Model iteracyjny
Software Developer’s Journal 10/2006
l Weryfikacja zgodności produktu z wymaganiami i jego
użyteczności następuje dopiero w końcowych krokach.
l Próba dopasowania produktu do zmieniających się wyma-
gań, powoduje znaczący wzrostu kosztów budowy systemu.
l Kolejności wykonywania prac muszą być ściśle przestrze-
gane, co niekoniecznie trzeba uważać za wadę. Warto jed-
nak zauważyć, że większość osób preferuje znacznie mniej
rygorystyczne procesy wytwarzania oprogramowania.
l Wysoki koszt błędów popełnionych we wstępnych eta-
pach jest bardzo charakterystyczną właściwością modelu
kaskadowego. Przecież błędy popełnione na etapie zbie-
rania 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.
l Częstym argumentem podnoszonym przeciwko modelowi li-
niowemu jest zmarginalizowanie roli klienta w procesie wy-
twarzania oprogramowania. Długa przerwa w kontaktach z
klientem, z którym ściśle współpracuje się podczas określa-
nia wymagań, pociąga za sobą ryzyko zmniejszenia zain-
teresowania 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 eta-
pie 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 wytwa-
rzaniu systemów informatycznych dla wojska. Standard ten
jest ścisłą realizacją modelu kaskadowego „kierowaną doku-
mentami”. 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 zreali-
zowanego etapu pozwala na rozpoczęcie kolejnego.
������
��������������� ����������
�������
�������������
������������������
����������������������
������������
�����������
�������
www.sdjournal.org 53
 Inżynieria
oprogramowania

�����
���������
������������

����� �����
�������� �����������

������� �����
�������� ������������

������� �����
�������� �������

������������� ���������

Rysunek 4. Model V

Model iteracyjny go rodzaju rozpoznania wymagań, w celu uzyskania ogólnego

W modelu iteracyjnym wymagania są porządkowane i dzie-
lone na 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 ite-
racji wybierany jest kolejny podzbiór wymagań do realizacji i
ponownie przechodzimy przez wszystkie etapy wytwarzania
oprogramowania.
Zauważmy, że takie podejście pozwala na szybką imple-
mentację przynajmniej części wymaganej funkcjonalności (tej
o najwyższym priorytecie, lub też stanowiącej najwyższe ry-
zyko niepowodzenia realizacji). Model iteracyjny pozwala więc
na bardzo szybką weryfikację realizowalności wytwarzanego
systemu i informację zwrotną od klienta, czy to, czego potrze-
buje, jest tym, co otrzyma jako produkt procesu wytwórczego.
Praktyka stosowania procesu iteracyjnego zaleca przed
rozpoczęciem rzeczywistych iteracji przeprowadzenie swe-
obrazu i zakresu projektu. Celem, jaki przyświeca tym działa-
niom, jest podział wymagań na właściwe iteracje. Takie wstęp-
ne działania polegają najczęściej na stworzeniu ogólnej archi-
tektury systemu, a niekiedy nawet jego prototypu.
Ciekawą i moim zdaniem niezwykle pożądaną odmia-
ną procesu iteracyjnego jest możliwość przekazania sys-
temu do wdrożenia, gdy tylko jakiś rozsądny podzbiór wy-
magań zostanie zaimplementowany i przetestowany. Jest to
korzystne, co najmniej z dwóch powodów: wcześniej moż-
na uzyskać pewne korzyści (nie ma co ukrywać, że chodzi
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 rzeczy-
wistych warunkach. W takich sytuacjach system można wy-
puszczać w kolejnych wydaniach, z których każde podzielo-
ne jest na pewną liczbę iteracji.

���������� �������������
����������������� ����������������

������������������������������� ������������������������
���������������������������� �������������������
�����������������������������

���������������������������
������������������ ����������������
�����������������������������������

������������������������� ������������������������

�����
����������
�������������

Rysunek 5. Model spiralny

54 www.sdjournal.org Software Developer’s Journal 10/2006

 Przegląd modeli cyklu życia oprogramowania
Bardzo często można spotkać się z pojęciem procesu przy-
rostowego, ewolucyjnego lub spiralnego, które w praktyce są tym
samym, co proces iteracyjny. Oczywiście na gruncie teoretycz-
nym 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 zo-
stał znacząco uproszczony, aby czytelnik uchwycił podsta-
wową różnicę pomiędzy tymi procesami. Praktyka pokazuje,
że oba procesy mogą podlegać bardzo wielu zaburzeniom, co
nie oznacza oczywiście, że wówczas system jest realizowany
niemetodycznie.
Często proponowanym rodzajem procesu jest tzw. etapo-
wy cykl tworzenia oprogramowania, które stanowi scalenie
modelu kaskadowego i modelu iteracyjnego. Proponuje się w
nim dokonać według modelu kaskadowego zbierania wyma-
gań, analizy i projektowania, a implementację i testowanie po-
dzielić następnie na iteracje. Wdrożenia można natomiast do-
konać po zaimplementowaniu i przetestowaniu całości wy-
magań ponownie według modelu kaskadowego lub też mo-
że to 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 po-
dejście wydaje się być z różnych przyczyn korzystniejsze za-
równo dla twórców, jak i odbiorców systemu.
Można śmiało postawić tezę, że jednym z głównych po-
wodów modyfikacji modelu kaskadowego elementami cha-
rakterystycznymi dla procesu iteracyjnego są względy finan-
sowe, a nie jak by się mogło wydawać oczywiste zalety itera-
cyjnego 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
R E K L
jest wstanie ocenić pod względem zgodności z wymaganiami
(a często niestety mało precyzyjnymi wyobrażeniami).
Model V
Rozwinięciem modelu wodospadu jest model V, charakteryzu-
jący się rozbudowaną fazą testów. Model V jest jednym z naj-
popularniejszych 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 wyma-
gania klienta.
Model V podobnie jak klasyczny model kaskadowy stwa-
rza bardzo duże niebezpieczeństwo. Oczywistym jest prze-
cież, że im później zostanie wykryty błąd lub niezgodność z
wymaganiami, tym kosztowniejsza będzie naprawa. Dzięki te-
mu, że każdy z etapów wytwórczych kończy się różnego ro-
dzaju przeglądami i inspekcjami prawdopodobieństwo poja-
wienia się błędu lub niezgodności z wymaganiami przy wdro-
żeniu i eksploatacji jest dużo mniejsze niż w modelu klasycz-
nym. Powoduje to znaczące obniżenie kosztów pielęgnacji
systemu. Dodatkowo wynikiem każdego etapu wytwórcze-
go 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).
Model spiralny
Model spiralny jest w pewnym sensie próbą formalizacji po-
dejścia iteracyjnego do wytwarzania oprogramowania. Głów-
ną cechą tego modelu jest analiza ryzyka występująca w każ-
dej iteracji. Ciągłe monitorowanie i pomiar zmian, które pod-
dawane są krytycznemu spojrzeniu użytkownika, umożliwiają
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ęp-
A M A
 Inżynieria
oprogramowania
Rysunek 6. Model prototypowania
nych zasobach (tzw. zasad trójkąta) można przejść do plano-
wania projektu i pierwszej iteracji.
Właściwie kolejne iteracje mają postać „małych” wodo-
spadó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ć kolejną iterację, a następ-
nie przeprowadzić analizę ryzyka realizacji kolejnego wyda-
nia. Model spiralny stanowi więc „obudowaną” wersję modelu
wodospadu opartą o bieżącą analizę ryzyka.
Model spiralny można postrzegać jako cyklicznie powta-
rzane cztery czynności:
l planowanie – na podstawie wymagań i celów wyznaczo-
nych przez klienta, dokonuje się określenia alternatyw i
ograniczeń oraz planowania iteracji przy każdorazowym
rozpoczęciu kolejnego cyklu spirali.
l analiza ryzyka – sprowadza się do oceny rozwiązań alter-
natywnych oraz próby identyfikacji i analizy ryzyka zwią-
zanego z każdą z możliwych alternatyw konstrukcji nowe-
go wydania.
l konstrukcja – ma postać „małego” wodospadu, a jej celem
jest wytworzenie kolejnego wydania systemu.
56 www.sdjournal.org
l ocena przez klienta – walidacja wydania i jego ocena z
możliwością modyfikacji wymagań na system (możliwość
wystąpienia modyfikacji wymagań powinna być minimali-
zowana).
Główne zalety modelu spiralnego to próba minimalizacji ry-
zyka niepowodzenia przedsięwzięcia oraz ciągła weryfikacja
produktu przez użytkownika, co ma na celu wytworzenie pro-
duktu w pełni satysfakcjonującego klienta.
Prototypowanie
Model prototypowania jest kolejną próbą radzenia sobie z pro-
blemem identyfikacji i braku stabilności wymagań. Prototy-
powanie polega na budowaniu kolejnych „przybliżeń” syste-
mu do momentu aż prototyp stanie się dobrym odzwiercie-
dleniem wymagań. Oceny prototypów i kolejne wersje owych
prototypów, w sposób bardzo naturalny prowadzą do identy-
fikacji wymagań. Zauważmy, że prototypowanie w tym przy-
padku pokrywa etap analizy wymagań i stąd często przedsta-
wiany model określa się jako „prototypowanie wymagań”. Ce-
chą charakterystyczną „prototypowania wymagań” jest budo-
wa „szybkiego projektu” bez dbałości o jego jakość i dostoso-
wanie 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śla-
ny jest mianem „prototypowania wytwórczego”.
Gdy mamy już pewność, że wszystkie wymagania zosta-
ły zidentyfikowane, wówczas można przystąpić do konstruk-
cji właściwego produktu zgodnie z modelem klasycznym wy-
twarzania oprogramowania, rozpoczynając od etapu projekto-
wania. Tego typu podejście może niekiedy spotkać się z nie-
zrozumieniem ze strony klienta, bądź też pojawić się na wyż-
szych szczeblach zarządzania firmą wykonawcy. Często po-
jawiają się pytania typu: Dlaczego trzeba zaczynać wszystko
od nowa „jeśli już prawie wszystko zrobiono”? Kolejną wadą
prototypowania jest możliwość „przyzwyczajenia się” klienta
do funkcjonalności oferowanej przez prototyp, a która nie wy-
nika z przyjętych wymagań. Również projektant może „przy-
zwyczaić się” do rozwiązań zastosowanych w prototypie. Re-
asumując, model prototypowy musi być dobrze rozumiany
przez obie strony tj. zarówno twórcę systemu informatyczne-
go, jak i klienta.
Planowanie predykcyjne i adaptacyjne
Wybór procesu wytwarzania oprogramowania bardzo silnie
zależeć będzie od stabilności wymagań. Również sposób pla-
nowania 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, za-
Literatura
l [1] Marin Fowler UML Distilled: A Brief Guide To The Standard
Object Modeling Language, Pearson Education, Inc., 2004;
l [2] Stanisław Szejko Metody wytwarzania oprogramowania,
MIKOM, Warszawa 2002;
l [3] Graham I. Inżynieria oprogramowania – metody obiektowe
w teorii i praktyce, WNT, Warszawa 2004.
Software Developer’s Journal 10/2006
 Przegląd modeli cyklu życia oprogramowania
leca się planowanie predykcyjne. Planowanie predykcyjne jest
bardzo często narzucone w projektach rządowych i dla woj-
ska. Trudno wyobrazić sobie tutaj inny sposób planowania,
ponieważ mamy najczęściej sztywną datę zakończenia i kwo-
tę 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 zosta-
nie 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 kosz-
tu wytworzenia jakiegoś produktu i czasu jego realizacji.
Powstaje jednak pytanie, czy projekty informatyczne mo-
gą 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 prak-
tycznie zawsze powodują konieczność przebudowy pierwot-
nie stworzonego planu projektu. Oczywiście można próbo-
wać walczyć z taką sytuacją. Powszechnie stosowanym spo-
sobem radzenia sobie ze zmianami „życzeń klienta” jest za-
mrożenie na pewnym etapie zbioru wymagań. Powstaje jed-
nak pewien problem. Zamrożenie wymagań powoduje ryzyko
stworzenia produktu, który właściwie nie jest potrzebny klien-
towi już w chwili wdrażania.
Można jednak inaczej próbować podejść do proble-
mu zmieniających się wymagań. Zakładamy mianowicie,
że „chaos wymagań” jest zjawiskiem nieuniknionym, a peł-
na przewidywalność to iluzja. Doskonale sprawdza się wów-
czas 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 ja-
ko 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 wpro-
wadzenia zmian niż do przewidywania, kiedy system zosta-
nia oddany w ręce klienta. W przypadku planowania adapta-
cyjnego można oczywiście na stałe określić budżet przewi-
dziany na projekt i czas jego zakończenia, jednak nie moż-
na przewidzieć zakresu wymagań, które zostaną zrealizo-
wane. Planowanie adaptacyjne wymaga ścisłej permanent-
R E K L
View publication stats
nej współpracy zespołu projektowego z klientem, a zbiór
wymagań może być dość elastycznie modyfikowany, roz-
szerzany, a niekiedy zawężany, oczywiście wszystko za po-
rozumieniem obu stron. W tego typu projektach zastosowa-
nie modelu kaskadowego z góry skazane jest na niepowo-
dzenie. Plan adaptacyjny możliwy jest do zastosowania je-
dynie w przypadku zastosowania procesu iteracyjnego i je-
go licznych modyfikacji, z których niektóre przedstawione
zostały w artykule.
Podsumowanie
Badania prowadzone w Stanach Zjednoczonych wykazały, że
ponad 2/3 wszystkich projektów informatycznych kończą się
niepowodzeniem. Niepowodzenie było najczęściej rezultatem
braku środków finansowych na kontynuowanie projektu (nie-
doszacowanie kosztów), stworzenie produktu, który nie speł-
nia wymagań klienta lub zakończenie procesu wytwarzania z
bliżej nieokreślonych względów (często politycznych).
Powodów porażki może być wiele, ale najczęściej wskazy-
wanymi były:
l brak większego zaangażowania ze strony klienta;
l zbyt ogólnie sformułowane wymagania lub ich modyfika-
cja;
l brak „właściciela” projektu;
l brak planu działania.
Wydaje się więc, że rozważania na temat procesu wytwarza-
nia oprogramowania są potrzebne, ponieważ twórcom syste-
mów informatycznych zależy na tym, aby sukces jednego pro-
jektu przekładał się na następny, aby był powtarzalny. Takie
podejście daje możliwość doskonalenia procesu wytwarza-
nia oprogramowania poprzez dokonywanie pomiarów i osza-
cowań, a to z kolei wpływa na polepszenie jakości produktu i
zadowolenie klienta.
Nie wolno zapominać, że proces wytwarzania oprogramo-
wania powinien być wspomagany przez narzędzia CASE, któ-
re oczywiście wymagają odpowiedniej konfiguracji na potrze-
by danego projektu. Umiejętność wykorzystania tego typu na-
rzędzi jest praktycznie warunkiem koniecznym powodzenia
każdego większego przedsięwzięcia informatycznego. n
A M A