Table of Contents

Cover

Title

PREFACE

1 INTRODUCTION

1.1 INTRODUCTION TO SOFTWARE PROJECT MANAGEMENT
1.2 OBJECTIVES OF THIS CHAPTER
1.3 WHY MANAGING AND LEADING SOFTWARE PROJECTS IS DIFFICULT
1.4 THE NATURE OF PROJECT CONSTRAINTS
1.5 A WORKFLOW MODEL FOR MANAGING SOFTWARE PROJECTS
1.6 ORGANIZATIONAL STRUCTURES FOR SOFTWARE PROJECTS
1.7 ORGANIZING THE PROJECT TEAM
1.8 MAINTAINING THE PROJECT VISION AND THE PRODUCT VISION
1.9 FRAMEWORKS, STANDARDS, AND GUIDELINES
1.10 KEY POINTS OF CHAPTER 1
1.11 OVERVIEW OF THE TEXT
REFERENCES
URLs
EXERCISES
APPENDIX 1A: FRAMEWORKS, STANDARDS, AND GUIDELINES FOR MANAGING SOFTWARE PROJECTS

2 PROCESS MODELS FOR SOFTWARE DEVELOPMENT

2.1 INTRODUCTION TO PROCESS MODELS
2.2 OBJECTIVES OF THIS CHAPTER
2.3 A DEVELOPMENT-PROCESS FRAMEWORK
2.4 TAILORING THE SYSTEM ENGINEERING FRAMEWORK FOR SOFTWARE-ONLY PROJECTS
2.5 TRADITIONAL SOFTWARE DEVELOPMENT PROCESS MODELS
2.6 ITERATIVE-DEVELOPMENT PROCESS MODELS
2.7 DESIGNING AN ITERATIVE-DEVELOPMENT PROCESS
2.8 THE ROLE OF PROTOTYPING IN SOFTWARE DEVELOPMENT
2.9 KEY POINTS OF CHAPTER 2
REFERENCES
URLs
EXERCISES
APPENDIX 2A: FRAMEWORKS, STANDARDS, AND GUIDELINES FOR SOFTWARE DEVELOPMENT PROCESS MODELS
APPENDIX 2B: CONSIDERATIONS FOR SELECTING AN ITERATIVE-DEVELOPMENT MODEL

3 ESTABLISHING PROJECT FOUNDATIONS

3.1 INTRODUCTION TO PROJECT FOUNDATIONS
3.2 OBJECTIVES OF THIS CHAPTER
3.3 SOFTWARE ACQUISITION
3.4 REQUIREMENTS ENGINEERING
3.5 PROCESS FOUNDATIONS
3.6 KEY POINTS OF CHAPTER 3
REFERENCES
EXERCISES
APPENDIX 3A: FRAMEWORKS, STANDARDS, AND GUIDELINES FOR PRODUCT FOUNDATIONS

4 PLANS AND PLANNING

4.1 INTRODUCTION TO THE PLANNING PROCESS
4.2 OBJECTIVES OF THIS CHAPTER
4.3 THE PLANNING PROCESS
4.4 THE CMMI-DEV-V 1.2 PROCESS AREA FOR PROJECT PLANNING
4.5 A MINIMAL PROJECT PLAN
4.6 A TEMPLATE FOR SOFTWARE PROJECT MANAGEMENT PLANS
4.7 TECHNIQUES FOR PREPARING A PROJECT PLAN
4.8 KEY POINTS OF CHAPTER 4
REFERENCES
EXERCISES
APPENDIX 4A: FRAMEWORKS, STANDARDS, AND GUIDELINES FOR PROJECT PLANNING
APPENDIX 4B: ANNOTATED OUTLINE FOR SOFTWARE PROJECT MANAGEMENT PLANS, BASED ON IEEE STANDARD 1058
2 REFERENCES
3 DEFINITIONS
4 PROJECT ORGANIZATION
5 MANAGERIAL PROCESS PLANS
6 TECHNICAL PROCESS PLANS
7 SUPPORTING PROCESS PLANS
8 ADDITIONAL PLANS

