PRACTICAL SUPPORT FOR LEAN SIX SIGMA

SOFTWARE PROCESS DEFINITION

Using IEEE Software Engineering Standards

^ IEEE wftcomputer

society 4 IEEE

Press Operating Committee

Chair

Linda Shafer former Director, Software Quality Institute

The University of Texas at Austin

Editor-in-Chief

Alan Clements Professor

University of Teesside

Board Members

David Anderson, Principal Lecturer, University of Portsmouth Mark J. Christensen, Independent Consultant

James Conrad, Associate Professor, UNC Charlotte Michael G. Hinchley, Director, Software Engineering Laboratory, NASA Goddard Space Flight Center

Phillip Laplante, Associate Professor, Software Engineering, Penn State University Richard Thayer, Professor Emeritus, California State University, Sacramento

Donald F. Shafer, Chief Technology Officer, Athens Group, Inc. Janet Wilson, Product Manager, CS Books

IEEE Computer Society Publications The world-renowned IEEE Computer Society publishes, promotes, and distributes a wide variety of authoritative computer science and engineering texts. These books are available from most retail outlets. Visit the CS Store at http://computer.org/cspress for a list of products.

IEEE Computer Society / Wiley Partnership The IEEE Computer Society and Wiley partnership allows the CS Press authored book program to produce a number of exciting new titles in areas of computer sci-ence and engineering with a special focus on software engineering. IEEE Computer Society members continue to receive a 15% discount on these titles when pur-chased through Wiley or at wiley.com/ieeecs.

To submit questions about the program or send proposals e-mail j.wilson@com-puter.org. Telephone +1-714-821-8380. Additional information regarding the Computer Society authored book program can also be accessed from our web site at http://computer.org/cspress.

PRACTICAL SUPPORT FOR LEAN SIX SIGMA

SOFTWARE PROCESS DEFINITION

Using IEEE Software Engineering Standards

SUSAN K. LAND DOUGLAS B. SMITH

JOHN W. WALZ

^ IEEE «^computer

society

WILEY

A JOHN WILEY & SONS, INC., PUBLICATION

Copyright © 2008 by IEEE Computer Society. All rights reserved.

Published by John Wiley & Sons, Inc., Hoboken, New Jersey Published simultaneously in Canada.

No part of this publication may be reproduced, stored in a retrieval system or transmitted in any form or by any means, electronic, mechanical, photocopying, recording, scanning or otherwise, except as permitted under Section 107 or 108 of the 1976 United States Copyright Act, without either the prior written permission of the Publisher, or authorization through payment of the appropriate per-copy fee to the Copyright Clearance Center, Inc., 222 Rosewood Drive, Danvers, MA 01923, 978-750-8400, fax 978-646-8600, or on the web at www.copyright.com. Requests to the Publisher for permission should be addressed to the Permissions Department, John Wiley & Sons, Inc., 111 River Street, Hoboken, NJ 07030, (201) 748-6011, fax (201) 748-6008.

Limit of Liability/Disclaimer of Warranty: While the publisher and author have used their best efforts in preparing this book, they make no representation or warranties with respect to the accuracy or completeness of the contents of this book and specifically disclaim any implied warranties of merchantability or fitness for a particular purpose. No warranty may be created or extended by sales representatives or written sales materials. The advice and strategies contained herein may not be suitable for your situation. You should consult with a professional where appropriate. Neither the publisher nor author shall be liable for any loss of profit or any other commercial damages, including but not limited to special, incidental, consequential, or other damages.

For general information on our other products and services please contact our Customer Care Department within the U.S. at 877-762-2974, outside the U.S. at 317-572-3993 or fax 317-572-4002.

Wiley also publishes its books in a variety of electronic formats. Some content that appears in print, however, may not be available in electronic format.

Library of Congress Cataloging-in-Publication Data is available,

ISBN 978-0470-17080-9

Printed in the United States of America.

10 9 8 7 6 5 4 3 2 1

CONTENTS

Preface xiii

Acknowledgments xv

1. Introduction and Overview 1 Introduction 1 Stimulus for Lean Six Sigma 3 Using This Book 4

2. Standards and Software Process Improvement 7 What are Standards? 7

IEEE S2ESC Software and Systems Engineering Standards Committee 8 SWEBOK 9 IEEE 12207 12

Software Processes Must Exist Before They Can Be Redesigned 13 Software Engineering and Training 13 Software Engineering and Organizational Support 14 Charter Infrastructure 14 Establish Steering Committee and Process Group 14 Software Engineering Processes 15 Software Engineering Artifacts 15

3. 12207 Primary Life Cycle Processes 17 The IEEE 12207 Process Framework 17 Acquisition 20

Software Acquisition Plan 20 Software Acquisition Plan Document Guidance 21

v

vi CONTENTS

Concept of Operations 23 Concept of Operations (ConOps) Document Guidance 24 Decision Tree Analysis 27

Supply 30 Request for Proposal 30 Request for Proposal (RFP) Document Guidance 31 Joint Customer Technical Reviews 32 Software Project Management Plan 34 Software Project Management Plan Document Guidance 35

Development 38 System Requirements Analysis 40 System Requirements Specification 41 System Requirements Specification Document Guidance 42 Software Requirements Analysis 45 Software Requirements Specification 45 Software Requirements Specification Document Guidance 46 Software Design Document 48 Software Design Document Guidance 50 Interface Control Document 53 Interface Control Document Guidance 53

