软件工厂相关资料汇编

<layer style="background-color: Yellow; color: black;" id="google-toolbar-hilite-0">软件工厂</layer>相关资料汇编

---

<layer style="background-color: Yellow; color: black;" id="google-toolbar-hilite-1">软件工厂</layer>

<layer style="background-color: Yellow; color: black;" id="google-toolbar-hilite-2">软件工厂</layer>就是指为了支持某种特定应用程序的快速开发而配置的开发环境。<layer style="background-color: Yellow; color: black;" id="google-toolbar-hilite-3">软件工厂</layer>从逻辑上讲就是软件开发方法和实践的下一个发展阶段。然而，通过引入产业化模式，<layer style="background-color: Yellow; color: black;" id="google-toolbar-hilite-4">软件工厂</layer>势必会改变软件行业的现状。
扩大软件开发的规模

从目前的情况来看，软件开发的速度缓慢、代价高昂而又极易出错，常常会生产出存在大量缺陷的产品，在可用性、可靠性、性能、安全以及其他服务质量方面造成严重的问题。

根据 Standish Group [Sta94] 的统计，美国公司每年投资约 175,000 个软件开发项目，投资额约为 2,500 亿美元。这些项目中只有 16％ 能够在预算内按计划完成。另有 31％ 的项目主要由于质量问题而被取消，经济损失约为 810 亿美元。另外 53％ 的项目平均超出预算 189％，经济损失约为 590 亿美元。完成的项目平均只实现了原来规划的功能的 42％。

这些数字客观地印证了我们根据经验所做出的判断，那就是软件开发是一项劳动密集型的产业，它创造每一美元的价值所消耗的人力资本超过了我们对于一个现代化行业的期望值。

当然，除了这些缺点以外，软件开发的成果显然为消费者带来了巨大的价值，正如需求增长的长期趋势所表明的那样。但这并不意味着消费者已经非常满意，不管是对我们提供的软件，还是对我们提供软件的方式。这只是说明他们确实看好软件的前景，愿意承担巨大的风险和损失，以此来获得软件所带来的好处。然而，正如软件开发的外包越来越受欢迎所表明的，这种情况显然不是最好的，因为它似乎不能推动软件行业在软件开发方法和实践方面作出重大的改变。

在过去十年中，生产率只获得了有限的提高，最重要的原因可能是采用了字节编码的语言、模式和灵活的方法。除了这些进步，我们开发软件的方法与十年前没有什么不同。我们的方法和实践实际上没有太大的改变，相应的成本和风险同样也没有太大的改变。

然而，这种情况就要被改变。据预测，全球对软件的总体需求将在下一个十年中以数量级的速度增长，这是由于受到全球经济中的新生力量（例如中国的崛起）的推动，以及由于新的应用类型（例如商业集成和医学信息科学）和新的平台技术（例如 Web 服务、移动设备和智能产品）而使软件在社会基础结构中的作用日益加大。

如果软件开发能力没有相应的增长，那么十年后势必出现总体软件开发能力大大低于总体需求的局面。当然，如果市场力量能够自由运作，这种情况不会真正出现，因为受到启发的软件提供商将出于个人利益而提供足够多的软件来满足这种需求。
再次面对新的挑战

那么，怎样才能提供足够多的软件开发能力呢？不用太多的分析就可以看出，必须对软件开发的方法和实践进行显著的改变。

因为行业的生产能力取决于合格开发人员的数量以及开发人员的工作效率，因此提高行业生产能力的方法是，或者继续采用现有的方法和实践而投入更多的开发人员，或者保持相当数量的开发人员而采用不同的方法和实践。

尽管过去十年间培育起来的学徒制似乎已经成功地增加了合格开发人员的数量并提高了开发人员的平均水平，但至少有两个理由可以说明学徒制不大可能使软件行业的生产能力满足预期的需求水平：
•

经验告诉我们，没有什么比拥有一些杰出的程序员更重要。杰出开发人员比蹩脚开发人员的工作效率高一千倍，但蹩脚开发人员的数量也几乎是杰出开发人员的一千倍 [Boe81]。
•

Brooks [Bro95] 指出，增加项目人数最终会导致边际收入减少。通过招募和培训新开发人员而获得的生产能力将逐渐下降。

因此解决问题的出路应是改变我们的方法和实践。我们必须通过各种途径提高开发人员的工作效率。
创新曲线与模式转变

作为一个行业，我们从一开始就需要共同面对这种情况。软件开发的历史是一个与复杂和变化作斗争的过程，时而盈利时而亏损，随着时代的进步而产生更多的需求。虽然仅仅半个世纪就取得了不少辉煌的成绩，然而道路并不平坦。相反，软件开发一直沿着著名的创新曲线模式在前进，如图 1 所示 。

图 1：创新曲线

典型的情况是，一个不连续的创新为一个新的技术时代奠定基础。新基础之上的发展一开始是快速的，但随着基础的稳固和成熟，发展速度逐渐慢下来。最后，这个基础失去了继续创新的能力，达到发展的顶峰。同时，另一个不连续的创新为另一个新技术时代的到来奠定基础，于是上述模式得以重复。Kuhn 称上述基础为模式，称它们之间的转变为模式转变 [Kuh70]。模式转变发生在需要改变现状以继续前进的交汇时刻。我们现在正处在这样一个交汇时刻。
提高抽象水平

在历史上，模式的转变曾经成功地提高了开发人员的抽象水平，为在平台和语言中获得知识并重复利用知识提供了强大的概念。例如，在平台方面，我们从批处理开始，经历了终端/主机、客户机/服务器、个人计算、多层系统和企业应用集成，再到异步、松散耦合的服务。在语言方面，我们从数字编码语言开始，经历了汇编语言、结构化语言和面向对象的语言，再到字节编码的语言和模式，这可以看作是基于语言的抽象。Smith 和 Stotts 对此进步作了意味深长的总结 [SS02]：

编程的历史是在体系结构抽象方面的一种锻炼。在每个时代，语言设计人员通过总结上一代的经验教训创造出结构，然后体系结构设计师使用这些结构创造出更复杂，更强大的抽象。

他们还指出，新的抽象一般先出现在平台上，然后移植到语言中。我们现在的情况是，基于语言的抽象已远远落后基于平台的抽象。换句话说，现在是工具远远落后于平台。我们现在正在使用最新的平台技术（例如，通过采用配乐法编写服务，我们现在能够使位于这个星球上任何位置的多个企业间的进程自动化），但我们仍然在手动编写每个应用程序，好象这是首选的方法一样。我们从小的具体概念（例如循环、字符串和整数）入手来创造大的抽象概念（例如保险索赔和证券交易）。我们勤勤恳恳一丝不苟地工作，将上百万小的相关源代码片段和资源组合在一起，形成巨大而复杂的结构。如果半导体行业也采用类似的做法，他们需要用手焊接晶体管来建立起支持这些应用程序的巨大而复杂的处理器。相反，他们通过组装称为特定用途集成电路 (ASIC) 的预定义组件，使用如图 2 所示的工具来完成实现。

图 2：基于 ASIC 的设计工具7

难道我们不能采用类似的方式来实现软件开发的自动化吗？当然能，而且实际上我们已经在这样做。例如，数据库管理系统通过 SQL 实现数据访问自动化，提供了诸如数据集成和独立性等优点，使数据驱动的应用程序更易于创建和维护。与此类似，Widget 框架和 WYSIWYG 编辑器使得创建和维护图形用户界面更容易，提供了诸如设备独立性和可视化组装等优点。仔细分析这些做法，我们可以发现一个反复出现的模式。
•

在给定问题领域开发出大量系统之后，我们为该领域确定一组可以重复利用的抽象，然后我们制订一组模式，规定如何使用这些抽象。
•

然后我们开发一个运行时（例如框架或服务器），将这些抽象和模式代码化。这样，我们可以通过对运行时所定义的组件实例化、调整、配置和组装，从而在该领域中创建系统。
•

然后我们定义一种语言并创建支持该语言的工具（例如编辑器、编译器和调试器），使组装过程自动化。这样可以帮助我们对不断变化的要求做出快速响应，因为部分实现已经完成，而且可以轻松地加以修改。

这就是 Roberts 和 Johnson [RJ96] 所描述的著名的“语言框架”模式。一个框架可以按数量级降低开发一个应用程序的成本，但只使用一个框架则很困难。一个框架定义一种具有某种典型体系结构的产品（例如应用程序或子系统），这些产品可以通过各种方式进行完善和专门化的处理，以满足不同的要求。将每种产品的要求映射到框架中绝不是一个小问题，通常需要借助于体系结构设计师或高级开发人员的专业技能。通过使用语言表达式捕获各种要求，然后生成框架完成代码，基于语言的工具可以自动完成此过程。
实现软件开发的产业化

在其他行业，提高生产能力的途经是从手工作业过渡到机械生产。在手工作业阶段，所有产品都是由个人或小组从无到有制造出来的，而在机械生产阶段，各种产品通过组装多家供应商生产的可重复利用的组件迅速生产出来，在这个过程中，许多机械琐碎的任务都是由机器自动完成的。这些行业对工艺、设计和包装进行标准化，借助产品线实现系统性重复利用，并通过供应链分担成本和风险。现在已有部分行业可以实现大规模定制，根据需求快速而经济地制造出各种产品，以满足不同客户的特定要求。
软件能够实现产业化吗？

人们对软件与实物之间的类比进行过热烈的讨论。这些产业化模式能够应用于软件行业吗？难道软件行业没有因其产品性质的不同而比其他行业特殊吗？Peter Wegner 对它们之间的异同总结如下 [Weg78]：

软件产品在某些方面与传统工程学科中的有形产品（如桥梁、建筑物和计算机）存在相似之处。但也存在某些重要的区别，使得软件开发与众不同。由于软件是逻辑概念而非实物，因此其成本集中在开发过程中而不是生产过程中。又因为软件不会磨损，因此其可靠性取决于逻辑质量（如正确性和稳健性）而非物理质量（如硬度和韧性）。

有些讨论将实物的生产与软件的开发比作“苹果与桔子”。理清这些困扰的关键是理解生产和开发之间的不同，以及规模经济与范围经济的不同。

为了获得投资回报，必须尽最大可能重复利用那些可重复利用的组件而不仅仅是收回开发成本，无论是直接通过降低成本，还是间接通过降低风险、缩短进入市场的时间或改进质量来实现。从投资角度讲，可重复利用的组件属于金融资产。由于为使组件可重复利用而耗费的成本通常非常高，很难达到可获利的重复利用程度，因此需要有一种系统的方法来实现重复利用。这通常包括确定一个要开发多个系统的领域，找出该领域中重现出现的问题，开发出一套解决该问题的集成生产资产，然后将这些资产应用到在该领域中开发系统的过程中。
规模经济与范围经济

系统性重复利用可以同时产生规模经济和范围经济的效应。这两种效应在其他行业广为人知。尽管二者都是通过集中而非单独生产多个产品来减少时间和降低成本并提高产品质量，但二者在产生这些优点的方式上却存在着不同。

当集中而非单独生产一个设计的多个相同实例时，就产生了规模经济，如图 3 所示。规模经济可能出现在生产机器螺钉等产品时，在这种生产过程中，可以使用机床等生产资产生产出多个相同的产品实例。工程师通过一种资源密集的过程（称为开发）完成设计与最初的实例（称为原型）。然后通过另一个由机器和/或低成本劳动力完成的过程（称为生产）创造出更多实例（称为复制品），以满足市场需要。

图 3：规模经济

范围经济通过集中而非单独生产多个相似但不同的设计和原型而实现，如图 4 所示。例如在汽车制造业，多个相似但不同的汽车设计通常是通过组合子部件（如底盘、车体、内部装饰及传动装置）的现有设计来开发的，而不同的款式或型号通常是通过改变现有设计中的某些功能（如发动机和装饰水平）来产生的。换言之，可以使用相同的方法、工艺、工具和材料设计出多个相似但不相同的产品，并制作出相似但不相同的原型。商业建筑同样如此，很少看到多座桥梁或多幢摩天大楼采用同一种设计。但商业建筑领域存在一个有趣的现象，即每个成功的设计通常只会产生一两个实例，因而规模经济几乎从未真正实现过。在汽车制造业，通常会从成功的设计产生出许多不同的实例，通过复制每个原型，范围经济与规模经济形成互补，如图 4 所示。

图 4：范围经济

当然，软件无论与汽车制造还是与商业建筑之间都存在重要区别，但它们常常有着相似的地方。
•

