毕业设计(论文)外文翻译

原文来源： Scott E. Donaldson, Stanley G. Siegel. Successful Software Development(2nd Edition)[M]. Publisher: Prentice Hall PTR, 2000

2020年 3 月 16 日

译文：

5.4结合审查进行软件审核

在第3章中，我们讨论了评审（即同行评审、技术编辑、独立产品保证和管理技术监督）如何成为组织的软件系统开发过程的一部分。在本章中，我们通过介绍和讨论以下产品和过程评审的分类，对第3章的评审进行了扩展:

• 管理评审

o产品程序跟踪

o过程程序跟踪

o产品技术监督

o过程技术监督

• 开发评审

o产品同行评审

o过程同行评审

o软件和软件相关文件的技术编辑

• 产品保证评审

o产品质量保证

o产品验证和确认

o产品测试和评估

o产品自我比较

o在产品层面的过程质量保证

o在项目层面的过程质量保证

正如我们前面所讨论的，这些产品和过程评审可以单独进行。现在，我们想要说明结合这些评论的价值。我们将这些合并的评论称为'软件审计'。下面的讨论表明，我们所说的评论是字典中所说的审计的一种形式。Audit的字典定义如下:

审计:对记录或帐目进行的官方检查，以检查其准确性[3]。

1. The American Heritage Desk Dictionary（波士顿，MA:Houghton Mifflin Company，1981年）。

与本书中的大多数概念一样，没有一种方法可以将这些审查结合起来用于软件审计。[4]我们讨论了一种方法，为您提供了一个起点，以便以对您的组织有意义的方式将这些审查结合起来。我们选择将软件审核细分为以下两种类型:

1. 审计的范围取决于许多因素。因此，审核可以由单个产品或过程审查组成。
   • 软件产品审计。

在软件系统开发项目中，卖方开发产品。卖方将产品与客户要求的产品进行比较。如果比较产生差异，则更改产品（和/或客户要求的产品），直到差异得到解决。将软件产品与其他产品进行比较，以确定这些产品是否在逻辑上得到了开发，是否与客户要求的一致，这就是我们所说的'软件产品审核'。

正如本节所讨论的，软件产品审核包括由产品保证执行的四种软件产品评审的一些组合，即产品质量保证、产品验证和确认、产品测试和评估以及产品自我比较。我们将讨论软件产品审核如何与CCB相结合。

• • 软件过程审计。

卖方使用软件系统开发流程开发项目所需的产品。随着项目的展开，卖方可以将项目的软件系统开发过程与组织过程进行比较。此外，卖方可以将项目流程与与客户谈判达成的协议中的内容进行比较。这些比较就是我们所说的'软件过程审计'。

正如本节所讨论的，软件过程审核包括由管理、开发和产品保证执行的四种过程评审的某种组合，即过程方案跟踪、过程技术监督、过程同行评审和过程质量保证。我们将讨论如何将软件过程审核与软件开发组织和过程工程组结合起来。

在继续讨论审计之前，我们需要补充一点。你所说的各种比较并不重要，你可能会将其纳入你的经营方式。除了评论和/或审计之外，您可能希望将您的比较称为其他东西，因为您的业务文化在不同的意义上使用这些术语。从我们定义它们的方式。您可能希望像我们在本章中所做的那样，区分单独的比较和组合的比较。关于审查和审计的底线如下:

应进行这种比较，以便了解正在开发的产品和用于开发这些产品的过程的进展情况。有了这种可见性，项目参与者就可以就下一步做什么做出明智的、有根据的决定，从而增加了成功进行软件开发的可能性。

软件产品审计

每当生成并冻结软件产品草案、软件相关产品、变更请求（Cr）或事件报告（IR）时，就会开始软件产品审核。审计过程以向变更控制委员会提交审计报告结束。

图5-22说明了文档的软件（相关）产品审计是如何与CCB结合在一起的。[5]注意，这个过程独立于任何特定的生命周期模型。该软件文档草案提交给产品保证组织[6]，以便与文档的基本事实进行比较（即审计）。审计本身会将软件产品草案与实际情况进行比较。

