Software maintenance

Software maintenance in software engineering is the modification of a software product after delivery to correct faults, to improve performance or other attributes.[1]

A common perception of maintenance is that it merely involves fixing defects. However, one study indicated that over 80% of maintenance effort is used for non-corrective actions.[2] This perception is perpetuated by users submitting problem reports that in reality are functionality enhancements to the system. More recent studies put the bug-fixing proportion closer to 21%.[3]

History

Software maintenance and evolution of systems was first addressed by Meir M. Lehman in 1969. Over a period of twenty years, his research led to the formulation of Lehman's Laws (Lehman 1997). Key findings of his research conclude that maintenance is really evolutionary development and that maintenance decisions are aided by understanding what happens to systems (and software) over time. Lehman demonstrated that systems continue to evolve over time. As they evolve, they grow more complex unless some action such as code refactoring is taken to reduce the complexity.

In the late 1970s, a famous and widely cited survey study by Lientz and Swanson, exposed the very high fraction of life-cycle costs that were being expended on maintenance. They categorized maintenance activities into four classes:

  • Adaptive – modifying the system to cope with changes in the software environment (DBMS, OS) [4]
  • Perfective – implementing new or changed user requirements which concern functional enhancements to the software
  • Corrective – diagnosing and fixing errors, possibly ones found by users [4]
  • Preventive – increasing software maintainability or reliability to prevent problems in the future [4]

The survey showed that around 75% of the maintenance effort was on the first two types, and error correction consumed about 21%. Many subsequent studies suggest a similar problem magnitude. Studies show that contribution of end users is crucial during the new requirement data gathering and analysis. This is the main cause of any problem during software evolution and maintenance. Software maintenance is important because it consumes a large part of the overall lifecycle costs and also the inability to change software quickly and reliably means that business opportunities are lost. [5] [6] [7]

Importance of software maintenance

The key software maintenance issues are both managerial and technical. Key management issues are: alignment with customer priorities, staffing, which organization does maintenance, estimating costs. Key technical issues are: limited understanding, impact analysis, testing, maintainability measurement.

Software maintenance is a very broad activity that includes error correction, enhancements of capabilities, deletion of obsolete capabilities, and optimization. Because change is inevitable, mechanisms must be developed for evaluation, controlling and making modifications.

So any work done to change the software after it is in operation is considered to be maintenance work. The purpose is to preserve the value of software over the time. The value can be enhanced by expanding the customer base, meeting additional requirements, becoming easier to use, more efficient and employing newer technology. Maintenance may span for 20 years, whereas development may be 1–2 years.

Software maintenance planning

An integral part of software is the maintenance one, which requires an accurate maintenance plan to be prepared during the software development. It should specify how users will request modifications or report problems. The budget should include resource and cost estimates. A new decision should be addressed for the developing of every new system feature and its quality objectives. The software maintenance, which can last for 5–6 years (or even decades) after the development process, calls for an effective plan which can address the scope of software maintenance, the tailoring of the post delivery/deployment process, the designation of who will provide maintenance, and an estimate of the life-cycle costs. The selection of proper enforcement of standards is the challenging task right from early stage of software engineering which has not got definite importance by the concerned stakeholders.

Software maintenance processes

This section describes the six software maintenance processes as:

  1. The implementation process contains software preparation and transition activities, such as the conception and creation of the maintenance plan; the preparation for handling problems identified during development; and the follow-up on product configuration management.
  2. The problem and modification analysis process, which is executed once the application has become the responsibility of the maintenance group. The maintenance programmer must analyze each request, confirm it (by reproducing the situation) and check its validity, investigate it and propose a solution, document the request and the solution proposal, and finally, obtain all the required authorizations to apply the modifications.
  3. The process considering the implementation of the modification itself.
  4. The process acceptance of the modification, by confirming the modified work with the individual who submitted the request in order to make sure the modification provided a solution.
  5. The migration process (platform migration, for example) is exceptional, and is not part of daily maintenance tasks. If the software must be ported to another platform without any change in functionality, this process will be used and a maintenance project team is likely to be assigned to this task.
  6. Finally, the last maintenance process, also an event which does not occur on a daily basis, is the retirement of a piece of software.

There are a number of processes, activities and practices that are unique to maintainers, for example:

  • Transition: a controlled and coordinated sequence of activities during which a system is transferred progressively from the developer to the maintainer;
  • Service Level Agreements (SLAs) and specialized (domain-specific) maintenance contracts negotiated by maintainers;
  • Modification Request and Problem Report Help Desk: a problem-handling process used by maintainers to prioritize, documents and route the requests they receive;

Categories of maintenance in ISO/IEC 14764

E.B. Swanson initially identified three categories of maintenance: corrective, adaptive, and perfective.[8] The IEEE 1219 standard was superseded in June 2010 by P14764.[9] These have since been updated and ISO/IEC 14764 presents:

  • Corrective maintenance: Reactive modification of a software product performed after delivery to correct discovered problems.
  • Adaptive maintenance: Modification of a software product performed after delivery to keep a software product usable in a changed or changing environment.
  • Perfective maintenance: Modification of a software product after delivery to improve performance or maintainability.
  • Preventive maintenance: Modification of a software product after delivery to detect and correct latent faults in the software product before they become effective faults.

There is also a notion of pre-delivery/pre-release maintenance which is all the good things you do to lower the total cost of ownership of the software. Things like compliance with coding standards that includes software maintainability goals. The management of coupling and cohesion of the software. The attainment of software supportability goals (SAE JA1004, JA1005 and JA1006 for example). Note also that some academic institutions are carrying out research to quantify the cost to ongoing software maintenance due to the lack of resources such as design documents and system/software comprehension training and resources (multiply costs by approx. 1.5-2.0 where there is no design data available).

Maintenance Factors

Impact of key adjustment factors on maintenance (sorted in order of maximum positive impact)

Maintenance Factors Plus Range
Maintenance specialists 35%
High staff experience 34%
Table-driven variables and data 33%
Low complexity of base code 32%
Y2K and special search engines 30%
Code restructuring tools 29%
Re-engineering tools 27%
High level programming languages 25%
Reverse engineering tools 23%
Complexity analysis tools 20%
Defect tracking tools 20%
Y2K “mass update” specialists 20%
Automated change control tools 18%
Unpaid overtime 18%
Quality measurements 16%
Formal base code inspections 15%
Regression test libraries 15%
Excellent response time 12%
Annual training of > 10 days 12%
High management experience 12%
HELP desk automation 12%
No error prone modules 10%
On-line defect reporting 10%
Productivity measurements 8%
Excellent ease of use 7%
User satisfaction measurements 5%
High team morale 5%
Sum 503%

Not only are error-prone modules troublesome, but many other factors can degrade performance too. For example, very complex spaghetti code is quite difficult to maintain safely. A very common situation which often degrades performance is lack of suitable maintenance tools, such as defect tracking software, change management software, and test library software. Below describe some of the factors and the range of impact on software maintenance.

Impact of key adjustment factors on maintenance (sorted in order of maximum negative impact)

Maintenance Factors Minus Range
Error prone modules -50%
Embedded variables and data -45%
Staff inexperience -40%
High code complexity -30%
No Y2K of special search engines -28%
Manual change control methods -27%
Low level programming languages -25%
No defect tracking tools -24%
No Y2K “mass update” specialists -22%
Poor ease of use -18%
No quality measurements -18%
No maintenance specialists -18%
Poor response time -16%
No code inspections -15%
No regression test libraries -15%
No help desk automation -15%
No on-line defect reporting -12%
Management inexperience -15%
No code restructuring tools -10%
No annual training -10%
No reengineering tools -10%
No reverse-engineering tools -10%
No complexity analysis tools -10%
No productivity measurements -7%
Poor team morale -6%
No user satisfaction measurements -4%
No unpaid overtime 0%
Sum -500%

[10]

See also

References

[11]

  1. ^ "ISO/IEC 14764:2006 Software Engineering — Software Life Cycle Processes — Maintenance". Iso.org. 2011-12-17. Retrieved 2013-12-02.
  2. ^ Pigoski, Thomas M., 1997: Practical software maintenance: Best practices for managing your software investment. Wiley Computer Pub. (New York)
  3. ^ Eick, S., Graves, T., Karr, A., Marron, J., and Mockus, A. 2001. Does Code Decay? Assessing Evidence from Change Management Data. IEEE Transactions on Software Engineering. 27(1) 1-12.
  4. ^ a b c Software Maintenance and Re-engineering, CSE2305 Object-Oriented Software Engineering
  5. ^ Lientz B., Swanson E., 1980: Software Maintenance Management. Addison Wesley, Reading, MA
  6. ^ Lehman M. M., 1980: Program, Life-Cycles and the Laws of Software Evolution. In Proceedings of IEEE, 68, 9,1060-1076
  7. ^ Penny Grubb, Armstrong A. Takang, 2003: Software Maintenance: Concepts and Practice. World Scientific Publishing Company
  8. ^ "E. Burt Swanson, The dimensions of maintenance. Proceedings of the 2nd international conference on Software engineering, San Francisco, 1976, pp 492 — 497". Portal.acm.org. doi:10.1145/359511.359522. Retrieved 2013-12-02.
  9. ^ Status of 1219-1998 by IEEE Standards
  10. ^ "The Economics Of Software Maintenance In The Twenty First Century" (PDF). Archived from the original (PDF) on 2015-03-19. Retrieved 2013-12-02.
  11. ^ Pigoski, Thomas. "Chapter 6: Software Maintenance" (PDF). SWEBOK. IEEE. Retrieved 5 November 2012.

Further reading

  • ISO/IEC 14764 IEEE Std 14764-2006 Software Engineering — Software Life Cycle Processes — Maintenance. 2006. doi:10.1109/IEEESTD.2006.235774. ISBN 0-7381-4960-8.
  • Pigoski, Thomas M. (1996). Practical Software Maintenance. New York: John Wiley & Sons. ISBN 978-0-471-17001-3.
  • Pigoski, Thomas M. Description for Software Evolution and Maintenance (version 0.5). SWEBOK Knowledge Area.
  • April, Alain; Abran, Alain (2008). Software Maintenance Management. New York: Wiley-IEEE. ISBN 978-0-470-14707-8.
  • Gopalaswamy Ramesh; Ramesh Bhattiprolu (2006). Software maintenance : effective practices for geographically distributed environments. New Delhi: Tata McGraw-Hill. ISBN 978-0-07-048345-3.
  • Grubb, Penny; Takang, Armstrong (2003). Software Maintenance. New Jersey: World Scientific Publishing. ISBN 978-981-238-425-6.
  • Lehman, M.M.; Belady, L.A. (1985). Program evolution : processes of software change. London: Academic Press Inc. ISBN 0-12-442441-4.
  • Page-Jones, Meilir (1980). The Practical Guide to Structured Systems Design. New York: Yourdon Press. ISBN 0-917072-17-0.

External links

76th Maintenance Wing

The 76th Maintenance Wing is a wing of the United States Air Force based out of Tinker Air Force Base, Oklahoma.

Application lifecycle management

Application lifecycle management (ALM) is the product lifecycle management (governance, development, and maintenance) of computer programs. It encompasses requirements management, software architecture, computer programming, software testing, software maintenance, change management, continuous integration, project management, and release management.

Backporting

Backporting is the action of taking parts from a newer version of a software system or software component and porting them to an older version of the same software. It forms part of the maintenance step in a software development process, and it is commonly used for fixing security issues in older versions of the software and also for providing new features to older versions.

Hotfix

A hotfix or quick-fix engineering update (QFE update) is a single, cumulative package that includes information (often in the form of one or more files) that is used to address a problem in a software product (i.e., a software bug). Typically, hotfixes are made to address a specific customer situation.

The term "hotfix" originally referred to software patches that were applied to "hot" systems; that is, systems which are live, currently running, and in production status rather than development status. For the developer, a hotfix implies that the change may have been made quickly and outside normal development and testing processes. This could increase the cost of the fix by requiring rapid development, overtime or other urgent measures. For the user, the hotfix could be considered riskier or less likely to resolve the problem. This could cause an immediate loss of services, so depending on the severity of the bug, it may be desirable to delay a hotfix. The risk of applying the hotfix must be weighed against the risk of not applying it, because the problem to be fixed might be so critical that it could be considered more important than a potential loss of service (e.g., a major security breach).

