The ability of a software development organisation to develop software that consistently meets the real requirements of a customer and doing so on time and within the budget is generally recognized to be fairly low across the industry. As the software projects continue to increase in size and importance, this inability greatly increases the risk to the customer. This risk can only be reduced by the software development organisation if a focused and sustained effort is made at building a process infrastructure of effective software engineering and management practices.

To build this process infrastructure, software producers need ways to appraise the capability of their processes to produce quality products. They also need guidance to improve their process capability. At the same time, customers need ways to evaluate the software producer organisation so that customer risks are minimized.

To help achieve both the above, the Software Engineering Institute (SEI) at Carnegie Mellon University, Pittsburgh, USA has developed the Capability Maturity Model (CMM) that delineates the characteristics of a mature capable software process. The progression from an immature software process to a mature, well managed software process is described in terms of maturity levels in the model.

CMM Maturity Levels

Level 1 – The Initial Level

  • Lack of sound software engineering processes and ineffective planning, thus within the organisation, project success cannot be consistently assured.
  • Software process capability is unpredictable and adhoc and so, Quality happens by chance rather than Quality by design
  • This Level has been variously termed as “chaotic” or “software development by black magic”

 

Level 2 – The Repeatable Level

  • Disciplined with basic management controls in place e.g. Project Planning, Configuration Management etc
  • Only the management processes are addressed in this level and, none of the processes which would have helped the project team to perform more effectively technically are yet to be put in place, e.g. training, product quality metrics

 

Level 3 – The Defined Level

  • A standard process for the organisation is developed and documented, which includes both software engineering, and project management processes
  • Still, various projects teams in organisation are free to tailor this process according to their specific project requirements and unique project characteristics
  • The management has a good insight into technical progresses of all its on going projects

 

Level 4 – The Managed Level

  • Organisation is able to set quantitative quality goals for both products and processes
  • Productivity and quality are measured as part of an organisation-wide metrics capture program
  • Projects achieve control by narrowing the variation in their performance to fall within the acceptable boundaries
  • The products produced by this organisation are of predictably high quality

 

Level 5 – The Optimizing Level

  • Organisation is now focused on continuous process improvement through continued analysis of defects data and to determine root causes and prevent these from happening
  • The process capability of organizations at this level can be characterized as continuously improving
  • Only level where the present tense has been used in naming the level

 

KPA (Key Process Area)

  • Each KPA identifies a cluster of related activities that, when performed collectively, achieve a set of goals considered important for enhancing process capability.

Level

KPAs
Level 1 KPAs §  None
Level 2 KPAs §  Requirements Management

§  Software Project Planning

§  Software Project Tracking And Oversight

§  Software Subcontract Management

§  Software Quality Assurance

§  Software Configuration Management

Level 3 KPAs §  Organisation Process Focus

§  Organisation Process Definition

§  Training Program

§  Integrated SW Management

§  SW Product Engineering

§  Intergroup Coordination

§  Peer Reviews

Level 4 KPAs §  Quantitative Process Management

§  Software Quality Management

Level 5 KPAs §  Defect Prevention

§  Technology Change Management

§  Process Change Management

 

Leave a Reply

Your email address will not be published. Required fields are marked *

Name *