软件工厂与构建

一 简介

如今构建软件已 成为一项艰巨的任务。系统变得日益复杂而庞大。我们不但要面对瞬息万变的技术，同时又要设法与那些希望我们以更高质量和速度编写更多软件的业务客户的需求 保持同步。既要提高软件产量，又要保证其质量有所改进，这真的可能实现吗？是否能够既保持整个维护和升级过程中的较高生产力，而又不会以牺牲质量或大量重 写代码为代价？拥有数百万行代码的系统不太可能进行重写，尤其在业务需要快速完成变更时更是如此。在本白皮书中，我们将阐述如何通过在软件开发中采用软件 工厂方式来提高生产力和软件质量。

二 改变构建软件的方式

   数十年来，软件业已打造出多个软件系统来满足其客户的需要。即使拥有所有这些开发经验，软件质量和生产力却未能随之快速提高。根据 Standish Group 所进行的一项年度调查，我们发现我们现今的生产力水平与 10 年前几乎没有什么分别。目前，在所有软件开发项目中，有 54% 的项目在超出预算的情况下交付，66% 的项目未得到其客户认可，90% 的项目无法按时交付！但该调查所揭示的最令人烦忧的一点是，这些数字在过去的十年里一直都没有多少改观。
    召集一组开发人员或项目经理，当面问他们，是否觉得自己如今在构建软件领域做得比较成功。多数人在这时往往是置之一笑，同时承认他们也是这种结果的牺牲者。令人遗憾的是，我们往往认为，由于构建软件是一个极具创造性的过程，因此我们必须要容忍糟糕的交付项目。

目前构建软件的方式

   生产力低下通常是由于未能正确了解需求或未 能全面了解需求而造成。不止是构建不适合的系统会导致生产力严重下降，当项目范围在逐渐扩大，导致其超出最初的功能量时也会导致生产力严重下降。我们还发 现，要达到令人满意的测试水平以确保预期的质量水平是很困难的。不成功的维护和升级发布通常与无法预见到代码更改对产品质量的影响有关。我们该如何确保对 系统某一部分的更改不会破坏另一部分呢？
   由于我们很少从曾经完成的项目中吸取教训，因此导致这类问题频繁出现。当问到开发团队他们是否从自己的错误中吸取了教训时，明显会看到几乎没有人会主动积 极地去总结教训，并将其应用到以后的项目中。很少有团队会习惯性地重新使用过去创建的解决方案，或者对成功和失败的案例进行记录。结果是，没有充足的知识 和信息在各项目之间传递，各开发人员所了解的知识和信息依旧停滞在自己的脑海里。新的开发人员需要重蹈覆辙才能获得以前的开发人员本来已经吸取的经验和教 训。开发人员发现很难以脱离现有的项目，因为他们对这些项目太熟悉了，并且发现加入新项目也很难，因为没有留下什么记录可供参考。
     由于多数项目都无法按时交付且会超出预算，因此我们意识到，我们还要面对一个可预见性问题。当问到项目经理是如何制定计划和日程表时，可以更明显地看到，许多人都在恪守着旧习惯，他们往往会这样说：“我向我最出色的程序员询问了此功能估计要花费多少时间，然后我会将该估计结果增加一倍；我的程序员往往都比较乐观。”通常，这种“预算”之后就会被缩减，或者是为了交出一份有竞争力的投标条件，使这些数字带来好结果，或者是为了满足预期要求。这些旧习惯是很难以改变的。 
   但老实说，项目经理几乎要注定依赖专业人员来推测，因为他们没有可靠的量度来代替使用。他们需要能够以一种可靠的方式从软件开发项目收集量度，例如，通过 数据仓库。从这些量度中，他们可以了解到其开发团队的运作情况，并利用了解的知识和信息来构想出更准确的估计数据。利用历史数据来对组织或项目绩效进行标 准化可以提高估计数据的准确度，但多数估计数据并不是这样得出的。
   如果没有良好的可预见性，是很难以掌控项目的。在项目经理进行决策时，如何才能了解这个决策将对其日程表和成本带来什么影响？您不能只是用粗略的估计数据来预测所做决策的影响。这与蒙着双眼射击又希望射中目标并无两异。
     这些问题就是我们花费大量时间却生产出很少软件的原因。我们交付的软件质量拙劣且难以控制。要使开发过程尽在掌握之中，我们面临着重重困难。对于实践者来 说，很难以对项目进行变更。超出预算的每个小时都会产生额外成本，在测试中（甚至更严重的是在生产中）发现的每个缺陷还要花费更多成本，这与整个过程中做 出的每个错误决策的结果是一样的。如今构建软件的代价是非常昂贵的。

