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.
Kompletny SRS na wyciągnięcie ręki…i to za darmo!
W zeszłym roku zostaliśmy zaproszeni (jako zespół Inżynierii Oprogramowania na Politechnice Poznańskiej) do współpracy przez Wydział Informatyki Urzędu Miasta Poznania nad dokumentem zawierającym wskazówki dotyczące zbierania wymagań dla projektów informatycznych. Jednostki samorządowe objęte są przepisami dotyczącymi zamówień publicznych, dlatego też najczęściej muszą one same muszą zadbać o zebranie wymagań dla systemów informatycznych, wymagania te później są podstawą ogłoszonego przetargu na realizację systemu.
Efektem naszej współpracy są 3 dokumenty:
- wskazówki dotyczące dokumentowania wymagań dla systemów informatycznych
- przykładowa pełna specyfikacja wymagań dla systemu archiwizacji elektronicznej
- wzorzec dla dokumentu specyfikacji wymagań (na bazie standardu IEEE 830:1998)
Dzięki uprzejmości Wydziału Informatyki Urzędu Miasta Poznania wszystkie 3 dokumenty są publicznie dostępne. Zapraszam tutaj (znajdziecie tam archiwum zip ze wspomnianymi wcześniej dokumentami oraz dodatkowy dokument zawierający szczegóły dotyczące zasad rozpowszechniania naszego opracowania).
Mam nadzieję, że zarówno zebrane przez nas wskazówki jak i przykład pozwolą Wam jeszcze efektywniej zbierać wymagania w Waszych projektach. Jeśli będziecie korzystali z tych dokumentów to dajcie znać co o nich sądzicie i czy się Wam przydały. Jesteśmy bardzo ciekawi Waszych opinii!
Oczywiście jeśli jesteście zainteresowani współpracą nad podobnym projektem, lub macie jakikolwiek problem z wymaganiami w Waszych projektach to również dajcie koniecznie znać.
Benchmark dla przypadków użycia
Które przypadki użycia wybrać do badań?
W naszym zespole zajmującym się Inżynierią Oprogramowania na Politechnice Poznańskiej skupiamy naszą uwagę w dużej mierze na analizie przypadków użycia. W ramach naszych prac tworzymy metody oraz narzędzia pozwalające analizować wymagania z różnych punktów widzenia. W pewnym momencie pojawił się problem: na jakich danych powinniśmy testować nasze metody i narzędzia? Wiadomo, że jeśli będziemy testować na danych spreparowanych przez nas to wyniki będą niemiarodajne. Moglibyśmy wziąć też pod uwagę specyfikacje stworzone w rzeczywistych projektach.Powstaje wówczas jednak pytanie: które specyfikacje powinniśmy wybrać? Doszliśmy więc do wniosku, dlaczego by nie przeanalizować dostępnych nam przypadków użycia i nie stworzyć pewnego rodzaju specyfikacji referencyjnej, która jak najwierniej odzwierciedlałaby rzeczywisty świat wymagań zapisanych w postaci przypadków użycia?
Benchmark 1.0
Aby stworzyć taki swoisty benchmark dla narzędzi badających przypadki użycia przeanalizowaliśmy 432 przypadki użycia z 11 dostępnych nam specyfikacji wymagań. Cześć naszej analizy możecie znaleźć tutaj (resztą wyników mogę udostępnić zainteresowanym osobom, w takiej sytuacji proszę o kontakt). Samą specyfikację, która powstała w wyniku tych prac znajdziecie tutaj. Jak powstał nasz benchmark? Każdy z przypadków użycia był przez nas badany m.in. pod kątem liczby kroków, liczby warunków początkowych, liczby kroków wykonywanych przez budowany system, itp. Następnie po takiej analizie zebraliśmy wyniki ze wszystkich projektów, co pozwoliło nam stworzyć obraz "przeciętnej" specyfikacji wymagań. Na tej podstawie stworzyliśmy przykładową specyfikację zachowującą właściwości specyfikacji "przeciętnej".
Benchmark 2.0
Po kilku miesiącach postanowiliśmy rozszerzyć naszą analizę o 5 kolejnych projektów (524 przypadki użycia łącznie), dodaliśmy również drugi wymiar do naszych badań. Za pierwszym razem wzięliśmy pod uwagę jedynie charakterstki ilościowe (liczba kroków, liczba rozszerzeń, etc.), tym razem dodatkowo analizowaliśmy różnież charakterystyki jakościowe (czy w każdym kroku jest wskazany aktor? czy używana jest czynna forma czasownika? etc.) i w ten sposób powstały dwie wersje referencyjnej specyfikacji: jedna zawierająca wyłącznie wyniki analizy ilościowej oraz druga zawierająca zarówno wyniki analizy ilościowej jak i jakościowej. Częściowe wyniki analiz możecie znaleźć tutaj, po resztę trzeba niestety poczekać dopóki nasz artykuł nie zostanie opublikowany. Benchmark w wersji ilościowej znajdziecie tutaj, a ten z dodatkową analizą jakościową tutaj.
Chcesz nam pomóc?
A może miałbyś ochotę podzielić się z nami swoimi przypadkami użycia? Jakość naszej pracy badawczej w dużej mierze zależy od tego na jakich danych operujemy. Czym więcej mamy danych rzeczywistych tym bardziej dopasowane metody i narzędzia możemy tworzyć. Zatem jeśli masz możliwość podzielenia się z nami wymaganiami ze swoich projektów to śmiało napisz do mnie maila! Oczywiście gwarantujemy pełną poufność danych, a jeśli trzeba to możemy również podpisać odpowiednie umowy.
7 mitów na temat metod formalnych
Jakiś czas temu pisałem o tym, jakie metody powinniśmy stosować do różnych projektów, jedną z takich metod są podejścia formalne do zapisywania wymagań. Z badań wynika, że metody takie są mało popularne, jednym z powodów takiego stanu rzeczy są mity i przekonania, które wokół nich powstały. Artykuł "Seven Myths of Formal Methods" rozprawia się z siedmioma takimi mitami. Oto one:
Mit #1
Metody formalne zagwarantują, że oprogramowanie będzie idealne.
Niestety prawda jest taka, że nie ma żadnych metod, które mogą nam zagwarantować pewny sukces. Zwolennicy metod formalnych często przedstawiają je jako sposób na wszystkie bolączki projektów i zapewniają stuprocentowe powodzenie, a jako jedyny powód porażek przedstawiają niedoskonałość ludzi, którzy takie metody wykorzystują. Praktyka jednak pokazuje, że żadne mniej lub bardziej wyszukane nie są w stanie zagwarantować nam sukcesu.
Mit #2
Metody formalne sprawdzają się, bo umożliwiają udowodnienie, że oprogramowanie jest poprawne.
Weryfikacja poprawności jest tylko jednym z elementów metod formalnych i to tą najbardziej kosztowną, dlatego też bardzo często, jeśli system nie jest krytyczny, to ten element pomija się podczas pracy nad projektem.
Mit #3
Tylko bardzo krytyczne systemy mogą skorzystać z zalet notacji formalnych.
Oczywiście w przypadku systemów krytycznych zastosowanie notacji formalnych jest często koniecznością, nie oznacza to jednak, że pozostałe rodzaje systemów nie mogą skorzystać z zalet jakie niosą ze sobą podejścia formalne.
Mit #4
Metody formalne wymagają znajomości skomplikowanej matematyki.
Jak wiadomo większość metod formalnych wywodzi się z matematyki, a ta często postrzegana jest jako coś wielce skomplikowanego i trudnego do opanowania. Okazuje się jednak, że w praktyce metody formalne są stosunkowo proste i łatwe do przyswojenia.
Mit#5
Metody formalne zwiększają koszty wytwarzania oprogramowania.
Nawet jeśli tworzenie specyfikacji w notacji formalnej, lub też późniejsza implementacja kosztują więcej (a niekoniecznie musi tak być!), to na pewno faza utrzymania oprogramowanie jest później dużo niższa.
Mit #6
Formalne notacje są niezrozumiałe dla klientów.
Pomimo swojej matematycznej natury notacje formalne niosą ze sobą różne inne sposoby prezentowania informacji, które mogą być bardziej zrozumiałe dla klientów.
Mit #7
Nikt nie wykorzystuje metod formalnych w rzeczywistych projektach.
Często metody formalne wiąże się ze środowiskiem naukowym, jakoby tylko one mają odpowiednie zdolności do operowania formalizmami. Badania pokazują jednak, że metody formalne mogą być (i są!) z powodzeniem wykorzystywane w rzeczywistych projektach przemysłowych,
Po szczegóły rozprawienia się z powyższymi mitami zapraszam do lektury artykułu. Zamiast mitów autor artykułu proponuje następujące fakty:
- Notacje formalne pozwalają znaleźć błędy we wstępnym etapie tworzenia oprogramowania oraz pozwalają wyeliminować pewne klasy błędów.
- Formalizmy zmuszają do intensywnego przemyślenia koncepcji tworzonego systemu.
- Praktycznie dotworzenia każdego rodzaju oprogramowania można wykorzystać metody formalne.
- Notacje formalne bazują na specyfikacji matematycznej, która jest dużo prostsza do zrozumienia niż kod programu.
- Metody formalne mogą zmniejszyć koszty wytwarzania oprogramowania.
- Klienci mogą lepiej zrozumieć budowany system tworzony z wykorzystaniem notacji formalnych.
- Wiele rzeczywistych projektów przemysłowych wykosztuje formalizmy.
Konferencja „Oprogramowanie zgodne z prawem” 2009
Właśnie ustaliłem szczegóły mojego wystąpienia na międzynarodowej konferencji "Oprogramowanie zgodne z prawem, inżynieria wymagań i prawo", która odbędzie się 01.12.2009 w Warszawie. Konferencja ma na celu zbliżenie do siebie informatyków oraz prawników - obie te grupy są niezbędne przy tworzeniu systemów informatycznych. Moja prezentacja będzie dotyczyła głównie wymagań (oraz problemów z nimi związanymi) dla projektów, na które ogłaszane są przetargi - jest to główna droga budowy systemów w organizacjach administracji publicznej. Prezentację będę opierał na doświadczeniach zdobytych przy analizie wymagań jednego z projektów prowadzonych przez jeden z urzędów miasta w Wielkopolsce. Nad tytułem oraz zakresem prezentacji nadal się zastanawiam, ale myślę, że niedługo będę mógł się nimi z Wami podzielić.
Jak wyglądają nasze wymagania?
Znalezisko sprzed 10-ciu lat
W zeszłym tygodniu natknąłem się na dość ciekawy artykuł pt. "Investigation of requirements documents written in natural language". Artykuł nie jest najmłodszy, bo pochodzi z 1998, ale wydaje mi się, że obserwacje w nim zawarte są nadal aktualne. Autor tegoż artykułu postawił sobie za cel przebadanie dostępnych mu specyfikacji wymagań i wyciągnięcie wniosków na temat tego jak wyglądają takie specyfikacje w praktyce.
Wnioski
Jakie najważniejsze wnioski wysunął autor z przeprowadzonej analizy? Otóź:
- Specyfikacje wymagań nie są aktualizowane na bieżąco, mimo zmieniających się wymagań
- W specyfikacji wymagań najczęściej brakowało
- definicji terminów, które pozwoliłyby poprawić jednoznaczność
- wymagań pozafunkcjonalnych
- opisu interakcji budowanego systemu z użytkownikami
- opisu istniejącego już systemu, jeśli mowa była o poprawianiu lub wymianie systemu
- sekcji "otwartych kwestii", które wymagały by wyjaśnienia
- Jako, że specyfikacje były zapisane głównie w języku naturalnym to zauważono również:
- brak precyzji
- niejednoznaczności
- powiązane informacje były "porozrzucane" po cały dokumencie
- brak jasnej separacji między wymaganiami
- W projektach nie były używane metody formalne ani pół-formalne ponieważ:
- wydawało się, że spowoduje to zbyt duże koszty
- osoby podejmujące decyzje nie były przekonane o skuteczności tych metod
- wykorzystywany proces nie był przystosowany do stosowania takich metod
Ciągle aktualne?
Niby wyniki są sprzed 10-ciu lat, ale moje doświadczenie pokazuje, że niewiele się zmieniło przez ten okres - ciągle mamy problem z precyzją i jednoznacznością, definiowaniem wymagań pozafunkcjonalnych, nadążaniem nad zmianami, itp. Myślicie, że kolejne 10 lat przyniesie jakąś poprawę?
IAG Business Analysis Benchmark 2009
Czym jest IAG Business Analysis Benchmark?
"Ścieżka do sukcesu" tak brzmi podtytuł corocznego raportu firmy IAG "Business Analysis Benchmark" na rok 2009. Firma IAG przebadała prawie 500 firm programistycznych i na podstawie swoich obserwacji przyporządkowała każdą z firm do jednego ze stworzonych przez siebie poziomów dojrzałości wymagań (na wzór CMMI).
Poziomy dojrzałości wymagań
Poziomów dojrzałości jest sześć:
- Poziom 0 - niepełen (ang. incomplete)
- Poziom 1 - wykonywany (ang. performed)
- Poziom 2 - zdefiniowany (ang. defined)
- Poziom 3 - zaimplementowany (ang. implemented)
- Poziom 4 - zinstytucjonalizowany (ang. institutionalized)
- Poziom 5 - optymalizowany (ang. optimizing)
Czynniki brane pod uwagę przy tworzeniu raportu
Przydział do poziomów następuje po analizie sześciu czynników:
- Proces - w jaki sposób jest zdefiniowany i wykorzystywany? w jaki sposób wymagania są zarządzane?
- Praktyka i techniki - czy są zdefiniowane czynności jakie powinien wykonywać analityk? jaka jest dokładność i wydajność tych czynności?
- Technologie - jakie i w jaki sposób są wykorzystywane narzędzia w kontekście wymagań?
- Kompetencje pracowników - jaki jest poziom wiedzy pracowników? jakie mają umiejętności i możliwości?
- Produkty - w jaki sposób tworzone są i wykorzystywane produkty powstałe w wyniku zbierania wymagań?
- Organizacja - w jaki sposób działa organizacja jako całość? w jaki sposób wykorzystywane są zasoby? w jaki sposób odbywa się praca z klientami?
Zależności między czynnikami a poziomami dojrzałości
Poniższa tabela przedstawia relacje między poszczególnymi czynnikami, a poziomami dojrzałości wymagań:
Wnioski z analizy
Jakie wnioski wypływają z przeprowadzonej analizy?
1) 74,1% przebadanych firm znajduje się na 1 lub 2 poziomie dojrzałości wymagań.
2) Firmy o niskim poziomie dojrzałości wymagań są znacząco mniej wydajne od firm z wyższych poziomów, mowa tutaj o wydajności w kontekście czasu dostawy, koszcie całkowitym, stopniu zgodności oprogramowania z wymaganiami, liczby projektów zakończonych sukcesem.
3) Firmy, którym udało się przejść z poziomu 1 do poziomu 4 osiągnęły następujące efekty:
- zwiększenie wydajności w kontekście czasu dostawy o 161%
- zmniejszenie czasu przekroczenia czasu dostawy o 87%
- zwiększenie wydajności w kontekście budżetu o 95%
- zmniejszenie kwoty przekroczenia budżetu o 75%
- zwiększenie liczby projektów, które w 100% zgodne były z wymaganiami o 75%
- zmniejszenie przeciętnie brakującej funkcjonalności o 78%
4) Firmy z poziomu 1 i 2 tracą odpowiednio 39% i 34% swoich budżetów z powodu wymagań o słabej jakości.
5) Wybór metodologii zarządzania projektem ma mniejszy wpływ na sukces projektu niż jakość zebranych wymagań.
6) Wydajność analityków zależy od poziomu firmy, w której pracują. Analityce z bardzo dobrymi umiejętnościami mają słabszą wydajność w firmach o niskim poziomie dojrzałości wymagań, natomiast słabsi analitycy działają (wydawałoby się) ponad swoje możliwości w firmach o wyższym poziomie dojrzałości wymagań.
Jak podobają się Wam te wnioski? Mnie one trochę przerażają, szczególnie biorąc pod uwagę, że dotyczą one głównie rynku amerykańskiego, gdzie wiedza i dbałość o wymagania jest znacznie wyższa niż u nas. Jak myślicie? Na jakim poziomie są Wasze firmy?
Raport dostępny jest tutaj, wystarczy podać adres email i po chwili raport w postaci pliku pdf powinien znaleźć się w naszej skrzynce pocztowej.