工件:
|
![]() | 创建(该工件)是为了捕获复审一个或多个项目工件的活动结果。 |
---|---|
角色: | 复审员 |
可选/发生: | 必需。在整个开发生命周期中进行。 |
模板和报告: |
|
示例: | |
UML 表示: | 不适用。 |
更多信息: |
活动的输入: | 活动的输出: |
复审记录 是专用于复审活动的评估工件。它主要用于获取复审活动的结果或结论,并确定复审所引起的任何操作项。
1. 项目确定和复审类型
确定项目和复审类型;例如,代码检查、需求可跟踪性复审、PRA 项目复审和项目规划复审。
2. 复审的工件和复审目标
列出将成为本次复审主题的工件并描述复审的目标。
3. 复审参与者
列出将参与复审者和他们在会议期间担任的角色;例如,主持人、记录人员、复审人员和作者。
4. 安排和场所
确定复审的安排。包括复审会议的日期、时间和地点,以及复审工件的出版计划(如果复审工件未附加到复审记录)。
5. 确定的问题和解决建议
列出在复审期间确定的任何问题。复审人员可以确定:
复审小组可提出解决问题的建议。
6. 操作项状态
列出复审所引起的任何操作项;列出这些操作项时应带有确定的所有者(负责完成操作)和目标日期。这些通常是为了更正已确定的问题而采用的操作项。 操作项可包括:
继续工作: | 不认为工件已完成,开发工作应继续进行 |
---|---|
提出工作单: | 如果问题需要计划新的工作,但不更改有基线的工件 |
提出变更请求: | 如果问题需要变更有基线的工件 |
可能存在以前复审该工件的操作项,列出这些操作项时应带有其状态(例如,打开/关闭)、所有者和目标日期或结束日期。
7. 项目经理考虑的事项
复审小组对于处理所发现的某些问题或意外情况的一系列操作未能达成一致意见,且需要通过升级来解决问题。
8. 后续复审
描述复审小组的后续操作建议(例如,是否需要其它复审)和需要哪些附加信息或数据(如果有)。
9. 工时记录
捕获准备和开展复审工作所花的工时。
复审活动是 Rational Unified Process 所必需的,并在整个开发生命周期中进行。
至少需要一个处于 复审员 角色的人负责复审记录。可在复审会议开始时分配该职责,定期在与会的复审小组成员之间轮换,或者由最具相应技能的小组成员来担任。负责复审记录的指定 复审员 者通常还需要管理所有后续操作项,并在必要时调整问题解决方案。
在较大的团队或较正式的项目环境中,复审员 角色的职责通常委托给一些专用的支持角色:
虽然所有项目都应使用该工件,但正式程度将因项目而异,这以诸如客户和开发人员之间关系的正式程度或开发人员自身组织符合流程的正式程度之类的因素为根据。例如,项目约定可能规定复审服从审计:在这种情况下,该工件通常将被视为复审的可审计记录及其结论
虽然该工件主要用于获取复审结果,但也可用作专用工作单或控制文档,以控制复审的执行。当这样使用时,则说明复审参与者在复审会议之前就开始了复审活动。
Rational Unified Process
|