Źródło: wikipedia.org
- Kolejne etapy następują po sobie bezpośrednio: Model kaskadowy (waterfall), wodospadowy, liniowy
Zalety:
- Klient wie dokładnie czego się spodziewać. Precyzyjnie określenie tego co program będzie realizował w ostatecznej wersji.
- Możliwe całościowe oszacowanie kosztów i czasu trwania projektu.
- Projekt dobrze udokumentowany na każdym etapie
- Stabilność i bezpieczeństwo, np. dzięki dużej licznie dokumnetacji nowa osoba może byc szybko wdrożona do projektu
- Łatwy nadzór
Wady:
- Brak możliwości powrotu do poprzedniego etapu
- Początkowe założenia są bardzo istotne, projekt musi być w całości zaplanowany i wszystkie wymagania musza być rozpoznane od początku projektu
- Błąd popełniony w początkowej fazie może mieś drastyczny wpływ na całość projektu
- Produkt jest testowany wyłącznie na końcowym etapie. Późne wykrywanie błędów podnosi koszty.
- Brak uwzględnienia zmian w zapotrzebowaniu klienta, rynku, zmian w technologiach
Aktywności się przeplatają. Te same (zazwyczaj) czynności jak w modelu kaskadowym, ale pozwala się na powroty z pewnych faz do innych faz poprzedzających.
Cechy
- adaptowanie systemu do zmian w wymaganiach i korygowanie popełnionych błędów
- trudne w nadzorowaniu, wymaga dodatkowych strategii dla uporządkowania procesu wytwarzania oprogramowania
- Model przyrostowy, iteracyjny (incremental development)
- Rational Unified Process - IBM, lekka wersja OpenUP/Basic, wchodzi w skład Eclipse Process Framework
- programowanie odkrywcze
- inne…
Prototyp - niepełny system, spełniający cześć wymagań, przeznaczonym do przetestowania rozwiązań wykorzystanych do jego wytworzenia. Produkt finalny może być (z zasady jest) różny od prototypu.
Z założenia prototyp nie wchodzi w skład ostatecznego systemu.
Ostateczny system budowany jest od podstaw po zaakceptowaniu rozwiązań zastosowanych w prototypie.
Cechy:
- 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ł
- Wysoki koszt budowy systemu
Model prototypowy (Software prototyping)
- „Ogólny” model iteracyjny.
- Fazy: 1) ustalanie celów, 2) rozpoznawanie zagrożeń, 3) tworzenie, 4) ocena i planowanie
- Faza oceny w każdym cyklu pozwala uniknąć błędów lub wcześniej je wykryć
- szczegółowe potraktowanie zagrożeń realizacji projektu (duże projekty)
Określenie wymagań → podział na kolejne „przyrosty” (iteracje), funkcje systemu dające się zaimplementować i testować
Pierwsze wersje zazwyczaj ujmują podstawowe funkcjonalności systemu.
Problemem podstawowym wytwarzania przyrostowego jest określenie „przyrostów”, tak aby były one istotnymi fragmentami oprogramowania, a mimo to każdą z wersji dawało się niezależnie testować i oceniać
- zakłada, że wymagania odbiorcy (klienta) często ewoluują podczas trwania projektu → regularna adaptacja do zmieniających się wymagań
- późne zmiany w specyfikacji nie mają destrukcyjnego wpływu na proces wytwarzania oprogramowania,
- szybkie wytwarzanie oprogramowania wysokiej jakości, działające oprogramowanie jest dostarczane okresowo (tygodniowo), każda iteracja dostarcza działające i przetestowane funkcje
- bezpośredni kontakt, jako najlepsza forma komunikacji w zespole i poza nim (zazwyczaj małe zespoły), potrzeba mniej dokumentacji
- bardzo ważny jest odpowiedni nadzór nad procesem wytwórczym.
Wady:
- trudności z oszacowaniem czasu rezlizacji oraz budrzetu projektu
- wymagana duża aktywność i współpraca członków zespołu, bezpośredni kontakt nie zawsze możliwy w projektach np. open source
- sumaryczny czas wykonania projektu zazwyczaj bedzie dłuższy niż w modelu kaskadowym
- zmiany personalne w zespole moga mieć katastrofalne skutki
- końcowy produkt może znaczenie odbiegać od pierwotnych zależeń
- wydajne tworzenie małych i średnich „projektów wysokiego ryzyka”, czyli takich, w których nie wiadomo do końca, co się tak naprawdę robi i jak to prawidłowo zrobić
- krótkie iteracje, planowany wyłącznie najbliższy przyrost
- brak ogólnego planu architektury, architektura powstaje i ewoluuje wraz z projektem
- najpierw testy jednostkowe potem kod testowany (Test-driven development, TDD)
- programowanie parami: wyłapywanie błędów, wzajemna nauka
- stały kontakt z klientem, który może nawet zastąpić specyfikację
- Wikipedia
- Ilona Bluemke, Inżynieria oprogramowania