Software maintenance

Last updated
Software development
Core activities
Paradigms and models
Methodologies and frameworks
Supporting disciplines
Practices
Tools
Standards and Bodies of Knowledge
Glossaries

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

Software engineering is the application of engineering to the development of software in a systematic method.

Contents

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.[ citation needed ] More recent studies put the bug-fixing proportion closer to 21%. [3]

A software bug is an error, flaw, failure or fault in a computer program or system that causes it to produce an incorrect or unexpected result, or to behave in unintended ways. The process of finding and fixing bugs is termed "debugging" and often uses formal techniques or tools to pinpoint bugs, and since the 1950s, some computer systems have been designed to also deter, detect or auto-correct various computer bugs during operations.

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.

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

Code refactoring is the process of restructuring existing computer code—changing the factoring—without changing its external behavior. Refactoring is intended to improve nonfunctional attributes of the software. Advantages include improved code readability and reduced complexity; these can improve source-code maintainability and create a more expressive internal architecture or object model to improve extensibility.

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:

Whole-life cost refers to the total cost of ownership over the life of an asset. The concept is also known as "Life-cycle cost" (LCC) or Lifetime cost, and is commonly referred to as "cradle to grave" or "womb to tomb" costs. Costs considered include the financial cost which is relatively simple to calculate and also the environmental and social costs which are more difficult to quantify and assign numerical values. Typical areas of expenditure which are included in calculating the whole-life cost include planning, design, construction and acquisition, operations, maintenance, renewal and rehabilitation, depreciation and cost of finance and replacement or disposal.

Operating system Software that manages computer hardware resources

An operating system (OS) is system software that manages computer hardware, software resources, and provides common services for computer programs.

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,[ citation needed ] whereas development may be 1–2 years.[ citation needed ]

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:

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:

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[ who? ] 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 FactorsPlus Range
Maintenance specialists35%
High staff experience34%
Table-driven variables and data33%
Low complexity of base code32%
Y2K and special search engines30%
Code restructuring tools29%
Re-engineering tools27%
High level programming languages25%
Reverse engineering tools23%
Complexity analysis tools20%
Defect tracking tools20%
Y2K “mass update” specialists20%
Automated change control tools18%
Unpaid overtime18%
Quality measurements16%
Formal base code inspections15%
Regression test libraries15%
Excellent response time12%
Annual training of > 10 days12%
High management experience12%
HELP desk automation12%
No error prone modules10%
On-line defect reporting10%
Productivity measurements8%
Excellent ease of use7%
User satisfaction measurements5%
High team morale5%
Sum503%

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 FactorsMinus 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 overtime0%
Sum-500%

[10]

See also

Related Research Articles

Project management is the practice of initiating, planning, executing, controlling, and closing the work of a team to achieve specific goals and meet specific success criteria at the specified time.The primary challenge of project management is to achieve all of the project goals within the given constraints. This information is usually described in project documentation, created at the beginning of the development process. The primary constraints are scope, time, quality and budget. The secondary—and more ambitious—challenge is to optimize the allocation of necessary inputs and apply them to meet pre-defined objectives.

The Software Engineering Body of Knowledge (SWEBOK) is an international standard ISO/IEC TR 19759:2005 specifying a guide to the generally accepted Software Engineering Body of Knowledge.

Configuration management process for maintaining consistency of a product attributes with its design

Configuration management (CM) is a systems engineering process for establishing and maintaining consistency of a product's performance, functional, and physical attributes with its requirements, design, and operational information throughout its life. The CM process is widely used by military engineering organizations to manage changes throughout the system lifecycle of complex systems, such as weapon systems, military vehicles, and information systems. Outside the military, the CM process is also used with IT service management as defined by ITIL, and with other domain models in the civil engineering and other industrial engineering segments such as roads, bridges, canals, dams, and buildings.

