2000-06-14

Piotr Kania

[e-mail]

20. Zarządzanie jakością projektu informatycznego

Rozdział 1: Zarządzanie jakością projektu

Pesymista mówi, że szklanka jest w połowie pusta, optymista, że jest do połowy pełna a specjalista do spraw jakości, że dwa razy za duża.

Jakość jest to obecność pożądanych charakterystyk i nieobecność niepożądanych charakterystyk w produkcie lub procesie [2],

Jakość produktu składa się z:

• cech wyróżniających dany produkt od innych,

• czasu potrzebnego na wykonanie produktu,

• kosztów jego wytworzenia,

Zarządzanie jakością projektu element zarządzania projektem. Jest to proces wymagany w celu zapewnienia, że

opracowywany projekt zaspokoi potrzeby dla których został przedsięwzięty.

Zarządzanie jakością jest osiągane przy pomocy procesów:

• planowania jakości (Quality Planning): określenia jakie standardy jakości są ważne dla projektu i jak można je spełnić,

• zapewnienia jakości (Quality Assurance): regularna ocena wyników projektu w celu zyskania zaufania, że projekt spełnia istotne standardy jakości,

• kontroli jakości (Quality Control): poprzez monitorowanie wyników prac nad projektem w celu ustalenia czy stosują się do istotnych standardów jakości oraz znalezienie metod eliminacji przyczyn niezadowalających wyników,

Każdy z tych procesów może oddziaływać na inny proces, niekoniecznie związany z zarządzaniem jakością.

Zarządzanie jakością projektu dotyczy zarówno zarządzania projektem i produktem projektu. Niespełnienie wymagań w jednym wymiarze może mieć negatywne konsekwencje dla każdego elementu projektu.

Zarządzanie jakością przykłada dużą wagę do zapobiegania błędom ponieważ koszt zapobiegania błędów jest znacznie niższy niż koszt naprawy błędów.

Jakość każdego wyrobu zależy od jakości poszczególnych procesów jego wytwarzania.

Zaleca się aby zarządzanie jakością było elementem zarządzania organizacji, bowiem stosowanie zarządzania jakością jedynie do wybranych projektów może nie przynieść oczekiwanych rezultatów przy ich realizacji. Np. sprawa taka jak umiejętność zapobiegania błędom jest rezultatem dłuższego procesu wdrażania zarządzania jakością wewnątrz organizacji.

1. Planowanie jakości QUALITY PLANNING

Poprzez QP rozumie się identyfikację standardów jakości znaczących dla projektu oraz wyznaczenie sposobów ich zaspokojenia. QP jest jednym z kluczowych procesów podczas procesu planowania projektu.

W procesie QP uwzględnia się:

1. politykę jakości - ogół intencji i wskazówek w organizacji w odniesieniu do jakości, formalnie wyrażona przez najwyższy szczebel zarządzania.

W projektach stosuje się zazwyczaj politykę jakości organizacji, jakkolwiek tworzy się niekiedy dedykowane dla projektu polityki jakości.

2. zakres projektu i jego cele,

3. opisu produktu zwłaszcza elementy zawierające szczegóły związane z jakością,

4. standardy i przepisy - rozważenie specyficznych dla projektu standardów i przepisów wpływających na projekt,

5. wyniki uzyskane z innych procesów które można związać z QP,

Narzędzia i techniki używane w QP:

1. Analiza korzyści i kosztów zastosowania metod zwiększenia jakości projektu.

Podstawowymi korzyściami są:

mniejsza liczba poprawek, wyższa produktywność, niższe koszty, zadowolenie udziałowców.

Podstawowym kosztem są wydatki związane z czynnościami z zarządzania jakością projektu. Aksjomatycznie zakłada się, że korzyści przeważają nad kosztami.

2. Pomiary przez benchmarkowanie - porównanie prac nad projektem z pracami przy innych projektach w celu szukania możliwych ulepszeń oraz pomiarów wyników.

3. Diagramy przepływu: pokazujące powiązania pomiędzy różnymi elementami

