RRC CMM CMMI

Software Engineering Process
Disciplined, Modern, and Mature
An Overview Workshop for the Railroad
Commission of Texas
January 21 & 22, 2003

Greetings and Welcome!Greetings and Welcome!
Greetings and Welcome to this
Overview Workshop
I would like to thank Melynda Caudle,
Solutions Manager for the Oil and Gas
Migration Project, for this opportunity to
visit with you over the next couple of days!

Overview Workshop
I would also like to thank you for taking the
time out of your busy schedule to attend this
overview workshop. Please know that your
active participation over the next two days
will be a critical success factor!

Overview Workshop
Before we get going, I would like to take a few
moments to introduce myself. Following this
introduction, I would like to take a few more
moments to get to know each of you a bit
better than I do right now.

In particular, I would like to know:
• Your role at the Railroad Commission
• Your background and experience
• What knowledge or understanding you would
like to take with you at the conclusion of this
Overview Workshop

Why An OverviewWhy An Overview
Workshop?Workshop?
You might have wondered why I called this session
an Overview Workshop? I did so for the following
reasons:
• Over the next two days, a lot of new information
will be introduced and discussed
• When being introduced to new information, an
overview is initially the best approach because it
facilitates achieving an overall understanding of
how the individual parts (e.g., use cases) relate to
the whole (i.e., software engineering process)

Why An OverviewWhy An Overview
Workshop?Workshop?
You might have wondered why I called this session
an Overview Workshop? I did so for the following
reasons:
• A workshop approach will be followed because it
is important that we collaborate and work
together as a team during this time together
• We must share information, experience, and
knowledge with each other in a trusting manner
• From this experience, we will grow together as
software engineering professionals

An Orville RedenbacherAn Orville Redenbacher
ApproachApproach
During this overview workshop, we will follow an
Orville Redenbacher Approach:
• Two full days have been allocated for this
overview workshop and many topics will be
covered
• For each topic that we will discuss, think of it as
a bag of Orville Redenbacher popcorn
• That is, we will put the popcorn in the
microwave and set the timer for five minutes

An Orville RedenbacherAn Orville Redenbacher
ApproachApproach
During this overview workshop, we will follow an
Orville Redenbacher Approach:
• Even though we have set the timer for five
minutes, we will listen carefully to the popping of
the corn
• When the popping is finished, we will pull the
popcorn out of the microwave least it burns and
is ruined

Next StepsNext Steps
To be successful, what are your next steps following
the conclusion of this overview workshop?
• Access to Formal Training
 Rational University
 Rational Training Center in Plano, TX
• Access to Mentoring
 Process Engineering
 Project Management
 Software Engineering

Next StepsNext Steps
To be successful, what are your next steps following
the conclusion of this overview workshop?
• Access to Experienced Staff
 Process Engineers
 Project Managers
 Software Engineers
• Access to Supporting Tools Including:
 Rational Unified Process
 RequisitePro
 Rational Rose

Overview WorkshopOverview Workshop
AgendaAgenda
Over the next two days, an overview of the following
material will be provided:
• Capability Maturity Model
• Rational Unified Process
• Use Case Centric Process
 Managing Software Requirements
 Use Case Modeling
 Object-Oriented Analysis and Design
 Testing – Use Case Scenarios and Test Cases

ScheduleSchedule
• January 21st
 Capability Maturity Model
 Rational Unified Process
• January 22nd
 A Use Case Centric Process
 Managing Software Requirements
 Use Case Modeling
 Object-Oriented Analysis and Design
 Testing – Use Case Scenarios and Test
Cases

ScheduleSchedule
• 9 am until Noon
 Discussion and Exercises
 Break 10:30 am (or as appropriate)
• Noon until 1:00 pm
 Lunch
• 1 pm until 4:30 pm
 Discussion and Exercises
 Break 3:00 pm (or as appropriate)

Capability Maturity ModelCapability Maturity Model
Background and History
• In cooperation with major corporations and
research centers, Congress founded the Software
Engineering Institute (SEI) in 1984
• This non-profit, federally funded organization
was located at the Carnegie-Mellon University in
Pittsburg
• SEI was created as a research body to help
improve the practice of software engineering

