Acquisition and Development Models

2,322 views

Published on

Published in: Business, Technology
0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
2,322
On SlideShare
0
From Embeds
0
Number of Embeds
2
Actions
Shares
0
Downloads
87
Comments
0
Likes
1
Embeds 0
No embeds

No notes for slide
  • CMMs are models that describe how system, software engineering, and other best practices in an organization evolve - work performed is organized and viewed as a process - the evolution of the process is manages separately Like all models, CMM is abstract, but based on experience. Is DESCRIPTIVE, not PRESCRIPTIVE. “ All models are wrong, some models are useful.” - Box’s Rule, George Box (quoted in CrossTalk Jan 97) CMM is not a silver bullet. The CMMI v1.1 is a large living document (714 pages - show it) - Available on SEI website or from SEPO (see references). V1.2 will be coming out FY 2005. No specific tools, methods, or technologies are mandated. No application domains, software technologies, people management
  • Show copy of the CMMI document. There is a really good summary article on CMM by Mark Paulk that first appeared in IEEE magazine, and included in SME Guidebook available on the PAL. I highly recommend it for anyone that needs a quick and good understanding of the model. The CMM had a sunset date of Dec 2003. We have been transitioning to the CMMI, which combine the SW, SE, IPD, and SA CMMs.
  • CMMI is a model that describes how engineering practices in an organization evolve - work performed is organized and viewed as a process - the evolution of the process is manages separately Like all models, CMMI is abstract, but based on experience. Is DESCRIPTIVE, not PRESCRIPTIVE. “ All models are wrong, some models are useful.” - Box’s Rule, George Box (quoted in CrossTalk Jan 97) CMM is not a silver bullet. The CMMI is a large living document ( show it) - Available on SEI website or from SEPO (see references) No specific tools, methods, or technologies are mandated. No application domains, software technologies, people management SSC will be using Staged version of CMMI - SE / SW / IPPD / SS
  • 22 PA in SE/SW 25 PAs in SE / SW / IPPD / SS Levels 2 through 5 are decomposed into PAs: cluster of related activities that achieve goals for enhancing process capability. CMMI describes what to do, not how to do it. Has common sense, efficient, proven ways of keeping whole team going in same direction. This is what you (prog. Mgr) are probably already doing because you learned you had to. CMMI is not a radical new approach - it is what you should be doing anyway!
  • Many projects are immature - may have to reinvent the wheel each time Processes are improvised by practitioners and management Processes not rigorously followed or enforced Reactionary to crises
  • Animation: titles only at start; details on first mouse click, PAs on second Issues of Level 1 orgs/project addressed by Level 2: No control of requirements, creep, drive-by tasking No plans; driven by customer’s budget and schedule No tracking, always “90% done” Little control over configurations and versions of documents and products If you remember back to the CMMI chart, the characteristic of Level 2, the Managed Level, is “management oversight and tracking project; stable planning and product baselines”. So, what does that mean in manager-speak? It means that a project manager is expected to first understand the project’s requirements, make and document the project plans, track progress against those plans, and control the software products. It also means that acquisition and management of any sub-contractors will be done appropriately. Each of these functions is described in a PA. These are basic, get your project under control, management processes. Which of these actions are not essential to a project? Which can be skipped?
  • Animation: titles only at start; details on first mouse click, PAs on second From the CMMI chart, we see that the characteristic of Level 3, the Defined Level, is “process standardization.” At L3, software groups share best practices, lessons learned, and data about software processes. “Take the process view.” Reuse assets. Issues addressed at L3: Standard systematic ways to develop products (engineering) Integrating engineering with project management Establishing organizational standard process Setting up process improvement infrastructure For a manager, that means you need to consciously pick,document, and train, the processes you expect your team to follow, like coding standards, or how to do testing, or what kind of design will they do. You also need to engage in team building and communications. And insist on the use of one of the easiest and most productive processes in terms of ROI process we have found -- peer reviews.
  • Animation: titles only at start; details on first mouse click, PAs on second The CMMI chart says the characteristic of Level 4, the Quantitatively Managed Level, is “product quality planning; tracking of measured software process”. At Level 4 and above, the organization is expected to use metrics heavily for it’s process and product management. Levels 2 and 3 build the foundation necessary for quantitative management expected at Level 4. Processes are measured and controlled. The org sets quantitative quality goals for products and processes. This means to you that at this point, you had better be making management decisions based on numeric and quality goals that you set for your performance and your products. You would use techniques such as statistical process control Issues addressed at L4: No ability to predict performance, or set goals No ability to manage by fact/experience, just feel The characteristics of Level 5 is “continuous process CAPABILITY improvement”. Level 5 has continuous process capability improvement. The focus is on continuous improvement of process capability, prevention of occurrence of defects using root cause analysis, and identifying and transitioning new technologies (tools, methods, processes). Issues addressed at L5: Determining root cause of problems Continually optimizing Taking advantage of new tools, methods, processes in the industry At Level 5, you identify weaknesses, strengthen the process. Innovations are identified and transferred throughout the org. Defects are analyzed for cause, lessons learned are disseminated.
  • Animation: figures at bottom appear after one mouse click At Level 1, projects may not have their own set of software engineering and management processes. Yet they might produce good products anyway. Projects may use 1. Heroes to solve problems 2. Primitive methods 3. Rudimentary processes 4. Processes that result in fires - need firefighters/tiger teams
  • At Level 2, projects may have their own set of software engineering and management processes, but they are not coordinated across the organization. Processes may be lousy or GREAT, but not coordinated. Each group at each level is different. “Stovepipes” Must have policies to guide projects in establishing processes for Level 2.
  • At level 3, 4, and 5, good practices are shared across the whole organization. An organization-wide SEPG (or SEPO) administers the Process Asset Library (PAL) with standard processes. Each dept. tailors the org’s processes to its own environment and then feedback lessons learned to improve the organization’s standard processes. So Dept A projects (1 and 2) share similar processes, and Dept B’s projects (3 and 4) share similar processes. They are not necessarily all the same because of all the factors that affect a process (remember the tailoring guidelines from the previous section?). We should not imply that each department has a single environment or a single set of processes. It is the application and the project environment that drives the process. There may be commonalities across departments; and differences within a department. The issue is the environments and processes have been tested and approved for application within the organization. Specific project characteristics drive the selection of the processes and the tailoring of those processes. Sponsors expect that when they give work to two different SSC San Diego Departments, the expectation of success is the same. URL for the SSC San Diego PAL is on vgs 70.
  • Acquisition and Development Models

    1. 1. CMMI Acquisition and Development Models (CMMI-ACQ/CMMI-DEV) 10 October 2006
    2. 2. Capability Maturity Models - Overview <ul><li>A representation of the engineering and management “world” </li></ul><ul><li>Focuses on elements of essential practices and processes from various bodies of knowledge </li></ul><ul><li>Describes common sense, efficient, proven ways of doing business (which you should already be doing) - not a radical new approach </li></ul><ul><li>Presents a minimum set of recommended practices and leverage points that have been shown to enhance organizational maturity and project capability </li></ul><ul><ul><li>It defines the expectation (the “what”) </li></ul></ul><ul><ul><li>Without overly constraining the implementation (the “how”) </li></ul></ul><ul><li>Example implementations of CMMs: </li></ul><ul><ul><li>People CMM: develop, motivate and retain project talent </li></ul></ul><ul><ul><li>Software CMM: enhance a software-focused development and maintenance capability </li></ul></ul><ul><ul><li>CMMI: focuses on systems and software engineering process development </li></ul></ul>
    3. 3. Who Needs CMMI? <ul><li>CMMI is for projects or organizations that: </li></ul><ul><ul><li>Need to manage the acquisition, development, and maintenance of products or services </li></ul></ul><ul><ul><li>Are concerned about cost and schedule overruns or unhappy users / stakeholders </li></ul></ul><ul><ul><li>Are concerned about costs of quality and rework </li></ul></ul><ul><ul><li>Are seeking a competitive advantage </li></ul></ul><ul><li>It is a process improvement method that provides a set of best practices to address productivity, performance, costs, and stakeholder satisfaction. CMMI focuses on the total system problem unlike: </li></ul><ul><ul><li>Single-discipline models that can result in confusion and higher costs. CMMI facilitates enterprise-wide process improvement </li></ul></ul><ul><ul><li>Asynchronous initiatives that result in bolt-ons that last only as long as the squeaking. </li></ul></ul><ul><ul><ul><li>CMMI provides a consistent, enduring framework that can accommodate new initiatives </li></ul></ul></ul><ul><ul><ul><li>CMMI integrates well with current best practices, process improvement, or quality management strategies (ISO-9001, PMBOK, Lean Six Sigma, etc.) </li></ul></ul></ul>C M M I
    4. 4. History/Relationship of CMMI Models
    5. 5. Capability Maturity Model Integration - Current <ul><li>Multiple models , based on disciplines addressed </li></ul><ul><ul><li>CMMI - ACQ : Acquisition </li></ul></ul><ul><ul><li>CMMI - DEV : Systems Engineering </li></ul></ul><ul><ul><li>CMMI - SVC : Technical Support Services </li></ul></ul><ul><li>CMMI V1.2 incorporates lessons learned from using other standards and models (Software CMM, EIA-731, IEEE-12207) </li></ul><ul><li>Developed at the DoD-sponsored Software Engineering Institute (SEI) </li></ul><ul><ul><li>CMMI-ACQ in draft, expect release in 2007 </li></ul></ul><ul><ul><li>CMMI-SVC in development, expect release in 2007 </li></ul></ul><ul><ul><li>Models and information at http://www.sei.cmu.edu/cmmi/ </li></ul></ul>C M M I
    6. 6. CMMI For Acquisition Organizations (CMMI-ACQ) <ul><li>CMMI-ACQ is being developed as a joint effort between General Motors and the Software Engineering Institute </li></ul><ul><li>Provides process improvement guidance for organizations engaged in acquisition </li></ul><ul><li>“Adopting CMMI for Acquisition Organizations: A Preliminary Report” published in June 2006 </li></ul><ul><ul><li>Contains the draft CMMI-ACQ model </li></ul></ul><ul><li>Model will be piloted and further developed before official acceptance by Government and industry </li></ul><ul><li>Based on CMMI V1.2 architecture and model framework </li></ul><ul><li>SEI developing CMMI V1.2 for Acquisition Organizations, Development Organizations, and Services Organizations </li></ul>
    7. 7. CMMI-ACQ Process Areas (22 process areas) <ul><li>Acquisition Management (AM) </li></ul><ul><li>Acquisition Requirement Development (ARD) </li></ul><ul><li>Acquisition Technical Solution (ATS) </li></ul><ul><li>Acquisition Validation (AVAL) </li></ul><ul><li>Acquisition Verification (AVER) </li></ul><ul><li>Causal Analysis and Resolution (CAR) </li></ul><ul><li>Configuration Management (CM) </li></ul><ul><li>Decision Analysis and Resolution (DAR) </li></ul><ul><li>Integrated Project Management (IPM) </li></ul><ul><li>Measurement and Analysis (MA) </li></ul><ul><li>Organization Innovation and Deployment (OID) </li></ul><ul><li>Organization Process Definition (OPD) </li></ul><ul><li>Organization Process Focus (OPF) </li></ul><ul><li>Organization Process Performance (OPP) </li></ul><ul><li>Organizational Training (OT) </li></ul><ul><li>Project Monitoring and Control (PMC) </li></ul><ul><li>Project Planning (PP) </li></ul><ul><li>Process and Product Quality Assurance (PPQA) </li></ul><ul><li>Quantitative Project Management (QPM) </li></ul><ul><li>Requirement Management (RM) </li></ul><ul><li>Risk Management (RSKM) </li></ul><ul><li>Solicitation and Supplier Agreement Development (SSAD) </li></ul>
    8. 8. CMMI-DEV Process Areas (22 process areas) <ul><li>Causal Analysis and Resolution (CAR) </li></ul><ul><li>Configuration Management (CM) </li></ul><ul><li>Decision Analysis and Resolution (DAR) </li></ul><ul><li>Integrated Project Management + Integrated Process and Product Development (IPM + IPPD) </li></ul><ul><li>Measurement and Analysis (MA) </li></ul><ul><li>Organization Innovation and Deployment (OID) </li></ul><ul><li>Organization Process Definition + IPPD (OPD + IPPD) </li></ul><ul><li>Organization Process Focus (OPF) </li></ul><ul><li>Organization Process Performance (OPP) </li></ul><ul><li>Organizational Training (OT) </li></ul><ul><li>Product Integration (PI) </li></ul><ul><li>Project Monitoring and Control (PMC) </li></ul><ul><li>Project Planning (PP) </li></ul><ul><li>Process and Product Quality Assurance (PPQA) </li></ul><ul><li>Quantitative Project Management (QPM) </li></ul><ul><li>Requirements Development (RD) </li></ul><ul><li>Requirement Management (RM) </li></ul><ul><li>Risk Management (RSKM) </li></ul><ul><li>Supplier Agreement Management (SAM) </li></ul><ul><li>Technical Solution (TS) </li></ul><ul><li>Validation (VAL) </li></ul><ul><li>Verification (VER) </li></ul>
    9. 9. MUTUALLY SUPPORTIVE CMMI MODELS
    10. 10. CMMI-ACQ Complements CMMI-DEV Process Areas Acquirer Developer Project Planning Decision Analysis & Resolution Risk Management Acquisition Strategy Development Strategy Acquisition Support Development Support Configuration Management Product & Process Quality Assurance Product Engineering Product Engineering Acquisition Requirements Development Requirements Development Define System User Needs Define System Architecture
    11. 11. CMMI DEV Staged Representation C M M I Level Focus Process Areas 5 Optimizing Continuous Process Improvement Organizational Innovation and Deployment Causal Analysis and Resolution 4 Quantitatively Managed Quantitative Management Organizational Process Performance Quantitative Project Management 3 Defined Process Standardization Requirements Development Technical Solution Product Integration Verification Validation Organizational Process Focus Organizational Process Definition (+ IPPD extras) Organizational Training Integrated Project Mgmt (+ IPPD extras) Risk Management Decision Analysis and Resolution Requirements Management Project Planning Project Monitoring and Control Supplier Agreement Management Measurement and Analysis Process and Product Quality Assurance Configuration Management 2 Managed Basic Project Management 1 Initial Quality Productivity Risk Rework
    12. 12. Level 1: the “Initial” Level Success depends on heroes <ul><li>Good performance is possible - but </li></ul><ul><li>Requirements often misunderstood, uncontrolled </li></ul><ul><li>Schedules and budgets frequently missed </li></ul><ul><li>Progress not measured </li></ul><ul><li>Product content not tracked or controlled </li></ul><ul><li>Engineering activities nonstandard, inconsistent </li></ul><ul><li>Teams not coordinated, not trained </li></ul><ul><li>Defects proliferate </li></ul>“ Schedules run everything” “ Processes limit my creativity” “ Processes don’t help my delivery schedule” “ Just send in the Tiger Team”
    13. 13. CMMI Level 2: the “Managed” Level - Establishing basic project management controls <ul><li>Baseline the product requirements </li></ul><ul><li>Estimate project parameters, </li></ul><ul><li>Develop plans and processes </li></ul><ul><li>Measure actual progress to enable timely corrective action </li></ul><ul><li>Measure for mgmt. info needs </li></ul><ul><li>Verify adherence of processes and products to requirements </li></ul><ul><li>Identify and control products, changes, problem reports </li></ul><ul><li>Select qualified suppliers / vendors; manage their activities </li></ul> DETERMINE REQUIREMENTS DOCUMENT PLANS TRACK PROGRESS CONTROL PRODUCTS <ul><li>7 Process Areas </li></ul><ul><li>Requirements Management (REQM) </li></ul><ul><li>Project Planning (PP) </li></ul><ul><li>Project Monitoring and Control (PMC) </li></ul><ul><li>Measurement & Analysis (M&A) </li></ul><ul><li>Process & Product Quality Assurance (PPQA) </li></ul><ul><li>Configuration Management (CM) </li></ul><ul><li>Supplier Agreement Management (SAM ) </li></ul>PROJECT MANAGEMENT 2
    14. 14. <ul><li>Clarify customer requirements </li></ul><ul><li>Solve design requirements; develop implementation processes </li></ul><ul><li>Assemble product components, deliver </li></ul><ul><li>Ensure products meet requirements </li></ul><ul><li>Ensure products fulfill intended use </li></ul><ul><li>Analyze decisions systematically </li></ul><ul><li>Follow integrated, defined processes </li></ul><ul><li>Identify and control potential problems </li></ul><ul><li>Establish org. responsibility for PI </li></ul><ul><li>Define the org’s best practices </li></ul><ul><li>Develop skills and knowledge </li></ul>CMMI Level 3: the “Defined” Level - Standardizing the organization’s process ENGINEER THE PRODUCT MANAGE THE PROJECT PROVIDE ORG. INFRASTRUCTURE <ul><li>11 Process Areas* </li></ul><ul><li>Requirements Developmt (RD) </li></ul><ul><li>Technical Solution (TS) </li></ul><ul><li>Product Integration (PI) </li></ul><ul><li>Verification (Ver) </li></ul><ul><li>Validation (Val) </li></ul><ul><li>Decision Analysis & Resolution (DAR) </li></ul><ul><li>Integrated Project Mgmt (IPM) </li></ul><ul><li>Risk Management (RSKM) </li></ul><ul><li>Org. Process Focus (OPF) </li></ul><ul><li>Org. Process Definition (OPD) </li></ul><ul><li>Org. Training (OT) </li></ul>*SE/SW model PROJECT MANAGEMENT 2 ORGANIZATIONAL PROCESSES 3
    15. 15. CMMI Higher Maturity Level Concepts <ul><li>Statistically manage the project’s processes and sub-processes </li></ul><ul><li>Understand process performance; quantitatively manage the organization’s projects </li></ul>MANAGE PROJECTS QUANTITATIVELY MANAGE THE ORGANIZATION QUANTITATIVELY <ul><li>Level 4 Process Areas </li></ul><ul><li>Quantitative Project Management (QPM) </li></ul><ul><li>Organizational Process Performance (OPP) </li></ul>CONTINUOUS IMPROVEMENT 5 <ul><li>Identify and eliminate the cause of defects early </li></ul><ul><li>Identify and deploy new tools and process improvements to meet needs and business objectives </li></ul> OPTIMIZE PERFORMANCE ADOPT IMPROVEMENTS <ul><li>Level 5 Process Areas </li></ul><ul><li>Causal Analysis and Resolution (CAR) </li></ul><ul><li>Organizational Innovation and Deployment (OID) </li></ul>PROJECT MANAGEMENT 2 ORGANIZATIONAL PROCESSES 3 QUANTITATIVE MANAGEMENT 4
    16. 16. Sample Level 1 Organization few processes in place Top Management Middle Management Dept. B The Organization Dept. A Dept. C Div. BB Div. AA Project 4 Project 3 Projects Processes Project 1 Project 2
    17. 17. Sample Level 2 Organization many processes in place; but they are project-specific Top Management Middle Management Dept. B The Organization Dept. A Dept. C Div. BB Div. AA Project 4 Project 3 Projects Processes Project 1 Project 2
    18. 18. Sample Level 3 Organization processes based on organization’s Process Asset Library (PAL) Div. AA The Organization Dept. A Dept. C Div. BB Projects Processes Project 1 Project 2 Dept. B Project 3 Project 4 SEPO Process Asset Library Approved life cycles Standard processes Tailoring guidelines Process database Related documents
    19. 19. Implementation Strategies at SSC San Diego <ul><li>Project Management Guide (Center wide implementation) </li></ul><ul><ul><li>Based on the Project Management Body of Knowledge from the Project Mgmt Institute </li></ul></ul><ul><ul><li>Establishes core Project Mgmt competencies as a basis for sound Project Mgmt, and a springboard for further process improvement (CMMI) </li></ul></ul><ul><li>Lean Six Sigma (Center wide implementation) </li></ul><ul><ul><li>Integrates Lean Manufacturing with Six Sigma statistical process control </li></ul></ul><ul><ul><li>Provides a mechanism for implementing process improvement to eliminate waste and maximize performance </li></ul></ul><ul><li>Top Ten Best Practices (Codes 240 and 270) </li></ul><ul><ul><li>Based upon the CMMI </li></ul></ul><ul><ul><li>Identifies best practices that are deemed essential for implementation within the organization (department) </li></ul></ul><ul><ul><li>THESE PROCESS IMPROVEMENT INITIATIVES ARE COMPLEMENTARY, AND DO NOT CONFLICT </li></ul></ul>
    20. 20. Summary <ul><li>CMMI-ACQ is being piloted </li></ul><ul><li>Complements Developer CMMI (CMMI-DEV v1.2) which has been released </li></ul><ul><li>Follows the CMMI architecture </li></ul><ul><li>Process Areas very similar to CMMI SW/SE with emphasis on the acquirers role </li></ul><ul><li>Can be adopted by acquisition commands (SPAWAR, NAVAIR, NAVSEA) </li></ul>

    ×