...
Even if maintainability is not of concern, that decision has to be decided and explicitly stated. The decisions on maintainability imply or impose affect the related QA parameters.
...
The development team should timely but also periodically:
- Manage the inflow of maintenance-related requests and faults.
- Identify maintenance issues and those that could hinder system maintenance.
- Review whether the received issues are captured in a clear, relevant, addressable and, if possible, reproducible way and prioritise them.
- Monitor and review long-standing issues reported in the issue tracker to in order prune or prioritise them.
- Review the backlog and related issues with an overall perspective, and group the related items together.
- Identify latent faults or root causes of recurring issues or groups of related issues - these may be minor but previously improperly resolved, or ones requiring a major refactoring or /an architectural change.
- Identify maintenance constraints imposed by the ongoing systems usage, users or intervention and support capabilities.
...
Some maintenance modifications respond to the need to establish additional interfaces to other systems, adapt to a different platform or environment, perfect optimize existing functions, improve security, prevent performance degradation, or prepare the system for retirement.
...
Consider, review and assess available options and choose what to do:
- Outline the options for maintenance solutions options.
- Define and weight weigh the alternatives: a workaround may suffice, it may need to be later replaced with a more permanent solution requiring a major refactoring or intersecting intervention.
- Consider the consequences and side effects of individual alternatives.
Determine who should implement and evaluate them; the involved may include developers, operations, support, customers, end-users…
- Select those that are most appropriate in current circumstances, considering the impact and cost of the issues they address and the complexity, cost and impact of solutions.
- Determine whether the solution requires the involvement of the development team, and schedule its development and addressing.
- Check whether maintenance constraints are satisfied and how the selected approach could impact the production systems.
The development team should not be immediately made responsible for addressing maintenance issues, but often needs to be consulted while they are addressed. When the problem is passed to them, they make the changes into the software that distributed as patches (out-of-band releases) or delivered through the regular maintenance release cycle. Some changes, especially in particular those addressing technical debt, could be thoroughly investigated and planned and put in the roadmap. The recurring issues or difficulties in their addressing are often an indication of technical debt.
Implementation of modifications
...
- Set up channels to operations, customers or end-users, agreements between the teams, and adjust the development team's procedures and tools that are used in Development and Implementation.
- Coordinate with the operations and support.
- Produce and verify modifications through Development and Implementation.(see the "Design and implementation" Target Area)
- Review and accept or /reject the modification; although it was verified during development, it should be validated from at the operational, maintenance and support level before the deployment
- Plan deployment and teams' availability, so that the possible disruption caused by modifications and duration of post-modification corrective actions are minimised.
- Deliver and integrate modifications into the supported system.
- If needed, quickly revert (rollback) conducted modifications.
Technical debt is often handled separately from standard changes or emergency changes, as the related modifications may require changes at a number of places and may impose greater risks and have a larger impact on the operation of the system. Such Therefore, such changes are therefore often separately planned within the roadmap, handled in separate branches, and may even include an operating environment, piloting period or early life support of their own, and include dealing early adopters and gradual migration of users. All this may result in additional requirements and concerns for software teams.
...