At my company I have seen a lot of bad software development practices over the years, so I have created a set of software development guidelines to help establish a set of best practices and baseline software requirements. I am publishing a series of experts from those guidelines here so that I might get some useful feedback that will help improve them.
Any software written for use in the Company should not only perform in a consistent manner, but it should also perform reliably and in accordance with the users’ expectations. In order to accomplish this programmers must plan how the software should work, continually test the application as it is developed (unit testing, integration testing, functional testing, etc.), and must thoroughly test the application to ensure that it is operating as planned before it is released into a production environment.
Each release needs to have a unique release or build number. The release or build number should be easy to identify and there should be a ‘change log’ that identifies the changes and bug fixes that occurred between each release. Using a revision control software such as Subversion would suffice to fulfill this requirement.
If a program relies on external files this needs to be documented. An administrator should know exactly which files and which versions of those files are required to make a program operate correctly. For interpreted programs, the interpreter version needs to be documented. The programmer should attempt to make an interpreted program version neutral and ensure that the required interpreter version does not interfere with any other existing programs’ version requirements. All of this should be provided in the technical documentation.
Once the program has been completed it needs to go through a formal testing process. The initial testing should be whether the software meets the requirements set forth in this document and in the requirement and platform specification. Then the application should be tested for consistency, usability, reliability, maintainability, and efficiency.
All testing must occur on standard Company equipment, it is not sufficient to test an application using a development computer.
The IT department must approve all software before it is released into the production environment and will not do so unless it is evident that proper testing has been performed.
Except in the case of extremely severe errors, bugs should not be fixed with quick ‘hacks’ or ‘work-arounds’; instead the correct fix should be used. Smaller, less critical bugs should be rolled together into a new release level of the program. Ideally, new releases of software should occur as infrequently as possible. Most bugs that were not caught during the planning stages should get caught during testing. Frequent updates to a software program is indicative of both planning and testing failures.
Since all extremely severe program errors should be discovered during the software testing process, the discovery of an error of this magnitude during production use indicates a failure in the testing process. At this point, the IT department should evaluate whether the program should be rolled back to it’s previous state and should go through the complete testing process again.
An 8D should be performed for all severe program errors that cause outages lasting longer than agreed upon reliability specifications.
Christopher