5 PROJECT PLANNING TECHNIQUES

5.1 INTRODUCTION TO PROJECT PLANNING TECHNIQUES
5.2 OBJECTIVES OF THIS CHAPTER
5.3 THE SCOPE OF PLANNING
5.4 ROLLING-WAVE PLANNING
5.5 SCENARIOS FOR DEVELOPING A PROJECT PLAN
5.6 DEVELOPING THE ARCHITECTURE DECOMPOSITION VIEW AND THE WORK BREAKDOWN STRUCTURE
5.7 GUIDELINES FOR DESIGNING WORK BREAKDOWN STRUCTURES
5.8 DEVELOPING THE PROJECT SCHEDULE
5.9 DEVELOPING RESOURCE PROFILES
5.10 RESOURCE-GANTT CHARTS
5.11 ESTIMATING PROJECT EFFORT, COST, AND SCHEDULE
5.12 KEY POINTS OF CHAPTER 5
REFERENCES
EXERCISES
APPENDIX 5A: FRAMEWORKS, STANDARDS, AND GUIDELINES FOR PROJECT PLANNING TECHNIQUES

6 ESTIMATION TECHNIQUES

6.1 INTRODUCTION TO ESTIMATION TECHNIQUES
6.2 OBJECTIVES OF THIS CHAPTER
6.3 FUNDAMENTAL PRINCIPLES OF ESTIMATION
6.4 DESIGNING TO PROJECT CONSTRAINTS
6.5 ESTIMATING PRODUCT SIZE
6.6 PRAGMATIC ESTIMATION TECHNIQUES
6.7 THEORY-BASED ESTIMATION MODELS
6.8 REGRESSION-BASED ESTIMATION MODELS
6.9 ESTIMATION TOOLS
6.10 ESTIMATING LIFE CYCLE RESOURCES, EFFORT, AND COST
6.11 AN ESTIMATION PROCEDURE
6.12 A TEMPLATE FOR RECORDING ESTIMATES
6.13 KEY POINTS OF CHAPTER 6
REFERENCES
URLs
EXERCISES
APPENDIX 6A: FRAMEWORKS, STANDARDS, AND GUIDELINES FOR ESTIMATION

7 MEASURING AND CONTROLLING WORK PRODUCTS

7.1 INTRODUCTION TO MEASURING AND CONTROLLING WORK PRODUCTS
7.2 OBJECTIVES OF THIS CHAPTER
7.3 WHY MEASURE?
7.4 WHAT SHOULD BE MEASURED?
7.5 MEASURES AND MEASUREMENT
7.6 MEASURING PRODUCT ATTRIBUTES
7.7 MEASURING AND ANALYZING SOFTWARE DEFECTS
7.8 CHOOSING PRODUCT MEASURES
7.9 PRACTICAL SOFTWARE MEASUREMENT
7.10 GUIDELINES FOR MEASURING AND CONTROLLING WORK PRODUCTS
7.11 ROLLING-WAVE ADJUSTMENTS BASED ON PRODUCT MEASURES AND MEASUREMENT
7.12 KEY POINTS OF CHAPTER 7
REFERENCES
URLs
EXERCISES
APPENDIX 7A: FRAMEWORKS, STANDARDS, AND GUIDELINES FOR MEASURING AND CONTROLLING WORK PRODUCTS

8 MEASURING AND CONTROLLING WORK PROCESSES

8.1 INTRODUCTION TO MEASURING AND CONTROLLING WORK PROCESSES
8.2 OBJECTIVES OF THIS CHAPTER
8.3 MEASURING AND ANALYZING EFFORT
8.4 MEASURING AND ANALYZING REWORK EFFORT
8.5 TRACKING EFFORT, SCHEDULE, AND COST; ESTIMATING FUTURE STATUS
8.6 EARNED VALUE REPORTING
8.7 PROJECT CONTROL PANEL^©
8.8 KEY POINTS OF CHAPTER 8
REFERENCES
URLs
EXERCISES
APPENDIX 8A: FRAMEWORKS, STANDARDS, AND GUIDELINES FOR MEASURING AND CONTROLLING WORK PROCESSES

