Ź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 prototypowy
• Model spiralny
• Model przyrostowy, iteracyjny (incremental development)
• Programowanie zwinne (Agile software development) Manifest Agile, Scrum
• Programowanie ekstremalne
• 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ę

1. Wikipedia
2. Wykład "Inżynieria oprogramowania" - Dawid Czerner
3. Ilona Bluemke, Inżynieria oprogramowania
4. Software development methodology