Presentation is loading. Please wait.

Presentation is loading. Please wait.

Michael Dermody September 2010  Capability Maturity Model Integration ◦ Is a Trademark owned by the Software Engineering Institute (SEI) of Carnegie.

Similar presentations


Presentation on theme: "Michael Dermody September 2010  Capability Maturity Model Integration ◦ Is a Trademark owned by the Software Engineering Institute (SEI) of Carnegie."— Presentation transcript:

1

2 Michael Dermody September 2010

3  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.”

4

5  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

6  Productivity gains  Early defect detection  Reduction in time between request and implementation  Reduction in post-implementation defects  Repeatable processes

7  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 Initiate Analyze Design Code Test Deliver Maintain Steps common to all life cycles

8

9

10

11  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 SW Project Design SW SW Project Design Documents

12

13 Focus on Project Management Requirements Management (RM) Project Tracking & Oversight (PTO) Project Planning (PP) Configuration Management (CM) Process Quality Assurance (PQA)

14 Verifies Process Manages Project Controls Products Requirements Management

15 Agree to an initial set of software requirements Manage further changes to SW requirements 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.

16

17 Condition or capability that must be met by a system application to satisfy a business request Speed Function User Interface Cost All requirements should be testable

18 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

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

20 Verifies Process Manages Project Controls Products Requirements Management Project Planning

21 To develop plans and schedules based on the activities, efforts, risks, and resources associated with satisfying project requirements Identify ac tivitie s and work products Estimate and obtain resource commitments Identify risks, issues, and measures to track Create the plan and the schedule

22 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

23 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. Table of Contents 1. Project objectives, scope, and assumptions 2. Standards, methods, and procedures to be followed and the identified decision makers 3. Work products to be created 4. Estimates of size, effort, and cost, and assumptions 7. Risk identification and assessment 6. A defined life cycle for the project including review points 5. References to schedule with resources and milestones 8. Commitments and dependencies 9. References to SCM and SQA plans for the project 10. Verification and validation

24 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 Tasks Wk 1 Wk2 Wk3 Wk4 Wk5 Plan Testing Review Test Plan Develop Scenarios Peer Review Scenarios

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

26

27 Verifies Process Manages Project Controls Products Requirements Management Project Planning Project Tracking & Oversight

28 To have adequate visibility into actual progress, in order to keep the project on track Track accomplishments and results Adjust plans to stay on track Agree to changes in commitments Track effort, size, risks, costs, and schedule

29 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?

30 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

31 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

32 Verifies Process Manages Project Controls Products Requirements Management Project Planning Project Tracking & Oversight Configuration Management

33 To manage the integrity of the project’s work products Identify items to put under configuration management Plan for CM activities Control changes to configured items Communicate status of configuration items Audit configuration baselines

34 Any item that is designated for control and surveillance in order to track, trace, and record any changes Examples Software code / Library elementsBaselines RequirementsDesign documents Product documentsUser documents Test casesTest plans PQA plansEstimates SW Project Design SW Project Design Document s User Manual

35 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 Example Project Life Cycle Production baseline at final release Initiate Baseline Examples Developmental baseline at end of System Test Functional baseline at end of Analysis Analyze Design Code Test Deliver Maintain System baseline at end of Design Developmental baseline at end of Unit Test

36 Verifies Process Manages Project Controls Products Requirements Management Project Planning Project Tracking & Oversight Configuration Management Process Quality Assurance

37 To provide management with insight into the software process Verify compliance Escalate non-compliance issues Report results Plan for PQA activities

38 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.

39 Reviews  Uses tools and techniques to review activities Peer Reviews Inspections  Compare actual activities against processes Audits  Uses tools and techniques to audit work products Testing  Compare actual work products against agreed upon standards and procedures

40 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


Download ppt "Michael Dermody September 2010  Capability Maturity Model Integration ◦ Is a Trademark owned by the Software Engineering Institute (SEI) of Carnegie."

Similar presentations


Ads by Google