www.eprace.edu.pl » iso-cmm » CMM » Osobiste zaangażowanie w jakość oprogramowania

Osobiste zaangażowanie w jakość oprogramowania

Model CMM został zaprojektowany z myślą o dużych i średnich organizacjach. Poniższy podrozdział wynika z modelu CMM i prezentuje zasady jakości wynikające z tego modelu w odniesieniu do projektów małych i pracy indywidualnej.

Jeżeli chcemy mieć wysokiej jakości system software’owy, musimy zapewnić wysoką jakość dla każdej jego części składowej. Strategia osobistego procesu tworzenia oprogramowania (Personal Software Process, PSP) koncentruje się na utrzymywaniu defektów powstałych w produkowanym oprogramowaniu. Udoskonalając zarządzanie defektami, otrzymujemy komponenty bardziej konsystentne i niezawodne. Te komponenty mogą po kolei być łączone w progresywnie coraz to wyższej jakości złożone systemy.

Ta strategia przynosi korzyści nie tylko dla jakości, ale w jeszcze większym stopniu dla produktywności. Generalnie w przypadku oprogramowania produktywność maleje wraz ze wzrostem rozmiaru produktu [Boehm 78]. Jednym z powodów tego zachowania jest to, że większy rozmiar produktu pociąga za sobą większy nakład pracy. Innym, jeszcze ważniejszym powodem jest jakość części składowych produktu. Wraz z powiększaniem się produktu zwiększa się złożoność logiczna, a to powoduje, że usuwanie błędów jest coraz trudniejszym zadaniem. Co za tym idzie, bardziej rozbudowany proces usuwania błędów zabiera więcej czasu w fazie testów.

Jeżeli produkujemy części posiadające bardzo wysoką jakość, nasz proces proporcjonalnie skaluje się (powiększa się) z mniejszą redukcją produktywności. Dzieje się tak, ponieważ dodajemy nowe elementy do powiększającego się wciąż produktu. Zajmujemy się jedynie testowaniem jakości nowych elementów. Podczas występowania problemów związanych z interfejsem, testowanie odbywa się jedynie w obrębie ściśle zlokalizowanych obszarów. Odtąd utrzymujemy produktywność typową dla małych programów przy rozwijaniu większych programów. Widzimy zatem, że dbając o wysoką jakość produktu, oszczędzamy wiele pracy w fazie testowania i powtórnego projektowania. Aby poprawić jakość produktu, musimy poprawić jakość procesu. Dokonanie tego wymaga pomiaru i śledzenia jakości procesu. Podczas przeprowadzania procesu tworzenia oprogramowania zbieramy wiele danych, których możemy używać do oszacowania jakości naszego procesu.

Czym jest jakość oprogramowania?

Zasadniczym punktem jakiejkolwiek definicji jakości oprogramowania powinny być potrzeby użytkownika. Jakość jest czasami definiowana jako „zgodność z wymaganiami” („conformance to requirements”) [Crosby 79]. Można by debatować rozróżniając pomiędzy wymaganiami i potrzebami, ale definicja jakości musi uwzględnić punkt widzenia użytkownika. Zatem kluczową kwestią będzie: kto jest użytkownikiem, co jest istotne dla użytkowników i jak ich priorytety mają się do tworzenia nowych produktów.

Jakość produktu

Aby odpowiedzieć na to pytanie, musimy pamiętać o hierarchicznej naturze jakości oprogramowania. Po pierwsze, produkt software’owy musi dostarczać funkcji (funkcjonalności) takich, jakich potrzebuje użytkownik. Jeśli tego nie spełnia, wszystko pozostałe staje się nieistotne. Po drugie, produkt musi działać. Jeżeli ma on na tyle dużo defektów, że nie może działać w sensowny sposób, użytkownik nie będzie go używał nie bacząc na inne atrybuty. Nie znaczy to, że defekty mają zawsze najwyższy priorytet, ale mogą być bardzo istotne. Musi zostać osiągnięty poziom błędów minimalnych. Powyżej tego progu jakości defekty, kompatybilność i funkcjonalność zależą od użytkownika, samej aplikacji i środowiska, w którym się znajdujemy.

Jakość szeroko rozumiana, widziana przez użytkowników, musi odnosić się do łatwości instalacji produktu, sprawności operacyjnej i wygody. Czy produkt będzie działał na zamierzonym systemie, czy aplikacje będą przeprowadzać wymagane operacje na plikach? Czy produkt jest wygodny, czy użytkownicy pamiętają, jak go używać, czy mogą łatwo się dowiedzieć, co powinni umieć? Czy produkt odpowiednio reaguje, czy zaskakuje użytkowników, czy ich chroni przed ich błędami i czy ich oddziela od systemowych mechanizmów operacyjnych? Te pytania (i cały szereg innych) są znaczące dla użytkowników. Co pewien czas priorytety będą się zmieniać wśród użytkowników, a jakość ma wiele warstw (poziomów) i nie ma jednej uniwersalnej definicji, która by stosowała się do każdego przypadku. Jeśli oprogramowanie nie spełnia wymagań użytkownika tylko w jednej znaczącej kwestii, będzie on sądził, że produkt jest niskiej jakości.

