您放在影响分析文档上的内容是什么？

因此，您要修复错误，然后遇到一个可能会影响软件产品其他模块的错误。您的数据不足以支持您对修复效果的主张，因此您被要求创建影响分析文档。

1. 是否有明确的流程来做到这一点？
2. 需要哪些关键信息？
3. 该文档有任何已知的格式/模板吗？

我看到的用于影响分析的模板是在我工作的公司内部制作的。我们使用它来评估变更请求，然后再处理它们（并可能拒绝某些变更请求）。它具有如下部分：

• 对需求的影响：在此部分中，分析师会写出用例中需要更改的内容以支持所请求的更改。
• 对设计和体系结构的影响：在这一部分中，架构师和设计人员提到需要修改或重做模型的哪些部分以支持更改。
• 对测试的影响：QC编写了需要更新的测试用例。
• 估算和对进度的影响：项目经理估算所需的工作量，变更成本以及对项目进度的影响。

为了涵盖所有可能的影响，您需要遍历依赖项。如果您具有双向可追溯性矩阵，它将使其更容易。

我们使用上述顺序是因为设计人员需要从分析师的角度了解影响，以便更好地了解更改，而测试人员也需要了解分析师和架构师的意见。同样，PM需要所有信息来了解成本和进度。

我们将其与CR一起使用，但是您可以以相同的方式将其与错误一起使用。另外，如果您需要在多个解决方案之间进行选择以解决该错误，则需要对每种可能的解决方案重复进行影响分析，并将所有数据合并为一个“决策分析和解决方案（DAR）”表格，以了解哪种解决方案是最好的。在DAR表格中，您应该添加一些评估因素，例如将来的可维护性或影响分析中未隐含的其他因素。然后给出每个因子的权重，并给出每个因子的每个解分数。最后乘以总和*权重并选择最佳。请注意，成本可能包含在因素中，或者PM可能有其他意见。

我相信任何文档都认为敏捷方法是一种好方法。现在，存在一些误解，认为敏捷意味着“根本没有文档或分析”，但事实并非如此。我所读到的有关敏捷的东西说：“使用有效的工具”。我认为这意味着该文档的长度和详细程度应与任务相称。

模板可以作为检查清单很有用，但是我不需要为小的或低风险的更改填写每个部分。对于单行更改，也许您根本不需要文档。我从未使用过影响分析文档的模板，但我经常处理业务需求或技术规范。模板可能过于严格；一个好的指导方针是考虑受众是谁。如果是针对非技术人员的经理，请集中精力进行变更的业务理由。如果是技术人员，请提供一些背景知识，以使团队中的新人不会迷路，并在他们必须支持变更的情况下给予他们足够的工作机会。另外，如果您想要更轻松，更轻巧的东西，请不要使用任何文档，而应将其放在Wiki中。

信息包括：

• 问题简要说明
• 解释或显示缺陷如何导致故障和/或效率低下的示例
• 包括复杂度估算
• 包括估计的成本和修复时间

这是一个不错的下限。在另一篇文章中，重点介绍了IBM大量的CMMi内容；如果您有足够的时间和资源来做，那很棒，并且（当您为危及人类生命的NASA构建系统时，人们最好对此认真对待），但是对于小型团队，您可能不需要那么重。与往常一样，小心估计。管理者倾向于假设估计是实际的。

注意，敏捷方法存在危险。一些开发人员确实认为这意味着“不需要任何文档，只需开始破解即可”（在某些情况下可能会很好）。另外，其他人会为任务分配自由度，只写那些毫无用处的糟糕文档（在大多数情况下不一定可以）。问题的一部分是写得好需要一些努力，技巧和时间。我们大多数人至少在其中两件事上是不够的；）

我一直在文档编制方面做了大量工作，因为它证明您至少投入了足够的思想来制定计划。但是，在我晚年的时候，我也开始意识到太多的文档本身会成为维护的麻烦，而且没有足够的人在意更新文档。

实际上，在大型项目中确实需要“影响分析”文档，特别是在程序员在不同位置进行地理工作的地方。

影响分析文档应得到潜在客户的批准，以确保所做的更改不会影响在生产中可以正常工作的其他组件。

需要进行影响分析以确保完全理解该要求，并确定所有要更改的组件，以避免重复工作

客户利益相关者也需要进行影响分析以确保问责制。否则，在部署后发生问题时，开发人员将成为替罪羊。

影响分析是估算的基础。没有这个估计就没有任何根据。它可能太高或太低。通过Impact Analysis，如果实际工作量超过了，也很​​容易解释。

在这里，您具有影响分析报告的标准模板。它是为特定行业分支而定制的，但是尽管如此，它还是有用的部分，可以作为您编写自己的文档的灵感。

链接：http： //www.itu.int/en/itu-d/projects/documents/templateimpactanalysis.pdf

干杯