Dwa lata temu pisałem o tym, czym jest, po co się prowadzi i jak, studium wykonywalności projektu:

W literaturze można spotkać różne ?definicje? studium wykonalności, jednak ta którą opisałem, zdaje się być najbliższa definicji, którą przytoczyłem na początku: bazującej na znaczeniu słownikowym. Praktyka pokazuje, że intencje sponsorów tych analiz są z nią zbieżne: celem jest podjęcie decyzji o najmniejszym ryzyku w świetle posiadanej na dany temat wiedzy. Definicje bazujące na technicznej i finansowej wykonalności danego projektu, są spotykane dość często i w literaturze i na stronach wielu instytucji. Metoda prowadzenia takich analiz, bazująca na modelowaniu czyli na analizie systemowej,  wydaje się być jednak najwłaściwszą. (Źródło: Studium wykonalności ? czym naprawdę jest | | Jarosław Żeliński IT-Consulting)

W artykule tym zwracałem uwagę na wartość modelowania (a nie rysowania…), wartością tą jest testowanie koncepcji. Sama koncepcja nie jest żadnym wymaganiem, co ilustruje świetny artykuł na stronach Modernanalyst.com:

Requirements must be based on facts and real-life scenarios. When the concept is untested or not fully tested, then the requirements are hypothetical. Moving to design and build with hypothetical requirements, the design and/or build phase becomes the testing ground for the concept. This may lead to clashes as each party has different expectations of the outcome of the ?hypotheses?.

Źródło: Blueprints Are Not Requirements!

Powyższy diagram pokazuje główne przesłanie opisanej metody, która jest zgodna w 100% z pełną analizą systemową: pierwszy etap to opracowanie koncepcji czyli hipotezy mówiącej “taki system jest nam potrzebny” do rozwiązania problemu biznesowego (potrzeby biznesowe).  Kolejny etap to stwierdzenie poprawności pomysłu, to nic innego jak studium wykonalności, testowanie pomysłu. Tu ważna rzecz: test musi być prowadzony w oparciu o fakty i tylko fakty, innymi słowy model nie może kolidować z rzeczywistością, musi także pokazać, że zaprojektowany nowy lub zmieniony mechanizm działania organizacji da oczekiwane efekty. Dopiero gdy hipoteza mówiąca, że “taki system realizuje nasze potrzeby” zostanie potwierdzona testami na modelu, ma sens opracowywanie wymagań na to rozwiązanie. W toku opracowywania wymagań, także je testujemy. Tu znowu sprawdza się skuteczność podejścia “projekt (model) jako wymaganie”.

Trzy lata temu opisałem cały taki proces, na dość może trywialnym przykładzie (szachy), ale za to (mam nadzieję) przejrzystym. Na zakończenie artykułu zwróciłem uwagę, że:

Analiza i projektowanie obiektowe (ang. OOAD) to niejako ?implementacja? klasycznej analizy systemowej. Nie ma ona nic wspólnego ze strukturalnymi metodami analizy i projektowania oprogramowania (czego wielu zdaje się nadal nie dostrzegać).  Wygląda na to, że jest znacznie trudniejsza ale praktyka pokazuje, że daje znacznie lepsze rezultaty. Języki obiektowe to nie jakaś tam nowa nazwa klasy na podprogramy, a zupełnie nowy paradygmat programowania: musi być poprzedzany analizą i projektem. Jego zaletą jest to, że pozwala na odwzorowywanie, niemalże jak w grze, analizowanego i rozwiązywanego problemu, pozwala na przetestowanie pomysłu na program zanim powstanie choć jedna linia programu. Problemem i wyzwaniem na etapie analizy jest zrozumienie problemu,  co mam nadzieję pokazałem. Niestety wiele analiz dokumentowanych z użyciem notacji UML nie ma wiele wspólnego  z OOAD, stanowią echa strukturalnych metod analizy i projektowania, stosowania baz relacyjnych już na etapie analizy (obiektowe narzędzia nie czynią projektów obiektowymi). Niestety błędy te popełniają nawet wykładowcy wielu uczelni i kursów. (Źródło: Plansza do gry w szachy czyli analiza i projektowanie | | Jarosław Żeliński IT-Consulting).

Autor artykułu przywołuje niezmienną od lat statystykę:

According to an often-quoted study from the Gartner Group, 75% of IT projects fail. The Standish Group conducts an annual survey of IT projects. Their latest report shows a decrease in project success rates.

1. 32% of all projects succeeded: delivered on time, on budget, with required features.
2. 44% were challenged: late, over budget, and/or with less than the required features.
3. 24% failed: cancelled prior to completion or delivered and never used.

When we look back, we not only see failures but can clearly see the boom the software industry has been given with its success. But the worrying aspect is that there are failures that are recurring every year, maybe in a different organization but mostly with common causes. (Źródło: Blueprints Are Not Requirements!)

…i zwraca uwagę, że ich przyczyny są od lat stale takie same…

“Requirements must be based on facts and real-life scenarios.” (wymagania muszą być oparte na faktach i realnych scenariuszach).  Więc ile warte są wizje w projektach agile albo wydumane w toku warsztatowych burz mózgów litanie życzeń i pomysłów? Nie tylko moim zdaniem: nie są wiele warte i nie powinny być wymaganiami.