| 工具 > Enterprise Architect >技术文档 |
|
使用用例指标进行项目估算
背景
Enterprise Architect提供了一个全面的项目估算工具，可以根据用例和参与者对象计算工作量，并结合定义工作环境复杂性的项目配置。该方法基于Karner的用例点方法，下面提到了几种变化。您还可以生成包含项目评估分析的度量报告，以将其合并到项目文档中。这里有一个例子。
在估算项目规模之前，首先需要配置技术和环境因素（请参阅菜单项配置 - 度量和估计类型 - TCF和ECF值）。对于TCF（技术复杂性因子）和ECF（环境复杂性因子），可编辑表格包含影响项目生产率的因素列表。权重与每个因素相关联，反映了该因素相对影响生产力的程度; 权重与项目无关。提供的因子及其相关权重由用例点方法定义，但可以根据项目的特定需求进行调整。对于大多数用途，需要调整的唯一表格列将是“值”，表示特定因子对项目的影响程度。作为建议的量具，
在使用UML用例构建项目来描述建议的功能时，您应该为每个用例分配一个评级：
- 简单（5分）：用例被认为是一件简单的工作，使用简单的用户界面，只触及一个数据库实体; 其成功案例不到3个步骤; 它的实现涉及少于5个类
- 中（10分）：用例更难，涉及更多界面设计，涉及2个或更多数据库实体; 它的成功案例有4到7步; 它的实施涉及5到10个班级
- 复杂（15分）：用例非常困难，涉及复杂的用户界面或处理并触及3个或更多数据库实体; 其成功案例有七个步骤; 它的实施涉及10个以上的课程
以上是分配复杂性的不同公认方法，但作为粗略指导。如果您正在编写一个没有持久性但复杂处理的应用程序，则必须使用您的判断来指定复杂性评级。
在构建用例时，请注意您也可以将它们分配给阶段（例如1.0,1.1），然后根据阶段过滤您的估算。您还可以在用例的Tag字段中输入自由文本，并根据标记信息过滤估计值（例如）。
Karner的UCP方法还通过考虑项目参与者及其贡献的复杂性来计算项目工作量。可以选择在估算计算中包括参与者; 默认情况下，仅考虑用例。如果还包括项目参与者，请确保通过某种方法分配其复杂性; 下面提供了这项任务的粗略指南：
- 简单：actor代表另一个具有已定义API的系统
- 中：actor表示通过协议交互的另一个系统，如TCP / IP
- 复杂：演员是通过界面进行交互的人。
设置用例，参与者和环境后，在项目浏览器中突出显示您要估计其内容的包; 对于整个项目，请选择根视图。接下来，从菜单中选择Project - Use Case Metrics。将出现以下屏幕：
这详细说明了项目的复杂性信息：
- 技术复杂性因子是根据您设置的值计算的
- 环境复杂性是根据您设置的值计算的
- 未经调整的用例点数（UUCP）=用例复杂性等级的总和*
- UUCP与TCF和ECF因子相乘，以产生加权用例点数（UCP）
- 结果数乘以每个UCP的默认小时数以产生最终估计
- 还显示了每个简单，中等和困难用例的平均小时数
*尽管Karner的UCP方法建议在此计数中排除包含和扩展用例，但Enterprise Architect会在计算中考虑所有用例。如果这些用例需要开发功能，那么这种努力仍然存在并且应该被考虑在内。
关键因素是“默认小时数”变量 - 最好使用类似项目的经验来定义。虽然Enterprise Architectdefault设置为10小时，但此变量可能很容易超过30小时，具体取决于环境。
准确地将新项目配置到您的独特环境的最佳方法是考虑已完成项目的用例。按照上面的说明配置已完成的项目并运行度量报告后，可以对可用因子进行微调，以产生与实际小时数相匹配的估算值。然后，您可以开始使用这些数字作为基线。
请注意，良好的健全性检查是查看“每次使用案例的Ave小时数”：如果您认为可以在允许的时间内构建一个简单的用例（包括您的设计，测试，文档，审查等程序）而中等和困难同样，那么你是在正确的轨道上。
不要指望对“多少钱”的问题有一个神奇的答案？还是'多久了？' - 收集一些统计数据和经验，以指导新项目的估算 |
|
|
