Bogdan Bereza Quo Vadis, analizo? Historia, teraźniejszość i przyszłość analizy biznesowej oraz inżynierii wymagań

Transkrypt

1 Quo Vadis, analizo? Historia, teraźniejszość i przyszłość analizy biznesowej oraz inżynierii wymagań Co robili starożytni? Wprawdzie nasi przodkowie nie budowali systemów IT, bowiem nie mieli jeszcze komputerów, ale budowali wiele innych rzeczy, co do których też warto było wiedzieć, co właściwie ma powstać, zanim wbiło się pierwsze gwoździe, postawiło pierwsze kroki w jakąś stronę, albo kupowało przedmiot od sąsiada. W przeciwnym razie, konsekwencje mogły być niemiłe: Wraz z pojawieniem się pierwszych wspólnot osiadłych, rozpoczął się handel wymienny: obie strony transakcji znały się wzajemnie. Gdy wyroby psuły się, to wszyscy w osadzie o tym wiedzieli i przynosiło to hańbę wytwórcy. [ ] Pojawienie się handlu między osadami spowodowało [ ] handel na ryzyko kupującego Kupujący musiał ocenić produkt pod względem jego użyteczności w chwili zakupu, potem kupcy wyjeżdżali i gdy wyroby nie działały lub psuły się, nie wiadomo było do kogo mieć pretensje. 1 Przeskoczmy teraz kilka tysięcy lat i popatrzmy na wymowny przykład o wiele późniejszy: jakie kłopoty spowodowało lekkomyślne traktowanie wymagań, czyli niestosowanie zasad inżynierii wymagań, w roku Wtedy to, 10 sierpnia, przewrócił się i zatonął, kilkanaście minut po odbiciu od nadbrzeża, nowo zbudowany okręt flagowy marynarki szwedzkiej Wasa 2. Przyczyny? Okręt z powodu ambicji króla był potężniejszy niż inne ówczesne okręty dwupokładowy. Takie było życzenie króla, któremu nikt nie ośmielił się przeciwstawić nasuwa się tutaj myśl, czy więc na pewno klient ma zawsze rację? Bowiem dwupokładowy okręt miał znacznie wyżej środek ciężkości i okazał się w związku z tym niezwykle wywrotny. Analiza biznesowa wskazała wprawdzie, że potrzebne są dwa pokłady z działami, ale zbyt szybko przeskoczono od potrzeby biznesowej do jej implementacji budowy kadłuba. Zaniedbano etapy pośrednie: inżynierię wymagań, która między innymi zajmuje się takimi atrybutami wymagań, jak ich wykonywalność (feasibility) 3, oraz projektowanie: nie umiano jeszcze wówczas precyzyjnie wyliczyć stabilności statku na podstawie danych o jego wymiarach i rozkładzie ciężaru. Zastosowano metodę, którą można by nazwać mega-agile: po prostu pracowici cieśleprogramiści dobudowali jeszcze jeden pokład, zgodnie z życzeniem zleceniodawcy-króla! Tak więc popełniono kardynalny błąd jakże typowy we współczesnych projektach IT już w początkowej fazie projektu, wynikający z powszechnego i wtedy, blisko 400 lat temu, i dzisiaj podejścia po co marnować czas na jakiś SRS, bierzmy się do roboty. 1 Inżynieria oprogramowania jak zapewnić jakość aplikacjom, Bogdan Bereza i Bolesław Szomański, 2009, Wydawnictwo Helion. 2 Wydobyty w 1961, okręt można dziś oglądać w Muzeum Wasa ( 3 IEEE Recommended Practice for Software Requirements Specification (IEEE ). Strona 1 z 6

2 Warto jeszcze rzucić okiem na konsekwencje tego błędu, bardzo charakterystyczne. Kiedy projekt popada w kłopoty albo wręcz, jak Wasa, kończy się spektakularną klęską zwykle winnych szuka się wszędzie, tylko nie w braku inżynierii wymagań. Otóż, oczywiście, choć cichutko wtedy jeszcze nie zniesiono kary śmierci obwiniano królazleceniodawcę i jego idiotyczne pomysły. Hm, tylko że z takich to pozornie idiotycznych pomysłów biorą się wielkie sukcesy biznesowe, zgodnie z zasadami strategii błękitnego oceanu 4, tylko trzeba umieć sobie z nimi radzić na przykład stosując inżynierię wymagań. Obwiniano głównego konstruktora, Henrika Hybertssona: no, jasne. Gdyby statek zatonął ledwo pół roku później, tenże Hybertsson zbierałby pochwały. Ocena kierowników projektów zawsze jest przeraźliwie krótkowzroczna, oparta albo na pozornym sukcesie, albo na równie pozornej, byle spektakularnej, klęsce. Jak zwykle, obwiniano też testowanie: czemu nie ostrzegli? Otóż, testowanie wykonano. Stabilność kadłuba sprawdzano wówczas w ten sposób, że gromada kilkuset robotników stoczni biegała po pokładzie z jednej strony na drugą, rozkołysując kadłub. W przypadku Wasy testy przerwano, gdyż kadłub zaczął się kołysać zbyt niebezpiecznie, grożąc wywrotką. Króla zaś nie zawiadomiono, bowiem obawiano się jego gniewu. No i jeszcze oskarżano Polaków, bo to z nami głównie wojował król Gustaw II Adolf. Polski sabotaż był więc ponętnym wyjaśnieniem. Sam król, nakazując śledztwo, określił przyczynę awarii jako głupotę i niedbalstwo. Bingo, proszę króla! Budując wielkie, skomplikowane rzeczy, ludzie z definicji są głupi, bo rozum nie wsparty narzędziami - nie radzi sobie z nimi, zaś niedbalstwo jest naszą cechą przyrodzoną geny pieczołowitości i staranności wyginęły dawno temu, stając się pokarmem tygrysów szablastozębnych, przed którymi nasi pieczołowici i staranni przodkowie nie uciekali, zajęci regułami i rytuałami. Wiedząc o tym, wprowadzamy procesy i procedury, które tę staranność gwarantują albo ich nie wprowadzamy, i nie przestrzegamy, wtedy tonie Wasa lub projekt IT kończy się klęską. Czyli, pod pewnymi względami, inżynieria wymagań jej wielka potrzeba i jeszcze większy brak jest bardzo, bardzo stara. Programistyczny pięściak Pięściak, albo tłuk pięściowy, wykonywano z twardego krzemienia, więc nasz jaskiniowy pra-praprzodek w swoim własnym interesie realizował trochę inżynierii wymagań, żeby jego wielodniowe wysiłki nie poszły na marne. Źle wykonany pięściak trudno było przerobić na coś innego. W latach czterdziestych i pięćdziesiątych ubiegłego wieku nauczyliśmy się wytwarzać pięściaki z miękkiego krzemu zamiast krzemienia. No, może sam krzem pierwiastek nie jest specjalnie użyteczny, ale w układach scalonych i budowanych z nich komputerach jak najbardziej. Komputery bowiem umożliwiają wykonywanie oprogramowania, które można modyfikować i 4 "błękitnego_oceanu" Strona 2 z 6

3 przerabiać o wiele łatwiej i taniej niż krzemienne pięściaki, albo budowane z drewna żaglowce. Ta łatwość zarówno robienia nowych rzeczy, którą daje oprogramowanie, jak i łatwość ich zmieniania, jest podłożem całego olbrzymiego skoku cywilizacyjnego bez precedensu, jaki zanotowaliśmy od lat 50-ych zeszłego wieku do dziś. Z drugiej strony, ta łatwość okazała się też niebezpieczna. Względnie nieskomplikowane algorytmy programów w latach 40-ych i 50-ych, w dodatku tworzone od początku do końca przez ludzi wybitnych, nawet laureatów nagrody Nobla 5, nie wymagały stosowania ani analizy biznesowej, ani inżynierii wymagań. Od tego czasu sytuacja zmieniła się diametralnie: wielomilionowej rzeszy twórców oprogramowania nie daje się już obsadzić geniuszami, a dla większości aplikacji oraz systemów IT o wiele ważniejsza jest ich zgodność z potrzebami biznesowymi, niż stosowanie trudnych, matematycznych algorytmów. Dlatego od podejścia charakteryzującego lata 50-e i 60-e od pojmowania tworzenia programów jako radosnego rzemiosła artystycznego, IT przeszło do nowej fazy inżynierii oprogramowania. Ta faza trwa do dziś i niesie nas w przyszłość. Inżynieria wymagań jest jednym ze składników inżynierii oprogramowania. Kalendarium inżynierii wymagań Konferencja Inżynierii Oprogramowania NATO, 1968 Tak zwany wówczas kryzys oprogramowania coraz trudniej było znaleźć wystarczającą liczbę wysoko kwalifikowanych programistów, coraz częściej projekty informatyczne przekraczały i budżet, i harmonogram 6, spowodował, że zaczęto poszukiwać środków zaradczych początkowo głównie z sferach języków programowania oraz jego architektury. Wyrazem tych tendencji była właśnie rzeczona konferencja, kiedy, wedle legendy, po raz pierwszy oficjalnie użyto określenie inżynieria oprogramowania. Inżynieria wymagań Ten termin prawdopodobnie po raz pierwszy pojawił się w druku w 1979 roku, w tak zwanym raporcie TRW 7, ale nie było szerzej znane ani stosowane aż do lat 90-ych, kiedy pojawiło się klasyczne opracowanie IEEE CS pod tytułem System and Software Requirements Engineering. Jak w wielu obszarach, także w dziedzinie inżynierii wymagań widać odmienność między światem akademickim, a realiami przemysłu IT. W świecie akademickim określenie inżynieria wymagań (jako gałąź szeroko rozumianej inżynierii systemów oraz inżynierii oprogramowania) jest powszechnie znane i przyjęte. Najpoważniejsze czasopismo w tej dziedzinie Requirements Engineering Journal 8 5 Przyszłość IT tworzą geniusze ( 6 Doświadczenia z tego okresu opisuje m.in. książka Freda Brooksa Mityczny osobomiesiąc. Eseje o inżynierii oprogramowania z 1975 roku, wielokrotnie usupełniana i wznawiana. 7 Software Requirements Engineering Methodology, TRW Defense and Space Systems Group Oryginalna nazwa lokalizacji: Strona 3 z 6

4 wydawane jest regularnie od 1996 roku, a więc już od szesnastu lat. Jeszcze starsza jest konferencja: IEEE International Requirements Engineering Conference odbędzie się w tym roku już po raz dwudziesty pierwszy 9. Historia i materiały ze wszystkich wcześniejszych konferencji znajdują się na portalu requirements-engineering.org, począwszy od roku Ciekawe porównanie największa w Europie konferencja na temat testowania oprogramowania, EuroSTAR, też po raz pierwszy odbyła się w 1993 roku, w Londynie. W międzyczasie testowanie stało się big business i modne: przykładowo, quasi-monopolistyczna organizacja ISTQB 10, działająca od 2003 roku, chwali się dziś ponad armią osób mających tak zwany certyfikat podstawowy testowania oprogramowania, podczas gdy analogiczna organizacja inżynierii wymagań, IREB 11, dopiero niedawno przekroczyła liczbę osób z certyfikatem podstawowym inżynierii wymagań. O co chodzi? Przecież kluczowe znaczenie inżynierii wymagań zarówno dla biznesu, jak i dla IT wydaje się nie budzić najmniejszych wątpliwości. Przeszkoliwszy wiele tysięcy osób w zakresie testowania, w tym na ów niezmiernie popularny certyfikat ISTQB, autor tego artykułu wielokrotnie zetknął się z opiniami osób zajmujących się testowaniem, że źródłem wszelkich kłopotów, które skrupiają się na testerach i testowaniu, są niedostatki inżynierii wymagań właśnie, czyli wiedza na ten temat istnieje w przemyśle IT, ale nie przekłada się na żadne działania. Czemu? Wyjaśnienie, moim zdaniem, ma charakter bardziej antropologiczny i socjologiczny, niż informatyczny. Otóż nazwijmy je tak górne obszary inżynierii wymagań zadomowiły się pod nazwą analizy biznesowej względnie wysoko w świecie organizacyjnych i korporacyjnych hierarchii; całkiem słusznie zresztą, bo trudno oczekiwać, że analizą biznesową będą się zajmować osoby z niewielkim doświadczeniem, nie mające całościowej wizji działania firmy. Z drugiej strony znów posłużę się ryzykowną nazwą dolne rejony inżynierii wymagań zadomowiły się w świcie projektowania, architektury systemów, w niełatwych technicznie zagadnieniach modelowania, UML, DDD To co pośrodku taka czysta inżynieria wymagań jakoś nie może dobić się uznania. Oczywiście, istnieje w rzeczywistości, bo magiczny, cudowny skok od wyników analizy biznesowej do diagramów UML, ani tym bardziej do gotowego, działającego kodu, nie istnieje. Czyli zadania inżynierii wymagań wykonują lepiej lub gorzej kierownicy projektów, dbający, żeby produkt końcowy jakoś tam dał się wcisnąć odbiorcom; inżynierami wymagań są też członkowie zespołów agile, zwłaszcza mistrzowie młyna 12 (kocham terminologię agile!). 9 W czerwcu 2013, w Rio de Janeiro ( 10 ISTQB International Software Testing Qualifications Board istqb.org, zrzesza ponad 40 krajów członkowskich, w tym Polskę. 11 IREB International Requirements Engineering Board ireb.org powstało w 2006 roku. 12 Czyli Scrum Masters Strona 4 z 6

5 I co dalej, czyli obiecane quo vadis Jak słusznie ktoś zauważył, osobiście mam skłonność do trafnego przewidywania zdarzeń IT, tyle że przedwcześnie. Na przykład, przywlokłem do Szwecji w 1999 roku nowość certyfikację ISEB (to taka dawna forma ISTQB), do Polski w 2001 i 2002 roku konferencje i szkolenia testowe oraz inspirację do założenia organizacji testerów oprogramowania. W 2005 roku opublikowałem artykuł pt. Drogowskaz do przyszłości - mądrość będzie na serwerach, czyli ASP 13 i hey presto oto mamy od paru lat arcy-modne pojęcie chmury obliczeniowej! Wszystkie przeze mnie przewidywane kierunki zrealizowały się w 110% i stały wielkim biznesem, ale ja sam już w tym zrywaniu owoców moich proroctw jakoś nie uczestniczę. Dlatego zachęcam do uważnej lektury poniższego akapitu to, co tam piszę, sprawdzi się na pewno, natomiast wciąż nieobsadzone są stanowiska prezesów organizacji, wciąż do wzięcia jest rynek szkoleń. Zacytujmy więc poetę: RE is like candy on a shelf / You want to taste and help yourself / The sweetest things are there for you / Help yourself, take a few / That's what I want you to do. Szok szkoleniowo-certyfikacyjny Szkolenia przygotowujące do certyfikacji IREB CPRE (Certified Professional in Requirements Engineering) będą za 2-3 lata szły jak świeże bułeczki. Na wyższych piętrach, spopularyzują się certyfikaty IIBA 14, oraz QAMP 15. W tej sytuacji wzrośnie rola polskiego oddziału IREB ( Organizacje Tak jak pół roku temu w Szwecji powstało SARE (Swedish Association for Requirements Engineering, tak w Polsce okrzepnie Stowarzyszenie Inżynierii Wymagań ( stanowisko prezesa nie obsadzone!). Konferencja Dobre Wymagania 2013 (breq2013.wymagania.org.pl) wprawdzie odbędzie się, jak zaplanowano, kwietnia 2013, ale prawdziwym sukcesem komercyjnym okaże się dopiero w 2014 roku, kiedy pod zmienioną nazwą wezmą się za nią mistrzowie marketingu i PR-u. Pisma: pojawi się nowe, międzynarodowe, wielojęzyczne pismo na temat inżynierii wymagań, którego główna wersja będzie anglojęzyczna JAKAŚDOMENA.com, ale będzie też miało swoje wersje w innych językach, np. polska.jakaśdomena.com. Praktyka i narzędzia Opisywane w Computerworld już wielokrotnie ADP (Automated Defect Prevention) jako metoda zarządzania projektami IT, stanie się czymś powszechnie stosowanym i oczywistym, oczywiście pod lepszą marketingowo nazwą skoro chmura jest już zajęta, to może inne, duże IIBA International Institute of Business Analysis (iiba.org). 15 QAMP Quality Assurance Management Professional ( Strona 5 z 6

6 zjawisko naturalne, np. wulkan albo śnieżyca? Ta powszechna za 5-10 lat metodyka usunie z zarządzania projektami zarówno magię i szarlatanerię, jak i biurokrację, zamiast nich wprowadzając automatyzację czynności powtarzalnych i prostych, oraz śledzenie statusu projektu na podstawie wymagań jak już pisaliśmy przed Świętami w numerze 35/2012 ( Projekty z automatu 16 ). Potwierdzam tak będzie. Bogdan Bereza, bogdan.bereza@victo.eu 16 Strona 6 z 6