Operation 56 User's Manual 56 User's Manual Document Guidance 57

Maintenance 59 Transition Plan 59 Transition Plan Document Guidance 61

12207 Supporting Life Cycle Processes 67 IEEE 12207 Supporting Processes 67 Documentation 68

Configuration Management Record 68 Configuration Management 69

Software Configuration Management Plan 69 Software Configuration Management Plan Document Guidance 70

Quality Assurance 78 Software Quality Assurance Plan (SQAP) 78 Software Quality Assurance Plan Document Guidance 79

Verification 86 Inspections 87 Walk-throughs 91

Validation 93 Software Test Plan 94 Software Test Plan Document Guidance 95 System Test Plan 102 System Integration Test Plan 109

Joint Review 114 Technical Reviews 115 Management Reviews 117

CONTENTS vii

Audit 119 Audits 120 Software Measurement and Measures Plan 122 Software Measurement and Measures Plan Document Guidance 123

Problem Resolution 128 Risk Management Plan 129 Probability/Impact Risk Rating Matrix 131

5. 12207 Organizational Processes 133 Management 133

Software Requirements Management Plan 135 Software Requirements Management Plan Document Guidance 137 Software Project Management Plan 143 Software Project Management Plan Document Guidance 144 Stakeholder Involvement 148 Work Breakdown Structure (WBS) 148 Work Breakdown Structure (WBS) for Postdevelopment Stage 150

Infrastructure 151 Organization's Set of Standard Processes 151

Improvement 152 Engineering Process Group Charter 153 Process Action Plan (PAP) 154 Tailoring Guidelines 154

Training 155 Training Plan 156

6. Lean Six Sigma Fundamentals 161 What is Lean Six Sigma? 161 Lean Principles 161 Six Sigma Principles 164 Lean Six Sigma Fundamentals 166

Typical Lean Six Sigma Data 167 The Laws of Lean Six Sigma 168 Lean Six Sigma as Applied to Software 170 What Lean Six Sigma is Not 170

Six Sigma Life Cycle Variants 171

7. Lean Six Sigma Techniques and DMAIC 173 Define 173

Build Sponsorship and Determine Stakeholders 173 Set Priorities 174 Plan Actions 175 Baseline Processes 175 Create a Solution 176 Abstraction Tree (KJ or Affinity) Diagram 177 Functional Analysis Diagrams 178 Critical-to-Quality (CTQ) Tree 180

viii CONTENTS

Kano Model Project Charter Quality Function Deployment (House of Quality) Stakeholder Analysis Supplier, Inputs, Process, Outputs, and Customers (SIPOC) Diagram Voice of the Customer

Measure Checksheet Control Charts FMEA (Failure Modes and Effects Analysis)/EMEA (Error Modes

and Effects Analysis) Histograms Pareto Charts Prioritization Matrix Process Cycle Efficiency (PCE) Run Charts Time Value Analysis

Analyze 5 Whys Analysis Analysis of Variance (ANOVA) Brainstorming Cause-and-Effect (C&E) Diagrams Flowcharts—y-to-x Flowdown Diagrams Multivoting Pugh Concept Selection Matrix Regression Analysis Root Cause Analysis Scatter Plots (Diagrams) Stratification Value-Stream Mapping Waste Identification and Elimination (Seven Elements of Waste)

Improve 5S's Method Balanced Work Flow Cellular/Flow Manufacturing Jidoka (Autonomation) Kaizen Events Little's Law Process Stability Production Smoothing (Heijunka) Setup Time Reduction Takt Time Total Productive Maintenance (TPM) Visual Workplace

Control Evolutionary Operation (EVOP) One-Piece Flow Measurement Systems and their Assessment

181 182 184 187 187 188 189 189 190 192

192 193 194 195 196 197 198 199 199 200 201 202 204 205 206 207 208 209 210 211 213 213 214 215 215 216 216 217 218 221 221 222 224 225 225 225 226

CONTENTS ix

PDCA 227 Poka-yoke (Error Proofing) 228 Quality Control Process Chart 228 Standardized Work/Processes 230 Statistical Process Control 230

8. Applying Lean Six Sigma 233 Why Should My Organization Implement Lean Six Sigma? 233

Keys to Success 233 The Change Context 235

What If My Organization Implements Lean Six Sigma? 236 Identify Your Target(s) 237 Staff Responsibilities and Training 237 Follow-up 239

Goal-Driven Implementation 239 Lean Six Sigma and Conformance 240 Implementation Pitfalls 242

Being Overly Prescriptive 243 Documentation, Documentation 243 Lack of Incentives 243 Overemphasis on Certification and Not on the Lean 244

Conclusion 244

Appendix A. 12207 Supporting Work Products 245 Acquisition 245

Make/Buy Decision Matrix 245 Alternative Solution Screening Criteria Matrix 247 Cost-Benefit Ratio 247

Supply 248 Recommendations for Software Acquisition 248 Organizational Acquisition Strategy Checklist 249 Supplier Evaluation Criteria 250 Supplier Performance Standards 252

Development 253 Requirements Traceability 253 Software Development Standards Description 253 System Architectural Design Description 254 Software Architectural Design Description 255 Database Design Description 255 Software Architecture Design Success Factors and Pitfalls 256 UML Modeling 257 Unit Test Report 257 Unit Test Report Document Guidance 258 System Integration Test Report 263 System Integration Test Report Document Guidance 263