在诸如用户桌面产品之类的市场中，操作系统和工作效率应用程序等产品通过复制形成批量生产，软件行业呈现出规模经济的特点，如同在汽车制造业中一样。
•

而在诸如企业用户产品之类的市场中，为获得竞争优势而开发的商业应用程序很少能够进行批量生产，软件仅呈现出范围经济的特点，如同在商业建筑领域中一样。

现在我们可以清楚地看到苹果与桔子之间的区别了。将实物行业的生产与软件开发进行比较未免有些天真。不管是软件还是实物，在任何类型的开发中寻求规模经济效果都是没有意义的。但是，我们却可以期待软件开发的产业化能够带来范围经济的效果。
产业化会带来什么样的结果？

假设可以在软件行业实现产业化，那么结果将会是什么样子呢？当然，在事情发生之前我们不可能确切地知道。但是，我们可以根据软件行业的发展道路以及其他行业产业化后的情形作出合理的推测。显然，软件开发永远不会简单到懒人们所希望的那种纯机械化的程度。相反，满足全球需求的关键是不要再把杰出开发人员的时间浪费在机械琐碎的任务上。我们必须尽一切努力更好地利用这些稀有资源，不要再让他们把时间花费在手动构造因为下一个主要平台版本的出现或者市场条件的变化而致使行业需求改变进而导致短短几个月或几年内就需要维护甚至替换掉的最终产品上。

实现此目的的方法之一就是为开发人员提供各种途经，使他们能够将自己的知识转化成可供他人重复利用的资产。这个目标是否遥遥无期？有些模式已经表现出重复利用知识的有效性，尽管利用程度不高。下一步是使用语言、框架和工具自动生成模式化的应用程序，从而实现从编程到自动化的飞越。

半导体开发为软件开发实现产业化后的情形提供了预演。这并不是说软件组件很快就能象 ASIC 那样易于组装，ASIC 是经过封装和接口技术领域二十年的创新和标准化而开发出来的产品。但另一方面，软件开发可能用不了 20 年。软件开发的优势在于只需要处理比特，而半导体行业还需要承担组件实现所需的物理材料工程的额外负担。与此同时，比特所固有的短寿特性也为诸如数字知识产权保护等带来了难题，正如我们在电影和音乐行业所看到的那样。

（来源：www.microsoft.com 作者：Jack Greenfield）

---

Web 服务<layer style="background-color: Yellow; color: black;" id="google-toolbar-hilite-5">软件工厂</layer>

关于<layer style="background-color: Yellow; color: black;" id="google-toolbar-hilite-6">软件工厂</layer>

p&p 团队最近开始发布<layer style="background-color: Yellow; color: black;" id="google-toolbar-hilite-7">软件工厂</layer>，它们采用更注重整体方法提供指导。这些<layer style="background-color: Yellow; color: black;" id="google-toolbar-hilite-8">软件工厂</layer>是指导资产工具、可重用的代码、文档、参考实施方法等类似内容的集合。它们有助于根据公认的模式和预定义的标准实现软件生成过程的自动化。

一般而言，安装<layer style="background-color: Yellow; color: black;" id="google-toolbar-hilite-9">软件工厂</layer>的目的是扩展您的开发环境，增加与指导有关的工具和资源。例如，<layer style="background-color: Yellow; color: black;" id="google-toolbar-hilite-10">软件工厂</layer>可能包括一些解决方案模板，借助它们，可以更轻松地开始一个新的应用程序。此外，<layer style="background-color: Yellow; color: black;" id="google-toolbar-hilite-11">软件工厂</layer>还可能提供在整个开发周期都能使用的向导和设计器。

<layer style="background-color: Yellow; color: black;" id="google-toolbar-hilite-12">软件工厂</layer>加强了架构师和开发人员之间的关系。架构师可以自定义各种通过某<layer style="background-color: Yellow; color: black;" id="google-toolbar-hilite-13">软件工厂</layer>提供的代码方案，然后，再将自定义好的<layer style="background-color: Yellow; color: black;" id="google-toolbar-hilite-14">软件工厂</layer>应用于开发团队。这为架构师提供了一种实用的机制来将他们自己的指导分发给开发人员。

<layer style="background-color: Yellow; color: black;" id="google-toolbar-hilite-15">软件工厂</layer>的一个主要方面是支持自动化工具。尽管 Visual Studio^® 已通过 Visual Studio 行业伙伴 (VSIP) 计划得到了很大的扩展，但该框架还远远谈不上易于使用。因此，p&p 团队开发了 Guidance Automation eXtensions (GAX) 和 Guidance Automation Toolkit (GAT)，以便架构师可以更轻松地将自定义指导应用于 Visual Studio 的使用过程。

GAX 是在 VSIP 基础上构建的运行库，用于通过指导包对 Visual Studio 进行扩展。而 GAT 是一个工具包，用于部署在 Visual Studio 内的 GAX 上运行的指导包。如果要使用现有的指导包，例如<layer style="background-color: Yellow; color: black;" id="google-toolbar-hilite-16">软件工厂</layer>中找到的指导包，则必须安装 GAX。另一方面，仅当要构建指导包时才需要 GAT。（重要事项：任何人都可以使用 GAT 创建新的指导包。您甚至可以从一个现有的<layer style="background-color: Yellow; color: black;" id="google-toolbar-hilite-17">软件工厂</layer>着手，将其指导包自定义，然后重新生成它们。）有关 GAT 的详细信息，请参阅“指导自动化工具包简介”。

Web 服务<layer style="background-color: Yellow; color: black;" id="google-toolbar-hilite-18">软件工厂</layer>

p&p 团队最近发布了一些新的<layer style="background-color: Yellow; color: black;" id="google-toolbar-hilite-19">软件工厂</layer>，包括 Web 服务<layer style="background-color: Yellow; color: black;" id="google-toolbar-hilite-20">软件工厂</layer>（有时也称为“服务工厂”），下面我将详细介绍一下该<layer style="background-color: Yellow; color: black;" id="google-toolbar-hilite-21">软件工厂</layer>。该<layer style="background-color: Yellow; color: black;" id="google-toolbar-hilite-22">软件工厂</layer>旨在帮助开发人员构建始终遵循知名体系结构和设计模式的 Web 服务解决方案。

服务工厂有两种：一种用于 ASP.NET Web 服务 (ASMX)，另一种用于 Windows^® Communication Foundation（将随 .NET Framework 3.0 提供）。ASMX 版本目前已得到官方支持，可供用户使用。官方发布的 Windows Communication Foundation 版本将与官方发布的 Windows Communication Foundation 一致。不过，服务工厂的 Windows Communication Foundation 版本目前可在 GotDotNet 上的 Web 服务<layer style="background-color: Yellow; color: black;" id="google-toolbar-hilite-23">软件工厂</layer>社区工作区找到其社区版本。

两 个版本都将安装文档和称为 Global Bank Reference Application 的完整参考应用程序。此外，每个版本均会安装多个提供 Visual Studio 自动化的指导包。例如，ASMX 版本会安装两个指导包，一个用于 ASMX 任务，另一个用于数据访问任务。Windows Communication Foundation 版本也会安装两个指导包，一个用于 Windows Communication Foundation 任务，另一个用于有关安全性的任务。指导包管理器（参见图1）可从 Visual Studio 2005 中的“工具”菜单打开，用于启用或禁用可用的指导包。

为了简化这一问题的讨论，此专栏的其余部分将重点介绍如何使用 ASMX 指导包。在以后的专栏中，我将介绍 Windows Communication Foundation 指导包与众不同的方面。

图 1指导包管理器 (单击该图像获得较小视图)

图 1指导包管理器 (单击该图像获得较大视图)

服务工厂入门

在安装时，服务工厂会在“开始”菜单中创建 Microsoft patterns & practices（Microsoft 模式和做法）| Web Service Software Factory（Web 服务<layer style="background-color: Yellow; color: black;" id="google-toolbar-hilite-24">软件工厂</layer>）菜单项。此处有多个指向各种服务工厂资产的链接。打开 Visual Studio 2005 并创建新项目时，会发现一个称为 Guidance Packages（指导包）的项目类型。所安装的每个<layer style="background-color: Yellow; color: black;" id="google-toolbar-hilite-25">软件工厂</layer>都会在此处显示它们提供的模板。如果安装了 GAT，您将看到用于创建新指导包的名为 Guidance Package Development（指导包开发）的包。

选择 Web 服务<layer style="background-color: Yellow; color: black;" id="google-toolbar-hilite-26">软件工厂</layer>（Web Service Software Factory，ASMX），并从右侧以模版形式显示的方案中选择其一。此方案会根据服务工厂指定的体系结构创建初始解决方案结构。选择了模板并按“确 定”后，便会调用方案。此方案首先会要求您指定一个前缀，以便它用于命名即将创建的每个项目（我已指定了 Coho.ClubServices.Membership 作为前缀）。当您按“完成”后，该方案会创建所有项目；生成的解决方案就是您的起点（参见图2）。

图 2生成的解决方案结构

在您使用指导包时，Visual Studio 会提供指导导航器（参见图3）。您可以使用它来导航您所使用的每个指导包提供的各种指导资产。

图 3指导导航器

规定的体系结构

指导包创建的初始解决方案的结构会与服务工厂定义的其中一个规定的体系结构保持一致。此体系结构的主要目标是企业级 Web 服务。但是，请记住，如果具体细节不符合您的要求，您尽可以自定义指导包并修改初始解决方案模板。

规定的体系结构分为三层：服务接口层、业务层和资源访问层。请注意，这些层映射到图2 中显示的所生成的解决方案结构。此体系结构包含分层式应用程序模式（在模式和做法 (p&p) 网站上介绍），这极大地简化了大型系统中的依赖关系管理。

每一层都由若干个彼此密切相关的不同软件组件构成。该体系结构还定义了一些适用于所有层的问题，尤其是安全性、操作管理和通讯。整体的体系结构如图4 所示。

图 4高级服务工厂体系结构 (单击该图像获得较小视图)

图 4高级服务工厂体系结构 (单击该图像获得较大视图)

服务接口层的组件包括服务约定和服务适配器。服务约定定义了服务可以执行哪些操作，但 它不包括任何行为，例如操作的实际执行方式。这就需要定义接口，即按照消息交换模式定义的操作组。对于每个操作，都要定义交换中使用的消息类型，而每个消 息类型都以可编写的数据类型的方式进行定义。服务适配器执行端点（通常称为服务主机）上显示的服务约定，负责调整该端点，使之与基础业务层相适应。

业 务层包含以下三个组件：业务实体、业务逻辑和业务工作流。业务实体是一些为有关域的实际对象建模的类。它们不同于服务约定中使用的数据类型，因为它们包含 行为，而且还可能包含状态。体系结构会封装业务实体，使它们不会暴露在服务边界之外。这可以确保每层内更加灵活，也让您有机会能够以不同的方式设置数据的 格式，使它们符合具体的综合情况。不过，这也意味着，必须进行实体转换才能在层与层之间移动。

业务逻辑执行实际的业务行为。这些类对业务实体进行操作，以便执行所需的行动。某些业务实体非常简单，而有些实体则利用更复杂的逻辑。

业务工作流处理那些需要复杂的消息关联和状态管理的长期运行的流程。业务工作流通常由业务工作流管理产品（如 BizTalk^® Server 2006 或 Windows Workflow Foundation）来执行。

业务层在基础资源访问层之上进行操作，后者提供对数据访问逻辑和服务代理的访问。数据访问逻辑提供您与基础数据存储区交互时所需的一切，而服务代理则提供您与外部 Web 服务交互时所需的一切。图5 显示了这些层和软件组件如何彼此关联的详细视图。这些组件中的每一个都与初始解决方案中的一个项目相对应。您可以看到，服务工厂的范围相当广泛。它提供的指导从使用者开始，再到所有方法，最后是后端数据源。

图 5层组件和关系 (单击该图像获得较小视图)

图 5层组件和关系 (单击该图像获得较大视图)

数据访问指导

服务工厂包括数据访问指导包，后者为实现数据访问层中的常见任务的自动化提供了许多方案。通常，要启动方案，只需右键单击某个项目，然后从服务工厂上下文菜单中选择相应的方案即可。（在特定上下文中，每个启用的包都有一个对应的菜单。）您也可以从指导导航器直接调用方案。

