54

Inżynieria

oprogramowania

www.sdjournal.org

Software Developer’s Journal 11/2007

Extreme Programming i CMMI

A

rtykuł jest drugą częścią cyklu, poświęconego porów-
naniu dwóch metod tworzenia oprogramowania – „lek-
kich”, reprezentowanych przez metodę

Extreme Pro-

gramming oraz „tradycyjnych” (określanych niekiedy jako
„strukturalne”), które odzwierciedla model CMMI.

W poprzedniej części, omówiona została, jedna z bar-

dziej znanych tzw. zwinnych metod programowania –

Extre-

me Programming (XP). Metoda ta mieści w sobie wszystko to,
co uosabia pojęcie kreatywności – spontaniczność, zwinność
(ang.

agility), otwartość na zmianę, a także odwaga w przekra-

czaniu stereotypów. Konkretne wartości XP, zasady, a przede
wszystkim praktyki developerskie, osadzone zostały w re-
aliach cyklu życia projektów agile’owych.

Druga część prezentowanego cyklu, przedstawia krótką

charakterystykę tradycyjnych metod tworzenia oprogramo-
wania, wraz z omówieniem genezy oraz podstawowej struk-
tury modelu CMMI (szkielet modelu, podstawowe komponen-
ty, konstelacje, obszary procesowe), który należy do bodaj-
że najbardziej popularnych reprezentantów podejść struktu-
ralnych.

Proces tworzenia oprogramowania

Tradycyjne metody wytwarzania oprogramowania w sposób
nierozerwalny związane są z pojęciem „procesu” jego tworze-
nia. Proces, najogólniej rzecz biorąc, to pewien zestaw kroków,
wykonywanych w określonym celu. Jego istotę, bardzo traf-
nie oddaje film Roberta Altmana:

The Company (USA/Niemcy

2003), który we współpracy z zespołem Joffrey Ballet of Chi-
cago, przedstawia znakomite występy tancerzy oprawione
grą światła, kolorów i muzyki. Taniec wyraża proces w pełnym
tego słowa znaczeniu. Nad jego właściwą definicją czuwa cho-
reograf, który odpowiada za stworzenie ogólnej koncepcji ukła-
du tanecznego. Określa poszczególne ruchy tancerzy, ewolu-
cje, kroki, obroty, skoki, i dzięki nim przekazuje akcję – nastrój
dzieła. Taniec oddaje życie organizacji – procesy, które nią kie-
rują. Metaforę tę w sposób znakomity wykorzystała Kim Capu-
to, w książce

CMM Implementation Guide. Choreographical So-

ftware Process Improvement (Addison–Wesley, 1998), gdzie
proces tworzenia oprogramowania opisany został właśnie za
pomocą języka choreografii.

Mówiąc o procesie w kontekście całej organizacji, nie

sposób pominąć jej trzech podstawowych wymiarów: ludzi,

procedur i narzędzi. Proces, jest tym wszystkim, co inte-
gruje wymienione obszary. Pracownik, mając do dyspozycji
określony zestaw narzędzi, kierując się odpowiednio dobra-
nym zbiorem procedur, może przekształcić surowy materiał
(dane wejściowe) w gotowy produkt (dane wyjściowe), któ-
ry będzie stanowił wartość biznesową z punktu widzenia na-
szego klienta.

Proces tworzenia oprogramowania, możemy zdefiniować

jako zespół aktywności, metod oraz praktyk, stosowanych w
celu wytworzenia i podtrzymania (ang.

maintenance) działają-

cego software’u. Warto zauważyć, iż proces ten skupia się nie
tylko na oprogramowaniu samym w sobie, ale także na wszel-
kich dodatkowych artefaktach, które jego powstaniu towarzy-
szą – plany projektowe, wymagania, projekt systemu, kod, czy
przypadki testowe.

Metody „Plan–Driven”

Tradycyjne metody tworzenia oprogramowania nazywane są
niekiedy metodami typu „plan–driven” (wiedzione planem).
Ich geneza związana jest z inżynierią systemów. W czasie,
gdy rozwijał się przemysł aerokosmiczny – satelity, statki ko-
smiczne, rakiety balistyczne – zasady inżynierii systemów
były wykorzystywane do koordynowania dużej liczby wzajem-
nie ze sobą oddziaływujących komponentów, dostarczanych
niekoniecznie przez jednego dostawcę. O ile komponenty har-
dware’owe bardzo dobrze się wkomponowywały w ten para-
dygmat, o tyle software do niego zupełnie nie przystawał. Za-
rządzano nim w sposób wysoce niezdyscyplinowany, co oczy-
wiście skutkowało niedotrzymywaniem terminów, przekracza-
niem zaplanowanego budżetu, a przede wszystkim niską jako-
ścią wytwarzanych produktów.

Żeby to zmienić, Departament Obrony Stanów Zjedno-

czonych

(United States Departement of Defense, w skró-

cie DoD), przygotował zestaw instrukcji, których celem by-
ło dopasowanie procesu tworzenia oprogramowania do wy-
magań, które stawiała inżynieria systemów. Pojawiły się ta-
kie dokumenty jak:

MIL–STD–1521, DoD–STD–2167, czy MIL–