1. Diagramy Przyczyn i Efektów "Cause-and-effect" tzw. schemat rybiej ości ukazujące wpływa różnych przypadków na tworzenie potencjalnych problemów lub efektów.

2. Diagram procesu: przedstawia powiązania elementów systemu.

Wyniki QP:

1. Plan zarządzania jakością - sposób w jaki zespół zarządzania projektem może zastosować politykę jakości. Opisuje on (według ISO 9000) system jakości projektu: strukturę organizacyjną, odpowiedzialności, procedury, procesy oraz zasoby niezbędne do wprowadzenia zarządzania jakością.

2. Definicje poziomu sprawności - Metryk: opis elementów jakości projektu oraz sposobów ich pomiarów przez proces kontroli jakości.

3. Checklists - zestaw wymaganych kroków do podjęcia, zazwyczaj związanych z określonym działaniem. Zwykle zawierają sformułowania typu: "Zrób to!", "Czy to wykonałeś?". Checklist'y umożliwiają zachowanie konsekwencji przy często powtarzanych czynnościach.

4. Wymagane dodatkowe działania w innych obszarach projektu.

2. Zapewnienie jakości QUALITY ASSURANCE

QA obejmuje wszystkie zaplanowane i systematyczne działania w systemie jakości dostarczające zaufania, że projekt spełnia znaczące standardy jakości. Powinno być to wykonywane od początku do końca projektu.

W procesie QA uwzględnia się:

1. Planu zarządzania jakością,

2. Wyniki pomiarów kontroli jakości: zapisy testów kontroli jakości i pomiarów w formie umożliwiającej analizę i porównywanie.

3. Metryki

Narzędzia i techniki używane w QA:

1. Narzędzia i techniki używane w QP,

2. Audyty jakości - strukturalny przegląd czynności zarządzania jakością. Jego celem jest poprawienie wyników projektu. Audyt może być planowany lub losowany, audytorzy mogą być z wewnątrz organizacji lub z zewnątrz.

Wyniki QA:

Poprawa jakości - obejmuje opis działań zwiększających efektywność i wydajności projektu. Poprawa jakości wymaga przygotowania wniosków zmian lub podjęcie akcji poprawy. Są one przeprowadzane w ramach procedur zmiany sterowania.

3. Kontrola, sterowanie jakością QUALITY CONTROL

QC zajmuje się monitorowaniem specyficznych wyników projektu aby określić, czy stosują się one do znaczących standardów jakości oraz identyfikacja sposobów eliminacji niezadowalających wyników.

Za wyniki projektu przyjmuje się zarówno wyniki produktu jak i wyniki zarządzania projektem typu: koszty, wyniki planu. Do kontroli jakości potrzebna jest wiedza o statystycznej kontroli jakości, próbkowaniu i prawdopodobieństwie.

W procesie QC uwzględnia się:

1. Wyniki pracy - aktualne wyniki procesu i wyniki produktu oraz spodziewane wyniki.

2. Plan zarządzania jakością,

3. Metryki,

4. Checklist'y,

Narzędzia i techniki używane w QC:

1. Inspekcje - inspekcjami określa się czynności takie jak: mierzenie, sprawdzanie, testowanie podejmowane w celu sprawdzenia zgodności wyniku z wymaganiami. Inspekcje mogą być przeprowadzane na różnych poziomach. Inne nazwy to: przeglądy, przeglądy produktu, audyty, przejścia walk-through,

2. Wykresy kontroli - graficzna wizualizacja wyników projektu w czasie. Pozwala stwierdzić, czy proces jest pod kontrolą. Przydatna do monitorowania różnych typów zmiennych.

3. Diagramy Pareto - jest to histogram, uporządkowany według częstotliwości występowania. Pozwala ustalić najważniejsze problemy które trzeba naprawić. Prawo Pareto mówi, że względnie mała liczba przyczyn produkuje większość problemów i defektów.

4. Próbkowanie statystyczne - pozwala na badanie populacji na podstawie jej części. Odpowiednie próbkowanie prowadzi do redukcji kosztów kontroli jakości.

5. Diagramy przepływów - pozwala ustalić miejsca powstawania błędów,