Operation 266 Product Packaging Information 266

Maintenance

x CONTENTS

Change Enhancement Requests 268 Baseline Change Request 269 Work Breakdown Structure for Postdevelopment 270 Configuration Management 271 Software Change Request Procedures 276 Version Description Document 279

Quality Assurance 280 Example Life Cycle 280 Minimum Set of Software Reviews 286 SQA Inspection Log 287 Inspection Log Description 288

Verification 288 Inspection Log Defect Summary 288 Inspection Log Defect Summary Description 289 Inspection Report 290 Inspection Report Description 291 Requirements Walk-through Form 292 Software Project Plan Walk-through Checklist 293 Preliminary Design Walk-through Checklist 294 Detailed Design Walk-through Checklist 295 Program Code Walk-through Checklist 296 Test Plan Walk-through Checklist 297 Walk-through Summary Report 298 Classic Anomaly Class Categories 298

Validation 299 Example Test Classes 299 Types of System Testing 301 Test Design Specification 302 Test Case Specification 303 Test Procedure Specification 304 Test Item Transmittal Report 305 Test Log 305 Test Incident Report 306 Test Summary Report 307

Joint Review 307 Open Issues List 307

Audit 309 Status Reviews 309 Critical Dependencies Tracking 309 List of Measures for Reliable Software 311 Example Measures—Management Category 312 Example Measures—Requirements Category 317 Example Measures—Quality Category 321 Measurement Information Model in ISO/IEC 15939 330

Problem Resolution 332 Risk Taxonomy 332 Risk Taxonomy Questionnaire 333 Risk Action Request 336

CONTENTS

Risk Mitigation Plan 337 Risk Matrix Sample 337

Management 338 Work Breakdown Structure 338 Work Flow Diagram 339

Infrastructure 340 Organizational Policy Examples 340 Software Life Cycle (SLC) Selection and Design 341 Process Definition 343 Process Definition Form 343 Asset Library Catalog 344

Improvement 345 Organizational Improvement Checklist 345 Organization Process Appraisal Checklist 349 Lessons Learned 3 51 Measures Definition for Organizational Processes 353

Training 353 Training Log 355

Appendix B. Planning For Small Projects 357 Process Definition and Small Projects 357 Proj ect Management Plan—Small Proj ects 358

Small Software Project Management Plan Document Guidance 359

Appendix C. CD ROM Reference Summary 367

Appendix D. IEEE Standards Abstracts 369

Appendix E. Mapping From IEEE 12207 to ISO/IEC 12207:2008 377

Appendix F. Acronyms 379

References 383 IEEE Publications 383 ISO Publications 385 Lean Six Sigma References 386 Other References 389

Index 393

About the Authors

PREFACE

Lean Six Sigma emphasizes that speed is directly related to process excellence. Many books have been written in support of streamlining core software processes or making core software processes and practices "lean." Additionally, numerous books and articles have been written in support of Six Sigma statistical measurement. This book begins by providing software developers with the fundamentals of software engineering. It then goes on to supply software project managers and development staff with the materials needed so that they can define their core software development processes and practices, and then proceeds to help support the refinement of these software and systems engineer-ing processes using Lean Six Sigma methods.

Many times, organizations head down the road toward the implementation of the Lean Six Sigma methodologies without a common understanding of the firm underpinnings of software and systems engineering. Before organizations can have processes that rapidly (using lean production) produce products of high quality (high sigma), they must first de-fine their basic software engineering processes and practices.

This book provides support for the foundation of a Lean Six Sigma program by pro-viding detailed process and practice documentation guidance in the form of:

• An overview of Lean Six Sigma methodologies • Detailed organizational policy examples • An Integrated set of over 40 déployable document templates • Examples of over 70 common work products required for support of process im-

provement activities • Examples of organizational delineation of process documentation

This book provides a set of IEEE software engineering standards-based templates that support the process definition and work-product documentation required for all activities

xiii

xiv PREFACE

associated with software development projects. The goal is to provide practical support for individuals responsible for the development and documentation of software processes and procedures. The objective is to present the reader with an integrated set of documents that support the initial requirements of a Lean Six Sigma program.

This book will provide specific support for organizations pursuing Lean Six Sigma guided software process definition and improvement. It is hoped that this knowledge pro-vides the essential foundation on which to build toward the evolution of software process definition, documentation, and improvement, and should be an integral part of every soft-ware engineering organization.

The IEEE Computer Society Software and Systems Engineering Standards Committee (S2ESC) is the governing body responsible for the development of software and systems engineering standards. S2ESC has conducted several standards users' surveys; the results of these surveys reflected that standards users found the most value in the guides and standards that provided the specific detail that they needed for the development of their process documentation. Users consistently responded that they used the guides in support of software process definition and improvement but that these standards and guides re-quired considerable adaptation when applied as an integrated set of software process doc-umentation.

This book was written to support software engineering practitioners who are responsi-ble for producing the process documentation, work products, or artifacts associated with support of software process definition and improvement. This book will be most useful to organizations with multiple products and having business customer relationships. In addi-tion to members of project development and test teams working on products with multiple versions, this book will also be useful to members of organizations supporting software project development and testing who work in such areas as project management, configu-ration management, risk management, human resources, and information technology.

It is the hope of the authors that this book will help members of organizations who are responsible for developing or maintaining their software processes in order to support Lean Six Sigma requirements.