要 实现数据访问层，开发人员必须执行几个常见任务。这些任务通常比较单调，而且容易出错。您在此处首先想要使用的几个方案之一是 Add database connection（添加数据库连接）方案。您可以从 Host（主机）项目的上下文菜单中选择它，以将其启动。该方案会要求您输入连接名称，然后要求您指定数据库连接的详细信息。在按下“完成”后，该方案会 在 Host（主机）项目的配置文件中添加指定的连接字符串。

接下来，（假定您的数据库模型已就绪）您可以生成一组存储过程，其中封装了针对数据库模型中的特定表的典型操作（例如，选择、插入、更新和删除）。该方案会让您选择表并为每个存储过程操作指定名称（参见图6）。

图 6生成存储过程 (单击该图像获得较小视图)

图 6生成存储过程 (单击该图像获得较大视图)

借助这些简单的方案，就不必为了满足将服务与现有的数据库模型集成的需要，而编写大量代码。除了生成代码之外，它们还让您确信，实施过程是按照经实践证明的最佳做法进行的。而且，您尽可方便地添加更多方案来满足自己的特定需要。

生成业务层代码

数 据访问指导包还提供了一个方案，用于生成与基础数据库模型相对应的业务实体。此方案可以从业务实体项目的上下文菜单中调出。方案会要求您选择数据库连接， 然后它会列出所有可用的表和视图。接着，您可以指定要使用的表和视图。然后，您可以针对每个表和视图自定义每个业务实体类的名称以其包含的字段。

生 成的业务实体类会给原有表的设计建模。生成的代码包含一个构造函数，以便使用所提供的数据填充新的实例，使用属性访问代表表中各列的基础字段。尽管使用此 方法可以生成业务实体层的大部分，但您一定需要扩展或自定义所生成的代码。该方案会以分部类的形式生成这些实体，让您可以安全地扩展或重新生成它们，而不 必直接修改所生成的代码。

在业务逻辑项目中，您必须为该层手动编写大部分代码 - 您的业务逻辑类应该在业务实体类上进行操作。由于任何特定的应用程序都有其特有的业务逻辑，所以在这部分中可以自动完成的任务不多。

但 是，您可以生成知道如何在生成的业务实体和生成的基础存储过程之间进行集成的数据存储库类。这一操作可使用 Create data repository classes from business entities（根据业务实体创建数据存储库类）方案来完成。该方案会要求您定义特定业务实体和存储过程之间的映射，之后，您还需要为存储库类定义要为 其生成的每种方法的名称和类型。完成后，即拥有了在数据和业务层之间来回移动所需的类。

服务层任务

ASMX 指导包提供多个可自动完成常见服务层开发任务的方案。由于规定的体系结构不允许业务实体暴露在服务边界之外，所以在服务层中的第一要务就是定义各种用于构造消息的数据类型。

Create data type（创建数据类型）方案可用于定义由适当的序列化属性注释的、与 XmlSerializer 兼容的类。您无需改动任何代码即可定义该类。该方案基于项目命名空间、年份和月份，采用试探性的方法在定义这些类型时选择 XML 命名空间。然后，它会要求您指定构成类型结构的数据成员。

如果已经有现成的 XML 架构定义，可以使用它们来以其他方案定义数据类型。您只需将 XML 架构文件添加到数据类型项目，右键单击它，然后从架构中选择 Create data type（创建数据类型）。该方案使您的开发过程支持架构优先的设计方案。

创建好所有服务层数据类型后，就可以使用 Create message type（创建消息类型）方案来定义消息类型。该方案可在服务约定项目中找到。方案会要求您命名用于请求和响应消息的类，还会要求您指定构成每个消息结构的数据类型（参见图7）。然后，会生成更多与 XmlSerializer 兼容的类来表示这些消息。

图 7创建消息类型 (单击该图像获得较小视图)

图 7创建消息类型 (单击该图像获得较大视图)

创建好所有消息类型后，就可以使用 Create service contract（创建服务约定）方案来设计服务约定定义了。该方案首先要求您指定服务约定的名称和命名空间。然后，需要您列出希望该服务约定支持的操 作。对于每个操作，您需要指定方法名称（操作），接着指定该操作映射到的相应的请求/响应消息。

定义了服务约定的详细信息后，即可指示该方案生成服务实现类（参见图8）。生成的 ASMX 类将实施您先前在该方案中定义的服务约定。

图 8生成服务实现类 (单击该图像获得较小视图)

图 8生成服务实现类 (单击该图像获得较大视图)

每个 ASMX WebMethod 的实现都应该调用业务层中定义的业务逻辑类。不过，要这么做，WebMethods 必须首先在服务约定类型和业务逻辑中使用的业务实体类型之间进行转换。由于这是一个常见而单调的任务，所以可用一个方案来生成转换代码。此方案名为 Create service contract translator（创建服务约定转换器），默认情况下，可在服务实现项目上调出。它提供用于在两个类之间定义映射的用户界面，而且会生成帮助转换器类 中的代码。接下来，您只需在调用相应的业务逻辑之前将生成的转换器类用在 WebMethod 的实现中。

服务实现后，即可对外公开了，请运行 Expose service（公开服务）方案，以生成引用 ASMX 实现类的 .asmx 端点。此时便可以对它进行测试了。

客户端和测试

您可能已经注意到了，生成了解决方案结构的原始方案已自动生成了一个可用作服务层测试工具的客户端应用程序。要使该客户端应用于您的特定服务方案，可能需要编写一点代码。

可 用于构建和测试客户端的服务工厂方案有多个。例如，服务工厂提供了 Add service reference（添加服务引用）方案、Debug client（调试客户端）方案以及 Run client（运行客户端）方案。服务主机上还有一些与测试有关的方案，例如 View in browser（在浏览器中查看）和 Debug host（调试主机）方案。

自定义解决方案

您可能会觉得服务工厂生成的解决方案对您的特定项目而言威力太大。或者觉得它不完全适合贵组织的要求或标准。要解决此问题，可以自定义解决方案：只需修改原始方案生成的内容，然后为规定的体系结构中的各层重新分配项目职责即可。

要 重新分配项目职责，必须在服务工厂菜单中选择 Unlock solution（解锁解决方案）来取消对解决方案的锁定。然后，右键单击服务约定项目，并选择 Specify project responsibility（指定项目职责）。在随之出现的对话框中，可以轻松指定各种职责（参见图9）。

图 9指定项目职责 (单击该图像获得较小视图)

图 9指定项目职责 (单击该图像获得较大视图)

更改完解决方案后，应将其重新锁定。您也可以导出修改后的解决方案模板，以便能够根据修改后的解决方案再生成指导包的自定义版本。

总结

Web 服务<layer style="background-color: Yellow; color: black;" id="google-toolbar-hilite-27">软件工厂</layer>提供了许多有价值的指导资产，借助它们，就能在开发 Web 服务解决方案时加快速度，提高质量并保证一致性。它包括有用的书面指导，以及阐述了规定的体系结构、模式和实践做法的完整的参考应用程序。此外，服务工厂还提供了多个指导包，可自动完成许多常见的开发任务。

建议您下载 Web 服务<layer style="background-color: Yellow; color: black;" id="google-toolbar-hilite-28">软件工厂</layer> (Web Service Software Factory ) 并了解其诸多功能。您还可以了解 MSDN^® 的动手实验套件（可从 GotDotNet 网站获得），进行逐步演练。

---

软件作坊如何成为<layer style="background-color: Yellow; color: black;" id="google-toolbar-hilite-29">软件工厂</layer>

在世界软件业进入工业化生产的今天，中国却依然在进行小作坊式生产。仍然没有走出凭借个人英雄主义打天下的"作坊式"经营模式，规模偏小仍然成为制约竞争 力的重要因素。在现阶段的中国，绝大多数企业与其说是软件企业还不如说是软件作坊，企业员工在50人以下的占多数，甚至还有些软件公司只有七八个人，规模 小且分散。
在这些小企业里，虽然用的是最好的计算机和最先进的开发工具，但生产方式却是作坊式的。既没有项目规划书，也没有项目经理，更谈不上系统分析和设计。基本上靠一两个程序英雄单枪匹马，边想边写代码，一旦这些英雄们因故离开，正在开发中的项目就必须得停止。
　　另外，程序英雄们"跳"得也快，程序员能兢兢业业在一家公司做上几年的绝无仅有。况且，这些英雄动不动就另立山头，招兵买马，然后利用自己掌握的资料开发产品，甚至跟原来的公司竞争。如此以来，全国的十大软件产业基地里到处都是这种作坊式企业。
　　因此，几个程序英雄组成的软件作坊如何转变成<layer style="background-color: Yellow; color: black;" id="google-toolbar-hilite-30">软件工厂</layer>，是一直困扰国人的问题，本文将就管理、技术和政策环境几个方面进行一些探讨。
一、深入贯彻软件工程思想
　　我国的软件企业由于规模太少，大多数企业局限于小软件的开发，大型软件大多来自国外，其中很重要的原因是开发过程管理不成体系，难以开发出高质量的软件。
　 　软件工程强调软件开发过程的"工程"性，把软件的设计、开发、测试、维护和管理工作当做一项系统工程来抓，表明软件不仅仅是编写代码的工作，而需要各个 学科的综合应用，才能形成真正的产业化。国外在软件工程方面的经验和标准及国内在此方面的探索无疑将给软件界人士很好的启示。
　　国人一直认为软件行业是聪明人的行业，凭的是高智慧，程序员都不愿意写文档。大多数编程人员基本没有软件工程的概念，我们身边有大把大把热血沸腾、雷厉风行的工程师们根本就没有踏踏实实搞设计的理念，他们一有思路就开始写代码，写完了就试，试通就得，不通再想办法。
　　由国内一些软件工程化思想的积极推动者和实践者创建的软件工程专家网，就是要唤醒大多数软件工程师的意识，教大家学会走软件工程之路。
二、严格项目管理，改进软件过程
　 　随着信息技术的飞速发展，软件产品的规模也越来越庞大。我们知道，软件开发是一个带有一定风险的工作，为了把风险降到最低，项目经理一定要进行严格的项 目管理。软件项目管理就是为了使软件项目能够按照预定的成本、进度、质量顺利完成，而对成本、人员、进度、质量、风险等进行分析和管理的活动。进行软件项 目管理有利于将程序员的个人开发能力转化成企业的开发能力。企业的软件开发能力越高，表明这个企业的软件生产越趋向于成熟，企业越能够稳定发展。
　　在项目管理的过程中，可以结合先进的管理软件和工具软件，形成规范性的文档，逐步总结经验，对当前的工作流程进行分析、整理及文档化，形成适合自己企业发展的软件过程，并用该文档化的过程指导软件项目的开发。
　 　在具体实施的过程中，可以选择有一定代表性和完善性的项目先进行试点，跟踪、监督软件过程的实施情况，对不满意的地方加以完善，使其成为一个尽量完美的 软件过程方案，然后将这个软件过程应用到当前正在承接的或即将承接的项目上，在实际使用过程中进一步发现其中的不足和错误之处，加以改进，最后将试点的结 果推广到整个企业。
三、引进先进的管理标准
　　中国的软件业要想真正成为产业，就必须引进先进的管理标准，改变整个软件业管理的方式和方法。特别是随着中国加入WTO，中国软件业要提升国际竞争力，在世界上占一席之地，解决与国际接轨的问题也变得越来越紧迫。
　 　近年来，我国已开始有越来越多的软件企业开展ISO9000质量体系认证活动，这为规范软件企业的管理起到了一定的推动作用。然而，ISO9000系列 标准并非为软件企业特别制定的，它是适用于各种生产和服务过程的标准化的质量控制体系。作为通用的标准，它更像硬件制造业的专用品，在软件产业实施起来显 得力不从心，十分别扭。
　　自2001年以来，国家很重视软件企业引入国际通行的CMM认证。作为目前国际上最实用的软件生产过程标准和软件企业 成熟度等级认证标准，CMM能帮助软件企业改进和优化管理，实现软件生产工程化。中国软件企业必须加紧实施CMM认证，走规范化发展的道路，提升水平，形 成规模。然而，CMM是以承接政府大型软件合同的企业为对象而制订出来的，我们只能"引进"而不能"拿来"，要根据我国软件企业的现状进行裁减。
　　特别要声明的是，企业实施CMM是为了让企业更好地发展，为企业进一步扩大规模打下坚实的基础。如果企业只是为了获得一纸证书而通过CMM，那么就已经本末倒置了，对企业的长久发展反而有害。
四、广泛使用软件复用技术
　 　软件复用是指在两次或多次不同的软件开发过程中重复使用相同或相似软件元素的过程。软件元素包括程序代码、测试用例、设计文档、设计过程、需要分析文档 甚至领域知识。对于新的软件开发项目而言，它们或者是构成整个目标软件系统的部件，或者在软件开发过程中发挥某种作用。
　　软件企业使用了软件复 用技术之后，开发人员在不断完成新项目的同时，对自己的工作允许复用的部分必须不断进行分类，建立索引，并提炼出简单的使用接口。使得以后的软件项目，只 要是重复或类似的工作都不必重新开发，而调用以前的工作成果就可以了。这样一来，企业就总在开发以前没有做过的新东西。当部件足够多时，一个新的项目几乎 可用以前的可重用的部件就可以搭建起来。并且，对新员工来说，只需要学习部件的简单接口即可。这时，<layer style="background-color: Yellow; color: black;" id="google-toolbar-hilite-31">软件工厂</layer>已经基本形成。
　 　由此可见，使用复用技术可以减少软件开发活动中大量的重复性工作，这样就能够提高软件的生产率，减低开发成本，缩短开发周期。同时，由于软部件大都经过 严格的质量认证，并在实际运行环境中得到检验，因此，复用软部件有助于改善软件质量。此外，大量使用软部件，软件的灵活性和标准化程度也得到了提高。
　　因此，软件复用虽然只是一项技术，但它却孕育着一场变革，可以使软件开发的小作坊变成大工厂，使软件行业从"小农经济"走向产业经济。
五、大力培养软件工人
　　一提到软件产业，国人就自然而然地拿中国跟印度比。印度软件业发达就是因为有很多熟练的软件编程工人，但其技术水平很低，仅仅相当于"来料加工"。国人一向认为软件是聪明人的行业，但作者认为，中国不缺软件英雄，缺少的恰恰是软件代码工人。
　 　据了解，今后几年内我国信息产业的增长每年至少需要40万IT人才，其中一半是软件人才，而我国目前高校每年培养出来与IT相关的大学毕业生仅5万人左 右，这其中还有部分毕业生出国或者从事其他行业工作。缺少合格的软件工人，是国内很多软件企业发展的最大障碍。现在的软件企业只能用高学历的专业人才来从 事简单的编程工作，不但导致人力资源成本过高，限制了企业的总体员工规模，同时也降低了软件价格上的国际竞争力。
　　因此，我们要大力培养软 件人才，这包括中国在每年培养5万多名计算机专业毕业的高级"白领"之外，还要培养一大批软件业的"蓝领" 工人，来填补人才需求方面巨大的缺口。 大批"蓝领" 工人进入软件业，除了可以降低开发成本之外，还可以促进软件企业真正采取工厂式运作并形成标准化，从而极大地避免对个别程序员的过分依赖，保持企业发展的 稳定性和可持续性。
六、政府的政策扶持
　 　我国政府在支持和帮助我国软件业发展方面所作出的贡献是不容质疑的，如果没有政府的支持，中国的软件发展道路将会更为曲折。近年来，政府一直表态支持我 国软件业发展，也出台过一些支持软件产业的政策规定，例如《鼓励软件产业和集成电路产业发展若干政策》，从法律和政策上给予软件企业很多的优惠措施；另 外，副总理吴邦国也曾经向10个国家软件产业基地代表授予过标牌。由此看来，我国政府对软件业的发展算得上是用心良苦。 但是，国家的这些政策是否都落到实处了呢？
　　从政策环境方面来考虑，目前，中国软件产业发展面临的最大障碍是软件盗版。大量存在的软件盗版 行为，严重地影响软件企业的生存和发展，盗版使软件企业无法获得正当的投资回报，极大地限制了软件企业的规模。软件盗版严重削弱了中国软件企业的竞争力， 使其在竞争中处于不利的位置。
　　其次是资金匮乏。软件行业是一个高投入、高风险的行业，对于一个软件企业来说，如果没有通畅的资金来源渠道就等 于自掘坟墓。如果没有大量资金的注入，光有很好的创新意识和智力资源，不可能转化为商品到市场中去流通，也不能从中获取高的利润回报，更谈不上企业规模的 扩大。

