UML项目计划.docx

1、UML项目计划UML项目计划那个项目打算的目的是为你提供一个项目打算模板。在项目中有大量的模板和表格需要你来填写，以记录项目的信息、估量等。本文的最重要的参考文献是Rational Unified Process 中文版 V 2000.02.20。为了针对你的项目更新那个打算，你需要：将项目名字OO项目改为你的项目名称；依照你的项目的信息填写各种模板表格；更新本文档以反映你的项目的打算和策略；依照项目组成员的反馈进行改进，将批准后的项目打算放入一个共享名目；执行打算，并监控项目的进行我们的目标是：那个项目打算将辅助所有的项目组成员朝成功完成项目的目标共同前进，制造高质量的软件产品。1引言一个O

2、O项目是由一系列围绕一个目标或目的的唯独的、复杂的和相互联系的活动组成，同时必须在规定的时刻完成，同时满足预算要求和符合合同规定的技术规范要求。一个项目的关键问题见下图。增加在三角形中间的“Scope and Quality”会增加“Cost”、“Time”和“Resources”.OO项目治理与非OO项目治理相比，关键的问题包括：在范畴规模/抽象的各种层次上进行打算和监控：企业业务层次、项目系统层次、构造/公布层次使用RUP时期模型：初始时期定义、精化时期打算、构造时期建模/编码、产品化时期向最终用户部署产品使用RUP为每个构造/公布项创建下列模型：需求、分析、设计、实现和测试使用UML元素

3、和语义使用面向对象的规模、复杂性和质量度量Grady Booch在对象-SolutionsManaging the 对象-Oriented Project中说：“软件治理小组的中心任务是平稳一组不完整、不一致和不断变化的技术和非技术需求，以产生一个对最本质的最小功能集最优的系统。”Booch还讲到：“一个成功的软件项目应该是：它的交付项满足同时可能超过最终用户的期望、它是以一种省时经济的方式被开发的，同时对变更和改变是有弹性的。”项目治理包含打算、进度安排、人员组织、资源配置和执行情形的监控，以产生一个高质量的系统。“更好、更快、更廉价。”Grady Booch在对象-SolutionsMan

4、aging the 对象-Oriented Project中说：“一个成功的OO项目有5中适应，包括：不留情面地用心于开发一个能提供被良好明白得的本质的最小功能集的系统.存在一种文化：以结果为中心、鼓舞性的交流沟通和不怕失败有效地使用面向对象建模技术有一个强壮的体系结构项目视图应用一个被良好治理的迭代增量开发声明周期。”Philippe Kruchten在The Rational Unified Process An Introduction Second Edition中为支持有效的软件工程提供了解决方案：迭代地开发软件治理需求使用基于组件的体系结构验证软件的质量操纵软件的变更下面是参考文献

5、和标准：Rational Unified Process 中文版 V 2000.02.20 Rational Software CorporationOMG Unified Modeling Language Specification v1.3 First Edition: March 20002企业级打算和监控OO项目系统应依照规模/抽象的层次进行建模。对整个企业来说明白OO项目处在何处是专门重要的。规模/抽象的层次级别层次级别定义UML例子OO项目全局关注阻碍多个企业的语言、标准、政策InternetANSI和IEEE标准企业有多个系统的组织XYZ公司全部的系统应用程序组需求观点：行动者

6、和系统实现观点：组件需求：行动者+系统实现：组件Office 2000包括OO项目在内的整个系统系统/子系统/组件应用程序成组的类作为一个系统或应用一起工作系统包或组件Word 2000OO项目系统包成组的类包标签盒子协作为一个特定的目的一起动作的成组的类实现一种模式协作图虚线椭圆类定义一组对象类Document属性操作属性值操作服务属性操作Document.Name Document.Open()期望OO项目系统成为大系统的一个组件是基于如下的理由：设置OO项目系统的边界促进精确的交流来了解规模/抽象的层次便于为OO项目系统指定责任和组件的交互假如组件接口被清晰地定义了，能够加速开发3企业级

