软件工程 chap-3 软件过程模型

1 过程模型概念

对软件开发过程按过程组织策略抽象出的模型

问题循环解决过程各个阶段
 每一种具体的软件工程过程模型实际上都代表了一种将本质上无序的活动有序化的企图。

 软件开发模型(Software Development Model) 是指软件开发全部过程、活动和任务的结构框架。软件开发包括需求、设计、编码和测试等阶段，有时也包括维护阶段。

 软件开发模型能清晰、直观地表达软件开发全过程，明确规定了要完成的主要活动和任务，用来作为软件项目工作的基础。

$$经典模型：\{\begin{array}{r}线性顺序模型\\ 瀑布模型\\ V模型\\ 国防部模型\\ RAD模型\\ 循环(圆形)模型\end{array}$$
$$演进模型：\{\begin{array}{r}原型模型\\ 边建边改模型\\ 增量模型\\ 螺旋模型\\ 并发模型\\ XP模型\\ RUP模型\end{array}$$
$$其他模型：\{\begin{array}{r}CBDAssembleModel(构件组装模型)\\ 形式化方法模型\\ IDEAL模型\end{array}$$

2 线形顺序模型系列

2.1 线性顺序模型

2.2 边建边改模型

主要问题在于：
　　（1）缺少规划和设计环节，软件的结构随着不断的修改越来越糟，导致无法继续修改；
　　（2）忽略需求环节，给软件开发带来很大的风险；
　　（3）没有考虑测试和程序的可维护性，也没有任何文档，软件的维护十分困难。

2.3 瀑布模型

最早出现的软件开发模型

瀑布模型将软件生命周期划分为制定计划、需求分析、软件设计、程序编写、软件测试和运行维护等六个基本活动，并且规定了它们自上而下、相互衔接的固定次序，如同瀑布流水，逐级下落。

瀑布模型上一阶段的变换结果是下一阶段变换的输入，相邻两个阶段具有因果关系，紧密联系。


特点：

1. 阶段间具有顺序性和依赖性
2. 推迟实现的观点
   清楚地区分逻辑设计与物理设计，尽可能推迟程序的物理实现
3. 质量保证的观点
   （1） 每个阶段都必须完成规定的文档，没有交出合格的文档就是没有完成该阶段的任务。
   （2） 每个阶段结束前都要对所完成的文档进行评审，以便尽早发现问题，改正错误。

其主要问题在于：
　　（1） 各个阶段的划分完全固定，阶段之间产生大量的文档，极大地增加了工作量；
　　（2） 由于开发模型是线性的，用户只有等到整个过程的末期才能见到开发成果，从而增加了开发的风险；
　　（3） 早期的错误可能要等到开发后期的测试阶段才能发现，进而带来严重的后果。

2.4 RAD(快速应用开发)模型

主要用于信息应用软件的开发

节省时间

通过使用基于构件的建造方法达到快速开发的效果。在需求得到很好理解、项目的范围约束明晰的前提下(通常不容易保证这样的条件)，采用RAD过程能够使项目组在很短的时间内(如60～90)天创建出功能完善的系统。

业务建模： 说明什么信息驱动业务流程、生成什么信息、谁负责生成该信息、该信息流向何处、谁处理它等。
数据建模： 标识出每个数据对象的特征属性，定义这些对象之间的关系。
处理建模： 创建处理描述以便增加、修改、删除或获取某个数据对象。
应用生成： 均使用自动化工具辅助软件建造。
测试及反复： RAD过程强调复用，许多构件是已经测试过的，减少了测试工作量。但是所有的新创建构件、所有的接口都必须测试到。

不适用于：
技术风险很高的、要采用很多新技术的项目
难以被适当模块化的系统
具有高性能需求的软件，这种高性能必须通过对接口的反复调整才能实现

2.5 国防部(DoD)模型

描述了与硬件相关联的活动，而这些活动又与跟软件相关联的活动相互独立。在项目进入最后的系统集成过程以前，这两个关键的路径能够且应该分开管理，这种错误结论导致了许多项目的失败。

2.6 V模型

测试驱动的模型

非常明确地标明了测试过程中存在的不同级别，并且清楚地描述了这些测试阶段和开发过程期间各阶段的对应关系。
需求分析确定验收测试标准
系统设计确定系统测试标准
程序设计确定集成测试标准

单元测试是基于代码的测试
集成测试验证了2个或多个单元之间的集成是否正确
系统测试以客户环境模拟系统的运行，以验证系统是否达到了在概要设计中所定义的功能和性能
验收测试由业务专家或用户进行，以确保产品能真正符合用户业务上的需要

该方法从项目开展到项目终结,无时无刻不强调质量控制

阶段围墙(stage containment)

3 演进模型系统

主要针对事先不能完整定义需求的软件开发

要求开发人员有能力把项目的产品需求分解为不同组
“分期完成、分步提交”

3.1 原型模型

主要是研发全新的产品时最实用

(演化模型)主要是针对事先不能完整定义需求的软件项目开发而言的。通常我们把第一次实验性开发出的软件称为原型(prototype)。这种开发模型可以减少由于需求不明给开发工作带来的风险，有较好的效果。

丢弃型： 原型开发后，已获得了更为清晰的需求反馈信息，原型无需保留而丢弃
样品型： 原型规模与最终产品相似，只是原型仅供研究用
渐增式演化型： 原型作为最终产品的一部分，它可以满足用户的部分需求

快速原型模型

所有的过程是采用迭代方式来开发的，因此需求的完整性会很强，而且也适合用户的习惯

3.2 增量模型

面向对象的项目开发

整个产品被分解成若干个构件，开发人员逐个构件地交付产品，这样做的好处是软件开发可以较好地适应变化，客户可以不断地看到所开发的软件，从而降低开发风险。

第一个增量构件往往实现软件的基本需求，提供最核心的功能。
第二个增量构件提供更完善的编辑和文档生成功能；
第三个增量构件实现拼写和语法检查功能；
第四个增量构件完成高级的页面排版功能。

分解时惟一必须遵守的约束条件是，当把新构件集成到现有软件中时，所形成的产品必须是可测试的。

优点：
能在较短时间内向用户提交可完成部分工作的产品
逐步增加产品功能可以使用户有较充裕的时间学习和适应新产品

增量模型融合了线性顺序模型的基本成分(重复的应用这些成分)和原型模型的迭代特征

缺陷：
　　（1） 由于各个构件是逐渐并入已有的软件体系结构中的，所以加入构件必须不破坏已构造好的系统部分，这需要软件具备开放式的体系结构。
　　（2） 在开发过程中，需求的变化是不可避免的。增量模型的灵活性可以使其适应这种变化的能力大大优于瀑布模型和快速原型模型，但也很容易退化为边做边改模型，从而使软件过程的控制失去整体性。

3.3 螺旋模型

该模型是由TRW公司的B.Boehm于1988年提出

能够在关键点上控制风险，适合大项目的开发

将瀑布模型和快速原型模型结合起来，强调了其他模型所忽视的风险分析，特别适合于大型复杂的系统

需要具有相当丰富的风险评估经验和专门知识

有助于将软件质量作为特殊目标融入产品开发之中


螺旋模型沿着螺线进行若干次迭代，图中的四个象限代表了以下活动：
　　（1） 制定计划：确定软件目标，选定实施方案，弄清项目开发的限制条件；
　　（2） 风险分析：分析评估所选方案，考虑如何识别和消除风险；
　　（3） 实施工程：实施软件开发和验证；
　　（4） 客户评估：评价开发工作，提出修正建议，制定下一步计划。

理解这种模型的一个简便方法，是把它看作在每个阶段之前都增加了风险分析过程的快速原型模型(如上图)

在早期的迭代中，发布的增量可以是一个纸上的模型或原型

优点：

1. 风险驱动
2. 对可选方案和约束条件的强调有利于已有软件的重用
3. 有助于把软件质量作为软件开发的一个重要目标
4. 减少了过多测试（浪费资金）或测试不足（产品故障多）所带来的风险
5. 在螺旋模型中维护只是模型的另一个周期，在维护和开发之间并没有本质区别。

缺点：用户可信度比较低，因为它比较新的模型，而且评估风险的技术要求比较高。

软件工程项目组按照顺时针方向沿螺旋移动。从核心开始，第一圈可能产生软件规格说明书，第二圈可能开发出一个原型，随后可能是软件更完善的版本。经过计划区域的每一圈都会对计划进行调整，基于从用户处得到的反馈，调整进度和费用以及版本的内容。

能够适应于计算机软件产品的整个生命周期。它使开发者在产品演化的任何阶段上都能够使用原型方法，保持了传统生命周期模型中的阶段化的工作方式，但同时又引入了迭代的框架，更加真实地反映了现实世界。同时也有利于防范技术风险。

各种模型的比较

4 其他模型系统

4.1 构件组装模型

特点：采用类的复用来实现软件开发。
优点：能够复用原来的构件。
实用环境:组件式的开发

4.2 形式化方法模型

采用数学的方法用自动化的控制软件开发每一个过程，净室软件工程就是它的变种

<1>特点：采用数学的方法控制，有一系列的自动化工具检测
<2>优点：软件开发出来准确
<3>缺点：成本很高，对技术人员的要求也特别高
<4>实用环境:软件质量要求特别高，精度要求特别高的项目。

4.3 IDEAL模型

5 补充模型

5.1 喷泉模型

（fountain model, (面向对象的生存期模型, OO模型)）

喷泉模型与传统的结构化生存期比较，具有更多的增量和迭代性质，生存期的各个阶段可以相互重叠和多次反复，而且在项目的整个生存期中还可以嵌入子生存期。就像水喷上去又可以落下来，可以落在中间，也可以落在最底部。

5.2 智能模型(四代技术(4GL))

四代语言(4GL): 是一种声明式、交互式和非过程性编程语言。用户界面极端友好

目前主要限于事务信息系统的中、小型应用程序的开发

5.3 混合模型（hybrid model）

过程开发模型，元模型（meta-model）

允许一个项目能沿着最有效的路径发展

实际上，一些软件开发单位都是使用几种不同的开发方法组成他们自己的混合模型

5.4 循环模型

问题主要有两个方面：
1．将连续存在的活动错误地认为是按照顺序排列的活动
2．某些活动放置的位置不合理

5.5 并发开发模型

试图根据传统生命周期的主要阶段来追踪项目的状态的项目管理者是根本不可能了解其项目的状态的。

同时可能有一些项目组人员在参与涉及开发的多个阶段的活动

一个并发过程模型是由用户要求、管理决策和结果复审驱动的

所有活动并发存在，但处于不同的状态

 并发过程模型可用于所有类型的软件开发，并能够提供关于一个项目的当前状态的准确视图。该模型不是将软件工程活动限定为一个顺序的事件序列，而是定义了一个活动网络。网络上的每一个活动均可与其他活动同时发生。在一个给定的活动中或活动网络中其他活动中产生的事件将触发一个活动中的状态的转移。

5.6 形式化方法模型

这种方法的一个变种，称为净室软件工程［MIL87，DYE92］

提供了一种机制，能够消除使用其他软件工程范型难以克服的问题。二义性、不完整性和不一致性能被更容易地发现和纠正-----不是通过专门的复审，而是通过数学分析。

它在商业环境中的可用性还需要考虑：

1. 形式化模型的开发目前还很费时和昂贵。
2. 因为很少有软件开发者具有使用形式化方法所需的背景知识，所以尚需多方面的进行培训。
3. 难以使用该模型作为与对其一无所知的用户进行通信的机制。