使用软件工厂

   我们能改善这种情况吗？答案是肯定的。我们 能够在构建软件时保证其准时交付、不超出预算并且质量达标。不过，首先各组织必须先意识到当前构建软件的方式是非常低效的。如果意识不到问题的存在，也不 会有改进的动力。要在保证可预知性的前提下开始构建软件系统，我们必须进行一次文化变革。我们必须使实践者更容易地了解要执行任务的内容、执行时间、执行 原因以及执行方式，并且必须将其工作中更多的机械和/或琐碎的方面实现自动化。可通过将开发流程中选出的各方面进行形式化来达到这些目标。这些方面有哪些？我们该如何将它们形式化而又不失灵活性？

创造性和形式性

 

   关键是将那些创建和修改工作产品的精细活动 进行形式化，而不是设法形式化整个开发流程。粗放式工作流随后可根据项目要求和情况来逐渐演化，前提是要一直保持固定流程以确保结果有效。例如，您可以同 时着手编写多个类，根据需要在它们之间进行切换，只要在您编译时它们之间的所有依存关系都得以满足。这种机动性即保持了灵活性又防止了围绕单个活动排队的 情况。如果将精细活动形式化，而不是试图将整个开发流程形式化，则可以在保证质量、可预见性和生产力的同时而又不失灵活性。您会认识到哪里需要形式化，哪 里不需要形式化，从而更容易在灵活性与形式性之间取得适当的平衡。通过仅在需要形式化的环节和时间实施形式化，可以使开发流程随着经验的积累以一种非常系 统的自下向上的方式演化。此方法还使收集知识及信息并在各项目和实践者之间传递这些知识及信息变得更加容易，本文稍后会对此进行阐述。
   解决问题时需要创造性，但执行机械和/或琐碎的活动时不需要创造性。遗憾的是，典型开发人员的日常工作中有很大一部分是由机械和/或 琐碎的活动组成，但这也许不会让人感到意外。保证生产力和可预见性而又不失灵活性的关键是，在需要创造性的方面激发并支持创造性，在不需要创造性的方面则 进行形式化。我们对模式、惯例和工具的形式化范围越大，从流程中剔除的不必要的变更就越多。剔除不必要的变更可以更容易地度量软件开发项目，从中吸取经验 教训，并使用这些度量值来改进未来的项目。将机械和/或琐碎的活动形式化减少了在不需要创造性的活动上花费的时间和精力，从而激发了更大的创造性。

软件工厂

   我们要讨论的是，将软件开发行业化，将已得到其他行业长期认可的方法应用于我们自己的行业，希望的是我们客户和我们自己的情况都能得以改善。这种行业化要通过创建可同时提高软件开发生产力和可预见性的软件工厂来实现。
   软件工厂是由用于加速特定类型软件组件、应用程序或系统的生命周期任务的集成式流程、工具及其他资产组成的打包集。通过为实践者提供指南来协助他们了解要 执行任务的内容、执行时间、执行原因以及执行方式，从而实现加速。为此，我们提供了将流程形式化做到恰到好处的流程指南、可快速组装和配置的组件，或可快 速完成的框架，并提供了将机械和/或琐碎活动全部或局部自动化的专用工具。
   我们希望借助软件工厂实现的其中一个主要目标是，从过去针对常见问题或需求创建的解决方案中学习经验和教训，然后将这些经验和教训应用于未来的项目中。为 此，我们需要一种描述这些可重用解决方案的方式，还需要一种围绕相关或所关注领域（也就是经常遇到这些解决方案所解决问题或需求的领域）来组织这些解决方 案的方式。按照此方式组织解决方案有助于缩小同时需要关注的问题或需求的范围，从而更轻松地确定可能适用的可重用解决方案。这些应予以关注的领域可能处于 高抽象级别（例如，定义体系结构层），也可能处于低抽象级别（例如，为 C# 类或接口定义方法签名）。