Niestety nie wszyscy zastanawiają się nad tymi punktami i ich działania nie są zgodne z tymi priorytetami. Dlatego wiele czasu i wysiłku powinno wkładać się w pracę nad stabilnością, użytecznością i sprawnością operacyjną produktu.

Jeżeli jakość części składowych jest niska, wtedy niepotrzebnie poświęca się czas i uwagę w ramach procesu tworzenia oprogramowania na znajdowanie i naprawianie błędów. Rozmiary tego zjawiska (procesu naprawczego) są zaskakujące. W wyniku tego cały zespół projektowy jest zbyt zaabsorbowany naprawą błędów, a bardziej istotne sprawy są ignorowane. Kiedy zespół projektowy musi walczyć z błędami w fazie testowej, pojawiają się też zazwyczaj problemy z planami. Naciski na dostarczenie produktu w terminie stają się tak silne, że zapomina się o wszystkich innych ważnych sprawach pracując intensywnie nad naprawą ostatnich błędów. Kiedy ostatecznie produkt zaczyna działać i przejdzie przez fazę testów systemowych, każdy czuje się uwolniony od ciężaru produktu. Jednak przez takie naprawianie krytycznych błędów systemowych, produkt osiąga tylko minimalny i podstawowy próg jakości. Co zostało zrobione, aby zapewnić użyteczność, co z kompatybilnością i mocą? Czy ktokolwiek sprawdził, czy dokumentacja jest zrozumiała i czy projekt nadaje się do przyszłych udoskonaleń? Okazuje się najczęściej, że zespół projektowy był tak zajęty naprawą defektów, nie miał czasu albo środków, aby zająć się sprawami zasadniczo ważnymi dla użytkowników.

Poprzez gwałtowne obniżenie ilości błędów w małych programach możemy więcej uwagi poświęcić na ważniejsze aspekty jakości oprogramowania. Tak więc jakość produktu i jakość procesu idą ze sobą w parze. Jeśli produkt niskiej jakości wejdzie w fazę testów, oznacza to zazwyczaj, że proces rozwoju nie zakończy się w uzgodnionym czasie i nie zmieści się w kosztach. Inaczej mówiąc niskiej jakości proces produkuje niskiej jakości produkt.

Pomimo, że defekty oprogramowania są tylko jednym aspektem jakości oprogramowania, poświęcamy im wiele uwagi. Nie oznacza to, że ich kontrolowanie powinno być najwyższym i jedynym priorytetem, ale że efektywne zarządzanie defektami stanowi fundament, na którym można zbudować pełną strategię jakości. Defekty mogą pochodzić z różnych źródeł, ale z niewielką liczbą wyjątków są one wynikiem błędów jednostek. Zatem, aby odpowiednio zająć się defektami i błędami, które je powodują musimy uporać się z defektami na poziomie podstawowym. Tam błędy są popełniane, tam należy ich szukać i tam je naprawiać.

Ekonomia jakości oprogramowania

Jakość oprogramowania można też rozpatrywać jako kwestię ekonomiczną. W dużych systemach zazwyczaj każdy nowy test ujawnia całe mnóstwo defektów. Z drugiej strony, każdy test wymaga nakładu pracy, czasu i pieniędzy. Wciąż można dokonywać nowych testów i inspekcji i trudno jest stwierdzić, kiedy zaprzestać testowania. Ekonomika jest więc istotną kwestią jakości nie tylko z powodu powyższej decyzji, ale także z powodu potrzeby optymalizacji kosztów cyklu życia jakości. Nie ulega wątpliwości, że produkt musi być poddany testom, zanim zostanie wypuszczony.

Koszt znajdowania i naprawy defektów

Ekonomika jakości oprogramowania dotyczy w dużym stopniu kosztów detekcji defektów, ich prewencji i usuwania. Koszt znajdowania i naprawy błędów zawiera koszt każdego z poniższych elementów:

Chociaż nie każda naprawa pociąga za sobą wzrost kosztu wszystkich elementów, to jednak im dłużej defekt tkwi w produkcie, tym większej liczby elementów będzie dotyczyła ta naprawa. Odkrycie problemu wymagań w testach może być bardzo kosztowne. Natomiast znalezienie defektu kodu podczas przeglądu kodu będzie kosztowało stosunkowo niewiele. Dlatego celem powinno być usuwanie defektów z fazy wymagań, projektu i kodowania najwcześniej, jak to możliwe. Przeglądy i inspekcje programów natychmiast po ich wyprodukowaniu minimalizują liczbę defektów w produkcie w każdej fazie. Minimalizuje to również powtórny nakład pracy.

Oto przykładowe dane zaczerpnięte z firmy IBM:

