Maintainability | EPFL Graph Search

Are you an EPFL student looking for a semester project?

Work with us on data science and visualisation projects, and deploy your project as an app on top of GraphSearch.

Maintainability is the ease of maintaining or providing maintenance for a functioning product or service. Depending on the field, it can have slightly different meanings. In engineering, maintainability is the ease with which a product can be maintained to: correct defects or their cause, Repair or replace faulty or worn-out components without having to replace still working parts, prevent unexpected working conditions, maximize a product's useful life, maximize efficiency, reliability, and safety, meet new requirements, make future maintenance easier, or cope with a changing environment. In some cases, maintainability involves a system of continuous improvement - learning from the past to improve the ability to maintain systems, or improve the reliability of systems based on maintenance experience. In telecommunication and several other engineering fields, the term maintainability has the following meanings: A characteristic of design and installation, expressed as the probability that an item will be retained in or restored to a specified condition within a given period of time, when the maintenance is performed by prescribed procedures and resources. The ease with which maintenance of a functional unit can be performed by prescribed requirements. In software engineering, these activities are known as software maintenance (cf. ISO/IEC 9126). Closely related concepts in the software engineering domain are evolvability, modifiability, technical debt, and code smells. The maintainability index is calculated with certain formulae from lines-of-code measures, McCabe measures and Halstead complexity measures. The measurement and tracking of maintainability are intended to help reduce or reverse a system's tendency toward "code entropy" or degraded integrity, and to indicate when it becomes cheaper and/or less risky to rewrite the code than it is to change it.

About this result

This page is automatically generated and may contain information that is not correct, complete, up-to-date, or relevant to your search query. The same applies to every other page on this website. Please make sure to verify the information with EPFL's official sources.

Related publications (2)

Related concepts (6)

Related lectures (2)

Dynamic Personalized Ranking

Jérémie Rappaz

Personalized ranking methods are at the core of many systems that learn to produce recommendations from user feedbacks. Their primary objective is to identify relevant items from very large vocabulari

EPFL2022

Specialising Parsers for Queries

Manohar Jonnalagedda

Many software systems consist of data processing components that analyse large datasets to gather information and learn from these. Often, only part of the data is relevant for analysis. Data processi

EPFL2016

Capacitor Circuits EE-105: Electrical engineering science and technology (Spring)

Covers the analysis of circuits containing capacitors and their voltage behavior.

Rheology of Liquids: Constitutive Laws and Viscosity Models MSE-206: Rheology and fluid mechanics

Covers the rheology of liquids, including viscometric flows and non-Newtonian flows.

Software architecture

Software architecture is the set of structures needed to reason about 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 the blueprints for the system and the development project, which project management can later use to extrapolate the tasks necessary to be executed by the teams and people involved.

Non-functional requirement

In systems engineering and requirements engineering, a non-functional requirement (NFR) is a requirement that specifies criteria that can be used to judge the operation of a system, rather than specific behaviours. They are contrasted with functional requirements that define specific behavior or functions. The plan for implementing functional requirements is detailed in the system design. The plan for implementing non-functional requirements is detailed in the system architecture, because they are usually architecturally significant requirements.

Maintainability