Types of Maintenance

Types of Maintenance

Successful software products tend to have very long life spans when measured from initial release to final retirement. For example, the initial release of Microsoft Word was in 1983, so that software product has been in use for more than 30 years with no retirement in sight. However, according to Sommerville, “During their lifetime, operational software systems have to change if they are to remain useful.” [Sommerville-16]

The need to change existing software products may result from:

  • The need for additional or changed functionality
  • Incremental or evolutionary development
  • Defects in the work products
  • Changes to the business climate or business needs
  • Changes to stakeholder requirements, industry standards, or regulations
  • Changes to the hardware or target platform
  • Technological advancements
  • Competitive motivations and threats
  • The need for more reliability, usability, security, or safety in the software

Therefore, changes are inevitable if the software is to remain technically current, competitive in the marketplace, retain its value, and continue to meet the stakeholders’ needs.

Software maintenance is the process of making changes to software products after they have been released into operations. In some cases, these software products may be legacy software, a term used to mean older software written using antiquated methods, programming languages, or technologies. Legacy software refers to software that is out of date and that needs to be re-engineered or replaced but that is still in use in operations.

Software maintenance adapts, optimizes, enhances, or corrects defects in a released software product while still preserving that product’s quality and integrity. In other words, the objective of software maintenance is to change part of a released software product without breaking another part of that product.

Since agile development processes are based on a continuous flow of software development supported by an emerging product backlog, there is no real distinction between initial development and ongoing post-delivery maintenance. All iterations after the software’s initial release could be considered maintenance iterations.

Corrective Maintenance

Even with the best state-of-the-practice software quality assurance and control techniques, it is likely that the users of the software will encounter at least a few software failures once the software products are delivered to operations. The IEEE Standard for Software Engineering—Software Life Cycle Processes— Maintenance defines corrective maintenance as “the reactive modification of a software product performed after delivery to correct discovered problems.” [IEEE-06] Corrective maintenance is performed to repair the defects that cause operational failures or other issues. Corrective maintenance can also be performed to correct latent defects that were found in released software during subsequent testing cycles.

Perfective Maintenance

As the software is used, the users, customers, or other external stakeholders may discover requirements that they need to add to the software product. Marketing or engineering may also come up with new requirements to add to the software to continue to innovate the software, to remain technically current, or to meet competitive threats. The IEEE/ISO/IEC Systems and Software Engineering—Vocabulary defines perfective maintenance as “improvements in the software’s performance or functionality, for example, in response to user suggestions or requests.” [IEEE/ISO/IEC-17] Perfective maintenance is performed to add new requirements to the software (to “perfect” the product). Perfective maintenance is the normal enhancement of successful, working software products over time so that the software retains its value to the stakeholders.

Adaptive Maintenance

Adaptive maintenance is Modifications to an existing software product performed after delivery, to adapt that product to new or changed external interfaces, environments, platforms, operating systems, or other elements. As time progresses, a software product’s operational environment is likely to change. Examples of changes to the external environment in which that software must function include:

  • External interface definitions may change (for example, communications, protocols, external data file structures)
  • Government regulations or other business rules may change (for example, tax code or regulatory reporting requirements)
  • Hardware and software that interface with the product may change (for example, new versions of the operating system, new or updated peripherals or other hardware, new or updated interfacing software applications, additional or modified fields/records in external databases)

Preventive Maintenance

Preventive maintenance is “modification of a software product after delivery to detect and correct latent faults in the software product before they manifest as failures.” [IEEE-06]

Preventive maintenance is a proactive approach to prevent problems with the software before they occur. For example, additional error handling and fault tolerance might be added to a safety-critical system, or an enhanced encryption methodology might be added to improve software security. Self-diagnostic testing might also be added to the software product.

As software products change over time they can deteriorate, especially if good design techniques were not employed when the software was originally developed. It may become necessary to modify an existing, released software product by refactoring it to eliminate duplication, complexity, or awkward structure, or to reengineer it to make it easier to maintain going forward. This is another type of preventive maintenance.

References

IEEE-06: IEEE Standards Software Engineering, Standard for Software Engineering— Software Life Cycle Processes—Maintenance, ISO/IEC 14764. New York, NY: The Institute of Electrical and Electronics Engineers. 2006.

IEEE/ISO/IEC-17: IEEE/ISO/IEC 24765 Systems and Software Engineering—Vocabulary. Geneva, Switzerland: ISO. New York, NY: The Institute of Electrical and Electronic Engineers. 2017.

Sommerville-16: Sommerville, Ian. Software Engineering. Tenth Edition, Boston: Pearson. 2016.

______________________________________________________________

Certified Software Quality Engineer (CSQE) Preparation Course

Online, Open Enrollment Course Presented by Linda Westfall

January 29 - February 2, 2024

9:00 am – 6:00 pm Central Time

Our Certified Software Quality Engineer (CSQE) Preparation?course is design to be a comprehensive, in-depth review of all of the topics in the ASQ’s CSQE Body of Knowledge.

