06. 系统开发基础¶

软件工程、开发方法与模型、需求分析、设计、测试、维护、质量与文档。

配套阅读：系统开发基础：课件笔记，含课程配图、例题和参考解析。

本章目录¶

软件工程概览¶

--- markmap: height: 760 initialExpandLevel: 2 autoFit: true colorFreezeLevel: 2 maxWidth: 280 spacingHorizontal: 80 spacingVertical: 12 nodeMinHeight: 24 paddingX: 10 --- # 软件工程 ## 开发过程 - [生命周期与开发模型](/software-design/06-system-development/#lifecycle) - 从可行性、需求与设计到实现、测试和维护 - 瀑布、V 模型、原型、增量、螺旋与统一过程 - 敏捷协作、过程改进与软件文档 - [需求分析与系统设计](/software-design/06-system-development/#requirements-and-design) - 功能、质量与约束；数据流图与业务规则 - 架构、模块、数据、接口和人机界面 - 高内聚、低耦合与信息隐藏 - [数据库设计](/software-design/09-databases/) - 将数据需求落实为模型、结构与约束 ## 质量与协作 - [测试、质量与维护](/software-design/06-system-development/#testing-and-maintenance) - 黑盒、白盒、测试层次与回归测试 - 圈复杂度、质量特性与维护类型 - [项目管理](/software-design/07-project-management/#project-management) - 进度网络、关键路径、风险和成本 - 沟通、人员、配置与变更控制 ## 面向对象 - [面向对象基础](/software-design/08-object-oriented/#object-oriented) - 对象、类、封装、继承、多态与设计原则 - [UML](/software-design/08-object-oriented/#uml) - 结构、行为、交互与关系语义 - [设计模式](/software-design/08-object-oriented/#design-patterns) - 创建型、结构型与行为型，共 23 种 ## 学科索引 - [软件工程](/software-design/06-system-development/) - [知识产权与标准化](/software-design/12-intellectual-property/#intellectual-property-and-standards)

生命周期与开发模型¶

--- markmap: height: 760 initialExpandLevel: 2 autoFit: true colorFreezeLevel: 2 maxWidth: 280 spacingHorizontal: 80 spacingVertical: 12 nodeMinHeight: 24 paddingX: 10 --- # 生命周期与开发模型 ## 生命周期 - 可行性分析 - 评估技术、经济、运行与约束条件 - 需求分析 - 确定系统应提供的能力与验收依据 - 概要设计与详细设计 - 从系统架构细化到接口、数据结构和算法 - 编码、测试与交付 - 实现设计，检查质量，部署可用版本 - 运行、维护与退役 - 修复缺陷、适应环境、持续演化 - 阶段可迭代、交叠，具体安排由过程模型决定 ## 开发方法 - 结构化方法 - 自顶向下、逐步分解，以功能和数据流组织分析设计 - 原型法 - 用可交互模型澄清需求、验证方案 - 可用于完整系统，也可用于大型系统的局部 - 面向对象方法 - 以对象职责和协作组织系统，支持封装与复用 ## 顺序与验证 - 瀑布模型 - 阶段顺序推进，阶段成果经过评审 - 适合需求较稳定、交付边界较清晰的场景 - 后期需求变更可能带来较大返工 - V 模型 - 需求与验收、系统设计与系统测试相对应 - 架构设计与集成测试、详细设计与单元测试相对应 - 在开发早期规划对应测试，并开展评审 ## 迭代与增量 - 演化模型 - 通过反馈逐步明确需求并改进产品 - 原型模型 - 抛弃式原型：验证后舍弃，正式系统重新工程化 - 演化式原型：持续改进为最终产品，需控制架构和质量 - 增量模型 - 按优先级分批交付可用功能 - 早期增量通常提供核心能力，各增量保持集成一致性 - 螺旋模型 - 风险驱动，每轮确定目标、分析风险、开发验证、规划下一轮 - 适合风险较高、复杂度较大的系统，风险分析需要投入 - 喷泉模型 - 面向对象活动相互交叠、反复迭代，阶段边界较弱 - 统一过程 UP - 用例驱动、以架构为中心、迭代与增量 - 初始、细化、构造、移交四个阶段 - 需求、设计、实现和测试活动可跨越多个阶段

