Generate a Software Maintenance Plan (SMP) and supporting maintenance documentation for SDLC projects. Compliant with ISO/IEC/IEEE 14764:2022. Covers Maintenance Strategy, MR/PR handling workflow, CCB process, maintenance cost estimation, and all...
Optional helper plugins may help in some environments, but they must not be treated as required for this skill.
SDLC Maintenance Skill
<!-- dual-compat-start -->
Use When
Generate a Software Maintenance Plan (SMP) and supporting maintenance documentation for SDLC projects. Compliant with ISO/IEC/IEEE 14764:2022. Covers Maintenance Strategy, MR/PR handling workflow, CCB process, maintenance cost estimation, and all...
The task needs reusable judgment, domain constraints, or a proven workflow rather than ad hoc advice.
Do Not Use When
The task is unrelated to
sdlc-maintenance
or would be better handled by a more specific companion skill.
The request only needs a trivial answer and none of this skill's constraints or references materially help.
Required Inputs
Gather relevant project context, constraints, and the concrete problem to solve.
Confirm the desired deliverable: design, code, review, migration plan, audit, or documentation.
Workflow
Read this
SKILL.md
first, then load only the referenced deep-dive files that are necessary for the task.
Apply the ordered guidance, checklists, and decision rules in this skill instead of cherry-picking isolated snippets.
Produce the deliverable with assumptions, risks, and follow-up work made explicit when they matter.
Quality Standards
Keep outputs execution-oriented, concise, and aligned with the repository's baseline engineering standards.
Preserve compatibility with existing project conventions unless the skill explicitly requires a stronger standard.
Prefer deterministic, reviewable steps over vague advice or tool-specific magic.
Anti-Patterns
Treating examples as copy-paste truth without checking fit, constraints, or failure modes.
Loading every reference file by default instead of using progressive disclosure.
Outputs
A concrete result that fits the task: implementation guidance, review findings, architecture decisions, templates, or generated artifacts.
Clear assumptions, tradeoffs, or unresolved gaps when the task cannot be completed from available context alone.
References used, companion skills, or follow-up actions when they materially improve execution.
Evidence Produced
Category
Artifact
Format
Example
Operability
Software Maintenance Plan (SMP)
Markdown doc compliant with ISO/IEC/IEEE 14764 covering corrective, adaptive, perfective, and preventive maintenance
docs/sdlc/smp-checkout.md
References
Use the links and companion skills already referenced in this file when deeper context is needed.
<!-- dual-compat-end -->
Generate a complete Software Maintenance Plan (SMP) and supporting maintenance documentation for software projects. This skill produces 3 documents that establish the maintenance baseline, define the change request workflow, and track ongoing maintenance metrics.
Load Order
Load
world-class-engineering
.
Load
reliability-engineering
,
engineering-management-system
, and
sdlc-post-deployment
.
Load this skill to formalize the maintenance operating model from real production evidence.
Executable Maintenance Standard
Maintenance documents must define:
intake, classification, and ownership rules
validation, rollout, and rollback expectations for maintenance changes
maintenance metrics tied to real operational evidence
learning loops back into planning, design, and release process
When to Use
Transitioning a delivered system into the maintenance phase
Planning maintenance for a live production system
Establishing a Change Control Board (CCB) and formal MR/PR workflow
Documenting maintenance cost estimates for budget planning
Complying with ISO/IEC/IEEE 14764:2022 maintenance process requirements
Preparing a maintenance strategy for a SaaS platform post-launch
When NOT to Use
Planning development activities before delivery — use
sdlc-planning
skill
Documenting test plans or quality gates — use
sdlc-testing
skill
Creating deployment or release procedures — use
sdlc-user-deploy
skill
Post-deployment health assessment — use
sdlc-post-deployment
skill (run that first; SMP follows)
Document Inventory
#
Document
Purpose
Audience
Phase
1
Software Maintenance Plan (SMP)
Primary governance document: scope, org, process model, CCB, cost, training, records
Periodic measurement: defect rates, MTTR, maintenance type mix, cost actuals vs. estimates
PM, stakeholders, CCB
Periodic (monthly/quarterly)
Standards Basis
The SMP structure is governed by ISO/IEC/IEEE 14764:2022 (Software Engineering — Software Life Cycle Processes — Maintenance), specifically Clause 9 (Software Maintenance Plan), which mandates 13 numbered subsections. This standard is a process standard within the ISO/IEC/IEEE 12207:2017 framework; Clause 6.4.13 of 12207 defines the maintenance process outcomes that the SMP must satisfy.
Relationship to ISO 12207: 14764 is the dedicated maintenance elaboration of 12207. When a project is governed by 12207, the SMP produced under 14764 Clause 9 fulfills the 12207 §6.4.13 process documentation requirement.
Five Maintenance Types
ISO/IEC/IEEE 14764:2022 defines five maintenance types. Every SMP must declare which types are in scope.
Type
Definition
Trigger
Corrective
Reactive modification to fix discovered faults
Bug report, system failure
Adaptive
Modification to keep the software usable in a changed environment
OS upgrade, API deprecation, regulatory change
Perfective
Modification to improve performance or maintainability
Performance complaint, code quality initiative
Preventive
Modification to detect and correct latent faults before they manifest
Code audit findings, proactive refactoring
Additive
Addition of new functionality or features after delivery (new in 2022)
Feature request from stakeholders
Empirical Distribution (Lientz & Swanson baseline): Corrective 20% / Adaptive 25% / Perfective 50% / Preventive 5%. Use this as the planning benchmark when no project-specific history exists. Track actual mix in the Maintenance Metrics Report and adjust future estimates accordingly.
SMP Required Sections (ISO 14764 Clause 9)
The SMP must include all 13 subsections below. Flag
[CONTEXT-GAP]
for any section where project context is absent.
9.1.2 — Identification and control of the plan
Document identifier, version, date, approval authority, and revision history. Links to the parent SDP and SRS.
9.1.3 — Scope of maintenance
Name the five maintenance types covered. State the system being maintained (name, version, deployment environment). Define the maintenance window (hours of operation, response SLAs).
9.1.4 — Designation of maintenance organization
Define roles: Maintenance Manager, Maintenance Engineers, Change Control Board (CCB) members, Configuration Manager, Customer Representative. Specify CCB quorum rules and escalation path.
9.1.5 — References
List all governing documents: SRS, SDD, STP, deployment guide, and this SMP. Include standard references: ISO/IEC/IEEE 14764:2022, ISO/IEC/IEEE 12207:2017.
9.1.6 — Definitions
Define all maintenance-specific terms used in the plan: MR (Modification Request), PR (Problem Report), CCB, MTTR, baseline, corrective/adaptive/perfective/preventive/additive maintenance.
9.1.7 — Processes (maintenance process model selection)
Select and justify one of three process models:
Quick-Fix Model: Fast turnaround; fix applied directly to operational code then back-ported to design docs. Risk: documentation drift. Use only for critical production fixes.
Iterative Enhancement Model: Changes are analyzed, designed, implemented, and tested in mini-cycles before release. Preferred for planned maintenance.
Osborne's Model: Post-delivery fixes integrated into a formal release pipeline with explicit review gates. Use when the CCB requires formal approval before any change.
9.1.8 — Organization and maintenance activities
Define the MR/PR 10-step workflow (see below). Assign responsible role to each step.
9.1.9 — Resources
List tools (version control, issue tracker, CI/CD pipeline, test environments), infrastructure, and third-party dependencies required to execute maintenance.
9.1.10 — Estimate of maintenance costs
Apply one or more estimation methods:
COCOMO II (post-architecture model): $Effort = A \times Size^{E} \times \prod EM_i$ where effort multipliers reflect maintenance context
Historical data ratio: Maintenance effort typically 40–80% of original development cost per year (Grubb & Takang, 2003)
Person-month estimates per maintenance type: State assumptions explicitly; flag estimates as
[ESTIMATE-UNVERIFIED]
until actual data replaces them
9.1.11 — Training
Identify training required for maintenance engineers: system domain knowledge, tool proficiency, standards compliance. State who is responsible for training delivery.
9.1.12 — Software maintenance control requirements
Define CCB authority levels (who can approve corrective fixes vs. perfective enhancements), configuration management (CM) procedures under the SCMP, and the baseline lock/unlock protocol.
9.1.13 — Maintenance records and reports
Specify which records are kept: all MRs/PRs (open and closed), CCB meeting minutes, cost actuals, Maintenance Metrics Reports. State retention period and storage location.
9.2.2 — Personnel resources
Headcount plan: number of maintenance engineers required per maintenance type, skill profiles, and ramp-up time for new team members.
9.2.3 — Environment resources
Maintenance environment specification: hardware, OS, database versions, network access. Must match the production environment documented in the Deployment Guide.
9.2.4 — Financial resources
Annual maintenance budget broken down by maintenance type. Include contingency reserve (recommend 15–20% of total estimate).
MR/PR 10-Step Process (ISO 14764 Clause 6.2)
Every modification — regardless of type — must follow this sequence. No step may be skipped without documented CCB waiver.
Step
Name
Description
Owner
1
Problem/modification identification
MR or PR submitted with system ID, version, environment, and symptom description
Requestor or designated user confirms the change resolves the original MR/PR
Requestor / QA
9
Delivery
Change released to production via CM-controlled deployment procedure
Ops / DevOps
10
Closure
MR/PR record updated to Closed; lessons learned captured; documentation updated
Maintenance Manager
Lehman's Laws
Two of Lehman's eight laws are directly relevant to maintenance planning and serve as the theoretical justification for why an SMP is mandatory, not optional.
Law I — Continuing Change (1974): A program that is used must be continually adapted or it becomes progressively less satisfactory in use.
Law VII — Declining Quality (1996): The quality of an evolving system will appear to be declining unless it is rigorously maintained and adapted to operational environment changes.
Implication for the SMP: These laws establish that software entropy is not accidental — it is a predictable consequence of failing to maintain. The SMP is the engineering control that counteracts both laws. An organization that delivers software without an SMP is accepting Law I and Law VII as inevitable outcomes rather than engineering risks to be managed.
Quality Checklist
All 3 documents generated (or justified why one was skipped)
SMP covers all 13 ISO 14764 Clause 9 subsections
All five maintenance types declared in scope (or explicitly excluded with rationale)
Process model selected (Quick-Fix / Iterative Enhancement / Osborne's) and justified
MR/PR 10-step workflow defined with role assigned to each step
CCB composition documented with quorum rules and escalation path
Maintenance cost estimate uses COCOMO II or historical ratio — no vague estimates
All cost estimates flagged
[ESTIMATE-UNVERIFIED]
until actuals replace them
Lientz/Swanson empirical distribution (20/25/50/5) used as planning baseline
Lehman's Laws I and VII cited as justification for mandatory SMP
Maintenance environment matches production environment in Deployment Guide
Training plan identifies who delivers training and when
Records retention period and storage location specified in 9.1.13
Financial resources section includes 15–20% contingency reserve
Change Request / Problem Report Form template covers: ID, classification, impact, CCB decision, resolution