Inżynieria Oprogramowania O analizie, zarządzaniu projektami i projektowaniu systemów informatycznych

Raport: Zarządzanie wymaganiami 2011

• Polish

Translate original post with Google Translate

Pod koniec 2010 roku Jama Software przeprowadziło badania na ponad 800 uczestnikach. Badania dotyczyły kwestii szeroko pojętych wymagań.

Wywiady były prowadzone głównie z analitykami biznesowymi (44,8 %), z kierownikami projektów (19,7 %) jak również z developerami (8,3 %), testerami (7,9 %), właścicielami produktów (6,9%), dyrektorami działów IT (6,4 %), konsultantami (5,3 %) oraz osobami do spraw usability (0,7 %).

 

 

Pod uwagę wzięto między innymi wielkości zespołów i prezentują się one następująco:

• 57,6 %: poniżej 25 osób w zespole,

• 26,8 %: od 25 do 50 osób w zespole,

• 10,3 %: od 50 do 100 w zespole,

• 3,8 %: od 100 do 250 osób w zespole,

• 1,5 %: ponad 250 osób w zespole.

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).

Złożoność wymagań:

• 25,4 % projektów zawiera poniżej 100 wymagań,
• 34,3 % projektów zawiera od 100 do 500 wymagań,
• 20% projektów zawiera od 500 do 1000 wymagań,
• 16,1 % projektów zawiera od 1000 do 5000 wymagań,
• 4,3 % projektów zawiera powyżej 5 000 wymagań.

Z powyższego zestawienia wynika iż ponad 70 % projektów zawiera 100 i więcej wymagań a 20 % zawiera 1000 i więcej wymagań.
Projekty z biegiem czasu stają się coraz bardziej skomplikowane co przekłada się bezpośrednio na zwiększenie liczby i złożoności wymagań. Rośnie zatem znaczenie odpowiedniego sposobu dokumentacji i zarządzania wymaganiami.

Średni czas poświęcany tygodniowo przez badanych na zarządzanie zmianą wymagań:

• 5% - więcej niż 5% czasu,
• 22,9 % - mniej niż 10 % czasu,
• 40,6 % - od 10 % do 25 % czasu,
• 24,7 % - od 25 % do 50 % czasu,
• 6,9 % badanych nie zajmuje się zarządzaniem zmianą wymagań.

Jak często projekt jest dostarczany zgodnie z czasem i w ramach założonego budżetu?:

• 17 % - w więcej niż 80 % przypadków,
• 26,4 % - od 60 % d0 80 %,
• 24,4 %- od 40 % do 60 %,
• 18 %- od 20 % do 30 %,
• 14,2 % - mniej niż 20 %.

Najczęstsze powody niepowodzeń w projektach (można było zaznaczyć kilka odpowiedzi):

• 75,3 % - nierealistyczny harmonogram projektu bądź oczekiwania,
• 72,8 % - pominięte bądź niedokładnie zdefiniowane wymagania,
• 69,9 % - zmiany zakresu projektu,
• 46,9 % - niezrozumienie podstawowych potrzeb klienta,
• 43,9 % - problemy z komunikacją i współpracą,
• 35,9 % - zarządzanie zmianą,
• 33,6 % - brak przeprowadzonych testów,
• 31,2 % - brak wsparcia ze strony osób zarządzających,
• 12,6 % - inne.

Najczęściej praktykowane podejście do procesu wytwarzania oprogramowania:

• 39,9 %- metodyki mieszane (dostosowane do własnych potrzeb),
• 25,9 %- podejście wodospadowe (waterfall),
• 19,2 % - agile,
• 8,4 % - podejście iteracyjne,
• 3,7 % - RUP,
• 4,3 % - inne,
• 3% % - używa własnego podejścia do wytwarzania oprogramowania.

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.

Zachęcam do zapoznania się z całym raportem.