Struktura modelu CMM

–

poziom 1 (początkowy)


brak porządnej inżynierii wymagań



słaba współpraca w zespole



zaniedbana analiza i projekt



brak procedur zapewnienia jakości



brak jasno określonych ról w zespole



systematycznie przekraczany czas i budżet



poziom większości firm informatycznych, które jednak pomimo tego potrafią
wprowadzać dobre produkty (dzięki umiejętnościom informatyków, ich zaangażowaniu
oraz tolerancji klientów na błędy)



do wejścia na kolejny poziom wymagane:
•

uporządkowanie procesu

•

zarządzanie projektem

–

poziom 2 (powtarzalny)


skok od chaosu do porządku



firma jest w stanie wprowadzić produkt o podbnej jakości wielokrotnie (powtarzalność)



kluczowe obszary działań:
•

zarządzanie wymaganiami

•

planowanie projektu (produktów, dat zakończenia, kamieni milowych, budżetu)

•

zarządzanie wykonawstwem (świadome i zorganizowane znalezienie wykonawcy,
określenie mu standardów jakości, terminów)

•

zapewnienie jakości oprogramowania (grupa odpowiedzialna za jakość, plan testów,
automatycznych procedur testowych, zbioru zalecanych praktyk programistycznych,
dokumentowanie działań związanych z testowaniem)

•

zarządzanie konfiguracją (stosowanie narzędzi informatycznych do centralizacji,
kontrole wersji)



do wejścia na kolejny poziom wymagane:
•

definicja procesu

•

zarządzanie produkcją

–

poziom 3 (zdefiniowany)


integracja, definicja procesów, standaryzacja



potrzeby ujawniają się w firmach średniej wielkości



kluczowe obszary działań:
•

program szkoleń

•

zintegrowanie zarządzanie oprogramowaniem
–

intranetowa baza wiedzy

–

inżynieria produktu

–

koordynacja między zespołowa

–

przeglądy partnerskie



do wejścia na kolejny poziom wymagane:
•

sterowanie procesem

•

zarządzanie ilościowe

–

poziom 4 (zarządzany, zmierzony)

–

zdefiniowanie, udokumentowanie i zbieranie miar (metryk)

–

ilościowa kontrola procesu informatycznego

–

kluczowe obszary działań:


zarządzanie ilościowe procesem – zbieranie danych dotyczących budowy: liczby godzin

poświęconych na realizację, liczebność zespołów, inwestycje w narzędzia, godziny
szkoleń i wydatki



zarządzanie jakością oprogramowania – liczba błędów, godziny testów, zgodność z
planem i wymaganiami, koszt wytworzenia jednej cechy w oprogramowaniu



kontrola kosztów budowy oprogramowania



do wejścia na kolejny poziom wymagane:
•

ulepszanie procesu

•

zarządzanie zmianami

–

poziom 5 (optymalizujący)


poziom czwarty ze sprzężeniem zwrotnym (czyli wykorzystujemy zebrane miary do
analizy i usprawnienia całości procesu)



kluczowe obszary działań:
•

przeciwdziałanie błędom

•

zarządzanie zmianą technologii

•

zarządzanie zmianą procesu

Dla każdego obszaru działań określono:

–

cele (goals)

–

zobowiązania (commitment to perform)

–

praktyki (ability to perform)

–

działania (acitivities performed)

–

miary i analizy (measurements and analysis)

–

sposoby weryfikacji (veryfying implementation)

Przykładowo dla poziomu drugiego, obszar planowania projektu:

–

cel: prace i role w projekcie zaplanowane i udokumentowane

–

zobowiązanie: projekt musi posiadać swojego kierownika, którego odpowiedzialnością jest
wynegocjowanie ról oraz stworzenie planu projektu

–

praktyka: istnieje formalny plan projektu zawierający następstwo działań, wymagania
techniczne, koszty, standardy etc.

–

działania: uczestniczenie grupy wykonującej projekt w procesie planowania, estymacje,
opisanie ryzyka etc.

–

miary i analizy: kroki milowe projektu

–

sposób weryfikacji: przeglądy projektu

