3--软件生存周期模型.pptVIP

软件工程

第三讲软件生存周期模型

朱建凯;2.2软件生存周期模型

１)基本概念

软件生存周期模型IEEEStandard12207.0-1996

把一个软件生存周期模型描述为：一个包括软件产品开

发、运行和维护中有关过程、活动和任务的框架，覆盖了从该

系统的需求定义到系统的使用终止。

中国计算机科学与技术百科全书

称软件生存周期模型为“软件开发模型”，并把它定义为：

软件过程、活动、任务的结构框架。;;（１）项目的开发依次经过：需求、设计、编码和单元测试、

集成以及维护–这一基本路径。

（２）在每一阶段提交以下产品：软件需求规约、设计文档、

实际代码、测试用例、最终产品等。工作产品（又称可

提交的产品，Deliverables）流经“正向”开发的基本步

骤路径。

（３）“反向”步骤流表示对前一个可提交产品的重复变更（又

称为“返工”(Rework)）。

?由于所有开发活动的非确定性，因此是否需要重复变

更，这仅在下一个阶段或更后的阶段才能认识到。

?返工不仅在以前阶段的某一地方需要，而且对当前正

在进行的工作也是需要的。;关于瀑布模型的几点说明

(１）瀑布模型的优点

虽然瀑布模型是一个比较“老”的、甚至过时的开发模型，

但其优点为：

?在决定系统怎样做之前，存在一个需求阶段，鼓励对系

统“做什么”进行规约（即设计之前的规约）。

?在建造构件之前，存在一个设计阶段，鼓励规划系统结

构（即编码之前的设计）。

?在每一阶段结束时进行复审，允许获取方和用户的参与。

?允许基线和配置早期接受控制。

?前一步工作产品可作为下一步被认可的、文档化的基线。;（２）瀑布模型存在的不足

?客户必须能够完整、正确和清晰地表达他们的需求；开发

人员一开始就必须理解其应用。

?在开始的两个或三个阶段中，很难评估真正的进度状态;

设计、编码和测试阶段都可能发生延期。

?在一个项目的早期阶段，过分地强调了基线和里程碑处

的文档;可能要花费??多的时间，用于建立一些用处不

大的文档。

?当接近项目结束时，出现了大量的集成和测试工作。

?直到项目结束之前，都不能演示系统的能力。;（3）瀑布模型适用的情况

?在开发中，向下、渐进的路径占支配地位。也就是说，

需求已被很好地理解；并且

?过程设计人员也很清楚：开发组织非常熟悉为实现这一模

型所需要的过程（或经过培训后，熟悉什么时候来支持这

一项目，以实现这一模型所需要的过程）。

因此为了避免产生过多的反复迭代工作，增加开发成本，

一般在准备采用瀑布模型(也包括其他模型)时，需要考虑以下2

个问题：第一个问题是，过程设计人员必须对初始产品(通常

是软件需求规约，SRS)的不确定性进行评估。

另一个问题是，组织是否具有熟练实施每个活动和

任务的历史经验。;;(３）该模型的适用情况

?在开始开发时，需求很明确，且产品还可被适当地分解为一些独立的、可交付的软件（构造增量：Buildincrements．如果一个增量并不需要交付给客户的话，那么这样的增量通常称为一个“构造”(Build)。如果增量被交付，那么它们就被认为是发布版本(Releasedversion)。）；

?在开发中，期望尽快提交其中的一些增量产品。

例如：

一个数据库系统，它必须通过不同的用户界面，为不同类型的用户提供不同的功能。在这一情况下，首先实现完整的数据库设计，并把一组具有高优先级的用户功能和界面作为一个增量；以后，陆续构造其它类型用户所需求的增量。;附：微软“同步-稳定的产品开发模型”

?将项目分为若干个里程碑阶段

?定义稳定、灵活的体系结构，并为构件

和子系统的开发提供统一的接口

?开发构件，维持一个可发布的系统版本

可以准确把握项目进展情况

增强开发人员的信心和成就感

可以随时根据市场情况及时作出调整;;关于演化模型的几点说明

(1）主要特征

该模型显式地把增量模型扩展到需求阶段。由图可以看出，

为了第二个构造增量，使用了第一个构造增量来精化需求。

这一精化可以有多个来源和路径。?

首先，如果一个早期的增量已向用户发布，那么用户会以变

更要求的方式提出反馈，以支持以后增量的需求开发。

第二，通过实实在在地开发一个构造增量