• At its founding, its goal was to assist American
software professionals maintain a competitive
edge in the field of software development
• To accomplish this goal, SEI embarked on a
strategy to bring an engineering discipline to the
software development profession
• One of the early results this initiative was the
Capability Maturity Model (CMM)

• The United States Department of Defense (DoD)
commissioned the original CMM
• With escalating costs and schedule overruns,
DoD projects were fairing no better than
commercial software projects at that time
• As a result, the DoD wanted a way to
independently assess the software engineering
capabilities of its consultants and suppliers

• The body of knowledge that came be known as
the CMM can be traced to the work of Watts S.
Humphrey who published Managing the
Software Process in 1989
• Mark Paulk of SEI, assisted by a team of
engineers and researches, refined this work and
published The Capability Maturity Model:
Guidelines for Improving the Software Process in
1994

Continuous Process Improvement
• CMM is not a proprietary process that must be
rigidly and unquestionably implemented
• Rather, it provides a broad framework that
enables an organization to establish a mature
software management process
• At its most fundamental, CMM is concerned
with continuous process improvement

• This approach can best be described as a spiral
of planning, implementing, and evaluating, with
the evaluation leading to process improvements
• This approach is continuous in that this spiral
continues until an organization establishes a
proven, optimized software management process
• From the perspective of SEI, that’s process
maturity

• At its most fundamental, CMM is concerned
with continuous process improvement
• This approach can best be described as a spiral
of planning, implementing, and evaluating, with
the evaluation leading to process improvements
• This approach is continuous in that this spiral
continues until an organization establishes a
proven, optimized software management process

Five Maturity Levels
• CMM’s focus is to assist software development
agencies mature their management processes
• In the context of CMM, maturity means an
environment in which predictability is high and
risk is low
• As you will see in the material presented later
today, risk mitigation is also central to the
Rational Unified Process (RUP)

• CMM is structured as a five-scale tier
• An organization is considered fully mature when it
has in place practices, policies, and disciplines that
enables it to produce quality software in a
predictable, reliable, and repeatable manner
• As you will see in the material presented later
today, the RUP provides a disciplined approach to
assigning tasks and responsibilities within in
software development organization

• CMM’s five levels of process maturity are:
 Initial
 Repeatable
 Defined
 Managed
 Optimized
• First, CMM sets general goals at each level and
then defines how the organization should operate
by defining a series of Key Process Areas (KPA)

The Initial Level
• Level 1 organizations lack a set of sound
management practices for developing and
maintaining software
• As such, Level 1 organizations tend to be ad hoc
and reaction-driven
• Success under these circumstances depends
entirely upon the skills and heroics of individuals
team members

The Initial Level
• In such an environment, very little learning occurs
because the factors that lead to a project success
are undocumented
• As a result, the success factors are not repeatable
or shareable across projects
• SEI estimates that in the industry as a whole,
between 75 to 85 percent of all software
development organizations would assess at Level 1

The Repeatable Level
• In many ways, maturing from Level 1 to Level 2 is
the hardest step to take in CMM
• At Level 2, software management processes are
implemented and continuously reviewed and
refined
• From the perspective of software process
management, Level 2 organizations become “self
aware” and from this awareness are able to learn
and improve

• Level 2, however, is very distinctly a project-
focused tier
• That is, the way in which a project is planned and
managed is influenced by experienced gained from
similar projects and, thus, it is repeatable
• Similarly, project commitments are based upon
the successes of previous projects while being
adapted to the requirements of the current project

• Level 2 organizations, however, operate with a set
of basic software management controls in place
• These controls bound the planning effort
• Quality assurance practices also begin to monitor
compliance with these basic management controls
• As a result, these controls shape the project
management approach used by individual project
managers

The Repeatable Level - Key Process Areas
• The key process areas for Level 2 focus on
managing the software project by establishing a
basic set of project management controls:
 Requirements Management
 Software Project Planning
 Software Project Tracking and Oversight
 Software Quality Assurance
 Software Configuration Management
 Subcontractor Management

