软件维护与质量管理
软件维护是软件生命周期中历时最长、成本最高的阶段；软件质量管理贯穿整个开发生命周期。
一、软件维护
1.1 定义与重要性
定义：软件交付使用后，为改正错误、满足新需要而修改软件的过程
特点：
- 历时最长的阶段
- 成本最高（可能超过开发成本）
- 约80%的维护工作是非纠错性的
1.2 维护类型
| 类型 | 定义 | 占比 | 示例 |
|---|---|---|---|
| 纠错性维护 | 修复运行中发现的错误 | ~20% | 修复Bug |
| 适应性维护 | 适应外部环境变化 | ~25% | 系统升级、平台迁移 |
| 完善性维护 | 满足新需求，改进功能 | ~50% | 添加新功能、性能优化 |
| 预防性维护 | 提高可维护性，为未来改进创造条件 | ~5% | 代码重构、文档更新 |
考试重点：完善性维护占比最高！
1.3 维护类型辨析
| 场景 | 维护类型 |
|---|---|
| 用户报告程序崩溃 | 纠错性维护 |
| 操作系统升级后程序不兼容 | 适应性维护 |
| 用户要求增加导出Excel功能 | 完善性维护 |
| 开发团队主动重构遗留代码 | 预防性维护 |
| 数据库从MySQL迁移到PostgreSQL | 适应性维护 |
| 优化查询性能 | 完善性维护 |
1.4 软件可维护性
定义：维护人员对软件进行理解、诊断错误、修改的难易程度
影响因素：
| 因素 | 说明 |
|---|---|
| 可理解性 | 结构、逻辑是否清晰易懂 |
| 可测试性 | 是否易于进行测试验证 |
| 可修改性 | 修改某部分对其他部分影响程度 |
| 可移植性 | 迁移到其他环境的难易程度 |
| 文档质量 | 文档是否完整、准确、清晰 |
| 代码规范性 | 是否遵循编码规范 |
| 模块化程度 | 模块划分是否合理 |
二、软件质量模型
2.1 ISO/IEC 9126 质量模型
六大质量特性：
| 特性 | 定义 | 子特性 |
|---|---|---|
| 功能性 | 功能满足需求的程度 | 适合性、准确性、互操作性、安全性、依从性 |
| 可靠性 | 在规定条件下保持性能的能力 | 成熟性、容错性、可恢复性、依从性 |
| 易用性 | 用户理解、学习、使用的难易程度 | 易理解性、易学性、可操作性、吸引性、依从性 |
| 效率 | 性能水平与资源使用的关系 | 时间特性、资源利用性、依从性 |
| 可维护性 | 被修改的难易程度 | 易分析性、易改变性、稳定性、易测试性、依从性 |
| 可移植性 | 转移到其他环境的能力 | 适应性、易安装性、共存性、易替换性、依从性 |
2.2 质量特性详解
功能性 (Functionality)
| 子特性 | 说明 |
|---|---|
| 适合性 | 提供的功能是否满足需求 |
| 准确性 | 结果是否正确精确 |
| 互操作性 | 与其他系统交互的能力 |
| 安全性 | 防止非授权访问的能力 |
可靠性 (Reliability)
| 子特性 | 说明 |
|---|---|
| 成熟性 | 避免软件故障的能力 |
| 容错性 | 出错时维持性能的能力 |
| 可恢复性 | 故障后恢复的能力 |
易用性 (Usability)
| 子特性 | 说明 |
|---|---|
| 易理解性 | 用户理解软件的难易程度 |
| 易学性 | 用户学会使用的难易程度 |
| 可操作性 | 用户操作和控制的难易程度 |
效率 (Efficiency)
| 子特性 | 说明 |
|---|---|
| 时间特性 | 响应时间、处理速度 |
| 资源利用性 | CPU、内存使用情况 |
可维护性 (Maintainability)
| 子特性 | 说明 |
|---|---|
| 易分析性 | 诊断缺陷的难易程度 |
| 易改变性 | 实施修改的难易程度 |
| 稳定性 | 修改带来意外影响的风险 |
| 易测试性 | 测试修改的难易程度 |
可移植性 (Portability)
| 子特性 | 说明 |
|---|---|
| 适应性 | 适应不同环境的能力 |
| 易安装性 | 安装的难易程度 |
| 共存性 | 与其他软件共存的能力 |
| 易替换性 | 替代其他软件的能力 |
三、软件质量保证 (SQA)
3.1 基本概念
定义：确保软件产品和过程符合标准和规程的一系列活动
特点：
- 侧重于过程的监控和改进
- 以预防缺陷为主要目标
- 贯穿整个开发生命周期
3.2 SQA主要内容
| 方面 | 说明 |
|---|---|
| 目标 | 明确质量目标和标准 |
| 承诺 | 管理层对质量的承诺和资源投入 |
| 能力 | 人员技能、工具和过程能力 |
| 活动 | 具体的质量保证活动 |
| 测量 | 度量指标监控质量 |
| 验证 | 评审、检查、测试 |
3.3 SQA活动
- 制定质量计划
- 过程审计
- 评审工作产品
- 缺陷跟踪
- 培训
四、CMMI能力成熟度模型
4.1 概述
CMMI (Capability Maturity Model Integration)：能力成熟度模型集成
来源：美国卡内基梅隆大学软件工程研究所（SEI）
用途：评估和改进组织过程能力和成熟度
4.2 表示方法
| 表示法 | 特点 |
|---|---|
| 阶段式 | 划分成熟度级别，整体评估 |
| 连续式 | 针对特定过程域评估能力级别 |
4.3 阶段式成熟度等级
| 级别 | 名称 | 特征 | 关键词 |
|---|---|---|---|
| ML1 | 初始级 | 过程混乱无序，依赖英雄 | 混乱、不可预测 |
| ML2 | 已管理级 | 项目级过程得到管理 | 项目管理、可重复 |
| ML3 | 已定义级 | 组织级标准过程定义 | 标准化、制度化 |
| ML4 | 量化管理级 | 使用统计技术管理过程 | 量化、可预测 |
| ML5 | 优化级 | 持续过程改进 | 持续优化、创新 |
4.4 各级别关键过程域 (KPA)
ML2 - 已管理级
| 过程域 | 缩写 | 说明 |
|---|---|---|
| 需求管理 | REQM | 管理需求和变更 |
| 项目策划 | PP | 制定项目计划 |
| 项目监控 | PMC | 跟踪项目进展 |
| 供方协议管理 | SAM | 管理供应商 |
| 度量与分析 | MA | 收集和分析数据 |
| 过程与产品质量保证 | PPQA | 质量保证活动 |
| 配置管理 | CM | 管理配置项 |
ML3 - 已定义级
| 过程域 | 缩写 | 说明 |
|---|---|---|
| 需求开发 | RD | 分析和定义需求 |
| 技术解决方案 | TS | 设计和实现 |
| 产品集成 | PI | 集成组件 |
| 验证 | VER | 验证工作产品 |
| 确认 | VAL | 确认满足需求 |
| 组织过程焦点 | OPF | 组织过程改进 |
| 组织过程定义 | OPD | 定义标准过程 |
| 组织培训 | OT | 培训计划 |
| 集成项目管理 | IPM | 综合项目管理 |
| 风险管理 | RSKM | 识别和管理风险 |
| 决策分析与解决 | DAR | 决策支持 |
ML4 - 量化管理级
| 过程域 | 缩写 | 说明 |
|---|---|---|
| 组织过程性能 | OPP | 组织层面的过程性能 |
| 量化项目管理 | QPM | 用量化方法管理项目 |
ML5 - 优化级
| 过程域 | 缩写 | 说明 |
|---|---|---|
| 组织绩效管理 | OPM | 组织绩效改进 |
| 因果分析与解决 | CAR | 分析问题根因 |
4.5 成熟度等级对比
| 级别 | 核心能力 | 过程特征 |
|---|---|---|
| ML1 | 无 | 混乱、随机 |
| ML2 | 项目管理 | 可重复成功 |
| ML3 | 工程能力 | 组织标准化 |
| ML4 | 量化管理 | 可预测 |
| ML5 | 持续改进 | 最优化 |
五、考试要点
高频考点
- 维护类型辨析（特别是完善性维护）
- ISO 9126六大质量特性及子特性
- CMMI五个成熟度等级及特征
- 各级别关键过程域（特别是ML2、ML3）
典型例题
题1：用户要求增加报表导出功能，属于什么维护？ 答案：完善性维护
题2：软件运行速度慢，响应时间长，这主要影响哪个质量特性？ 答案：效率（时间特性）
题3：CMMI ML3的核心特征是？ 答案：组织级标准过程得到定义和制度化
题4：配置管理属于CMMI哪个级别的过程域？ 答案：ML2（已管理级）
记忆口诀
维护类型：
纠错改Bug最直接
适应环境变化改
完善功能占一半
预防未来好维护CMMI等级：
初始混乱靠英雄
管理项目可重复
定义标准全组织
量化数据可预测
优化持续最顶峰质量特性：
功能可靠易使用
效率维护可移植
六大特性要记牢
子特性需细分辨