STD–498. Dodatkowo, w tym samym czasie, duże firmy ko-
mercyjne

(IBM, Siemens, Hitachi), przygotowały podobne

standardy, przeznaczone do użytku wewnętrznego. Z cza-
sem, gdy inżynieria oprogramowania stawała się coraz bar-
dziej popularna, coraz większego znaczenia nabierały me-
tody, mające na celu „zdyscyplinowanie” procesu tworzenia
oprogramowania.

Charakterystyka

Metody typu

plan–driven wykorzystują najczęściej kaska-

dowy cykl życia oprogramowania, który to, na proces two-
rzenia oprogramowania każe nam patrzeć liniowo – kolej-
ne fazy (analiza i specyfikacja wymagań /projektowanie/
implementacja, testy, wdrożenie i pielęgnacja) występują se-
kwencyjnie, jedna po drugiej. Dodatkowo, dość duży nacisk

Mariusz Chrapko

Autor pracuje w Motorola Polska Electronics sp. z o.o. (krakow-
skie Centrum Oprogramoawnia Motoroli) na stanowisku inżynie-
ra jakości. Od strony zawodowej interesuje się problematyką do-
skonalenia procesu tworzenia oprogramowania w oparciu o Mo-
del CMMI®, a także praktykami Agile Software Development. Pry-
watnie lubi jazz i filozofię (głównie współczesną). W wolnych chwi-
lach fotografuje.
Kontakt z autorem:

[e-mail]

Extreme Programming i CMMI

55

www.sdjournal.org

Software Developer’s Journal 11/2007

położony jest na dokumentację poszczególnych faz projektowych. Każ-
da faza realizacji projektu, związana jest z opracowaniem szeregu doku-
mentów, opisujących jej rezultaty, które to z kolei stanowią dane wej-
ściowe do kolejnej.

Cechą charakterystyczną tradycyjnych metod tworzenia oprogra-

mowania jest precyzyjnie zdefiniowany proces, który podlega ciągłe-
mu doskonaleniu. Dobrze zdefiniowany proces to taki, którego struktu-
rę tworzą następujące elementy: Źródło:

„A Software Process Framework

for the SEI Capability Maturity Model”, Olson, Timothy G., CMU/SEI–94–HB–
01, 1994.

Mając dobrze zdefiniowany proces, czas na kolejny krok – jego im-

plementację i instytucjonalizację. Implementacja – to wykonywanie kon-
kretnych aktywności projektowych w ramach danego obszaru proce-
sowego (np. przygotowywanie planów projektowych w ramach procesu
zwanego „Planowaniem Projektu”).

Instytucjonalizacja z kolei, jest wynikiem wielokrotnej implementacji

danego procesu. Sytuacja taka, ma miejsce wówczas, gdy proces jest cał-
kowicie zintegrowany z działaniami danej organizacji i będzie on stoso-
wany, nawet wówczas, gdy zmienią się wszyscy jej pracownicy.

Metody plan–driven bardzo duży nacisk kładą na tzw. ilościowe za-

rządzanie procesem

(ang. quantative process management). Procesy są

najpierw precyzyjnie definiowane, implementowane, by później móc nimi
zarządzać właśnie w sposób ilościowy. Organizacje, mając do dyspozycji
narzędzia w postaci statystycznej analizy procesu, zbierają metryki pro-
cesowe, by później, na ich podstawie sporządzać tzw. wykresy kontrolne
(ang.

control charts), które umożliwiają śledzenie zachowań procesów. Za

ich pomocą możemy określić, czy zaimplementowany proces jest stabil-
ny, a więc czy jest powtarzalny oraz, czy jesteśmy w stanie przewidzieć
jego zachowanie w przyszłości. Ilościowe zarządzanie procesem jest na-
rzędziem, które służy jego ciągłemu doskonaleniu. Dane, które organiza-
cja zbiera, a które są później przetwarzane i analizowane, posiadają nie-
oceniony wpływ na dojrzałość procesów wytwórczych w firmie (Rysunek
1). Zainteresowanych odsyłam do doskonałej lektury: W. A. Florac oraz A.
D. Carleton,

Measuring the Software Process. Statistical Process Control

for Software Process Improvement, Addison–Wesley, 1999.

Ciągłe doskonalenie procesów wytwórczych, zazwyczaj związa-

ne jest z istnieniem specjalnie do tego powołanej grupy ludzi, tworzącej
niekiedy odrębny dział w firmie – Dział Jakości. Do ich obowiązków nale-
ży między innymi monitoring i kontrola procesów wytwórczych, a także
dostarczanie pracownikom wszelkich, niezbędnych szkoleń, związanych
z ich implementacją

Mocną stroną tradycyjnych metod tworzenia oprogramowania jest

nacisk położony na powtarzalność i standaryzację procesów. Dokład-
ne zdefiniowanie procesów wytwórczych w organizacji oraz przeszkole-
nie pracowników w zakresie ich stosowania, prowadzi do sytuacji, w któ-

