Systematic process improvement using ISO 9001:2000 and CMMI

162 Transitioning from Legacy Standards
wherever possible. If there is no equivalent specific practice at the same
maturity level, we will consider key practices at the next higher level. When
analyzing similarities and differences between the models, a mapping, such
as that given in [3], may be useful. Because of the cumulative nature of
KPAs and PAs, projects in high-maturity organizations will benefit from their
higher maturity processes even when they implement lower level PAs. When
comparing the models we may distinguish two cases: (1) organizations that
are new to process improvement and are committed to using the CMMI ®
and (2) organizations that are transitioning from the CMM ® to the CMMI ® .
Organizations in either of those cases will approach the CMMI ® requirements
differently. An organization transitioning from the CMM ® to the CMMI ®
will have to perform a gap analysis to determine what it has to do to preserve
its investment in the CMM ® and still satisfy the CMMI ® requirements. On the
other hand, an organization new to process improvement will also perform a
gap analysis, but will be free to select the implementation road map that
best suits its business goals.
As Figure 6.3 shows, most KPAs have migrated from the CMM ® to the
CMMI ® . They have been extended to include systems engineering concepts
not present in the CMM ® resulting, at least, in name changes. For example,
Software Configuration Management (SCM) in the CMM ® has become Configuration
Management in the CMMI ® . Software Project Planning (SPP) is now
Project Planning. A new PA that is not in the CMM ® , Measurement and
Analysis, has been added.
Requirements Management (REQM)
Let us start with the REQM PA. The first specific practice, SP 1.1, Obtain
Understanding of the Requirements, is new in the CMMI ® . It merges activities
from Software Process Engineering (SPE) and Intergroup Coordination (IC) 5 and
extends them to include all system requirements, not just software requirements.
SP 1.2, Obtain Commitments to Requirements, and SP 1.3, Manage Requirements
Changes, closely match the CMM ® RM activities 1 and 3, respectively.
In the CMM ® , requirements traceability is buried in level 3 as a subpractice
to SPE activity 10. The CMMI ® elevates traceability to SP 1.4, Maintain
Bidirectional Traceability of Requirements. This means that the source and the
user of each requirement is known and that related information such as
5. SPE.AC.2: ‘‘The software requirements are developed, maintained, documented, and verified by systematically
analyzing the allocated requirements according to the project’s defined software process.’’
IC.AC.1: ‘‘The software engineering group and the other engineering groups participate with the customer and
end users, as appropriate, to establish the system requirements.’’