--- markmap: height: 760 initialExpandLevel: 2 autoFit: true colorFreezeLevel: 2 maxWidth: 280 spacingHorizontal: 80 spacingVertical: 12 nodeMinHeight: 24 paddingX: 10 --- # 敏捷与协作方法 ## 敏捷思想 - 短周期交付可用软件，通过反馈调整优先级 - 重视人员协作、客户参与、技术质量与持续改进 - 保留必要的文档、设计和计划，使其服务于交付 - 小团队便于沟通，大规模采用需要额外协调机制 ## 极限编程 XP - 价值观 - 沟通、简单、反馈、勇气 - 后续版本加入尊重，常概括为五项价值观 - 早期五项原则 - 快速反馈、简单性假设、增量变化、拥抱变化、优质工作 - 经典十二项实践 - 计划游戏、小型发布、系统隐喻、简单设计 - 测试、重构、结对编程、集体代码所有权 - 持续集成、每周 40 小时、现场客户、编码标准 - 工时实践强调可持续节奏，实践集合随版本演化 ## Scrum - Sprint 是固定时长的冲刺，长度不超过一个月 - 产品负责人、Scrum Master、开发者共同组成 Scrum 团队 - 产品待办列表、Sprint 待办列表、增量 - Sprint 计划、每日 Scrum、评审与回顾 - 通过透明、检视和适应调整工作 ## 水晶方法 Crystal - 以人为中心，根据团队规模和系统关键性调整过程 - 强调沟通、频繁交付与反思改进 ## 特性驱动开发 FDD - 建立总体模型和特性列表 - 按特性计划、设计和构建 - 常设置首席程序员、类所有者与临时特性团队 ## 自适应软件开发 ASD - 推测、协作、学习形成反复循环 - 在不确定条件下通过反馈调整方向 ## 开源协作 - 常见分布式开发、公开评审与共同维护 - 开源是协作与许可方式，本身不等同于敏捷过程

--- markmap: height: 760 initialExpandLevel: 2 autoFit: true colorFreezeLevel: 2 maxWidth: 280 spacingHorizontal: 80 spacingVertical: 12 nodeMinHeight: 24 paddingX: 10 --- # 过程改进与软件文档 ## SW-CMM 成熟度等级 - 1 初始级：过程不稳定，结果较依赖个人经验 - 2 可重复级：建立基本项目管理，跟踪成本、进度和功能 - 3 已定义级：组织过程文档化、标准化，项目按需裁剪 - 4 已管理级：定量度量和控制过程及产品质量 - 5 优化级：利用反馈、缺陷预防和技术改进持续优化 ## CMMI 的等级口径 - 阶段式成熟度与连续式能力等级含义不同 - 成熟度等级描述组织过程改进的整体阶段 - 能力等级描述特定过程域的能力 - CMMI V1.3 阶段式成熟度 - 1 初始、2 已管理、3 已定义 - 4 定量管理、5 优化 - CMMI V1.2 连续式能力等级 - CL0 未完成：未执行，或未满足过程域目标 - CL1 已执行：完成过程域所需工作 - CL2 已管理：计划、监控并制度化管理 - CL3 已定义：采用经裁剪的组织标准过程 - CL4 定量管理：通过统计与量化手段控制过程 - CL5 优化：持续改进过程性能 - CMMI V1.3 连续式保留 CL0–CL3 - 等级名称与范围必须结合模型版本和表示方式 ## 软件文档 - 开发文档 - 可行性分析、需求规格、设计说明、测试计划与报告 - 产品文档 - 安装、使用、运维和接口说明 - 管理文档 - 项目计划、进展记录、质量报告、变更和配置记录 - 文档随版本维护，保持需求、实现和验证结果可追踪

需求分析与系统设计¶

--- markmap: height: 760 initialExpandLevel: 2 autoFit: true colorFreezeLevel: 2 maxWidth: 280 spacingHorizontal: 80 spacingVertical: 12 nodeMinHeight: 24 paddingX: 10 --- # 需求分析 ## 需求的类别 - 功能需求 - 系统应提供的服务、业务规则和行为 - 性能需求 - 响应时间、吞吐量、容量和资源消耗 - 指标应说明负载、数据规模和运行条件 - 其他质量需求 - 安全性、可靠性、可用性、可维护性等 - 设计与实现约束 - 法规、平台、接口协议、技术选型和兼容性限制 ## 分析与确认 - 获取利益相关者需求，明确系统边界与术语 - 处理冲突、遗漏和歧义，确定优先级 - 形成可验证的需求规格和验收条件 - 建立需求到设计、实现和测试的追踪关系 ## 结构化分析成果 - 分层数据流图 DFD - 外部实体：系统边界外的数据提供者或接收者 - 加工：输入数据到输出数据的转换 - 数据流：数据的传递；数据存储：需要保存的数据 - 顶层图描述边界，逐层细化加工 - 父图与子图的输入输出保持平衡 - 描述数据变换，不表示程序控制顺序或执行时间 - 数据字典 - 统一定义数据项、数据结构、数据流和数据存储 - 记录类型、取值范围、含义和组成关系 - 加工规格说明 - 说明底层加工的规则，可用结构化语言、判定表或判定树 - 补充材料 - 性能、安全、异常处理等难以由数据流图表达的要求 ## 判定表与判定树 - 判定表 - 条件项、条件组合、动作项和动作选择 - 适合检查多条件业务规则的完整性与冲突 - 判定树 - 用分支表达条件判断和对应动作 - 适合展示分层决策，较容易看出判断顺序

