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

 

 

Jarosław Żeliński

Jarosław Żeliński: autor, badacz i praktyk analizy systemowej organizacji: Od roku 1991 roku, nieprzerwanie, realizuje projekty z zakresu analiz i projektowania systemów, dla urzędów, firm i organizacji. Od 1998 roku prowadzi samodzielne studia i prace badawcze z obszaru analizy systemowej i modelowania (modele jako przedmiot badań: ORCID). Od 2005 roku, jako nieetatowy wykładowca akademicki, prowadzi 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. Prawa autorskie: Zgodnie z art. 25 ust. 1 pkt. 1) lit. b) ustawy o prawie autorskim i prawach pokrewnych zastrzegam, że dalsze rozpowszechnianie artykułów publikowanych w niniejszym serwisie jest zabronione bez indywidualnej zgody autora (patrz Polityki Strony).

Ten post ma 3 komentarzy

  1. jacek2v

    “Przyznajemy mimo to, ż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.”
    Nie do końca. Chyba nie chodziło o diagramy w przypadku prototypów, a wykonane “kawałki aplikacji”.

    1. Jarek Żeliński

      literalnie “diagramy najlepiej wyjaśniające (uzupełniające) wątpliwości związane z wymaganiami to modele procesów i prototypy” nie gdybał bym, prototyp w postaci diagramów UML da się zrobić i pzretestować … jak czytam cudze badania to nie polemizuje z wynikami…

    2. jacek2v

      “jak czytam cudze badania to nie polemizuje z wynikami?”
      Ja też. Nie doczytałem 🙂 :”Diagramy najlepiej wyjaśniające…”

Możliwość dodawania komentarzy nie jest dostępna.