UML项目计划--基于RUP的软件开发过程规范.doc

基于rup的软件开发过程规范draft 1uml项目计划这个项目计划的目的是为你提供一个项目计划模板。在项目中有大量的模板和表格需要你来填写，以记录项目的信息、估计等。本文的最重要的参考文献是rational unified process 中文版 v 2000.02.20。为了针对你的项目更新这个计划，你需要：l 将项目名字oo项目改为你的项目名称；l 根据你的项目的信息填写各种模板表格；l 更新本文档以反映你的项目的计划和策略；l 根据项目组成员的反馈进行改进，将批准后的项目计划放入一个共享目录；l 执行计划，并监控项目的进行我们的目标是：这个项目计划将辅助所有的项目组成员朝成功完成项目的目标共同前进，创造高质量的软件产品。1 引言一个oo项目是由一系列围绕一个目标或目的的唯一的、复杂的和相互联系的活动组成，并且必须在规定的时间完成，同时满足预算要求和符合合同规定的技术规范要求。一个项目的关键问题见下图。增加在三角形中间的“scope and quality”会增加“cost”、“time”和“resources”.oo项目管理与非oo项目管理相比，关键的问题包括：l 在范围规模/抽象的各种层次上进行计划和监控：企业业务层次、项目系统层次、构造/发布层次l 使用rup阶段模型：初始阶段定义、精化阶段计划、构造阶段建模/编码、产品化阶段向最终用户部署产品l 使用rup为每个构造/发布项创建下列模型：需求、分析、设计、实现和测试l 使用uml元素和语义l 使用面向对象的规模、复杂性和质量度量grady booch在对象-solutionsmanaging the 对象-oriented project中说：“软件管理小组的中心任务是平衡一组不完整、不一致和不断变化的技术和非技术需求，以产生一个对最本质的最小功能集最优的系统。”booch还讲到：“一个成功的软件项目应该是：它的交付项满足并且可能超过最终用户的期望、它是以一种省时经济的方式被开发的，并且对变更和改变是有弹性的。”项目管理包含计划、进度安排、人员组织、资源配置和执行情况的监控，以产生一个高质量的系统。“更好、更快、更便宜。”grady booch在对象-solutionsmanaging the 对象-oriented project中说：“一个成功的oo项目有5中习惯，包括：l 不留情面地专注于开发一个能提供被良好理解的本质的最小功能集的系统.l 存在一种文化：以结果为中心、鼓舞性的交流沟通和不怕失败l 有效地使用面向对象建模技术l 有一个强壮的体系结构项目视图l 应用一个被良好管理的迭代增量开发声明周期。”philippe kruchten在the rational unified process an introduction second edition中为支持有效的软件工程提供了解决方案：l 迭代地开发软件l 管理需求l 使用基于组件的体系结构l 验证软件的质量l 控制软件的变更下面是参考文献和标准：l rational unified process 中文版 v 2000.02.20 rational software corporationl omg unified modeling language specification v1.3 first edition: march 20002 企业级计划和监控oo项目系统应根据规模/抽象的层次进行建模。对整个企业来说知道oo项目处在何处是很重要的。规模/抽象的层次级别层次级别定义uml例子oo项目全局关注影响多个企业的语言、标准、政策internetansi和ieee标准企业有多个系统的组织xyz公司全部的系统应用程序组需求观点：行动者和系统实现观点：组件需求：行动者+系统实现：组件office 2000包括oo项目在内的整个系统系统/子系统/组件应用程序成组的类作为一个系统或应用一起工作系统包或组件word 2000oo项目系统包成组的类包标签盒子协作为一个特定的目的一起动作的成组的类实现一种模式协作图虚线椭圆类定义一组对象类document属性操作属性值操作服务属性操作document.name document.open()希望oo项目系统成为大系统的一个组件是基于如下的理由：l 设置oo项目系统的边界l 促进精确的交流来了解规模/抽象的层次l 便于为oo项目系统指定责任和组件的交互l 如果组件接口被清晰地定义了，可以加速开发3 企业级业务建模业务建模（business modeling ）是对整个企业进行建模。对oo项目来说支持企业地短期和长期目标，并能适当地拟合企业是重要的。业务建模有下列产出：vision文档、组织结构图、业务事件和流程(use case)、业务行动者、工作者和实体(domain model)、商业规则目录、业务接口（操作的集合）、业务模式、业务系统体系结构、组件图和词汇表。业务模型关键的uml元素业务流程(use case)、业务领域对象对象s关键任务对业务建模目标充分的业务/企业信息静态/结构图业务领域对象动态/基于时间的图业务流程(use case)工具rose、需求跟踪工具关键角色业务/系统分析员、体系结构师模型验收项目经理，体系结构师、客户/用户下面是一张企业业务建模的状态表。企业业务模型位置-引用编号备注业务模型业务事件业务行动者、工作者、实体业务接口业务模式业务词汇表体系结构组件业务建模的好处有：l 支持定义好的需求，从而导致快速、有效的系统开发。l 支持创建正确、可靠、可扩展的和可重用的系统l 支持交流、一致性和减少冗余4 基于组件开发（cbd）的系统体系结构oo项目系统是一个更大的由组件组成的企业级系统的一部分。基于组建的开发（组件-based developmentcbd）是创建和部署通过组件组装而成的软件系统，同时要开发和实现这些组件，通常需要建立一个分层的组件体系结构。kruchen 在the rational unified process an introduction second edition定义体系结构为：“体系结构涵盖对下面问题的重要的决定：l 一个软件系统的组织结构；l 组成系统的结构化元素的选择集合和它们的接口，以及这些元素相互协作所需要的行为；l 将这些元素渐进地组装进更大的系统的合成过程；l 指导这个组织结构、元素、接口、元素之间的协作关系和合成方式的体系结构风格。”体系结构指一个系统的组织结构，包括它分解成部件、部件间的连接、交互机制和关于系统设计的指导性原则。uml组件图显示了具有接口的组件。一个接口（interface）是一个没有实现的操作的集合。基于组件的开发方式的益处有：l 通过组件替换，支持开发高度可升级、可修改的系统l 通过良好定义的接口，支持通讯l 通过定义可重用的组件，支持重用l 支持一个高度柔性的系统体系结构，l 支持使用标准化的组件框架，如com+、corba、ejb等等l 支持使用第三方商业组件l 为配置管理和版本管理提供了一个自然的基础5 项目计划和监控5.1 项目目标和概述oo项目应该设计、构造和发布与oo项目需求一致的oo项目系统。目标是创建一个正确、可靠、容易理解、可扩展和重用的系统。系统必须满足所有功能性需求，例如各种特性（使用use case建模）。系统必须满足以下的非功能性需求：可用性、可靠性、性能和支持能力。描述或位置备注项目名称项目描述项目目标项目功能性需求文档项目非功能性需求文档项目约束项目假设项目标准uml、编码标准、其他 (错误处理、线程)企业业务模型项目工作指南见附录项目原型、标签值和约束见附录项目uml模型示例见附录项目文档见工件总结（附录b）项目工具使用指导、cd、书籍、培训项目词汇表项目重用库组件、类、操作、模式等项目uml模型复查每两周或在每个迭代结束时进行定义项目目标的好处有：l 使项目成员、客户和其他人员在共同的基础上进行沟通l 支持在项目计划和实际进展之间进行比较，并识别潜在的问题l 使项目成员集中在实现项目目标的活动上，提高项目效率l 可以有效地安排和设置为实现项目目标需要进行的活动和它们的优先顺序5.2 项目风险风险是正在进行或迫近的对主要里程碑的实现有重要负面影响的因素。如果风险产生，那么对项目而言必然在成本、进度或系统性能等方面存在负面因素。booch在对象 solutions 讲到：“什么是任何实际的项目都面临的最严重的风险因素？包括：l 不准确的测量尺度l 不充分的测量l 过度的进度压力l 管理失误l 不准确的成本估计l 银弹综合症l 蠕变的用户需求l 低质量l 低生产率l 取消的项目”为了保证我们能实现项目目标，oo项目应识别和监控所有主要的风险。我们必须准备和避免灾难性的“惊奇”和未期待的事件。oo项目已计划的风险如下：风险名称描述发生的可能性影响规避计划发生时的应变方案备注数据库未按时交付10%延迟项目按月监控定义项目风险的益处有：l 支持有效的计划，避免“惊奇”l 提高项目成功的概率l 支持有效的决策5.3 项目阶段和进度安排oo项目应遵循rup中描述的统一软件开发过程。 这是一个迭代增量开发过程，强调渐进地交付一个复杂软件系统的交付项（builds/releases）。每个阶段（phase） 是两个主要里程碑之间的时间跨度，例如先启、精化、构建和产品化。rup阶段化分对一个52周的项目的按周阶段化分示例先启阶段-5周精化阶段-16周构建阶段-26周产品化阶段-5周描述定义项目的范围和商业案例计划项目，指定特性和建立体系结构基线构造项目。软件从体系结构基线发展到可以向用户交付的程度将软件交到用户的手中产品项目视图文档、use case列表、项目词汇表、商业案例（商业环境、成功标准、赢利预测）、风险评估、项目计划、业务模型use case模型、非功能性需求、软件体系结构、体系结构原型、迭代计划、开发案例、初步的用户手册uml模型（需求、分析、设计、实现、测试）、每次迭代的交付项（build/release）推向市场或交给用户的软件产品时间估计10%5周30%16周50%26周2-3周/迭代10%5周资源估计5% 20% 65%10%关键角色项目经理、体系结构师、业务/系统分析员项目经理、体系结构师、业务/系统分析员项目经理、体系结构师、业务/系统分析员、程序员、测试员项目经理、体系结构师里程碑生命周期目标里程碑生命周期构架里程碑最初操作性能里程碑产品发布里程碑拥有良好定义的项目阶段划分的好处有：l 支持拥有一个良好管理的项目l 支持沟通，使客户和项目成员了解项目的进展l 支持在项目计划和实际进展之间的比较测量，尽早发现问题5.4 项目人员组成oo项目应由完成下列角色职能的人员组成：项目经理、体系结构师、业务/系统分析员、程序员、测试人员和其他需要的人员。每个角色的职责如下：项目经理管理项目的所有方面，包括进度、资源、人力等等，以实现项目的目标和交付合格的软件产品。体系结构师监督项目的技术方面，包括整个系统的体系结构、组件、组件的接口和组件之间的通讯。对开发和部署的基础结构（infrastructure）负责。提供过程环境（硬件和软件配置清单）和实现模型（组件图和部署图）。方法师/工具专家监督指导uml 和rup的使用。负责保证uml模型的正确性和完整性。提供uml、rup和case工具的使用帮助。创建用来形成报告和生成代码的case工具脚本。客户/用户提供用户的观点，作为行业领域专家参与项目开发工作。业务/系统分析员领导和协调在业务建模、需求、和分析模型工作中的需求收集、use case建模和类建模。开发人员/程序员创建所有在设计模型中的uml视图、规格说明和代码。qa 测试员创建测试计划、测试用例、测试过程和相关的测试文档。执行测试并提供测试用例结果。人员需求和角色指派对一个52周的项目的按周阶段化分示例角色先启阶段5周精化阶段16周构建阶段26周产品化阶段5周项目经理1john smith1john smith1john smith1john smith体系结构师1?1?1?1?客户/用户1?1?1?1?业务/系统分析员3?，?，?3?，?，?3?，?，?0开发人员/程序员03?，?，?3?，?，?1?qa 测试员01?1?1?其他tbdtbdtbdtbd合计610105为项目成员规定良好定义的角色的益处有：l 支持有效的计划和决策l 支持沟通，使项目成员知道他们的职责l 通过不同的项目成员从不同角度工作，支持创建一个质量系统5.5 项目资源资源必须被识别、预算和控制包括人力资源和其他资源，如工具、设备等。资源请求/批准/使用对一个52周的项目的按周阶段化分示例资源类别先启阶段5周精化阶段16周构建阶段26周产品化阶段5周 人力服务软件设备交通通讯其他总计有良好定义的资源规划的益处有：l 支持有效的项目计划和决策l 支持沟通，以识别需要的资源l 支持创建一个质量系统和满意的客户5.6 项目配置管理和版本控制项目配置管理的目标是跟踪和维护不断演化的项目资产的完整性。这些项目资产必须可被重用。有三种独立的功能：l 配置管理处理工件识别、版本和依赖关系方面的问题l 变更请求管理处理工件中被请求的变更的捕获和管理方面的问题l 状态和测量处理项目控制信息方面的问题项目资产和文档工件负责人位置当前版本/日期工具备注配置管理和版本控制的益处在于：l 支持沟通，以使项目成员使用最新的版本工作l 通过减少重复劳动提高效率l 支持创建一个质量系统，其所有部分很好地相互适合5.7 项目需求oo项目应维护一个最新的需求文档和一个需求跟踪表（requirements trace ability table）。需求跟踪表 (partial)需求编号需求名称引用 use case名称uml元素测试用例 描述 负责人1.1 deposittosavings accountdeposittosavingsaccount有良好定义的项目需求的益处有：l 支持沟通，使项目成员为实现需求而工作l 支持定义use case、use case 增量 和build/release 迭代(在一个增量内的use case 场景)l 支持识别和解决在需求中的不一致性问题l 支持创建一个质量系统，它完全满足客户需求6 迭代计划和监控oo项目应使用rup中定义的迭代增量软件开发过程。 一个use case增量（use case increment）是一个use case的集合，它表示了一个与其他增量基本不相关的业务功能的完整子集。一个use case场景（use case场景）是一个use case的一系列交互，例如 乐观的（简单）、正常（中等）或悲观的 (复杂) 场景。 一个迭代（iteration）是具有已建立的计划和评估标准的一个活动序列，它执行的结果是一个可执行的发布。它完整地经历整个软件开发过程的各个阶段，例如对一个use case增量的需求、分析、设计、实现和测试，得到一个可执行的发布项。一个产品发布（product release）是一个完整和一致的工件的集合，包括一个软件构造（software build系统的一个可执行版本）。6.1 use case 增量和build/release 迭代oo项目由多个use case增量组成。每个 use case增量包含多个build/release迭代。每个迭代通常需要34个星期。具体步骤如下：1识别所有的use case (name only)2将use case分组，形成use case 增量3在每个use case增量内，定义build/release 迭代4在每个build/release迭代中，识别所有的use case场景(name only)oo项目 增量/迭代计划 (34 周的迭代周期)增量名称use case build/release迭代 use case场景increment 1use case 1，2，3迭代1 乐观/简单，迭代2 正常/中等，迭代3 悲观/复杂迭代1 乐观/简单: uc1opt，uc2opt，uc3opt迭代2 正常/中等: uc1nor，uc2nor，uc3nor迭代3 悲观/复杂:uc1pess，uc2pess，uc3pessincrement 2use case 3，4，5iteration 4 乐观/简单，iteration 5 正常/中等，iteration 6 悲观/复杂iteration 4 乐观/简单:uc4opt，uc5opt，uc6optiteration 5 正常/中等:uc4nor，uc5nor，uc6noriteration 6 悲观/复杂:uc4pess，uc5pess，uc6pess下面是增量/迭代计划的一个例子增量名称use case build/release迭代 use case场景deposits and withdrawschecking deposit，checking withdraw，saving deposit，saving withdrawdeposit and withdraw 乐观/简单checkingdepositoptimisticcheckingwithdrawoptimisticsavingdepositoptimisticsavingwithdrawoptimisticdeposit and withdraw 正常/中等checkingdepositnormalcheckingwithdrawnormalsavingdepositnormalsavingwithdrawnormaldeposit and withdraw 悲观/复杂checkingdepositpessimisticcheckingwithdrawpessimisticsavingdepositpessimisticsavingwithdrawpessimisticinquiries and transferschecking inquiry，checking transfer，saving inquiry，saving transferinquiries and transfers 乐观/简单checkinginquiryoptimisticcheckingtransferoptimisticsavinginquiryoptimisticsavingtransferoptimisticinquiries and transfers 正常/中等checkinginquirynormalcheckingtransfernormalsavinginquirynormalsavingtransfernormalinquiries and transfers 悲观/复杂checkinginquirypessimisticcheckingtransferpessimisticsavinginquirypessimisticsavingtransferpessimisticoverdraftscheckingoverdraft，savingoverdraftoverdraft 乐观/简单checkingoverdraftoptimisticsavingoverdraftoptimisticoverdraft 正常/中等checkingoverdraftoptimisticsavingoverdraftnormaloverdraft 悲观/复杂checkingoverdraftoptimisticsavingoverdraftpessimistic对每个build/release 迭代，下面是计划和监控表。 uml模型是当前模型的位置，例如xyzf:umlmodelsiteration1model.mdl.oo项目进度状态表迭代1-乐观/简单迭代2-正常/中等迭代3-悲观/复杂uml模型计划开始日期修订的开始日期实际开始日期计划完成日期修订的完成日期实际完成/复查日期目前完成百分比（%）模型复审日期构造批准日期备注uml模型的复审每两周进行一次或在每个迭代结束时进行。周期性的，我们可以计划安排在一个迭代内部对需求、分析、设计和实现进行复审。所有uml视图和规格说明应被放置在姓名目录中，并且使所有项目复审和评论人员可以获得。每个迭代的源代码和测试结果也应使所有项目复审和评论人员可以获得。模型复审应包含对主要的uml视图和问题的简要评述。使用use case增量和build/release迭代的好处有：l 支持有效的计划和决策，“一点一点”而不是“一次完成”的方式l 降低项目风险，因为客户可以看见切实的结果l 支持有效的变更管理l 支持创建分阶段交付的一个质量系统6.2 use case 需求规格说明use case规格说明是oo项目需求的主要规格说明文档之一。每个oo项目use case要收集以下信息：名称、发起者、输入参数、输出返回值、前提条件/异常情况、后置条件/异常情况、基本/乐观的场景、替代/悲观场景、业务规则、测试用例。withdrawfromcheckingaccount use case 的use case规格说明use case名称withdrawfromcheckingaccount触发用例withdrawfromcheckingaccount输入参数sacctnum，nwithdraw输出返回stext前提条件validaccount = true and nwithdraw = ncurrentbalance引发异常的前提条件to be determined描述/变换ncurrentbalance = ncurrentbalancenwithdraw后置条件ncurrentbalance noldbalance异常的后置条件none基本/乐观的场景文本待确定；图形-见withdrawfromcheckingaccountoptimistic scenario 序列图替代/悲观的场景文本待确定；图形见withdrawfromcheckingaccount 活动图业务规则validaccountrule，adequatebalancerule测试用例1optimistic:l inputs: n sacctnumbgates001n nwithdraw100n ncurrentbalance1000 l conditions: nonel output: bgates001 withdraw $100 ok and recorded，2 to be determined输入/输出表单见下面input/output forms for withdrawfromcheckingaccount use casewithdraw request formcustomer account number _withdraw amount _button-submit button-clearwithdraw response formcustomer account number _withdraw amount _status _button-ok使用良好定义的use case规格说明的好处是：l 支持use case建模的一致性l 支持完整性，尤其对识别前提条件、后置条件和业务规则l 对与行业专家的交流很有用6.3 在构建阶段的rup模型在构建阶段，我们创建主要的uml视图和规格说明。这些模型在rup中的关键部分如下表所示。关键是对每个build/release迭代(3-4星期)创建所有这些模型。需求模型分析模型设计模型实现模型测试模型关键的uml元素系统，行动者，use case，迭代业务包，类，对象，消息硬件和软件配置，包，类，对象，消息组件，节点，代码测试计划和测试用例工作要点将系统看成黑盒进行建模在问题域对业务元素建模，不涉及实现细节为根据一个特定的实现（如硬件和软件配置）更新分析模型中的视图和规格说明为发布环境的物理元素建模，代码满足所有需求单元(类/操作) 测试，集成/系统/验收测试目标-元素之间弱偶合-强内聚所有use case和场景都有充分的信息，所有增量/迭代已计划满足需求的最简单的业务/问题域模型有充分的信息可以生成代码或手工编码优化组件体系结构网络友好，代码满足所有需求充分的测试保证代码满足所有需求静态/结构性视图方块图和use case图包图/类图包图/类图组件图/部署图/逆向工程类图-动态/时间相关的视图use case图，为每个use case的每个use case场景绘制序列图为每个use case场景绘制序列图，为每个基于状态的类绘制状态图，为每个复杂的操作绘制活动图为每个use case场景绘制序列图，为每个基于状态的类绘制状态图，为每个复杂的操作绘制活动图根据需要更新序列图来显示分布式消息-工具rose，需求跟踪，配置管理rose，需求跟踪，配置管理rose，需求跟踪，配置管理rose，需求跟踪，配置管理，测试配置管理，测试关键角色业务/系统分析员业务/系统分析员程序员体系结构师，程序员程序员/测试员模型结束项目经理，体系结构师，客户/用户项目经理，体系结构师，客户/用户项目经理，体系结构师项目经理，体系结构师项目经理，体系结构师，负责验收的客户/用户6.4 测量和监控测量（metrics）提供了监控进展、进行估计、识别风险和识别高风险复杂实体的定量手段。测量对有效的项目管理和创建高质量的系统作用重大。应该使用case工具和代码分析工具来自动进行测量数据的收集。 “如果你不能测量它，你就不能将它工程化。”管理测量（management metrics） 提供关于项目进度、资源和其他管理关注的要素计划和实际对比的信息。典型的管理测量有：每个系统的里程碑完成情况、指派人员情况、成本、use case场景数量、关键类数量、支持类数量(gui，collections，etc)、包数量，每个类的人日数、每个开发人员实现的类、开发进行的迭代数等等。参见lorenz和kidd的 对象-oriented software metrics.项目测量（project metrics）提供关于系统、包、类和其他元素的信息。项目测量对显示随时间的变更和指示高风险复杂元素很有价值。项目测量示例系统级测量在系统中的数量类/对象级测量在系统中的数量类/对象级测量比例和平均值代码测量比例和平均值规模测量分析：需求，行动者，输入消息组件，输出消息组件，输入对象/数据组件，输出对象/数据组件，use case，use case场景 设计：可执行组件，组件间的消息，节点，节点间的连接包，类，接口，操作，属性，关系，对象，消息，状态，变换，异常类，重用类代码行数/系统loc/类，loc/操作loc指ncssnon-comment source statements复杂性测量use case场景/use case泛化的级别水平类和接口/包，属性/类，操作/类，关系/类，发送消息/类，发送消息/操作，参数/操作，子类/超类加权操作/类，mccabe cyclomatic 复杂性/操作，halsted操作/操作，length * (fan-in * fan-out)2 重用性测量重用的模式，重用的组件重用的模式，重用的包，重用的类质量测量缺陷缺陷缺陷缺陷我们的目标是使用case和其他工具来监控。下面一些自动产生的表被使用。根据需要可以产生更详细的报告。规模测量number of uml elementscase tool generated迭代1-乐观/简单迭代2-正常/中等迭代3-悲观/复杂行动者use caseuse case场景包类接口属性操作泛化关系实现关系合成关系聚合关系依赖关系对象消息状态变换组件组件依赖关系节点节点连接测试用例总slocsloc/类sloc/操作复杂性测量case or other tool generated min/max/average provided in each cell迭代1-乐观/简单迭代2-正常/中等迭代3-悲观/复杂类和接口/包属性/类操作/类参数/操作发送消息/操作发送消息/类关系/类加权操作/类mccabe cyclomatic复杂性/操作halsted/操作length * (fan-in * fan-out)2使用项目测量和监控的益处有：l 支持沟通，使项目成员在最新的版本上工作l 支持尽早识别风险和问题来满足成本、进度和其他目标l 通过减少重复劳动提高效率l 使所有部分很好形成一个整体创建高质量的系统6.5 重用我们的目标是在oo项目中提倡重用。在scott ambler的文章building 对象 applications that work (sigs books，1997)中定义了以下形式的重用：操作重用（操作 reuse）是复杂操作的重用，如工具性操作或度杂的数学操作。类重用（类 reuse）是类的重用。类重用是通过共享公共类或函数或过程的集合的方式实现的。类重用导致了代码的重用。继承重用（inheritance reuse）是使用继承来利用现存类实现的行为。模板重用（template reuse）是典型一种文档重用的方式。它指使用为关键的开发工件文档、模型和源代码使用一组公共的布局的集合。组件重用（组件 reuse）是使用实现构造的、完全封装的组件。模式重用（pattern reuse）是使用已经标准化的模式，如在design patterns by erich gamma，richard helm，ralph johnson，and john vlissides，patterns in java vol 1 and 2 by mark grand，a 系统 of patterns by frank buschmann，regine meunier，hans rohnert，peter sommerlad，and michael stal，and other books. 框架重用（framework reuse）是一起使用实现了一个公共技术或业务领域基本功能的类集合。工件重用（artifact reuse）是使用先前创建的开发工件use case、标准文档、业务领域相关的模型、过程和工作指南，及其他应用。在oo项目中，我们将维护重用表。迭代中的重用表迭代1-乐观/简单迭代2-正常/中等迭代3-悲观/复杂来自类/操作库的操作来自类/操作库的类来自模式/协作库的模式来自框架库的框架重用的益处有：l 减少人力和资源消耗，因为一个重用的元素已经被文档化、构造和测试了。l 在高质量重用元素的基础上可以构造高质量的系统7 质量保证和测试质量保证（quality assurance）是保证适当的过程、资源和管理来创建一个满足约束条件的、无缺陷的高质量的系统。质量因素包括可靠性、正确性、可扩展性、可重用性、可移植性、可用性等。关于正确性和缺陷发现的质量保证活动包括：l uml模型复审（uml model reviews）这些包括视图和规格说明的描述l 走查（可选）（walkthroughs ）一种角色扮演技术，检查o-o 模型的完整性和一致性。一个人代表系统、行动者、对象或其他元素。以一个系统的输入消息开始，执行完整的use case场景，得到系统的输出消息。l case工具检查（case tool checks）自动检查视图和规格说明的完整性和一致性l 代码审查（代码 inspections）检查源代码并倒推到类图l 测试（testing）使用测试用例执行一个系统、组件、类、操作或其他元素来确认元素实现了需求并验证正确性。l 正确性证明（可选）（correctness proofs）使用数学形式化的正则模型来证明模型和代码分析和设计的正确性构建阶段的qa活动 qa活动需求模型分析模型 设计模型实现模型测试模型qa计划项目计划项目计划项目计划项目计划，编码标准测试计划uml模型复审和评审系统需求，项目计划，见需求模型检查列表分析模型的视图和规格说明，见分析模型检查列表设计模型的视图和规格说明，见设计模型检查列表case工具脚本，测试用例，代码评审，见实现模型检查列表测试用例，代码评审，见测试模型检查列表工具检查需求跟踪用case工具检查分析模型用case工具检查设计模型编译器，代码分析工具，case逆向工程，测试工具单元/集成/系统/验收测试工具7.1 操作规格说明操作规格说明（operation specification）是关键的规格说明，它对支持正确性很有用。以下是操作规格说明的一个示例：操作规格说明use case名称 withdraw触发用例 withdraw输入参数 nwithdraw ：int输出返回 boolean前提条件 nwithdraw = ncurrentbalance引发异常的前提条件 exinsuffientfunds描述/变换 ncurrentbalance = ncurrentbalancenwithdraw后置条件 ncurrentbalance priorcurrentbalance异常的后置条件 exincorrectbalance基本/乐观场景 见withdrawfromcheckingaccount 序列图替代/悲观场景 见withdrawfromcheckingaccount 活动图业务规则 validaccountrule，adequatebalancerule7.2 为每个build/release进行类图逆向工程逆向工程是从源代码产生uml视图和规格说明的方法。类图可以通过case工具从源代码中自动生成。其他视图，如use case图、序列图、状态图等，必须利用生成的类图手工创建并和领域专家进行交流。下面是为每个build/release迭代开发逆向工程uml模型的步骤：1选择一个或多个case工具来对oo项目的源代码进行逆向工程，在case工具中设置逆向选择项。2收集build/release的源代码3对每个目录/包逆向工程源代码来产生逆向工程类图4验证和更新逆向工程类图以保证视图准确地显示了类、属性、操作和关系（实现关系、泛化关系、关联关系、聚合关系、合成关系和依赖性）5创建一个词汇表数据字典，列出并定义了所有主要的词汇和其他来自逆向工程类图的报告6在检查了逆向工程类图和报告之后，创建一个推荐的为正确性、与编码标准一致等目的的代码变更列表。逆向工程的益处在于：l 可视化地显示代码l 尽早识别质量差地代码，例如意大利式细面条式的代码l 提倡遵循项目的编码标准，例如大小写、前缀、命名规则等。l 提高代码的质量7.3 测试测试应在项目的整个生命周期中进行。测试维度包括：l 质量：可靠性、use case要求的功能、性能l 测试阶段：n 单元测试（unit tests）系统最小的可测元素被独立地测试，例如组件、协作、类、操作n 集成测试（integration tests）测试集成单元（组件或子系统）n 系统测试（system test）完成的系统被测试n 验收测试（acceptance test）完整的系统被最终用户测试，为部署做好准备l 测试的类型：n benchmark测试n 配置测试n 功能测试n 安装测试n 集成性测试n 负载测试n 性能测试oo项目的测试计划应包括以下内容：l 测试用例（test case）一组测试输入、条件和期望的结果的集合见下面的测试用例规格说明l 测试过程（test procedures）“如何”建立、执行和评估测试结果的活动步骤l 测试脚本（test scripts）自动测试用的高级语言脚本l 测试类和组件（test classes and components）驱动（drivers），桩（stubs），和其他用于测试的程序下面是oo项目的测试用例规格说明（test case specification）：测试用例规格说明测试用例名称use case名称use case场景名称触发用例输入参数输出返回前提条件引发异常的前提条件描述/变换后置条件异常的后置条件备注迭代的测试planned/completed/% in each cell引用/位置迭代1-乐观/简单迭代2-正常/中等迭代3-悲观/复杂单元测试操作单元测试类单元测试-组件集成测试系统测试end to end用户验收测试质量因素备注：可靠性、正确性、可扩展性、可重用性、可移植性、可维护性、可用性测试的益处有：l 支持尽早识别缺陷，从而降低改正缺陷的成本l 支持尽早识别风险和问题l 支持组件正确的交互作用和集成l 支持建立高质量、无缺陷的系统8 总结此项目计划是为了帮助所有项目成员为成功地完成项目，创建一个高质量的无缺陷的系统，满足客户需求而协同工作项目计划批准：_项目经理批准和日期体系结构师批准和日期批准和日期9 附录 创建一个完整uml模型要进行的工作9.1 业务建模（business modeling）