MSF中针对CMMI的错误和更改请求之间有什么区别?

目前,我正在评估 TFS 下的 MSF for CMMI 流程模板以供我的开发团队使用,并且我无法理解单独的错误和更改请求工作的需求项目类型。

我知道,在生成报告时能够区分错误(错误)和更改请求(更改需求)是有益的。

但是,在我们当前的系统中,我们只有一种类型的更改请求,只是使用一个字段来指示它是否是错误,需求更改等(此字段可用于生成报告查询)。

为错误提供单独的工作流程有什么好处?

我也对开发人员可以针对bug 更改请求提交工作这一事实感到困惑,我认为预期的工作流程是针对错误生成更改请求,这些更改请求是开发人员在进行更改时引用的内容。

0

5 答案

我的假设是不正确的,那么更改请求应该从错误中产生?我很困惑,因为我认为所有的错误都不应该被自动批准实施 - 它们可能是微不足道的,至少在我们的情况下,在被分配给开发人员之前,将经过与更改请求相同的审查过程。

0
额外

一个错误是在已被批准实施的要求中被破坏的。

变更请求需要经历一个周期,在该周期中必须为该变更估计影响和努力,然后在开始工作之前必须批准实施。

这两者在CMM下根本不同。

0
额外

通常,虽然我不能说CMM,但更改请求和错误的处理方式和考虑因素通常不同,因为它们通常指的是应用程序生命周期的不同部分。

缺陷是您程序实施中的缺陷。例如,如果你设计你的程序能够添加两个数字并给用户总和,那么缺陷是它不能正确处理负数,从而导致错误。

当你有设计缺陷时,变更请求是。例如,你可能特别说过你的程序不应该处理负数。然后提交变更请求以重新设计并重新实现该部分。设计缺陷可能不是有意的,但可能很容易,因为当你最初设计你的程序时你并没有考虑到这个部分,或者创造或发现了创建原始设计时并不存在的新案例以来。

换句话说,一个程序可能按照设计完全运行,但需要改变。这是一个变更请求。


通常情况下,修复错误被认为比执行更改请求要便宜得多,因为该错误从未打算成为程序的一部分。然而,设计是。

因此,处理两种不同的情况可能需要不同的工作流程。例如,您可能有不同的确认和归档错误的方式,而不是您对变更请求的确认和归档,这可能需要更多工作来阐明变更的后果。

0
额外

@Luke

我并不反对你,但这种差异通常是为什么有两种不同的过程可用于处理这两类问题的解释。

我想说,如果主页的颜色最初设计为红色,并且由于某种原因它是蓝色的,那么这很容易很快修复,并且不需要涉及许多人员或工时来完成更改。只需检查文件,更改颜色,检查并更新错误。

但是,如果主页的颜色设计为红色,并且是红色的,但是有人认为它需要蓝色,也就是说,对我来说,是一种不同类型的更改。例如,是否有人想过这可能会对页面的其他部分产生影响,如覆盖蓝色背景的图像和徽标?难道有东西看起来很糟糕的边界吗?链接下划线是蓝色的,会显示出来吗?

作为一个例子,我是红/绿色盲,改变某种东西的颜色对我来说并不是我轻视的东西。网络上有足够的网页,给我带来问题。只是要指出,即使是最微不足道的变化,如果你考虑所有事情,也可能是不平凡的。

实际的最终实现变化可能大致相同,但对我而言,变更请求不同的野兽,正是因为需要更多地考虑变更请求以确保其按预期工作。

然而,一个错误是有人说这是我们要做的,然后有人以不同的方式做。

更改请求更像,但我们还需要考虑另一件事......以及......

当然也有例外,但让我把你的例子分开。

如果服务器被设计为处理超过300,000,000,000次综合浏览量,那么是的,这是一个它没有的错误。但设计一个服务器来处理这么多的综合浏览量不仅仅是说我们的服务器应该处理300,000,000,000个综合浏览量,它应该包含一个非常详细的规范说明它是如何做到的,正确的直至处理时间保证和磁盘访问平均时间。如果代码完全按照设计实现,并且无法按预期执行,那么问题就会变成:我们是否设计不正确,或者我们是否实现了错误?

我同意在这种情况下,它被认为是设计缺陷或实施缺陷取决于为什么它不能达到预期的实际原因。例如,如果有人假定磁盘的速度是其实际速度的100倍,并且这被认为是服务器无法按预期执行的原因,但我认为这是一个设计错误,有人需要重新设计。如果仍需要保留许多综合浏览量的原始要求,则可能需要进行一次包含更多内存数据和类似内容的重大设计。

但是,如果有人刚刚没有考虑RAID磁盘如何操作以及如何从条带化媒体中正确获益,那就是一个错误,可能不需要那么大的修改来修复。

再次,当然会有例外。

无论如何,我所说的原始差异是我发现在大多数情况下都是真实的。

0
额外

请记住,TFS的工作项类型定义的一部分是它的“工作流”定义,这意味着工作项可以是状态以及状态之间的转换。这可以通过安全角色来保证。

所以 - 一般来说 - 一个“变更请求”将由组织中相对较高的人发起和批准(某人拥有“支持”权利与花费资源对系统进行(可能非常大的)更改有关人将是批准变更成功的人。

但是,对于“Bug”,应用程序的任何用户都应该能够启动一个Bug。

在我实施TFS的组织中,只有部门负责人可以成为“变更请求”的发起人 - 但是,“错误”是从“帮助台”门票创建的(不是自动化的,只是通过流程...)

0
额外