Czas poświęcony wymaganiom i jego wpływ na sukces projektu i czas rozwoju

Czy istnieją dowody sugerujące, że czas poświęcony na pisanie lub myślenie o wymaganiach będzie miało jakikolwiek wpływ na czas opracowywania? Badanie przeprowadzone przez Standish (1995) sugeruje, że niekompletne wymagania częściowo (13,1%) przyczyniły się do niepowodzenia projektów. Czy przeprowadzono jakieś badania, które pokazują, że czas poświęcony na analizę wymagań będzie miał jakikolwiek wpływ na czas opracowywania projektu lub na sukces projektu.

Patrz Kod ukończony, Steve McConnell, Tabela 3-1. Porównuje średni koszt naprawy defektów w oparciu o czas ich wprowadzenia i wykrycia. Wykrywanie w czasie budowy kosztuje 5-10 razy więcej niż wykrywanie w czasie wymagań i 10-100 razy więcej po wydaniu.

Tabela oparta jest na następujących źródłach:

1. „Kontrola projektu i kodu w celu zmniejszenia liczby błędów w programowaniu” (Fagan 1976)

2. Usuwanie defektów oprogramowania (Dunn 1984)

3. „Software Process Improvement at Hughes Aircraft” (Humphrey, Snyder i WIllis 1991)

i kilka innych

Tak, istnieje wiele badań na ten temat. Oczywiście pytanie jest zbyt ogólne, aby odpowiedzieć na wszelkiego rodzaju projekty rozwoju oprogramowania, ale istnieją dowody z kilku kontekstów, które potwierdzają pogląd, że prawidłowe przeprowadzenie analizy wymagań będzie miało pozytywny wpływ na etap wdrożenia. Dowody te zostały częściowo zebrane w „prawa”, a oto trzy przykłady:

Prawo szkła: braki wymagań są głównym źródłem niepowodzeń projektu.

To prawo jest poparte dowodami ze studiów przypadków z dużych projektów rozwoju oprogramowania. Glass stwierdził, że w nieudanych przypadkach było zbyt wiele wymagań, były one niestabilne z powodu późnych zmian oraz były niejednoznaczne i niekompletne.

Sugeruje to, że istnieje związek między jakością wymagań a rezultatem projektu.

Pierwsze prawo Boehm'a : Błędy występują najczęściej podczas wymagań i działań projektowych, a im droższe, tym później zostaną usunięte.

Jest to również poparte dowodami ze studium przypadku i przyczynia się do odpowiedzi na pytanie w następujący sposób: prawidłowe wykonanie wymagań zmniejszy liczbę błędów w systemie, a poprawienie błędów przed rozpoczęciem wdrażania będzie tańsze niż ich polowanie w dół, gdy implementacja już się rozpoczęła (lub gorzej, gdy system już został wysłany).

Drugie prawo Boehm'a: Prototypowanie (znacznie) zmniejsza wymagania i błędy projektowe, szczególnie w przypadku interfejsów użytkownika.

Jest to poparte kontrolowanymi eksperymentami w kontekście studenckim. Jedną z możliwych interpretacji jest to, że wymagania i fazy projektowania nie muszą być całkowicie oparte na dokumentacji i teoretyczne. Zamiast tego wykonywanie prototypów w ramach fazy wymagań i projektowania - co sprowadza się do spędzenia czasu i zastanowienia się nad wymaganiami - wpłynie na sukces projektu i czas wdrożenia.

Istnieje również wiele innych dowodów wskazujących na ten sam kierunek: poświęcenie czasu na przygotowanie do wdrożenia się opłaca w postaci mniejszego ryzyka i mniejszej szansy na przekroczenie harmonogramu z powodu niespodzianek. Chociaż pytanie nie dotyczyło testowania, prawidłowe przygotowanie również pozytywnie wpływa na testowanie.

Odniesienia do tych przepisów są następujące:

Prawo Glassa: Glass, RL: Software Runaways. Wnioski wyciągnięte z ogromnych awarii projektu oprogramowania. Upper Saddle River, NJ: Prentice Hall 1998

Pierwsze prawo Boehm: Boehm, BW, McClean, RK, Urfrig, DB: Pewne doświadczenie z automatycznymi pomocami w projektowaniu niezawodnego oprogramowania na dużą skalę. IEEE Trans on Software Engineering 1, 1 (1975), 125–133

Drugie prawo Boehm'a: Boehm, BW, Gray, TE, Seewaldt, T .: Prototypowanie a określenie: eksperyment z wieloma projektami. IEEE Trans on Software Engineering 10, 3 (1984), 290–302

Interesujące mogą być również następujące odniesienia: Endres, A. i Rombach, D. Podręcznik oprogramowania i inżynierii systemów. Obserwacje empiryczne, prawa i teorie. Seria Fraunhofer IESE na temat inżynierii oprogramowania. Addison Wesley, 2003.