Similar use of the terms can be seen in hot-swappable disk drives. The more recent usage of the term is likely due to software vendors making a distinction between a hotfix and a patch.

IEC 62304

The international standard IEC 62304 – medical device software – software life cycle processes is a standard which specifies life cycle requirements for the development of medical software and software within medical devices. It is harmonized by the European Union (EU) and the United States (US), and therefore can be used as a benchmark to comply with regulatory requirements from both these markets.

Long-term support

Long-term support (LTS) is a product lifecycle management policy in which a stable release of computer software is maintained for a longer period of time than the standard edition. The term is typically reserved for open-source software, where it describes a software edition that is supported for months or years longer than the software's standard edition.

Short term support (STS) is a term that distinguishes the support policy for the software's standard edition. STS software has a comparatively short life cycle, and may be afforded new features that are omitted from the LTS edition to avoid potentially compromising the stability or compatibility of the LTS release.

Microsoft Software Assurance

Microsoft Software Assurance (SA) is a Microsoft maintenance program aimed at business users who use Microsoft Windows, Microsoft Office, and other server and desktop applications. The core premise behind SA is to give users the ability to spread payments over several years, while offering "free" upgrades to newer versions during that time period.

Patch (computing)

A patch is a set of changes to a computer program or its supporting data designed to update, fix, or improve it. This includes fixing security vulnerabilities and other bugs, with such patches usually being called bugfixes or bug fixes, and improving the usability or performance. Although meant to fix problems, poorly designed patches can sometimes introduce new problems (see software regressions). In some special cases updates may knowingly break the functionality or disable a device, for instance, by removing components for which the update provider is no longer licensed.

Patch management is a part of lifecycle management, and is the process of using a strategy and plan of what patches should be applied to which systems at a specified time.

Patch Tuesday

Patch Tuesday (also known as Update Tuesday) is an unofficial term used to refer to when Microsoft regularly releases security patches for its software products. It is widely referred to in this way by the industry. Microsoft formalized Patch Tuesday in October 2003.Patch Tuesday occurs on the second, and sometimes fourth, Tuesday of each month in North America. As far as the integrated Windows Update (WU) function is concerned, Patch Tuesday begins at 18:00 or 17:00 UTC (10:00 PST (UTC−8) or 10:00 PDT (UTC−7)). The updates show up in Download Center before they are added to WU, and the KB articles and the Technet bulletin are unlocked later.

Microsoft has a pattern of releasing a larger number of updates in even-numbered months, and fewer in odd-numbered months. Minor updates are also released outside Patch Tuesday. Daily updates consist of malware database refreshes for Windows Defender and Microsoft Security Essentials. Sometimes there is an extraordinary Patch Tuesday, two weeks after the regular Patch Tuesday. Some updates could be released at any time.

Server emulator

A server emulator, also called Freeshard or Private server, is the reimplementation of online game servers, typically as clones of proprietary commercial software by a third party of the game community. The private server is not always made by the original company, but usually attempts to mimic it in some way.

Technically, a server emulator does not emulate by the traditional definition. Instead it is the alternative implementation of the proprietary gaming server that communicates with the same gaming client through the same, reverse-engineered proprietary protocols. Server emulators exist for many online games. If the original proprietary servers were shut down, server emulators can be considered community continuations as fix for an orphaned software product.

Software analytics

Software analytics is the analytics specific to the domain of software systems taking into account source code, static and dynamic characteristics (e.g., software metrics) as well as related processes of their development and evolution. It aims at describing, monitoring, predicting, and improving efficiency and effectivity of software engineering throughout the software lifecycle, in particular during software development and software maintenance. The data collection is typically done by mining software repositories, but can also be achieved by collecting user actions or production data. One avenue for using the collected data is to augment the integrated development environments (IDEs) with data-driven features.

Software archaeology