SUSAN K. LAND DOUGLAS B. SMITH JOHN W. WALZ

ACKNOWLEDGMENTS

I acknowledge my associates on the America's Army project (www.americasarmy.com) for supplying me with the vision for this book and for also providing me with the ideal en-vironment for the deployment of Lean Six Sigma principles and practices. I would also like to acknowledge my colleagues within the volunteer organizations of the IEEE Com-puter Society and thank them for their constant encouragement, their dedication to quali-ty, and their friendship. Special thanks again to my family for their continuing and unfail-ing support.

S. K. L.

I thank my family—Becky, Tim, and Kaitlin—for their tolerance and support. I am deeply indebted to many present and former colleagues from Northrop Grumman: Dr. Ralph Young, who leads and teaches by example in so many ways; Dan Baker, who set me on the Lean Six Sigma path and whose counsel has guided me to personal and profession-al growth; Craig Hollenbach, font of knowledge, faith, and friendship; my Master Black Belts—Sy Sherman and Jerry Stefanko—whose support has been statistically significant (p < 0.05); and Beth Barnickel, whose commitment to One Northrop Grumman and Lean Six Sigma has been crucial to our success and is greatly appreciated.

D. B. S.

Without the support of Ann, my wife, this book would not have been a reality; thank you. I thank my previous managers who guided my professional development and their continued support of my IEEE Computer Society volunteer activities: Thomas J. Scur-lock, Jr and Terry L. Welsher, both retired from Lucent Technologies, and James R. Mc-Donnell, AT&T. For my long involvement in software engineering standards, I would like to thank the leadership of Helen M. Wood.

J. W. W.

The authors thank the editing staff at John Wiley & Sons and Angela Burgess of the IEEE Computer Society for their publication support.

xv

1 INTRODUCTION AND OVERVIEW

INTRODUCTION

Software is generated from thousands of lines of code which are developed by a number of people with a variety of skill sets using a multitude of development methods, stan-dards, and rules. These lines of code have to come together at the right time, in the right order, at the right cost, and with the required quality. In order to try to confront this soft-ware development challenge, organizations have been employing:

• Software engineering practitioners with better software engineering skills • Software engineering tools that better fit practitioners and their methods • Software process improvement methodologies and controls that help to guarantee

quality and delivery

Moving an organization from the chaotic environment of free-form development to-ward an environment that is managed for success using control and communication processes can be confusing to those tasked with making it happen. When those same indi-viduals are also challenged to additionally produce "lean" and "efficient" processes, the task can be overwhelming. It is imperative that the people responsible for the develop-ment of software processes and practices understand the foundations of software engi-neering.

If an organization, and its employees, do not practice or understand the tenants of basic software engineering, trying to employ Lean Six Sigma methodologies is not advisable. Organizations must first have sound software engineering processes and practices. These processes and practices should be based upon standards and industry best practices. Em-ployees must embrace, understand, and should be well trained in these supporting prac-tices before any attempt can be made at increasing software development speed. It should

Practical Support for Lean Six Sigma Software Process Definition. By S. Land, D. Smith, and J. Walz 1 Copyright © 2008 IEEE Computer Society

2 INTRODUCTION AND OVERVIEW

be noted that significant quality improvement gains can be made by simply defining processes and practices in organizations where none exist.

This book is written to support software engineering practitioners who are responsible for producing the process documentation and work products or artifacts associated with support of software process definition and improvement. This book specifically addresses how IEEE standards may be used to facilitate the development of processes, internal plans, and procedures in support of managed and defined software and systems engineer-ing processes in support of Lean Six Sigma implementation [81].

The IEEE Computer Society Software and Systems Engineering Standards Committee (S2ESC) offers an integrated suite of standards based on using IEEE 12207 [40] as a set of reference processes. S2ESC recommends that organizations should use 12207 and re-lated standards to assist them in defining their organizational processes in support of the implementation of the Lean Six Sigma process methodology. However, this book is based on the premise that the reader's processes may not have been defined in this fashion and that the reader seeks help in improving their processes. Therefore, the advice provided in this book does not make the assumption that the user's processes conform to 12207. In general, that advice will be consistent with 12207, but its intent is to assist with process documentation and improvement in the context of Lean Six Sigma. It is the premise of the information provided within these pages that IEEE software engineering standards [42] can be used to provide the basic beginning framework for this type of process improve-ment.

IEEE standards can be used as instruments to help with the process definition and doc-umentation (e.g., work products) required in support of the process improvement of soft-ware and systems development efforts. Many of the IEEE software engineering standards provide detailed procedural explanations; they offer section-by-section guidance on building the necessary support material, and most importantly, they provide best-practice guidance in support of process définition as described by those from academia and indus-try who sit on the panels of standards reviewers.

In using this book, the key is to use the templates provided to develop simple process-es that support your development efforts; team member involvement is critical. The Lean Six Sigma approach combines general quality guidance with a process-based manage-ment approach, describing the criteria that the processes should support. IEEE standards are prescriptive. These standards describe how to fulfill the requirements associated with all activities of effective software and systems project life cycle.

IEEE standards are highly specific. They are documented agreements containing tech-nical specifications or other precise criteria to be used consistently as rules, guidelines, or definitions of characteristics to ensure that materials, products, processes, and services are fit for their purpose. In contrast, Lean Six Sigma has been called an improvement method, or improvement engine, using data to identify and eliminate process problems [80]. This book is an attempt to bridge the gap between defined methods and the end goal of a prac-ticing Lean Six Sigma organization.

