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”:

Jarosław Żeliński

BIO: Od roku 1991 roku, nieprzerwanie, realizuję projekty z zakresu analiz i projektowania systemów, dla urzędów, firm i organizacji. Od 1998 roku prowadzę także samodzielne studia i prace badawcze z obszaru analizy systemowej i modelowania (modele jako przedmiot badań: ORCID). Od 2005 roku, jako nieetatowy wykładowca akademicki, prowadzę wykłady i laboratoria (ontologie i modelowanie systemów informacyjnych, aktualnie w Wyższej Szkole Informatyki Stosowanej i Zarządzania pod auspicjami Polskiej Akademii Nauk w Warszawie. Oświadczenia: moje badania i publikacje nie mają finansowania z zewnątrz, jako ich autor deklaruję brak konfliktu interesów. Masz pytania to treści artykułu? Kliknij tu i umów się na krótkie konsultacje.

Ten post ma 3 komentarzy

  1. jacek2v

    Przyznajemy mimo to, ż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.”
    Nie do koń­ca. Chyba nie cho­dzi­ło o dia­gra­my w przy­pad­ku pro­to­ty­pów, a wyko­na­ne kawał­ki aplikacji”.

    1. Jarek Żeliński

      lite­ral­nie 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” nie gdy­bał bym, pro­to­typ w posta­ci dia­gra­mów UML da się zro­bić i pzre­te­sto­wać … jak czy­tam cudze bada­nia to nie pole­mi­zu­je z wynikami…

    2. jacek2v

      jak czy­tam cudze bada­nia to nie pole­mi­zu­je z wynikami?”
      Ja też. Nie doczy­ta­łem 🙂 :„Diagramy naj­le­piej wyjaśniające…”

Dodaj komentarz

Witryna wykorzystuje Akismet, aby ograniczyć spam. Dowiedz się więcej jak przetwarzane są dane komentarzy.