PLAN
INF5180
ACT
Produkt og prosessforbedring
i systemutvikling
DEL 7
”Bruk av CMM”
DO
Geir Amsjø
geirams@ifi.uio.no
CHECK
Innhold
Bakgrunn
Struktur og definisjon
Nivå for nivå
CMM Evaluering
CMM brukt i kontinuerlig prosessforbedring
Dokumentasjon
Fremtiden - CMMI
INF5180
2
1
Bakgrunn
DoD bestemte seg i 80-årene å gjøre noe med alle de feilslåtte og
dyre programvareprosjektene sine.
• Ada løste ikke problemene (som mange trodde)
• Evalueringer viste at det var et ledelsesproblem.
Watts Humphrey gikk fra IBM til SEI og begynte utviklingen av CMM
i 1986
Managing the Software Process av W. Humphrey kom i 1989
Versjon 1.1 kom i 1993 – er fremdeles den mest brukte modellen
INF5180
3
Slogan fra SEI
“The Capability Maturity Model for Software (CMM) is a
framework that describes the elements of an effective
software process.
The CMM describes an evolutionary path
from an ad hoc, chaotic process,
to a mature disciplined process”
INF5180
4
2
Programvarebransjen...?
Estimeringsproblemer
• Budsjett overskrides
• Tidsfrister overskrides
Kvalitetsproblemer
• Sliter med feilretting (fremfor
utvikling)
• Sliter med misfornøyde
kunder
Har ingen veldefinert prosess
• Starter ”fra scratch” i hvert
prosjekt
• God praksis ofres under stress
Suksessfaktorer
• Helter
• Overtid
• Brannslukking
INF5180
5
En utfordring!
Software System
Software Engineering Process
Test
Coverage
• Kvalitet kan ikke testes inn i etterkant, men må bygges inn
fra starten av.
• Jo høyere kvalitetskrav, desto større krav til prosessen.
• Prosessen kan ikke gi forutsigbart resultat med mindre det er
kultur for det på individuellt nivå.
"The quality of a system is highly influenced by the quality of the
process used to acquire, develop, and maintain it." (W.Humphrey)
INF5180
6
3
Hvordan gjenta god praksis?
”Kvalitets
modeller”
Metode,
Prosess
Prosjekter
CMM, ISO,
Bootstrap ...
Basert på:
RUP, XP,
DSDM,
MSF....
Modenhets/kvalitets-modeller gir støtte til
• å evaluere behov og forbedring
• organisasjonsendring
• kulturendring
• kunnskapsutvikling
• målinger
Mye god praksis er beskrevet i ferdige
utviklingsmodeller. Men man må velge
riktig og tilpasse til egne behov
Læring og identifisering av god praksis
foregår i prosjektene. Oppdater prosessmodellen
etter hvert prosjekt!
INF5180
7
CMM scope
SW - CMM
INF5180
8
4
Prosjekt og modenhet
”Umodne” organisasjoner
”Modne” organisasjoner
Prosjektleder opplever:
Må starte fra scratch
Vanskelig å få oversikt
Overraskelser
Konstant endringshåndtering
Overtid!
Ta igjen det tapte – fra dag 1
Dårlig nattesøvn...
Prosjektleder opplever:
Kommer til dekket bord
Endringer er normalt
Overtid, men kun i perioder
Estimatene holder
Yrkesstolthet! Sover godt!
Kunden opplever:
Upålitelige løfter
Dårlig kvalitet
Forventningene ikke innfridd
Kunden opplever:
Estimatene holder
God kvalitet
Forventningene blir innfridd
INF5180
9
Linjeledelse og modenhet (2)
”Umodne” organisasjoner
”Modne” organisasjoner
Linjeledelsen opplever:
Løfter vanskelig å innfri
Prosjektene kommer ikke i gang
Ressursene ikke tilgjengelige
Nøkkelpersoner brukes i økende
grad til vedlikehold og feilretting
Får ikke tatt ut effekten av
prosjektene
Strategisk planlegging nesten
umulig
Linjeledelsen opplever:
Lett å planlegge
Løfter innfris
God ressursallokering blir
mulig
Strategier blir gjennomført
Tjener penger!
INF5180
10
5
Det er menneskelig å feile
Overvurderer egne ferdigheter
• ”Alle” menn er over gjennomsnittelig gode sjåfører...
• Undersøkelse på Simula viser lignende tendens for utviklere
Vi estimerer ”internt”
• Glemmer å se på prosjektet fra utsiden.
⌫Hvilke erfaringer finnes ved lignende prosjekter?
⌫Er det i det hele tatt gjort lignende før?
Vi ”glemmer” å håndtere risiko
Sannsynlighet
• Lite lystbetont aktivitet
• ”Ikke vær så negativ da”
Referanse:
Magne Jørgensen et.al.(2003) ”Better sure than safe?
Overconfidence in judgment based software
development effort prediction intervals”
Mål
INF5180
Tidsforbruk
11
Key Process Areas (KPAs)
Level
Key Process Areas
Optimizing (5) Defect prevention
Technology change management
Process change management
Characteristics
Continous process
improvement
Managed (4)
Quantitative process management
Software quality management
Product and process
quality
Defined (3)
Organisational process focus
Organisational process definition
Integrated software management
Software product engineering
Intergroup coordination
Training program
Peer reviews
Defined engineering
process
Repeatable (2) Requirements management
Project management
and commitment
process
Initial (1)
Heroes
Software
Software
Software
Software
Software
project planning
project tracking
subcontract management
quality assurance
configuration management
INF5180
12
6
In
Out
Level 4
In
Out
Probability
Level 3
In
Out
Probability
Level 2
In
Out
Level 1
Out
In
Probability
Level 5
Probability
Probability
Hva skjer i prosjektene?
INF5180
target
target
target
target
target
13
CMM Hovedstruktur
Practices
Maturity Levels
Key Process Area
Goals
Practices
Goals
Practices
Key Process Area
Goals
Practices
Practices
INF5180
14
7
Evaluering mot CMM
For å tilfredsstille en KPA gjelder det å vise at man gjør det man sier (implementasjon)
I tillegg man må i tillegg vise at det er sannsynlig at dette er varig (institusjonalisering)
Goal
Commitment
Ability
Institusjonalisering
Activities
Measurement
Verification
Implementasjon
INF5180
15
CMM nivå 2
5. Optimizing
4. Managed
3. Defined
2. Repeatable
1. Initial
Requirements management
Software project planning
Software project tracking and oversight
Software subcontract management
Software quality assurance
Software configuration management
INF5180
16
8
En repeterbar prosess...
Grunnleggende prosjektstyring etablert
Prosjekter planlegges og følges opp
Endringer i planene håndteres under kontroll
Man klarer å identifiserer god praksis
Gjensidige avtaler inngås
Suksessprosjekter kan gjentas under stabile forhold
INF5180
17
Hvordan klatre til nivå 2
Fokuser på prosjektene – ett og ett
Sats på opplæring av prosjektledere
Implementer noen ytterst få og enkle målinger
Bruk Kvalitetssikringsfunksjonen til institusjonalisering
Sett i verk kontrollpunkter ved hovedmilepæler
Inngå forpliktende, gjensidige avtaler!
INF5180
18
9
Requirement Management
Goals:
1. System requirements allocated to software are controlled to
establish a baseline for software engineering and
management use.
2. Software plans, products, and activities are kept consistent
with the system requirements allocated to software.
customer
software
project
INF5180
19
Requirement Management - Practices
1
2
3
4
5
6
7
8
9
10
11
12
The project follows a written organizational policy for managing the system
requirements allocated to software.
For each project, responsibility is established for analyzing the system requirements and
allocating them to hardware, software, and other system components.
The allocated requirements are documented.
Adequate resources and funding are provided for managing the allocated requirements.
Members of the software engineering group and other software related groups are
trained to perform their requirements management activities.
The software engineering group reviews the allocated requirements before they are
incorporated into the software project.
The software engineering group uses the allocated requirements as the basis for
software plans, work products, and activities.
Changes to allocated requirements are reviewed and incorporated into the software
project.
Measurements are made and used to determine the status of the activities for managing
the allocated requirements.
The activities for managing the allocated requirements are reviewed with senior
management on a periodic basis.
The activities for managing the allocated requirements are reviewed with the project
manager on both a periodic and event-driven basis.
The software quality assurance group reviews and/or audits the activities and work
products for managing the allocated requirements and reports the results.
INF5180
CO1
AB1
AB2
AB3
AB4
AC1
AC2
AC3
ME1
VE1
VE2
VE3
20
10
Software Project Planning
Goals:
1. Software estimates are documented for use in planning and
tracking the software project.
2. Software project activities and commitments are planned and
documented.
3. Affected groups and individuals agree to their commitments
related to the software project.
INF5180
21
Software Project Tracking and Oversight
Goals:
1. Actual results and performance are tracked against the software
plans.
2. Corrective actions is taken and managed to closure when actual
results and performance deviate significantly from the software
plans.
3. Changes to software commitments are agreed to by the affected
groups and individuals.
INF5180
22
11
Software Subcontract Management
Goals:
1. The prime contractor selects qualified software subcontractors.
2. The prime contractor and the software subcontractor agree to their
commitments to each other.
3. The prime contractor and the software subcontractor maintain
ongoing communications.
4. The prime contractor tracks the software subcontractor’s actual
results and performance against its commitments.
INF5180
23
Software Configuration Management
Goals:
1. Software Configuration Management activities are planned.
2. Selected software work products are identified, controlled and
available.
3. Changes to identified software work products are controlled.
4. Affected groups and individuals are informed of the status and
content of software baselines.
INF5180
24
12
Software Quality Assurance
Goals:
1. Software quality assurance activities are planned.
2. Adherence of software products and activities to the applicable
standards, procedures and requirements is verified objectively.
3. Affected groups and individuals are informed of software quality
assurance activities and results.
4. Noncompliance issues that cannot be resolved within the software
project are addressed by senior management.
INF5180
25
Nivå 3
Optimizing
Managed
Defined
Organization process focus
Organization process definition
Integrated software management
Software product engineering
Intergroup coordination
Training program
Peer review
Repeatable
Initial
INF5180
26
13
Hva er defined ?
Standard utviklingsprosess er
• veldefinert på organisasjonsnivå
• i bruk i vid forstand
• danner basis for all læring og lagring av erfaringer (best practice)
Organisasjonen viser tydelig at prosessen skal brukes
•
•
•
•
•
•
oppretter prosessgrupper (”SEPG”)
sørger for erfaringsmekanismer (”de-briefing”, PMA, etc)
knytter erfaringsdata til prosessen
tilbyr opplæring i prosessen
og knytter teknisk opplæring til prosessen
definerer tydelige grensesnitt mellom grupper
INF5180
27
Ansvar på nivå 3
Organisasjonen
•
•
•
•
Hovedansvar for endringer
Etablering av standard prosessrammeverk
Koordinering av forbedringsarbeid
Koordinering av opplæring
Prosjektene
• Gjør tilpasninger av standard prosess mot prosjektets behov
(prosessinstans)
• Koordinerer avhengigheter og grensesnitt med andre involverte
grupper
Individene
• Benytter prosessen i det daglige arbeid
• Følger opp opplæring ved behov
INF5180
28
14
Organisation Process Focus
Goals:
1. Software process development and improvement activities are
coordinated across the organization.
2. The strengths and weaknesses of the software processes used are
identified relative to a process standard.
3. Organization-level process development and improvement activities
are planned.
INF5180
29
Organisation Process Definition
Goals:
1. A standard software process for the organization is developed and
maintained.
2. Information related to the use of the organization’s standard
software process by the software projects is collected, reviewed
and made available.
INF5180
30
15
Integrated Software Management
Goals:
1. The project’s defined software process is a tailored version of the
organization’s standard software process.
2. The project is planned and managed according to the project’s
defined software process.
INF5180
31
Software Product Engineering
Goals:
1. The software engineering tasks are defined, integrated, and
consistently performed to produce the software.
2. Software work products are kept consistent with each other.
INF5180
32
16
Intergroup Coordination
Goals:
1. The customer’s requirements are agreed to by all affected groups.
2. The commitments between the engineering groups are agreed to
by the affected groups.
3. The engineering groups identify, track and resolve intergroup
issues.
INF5180
33
Training Program
Goals:
1. Training activities are planned.
2. Training for developing the skills and knowledge needed to perform
software management and technical roles is provided.
3. Individuals in the software engineering group and software-related
groups receive the training necessary to perform their roles.
INF5180
34
17
Peer Review
Goals:
1. Peer review activities are planned.
2. Defects in the software work products are identified and removed.
INF5180
35
Nivå 4
Optimizing
Managed
Defined
Repeatable
Quantitative Process Management
Software Quality Assurance
Initial
INF5180
36
18
Hva er managed ?
Prosessen overvåkes gjennom målinger. Mange bruker statistisk
prosesskontroll (SPC) for å identifisere avvik som må sees nærmere
på.
Målsetninger er gjerne kvantitative og følges opp gjennom
målinger.
Special cause of process
variation (e.g. defect
prone module)
Control Chart
Upper performance boundary
Average process performance
Process performance
Lower performance boundary
INF5180
37
Quantitative Process Management
Goals:
1. The quantitative process management activities are planned.
2. The process performance of the project’s defined software process
is controlled quantitatively
3. The process capability of the organizations standard software
process is known in quantitative terms.
INF5180
38
19
Software Quality Management
Goals:
1. The project’s software quality management activities are planned.
2. Measureable goals for software product quality and their priorities
are defined.
3. Actual progress toward achieving the quality goals for the software
products is quantified and managed.
INF5180
39
Nivå 5
Optimizing
Managed
Defined
Repeatable
Defect prevention
Technology change management
Process change management
Initial
INF5180
40
20
Hva er optimized ?
Ytelsen i organisasjonen er kontinuerlig overvåket og forbedret.
Alternative prosesstrinn utvikles for ulike formål.
• Avveiing mellom tid, kost og kvalitet
• Kunden vil kunne velge prosessmodell i henhold til sine behov.
Ny teknologi og metodikk prøves ut i ufarlige omgivelser for å
undersøke om de kan bidra til ytterligere forbedring.
INF5180
41
Defect Prevention
Goals:
1. Defect prevention activities are planned.
2. Common causes of defects are sought out and identified.
3. Common causes of defects are prioritized and systematically
eliminated.
INF5180
42
21
Technology Change Management
Goals:
1. Incorporation of technology changes is planned.
2. New technologies are evaluated to determine their effect on quality
and productivity.
3. Appropriate new technologies are transferred into normal practice
across organization.
INF5180
43
Process Change Management
Goals:
1. Continuous process improvement is planned.
2. Participation in the organizations software process improvement
activities is organization-wide.
3. The organisations standard process and the project’s defined
software processes are improved continuously.
INF5180
44
22
Organisasjonsendringer
St
ab
ili
ty
Organization
Project
L1
Individual
L2 Management
establishes
process
discipline
L4
t
us
Tr
L3Organization
establishes
process
framework
Project
reduces
process
variation
L5 Individual
improves
personal
process
Ad hoc,
Inconsistent
undisciplined
process
INF5180
45
Kulturendringer
Level 5
Level 4
Level 3
Level 2
Level 1
Culture of empowerment and innovation
Culture of performance excellence
Culture of engineering
Culture of commitment
Imported culture
INF5180
46
23
Bruksområder
• CMM er en Evalueringsmodell for å fastslå modenheten til
programvareorganisasjoner
• CMM er et rammeverk for kontinuerlig forbedring av
utviklingsprosesser
• Modellen er designet slik at disse skal kunne brukes samtidig slik at
man gradvis kan jobbe mot øket modenhet og vise dette utad gjennom
formelle evalueringer (assessments)
Level 5:
Continuous
Optimizing
process
improvement
Level 4:
Managed
Process
control
Process
definition
Process
discipline
Level 3:
Defined
Level 2:
Repeatable
Level 1:
Initial
Change
management
Quantitative
management
Engineering
management
Project
management
INF5180
47
CMM Evaluering
En lang rekke modeller, skjemaer og formalismenivåer
Offisiell CBA IPI eller SCE
Light assessments
Ultra-light assessments
Kombinert opplæring og assessment (Q-Labs’ ”Focused Training”)
Basert på åpne intervjuer
Basert på lukkede/strukturerte intervjuer
Basert på spørreskjemaer
INF5180
48
24
CBA IPI – den offisielle SEI-modellen
Må involvere en SEI-godkjent
Lead Assessor
Krever detaljert gjennomgang av
de aktuelle KPA’ene
Koster > 200.000 NKR
For å bli godkjent Lead assessor
må man dokumentere:
• Pedagogisk erfaring og evner
• 10 års erfaring innen Software
Engineering og eller
prosjektledelse. Minst 2 av disse
årene i lederrolle
• Akademisk bakgrunn må være
”Avansert” (Siv.ing, Cand Scient
++) innen Software Engineering
• Må ha deltatt på minst 2 offisielle
CMM assessments de siste 24
månedene
INF5180
49
En enkel assessment-prosess *
1.
Awareness
Present CMM overview and discuss the CMM potential with
management team. Get commitment!
Define scope of assessment.
Define additional scope (outside CMM) if needed.
Define assessment team and ensure that the team gets full CMM
training.
Give one-day course on the CMM model to everybody
2.
3.
4.
Review and interviews
1.
2.
3.
4.
1.
Reporting
2.
3.
Document review
Decide on interview technique:
Questionnaire send-out
Individual
Group
Perform Inteviews
Summarise results
Make Findings report based on inteviews:
General, overall findings
KPA specific findings
Quick-win candidates
Discuss findings in assessment team
Present findings to everybody:
Discuss findings
Resolve conflicts
*) Brukes bl.a. i Q-Labs
Improvement planning
INF5180
50
25
Prosessforbedring: IDEAL
SEI sin prosessforbedringsprosess:
INF5180
51
CMM og QIP
CMM er godt egnet til å brukes sammen med Quality Improvement
Paradigme på organisasjonsnivå
1. Gjennomfør en CMM-assessment.
2.
3.
4.
5.
6.
Kombiner resultatene med
forretningsmessige målsetninger og
identifiserte problemer.
Bruk ”Findings” fra assessmenten til
å sette forbedringsmål
Velg tiltak som antas å føre fram mot
målsetningene
Gjennomfør ett eller flere prosjekter med
de nye modellene, verktøyene og
metodene. Samle data underveis
Analyser erfaringene fra prosjektene
Oppdater standard prosessmodell og
erfaringsdatabase
INF5180
52
26
CMM som veikart
Det er ikke vanskelig å komme frem til en lang liste med gode
forslag til forbedringer. (Hvem har vel ikke vært med på ”GAPanalyse” og brainstorming rundt sterke og svake sider.)
Langt vanskeligere er det å prioritere det viktigste og å lage en
realistisk fremdriftsplan.
Det aller vanskeligste er å håndtrere de nødvendige endringene i
organisasjonen - arbeidsmåte og ikke minst kultur.
Hit vil jeg
Dette er veien dit
Her er jeg
INF5180
53
Ulike anvendelser av CMM
De aller fleste som bruker CMM i dag bruker den internt som et
forbedringsrammeverk – dvs at de ikke har til hensikt å utnytte
markedsverdien gjennom en CBA IPI eller SCAMPI.
De mest aktive CMM-profilene (Mark Paulk og Bill Curtis) advarer i
dag sterkt mot å følge modellen blindt. Bruk modellen med sunn
fornuft, paret med forståelse av egne behov og problemområder.
Modelløs SPI
(f.eks. GQM)
CMM brukt veiledende
(kombinert med GQM/QIP el.l.)
INF5180
”Hard-core CMM”
(CBA IPI)
54
27
Bruk sunn fornuft...
Mark Paulk, SEI:
Common Sense
Process Discipline
Mindless
Bureaucracy
INF5180
55
Virker det ? (I)
INF5180
56
28
Over/Under Percentage
Virker det ? (II)
140%
Results: Boeing Effort Estimation
.
.
.. ..... ............... .....
.. .. .. ..
. . . .. ... . . . ... .. .. .............
.
.
..
. . . .. .. .. ..... .
.
. . .... .. .....
... . .
. .... .. ... .... ..... .. ..
. . .... . .. ... ..
.. . . . .. . .... .
. . .. ... ... .. . . . .
.. .. .
-140%
Without Historical. Data
With Historical Data
Variance between + 20% to - 145% Variance between - 20% to + 20%
0%
(Mostly Level 1 & 2)
(Level 3)
(Based on 120 projects in Boeing Information Systems)
Reference: John D. Vu. “Software Process Improvement Journey:From Level 1 to Level 5.”
7th SEPG Conference, San Jose, March 1997.
INF5180
57
Status og utbredelse
Offisielle SEI-assessments utført fra 1998 til August 2002:
•
•
•
•
1124 organisasjonsenheter
388 selskaper
5538 prosjekter
42,3 % utenfor USA
Se http://www.sei.cmu.edu/sema/profile.html (oppdateres halvårlig)
INF5180
58
29
Modenhetsprofil
INF5180
59
Andre Rammeverk i ”familien”
INF5180
60
30
CMMI er ”redningen” (?)
CMMI Design spesifikasjon:
Integrere ulike modeller, eliminere inkonsistens, redusere
duplisering
Redusere kostnadene ved å implementere modell-basert
prosessforbedring
Være klargjørende og øke forståelsen ved
• felles terminologi
• konsistent stil
• uniforme strukturregler
• ha en del felles komponenter
Sikre konsistens med ISO 15504 (SPICE)
Ikke overraskende: CMMI har blitt et langt mer
omfattende og komplisert regime enn SW-CMM
INF5180
61
Overgangen fra SW-CMM til CMMI
Assessment metodene CBA IPI og SCE erstattes av SCAMPI
”To assist Capability Maturity Model® for Software (SW-CMM®) users
upgrading to the CMMI® Product Suite, the SEI has announced it will
support the use of the Standard CMMI Appraisal Method for Process
Improvement (SCAMPISM) for appraising organizations using the SWCMM starting December 1, 2003.
Support for performing SCAMPI appraisals with the SW-CMM will
expire with the sunsetting of the SW-CMM on December 31, 2005. ”
INF5180
62
31
Satse på CMMI?
SEI viser tydelig at de er ”fully committed” til
CMMI blant annet ved å åpent planlegge
utfasing av SW-CMM.
Markedet er imidlertid avventende, især de som
kun utvikler programvare. Mange roper etter
SW-CMM v2.0 (som finnes i Draft versjon, men
som ble stoppet og i stedet integrert i CMMI)
INF5180
63
Referanser
Artikler om CMM fra SEI:
http://www.sei.cmu.edu/cmm/cmm.articles.html
Offisiell CMMI hjemmeside:
http://www.sei.cmu.edu/cmmi/cmmi.html
Sun-setting of SW-CMM:
http://www.sei.cmu.edu/cmmi/adoption/sunset.html
INF5180
64
32