Model kaskadowy to stosunkowo liniowe podejście do projektowania sekwencyjnego w niektórych obszarach inżynierii.
W rozwoju oprogramowania jest to jedno z mniej iteracyjnych i elastycznych podejść, ponieważ postęp płynie głównie w jednym kierunku w dół, jak wodospad, przez fazy koncepcji, inicjacji, analizy, projektowania, budowy, testowania, wdrażania i utrzymania. W projektach rozwoju oprogramowania fazy zazwyczaj wyglądają tak:
1. Wymagania
Jeśli zajmujesz się rozwojem oprogramowania lub jakimkolwiek zespołem zajmującym się tworzeniem projektów, chcesz znać kontekst biznesowy tego, co próbujesz stworzyć – chcesz zdefiniować, jakie problemy próbujesz rozwiązać i jak ludzie zareagują na twój gotowy produkt. Po zdefiniowaniu wszystkich tych „wymagań” masz dane wejściowe, które są potrzebne, aby przejść do następnego kroku.
2. Projektowanie
Ten krok składa się ze wszystkich kroków, które musisz wykonać, aby spełnić wszystkie wymagania, które określiłeś wcześniej. W rozwoju oprogramowania jest to część, w której definiujesz całą architekturę oprogramowania i sprzętu, język programowania, przechowywanie danych itp. To także część, w której określasz, jak projekt będzie użyteczny dla jego końcowego użytkownika.
3. Wdrożenie
W tym kroku zaczynasz budować to, co zaplanowałeś. Ta część metody kaskadowej jest poświęcona spełnieniu standardów, które ustaliłeś w poprzednich krokach. To jest część, w której ludzie z zespołu deweloperskiego wkraczają i realizują wszystkie rzeczy omówione w poprzednich krokach.
4. Weryfikacja
To jest część metody, w której wkraczają osoby odpowiedzialne za zapewnienie jakości, aby upewnić się, że zespół deweloperski nie popełnił żadnych błędów. To także najprawdopodobniej część, w której ludzie zdają sobie sprawę, co działa, a co nie działa w ich planie.
Zauważ, że
Gdy wszystkie rzeczy są spełnione przez deweloperów projektu, klient lub końcowy użytkownik wkracza i podejmuje ostateczną decyzję, czy projekt jest gotowy do uruchomienia.
Metoda kaskadowa podkreśla, że gdy coś pójdzie nie tak na danym etapie, ludzie mogą wrócić do poprzedniego, aby zobaczyć, co poszło źle. Na przykład, jeśli występuje problem w realizacji planu i ludzie wiedzą, że po prostu podążali za przekazanym im planem, menedżerowie przyglądają się swojemu planowi i dokonują poprawek.
Jakie są problemy modelu kaskadowego?
Klienci mogą nie wiedzieć dokładnie, jakie są ich wymagania, zanim zobaczą działające oprogramowanie, co prowadzi do zmiany wymagań, przprojektowania, ponownego rozwoju i testowania, a także zwiększonych kosztów.
Deweloperzy mogą nie być świadomi przyszłych trudności podczas projektowania nowego produktu lub funkcji oprogramowania, w takim przypadku lepiej jest zrewidować projekt niż trwać przy projekcie, który nie uwzględnia nowo odkrytych ograniczeń, wymagań lub problemów.
W związku z tym nie ma gwarancji, że wymagania, które organizacja wymyśliła, rzeczywiście zadziałają. Stąd zdasz sobie sprawę, że model kaskadowy ma następujące problemy:
1.Ludzie ślepo podążają za planami.
W tradycyjnej metodzie ludzie zwracają większą uwagę na to, jak rzeczy będą się działy w odpowiednim momencie, nie zwracając uwagi na to, czy rzeczy naprawdę układają się w całość. Chociaż planowanie jest ważne, równie ważne jest, aby deweloperzy i kontrolerzy jakości rozumieli, jak rzeczy powinny się dziać, szczególnie w relacji z klientem lub końcowym użytkownikiem. Ważne jest również, aby wszyscy zaangażowani w projekt mogli natychmiast powiedzieć, jak dany krok w realizacji projektu może się nie powieść, nie czekając na etap testowania.
2. Proces sekwencyjny i zmiany stają się kosztowne
To podejście nie uwzględnia zmiany zdefiniowanych wymagań w miarę postępu projektu. W związku z tym istnieje duże prawdopodobieństwo, że oprogramowanie nie spełni w pełni wymagań użytkownika, będzie nieefektywne i będzie miało słabą funkcjonalność.
Jest to niewystarczające, ponieważ deweloperzy nie mogą po prostu wrócić i zmienić coś w poprzedniej fazie, gdyż wymagania konsumentów się zmieniają, ale deweloper musi wrócić do miejsca, w którym wymaganie musi się zmienić i rozpocząć tę fazę od nowa. Dopiero po zakończeniu tej fazy może przejść do następnej.
3. Końcowi użytkownicy nie wiedzą, czego chcą.
Najczęściej umysł końcowego użytkownika ciągle się zmienia, a większość osób ma niejasne pojęcie o swoich wymaganiach dotyczących oprogramowania, a to w miarę rozwoju oprogramowania precyzują swoje wymagania.
Kiedy przychodzi czas na przekazanie gotowego produktu klientowi, prawdopodobnie nie będą zadowoleni z tego, jak to wyszło, mimo że celowo mówili inaczej w początkowych etapach. Klientom i końcowym użytkownikom łatwo jest zmieniać to, czego chcą, w miarę upływu czasu. System kaskadowy nie ma jeszcze sposobu na rozwiązanie tego, bez konieczności rewizji planów i ponownego wykonania całego projektu.
4. Testowanie jakości może ucierpieć.
Niemożliwe jest dokładne przewidzenie wyników projektu, a gdy cały zespół jest pod presją czasu, możliwe jest skrócenie etapu testowania, aby dotrzymać terminu.
5. Nigdy nie będziesz wiedział, na jakim etapie naprawdę jesteś.
Ponieważ produkt, który próbujesz stworzyć, nie zostanie wyprodukowany aż do samego końca, nie jesteś pewien, czy nadal jesteś na etapie planowania, czy już na etapie rozwoju. Oznacza to, że prawdopodobnie spędzisz więcej czasu na etapie, niż się spodziewałeś, z powodu tej słabej widoczności.
Na koniec metoda kaskadowa może być zbyt ryzykowna, ponieważ jest zbyt sztywna. Aby stworzyć produkt, który działa i byłby wystarczająco elastyczny, aby pomóc ci zrozumieć, co działa, a co nie.
Powiązane zasoby
Ten post dostępny jest również w Deutsch, English, Español, فارسی, Français, Bahasa Indonesia, 日本語, Portuguese, Ру́сский, Việt Nam, 简体中文 and 繁體中文