Ka┐dy kto mia│ okazjΩ ogl▒daµ dokumentacjΩ analizy wymaga± du┐ego, formalnie prowadzonego projektu musia│ choµ raz zadaµ sobie pytanie dotycz▒ce praktycznej u┐yteczno╢ci tych ''metr≤w bie┐▒cych'' papieru wype│nionego modelami, opisami, definicjami i tabelkami, W ostatnim numerze ''Informatyki'', po╢wiΩconym w ca│o╢ci realizowanemu przez MPiPS projektowi ALSO, podano ca│kowit▒ objΩto╢µ dokumentacji systemu - 20 000 stron!!! Przyjmuj▒c szybko╢µ czytania 40 stron na godzinΩ, przeczytanie jej w ca│o╢ci jest zadaniemo pracoch│onno╢ci 500 osobogodzin, czyli 62 dni. Dokumentacja wielu ╢redniej wielko╢ci projekt≤w to grube dziesi▒tki lub setki stron. Czy rzeczywi╢cie nie da siΩ realizowaµ z│o┐onych przedsiΩwziΩµ informatycznych bez produkowania mniej lub bardziej monstrualnych specyfikacji?

ObjΩto╢µ specyfikacji z│o┐onych system≤w daje siΩ uzasadniµ. Aplikacja o z│o┐ono╢ci 1500 punkt≤w funkcyjnych, odpowiadaj▒ca ╢redniej wielko╢ci systemowi budowanemu metod▒ szybkiej ╢cie┐ki projektowej (Rapid Application Development), to nieca│e 200 tys. linii kodu jΩzyka C. Kod aplikacji zajmuje wiΩc ponad 7 tysiΩcy standardowych stron A4 wydruku. Typowa specyfikacja takiego systemu to 100-200 stron zawieraj▒cych opis kilkudziesiΩciu wymaga±, od 20 do 30 przypadk≤w u┐ycia, model opisuj▒cy kilkadziesi▒t klas i s│ownik danych. Proste zestawienie tych liczb pokazuje, ┐e budowanie specyfikacji stanowi zupe│nie racjonalny odruch stopniowego uszczeg≤│owiania tworzonego rozwi▒zania. Z drugiej strony niejeden czytelnik ''Strategii Informatyzacji'' potrafi zapewne przytoczyµ anegdoty o specyfikacjach - p≤│kownikach, kt≤re powsta│y tylko po to, by pokrywaµ siΩ kurzem, czy historie o frustracji spowodowanej konieczno╢ci▒ weryfikacji modelu danych przez przedstawicieli przysz│ych u┐ytkownik≤w systemu.

Wydaje siΩ, ┐e problem rodzi siΩ w≤wczas, kiedy warsztat pracy - techniki, notacja, narzΩdzia przes│oni▒ nam sens i zasadniczy paradygmat analizy wymaga±. Celem procesu analizy nie jest powstanie dokumentu o dumnej i tajemniczej nazwie ''Specyfikacja wymaga±'' tylko osi▒gniΩcie porozumienia pomiΩdzy wykonawc▒ a biorc▒ produktu informatycznego, co do oczekiwanych korzy╢ci z wdro┐enia, zakresu, istotnych cech i wa┐nych uwarunkowa± realizacyjnych (czas, bud┐et).

Analiza - proces komunikacji

Je┐eli patrzymy na analizΩ potrzeb przede wszystkim jako na proces komunikacji, troska o to, by efektem analizy nie by│a specyfikacja - p≤│kownik, powinna wyra┐aµ siΩ w zapewnieniu trzech podstawowych warunk≤w skutecznej komunikacji:

Po pierwsze - jasno okre╢lone strony, kt≤re maj▒ siΩ ze sob▒ komunikowaµ oraz zdefiniowany zakres ich odpowiedzialno╢ci. Postulat ten brzmi trywialnie, ale wcale trywialny nie jest. CzΩsto zdarza siΩ sytuacja, w kt≤rej ludzie zaanga┐owani w proces analizy maj▒ niejasno okre╢lone kompetencje, ich poziom merytoryczny jest przypadkowy, a czas jakim dysponuj▒ na potrzeby analizy nieadekwatny do tych potrzeb.