9 MANAGING PROJECT RISK

9.1 INTRODUCTION TO MANAGING PROJECT RISK
9.2 OBJECTIVES OF THIS CHAPTER
9.3 AN OVERVIEW OF RISK MANAGEMENT FOR SOFTWARE PROJECTS
9.4 CONVENTIONAL PROJECT MANAGEMENT TECHNIQUES
9.5 RISK IDENTIFICATION TECHNIQUES
9.6 RISK ANALYSIS AND PRIORITIZATION
9.7 RISK MITIGATION STRATEGIES
9.8 TOP-N RISK TRACKING AND RISK REGISTERS
9.9 CONTROLLING THE RISK MANAGEMENT PROCESS
9.10 CRISIS MANAGEMENT
9.11 RISK MANAGEMENT AT THE ORGANIZATIONAL LEVEL
9.12 JOINT RISK MANAGEMENT
9.13 KEY POINTS OF CHAPTER 9
REFERENCES
EXERCISES
APPENDIX 9A: FRAMEWORKS, STANDARDS, AND GUIDELINES FOR RISK MANAGEMENT
APPENDIX 9B: SOFTWARE RISK MANAGEMENT GLOSSARY

10 TEAMS, TEAMWORK, MOTIVATION, LEADERSHIP, AND COMMUNICATION

10.1 INTRODUCTION
10.2 OBJECTIVES OF THIS CHAPTER
10.3 MANAGING VERSUS LEADING
10.4 TEAMS AND TEAMWORK
10.5 MAINTAINING MORALE AND MOTIVATION
10.6 CAN’T VERSUS WON’T
10.7 PERSONALITY STYLES
10.8 THE FIVE-LAYER BEHAVIORAL MODEL
10.9 KEY POINTS OF CHAPTER 10
REFERENCES
EXERCISES
APPENDIX 10A: FRAMEWORKS, STANDARDS, AND GUIDELINES FOR TEAMWORK AND LEADERSHIP

11 ORGANIZATIONAL ISSUES

11.1 INTRODUCTION TO ORGANIZATIONAL ISSUES
11.2 OBJECTIVES OF THIS CHAPTER
11.3 THE INFLUENCE OF CORPORATE CULTURE
11.4 ASSESSING AND NURTURING INTELLECTUAL CAPITAL
11.5 KEY PERSONNEL ROLES
11.6 FIFTEEN GUIDELINES FOR ORGANIZING AND LEADING SOFTWARE ENGINEERING TEAMS
11.7 KEY POINTS OF CHAPTER 11
REFERENCES
EXERCISES
APPENDIX 11A: FRAMEWORKS, STANDARDS, AND GUIDELINES FOR ORGANIZATIONAL ISSUES

GLOSSARY OF TERMS

GUIDELINES FOR TERM PROJECTS

INDEX

End User License Agreement

List of Tables

1 INTRODUCTION

TABLE 1.1 Typical constraints on software projects
TABLE 1.2 Some supporting processes for software development
TABLE 1.3 Some work-product documents produced by software projects
TABLE 1A.1 CMMI maturity levels
TABLE 1A.2 Capability levels in the CMMI continuous representations
TABLE 1A.3 Process areas for project management in the continuous representation of CMMI - DEV - v 1.2
TABLE 1A.4 Purposes of the CMMI-DEV-v1.2 processes
TABLE 1A.5 Chapters in the PMBOK^® Guide

2 PROCESS MODELS FOR SOFTWARE DEVELOPMENT

TABLE 2.1 Some ways to obtain software components
TABLE 2.2 Primary emphases of some software development models
TABLE 2.3 Mechanisms of planning and controlling traditional software projects
TABLE 2.4 Some partitioning criteria for incremental builds
TABLE 2.5 Primary mechanisms for planning and controlling iterative projects
TABLE 2B.1 Considerations based on characteristics of the requirements
TABLE 2B.2 Considerations based on characteristics of the project team
TABLE 2B.3 Considerations based on characteristics of the user community
TABLE 2B.4 Considerations based on characteristics of project type and risk factors

3 ESTABLISHING PROJECT FOUNDATIONS

TABLE 3.1 Foundation elements of software projects
TABLE 3.2 Taxonomy of requirements problems and examples
TABLE 3.3 Use case template and example
TABLE 3.4 Categories of technical specifications
TABLE 3.5 Specific requirements in IEEE Standard 830–1998
TABLE 3.6 Traceability of operational features to primary requirements

4 PLANS AND PLANNING

TABLE 4.1 Preplanning activities for software projects
TABLE 4.2A Comprehensive scope of planning activities for software projects (part 1)
TABLE 4.2B Comprehensive scope of planning activities for software projects (part 2)
TABLE 4.3 CMMI-DEV-v1.2 specific goals and practices of project planning
TABLE 4.4A Template for a Software Project Management Plan (part 1)
TABLE 4.4B Template for a Software Project Management Plan (part 2)
TABLE 4.4C Template for a Software Project Management Plan (part 3)
TABLE 4A1.1 Format of a Software Project Management Plan

5 PROJECT PLANNING TECHNIQUES

TABLE 5.1 Some prioritized requirements for ATM software
TABLE 5.2 Fifteen guidelines for designing work breakdown structures
TABLE 5.3A Template for work packages
TABLE 5.3B A work package example
TABLE 5.4 A task list
TABLE 5.5 Milestones for the schedule network in Figure 5.6
TABLE 5.6 Probability of completing a project in time t or less when μ = 12 and σ = 3

6 ESTIMATION TECHNIQUES

TABLE 6.1 A function point example
TABLE 6.2 Examples of external size measures
TABLE 6.3 Probability ranges for a SLIM estimate
TABLE 6.4 COCOMO81 cost drivers and effort multipliers
TABLE 6.5 An example of determining the EAF
TABLE 6.6 Capabilities of software estimation tools [Jones02]

7 MEASURING AND CONTROLLING WORK PRODUCTS

TABLE 7.1 Hierarchy of measurement scales
TABLE 7.2 Responses to a course evaluation survey
TABLE 7.3 Some direct measures
TABLE 7.4 Some indirect measures
TABLE 7.5 Ways to measure requirements
TABLE 7.6 Some product measures for requirements activities
TABLE 7.7 Template for a change request
TABLE 7.8 Template for a defect report
TABLE 7.9 Some product measures for architectural design
TABLE 7.10 Some product measures for software implementation
TABLE 7.11 Distinction between inspections and walkthroughs
TABLE 7.12 Various kinds of reviews and their purposes
TABLE 7.13 Some measures of coupling complexity
TABLE 7.14 Some measures for software cohesion
TABLE 7.15 Some measures for software integration and verification
TABLE 7.16 Some measures for system verification and validation
TABLE 7.17 Reasons humans make mistakes on software projects
TABLE 7.18 Template for a defect report
TABLE 7.19 Template for reporting defect aging by severity level
TABLE 7.20 Template for reporting defects by reporting period
TABLE 7.21 Template for defect matrices
TABLE 7.22 A partial legend for Table 7.21
TABLE 7.23 An example of a defect matrix for a completed project

8 MEASURING AND CONTROLLING WORK PROCESSES

TABLE 8.1 A work package template augmented to report planned versus actual outcomes
TABLE 8.2 A template for rework matrices
TABLE 8.3 A partial legend for Table 8.2
TABLE 8.4 Rework effort in staff-hours for a hypothetical, but realistic, software product
TABLE 8.5 An example of a defect matrix for a completed project
TABLE 8.6 Exponential growth of the effort multiplier to fix a defect for a hypothetical, but realistic, organization
TABLE 8.7 Example of project status using binary tracking
TABLE 8.8 Percentage of effort for various work activities
TABLE 8.9 Earned value terminology

9 MANAGING PROJECT RISK

TABLE 9.1A Quantitative determination of risk exposure levels
TABLE 9.1B Qualitative determination of risk exposure levels
TABLE 9.2 Some commonly occurring risk factors for software projects
TABLE 9.3 Risk factors and risk management techniques
TABLE 9.4 Some techniques for identifying risk factors
TABLE 9.5A Top levels of the SEI risk taxonomy [Carr93]
TABLE 9.5B Some second- and third-level elements of the SEI risk taxonomy [Carr93]
TABLE 9.6 Examples of organizational assets
TABLE 9.7 Ratio-scale equivalents of ordinal symbols
TABLE 9.8 Risk mitigation Strategies
TABLE 9.9 Example of an immediate-action plan
TABLE 9.10 Template for a contingency plan
TABLE 9.11 Example of a contingency plan
TABLE 9.12 Example of a top-N risk repor (N = 8)
TABLE 9.13 Elements of a risk register
TABLE 9.14 Format of a risk reporting form

10 TEAMS, TEAMWORK, MOTIVATION, LEADERSHIP, AND COMMUNICATION

TABLE 10.1 Some attributes of effective leaders
TABLE 10.2 Factors that contribute to efficient and effective software engineering teams
TABLE 10.3 Some antidotes for teamicide
TABLE 10.4 Psychological elements of job satisfaction
TABLE 10.5 Factors that make software engineers happy at work
TABLE 10.6 Four combinations of can’t and won’t
TABLE 10.7 Four situations and leadership styles
TABLE 10.8 MBTI styles and career choices
TABLE 10A.1 Teamicide techniques and examples

11 ORGANIZATIONAL ISSUES

Table 11.1 Elements of organizational culture
Table 11.2 Direct and indirect measures of intellectual capital
Table 11.3 Some key personnel roles for software projects
Table 11.4 Responsibilities of the software architect role
Table 11.5 Responsibilities of the team leader role
Table 11.6 Some software project roles
Table 11.7 Assignment of individuals to roles
TABLE 11.8 An example of a work package
TABLE 11.9 Format of a weekly status report
TABLE 11.10 Agenda and follow – up activities for weekly status meetings
TABLE 11.11 Fifteen guidelines for organizing and leading SETs
TABLE 11A.1 CMMI-DEV-v 1.2 level 2 process areas
TABLE 11A.2 CMMI-DEV-v 1.2 level 3 process areas for projects
TABLE 11A.3 CMMI-DEV-v1.2 level 3 organizational process areas
TABLE 11A.4 CMMI-DEV-v 1.2 levels 4 and 5 processes

List of Illustrations

1 INTRODUCTION

FIGURE 1.1 A workflow model for managing software projects
FIGURE 1.2 A process-oriented functional organization
FIGURE 1.3 A product-oriented functional organization
FIGURE 1.4 A project-oriented organization
FIGURE 1.5 A matrix-structured organization
FIGURE 1.6 The organizational continuum [Youk77]
FIGURE 1.7 An organizational model for software projects
FIGURE 1A.1 Staged representation of the CMMI-DEV-vl.2

2 PROCESS MODELS FOR SOFTWARE DEVELOPMENT

FIGURE 2.1A A workflow model for managing software projects.
FIGURE 2.1B A process framework for developing software-intensive systems
FIGURE 2.2 A simple customer–developer relationship
FIGURE 2.3 Relationships among project stakeholders
FIGURE 2.4 A system-level block diagram for an Automated Teller System
FIGURE 2.5 A development framework for software-only projects
FIGURE 2.6 The Requirements-to-code development model
FIGURE 2.7 Waterfall tailoring of Figure 2.1b
FIGURE 2.8 Traditional depiction of the Waterfall model with milestones
FIGURE 2.9 Relative cost to find and fix a software defect
FIGURE 2.10 Tailoring of Figure 2.5 for the Incremental-build process
FIGURE 2.11 Incremental build–verify–validate–demonstrate cycles
FIGURE 2.12 An Incremental-build example
FIGURE 2.13 Tailoring of Figure 2.5 for the Evolutionary development process
FIGURE 2.14 Management view of the Evolutionary development process
FIGURE 2.15 An Agile development process
FIGURE 2.16 The Sprint development process [Wiki]
FIGURE 2.17 The Spiral meta-model
FIGURE 2.18 A Spiral depiction of the Evolutionary development process
FIGURE 2.19 A Spiral depiction of the Incremental-build process
FIGURE 2.20 A tailored development process

