Managing and Leading Software Projects - Hardcover

Fairley, Richard E.

Hardcover

ISBN 10: 0470294558 ISBN 13: 9780470294550

Publisher: Wiley-IEEE Computer Society Pr, 2009

Synopsis

• The book is organized around basic principles of software project management: planning and estimating, measuring and controlling, leading and communicating, and managing risk.
• Introduces software development methods, from traditional (hacking, requirements to code, and waterfall) to iterative (incremental build, evolutionary, agile, and spiral).
• Illustrates and emphasizes tailoring the development process to each project, with a foundation in the fundamentals that are true for all development methods.
• Topics such as the WBS, estimation, schedule networks, organizing the project team, and performance reporting are integrated, rather than being relegating to appendices.
• Each chapter in the book includes an appendix that covers the relevant topics from CMMI-DEV-v1.2, IEEE/ISO Standards 12207, IEEE Standard 1058, and the PMI® Body of Knowledge.

(PMI is a registered mark of Project Management Institute, Inc.)

About this title

About the Author

Richard E. (Dick) Fairley, PhD, is founder and Principal Associate of Software Engineering Management Associates (SEMA), a firm specializing in consulting services and training in software systems engineering, software project management, cost estimation, project planning and control techniques, risk management, and process assessment and improvement. He is also an Adjunct Professor of Computer Science and Engineering at Colorado Technical University in Colorado Springs, Colorado. He is a former associate dean, department head, director of software engineering, and professor of computer science at the OGI School of Science and Engineering in Beaverton, Oregon. Dr. Fairley has designed and implemented educational programs in universities and in industry, headed research programs in software engineering, and lectured to and consulted with many companies worldwide.

From the Back Cover

Discover the fundamental techniques for managing and leading software projects

This book bridges the communication gap between project managers and software developers working toward the common goal of developing successful software products and software systems. It provides the insights, methods, tools, and techniques necessary to understand the basic principles of software project management: planning and estimating, measuring and controlling, leading and communicating, and managing risk. It introduces software development methods, from?traditional (hacking, requirements to code, and waterfall) to iterative (incremental build, evolutionary, agile, and spiral), and illustrates and emphasizes how to tailor the development process to specific projects.

By reading this text and working through the exercises provided in each chapter, readers will learn how software projects differ from other kinds of projects (i.e., construction, agricultural, manufacturing, administrative, and traditional engineering projects), and how the methods and techniques of project management can be modified and adapted for software projects.

Three appendices contain a glossary of terms, which is based on and augments IEEE Standard 610; suggestions for term projects; and an annotated template for preparingsoftware project management plans. Additionally, a URL listed in the Preface directs readers to a Web site that provides supporting materials for the text.

Clearly written and easy to follow, this book serves as an accessible textbook for advanced undergraduate- and graduate-level software engineering courses, as well as a valuable reference for software developers and software project managers.

This book bridges the communication gap between project managers and software developers working toward the common goal of developing successful software products and software systems. It provides the insights, methods, tools, and techniques necessary to understand the basic principles of software project management: planning and estimating, measuring and controlling, leading and communicating, and managing risk. It introduces software development methods, from?traditional (hacking, requirements to code, and waterfall) to iterative (incremental build, evolutionary, agile, and spiral), and illustrates and emphasizes how to tailor the development process to specific projects.

By reading this text and working through the exercises provided in each chapter, readers will learn how software projects differ from other kinds of projects (i.e., construction, agricultural, manufacturing, administrative, and traditional engineering projects), and how the methods and techniques of project management can be modified and adapted for software projects.

Three appendices contain a glossary of terms, which is based on and augments IEEE Standard 610; suggestions for term projects; and an annotated template for preparingsoftware project management plans. Additionally, a URL listed in the Preface directs readers to a Web site that provides supporting materials for the text.

Clearly written and easy to follow, this book serves as an accessible textbook for advanced undergraduate- and graduate-level software engineering courses, as well as a valuable reference for software developers and software project managers.