1. CRS和IRS遵循相同的软件产品审核流程。有关CRS和IRS如何与CCB相结合的详细讨论，请参阅第4章。
2. 独立的产品保证组织是我们推荐的选择，用于执行产品与实际情况的比较。如果您的组织没有独立的产品保证组织，则此比较应由未构建该产品的个人或组织执行。

图5-22该图显示了软件和软件相关产品的审核过程的概述。

软件文档的基本事实由批准的需求规格说明、批准的生命周期阶段n-1产品组成。（即:、前身产品）和产品标准。请注意，基本事实可用于质量保证检查。（即:、软件产品与产品标准的比较），以及验证和确认检查（即:软件产品与前代产品和需求的比较）。此外，在软件产品审核中，还会例行地将软件文档与其自身进行比较。您可以结合QA、Vamp;V和自我比较技术来进行软件产品审核。

作为这种比较的结果，可以发现软件产品草案与基本事实之间的差异。这些差异记录在软件产品审计报告中，并提交给变更控制委员会进行处置。图523描述了软件产品审计报告的建议格式。

产品审核报告由以下部分组成:

引言、参考文献、程序、发现、结论和建议。在审计报告中注意，审计员的客观发现（即第4节）与审计员的主观意见（即第5节和第6节）明确分开。还注意到，除了质量保证、核查和验证以及自我比较过程发现的差异外，可追溯性矩阵的开发可能会发现各种差异。

1. 可追溯性矩阵是一种文档，它将需求规范中的每个软件部分追溯到每个后续软件产品中的相应软件部分，并追溯到测试文档，测试文档的执行验证了软件部分中包含的需求。

商业罪案调查科在收到审计报告后采取的第一项行动是处理未发现的差异。变更控制委员会记录和处理差异的方法包括:

• • 将整个产品审核报告分配给开发组织进行分析；生成的分析报告为每个差异提供建议的解决方案。
  • 将差异分为明显解决的差异和不明显解决的差异；立即处理前一类；为后一类中的每个差异创建一个IR；[8]有选择地创建IRS比不创建IRS就处理审计报告提供了更好的可见性和可追踪性。然而，这种可见性和可追踪性的提高是有代价的:处理和处理IRS需要更多的资源。

1. 章部分讨论了事件报告（IRS）的更改控制流程。

4使用图4-10。开发人员完成IR的分析部分，CCB制作其

如果变更获得批准，则使用软件变更通知（SCN）来发布该变更。

bull;为产品审计报告中的每个差异创建IR；处理国税局。这些IRS就像使用部署的系统导致的事件所创建的IRS一样被处理和处理。仍采用此方法编制产品审核报告，但无需报告审核中发现的差异。在这里，产品审计报告只是简单地将差异汇总并归类为IRS。同样，由于该方法提供了更高的可见性和可追踪性，有一个增加的价格支付处理和处理国税局。注意，每个IR的处理都需要时间和金钱，即使IR记录的差异影响很小，其解决方案也是显而易见的。

图5-23这里是软件产品审计报告的建议格式。

这三种方法按可见性、可跟踪性、成本和时间的升序排列。如果人的生命处于危险之中，并且/或者有可能造成巨大的财务损失，您可能希望使用第三种方法的某种形式，即为每个差异创建IR。在项目启动之初，建设银行在确立经营模式时，应仔细权衡这三种方式的利弊。

一旦选择了一种方法，将对差异进行分析，随后分析器将向CCB提交针对每个差异的建议解决方案。根据分析报告中提供的建议解决方案，CCB继续对产品审计报告中的每个差异做出决定。这些决定记录在商业罪案调查科的会议记录中。

建设银行根据开发商的产品审计报告和分析，决定:或者不需要对草稿产品进行更改，或者确实需要对草稿产品进行更改。如果不需要改变或只有少数影响相对较小的改变仍未解决，国家创新系统生命周期阶段的产品草案获得批准，并被确立为基准。[9]如果需要更改，变更控制委员会指示的修改将在当前阶段对生命周期阶段N的产品草案进行。或者重新访问前几个阶段以更改实际的软件文档，需求规格或以前阶段批准的产品。当对阶段N的草案产品进行更改时，草案产品在更改后将重新引入产品审核流程。当重访前一阶段时，更新该阶段的已批准产品，并启动重新审查阶段的产品审核流程。这样的重访耗费时间和金钱，但这些重访就是可维护性的全部。产品草案通过产品审核和控制流程循环多次，直到CCB决定不对草案PR进行更改。或者剩余未解决的差异很少，影响很小。在这两种情况下，产品是基线。

