UML项目计划.docx
《UML项目计划.docx》由会员分享，可在线阅读，更多相关《UML项目计划.docx（36页珍藏版）》请在冰点文库上搜索。
UML项目计划
UML项目计划
那个项目打算的目的是为你提供一个项目打算模板。
在项目中有大量的模板和表格需要你来填写，以记录项目的信息、估量等。
本文的最重要的参考文献是《RationalUnifiedProcess 中文版V2000.02.20》。
为了针对你的项目更新那个打算，你需要：
●将项目名字OO项目改为你的项目名称；
●依照你的项目的信息填写各种模板表格；
●更新本文档以反映你的项目的打算和策略；
●依照项目组成员的反馈进行改进，将批准后的项目打算放入一个共享名目；
●执行打算，并监控项目的进行
我们的目标是：
那个项目打算将辅助所有的项目组成员朝成功完成项目的目标共同前进，制造高质量的软件产品。
1引言
一个OO项目是由一系列围绕一个目标或目的的唯独的、复杂的和相互联系的活动组成，同时必须在规定的时刻完成，同时满足预算要求和符合合同规定的技术规范要求。
一个项目的关键问题见下图。
增加在三角形中间的“ScopeandQuality”会增加“Cost”、“Time”和“Resources”.
OO项目治理与非OO项目治理相比，关键的问题包括：
●在范畴规模/抽象的各种层次上进行打算和监控：
企业——业务层次、项目——系统层次、构造/公布层次
●使用RUP时期模型：
初始时期——定义、精化时期——打算、构造时期——建模/编码、产品化时期——向最终用户部署产品
●使用RUP为每个构造/公布项创建下列模型：
需求、分析、设计、实现和测试
●使用UML元素和语义
●使用面向对象的规模、复杂性和质量度量
GradyBooch在对象-Solutions–Managingthe对象-OrientedProject中说：
“软件治理小组的中心任务是平稳一组不完整、不一致和不断变化的技术和非技术需求，以产生一个对最本质的最小功能集最优的系统。
”
Booch还讲到：
“一个成功的软件项目应该是：
它的交付项满足同时可能超过最终用户的期望、它是以一种省时经济的方式被开发的，同时对变更和改变是有弹性的。
”
项目治理包含打算、进度安排、人员组织、资源配置和执行情形的监控，以产生一个高质量的系统。
“更好、更快、更廉价。
”
GradyBooch在对象-Solutions–Managingthe对象-OrientedProject中说：
“一个成功的OO项目有5中适应，包括：
●不留情面地用心于开发一个能提供被良好明白得的本质的最小功能集的系统.
●存在一种文化：
以结果为中心、鼓舞性的交流沟通和不怕失败
●有效地使用面向对象建模技术
●有一个强壮的体系结构项目视图
●应用一个被良好治理的迭代增量开发声明周期。
”
PhilippeKruchten在TheRationalUnifiedProcessAnIntroductionSecondEdition中为支持有效的软件工程提供了解决方案：
●迭代地开发软件
●治理需求
●使用基于组件的体系结构
●验证软件的质量
●操纵软件的变更
下面是参考文献和标准：
●《RationalUnifiedProcess 中文版V2000.02.20》RationalSoftwareCorporation
●《OMGUnifiedModelingLanguageSpecificationv1.3》FirstEdition:
March2000
2企业级打算和监控
OO项目系统应依照规模/抽象的层次进行建模。
对整个企业来说明白OO项目处在何处是专门重要的。
规模/抽象的层次级别
层次级别
定义
UML
例子
OO项目
全局
关注阻碍多个企业的语言、标准、政策
Internet–ANSI和IEEE标准
企业
有多个系统的组织
XYZ公司
全部的系统——应用程序组
需求观点：
行动者和系统
实现观点：
组件
需求：
行动者+系统
实现：
组件
Office2000
包括OO项目在内的整个系统
系统/子系统/组件——应用程序
成组的类作为一个系统或应用一起工作
系统包或组件
Word2000
OO项目系统
包
成组的类
包——标签盒子
协作
为一个特定的目的一起动作的成组的类——实现一种模式
协作图——虚线椭圆
类
定义一组对象
类
Document
属性——操作
属性——值
操作——服务
属性——操作
Document.Name
Document.Open（）
期望OO项目系统成为大系统的一个组件是基于如下的理由：
●设置OO项目系统的边界
●促进精确的交流来了解规模/抽象的层次
●便于为OO项目系统指定责任和组件的交互
●假如组件接口被清晰地定义了，能够加速开发
3企业级业务建模
业务建模（BusinessModeling）是对整个企业进行建模。
对OO项目来说支持企业地短期和长期目标，并能适当地拟合企业是重要的。
业务建模有下列产出：
Vision文档、组织结构图、业务事件和流程（UseCase）、业务行动者、工作者和实体（DomainModel）、商业规则名目、业务接口（操作的集合）、业务模式、业务系统体系结构、组件图和词汇表。
业务模型
关键的UML元素
业务流程（UseCase）、业务领域对象对象s
关键任务
对业务建模
目标
充分的业务/企业信息
静态/结构图
业务领域对象
动态/基于时刻的图
业务流程（UseCase）
工具
ROSE、需求跟踪工具
关键角色
业务/系统分析员、体系结构师
模型验收
项目经理，体系结构师、客户/用户
下面是一张企业业务建模的状态表。
企业业务模型
位置-引用
编号
备注
业务模型
业务事件
业务行动者、工作者、实体
业务接口
业务模式
业务词汇表
体系结构——组件
业务建模的好处有：
●支持定义好的需求，从而导致快速、有效的系统开发。
●支持创建正确、可靠、可扩展的和可重用的系统
●支持交流、一致性和减少冗余
4基于组件开发（CBD）的系统体系结构
OO项目系统是一个更大的由组件组成的企业级系统的一部分。
基于组建的开发（组件-baseddevelopment——CBD）是创建和部署通过组件组装而成的软件系统，同时要开发和实现这些组件，通常需要建立一个分层的组件体系结构。
Kruchen在TheRationalUnifiedProcessAnIntroductionSecondEdition定义体系结构为：
“体系结构涵盖对下面问题的重要的决定：
●一个软件系统的组织结构；
●组成系统的结构化元素的选择集合和它们的接口，以及这些元素相互协作所需要的行为；
●将这些元素渐进地组装进更大的系统的合成过程；
●指导那个组织结构、元素、接口、元素之间的协作关系和合成方式的体系结构风格。
”
体系结构指一个系统的组织结构，包括它分解成部件、部件间的连接、交互机制和关于系统设计的指导性原则。
UML组件图显示了具有接口的组件。
一个接口（interface）是一个没有实现的操作的集合。
基于组件的开发方式的益处有：
●通过组件替换，支持开发高度可升级、可修改的系统
●通过良好定义的接口，支持通讯
●通过定义可重用的组件，支持重用
●支持一个高度柔性的系统体系结构，
●支持使用标准化的组件框架，如COM+、CORBA、EJB等等
●支持使用第三方商业组件
●为配置治理和版本治理提供了一个自然的基础
5项目打算和监控
5.1项目目标和概述
OO项目应该设计、构造和公布与OO项目需求一致的OO项目系统。
目标是创建一个正确、可靠、容易明白得、可扩展和重用的系统。
系统必须满足所有功能性需求，例如各种特性（使用UseCase建模）。
系统必须满足以下的非功能性需求：
可用性、可靠性、性能和支持能力。
描述或位置
备注
项目名称
项目描述
项目目标
项目功能性需求文档
项目非功能性需求文档
项目约束
项目假设
项目标准
UML、编码标准、其他（错误处理、线程）
企业业务模型
项目工作指南
见附录
项目原型、标签值和约束
见附录
项目UML模型示例
见附录
项目文档
见工件总结（附录B）
项目工具
使用指导、CD、书籍、培训
项目词汇表
项目重用库
组件、类、操作、模式等
项目UML模型复查
每两周或在每个迭代终止时进行
定义项目目标的好处有：
●使项目成员、客户和其他人员在共同的基础上进行沟通
●支持在项目打算和实际进展之间进行比较，并识别潜在的问题
●使项目成员集中在实现项目目标的活动上，提高项目效率
●能够有效地安排和设置为实现项目目标需要进行的活动和它们的优先顺序
5.2项目风险
风险是正在进行或迫近的对要紧里程碑的实现有重要负面阻碍的因素。
假如风险产生，那么对项目而言必定在成本、进度或系统性能等方面存在负面因素。
Booch在对象Solutions讲到：
“什么是任何实际的项目都面临的最严峻的风险因素？
包括：
●不准确的测量尺度
●不充分的测量
●过度的进度压力
●治理失误
●不准确的成本估量
●银弹综合症
●蠕变的用户需求
●低质量
●低生产率
●取消的项目”
为了保证我们能实现项目目标，OO项目应识别和监控所有要紧的风险。
我们必须预备和幸免灾难性的“惊奇”和未期待的事件。
OO项目已打算的风险如下：
风险名称
描述
发生的可能性
阻碍
规避打算
发生时的应变方案
备注
数据库未按时交付
10%
延迟项目
按月监控
定义项目风险的益处有：
●支持有效的打算，幸免“惊奇”
●提高项目成功的概率
●支持有效的决策
5.3项目时期和进度安排
OO项目应遵循RUP中描述的统一软件开发过程。
这是一个迭代增量开发过程，强调渐进地交付一个复杂软件系统的交付项（builds/releases）。
每个时期（phase）是两个要紧里程碑之间的时刻跨度，例如先启、精化、构建和产品化。
RUP时期化分
对一个52周的项目的按周时期化分示例
先启时期-5周
精化时期-16周
构建时期-26周
产品化时期-5周
描述
定义项目的范畴和商业案例
打算项目，指定特性和建立体系结构基线
构造项目。
软件从体系结构基线进展到能够向用户交付的程度
将软件交到用户的手中
产品
项目视图文档、USECASE列表、项目词汇表、商业案例（商业环境、成功标准、赢利推测）、风险评估、项目打算、业务模型
USECASE模型、非功能性需求、软件体系结构、体系结构原型、迭代打算、开发案例、初步的用户手册
UML模型（需求、分析、设计、实现、测试）、每次迭代的交付项（Build/Release）
推向市场或交给用户的软件产品
时刻估量
10%–5周
30%–16周
50%–26周
2-3周/迭代
10%–5周
资源估量
5%
20%
65%
10%
关键角色
项目经理、体系结构师、业务/系统分析员
项目经理、体系结构师、业务/系统分析员
项目经理、体系结构师、业务/系统分析员、程序员、测试员
项目经理、体系结构师
里程碑
生命周期目标里程碑
生命周期构架里程碑
最初操作性能里程碑
产品公布里程碑
拥有良好定义的项目时期划分的好处有：
●支持拥有一个良好治理的项目
●支持沟通，使客户和项目成员了解项目的进展
●支持在项目打算和实际进展之间的比较测量，尽早发觉问题
5.4项目人员组成
OO项目应由完成下列角色职能的人员组成：
项目经理、体系结构师、业务/系统分析员、程序员、测试人员和其他需要的人员。
每个角色的职责如下：
项目经理–治理项目的所有方面，包括进度、资源、人力等等，以实现项目的目标和交付合格的软件产品。
体系结构师–监督项目的技术方面，包括整个系统的体系结构、组件、组件的接口和组件之间的通讯。
对开发和部署的基础结构（infrastructure）负责。
提供过程环境（硬件和软件配置清单）和实现模型（组件图和部署图）。
方法师/工具专家–监督指导UML和RUP的使用。
负责保证UML模型的正确性和完整性。
提供UML、RUP和CASE工具的使用关心。
创建用来形成报告和生成代码的CASE工具脚本。
客户/用户–提供用户的观点，作为行业领域专家参与项目开发工作。
业务/系统分析员–领导和和谐在业务建模、需求、和分析模型工作中的需求收集、USECASE建模和类建模。
开发人员/程序员–创建所有在设计模型中的UML视图、规格说明和代码。
QA测试员–创建测试打算、测试用例、测试过程和相关的测试文档。
执行测试并提供测试用例结果。
人员需求和角色指派
对一个52周的项目的按周时期化分示例
角色
先启时期–5周
精化时期–16周
构建时期–26周
产品化时期–5周
项目经理
1–JohnSmith
1–JohnSmith
1–JohnSmith
1–JohnSmith
体系结构师
1–?
?
?
1–?
?
?
1–?
?
?
1–?
?
?
客户/用户
1–?
?
?
1–?
?
?
1–?
?
?
1–?
?
?
业务/系统分析员
3–?
?
?
，?
?
?
，?
?
?
3–?
?
?
，?
?
?
，?
?
?
3–?
?
?
，?
?
?
，?
?
?
0
开发人员/程序员
0
3–?
?
?
，?
?
?
，?
?
?
3–?
?
?
，?
?
?
，?
?
?
1–?
?
?
QA测试员
0
1–?
?
?
1–?
?
?
1–?
?
?
其他
TBD
TBD
TBD
TBD
合计
6
10
10
5
为项目成员规定良好定义的角色的益处有：
●支持有效的打算和决策
●支持沟通，使项目成员明白他们的职责
●通过不同的项目成员从不同角度工作，支持创建一个质量系统
5.5项目资源
资源必须被识别、预算和操纵——包括人力资源和其他资源，如工具、设备等。
资源要求/批准/使用
对一个52周的项目的按周时期化分示例
资源类别
先启时期–5周
精化时期–16周
构建时期–26周
产品化时期–5周
人力
服务
软件
设备
交通
通讯
其他
总计
有良好定义的资源规划的益处有：
●支持有效的项目打算和决策
●支持沟通，以识别需要的资源
●支持创建一个质量系统和中意的客户
5.6项目配置治理和版本操纵
项目配置治理的目标是跟踪和爱护不断演化的项目资产的完整性。
这些项目资产必须可被重用。
有三种独立的功能：
●配置治理处理工件识别、版本和依靠关系方面的问题
●变更要求治理处理工件中被要求的变更的捕捉和治理方面的问题
●状态和测量处理项目操纵信息方面的问题
项目资产和文档
工件
负责人
位置
当前版本/日期
工具
备注
配置治理和版本操纵的益处在于：
●支持沟通，以使项目成员使用最新的版本工作
●通过减少重复劳动提高效率
●支持创建一个质量系统，其所有部分专门好地相互适合
5.7项目需求
OO项目应爱护一个最新的需求文档和一个需求跟踪表（RequirementsTraceabilityTable）。
需求跟踪表（Partial）
需求编号
需求名称
引用
UseCase名称
UML元素
测试用例
描述
负责人
1.1
DepositToSavingsAccount
DepositToSavingsAccount
有良好定义的项目需求的益处有：
●支持沟通，使项目成员为实现需求而工作
●支持定义UseCase、UseCase增量和build/release迭代（在一个增量内的UseCase场景）
●支持识别和解决在需求中的不一致性问题
●支持创建一个质量系统，它完全满足客户需求
6迭代打算和监控
OO项目应使用RUP中定义的迭代增量软件开发过程。
一个UseCase增量（UseCaseIncrement）是一个UseCase的集合，它表示了一个与其他增量差不多不相关的业务功能的完整子集。
一个UseCase场景（UseCase场景）是一个UseCase的一系列交互，例如乐观的（简单）、正常（中等）或悲观的（复杂）场景。
一个迭代（iteration）是具有已建立的打算和评估标准的一个活动序列，它执行的结果是一个可执行的公布。
它完整地经历整个软件开发过程的各个时期，例如对一个UseCase增量的需求、分析、设计、实现和测试，得到一个可执行的公布项。
一个产品公布（productrelease）是一个完整和一致的工件的集合，包括一个软件构造（softwarebuild——系统的一个可执行版本）。
6.1UseCase增量和Build/Release迭代
OO项目由多个UseCase增量组成。
每个UseCase增量包含多个build/release迭代。
每个迭代通常需要3–4个星期。
具体步骤如下：
1–识别所有的UseCase（nameonly）
2–将UseCase分组，形成UseCase增量
3–在每个UseCase增量内，定义build/release迭代
4–在每个build/release迭代中，识别所有的UseCase场景（nameonly）
OO项目增量/迭代打算（3–4周的迭代周期）
增量名称
UseCase
Build/Release迭代
UseCase场景
Increment1
UseCase1，2，3
迭代1乐观/简单，
迭代2正常/中等，
迭代3悲观/复杂
迭代1乐观/简单:
UC1Opt，UC2Opt，UC3Opt
迭代2正常/中等:
UC1Nor，UC2Nor，UC3Nor
迭代3悲观/复杂:
UC1Pess，UC2Pess，UC3Pess
Increment2
UseCase3，4，5
Iteration4乐观/简单，
Iteration5正常/中等，
Iteration6悲观/复杂
Iteration4乐观/简单:
UC4Opt，UC5Opt，UC6Opt
Iteration5正常/中等:
UC4Nor，UC5Nor，UC6Nor
Iteration6悲观/复杂:
UC4Pess，UC5Pess，UC6Pess
下面是增量/迭代打算的一个例子
增量名称
UseCase
Build/Release迭代
UseCase场景
DepositsandWithdraws
CheckingDeposit，
CheckingWithdraw，
SavingDeposit，
SavingWithdraw
DepositandWithdraw乐观/简单
CheckingDepositOptimistic
CheckingWithdrawOptimistic
SavingDepositOptimistic
SavingWithdrawOptimistic
DepositandWithdraw正常/中等
CheckingDepositNormal
CheckingWithdrawNormal
SavingDepositNormal
SavingWithdrawNormal
DepositandWithdraw悲观/复杂
CheckingDepositPessimistic
CheckingWithdrawPessimistic
SavingDepositPessimistic
SavingWithdrawPessimistic
InquiriesandTransfers
CheckingInquiry，
CheckingTransfer，
SavingInquiry，
SavingTransfer
InquiriesandTransfers乐观/简单
CheckingInquiryOptimistic
CheckingTransferOptimistic
SavingInquiryOptimistic
SavingTransferOptimistic
InquiriesandTransfers正常/中等
CheckingInquiryNormal
CheckingTransferNormal
SavingInquiryNormal
SavingTransferNormal
InquiriesandTransfers悲观/复杂
CheckingInquiryPessimistic
CheckingTransferPessimistic
SavingInquiryPessimistic
SavingTransferPessimistic
Overdrafts
CheckingOverdraft，
SavingOverdraft
Overdraft乐观/简单
CheckingOverdraftOptimistic
SavingOverdraftOptimistic
Overdraft正常/中等
CheckingOverdraftOptimistic
SavingOverdraftNormal
Overdraft悲观/复杂
CheckingOverdraftOptimistic
SavingOverdraftPessimistic
对每个Build/Release迭代，下面是打算和监控表。
UML模型是当前模型的位置，例如XYZ\F:
UMLModels\Iteration1Model.mdl.
OO项目进度状态表
迭代1-乐观/简单
迭代2-正常/中等
迭代3-悲观/复杂
UML模型
打算开始日期
修订的开始日期
实际开始日期
打算完成日期
修订的完成日期
实际完成/复查日期
目前完成百分比（%）
模型复审日期
构造批准日期
备注
UML模型的复审每两周进行一次或在每个迭代终止时进行。
周期性的，我们能够打算安排在一个迭代内部对需求、分析、设计和实现进行复审。
所有UML视图和规格说明应被放置在姓名名目中，同时使所有项目复审和评论人员能够获得。
每个迭代的源代码和测试结果也应使所有项目复审和评论人员能够获得。
模型复审应包含对要紧的UML视图和问题的简要评述。
使用UseCase增量和build/release迭代的好处有：
●支持有效的打算和决策，“一点一点”而不是“一次完
升级会员 