ConventionalToModernFeb02 - CMM vs. CMMI: From Conventional...

Info iconThis preview shows pages 1–3. Sign up to view the full content.

View Full Document Right Arrow Icon

Info iconThis preview has intentionally blurred sections. Sign up to view the full version.

View Full DocumentRight Arrow Icon
This is the end of the preview. Sign up to access the rest of the document.

Unformatted text preview: CMM vs. CMMI: From Conventional to Modern Software Management by Walker Royce Vice President and General Manager Strategic Services Rational Software Corporation This article summarizes some thoughts on making the transition from conventional software management techniques to modern ones. In particular, I want to endorse the improvements in the Software Engineering Institute's new CMMI ( Capability Maturity Model Integration ) 1 approach and motivate development organizations to apply the approach correctly. Although I have always been a supporter of the spirit behind the original Capability Maturity Model (CMM), in practice, it has been misused and misinterpreted too much for my liking. Based on my twenty-five years of experience with many of the world's leading software development organizations engaged in process improvement, I am convinced that most organizations using the CMM are still entrenched in a default waterfall model mentality. I won't lay blame on the model itself, for I am aware of some process improvements made within a CMM context that were very much based on a modern, iterative approach to development. But this enlightened interpretation is not the norm. CMM Overview The CMM defines five levels of software process maturity, based on an organization's support for certain key process areas (KPAs). Level 1 (initial) describes an organization with an immature or undefined process. Level 2 (repeatable), Level 3 (defined), Level 4 (managed), and Level 5 (optimizing), respectively, describe organizations with successively higher levels of software process maturity. The associated KPAs for these levels are: Level 2 : requirements management; software project planning; software project tracking and oversight; software subcontract management; software quality assurance; software configuration management Level 3: organizational process focus, organizational process definition, training program, integrated software management, software product engineering, intergroup coordination, peer reviews Level 4: process measurement and analysis; quality management; defect prevention Level 5: technology innovation, process change management The primary goal for most organizations is to achieve a Level 3 maturity . One instrument for assessing an organization's current maturity level is a software capability evaluation (SCE), which determines whether the organization "says what it does and does what it says" by evaluating its software process (usually in the form of policy statements) and project practices. The organization's process captures the "say what you do," and project implementations (specific tailorings and interpretations of this process) should demonstrate the "do what you say." Issues with the CMM One of the key issues I have encountered with the CMM is that the KPAs focus mostly on activities and supporting artifacts associated with a conventional waterfall process: requirements specifications, documented plans, quality assurance audits and inspections, and documented processes...
View Full Document

Page1 / 11

ConventionalToModernFeb02 - CMM vs. CMMI: From Conventional...

This preview shows document pages 1 - 3. Sign up to view the full document.

View Full Document Right Arrow Icon
Ask a homework question - tutors are online