COPYRIGHT 2010 GENERAL DYNAMICS ADVANCED INFORMATION SYSTEMS Published and used by TwinSPIN with permission CMMI Level 5 Journey (A.K.A. Things I Wish.

Slides:



Advertisements
Similar presentations
Implementing CMMI® for Development Version 1.3
Advertisements

Copyright © 2003 by Cooliemon TM, LLC 1 Causal Analysis & Resolution (CAR) at Level 1 Presenter: Ralph Williams, President SEI Authorized CBA IPI Lead.
Kai H. Chang COMP 6710 Course NotesSlide CMMI-1 Auburn University Computer Science and Software Engineering Capability Maturity Model Integration - CMMI.
National Cheng-Kung University
Copyright 2005 CMMI and ITIL Alison Adams & Kieran Doyle.
Copyright 2003 CMMI: Executive Briefing Presented by Kieran Doyle
CMMI Overview Dr. Korson Software Engineering. 2 Immature organizations can be successful on occasion, but ultimately run into difficulties because –Success.
OPM and CAR Once special causes are removed from the execution of your chosen process in a project it is now possible to address common causes of variation.
18 th International Forum on COCOMO and Software Cost Modeling October 2003 Use of Historical Data by High Maturity Organizations Rick Hefner, Ph.D.
Copyright 2005 Northrop Grumman Corporation Is CMMI High Maturity Worth the Investment? Southern California SPIN 2 February 2007 Rick Hefner, Ph.D. Director,
Capability Maturity Model Integration (CMMI). CMMI Enterprise-wide process improvement framework Focuses on processes for improved product Process areas:
CMMI Overview Quality Frameworks.
Software Process CS 414 – Software Engineering I Donald J. Bagert Rose-Hulman Institute of Technology December 17, 2002.
Lecture 11 CMM CSCI – 3350 Software Engineering II Fall 2014 Bill Pine.
Space and Airborne Systems NDIA/SEI CMMI Technology Conference Presented by N. Fleischer 1 Raytheon’s Six Sigma Process and Its Application for CMMI By.
Using Six Sigma to Achieve CMMI Levels 4 and 5
SPIN-BG Seminar Intermediate Concepts of CMMI
CMMI Course Summary CMMI course Module 9..
Capability Maturity Model Integration
1 The Continuous Representation. 2 UNIT 2 Topics covered in this unit include Additional terminology Practices – The fundamental building blocks Process.
Copyright © 2009, Systems and Software Consortium, Inc. Introduction to an Integrated Lean Thinking, Six Sigma  and CMMI  Approach for Process Improvement.
Integrated Capability Maturity Model (CMMI)
Training on “CMMI for Development – ver 1.2”
Capability Maturity Model. Reflection Have you ever been a part of, or observed, a “difficult” software development effort? How did the difficulty surface?
CMMI Technology Conference and User Group November 2003 Experiences with Leveraging Six Sigma to Implement CMMI Levels 4 and 5 Jeff Facemire & Hortensia.
The Capability Maturity Model in Software Development Paul X. Harder, JD Government Micro Resources, Inc. September 14, 2004.
Capability Maturity Model Part One - Overview. History Effort started by SEI and MITRE Corporation  assess capability of DoD contractors First.
N By: Md Rezaul Huda Reza n
1 The Continuous Representation. 2 UNIT 2 Topics covered in this unit include Additional terminology Practices – The fundamental building blocks Process.
J. R. Burns, Texas Tech University Capability Maturity Model -- CMM n Developed by the Software Engineering Institute (SEI) in 1989 –SEI is a spinoff.
CMMi What is CMMi? Basic terms Levels Common Features Assessment process List of KPAs for each level.
College of Engineering and Computer Science Computer Science Department CSC 131 Computer Software Engineering Fall 2006 Lecture # 1 (Ch. 1, 2, & 3)
Software Engineering Lecture # 17
NDIA Systems Engineering Supportability & Interoperability Conference October 2003 Using Six Sigma to Improve Systems Engineering Rick Hefner, Ph.D.
1 The Do’s and Don’ts of Software Process Improvement Steve Chenoweth, RHIT.
IT Requirements Management Balancing Needs and Expectations.
10/16/2015Bahill1 Organizational Innovation and Deployment Causal Analysis and Resolution 5 Optimizing 4 Quantitatively Managed 3 Defined 2 Managed Continuous.
Software Process Assessment and Improvement
CS 3610: Software Engineering – Fall 2009 Dr. Hisham Haddad – CSIS Dept. Chapter 2 The Software Process Discussion of the Software Process: Process Framework,
1 ISO 9001:2000 ISO 9001 is the creation of the International Organisation for Standardisation (ISO), a Swiss-based federation of national standards bodies.ISO.
Georgia Institute of Technology CS 4320 Fall 2003.
1 © Mahindra Satyam 2009 Mahindra Satyam Confidential Welcome To CMMI Introduction.
IS Methodologies. Systems Development Life Cycle - SDLC Planning Planning define the system to be developed define the system to be developed Set the.
@2002 Copyright, Itreya Technologies CMMI kick off July 2005.
CS Process Improvement CMM Hans Van Vliet, Software Engineering, Principles and Practice, 3 rd edition, John Wiley & Sons, Chapter 6. W. Humphrey,
Process Improvement. It is not necessary to change. Survival is not mandatory. »W. Edwards Deming Both change and stability are fundamental to process.
CMMI. 1.Initial - The software process is characterized as ad hoc, and occasionally even chaotic. Few processes are defined, and success depends on individual.
January 2003 CMMI ® CMMI ® V1.1 Tutorial Sponsored by the U.S. Department of Defense © 2003 by Carnegie Mellon University SM CMM Integration and SCAMPI.
Process Improvement. It is not necessary to change. Survival is not mandatory. »W. Edwards Deming.
Purpose: The purpose of CMM Integration is to provide guidance for improving your organization’s processes and your ability to manage the development,
Guidelines for Process
An Introduction. Objective - Understand the difference between CMM & CMMI - Understand the Structure of CMMI.
Copyright © | Trade secret and confidential Page 1 Innovative, Professional, Fact Based and Eustressed© Maruthi Quality Management Services Ptv. Ltd..,
SOFTWARE PROCESS IMPROVEMENT
COMPGZ07 Project Management CMMI Project Planning Lecture 5b Graham Collins, UCL.
MSA Orientation – v203a 1 What’s RIGHT with the CMMI?!? Pat O’Toole
Project Management Strategies Hidden in the CMMI Rick Hefner, Northrop Grumman CMMI Technology Conference & User Group November.
CMMI Overview Quality Frameworks. Slide 2 of 146 Outline Introduction High level overview of CMMI Questions and comments.
© 2004 Tangram Hi-Tech Solutions Project Management According to the CMMI1 Project Management according to the Capability Maturity Model (CMMI)
CMMI for Services, Version 1.3
Certification: CMMI Emerson Murphy-Hill. Capability Maturity Model Integration (CMMI) Creation of the Software Engineering Institute (SEI) at Carnegie.
A Comparison of CMMI & SPICE
State of Michigan Achieving Software Process Improvement with
CS4311 Spring 2011 Process Improvement Dr
Chapter 10 Software Quality Assurance& Test Plan Software Testing
CMMI Overview Quality Frameworks.
CMMI Q & A.
CMMI Overview.
Software Engineering I
Presentation transcript:

COPYRIGHT 2010 GENERAL DYNAMICS ADVANCED INFORMATION SYSTEMS Published and used by TwinSPIN with permission CMMI Level 5 Journey (A.K.A. Things I Wish Others Shared With Me) Linda Schultz February 2010

2 Agenda l Why is High Maturity CMMI Important to General Dynamics? l Our CMMI Journey l Why the Backslide? l Lessons Learned ä Quality and Process-Performance Objectives (QPPOs) ä Process Performance Models (PPMs) ä Process Performance Baselines (PPBs) ä Causal Analysis and Resolution Activities (CARs) ä Organizational Innovations and Deployments (OIDs)

3 Importance of CMMI to General Dynamics l Organization has a strong affinity for process ä CMM for software since 1980s ä IEEE, MIL- and DoD- standards l CMMI Level 3 is a stated management expectation l We have contract requirements for certain CMMI levels l Strong belief that higher levels of CMMI maturity will make our developed products better, cheaper, and ready faster

4 CMMI Staged Representation Eliminate Common Causes of Variation Eliminate Special Causes of Variation Ad hoc Each Program May Have Own Process, Reactive Common Org Processes, More Proactive

5 CMMI Journey 1999 CMM Level 3 SW 2004 CMMI Level 3 version 1.1 SE, SW, IPPD, SS 2005 CMMI Level 5 version 1.1 SE, SW, IPPD, SS 2008 CMMI Level 3 version 1.2 CMMI-DEV+IPPD SYS, SW, HW 2009 CMMI Level 5 version 1.2 CMMI- DEV+IPPD SYS, SW, HW

6 CMMI Journey We are here!

7 Why the Backslide? Less Internal Focus on Process Improvement Initiatives 15% Organizational Changes 5% New CMMI Model – CMMI version 1.2 0% Changed Expectations from SEI 80%

8 CMMI Journey l We were appraised at CMMI Level 5 in 2005 l We just wanted to “renew” our credentials before they expired in 2008 l Started down the appraisal path in 2007 l What we did in the past didn’t work anymore ä Big changes for the Level 4 and 5 Process Areas: OPP, QPM, OID and CAR ä Artifacts that were acceptable in 2005 were no longer acceptable in 2007 l Needed to listen and learn... fast!

9 Changed Expectations QPPO Lessons Learned l A Quality and Process-Performance Objective (QPPO) is not just any well-stated goal or objective ä QPPOs relate back to business objectives ä QPPOs must be quantified and time-based n Reduce the escape of software defects by 15% prior to Integration Testing by December 31, 2010 ä QPPOs are impacted by 1 or more well-documented sub-processes n Sub-processes must be composed of clearly defined steps n Sub-processes must be under statistical process control

10 Changed Expectations QPPO Lessons Learned (continued) ä Organizational QPPOs flow down to the programs n Programs need to do some data analysis to assure that org QPPOs are achievable n If programs modify org QPPOs, they must provide rationale based on data analysis n Programs document their QPPOs in their Program QMP n For each program QPPO, there should be a strategy as to how it will be measured during the execution of the project and documented in the QMP n During program execution, if a program can’t meet a QPPO, they implement process changes to try to achieve it ä If it’s not possible to achieve the QPPO, programs negotiate a change to their QMP and obtain management approval using the CAR process

11 Changed Expectations PPM Lessons Learned l A Process Performance Model (PPM) is not a model [at least as we knew it] ä It’s not an application model – like CoCoMo l It is... ä An equation that relates controllable and uncontrollable factors of a sub-process ä Generated using modeling techniques (e.g., regression analysis) with tools such as Minitab ä Used throughout a program’s lifecycle to evaluate current status and predict progress towards meeting QPPOs

12 Changed Expectations PPB Lessons Learned l Be careful about selecting the data for Process Performance Baselines (PPBs) l PPBs need to be based on: ä “Clean” data vs. “Dirty” data ä Data representative of current process ä Sufficient # of data points on which to draw conclusions ä Dis-aggregated data n Don’t combine all Systems Data in a single PPB; Break separately into Requirements, Integration & Test, etc.

13 Changed Expectations PPB Lessons Learned (continued) l Generated using a tool like Minitab l Initially, a program may use organizational PPBs until they have enough data points to calculate their own PPBs ä Organizational PPBs represent a rollup of many programs’ data; programs should realize the risk of using Org PPBs l A program may use PPBs from a similar program that may be “closer” to their own (instead of using the org PPBs) until they have enough data points to calculate their own PPBs

14 Changed Expectations CAR Lessons Learned l A Causal Analysis and Resolution (CAR) activity isn’t just root cause analysis done on any problem l It is... ä A program process area ä Based on Common Cause (proactive) vs. Special Cause Variation (reactive) ä Must be related to a quantitative measure on the program -- even better if related to a QPPO ä Requires a measure of effectiveness n Effectiveness must be shown in terms of a process performance change in the program’s data n Not an ROI calculation

15 Changed Expectations OID Lessons Learned l An Organizational Innovation and Deployment (OID) isn’t just any process improvement ä even if it’s well-planned, been piloted and been monitored l It is... ä An organizational process area - the org version of CAR ä Change affects a stable process ä Process change requires a phased implementation (Pilot, Deployment, etc.) ä Based on Common Cause ä Requires a measure of effectiveness in terms of a process performance change in the program’s data - not an ROI calculation ä Apply process changes across the organization – not on 1 program or function

16 Benefits From Our CMMI Journey l Lots of new training, tools, and templates being used l Managing more with objective data rather than subjective gut feel l Data being collected is of higher quality; allows better decisions to be made l More rigorous statistical analysis done for the organization and the programs as a matter of course l More dramatic process improvements on the programs – can see the difference in their charts l Organizational process improvements have broader applicability l Tighter coupling between business objectives, process improvement goals and program QPPOs

17 Questions? Comments? Contact Information: Linda Schultz General Dynamics Advanced Information Systems Senior Process and Quality Manager, and CMMI Program Manager

18