Po drugie rozumiany przez obie strony jΩzyk. Ka┐dy kto pr≤bowa│ - nie znaj▒c jΩzyka francuskiego - dogadaµ siΩ z kelnerem we Francji po angielsku, wie o czym m≤wiΩ. Oczywi╢cie obywatele Francji znaj▒ co najmniej jeden ╢wiatowy jΩzyk, co ogranicza ich potrzebΩ znajomo╢ci innych jΩzyk≤w ╢wiatowych (a zw│aszcza jΩzyka kraju, w kt≤rym kana│ La Manche okre╢lany jest mianem English Channel, samochody je┐d┐▒ pod pr▒d, a sztuka kulinarna nie wystΩpuje) czy te┐ umieszczania w menu innych ni┐ francuskie nazw potraw. Podobnie bywa w procesie analiz, .gdy jedna ze stron uwa┐a, ┐e ka┐dy powinien wiedzieµ co to jest model danych. metryka wymagania, czy ''juz kejs'', a druga s▒dzi, ┐e mo┐na swoj▒ odpowiedzialno╢µ za okre╢lanie potrzeb sprowadziµ do prostego ''ma byµ dobrze'', Wsp≤lny jΩzyk trzeba wypracowaµ, standardy notacji, metodyka, warsztatowe formy pracy mog▒ jedynie stanowiµ pewien ''wstΩpny s│ownik'', kt≤ry wymaga jednak adaptacji i przyswojenia w swej zaadaptowanej formie przez obie strony zaanga┐owane w identyfikacjΩ i analizΩ potrzeb.

Po trzecie aktywna interakcja z obu stron. Doj╢cie do porozumienia wymaga zar≤wno jasnego wyra┐ania pogl▒d≤w, jak te┐ czytelnego reagowania na komunikaty W przeciwnym wypadku proces komunikacji zamienia siΩ w dialog dw≤ch z│otych rybek w akwarium (kolega psycholog twierdzi, ┐e z│ote rybki maj▒ pamiΩµ, kt≤ra siΩga jedynie ostatnich 15 sekund - nawet je┐eli to nieprawda, to przyk│ad jest sugestywny):
- Cze╢µ.
- Cze╢µ.
- Fajny zamek.
- Jaki zamek?
- Cze╢µ.
- Aha, zamek...
- Jaki zamek?
- Zamek? Cze╢µ
...i tak dalej.

Aktywna interakcja - typowa dla warsztatowych technik zespo│owego rozwi▒zywania problem≤w - sprawia, ┐e przep│yw informacji w procesie analizy jest intensywny i szybko prowadzi do niezbΩdnych rozstrzygniΩµ, czyli do u╢wiadomienia struktury potrzeb oraz do wypracowania koncepcji rozwi▒za±.

Precyzowanie zakresu

Podstawowym celem analizy wymaga± jest precyzowanie zakresu. Pierwszym krokiem na tej drodze jest okre╢lenie ''terytorium'' na jakim poruszamy siΩ identyfikuj▒c potrzeby i mo┐liwe do pomy╢lenia rozwi▒zania. Jak uczy do╢wiadczenie, ka┐de z takich rozwi▒za± zawiera pewn▒ ilo╢µ w│asno╢ci nieistotnych z punktu widzenia potrzeb u┐ytkownika, oraz nie zawiera niekt≤rych w│asno╢ci, kt≤re s▒ dla niego wa┐ne, Jaki jest ostateczny bilans chcianego i nie chcianego, dowiadujemy siΩ tak naprawdΩ dopiero w procesie eksploatacji rozwi▒zania, jednak nie oznacza to, ┐e dobre przybli┐enie takiego bilansu nie jest mo┐liwe do uzyskania du┐o, du┐o wcze╢niej. Skuteczne precyzowanie zakresu zale┐y od obecno╢ci trzech kluczowych sk│adnik≤w analizy potrzeb.

