Implementing the CMM Level 3

1. Implementing the CMM Level 3 • Focusing on Organizational Process Improvement • Organization Process Definition • Creating Level 3 Structures • Creating Level 3 Processes • Creating a Level 3 Training Program • Creating Level 3 Policies

2. Focusing on Organizational Process Improvement At Level 3, the entire organization becomes focused on process improvement. It’s an important step up the maturity scale. At this point your teams have developed a set of proven processes and practices that have been shown to work over time and across a wide variety of projects. The challenge now is to gather these into a single program and then to implement it across the organization, with the idea of measurement and improvement still in mind. -- Alan Waklin, Micronetix Corporation

3. SE: Process Improvement • Understanding existing processes • Introducing process changes to achieve organisational objectives which are usually focused on quality improvement, cost reduction and schedule acceleration • Most process improvement work so far has focused on defect reduction. This reflects the increasing attention paid by industry to quality • However, other process attributes can be the focus of improvement

4. SE: Process Attributes

5. SE: Process Improvement Stages • Process analysis • Model and analyse (quantitatively if possible) existing processes • Improvement identification • Identify quality, cost or schedule bottlenecks • Process change introduction • Modify the process to remove identified bottlenecks • Process change training • Train staff involved in new process proposals • Change tuning • Evolve and improve process improvements

6. SE: The Process Improvement Process

7. The Right Structure for a Focus on Process at Level 3 SPI Plan SPI Plan SPI Plan Software Engineering Process Group (SEPG) Activity Activity Activity Activity Activity Feedback

8. Software Process Improvement Plan • Creating the SPI plan is a core effort for Level 3 shops • CMM is not really a software process improvement program. It is a framework on which you can build your own SPI program. • CMM gives you the infrastructure and direction to instantiate SPI activities.

9. Template for Building Your SPI Plan I • Introduction >> Statement of the organization’s commitment to SPI >> Statement of the executive sponsorship of the SPI plan • Description of the general goals of this SPI plan • Description of the goals of the SPI plan as related to overall company objectives • Description of the role of the SEPG within the organization • Listing of SEPG membership with contact information • Approved use of the SPI plan • Scope of SPI activities • Functional areas affected by SPI and the plan • Protocol for evaluations >> Choose evaluators >> Create evaluation forms and guidelines >> Announce evaluations >> Conduct evaluations to identify strengths and weaknesses

10. Template for Building Your SPI Plan II >> Document results >> Create evaluation report >> Distribute evaluation report >> Review recommended improvement actions • Coordinate improvement action integration • Coordinate deployment of the revised (new) process assets • Coordinate project adoption of revised material • Coordinate training in the new changes • Schedule of planned evaluations • Definition of measurements to gauge SPI/EPG progress • Management of the SPI plan

11. Evidence of Organization Process Focus Activity

12. Organization Process Definition The entry for Level 3 is a degree of maturity marked by an already present focus on process improvement. The move to Level 3 – the organization’s adoption of A common set of software development processes and practices – is almost always accompanied by a Depth of experience that provides a benchmark for What works well. At level 3, that knowledge is Formally defined. -- Booch Kasadian, Process Development Enterprises

13. Kick-off KPAs for CMM Level 3 • Organization Process Focus (OPF) • Organization Process Definition (OPD)

14. Five Assets Comprised By SSPS • The documented processes and practices that you elected to institutionalize across the organization • The descriptions of the software development life cycles you have elected to allow for use on your project. • The set of tailoring guidelines that helps your people fine-tune the SSPS to the unique needs of a specific project. • The establishment of a common measurement database used as a repository for all project-level process and practice measurements. • A centralized process library that is used to manage and version control the contents of the SSPS.

15. A Structure to Support OPD Organization’s Standard Software Process Set Defined Software Process Set for Project ABC Defined Software Process Set for Project 123 Defined Software Process Set for Project XYZ

16. Evidence of Program Compliance