架构和模板

   软件工厂使用了 IEEE 1471 术 语，即“对软件密集型系统体系结构描述的推荐实践”，它将关注领域称为“视点”。视点可能因多种原因而定义，例如，在软件开发生命周期的不同阶段，在不同 抽象级别描述产品的不同部分。各视点是相互嵌套的，因此，“数据访问层”视点可能包含一个“数据访问库”视点、一个“逻辑数据库设计”视点、一个“物理数 据库设计”视点以及一个“数据安全性”视点。
   从给定视点生产或耗用的工作产品组成一个“视图”。视图由其视点定义，这与对象由其类定义差不多。工作产品可能是某个文件、某个文件的一部分、多个文件或 多个文件的多个部分。例如，在“数据访问库”视点中，工作产品可以是一个包含了用于数据库表格的数据访问类的文件。由“数据访问库”视点定义的视图可以是 包含一组用于给定数据库中所有表格的数据访问类的项目。视点可以交互组合，也可以呈模块化结构。例如，针对“数据安全性”视点的工作产品可能是数据访问类 的插入、替换和更新方法的前导。
    视点往往会推动项目类型和工具的创建。例如，“数据访问库”视点可能会映射到一个基于具有某些属性的项目模板的类库项目类型，从而包含具有数据访问类某些属性的项目模板。当我们创建该类型的项目时，就会基于该视点创建视图。视图的内容即是项目文件夹中的文件。这些是由视点定义的工作产品。
   在较高的抽象级别，视点往往会推动工具的开发。例如，“业务流程”视点可能由业务流程建模工具来表现。该工具以模型的形式呈现基于该视点的视图，这些模型 也就是由该视点定义的工作产品。它还通过菜单命令和其他示意动作（例如，执行从工具箱到图表的拖放操作以创建新的消息类型）来支持由视点定义的活动。
   对于每个视点，都需要有一个名称和描述。我们还需要知道生产或耗用的工作产品、创建或修改这些工作产品所涉及的步骤，以及用于执行这些步骤的资产。换言 之，视点应该告诉我们要构建什么、如何构建，以及可使用什么来构建（模式、工具、模板等）。视点是软件工厂的构建块。它们将那些创建和修改工作产品的精细 活动进行了形式化。

每个软件工厂都定义了一组构建其产品所需的相互关 联的视点。这组相互关联的视点称为“架构”。您可以将工厂架构设想为一个目录，它可帮助您发现软件工厂的组织方式，以便您可以使用它所提供的资产来构建其 目标产品。工厂架构在很大程度上像是一个数据库架构，数据库架构可帮助您发现数据库的组织方式，以便您可以导航、查询并操纵其中包含的数据。但工厂架构不 是描述数据的组织方式，而是描述软件工厂的组织方式。
   举一个简单例子来说明架构，让我们设想一个基于“面向服务的体系结构”(SOA) 创建“企业管理应用程序”的工厂。对于该工厂，您可能要定义以下视点：

前台应用程序。描述支持用户桌面上数据输入的 Web 或 Windows 应用程序的创建。它告诉用户如何使用窗体设计器和您所开发库中的数据输入控件来创建 Web 或 Windows 窗体。用于此视点的活动是创建 Web 或 Windows 窗体。工作产品就是这些窗体。所用资产是窗体设计器和数据输入控件库。
流程服务。描述负责管理业务流程的 Web 服务的创建。Web 服务始终按照某模式以同一方式构造，并且带有一个由 C# 接口使用 XSD 架构生成的类型化对象来描述的服务合约。用于此视点的活动是创建 Web 服务。Web 服务即是工作产品。所用资产是模式和类型化对象生成器。
平台服务。描述不负责业务数据而仅负责通用于所有系统的服务（如打印、审核、授权等）的 Web 服务的创建。此视点提供了可重用的通用服务，并告诉用户如何评估和定制每个服务。用于此视点的活动是评估和定制这些服务。工作产品是定制服务。所用资产是通用服务最后一条要了解的软件工厂术语是工厂“模板”，它是一个包含软件工厂所提供资产的可安装数据包。要使用工厂，实践者必须将工厂模板安装到工作站上。
   工厂通常是以自下向上的方式开发。确定了目标产品系列后，在构建系统时，可以开始发现并描述工作产品和活动；将它们组织到视点中；开发支持这些活动的资产；将各视点组织到工厂架构中；然后将各资产打包到工厂模板中。