--- markmap: height: 760 initialExpandLevel: 2 autoFit: true colorFreezeLevel: 2 maxWidth: 280 spacingHorizontal: 80 spacingVertical: 12 nodeMinHeight: 24 paddingX: 10 --- # 系统设计 ## 从概要到细节 - 概要设计 - 确定架构、子系统、模块分工及主要接口 - 详细设计 - 确定模块内部算法、数据结构、状态和异常处理 - 基本原则 - 抽象、自顶向下、逐步求精 - 信息隐藏、模块独立、高内聚与低耦合 ## 设计任务 - 体系结构设计 - 定义主要部件、职责、连接方式与部署约束 - 数据设计 - 将概念模型落实为逻辑结构和物理存储方案 - 包括数据库表、索引、文件格式和内部数据结构 - E-R 模型可支持数据库设计，不直接决定全部文件系统结构 - 接口设计 - 模块间、外部系统、操作系统和用户交互接口 - 明确输入输出、协议、错误语义与调用约束 - 过程设计 - 用伪代码、流程图等描述算法和处理逻辑 ## 模块结构 - 控制规模与调用深度，使职责和行为可理解 - 扇入：直接调用某模块的模块数量 - 公共模块可能有较大扇入，反映复用机会 - 扇出：某模块直接调用的模块数量 - 过大可能表示职责过重，需要合理分层 - 作用范围尽量限制在控制范围内 - 某判断影响的模块，应处于该判断所属模块的控制结构内 - 单入口、单出口是结构化设计原则 - 具体语言的异常、提前返回等应结合可读性和正确性处理 ## 人机界面 - 用户掌控 - 操作有反馈，可取消或撤销，错误后可恢复 - 减少记忆负担 - 显示可选项与上下文，使用有意义的默认值 - 保持一致 - 术语、布局、控件行为与错误提示遵循统一规则

--- markmap: height: 760 initialExpandLevel: 2 autoFit: true colorFreezeLevel: 2 maxWidth: 280 spacingHorizontal: 80 spacingVertical: 12 nodeMinHeight: 24 paddingX: 10 --- # 模块内聚与耦合 ## 内聚：模块内部的联系 - 功能内聚 - 全部元素协作完成一个明确功能 - 顺序内聚 - 前一处理的输出成为后一处理的输入 - 通信内聚 - 多项处理使用相同输入，或产生相同输出 - 过程内聚 - 多项处理因执行次序而放在一起，不必存在数据传递 - 时间内聚／瞬时内聚 - 多项任务因在同一阶段发生而组合，如初始化 - 逻辑内聚 - 同类操作集中，通过控制参数选择执行其中一种 - 偶然内聚 - 无关或联系很弱的任务被放在同一模块 - 传统分类通常按上述次序由强到弱 ## 耦合：模块之间的依赖 - 非直接耦合 - 模块间无直接联系，通过共同上层模块协作 - 数据耦合 - 通过明确参数传递所需数据 - 标记耦合／印记耦合 - 传递复合数据结构，接收者只使用其中一部分 - 控制耦合 - 传入标志或命令，影响另一模块的内部控制流程 - 外部耦合 - 共同依赖外部规定的格式、协议或设备接口 - 公共耦合 - 多个模块共享全局变量或公共数据区 - 共享单个全局变量也属于公共数据依赖 - 内容耦合 - 直接访问另一模块内部实现或跳入其内部执行 - 设计目标 - 减少隐藏依赖，让数据交换和接口契约明确 - 耦合强弱还受接口规模、变更频率和依赖方向影响

测试、质量与维护¶

