MSF for CMMI Process

Improvement v5.0
Process Guidance
Microsoft
6/17/2010

Page 0 of 68
Table of Contents
Table of Contents........................................................................................................ 1
1. Introduction..........................................................................................................
!. "ac#ground to CMMI............................................................................................
!.1. $%& 'se a Model(.......................................................................................... 5
!.!. $%at is t%e Purpose of t%e CMMI Model(.......................................................5
!.). *o+ "est S%ould t%e CMMI Model "e 'sed(..................................................,
!.. -lements of t%e CMMI Model.......................................................................... .
!.5. /dditional 0esources.................................................................................... 10
). Pro1ect Management.......................................................................................... 10
).1. Introduction................................................................................................. 10
).1.1. Iterative 2evelopment........................................................................... 11
).1.!. 3arger and smaller c&cles......................................................................1!
).!. Pro1ect /ctivities.......................................................................................... 1)
).!.1. 4vervie+............................................................................................... 1)
).!.!. Pro1ect Inception.................................................................................... 1,
).!.). Planning t%e Pro1ect 5CMMI6...................................................................!0
).!.. Managing C%ange 5CMMI6......................................................................!5
).!.5. Managing 0is#s...................................................................................... !.
).). Iteration /ctivities........................................................................................ )1
).).1. 4vervie+............................................................................................... )1
).).!. Planning an Iteration 5CMMI6.................................................................)5
).).). Managing Issues 5CMMI6........................................................................)7
. -ngineering........................................................................................................ !
.1. 2eveloping 0e8uirements............................................................................ !
.1.1. $%en to 2evelop 0e8uirements............................................................)
Page 1 of 68
.1.!. $rite a 9ision Statement.......................................................................
.1.). $rite Scenarios......................................................................................
.1.. Model t%e business domain...................................................................7
.1.5. 2evelop :ualit& of Service 0e8uirements..............................................50
.1.,. 0evie+ 0e8uirements............................................................................50
.1.7. 9alidation............................................................................................... 51
.1... Inspecting and -diting t%e 0e8uirements..............................................51
.1.;. /dditional 0esources............................................................................. 5!
.!. /rranging 0e8uirements into a Product Plan................................................5!
.!.1. 0e8uirements and Features...................................................................5!
.!.!. Scenario 2ecomposition........................................................................5
.!.). /ssign 3eaf Scenarios to Iterations........................................................5,
.!.. Features < 0e8uirements Ful=lled in eac% Iteration................................57
.!.5. -ntering and inspecting features...........................................................5.
.!.,. To enter and edit features......................................................................5;
.!.7. :ualit& of Service Features....................................................................5;
.!... Product planning.................................................................................... 5;
.!.;. Iteration planning.................................................................................. ,0
.). Creating a Solution /rc%itecture..................................................................,1
.).1. Create /lternative /rc%itecture Partitioning 2esigns.............................,1
.).!. 2esign S&stem /rc%itecture and 2eplo&ment.......................................,!
.).). Create Proofs of Concept.......................................................................,)
.).. /ssess /lternatives................................................................................ ,
.).5. Select t%e /rc%itecture..........................................................................,5
.).,. 2evelop a Performance Model...............................................................,,
.).7. 2evelop a T%reat Model.........................................................................,7
Page 2 of 68
.. "uilding a Product........................................................................................ ,7
.5. 9erif&ing 0e8uirements................................................................................ ,7
.,. $or#ing $it% "ugs....................................................................................... ,7
5. /rtifacts.............................................................................................................. ,7
Page 3 of 68
1. Introduction
You can use MSF for CMMI v5.0 to help your team exercise software development processes
that meet CMMI requirements.
For more information aout CMMI! see "ac#$round to CMMI.
MSF for CMMI v5.0 provides the followin$ help and tools%
& process template for 'eam Foundation that defines wor# items! reports! and other
tools. For information aout the artifacts in this template! see &rtifacts (CMMI).
'he process $uidance in the topics in this section.
MSF for CMMI v5.0 is availale online. You can download this content y updatin$ your
offline help files y usin$ the *elp +irary Mana$er. For more information! see *elp
+irary Mana$er (Microsoft *elp System).
'he situations and wor#in$ practices of development teams vary widely! and most companies
will have their own well,estalished processes. For these reasons! the $uidance $iven here does
not attempt to prescrie a development process in full. Instead! we descrie -ust the activities that
are relevant to ma#in$ est use of the MSF for CMMI process template.
You should adapt this $uidance to your own situation! which will depend on the type and history
of the product that you are developin$! the pro-ect.s scale! the ac#$round of the team memers!
and accepted practice in your or$ani/ation.
0sin$ the CMMI template and $uidance can help you achieve the aims of CMMI if you use it as
part of a process improvement pro$ram. You can find many resources for such a pro$ram on the
1e.
'his $uidance was developed in partnership with 2avid &nderson. For more information! see the
followin$ 1e pa$e% 2avid 3 &nderson 4 &ssociates.
2. Background to CMMI
'he definitive $uide to the Capaility Maturity Model Inte$ration (CMMI) for 2evelopment is
pulished y the Software 5n$ineerin$ Institute as 6CMMI% 7uidelines for 8rocess Inte$ration
and 8roduct Improvement.9 'his oo# specifically descries the CMMI for 2evelopment
(CMMI,25:) version ;.<! which is one of the models within the current CMMI product suite at
the time of this writin$. 'his model is extremely stale and should continue to e current well
eyond <0;0. You may also find 6CMMI 2istilled% & 8ractical Introduction to Inte$rated 8rocess
Improvement6 to e a useful and accessile oo# aout the topic. For more information aout
oth of these oo#s! see &dditional =esources later in this topic.
Page of 68
'he CMMI started life in ;>?@ as the Capaility Maturity Model (CMM)! a pro-ect at the
Software 5n$ineerin$ Institute! which is a research center at Carne$ie,Mellon 0niversity. 'his
center was estalished and funded y the 0nited States 2epartment of 2efense. 'he CMM for
Software was first pulished in ;>>; and is ased on a chec#list of critical success factors in
software development pro-ects durin$ the late @0s and early ?0s. 'he model is also informed y
research at International "usiness Machines (I"M) Corporation and <0th,century quality
assurance leaders 8hilip Crosy and 1. 5dwards 2emin$. "oth the name! Capaility Maturity
Model! and the five levels in the Sta$ed =epresentation (as discussed later in this topic) were
inspired y CrosyAs Manufacturin$ Maturity Model. &pplied mainly to defense pro$rams!
CMM has achieved considerale adoption and under$one several revisions and iterations. Its
success led to the development of CMMs for a variety of su-ects eyond software. 'he
proliferation of new models was confusin$! so the $overnment funded a two,year pro-ect that
involved more than <00 industry and academic experts to create a sin$le! extensile framewor#
that inte$rated systems en$ineerin$! software en$ineerin$! and product development. 'he result
was CMMI.
'he most important thin$ to understand aout the CMMI,25: is that it is a model. It is not a
process or a prescription to e followed. It is a set of or$ani/ational ehaviors that have proven
to e of merit in software development and systems en$ineerin$. 1hy use such a modelB 1hat is
its purposeB &nd how est should it e usedB 'hese are critical questions and are perhaps the
most misunderstood issues with CMMI.
2.1. Why Use a Model?
1ithout a model of how our or$ani/ations wor#! which functions they need! and how those
functions interact! it is difficult to lead efforts to improve. & model $ives us an understandin$ of
discrete elements in our or$ani/ations and helps us formulate lan$ua$e and discussion of what
needs to e improved and how such improvement mi$ht e achieved. & model offers the
followin$ enefits%
provides a common framewor# and lan$ua$e to help communicate
levera$es years of experience
helps users #eep the i$ picture in mind while focusin$ specifically on improvement
is often supported y trainers and consultants
can provide a standard to help solve disa$reements
2.2. What is the Purpose of the CMMI Model?
'he textoo# will tell you that the purpose of the model is to assess the maturity of an
or$ani/ationAs processes and to provide $uidance on improvin$ processes that will lead to
improved products. 1hen tal#in$ directly with people from the Software 5n$ineerin$ Institute!
Page ! of 68
you mi$ht hear them say that the CMMI is a model for ris# mana$ement and indicates an
or$ani/ationAs aility to mana$e ris#. 'his indication is evidence for the li#elihood that the
or$ani/ation can deliver on its promises or deliver products of hi$h quality that are attractive to
the mar#et. &nother way to thin# of this is that the model provides a $ood indicator of how an
or$ani/ation will perform under stress. & hi$h maturity! hi$h capaility or$ani/ation will ta#e
unexpected! stressful events in its stride! react! chan$e! and proceed forward. & low maturity and
lower capaility or$ani/ation will tend to panic under stress! lindly follow oviated procedures!
or throw out all process alto$ether and retrench ac# to chaos.
'he CMMI has not proven a $ood indicator of the economic performance of an or$ani/ation.
&lthou$h hi$her maturity or$ani/ations may mana$e ris# etter and e more predictale! there is
evidence of ris# aversion amon$ hi$her maturity firms. 'his aversion can lead to a lac# of
innovation or evidence of $reater ureaucracy that results in lon$ lead times and a lac# of
competitiveness. +ower maturity firms tend to e more innovative and creative ut chaotic and
unpredictale. 1hen results are achieved! they are often the result of heroic effort y individuals
or mana$ers.
2.3. How Best Should the CMMI Model Be Used?
'he model was desi$ned to e used as the asis for a process improvement initiative! with its use
in assessment only a support system for measurin$ improvement. 'here has een mixed success
with this usa$e. It is all too easy to mista#e the model for a process definition and try to follow it!
instead of a map that identifies $aps in existin$ processes that may need to e filled. 'he
fundamental uildin$ loc# of CMMI is a process area that defines $oals and several activities
that are often used to meet them. Cne example of a process area is 8rocess and 8roduct Duality
&ssurance. &nother is Confi$uration Mana$ement. It is important to understand that a process
area is not a process. & sin$le process may cross multiple process areas! and an individual
process area may involve multiple processes.
'he CMMI,25: is really two models that share the same underlyin$ elements. 'he first and
most familiar is the Sta$ed =epresentation! which presents the << process areas mapped into one
of five or$ani/ational maturity levels. &n appraisal of an or$ani/ation would assess the level at
which it was operatin$! and this level would e an indicator of its aility to mana$e ris# and!
therefore! deliver on its promises.
Page 6 of 68
+evels E and 5 are often referred to as hi$her maturity levels. 'here is often a clear difference
etween hi$her maturity or$ani/ations! which exhiit the quantitative mana$ement and
optimi/in$ ehaviors! and lower maturity or$ani/ations! which are merely mana$ed or followin$
defined processes. *i$her maturity or$ani/ations exhiit lower variaility in processes and often
use leadin$ indicators as part of a statistically defensile mana$ement method. &s a result! hi$her
maturity or$ani/ations tend to e oth more predictale and faster at respondin$ to new
information! assumin$ that other ureaucracy does not $et in the way. 1here low maturity
or$ani/ations tend to exhiit heroic effort! hi$h maturity or$ani/ations may lindly follow
processes when under stress and fail to reco$ni/e that a process chan$e may e a more
appropriate response.
'he second! the Continuous =epresentation! models process capaility within each of the <<
process areas individually! allowin$ the or$ani/ation to tailor their improvement efforts to the
processes that offer the hi$hest usiness value. 'his representation is more in line with CrosyAs
ori$inal model. &ppraisals a$ainst this model result in profiles of capaility rather than a sin$le
numer. Cf course! ecause the or$ani/ational maturity level is the level that most mana$ers and
executives understand! there are ways of mappin$ the results of a continuous model assessment
into the five sta$es.
0sin$ the sta$ed model as a asis for a process improvement pro$ram can e dan$erous ecause
implementers may for$et that the CMMI is not a process or wor#flow model ut provides $oals
for process and wor#flow to achieve. Meetin$ those $oals will improve the maturity of the
Page 7 of 68
or$ani/ation and the li#elihood that events unfold as planned. 8erhaps the i$$est failure mode is
ma#in$ achievin$ a level the $oal and then creatin$ processes and infrastructure simply to pass
the appraisal. 'he $oal of any process improvement activity should e measurale improvement!
not a numer.
'he Continuous model seems to have some $reater success as a $uide to process improvement!
and some consultin$ firms choose only to offer $uidance around the Continuous model. 'he
most ovious difference is that a process improvement pro$ram that is desi$ned around the
Continuous model does not have artificial $oals that are determined y maturity levels. 'he
Continuous model also more naturally lends itself to applyin$ process improvement in the areas
where it is most li#ely to levera$e an economic enefit for the or$ani/ation. 'herefore! those
who follow the Continuous model are more li#ely to receive positive feedac# from an initiative
that is ased on the CMMI model. Moreover! positive feedac# is more li#ely to lead to the
development of a virtuous cycle of improvements.
2.4. le!e"ts of the CMMI Model
'he CMMI model is divided into << process areas! which are listed in the followin$ tale%
Acronym Process Area
C&= Causal &nalysis 4 =esolution
CM Confi$uration Mana$ement
2&= 2ecision &nalysis 4 =esolution
I8M Inte$rated 8ro-ect Mana$ement
M& Measurement 4 &nalysis
CI2 Cr$ani/ational Innovation 4 2eployment
C82 Cr$ani/ational 8rocess 2efinition
C8F Cr$ani/ational 8rocess Focus
C88 Cr$ani/ational 8rocess 8erformance
C' Cr$ani/ational 'rainin$
8I 8roduct Inte$ration
8MC 8ro-ect Monitorin$ 4 Control
88 8ro-ect 8lannin$
88D& 8rocess 4 8roduct Duality &ssurance
D8M Duantitative 8ro-ect Mana$ement
=2 =equirements 2efinition
=5DM =equirements Mana$ement
=SFM =is# Mana$ement
S&M Supplier &$reement Mana$ement
'S 'echnical Solution
:5= :erification
:&+ :alidation
Page 8 of 68
In the Sta$ed =epresentation! the process areas are mapped a$ainst each sta$e! as shown in the
followin$ illustration.
In the Continuous =epresentation! the process areas are mapped into functional $roupin$s! as
shown in the followin$ illustration.
5ach process area is made up of required! expected! and informative components. Cnly the
required components are actually required to satisfy an appraisal a$ainst the model. 'he required
components are the specific and $eneric $oals for each process area. 'he expected components
are the specific and $eneric practices for each specific or $eneric $oal. Gote that! ecause an
expected component is merely expected and not required! this indicates that a specific or $eneric
practice can e replaced y an equivalent practice. 'he expected practices are there to $uide
implementers and appraisers. If an alternative practice is chosen! it will e up to the implementer
to advise an appraiser and -ustify why an alternative practice is appropriate. Informative
components provide details that help implementers $et started with a process improvement
initiative that is $uided y the CMMI model. Informative components include su,practices of
$eneric and specific practices and typical wor# products.
Page " of 68
It is very important that we understand that only $eneric and specific $oals are required.
5verythin$ else is provided as a $uide. 'he examples of the expected and informative
components that are $iven in the CMMI literature are very often pulled from lar$e space and
defense,systems inte$ration pro-ects. 'hese pro-ects are run y companies that sponsor and
support the Software 5n$ineerin$ Institute at Carne$ie,Mellon 0niversity. 'hese pro-ects may
not reflect the type of pro-ects that are underta#en in your or$ani/ation! nor may they reflect
more recent trends in the industry! such as the emer$ence of a$ile software development
methods.
2.#. $dditio"al %esour&es
For more information! see the followin$ 1e resources%
CMMI% 7uidelines for 8rocess Inte$ration and 8roduct Improvement (<nd 5dition)! Mary
"eth Chrissis! Mi#e Fonrad! and Sandy ShrumH &ddison,1esley 8rofessional! <00I.
CMMI 2istilled% & 8ractical Introduction to Inte$rated 8rocess Improvement (Jrd
5dition)! 2ennis M. &hren! &aron Clause! and =ichard 'urnerH &ddison,1esley
8rofessional! <00?.
3. #ro$ect Manage%ent
3.1. I"trodu&tio"
You can use the 8ro-ect Mana$ement section of the MSF for CMMI process improvement
$uidance to etter understand how to mana$e! plan! and coordinate development and
maintenance of software products. For more information aout CMMI! see "ac#$round to
CMMI.
'he 8ro-ect Mana$ement $roupin$ of process areas in the CMMI includes 8ro-ect 8lannin$!
8ro-ect Monitorin$ and Control! Supplier &$reement Mana$ement! Inte$rated 8ro-ect
Mana$ement! =is# Mana$ement! and Duantitative 8ro-ect Mana$ement. &ll ut Duantitative
8ro-ect Mana$ement are part of model levels < or J. Duantitative 8ro-ect Mana$ement is a model
level E activity that reflects how hi$h,maturity or$ani/ations use quantitative! statistically
defensive! o-ective data to ma#e mana$ement decisions and to steer pro-ects to a successful and
predictale outcome.
'he pro-ect mana$ement activities represent economic costs on value,added en$ineerin$
activities. 'hese activities are necessary and important to mana$e ris#! coordinate successful
en$ineerin$ efforts! and set customer expectations appropriately. *owever! you should minimi/e
the effort that is expended on these activities. K+ittle and often9 is a $ood mantra. Smaller
atches reduce complexity and coordination costs. 1hen you define and tailor your process
definition! you should #eep in mind that your pro-ect mana$ement activities should e as
minimal as possile while satisfyin$ the ris# profile of your pro-ect.
Page 10 of 68
3.1.1. Iterati&e 'e&elo(%ent
'eam Foundation to$ether with the MSF for CMMI process template supports iterative wor#.
Iterative development mana$es ris# y deliverin$ demonstrale and tested software at set
intervals throu$hout the pro-ect.
'he pro-ect schedule is or$ani/ed into a series of iterations that are typically four to six wee#s
lon$. 5ach iteration ends with a demonstration of usale! tested software. For more information!
see Create and Modify &rea or Iteration 8aths.
'he pro-ect plan states what feature requirements will e developed in each iteration. 'he
pro-ect plan is developed in Iteration 0 and reviewed at the start of each iteration. 'he
pro-ect plan can e viewed in several ways! such as throu$h the 8ro-ect 2ashoard. For
more information! see =equirement (CMMI) and 8ro-ect 2ashoard (CMMI).
5ach iteration plan states what tas#s will e performed durin$ that iteration. Most tas#s
are development and test wor# that is needed to fulfill the feature requirements that are
scheduled for that iteration. 'he iteration plan can e viewed throu$h the 8ro$ress
2ashoard. For more information! see 'as# (CMMI) and 8ro$ress 2ashoard (CMMI).
Iterative wor# does not automatically mana$e ris#s. 'o minimi/e ris#! you must arran$e the
pro-ect plan in increments. 5arly iterations should provide an 6end,to,end thin slice!6 that is! a
minimal version of the most important ehaviors of the product. +ater iterations add more
functionality.
"y contrast! it would e much less useful to schedule all of the sales part of a shoppin$ 1e site
for the first third of the pro-ect! all of the warehouse system in the second third! and all of the
payments system in the last third. 'his schedule would ris# producin$ an attractive and feature,
rich sales 1e site that has no means for the usiness to ta#e money from its customers. It is
iterative without ein$ incremental.
Incremental development has the followin$ enefits%
Page 11 of 68
Meets the true requirements. Sta#eholders have the opportunity to try out the product!
which always results in improvements to their stated requirements.
'unes the architecture. &llows the development team to discover and address any
difficulties that occur with their platform or potential improvements to their desi$n.
5nsures results. Sta#eholders #now that! even if pro-ect resources are cut part,way
throu$h! the expenditure to date has not een not wasted. 'he same is true if the
development estimates prove to have een optimistic and you must drop the less
important features.
For more information aout how to express the requirements in an appropriate form for
incremental development! see 2evelopin$ =equirements.
3.1.2. )arger and s%aller c*cles
'he pro-ect and the iteration are not the only cyclic aspects of software development. For
example! in an iteration! team memers start and complete tas#s and chec# in code. 'he uild
system uilds the product on a continuous or ni$htly asis. 'he team holds a rief daily review
of pro$ress on the iteration tas#s.
3.1.2.1. )arge #ro$ects
& pro-ect in which a team wor#s throu$h a series of iterations may e part of a lar$er pro-ect or
pro$ram. & lar$e pro-ect has several teams that wor# in parallel. 5ach team typically has four to
;I people.
Page 12 of 68
Cpen a separate version control ranch for each team. 5ach team should inte$rate with the main
ranch at the end of each iteration. For more information! see "ranchin$ and Mer$in$.
=eserve the main ranch for inte$ration and tests. 'he uild machine should perform a complete
set of tests after an inte$ration.
&ssi$n an area to each team so that its wor# items can e easily separated from the others. For
more information! see Create and Modify &rea or Iteration 8aths.
'he teams can share a series of inte$rations! ut this is not always necessary. If the teams do not
synchroni/e inte$rations! each team must have its own prefix for its iteration names.
3.2. Pro'e&t $&ti(ities
3.2.1. +&er&ie,
'o ma#e the most effective use of MSF for CMMI 8rocess Improvement v5.0! you should
or$ani/e your pro-ect into a series of iterations! typically etween four and ei$ht wee#s lon$.
'his helps you reduce the ris#s to your pro-ect that stem from shiftin$ requirements and
implementation costs. Iterative pro-ect structure is an important contriution to meetin$ the ris#
mana$ement requirements of CMMI.
For more information aout CMMI! see "ac#$round to CMMI.
3.2.1.1. -t t.e /tart of t.e #ro$ect
3.2.1.1.1. Pro'e&t I"&eptio"
Inception includes definin$ the pro-ect vision! which states what users will e ale to do when
the pro-ect releases its product.
It also includes settin$ up the team! the infrastructure! and other resources and determinin$ the
development process.
For more information! see 8ro-ect Inception.
3.2.1.1.2. I"itial Pro'e&t Pla""i")
8ro-ect plannin$ includes the followin$ activities%
&naly/in$ the requirements in sufficient detail to enale you to form a plan. 'his analysis
can include the use of requirements models! storyoards! and other tools that help
envisa$e the wor#in$ system.
Page 13 of 68
2evisin$ an overall desi$n or architecture for the system. If this involves wor#in$ on a
platform that is new to team memers! some time must e assi$ned to experimentin$ with
it. 2evelopment will e slow in the earlier iterations.
Castin$ the requirements as a set of incremental product requirements whose
development can e approximately estimated. 'he difference etween $eneral
requirements and product requirements is an important one! and this is a si$nificant
activity. For more information! see 2evelopin$ =equirements.
Ma#in$ an initial assi$nment of product requirements to iterations.
Settin$ dates for releases.
'he plan and requirements models will e revisited and refined throu$hout the pro-ect. 8art of
the purpose of iterative development is to allow improvements in the requirements that stem
from demonstratin$ wor#in$ software at an early sta$e.
Initial pro-ect plannin$ is done in Iteration 0.
For more information! see 8lannin$ the 8ro-ect (CMMI).
3.2.1.1.3. *plori") a" e*isti") produ&t
'he $oal of your pro-ect mi$ht e to update a product that already exists. In this case! if the team
is unfamiliar with the product! exploration of the code is an activity for Iteration 0. 5ach
development tas# in susequent iterations will also involve understandin$ the code in a particular
locality and tracin$ the consequences of chan$in$ it.
For more information! see 5xplorin$ 5xistin$ Code.
3.2.1.2. 'uring t.e #ro$ect
'he plan is reviewed and su-ect to chan$e throu$hout the pro-ect.
Several activities that are related to the pro-ect plan are performed re$ularly throu$hout the
pro-ect! usually toward the end of an iteration.
3.2.1.2.1. +alidatio"
2emonstrate to your customers or usiness sta#eholders the software that has een developed
durin$ the iteration. 1here feasile! release it to them so that they can experiment with it or use
it to a de$ree in a practical context.
Page 1 of 68
&fter a sufficient interval! arran$e a meetin$ to review user feedac#. 'he feedac# should e
used to $enerate chan$e requests.
For more information! see :alidation.
3.2.1.2.2. %is, !a"a)e!e"t
=eview the proaility and impact of potential adverse events! and ta#e steps to reduce the ris#s.
For more information! see Mana$in$ =is#s.
3.2.1.2.3. Cha")e !a"a)e!e"t
You can use chan$e request wor# items to record chan$es in the requirements that are stated y
the usiness sta#eholders. 'hey can stem from chan$es in the usiness context ut also from
demonstration and trials of early versions of the product. 'hese chan$es should e welcomed
ecause they improve the fitness of your product to its usiness purpose. 'his effect is part of the
o-ective of incremental development.
Some pro-ect teams ad-ust the product requirements wor# items when chan$es are requested!
without usin$ a separate wor# item. "ut the advanta$e of the chan$e request wor# item is that! in
the later part of the pro-ect! you can review the numer and nature of the chan$es that were
made. You can use that information to improve your process or architecture for the future.
Chan$e requests should e used as input to the 8roduct 8lan =eview.
For more information! see Mana$in$ Chan$e (CMMI).
3.2.1.2.4. Produ&t Pla" %e(iew
*old a 8roduct 8lan =eview efore you plan each iteration. 'he pro-ect plan assi$ns product
requirements to iterations.
'he plan will chan$e for two principal reasons%
Chan$es in requirements.
Chan$es in the estimates that the developers made. &s the pro-ect pro$resses! the
development team can ma#e more reliale estimates of the wor# that will e required to
implement future features. In some cases! some functionality mi$ht have een postponed
from a previous iteration! which adds a feature to the plan.
"oth types of chan$e ecome less frequent in later iterations.
=evise the requirements models from which the product requirements are derived.
Page 1! of 68
=evise the assi$nment of requirements to iterations. 3ust as in the initial plannin$ activity! the
usiness sta#eholders provide the priorities! the development team provides the estimates! and
the meetin$ -u$$les the features etween iterations.
For more information! see 8lannin$ the 8ro-ect (CMMI).
3.2.1.3. Before Ma$or 0eleases of t.e #roduct
'he activities that are involved in deployment of a product vary accordin$ to its type and are not
dealt with here.
Consider the followin$ points in respect to the later iterations of software development%
5xclude ma-or chan$es to the desi$n to avoid the chance of unforeseen prolems.
=aise the ar for chan$es and u$s in tria$e meetin$s. 8roposed chan$es and u$ fixes
should e re-ected unless they have si$nificant effects on the usaility and fitness for
purpose of the product.
2evote resources to increasin$ test covera$e and to performin$ manual tests.
3.2.2. #ro$ect Ince(tion
You arran$e the asic resources of the pro-ect in an initial sta$e that is named 8ro-ect Inception.
3.2.2.1. #lanning %eeting
&t an early sta$e in the pro-ect! several sta#eholders and su-ect matter experts should e
convened to discuss the pro-ect and ma#e the product plan. You should choose sta#eholders
ased on the nature and complexity of the pro-ect and its product deliverale.
2ependin$ on the si/e of the pro-ect and its complexity! the meetin$ may ta#e several days or
wee#s.
3.2.2.2. Iterati&e de&elo(%ent
&n important technique in ris# mana$ement is plannin$ your pro-ect in iterations! typically of
four to six wee#s. &n iteration plan is a list of features that the pro-ect team will develop and test.
5ach feature specifies a tas# or an improved variant of a tas# that the user will e ale to perform
y usin$ the product. &t the end of each iteration! the planned features are demonstrated. &t the
end of some iterations! the partly completed product is released for trial y a limited set of users.
Page 16 of 68
'he feedac# from those demonstrations and trials is used to review the plan.
'he product plan is arran$ed so that the principal user scenarios and the main components of the
system are exercised at an early sta$e! even if only in a simplified manner.
Cne of the most si$nificant ris#s in most pro-ects is misunderstood requirements. =equirements
can e misunderstood not only y the development team ut also y the end users and
sta#eholders. 'hey can find it difficult to envisa$e how their usiness activities will e affected
y the installation of the new system.
In addition! the usiness context may chan$e durin$ the lifespan of the pro-ect! leadin$ to a
chan$e in the product requirements.
&n iterative process provides assurance that any ad-ustment in the requirements that is found y
demonstratin$ the product can e accommodated efore the end of the pro-ect! without incurrin$
the costs of sustantial rewor#.
&nother si$nificant ris# is poorly estimated development costs. It can e difficult for developers
who wor# in a new area! and perhaps on a new platform! to ma#e accurate estimates of
development costs in advance of the pro-ect. In some cases! it can e difficult to determine
whether a particular implementation strate$y will perform sufficiently well. "ut y reviewin$ the
plan at the end of each iteration! the team can consider the experience of the previous iterations.
'his is one reason why a $ood product plan schedules some wor# on every principal component
at an early sta$e.
3.2.2.3. Is t.is a sco(e1dri&en or date1dri&en (ro$ect2
Some pro-ects require that all the requirements must function efore delivery. 'hese #inds of
pro-ects are unusual in a software context. & real,world example mi$ht e uildin$ a rid$e. &
half,finished span is useless. Cn the other hand! a half,completed ut properly planned software
pro-ect should e deployale and usale for a limited set of users. It can then e completed
incrementally over the course of several up$rades.
First determine whether your pro-ect is truly scope,driven. If it is! you must wait to determine an
end date until you have detailed estimates and a detailed plan. You pay a price for this. 8lannin$
overhead is increased! and schedule ufferin$ as a contin$ency a$ainst poor estimation will push
the delivery date out more! which increases costs. 'herefore! efore you decide that you have a
scope,driven pro-ect! e asolutely sure. It is more proale in a complex systems,en$ineerin$
environment than in a pure software product or service situation.
Most software pro-ects are date,driven ecause they can e delivered incrementally. For
example! if a computer $ame is to e released for the holiday season in the 0nited States! it must
e ready y Cctoer. Failure to deliver in Cctoer will severely affect sales etween *alloween
and Christmas! and! if the schedule slips y two months! the window of opportunity may e lost
alto$ether.
Page 17 of 68
3.2.2.. #lan (ro$ect resources
& pro-ect should e staffed so that it can e delivered y the desired date. *istorical data from
previous pro-ects should e used to inform a discussion aout sufficient resources.
&fter you understand your staff requirements! create a pro-ect or$ani/ation chart that clearly
identifies the pro-ect team structure! resourcin$ levels! and $eo$raphic distriution! if
appropriate. Save all staffin$ information to your pro-ect portal.
3.2.2.!. 'e3ne roles and res(onsibilities
2escrie each pro-ect role and its responsiilities! and pulish them in the pro-ect plan. 5ach
person who -oins the pro-ect should understand their role and responsiilities in the pro-ect.
3.2.2.6. 'e3ne a co%%unication (lan
It is important to define a communication plan for the pro-ect. 8aths of communication help
mana$e the coordination costs on the pro-ect. It is important to define who should attend
meetin$s! how often meetin$s are held! paths of communication! and how to escalate issues that
cannot e resolved y the usual attendees of any one meetin$.
'he o-ective of a $ood communication plan is to ma#e sure that coordination activities on the
pro-ect run as smoothly as possile and to avoid wasted effort throu$h miscommunication.
'he communication plan should e pulished to the pro-ect portal and maintained as it is
required. & communication plan is a useful tool for all staff! particularly new memers. It helps
them understand how a lar$er team wor#s and how to $et thin$s done y communicatin$
appropriately in different ways! with different team memers! and for different purposes.
3.2.2.7. Identif* stake.olders
Identify all relevant pro-ect sta#eholders. In addition to the core team memers! the list should
include usiness people and technical people who have an interest in the successful
implementation of the pro-ect or the effect that the product mi$ht have after it enters service.
'hese sta#eholders may e upstream or downstream of the software en$ineerin$ activity.
3.2.2.8. +utline t.e (ro$ect (lan
Page 18 of 68
Create a s#etch version of the first pro-ect plan! which can e revised when development starts.
'he purpose of this version is to help discuss resources and timescales with pro-ect sponsors. It
should outline the ma-or features and their estimated delivery dates. For more information! see
8lannin$ the 8ro-ect (CMMI).
3.2.2.". 0e&ie, t.e (ro$ect (lan
8ulish the outline of the pro-ect plan on the pro-ect portal. &lthou$h much wor# has $one into
the plan! it is still a hi$h,level plan that defers many detailed schedulin$ decisions. 'his is
intentional. 'oo much detail now will $enerate waste later.
1here requirements are uncertain! plan them in outline only! and detail should e deferred until
more information is availale. 8lan to otain that information.
Schedule a review meetin$ with all sta#eholders. Face,to,face meetin$s are always est for this
#ind of activity. "e sure to schedule enou$h time to enale a full review and to allow dissentin$
opinions to e heard.
3.2.2.10. +btain #ro$ect Co%%it%ents
Gow that the pro-ect plan is a$reed upon with the pro-ect sta#eholders! otain commitments from
each sta#eholder to approve the pro-ect plan.
Collect the commitments! and archive the details in the pro-ect portal.
3.2.2.11. -dditional 0esources
For more information! see the followin$ 1e resources%
& 8ractical 7uide to Feature 2riven 2evelopment! Stephen =. 8almer and 3ohn Malcolm
Felsin$H 8rentice *all 8'=! <00<.
'he I' Measurement Compendium% 5stimatin$ and "enchmar#in$ Success with
Functional Si/e Measurement! Manfred "undschuh and Carol 2e##ersH Sprin$er! <00?.
3.2.3. #lanning t.e #ro$ect 4CMMI5
'he desired outcome of plannin$ a pro-ect is a plan that includes a scope! a schedule! a ud$et! a
ris# mana$ement plan! and a commitment and approval from all sta#eholders. 1ith an a$reed,
upon pro-ect plan! you want to pro$ress with analysis! desi$n! development! testin$! and
eventually delivery.
Page 1" of 68
You can reduce ris# y usin$ an iterative development method. Iterations let you demonstrate a
partly wor#in$ product at the end of each iteration and act on feedac# from that demonstration.
'herefore! the plan provides an overall shape and is su-ect to review and refinement efore the
start of each iteration.
3.2.3.1. 6at.ering and Modeling t.e 0e7uire%ents
'his activity is aout discussin$ what the system should do! with usiness sta#eholders!
prospective users! and su-ect matter experts. It is important to understand the usiness context.
If you have een as#ed to write an application for police officers! it helps to understand their
-ar$on! procedures! and rules.
0M+ models are a useful tool for expressin$ and thin#in$ aout complex relationships. You can
draw them in :isual Studio and lin# them to other documents and to 'eam Foundation wor#
items. For more information see Modelin$ 0ser =equirements.
0pdate and refine the requirements model throu$hout the pro-ect. &s each iteration approaches!
add more detail to the aspects of the model that are relevant to that iteration. From the model!
you can derive verification tests.
For more information! see 2evelopin$ Customer =equirements and 2evelopin$ 'ests from a
Model.
3.2.3.2. Creating Incre%ental #roduct 0e7uire%ents
'he requirements as you have $athered them from your customers are not directly appropriate
for the purpose of schedulin$ incremental development. For example! to clarify the procedure
when a user uys somethin$ from a 1e site! you mi$ht have written a detailed series of steps%
customer rowses catalo$! adds item to cart! chec#s out cart! supplies address! and paysH
warehouse schedules deliveryH and so on. 'hese steps! or an equivalent activity dia$ram! are not
incremental requirements.
Instead! the first increment of your system mi$ht offer only one item for sale! deliver to only one
address! and perform only a test transaction with the payment service. 'he second increment
mi$ht provide a catalo$ that consists of a simple list. +ater increments mi$ht add the option of
$ift wrappin$ the purchase or of requestin$ catalo$s that are provided y different vendors. Some
increments mi$ht e aout quality of service! such as the aility to handle ;!000 customers
instead of only one.
In other words! the early increments should exercise the ma-or use cases end,to,end and
$radually add functionality throu$hout.
Page 20 of 68
If you wor# with an existin$ product! the principle is the same! ut you start from the existin$
functionality. If you are unfamiliar with its internal desi$n! the cost of updates can e difficult to
estimate. It is worth ein$ lieral with your estimates for the earlier chan$es.
For more information! see 2evelopin$ =equirements.
3.2.3.3. 8ntering and 8diting #roduct 0e7uire%ents
=ecord the incremental product requirements as requirement wor# items in 'eam Foundation!
and set the requirements type to Feature. You can create requirement wor# items in 'eam
5xplorer. If you have several wor# items that you want to create at the same time! you can use
the Cffice 5xcel view of the 8roduct =equirements query. For more information! see 1or#in$ in
Microsoft 5xcel and Microsoft 8ro-ect Connected to 'eam Foundation Server and 8erformin$
'op,2own 8lannin$ 0sin$ a 'ree +ist of 1or# Items (In 5xcel).
3.2.3.. 8sti%ating t.e #roduct 0e7uire%ents
'he development team should estimate the wor# that is required to develop each product
requirement. 'he estimate should e entered in hours! in the Cri$inal 5stimate field of the wor#
item.
5arly in the pro-ect! a rou$h estimate is all that is needed.
"rea# lar$e product requirements into smaller ones. Ideally! each product requirement will ta#e
only a few days of development time.
3.2.3.!. -ssigning #roduct 0e7uire%ents to Iterations
=epresentatives of the usiness sta#eholders and the development team should wor# to$ether to
assi$n product requirements to iterations. 'ypically! you do this in a meetin$! where you share or
pro-ect the Cffice 5xcel view of the 8roduct =equirements query.
'he assi$nment is completed y usin$ the followin$ pieces of information%
'he priority of the requirement. See the notes in the followin$ susection.
'he estimated cost. 7iven the numer of team memers and the len$th of the iteration!
each iteration has only a fixed numer of hours that are availale for development.
Furthermore! a si$nificant numer of those hours will e used for iteration plannin$ and
other tas#s that do not directly involve development.
Page 21 of 68
2ependencies amon$ the product requirements. In an incremental series of requirements!
the simplest requirements must e tac#led efore enhancements in the same area.
You can define the requirement in a wor# item y specifyin$ a variety of information! as the
followin$ illustrations show%
Page 22 of 68
3.2.3.#.1. So!e )uideli"es o" prioriti-atio"
Page 23 of 68
Many detailed schemes exist for prioriti/ation. 1e will examine some of these when we consider
iteration plannin$. For now! at the pro-ect level! we include some $uidelines that may e useful
to help mana$e ris# and optimi/e added value.
;. 8rioriti/e minimal end,to,end scenarios.
&im to achieve a simple end,to,end scenario as early in the pro-ect as possile. +ater! add
more features to the different parts of the scenario. 'his practice ensures that the principal
functions of the platform and the principal ideas in the requirements are tried early.
"y contrast! do not divide the schedule accordin$ to the architecture. & schedule that
completes the dataase! then the usiness lo$ic! and then the user interface will proaly
require a $reat deal of rewor# to inte$rate the parts at the end. In the same manner! a
hori/ontal split such as Lsales componentH warehouse componentH payment componentM
is not recommended. It would proaly produce a wonderful system for sellin$ on the
1e ut run out of time efore the usiness has a means of $ettin$ money from its
customers. Complete components can e scheduled for later iterations only if they are
truly optional add,ons.
<. 8rioriti/e technical ris#.
If a scenario includes a technically ris#y element! develop it early in the schedule. 'a#e a
Kfail early9 approach to ris#. If somethin$ cannot e accomplished! you want to #now this
early in the pro-ect so that it can e canceled or replaced with an alternative approach. So
prioriti/e technically ris#y requirements into early iterations.
J. 8rioriti/e reduction of uncertainty.
'he usiness sta#eholders will not e sure aout some requirements. It is difficult to
predict what product ehavior will wor# est in the usiness context. 8rioriti/e wor# that
is li#ely to reduce the uncertainties. 'his can often e achieved y developin$ a simpler
version of the scenario with which users can experiment. 2efer the full scenario to a later
iteration! in which the results of these experiments can e considered.
E. 8rioriti/e hi$hly valuale requirements.
If possile! try to estalish an opportunity,cost,of,delay function for each scenario. 0se
these to determine the requirements that can potentially rin$ more value to the
customers earlier. 8rioriti/e these requirements into earlier iterations. 'his may uy you
the option of releasin$ a partial product early
5. 7roup scenarios that are common to multiple personas.
If you have scenarios that have utility for two or more personas! $roup these to$ether.
=an# them y the numer of personas that require the scenario. 8rioriti/e the scenarios
that apply to a lar$er numer of personas into early iterations.
Page 2 of 68
I. =an# personas.
8ersonas represent mar#et se$ments or user $roups. Mar#etin$ people or usiness owners
should e ale to articulate the priority of such se$ments or $roups ased on utility to e
delivered or the value of the se$ment. If se$ments or user $roups can e ran#ed in
priority! show this y listin$ the personas for each se$ment y ran#. Identify the scenarios
for the hi$hest ran#ed personas! and prioriti/e these into earlier iterations in the schedule.
In $eneral! we want to prioriti/e the reduction of ris# ecause of the possiility of failure. 1e
want to prioriti/e common functionality ecause it is li#ely to e required and unli#ely to
chan$e. 1e want to prioriti/e more valuale requirements. 1e want to enale the option for early
release of the product to a suset of personas y prioriti/in$ all scenarios that are required to
satisfy the needs of any one persona.
3.2.3.6. #lanning Tests
'he wor# estimate for each requirement must include the effort that is required to test the
requirement! either manually or y creatin$ an automated test.
"efore it is considered completed! each product requirement must e lin#ed to a set of test case
wor# items that to$ether demonstrate whether the requirement has een met! and the tests must
pass.
1hen you create or revise product requirements! the correspondin$ test plan must e updated.
3.2.3.7. 0e&ising t.e #roduct 0e7uire%ents
=evisit this activity efore each iteration to consider revised and new requirements! revised
priorities! and revised estimates. 'here will e more revisions in the first few iterations.
&fter the first few iterations! memers of the development team will e more confident aout the
estimates. 'hey should $o throu$h the estimates for the next one or two iterations and revise the
Cri$inal 5stimates fields of the requirements that are assi$ned to those iterations.
3.2.. Managing C.ange 4CMMI5
You can use chan$e request wor# items to trac# and control all chan$es to the product and
supportin$ systems. &ll chan$e requests are initiated as the result of a deviation from the
aseline! which consists of the ori$inal requirements that were identified for the pro-ect. For
example! if a meetin$ with a user uncovers new requirements! a chan$e request should e created
to propose updatin$ the requirements aseline. For more information aout CMMI see
"ac#$round to CMMI.
Page 2! of 68
3.2..1. Creating a C.ange 0e7uest
1hen you reali/e that an ori$inal requirement must chan$e! you create a chan$e request wor#
item and lin# it to the old requirement wor# item y usin$ an &ffects lin# type. & requirement
wor# item that has details of what is new or has chan$ed should also e created and lin#ed to the
chan$e request. &ll chan$e requests are extensively analy/ed for impact on the user! product! and
teams. 2urin$ this analysis! tas#s may e ro#en out for estimation. 'hese new tas# wor# items
should e lin#ed to the new requirement wor# item to provide traceaility. 'his is accomplished
y addin$ the tas#s on the Implementation ta of the wor# item form.
'he chan$e request and resultant new wor# items must contain details of all new wor# that is
required and all existin$ wor# that is to e removed! modified! or oviated. &s the followin$
illustrations show! you can specify the chan$e that you are requestin$ in the 'itle field! the team
memer who owns the chan$e! and other information aout the request%
Page 26 of 68
For more information aout how to complete the wor# item! see Chan$e =equest (CMMI).
3.2..2. -nal*9ing a C.ange 0e7uest
"efore a chan$e request is analy/ed! it should e tria$ed y a confi$uration control oard. &
confi$uration control oard is a $roup of people who are responsile for approvin$ and denyin$
chan$e requests and who ensure that chan$es are implemented correctly. You can indicate that a
request must e tria$ed y settin$ the 'ria$e field in the wor# item to 8endin$. For more
information! see Chan$e =equest (CMMI). &nalysis of chan$e requests can e a drain on
resources! and it is important that the chan$e request queue does not put undue demands on the
team and affect the pro-ect timeline.
& chan$e request should e analy/ed to determine the scope of its impact on existin$ and
planned wor#. 'he effect must e #nown so that it can e used to estimate the cost in person,
hours to implement the chan$e.
&naly/e the ris# of acceptin$ the chan$e. &re external teams dependent upon the code or feature
that would e chan$ed! and could their schedules e adversely affectedB Could assi$nment of
resources to this chan$e adversely affect other important feature areas or requirements of the
productB
&s part of your analysis! request input from sta#eholders and add that input to the chan$e request
wor# item. If the chan$e requires chan$es to other plannin$ documents! note that in the chan$e
request! and chan$e those documents as appropriate. 'his will maintain the revision history and
enale everyone to see the details. 'his miti$ates ris# from ad communication and provides
important evidence for a Standard CMMI &ppraisal Method for 8rocess Improvement
(SC&M8I) appraisal.
Page 27 of 68
If a chan$e request is accepted! chan$e the State from 8roposed (the default for new chan$e
requests) to &ctive.
3.2..3. Monitoring C.ange 0e7uests
1hile a chan$e request is active! you can monitor it y usin$ the chan$e request query in :isual
Studio 'eam Foundation Server. Chan$e requests should e processed in a reasonale amount of
time.
If a chan$e request does not receive the attention that it requires! escalate the matter y creatin$
an issue wor# item. +in# the new issue to the chan$e request! and escalate the issue to $et the
chan$e request impact assessment on trac#.
3.2.!. Managing 0isks
=is# implies that actual outcomes may vary (sometimes si$nificantly) from desired outcomes.
"oth the proaility of this variance and the de$ree of variance etween actual and desired
outcomes is encapsulated in the term Kris#.9 1hen you mana$e ris#! you strate$ically minimi/e
the variance etween the outcome that you want and the actual outcome.
'he aility to identify! classify! analy/e! and mana$e ris#s is an or$ani/ational capaility that is
required to achieve a Standard CMMI &ppraisal Method for 8rocess Improvement (SC&M8I)
appraisal at level J. For more information aout CMMI! see "ac#$round to CMMI.
"y mana$in$ these event,driven ris#s! a si$nificant contriution is made to the overall $oal of
mana$in$ ris# at the pro-ect! portfolio! and or$ani/ational levels. 7ood event,driven ris#
mana$ement contriutes to an outcome that is satisfactory to all sta#eholders and that deviates
little from the initially desired outcome. It contriutes to an expectation of Kno surprisesN9
3.2.!.1. 'e3ne 0isks
'hin#in$ of ris#s in this manner is sometimes referred to as the event,driven ris# model. 'his
implies that a list of ris#s is a list of potential future events. 5ach ris# descries some event that
may occur in the future. It may include some information aout the proaility of occurrence. It
should include a description of the impact that such an occurrence would have on the pro-ect
plan. It may also include a description of ways to reduce the proaility of occurrence and ways
to miti$ate the impact of occurrence. It may also include su$$ested forms of recovery after an
occurrence.
For each ris# that is identified! create a ris# wor# item in the team pro-ect.
Page 28 of 68
3.2.!.2. T.e 0isk :ork Ite%
'he =is# Mana$ement (=SFM) process area in the CMMI focuses on the mana$ement of these
event,related ris#s. MSF for CMMI 8rocess Improvement and :isual Studio 'eam Foundation
Server ma#e this easier y providin$ the ris# wor# item type. "y usin$ the ris# wor# item type!
you can define and trac# a list of ris#s. It provides fields to descrie the ris#! the proaility of
occurrence. It also provides fields for actions that can e ta#en to reduce the proaility of
occurrence! miti$ate the impact! and implement contin$ency plans for recovery in the event of an
occurrence.
'he initial pro-ect ris#s should e identified durin$ pro-ect plannin$. 'he ris# list should e
revisited durin$ iteration plannin$ at the start of each pro-ect iteration.
'he wor# item form for a ris# stores data in the fields that the followin$ illustration shows%
3.2.!.3. /elect -ctions to be Taken
Page 2" of 68
&fter you create a list of ris#s and they have een sufficiently analy/ed! it is time to decide what!
if any! actions will e ta#en to mana$e these ris#s. &re there any actions that will reduce the
proaility of occurrence that you want to ta#e now or descrie in an iteration planB &re there
any actions that would miti$ate the impact of occurrence that you want to ta#e now or descrie
in an iteration planB 'a#in$ actions to reduce or miti$ate ris#s costs time and resources. 'his
must e traded a$ainst usin$ those resources and the availale time to move the pro-ect wor#
forward and turn the scope into wor#in$ software. 2ocument the ris# reduction and miti$ation
actions that you plan on the Miti$ation ta of the ris#.
'he overall ris# profile for the pro-ect must e considered when you decide when to ta#e action
to reduce the proaility or miti$ate the impact of ris#s. If the ris# profile says Kany loss of life is
unacceptale!9 any ris# that mi$ht cause a loss of life must e mana$ed! and reduction and
miti$ation actions must e planned and ta#en.
You should ensure that ris#s are mana$ed in line with pro-ect $overnance constraints and in an
appropriate alance with the need to achieve delivery of all value,added wor# within the
availale time and ud$et.
If a ris# is selected for reduction of proaility or miti$ation of its impact! plan this activity y
rea#in$ it into tas# wor# items and lin# each to a ris# wor# item.
'he wor# item form for a ris# stores data in the tas that the followin$ illustration shows%
3.2.!.. Monitor 0isks
8ro-ect ris#s should e monitored re$ularly.
0se the ris#s query to monitor ris#s. Scan each active ris# on the list! and consider whether the
proaility of occurrence has increased! whether the potential impact has chan$ed! and whether
any miti$ation tri$$er events have occurred. If there is any material chan$e in the information
that is captured for a ris#! update the wor# item. &lso! consider whether further action needs to
e ta#en to reduce the ris# or to miti$ate its impact.
Page 30 of 68
'he current ris# status of the pro-ect should e communicated. =eports should include
information aout any ris#s that were recently uncovered! any reduction or miti$ation actions
that are in pro$ress! and any chan$e in status that would cause a chan$e in the earlier assessment
of the ris#.
3.2.!.!. Make Contingenc* #lans
For ris#s where a recovery action was defined! a plan should e made to implement the
contin$ency if the event of occurs. For example! if there is a ris# that a server mi$ht fail and the
contin$ency is to orrow hardware from another department! you should have a plan to enact this
if the server fails. Ma#in$ plans in advance reduces the coordination challen$e if the event
occurs. & hi$her maturity or$ani/ation with a $reater capaility for ris# mana$ement ma#es
contin$ency plans and #nows how to enact them without si$nificant impact to other pro-ect
activities. +ower maturity or$ani/ations suffer panic and chaos while tryin$ to recover from
unexpected events. &n or$ani/ation that see#s a SC&M8I appraisal at level J should have
documented evidence to show that contin$ency plans were made and! when appropriate!
followed.
"rea# out the contin$ency plan into a series of tas#s or actions to e ta#en. 5stimate each tas#.
Create a schedule and a recommended list of assi$ned personnel. 2escrie all the resources that
will e required to execute the contin$ency plan.
&dd the contin$ency plan to the ris# wor# item on the Contin$ency 8lan ta! or add the plan as
an attachment.
3.3. Iteratio" $&ti(ities
3.3.1. +&er&ie,
In MSF for CMMI 8rocess Improvement v5.0! you plan a pro-ect as a series of iterations. 5ach
iteration is typically four to six wee#s lon$! durin$ which the development team implements a
specified set of requirements.
3.3.1.1. -t t.e start of an iteration
Iteration plannin$ ta#es place at or efore the start of each iteration. It includes the followin$
tas#s%
=eview the requirements that are assi$ned to the iteration! and define them in more detail.
Create tas# wor# items for the wor# that must e performed to implement and test each
requirement. +in# the tas#s to the requirement wor# item y usin$ the parent lin# type.
Page 31 of 68
Set the Cri$inal 5stimate field of each tas#. 2ivide tas#s that have estimates that are
lon$er than a few days.
Compare the estimates with the time that is availale for the iteration. If the estimate total
is too lon$! simplify some of the requirements! or defer them to later iterations.
For more information! see 8lannin$ an Iteration (CMMI).
3.3.1.2. 'uring an iteration
3.3.1.2.1. .as, e*e&utio"
'eam memers start and complete tas#s! recordin$ these events in wor# items. Completion of a
tas# mi$ht include chec#in$ in pro$ram code and other artifacts. 5ach tas# should last no more
than a few daysH lar$er tas#s are split durin$ iteration plannin$. For more information see
Creatin$! Copyin$! and 0pdatin$ 1or# Items and Completin$ 2evelopment 'as#s.
If a team memer encounters any ostacle to their wor# that cannot e resolved immediately!
they should lo$ an issue wor# item. For more information see Issue (CMMI).
3.3.1.2.2. .ests
Manual or automatic tests should e developed! and test cases should e lin#ed to the product
requirements. & product requirement cannot e considered completed until the wor# item is
lin#ed to test cases that pass and that demonstrate that it is wor#in$.
2evelopment wor# for the tests should e included in the tas#s that are lin#ed to the product
requirement.
3.3.1.2.3. %olli") a"d "i)htly /uilds
'he uild system uilds the product from recently chec#ed,in updates and runs automated tests.
You can set principal tests to run on a continuous asis! and you can set a full suite to run every
ni$ht. 'his practice helps to ensure that multiple increments do not create an accumulation of
u$s. For more information see &dministerin$ 'eam Foundation "uild.
3.3.1.2.4. Sta"d0up !eeti")
'he whole team conducts a rief daily review of pro$ress on the tas#s of the iteration. 'eam
memers mi$ht pro-ect the 8ro$ress 2ashoard on the wall! share it y usin$ Cffice +ive
Meetin$! or oth. For more information! see 8ro$ress 2ashoard (CMMI).
Page 32 of 68
5ach team memer riefly reports recent pro$ress! wor# in hand for the day! and any
loc#in$ issues.
'he pro-ect mana$er or team leader reports on pro$ress toward resolvin$ issues. For more
information! see Mana$in$ Issues (CMMI).
'he u$ count is reviewed. "u$s should e $iven priority over new development. &im to
#eep the u$ count low throu$hout the pro-ect. If the numer of u$s increases! discuss
the causes and the possile impact on development wor#.
'he urndown rate is reviewed.
3.3.1.2.#. S&ope ad'ust!e"ts
'he "urndown Chart mi$ht indicate that the tas#s will not e completed y the end of the
iteration. In that case! the pro-ect mana$er or team leader initiates a discussion aout how
requirements can e simplified so that tas#s can e cut. For more information! see "urndown and
"urn =ate =eport (CMMI).
'he requirements and correspondin$ tests are ad-usted. & new requirement feature is put on the
pro-ect plan for the missin$ functionality. In the pro-ect plan review that is held toward the end of
the iteration! the feature mi$ht e assi$ned to a future iteration or cut.
Chan$e requests and ris#s are not considered durin$ an iteration.
3.3.1.2.1. .ria)e
Some team memers (usually not the whole team) meet re$ularly to review u$s. 5very team
memer must lo$ a u$ when they discover a defect. & lo$$ed u$ starts in the 8roposed state!
and the purpose of the tria$e meetin$ is to decide whether to fix it! postpone it to a later iteration!
or re-ect it.
For more information! see 1or#in$ with "u$s.
3.3.1.3. -t t.e end of an iteration
3.3.1.3.1. +eri2&atio"
'he requirements are considered completed only if the associated tests pass. For more
information! see :erifyin$ =equirements.
3.3.1.3.2. %etrospe&ti(e
8rocess improvement is an important CMMI $oal.
Page 33 of 68
&n iteration retrospective reflects on what went well or adly in the iteration and considers
improvements to the process and tools that are used y the team. & si$nificant volume of
material aout retrospectives is availale on the 1e.
'eam memers should avoid any assi$nment of lame. 'ry to improve the process so that
mista#es that are made y individuals are less li#ely to have an effect.
1hen you introduce a chan$e in your process! ma#e sure that the team a$rees on the followin$
decisions%
*ow you will #now whether it was an improvement.
1hen you will ma#e that assessment.
1hat you will do as a result.
3.3.1.3.3. I"te)ratio"
If this pro-ect is part of a lar$er pro$ram! each team performs its wor# in a ranch of the version
control system. 'he Main ranch is reserved for inte$ratin$ the wor# of the teams. &t the end of
an iteration! the team mi$ht perform an inte$ration with the main ranch. For more information!
see "ranchin$ and Mer$in$.
'he inte$ration consists of two steps%
& forward inte$ration! to mer$e the newer code from the main ranch into the local
pro-ect ranch. &fter performin$ the mer$e! automatic and manual tests are run. 'his will
create some defects. 'he defects are fixed at hi$h priority.
& reverse inte$ration. 'he local ranch code is mer$ed into the main ranch! and the
uild and full test suite on the main ranch runs. 'he chan$es are reversed if any errors
occur. Introducin$ errors to the main ranch is frowned upon. If no errors occur! the
inte$ration is declared completed.
1e recommend that you perform an inte$ration at the end of each iteration. If you delay it! the
list of u$s to e fixed after forward inte$ration is lon$er. If it ta#es a lon$ time to fix the u$s!
the main ranch will have new material! and you will have to perform another forward
inte$ration.
3.3.1.3.4. Prepari") for the 3e*t Iteratio"
'oward or at the end of an iteration! several pro-ect mana$ement activities are performed. 'hese
include reviewin$ ris#s and reviewin$ the plan with re$ard to chan$e requests and chan$ed
development estimates.
For more information! see 8ro-ect &ctivities.
Page 3 of 68
3.3.2. #lanning an Iteration 4CMMI5
2evelopin$ software in iterations means that you divide your wor# into incremental sta$es such
that you have software with pro$ressively more wor#in$ features at the end of each iteration.
Ideally! you have somethin$ to show the customer after even the first iteration. Iterations let you
receive feedac# early so that you can ma#e course corrections early.
'he matter of plannin$ iterations comes down to decidin$ how lon$ you want your iterations to
e! determinin$ how much wor# your team can $et done in that time! and plannin$ what wor#
should e included in each iteration.
'he MSF for CMMI 8rocess Improvement template supplies an Iteration 8ath field in each wor#
item to help you trac# your wor# y iteration. You can customi/e that path to reflect the
iterations that you plan to perform. For more information aout CMMI! see "ac#$round to
CMMI
In this topic
5stimate the appropriate wor# load for an iteration
Schedule an iteration demonstration and handoff
+aunch an iteration
'rac# an iteration
3.3.2.1. Create tasks to i%(le%ent and test eac.
re7uire%ent
'he iteration plan is represented y the list of tas#s that are scheduled for the iteration. 5ach tas#
is lin#ed to the product requirement that it implements.
'he tas# list is visile in the 1or# "rea#down query and on the 8ro$ress 2ashoard . For more
information! see 8ro$ress 2ashoard (CMMI).
&t the start of the iteration! the team reviews the requirements that are scheduled for this iteration
and creates tas# wor# items. 'he tas# wor# items descrie the wor# (such as desi$n!
development! and testin$) that is required to complete the requirement.
'he tas#s can e most easily created and lin#ed to the product requirements y usin$ Cffice
5xcel. For more information! see 8erformin$ 'op,2own 8lannin$ 0sin$ a 'ree +ist of 1or#
Items (In 5xcel).
2urin$ the iteration! team memers update the completion status and wor# remainin$ fields of
the tas#s. If the team #eeps this information current! the 8ro$ress dashoard and other reports
Page 3! of 68
indicate how much wor# remains and the slope of the urndown chart indicates whether the
wor# is li#ely to e completed on time.
3.3.2.2. 8sti%ate t.e a((ro(riate ,ork load for t.e
iteration
It is most li#ely that! durin$ pro-ect plannin$! it was a$reed that product increments should e
developed in a series of time,ound iterations. 'ypically! these iterations vary from one wee# to
four wee#s.
'he template provides the followin$ reports! which are useful when estimatin$ how much wor#
to plan for an iteration.
Status on &ll Interations 'his report helps you trac# team performance over successive
iterations. 0se the report to see how many requirements and how many hours were
completed in an iteration.
=equirements Cverview 'his report lists all requirements! filtered y area and iteration
and sorted in order of importance. 'his report can show you how much wor# was
completed y the team in an iteration.
"urndown and "urn =ate "urndown shows the trend of completed and remainin$ wor#
over a specified time period. 'he urn rate shows the completed and required rate of
wor# ased on the len$th of the iteration.
3.3.2.3. /c.edule an iteration de%onstration and .ando;
You should plan time to demonstrate the incremental functionality to sta#eholders! to $ather the
team for a retrospective! and to hand off the completed wor# for validation tests.
'ypically! you should allocate time on the last day of the iteration to demonstrate the wor#in$
functionality to sta#eholders.
=ecord the feedac#! and save it on the pro-ect portal. If the demonstration rin$s new tas#s or
requirements to li$ht! create wor# items as necessary. 'hese should then e fed into future
iteration plans.
3.3.2.. )aunc. an iteration
Fic# off the iteration with a mini,version of the pro-ect launch. "rin$ the team to$ether. Cutline
the $oals and the scope of the iteration. 2iscuss and present the plan and any tar$ets. 5nsure that
all team memers have enou$h context to continue with the wor# in a self,or$ani/in$ manner.
Page 36 of 68
Ma#e time and space for questions from team memers! and record any issues or ris#s that are
rou$ht up durin$ the meetin$. Store these as minutes in the pro-ect portal. &s a pro-ect mana$er!
follow up y creatin$ ris# and issue wor# items! as appropriate.
3.3.2.!. Track an iteration
'hrou$hout the iteration! you should monitor its pro$ress daily y usin$ the reports that are
provided with the template. You will want to pay extra attention to the =emainin$ 1or#!
0nplanned 1or#! and =equirements Cverview reports to ma#e sure that the iteration is trac#in$
a$ainst expectations. For more information! see =emainin$ 1or# =eport! 0nplanned 1or#! and
=equirements Cverview =eport (CMMI).
3.3.2.6. -dditional resources
For more information! see the followin$ 1e resources%
8ro-ect =etrospectives% & *andoo# for 'eam =eviews! Gorman FerthH 2orset *ouse! <00;.
&$ile =etrospectives% Ma#in$ 7ood 'eams 7reat! 5sther 2ery and 2iana +arsenH 8ra$matic
"oo#shelf! <00I.
3.3.3. Managing Issues 4CMMI5
You can use the issue wor# item in :isual Studio 'eam Foundation Server to help you trac#
prolems with the pro-ect plan and its activities and tas#s. Issues are not to e confused with
u$s. 'he u$ wor# item type is provided to trac# prolems with the code and specific failin$
tests. 'he issue wor# item type is provided to help you trac# all other prolems with the pro-ect.
Some examples are ami$uity in the requirements! unavailaility of personnel or other resources!
prolems with environments! other pro-ect ris#s that are occurrin$! and! in $eneral! anythin$ that
puts successful delivery of the pro-ect at ris#.
1hat ma#es issues different is that they represent unplanned activities. =esolvin$ issues is not
normal pro-ect wor#. 'herefore! it must e trac#ed and $iven special attention. 'rac#in$ these
pro-ect prolems with issue wor# items and usin$ the reportin$ and queries in 'eam Foundation
Server helps to develop a core capaility to mana$e and resolve issues quic#ly and effectively.
3.3.3.1. Create an Issue :ork Ite%
1hen an issue occurs! create an issue wor# item! descrie the prolem! and descrie su$$ested
resolutions! if any are #nown. 'he issue wor# items for the pro-ect create a si$nificant ody of
Page 37 of 68
evidence for a Standard CMMI &ppraisal Method for 8rocess Improvement (SC&M8I)
appraisal. For more information aout CMMI! see "ac#$round to "ac#$round to CMMI.
'he wor# item form for an issue stores data in the fields and tas that appear in the followin$
illustrations%
3.3.3.2. 0e&ie, t.e Issues
Page 38 of 68
'he open issues on the pro-ect should e reviewed re$ularly.
'o view the issues! run the Cpen Issues query that is provided with the template. Sort the issues
y status usin$ Kproposed9 to tria$e any new issues. For more information! see Issue (CMMI).
3.3.3.3. -nal*9e Issues
5ach new issue should e analy/ed for oth its symptoms and root cause. & plan of corrective
action should e made to address the symptoms or (preferaly) the root cause. =ecord the plan
on the Corrective &ction ta of the issue. 'he decision to wor# around the issue or try to fix the
root cause should reflect the pro-ect ris#s. 'hese decisions should e documented in the issue
wor# item. 'hey will provide evidence for a SC&M8I appraisal and demonstrate a level of
capaility at ris# mana$ement that is important for level J appraisal.
1or#in$ around symptoms is a lower,maturity ehavior that shows a level of capaility that is
adequate for a CMMI model level < or J appraisal. =oot cause analysis and resolution implies
that the or$ani/ation intends that the issue should not recur. 'his is a hi$her,maturity ehavior. It
demonstrates a level of capaility in issue resolution and process improvement that is typical of
an or$ani/ation that achieves a level E or 5 appraisal.
=ecord the action plan! and then rea# the wor# into tas# wor# items! lin#ed to the issue wor#
item as children. For more information aout how to lin# wor# items! see Issue (CMMI). 'as#s
should e assi$ned to individual team memers for resolution. 5ach tas# should e created
to$ether with a tas# type of Kcorrective action.9
Page 3" of 68
3.3.3.. <erif* 0esol&ed Issues
2urin$ your re$ular review of open issues! it is a $ood idea to review issues that have een
mar#ed as resolved. If a consensus accepts the documented resolution! mar# the issue as
Kclosed!9 and set its reason to Kresolved.9 0se the open issues query! and filter for state equals
Kresolved.9
3.3.3.!. 0e&ie, Issues for 0esolution
&fter all tas#s under an issue have een completed! the sta#eholders should decide whether the
issue has een resolved.
Cpen the issue wor# item and any loc#ed wor# items. You can refer to the Corrective &ctions
ta to view the ori$inal plan for action and what action was ta#en. You can also see the tas# wor#
items that are associated with the issue y displayin$ the &ll +in#s ta for the Child lin#s. *as
the corrective action successfully unloc#ed the wor# items and resolved the issueB If not!
rewor# the corrective actions! and reassi$n them to team memers. 1as the corrective action
performed promptlyB 1as an unexpected external (or special cause) event and impact on the
Page 0 of 68
schedule critical path avoidedB &re the pro-ect commitments safe! or must they e rene$otiatedB
=ecord all this detail in the wor# item. 'his $enerates valuale evidence for a CMMI appraisal.
If the sta#eholders are satisfied that the issue has een resolved successfully! mar# the issue as
Kresolved.9 It can then e formally closed.
If the issue has not een successfully resolved! rewor# the corrective action tas#s! and assi$n
them to suitale personnel for resolution. =econsider the priority of the issue! and consider
raisin$ it to expedite resolution and to avoid additional delay.
3.3.3.6. -dditional 0esources
For more information aout SC&M8I appraisals! see the followin$ 1e pa$e% Software
5n$ineerin$ Institute.
. 8ngineering
T%e -ngineering section of t%e MSF for CMMI Process Improvement guidance covers
t%e value<added activities for discovering t%e information t%at is re8uired to design
and build soft+are products. T%e -ngineering grouping of process areas in t%e CMMI
includes 0e8uirements 2evelopment> 0e8uirements Management> Tec%nical
Solution> Product Integration> 9eri=cation> and 9alidation. /ll of t%ese are model
level ! or ) process areas.
4.1. 4e(elopi") %e5uire!e"ts
=equirements descrie what the sta#eholders expect from the product. You should express your
requirements in terms that allow them to e easily discussed with the usiness sta#eholders!
usin$ the vocaulary and concepts of the usiness domain. =equirements should neither discuss
nor depend on the implementation. =equirements include not only the ehavioral and quality of
service expectations of the users ut also statutory constraints and commercial standards.
"y recordin$ requirements in :isual Studio 'eam Foundation Server y usin$ the requirements
wor# item! you $ain the followin$ enefits%
:erify that requirements have een satisfied y lin#in$ them to test cases.
Monitor pro$ress toward implementin$ the requirements y lin#in$ them to tas# wor#
items.
Structure the requirements into overall and more detailed requirements so that you can
mana$e them more easily and so that pro$ress reports can summari/e the information.
Model the requirements in :isual Studio 0ltimate! lin#in$ model elements to
requirements in 'eam Foundation Server.
Page 1 of 68
'his topic does not attempt to replicate the very lar$e ody of literature that is availale on the
su-ect of determinin$ requirements. Instead! it focuses on the aspects that are important for
usin$ the :isual Studio tools in a manner that conforms to CMMI. For more information aout
CMMI! see "ac#$round to CMMI.
'he activities that are descried in this topic! li#e any development activities! should not e
performed in strict order. 2evelop a domain model while you are writin$ scenarios ecause one
activity will help you improve the other activity. 2evelop the scenarios as the time for codin$
them approaches. Feed the experience with code that has een written and demonstrated ac# to
the scenarios that have yet to e implemented.
.1.1. :.en to 'e&elo( 0e7uire%ents
'eam Foundation Server supports iterative wor#in$! and this practice is most effective when the
early iterations are used to $ain feedac# from prospective users and other sta#eholders. 'his
feedac# can e used to improve the requirements that have een stated for future iterations. 'his
results in a product that is much more effective in its ultimate installation than a product that is
developed over the same period without any user trial. If your pro-ect is one component amon$
many in a lar$er pro$ram! early inte$ration with other components allows the pro$ram architects
to improve the overall product.
'his flexiility must e alanced a$ainst the need to $ive firm commitments to your customer or
to partners in parallel pro-ects.
'o a controlled extent! therefore! requirements are developed and refined throu$hout the pro-ect.
"ecause the detailed requirements are li#ely to chan$e durin$ the pro-ect! determinin$ them in
full efore the appropriate implementation is li#ely to result in wasted effort.
In Iteration 0! develop a set of requirements that descrie of the main features! with -ust
enou$h detail to form a product plan. 'he product plan assi$ns requirements to iterations
and states what requirement will e fulfilled at the end of each iteration. Create a domain
model of the ma-or concepts and activities! and define the vocaulary that will e used
for those concepts oth in discussion with the users and in the implementation. 2etermine
road requirements that pervade every feature! such as security and other quality of
service requirements.
&t or near the start of each iteration! develop the requirements for those features in more
detail. 2etermine the steps that the users will follow! definin$ them with the help of
activity or sequence dia$rams. 2efine what happens in exceptional cases.
:erify as often as possile all the requirements that have een implemented. 8ervasive
requirements! such as security! must e verified with tests that are extended for each new
feature. If possile! automate the tests ecause automatic tests can e performed
continuously.
Page 2 of 68
.1.1.1. Managing re7uire%ents c.anges
'he followin$ $uidelines let you operate an incremental process while monitorin$ it to satisfy
CMMI requirements.
2o not chan$e the requirements that are set for an iteration. In the rare case of an arupt
chan$e in circumstances! you mi$ht have to cancel an iteration! review the product plan!
and start a new iteration.
+oo# for uncertainties in the requirements. 'ry to arran$e the plan so that user experience
with early iterations yields information that reduces the uncertainties.
0se chan$e request wor# items to record requests to chan$e ehavior that has already
een implemented! unless the requested improvement is already part of the plan. +in#
each chan$e request to the appropriate requirement wor# items. For more information!
see Chan$e =equest (CMMI).
=eview chan$e requests when you review the product efore each iteration. 5xamine the
impact of the request on dependent pro-ects and users! and estimate the cost with re$ard
to chan$es in your code. If a chan$e request is accepted! update the requirement.
0pdate the tests to conform to every requirements chan$e.
2esi$nate a cut,off date (for example! after iteration < or J) after which requirements
chan$es must e much more stron$ly -ustified. If your pro-ect is for a payin$ customer!
this is the date to have the customer approve a aseline set of requirements and switch
from hourly payment to fixed price.
0se u$ wor# items to record implemented ehavior that does not perform accordin$ to
the explicit or implicit requirements. 1here practical! create a new test that would have
cau$ht the u$.
.1.2. :rite a <ision /tate%ent
2iscuss a vision statement with the team! and display it on the pro-ect.s 1e portal for 'eam
Foundation Server.
& vision statement is a short summary of what enefit the product will rin$. 1hat will the users
e ale to do that they could not do eforeB 'he vision statement helps clarify the scope of the
product.
If the product already exists! write a vision statement for this version. 1hat will the product.s
users e ale to do that they could not do eforeB
Page 3 of 68
.1.3. :rite /cenarios
1or# with your customer and other sta#eholders to create scenarios! and enter them as
requirement wor# items! with the =equirement 'ype field set to Scenario.
& scenario or use case is a narrative that descries a sequence of events! shows how a particular
$oal is achieved! and usually involves interaction etween people or or$ani/ations and
computers.
7ive it a descriptive title that clearly distin$uishes it from others when viewed in a list. Ma#e
sure that the principal actor or actors are stated and that their $oal is clear. For example! this
would e a $ood title%
Customer uys a meal.
You can write a scenario in the followin$ forms. Sometimes it can help to use more than one
form%
Cne or two sentences in the wor# item description%
& customer orders a meal on a 1e site and pays with a credit card. 'he order is passed
to a restaurant! which prepares and delivers the meal.
Gumered steps in the wor# item description%
;. & customer visits the 1e site and creates an order for a meal.
<. 'he 1e site redirects the customer to a payment site to ma#e payment.
J. 'he order is added to the restaurant.s wor# list.
E. 'he restaurant prepares and delivers the meal.
Storyoard. & storyoard is essentially a cartoon strip that tells the story. You can draw it
in 8ower8oint. &ttach the storyoard file to the requirement wor# item! or upload the file
to the team portal! and add a hyperlin# to the wor# item.
& storyoard is especially useful for showin$ user interactions. "ut for a usiness
scenario! it is recommended to use a s#etch style that ma#es it clear that this is not the
final desi$n for the user interface.
=equirement documents. =equirement documents $ive you the freedom to provide the
appropriate level of detail for each requirement. If you decide to use documents! create a
1ord document for each requirement! and attach the document to the requirement wor#
item! or upload the file to the team portal and add a hyperlin# to the wor# item.
Page of 68
0nified Mar#up +an$ua$e (0M+) sequence dia$ram. & sequence dia$ram is especially
useful where several parties interact. For example! orderin$ the meal requires the
customer! the 2innerGow 1e site! the payment system! and the restaurant to interact in
a specific sequence. 2raw the sequence dia$ram in a 0M+ model! chec# it into 'eam
Foundation Server! and enter a lin# in the requirement wor# item. For more information!
see 0M+ Sequence 2ia$rams% 7uidelines.
.1.3.1. /(eci3c /cenarios
Start y writin$ specific scenarios! which follow a particular set of actors throu$h a specific
sequence. For example! 6Carlos orders a pi//a and $arlic read at the 2innerGow 1e site. 'he
1e site redirects Carlos to 1ood$rove "an#.s payment service. Fourth Coffee prepares the
pi//a and delivers it.6
Specific scenarios help you envisa$e the system in use and are most useful when you first
explore a feature.
It can also e useful to create named personas that descrie the ac#$rounds and other activities
of people and or$ani/ations. Carlos sleeps rou$h and uses an Internet cafOH 1endy lives in a
$ated communityH San-ay orders meals for his wife at her wor#H Contoso runs a chain of <!000
restaurants worldwideH Fourth Coffee is run y a couple who deliver y icycle.
More $eneric scenarios that are written in terms of 6a customer!6 6a menu item!6 and so on can
e more convenient ut are less li#ely to lead to the discovery of useful features.
.1.3.2. )e&els of detail
In Iteration 0! write a few important scenarios in some detail! ut write most scenarios in outline.
1hen an iteration approaches in which a particular scenario is to e fully or partly implemented!
add more detail.
1hen you first consider a scenario! it can e useful to descrie the usiness context! even aspects
in which the product ta#es no part. For example! descrie the 2innerGow method of delivery%
2oes each restaurant or$ani/e its own deliveries! or does 2innerGow run a delivery serviceB 'he
answers to such questions provide useful context for the development team.
'he more detailed scenarios that you develop at the start of an iteration can descrie user
interface interactions! and storyoards can show user interface layout.
.1.3.3. +rgani9ing t.e scenarios
You can or$ani/e scenarios y usin$ the followin$ methods%
Page ! of 68
2raw use case dia$rams that show each scenario as a use case. 'his method is
recommended ecause it ma#es the scenarios very easy to present and discuss. For more
information! see 0M+ 0se Case 2ia$rams% 7uidelines.
o +in# each use case to the wor# item that defines the scenario. For more
information! see *ow to% +in# from Model 5lements to 1or# Items.
o 2raw 5xtends relationships to show that one scenario is a variation of another.
For example! 6Customer specifies separate payment and delivery addresses6 is an
extension of the asic 6Customer ma#es an order6 use case. 5xtensions are
particularly useful to separate out scenarios that will e implemented in a later
iteration.
o 2raw Includes relationships to separate a procedure such as 6Customer lo$s on!6
which is common to several use cases.
o 2raw $enerali/ation relationships etween $eneral scenarios such as 6Customer
pays6 and specific variants such as 6Customer pays y card.6
Create parent,child lin#s etween scenario wor# items in 'eam Foundation Server. You
can view the hierarchy in 'eam 5xplorer. For more information! see &rran$in$
=equirements into a 8roduct 8lan.
.1.. Model t.e business do%ain
Create a 0M+ model that descries the principal activities and concepts that are involved in the
use of your product. 0se the terms that are defined in this model as a 6uiquitous lan$ua$e!6 in
the scenarios! in discussions with the sta#eholders! in the user interface and any user manuals!
and in the code itself.
Many requirements are not explicitly stated y your customer! and comprehendin$ the implied
requirements depends on an understandin$ of the usiness domain! that is! the context in which
the product will wor#. Some of the wor# of requirements $atherin$ in an unfamiliar domain is!
therefore! aout $ainin$ #nowled$e of that context. &fter this #ind of #nowled$e has een
estalished! it can e used on more than one pro-ect.
Save the model in version control.
For more information! see Modelin$ 0ser =equirements.
.1..1. Modeling Be.a&iors
2raw activity dia$rams to summari/e scenarios. 0se swimlanes to $roup the actions that are
performed y different actors. For more information! see 0M+ &ctivity 2ia$rams% 7uidelines.
Page 6 of 68
&lthou$h a scenario usually descries a specific sequence of events! an activity dia$ram shows
all the possiilities. 2rawin$ an activity dia$ram can prompt you to thin# aout alternative
sequences and to as# your usiness clients what should happen in those cases.
'he followin$ illustration shows a simple example of an activity dia$ram.
1here the interchan$e of messa$es is important! it mi$ht e more effective to use a sequence
dia$ram that includes a lifeline for each actor and ma-or product component.
0se case dia$rams let you summari/e the different flows of activity that your product supports.
5ach node on the dia$ram represents a series of interactions etween the users and the
application in pursuit of a particular user $oal. You can also factor common sequences and
optional extensions into separate use case nodes. For more information! see 0M+ 0se Case
2ia$rams% 7uidelines.
'he followin$ illustration shows a simple example of a use case dia$ram.
Page 7 of 68
.1..2. Modeling Conce(ts
2raw domain class dia$rams to descrie the important entities and their relationships that are
mentioned in the scenarios. For example! the 2innerGow model shows =estaurant! Menu! Crder!
Menu Item! and so on. For more information! see 0M+ Class 2ia$rams% 7uidelines.
+ael the roles (ends) of the relationships with names and cardinalities.
In a domain class dia$ram! you do not typically attach operations to the classes. In the domain
model! the activity dia$rams descrie the ehavior. &ssi$nin$ responsiilities to pro$ram classes
is part of the development wor#.
'he followin$ illustration shows a simple example of a class dia$ram.
.1..3. /tatic constraints
&dd to the class dia$rams constraints that $overn the attriutes and relationships. For example!
the items on an order must all come from the same restaurant. 'hese types of rules are important
for the desi$n of the product.
.1... Model consistenc*
5nsure that the model and scenarios are consistent. Cne of the most powerful uses for a model is
to resolve ami$uities.
'he scenario descriptions use the terms that are defined in the model and are consistent
with the relations that it defines. If the model defines menu items! the scenarios should
not refer to the same thin$ as products. If the class dia$ram shows that a menu item
Page 8 of 68
elon$s to exactly one menu! the scenarios should not tal# of sharin$ an item etween
menus.
5very scenario descries a series of steps that are allowed y the activity dia$rams.
Scenarios or activities descrie how each class and relationship in the class dia$ram is
created and destroyed. For example! what scenario creates a menu itemB 1hen is an
order destroyedB
.1.!. 'e&elo( =ualit* of /er&ice 0e7uire%ents
Create wor# items that specify quality of service requirements. Set the =equirement 'ype field to
Duality of Service.
Duality of service or non,functional requirements include performance! usaility! reliaility!
availaility! data inte$rity! security! affordaility! serviceaility and up$radeaility! deliveraility!
maintainaility! desi$n! and fit and finish.
Consider each of these cate$ories for each scenario.
'he title of each quality of service requirement should capture its definition y presentin$ a
context! an action! and a measurement. For example! you mi$ht create the followin$
requirement% 62urin$ a catalo$ search! return the search results in less than three seconds.9
In addition! it is useful to capture more detail that explains why the requirement is necessary.
2escrie why the persona would value the requirement and why this level of service is required.
8rovide context and -ustification. 'his explanation may include useful ris# mana$ement
information such as data from a mar#et survey! a customer focus $roup! or a usaility studyH help
des# reportsPtic#etsH or other anecdotal evidence.
+in# the quality of service requirement to any scenario (requirement wor# item) that is affected
y the quality of service. +in#in$ related wor# items allows users of 'eam Foundation Server to
#eep trac# of dependent requirements. Dueries and reports can show how quality of service
requirements affect the functional requirements that are captured as scenarios.
.1.6. 0e&ie, 0e7uire%ents
1hen the requirements have een written or updated! they should e reviewed y the appropriate
sta#eholders to ensure that they adequately descrie all user interactions with the product.
Common sta#eholders mi$ht include a su-ect matter expert! a usiness analyst! and a user
experience architect. 'he scenarios are also reviewed to ensure that they can e implemented in
the pro-ect without any confusion or prolems. If any prolems are spotted! the scenarios must
e fixed so that they are valid at the conclusion of this activity.
Page " of 68
Create a review wor# item to trac# the review. 'his item provides important evidence for a
Standard CMMI &ppraisal Method for 8rocess Improvement (SC&M8I) appraisal and may
provide a $ood source of information for root cause analysis in the future.
=eview each scenario for the followin$ characteristics%
'he scenario is written in the context of what tas# users must perform! what they already
#now! and how they expect to interact with the product.
'he scenario outlines a prolem and is not oscured y proposed solutions to the
prolem.
&ll relevant user interactions with the product are identified.
'he su-ect matter expert! the usiness analyst! and the user experience architect review
each scenario in the context of the pro-ect to validate that all scenarios can e
implemented successfully. If a scenario is not valid! it is revised so that it is valid.
'he scenario can e implemented with the availale techniques! tools! and resources and
within ud$et and schedule.
'he scenario has a sin$le interpretation that is easily understood.
'he scenario does not conflict with another scenario.
'he scenario is testale.
.1.7. <alidation
8lan to deploy eta versions of the product into its wor#in$ environment efore its final release.
8lan to update the requirements! ased on sta#eholder feedac# from that deployment.
:alidation means ensurin$ that the product fulfills its intended use in its operatin$ environment.
In MSF for CMMI! validation is achieved y demonstratin$ wor#in$ software to the sta#eholders
at the end of every iteration throu$hout the pro-ect. 'he schedule is arran$ed in such a way that
concerns that are fed ac# to the developers from early demonstrations can e dealt with in the
plan for the remainin$ iterations.
'o achieve true validation! the product must not only e run in a demonstration or simulated
context. &s far is as practicale! it should e tested in real conditions.
.1.8. Ins(ecting and 8diting t.e 0e7uire%ents
Page !0 of 68
'he scenario and quality of service requirements! which lead to most development tas#s! can e
inspected y usin$ the customer requirements query. If you prefer to display all requirements!
you can write a query that returns all wor# items of the requirement wor# item type. Set the
columns of the result to show the iteration path. For more information! see 'eam Dueries
(CMMI).
In addition to viewin$ the query directly in 'eam 5xplorer or 'eam 1e &ccess! you can open it
in Cffice 5xcel or Cffice 8ro-ect. 'hese tools are more convenient for editin$ and addin$ wor#
items as a atch. For more information! see 1or#in$ in Microsoft 5xcel and Microsoft 8ro-ect
Connected to 'eam Foundation Server and 8erformin$ 'op,2own 8lannin$ 0sin$ a 'ree +ist of
1or# Items (In 5xcel).
Your team should create most requirements in the early iterations of the pro-ect. Gew
requirements will e added and others ad-usted as feedac# is $ained from early versions.
.1.". -dditional 0esources
For more information! see the followin$ 1e resources%
& 8ractical 7uide to Feature 2riven 2evelopment! Stephen =. 8almer and Malcolm 3.
Felsin$H 8rentice,*all 8'=! <00<.
Streamlined C-ect Modelin$% 8atterns! =ules and Implementation! 3ill Gicola! Mar#
Mayfield! and Mi#e &neyH 8rentice *all 8'=! <00;.
&$ile Modelin$% 5ffective 8ractices for 5xtreme 8ro$rammin$ and the 0nified 8rocess!
Scott &mlerH 1iley! <00<.
2omain 2riven 2esi$n% 'ac#lin$ Complexity in the *eart of Software! 5ric 5vansH
&ddison 1esley 8rofessional! <00J.
C-ect 2esi$n% =oles! =esponsiilities and Collaorations! =eecca 1irfs,"roc# and
&lan McFeanH &ddison 1esley 8rofessional! <00<.
4.2. $rra")i") %e5uire!e"ts i"to a Produ&t Pla"
&fter you analy/e your customer requirements sufficiently to understand what the product should
do! you must wor# out a plan to implement the product. Cr! for an existin$ product! you must
wor# out what functionality is missin$ and wor# out a plan for ma#in$ the chan$es. "ut the
requirements do not automatically tell you the plan.
'his topic outlines a method of otainin$ a plan! startin$ from a set of requirements. 'his is -ust
one method amon$ a variety that will wor# on :isual Studio! and you should adapt it so that it
suits your needs.
Page !1 of 68
In this topic
.2.1. 0e7uire%ents and >eatures
'here are two #inds of requirement in this method% customer requirements and features.
Customer requirements are what you $et y analy/in$ what the customer wants from the
product. Features are items in the product plan! which correspond to small susets of the
customer requirements. 5ach feature may include pieces of the customer requirements that come
from different parts of the user experience and different functional areas.
Customer =equirements
Customer requirements are determined y discussion with the prospective users and other
sta#eholders.
'o help analy/e these requirements! you will typically create storyoards and models! and
you decompose the scenarios into smaller steps! formin$ a tree. You can lin# modelin$
elements such as use cases and activities to scenario wor# items.
'here are two #inds of customer requirement%
o Scenarios! also #nown as use cases! represent sequences of interactions etween
the users and product! in pursuit of specific $oals. &n example scenario mi$ht
have the title 60ser uys a oo#.6
o Duality of Service requirements include performance! security! usaility! and
other criteria.
You can represent these requirements as wor# items of type requirement! with the
=equirement 'ype field set to Scenario or Duality of Service.
'hese requirement wor# items should e lin#ed to system tests so that you can ensure
that all the requirements are tested.
0se the Customer =equirement query to list these requirement wor# items.
0se the =equirements 8ro$ress report to monitor which requirements have een satisfied.
For more information! see 2evelopin$ =equirements! 'eam Dueries (CMMI)! =equirements
8ro$ress =eport (CMMI)! and Creatin$ a 'est 8lan 0sin$ =equirements or 0ser Stories.
Features
Page !2 of 68
& feature is an item in a product plan that represents a $roup of tas#s. In product
plannin$! representatives of the development team and sta#eholders assi$n features to
iterations. For more information! see 8lannin$ the 8ro-ect (CMMI).
5nter features as requirement wor# items with the =equirements 'ype field set to Feature.
'he feature.s title states! in users. terms! what the users will e ale to do with the
product! that they could not do in previous iterations. 'here are no items! or very few
items! on the plan that do not deliver new user value.
For example! this sequence of features could form an implementation plan%
o 6& uyer can pic# a oo# from a list and add it to a wish list.6
o 6'he oo# list displays prices. In the wish list! the total price is displayed.6
o 6:endors can attach ta$s to oo#s. "uyers can filter the oo# list y ta$.6
Gotice that no feature touches -ust one step in the user experience! and no feature
involves -ust one part of the product architecture. Instead! as the features are
implemented! several functions are revisited and au$mented with new user value.
& feature is assi$ned to an iteration durin$ product plannin$. &ll the tas#s under a feature
must e assi$ned to the same iteration. For more information! see 8lannin$ the 8ro-ect
(CMMI).
& feature descries a partial reali/ation of the customer requirements. It is a suset of the
customer requirements! and it mi$ht implement each customer requirement to a limited
extent.
5very feature can e lin#ed to one or more test cases that test the part of the requirements
that the feature represents. 'hese test cases are a suset of the system tests that are lin#ed
to the customer requirements.
'he feature.s state must not e mar#ed complete until its tests are fully defined and pass.
5very feature is a $roup of development and test tas#s. It is the root of a tree of tas#s in
:isual Studio 'eam Foundation Server. 'he development tas#s implement the partial
requirements that the feature descries. 'he test tas#s desi$n and execute the appropriate
test cases.
You use the 8roduct =equirements query to list features. 'o display the product plan! you
clic# Column Cptions and add Iteration 8ath to the list of displayed columns. 'o sort y
iteration! you clic# the Iteration 8ath column. For more information! see 'eam Dueries
(CMMI).
Page !3 of 68
.2.1.1. >inding features
Separatin$ requirements into incremental features is a creative tas# that must involve developers!
analysts! and sta#eholders. & feature defines a piece of the product.s functionality that can
sensily e implemented separately from the surroundin$ functions. 'herefore! a wor#ale set of
feature definitions and an orderin$ into a plan depends partly on the architecture of the system.
For this reason! plannin$ and the initial desi$n of the product must wor# in parallel! particularly
in Iteration 0 where the ul# of the plan is ein$ s#etched.
.2.2. /cenario 'eco%(osition
'o help you arran$e the requirements into features! it helps to decompose the scenarios into
smaller steps.
Storyoards often help with this activity. & storyoard is a sequence of pictures that illustrate the
scenario. 0M+ activity dia$rams are useful for showin$ alternative paths! and 0M+ sequence
dia$rams can help you discuss interactions etween several actors. &fter you use these tools to
analy/e a scenario! you can enter the decomposed scenarios into 'eam 5xplorer. 'his lets you
lin# test cases to the scenarios and therey ensure that the requirements have een satisfied. For
more information! see 0M+ &ctivity 2ia$rams% 7uidelines and 0M+ Sequence 2ia$rams%
7uidelines.
In this short wal#throu$h! you enter a set of customer requirements in the form of a small tree of
scenarios. 'his will provide an example from which to create features.
.2.2.1. To o(en t.e custo%er re7uire%ents tree in 8?cel
;. In 'eam 5xplorer! open a MSF for CMMI 8rocess Inte$ration v5.0 pro-ect.
<. 5xpand 1or# Items! expand 'eam Dueries! expand 8lannin$ and 'rac#in$! and run
Customer =equirements.
J. If the Iteration 8ath and =equirements 'ype columns do not appear! clic# Column
Cptions! and add them to the display list.
You mi$ht also want to add the &rea 8ath column.
E. Set the query to show a tree.
;. Clic# 5dit Duery.
<. Set 'ype of Duery to 'ree of 1or# Items.
J. Clic# Save Duery.
Page ! of 68
If you cannot save the query in 'eam Dueries! save it in My Dueries.
E. Clic# :iew =esults to close the editin$ view.
5. Clic# Cpen in Microsoft Cffice! and then clic# Cpen Duery in Microsoft 5xcel.
I. In Cffice 5xcel! if the column headed 'itle ; is not followed y columns that are
headed 'itle < and 'itle J! clic# the 'eam ta! and then clic# &dd 'ree +evel to create the
additional columns.
You can now conveniently enter the scenarios as a atch.
In a real situation! you mi$ht start y enterin$ one level of scenarios and then decomposin$ each
scenario to smaller steps in separate operations.
.2.2.2. To enter t.e scenarios
;. In the row immediately after the ottom row of existin$ wor# items (if any)! enter the
title of the top,level scenario in the 'itle ; column%
Customer orders a meal.
<. In discussion with the usiness sta#eholders! you determine the principal steps that ma#e
up the top,level scenario.
In the rows that immediately follow the top,level scenario! enter the steps in the 'itle <
column%
Customer chooses a restaurant.
Customer chooses items from the restaurant.s menu! to create an order.
Customer enters payment details.
=estaurant prepares and delivers order.
Customer.s card is char$ed with the payment.
J. Further analysis! perhaps usin$ 0M+ activity dia$rams or interaction dia$rams! yields
more detailed steps for some of these scenarios.
Immediately under Customer chooses a restaurant! insert some rows! and enter these
steps in the 'itle J column%
Customer enters the delivery postal code.
1e site displays a list of restaurants that deliver to that address.
Page !! of 68
Customer can rowse menus of all displayed restaurants.
Customer selects one restaurant to start an order.
2elete any lan# rows.
E. In the 1or# Item 'ype column of all the new rows! set the type to =equirement.
5. Set the =equirements 'ype column of all the new rows to Scenario.
I. 'o pulish the requirements to 'eam Foundation Server! select any cell in the tale of
wor# items! and then clic# 8ulish on the 'eam ta.
You now have a tree of customer requirements! which you can edit further in Cffice 5xcel or
'eam 5xplorer.
.2.3. -ssign )eaf /cenarios to Iterations
'he 6leaf6 scenarios are those that have no children of their own.
&ssi$n the most asic steps in the scenarios to iterations y settin$ the iteration path field. You
can do this in the Cffice 5xcel view.
'hen assi$n each scenario that has children to the earliest iteration in which it can e considered
usale.
In the followin$ example! the most essential scenarios are implemented in iterations ; and <! and
other functions are added in later iterations.
Iteration < , Customer chooses a restaurant.
o Iteration 5 , Customer enters the postal code.
o Iteration < , 2innerGow displays a list of restaurants.
o Iteration J , Customer can rowse menu of each restaurant.
o Iteration < , Customer selects one restaurant to create an order.
Iteration ; , Customer chooses items from the menu! to create an order.
o Iteration ; , Customer clic#s menu item to add to order.
o Iteration < , Crder summary displays total price of order.
o Iteration ; , Customer clic#s 6Confirm6 to complete the order.
Page !6 of 68
Iteration E , Customer enters payment details.
Iteration < , =estaurant prepares and delivers the order.
Iteration E , Customer.s card is char$ed with the payment.
'hese assi$nments let you exercise the overall desi$n of the system at an early sta$e ut leave
many details until later. Some aspects that are considered low ris# can e left to later iterations.
In this example! the team has had previous experience of lin#in$ to a card payment system.
'herefore! it feels confident to leave that part to a later iteration.
In some cases! you will want to decompose the leaf scenarios further! to allow simplified and
more complex versions to e separated into different iterations! as the followin$ picture
illustrates.
.2.. >eatures 1 0e7uire%ents >ul3lled in eac. Iteration
& feature is a requirement that summari/es what the users can do at the completion of each
iteration. You can create more than one feature for each iteration. 5nter them as requirement
wor# items! settin$ the =equirement 'ype to Feature.
0se your assi$nments of scenarios to wor# items to help you define the features. 'he followin$
example feature plan is derived from the assi$nments of scenarios to iterations in the previous
section%
Iteration ;
o Customer chooses items from a menu! adds them to an order! and adds a delivery
address.
Iteration <
o Customers start y displayin$ a list of restaurants and then choose one.
Page !7 of 68
o 1hen the customer completes an order! the order appears on the chosen
restaurant.s screen.
o 'he prices of items and the total price are displayed on the order.
Iteration J
o =estaurant mar#s the order as 62one6 when the prepared meal has een
dispatched. 'he meal is lo$$ed a$ainst the restaurant.
o 5ach restaurant can enter and update its menu.
o Customer can rowse the menu of every restaurant efore selectin$ one.
Iteration E
o Customer enters payment details on completin$ an order. Customer.s card is
char$ed when the restaurant mar#s the order as 2one.
o =estaurant is paid for orders that are mar#ed as 2one.
Iteration 5
o =estaurants can set their delivery area. Customer enters postal code at start of
session. 'he 1e site displays only restaurants that can deliver to the local area.
.2..1. #artl* i%(le%ented scenarios
2ecomposin$ the scenarios into small steps helps you to separate some steps that can e
implemented earlier from others that can e implemented later.
"ut sometimes you can separate out other aspects of the scenarios. In this example! the team
mi$ht implement a asic version of the user experience in early iterations and then improve it
later. So you mi$ht add the followin$ feature%
Iteration I , =estaurant can choose the color scheme and font of its menu and upload its
own lo$o and pictures of meals.
'his type of feature does not emer$e directly from the decomposition into steps! ut it usually
emer$es in discussion of storyoards. 0ser experience features are $ood candidates for later
iterations.
Page !8 of 68
.2.!. 8ntering and ins(ecting features
Create wor# items with wor# item type of requirement! and set the =equirement 'ype field to
Feature. Set the feature title to the short description.
'o enter the features in a atch and to discuss their assi$nment to iterations! adapt the 8roduct
=equirement query! and use an Cffice 5xcel view.
.2.6. To enter and edit features
;. In 'eam 5xplorer! open an MSF for CMMI 8rocess Improvement v5.0 pro-ect.
<. 5xpand 1or# Items! expand 'eam Dueries! expand 8lannin$ and 'rac#in$! and open
8roduct =equirements.
J. Clic# Column Cptions! and add Cri$inal 5stimate and Iteration 8ath to the list of
displayed columns.
E. Clic# Cpen in Microsoft Cffice! and then clic# Cpen Duery in Microsoft 5xcel.
5. In the dialo$ ox that as#s whether you want to save the query! clic# Yes.
I. (Cptional) In Cffice 5xcel! enter the list of feature titles! set iteration paths! and order the
rows y iteration path.
@. 'o save chan$es to 'eam Foundation Server! clic# any cell in the wor# item tale! and
then clic# 8ulish on the 'eam ta.
.2.6.1. Tracing features to re7uire%ents
You can lin# features to requirements in the followin$ ways%
+in# feature wor# items to the leaf scenario requirements of their iterations. You must
lin# them y usin$ =elated Item lin#s ecause the leaf scenarios already have parents.
+in# test case wor# items to the scenarios and quality of service requirements that they
test. +in# features to the suset of test cases that should pass when the feature has een
developed. In this manner! the test cases act as the lin# etween features and customer
requirements.
.2.7. =ualit* of /er&ice >eatures
Duality of service requirements are usually pervasive with re$ard to the software desi$n. For
example! security requirements are $enerally not related to a particular development tas#.
Page !" of 68
Gevertheless! for each quality of service requirement! you should create a feature wor# item
whose children are mainly testin$ tas#s that ensure that a quality of service criterion is met.
'hese wor# items are called quality of service features.
Some quality of service features can have development tas#s. For example! in an early iteration!
you mi$ht implement a version of the system that can handle only a few users! as a proof of
concept. For a later iteration! you mi$ht add a feature that specifies the tar$et capacity as stated
in the customer requirements.
.2.8. #roduct (lanning
"efore the start of every iteration! hold a meetin$ to review the product plan. 'he first product
plannin$ meetin$ creates the plan! and susequent meetin$s review it ased on earlier iterations.
For more information! see 8lannin$ the 8ro-ect (CMMI).
In a product plan review! discuss the features with usiness sta#eholders! and e prepared to
reprioriti/e them and arran$e them into different iterations. 'he meetin$ should include usiness
sta#eholders and representatives of the development team.
'he meetin$ discusses the sequence in which features will e developed. 'his can e done y
pro-ectin$ or screen,sharin$ the Cffice 5xcel view of the 8roduct =equirements query and
orderin$ the features y iteration.
&n alternative technique is to place the features in a specific sequence and then consider how
much can e done in each iteration. For example! the developers mi$ht discuss whether
6Customer can display the prices6 should e moved from Iteration < to Iteration J! without
movin$ it in the sequence. 'o place the items in a sequence! add an extra column that is named
=an# to the spreadsheet! and insert inte$ers that denote the sequence. Crder the spreadsheet y
this column. 'he ran#s will not e stored in 'eam Foundation Server! ut you can save the
spreadsheet. 1hen you open the spreadsheet a$ain! clic# any cell in the wor# item tale! and
then clic# =efresh on the 'eam ta.
8roduct plannin$ considers the priorities of the features and the development costs. 8riorities
come from the usiness sta#eholders! with some $uidance aout ris# from the developers. Cost
estimates come from the developers. 'o $et an accurate idea of the costs! the development team
must have already done some wor# on the architecture of the product and mi$ht need some
experience from the early iterations. For this reason! the cost estimates should e refined at every
product plan review.
.2.". Iteration (lanning
Page 60 of 68
&fter the product plan review! plan the iteration. 'he product plan determines the features that
will e delivered y the end of the iteration. 'he iteration plan determines what wor# the team
will do to implement and test the features.
'he followin$ activities are part of iteration plannin$%
Create tas#s for development and testin$! and lin# them as children to the feature
requirements.
Create test cases for the aspects of the customer requirements that are to e developed in
each feature. 'he test cases should e lin#ed to the customer requirements so that you can
monitor how complete the requirements are.
You can also lin# test cases to the features so that you can trac# the correspondence etween
features and requirements. 'he feature should not e mar#ed complete until the lin#ed test cases
pass.
For more information! see 8lannin$ an Iteration (CMMI).
4.3. Creati") a Solutio" $r&hite&ture
8art of creatin$ a $ood architecture is investi$atin$ alternative architectural strate$ies.
&lternative strate$ies have different enefits that are ased on platform selection! technolo$ies
that are used! and code reuse. 5ach strate$y is desi$ned and proofs of concept are uilt to further
investi$ate the costs and enefits of each strate$y. 'he strate$ies are assessed a$ainst product and
quality requirements! and ultimately a strate$y is chosen to e used to implement the product.
Finally! security and performance are architectural concerns for which wor# must e done over
the entire product.
.3.1. Create -lternati&e -rc.itecture #artitioning 'esigns
'he prolem is analy/ed! and different approaches are considered. & $roup of requirements are
selected that represent #ey usiness and technolo$ical challen$es. 5xamine the characteristics of
these challen$es! such as inte$ration of le$acy systems! and predict future needs ased on current
needs! reusaility of code! and maintenance costs.
.3.1.1. Create an -((lication 'iagra%
0sin$ the domain model and requirements as input! create an application dia$ram that represents
the core lo$ical elements of the system. 'his will later e partitioned into system dia$rams.
&lternative partitionin$ schemes will e considered and evaluated.
Cne way to represent an application dia$ram is as a 0nified Modelin$ +an$ua$e (0M+) use case
dia$ram. 'his type of dia$ram can show the ma-or susystems and their dependencies. In
Page 61 of 68
addition! you can place use cases in each susystem to show which susystem mana$es each user
scenario.
.3.1.2. 8stablis. 8&aluation Criteria
2etermine which criteria to use to identify requirements and scenarios that represent si$nificant
architectural challen$es. Consult the existin$ enterprise architecture documents for criteria.
=eview any usiness requirements! technical requirements! and enterprise standards that must e
applied to new applications. Capture additional criteria that are #nown to e architecturally
si$nificant! such as inte$ration with le$acy systems! reusaility of code! reusin$ existin$ vendor
liraries and platforms! and controllin$ maintenance costs. Capture additional criteria that
represent ris#s and cost when implementin$ a technical solution.
.3.1.3. /elect a Candidate 6rou( of 0e7uire%ents
5valuate each quality of service requirement and product requirement a$ainst the evaluation
criteria. If a requirement represents an architectural challen$e! consider it a candidate for
modelin$. For example! a requirement that the new product must support older customer
dataases meets the criteria of inte$ratin$ with le$acy systems. Such a requirement is a candidate
for modelin$ how the inte$ration would wor#.
.3.1.. /elect a Candidate 6rou( of /cenarios
5valuate each scenario a$ainst the evaluation criteria. If a scenario represents an architectural
challen$e! consider it a candidate for modelin$. For example! a scenario in which the user
downloads a client update meets the criteria that concerns maintenance costs. Such a scenario is
a candidate for modelin$ how est to handle client updates.
.3.1.!. 0educe t.e Candidate 6rou(
=eview the candidate scenarios and requirements. =emove scenarios and requirements that
duplicate the evaluation criteria or are etter represented y other scenarios and requirements.
'rim the candidate $roup to a core $roup that represents the #ey architectural challen$es! ris#s!
and costs of the new application. Feep the scenarios and requirements that est represent the
evaluation criteria! that present the most ris#! and that present the most potential cost when
architectin$ a technical solution. Feep the scenarios and the requirements that are the most
comprehensive or #ey parts of the application.
.3.1.6. Create #artitioning Criteria
0sin$ the requirements as motivation! analy/e estalished architectural patterns (such as faQade
or model,view,controller)! and identify potential candidates for implementation. Identify
candidate patterns throu$h their motivation! and consider their desi$n tradeoffs with re$ard to
Page 62 of 68
couplin$! cohesion! extensiility! adaptaility! and flexiility. Select a set of candidates for
implementation as alternatives for assessment.
.3.2. 'esign /*ste% -rc.itecture and 'e(lo*%ent
'he system architecture defines the $roupin$s and confi$urations of elements that are identified
in the application dia$ram. System dia$rams are created that capture the system architecture for
each possile architecture approach. 2eployment dia$rams show the deployment steps that are
ased on dependencies and core functionality. &n infrastructure architect creates a lo$ical
datacenter dia$ram that descries the lo$ical structure of the datacenter where the application
will e deployed. 'he deployment dia$rams are validated a$ainst the lo$ical datacenter dia$ram
to ensure that the systems can e deployed.
.3.2.1. Create a /*ste% Model
'he architect and the lead developer create system dia$rams from the application dia$ram.
'hrou$h system dia$rams! you can desi$n reusale application systems as units of deployment
y composin$ them from elements on the application dia$ram. You can also desi$n lar$er and
more complex systems that contain other systems so that you can use them in distriuted system
scenarios and astract the details of applications in those systems. Chec# in each new dia$ram
file to version control.
You can represent system dia$rams in :isual Studio in the followin$ ways%
0se case dia$rams. 'he main user scenarios are represented as use cases! and the ma-or
components of the system are shown as susystems. 5ach use case can e placed inside
the susystem that deals with it. For more information! see 0M+ 0se Case 2ia$rams%
7uidelines.
0M+ component dia$rams. 'hese dia$rams let you show communications channels
etween the components! in addition to dependencies. You mi$ht also want to create class
dia$rams to descrie the types that are visile at the interfaces to the components! and
you can create sequence dia$rams to show their interactions. For more information! see
0M+ Component 2ia$rams% 7uidelines! 0M+ Class 2ia$rams% 7uidelines! and 0M+
Sequence 2ia$rams% 7uidelines.
+ayer dia$rams. & layer dia$ram descries the loc# structure of the application. It shows
only components and the dependencies etween them. It has the enefit that! after the
code is written! you can validate the code and the dependencies a$ainst the dia$ram. For
more information! see +ayer 2ia$rams% 7uidelines.
For each susystem! you can create a pac#a$e that descries its types and ehavior in more
detail. For more information! see 2efinin$ 8ac#a$es and Gamespaces.
Page 63 of 68
.3.3. Create #roofs of Conce(t
Si$nificant ris#s to the pro-ect can e miti$ated y creatin$ an architectural proof of concept. It is
important to address ris# as early as possile in the pro-ect so that #ey strate$ic and architectural
decisions can e made while it is still easy to modify fundamental pieces of the architecture.
Creatin$ early proofs of concept reduces overall pro-ect ris# and un#nowns. +ower pro-ect ris#
and fewer un#nowns ma#e plannin$ and estimatin$ in later iterations more accurate. 8roofs of
concept can e temporary and discarded after the issues have een addressed! or they can e uilt
as the foundation of the core architecture.
.3.3.1. 8?a%ine 0isk
0nderstand the elements that lead to the identification of the ris# or architectural decisions.
5xamine related scenarios and quality of service requirements. Chec# for any tar$et environment
implications.
.3.3.2. #lan t.e -((roac.
2etermine the form of the proof of concept that is needed. 0se the application and system
dia$rams to help plan. Solve only the architectural prolem that is identified y the ris#. +oo# for
the simplest resolution.
.3.3.3. Build and 0un t.e #roof of Conce(ts
"uild the proof of concept. You can implement the proof of concept from the application
dia$ram. Maintain focus on the prolem to e solved. 2eploy the proof of concept to a physical
environment that is con$ruent to the lo$ical datacenter dia$ram. 'he physical environment
should match the settin$s of the lo$ical datacenter dia$ram as closely as possile. 'est the proof
of concept a$ainst the hi$h,ris# issues.
.3.. -ssess -lternati&es
'he +i$htwei$ht &rchitecture &lternative &nalysis Method (+&&&M) is used to help decide
etween different architectural strate$ies for uildin$ an application. 'he +&&&M typically
ta#es one day to complete. Start y uildin$ a utility tree that descries #ey quality and
functional drivers of the application that are ased on requirements. 5ach driver is written as a
scenario that ta#es the form of a statement that is written as context! stimulus! and response. 0se
an assessment matrix to evaluate how well each strate$y addresses each scenario.
Page 6 of 68
.3..1. Create a @tilit* Tree
5xamine quality of service requirements and product requirements to determine the #ey drivers
of quality and function in the application. Construct a utility tree that represents the overall
quality of the application. 'he root node in the tree is laeled 0tility. Susequent nodes are
typically laeled in standard quality terms such as modifiaility! availaility! and security. 'he
tree should represent the hierarchical nature of the qualities and provide a asis for prioriti/ation.
5ach level in the tree is a further refinement of the qualities. 0ltimately! these qualities ecome
scenarios.
.3..2. Construct an -ssess%ent Matri?
For each leaf in the utility tree! write a scenario. 'he scenario is in the form of context! stimulus!
and response (for example! 60nder typical operation! perform a dataase transaction in fewer
than ;00 milliseconds6).
Create a spreadsheet or a tale! and enter each scenario as a row in this assessment matrix. 5nter
each architectural strate$y as a column. &t each intersection of strate$ies and scenarios! enter a
ratin$ on a scale etween ; and E.
'he ratin$ should ta#e into account the followin$ factors%
2evelopment cost Is this solution easy or difficult to implementB 1hat is its impact on
other areasB
Cperational cost &t run time! will this solution wor# easily! or will it adversely affect
usaility! performance! and so onB
=is# Is this solution certain to address the scenario well! or are there un#nown costsB
Could this solution have an adverse impact on the team.s aility to accommodate future
enhancements in the requirementsB
If a proof of concept has een uilt for a strate$y! use information from that proof of concept to
help determine the values.
&t the ottom of the tale! sum the values from the scenarios. 0se these fi$ures as an input to the
discussion that leads to decisions on the alternative architectures.
0pload the completed assessment matrix to the pro-ect portal.
.3.!. /elect t.e -rc.itecture
&fter the assessment matrix is created! a review meetin$ is held to determine which architecture
to use in the next iteration. 'he assessment matrix and information that is discovered from
creatin$ the proofs of concept is used to help ma#e a decision. &fter the architecture is selected!
Page 6! of 68
dia$rams for the architecture are chec#ed in as the reference solution! and a -ustification
document is created that captures the reasons ehind the selection.
.3.!.1. #re(are for 0e&ie,
'he architect and the lead developer identify the appropriate reviewers for reviewin$ the
proposed architectures and circulate documentation for the architectures to each participant.
.3.!.2. 0e&ie, /*ste% -rc.itecture and 'e(lo*%ent
-rc.itecture
2urin$ the review meetin$! the system dia$rams! the deployment report! and the lo$ical
datacenter dia$ram are reviewed. 'he $oal is to choose an architecture to implement in the next
iteration.
Consider the assessment matrix ran#in$s for each architecture to help evaluate the suitaility of
each architecture. Consider any information that is discovered from the proofs of concept such as
cost or complexity that is involved with implementin$ the different architectures. If the lo$ical
datacenter dia$ram represents an existin$ datacenter that cannot e modified! do not review it. If
a datacenter is ein$ created! review the dia$ram for deployment considerations. Select the
architecture to e used. =eview the architectural concept a$ainst the scenarios to validate that the
solution meets the customer needs and is complete.
.3.!.3. Create a 0eference /olution
Create a -ustification document that captures the decisions of the meetin$. 0pload it to the
pro-ect portal. For the selected architecture! chec# in any application! system! or lo$ical
datacenter dia$rams as the reference solution to use for implementin$ features in the next
iteration. Communicate to the entire team and any dependent teams the decision on what
architecture is selected for the next iteration.
.3.6. 'e&elo( a #erfor%ance Model
8erformance modelin$ is used to identify and address potential performance issues in the
application. & performance model is developed from a quality of service requirement! which is
then ro#en into development tas#s. 5ach development tas# is assi$ned a performance ud$et for
implementation.
Identify the scenarios that are lin#ed to the performance quality of service requirement. Map the
development tas#s to the scenarios. From the quality of service requirements list! determine the
wor#load for the application. 0sin$ the wor#load estimates and the quality of service
requirements list! identify the performance o-ectives for each #ey scenario. 'hese include
o-ectives such as response time! throu$hput! and resource use. Identify the performance,related
Page 66 of 68
resources that have een ud$eted to meet the performance o-ectives. Some examples of
performance,related resources are execution time and networ# andwidth. 2etermine the
maximum allowale allocation of each resource.
Spread the ud$eted resources across the processin$ steps for each scenario. 1hen not sure of
how to allocate the ud$et! ma#e est $uesses! or divide the resources evenly amon$ the steps.
"ud$etin$ is refined durin$ validation. &ttach or write the allocation on the appropriate
development tas#.
Find ud$et allocations that pose a ris# to meetin$ performance o-ectives. Consider tradeoffs
that help meet performance o-ectives such as desi$n and deployment alternatives. =eevaluate
quality of service requirements if necessary.
Identify the scenarios that do not meet ud$et allocations. Measure the performance of the
scenarios. 0se prototypin$ in early iterations if code is not availale. =epeat the ud$etin$!
evaluation! and validation steps as necessary y usin$ data that is acquired durin$ validation.
.3.7. 'e&elo( a T.reat Model
For more information! see the followin$ pa$e on the Microsoft 1e site% Security 2eveloper
Center.
4.4. Building a Product
4.#. +erifyi") %e5uire!e"ts
4.1. Wor,i") With Bu)s
!. -rtifacts
Page 67 of 68