功能配置

    构建有效工厂的关键之一是定义可在多个不同的解决方案中付诸使用的工作产品、活动和资产。例如，“数据访问库”视点可提供有助于访问 SQL 数据库的库。您可能会发现，您并不是始终将同一个 RDBMS 用于每个项目，因此，您的库必须要容纳其他 RDBMS。 与该库配合使用的工作产品和配合库执行的活动的描述可能也必须做出相应调整。视点接受的可变性越多，将其应用于多个解决方案的灵活性就越高，但同时也要执 行更多的工作才能将其配置正确。允许可变性却带来了复杂性。您必须在过多可变性与过少可变性之间找到适当的平衡点，才能使软件工厂发挥效用。您的工厂的通 用性越高，实现的生产力和可预见性就越低。
   确定应该允许多少可变性的一个有效方法是分析您期望构建的解决方案的功能。通过利用一种称为“通用性/可变性 (C/V) 分析”的方法，您将那些必须以同一方式在每个解决方案中都出现的通用（或强制）功能与那些可能只在某些解决方案中出现的可变（或可选）功能，或在各解决方案之间出现方式不同的功能分隔开。本白皮书将不对 C/V 分析进行详述，但有许多关于此主题的文章和书籍可供感兴趣的读者参考。
   在基于 SOA 创建“企业管理应用程序”的工厂中，“数据访问”是一个强制功能（因为每个解决方案都将执行数据访问），但“Web 前台”却是一个可选功能（因为一些解决方案将带有 Web 前台，而另一些解决方案将带有 Windows 前台或甚至根本没有前台）。 在工厂中，您可以使用功能模型来描述可能在该产品系列的某一成员中出现的功能，以将通用功能与可变功能分开，并指明可变功能的出现方式。（功能模型由 Czarnecki 和 Eisenecker 进 行详细描述。有关详细信息，请参阅本白皮书中的部分。）功能模型也可定义关于可变功能的决策相互影响的方式，例如，声明一个可变功能需要另一个可变功能， 或一个功能与另一个功能不兼容。通过配置功能模型来为给定应用程序做出这些决策。配置是一个简单的过程，它涉及到指定哪些由模型描述的可变功能在应用程序 中出现以及它们中每个功能的出现方式。图 1 显示的是上文所述工厂的一个简单的功能模型。

   尽管功能模型通常用于按要求呈现的用户可见 功能，但它们也可用于仅对开发人员可见的设计、实现、测试和部署功能。某些功能强大的场景通过链接这些功能来启用，以便在配置用户可见功能的同时也配置开 发人员可见功能。例如，将用户可见的“前台”功能链接到开发人员可见的解决方案布局功能可能会使工厂根据用户所选的前台类型生成一个默认的解决方案布局。
   功能建模只是用于描述可变性的多种知名机制之一。其他机制还包括窗体、表格、向导、设计器、模板、模式、脚本和代码。可变性机制可单独使用，也可以各种组合使用，目的是指定和实现软件工厂中的可变功能。

成功的关键

成功过渡到软件工厂方法的关键因素是什么？您需要具备以下能力：
----找到产品中的通用性和可变性。
----在生产力和质量方面度量您的产品开发流程目前的绩效。
----定义和改进有效支持产品开发的流程。
----提供有助于每个人了解所实现的生产力和质量的透明模型，并使用这个透明模型推动文化转型。
同时规划多个项目。
----快速、经济地开发将知识和信息进行封装并使其易于重新使用的可重用资产，尤其是自定义工具。----确定特定领域并将自定义工具和流程专用于这些领域，而不是试图将多用途工具和流程应用于所有领域。

