Sergey Nivens - Fotolia
4 common software maintenance models and when to use them
Should you use a quick-fix or closed-loop maintenance model for the software project on your development team's plate? What about iterative? Learn the benefits, use cases and limits of four common models.
Digitally focused companies want orderly, incremental changes to their software. What they don't want is time-consuming, expensive enterprise development efforts that tie the business to specific sets of hardware, software and middleware. A software maintenance model can provide the framework to achieve improvements without starting over.
Budget constraints are a major reason to choose software maintenance over a full-on replacement. IT organizations have two sources of money to fund software: money allocated to sustain current operations based on the accepted benefits, and project funding used to obtain new business benefits. It can be difficult to prove the new benefits -- and, thus, to justify major increases to software funding. Maintenance, then, is the only practical way to keep software aligned with business needs.
The maintenance process must be done in a systematic way. Select a general type of software maintenance based on the scope of the project, then choose a maintenance model that has the most benefits and fewest limitations for the specific project.
Software maintenance types
First, assess the impact scope of the changes the dev team proposes for a piece of software, both for the current cycle and next year.
- If the impact scope is more than about 25% of the code, evaluate the age and structure of the current application, and consider a rewrite or restructure.
- If the dev team intends to change less than 15% of the code, basic maintenance is the likely best option.
- If the estimate lands between those two figures, make the choice based on time and budget constraints.
Set a priority level. If the maintenance is needed to repair an application fault or introduce a capability that will drive business or comply with regulations, classify that as emergency maintenance. If the maintenance will accommodate the application's platform or utility roadmap, consider it scheduled maintenance. If the driver is stability or efficiency improvements, that is application modernization; in this case, evaluate whether the scope of the change justifies a rewrite of the application instead.
Software maintenance models
Organizations should explore common software maintenance models that align with the maintenance types and scopes laid out in the first part of this article.
Each software maintenance model has benefits and risks. The most common models are:
- quick-fix
- iterative
- reuse
- closed-loop
Quick-fix. In this model, you simply make a change without considering efficiency, cost or possible future work. The quick-fix model fits emergency maintenance only. Development policies should forbid the use of this model for any other maintenance motives. Consider forming a special team dedicated to emergency software maintenance. Make it the only group allowed to use this software maintenance model.
When using the quick-fix model, annotate changes with code comments and include a change ID. Enter these changes into a maintenance history that details why the change was made, who made it and what specific techniques they used. If multiple points in the code change, note each location and tie them together via the change ID.
Iterative. Use this model for scheduled maintenance or small-scale application modernization. The business justification for changes should either already exist or be unnecessary. The iterative model only gets the development team involved. The biggest risk here is that it doesn't include business justifications -- the software team won't know if larger changes are needed in the future. The iterative model treats the application target as a known quantity.
An iterative maintenance approach covers the common development steps of requirements, design, code, and test and verify results. This iterative flow is roughly the same as a complete software project and includes a benefits analysis.
Because it does not include business analysis, the iterative model best suits changes made to confined application targets, with little cross-impact on other apps or organizations.
Reuse. Similar to the iterative model, the reuse model includes the mandate to build, and then reuse, software components. These components can work in multiple places or applications. Some organizations equate this model to componentized iteration, but that's an oversimplification; the goal here is to create reusable components, which are then made available to all projects under all maintenance models. A dev team typically introduces the reuse model in the requirements phase, which means the process has a similar structure to that of the iterative model, once requirements for reuse are met.
When applying the reuse model, the dev team should consider components of the existing application for reuse, and either make modifications to them or add new ones. It's crucial to work within the organization's broader reuse missions with this approach. Dev teams can easily introduce too much specialization into code and prevent its reuse.
Closed-loop. Use the closed-loop model for scheduled maintenance and application modernization. In this model, the dev team proposes the project and stakeholders must validate its business case before work begins. Once the business and development stakeholders approve, maintenance work proceeds via the iterative model's flow. The loop closes when the dev team evaluates the changes in the live software, and proposes additional work to improve the product, kicking off a new round of proposed changes and business validation.
Closed-loop maintenance goes through several phases. In the analysis phase, the organization establishes the business case for changes. Then, the dev team goes through requirements gathering and approval. At this point, the business assesses the project relative to overall software structures, data center and cloud hosting initiatives and other proposed projects. From this analysis, the organization creates the actual project requirements.
The Boehm and Taute models are formal methodologies for closed-loop maintenance projects. The Boehm model adapts economic principles to maintenance decisions. The Taute model specifies estimates and scheduling for a change before the IT team carries out programming, test and implementation. Like in the Boehm model, the IT team observes the updated software product and makes new proposals for changes, restarting the loop. Some organizations say the Boehm model aligns more easily than Taute's to enterprise architecture principles.
Most organizations use multiple software maintenance models, depending on the situation. Emergency maintenance is a standalone situation. For scheduled maintenance, iterative and closed-loop models differ primarily in how tightly they integrate business operations and benefit analysis. Some software maintenance projects should be vetted for their benefits, while others need no such proof to proceed.