Software archaeology or software archeology is the study of poorly documented or undocumented legacy software implementations, as part of software maintenance. Software archaeology, named by analogy with archaeology, includes the reverse engineering of software modules, and the application of a variety of tools and processes for extracting and understanding program structure and recovering design information. Software archaeology may reveal dysfunctional team processes which have produced poorly designed or even unused software modules. The term has been in use for decades, and reflects a fairly natural metaphor: a programmer reading legacy code may feel that he or she is in the same situation as an archaeologist exploring the rubble of an ancient civilization.

Software evolution

Software evolution is the term used in software engineering (specifically software maintenance) to refer to the process of developing software initially, then repeatedly updating it for various reasons.

Software maintainer

In free and open source software, a software maintainer or package maintainer is usually one or more people who build source code into a binary package for distribution, commit patches, or organize code in a source repository.Maintainers often cryptographically sign binaries so that people can verify their authenticity.

Software visualization

Software visualization or software visualisation refers to the visualization of information of and related to software systems—either the architecture of its source code or metrics of their runtime behavior- and their development process by means of static, interactive or animated 2-D or 3-D visual representations of their structure, execution, behavior, and evolution.

Source port

A source port is a software project based on the source code of a game engine that allows the game to be played on operating systems or computing platforms with which the game was not originally compatible.

Thin client

A thin client is a lightweight computer that has been optimized for establishing a remote connection with a server-based computing environment. The server does most of the work, which can include launching software programs, crunching numbers, and storing data. This contrasts with a fat client or a conventional personal computer; the former is also intended for working in a client–server model but has significant local processing power, while the latter aims to perform its function mostly locally.

Thin clients occur as components of a broader computing infrastructure, where many clients share their computations with a server or server farm. The server-side infrastructure uses cloud computing software such as application virtualization, hosted shared desktop (HSD) or desktop virtualization (VDI). This combination forms what is known as a cloud-based system where desktop resources are centralized at one or more data centers. The benefits of centralization are hardware resource optimization, reduced software maintenance, and improved security.

Example of hardware resource optimization: Cabling, busing and I/O can be minimized while idle memory and processing power can be applied to user sessions that most need it.

Example of reduced software maintenance: Software patching and operating system (OS) migrations can be applied, tested and activated for all users in one instance to accelerate roll-out and improve administrative efficiency.

Example of improved security: Software assets are centralized and easily fire-walled, monitored and protected. Sensitive data is uncompromised in cases of desktop loss or theft.Thin client hardware generally supports a keyboard, mouse, monitor, jacks for sound peripherals, and open ports for USB devices (e.g., printer, flash drive, webcam). Some thin clients include legacy serial or parallel ports to support older devices such as receipt printers, scales or time clocks. Thin client software typically consists of a graphical user interface (GUI), cloud access agents (e.g., RDP, ICA, PCoIP), a local web browser, terminal emulators (in some cases), and a basic set of local utilities.

Workaround

A workaround is a bypass of a recognized problem or limitation in a system. A workaround is typically a temporary fix that implies that a genuine solution to the problem is needed. But workarounds are frequently as creative as true solutions, involving outside the box thinking in their creation.

Typically they are considered brittle in that they will not respond well to further pressure from a system beyond the original design. In implementing a workaround it is important to flag the change so as to later implement a proper solution.Placing pressure on a workaround may result in later system failures. For example, in computer programming workarounds are often used to address a problem or anti-pattern in a library, such as an incorrect return value. When the library is changed, the workaround may break the overall program functionality, effectively becoming an anti-pattern, since it may expect the older, wrong behaviour from the library.

Workarounds can also be a useful source of ideas for improvement of products or services.

Hardware
Computer systems
organization
Networks
Software organization
Software notations
and tools
Software development
Theory of computation
Algorithms
Mathematics
of computing
Information
systems
Security
Human–computer
interaction
Concurrency
Artificial
intelligence
Machine learning
Graphics
Applied
computing
Fields
Concepts
Orientations
Models
Software
engineers
Related fields
Current
802 series
Proposed
Superseded
ISO standards by standard number
1–9999
10000–19999
20000+

This page is based on a Wikipedia article written by authors (here).
Text is available under the CC BY-SA 3.0 license; additional terms may apply.
Images, videos and audio are available under their respective licenses.