---

组件技术造就<layer style="background-color: Yellow; color: black;" id="google-toolbar-hilite-32">软件工厂</layer>

软件开发一直以来都受到以下几个方面的困扰：开发预算和开发进度时常超出预定的限制条件、维护成本增长过快、不恰当的功能设计、拙劣的性能、不断膨胀的bug和代码量、不兼容、重复开发等等。这些问题在最严重的情况下就会导致所谓的“软件危机”。现在，我们有了两种明确的技术措施有望解决以上的问题：组件技术和软件开发的工厂模式。

组件技术对软件开发的促进作用是非常显著的。发端于上个世纪50年代的组件技术开发思想源于传统的软件模块和五花八门的子程序库。以后，其原形中还出现了抽象数据类型以及在此基础上诞生的面向对象开发思想。但是，组件技术超越了以上所有这些软件开发概念，采用组件技术开发大规模、不同类乃至分布式的系统速度快而成本也得到大大降低。

目前，财富1000家榜上公司中有大约80%在过去的三年中对基于对象或者组件的系统进行了投资。分析人士估计，到2002年，组件软件的收益即可达到79亿美元，其中软件本身占24亿美元，服务占55亿美元。到2003年，市场上出售的新软件中将有70%是主要通过各种软件“建筑模块”生产出来的，这些所谓的软件建筑模块其实就是各种各样的程序框架、模版和组件库。其市场年增长率可望达到30%。

组件技术是一种近来才开始日益普及的最新软件开发技术。到目前为止，我们还很难确定组件技术的明确定义。比如，对组件技术的常见说法有以下这些：“二进制软件单元”、“任意场合可部署的软件”、“特别适合第三方开发”和“规范定义的接口”等等。大致上可以这样理解组件技术：所谓组件，其实就是一种可部署软件的代码包，其中包括某些可执行模块。组件单独开发并作为软件单元使用，它具有明确的接口，软件就是通过这些接口调用组件所能提供的服务，多种组件可以联合起来构成更大型的组件乃至直接建立整个系统。组件必须是自包含的，组件设计中必须包括需求、源代码和可执行代码、接口规范、分析和设计模型、测试和其他同类术语。组件的实现必须支持一种或者多种其用户所希望获得的接口。

实现组件并不一定需要采用面向对象语言。支持组件的技术包括COM+、CORBA和Enterprise JavaBeans （EJB）等。

组件技术的多样性可以让那些采用组件技术的机构大大降低系统风险。当软件工作人员更新系统中旧有的组件时，采用组件系统的机构仍然可以正常运转。

组件的组装产生了<layer style="background-color: Yellow; color: black;" id="google-toolbar-hilite-33">软件工厂</layer>的概念。为了构造新应用程序，软件开发人员找出适当的组件，将这些组件加入到正生产中的应用程序，同时对应用程序进行测试并保证应用程序的组装工作按照预定的规划正常进行。软件开发人员所起的作用和车间流水线工人别无二至，只是开发软件的“流水线”上跑的是应用程序产品。

<layer style="background-color: Yellow; color: black;" id="google-toolbar-hilite-34">软件工厂</layer>的出现使得软件开发商可以通过可重复的开发过程快速生产出效率高、成本低、质量好的企业级软件。<layer style="background-color: Yellow; color: black;" id="google-toolbar-hilite-35">软件工厂</layer>所提供的软件基础架构可以实现快捷的、生产线级的软件生产能力。具体包括：建立标准结构、软件中间件、开发过程、实践、扩展的集成开发环境、组件库和知识库以及重用策略等。

<layer style="background-color: Yellow; color: black;" id="google-toolbar-hilite-36">软件工厂</layer>是唯一一种在建立工厂的同时生产产品的特殊“工厂”。这种方式可以大大降低现代软件开发的成本和复杂性。只有当我们在建立<layer style="background-color: Yellow; color: black;" id="google-toolbar-hilite-37">软件工厂</layer>和生产软件之间划清了明确的界限的情况下，软件的工厂化生产才会得到成功是实现。

由此，我们把软件开发人员划分成三种类型：工厂建设人员、组件开发人员、系统建设人员和组件装配人员。工厂建设人员搭建生产设备并负责建设工厂。组件开发人员是工厂的核心成员，他们负责建立可重用组件。系统建设人员和组件装配人员负责把软件需求转化为组成系统的模块，这些模块再由已经过质量检验的其他代码模块组装而成。

这可不是一篇科学幻想小说，今天的软件开发产业中已经存在多种技术和多家厂商支持面向组件的大规模软件生产了。CA、Inprise、 Microsoft、Rational、Sun、Symantec和众多其他厂商都纷纷推出了各种基于组件和Web的集成开发环境，其中包括了大量的软件结构和组件库。支持对象和组件概念的编程语言也不少，比如Java、C++、Ada、Eiffel甚至VB等都可以达到组件设计目标。在中间件和基础结构组件方面，有COM+、CORBA和EJB/J2EE这几种结构/环境供开发人员使用。BEA、IBM、Iona、Microsoft、 Persistence和Sun/Forte 都可以提供相应的应用服务器、基础组件和组件框架。数据库厂商如 Oracle和Informix也支持对象和组件概念。

是的，今天我们已经具备实现面向组件软件生产的条件，但是只有当以上技术都趋于成熟的时候我们才有必要进一步提出更好的<layer style="background-color: Yellow; color: black;" id="google-toolbar-hilite-38">软件工厂</layer>解决方案。

---

<layer style="background-color: Yellow; color: black;" id="google-toolbar-hilite-39">软件工厂</layer>项目简介

项目开发，既是企业需要投入人力财力的环节，也是IT从业者经验积累的重要历练过程，华育国际教育集团作为软件人才培养的实训基地，为企业与学员之间搭建了一个以项目开发为媒介的<layer style="background-color: Yellow; color: black;" id="google-toolbar-hilite-40">软件工厂</layer>。

<layer style="background-color: Yellow; color: black;" id="google-toolbar-hilite-41">软件工厂</layer>，致力于为企业提供低成本完成项目开发成果途径的同时，也让在校学员有机会亲身参予到实际的项目开发当中，让学员真正获得实际的项目开发经验。我们有三大优势：

一 . 实战经验丰富的师资团队

我们的教师拥有丰富的项目开发经验、极强的项目管理能力、严谨科学的研发能力、丰富的社会阅历及教学经验，他们都曾是优秀的软件工程师，整个项目的设计和管理将由我们的资深工程师来完成。

二 . 动手能力强，掌握主流技术的优秀学员

在项目开发过程中，基础编码是优秀学员在教师的指导下或独立完成的，学员因为经过华育国际1年的强化培训，与学历教育走出校园的学生不同的是，他们拥有很强的动手能力，并且能够掌握J2EE/.NET等主流技术，他们在<layer style="background-color: Yellow; color: black;" id="google-toolbar-hilite-42">软件工厂</layer>的项目开发，以掌握实战经验为目的，能够最大程度地降低企业项目开发成本。

三 . 教育集团雄厚的实力，诚信的服务理念

华育国际教育集团成立于2000年，办学7年多来始终致力于我国IT紧缺人才的培养工程，培养适合中国软件行业的实用型人才。至今已发展成为拥有北京、天津、济南、青岛、沈阳、哈尔滨、南昌等多家分校的大型专业IT人才培训机构，致力于在业界拥有良好的口碑，诚信办学，服务社会是华育国际一贯的宗旨。通过<layer style="background-color: Yellow; color: black;" id="google-toolbar-hilite-43">软件工厂</layer>，使企业降低成本，使学员获得项目实战经验，成为具有过硬IT职业技能与优秀职业素质的国际化软件工程师，使学校拥有更好的口碑，最终达到多方共赢是华育最大的愿望。

近日，微软（中国）有限公司与华育国际教育集团在北京签定《共同开展职业教育战略合作协议》，标志着华育国际教育集团正式加入微软全球合作伙伴计划（MSPP），成为“微软授权（全球）高级技术培训中心（CPLS）”。双方将在研发课程、教材，建立微软项目实训基地，携手进行各方面的广泛合作。微软教育还计划在年内提供相关硬件及软件建立一个专属华育的微软技术实验室，完善学员专业知识和前沿技术的同时，发挥微软公司在软件技术、管理、培训等方面的领先优势，与华育国际共同促进软件人才事业的发展和建设。

---

利用软件工厂和 Visual Studio Team System 度量成功

简介

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

