Sor TWARE PROJECT MANAGEMENT A UNIFIED FRAMEWORK WALKER ROYCE Foreword by Barry Boehm i | heeSOFTWARE PROJECT MANAGEMENT A Unified Framework WALKER ROYCEThe Addison-Wesley Object Technology Series Grady Booch, Ivar Jacobson, and James Rumbaugh, Series Editors For more information check out the series web site [http:/wwww awl comlesenglotseries/] ‘Armout/Miller, Advanced Use Case Modeling, Volume 1 Binder, Testing Object-Oriented Systems: Models, Patterns and Tools Blakley, CORBA Security: An Inroduction 10 Safe Computing with Objects Booch, Object Solutions: Managing the Object-Oriented Project Booch, Object-Oriented Analysis and Design with Applications Second Edition Booch/Rumbaugh/lacobson, The Unified Modeling Language User Guide Box, Essential COM Box/Brown/Ewald/Sels, Effective COM: 50 Ways 10 Improve Your COM and MTS-based Applications ‘Cockbucn, Surviving Object-Oriented Projects: A Manager's Guide Collins, Designing Object-Oriented User Inerfaces Conalen. Building Web Applications with UML. D'Souza/Wilis, Objects: Components, and Frameworks with UML: The Catalysis Approach Douglass, Doing Hard Time: Developing Real-Time Systems with UML, Objects, Frameworks, and Patterns Douglass, Real-Time UML, Second Edition: Developing Efcient Objects for Embedded Sysiems Fowler, Analysis Patterns: Reusable Object Models Fowler/Beck/BranvOpdyke/Roberts, Refactoring: Improving the Design of Existing Code Fowler/Scott, UML Distilled, Second Edition: A Brief Guide 0 the Standard Object Modeling Language Gomaa, Designing Concurrent, Distributed. and Real-Time Applications with UML Gorton, Encerprise Transaction Processing Stems: Putting the CORBA OTS, Encina++ and Orbic OTM to Work Graham, Object-Oriented Methods, Third Edition: Principles and Practice Heinckiens, Building Scalable Database Applications: Object Oriented Design, Architectures, and Implementations HofmesterINord/Dilip, Applied Software Architecture Jacobson/Boocl/Rumbaugh, The Unified Software Development Process acobson/Christersonibonsson/Overgaard, Object-Oriented ‘Software Engineering: A Use Case Driven Approach Jacobson/Eriesson/Jacobson, The Object Advantage: Business Process Reengineering with Object Technology Jacobsow/Grisstlonsson, Software Reuse: Architecture, Process ‘and Organization for Business Success Jordan, C++ Object Databases: Programming withthe ODMG Standard Kruchien, The Rational Unified Process. An Iniroduction, Second Eaiion Lau, The Art of Objects: Object-Oriented Design and Architecture LLeffingwellWidrig, Managing Software Requirements: A Unified Approach Marshall. Enterprive Modeling with UML: Designing Successful Sofware vhrough Business Analysis Mowbray/Ruh, Inside CORBA: Distributed Object Standards and Applications estereich, Developing Software with UML: Object-Oriented ‘Analysis and Design in Practice Page-Jones, Fundamentals of Object-Oriented Design in UML Pohl, Object-Oriented Programming Using C++, Second Editon Pooley/Stevens, Using UML: Software Engineering with Objects ‘and Components ‘Quatani Visual Modeling with Rational Rose 2000 and UBL. RectoiSells, ATL Internals Reed, Developing Applications with Viual Basic and UML Rosenbery/Scot, Use Case Driven Object Modeling with UML: A Practical Approach Royce, Software Project Management: A Unified Framework RuhiHerron/Klinker, JOP Complete: Understanding CORBA and Middleware Interoperability Rumbaugh/tacobson/Boach, The Unified Moudeling Language Reference Manual Schneider Winters, Applying Use Cases: A Practical Guide Shan‘€arle, Emerprise Computing with Objects: From Client/Server Environments tothe Internet WarmeriKleppe, The Object Constraint Language: Precise Modeling with UML White, Software Configuration Management Sirategies and Rational ClearCase®: A Practical Iniuduction ‘The Component Software Series Clemens Szyperski, Series Editor For more information check out the series web site [http://www.awl convcseng/esseries’]. * Allen, Realizing eBusiness with Components ‘Cheesman/Daniels. UML Components: A Simple Process for ‘Specifving Component-Based SoftwareSOFTWARE PROJECT MANAGEMENT A Unified Framework WALKER ROYCE RATIONAL SOFTWARE CORPORATION Ww ADDISON-WESLEYMany of the designations used by manufacturers and sellers to distinguish their products are claimed as trademarks. Where those designations appear in this book, and we were aware of a trademark claim, the designations have been printed in initial capital leters or in all capitals ‘The author and publisher have taken care in the preparation of this book, but make no expressed or implied warranty of any kind and assume no responsibility for errors or omissions. No liability is assumed for incidental or consequential damages in connection with or arising out of the use of the information or programs contained herein. ‘The publisher offers discounts on this book when ordered in quantity for special sales. For more informa- tion, please contact: Pearson Education Corporate Sales Division One Lake Street Upper Saddle River, NJ. 07458 (800) 382-3419 ccorpsales @pearsontechgroup.com Visit AW on the Web: www awl.com/eseng/ Library of Congress Cataloging-in-Publication Data Royce, Walker, 1955- Software project management : a unified framework / Walker Royce, . cm. ~ (The Addison-Wesley object technology series) Includes bibliographical references and index. ISBN 0-201-30958-0 1, Computer software—Development—Management. 1. Tile UL. Series. QA76.76.D47R69 1998 005.1'2—de21 98-2071 5 cP ‘Special permission to paraphrase and use the Maturity Questionnaire, CMU/SEI-94-SR-007 © 1998 by CCamegie Mellon University, in the book Software Project Management: A Unified Framework is granted by the Software Engineering Institute. Capability Maturity Model is a service mark of Carnegie Mellon University, CMMSM registered in the US, Patent and Trademark Office. Copyright © 1998 by Addison-Wesley {Al sights reserved, No pat of this publication may be reproduced, stored in a retrieval system, or transmited, in any form, or by any means, electronic, mechanical, photocopying, recording, or other- wise, without the prior consent ofthe publisher, Printed inthe United States of America, Published simultaneously in Canada. . ISBN 0-201-30958-0 ‘Text printed on recycled paper 6789 10—MA—0403020100 Sixth printing, November 2000This work is dedicated to my father, Winston Royce, whose vision and practicality were always in balance. —WalkerPARTI CHAPTER 1 CHAPTER 2 CHAPTER 3 Contents List of Figures... List of Tables Foreword. Preface... SOFTWARE MANAGEMENT RENAISSANCE Conventional Software Management. 1.1 The Waterfall Model 1.1.1 In Theory. 1.1.2 In Practice enn 1.2. Conventional Software Management Performance. Evolution of Software Economics.. 2.1 Software Economic: 2.2 Pragmatic Software Cost Estimation Improving Software Economics 3.1 Reducing Software Product Size . 3.1.1 Languages ; 3.1.2 Object-Oriented Methods and Visual Modeling... 3.1.3 Reuse 3.1.4 Commercial Components 3.2. Improving Software Processes. 3.3. Improving Team Effectiveness . viiCONTENTS CHAPTER 4 PART II CHAPTER $ CHAPTER 6 CHAPTER 7 CHAPTER 8 CHAPTER 9 ‘A SOFTWARE MANAGEMENT PROCESS FRAMEWORK 3.4 Improving Automation through Software Environments... 3.5. Achieving Required Quality 3.6 Peer Inspections: A Pragmatic View... The Old Way and the New 4.1 The Principles of Conventional Software Engineering .. 4.2 The Principles of Modern Software Management... 4.3. Transitioning to an Iterative Proces... Life-Cycle Phases 5.1 Engineering and Production Stag 5.2 Inception Phase 5.3 Elaboration Phase... 5.4 Construction Phase 5.§ Transition Phase ...: Artifacts of the Process. 6.1 The Artifact Sets.. 6.1.1 The Management Set... 6.1.2 The Engineering Sets. 6.1.3 Artifact Evolution over the Life Cycle... 6.14 Test Artifacts. 6.2 Management Artifact... 6.3 Engineering Actifacts.. 64 Pragmatic Artifacts Model-Based Software Architectures. 7.1 Architecture: A Management Perspective .. 7.2 Architecture: A Technical Perspective. Workflows of the Proces 8.1 Software Process Workflows. 8.2 Iteration Workflows... Checkpoints of the Process. a1 Major Milestones 9.2 Minor Milestones. 9.3 Periodic Status Assessments...... 103 105 109 110 ua 47 118 121 125 126 132 133CONTENTS ix PART IIT SOFTWARE MANAGEMENT DISCIPLINES 135 CHAPTER 10 _ Iterative Process Planning .. 139 10.1 Work Breakdown Structures. 139 10.1.1 Conventional WBS Issues. = 140 10.1.2. Evolutionary Work Breakdown Structures. wo 142, 10.2 Planning Guidelines. 146 10.3 The Cost and Schedule Estimating Process 149 10.4 The Iteration Planning Process 150 10.5 Pragmatic Planning. 153 CHAPTER 11 Project Organizations and Responsibilities... 15s LLL Line-of-Business Organizations 156 11.2 Project Organizations 158 11.3. Evolution of Organizations 165 CHAPTER 12 _ Process Automation. 167 12.1 Tools: Automation Building Blocks 168 12.2 The Project Environment 172 12.2.1 Round-Trip Engineering, 173 12.2.2 Change Management ..csncssensinnnsnsst see 174 12.2.3. Infrastructures... 181 12.2.4 Stakeholder Environments . 184 CHAPTER 13 Project Control and Process Instrumentation. 187 13.1 The Seven Core Metrics. 188 13.2. Management Indicators... 190 13.2.1 Work and Progress.. 190 132.2 Budgeted Cost and Expenditures.viussonnesonenn 191 13.2.3. Staffing and Team Dynamics... 195 13.3 Quality Indicators .. 196 133.1 Change Traffic and Stability 196 13.3.2. Breakage and Modularity. 197 13.3.3 Rework and Adaptability... — 197 13.3.4 MTBF and Maturity... 198 13.4 Life-Cycle Expectations enesene 199 201 202 13.5 Pragmatic Software Metrics. 13.6 Metrics Automation ...CHAPTER 14 PART IV CHAPTER 15 CHAPTER 16 CHAPTER 17 PART V APPENDIX A APPENDIX B Tailoring the Process. 14.1 Process Discriminants.. 14.1 Scale . : 14.1.2. Stakeholder Cohesion or Contention 14.1.3. Process Flexibility or Rigor 14.1.4 Process Maturity 14.1.5 Architectural Ris! 14.1.6 Domain Experience, 14.2. Example: Small-Scale Project versus Large-Scale Project. LOOKING FORWARD Modern Project Profiles. 15.1 Continuous Integration 15.2 Early Risk Resolution. 15.3. Evolutionary Requirements 15.4 Teamwork among Stakeholders. 15.5 Top 10 Software Management Principles 15.6 Software Management Best Practices ‘Next-Generation Software Economics 16.1 Next-Generation Cost Models 16.2 Modern Software Economics . Modern Process Transitions.. 17.1. Culture Shifts 17.2 Denouement. CASE STUDIES AND BACKUP MATERIAL ‘The State of the Practice in Software Management ‘The COCOMO Cost Estimation Model BL COCOMO vrs B2 Ada COCOMO B3 COCOMONCONTENTS _xi APPENDIX C Change Metrics. 283 Cl Overview. (284 C2 Metrics Derivation 286 C21 Collected Statistics 2.2 End-Product Quality Metrics 2.3. In-Progress Indicators... C3 Pragmatic Change Metrics. 288 291 293 297 299 300 APPENDIX D —CCPDS-R Case Study. D.1 Context for the Case Study. D.2_ Common Subsystem Overview. 301 D.3_ Project Organization = 304 Da Common Subsystem Product Overview... senennnnmnees 305 310 312 315 318 321 323 326 337 338 340 343 343 D5 Process Overview ... D,S5.1 Risk Management: Build Content D.5.2_ The Incremental Design Process D.5.3. Component Evolution... D.5.4 The Incremental Test Process .. D.5.8. DOD-STD-2167A Artifacts D.6 _ Demonstration-Based Assessment. D7 Core Metrics. D.7.1 Development Progress D.7.2_ Test Progress D.73 Stability. D.74 Modularity... D.7.5 Adaptability 344 D.7.6 Maturity. = 345 D77 Coston Expenditures by Aas seonnsnnmnes 34S D.8 Other Metrics. ; vn 348 D.8.1 Software Size Evolution 348 1.8.2. Subsystem Process Improvements.. 352 D.8.3 SCO Resolution Profile 353 D.8.4 CSCI Productivities and Quality Factors... 354 D.9 People Factors... 356 D.9.1 Core Team... 337 D.9.2 Award Fee Flowdown Plan. 358 D.10 Conclusions... 359)xii__ CONTENTS APPENDIX E Process Improvement and Mapping to the CMM. E.1 CMM Overview se E.2 Pragmatic Process Improvement 363 363 366 £3 Maturity Questionnaire 367 E44 Questions Not Asked by the Maturity Questionnaire. 387 ES — Overall Process Assessment 390 391 397 401 Glossary References Index...FIGURE 1-1 FIGURE 1.2 FIGURE 1-3 FIGURE 1.4 FIGURE 241 FIGURE 2.2 FIGURE 23 FIGURE 3-1 FIGURE 41 FIGURE 5-1 FIGURE 61 FIGURE 62 FIGURE 63 FIGURE 6-4 FIGURE 65 FIGURE 6-6 FIGURE 6-7 FIGURE 68 FIGURE 6.9 FIGURE 6-10 List of Figures ‘The waterfall model Progress profile of a conventional software project... Risk profile of a conventional software project across its life cycle. Suboptimal software component organization resulting from a requirements-driven approach. Three generations of software economics leading to the target objective. Return on investment in different domains. The predominant cost estimation process. Cost and schedule investments necessary to achieve reusable components The top five principles of a modern process... The phases of the life-cycle process. Overview of the artifact sets..... Life-cycle focus on artifact sets .. Life-cycle evolution of the artifact sets ‘Typical business case outline . Typical release specification outline . ‘Typical software development plan outline... ‘Typical release description outline Artifact sequences across a typical life cycle... ‘Typical vision document outline ‘Typical architecture description outline 12 14 16 23 25 28 39 64 75 85 89 2 7 7 997 100 102 103 105FIGURE FIGURE FIGURE FIGURE FIGURE FIGURE FIGURE FIGURE FIGURE FIGURE FIGURE FIGURE FIGURE FIGURE FIGURE FIGURE FIGURE FIGURE FIGURE FIGURE FIGURE FIGURE FIGURE FIGURE FIGURE FIGURE FIGURE FIGURE FIGURE FIGURE FIGURE FIGURE FIGURE 7 a 82 83 84 oA 92 93 94 10-1 102, 10-3, 10-4 122 123 4 125 126 134 132 133 134 135 136 13.7 Architecture, an organized and abstracted view into the design models. Activity levels across the life-cycle phases The workflow of an iteration ... Iteration emphasis across the life cycle A typical build sequence associated with a layered architecture... A typical sequence of life-cycle checkpoints Engineering artifacts available at the life-cycle architecture milestone Default agendas for the life-cycle architecture milestone .... ‘Typical minor milestones in the lifecycle of an iteration. Conventional work breakdown structure, following the product hierarchy .. Default work breakdown structure Evolution of planning fieley in che WBS over the Planning balance throughout the life cycle... Default roles in a software line-of-business organization... Default project organization and responsibilities. Software management team activities... Software architecture team activities... Software development team activities Software assessment team activites. Software project team evolution over the life eycle ‘Typical automation and tool components that support the process workflows .. Round-trip engineering. The primitive components ofa sofware change order Example release histories for a typical project and a typical product... Organization policy outline Extending environments into stakeholder domains .. Expected progress for a typical project with three major releases... The basic parameters of an earned value system... Assessment of book progress (example ‘Typical staffing profile... Stability expectation over a healthy project lifecycle. Modularity expectation over a healthy project’ life cycle. Adaptability expectation over a healthy project's life cycle... 113 119 121 123 124 127 130 131 133 141 144 147 151 156 159 160 161 162 164 165 169 174 176 179 183 185 191 193 194 196 197 197 198LISTOF FIGURES x FIGURE 13-8 Maturity expectation over a healthy project’ life cyClessnnnsmnnnnnn 198 205 206 FIGURE 13.9 Examples of the fundamental metrics classes.. FIGURE 13-10 Example SPCP display for a top-level project situation... FIGURE 14-1 The two primary dimensions of process variability 210 FIGURE 14-2 Priorities for tailoring the process framework. ve 20 FIGURE 15-1 Progress profile of a modern project... ee 226 FIGURE 15:2 Risk profile of a typieal modern project across its lifecycle . 229 FIGURE 15-3 Organization of software components resulting from a modern process... 230 FIGURE 15-4 Balanced application of modern principles to achieve economic results... 233 FIGURE 16-1 Next-generation cost models... 239 FIGURE 16-2 Differentiating potential solutions through cost estimation .... 240 FIGURE 16-3 Automation of the construction process in next-generation environments... 242 292 270 276 276 FIGURE 17-1 Next-generation project performance. FIGURE B1 Profile of a conventional project FIGURE B2 Software estimation over a project life cycle FIGUREB3 CO 20MO I estimation over a project life cycle.. FIGURE C-1 Expected trends for in-progress indicators. 294 FIGURE C2 Expectations for quality trends. 295 FIGURE D1 CCPDS-R life-cycle overview 302 FIGURE D2 Full-scale development phase project organization. 306 FIGURE D3 Common Subsystem SAS evolution.. 309 FIGURE D-4 Overview of the CCPDS-R macroprocess, milestones, and schedule... 311 FIGURE D-5_ Common Subsystem builds so 313 FIGURE D-6 Basic activities sequence for an individual build sis FIGURE D-7 Incremental baseline evolution and test activity flOW srs 322 FIGURE D-8 CCPDS-R first demonstration activities and schedule 330 FIGURE D9 Development progress summary... 339 FIGURE D-10 Common Subsystem development progress 340 FIGURE D-11_ Common Subsystem test progress. 342 FIGURE D-12. Common Subsystem stability 343 FIGURE D-13 Common Subsystem modularity 344 FIGURE D-14 Common Subsystem adaptability... 345 FIGURE DIS Common Subsystem maturity . 346 FIGURE D-16 Common Subsystem SCO change profile 355 FIGURE E-1 Project performance expectations for CMM maturity levels 365TABLE 1-1 TABLE 1.2 TABLE 3.1 TABLE 3:2 TABLE 33 TABLE 3-4 TABLE 3.5 TABLE 41 TABLE 5-1 TABLE 8-1 TABLE 9-1 TABLE 9-2 TABLE 10-1 TABLE 102 TABLE 124 TABLE 13-1 TABLE 13.2 TABLE 133 TABLE 14-1 List of Tables Expenditures by activity for a conventional software project... Results of conventional software project design reviews... Important trends in improving software economics. Language expressiveness of some of today’s popular languages ‘Advantages and disadvantages of commercial components versus custom software. Three levels of process and their attributes... General quality improvements with a modern process. Modern process approaches for solving conventional problems.. The two stages of the life cycle: engineering and production... The artifacts and life-cycle emphases associated with each workflow The general status of plans, requirements, and products across the major milestones... Default content of status assessment reviews: WBS budgeting defaults... . Defaul distributions of effort and schedule by phase Representative examples of changes at opposite ends of the project spectrum .... Overview of the seven core metrics. ‘Measurement of actual progress of book development (example)... The default pattern of life-cycle metrics evolution... Process discriminators that result from differences in project size.. 13 7 32 34 40 41 49 66 74 120 128 134 148 148 180 189 194 200 213 xviiTABLE TABLE TABLE TABLE TABLE TABLE TABLE TABLE TABLE TABLE TABLE TABLE TABLE TABLE TABLE TABLE TABLE TABLE TABLE TABLE TABLE TABLE TABLE TABLE TABLE TABLE TABLE TABLE TABLE TABLE 142 143 144 14s 146 147 148 49 152, Ma Az AS BA Be Bs Be Bs Bs D4 bs D6 D7 LIST OF TABLES Process discriminators that result from differences in stakeholder cohesion... Process discriminators that result from differences in process flexibility Process discriminators that result from differences in process maturity - Process discriminators that result from differences in architectural risk Process discriminators that result from differences in domain experience Schedule distribution across phases for small and large projects... Differences in workflow priorities between small and large projects... Differences in artifacts between small and large projects, Differences in workflow cost allocations between a conventional process and a modern process.. Results of major milestones in a modern process Technologies used on software projects. Social factors observed on software projects... Factors that affect the success of software projects: OMO project characterization parameters... Effort and schedule partition across conventional life-cycle phases... Default effort allocations across COCOMO WEBS activities. Ada COCOMO improvements to the effort adjustment factors Early design model effort adjustment factors. COCOMO Il post architecture model updates to Ada COCOMO and COCOMO, COCOMO HI process exponent parameters Definitions of collected statistics End-product quality metrics. Definitions of in-progress indicators... CSCI summary. A typical component evolution from creation through turnov NAS CSCI metrics summary at month 10... CCPDS-R software artifacts.. Software development fle evolUtiON. seem SCO characteristics for build 2 BIT testing, Requirements verification work by test type and CSC 24 216 216 217 218 218 219 220 227 231 260 261 262 267 268 269 272 a7 278 281 288 291 293 307 319 320 325 326 341 342TABLE D-8 TABLE D9 TABLE D-10 TABLE Det TABLE D2 TABLE D3, TABLE D-14 TABLE D-15 TABLE Es Common Subsystem cost expenditures by top-level WBS element .. Common Subsystem lower level WBS elements Common Subsystem CSCI sizes... SLOC-to-ESLOC conversion factors.. Common Subsystem CSCI sizes in ESLOC.. CCPDS-R subsystem changes by CSCI Common Subsystem CSCI summary CCPDS-R technology improvements. Industry distribution across maturity levels. LISTOF TABLES _ xix 346 347 349 350 392 354 355 360 364Foreword his book blazes the way toward the next generation of software management prac- tice. Many organizations still cling to the waterfall model because, even with its shortfalls, it provides the most fully elaborated management guidelines on how to proceed in a given software situation. Ichas been difficult to find a fully articulated alternative management approach for dealing with such issues as commercial component integration, software reuse, risk management, and evolutionary/incremental/spiral software processes. This book provides a new experience-tested framework and set of guidelines on how to proceed. Walker Royce developed and tested this software management approach during his inception-to-delivery participation in the large, successful CCPDS-R project per- formed by TRW for the U.S. Air Force. He then refined and generalized it across a wide spectrum of government, aerospace, and commercial software development experiences at Rational. Chapters 1 through 4 of the book motivate the approach by showing how it gives you management control of the key software economics leverage points with respect to traditional software management. These are (1) reducing the amount of software you need to build, (2) reducing rework via improved processes and team- work, and (3) reducing the labor-intensiveness of the remaining work via automation. Chapters 5 through 10 present the specifics of a new organization of the soft- ware life cycle, which also forms the management basis for Rational’s Unified process. It combines the flexibility of the spiral model with the discipline of risk management and a set of major life-cycle phases and milestones. These milestones are focused on major management commitments to life-cycle courses of action. As with our Anchor Point approach at USC, the life-cycle objectives milestone involves a management commitment to engage in a software architecting effort based on a business case analysis (or not to engage, in which case the project is mercifully xxixxii FOREWORD killed). The life-cycle architecture milestone involves a management commitment to proceed into full-scale development based on establishing and demonstrating a sound architecture and resolving all major risk items. The initial operational capability mile- stone involves a management commitment to proceed to beta testing the product with outside users, oF its equivalent. In these chapters, Royce provides a set of views showing how these milestones differ from conventional document-oriented or code-oriented milestones. Instead, the key product artifact sets (requirements, design, implementation, deployment) concur- rently evolve and coalesce in a manner consistent with the project’s objectives and its strategies for controlling risk. In Chapters 10 through 14, Royce addresses how to ensure that the software project’s management artifacts are also concurrently evolving and coalescing. These include the project’s plans and associated cost and schedule estimates, the project’s organization and team-building activities, and the project’s metrics, instrumentation, and control processes. Chapter 14 is particularly noteworthy. It not only emphasizes that the management solutions are situation-dependent, it also provides guidelines for tailoring them to the project's scale, team culture, process maturity, architectural risk, and domain experience. In Chapters 15 through 17, Royce looks forward to where the best software developers are going with their practices: toward product line management, round- trip engineering, and smaller teams with managers as performers and quality assur- ance as everyone’s job. Appendixes relate his software management approach to the current state of the practice, to the COCOMO and COCOMO I family of cost mod- els, and to the SEI Capability Maturity Model, Appendix D provides a convincing case study of how the approach was successfully used on the large, technically chal- lenging CCPDS-R project. Royce has a refreshing candor about some of the fads, follies, and excesses in the software field. This comes out particularly in several “pragmatic” sections that address such topics as software cost estimation, inspections, artifacts, planning, and metrics, Not everyone will agree with all of his assessments, particularly on inspec tions, bur they are incisive and thought-provoking. 1 feel extremely fortunate to have been able to work with both Walker Royce and his equally insightful father, Winston Royce; to have learned from their experi- ences; and to have interacted with them as they evolved their path-breaking ideas. Barry Boehm Director, USC Center for Software Engineering April 1998Preface he software industry moves unrelentingly toward new methods for managing the ever-increasing complexity of software projects. In the past, we have seen evolu- tions, revolutions, and recurring themes of success and failure. While software technol- ogies, processes, and methods have advanced rapidly, software engineering remains a people-intensive process. Consequently, techniques for managing people, technology, resources, and risks have profound leverage. This book captures a software management perspective that emphasizes a bal- anced view of these elements: * Theory and practice * Technology and people * Customer value anid provider profitability © Strategies and tactics Throughout, you should observe a recurring management theme of paramount importance: balance. It is especially important to achieve balance among the objec- tives of the various stakeholders, who communicate with one another in a variety of languages and notations. Herein is the motivation for the part opener art, an abstract portrayal of the Rosetta stone. The three fundamental representation languages inher- ent in software engineering are requirements (the language of the problem space), design (the transformation languages of software engineers), and realizations (the lan- guage of the solution space executable on computers). Just as the Rosetta stone enabled the translation of Egyptian hieroglyphics, software management techniques enable the translation of a problem statement into a solution that satisfies all stakeholders.xxiv PREFACE There is no cookbook for software management. There are no recipes for obvi- ous good practices. I have tried to approach the issues with as much science, realism, and experience as possible, but management is largely a matter of judgment, (un)com- mon sense, and situation-dependent decision making. That’s why managers are paid big bucks. Some chapters include sections with a pragmatic and often hard-hitting treat- ment of a particular topic. To differentiate this real-world guidance from the general process models, techniques, and disciplines, headings of these sections include the word pragmatic. By pragmatic I mean having no illusions and facing reality squarely, which is exactly the intent of these sections. They contain strong opinions and pro- vocative positions, and will strike nerves in readers who are entrenched in some obso- lete or overhyped practices, tools, or techniques. Ihave attempted to differentiate among proven techniques, new approaches, and obsolete techniques using appropriate substantiation. In most cases, I support my positions with simple economic arguments and common sense, along with anecdotal experience from field applications. Much of the material synthesizes lessons learned (state-of-the-practice) managing successful software projects over the past 10 years. On the other hand, some of the material represents substantially new (state-of-the- art), hypothesized approaches that do not have clear substantiation in practice. Thave struggled with whether to position this book as management education or management training. The distinction may seem nitpicky, but it is important. An example I heard 15 years ago illustrates the difference. Suppose your 14-year-old daughter came home from school one day and asked, “Mom and Dad, may Itake the sex education course offered at school?” Your reaction would likely be different if she asked, “May I take the sex training course offered at school?” (This meant less to me then than it does now that my three daughters are teenagers!) Training has an aspect of applied knowledge that makes the knowledge more or less immediately useful. Education, on the other hand, is focused more on teaching the principles, experience base, and spirit of the subject, with the application of such. knowledge left to the student. I have tried to focus this book as a vehicle for software ‘management education. (I am not sure there is such a thing as management training other than on-the-job experience.) I will not pretend that my advice is directly appli- cable on every project. Although I have tried, to substantiate as many of the position statements as possible, some of them are left unsubstantiated as pure hypotheses. I hope my conjecture and advice will stimulate further debate and progress. My intended audience runs the gamut of practicing software professionals, Pri- mary target readers are decision makers: those people who authorize investment and expenditure of software-related budgets. This group includes organization managers, project managers, software acquisition officials, and their staffs. For this audience, I am trying to provide directly applicable guidance for use in today’s tactical decisionPREFACE _XXV making and tomorrow's strategic investments. Another important audience is soft- ware practitioners who negotiate and execute software project plans and deliver on organizational and project objectives. Style Because | am writing for a wide audience, I do not delve into technical perspectives or technical artifacts, many of which are better discussed in other books. Instead, I pro- vide fairly deep discussions of the economics, management artifacts, work breakdown strategies, organization strategies, and metrics necessary to plan and execute a success- ful software project. Ilustrations are included to make these complex topics more understandable. The precision and accuracy of the figures and tables merit some comment. While most of the numerical data accurately describe some concept, trend, expectation, or rela- tionship, the presentation formats are purposely imprecise. In the context of software management, the difference between precision and accuracy is not as trivial as it may seem, for two reasons: 1, Software management is full of gray areas, situation dependencies, and ambiguous trade-offs, It is difficult, if not impossible, to provide an accu- rate depiction of many concepts and to retain precision of the presentation across a broad range of domains. Understanding the difference between precision and accuracy is a funda- mental skill of good software managers, who must accurately forecast est mates, risks, and the effects of change. Unjustified precision—in requirements or plans—has proven to be a substantial, yet subtle, recurring obstacle to success. In many of my numeric presentations, the absolute values are unimportant and quite variable across different domains and project circumstances. The relative values co} stitute the gist of most of the figures and tables. I occasionally provide anecdotal evidence and actual field experience to put the management approaches into a tangible context and provide relatively accurate and precise benchmarks of performance under game conditions. Several appendixes clar- ify how the techniques presented herein can be applied in real-world contexts. My flagship case study is a thoroughly documented, successful, large-scale project that provides a concrete example of how well many of these management approaches can work. It also provides a framework for rationalizing some of the improved processes and techniques. :Xxvi__ PREFACE Organization The book is laid out in five parts, each with multiple chapters: * Part I, Software Management Renaissance. Describes the current state of software management practice and software economics, and introduces the state transitions necessary for improved software return on investment. ‘+ Part II, A Software Management Process Framework. Describes the process primitives and a framework for modern software management, including the life-cycle phases, artifacts, workflows, and checkpoints. * Part Ill, Software Management Disciplines. Summarizes some of the criti- cal techniques associated with planning, controlling, and automating a modern software process. + Part IV, Looking Forward. Hypothesizes the project performance expectations for modern projects and next-generation software economics, and discusses the culture shifts necessary for success. + Part V, Case Studies and Backup Material, Five appendixes provide substan- tial foundations for some of the recommendations, guidance, and opinions presented elsewhere. Acknowledgments Although my perspective of iterative development has been influenced by many sources, Thave drawn on relatively few published works in writing this book. Providing a more detailed survey of related publications might have helped some readers and satisfied some authors, but most of the correlation with my views would be coincidental. The foundation of ny material comes basically from three sources, on which I have drawn extensively: 1. TRW’s Ada Process Model Guidebook [Royce, Walker, 1989]. I wrote this guidebook to capture the process description implemented successfully on a large-scale TRW project so that it could be used throughout TRW. 2. Rational Software Corporation’s software management seminar [Royce, Walker, 1997]. I wrote this two-day seminar on software best practices to describe Rational’s software management approach. The peer reviewers for this material included Don Andres (TRW), Barry Boehm (University of Southern California), Larry Druffel (Software Engineering Institute), Lloyd Mosemann (U.S. Air Force), and Winston Royce (TRW), in addition to numerous field practitioners and executives within Rational. The seminar was delivered dozens of times in the mid-1990s to a broad range of audi- ences, including government groups, defense contractors, and commercial organizations.