- Shopping Bag ( 0 items )
This project management guide for technical leaders and managers distills practical wisdom from the author's prior publication, Rapid Development. It also includes management requirements and standards from IEEE's "Key Practices of the Capability Maturity Model, Version 1.1" and the NASA SEL``s "Recommended Approach to Software Development, Revision 3."
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
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:
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.
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.
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.
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.
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. . . .
Posted January 9, 2003
This is an excellent guide to doing large software projects (10 man months minimum) well. Not only does it tell one what the right steps are, but also what difficulties one may encounter and good ways to get around them. Unfortunately, most situations I've seen lately are for many micro-projects (a.k.a. feature enhancements) which, I think, require a somewhat different methodology.Was this review helpful? Yes NoThank you for your feedback. Report this reviewThank you, this review has been flagged.
Posted October 3, 2002
McConnell's methodology is concise, lightweight, and yet it will help you avoid many of the risks rapid development projects face. Buy this book, if only for the checklists!Was this review helpful? Yes NoThank you for your feedback. Report this reviewThank you, this review has been flagged.
Posted March 17, 2001
This is a good intermediate book for even programmers. Good intro to Rapid Development. Also good for members of a project who overseers and have less knowledge of software.Was this review helpful? Yes NoThank you for your feedback. Report this reviewThank you, this review has been flagged.
Posted January 29, 2001
I am a programmer and so most of the wisdom in the book are things that I already know. However I think the book would be of value to you if you are a manager who is NOT a software engineer. The book is easy to read and spells out what you need to do to manage a medium sized software project.Was this review helpful? Yes NoThank you for your feedback. Report this reviewThank you, this review has been flagged.
Posted May 6, 2011
No text was provided for this review.
Posted April 10, 2010
No text was provided for this review.