Na stro­nach zaprzy­jaź­nio­ne­go ser­wi­su Inżynieria opro­gra­mo­wa­nia poka­za­ły się naj­śwież­sze dane (za 2011 rok) na temat ​„kło­po­tów w pro­jek­tach pro­gra­mi­stycz­nych”. Wykonajmy mały eks­pe­ry­ment pole­ga­ją­cy na zesta­wie­niu dwóch pierw­szych pozy­cji wybra­nych poni­żej kate­go­rii. Najpierw ich peł­ne zestawienie:

Z rapor­tu wyni­ka, iż naj­więk­szą trud­no­ścią oka­zu­je się (moż­na było zazna­czyć kil­ka odpowiedzi):

• 72,9 % – jasne zro­zu­mie­nie tego cze­go tak napraw­dę klient potrzebuje,
• 58,9 % – udo­ku­men­to­wa­nie wymagań,
• 50,7 % – zbu­do­wa­nie aplikacji/systemu na pod­sta­wie usta­lo­nych wymagań,
• 46,9 % – usta­le­nie prio­ry­te­tów wymagań,
• 43,7 % – prze­ka­za­nie wyma­gań zespo­ło­wi (komu­ni­ka­cja wewnątrz zespołu).

Najczęstsze spo­so­by prze­cho­wy­wa­nia wyma­gań (moż­na było zazna­czyć kil­ka odpowiedzi):

• 83,2 % – doku­men­ty typu word i excel,
• 42 % – email,
• 31,4 % – narzę­dzia do zarzą­dza­nia wyma­ga­nia­mi (typu [[JIRA]]),
• 31,1 % – prze­ka­zy­wa­ne ust­nie pod­czas codzien­nych spotkań,
• 21,6 % – narzę­dzia case do zarzą­dza­nia wymaganiami,
• 21,6 % – zapi­ski na tabli­cy, żół­te karteczki,
• 11,3 % – por­ta­le typu wiki,
• 6,6 % – inne.

Diagramy naj­le­piej wyja­śnia­ją­ce (uzu­peł­nia­ją­ce) wąt­pli­wo­ści zwią­za­ne z wyma­ga­nia­mi (moż­na było zazna­czyć kil­ka odpowiedzi):

• 71,4 % – mode­le procesów,
• 50,1 % – prototypy,
• 47,5 % – mode­le inter­fej­su użytkownika,
• 46,5 % – dia­gra­my przy­pad­ków użycia,
• 31,1 % – dia­gram aktywności,
• 30,1 % – schematy/odręczne rysunki,
• 6,6% % – inne.

(za Raport: Zarządzanie wyma­ga­nia­mi 2011 | Inżynieria Oprogramowania).

A teraz zrób­my z tego wyzna­nie na spo­wie­dzi hipo­te­tycz­ne­go kie­row­ni­ka pro­jek­tu” (po dwa pierw­sze powo­dy z powyż­szych statystyk):

Ponad 80% pro­jek­tów pro­gra­mi­stycz­nych ma prze­kro­czo­ne ter­min i budżet. Największą trud­no­ścią w tych pro­jek­tach oka­za­ło się jasne zro­zu­mie­nie tego, cze­go tak napraw­dę klient potrze­bu­je, oraz udo­ku­men­to­wa­nie jego wyma­gań. Do prze­cho­wy­wa­nia wyma­gań uży­ty był głów­nie word i excel oraz ema­il. Przyznajemy jed­nak, że dia­gra­my naj­le­piej wyja­śnia­ją­ce (uzu­peł­nia­ją­ce) wąt­pli­wo­ści zwią­za­ne z wyma­ga­nia­mi to mode­le pro­ce­sów i pro­to­ty­py, jed­nak nie sto­su­je­my ich. ( 2011 State of Requirements Management Report.)

Jak widać brzmi zna­jo­mo z dwóch powo­dów: pro­ble­my zna­ne każ­de­mu i powo­dy nie­ste­ty tak­że. Ciśnie mi się na usta ​„a nie mówiłem”…

Czyli jed­nak wie­my że pro­ble­mem pro­jek­tów z zakre­su inży­nie­rii opro­gra­mo­wa­nia są zbyt pro­ste meto­dy i narzę­dzia zarzą­dza­nia wyma­ga­nia­mi (pakiet biu­ro­wy), któ­re w więk­szo­ści są sto­so­wa­ne. Wiemy, że mode­lo­wa­nie jest naj­sku­tecz­niej­sza meto­dą ana­li­zy i pro­jek­to­wa­nia a mimo to nie sto­su­je się tych metod szu­ka­jąc sta­le ​„dro­gi na skróty”.

Dlaczego dostaw­cy opro­gra­mo­wa­nia nie sto­su­ją metod powszech­nie jed­nak uzna­wa­nych za sku­tecz­ne? Czy to przy­pad­kiem nie jest tak, jak z Lotto? Powszechnie wia­do­mo, że praw­do­po­do­bień­stwo wygra­nia jest bli­skie zeru a mimo to wie­lu pró­bu­je, bo gdy­by się uda­ło to nie trze­ba się naro­bić by mieć … 

Dlatego, by się nie powta­rzać, jako kon­ty­nu­ację tego arty­ku­łu pro­po­nu­ję opis metod ana­li­zy wyma­gań i pro­jek­to­wa­nia. Nie jest tania ale jest skuteczna…

Na koniec tro­chę humo­ru 🙂 na temat zbie­ra­nia wyma­gań meto­dą ​„warsz­ta­tów”: