更改请求 (CMMI)
在本主题中,您可以学习如何填写更改请求工作项的详细信息。 团队可以使用更改请求工作项跟踪对产品的某一部分所建议的更改。 每当建议对已纳入变更控制的任何工作产品进行更改时,都可以创建更改请求。 有关更多信息,请参见管理更改 (CMMI)。
有关如何创建此类工作项的信息,请参见工作项和工作流 (CMMI)。
主题内容 |
相关主题 |
---|---|
|
过程指南 工作簿 字段参考 |
必需的权限
若要查看更改请求,您必须是**“Readers (访问者)”组的成员,或者您的“查看此节点中的工作项”权限必须设置为“允许”。 若要修改更改请求,您必须是“Contributors (参与者)”组的成员,或者您的“编辑此节点中的工作项”权限必须设置为“允许”**。 有关更多信息,请参见管理权限。
定义更改请求
更改请求的工作项窗体在如下图所示的字段和选项卡中存储数据:
在定义更改请求时,必须定义**“标题”**。 可以将所有其他字段保留为空白,也可以接受其默认值。
定义单个更改请求
在工作项窗体的上方区域,指定以下一类或多类信息:
在**“标题”**(必需)中,键入简短的说明。
好的标题指明受影响的产品区域以及如何受影响。 您可以随时更新文本,以便更准确地定义更改和受影响的工作区域
在 指派给 列表中,选择负责解决更改请求的团队成员的名字。
备注
只能为“Contributors (参与者)”组的成员分配工作项。
如果未指派更改请求,则该更改请求将自动指派给您。
在**“状态”列表中,保留默认值“已建议”**。
默认情况下,“原因”字段的值为“新建”。 有关此字段以及如何使用此字段跟踪工作流的更多信息,请参见本主题后面的对更改请求的状态进行更改。
在 优先级 请按1列表中,选择更改请求的重要性级别(最重要)到4 (最不重要)。
默认情况下,此值为 2。
在 会审 列表中,选择会审子状态。
此字段标识为任何处于**“已建议”状态的更改请求确定的会审级别。 有效值包括“挂起”(默认值)、“详细信息”、“收到信息”和“已会审”**。
在 已阻止,如果问题使团队无法实现更改请求,列表中,选择 是。
在 区域 和 迭代 列表中,选择相应的区域和迭代。
备注
项目管理员已经定义“区域”和“迭代”树层次结构,以便团队成员可以根据这些指定跟踪进度。有关更多信息,请参见创建和修改区域和迭代。
在 详细信息 选项卡上,提供尽可能详细的信息,以正确描述团队必须更改。
在更改请求中提供尽可能详细的信息,以确保开发人员能够实现更改请求,并且测试人员能够对其进行测试。 您的团队可以使用此信息为任务和测试用例创建工作项。 有关更多信息,请参见任务 (CMMI)和测试用例 (Agile)。
在 调整 选项卡上,提供尽可能详细的信息,以描述该值设置为客户或产品更改请求实现。
在 分析 选项卡中,选择每个文本框,并提供更改请求在以下方面所产生的影响的详细信息:
对体系结构的影响
对用户体验的影响
对测试的影响
对设计/开发的影响
对技术出版物的影响
除了指明实现更改所需的开销外,您还可以指明受影响的特定区域。
在 其他 选项卡上,指定以下类型的信息:
在**“初始估计”**框中,键入一个数字,用于表示实现更改请求需要花费的工时数。
备注
通常,您将在开发周期的后期定义以下字段,而不是在第一次定义更改请求时进行定义。
在 集成版本 列表中,选择开发团队将更改请求集成的生成名称或内部版本号。
在 所有链接 选项卡上,将一个或多个链接到其他工作项更改请求,如要求或任务。
在 附件 选项卡上,可以附加规范、图像,或者更改请求提供的更多详细信息实现的其他文件。
有关更多信息,请参见本主题后面的以下各节:
将更改请求链接到要求、任务或其他工作项
向更改请求中添加详细信息、附件或超链接
选择 保存工作项。
备注
在保存更改请求之后,标识符将出现在工作项工具栏下方的标题中。
将更改请求链接到要求、任务或其他工作项
通过在更改请求和其他工作项之间建立关系,可以更有效地计划项目,更准确地跟踪依赖项,更清楚地查看层次结构关系以及更快速地查找相关信息。 从更改请求的工作项窗体中,您可以创建自动链接到更改请求的工作项,或者可以创建指向现有工作项的链接。
使用**“链接”**选项卡来创建指向特定类型工作项的特定类型的链接。 有关更多信息,请参见Linking Work Items (CMMI)。
创建任务、Bug、要求或其他工作项并将它们链接到更改请求
打开更改请求的工作项窗体中,选择 所有链接 选项卡,然后选择 新建。
将打开**“添加新的链接工作项”**对话框。
在 链接类型 列表中,选择要创建基于工作项跟踪的关系的其他链接类型。
若要链接到任务或 Bug,请创建**“子级”**链接。
若要链接到要求、风险或问题,请创建**“影响者”**链接。
若要链接到测试用例,请创建**“测试方”**链接。
若要链接到其他任何类型的工作项,请创建**“相关”**或表示要跟踪的关系的其他链接类型。
在 工作项类型 列表中,选择要创建的工作项的类型。
在**“标题”**中,键入所建议更改的简短但具体的说明。
(可选)在**“注释”**中键入附加信息。
选择**“确定”**。
打开一个与您指定的工作项类型相对应的工作项窗体,其中含有您提供的信息。
按下列主题中所述的方式指定其余字段:
选择 保存工作项。
将若干现有工作项链接到更改请求
打开更改请求的工作项窗体中,选择 所有链接 选项卡,然后选择 链接到。
**“将链接添加到更改请求”**对话框随即打开。
在 链接类型 列表中,选择要创建基于工作项跟踪的关系的其他链接类型。
若要链接到任务或 Bug,请创建**“子级”**链接。
若要链接到要求、风险或问题,请创建**“影响者”**链接。
若要链接到测试用例,请创建**“测试方”**链接。
若要链接到其他任何类型的工作项,请创建**“相关”**或表示要跟踪的关系的其他链接类型。
执行以下操作之一:
在**“工作项 ID”**中,键入要查找的工作项的 ID。 使用逗号或空格分隔各个 ID。
选择 浏览 从列表中指定工作项。
将显示**“选择链接工作项”**对话框。
在 已保存的查询 列表中,选择包含要添加的查询。 例如,您可以选择 打开的工作项、 活动 Bug或 活动任务。
选择 查找,在要使用该链接到更改请求的每个工作项旁边的复选框,然后选择 确定。
(可选)键入对链接目标项的说明。
选择**“确定”**。
有关更多信息,请参见查找要链接或导入的工作项。
选择 保存工作项。
备注
更改请求和链接到的工作项都将更新。
向更改请求中添加详细信息、附件或超链接
随着所得信息不断增多,您可以用以下方式向更改请求中添加信息:
在**“详细信息”、“论证”或“分析”**选项卡上的文本框中键入信息。
附加文件。
例如,可以附加电子邮件线索、文档、图像、日志文件或其他类型的文件。
添加指向网站的超链接,或者指向存储在服务器或网站上的文件的超链接。
向更改请求中添加详细信息
选择 详细信息、 调整或 分析 选项在框中键入信息。
您可以设置信息格式以强调重点或获取项目符号列表。
备注
每次团队成员更新该工作项时,其历史记录都会显示更改日期、执行更改的团队成员的名字和所更改的字段。
有关更多信息,请参见更改请求字段引用 (CMMI)和要求字段引用 (CMMI)。
选择 保存工作项。
向更改请求中添加附件
在**“附件”**选项卡中,执行以下操作之一:
将文件拖动到附件区。
选择 或按CTRL+V粘贴已复制的文件。
选择 添加,选择 浏览,因此,在 附件 对话框中,键入或浏览到要附加的文件的名称。
(可选)在**“注释”**框中,键入有关附件的更多信息。 若要关闭 附件 对话框中,选择 确定。
选择 保存工作项。
向更改请求中添加超链接
在 所有链接 选项卡中,选择 链接到。
在 链接类型 列表中,选择 超链接。
在**“地址”**框中,执行下列操作之一:
如果目标是网站,请键入 URL,或者从 Internet 浏览器中复制该 URL,然后将其粘贴到**“地址”**框中。
如果目标是服务器位置,请键入其 UNC 地址。
(可选)在**“注释”**框中键入有关超链接的附加信息。
选择**“确定”**。
选择 保存工作项。
对更改请求的状态进行更改
会审团或产品规划会议可以审阅这些工作项以分析、接受或拒绝建议的更改。 更改请求得到接受后,团队可以生成任务来实现更改。 团队实现更改之后,将最终关闭更改请求。
有关可用于跟踪工作项状态的数据字段的更多信息,请参见指派、工作流和计划 (CMMI)。
可使用以下状态来跟踪更改请求的进度:
已建议
活动
已解决
已关闭
任何团队成员都可对更改请求的状态进行更改。
默认情况下,当您创建工作项时,每个更改请求都处于**“已建议”状态。 当团队接受当前迭代的更改请求时,工作项将改为“活动”状态,团队将对该工作项进行分析,确定其实现详细信息并创建任务。 当任务完成,并且系统测试显示团队已成功实现更改请求后,团队成员会将更改请求更改为“已解决”状态。 最后,当团队验证更改请求时,团队成员会将更改请求更改为“已关闭”**状态。
对更改请求的状态进行更改
打开更改请求。
在 状态 列表中,选择 活动、 已解决或 已关闭。
如果将状态从**“已建议”更改为“活动”,“原因”字段会自动更改为“已接受”**。
如果将状态从**“活动”更改为“已解决”,“原因”字段会自动更改为“代码完成且系统测试通过”**。
如果将状态从**“已解决”更改为“已关闭”,则“原因”字段更改为“验证测试已通过”**。
选择 保存工作项。
典型工作流进度:
非典型转换:
|
更改请求状态图 |
已建议(新建)
当团队发现 Bug 或另一个事件确定必须对已纳入变更控制的工作产品进行更改时,团队成员可以创建更改请求工作项。
在团队成员创建更改请求时会自动捕获以下数据字段:
创建者:创建更改请求的团队成员的名字。
创建日期:按服务按器时钟记录的创建更改请求时的日期和时间。
由“已建议”改为“活动”
更改请求描述对产品或基线的更改。 变更控制委员会必须审阅、调查以及接受或拒绝团队建议的每项更改。
由于下表中的原因,团队成员可以将更改请求从**“已建议”状态更改为“活动”**状态:
原因 |
何时使用 |
要采取的其他操作 |
---|---|---|
已接受 |
当变更控制委员会批准更改请求以供团队在当前迭代中实现时。 |
将更改请求指派给将实现更改请求的团队成员。 |
调查 |
当变更控制委员会认为在委员会接受请求之前必须先调查请求的影响时。 |
在调查完成后将更改请求恢复为“已建议”状态。 |
在团队成员将更改请求的状态更改为**“活动”**时会捕获以下数据字段:
激活者:激活更改请求的团队成员的名字。
激活日期:按服务器时钟记录的激活更改请求时的日期和时间。
状态更改日期:更改请求的状态更改日期和时间。
由“已建议”改为“已关闭”
由于下表中的原因,团队成员可以关闭处于**“已建议”**状态的更改请求:
原因 |
何时使用 |
要采取的其他操作 |
---|---|---|
已拒绝 |
当变更控制委员会认为团队无法实现请求或者客户不需要请求时。 |
无。 |
在团队成员关闭更改请求时会捕获以下数据字段:
关闭者:关闭更改请求的团队成员的名字。
关闭日期:按服务器时钟记录的更改请求的关闭日期和时间。
状态更改日期:更改请求的状态更改日期和时间。
活动
团队只应实现处于**“活动”状态的那些更改请求。 对于活动更改请求,团队成员应创建用于编写代码、测试和记录更改的任务。 当所有任务完成后,团队的成员会将更改请求更改为“已解决”**状态。 如果团队放弃了更改请求或认为更改请求超出范围,您也可以关闭更改请求。
由“活动”改为“已解决”
由于下表中的原因,团队成员可以解决活动更改请求:
原因 |
何时使用 |
要采取的其他操作 |
---|---|---|
代码完成且已测试系统 |
当团队已签入代码以实现更改请求并且所有系统测试已通过时。 |
将更改请求指派给将测试更改请求的团队成员。 |
在团队成员解决活动更改请求时会捕获以下数据字段:
解决者:解决更改请求的团队成员的名字。
解决日期:按服务器时钟记录的解决更改请求时的日期和时间。
状态更改日期:更改请求的状态更改日期和时间。
从活动到关闭
由于下表中的原因之一,团队成员可以关闭活动更改请求:
原因 |
何时使用 |
要采取的其他操作 |
---|---|---|
已放弃 |
认为不再需要实现更改请求时。 |
无。 |
超出范围 |
当团队没有足够的资源或另一个问题使团队无法实现当前迭代的更改请求时。 |
更新“迭代”字段以指定团队可能在哪个迭代中实现更改请求。 如果已将更改请求推迟到软件的下一版本,则将“迭代”字段留空,但要详细说明更改请求推迟的原因以及团队应在何时实现更改请求。 |
在团队成员关闭活动更改请求时会捕获以下数据字段:
关闭者:关闭更改请求的团队成员的名字。
关闭日期:按服务器时钟记录的更改请求的关闭日期和时间。
状态更改日期:更改请求的状态更改日期和时间。
由“活动”改为“已建议”
以**“调查”方式激活更改请求后,您在团队完成更改请求的调查后将其状态更改为“已建议”。 当您将活动更改请求的状态更改为“已建议”**时会捕获以下数据字段:
更改者:更改了更改请求状态的团队成员的名字。
状态更改日期:更改请求的状态更改日期和时间。
已解决
当团队实现更改请求后,开发人员主管将请求的状态设置为**“已解决”**,并将请求指派给测试人员,以便能开始测试。
解决的更改请求已实现,并且已通过系统测试。 但是,团队必须与客户一起验证解决的更改请求,以确保团队根据客户期望实现了请求。 如果验证测试通过,则团队将关闭更改请求。 否则,将重新激活更改请求以进行进一步的工作。
由“已解决”改为“已关闭”
由于下表中的原因,团队成员可以关闭解决的更改请求:
原因 |
何时使用 |
要采取的其他操作 |
---|---|---|
验证测试已通过 |
当更改请求已通过所有验证测试时。 |
将更改请求指派给产品所有者。 |
当团队成员关闭解决的更改请求时会自动捕获以下数据字段:
关闭者:关闭更改请求的团队成员的名字。
关闭日期:按服务器时钟记录的更改请求的关闭日期和时间。
状态更改日期:更改请求的状态更改日期和时间。
由“已解决”改为“活动”
由于下表中的原因,团队成员可以重新激活解决的更改请求:
原因 |
何时使用 |
要采取的其他操作 |
---|---|---|
验证测试未通过 |
当一个或多个验证测试指明一项或多项客户期望未得到满足时。 |
测试人员为测试失败创建 Bug,并将更改请求指派给开发人员主管,后者将确定如何解决问题。 |
当团队成员重新激活解决的更改请求时会自动捕获以下数据:
激活者:重新激活更改请求的团队成员的名字。
激活日期:按服务器时钟记录的重新激活更改请求时的日期和时间。
状态更改日期:更改请求的状态更改日期和时间。
已关闭
团队应该不会再处理已关闭的更改请求。 当变更控制委员会拒绝了更改请求,或团队已成功实现、核实和验证了请求后,更改请求将关闭。
如果某个已关闭的更改请求返回范围内,则团队的成员(通常为业务分析人员或项目经理)可以重新激活该更改请求。
从关闭到活动
由于下表中的原因,团队成员可以重新激活关闭的更改请求:
原因 |
何时使用 |
要采取的其他操作 |
---|---|---|
错误地关闭 |
团队成员意外关闭了更改请求。 |
确保更改请求的实现任务、测试用例和详细信息都定义清晰,并且足以支持其开发。 |
当团队成员重新激活关闭的更改请求时会自动捕获以下数据:
激活者:重新激活更改请求的团队成员的名字。
激活日期:按服务器时钟记录的重新激活更改请求时的日期和时间。
状态更改日期:更改请求的状态更改日期和时间。