Pierwszym z nich jest ╢wiadomo╢µ cel≤w Jednoznacznie i precyzyjnie okre╢lony cel jest podstawowym instrumentem pozwalaj▒cym na oddzielenie istotnych i nieistotnych aspekt≤w przedsiΩwziΩcia. Dzia│a jak ''brzytwa Ockhama'' eliminuj▒c z obszaru analizy te wymagania, kt≤rych spe│nienie nie wp│ywa w spos≤b istotny na osi▒gniΩcie cel≤w.

Drugim obok ╢wiadomo╢ci cel≤w wa┐nym czynnikiem analizy potrzeb jest ╢wiadomo╢µ priorytet≤w. W╢r≤d po┐▒danych cech systemu s▒ takie potrzeby (zwykle stosunkowo niewielka grupa), kt≤rych spe│nienie mo┐emy uto┐samiaµ z sukcesem projektu, S▒ i takie potrzeby, kt≤rych znaczenie jest marginalne. Dobre zrozumienie priorytet≤w w trakcie analizy potrzeb pozwala znacznie lepiej zaplanowaµ pragmatyczne rozwi▒zanie, ''mieszcz▒ce siΩ'' w limicie czasu i bud┐etu dostΩpnego dla przedsiΩwziΩcia.

Trzecim czynnikiem skutecznej analizy potrzeb jest umiejΩtno╢µ formu│owania wymaga± jako mierzalnych charakterystyk budowanego rozwi▒zania. Tutaj, niestety, w procesie analizy bardzo czΩsto zaczynaj▒ siΩ przys│owiowe schody. Konkretne sformu│owanie modelu korzy╢ci oznacza przyjΩcie odpowiedzialno╢ci za kszta│t przysz│ego rozwi▒zania, co w praktyce rodziµ mo┐e wiele nieufno╢ci i ''ukrytych agend'' w relacjach pomiΩdzy odbiorc▒ i dostawc▒ rozwi▒zania. Precyzyjne sformu│owanie wymaga± pozwala na okre╢lenie mierzalnych kryteri≤w sukcesu, a wiΩc r≤wnie┐ jednoznacznych wska╝nik≤w potencjalnej klΩski. Uszczeg≤│owienie modelu korzy╢ci mo┐e te┐ powodowaµ ciΩcia zakresu, w celu poprawienia bilansu op│acalno╢ci.

Zadeklarowanie konkretnych korzy╢ci zwi▒zanych z realizacj▒ przedsiΩwziΩcia informatycznego bywa wiΩc czΩsto trudne z przyczyn kulturowych. M≤wi▒c nieco ┐artobliwie, objawia siΩ tu odwieczny konflikt romantyzmu z pozytywizmem. Wci▒┐ bardziej kochamy szar┐Ω z szabelk▒ na przewa┐aj▒ce si│y wroga, ni┐ trze╝w▒ kalkulacjΩ, a co za tym idzie chΩtnie okre╢lamy korzy╢ci jako ''wa┐ne'', ''strategiczne'', ale niestety nie daj▒ce siΩ przeliczyµ na pieni▒dze i inne mierzalne efekty.

Standardy tworzenia specyfikacji - hierarchiczna analiza cel≤w

Podstawowe techniki identyfikacji wymaga± polegaj▒ na budowaniu drzewa (hierarchii) cel≤w, Przyk│adowe ''wcielenia'' tej techniki to choµby model GQM (Goal-Question-Metrics), czy CRA (Critical Requirement Analysis, analiza wymaga± krytycznych). NarzΩdziem hierarchicznej analizy cel≤w i problem≤w s▒ popularne diagramy Ishikawy (diagram ''rybiej o╢ci''). Ka┐da z tych technik wychodzi od centralnego punktu np. od definicji celu - a nastΩpnie stosuje okre╢lon▒ konwencjΩ postΩpowania do identyfikacji obszar≤w wymaga± powi▒zanych z celem, aby wreszcie identyfikowaµ mierzalne charakterystyki uto┐samiane z wymaganiami.

