软件开发各典型阶段

软件开发主要有以下几个过程：

阶段	目标	关注点	工作基础	方法	主要任务		执行者	制品
需求工程	建立解决方案	理解现实；制定解决方案	客户、用户、环境等	结构化分析（DFD、ERD等）；面向对象分析（用例图、概念类图、顺序图、状态图等）	需求开发		需求工程师	需求分析模型与需求文档
			需求基线		需求管理		所有开发人员	无
软件设计	建立由抽象软件实体组成的软件结构	整体功能组织与质量特征（各种质量属性）	系统需求	模块结构（UML：包图、构件图、部署图）	软件体系结构		体系结构师	体系结构原型、体系结构模型和文档
		模块内部的结构及质量（易开发、可复用、可维护等）	软件体系结构、软件需求	结构化方法（结构图）；面向对象方法（包图、类图、顺序图等）	软件详细设计		设计师	软件详细设计模型和文档
		人机交互质量（易用性）	软件需求	人机交互设计方法	人机交互设计		人机交互设计师	界面原型
软件构造	构建软件	程序的质量（可读、可靠、性能、可维护等）	软件设计方案	结构化程序设计；面向对象程序设计	编程、集成、测试与调试等		程序员	源代码；可执行程序
软件测试	保障软件产品的质量	质量（程序正确性和对需求的符合度）保障	软件需求、软件设计、程序代码	黑盒、白盒等测试方法	测试执行	单元测试	程序员或测试人员	测试报告；通过测试的软件产品
						集成测试
						系统测试	测试人员
					测试计划
					测试报告
软件交付	将软件交付给用户	交付的有效性	可执行程序	无	安装与部署、用户培训、文档支持		专门人员	用户使用手册；已交付软件产品
软件维护	产品终结前的正常使用	变更时控制效益和质量的综合平衡	已交付软件产品	软件演化方法（重构、逆向工程、再工程）	重复上述各阶段任务		维护人员	维护后的产品

软件生命周期模型

人们将软件从生产到报废的生命周期分割为不同阶段，每个阶段有明确的典型输入/输出、主要活动和执行人，各个阶段形成明确、连续的顺序过程，这些阶段划分就被称为 软件生命周期模型。

典型的软件生命周期：需求工程 - 软件设计 - 软件实现 - 软件测试 - 软件交付 - 软件维护

软件过程模型

软件过程模型在生命周期模型的基础上进一步详细说明各个阶段的任务、活动、对象及其组织、控制过程。

与简略的软件生命周期模型不同，软件过程模型可以被看作是网络化的活动组织，不同的生命周期模型有不同的软件过程模型，阶段划分不相同。同一个生命周期模型也会有多个不同的软件过程模型，虽然阶段划分一样，但是各个阶段的时间安排、先后衔接等执行过程不一样

构建-修复模型

构建-修复模型是最早也是最自然产生的软件开发模型。其实它不能算是一个软件过程模型，因为它对软件开发活动没有任何规划和组织，是完全依靠开发人员个人能力进行软件开发的方式。

缺点

1. 在这种模型中，没有对开发工作进行规范和组织，所以随着软件系统的复杂度提升，开发活动会超出个人的直接控制能力，构建-修复模型就会导致开发活动无法有效进行而失败。
2. 没有分析需求的真实性，给软件开发带来很大的风险
3. 没有考虑软件结构的质量，使得软件结构在不断的修改中变得质量越来越糟，直至无法修改
4. 没有考虑测试和程序的可维护性，也没有任何文档，软件的维护十分困难

适用性

1. 软件规模很小，只需要几百行程序，其开发复杂度是个人能力能够胜任的
2. 软件对质量要求不高，即使出错也无所谓
3. 只关注开发活动，对后期维护的要求不高，甚至不需要进行维护

比如OJ系统上的作业，平时写的一些只要经过了检查就可以删掉的程序等，而不是真正要上线面向用户的系统

瀑布模型

[Royce 1970]通过分析早期的软件开发活动后发现，如果将软件开发活动划分为不同的阶段，并且保障每一个阶段工作的正确性和有效性（尤其是重视分析和设计阶段），那么会取得比构建-修复方式好得多的表现，包括更高的质量、更低的成本和更小的风险。

