Zarażeni jakością

Jeżeli przyjrzeć się inżynierii oprogramowania początku XXI w., to można stwierdzić, że ma ona te same przypadłości, na które cierpiała produkcja towarów przemysłowych pół wieku temu: produkty są zawodne, klienci narzekają, na rynku panuje poniekąd dyktat producenta, wiele do życzenia pozostawia obsługa klienta.

Jeżeli przyjrzeć się inżynierii oprogramowania początku XXI w., to można stwierdzić, że ma ona te same przypadłości, na które cierpiała produkcja towarów przemysłowych pół wieku temu: produkty są zawodne, klienci narzekają, na rynku panuje poniekąd dyktat producenta, wiele do życzenia pozostawia obsługa klienta.

Bolączkom świata produkcji przemysłowej udało się zaradzić za pomocą kilku mechanizmów, które określamy nazwą systemy jakości. Koncentrują się one na kilku zagadnieniach. Warto przyjrzeć się im bliżej, zanim zaczniemy się zastanawiać nad jakością systemów informatycznych.

Pierwszym z nich jest powtarzalność. To właśnie wytwarzanie powtarzalnych produktów jest np. podstawowym celem normy ISO 9001. Mówi ona mniej więcej tyle: opisz to, co robisz, a potem postępuj tak jak napisano. Uniwersalność i względnie duży poziom ogólności tej normy pozwalają stosować ją zarówno w typowej produkcji, jak i usługach. Kilkadziesiąt polskich firm informatycznych posiada certyfikat ISO 9001 na proces wytwarzania i dostarczania systemów informatycznych. Dodajmy, że wiele z nich (np. ComputerLand) wokół normy ISO 9001 zbudowało system jakości obejmujący znacznie więcej, niż norma ta rzeczywiście wymaga.

Drugim celem systemów jakości jest zapewnienie takiej sprawności procesów, aby liczba defektów była jak najmniejsza. Normy pochodzące z przemysłu samochodowego, lotniczego i kosmicznego - zastosowane dziś także np. w usługach finansowych lub wytwarzaniu sprzętu audio - stawiają poprzeczkę bardzo wysoko. Słowo kluczowe tej grupy norm to "pięć dziewiątek", czyli sprawność procesów biznesowych na poziomie 99,999%. Taką jakość osiąga się dzisiaj dzięki bardzo dokładnemu sprzętowi pomiarowemu, opomiarowaniu procesu wytwórczego, wyśrubowanym normom materiałowym, złożonym narzędziom kontrolnym i wszechstronnemu testowaniu produktu.

Trzecim wreszcie celem systemów zapewniania jakości jest tworzenie coraz lepszych produktów przez "przesycenie" całego procesu wytwórczego myśleniem o jakości oraz nieustającej poprawie. To właśnie stoi w centrum uwagi TQM. Nieprzetłumaczalne japońskie słowo kaizen opisuje właśnie proces wprowadzania stałych, drobnych innowacji. Przykładem może być historia lampy przedniej w samochodzie marki Toyota: ponieważ była ona symetryczna, w ok. 1% przypadków technik montował ją do góry nogami. Problem rozwiązano, wprowadzając u dołu lampy mały, plastikowy ząbek oraz odpowiadające mu wycięcie w blachach - w ten sposób zaburzono symetrię i reflektor pasował tylko w jedną stronę. Elementem TQM jest też pewna mentalność, zawarta w słowie total: zapewnienie jakości nie jest podejmowane w jednej fazie procesu wytwórczego, a elementem wszystkich, dosłownie wszystkich działań przedsiębiorstwa. Zapewnienie jakości zaś - nie obowiązkiem Działu Kontroli Jakości, a każdego pracownika.

Do jakiego stopnia to działa?

Jednym słowem, zapewnienie jakości w procesach produkcyjnych i usługach jest rzeczą znaną i dobrze opisaną. Na uczelniach tego się uczy, firmy mają odpowiednie metodologie, narzędzia i wiedzę. Dlaczego więc tej filozofii jakości nie zastosować w informatyce? Dlaczego budowanie systemów informatycznych miałoby podlegać innym regułom niż budowa samochodów albo przewóz pasażerów w metrze?

Zacznijmy od problemu skali. Większość procesów zapewniania jakości w środowiskach produkcyjnych i usługowych jest pomyślana jako rozwiązania wielkoskalowe. Sama norma "pięć dziewiątek", czyli najwyżej jednego defektu na sto tysięcy elementów, sugeruje właśnie wytwarzanie setek tysięcy jednakowych elementów lub wykonywanie milionów powtarzalnych czynności. Niestety, takiej skali powtarzalności próżno doszukiwać się w systemach informatycznych. Nie ma przecież miliona identycznych ani nawet podobnych elementów. Skoro mamy normę reprezentowaną jako liczba defektów podzielonych przez jakiś mianownik, to co uczynić mianownikiem tego dzielenia. Liczbę linii kodu? Liczbę funkcji użytkowych systemu? Liczbę miejsc, gdzie programista musiał podjąć istotne decyzje? Każde z rozwiązań ma wady i zalety. Liczba linii kodu różni się w zależności od zastosowanego języka programowania, nie uwzględnia komponentów zewnętrznych użytych w systemie, a na dodatek można nią dość łatwo manipulować. Liczba funkcji użytkowych jest pozornie lepsza, ale nie uwzględnia istotności biznesowej poszczególnych funkcji.

Załóżmy jednak, że udałoby się znaleźć taką miarę. Zestandaryzowanie i opomiarowanie procesu wytwórczego wg tej miary jest dość kosztowne. Niestety, prawdopodobnie przyda się tylko na krótki czas, bo w informatyce technologia za szybko się zmienia. Załóżmy, że jako miarę przyjęto linię kodu i na tej podstawie wytworzono kilka systemów informatycznych. W momencie wejścia narzędzi RAD (Rapid Application Development) budowa pewnych części systemu (np. formatek) radykalnie się uprościła - zamiast pracowicie pisać kod, można go dziś projektować na ekranie. Normy i aparat pomiarowy powinny to odzwierciedlić, by nie przekłamywać danych. Firma, która zainwestowała w system jakości, znajduje się więc w punkcie wyjścia. Musi dokonać wyboru iście salomonowego: albo wyda ponownie mnóstwo pieniędzy na zbudowanie nowego systemu jakości, albo pozostanie przy starej technologii - z całym ryzykiem, które temu towarzyszy.

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

TOP 200