Successful software design involves defining what job the software is to perform, writing a design specification which describes in clear terms the solution to performing the job, allocating tasks for detail design and coding, and measuring progress.
A requirements document describes accurately and in detail what the government's problem is. In some cases, this is done during proposal efforts before contract award and, in others, the government has defined requirements in only sketchy terms and the first phase of the contract will involve a significant analysis effort. The requirements document should state what the problem is, not how to solve it.
The design specification is the contractor's solution, chosen from alternatives offered by the design team, on how he is going to solve the customer's problem. The design specifications, (which is the product baseline), should show the solution in terms of a functional description of what the system will do, and also in terms of how the system is structured to perform its functions.
After the design specification is written and accepted by the customer, actual programming can begin. Top-down design allocates the work into modules for detailed design, with allocation of module design to specific individuals. The module design must live within the company manual that defines standard practices, procedures, and conventions for detailed design and coding. The unit development folder has been used by many companies to provide:
a. An orderly and consistent approach to developing
each software unit.
b. A uniform collection vehicle for all unit
documentation and code.
c. Discipline in establishing and achieving
d. Improved management and control over the detailed
design and coding phase.
As the design and coding phases progress, frequent informal reviews (programmers like to call them walk-throughs) should be conducted with a small team of experts to ensure that the detailed design and coding are consistent with the design specification, and to uncover potential interface problems among modules. As coding proceeds, changes in the detailed design often will be found necessary or desirable. As long as these changes do not affect the baseline design and are in accordance with the company standard practices, procedures, and conventions, making these changes is the responsibility of the programmer.
Module testing is a concurrent process with module development. Each module should run flawlessly before attempting to combine it with other modules. Proper interface definition in the design specification will avoid interface problems between modules and with the hardware. Since almost all software will require maintenance after acceptance and delivery, good documentation will enable software maintainers to perform their tasks efficiently in the operational use of the software. Maintenance involves finding and correcting bugs not previously identified, making improvements in the delivered software, and providing enhancements to the system. Definition of the contents of user manuals and design of test plans should be completed as a part of the design phase before programming. These documents provide guidance for the detailed design effort so that the user will have programs that are "user friendly," and the test team will be able to measure the ability of the system to do what the customer wants it to do.