Raport Inżynierii Wymagań 2014

WWW.COMPUTERWORLD.PL
INŻYNIERIA
WYMAGAŃ
• Bez eksperymentowania str. 2 • Analiza biznesowa ulepsza procesy IT str. 4 • Przepis na sukces w projektach IT str. 6
• Projekty z automatu str. 8 • Procedury chronią przed skutkami błędów str. 10 • Projekt bez zbędnych opóźnień str. 12
• Dramatyczny wzrost wydajności dzięki IT str. 14
Z A R ZDOWIEDZ
Ą D Z A N I E SIĘ
I N ŻWIĘCEJ
Y N I E R I A WEŹ
W Y MUDZIAŁ
AG A Ń W KONFERENCJI!
Bez eksperymentowania
Poświęcamy dużo czasu na wdrażanie nowych
metod, narzędzi i sposobów zarządzania, ale
robimy to na oślep. Należy sięgnąć po metody
szacowania opłacalności i skuteczności działań.
bzdury zawzięcie ujadają na prestiżowych konferencjach, można się tego obawiać. Nie twierdzę,
że mając dobrze udowodnioną wiedzę o tym, co
działa, co jest skuteczne, przekonamy innych.
Nie, ludzkie zapotrzebowanie na wiarę w modne
bzdury jest niewyczerpane. Ale to możemy
dobrze wykorzystać w praktyce projektowej,
w organizacjach, w działalności biznesowej.
Czy łysi są mądrzejsi od kudłatych?
BOGDAN BEREZA
P
rzed wojenną wyprawą, nad ogniskiem,
w tipi wodza zebrało się ich trzech.
Wódz zamierzał przedsięwziąć wyprawę przeciwko sąsiedniemu plemieniu,
ale tak ważnej decyzji nie chciał, nie
mógł podjąć sam. Może wyprawa się
nie powiedzie? Może wystąpią nieoczekiwane
przeszkody? Jakie mogą być ich skutki? Z tymi
pytaniami zwrócił się do młodszego z szamanów. Starszy szaman milczał, jego oczy patrzyły
w przyszłość. Myślał nie tylko o tej wyprawie,
ale i o następnych: co zrobić, aby decyzje o ich
podjęciu on i jego następcy podejmowali coraz
lepiej, coraz bardziej bezbłędnie?
Takiej narady Indian sprzed dwustu–trzystu
lat raczej nie zobaczymy dzisiaj. Wódz – kierownik projektu – rzadko rozmawia ze specjalistą
od zarządzania ryzykiem (młodszy szaman),
a prawie nigdy – ze specjalistą od udoskonalania
procesów i procedur (starszy szaman). A szkoda,
bo mogliby się sobie nawzajem przydać.
Skąd wiadomo, czy to prawda?
W nauce o zarządzaniu, o zapewnieniu jakości, a nawet w pewnych obszarach inżynierii
oprogramowania nietrudno spotkać tezy i teorie
wątpliwe – modne bzdury. Nie zawsze to, co
modne, jest bzdurą, a to, co niemodne – mądrością, ale brakuje metod pozwalających szybko
i skutecznie odróżnić jedno od drugiego.
26
2
COMPUTERWORLD 5 marca 2013
O tym, że metoda staje się modna, decyduje
wiele czynników, nie mających nic wspólnego
z jej rzeczywistą wartością. Pomińmy mechanizmy, których opis należy do psychologii,
dynamiki grupowej, socjologii, antropologii czy
mechanizmów międzyludzkiej komunikacji. Jeśli
chcemy zmniejszyć ich wpływ, trzeba dać inne,
lepsze metody w zamian. I z tym mamy kłopot.
Kiedyś, w czasie młodzieńczego wakacyjnego
wyjazdu, moja namiotowa partnerka wdała się
przy kolacji w spór z moim kolegą na temat wyższości języków strukturalnych nad COBOL-em.
Po dwóch godzinach strasznej pyskówki wspólny wyjazd stanął pod znakiem zapytania. Minęło
Jak można odpowiedzieć na to pytanie? Kusi
tzw. „logiczna” (czytaj: nielogiczna) dyskusja,
odwoływanie się do anegdotycznych przykładów i fałszywych analogii. Zainteresowanym
polecam lekturę „Krótkiego kursu samoobrony
intelektualnej” Normanda Baillargeona. Mając
choć odrobinę intelektualnej uczciwości, należy
przeprowadzić badanie spełniające wymogi
naukowe. Wybiera się połowę osób łysych,
połowę kudłatych, mierzy im iloraz inteligencji
oraz poziom wiedzy i teza o wielkiej przewadze
łysych udowodniona. Jakim cudem? Drobne
fałszerstwo: łysych wybieraliśmy spomiędzy
pracowników wyższej uczelni, a kudłatych spośród bezrobotnych w PGR na odludziu. Nie, nie,
nie: żeby wynik badania był miarodajny, grupy
muszą być choć trochę równoważne.
Ta zasada nigdy nie jest przestrzegana, kiedy
porównuje się ze sobą różne metody, języki
programowania, technologie, narzędzia, sposoby modelowania, podejścia do zarządzania,
struktury organizacyjne, procedury. Czy razi
kogoś uzasadnienie typu: „ta metoda jest lepsza,
przecież projekt zakończył się sukcesem”. Albo
inne: „musimy stosować tę technologię, używają
jej wszyscy”. Zamiast gołosłownych twierdzeń
należy zrobić… co? Porównać ze sobą dwa,
a najlepiej więcej projektów równoważnych pod
każdym względem, różniących się tylko metodą,
której skuteczność chce się zbadać. Tylko to jest
nierealne z powodów finansowych. Żeby sobie
na to pozwolić, trzeba znaleźć ekscentrycznego
miliardera-przedsiębiorcę, tak jak bohater książki
Toma DeMarco „Zdążyć przed terminem”.
Każdy język programowania,
a nawet każdy arkusz kalkulacyjny zapewni wsparcie narzęNadzieja jest w matematyce
dziowe metody Monte Carlo.
Wyobraź sobie, Czytelniku, że Twój dział personiemal 30 lat i oto kilka tygodni temu byłem
świadkiem równie zażartej dyskusji o wyższości
Mac nad Windows i odwrotnie. Gdzie indziej
jeszcze toczą się zajadłe i bezproduktywne
dyskusje o wyższości agile nad metodami tradycyjnymi, PRINCE-2 nad PMI, IREB nad REQB,
UML nad XML. Czyżby trzeba było uznać, że
prawda jest subiektywna i nie da się niczego
rozstrzygnąć w żadnej kwestii, w tym w sprawie
skuteczności metod produkcji oprogramowania?
Nie jest tak źle, choć w chwilach pesymizmu,
kiedy wygadani zwolennicy jakiejś modnej
nalny zawiódł haniebnie i zatrudnił człowieka,
który zamiast dostosować się do kultury Twojej
organizacji i zaangażować z całego serca w walkę
o wpływy, robienie dobrego wrażenia i podgryzanie rywali, jest autentycznie zainteresowany
usprawnieniem procesów, aby osiągnąć biznesowe korzyści! Mówi, że inwestycja w lepsze praktyki inżynierii wymagań zwróci się w krótkim
czasie, ba – przyniesie znaczne zyski. Twój CIO
stuka się w głowę, Twój CFO mówi, że nie da
się uzyskać potrzebnych danych finansowych,
a Twój CMO trzyma się za serce i jęczy coś na
SPECJALNE
zarządzanIe
I n Ż Y n I e rUSŁUGI
I a WYDANIE
W Y M aG a Ń
temat CRM, CEM, BPML. Tego nowego to trzeba
jak najszybciej zwolnić dyscyplinarnie… niestety, jeden z ważnych członków zarządu, znajdujący się na liście 100 najbogatszych Polaków,
dał się zbajerować i mówi, żeby dać młodemu
spróbować. Młody wziął się do pracy. Najpierw
zbudował sieć bayesowską pokazującą, od czego
i w jakim stopniu zależy stopa zysku firmy. Taka
sieć mogła wyglądać następująco:
Na rysunku 1 (tak, to jest graf – diagram sieci
bayesowskiej) interesujący wynik – STOPA ZYSKU – przedstawiony jest jako zależny (strzałki
pokazują tę zależność) od szeregu czynników.
Czynniki przedstawione na niebiesko – marketing, logistyka itd. – te nas nie interesują. Poza
tym stopa zysku zależy od KOSZTÓW UZYSKANIA oraz KOSZTÓW UTRZYMANIA produktu
(np. produktu IT). Te zaś zależą od CZYNNIKÓW
JAKOŚCI – to zielone pola na rysunku, wśród
nich zarządzanie, inżynieria wymagań i inne.
Strzałki-zależności mają swój atrybut, swego
rodzaju siłę zależności mówiącą, jak mocno
dany czynnik wpływa na końcowy efekt (zob.
rys. 2). Suma wszystkich zależności powinna
wynosić 100%, w przeciwnym razie oznacza to,
że jakiś ważny czynnik został pominięty. Skąd
możemy wiedzieć, jaka jest siła tych zależności?
Jak bardzo jakość inżynierii wymagań wpływa
na koszty utrzymania i wytworzenia? Czy to 5%,
czy raczej 40%? To można próbować oszacować,
na pewnym poziomie pewności, na podstawie:
1. opinii eksperckich, 2. danych historycznych
z kolejnych projektów oraz – najlepsze oszacowanie – na podstawie 3. danych z całej branży.
Przyjmując, że dane są prawdziwe, możemy
dokonywać na papierze eksperymentów: jeśli
usprawnimy inżynierię wymagań o 50%, to o ile
zmaleją koszty produktu, o ile wzrośnie zysk?
Ponieważ nie wiemy, na ile proponowane przez
młodego pracownika zmiany zaowocują mniejszą liczbą błędów w wymaganiach ani jakie będą
koszty ich wdrożenia, ani jak silna jest zależność
między jakością inżynierii wymagań a kosztami
produktu, ani nawet tego, na ile koszty produktu
wpływają na zyski – to co mamy robić?
rysunek 2: określenie siły oddziaływania poszczególnych czynników na końcowy efekt stopy zysku
Sądząc z poziomu płac w Polsce, górny kwartyl wynagrodzenia dla kierowników marketingu
to 11 tys. zł, a dla kierowników działu IT 12 tys.
Odpowiednio, 25% dyrektorów działu IT zarabia
ponad 23 tys. zł – tyle, ile 25% dyrektorów działu
marketingu. Czyli rynek szacuje znaczenie tych
działów jako podobne. Znaczny poziom niepewności pozostaje i wyliczenia algorytmiczne na
podstawie niepewnych danych nie mają sensu.
Z pomocą przychodzi metoda Monte Carlo.
Jedna definicji brzmi: „metoda Monte Carlo jest
stosowana do modelowania matematycznego
procesów zbyt złożonych, aby można było przewidzieć ich wyniki za pomocą podejścia analitycznego. Istotną rolę odgrywa w niej losowanie
wielkości charakteryzujących proces”.
Procesy zbyt złożone – to dotyczy procesów
wytwarzania oprogramowania. Nie da się wziąć
pod uwagę wszystkich czynników wywierających wpływ na ich koszty i na ich skuteczność.
Można zanalizować rozkład wyników dla
danych generowanych losowo. Ręcznie byłoby
to beznadziejne zadanie, ale od czego mamy
komputery. Wrzuciwszy diagram sieci Bayesa
do odpowiedniego narzędzia, możemy na nim
rysunek 1: diagram sieci bayesowskiej pokazuje, od czego i w jakim stopniu zależy stopa zysku firmy
wykonywać eksperymenty za pomocą wartości
losowo wygenerowanych wokół oczekiwanej
średniej. Wsparcie narzędziowe metody Monte
Carlo da nam każdy język programowania, a nawet każdy arkusz kalkulacyjny.
I co dalej?
Co dalej i kogo w czasach kryzysu stać na takie
eksperymenty? Przewidując to pytanie, z wielką
obawą powołuję się na opracowanie z 2009 r.,
opublikowane przez SEI (Software Engineering
Institute), dotyczące zastosowania tej metody
w dziale badawczo-rozwojowym firmy Ericsson
w Holandii: http://repository.cmu.edu/cgi/viewcontent.cgi?article=1273&context=sei. To nie
jest dobra rekomendacja dla prezesa kilkudziesięcioosobowej firmy informatycznej…
Przypomnijmy sobie anegdotę o drwalu, co
marnie rąbał drzewa, bo tak był zajęty, że nie
miał czasu naostrzyć siekiery, czy o budowlańcu, co biegał z pustymi taczkami... Na co dzień
poświęcamy dużo czasu na projektowanie i realizację zmian procedur i procesów, na wdrażanie
nowych metod i narzędzi, nowych sposobów
zarządzania, ale robimy to na oślep, kierując się
intuicją i nie prowadząc późniejszych oszacowań
opłacalności ani skuteczności tych eksperymentów. W ten sposób mnóstwo pieniędzy się marnuje, wręcz wyrzuca w błoto – choć część ich
można przeznaczyć na zastosowanie opisanych
w tym artykule metod, które są najzwyczajniej
praktyczne, konkretne i opłacalne. A kryzys to
najlepszy czas na takie sprawy! (http://gazeta.
testerzy.org.pl/nr/2013-02-17/kryzys.html).
Poza tym można spróbować przełamać
stereotypy i uprzedzenia i poszukać współpracy
z uczelniami. Przykłady, że taka współpraca jest
obustronnie korzystna i pozwala nawet niewielkim firmom niskim kosztem osiągnąć udoskonalenia, będą omawiane na spotkaniu „Praktyczne
doświadczenia współpracy między IT a wyższymi uczelniami w szwedzkim i polskim przemyśle IT”, 18 kwietnia br., podczas konferencji
„Dobre wymagania” (http://breq2013.wymagania.
org.pl/program/panel.html). Warto się przyjrzeć
doświadczeniom z tej dziedziny. 
computerworld 5 marca 2013
27
3
z a r zDOWIEDZ
ą d z a n i e SIĘ
i n ŻWIĘCEJ
Y n i e r i a WEŹ
W Y MUDZIAŁ
aG a Ń W KONFERENCJI!
analiza biznesowa
ulepsza procesy iT
Usprawnianie pozyskiwania, konsolidacji,
weryfikacji, zarządzania i realizacji wymagań
IT jest równie ważne jak ulepszanie zarządzania
finansami, marketingiem, sprzedażą i dostawami.
na ratujących sumienie menedżerów gotowcach
(następny akapit). Dopóki to się nie zmieni, dopóki analiza biznesowa oraz inżynieria wymagań
nie znajdą się na szczycie listy w przewodniku po
rynku szkoleń, dopóty udoskonalanie procesów
będzie w dużym stopniu grą pozorów i fikcją.
Moda na gotowce: BePL,
UML, iTiL, PrinCe 2
Nie mam nic przeciwko tym językom (BEPL
i UML) ani standardom (ITIL, PRINCE 2). To
dobre narzędzia pracy. Niestety, nie zastąpią myślenia – a takie próby są podejmowane. Tak samo
jak niestosowne jest sięganie po młotek, zanim
się wie, co do czego trzeba przybić i czy w ogóle
przybijać, tak mija się z celem modelowanie
w języku UML wymagań, które są niepoprawnie
pozyskiwane, czy można się ich tylko domyślać.
Moda na gotowce utrudnia udoskonalanie
procesów. Skoro już zainwestowało się spore
sumy we wdrożenie UML, to niełatwo znaleźć
czas na zastanowienie się, czy ten sposób modelowania jest zawsze stosowny. Jeśli firma weszła
w świat PRINCE 2, trudno z niego zrezygnować
w projektach, w których nie przynosi korzyści.
dopóki analiza biznesowa
oraz inżynieria wymagań nie
znajdą się na szczycie listy
w przewodniku po rynku
szkoleń, dopóty udoskonalanie procesów będzie w dużym
stopniu grą pozorów i fikcją.
BOGdan Bereza
W
„Przewodniku po rynku szkoleń
IT” (Computerworld, wrzesień
2012) możemy przeczytać, jakie
wymagania pojawiają się najczęściej w ofertach pracy. Widzimy
tam nazwy: systemy klasy ERP
firmy SAP, systemy klasy ERP firmy Oracle,
systemy wspierające zarządzanie relacjami
z klientami CRM, projektowanie aplikacji internetowych, wirtualizacja, oprogramowanie klasy
ERP Comarch, Java, .Net, HTML, C++, PHP,
Delphi, Oracle, MySQL, Microsoft SQL Server,
IBM DB2, Linux, Oracle, Unix, Microsoft, HP,
Cisco, IBM, Vmware, Novell… Brakuje określeń:
inżynieria oprogramowania, inżynieria wymagań, zapewnienie jakości, zarządzanie projektami
informatycznymi, testowanie, projektowanie
systemów, udoskonalanie procesów.
Jak usprawniać procesy, i tworzyć choćby
pojedyncze, ale dobre rozwiązania IT, skoro nie
14
4
computerworld 5 lutego 2013
zwraca się uwagi, jaki jest cel i sens biznesowy
rozwiązania, ani jaka jest skuteczność i opłacalność metod IT, lecz koncentruje się na detalicznej, przemijającej znajomości technologii?
Struktura rynku szkoleń IT jest odwzorowaniem tego stanu rzeczy. Teraz dobrze sprzedają
się kursy dla użytkowników modnego narzędzia
Cucumber (jedno z narzędzi do wykonywania
tzw. testowania za pomocą słów-kluczy), kursy
języka programowania Ruby (jeden z dziesiątków obiektowych języków programowania)
oraz kursy Selenium – jednego z wielu narzędzi
do testowania aplikacji webowych. Spróbujcie
jednak sprzedać wiedzę pozwalającą zrozumieć
te zagadnienia ponad technologicznymi szczegółami. Nie uda się – zbyt mały jest popyt. Mało kto
chce rozumieć, wszyscy chcą tylko umieć, szukają gotowych przepisów na jedną sytuację.
Podsumowując: zafascynowani selenem, ogórkiem oraz rubinem, nie znając inżynierii oprogramowania, realizujemy projekty IT ad hoc, kierując się zawodnym instynktem lub opierając się
Słowem, aby móc naprawdę oceniać jakość
procesów i usprawniać je, punktem wyjścia
muszą być rzeczywiste cele biznesowe i realne
wymagania, a nie narzędzia, które mogą (choć
nie muszą) usprawnić realizację tych wymagań.
Dotyczy to zarówno narzędzi wysokich, np.
BEPL, jak i niskich, typu ogórek, selen czy rubin.
Od samuraja do deminga i Jurana
Po co bawić się w ulepszanie procesów? W porównaniu z ogórkiem, rubinem i selenem brzmi
to mało konkretnie. Budzi podejrzenia, że chodzi
o zaspokojenie niepotrzebnych ambicji i potrzeb
leśnych dziadków, czy o sprostanie wymogom
modnej poprawności politycznej, a nie o budowanie aplikacji, o biznesowy sukces i zysk.
Jest odwrotnie. To fiksacje technologiczno-narzędziowe z jednej strony, a z drugiej strony
nawiedzony, niejasny język biznesu i marketingu
służą głównie zaspokajaniu potrzeb rozmaitych
„młodych wilczków” i „leśni dziadkowie” niekoniecznie odnoszą się do daty urodzenia – raczej
do sposobu pracy i systemu wartości), a mało
biznesowym, finansowym korzyściom. Zapoznajmy się z klasycznym przykładem.
Lata 60. XX wieku. Raczkujący, japoński
przemysł motoryzacyjny rodzi śmiech i politowanie, podczas gdy amerykańskie krążowniki
SPECJALNE
zarządzanie
i n Ż Y n i e rUSŁUGI
i a WYDANIE
W Y M aG a Ń
szos zachwycają i budzą podziw. W tym czasie
dwaj leśni dziadkowie, Deming i Juran (Juran żył
104 lata, jak na leśnego dziadka przystało) głoszą
swoje teorie jakości. Pewne siebie amerykańskie
firmy motoryzacyjne nie chcą ich słuchać. Bo po
co, skoro dysponują najnowszymi motoryzacyjnymi odpowiednikami ogórka, selenu i rubinu?
Procedury – to dobre dla mięczaków! Deming
i Juran pojechali do Japonii, gdzie gospodarze
uważnie ich słuchali… i posłuchali. W japońskich fabrykach zaczęto odchodzić od starego
paradygmatu produkcji taśmowej, gdzie kontrola
jakości skupiała się na końcu taśmy, a wykrywane braki albo odrzucano, albo naprawiano… wielokrotnie, gdyż wciąż powracały. Nowa kontrola
jakości pojawiła się na każdym etapie produkcji,
zaś wykrywane braki wykorzystywano, by wykryć ich przyczynę i trwale ją usunąć. Mówiąc
językiem IT, zamiast obszernych i kosztownych
testów systemowych i wdrożeniowych, zaczęto
stosować znacznie skuteczniejsze testy wymagań, testy statyczne kodu źródłowego oraz testy
jednostkowe, a wykryte defekty wykorzystywano
do tego, aby usuwać ich technologiczne lub procesowe przyczyny. Kiedy IT dojrzeje do tego?
Co zrobili Japończycy z amerykańskim przemysłem motoryzacyjnym, dobrze wiemy: „1980
– Japan surpassed the United States and became
first in auto manufacturing” (http://en.wikipedia.
org/wiki/Automotive_industry_in_Japan). To
samo zrobią z innymi za najwyżej 10 lat firmy,
których działy IT skoncentrują się na ulepszaniu procesów, zamiast na rubinach, ogórkach,
selenie, oraz na „wirtualizacji, oprogramowaniu
klasy ERP Comarch, Java, .Net, HTML, C++,
PHP, Delphi, Oracle, MySQL, Microsoft SQL
Server, IBM DB2, Linux, Oracle, Unix itd.
Żeby ulepszać, trzeba mierzyć
Dobrze, ulepszajmy, skoro tyle na tym wygrali
Japończycy. Agile! – krzyczą jedni. Programowanie ekstremalne! – krzyczą drudzy. TDD! SPICE!
COBIT! CMMI! PMBOK!
Jeśli wygrało Agile, nagle wszystko staje na
głowie i zamiast robić oprogramowanie, wszyscy
chodzą na treningi współpracy w grupie, kierownicy stają się mistrzami młyna, wymagania
– zaległościami, a kolejne etapy projektu – przebiegami. Tylko co to zmienia? Nawet przyjąwszy,
że agile jest cudowną bronią (Wunderwaffe, silver
bullet), to co z procedurami czynności innych niż
samo pisanie oprogramowania – tymi, z których
powodu CMM stało się CMMI?
Fiksacje technologiczno-narzędziowe z jednej strony, a z drugiej – nawiedzony,
niejasny język biznesu
i marketingu, służą głównie
zaspokajaniu potrzeb rozmaitych „młodych wilczków”.
Więc może CMMI, może COBIT? Świat się
biurokratyzuje, jest smutniej, a efekt biznesowy
mizerny. Nawet po osiągnięciu kosztem znacznych nakładów magicznego poziomu CMMI-5.
Nie wystarczy wdrożyć procedury, których domaga się zewnętrzny standard. Trzeba mierzyć,
ile ich wdrożenie i przestrzeganie kosztuje, jakie
przynosi efekty, jeśli chodzi o jakość i o wydajność, i jaki jest ich ostateczny skutek biznesowy,
mierzony obrotami, zyskiem, udziałem w rynku.
Bez tego cała robota na nic. Najwięcej na świecie
firm IT mających poziom dojrzałości procesów
CMMI-5 jest w Indiach, ale jakoś indyjski przemysł informatyczny dotąd świata nie podbił.
Trzeba mierzyć prawdziwe koszty zbudowania systemu IT i jego poprawek, modyfikacji, utrzymania. Próbować oszacować efekty
biznesowe wdrożenia systemu i porównać je
z oszacowaniem biznesowych skutków zaniechania wdrożenia. Dział finansowy każdej, dobrze
prowadzonej firmy ma dane i narzędzia, aby te
porównania zrobić. Musi tylko otrzymać wytyczne od kierownictwa firmy, a dane – z działu IT.
Pomiary wydajności i kosztów w IT nie cieszą
się dobrą sławą. Począwszy od doświadczenia
z „bystrymi inaczej” firmami doradczymi, usiłującymi mierzyć wydajność IT liczbą przyciśnięć przez pracowników klawiszy klawiatury
na godzinę, a skończywszy na obawach przed
rozbudowaną papierologią: pół dnia się pracuje,
a drugie pół wpisuje w formularze, co w tym
czasie się robiło. Nie! Tak rozumiane „pomiary
wydajności” nie działają. Trzeba to robić inaczej
– automatycznie. Wtedy dopiero, bez żmudnych,
nudnych, dodatkowych nakładów, będzie można
bez trudu dowiedzieć się, co ile czasu zajmuje
w projektach IT i ocenić efekty ulepszeń.
Jak można to robić? Polecam artykuły:
• „Między biurokracją a chaosem” (http://
www.computerworld.pl/artykuly/321693_2/
Miedzy.biurokracja.a.chaosem.html)
• „Dramatyczny wzrost wydajności dzięki
IT” (http://www.computerworld.pl/artykuly/361381/Dramatyczny.wzrost.wydajnosci.
dzieki.IT.html)
• „Jakość warunkiem wydajności” (http://victo.eu/PL/Wiedza/jakosc_warunkiem.pdf).
Sukces w biznesie
a udoskonalanie procesów
Po co udoskonalać procesy IT? Po to, żeby docelowo zwiększyć lub co najmniej utrzymać zysk
firmy. Docelowo, czyli:
• albo zwiększywszy stopę zysku przy tych
samych co wcześniej obrotach;
• albo zwiększywszy obroty, np. wprowadziwszy nowe produkty / usługi;
• albo utrzymawszy / zwiększywszy udział
w już istniejącym segmencie rynku.
Dla firm IT, które tworzą oprogramowanie na
zamówienie, i działów IT w firmach zajmujących się innym biznesem kluczem do sukcesu
są wymagania: żeby miały biznesowy sens, żeby
były dobrze zdefiniowane i opisane, i wreszcie
sprawnie z realizowane. Usprawnianie procesu
pozyskiwania, konsolidacji, weryfikacji, zarządzania i realizacji wymagań, czyli całego procesu
IT, jest dla firmy tak ważne jak ulepszanie
procesów zarządzania finansami, marketingiem,
sprzedażą, procesem dostaw.
Proces produkcji oprogramowania nie jest –
w przeciwieństwie do procesów produkcyjnych
w tradycyjnym przemyśle – wytwarzaniem
wielu kopii tego samego produktu. Każdy projekt
IT jest inny, realizuje odmienne wymagania.
Dlatego aby stwierdzić, na ile skuteczne są próby
udoskonalenia procesu IT, trzeba znaleźć miary
pozwalające porównywać ze sobą projekty i produkty IT. Taką miarą są wymagania, ich trudność
i złożoność. W tym miejscu łączą się trzy obszary, tradycyjnie taktowane jako odrębne:
• inżynieria wymagań i wykonywane na
podstawie wymagań oszacowania pracochłonności;
• zarządzanie projektami IT;
• metody udoskonalania i oceny jakości
procesu IT.
computerworld 5 lutego 2013
15
5
i n ŻWIĘCEJ
Y n i e r i a WEŹ
W Y MUDZIAŁ
aG a Ń W KONFERENCJI!
z a r zDOWIEDZ
ą d z a n i e SIĘ
Przepis na sukces
w projektach iT
Inżynieria wymagań porządkuje etapy pomiędzy
potrzebą biznesową a wdrożeniem. Wprowadza
procesy i procedury, bez których projekt IT nie
może zakończyć się powodzeniem.
Siedem żelaznych reguł
udanego projektu

Wiedzieć, co jest celem projektu.
Narzędzia: współpraca z klientem, analiza biznesowa, inżynieria wymagań.

W trakcie projektu umieć skutecznie
modyfikować jego cel.
Narzędzia: prototypowanie, zarządzanie wymaganiami, metodyki zwinne.

Trafnie określić zadania do wykonania
i oszacować pracochłonność projektu.
Narzędzia: analiza wymagań.

Skutecznie nadzorować przebieg projektu
i stan produktu.
Narzędzia: śledzenie realizacji wymagań, testowanie wymagań od samego początku.

Automatyzować czynności administracyjne.
Narzędzia: wersjonowanie, zarządzanie zmianami,
testowanie podstawowe, śledzenie wymagań.

Strategia: jakość osiąga się nie kosztem wydajności, przeciwnie: dążenie do jakości (unikanie
błędów) zwiększa wydajność.

Nacisk nie na znajdowanie błędów, lecz na zapobieganie błędom - w tym przez poprawnie określone
wymagania.
BoGdan Bereza
I
nżynieria wymagań to określenie, które
odnosi się nie tylko do projektów IT. Choć
samo pojęcie inżynierii wymagań jest stosunkowo nowe, to kłopoty, jakie powoduje
lekkomyślne traktowanie wymagań, czyli
niestosowanie zasad inżynierii wymagań,
znane są od wieków.
Toną statki i projekty
10 sierpnia 1628 r. przewrócił się i zatonął,
kilkanaście minut po odbiciu od nadbrzeża,
nowo zbudowany okręt flagowy marynarki
szwedzkiej „Wasa”. Przyczyny? Okręt z powodu
ambicji króla był potężniejszy niż inne ówczesne jednostki – dwupokładowy. Takie było
życzenie króla, któremu nikt nie ośmielił się
przeciwstawić. Tu od razu nasuwa się całkiem
współczesna wątpliwość, czy na pewno klient
ma zawsze rację? Dwupokładowy okręt miał
12
6
computerworld 15 stycznia 2013
znacznie wyżej środek ciężkości i okazał się
przez to 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 m.in. zajmuje
się takimi ich atrybutami, jak wykonalność
(feasibility), oraz projektowanie: nie umiano
wówczas precyzyjnie wyliczyć stabilności statku na podstawie informacji o jego wymiarach
i rozkładzie ciężaru. Zastosowano metodę, którą
można nazwać megaagile: po prostu pracowici
cieśle-programiści dobudowali jeszcze jeden pokład, zgodnie z życzeniem zleceniodawcy-króla!
Tak popełniono kardynalny błąd już
w początkowej fazie projektu. Wynika on
z powszechnego i wtedy, blisko 400 lat temu,
i dzisiaj podejścia: „po co marnować czas na
jakiś SRS, bierzmy się do roboty”.
Kiedy projekt popada w kłopoty – albo
wręcz, jak „Wasa”, kończy się spektakularną
klęską – zwykle przyczyn szuka się wszędzie, tylko nie w braku inżynierii wymagań.
Cichutko, bo wtedy jeszcze nie zniesiono kary
śmierci, obwiniano króla-zleceniodawcę i jego
idiotyczne pomysły. Ktoś powie: z takich
pozornie idiotycznych pomysłów biorą się
wielkie sukcesy biznesowe, zgodnie z zasadami strategii błękitnego oceanu. Owszem, tylko
trzeba umieć sobie z nimi radzić. Na przykład
stosując inżynierię wymagań.
Obwiniano też głównego konstruktora,
Henrika Hybertssona. Gdyby statek zatonął pół roku później, Hybertsson zbierałby
pochwały. Ocena kierowników projektów
zawsze jest przeraźliwie krótkowzroczna,
oparta na pozornym sukcesie albo na równie pozornej, byle spektakularnej, klęsce.
Obwiniano też procedury testowania. Ale
testy przeprowadzono. Stabilność kadłuba
sprawdzano w ten sposób, że gromada kilkuset robotników stoczni biegała po pokładzie
z jednej strony na drugą, próbując rozkołysać
kadłub. W przypadku „Wasy” testy przerwano, gdyż kadłub zaczął się kołysać zbyt
niebezpiecznie, grożąc wywrotką. Króla zaś
nie zawiadomiono, bo… obawiano się jego
gniewu. No i oskarżano Polaków, bo to z nami
głównie wojował król Gustaw II Adolf. Polski
sabotaż był więc wyjaśnieniem.
Król, nakazując śledztwo, wskazał jako
przyczynę awarii „głupotę i niedbalstwo”.
Bingo, proszę króla! Budując wielkie, skomplikowane rzeczy, ludzie z definicji są głupi, bo
SPECJALNE
i n Ż Y n i e rUSŁUGI
i a WYDANIE
W Y M aG a Ń
zarządzanie
rozum niewsparty narzędziami nie radzi sobie
z nimi, a niedbalstwo jest 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 przodkowie nie uciekali, zajęci regułami i rytuałami.
Wprowadzamy procesy i procedury, które tę
staranność gwarantują. Albo ich nie wprowadzamy bądź nie przestrzegamy, wtedy tonie
„Wasa” albo projekt IT kończy się klęską. Można powiedzieć, że pod pewnymi względami
inżynieria wymagań jest bardzo stara.
Programistyczny pięściak
Pięściak albo inaczej tłuk pięściowy wykonywano z twardego krzemienia. To oznacza,
że nasz jaskiniowy prapraprzodek w swoim
interesie musiał 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 40. i 50. ubiegłego wieku nauczyliśmy się wytwarzać pięściaki z miękkiego
krzemu zamiast krzemienia. Sam krzem,
pierwiastek, nie jest specjalnie użyteczny, ale
w układach scalonych i budowanych z nich
komputerach – jak najbardziej. Komputery
umożliwiają wykonywanie oprogramowania,
które można modyfikować i przerabiać o wiele łatwiej i taniej niż krzemienne pięściaki
czy budowane z drewna żaglowce. Oferowana przez oprogramowanie łatwość robienia
nowych rzeczy i ich zmieniania jest podłożem
olbrzymiego skoku cywilizacyjnego, jaki zanotowaliśmy właśnie od lat 50. zeszłego wieku.
Ta łatwość okazywała się niebezpieczna.
Względnie nieskomplikowane algorytmy
programów w latach 40. i 50., tworzone od
początku do końca przez ludzi wybitnych,
nawet laureatów nagrody Nobla, 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 matematycznych algorytmów.
Dlatego od podejścia charakteryzującego
lata 50. i 60. – od pojmowania tworzenia
programów jako rzemiosła artystycznego, IT
przeszło do nowej fazy – inżynierii oprogramowania. Inżynieria wymagań jest jednym ze
składników inżynierii oprogramowania.
W inżynierii wymagań widać odmienność
między światem akademickim a realiami
przemysłu IT. W świecie akademickim określenie „inżynieria wymagań” jest powszechnie znane. Najpoważniejsze czasopismo w tej
dziedzinie – „Requirements Engineering
Journal” – wydawane jest od 1996 r., a więc
już od 17 lat. Jeszcze starsza jest konferencja
„IEEE International Requirements Engineering
Conference”, która odbędzie się w tym roku
już po raz dwudziesty pierwszy. Historia i materiały ze wszystkich wcześniejszych konferencji, począwszy od roku 1993, znajdują się
na portalu requirements-engineering.org.
Między analizą biznesową
a oprogramowaniem
Ciekawe porównanie – największa w Europie
konferencja na temat testowania oprogramowania, EuroSTAR, też po raz pierwszy odbyła
się w 1993 r. w Londynie. W tym czasie testowanie stało się i modą, i biznesem.
A przecież kluczowe znaczenie inżynierii wymagań dla biznesu i dla IT wydaje
się nie budzić najmniejszych wątpliwości.
Przeszkoliwszy wiele tysięcy osób w zakresie
testowania, w tym na niezmiernie popularny
certyfikat ISTQB, autor 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ń. Zatem wiedza
na ten temat istnieje w przemyśle IT, ale nie
przekłada się na żadne działania. Czemu?
Wyjaśnienie ma charakter bardziej antropologiczny i socjologiczny niż informatyczny.
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;
Koszty
Korzyść
usunięcia błędu
w różnych fazach
projektu
analiza
budowa
wdrożenie utrzymanie
z inwestycji w jakość
w różnych fazach
projektu
analiza
budowa
wdrożenie utrzymanie
Początki inżynierii wymagań
W drugiej połowie lat 60. coraz trudniej było znaleźć
wystarczającą liczbę wysoko kwalifikowanych programistów, a projekty informatyczne przekraczały i budżet,
i harmonogram. Zaczęto mówić o kryzysie oprogramowania i poszukiwać środków zaradczych – początkowo
głównie w sferach języków programowania oraz jego
architektury. Wyrazem tych tendencji była Konferencja
Inżynierii Oprogramowania NATO, która odbyła się w 1968
r. To wtedy, wedle źródeł, po raz pierwszy oficjalnie użyto
określenia „inżynieria oprogramowania”.
W druku ten termin po raz pierwszy pojawił się prawdopodobnie w 1979 r., w tzw. „Raporcie TRW”. Nie było jednak
szerzej znane ani stosowane aż do lat 90., kiedy ukazało
się klasyczne opracowanie IEEE CS pt. „System and
Software Requirements Engineering”.
słusznie zresztą, bo trudno oczekiwać, że
analizą biznesową będą się zajmować osoby
z niewielkim doświadczeniem, bez całościowej wizji działania firmy. Znów posłużę się
ryzykowną nazwą, dolne rejony inżynierii
wymagań zadomowiły się w świecie 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ą kierownicy projektów, dbający, żeby
produkt końcowy jakoś dał się wcisnąć odbiorcom; inżynierami wymagań są też członkowie
zespołów agile, zwłaszcza „mistrzowie młyna”.
Co dalej, czyli świt inżynierii
Szkolenia przygotowujące do certyfikacji
IREB CPRE (Certified Professional in Requirements Engineering) będą za dwa, trzy lata szły
jak świeże bułeczki. Na wyższych piętrach
spopularyzują się certyfikaty IIBA oraz
QAMP. W tej sytuacji wzrośnie rola polskiego
oddziału IREB (www.ireb.org.pl). W Polsce
okrzepnie Stowarzyszenie Inżynierii Wymagań (www.wymagania.org.pl). Przyczynić się
do tego może konferencja „Dobre Wymagania
2013” (breq2013.wymagania.org.pl), która
odbędzie się 18–19 kwietnia.
Opisywane w „Computerworld” wielokrotnie ADP (Automated Defect Prevention).
jako metoda zarządzania projektami IT,
stanie się czymś powszechnie stosowanym,
oczywiście pod lepszą marketingowo nazwą.
Skoro „chmura” jest już zajęta, to może inne
duże zjawisko naturalne, np. „wulkan” albo
„śnieżyca”? Ta metodyka za pięć czy dziesięć lat może stać się powszechna i usunąć
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ń.
computerworld 15 stycznia 2013
13
7
i n ŻWIĘCEJ
Y n i e r i a WEŹ
W Y MUDZIAŁ
aG a Ń W KONFERENCJI!
z a r zDOWIEDZ
ą d z a n i e SIĘ
BoGdan Bereza
W
świetnej książce Toma
DeMarco „Zdążyć przed
terminem” akcję otwiera
scena, gdy bohater książki,
nieprawomyślny kierownik
projektów IT w dużej firmie,
stawia się na obowiązkowym kursie zarządzania projektami. Bohater pyta prowadzącego, czego będzie dotyczyć szkolenie. Jak
dobierać uczestników projektu? A może
jak ich motywować? Jak się porozumiewać,
rozwiązywać konflikty? Nic podobnego!
Prowadzący wyjaśnia, że szkolenie ma
nauczyć procedur, będzie zawierać omówienie dokumentacji i procesów. Tak, to
ważne sprawy – zgadza się bohater – tylko
nazwa szkolenia jest wobec tego nieodpowiednia. Powinno się ono nazywać nie
„Zarządzanie projektami”, lecz „Drobne
szczegóły administracyjne”.
istnieje szereg dobrych
metod szacowania pracochłonności projektów
na podstawie wymagań,
na przykład na podstawie
punktów funkcyjnych albo
punktów UML, czyli z modeli
wymagań. inne metody
to wróżenie z fusów.
Projekty
z automatu
Wystarczy jasno sformułować wymagania,
by zarządzanie projektami stało się
prostsze. Zawiłe scenariusze różnych
metodyk można wtedy zastąpić
zautomatyzowanymi działaniami.
20
8
computerworld 7 grudnia 2012
Jest w tym wiele prawdy, ale, moim zdaniem, tylko pod warunkiem, że te drobne
szczegóły administracyjne są pod kontrolą.
W przeciwnym razie nawet najbardziej
charyzmatyczny przywódca zainspiruje
uczestników do... entuzjastycznego i pracowitego udziału w marnotrawiącym zasoby chaosie. Natomiast projekt, w którym
te drobne szczegóły administracyjne nie są
problemem, nie potrzebuje ani Aleksandra
Wielkiego, ani Steve’a Jobsa – wystarczy
sprawny organizator.
Ja, robot: zalety
automatycznego nadzoru
Zalety automatyzacji rutynowych czynności administracyjnych, żmudnych i obarczonych ryzykiem pomyłki wynikającej
z ludzkiego zmęczenia, są oczywiste. Bez
komputerowej automatyzacji nie mielibyśmy dziś kart płatniczych ani przelewów
przez internet, telefonów komórkowych,
hamulców ABS... Szkoda czasu i miejsca
na dalsze wyliczanie!
Ta oczywista prawda ma, niestety,
wielu przeciwników – wszelkiej maści
konserwatystów, bystrych inaczej, którzy
boją się, że automatyzacja rutynowych
czynności pozbawi ich pracy.
SPECJALNE
i n Ż Y n i e rUSŁUGI
i a WYDANIE
W Y M aG a Ń
zarządzanie
Wystarczy wielka
tablica świetlna
Jak więc konkretnie, w praktyce, można
zrealizować automatyczne zarządzanie
projektem IT? Wystarczy wielka tablica
świetlna, na której każda żarówka odpowiada jednemu wymaganiu, które tworzony system ma realizować. Na początku
projektu żaróweczki świecą się głównie
na czerwono – nic nie jest jeszcze gotowe.
Rzut oka na taką tablicę zastępuje kunsztowne wyliczenia dumnych posiadaczy
MBA, listy kontrolne rycerzy zakonu
PRINCE2 czy intuicję liderów.
Praca każdej osoby w projekcie jest
połączona niewidzialnym drucikiem z tą
tablicą. Deweloperowi udaje się zrealizować, dokonać analizy statycznej i skompilować kawałek kodu – jedna żarówka
zmienia swoją barwę z czerwonej na
nieco bardziej żółtą. Udaje się zintegrować, połączyć ze sobą i nawet uruchomić
razem wiele takich kawałków? Cała grupa
żaróweczek zaczyna się palić miłym żółtym blaskiem.
Kiedy testy systemowe i akceptacyjne idą do przodu, coraz więcej żarówek
zielenieje. Jeśli cały projekt posuwa się
sprawnie do przodu, to w kolejnych
rzędach coraz więcej żarówek świeci się
na zielono. Wreszcie, w ostatnim rzędzie,
odpowiadającym ostatecznemu terminowi
zakończenia projektu, można spodziewać
się wszystkich czy niemal wszystkich
żarówek świecących na zielono.
Ale nie wszystkie żarówki są tej samej
wielkości. Są przecież wymagania kluczowe, które warunkują biznesowy sens całego
przedsięwzięcia (wielkie żarówy), i wymagania mniej ważne (małe żaróweczki).
Jakie to proste! Wystarczy dobrze znać
wymagania, ich wagę, powiązania ze
Zarządzanie projektem
to zarządzanie ryzykiem
Zarządzanie projektami, jeśli pojmować je nowocześnie, a nie w postaci ITIL-owej, COBIT-owej czy
PRINCE2-owej rąbanki, to przede wszystkim zarządzanie ryzykiem. Jak to znakomicie opisują w swojej
książce „Walzing with Bears” Tom DeMarco i Tim
Lister, oszacowanie terminu realizacji projektu jest
w istocie ćwiczeniem z oceny prawdopodobieństwa:
im późniejszą datę się podaje, tym mniejsze jest
ryzyko, że projekt przed jej upływem nie zostanie
ukończony.
Aby porządne zarządzanie ryzykiem nie odbywało
się metodą stosowania niedoskonałej, emocjonalnej
intuicji kierownika projektu lub jego podwładnych,
konieczne jest systematyczne przypisywanie ryzyka
poszczególnym wymaganiom i śledzenie jego zmian.
Taka praktyka, zastosowana w kilku projektach,
pozwoli nie tylko na półautomatyczne szacowanie
ryzyka w kolejnych projektach, ale także na udoskonalenie całego procesu IT.
sobą oraz z zaprojektowanymi modułami kodu i testami, a te z kolei powiązać
z osobami, które dane zadania wykonują! To się nazywa śledzeniem powiązań
wymagań (ang. requirements traceability). Na rynku jest wiele narzędzi, tak
By zrealizować
automatyczne zarządzanie
projektem iT, wystarczy
wielka tablica świetlna,
na której każda żarówka
odpowiada jednemu
wymaganiu, które tworzony
system ma realizować.
na początku projektu
żaróweczki świecą się
głównie na czerwono,
w miarę postępu prac jest
coraz więcej żółtych
i, wreszcie, zielonych.
komercyjnych, jak i darmowych, które to
wspierają.
Oczywiście, takie rozwiązania dostępne są też w chmurze. Polecam jedno
z wielu, znakomite, proste i niedrogie
narzędzie ReQtest. Szwedzkie narzędzie,
dodam, bo to – sądząc z reklam blachy
dachowej i rynien – dobry argument marketingowy.
Bez wróżenia z fusów
Czy narzędzie do zarządzania wymaganiami może wystarczyć do zarządzania
projektem? A co z oszacowaniem pracochłonności, co ze ścieżkami krytycznymi,
co z kamieniami milowymi, z harmonogramowaniem, przydzielaniem zadań różnym uczestnikom projektu? Jak mierzyć
stan realizacji projektu? Gdzie umieszczać plany, raporty, wyniki audytów?
Po kolei. Do oszacowania pracochłonności potrzeba przede wszystkim i niemal
wyłącznie dobrych wymagań. Tak jak
pracochłonność wykopania dołu jest
względnie prostą funkcją jego objętości
oraz twardości podłoża, tak pracochłonność projektu IT jest względnie zawiłą
funkcją sumy jego założeń – systemowego
odpowiednika objętości dołu. Istnieje szereg naprawdę dobrych metod szacowania
pracochłonności projektów na podstawie
wymagań, na przykład na podstawie
punktów funkcyjnych albo punktów
UML, czyli z modeli wymagań. Inne metody to wróżenie z fusów.
Ścieżki krytyczne są funkcją hierarchii
wymagań. Jeśli realizacja ważnych
wymagań X, Y i Z wymaga realizacji
wymagania A, to owo A grzecznie nam się
układa na trzech ścieżkach krytycznych.
I patrzcie: wystarczyła analiza wymagań,
nie trzeba było doktoratu z zarządzania!
Harmonogram, kamienie milowe... Tak,
przyznaję, to są rzeczy, których narzędzia
do zarządzania wymaganiami nie wspierają wprost. Dlatego zbudowano narzędzia
łączące świat PM oraz świat wymagań.
Moim zdaniem znakomitym przykładem
takiego narzędzia jest Concerto. Łączy ze
sobą tradycyjnie osobne światy: śledzenie
powiązań wymagań, zarządzanie zadaniami, automatyczne zapobieganie błędom, zarządzanie projektem i integrację.
Jeśli nawet udało mi się jakoś okiełznać zastrzeżenia tradycjonalistów, to
już słyszę nadciągającą falę zastrzeżeń
ze świata Agile, sprowadzających się do
narzekań – „jest zupełnie inaczej, niż
myślisz” oraz „ty mnie nie rozumiesz”.
Rzeczywiście, proponowana przeze mnie
tablica świetlna odebrałaby nieco chaotycznego romantyzmu „młynom” (scrum
w agile’owym dialekcie, czyli – mówiąc
po ludzku – codzienne spotkania zespołu), bo przestałyby one służyć tak mocno
wzajemnemu informowaniu się. Jednak
nasza tablica świetlna doskonale wpisuje się w agile’owe pojęcie rejestru zadań
przebiegu (sprint backlog).
Jeśli to takie proste, to
dlaczego się tego nie robi
Zetknąłem się ostatnio z nieznanym
mi wcześniej zagadnieniem: audytem
zarządzania budynkiem użyteczności publicznej. Zakres takiej kontroli
jest olbrzymi, ale prawdziwy jej smak
wynika dopiero z faktu, że nikt – poza
kontrolerami – nie wie dokładnie, jakie
są wymagania! Okazuje się na przykład,
że obowiązkowa kontrola techniczna powinna obejmować coroczne sprawdzanie
instalacji odgromowej.
Nawet jeśli administrator budynku
wie, co i kiedy powinno być zrobione,
musi sam zadbać, aby o tym pamiętać.
Nie istnieje żaden automatyczny system,
który o tym przypomni. Aż się prosi
o taką automatyczną listę kontrolną – zadanie do realizacji dla studenta drugiego
roku informatyki. Wtedy administrowanie budynkiem przestałoby być nieustannym stresem i nieustannym pilnowaniem
tysięcy drobnych szczegółów administracyjnych. To wszystko robiłoby się
automatycznie!
Ale pewnie nigdy tak nie będzie.
Pomyślałem: jaka straszna jest ta branża,
administrowanie budynkami publicznymi, prawda? Bo u nas, w świecie IT, jest
przecież zupełnie... tak samo.
computerworld 7 grudnia 2012
21
9
WIĘCEJ
PrO
J e K T Y i TWEŹ UDZIAŁ W KONFERENCJI!
z a r zDOWIEDZ
ą d z a n i e SIĘ
Procedury chronią przed
skutkami błędów
inżynieria wymagań
– splot słoneczny iT
Inżynieria wymagań obejmuje kluczowe dla
projektów IT obszary: analizę biznesową,
techniki sprzedaży, metodyki agile,
zarządzanie, technologie programowania,
testowanie i prawo IT.
BOgdan
Bereza
22
10
W
73. sekundzie lotu promu
kosmicznego Challenger 28 stycznia 1986 r.
nastąpiła eksplozja – cała
załoga zginęła. Członkiem
komisji badającej przyczyny katastrofy był laureat Nagrody Nobla
Richard Feynman. To on wykrył przyczyny
awarii: uszczelki w silnikach pomocniczych nie działały poprawnie w niskich
temperaturach. Wiedzieli o tym szeregowi
pracownicy projektu, ale to nie dotarło do
kadry zarządzającej lub zostało przez nią
zignorowane.
1996 rok: w wyniku błędu oprogramowania misja 501 rakiety Ariane 5 kończy
się zaraz po starcie efektowną eksplozją.
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 wpisany na listę
zabytków, co dramatycznie obniża wartość
nieruchomości. Konserwator zabytków
tłumaczy się, że „nie przyszło mu do głowy” zawiadomić właściciela, zaś rzecznik
computerworld 20 listopada 2012
Ministerstwa Kultury mówi: „nie było złej
woli, zabrakło procedur”.
Przyczyny pomyłek,
błędów i awarii
Co wspólnego mają te historie? Temu
zagadnieniu poświęcona jest książka
Dietricha Dörnera „The Logic of Failure”.
Jest to książka o tym, jak ludzie się mylą,
podejmują złe i głupie decyzje. Co nam,
ludziom IT, z tej gorzkiej prawdy? 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. Niezbędne są procedury! Nie
biurokracja i papierologia, ale elastyczne, sprawne i automatyczne procedury,
zabezpieczające nas przed skutkami
naszych pomyłek.
Procedury to nie luksus, to oszczędność.
Dzięki nim wykryjemy błędy, kiedy ich
usunięcie jest jeszcze tanie, projekty będą
przebiegały sprawniej, a programiści, testerzy i klienci będą szczęśliwsi.
Procedury to drogi prowadzące do celu.
W IT cel to wymagania wobec systemu IT.
To nie jest popularna nazwa: częściej mówi
się o warunkach, założeniach, projektach,
właściwościach. Zaś nazwa dziedziny
wiedzy uczącej, jak znajdować, określać
i skutecznie realizować cele, czyli inżynieria wymagań, to rzadkość. Inżynieria wymagań obejmuje kluczowe dla powodzenia
przedsięwzięć IT obszary, których nazwy
atakują nas ze wszystkich stron: analizę
biznesową, techniki sprzedaży, metodyki
agile, metody zarządzania, technologie
programowania, sposoby testowania i nawet prawo IT. Niepowodzenia projektów
wynikają z deficytów inżynierii wymagań.
analiza biznesowa to inżynieria
wymagań
Obecnie wszelkie zmiany procesów biznesowych oznaczają zmiany systemów IT lub
wdrażanie nowych rozwiązań IT. Analiza biznesowa to dyscyplina na wskroś
informatyczna. To pierwszy etap inżynierii
wymagań albo proces ją poprzedzający,
źródło wiedzy dla tzw. procesu pozyskiwania wymagań.
Często spotyka się opisy, w których inżynieria wymagań nie występuje. Następnym krokiem po analizie biznesowej jest
projektowanie systemów. Wskutek takiego
podejścia, informatycy słabo się orientują,
co właściwie mają skonstruować...
Sprzedaż to 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!
Innymi słowy, sprzedaż to forma inżynierii
wymagań, a psychologiczne zagrywki potrzebne do złapania klienta omawia się na
kursach analizy biznesowej oraz inżynierii
wymagań pod skromną nazwą technik
pozyskiwania wymagań.
Metodyki agile to inżynieria
wymagań
Wymagania kojarzą się z opasłymi tomami
dokumentacji. Natomiast metodyki zwinne
WYDANIE
USŁUGI
PrO
J e K T Y i TSPECJALNE
zarządzanie
– agile, extreme programming, TDD – same
nazwy brzmią radośnie, luzacko, nowocześnie. Porządna inżynieria wymagań nie
musi być nudziarstwem, zaś metody agile
nie tylko nie obywają się bez inżynierii
wymagań, lecz są jej częścią!
Co wykryli i ogłosili światu sygnatariusze Manifestu Agile? (www.agilemanifesto.
org) Odkryli proste i dobrze znane zasady
inżynierii wymagań i zarządzania projektami:
• wymagania są zwykle zmienne; 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ń; skuteczną metodą pomocy jest
prototypowanie: tworzenie małych fragmentów funkcjonalności, które ułatwiają
klientom odkrycie, czego tak naprawdę
chcą;
• próby kurczowego trzymania się kaskadowego modelu cyklu wytwarzania oprogramowania i szczegółowego opisania wymagań, zanim przystąpi się do tworzenia
kodu, są nieskuteczne i szkodliwe.
Oto koncepcja agile w pigułce. Metodyki zwinne przyniosły IT odkrycie, że
wymagania można i warto odkrywać za
pomocą prototypowania i bardzo częstych
kontaktów z klientem. Tylko niech nikt nie
twierdzi, że podejście agile eliminuje inżynierię wymagań. Jest przeciwnie – metody
zwinne wprowadzają inżynierię wymagań
w procesy projektowania i programowania
w znacznie większym stopniu niż w metodach tradycyjnych!
Pokusa
pisania kodu
na łapu-capu
jest wielka.
Program,
w przeciwieństwie do
mostu, można
poprawiać
wielokrotnie,
nawet po widowiskowym
zawaleniu się.
za uleganie
tej pokusie
przychodzi
nam nieraz
drogo płacić.
zarządzanie projektami to
inżynieria wymagań
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
Prawnicy to zamaskowani inżynierowie
wymagań
Zrozumienie podstaw inżynierii wymagań jest potrzebne zarówno
wśród prawników, jak i podpisujących kontrakty menedżerów.
Mimo dużych różnic w zakresie terminologii, są liczne podobieństwa w sposobie podejścia prawników, inżynierów wymagań
oraz testerów projektujących testy akceptacyjne. Kontrakt na
„wdrożenie systemu” 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 została
przez prawnika strony zamawiającej propozycją, że w tej sytuacji
zamawiający „w zasadzie zapłaci za aplikację”...
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 inżynieria wymagań
w 100%;
2. Oszacowanie pracochłonności to zestaw
metod, pozwalających szacować pracochłonność ich realizacji;
3A. Identyfikacja zadań to podział wymagań głównych na mniejsze, cząstkowe;
3B. Przydzielenie zadań i harmonogramowanie nie należą do inżynierii wymagań, ale ich wyniki przekładają się na
atrybuty wymagań;
4. Nadzorowanie to określanie statusu
realizacji poszczególnych wymagań.
Celem wywodu nie jest udowadnianie
tezy, że inżynieria wymagań oraz zarządzanie projektami to jedno i to samo, bo tak
nie jest. Należy zrozumieć, że te dwa procesy są ze sobą powiązane; nie ma dobrego
kierowania projektem bez zaangażowania
się w inżynierię wymagań.
Programowanie to inżynieria
wymagań
Jeśli programowanie to inżynieria wymagań, to czy wbijanie gwoździ lub układanie
cegieł to architektura czy biznesplan dla
nowego wieżowca? W dobrze zorganizowanym projekcie każde uderzenie młotka
powinno wynikać z dokumentacji.
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 daje się to zrobić, tyle
że gorzej i drożej. Kompetencje planisty,
architekta, operatora dźwigu i murarza to
zupełnie różne światy, ale między inżynierem wymagań, projektantem i programistą
nie ma tak dużych różnic.
Skąd bierze się wiele chronicznych
problemów IT? Pokusa pisania kodu na
łapu-capu jest wielka. Program można
poprawiać wielokrotnie, nawet po widowiskowym zawaleniu się. Za uleganie jej
przychodzi nam nieraz drogo płacić.
Testowanie to inżynieria
wymagań
Testowanie polega na kontrolowaniu, czy
to, jak jest, zgadza się z tym, jak ma być.
Skąd wiadomo, jak ma być? To jest zapisane w wymaganiach!
To jakim cudem odbywa się testowanie
w tysiącach projektów, gdzie wymagania
są niepełne, błędne, niespójne, nigdzie
niezapisane? Cóż, wtedy albo testowanie
jest bezcelowym marnowaniem czasu,
albo brakujące wymagania zdobywa się
podczas testowania. Testerzy domyślają się,
jaki ma być wynik oczekiwany. Jest nawet
szkoła „testowania eksploracyjnego”, która
Nauka i certyfikacja
inżynierii wymagań
Zasad inżynierii wymagań i analizy biznesowej
można się nauczyć. Istnieje wiele kursów
uczących metod modelowania procesów
biznesowych i wymagań (m.in. popularne UML).
Poniżej prezentujemy listę kilku znanych na
świecie certyfikacji ogólnych, wykraczających
poza jedną technikę.
IREB – Intenational Requirements
Engineering Board
Certyfikaty inżynierii wymagań oferuje międzynarodowa organizacja IREB (www.ireb.org). Polska
grupa 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. Na
świecie certyfikaty IREB oferowane są w sześciu
językach, w wielu krajach Europy, Ameryki i Azji.
Certyfikat podstawowy – CPRE Foundation Level
– ma 10 tys. 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 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.
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.
W Polsce powstaje Stowarzyszenie Inżynierii
Oprogramowania (zebranie założycielskie
planowane jest na 10 stycznia 2013). Na
kwiecień planowana jest konferencja „Dobre
wymagania 2013”. Osoby zainteresowane
przystąpieniem do stowarzyszenia i udziałem w konferencji mogą uzyskać więcej informacji na stronie: www.wymagania.org.pl
computerworld 20 listopada 2012
23
11
DOWIEDZ SIĘ WIĘCEJ  WEŹ UDZIAŁ W KONFERENCJI!
Projekt bez zbędnych opóźnień
Z TOMEM GILBEM, konsultantem zarządzania
i inżynierii oprogramowania, rozmawiamy
o ewolucyjnych metodach zarządzania projektami.
dzi jest zdania, że skoro co tydzień dostarczają nowy kod, to pracują ewolucyjnie. Ale jeśli
nie tworzą co tydzień nowej wartości dla
rzeczywistych użytkowników oraz innych
interesariuszy, to nie jest to metoda ewolucyjna.
Zaletą
podejścia
ewolucyjnego
jest to, że na
jego wyniki nie
trzeba czekać
długo. Już po
tygodniu widać,
czy robimy coś
dobrze,
czy nie.
A programowanie ekstremalne czy metody
zwinne, w których bezpośrednio współpracuje się
z klientem?
Programowanie ekstremalne nie zakłada
tworzenia całościowych wymagań, więc
trudno określić, na ile kolejne, bardzo często
budowane wersje programu tworzą kolejny
poziom wartości dla klienta. Z kolei najbardziej popularna metodyka zwinna, Agile
Scrum, nie określa jasno relacji między nadrzędnymi wymaganiami a zadaniami dla poszczególnych przebiegów. Nie mówię, że to
są złe metodyki, ale nie wystarczy pracować
zgodnie z nimi, aby móc mówić o metodzie
ewolucyjnej.
O
co właściwie chodzi z metodami ewolucyjnymi? Czy to nie jest kolejna ładna
nazwa na te same sposoby pracy, jakie
stosowano zawsze?
Szesnaście lat temu, w 1994 roku,
konserwatywny przecież Departament Obrony USA zmienił swoje standardy
inżynierii oprogramowania. Zaczęto wtedy
stosować tak zwany Standard 498, który jest
ewolucyjny. Departament Stanu oficjalnie
wyrzekł się stosowania metod kaskadowych
w projektach. To jest przykładem, jak w końcu, po wielu latach doświadczeń, przekonano się, że metody ewolucyjne sprawdzają się
tam, gdzie metody kaskadowe zawodzą.
Co charakteryzuje metody ewolucyjne?
Metody ewolucyjne polegają na tym, że
każdy projekt dzieli się na mniejsze projekty. Może ich być wiele, nawet pięćdziesiąt! Chodzi o to, aby każdy kolejny cykl
dostarczał interesariuszom projektu jakąś
nową wartość. Dzięki temu można także już
w trakcie projektu, a nie dopiero tuż przed
jego zakończeniem, zorientować się, czy
zastosowane technologie sprawdzają się, czy
12
dobrze rozumiemy potrzeby użytkowników.
Dzięki podejściu ewolucyjnemu kierownictwo projektu, jego sponsorzy otrzymują na
bieżąco informację, czy wszystko dobrze
idzie.
Czym różnią się metody ewolucyjne od metod
zwinnych?
Pojęcie „metody ewolucyjne” jest szersze.
Zawierają się w nich metody zwinne, ale nie
tylko. Metody ewolucyjne pojawiły się dużo
wcześniej, pod innymi nazwami, takimi jak:
cleanroom software engineering, codzienne
budowanie, metody przyrostowe, prototypowanie. Każda z nich jest w jakimś stopniu
metodą ewolucyjną.
Na ile metody ewolucyjne – niezależnie od nazwy
– są dziś rozpowszechnione?
Widziałem wyniki badań, według których
około 30% organizacji posługuje się metodami ewolucyjnymi. To mnie dziwi.
Dlaczego? Jak, Pana zdaniem, wygląda to
naprawdę?
W rzeczywistości odsetek firm stosujących
metody ewolucyjne wynosi 1–5%. Wielu lu-
Czy są sytuacje, kiedy metody ewolucyjne nie są
odpowiednie?
Moim zdaniem, nie – a wiele się nad tym
zastanawiałem. Metodami ewolucyjnymi
posługuję się od 1960 roku. Wielokrotnie
natrafiałem na opór, spotykałem się z osobami mówiącymi, że ich projektu nie da się
zrealizować w sposób ewolucyjny, bowiem
nie da się go podzielić na tak małe kawałki.
W rzeczywistości trudność polega na tym,
że nie umie się tego zrobić. W tej dziedzinie wielu ludziom brakuje odpowiedniego
wykształcenia.
Co doradziłby Pan organizacjom, które chciałyby
spróbować podejścia ewolucyjnego?
Zaletą podejścia ewolucyjnego jest to, że na
jego wyniki nie trzeba czekać długo. Już po
tygodniu widać, czy robimy coś dobrze, czy
nie.
Podstawowa trudność dotyczy oceny
wartości dla udziałowców. Jeśli na przykład
nadrzędnym celem projektu jest obniżenie
kosztów określonego działania klienta, to nie
jest dostarczaniem wartości produkowanie
kodu realizującego kolejne punkty funkcyjne lub kolejne przypadki użycia, o ile ich
dostarczenie nie powoduje rzeczywistego
obniżenia kosztów. Pod tym kątem w pierwszym rzędzie trzeba oceniać wartość poszczególnych funkcji oprogramowania.
Czy mógłby Pan podać przykłady sukcesu metod
ewolucyjnych?
Doświadczenie nauczyło mnie, że w ciągu
godziny potrafię znaleźć sposób, jak podzielić dowolnej wielkości projekt na fragmenty
nie większe niż 2% całości. Udało mi się to
osiągnąć w ogromnym projekcie amerykań-
WYDANIE SPECJALNE
USŁUGI
skiego Departamentu Obrony, tworzącym
oprogramowanie do zarządzania personelem
tej zatrudniającej ponad 2 mln osób organizacji. W Hewlett-Packard ta metoda pracy
stosowana jest od 20 lat, nikomu nawet do
głowy nie przychodzi, by podważać zasadę
cotygodniowych dostaw nowych wersji.
Dzięki metodom ewolucyjnym działania
organizacji stają się bardziej elastyczne,
pracownicy zadowoleni, a klienci usatysfakcjonowani. Microsoft jest także wielkim
użytkownikiem tej metody, choć nigdy nie
nazywał jej ewolucyjną, posługując się
własnymi nazwami. Zostało to opisane m.in.
w książce dr. Michaela Cusumano z MIT pt.
„Microsoft Secrets”. W tym czasie Microsoft
był moim klientem. Kiedy współpracowałem z ich dyrektorem testów, powiedział
kiedyś: „Tom, ewolucyjne dostawy to nasz
sposób życia tutaj, w Microsoft”, choć, jak
już wspomniałem, stosowano tam zupełnie
inne nazwy.
Microsoft wykorzystuje podejście ewolucyjne na trzech poziomach. Mają swoje codzienne budowanie, swoje kamienie milowe
co 6 tygodni i wreszcie swoje uwolnienia,
sterowane kryteriami marketingowymi. Tak
naprawdę Microsoft jest jednym z wielkich
użytkowników metod ewolucyjnych.
Inny przykład to trwający ponad 4 lata
projekt zrealizowany przez IBM Federal
Systems Division (Wydział Projektów Federalnych IBM), kierowany przez prof. Harlana
Millsa. Co miesiąc – to prawie dokładnie 2%
z 4 lat – robiono kolejną przetestowaną dostawę. Ten i inne projekty prowadzone przez
dział Millsa zrealizowano w terminie i bez
przekroczenia budżetu. Wśród nich znalazło
się oprogramowanie – jego naziemna część
– do promu kosmicznego NASA, którego
pracochłonność wyniosła 10 000 osobolat!
Jeszcze w latach 80. ubiegłego stulecia Harlan Mills udowodnił, że podejście ewolucyjne działa w projektach Marynarki Wojennej
USA, Departamentu Obrony i w NASA.
Przy okazji odkryliśmy wtedy, że w podobny sposób NASA tworzyło tę część oprogramowania promu, która wraz z nim leciała
w przestrzeń (na pokładzie promu kosmicznego znajdują się cztery komputery, niezależnie
wykonujące to samo oprogramowanie, oraz
piąty, rezerwowy, wykonujący tylko procedury wejścia na orbitę i lądowania). Co nas jeszcze bardziej zaskoczyło, to fakt, że naukowcy
zajmujący się techniką rakietową i lotów
kosmicznych pracowali w sposób ewolucyjny
już od końca II wojny światowej, podczas
gdy znaczna część ludzkości aż do dzisiaj
tkwi w przestarzałym modelu kaskadowym!
Projekt dąży do celu tak samo jak samonaprowadzająca się rakieta – dokonując, gdy trzeba,
nieznacznych poprawek kursu. W granicach
2% zawsze można zmienić kierunek; umożliwia to adaptację do zmian wymagań w trakcie
projektu, co dziś jest koniecznością biznesową. Tę zasadę znano i stosowano już o wiele
lat wcześniej, niż powstał Manifest Agile.
Jest Pan współautorem książki „Software Inspection”. Jaka jest Pana zdaniem obecna i przyszła
rola testowania i kontroli jakości?
Pana pytanie dotyczy w istocie dwóch
zagadnień: kontroli jakości oraz zapewnienia jakości. Inspekcje same w sobie nie są
żadnym magicznym rozwiązaniem. To dobra,
systematyczna metoda pozwalająca skutecznie sprawdzać jakość dokumentacji, kodu,
produktów informatycznych, lecz niewłaściwie stosowana, nie uratuje źle prowadzonego
projektu.
Od około 15 lat coraz więcej uwagi poświęca się testowaniu. Jest to wprawdzie postęp w porównaniu z czasem, kiedy testowanie utożsamiano z debugowaniem, ale nadal
jest to metoda przestarzała i nieskuteczna
w porównaniu z zapobieganiem błędom. Pod
tym względem przemysł informatyczny nadal pozostaje daleko w tyle za – na przykład
– przemysłem motoryzacyjnym.
Zapobieganie błędom nazywam „lekkim
zapewnieniem jakości” (Lean Quality Assurance).
Na czym polega nowatorstwo tej metody?
W istocie, jest ona sposobem na to, jak
w praktyce realizować zasady, doskonale podsumowane tytułem znanej książki
Philipa Crosby’ego „Quality is Free” („Jakość
jest za darmo”). Oczywiście, jakość nie jest
dosłownie za darmo, ale jest o wiele tańsza
niż jej brak.
Testowanie – także automatyczne, metodami TDD czy zwinnymi – jest kosztowne, a najbardziej kosztowne jest naprawianie znalezionych przez testy błędów. O wiele taniej jest
im zapobiegać, zarówno w każdym projekcie,
jak i poprzez takie kształtowanie procesów,
aby sprzyjały zapobieganiu błędom.
Na czym polega takie zapobieganie błędom?
W jego skład wchodzi szereg szczegółowych
technik. Zaczyna się od starannej analizy
wymagań interesariuszy – wszystkich, nie
tylko użytkowników i zleceniodawcy! Potem
konieczne jest dokładne zaprojektowanie
jakości – nie da się jej wtestować w prawie
już gotowy system. Dobrze zaprojektowana
architektura jest podstawą jakości systemów,
czego nie biorą pod uwagę modne dziś metody zwinne.
Rozmawiał Bogdan Bereza-Jarociński
ŻYCIE POD PRĄD
Tom Gilb należy do znanych na całym świecie
guru zarządzania i inżynierii oprogramowania.
Jest autorem kilku wielokrotnie wznawianych
książek, oryginalnym myślicielem i aktywnym
praktykiem, którego metody z powodzeniem
stosuje wiele międzynarodowych korporacji.
Urodził się w 1940 roku w Pasadenie, w pobliżu
Los Angeles. Prowadzi intensywne życie – pod
prąd. Większość ludzi stara się przenieść do
Kalifornii, Tom płynął w przeciwnym kierunku.
Wyemigrował do Londynu, mając 16 lat, do
Norwegii – dwa lata później. Obecnie mieszka
niedaleko Oslo.
Napisał m.in. książki „Principles Software
Engineering Management” („Zasady zarządzania
inżynierią oprogramowania”), „Software
Inspection” („Inspekcje oprogramowania”)
razem z Dorothy Graham oraz „Competitive
Engineering” („Konkurencyjna inżynieria”).
Jest twórcą języka Planguage do opisu
wymagań oraz metodyki Evo – Evolutionary
Project Management („Ewolucyjne zarządzanie
projektami”), o której książkę napisał
współpracujący z nim jego syn, Kai Gilb.
Tom angażował się początkowo głównie
w projekty IT, ale od ponad 25 lat zajmuje się
intensywnie zagadnieniami zarządzania korporacyjnego oraz inżynierią wielkich systemów
w przemyśle lotniczym, telekomunikacyjnym
i elektronicznym. Metody Toma Gilba są oficjalnymi standardami w IBM, Nokii, Ericssonie, HP,
Intelu, Citigroup, Symbian i w Philips Medical.
Tom był dotąd w Polsce dwukrotnie:
w kwietniu 2008 roku na konferencji QAFATMS w Krakowie oraz w październiku 2008
na konferencji RE-AQCtion w Gdańsku.
W maju tego roku będzie prowadził warsztaty
w Szczecinie i Warszawie.
Testowanie jest kosztowne,
a najbardziej kosztowne
jest naprawianie
znalezionych przez testy
błędów. O wiele taniej jest
im zapobiegać, zarówno
w każdym projekcie, jak
i poprzez takie kształtowanie
procesów, aby sprzyjały
zapobieganiu błędom.
13
Z ADOWIEDZ
R Z Ą D Z A NSIĘ
I E WIĘCEJ
I T I BI ZWEŹ
N E S UDZIAŁ W KONFERENCJI!
Dramatyczny wzrost
wydajności dzięki IT
Aby firmy mogły sprawnie reagować na
potrzeby rynku, potrzebne jest tworzenie
„oprogramowania jednorazowego”, tak jak
jednorazowych maszynek do golenia.
„Parasoftu” służą przede wszystkim
programistom, umożliwiając wczesne
testowanie oprogramowania (analiza statyczna, automatyczne testy jednostkowe),
testerom (automatyczne testy funkcjonalne) oraz kierownikom projektów. Przy
okazji Adam odkrył, że oprogramowanie
można tworzyć zupełnie inaczej – dramatycznie sprawniej i skuteczniej – niż
pozwalają na to sposoby dominujące dziś
w przemyśle informatycznym. Ta nowa,
rewolucyjna metoda, została opisana
w książce Automated Defect Prevention
(wydana w USA w 2007 roku, nie tłumaczona na język polski).
Wszędzie, tylko nie w IT
B
lisko trzy lata temu, na łamach BOGDAN
„Computerworld” opublikowa- BEREZAJAROCIŃSKI
ny został artykuł pt. „Między biurokracją a chaosem”
(CW 30/2007). Traktował on
o metodyce automatycznego
zapobiegania błędom (ADP – Automated
Defect Prevention), stworzonej i opisanej
w książce Adama Kolawy, założyciela
i właściciela rmy „Parasoft” oraz Doroty
Huizinga, wiceprzewodniczącej California State University – Fullerton.
Adam, mający doktorat z zyki
teoretycznej na California Institute of
Technology, potrzebował kiedyś stworzyć
oprogramowanie na użytek swoich badań.
Zrobił to i odkrył, że informatyka pociąga
go bardziej niż zyka. Wtedy (w 1987 r.)
założył rmę „Parasoft”, specjalizującą się
w produkcji narzędzi wspomagających
produkcję oprogramowania. Narzędzia
26
14
COMPUTERWORLD 31 sierpnia 2010
Około 80 lat temu, dwóch amerykańskich
specjalistów, Joseph Juran i Wiliam Deming opracowało metodyki zarządzania
jakością, których podstawą jest teza, że
zapobieganie błędom (a więc i defektom)
jest o wiele tańsze i skuteczniejsze niż
wykrywanie defektów i ich mozolne usuwanie. Tezy tej nie bardzo chciał słuchać
w latach 40., po zakończeniu II wojny
światowej, amerykański przemysł motoryzacyjny. Zarządzanie jakością polegało
tam przede wszystkim na kontroli jakości:
na wykrywaniu braków i ich mozolnym
usuwaniu. Natomiast idee Jurana i Deminga wzięli sobie do serca japońscy producenci samochodów i dlatego – jeszcze
dziś – na polskich (i nie tylko!) drogach
widzi się o wiele więcej aut produkcji
japońskiej niż amerykańskiej.
Obecnie podejście Jurana/Deminga jest
czymś naturalnym w większości branż
produkcyjnych. Zamiast tylko naprawiać
lub odrzucać wadliwe produkty, zarządzanie jakością koncentruje się na identykacji i usuwaniu wad procesu produkcyjnego. Proces zarządzania jakością jest
ciągły i każdy z pracowników jest w niego
zaangażowany. Jako TQM (Total Quality
Management, kompleksowe zarządzanie
jakością) lub pokrewna metoda SixSigma,
koncepcja ta znana i stosowana jest od
dawna. Ale nie w przemyśle informatycznym! Tutaj, niestety, wciąż dominuje podejście typu: „jakość to będzie”.
Głównym sposobem zarządzania jakością
jest kontrola jakości – zamiast usprawniać
procesy i procedury, koncentrujemy się
na testowaniu i „debugowaniu”, czyli
szukaniu i usuwaniu defektów gotowych
produktów. Takie podejście ma wysoce
niekorzystne skutki biznesowe.
Biznes to IT
OK, powie Czytelnik, produkcję oprogramowania można usprawnić. Równie
dobrze można usprawnić dostawy elektryczności, wywóz śmieci albo znaleźć
tańsze lokale dla rmy. Czy jednak ma to
większe, nie mówiąc już o „dramatycznym”, znaczenie dla skuteczności rmy,
dla jej rezultatów biznesowych? Temu
właśnie tematowi poświęcona jest najnowsza książka Adama Kolawy „Skokowy
wzrost wydajności” (The Next Leap in
Productivity, która w najbliższych miesiącach pojawi się w polskim tłumaczeniu
nakładem Wydawnictwa CeDeWu.
Otóż, współczesny biznes nie tylko
– jak 20 lub 30 lat temu – wykorzystuje
IT, jako funkcję o marginalnej wartości, w porównaniu np. z marketingiem
i sprzedażą, lecz – niezależnie od tego,
czy chodzi o handel butami, produkcję
oprogramowania lub sprzedaż usług, np.
wycieczek zagranicznych – współczesny
biznes to jest IT!
Jaki jest typowy problem z oprogramowaniem? Kierownicy działów IT śmiertelnie boją się wszelkich zmian i modykacji: „co nie jest popsute, tego nie
należy naprawiać”. Zmiany budzą obawy
i zajmują wiele czasu, a oprogramowanie
jest notorycznie zawodne. Z tego powodu
zmiany systemów IT chronicznie nie na-
Dotąd mówiło się głównie, że kluczowe jest, aby
dyrektor IT rozumiał dobrze
biznes. Teraz już wiemy, że
równie ważne jest, aby
dyrektor zarządzający
rozumiał dobrze możliwości, które stwarza IT.
dążają za zmianami rynkowymi: nowymi
potrzebami lub upodobaniami klientów.
Jakakolwiek modykacja istniejących
aplikacji połączona jest ze znacznym
ryzykiem, czego wyraźnym objawem są
m.in. rozbudowane systemy zarządzania błędami („defektami” wg termino-
SPECJALNE
I T IUSŁUGI
B I WYDANIE
ZNES
Z
ARZĄDZANIE
logi ISTQB), ponieważ błędy znajduje
się zwykle pod koniec projektu, a ich
naprawa – podobnie jak każda modykacja istniejącej funkcjonalności – zawsze
budzi obawy, że zepsuje się to, co dotąd
działało poprawnie.
Taki stan rzeczy powoduje, że
rmy nie nadążają szybko i elastycznie
reagować na zmienne potrzeby rynku,
na potrzeby tworzenia nowych wersji
oprogramowania, na zróżnicowanie
rynków w epoce globalizacji. Dlatego
potrzebna jest metoda, która pozwoliłaby
tworzyć – wg określenia Adama Kolawy
– „oprogramowanie jednorazowe”, tak jak
istnieją obecnie jednorazowe maszynki
do golenia, pieluchy, talerze i sztućce.
Takie oprogramowanie można by tworzyć
i modykować szybko i niezawodnie, bez
długotrwałego procesu produkcji, testowania, debugowania i wdrażania.
Kierownicy działów IT
śmiertelnie boją się wszelkich
zmian i modyfikacji. Z tego
powodu zmiany systemów IT
chronicznie nie nadążają za
zmianami rynkowymi: nowymi
potrzebami lub upodobaniami
klientów.
Jak osiągnąć ten cudowny – zdawałoby
się – wynik? Według Kolawy, rozwiązanie
jest proste: poprzez zastosowanie ADB
(Automated Defect Prevention) do wytwarzania aplikacji. Czy to możliwe? Tak.
Zastosowanie ADB, czyli w pełni zautomatyzowanych testów statycznych, jednostkowych i funkcjonalnych, w połączeniu
z narzędziami do zarządzania projektem,
śledzenia związków wymagań z komponentami oprogramowania i testami,
pozwala kilkakrotnie, a nawet kilkunastokrotnie zwiększyć wydajność w tworzeniu
oprogramowania, co odpowiednio i umiejętnie wykorzystane, może doprowadzić
do wielokrotnego wzrostu wydajności
przedsiębiorstwa – dramatycznego, skokowego wzrostu wydajności rmy.
Klucz do sukcesu
Dotąd mówiło się głównie, że kluczowe
jest, aby dyrektor IT rozumiał dobrze
biznes. Teraz już wiemy, że równie ważne
jest, aby dyrektor zarządzający rozumiał
dobrze możliwości, które stwarza IT.
Adam Kolawa pisze: „Bez IT nie bylibyśmy
w stanie wykorzystywać okazji i unikać
szybko pojawiających się zagrożeń. Aby
móc szybko i sprawnie reagować na
zmiany na rynkach, potrzebne są duże
pieniądze i elastyczne zasoby IT. Mówiąc
szczerze, IT musi umieć zmieniać się
równie szybko jak rynki. Statyczne IT nie
pomoże organizacji konkurującej w globalnym biznesie. Aby szybko dostosowywać
się do zmian, IT potrzebuje dającego
się dostosować oprogramowania, co jest
wprawdzie kłopotliwe, ale stwarza też
nowe okazje. Organizacje umiejące szybko
i sprawnie przekształcić wiedzę oraz informację w kod oprogramowania, uzyskają
przewagę konkurencyjną nad rywalami,
mającymi wolniejsze, mniej sprawne
procesy wytwarzania oprogramowania.
W kolejnej rundzie światowej konkurencji
nie wystarczy mieć najlepszych ludzi. Co
będzie potrzebne? Najszybsi i najbardziej
kreatywni programiści, umiejący przetwarzać pomysły biznesowe w kod oprogramowania? Wcale nie. To przestarzały i niebezpieczny sposób myślenia. Zakłada się, że
IT jest tylko kosztem ponoszonym, aby móc
utrzymać przedsiębiorstwo. W rzeczywistości IT jest olbrzymią wartością – bezcennym motorem wzrostu i ekspansji”.
Elastyczne i szybkie tworzenie niezawodnego oprogramowania pozwala przedsiębiorstwu szybko, sprawnie i elastycznie
dostosować się do zmian na rynkach, wyprzedzać konkurencję, dostarczać klientom
to, czego chcą. Dyrektor IT każdej rmy
– zarówno wytwarzającej oprogramowanie na własne potrzeby, jak i na sprzedaż
– powinien z grubsza znać metodykę ADP,
umożliwiającą taki tryb pracy. Analitycy
systemów (nazwa amerykańska – w Europie bardziej przyjęta jest nazwa „inżynierowie wymagań”), projektanci oraz
programiści powinni stopniowo uczyć się
pracować zgodnie z tą metodyką, aby móc
ją stosować w praktyce i wytwarzać aplikacje – lub modykować istniejące – tak aby
szybko i niezawodnie przekładać pomysły
biznesowe na poprawnie działające oprogramowanie!
Żeby ulepszyć,
trzeba zrozumieć
Po co dyrektor zarządzający, właściciel
lub prezes rmy ma rozumieć podstawowe zasady IT, tak jak opisuje je Adam
Kolawa? Oczywiście nikt nie wymaga – byłoby to absurdem – by prezes
uczył się programowania. Nie w tym
rzecz. Natomiast zadaniem jego jest
zatrudnienie właściwego dyrektora IT
i narzucenie mu właściwego kierunku.
Aby umieć to zrobić, musi rozumieć
z grubsza tezy Adama.
Uwaga: choć narzędzia rmy „Parasoft”
oferują funkcjonalność, która potrzebna
jest do realizacji „dramatycznego wzrostu
wydajności”, ani książka Kolawy, ani ten
artykuł nie służą ich promocji. Te same
wyniki można osiągnąć przy pomocy narzędzi innych rm lub narzędzi wolnodo-
JAK TO OSIĄGNĄĆ
W PRAKTYCE?
Szczegóły na temat ADP (Automated
Defect Prevention) znajdują się albo we
wspomnianym na początku tekstu artykule „Między biurokracją a chaosem”,
albo w książce Adama Kolawy. ADP
pozwala osiągnąć „dramatyczny wzrost
wydajności” działu IT. Pozwolę sobie
tylko przypomnieć podstawowych sześć
zasad ADP:
• Stworzenie infrastruktury jednoczącej
ludzi i technologię;
• Określenie i zastosowanie dobrych
praktyk;
• Dostosowanie dobrych praktyk do
specyfiki firmy, technologii, produktu
i projektu;
• Pomiary i monitorowanie statusu
projektu;
• Automatyzacja;
• Przyrostowe wdrożenie praktyk ADP.
Oczywiście, same nazwy niewiele mówią.
Dlaczego ADP, a nie – szerzej przecież
znane – ISO 9000 – ISO 9001, Six Sigma,
CMMI, COBIT, ITIL, TickIT, ISO/IEC
12207, Bootstrap, SPICE, ISO/IEC 15504,
TMM, MMAST, TAP, TCMM, TIM, TOM,
TSM, TPI? Dlatego, że są to metody normatywne: wymagają spełnienia szeregu
zasad, a jakość ocenia się na podstawie
zgodności ze standardem, nie z produktywnością. No i wprowadzają masę biurokracji… mało mają wspólnego z regułami
TQM (Total Quality Management)!
stępnych (freeware). Naromiast metodyka
Kolawy – darmowa – jest niezastąpiona.
Wystarczy zakupić książkę, liczącą dużo
mniej niż 200 stron; można ją przeczytać
w jeden wieczór.
Wiele praktycznych doświadczeń
potwierdza (przykłady znajdziemy
w książce), że wzrost wydajności IT
i rmy naprawdę może nastąpić skokowo
– zaskakująco, dramatycznie. Nic nie stoi
na przeszkodzie – oprócz kurczowego
trzymania się przyjętych, tradycyjnych
metod – aby dać swojej rmie dramatyczną, rynkową przewagę nad konkurencją.
Aby, stosując zasady ADP, osiągnąć
umiejętność szybkiego, niezawodnego
tworzenia nowego oprogramowania lub
modykacji już istniejących aplikacji.
Dzięki temu, produkcja oprogramowania
przestanie być hamulcem zmian, a stanie
się – ich nośnikiem.
Bogdan Bereza-Jarociński jest konsultantem w rmie NewQuality, m.in. specjalistą
w zakresie zarządzania projektami, zarządzania ryzykiem i zarządzania jakością,
trenerem biznesu, psychologiem organizacji, informatykiem.
COMPUTERWORLD 31 sierpnia 2010
27
15