优点

为软件开发活动定义了清晰的阶段划分（包括输入/输出、主要工作及其关注点），这让开发者能够以关注点分离的方式更好地进行那些复杂度超越个人能力的软件项目中的开发活动。

缺点

1. 对文档的过高期望具有局限性：一方面会耗费很大的工作量和成本，另一方面很难为经常变化的需求建立完备可靠的文档
2. 对开发活动的线性顺序假设具有局限性：要求一个阶段的工作经过验证后才能进入后续阶段是不切实际的。在实际开发中，常常需要进行一定的后续工作才能验证当前的工作是否正确、可靠。
3. 客户、用户参与具有局限性：成功的项目开发需要客户、用户从始至终的参与，而不仅仅是一个阶段
4. 里程碑粒度具有局限性：里程碑粒度过粗，基本丧失了“早发现缺陷早修复”这一思想

适用性

1. 瀑布模型适用于需求非常成熟、稳定，没有不确定的内容，也不会发生辩护；
2. 适用于所需的技术成熟、可靠，没有不正确的技术难点，也没有开发人员不熟悉的技术问题
3. 适用于复杂度适中，不至于产生太大的文档负担和过粗的里程碑

增量迭代模型

• 增量迭代模型需要在项目早期就确定项目的目标和范围，项目需求要比较成熟和稳定
• 少量的不确定性和影响不大的需求变更通过迭代的方式加以解决
• 每个迭代的增量需求相对独立，被开发为产品的独立部分交付给用户
• 第一个迭代完成的往往是产品的核心部门，满足基本的需求
• 需求驱动：增量需求是增量迭代模型进行迭代规划、开发活动组织和控制的主要依据。

优点

1. 迭代式开发更加符合软件开发的实践情况，具有更好的适用性；
2. 并行开发可以帮助缩短软件产品的开发时间
3. 渐近交付可以加强用户反馈，降低开发风险

缺点

1. 由于各个构建是逐渐并入已有的软件体系结构中的，所以加入构建必须不破坏已经构造好的系统部分，这需要软件具备开放式的体系结构
2. 增量交付模型需要一个完备、清晰的项目前景和范围以进行并发开发规划，但是在一些不稳定的领域，不确定性太多或者需求变化非常频繁，很难在项目开始就确定前景和范围。

适用性

因为能够很好的适用于大规模软件系统开发，所以增量迭代模型在实践中有着广泛的应用，尤其是比较成熟和稳定的领域。

演化模型

演化模型与增量迭代模型的异同

1. 相同点：两者都是迭代、并行开发和渐进交付，都适合大规模软件开发
2. 不同点：演化模型能够更好地应对需求变更，更适用于需求变更比较频繁或者不确定性比较多的领域。

演化模型在一个阶段的基础上会收集反馈并作用于下一个阶段，能够比较好的适应需求的变更

优点

1. 使用了迭代式开发，具有更好的适用性，尤其是演化模型中迭代的安排能够适用于哪些需求变更比较频繁或者不确定性比较多的软件系统的开发
2. 并行开发可以帮助缩短软件产品的开发时间
3. 渐进交付可以加强用户反馈，降低开发风险。

缺点

1. 无法在项目早起阶段建立项目范围，所以项目的整体计划、进度调度、尤其是商务协商事宜无法准确把握
2. 后续迭代的开发活动是在前导迭代基础上进行修改和扩展的，这容易让后续迭代忽略分析和设计工作，蜕变为构建-修复方式

适用性

在实践中，不稳定领域的大规模软件系统开发适合使用演化模型进行组织

原型模型

1. 抛弃式原型：它通过模拟“未来”的产品，将“未来”的知识置于“现在”进行推敲，解决不确定性
2. 演化式模型：在迭代中构建，是系统的核心，并不断扩充，最终成为真正的软件产品

螺旋模型

Rational统一过程

敏捷过程

Reference

1. 南京大学软件学院2022春季学期《软件工程与计算二》