The Repeatable Level - SEI Estimates
• SEI estimates that in the industry as a whole, 5 to
10 percent of all software development
organizations would probably assess at Level 2

The Defined Level
• Once an organization has reached Level 2 and
over time, a refined set of key software
management process will have emerged
• Moving from Level 2 to Level 3 then is not so
much focused on adopting new processes as it is
with the movement from a project-level focus to
an organization-level focus
• That is, the key software management processes
are documented and utilized by the organization

The Defined Level
• As a result and whenever a new project is begins,
the organization’s documented processes for
planning and developing software are used
• Tailoring of these processes, however, is allowed in
order to take into account the unique
characteristics of a given software project
• In addition to management, this set of documented
processes includes software engineering processes
and this is where RUP complements CMM

The Defined Level
• At Level 3, two new groups appear within the
organization:
 Training
 Software Engineering Process Group (SEPG)
• An organization-wide training program is
implemented to provide staff and managers with
the skills and knowledge required to be successful
• The SEPG manages the evolution of the defined
organization-wide processes

The Defined Level
• The two chief qualities of the software process at
this level are standardization and consistency
• Software management and engineering have
become stable and repeatable
• This stability is based upon an organization-wide
understanding of the activities, roles, and
responsibilities in the defined software process,
which is a particular focus of the RUP

The Defined Level - Key Process Areas
establishing effective software management and
engineering processes across all projects:
 Organizational Process Focus
 Organizational Process Definition
 Process Training Program
 Integrated Software Management
 Software Product Engineering
 Intergroup Coordination

The Defined Level - Key Process Areas
establishing effective software management and
engineering processes across all projects:
 Peer Reviews

The Defined Level – SEI Estimates
• SEI estimates that in the industry as a whole, only
3 to 7 percent of all software development

The Managed Level
• With Level 2 focused on process experimentation
and Level 3 focused process definition, Level 4 is
focused on process measurement
• That is, moving from Level 3 to Level 4 is
concerned with measuring the effectiveness of the
defined process with a goal of continuous process
improvement
• To accomplish this, the organization establishes
quantitative quality goals

The Managed Level
• These quantitative quality goals apply to the
software products, as well as the managerial and
software engineering processes
• Level 4 is the ‘managed’ stage because nearly
every aspect of the software product and process is
being actively managed
• Metrics are collected, organized, and stored in a
organization-wide software process database for
analysis

The Managed Level - Key Process Areas
establishing a quantitative understanding of the
software process and products created by the
organization:
 Quantitative Process Management
 Software Quality Management

The Managed Level – SEI Estimates
• SEI estimates that in the industry as a whole, only
2 to 3 percent of all software development

The Optimizing Level
• The transition from Level 4 to Level 5 is a
transition in which the entire organization now
becomes focused on continuous process
improvement
• This level is characterized by an ongoing,
continuous state of operation where the major
goal becomes the prevention of defects
• The organization as a whole consistently strives to
improve the range of its process ability

The Optimizing Level - Key Process Areas
implementing continuous and measurable
software process improvement:
 Defect Prevention
 Technology Change Management
 Process Change Management

1. Initial
2. Repeatable
3. Defined
4. Managed
5. Optimized
• Project-Level Focus
• Basic Set of Software Project
Management Controls
• Organization-Level Focus
• Institutionalized Software Management
and Engineering Processes
Quantitative Understanding of the
Software Processes and Products
Continuous Process Improvement and
Defect Prevention

From CMM to CMMIFrom CMM to CMMI
Capability Maturity Model IntegrationCapability Maturity Model Integration Version 1.1
• Over the past two decades, the CMM for Software
(SW-CMM) has been the predominant tool for
assessing and assisting an organization’s processes
improvement efforts
• In fact, its success led to the creation of models to
support a variety of other disciplines including:
 Systems Engineering CM
 Software Acquisition CMM
 Integrated Product Development CMM

• While each of these models was well received,
inconsistencies in approach, structure, and
terminology were introduced
• For example, CMM-SW provided a “staged”
approach with its pre-defined maturity levels
• In contrast, Systems Engineering CM provided a
“continuous” approach that allows an
organization to improve maturity within a single
process area, independent of other process areas

