We discussed the Systems Development Life Cycle (SDLC) this week, which is the process an organization goes through to develop its information system. The text book, (3rd Edition) gave us an overview of the components of the SDLC. The last component, Program Change Procedures, is also known as Systems Maintenance, and is an area that could cause a lot of problems for the organization if it’s not implemented properly.
Systems Maintenance can be viewed as a process of moving program changes from a Development environment, through Integration and Staging Environments, and into the Production Environment. This is a fairly complex process, but if managed properly, it can reduce the number of potential errors released into a Production Environment.
This is a brief overview of the different kinds of environments:
Development Environment: This is an isolated environment where developers make coding changes without affecting the rest of the team. Development environments can be configured for individual developers or small teams.
Integration Environment: At this stage, coding changes made in the Development Environment are brought forward and integrated with the work of the entire project team. This is intended to test the changes made by the developers before they are pushed up to the Staging Environment. It is possible for the Development and Integration Environments to be the same environment. For testing purposes, developers should use a subset of the data in the Production Environment.
Staging Environment: Should be configured to simulate the Production Environment as closely as possible. If possible, the Staging Environment should utilize a copy of the entire database, not a subset of it. It should also have a similar hardware configuration so that it’s possible to accurately forecast performance.
Production Environment: Real world environment. It could consist of one machine or many machines.
Below is a chart that illustrates the process of moving coding changes, made by developers, from the Development Environment, through the Integration and Staging Environments, and into the Production Environment.
This chart is based on the chart displayed in the article. (Murray 2013)
1. Developers write code changes in Development Environment.
2. Code changes are then moved into Integration Environment and checked into the Source Program Library (SPL).
3. Bugs are found in the Integration Environment. Bug Reports are sent back to the developers.
4. Developers fix bugs in Development Environment.
5. Changes are pushed into Integration Environment and checked into the SPL.
6. The Release Manager reviews code changes in Integration Environment.
7. Changes are promoted to Staging Environment.
8. QA team tests changes in the Staging Environment.
9. QA finds bugs in the Staging Environment, sends Bug Reports back to the Developers.
10. Developers fix bugs in the Development Environment.
11. Code changes are pushed into the Integration Environment.
12. Release Manager promotes code changes into the Staging Environment.
13. Release Manager reviews changes and issues “Ok to Release”
14. Code is packaged and given a release version number.
15. Code Packages are promoted to the Production Environment.
16. Bugs are found in the Production Environment, Bug Reports are sent back to the Developers.
17. Developers fix bugs in Development Environment.
18. Changes are pushed into Integration Environment and checked into the SPL. (Murray 2013)
Systems Maintenance is a fairly complex process, and is ongoing. As can be seen above, it’s very important to have a Source Program Library controlled by SPL Management Software that controls access to the code, manages development, and tracks changes.
Murray, Peter. Traditional Development/Integration/Staging/Production Practice for Software Development. September 25, 2013. http://dltj.org/article/software-development-practice/ (accessed February 17, 2014).