Article Preview
Top2. Establishing Product And System Definitions
Documenting the proper behavior of an application is a necessary step for secure and reliable development in every environment. This documentation should include the system behavior and configurations, preferably as a process diagram or as human-readable documentation. The inclusion of testing from the beginning of any development has also proven to be a useful supplement to the user documentation. Using strategies like test driven development (Astels 2003) or behavior driven development (Solis & Wang 2011) provide the opportunity for the project management to define their requirements in a formalized and reproducible fashion, such that the functionality, once developed, is known to work to the specifications and requirements initially produced. At IBM, a development team was able to reduce their defect rate by 50 percent by implementing test-driven development strategies in their retail store solutions (Jarvis & Nilletary 2014). In addition to the dramatic decrease of defects, test-driven development produces a reusable test asset, which is an invaluable tool come the time for regression testing. Product and system definitions provide critical guidance to the developers and users during and after the development period. Test driven development enhances this documentation with functional proof that the product works as intended.
The process by which a change is deployed is just as important as the testing that happens before it. Similarly, the deployment process must also be thoroughly tested and documented, as deploying a change to an application or an infrastructure is perhaps the riskiest portion of the process, as it adds an element of variation to an environment that is likely already functioning. Every step of the deployment process needs to be crafted with care and scrutiny. The tools used to develop the code must be reviewed to ensure proper code is generated. The repositories that store and track the source code must be vetted to ensure the code is not at risk for being leaked to prying eyes. Finally, when the package is ultimately deployed, the configuration must be deployed through a system known and tested to reliably deliver the correct results (Maximilien & Williams 2003). Mature change management will consider many aspects of each individual process. Each change should document its intended effect, and the tests run to ensure that the change executes its purpose with no unintended side-effects. Additionally, the precise actions to deploy the change will be vetted, checking whether this kind of change has failed before, and that there are no other conflicting changes happening at the same time. This list can contain a seemingly endless set of records to document, but a final important piece is the backout plan: what to do when the change goes south, despite your best efforts. Ensuring a functional environment is most frequently more important than implementing the change to it.