Excerpt. © Reprinted by permission. All rights reserved.

Managing and Leading Software Projects

By Richard E. Fairley

John Wiley & Sons

Copyright © 2009 IEEE Computer Society
All right reserved.
ISBN: 978-0-470-29455-0

Chapter One

INTRODUCTION

In many ways, managing a large computer programming project is like managing any other large undertaking-in more ways than most programmers believe. But in many other ways it is different-in more ways than most professional managers expect. -Fred Brooks

1.1 INTRODUCTION TO SOFTWARE PROJECT MANAGEMENT

When you become (or perhaps already are) the manager of a software project you will find that experience to be one of the most challenging and most rewarding endeavors of your career. You, as a project manager, will be (or are) responsible for (1) delivering an acceptable product, (2) on the specified delivery date, and (3) within the constraints of the specified budget, resources, and technology. In return you will have, or should have, authority to use the resources available to you in the ways you think best to achieve the project objectives within the constraints of acceptable product, delivery date, and budget, resources, and technology.

Unfortunately, software projects have the (often deserved) reputation of costing more than estimated, taking longer than planned, and delivering less in quantity and quality of product than expected or required. Avoiding this stereotypical situation is the challenge of managing and leading software projects.

There are four fundamental activities that you must accomplish if you are to be a successful project manager:

1. planning and estimating, 2. measuring and controlling, 3. communicating, coordinating, and leading, and 4. managing risk.

These are the major themes of this text.

1.2 OBJECTIVES OF THIS CHAPTER

After reading this chapter and completing the exercises, you should understand:

why managing and leading software projects is difficult,

the nature of project constraints,

a workflow model for software projects,

the work products of software projects,

the organizational context of software projects,

organizing a software development team,

maintaining the project vision and product goals, and

the nature of process frameworks, software engineering standards, and process guidelines.

Appendix 1A to this chapter provides an introduction to elements of the following frameworks, standards, and guidelines that are concerned with managing software projects: the SEI Capability Maturity Model(r) Integration CMMI-DEV-v1.2, ISO/ IEC and IEEE/EIA Standards 12207, IEEE/EIA Standard 1058, and the Project Management Body of Knowledge (PMBOK(r)). Terms used in this chapter and throughout this text are defined in a glossary at the end of the text. Presentation slides for this chapter and other supporting material are available at the URL listed in the Preface.

1.3 WHY MANAGING AND LEADING SOFTWARE PROJECTS IS DIFFICULT

A project is a group of coordinated activities conducted within a specific time frame for the purpose of achieving specified objectives. Some projects are personal in nature, for example, building a dog house or painting a bedroom. Other projects are conducted by organizations. The focus of this text is on projects conducted within software organizations. In a general sense, all organizational projects are similar:

objectives must be specified, a schedule of activities must be planned, resources allocated, responsibilities assigned, work activities coordinated, progress monitored, communication maintained, risk factors identified and confronted, and corrective actions applied as necessary.

In a specific sense, the methods, tools, and techniques used to manage a project depend on the nature of the work to be accomplished and the work products to be produced. Manufacturing projects are different from construction projects, which are different from agricultural projects, which are different from computer hardware projects, which are different from software engineering projects, and so on. Each kind of project, including software projects, adapts and tailors the general procedures of project management to accommodate the unique aspects of the development processes and the nature of the product to be developed.

Fred Brooks has famously observed that four essential properties of software differentiate it from other kinds of engineering artifacts and make software projects difficult:

1. complexity,

2. conformity,

3. changeability, and

4. invisibility of software.

1.3.1 Software Complexity

Software is more complex, for the effort and the expense required to construct it, than most artifacts produced by human endeavor. Assuming it costs $50 (USD) per line of code to construct a one-million line program (specify, design, implement, verify, validate, and deliver it), the resulting cost will be $50,000,000. While this is a large sum of money, it is a small fraction of the cost of constructing a complex spacecraft, a skyscraper, or a naval aircraft carrier.