三 度量质量和生产力

   既然我们已经大概了解了关于软件工厂的一些知识，那就让我们更深入探讨一下如何在软件上下文中度量质量和生产力。
   事实证明，工厂架构为组织量度提供了一个有用机制。由于每个视点都面向软件开发流程的一个特定方面，因此可以使用各视点来定义生产力和质量的目标度量。使 用这些度量，您可以收集软件开发流程特定方面的数据。通过分析这些数据，您接下来就可以确定哪些视点需要改进、如何进行改进以及改进后可获得哪些益处。
   要实现此方法，您需要确定一种表示产品规模、所用时间和预算以及产品质量的方式。这些度量可用来量化每个视点的可预见性、生产力以及质量。它们也可用于评 估您的工厂生产的最终产品。通过度量每个视点以及工厂总体绩效，您可以确定每个视点对工厂总体绩效的影响有哪些，从而确定要投入多少可重用资产来支持给定 视点中的活动。例如，您可以为没有明显影响到总体效率的视点提供简单的指南，为明显影响到总体效率的视点提供高级的基于“域专用语言”(DSL) 的设计器。
   此方法类似于大型企业组织优化其业务流程的方式。他们针对特定业务目标定义生产工作产品所需的技能、流程和工具。从这时起，他们度量要完成该流程所需要执 行的工作，然后分析哪些方面可予以批准。他们称其为“业务流程监控”，但它基本上还是考评在优化软件工厂时要执行哪些工作。显然，在建立工厂当前绩效的基 准线和确定要在软件工厂开发方面进行的正确投资时，度量是一个关键因素。此过程有助于您在可预见性、生产力和质量方面获得最佳投资回报。它还有助于将结果 与最初在开始开发工厂前设定的目标进行对比。