rej każdy wie, gdzie, w razie potrzeby, może znaleźć potrzebne mu infor-
macje oraz czego projekt od niego oczekuje. Dodatkowo, znika problem
migracji międzyprojektowej. Menedżerowie, mając ludzi posiadających
znajomość procesów w organizacji, mogą dowolnie przypisywać osoby
do różnych projektów, bez ryzyka poniesienia klęski. Oczywiście dość
ważną rzeczą, o której nie wolno nam zapominać, jest ekspertyza, a co za
tym idzie indywidualizm poszczególnych członków zespołu projektowe-
go. Wynika ona ze szczególnie dobrej znajomości określonej części pro-
duktu, procesu etc. Jest to czynnik, który będzie zawsze nierozerwalnie
związany z pracownikiem – stanowi tzw. dobrą energię projektu i, tak na-
prawdę, od menedżera zależy jak ją wykorzysta.

Podejście procesowe niesie ze sobą również pewne zagrożenia. Kie-

dy organizacja zbytnio skupi się na procesie, może bardzo szybko za-
tracić perspektywę całego produktu, która przecież jest perspektywą
naszego klienta. Może to być zabójcze dla innowacyjności oraz prowa-
dzić do powstania czegoś, co niektórzy nazywają tzw. „mentalnością li-
sty kontrolnej” (ang.

checklist mentality). Pracownicy wówczas, bardziej

skupiają się na karmieniu źle zdefiniowanego procesu, niż na tworzeniu
działającego, wolnego od defektów software’u. Produkt wówczas zajmu-
je plan drugi – tak rodzi się

dyktatura procesu.

Wyznaczniki sukcesu

Tradycyjne metody tworzenia oprogramowania, silnie zorientowane
na powtarzalność i ciągłe doskonalenie procesu, wymagają pełnego
wsparcia i zaangażowania ze strony wyższego kierownictwa. Mene-

Tabela 1.

Elementy dobrze zdefiniowanego procesu

Pytanie

Element procesu

Po co dana aktywność jest wykonywana?

1. Cel

Jakie działania są podejmowane?

2. Aktywności

Jakie produkty robocze są wykorzystywane?

3. Wejście/ścia

Jakie produkty robocze powstają?

4. Wyjście/ścia

Kiedy dana aktywność się rozpoczyna?

5. Kryteria wejściowe

Kiedy dana aktywność się kończy?

6. Kryteria wyjściowe

Kto wykonuje daną aktywność?

7. Role

Gdzie dana aktywność jest wykonywana?

8. Kontekst procesu (np. Hierarchia)

Jak dana aktywność jest zaimplementowana?

9. Procedury

Rysunek 1.

Cykl doskonalenia procesu

Doskonalenie

procesu

Pomiar

procesu

Kontrola

procesu

Egzekucja

procesu

Definicja

procesu

56

Inżynieria

oprogramowania

www.sdjournal.org

Software Developer’s Journal 11/2007

dżerowie muszą dostrzegać znaczenie dobrze zdefiniowanego i pod-
trzymywanego procesu z punktu widzenia produktu, który mają dostar-
czyć klientowi. Organizacja musi stworzyć pewnego rodzaju infrastruk-
turę, której celem będzie podnoszenie świadomości pracowniczej w za-
kresie istniejących procesów w firmie oraz zależności, które między ni-
mi zachodzą.

Taka infrastruktura, to systematyczne dostarczanie szkoleń proce-

sowych dla pracowników firmy, dzięki którym zdobywają oni niezbęd-
ną wiedzę na temat wszystkich dostępnych procesów organizacyjnych,
dowiadują się o miejscu ich przechowywania, rodzajach szablonów (ang.

templates), których mogą używać, a także do kogo, w razie pytań, mo-
gą się zwrócić o pomoc. Szkolenia tego typu zazwyczaj prowadzone są
przez ekspertów procesowych, którzy albo uczestniczyli w pracach nad
definiowaniem określonych procesów, albo ich ekspertyza i doświadcze-
nie są na tyle wysokie, że takie szkolenia mogą prowadzić.

Dodatkowo, organizacje, które właściwie zarządzają swoimi proce-

sami wytwórczymi, utrzymują wspólne repozytorium, w którym skła-
dowane są wszystkie procesy w postaci konkretnych plików „doc”, czy
„pdf”. Repozytorium to najczęściej nazywane jest

Process Asset Library,

w skrócie PAL.

Podejście procesowe wymaga od firmy pewnego rodzaju dyscypli-

ny. Projekty muszą w pewnym sensie wyzbyć się swojego indywiduali-
zmu – niepowtarzalności, na rzecz zdefiniowanego procesu organizacji.
Brzmi to nieco kontrowersyjnie, w praktyce jednak oznacza wiele dobre-
go, szczególnie, z perspektywy klienta i jego produktu. Załóżmy, że ma-
my do czynienia z organizacją, która realizuje dziesiątki projektów infor-
matycznych rocznie. Wyzbycie się indywidualizmu na poziomie projek-
tów oznacza, iż wymagania zbierane są zgodnie z przyjętym procesem:
plany projektowe tworzone są z użyciem wspólnego szablonu, struktu-

ra podziału pracy (ang.

Work Breakdown Structure) wprowadzana jest do

