Jak osiągnąć trwały wzrost produktywności w IT?

Jak osiągnąć trwały wzrost produktywności w IT?
Branża IT od początku swego istnienia, od ponad sześćdziesięciu lat, boryka się z
problemem, jak osiągnąć większą skuteczność i sprawność projektów, budujących
oprogramowanie i systemy informatyczne. Kiedy wzrost złożoności tworzonych aplikacji
spowodował, że rzemieślnicze i chwilami chaotyczne metody, powszechnie stosowane w
latach czterdziestych i pięćdziesiątych ubiegłego wieku, przestały wystarczać, uświadomiono
sobie potrzebę systematyczności i pod koniec szóstej dekady tego stulecia powstała
nieznana wcześniej dziedzina, nazwana i n ż y n i e r i ą
o p r o g r a m o w a n i a . Pojawiły się liczne standardy, usiłujące uregulować tę
niesforną branżę i zapewnić projektom informatycznym solidny nadzór oraz większą
przewidywalność i precyzję realizacji. Takie podejście pozostawało jednak w sprzeczności z
potrzebami elastyczności i kreatywności przedsięwzięć, więc na przełomie tysiącleci,
równolegle z wybuchowym rozwojem technologii internetowych, coraz wyraźniej ujawniał
się nurt przeciwny, dochodzący do głosu w metodykach zwinnych, w lean, w
programowaniu ekstremalnym.
IT rozwijało się i nadal rozwija nierównomiernie. Najszybciej idzie do przodu ewolucja
platformy sprzętowej, której wydajność rośnie równie szybko, jak prędko maleją jej koszty,
zgodnie z prawem Moore’a. Równie wyraźny, choć wolniejszy, rozwój nastąpił też w
obszarze niektórych technologii programistycznych: pojawienie się języków strukturalnych,
a potem obiektowych, zrewolucjonizowało pracę programistów. Stworzenie interfejsu
graficznego oraz środowisk zintegrowanych ogromnie ułatwiło pracę zarówno twórcom
programów, jak i ich użytkownikom, a WWW skutecznie obaliło szereg barier dostępu do
informacji oraz komunikowania się ludzi ze sobą.
Natomiast nie sposób mówić o równie jednoznacznym postępie w dziedzinie metod
tworzenia oprogramowania i realizowania przedsięwzięć IT. Mamy tutaj do czynienia raczej
z poruszaniem się w kółko, gdzie kolejne mody, oferujące pod coraz to nowymi nazwami te
same, od lat znane i nie całkiem skuteczne recepty, są bardziej wyrazem naszej bezradności
niż autentycznego wzrostu.
Inżynieria oprogramowania bardzo się zróżnicowała w ciągu ponad czterdziestu lat swego
istnienia, ponadto obrosła wieloma metodami i narzędziami, które jednak nie przekładają
się na nie budzący wątpliwości wzrost produktywności. Wydawać się może niekiedy, że
wzorem gałęzi humanistycznych bardziej, niż autentycznie inżynierskich, bawimy się
nowymi prądami, tworzeniem nowych terminów i pseudo-nauk, nie przejmując się
nieskutecznością tych działań.
Popatrzmy, co dzieje się na obszarze IT, co cieszy się szczególną popularnością, a może uda
nam się określić jakiś wspólny mianownik tych aktywności?
Przede wszystkim, ogromną popularnością cieszy się zarządzanie projektami IT, czego
wyrazem – między innymi – jest przekraczająca już dwa miliony na świecie, liczba osób
mających rozmaite certyfikaty (IPMA, PMI, PRINCE2) w tym obszarze.
Kierunki, ku którym studenci kierunków informatycznych i ekonomicznych dążą, niczym
pszczoły do miodu, to BI (Business Intelligence) oraz jej podstawa – Big Data. Modna jest
analiza biznesowa (w obydwu często spotykanych znaczeniach: analizy danych oraz analizy
procesów przedsiębiorstwa), dużo się słyszy o ładzie korporacyjnym, o zgodności, o DevOps
i oczywiście o wszystkim, co ma w nazwie słowo agile lub lean. Po stronie bardziej
technicznej, tematy na czasie to – oprócz wymienionych wcześniej Big Data – architektura
korporacyjna oraz architektura oprogramowania, bezpieczeństwo informacji, platformy
mobilne, języki programowania (Java, Phyton, Ruby), chmura obliczeniowa i wszelkie
realizowane w niej usługi – zwłaszcza w technologii usług internetowych (web services).
Popularne – przynajmniej w porównaniu z sytuacją sprzed lat dziesięciu – stało się też
testowanie i służące do niego narzędzia.
Nie zapominajmy także o uwarunkowaniach prawnych sektora IT – wiele kancelarii
prawniczych specjalizuje się w umowach, zwanych niepoprawnie, ale powszechnie,
umowami wdrożeniowymi. Specjaliści od łączenia ognia i wody, czyli potrzeb IT z regułami
prawa o zamówieniach publicznych, też nie narzekają na brak zleceń.
Wreszcie, nie wolno przeoczyć mniej widocznego, ale wciąż rosnącego przemysłu systemów
wbudowanych i krytycznych dla bezpieczeństwa. Nie cieszy się taką hałaśliwą popularnością
jak aplikacje mobile oraz oprogramowanie i portale internetowe, ale ma w gruncie rzeczy
większe od nich znaczenie – zarówno biznesowe, jak i dla jakości życia użytkowników, nas
wszystkich.
Poszukajmy teraz wspólnego mianownika. Przykładowo, tematyka architektury cieszy się
wielkim zainteresowaniem, i jest – zgadzamy się - bardzo ważna. Co decyduje o kształcie jej
rozwiązań? Przyjrzyjmy się rysunkowi poniżej:
Rysunek 1. Wymagania wobec architektury na różnych poziomach
Rysunek powyżej pokazuje, że aby zaprojektować, stworzyć i utrzymywać architekturę,
konieczne są w y m a g a n i a d o t y c z ą c e a r c h i t e k t u r y ;
podobnie, jak w celu zbudowania każdego, choćby najmniejszego kawałka oprogramowania,
niezbędne jest określenie dla niego trafnych wymagań.
Wymagania i zbudowane na ich podstawie systemy służą realizacji c e l ó w
b i z n e s o w y c h , których trafne określenie jest możliwe z wykorzystaniem analizy
danych oraz analizy biznesowej.
Podobną argumentację można przeprowadzić dla każdego z wyżej wymienionych,
kluczowych i cieszących się szczególną popularnością obszarów IT. Wymagania, a dokładniej,
specjalizująca się w ich pozyskiwaniu i analizie i n ż y n i e r i a w y m a g a ń , jest
zwornikiem, łączącym ze sobą rozmaite dyscypliny, wchodzące w skład projektu
informatycznego.
Nic więc dziwnego, że inżynieria wymagań jest w standardzie ISO/IEC/IEEE 29148:2011
nazwana d z i e d z i n ą i n t e r d y s c y p l i n a r n ą , łączącą w sobie trzy
główne składowe przedsięwzięć IT: biznes, technologię oraz procedury zarządzania:
Rysunek 2. Rola inżynierii wymagań, jako dziedziny interdyscyplinarnej
Z przyczyn, których roztrząsanie, choć pouczające, mija się z celem, świadomość roli
inżynierii wymagań jest w tej chwili niepełna i rozproszona w innych dziedzinach:
Rysunek 3. Jak często rozumiana jest inżynierii wymagań
Inżynieria wymagań jest rozumiana właściwie, czyli jako j e d n a ,
i n t e r d y s c y p l i n a r n a d z i e d z i n a (rysunek 2), głównie w firmach,
tworzących oprogramowanie wbudowane: sprzęt elektroniczny, pojazdy szynowe,
samochody, sprzęt medyczny, urządzenia lotnicze, roboty przemysłowe, uzbrojenie,
systemy zarządzania procesem produkcyjnym. W świecie IT natomiast dominuje
postrzeganie rozproszone (rysunek 3): o wymaganiach mówi się wiele w ramach zarządzania
projektami, dużo – na konferencjach programistycznych, bardzo dużo – w świecie agile, ale
nie dostrzega się odrębnej dziedziny i n ż y n i e r i i
mianownika tych zagadnień.
w y m a g a ń , jako wspólnego
Czy jest o co kruszyć kopie, czy nie jest to sprawa akademicka, może wręcz prestiżowa? Otóż
nie, takie rozproszone widzenie wymagań jest główną przyczyną większości niepowodzeń,
jakie chronicznie dotykają naszą branżę. Przykładowo, według „Chaos Report”,
opublikowanego przez Standish Group, jako przyczynę niepowodzeń projektów
informatycznych na pierwszych miejscach wymienia się: niepełne wymagania, błędne i
niepełne specyfikacje wymagań, brak zaangażowania użytkowników oraz zmiany wymagań i
specyfikacji.
Wniosek? Wyniki wręcz natychmiastowe daje uzyskanie przez wszystkich interesariuszy
projektów, zarówno po stronie zamawiającego, jak i wykonawcy, systematycznej i
uporządkowanej, podstawowej wiedzy z inżynierii wymagań, niezależnie od już posiadanej
wiedzy z innych dziedzin oraz praktycznych umiejętności. Utrzymanie uzyskanej w ten
sposób przewagi możliwe jest, jeśli stopniowo i systematycznie udoskonala się własne
praktyki w tym obszarze. Zarówno tę potrzebę, jak i tę możliwość, dostrzeżono około
dziesięciu lat temu w kręgu czołowych firm niemieckich oraz szwajcarskich, skąd wyszła
inicjatywa stworzenia dostosowanego do wymogów branży IT systemu wiedzy, oraz
osadzonego w niej systemu szkoleń i certyfikacji, dla inżynierii oprogramowania.
Tak powstała w 2006 roku IREB – International Requirements Engineering Board
(Międzynarodowa Rada Inżynierii Wymagań), oraz jej, zapisany w formie sylabusów, system
certyfikacji CPRE - Certified Professional in Requirements Engineering (Certyfikowany
specjalista inżynierii wymagań).
Dziś w skład IREB wchodzi kilkudziesięciu fachowców, zarówno z przemysłu, jak i z uczelni:
właścicieli i dyrektorów firm, wykładowców, profesorów z całego świata. W przeciwieństwie
do niektórych innych modnych certyfikatów, kwalifikacje, dorobek i osiągnięcia członków
IREB można precyzyjnie zweryfikować (ireb.org/en/board.html). Certyfikaty – zarówno
sylabusy, jak i egzaminy – dostępne są w kilkunastu językach, a blisko 18.000 certyfikatów
uzyskali już specjaliści z kilkudziesięciu krajów. Egzaminy odbywają się zgodnie z ISO/IEC
17024:2012 naprawdę, a nie tylko formalnie, co gwarantuje ich uczciwość, bezstronność i
wysoki prestiż.
Dzisiaj po polsku dostępny jest certyfikat podstawowy (IREB CPRE Foundation), trwają prace
nad kolejnymi (ireb.org/en/international/polski).
Rysunek 4. Układ systemu certyfikacji inżynierii wymagań IREB CPRE
CTS oferuje w okresie od 23 października do 4 grudnia 2014 cykl bezpłatnych warsztatów
on-line, wprowadzających w tematykę inżynierii wymagań, oraz certyfikacji IREB CPRE:
cts.com.pl/Aktualnosci/Inzynieria-wymagan---jak-skutecznie-i-sprawnie-zarzadzacprojektami-IT-.
Bogdan Bereza, [email protected]