7、业务建模业务建模（Business Modeling ）是对整个企业进行建模。对OO项目来说支持企业地短期和长期目标，并能适当地拟合企业是重要的。业务建模有下列产出：Vision文档、组织结构图、业务事件和流程(Use Case)、业务行动者、工作者和实体(Domain Model)、商业规则名目、业务接口（操作的集合）、业务模式、业务系统体系结构、组件图和词汇表。业务模型关键的UML元素业务流程(Use Case)、业务领域对象对象s关键任务对业务建模目标充分的业务/企业信息静态/结构图业务领域对象动态/基于时刻的图业务流程(Use Case)工具ROSE、需求跟踪工具关键角色业务/系统分析

8、员、体系结构师模型验收项目经理，体系结构师、客户/用户下面是一张企业业务建模的状态表。企业业务模型位置-引用编号备注业务模型业务事件业务行动者、工作者、实体业务接口业务模式业务词汇表体系结构组件业务建模的好处有：支持定义好的需求，从而导致快速、有效的系统开发。支持创建正确、可靠、可扩展的和可重用的系统支持交流、一致性和减少冗余4基于组件开发（CBD）的系统体系结构OO项目系统是一个更大的由组件组成的企业级系统的一部分。基于组建的开发（组件-based developmentCBD）是创建和部署通过组件组装而成的软件系统，同时要开发和实现这些组件，通常需要建立一个分层的组件体系结构。Kruche

9、n 在The Rational Unified Process An Introduction Second Edition定义体系结构为：“体系结构涵盖对下面问题的重要的决定：一个软件系统的组织结构；组成系统的结构化元素的选择集合和它们的接口，以及这些元素相互协作所需要的行为；将这些元素渐进地组装进更大的系统的合成过程；指导那个组织结构、元素、接口、元素之间的协作关系和合成方式的体系结构风格。”体系结构指一个系统的组织结构，包括它分解成部件、部件间的连接、交互机制和关于系统设计的指导性原则。UML组件图显示了具有接口的组件。一个接口（interface）是一个没有实现的操作的集合。基于组件的

10、开发方式的益处有：通过组件替换，支持开发高度可升级、可修改的系统通过良好定义的接口，支持通讯通过定义可重用的组件，支持重用支持一个高度柔性的系统体系结构，支持使用标准化的组件框架，如COM+、CORBA、EJB等等支持使用第三方商业组件为配置治理和版本治理提供了一个自然的基础5项目打算和监控5.1项目目标和概述OO项目应该设计、构造和公布与OO项目需求一致的OO项目系统。目标是创建一个正确、可靠、容易明白得、可扩展和重用的系统。系统必须满足所有功能性需求，例如各种特性（使用Use Case建模）。系统必须满足以下的非功能性需求：可用性、可靠性、性能和支持能力。描述或位置备注项目名称项目描述项目

11、目标项目功能性需求文档项目非功能性需求文档项目约束项目假设项目标准UML、编码标准、其他 (错误处理、线程)企业业务模型项目工作指南见附录项目原型、标签值和约束见附录项目UML模型示例见附录项目文档见工件总结（附录B）项目工具使用指导、CD、书籍、培训项目词汇表项目重用库组件、类、操作、模式等项目UML模型复查每两周或在每个迭代终止时进行定义项目目标的好处有：使项目成员、客户和其他人员在共同的基础上进行沟通支持在项目打算和实际进展之间进行比较，并识别潜在的问题使项目成员集中在实现项目目标的活动上，提高项目效率能够有效地安排和设置为实现项目目标需要进行的活动和它们的优先顺序5.2项目风险风险是正

12、在进行或迫近的对要紧里程碑的实现有重要负面阻碍的因素。假如风险产生，那么对项目而言必定在成本、进度或系统性能等方面存在负面因素。Booch在对象 Solutions 讲到：“什么是任何实际的项目都面临的最严峻的风险因素？包括：不准确的测量尺度不充分的测量过度的进度压力治理失误不准确的成本估量银弹综合症蠕变的用户需求低质量低生产率取消的项目”为了保证我们能实现项目目标，OO项目应识别和监控所有要紧的风险。我们必须预备和幸免灾难性的“惊奇”和未期待的事件。OO项目已打算的风险如下：风险名称描述发生的可能性阻碍规避打算发生时的应变方案备注数据库未按时交付10%延迟项目按月监控定义项目风险的益处有：支

