实验三 1 考勤卡应用程序用例分析.docVIP

考勤卡应用程序用例分析 实践 实践目的 通过例子过一遍分析的全过程 背景 目前已经为考勤卡系统收集了需求。接下来就是分析这些需求，将其转化为开发人员可以理解的语言。 总体操作步骤 从用例分级开始，寻找候选对象及其交互，最后详细地描述这些类。 详细操作说明 用例分级 对每一个用例根据其风险、对用户和架构的重要性、对团队是否有能力开发进行分级。然后确定一个最重要的用例子集，在第一次系统迭代中实现。 建立分级系统 将风险、重要性、对开发团队合适性分成1~5个级别，级别越高，表示用例越适合在第一个或下一个迭代中实现。 风险 应该尽可能在开发周期的初期攻克系统有风险的部分。 先列出风险清单，经考虑界面比较简单，用户可能对时间要求较突出，另外增加系统的规模和特性也可能碰到。 头脑风暴得出的风险有： 无法接受的系统性能 无法接受的用户界面 不确定的进度及开发周期 无法应付新的需求 经整理，得出如下关注的风险排序： 1. 无法接受的系统性能 2. 无法应付新的需求 3. 不确定的进度及开发周期 4. 无法接受的用户界面 风险评估值的获得 通过向开发人员询问：是否有把握在第一次尝试解决某个问题，然后看答案的选择： 1）当然可以，我们项目团队以前做过 2）没问题，以前我们机构里面解决过这个问题 3）可以采用第三方产品、培训、书等，但我们内部没有任何经验 4）可能吧，听过类似的可以解决的问题 5）我希望可以，但得做一些开创性的工作 重要性 及其指标值的获取 一个重要的用例应该能体现系统的特性和目标，其他用例只是扮演支持的角色。 如没有Add Employee就不能使用系统，但Record Time和Export Time Entries则反映了系统的目的。 用如下问题：如果这个用例在本次迭代中忽略掉，或者用其他用例取代，用户将会怎样反应？ 1. 他们几乎不会注意到用例不存在，不用它系统也没什么影响。 2. 他们会注意到这个用例不在了，但是稍加想象系统仍然可以很好的使用。 3. 系统大部分可以独立于这个用例。 4. 系统的一部分可以独立于这个用例。 5. 没有它，就不可能使用这个系统。 合适性 及其指标值的获取 如果项目组需要很少的培训和短时的学习就可以开始开发某个用例，则这个用例比较适合团队。 要求开发人员描述他们对方法和技术的把握有多高： 1. 这个团队绝对需要一段培训时间来开发这个用例 2. 对于这个用例，团队可能有了足够的能力，但一次迭代后，团队能力需要有本质的提高。 3. 团队可能有了足够的能力，但一次次跌代后这个能力不需怎么提高。 4. 不需要很多的培训。要么团队能力有余，要么这个用例相当简单。 5. 不需要很多培训。团队有了足够的经验，用例也很简单。手到就擒。 创建上述的风险项目及获取方法后，下一步就是得出具体的风险项与评估值。操作方法是对每个用例进行评估，看看其风险因素和可能性及影响。 在需求收集过程中得到的需求模型如下，下面针对用例逐个评估。 评估Export Time Entries用例 让管理员用户导出指定时间段的条目到格式化的XML文件中。 1. 风险： 性能稍有风险。必须可扩展。2级 2. 重要性：非常重要的用例。5级（没有它，系统不能用） 3. 合适性：相对简单。 4级 结论： 考虑重要性，有助于同用户建立信任，并提供重要的构架信息，需要在第一次迭代中开发。 评估Create Charge Code用例 让管理员用户增加新的收费项目代码，用户输入要用到。 1. 风险：性能没有风险。扩展性低，界面/用例简单 2级 2. 重要性：很重要的用例，更像是支撑的用例，早期用户不会注意到是模拟的还是输入的。1级（不会注意到没有它，没有它也没有什么影响） 3. 合适性：5级 不需要很多培训 结论： 没有必要在第一次迭代中开发 评估Change Password用例 让用户更改密码。 1. 风险：没有性能风险，很少改动，扩展性低，界面/用例简单 1级 2. 重要性：也是支撑的用例，1级（不会注意到没有它，没有它也没有什么影响） 3. 合适性：5级 不需要很多培训 结论： 可以在第一次迭代中开发忽略它，当然对系统很重要，推迟实现对评估系统和设计系统不会有影响。 评估Login用例 验证用户身份，作为执行其他用例的先决条件。 1. 风险：有性能风险，但比较低，界面/用例简单 1级 2. 重要性：没有这个用例，系统就无法接受，但用户可以在没有此用例下评估系统，第一次迭代中即使不包含，也要考虑其构架支持，2级（会注意到没有它，稍加想象可以使用） 3. 合适性：4级 不需要很多培训 结论： 尽管在构架上很重要，可以在第一次迭代中开发忽略它 评估Record Time用例 让用户在当前时间段中输入它们的工时。 1. 风险： 性能风险明显。