RRC CMM CMMI

Software Engineering ProcessDisciplined, Modern, and Mature

An Overview Workshop for the Railroad Commission of Texas

January 21 & 22, 2003

http://www.rrc.state.tx.us/index.html

Greetings and Welcome!Greetings and Welcome!

Greetings and Welcome to thisSoftware Engineering Process

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 Overview Why 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 Overview Why 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 Redenbacher An 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 Redenbacher An 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 Workshop Overview 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

Overview Workshop Overview Workshop 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

Overview Workshop Overview Workshop 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

• The key process areas for Level 3 focus on 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

• The key process areas for Level 3 focus on 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 organizations would probably assess at Level 3


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

• The key process areas for Level 4 focus on 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



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

• The key process areas for Level 5 focus on implementing continuous and measurable software process improvement: Defect Prevention Technology Change Management Process Change Management


The Managed Level – SEI Estimates



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 Maturity Capability Maturity Model Integration (CMMI) effortModel Integration (CMMI) effort

• Its goal is to reduce the redundancy and Its 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 the To reach this goal, SEI set out to integrate the CMMs and create a product suite designed to CMMs 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

AbilityTo Perform

DirectingImplementation

CommitmentTo Perform

VerifyingImplementationSpecific

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


http://www.sei.cmu.edu/cmmi/cmmi.html

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-Up Wrap-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

Documents

Transcript of RRC CMM CMMI