Model przyrostowy w SDLC: zastosowanie, zaleta i wada
Co to jest model przyrostowy?
Model przyrostowy to proces tworzenia oprogramowania, w którym wymagania są podzielone na wiele niezależnych modułów cyklu tworzenia oprogramowania. Rozwój przyrostowy odbywa się etapami, począwszy od projektowania analizy, wdrożenia, testowania/weryfikacji i konserwacji.
Każda iteracja przechodzi przez wymagania, fazy projektowania, kodowania i testowania. Każda kolejna wersja systemu dodaje funkcje do poprzedniej wersji, aż do momentu wdrożenia wszystkich zaprojektowanych funkcjonalności.
System zostaje oddany do produkcji po dostarczeniu pierwszego egzemplarza. Pierwsza aktualizacja jest często produktem podstawowym, w którym spełnione są podstawowe wymagania, a w kolejnych edycjach dodawane są funkcje dodatkowe. Po przeanalizowaniu przez klienta podstawowego produktu następuje opracowanie planu następnego przyrostu.
Charakterystyka modułu przyrostowego obejmuje
- Rozwój systemu jest podzielony na wiele mini projektów rozwojowych
- Systemy częściowe są budowane sukcesywnie w celu uzyskania ostatecznego systemu całkowitego
- W pierwszej kolejności rozpatrywane jest wymaganie o najwyższym priorytecie
- Po opracowaniu wymagania wymagania dotyczące tego przyrostu zostają zamrożone
Fazy przyrostowe | Działania wykonywane etapami |
---|---|
Analiza wymagań |
|
Wnętrze |
|
Code |
|
Testowanie |
|
Kiedy stosować modele przyrostowe?
- Wymagania systemu są jasno zrozumiałe
- Kiedy pojawia się zapotrzebowanie na wcześniejsze wydanie produktu
- Kiedy Inżynieria oprogramowania zespół nie jest zbyt dobrze wykwalifikowany ani przeszkolony
- Kiedy w grę wchodzą funkcje i cele wysokiego ryzyka
- Taka metodologia jest częściej stosowana w firmach zajmujących się aplikacjami internetowymi i produktami
Zalety i wady modelu przyrostowego
Zalety | Niedogodności |
---|---|
Oprogramowanie zostanie wygenerowane szybko w trakcie cyklu życia oprogramowania | Wymaga dobrego planowania projektowania |
Zmiana wymagań i zakresu jest elastyczna i tańsza | Problemy mogą wynikać z architektury systemu, ponieważ nie wszystkie wymagania są zbierane z góry na potrzeby całego cyklu życia oprogramowania |
Zmiany można wprowadzać na każdym etapie rozwoju | Każda faza iteracji jest sztywna i nie nakłada się na siebie |
Model ten jest tańszy w porównaniu do innych | Naprawienie problemu w jednej jednostce wymaga korekty we wszystkich jednostkach i zajmuje dużo czasu |
Klient może odpowiedzieć na każdy budynek | |
Błędy są łatwe do zidentyfikowania |