If you are thinking about taking the ASQ CSQE exam then this course can help you get ready. This course has been recently updated to the newest CSQE Body of Knowledge 2023 version.

This course:

  • Helps CSQE candidates prepare for and perform well on the ASQ CSQE exam
  • Provides an excellent knowledge base for anyone interested in implementing or improving Software Quality Engineering techniques and practices in their organization

This course includes:

  • For each sub-section of the ASQ CSQE Body of Knowledge: One or more videos and a three-question practice quiz
  • Introductory materials including information on the class, the CSQE certification and the CSQE Exam
  • A bibliography of reference materials and websites
  • An extensive glossary and index that can be printed to take into the exam as a reference
  • Three complete 160 item practice exams that match the distribution of topic areas on the actual exam

*** Special Bonus ***

Purchase this course and receive a free registration to our On-Demand Web-Based version of this course.

To learn more about this course click here

To purchase this course click here

______________________________________________________________

Upcoming webinars from the Software Excellence Academy - sponsored by the ASQ Software Division

January 2024 - Topic of the Month: Communication, Collaboration & Trust

Scott Duncan will be presenting three webinars this month on Communication, Collaboration, and Trust. You can submit your questions before these webinars by emailing them to [email protected]

  • January 10, 2024 – Listening presented by Linda Westfall
  • January 16, 2024 – Part 2: Collaboration presented by Scott Duncan (Note this webinar is on a Tuesday)
  • January 24, 2024 – Part 3: Trust presented by Scott Duncan

February 2024 Topic of the Month: Agile

For more information about our webinars or to register for one or more of these webinars click here.

_____________________________________________________

The following webinar recordings are currently available for free on our website:

  • Software Assurance (SwA) from the Lens of the Contract?presented by Sabrina Patten
  • Army Software Suitability Statement Criteria for AI presented by Adam Hilburn
  • Equivalence Class Testing for Black-Box Testers presented by Linda Westfall
  • Debunking LinkedIn Lies and Unlocking Your Career Success presented by Diana Alt
  • Building Trust, Communications, and Respect at Work: Enhance Your Multi-Generational Culture presented by Zac Jarrard and Douglas C. Woods
  • CSQE Body of Knowledge - What's Changed presented by Linda Westfall
  • True Shift Left Is Not Mere Marginally Earlier Test Execution presented by Robin Goldsmith
  • The Building Blocks of Organizational Culture presented by Grace Duffy

To watch these webinars click here and scroll down to the recordings.

_____________________________________________________

? 2023 Westfall Team. All Rights Reserved

an excellent infographic to quickly explain and capture interest to read the article! Very valuable to one who is simply a user.

回复
Scott Duncan

Lead Coach & Trainer at Agile Software Qualities

1 年

Thanks...a good reminder of the different kinds.

回复

要查看或添加评论,请登录

Linda Westfall的更多文章

  • DevOps Defined

    DevOps Defined

    “DevOps is the emerging professional movement that advocates a collaborative working relationship between Development…

    4 条评论
  • Risk-Based Peer Reviews

    Risk-Based Peer Reviews

    Risk-based peer reviews focus on the identification of software work products with the highest risk exposure. In…

    6 条评论
  • Types of Peer Reviews

    Types of Peer Reviews

    There are many different types of peer reviews called by many different names in the software industry. Peer reviews go…

  • Informal vs. Formal Peer Reviews

    Informal vs. Formal Peer Reviews

    Peer reviews can vary greatly in their level of formality. At the most informal end of the peer review spectrum, a…

    2 条评论
  • Data to Information to Knowledge

    Data to Information to Knowledge

    In a previous article, Measurement Defined, I talked about Norman Fenton’s definition of measurement as “the process by…

    4 条评论
  • Why Should Your Team Conduct Peer Reviews?

    Why Should Your Team Conduct Peer Reviews?

    What is a Peer Review? The IEEE/ISO/IEC Systems and Software Engineering Vocabulary defines a review as “a process or…

    4 条评论
  • Kiviat Charts

    Kiviat Charts

    Many times, it takes more than one metric to understand, evaluate or control a software project, product, process, or…

    2 条评论
  • Software Configuration Management Audits Part 4 - In Process Audits

    Software Configuration Management Audits Part 4 - In Process Audits

    In the first part of this article, we introduced the three different types of Software Configuration Management Audit:…

  • Software Configuration Management Audits Part 3 – Physical Configuration Audits (PCA)

    Software Configuration Management Audits Part 3 – Physical Configuration Audits (PCA)

    In the first part of this article, we introduced the three different types of Software Configuration Management Audit:…

    1 条评论
  • Software Configuration Management Audits Part 2 – Functional Configuration Audits (FCA)

    Software Configuration Management Audits Part 2 – Functional Configuration Audits (FCA)

    In the first part of this article, we introduced the three different types of Software Configuration Management Audit:…

    1 条评论

社区洞察

其他会员也浏览了