CMM and the SDLC

1. CMM and the SDLC Michael Dermody September 2010

2. What is CMMI ? • Capability Maturity Model Integration • Is a Trademark owned by the Software Engineering Institute (SEI) of Carnegie Mellon University • Process Improvement Approach – Improves Performance by improving processes • Provides organizations with the needed for effective process improvements • Framework for appraising the process maturity of the organization • According to SEI in 2008, CMMI helps "integrate traditionally separate organizational functions, set process improvement goals and priorities, provide guidance for quality processes, and provide a point of reference for appraising current processes.”

3. Maturity Levels

4. Level 2 Characteristics • Projects are managed and under control • Estimating new project tasks is based on actual results from previous projects • Realistic commitments are negotiated and managed • Plans are documented, progress is tracked, and status is reported appropriately • Processes are defined at the project level • Project decisions are based on data

5. Benefits of Moving to Level 2 • Productivity gains • Early defect detection • Reduction in time between request and implementation • Reduction in post-implementation defects • Repeatable processes

6. Initiate Analyze Design Code Test Deliver Maintain Life Cycle • A life cycle is a description of the approach that a project takes to develop and deliver software. It includes the sequencing of tasks organized by phases Steps commonto all life cycles

7. Lifecycles - Waterfall

8. Iterative Lifecycles

9. Incremental Lifecycle

10. SW Project Design Documents SW Project Design SW Work Products • A work product is any document or deliverable that is used during the entire life cycle as well as any portion of the software that is delivered to the customer • The SDLC has templates and procedures for generating required work products

11. Lifecycle Templates

12. Level 2 Key Process Areas (KPA) Focus on Project Management Requirements Management (RM) Project Tracking & Oversight (PTO) Project Planning (PP) Configuration Management (CM) Process Quality Assurance (PQA)

13. Level 2 KPAs Manages Project Requirements Management Verifies Process Controls Products

14. Requirements Management (RM) To establish a common understanding of requirements between the customer and the project and manage any changes to these over the life of the project. Why? Agree to an initial set of software requirements Manage further changes to SW requirements How?

15. Poor Requirements Management

16. What is a Requirement? Condition or capability that must be met by a system application to satisfy a business request User Interface Speed Cost Function All requirements should be testable

17. Requirements Baselined A document that: • Has been formally reviewed, agreed upon, and committed to by means of signoff • Serves as the basis for further development • Can be changed only through formal change control procedures Builder Model 101 Cost: $170,000 Bedrooms: 3 Living Room Kitchen Dining Room Expected Completion: April 30

18. Requirements Revised Change Request - Add Fireplace to Living Room- Build Bookshelves in Living Room - Add Family Room - Add Porch Builder Model 101 Cost: $220,000 Bedrooms: 3 Living Room with Fireplace & Bookshelves Kitchen Dining RoomFamily Room Porch Expected Completion June 30 Add Fireplace & Install Built-in Bookshelves Add Family Room Add Porch

19. Level 2 KPAs Manages Project Project Planning Requirements Management Verifies Process Controls Products

20. Project Planning (PP) To develop plans and schedules based onthe activities, efforts, risks, and resources associated with satisfying project requirements Why? Estimate and obtain resource commitments Identify activities and work products How? Create the planand the schedule Identify risks, issues, and measures to track

21. What is a Statement of Work? • A document that describes the work required to complete a project that consists of: • High-level project objectives and scope • Identification of customers • Imposed standards (management or technical) • Constraints (cost, schedule, and resources) • External commitments and dependencies • Top-level system requirements

22. Table of Contents Table of Contents 6. A defined life cycle for the project including review points 5. References to schedule with resources and milestones 2. Standards, methods, and procedures to be followed and the identified decision makers 1. Project objectives, scope, and assumptions 7. Risk identification and assessment 3. Work products to be created 4. Estimates of size, effort, and cost, and assumptions 9. References to SCM and SQA plans for the project 8. Commitments and dependencies 10. Verification and validation What is a Project Plan? A collection of plans describing the technical and nontechnical activities for a project. It governs the management of activities performed by the Software Engineering Process Group (SEPG) for a project.