6. Analiza trendów - użycie matematycznych technik do przepowiadania przyszłości na podstawie historycznych wyników. Najczęściej używane do monitorowania:

• wyników technicznych - liczby występujących oraz pozostałych błędów,

• kosztów i wyników planu - określenie liczby czynności z odpowiednich okresów pracy które zakończono ze znaczącą wariancją,

Wyniki QC:

1. Poprawa jakości jak w QA,

2. Decyzje o akceptacji: akceptacja bądź odrzucenie elementów poddanych inspekcji. Elementy odrzucone wymagają ponownego opracowania,

3. Ponowne opracowanie: czynność której zadaniem jest doprowadzenie wadliwego lub niepoprawnego elementu do zgodności z wymaganiami lub specyfikacją. Nieprzewidziana konieczność ponownego opracowania elementów projektu, produktu jest najczęstszą przyczyną przedłużenie pracy nad projektem. Zespół projektowy powinien starać się w rozsądny sposób minimalizować potrzebę ponownego opracowania.

4. Wypełnione checklist'y: wypełnione checklist'y stają się elementem protokołów projektu,

5. Przystosowanie procesu: jest to pilna akcja naprawcza lub zapobiegawcza podejmowana w wyniku pomiarów kontroli jakości. Niekiedy powinna to zostać przeprowadzane w ramach procedur zmiany sterowania.

Rozdział 2: Zarządzanie jakością projektu informatycznego

Zarządzanie jakością projektu informatycznego jest specjalizacją zarządzania jakością projektu.

Zapewnienie Jakości Oprogramowania Software Quality Assurance polega na stosowaniu praktyk dobrej inżynierii oprogramowania oraz monitorowania stopnia ich stosowania w cyklu rozwoju oprogramowania. Oprócz kontroli produktu kontroluje się proces wytwarzający produkt.

Jakością nie może zajmować się wybrana osoba czy organizacja. Jakość musi być podstawowym obowiązkiem każdej z osób zaangażowanych w proces rozwoju produktu. Rolą SQA jest sprawienie, aby każdy wykonywał swoje funkcje w sposób jakościowy. Konsekwentne stosowanie procesu jakości dostarczy produkt wysokiej jakości.

Początkiem SQA jest stworzenie w początkowej fazie projektu informatycznego Planu zapewnia jakości.

Jest on przygotowywany dla każdej fazy projektu. Zawiera identyfikację wszystkich produktów końcowych fazy, określa metody zapewnienia ich jakości, określa metody zapewnienia jakości procesów wytwarzających te produkty.

Sposoby zapewnienia jakości oprogramowania:

• Przeglądy techniczne,

• Ocenianie,

• Zarządzanie konfiguracją,

• Raportowanie błędów,

• Analiza trendów,

• Działania naprawcze usuwające przyczyny błędów,

• Śledzenie,

• Zarządzenie dokumentacją,

• Pomiary,

• Tworzenie podsumowań projektów,

I. Elementy SQA

a) Przegląd techniczny: proces grupowy którego celem jest szczegółowe zbadanie produktu lub procesu. Jego wyjątkowa skuteczność jest wynikiem połączonej ekspertyzy uczestników przeglądu. Istotą inspekcji jest wykorzystanie zdolności analitycznych ludzi biorących w niej udział oraz zaangażowanie innych (niż autor) ludzi do szukania ewentualnych błędów (najtrudniej jest zauważyć własne błędy).

Umożliwia to wczesne wykrywanie błędów. Jest to forma niesamowicie skuteczna SQA (wg. informacji autora).

Najważniejsze typy przeglądów:

• Walkthrough: jest to zazwyczaj swobodny (może też być formalny) przegląd kodu źródłowego,

• Inspekcje: zdyscyplinowany przegląd dowolnych dokumentów projektu (np. dokumentów analizy, projektowania, rzadziej kodów źródłowych),

b) Ocenianie: wykonywane jest przez pojedynczą osobę lub organizację. Sprawdzana jest zgodność produktu procesu rozwoju oprogramowania ze wszystkimi stosowanymi wymaganiami. Produkty poddawane ocenie powinny zostać wyznaczone w planie zapewnienia jakości.

