A Capability Maturity Model for Research Data Management
CMM for RDM » 0. Introduction » 0.2 Background of the Capability Maturity Model
Last modified by Arden Kirkland on 2014/06/30 09:26
From version 10.3
edited by Arden Kirkland
on 2014/03/14 15:55
To version 11.1
edited by Arden Kirkland
on 2014/03/14 17:54
Change comment: added title

Content changes

... ... @@ -1,3 +1,5 @@
1 += 0.2 Background of the Capability Maturity Model =
2 +
1 1 The original Capability Maturity Model (CMM) was developed at the Software Engineering Institute (SEI) at Carnegie Mellon University to support improvements in the reliability of software development organizations, that is, in their ability to develop quality software on time and within budget. More specifically, it was “designed to help developers to select process-improvement strategies by determining their current process maturity and identifying the most critical issues to improving their software quality and process” ([[Paulk et al., 1993, p. 19>>||anchor="Paulk"]]).
2 2
3 3 The model has evolved over time, but the basic structure remains roughly the same. It includes four key concepts: key practices, key specific and generic process areas and maturity levels. The development of the CMM was based on the observation that in order to develop software, organizations must be capable of reliably carrying out a number of key software development //practices// (e.g., eliciting customer needs or tracking changes to products), that is, they must be able to perform them in a consistent and predictable fashion. In the original CMM, these practices are clustered into 22 //specific process areas//, that is, “related practices in an area that, when implemented collectively, satisfy a set of goals considered important for making improvement in that area” ([[CMMI Product Team, 2006, Glossary>>||anchor="CMMI"]]). For example, eliciting customer needs is part of requirements development; tracking changes to products, part of configuration management. Achieving the goals is mandatory for good performance; the practices given are the expected (though not required) way to achieve those goals. The process areas are further grouped into four categories: support, project management, process management and engineering.

XWiki Enterprise 5.1-milestone-1 - Documentation