Modele budowy aplikacji dzielą się tak naprawdę na dwie grupy – tych, w których pokazujemy klientowi prototypy i tych, w których klientowi pokazujemy jedynie elementy skończone. Kiedy ten pierwszy jest lepszy i bezpieczniejszy w ramach relacji pracownicy – klient (można demonstrować działanie całości na długo przed ukończeniem prac i ewentualne uwagi dostać jak najwcześniej), ta druga grupa dużo lepiej działa dla programistów, bo tworzone są elementy skończone, nie zaś takie, które potem trzeba dopracowywać. Przykładem takiego modelu jest „model kaskadowy”, zaproponowany w tysiąc dziewięćset siedemdziesiątym roku przez Winstrona W. Royce’a w artykule naukowym „Managing the Development of Large Software Systems”. Kaskada w tym przypadku ma odpowiadać rodzajowi wodospadu, który płynąc zbiega po wielu niedużych „schodach”, jednocześnie zachowując połączenie z poprzednim. Dlatego tutaj każdy krok programowania polega na połączeniu z poprzednim „schodkiem” i – w wypadku, gdy któryś ze „schodków” okaże się nie spełniać założeń – możliwości powrotu. Te zejścia dzielą się na planowanie i specyfikację wymagań, analizę w której ustalimy, ile „sensu” mają założenia i na ile da się je zrealizować (relacja „fundusze / praca” i „praca / osoba”). Następnie następuje projektowanie, gdzie ustalamy jak co ma działać, w końcu implementacja – łączenie w całość. Potem zostaje testowanie (części i programu jako całości) i wdrożenie.