17. Creating Level 3 Structures The Structure that put into place at Level 3 are there, ultimately, to help you communicate. There is organizational need to share a common body of knowledge with the workforce. There are also specific communication needs within each project – sharing information on process, status, and the risks each group needs to be aware of. -- Dan Payne, Senior Analyst, Lockheed-Martin Corp

18. New Structures in Level 3 SEPG Umbrella Commitment for Resources, funding, Tools, and Facilities Level 3 Process Management And Software Process Improvement Activities SQA Function Training Group SCM Function SPP Function SPTO Function SRM Function

19. Evidence of Program Compliance

20. Creating Level 3 Processes Effective process management at Level 3 requires the extension of what you have built at Level 2. At Level 2 you set the pillars in place for process improvement. At Level 3 you strengthen them, and the foundation for process improvement settles into place. -- Ransom Day, Public Health Software Systems

21. Level 3 Mostly Just Extends Level 2 on Processes For CMM Level 2, you’ll set up processes for RM, SPP, SQA, CM, and vendor management. Each of these areas can be seen as existing in may ways apart from each other. Each addresses a specific functional area along the development chain. But at Level 3 things change. The CMM introduces only one more independent KPA, Training Program. The others-Organization Process Focus, Organization Process Definition, Integrated Software Management, Software Product Engineering, Intergroup Coordination, and Peer Review – all serve to expand the Level 2 processes, to deepen their reach within the organization, to crystallize tracking elements down to finer detail.

22. Level 2 Project-wide Repeatable SDP is focused mainly on the management ofbroad issues and work products. SDP is just SDP Review process Level 3 Organization-wide Defined, institutionalized, standard SDP is focused on making up Software Product Engineering effort SDP includes SDP, SQAP, SCMP, Intergroup coordination LAN, PRP Peer Review extends L2’s review process Comparison Of L3 And L2

23. Peer Review Process

24. A Peer Review Plan Template • Work products for review • Peer review dates • Peer review participants • SQA quality control points • Metrics collection

25. A Peer Review Process • Draft Ready Date Arrives • Draft Author Assigns Review Moderator and Recorder • Draft Confirmed to Be Ready for Review • Meeting Facilities Prepared • Material Distributed and Meeting Announced • Review Period • Review Meeting Occurs • Meeting Notes Distributed • Revisions Made as Requested • Revised Document Redistributed • Product Submitted for Signature/Approval • Product Baselined • Process Metrics Collected

26. Training Program Processes • Preparing a syllabus for each training course you are offering • Preparing a training plan for each project being initiated in your shop

27. A Training Course Syllabus Template • Course Number • Course Title and Subtitle • Course Description • Textbook and Required Materials • Learning Objectives • Content Outline • Course Length • Audience; Enrollment Criteria • Waiver Criteria • Instructor/Sponsor • Location/Classroom • Cost Per Attendee • Review Cycle • Scheduling Point of Contact

28. A Training Plan Template • Course to be taught • Recommended participants • Rationale • Training duration and cost • Available training dates • Preparation tasks • Waiver option

29. Software Product Engineering Processes • The SPE KPA of the CMM is a different kind of KPA. From it, the CMM begins to address direct intervention into the rote technical activities involved in software development. • The idea of a software product engineering KPA lies pretty much in its name: improved technical performance through the administration of process measures.

30. Traditional Requirements gathering System analysis System design Coding Unit testing System testing Integration testing Documentation Acceptance testing Maintenance CMM Focus Requirements management Software design Coding Unit testing Integration testing Acceptance testing Documentation Control of development tools and the manner in which defect data (metrics) is gathered and managed. Stages of Development Life Cycle

31. SDP at Level 2 Statement of work Introduction/overview Life cycle adopted Standards and procedures A list of the work procedures to be developed Scope projections Schedule Measurements to be made Facilities and support tools available Risks and assumptions Any related appendixes L3 Extending SDP Identify major engineering milestones Budget and schedule resources Assess risks Create a SQA plan Create a SCM plan Create a IC plan Conduct Peer Reviews Add Integrated Software Management practices Extending Software Development Planning

