软件工程第二章——软件生命周期（仅记录我所认为重要的知识点）

前言

视频地址：中国大学MOOC搜索软件工程（电子科技大学）
https://www.bilibili.com/video/BV1YZ4y1x7LX?p=1

生命周期组成（顺序）

1. 问题定义
2. 可行性研究
3. 需求分析
4. 总体设计
5. 详细设计
6. 编码
7. 测试
8. 维护

对应文档

1. 项目计划报告
2. 可行性研究报告
3. 需求规格说明书
4. 总体设计说明书
5. 详细设计说明书
6. 源程序
7. 软件测试报告
8. 软件维护说明

软件过程

软件过程是在工作产品构建过程中，所需完成的工作活动、动作和任务的集合。

活动

活动主要实现宽泛的目标，与应用领域、项目大小、结果复杂性或者实施软件工程的重要程度没有直接关系。

动作

动作包含了主要工作产品生产过程中的一系列任务。

任务

任务关注小而明确的目标，能够产生实际产品。

软件过程模型

或称：软件开发模型，软件生存周期模型，软件工程范型
是软件开发全部过程、活动和任务的结构框架。它能直观表达软件开发全过程，明确规定要完成的主要活动、任务和开发策略

CMM能力成熟度模型

瀑布模型

1970年提出，规定了各项软件工程活动，以及它们自上而下，相互衔接的固定次序，如同瀑布流水，逐级下落
是一种线性模型
下层依赖上层
具有阶段间顺序性和依赖性
有推迟实现的观点

是一种使用广泛，以文档为驱动的模型
每个阶段都有与其相关联的里程碑和可交付产品
每个阶段结束前完成文档审查，及早改正错误
在实际应用时应该使用带反馈的瀑布模型
即后一阶段发现前一阶段的错误需要向上反馈修改返回

适用场合：

用于系统需求明确且稳定、技术成熟、工程管理较严格的场合

瀑布模型的缺点

1. 增加工作量
2. 开发风险大
3. 早期错误发现晚
4. 不适应需求变化

V模型（瀑布模型的变种）

原型模型

先部分开发产品，使客户和开发人员能够对计划开发的系统的相关方面进行检查。
目的：

1. 明确并完善需求，如演示原型
2. 研究技术选择方案，如技术验证原型

原型构建 and 系统开发

适用场合

客户定义一个总体目标集，但是他们并不清楚系统的具体输入输出;或开发者不确定算法的效率、软件与操作系统是否兼容以及客户与计算机交互的方式。

优点

1. 减少需求不明确带来的风险

缺点

1. 构造原型采用的技术和工具不一定主流
2. 快速建立起来的系统加上连续的修改可能导致原型质量低下
3. 设计者在质量和原型中进行折中
4. 客户意识不到一些质量问题

增量模型

增量:满足用户需求的一个子集，能够完成一定功能、小而可用的软件
和原型模型不同的是增量模型是开发子集不会抛弃，原型是可抛弃，快速构建的

需要开放式结构
若一开始无法确定系统所用功能可以以一个增量为单位逐个进行：需求分析==》设计==》编码==》测试==》交付
增量模型是一种非整体开发的模型，是一种进化式的开发过程
增量模型从部分需求出发，先建立一个不完整的系统，通过测试运行这个系统取得经验和反馈，进一步使系统扩充和完善
如此反复进行，直至软件人员和用户对所设计的软件系统满意为止
增量模型结合了原型模型的基本要素和迭代的特征，采用了基于时间的线性序列，每个线性序列都会输出该软件的一个“增量

增量方式

适用场合

适用于软件开发中需求可能发生变化、具有较大风险、或者希望尽早进入市场的项目。

优点

1. 无需提供完整的需求
2. 软件能够更早投入市场
3. 开放式体系结构便于维护
4. 项目初期无需投入大量人力
5. 产品逐步交付，能够较好的适应需求变化
6. 能够看到中间产品进行改进，减少返工，风险低

缺点

1. 每个增量提供系统功能，开发者很难根据客户需求给出大小合适的增量
2. 必须具备开放式体系结构
3. 易退化为边做边改的方式，导致软件过程控制失去整体性

螺旋模型

结合了瀑布模型和原型模型的特点
开发过程分成若干次迭代，每次迭代代表开发的一个阶段，对应模型中一条环线
每次迭代分成四个方面的活动，对应笛卡尔坐标的四个象限:

1. 确定本阶段目标，选定实施方案，弄清项目开发的限制条件
2. 评估所选方案，通过构造原型和风险分析识别和消除风险
3. 实施软件开发和验证
4. 评价本阶段的工作成果，提出修正建议，并计划下一阶段工作
   
   

优点

1. 具有可扩展性和可修改性，提升了目标软件的适应能力，支持用户的需求的动态变化
2. 原型可看作需求规格说明，易于用户和开发人员理解方便决策
3. 方便管理人员及时进行决策的调制，减低风险

