plik

Inżynieria

oprogramowania

www.sdjournal.org

Software Developer’s Journal 10/2006

Przegląd modeli

cyklu życia oprogramowania

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.

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-

Rafał Kasprzyk

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

Rysunek 1.

Programowanie odkrywcze

��

Przegląd modeli cyklu życia oprogramowania

www.sdjournal.org

Software Developer’s Journal 10/2006

ś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:

Uzyskanie produktu spełniającego oczekiwania klienta

niezwykle silnie zależy od stabilności wymagań, która jest

przecież trudna do uzyskania.

Weryfikacja zgodności produktu z wymaganiami i jego

użyteczności następuje dopiero w końcowych krokach.

Próba dopasowania produktu do zmieniających się wyma-

gań, powoduje znaczący wzrostu kosztów budowy systemu.

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.

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.

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.

Rysunek 2.

Model kaskadowy

��

Rysunek 3.

Model iteracyjny

��

Inżynieria

oprogramowania

www.sdjournal.org

Software Developer’s Journal 10/2006

Model iteracyjny

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-

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

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 4.

Model V

��

Rysunek 5.

Model spiralny

��

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

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-

Inżynieria

oprogramowania

www.sdjournal.org

Software Developer’s Journal 10/2006

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:

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.

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.

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ą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

[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.

Rysunek 6.

Model prototypowania

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-

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:

brak większego zaangażowania ze strony klienta;

zbyt ogólnie sformułowane wymagania lub ich modyfika-

cja;

brak „właściciela” projektu;

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