13、持有效的打算，幸免“惊奇”提高项目成功的概率支持有效的决策5.3项目时期和进度安排OO项目应遵循RUP中描述的统一软件开发过程。 这是一个迭代增量开发过程，强调渐进地交付一个复杂软件系统的交付项（builds/releases）。每个时期（phase） 是两个要紧里程碑之间的时刻跨度，例如先启、精化、构建和产品化。RUP时期化分对一个52周的项目的按周时期化分示例先启时期-5周精化时期-16周构建时期-26周产品化时期-5周描述定义项目的范畴和商业案例打算项目，指定特性和建立体系结构基线构造项目。软件从体系结构基线进展到能够向用户交付的程度将软件交到用户的手中产品项目视图文档、USE CASE

14、列表、项目词汇表、商业案例（商业环境、成功标准、赢利推测）、风险评估、项目打算、业务模型USE CASE模型、非功能性需求、软件体系结构、体系结构原型、迭代打算、开发案例、初步的用户手册UML模型（需求、分析、设计、实现、测试）、每次迭代的交付项（Build/Release）推向市场或交给用户的软件产品时刻估量10%5周30%16周50%26周2-3周/迭代10%5周资源估量5% 20% 65%10%关键角色项目经理、体系结构师、业务/系统分析员项目经理、体系结构师、业务/系统分析员项目经理、体系结构师、业务/系统分析员、程序员、测试员项目经理、体系结构师里程碑生命周期目标里程碑生命周期构架里

15、程碑最初操作性能里程碑产品公布里程碑拥有良好定义的项目时期划分的好处有：支持拥有一个良好治理的项目支持沟通，使客户和项目成员了解项目的进展支持在项目打算和实际进展之间的比较测量，尽早发觉问题5.4项目人员组成OO项目应由完成下列角色职能的人员组成：项目经理、体系结构师、业务/系统分析员、程序员、测试人员和其他需要的人员。每个角色的职责如下：项目经理治理项目的所有方面，包括进度、资源、人力等等，以实现项目的目标和交付合格的软件产品。体系结构师监督项目的技术方面，包括整个系统的体系结构、组件、组件的接口和组件之间的通讯。对开发和部署的基础结构（infrastructure）负责。提供过程环境（硬件

16、和软件配置清单）和实现模型（组件图和部署图）。方法师/工具专家监督指导UML 和RUP的使用。负责保证UML模型的正确性和完整性。提供UML、RUP和CASE工具的使用关心。创建用来形成报告和生成代码的CASE工具脚本。客户/用户提供用户的观点，作为行业领域专家参与项目开发工作。业务/系统分析员领导和和谐在业务建模、需求、和分析模型工作中的需求收集、USE CASE建模和类建模。开发人员/程序员创建所有在设计模型中的UML视图、规格说明和代码。QA 测试员创建测试打算、测试用例、测试过程和相关的测试文档。执行测试并提供测试用例结果。人员需求和角色指派对一个52周的项目的按周时期化分示例角色先启

17、时期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为项目成员规定良好定义的角色的益处有：支持有效的打算和决策支持沟通，使项目成员明白他们的职责通过不同的项目成员从不同角度工作，支持创建一个质量系统5.5项目资源资源必须被识别、预算和操纵包括人力资源和其他资源，如工具、设备等。资源要

18、求/批准/使用对一个52周的项目的按周时期化分示例资源类别先启时期5周精化时期16周构建时期26周产品化时期5周 人力服务软件设备交通通讯其他总计有良好定义的资源规划的益处有：支持有效的项目打算和决策支持沟通，以识别需要的资源支持创建一个质量系统和中意的客户5.6项目配置治理和版本操纵项目配置治理的目标是跟踪和爱护不断演化的项目资产的完整性。这些项目资产必须可被重用。有三种独立的功能：配置治理处理工件识别、版本和依靠关系方面的问题变更要求治理处理工件中被要求的变更的捕捉和治理方面的问题状态和测量处理项目操纵信息方面的问题项目资产和文档工件负责人位置当前版本/日期工具备注配置治理和版本操纵的益处

