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

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

• 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

Document Outline