Software Project Survival Guideby Steve McConnell
The author of the classics "Code Complete" and "Rapid Development" throws a lifeline to the industry's huge and indispensable population of rookie managers and technical leads. This book is a roadmap to how an effective software project worksunderstandable even for those with limited project experience.See more details below
The author of the classics "Code Complete" and "Rapid Development" throws a lifeline to the industry's huge and indispensable population of rookie managers and technical leads. This book is a roadmap to how an effective software project worksunderstandable even for those with limited project experience.
Consider the Alternative
McConnell's latest book, Software Project Survival Guide, is a recipe for the success of any software project. He has made it easy for project managers to be effective by outlining the items needed for a software project's success in clear, tabular form and giving examples to demonstrate his concepts.
As a bonus, many of these items are online at his web site. In chapter 2, the "Survival Test (http://www.construx.com/survivalguide) sums up the important points presented in the rest of the book. I highly recommend it to everyone. It will give you valuable insight on the possible shortcomings of your own project. In chapter 7 is a "Sample Top Ten Risks List". Using this list as a guide, you'll be better able to identify risks and do contingency planning. And, of course, McConnell doesn't neglect QA plans. Chapter 9 identifies the "Recommended Quality Assurance Practices and Responsibilities for This Book's Work Products."
In a sense, this whole book is about software quality. Software project teams have little hope of delivering their products on time and in budget without ensuring quality throughout their development. McConnell reminds us many times throughout the book:
Researchers have found that an error...tends to cost 50 to 200 times as much to correct late in the project as it does...close to the point where it originally [occurred].
By software quality, I don't mean to say that this book covers only quality assurance (QA) issues. The QA phase is the final stage of a project where defects are found and corrected. Since exhaustive testing is the only way to be sure that software meets its design goals and is defect free, the best way to ensure quality is to build it into the development processes. Otherwise, QA can take enormous amounts of time. It is a major cause for the failure of software projects. In McConnell's view, such processes are the most important part of developing any software project, and they are the only way to be sure that product quality is maintained for the duration of the project.
One of the biggest hurdles that Software Project Survival Guide must overcome is that many programmers view "process" as a four-letter word. They see it as rigid, restrictive, and inefficient. What they don't realize is that they will eventually employ processes in response to situations that could be avoided if only they realized its value. They use processes reactively and may not even be aware that they are using them at all.
This book creates a valuable template for any software project manager to follow. This is especially evident if you look at the two base references McConnell cites in the preface. His interpretation of the models makes it easy for us to benefit from them. The Software Engineering Institute's (SEI) "Key Practices of the Capability Maturity Model, Version 1.1" (http://www.sei.cmu.edu) is a gold mine of hard won industry experience. NASA's Software Engineering Lab's (SEL) "Recommended Approach to Software Development, Revision 3" (http://fdd.gsfc.nasa.gov/seltext.html) describes a structured sequence of practices that may be used to implement many of the processes described in the SEI document.
You can get a good idea of McConnell's views on software project management before reading this book by visiting his web site at (http://www.construx.com/stevemcc). He has included many of the magazine articles he has written. I particularly liked "From Anarchy to Optimizing" (Software Development, July 1993). In fact, I was disappointed that he didn't include this information in his book. This article describes The SEI Process Maturity Model in understandable terms. According to the article, only 1 percent of companies use the methods necessary to reduce cost and improve the quality of their software (Note 1). This means that the ideas McConnell helps to promote are generally not well recognized.
The Software Project Survival Guide doesn't adequately address this point. There is very little discussion of the relationship between creating and using processes (chapter 3) and shipping software (chapter 4). From my experience, when processes are always neglected in the name of shipping product. For example, I was once denied a job because the boss thought I would focus too much on "process" and that it would distract me from the work. And the day before I wrote this review, a coworker told me that he prefers to "get to the work," rather than "waste time in planning a software product." This is truly a prevalent and troubling viewpoint. Personally, I enjoy the planning and design stages because they are creative stages. The implementation seems more like work and it can be frustrating work if the design and planning are hortchanged.
Also, I would have appreciated some comparison of the more common software project techniques. In my career as a consultant, I have seen many methods used to measure and control software development. Although McConnell recognizes that other management methods exist, he makes no attempt to summarize any of the methods in common use. For many programmers, this would help them understand the software project plan that he describes.
Many books on software project management are highly technical and difficult to read, like the SEI and SEL documents. Others are anecdotal, like McCarthy's Dynamics of Software Development, which I reviewed in Dr. Dobb�s Journal in August 1997. Compared to McCarthy's book, McConnell's book presents an ideal approach to project management. McCarthy's book recounts his experiences as a Microsoft project manager. His style is informal, his book is fun to read and can be read quickly, but it will soon be forgotten. When his writing becomes awkward, the information isn't very valuable anyway. In contrast, McConnell's book will be remembered for a long time. He is an experienced wordsmith and develops his ideas with clarity and purpose. Even though it is easy to read, I found myself reading it slowly. Every paragraph has something to offer the reader.
Soon everyone will see the advantage of using the techniques McConnell promotes. The way software is developed is changing, and this book is moving that trend forward. McConnell shows us proven ways to cut defects to one ninth and costs to one fifth of the their present amounts (Note 2). Results like that will get anyone's attention. To stay competitive, many more companies will adopt these methods. They are not difficult, they are not magic, there is no trick to it. They rely on patience, planning, common sense, and adapting from experience. Like McConnell's previous two books, this one will also be widely read; it may even become his most important and most popular book.--Dr. Dobb's Electronic Review of Computer Books
Read an Excerpt
Chapter 8: Requirements DevelopmentDuring requirement development, the software concept becomes tangible through the creation of several versions of the User Interface Prototype and the User Manual/Requirements Specification. This approach facilitates gathering the best possible set of requirements, lays a foundation for excellent architecture work, streamlines the project by eliminating the time-consuming detailed requirements document, and keeps user documentation off the critical path.
Software requirement development is the part of the project during which the needs of the customer are gathered and translated into a specification of what the system must do. Requirement development consists of three related activities:
- Gathering candidate requirements, which is accomplished by interviewing the potential users about the system they want, reviewing competitive products, building interactive prototypes, and so on.
- Specifying requirements, which is accomplished by committing the gathered requirements to tangible media, such as a written requirement document, project storyboards, an interactive User Interface Prototype, or some other medium.
- Analyzing requirements, which is accomplished by looking for commonalties and differences among requirements and breaking them down into their essential characteristics. (This is a preliminary design activity and is not discussed further in this chapter.)
I depart somewhat from common terminology in referring to these activities as requirement development. These activities are often referred to as "specification," "analysis," or "gathering." I use the word development to emphasize that requirements work is usually not as simple as writing down what key user want the software to do. Requirements are not "out there" in the users' minds waiting to be gathered in the same way that iron ore is in the ground waiting to be mined. Users' minds are fertile sources of requirements, but the project team must plant the seeds and cultivate them before the requirements can be harvested.
The most difficult part of requirements gathering is not the act of recording what the users want; it is the exploratory, developmental activity of helping users figure out what they want.
Requirements gathering and specification is an open-ended activity. You can consider the project team to be finished with requirements only when it has achieved a clear, stable understanding of what the users want
The software to do. Abbreviating requirement activities is a costly mistake. For each requirement that is incorrectly specified, you will pay 50 to 200 times as much to correct the mistake downstream--during coding-as you would pay to correct the mistake at requirements time.
OVERVIEW OF THE REQUIREMENTS DEVELOPMENT PROCESSHere are the general steps I recommend to develop requirements:
1. Identify a set of key end users that collectively have the credibility to define the software that the team is building.
2. Interview the end users to create a set of preliminary requirements.
3. Build a simple, interactive User Interface Prototype.
4. Show the simple User Interface Prototype to the key end users and solicit their feedback. Continue revising the simple prototype, keeping it simple, showing it to the end users, and revising it again until the end users are excited about the software concept,
5. Develop a style guide that codifies the prototype's look and feel, review it, and put it under change control.
6. Fully extend the prototype until it demonstrates every functional area of the software. Make the prototype broad enough to cover the whole system, but keep it as shallow as possible. It should demonstrate the functional area, not actually implement it.
7. Treat the fully extended prototype as the baseline specification. Put it under change control. Then require the developed software to match the prototype exactly, except for changes approved through the change control process.
8. Write the detailed end-user documentation based on the prototype. This detailed end-user documentation will become the detailed software specification, and it should also be put under change control.
9. Create a separate, non-user-interface requirements document for algorithms, interactions with other hardware and software, and so on. Put that document under change control.
This set of steps is weighted heavily toward development of interactive software. If the software you are developing is an embedded system that doesn't have a user interface (such as an automobile cruise control), much of the discussion in this chapter won't apply to your project.
The following sections describe the nuances of the steps in the requirement process.
IDENTIFY A SET Of KEY END USERSThe first step in gathering requirements is to identify a set of users who will provide guidance in defining software requirements. These users must be selected in such a way that if they say that a feature is important, you can believe that it truly is important. Likewise, if they say that a feature can be left out, you should be confident that you truly can leave it out. Be sure to include both power users and average users.
If the project is in-house software, the project leaders can recruit a handful of actual users and make the users' involvement with the project part of their job descriptions. If the project is shrink-wrap software, the project leaders can still recruit a handful of actual users. In order to use their time efficiently, they'll need to make sure that interactions with the users are more planned and structured.
Soliciting user input is a critical success factor. What if you can't find any end users and the project grinds to a halt? That might be a blessing in disguise. The project is better off burning only calendar time while you try to find end users than burning both calendar time and money while you build software that users will ultimately reject.
INTERVIEW THE END USERSAn initial set of user interviews should be conducted to elicit a preliminary set of requirements. The preliminary set of requirements is used as the basis for creating the initial, simple User Interface Prototype.
If we've learned one thing in the last 20 years about software developers' abilities to design software that users like, it's that software developers by themselves aren't very good at designing software that users like. But software developers can be very good at helping users discover what they like, because users by themselves aren't very good at designing software they like either.
BUILD A SIMPLE USER INTERFACE PROTOTYPEKeep the prototype as simple as possible. The point of this activity is to present many alternatives. to the user before you commit much effort to any particular approach. The project team should develop just enough to give the user the look and feel of the software they're going for, and nothing more. If you want to prototype a report format, for example, don't even bother to have the User Interface Prototype print the report. The developers should only mock up the report in a word processor and tell the users, "Here's what will come out when you hit the print button."
If the project is being developed in an environment that doesn't have good prototyping tools, consider prototyping on a Windows-based machine and mimicking the look and feel of the target platform. If the real development environment is an IBM mainframe, for example, use Microsoft Visual Basic to mock up screens with green characters and black backgrounds.
Prototyping activity should be performed by a small team of about one to three senior developers. These developers should be skilled at demonstrating a software's look and feel with the least amount of work possible. If developers are taking more than a couple of hours to develop the prototype for any single part of the software, they are doing too much work; they are developing the prototype with too much functional depth. Keep it as shallow as possible.
Developing the prototype in this way helps users visualize the software they are specifying, which minimizes the problem of users not knowing what they want until they see it and then changing their minds later in the project. This kind of prototyping reduces the risk of creeping requirements, which is traditionally one of the most serious risks a software project faces.
Be sure the users understand that the prototype is "just a prototype." One risk of creating a User Interface Prototype is accidentally raising unrealistic expectations about future progress on the project. . . .
and post it to your social network
Most Helpful Customer Reviews
See all customer reviews >