Przykład:

Software Requirements: każda z czynności i każdy produkt powinien być sprawdzany przez cały czas przeprowadzania tej fazy. Powinny zostać ocenione m.in.:

• plan rozwoju oprogramowania,

• podręcznik standardów oprogramowania i procedur,

• plan programu jakości oprogramowania,

• specyfikację wymagań oprogramowania,

Typy ocen (przykładowe):

• zgodność z wymaganym formatem i standardami dokumentacji,

• zgodność z wymaganiami kontraktu,

• wewnętrzną zgodność,

• zrozumiałość,

• odpowiednie przypadki testowe, procedury testowe,

• kompletność testowania,

c) Zarządzanie konfiguracją: Zarządzanie konfiguracją oprogramowania obejmuje dyscyplinę i techniki wprowadzania, oceniania i kontrolowania zmian oprogramowania podczas procesu rozwoju oraz po jego zakończeniu Efektywne zarządzanie konfiguracją powinno obejmować zmiany we wszystkich produktach projektu rozwoju oprogramowania włączając w to: dokumentację, raporty testowe, raporty błędów.

Zarządzanie konfiguracją oprogramowania dostarcza podstaw dla wszelkich innych działań występujących w trakcie rozwoju oprogramowania. Potrzeba stosowania zarządzania konfiguracją jest wyjątkowo silna w dużych projektach.

Funkcjami zapewnienia jakości są:

• Zarządzanie integralnością produktu,

• Zarządzanie zmianami,

• Kontrola wersji,

• Stosowanie metryk,

• Planowanie zarządzania konfiguracją,

d) Raportowanie błędów: System raportowania błędów powinien być składnikiem każdego projektu informatycznego. Jego zadaniem jest dokumentowanie działań podejmowanych w związku ze znalezieniem defektów. Powinien on obsługiwać:

• Identyfikację defektów: opisywanie błędnych zachowań produktu,

• Analizę defektów,

• Naprawienie defektów: dokumentacja wprowadzonych zmian w dokumentach projektu i źródłach programów,

• Implementację uaktualnień: dokumentacja poprawek wprowadzanych do kolejnych wersji oprogramowania,

• Testowanie regresyjne: dokumentacja wykonanych testów sprawdzających, czy naprawienie defektu nie wprowadziło dodatkowych błędów,

• Kategoryzację błędów: grupowanie błędów według różnych klasyfikacji np. typu (wymagań, analizy, projektu, kodu, testu itp.), priorytetu, częstości występowania (powracający, nie powracający),

Raportowanie błędów powinno być dostosowywane do fazy rozwoju np. inne dla rozwijanego produktu, inne dla produktu dostarczonego już do klienta,

e) Analiza trendów: jest to analiza danych w czasie. Dostarcza informacji pomagających podjąć decyzję o akcjach naprawczych. Analiza trendów jest w bardzo dużym stopniu zależna od fazy rozwoju projektu tj. raporty ważne przy tworzeniu specyfikacji są już nie przydatne w fazie testowania systemu.

Typowe raporty:

• liczby błędów raport liczby pojawiających się błędów od czasu rozpoczęcia do czasu zakończenia fazy, pozwala zlokalizować źródła błędów, procesy w których pojawia się duża liczba błędów,

• częstotliwości błędów: liczby błędów na jednostkę produktu np. kodu, specyfikacji. Pozwalają ustalić które elementy produktu będą przyczyną późniejszych błędów według zasady Pareto niehomogenicznej dystrybucji błędów: "Jednostki o większej częstotliwości błędów będą miały prawdopodobnie większą liczbę utajnionych błędów",

• złożoności jednostek produktu: raport przedstawiający pomiar złożoności elementów produktu, według którego można wyszukać elementu o największej złożoności - w których prawdopodobieństwo istnienia błędów jest największe. Pozwala to także na wyszukanie elementów produktu które powinny zostać uproszczone przez ponowne zaprojektowanie.

