Na stronach zaprzyjaźnionego serwisu Inżynieria oprogramowania pokazały się najświeższe dane (za 2011 rok) na temat “kłopotów w projektach programistycznych”. Wykonajmy mały eksperyment polegający na zestawieniu dwóch pierwszych pozycji wybranych poniżej kategorii. Najpierw ich pełne zestawienie:

Z raportu wynika, iż największą trudnością okazuje się (można było zaznaczyć kilka odpowiedzi):

• 72,9 % – jasne zrozumienie tego czego tak naprawdę klient potrzebuje,
• 58,9 % – udokumentowanie wymagań,
• 50,7 % – zbudowanie aplikacji/systemu na podstawie ustalonych wymagań,
• 46,9 % – ustalenie priorytetów wymagań,
• 43,7 % – przekazanie wymagań zespołowi (komunikacja wewnątrz zespołu).

Najczęstsze sposoby przechowywania wymagań (można było zaznaczyć kilka odpowiedzi):

• 83,2 % – dokumenty typu word i excel,
• 42 % – email,
• 31,4 % – narzędzia do zarządzania wymaganiami (typu [[JIRA]]),
• 31,1 % – przekazywane ustnie podczas codziennych spotkań,
• 21,6 % – narzędzia case do zarządzania wymaganiami,
• 21,6 % – zapiski na tablicy, żółte karteczki,
• 11,3 % – portale typu wiki,
• 6,6 % – inne.

Diagramy najlepiej wyjaśniające (uzupełniające) wątpliwości związane z wymaganiami (można było zaznaczyć kilka odpowiedzi):

• 71,4 % – modele procesów,
• 50,1 % – prototypy,
• 47,5 % – modele interfejsu użytkownika,
• 46,5 % – diagramy przypadków użycia,
• 31,1 % – diagram aktywności,
• 30,1 % – schematy/odręczne rysunki,
• 6,6% % – inne.

(za Raport: Zarządzanie wymaganiami 2011 | Inżynieria Oprogramowania).

A teraz zróbmy z tego wyznanie na spowiedzi hipotetycznego  kierownika projektu” (po dwa pierwsze powody z powyższych statystyk):

Ponad 80% projektów programistycznych ma przekroczone termin i budżet. Największą trudnością w tych projektach okazało się jasne zrozumienie tego, czego tak naprawdę klient potrzebuje, oraz udokumentowanie jego wymagań. Do przechowywania wymagań użyty był głównie word i excel oraz email. Przyznajemy jednak, że diagramy najlepiej wyjaśniające (uzupełniające) wątpliwości związane z wymaganiami to modele procesów i prototypy, jednak nie stosujemy ich. ( 2011 State of Requirements Management Report.)

Jak widać brzmi znajomo z dwóch powodów: problemy znane każdemu i powody niestety także. Ciśnie mi się na usta “a nie mówiłem”…

Czyli jednak wiemy że problemem projektów z zakresu inżynierii oprogramowania są zbyt proste metody i narzędzia zarządzania wymaganiami (pakiet biurowy), które w większości są stosowane. Wiemy, że modelowanie jest najskuteczniejsza metodą analizy i projektowania a mimo to nie stosuje się tych metod szukając stale “drogi na skróty”.

Dlaczego dostawcy oprogramowania nie stosują metod powszechnie jednak uznawanych za skuteczne? Czy to przypadkiem nie jest tak, jak z Lotto? Powszechnie wiadomo, że prawdopodobieństwo wygrania jest bliskie zeru a mimo to wielu próbuje, bo gdyby się udało to nie trzeba się narobić by mieć … 

Dlatego, by się nie powtarzać,  jako kontynuację tego artykułu proponuję opis metod analizy wymagań i projektowania. Nie jest tania ale jest skuteczna…

Na koniec trochę humoru 🙂 na temat zbierania wymagań metodą “warsztatów”: