Read an Excerpt
- I wake up each morning determined to change the World and also to have one hell of a good time. Sometimes that makes planning the day a little difficult.
- E.B. White
This book is written for technical managers who wish to be successful in the use of object-oriented technology. It contains our advice, distilled from 20 years of direct experience in the creation and use of the technology--programming languages, development tools, and methods for analysis and design.
What This Book is About
Our original intent was to present a prescription that details, step by step, what an organization--its managers, developers, support teams, and customers--should do to be successful in the use of object-oriented technology. The prescription was going to be something like: Plan so that incremental results will be delivered every three months; use "some language" as the programming language; limit team size to no more than eight developers, including a tester, documentor, and code librarian; and assign a corporate-funded reuse engineer to each team. However, no single prescription for managing object-oriented technology was appropriate. Differences in culture and long- and short-term goals create remarkably large variations in a potential prescription. A company might have only C programmers who believe C++ is easier to learn. A company that is accustomed to project staffs with 40 or 50 developers might not appreciate how to do the work with only eight. And some companies have no structure with which to support and finance a corporate-level competency center staffed withreuse engineers.
What we have written instead is an explanation of how to construct your own prescription. We examine the decisions you need to make, and the issues that enter into the decision-making process. Each related decision has to be made in a coordinated fashion, one leading to the other so as to provide a coherent project-management plan. Although you are the one who needs to make these decisions for your organization, we do make recommendations, and we tie these recommendations to the conditions under which we have seen success and failure. Specifically, we provide examples of decisions derived from 39 project case studies we conducted over a four-year period.
Object-oriented technology involves organizational change. Objects suggest new ways to develop software that alter the relationship between customers and developers, and between developers and business experts. Objects influence how development teams acquire the skills needed for effective use of new analysis, design, implementation, testing, and integration techniques. A commitment to objects is a commitment to change your organization's structure, processes, and resources. This book helps you manage the changes that attend object-oriented technology.
Our emphasis in this book is on project-management practices for professional software development teams. Although we are object advocates, we do not try to sell you on objects alone. Rather, we are interested in showing you the benefits that come from applying object-oriented technology in the context of good project management.
Who Should Read This Book
We expect the reader to be an information systems project manager or a manager of technical managers, someone with a desire to find better processes and techniques for building software systems. This person may not have caught the object wave yet, but is trying to learn what is involved in committing his or her organization to the use of the technology. Most likely, this person will be a project leader when the organization initiates its first object-based project, and will be involved in making many of the management decisions we propose.
Although this book is written for a project manager, everyone involved with the project team should read it to understand their roles within an organization that is using object-oriented technology. We do not assume that the reader has experience in the use of object-oriented technology, so we provide a managerial introduction to the basic concepts. We also provide an overview of the important issues related to managing software projects: planning, organizing, staffing, directing, and controlling. As such this book can serve as the blueprint for a basic software engineering course. To support this objective, we include additional readings about each topic. This book is not intended to be a substitute for the literature on object-oriented languages, databases, tools, or other technical aspects that you might wish to study.
Broadly, the book is organized around a set of frameworks for helping you make management decisions affecting software projects. Chapter 1 defines the essential characteristics of a decision framework--its principles, goals, maxims, and decisions. In Chapter 2, we introduce the first decision framework: Defining project goals and objectives. We define what we mean by a project, setting the stage to explain the kinds of process-improvement and resource-improvement projects that are needed to base software development effectively on the use of object-oriented technology.
A brief managerial overview of object-oriented technology --defining the concepts and terminology--is provided in Chapter 3. The primary focus of the chapter is to point out the benefits of using the technology in the context of the second decision framework, which asks you to examine what you value in products, processes, and resources, and to decide what about objects can help you obtain what you value. Constructing this value proposition for objects is the first step in creating the organization's rationale for a long-term commitment to the technology.
The next chapter, Chapter 4, discusses how to get started with object-oriented technology to fulfill your value proposition. We suggest that you initiate a first software development project in advance of having the details about how to transition your organization to one in which objects are effectively employed. The details make more sense if you have some experience and if you are ready to make a commitment to the strategic use of the technology. Indeed, many companies will not make a commitment to new technology until they can assess the outcome of a first project. You may also decide to initiate a special technology center to provide a focal point for gathering and assessing information about object-oriented technology.
- Selecting a product process model
- Setting up a project schedule and controlling to meet the schedule
- Selecting a reuse process model
- Selecting a project team structure
- Selecting a software development environment
- Setting up a training plan
- Selecting measures for assessing, controlling, and predicting process, resource, and product attributes
These seven topics are covered in the following 16 chapters. Process models plus planning and control take up the first four of these chapters. Reuse, covered in the next three chapters, focuses on the process needed to make systematic reuse a reality. We do not provide a technical explanation of how to design for reuse, as that level of detail is outside the scope of management concerns. The discussion of team structures and how they relate to the goals of a project is presented in the next two chapters. (We have relegated the important but detailed job descriptions for team roles to an appendix.) Software development environments--what they are and how to select them--take up the next four chapters. These chapters include definitions and criteria for selecting analysis-and-design method tools, programming languages, libraries, tools, and databases. Chapters 18 and 19 review subject areas and proficiency levels required by members of a team using object-oriented technology, and describe the kinds of training that can be used effectively with the different team members. And then Chapter 20 encourages you to set up a software measurement program, with the goal of measuring progress on individual projects and on transitioning your organization into one that is a mature user of objects. The last chapter recapitulates our main recommendations, restated as the pitfalls of poor decision making.
We conducted case studies of 39 projects that used object-oriented technology. These case studies, along with our own experiences, are used to illustrate the decision frameworks and our recommendations. The demographics of the case studies are relegated to an appendix, best read only by those curious about the source of this information.
When and How to Read This Book
We offer ten project-management decision frameworks, each of which is defined by a principle, a goal, several steps, and several maxims. To help you identify these framework elements, look for the following symbols in the margins. They mark where each element is introduced, and look like this:
- Framework Principle. You should know where you are going, so you will know whether you have arrived.
- Framework Goal. Set realistic expectations for how object-oriented technology can help you to achieve your software development goals and objectives.
- Make the decision to use objects
- Obtain an initial management commitment to the use of objects
- Select an initial process model and software development environment
- Select and set up an initial pilot project
- Assess the outcome of the initial pilot project
- Confidence comes from the planning process, not from the plan.
There are three possible pathways through the book, depending on your primary interests and level of involvement with object-oriented technology: a fast track, to review the decision frameworks; a foundation track, to explore fundamental concepts and acquire a basis for making choices; and an adoption track, to find information as you need it.
FAST TRACK. This book contains a lot of detail, not all of which is necessary or appropriate to cover on your first reading. The detail will be important when you actually have to do the work--when you have to set up a project, decide on the team members, plan a training program, set up a corporate reuse program, determine which measures give you the information you need, and so on.
To help you circumvent the details, we provide a list in Table P.1 (click here for HTML version 3.0 compatible version of this Table P.1) of the chapter sections (including their subsections) that offer a quick path through the guidelines. The fast track includes only those sections that describe the principles, goals, maxims, and steps of the project-management decision frameworks. In addition to the listed sections and tables or figures, you should read the chapter opening and the summary provided at the end of each chapter. The fast-track material assumes a knowledge of terminology and of background material provided in other chapters, which you can read opportunistically.
FOUNDATION TRACK. Any reader who is uncertain about the terminology we use, or about the fundamental concepts underlying the proposals we make, should read the chapters in the foundation track. This track consists of Chapters 1 through 3 plus the chapters listed in Table P.2 (click here for HTML version 3.0 compatible version of this Table P.2) that have a check mark in the column titled "Definitions and Choices." The material in this part of the book presents our opinions about how to make the various project-management decisions.
Table P.2 provides additional pathway information. Case studies contain the experiences of other practitioners and illustrate many of the decisions in the project-management decision frameworks. In Table P.2, we placed a check mark next to the chapters that include case study illustrations. The table also identifies which chapters contain the descriptions of the frameworks themselves.
ADOPTION TRACK. You can also read this book in an opportunistic fashion. First read Chapters 1 through 3. You are then ready for your first project. Chapter 4 can help you select this project. The decisions you make to formulate and carry out a product development project are typically ordered as follows: set goals and objectives, select the project process model, create a plan including how to measure progress and results, select the team, select the tolls, train the team, carry out the project, revisit the process and planning decisions with the team, and intermittently assess progress and results. As you come to each of these steps, you can read the relevant chapters on each framework, as cited in groups in Table P.2, independently. If you are setting up a reuse program, you will also want to pay special attention to the three chapters on a reuse process model.
This book has taken a long time to complete. At times our confidence that we could distill our experiences rationally would falter--these were the times when we would encounter a new client with an even newer kind of problem., It took some time to realize that the ever-changing problem situations were, in fact, the key to writing a book of value. We then stopped looking for answers and started formulating the questions. We thank our clients and the people who attended our courses and talks, spread over five continents and as many years, for sharing their time and experience.
We thank the 26 organizations willing to open their project doors to us, allowing us to participate in their projects and project postmortems. We hope they will understand that our nondisclosure agreements with their companies prevent us from naming them here. We also appreciate the assistance of our colleagues at ParcPlace Systems for being willing sounding boards: Tw Cook, Marek Jeziorek, David Leibs, K. Ross Looney, Patrick McClaughry, Paul McCullough, David Pellegrini, Mike Robicheaux, and David Smith.
A special debt of appreciation goes to our reviewers, who patiently explained where our explanations could be greatly improved. Thank you to: Brian Alexander, Dennis Allison, Mike Crooks, John Davis, James Falek, Steve Fraser, Martin Griss, Marie Lenzi, William Lively, and Efrem Mallach. We hope we did justice to John and Martin's extensive suggestions. And we are especially indebted to Dennis, whose forcefulness in getting us to rewrite the original draft undoubtedly led to a more readable and acceptable manuscript.
Our special and fondest thanks to our personal artist, Rebecca Cannara, who provided the cartoon artwork that resulted in the cover characters, the team role characters, and the many chapter cartoon illustrations.
Finally, we would like to thank the folks at Addison-Wesley whose careful eyes and ears allowed us to produce a quality edition--to Peter Gordon, who has been our book mentor for many years, and to the editorial and production staff, including Robert Chamberlain, Helen Goldstein, Eileen Hoff, Margo Shearman, and Helen Wythe.
Adele and Kenny
Palo Alto, California