MSF for CMMI 中的错误和更改请求之间有啥区别？

Posted 2023-03-22

【中文标题】MSF for CMMI 中的错误和更改请求之间有啥区别？

【英文标题】：What is the difference between a bug and a change request in MSF for CMMI?MSF for CMMI 中的错误和更改请求之间有什么区别？

【发布时间】：2010-09-05 12:59:46

【问题描述】：

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

我了解在生成报告时能够区分错误（错误）和更改请求（更改需求）是有益的。

然而，在我们当前的系统中，我们只有单一类型的变更请求，并且只使用一个字段来指示它是否是错误、需求变更等（该字段可用于构建报告查询）。

为错误设置单独的工作流程有什么好处？

我还对开发人员可以针对错误或更改请求提交工作这一事实感到困惑，我认为预期的工作流程是让错误生成更改请求，这是开发人员在进行更改。

【参考方案1】：

@卢克

我不同意你的观点，但这种差异通常是解释为什么有两种不同的流程可用于处理这两种类型的问题。

我想说的是，如果主页的颜色最初设计为红色，但由于某种原因它是蓝色的，那么这很容易解决，不需要很多人或工时来做改变。只需签出文件，更改颜色，重新签入并更新错误。

但是，如果主页的颜色被设计成红色，而且是红色，但有人认为它需要是蓝色的，那无论如何对我来说都是一种不同的变化。例如，是否有人考虑过这可能对页面的其他部分产生影响，例如覆盖蓝色背景的图像和徽标？会不会有看起来很糟糕的事物的边界？链接下划线是蓝色的，会显示吗？

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

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

然而，一个错误是有人说我们将这样做，然后有人又做了不同的事情。

变更请求更像是，但我们还需要考虑其他事情......嗯......。

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

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

我同意在这种情况下，是否将其视为设计缺陷或实施缺陷取决于其未能达到预期的实际原因。例如，如果有人假设磁盘的速度是实际速度的 100 倍，而这被认为是服务器无法按预期运行的原因，我会说这是一个设计错误，有人需要重新设计.如果仍要保持这么多页面浏览量的原始要求，则可能必须进行重大的重新设计，包括更多的内存数据和类似的数据。

但是，如果有人刚刚没有考虑到 RAID 磁盘的运行方式以及如何正确地从条带化媒体中受益，这就是一个错误，可能不需要进行那么大的更改来修复。

同样，当然会有例外。

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

【参考方案2】：

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

所以 - 一般而言 - “变更请求”将由组织中相对较高的人发起和批准（具有与花费资源对系统进行（可能非常大的）变更相关的“赞助”权利的人） . 最终，此人将是批准更改成功的人。

但是，对于“Bug”，应用程序的任何用户都应该能够发起 Bug。

在我实施 TFS 的组织中，只有部门负责人可以成为“变更请求”的发起者 - 但“错误”是从“服务台”工单创建的（不是自动化的，只是通过流程......）

【参考方案3】：

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

错误是您的程序实现中的缺陷。例如，如果您将程序设计为能够将两个数字相加并给用户一个和，那么缺陷将是它不能正确处理负数，因此是一个错误。

更改请求是指您有设计缺陷。例如，您可能已经明确表示您的程序不应该处理负数。然后提交更改请求以重新设计并重新实现该部分。设计缺陷可能不是故意的，但很可能是因为您在最初设计程序时没有考虑该部分，或者在创建原始设计时不存在的新案例已被发明或发现从那时起。

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

---

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

因此可能需要不同的工作流程来处理这两种不同的场景。例如，您确认和提交错误的方式可能与变更请求不同，这可能需要更多的工作来说明变更的后果。

【参考方案4】：

错误是已被批准实施的需求中出现的问题。

变更请求需要经过一个周期，在该周期中，必须估计该变更的影响和工作量，然后必须批准实施，然后才能开始工作。

两者在 CMM 下有着根本的不同。

【参考方案5】：

我的假设是否不正确，即变更请求应该由错误生成？我很困惑，因为我不认为所有的错误都应该被自动批准实施——它们可能是微不足道的，至少在我们的案例中，在分配给开发人员之前，它们会经历与变更请求相同的审查过程。

【参考方案6】：

实施总是来自需求。它可能来自产品经理，也可能来自你们中的一些人的随机想法。它可能被记录在案，它可能来自一些对话。归根结底，即使是像a := a + 1 这样简单的东西，“真正的”实现也将基于编译器、链接器、CPU 等，这取决于现实生活中的物理规律。

错误是针对原始要求实施的。除此之外，这是一个变更请求。

如果需求改变了，实现也需要改变，那就是变更请求。

如果依赖已经改变，例如浏览器停止支持某些标签，你需要做一些改变，这是一个改变请求。

实际上，任何未正确记录的内容都应视为变更请求。产品经理忘记在故事中添加内容？抱歉，这是一个更改请求。

应正确估计和指出所有变更请求。开发人员通过提出变更请求获得报酬，而不是因为提出错误和修复他们提出的问题。