数十年来，软件业已打造出多个软件系统来满足其客户的需要。即使拥有所有这些开发经验，软件质量和生产力却未能随之快速提高。根据 Standish Group 所进行的一项年度调查，我们发现我们现今的生产力水平与 10 年前几乎没有什么分别。目前，在所有软件开发项目中，有 54% 的项目在超出预算的情况下交付，66% 的项目未得到其客户认可，90% 的项目无法按时交付！但该调查所揭示的最令人烦忧的一点是，这些数字在过去的十年里一直都没有多少改观。

召集一组开发人员或项目经理，当面问他们，是否觉得自己如今在构建软件领域做得比较成功。多数人在这时往往是置之一笑，同时承认他们也是这种结果的牺牲者。令人遗憾的是，我们往往认为，由于构建软件是一个极具创造性的过程，因此我们必须要容忍糟糕的交付项目。
目前构建软件的方式

生产力低下通常是由于未能正确了解需求或未能全面了解需求而造成。不止是构建不适合的系统会导致生产力严重下降，当项目范围在逐渐扩大，导致其超出最初的功能量时也会导致生产力严重下降。我们还发现，要达到令人满意的测试水平以确保预期的质量水平是很困难的。不成功的维护和升级发布通常与无法预见到代码更改对产品质量的影响有关。我们该如何确保对系统某一部分的更改不会破坏另一部分呢？

由于我们很少从曾经完成的项目中吸取教训，因此导致这类问题频繁出现。当问到开发团队他们是否从自己的错误中吸取了教训时，明显会看到几乎没有人会主动积极地去总结教训，并将其应用到以后的项目中。很少有团队会习惯性地重新使用过去创建的解决方案，或者对成功和失败的案例进行记录。结果是，没有充足的知识和信息在各项目之间传递，各开发人员所了解的知识和信息依旧停滞在自己的脑海里。新的开发人员需要重蹈覆辙才能获得以前的开发人员本来已经吸取的经验和教训。开发人员发现很难以脱离现有的项目，因为他们对这些项目太熟悉了，并且发现加入新项目也很难，因为没有留下什么记录可供参考。

由于多数项目都无法按时交付且会超出预算，因此我们意识到，我们还要面对一个可预见性问题。当问到项目经理是如何制定计划和日程表时，可以更明显地看到，许多人都在恪守着旧习惯，他们往往会这样说：“我向我最出色的程序员询问了此功能估计要花费多少时间，然后我会将该估计结果增加一倍；我的程序员往往都比较乐观。”通常，这种“预算”之后就会被缩减，或者是为了交出一份有竞争力的投标条件，使这些数字带来好结果，或者是为了满足预期要求。这些旧习惯是很难以改变的。

但老实说，项目经理几乎要注定依赖专业人员来推测，因为他们没有可靠的量度来代替使用。他们需要能够以一种可靠的方式从软件开发项目收集量度，例如，通过数据仓库。从这些量度中，他们可以了解到其开发团队的运作情况，并利用了解的知识和信息来构想出更准确的估计数据。利用历史数据来对组织或项目绩效进行标准化可以提高估计数据的准确度，但多数估计数据并不是这样得出的。

如果没有良好的可预见性，是很难以掌控项目的。在项目经理进行决策时，如何才能了解这个决策将对其日程表和成本带来什么影响？您不能只是用粗略的估计数据来预测所做决策的影响。这与蒙着双眼射击又希望射中目标并无两异。

这些问题就是我们花费大量时间却生产出很少软件的原因。我们交付的软件质量拙劣且难以控制。要使开发过程尽在掌握之中，我们面临着重重困难。对于实践者来说，很难以对项目进行变更。超出预算的每个小时都会产生额外成本，在测试中（甚至更严重的是在生产中）发现的每个缺陷还要花费更多成本，这与整个过程中做出的每个错误决策的结果是一样的。如今构建软件的代价是非常昂贵的。
使用<layer style="background-color: Yellow; color: black;" id="google-toolbar-hilite-45">软件工厂</layer>

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

关键是将那些创建和修改工作产品的精细活动进行形式化，而不是设法形式化整个开发流程。粗放式工作流随后可根据项目要求和情况来逐渐演化，前提是要一直保持固定流程以确保结果有效。例如，您可以同时着手编写多个类，根据需要在它们之间进行切换，只要在您编译时它们之间的所有依存关系都得以满足。这种机动性即保持了灵活性又防止了围绕单个活动排队的情况。如果将精细活动形式化，而不是试图将整个开发流程形式化，则可以在保证质量、可预见性和生产力的同时而又不失灵活性。您会认识到哪里需要形式化，哪里不需要形式化，从而更容易在灵活性与形式性之间取得适当的平衡。通过仅在需要形式化的环节和时间实施形式化，可以使开发流程随着经验的积累以一种非常系统的自下向上的方式演化。此方法还使收集知识及信息并在各项目和实践者之间传递这些知识及信息变得更加容易，本文稍后会对此进行阐述。

解决问题时需要创造性，但执行机械和/或琐碎的活动时不需要创造性。遗憾的是，典型开发人员的日常工作中有很大一部分是由机械和/ 或琐碎的活动组成，但这也许不会让人感到意外。保证生产力和可预见性而又不失灵活性的关键是，在需要创造性的方面激发并支持创造性，在不需要创造性的方面则进行形式化。我们对模式、惯例和工具的形式化范围越大，从流程中剔除的不必要的变更就越多。剔除不必要的变更可以更容易地度量软件开发项目，从中吸取经验教训，并使用这些度量值来改进未来的项目。将机械和/或琐碎的活动形式化减少了在不需要创造性的活动上花费的时间和精力，从而激发了更大的创造性。
<layer style="background-color: Yellow; color: black;" id="google-toolbar-hilite-46">软件工厂</layer>

我们要讨论的是，将软件开发行业化，将已得到其他行业长期认可的方法应用于我们自己的行业，希望的是我们客户和我们自己的情况都能得以改善。这种行业化要通过创建可同时提高软件开发生产力和可预见性的<layer style="background-color: Yellow; color: black;" id="google-toolbar-hilite-47">软件工厂</layer>来实现。

<layer style="background-color: Yellow; color: black;" id="google-toolbar-hilite-48">软件工厂</layer>是由用于加速特定类型软件组件、应用程序或系统的生命周期任务的集成式流程、工具及其他资产组成的打包集。通过为实践者提供指南来协助他们了解要执行任务的内容、执行时间、执行原因以及执行方式，从而实现加速。为此，我们提供了将流程形式化做到恰到好处的流程指南、可快速组装和配置的组件，或可快速完成的框架，并提供了将机械和/或琐碎活动全部或局部自动化的专用工具。

我们希望借助<layer style="background-color: Yellow; color: black;" id="google-toolbar-hilite-49">软件工厂</layer>实现的其中一个主要目标是，从过去针对常见问题或需求创建的解决方案中学习经验和教训，然后将这些经验和教训应用于未来的项目中。为此，我们需要一种描述这些可重用解决方案的方式，还需要一种围绕相关或所关注领域（也就是经常遇到这些解决方案所解决问题或需求的领域）来组织这些解决方案的方式。按照此方式组织解决方案有助于缩小同时需要关注的问题或需求的范围，从而更轻松地确定可能适用的可重用解决方案。这些应予以关注的领域可能处于高抽象级别（例如，定义体系结构层），也可能处于低抽象级别（例如，为 C# 类或接口定义方法签名）。
架构和模板

<layer style="background-color: Yellow; color: black;" id="google-toolbar-hilite-50">软件工厂</layer>使用了 IEEE 1471 术语，即“对软件密集型系统体系结构描述的推荐实践”，它将关注领域称为“视点”。视点可能因多种原因而定义，例如，在软件开发生命周期的不同阶段，在不同抽象级别描述产品的不同部分。各视点是相互嵌套的，因此，“数据访问层”视点可能包含一个“数据访问库”视点、一个“逻辑数据库设计”视点、一个“物理数据库设计”视点以及一个“数据安全性”视点。

从给定视点生产或耗用的工作产品组成一个“视图”。视图由其视点定义，这与对象由其类定义差不多。工作产品可能是某个文件、某个文件的一部分、多个文件或多个文件的多个部分。例如，在“数据访问库”视点中，工作产品可以是一个包含了用于数据库表格的数据访问类的文件。由“数据访问库”视点定义的视图可以是包含一组用于给定数据库中所有表格的数据访问类的项目。视点可以交互组合，也可以呈模块化结构。例如，针对“数据安全性”视点的工作产品可能是数据访问类的插入、替换和更新方法的前导。

视点往往会推动项目类型和工具的创建。例如，“数据访问库”视点可能会映射到一个基于具有某些属性的项目模板的类库项目类型，从而包含具有数据访问类某些属性的项目模板。当我们创建该类型的项目时，就会基于该视点创建视图。视图的内容即是项目文件夹中的文件。这些是由视点定义的工作产品。

在较高的抽象级别，视点往往会推动工具的开发。例如，“业务流程”视点可能由业务流程建模工具来表现。该工具以模型的形式呈现基于该视点的视图，这些模型也就是由该视点定义的工作产品。它还通过菜单命令和其他示意动作（例如，执行从工具箱到图表的拖放操作以创建新的消息类型）来支持由视点定义的活动。

对于每个视点，都需要有一个名称和描述。我们还需要知道生产或耗用的工作产品、创建或修改这些工作产品所涉及的步骤，以及用于执行这些步骤的资产。换言之，视点应该告诉我们要构建什么、如何构建，以及可使用什么来构建（模式、工具、模板等）。视点是<layer style="background-color: Yellow; color: black;" id="google-toolbar-hilite-51">软件工厂</layer>的构建块。它们将那些创建和修改工作产品的精细活动进行了形式化。

每个<layer style="background-color: Yellow; color: black;" id="google-toolbar-hilite-52">软件工厂</layer>都定义了一组构建其产品所需的相互关联的视点。这组相互关联的视点称为“架构”。您可以将工厂架构设想为一个目录，它可帮助您发现<layer style="background-color: Yellow; color: black;" id="google-toolbar-hilite-53">软件工厂</layer>的组织方式，以便您可以使用它所提供的资产来构建其目标产品。工厂架构在很大程度上像是一个数据库架构，数据库架构可帮助您发现数据库的组织方式，以便您可以导航、查询并操纵其中包含的数据。但工厂架构不是描述数据的组织方式，而是描述<layer style="background-color: Yellow; color: black;" id="google-toolbar-hilite-54">软件工厂</layer>的组织方式。

举一个简单例子来说明架构，让我们设想一个基于“面向服务的体系结构”(SOA) 创建“企业管理应用程序”的工厂。对于该工厂，您可能要定义以下视点：

*

前台应用程序。描述支持用户桌面上数据输入的 Web 或 Windows 应用程序的创建。它告诉用户如何使用窗体设计器和您所开发库中的数据输入控件来创建 Web 或 Windows 窗体。用于此视点的活动是创建 Web 或 Windows 窗体。工作产品就是这些窗体。所用资产是窗体设计器和数据输入控件库。
*

流程服务。描述负责管理业务流程的 Web 服务的创建。Web 服务始终按照某模式以同一方式构造，并且带有一个由 C# 接口使用 XSD 架构生成的类型化对象来描述的服务合约。用于此视点的活动是创建 Web 服务。Web 服务即是工作产品。所用资产是模式和类型化对象生成器。
*

平台服务。描述不负责业务数据而仅负责通用于所有系统的服务（如打印、审核、授权等）的 Web 服务的创建。此视点提供了可重用的通用服务，并告诉用户如何评估和定制每个服务。用于此视点的活动是评估和定制这些服务。工作产品是定制服务。所用资产是通用服务。

最后一条要了解的<layer style="background-color: Yellow; color: black;" id="google-toolbar-hilite-55">软件工厂</layer>术语是工厂“模板”，它是一个包含<layer style="background-color: Yellow; color: black;" id="google-toolbar-hilite-56">软件工厂</layer>所提供资产的可安装数据包。要使用工厂，实践者必须将工厂模板安装到工作站上。

工厂通常是以自下向上的方式开发。确定了目标产品系列后，在构建系统时，可以开始发现并描述工作产品和活动；将它们组织到视点中；开发支持这些活动的资产；将各视点组织到工厂架构中；然后将各资产打包到工厂模板中。
功能配置

