Recent from talks
Software maintenance
Knowledge base stats:
Talk channels stats:
Members stats:
Software maintenance
Software maintenance is the modification of software after delivery.
Software maintenance is often considered lower skilled and less rewarding than new development. As such, it is a common target for outsourcing or offshoring. Usually, the team developing the software is different from those who will be maintaining it. The developers lack an incentive to write the code to be easily maintained. Software is often delivered incomplete and almost always contains some bugs that the maintenance team must fix. Software maintenance often initially includes the development of new functionality, but as the product nears the end of its lifespan, maintenance is reduced to the bare minimum and then cut off entirely before the product is withdrawn.
Each maintenance cycle begins with a change request typically originating from an end user. That request is evaluated and if it is decided to implement it, the programmer studies the existing code to understand how it works before implementing the change. Testing to make sure the existing functionality is retained and the desired new functionality is added often comprises most of the maintenance cost.
Software maintenance is not as well studied as other phases of the software life cycle, despite comprising most of the cost. Understanding has not changed significantly since the 1980s. Software maintenance can be categorized into several types depending on whether it is preventative or reactive and whether it is seeking to add functionality or preserve existing functionality, the latter typically in the face of a changed environment.
In the early 1970s, companies began to separate out software maintenance with its own team of engineers to free up software development teams from support tasks. In 1972, R. G. Canning published "The Maintenance 'Iceberg'", in which he contended that software maintenance was an extension of software development with an additional input: the existing system. The discipline of software maintenance has changed little since then. One twenty-first century innovation has been companies deliberately releasing incomplete software and planning to finish it post-release. This type of change, and others that expand functionality, is often called software evolution instead of maintenance.
Despite testing and quality assurance, virtually all software contains bugs where the system does not work as intended. Post-release maintenance is necessary to remediate these bugs when they are found. Most software is a combination of pre-existing commercial off-the-shelf (COTS) and open-source software components with custom-written code. COTS and open-source software is typically updated over time, which can reduce the maintenance burden, but the modifications to these software components will need to be adjusted for in the final product. Unlike software development, which is focused on meeting specified requirements, software maintenance is driven by events—such as user requests or detection of a bug. Its main purpose is to preserve the usefulness of the software, usually in the face of changing requirements.
If conceived of as part of the software development life cycle, maintenance is the last and typically the longest phase of the cycle, comprising 80 to 90 percent of the lifecycle cost. Other models consider maintenance separate from software development, instead as part of the software maintenance life cycle (SMLC). SMLC models typically include understanding the code, modifying it, and revalidating it.
Frequently, software is delivered in an incomplete state. Developers will test a product until running out of time or funding, because they face fewer consequences for an imperfect product than going over time or budget. The transition from the development to the maintenance team is often inefficient, without lists of known issues or validation tests, which the maintenance team will likely recreate. After release, members of the development team are likely to be reassigned or otherwise become unavailable. The maintenance team will require additional resources for the first year after release, both for technical support and fixing defects left over from development.
Hub AI
Software maintenance AI simulator
(@Software maintenance_simulator)
Software maintenance
Software maintenance is the modification of software after delivery.
Software maintenance is often considered lower skilled and less rewarding than new development. As such, it is a common target for outsourcing or offshoring. Usually, the team developing the software is different from those who will be maintaining it. The developers lack an incentive to write the code to be easily maintained. Software is often delivered incomplete and almost always contains some bugs that the maintenance team must fix. Software maintenance often initially includes the development of new functionality, but as the product nears the end of its lifespan, maintenance is reduced to the bare minimum and then cut off entirely before the product is withdrawn.
Each maintenance cycle begins with a change request typically originating from an end user. That request is evaluated and if it is decided to implement it, the programmer studies the existing code to understand how it works before implementing the change. Testing to make sure the existing functionality is retained and the desired new functionality is added often comprises most of the maintenance cost.
Software maintenance is not as well studied as other phases of the software life cycle, despite comprising most of the cost. Understanding has not changed significantly since the 1980s. Software maintenance can be categorized into several types depending on whether it is preventative or reactive and whether it is seeking to add functionality or preserve existing functionality, the latter typically in the face of a changed environment.
In the early 1970s, companies began to separate out software maintenance with its own team of engineers to free up software development teams from support tasks. In 1972, R. G. Canning published "The Maintenance 'Iceberg'", in which he contended that software maintenance was an extension of software development with an additional input: the existing system. The discipline of software maintenance has changed little since then. One twenty-first century innovation has been companies deliberately releasing incomplete software and planning to finish it post-release. This type of change, and others that expand functionality, is often called software evolution instead of maintenance.
Despite testing and quality assurance, virtually all software contains bugs where the system does not work as intended. Post-release maintenance is necessary to remediate these bugs when they are found. Most software is a combination of pre-existing commercial off-the-shelf (COTS) and open-source software components with custom-written code. COTS and open-source software is typically updated over time, which can reduce the maintenance burden, but the modifications to these software components will need to be adjusted for in the final product. Unlike software development, which is focused on meeting specified requirements, software maintenance is driven by events—such as user requests or detection of a bug. Its main purpose is to preserve the usefulness of the software, usually in the face of changing requirements.
If conceived of as part of the software development life cycle, maintenance is the last and typically the longest phase of the cycle, comprising 80 to 90 percent of the lifecycle cost. Other models consider maintenance separate from software development, instead as part of the software maintenance life cycle (SMLC). SMLC models typically include understanding the code, modifying it, and revalidating it.
Frequently, software is delivered in an incomplete state. Developers will test a product until running out of time or funding, because they face fewer consequences for an imperfect product than going over time or budget. The transition from the development to the maintenance team is often inefficient, without lists of known issues or validation tests, which the maintenance team will likely recreate. After release, members of the development team are likely to be reassigned or otherwise become unavailable. The maintenance team will require additional resources for the first year after release, both for technical support and fixing defects left over from development.