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