Putting a Software Maintenance Plan Together

Software Maintenance accounts for much of today's work in the information technology industry as many businesses have older technologies they're attempting to make work with current advancements. Many information technology professionals find a variety of cluttered, uncommented computer code with little or disorganized documentation when beginning to upgrade projects. The reverse engineering that takes place is costly to any organization. Having a well-defined maintenance plan can keep costs to a minimum going forward.

Document everything as much as possible.
Develop a handbook for future employees, preferably a protocol kept in a three ring binder or better yet as an editable PDF document stored on the company's hard drive for the IT department. Include pages for definitions of roles and related responsibilities, chain of command procedures, disaster recovery procedures, documentation that exists for current software programs and documentation for all code changes made going forward.

Clearly define roles & responsibilities.
Begin by looking at the status of the information technology department and analyze the current workload of the staff. Select a team that will be dedicated to the software maintenance. Carefully decide who has authorization over things like gathering and examining past software documentation and who will be in charge of each portion of revising the code. Decide if the team will scrap the old and start over from scratch, will replace just the functions that are obsolete, or go with a third party software when necessary. Define procedures of how to deal with disagreements amongst the team.

Develop a timeline.
Decide how often the maintenance will take place. Consider if you will have weekly team meetings, how incoming technical support tickets will be handled, and under what conditions relooking at the maintenance will need to take place. A work break down structure should be defined and a time line chart be developed. If a complete overhaul is necessary then benchmarks should be determined to ensure business deadlines are met. Some benchmark examples could be: having all classes and the class hierarchy defined and approved, class relationships being established, or prototype being started or completed.

Consider the budget.
The maintenance plan must not go over the company's allotted budget. This may have a direct impact on the approach used to maintain the software in its current form and going forward. Some positions may have to take on increased responsibilities if the budget doesn't allow for more staff to be allocated to the maintenance team. Often a compromise between the quality of the wants of the users and what the business needs actually are, will be met, and determined based on budgetary constraints.

Other considerations.
Define ground rules for the team when rewriting the software. Consider agreeing on naming convention practices for variables and enforcing a policy where all code modules require specific comments describing what is happening in the module. The marks of good software maintenance is having a future employee with little or no knowledge of the project be able to pick up the documentation including source codes, and be able to tell exactly what is taking place within the application and exactly where the last crew left off.