Cykl życia projektu –
model prototypowy i
kaskadowy
Wstęp
Produkcja i eksploatacja
oprogramowania jest pewnym
procesem, który powinien być
realizowany w systematyczny sposób.
Używa się do tego tzw. Modeli cyklu
życia oprogramowania, modele te
wprowadzają pewne fazy życia
oprogramowania, określają czynności
wykonywane w poszczególnych fazach
oraz ustalają kolejność ich realizacji.
Model kaskadowy
Model kaskadowy , zwany też modelem wodospadu
lub liniowym, jest klasycznym modelem cyklu życia
oprogramowania. Jest to model, który został
zaproponowany poprzez analogię do sposobu
prowadzenia przedsięwzięć w innych dziedzinach
inżynierii, na przykład budownictwie. Budowa mostu
rozpoczyna się od określenia głównych zadań jakie
ma on spełniać, a następnie szczegółowego
określenia wymagań, które zapewnią realizację tych
zadań. Kolejnym krokiem jest wykonanie
szczegółowego projektu konstrukcji. Dalej następują
faza budowy oraz testowania wybudowanego
mostu. Ostatnim etapem jest faza konserwacji. Model
kaskadowy cyklu życia oprogramowania wprowadza
analogiczne fazy (jak na rysunku):
Kaskadowy
model cyklu
życia oprogramowania
Fazy modelu
kaskadowego
• Faza określenia wymagań - określane są cele oraz
szczegółowe wymagania wobec tworzonego systemu.
Dobry opis wymagań powinien: być kompletny oraz
niesprzeczny, opisywać zewnętrzne zachowanie systemu a
nie sposób jego realizacji, obejmować ograniczenia przy
jakich musi pracować system, być łatwy w modyfikacji, brać
pod uwagę przyszłe możliwe zmiany wymagań wobec
systemu, opisywać zachowanie systemu w niepożądanych
sytuacjach.
• Faza projektowania w której powstaje szczegółowy
projekt systemu spełniającego ustalone wcześniej
wymagania. W fazie projektowania wykonywane są
następujące czynności: uszczegółowienie wyników analizy,
projektowanie składowych systemu nie związanych z
dziedziną problemu, optymalizacja systemu, dostosowanie
do ograniczeń i możliwości środowiska implementacji,
określenie fizycznej struktury systemu.
• Faza implementacji (kodowania) w której projekt zostaje
zaimplementowany w konkretnym środowisku
programistycznym oraz wykonywane są testy
poszczególnych modułów
• Faza testowania, w której następuje integracja
poszczególnych modułów połączonych z testowaniem
poszczególnych podsystemów oraz całego
oprogramowania. Testowanie ma dwa główne cele:
wykrycie i usunięcie błędów w systemie, ocenę
niezawodności systemu.
• Faza konserwacji, w której oprogramowanie jest
wykorzystywane przez użytkownika a producent dokonuje
konserwacji oprogramowania- wykonuje modyfikacje
polegające na usuwaniu błędów zmianach i rozszerzenia
funkcji systemu. Podstawowe rezultaty konserwacji to
poprawione kod, projekt, model i specyfikacja wymagań
• Faza strategiczna wykonywana przed formalnym
podjęciem decyzji o realizacji przedsięwzięcia. W tej fazie
podejmowane są strategiczne decyzje dotyczące dalszych
etapów prac. Faza ta wymaga przynajmniej ogólnego
określenia wymagań.
• Faza dokumentacji, w której wytwarzana jest
dokumentacja użytkownika. Opracowywanie
dokumentacji przebiega równolegle z produkcją
oprogramowania. Faza ta może rozpocząć się
już w trakcie określania wymagań. Sugeruje się
nawet, że podręcznik użytkownika dla
przyszłego systemu jest dobrym dokumentem
opisującym wymagania. Ostatnie zmiany w
dokumentacji dokonywa są w fazie instalacji.
• Faza instalacji, w której następuje przekazanie
systemu użytkownikowi.
• Jeśli któraś z faz zwróci nie satysfakcjonujący
produkt cofamy się wykonując kolejne iteracje
aż do momentu kiedy otrzymamy
satysfakcjonujący produkt na końcu schodków.
Wady modelu
kaskadowego
• Narzucenie twórcom oprogramowania ścisłej
kolejności wykonywania prac. Osoby
pracujące nad oprogramowaniem preferują
mniej regorystyczny styl pracy.
• Wysoki koszt błędów popełnionych we
wstępnych fazach. Błędy popełniane w fazie
określania wymagań zostaną
najprawdopodobniej wykryte dopiero w fazie
testowania lub konserwacji. Ich koszt może
o rzędy wielkości przewyższać koszt błędów
popełnionych np. w fazie implementacji.
• Długa przerwa w kontaktach z klientem.
Faza strategiczna oraz określania
wymagań i analizy realizowane są w ścisłej
współpracy z klientem. Projektowanie,
implementacja i w dużej mierze
testowanie wykonywane są wyłącznie
przez firmę programistyczną. Pojawia się
więc ryzyko zmniejszenia zainteresowania
klienta przedsięwzięciem w czasie gdy nie
bierze on bezpośredniego udziału w jego
realizacji
Zalety modelu
kaskadowego
• Rozliczenie finansowe z klientem na
początku
• Po każdej fazie wymusza kończenie
dokumentacji
• Formalny odbiór poszczególnych
etapów, monitorowanie postępu
pracy
• Łatwość budżetowania
– Na temat praktycznej przydatności modelu kaskadowego
wypowiada się skrajnie różne opinie. Z jednej strony
twierdzi
się,
że
praktycznie
żadne
rzeczywiste
przedsięwzięcie programistyczne nie zostało
zrealizowane zgodnie z nim. Inni autorzy twierdzą,
że zdecydowana większość rzeczywistych przedsięwzięć
przebiega zgodnie z modelem kaskadowym. Ta różnica
zdań wynika z faktu różnej interpretacji tego modelu.
Interpretacja ścisła traktuje poszczególne fazy jako
konkretne okresy realizacji przedsięwzięcia, okresy,
które nie nakładają się na siebie i są wykonywane
ściśle sekwencyjnie bez żadnych iteracji.
– Interpretacja ogólna zakłada, że poszczególne fazy
mają znaczenie bardziej koncepcyjne, poszczególne
fragmenty systemu mogą np. znajdować się w
tym samym czasie na różnych etapach realizacji.
Interpretacja ta dopuszcza także iteracje — nawroty do
wcześniejszych faz modelu
Model prototypowy
Jedną z wymienionych wcześniej wad modelu
kaskadowego jest duży koszt błędów popełnionych w
fazie określania wymagań. W związku z tym model ten
zalecany jest dla realizacji systemów, w wypadku
których określenie wymagań jest stosunkowo łatwe.
Typowym przykładem są tutaj systemy informatyczne w
prosty sposób automatyzujące pracę pewnych
organizacji, tj. automatyzujące przechowywanie i
wyszukiwanie danych oraz realizację pewnych prostych
operacji. Takie systemy wykonują więc praktycznie
wyłącznie funkcje, które były już realizowane w
danej organizacji bez wykorzystania technologii
komputerowej. Systemy informatyczne pozwalają
jednak także na wprowadzanie funkcji, praktycznie
niewykonalnych bez stosowania komputerów, np.
złożonych analiz, optymalizacji produkcji, wspomagania
decyzji, czy automatycznego sterowania produkcją.
Ścisłe zdefiniowanie przez klienta wymagań wobec tak
nowatorskich funkcji może być bardzo trudne.
Prototypowanie (ang. prototyping) jest modelem,
którego celem jest minimalizacja ryzyka związanego z
niewłaściwym określeniem wymagań.
Głównym celem realizacji prototypu jest lepsze określenie
wymagań, czyli:
– wykrycie nieporozumień pomiędzy klientem a
twórcami systemu,
– wykrycie brakujących funkcji,
– wykrycie trudnych usług,
– wykrycie braków w specyfikacji wymagań.
Fazy modelu
prototypowego
• Faza wymagań
• Faza specyfikacji
• Faza projektu
• Faza implementacji
• Faza integracji
• Faza konserwacji
• W fazie wymagań tworzony jest prototyp
systemu, realizujący część funkcji
systemu, budowany, aby ustalić
wymagania. Jeżeli spełnia wymagania,
tworzona jest specyfikacja. Ponieważ
prototyp został zatwierdzony przez
klienta, mało prawdopodobne jest
cofanie się w kolejnych fazach do faz
poprzednich. Zaletą tego modelu jest to,
że klient może wcześnie testować
produkt, natomiast wadą - jeśli nie
pozbędziemy się prototypu, produkt
będzie nieefektywny.
Omówienie poszczególnych
faz:
• Faza określenia wymagań- Klient określa
cele, jakie powinien spełniać zamawiany
system. Na tym etapie nie wiemy jeszcze,
czy w ogóle przyjmiemy zamówienie. W tej
fazie badamy środowisko, w jakim będzie
działał system, jakie są jego ograniczenia,
kto będzie wykorzystywał program w swojej
pracy. Przedstawiamy klientowi możliwe
rozwiązania i sugerujemy rozwiązanie
najlepsze. Następnie szacujemy koszty i
przedstawiamy wstępny harmonogram prac.
Uwaga! Należy rozróżnić zleceniodawcę
systemu od jego przyszłych użytkowników. To
ich zdanie jest dla nas najistotniejsze.
• Faza specyfikacji - Dokładna analiza
systemu, bierze się pod uwagę te
czynniki, które mogą wpłynąć na
decyzje projektowe, kontekst projektu,
organizaji itd. W efekcie powstaje
dokument specyfikujący wymagania
systemu, jego funkcjonalność.
• Faza projektowania -Stworzenie
szczegółowego projektu,
uwzględniającego ustalone wcześniej
wymagania
• Faza implementacji - Kodowanie i
testowanie poszczególnych modułów,
faza ta powinna być jak najbardziej
mechaniczna, oparta na projekcie
opracowanym w fazie wcześniejszej
• Faza integracji - Łączenie modułów
w całość, testowanie systemu
• Faza konserwacji- Przekazanie
klientowi systemu, konfiguracja,
szkolenie użytkowników
Proponowane, niewykluczające
się, metody budowy prototypu:
• Niepełna realizacja. Z reguły tylko część wymagań wobec
systemu jest trudna do określenia. W związku z tym
proponuje się, aby w ramach prototypu ująć tylko te funkcje
systemu.
• Użycie języków wysokiego poziomu.
• Wykorzystanie gotowych komponentów.
• Generatory interfejsu użytkownika. Realizacja prototypu
często polega wyłącznie na realizacji interfejsu
użytkownika. Przydatne są więc wszelkie narzędzia
ułatwiające szybką realizację interfejsu.
• Szybkie programowanie . Prototyp może polegać na
realizacji wszystkich funkcji systemu z wykorzystaniem
tych samych technik, które będą stosowane przy
realizacji pełnego systemu. Prace przyspiesza się jednak
poprzez zaniechanie, np. procedur testowania. W
związku z tym prototyp różni się od końcowego
systemu przede wszystkim niezawodnością.
• Prototyp na papierze. Jest to szybka i
stosunkowo lubiana przez klientów forma
prototypowania interfejsu użytkownika.
• Programowanie odkrywcze.
Ponieważ podstawowym zadaniem
prototypu jest pomoc w lepszym
określeniu wymagań, budowę i weryfikację
prototypu można uznać za specyficzny
sposób realizacji fazy określania wymagań
tradycyjnego modelu kaskadowego.
Wady modelu
prototypowego
• Możliwość nieporozumień z klientem
(klient widzi prawie gotowy produkt,
który w rzeczywistości jest dopiero w
początkowej fazie rozwoju)
• Wysoki koszt budowy systemu
Zalety modelu
prototypowego
• Prototyp jest łatwy do zmiany
• Zwiększa zrozumienie programistów
co do potrzeb klienta
• Pozwala klientowi zobaczyć jak mniej
więcej system będzie wyglądał
• W zależności od rodzaju prototypu,
może pozwalać rozpocząć szkolenie
obsługi systemu po stronie klienta
• Redukcja kosztów