基于RUP软件开发规范.docx
《基于RUP软件开发规范.docx》由会员分享，可在线阅读，更多相关《基于RUP软件开发规范.docx（66页珍藏版）》请在冰豆网上搜索。
基于RUP软件开发规范
基于RUP软件开发规范
部门批准人
批准日期
公司批准人
批准日期
目录
1概述6
2角色与活动6
2.1项目经理6
2.2构架设计师7
2.3系统分析员7
2.4用户界面设计员8
2.5数据库设计员8
2.6系统设计员8
2.7实施员9
2.8测试员9
2.9部署经理9
3需求调研分析规范10
3.1需求调研规范10
3.1.1需求调研人员10
3.1.2需求调研方法10
3.1.3需求调研工件11
3.2需求分析规范11
3.2.1业务建模规范11
3.2.1.1业务建模目的11
3.2.1.2业务建模活动概述11
3.2.1.3业务建模工件17
3.2.2需求分析规范17
3.2.2.1需求分析目的17
3.2.2.2需求分析活动概述17
目的：
17
步骤：
17
目的：
18
步骤：
18
目的：
19
步骤：
20
目的：
22
步骤：
22
3.2.2.3需求分析工件24
4分析设计规范24
4.1分析设计目的24
4.2分析设计活动概述25
4.2.1构架分析25
目的：
25
步骤：
25
4.2.2确定设计机制27
目的：
27
步骤：
27
4.2.3确定设计元素28
目的：
28
步骤：
28
4.2.4合并现有设计元素30
目的：
30
步骤：
30
4.2.5说明运行时构架31
目的：
31
步骤：
32
4.2.6说明分布33
目的：
33
步骤：
33
4.2.7用例分析34
目的：
34
步骤：
34
4.2.8用例设计36
目的：
36
步骤：
36
4.2.9子系统设计38
目的：
38
步骤：
38
4.2.10类设计39
目的：
39
步骤：
39
4.2.11数据库设计42
目的：
42
步骤：
42
4.3分析设计工件44
5实施规范44
5.1实施目的44
5.2实施活动概述44
5.2.1建立实施模型44
目的：
44
步骤：
44
5.2.3实施构件46
目的：
46
步骤：
46
5.2.4修复缺陷47
目的：
47
步骤：
47
5.2.5执行单元测试48
目的：
48
步骤：
48
5.2.6集成子系统48
目的：
48
步骤：
48
5.2.7集成系统49
目的：
49
步骤：
49
5.3实施工件49
6测试规范50
6.1测试目的50
6.2测试活动概述50
6.2.1制定测试计划50
目的：
50
步骤：
50
6.2.2设计测试51
目的：
51
步骤：
51
6.2.3设计测试包和测试类52
目的：
52
步骤：
52
6.2.4实施测试52
目的：
52
步骤：
53
6.2.5执行测试53
目的：
53
步骤：
53
6.3测试工件54
7部署规范54
7.1部署目的54
7.2部署活动概述54
7.2.1制定部署计划54
目的：
54
步骤：
55
7.2.2管理验收测试56
目的：
56
步骤：
56
7.2.3检验已生产的产品56
目的：
56
步骤：
56
7.2.4编写发布说明57
目的：
57
步骤：
57
7.2.5开发安装工件57
目的：
57
步骤：
57
7.2.6编写培训材料58
目的：
58
步骤：
58
7.3部署工件58
8配置与变更管理58
8.1配置与变更管理目的58
8.2配置与变更管理活动概述59
8.2.1编写CM计划59
目的：
59
步骤：
59
8.2.2创建部署单元59
目的：
59
步骤：
59
8.2.3报告配置状态60
目的：
60
步骤：
60
8.2.4执行配置审核60
目的：
60
步骤：
60
8.2.5建立变更控制流程60
目的：
60
步骤：
60
8.3配置与变更管理工件61
附件62
调研记录表62
用户视图清单63
1概述
该软件规范基于RUP2000制定的。
制定过程中考虑了XX事业部目前设计水平和能力，其中抽取了RUP中较为核心的活动，并结合了公司和部门以前的设计与开发经验。
该规范是作为XX事业部软件开发工作中必须依据的文件，详细的设计流程、活动和工件描述，参见RUP2000文件。
2角色与活动
2.1项目经理
●定义：
项目经理负责分配资源，确定优先级，协调与客户和用户之间的沟通。
总而言之，就是尽量使项目团队一直集中于正确的目标。
项目经理还要建立一套工作方法，以确保项目工件的完整性和质量。
●活动：
序号
活动名称
1.
确定监测与控制流程
2.
计划阶段和迭代
3.
制定评测计划
4.
定义项目组织和人员配备
5.
制定软件开发计划
6.
制定产品验收计划
7.
制定风险管理计划
8.
制定问题解决计划
9.
制定迭代计划
10.
人员配备
11.
启动迭代
12.
评估迭代
13.
为阶段收尾做准备
14.
为项目收尾做准备
15.
监测项目状态
16.
安排和分配工作
17.
报告状态
18.
处理异常事件和问题
19.
制定QA计划
2.2构架设计师
●定义：
构架设计师负责在整个项目中对技术活动和工件进行领导和协调。
构架设计师要确立每个构架视图的整体结构：
视图的详细组织结构、元素的分组以及这些主要分组之间的接口。
因此，与其他角色相比，构架设计师的见解重在广度，而不是深度。
●活动：
序号
活动名称
1.
确定用例的优先级
2.
构架分析
3.
确定设计机制
4.
确定设计元素
5.
合并现有设计元素
6.
说明分布
7.
说明运行时构架
8.
建立实施模型
9.
制定设计指南
10.
制定编程指南
2.3系统分析员
●定义：
系统分析员通过概括系统的功能和界定系统来领导和协调需求获取及用例建模。
例如，确定存在哪些主角和用例，以及他们之间如何交互。
●活动：
序号
活动名称
1.
制定需求管理计划
2.
制定用例建模指南
3.
获取常用词汇
4.
获取涉众请求
5.
确定前景
6.
查找主角和用例
7.
建立用例模型结构
8.
管理依赖关系
2.4用户界面设计员
●定义：
用户界面设计员通过以下方法领导和协调用户界面的原型设计和正式设计：
1、分析对用户界面的需求，包括可用性需求；
2、构建用户界面原型；
3、邀请用户界面的其他涉众（如最终用户）参与可用性复审和使用测试会议；
4、对用户界面的最终实施方案（由设计员和实施员等其他开发人员创建）进行复审并提供相应的反馈。
●活动：
序号
活动名称
1.
用户界面建模
2.
设计用户界面原型
3.
制定用户界面指南
2.5数据库设计员
●定义：
数据库设计员定义表、索引、视图、约束条件、触发器、存储过程、表空间或存储参数，以及其他在存储、检索和删除永久性对象时所需的数据库专用结构。
●活动：
序号
活动名称
1.
数据库设计
2.6系统设计员
●定义：
系统设计员定义一个或几个类的职责、操作、属性及关系，并确定应如何根据实施环境对它们加以调整。
此外，设计员可能要负责一个或多个设计包或设计子系统，其中包括设计包或子系统所拥有的所有类。
●活动：
序号
活动名称
1.
类的设计
2.
子系统设计
3.
用例分析
4.
用例设计
5.
设计测试包和测试类
2.7实施员
●定义：
实施员负责按照项目所采用的标准来进行构件开发与测试，以便将构件集成到更大的子系统中。
如果必须创建驱动程序或桩模块等测试构件来支持测试，那么实施员还要负责开发和测试这些测试构件及相应的子系统。
●活动：
序号
活动名称
1.
实施构件
2.
修复缺陷
3.
执行单元测试
4.
实施测试构件和子系统
5.
开发安装工件
2.8测试员
●定义：
测试员负责对测试进行计划、设计、实施和评估，包括：
生成测试计划和测试模型；执行测试过程；评估测试范围和测试结果，以及测试的有效性；生成测试评估摘要
●活动：
序号
活动名称
1.
制定测试计划
2.
设计测试
3.
实施测试
4.
评估测试
5.
制定测试指南
2.9部署经理
●定义：
部署经理负责制定向用户群体发布产品的计划，并将其纳入布署计划中。
●活动：
序号
活动名称
1.
制定部署计划
2.
定义材料清单
3.
管理验收测试
4.
管理Beta测试
5.
编写发布说明
6.
提供下载站点
7.
发布以进行生产
8.
检验已生产的产品
3需求调研分析规范
3.1需求调研规范
3.1.1需求调研人员
参加需求调研的人员，一般由开发方需求调研人员和相关配合人员组成。
需求调研人员：
应该善于简化工作，并且具有良好的沟通技巧。
担任该角色的人应该具有相关业务领域的知识并具有丰富开发经验。
相关配合人员：
是被开发方配合开发的人员，具有一定的计算机应用水平，并且能够熟悉相关的一些具体业务。
3.1.2需求调研方法
需求调研一般采用座谈方式，参加人员是需求调研人员、相关配合人员和业务部门领导或业务代表。
步骤一、了解用户需求，主要从以下几方面
1、了解业务部门的组织机构和岗位分布情况
2、了解业务部门主要业务内容
3、了解业务部门的主要业务流程和业务特点
4、了解业务部门和其他业务部门相关联业务
5、了解业务部门现有机器、网络和软件应用现状
6、了解业务部门对新系统的要求和期望
步骤二、收集用户视图
1、收集业务部门内部使用的台帐、单据和报表
2、收集流向该业务部门的单据、报表
3、收集流向其他业务部门的单据、报表
步骤三、需求调研确认
1、需求调研人员填写用例模型确认子表
2、由相关业务部门进行用例模型确认
3.1.3需求调研工件
需求调研阶段产生的工件如下：
1、调研记录表
2、用户视图清单
3.2需求分析规范
需求分析方法主要采用面向对象的方法，在具体实施时采用RUP（RationalUnifiedProcess）方法。
在RUP中需求分析具体包括两部分，一是业务建模，另一是需求分析。
3.2.1业务建模规范
3.2.1.1业务建模目的
业务建模的目的在于：
●了解目标组织（将要在其中部署系统的组织）的结构及机制。
●了解目标组织中当前存在的问题并确定改进的可能性。
●确保客户、最终用户和开发人员就目标组织达成共识。
●导出支持目标组织所需的系统需求
3.2.1.2业务建模活动概述
3.2.1.2.1评估目标组织
目的：
●从当前流程、工具、人员能力、人们的态度、客户、竞争对手、技术趋势、问题以及有待改进之处等方面入手，来描述要部署应用程序的组织的当前状态。
●确立必须对目标组织进行设计的动机。
●确定业务建模工作的涉众。
步骤：
●启动评估
建议在研讨班中启动评估，以便在研讨班中召集关键人员（启动时已知的关键人员）。
这一启动研讨班主要用于业务分析员召集业务建模工作的涉众，收集来自项目涉众的问题，以便创建一个全面的列表。
●确定涉众
确定业务建模工作的涉众。
确定目标组织以外的涉众，例如：
顾客、竞争对手和其他涉众等
●说明目标组织的结构
简要说明组织结构及其当前的角色和团队。
此外，还要考虑目标组织中不同部分之间的关系。
例如，销售和维护之间的关系，以及产品开发和销售之间的关系
●确定关键人员
确定目标组织中的所有关键人员。
●评估经营理念和经营策略
大多数组织都详尽地记录了其经营理念和策略。
如果已经记录了“虚拟”组织（即进行业务建模是为了理解目标客户的业务流程，以便生产更好的产品），则可以不执行此步骤。
●基准
确定下列内容：
参照的基准是谁；用于基准比较的指标；如何执行基准比较
●评测目标组织
评测组织是指理解组织的业务流程，并对其加以评测
●确定变更的起因
询问涉众希望变更业务流程和业务工具的原因。
●评估应变能力
分析目标组织的应变能力。
组织就象个人一样，只能适应一定范围之内的变化。
某些组织对变更的准备可能会比其他组织更加充分。
要了解组织的应变能力，我们建议您同组织中的人员进行访谈，了解他们对变更的态度和意愿。
●确定问题
确定问题的最佳途径是召集关键人员通过开会来发现问题。
●作出结论
分析收集到的信息，编辑应该关注的方面和问题的列表。
●提出建议
您需要将有关未来的建议作为评估的一部分。
这些建议应该说明进行业务建模所采用的方法。
3.2.1.2.2设定和调整目标
目的：
●确定业务建模工作的范围。
●确定未来目标组织的前景。
●就目标组织可能要做的改进和新的目标达成一致。
●说明目标组织的首要目标。
步骤：
●确定目标组织的范围
讨论应在建模工作中选择包括的内容范围，从而确定目标组织的构成。
通过使用业务主角和业务用例符号能够有效（但并不必然）地完成该讨论工作。
●确定涉众
在目标组织评估中，您应该已经确定了业务的涉众。
在业务前景中，您需要指明这些涉众中的哪些在目前项目的范围内仍被认为是涉众。
●就目标组织的目标达成一致
标组织的目的表示了利用业务建模工作要实现的目标。
●确定对工作施加的约束
需要考虑多种多样的约束来源。
●明确阐述问题说明
在目标组织评估中，您可能确定在目标组织中已经存在一系列问题，这些问题是您和涉众共同确定的。
在业务前景文档中，您需要将列表中的问题限制在业务建模工作范围之内准备集中解决的问题。
●确定哪些区域需要划分优先级
需要就业务建模工作应该区分目标组织中哪些区域的优先级问题加以讨论并达成一致。
3.2.1.2.3制定业务规则
目的：
●确定要在项目中考虑哪些业务规则。
●对业务规则做出详细的定义。
步骤：
●收集规则源
确定您有哪些规则源。
有些业务规则来自法律和法规，而其他业务规则可能是公司标准。
还有一些业务规则表达了业务建模工作要实现的目标。
●表述规则
用严格和正式的语言来表述业务规则，同时要考虑规则阅读者的具体情况，以确保他们能够有效地理解这些规则。
有关业务规则的类别和风格的详细信息。
3.2.1.2.4获取常用业务词汇
目的：
●定义可用于业务的所有文本说明，尤其是可用于业务用例说明的常用词汇。
步骤：
●查找常用术语
在业务建模中，必须使用问题领域中最常用的术语和表达方法来定义常用词汇。
此后您还应该在业务的所有文本说明中始终如一地使用常用词汇。
这样可以保持文本说明的一致性，从而避免项目成员对术语的使用及其含义产生误解。
您应该将词汇记录在一个词汇表中。
3.2.1.2.5查找业务主角和业务用例
目的：
●概述业务中的各个流程。
●为待建模的业务定义边界。
●定义将与业务交互的对象（人或事物）。
●制作业务用例模型图。
步骤：
●查找业务主角
业务主角备选者可以是与业务进行交互的任何个人、小组、组织、公司或计算机。
●查找业务用例
为了找到主要的业务用例，请考虑各业务主角可以从业务中获取的价值。
请从主要且最重要的业务主角（即客户）开始
●确定业务用例的优先级
业务主角与业务用例一旦确定，就必须确定业务用例的优先级，看哪些业务用例值得进行详细说明。
●编写业务用例工作流程的概述
为了解业务用例的目的，您通常都需要使用工作流程的概述。
这种概述可采用分步说明的形式。
当相关人员（即使是同一个人）在以后具体说明业务用例时，将会需要使用该分步说明。
●描述业务主角与用例交互的方式
要确定哪些业务主角与业务用例进行交互，可通过定义它们之间的通信关联关系来进行。
如果必须要表示通信的发起方，则应向该关联关系中添加导向性。
●将业务用例与主角打包
如果您拥有很多业务用例，就可以将它们划分成用例包，使文档更易于理解。
●在用例图中表示业务用例模型
用例图用于综合说明业务主角、业务用例以及它们之间的关系。
3.2.1.2.6建立业务用例模型
目的：
●从需要作为抽象业务用例考虑的业务用例中提取行为。
这类行为的示例包括公用行为、可选行为以及将在以后的迭代过程中开发的行为。
●查找新的抽象业务主角,它们定义了与其他几个业务主角共享的角色。
步骤：
●建立业务用例间的包含关系
如果发现工作流程中有很大部分能够析出某种包含关系，达到简化原有业务用例的目的，那么这些部分就可以组成一个新的业务用例，包含在原有业务用例中。
例：
个人登记（IndividualCheck-in）和团体登记（GroupCheck-in）两个业务用例都包含行李处理（Baggage-Handling）业务用例。
●建立业务用例间的扩展关系
如果发现工作流程的主要部分能够组成正常工作流程的一个选项，则可将该部分析出形成一个新的业务用例，将它作为原有业务用例的扩展。
例：
利用扩展关系将“特殊行李处理”用例的工作流程插入到“个人登记”用例中。
●建立业务用例间的泛化关系
如果您发现工作流程具有结构、目的和行为，您可通过用例泛化关系将它显示在业务用例模型中。
例：
具体参见用例模型中的泛化关系
●建立业务主角间的泛化关系
如果两个业务主角以完全相同的方式与同一个业务用例相互作用，则它们对于该业务用例所扮演的角色是完全一样的。
为了区分这种情况，您可以为它们之间的共同角色创建一个新的业务主角。
原有的业务主角继承这个新的业务主角。
例：
差旅人员（BusinessTraveler）和普通旅行者（Tourist）这两个主角继承了乘客的所有属性。
所以，这两个主角都能担任乘客（Passenger）这一角色。
3.2.1.3业务建模工件
业务建模阶段产生的工件如下：
1、业务词汇表
2、业务规则
3、业务用例模型
3.2.2需求分析规范
3.2.2.1需求分析目的
●与客户和其他涉众在系统的工作内容方面达成并保持一致。
●使系统开发人员能够更清楚地了解系统需求。
●定义系统边界（限定）。
●为计划迭代的技术内容提供基础。
●为估算开发系统所需成本和时间提供基础。
●定义系统的用户界面，重点是用户的需要和目标。
3.2.2.2需求分析活动概述
3.2.2.2.1获取常用词汇
目的：
●定义可用于系统的所有文本说明，尤其是可用于用例说明的常用词汇。
步骤：
●查找常用术语
在需求工作流程中，必须使用问题领域中最普通的术语来定义常用词汇。
此后您还应该在系统的所有文本说明中始终如一地使用常用词汇，尤其是在用例说明中。
这样可以保持文本说明的一致性，从而避免项目成员对术语的使用及其含义产生误解。
您应该将词汇记录在一个词汇表中。
要发现问题领域中的常用术语，不仅可以考虑在需求中使用的术语，还可以考虑开发团队对于要构建的系统的常识中涉及的术语。
侧重描述下列概念的术语：
a:
代表那些在组织的日常工作中或系统预期的操作环境中所用概念的业务对象的概念。
在多数情况下，已经存在类似的概念列表。
b:
系统需要涉及的存在于真实生活中的对象。
这些对象是自然存在的，例如：
汽车、宠物狗、瓶子、飞机、乘客、保护区或票据。
3.2.2.2.2查找主角和用例
目的：
●概述系统的功能。
●定义在系统内处理的内容和在系统外处理的内容。
●定义与系统进行交互的对象（人或事物）。
●将模型分为主角包和用例包。
●制作用例模型图。
步骤：
●查找主角
定义系统用途的最初步骤包括查找主角。
系统必须与之交互的每种外部现象都由一个主角来代表。
为了查找主角，需考虑以下问题：
a：
哪些用户组需要该系统来帮助他们执行任务？
b：
需要哪些用户组来执行该系统最明显的主要功能？
c：
需要哪些用户组来执行该系统的辅助功能（如系统维护与系统管理）？
d：
该系统是否将会与外部的硬件或软件系统进行交互？
主角的名称应明确表示主角的角色。
确保在以后不会对主角的名称产生混淆。
撰写包括主角的职责范围及主角对系统的要求在内的简要说明，以提供各个主角的定义。
由于主角代表的是系统外的事物，所以无需对其作详细说明。
●查找用例
当完成了对主角的初步概述之后，下一步就是查找系统的用例。
第一批用例都是非常初步的用例，您必定会对其进行几次修改，直至他们稳定为止。
如果系统的版本或需求不完善，或者系统分析含混不清，那么系统的功能也将会含混不清。
因此，您必须不断地问自己，是否找到了恰当的用例。
此外，在得到最终的版本之前，您还应准备添加、删除、组合和分割用例。
详细说明用例之后，就可以更好地理解用例。
查找用例的最佳方法是考虑各个主角对系统的需求。
不要忘记，系统仅为其用户而存在，所以系统应以用户的需要为基础。
通过对系统提出的功能性需求，您可以考虑到主角的更多需要。
对于各个（人或非人）主角，需考虑以下问题：
a：
此主角希望系统执行的主要任务是什么？
b：
此主角是否将在系统中创建、存储、更改、删除或读取数据？
c：
此主角是否需要将突发变更或外部变更通知给系统？
d：
是否需要将系统中发生的某些特定事件通知给此主角？
e：
此主角是否将执行系统启动或关闭操作？
●描述主角与用例交互的方式
由于表示主角与用例之间的关系十分重要，所以每当找到一个用例，就应确定哪些主角将与之进行交互。
为此，必须定义一个通信关联关系，其导航方向应该与主角和用例之间的信号传输方向相同。
通信关联关系示例：
用例和主角之间的一条线或一个箭头表示它们通过相互发送信号进行交互。
●将用例和主角打包
如果主角或用例的数目过多，就应该将它们分成用例包，以简化用例模型的维护。
这也使用例模型更易于掌握。
另外，通过让开发人员负责用例包或主角包，可简化用例模型中职责的分配。
●在用例图中表示用例模型
在用例模型图中，您可以详细说明用例与主角的关系以及相关用例之间的关系。
这些图中可能包括：
a：
属于同一个用例包的主角。
b：
主角及与之交互的所有用例。
c：
处理相同信息的用例。
d：
同一组主角所使用的用例。
e：
通常按一种顺序执行的用例。
f：
属于同一个用例包的用例。
g：
最重要的用例。
这种用例图可作为模型的概要，并可能会包括在用例视图中。
h：
一同开发的用例（在相同的递增阶段中）。
每个图都应该由用例模型中的相应包所拥有。
用例图示例：
3.2.2.2.3建立用例模型
目的：
●有些业务用例需要作为抽象业务用例考虑，并从中提取行为。
升级会员 