Software Maintenance

Both the photo editor application and Online Photo Shop have been successfully tested and are ready for deployment. We now must choose a process and strategy for software maintenance, which begins as soon as the product is released to the customer for the first time. According to the IEEE standard (1219) software maintenance is defined as follows:

Modification of a software product after delivery to correct faults, to improve performance or other attributes, or adapt the product to a modified environment.

13.4.1 Change Request Management

Throughout the project, we have used a defect tracking process to capture bugs and possible improvements that could not be addressed in the initial release of the software. We used a simple spreadsheet to record and track this information. However, for larger projects a number of commercial and freeware software packages are available for this purpose. Real-life projects can quickly accumulate from several dozen to a few hundred bug reports per release cycle, and it can be challenging to manage those without using specialized tools.

Tools to manage change requests (for example, bugs, improvements, or new features) can simplify a number of frequently repeated tasks:

• Progress tracking: All electronically filed reports can easily be sorted and filtered using various criteria such as release version or current status. Using this filtering, it is easy to see which problems are scheduled but not yet solved during a particular maintenance release. This form of progress tracking can also be used to validate internal milestones such as feature or code freezes.
• Prioritizing and scheduling: Most tracking tools allow you to configure multiple release versions so that change requests can be deferred to future versions. Also, assigning priorities helps in scheduling the change requests, a benefit that is particularly useful in larger projects. Other information, such as the number of bugs reported in previous versions, can help in planning future releases. If in prior versions an average of 10 bugs per 100 lines has been the reality, it is safe to assume that this release will drop to 1 defect. The necessary buffers should therefore be allocated in the project plan.
• Resource allocation: Good tools allow you to assign resources for investigating, implementing, or validating a change request. The developer or tester who is assigned to investigate, analyze, or implement a change is automatically notified via e-mail. Also, it is possible to get an overview of how many change requests are assigned to a person. Some tools even provide fields where you can enter the estimated effort for correction after an investigation, information that helps in selecting a developer for the implementation.
• Process enforcement: Change request management software often lets you customize the workflow in which the change requests are processed. This allows your organizational processes to be enforced. You could, for example, require that each implemented change request be forwarded to a tester for validation and that a tester attach an electronic copy of the test record before the request can be closed.
• Process improvement: Many tools can automatically collect additional information, such as timestamps, project phases, or iterations of state changes (for example, when a bug was reported, analyzed, implemented, or tested). Using this information you can create statistics that help you identify areas for improvement. For example, it is usually simple to compute the average bug closing time, how many bugs have been filed after code freeze, how many bugs have been found by the test team versus external customers, and many more.

13.4.2 Maintenance Strategies

The cost of software maintenance is commonly estimated to be 60 percent to 80 percent of the total budget for software development. It is therefore crucial to choose good practices and optimize maintenance processes and procedures in order to stay competitive. There are four main maintenance strategies you can follow:

• Fixed staff and variable schedule: This strategy is followed by most organizations that have a fixed group of maintenance engineers, who analyze, implement, and unit-test change requests from a backlog queue one by one. The management then declares feature freeze depending on the mission's needs. The integration test phase following the feature freeze will determine the release date.
• Fixed schedule and variable staff: In this model the product release date is established between customer and supplier based first on the mission's needs. Then the priority changes are agreed upon in a so-called Version Content Notice (VCN) or Statement of Work (SOW). The necessary resources are allocated to the release, and work is started on the changes. Often the resources also come from a fixed group of maintenance engineers (as in the fixed staff/variable schedule model), but here they are assigned to particular software releases as needed. Content and staffing also might be renegotiated throughout the project. When a final project agreement is achieved between customer and supplier, unit and integration testing is completed and the new version is released. The fixed schedule/variable staff strategy is often used for projects that develop libraries or low-level components that become building blocks for higher-level applications.
• Variable schedule and variable staff: Organizations that do not have a fixed software maintenance staff usually follow the variable schedule/variable staff model. After the content of a release is determined, schedule and cost are negotiated with contractors, who work on the change requests. While the contractors design, implement, and test the changes, multiple reviews throughout these phases ensure the quality of the release.
• Fixed staff and fixed schedule: From our experience the fixed staff/fixed schedule model is not very commonly used. It is applied in projects or organizations that have clearly defined need dates but for whom the addition of resources is not feasible. For example, working on the project might require highly specialized skills that are not offered by any contractors and cannot be acquired simply by training.

Each of the maintenance strategies has strengths and weaknesses in various areas, including performance, quality, efficiency, and costs. From our experience there is no gold standard for a software maintenance process, and all software processes need to be tailored to project needs and environments. However, the large percentage of the total software budget spent on maintenance makes it important to optimize this process to stay competitive in today's software business.

Because our team is very small, it is not feasible to allocate a fixed maintenance group for the photo editor application and Online Photo Shop project. Furthermore, contracts with our customer, the printing and embossing business, are very specific about release dates of the software. We therefore choose a fixed schedule/variable staff maintenance strategy, which allows us to allocate developers within the organization to a particular release as needed.