3 ESTABLISHING PROJECT FOUNDATIONS

FIGURE 3.1 A taxonomy of product requirements
FIGURE 3.2 Process-flow of requirements engineering
FIGURE 3.3 Operational features and primary requirements
FIGURE 3.4 Process flow for a software development CCB
FIGURE 3.5 Trend report for baselined requirements

4 PLANS AND PLANNING

FIGURE 4.1 A workflow model for software projects

5 PROJECT PLANNING TECHNIQUES

FIGURE 5.1 Project workflow, emphasizing planning, estimating, and activity definition
FIGURE 5.2 Rolling-wave updating of detailed plans each month
FIGURE 5.3 Three architectural views of software and examples of notations used. The architecture decomposition view (ADV) specifies the hierarchical “is-part-of” relationship among software modules. The ADV is used by project managers (you) to develop the work breakdown structure (WBS)
FIGURE 5.4 A partial architecture decomposition view (ADV) of ATM software
FIGURE 5.5A Tree-structured form of a WBS
FIGURE 5.5B Indented form of a WBS
FIGURE 5.6 A critical-path activity network
FIGURE 5.7 A PERT scheduling network
FIGURE 5.8 Task-Gantt chart corresponding to Figure 5.6
FIGURE 5.9 An augmented task-Gantt chart
FIGURE 5.10 A linked task-Gantt chart
FIGURE 5.11 Staffing profile for earliest start times for all tasks
FIGURE 5.12 Staffing profile for latest start times for all tasks
FIGURE 5.13 A desirable but unobtainable staffing profile for Table 5.4 and Figure 5.6
FIGURE 5.14 A WBS-Gantt chart for a project schedule
FIGURE 5.15 Resource-Gantt chart for Joe Hotshot
FIGURE 5.16 Resource profile for Joe Hotshot

6 ESTIMATION TECHNIQUES

FIGURE 6.1 The estimation process
FIGURE 6.2 A workflow model for managing software projects, emphasizing estimation and re-estimation
FIGURE 6.3 Design to project constraints
FIGURE 6.4A Three fundamental variables of estimation and the resulting solution box
FIGURE 6.4B The constrained solution box in Figure 6.4a
FIGURE 6.5 Function point factors to be counted
FIGURE 6.6 Elements of external size measures
FIGURE 6.7 A Delphi report
FIGURE 6.8 Simultaneous solution of the SLIM equations
FIGURE 6.9 A conceptual view of a SLIM estimate
FIGURE 6.10 A Norden–Rayleigh equation and curve
FIGURE 6.11 Ranges of values for some COCOMO81 effort multipliers
FIGURE 6.12 Derivation of a regression-based estimation model
FIGURE 6.13A Sampling using Monte Carlo estimation
FIGURE 6.13B An effort histogram
FIGURE 6.14 SCED effort multiplier

7 MEASURING AND CONTROLLING WORK PRODUCTS

FIGURE 7.1 A workflow model for software projects with emphasis on measuring, reporting, replanning, and controlling
Figure 7.2 A template for documenting, and an example of a use case
Figure 7.3 State diagram for the use case in Figure 7.2
Figure 7.4 Workflow of a change request process
Figure 7.5 The inspection process
Figure 7.6 A control flow graph and cyclomatic complexity calculation
Figure 7.7 Cyclomatic design complexity
Figure 7.8 Control flow graph for two sequential IF-THEN-ELSE statements
Figure 7.9 A reliability growth model
Figure 7.10 Defect detection and repair process
Figure 7.11 Technical Performance Measurement of memory usage
Figure 7.12 Relationship of the technical measures [Roed05]
FIGURE 7A.1 Closed loop problem resolution
FIGURE 7B.1 Flow diagram for the inspection process

8 MEASURING AND CONTROLLING WORK PROCESSES

