[Trochę teorii -cz.1] Podstawy teoretyczne metodyk tradycyjnych

Metoda kaskadowa, czyli jedna z tradycyjnych praktyk wytwarzania oprogramowania(1), do 2005 roku była przodującą metodą prowadzenia projektów(2).

Model waterfall (wodospad), czyli metoda kaskadowa, nazwę wziął ze schematu kolejnych faz, które następują jedna po drugiej. Model został pierwszy raz przedstawiony przez Herberta D. Beningtona (1956 r, konferencja Sympozium on Advanced Progamming Methods for Digital Computers). Pierwszy formalny opis to artykuł „Mana- ging the Development for Large Software Systems” opublikował dr Winston W. Royce w 1970 (3).

W modelu kaskadowym projekt rozpoczyna się na szczycie modelu, od pierwszej fazy, następnie po zakończeniu prac w pierwszej fazie projekt płynnie przechodzi do kolejnego etapu. Waterfall powstał na podstawie obserwacji organizacji pracy w fabrykach i przy projektach budowlanych(4). Wszystkie prace rozpoczynają się zebraniem szczegółowych wymagań, na podstawie których w kolejnym etapie eksperci planują ich realizacje, po czym następuje wykonywanie pracy, testowanie i dalsze utrzymanie. Bardzo istotne w przypadku modelu kaskadowego jest to, że poprzedni etap musi się formalnie zakończyć (oficjalne przekazanie projektu do kolejnej fazy) by mógł rozpocząć się następny(5). W pierwotnym opisie, waterfall miał 7 faz (wymagania systemu, wymagania oprogramowania, analiza, projekt programu, kodowanie, testowanie, użytkowanie), jednak obecnie najczęściej mówi się o 5 krokach (analiza, projektowanie, implementacja, testowanie, utrzymywanie). Zdarza się, że na początku procesu dodaje się fazę początkową, planującą realizacje projektu (planowanie). Fazy modelu kaskadowego przedstawione zostały na rysunku 1.1.

Rysunek 1.1. Fazy modelu kaskadowego

Cechy charakterystyczne waterfall to:

• proces jest sekwencyjny, kolejne fazy następują po ukończeniu wcześniejszych;
• zdefiniowanie przez użytkownika szczegółowych wymagań na początku projektu, na podstawie samej wizji;
• konieczność stabilizacji środowiska biznesowego, bez możliwości zmian w wymaganiach w trakcie trwania projektu;
• tworzenie pełnej formalnej dokumentacji projektowej umożliwiającej wykonawcom wytworzenie właściwego projektu, w pełni spełniającego te wymagania(6).

Projekt odnosi sukces, gdy wszystkie wymagania będą zrealizowane, nie zostaną przekroczone terminy ani budżet, a otrzymany projekt będzie spełniał wymagania jakościowe(7). Zaskakujący może wydać się fakt, że takie podejście do wytwarzania oprogramowania już przez autora zostało uznane za podatne na błędy:

„Wierzę w ten koncept, ale implementacja opisana powyżej jest ryzykowna i naraża się na porażkę”(8).

 Wynikało to głównie z umieszczenia testowania na końcu procesu oraz bardzo kosztownym wprowadzaniem poprawek szczególnie, gdy wymagania po zrealizowaniu projektu okazywały się błędne lub założona implementacja niemożliwa do wykonania(9).Metoda kaskadowa jest pożądana głównie przez managerów, którzy widzą w nim szanse na przewidywalność i możliwość kontrolowania kosztów i harmonogramu projektu(10). Niestety proces wytwarzania oprogramowania metodą kaskadową najczęściej okazywał się powolny, nieprzewidywalny(11), a końcowy produkt zwykle nie spełniał oczekiwań klientów, co wiązało się z trudnościami w uzyskaniu zapłaty za wykonaną pracę. Związane to było najczęściej niepewnymi wymaganiami, ulegającymi znacznej zmianie w czasie, dużymi kosztami wprowadzania zmian, spowodowanymi brakiem iteracji w procesie wytwórczym, błędami wykrywanymi na etapie testowania po zakończeniu fazy implementacji oraz integracją modułów na końcu etapu wytwarzania, co powodowało późne wykrycie błędów integracyjnych i jeszcze bardziej wydłużało projekt. Model kaskadowy można w wytwarzaniu oprogramowania zastosować z bardzo dobrym rezultatem, ale wymaga to rygorystycznego spełnienia warunków: niezmienności wymagań i zakresu projektu, doskonałej znajomości technologii przez zespół, perfekcyjnego zrozumienie wymagań biznesu przez zespół projektowy, bezbłędnego oszacowanie zakresu prac oraz brakiem zakłóceń, wynikających np. dostępności wszystkich osób zaangażowanych w proces(12).