A najczęściej używana notacja to…
Patrząc przez ramię
Ile razy zastanawialiście się, w jaki sposób modelować Wasze wymagania? Która notacja będzie najlepsza? Który sposób modelowania powinienem\am wybrać? Ile razy zaglądaliście przez ramię koleżanki lub kolegi, żeby zobaczyć jak oni to robią? Czy nie fajnie by było spojrzeć przez ramię prawie 200 innych analityków i zobaczyć, z czego oni korzystają w swojej pracy z wymaganiami?
Ale jak to zrobić?
Na szczęście panowie Colin J. Neill oraz Phillip A. Laplante z Penn State University postanowili dowiedzieć się czegoś więcej na temat najczęściej stosowanych praktyk inżynierii wymagań. Stworzyli internetową ankietę, która składała się z 22 pytań i zaprosili do jej wypełnienia prawie 2000 osób (głównie absolwentów PennState University). Odpowiedzi udzieliły 194 osoby (m.in. z takich firm jak SAP, Boeing, Dupont, Simens Medical Systems) i odpowiedzi te były podstawą artykułu "Requirements Engineering: The State of the Practice", który ukazał się w 2003 roku.
A zwycięzcą jest...
Jako, że cały dokument jest dostępny tutaj, to nie będę rozwodził się nad poszczególnymi wnioskami, tylko przedstawię najciekawsze (moim zdaniem) wyniki, i tak:
- 60% osób biorących udział w ankiecie stosowało w jakimś stopniu prototypowanie.
- 35% respondentów powiedziało, że wykorzystują podejście kaskadowe.
- W projektach, które trwały dłużej niż dwa lata najpopularniejsze było podejście iteracyjne.
- 33% osób stwierdziło, że nie korzystają z żadnej metodologii
- 51% respondentów powiedziało, że stosują nieformalne sposoby zapisu wymagań, 27% sposoby półformalne, a 7% stosują notacje formalne.
- W 59% przypadków stosuje się inspekcje, jako sposób na podniesienie jakości wymagań.
- 52% osób stwierdziło, że w ich firmach za mało uwagi poświęca się na inżynierię wymagań.
- Ponad 50% osób wykorzystuje przypadki użycia i/lub scenariusze do zapisu wymagań.
Tak wyglądają wyniki badań po drugiej stronie oceanu, ciekaw jestem jak to wyglądałoby u nas? Bylibyście zainteresowani wzięciem udziału w takim badaniu? Dajcie znać w komentarzach lub mailowo.
Echa konferencji Requirements Engineering 2009
W zeszłym roku miałem szansę brać udział w jednej z najbardziej prestiżowych konferencji poświęconych inżīnierii wymagań Requirements Engineering. To właśnie podczas tej konferencji zdecydowałem się założyć tego bloga, którego jednym z celów miało być omówienie najciekawszych zagadnień omawianych tamtego wydarzenia. Minęło pół roku od powstania bloga, a ja jeszcze nie napisałem ani słowa na temat konferencj - czas to zmienić.
Zacznę może od pierwszej prezentacji zaproszonej, którą poprowadził pan Dave West z Forester Research. Prezentacja dotykała problemów zwinności oraz wymagań, a pan West dzielił się wynikami różnorodnych ankiet i badań jakie prowadzone są przez Forester Research. Oto kilka fragmentów z notatek, które udało mi się zrobić:
- 1298 profesjonalistów z dziedziny IT odpowiadało na pytanie która z istniejących metodologii jest najbliższa temu, co robicie w waszej firmie? 31% podejście zwinne (zbliżone do RUP); 21# model kaskadowy; 12% podejście zwinne.
- Na pytanie, jakie są doświadczenia firm z wykorzystaniem podejść zwinnych odpowiedzi były następujące: 38% określiło, że mają wykoształcone dojrzałe podejście do zwinności; 30,8% stwierdziło, że są w połowie wdrażania podejść zwinnych; 25% dopiero zaczęło wprowadzać metodyki zwinne; a 5% dopiero zaczyna oceniać zalety takich podejść.
- Dlaczego ludzie wybierają zwinne metodyki? 63% - bo dają możliwość wprowadzenia zmian podczas tworzenia projektów; 60% - pozwalają zwiększyć jakość projektów; 60% - dają możliwość częstszych wydań; 55% - pozwalają na większość przewidywalność wydań; 45% - zwiększają motywację członków zespołów.
- Główne problemy związane z wymaganiami to: wymagania szybko stają się nieaktualne; wymagania to zwykle długie dokumenty, których nikt nie chce czytać; wymagania opisują zwykle rozwiązanie, a nie problem; zbieranie i analiza wymagań zabierają zbyt dużo czasu. Dodatkowe utrudnienia sprawiają: brak czasu po stronie klienta; wiele osób zainteresowanych tworzonym system, które często reprezentują sprzeczne interesy; słabe umiejętności komunikacyjne po stronie zespołu wytwórczego.
- Analityk powinien: mieć możliwość samodzielnego podejmowania decyzji; znać dziedzinę biznesową; dobrze współpracować z zespołem programistów.
- 81 profesjonalistów powiedziało, jakie mechanizmy z inżynierii wymagań wykorzystują najczęściej: 82% specyfikuje wymagania funkcjonalne; 62% wykorzystuje przypadki użycia; 57% tworzy prototypy; 46% specyfikuje wymagania pozafunkcjonalne; 37 % wykorzystuje warsztaty; 17% wykorzystuje wiki.
- Głównym narzędziem ankietowanych 230 analityków jest MS Office.
- Zalecenia: specyfikuj tylko to co będzie zaimplementowane; dobrze dobieraj poziom szczegółowości, staraj się estymować pracochłonność na etapie zbierania wymagań; pozwól wymaganiom ewoluować razem z powstającą implementacją; ciągle dostosowuj wykorzystywane techniki do zmieniającej się sytuacji.
- Pamiętajcie o wykorzystywaniu narzędzi i modeli graficznych.
W przygotowaniu dalsze relacje z Requirements Engineering 2009.