1 / 16

Capability Maturity Models

June 7, 1999 Capability Maturity Models Software Engineering Institute (supported by DoD) The problems of software development are mainly caused by poor process management Five process maturity levels are defined Each maturity level has its associated key process areas (KPAs)

Télécharger la présentation

Capability Maturity Models

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.


Presentation Transcript

  1. June 7, 1999 Capability Maturity Models • Software Engineering Institute (supported by DoD) • The problems of software development are mainly caused by poor process management • Five process maturity levels are defined • Each maturity level has its associated key process areas (KPAs) • Level 1: Initial Level • Everything is done on an ad hoc basis; few processes are defined • Unpredictable - success depends on individual effort • Capability is a characteristic of the individuals, not of the organization. • The majority of software organizations are Level 1 organization

  2. Capability Maturity Models (2) • Level 2: Repeatable • Basic project management processes are established to track cost and schedule (measurements) • The necessary process discipline is in place to repeat earlier success on similar projects • Processes may differ among projects in a Level 2 organization • KPAs • Software configuration management • Software quality assurance • Software subcontract management • Software project tracking and oversight • Software project planning • Requirements management

  3. Capability Maturity Models (3) • Level 3: Defined • The software process for both management and engineering activities is documented, standardized, and integrated into an organization-wide software process • Projects tailor the organization’s standard software process to develop their own defined software process, which accounts for the unique characteristics of the project. (Project Defined Software Process) • KPAs • Peer review • Intergroup coordination • Software product engineering • Integrated software management • Training program • Organization process definition • Organization process focus

  4. Capability Maturity Models (4) • Level 4: Managed • The organization sets quantitative quality goals for both software products and processes. • Quality and productivity are continuously measured • An organization-wide software process database is used to collect and analyze the data available form the projects’ defined software process • Corrective actions are taken when there are unacceptable deviations from the goal • KPAs • Software quality management • Quantitative process management

  5. Capability Maturity Models (5) • Level 5: Optimizing • Focused on continuous process improvement • Cost/benefit analyses of new technologies and proposed changes to the organization’s software process. • Innovations that exploit the best software engineering practices are identified and transferred throughout the organization • KPAs • Process change management • Technology change management • Defect prevention

  6. Process Capability and the Prediction of Performance • Figure 2.2 from the CMM handout • Software process is the way we produce software. It incorporates the software life-cycle model, the tools we use and, most important of all, the individuals building the software.

  7. Chapter 3: Software Life-Cycle Models • The series of steps through which the product progresses is called the life-cycle model • Build-and-fix model • Waterfall model (most commonly used) • Rapid prototyping model (most commonly used) • Incremental model • Synchronize-and-stabilize (or daily build) model (Microsoft) • Spiral model (Boehm) • Object-oriented Life-cycle models • Fountain (Henderson-Sellers), Baseball (Coad), and others

  8. Build-and-Fix Model • Figure 3.1 • No specifications and design • Build (implement) the product and rework the product as many times as necessary to satisfy the client • Strength and Weakness • Work well on small programs • High rework cost • Maintenance is difficult (without specifications and design documents)

  9. Waterfall Model • Waterfall model (Royce, 1970) (Figure 3.2) • A critical point regarding the waterfall model is that no phase is complete until the documentation for that phase has been completed. • Strength • Enforced disciplined approach • Documentation provided (documentation-driven model) • The products of each phase being carefully checked by SQA • Inherent in every phase of the waterfall model is testing • Weakness • In general, specification documents are long, detailed, and hard to read • The first time that the client sees a working product is only after the entire product has been coded

  10. Rapid Prototyping Model • A rapid prototype is a working model that is functionally equivalent to a subset of the product • Figure 3.3 • Build a rapid prototype and let the client or end-users interact with the rapid prototype and experiment with it; specification follows • Strength • The feedback loops of the Waterfall model are less likely to be needed in the rapid prototyping model • the prototype has been “validated” through interaction with the client • Design teams can gain insights from the rapid prototype • Weakness?

  11. Incremental Model • The product is designed, implemented, integrated, and tested as a series of incremental “builds” • Each build consists of code pieces from various modules interacting together to provide a specific functionality capability • Strength • Early delivery of “useful” and “usable” products to the client • Allow time for the client to learn and adjust to the new product • The client can stop the development of the product at any time • Requirements change can be incorporated in later builds (releases) • Weakness • Each additional build has to be incorporated into the existing structure without destroying what has been built to date -- success relies on product has an “open architecture” • Project control becomes more difficult

  12. Synchronize-and-Stabilize Model • Prioritized features • Specification • Divide the set of features into three or four builds • Each build is carried out by a number of small teams (six to eight people) working in parallel • At the end of each day all the teams synchronize (put together the partially completed components and test the resulting product (daily build) • Stabilization is performed at the end of each build (milestone); the contents of the build is frozen

  13. Synchronize-and-Stabilize Model (2) • Advantages • Repeated synchronization ensures that the various components always work together (I.e., always has something working to ship) • Early insight into the operation of the product help revise and refine requirements

  14. Spiral Model • Software development involves unavoidable risks • The delivered product does not satisfy client’s real needs • Key personnel resigns while the development is still in progress • Essential difference between small scale product and large scale product. • Use “prototyping” as a risk reduction mechanism • Figures 3.6, 3.7, and 3.8 • Strength and Weakness • The iterative framework realistically reflects the real world (software evolves) • Risk-driven: demands considerable risk assessment expertise • Suitable for large-scale software development • Project termination legal issues

  15. Object-Oriented Life-Cycle Models • Fountain Model (Figure 3.9) • Undisciplined form of software development • A better way to proceed is to have as an overall objective a linear process as well as appreciate the realities of the OO paradigm concerning the features as frequent iteration and refinements. • “Iteration” is an intrinsic property of software production in general and the OO paradigm in particular

  16. Comparison of Life-Cycle Models • Figure 3.10

More Related