1、软件工程 第三讲 软件生存周期模型,2.2 软件生存周期模型 ) 基本概念软件生存周期模型 IEEE Standard 12207.0-1996 把一个软件生存周期模型描述为：一个包括软件产品开发、运行和维护中有关过程、活动和任务的框架，覆盖了从该系统的需求定义到系统的使用终止。中国计算机科学与技术百科全书称软件生存周期模型为“软件开发模型”，并把它定义为：软件过程、活动、任务的结构框架。,系统需求,软件需求,需求分析,设 计,编 码,测 试,运 行,归纳逻辑：PQPQ,) 瀑布模型1970年，W.Royce The basis for most current practice and ha
2、s many variations. Its name come from the progression of activities based on the output of one phase “falling” as input to the following phase. It is driven by the needs to schedule project milestones which are provided by the completion of documents at each level or phase.,（）项目的开发依次经过：需求、设计、编码和单元测试
3、、集成以及维护 这一基本路径。（）在每一阶段提交以下产品：软件需求规约、设计文档、实际代码、测试用例、最终产品等。工作产品（又称可 提交的产品，Deliverables） 流经“正向”开发的基本步骤路径。（）“反向”步骤流表示对前一个可提交产品的重复变更（又称为“返工”(Rework)） 。由于所有开发活动的非确定性，因此是否需要重复变更，这仅在下一个阶段或更后的阶段才能认识到。返工不仅在以前阶段的某一地方需要，而且对当前正在进行的工作也是需要的。,关于瀑布模型的几点说明 (）瀑布模型的优点 虽然瀑布模型是一个比较“老”的、甚至过时的开发模型， 但其优点为：在决定系统怎样做之前，存在一个需求阶
4、段，鼓励对系 统“做什么”进行规约（即设计之前的规约）。在建造构件之前，存在一个设计阶段，鼓励规划系统结构（即编码之前的设计）。在每一阶段结束时进行复审，允许获取方和用户的参与。允许基线和配置早期接受控制。前一步工作产品可作为下一步被认可的、文档化的基线。,（）瀑布模型存在的不足客户必须能够完整、正确和清晰地表达他们的需求；开发人员一开始就必须理解其应用。在开始的两个或三个阶段中，很难评估真正的进度状态;设计、编码和测试阶段都可能发生延期。在一个项目的早期阶段，过分地强调了基线和里程碑处的文档;可能要花费更多的时间，用于建立一些用处不大的文档。当接近项目结束时，出现了大量的集成和测试工作。 直
5、到项目结束之前，都不能演示系统的能力。,（3）瀑布模型适用的情况在开发中，向下、渐进的路径占支配地位。也就是说，需求已被很好地理解；并且过程设计人员也很清楚：开发组织非常熟悉为实现这一模型所需要的过程（或经过培训后，熟悉什么时候来支持这一项目，以实现这一模型所需要的过程）。因此为了避免产生过多的反复迭代工作，增加开发成本， 一般在准备采用瀑布模型(也包括其他模型)时，需要考虑以下2 个问题：第一个问题是，过程设计人员必须对初始产品(通常是软件需求规约，SRS)的不确定性进行评估。另一个问题是，组织是否具有熟练实施每个活动和任务的历史经验。,1,3,2,5,9,10,11,6,7,12,13,8
6、,4,增量1 1,2,5,9 增量2 3,6,7,4,10,11 增量3 8,12,13 ,管理,增量规约,增量设计,纠错性分析,增量实现,增量1,增量2,增量3,3) 增量模型,该模型有一个假设，即需求可以分段，成为一系列增 量产品，每一增量可以分别地开发。,关于增量模型的几点说明：,(1）增量模型的优点作为瀑布模型的第一个变体，具有瀑布模型的所有优点。此外，它还有以下优点：第一个可交付版本所需要的成本和时间是很少的；开发由增量表示的小系统所承担的风险是不大的；由于很快发布了第一个版本，因此可以减少用户需求的变更；允许增量投资，即在项目开始时，可以仅对一个或两个增量投资。,(）缺点：如果增量
7、模型不适于某些项目，或使用有误，则有 以下缺点： 如果没有对用户的变更要求进行规划，那么产生的初始增量可能会造成后来增量的不稳定；如果需求不像早期思考的那样稳定和完整，那么一些增量就可能需要重新开发，重新发布；管理发生的成本、进度和配置的复杂性，可能会超出组织的能力。注：如果采用增量投资方式，那么客户就可以对一些增量进 行招标。然后，开发人员按提出的截止期限进行增量开发，这 样客户就可以用多个契约来管理组织的资源和成本。,(）该模型的适用情况在开始开发时，需求很明确，且产品还可被适当地分解为一些独立的、可交付的软件（构造增量：Build increments如果一个增量并不需要交付给客户的话，
8、那么这样的增量通常称为一个“构造”(Build)。如果增量被交付，那么它们就被认为是发布版本(Released version)。 ）； 在开发中，期望尽快提交其中的一些增量产品。 例如： 一个数据库系统，它必须通过不同的用户界面，为不同类型的用户提供不同的功能。在这一情况下，首先实现完整的数据库设计，并把一组具有高优先级的用户功能和界面作为一个增量；以后，陆续构造其它类型用户所需求的增量。,附：微软“同步-稳定的产品开发模型” 将项目分为若干个里程碑阶段 定义稳定、灵活的体系结构，并为构件和子系统的开发提供统一的接口 开发构件，维持一个可发布的系统版本可以准确把握项目进展情况增强开发人员的信
9、心和成就感可以随时根据市场情况及时作出调整,需求,设计,编码,测试,集成,需求,设计,编码,测试,集成,开发,反 馈,开发,反 馈,.,核 心 系 统 开 发,第 二 次 迭 代,) 演化模型（ Evolutionary model）是一种有弹性的过程模式，由一些小的开发步组成，每一步历经需求分析、设计、实现和验证，产生软件产品的一个增量。通过这些迭代，完成最终软件产品的开发。 针对事先不能完整地定义需求 针对用户的核心需求,开发核心系统 根据用户的反馈,实施活动的迭代,关于演化模型的几点说明 (1）主要特征该模型显式地把增量模型扩展到需求阶段。由图可以看出， 为了第二个构造增量，使用了第一个
10、构造增量来精化需求。 这一精化可以有多个来源和路径。 首先，如果一个早期的增量已向用户发布，那么用户会以变 更要求的方式提出反馈，以支持以后增量的需求开发。第二，通过实实在在地开发一个构造增量，为以前还没有认 识到的问题提供了可见性，以便实际地开始这一增量的工作。,(2）与瀑布模型的关系在演化模型中，仍然可以使用瀑布模型来管理每一个演化的增量。一旦理解了需求，就可以像实现瀑布模型那样开始设计阶段和编码阶段。 (3）使用演化模型应注意的问题不能弱化需求分析阶段的工作。其原因是：在项目开始时，考虑所有需求来源的重要性和风险，对这些来源的可用性进行评估。只有采用这一方法，才能识别和界定不确定的需求，
11、并识别第一个增量中所包含的需求。,(4）演化模型的长处和不足演化模型还具有以下优点：与增量模型是类似的。特别地，在需求不能予以规约时，可以使用这一演化模型。用户可以通过运行系统的实践，对需求进行改进。与瀑布模型相比，需要更多用户/获取方的参与。缺点有：演化模型的使用仍然处于探索阶段，因此具有较大的风险，需要有力的管理。演化模型的使用很容易成为不编写需求或设计文档的借口，即使很好地理解了需求或设计。用户/获取方不易理解演化模型的自然属性，因此当结果不够理想时，可能产生抱怨。,演化,维护,确认,实现,设计,分析,) 喷泉模型 特征：迭代无缝 与面向对象技术 的关系,) 螺旋模型 该模型是由Dr.
12、Barry Boehm Boehm 1988开发的。该模型将软件生存周期的活动分为四个可重复的阶段： 规划、风险分析、开发和评估： 项目的进度是“螺旋”式的。,risk analysis stage,Development stage,Planning stage,Evaluation stage,start,Resource use,其中： 评估和风险分析阶段都可作出一个决策：项目是否继续。 螺旋循环的次数指示了已消耗的资源； 在规划阶段、风险分析阶段和开发阶段均进行需求规约活动； 在早期螺旋循环中，为了为最终的实现给出一些指导性决策，经常使用原型构造； 设计和实现活动一般是在开发阶段进行；
13、 V&V 活动在开发阶段和评估阶段进行；,关于螺旋模型的几点说明： (1）该模型关注解决问题的基本步骤:标识问题;标识一些可选方案，选择一个最佳方案;遵循动作步骤，并实施后续工作。其中只要完成了开发的一个迭代，开发的另一个迭代就开始。 (2）螺旋模型的一个特征是，实际上只有一个迭代过程真正开发可交付的软件。因此,如果项目的开发风险很大，或客户不能确定系统需求，在更广泛的意义上来讲，还包括系统或系统类型的要求，这时螺旋模型就是一个好的生存周期模型。,(3) 与其它模型的关系与演化模型一样，螺旋模型也使用瀑布模型作为一个嵌入的过程-即分析、设计、编码、实现和维护的瀑布过程，是螺旋一周的组成部分。
14、尽管螺旋模型和一些迭代模型在框架和全局体系结构方面是等同的，但所关注的阶段以及它们的活动是不同的。具体地说：标识客户想要的是一个什么样的系统；确定风险和效益的可选路线；选择最优方案；开发系统；评估完成情况等；重新开始。即 螺旋模型扩展了增量模型的管理任务范围。而增量模型是基于以下假定：需求是最基本的、并且是唯一的风险源。而在螺旋模型中，决策和降低风险的空间是相当广泛的。,7) 模型中的三个重要修饰原型、并发、商业构件的复用。（1）原型与原型构造 何谓原型显式地规划如何使用一个或多个演化的增量，这作为一个 明确的需求揭示工具, 是生存周期模型的发展的必然。遵循其它工程领域所使用的术语，我们把这样
15、的一个增量 称为一个原型。,注：尽管原型可以由用户以某一受限的方式使用，但不能把原型看作是一个具有完备功能的增量。, 原型的作用 揭示那些以后将在具有完备功能的、可交付的、可支持的 增量中予以实现的需求。 可以用于为一个项目或一个项目的某些部分，确定技术、 成本和进度的可能性。例如，原型有助于回答以下问题：一个新的开发环境或工具，是否能够满足客户成本和进度约束？一个被安装的、可用的软/硬件基础设施，是否可以支持客户新的性能和能力需求？是否能够创建这一产品，即这是可行的吗？, 原型构造原型构造，有时它也被称为快速应用开发（Rapid Application Development, RAD）。适
16、用范围：对那些具有较多用户界面和数据库的系统开发中，可使用之使用条件：需要相应RAD方法和工具的支持。,注：近年来，由于VB（Visual Basic）、Delphi、。NET 等开发环境的出现，这一术语得到了广泛的应用，使用这些 工具几乎可以无缝地建造原型和最终系统。,如何使用： 首先给出一个原型的目标陈述，其中包括为实现这一目标所需要的特定需求。 随后进行设计。其中应选择一组可用的工具，用于实现该系统的原型，而后当设计完成之后，开发人员就建造这一原型，即实现对客户可见的或强调一个关键技术风险的那些方面。 最后，通过某种形式，对原型进行评估。评估方法：通常是把原型交给客户，进行试用。,原型试
17、用的目标是：揭示客户界面的需求。 通过客户与一个原型系统的交互，提出反馈，明确或揭示客户的功能和性能需求。随后，开发人员可依据这一反馈，基于所使用的生存周期模型，再将这些需求精化并实现之。,原型构造在应用中的风险 用户和开发人员不能很好地判断将一个原型变成一个具有 完整功能的系统需要多少工作。 由于客户看到的是一个精化、复杂的用户界面，于是他们就可能认为系统开发的大部分工作已经完成。 一旦由于感觉构造的原型看起来是乎是相当成功的，这样，原型就有可能以一种无规划的方式“成长”，以至于超出了系统的期望或要求，为了最终版本，耗尽进度、资金和人力，付出了很高的代价。换言之，它违背了所指出的计划，即它是
18、第一个增量的交付。,可能发生原型开发组与最终产品开发组之间的交流和学习不能是充分的，例如原型构造组是一个独立组织功能的一部分，如市场策划。另外，原型开发所使用的工具与整个开发工作所使用的工具可能无法实现互操作。不论在性能方面还是在能力方面，都无法对原型进行度量，以确定实现的程度。有时，由于原型并没有必要支持系统所有功能，因此原型实际执行的功能（它所实现的）可能甚至好于一个可交付的功能。在这种情况下，从原型到整个系统的进行中，客户就有可能会遗漏一些事情，而说明这种情况又可能是非常困难的。,如何解决这些风险：在项目早期，原型开发组标识并监控以上这些风险进一步说，即使对它们实施了管理，所有这些风险也
19、可能发生到一定程度，但关键的问题是它们必须被识别并被管理。,（）生存周期模型中的并发 问题的提出：当一个工作程序经过其所选择的生存周期时，一些过程之 间的重叠几乎是不可避免的，不论这一重叠是规划的还是没 有规划的。例如，即使在需求是非常清楚的，出于对成本和进度的考虑，可能就选择通常的瀑布模型的情况下，表面上看，这排除了并发的可能性事实上这是非常困难的。例如，如果一个子系统的详细设计在另一个子系统之前完成，并且这两个子系统之间的接口是稳定的，那么就可以提前对已完成详细设计的那个子系统进行编码，从而导致一个系统的详细设计阶段和编码阶段的并发。,还要注意，在所有生存周期模型的反向流（即对已经完成的
20、一个文档或其它产品必须要做的改变）中，也可能隐含地存在 一些并发。使用并发的基本要求-要求组织的管理必须有能力支持并发，包括进度安排、 成本控制、状态跟踪和配置管理系统，包括技术复审机制 和任何设计工具。-如果两个子系统同时处在同样的开发阶段，那么就要求 严格监控这两个子系统之间的界面。,使用中的问题围绕并发的使用，存在以下两个重要的问题： 并发程度。并发的程度可以从偶然的，只有少量反向改变的要求； 到过分的，存在一个增量正在设计，而前面那个增量正在集成。注意：以上两种情况，对技术系统和管理系统的需求是非常不同的。 并发的管理。一旦出现并发，就要很好地进行规划。其中应重视由于使用并发所出现的这
21、些问题。,（3）商业构件的复用 问题的提出现代软件系统的创建趋势是，使用商业应用框架和商业构 件，或复用组织内部已开发的构件和框架，当然，也复用组 织的实践和规程。这一趋势的出现，有以下三个原因：（1）. 市场和成本的竞争压力；（2）. 交付环境的日趋复杂和标准化，例如Internet；（3）. 产品线工程的出现，其中系统地规划和实施：多个相关软件产品的开发和演化； 那些可复用的设计和实现； 用于产品线的所有产品。,这趋势意味着：一个项目生存周期过程的意义，可能从毫无意义，一直 到意义深远。例如，如果开发组织使用一个新的商业应用框架来建造一个产 品，那么就需要开发一个原型，以获得框架使用的经验
22、，并 检验该框架对这一应用的适应性。如果使用的框架是组织内部开发的，那么也需要开发一个 原型，以评估该框架对应用开发的的适应性。框架的选择就是这样一个基本的设计决策，以至于必须在 项目生存周期的早期实施原型构造。如果可能的话，原型构 造应在承约项目的成本和进度之前实施。, 商业构件的使用 如果使用内部开发的构件或市场购买的构件，作为新系 统的组成部分，那么就必须在项目早期评估这些构件的适应 性。确切地说，怎样使用这些构件，什么时候评估这些构件。 例如，如果产品的的很大部分都涉及与用户的交互，那么就应 该仔细地评估实现图形用户界面的构件，以确保它们支持所要 求的功能。在操作文档开发之后，就应立即
23、进行这一评估。 如果一个商业构件为产品提供较少的但是很关键的部分， 那么就应该在设计阶段之前或期间对其进行评估，一旦发现构 件不适合该产品，就要建造一个构件或在一些可选的构件中获 得一个构件。,按着一般的原则，如果存在一些构件或框架，即使这些资源 正在用于一个产品的开发，那么也应该对它们进行评估。评估 过程应在生存周期模型中予以明确地表达。例如，在某些情况 下，评估过程可能在很大程度上影响生存周期模型的选择或生 成，如选择螺旋模型，而不选择增量模型。 使用已存在的构件，除了会引起一个项目生存周期结构上的 改变，还可能极大地影响个体的技术过程。例如，如果复用的 构件表示了该产品的重要部分，那么单元测试工作量的百分比 就会相对地减少，但集成该部分的工作量就会增大。同样，由 于必须建立或修改子过程，以确保设计与任何可复用的框架或 构件是一致的，因此设计过程将是有效的。,作业一：,（第5页）解释以下术语：软件、软件工程、软件危机、模型（第57页）简述软件生存周期、软件生存周期过程、软件生存周期模型、软件项目生存周期过程之间的基本关系,