使用功能点表示产品规模

   在软件开发中，我们可能想要提高的一个方面 就是生产力。要量化生产力，您需要一个可用来根据在一段时间内构建的软件产品量来表示生产力的量度。当我们能够预测系统规模并度量开发过程中产品规模增长 量时，我们就可以更好地预测完成该项目所需的时间并根据单位产品规模所用的小时数来度量生产力。通过度量实际的增长量和规模，我们能够鉴别实际值与计划值 之间的差异，并在差异变得明显时开始对其进行分析和管理。
   此时，您可能想知道我们如何才能以足够的准确度来预测产品规模和增长量，以使这种度量和分析发挥作用。如果我们以一次一个项目的方式开发任意的应用程序， 这看起来的确不太可能实现。不过，如果我们使用软件工厂，我们就有两个可显著提高可预见性的优势。首先，我们开发的是具有已知特征的特定产品系列的一个成 员，而不只是一个任意的应用程序。通过软件工厂，我们可以描述一个产品系列及其突出功能，更重要的是，我们可以一边随着多个项目的进展过程积累经验，一边 来逐渐优化该描述，因此，对于使用工厂开发的应用程序，我们所掌握的知识和信息要远多于对任意应用程序所掌握的知识和信息。其次，我们将通过应用工厂提供 的规定性指南来开发应用程序。因此，我们有许多开发任务在前后各应用程序中的执行方式都大体相同，使用的是一些相同的模式、模板、库和工具。如果我们将执 行某些任务的方式标准化，工厂往往就会从开发流程中剔除不必要的变更，使前后各应用程序的产品规模和增长量更有可能遵循相似的模式。 如果我们使用软件工厂，则度量这些值并确定、分析和管理计划值与实际值间的差异就会极其有用。
   目前已经有多种估计方法可帮助您确定系统规模。如果您想要一个有助于表示规模和生产力的量度，您需要一个目标定量。此目标定量可通过使用标准化的方法实现。其中一个方法就是 ISO 24570 标准中定义的“功能规模度量”(Functional Size Measurement)。（ISO/IEC 24570:2004 指定了度量软件功能规模的方法，提供了关于如何确定软件功能规模各组件的指南，详细说明了如何按照上述方法计算功能规模，并提供了上述方法的应用指南）。此 ISO 标准将功能点用作基于功能规范表示软件系统规模的方法。可将这些功能点视为确定系统规模和预估工作及日程表的“总量度”。在开发期间，此量度可用于确定相对于其他类似项目，该项目是需要执行多一些工作还是少一些工作。
   借助功能点，您可以根据业务功能定义系统规模。此功能根据您收集的早期需求来确定，并使用规范来进行评分。功能点分析充分利用了构建面向数据库的应用程序 的知识和信息，只要您构建的系统在数据库中使用数据操纵，就可应用该方法。功能点是根据对两个数据的了解计算得出的：您的应用程序将含有的表格估计数；数 据操纵函数（如数据检索函数和数据更新函数）的数量。由此，您可以计算出表示产品规模的功能点的数量。在表示了估计的产品规模后，您可以了解实现一个功能 点要花费多少时间，甚至可以使用已有的历史数据对实现一个功能点要花费的时间进行预测。软件工厂可影响实现一个功能点所用的时间（生产力），每个功能点的缺陷数（质量）以及您的估计数据的可预见性。
   再深入探讨一下可预见性，我们已经了解到，工厂是如何允许我们将一个产品系列所有成员的通用功能与仅在某些成员中出现的可变功能或在不同成员中有不同规模 或特征的可变功能相分离。因此，我们无需从头收集对给定产品的需求，而是可以假定该产品具有所有系列成员共享的通用功能，并仅将重点集中在详细说明其独特 或可变的需求上。
   返回工厂上下文中的功能点分析时，我们发现可以将一个始终都存在的固定的最小产品规模作为起点，因为我们的产品系列始终都包含某些固定部分。这个固定的最 小产品规模即是该产品系列通用功能的一个度量。我们也可以为许多可以或不可以添加到产品基本配置文件中的可变功能定义可计算规模。从这些信息中，我们可以 估计出某一功能配置将要花费的时间和成本。接下来，该信息还可以帮助我们决定要构建哪些功能。换言之，基于功能配置的功能点分析为我们提供了一种预先对成 本和功能做出明智权衡的方法。
   例如，假设我们应用了功能点分析，并确定我们将要构建的系统的估计规模是 500 个功能点。当我们开始构建此系统时，我们可确定构建它要花费 6,500 个小时。由此我们可以将生产力表示为 13 小时 (h)/功能点 (fp)。
   如果我们还在开发、用户验收测试和生产过程中跟踪在产品中发现的缺陷数，则也可以将该数字表示为一个质量量度。假设我们在开发过程中发现 500 个程序错误，在验收测试过程中发现 50 个程序错误，在投入生产后发现 5 个程序错误。我们可以将其表示为，开发过程中是 1 个缺陷/fp，验收测试时是 0.1 个缺陷/fp，生产中是 0.01 个缺陷/fp。
   现在，假设其中许多缺陷可追溯到前台应用程序视点。由此我们了解到，在造成所有这些缺陷的原因中，此视点占了很大一部分比重，我们可以集中分析此视点范围 内哪些方面可能需要改进。通过这种分析，我们可以确定要改进哪些视点以及如何改进，以减少下次使用工厂时发现的缺陷数。将缺陷数与某量度（如功能点数量） 的比值进行量化的好处是，您现在可以为希望通过投资实现的改进方面设定目标。例如，我希望前台应用程序视点的每功能点缺陷数下降 20%。对每个视点逐一执行缺陷和功能点分析为我们改进产品开发流程提供了强大工具，因为它有助于我们确定瓶颈所在之处，从而确定在何处投资以及如何投资才能获得更好的结果。
   如果您有更多的开发任务要执行，并且该开发任务涉及到您已收集量度的视点，则刚才所阐述的基本量度可以让您了解有关下一个项目（也许甚至是当前项目）的一些有价值的信息。例如，假设在收集需求并应用功能点分析后，您知道新系统的规模将是 750 fp。您现在就可预测到，实现这些需求将需要约 9,750 个小时的工作，并且将在用户验收测试中发现约 75 个程序错误。
   这些预测的准确度在很大程度取决于您收集的量度级别以及未来的系统开发项目与已收集量度的项目的相似程度。软件工厂中的每个视点都允许在系统开发中有一定 量的可变性。可变性的量又依次决定了视点可向工厂用户提供的资产类别，从而决定了前后项目之间在产品该方面的一致性程度。例如，在工厂的第一个版本中，可 能只有几个描述系统体系结构和只提供支持开发人员完善实现的指南的视点。使用此工厂的开发人员将不得不手动编 写大量代码。不过，在使用此工厂构建多个系统后，您可能会看到，由于各个开发人员对指南的理解都截然不同，这些系统的用户界面部分的构造也往往是多种多 样。从这个观察事实可以得出结论，用户界面视点允许大量可变性。如果您的工厂中有多个可变性很高的视点，则您的度量值和预测值准确度要低于在视点中可变性 有限时的准确度。
   此时，我们可能会问到，给定视点中的可变性程度是否真的必不可少。如果不是，我们将能够通过剔除过多或不必要的可变性来提高度量值和预测值的准确度。例 如，让我们再一次探讨用户界面视点，但这次我们提供了一组支持指南的库组件和一个配置用户导航路径的图形工具。通过提供这些资产，我们将对用户界面开发流 程中先前松散定义的某些方面进行形式化。这种形式化减少了用户界面视点允许的可变性的量。使用此工厂开发的系统将在用户界面构造中展现出更多的一致性，从 而使我们的度量值和预测值更加准确。由于估计数据中的错误量会随着工厂允许的可变性的减少而减少，因此，在工厂通过剔除过多或不必要的可变性而逐渐演化的 过程中，可预见性也会随之提高。实际上，生产力和质量往往也会随可预见性提高，因为减少可变性也就减少了构建给定功能所需的时间量以及在其构建过程中引入 的缺陷数。此时，有一则警言妙语用在这里很适宜：按照 Occam 的剃刀法则，应尽可能多地减少可变性，但绝不要减少到因过分限制开发人员而使项目耗时更长、成本更高的程度。
   当您着手使用功能点时，最初可以使用文档资料中记载的周围组织的历史数据来进行第一次估计。历史数据还是很有帮助的，因为它将组织影响（无论是已被公认的 还是未得到公认的）考虑了进去。这一理念也适用于在软件工厂内对历史数据的应用。使用软件工厂开发的各个项目将有许多共同之处。即使没有过去项目的历史数 据，您也可以从当前项目收集数据并将其用作预测项目余下部分的基准。您的目标应从使用组织数据或行业平均数据尽快转换为使用工厂数据和项目数据 (McConnell, 2006)。