wspólnego narzędzia, kod pisany jest zgodnie z przyjętym standardem,
testy, przeprowadzane są na podstawie wcześniej zdefiniowanego planu.
Taki brak indywidualizmu powoduje, iż każdy z realizowanych projektów
w organizacji jest przewidywalny, tzn. jeżeli zostaną spełnione określone
warunki początkowe (które definiuje proces), to z pewnością jesteśmy w
stanie przewidzieć jego rezultaty końcowe. Każdy z realizowanych pro-
jektów jest więc w pewien sposób podobny, jednolity – pozbawiony swo-
jej niepowtarzalności.

Indywidualizm projektowy należy jednak odróżnić od indywidu-

alizmu pracowniczego, który – zarówno w tradycyjnych, jak i agile’o-
wych metodach tworzenia oprogramowania ma charakter niezbywal-
ny! Dzięki niemu właśnie możliwa jest kreatywność, która sprawia,
że wszelkie problemy projektowe mogą być rozwiązane na kilka moż-
liwych sposobów, a development produktu staje się niezwykle dyna-
miczny i twórczy.

Capability Maturity Model Integration (CMMI)

Jednym z czołowych reprezentantów tradycyjnych metod tworzenia
oprogramowania jest Capability Maturity Model Integration. Pełni on funk-
cję swoistego drogowskazu na drodze doskonalenia procesów tworzenia
oprogramowania w organizacji. Składa się ze zbioru dobrych (

dojrzałych)

praktyk inżynierii oprogramowania, sprawdzonych i zaimplementowa-
nych w wielu organizacjach informatycznych. CMMI nie mówi nam jednak,
jakie konkretne praktyki powinniśmy zaimplementować w naszej firmie,
aby obecne w niej procesy były powtarzalne, a przez to stabilne. CMMI je-
dynie podpowiada pewne rozwiązania. Na przykład, jedną z dobrych prak-
tyk, sugerowaną przez CMMI w ramach obszaru procesowego: „Planowa-
nie projektu”, jest sporządzenie jego planu. Model akcentuje, na co należy

Tabela 2.

Obszary Procesowe modelu CMMI wraz z kategoriami, do których zostały przypisane oraz poziomami dojrzałości

Obszar Procesowy

Kategoria

Poziom dojrzałości

Analiza przyczyn i działania prewencyjne (Causal Analysis and Resolution)

Wsparcie

5

Zarządzanie konfiguracją (Configuration Management)

Wsparcie

2

Analiza decyzyjna (Decision Analysis and Resolution)

Wsparcie

3

Zintegrowane zarządzanie projektem (Integrated Project Management + IPPD) Zarządzanie projektem

3

Miary i analizy (Measurement and Analysis)

Wsparcie

2

Innowacje i wdrożenia (Organizational Innovation and Deployment)

Zarządzanie procesem

5

Definicja procesu organizacyjnego (Organizational Process Definition + IPPD)

Zarządzanie procesem

3

Koncentracja na procesie organizacyjnym (Organizational Process Focus)

Zarządzanie procesem

3

Wydajność procesu organizacyjnego (Organizational Process Performance)

Zarządzanie procesem

4

Szkolenia organizacyjne (Organizational Training)

Zarządzanie procesem

3

Integracja produktu (Product Integration)

Inżynieria

3

Monitoring i kontrola (Project Monitoring and Control)

Zarządzanie projektem

2

Planowanie projektu (Project Planning)

Zarządzanie projektem

2

Zapewnienie jakości procesu i produktu (Process Product Quality Assurance)

Wsparcie

2

Ilościowe zarządzanie projektem (Quantitative Project Management)

Zarządzanie projektem

4

Rozwój wymagań (Requirements Development)

Inżynieria

3

Zarządzanie wymaganiami (Requirements Management)

Inżynieria

2

Zarządzanie ryzykiem (Risk Management)

Zarządzanie projektem

3

Zarządzanie dostawcami (Supplier Agreement Management)

Zarządzanie projektem

2

Rozwiązania techniczne (Technical Solution)

Inżynieria

3

Walidacja (Validation)

Inżynieria

3

Weryfikacja (Verification)

Inżynieria

3

Extreme Programming i CMMI

57

www.sdjournal.org

Software Developer’s Journal 11/2007

zwrócić szczególną uwagę przy konstruowaniu takiego dokumentu, wy-
mienia przykładowe jego elementy, a także wskazuje, z jakimi, innymi ob-
szarami procesowymi proces planowania projektu jest powiązany. CMMI
jest więc czymś, w rodzaju „układu odniesienia” – zbioru punktów (obsza-
ry procesowe), względem których określa się położenie lub zmianę po-
łożenia danego ciała (organizacji). Z jednej strony, umożliwia nam ocenę
dojrzałości procesów wytwórczych w organizacji, z drugiej zaś – pomaga
w zdefiniowaniu planu ich poprawy.

Początki

Pierwsza wersja Capability Maturity Model powstała w 1987 roku. Została
opracowana przez grupę amerykańskich programistów, pracujących w So-
ftware Engineering Institute (SEI), przy Carnegie Mellon University, w Pit-
tsburghu. Instytut od samego początku swego istnienia był i nadal jest
sponsorowany przez Departament Obrony Stanów Zjednoczonych (DoD),
za pośrednictwem Biura Podsekretarza Obrony ds. Zaopatrzenia, Techno-
logii i Logistyki (OUSD/AT&L). Celem utworzenia SEI było wypracowanie
metod, które zwiększałyby skuteczność realizowanych przez DoD projek-
tów informatycznych tak, by nie przekraczały one zaplanowanego czasu,
mieściły się w założonym budżecie oraz były dostarczane w ręce klien-
ta bez okrojonej funkcjonalności. W tym celu opracowano tzw. „kwestio-
nariusz oceny dojrzałości procesów” (ang.

maturity questionnaire), który