Względny koszt rozpoznania defektów oprogramowania: podczas projektów: 1.5; przed kodowaniem: 1; podczas kodowania: 1; przed testowaniem: 10; podczas testów: 60; w użyciu: 100.

Względny czas rozpoznania defektów: podczas przeglądów projektu:1; podczas inspekcji kodu: 20, podczas testów maszynowych: 82. [Remus]

Widać wyraźnie, że koszty rozpoznania defektów są najwyższe podczas testów i podczas użytkowania produktu. Jeśli chcemy zatem zredukować koszt rozwoju lub czas rozwoju produktu powinniśmy skoncentrować się na usunięciu defektów przed rozpoczęciem testów.

Dostępnych jest sporo danych dotyczących kosztów znajdowania defektów, natomiast mało jest danych dotyczących efektywności inspekcji i przeglądów oprogramowania. To znaczy, że jeśli dokonujemy przeglądu produktu software’owego, który zawiera 100 defektów, jak wiele z nich zostanie wykryte? Wielkość tą, czyli procent wykrywalności defektów będziemy nazywać yield. Nie istnieją opublikowane dane na ten temat, ale posługując się danymi z IBM typowa wartość parametru yield zawiera się pomiędzy 60 a 80 procent. Dla dużych systemów wartość ta będzie bliższa 60 procentom, natomiast dla mniejszych przedsięwzięć może sięgać 80 procent. Można by zatem spytać, dlaczego nie dokonujemy więcej przeglądów i inspekcji? Są dwa tego powody. Po pierwsze, niewiele organizacji posiada niezbędne dane, aby sporządzić daleko idące plany. Ich plany często opierają się na domysłach i przypuszczeniach. Założenia te są często mało realistyczne. Gdy dochodzi już do ich dokładnej projekcji, w środowisku inżynierskim szybko narasta stres i presja i dochodzi do okresowego kryzysu. Nikt nie ma czasu myśleć, gdyż wszyscy zajmują się testowaniem, wykrywaniem i naprawą błędów.

Po drugie yield nie jest właściwie zarządzany. Bez dyscypliny procesu tworzenia oprogramowania inżynierowie nie posiadają danych o powstających defektach i o kosztach ich znajdowania i usuwania. W ten sposób rzadko oceniają dużych rozmiarów koszty, których można by uniknąć znajdując i usuwając defekty przed fazą testów.

Miary procesu

Juran opisuje miary jakości jako sposób „wyznaczenia rozmiaru problemu jakości tak, aby miał on wpływ na wyższe kierownictwo” [Juran 89]. Koszt jakości składa się z trzech komponentów: koszt awarii, koszt wyceny i koszt prewencji. Definicje tych komponentów kosztu jakości podane są poniżej:

W przypadku dużych projektów powinniśmy zebrać dokładniejsze dane o kosztach jakości poszczególnych komponentów. Na przykład, koszt oceny powinien obejmować koszt prowadzenia testów nawet w przypadku braku występowania defektów. Podobnie, koszty naprawy defektów wykrytych podczas przeglądów i inspekcji powinny zostać potrącone z kosztów oceny i wliczone do kosztów awarii. Juran klasyfikuje przeglądy projektu jako koszty prewencji, ale w przypadku oprogramowania wydaje się bardziej sensownym zaliczyć zarówno przeglądy projektów, jak i inspekcje do kosztów oceny. Natomiast koszty rozwoju większości prototypów, zebrań nad analizą, działania udoskonalające proces powinny być raczej zaliczone do kosztów prewencji.

Podsumowanie

Pierwotne przyczyny rozwinięcia osobistego procesu tworzenia oprogramowania (PSP) wywodzą się z zastosowania Capability Maturity Model. Uważa się, że model CMM jest zaprojektowany z myślą o dużych organizacjach i nie jest jasne, jak może być zastosowane do małych projektów. Mimo, że CMM stosuje się zarówno do dużych i małych organizacji, to PSP można traktować jako wskazówkę i poradę w odniesieniu do mniejszych zespołów projektowych.

Można się zastanawiać, dlaczego środowiska programistyczne tak trudno adoptują dowiedzione już zasady jakości. Prawdopodobnie dlatego, że powyższe metody są trudne do wprowadzenia i nie są intuicyjnie oczywiste. Bez przekonujących dowodów niewielu inżynierów wierzy, że bardziej wydajne jest znajdowanie defektów przez przeglądy kodu niż przez testowanie i debagowanie. Strategia PSP zajmuje się tym problemem demonstrując to inżynierom na ich własnych danych. Wynika to z zastosowania zasad CMM na gruncie projektów małych i pracy bardziej indywidualnej. Strategia PSP zwiększa zarówno jakość, jak i produktywność pracy i jest z powodzeniem stosowana przez inżynierów m.in. Hevelet Packard, Digital Equipment Corporation, Advanced Information Services Corporation.



komentarze

Copyright © 2008-2010 EPrace oraz autorzy prac.