软件过程-犀牛软件40破解版安装过程

1.瀑布模型

也叫做鲑鱼模型(Salmon model)：向前一阶段回溯

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

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

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

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

侧重于文档与产出物

优点——追求效率

简单、易懂、易用、快速

为项目提供了按阶段划分的检查点，项目管理比较容易

每个阶段必须提供文档，而且要求每个阶段的所有产品必须进行正式、严格的技术审查

缺点——过于理想化

在开发早期，用户难以清楚地确定所有需求，需求的错误很难在开发后期纠正，因此难以快速响应用户需求变更

开发人员与用户之间缺乏有效的沟通，开发人员的工作几乎完全依赖规格说明文档，容易导致不能满足客户需求

客户必须在项目接近尾声的时候才能得到可执行的程序，对系统中存在的重大缺陷，如果在评审之前没有被发现，将可能会造成重大损失

瀑布模型太理想化，太单纯，已不再适合现代的软件开发模式，在大型系统开发中已经很少使用

适用场合：

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

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

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

使用的技术非常成熟，团队成员都很熟悉这些技术

负责各个步骤的子团队分属不同的机构或不同的地理位置，不可能做到频繁的交流

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

2.增量过程模型

在很多情况下，由于初始需求的不明确，开发过程不宜采用瀑布模型

因此，无须等到所有需求都出来才进行开发，只要某个需求的核心部分出来，即可进行开发

另外，可能迫切需要为用户迅速提供一套功能有限的软件产品，然后在后续版本中再细化和扩展功能

在这种情况下，需要选用增量方式的软件过程模型

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

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

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

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

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

举例1：开发一个类似于Word的字处理软件

举例2：开发一个教务管理系统

优点：

困难：

RAD模型

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

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

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

缺点：

3.演化过程模型

软件开发过程面临的客观情况：

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

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

主要包括两种形态：快速原型法，螺旋模型

3.1快速原型法

快速原型法的步骤

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

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

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

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

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

“原型”的类型

快速原型法的优缺点

优点：

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

缺点：

3.2螺旋式过程模型

与增量、RAD等的最大区别在于重视风险评估

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

举例：

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

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

缺陷：

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

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

总结：演化过程模型的缺点

演化过程模型的目的：

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

存在的问题：

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

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

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