1. IRS可能要求对产品草案进行小的或大的更改。建设银行可以决定暂不变更汇票产品。无论如何，IRS和相应的变化都需要跟踪。最终，需要解决每个IR—例如，CCB决定进行更改（因为IR），CCB决定在将来进行更改，或者CCB决定永远不会进行更改。

软件产品审核适用于所有软件产品，无论软件是文档还是计算机代码。但是，根据软件是文档还是代码，过程的细节存在差异。这些差异将在以下示例中进行说明。在展示软件产品审计示例之前，我们将更详细地讨论可能发现的产品差异的性质。

必须注意的是，产品差异并不一定代表软件产品有问题。简单地说，差异就是将软件产品与实际情况进行比较时所观察到的不一致。当然，差异可能表示软件产品中存在错误。但是，差异也可能代表着与基本事实不符的东西。如果基本真理是不正确的，它必须被纠正，然后被重新建立为基本真理。此外，差异可能产生于误解或源于基本事实的无效假设。在这种情况下，应澄清基本事实，并修改软件产品以反映基本事实的澄清。最后，差异可能并不真正代表软件产品与实际情况之间的不一致。根据对差异的分析，确定存在对基本事实和/或软件产品的误解。这个矛盾不是矛盾，是错误。

1. 不协调就是缺乏一致性；也就是说，不协调是软件产品中的一部分，不能与另一软件产品、相关软件产品或其本身的任何部分相关联。

考虑这样一种情况:审计师不确定是否存在不一致。如果审计师没有报告这种可能的不一致，而这种不一致确实存在，那么不一致就不会显现出来。因此，审计师在面对这种情况时，应该报告可能的不一致。变更控制委员会论坛中的其他项目人员应能够解决是否存在差异的问题。如果不存在，则干脆被建行拒绝。这种'有疑问就报告'的做法是为了防止出现漏洞。然而，这种做法不应走向极端。引入过多无意义的差异浪费时间和金钱。

管理人员尤其应该意识到，每个差异并不一定代表被审计的软件产品有问题。我们经常看到忙碌的经理们纯粹根据软件产品中发现的差异数量来评估新的软件产品。UCT审计，就好像每一个差异都代表着新产品中的一个错误。前面的段落显示了这样的评估可能是多么不公平——差异可能代表新产品的问题。与地面真相的问题，或根本没有问题。如果管理者不是基于审计报告中的差异数量，而是基于中国建设银行并购的决策，那么管理者可以做出更好的评估。KES关于审计发现的差异。对此类决策的分析将揭示对软件产品和实际情况要进行多少更改以及更改的实质性程度。

这一信息将比审计报告中的差异计数更好地评估新的软件产品。在评估软件产品或实际情况时，不应考虑导致未对任何产品进行更改的差异。

应以具体、客观和中性的方式报告差异，并应包含解决差异的理由。在指定软件部件时，差异应是具体的。—在被审核的软件产品中和/或在实际情况中—不一致的地方，以及不一致的地方是什么。矛盾报告应当客观陈述事实，既不发表意见，也不作假设。差异报告应该是中立的，因为它不能断言软件产品或基本事实是错误的，但只是它们不同而已。措辞恰当的差异不应包括这样的陈述:

• '文件第一节措辞不当，因此难以理解。'
• '可靠性要求是荒谬的。编写它的人显然不了解软件是如何操作的。'
• '尽管设计满足其所有要求，但在我看来，数据库检索功能的设计过于繁琐，无法以最佳方式发挥作用。'

软件产品审核寻求确定（1）软件产品中的每个部分是否在前一产品中有前因，以及相反，（2）该前一产品中的每个部分是否在软件产品中有后续部分。通过这种双向比较，审计可以确定两种产品的一致程度。

^{[11]当一种或两种产品都是与软件有关的产品（例如，需求规格[软件产品]和用户手册[}

剩余内容已隐藏，支付完成后下载完整资料

资料编号：[255305]，资料为PDF文档或Word文档，PDF文档可免费转换为Word