Wymagania: IT w pigułce
Transkrypt
Wymagania: IT w pigułce
Bogdan Bereza „Wymagania: IT w pigulce” Wymagania: IT w pigułce 28 stycznia 1986 roku: w 73 sekundzie lotu promu kosmicznego „Challenger” nastąpiła eksplozja – cała załoga zginęła. W komisji, badającej przyczyny katastrofy, uczestniczył między innymi laureat Nagrody Nobla, słynny fizyk Richard Feynman. To jego przede wszystkim zasługą było wykrycie przyczyny śmiertelnej awarii: uszczelki w silnikach pomocniczych nie działały poprawnie w niskich temperaturach, o czym wprawdzie dobrze wiedzieli szeregowi pracownicy projektu, ale ta wiedza jakoś nie dotarła to kadry zarządzającej, lub została przez nią zignorowana. 1996: w wyniku błędu oprogramowania, misja 501 rakiety „Ariane 5” kończy się zaraz po starcie efektowną eksplozją – na szczęście nikt nie zginął, ale z dymem poszło kilkaset milionów dolarów. Rok 2012: pawilon „Emilia” w centrum Warszawy, kupiony od miasta przez spółkę deweloperską, zostaje – bez wiedzy kupujących – wpisany na listę zabytków, co dramatycznie obniża wartość tej nieruchomości. Konserwator zabytków tłumaczy się, że „nie przyszło mu do głowy” zawiadomić właściciela, zaś rzecznik Ministerstwa Kultury mówi: „nie było złej woli, zabrakło procedur”. Przyczyny pomyłek, błędów i awarii Co mają ze sobą wspólnego te trzy, opisane powyżej, tak na pozór różne, historie? Temu zagadnieniu poświęcona jest znakomita książka Dietricha Dörnera „The Logic of Failure”. Jest to książka… psychologiczna o tym, jak ludzie systematycznie i spektakularnie mylą się, podejmują złe i głupie decyzje, tak samo w IT, jak w administracji, w przemyśle, w rolnictwie. Pewnie to prawda… tylko co nam, ludziom IT, z tej gorzkiej wiedzy? Cóż, dzięki niej mamy szansę przestać się łudzić, że dobre wyniki projektów IT osiągnie się za pomocą natchnienia, uduchowienia, intuicji albo najnowszego języka programowania o dziwacznej nazwie. Sorry, folks, niezbędne są procedury – nie biurokracja i papierologia, ale elastyczne, sprawne i w miarę możliwości automatyczne procedury, zabezpieczające nas przed skutkami naszych – w 100% ludzkich – pomyłek. Procedury, to nie kosztowny luksus, lecz wręcz przeciwnie – oszczędność. Dzięki nim wykryjemy skutki ludzkich pomyłek – błędy – jak najwcześniej, kiedy ich usunięcie jest jeszcze względnie tanie. Dzięki procedurom projekty będą przebiegały sprawniej, a programiści, testerzy i – co najważniejsze – Klienci – będą szczęśliwsi. Jak piękny jest świat, kiedy nie musimy marnować czasu i nerwów na borykanie się ze skutkami cudzych pomyłek, ani na maskowanie własnych! Strona 1 z 9 Bogdan Bereza „Wymagania: IT w pigulce” Inżynieria wymagań – splot słoneczny IT Procedury, to jakby drogi, prowadzące nas jak najlepiej do celu. Pojemne określenie „jak najlepiej” czasem oznacza autostradę, czasem wąską ścieżkę, czasem kolejkę linową, a czasem nawet przedzieranie się z kompasem przez bezdroża – zależnie och celu. Uwaga: w dwóch powyższych zdaniach dwukrotnie użyłem słowa „cel”. Cel trzeba znać, aby wiedzieć, dokąd idziemy, ale również, aby wybrać jak najlepszą drogę, która tam – do celu – prowadzi. Polecam małe ćwiczenie: wpisać w Google wyrażenie „definicja celu” i pooglądać wyniki wyszukiwania. Cel, to wiedza o tym, co chce się zrobić, dokąd dojść, co zrealizować. Cel, czyli wymagania wobec systemu IT. To nie jest popularna nazwa: częściej mówi się o warunkach, o celach, założeniach, projektach, właściwościach. Zaś nazwa dziedziny wiedzy, uczącej, jak znajdować, określać i skutecznie realizować cele – inżynieria wymagań – to już – niestety! – zupełna rzadkość. Szukając na portalach pośrednictw pracy, znajdujemy oferty dla analityków, sprzedawców, projektantów, programistów, nawet testerów! – ale ze świecą szukać firmy, ogłaszającej potrzebę zatrudnienia inżyniera wymagań. Trochę lepiej wygląda to na uczelniach, gdzie zdarzają się studia podyplomowe dla inżynierów wymagań. Tymczasem inżynieria wymagań, to w istocie rzeczy dziedzina, obejmująca wszystkie kluczowe dla powodzenia przedsięwzięć IT obszary, których nazwy atakują nas dziś ze wszystkich stron: analizę biznesową, techniki sprzedaży, metodyki agile, metody zarządzania, technologie programowania, sposoby testowania, i nawet prawo IT. Niepowodzenia projektów, zarówno IT, jak innych, nieodmiennie wynikają z deficytów inżynierii wymagań, choć łatwiej nam mówić o… pomyłkach prezesa Lato, bezmyślnych urzędnikach czy niestarannych programistach. „Nie było złej woli – zabrakło procedur”, a procedury to wszakże drogi, prowadzące do celu, czyli zabrakło umiejętności określenia celu i sposobów jego realizacji: zabrakło inżynierii wymagań. Analiza biznesowa, to właśnie inżynieria wymagań Niby to samo, a jednak nie to samo: zależy, jak zdefiniuje się zakres obu pojęć. W praktyce, analityk (analityk biznesowy), to osoba, która bada i opisuje (modeluje) procesy biznesowe, te istniejące obecnie, jak i te, które chce się mieć w przyszłości. Na razie jakby niewiele ma to wspólnego z informatyką? - tyle że w dzisiejszych czasach wszelkie zmiany procesów biznesowych oznaczają albo zmiany istniejących systemów IT, albo wdrażanie nowych rozwiązań IT, czyli analiza biznesowa to dyscyplina na wskroś informatyczna. Z punktu widzenia inżynierii wymagań (pojęcie stosowane wyłącznie w IT, podczas gdy analiza biznesowa jest określeniem używanym w wielu branżach), analiza biznesowa to albo pierwszy etap inżynierii wymagań, albo proces ją poprzedzający, źródło wiedzy dla tak zwanego procesu pozyskiwania wymagań. Często spotyka się opisy, gdzie nazwa „inżynieria wymagań” w ogóle nie występuje: następnym krokiem po analizie biznesowej jest projektowanie systemów (czasem między nimi pojawia się Strona 2 z 9 Bogdan Bereza „Wymagania: IT w pigulce” jeszcze analiza systemowa). Nieważne są nazwy – problem w tym, że jakże często chaos w nazewnictwie sprzyja chaosowi w projektach: Analiza biznesowa A miracle happens… Projektowanie systemu Jak przemysł IT często widzi proces oprogramowania Ponieważ jednak cuda zdarzają się nieczęsto, skutkiem takiego podejścia informatycy – projektanci, architekci, programiści – słabo orientują się, co właściwie mają skonstruować. Przykłady w obfitości każdy znajdzie we własnym doświadczeniu, a ponadto w komiksach Dilberta… Oto, jak naprawdę wyglądają relacje między analizą biznesową, inżynierią wymagań i projektowaniem: Inne wymagania biznesowe Analiza biznesowa Pozyskiwanie wymagań Inżynieria wymagań (proces wymagań) Projektowanie systemu Wymagania techniczne A tak jest naprawdę – nawet jeśli te procesy inaczej się nazywają! Sprzedaż, to – o dziwo! - inżynieria wymagań Aż w głowie się kręci, tyle jest rozmaitych teorii sprzedaży, metod sprzedaży, technik sprzedaży i szkoleń dla sprzedawców! Z lewej strony naciera marketing i zagadnienia tworzenia marki, z prawej – techniki sprzedaży, z dołu – reklama, a z góry – zarządzanie doświadczeniem klienta1. 1 Customer Experience Management (CEM). Strona 3 z 9 Bogdan Bereza „Wymagania: IT w pigulce” I wszędzie powtarzane jest jak mantra: poznać potrzeby klienta, odkryć potrzeby klienta, stworzyć nowe potrzeby klienta, ukierunkować potrzeby klienta na swój produkt, zidentyfikować ukryte – autentyczne – długofalowe potrzeby klienta… Czy chodzi o proszek do prania, samochód, film, biuro podróży czy system komputerowy2, sedno sprawy to wykryć, zrozumieć, opisać i przełożyć na język operacyjny wykonanie produktu czy usługi, które będziemy realizować i z zyskiem sprzedawać. Czyli innymi słowy, sprzedaż to w gruncie rzeczy forma inżynierii wymagań, a psychologiczne zagrywki, potrzebne do złapania klienta, wykładane na szkoleniach sprzedawców jako wiedza tajemna, omawia się na kursach analizy biznesowej oraz inżynierii wymagań pod skromną nazwą technik pozyskiwania wymagań. Inna rzecz, że tradycyjna inżynieria wymagań też mogłaby się niejednego nauczyć od marketingu oraz reklamy: a dlaczego niby nie robić spotkań JRP przy muzyce i występach dobrze zbudowanych tancerzy płaci obojga!? Niech jednak lepiej zostanie, tak jak jest – bo bez tej otoczki czarnej magii, NLP, freudyzmu i guślarstwa, dostawcy szkoleń dla sprzedawców poszliby wkrótce z torbami! Ale czytelnicy tego artykułu niech wiedzą, jak jest naprawdę. Metodyki agile, to - wbrew mitom - inżynieria wymagań Wymagania kojarzą się wielu osobom z opasłymi, zakurzonymi - fizycznym lub wirtualnym kurzem - tomami dokumentacji, której nikt nie czyta, która zawsze jest nieaktualna, niepotrzebna i nieczytelna, oraz z paraliżującą biurokracją. Natomiast metodyki zwinne – agile, extreme programming, TDD – same już nazwy brzmią radośnie, luzacko, nowocześnie! Lecz to tylko przesądy. Podobnie jak nie każdy homoseksualista jest wesoły (gay), a nie każdy heteroseksualista jest ponurym katoendekiem, tak samo porządna inżynieria wymagań nie musi być przygnębiającym nudziarstwem, zaś metody agile nie tylko nie obywają się bez inżynierii wymagań – one są wręcz częścią inżynierii wymagań! Co wykryli i ogłosili światu sygnatariusze Manifestu Agile (www.agilemanifesto.org)? Otóż odkryli proste i w gruncie rzeczy dobrze znane, choć powszechnie ignorowane zasady inżynierii wymagań i zarządzania projektami, a mianowicie: Wymagania są zwykle zmienne (często – ogromnie zmienne!) i potrzebny jest sprawny, elastyczny proces zarządzania tymi zmianami; Klienci – użytkownicy często nie są w stanie od początku zdefiniować i jednoznacznie określić swoich potrzeb oraz wymagań, a skuteczną metodą, jak im pomóc, jest 2 W gruncie rzeczy chodzi o to samo, bowiem produkcja i dystrybucja proszku do prania, funkcjonalność samochodu, produkcja i dystrybucja filmu oraz logistyka biura podróży realizowane są w 90% przy pomocy systemów IT. Strona 4 z 9 Bogdan Bereza „Wymagania: IT w pigulce” prototypowanie: tworzenie dla nich małych fragmentów funkcjonalności, które ułatwiają klientom odkrycie, czego tak naprawdę chcą; W takiej sytuacji, próby kurczowego trzymania się modelu kaskadowego cyklu wytwarzania oprogramowania, oraz próby szczegółowego opisania wymagań zanim przystąpi się do tworzenia kodu, są nieskuteczne i szkodliwe. Oto cała koncepcja agile w pigułce, a reszta – humanistyczna frazeologia („ludzie są ważniejsi niż dokumentacja”), rozmaite rytuały (np. programowanie parami) oraz ostentacyjnie dziwaczna terminologia (np. „młyn” i „przebieg” w terminologii agile scrum) – to tylko szczegóły. Podsumowując – metodyki zwinne przyniosły IT cenne odkrycie, że wymagania można i niekiedy ogromnie warto odkrywać (pozyskiwać) przy pomocy prototypowania i bardzo częstych kontaktów z klientem; że dobrą definicją wymagania może być czasem zaakceptowany przez klienta kawałek kodu, a nie pracochłonny opis, który rozmija się z rzeczywistymi potrzebami użytkowników. Znakomicie! – tylko niech nikt nie twierdzi, że podejście agile eliminuje inżynierię wymagań, skoro jest przeciwnie – metody zwinne wprowadzają inżynierię wymagań w procesy projektowania i programowania w znacznie większym stopniu, niż odważały się metody tradycyjne! Zarządzanie projektami, to nic innego, jak inżynieria wymagań PRINCE-2, PMI, zarządzanie projektami, przez cele, procesowe, humanistyczne, zasobami ludzkimi – wow! Wielki świat, pełen wypasionych metodyk, monopoli, guru, mistrzów, szkół, certyfikatów, trzyczęściowych garniturów, NLP, BMW i nawiedzonych przywódców! A jednak… spróbujmy przyjrzeć się dokładnie: a nuż król jest nagi? Zarządzanie projektami to: 1. Określenie, co jest celem projektu; 2. Oszacowanie pracochłonności projektu; 3. Identyfikacja zadań do wykonania, przydzielenie ich ludziom i budowa harmonogramu; 4. Nadzorowanie przebiegu projektu, jego statusu, zgodności z harmonogramem i podejmowanie działań zaradczych, kiedy projekt zaczyna się walić. Teraz spójrzmy na te zadania z perspektywy inżynierii wymagań. 1 – określenie celu – to jest inżynieria wymagań w 100%; 2 – oszacowanie pracochłonności – to zestaw metod, pozwalających na podstawie wymagań szacować pracochłonność ich realizacji; klasycznym przykładem jest np. analiza punktów funkcyjnych; Strona 5 z 9 Bogdan Bereza „Wymagania: IT w pigulce” 3A – identyfikacja zadań, to podział wymagań głównych (nadrzędnych) na mniejsze, cząstkowe; 3B – przydzielenie zadań i harmonogramowanie nie należą – przyznaję - do inżynierii wymagań, ale ich wyniki przekładają się na atrybuty wymagań (np. czas wykonania, osoba odpowiedzialna za realizację wymagania); 4 – nadzorowanie, to określanie statusu (stopnia) realizacji poszczególnych wymagań. Celem powyższego wywodu nie jest udowadnianie naciąganej tezy, że inżynieria wymagań oraz zarządzanie projektami to w 100% jedno i to samo – bo tak nie jest. Należy jednak koniecznie zrozumieć, że te dwa procesy są ze sobą ogromnie powiązane, w związku z czym nie ma – cokolwiek twierdzą modne teorie i VIP-certyfikaty dla kierowników projektów – nie ma dobrego kierowania projektem bez zaangażowania się w inżynierię wymagań! Każdy zaś kierownik projektu, który bawi się w wielkiego lidera, nie dbając o wymagania („Umiecie przecież sami napisać program! Czy trzeba was prowadzić za rączkę? Klient nie ma czasu określić swoich wymagań!”), tylko pozoruje kierowniczą pracę i przynosi więcej szkody niż pożytku. Programowanie, to też inżynieria wymagań Jeśli programowania, to inżynieria wymagań, czy wobec tego wbijanie gwoździ lub układanie cegieł, to architektura czy wręcz biznesplan dla nowego wieżowca? I tak, i nie. Oczywiście, czynności wykonywane przez osobę trzymającą młotek lub kielnię, są dramatycznie odmienne od czynności, wykonywanych przez osoby pracujące w z modelowaniem biznesowym w MS Excel, lub przy pomocy CAD architekta. Niemniej, w dobrze zorganizowanym projekcie każde uderzenie młotka i położenie każdej cagły powinny wynikać precyzyjnie z wcześniejszej dokumentacji, z projektu architektury, z wymagań – w przeciwnym razie zagrożenia projektu są ogromne. Sytuacja w IT jest o tyle szczególna, że podczas gdy w budownictwie nie ma szans na zbudowanie gmachu przy pomocy samych murarzy, bez planistów i architektów, o tyle w IT w jakimś sensie daje się to zrobić – tyle że znacznie gorzej i znacznie drożej. Co więcej, kompetencje planisty, architekta, operatora dźwigu i murarza to zupełnie różne światy, natomiast między inżynierem wymagań, projektantem i programistą nie ma aż tak dużych różnic. Stąd bierze się wiele chronicznych problemów IT. Pokusa pisania kodu na łapu-capu jest wielka – program, w przeciwieństwie do mostu, można poprawiać wielokrotnie, nawet po widowiskowym zawaleniu się – i za uleganie tej pokusie przychodzi nam nieraz drogo płacić. Strona 6 z 9 Bogdan Bereza „Wymagania: IT w pigulce” Testowanie, to po prostu inżynieria wymagań Testowanie, to kontrola, czy to, jak jest, zgadza się z tym, jak ma być. Na przykład, czy aplikacja poprawnie dodaje albo steruje urządzeniem, czy dokument zgodny jest ze swoim celami z dokumentami źródłowymi, czy funkcja pomocy w programie wyświetla właściwe informacje. Skąd jednak wiadomo, jak ma być? To jest właśnie zapisane w wymaganiach! Doprawdy? – zaoponuje ktoś.To jakim cudem odbywa się testowanie w tysiącach projektów, gdzie wymagania są niepełne, błędne, niespójne, nigdzie nie zapisane? Cóż, wtedy albo testowanie jest najzupełniej bezcelowym marnowaniem czasu (skoro każdy wynik testu daje się na siłę wyinterpretować jako „w zasadzie poprawny”…), albo brakujące wymagania de facto zdobywa się podczas testowania. Testerzy domyślają się, jaki ma być zgodny z niezapisanymi wymaganiami wynik oczekiwany. Czasem domyślają się dobrze, czasem źle, często – inaczej niż programiści, czasem – inaczej niż użytkownicy. Jest nawet cała, modna szkoła „testowania eksploracyjnego”, która uczy, jak kreatywnie domyślać się, mimo braku wymagań, co jest OK, a co nie jest, lub niestandardowo zdobywać wymagania ze starych manuali, z rozmów przy piwie, w saunie… Pięknie, ale czasochłonnie, drogo… i nie zawsze skutecznie. Prawnicy, to zamaskowani inżynierowie wymagań 7 marca 2008 roku zorganizowaliśmy 1-dniową konferencję „SoftLex – prawne aspekty inżynierii oprogramowania”. Okazało się wtedy, jak liczne są podobieństwa – mimo wielkich różnic terminologii – podejścia prawników, inżynierów wymagań oraz testerów projektujących testy akceptacyjne. Kontrakt na „wdrożenie systemu” (tak w języku prawniczym nazywa się budowa systemu na zlecenie) określa warunki, które muszą być spełnione, aby zadanie dostawcy uznać za wykonane. Propozycja jednego z dostawców, opisania warunków odbioru systemu zdaniem „oprogramowanie w zasadzie będzie działać”, skontrowana przez prawnika strony zamawiającej propozycją, że w tej sytuacji zamawiający „w zasadzie zapłaci za aplikację”, okazało się niedostatecznie precyzyjne… Jednym słowem, zrozumienie podstaw inżynierii wymagań orzez prawników i podpisujących kontrakty menedżerów jest potrzebne. Nauka i certyfikacja inżynierii wymagań Zasad inżynierii wymagań oraz analizy biznesowej można się nauczyć. Istnieje szereg kursów uczących konkretnych metod modelowania tak procesów biznesowych, jak i wymagań (m.in. popularne UML), ale tutaj podamy kilka znanych na świecie certyfikacji ogólnych, wykraczających poza jedną technikę. Strona 7 z 9 Bogdan Bereza „Wymagania: IT w pigulce” IREB – Intenational Requirements Engineering Board Certyfikaty inżynierii wymagań oferuje międzynarodowa organizacja IREB (www.ireb.org). Polska gupa działaczy IREB (www.ireb.org.pl) zajmuje się promocją wiedzy na temat inżynierii wymagań w Polsce i udostępnieniem sylabusów oraz egzaminów na certyfikaty IREB po polsku. W tej chwili na świecie certyfikaty IREB oferowane są w sześciu językach, w wielu krajach Europy, Ameryki oraz Azji. Certyfikat podstawowy – CPRE Foundation Level – ma dziś na świecie 10.000 osób. IREB oferuje także certyfikaty zaawansowane (Advanced Level). Listę firm prowadzących szkolenia przygotowujące do egzaminów na certyfikaty IREB można znaleźć na www.ireb.org (zakładka „Training”), zaś firmy szkoleniowe w Polsce na www.ireb.org.pl/szkolenia. QAI – Quality Assurance Institute QAI Software Certifications (www.softwarecertifications.org) oferuje dwa ciekawe certyfikaty: CABA – Certified Associate Business Analyst CSBA – Certified Software Business Analyst IIBA – International Institute of Business Analysis IIBA (www.iiba.org) także ma dwa poziomy certyfikacji: CCBA – Certification of Competency in Business Analysis CBAP – Certified Business Analysis Professional Opisy tych certyfikacji ma na swojej stronie po polsku IIBA Warsaw Chapter (www.warsaw.iiba.org) – polska organizacja IIBA. Zapraszamy do tańca! Konferencja poświęcona inżynierii wymagań i analizie biznesowej Dobre Wymagania (breq2013.wymagania.org.pl) odbędzie się 18-19 kwietnia 2013 w Warszawie. Jak to było z testowaniem? W roku 2000 mało kto w Polsce słyszał o testowaniu – to znaczy, testowano oczywiście, ale testowanie nie było postrzegane jako odrębna specjalność, nie istniały szkolenia dla testerów. Tematyka testowania pojawiła się po raz pierwszy na konferencji KKIO w 2000 roku, potem na konferencjach zorganizowanych przez autora artykułu we współpracy z IIR w 2002 i 2003 roku. Ruszyły pierwsze w Polsce szkolenia na tzw. certyfikaty ISEB (dziś ISTQB), w 2003 roku założono stowarzyszenie testerów SJSI. Dziś testowanie w Polsce staje się big business. Tak samo będzie – z mniej więcej 10-letnim opóźnieniem – z inżynierią wymagań! Za 10 lat, w 2022 roku, trudno będzie sobie wyobrazić, że kiedyś „inżynier wymagań” był niemal nieznanym zawodem. Dlatego serdecznie zapraszamy wszystkich zainteresowanych na zebranie Strona 8 z 9 Bogdan Bereza „Wymagania: IT w pigulce” założycielskie SIW – Stowarzyszenia Inżynierii Wymagań (wymagania.org.pl), które odbędzie się we czwartek, 24 stycznia 2013 roku w Warszawie (enter.wymagania.org.pl). Bogdan Bereza, [email protected] Strona 9 z 9