软件工程与计算（二十二）软件开发过程模型

（自顶向下，逐层细化）

一.软件开发的典型阶段

1.需求工程

2.软件设计

3.软件构造

4.软件测试

5.软件交付

6.软件维护

二.软件生命周期模型

三.软件过程模型

四.构建-修复模型

五.瀑布模型

六.增量迭代模型

七.演化模型

八.原型模型

九.螺旋模型

十.Rational统一过程

十一.敏捷过程

一.软件开发的典型阶段

1.需求工程

目标：建立能够妥善解决用户问题的软件系统解决方案，简单地说就是定义“软件系统要完成哪些功能”

任务：需求开发（包括需求获取、分析、规格说明、验证）和需求管理（持续进行，直到软件生命周期终结）

软件开发人员：软件需求工程师and软件需求分析师

需求开发的两个阶段：

系统需求开发：为了获得整个系统的期望目标（即完成业务需求处理），包括软件系统和硬件系统（软件系统通常会承担主要的需求）
软件需求开发：以承载的系统需求为出发点，建立软件系统解决方案，使其满足系统需求

常见建模方法与技术：结构化分析方法（DFD和ER图），面向对象分析方法（用例图描述系统功能，概念类图描述系统静态结构，顺序图）

关注点：首要是理解现实，次要是建立高质量的软件系统~

主要制品：需求分析模型and软件需求规格说明文档~

2.软件设计

目标：使用各种抽象软件实体建立系统的结构，搭建系统的实现框架

开发人员：软件设计师

划分为以下3个类：

体系结构设计：系统的高层设计，将软件系统划分为不同的子系统和模块
软件详细设计：在高层设计的基础上，使用模块、过程、类等软件抽象实体完成各个子系统内部的细粒度设计
人机交互设计：建立用户之间的交互机制，使得系统具有量化的易用性

（前两者均存在面向对象方法和结构化方法两种实现途径）

3.软件构造

目标：构建软件

开发人员：程序员——编程实现和构造高质量软件产品

主要任务：编程、测试与调试等子活动

主要制品：源代码和可执行程序

4.软件测试

目标：保证软件产品的质量

主要划分为3个层次：

单元测试：验证一个系统构造单元内部的实现质量
集成测试：验证系统各个构建单元和部件按照要求进行集成的质量
系统测试：验证系统产品符合用户级客户要求的质量

主要任务：测试计划、测试执行和测试报告

主要制品：测试用过的高质量软件产品和测试报告

5.软件交付

目标：将软件产品交付给用户和客户

主要任务：部署、用户培训、文档支持等

关注：交付的有效性，让客户和用户真正掌握软件产品，能够顺利地使用软件产品完成工作任务

重视点：项目总结和项目评价

6.软件维护

目标：保障用户从接收产品到软件生命终结之间的正常使用

任务：完善性维护、适应性维护、修正性维护and预防性维护

（可由开发人员进行，也可以由专门的维护人员进行）

关注点：软件系统如何在效益和质量的总和平衡下演化

分享一张详细归纳的好图：

二.软件生命周期模型

每个阶段都有明确的典型输入/输出、主要活动和执行人、各个阶段形成明确、连续的顺序过程

（特定软件系统的生命周期简要描述了该系统的开发活动历史，而一个软件生命周期模型则描述了新的软件系统该如何开发）

三.软件过程模型

与简略的软件生命周期模型不同，软件过程模型进一步详细说明各个阶段的任务、活动、对象及其组织、控制过程，可以被看做是网络化的活动组织

因为要在整体上遵守软件生命周期的约束，所以不同的软件生命周期模型展开以后是不同的软件过程模型~

四.构建-修复模型

1.背景与动机：最早也是最自然产生软件的开发模型，完全依靠开发人员的个人能力进行开发

2.描述：依靠个人分享和理解直接构造软件的第一个版本，提交给用户使用；发现缺陷后就直接修改代码修改缺陷，直到全部完成后进行交付，然后进入维护阶段

3.特点

没有对开发工作进行规范和组织，随着难度提升开发活动会超出个人的控制模型
没有分析需求的真实性，给软件开发带来很大危险
没有考虑软件结构的质量
没有考虑测试和程序的可维护性，且没有任何文档——维护工作十分困难

4.常用情况

软件规模很小（几百行程序）
对软件质量要求不高
只关注开发活动，对后期维护的要求不高，甚至不需要进行维护

五.瀑布模型

1.背景与动机：将软件开发活动划分为不同的阶段，并且保证每一个阶段工作的正确性和有效性~

2.描述:自上而下，相互衔接，从一个阶段到另一个阶段的有序的转换序列~

虽然像瀑布流水逐级而下，瀑布模型允许活动出现反复和迭代~

