Model Waterfall lub metoda kaskadowa została opisana po raz pierwszy w 1970 roku przez Winstona W. Royce w artykule „Managing the Development of Large Software Systems” (Zarządzanie tworzeniem dużych systemów informatycznych). Jest to liniowe podejście do zarządzania projektami przechodzące przez sześć etapów: planowania, analizy, projektowania, implementacji, testowania i wdrożenia. Jest to jedno z najmniej elastycznych podejść do zarządzania projektami. Im późniejsza faza, tym ciężej wprowadzić zmiany. Jednakże ma ona również swoje plusy, które przedstawię poniżej.
Wróćmy jeszcze na chwilę do historii.
Pierwsza znana prezentacja opisująca próbę wykorzystanie sześciu faz w inżynierii oprogramowania odbyła się w Herbert D. Benington na Sympozjum na temat zaawansowanych metod programowania dla komputerów cyfrowych w dniu 29 czerwca 1956r. Prezentacja ta dotyczyła rozwoju oprogramowania. Jednakże w 1983r. kiedy to artykuł został ponownie opublikowany, wskazano w nim, że proces ten nie był do końca faktycznie wykonywany w ścisły sposób z góry na dół.
Natomiast pierwszy formalny opis modelu tak jak pisałam na samym początku, jest często cytowany jako artykuł z 1970 r. Autorstwa Winstona W. Royce'a, chociaż Royce nie użył terminu "waterfall" w tym artykule. Royce przedstawił ten model jako przykład wadliwego, niedziałającego modelu.
Najwcześniejsze użycie terminu "waterfall" mogło być w artykule z 1976 r. Autorstwa Bell and Thayer.
W 1985 r. Departament Obrony Stanów Zjednoczonych uchwycił to podejście w standardach dotyczących współpracy z wykonawcami oprogramowania oraz stwierdził, że wykonawca wdroży cykl tworzenia oprogramowania, który obejmuje sześć faz planowania.
Sześć faz projektowych, gdzie każda czynność to kolejny schodek w projekcie:
- Planowanie. Wszystkie wymagania dotyczące projektu są spisywane i udokumentowane.
- Analiza. Badane są wszystkie wymagania, aby osiągnąć cel projektu.
- Projektowanie. W tej części następuje projektowanie poszczególnych struktur systemu.
- Implementacja. Wytwarzanie kodu, testowanie poszczególnych elementów.
- Testowanie. Testowanie całości kodu, najpierw wewnętrznie, a następnie w środowisku klienta.
- Wdrożenie. Wdrożenie systemu u klienta oraz jego pielęgnacja. Wydawanie poprawek, jeżeli jest to wymagane.
Jeżeli w naszej metodzie zarządzania, któryś z punktów da nam niesatysfakcjonujący wynik, cofamy się i wykonujemy go ponownie, dopóki na końcu nie osiągniemy zaplanowanego celu. Krok A musi zakończyć się sukcesem, aby przejść do kroku B.
Metodę Waterfall stosuje się w projektach, które można z góry ściśle określić. Czyli wymagania są zrozumiałe i przejrzyste, cel jest ściśle zdefiniowany. Jest to bardzo ważne, gdyż każda zmiana w projekcie kaskadowym jest czasochłonna oraz wymaga dużych dodatkowych środków finansowych. Metoda ta jest powszechnie używana w szczególności, kiedy projekty są duże.
Zalety:
Bardzo duża szczegółowość. Planowanie stoi tutaj na pierwszym miejscu, jest ono najważniejsze, aby osiągnąć sukces w projekcie. Wszystkie elementy są szczegółowo doprecyzowane. Dokumentacja jest, powinna być prowadzona z wyjątkową dokładnością, co z korzyścią przekłada się na losy prowadzonego projektu, jak również jest dobrym wzorem na przyszłość.
Rezultaty zgodne z oczekiwaniami. Koszty, harmonogram jest zgodny z oczekiwaniami klienta, ponieważ wszystko zostało dokładnie zaplanowane, nakreślone w pierwszych fazach projektu. Zostało zaakceptowane przez klienta po szczegółowym długim planowaniu.
Jest nadany odpowiedni rytm projektowi. Każdy element jest szczegółowo opisany oraz przypisany co niweluje ewentualne spięcia, oraz konflikty przy realizacji zadań. Dzięki szczegółowej dokumentacji nowi członkowie zespołu mogą się szybko odnaleźć. Natomiast przy całkowitej zmianie zespołu projektowego nie następują duże przesunięcia w czasie, gdyż wystarczy tylko zapoznać się z dokumentacją.
Wady:
Problemem jest powrót do wcześniejszej fazy. Może on powodować duże koszty oraz duże zmiany w harmonogramie. Przy niektórych projektach taki powrót jest wręcz niemożliwy i kończy się on zamknięciem projektu. Powroty takie wiążą się z wyrzuceniem do kosza czasami wielu linii kodu. Dlatego tez przy ustalaniu projektu klient powinien być pewny, czego potrzebuje.
Testy całej pracy są wykonywane dopiero pod koniec danego cyklu, dlatego też ta faza pochłania bardzo dużo czasu. Należy tutaj wyeliminować wszystkie błędy, jakie powstały przy integracji kodu lub przy wyeliminowaniu wszystkich defektów.
Oczekiwania klientów często ewoluują w trakcie realizacji projektu. Jeżeli są to małe zmiany, to można sobie z nimi poradzić. Jeżeli zmiany są duże, to są one niemożliwe do wprowadzenia.
Przy wyborze tego modelu zarządzania naszym projektem musi pamiętać o tym, czy cel jest jasny, sprecyzowany, przejrzysty (najlepiej użyć tutaj metody SMART do jego osiągnięcia). Musimy zadbać odpowiednio o dokumentacje oraz o dokładny plan działania i wtedy można działać.