08.02.2015 Views

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

SHOW MORE
SHOW LESS

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.

Hooray! Your file is uploaded and ready to be published.

Saved successfully!

Ooh no, something went wrong!