• As a result, SEI launched the Capability MaturityCapability Maturity
Model Integration (CMMI) effortModel Integration (CMMI) effort
• Its goal is to reduce the redundancy andIts goal is to reduce the redundancy and
complexity that resulted from the use of separate,complexity that resulted from the use of separate,
multiple CMMsmultiple CMMs
• To reach this goal, SEI set out to integrate theTo reach this goal, SEI set out to integrate the
CMMs and create a product suite designed toCMMs and create a product suite designed to
improve efficiency and return on investmentimprove efficiency and return on investment

Understanding CMMIUnderstanding CMMI
• In March 2002, the for Systems Engineering,
Software Engineering, Integrated Product and
Process Development, and Supplier Sourcing
(CMMI-SE/SW/IPPD/SS) Version 1.1 was
released
• Both a staged and a continuous representation of
the CMMI V1.1 is available
• The staged representation of CMMI, like CMM
before it, describes five distinct levels of maturity

CMMI’s Five Maturity LevelsCMMI’s Five Maturity Levels
• These five CMMI maturity levels are, in fact,
named similarly to the five CMM levels:
 Initial
 Managed
 Defined
 Quantitatively Managed
 Optimized

CMMI’s Process AreasCMMI’s Process Areas
• CMMI V1.1 has defined twenty-two process areas
• A process area is a set of related practices, which
when performed collectively, satisfy a set of goals
considered important in making significant
improvements in a given area
• These process areas are common to both the
staged and continuous representations

CMMI’s Process AreasCMMI’s Process Areas
• In the staged representation, these twenty-two
process areas are organized by the five maturity
levels identified earlier
• This approach provides a proven sequence of
improvements, beginning with basic management
practices and progressing through a predefined
and proven path of successive levels
• Each sequence of improvements provides a
foundation for the next maturity level

1. Initial
2. Managed
3. Defined
4. Quantitatively
Managed
5. Optimizing
• Project-Level Focus
• Processes Characterized as
Reactive
• Organization-Level Focus
• Processes Characterized as Proactive
Processes Measured and Controlled
Focus on Continuous Process
Improvement
• Processes Unpredictable
• Poorly Controlled
• Ad Hoc and Chaotic

Process Areas – Specific and Generic GoalsProcess Areas – Specific and Generic Goals
• Each process area consists of one or more specific
goals and one or more generic goals
• Specific goals describe what must be implemented
to satisfy a specific process area and are used in
the appraisal process to determine if a process
area has been satisfied
• Specific goals are supported by specific practices
that describe activities that should result in the
achievement of a process area’s specific goals

• Generic goals are called “generic” because the
same goal statement appears in multiple process
areas
• In the staged representation, each process area
has only one generic goal, the achievement of
which specifies improved control in the planning
and implementing the processes associated with
that area

• Achieving a generic goal is an indicator of whether
a process is likely to be effective, repeatable, and
lasting
• Thus, generic goals are also used in the appraisal
process to determine if a process area is satisfied
• Generic goals are supported by generic practices
that institutionalize the area’s processes

• Generic practices are organized by the following
four common features:
 Commitment to Perform (CO)
 Ability to Perform (AB)
 Directing Implementation (DI)
 Verifying Implementation (VE)
• The common features are used as groupings,
which provide a way to present the generic
practices

Maturity Levels
Process Area 1 Process Area 2 Process Area 3
Specific Goals Generic Goals
Ability
To Perform
Directing
Implementation
Commitment
To Perform
Verifying
ImplementationSpecific
Practices
Specific
Practices

CMMI Level 2 - ManagedCMMI Level 2 - Managed
• At maturity Level 2, an organization has achieved
all the specific and generic goals of the maturity
level 2 process areas
• That is, the projects of the organization have
ensured that requirements are manage and that
processes are planned, performed, measured, and
controlled

CMMI Level 2 – Managed: Process AreasCMMI Level 2 – Managed: Process Areas
• Requirements Management
• Project Planning
• Project Monitoring and Control
• Supplier Agreement Management
• Measurement and Analysis
• Process and Product Quality Assurance
• Configuration Management

