Procedury chronią przed skutkami błędów

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.

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ę"...

28 stycznia 1986 r.: w 73 sekundzie lotu promu kosmicznego Challenger 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 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.

Inżynieria wymagań - splot słoneczny IT

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 - 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!

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 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 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

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.

W celu komercyjnej reprodukcji treści Computerworld należy zakupić licencję. Skontaktuj się z naszym partnerem, YGS Group, pod adresem [email protected]

TOP 200