Lecture Software process improvement: Lesson 11 provide students with knowledge about: CMM capability maturity model; organization process focus; organization process definition; training program; integrated software management; software product engineering; intergroup coordination; peer reviews;... Please refer to the detailed content of the lecture!
CMM Level 3 Lecture # 11A CMM Capability Maturity Model • • • • • Initial Repeatable Defined Managed Optimizing The Defined Level C MM Moving from Level 2 to Level 3 • At level 2, the focus is on projects • At level 3, the emphasis shifts to the organization – best practices are gathered across the organization – processes are tailored as appropriate • organization supports the project by establishing – common processes, common measurements and training Moving from Level 2 to Level 3 • Organizations have mastered a development process that can often lead to successful large systems • Over and above the project management and technical approaches found in Level 2 organizations, the Level 3 groups have a welldefined development process that can handle all sizes and kinds of projects Following slide to be inserted Level 3 KPAs C MM • • • • • • • KPA’s Level 3 Organization Process Focus Organization Process Definition Training Program Integrated Software Management Software Product Engineering Intergroup Coordination Peer Reviews Organization Process Focus C MM Purpose • Purpose is to establish the organizational responsibility for software process activities that improve the organization’s overall process capability • Involves – developing and maintaining an understanding of organization’s and projects software processes – coordinating the activities to assess, develop, maintain, and improve these processes C MM Dedicating People to Process • A dedicated group of people is responsible for the organization’s software process activities; e.g., – appraisals – software process improvement plans • Includes maintaining the organization’s software process database and providing training about the organization’s software process C MM Project Management Evolves • Software development plan is now based on the project’s defined software process • Projects can use and share process data and lessons learnt • Integrated software management is the evolution of software project planning and software project tracking and oversight Software Product Engineering C MM Purpose • Purpose is to consistently perform a well defined engineering process that integrates all the software engineering activities to produce correct, consistent software products effectively and efficiently. • Involves – performing the engineering tasks to build and maintain the software using the appropriate methods and tools C MM Software Life cycles processes • Development and maintenance activities include • • • • • software requirement analysis software design coding testing integration • Testing activities include • • • • unit integration system acceptance C MM Documentation • Addresses needs that span life cycle • Customer and enduser documentation includes – user manuals – training materials – operator manuals • Developer / maintainer documentation includes – – – – software requirements documents design documents test documents maintenance manuals C MM Consistency and Traceability • Consistency and traceability among documents are critical to their usefulness • Inconsistent specifications are not useable • If the relationship between documents is not clearly traceable, their usefulness is minimized Inter group Coordination C MM Purpose • Purpose is to establish a means for software engineering group to participate actively with the other engineering groups, so that the project is better able to satisfy the customer needs effectively and efficiently • Involves – disciplined interaction and coordination of the projects engineering groups with each other to address systemlevel requirements, objectives and plans C MM Ongoing working Relationship • “Commitments” among groups are documented and agreed to by all groups • Inter group coordination can be – as minimal as one or two meetings between project groups – as extensive as integrated product teams C MM Interdisciplinary Groups • The software engineering group actively interfaces with a variety of groups – Examples of these groups, to whom the interface must be managed include; • • • • • Systems engineering Marketing Training Sub contract management Documentation – Intergroup coordination is a first step on the road to concurrent engineering Peer Reviews C MM Purpose • Purpose is to remove defects from the software work products early and efficiently. An important corollary effect is to develop a better understanding of the software work products and of defects that might be prevented • Involves – methodical examination of work products by the producer’s peers to identify defects and areas where changes are needed – Identifying products that will undergo a peer review in the project’s defined software process C MM • • • • • • • • Performing Peer Reviews Plan and schedule peer reviews Train leaders and participants Give material to the reviewers in advance Assign each reviewer a specific role Specify criteria to begin and end reviews Use pre planned checklists Identify action items and track to closure Collect and analyze data for product and peer review process C MM Alternative Peer Review Methods Possible alternative ways of implementing peer reviews include; • Faganstyle inspections • Structured walkthroughs • Active reviews • Phased inspections References • The Capability Maturity Model: Guidelines for Improving Software Process 49 ... Guidelines and criteria for tailoring the organization’s standard? ?software? ? process – The organization’s? ?software? ?process? ?database – A library of? ?software? ?process? ?related documentation Following slide to be inserted Context for? ?Software? ?Process? ?Assets ... process? ?that is tailored from the organization’s standard software? ?process? ?and related? ?process? ?assets • Involves – developing the projects defined? ?software? ?process? ?by tailoring the organization’s standard? ?software? ?process – managing the? ?software? ?project according to this defined? ?software? ?process. .. These relationships are sometimes referred to as a? ?software? ? process? ?architecture • Many different? ?software? ?processes can be built using the architecture of the organization’s standard? ?software? ?process C MM Software? ?Life Cycles