Learning Objectives You should be able to z
Learning Objectives You should be able to: z Describe the evolution of software process models z Explain the features of each model, I. e. , how each improves on the previous model z Discuss the motivation for the CMM, e. g. , its relationship to software engineering and quality improvement z Compare immature and mature software organizations z List and describe the 5 CMM maturity levels z Discuss benefits and difficulties in implementing the CMM
ISM 5316 Software Process Models and the CMM
Software Process Models z. Purpose of software process models: ydetermine order of stages x. What shall we do next? yestablish transition criteria from one stage to the next x. How long shall we continue to do it? z. Model vs. method z. Process vs. product
Problems with Software Development Processes z Late, over-budget, chaotic, undisciplined z Poor quality software products z Best results due to individual heroic efforts, not mature process z No consistent long-term productivity z Difficult to repeat best results z Larger, more complex projects need a shift from technical to management focus z $$ spent on software increases 12+% per year z Increasing demand for added functionality
Code-and-Fix Model z Steps y. Write some code y. Fix problems in the code y. Think about requirements, design, testing, and maintenance later y. Code-driven z Problems y. Increasingly poorly structured code y. Increasingly expensive to change and fix y. Poor match to users’ needs, thus increasing the need for changing and fixing
Stagewise/Waterfall Models Feasibility Functional Analysis Specifications Detailed Design Specs Design Construction Implementation Evaluation/ maintenance
Difficulties with Waterfall z. Document-driven y. Formal specs may be too much, inaccurate z. Doesn’t accommodate: y. Parallel or incremental development y. Changing requirements y. Interactive software y 4 GL tools
Evolutionary and Transform Models z Prototyping y. Iterative development y. Expanding operational software incrementally y. Too much like Code&Fix y. Lack of planning y. Lack of structure z Transform Model ymore structured “I can’t tell you what I want, but I’ll know it when I see it” Client
Spiral Model (Iterative) z Risk-driven (versus document-driven or code-driven) z Evolutionary and flexible z Iterative enhancement z Prototyping = risk reduction z Specifications not uniform, exhaustive, or formal = less time z Focuses early attention on reuse z Incorporates software quality objectives
Steps in Each Cycle of Spiral Model z. Objectives z. Constraints z. Alternatives z. Risk identification z. Risk resolution and results z. Plan for next phase z(Re)commitment
Object-Oriented Process Model z Establish core requirements: Conceptualization y Proof of concept (risk) z Develop a model of desired behavior: Analysis y develop common vocabulary z Create an architecture: Design y policies for implementation z Evolve the implementation: Evolution y refine architecture z Manage postdelivery evolution: Maintenance y continued evolution based on new requirements
Object-Oriented Process Analysis Conceptualization Design Maintenance Evolution
Current Life-cycle Phases z. Engineering y. Inception (idea) y. Elaboration (architecture) z. Production y. Construction (iterations - beta releases) y. Transition (products)
Capability Maturity Model (CMM) z Helps organizations improve software processes z Based on results of assessments of contractors, industry and gov’t feedback z Software process assessment yassess current capabilities yhighlight high-priority areas for improvement ygain organizational support for improvement z Based on Juran’s Trilogy of quality improvement yquality planning, control, improvement z 5 maturity levels
Software Organization Maturity Immature Mature processes improvised reactionary unrealistic estimates quality compromised to meet schedule z no objective basis for evaluation z inadequate review, testing, etc. z standard, documented processes z known, used, and learned z organization-wide ability to manage processes z continuous process improvement z clear roles and responsibilities z managers monitor product quality and customer satisfaction z realistic schedules and budgets based on historical data z z
CMM Definitions z. Software process y. Activities, methods, practices, and transformations used by people to develop and maintain software products z. Capability y. Range of expected results achieved by a software process z. Performance y. Actual results achieved by a software process z. Maturity y. Extent to which a software process is explicitly defined, managed, controlled, effective, and consistent
CMM Level 1: Initial z Unstable, chaotic software processes z Poor planning undermines good software engineering practices z Process capability is unpredictable z Performance depends on individual capabilities, not repeatable z Procedures are abandoned in crises z Lack understanding of importance of planning, design, reviews, testing
CMM Level 2: Repeatable z Management vs. technical focus z PM policies and procedures are established, PM standards are defined and enforced z Planning is based on previous experiences ytime, cost estimation z Effective processes are: ypracticed, documented, enforced, trained, measured z Objective: Basic management controls
CMM Level 3: Defined z Software processes, both project management and software engineering, are standardized and documented z Organization-wide process definition and training z Projects can tailor processes to their unique needs y processes empower but don’t constrain z Well-defined, consistent processes, have: y readiness criteria, inputs, outputs y performance standards, completion criteria, verification z Software Engineering process group established z Common organizational understanding of process y activities, roles, responsibilities
CMM Level 4: Managed z Quantitative measures of quality yproducts and processes z Organization-wide process database for analysis and as basis for measurement z Narrow variation in process performance z Risk assessment and management z Predictable capability
CMM Level 5: Optimizing z Organization-wide focus on continuous improvement yincremental improvement yimprovement by adoption & transfer of innovations z Goal is defect prevention yanalyze defects to determine causes z Lessons learned transferred to future projects z Emulates statistical process control in manufacturing systems
Strengths and Limitations z Descriptive, normative model of behavior z Doesn’t constrain unique organizational process needs z Needs to be interpreted, implemented to fit the context yorganization’s strategic objectives, culture, structure, systems z Assumes other organizational change processes in place z Takes 1+ years to move from one level to the next z Levels should not be skipped yeach provides the foundation for the next one
Difficulties in Improving Software Processes z Lack of consensus between managers and developers about how to improve z Focus on management vs. engineering ymanagement process harder to define z Requires time - no quick fix z Must be done level at a time z Requires culture change z Requires organization-wide commitment z Scarcity of skilled personnel
Benefits of CMM z Visibility of software process to management z Predictable performance ytime and cost estimation ydecreases differences in targeted/actual results and variability of results z Better control over new technologies and applications z More efficient communication yconcise, common, quantitative terms z Disciplined change as a way of life
- Slides: 24