| This book’s key guidelines are presented in
combination with key guidelines from one of the world’s most effective software
development organizations. The end of the chapter provides pointers to additional reading
and other resources. |
This chapter summarizes the elements needed for software project
success. It distills the main messages of this book into a few pages.
The first section overviews the approach used by one of NASA’s
software development organizations. The second describes resources you should consider
adding to your personal software survival kit.
NASA’s Success Checklist
The Software Engineering Laboratory at NASA’s Goddard Space Flight
Center has been on the cutting edge of software development practices for almost 20 years.
The Software Engineering Laboratory (SEL) is one of the most competent, most successful
software development organizations in the world. In 1994, in recognition of the
extraordinary productivity and software quality it has achieved, the SEL became the first
organization to win the IEEE’s award for software process achievement.
If you think that NASA’s software needs to be ultra-reliable and
their lessons don’t apply to your organization, think again. The SEL has achieved
productivity comparable to the average MIS or IT system, at the same time achieving
quality levels that are at least 10 to 20 times better. To put it a little differently,
the average MIS shop would need about 14 calendar months and 110 staff-months to deliver a
100,000 line-of-code MIS system, and it would typically contain about 850 defects when
delivered. The NASA SEL would deliver a system of that size with about the same amount of
time and effort, but it would contain only about 50 defects.
The SEL’s Recommended Approach to Software Development
crystallizes the lessons the SEL has learned over 20 years into a set of 9 Dos and 8
Don’ts for software project success, which are presented here.
NASA SEL’s Dos for Software Success
Here are nine elements of a successful project.
Create and follow a Software Development Plan.
At the beginning of the project, prepare a Software Development Plan that describes
the project’s vision, defines the team structure, and defines the development
methods. The plan should include estimates, major milestones, and other measures that will
be used to track progress. The SDP should be a living document, which is updated at the
end of each major phase or stage.
Empower project personnel.
Tap into the project’s human potential by aligning the development team on a
project vision, providing them with a productive environment to work in, and clearly
assigning responsibilities and the authority needed to carry out their responsibilities.
Minimize the bureaucracy.
Establish the minimum amount of process overhead needed to satisfy the project’s
objectives. Be sure that there is a good reason for required meetings and paperwork. As
NASA says, "More meetings plus more documentation plus more management does not equal
more success."
Define the requirements baseline and manage changes to it.
Stabilize requirements as early as possible. Keep a detailed list of potentially
volatile requirements or undefined requirements, and prioritize the list by estimated cost
and schedule impact. Try to resolve these items during architecture or, at latest, during
detailed design.
Take periodic snapshots of project health and progress, and replan
when necessary.
Regularly compare the project’s progress against the project plan. Also compare
the project’s progress against past similar projects. The project plan should be
based on experience from past similar projects. If there is a significant deviation from
the project plan, replan. Carefully consider reducing the scope of the work when
replanning, and try not to be unrealistically optimistic.
Reestimate system size, effort, and schedules periodically.
Each new phase of the project provides new information about the system being built.
Do not insist on maintaining the original estimates, but plan on refining the estimates at
the completion of each major milestone. Estimation is an inexact science, and there is
nothing wrong with finding that the development team underestimated the project’s
size or overestimated their own productivity. What is wrong is not to plan to periodically
check an estimate’s accuracy and correct it as the project progresses.
Define and manage phase transitions.
Some projects lose time in the transition from requirements development to
architecture, architecture to stage planning, end of one stage to beginning of the next,
and so on. Begin preliminary work on the next phase a few weeks before completing the
current phase so that the project team as a whole can make an efficient transition to the
next phase.
Foster a team spirit.
Even when a project includes people from different organizations or companies,
emphasize the common vision that every person on the project is working toward. Define
each person’s individual responsibilities clearly, but emphasize the whole-project
context within which those responsibilities exist. Be sure to communicate status, risks,
and other management issues throughout the project in the same way.
No individual is a success who hurts the team and no
individual is a failure who helps it.
Start the project with a small senior staff.
Begin the project with a small group of experienced senior people who will provide
leadership throughout the project. Be sure they establish a vision, define the software
concept, develop an approach to the project, and are generally in alignment with each
other before junior staff are brought on board.
NASA SEL’s Don’ts for Software Success
Here are eight things that successful projects do not do.
Don’t let team members work in an unsystematic way.
Efficient development of high-quality software is not a touchy-feelly, unmanageable
process. It is a creative process, but one that benefits from reasoned application of
defined principles, practices, methods, and techniques. Insist that the team use
systematic development practices.
Don’t set unreasonable goals.
It is worse to set unreasonable goals than to set no goals at all. If the team
doesn’t believe in the goals, they will merely put in their time, punch the clock,
and go home. If they are rushed, they will make mistakes upstream that cost fortunes to
correct downstream. Set reasonable, moderately challenging goals, and the team will
stretch to meet them without damaging project efficiency.
Don’t implement changes without assessing their impacts and
obtaining approval of the change board.
Estimate the impacts of each change—even important, small changes that the
project can absorb without rescheduling. The project needs a record of how it changed over
time, in both major and minor ways. Even if a particular change does not have a large
impact, small changes add up over time and will eventually cause cost and schedule
overruns if not controlled.
Don’t "gold-plate."
Implement only what is required. Developers, managers, and customers often think of
small, easy changes that seem to make the software better. These changes often have much
more far-reaching impacts than anticipated by the specific developer who will implement
the change. Do not let additional complexity creep into the project through gold-plating.
Don’t overstaff, especially early in the project.
Start the project with a small senior team. Bring additional people onto the project
only when there is meaningful work for them to do. This guideline does allow for some
early use of junior personnel. During requirements and early architecture, relatively
junior staff members can review documents, investigate capabilities of tools and code
libraries, and perform many other tasks that require good technical skills but not guru
level standing.
Don’t assume that a schedule slip in the middle of a phase will
be made up later.
One common mistake is to assume that productivity will improve as the project
progresses from the beginning of a phase to the end. Productivity might improve slightly,
but there isn’t enough time within any particular phase to make up time. More
generally, do not assume that a schedule slip at any point in the project can be made up
later. If the project doesn’t catch up soon after a slip is detected, you can safely
assume that it won’t be possible to catch up.
Don’t relax standards in order to cuts costs or shorten a
schedule.
Relaxing standards tends to introduce errors into the project, and optimum project
cost and schedule both depend on eliminating errors. Relaxing standards can also have a
demotivational effect. Most developers are quality oriented, and a relaxation of standards
sends the message that the customer or upper management doesn’t care about quality.
Don’t assume that a large amount of documentation ensures
success.
Different projects require different kinds of documentation support. Determine the
amount and kind of documentation required based on the project size, schedule, and
expected lifetime of the system. Avoid U.S. Department of Defense style documentation in
which a 25,000 line of code program could easily require 5000–10,000 pages of
paperwork, and a 100,000 line of code program could require as much as 40,000 pages of
paperwork.
Other Survival Resources
This book is a software survival guide. You might think of it as the
first aid kit you carry in your backpack or car. Just as hospitals are medically better
equipped than the back of your car, the universe of other software development resources
will provide you with many more survival tools than this short guide presents.
Books
Here are some books that provide especially good insights mixed with
practical advice.
Recommended Approach to Software Development, Revision 3,
Document SEL-81-305, Greenbelt, Maryland: NASA Goddard Space Flight Center, NASA, 1992.
The Software Engineering Laboratory’s Recommended Approach is probably the
most practical overview of how to run a software project that I have read. It is intended
for use specifically with flight dynamics projects, but many of its recommendations are
much more broadly applicable. The book describes entry criteria and exit criteria for each
project phase, and gives cogent summaries of the development team, management team, and
various tiger team activities within each phase. The book is worth reading solely for the
sense it projects that software projects are not mysterious, hard-to-control entities, but
merely extremely complex entities that can be controlled through diligent application of
lessons learned from previous projects. You can obtain a single copy for free by emailing
NASA SEL from http://sel.gsfc.nasa.gov/doc-st/orderdoc.htm.
You can also download the document from the SEL’s website at http://sel.gsfc.nasa.gov/.
Manager’s Handbook for Software Development, Revision 1,
Document SEL-84-101, Greenbelt, Maryland: NASA Goddard Space Flight Center, NASA, 1990.
The SEL’s Manager’s Handbook is almost as useful as the Recommended
Approach. It is shorter, and the guidelines it presents are focused specifically on
software project management topics. You can order it or download it in the same ways as
the Recommended Approach
Fergus O’Connell. How to Run Successful Projects II: The
Silver Bullet. London: Prentice Hall International (UK) Limited, 1996.
O’Connell’s book provides a well-written, end-to-end examination of what is
needed to run a successful software project. It covers the same ground as the book
you’re reading now and is quite compatible with it, but there is surprisingly little
overlap. Whereas this book provides a big picture technical framework for a project,
O’Connell’s book focuses on the many specific activities a project manager must
perform. It includes many example project forms and planning materials. If, in reading
this book you’ve asked yourself, "This all sounds good, but what do I do?"
then O’Connell’s book is the right book for you.
Tom Gilb. Principles of Software Engineering Management.
Wokingham, England: Addison-Wesley, 1988.
Gilb’s book puts the "engineering" into software engineering management
by taking a quantitative, risk-oriented approach to conducting a software project. It is
based on Gilb’s considerable experience as an internationally renowned software
project management consultant. This is not the book to read to learn the conventional
wisdom about software project success—it takes its own path too often for that. But I
think that in the vast majority of cases in which it doesn’t follow the conventional
wisdom, it is because Gilb is right and the conventional wisdom is wrong.
Lawrence H. Putnam and Ware Myers. Industrial Strength Software:
Effective Management Using Measurement, Washington: IEEE Computer Society Press, 1997.
Putnam and Myers have created an excellent reference that describes how to use
software measurement to manage all aspects of software development. In contrast to
Gilb’s book, Putnam and Myers’s book focuses less on specific projects and more
on organizational capability. Chapter 21, "Shining Shadow Loses its Luster," is
a special gem—dramatically illustrating the power of quantitative approaches to
software project management.
Tom DeMarco and Timothy Lister. Peopleware: Productive Projects
and Teams. New York: Dorset House, 1987.
Peopleware drives home the message that programming is first and foremost
something done by people and only secondarily something that happens to involve computers.
It’s entertaining reading, providing memorable stories about software teams that
worked and teams that didn’t.
Alan M. Davis. 201 Principles of Software Development, New
York: McGraw-Hill, 1995.
201 Principles provides an easy-to-read introduction to the critical issues in
software development. Davis’s book prepares you to recognize key issues when other
books discuss them and when they crop up on your own projects.
Steve McConnell. Rapid Development. Redmond, WA: Microsoft
Press, 1996.
If you’ve liked this book, you will probably also like what I have to say in Rapid
Development. It contains general, but still practical, discussions of classic
mistakes, risk management, lifecycle planning, scheduling, motivation, teamwork, and many
other topics related to rapid software development.
Internet Resources
My company has created a survival guide website at http://www.construx.com/survivalguide/.
It includes examples of many of the sample documents and forms this book recommends such
as the Software Development Plan, User Interface Style Guide, estimation procedure,
release signoff form, and many more. It contains links to software development resources
on other websites including current links to source code control tools, time accounting
tools, estimation software, and defect tracking tools. It contains electronic versions of
this book’s Survival Checks and a spreadsheet version of Chapter 2’s Software
Project Survival Test.
|
