2. Greetings and Welcome!Greetings and Welcome!
Greetings and Welcome to this
Software 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!
3. Greetings and Welcome!Greetings and Welcome!
Greetings and Welcome to this
Software Engineering Process
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!
4. Greetings and Welcome!Greetings and Welcome!
Greetings and Welcome to this
Software Engineering Process
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.
5. Greetings and Welcome!Greetings and Welcome!
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
6. 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)
7. 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
8. 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
9. 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
10. 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
11. 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
12. 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
13. Overview WorkshopOverview 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
14. Overview WorkshopOverview 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)
15. 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
16. Capability Maturity ModelCapability Maturity Model
Background and History
• 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)
17. Capability Maturity ModelCapability Maturity Model
Background and History
• 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
18. Capability Maturity ModelCapability Maturity Model
Background and History
• 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
19. Capability Maturity ModelCapability Maturity Model
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
20. Capability Maturity ModelCapability Maturity Model
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
21. Capability Maturity ModelCapability Maturity Model
Continuous Process Improvement
• 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
22. Capability Maturity ModelCapability Maturity Model
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)
23. Capability Maturity ModelCapability Maturity Model
Five Maturity Levels
• 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
24. Capability Maturity ModelCapability Maturity Model
Five Maturity Levels
• 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)
25. Capability Maturity ModelCapability Maturity Model
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
26. Capability Maturity ModelCapability Maturity Model
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
27. Capability Maturity ModelCapability Maturity Model
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
28. Capability Maturity ModelCapability Maturity Model
The Repeatable Level
• 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
29. Capability Maturity ModelCapability Maturity Model
The Repeatable Level
• 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
30. Capability Maturity ModelCapability Maturity Model
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
31. Capability Maturity ModelCapability Maturity Model
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
32. Capability Maturity ModelCapability Maturity Model
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
33. Capability Maturity ModelCapability Maturity Model
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
34. Capability Maturity ModelCapability Maturity Model
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
35. Capability Maturity ModelCapability Maturity Model
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
36. Capability Maturity ModelCapability Maturity Model
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
37. Capability Maturity ModelCapability Maturity Model
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
38. Capability Maturity ModelCapability Maturity Model
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
39. Capability Maturity ModelCapability Maturity Model
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
40. Capability Maturity ModelCapability Maturity Model
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
41. Capability Maturity ModelCapability Maturity Model
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
42. Capability Maturity ModelCapability Maturity Model
The Managed Level – SEI Estimates
• SEI estimates that in the industry as a whole, only
2 to 3 percent of all software development
organizations would probably assess at Level 4
43. Capability Maturity ModelCapability Maturity Model
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
44. Capability Maturity ModelCapability Maturity Model
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
45. Capability Maturity ModelCapability Maturity Model
The Managed Level – SEI Estimates
• SEI estimates that in the industry as a whole, only
2 to 3 percent of all software development
organizations would probably assess at Level 4
46. Capability Maturity ModelCapability Maturity Model
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
47. 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
48. Capability Maturity Model IntegrationCapability Maturity Model Integration Version 1.1
• 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
From CMM to CMMIFrom CMM to CMMI
49. Capability Maturity Model IntegrationCapability Maturity Model Integration Version 1.1
• 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
From CMM to CMMIFrom CMM to CMMI
50. Understanding CMMIUnderstanding CMMI
Capability Maturity Model IntegrationCapability Maturity Model Integration Version 1.1
• 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
51. 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
Understanding CMMIUnderstanding CMMI
52. 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
Understanding CMMIUnderstanding CMMI
53. 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
Understanding CMMIUnderstanding CMMI
54. 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
Understanding CMMIUnderstanding CMMI
55. 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
Understanding CMMIUnderstanding CMMI
56. Process Areas – Specific and Generic GoalsProcess Areas – Specific and Generic 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
Understanding CMMIUnderstanding CMMI
57. Process Areas – Specific and Generic GoalsProcess Areas – Specific and Generic Goals
• 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
Understanding CMMIUnderstanding CMMI
58. Process Areas – Specific and Generic GoalsProcess Areas – Specific and Generic Goals
• 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
Understanding CMMIUnderstanding CMMI
59. Understanding CMMIUnderstanding CMMI
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
60. 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
Understanding CMMIUnderstanding CMMI
61. 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
Understanding CMMIUnderstanding CMMI
62. 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
Understanding CMMIUnderstanding CMMI
63. 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)
Understanding CMMIUnderstanding CMMI
64. Requirements Management: Generic GoalRequirements Management: Generic Goal
Institutionalize a Managed Process
• Generic Practices
Understanding CMMIUnderstanding CMMI
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)
65. 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
Understanding CMMIUnderstanding CMMI
66. 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
Understanding CMMIUnderstanding CMMI
67. 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
Understanding CMMIUnderstanding CMMI
68. 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
69. 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.
70. 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.
71. 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.
72. 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