UML项目计划.docx
《UML项目计划.docx》由会员分享,可在线阅读,更多相关《UML项目计划.docx(36页珍藏版)》请在冰豆网上搜索。
UML项目计划
UML项目计划
这个项目计划的目的是为你提供一个项目计划模板。
在项目中有大量的模板和表格需要你来填写,以记录项目的信息、估计等。
本文的最重要的参考文献是《RationalUnifiedProcess?
中文版V》。
为了针对你的项目更新这个计划,你需要:
将项目名字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?
中文版V》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视图和问题的简要评述