--- markmap: height: 760 initialExpandLevel: 2 autoFit: true colorFreezeLevel: 2 maxWidth: 280 spacingHorizontal: 80 spacingVertical: 12 nodeMinHeight: 24 paddingX: 10 --- # 测试方法 ## 测试目标 - 发现缺陷，评估质量与风险，检查需求是否满足 - 测试发现缺陷的存在，不能一般性地证明不存在缺陷 - 静态检查 - 评审需求、设计和代码，不执行被测程序 - 动态测试 - 执行程序，比较实际结果与预期结果 - 调试 - 定位原因、修复缺陷，与测试活动相互配合 ## 黑盒测试 - 从输入输出与规格设计用例，不依赖内部实现 - 等价类划分 - 将输入划分为有效类与无效类，每类选代表值 - 有效用例可覆盖多个有效类 - 无效类通常分别设计用例，避免错误互相掩盖 - 边界值分析 - 检查边界及其相邻值，兼顾输入和输出边界 - 整数闭区间可取最小值前后、最大值前后及边界本身 - 连续数值的相邻值取决于精度与表示方式 - 判定表、状态迁移等方法 - 检查条件组合和状态相关的业务行为 ## 白盒测试 - 语句覆盖 - 每条可执行语句至少执行一次 - 判定覆盖／分支覆盖 - 每个判定的各个结果或分支至少执行一次 - 条件覆盖 - 每个基本布尔条件的真、假值至少出现一次 - 条件覆盖与判定覆盖一般互不蕴含 - 判定／条件覆盖 - 同时满足判定覆盖和条件覆盖 - 条件组合覆盖 - 每个判定中基本条件的可行取值组合都被覆盖 - 短路求值会影响条件是否实际执行 - 路径覆盖 - 执行所有可行路径 - 循环可能产生无限路径，不可行路径也需识别 - 覆盖率限制 - 高覆盖率不代表断言充分、需求完整或软件无缺陷

--- markmap: height: 760 initialExpandLevel: 2 autoFit: true colorFreezeLevel: 2 maxWidth: 280 spacingHorizontal: 80 spacingVertical: 12 nodeMinHeight: 24 paddingX: 10 --- # 测试层次与控制流复杂度 ## 测试层次 - 单元测试 - 检查函数、类或模块的逻辑、接口、边界和异常 - 必要时用桩或替身隔离依赖，用驱动调用被测单元 - 集成测试 - 检查组件之间的接口、数据交换与协作 - 自顶向下常用桩，自底向上常用驱动 - 渐增集成便于定位接口缺陷 - 系统测试 - 在代表性环境中检查完整系统的功能和质量属性 - 包含性能、安全、恢复、兼容性等方面 - 确认与验收 - 确认关注是否满足用户需要和预期用途 - 验收依据约定准则决定是否接受交付 ## 变更后的检查 - 确认修复 - 重现原失败场景，检查缺陷是否已修复 - 回归测试 - 检查变更是否破坏原有功能或引入新的副作用 - 可发生在任何测试层次，并非独立的固定生命周期阶段 ## McCabe 圈复杂度 - 基于程序控制流图衡量结构复杂程度 - 单一连通控制流图 - V(G) = E − N + 2 - E 为控制流边数，N 为节点数 - 通常按单入口、单出口的控制流图建模 - 多个独立控制流分量 - V(G) = E − N + 2P - P 为独立控制流分量数，每个分量按同一规则建模 - 二分支判定的简式 - V(G) = 判定节点数 + 1 - 多路分支、短路表达式需先按控制流展开，不能直接数代码行 - 基本路径测试 - 依据独立路径集合构造用例，并分析路径可行性 - 圈复杂度与独立路径有关，不等于全部路径数量

--- markmap: height: 760 initialExpandLevel: 2 autoFit: true colorFreezeLevel: 2 maxWidth: 280 spacingHorizontal: 80 spacingVertical: 12 nodeMinHeight: 24 paddingX: 10 --- # 软件维护与质量 ## 维护类型 - 改正性维护 - 修复交付后发现的缺陷 - 适应性维护 - 适应操作系统、硬件、协议等环境变化 - 完善性维护 - 扩充能力、改进性能或使用体验 - 预防性维护 - 提前消除潜在问题，降低未来故障与维护成本 - 分类依据是变更目的，同一变更可能兼具多个目的 ## 可维护性 - 可理解：结构清晰，职责、接口和文档一致 - 可分析：能够定位问题并评估变更影响 - 可修改：局部变更不会产生失控的连锁影响 - 可测试：能够构造输入并观察和验证结果 - 维护过程 - 分析影响、实施变更、回归验证、更新配置和文档 ## 经典六特性质量模型 - 功能性 - 适合性、准确性、互操作性与安全性 - 功能符合规定和约束 - 可靠性 - 成熟性、容错性、易恢复性 - 易用性 - 易理解、易学、易操作与吸引性 - 效率 - 时间特性与资源利用 - 维护性 - 易分析性、易改变性、稳定性、易测试性 - 可移植性 - 适应性、易安装性、共存性、易替换性 - 模型版本 - ISO/IEC 9126 属于历史六特性模型 - 后续质量模型调整了分类，指标应使用一致的版本口径 ## 质量保证 - 通过过程规范、评审、审计和度量预防质量问题 - 测试、缺陷分析和过程改进共同提供质量证据 - 为质量目标设定可测量指标，并明确使用情境