缺点

1. 若每次迭代的效率不高，迭代次数多吗，将增加成本和推迟交付时间
2. 需要非常有风向评估经验和专业知识的人规划管理，开发团队水平需求高

适用场合

适用于需求不明确或者需求可能发生变化的大型复杂的软件系统。
支持面向过程、面向对象等多种软件开发方法,是一种具有广阔前景的模型

喷泉模型

喷泉模型是一种以用户需求为动力，以对象为驱动的模型，主要用于描述面向对象的软件开发过程

软件开发早期定义对象，整个开发过程充实和扩充对象
各个阶段使用统一的概念和表示方法，生命周期各阶段无缝连接
各个开发步骤多次反复迭代

优点

喷泉模型的各个阶段没有明显的界限，开发人员可以同步进行开发,可以提高软件项目开发效率，节省开发时间,适应于面向对象的软件开发过程。

缺点

由于喷泉模型在各个开发阶段是重叠的，在开发过程中需要大量的开发人员，因此不利于项目的管理。
喷泉模型要求严格管理文档,使得审核的难度加大，尤其是面对可能随时加入的各种信息、需求与资料的情况。

适用场合

面向对象开发

基于构件的开发模型

近年来得到广泛应用，改变大型软件开发方式
考虑的焦点是集成，而非实现

构件

1. 系统中模块化的、可更换的部分
2. 实现特定的功能
3. 对实现进行封装，暴露一组接口

例如:动态链接库(.dll)，浏览器插件

阶段解读

第一阶段：需求分析
第二阶段：构件分析（根据需求搜索构件，如果没有完全匹配的构件，则需要修改构件或者修改需求）
第三阶段：系统设计（考虑重用和集成，如果没有可重用的构件，则设计新软件）
第四阶段：开发集成（将构件集成到系统中，开发新软件）

优点

1. 软件复用思想
2. 降低开发成本和风险，加快开发速度
3. 有较高的软件质量

缺点

1. 模型复杂
2. 商业构件不能修改，易导致需求变更
3. 无法完全控制所开发的系统的演化
4. 项目划分的好坏直接影响项目的结果

适用场合

系统之间有共性的情况

统一过程模型

完整且完美，基于面向对象方法学

从三个视角描述软件开发过程
1.动态视角：随时间变化的各个阶段
2.静态视角：所进行的活动
3.实践视角：可采用的良好实践建议

实践视角的6条最佳实践

1. 迭代式开发：需求变更不可避免每次迭代产生一个可交付版本，用户反馈，减少风险，根据客户的轻重缓急来规划增量，先开发和交付优先级最高的增量
2. 管理需求：采用用例分析来捕获需求，由用例驱动设计和实现，对需求及其变更进行管理
3. 基于构件体系结构：采用基于构件的体系结构，提高软件复用率
4. 可视化建模：使用统一建模语言，(UML)对系统进行可视化建模
5. 验证软件质量：软件质量评估贯穿整个开发过程的所有活动全体成员参与
6. 控制软件变更描述如何控制和跟踪软件的变更

动态视角和静态视角

统一过程的静态结构

统一过程的动态结构

适合场所

面向对象，具有大团队

敏捷开发过程

1. 个体交互（个体和交互胜过过程和工具）
2. 可工作的软件（可工作的软件胜过面面俱到的文档）
3. 客户合作（客户合作胜过合同谈判）
4. 响应变化（响应变化胜过遵循计划）

敏捷软件过程是基本原理和开发准则的结合
强调客户满意度和较早的软件增量交付
小但有激情的团队
非正式的方法
最小的软件工程产品
简化整体开发
开发中强调分析和设计的交付
开发者和客户之间积极持续交流

优点

1. 快速响应变化和不确定性
2. 可持续开发速度
3. 适应商业竞争环境下的有限资源和有限时间

缺点

1. 测试驱动开发可能导致通过测试但非用户期望
2. 重构而不降低质量困难

适用场合

适用于需求模糊且经常改变的场合，商业竞争环境下的项目

选择过程模型

没有最好的软件过程模型只有最适合软件的软件过程模型
可以进行多模型组合

场合建议

1.前期需求明确的情况下，尽量采用瀑布模型
2.用户无系统使用经验，需求分析人员技能不足的情况下，尽量借助原型模型
3.不确定因素很多，很多东西无法提前计划的情况下，尽量采用增量模型或螺旋模型4.需求不稳定的情况下，尽量采用增量模型
5.资金和成本无法一次到位的情况下，可采用增量模型
6.对于完成多个独立功能开发的情况，可在需求分析阶段就进行功能并行，每个功能内部
都尽量遵循瀑布模型
7.全新系统的开发必须在总体设计完成后再开始增量或并行8.编码人员经验较少的情况下，尽量不要采用敏捷或迭代模型
9.增量、迭代和原型可以综合使用，但每一次增量或迭代都必须有明确的交付和出口原则