构建有效工厂的关键之一是定义可在多个不同的解决方案中付诸使用的工作产品、活动和资产。例如，“数据访问库”视点可提供有助于访问 SQL 数据库的库。您可能会发现，您并不是始终将同一个 RDBMS 用于每个项目，因此，您的库必须要容纳其他 RDBMS。与该库配合使用的工作产品和配合库执行的活动的描述可能也必须做出相应调整。视点接受的可变性越多，将其应用于多个解决方案的灵活性就越高，但同时也要执行更多的工作才能将其配置正确。允许可变性却带来了复杂性。您必须在过多可变性与过少可变性之间找到适当的平衡点，才能使<layer style="background-color: Yellow; color: black;" id="google-toolbar-hilite-57">软件工厂</layer>发挥效用。您的工厂的通用性越高，实现的生产力和可预见性就越低。

确定应该允许多少可变性的一个有效方法是分析您期望构建的解决方案的功能。通过利用一种称为“通用性/可变性 (C/V) 分析”的方法，您将那些必须以同一方式在每个解决方案中都出现的通用（或强制）功能与那些可能只在某些解决方案中出现的可变（或可选）功能，或在各解决方案之间出现方式不同的功能分隔开。本白皮书将不对 C/V 分析进行详述，但有许多关于此主题的文章和书籍可供感兴趣的读者参考。

在基于 SOA 创建“企业管理应用程序”的工厂中，“数据访问”是一个强制功能（因为每个解决方案都将执行数据访问），但“Web 前台”却是一个可选功能（因为一些解决方案将带有 Web 前台，而另一些解决方案将带有 Windows 前台或甚至根本没有前台）。

在工厂中，您可以使用功能模型来描述可能在该产品系列的某一成员中出现的功能，以将通用功能与可变功能分开，并指明可变功能的出现方式。（功能模型由 Czarnecki 和 Eisenecker 进行详细描述。有关详细信息，请参阅本白皮书中的部分。）功能模型也可定义关于可变功能的决策相互影响的方式，例如，声明一个可变功能需要另一个可变功能，或一个功能与另一个功能不兼容。通过配置功能模型来为给定应用程序做出这些决策。配置是一个简单的过程，它涉及到指定哪些由模型描述的可变功能在应用程序中出现以及它们中每个功能的出现方式。图 1 显示的是上文所述工厂的一个简单的功能模型。

.
图 1. 功能模型示例

尽管功能模型通常用于按要求呈现的用户可见功能，但它们也可用于仅对开发人员可见的设计、实现、测试和部署功能。某些功能强大的场景通过链接这些功能来启用，以便在配置用户可见功能的同时也配置开发人员可见功能。例如，将用户可见的“前台”功能链接到开发人员可见的解决方案布局功能可能会使工厂根据用户所选的前台类型生成一个默认的解决方案布局。

功能建模只是用于描述可变性的多种知名机制之一。其他机制还包括窗体、表格、向导、设计器、模板、模式、脚本和代码。可变性机制可单独使用，也可以各种组合使用，目的是指定和实现<layer style="background-color: Yellow; color: black;" id="google-toolbar-hilite-58">软件工厂</layer>中的可变功能。
成功的关键

成功过渡到<layer style="background-color: Yellow; color: black;" id="google-toolbar-hilite-59">软件工厂</layer>方法的关键因素是什么？您需要具备以下能力：

*

找到产品中的通用性和可变性。
*

在生产力和质量方面度量您的产品开发流程目前的绩效。
*

定义和改进有效支持产品开发的流程。
*

提供有助于每个人了解所实现的生产力和质量的透明模型，并使用这个透明模型推动文化转型。
*

同时规划多个项目。
*

快速、经济地开发将知识和信息进行封装并使其易于重新使用的可重用资产，尤其是自定义工具。
*

确定特定领域并将自定义工具和流程专用于这些领域，而不是试图将多用途工具和流程应用于所有领域。

返回页首
度量质量和生产力

既然我们已经大概了解了关于<layer style="background-color: Yellow; color: black;" id="google-toolbar-hilite-60">软件工厂</layer>的一些知识，那就让我们更深入探讨一下如何在软件上下文中度量质量和生产力。

事实证明，工厂架构为组织量度提供了一个有用机制。由于每个视点都面向软件开发流程的一个特定方面，因此可以使用各视点来定义生产力和质量的目标度量。使用这些度量，您可以收集软件开发流程特定方面的数据。通过分析这些数据，您接下来就可以确定哪些视点需要改进、如何进行改进以及改进后可获得哪些益处。

要实现此方法，您需要确定一种表示产品规模、所用时间和预算以及产品质量的方式。这些度量可用来量化每个视点的可预见性、生产力以及质量。它们也可用于评估您的工厂生产的最终产品。通过度量每个视点以及工厂总体绩效，您可以确定每个视点对工厂总体绩效的影响有哪些，从而确定要投入多少可重用资产来支持给定视点中的活动。例如，您可以为没有明显影响到总体效率的视点提供简单的指南，为明显影响到总体效率的视点提供高级的基于“域专用语言”(DSL) 的设计器。

此方法类似于大型企业组织优化其业务流程的方式。他们针对特定业务目标定义生产工作产品所需的技能、流程和工具。从这时起，他们度量要完成该流程所需要执行的工作，然后分析哪些方面可予以批准。他们称其为“业务流程监控”，但它基本上还是考评在优化<layer style="background-color: Yellow; color: black;" id="google-toolbar-hilite-61">软件工厂</layer>时要执行哪些工作。显然，在建立工厂当前绩效的基准线和确定要在<layer style="background-color: Yellow; color: black;" id="google-toolbar-hilite-62">软件工厂</layer>开发方面进行的正确投资时，度量是一个关键因素。此过程有助于您在可预见性、生产力和质量方面获得最佳投资回报。它还有助于将结果与最初在开始开发工厂前设定的目标进行对比。
使用功能点表示产品规模

在软件开发中，我们可能想要提高的一个方面就是生产力。要量化生产力，您需要一个可用来根据在一段时间内构建的软件产品量来表示生产力的量度。当我们能够预测系统规模并度量开发过程中产品规模增长量时，我们就可以更好地预测完成该项目所需的时间并根据单位产品规模所用的小时数来度量生产力。通过度量实际的增长量和规模，我们能够鉴别实际值与计划值之间的差异，并在差异变得明显时开始对其进行分析和管理。

此时，您可能想知道我们如何才能以足够的准确度来预测产品规模和增长量，以使这种度量和分析发挥作用。如果我们以一次一个项目的方式开发任意的应用程序，这看起来的确不太可能实现。不过，如果我们使用<layer style="background-color: Yellow; color: black;" id="google-toolbar-hilite-63">软件工厂</layer>，我们就有两个可显著提高可预见性的优势。首先，我们开发的是具有已知特征的特定产品系列的一个成员，而不只是一个任意的应用程序。通过<layer style="background-color: Yellow; color: black;" id="google-toolbar-hilite-64">软件工厂</layer>，我们可以描述一个产品系列及其突出功能，更重要的是，我们可以一边随着多个项目的进展过程积累经验，一边来逐渐优化该描述，因此，对于使用工厂开发的应用程序，我们所掌握的知识和信息要远多于对任意应用程序所掌握的知识和信息。其次，我们将通过应用工厂提供的规定性指南来开发应用程序。因此，我们有许多开发任务在前后各应用程序中的执行方式都大体相同，使用的是一些相同的模式、模板、库和工具。如果我们将执行某些任务的方式标准化，工厂往往就会从开发流程中剔除不必要的变更，使前后各应用程序的产品规模和增长量更有可能遵循相似的模式。 如果我们使用<layer style="background-color: Yellow; color: black;" id="google-toolbar-hilite-65">软件工厂</layer>，则度量这些值并确定、分析和管理计划值与实际值间的差异就会极其有用。

目前已经有多种估计方法可帮助您确定系统规模。如果您想要一个有助于表示规模和生产力的量度，您需要一个目标定量。此目标定量可通过使用标准化的方法实现。其中一个方法就是 ISO 24570 标准中定义的“功能规模度量”(Functional Size Measurement)。（ISO/IEC 24570:2004 指定了度量软件功能规模的方法，提供了关于如何确定软件功能规模各组件的指南，详细说明了如何按照上述方法计算功能规模，并提供了上述方法的应用指南）。此 ISO 标准将功能点用作基于功能规范表示软件系统规模的方法。可将这些功能点视为确定系统规模和预估工作及日程表的“总量度”。在开发期间，此量度可用于确定相对于其他类似项目，该项目是需要执行多一些工作还是少一些工作。

借助功能点，您可以根据业务功能定义系统规模。此功能根据您收集的早期需求来确定，并使用规范来进行评分。功能点分析充分利用了构建面向数据库的应用程序的知识和信息，只要您构建的系统在数据库中使用数据操纵，就可应用该方法。功能点是根据对两个数据的了解计算得出的：您的应用程序将含有的表格估计数；数据操纵函数（如数据检索函数和数据更新函数）的数量。由此，您可以计算出表示产品规模的功能点的数量。在表示了估计的产品规模后，您可以了解实现一个功能点要花费多少时间，甚至可以使用已有的历史数据对实现一个功能点要花费的时间进行预测。<layer style="background-color: Yellow; color: black;" id="google-toolbar-hilite-66">软件工厂</layer>可影响实现一个功能点所用的时间（生产力），每个功能点的缺陷数（质量）以及您的估计数据的可预见性。

再深入探讨一下可预见性，我们已经了解到，工厂是如何允许我们将一个产品系列所有成员的通用功能与仅在某些成员中出现的可变功能或在不同成员中有不同规模或特征的可变功能相分离。因此，我们无需从头收集对给定产品的需求，而是可以假定该产品具有所有系列成员共享的通用功能，并仅将重点集中在详细说明其独特或可变的需求上。

返回工厂上下文中的功能点分析时，我们发现可以将一个始终都存在的固定的最小产品规模作为起点，因为我们的产品系列始终都包含某些固定部分。这个固定的最小产品规模即是该产品系列通用功能的一个度量。我们也可以为许多可以或不可以添加到产品基本配置文件中的可变功能定义可计算规模。从这些信息中，我们可以估计出某一功能配置将要花费的时间和成本。接下来，该信息还可以帮助我们决定要构建哪些功能。换言之，基于功能配置的功能点分析为我们提供了一种预先对成本和功能做出明智权衡的方法。

例如，假设我们应用了功能点分析，并确定我们将要构建的系统的估计规模是 500 个功能点。当我们开始构建此系统时，我们可确定构建它要花费 6,500 个小时。由此我们可以将生产力表示为 13 小时 (h)/功能点 (fp)。

如果我们还在开发、用户验收测试和生产过程中跟踪在产品中发现的缺陷数，则也可以将该数字表示为一个质量量度。假设我们在开发过程中发现 500 个程序错误，在验收测试过程中发现 50 个程序错误，在投入生产后发现 5 个程序错误。我们可以将其表示为，开发过程中是 1 个缺陷/fp，验收测试时是 0.1 个缺陷/fp，生产中是 0.01 个缺陷/fp。

现在，假设其中许多缺陷可追溯到前台应用程序视点。由此我们了解到，在造成所有这些缺陷的原因中，此视点占了很大一部分比重，我们可以集中分析此视点范围内哪些方面可能需要改进。通过这种分析，我们可以确定要改进哪些视点以及如何改进，以减少下次使用工厂时发现的缺陷数。将缺陷数与某量度（如功能点数量）的比值进行量化的好处是，您现在可以为希望通过投资实现的改进方面设定目标。例如，我希望前台应用程序视点的每功能点缺陷数下降 20%。对每个视点逐一执行缺陷和功能点分析为我们改进产品开发流程提供了强大工具，因为它有助于我们确定瓶颈所在之处，从而确定在何处投资以及如何投资才能获得更好的结果。

如果您有更多的开发任务要执行，并且该开发任务涉及到您已收集量度的视点，则刚才所阐述的基本量度可以让您了解有关下一个项目（也许甚至是当前项目）的一些有价值的信息。例如，假设在收集需求并应用功能点分析后，您知道新系统的规模将是 750 fp。您现在就可预测到，实现这些需求将需要约 9,750 个小时的工作，并且将在用户验收测试中发现约 75 个程序错误。

这些预测的准确度在很大程度上取决于您收集的量度级别以及未来的系统开发项目与已收集量度的项目的相似程度。<layer style="background-color: Yellow; color: black;" id="google-toolbar-hilite-67">软件工厂</layer>中的每个视点都允许在系统开发中有一定量的可变性。可变性的量又依次决定了视点可向工厂用户提供的资产类别，从而决定了前后项目之间在产品该方面的一致性程度。例如，在工厂的第一个版本中，可能只有几个描述系统体系结构和只提供支持开发人员完善实现的指南的视点。使用此工厂的开发人员将不得不手动编写大量代码。不过，在使用此工厂构建多个系统后，您可能会看到，由于各个开发人员对指南的理解都截然不同，这些系统的用户界面部分的构造也往往是多种多样。从这个观察事实可以得出结论，用户界面视点允许大量可变性。如果您的工厂中有多个可变性很高的视点，则您的度量值和预测值准确度要低于在视点中可变性有限时的准确度。