32. Integrated Software Management Processes • The ISM KPA is in place to help coordinate the use of the organization’s SSPS across the projects within the organization. • The ISM KPA also guides how to tailor the SSPS to DSPS which is used to shape and control various elements of project progress and activity results.

33. Guidelines for Tailoring the SSPS • Study and then define the tailoring steps • Document the guidelines for all to use • Establish the procedures to waive certain SSPS steps • Peer review the guidelines for approval • Configuration manage the resulting guidelines documents • Revise the guidelines over time as necessary

34. The Level 3 SD Plan I • Statement of work • Introduction/overview • Life cycle adopted • Standards and procedures • A list of the work products to be developed. The work products include >> The requirements >> software design >> system code >> unit/system testing >> integration testing >> acceptance testing >> project documentation This includes both plan and activities. The work products also include

35. The Level 3 SD Plan II >> size estimates >> effort and cost estimates >> critical resources required >> critical path or dependencies >> identified risks/assumptions • Scope projections • Schedule • Measurements to be made • Facilities and support tools available • Risks and assumptions • Any related appendixes

36. The Level 3 SD Plan III • SQA plan • SCM plan • IC plan • Vendor management plan (if you’re contracting with outside services.) • PR plan • Training plan • Risk management plan • Any relevant appendixes • The project’s Defined Software Process Set – DSPS (by way of reference)

37. Intergroup Coordination Processes • Software development can involve many different groups. • Software development usually fares poorly in an isolationist environment. • Communication is vital for any project, not just within teams but between teams. • The effective and coordinatedcommunication is so important to quality software development. • In fact, we might say that the CMM is all about coordination. The plans, processes, and practices employed to create a product are there as a way to coordinate activity in a predicable and trackable manner.

38. No In the sense that any exchange between groups can be seen as a status meeting of sorts, and the format that you’ll use for the exchanges will be probably be for all practical matters the same as for regular status meetings. Yes In the sense that these exchanges, the IC “events” will be individually planned in advance. They will be anticipated in the project plan and recognized as perhaps “formal” status meetings where specific items, not just project progress in general, need to be addressed. Is IC Different from Regular Project Status Meeting?

39. A Template for IC Plan • The milestone • The participating groups • The agenda (Technical issues, Critical Dependencies, and Overall status) • Event date • Event location (if available) • SQA review points • SCM review points • Coordination measurements

40. Evidence of Program Compliance

41. Creating Level 3 Training Program Training is an important long-term success factor in organizations. Personnel management studies point out an interesting correlation – companies that invest in training show a lower level of turnover than companies that don’t. Training not only brings needed skills and knowledge to the workforce, but it in many other ways reinforces the workforce, imparting both a sense of individual growth and a sense of common mission. -- Makie May, Quality Assurance Consultant

42. L3 Training Program Structure Process & Practice Competency Technical Proficiency Job Role Training Project Orientations Centralized Training Program General Leadership And Team Training

43. Evidence of Program Compliance

44. Creating Level 3 Policies At level 3 the entire organized becomes focused on process improvement. It’s an important step up the maturity scale. At this point your teams have developed a set of proven processes and practices that have been shown to work over time and across a wide variety of projects. The challenge now is to gather these into a single program and then to implement it across the organization, with the idea of measurement and improvement still in mind. -- Peter Dillon, Staffing Resources Inc

45. Carrying Over Policies From L2 • A requirements management policy directing the conditions and use of requirements within a project • A project planning policy governing how project planning materials are developed and approved and how formal commitments are made concerning the project. • A project tracking policy directing the manner in which project resources and commitments are kept consistent with project progress. • A subcontractor management policy on the use of overseeing subcontractor work • A configuration management policy describing the use and availability of CM resources and tools for each project. • A software quality assurance policy governing the oversight and reporting duties particular to the SQA mission.

46. Policies Required in Level 3

47. Evidence of Program Compliance