piątek, 10 lutego 2017

Miary jakości w IT

"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."
  • Andrzej Kobyliński "Modele jakości produktów i procesów programowych", Warszawa 2005, SGH w Warszawie, ISSN 0867-7727 [nakład wyczerpany]
Napisałem to w... 2005 roku. Nadal aktualne, może nawet bardziej niż wtedy, bo szarlataneria, zastępująca dobre miary wiedzą tajemną i społeczną wyczuwką wciąż nabiera śmiałości i tempa.
 
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!
      

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 metody 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 - 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 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 w 2005 roku 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".
 
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.

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

Brak komentarzy:

Prześlij komentarz