此时，我们可能会问到，给定视点中的可变性程度是否真的必不可少。如果不是，我们将能够通过剔除过多或不必要的可变性来提高度量值和预测值的准确度。例如，让我们再一次探讨用户界面视点，但这次我们提供了一组支持指南的库组件和一个配置用户导航路径的图形工具。通过提供这些资产，我们将对用户界面开发流程中先前松散定义的某些方面进行形式化。这种形式化减少了用户界面视点允许的可变性的量。使用此工厂开发的系统将在用户界面构造中展现出更多的一致性，从而使我们的度量值和预测值更加准确。由于估计数据中的错误量会随着工厂允许的可变性的减少而减少，因此，在工厂通过剔除过多或不必要的可变性而逐渐演化的过程中，可预见性也会随之提高。实际上，生产力和质量往往也会随可预见性提高，因为减少可变性也就减少了构建给定功能所需的时间量以及在其构建过程中引入的缺陷数。此时，有一则警言妙语用在这里很适宜：按照 Occam 的剃刀法则，应尽可能多地减少可变性，但绝不要减少到因过分限制开发人员而使项目耗时更长、成本更高的程度。

当您着手使用功能点时，最初可以使用文档资料中记载的周围组织的历史数据来进行第一次估计。历史数据还是很有帮助的，因为它将组织影响（无论是已被公认的还是未得到公认的）考虑了进去。这一理念也适用于在<layer style="background-color: Yellow; color: black;" id="google-toolbar-hilite-68">软件工厂</layer>内对历史数据的应用。使用<layer style="background-color: Yellow; color: black;" id="google-toolbar-hilite-69">软件工厂</layer>开发的各个项目将有许多共同之处。即使没有过去项目的历史数据，您也可以从当前项目收集数据并将其用作预测项目余下部分的基准。您的目标应从使用组织数据或行业平均数据尽快转换为使用工厂数据和项目数据 (McConnell, 2006)。
使用度量改进工厂

通过建立基准或实际校准生产力和质量参数（以小时数/功能点和缺陷数/功能点测得），您可对项目数据进行分析，然后识别那些可能会花费大量时间的活动或产生大量缺陷的视点。校准完毕后，就可以着手更改工厂的组织方式，通过各种途径（如所要求的技能、定义的流程或提供的可重用资产）对其加以更改。确定哪些区域需要改进是至关重要的，以便保证投资到位。但这应该相对容易一些，因为您掌握了用以确定每个视点对可预见性、生产力和质量作出多大贡献的途径。在使用原始数据建立基准后，就可以连续不断地运行以下循环：分析每个视点的性能，使用这些信息确定需要改进的区域，执行改进，然后重复这个过程。

这一有效循环可用于实现各种度量。例如，要提高生产力，可根据小时数/功能点来确定效率最低的视点，然后通过各种方法对其加以改进：提供更多更好的指导或培训；改进用于构建工作产品初始切割的模板；提供用于实现工作产品构建和修改自动化的专业化工具；等等。这一过程的关键部分是估算进行指定改进的成本、估算因改进而可能提高的生产力以及估算结果是否证明投资正确。在实现改进并将其并入工厂后，您可以根据减少的工时数/功能点来度量该改进是否满足预定目标。图 2 阐明了这一过程。

.
图 2. 工厂开发的迭代循环
返回页首
应用 Visual Studio Team System

既然我们已经学习了如何定义工厂以及如何使用度量和分析对工厂进行迭代优化，现在将考虑如何使我们的产品开发团队能够利用工厂来创建所需的工作产品。这一实现要从支持整个产品生命周期（从产生到废止）的开发环境着手，例如 Visual Studio Team System。使用 Team System 是能够使产品开发团队从先前介绍的方法中受益的关键。

Team System 大致分为两个部分。Visual Studio Team Edition（供架构师、开发人员和测试人员使用的 Team Edition）安装在开发机器上，它是 Visual Studio Development IDE 的一部分，为开发团队中的特定角色提供工具。第二部分是 Team Foundation Server (TFS)，它用于托管 Team System 核心生命周期的各个方面，如版本控制、工作项目追踪、团队构建、团队门户以及数据仓库（其中包含使用 TFS 的项目的数据）。
使用 Team System 实现工厂

目前，Team System 并不了解<layer style="background-color: Yellow; color: black;" id="google-toolbar-hilite-70">软件工厂</layer>。不过，由于 Team System 非常容易配置和扩展，我们可以手动将其设置为支持<layer style="background-color: Yellow; color: black;" id="google-toolbar-hilite-71">软件工厂</layer>，也就是将工厂架构的各部分映射到各配置元素或扩展点上。

请记住，<layer style="background-color: Yellow; color: black;" id="google-toolbar-hilite-72">软件工厂</layer>包含用于描述其组织的架构。正如我们已经看到的，工厂架构定义了一组相互关联的视点，每个视点用于描述特定角色用户的相关工作产品、活动和资产。我们可以借助这些信息配置 Team System 进行应用程序开发。

视点可映射到一个或多个迭代中的概念，Team System 称之为区域。与视点关联的角色可映射到一个或多个 Team System 项目角色。实际上，多个视点角色可能会映射到一个 Team System 项目角色。创建项目时，可将视点定义的活动作为工作项目添加到这些区域中，并直接分配给适当的角色。还可以通过定制过程指南将它们记录在案，并创建自定义工作项目类型来追踪它们以及将它们链接到工作产品。有些工作产品可以使用自定义工作项目类型加以描述。可将内容资产（如指南、模式和模板）添加到项目门户文档库中。可执行资产（如工具和类库）可放置在版本控制系统中。为了度量和提高工厂性能，可将量度添加到 Team Foundation 数据仓库中。

配置 Team System 的关键是项目创建向导和过程模板。项目创建向导是在 TFS 中创建项目的工具。它使用用户选择的文件（称为过程模板）来配置项目的服务器。该模板包含许多部分，每一部分都介绍了服务器的一个特定部分的配置方法。例如，使用过程模板可以定义工作项目类型、定制版本控制、定义区域和迭代、定义角色、为每个角色分配适当的权限、设置项目门户以及用以完成定制开发环境和开发过程的许多其他事情。

让我们了解一下如何使用项目创建向导和过程模板以将 Team System 配置为支持<layer style="background-color: Yellow; color: black;" id="google-toolbar-hilite-73">软件工厂</layer>。
定义工作项目

Team System 使用工作项目来追踪创建指定产品所必须完成的工作。工作项目用于描述必须完成的工作，由它们来确定在特定时间点负责该工作的人员。工作项目可以属于不同类型，以描述不同种类的工作。例如，错误可由 Defect 类型的工作项目来描述，其中包含与修复错误相关的信息，如错误的描述、重新生成步骤、分析或修复错误所需的估算时间，等等。工作项目类型通过更改已载入服务器中的 XML 定义创建或修改，然后在项目创建时进行使用。也可在项目建立后进行修改。

有些类型的工作项目是由 MSF for CMMI Process Improvement 定义的，如 Bug 和 Requirement，它们用于描述工作产品。Task 类型的工作项目用于描述某工作产品从一个阶段到另一个阶段所执行的活动。可将这两种类型有效地用在工厂中，因为它们与用于定义该工厂的概念非常相符。特别是，我们可以为由视点定义的工作产品预订工作项目，为关联的活动预订任务。通过这些工作项目，我们可以收集关于每个活动需花费多少时间的信息，然后就可以知道该活动对工厂生产力有多大影响。

执行映射时遇到的问题之一是工作项目当前未相互嵌套。不能嵌套工作项目会难以描述聚合或复合视点（如上面所述的“数据访问层”视点）的工作产品。您还会发现，在典型的团队项目中，许多工作产品并不是由工作项目进行明确描述的。例如，我们不是创建一个工作项目来描述数据访问库，而是创建一个工作项目来描述数据访问库的构建，然后将工作项目链接到配置管理系统中该库的源文件。另一个问题是，Team System 任务并不像工厂中的活动那样在满足条件之前和之后都执行，因此没有记录将它们移入或移出范围的条件，必须手动制定计划决策。
定义区域和迭代

工作项目可链接到所谓的项目区域和迭代。区域提供了一种方法，使您能够在想要针对数据仓库中的累积数据运行报表时预定感兴趣的解决方案特定部分的工作。Team System 中的区域与<layer style="background-color: Yellow; color: black;" id="google-toolbar-hilite-74">软件工厂</layer>中的视点概念非常相符，因为这两者均代表感兴趣或关注的区域。

注册在感兴趣的特定区域上完成的工作后，您会查明哪些区域包含的错误最多或消耗的时间最长。将工作项目追踪中的感兴趣区域映射到工厂视点后，就可以使用这些量度来为特定视点提供生产力和质量度量了。

要从工作项目获得正确信息，您必须在开始产品开发时正确定义区域和迭代。通过为即将开发的产品类型定义感兴趣的视点，您能利用工厂简化这一任务。要想正确建立区域，只需为每个视点定义一个区域。然后可能需要将视点名称映射为您的开发团队所熟知的区域名称，这样，团队成员能够轻松地识别出指定工作项目所属的那个区域。

为工厂定义视点时，开始时最好使用一组常常会出现在许多工厂中的通用视点。在 Business-Collaboration Software Factory 的架构中提供了这些通用视点的有效示例（请参阅本白皮书的结尾部分）。其中，已证实在配置 Team System 时特别有用的两个通用视点是 System Engineering 和 Project Engineering。在 System Engineering 区域中，您应该生成一个子树，其中包含用于描述系统突出部分的体系结构视点。这有助于确定系统中的哪些部分对生产力（花费的时间）和质量（缺陷数）的影响最显著。Project Engineering 也是值得关注的区域，因为它能够帮助您以形式化项目中活动的方式来查找异常情况，它还能够帮助您决定是否改进特定点的过程定义。图 3 显示了一个区域和迭代的示例，它反映了一个简单工厂的架构，该简单工厂用于构建包含多个前端的面向服务的管理应用程序。

.
图 3. 用于反映视点的区域定义示例

您为工作项目追踪定义的区域将随同工厂一起发展。工厂成熟时，组成工厂架构的一组视点会发生变化，您要度量的一组视点也会变化。如果您试图合并由工厂定义的所有视点，区域树会变得相当深。不要将树分成许多个不同的级别，这一点非常重要。请记住，区域树越简单越好，这样团队成员才能够轻松地识别出工作项目应该链接到的那些区域。树嵌套得越深，为指定工作项目找到正确区域就越难。如果难度太大，开发人员会仅仅在层次结构的根附近预定工作项目，从而使创建深度嵌套的树失去意义。
定义角色

您在 Team System 中创建的角色应该反映工厂架构中由视点标识的所有角色。这些角色不必与由视点标识的那些角色完全相同，但项目中的每个角色都应该映射到由视点标识的一个或多个角色。因为由视点标识的角色通常要比为项目定义的角色更为精细，所以，一个项目角色通常可实现多个相关的视点角色。
配置产品功能

通过修改向导和过程模板，用户可以启用由 TFS 随附的默认向导和过程模板启用的配置之外的配置。事实上，您可以创建向导自定义页面，用户可利用这些页面对工厂定义的一部分可变功能进行配置。回到前面的示例，即配置为使用不同数据库产品的数据访问构件块，您可能会先询问用户要使用哪个数据库产品，然后在版本控制中放置一个针对该产品预先配置的构件块版本以着手开发项目。虽然<layer style="background-color: Yellow; color: black;" id="google-toolbar-hilite-75">软件工厂</layer>通常会要求配置贯穿整个开发过程，但定制项目创建向导和过程模板格式确实是一个良好的开端。图 4 显示如何使用自定义向导页面来配置图 3 中显示的功能模型。

项目创建向导是主要的可扩展点，它完全支持查找具有通用性的资产的<layer style="background-color: Yellow; color: black;" id="google-toolbar-hilite-76">软件工厂</layer>概念。将这些资产拿来，然后单独进行开发。为要重复使用的资产定义所需要的不同可变性，然后使用向导页就针对此特定项目必须怎样设置变量来询问用户。然后向导基于输入进行定制，并根据项目的需求来定制资产。虽然<layer style="background-color: Yellow; color: black;" id="google-toolbar-hilite-77">软件工厂</layer>中的通用性和可变性概念超出了这些资产的预配置范围之外，但这可以作为定制的起点。配置选定资产后，工厂可能还会提供其他配置工具，以在项目初始设置完毕后更改选定配置。

