Über die Autorin bzw. den Autor

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.

Von der hinteren Coverseite

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.

Aus dem Klappentext

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.

Auszug. © Genehmigter Nachdruck. Alle Rechte vorbehalten.

Managing and Leading Software Projects

John Wiley & Sons

Chapter One

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