对于CMMI,MSF中的bug和变更请求有什么区别?

@卢克

我不同意你的看法,但这一区别通常是解释为什么有两种不同的流程可用于处理这两种类型的问题。

我想说,如果主页的颜色最初设计为红色,并且出于某种原因是蓝色,那么这很容易是一个快速解决方案,不需要很多人或工时来进行更改。只需签出文件,更改颜色,重新签入并更新bug。

然而,如果主页的颜色被设计成红色,并且是红色的,但是有人认为它需要蓝色,也就是说,对我来说,无论如何,一种不同的变化类型。例如,是否有人考虑过这可能对页面其他部分产生的影响,比如覆盖蓝色背景的图像和徽标?会不会有些事情看起来很糟糕?链接下划线是蓝色的,会出现吗?

举个例子,我是红/绿色盲,对我来说,改变事物的颜色并不是我轻视的事物。网上有足够多的网页给我带来问题。只是为了说明一点,即使是最微不足道的改变,如果你考虑到每件事,也可能是不平凡的。

实际的最终实现更改可能大致相同,但对我来说是一个更改请求 是 一只不同的野兽,正是因为它需要更多的思考,以确保它能像预期的那样工作。

不过,有人说这是个错误 我们就是这样做的 然后有人做了不同的事情。

变更请求更像是 但我们也需要考虑另一件事…隐马尔可夫模型。。。 .

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

如果服务器是 设计 要处理超过300000000000个页面视图,那么是的,这是一个错误,但设计一个服务器来处理这么多页面视图不仅仅是说 我们的服务器应该能够处理300000000个页面视图 ,它应该包含 非常 详细说明如何做到这一点,包括处理时间保证和磁盘访问平均时间。如果代码的实现与设计完全相同,并且无法按预期执行,那么问题就变成: 我们是错误地设计了它还是错误地实现了它? .

我同意在这种情况下,它是设计缺陷还是实现缺陷取决于它未能达到预期的实际原因。例如,如果有人假定磁盘的速度是实际速度的100倍,而这被认为是服务器无法按预期运行的原因,我会说这是一个设计错误,需要重新设计。如果许多页面视图的原始需求仍然需要保留,那么可能需要进行一次具有更多内存数据和类似数据的重大重新设计。

但是,如果有人没有考虑到RAID磁盘的运行方式以及如何正确地从带区介质中获益,那么这是一个错误,可能不需要进行那么大的更改来修复。

当然,也会有例外。

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

请记住,tfs的工作项类型定义的一部分是其“工作流”的定义,这意味着工作项可以是的状态以及状态之间的转换。这可以由安全角色保护。

因此,一般来说,“变更请求”将由组织中相对较高级别的人员(具有与花费资源对系统进行(可能非常大)变更相关的“赞助”权限的人员)发起和批准。最终,这个人将是批准成功进行更改的人。

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

在我在实施TFS的组织中,只有部门主管可以是“变更请求”的发起人,但“错误”是从“帮助台”记录单创建的(不是自动的,只是通过流程…)

一般来说,虽然我不能代表CMM,但是变更请求和bug的处理和考虑是不同的,因为它们通常涉及应用程序生命周期的不同部分。

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

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

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

通常,修复bug被认为是比执行变更请求便宜得多的操作,因为bug从来没有打算成为程序的一部分。然而,设计是。

因此,处理这两个不同的场景可能需要不同的工作流。例如,与变更请求相比,您可能有不同的确认和归档错误的方法,这可能需要更多的工作来安排变更的后果。

一个bug是在一个已经被批准实施的需求中被打破的东西。

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

在CMM下,这两种情况根本不同。

我的假设是错误的,那么变更请求应该由bug生成吗?我很困惑,因为我不认为所有的bug都应该被自动批准来实现——它们可能是微不足道的,至少在我们的情况下,在分配给开发人员之前,它们将经历与变更请求相同的审查过程。