信息技术 软件产品通用要求（二）

safety

A.2  原型 瀑布模型
A.2.1  模型描述
原型模型本身是一个迭代的模型，是为了解决在产品开发的早期阶段存在的不确定性、歧义性和不完整性等问题，通过建立原型使开发者进一步确定其应开发的产品，使开发者的想象更具体化，也更易于被客户所理解。原型只是真实系统的一部分或一个模型，完全可能不完成任何有用的事情，通常包括抛弃型和进化型两种，抛弃型指原型建立、分析之后要扔掉，整个系统重新分析和设计；进化型则是对需求的定义较清楚的情形，原型建立之后要保留，作为系统逐渐增加的基础，采用进化型一定要重视软件设计的系统性和完整性，并且在质量要求方面没有捷径，因此，对于描述相同的功能，建立进化型原型比建立抛弃型原型所花的时间要多。原型建立并确认需求之后采用瀑布模型的方式完成项目开发。原型 瀑布模型的开发流程如图2所示：
图2  原型 瀑布模型
A.2.2  时机
如下情形可考虑选择原型 瀑布模型
a.       项目包含一种新技术，例：新硬件、新的开发语言、新的系统体系结构等；
b.       需求不很清楚；
c.       存在关于性能、可靠性和可行性方面的主要的、未解决的问题；
d.       用户界面对系统成功是很关键的，但不很清楚。
A.2.3  缺点
由于原型并非最终产品，如果原型不能利用，可能导致成本的增加，同时会引起客户的误解，以为产品即将完成。
A.3  增量模型
A.3.1  模型描述
增量模型如图3所示，也叫作有计划的产品改进型，它从一组给定的需求开始，通过构造一系列的可执行工作版本来实施开发活动。第一个工作版本纳入一部分需求，下一个工作版本纳入更多的需求，以此类推，直到系统完成。每个工作版本都要执行必要的过程、活动和任务，如：需求分析和体系结构设计需要执行一次，而软件详细设计、软件编码和测试、软件集成和软件合格性测试在每个工作版本构造过程中都执行。
在这种方法中，在开发每个工作版本时，开发过程中的活动和任务顺序地或部分平行地使用。当相继的工作版本在部分并发开发时，开发过程中的活动和任务可以在各工作版本间平行地被采用。
在所有的工作版本中，开发过程的活动和任务通常按相同的顺序被重复使用。维护过程和运作过程可以与开发过程平行地使用。获取过程、供应过程、支持过程和组织过程通常与开发过程平行地进行。

图3  增量模型
A.3.2  时机
如下情形可考虑选择增量模型：
a)       需要早期获得功能；
b)      中间产品可以提供使用；
c)      系统被自然地分割成增量；
d)      工作人员/资金可以逐步增加。
A.3.3  缺点
由于增量模型的灵活性，往往容易退化成边做边改模式，使软件过程的控制丧失了整体性，最终的产品也不是开放的，给维护人员带来极大负担。
A.3.4  风险
在选择该方法时，如下一些相关的风险因素应加以考虑：
a)       需求未被很好地被理解；
b)      一次要求所有功能；
c)      事先打算采用的技术迅速发生变化；
d)      需求迅速发生变化；
e)       长时期内有限的资源的保证（工作人员/资金）。
A.4  增量的迭代模型
A.4.1  模型描述
该模型是一个不断迭代和增量的过程（见图4），迭代过程首先要处理一组客户的业务需求，这些业务需求组合起来能够扩展所开发产品的可用性。其次，迭代过程要解决最突出的风险问题。后续的迭代过程建立在前一次的迭代过程末期所产生的产品之上。一个增量不一定是对原有产品的增加，尤其在生存周期初期，开发人员可能用更加详细和更加完善的设计来代替最初简单的设计。在较后的阶段，增量通常是对原有产品的增加。采用此种模型最好是基于构件和有相应的构件开发工具（如：RUP、配置管理工具等）。

图4  增量的迭代模型

A.4.2  缺点
需要相当的风险评估的技术；每个迭代循环控制不好就会变成边做边改模式。
A.5 快速应用开发模型
A.5.1  模型描述
快速应用开发模型（RAD）是一个线性顺序的软件开发模型，强调极短的开发周期（2-3个月）。该模型是线性顺序模型的一个“高速”变种，如果需求理解得很好，且约束了项目范围，就可通过使用基于构件或可重用软件包的建造方法获得快速开发。快速应用开发模型流程见图5。适用于信息系统应用软件的开发。

图5  快速应用开发模型

A.5.2  缺点
对大型的、但可伸缩的项目，RAD需要足够的人力以创建足够的RAD小组。RAD要求开发者和用户在一个很短的时间内完成一个系统，如果双方中的任何一方没完成约定，都会导致RAD项目失败。
A.6  演化模型
A.6.1  模型描述
演化模型也是通过构造系统的各个可执行的工作版本来开发系统的，但是，与增量模型的区别是承认：需求不能被完全了解，且不能在初始时就确定。在该方法中，需求一部分被预先定义，然后在每个相继的工作版本中逐步完善。
该方法中，每个工作版本在开发时，开发过程中的活动和任务顺序地或部分重叠平行地被采用。
对所有的工作版本，开发过程中的活动和任务通常按同一顺序被重复使用。维护过程和运作过程可以与开发过程平行地使用。获取过程、供应过程、支持过程和组织过程通常与开发过程平行地使用。
演化模型示例见图6

图6  演化模型示例

A.6.2  时机
具有如下条件时，可考虑采用演化模型：
a)       需要早期获得功能；
b)      中间产品可以提供使用；
c)      系统被自然地划分为增量；
d)      工作人员/资金可以逐步增加；
e)       需要通过用户反馈来理解全部需求；
f)       便于对技术变化的监督。
A.6.3  风险
在选择采用演化模型时，应考虑如下的风险因素：
a)       一次要求所有功能；
b)      长时期内有限的资源（工作人员/资金）的保证。

                                    
                  
              
            
            
              
            
            
              源自：