5.3 产品与过程评审分类

本章中描述的评审主要与卖方开发团队相关。如图5-4中以深灰色突出显示的区域所示，产品和过程评审涉及卖方项目经理、主要开发人员、产品保证经理、技术编辑、卖方管理层和变更控制委员会（CCB）。

图5-4本章讨论的重点是关键软件产品和软件系统开发过程评审。卖方开发团队在项目层面执行这些审查。

由于许多产品和过程评审支持CCB活动，客户也参与了这些评审活动。此外，由于这些审查可以与任何软件系统开发过程相结合，阅读本章的买方/用户可能希望将这些概念纳入其对卖方服务的请求中。

图5-5本章介绍了项目级别的关键管理，开发和产品保证审查。 评论分为两大类：产品和过程。

我们的审查分类法解决了与降低软件系统开发风险相关的可见性问题。我们分类法中的每一个评论都提供了对软件开发项目状态的洞察。这种洞察力有助于客户和/或开发人员就下一步做什么做出明智、明智的决策。

图5-5中所示的分类法和分类法中的条目旨在作为您设计自己的审核分类法和条目集的起点。例如，分类法将同行评审和技术编辑显示为开发人员执行的软件产品评审；未显示开发人员执行的测试类型。

单独工作的开发人员通常在系统级以下执行测试级别，例如测试可单独编译的计算机代码的逻辑结构。从评审的角度来看，我们认为这种测试活动是一种“自我评审”，也就是说，评审只涉及被评审产品的创建者。我们在图5-5中没有显示这样的“自我评价”。另一方面，如果开发人员邀请其他人（如其他开发人员）见证并随后对此类测试发表评论，则该活动可被视为同行评审（带有产品和过程评审的含义）。

如果图5-5所示的分类法补充了您的组织，那么您可以列出相应的分类法条目集。此集合可以（1）包括所示的某些条目，（2）删除某些条目（例如，您可能不将技术编辑视为审阅的一种类型；而只是文档生成过程的一部分），和/或（3）包括新条目（例如，开发人员执行的测试类型、开发人员执行的项目跟踪类型）。

如果图5-5所示的分类法不能补充您的组织，那么您可以使用该分类法来帮助您提出如何构建一个更适合您的环境的分类法的想法。例如，您可能没有执行质量保证、测试和配置管理的集成产品保证组织。相反，您可能有一个质量保证组织、一个测试组织和一个配置管理组织。

在这种情况下，您可能希望用三个单独的行替换分类法中的产品保证行，一个用于质量保证，一个用于测试，一个用于配置管理。然后，在测试行中，例如，您可能在软件产品列中拥有测试组织执行的测试类型。您的测试组织可能负责所有测试，在这种情况下，开发人员可能不会执行任何测试。或者，您的测试组织可以执行补充和补充开发人员执行的测试的测试。

在本书中，我们断言没有一种方法可以进行软件系统开发。 无论选择哪种方式定义评审分类法及其条目，评论都应使您可以了解正在开发的产品以及开发这些产品所使用的过程。

如图5-6所示，软件产品评论涉及互补的管理，开发和产品保证观点。 例如，管理人员可能会提出程序跟踪问题，例如以下问题：“产品是否按时且在预算之内开发？” 开发人员可以在同行评审中检查软件产品的技术细节，并向主要产品开发人员提供建议。 产品保证审阅者可以检查软件产品是否符合既定标准。 每次审查都满足不同的可见性需求。

图5-6软件产品评论解决了编程，技术，社论和一致性问题。

正如不同类型的产品评论提供产品的补充视图一样，不同类型的过程评论也提供了项目软件系统开发过程的补充视图。 如图5-7中的问题所建议，这些视图满足不同的可见性需求。

图5-7项目软件系统开发过程审阅解决了编程，技术和一致性问题。

在以下各节中，我们将从管理，开发和产品保证的角度介绍产品和过程审查。

管理评审

管理层针对特定软件产品提供以下类型的程序化跟踪和技术监督：

bull; 项目经理跟踪产品开发的成本和进度。 通过这种程序化跟踪，可以查看围绕产品开发的成本和进度问题。 项目经理提出以下问题：产品开发落后吗？ 是否出现了计划外成本，这会影响按时交付产品的预算吗？

• 项目经理的管理层（或其他高级管理层）定期提供对特定软件产品的技术监督。 高级管理层开始参与产品开发，以指导项目经理以预测产品开发遇到的困难（例如，由客户引起的需求攀升，而客户难以专注于产品的具体细节或卖方开发人员对客户的需求产生误解）。 技术监督的数量是管理的特权，并且与产品的复杂性，大小和重要性有关。 这种监督有助于项目经理重复以前的成功。 对于项目具有多个管理层的情况，项目经理为任务负责人（即下一个较低的管理层）提供技术监督。