Software architecture refers to the fundamental structures of a software system and the discipline of creating such structures and systems. Each structure comprises software elements, relations among them, and properties of both elements and relations. The architecture of a software system is a metaphor, analogous to the architecture of a building. It functions as a blueprint for the system and the developing project, laying out the tasks not necessary to be executed by the design teams.

Software development is the process of conceiving, specifying, designing, programming, documenting, testing, and bug fixing involved in creating and maintaining applications, frameworks, or other software components. Software development is a process of writing and maintaining the source code, but in a broader sense, it includes all that is involved between the conception of the desired software through to the final manifestation of the software, sometimes in a planned and structured process. Therefore, software development may include research, new development, prototyping, modification, reuse, re-engineering, maintenance, or any other activities that result in software products.

The following outline is provided as an overview of and topical guide to software engineering:

ISO/IEC/IEEE 12207Systems and software engineering – Software life cycle processes is an international standard for software lifecycle processes. First introduced in 1995, it aims to be a primary standard that defines all the processes required for developing and maintaining software systems, including the outcomes and/or activities of each process.

Requirements engineering (RE) refers to the process of defining, documenting and maintaining requirements in the engineering design process. It is a common role in systems engineering and software engineering.

A software requirements specification (SRS) is a description of a software system to be developed. It is modeled after business requirements specification(CONOPS), also known as a stakeholder requirements specification (StRS). The software requirements specification lays out functional and non-functional requirements, and it may include a set of use cases that describe user interactions that the software must provide to the user for perfect interaction.

In the context of software engineering, software quality refers to two related but distinct notions:

Software quality assurance (SQA) is a means of monitoring the software engineering processes and methods used to ensure quality. The methods by which this is accomplished are many and varied, and may include ensuring conformance to one or more standards, such as ISO 9000 or a model such as CMMI. It is a set of methods that try to ensure the quality of all projects in the software process. This includes standards and procedures that administrators may use to review and audit software products and activities to verify that the software meets standards. According to ISO/IEC 15504 v.2.5 (SPICE), it is a supporting process that has to provide the independent assurance in which all the work products, activities and processes comply with the predefined plans and ISO 15504.

Integrated logistic support (ILS) is an integrated and iterative process for developing materiel and a support strategy that optimizes functional support, leverages existing resources, and guides the system engineering process to quantify and lower life cycle cost and decrease the logistics footprint, making the system easier to support. Although originally developed for military purposes, it is also widely used in commercial product support or customer service organisations.

A function point is a "unit of measurement" to express the amount of business functionality an information system provides to a user. Function points are used to compute a functional size measurement (FSM) of software. The cost of a single unit is calculated from past projects.

IEEE 1471 is a superseded IEEE Standard for describing the architecture of a "software-intensive system", also known as software architecture.

Quality engineering is the discipline of engineering concerned with the principles and practice of product and service quality assurance and control. In the software development, it is the management, development, operation and maintenance of IT systems and enterprise architectures with a high quality standard.

In software engineering, a software development process is the process of dividing software development work into distinct phases to improve design, product management, and project management. It is also known as a software development life cycle (SDLC). The methodology may include the pre-definition of specific deliverables and artifacts that are created and completed by a project team to develop or maintain an application.

ISO/IEC 29110: Systems and Software Life Cycle Profiles and Guidelines for Very Small Entities (VSEs) International Standards (IS) and Technical Reports (TR) are targeted at Very Small Entities (VSEs). A Very Small Entity (VSE) is an enterprise, an organization, a department or a project having up to 25 people. The ISO/IEC 29110 is a series of international standards and guides entitled "Systems and Software Engineering — Lifecycle Profiles for Very Small Entities (VSEs)". The standards and technical reports were developed by working group 24 (WG24) of sub-committee 7 (SC7) of Joint Technical Committee 1 (JTC1) of the International Organization for Standardization and the International Electrotechnical Commission.

ITIL, formerly an acronym for Information Technology Infrastructure Library, is a set of detailed practices for IT service management (ITSM) that focuses on aligning IT services with the needs of business.

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. 1 2 3 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