Inżynieria
oprogramowania
Extreme Programming i CMMI
Mariusz Chrapko
rtykuł jest drugą częścią cyklu, poświęconego porów- procedur i narzędzi. Proces, jest tym wszystkim, co inte-
naniu dwóch metod tworzenia oprogramowania   lek- gruje wymienione obszary. Pracownik, mając do dyspozycji
Akich , reprezentowanych przez metodę Extreme Pro- określony zestaw narzędzi, kierując się odpowiednio dobra-
gramming oraz  tradycyjnych (określanych niekiedy jako nym zbiorem procedur, może przekształcić surowy materiał
 strukturalne ), które odzwierciedla model CMMI. (dane wejściowe) w gotowy produkt (dane wyjściowe), któ-
W poprzedniej części, omówiona została, jedna z bar- ry będzie stanowił wartość biznesową z punktu widzenia na-
dziej znanych tzw. zwinnych metod programowania  Extre- szego klienta.
me Programming (XP). Metoda ta mieści w sobie wszystko to, Proces tworzenia oprogramowania, możemy zdefiniować
co uosabia pojęcie kreatywności  spontaniczność, zwinność jako zespół aktywności, metod oraz praktyk, stosowanych w
(ang. agility), otwartość na zmianę, a także odwaga w przekra- celu wytworzenia i podtrzymania (ang. maintenance) działają-
czaniu stereotypów. Konkretne wartości XP, zasady, a przede cego software u. Warto zauważyć, iż proces ten skupia się nie
wszystkim praktyki developerskie, osadzone zostały w re- tylko na oprogramowaniu samym w sobie, ale także na wszel-
aliach cyklu życia projektów agile owych. kich dodatkowych artefaktach, które jego powstaniu towarzy-
Druga część prezentowanego cyklu, przedstawia krótką szą  plany projektowe, wymagania, projekt systemu, kod, czy
charakterystykÄ™ tradycyjnych metod tworzenia oprogramo- przypadki testowe.
wania, wraz z omówieniem genezy oraz podstawowej struk-
tury modelu CMMI (szkielet modelu, podstawowe komponen- Metody  Plan Driven
ty, konstelacje, obszary procesowe), który należy do bodaj- Tradycyjne metody tworzenia oprogramowania nazywane są
że najbardziej popularnych reprezentantów podejść struktu- niekiedy metodami typu  plan driven (wiedzione planem).
ralnych. Ich geneza związana jest z inżynierią systemów. W czasie,
gdy rozwijał się przemysł aerokosmiczny  satelity, statki ko-
Proces tworzenia oprogramowania smiczne, rakiety balistyczne  zasady inżynierii systemów
Tradycyjne metody wytwarzania oprogramowania w sposób były wykorzystywane do koordynowania dużej liczby wzajem-
nierozerwalny związane są z pojęciem  procesu jego tworze- nie ze sobą oddziaływujących komponentów, dostarczanych
nia. Proces, najogólniej rzecz biorąc, to pewien zestaw kroków, niekoniecznie przez jednego dostawcę. O ile komponenty har-
wykonywanych w określonym celu. Jego istotę, bardzo traf- dware owe bardzo dobrze się wkomponowywały w ten para-
nie oddaje film Roberta Altmana: The Company (USA/Niemcy dygmat, o tyle software do niego zupełnie nie przystawał. Za-
2003), który we współpracy z zespołem Joffrey Ballet of Chi- rządzano nim w sposób wysoce niezdyscyplinowany, co oczy-
cago, przedstawia znakomite występy tancerzy oprawione wiście skutkowało niedotrzymywaniem terminów, przekracza-
grą światła, kolorów i muzyki. Taniec wyraża proces w pełnym niem zaplanowanego budżetu, a przede wszystkim niską jako-
tego słowa znaczeniu. Nad jego właściwą definicją czuwa cho- ścią wytwarzanych produktów.
reograf, który odpowiada za stworzenie ogólnej koncepcji ukła- Żeby to zmienić, Departament Obrony Stanów Zjedno-
du tanecznego. Określa poszczególne ruchy tancerzy, ewolu- czonych (United States Departement of Defense, w skró-
cje, kroki, obroty, skoki, i dzięki nim przekazuje akcję  nastrój cie DoD), przygotował zestaw instrukcji, których celem by-
dzieła. Taniec oddaje życie organizacji  procesy, które nią kie- ło dopasowanie procesu tworzenia oprogramowania do wy-
rują. Metaforę tę w sposób znakomity wykorzystała Kim Capu- magań, które stawiała inżynieria systemów. Pojawiły się ta-
to, w książce CMM Implementation Guide. Choreographical So- kie dokumenty jak: MIL STD 1521, DoD STD 2167, czy MIL
ftware Process Improvement (Addison Wesley, 1998), gdzie STD 498. Dodatkowo, w tym samym czasie, duże firmy ko-
proces tworzenia oprogramowania opisany został właśnie za mercyjne (IBM, Siemens, Hitachi), przygotowały podobne
pomocą języka choreografii. standardy, przeznaczone do użytku wewnętrznego. Z cza-
Mówiąc o procesie w kontekście całej organizacji, nie sem, gdy inżynieria oprogramowania stawała się coraz bar-
sposób pominąć jej trzech podstawowych wymiarów: ludzi, dziej popularna, coraz większego znaczenia nabierały me-
tody, majÄ…ce na celu  zdyscyplinowanie procesu tworzenia
oprogramowania.
Autor pracuje w Motorola Polska Electronics sp. z o.o. (krakow-
skie Centrum Oprogramoawnia Motoroli) na stanowisku inżynie-
Charakterystyka
ra jakości. Od strony zawodowej interesuje się problematyką do-
Metody typu plan driven wykorzystują najczęściej kaska-
skonalenia procesu tworzenia oprogramowania w oparciu o Mo-
dowy cykl życia oprogramowania, który to, na proces two-
del CMMI®, a także praktykami Agile Software Development. Pry-
watnie lubi jazz i filozofię (głównie współczesną). W wolnych chwi- rzenia oprogramowania każe nam patrzeć liniowo  kolej-
lach fotografuje. ne fazy (analiza i specyfikacja wymagań /projektowanie/
Kontakt z autorem: [e-mail]
implementacja, testy, wdrożenie i pielęgnacja) występują se-
kwencyjnie, jedna po drugiej. Dodatkowo, dość duży nacisk
54
www.sdjournal.org
Software Developer s Journal 11/2007
Extreme Programming i CMMI
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
położony jest na dokumentację poszczególnych faz projektowych. Każ- rej każdy wie, gdzie, w razie potrzeby, może znalez
ć potrzebne mu infor-
da faza realizacji projektu, zwiÄ…zana jest z opracowaniem szeregu doku- macje oraz czego projekt od niego oczekuje. Dodatkowo, znika problem
mentów, opisujących jej rezultaty, które to z kolei stanowią dane wej- migracji międzyprojektowej. Menedżerowie, mając ludzi posiadających
ściowe do kolejnej. znajomość procesów w organizacji, mogą dowolnie przypisywać osoby
Cechą charakterystyczną tradycyjnych metod tworzenia oprogra- do różnych projektów, bez ryzyka poniesienia klęski. Oczywiście dość
mowania jest precyzyjnie zdefiniowany proces, który podlega ciągłe- ważną rzeczą, o której nie wolno nam zapominać, jest ekspertyza, a co za
mu doskonaleniu. Dobrze zdefiniowany proces to taki, którego struktu- tym idzie indywidualizm poszczególnych członków zespołu projektowe-
rę tworzą następujące elementy: y
ródło: A Software Process Framework go. Wynika ona ze szczególnie dobrej znajomości określonej części pro-
for the SEI Capability Maturity Model
, Olson, Timothy G., CMU/SEI 94 HB duktu, procesu etc. Jest to czynnik, który będzie zawsze nierozerwalnie
01, 1994. zwiÄ…zany z pracownikiem  stanowi tzw. dobrÄ… energiÄ™ projektu i, tak na-
Mając dobrze zdefiniowany proces, czas na kolejny krok  jego im- prawdę, od menedżera zależy jak ją wykorzysta.
plementację i instytucjonalizację. Implementacja  to wykonywanie kon- Podejście procesowe niesie ze sobą również pewne zagrożenia. Kie-
kretnych aktywności projektowych w ramach danego obszaru proce- dy organizacja zbytnio skupi się na procesie, może bardzo szybko za-
sowego (np. przygotowywanie planów projektowych w ramach procesu tracić perspektywę całego produktu, która przecież jest perspektywą
zwanego  Planowaniem Projektu ). naszego klienta. Może to być zabójcze dla innowacyjności oraz prowa-
Instytucjonalizacja z kolei, jest wynikiem wielokrotnej implementacji dzić do powstania czegoś, co niektórzy nazywają tzw.  mentalnością li-
danego procesu. Sytuacja taka, ma miejsce wówczas, gdy proces jest cał- sty kontrolnej (ang. checklist mentality). Pracownicy wówczas, bardziej
kowicie zintegrowany z działaniami danej organizacji i będzie on stoso- skupiają się na karmieniu z
le zdefiniowanego procesu, niż na tworzeniu
wany, nawet wówczas, gdy zmienią się wszyscy jej pracownicy. działającego, wolnego od defektów software u. Produkt wówczas zajmu-
Metody plan driven bardzo duży nacisk kładą na tzw. ilościowe za- je plan drugi  tak rodzi się dyktatura procesu.
rzÄ…dzanie procesem (ang. quantative process management). Procesy sÄ…
najpierw precyzyjnie definiowane, implementowane, by póz
niej móc nimi Wyznaczniki sukcesu
zarządzać właśnie w sposób ilościowy. Organizacje, mając do dyspozycji Tradycyjne metody tworzenia oprogramowania, silnie zorientowane
narzędzia w postaci statystycznej analizy procesu, zbierają metryki pro- na powtarzalność i ciągłe doskonalenie procesu, wymagają pełnego
cesowe, by póz
niej, na ich podstawie sporządzać tzw. wykresy kontrolne wsparcia i zaangażowania ze strony wyższego kierownictwa. Mene-
(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ć
Doskonalenie
jego zachowanie w przyszłości. Ilościowe zarządzanie procesem jest na-
procesu
rzędziem, które służy jego ciągłemu doskonaleniu. Dane, które organiza-
cja zbiera, a które są póz
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.
Definicja Kontrola Pomiar
Ciągłe doskonalenie procesów wytwórczych, zazwyczaj związa-
procesu procesu procesu
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Ä…
Egzekucja
MocnÄ… stronÄ… tradycyjnych metod tworzenia oprogramowania jest
procesu
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ó- Rysunek 1. Cykl doskonalenia procesu
Software Developer s Journal 11/2007 www.sdjournal.org
55
Inżynieria
oprogramowania
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
dżerowie muszą dostrzegać znaczenie dobrze zdefiniowanego i pod- ra podziału pracy (ang. Work Breakdown Structure) wprowadzana jest do
trzymywanego procesu z punktu widzenia produktu, który mają dostar- wspólnego narzędzia, kod pisany jest zgodnie z przyjętym standardem,
czyć klientowi. Organizacja musi stworzyć pewnego rodzaju infrastruk- testy, przeprowadzane są na podstawie wcześniej zdefiniowanego planu.
turę, której celem będzie podnoszenie świadomości pracowniczej w za- Taki brak indywidualizmu powoduje, iż każdy z realizowanych projektów
kresie istniejących procesów w firmie oraz zależności, które między ni- w organizacji jest przewidywalny, tzn. jeżeli zostaną spełnione określone
mi zachodzą. warunki początkowe (które definiuje proces), to z pewnością jesteśmy w
Taka infrastruktura, to systematyczne dostarczanie szkoleń proce- stanie przewidzieć jego rezultaty końcowe. Każdy z realizowanych pro-
sowych dla pracowników firmy, dzięki którym zdobywają oni niezbęd- jektów jest więc w pewien sposób podobny, jednolity  pozbawiony swo-
ną wiedzę na temat wszystkich dostępnych procesów organizacyjnych, jej niepowtarzalności.
dowiadują się o miejscu ich przechowywania, rodzajach szablonów (ang. Indywidualizm projektowy należy jednak odróżnić od indywidu-
templates), których mogą używać, a także do kogo, w razie pytań, mo- alizmu pracowniczego, który  zarówno w tradycyjnych, jak i agile o-
gą się zwrócić o pomoc. Szkolenia tego typu zazwyczaj prowadzone są wych metodach tworzenia oprogramowania ma charakter niezbywal-
przez ekspertów procesowych, którzy albo uczestniczyli w pracach nad ny! Dzięki niemu właśnie możliwa jest kreatywność, która sprawia,
definiowaniem określonych procesów, albo ich ekspertyza i doświadcze- że wszelkie problemy projektowe mogą być rozwiązane na kilka moż-
nie są na tyle wysokie, że takie szkolenia mogą prowadzić. liwych sposobów, a development produktu staje się niezwykle dyna-
Dodatkowo, organizacje, które właściwie zarządzają swoimi proce- miczny i twórczy.
sami wytwórczymi, utrzymują wspólne repozytorium, w którym skła-
dowane są wszystkie procesy w postaci konkretnych plików  doc , czy Capability Maturity Model Integration (CMMI)
 pdf . Repozytorium to najczęściej nazywane jest Process Asset Library, Jednym z czołowych reprezentantów tradycyjnych metod tworzenia
w skrócie PAL. oprogramowania jest Capability Maturity Model Integration. Pełni on funk-
Podejście procesowe wymaga od firmy pewnego rodzaju dyscypli- cję swoistego drogowskazu na drodze doskonalenia procesów tworzenia
ny. Projekty muszą w pewnym sensie wyzbyć się swojego indywiduali- oprogramowania w organizacji. Składa się ze zbioru dobrych (dojrzałych)
zmu  niepowtarzalności, na rzecz zdefiniowanego procesu organizacji. praktyk inżynierii oprogramowania, sprawdzonych i zaimplementowa-
Brzmi to nieco kontrowersyjnie, w praktyce jednak oznacza wiele dobre- nych w wielu organizacjach informatycznych. CMMI nie mówi nam jednak,
go, szczególnie, z perspektywy klienta i jego produktu. Załóżmy, że ma- jakie konkretne praktyki powinniśmy zaimplementować w naszej firmie,
my do czynienia z organizacją, która realizuje dziesiątki projektów infor- aby obecne w niej procesy były powtarzalne, a przez to stabilne. CMMI je-
matycznych rocznie. Wyzbycie się indywidualizmu na poziomie projek- dynie podpowiada pewne rozwiązania. Na przykład, jedną z dobrych prak-
tów oznacza, iż wymagania zbierane są zgodnie z przyjętym procesem: tyk, sugerowaną przez CMMI w ramach obszaru procesowego:  Planowa-
plany projektowe tworzone są z użyciem wspólnego szablonu, struktu- nie projektu , jest sporządzenie jego planu. Model akcentuje, na co należy
56
www.sdjournal.org
Software Developer s Journal 11/2007
Extreme Programming i CMMI
zwrócić szczególną uwagę przy konstruowaniu takiego dokumentu, wy- pa Enterprise Process Improvement Collaboration (EPIC), zrzeszająca or-
mienia przykładowe jego elementy, a także wskazuje, z jakimi, innymi ob- ganizacje rządowe, przemysłowe, a także akademickie opracowała Sys-
szarami procesowymi proces planowania projektu jest powiÄ…zany. CMMI tem Engineering Capability Maturity Model (SE CMM). Dodatkowo, w tym
jest więc czymś, w rodzaju  układu odniesienia  zbioru punktów (obsza- samym czasie, International Council on System Engineering (INCOSE),
ry procesowe), względem których określa się położenie lub zmianę po- stworzyła listę kontrolną (ang. checklist), mającą na celu ocenę dojrza-
łożenia danego ciała (organizacji). Z jednej strony, umożliwia nam ocenę łości procesów w organizacjach, zajmujących się inżynierią systemów.
dojrzałości procesów wytwórczych w organizacji, z drugiej zaś  pomaga Z czasem pytania z listy kontrolnej, zostały przekształcone i opracowa-
w zdefiniowaniu planu ich poprawy. ne w postaci System Engineering Capability Assessment Model (SECAM).
Po kilku latach dyskusji nad sensownością utrzymywania dwóch podob-
PoczÄ…tki nych modeli, utworzono jeden  Electronic Industries Alliance (EIA) Inte-
Pierwsza wersja Capability Maturity Model powstała w 1987 roku. Została rim Standard 731, znany również jako System Engineering Capability Mo-
opracowana przez grupę amerykańskich programistów, pracujących w So- del (SECM).
ftware Engineering Institute (SEI), przy Carnegie Mellon University, w Pit- Dodatkowo, w 1996 roku, powstał Acquisition Capability Maturity Mo-
tsburghu. Instytut od samego początku swego istnienia był i nadal jest del (SA CMM), który jest zorientowany przede wszystkim na akwizycję 
sponsorowany przez Departament Obrony Stanów Zjednoczonych (DoD), adresuje potrzeby tych działów danego przedsiębiorstwa, które zajmu-
za pośrednictwem Biura Podsekretarza Obrony ds. Zaopatrzenia, Techno- ją się pozyskiwaniem nabywców, zbieraniem zamówień handlowych, za-
logii i Logistyki (OUSD/AT&L). Celem utworzenia SEI było wypracowanie wieraniem umów o wykonanie określonych usług itp.
metod, które zwiększałyby skuteczność realizowanych przez DoD projek- Software Engineering Insitute zwrócił także uwagę na doskonalenie
tów informatycznych tak, by nie przekraczały one zaplanowanego czasu, tzw.  miękkich umiejętności w przedsiębiorstwach, a więc to wszystko,
mieściły się w założonym budżecie oraz były dostarczane w ręce klien- co składa się na dziedzinę zarządzania zasobami ludzkimi. W 1995 roku
ta bez okrojonej funkcjonalności. W tym celu opracowano tzw.  kwestio- powstał People Capability Maturity Model (People CMM), który stanowi
nariusz oceny dojrzałości procesów (ang. maturity questionnaire), który zbiór dobrych praktyk, z zakresu kierowania ludz
mi, rozwijania obecnego
przeprowadzono w organizacjach, będących podwykonawcami DoD. Skła- w nich potencjału, pogłębiania komunikacji interpersonalnej, a także wła-
dał się on z 85 pytań dotyczących między innymi takich zagadnień jak: ściwego zarządzania wiedzą w organizacji.
planowanie projektu informatycznego, śledzenie postępu jego prac, za- W tym samym też czasie, doszło do opublikowania modelu Inegra-
rządzanie harmonogramem, zarządzanie wymaganiami, zarządzanie kon- ted Product Development CMM (IPD CMM), który ukazał się tylko w wer-
figuracją, zapewnienie jakości tworzonego oprogramowania oraz ciągłe sji roboczej i zawierał praktyki, mające na celu doskonalenie procesów
doskonalenie procesu. Jak się okazało, wśród setek przebadanych firm wytwórczych z zakresu zintegrowanego zarządzania produktem. W je-
wykryto pewne prawidłowości w zakresie wytwarzanego oprogramowa- go powstaniu, dość dużą rolę odegrała, wspomniana grupa EPIC. Model
nia. Proces  dojrzewania do określonego poziomu jakości i produktywno- IPD CMM miał stanowić pewnego rodzaju szkielet, do którego można
ści, w każdym z badanych przypadków, miał podobny przebieg. Wnioski, by było dopasować pozostałe modele rodziny CMM, takie jak SW CMM,
wypływające z przeprowadzonych badań, a także zaobserwowane dobre czy SE CMM. Był to pierwszy moment, kiedy uwidoczniły się potrzeby
praktyki projektowe, zebrano i opisano, w wyniku czego, w 1991 roku po- stworzenia jednego modelu, który miałby zastosowanie w wielu dyscy-
wstała pierwsza miniatura modelu CMM  Capability Maturity Model for So- plinach.
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- Integracja
rzaniem oprogramowania. Po dwóch latach, w roku 1993, powstała kolej- Mimo, że wszystkie modele rodziny CMM, cieszyły się dużą popularno-
na wersja 1.1, której kontynuatorką w roku 1997 miała być wersja 2.0, któ- ścią wśród przedsiębiorstw, każdy z nich dotykał jakby innego problemu/
ra powstała jedynie jako wersja robocza  nigdy nie doczekała się swojego dziedziny. Implementacja kilku modeli, była niezwykle kosztowna dla or-
oficjalnego wydania. Prace jednak nad wersją 2.0 nie poszły na marne, zo- ganizacji, która chciała jednocześnie doskonalić swoje procesy wytwór-
stały one wykorzystane przy okazji tworzenia modelu CMMI. cze w kilku dziedzinach. Wiązało się to z dodatkowymi nakładami w po-
Sukces i ogromna popularność modelu SW CMM wśród organizacji staci szkoleń pracowniczych, oceny stopnia implementacji praktyk, któ-
zajmujących się tworzeniem software u, spowodował, iż w 1995 roku gru- 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ł-
Systems Engineering
CNM for Software,
CNM, v1.1 (1995)
by charakter kompleksowy, i który można by było zaimplementować w
INCOSE SECAM
v1.1 (1993)
(1996)
organizacjach o różnych profilach działalności. W efekcie powstał Capa-
bility Maturity Model Integration (CMMI). Zespół SEI, a konkretnie  CMMI
Integrated Product
Product Team , do jego stworzenia wykorzystał trzy modele z
ródłowe
Software CNM,
Development
v2, draft C
(ang. source models):
EIA 731 SECM
(1997)
(1997)
(1998)
" The Capability Maturity Model for Software (SW CMM), v2.0 draft C;
" The System Engineering Capability Maturity Model (SECM);
v1.0, (2000)
" The Integrated Product Development Capability Maturity Model (IPD
v1.1, (2002)
CNM for Services,
CMM for Acquisition, CMM), v0.98.
v1.2, (2007)
CMM for Development,
v1.2, (2007)
v1.2, (2006)
Modele te zostały wykorzystane przede wszystkim ze względu na ich
ogromną popularność i zastosowanie w wielu organizacjach. W efekcie
Rysunek 2. Ewolucja modelu CMMI powstał model, który mógł być wdrożony zarówno w firmach, które po-
Software Developer s Journal 11/2007 www.sdjournal.org
57
Inżynieria
oprogramowania
siadały już jeden ze wspomnianych wcześniej modeli, jak i tych,  któ-
re dopiero zaczynały swoją przygodę z programem doskonalenia proce-
5
sów wytwórczych. CMMI Product Team, przygotował trzy odmiany mode-
OPTYMALIZUJ
CY
lu CMMI:
4
ZARZ
DZAJ
CY
" CMMI SE/SW, v.1.0  wersja łącząca praktyki z dziedziny inżynierii
ILOÅšCIOWO
systemów (ang. System Ingineering) oraz inżynierii oprogramowania
3
(ang. Software Engineering).
" CMMI SE/SW/IPPD, v.1.0  oprócz praktyk wymienionych w punkcie ZDEFINIOWANY
1, wersja ta zawierała rozszerzenie o praktyki z zakresu zintegrowa-
2
nego zarzÄ…dzania produktem i procesem w organizacji (ang. Integra-
ZARZ
DZAJ
CY
ted Product and Process Development).
" CMMI SE/SW/IPPD/SS, v. 1.0  jedyna wersja, która pojawiła się w for-
1
mie roboczej. Oprócz praktyk wskazanych w punktach 1 2, dodatko-
POCZ
TKUJ
CY
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.
Rysunek 4. Reprezentacja stała (ang. staged) modelu CMMI
Po dwóch latach stosowania odmian modelu CMMI w organizacjach, po wowych elementów jest tzw,  szkielet CMMI (ang. CMMI Framework), któ-
uwzględnieniu około 1500 propozycji zmian (ang. change request), set- ry składa się z 3 komponentów:
kach komentarzy, zdecydowano siÄ™ na publikacjÄ™ kolejnej wersji modelu
1.1 w roku 2002. Oprócz wspomnianych trzech, pojawiła się czwarta od- " modelu (ang. model components)  obszary procesowe (ang. process
miana, skupiająca w sobie tylko te praktyki, które dotyczyły poprawy pro- areas), praktyki, materiały informacyjne, stanowiące dla organizacji
cesów tworzenia oprogramowania w organizacjach, zajmujących się two- pomoc w implementacji wymagań modelu CMMI;
rzeniem software u. " szkoleń (ang. training components)  materiały szkoleniowe, prze-
Popularność wersji 1.1 modelu CMMI, przerosła najśmielsze ocze- wodniki wyjaśniające zasady związane z implementacją modelu,
kiwania Software Engineering Institute. Przeszkolono ponad 45 tysięcy oraz wszelkie pomoce audi wizualne, przekazujące wiedzę związa-
ludzi, przeprowadzono około 1500 ocen (ang. appraisal), mających na ną z praktycznym wdrożeniem praktyk modelu CMMI;
celu zmierzenie dojrzałości procesów wytwórczych różnych organiza- " oceny (ang. appraisal components)  zasady opisujące metodę oce-
cji w kontekście praktyk zdefiniowanych w modelu CMMI. Implementacja ny dojrzałości procesów wytwórczych organizacji w kontekście ce-
modelu CMMI okazała się możliwa w wielu różnych organizacjach. Model lów i praktyk opisanych w modelu. Na obszar ten składają się również
CMMI okazał się być na tyle uniwersalny, że jego użycie stało się możliwe wszelkie szkolenia, związane z organizowaniem i przeprowadzaniem
w organizacjach, zajmujÄ…cych siÄ™ nie tylko developmentem software u. ocen (ang. appraisals).
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- Szkielet CMMI dostarcza nam pewnej struktury, którą należy jedynie wy-
zała się możliwa na gruncie wielu organizacji, co zaowocowało powsta- pełnić praktykami, dotyczącymi konkretnych obszarów zainteresowań.
niem wersji 1.2 Capability Maturity Model Integration (Rysunek 2). y
ródło: Nie musimy tworzyć nowej terminologii, programów szkoleń, metod oce-
CMMI Product Team, CMMI for Development, Version 1.2 (CMU/SEI 2006 ny  to wszystko zapewnia nam dostępny szkielet.
TR 008), Pittsburgh, PA: Software Engineering Institute, Carnegie Mellon Kolejnym ważnym pojęciem, związanym z architekturą mode-
University, 2006. lu CMMI jest pojęcie  konstelacji (ang. constellation). Jest to takie po-
łączenie komponentów szkieletu CMMI, które umożliwia doskonalenie
Architektura procesów wytwórczych w określonym obszarze jej zainteresowań (np.
Zmiany, które pojawiły się w ostatniej wersji modelu 1.2, dotyczą przede w sferze usług, czy rozwoju oprogramowania). W chwili obecnej, istnie-
wszystkim jego architektury. W obecnej formie, umożliwia ona dopaso- ją 3 konstelacje, z których  jak dotąd  jedynie pierwsza została opu-
wanie modelu CMMI do potrzeb różnych organizacji. Jednym z jej podsta- 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Ä™
SERVICES
dostarczaniem usług;
DEVELOPMENT
" CMMI for Acquisition (CMMI ACQ)  wspiera organizacje zajmujÄ…ce siÄ™
pozyskiwaniem produktów i usług od zewnętrznych poddostawców.
ACQUISITION
KONSTELACJA
W skład każdej konstelacji, oprócz materiałów szkoleniowych oraz me-
MATERIAA
Y METODA
SZKOLENIOWE OCENY
tod oceny, wchodzi tzw.  podstawa modelu CMMI (ang. CMMI model fo-
undation)  zbiór komponentów, które są wspólne dla wszystkich odmian
Podstawa
Dodatki
modelu CMMI. Tworzą ją określone obszary procesowe, ogólne cele i prak-
Modelu
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-
Rysunek 3. Szkielet modelu CMMI (ang. CMMI Framework) ki, które rozbudowywane są w oparciu o jego podstawę (Rysunek 3). Na
58
www.sdjournal.org
Software Developer s Journal 11/2007
ÓW
DOJRZAA
OŚĆ PROCES
Extreme Programming i CMMI
podstawie: D. M. Ahern, A. Clouse, R. Turner, CMMI Distilled: A Practical In-
troduction to Integrated Process Improvement, Second Edition, Boston:
Addison Wesley, 2003.
5
CMMI for Development (CMMI DEV)
Konstelacja CMMI for Development składa się z dwóch modeli: CMMI for
4
Development + IPPD (ang. Integrated Product and Process Development)
oraz CMMI for Development (bez dodatków IPPD). Ponieważ model CMMI
3
DEV+IPPD, oprócz wspomnianych dodatków, w zasadzie niczym nie róż-
ni się od CMMI DEV, Software Engineering Institute opublikował tylko je-
2
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
1
wersji modelu, zawiera liczne, ciekawe opracowania (pliki  pdf i  doc ) z
zakresu różnych dziedzin inżynierii oprogramowania. Dostęp do wszyst-
etc.
Obszar 1 Obszar 2 Obszar 3
kich materiałów jest oczywiście bezpłatny.
Grupa dodatków IPPD, obecnych w modelu CMMI DEV+IPPD, skupia
PROCES
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
Rysunek 5. Reprezentacja ciągła (ang. continuous) modelu CMMI
których praca podzielona jest pomiędzy zespoły projektowe, skupione w
różnych lokalizacjach (zespoły rozproszone). Zasady zawarte w dodatku ziomów wydolności procesu (ang. capability levels), które obrazują
IPPD, określają reguły właściwej komunikacji w zespołach projektowych, poziom instytucjonalizacji procesu w organizacji. Obszary proceso-
promują umiejętne zarządzanie wiedzą oraz doświadczeniem pracowni- we w reprezentacji ciągłej mogą być doskonalone w ramach sześcio-
ków, a także zawierają wytyczne, dotyczące tworzenia niezbędnej infra- stopniowej skali od 0 do 5. Wydolność procesów wytwórczych może
struktury organizacyjnej w zakresie praktyk IPPD. Dodatki IPPD zosta- być zróżnicowana, co ilustruje (Rysunek 5). To organizacja decyduje
ły przypisane do tych obszarów procesowych modelu CMMI, które w ja- o tym, który proces wymaga poprawy oraz w jakim zakresie. y
ródło:
kiś sposób pozostają zbieżne z obecną w nich tematyką (Tabela 2). Sporo D. M. Ahern, A. Clouse, R. Turner, CMMI Distilled: A Practical Introduc-
ciekawych informacji na temat IPPD, można znalez
ć w publikacji Departa- tion to Integrated Process Improvement, Second Edition, Boston: Ad-
mentu Obrony Stanów Zjednoczonych (United States Department of De- dison Wesley, 2003.
fense): DoD guide to Introduction Product and Process Development (Ver- W reprezentacji ciągłej, obszary procesowe zostały podzielone na 4
sion 1.0), Washington DC, Office of the Under Secretary of Defense (Acqu- kategorie: ZarzÄ…dzanie procesem (ang. Process Management), ZarzÄ…dza-
isition and Technology), 1996  materiał do pobrania na stronie: https:// nie projektem (ang. Project Management), Inżynieria (ang. Engineering)
acc.dau.mil/. oraz Wsparcie (ang. Support). Zestawienie wszystkich obszarów obrazu-
je Tabela 2, podając nazwę procesu wraz z przypisaniem go do określo-
Jeden Model, Dwie reprezentacje nej kategorii oraz poziomu dojrzałości modelu CMMI. Obszary te zostaną
Model CMMI składa się z 22 obszarów procesowych (ang. Proces Areas), szczegółowo omówione oraz zestawione z wybranymi praktykami me-
które organizacja może doskonalić w ramach dwóch reprezentacji: sta- tody Extreme Programming, w kolejnej, ostatniej części prezentowanego
łej (ang. staged) i ciągłej (ang. continuous). Reprezentacja stała, umożli- cyklu, która ukaże się w kolejnym numerze pisma. y
ródło: M. B. Chrissis,
wia doskonalenie procesów wytwórczych, w ramach ściśle zdefiniowanej M. Konrad, S. Shrum, CMMI: Guidelines for Process Integration and Pro-
ścieżki rozwoju. Wyznacza ją pięć poziomów dojrzałości (ang. maturity le- duct Improvement, Addison Wesley, 2007.
vels), co obrazuje(Rysunek 4)
Każdy z poziomów dojrzałości składa się z określonej liczby obsza- Podsumowanie
rów procesowych, które organizacja musi zaimplementować, aby zna- Artykuł jest kolejną częścią cyklu artykułów, poświęconych porówna-
lez
ć się na określonym poziomie dojrzałości CMMI. Warto zauważyć, iż niu dwóch metod tworzenia oprogramowania   lekkich , reprezentowa-
obszary procesowe w tej reprezentacji zostały tak zaprojektowane, iż nych przez podejście określane mianem Extreme Programming oraz  tra-
nie jest możliwe osiągnięcie poziomu 3, nie spełniając wcześniej wyma- dycyjnych , których istotę oddaje model CMMI. Publikacja przedstawia
gań poziomu 2  podobnie, w przypadku poziomu 4, czy 5. W ten spo- charakterystykę tradycyjnych metod tworzenia oprogramowania, które
sób, doskonalenie procesów wytwórczych w reprezentacji stałej ma wykorzystują najczęściej kaskadowy cykl życia projektu software owe-
charakter przyrostowy (inkrementalny). Organizacja posiada nieja- go (wymagania/projekt/implementacja), a ich cechÄ… charakterystycznÄ…
ko gotowy program doskonalenia, obecnych w niej procesów wytwór- jest precyzyjnie zdefiniowany proces, który podlega ciągłemu doskona-
czych. Jest to dobre rozwiązanie dla tych przedsiębiorstw, które nie po- leniu. Metody te, wyrażają wszystko to, co mieści w sobie pojęcie:  dys-
siadają wystarczającej wiedzy na temat stopnia zaawansowania swo- cypliny . Dodatkowo, w artykule omówione zostały podstawowe założe-
ich procesów wytwórczych, a co za tym idzie  trudno jest im jedno- nia modelu CMMI (jego geneza, struktura, reprezentacje), który należy do
znacznie zdecydować, jak powinien wyglądać ich plan doskonalenia. W jednego z bardziej znanych reprezentantów tradycyjnych metod tworze-
takiej sytuacji, zastosowanie reprezentacji stałej może się okazać nie- nia oprogramowania.
zwykle pomocne. W trzeciej, ostatniej części prezentowanego cyklu, która ukaże się
Gdy jednak organizacja, posiada ugruntowaną wiedzę na temat w kolejnym numerze pisma, przedstawiona zostanie próba pogodzenia
swoich procesów wytwórczych, wówczas dobrze jest skorzystać z tych dwóch, pozornie odmiennych, stanowisk:  lekkiego (Extreme Pro-
rozwiązań, które proponuje nam reprezentacja ciągła. Umożliwia ona gramming) oraz  strukturalnego (CMMI). Praktyki metody XP zesta-
skupienie się tylko na tych obszarach procesowych, które wymagają wione zostaną z obszarami procesowymi (ang. Process Areas) mode-
szczególnej poprawy. W reprezentacji ciągłej pojawia się pojęcie po- lu CMMI. n
Software Developer s Journal 11/2007 www.sdjournal.org
59
WYDAJNOŚĆ