sdlc-maintenance

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Platform Notes

平台说明

Optional helper plugins may help in some environments, but they must not be treated as required for this skill.

可选辅助插件可能在部分环境中提供帮助，但不得将其视为使用本技能的必备条件。

SDLC Maintenance Skill

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.

为SDLC项目生成软件维护计划（SMP）及配套维护文档，符合ISO/IEC/IEEE 14764:2022标准。内容涵盖维护策略、MR/PR处理流程、CCB流程、维护成本估算等全部相关内容
任务需要可复用的判断逻辑、领域约束或成熟的工作流程，而非临时建议

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.

任务与
```
sdlc-maintenance
```
无关，或更适合由更专业的配套技能处理
请求仅需要简单答案，本技能的约束条件或参考内容无法提供实质性帮助

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.

首先阅读本
```
SKILL.md
```
文件，然后仅加载完成任务所需的相关深度参考文件
应用本技能中的有序指导、检查清单和决策规则，而非随意挑选孤立片段
生成交付物时，需明确标注关键假设、风险及后续工作

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`

类别	工件	格式	示例
可操作性	Software Maintenance Plan (SMP)	符合ISO/IEC/IEEE 14764标准的Markdown文档，涵盖纠正性、适应性、完善性、预防性维护	`docs/sdlc/smp-checkout.md`

References

参考资料

Use the links and companion skills already referenced in this file when deeper context is needed.

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.

当需要更深入的上下文时，使用本文件中已引用的链接和配套技能

为软件项目生成完整的**Software Maintenance Plan (SMP)**及配套维护文档。本技能将生成3份文档，用于建立维护基准、定义变更请求流程并跟踪持续维护指标。

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.

加载
```
world-class-engineering
```

加载

reliability-engineering

、

engineering-management-system

和

sdlc-post-deployment

加载本技能，基于实际生产证据规范化维护运营模型

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

将已交付系统转入维护阶段
为在线生产系统规划维护工作
建立**Change Control Board (CCB)**及正式的MR/PR工作流程
为预算规划记录维护成本估算
满足ISO/IEC/IEEE 14764:2022维护流程要求
为SaaS平台上线后制定维护策略

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)

交付前的开发活动规划——使用
```
sdlc-planning
```
技能
测试计划或质量门文档编制——使用
```
sdlc-testing
```
技能
部署或发布流程创建——使用
```
sdlc-user-deploy
```
技能
部署后健康评估——使用
```
sdlc-post-deployment
```
技能（先运行该技能，再生成SMP）

Document Inventory

文档清单

#	Document	Purpose	Audience	Phase
1	Software Maintenance Plan (SMP)	Primary governance document: scope, org, process model, CCB, cost, training, records	Maintenance team, PM, stakeholders	Maintenance phase
2	Change Request / Problem Report Form	MR/PR intake template: identification, classification, impact, approval, resolution	Developers, CCB, end users	Ongoing
3	Maintenance Metrics Report	Periodic measurement: defect rates, MTTR, maintenance type mix, cost actuals vs. estimates	PM, stakeholders, CCB	Periodic (monthly/quarterly)

序号	文档	目的	受众	阶段
1	Software Maintenance Plan (SMP)	核心治理文档：范围、组织、流程模型、CCB、成本、培训、记录	维护团队、项目经理、利益相关方	维护阶段
2	变更请求/问题报告表单	MR/PR接收模板：标识、分类、影响、审批、解决方案	开发人员、CCB、终端用户	持续维护阶段
3	维护指标报告	定期测量：缺陷率、MTTR、维护类型占比、实际成本与估算对比	项目经理、利益相关方、CCB	定期（月度/季度）

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.

SMP结构受ISO/IEC/IEEE 14764:2022（软件工程——软件生命周期流程——维护）管控，特别是第9条款（软件维护计划），该条款要求包含13个编号子章节。本标准是ISO/IEC/IEEE 12207:2017框架内的流程标准；12207的第6.4.13条款定义了SMP必须满足的维护流程成果要求。

与ISO 12207的关系：14764是12207中维护环节的详细阐述。当项目受12207管控时，依据14764第9条款生成的SMP可满足12207第6.4.13条款的流程文档要求。

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.

ISO/IEC/IEEE 14764:2022定义了五种维护类型。每个SMP必须声明涵盖的维护类型。

类型	定义	触发条件
纠正性维护	对已发现故障进行响应式修改以修复问题	Bug报告、系统故障
适应性维护	修改软件以使其在环境变化后仍可使用	操作系统升级、API弃用、法规变更
完善性维护	修改软件以提升性能或可维护性	性能投诉、代码质量改进计划
预防性维护	修改软件以检测并纠正潜在故障，避免其显现	代码审计发现、主动重构
添加性维护	交付后新增功能或特性（2022版新增）	利益相关方的功能请求

经验分布（Lientz & Swanson基准）：纠正性20% / 适应性25% / 完善性50% / 预防性5%。当无项目特定历史数据时，以此作为规划基准。在维护指标报告中跟踪实际占比，并相应调整未来估算。

SMP Required Sections (ISO 14764 Clause 9)

SMP必备章节（ISO 14764第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).

SMP必须包含以下全部13个子章节。若某章节缺少项目上下文，需标记

[CONTEXT-GAP]

。

9.1.2 — 计划的标识与管控 文档标识符、版本、日期、审批权限及修订历史。链接至父级SDP和SRS。

9.1.3 — 维护范围 列出涵盖的五种维护类型。说明被维护系统（名称、版本、部署环境）。定义维护窗口（运营时间、响应SLA）。

9.1.4 — 维护组织指定 定义角色：维护经理、维护工程师、Change Control Board (CCB)成员、配置经理、客户代表。明确CCB法定人数规则和升级路径。

9.1.5 — 参考资料 列出所有管控文档：SRS、SDD、STP、部署指南及本SMP。包含标准参考：ISO/IEC/IEEE 14764:2022、ISO/IEC/IEEE 12207:2017。

9.1.6 — 定义 定义计划中使用的所有维护特定术语：MR（变更请求）、PR（问题报告）、CCB、MTTR、基准、纠正性/适应性/完善性/预防性/添加性维护。

9.1.7 — 流程（维护流程模型选择） 选择并论证以下三种流程模型之一：

快速修复模型：周转速度快；直接对运营代码进行修复，随后反向同步至设计文档。风险：文档与代码不一致。仅用于关键生产修复。
迭代增强模型：变更经过分析、设计、实现和测试的迷你周期后再发布。为计划维护的首选模型。
Osborne模型：交付后的修复整合至正式发布流程，包含明确的评审关卡。当CCB要求任何变更需经正式审批时使用。

9.1.8 — 组织与维护活动 定义MR/PR的10步工作流程（见下文）。为每个步骤分配负责角色。

9.1.9 — 资源 列出执行维护所需的工具（版本控制、问题跟踪器、CI/CD流水线、测试环境）、基础设施及第三方依赖。

9.1.10 — 维护成本估算 应用一种或多种估算方法：

COCOMO II（后架构模型）：$Effort = A \times Size^{E} \times \prod EM_i$，其中工作量乘数反映维护上下文
历史数据比率：维护工作量通常为原始开发成本的每年40–80%（Grubb & Takang, 2003）
按维护类型估算人月：明确说明假设；在实际数据替换估算前，标记估算为
```
[ESTIMATE-UNVERIFIED]
```

9.1.11 — 培训 确定维护工程师所需的培训：系统领域知识、工具熟练度、标准合规性。说明培训交付责任人。

9.1.12 — 软件维护管控要求 定义CCB权限级别（谁可批准纠正性修复 vs 完善性增强）、SCMP下的配置管理（CM）流程，以及基准锁定/解锁协议。

9.1.13 — 维护记录与报告 指定需保存的记录：所有MR/PR（已打开和已关闭）、CCB会议纪要、实际成本、维护指标报告。说明保留期限和存储位置。

9.2.2 — 人员资源 人员计划：每种维护类型所需的维护工程师数量、技能配置，以及新团队成员的上手时间。

9.2.3 — 环境资源 维护环境规范：硬件、操作系统、数据库版本、网络访问权限。必须与部署指南中记录的生产环境一致。

9.2.4 — 财务资源 按维护类型细分的年度维护预算。包含应急储备金（建议为总估算的15–20%）。

MR/PR 10-Step Process (ISO 14764 Clause 6.2)

MR/PR 10步流程（ISO 14764第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
2	Analysis	Impact assessment: affected modules, risk level, effort estimate, classification (corrective/adaptive/perfective/preventive/additive)	Maintenance Engineer
3	CCB review	CCB evaluates analysis, approves, defers, or rejects the change	CCB
4	Design	Technical solution designed; existing design documents updated	Maintenance Engineer
5	Implementation	Code change developed against approved design	Developer
6	Unit testing	Verify the change in isolation per STP criteria	Developer
7	Integration/regression testing	Verify no regression; run full test suite	QA
8	Acceptance testing	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

所有变更——无论类型——必须遵循此流程。未经CCB书面豁免，不得跳过任何步骤。

步骤	名称	描述	负责人
1	问题/变更识别	提交MR或PR，包含系统ID、版本、环境及症状描述	请求方
2	分析	影响评估：受影响模块、风险等级、工作量估算、分类（纠正性/适应性/完善性/预防性/添加性）	维护工程师
3	CCB评审	CCB评估分析结果，批准、推迟或拒绝变更	CCB
4	设计	设计技术解决方案；更新现有设计文档	维护工程师
5	实现	根据获批设计开发代码变更	开发人员
6	单元测试	按照STP标准单独验证变更	开发人员
7	集成/回归测试	验证无回归问题；运行完整测试套件	QA
8	验收测试	请求方或指定用户确认变更解决了原始MR/PR中的问题	请求方 / QA
9	交付	通过CM管控的部署流程将变更发布至生产环境	Ops / DevOps
10	关闭	将MR/PR记录更新为已关闭；总结经验教训；更新文档	维护经理

Lehman's Laws

莱曼定律（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.

莱曼八项定律中有两项与维护规划直接相关，是SMP为必备项而非可选项的理论依据。

定律I — 持续变更（1974）：正在使用的程序必须持续适配，否则其适用性会逐渐下降。

定律VII — 质量下降（1996）：若不严格维护并适配运营环境变化，演进系统的质量会呈现下降趋势。

对SMP的启示：这些定律表明软件熵并非偶然——它是维护不力的可预测结果。SMP是抵消这两项定律的工程管控手段。若组织交付软件时未制定SMP，就是将定律I和定律VII视为必然结果，而非需要管理的工程风险。

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
Maintenance Metrics Report covers: defect rates, MTTR, type mix, cost actuals
All documents cross-reference the SRS, SDP, STP, and Deployment Guide
Maintenance workflow includes release evidence, rollback posture, and documentation update requirements
No vague language ("fast fixes", "as needed") — all SLAs have numeric targets

已生成全部3份文档（或已说明跳过某份文档的理由）
SMP涵盖ISO 14764第9条款的全部13个子章节
已声明五种维护类型的涵盖范围（或已明确排除并说明理由）
已选择并论证流程模型（快速修复/迭代增强/Osborne模型）
已定义MR/PR的10步工作流程，并为每个步骤分配角色
已记录CCB组成、法定人数规则和升级路径
维护成本估算使用COCOMO II或历史比率——无模糊估算
所有成本估算均标记
```
[ESTIMATE-UNVERIFIED]
```
，直至实际数据替换
已使用Lientz/Swanson经验分布（20/25/50/5）作为规划基准
已引用莱曼定律I和VII作为SMP强制性的依据
维护环境与部署指南中的生产环境一致
培训计划明确了培训交付方和时间
9.1.13章节已指定记录保留期限和存储位置
财务资源章节包含15–20%的应急储备金
变更请求/问题报告表单模板涵盖：ID、分类、影响、CCB决策、解决方案
维护指标报告涵盖：缺陷率、MTTR、类型占比、实际成本
所有文档均交叉引用SRS、SDP、STP和部署指南
维护流程包含发布证据、回滚预案和文档更新要求
无模糊表述（如"快速修复"、"按需"）——所有SLA均有数值目标

Anti-Patterns

反模式

Anti-Pattern	Why It Fails	Do This Instead
No SMP at product launch	Teams improvise; fixes are inconsistent; costs balloon	Draft SMP during final testing phase; activate at go-live
Treating all changes as corrective	Perfective and adaptive work goes unplanned and unbudgeted	Classify every MR/PR using the five-type taxonomy at intake
Quick-Fix model as the default	Documentation drifts from code; next maintainer inherits technical debt	Default to Iterative Enhancement; Quick-Fix requires documented CCB waiver
CCB with no quorum rules	Changes approved by a single person; no audit trail	Define minimum quorum (e.g., 3 of 5 members) in SMP §9.1.4
Ignoring Lehman's Laws	Management treats maintenance as optional spend and cuts budget mid-year	Cite Law I and Law VII in the SMP business case to anchor the budget
Vague cost estimates with no method	Budget is arbitrary; overruns are guaranteed	Use COCOMO II or historical ratio; document all assumptions
No regression testing gate (Step 7)	Fixes break other features silently	Step 7 is mandatory before acceptance; reference STP for suite scope
Closing MRs without documentation updates	System documentation diverges from deployed code over time	Step 10 requires documentation update before closure

反模式	失败原因	正确做法
产品上线时无SMP	团队临时应变；修复不一致；成本激增	在最终测试阶段起草SMP；上线时启用
将所有变更视为纠正性维护	完善性和适应性工作无规划、无预算	在接收时使用五类分类法对每个MR/PR进行分类
默认使用快速修复模型	文档与代码脱节；后续维护人员继承技术债务	默认使用迭代增强模型；快速修复需经CCB书面豁免
CCB无法定人数规则	变更由单人批准；无审计轨迹	在SMP第9.1.4章节定义最低法定人数（如5人中的3人）
忽略莱曼定律	管理层将维护视为可选支出，年中削减预算	在SMP商业案例中引用定律I和VII，锚定预算
无方法的模糊成本估算	预算随意；超支不可避免	使用COCOMO II或历史比率；记录所有假设
无回归测试关卡（步骤7）	修复会静默破坏其他功能	步骤7为验收前的必备环节；参考STP确定测试套件范围
未更新文档即关闭MR	系统文档与部署代码逐渐脱节	步骤10要求先更新文档再关闭

Cross-References

交叉引用

Upstream Skills (use BEFORE this skill)

上游技能（在本技能之前使用）

Skill	Relationship
`sdlc-user-deploy`	Deployment Guide documents the production environment that §9.2.3 must match. Release procedures inform the Step 9 delivery process.
`sdlc-testing`	STP defines the regression suite scope used in MR/PR Step 7 and acceptance criteria in Step 8.
`sdlc-post-deployment`	PDER provides first-90-day metrics (defect rate, MTTR, type mix) that seed the SMP cost estimates in §9.1.10.

技能	关系
`sdlc-user-deploy`	部署指南记录了第9.2.3章节必须匹配的生产环境。发布流程为步骤9的交付流程提供参考。
`sdlc-testing`	STP定义了MR/PR步骤7中使用的回归套件范围，以及步骤8中的验收标准。
`sdlc-post-deployment`	PDER提供了前90天的指标（缺陷率、MTTR、类型占比），为SMP第9.1.10章节的成本估算提供基础数据。

Parallel Skills (use ALONGSIDE this skill)

并行技能（与本技能同时使用）

Skill	Relationship
`sdlc-planning`	SCMP governs CM procedures referenced in §9.1.12. QA Plan standards apply to maintenance quality gates.

技能	关系
`sdlc-planning`	SCMP管控第9.1.12章节引用的CM流程。QA计划标准适用于维护质量关卡。

Sibling SDLC Skills

兄弟SDLC技能

Skill	Phase	Status
`sdlc-planning`	Planning & Management	Available
`sdlc-design`	Design & Architecture	Available
`sdlc-testing`	Testing & Quality	Available
`sdlc-user-deploy`	Delivery & Deployment	Available
`sdlc-post-deployment`	Post-Deployment Evaluation	Available
`sdlc-maintenance`	Software Maintenance	This Skill

Back to: Skills Repository Related: sdlc-planning | sdlc-testing | sdlc-user-deploy | sdlc-post-deployment Last Updated: 2026-03-15 (created per ISO/IEC/IEEE 14764:2022 Clause 9 + Grubb & Takang 2003)

技能	阶段	状态
`sdlc-planning`	规划与管理	可用
`sdlc-design`	设计与架构	可用
`sdlc-testing`	测试与质量	可用
`sdlc-user-deploy`	交付与部署	可用
`sdlc-post-deployment`	部署后评估	可用
`sdlc-maintenance`	软件维护	本技能

返回： 技能仓库 相关： sdlc-planning | sdlc-testing | sdlc-user-deploy | sdlc-post-deployment 最后更新： 2026-03-15（依据ISO/IEC/IEEE 14764:2022第9条款 + Grubb & Takang 2003创建）

References

参考资料

../sdlc-lifecycle.md: Shared SDLC execution model and lifecycle gates.

../sdlc-lifecycle.md：共享SDLC执行模型和生命周期关卡。