软件过程模型

一、软件过程

黑盒过程：

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

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

白盒过程：

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

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

二、典型的软件过程模型

1. 瀑布模型

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

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

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

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

侧重于文档与产出物。

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

适用场合：

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

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

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

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

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

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

2. 增量过程模型

2.1 增量模型

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

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

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

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

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

优点：

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

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

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

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

困难：

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

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

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

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

2.2 RAD模型

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

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

–多个团队并行进行开发，但启动时间有先后，先启动团队的提交物将作为后启动团队的输入；

缺点：

–需要大量的人力资源来创建多个相对独立的RAD团队；

–如果没有在短时间内为急速完成整个系统做好准备，RAD项目将会失败；

–如果系统不能被合理的模块化，RAD将会带来很多问题；

–技术风险很高的情况下(采用很多新技术、软件需与其他已有软件建立集成、等等)，不宜采用RAD。

3. 演化过程模型

软件系统会随着时间的推移而发生变化，在开发过程中，需求经常发生变化，直接导致产品难以实现；

严格的交付时间使得开发团队不可能圆满完成软件产品，但是必须交付功能有限的版本以应对竞争或压力；

很好的理解和核心产品与系统需求，但对其他扩展的细节问题却没有定义。

在上述情况下，需要一种专门应对不断演变的软件过程模型，即“演化过程模型”。

本质：循环、反复、不断调整当前系统以适应需求变化；

包括两种形态：

–快速原型法

–螺旋模型

3.1 快速原型法

Step 1：双方通过沟通，明确已知的需求，并大致勾画出以后再进一步定义的东西。

Step 2：迅速策划一个原型开发迭代并进行建模，主要集中于那些最终用户所能够看到的方面，如人机接口布局或者输出显示格式等；

Step 3：快速设计产生原型，对原型进行部署，由客户和用户进行评价；

Step 4：根据反馈，进一步细化需求并调整原型；

Step 5：原型系统不断调整以逼近用户需求。

原型的类型：

Throwaway prototyping(抛弃式原型)

–最初的原型在完成并得到用户认可之后，将不会作为交付给用户的最终系统的一部分，而是被抛弃，其目的只是为了收集与验证需求；

–该类原型可能是不可执行的(例如，只包含用户界面)；

Evolutionary prototyping(演化式原型)

–最初构造的原型将具备较高的质量，包含了系统的核心功能，然后通过收集需求对其进行不断的改善和精化；

–该类原型是可执行的，将成为最终系统的一部分；

优点：

–提高和改善客户/用户的参与程度，最大程度的响应用户需求的变化；

缺点：

–为了尽快完成原型，开发者没有考虑整体软件的质量和长期的可维护性，系统结构通常较差；

–可能混淆原型系统与最终系统，原型系统在完全满足用户需求之后可能会被直接交付给客户使用；

–额外的开发费用。

 3.2 螺旋式过程模型

螺旋模型沿着螺线旋转，在四个象限内表达四个方面的活动：

–制定计划：确定软件目标，选定实施方案，弄清项目开发的限制；

–风险分析：分析所选方案，考虑如何识别和消除风险；

–实施工程：实施软件开发；

–客户评估：评价开发工作，提出修正建议。

举例：

–第1圈：开发出产品的规格说明；

–第2圈：开发产品的原型系统；

–第3~n圈：不断的迭代，开发不同的软件版本；

–根据每圈交付后用户的反馈来调整预算、进度、需要迭代的次数；

出发点：开发过程中及时识别和分析风险，并采取适当措施以消除或减少风险来的危害。

优点：结合了原型的迭代性质与瀑布模型的系统性和可控性，是一种风险驱动型的过程模型：

–采用循环的方式逐步加深系统定义和实现的深度，同时更好的理解、应对和降低风险；

–确定一系列里程碑，确保各方都得到可行的系统解决方案；

–始终保持可操作性，直到软件生命周期的结束；

–由风险驱动，支持现有软件的复用。

缺陷：

–适用于大规模软件项目，特别是内部项目，周期长、成本高；

–软件开发人员应该擅长寻找可能的风险，准确的分析风险，否则将会带来更大的风险。

演化过程模型的目的：

–需求的变更频繁，要求在非常短的期限内实现，以充分满足客户/用户要求、及时投入市场；

存在的问题：

–由于构建产品所需的周期数据不确定，给项目管理带来困难；

–演化速度太快，项目陷入混乱；演化速度太慢，影响生产率；

–为追求软件的高质量而牺牲了开发速度、灵活性和可扩展性；

4. 形式化过程模型

使用严格的数学形式来刻画每一阶段的产物(需求、设计、程序、测试)；

应用一系列形式化方法在各阶段的产物之间进行自动/半自动的转换。

优点：

–应用数学分析方法，歧义性、不完整性、不一致性等问题更容易被发现和改正，目的是“提供无缺陷的软件”。

缺陷：

–形式化数学方法难以理解，可视性太差，对开发人员技能要求较高；

–构造形式化模型是一件非常耗时的工作，成本也很高；

–软件系统中的某些方面难以用形式化模型表达出来(如用户界面)；

应用场合：

–对可靠性和安全性要求较高的一些关键系统，在真正被投入使用之前，需要严格保证100%的正确。传统的方法靠人去验证，难以奏效。

——太过于理想化，因此仅停留在理论研究中，实践中很少使用。

5. 面向复用的软件过程

该过程模型的主要思想是复用(reuse)；

针对一个新的软件系统，不是完全从一无所有开始入手，而是通过使用已有的软件单元(称为“软构件”)来构造系统；

主要过程：

–需求分析；

–体系结构设计；

–构件获取(购买、重新开发)；

–构件修改与测试；

–构件组装；

–集成测试；