Software Project Management and Support

(1)

-

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

(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

•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

•Quality

•Productivity

•Risk Reduction

(4)

Audience

CMMI

• Software Project Managers

• Software Engineering Professionals

• Software Engineering Managers

• Organizations seeking to satisfy

documentation requirements for Levels 2 & 3 of Capability Maturity Model Integrated for

Software (CMMI

^®

-SW)

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

(6)

6

Software Project Management & Support

• Objectives

• People

• Processes

• Standards / Methods

•Life Cycle Models

•Project Management

•Support

(7)

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)

(8)

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, 2002

(9)

CMMI ^® Structure

Generic Practices Generic Goals

Process Area 2

Process Area 1 Process Area n

Specific Goals

Specific Practices

Capability Levels Generic Practices Generic Goals

Process Area 2

Process Area 1 Process Area n

Specific Goals

Specific Practices

Capability Levels

SPx.y GPx.y

SGx GGx

PA n Maturity Levels MLx

CLx

(10)

Maturity Level (ML)

Process Area (PA) Name

Process Area (PA) Name #Practices

GP/SP

#Practices

GP/SP 5

Optimizing

Organizational Innovation and Deployment Causal Analysis and Resolution

19 17

4

Quant Managed

Organizational Process Performance Quantitative Project Management

17 20

3 Defined

Requirements Development Technical Solution

Product Integration Verification/Validation

Organizational Process Focus Organizational Process Definition Organizational Training

Integrated Project Management Risk Management

20 21 21 20 19 17 19 20 19

2 Managed

Requirements Management Project Planning

Project Monitoring and Control

Process and Product Quality Assurance Configuration Management

Supplier Agreement Management Measurement and Analysis

15 24 20 14 17 17 18

CMMI ^® -SW Process Areas

Documentation Scope

(11)

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

(12)

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

