用例分析方法总结
1. 前言
2. 具体分析方法
2.1. 如何参与者用例?
(1)、谁会来使用这个系统?
(2)、谁会来安装这个系统?
(3)、谁会来启动这个系统?
(4)、谁会来维护这个系统?
(5)、谁会来关闭这个系统?
(6)、哪些系统会来使用这个系统?
(7)、谁会从这个系统获取信息?
(8)、谁会给这个系统提供信息?
(9)、在预先设定的时候到达时,有什么事情会自动发生吗?
(10)、哪些系统会和这个系统联网?
(11)、是否会有硬件设备会与这个系统联网?
(12)、哪些数据库会与这个系统联网?
(13)、公司内部会有哪些人员会来使用这个系统?
(14)、公司外部会有哪些人员会来使用这个系统?
(15)、当特定的时间或事件发生时,这个系统需要自动通知什么人,或是自动通知其他系统吗?
2.2. 如何寻找参与者?
(1)、参与者想要从这个系统获得什么样的功能?
(2)、这个系统存储信息吗?哪些参与者将建立、读取、更新或删除这些信息?
(3)、当系统内部状态有变化的时候,这个系统需要通知参与者吗?
(4)、是否有什么外部事件是这个系统需要知道的的?当这些外部事件发生时,哪些参与者会通知这个系统?
(5)、这个系统需要定期执行什么操作?
(6)、当发生了某些重要的外部事件时,这个系统需要自动执行什么操作吗?
(7)、这个用例的名称够明确吗?是否能够从这个用例的名称,直接判断出它的结果?
(8)、这个用例会有许多不同的结果吗?还是这些结果,其实是在不同的时间点产生的?
2.3. 包含关系注意要点
(1)、需要共享的相同流程,才能独立处理
(2)、暂存数据或是访问数据库的操作,不要轻易独立出来
(3)、如果只是一两句相同的流程叙述,不要大费周章地独立出来
2.4. 扩展关系要点
(1)、谨慎的使用扩展关系,避免因为扩展关系,而让用例图变得很难理解
(2)、扩展关系通常用于系统上线之后的改版,可以在不变动已经写好的用例叙述的情况下,利用扩展关系,加上一段新的用例
叙述,以满足需求
(3)、不一定会执行的流程,可以放置在替代流程中,要是想要跟其他用例共享这段流程的话,也可以改用扩展关系
2.5. Gustav Karner的用例点模型估算工时
Karner先生建议:一个用例点大约可以估算成20人时(man hour)
举个例子:假设我们的项目算出来一共有100个用例点,团队成员一共有5人,没人每天工作8小时,并且一周工作5天,最后就
会得到需要花费10州的估算,计算过程如下:
每个用例点估算人时:20人时
用例点:100个
团队成员:5人
每天工作时数:8小时
每周工作天数:5天
计算过程:
20(人时) × 100(用例点) = 2000(人时)
8(小时) × 5(工作天) = 40(工时)
2000(人时) ÷ 5(人) ÷ 40(工时) = 10(周)
估计工时:10周
用例点 = 未经调整的用例点 × 技术复杂系数 × 环境系数
未经调整的用例点 = 参与者总权重 + 用例总权重
[*]2.5.1. 参与者总权重
[table]
|参与者总权重 |
|类型| 描述 |权值 |个数 |
|简单参与者| 这种类型的参与者通常是其他系统,采用程序接口与我们开发的系统交互 |1 |
|一般参与者 |一般有2中,第一种是采用特殊协议交互的其他系统,第二种是采用文本模式交互的人类用户 |2 |
|复杂参与者| 这种参与者就是我常见的人类用户,采用丰富且亲和力高的图形界面 |3 |
|总计权重:|
[/table]
[*]2.5.2. 用例总权重——分类方法1
[table]
|用例总权重 |
|类型| 描述| 权值| 个数 |
|简单型用例| 拥有少于3个的事务| 5 |
|一般型用例| 拥有4——7个事务 |10 |
|复杂型用例| 拥有多于7个事务 |15 |
|总计权重:|
[/table]
[*]2.5.3. 用例总权重——分类方法2
[table]
|用例总权重|
|类型 |描述| 权值| 个数 |
|简单型用例 |少于5种分析对象 |5 |
|一般型用例 |使用了5——10种分析对象| 10 |
|复杂型用例| 多于10种分析对象 |15 |
|总计权重:|
[/table]
[*]2.5.4. 技术系数加权值
[table]
|技术系数加权值|
|系数|说明|加权值|强度等级(0-5)|技术权重(加权值 * 强度等级) |
|T1|分布式系统|2|
|T2|相应时间(联网)| 2 |
|T3|终端客户性能|1|
|T4|复杂的内部处理|1|
|T5|程序代码的可重用度|1|
|T6|容易安装|0.5|
|T7|容易使用|0.5|
|T8|便于携带|2|
|T9|容易更改|1|
|T10|同步性|1|
|T11|包含特殊的安全机制|1|
|T12|提供直接访问给第三方|1|
|T13|特殊的用户培训设施要求|1|
|技术权重总和:
[/table]
[*]2.5.5. 环境系数和加权值
[table]
|环境系数和加权值 |
|系数| 说明| 加权值| 强度等级(0-5)| 环境权重(加权值 * 强度等级) |
|E1| 熟悉迭代开发方法| 1.5 |
|E2 |应用领域的经验 |0.5 |
|E3 |面向对象的经验 |1 |
|E4 |分析师的能力 |0.5|
|E5 |干劲 |1 |
|E6 |稳定的需求| 2 |
|E7 |简直的工作人力| -1 |
|E8 |困难的程序语言| -1|
|环境总权重: |
[/table]
[*]2.5.6. 调整人时
用例点的传世人Karner先生建议,以20人时完成一个用例点为基准。但是并非所有的项目的情况都适合用20人时来估算,可以
根据项目的负面系数的个数来调整人时,如下:
[table]
|≤2|——项目的总负面系数个数小于等于2是,可以采用20人时来估算 |
|3~4|——项目的总负面系数个数等于3或4时,可以采用28人时来估算|
|≥5|——项目的总负面系数个数大于或等于5时,项目失败的可能性非常高,最好调整项目,知道项目的负面系数个数降到5以
下为止 |
[/table]
如何计算项目的负面系数个数呢?在E1~E6的环境系数之中,数数看有几个系数的强度等级低于3的,然后再数数看E7~E8环境系
数中,有几个系数的强度等级高于3的。最后,再把这两个数字加起来,就是项目的负面系数个数了。
1. 前言
2. 具体分析方法
2.1. 如何参与者用例?
(1)、谁会来使用这个系统?
(2)、谁会来安装这个系统?
(3)、谁会来启动这个系统?
(4)、谁会来维护这个系统?
(5)、谁会来关闭这个系统?
(6)、哪些系统会来使用这个系统?
(7)、谁会从这个系统获取信息?
(8)、谁会给这个系统提供信息?
(9)、在预先设定的时候到达时,有什么事情会自动发生吗?
(10)、哪些系统会和这个系统联网?
(11)、是否会有硬件设备会与这个系统联网?
(12)、哪些数据库会与这个系统联网?
(13)、公司内部会有哪些人员会来使用这个系统?
(14)、公司外部会有哪些人员会来使用这个系统?
(15)、当特定的时间或事件发生时,这个系统需要自动通知什么人,或是自动通知其他系统吗?
2.2. 如何寻找参与者?
(1)、参与者想要从这个系统获得什么样的功能?
(2)、这个系统存储信息吗?哪些参与者将建立、读取、更新或删除这些信息?
(3)、当系统内部状态有变化的时候,这个系统需要通知参与者吗?
(4)、是否有什么外部事件是这个系统需要知道的的?当这些外部事件发生时,哪些参与者会通知这个系统?
(5)、这个系统需要定期执行什么操作?
(6)、当发生了某些重要的外部事件时,这个系统需要自动执行什么操作吗?
(7)、这个用例的名称够明确吗?是否能够从这个用例的名称,直接判断出它的结果?
(8)、这个用例会有许多不同的结果吗?还是这些结果,其实是在不同的时间点产生的?
2.3. 包含关系注意要点
(1)、需要共享的相同流程,才能独立处理
(2)、暂存数据或是访问数据库的操作,不要轻易独立出来
(3)、如果只是一两句相同的流程叙述,不要大费周章地独立出来
2.4. 扩展关系要点
(1)、谨慎的使用扩展关系,避免因为扩展关系,而让用例图变得很难理解
(2)、扩展关系通常用于系统上线之后的改版,可以在不变动已经写好的用例叙述的情况下,利用扩展关系,加上一段新的用例
叙述,以满足需求
(3)、不一定会执行的流程,可以放置在替代流程中,要是想要跟其他用例共享这段流程的话,也可以改用扩展关系
2.5. Gustav Karner的用例点模型估算工时
Karner先生建议:一个用例点大约可以估算成20人时(man hour)
举个例子:假设我们的项目算出来一共有100个用例点,团队成员一共有5人,没人每天工作8小时,并且一周工作5天,最后就
会得到需要花费10州的估算,计算过程如下:
每个用例点估算人时:20人时
用例点:100个
团队成员:5人
每天工作时数:8小时
每周工作天数:5天
计算过程:
20(人时) × 100(用例点) = 2000(人时)
8(小时) × 5(工作天) = 40(工时)
2000(人时) ÷ 5(人) ÷ 40(工时) = 10(周)
估计工时:10周
用例点 = 未经调整的用例点 × 技术复杂系数 × 环境系数
未经调整的用例点 = 参与者总权重 + 用例总权重
[*]2.5.1. 参与者总权重
[table]
|参与者总权重 |
|类型| 描述 |权值 |个数 |
|简单参与者| 这种类型的参与者通常是其他系统,采用程序接口与我们开发的系统交互 |1 |
|一般参与者 |一般有2中,第一种是采用特殊协议交互的其他系统,第二种是采用文本模式交互的人类用户 |2 |
|复杂参与者| 这种参与者就是我常见的人类用户,采用丰富且亲和力高的图形界面 |3 |
|总计权重:|
[/table]
[*]2.5.2. 用例总权重——分类方法1
[table]
|用例总权重 |
|类型| 描述| 权值| 个数 |
|简单型用例| 拥有少于3个的事务| 5 |
|一般型用例| 拥有4——7个事务 |10 |
|复杂型用例| 拥有多于7个事务 |15 |
|总计权重:|
[/table]
[*]2.5.3. 用例总权重——分类方法2
[table]
|用例总权重|
|类型 |描述| 权值| 个数 |
|简单型用例 |少于5种分析对象 |5 |
|一般型用例 |使用了5——10种分析对象| 10 |
|复杂型用例| 多于10种分析对象 |15 |
|总计权重:|
[/table]
[*]2.5.4. 技术系数加权值
[table]
|技术系数加权值|
|系数|说明|加权值|强度等级(0-5)|技术权重(加权值 * 强度等级) |
|T1|分布式系统|2|
|T2|相应时间(联网)| 2 |
|T3|终端客户性能|1|
|T4|复杂的内部处理|1|
|T5|程序代码的可重用度|1|
|T6|容易安装|0.5|
|T7|容易使用|0.5|
|T8|便于携带|2|
|T9|容易更改|1|
|T10|同步性|1|
|T11|包含特殊的安全机制|1|
|T12|提供直接访问给第三方|1|
|T13|特殊的用户培训设施要求|1|
|技术权重总和:
[/table]
[*]2.5.5. 环境系数和加权值
[table]
|环境系数和加权值 |
|系数| 说明| 加权值| 强度等级(0-5)| 环境权重(加权值 * 强度等级) |
|E1| 熟悉迭代开发方法| 1.5 |
|E2 |应用领域的经验 |0.5 |
|E3 |面向对象的经验 |1 |
|E4 |分析师的能力 |0.5|
|E5 |干劲 |1 |
|E6 |稳定的需求| 2 |
|E7 |简直的工作人力| -1 |
|E8 |困难的程序语言| -1|
|环境总权重: |
[/table]
[*]2.5.6. 调整人时
用例点的传世人Karner先生建议,以20人时完成一个用例点为基准。但是并非所有的项目的情况都适合用20人时来估算,可以
根据项目的负面系数的个数来调整人时,如下:
[table]
|≤2|——项目的总负面系数个数小于等于2是,可以采用20人时来估算 |
|3~4|——项目的总负面系数个数等于3或4时,可以采用28人时来估算|
|≥5|——项目的总负面系数个数大于或等于5时,项目失败的可能性非常高,最好调整项目,知道项目的负面系数个数降到5以
下为止 |
[/table]
如何计算项目的负面系数个数呢?在E1~E6的环境系数之中,数数看有几个系数的强度等级低于3的,然后再数数看E7~E8环境系
数中,有几个系数的强度等级高于3的。最后,再把这两个数字加起来,就是项目的负面系数个数了。