przeprowadzono w organizacjach, będących podwykonawcami DoD. Skła-
dał się on z 85 pytań dotyczących między innymi takich zagadnień jak:
planowanie projektu informatycznego, śledzenie postępu jego prac, za-
rządzanie harmonogramem, zarządzanie wymaganiami, zarządzanie kon-
figuracją, zapewnienie jakości tworzonego oprogramowania oraz ciągłe
doskonalenie procesu. Jak się okazało, wśród setek przebadanych firm
wykryto pewne prawidłowości w zakresie wytwarzanego oprogramowa-
nia. Proces „dojrzewania” do określonego poziomu jakości i produktywno-
ści, w każdym z badanych przypadków, miał podobny przebieg. Wnioski,
wypływające z przeprowadzonych badań, a także zaobserwowane dobre
praktyki projektowe, zebrano i opisano, w wyniku czego, w 1991 roku po-
wstała pierwsza miniatura modelu CMM – Capability Maturity Model for So-
ftware (SW–CMM), wersja 1.0. Model ten skupiał się na doskonaleniu pro-
cesów wytwórczych, ale tylko w organizacjach, zajmujących się wytwa-
rzaniem oprogramowania. Po dwóch latach, w roku 1993, powstała kolej-
na wersja 1.1, której kontynuatorką w roku 1997 miała być wersja 2.0, któ-
ra powstała jedynie jako wersja robocza – nigdy nie doczekała się swojego
oficjalnego wydania. Prace jednak nad wersją 2.0 nie poszły na marne, zo-
stały one wykorzystane przy okazji tworzenia modelu CMMI.

Sukces i ogromna popularność modelu SW–CMM wśród organizacji

zajmujących się tworzeniem software’u, spowodował, iż w 1995 roku gru-

pa Enterprise Process Improvement Collaboration (EPIC), zrzeszająca or-
ganizacje rządowe, przemysłowe, a także akademickie opracowała Sys-
tem Engineering Capability Maturity Model (SE–CMM). Dodatkowo, w tym
samym czasie, International Council on System Engineering (INCOSE),
stworzyła listę kontrolną (ang.

checklist), mającą na celu ocenę dojrza-

łości procesów w organizacjach, zajmujących się inżynierią systemów.
Z czasem pytania z listy kontrolnej, zostały przekształcone i opracowa-
ne w postaci System Engineering Capability Assessment Model (SECAM).
Po kilku latach dyskusji nad sensownością utrzymywania dwóch podob-
nych modeli, utworzono jeden – Electronic Industries Alliance (EIA) Inte-
rim Standard 731, znany również jako System Engineering Capability Mo-
del (SECM).

Dodatkowo, w 1996 roku, powstał Acquisition Capability Maturity Mo-

del (SA–CMM), który jest zorientowany przede wszystkim na akwizycję –
adresuje potrzeby tych działów danego przedsiębiorstwa, które zajmu-
ją się pozyskiwaniem nabywców, zbieraniem zamówień handlowych, za-
wieraniem umów o wykonanie określonych usług itp.

Software Engineering Insitute zwrócił także uwagę na doskonalenie

tzw. „miękkich umiejętności” w przedsiębiorstwach, a więc to wszystko,
co składa się na dziedzinę zarządzania zasobami ludzkimi. W 1995 roku
powstał People Capability Maturity Model (People CMM), który stanowi
zbiór dobrych praktyk, z zakresu kierowania ludźmi, rozwijania obecnego
w nich potencjału, pogłębiania komunikacji interpersonalnej, a także wła-
ściwego zarządzania wiedzą w organizacji.

W tym samym też czasie, doszło do opublikowania modelu Inegra-

ted Product Development CMM (IPD–CMM), który ukazał się tylko w wer-
sji roboczej i zawierał praktyki, mające na celu doskonalenie procesów
wytwórczych z zakresu zintegrowanego zarządzania produktem. W je-
go powstaniu, dość dużą rolę odegrała, wspomniana grupa EPIC. Model
IPD–CMM miał stanowić pewnego rodzaju szkielet, do którego można
by było dopasować pozostałe modele rodziny CMM, takie jak SW–CMM,
czy SE–CMM. Był to pierwszy moment, kiedy uwidoczniły się potrzeby
stworzenia jednego modelu, który miałby zastosowanie w wielu dyscy-
plinach.

Integracja

