Software Project Management and Support - Practical Support for CMMI -SW Project Documentation: Using IEEE Software Engineering Standards

Transcription

1 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 John Walz 1 1

2 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

3 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

4 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

5 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

6 Software Project Management & Support Objectives People Processes Standards / Methods Life Cycle Models Project Management Support 2006 John Walz 6 6

7 Processes Life Cycle Models Software Life Cycle Processes -IS 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

8 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, John Walz 8 8

9 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

10 Maturity Level (ML) 5 Optimizing CMMI -SW Process Areas Process Area (PA) Name Organizational Innovation and Deployment Causal Analysis and Resolution #Practices GP/SP Quant Managed Organizational Process Performance Quantitative Project Management 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 Documentation Scope

11 Organization Institutionalization Generic Practices 2.1 to 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

12 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

13 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

14 Software Project Management & Support Objectives People Processes Standards / Methods SoftWare Engineering Body Of Knowledge (SWEBOK) Software Engineering Standards 2006 John Walz 14 14

15 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

16 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, CSEE&T Panel John Walz 16 16

17 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 th 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

18 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

19 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

20 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

21 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 Software Test Documentation IEEE Project Management Body of Knowledge IEEE 1058 Software Project Management Plans IEEE Risk Management

22 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

23 Expert Guidance

24 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

25 Artifact Creation Example PA: Requirements Management 2006 John Walz 25 25

26 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

27 PA Requirements Management Artifact Software Requirements Management Plan IEEE Std , 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

28 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 Management Program Manager Project Lead Team Members Customer 5.0 Software Requirements Management Overview 5.1 Software Requirements Modeling Techniques Functional Analysis Object-Oriented Analysis Dynamic Analysis 5.2 Software Requirements Management Process Requirements Elicitation Requirements Analysis Requirements Specification 5.3 Characteristics of a Good SRS Correct Nonambiguous Complete Verifiable Consistent Modifiable Traceable 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

29 Software Requirements Management Plan Document Guidance Purpose -.. Scope -.. Definitions -.. Goals -.. Management Organization -.. Tasks -.. Responsibilities -.. Software Requirements Management -.. Software Requirements Modeling Techniques John Walz 29 Provides section-by-section guidance in support of the document creation 29

30 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

31 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 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

32 IEEE Software Engineering Standards Collection Over 40 of the most current IEEE software engineering standards on CD-ROM ISBN X, Sep03, Catalog # ST01121, $ Members / $ List 2006 John Walz 32 32

33 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

34 Questions? 2006 John Walz 34 34

35 Mind Map

36 Backup slides

37 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 John Walz 37 37

38 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 John Walz 38 38

39 Initiate Diagnose Establish Act Learn Implementation Guidance Serves a road map for software process implementation (e.g. CMMI) and improvement

40 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

41 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 ISO/IEC 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

42 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 John Walz 42