3.特点

明显优势：为开发活动定义了清晰的阶段划分，这让开发者能够以关注点分离的方式更好地进行那些复杂的软件项目的开发活动~

局限性：

对文档的过高期望
对开发活动的线性顺序假设
客户、用户参与不够
里程碑粒度过粗

4.常用情况

需求非常成熟稳定，没有不确定的内容
所需的技术成熟
复杂度适中

六.增量迭代模型

1.背景与动机：实际开发中绝大多数复杂系统都是需要迭代完成的~

2.描述：在项目开始时，通过系统需求开发和核心体系结构设计活动完成项目队前景和范围的界定，然后再将后续开发活动组织为多个迭代、并行的瀑布式开发活动~

比较显著的要求是，需要在项目早期就确定项目的目标和范围，因此项目需求要比较稳定和成熟~

3.特点：

优点：

更加符合软件开发的实践情况，具有更好地适用性~
并行开发可以帮助缩短软件产品的开发时间~
加强用户反馈，降低开发风险~

缺点：

需要软件有开放式的体系结构，以便于不断加入构件
很难再项目开始就确定前景和范围

4.常用情况：实践中广泛应用

七.演化模型

1.背景与动机

和增量相同，都采用迭代式；不同点在于演化模型主要用在需求变更频繁或者不确定性较多的领域

2.描述

将软件开发活动组织为多个迭代、并行的瀑布式开发活动——主要任务是澄清和明确系统的核心需求，建立和交付核心系统~

对需求的反馈是演化模型进行迭代预测、开发活动组织和控制的主要依据，因此它也是“需求驱动”

3.特点

优点：

具有更好地适用性，尤其是其演化式迭代安排能够适用于需要频繁变更需求的软件系统~
并行开发可以缩短软件产品的开发时间~
渐进交付可以加强用户反馈，降低开发风险~

缺点：

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

4.常用情况

不稳定领域的大规模软件系统

八.原型模型

1.背景与动机

简单的说，原型产生于真正产品构建之前，一种情况是，它被扩展之后成为真正的产品，另一种情况是，它模拟真正产品但不会出现在真正产品之中，而在真正产品中出现的是比原型质量更好地改进和替代~（第一种称为演化式原型，第二种称为抛弃式原型）

（基本特征不是注重演化式而是注重抛弃式原型）

2.描述

将需求开发活动展开为抛弃式原型开发的迭代，充分利用抛弃式原型解决新颖领域的需求不确定问题~

3.特点

优点：

对原型方法的使用加强了与客户、用户的交流，可以让最终产品取得更好地满意度
适用于存在大量不确定性的领域

缺点：

原型方法能够解决风险，但是自身也能带来新的风险，例如原型方法成本太高
实践中，很多项目负责人不舍得抛弃“抛弃式原型”，导致降低产品质量

4.常用情况：存在这大量不确定性的新颖领域进行开发活动组织

九.螺旋模型

1.背景与动机

解决软件开发的越来越高的风险~

基本思想：尽早解决比较高的风险（尽量早发现）

2.描述

基于风险驱动，完全按照风险解决的方式组织软件开发活动~

风险解决的基本思路是：

确定目标、解决方案和约束——评估方案，发现风险——寻找解决风险方法——解决风险方案~

3.特点：

优点：可以降低风险，减少项目因风险造成的损失

缺点：

风险解决需要使用原型手段，也就会存在原型带来的风险（与原型相同）
模型过于复杂，不利于管理者依据其组织软件开发活动

4.常用情况

在高风险的大规模软件系统开发中有着较多的应用

十.Rational统一过程

1.背景与动机

多种过程模型方法互不相容，各有自己的优点和最佳实践方法，又都有自己的局限性；为了减少过程模型方法上选择的困难，同时由充分吸收和利用各种过程模型方法下的最佳实践方法，Rational公司提出了统一过程（RUP）——总结和借鉴传统的各种有效经验，建立最佳实践方法的集合，并提供有效的过程定制手段~

2.描述

模型概述：横轴以时间来组织，是过程展开的生命周期特征，体现开发过程的动态结构；纵轴以内容来组织，是自然的逻辑活动，体现开发过程的静态结构

核心实践方法：

迭代式开发：过去被反复证明的最佳实践方法
管理需求：重视需求工程中除了需求开发之外的需求管理活动
使用基于组件的体系结构：它帮助建立一个可维护、易开发、易复用的软件体系结构
可视化建模：利用UMl进行建模
验证软件质量：尽早和持续地开发验证，以尽早发现缺陷，降低风险和成本
控制软件变更：适应90年代以后需求变更越来越重要的事实

3.特点

优点：