第2章节 软件生命周期过程模型.pptVIP

2.4 增量过程模型 2.4 增量过程模型 增量和迭代模型： 两个系统并行工作，产品系统和开发系统 产品系统（或称操作的系统）是一个被顾客和用户使用的系统 开发系统是准备用来替换现行产品系统的下一个版本 2.4 增量过程模型 增量开发：需求文档中指明的系统按功能划分为子系统。定义发布时首先是定义一个小的、具有一定功能的子系统，然后在每一个新的发布中增加新的功能。 迭代开发：在一开始就移交一个完整的系统，然后在每一个新的发布版本中改变每个子系统的功能。 2.4 增量过程模型 增量开发 迭代速度加快，每次只是在前一次的基础上增加少量功能，增量过程。 有些时候可能会用一种几乎连续的过程小幅度地推进项目。 适用于项目后期 。 2.5 其他类型的过程模型 喷泉模型：（仅作了解） 一种以用户需求为动力，以对象为驱动的模型，主要用于描述面向对象的软件开发过程。 软件开发过程自下而上周期的各阶段是相互重叠和多次反复的。各个开发阶段没有特定的次序要求，并且可以交互进行，可以在某个开发阶段中随时补充其他任何开发阶段中的遗漏。 2.5 其他类型的过程模型 智能模型：（仅作了解） 也称为“基于知识的软件开发模型”，把瀑布模型和专家系统结合在一起，利用专家系统来帮助软件开发人员的工作。 在实施过程中以软件工程知识为基础的生成规则构成的知识系统与包含应用领域知识规则的专家系统相结合，构成这一应用领域软件的开发系统。 2.5 其他类型的过程模型 V模型： 特点：实现了测试设计和测试执行相分离，揭示了软件测试活动分层和分阶段的本质特性，测试执行的顺序与开发活动相反（对应关系） 单元和集成测试应检测程序的执行是否满足软件设计的要求；系统测试应检测系统功能、性能的质量特性是否达到系统要求的指标；验收测试确定软件的实现是否满足用户需求或合同的要求。 2.5 其他类型的过程模型 2.5 其他类型的过程模型 2.5 其他类型的过程模型 需求分析阶段：参与SRS的调研及评审工作，从测试角度分析需求的可测试性，如：需求内容是真实可靠的，一条需求存在一个明确预知的结果，是否正确、完整、严密、无歧义；并制定系统测试计划。 概要设计阶段：参与HLD（High Layer Desigh）评审，制定集成测试计划，并编写系统测试方案及系统测试用例的设计，完成本阶段的测试需求跟踪。 详细设计阶段：参与LLD（Low Layer Desigh）评审，制定单元测试计划，并编写集成测试方案及集成测试用例的设计，完成本阶段的测试需求跟踪。 编码阶段：参与代码的评审，编写相关的单元测试方案，单元测试用例的设计，并参加相应的评审工作，完成本阶段的测试需求跟踪。 2.5 其他类型的过程模型 单元测试UT/集成测试IT/系统测试ST阶段：搭建测试环境，执行测试用例；发现缺陷后提交缺陷报告，进行回归测试，提交测试日报，系统测试预测试报告，系统测试报告。 验收测试阶段：提交测试报告以及对测试报告的相关评审工作，最后是对缺陷的度量分析及总体测试工作的评价；做好整个测试周期中一切需要更新的内容，方便未来新版本的测试。 2.5 其他类型的过程模型 优点：非常明确的标明了测试过程中存在的不同等级，并且清晰的描述了这些测试阶段和开发过程期间各阶段的对应关系。 缺点： 仅仅把测试作为在编码之后的一个阶段，是针对程序进行的寻找错误的活动，而忽视了测试活动对需求分析，系统设计等活动的验证与确认的功能。 仅注重动态测试，未涉及静态测试技术。 2.5 其他类型的过程模型 验证和确认（VV） 验证（verification） ：保证软件正确地实现特定功能的一系列活动，Am I building the system right? 检测每一阶段形成的工作产品是否与前一阶段定义的规格相一致（需求、设计、编码、测试前后是否一致）。 包括需求评审、代码走查、代码审查、设计评审及回顾评审等； 2.5 其他类型的过程模型 确认（validation） ：保证所生产的软件可追溯到用户需求的一系列活动，Am I building the right system? 检测每一阶段的工作产品是否与最初定义的软件需求规格相一致（需求、设计、编码、测试对需求的跟踪） 执行真实的功能来完成，包括单元测试、集成测试、系统测试、用户验收测试等。 2.5 其他类型的过程模型 通常在测试中，使用验证来检查中间可交付的结果，使用确认来评估可执行代码的性能。 从需求阶段到编码阶段，主要是采用验证手段进行测试，从而完成对开发的中间结果的正确性的评估。 编码完成并经过代码审查等测试之后，此时的测试主要在软件的可执行模式下进行，即利用确认手段进行测试。 2.5 其他类型的过程模型 2.5 其他类型的过程模型 变换模型：试图通过减少某些主要的开发