Mylenie Procesu i Produktu

czyli "Dlaczego jeszcze nie osiągamy pożądanej jakości".

David A. Cook
Software Technology Support Center
tłumaczył: Darek Cieślak

Od lat Ministerstwo Obrony Stanów Zjednoczonych (DoD) i komercyjne firmy tworzące oprogramowanie popierają model dojrzałości oprogramowania CMM pochodzący od Software Engineering Institute (SEI). Dodatkowo jest wiele organizacji które zamierzają spełnić wymagania ISO 9000 i 9001. Niestety nawet organizacje które spełniły wymagania CMM lub ISO 9001 niekoniecznie produkują oprogramowanie wysokiej jakości. Artykuł omawia wpływ certyfikacji ISO lub CMM na jakość oprogramowania.

Jakość Zdefiniowana

Jakość jest trudna do formalnego zdefiniowania. Jeśli rozpatrywać ścisłą definicję ISO 9001 sugeruje, że jest ona "spełnieniem wymagań". Jest to oczywiście ważne, ale nie wystarczające. Większość programistów wskaże natychmiast że wiele wymagań jest domyślnych często niewyartykułowanych dopóki nie rozpocznie się implementacja systemu. Dodatkowo większości użytkowników zależy na oprogramowaniu niezawodnym (ang. reliable) i solidnym (ang. robust). Oprogramowanie niezawodne robi to co do niego należy i nie robi tego czego nie powinno. Oprogramowanie solidne jest niezawodne ale działa pewnie także w niespodziewanych warunkach. Ponieważ dzisiejsze systemy są duże i złożone (i często muszą pracować w trudnych warunkach gdzie błąd oznacza zagrożenie ludzkiego życia) te systemy powinny być solidne.

CMM i ISO

Niezależnie od tego które kryterium wybierzemy: jakość, niezawodność czy solidność należy się zgodzić z twierdzeniem, że większość (jeśli nie całe) oprogramowanie powinno mieć wyższą jakość. Przed polepszeniem jakości powinniśmy przyjrzeć się bliżej jak oprogramowanie jest tworzone. Jedną z najlepszych prób ostatnich lat jest CMM. Jest on ciągle uznawany przez organizacje które z niego korzystają i wskazuje organizacji praktyki które muszą istnieć by tworzone oprogramowanie było niezawodne.

Wiele organizacji pracujących dla Ministerstwa Obrony Stanów Zjednoczonych osiągnęło trzeci poziom CMM (poziom zdefiniowany). Na tym poziomie procesy zarządzania i typowo inżynierskie są udokumentowane, ustandaryzowane i połączone ze standardowymi procesami organizacji. W efekcie poziom trzeci CMM usuwa konieczność istnienia "superprogramisty" aby organizacja tworzyła "dobry" software. Według Watts-a Humphreya: "Istnieje przekonanie że kilku wysokiej klasy artystów może wykonać dużo lepszą pracę niż typowy zespół programistów. ... Jeśli to była by prawda można by oczekiwać, że organizacje mające najlepszych ludzi nie cierpią na problemy związane z jakością. ... Doświadczenie pokazuje że to nie jest to. (2)" Poziom trzeci CMM próbuje zastąpić superprogramistę poprzez jasne reguły dla wszystkich programistów.

Należy zauważyć, że procesy w organizacji nie są zwykle wystarczające do tworzenia naprawdę dobrego oprogramowania -- oprogramowanie tworzone jest przecież nadal przez ludzi. Tu przychodzi z pomocą Personal Software Process (PSP). PSP stanowi odpowiednik CMM dla poszczególnych programistów -- organizuje proces na poziomie indywidualnym (nie organizacji jak to ma miejsce w przypadku CMM). PSP w połączeniu z CMM zwiększa prawdopodobieństwo wytworzenia produktu wysokiej jakości.

Inną bronią przed złą jakością jest dla niektórych organizacji ISO 9001. Standard ten powinien w teorii dostarczyć produktu wysokiej jakości. Niestety większość ludzi myli system jakości -- czego niewątpliwie dotyczy ISO 9001 -- z produktem wysokiej jakości. Systemy jakości są konieczne do wytworzenia wysokiej jakości produktu ale nie wystarczające (4). W rzeczywistości ISO 9001 nie jest nawet wystarczające dla kompletnego systemu jakości.

