软件工程概述
一、软件工程的产生背景
20世纪60年代前，软件生产呈私人化模式，规模小、无规范文档，设计等同于编程。60年代中期后，计算机应用扩大，软件规模和复杂度激增，出现软件危机（1968年NATO会议首次提出），具体表现为：
- 开发进度与成本难以控制；
- 功能与质量不达标，维护困难；
- 缺乏规范文档。
为解决危机，1968-1969年NATO会议提出软件工程概念，将工程化思想引入软件开发。
二、软件工程定义
软件工程尚无统一定义，核心内涵可概括为：将系统化、规范化、可量化的工程方法应用于软件的开发、运行和维护，以经济手段获得可靠、高效的软件。主要定义包括：
- Barry Boehm：强调运用科学技术设计程序及相关文档；
- IEEE：明确工程化方法在软件全生命周期的应用及对这些方法的研究；
- Fritz Bauer：通过工程化原则实现低成本、可靠软件；
- 《计算机科学技术百科全书》：融合计算机科学、数学、工程科学及管理科学的交叉学科。
软件工程过程包含4个核心活动：
- P（Plan）：软件规格说明（定义功能及运行约束）；
- D（Do）：软件开发（实现规格说明）；
- C（Check）：软件确认（验证是否满足用户需求）；
- A（Action）：软件演进（持续改进以适应新需求）。
三、软件过程模型
软件过程模型（生命周期模型）是软件全生命周期（需求分析→设计→开发→维护→淘汰）的规范化工作流程，主流模型包括：
1. 瀑布模型
- 特点：线性串行流程，阶段分明（如需求分析→设计→编码→测试→维护），前一阶段输出为后一阶段输入，每个阶段需通过里程碑审查。
- 优势：利于人员管理和方法工具研究，结构清晰。
- 缺点：
- 需求难以提前确定（用户对系统认知模糊）；
- 串行化导致用户长时间无法看到可运行系统，需求变更成本极高；
- 假设每个阶段一次性完美完成，不符合实际。
2. 原型化模型（快速原型）
- 背景：为弥补瀑布模型缺陷，借鉴工程原型思想，通过快速开发原型明确需求。
- 阶段：
- 原型开发：构建包含关键功能的原型（可通过模拟界面、简化开发或参考同类软件实现）；
- 目标开发：根据用户对原型的反馈修改完善，确认需求后开发实际系统。
- 类型：
- 抛弃型原型：仅用于需求确认，后续废弃并重新开发；
- 演化型原型：持续迭代完善，最终形成产品。
- 注意事项：需用户需求模糊、有开发工具支持，且原型需收敛到目标范围；大型软件若无现成原型基础，适用性有限。
3. 螺旋模型
- 特点：结合生命周期模型与原型模型，以“螺旋迭代”方式推进，每轮迭代包含4个步骤：
- 目标设定（定义阶段目标、约束及管理计划）；
- 风险分析（识别并应对潜在风险）；
- 开发与验证（选择开发模型，构建原型或产品）；
- 评审（决定是否进入下一轮迭代）。
- 优势：支持大型软件开发，强调风险控制，兼容多种开发方法（面向规格、过程、对象）。
- 关键：迭代需收敛到用户可接受范围，否则可能中途失败。
四、敏捷模型
20世纪90年代，因面向对象编程普及和互联网快速发展，传统模型难以适应快速变化的需求。2001年，17位专家签署敏捷宣言，提出敏捷方法。
1. 核心特点
- 适应性而非预设性：拥抱变化，通过反馈机制应对不可预测的需求，而非严格遵循固定计划；
- 面向人而非过程：强调发挥人的创造力，减少繁琐流程，鼓励面对面沟通，赋予开发人员技术决策权。
2. 核心思想
- 适应变化：利用变化完善系统，而非抗拒；
- 以人为本：平衡过程控制，避免过度约束，依赖团队协作；
- 迭代增量开发：以原型为基础，小步迭代，逐步扩充功能，快速交付可用版本。
3. 主要敏捷方法
- 极限编程（XP）：轻量且严谨，基于“交流、朴素、反馈、勇气”价值观，将开发分解为小周期，通过持续反馈调整过程。
- 水晶系列方法：以人为中心，提供多套适配不同项目的流程（如团队规模、复杂度），强调机动性。
- Scrum：侧重项目管理，以“Sprint（短迭代）”为单位，通过产品Backlog（需求列表）和Sprint Backlog（迭代任务）管理开发，每次迭代交付可运行增量。
- 特征驱动开发（FDD）：迭代模型，定义6种角色（如项目经理、架构师），核心过程包括开发对象模型、构建特征列表、计划与开发特征。
软件工程从解决软件危机出发，通过定义规范化过程和模型（瀑布、原型、螺旋）提升开发效率；敏捷模型则进一步适应快速变化的需求，强调灵活性与以人为本，形成了传统计划驱动与现代敏捷驱动并存的多元方法体系。
5.1.4 统一过程模型（RUP）
软件统一过程（Rational Unified Process，RUP）是Rational软件公司提出的软件工程方法，属于重量级过程，为软件开发全流程提供指导方针、模板及事例支持，可理解为“在线指导者”。
1. RUP的生命周期
RUP的生命周期是二维模型，包含9个核心工作流和4个阶段，通过迭代增量方式推进开发。
（1）9个核心工作流
核心工作流（Discipline）是与项目某一方面相关的活动集合，具体包括：
- 业务建模：理解系统所在机构的商业运作，统一认知并评估系统对机构的影响；
- 需求：定义系统功能及用户界面，为客户和开发人员建立共识，作为预算与计划的基础；
- 分析与设计：将需求转化为分析与设计模型；
- 实现：将设计模型转换为可执行系统，包含单元测试和模块集成；
- 测试：验证子系统交互、需求实现，归档缺陷并提出改进建议；
- 部署：打包、分发、安装软件，升级旧系统，提供用户培训与技术支持；
- 配置与变更管理：跟踪并维护开发过程中所有制品的完整性和一致性；
- 项目管理：提供计划、人员分配、执行、监控及风险管理框架；
- 环境：为开发机构提供过程管理和工具支持的开发环境。
（2）4个阶段
RUP将生命周期划分为多个循环（生成产品新版本），每个循环包含4个连续阶段，阶段结束前通过里程碑评估：
- 初始阶段：定义最终产品视图、业务模型，确定系统范围；
- 细化阶段：设计系统体系结构，制订工作计划及资源需求；
- 构造阶段：开发产品，持续演进需求、体系结构和计划，直至产品提交；
- 移交阶段：将产品交付用户使用。
（3）迭代特性
每个阶段包含1个或多个迭代（Iteration），迭代是完整的开发过程：
- 迭代针对不同用例细化实现，非简单重复；
- 项目经理需根据阶段和上次迭代结果，裁剪核心工作流中的行为；
- 若未通过阶段里程碑评估，需决策项目是否继续。
2. RUP中的核心概念
理解以下核心概念是掌握RUP的关键：
- 角色（Role）：“谁来做”，描述个人或小组的行为与职责（如体系结构师、测试员等）；
- 活动（Activity）：“怎么做”，有明确目的的独立工作单元；
- 制品（Artifact）：“做什么”，活动生成、创建或修改的信息（如文档、代码等）；
- 工作流（Workflow）：“何时做”，有意义的连续活动序列，产出有价值的产品，体现角色关系。
此外，RUP 2003还包含工具教程、检查点、模板、报告等辅助概念。
3. RUP的特点
RUP是用例驱动、以体系结构为中心、迭代和增量的开发过程，具体表现为：
（1）用例驱动
需求分析、设计、实现、测试等开发活动均以用例为核心推进。
用例的本质：聚焦 “用户目标” 而非 “功能列表” 用例是从用户视角描述系统功能的需求载体，它定义了
“系统与外部参与者（Actor）如何交互以实现用户的某个目标”，而非简单罗列功能点。例如，“用户登录系统”“管理员导出月度报表”
都是用例，它们关注的是 “用户要通过系统完成什么”，而非 “系统内部有哪些模块”。这种视角确保了开发始终围绕 “用户实际需求” 展开，避免陷入技术细节或无意义的功能堆砌。
（2）以体系结构为中心
开发围绕软件体系结构展开，体系结构设计需考虑：
- 功能性（系统功能）、非功能性（性能、安全性等）、开发相关特征（可修改性、可重用性等）及开发经济学（时间、成本等），需在冲突特征中权衡；
- 采用“4+1”视图模型描述体系结构：用例视图（行为）、逻辑视图（功能）、实现视图（配置）、进程视图（性能）、部署视图（拓扑），满足不同角色（分析员、用户、程序员等）的关注点。
（3）迭代与增量
将项目分为多个迭代，每次迭代实现部分需求，基于已有成果增量扩展，直至完成：
- 优势：早期处理关键风险、指导体系结构设计、适应需求变更、快速产出可运行系统、提升开发效率。
5.1.5 软件能力成熟度模型
软件能力成熟度模型（CMM）及演进后的CMMI（软件能力成熟度模型集成）是指导软件过程改进和能力评估的框架，由美国卡耐基梅隆大学软件工程研究所（SEI）主导开发，通过5个成熟度等级实现过程的循序渐进改进。
1. CMMI概述
CMMI整合了软件过程改进经验，包含18个关键过程域、52个过程目标及3168种关键实践，为软件过程改进提供标准化框架，显著提升了软件生产率和质量。
2. 5个成熟度等级
（1）Level 1 初始级
过程随意且混乱，依赖个人能力与“英雄主义”；能产出可用产品，但常超出计划预算与成本。
（2）Level 2 已管理级
项目级过程被策划、文档化、执行、监督和控制；建立明确目标，可实现成本、进度和质量目标。
（3）Level 3 已定义级
企业定义适合自身的标准流程并制度化；开始积累项目资产，形成组织级知识沉淀。
（4）Level 4 量化管理级
建立产品质量、服务质量及过程性能的定量目标；与Level 3的核心区别是“过程性能可预测”。
（5）Level 5 优化级
通过增量式和创新式改进，持续优化过程性能；基于多项目数据关注组织级整体绩效，达到项目管理的最高境界。