Software Project Management and Support

© 2006 John Walz 11

Software Project Management and Support

-Practical Support for CMMI®-SW

Project Documentation: Using IEEE Software Engineering Standards

John WalzThe Sutton Group

IEEE Computer Society Standards Activities Board and Awards Committee member

APEGGA Professional Development seminars Edmonton, Alberta, Canada

20-Apr-06

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

•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

AudienceCMMI

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



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



• Objectives • People • Processes• Standards / Methods

•Life Cycle Models •Project Management •Support


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)


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


CMMI® Structure

Generic Practices

Generic Goals

Process Area 2Process Area 1 Process Area n

Specific Goals

Specific Practices Capability LevelsGeneric Practices

Generic Goals

Process Area 2Process Area 1 Process Area n

Specific Goals

Specific Practices Capability Levels

SPx.y GPx.y

SGx GGx

PA n

Maturity Levels MLx

CLx

Maturity Level(ML)

Maturity Level(ML)

Process Area (PA) NameProcess Area (PA) Name #PracticesGP/SP

#PracticesGP/SP

5Optimizing

Organizational Innovation and DeploymentCausal Analysis and Resolution

1917

4Quant Managed

Organizational Process PerformanceQuantitative Project Management

1720

3Defined

Requirements DevelopmentTechnical SolutionProduct IntegrationVerification/ValidationOrganizational Process FocusOrganizational Process DefinitionOrganizational TrainingIntegrated Project ManagementRisk Management

202121201917192019

2Managed

Requirements ManagementProject PlanningProject Monitoring and ControlProcess and Product Quality AssuranceConfiguration ManagementSupplier Agreement ManagementMeasurement and Analysis

15242014171718

CMMI®-SW Process Areas

DocumentationScope

© 2006 John Walz 1111

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 1212

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 1313

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 1414


• Objectives • People • Processes • Standards / Methods

•SoftWare Engineering Body Of Knowledge(SWEBOK)•Software Engineering Standards

© 2006 John Walz 1515

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 1616

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 NameName for an for an otherwise fuzzy conceptotherwise 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.

© 2006 John Walz 1717

8 Steps to Success In CMMI® -Compliant Process Engineering

1Understand

your business processes

2Look to the CMMISM for

Process Completeness

3Look to

Framework Standards for Life Cycle Definition

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

333

3

8 Confirm Your Status With Independent Appraisals

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

16th Annual Systems and Software Technology Conference – Track 6, IEEE Sponsored Track – 20 April 2004Copyright 2004, Paul R. Croll, All rights reserved

© 2006 John Walz 1818

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 1919

The CMMI® and IEEE SE Standards

The CMMI is a compendium of software engineering practices, which act as the motivator for the continuous evolutionof improved software engineering processes

IEEE Standards can be used to provide the basic beginning framework

for software process improvement

CMMI®-SW Level 2 & 3 Comparison to IEEE SE Standards

Level 2 CMMI-SW PALevel 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

CMMI®-SW Level 2 & 3 Comparison to IEEE SE Standards

Level 3 CMMI-SW PALevel 3 CMMI-SW PA IEEE StandardsIEEE Standards

Technical Solution IEEE 1016 – Software Design DescriptionsIEEE 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

. . .

. . .. . .. . .

© 2006 John Walz 2222

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

Expert Guidance

http://www.wiley.com/WileyCDA/WileyTitle/productCd-0471738492.html


Book Chapters

© 2006 John Walz 2424

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

Artifact Creation ExamplePA: Requirements Management

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

© 2006 John Walz 2727

PA – Requirements Management ArtifactSoftware 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 2828

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 2929

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

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

© 2006 John Walz 3131

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. - Watts Humphrey

Make a plan. Then follow the plan. - Watts Humphrey

© 2006 John Walz 3232

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

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

http://www.wiley.com/WileyCDA/Section/id-11028.html


© 2006 John Walz 3434

Questions?

Mind Map

Backup slides

© 2006 John Walz 3737

Software Engineering Body of Knowledge (SWEBOK)

SWEBOK® Area CMMI®-SW Process AreasRequirements . . .

Design . . . Construction . . .

Testing . . . Maintenance . . .

Configuration Management . . . Engineering Management . . .

Engineering Process . . . Tools and Methods . . .

Quality . . . ISO/IEC TR 19759

© 2006 John Walz 3838

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.

Implementation GuidanceInitiateDiagnoseEstablishActLearn

Serves a road map for software process implementation (e.g. CMMI) and improvement

© 2006 John Walz 4040

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 4141

Standards Support of Continuous Process Improvement

TrainingMaterials

WorkInstructions

Process Baseline

Process DeploymentProcess Deployment

Framework Standards

Supporting Standards

Standards-BasedKnowledge Products

Tailoring

Validation

Evaluation

Performance

TrainingMaterialsTrainingMaterials

TrainingMaterials

ActionPlans

TrainingMaterialsTrainingMaterials

TrainingMaterialsTailoringRecords

TrainingMaterialsFindings

ContinuousProcess

Improvement

IEEEStandards-

BasedTraining

IEEE830IEEE

830

IEEE830

ISO/IEC15288

IEEE/EIA12207

ProcessImprovement

Plan

P&P

PAL

ManagementPlans

EvaluationReports

TrainingMaterials

WorkInstructionsTrainingMaterials

WorkInstructions

Process Baseline

Process DeploymentProcess Deployment

Framework Standards

Supporting Standards

Standards-BasedKnowledge Products

Tailoring

Validation

Evaluation

Tailoring

Validation

Evaluation

PerformancePerformance

TrainingMaterialsTrainingMaterialsTrainingMaterialsTrainingMaterials

TrainingMaterials

ActionPlans

TrainingMaterials

ActionPlans

TrainingMaterialsTrainingMaterialsTrainingMaterialsTrainingMaterials



TrainingMaterialsFindingsTraining

MaterialsFindings

ContinuousProcess

Improvement

IEEEStandards-

BasedTraining

IEEE830

IEEE830IEEE

830IEEE830

IEEE830

ISO/IEC15288

IEEE/EIA12207

ProcessImprovement

Plan

P&PP&P

PAL

ManagementPlans

EvaluationReports

© 2006 John Walz 4242

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 andDeployment

• 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 ManagementIntegrated Supplier Management•

Organizational Environment for Integration

Determine if essential elements of your processes are missing orincomplete

Documents

Software Project Management and Support