1. :RUP个性化定制RMC
2.
项目组合:来源于华尔街的金融投资portfolio(组合)
3.
领域:Project / Program / Portfolio3P
项目组合,模型
不是程序的意思,意义为大项目
项目与变化
4.
需求和系统分析
静态分析:代码级——比如RSA中的(代码复审)
动态分析:动态的,代码覆盖率,比如应用服务器程序servlet
系统级分析:自动化工具
性能分析:需要考虑并发性能测试,主要是WEB
5.
设计与构建
6.
变更和配置管理
变更广义:需求,新的改进请求,BUG,变更是一个维度。项目经理等角色需要根据变更来考虑与分配工作——形成文档——实现形成版本——产生不同版本——需要配置管理!
7.
为什么使用RSA不使用ROSE?
a)
,ROSE不支持该标准,只熟悉UML1.4UML2
b)
MDA开发=模型驱动的软件开发 model
code
c)
工作量估计:cocomoⅱ
d)
tranteformation
e)
Eclipse开发工具的集成
f)
软件资产规格说明书,是否重用。Patterm设计模式RAS
g)
中文化支持
8.
可以作代码,RAD作为一个RSA的一个部分。内置WASRSA
9.
文档自动化。基于RequesitePro中的数据——生成文档的模版。好处。如果数据源变化了文档也随之变化了。SoDA (Software of Docutment Authertion)
10.
需求管理
a)
电力现状:
i. 基于文档,《需求调查表》
ii. 信息采集,需求分析报告
iii. 概要设计
iv. 保持一致性。如何保证一致性。
v. 功能角度
vi. 设计文档
vii. 自动化文档生成工具
viii. 如何看到不同的变更
ix. 数据规划,类似CA ERwin
x. 数据规划的变化。
b)
:使用USE CASE,使用《需求调查表》前提是必须要具备业务逻辑能力,这种沟通基于工作职位,需求的追踪。RD
采集来的很多
需求
使用CQ变更管理平台,方便收集客户需求
使用建模工具WBI,ROSE XDE, RSM,RSA
使用模型(用例模型)和文档的有机结合,准确的描述需求
DEMO:
RequesitePro提供不同的应用界面:
Ø
MS WORD界面
Ø
数据库界面
Ø
WEB界面
F URPS +行为,可用性,性能,测试规约,设计约束
c)
RM
DEMO:华中电力科技公司合同收支系统
A.
使用REQUISITEPRO:需求类型,文档类型,属性,联系人,优先级,来源,稳定性,用例,补充规约,概要设计文档,详细设计文档,追踪设计文档。
B.
客户需求,用例,概要设计,补充规约
C.
定义 需求调查表 对应的客户类型 客户需求 文档后缀:CR
D.
定义 需求规格说明书
对应的
用例
E.
定义 概要设计文档 DES 对应的
概要设计
F.
加属性 如优先级,来源,稳定性,风险,负责人(可以直接改名字)
G.
在FLES菜单中导入业务文档
形成导入到RQ的数据库文档
H.
改了文档——RQ中的需求也发生变化=====自动同步
I.
方式,中间WASEXV6 在RQ中嵌入:RWP。后面DB,WEB
J.
处理变更,我们需要建立VIEW,在VIEW中体现变化。
a)
是否具备权限设定比如CC PUBLIC/PARIVATE,可以take offline
b)
修改后的COMENCE是否能够设定为强制,
不能。
c)
是否多人进行更改,
不能。
d)
安装DB2冲突,端口问题,JDBC
e)
二次开发问题。
f)
数据库建模方面采用
RADA类似Erwin,新产品。
g)
安装WAS会有冲突吗?端口问题,9060端口。
11.
可视化建模
a)
什么情况下使用可视化建模
i. 沟通、协作
A.
语言L
B.
图形化的M
C.
我们之间沟通,统一沟通U
ii. 变更
iii. 规范化
iv. 管理复杂度
A.
因为复杂就需要提高抽象层次,提高高度。
B.
化复杂为简单
v. 重用
A.
文件,头文件H
B.
,库函数LIB
C.
设计模式
D.
FRAMEWORKS
a)
团队如何快速理解已有实现或框架?UML
b)
相关培训DEV475:OOAD
c)
是可以推导出来的,公式化。OOAD
12.
RSA
需求
用例
系统定义
分析与设计
13.RUP思路展现
推荐安装RUP/RMC,基于角色来采集相关展现。
建议拷贝宁德军RMC介质与介绍文档。
14.RSA演示业务用例的实现的解决方式
关注实体间的关系,使用CA BPWin。使用RSA business model,使用业务用例为核心。业务用例来自客户需求中的业务需求,业务流程在里面。实体有生命周期,状态不同,不同阶段不同处理办法,流程怎么描述。尝试实现业务流程。《编写有效用例》,根据对业务流程的要求,定义流程中的对象实体间一对多,多对多的关系。
15.画图的意义的描述过程,在华中电力中数据规划,目的是产生业务实体,形成某一个业务领域的实体模型。根据业务领域来抽象。
16.实体模型分层次。数据规划一定要这么做!!!
17.数据分析与建模交叉部分?冲突解决。层次划分,子系统/包/包
子系统更加强调细微差别采用8个系统,一个系统一个包。
8个不同的
系统
这个概念和模式分解类似!!!!工件——构件
同时形成数据字典,这个结果里面不但包括实体模型,而且数据字典里面避免了数据字典的分析,建立高层形式的视图。
业务远景:为什么做这个项目,业务指南和模板。
从实体模型到词汇表,需要解决一下迭代的过程,定义数据表示规范。
18.怎么定义到业务模型,需要属性、方法,应用层次。不关心范式只关心应用设计。需要迭代中关注参数,实体类有没有状态。有状态需要画状态机。
19.找到可以自动化的部分,提取自动化的部分来提取USE CASE,然后来做分析。产生用例模型并用于需求相关的东西。————产生一个VIEW,这个VIEW是一个系统VIEW不是一个业务VIEW。
20.AS IS – TO BE =需求分析的过程。
21.用例模型之后做什么?
a)
用例模型包括2个包含用例和文档,文档可以是LINK
b)
分为两种图:静态图和动态图UML
c)
用例模型之后做的第一件事情:架构分析
d)
架构分析前提取关键抽象。提取实体类
e)
然后进行架构分析,要先设计风格。B/S,C/S,3-LAYS
f)
然后进行用例分析,用例分析关心的是功能性的分析,还有其他的非功能性的分析,比如数据库存在哪里?数据读取速度?采用什么架构模式和设计模式。
g)
用例分析——提取我们的分析类。
h)
时序图。产生方法,产生属性。
i)
用例分析——用例设计
j)
产生子系统/产生interface
k)
如果有上一步的子系统产生,那么还要进行子系统分析。还要产生接口
l)
静态结构图,类图
m)
状态机,向上抽取。
n)
持久性机制的选择,部署图的部署。
o)
模式:带参数的协作图/类图。
22.SoDA生成相关文档
a)
显示相关模板
b)
显示连接服务器的模型要求。
c)
对PDF的集成。
23.RSA实例讲解
a)
中切换到需求透视图,打开需求浏览器打开需求分析RSA
b)
建立业务分析或者系统分析。
c)
建立合同支付子系统
d)
新建用例视图包
e)
拖左边需求浏览图到右边的用例图中
f)
用例完成之后,新建活动图
g)
建立协作图
h)
建立主流/被选流,产生用户信息
i)
用例实现
j)
用例实现的追踪图
24.SoDA模板有两个部分组成。
静态文档:原DOC文档,还有一个部分是动态部分:动态部分会连接到某个领域源,比如RSA的源,ROSE的源。这些动态部分是SoDA的命令。生成文档的时候,收集这些动态的东西形成文档。生成有2种方式,一种是文档,一种是报告。报告是静态,与数据库没有关联。文档是动态,与数据库进行关联,这样的变更是同步你的领域源。
25.
25.建模建立到什么程度才算好?
a)
能够描述清楚业务就算好
b)
没有一个定式
26.作数据规划的时候,我们提取的过程。
package
package
package
package
package
package
层次树型。
按照功能模块划分。
27.由于业务实体有生命周期,所以业务建模中需要用例图、活动图、状态图(时间、变化)、类图。
28.状态图隶属于某一个实体。
29.数据模型只有类图。
业务系统
子系统
用例图
活动图
功能模块
类图
用例实现
业务实体
|
|————系统
|——————子系统
|
|——————功能模块
数据字典(词汇表)
|
|——————关键抽象(约定俗成的词汇关键字)
安装RSA
原文链接: http://blog.csdn.net/jaminwm/article/details/1364268