It is often hard to separate the details associated with product development from the practices required to manage the effort. Simply providing a description of the Six Sigma methodology and lean manufacturing processes to a project lead or manager provides them with a description of an end results model. Pairing this with IEEE standards pro-vides them with a way to work toward this desired end. IEEE standards do not offer a "cookie cutter" approach to management; rather, they support the définition of the man-agement processes in use by describing what is required. IEEE standards provide much

STIMULUS FOR LEAN SIX SIGMA 3

needed guidance to organizations working to define their organizational processes and practices.

STIMULUS FOR LEAN SIX SIGMA

Organizations are motivated to use Lean Six Sigma from two directions: external and in-ternal. External motivations may be customers, investors, or competitors. Lean Six Sigma requirements are now showing up in the form of Dept. of Defense (DoD) requirements. The Office of the Secretary of Defense (OSD) and all of the Services are embarked on multiyear continuous process improvement initiatives based on Lean Six Sigma, includ-ing the Air Force's Smart Operations for the 21 Century (AFS021) and the Navy's AIRSpeed. DoD requests for proposals are increasingly asking for Lean Six Sigma quali-fications. The Air Force in 2007 awarded a 5-year contract worth up to $99 million for lean expertise and training [123, 124].

Internal motivations for Lean Six Sigma implementation are improving company prof-itability through improved revenue growth, reduced costs, improved delivery times, and increased customer satisfaction [80]. Lean Six Sigma implementation normally is insti-gated by top management and enjoys on-going support due to its successes across many industries.

Many software engineering organizations have implemented Lean Six Sigma in mini-mal form but have not realized its full potential. This may be due to the general and ab-stract nature of Lean Six Sigma as contrasted with the inherent complexity of software engineering processes. However, it is much more likely that software development orga-nizations may not be realizing the full benefits of Lean Six Sigma because they are trying to apply it to incomplete or nonrobust software engineering development activities. An organization must have sound software engineering practices before it can look to im-prove them using a methodology like Lean Six Sigma.

Successful software engineering organizations should create well-formed internal work products, or artifacts, during development phases leading to a finished product or as by-products of their software process or practice definition. Although Lean Six Sigma does not describe these artifacts in detail, this book will describe and provide examples of the im-portant artifacts that are aligned with the IEEE software engineering standards. The usage of IEEE related artifacts allows customers and investors additional opportunities for inter-action during the various project phases leading to refined requirements, feedback, and ex-pectations. IEEE-related artifacts provide increased clarity among project personnel, which promotes easier personnel movement between teams and organizations, better alignment between project/program management and software engineering, and better alignment be-tween company goals, objectives, and project/program success factors.

For organizations that do not wish to pursue an implementation of the Lean Six Sigma techniques, this text will show how the application of IEEE standards, and their use as reference material, can facilitate the development of sound software and systems engi-neering practices. This book is geared for the Lean Six Sigma novice, the project manag-er, and software engineering practitioners and managers who want a one-stop source, a helpful document, that provides the details and implementation support required when pursuing process definition and improvement.

The plans and artifacts described in this book may be used as an integrated set in sup-port of software and systems process definition and improvement. The plans and artifacts

4 INTRODUCTION AND OVERVIEW

are meant to elicit thought and help guide organizations and development teams through the definition of their own unique software development processes and practices. It should be noted that many of the plans offer examples; these examples are meant to show intent and offer only narrow perspectives on possible plan content.

In addition to Lean Six Sigma, there are also other well-known software process im-provement models that have widespread popularity. Two of these models are the Capabil-ity Maturity Model Integration (CMMI(r)) and ISO 9001. The authors of this book have taken the realistic view that many software development organizations may have multiple motivators for software process improvement. Organizations may want lean processes, but they may also have dual requirements for CMMI or ISO 9001 certification.

Although these topics will not be covered in this book, they are covered extensively in related texts by the same authors* and deliberate efforts have been made to keep the foun-dation materials and artifacts provided for the creation of baseline software engineering processes and practices consistent. This is done so that organizations that may have a dual requirement—not only being a Lean organization, but also one meeting the capability re-quirements of a Level 2 or 3 CMMI organization, or ISO 9001 certified software develop-ing entity. If employed, these plans and artifacts will help organizations establish the sound software engineering foundation required to help them then move on their way to-ward sound software process improvement.

The authors recommend attendance in the following, or similar, courses: Six Sigma Green Belt Training (5 days) and Lean Practitioner Training (4 days). The authors also recommend the acquisition of the IEEE Software Engineering Collection, which fully in-tegrates over 40 of the most current IEEE software engineering standards onto one CD-ROM [42]. This book provides a list of the IEEE standards abstracts in Appendix C and the mapping IEEE 12207 clause numbers to both the relevant IEEE standards and the IEEE 12207 2008 version clauses in Appendix E.

USING THIS BOOK

The purpose of this book is to assist users in selecting IEEE software engineering stan-dards and their related artifacts appropriate to their needs for process changes leading to Lean Six Sigma implementation. It is important that readers understand that process im-provement begins when organizations have a strong foundation of software engineering process methodology. Processes must exist before they can be improved. This book pro-vides two components: a set of templates to establish a core set of software engineering practices and processes, and a description of Lean Six Sigma techniques to accomplish software process improvement.