Mimo, że wszystkie modele rodziny CMM, cieszyły się dużą popularno-
ścią wśród przedsiębiorstw, każdy z nich dotykał jakby innego problemu/
dziedziny. Implementacja kilku modeli, była niezwykle kosztowna dla or-
ganizacji, która chciała jednocześnie doskonalić swoje procesy wytwór-
cze w kilku dziedzinach. Wiązało się to z dodatkowymi nakładami w po-
staci szkoleń pracowniczych, oceny stopnia implementacji praktyk, któ-
re zazwyczaj przeprowadzane są przez zewnętrzne firmy, a także sa-
mych nakładów organizacyjnych, które w tego rodzaju przedsięwzię-
ciach są przecież niemałe. Dlatego Software Engineering Institute, w
1997 roku, rozpoczął bardzo intensywne prace nad modelem, który miał-
by charakter kompleksowy, i który można by było zaimplementować w
organizacjach o różnych profilach działalności. W efekcie powstał Capa-
bility Maturity Model Integration (CMMI). Zespół SEI, a konkretnie „CMMI
Product Team”, do jego stworzenia wykorzystał trzy modele źródłowe
(ang.

source models):

• The Capability Maturity Model for Software (SW–CMM), v2.0 draft C;
• The System Engineering Capability Maturity Model (SECM);
• The Integrated Product Development Capability Maturity Model (IPD–

CMM), v0.98.

Modele te zostały wykorzystane przede wszystkim ze względu na ich
ogromną popularność i zastosowanie w wielu organizacjach. W efekcie
powstał model, który mógł być wdrożony zarówno w firmach, które po-

Rysunek 2.

Ewolucja modelu CMMI

�����������������

�����������

������������

������

�������������������

����������������

������������������

�����������

������

�������������

�����������

������

������������

������

�����������������

������������

��������������������

������������

������������

������������

��������������������

������������

58

Inżynieria

oprogramowania

www.sdjournal.org

Software Developer’s Journal 11/2007

siadały już jeden ze wspomnianych wcześniej modeli, jak i tych, – któ-
re dopiero zaczynały swoją przygodę z programem doskonalenia proce-
sów wytwórczych. CMMI Product Team, przygotował trzy odmiany mode-
lu CMMI:

• CMMI–SE/SW, v.1.0 – wersja łącząca praktyki z dziedziny inżynierii

systemów (ang. System Ingineering) oraz inżynierii oprogramowania
(ang.

Software Engineering).

• CMMI–SE/SW/IPPD, v.1.0 – oprócz praktyk wymienionych w punkcie

1, wersja ta zawierała rozszerzenie o praktyki z zakresu zintegrowa-
nego zarządzania produktem i procesem w organizacji (ang.

Integra-

ted Product and Process Development).

• CMMI–SE/SW/IPPD/SS, v. 1.0 – jedyna wersja, która pojawiła się w for-

mie roboczej. Oprócz praktyk wskazanych w punktach 1–2, dodatko-
wo została wzbogacona o praktyki z dziedziny zarządzania dostaw-
cami (ang.

Supplier Sourcing). Model ten, był przeznaczony wyłącznie

do użycia w projektach pilotażowych.

Po dwóch latach stosowania odmian modelu CMMI w organizacjach, po
uwzględnieniu około 1500 propozycji zmian (ang

. change request), set-

kach komentarzy, zdecydowano się na publikację kolejnej wersji modelu
1.1 w roku 2002. Oprócz wspomnianych trzech, pojawiła się czwarta od-
miana, skupiająca w sobie tylko te praktyki, które dotyczyły poprawy pro-
cesów tworzenia oprogramowania w organizacjach, zajmujących się two-
rzeniem software’u.

Popularność wersji 1.1 modelu CMMI, przerosła najśmielsze ocze-

kiwania Software Engineering Institute. Przeszkolono ponad 45 tysięcy
ludzi, przeprowadzono około 1500 ocen (ang.

appraisal), mających na

celu zmierzenie dojrzałości procesów wytwórczych różnych organiza-
cji w kontekście praktyk zdefiniowanych w modelu CMMI. Implementacja
modelu CMMI okazała się możliwa w wielu różnych organizacjach. Model
CMMI okazał się być na tyle uniwersalny, że jego użycie stało się możliwe
w organizacjach, zajmujących się nie tylko developmentem software’u.
Praktyki obecne w modelu, a dotyczące właściwego zarządzania proce-
sem oraz projektem, były na tyle uniwersalne, że ich implementacja oka-
zała się możliwa na gruncie wielu organizacji, co zaowocowało powsta-
niem wersji 1.2 Capability Maturity Model Integration (Rysunek 2). Źródło:
CMMI Product Team, CMMI for Development, Version 1.2 (CMU/SEI–2006–
TR–008), Pittsburgh, PA: Software Engineering Institute, Carnegie Mellon
University, 2006.

Architektura

Zmiany, które pojawiły się w ostatniej wersji modelu 1.2, dotyczą przede
wszystkim jego architektury. W obecnej formie, umożliwia ona dopaso-
wanie modelu CMMI do potrzeb różnych organizacji. Jednym z jej podsta-

wowych elementów jest tzw, „szkielet CMMI” (ang.

CMMI Framework), któ-

ry składa się z 3 komponentów:

• modelu (ang.

model components) – obszary procesowe (ang. process

areas), praktyki, materiały informacyjne, stanowiące dla organizacji
pomoc w implementacji wymagań modelu CMMI;

• szkoleń (ang.

training components) – materiały szkoleniowe, prze-

wodniki wyjaśniające zasady związane z implementacją modelu,
oraz wszelkie pomoce audi–wizualne, przekazujące wiedzę związa-
ną z praktycznym wdrożeniem praktyk modelu CMMI;