19、在于：支持沟通，以使项目成员使用最新的版本工作通过减少重复劳动提高效率支持创建一个质量系统，其所有部分专门好地相互适合5.7项目需求OO项目应爱护一个最新的需求文档和一个需求跟踪表（Requirements Trace ability Table）。需求跟踪表 (Partial)需求编号需求名称引用 Use Case名称UML元素测试用例 描述 负责人1.1 DepositToSavings AccountDepositToSavingsAccount有良好定义的项目需求的益处有：支持沟通，使项目成员为实现需求而工作支持定义Use Case、Use Case 增量 和build/release

20、 迭代(在一个增量内的Use Case 场景)支持识别和解决在需求中的不一致性问题支持创建一个质量系统，它完全满足客户需求6迭代打算和监控OO项目应使用RUP中定义的迭代增量软件开发过程。 一个Use Case增量（Use Case Increment）是一个Use Case的集合，它表示了一个与其他增量差不多不相关的业务功能的完整子集。一个Use Case场景（Use Case场景）是一个Use Case的一系列交互，例如 乐观的（简单）、正常（中等）或悲观的 (复杂) 场景。 一个迭代（iteration）是具有已建立的打算和评估标准的一个活动序列，它执行的结果是一个可执行的公布。它完整地

21、经历整个软件开发过程的各个时期，例如对一个Use Case增量的需求、分析、设计、实现和测试，得到一个可执行的公布项。一个产品公布（product release）是一个完整和一致的工件的集合，包括一个软件构造（software build系统的一个可执行版本）。6.1Use Case 增量和Build/Release 迭代OO项目由多个Use Case增量组成。每个 Use Case增量包含多个build/release迭代。每个迭代通常需要34个星期。具体步骤如下：1识别所有的Use Case (name only)2将Use Case分组，形成Use Case 增量3在每个Use Cas

22、e增量内，定义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 Cas

23、e 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 Depos

24、it，Saving WithdrawDeposit and Withdraw 乐观/简单CheckingDepositOptimisticCheckingWithdrawOptimisticSavingDepositOptimisticSavingWithdrawOptimisticDeposit and Withdraw 正常/中等CheckingDepositNormalCheckingWithdrawNormalSavingDepositNormalSavingWithdrawNormalDeposit and Withdraw 悲观/复杂CheckingDepositPessimist

25、icCheckingWithdrawPessimisticSavingDepositPessimisticSavingWithdrawPessimisticInquiries and TransfersChecking Inquiry，Checking Transfer，Saving Inquiry，Saving TransferInquiries and Transfers 乐观/简单CheckingInquiryOptimisticCheckingTransferOptimisticSavingInquiryOptimisticSavingTransferOptimisticInquiri

26、es and Transfers 正常/中等CheckingInquiryNormalCheckingTransferNormalSavingInquiryNormalSavingTransferNormalInquiries and Transfers 悲观/复杂CheckingInquiryPessimisticCheckingTransferPessimisticSavingInquiryPessimisticSavingTransferPessimisticOverdraftsCheckingOverdraft，SavingOverdraftOverdraft 乐观/简单Checkin

27、gOverdraftOptimisticSavingOverdraftOptimisticOverdraft 正常/中等CheckingOverdraftOptimisticSavingOverdraftNormalOverdraft 悲观/复杂CheckingOverdraftOptimisticSavingOverdraftPessimistic对每个Build/Release 迭代，下面是打算和监控表。 UML模型是当前模型的位置，例如XYZF:UMLModelsIteration1Model.mdl.OO项目进度状态表迭代1-乐观/简单迭代2-正常/中等迭代3-悲观/复杂UML模型打算开始日期修订的开始日期实际开始日期打算完成日期修订的完成日期实际完成/复查日期目前完成百分比（%）模型复审日期构造批准日期备注UML模型的复审每两周进行一次或在每个迭代终止时进行。周期性的，我们能够打算安排在一个迭代内部对需求、分析、设计和实现进行复审。所有UML视图和规格说明应被放置在姓名名目中，同时使所有项目复审和评论人员能够获得。每个迭代的源代码和测试结果也应使所有项目复审和评论人员能够获得。模型复审应包含对要紧的UML视图和问题的简要评述。使用Use Case增量和build/release迭代的好处有：支持有效的打算和决策，“一点一点”而不是“一次完