FIGURE 8.1 A taxonomy of project effort
FIGURE 8.2 Relative effort to fix a defect
FIGURE 8.3 Illustrating the 95% complete syndrome
FIGURE 8.4 Binary tracking of work packages
FIGURE 8.5 Increased detail in binary tracking of work packages
FIGURE 8.6 An example of earned value reporting
FIGURE 8.7 Earned value projections of Estimated Actual Cost and Estimated Completion Date
FIGURE 8.8 Display from the Project Control Panel^® [PROJCP]

9 MANAGING PROJECT RISK

FIGURE 9.1 A critical-path activity network
FIGURE 9.2 A Monte Carlo estimate of project completion date
FIGURE 9.3 Illustrating a 10% memory threshold for risk management
FIGURE 9.4 Process flow for controlling the risk management process

10 TEAMS, TEAMWORK, MOTIVATION, LEADERSHIP, AND COMMUNICATION

FIGURE 10.1 Dimensions of social styles [Wilson04]
FIGURE 10.2 Five-layer behavioral model of software development [Curtis88]
FIGURE 10.3 Layers of communication in the behavioral model [Curtis88]
FIGURE 10A.1 Maturity levels of the People CMM

11 ORGANIZATIONAL ISSUES

FIGURE 11.1 A workflow model for managing software projects
FIGURE 11.2 An organizational model for software projects
FIGURE 11.3 Augmented rolling-wave planning
FIGURE 11.4 A partial work breakdown structure

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. Hinchey, 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.
Evan Butterfield, Director of Products and Services
Kate Guillemette,Product Development Editor, CS Press

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 science, computing and networking with a special focus on software engineering. IEEE Computer Society members continue to receive a 15% discount on these titles when purchased through Wiley or at wiley.com/ieeecs

To submit questions about the program or send proposals please e-mail kguillemette@computer.org or write to Books, IEEE Computer Society, 10662 Los Vaqueros Circle, Los Alamitos, CA 90720-1314. 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.

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) 750-4470, 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, or online at http://www.wiley.com/go/permission.

Limit of Liability/Disclaimer of Warranty: While the publisher and author have used their best efforts in preparing this book, they make no representations 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 United States at (800) 762-2974, outside the United States 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 may not be available in electronic formats. For more information about Wiley products, visit our web site at www.wiley.com.

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

ISBN: 978-0-470-29455-0

PREFACE

Too often those who develop and modify software and those who manage software development are like trains traveling different routes to a common destination. The managers want to arrive at the customer ‘s station with an acceptable product, on schedule and within budget. The developers want to deliver to the users a trainload of features and quality attributes; they will delay the time of arrival to do so, if allowed. Sometimes the two trains appear to be on the same schedule, but often one surges ahead only to be sidetracked by traffic of higher priority while the other chugs onward. One or both may be unexpectedly rerouted, making it difficult to rendezvous en route and at the final destination.

Managers traveling on their train often wonder why programmers cannot just write the code that needs to be written, correctly and completely, and deliver it when it is needed. Software developers traveling on their train wonder what their managers do all day. This text provides the insights, methods, tools, and techniques needed to keep both trains moving in unison through their signals and switches and, better yet, shows how they can combine their engines and freight to form a single express train running on a pair of rails, one technical, the other managerial.

By reading this text and working through the exercises, students, software developers, project managers, and prospective managers will learn why

managing a large computer programming project is like managing any other large undertaking—in more ways than most programmers believe. But in many ways it is different—in more ways than most professional managers expect.¹

Readers will learn how software projects differ from other kinds of projects (i.e., construction, agricultural, manufacturing, administrative, and traditional engineering projects), and they will learn how the methods and techniques of project management must be modified and adapted for software projects.

Those who are, or will become managers of software projects, will acquire the methods, tools, and techniques needed to effectively manage software projects, both large and small. Software developers, both neophyte student and journeyman/jour- neywoman professional, will gain an increased understanding of what managers do, or should be doing all day and why managers ask them to do the things they ask/ demand. These readers will gain the knowledge they need to become project managers. Those students and software developers who have no desire to become project managers will benefit by gaining an increased understanding of what those other folks do all day and why the seemingly extraneous things they, the developers, are asked to do are important to the success of their projects.

