Operacyjna definicja CMM
CMM jest schematem pokazującym organizacjom software’owym zalecaną ścieżkę udoskonalania ich procesów tworzenia oprogramowania. To operacyjne opracowanie CMM jest zaprojektowane, aby wspierać działania organizacji na wiele sposobów. Istnieją następujące zastosowania modelu:
zespoły szacujące używają CMM, aby wyznaczyć silne i słabe punkty organizacji,
zespoły oceniające używają CMM, aby wyznaczyć ryzyko związane z wybraniem odpowiedniego kontrahenta i monitorowania kontraktu,
kierownictwo i personel techniczny używa CMM, aby zrozumieć konieczne czynności, zaplanować i zaimplementować program udoskonalania procesu tworzenia oprogramowania,
grupy udoskonalające proces, takie jak SEPG, używają CMM jako przewodnika, który pomaga im poprawić proces tworzenia oprogramowania w organizacji.
Z powodu tej różnorodności użycia modelu CMM, musi on być zdekomponowany z dostateczną szczegółowością, żeby bieżące rekomendacje procesów wynikały ze struktury poziomów dojrzałości. Ta dekompozycja wskazuje również procesy i ich strukturę, co charakteryzuje dojrzałość procesu i jego potencjalną wydajność.
Struktura wewnętrzna poziomów dojrzałości
Każdy poziom może być zdekomponowany na konsystentne części. Z wyjątkiem poziomu 1, dekompozycja każdego poziomu rozciąga się od abstrakcyjnego streszczenia aż do operacyjnej definicji ich praktyk kluczowych, co przedstawione jest na rysunku 3.1. Każdy poziom dojrzałości złożony jest z kilku obszarów procesów kluczowych. Każdy obszar zawiera pięć sekcji nazywanych common features. Common features pozwalają zrealizować cele poszczególnych obszarów procesu poprzez sprecyzowanie praktyk kluczowych.
Rysunek 3.5. Struktura CMM
Obszary procesów kluczowych
Każdy poziom dojrzałości składa się z kilku obszarów wskazujących, gdzie ma koncentrować się poprawa procesu tworzenia oprogramowania. Obszary procesów kluczowych identyfikują, które zagadnienia muszą być poprawione, aby osiągnąć poziom dojrzałości.
Każdy obszar identyfikuje grupę pokrewnych czynności, które wspólnie wykonywane pozwalają osiągać zespół celów istotnych dla podniesienia wydolności procesu. Jakie obszary procesów kluczowych znajdują się na poszczególnych poziomach, pokazuje rysunek 3.6. Ścieżka osiągania celów przez obszary może się nieco różnić w obrębie projektów z powodu różnic w dziedzinach aplikacji i ich środowiskach. Niemniej jednak wszystkie cele obszaru procesów kluczowych muszą być zrealizowane.
Rysunek 3.6. Obszary procesów kluczowych na poszczególnych poziomach
CMM nie opisuje dokładnie wszystkich obszarów procesu, które są zaangażowane w udoskonalanie oprogramowania. Pewne obszary zostały uznane jako wyznaczniki wydolności procesu i właśnie te zostały opisane w CMM.
Chociaż niektóre zagadnienia również oddziałują na wykonanie procesu, zajęliśmy się jedynie obszarami procesów kluczowych, gdyż one w sposób szczególny wpływają na poprawę wydajności procesu tworzenia oprogramowania. Mogą one być uważane jako wymagania do osiągnięcia odpowiedniego poziomu. Rysunek 3.2 przedstawia obszary procesów kluczowych dla każdego poziomu dojrzałości. Aby osiągnąć dany poziom, jego obszary procesów kluczowych muszą być zrealizowane. Cele są podsumowaniem praktyk kluczowych obszarów i mogą być używane do wyznaczenia, czy został efektywnie zaimplementowany obszar procesu kluczowego.
Obszary procesów kluczowych na poziomie 2 koncentrują się na ustanowieniu podstawowej kontroli zarządzającej. Opis każdego obszaru procesu kluczowego poziomu 2 podany jest poniżej:
Celem Zarządzania Wymaganiami (Requirements Management) jest ustanowienie ogólnego porozumienia pomiędzy klientem i projektem oprogramowania, chodzi tu o wymagania klienta adresowane do projektu. Ta umowa z klientem jest podstawą do planowania (które jest opisane w części Planowanie Projektu Oprogramowania) i zarządzania (które jest opisane w części Nadzór i Śledzenie Projektu, Software Project Tracking and Oversight). Kontrola relacji z klientem zależy od procesu kontroli zmian (co jest opisane w Zarządzanie Konfiguracją Oprogramowania)
Celem Planowania Projektu Oprogramowania jest ustalenie rozsądnych planów odnośnie zarówno inżynierii oprogramowania, jak i zarządzania projektem oprogramowania. Te plany są niezbędnym fundamentem dla zarządzania projektem. Bez realistycznych planów nie może być wdrożone skuteczne zarządzanie.
Celem Śledzenia i Nadzoru Projektu Oprogramowania jest ustanowienie odpowiedniej widoczności rzeczywistego rozwoju. Chodzi o to, aby kierownictwo mogło podjąć skuteczną akcję, jeśli wykonanie projektu odbiega znacznie od ustalonych planów.
Celem Zarządzania Subkontrahentami jest wybranie wykwalifikowanych subkontrahentów i zarządzanie nimi w efektywny sposób. Skupia ono w sobie podstawowe elementy Zarządzania Wymaganiami, Planowania i Śledzenia oraz Nadzorowania wraz z konieczną koordynacją Zapewnienia Jakości Oprogramowania i Zarządzaniem Konfiguracja Oprogramowania, stosując odpowiednio tą kontrolę wobec subkontrahentów.
Celem Zapewnienia Jakości Oprogramowania jest dostarczenie kierownictwu odpowiedniego wglądu w procesy projektu i tworzone produkty. Zapewnienie Jakości Oprogramowania jest integralną częścią większości procesów inżynierii oprogramowania oraz procesów zarządzających.
Celem Zarządzania Konfiguracją Oprogramowania jest ustanowienie i podtrzymanie produktów projektu oprogramowania poprzez cały cykl życia projektu. Zarządzanie Konfiguracją Oprogramowania jest integralną częścią większości procesów inżynierii oprogramowania oraz procesów zarządzających.
Procesy kluczowe na poziomie 3 odnoszą się zarówno do zagadnień projektowych, jak i organizacyjnych, gdzie organizacja ustanawia infrastrukturę, która wprowadza efektywną inżynierię oprogramowania i procesy zarządzania poprzez cały projekt. Opis każdego procesu kluczowego dla poziomu 3 podany został poniżej:
Celem Skupienia Procesu Organizacji (Organization Process Focus) jest ustanowienie organizacyjnej odpowiedzialności za czynności procesu tworzenia oprogramowania, co podnosi całościową wydolność procesu tworzenia oprogramowania w organizacji. Zasadniczym rezultatem Skupienia Procesu Organizacji jest zestaw aktywów procesu tworzenia oprogramowania, który jest opisany przy okazji Definicji Procesu Organizacji. Te aktywa są używane w projekcie tworzenia oprogramowania, jak to jest opisane w Zintegrowanym Zarządzaniu Oprogramowaniem.
Celem Definicji Procesu Organizacji (Organization Process Definition) jest rozwinięcie i podtrzymywanie użytecznego zestawu aktywów procesu tworzenia oprogramowania, które poprawiają wykonanie procesu w obrębie projektu i dostarczają podstawy do długoterminowych rosnących korzyści organizacji. Te aktywa stanowią trwałe fundamenty, które mogą być wprowadzone poprzez mechanizmy takie jak szkolenia, opisane w Programie Szkoleniowym.
Celem Programu Szkoleniowego jest rozwinięcie umiejętności i wiedzy jednostek, tak aby mogły wykonywać swoje zadania skutecznie i wydajnie. Szkolenie jest odpowiedzialnością organizacji, która powinna identyfikować, jakie umiejętności są konieczne do wykonania projektu i dostarczać niezbędnych szkoleń, jeśli są takie potrzeby projektu.
Celem Zintegrowanego Zarządzania Oprogramowaniem jest scalenie inżynierii oprogramowania i czynności zarządzających w jeden koherentny, zdefiniowany proces tworzenia oprogramowania, który jest stworzony ze standardowego procesu tworzenia oprogramowania i skojarzonych aktywów, opisanych w Definicji Procesu Organizacji. To tworzenie opiera się zarówno na podstawach finansowo-ekonomicznych, jak i na technicznych potrzebach projektu, jak to jest opisane w Inżynierii Produktu Oprogramowania. Zintegrowane Zarządzanie Oprogramowaniem rozwija się stopniowo z Planowania Projektu Oprogramowania i Śledzenia i Nadzoru Projektu na poziomie 2.
Celem Inżynierii Produktu Oprogramowania jest zgodne wykonywanie dobrze zdefiniowanego procesu inżynieryjnego, które łączy w jedną całość wszystkie czynności inżynieryjne, produkując konsystentne oprogramowanie skutecznie i wydajnie. Inżynieria Produktu Oprogramowania opisuje techniczne czynności projektu, np. analizę wymagań, projekt, kod czy testy.
Celem Koordynacji Międzygrupowej jest ustanowienie środków do tego, aby jedne grupy inżynieryjne mogły aktywnie uczestniczyć w innych grupach. Wtedy projekt ma większe możliwości, aby odpowiadać wymaganiom klienta. Koordynacja Międzygrupowa jest interdyscyplinarnym aspektem Zintegrowanego Zarządzania Oprogramowaniem, które wykracza poza inżynierie oprogramowania. Nie tylko proces tworzenia oprogramowania powinien być zintegrowany, ale powinny być kontrolowane i koordynowane interakcje grup inżynierii oprogramowania z innymi grupami w projekcie.
Celem Peer Revievs jest usunięcie defektów z produktów oprogramowania względnie wcześnie i skutecznie. Bezpośrednią tego konsekwencją jest lepsze zrozumienie pracy programistycznej i defektów, którym możemy zapobiec. Peer Reviews jest ważną i skuteczną metodą używaną w inżynierii produktu oprogramowania i może być zaimplementowana poprzez przejścia strukturalne i inne liczne akademickie metody przeglądu.
Obszary procesów kluczowych na poziomie 4 koncentrują się na ustanowieniu zrozumienia zarówno procesu tworzenia oprogramowania, jak i produktów pracy programistycznej. Dwa obszary procesów kluczowych na tym poziomie: Ilościowe Zarządzanie Procesem i Zarządzanie Jakością Oprogramowania są od siebie ściśle uzależnione.
Celem Ilościowego Zarządzania Procesem jest kontrolowanie stanu procesu w projekcie oprogramowania w sensie ilościowym. Stan procesu jest reprezentowany przez wyniki osiągnięte przy zastosowaniu danego procesu. Koncentrujemy tu uwagę na identyfikowaniu specjalnych przyczyn zmienności w obrębie względnie stabilnego procesu oraz na odpowiednim korygowaniu warunków powodujących powstawanie przelotnej zmienności. Ilościowe Zarządzanie Procesem dodaje do programu obszerne i wyczerpujące badania do wykonania praktyk Organizacyjnej Definicji Procesu, Zintegrowanego Zarządzania Softwarem, Koordynacji międzygrupowej i Peer Revievs.
Celem Zarządzania Jakością Oprogramowania jest rozwój ilościowego zrozumienia jakości produktów procesu tworzenia oprogramowania i osiągnięcie celów ściśle określonej jakości. Zarządzanie Jakością Oprogramowania stosuje program rozległych badań na produktach softwarowych opisanych w Inżynierii Produktu Oprogramowania. Obszary procesów kluczowych na poziomie 5 obejmują kwestie, którymi musi zająć się zarówno organizacja jak i procesy, aby wprowadzić w życie ciągłą i wymierną poprawę procesu tworzenia oprogramowania. Opis każdego obszaru procesów kluczowych na poziomie 5 znajduje się niżej.
Celem Profilaktyki Defektów jest zidentyfikowanie przyczyn defektów i zapobieganie ich powtarzaniu. Projekt oprogramowania analizuje wady, identyfikuje ich przyczyny i zmienia swój zdefiniowany uprzednio proces tworzenia oprogramowania, jak to jest opisane w Zintegrowanym Zarządzaniu Oprogramowaniem. Zmiany procesu o globalnym znaczeniu są przenoszone do innych projektów oprogramowania, jak to jest opisane w Zarządzaniu Zmianami Procesu.
Celem Zarządzania Zmianami Technologii jest zidentyfikowanie nowych wartościowych technologii (narzędzi, metod i procesów) i przeniesienie ich do organizacji w uporządkowany sposób, jak to jest opisane w Zarządzaniu Zmianami Procesów. Zadaniem Zarządzania Zmianami Technologii jest skuteczne przeprowadzanie innowacji w ciągle zmieniającym się świecie.
Celem Zarządzania Zmianami Procesu jest nieprzerwane ulepszanie procesu tworzenia oprogramowania stosowane w organizacji w celu poprawy jakości oprogramowania, zwiększenia wydajności i zmniejszenia czasu cyklu rozwoju produktu. Zarządzania Zmianami Procesu dokonuje przyrostowych udoskonaleń Prewencji Defektów i innowacyjnych udoskonaleń Zarządzania Zmianami Technologii udostępniając je całej organizacji.
3.3.3Common Features
Dla wygody, obszary procesów kluczowych są zorganizowane w Common Features. Common Features są atrybutami wskazującymi, czy implementacja i ustanowienie obszarów procesów kluczowych są skuteczne, powtarzalne i trwałe. Pięć Common Features zostało podane poniżej:
Podjęcie Wykonywania (Commitment to Perform)
Podjęcie Wykonywania opisuje, jakie działania musi podjąć organizacja, aby ustanowić proces i aby proces ten był trwały. Podjęcie Wykonywania wymaga ustanowienia polityki organizacyjnej i zaangażowania najwyższego kierownictwa.
Zdolność do wykonywania (Ability to Perform)
Kompetencje Wykonania opisują warunki wstępne, które muszą być spełnione w projekcie czy organizacji, aby fachowo zaimplementować proces tworzenia oprogramowania. Kompetencje Wykonania zasadniczo wymagają zasobów, struktur organizacyjnych i szkoleń.
Wykonywane Czynności (Activities Performed)
Wykonywane Czynności opisują odpowiednie role i procedury konieczne do zaimplementowania w obszarze procesu kluczowego. Wykonywane czynności zasadniczo wymagają ustanowienia planów i procedur, prowadzenia prac, śledzenia ich i podejmowania odpowiednich akcji korygujących, jeśli to jest konieczne.
Pomiary i Analiza (Measurement & Analysis)
Pomiary i Analiza opisują potrzebę mierzenia procesów i analizowania pomiarów. Pomiary i Analiza zasadniczo zawierają przykłady pomiarów, które powinny być dokonane, aby wyznaczyć status i skuteczność Wykonywanych Czynności.
Weryfikowanie Implementacji (Verifying Implementation)
Weryfikowanie Implementacji opisuje kroki, jakie należy podjąć, aby zapewnić, że Wykonywane Czynności są zgodne z ustalonym wcześniej procesem. Weryfikacja obejmuje przeglądy i rewizje dokonywane przez kierownictwo i kontrole jakości oprogramowania.
Praktyki Kluczowe (Key Practices)
Każdy obszar procesów kluczowych jest opisany pod względem praktyk, które przyczyniają się do spełniania ich celów. Praktyki kluczowe opisują infrastrukturę i czynności, które najbardziej przyczyniają się do skutecznej implementacji i ustanowienia obszarów procesów kluczowych.
Każda praktyka kluczowa składa się z pojedynczego zdania, często następuje po nim bardziej szczegółowy opis, który może zawierać przykłady i szczegółowe badania. Te praktyki, o których też czasem mówimy "praktyki najwyższego poziomu", ustalają podstawowy kierunek działań, postępowania i czynności obszarów procesów kluczowych. Składniki ich szczegółowego opisu są często nazywane subpraktykami. Rysunek 3.7 przedstawia przykład struktury praktyk kluczowych w obrębie obszaru procesu kluczowego Planowanie Projektu Oprogramowania.
Rysunek 3.7. Budowanie struktury CMM – przykład praktyki kluczowej
Jak pokazano na rysunku 3.7, aby zapewnić całkowite osiągnięcie celu udokumentowania planów dla planowania i śledzenia projektu, organizacja musi wprowadzić udokumentowaną procedurę do szacunkowej oceny rozmiaru oprogramowania. Jeżeli te szacunkowe przybliżenia nie są rozwijane z udokumentowanej procedury, mogą się one zmieniać w szerokim zakresie.
Praktyki kluczowe opisują ”co” jest do zrobienia, ale nie powinny być interpretowane jako zalecające, ”jak” cele powinny być osiągane. Alternatywne praktyki mogą prowadzić do osiągnięcia celów obszarów procesów kluczowych, dlatego praktyki kluczowe powinny być racjonalnie interpretowane.
komentarze
Copyright © 2008-2010 EPrace oraz autorzy prac.