Pojawia się jednak wiele kontrowersji w samej definicji: czym jest projekt o nazwie Analiza wymagań na oprogramowanie a czym projekt Analiza przedwdrożeniowa?

Kupujemy buciki

Krótki przykład z dziedziny, którą wielu z nas (może nawet większość) zna. Aby kupić buty małemu dziecku z wielu powodów nie ciągniemy malucha po centrach handlowych. Jak jednak kupić te buty i nie żałować? Rozwiązaniem jest przygotowanie patyczka o długości równej długości stopy dziecka od pięty do końca dużego palca (pisze dla pewności ). Z tym patyczkiem udajemy się do sklepu i szukamy bucików. Aby dokonać tego wyboru dysponujemy dwoma podstawowymi narzędziami: patyczek oraz ograniczenie (tu nasze doświadczenie), które mówi nam, że bucik będzie dobry jeśli patyk się zmieści, może być mały luz (np. maks. 5 mm) ale absolutnie nie dopuszczamy faktu, że mógłby się nie zmieścić. Doskonale wiemy dlaczego tak, a nie inaczej postępujemy: bucik zbyt duży będzie po protu nadmiarowym zakupem, którego i tak nie wykorzystamy zaś bucik zbyt mały po protu nie ma sensu z powodów oczywistych. Tak więc mamy skutecznie określone wymagania: patyczek jako model (uproszczenie) stopy dziecka i ograniczenia na jego użycie: zakaz zakupu zbyt małego i umiar w zakupie zbyt dużego.

Wyobraźmy sobie, że tak wyposażeni trafimy na sprzedawcę, który powie, że ma super buciki, kupują je dzieci znanych aktorów i polityków, ale musimy troszeczkę skrócić patyczek i pogodzić się z wielka cholewką w zamian. .

A teraz wymagania na system ERP.

Już widzę uśmiechy na twarzach czytelników . Tak, dobra metoda to mieć model i dodatkowe ograniczenia oraz nie dać sobie wcisnąć czegoś czego nie potrzebujemy. Niestety bez tych dwóch pierwszych (model i ograniczenia) nie mamy żadnej broni ani przed sobą samym (np. emocje) ani przed dostawcą - jesteśmy bardzo podatni na zakup czegoś zupełnie niepotrzebnego. Niektórzy opisują patyczek kolorem, poziomem wygładzenia, ornamentyką, skomplikowaną procedurą jego użycia i wieloma innymi cechami jednak tak na prawdę maja one znikomy wpływ na skuteczność dokonanego wyboru: liczą się w 99% długość patyczka i ograniczenie: patyczek musi wejść.

Czy tak można z oprogramowaniem?

Wystarczy mieć model naszej organizacji oraz ograniczenia nałożone na użycie tego modelu. Czy mając patyczek jest możliwa jakaś perswazja ze strony sprzedawcy butów? Nie! A bez patyczka? Kto dał sobie sprzedać nieco za małe buty w swoim życiu i czy je potem nosił (czasem tak, bo pieniądza na buty wydano i drugich nie na razie kupimy)? Czego nie lubią nieuczciwi sprzedawcy butów? Nie znoszą klientów z patyczkiem! Są nawet tacy, którzy wmawiają, że patyczek należy wyrzucić bo buciki są super i się rozchodzą, w skrajnym przypadku wytniemy otwór na palce (kastomizacja gotowego bucika).

Jak wykonać patyczek?

Tu pojawia się moja nieukrywana niechęć do metod polegających na prostym spisywaniu wymagań na oprogramowanie metodą spisywania explicite konkretnych funkcjonalności. Co będzie skuteczniejszym zamówieniem: bogaty opis tego do czego można użyć korby bez jej projektu czy raczej jej rysunek techniczny? Nawet jeśli będą to warsztaty, spotkania nawet wszystkich pracowników i wielkiej burzy mózgów, nic z tego nie będzie (w sensie skuteczności) mimo, że powstają kosztowne mega-dokumenty. Skoro każdy z nas jest w stanie pominąć coś istotnego przygotowując listę kilkunastu sprawunków idąc do sklepu to jak zagwarantować by braków takich nie było w tak wykonanej specyfikacji wymagań liczącej nawet setki pozycji?

Należy przygotować nie opis bucika a patyczek (nie opis planowanych zastosowań korby a jej rysunek)! Ma same zalety: ryzyko złego wyboru jest bliskie zeru, jest poręczny, można go nawet wysłać do sklepu pocztą i spodziewać się mimo to dobrych bucików.

Jak nie trudno się domyśleć mowa o modelowaniu, patyczek jest modelem stopy a rysunek korby jej modelem. Jak wykonać minimalny skuteczny model organizacji? Jest to trudne jednak nie niemożliwe. Paradoksalnie zaś opracowanie modelu jest prawie zawsze tańsze niż bogatej specyfikacji, że nie wspomnę o ryzyku użycia każdej z tych metod.

Co zawiera taki model?

Organizację definiują skutecznie:

Jak to pokazać a nie opisywać? Nie da się (nie sądzę) stworzyć jednego mega-modelu. Powinny powstać osobno:

Dobrze wykonany model nie zawiera informacji nadmiarowych, które zawsze podnoszą koszt wykonania modelu a nie raz stanowią zbędne ograniczenia. Dobry model powstaje z użyciem standardowych, opisanych semantycznie i syntaktycznie, notacji, tu BPMN w obszarze modelowania procesów oraz UML w pozostałych obszarach (używanie notacji pozwana zagwarantować weryfikowalność poprawności modeli). Użycie takiego modelu jako narzędzia wyboru systemu ERP jest bardzo skuteczne: wystarczy go rozesłać do dostawców i zapytać: po pierwsze czy ich system pasuje do niego, ile kosztuje ten produkt rok po roku.

Z takim modelem kupujący nie musi udowadniać, że jego oczekiwania mają sens (co nie raz zdają się podważać dostawcy) a dostawca musi zdeklarować i wykazać, że jego produkt pasuje do modelu. Lepiej: model jest doskonałym narzędziem testowania dostarczonego produktu. Użycie notacji niestandardowych, bez zdefiniowanych reguł, prowadzi do powstania nieweryfikowalnych modeli a to całkowicie dyskwalifikuje ich skuteczności i przydatność. Tak wykonane modele są one nieweryfikowalne i niejednoznaczne.

Tak więc analiza przedwdrożeniowa to jest jakaś praca, jej produktem mogą być różne treści. Dlatego właśnie warto pytać wykonawcę takiej analizy o to, co będzie jej produktem i do czego to coś posłuży.

A co gdy żaden mega produkt nie pasuje co jest bardzo prawdopodobne? O tym w kolejnej części.

Źródło: http://www.it-consulting.pl/blog
Autor: Jarosław Żeliński