f) Działania naprawcze usuwające przyczyny błędów: celem systemu naprawczego jest eliminacja powracających błędów przez znalezienie ich głównych przyczyn. Odnalezienie głównej przyczyny jest zwykle trudne, ale dopóki nie zostanie ona znaleziona, błędy będą ciągle powracać.

System akcji naprawczych powinien obejmować:

1. Identyfikacje wymagań dla podjęcia akcji naprawczej: Określenie, czy wymagane jest podjęcie akcji naprawczej i czy przyniesie ono korzyści. Możliwe jest podejmowanie akcji naprawczych:

• dla każdego błędu - zbyt kosztowne,

• dla błędów o największej częstotliwości występowania

• dla błędów o największym wpływie na projekt,

• dla błędów należących do próbki statystycznej,

2. Wyznaczanie akcji naprawczych,

3. Wprowadzanie akcji naprawczych,

4. Dokumentacja akcji naprawczych :dokumentacja działań naprawczych jest konieczna w celu oceny efektywności systemu akcji naprawczych.

5. Okresowe przeglądy podejmowanych działań

g) Możliwość śledzenia (traceablity): zasada śledzenia mówi, że każdy produkt powinien być związany (śledzony) z produktem(ami) z którego został wyprowadzony. Np. można zidentyfikować wymagania lub decyzje projektowe z którymi wiąże się zastosowanie wybranego algorytmu w oprogramowaniu.

Jest to bardzo pomocne przy wszystkich zmianach projektu, uaktualnianiu procedur testowych, ocenie zgodności z wymaganiami.

h) Zarządzenie dokumentacją: wymaga ścisłej metody zarządzania dokumentami projektu, raportami.

i) Pomiary: Pomiar jest to proces, w którym atrybutom elementów świata rzeczywistego przydzielane są liczby lub symbole w taki sposób, aby charakteryzować te atrybuty według jasno określonych zasad. Jednostki

przydzielane atrybutom w ramach tego procesu nazywane są miarą danego atrybutu. [4]

Jest to jeden z głównych elementów zapewnienia jakości. Pomiar wytworzonego produktu pozwala

ocenić jego jakość. Wynik pomiarów można także wykorzystać do poprawy procesu wytwarzania. Pomiar został użyty przez Deminga do statystycznej kontroli procesu, metoda to odniosła niezwykły sukces w Japonii i na całym świecie.

Metryka jest to proponowana (postulowana) miara wybranego atrybutu. Nie zawsze metryka jest odpowiednią miarą. np. liczba linii kodu źródłowego nie jest miarą złożoności chociaż może być miarą atrybutu "długość programu". [4]

Pomiary i Metryki oprogramowania związane z jakością:

Metryka gęstości defektów :(ilość defektów odkrytych w kodzie / rozmiar kodu). Rozmiar kodu wyrażany jest w KLOC - tysiącach linii kodu.

Metryki złożoności: Jest ich wiele (ponad 100). Informacja o złożoności w dużym stopniu może wpłynąć na metody zapewnienia jakości.

Szacowanie kosztów i nakładu pracy:

Pomiary w celu oszacowania kosztów projektu i niezbędnego nakładu pracy są niezwykle ważne dla menadżerów projektów. Stworzono kilka metod szacujących koszty i nakłady pracy np.

• model COCOMO,

• metoda punktów funkcyjnych,

Modele i miary wydajności ludzi : wydajność pracy ludzi jest ściśle związana z planowaną jakością produktu. Standardowo stosowane są proste metody liczby napisanych linii kodu na miesiąc pracy programisty. Inną metodą mierzy wydajności ludzi w punktach funkcyjnych na miesiąc.

k) Podsumowanie projektu: Podsumowanie projektu powinno zawsze wchodzić w skład planu projektu. Pozwala ono uniknąć błędów przy podejmowaniu przyszłych projektów oraz skorzystać z poprzednich doświadczeń. Powinno składać się z:

• przeglądu i oceny wytworzonego produktu,

• przeglądu projektu,

II. Dojrzałość procesu wytwarzania

CMM Model dojrzałości procesu wytwarzania Capability Maturity Model