(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

(14)

14

Software Project Management & Support

• Objectives

• People

• Processes

• Standards / Methods

•SoftWare Engineering Body Of Knowledge (SWEBOK)

•Software Engineering Standards

(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

(16)

16

Value of Standards

• 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

A standard is a

A standard is a Name Name for an for an otherwise fuzzy concept otherwise fuzzy concept

In a complex, multidimensional trade space of solutions ...

… a standard gives a name to a bounded region.

It defines some characteristics that a buyer can count on.

(17)

8 Steps to Success In CMMI

^®

-Compliant Process Engineering

1 Understand your business

processes

2 Look to the CMMI^SM for

Process Completeness

3 _Framework^{Look to}

Standards for Life Cycle Definition

4 Supporting ^{Look to} Standards for Process Detail

5 Build or Refine Your Process

Architecture

6 Execute Your

Processes 7 Measure Your Results - Modify

Processes as Necessary

3 3

8 Confirm Your Status With Independent

Appraisals

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

(18)

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

(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

(20)

CMMI

^®

-SW Level 2 & 3 Comparison to IEEE SE Standards

Level 2 CMMI-SW PA

Level 2 CMMI-SW PA IEEE StandardsIEEE Standards

Requirements Management IEEE Std 830 – Practice for Software Requirements Specifications

Project Planning IEEE Std 1058 – Software Project Management Plans;

IEEE Std 1490 – PMBOK

Project Monitoring and Control IEEE Std 1058 – Software Project Management Plans

Process and Product Quality Assurance

IEEE Std 730 – Software Quality Assurance

Configuration Management IEEE Std 828 – Software Configuration Management Plans

Supplier Agreement Management IEEE Std 1062 – Practice for Software Acquisition

Measurement and Analysis IEEE Std 1045 – Software Productivity Metrics

(21)

CMMI

^®

-SW Level 2 & 3 Comparison to IEEE SE Standards

Level 3 CMMI-SW PA

Level 3 CMMI-SW PA IEEE StandardsIEEE Standards

Technical Solution IEEE 1016 – Software Design Descriptions IEEE 1063 – Sftw. User Documentation;

IEEE 1471 – Arch. Desc. of Sftw. Syst.

Validation IEEE 1028 – Software Reviews

Verification;

Validation

IEEE 829 - Software Test Documentation

Project Planning;

Project Monitoring & Control;

Integrated Product Management

IEEE 1490 - Project Management Body of Knowledge

Project Planning;

Project Monitoring & Control

IEEE 1058 – Software Project Management Plans

Risk Management IEEE 1540 - Risk Management

(22)

22

CMMI ^® Model Components

• Specific Goals

• Specific Practices

• Generic Goals

• Generic Practices

– Typical work products – Sub-practices

– Notes

– References

Required

Expected

Informative

CMMI / IEEE SE Book

• Specific Goals

• Specific Practices

• Generic Practices

– Typical work products – Sub-practices

– Notes

– References

CMMI^®-SW Level 2 & 3 Support

(23)

Expert

Guidance

(24)

Book Chapters

24

• 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)

(25)

Artifact Creation Example

PA: Requirements Management

(26)

PA: Requirements Management Goals and Practices

CMMI

^®

-SW Level 2 & 3 Support

Specific and Generic Goals/Practices and Typical Work Products

Book Plan or Artifact GG2 – Institutionalize a Managed Process

GP2.1 – Establish an organizational policy Organizational policy supporting requirements management

Organizational policy GP2.2 – Plan the process

Documentation in support of the requirements management planning process

Requirements management plan GP2.3 – Provide resources

Identification of resources used in support of requirements identification and management

Project plan, requirements management plan GP2.4 – Assign responsibility

Description of individuals responsible for requirements management activities

Requirements management plan, project plan, or organizational policy GP2.5 – Train people

Identify how individuals will be provided the appropriate training

Training plan or project plan

GP 2.6 – Manage configurations Description of how requirements and all associated artifacts are placed under configuration management

Configuration management plan GP 2.7 – Identify relevant stakeholders

Identify who is responsible for the definition and management of requirements

CCB meeting minutes, traceability reporting, and requirements reviews

Specific and Generic Goals/Practices and Typical Work Products

Book Plan or Artifact SG1 – Manage Requirements

SP1.1 – Obtain an understanding of requirements

List of criteria for distinguishing appropriate requirements providers

Requirements Management Plan Criteria for evaluation and acceptance

of requirements

Requirements Management Plan Results of analyses against criteria Requirements Specification Review An agreed-to set of requirements Requirements Specification SP1.2 – Obtain commitments to

requirements

Requirements impact assessments Requirements Specification Documented commitments to

requirements and requirements changes

Signed SRS or approved change requests

SP1.3 – Manage requirements changes

Requirements status Requirements database, baseline change request

Requirements database Requirements database Requirements decision database Requirements database SP1.4 – Maintain bi-directional

traceability of requirements

Requirements traceability matrix Requirements Specification and database

Requirements tracking system Requirements database SP1.5 – Identify inconsistencies

between project work and requirements Documentation of inconsistencies including sources, conditions, and rationale

Requirements Specification Review

Corrective actions Revised SRS

(27)

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

(28)

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

(29)

Software Requirements Management Plan Document Guidance

• Purpose - ………..

• Scope - ………..

• Definitions - ………..

• Goals - ………..

• Management Organization - ………..

• Tasks - ………..

• Responsibilities - ………..

• Software Requirements Management -

………..

• Software Requirements Modeling Techniques -

………..

• ………..

Provides section-by-section guidance in support of the document creation

(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)

In Conclusion

• 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

• 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 Make a plan. Then follow the plan.

Make a plan. Then follow the plan.

(32)

32

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

(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)

34

Questions?

(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 19759

(38)

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.

(39)

Implementation Guidance

Initiate

Diagnose Establish

Act

Learn

Serves a road map for software process

(40)

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

(41)

Standards Support of Continuous Process Improvement

Training MaterialsWork Instructions

Process Baseline

Process Deployment Process Deployment

Framework Standards

Supporting Standards

Standards-Based Knowledge Products

Tailoring Validation

Performance

Training MaterialsTraining

Materials

Training Materials

Action Plans

Materials Training

MaterialsTailoring Records Training MaterialsFindings

Continuous Process Improvement

IEEE Standards-

Based Training

IEEE 830IEEE

830 IEEE 830 ISO/IEC 15288 IEEE/EIA

12207

Process Improvement

Plan

P&P PAL

Management Plans

Training MaterialsWork Instructions

Process Baseline

Process Deployment Process Deployment

Framework Standards

Supporting Standards

Standards-Based Knowledge Products

Tailoring Validation

Performance Performance

Materials Training MaterialsTraining

Materials

Training Materials

Action Plans Training Materials

Action Plans

Materials Training MaterialsTraining

Materials Training

MaterialsTailoring Records Training MaterialsTailoring

Records Training MaterialsTrainingFindings MaterialsFindings

Continuous Process Improvement

IEEE Standards-

Based Training

IEEE 830 IEEE

830IEEE 830 IEEE

830 IEEE 830 ISO/IEC 15288 IEEE/EIA

12207

Process Improvement

Plan

P&P P&P PAL

Management Plans

(42)

42

Strategy: Use the CMMI

^®

as a Guide to Process Completeness

Process Management Engineering

• Organizational Process Focus • Requirements Management

• Organizational Process Definition • Requirements Development

• Organizational Training • Technical Solution

• Organizational Process Performance

• Product Integration

• Verification

• Organizational Innovation and Deployment

• Validation

Project Management Support

• Project Planning • Configuration Management

• Project Monitoring and Control

• Supplier Agreement Management

• Process and Product Quality Assurance

• Measurement and Analysis

• Integrated Project Management for IPPD • Decision Analysis and Resolution

• Risk Management •

• Integrated Teaming • Causal Analysis and Resolution

• Quantitative Project Management Integrated Supplier Management

•

Organizational Environment for Integration

Determine if essential elements of your processes are missing or incomplete

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