• PAGE ONE
• INDEX
• HOME

Make space for NASA way

Steve McConnell on NASA's dos and don'ts for software success

THE Software Engineering Laboratory (SEL) at NASA's Goddard Space Flight Center has been on the cutting edge of software development practices for almost 20 years. It is one of the most competent, most successful software development organisations in the world. In 1994, in recognition of the extraordinary productivity and software quality it had achieved, the SEL became the first organisation to win the IEEE's award for software process achievement.

You might think that because NASA's software needs to be ultra-reliable, NASA's lessons do not apply to your organisation. But think again. The approach that the SEL follows is one that almost any software organisation can and should follow. It has enabl ed the SEL to achieve productivity comparable to the average information systems project and at the same time achieve quality levels that are at least 10 to 20 times better. To put it a little differently, the average information systems shop would need about 14 calendar months and 110 staff months to deliver a 100,000-line-of-code information 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 e ffort, but it would contain only about 50 defects.

The SEL's Recommended Approach to Software Development crystallises the lessons the SEL has learned over 20 years into a set of nine Dos and eight Don'ts for software project success.

NASA's dos

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, m ajor milestones, and other measures that will be used to track progress. The software development plan should be a living document that 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 members with a project vision, providing the members with a productive environment to work in, and assigning them clear responsibilities and the authority needed to carry out their responsibilities.

Minimise 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 mor e management does not equal more success.''

Define the requirements baseline, and manage changes to it: Stabilise requirements as early as possible. Keep a detailed list of potentially volatile requirements or undefined requirements, and prioritise the list by estimated cost and schedule impact. T ry to resolve these items during architecture or, at the 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 and against similar past projects. If progress deviates significantly from the project plan, replan. Care fully consider reducing the scope of the work when replanning, and try not to be unrealistically optimistic.

Re-estimate system size, effort, and schedules periodically: Each new phase of the project provides new information about the software being built. Do not insist on maintaining the original estimates; instead, plan on refining the estimates at the comple tion 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 its own productivity. What is wrong is not planning to periodically check an estimate's accuracy and not correcting the estimate 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, the end of one stage to the beginning of the next, and so on. The project team should begin prel iminary work on the next phase a few weeks before completing the current phase so that the 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 organisations or companies, emphasise the common vision that every person on the project is working toward. Clearly define each person's individual responsibilities, but emphasise t he 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.

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 pr oject, and are generally in alignment with one another before junior staff are brought on board.

The don'ts

Here are eight don'ts for successful projects:

Don't let team members work in an unsystematic way: Efficient development of high quality software is not a touchy-feely, unmanageable process. It is a creative process, but one that benefits from reasoned application of defined principles, practices, me thods, and techniques. Insist that the team use systematic development practices.

Don't set unreasonable goals: Setting unreasonable goals is worse than setting no goals at all. If the team does not believe in the goals, team members will merely put in their time, punch the clock, and go home. If they are rushed, they will make mistak es 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 impact and obtaining approval of the change board: Estimate the impact of each change-even important, small changes that the project can absorb without rescheduling. The project needs a record of how it cha nged over time, both in major and minor ways. Even when 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. But these changes often have much more far-reaching impact than anticipated by the specific d eveloper who implemented 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. Du ring 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 cut 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 demotivating eff ect. Most developers are quality oriented, and a relaxation of standards sends the message that the customer or upper management does not 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 the United States 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 many as 40,000 pages of paperwor k.

(Edited extracts from Software Project -- Survival Guide. Book courtesy: Word Power, Chennai. e-mail: wpch@satyam.net.in)