====== Maintainability ====== [[dido:99_annexes:annex-b-terms-and-definitions:start|Go up to Terms and Definitions]] ===== Discussion ===== Maintainability is a [[dido:99_annexes:annex-b-terms-and-definitions:q:quality_characteristic|Quality Characteristic]] concerning the degree to which a subject supports effective and efficient analysis, correction, modification, testing, and controlled change. Maintainability applies to subjects such as: * A [[dido:99_annexes:annex-b-terms-and-definitions:c:candidate_solution|Candidate Solution]] * A [[dido:99_annexes:annex-b-terms-and-definitions:d:distributed_system|Distributed System]] * A system * A service * A software component * A [[dido:99_annexes:annex-b-terms-and-definitions:n:node|Node]] * A [[dido:99_annexes:annex-b-terms-and-definitions:q:qualified_node|Qualified Node]] * A [[dido:99_annexes:annex-b-terms-and-definitions:n:node_set|Node Set]] * A governed function implementation * A deployment * A [[dido:99_annexes:annex-b-terms-and-definitions:c:configuration|Configuration]] * Another subject requiring controlled change Maintainability concerns activities such as: * Analysis * Diagnosis * Defect correction * Policy update * Configuration change * Interface change * Dependency update * Refactoring * Testing * Regression testing * Controlled release * Version control * Rollback * Retirement of obsolete versions Maintainability supports long-term operation, qualification continuity, auditability, evidence continuity, and controlled evolution. A Maintainability evaluation can identify: * The evaluated subject * The applicable change * The reason for the change * The affected components * The affected interfaces * The affected dependencies * The applicable [[dido:99_annexes:annex-b-terms-and-definitions:c:configuration|Configuration]] * The applicable [[dido:99_annexes:annex-b-terms-and-definitions:v:version|Version]] * The effort required to analyse the change * The effort required to implement the change * The effort required to test the change * The time required to complete the change * The defects introduced by the change * The applicable regression scope * The applicable rollback procedure * The applicable DIDO [[dido:99_annexes:annex-b-terms-and-definitions:b:baseline|Baseline]] * The applicable [[dido:99_annexes:annex-b-terms-and-definitions:v:validation_criteria|Validation Criteria]] * The applicable [[dido:99_annexes:annex-b-terms-and-definitions:a:acceptance_criteria|Acceptance Criteria]] * Its [[dido:99_annexes:annex-b-terms-and-definitions:e:evidence|Evidence]] * Its [[dido:99_annexes:annex-b-terms-and-definitions:p:provenance|Provenance]] * Its [[dido:99_annexes:annex-b-terms-and-definitions:t:traceability|Traceability]] In the Governed Node Service Market, Maintainability supports: * Long-term operation * Qualification continuity * Defect correction * Policy updates * Configuration review * Version control * Auditability * Controlled release * Rollback * Retirement of obsolete implementations A maintainable Qualified Node continues to satisfy its governed function obligations after an approved fix, update, configuration change, policy change, interface change, or deployment change. Controlled maintenance preserves: * Qualification obligations * Functional obligations * Non-functional obligations * Evidence obligations * Service-level expectations * Interoperability * Traceability ===== Definition ===== //[[dido:99_annexes:annex-b-terms-and-definitions:q:quality_characteristic|Quality Characteristic]] concerning the degree to which a subject supports effective and efficient analysis, correction, modification, testing, and controlled change// ===== Source ===== Adapted from: * [[https://www.iso.org/standard/78176.html|ISO/IEC 25010:2023, Systems and software Quality Requirements and Evaluation (SQuaRE) — Product quality model]] * Financial Systems Archetype, Part 7: Governed Node Service Market * DIDO Reference Implementation Conceptual Model * DIDO-TE draft Requirements Register The original shared definition described Maintainability as the ability of a governed function implementation to support analysis, correction, update, testing, and controlled change. This revision generalizes the subject for use throughout the shared DIDO corpus while preserving the original Governed Node Service Market application. ===== Note ===== Maintainability supports long-term operation and governance. A maintainable Node supports: * Version control * Defect correction * Configuration review * Test Evidence * Controlled release * Rollback * Retirement of obsolete versions Maintainability differs from [[dido:99_annexes:annex-b-terms-and-definitions:p:portability|Portability]]: * Portability concerns movement across approved platforms, runtimes, or deployment environments * Maintainability concerns controlled analysis, correction, modification, testing, and change Maintainability differs from [[dido:99_annexes:annex-b-terms-and-definitions:r:reliability|Reliability]]: * Reliability concerns the degree to which a subject performs specified functions under specified conditions for a specified period * Maintainability concerns the degree to which the subject supports controlled analysis, correction, modification, testing, and change Maintainability differs from [[dido:99_annexes:annex-b-terms-and-definitions:r:recoverability|Recoverability]]: * Recoverability concerns restoration after an interruption or failure * Maintainability concerns controlled changes to the subject and its supporting artifacts A maintainable subject does not necessarily require fewer changes. Maintainability concerns the effectiveness, efficiency, control, and verifiability of the change process. A Maintainability claim requires identified evaluation conditions. Useful measures include: * Time required to identify a defect * Time required to locate affected components * Time required to implement a correction * Time required to complete regression testing * Number of components affected * Number of defects introduced * Percentage of tests automated * Percentage of changes successfully rolled back * Completeness of change Evidence * Completeness of Traceability ===== Example ===== A policy-evaluation Qualified Node receives an approved policy update. The provider: * Records the applicable change request * Identifies affected components and interfaces * Updates the implementation * Runs the applicable regression tests * Records the resulting Version and Evidence * Verifies continued satisfaction of the governed function obligations * Releases the updated implementation through the controlled release process * Retains the preceding Version for rollback according to the applicable policy The resulting records support evaluation of the Qualified Node's Maintainability. In a DIDO-TE evaluation, multiple Candidate Solutions receive the same controlled change request. DIDO-TE compares the analysis effort, implementation effort, testing effort, elapsed time, introduced defects, rollback results, Evidence, and Traceability associated with each Candidate Solution. ---- © 2026 Dido Solutions, Inc. and Jackrabbit Consulting, Inc.