THE CAPABILITY MATURITY MODEL

INTEGRATION (CMMI):

 Capability Maturity Model Integration (CMMI) is a process

improvement approach that helps organizations improves their
performance.
 The CMMI represents a process meta-model in two different
ways:
 As a continuous model
 As a staged model.
 Each process area is formally assessed against specific goals and
practices and is rated according to the capability levels.
 THE CAPABILITY MATURITY
WHYMODEL
WE CHOSE
INTEGRATION (CMMI): CMM

 CMM today serves as a “seal of approval” in software development

 CMM helped guide us towards standard, repeatable processes
reduced learning time on how to get things done
 Standard practices mean time savings to our team - everyone knows
what to expect and what to deliver.
 Our quality activities became more aligned within the project rather
than thought of as a separate event.
 We rely on our processes and our people together, not just one or
the other
 Ideas in CMMI creates an environment of improvement – if you
don’t like things one way, make it better!
 THE CAPABILITY MATURITY MODEL
INTEGRATION (CMMI):
 Level 0: Incomplete. The process area is either not performed or
does not achieve all goals and objectives defined by CMMI for
level 1 capability.
 Level 1: Performed. All of the specific goals of the process area
have been satisfied. Work tasks required to produce defined work
products are being conducted.
 Level 2: Managed. All level 1 criteria have been satisfied. In
addition, all work process area conforms to an defined policy;
all people doing the work have access to adequate resources to
get the job done; stakeholders are actively involved; all work
tasks and work products are “monitored, controlled, and reviewed;
 THE CAPABILITY MATURITY MODEL
INTEGRATION (CMMI):

 Level 3: Defined. All level 2 criteria have been achieved. In addition, the process
is “tailored from the organizations set of standard processes according to the
organizations tailoring guidelines, and contributes and work products, measures
and other process-improvement information to the organizational process assets”.
Level 4: Quantitatively managed. All level 3 criteria have been achieved. In
addition, the process area is controlled and improved using measurement and
quantitative assessment.” Quantitative objectives for quality and process
performance are established and used as criteria in managing the process”
Level 5: Optimized. All level 4 criteria have been achieved. In addition, the
process area is adapted and optimized using quantitative means to meet changing
customer needs and to continually improve the efficacy of the process area under
consideration”
PERSONAL AND TEAM PROCESS MODELS

 The best software process is one that is close to the people

who will be doing the work.
 Each software engineer would create a process that best
fits his or her needs, and at the same time meets the
broader needs of the team and the organization.
 Alternatively, the team itself would create its own process,
and at the same time meet the narrower needs of individuals
and the broader needs of the organization.
 PERSONAL AND TEAM PROCESS MODELS

 The quality of a software system is determined by the quality

of its worst components.
 The quality of a software component is governed by the
individual who developed it.
 The quality of a software component is governed by the quality
of the process used to develop it.
 The key to quality is the individual developer’s skill,
commitment, and personal process discipline.
 PERSONAL AND TEAM PROCESS MODELS

 As a software professional, you are responsible for

your personal process.
 You should measure, track, and analyze your work.
 You should learn from your performance variations.
 You should incorporate lessons learned into your
personal practices.
PERSONAL SOFTWARE PROCESS (PSP)

 The personal software process (PSP) emphasizes personal

measurement of both the work product that is produced and
the resultant quality of the work product.
 The PSP process model defines five framework activities:
 planning,
 high-level design,
 high level design review,
 Development and
 postmortem.
 PERSONAL SOFTWARE PROCESS (PSP)
 Planning: This activity isolates requirements and, base on
these develops both size and resource estimates.
In addition, a defect estimate is made. All metrics are recorded
on worksheets or templates. Finally, development tasks are
identified and a project schedule is created.
 High level design: External specifications for each component
to be constructed are developed and a component design is
created. Prototypes are built when uncertainty exists. All issues
are recorded and tracked.
 High level design review: Formal verification methods are
applied to uncover errors in the design. Metrics are maintained
for all important tasks and work results.
 PERSONAL SOFTWARE PROCESS (PSP)

 Development: The component level design is refined and reviewed.

Code is generated, reviewed, compiled, and tested. Metrics are
maintained for all important task and work results.
 Postmortem: Using the measures and metrics collected the
effectiveness of the process is determined. Measures and metrics
should provide guidance for modifying the process to improve its
effectiveness.
 PSP stresses the software engineer to identify errors early and, as
important, to understand the types of errors that he is likely to make.
 PSP represents a disciplined, metrics-based approach to software engineering.
 TEAM SOFTWARE PROCESS (TSP)
 The goal of TSP is to build a “self-directed project team” to produce
high-quality software.
 The following are the objectives for TSP:
 Build self-directed teams that plan and track their work,
establish goals, and own their processes and plans. These can be
pure software teams or integrated product teams(IPT) of 3 to about
20 engineers.
 Show managers how to coach and motivate their teams and how
to help them sustain peak performance.
 Accelerate software process
 Provide improvement guidance to high-maturity organizations.
 TEAM SOFTWARE PROCESS (TSP)

 A self-directed team defines

- roles and responsibilities for each team member
- tracks quantitative project data
- identifies a team process appropriate for project
- a strategy for implementing the process
- defines local standards that are applicable to the teams
software engineering work;
- continually assesses risk and reacts to it
- Tracks, manages, and reports project status.
 TEAM SOFTWARE PROCESS (TSP)
 TSP defines the following framework activities:
 Project launch,
 high-level design,
 implementation,
 integration and test,
 and postmortem.
 TSP makes use of a wide variety of scripts, forms, and standards
that serve to guide team members in their work.
 Scripts define specific process activities and other more detailed
work functions that are part of the team process.
 TEAM SOFTWARE PROCESS (TSP)

 Each project is “launched” using a sequence of tasks.

 The following launch script is recommended
 Review project objectives with management and agree on and
document team goals.
 Establish team roles
 Define the teams development process
 Make a quality plan and set quality targets
 Plan for the needed support facilities