June 7 1999 Capability Maturity Models Software Engineering

June 7, 1999 Capability Maturity Models • Software Engineering Institute (supported by Do. D) • 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

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

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

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

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

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.

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

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)

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

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?

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

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

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

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

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

Comparison of Life-Cycle Models • Figure 3. 10