23. Tasks Wk 1 Wk2 Wk3 Wk4 Wk5 Plan Testing Review Test Plan DevelopScenarios Peer ReviewScenarios Software Estimation • Use requirements as the high-level basis for beginning the project plan • Collect historical data for use in new estimates • Break activities down into manageable chunks(for example, < 60 hours of effort or 2 weeks duration) • Decompose manageable chunks into smaller process steps

24. Use a standard methodology • Identify and document estimating assumptions • Develop estimates in effort-hours, not elapsed time • Use in budgeting and staffing projects appropriately Quality What level of quality is required? Cost How much will it cost? Effort How much work will it require? Schedule When will deliverables be available? Size How big is it? Productivity How much time is available per week? Resources How many people are needed? What type of skills? What tools do we need?

25. Estimation Tool

26. Level 2 KPAs Manages Project Project Tracking & Oversight Project Planning Requirements Management Verifies Process Controls Products

27. Project Tracking & Oversight (PTO) To have adequate visibility into actual progress, in order to keep the project on track Why? Track accomplishments and results Adjust plans to stay on track How? Agree to changes in commitments Track effort, size, risks,costs, and schedule

28. What to Track in the Project Plan • Size, effort, cost, and duration • Larger/smaller, more/less complex, early/late? • Resources • Change in availability, over/under allocations? • Schedule/activities • Complete/not complete, additional activities? • Impact on dependent activities? • Risks • Resolved, changed, additional risks ? • Risk impact or probability changed?

29. Corrective Action Tasks • Adjust plan as deviations from the plan occur • Scope, Resources, Schedule • Review adjustments and obtain buy-in and commitment • Update plans based on requirement changes • Manage and mitigate risk

30. Communication and Oversight • Internal project status reviews • Detail status of activities, schedule, effort, costs, and risks • Detail actuals to compare with estimates • Periodic senior management reviews • Status of accomplishments, issues, and risks • Milestone reviews • Formal reviews for customers, management. and affected groups at predetermined milestones • Progress, accomplishments, issues, risks • Ad hoc reviews occur as needed

31. Level 2 KPAs Manages Project Project Planning Requirements Management Project Tracking & Oversight Verifies Process Controls Products Configuration Management

32. Plan for CM activities Identify items to put under configuration management Control changes to configured items Communicate status of configuration items Audit configuration baselines Configuration Management (CM) Why? To manage the integrity of the project’s work products How?

33. User Manual SW Project Design Documents SW Project Design Configuration Items Any item that is designated for control and surveillance in order to track, trace, and record any changes Examples Software code / Library elements Baselines Requirements Design documents Product documents User documents Test cases Test plans PQA plans Estimates

34. Baselining Configuration Items • Baselines are established at predetermined points in the life cycle of the work product. • Configuration of a work product evolves during development and is applied by developers as they perform their work. • Create baselines at predetermined points Baseline Examples Initiate Functional baseline at end of Analysis Analyze System baseline at end of Design Design Example ProjectLife Cycle Developmental baseline at end of Unit Test Code Developmental baseline at end of System Test Test Deliver Production baseline at final release Maintain

35. Level 2 KPAs Manages Project Project Planning Requirements Management Project Tracking & Oversight Verifies Process Controls Products Process Quality Assurance Configuration Management

36. Process Quality Assurance (PQA) Why? To provide management with insight into the software process Verify compliance Plan for PQA activities How? Report results Escalate non-compliance issues

37. PQA • A planned and systematic pattern of all actions necessary to provide adequate confidence that work products comply with software standards, procedures, and contractual requirements. • A set of activities designed to evaluate the process by which work products are developed and/or maintained.

38. PQA Audits • Uses tools and techniques to audit work products Testing • Compare actual work products against agreed upon standards and procedures Reviews • Uses tools and techniques to review activities Peer Reviews Inspections • Compare actual activities against processes

39. Summary of Level 2 Behaviors • Use of processes and procedures is ensured by management and encouraged by peers • Benefits of following the process are understood and recognized • Appropriate training and resources are provided • Planned activities are willingly committed to • Open communications and sharing • Team approach versus individual heroics