• oceny (ang.

appraisal components) – zasady opisujące metodę oce-

ny dojrzałości procesów wytwórczych organizacji w kontekście ce-
lów i praktyk opisanych w modelu. Na obszar ten składają się również
wszelkie szkolenia, związane z organizowaniem i przeprowadzaniem
ocen (ang.

appraisals).

Szkielet CMMI dostarcza nam pewnej struktury, którą należy jedynie wy-
pełnić praktykami, dotyczącymi konkretnych obszarów zainteresowań.
Nie musimy tworzyć nowej terminologii, programów szkoleń, metod oce-
ny – to wszystko zapewnia nam dostępny szkielet.

Kolejnym ważnym pojęciem, związanym z architekturą mode-

lu CMMI jest pojęcie „konstelacji” (ang.

constellation). Jest to takie po-

łączenie komponentów szkieletu CMMI, które umożliwia doskonalenie
procesów wytwórczych w określonym obszarze jej zainteresowań (np.
w sferze usług, czy rozwoju oprogramowania). W chwili obecnej, istnie-
ją 3 konstelacje, z których – jak dotąd – jedynie pierwsza została opu-
blikowana:

• CMMI for Development (CMMI–DEV) – wspiera organizacje, zajmujące

się developmentem produktów lub usług;

• CMMI for Services (CMMI–SVC) – wspiera organizacje, zajmujące się

dostarczaniem usług;

• CMMI for Acquisition (CMMI–ACQ) – wspiera organizacje zajmujące się

pozyskiwaniem produktów i usług od zewnętrznych poddostawców.

W skład każdej konstelacji, oprócz materiałów szkoleniowych oraz me-
tod oceny, wchodzi tzw. „podstawa modelu CMMI” (ang.

CMMI model fo-

undation) – zbiór komponentów, które są wspólne dla wszystkich odmian
modelu CMMI. Tworzą ją określone obszary procesowe, ogólne cele i prak-
tyki, a także wspólny słownik (ang.

glossary). Natomiast to, co decyduje o

powstaniu nowego modelu, w ramach danej konstelacji, to pewne dodat-
ki, które rozbudowywane są w oparciu o jego podstawę (Rysunek 3). Na

Rysunek 3.

Szkielet modelu CMMI (ang. CMMI Framework)

��������

�����������

�����������

���������

������������

������

�����

�����������

��������

������

�������

Rysunek 4.

Reprezentacja stała (ang. staged) modelu CMMI

������������

�

������������

�

������������

�

������������

���������

�

��������������

�

�����������������

��

59

Extreme Programming i CMMI

www.sdjournal.org

Software Developer’s Journal 11/2007

podstawie: D. M. Ahern, A. Clouse, R. Turner, CMMI Distilled: A Practical In-
troduction to Integrated Process Improvement, Second Edition, Boston:
Addison–Wesley, 2003.

CMMI for Development (CMMI–DEV)

Konstelacja CMMI for Development składa się z dwóch modeli: CMMI for
Development + IPPD (ang.

Integrated Product and Process Development)

oraz CMMI for Development (bez dodatków IPPD). Ponieważ model CMMI–
DEV+IPPD, oprócz wspomnianych dodatków, w zasadzie niczym nie róż-
ni się od CMMI–DEV, Software Engineering Institute opublikował tylko je-
den z nich CMMI–DEV+IPPD. Model jest do pobrania na stronie SEI (

http:/

/www.sei.cmu.edu/cmmi/), która oprócz wszystkich dotychczasowych
wersji modelu, zawiera liczne, ciekawe opracowania (pliki „pdf” i „doc”) z
zakresu różnych dziedzin inżynierii oprogramowania. Dostęp do wszyst-
kich materiałów jest oczywiście bezpłatny.

Grupa dodatków IPPD, obecnych w modelu CMMI–DEV+IPPD, skupia

w sobie praktyki, które dotyczą rozwoju zintegrowanych procesów i pro-
duktów w organizacji. Są one szczególnie pomocne dla tych organizacji, w
których praca podzielona jest pomiędzy zespoły projektowe, skupione w
różnych lokalizacjach (zespoły rozproszone). Zasady zawarte w dodatku
IPPD, określają reguły właściwej komunikacji w zespołach projektowych,
promują umiejętne zarządzanie wiedzą oraz doświadczeniem pracowni-
ków, a także zawierają wytyczne, dotyczące tworzenia niezbędnej infra-
struktury organizacyjnej w zakresie praktyk IPPD. Dodatki IPPD zosta-
ły przypisane do tych obszarów procesowych modelu CMMI, które w ja-
kiś sposób pozostają zbieżne z obecną w nich tematyką (Tabela 2). Sporo
ciekawych informacji na temat IPPD, można znaleźć w publikacji Departa-
mentu Obrony Stanów Zjednoczonych (United States Department of De-
fense): DoD guide to Introduction Product and Process Development (Ver-
sion 1.0), Washington DC, Office of the Under Secretary of Defense (Acqu-
isition and Technology), 1996 – materiał do pobrania na stronie:

https://

acc.dau.mil/.

Jeden Model, Dwie reprezentacje

Model CMMI składa się z 22 obszarów procesowych (ang.

Proces Areas),