A key question is, where is your organization? What is its current state? Is your organi-zation currently using

• Six Sigma for software engineering • Lean software engineering

*Land, Susan K.; Using IEEE Software Engineering Standards to Jumpstart CMM/CMMI Software Process Im-provement, lEEEAViley, 2005; Land, Susan K., and Walz, John, Practical Support for CMMI-SW Software Pro-ject Documentation: Using IEEE Software Engineering Standards, lEEEAViley, 2006; Land, Susan K., and Walz, John, Practical Support for ISO 9001 Software Project Documentation: Using IEEE Software Engineer-ing Standards, lEEEAViley, 2006.

USING THIS BOOK 5

• Measurements of software engineering processes • Process frameworks such as CMMI-DEV® • Formalized management systems such as ISO 9001 • Some of the above on selected projects, but not all projects • None of the above

A typical journey for newly formed software engineering organizations is to reverse the seven bulleted items above by taking steps, one at a time, starting on a pilot project and applying the learning to all projects in the organization.

Lean manufacturing initiatives are becoming relatively commonplace in the world of manufacturing. Lean manufacturing helps eliminate production waste, introduce value-added measurements, and push for continuous improvements. The Six Sigma methodolo-gy uses data and statistical analysis tools to identify, track, and reduce problem areas and defects in products and services.

As Six Sigma is complementary to lean processes, the two are combined into Lean Six Sigma, which strives to present the same types of gains for software engineering compa-nies. Once the waste is removed from software development and production is truly "lean," then the Six Sigma tool set is applied to reduce defects in the value-adding parts of the process.

The subsequent application of Six Sigma methodology supports risk management and problem identification and resolution. In addition to the lean tools to reduce waste and Six Sigma tools to reduce defects, some organizations also include Goldratt's Theory of Con-straints [83] in their continuous improvement toolkit to use on bottlenecks. Although we do not cover Theory of Constraints in detail in this book, it is a very compatible approach that, at a high level, consists of a five step process:

1. Identify the system's constraint. 2. Exploit (maximize throughput of) the system's constraint. 3. Subordinate other processes to the constraint; reduce suboptimzation. 4. Elevate the constraint (make it more capable). 5. Repeat the cycle (what limits the system now that you have broken its previous

constraint?).

The Theory of Constraints and its application to scheduling (also called the Critical Chain) are similar to the lean principle of flow, and lean's emphasis on reducing multi-tasking [83].

The Lean Six Sigma approach combines general quality guidance with a process-based management approach, describing the criteria that the processes should support. Just as lean implementation should generally precede the application of Six Sigma techniques, the combined Lean Six Sigma requires a robust management and process measurement system foundation such as ISO 9001 or the CMMI-DEV framework prior to the applica-tion of its improvement methodologies. This book is oriented toward organizations whose current state is any of the seven bulleted levels above.

This book provides the coherent software life cycle processes as defined in IEEE 12207 and related software engineering standards to assist organizations in defining their organizational processes and artifacts in support of the implementation of the Lean Six

6 INTRODUCTION AND OVERVIEW

Sigma methodology. The software engineering standards are used as instruments to help with the process definition and documentation (e.g., work products or artifacts) required in support of the software process improvement toward the desired organizational state. These desired states can be reached in steps: first achieving the robust management sys-tem foundation, followed by primary life cycle software processes measurements, and, fi-nally, implementation of the Lean Six Sigma methodology. This journey requires adapta-tion and tailoring of standards and their artifacts as "one size does not fit all." Projects must design and use their objective experiences to determine what works best when using selected best practices.

Many organizations with a robust management system foundation are pursuing process improvement by establishing a set of organizationally adopted processes to be ap-plied by all of their projects, and then improving them on the basis of their experience. This "experience" is factored by both the lean principles and the Six Sigma principles, re-sulting in the use of specific Lean Six Sigma improvement techniques that validate spe-cific process changes to be deployed across the organization. Whenever objective experi-ences demonstrate the need for changes to processes and artifacts, then this book will show the appropriate IEEE software engineering standards to be selected and analyzed so that their best practices can be incorporated into processes, internal plans, procedures, and other artifacts, to support Lean Six Sigma implementation.

Change management is not solely a technical endeavor of engineering process experts. Whether the Lean Six Sigma motivation is from external or internal sources, top manage-ment support is required for organizational change management. Top management has the responsibility of providing overall direction, resources, and the control framework for managing the change process. The organizational changes result in changes to partici-pant's skills, their tools, and their work processes and artifacts. This book focuses on the software engineering and improvement work processes and artifacts that support Lean Six Sigma implementation. Although process engineers have major roles, team member in-volvement in organizational and process changes is critical.

This book will guide your organization to use the provided software engineering stan-dards and artifacts such as document templates to develop or enhance processes that sup-port your development efforts with Lean Six Sigma.

2 STANDARDS AND SOFTWARE PROCESS IMPROVEMENT

WHAT ARE STANDARDS?

Standards are documented sets of rules and guidelines that provide a common framework for communication and are expressed expectations for the performance of work. These rules and guidelines set out what are widely accepted as good principles or practices in a given area. They provide a basis for determining consistent and acceptable minimum lev-els of quality, performance, safety (low risk) and reliability.

Standards are.consensus-based documents that codify best practice [43]. Consensus-based standards have seven essential attributes that aid in process engineering. They

