Systematic process improvement using ISO 9001:2000 and CMMI
Systematic process improvement using ISO 9001:2000 and CMMI
Systematic process improvement using ISO 9001:2000 and CMMI
Create successful ePaper yourself
Turn your PDF publications into a flip-book with our unique Google optimized e-Paper software.
194 Transitioning from Legacy St<strong>and</strong>ards<br />
Level 2 organizations need to revisit the already established PAs in light<br />
of newly added systems engineering aspects. A slightly different approach<br />
may be required after considering questions such as these:<br />
• Is the organization developing software systems<br />
• Is the organization developing systems that contain hardware, such<br />
as satellite communications<br />
• Is the organization performing software maintenance<br />
• How large is the organization<br />
• How is the <strong>CMMI</strong> ® going to be interpreted in each of these cases<br />
At maturity level 2, the inclusion of systems engineering in the model<br />
requires some clarification of certain specific practices. In the <strong>CMMI</strong> ® , these<br />
clarifications are called discipline amplifications. For example, in the REQM<br />
PA, SG 1, Manage Requirements, has amplifications for both software engineering<br />
<strong>and</strong> for systems engineering. For software engineering, the <strong>CMMI</strong> ®<br />
provides amplification by explaining that requirements may be a subset of<br />
overall product requirements (where there are other requirements, such as<br />
for hardware components) or that they may constitute the entire product<br />
requirements (for a purely software product).<br />
Similarly, in the PP PA, SP 1.3, Define Project Life Cycle, has two amplifications.<br />
For software engineering, the <strong>CMMI</strong> ® indicates that determination of<br />
project phases typically includes selecting <strong>and</strong> refining a software development<br />
model <strong>and</strong> addressing the interdependencies <strong>and</strong> interactions of its<br />
activities. For systems engineering, an organization should identify major<br />
product phases for the current state of the product <strong>and</strong> expected future<br />
phases, <strong>and</strong> the relationships <strong>and</strong> effects among those phases. In such cases,<br />
an organization should evaluate its approach. Several different approaches<br />
can be envisioned to support different applications <strong>and</strong> fields of implementation<br />
while maintaining the major core practices common to all applications.<br />
In all of these cases, the organization benefits from <strong>CMMI</strong> ® implementation.<br />
GP 2.5, Train People, also requires attention. The training curriculum of an<br />
organization transitioning to the <strong>CMMI</strong> ® will have to address the differences<br />
between the newly added <strong>process</strong>es <strong>and</strong> the existing CMM ® -based <strong>process</strong>es.<br />
For example, a data management <strong>process</strong> added to the PP PA or aspects of<br />
measurement <strong>and</strong> analysis that are also new at maturity level 2 will have<br />
to be addressed. In addition, SP 2.5, Plan for Needed Knowledge <strong>and</strong> Skills, in<br />
the PP PA represents a new requirement at level 2.