This article has multiple issues. Please help improve it or discuss these issues on the talk page . (Learn how and when to remove these template messages)(Learn how and when to remove this template message)
|Paradigms and models|
|Methodologies and frameworks|
|Standards and Bodies of Knowledge|
Software maintenance in software engineering is the modification of a software product after delivery to correct faults, to improve performance or other attributes.
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. [ citation needed ] More recent studies put the bug-fixing proportion closer to 21%.This perception is perpetuated by users submitting problem reports that in reality are functionality enhancements to the system.
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:
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.
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 ]
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.
This section describes the six software maintenance processes as:
There are a number of processes, activities and practices that are unique to maintainers, for example:
E.B. Swanson initially identified three categories of maintenance: corrective, adaptive, and perfective.The IEEE 1219 standard was superseded in June 2010 by P14764. 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). 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).
Impact of key adjustment factors on maintenance (sorted in order of maximum positive impact)
|Maintenance Factors||Plus Range|
|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%|
|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%|
|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%|
|Excellent ease of use||7%|
|User satisfaction measurements||5%|
|High team morale||5%|
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%|
|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%|
|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%|
In a paper for the 27th International Conference on Software Quality Management in 2019, John Estdale introduced the term “maintenance debt” for maintenance needs generated by an implementation’s dependence on external IT factors such as libraries, platforms and tools, that have become obsolescent . The application continues to run, and the IT department forgets this theoretical liability, focussing on more urgent requirements and problems elsewhere. Such debt accumulates over time, silently eating away at the value of the software asset. Eventually something happens that makes system change unavoidable.
The owner may then discover that the system can no longer be modified – it is literally unmaintainable. Less dramatically, it may take too long, or cost too much, for maintenance to solve the business problem, and an alternative solution must be found. The software has suddenly crashed to £0 value.
Estdale defines "Maintenance Debt"as: the gap between the current implementation state of an application and the ideal, using only functionality of external components that is fully maintained and supported. This debt is often hidden or not recognized. An application’s overall maintainability is dependent on the continuing obtainability of components of all sorts from other suppliers, including:
and of course
The complete disappearance of a component could make the application un-rebuildable, or imminently unmaintainable.
A quality management system (QMS) is a collection of business processes focused on consistently meeting customer requirements and enhancing their satisfaction. It is aligned with an organization's purpose and strategic direction (ISO9001:2015). It is expressed as the organizational goals and aspirations, policies, processes, documented information and resources needed to implement and maintain it. Early quality management systems emphasized predictable outcomes of an industrial product production line, using simple statistics and random sampling. By the 20th century, labor inputs were typically the most costly inputs in most industrialized societies, so focus shifted to team cooperation and dynamics, especially the early signaling of problems via a continual improvement cycle. In the 21st century, QMS has tended to converge with sustainability and transparency initiatives, as both investor and customer satisfaction and perceived quality is increasingly tied to these factors. Of QMS regimes, the ISO 9000 family of standards is probably the most widely implemented worldwide – the ISO 19011 audit regime applies to both, and deals with quality and sustainability and their integration.
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 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) is the process of defining, documenting, and maintaining requirements in the engineering design process. It is a common role in systems engineering and software engineering.
Software prototyping is the activity of creating prototypes of software applications, i.e., incomplete versions of the software program being developed. It is an activity that can occur in software development and is comparable to prototyping as known from other fields, such as mechanical engineering or manufacturing.
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 proper quality. This is accomplished by many and varied approaches. It may include ensuring conformance to one or more standards, such as ISO 9000 or a model such as CMMI.
Release engineering, frequently abbreviated as RE or as the clipped compound Releng, is a sub-discipline in software engineering concerned with the compilation, assembly, and delivery of source code into finished products or other software components. Associated with the software release life cycle, it was said by Boris Debic of Google Inc. that release engineering is to software engineering as manufacturing is to an industrial process:
Release engineering is the difference between manufacturing software in small teams or startups and manufacturing software in an industrial way that is repeatable, gives predictable results, and scales well. These industrial style practices not only contribute to the growth of a company but also are key factors in enabling growth.
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.
The change management process in systems engineering is the process of requesting, determining attainability, planning, implementing, and evaluating of changes to a system. Its main goals are to support the processing and traceability of changes to an interconnected set of factors.
Software evolution : The software is modified to adapt it to changing customer and market requirement.software evolution is important because organization has invested large amount of money in their software and are completely dependent on this software,where software evolution is triggered by changing businesses requirements by reporting of software defect or by changes to other system in a software system environment (Updated on 5th of January 2020)
Legacy modernization, also known as software modernization or platform modernization, refers to the conversion, rewriting or porting of a legacy system to a modern computer programming language, software libraries, protocols, or hardware platform. Legacy transformation aims to retain and extend the value of the legacy investment through migration to new platforms to benefit from the advantage of the new technologies.
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.
Continuous delivery is a software engineering approach in which teams produce software in short cycles, ensuring that the software can be reliably released at any time and, when releasing the software, doing so manually. It aims at building, testing, and releasing software with greater speed and frequency. The approach helps reduce the cost, time, and risk of delivering changes by allowing for more incremental updates to applications in production. A straightforward and repeatable deployment process is important for continuous delivery.
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.