1. Represent the collected experience of others who have been down the same road 2. Describe in detail what it means to perform a certain activity 3. Can be attached to or referenced by contracts 4. Help to assure that two parties define an engineering activity in the same way 5. Increase professional discipline 6. Protect the business and the buyer 7. Improve the product

IEEE software engineering standards provide a framework for documenting software engineering activities. The "soft structure" of the standards set lends well to the instantia-tion of software engineering processes and practices. The structure of the IEEE software engineering standards set also provides for tailoring. Each standard describes recom-mended best practices detailing required activities. These standards documents provide a common basis for documenting organizationally unique software process activities.

When trying to understand exactly what the IEEE software and systems engineering standards collection is, and what this body of work represents, the following statement

Practical Support for Lean Six Sigma Software Process Definition. By S. Land, D. Smith, and J. Walz 7 Copyright © 2008 IEEE Computer Society

8 STANDARDS AND SOFTWARE PROCESS IMPROVEMENT

(taken from the Synopses of Standards section in the IEEE Standards Collection, Soft-ware Engineering, 1994 Edition) summarizes it best:

The main motivation behind the creation of these IEEE Standards has been to provide recom-mendations reflecting the state-of-practice in development and maintenance of software. For those who are new to software engineering, these standards are an invaluable source of care-fully considered advice, brewed in the caldron of a consensus process of professional discus-sion and debate. For those who are on the cutting edge of the field, these standards serve as a baseline against which advances can be communicated and evaluated. [42]

IEEE software and systems engineering standards provide a framework for defining and documenting software and systems engineering activities. These standards docu-ments provide a common basis for documenting organizationally unique process activi-ties. The structure of the standards set supports the Lean Six Sigma process methodology while also providing for organizational adaptation. Each standard describes recommend-ed best practices detailing required activities.

IEEE S2ESC Software and Systems Engineering Standards Committee

In 1976, this arm of the IEEE Computer Society was chartered to develop the first stan-dards for software engineering. The mission of the S2ESC is:

1. To develop and maintain a family of software and systems engineering standards that is relevant, coherent, comprehensive, and effective in use. These standards are for use by practitioners, organizations, and educators to improve the effectiveness and efficiency of their software engineering processes, to improve communications between acquirers and suppliers, and to improve the quality of delivered software and systems containing software.

2. To develop supporting knowledge products that aid practitioners, organizations, and educators in understanding and applying our standards.

From a narrow perspective, S2ESC manages the scope and direction of IEEE software and systems engineering and standards. S2ESC is the standards partner of the IEEE Tech-nical Council on Software Engineering (TCSE), and has worked to provide the standards collection that

• Provides a consistent view of the state of the practice • Is aligned with the Software Engineering Body of Knowledge (SWEBOK) • Addresses practitioner concerns • Is affordable

From a broader perspective, in addition to the development of standards, S2ESC de-velops supporting knowledge products and sponsors or cooperates in annual conferences and workshops in its subject area. S2ESC also participates in international standards mak-ing as a member of the U.S. Technical Advisory Group (TAG) to ISO/IEC JTC1/SC7 and as a direct liaison to SC7 itself. Table 2-1 provides a sample of some of the types of soft-ware engineering activities supporting by the S2ESC standards.

S2ESC also supports and promotes the Software Engineering Body of Knowledge,

WHAT ARE STANDARDS? 9

Table 2-1. Some examples of what IEEE standards do

IEEE 982.1 Specify techniques to develop software faster, cheaper, better Measures for Reliable Software IEEE 1008 Describes "best practices" Unit Testing IEEE 1061 Provide consensus validity for techniques that cannot be SW Quality Metrics scientifically validated IEEE/EIA 12207 Provide a framework for communication between buyer and SW Life Cycle Processes seller IEEE 1028 Give succinct, precise names to concepts that are otherwise SW Reviews fuzzy, complex, detailed and multidimensional [159]

certification mechanisms for software engineering professionals, and other products con-tributing to the profession of software engineering.

SWEBOK

On May 21, 1993, the IEEE Computer Society Board of Governors approved a motion to "establish a steering committee for evaluating, planning, and coordinating actions related to establishing software engineering as a profession" [45]. Many professions are based on a body of knowledge that supports purposes such as accreditation of academic programs, development of education and training programs, certification of specialists, or profes-sional licensing. One of the goals of this motion was to establish a body of knowledge in support of software engineering. In 1996, the initial Strawman version of this body of knowledge was published as the Software Engineering Body of Knowledge (SWEBOK®*). The 2004 version of the SWEBOK® has been released and is available at www.swebok.org. ISO and IEC adopted the SWEBOK in 2005 as a Technical Report, ISO/IEC TR 19759:2005 Software Engineering—Guide to the Software Engineering Body of Knowledge (SWEBOK).

The SWEBOK® outlines the knowledge associated with what has become the consen-sus body of software engineering knowledge. The goal of the SWEBOK® is to define the core of what the software engineering discipline should contain. The acknowledgement of the SWEBOK® by educational institutions would mean a shift from technology-specific programming courses, like C++ and Java, to the knowledge and practices required in sup-port of software development and software project management.

The purpose of the SWEBOK is to provide a consensually validated characterization of the bounds of the software engineering discipline and to provide a topical access to the body of knowledge supporting that discipline.

Software engineering should be balanced among the following guiding principles:

