Podstawowe pojęcia system (gr. umieścić razem) zbiór lub ułożenie elementów tak powiązanych, że tworzą jedność lub ograniczoną całość; jak na przykład system słoneczny, system nawadniający; inaczej regularnie współpracująca lub współzależna grupa elementów tworzących jednolitą całość zakres obowiązków (odpowiedzialności) systemu powiązany w całości zbiór rzeczy, za które system odpowiada system informacyjny przechowywanie, przesyłanie, przetwarzanie, udostępnianie informacji system informatyczny system zautomatyzowany, skomputeryzowany, w całości lub części projektowanie cel: szybkie i bezkonfliktowe wprowadzenie zmian bez zakłócenia normalnego funkcjonowania organizacji projekt pod pojęciem projektu możemy rozumieć tworzenie nowych obiektów, wprowadzanie zmian organizacyjnych, modernizację istniejących obiektów czy też promowanie nowej usługi lub produktu; projekt jest określony przez: produkt końcowy (zakres) czas realizacji (terminy) koszty realizacji (budżet) jakość (parametr dodatkowy, czwarty wymiar) zarządzanie projektem ogół aktywności związanych z planowaniem i kontrolą projektu projekt informatyczny; przedsięwzięcie projektowe zestaw zadań, których realizacja ma doprowadzić do skonstruowania i/lub wdrożenia systemu informatycznego (systemu oprogramowania) spełniającego zdefiniowane wcześniej wymagania, w ramach określonego czasu i budżetu systemy informatyczne to szczególna klasa projektów, ze względu na złożoność, różnorodność oddziaływania; istnieje duża liczba zakończonych niepowodzeniem/niezakończonych projektów informatycznych w różnych krajach (rozmaite przyczyny), stąd prace nad doskonaleniem procesu prowadzenia projektu
próg złożoności człowiek nie jest w stanie ogarnąć w pełni wycinka rzeczywistości powyżej pewnej złożoności (objętości problemu), stąd konieczność dekompozycji i strukturalizacja problemu na mniejsze podproblemy problem różnice między aktualnym stanem a tym, co chcielibyśmy osiągnąć identyfikacja problemu proces definiowania tych różnic rozwiązanie problemu przedsięwzięcie mające na celu zniwelowanie tych różnic dziedzina problemu rozważane pole działania (wycinek rzeczywistości) abstrakcja zasada ignorowania tych aspektów rzeczywistości, które nie są istotne z punktu widzenia bieżącego celu, by móc pełniej koncentrować się na tych ważnych; nawet jeśli analityk wie o wielu rzeczach, pewne z nich przedkłada nad inne model uproszczony fragment rzeczywistości opisany przy pomocy pewnej notacji, np. z punktu widzenia struktury funkcjonalnej (DFD), struktury danych (ERD), dynamiki systemu (STD, czyli diagramy stanów) model cyklu życia oprogramowania/systemu czyli System Development Life Circle (SDLC); całość działań z okresu życia systemu: od projektowania przez eksploatację, aż po wycofanie model cyklu tworzenia (konstrukcji) oprogramowania/systemu definiowany przez kierownika projektu; dostarcza środki kontroli projektu; rodzaj przewodnika uwzględniającego cele i potrzeby projektu, np. model kaskadowy MTBF (Mean Time Between Failures) parametr charakteryzujący niezawodność systemu: średni czas pomiędzy awariami MTTR (Mean Time To Repair) parametr charakteryzujący pielęgnowalność systemu (czas przywrócenia do działania po awarii) System cechy dobrego systemu: użyteczny (spełnia postawione wymagania i realizuje cele) komfortowy w obsłudze (user friendly) bezpieczny (stopień zagrożenia dla środowiska, w którym jest zanurzony) niezawodny (parametr MTBF) pielęgnowalny (parametr MTTR) modyfikowalny, elastyczny (zmiana wymagań w czasie) niezbyt drogi co zwykle uniemożliwia osiągnięcie tych cech? niska jakość fazy analizy wymagań pominięcie wymagań i niespełnienie oczekiwań klienta częste zmiany wymagań w trakcie realizacji projektu system przestarzały po zakończeniu prac nad nim ze względu na bardzo długi czas tworzenia błędy techniczne jak zbudować dobry system? wykorzystać dobrze zdefiniowany proces projektowania: z jasno określonymi fazami, z których każda kończy się dostarczeniem produktu końcowego (np. dokumentu)
jak najwcześniej zdefiniować jasno określony zestaw wymagań koniecznie uwzględnić weryfikację i walidację (testowanie) użyć zestawu odpowiednich architektur, komponentów i narzędzi składniki systemu: komponenty (podsystemy) wzajemne powiązania komponentów granice środowisko, w którym system jest zanurzony cel istnienia wejście wyjście interfejsy (sposób w jaki środowisko może komunikować się z systemem) wymagania odnośnie powstającego systemu: funkcjonalne (co system ma robić, w tym obsługa błędów) niefunkcjonalne (parametry systemu, np. wydajność, zgodność ze starą bazą danych firmy oraz parametry projektu ich źródłem są ograniczenia sprecyzowane na etapie określenia wymagań) Fazy modelu cyklu tworzenia W zależności od definicji, jest 5 lub 6 podstawowych faz konstrukcji systemu: 1. (1A) określenie wymagań 2. (1B) analiza (modelowanie) 3. projektowanie 4. implementacja 5. instalacja i testowanie 6. konserwacja i rozwój Poniższa tabela zestawia fazy dla nieklasycznego modelu kaskadowego. Warto ją znać, bowiem te same fazy występują w pozostałych modelach w tej czy innej formie. Dokładne zapoznanie się z tym schematem powinno ułatwić ogólne zrozumienie przedsięwzięcia projektowego: Określenie wymagań Projektowanie Implementacja Testowanie Wdrożenie Konserwacja Faza strategiczna Analiza Instalacja < DOKUMENTOWANIE > Planowanie Planowanie to analiza celowości i potrzeb (odpowiada głównie na pytanie czy realizować system? ). Jest podstawą do podjęcia decyzji o ustanowieniu projektu oraz punktem wyjścia do dalszego, szczegółowego planowania. Jej podstawowym składnikiem jest faza strategiczna. Wyniki: wstępne założenia dotyczące budowy systemu, podstawowe informacje dotyczące zamierzonego przedsięwzięcia, wstępna wizja systemu, założenia jakościowe i parametry techniczne, standardy, słownik danych.
Faza strategiczna jest wykonywana zanim podjęta zostanie ostateczna decyzja o realizacji dalszych etapów (czyli np. w momencie przetargu). Jest szeregiem decyzji o dużym znaczeniu dla dalszych etapów przedsięwzięcia. Czynności tej fazy: rozmowy z przedstawicielami klienta: wstępne określenie celów przedsięwzięcia z punktu widzenia klienta (punkt odniesienia na dalszych etapach pracy), a także wstępne określenie zakresu (pozwala oszacować koszt) oraz kontekstu przedsięwzięcia ogólne określanie wymagań i wykonanie na tej podstawie zgrubnej analizy oraz projektu (również do potrzeb oszacowania kosztów) określenie wstępnego harmonogramu projektu (wykresy Gantta) określenie proponowanych rozwiązań wraz z oceną ich kosztu i ryzyka zdefiniowanie wymaganych standardów określających przebieg dalszej pracy (dobra firma korzysta wciąż z tych samych, dostosowując je tylko do potrzeb zadania) Firma informatyczna przystępuje do wstępnego projektowania systemu spełniającego określone cele, a następnie podejmuje się analizy proponowanych rozwiązań. Wyniki prezentuje się klientowi przy czym zwykle pokazuje się jedynie najlepsze, wybrane rozwiązanie. Klient może się na nie zgodzić (wtedy przedsięwzięcie przechodzi w kolejną fazę) bądź nie (co oznacza całkowite zerwanie prac albo ewentualną poprawę zgodnie ze wskazówkami). Jako, że należy dokonać oceny złożoności systemu i kosztów budowy, konieczne jest dokonanie wstępnej analizy (środki i czas ograniczone, więc nie koncentrujemy się na detalach). Decyzje strategiczne: wybór modelu cyklu tworzenia oprogramowania wybór technik stosowanych w fazach analizy i projektowania wybór narzędzia CASE wybór środowiska implementacji określenie wykorzystania gotowych komponentów podjęcie decyzji na temat współpracy z np. ekspertem z zewnątrz Faza nazywana jest strategiczną, bo decyzje podjęte w trakcie jej trwania są podstawowym warunkiem końcowego sukcesu całego przedsięwzięcia. Zakończenie sukcesem fazy strategicznej wymaga: szybkiej pracy (czynności wykonuje mała ilość pracowników w niewielkim czasie, bo budżet jest niewielki) zaangażowania kluczowych osób ze strony klienta (dobra wstępna specyfikacja wymagań) uchwycenia całościowej postaci systemu Wynik: raport wykonalności (technicznej, ekonomicznej, organizacyjnej), czyli ustalenie możliwości realizacji przedsięwzięcia, opis proponowanego rozwiązania i oszacowanie jego kosztu (raport oceny rozwiązań), opis wymaganych zasobów (pracownicy, oprogramowanie), wstępny harmonogram prac. Ocena kosztu i ryzyka poszczególnych rozwiązań Źródła trudności podczas szacowania kosztu: wielość kryteriów niepewność, tzn. żadne rozwiązanie nigdy nie jest rozwiązaniem stuprocentowo skutecznym
Przykładowe kryteria stosowane do oceny: koszt czas niezawodność stopień możliwości ponownego wykorzystania fragmentów systemu przenośność wydajność Przy wybieraniu najlepszego rozwiązania można przyjąć strategię: optymistyczną bierze pod uwagi szacunku optymistyczne pesymistyczną (konserwatywną) bierze pod uwagę szacunki pesymistyczne Aby uzyskać dokładniejsze wyniki do zestawienia rozwiązań można wprowadzić prawdopodobieństwa. Koszt szacujemy oczywiście dla każdego z proponowanych rozwiązań. Dodatkowo, dla ostatecznie wybranego, najlepszego rozwiązania ponawiamy oszacowanie tym razem dokładniej. Koszt przedsięwzięcia wyznaczają: sprzęt będący częścią systemu koszt wyjazdów i szkoleń personelu (wdrożenie zmian w działaniu organizacji) koszt zakupu narzędzi nakład pracy (najtrudniej ocenić) Sposoby szacowania: modele algorytmiczne (np. COCOMO) ocena przez ekspertów w dziedzinie ocena przez analogię z podobnymi przedsięwzięciami z przeszłości Uwaga: prawo Parkinsona mówi, że przedsięwzięcia wydłuża się tak, aby wypełnić cały założony czas pracy. Kilka słów o COCOMO (wzór roboczy: nakład [osobomiesiące ]=B KDSI a : model szacuje czas trwania projektu lub jego faz oszacowanie nakładu pracy na podstawie tysięcy linii kodu (KDSI), które finalny system będzie zawierał niedokładność oszacowań (problem z jednoznacznym zakwalifikowania projektu do odpowiedniego poziomu trudności, aby uzyskać wartości parametrów niezbędnych do wzoru) Szacowanie ryzyka to zadanie z dziedziny zarządzania ryzykiem: identyfikacja ryzyka minimalizacja prawdopodobieństwa wystąpienia jego przyczyn ewentualna redukcja efektów wystąpienia problemów, jeśli nie da się im zapobiec Rodzaje ryzyka: czasowe (harmonogram, ścieżka krytyczna) kosztowe (budżet i jego przekroczenie) jakościowe (nie spełnienie wymagań z zakresu) inne (techniczne, organizacyjne)
Nie ma srebrnych kul, ale są pewne metody minimalizacji ryzyka: stały wgląd w postęp prac, sprawdzanie rozbieżności z harmonogramem dostarczanie klientowi prototypów (ryzyko techniczne rozproszone na etapy) plan osiągania kamieni milowych Analiza Najważniejszym aspektem analizy jest zrozumienie dziedziny problemu. Analiza dzieli się na określenie wymagań i fazę modelowania. Pierwsza subfaza odpowiada na pytanie co i pod jakimi założeniami system ma robić? a druga jak system ma działać by spełnić te założenia?. Studium dziedziny problemu prowadzi do specyfikacji obserwowalnego zachowania systemu; jest to kompletne, spójne i prawdopodobne sformułowanie potrzeb podanie zarówno ilościowych, jak i funkcjonalnych charakterystyk operacyjnych (np. niezawodności, dostępności, wydajności). Trudności: zrozumienie i usystematyzowanie obszernej dziedziny problemu ustawiczne zmiany wymagań (trudność z uświadomieniem sobie kompletu wymagań przez użytkownika w jednej chwili) komunikacja międzyludzka Problematyka analizy inaczej (wg Brooks): jak zaprojektować i zbudować zbiór programów, żeby powstał system (niskopoziomowo) jak zaprojektować i zbudować program lub system, żeby powstał produkt o dużej mocy, sprawdzony, udokumentowany i stale pielęgnowany (wyższy poziom rozważań) jak utrzymać intelektualną kontrolę nad dużymi porcjami złożoności (próg złożoności) Określenie wymagań jest podobne do prowadzenia śledztwa. Składa się głównie z wywiadów prowadzonych przez analityków z pracownikami klienckiej firmy. Zespół analityków usiłuje ustalić w jaki sposób pracownicy wykonują i jak chcieliby wykonywać swoją pracę. Ważne pytania: w jaki sposób funkcjonuje bieżący system? jest ręczny czy zautomatyzowany? które dane są niezbędne do jego funkcjonowania? które są potrzebne aby działał płynnie? jakie raporty są generowane? w jaki sposób korzystają z niego użytkownicy? jakie nowe lub udoskonalone usługi trzeba wprowadzić, aby zapewnić realizację przyszłych celów? Skuteczny przebieg tego procesu jest uzależniony od: użytkownik znajomość i umiejętność formułowania wymagań, analityk systemowy pokonywanie barier komunikacyjnych: aspekty techniczne i psychologiczne, identyfikacja użytkowników/dostęp do nich, zrozumienie zakresu systemu oraz celów biznesowych systemu; analityk systemowy musi umieć wyłowić, opisać i rozumieć, na czym polegają poszczególne funkcje, jakie ma spełniać system; musi stać się ekspertem w dziedzinie działania przedsiębiorstwa
Pozyskiwanie wymagań i przygotowywanie specyfikacji to zagadnienia złożone będące funkcją: strategii, zarządzania, struktury organizacji, kompetencji użytkowników i analityków, osobistego nastawienia etc. Uwaga: na tym etapie należy już brać pod uwagę sytuacje nietypowe, bardzo głęboko analizować szczegóły. Wyniki: dokument specyfikacji wymagań, czyli zewnętrzny opis systemu (kompletne i niesprzeczne wymagania funkcjonalne i niefunkcjonalne) opisujący jego zachowanie Potem występuje faza modelowania, analizy wymagań i konstrukcji modelu logicznego. Wyniki: model logiczny systemu (CASE diagramy oraz opis abstrahujący od szczegółów implementacyjnych, opisujący sposób realizacji postawionych wymagań), szkic podręczników użytkownika, rozszerzony słownik danych Wymagania Wymagania funkcjonalne opisują funkcje (czynności, operacje) wykonywane przez system. Funkcje te mogą być wykonywane przy udziale systemów zewnętrznych. Inna definicja: jakie usługi ma oferować system, jak reagować na określone dane wejściowe, jak się zachowywać w określonych sytuacjach, czego system ma nie robić? Język naturalny jest tu często stosowaną metodą opisu, ale ma wady: niejednoznaczność, która utrudnia precyzyjny zapis; może prowadzić do różnej interpretacji tej samej treści przez różne osoby elastyczność, utrudniająca wykrycie powiązanych wymagań; może prowadzić do sprzeczności wymagań sformułowanych dla tej samej funkcji w różny sposób Notacje formalne nie mają powyższych wad, ale w większości przypadków są niezrozumiałe dla klienta, stąd mogą być jedynie uzupełnieniem zapisu słownego. Kompromisem jest stosowanie formularzy: wykorzystują język naturalny zapis podzielony na konkretne pola pozwala uniknąć szeregu błędów w określaniu wymagań uwaga: z reguły podaje się jedynie efekt działania funkcji, a nie algorytm; czasem pojawia się konieczność zastosowania konkretnego algorytmu jest to wtedy przykład wymagania niefunkcjonalnego Pola formularza opisu: Nazwa funkcji Opis Dane wejściowe Źródło danych wejściowych Wynik i przeznaczenie Warunek wstępny Warunek końcowy Efekty uboczne \ uwagi Powód (uzasadnienie)
Jak zapanować nad dużą liczbą wymagań? hierarchiczny zapis wymagań diagramy przypadków użycia (use cases) Wymagania niefunkcjonalne to ograniczenia usług i funkcji systemu (np. czasowe, standardy itd.). Mogą dotyczyć właściwości systemu takich jak niezawodność czy zajętość pamięci. Definiują również ograniczenia systemu (możliwości urządzeń wejścia wyjścia, reprezentację danych). Klasyfikacja tego rodzaju wymagań: produktowe: zachowanie produktu (wymaganie efektywnościowe: szybkość działania systemu i jego zapotrzebowanie na pamięć, niezawodność akceptowalna częstość awarii, przenośność, użyteczność) organizacyjne: wynikają ze strategii i procedur klienta i wytwórcy (standardy procesu implementowania: język, metoda oraz ograniczenia czasowe: kiedy dostarczyć produkt i dokumentację) zewnętrzne: szeroka kategoria (wymagania współpracy z innymi firmami, ograniczenia prawne, etyczne) Wymagania produktowe: użyteczność sprawność (efektywność, pamięć) niezawodność przenośność Wymagania organizacyjne: dostawcy wymagania implementacyjne standardy Wymagania zewnętrzne: współpracy etyczne prawne (ochrona prywatności, zabezpieczenia) Wymagania niefunkcjonalne trudno zweryfikować w produkcie finalnym, co zostawia duży margines do interpretacji i konfliktów przy dostarczeniu systemu. Należy uściślić kryteria oceny: cel systemu: łatwość, sposób jego działania powinien zmniejszać błędy użytkownika (możliwość używania wszystkich funkcji systemu dwie godziny po szkoleniu, średnia liczba błędów: trzy dziennie) niezawodność (średni czas bez awarii, częstość błędów) solidność (czas uruchomienia po awarii, p stwo utraty danych, procent zdarzeń powodujących awarie) przenośność (procent poleceń zależnych od platformy, liczba systemów docelowych) Dobrze sformułowane wymagania niefunkcjonalne są weryfikowalne wyrażamy je przy pomocy wielkości mierzalnych. Projektowanie Odwzorowuje wymagania organizacji w funkcje/metody. Odpowiada na pytanie: jak system ma zostać zaimplementowany bo dobrze realizował założone cele?.
projektowanie logiczne projektowanie wysokiego poziomu: określamy strukturę, komponenty, architekturę projektowanie fizyczne projektowanie niskiego poziomu Wyniki: dokumentacja projektu konstrukcyjnego (sposobu implementacji), rozszerzony słownik danych Implementacja Odwzorowuje wyniki poprzednich faz w kod. Odpowiada na pytanie: w jaki sposób system ma działać?. Wyniki: kod, dokumentacja wstępnych testów, podręczniki użytkownika i instalacyjne Testowanie i integracja Scalanie kodu w całość (sprawdzanie zgodności: funkcjonalności, poprawności, efektywności, użyteczności itd. z oczekiwaną). Wyniki: kompletne oprogramowanie, dokumentacja, dokumentacja testów, finalne podręczniki Wdrożenie Instalacja systemu, przeprowadzenie szkoleń, ewentualna reorganizacja struktury przedsiębiorstwa. Wyniki: raporty z procesu przebiegu zmian Utrzymanie Usuwanie defektów, poszerzanie funkcjonalności. Rodzaje: utrzymanie naprawcze adaptacja ulepszanie utrzymanie prewencyjne Wyniki: dokumenty i raporty
Model kaskadowy Model klasyczny: przejście do następnego etapu wymaga ukończenia prac i dostarczenia produktów etapu poprzedniego Model zmodyfikowany: faza analizy pokrywa się częściowo zarówno z fazami określania wymagań jak i projektowania; uwzględnia nie tylko kaskadowość, ale również równoległą realizację niektórych faz Główne etapy projektu są realizowane w ściśle zdefiniowanej kolejności. Każdy etap musi być zakończony przed rozpoczęciem następnego. Nie występuje (wprost) weryfikacja. Działania weryfikacyjne w ramach każdej fazy (oraz pomiędzy sąsiednimi) są dodatkową decyzja szefa projektu. Zalety: naturalność (analogia do projektów inżynierskich z innych dziedzin), zrozumiałość strukturalność modelu: cykl dobrze zdefiniowanego ciągu kroków model dobrze sprawdzony, stosowany od lat
Wady: milczące założenie, że można wytworzyć poprawną (kompletną, spójną) specyfikację wymagań już na początku projektu, co w praktyce jest niemożliwe ze względu na: trudności w wydobywaniu wymagań i uświadomieniu sobie przez użytkowników kompletu wymagań długi czas między etapem tworzenia specyfikacji (założenie że jest prawidłowa!) a dostarczeniem systemu brak weryfikacji; w trakcie projektu występują liczne zmiany w wymaganiach, więc tworzenie specyfikacji nie może być procesem zamkniętym (wymagania użytkowników zazwyczaj rosną w miarę jedzenia ); koszt błędów z etapu specyfikacji szybko rośnie z czasem co przynosi katastrofalne skutki w kontekście całego przedsięwzięcia Uwaga: przejścia do góry pomiędzy sąsiadującymi etapami występują tylko w modelu nieklasycznym. Dodatkowo na schemacie należałoby dopisać wyniki poszczególnych faz (kod, model konstrukcji oprogramowania) i pracowników (analitycy, programiści). Model kaskadowy może być używany przy krótkich projektach (np. pół roku), gdzie wymagania są dobrze określone i zrozumiałe, a specyfikacja w pełni przygotowana (projekty na studiach). Długie projekty można próbować dopasować do modelu kaskadowego poprzez m. in. właściwą procedurę zarządzania zmianami specyfikacji oraz dobrą współpracę z klientem/użytkownikiem, ale tak czy inaczej lepiej odwołać się do bardziej nowoczesnych metod. Realizacja kierowana dokumentami Model zaproponowany przez armię amerykańską: ścisła realizacja modelu kaskadowego. Szereg faz następujących po sobie, a każda z nich kończy się opracowaniem dokładnie zestandaryzowanych dokumentów. Dokumenty te udostępniane klientowi są podstawą do realizacji kolejnych faz dopiero po ich zaakceptowaniu przedsięwzięcie można kontynuować. Zalety: łatwe planowanie i harmonogramowanie łatwy monitoring przedsięwzięcia możliwość dalszej realizacji przedsięwzięcia przez inną firmę, jeśli aktualna zawiedzie; wszystko to dzięki ścisłym standardom produkcji dokumentów opisujących projekt Wady: duży nakład pracy na opracowanie dokumentów zgodnych ze standardem (ponad 50% nakładów) przerwy niezbędne do weryfikacji dokumentów przez klienta
Model przyrostowy Fazy: określamy całość wymagań, następnie wykonujemy ogólny projekt systemu teraz wybieramy pewien podzbiór funkcji systemu (wg ważności to, co najważniejsze na początku) tworzymy szczegółowy projekt podzbioru (wg modelu kaskadowego) i przechodzimy do jego implementacji testujemy zrealizowany fragment i dostarczamy go klientowi powtarzamy proces od punktu drugiego, aż do ukończenia całości Zalety: częste kontakty z klientem brak konieczności zdefiniowania z góry wszystkich wymagań klient wykorzystuje fragmenty systemu dość wcześnie, może wpływać na kierunek prac jeżeli wystąpią opóźnienia w jakiejś fazie realizacji, można próbować je zniwelować w kolejnej Wady: dodatkowy koszt związany z niezależną realizacją podzbiorów trudności z wycinaniem podzbioru funkcji w pełni niezależnych w efekcie powstaje konieczność implementowania szkieletów (interfejsów zgodnych z systemem docelowym),
będąca dodatkowym nakładem pracy i dodatkowym ryzykiem, że coś umknie nam podczas testów Uwagi: model stosowany w przypadkach, gdy dopuszczalna jest okrojona funkcjonalność systemu finalnego przyrosty nie mogą być duże (<= 20 000 linii kodu) ewolucją tego podejścia jest programowanie ekstremalne
Prototypowanie Cel: minimalizacja ryzyka związanego z niewłaściwym określeniem wymagań wczesne wykrycie brakujących funkcji, trudnych usług Fazy: ogólne określenie wymagań budowa prototypu i jego weryfikacja przez klienta pełne określenie wymagań realizacja pełnego systemu zgodnie z modelem kaskadowym Zalety: możliwość szybkiej demonstracji działającego systemu możliwość rozpoczęcia szkoleń przed zbudowaniem systemu testowanie równoległe (prototypu i systemu finalnego)
Wady: dodatkowy koszt budowy prototypu (choć rekompensuje to skutecznie spadek kosztów za błędy popełnione w fazie specyfikacji wymagań) potencjalne zdziwienie klienta ( dlaczego nie możemy dostać tego prototypu już teraz, za połowę ceny? ) Prototyp jest systemem ograniczonym. W zasadzie tylko nieliczne z jego fragmentów wykorzystuje się przy implementacji finalnego systemu, bowiem prototyp jest projektowany na szybko z pominięciem szczegółowej fazy testowania i bez zwracania większej uwagi na efektywność świadczonych usług.
Prototypowanie wytwórcze Przedstawiciel tzw. współczesnych cyklów wytwarzania, tzn. dających oprogramowanie o wyższej jakości: bardziej niezawodne, efektywne, użyteczne. Prototypowanie konstrukcji weryfikowanie hipotez projektowych dające odpowiedź na pytania takie jak: poprawność bądź efektywność rozwiązania itp. Prototypowanie wymagań szczególna analiza wymagań (faza określania wymagań analizy) Prototypowanie wytwórcze wiąże p. konstrukcji i p. wymagań: projekt (logiczny), potem dodawanie elementów konstrukcyjnych (konstrukcja szczegółowa) specyfikacja opis struktury statycznej i dynamicznej systemu oraz jego działania (realizacja funkcji i obsługa wyjątków) prototyp konstrukcyjny powstaje na bazie specyfikacji
Model spiralny Fazy (cztery, wykonywane cyklicznie): planowanie (nowej wersji) analiza ryzyka konstrukcja testowanie Planowanie: ustalane są generalne cele produkcji kolejnej wersji systemu Analiza ryzyka: rozważane są ogólne opcje budowy nowej wersji analiza możliwości realizacji (technicznej, ekonomicznej, organizacyjnej) może obejmować budowę prototypu Konstrukcja: tworzenie kolejnej wersji przybliżenia systemu (np. zgodnie z modelem kaskadowym) Testowanie: ocena przez klienta kolejnej wersji systemu (rozpoczynamy kolejny cykl, jeśli ocena nie jest w pełni pozytywna) Zalety: zmniejszenie ryzyka wprowadzenie oceny przez użytkownika dobry dla firm wytwarzających oprogramowanie rynkowe
Wady: przydatny jedynie w wypadku systemów, które można wdrożyć przy ograniczonej funkcjonalności i obniżonej jakości osiągnięcie wersji docelowej zajmuje dużo czasu Ocena praktyczna modeli Nie ma jednoznacznej odpowiedzi na to, którego warto używać w praktyce. Każdy z nich ma specyficzną dla siebie przydatność zależną od sytuacji: model kaskadowy: dobry przy dobrze zdefiniowanych wymaganiach i dobrze rozumianych zastosowaniach (krótkie projekty) prototypowanie: dobry dla nowatorskich zastosowań model przyrostowy: tam, gdzie dopuszcza się okrojoną funkcjonalność (duże projekty) model spiralny: tam, gdzie nieostro określone wymagania, brak fazy specyfikacji, ryzyko Modele nie wykluczają się nawzajem, np. model kaskadowy może być użyty w fazie konstrukcji modelu spiralnego, albo w fazie budowy finalnego systemu w modelu prototypowym. Wybór sposobu prowadzenia przedsięwzięcia to jedna z najważniejszych decyzji, mogąca zaważyć na jego losach.