活动:
|
目的
|
|
角色:实施者 | |
频率:此活动通常在创建或修改实施元素期间执行多次。 | |
步骤 | |
输入工件: | 生成的工件: |
更多信息: | |
工具向导: |
工作流程明细: |
目的: | 确定将激励期望的运行时行为的执行路径 |
如果要从运行时行为的观察和分析中获得对软件行为的期望认识,您就必须考虑应用程序的哪些执行路径将具有值得探索的重要性,而这些路径中哪些又将提供最多的机会来了解软件的运行时行为。
一般情况下,对于探索最有用的场景往往能反映最终用户一般将使用的全部或部分运行时行为。因此,只要有可能就通过提问或以其它方式咨询领域专家(如正在开发的软件的最终用户代表)来确定场景,这样做会很有用。
用例提供一组有价值的工件,可以从它们确定并探索有用的场景。作为开发人员,最熟悉的用例实现将可能是您应该首先使用的用例实现(如果可用的话)。如果没有用例实现,就请确定任何可用的用例场景 - 这些场景应该对最终用户将在用例规范中的各种事件流中浏览的路径提供文字说明。最后,还可以查看用例事件流来提供可以从中确定可能的候选场景的信息。如果向用例参与者代表或其它领域专家咨询,这最后一个方法的成功率可得到进一步提高。
在尝试为运行时分析确定有用的场景时,测试人员是另一个可供咨询的有用资源。测试人员往往因为其测试工作(这样的工作使他们成为准领域专家)而对领域有一定的见解和经验。在很多情况下,观察软件的运行时行为的激励因素将来自于测试工作本身的结果。
如果该活动是受所报告缺陷的推动,那么活动的主要重点将是在受控的环境中重现缺陷。根据问题发生时记录的信息,一些测试用例必须确定为一定能使缺陷发生的可能候选原因。您可能需要调整一些测试或撰写一些新的测试,但是必须记住,重现缺陷是一个基本步骤,而且对最难的案例来说,稳定缺陷比修正缺陷要花费更多的时间。
目的: | 确保组件处于适当的状态,准备好支持运行时执行 |
为了让组件的运行时执行能得出准确的结果,应该注意满意地准备组件,从而使实施、编译和链接中不会由于错误而附带出现反常结果。
往往有必要使用插桩组件,以使运行时观察能及时完成,或者使它能够在组件依赖于其它尚未实施的组件的情况下得到实际的执行。
您还必须准备执行组件所必需的所有框架或支持工具。在有些情况下,这可能意味着创建驱动程序或利用代码来支持组件的执行;在其它情况下,这可能意味着检测组件,使外部支持工具可以观察并可能控制组件行为。
目的: | 确保目标环境的必备设置已经令人满意地完成。 |
很重要的一点是要考虑所有在将进行运行时分析的目标环境中必须加以处理的需求和限制条件。在一些情况下,有必要模仿会最终要求组件运行的一个或多个目标部署环境。在其它情况下,在开发人员机器上执行“观察运行时行为”就足够了。
在任何情况下,令人满意地为运行时观察设置目标环境都很重要,这样就不会因为包含可能会使后续分析无效的“杂质”而使工作被浪费。
另一个考虑事项是使用生成环境限制条件或异常状况的工具(没有这样的工具,这些状况就很难重现)。这样的工具对于分离这些状况下的运行时行为中发生的失败或反常情况是非常宝贵的。
目的: | 观察并捕获组件的运行时行为。 |
准备组件以及将观察组件的环境后,现在您就可以开始通过选择的场景执行组件了。根据使用的方法和工具,这一步骤的执行可能只需少量关注,也可能随着场景的发展而提供(或者甚至要求)持续的关注。
目的: | 确定组件运行时行为中的失败和反常情况 |
在您正在观察的场景中间或结束时的每一个步骤中,在预期的行为中查找失败或反常情况。请记下所有您认为可能与反常行为相关的观察结果或留有印象。
目的: | 了解任何失败和反常情况的根本原因 |
根据您的发现结果开始调查每个失败情况的底层故障或根本原因。
目的: | 建议进一步的调查或更正操作 |
当查看您的所有发现结果后,您可能会有一系列要求进一步调查的想法和念头,并可能还有您提议的具体的更正操作。如果您不自行立即对这些项采取行动,就请以适当的格式记下您的提议,然后将它们传达给您的团队成员,让他们核准或以其它方式执行您的提议。
目的: | 验证活动已适当地完成,结果工件是可以接受的。 |
现在您已经完成了工作,这时如果能验证工作有足够的价值就是一个好的做法。您应该评价自己的工作质量是否适当,是否已经足够完整供团队中其他成员在后续工作中使用您的工作结果。只要有可能,就用 RUP 中提供的检查列表验证质量和完整性已经“足够好”了。
让那些将利用您的工作作为执行他们的下游活动的输入的人员参加进来复审您的中期工作。请在您还有时间针对他们的意见采取行动时让他们参与复审。您还应该针对关键输入工件评价您的工作,确保您已经足够、准确地代表或者考虑了这些工件。在这种情况下让输入工件的作者复审您的工作可能很有用。
请记住,RUP 是一个反复的过程,在很多时候工件会随着时间发展。所以,多数情况下没必要完全形成将在临近的随后工作中只部分使用或根本不用的工件,并且这通常对生产力有副作用。这是因为很有可能在使用工件前,工件周围的环境会发生变化 - 在创建工件时的假设也会证明是不正确的 - 从而造成返工,因而带来精力的浪费。
还要避免将太多的周期时间花费在展示内容本身的价值损害上。在展示作为项目可交付工件有很大的重要性而且有经济价值的项目环境中,您可能希望考虑使用管理资源或初级资源来对工件执行工作,以改进其展示效果。
Rational Unified Process
|