W klasycznym, uporządkowanym ujęciu procesu wytwarzania oprogramowania (często omawianym w szkole jako model "krok po kroku") etapy wynikają z tego, że kolejny etap korzysta z efektów poprzedniego.
1) Analiza wymagań klienta polega na zebraniu i zrozumieniu potrzeb: co system ma robić, dla kogo, w jakich ograniczeniach. Bez tego łatwo stworzyć funkcje nieprzydatne albo pominąć krytyczne scenariusze.
2) Specyfikacja wymagań porządkuje wynik analizy i zapisuje go w sposób jednoznaczny (np. wymagania funkcjonalne i niefunkcjonalne, kryteria akceptacji). Specyfikacja jest podstawą do projektowania, implementacji oraz przygotowania testów.
3) Tworzenie (implementacja) to budowa aplikacji zgodnie z ustalonymi wymaganiami. W tym momencie powstaje kod, konfiguracja i elementy niezbędne do uruchomienia rozwiązania.
4) Testy następują po implementacji, bo trzeba mieć co weryfikować. Testowanie (jednostkowe, integracyjne, systemowe) ma wykryć błędy oraz sprawdzić zgodność z wymaganiami przed udostępnieniem użytkownikom.
5) Wdrażanie jest na końcu, ponieważ oznacza udostępnienie aplikacji na środowisku docelowym (np. produkcyjnym). Wdrożenie przed testami zwiększa ryzyko awarii i niezadowolenia użytkowników.
Dlaczego pozostałe odpowiedzi są błędne?
- Warianty rozpoczynające od specyfikacji przed analizą odwracają logikę: trudno specyfikować coś, czego jeszcze nie zrozumiano i nie uzgodniono.
- Warianty zaczynające od tworzenia pomijają fundament procesu: implementacja bez wymagań prowadzi do "zgadywania" funkcjonalności.
- Warianty z wdrożeniem przed testami ignorują etap weryfikacji jakości i zgodności z wymaganiami.
Na egzaminie warto szukać odpowiedzi, w której testy poprzedzają wdrożenie, a analiza poprzedza specyfikację.
