When United States government agencies decide to install a new computer system, it is most often accomplished through a joint effort between the agency and one or more contractors. When a new computer system will include new software, specifically developed for the unique needs of the agency, the development effort is governed by extensive engineering and documentation standards. This is true even when the system will include a mix of commercial off-the-shelf (COTS) packages and new code. The value of these standards is as much in the level of communication they force during development as anything else.

The development team has a road map and the agency project team has tools to assess and evaluate the software during every phase of the development. During the requirements phase, the agency's needs and wants are analyzed, and the technological methods and techniques for meeting the needs are determined and documented. There are formal presentations, weeks of scheduled reviews, negotiations, and compromise in order to stay within budget. In the end, there is a great ceremonial meeting where acceptance by the agency is given to proceed with the development of the system.

The design phase is often two-tiered. The first part of the design can be referred to as high level. It is at this level that the grand system and all of its subsystems are clearly defined. The requirements agreed to in the previous phase are clearly mapped to the system design. Decisions are made about how the system will be tested to prove it has met the requirements. Again, there are meetings, reviews, documentation, and a great ceremonial meeting to grant approval to proceed. Another milestone is marked; the low-level design begins and will be followed by other ceremonial meetings at the conclusion of each subsystem design.

By now there are type A specifications, type B specifications, interface specifications, database specifications, project plans, configuration management plans, quality assurance plans, and programmer guidelines at a minimum. There are hundreds, and sometimes thousands, of pages documenting what the system will do, how it will do it, how it will be managed during development, and how it will be tested to ensure it meets the specifications. According to the standards used by the agencies, such as the FAA, the DOD, and the IRS, to name a few, all of this is supposed to occur before a single line of code is written.

During the coding phase, the system is documented in user manuals, operations manuals, and maintenance manuals. Detailed test procedures with expected results and text repeated from previous documents are put into place. Much of the text in the manuals is redundant to the specifications. It is these manuals that will survive when the system goes operational. In some agencies and for some systems, these manuals are maintained throughout the life of the system. In many, they are not. The level of funding justified and made available for development is not extended to maintaining many of the systems or their documentation once they are migrated into production.

This level of documentation may be warranted on mission-critical projects such as software for man-space travel. In most instances, it is sheer overkill and can actually impede the development effort by forcing focus on documentation deliverables while coding and testing time are diminished.

Project Management Made Easy

Project Management Made Easy

What you need to know about… Project Management Made Easy! Project management consists of more than just a large building project and can encompass small projects as well. No matter what the size of your project, you need to have some sort of project management. How you manage your project has everything to do with its outcome.

Get My Free Ebook

Post a comment