管理层对项目的软件系统开发过程提供以下类型的程序化跟踪和技术监督：

• 项目经理以编程方式跟踪项目软件系统的开发。 通过程序化跟踪，可以查看整个项目的成本和进度问题（与产品特定问题相比）。 项目经理提出以下问题：项目是否落后？ 我的交付成果总是迟到吗？ 是否出现了计划外成本，这些成本会影响按时交付项目剩余产品的预算吗？
• 项目经理的管理层（或其他高级管理层）定期为特定项目提供技术监督。管理层参与到一个项目中来，指导项目经理预测项目软件系统开发的不利因素（例如，盲目遵守开发过程导致的分析瘫痪，或开发人员与买方/用户之间缺乏有效和及时的沟通）。技术监督的数量是管理特权，与项目的复杂性、规模和重要性有关。这种监督有助于项目经理重复以前的成功。对于项目有多个管理层的情况，项目经理向任务负责人（即下一个较低的管理层）提供技术监督。

管理产品和过程评审的例子在下面的章节中介绍。

产品程序跟踪

图5-8解决了以下类型的产品程序跟踪问题：产品是否在预算内按时开发？文中给出了程序跟踪差异的两个例子。其中一个差异涉及进度的延误，因为首席开发人员被叫出了办公室。幸运的是，在本例中，产品的交付不在项目的关键路径上，交付可能会下滑一周，而不会影响整个项目。第二个差异涉及由于设计规范的同行评审和产品保证评审而导致的进度加速。

图5-8产品程序跟踪有助于深入了解计划与实际的进度和资源产品开发问题

在将正在开发的产品与控制该产品开发的成本和进度进行比较的过程中，可能会报告（或发现）这种差异。最初应在项目计划中规定的成本和进度，作为项目标准。该产品程序检查提供了一种确定（1）是否应调整标准（即，是否应更改计划或预算，或两者兼有）或（2）是否应调整产品（即，是否应增加或减少产品要求）的方法。当在整个项目中执行以及与其他评审一起执行时，这些程序性检查有助于在客户和卖方对产品的期望之间实现一致。

过程程序跟踪

图5-9解决了以下类型的过程程序跟踪问题：项目过程的应用是否与项目预算和进度一致？以下三个过程方案跟踪差异的例子如下：（1）预计预算超支，（2）进度变更，和（3）范围缩小。所示时间线用于项目的四个月部分，涉及两种产品和一种服务；时间线表示计划的时间表。所示的差异报告假定是在1999年12月产品5完成之前的某个时间编写的

图5-9产品程序跟踪有助于深入了解整个项目涉及的计划与实际进度和资源问题。

在将正在进行的项目与管理该项目的成本和进度进行比较的过程中，可能会报告（或揭示）这种差异。最初应在项目计划中规定的成本和进度，作为项目标准。该过程程序检查提供了一种方法，用于确定（1）是否应调整标准（即，是否应更改计划或预算，或两者兼有）或（2）是否应调整项目（即，是否应扩大或削减项目范围）。当在整个项目中执行时，这些项目级的程序性检查有助于在客户和卖方对整个项目的期望之间取得一致。

产品技术监督

图5-10解决了以下类型的产品技术监督问题：您是否考虑过如何解决以下问题：（1）。，（2）。，和（3）？文中给出了两个产品技术监督的例子。在卖方管理层有机会审查产品后，但在向客户展示产品之前，可以讨论这些评论。

图5-10以下是一些示例说明，其中高级经理可能会就软件（相关）产品的上下文或方向转嫁给项目经理或项目团队成员。

管理评论主要基于成功或不成功的个人或已知经验。 有关数据转换需求文档的示例注释表明，团队可以理解转换过程，如参考显示整个转换过程的图所示。 但是，管理层建议应更详细地描述该图，以使读者（例如，客户）清楚地了解将要发生的情况。 这种解释可能导致开发人员发现被忽略的内容，或者导致客户指出先前未与卖方讨论过的内容。 在此示例中，产品技术监督的目的是消除在转换数据之前需要执行的任何歧义。

关于数据转换需求文档中有关整个转换过程的第二个管理意见，建议对一个数字进行解释。 开发人员可能认为文档中包含的数字是不言而喻的。 在这里，管理层正在运用与客户合作的经验，以确保产品进行清晰的沟通。

