软件过程
掌握软件工程过程、四个基本活动；理解瀑布/增量/基于组件等常用过程模型，以及原型、增量交付、螺旋等应对变更的模型。
🎯学习目标
- 掌握软件工程过程与四个基本过程活动；
- 掌握瀑布、增量、基于组件三种常用过程模型；
- 理解应对变更的过程模型：原型开发、增量式交付、螺旋模型；
- 能根据系统特点选择合适的过程模型。
1软件生存周期
软件生存周期是指一个软件从提出开发要求开始直到不再使用（报废）为止的整个时期，包括软件定义、软件开发、软件使用和维护三个时期。
图1 · 软件生存周期：计划/开发/运行三时期及各阶段
各阶段任务与典型文档
| 阶段 | 任务 | 典型文档 |
|---|---|---|
| 问题定义 | 确定要解决的问题是什么 | — |
| 可行性研究 | 技术/经济/法律/社会可行性，制定开发计划 | 项目计划书 |
| 需求分析 | 准确确定"软件系统必须做什么" | 软件需求规格说明书 |
| 概要设计 | 软件结构、接口、数据结构设计，制定集成测试计划 | 概要设计说明书 |
| 详细设计 | 模块算法/数据结构精确描述，制定单元测试计划 | 详细设计说明书 |
| 编码及模块测试 | 编程实现 + 单元测试，验证与详细设计一致 | — |
| 测试 | 集成测试、确认测试、系统测试 | 软件测试计划、测试分析报告 |
| 运行与维护 | 查错、纠错、改进，持久满足用户需要 | 操作手册、安装部署手册 |
⭐ 四类维护改正性（改正使用中发现的错误）、适应性（适应环境变化）、完善性（按用户要求改进扩充）、预防性（为将来维护做准备）。
2软件工程过程
软件过程是软件工程人员为了获得软件产品而在软件工具的支持下实施的一系列软件工程活动。软件工程以关注软件质量为目标，包括过程、方法和工具三个要素。软件过程决定了软件的质量。
💡 过程定义要明确什么① 团队人员的工作和职责；② 所执行的活动及其顺序关系；③ 活动的内容和步骤。好处：提高可见性以降低开发风险，并允许基于用户反馈进行项目变更。
软件过程体系结构
| 类别 | 过程元素 |
|---|---|
| 主要软件过程元素 | 需求分析、概念设计、详细设计、编码与单元测试、软件集成、部署维护 |
| 支持的软件过程元素 | 配置管理、质量保证、文档编制、组间协调、同伴/进度检查 |
过程描述包含的内容
- 产品交付物：软件过程活动的结果，如体系结构设计的产出是体系结构模型；
- 角色：反映人在过程中的职责，如项目经理、配置经理、程序员；
- 前置/后置条件：活动或产品生产前后必须满足的条件，如体系结构设计前需求已被认可（前置），其后 UML 模型需评审（后置）。
3四个基本过程活动
不同企业的过程取决于软件类型、客户需求与人员技能，但基本都包含 4 个最基本的软件工程活动：
📋
① 软件规格说明
需求工程定义软件的功能及对软件运行的约束。即需求工程，目标是产生一致的需求文档。
🏗️
② 软件设计和实现
Design & Impl设计并编程实现，生产符合规格说明的软件：体系结构设计→接口设计→数据库设计→组件设计。
✅
③ 软件有效性验证
V&V检查软件确实是客户所需要的：组件（单元）测试→系统测试→接收测试（用真实数据）。
🔄
④ 软件进化
Evolution随客户和市场需求的变化而修改软件。将开发与维护看成一个连续的进化过程。
① 软件规格说明（需求工程过程）
| 活动 | 产物 | 说明 |
|---|---|---|
| 可行性研究 | 可行性报告 | 从技术和业务角度判断系统是否值得开发 |
| 需求导出和分析 | 系统模型 | 分析现有系统、与用户讨论、任务分析，可能开发原型 |
| 需求描述 | 用户需求和系统需求 | 用户需求是抽象描述，系统需求是详尽描述 |
| 需求有效性验证 | 需求文档 | 检查需求的现实性、一致性和完备性 |
② 软件设计和实现（设计过程通用模型）
- 体系结构设计：识别系统总体结构、基本组件及其关系和分布；
- 接口设计：定义组件间无二义的接口，接口确定后组件可并行开发；
- 数据库设计：设计数据结构及其在数据库中的表示；
- 组件设计：针对每个组件设计其运行方式。
③ 软件有效性验证
- 组件（单元）测试：每个组件单独测试，不受其他组件影响；
- 系统测试：集成组件，关注组件间交互、界面问题与功能/非功能需求；
- 接收测试：用客户真实数据测试，能暴露需求定义的错误和遗漏。
4瀑布模型 ⭐（核心考点）
瀑布模型是最早出现的软件开发过程模型（Royce，1970），源于大型军事系统工程模型，是典型的计划驱动模型，把开发表示为界限分明的若干阶段。
图2 · 瀑布模型：阶段如瀑布逐级下落，文档驱动、阶段分明
瀑布模型的特点
- 计划驱动——开始前须对所有过程活动制定计划和进度；
- 阶段分明——每阶段产出核准文档，上阶段完成下阶段才启动；
- 反复迭代——各活动之间存在交互和反复；
- 适度冻结——需求冻结有助于活动开展；
- 文档为王——文档是阶段成果和交互的唯一凭据。
| 优点 | 缺点 |
|---|---|
| 线性、阶段顺序清晰；文档驱动；每阶段审查保证质量 | 客户难以一次说清需求；文档工作量大；难响应需求变更；早期错误到测试阶段才发现 |
⭐ 适用场合① 嵌入式系统（软件与硬件紧密交互，硬件不灵活）；② 安全攸关系统（规格说明和设计须完整、可分析）；③ 大型软件系统（多企业合作，需完整规格以独立开发子系统）。共同点：需求明确且稳定。
5增量过程模型
增量式开发先开发一个初始实现，交用户使用并听取意见，通过多个版本不断修改，直到产生充分的系统。是敏捷方法的基本部分。
图3 · 增量过程模型：核心功能优先，逐个增量逼近完整系统
特点
- 规格说明、开发和验证活动交织而非分离；
- 逐步逼近解决方案，发现错误时回溯更方便快捷；
- 每个增量包含按重要性排序的一部分功能；
- 需要开放的体系结构，不适合大型、长生命周期、多团队联合开发的系统。
| 优点 | 缺点 |
|---|---|
| 降低适应需求变更的成本；更易获得用户反馈；更快交付有用软件，更早创造商业价值 | 过程不可见（频繁文档不划算）；随增量添加系统结构逐渐退化，后期变更越来越困难、成本上升 |
💡 术语不交付给客户的增量称为"构造（Build）"；需要交付的增量称为"发布版本（Released version）"。
6基于组件的开发（面向复用的软件工程）
类比汽车工业"在已有部件基础上组装生产"，将组装式生产模式引入软件开发。基于组件的软件工程（CBSE）强调使用可复用软件组件来设计和构造系统，依赖可复用构件库 + 集成框架。
图4 · 基于组件的开发过程：需求→组件分析→需求精化→面向复用设计→开发集成→验证
三类开发角色 & 三类可复用组件
| 角色 | 职责 |
|---|---|
| 构件生产者 | 负责构件的生产、描述 |
| 构件库管理者 | 负责构件分类及构件库管理 |
| 构件复用者 | 构件查询、理解、适应性修改、组装及系统演化 |
| 概念 | 说明 | 举例 |
|---|---|---|
| 技术 | 解决某类问题的方法 | JSP、JDBC、XML |
| 构件 | 应用程序里可重用的"零件" | 分页构件、控制器、视图构件 |
| 框架 | 一系列构件按一定结构组合的开发平台 | Struts、Spring、Hibernate、EJB |
| 系统 | 实现完整功能的应用程序 | 物流管理系统、销售系统 |
| 优点 | 缺点 |
|---|---|
| 不再一切从头开发；开发=构件组装；降低成本与风险、加快速度、提高质量 | 对系统进化的控制问题：可复用组件新版本可能不受机构控制；商业构件不能修改可能导致需求妥协 |
7应对变更的过程模型 ⭐
对所有大型项目，变更不可避免。应对变更的过程模型（也称演化过程模型）常见有：原型开发、增量式交付、螺旋模型。
① 原型开发
原型是软件系统的最初版本，用于验证概念、试用设计选项、发现问题。当需求模糊时最适用。过程：建立原型目标 → 定义原型功能 → 开发原型 → 评估原型。
| 作用 | 问题 |
|---|---|
| 启发并验证系统需求；探索解决方案、支持界面设计；发现需求的错误和遗漏 | 难满足非功能需求（性能/安全/可靠性）；无文档不利维护；变更破坏结构；质量标准被放松——多为临时系统、会被废弃 |
② 增量式交付
所开发的某些增量逐步交付给用户并在其操作环境中运行，客户指明服务优先级，最高优先权的服务首先交付。
| 好处 | 缺点 |
|---|---|
| 早期增量是真正系统的一部分，无需重新学习；客户无需等全部完成即获益；变更易嵌入；最重要服务接受最多测试 | 难确定全体增量所需的公用基本设施；替换系统时用户不愿用不完整系统、反馈难；与"完整描述写进合同"的采购模型冲突 |
③ 螺旋模型（Boehm，1988）⭐
风险驱动的过程框架，每个回路代表软件过程的一个阶段，分四个象限：
图5 · 螺旋模型：四象限循环，以风险驱动决定是否进入下一环路
- 目标设置：定义本阶段目标、约束、管理计划，分析风险并规划策略；
- 风险评估和规避：详细分析每个风险并采取措施（如开发原型）；
- 开发和有效性验证：根据主要风险选择开发模型（界面风险→抛弃式原型；安全风险→形式化转换；集成风险→瀑布）；
- 规划：评审决定是否进入下一环路并制定下阶段计划。
⭐ 螺旋模型关键点① 内嵌瀑布过程作为螺旋一周；② 实际只有一个迭代真正开发可交付软件；③ 适合需求不确定、开发风险大的大型复杂系统；④ 扩展了增量模型的管理任务范围（增量假定需求是唯一风险源，螺旋则降低更广泛的风险）。
8过程模型比较与选择
没有放之四海皆准的软件过程，正确的过程取决于客户和管理需求、软件所处环境及软件类型。
| 模型 | 优点 | 缺点 | 适用场合 |
|---|---|---|---|
| 瀑布模型 | 线性、文档驱动、阶段审查保证质量 | 早期错误后期才发现、文档量大、难应对变更 | 需求明确稳定、技术成熟（军工、航天、医疗） |
| 增量模型 | 可见中间产品、降低风险、适应变更、更早入市 | 需开放式体系结构、易退化为边做边改 | 需求可能变化、风险较大、希望尽早入市 |
| 螺旋模型 | 开发与风险管理结合、原型化降险、支持需求动态变化 | 需丰富风险评估经验、迭代过多增加成本 | 需求不明确或可能变化的大型复杂系统 |
| 原型模型 | 明确完善需求、研究方案可行性、降低风险 | 技术工具不一定主流、快速修改易致质量低 | 需求不明确或技术/算法可行性不明 |
| 基于组件开发 | 软件复用、降本降险、加快速度提高质量 | 商业构件不能改，可能导致需求妥协 | 系统间有共性的情况 |
案例选型
| 案例 | 特点 | 选型 |
|---|---|---|
| 医疗设备控制软件 | 需求明确稳定、可靠安全要求极高、需大量文档 | 瀑布模型 |
| 校园一卡通系统 | 功能相对独立、需求会变、需可扩展、风险较低 | 增量模型 |
| 企业 ERP 系统 | 含销售/库存/财务等、企业间有差异、已有组件积累 | 基于组件的开发模型 |
| 连锁店物流管理系统 | 需求不明确无法一次提出、各店需求不同、人员有限 | 增量模型 + 基于组件的开发模型 |
⭐重点例题
例题1：比较瀑布模型与螺旋模型的适用场景
瀑布模型：计划驱动，阶段分明、文档为王
→ 适合「需求明确且稳定」的系统：嵌入式、安全攸关、大型多企业系统
螺旋模型：风险驱动，四象限循环、原型化降险
→ 适合「需求不明确、开发风险大」的大型复杂系统例题2：增量开发与增量式交付有何不同？
答：增量开发是把系统分成若干增量，按重要性排序逐个分析、设计、编码、测试，逐步逼近完整系统，强调的是开发方式；增量式交付在此基础上，把开发好的增量逐步交付到用户的真实操作环境中运行，最高优先级服务先交付，强调的是交付/部署方式。增量式交付的增量是真正系统的一部分，用户无需重新学习。
例题3：为什么原型常被废弃？
答：原型开发为了快速验证概念而放松质量标准、忽略非功能需求（性能/安全/可靠性）、缺乏文档、快速变更破坏系统结构。这样的系统难以长期维护，因此许多原型是临时系统，目标达成后即被废弃，正式系统重新规范开发。
🎯自测（点击展开）
四个基本软件工程活动是什么？
软件规格说明、软件设计和实现、软件有效性验证、软件进化。
瀑布模型的核心特点和适用场合？
计划驱动、阶段分明、文档为王；适合需求明确稳定的嵌入式、安全攸关、大型系统。
螺旋模型的四个象限活动是什么？
目标设置、风险评估与规避、开发与有效性验证、规划下一阶段。
螺旋模型最大的特征（区别于其他模型）是什么？
风险驱动——以风险分析决定是否进入下一环路，扩展了增量模型的管理任务范围。
基于组件开发的三类开发角色？
构件生产者、构件库管理者、构件复用者。
软件有效性验证的三级测试是什么？
组件（单元）测试、系统测试、接收测试（用客户真实数据）。
📝强化题库
选择题点选即时判分；填空题输入后"检查"或"显示答案"。
已答 0/0答对 0正确率 —
已答 0/0答对 0