Page 55 -
P. 55
26 PART ONE THE PRODUCT AND THE PROCESS
• Software subcontract management
• Software project tracking and oversight
• Software project planning
• Requirements management
Process maturity level 3
• Peer reviews
WebRef
• Intergroup coordination
A tabular version of the
complete SEI-CMM, • Software product engineering
including all goals,
commitments, abilities, and • Integrated software management
activities, is available at • Training program
sepo.nosc.mil/
CMMmatrices.html • Organization process definition
• Organization process focus
Process maturity level 4
• Software quality management
• Quantitative process management
Process maturity level 5
• Process change management
• Technology change management
• Defect prevention
Each of the KPAs is defined by a set of key practices that contribute to satisfying its
goals. The key practices are policies, procedures, and activities that must occur before
a key process area has been fully instituted. The SEI defines key indicators as "those
key practices or components of key practices that offer the greatest insight into whether
the goals of a key process area have been achieved." Assessment questions are
designed to probe for the existence (or lack thereof) of a key indicator.
2.3 SOFTWARE PROCESS MODELS
To solve actual problems in an industry setting, a software engineer or a team of engi-
neers must incorporate a development strategy that encompasses the process, meth-
“Too often, software
work follows the ods, and tools layers described in Section 2.1.1 and the generic phases discussed in
first law of bicycling: Section 2.1.2. This strategy is often referred to as a process model or a software engi-
No matter where neering paradigm. A process model for software engineering is chosen based on the
you're going, it's nature of the project and application, the methods and tools to be used, and the con-
uphill and against trols and deliverables that are required. In an intriguing paper on the nature of the
the wind.”
author unknown software process, L. B. S. Raccoon [RAC95] uses fractals as the basis for a discussion
of the true nature of the software process.