卖方管理人员对项目计划草案的意见表明，计划团队可能了解计划问题的技术方面，但并未完全理解生产可交付成果所需的资源。 计划团队中的卖方开发人员是根据计算机代码进行思考的工程师。 有时，他们可能会在购买者/用户使用“雪佛兰”的地方读到“凯迪拉克”。 在这里，卖方管理层建议开发人员重新考虑他们的方法，看看他们是否可以在可交付成果的数量与计划资源之间取得平衡。

流程技术监督

图5-11解决了以下类型的过程技术监督问题：如何规范地将项目过程应用于产品开发？文中给出了工艺技术监督的一个实例。在本例中，卖方管理层提供了有关项目软件开发过程的建议。

图5-11是一些例子说明，高级经理可能会将项目级软件系统开发过程传递给项目经理或项目团队成员。

在示例中，卖方高级经理建议开发团队跟踪同行评审所花的时间。 将来，开发团队可以使用此历史信息来帮助它更好地计划所需的资源。 此外，卖方高级经理建议对CCB会议进行修改，以跟踪发现的“新”要求。 如经理的话所述，时间表不能拖延； 因此，实施新要求可能意味着需要更多资源。 但是，额外的资源并不总是实现更多需求的解决方案。 其他方法包括“分阶段实施”，即在一个产品中提出一些要求，并在后续产品中解决其余要求。

开发评论

开发产品和过程评审包括同行评审和技术编辑。同行评审的范围可以从开发负责人和同行（或几个同行）之间的“一对一”会议到“正式的预定”会议，在这些会议期间，材料在预定时间之前分发给评审员（例如，三到六名评审员）。如下文所述，审查是技术性的。一般来说，管理层不直接参与评审，但应将评审情况告知管理层。

开发部对不断发展的产品和文件的技术编辑进行以下类型的同行评审：

• 产品同行评审涉及开发人员之间的详细技术交流，以帮助主要开发人员更好地实现客户所需。 例如，同行评审可以帮助主要开发人员提供与产品预期受众一致的材料。 如果听众是新手，则材料应包括基本或基本概念的说明。 另一方面，如果听众由专家组成，则材料不必过多关注基础知识。
• 技术编辑有助于确保将文档内容明确传达给目标受众，并且产品符合公认的文档标准。 技术编辑侧重于技术内容的呈现，以确保产品具有说服力和明确性。

开发对项目的软件系统开发过程进行以下类型的同行评审：

• 项目过程同行评审涉及开发人员之间的详细技术交流，以帮助首席开发人员详细说明在项目软件系统开发过程中开发软件产品所需的步骤。例如，同行评审可以帮助首席开发人员决定过程评审活动（例如，产品同行评审、技术编辑和/或产品保证评审）的适当组合，以应用于软件产品。

开发产品和过程评审的例子见以下段落。

产品同行评审

图5-12说明了以下类型的产品同行评审声明：

图5-12是软件文档、软件相关文档、计算机代码和数据的产品同行评审意见示例。

您需要考虑如何解决以下产品开发技术问题：（1）。 。 。 ，（2）。 。 。 和（3）。 。 。 。

示例产品同行评审意见显示为（1）软件文档，（2）软件相关文档，（3）计算机代码，和（4）数据。

首席开发人员与一个或多个同行一起讨论产品或产品的某一部分。如图5-12所示，同行向首席开发人员提出问题并提供建议。例如，对等方认为需求规范中的响应时间需求是不可测试的。同行们指出，需求并没有定义测量响应时间的时间间隔。注意，可测试性的问题是在需求规范期间发生的。在本例中，卖方开发人员通过确保每个需求都是可测试的，试图确保与客户就客户的需求达成一致。

处理同行评审

图5-13解决了以下类型的过程同行评审问题：将项目过程应用于产品开发的计划是什么？给出了过程同行评审意见的三个例子：（1）需求规范开发，（2）计算机代码开发，（3）数据库开发。

图5-13是开发需求规范、计算机代码和数据库的过程同行评审意见的示例。

首席开发人员与一个或多个对等方聚在一起讨论软件开发过程或过程的某些部分。如图所示，同行向首席开发人员提出问题并提供建议。例如，同行建议首席开发人员使用信息工程技术和工具来开发数据库。对于根据实体类型、它们的关系和属性详细说明主题领域的过程，提出了具体的建议。卖方开发商还试图通过建议牵头开发商获得客户对项目在整个生命周期中所做的和需要做的事情的接受，以确保与客户达成交易。

<stro

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

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