Requirements Management: Specific GoalRequirements Management: Specific Goal
Manage Requirements
• Specific Practices
 Obtain an Understanding of Requirements
 Obtain Commitment to Requirements
 Manage Requirement Changes
 Maintain Bidirectional Traceability of
Requirements
 Identify Inconsistencies between Project Work
and Requirements

Requirements Management: Generic GoalRequirements Management: Generic Goal
Institutionalize a Managed Process
• Generic Practices
 Establish an Organizational Policy (CO 1)
 Plan the Process (AB 1)
 Provide Resources (AB 2)
 Assign Responsibility (AB 3)
 Train People (AB 4)

Requirements Management: Generic GoalRequirements Management: Generic Goal
Institutionalize a Managed Process
• Generic Practices
 Manage Configurations (DI 1)
 Identify and Involve Relevant Stakeholders
(DI 2)
 Monitor and Control the Process (DI 3)
 Objectively Evaluate Adherence (VE 1)
 Review Status with Higher Level Management
(VE 2)

CMMI Level 3 – Defined: Process AreasCMMI Level 3 – Defined: Process Areas
• Requirements Development
• Technical Solution
• Product Integration
• Verification
• Validation
• Organizational Process Focus
• Organizational Process Definition
• Organizational Training

CMMI Level 3 – Defined: Process AreasCMMI Level 3 – Defined: Process Areas
• Integrated Project Management for Integrated
Process and Product Development (IPPD)
• Risk Management
• Integrated Teaming
• Integrated Supplier Management
• Decision Analysis and Resolution
• Organizational Environment for Integration

For Additional InformationFor Additional Information
• For additional information on CMMI V.1.1, please
visit the SEI’s Web Site
• http://www.sei.cmu.edu/cmmi/cmmi.html
• Portable Document Format (PDF) editions of both
the staged and continuous representations are
available for downloading

CMM and CMMI V1.1CMM and CMMI V1.1
• To hasten the transition from SW-CMM to CMMI
V1.1, SEI has stopped updating the SW-CMM
• It also plans to discontinue training for SW-CMM
by the end of 2003
• Because CMMI embraces modern software
engineering best practices, the Rational Software
Corporation has endorsed CMMI V1.1
Wrap-UpWrap-Up

ResourcesResources
• Watts S. Humphrey (1990). Managing the
Software Process. Addison-Wesley Publishing
Company, Inc.
• Mark Paulk, et al. (1994). The Capability Maturity
Model: Guidelines for Improving the Software
Process. Addison Wesley Longman, Inc.
• James R. Persse (2001). Implementing the
Capability Maturity Model. John Wiley & Sons,
Inc.

ResourcesResources
• CMMI Project Team (2002). Capability Maturity
Model Integration (CMMI) Version 1.1. Carnegie
Mellon Software Engineering Institute.
• Reaching CMM Levels 2 and 3 with the Rational
Unified Process. A Rational Software Corporation
White Paper.
• Rolf W. Reitzig, Carlo Rodriguez, and Gary Holt
(2002). Achieving Capability Maturity Model Level
2 with the Rational Unified Process. A Rational
Software Corporation White Paper.

ResourcesResources
• Walker Royce (2002). CMM vs CMMI: From
Conventional to Modern Software Management. A
Rational Software Corporation Article printed in
the Rational Edge.
• Rolf W. Reitzig (2003). Using Rational Software
Solutions to Achieve CMMI Level 2. A Rational
Software Corporation Article printed in the
Rational Edge.

Exercise #1Exercise #1
Informal Assessment of the Railroad CommissionInformal Assessment of the Railroad Commission
• Organize into groups and identify a group
facilitator
• Each group is charged with performing an
informal assessment of the Railroad Commission’s
software management and engineering processes
• After each group has completed its assessment, the
assessment will be presented and discussed

RRC CMM CMMI

More Related Content

What's hot

Viewers also liked

Similar to RRC CMM CMMI

More from Terry Startzel, MS, PMP, SCPM, CSM

RRC CMM CMMI