The blueprint of the software created during the design phase is implemented into a software application that is stable, reliable, secure and meets the client’s requirements.

The phases of System Engineering, Analysis and Design allow our engineers to build the detailed blueprint of the software application that is known as the Design Document. The logical and physical designs that compose the Design Document are then converted to a machine language, where software programs are written, data files are constructed and documentation completed.

The order in which program modules will be implemented is determined by the Design Document. Both a bottom-up and top-down approach to organizing the order of module implementation are used. The bottom-up approach will find those low-level modules implemented first, such as ones that perform calculations or input and output operations. These low-level modules are characterized as the workhorses of the application, the processors, and are typically easier to implement and test than their top-level counterparts. Decision-management modules reside at the top-level, while mid-level modules perform control tasks and some work (such as the handling of input and output).

An all-too-common malpractice by many programmers is improper programming style when implementing modules. Good programming style that conforms to a standard set of procedures tremendously benefits the testing, error correction and maintenance of an application. Proper programming style adheres to the following rules:

• A module should be simple to read.
• Variable names should match real-world objects.
• Module prologues should be used (a prologue is a set of comments that define the module’s purpose and its functionality as well as other information such as important variables, other modules it employs or affects, modifications that have been made, the author of those modifications and much more).
• Consistent commenting conventions should be used throughout a module to specify certain processes or characteristics of the module.
• Readability and simplicity of a module should be emphasized over efficiency (a module is only as efficient as it is readable).

Proper and consistent style is critical to the reliability of a program; it allows for more thorough testing and debugging and further ensures the readability of the application. The readability of a program is essential not only to testing but also to modification. For instance, a highly readable program allows programmers other than those who originally wrote the program to step in at any time during the Maintenance stage and quickly understand the program as well as individual modules so changes can be made more easily, quickly and reliably. This removes the need for backward engineering. Backward Engineering requires an engineer or programmer to pore through perhaps thousands of lines of code–oftentimes line by line–and the information system structure to discover how a program and individual modules process data and perform operations. This is a time-consuming and costly endeavor, as one can imagine. Poor programming skills and slapdash software engineering practices result in unreadable and unmanageable applications that will always necessitate backward engineering. And it is entirely avoidable with an engineering approach to the development cycle.

One must realize that there is typically not just one programmer who implements a program but a team. And it is not always the same programmer who maintains the software after it is constructed. A highly readable program is one that allows any programmer, whether one worked on the program before or not, to efficiently correct errors, make modifications, and add and test modules far more quickly and reliably than would otherwise be the case. In fact, unreadable programs can make applications incapable of being tested, corrected and even updated.

All the work leading up to the implementation of an application, the System Engineering, and the Analysis and Design, is absolutely necessary to the engineering of a high-quality application. The details comprise the Design Document, the blueprint and manual for coding, testing, debugging and maintaining the software. Like an expert craftsman, the software engineer translates the Design Document into a software application that is stable, reliable, and secure, one that meets the customer’s requirements and is able to be updated as the client’s needs evolve. The result is an application of superior quality.