• Rigor and formality. Repeatable methods and processes promote better estimates and less waste (e.g., defects). This channels creativity to the software development product or service instead of the methods.

*SWEBOK is a registered trademark of the IEEE.

10 STANDARDS AND SOFTWARE PROCESS IMPROVEMENT

• Separation of concerns. Supports the management of complexity and paralleliza-tion. Design techniques include modularity and decomposition, cohesion and cou-pling, and abstraction.

• Anticipation of change. Customers expect change and sometimes do not know all of their requirements.

• Generality. Allows reuse to quickly solve problems or implement similar features. • Incrementally. Frequent customer interaction to confirm and prioritize requirements. • Scalability. Supports quick deployment or addresses larger customer needs. • Compositionality. Allows for precise requirements under various conditions or un-

derstanding different user/actor roles. • Heterogeneity. Understanding the variability or differences between studies in the

estimates of effects [158].

The SWEBOK® is divided into ten knowledge areas (refer to Table 2-2) that contain descriptions and references to topically supportive materials that reflect the knowledge re-quired to support the software engineering discipline. Appendix C of the SWEBOK Guide provides an Allocation of Standards to Knowledge Area, supplying an annotated table of the most relevant standards, mostly from the IEEE and the ISO, allocated to the SWEBOK Guide Knowledge Areas [45]. Process teams can use the SWEBOK® as a ref-erence tool supporting their requirements for process development and definition.

The SWEBOK® will continue to evolve, as do all the bodies of knowledge associated with other professional disciplines. Areas will be redefined and refined over time to ad-dress all of the factors that affect the creation or maintenance of a software product. The SWEBOK® offers a challenge to all of those involved with software—broaden the knowl-edge base and move from computer science to software engineering. The requirement is for software engineering practitioners to not only know how to write code, but to under-stand all aspects of the processes that support the creation of their products.

Table 2-2. The ten SWEBOK Knowledge Areas [45]

SWEBOK® Knowledge Area Supports

Software Requirements Software Requirements Fundamentals Requirements Process Requirements Elicitation Requirements Analysis Requirements Spécification Requirements Validation Practical Considerations

Software Design Software Design Fundamentals Key Issues in Software Design Software Structure and Architecture Software Design Quality Analysis and Evaluation Software Design Notations Software Design Strategies and Methods

Software Construction Software Construction Fundamentals Managing Construction Practical Considerations

SOFTWARE PROCESSES MUST EXIST BEFORE THEY CAN BE REDESIGNED 11

Table 2-2. Continued

SWEBOK® Knowledge Area Supports

Software Testing

Software Maintenance

Software Configuration Management

Software Engineering Management

Software Engineering Process

Software Engineering Tools and Methods

Software Quality

Software Testing Fundamentals Test Levels Test Techniques Test-Related Measures Test Process

Software Maintenance Fundamentals Key Issues in Software Maintenance Maintenance Process Techniques for Maintenance

Management of the SCM Process Software Configuration Identification Software Configuration Control Software Configuration Status Accounting Software Configuration Auditing Software Release Management and Delivery Initiation and Scope Definition Software Project Planning Software Project Enactment Review and Evaluation Closure Software Engineering Measurement

Process Implementation and Change Process Definition Process Assessment Product and Process Measurement

Software Tools Software Requirements Tools Software Design Tools Software Construction Tools Software Testing Tools Software Maintenance Tools Software Engineering Process Tools Software Quality Tools Software Configuration Management Tools Software Engineering Management Tools Infrastructure Support Tools Miscellaneous Tool Issues Software Engineering Methods

Software Quality Fundamentals Software Quality Management Processes Practical Considerations

12 STANDARDS AND SOFTWARE PROCESS IMPROVEMENT

IEEE 12207

The SWEBOK Knowledge Area breakdown is broadly compatible with the sections of IEEE 12207 Standard for Software Life Cycle Processes, and refers to its various require-ments activities. The mapping table in Table 2-3 allows process teams to use the SWEBOK® as a reference to additional process development and définition.

Table 2-3. High-level mapping of the SWEBOK to IEEE 12207

SWEBOK® Area IEEE 12207

Software Requirements

Software Design

Software Construction

Software Testing

Software Maintenance

Software Configuration Management

Software Engineering Management

Software Engineering Process

Software Engineering Tools and Methods

Software Quality

5.1 Acquisition 6. Supporting Life Cycle Processes:

6.1 Documentation

5.2 Supply 6. Supporting Life Cycle Processes:

6.1 Documentation

5.3 Development 6. Supporting Life Cycle Processes:

6.1 Documentation

6. Supporting Life Cycle Processes: 6.1 Documentation 6.4 Vérification 6.5 Validation 6.8 Problem Resolution

5.4 Operation 5.5 Maintenance

6. Supporting Life Cycle Processes: 6.1 Documentation

6. Supporting Life Cycle Processes: 6.1 Documentation 6.2 Configuration Management

7. Organizational Life Cycle Processes: 7.1 Management

6. Supporting Life Cycle Processes: 6.1 Documentation 6.6 Joint Review

6. Supporting Life Cycle Processes: 6.1 Documentation

7. Organizational Life Cycle Processes: 7.2 Infrastructure 7.3 Training 7.4 Improvement

6. Supporting Life Cycle Processes: 6.1 Documentation

6. Supporting Life Cycle Processes: 6.1 Documentation 6.3 Quality Assurance 6.7 Audit