软件过程模型

一、软件过程

黑盒过程：

要求开发之前需求被充分理解。

与客户的交互只在开始和最后，类似于产品制造过程。

白盒过程：

通过改进可见性来减少风险。

在开发过程中，通过不断地获得顾客的回馈允许变更，类似于服务过程。

二、典型的软件过程模型

1. 瀑布模型

上一个阶段结束，下一个阶段才能开始。

每个阶段均有里程碑和提交物。

上一阶段的输入是下一阶段的输出。

每个阶段均需进行V&V。

侧重于文档与产出物。

优点：追求效率；缺点：过于理想化。

适用场合：

软件项目较小，各模块间接口定义非常清晰。

需求在项目开始之前已经被全面了解，产品的定义非常稳定。

需求在开发中不太可能发生重大变化。

使用技术非常成熟，团队成员熟悉这些技术。

负责各步骤的子团队不可能做到频繁交流。

外部环境不可控因素很少。

2. 增量过程模型

2.1 增量模型

软件被作为一系列的增量来设计、实现、集成和测试，每一个增量是由多种相互作用的模块所形成的提供功能的代码片段构成。

本质：以迭代的方式运用瀑布模型

–第一个增量往往是核心产品：满足了基本的需求，但是缺少附加的特性；

–客户使用上一个增量的提交物并进行自己评价，制定下一个增量计划，说明需要增加的特性和功能；

–重复上述过程，直到最终产品产生为止。

优点：

–在时间要求较高的情况下交付产品：在各个阶段并不交付一个可运行的完整产品，而是交付满足客户需求的一个子集的可运行产品，对客户起到“镇静剂”的作用；

–人员分配灵活：如果找不到足够的开发人员，可采用增量模型：早期的增量由少量人员实现，如果客户反响较好，则在下一个增量中投入更多的人力；

–逐步增加产品功能可以使用户有较充裕的时间来学习和适应新产品，避免全新软件可能带来的冲击；

–因为具有较高优先权的模块被首先交付，而后面的增量也不断被集成进来，这使得最重要的功能肯定接受了最多的测试，从而使得项目总体性失败的风险比较低。

困难：

–每个附加的增量并入现有的软件时，必须不破坏原来已构造好的东西。

–同时，加入新增量时应简单、方便——该类软件的体系结构应当是开放的；

–仍然无法处理需求发生变更的情况；

–管理人员须有足够的技术能力来协调好各增量之间的关系。

2.2 RAD模型

快速应用开发RAD (Rapid Application Development)

–侧重于短开发周期(一般为60~90天)的增量过程模型，是瀑布模型的高速变体，通过基于构件的构建方法实现快速开发；

–多个团队并行进行开发，但启动时间有先后ÿ