W. F. Fightmaster, vice president ds. jakości w firmie Square D: "Są ludzie którzy myślą, że kiedy mają certyfikat ISO 9001 mają system jakości. To jeszcze nie jest całość ale zaledwie jedna siódma (5)" Ciągle faktem jest, że system jakości jest niezbędny jeśli zamierzamy tworzyć produkt wysokiej jakości.

Dlaczego jeszcze nie osiągamy pożądanej jakości

Podsumujmy: mamy narzędzia, które pracują poprawnie. CMM ulepsza proces w organizacji, PSP koncentruje się na procesie jednego programisty, ISO 9001 dostarcza systemu jakości. Pozostaje pytanie: Dlaczego nadal nie widzimy polepszenia jakości ?

Bazując na swoich doświadczeniach mogę wskazać trzy problemy, z którymi sobie nie radzi większość organizacji. Sądzę, że są one oczywiste. Należy je podać bo często te oczywiste są najtrudniejsze do dostrzeżenia i zrozumienia.

• Nie używamy wspólnego kierunku
• Inny proces publikujemy a inny używamy
• Dobre praktyki nie mogą przeważyć złego zarządzania

Dopasuj proces do swoich potrzeb

Prawda numer 1: nie używamy wspólnego mianownika. CMM jest procesem a nie produktem. Osiągnięcie poziomu trzeciego nie jest końcem pracy -- koniec stanowi dopiero wysoka jakość oprogramowania. Pracowałem ostatnio z organizacją która zamierzała zorganizować swoją grupę procesów w celu koordynowania tworzenia oprogramowania (SEPG - software engineering process group). Odnalazła inną organizację mającą już to za sobą i skopiowała prawie bezpośrednio dokumentację. Jeden problem -- organizacja źródłowa miała 300 programistów plus kilka szczebli zarządzania -- podczas gdy w docelowej organizacji pracowało 17 osób. Wyobraźcie sobie 17-to osobową firmę wykorzystującą proces dopasowany do 300-to osobowej firmy. Wielkość dokumentacji z dużej firmy przekonała mnie, że ponad 50% czasu będzie spędzane na zebraniach tyczących SEPG. Organizacja próbowała osiągnąć trzeci poziom CMM ponieważ nie mogli osiągnąć wysokiej jakości aktualnie przeprowadzanym procesem.

Wnioskiem nie jest, że wspólny mianownik nie istnieje. Zapominamy o różnicach pomiędzy produktem (jakość oprogramowania) a procesem (podążanie za wytycznymi CMM). CMM powinno być żywym procesem który w wyniku częstych przeglądów prowadzi organizację do samodoskonalenia. To jest podstawowe założenie CMM. Jednak większość organizacji z którymi pracowałem traktuje dokumenty związane z CMM jako standard. (...) Niektóre organizacje uruchamiają procesy które są nieelastyczne. Nie możemy sobie pozwolić na uruchamianie procesów, które nie będą pracować.

Jako komentarz do braku wspólnego mianownika niedawno opublikowany dokument SEI sygnalizuje pewne problemy z projektami prowadzonymi dla rządu (USA). Zintegrowany zespół procesów nie był zintegrowany -- była część "rządowa" i część "wykonawcy". Dokument ten jest wart przeczytania -- wskazuje gdzie znika wspólny mianownik.

Użyj procesu który pracuje dla ciebie

Inny proces publikujemy a innym się posługujemy. Myślę, że większość organizacji z którymi pracowałem produkowała dobre oprogramowanie ponieważ większość programistów włączyło swoje "obejścia" do systemu. Proce nie pracuje jeśli nie jest modyfikowany. Programiści znajdują sposoby na działanie systemu. To jest argument który używam podczas konsultacji z organizacją: Jeśli programiści nie postępują zgodnie z procesem proces nie działa. Nie oznacza to wcale, że programiści będą automatycznie postępować zgodnie z dobrym procesem. Myślę, że dobrzy programiści mają "defekt genetyczny" który powoduje, że starają się zmieniać system. Mogą powiedzieć kiedy proces będzie lub nie będzie działał i będą postępować zgodnie z procesem jeśli będą przekonani, że przyniesie im korzyści.

W jednej organizacji programiści walczyli z procesem zorganizowanego przeglądu (zobacz: Inspekcje Oprogramowania). Walczyli dopóki nie dostrzegli korzyści wynikających ze zmniejszonej potrzeby poprawiania błędów i lepszej pielęgnowalności w wyniku takich przeglądów. Jeśli programiści ignorują proces, to inny proces jest "na pokaz" a inny w rzeczywistości pracuje. (...)