Software Project Management and Support - Practical Support for CMMI -SW Project Documentation: Using IEEE Software Engineering Standards John Walz The Sutton Group IEEE Computer Society Standards Activities Board and Awards Committee member APEGGA Professional Development seminars Edmonton, Alberta, Canada 20-Apr-06 2006 John Walz 1 1
John Walz Sr. Consultant, The Sutton Group Software / CMMI Retired Lucent / AT&T Sr. Member IEEE, Standards Assoc. Secretary, IEEE Computer Standards Activity Board Vice-Chair Planning, IEEE Software & Systems Standards Committee Secretary TL 9000 SIG Sr. Member ASQ Blog Author, ASQ Sarbanes-Oxley
Software Project Management & Support Objectives People Processes Standards / Methods Quality Productivity Risk Reduction Certifications Sftw Prj Mgr - CSPM -QAI Sftw Prj Mgr - SwPM -SQI Project Mgmt Professional -PMI Sftw Dev Prof - CSDP -IEEE Sftw Quality Engr - CSQE -ASQ Training 2006 John Walz 3 3
Audience Software Project Managers Software Engineering Professionals Software Engineering Managers CMMI Organizations seeking to satisfy documentation requirements for Levels 2 & 3 of Capability Maturity Model Integrated for Software (CMMI -SW) 2006 John Walz 4 4
Overview Problem Statement Sftw Engr organizations face pressures and risks of missed deliveries and cost overruns Proposed Solution Organizations using CMMI -SW model, report significant reductions in missed deliveries and cost overruns Good news CMMI -SW is free to use and flexible Bad news Organizational difficulties with CMMI -SW implementation and assessments 2006 John Walz 5 5
Software Project Management & Support Objectives People Processes Standards / Methods Life Cycle Models Project Management Support 2006 John Walz 6 6
Processes Life Cycle Models Software Life Cycle Processes -IS 12207 CMMI-SW Framework Project Management Project Planning (PP) Project Monitoring and Control (PMC) Risk Management (RSKM) Support Configuration Mgmt (CM) Process & Product Quality Assurance (PPQA) 2006 John Walz 7 7
What is CMMI -SW? CMMI is a Goal-oriented process model Framework for reliable and consistent assessments Mechanism for identifying & adopting best practices Lessons learned by high maturity organizations CMMI is NOT a Prescription Standard Methodology Reference: CMMI -SW, v1.1, Carnegie Mellon University, Software Engineering Institute, Pittsburgh, PA, 2002 2006 John Walz 8 8
CMMI Structure Maturity Levels MLx Process Area 1 Process Area 2 Process Area n PA n Specific Goals SGx Generic Goals GGx Specific Practices SPx.y Capability Levels CLx Generic Practices GPx.y 2006 John Walz 9 9
Maturity Level (ML) 5 Optimizing CMMI -SW Process Areas Process Area (PA) Name Organizational Innovation and Deployment Causal Analysis and Resolution #Practices GP/SP 19 17 4 Quant Managed Organizational Process Performance Quantitative Project Management 17 20 3 Defined 2 Managed Requirements Development Technical Solution Product Integration Verification/Validation Organizational Process Focus Organizational Process Definition Organizational Training Integrated Project Management Risk Management Requirements Management Project Planning Project Monitoring and Control Process and Product Quality Assurance Configuration Management Supplier Agreement Management Measurement and Analysis 20 21 21 20 19 17 19 20 19 15 24 20 14 17 17 18 Documentation Scope
Organization Institutionalization Generic Practices 2.1 to 3.2 2.1 Adhering to organizational policies 2.2 Following established plans and process descriptions 2.3 Providing adequate resources 2.4 Assigning responsibility and authority for performing the process 2.5 Training the people performing and supporting the process 2.6 Placing work products under appropriate configuration management levels 2.7 Identifying and involving relevant stakeholders 2.8 Monitoring process performance against performance plans and taking corrective actions are when required 2.9 Evaluating the process, its work products, and its services for adherence to the process descriptions, objectives, and standards, and addressing noncompliance issues 2.10 Reviewing all process activities, status, and results with higher level management, and taking corrective action when required 3. Addressing all items that institutionalize a Managed process 3.1 Establishing the description of the defined process for the project or organizational unit 3.2 Deriving work products, measures, and improvement information from information collected from the planning and performance of defined processes Addressing all items that institutionalize a Defined process 2006 John Walz 11 11
Work Product / Artifact CMMI : any artifact produced by a process Include files, documents, parts of the product, services, processes, specifications, and invoices, etc. Scheduled by Project Managers Stored in Configuration Management Systems Tested for Quality Used & shared by project staff members Assessed for Organizational Capability or Maturity 2006 John Walz 12 12
Problem Details Difficulties CMMI -SW creates many Work Products or Artifacts during the Software Life Cycle and these are inputs to the Assessment Artifact Problem Which Artifact? What is the Artifact content and format? How to convince the organization to use our standard Artifact? Artifact Approaches Mandate using existing Artifacts from best company s project Invent and design your own Artifacts Benchmark & borrow Artifacts from the industry best company Borrow Artifacts from Standards developed by the industry best 2006 John Walz 13 13
Software Project Management & Support Objectives People Processes Standards / Methods SoftWare Engineering Body Of Knowledge (SWEBOK) Software Engineering Standards 2006 John Walz 14 14
What are IEEE Software Engr. Standards? Represent industry best practices having been developed by domain experts with broad expert consensus. Specify content Provide detailed procedure explanations and offer section by section guidance on building the necessary documentation with no recommendation of exact techniques or formats Used as tools to help in the painful process of self-documentation Specify the minimum required contents for each CMMI support document 2006 John Walz 15 15
Value of Standards In a complex, multidimensional trade space of solutions... A standard is a Name for an otherwise fuzzy concept a standard gives a name to a bounded region. It defines some characteristics that a buyer can count on. What is testing? Sftw Engr needs standards to assign names to practices or collections of practices. This enables communication between Buyer and Seller Standards represent the minimum level of responsible practice Jim Moore, 2004-03 CSEE&T Panel 7 2006 John Walz 16 16
8 Steps to Success In CMMI -Compliant Process Engineering Practical Support for CMMI -SW Project Documentation: Using IEEE Software Engineering Standards 1 Understand your business processes 2 Look to the CMMI SM for Process Completeness 3 Look to Framework Standards for Life Cycle Definition 4 Look to Supporting Standards for Process Detail 5 Build or Refine Your Process Architecture 6 Execute Your Processes 7 Measure Your Results - Modify Processes as Necessary 8 Confirm Your Status With Independent Appraisals 3 3 3 3 16th Annual Systems and Software Technology Conference Track 6, IEEE Sponsored Track 20 April 2004 Copyright 2004, Paul R. Croll, All rights reserved 2006 John Walz 17 17
In Other Words Using IEEE Software Engineering Standards to: Define software engineering (SE) processes Perform software engineering gap analyses Improve existing SE processes Ensure CMMI -SW Level 2 & 3 conformance 2006 John Walz 18 18
The CMMI and IEEE SE Standards The CMMI is a compendium of software engineering practices, which act as the motivator for the continuous evolution of improved software engineering processes IEEE Standards can be used to provide the basic beginning framework for software process improvement 2006 John Walz 19 19
CMMI -SW Level 2 & 3 Comparison to IEEE SE Standards Level 2 CMMI-SW PA IEEE Standards Requirements Management Project Planning Project Monitoring and Control Process and Product Quality Assurance Configuration Management Supplier Agreement Management Measurement and Analysis IEEE Std 830 Practice for Software Requirements Specifications IEEE Std 1058 Software Project Management Plans; IEEE Std 1490 PMBOK IEEE Std 1058 Software Project Management Plans IEEE Std 730 Software Quality Assurance IEEE Std 828 Software Configuration Management Plans IEEE Std 1062 Practice for Software Acquisition IEEE Std 1045 Software Productivity Metrics
CMMI -SW Level 2 & 3 Comparison to IEEE SE Standards Level 3 CMMI-SW PA IEEE Standards Technical Solution Validation IEEE 1016 Software Design Descriptions IEEE 1063 Sftw. User Documentation; IEEE 1471 Arch. Desc. of Sftw. Syst. IEEE 1028 Software Reviews Verification; Validation Project Planning; Project Monitoring & Control; Integrated Product Management Project Planning; Project Monitoring & Control Risk Management IEEE 829 - Software Test Documentation IEEE 1490 - Project Management Body of Knowledge IEEE 1058 Software Project Management Plans IEEE 1540 - Risk Management............
CMMI Model Components Specific Goals Specific Practices Generic Goals Generic Practices Typical work products Sub-practices Notes References Required Expected CMMI / IEEE SE Book Informative CMMI -SW Level 2 & 3 Support 2006 John Walz 22 22
Expert Guidance http://www.wiley.com/wileycda/wileytitle/productcd-0471738492.html
Book Chapters Introduction and Overview CMMI -SW Summary Organization Institutionalization ML 2 & 3 GP Implementation Guidance CMMI -SW Level 2 Support CMMI -SW Level 3 Support CMMI -SW Level 2 for Small Projects CMMI -SW Level 2 & 3 Comparison to IEEE SE Standards Software Process Work Products (102) Software Process Work Products Templates (38) 2006 John Walz 24 24
Artifact Creation Example PA: Requirements Management 2006 John Walz 25 25
PA: Requirements Management Goals and Practices CMMI -SW Level 2 & 3 Support Specific and Generic Goals/Practices and Typical Work Products SG1 Manage Requirements SP1.1 Obtain an understanding of requirements List of criteria for distinguishing appropriate requirements providers Criteria for evaluation and acceptance of requirements Results of analyses against criteria An agreed-to set of requirements SP1.2 Obtain commitments to requirements Requirements impact assessments Documented commitments to requirements and requirements changes SP1.3 Manage requirements changes Requirements status Requirements database Requirements decision database SP1.4 Maintain bi-directional traceability of requirements Requirements traceability matrix Requirements tracking system SP1.5 Identify inconsistencies between project work and requirements Documentation of inconsistencies including sources, conditions, and rationale Corrective actions Book Plan or Artifact Requirements Management Plan Requirements Management Plan Requirements Specification Review Requirements Specification Requirements Specification Signed SRS or approved change requests Requirements database, baseline change request Requirements database Requirements database Requirements Specification and database Requirements database Requirements Specification Review Revised SRS Specific and Generic Goals/Practices and Typical Work Products GG2 Institutionalize a Managed Process GP2.1 Establish an organizational policy Organizational policy supporting requirements management GP2.2 Plan the process Documentation in support of the requirements management planning process GP2.3 Provide resources Identification of resources used in support of requirements identification and management GP2.4 Assign responsibility Description of individuals responsible for requirements management activities GP2.5 Train people Identify how individuals will be provided the appropriate training GP 2.6 Manage configurations Description of how requirements and all associated artifacts are placed under configuration management GP 2.7 Identify relevant stakeholders Identify who is responsible for the definition and management of requirements Book Plan or Artifact Organizational policy Requirements management plan Project plan, requirements management plan Requirements management plan, project plan, or organizational policy Training plan or project plan Configuration management plan CCB meeting minutes, traceability reporting, and requirements reviews
PA Requirements Management Artifact Software Requirements Management Plan IEEE Std 830-1998, IEEE Recommended Practice for Software Requirements Specifications. Outlines the requirements for what comprises a good Software Requirements Specification (SRS): Establishes basis for agreement between customers and suppliers on what the software product is to do Reduces the development effort Provides a basis for estimating costs and schedules Provides a baseline for validation and verification Facilitates transfer Serves as a basis for enhancement 2006 John Walz 27 27
Software Requirements Management Plan Document Outline Table of Contents Revision Sheet 1.0 Introduction 2.0 Purpose 2.1 Scope 2.2 Definitions 2.3 Goals 3.0 References 3.1 Key Acronyms 3.2 Key Terms 3.3 Key References 4.0 Management 4.1 Organization 4.2 Tasks 4.3 Responsibilities 4.3.1 Management 4.3.2 Program Manager 4.3.3 Project Lead 4.3.4 Team Members 4.3.5 Customer 5.0 Software Requirements Management Overview 5.1 Software Requirements Modeling Techniques 5.1.1 Functional Analysis 5.1.2 Object-Oriented Analysis 5.1.3 Dynamic Analysis 5.2 Software Requirements Management Process 5.2.1 Requirements Elicitation 5.2.2 Requirements Analysis 5.2.3 Requirements Specification 5.3 Characteristics of a Good SRS 5.3.1 Correct 5.3.2 Nonambiguous 5.3.3 Complete 5.3.4 Verifiable 5.3.5 Consistent 5.3.6 Modifiable 5.3.7 Traceable 5.3.8 Usable During Operation and Maintenance 6.0 Standards and Practices 7.0 Software Measurement and Metrics 8.0 Verification and Validation 9.0 Software Configuration Management 10.0 Developing a Software Requirements Specification Appendix A // Project Software Requirements Specification Template Appendix B// Requirements Traceability Matrix 2006 John Walz 28 28
Software Requirements Management Plan Document Guidance Purpose -.. Scope -.. Definitions -.. Goals -.. Management Organization -.. Tasks -.. Responsibilities -.. Software Requirements Management -.. Software Requirements Modeling Techniques -...... 2006 John Walz 29 Provides section-by-section guidance in support of the document creation 29
Software Requirements Management Plan Document Template Purpose -.. Scope -.. Definitions -.. Goals -.. Management Organization -.. Tasks -.. Responsibilities -.. Software Requirements Management -.. Software Requirements Modeling Techniques -...... Provides section-by-section fill-in the blanks support of the document creation Book has integrated set of 38 deployable document templates on CD-ROM
Understand your business processes Look to the CMMI for Process Completeness Use CMMI building blocks for higher maturity set at each stage Look to Framework Standards for Life Cycle Definition IEEE 12207 Look to Supporting Standards for Process Detail Use IEEE standards to perform a gap analysis In Conclusion Make a plan. Then follow the plan. - Watts Humphrey 2006 John Walz 31 Build or Refine Your Process Architecture Fix timelines to produce goal driven process improvement Define your processes in outline form Redefine your processes Use IEEE standards to develop your baseline process documentation Execute Your Processes Measure Your Results - Modify Processes as Necessary Perform self-audit using CMMI PAs Readjust processes/plans based upon audit results. Confirm Your Status With Independent Appraisals 31
IEEE Software Engineering Standards Collection Over 40 of the most current IEEE software engineering standards on CD-ROM ISBN 0-7381-3757-X, Sep03, Catalog # ST01121, $370.00 Members / $465.00 List 2006 John Walz 32 32
Wiley and IEEE Computer Society Press Book Series Software Engineering, Vol. 1 & 2, The Development Process, 3rd Edition by Richard H. Thayer, Mark J. Christensen Trustworthy Systems Through Quantitative Software Engineering by Lawrence Bernstein, C. M. Yuhas Software Quality Engineering: Testing, Quality Assurance, and Quantifiable Improvement by Jeff Tian Jumpstart CMM/CMMI Software Process Improvements: Using IEEE Software Engineering Standards by Susan K. Land Information Security : A Strategic Approach by Vincent LeVeque The Road Map to Software Engineering: A Standards-Based Guide by James W. Moore Practical Support for CMMI-SW Software Project Documentation: Using IEEE Software Engineering Standards by Susan K. Land, John W. Walz www.wiley.com/wileycda/section/id-11028.html
Questions? 2006 John Walz 34 34
Mind Map
Backup slides
Software Engineering Body of Knowledge (SWEBOK) SWEBOK Area CMMI -SW Process Areas Requirements... Design... Construction... Testing... Maintenance... Configuration Management... Engineering Management... Engineering Process... Tools and Methods... Quality... ISO/IEC TR 19759 2006 John Walz 37 37
Why Use IEEE Standards in Support of Process Improvement? IEEE Standards can be used as tools to help in the painful process of self-documentation. Many of the standards provide detailed procedure explanations, e.g., section by section guidance on building the necessary documentation. Most importantly, they provide the best practice as defined by those from the software development industry who sit on the panels of reviewers. They can be used to: Define software engineering (SE) processes. Ensure CMM/CMMI-SW Level 2 compliance. Improve existing SE processes. Perform software engineering gap analyses. 2006 John Walz 38 38
Initiate Diagnose Establish Act Learn Implementation Guidance Serves a road map for software process implementation (e.g. CMMI) and improvement
Implementation Guidance IDEAL Implementation Initiate Define and Train the Process Team Leverage the expertise contained in the IEEE Software and Systems Engineering Standards. Diagnose Initial process baseline, Gap Analysis Set Realistic Goals Establish Fix Timelines for Goal driven process improvement, Develop Action Plans Act Baseline and Implement Processes changes Define your processes in outline form; Document templates, Staff training, Redefine your processes./ Use IEEE standards to change your baseline process documentation Learn Perform Gap Analysis / self-audit using CMMI PAs Re-plan Readjust processes/plans based upon audit results 2006 John Walz 40 40
Standards Support of Continuous Process Improvement Training Work Instructions Materials PAL P&P Process Baseline Process Improvement Plan Training Action Materials Plans Training Materials IEEE/EIA 12207 ISO/IEC 15288 Management Plans Process Deployment Continuous Process Improvement Framework Standards Supporting Standards Standards-Based Knowledge Products IEEE 830 IEEE 830 IEEE 830 Training Materials Performance Tailoring Validation Training Tailoring Materials Records Training Findings Materials IEEE Standards- Based Training Evaluation 2006 John Walz 41 Evaluation Reports 41
Strategy: Use the CMMI as a Guide to Process Completeness Determine if essential elements of your processes are missing or incomplete Process Management Engineering Organizational Process Focus Requirements Management Organizational Process Definition Requirements Development Organizational Training Technical Solution Organizational Process Product Integration Performance Verification Organizational Innovation and Deployment Validation Project Management Support Project Planning Configuration Management Project Monitoring and Control Process and Product Quality Assurance Supplier Agreement Management Measurement and Analysis Integrated Project Management for IPPD Decision Analysis and Resolution Risk Management Organizational Environment for Integration Integrated Teaming Causal Analysis and Resolution Integrated Supplier Management Quantitative Project Management 42 2006 John Walz 42