Volere

Ciekawym przyk│adem systematycznego podej╢cia do budowy specyfikacji jest schemat ''Volere'' autorstwa Jamesa i Suzanne Rohertson≤w, lider≤w Atlantic Systems Guild, Na schemat sk│ada siΩ generyczny proces (metodyka) analizy wymaga±, taksonomia wymaga± i wzorowa specyfikacja. Volere jest znacznie bogatszy, bardziej wyczerpuj▒cy i jednocze╢nie bardziej elastyczny ni┐ wiΩkszo╢µ standard≤w (np. IEEE lub ANSI). W centrum stawia on - w odr≤┐nieniu od hierarchicznej analizy cel≤w - funkcjonalno╢µ systemu opisywan▒ przez zbi≤r przypadk≤w u┐ycia i powi▒zanych z nimi wymaga± funkcjonalnych i pozafunkcjonalnych, Cele reprezentowane s▒ tu przez zbi≤r ogranicze± zewnΩtrznych (constraints) powi▒zanych z Pozosta│ymi elementami specyfikacji.

Siatka Zachmana

Siatka Korporacyjnej Architektury Informacyjnej (Enterprise Information Systems Architecture) Johna Zachmana to system my╢lenia o potrzebach zwi▒zanych z informatyzacj▒, oraz o rozwi▒zaniach realizuj▒cych te potrzeby. Zawiera propozycjΩ wielopoziomowej i wieloaspektowej klasyfikacji pojΩµ wystΩpuj▒cych w planowaniu system≤w informacyjnych - od potrzeb strategicznych, poprzez architekturΩ aplikacji po istotne charakterystyki eksploatowanych system≤w.

Podsumowanie

Warsztat pracy dla analizy potrzeb obfituje w r≤┐norodne techniki modelowania, strukturalne, obiektowe czy wykorzystuj▒ce zapis matematyczny. Pomimo tej r≤┐norodno╢ci, centraln▒ pozycjΩ w analizie potrzeb zajmuj▒ wci▒┐ tradycyjnie formu│owane wymagania. To ich jako╢µ wyznacza jako╢µ i przydatno╢µ ca│ej specyfikacji. Jako╢µ ta nie jest jednak kategori▒ oderwan▒ od procesu powstawania specyfikacji, W pracy nad wymaganiami proces jest wa┐niejszy od produktu ko±cowego. Najwa┐niejszym ''atrybutem jako╢ci'' ka┐dej specyfikacji jest to, na ile z jej zawarto╢ci▒ identyfikuj▒ siΩ odbiorcy przysz│ego rozwi▒zania. Mo┐emy to osi▒gn▒µ tylko w jeden spos≤b - dbaj▒c, by proces analizy potrzeb by│ procesem autentycznego precyzowania zakresu i komunikowania siΩ odbiorcy i wykonawcy danego systemu.

Artyku│ ukaza│ siΩ w kwartalniku mened┐er≤w informatyki "Strategie Informatyzacji" wydawanym przez firmΩ InfoViDE.

InfoViDE jest polsk▒ firm▒ konsultingowo-szkoleniow▒, koncentruj▒c▒ siΩ na zapewnieniu klientom strategicznych korzy╢ci z wykorzystania technologii informatycznych. InfoViDE jest wiod▒cym dostawc▒ us│ug konsultingowych i praktycznej wiedzy fachowej dotycz▒cej zarz▒dzania przedsiΩwziΩciami, analizy potrzeb informacyjnych, czy projektowania system≤w informatycznych stanowi▒cych rozwi▒zania dla biznesu. Ecommerce Zarz▒dzanie PrzedsiΩwziΩciami i Architektura SI Systemy Wspomagania Decyzji Organizacja Zapewnienia i Kontroli Jako╢ci Budowa Aplikacji i System≤w Informatycznych SAP www.infovide.pl