Model oceniający zdolność organizacji do wytwarzania wysokiej jakości oprogramowania. Model ten ocenia organizację i przydziela ją do jednego z 5 poziomów dojrzałości. związanych głównie ze stopniem zdyscyplinowania procesów wytwórczych organizacji.

Każdy poziom jest charakteryzowany przez KPA - Key Process Areas kluczowe obszary procesu.

Poziomy dojrzałości:

1. Początkowy - określany jest także jako chaotyczny. Nie jest to jednak regułą. Istnieją organizację na tym poziomie które dobrze funkcjonują, jednak ich projekty są mniej przewidywalne, kosztują więcej, posiadają więcej błędów.

2. Powtarzalny - Stosowane zarządzanie projektami oraz uporządkowanie procesu,. W skład KPA wchodzą: zarządzanie wymaganiami, planowanie projektu, śledzenie projektu, zarządzanie podzleceniami, zapewnienie jakości, zarządzanie konfiguracją.

3. Zdefiniowany - Proces jest zdefiniowany, używany we wszystkich projektach wytwarzających oprogramowanie. KPA obejmuje organizowanie procesów, inżynierię oprogramowania, komunikację międzygrupową.

4. Zarządzany Stosowane jest sterowanie procesem.

5. Optymalizujący: KPA :zapobieganie defektom, zarządzanie zmianami technologii, zarządzanie zmianami procesu.

W CMM szeroko stosowane są metryki oprogramowania. Na każdym poziomie odbywają się odpowiednie pomiary:

Poziom 1. pomiary w celu próby poprawy procesów i produktów,

Poziom 2. pomiary zarządzania projektem,

Poziom 3. pomiary produktów oprogramowania,

Poziom 4. pomiary procesów wytwarzania,

Poziom 5. pomiary umożliwiające dynamiczną zmianę procesów w trakcie realizacji projektu,

Korzyściami ze zwiększenia poziomu dojrzałości organizacji jest:

• redukcja czasu projektów informatycznych,

• redukcja kosztów,

• bardziej efektywne użycie zasobów,

SPI Poprawa Procesów Programowych Software Process Improvement ruch którego celem jest polepszenie procesu wytwarzania i eksploatacji oprogramowania w celu osiągnięcia wysokiej jakości oprogramowania oraz korzyści finansowych, czasowych i przewagi nad konkurencją.

III. Standardy jakości

ISO 9001 jest Międzynarodowym Standardem Jakości, który określa sposób realizacji i dokumentowania poszczególnych procesów organizacji i zarządzania przedsiębiorstwem. Ich stosowanie w trakcie całego cyklu życia pomoże dostarczyć produkt wysokiej jakości.

Certyfikacja systemu jakości polega na poddaniu systemu funkcjonującego w przedsiębiorstwie ocenie prowadzonej przez niezależną i obiektywną jednostkę certyfikującą. Pozytywny wynik certyfikacji skutkuje przyznaniem certyfikatu Systemu Zarządzania Jakością potwierdzającym skuteczność tego systemu oraz jego zgodność z wymaganiami określonej normy (np.ISO 9001, 9002, 9003).

ISO 9003 jest wersją ISO 9001 dla zapewnienia jakości oprogramowania.

Literatura: (zalecana jest ta z pogrubioną czcionką).

[1] Wiliam R. Duncan "A Guide to the project management, body of knowledge", 1996,

[2] Bradley J. Brown Assurance of Software Quality 1987 Software Engineering Insitute, Carnegle Mellon University,

[3] Janusz Górski i inni "Inżynieria oprogramowania w projekcie informatycznym" 1999,

[4] Andrzej Blikle Doktryna jakości PCkurier 8/2000 >> IT w firmach >> Zarządzanie jakością,

[5] Andrzej Blikle Doktryna jakości w praktyce PCkurier 9/2000 >> IT w firmach >> Zarządzanie jakością,

Szukasz gotowej pracy ?

To pewna droga do poważnych kłopotów.

Plagiat jest przestępstwem !

Nie ryzykuj ! Nie warto !

Powierz swoje sprawy profesjonalistom.

---