Książkę Andrzeja Kobylińskiego można polecić inżynierom jakości i testów, bo przecież testy są jednym z najważniejszych narzędzi pomiarowych w IT.

Miary często kojarzą się nam z czymś pozytywnym: mówi się umiarkowany, miarkować, znać miarę, na miarę czy miarowo. Z drugiej strony, brak miary też chwilami brzmi obiecująco, jak w słowie bezmierny. Miary są niebezpieczne dla tych, którzy usiłują coś ukryć, wolą mętniactwo i niejednoznaczność od precyzji. Miary trzeba dobrze rozumieć, tak więc niektórym ludziom miary wydają się niebezpieczne; według Flawiusza to Kain wynalazł "miary i wagi, zmienił ową niewinną i szlachetną prostotę, w jakiej żyli ludzie, póki ich nie znali, w życie pełne oszustwa" (Józef Flawiusz, "Starożytności żydowskie"). Miary, które znamy na co dzień, wydają się oczywiste, ale nie ma nic oczywistego w tym, aby od prostego "zimno", "średnio" i "ciepło" przejść do skal, gdzie wartości liczbowe przypisywane temperaturze powietrza odnoszone są do długości słupka rtęci zamkniętej w szklanej rurce. Fakt, że istnieją trzy różne, powszechnie stosowane skale temperatury: Fahrenheita, Celsjusza i Kelvina, z których każda ma punkt zerowy przy innej temperaturze, a dwie pierwsze różnią się rozmiarem jednostki skali, wskazuje, że miary nie są niczym oczywistym, że są przyjmowanym częściowo arbitralnie sposobem odwzorowania natężenia pewnych atrybutów rzeczywistości - brzmi to wszystko bardzo naukowo, ale ma konkretny, praktyczny sens.

Inżynieria - zestaw zdefiniowanych, powtarzalnych technik projektowania, wytwarzania i utrzymania rozmaitych rzeczy, nie może istnieć bez pomiarów. Trudno wyobrazić sobie inżyniera, który nie umie mierzyć długości, ciężaru, napięcia czy natężenia, albo lekarza bez termometru i narzędzi do precyzyjnego pomiaru chemicznego składu krwi. Tymczasem tylko inżynieria oprogramowania choruje na brak umiejętności pomiaru nie tylko własnych procesów, ale nawet produktów!

Nie można zmierzyć

Zapyta ktoś - jakie to ma znaczenie? Czyżby coś bardzo złego działo się z przemysłem informatycznym, podczas gdy gołym okiem widać, że dzieje się całkiem dobrze?

Wiele zależy od tego, w odniesieniu do czego jest to "dobrze". W porównaniu z przemysłem elektronicznym przyrost wydajności w produkcji oprogramowania jest od wielu lat skromny. Produkty programistyczne często okazują się zawodne, a spektakularne niepowodzenia projektów informatycznych - jak np. osławione dwuletnie opóźnienie oddania do użytku lotniska w Denver w 1995 r. z powodu przekroczenia terminu dostawy oprogramowania systemu bagażowego - przechodzą do legendy. Wielkie jest zróżnicowanie produktywności programistów w różnych firmach i projektach - według niektórych danych różnice wynoszą nawet 600:1 (słownie: sześćset do jednego, to nie jest błąd w druku).

"Nasze najnowsze techniki gwarantują 100% wzrostu produktywności", "użycie narzędzi pozwoli skrócić testowanie o 2/3" - przykłady gołosłownych twierdzeń i sloganów w branży IT można dowolnie mnożyć. Czego nam brakuje, by móc przeciwstawić wiedzę próbom manipulacji? Systematycznego stosowania pomiarów i dostępu do ich wyników.

Planowanie projektów informatycznych okazuje się w praktyce niejednokrotnie zwykłym wróżeniem z fusów. Jak oszacować pracochłonność projektu produkcji oprogramowania, którego wymagania są opisem słowno-muzycznym? Niełatwo na takiej podstawie oszacować wielkość produktu, np. w formie liczby linii kodu, a nawet mając do dyspozycji takie oszacowanie, nie ma prostej i godnej zaufania metody, aby przełożyć je na liczbę koniecznych "osobodni".

Brak umiejętności mierzenia powoduje, że jakiekolwiek dyskusje porównujące zalety i wady różnych metod, technik, języków programowania i modelowania cierpią na chroniczną dowolność, na odwoływanie się do anegdotycznych, statystycznie nieistotnych przykładów. Nie umiejąc mierzyć przebiegu projektów, nie umiemy na dobrą sprawę nimi zarządzać. Intuicja, objawienia, i-cing - wszystko to bardzo ciekawe metody, wszakże pod warunkiem, że uzupełniają proces decyzyjny i przewidywania oparte na pomiarach, a nie usiłują je zastępować.