które organizacja może doskonalić w ramach dwóch reprezentacji: sta-
łej (ang.

staged) i ciągłej (ang. continuous). Reprezentacja stała, umożli-

wia doskonalenie procesów wytwórczych, w ramach ściśle zdefiniowanej
ścieżki rozwoju. Wyznacza ją pięć poziomów dojrzałości (ang.

maturity le-

vels), co obrazuje(Rysunek 4)

Każdy z poziomów dojrzałości składa się z określonej liczby obsza-

rów procesowych, które organizacja musi zaimplementować, aby zna-
leźć się na określonym poziomie dojrzałości CMMI. Warto zauważyć, iż
obszary procesowe w tej reprezentacji zostały tak zaprojektowane, iż
nie jest możliwe osiągnięcie poziomu 3, nie spełniając wcześniej wyma-
gań poziomu 2 – podobnie, w przypadku poziomu 4, czy 5. W ten spo-
sób, doskonalenie procesów wytwórczych w reprezentacji stałej ma
charakter przyrostowy (inkrementalny). Organizacja posiada nieja-
ko gotowy program doskonalenia, obecnych w niej procesów wytwór-
czych. Jest to dobre rozwiązanie dla tych przedsiębiorstw, które nie po-
siadają wystarczającej wiedzy na temat stopnia zaawansowania swo-
ich procesów wytwórczych, a co za tym idzie – trudno jest im jedno-
znacznie zdecydować, jak powinien wyglądać ich plan doskonalenia. W
takiej sytuacji, zastosowanie reprezentacji stałej może się okazać nie-
zwykle pomocne.

Gdy jednak organizacja, posiada ugruntowaną wiedzę na temat

swoich procesów wytwórczych, wówczas dobrze jest skorzystać z
rozwiązań, które proponuje nam reprezentacja ciągła. Umożliwia ona
skupienie się tylko na tych obszarach procesowych, które wymagają
szczególnej poprawy. W reprezentacji ciągłej pojawia się pojęcie po-

ziomów wydolności procesu (ang.

capability levels), które obrazują

poziom instytucjonalizacji procesu w organizacji. Obszary proceso-
we w reprezentacji ciągłej mogą być doskonalone w ramach sześcio-
stopniowej skali od 0 do 5. Wydolność procesów wytwórczych może
być zróżnicowana, co ilustruje (Rysunek 5). To organizacja decyduje
o tym, który proces wymaga poprawy oraz w jakim zakresie. Źródło:
D. M. Ahern, A. Clouse, R. Turner, CMMI Distilled: A Practical Introduc-
tion to Integrated Process Improvement, Second Edition, Boston: Ad-
dison–Wesley, 2003.

W reprezentacji ciągłej, obszary procesowe zostały podzielone na 4

kategorie: Zarządzanie procesem (ang.

Process Management), Zarządza-

nie projektem (ang.

Project Management), Inżynieria (ang. Engineering)

oraz Wsparcie (ang.

Support). Zestawienie wszystkich obszarów obrazu-

je Tabela 2, podając nazwę procesu wraz z przypisaniem go do określo-
nej kategorii oraz poziomu dojrzałości modelu CMMI. Obszary te zostaną
szczegółowo omówione oraz zestawione z wybranymi praktykami me-
tody

Extreme Programming, w kolejnej, ostatniej części prezentowanego

cyklu, która ukaże się w kolejnym numerze pisma. Źródło: M. B. Chrissis,
M. Konrad, S. Shrum, CMMI: Guidelines for Process Integration and Pro-
duct Improvement, Addison–Wesley, 2007.

Podsumowanie

Artykuł jest kolejną częścią cyklu artykułów, poświęconych porówna-
niu dwóch metod tworzenia oprogramowania – „lekkich”, reprezentowa-
nych przez podejście określane mianem

Extreme Programming oraz „tra-

dycyjnych”, których istotę oddaje model CMMI. Publikacja przedstawia
charakterystykę tradycyjnych metod tworzenia oprogramowania, które
wykorzystują najczęściej kaskadowy cykl życia projektu software’owe-
go (wymagania/projekt/implementacja), a ich cechą charakterystyczną
jest precyzyjnie zdefiniowany proces, który podlega ciągłemu doskona-
leniu. Metody te, wyrażają wszystko to, co mieści w sobie pojęcie: „dys-
cypliny”. Dodatkowo, w artykule omówione zostały podstawowe założe-
nia modelu CMMI (jego geneza, struktura, reprezentacje), który należy do
jednego z bardziej znanych reprezentantów tradycyjnych metod tworze-
nia oprogramowania.

W trzeciej, ostatniej części prezentowanego cyklu, która ukaże się

w kolejnym numerze pisma, przedstawiona zostanie próba pogodzenia
tych dwóch, pozornie odmiennych, stanowisk: „lekkiego” (

Extreme Pro-

gramming) oraz „strukturalnego” (CMMI). Praktyki metody XP zesta-
wione zostaną z obszarami procesowymi (ang.

Process Areas) mode-

lu CMMI. n

Rysunek 5.

Reprezentacja ciągła (ang. continuous) modelu CMMI

���������

�

�

�

�

�

��������

��������

��������

����

������