Brooks says, "Software entities are more complex for their size [emphasis added] than perhaps any other human construct, because no two parts are alike (at least above the statement level)." It is difficult to visualize the size of a software program because software has no physical attributes; however, if one were to print a one-million line program the stack of paper would be about 10 feet (roughly 3 meters) high if the program were printed 50 lines per page. The printout would occupy a volume of about 6.5 cubic feet. Biological entities such as human beings are of similar volume and they are far more complex than computer software, but there are few, if any, human-made artifacts of comparable size that are as complex as software.

The complexity of software arises from the large number of unique, interacting parts in a software system. The parts are unique because, for the most part, they are encapsulated as functions, subroutines, or objects and invoked as needed rather than being replicated. Software parts have several different kinds of interactions, including serial and concurrent invocations, state transitions, data couplings, and interfaces to databases and external systems. Depiction of a software entity often requires several different representations to portray the numerous static structures, dynamic couplings, and modes of interaction that exist in computer software.

A seemingly "small" change in requirements is one of the many ways that complexity of the product may affect management of a project. Complexity within the parts and in the connections among parts may result in a large amount of evolutionary rework for the "small" change in requirements, thus upsetting the ability to make progress according to plan. For this reason many experienced project managers say there are no small requirements changes. Size and complexity can also hide defects that may not be discovered immediately and thus require additional, unplanned corrective rework later.

1.3.2 Software Conformity

Conformity is the second issue cited by Brooks. Software must conform to exacting specifications in the representation of each part, in the interfaces to other internal parts, and in the connections to the environment in which it operates. A missing semicolon or other syntactic error can be detected by a compiler but a defect in the program logic, or a timing error caused by failure to conform to the requirements may be difficult to detect until encountered in operation. Unlike software, tolerance among the interfaces of physical entities is the foundation of manufacturing and construction; no two physical parts that are joined together have, or are required to have, exact matches. Eli Whitney (of cotton gin fame) realized in 1798 that if musket parts were manufactured to specified tolerances, interchangeability of similar (but not identical) parts could be achieved.

There are no corresponding tolerances in the interfaces among software entities or between software entities and their environments. Interfaces among software parts must agree exactly in numbers and types of parameters and kind of couplings. There are no interface specifications for software stating that a parameter can be "an integer plus or minus 2%."

Lack of conformity can cause problems when an existing software component cannot be reused as planned because it does not conform to the needs of the product under development. Lack of conformity might not be discovered until late in a project, thus necessitating development and integration of an acceptable component to replace the one that cannot be reused. This requires unplanned allocation of resources and can delay product completion. Complexity may have made it difficult to determine that the reuse component lacked the necessary conformity until the components it would interact with were completed.

1.3.3 Software Changeability

Changeability is Brooks's third factor that makes software projects difficult. Software coordinates the operation of physical components and provides the functionality in software-intensive systems. Because software is the most easily changed element (i.e., the most malleable) in a software-intensive system, it is the most frequently changed element, particularly in the late stages of a project. Changes may occur because customers change their minds; competing products change; mission objectives change; laws, regulations, and business practices change; underlying hardware and software technology changes (processors, operating systems, application packages); and/or the operating environment of the software changes. If an early version of the final product is installed in the operating environment, it will change that environment and result in new requirements that will require changes to the product. Simply stated, now that the new system enables me to do A and B, I would like for it to also allow me to do C, or to do C instead of B.

Each proposed change in product requirements must be accompanied by an analysis of the impact of the change on project work activities:

what work products will have to be changed?

how much time and effort will be required?

who is available to make the changes?

how will the change affect your plans for schedule, budget, resources, technology, other product features, and the quality attributes of the product?

The goal of impact analysis is to determine whether a proposed change is "in scope" or "out of scope." In-scope changes to a software product are changes that can be accomplished with little or no disruption to planned work activities. Acceptance of an out-of-scope change to the product requirements must be accompanied by corresponding adjustments to the budget, resources, and/or schedule; and/or modification or elimination of other product requirements. These actions can bring a proposed out-of-scope requirement change into revised scope.