使用度量改进工厂

   通过建立基准或实际校准生产力和质量参数（以小时数/功能点和缺陷数/功 能点测得），您可对项目数据进行分析，然后识别那些可能会花费大量时间的活动或产生大量缺陷的视点。校准完毕后，就可以着手更改工厂的组织方式，通过各种 途径（如所要求的技能、定义的流程或提供的可重用资产）对其加以更改。确定哪些区域需要改进是至关重要的，以便保证投资到位。但这应该相对容易一些，因为 您掌握了用以确定每个视点对可预见性、生产力和质量作出多大贡献的途径。在使用原始数据建立基准后，就可以连续不断地运行以下循环：分析每个视点的性能， 使用这些信息确定需要改进的区域，执行改进，然后重复这个过程。
   这一有效循环可用于实现各种度量。例如，要提高生产力，可根据小时数/功 能点来确定效率最低的视点，然后通过各种方法对其加以改进：提供更多更好的指导或培训；改进用于构建工作产品初始切割的模板；提供用于实现工作产品构建和 修改自动化的专业化工具；等等。这一过程的关键部分是估算进行指定改进的成本、估算因改进而可能提高的生产力以及估算结果是否证明投资正确。在实现改进并 将其并入工厂后，您可以根据减少的工时数/功能点来度量该改进是否满足预定目标。图 2 阐明了这一过程。