This text is intended as a textbook for upper division undergraduates and graduate students as well as for software practitioners and current and prospective software project managers. Exercises are included in each chapter. Practical hints and guidelines are included throughout the text, thus making it suitable for industrial short courses and for self-study by practitioners and managers.

Chapters 1 through 3 provide the context for the remainder of the text: Chapter 1 provides an introduction to software project management; Chapter 2 covers process models for developing software-intensive systems; Chapter 3 is concerned with establishing the product foundations for software projects.

Chapters 4 through 10 cover the four primary activities of software project management:

Planning and estimating is covered in Chapters 4 through 6.
Measuring and controlling is covered in Chapters 7 and 8.
Managing risk is covered in Chapter 9.
Leading, motivating, and communicating are covered in Chapter 10.

Chapter 11 covers organizational issues and concludes the text with a summary of 15 guidelines for organizing and leading software engineering teams.

For each topic covered, the approach taken is to present the full scope of activities for the largest and most complex projects and to show how those activities can be tailored, adapted, and scaled to fit the needs of projects of various sizes and complexities.

Learning objectives are presented at the beginning of each chapter and each concludes with a summary of key points from the chapter. Occasional sidebars elaborate the material at hand. An appendix to each chapter relates the topics covered in that chapter to four leading sources of information concerning management of software projects:

CMMI-DEV-v1.2 process framework
ISO/IEC and IEEE/EIA Standards 12207
IEEE/EIA Standard 1058
PMI’s Body of Knowledge (PMBOK®)

The text is consistent with the guidelines contained in PMBOK and ACM/IEEE curriculum recommendations.

Presentation slides, document templates, and other supporting material for the text and for term projects are available at the following URL: computer.org/book_extras/fairley_software_projects

Terms used throughout this text are defined in the Glossary at the end of the text. Topics, schedule, and a template for term projects follow the Glossary and included are some hypothetical projects that can be used as the basis for term projects in a course or as examples that practitioners and managers can use to gain experience in preparing software project management plans. Schedule and templates for deliverables for the hypothetic projects are also provided; electronic copies of templates and some software tools are provided at the URL previously cited. Alternatively, practitioners and managers can apply the templates and tools to a past, present, or future project.

A continued example for planning and conducting a project to build the software element of an automated teller system is presented to motivate and explain the material contained in each chapter.

As is well known, one learns best by doing. I strongly recommended that the exercises at the end of each chapter be completed and that progress through the material be accompanied by an extended exercise (i.e., a term project) to develop some elements a project plan for a real or hypothetical software project. The planning exercise can be based on an actual project that the reader has been, is currently, or will be involve in; or it can be based on one of the hypotheticals at the end of the text; or it can be based on a project assigned by the instructor. A week-by-week schedule for completing the term project on a quarter or semester basis is provided. Completion of the planning exercise will result in a report that contains elements similar to those presented in IEEE/EIA Standard 1058 for software project management plans.

The material can be presented in reading/lecture/discussion format or by assigned readings followed by classroom or on-l ine discussions based on the exercises and the term project.

I am indebted to the pioneers who surveyed the terrain, prepared the roadbed, laid down the tracks, and drove the golden spike so that our project trains can proceed to their destinations. Those pioneers include Fred Brooks, the intellectual father of us all; Winston Royce, who showed us systematic approaches to software development and management of software projects; Barry Boehm, who was the first to address issues of software engineering economics, risk management, and so much more; Tom DeMarco, the master tactician of software development, project management, and peopleware; and the many others who prepared the way for this text. I accept responsibility for any misinterpretations or misstatements of their work. My apologies to those I have failed to credit in the text, either through ignorance or oversight.

Thanks to Mary Jane Fairley, Linda Shafer, and the other reviewers of the manuscript for taking the time to read it and for the many insightful comments they offered. Special thanks to the many students to whom I have presented this material and from whom I have learned as much as they have learned from me.

Teller County, Colorado

RICHARD E.(DICK) FAIRLEY