A commonly occurring source of problems in managing software projects is an out-of-scope product change that is not accompanied by corresponding changes to the schedule, resources, budget, and/or technology. The problems thus created include burn-out of personnel from excessive overtime, and reduction in quality because tired people make more mistakes. In addition reviews, testing, and other quality control techniques are often reduced or eliminated because of inadequate time and resources to accomplish the change and maintain these other activities.

1.3.4 Software Invisibility

The fourth of Brooks's factors is invisibility. Software is said to be invisible because it has no physical properties. While the effects of executing software on a digital computer are observable, software itself cannot be seen, tasted, smelled, touched, or heard. Our five human senses are incapable of directly sensing software; software is thus an intangible entity. Work products such as requirements specifications, design documents, source code, and object code are representations of software, but they are not the software. At the most elemental level, software resides in the magnetization and current flow in an enormous number of electronic elements within a digital device. Because software has no physical presence we use different representations, at different levels of abstraction, in an attempt to visualize the inherently invisible entity.

Because software cannot be directly observed as can, for example, a building under construction or an agricultural plot being prepared for planting, the techniques presented in this text can be used to determine the true state of progress of a software project. An unfortunate result of failing to use these techniques is that software products under development are often reported to be "almost complete" for long periods of time with no objective evidence to support or refute the claim; this is the well-known "90% complete syndrome" of software projects. Many software projects have been canceled after large investments of effort, time, and money because no one could objectively determine the status of the work products or provide a credible estimate of a completion date or the cost to complete the project. Sad but true, this will occur again. You do not want to be the manager of one of those projects.

1.3.5 Team-Oriented, Intellect-Intensive Work

In addition to the essential properties of software (complexity, conformity, change-ability, and invisibility), one additional factor distinguishes software projects from other kinds of projects: software projects are team-oriented, intellect-intensive endeavors. In contrast, assembly-line manufacturing, construction of buildings and roads, planting of rice, and harvesting of fruit are labor-intensive activities; the work is arranged so that each person can perform a task with a high degree of autonomy and a small amount of interaction with others. Productivity increases linearly with the number of workers added; the work will proceed roughly twice as fast if the number of workers is doubled. Although labor-saving machines have increased productivity in some of these areas, the roles played by humans in these kinds of projects are predominantly labor-intensive.

Software is developed by teams of individuals who engage in creative problem solving. Teams are necessary because it would take too much time for one person to develop a modern software system and because it is unlikely that one individual would possess the necessary range of skills. Suppose, for example, that the total effort to develop a software product or system results in a productivity level of 1000 lines of code per staff-month (more on this later). A one million line program would require 1000 staff-months. Because effort (staff-months) is the product of people and time, it would require 1 person 1000 months (about 83 years) to complete the project.

A feasible combination of people and time for a 1000 staff-month project might be a team of 50 people working for 20 months but not 1000 people working for 1 month or even 200 people working for 5 months. The later proposals (1000 1 and 200 5) are not feasible because scheduling constraints among work activities dictate that some activities cannot begin before other work activities are completed: you can't design (some part of a system) without some corresponding requirements, you should not write code without a design specification for (that part of) the system, you cannot review or test code until some code has been written, you cannot integrate software modules until they are available for integration, and so on.

(Continues...)

Excerpted from Managing and Leading Software Projectsby Richard E. Fairley Copyright © 2009 by IEEE Computer Society. Excerpted by permission.
All rights reserved. No part of this excerpt may be reproduced or reprinted without permission in writing from the publisher.
Excerpts are provided by Dial-A-Book Inc. solely for the personal use of visitors to this web site.

Edition details

• Publisher: Wiley-IEEE Computer Society Pr
• Publication date: 2009
• Language: English
• ISBN 10: 0470294558
• ISBN 13: 9780470294550
• Binding: Hardcover
• Edition number: 1
• Number of pages: 512