plik

Inżynieria

oprogramowania

www.sdjournal.org

Software Developer’s Journal 11/2007

Extreme Programming i CMMI

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:

mariusz.chrapko@gmail.com

Extreme Programming i CMMI

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

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

Zarządzanie konfiguracją (Configuration Management)

Wsparcie

Analiza decyzyjna (Decision Analysis and Resolution)

Wsparcie

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

Miary i analizy (Measurement and Analysis)

Wsparcie

Innowacje i wdrożenia (Organizational Innovation and Deployment)

Zarządzanie procesem

Definicja procesu organizacyjnego (Organizational Process Definition + IPPD)

Zarządzanie procesem

Koncentracja na procesie organizacyjnym (Organizational Process Focus)

Zarządzanie procesem

Wydajność procesu organizacyjnego (Organizational Process Performance)

Zarządzanie procesem

Szkolenia organizacyjne (Organizational Training)

Zarządzanie procesem

Integracja produktu (Product Integration)

Inżynieria

Monitoring i kontrola (Project Monitoring and Control)

Zarządzanie projektem

Planowanie projektu (Project Planning)

Zarządzanie projektem

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

Wsparcie

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

Zarządzanie projektem

Rozwój wymagań (Requirements Development)

Inżynieria

Zarządzanie wymaganiami (Requirements Management)

Inżynieria

Zarządzanie ryzykiem (Risk Management)

Zarządzanie projektem

Zarządzanie dostawcami (Supplier Agreement Management)

Zarządzanie projektem

Rozwiązania techniczne (Technical Solution)

Inżynieria

Walidacja (Validation)

Inżynieria

Weryfikacja (Verification)

Inżynieria

Extreme Programming i CMMI

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

��

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

��

�

��

�

��

�

��

�

��

�

��

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

��

�

��