Zarządzanie ryzykiem staje się fikcją, jeśli ani nie potrafimy zagrożeń zidentyfikować, ani oszacować kosztów zapobiegania, ani ocenić ich prawdopodobieństwa. W opublikowanym niedawno na tych łamach artykule napisałem, że "w przemyśle informatycznym chętnie udajemy Kierowców Formuły 1 oraz dzielnych Przewodników, nie mając niezbędnych po temu umiejętności mierzenia".

Jak nauczyć się trudnej sztuki wykonywania i analizy wyników pomiarów? Jak nie dać się w przyszłości zagadać elokwentnym zwolennikom Jedynie Słusznej Drogi, czy będzie nią czysty Brak Procedur, czy ISO 9000, czy CMM, czy cokolwiek innego?

Doskonałym, praktycznym przewodnikiem jest wydana pod koniec ub.r. książka dr Andrzeja Kobylińskiego z SGH pod niezbyt chwytliwym marketingowo tytułem "Modele jakości produktów i procesów programowych" - pewnie lepiej byłoby ją nazwać "Informatyk mierzy".

Książka o mierzeniu

Pierwszą podstawową zaletę omawianej książki dla praktyków informatyki stanowi jej przystępność. Choć jest to pozycja akademicka, zarówno jej język, jak i zorientowany na praktyczne potrzeby tryb wykładu umożliwiają skuteczną lekturę także osobom mającym głównie praktyczne doświadczenia informatyczne.

Jakość to pojęcie kluczowe dla praktyki informatycznej, a mimo to niebezpiecznie niejednoznaczne. Choć definicji jakości jest wiele, a każda zasługuje na osobną monografię, istnieje przecież duża, niezaspokojona potrzeba jednoznacznego określenia jakości w ten sposób, by móc ją mierzyć, oceniać, porównywać, zapisywać w kontraktach i wymaganiach. Książka traktuje także o jakości produktu. Omawia atrybuty jakości, zależności między nimi oraz sposoby ich pomiarów. To tematyka o dużym znaczeniu dla wszystkich udziałowców projektu informatycznego. Niedostatki wiedzy na ten temat powodują, że klienci niejasno i niepoprawnie określają swoje wymagania, analitycy systemowi sporządzają niepełne modele, inżynierowie jakości mają problemy z jednoznaczną oceną jakości gotowego lub budowanego właśnie produktu.

Jeśli w projektach zdarzają się kłopoty, próbuje się je rozwiązywać, usprawniając procesy i procedury. Jest wiele różnych modeli dotyczących tego jak postępować, by określić i wdrożyć usprawnienia, a każdy z nich ma swoich zwolenników i przeciwników. Czym się od siebie różnią, który najlepiej pasuje do naszych potrzeb? Nie są to czcze pytania. Zmienia się środowisko, w którym firmom przychodzi działać i konkurować, więc firmy muszą także zmieniać się, by sprostać nowym wyzwaniom. Różne są przyczyny i cele zmian, a udoskonalenie sposobu pracy jest jednym z ważniejszych. Po to, aby zmniejszyć ryzyko niepowodzenia, trzeba sprawnie przeprowadzić analizę możliwej zmiany oraz skutecznie zrealizować jej wdrożenie. W książce znajdziemy zarówno przegląd istniejących, znanych metod oceny i doskonalenia procesów, jak i porównanie wynikających z nich korzyści oraz zagrożeń.

Tematyka budząca spore emocje, a przy tym znacząca dla powodzenia projektów oraz firm, to kwestia relacji między udoskonalaniem procesów a jakością produktów. Każdy pewnie słyszał sarkastyczne historyjki o wdrożeniach certyfikatów ISO 9000, wymagających jakoby jedynie naklejenia karteczek z nazwą na wszystkie znajdujące się w firmie przedmioty, mnożących zbędną papierologię i nieprzekładających się w żaden sposób na jakość produktów. Na przykład znany guru, Tom DeMarco, jest sceptycznie usposobiony do korzyści płynących z osiągania wyższych poziomów CMM twierdząc, że prowadzi to wyłącznie do polepszenia chwilowej sprawności kosztem zmniejszenia elastyczności i utraty strategicznej efektywności.

Bogdan Bereza-Jarociński, mailto:[email protected] , jest założycielem i kierownikiem Centrum Jakości Oprogramowania bbjTest (http://www.bbjtest.com ).

Andrzej Kobyliński "Modele jakości produktów i procesów programowych", Warszawa 2005, SGH w Warszawie, ISSN 0867-7727