在工厂中，您将使用先前显示的功能模型来描述您想要使用的可能功能、对一个功能作出的某些决策影响其他功能的方式以及工厂实例的创建方式。正如您在图 1 的示例中所看到的那样，您可以创建一个功能模型来模拟工厂的一组功能，从而实现使用 SOA 来开发管理应用程序。

图 4 显示了在允许用户预配置工厂的自定义向导页中如何反映此模型。

.
图 4. 项目向导自定义页

除了项目创建向导外，至少还有两种方法用以支持团队项目设置方面的配置。您可以定制版本控制存储库来预见即将在解决方案开发过程中采用的主要配置决策。这样，可便于您在采用决策前将解决方案的状态保存在配置管理中以及在以后必须更改决策时将其恢复。这项技术称为回溯。您还可以定义用于捕捉配置决策的工作项目类型，然后在作出决策时将这些类型的实例添加到工作项目追踪数据库中，以捕捉产出及安排随之而来的工作。
定制项目门户

Team System 提供了一个项目门户，开发团队可利用它来共享项目相关信息。此门户也是特定过程模板的过程指南的入口点以及可重用资产（如模板和指南）的入口点。上传到门户的可重用资产由过程模板提供。您还可以更改过程指南网站中显示的内容。使用 InfoPath 文档来执行这一定制。编译 InfoPath 文档以创建一个可并入过程模板的新网站。上传新过程模板后，就可以创建那些使用您所定制的过程指南网站的团队项目了。
向数据仓库添加度量值

Team System 数据仓库可记录有关解决方案开发的所有类型的信息。数据仓库中有一部分存储的是有关工作项目的信息，如前所述，从工厂的角度来看，这部分信息很重要。数据仓库的其他部分则存储的是有关测试、日常构建和其他 Team System 功能的信息。可以通过两种方式来扩展数据仓库以支持度量值。

首先，可以通过修改特定工作项目类型定义来更改仓库中为该工作项目类型保留的字段，修改方式是更改工作项目类型定义中所包含的字段，或者向仓库中的新事实或维度添加字段。当某字段在工作项目类型定义中标记为“可报告”时，该字段就会动态添加到数据仓库中。当然，如果您希望显示有关这些附加字段的报告，则还必须为这些数据创建报告并将其上载到报告服务器，以便其他团队成员可以访问它们。

其次，您可以将自定义工具生成的数据进行合并。如果您的工厂提供了生成数据的自定义工具，并且您希望在数据仓库中使用这些数据，则可以向 TFS 添加一个自定义数据仓库适配器，如图 5 所示。

.
图 5. Team Foundation Server 数据仓库体系结构

单击查看大图像

例如，要根据代码行数来度量每个解决方案的规模，可以构建一个计算文件中代码行数的自定义工具以及一个自定义数据仓库适配器。在您的日常构建中还要多加一步，即对当前解决方案中的所有源代码运行您的自定义工具，然后将结果放到一个文件中。随后，自定义数据仓库适配器会从该文件中提取信息并调用 Team System 所提供的数据仓库对象模型，以将信息添加到数据仓库中。可使用自定义报告查看自定义数据。
返回页首
使用度量构造 (ISO 15939)

到目前为止，我们已经探讨了如何定义工厂、使用度量和分析优化工厂以及配置 Team System 以支持工厂。在将这些见解综合到一起以通过 Team System 构建和优化<layer style="background-color: Yellow; color: black;" id="google-toolbar-hilite-78">软件工厂</layer>之前，我们还要了解一件事情：如何收集正确的信息。

我们需要的是待度量对象与支持优化所需信息之间的关系的正式定义。这些定义被称作“度量构造”。度量构造是基本度量、派生度量和指标的组合。基本度量使用指定的度量方法来收集某些软件实体的单个特性信息，其在作用上独立于其他所有度量。派生度量被定义为两个或两个以上基本度量和/或派生度量的函数，可收集多个特性的相关信息。指标是通过将分析模型应用于一个或多个基本和/或派生度量来提供估计值或评估值的度量，用于解决指定的信息需求。指标是度量分析和决策的基础。度量构造描述了信息需求、相关实体和特性、基本和派生度量、指标以及数据收集过程。可以向基本度量、派生度量和指标添加其他的规则、模型和决策条件。图 6 例示了度量构造的结构 (McGarry, 2002)。

.
图 6. 度量构造的结构

单击查看大图像

在 ISO/IEC 15939 中，已根据 ISO 国际度量衡学词汇表对有关软件度量标准和度量方法的关键术语进行了定义。本白皮书中所用的术语源自 ISO 15939 和 PSM（实用软件度量）。
定义度量构造

要定义可添加到我们的 TFS 数据仓库中的度量构造，应采用以下步骤：

*

定义和分类信息需求

为确保度量我们需要的信息，必须清楚地了解我们的信息需求以及这些需求与我们所度量信息之间的关系。经验表明，软件开发中的大部分信息需求都可以归入到 ISO 15939 定义的七大类别之一：日程表和进度、资源和成本、产品规模和稳定性、产品质量、流程绩效、技术有效性以及客户满意度。产品规模和稳定性类别中的一个信息需求例子可能是“评估软件产品规模以鉴定最初预算估计值”。

这些信息需求可用于度量<layer style="background-color: Yellow; color: black;" id="google-toolbar-hilite-79">软件工厂</layer>中特定视点的属性。必须将这些信息需求进行优先顺序排列，以确保度量程序能够将重点集中到那些对已定义目标的潜在影响最大的需求。正如先前所述，我们的主要目标通常是确定哪些视点的改进将产生最大投资回报。由于各视点是互相嵌套的，因此我们通常可将度量值逐渐累积到更高级别的视点。例如，如果我们有一个“用户界面”视点，其中包含了“Web 部件开发”和“用户授权”之类的视点，则我们可以将客户满意度度量值从特定的 Web 部件累积到用户界面级别。
*

定义实体和特性

可度量特性也就是软件实体的可辨识属性。与信息需求（例如“评估软件产品规模以鉴定最初预算估计值”）相关的实体可能是一个开发计划或日程表，以及一组已建立基准线的源文件。其特性可能是每个期段计划完成的功能点、源代码行数和所用编程语言的语言表示表。
*

定义基本度量和派生度量

基本度量在作用上独立于其他所有度量并收集关于单个特性的信息。指定基本度量可采用的值范围和/或类型有助于检验所收集数据的质量。在本示例中，有两个基本度量：软件产品的估计规模和实际规模。这两个基本度量的数值范围是从零到无穷大。派生度量可收集多个特性的相关信息。图 7 举例说明了这些术语。

.
图 7. 软件规模增长量的基本和派生度量

单击查看大图像
*

指定指标

指标是度量分析和决策的基础。它们是呈现给用户的度量值。要正确使用指标，其用户必须了解指标所基于的度量与指标所展现趋势之间的关系。因此，度量构造应为每个指标提供以下信息：
o

用于分析信息的指南。对于本示例，我们所提供的分析指南可能是这样：“不断增长的软件规模增长比率表明达到成本和日程预算的风险越来越高。”
o

用于根据信息做出决策的指南。对于本示例，我们所提供的决策指南可能是这样：“查明软件规模增长比率变化量何时超出 20%”。
o

解释指标的图解。对于本示例，我们可能提供类似图 8 的图解并做出如下描述：“指标似乎表明项目生产率比原计划提前了。但经过进一步调查，结果是因为疏漏了直到初始测试时才明确的需求，某一项目的实际规模超出了计划规模。资源分配、日程安排、预算以及测试日程表和计划均受到了这个意外增长量的影响。”

.
图 8. 指标图形表示，软件计划增长量与实际增长量的对比
*

定义数据收集过程

既然我们知道了如何将基本度量与信息需求相关联，就必须要定义数据收集过程。数据收集过程指定了数据收集频率、负责人、将要收集数据的阶段或活动、确认和验证规则、用于数据收集的工具以及存放所收集数据的存储库。

使用度量构造

要成功使用度量构造，必须解决两个重要问题：影响指标和避免失效的度量。

影响指标

要成功使用指标进行度量分析、做出决策和更改流程，就必须确保其用户知道这些指标代表什么、如何解释指标以及可以变更哪些方面来影响其结果。对于本示例，用户必须了解，要使“功能点实际规模”达到“功能点计划规模”，我们必须在同样多的时间内生产出更多功能点（也就是说，我们必须提高生产力）。用户还必须了解如何提高生产力。

避免失效的度量

决策者还必须知道如何避免失效的度量。度量的目标是通过做出变更（如执行不同的活动、应用不同的资产等等）来改进绩效。重要的是要确保变更合情合理。您不希望人们为了在某些度量中取得预期结果而做出阻碍生产力的变更。在本示例中，要达到“功能点计划规模”的压力可能会很高，以使得人们开始用附加代码行来加长实现。确定并描述风险是实现成功度量的一个关键之处。最好的方法是避免逐一度量。对于任何定量社会指标来说，与其关联的权重越大，就越有可能歪曲和破坏该指标想要改进的流程。
返回页首
综合利用

最后，综合一下我们所学过的内容并就如何定义和使用度量构造以改进 Team System 支持的<layer style="background-color: Yellow; color: black;" id="google-toolbar-hilite-80">软件工厂</layer>加以探讨。
向数据仓库添加度量构造

如前文所述，每个度量构造至少都需要定义信息需求、实体和特性、基本度量和派生度量、指标以及数据收集过程。要将这映射到 Team System 数据仓库，我们必须确定如何获得所需信息，或者通过修改工作项目类型定义以添加字段并将其标记为事实或维度，或者通过构建自定义工具以及收集工具所生成数据的自定义数据仓库适配器。我们还必须确定如何显示指标，通常是通过创建 Microsoft SQL Server 2005 Reporting Services 自定义报告来实现。
迭代式改进

将工厂映射到 Team System 之后，就可以开始使用它构建解决方案。它将指导您的团队构建解决方案，并根据您定义和实现的度量构造为您提供信息。从这时起，您就可以开始分析度量值并使用指标来确定改进时机。利用该信息，您可以确定哪些视点可以改进、改进这些视点会得到多大收益，以及要进行多少投资来改进它们。最后，您可以执行已选择的改进，通常是通过添加指导和提供更好的资产来支持工作产品的创建。在利用这些改进构建解决方案时，可以再次使用度量值和指标来确定所实现收益与期望收益的对比情况，并相应调整投资计划。
返回页首
结论

目前我们构建软件采用的是“一次性”或一次一个项目式开发，这种极其低效的方式需要改变，本白皮书正是在这个愿望的促使下撰写而成。客户明白，我们一直在力争做到项目能按时交付、不超出预算，并且具备所有期望的功能。通过收集从经验中获得的知识和信息并使用<layer style="background-color: Yellow; color: black;" id="google-toolbar-hilite-81">软件工厂</layer>将其传递给其他项目，就可以全面拯救我们自己和我们的行业。我们了解了如何定义工厂以及如何在生产力和质量方面来度量工厂绩效。

通过量化所构建产品的规模、度量构建产品所耗费的时间以及记录所发现的缺陷数，我们可以描述工厂的绩效。从工厂架构到 Team System 的映射通过使用 Team System 中的自定义和可扩展性功能点完成。可以通过将工厂架构确定的资产放置在版本控制存储库或团队基础门户中来设置 Team System。可以使用该门户来为工厂架构描述的活动提供流程指导。可以使用项目创建向导来安排工厂的初始设置，还可以使用功能建模来创建映射以定义要添加到向导中的窗体。初始项目的很大一部分使用流程模板完成，也可以修改这些模板以支持我们的工厂。

通过定义度量构造并在 Team System 数据仓库中实现它们，我们可以收集在生产力和质量方面描述<layer style="background-color: Yellow; color: black;" id="google-toolbar-hilite-82">软件工厂</layer>绩效的量度。随着时间的推移，我们可以使用这些量度不断改进工厂，不仅可以提高生产力和质量，还可以通过剔除多余或不必要的可变性来提高可预见性。

利用 Visual Studio Team System 实现<layer style="background-color: Yellow; color: black;" id="google-toolbar-hilite-83">软件工厂</layer>的最终结果是，项目的成功程度和客户满意度都会有一个质的飞跃。