CMM jest metodą certyfikacji, zawierającą wiele praktycznych wskazówek dla szefów i ich
zespołów.

Wybrane parametry firmy na 5-tym poziomie:

–

koszt złej jakości (koszt poprawy wszystkich błędów) to 4% całkowitych nakładów na
produkcję oprogramowania – na poziomie 1-szym ponad 50%

–

nie przekraczają zaplanowanych kosztów i czasu – na poziomie pierwszym przekraczają
czas średnio o 150%, koszt prawie o 200%

–

koszt tworzenia funkcji to 30% kosztów firmy z poziomu pierwszego

–

średnio 7.5 roku jest potrzebne, by wejść z poziomu 1 na 5

Model propagacji defektów (wg IBM)

Propagacja błędów (wg Pressmana)

–

koszt błędów w zależności od projektowania

Generalnie polega to na tym, że w każdej fazie produkcji (modelowanie, projektowanie, kodowanie,
testowanie) powstaje pewna ilość błędów. Część z błędów, które przechodzą do fazy następnej jest
wzmacniana, dodatkowo pojawiają się też nowe błędy. Dlatego poszukiwania błędów nie
powinniśmy zaczynać dopiero w fazie kodowania tylko już przy modelowaniu, bo ilość błędów
przepuszczonych i wzmocnionych przy modelowaniu i projektowaniu będzie duża i nie wyłapiemy
ich nawet przy efektywnym testowaniu.

Wady CMM:

–

duży skok jakościowy pomiędzy pierwszym a drugim poziomem (teoretycznie nie jest to
wada, ale firma może mieć problem ze zorganizowaniem się)

–

duży koszt wdrażania (dokumentacja, uzgodnienia, przeglądy, etaty dla nie-programistów,
koszt certyfikatów)

ISO a CMM

–

oba standardy typu „mów co robisz i rób, co mówisz”

–

firmy z ISO 9000 kwalifikują się najczęściej do 3-4 poziomu CMM

–

ISO ma charakter binarny (certyfikowana firma lub nie), CMM ma 4 poziomy certyfikacji

–

CMM bardziej ukierunkowany na firmy informatyczne

–

standaryzacja CMM bardziej złożona od ISO

Konserwacja oprogramowania

–

z punktu widzenia klienta jest to faza eksploatacji

–

z punktu widzenia producenta faza konserwacji (pielęgnacji, utrzymania)

Konserwacja do wprowadzanie modyfikacji. Klasy modyfikacji:

–

modyfikacje poprawiające
•

usuwają błędy z oprogramowania

•

poprawa błędów popełnionych w każdej fazie tworzenia oprogramowania

–

modyfikacje ulepszające
•

poprawiają jakość oprogramowania

•

poprawa wydajności funkcji

•

poprawa ergonomii interfejsu użytkownika

•

poprawa przejrzystości raportów

–

modyfikacje dostosowujące
•

dostosowują oprogramowanie do zmian zachodzących w środowisku jego pracy

•

zmiany wymagań użytkownika

•

zmiany przepisów prawnych dotyczących dziedziny problemu

•

zmiany organizacyjne po stronie klienta

•

zmiany sprzętu i oprogramowania systemowego

Przyczyny modyfikacji:

–

żądania użytkowników

–

decyzja kierownictwa firmy programistycznej (np. zwiększenie konkurencyjności
oprogramowania)

Koszty konserwacji

Obiektywne:

–

stabilność środowiska, w którym pracuje system

–

stabilność platformy sprzętowej i oprogramwania systemowego

–

czas użytkowania systemu

Czynniki wpływające na redukcję kosztów konserwacji:

–

znajomość dziedziny problemu

–

wysoka jakość modelu i projektu (spójność, stopień powiązań składowych, przejrzystość)

–

wysoka jakość dokumentacji technicznej (w pełni odpowiada systemowi, wystarczająco
szczegółowa, zgodna z przyjętymi standardami)

–

stabilność personelu

–

środowisko implementacji

–

niezawodność oprogramowania

–

inżynieria odwrotna

–

zarządzanie wersjami

Wniosek – wiele działań zmierzających do redukcji kosztów systemu musi być podejmowana już w
trakcie budowy systemu!