Data Vault方法论之项目评估FPA

项目评估

Data Vault 2.0方法论中的评估过程依赖于功能点分析(FPA)。 与其他评估技术相比，这种方法是推荐的，因为它基于将功能分解为单个项，这在Data Vault 2.0中相当容易（由于标准化的工件）。 通过使用FPA，团队成员通过计算单个项目的功能点和估计交付功能点所需的时间来评估数据仓库所需的功能。

功能点分析

成功的数据仓库项目需要对即将开展的项目的努力进行现实的规划。 为了进行现实的规划，需要一种准确的评估技术。 为了评估任何软件，如数据仓库，度量标准被用来度量过去已经执行和将来将要执行的工作单位。功能点是指标，并且是功能点分析中的关键元素，功能点分析是一种广泛用于软件评估的评估技术。

随着功能点的使用，FPA独立于技术相关的指标，例如代码行(LOC)或其他需要测量特定工具或平台的指标。代码行指标对高级语言不公平。例如，业务用户请求的相同功能可能需要C#中的100行代码，而C中需要500行代码。然而，功能点衡量已交付给最终用户或将在未来交付的功能。

图3.12显示了航空业软件系统的功能特点。

图 3.12 航空业软件系统的功能特点

软件的功能特性由外部输入(EI)，即进入系统的数据；外部输出(EO)和外部查询(EQ)，即以某种方式离开系统的数据；内部逻辑文件(ILF)，即在系统内制造和存储的数据；外部接口文件(EIF)，即在系统外保持但执行任务所必需的数据。功能点的评估还包括一般系统的复杂性。
在功能点分析中，为了更好地分析，系统被分解成更小的组件。下一节介绍了计数功能点并执行功能点分析的高级步骤。

用功能点测量

为了测量软件系统的大小，对其每个组件进行了分析，以了解上一节中概述的特性。
国际功能点用户组(IFPUG)是功能点分析背后的组织，建议执行测量的步骤如下：

第一步：确定功能点计数类型。由于新项目或现有项目的工作量是不同的，评估者必须选择以下三个选项之一：

• 开发项目功能点计数
• 增强项目功能点计数
• 应用功能点计数

第二步：识别计数边界。识别和定义要测量的组件的边界。这需要作出决定，哪些功能包括在计数中，哪些不包括在内。此外，还需要区分内部文件和外部文件以及组件的输入和输出。

第三步：识别和统计数据功能类型。 上一节介绍了两种数据功能类型：内部逻辑文件(ILF)和外部接口文件(EIF)。这些功能表示用户功能以满足内部和外部数据需求。

第四步：识别并统计事务性功能类型。事务功能类型表示系统的功能，以满足用户对数据处理的要求。包括外部输入(EI)，外部输出(EO)和外部查询(EQ)。

第五步：确定未调整功能点计数。步骤3和步骤4中的功能类型数根据复杂度进行调整。

第六步：确定价值调整因子。价值调整因子(VAF)通过评估系统的一般功能，向用户表示一般系统的总体价值。构成因素的一般系统特征有14个。

第七步：计算最终调整后的功能点计数。这是使用以下公式之一完成的，这取决于步骤1中选择的函数点计数类型。

所描述的一系列步骤对所有软件开发工作都是有效的，包括数据仓库项目。 下一节将介绍如何在此类项目中应用此程序。

数据仓库的功能点分析

为了将功能点分析应用于数据仓库，评估器必须应对这些类型项目特有的一些挑战：

1.数据仓库项目往往依赖各种技术和工具来处理业务问题。每个工具都有优点和局限性，在评估工作时必须考虑这些优点和局限性。

2.后端进程，例如用于加载数据仓库层的ETL，通常有许多相互关联的进程，这些进程需要收集所需的信息。结果是增加了复杂性，使评估变得复杂。

3.前端主要由OLAP立方体、报表、仪表板和其他图形用户界面组成，它有自己的一些方面，在评估工作量时必须加以考虑。示例包括接口的性能、可理解性等。

4.当新功能被添加到系统中时，项目团队必须通过破坏或引入错误来确保现有功能不会受到负面影响。因此，必须考虑对数据仓库进行回归测试的工作量。

5.由于数据仓库可以每天加载大量数据，因此在评估过程中必须考虑对新需求进行加载测试的工作量。

即使不是不可能的，这些挑战也使得先前描述的步骤（在常见的软件工程中广泛使用）成为一项艰巨的任务。这是由于软件的过程导向相对于面向主题的数据仓库视图来说是很不一样的。因此，必须调整这一步骤，以便适用于数据仓库。

数据仓库的边界

适应的第一个转换是定义数据仓库中“组件”的边界。由于该领域的分层方法，每个功能都必须在系统的各个层中实现。组件由所有这些更改组成（图3.13）。

图 3.13数据仓库应用边界

图3.11显示了每个功能由集结区表、核心数据仓库中的对象和数据集市组成。这包括在ETL中实现的所有逻辑，例如业务规则。还包括图形元素，如OLAP立方体中的报告、尺寸和指标以及仪表板上的项目。

图3.11 数据仓库的报告界定

评估规模

第二个转换是定义用于数据仓库项目中评估的功能类型。由于数据仓库架构通常遵循类似于第二章描述的架构的某种形式，因此在评估过程中使用了表3.2所示的映射表。
表3.2 将数据仓库组件映射到功能点类型

DWH组件	功能点类型
集结区表	外部接口文件(EIF)
目标表	内部逻辑文件(ILF)
事实表	内部逻辑文件(ILF)
维度表	内部逻辑文件(ILF)
查找表	内部逻辑文件(ILF)
映射	外部输入(EI)
流程警报	外部输出(EO)

集结区表实际上在数据仓库功能的边界内，被视为外部接口文件（而不是内部逻辑文件)的原因是，它们主要将外部数据作为直接副本保存(丰富了一些简单的元数据）。然而，如果将内部处理应用于这些表，则它们被视为的内部逻辑文件。

出于同样的原因，目标表被认为是内部逻辑文件，而不是外部边界：它们是在数据仓库功能的边界内处理的数据更新的。

数据仓库中的映射通过从源表中提取数据、转换数据并将其加载到目标表来实现所需的逻辑。 它们被认为是外部输入(EI)，因为它们通过实现业务规则来改变系统的行为。

数据仓库映射通常会广泛使用查找表，该表将代码与描述性更强的数据映射在一起。例如，代理键映射到业务键，以支持最终用户的可理解性。因为它们提供了这样的数据，所以这些表对业务用户来说比提供技术优势更有价值。因此，它们被认为是内部逻辑文件(ILF)。

流程警报通知外部实体ETL进程状态，并被视为外部输出(EO)。

评估ETL复杂性因素

第三个转换是确定对ETL过程复杂性有影响的因素。典型的复杂性因素如图3.14所示。

图 3.14 ETL复杂性因素的原因和效果图

图中显示了复杂性因素对典型ETL项目的原因和影响。然而，并非所有这些因素都与实际效果相关。他们依赖于组织和项目团队。为了找出有影响的因素，需要进行相关分析，例如使用逐步正向回归分析。

特定数据仓库项目回归分析的样本方程可能类似于方程3.1中提出的方程：
用于回归分析的样本方程：
实际工作量 = A + B(X5) – C(X9) + D(X15) – E(X16) + F(X19) + G(X2X4) + H (X3X4)

其中X5：目标栏数，X9：转型类型，X15：要修改或创建的参数文件，X16：新的制图，X19：未调整的功能点，X2X4：转换次数（相互关联的因素），X3X4：转换次数（相互关联的因素）

项目回归分析的实际方程也将包含回归系数，这些系数被描述为方程3.1中的字符A到H。

将功能点分析应用于数据仓库

评估过程的总体目标是使工作更加可预测，从而使业务信息系统开发标准化：由于开发团队使用系统方法估计所需的功能，因此一旦功能交付后，可以将估计值与实际值进行比较。 当两个值相互比较时，团队成员可以从以前的估计中学习并改进他们未来的估计。

当业务要求提供所要的功能的评估时间范围或工作量时，评估过程应该为IT团队提供支持。 提供深层次的答案的能力是CMMI的核心要求，以实现高于初始（0级）或已执行（1级）的能力等级。例如，FPA可以应用于能力2级（已管理），以便量化需求管理中的功能需求的大小，评估项目管理中的努力和成本，向管理层报告功能点数据等。

为了使用FPA执行评估过程，需要对过去的数据仓库开发工作保持准确的度量，以便能够将评估过程中的经验用于未来的评估。这些信息用于调整组织的工作量等级。人小时取决于功能的复杂性。应该清楚的是，困难的功能要比简单的功能（按计算的功能点计算)更长时间才能实现）。表3.3显示了一个在一个特定项目中有效的示例。

表3.3 每个功能点的复杂性与人小时数关系

复杂性因素	每个功能点的人小时数
很简单	0.1
适度	0.2
很难	0.7

请注意，表3.3必须调整到每个项目的估计，这些值也随着时间的推移而变化，因为开发人员越来越有经验，或者由于营业额，在团队中失去经验。正如我们在前面的讨论中所看到的，功能点的数量取决于要构建的软件的功能特性。为了在DataVault2.0方法论中使用FPA，必须调整软件的功能特性（外部输入、外部输出、外部查询、内部逻辑文件和外部接口文件），以映射到Data Vault项目。

定义了使用Data Vault构建的数据仓库的以下功能特征：

• 集结区加载
• 中心表加载
• 链接表加载
• 卫星表加载
• 维度表加荷
• 事实表加荷
• 报告生成

同样，也可以定义其他功能特性，例如。用于时间点(PIT)表、桥接表、业务仓库实体或OLAP立方体。一般来说，Data Vault2.0加载过程是EtL模式(用于转换的小写“t”)：加载原始Data Vault所需的原始数据只有最小的转换。因此，这些转换的功能点应该是低的，功能特性可以指导高级别的优化、评估低级别的复杂性和简单的功能点计数。

参考表3.4所示的每个项目的功能点列表，用于计算工作量等级。

表3.4 功能点和工作量等级

项目构建输出	复杂因素构建输出	估计功能点构建输出	估计总小时构建输出
集结区加载	很简单	2	0.2
中心表加载	很简单	2	0.2
链接表加载	很简单	3	0.3
薄卫星表加载	很简单	3	0.3
宽卫星表加载	适度	4	0.8
维度表加载	很难	4	2.8
事实表加载	适度	4	0.8
报告生成	很难	5	3.5

单元测试项	单元测试复杂性	单元测试功能点估计	单元测试总小时估计
集结区加载	很简单	1	0.1
中心表加载	很简单	1	0.1
链接表加载	很简单	1	0.1
卫星表加载	很简单	2	0.2
维度表加载	适度	2	0.4
事实表加载	很简单	2	0.2
报告生成	适度	4	0.4

示例表明，每种类型的功能都必须独立于其他类型进行估计。第一列表示功能的类型。第二列表示项目的复杂性因子。显示的值是典型的。然而，也有可能有简单和中等类型的卫星表（有些卫星表具有较低的属性，这使得加载过程比平均值容易得多）。由于这个原因，对复杂程度不同的卫星表增加了多行。估计的功能点表示为项目类型计算的功能点数。估计总小时列是表3.4中估计功能点列和表3.3中每个功能点的人员小时的乘积。

请注意，薄卫星表和宽卫星表之间有区别。这种区分是指列数而不是表的物理宽度，这取决于列数和每列的宽度(以字节为单位）。一般来说，卫星表拥有的列越多，需要的加载逻辑就越复杂，可能会出现更多的拼写错误，将错误的字段加载到错误的目标或错过列比较的机会就越多。这就是为什么这个表区分这些加载。

同样，表3.4第二部分中的单元测试也应用了同样的概念。对于每个项目和测试的复杂性，功能点将根据预计的总人小时进行估算和增强，这再次基于表3.3。

因此，表的第二部分与第一部分非常相似。然而，它根据实现和测试之间的不同努力进行调整。 请记住，此表必须为每个项目单独构建并随时间更新。可能需要对较不复杂或较复杂的工作项目（如表3.4中的例子中的卫星表加载)进行额外的区分。

为了启动这一进程，必须遵循前面概述的一般程序，提出与正在构建的项目背后的实际工作量有关的功能点估计，并跟踪这些功能点背后实现和测试所需的人员时间。因此，跟踪每个功能点的小时成为您开发工作的第一个周期中的一个重要步骤，然后才能实际估计未来的工作量。这是由于在特定情况下，估计数是从过去的经验中得出的。不可能（如果没有复杂的转变)利用来自一个背景(例如，一个组织)的经验来估计另一个背景下的努力，因为各组织之间存在许多差异-例如成熟程度、开发人员和管理人员的经验水平以及内部和外部工作人员(他们给公司带来了专业经验)之间的比率。

企业数据仓库的功能点

虽然每个功能点的估计小时可以直接从过去的项目或冲刺中提取，但每个项目的功能点必须有不同的决定（但这可以在整个组织范围内进行，并且需要较少的维护）。有一些一般的规则来决定多少功能点应该与各种项目相关联：

• 集结区表：功能点的数量取决于所需的归一化量。
  考虑逗号分隔值(CSV)平面文件的情况，这些文件不需要规范化（用于暂存），因为所有列都可以直接添加到集结区中。将其与XML或COBOL文件进行比较，由于存在子结构的原因，XML或COBOL文件不像CSV文件那样容易加载到关系表中。为了加载此类数据，需要一些规范化工作才能将数据从其结构化格式转换为一组关系表。当将数据加载到分层表(例如XML数据类型)时，可以避免这种规范化工作，但需要接受（严重的）性能的下降。

• 集结区和Data Vault加载：根据加载集结区表或Data Vault实体（如中心表、链接表、卫星表等）所需的ETL复杂性，功能点数都是不同。中心表的功能点一般相同，无论业务键的大小或组成如何。在所有其他情况下，这是不正确的：连接到链接表的中心表越多，关联的功能点就越多，这是因为ETL数据流会复杂一点。（但同样，连接两个中心表的所有链接表应该具有相同的功能点关联)。此外，卫星表属性的数量、卫星表超载和分裂也产生了影响。但是，针对此功能特性，请关注映射本身的复杂性。一般来说：中心表是最容易加载，链接表适中，卫星表通常是中等到难以加载。

• 信息集市加载：对于这些功能特性，业务规则的数量和复杂性以及在ETL加载中实现的附加列的数量是关键因素。如果您在ETL中实现业务规则，或者实际上在SQL视图中实现业务规则，这也是一个不同之处。此外，对于事实表、维度表、OLAP立方体、关系报告等，应该有不同的功能点。

• 业务仓库加载：它们类似于信息集市，因为它们还实现业务规则。

这些一般规则应该为开发团队在决定与单个功能特性相关的功能点时提供指导。请注意，当自动化Data Vault加载过程时，用于开发和维护的估计人小时会大大减少，这一概念超出了本文的范围。

当组织通过CMMI成熟度等级前进时，他们会认识到基于功能点的评估随着时间的推移变得更容易。这是由于一致和可重复的业务流程更容易预测，因为过去的经验可以实际应用于这些流程。如果没有这种一致的执行，评估数就没有很好的依据，因为流程执行的情况一直在变化。

定义良好的标准有助于组织实现这种一致和可重复的业务流程。功能点分析（FPA）还有助于推动可测量和可优化的组件，这些组件是执行评估所需的。这一目标得到了必须交付业务的各个组件的分离的支持。如果没有这种分离，评估数将重叠功能，从而使评估数不那么准确。 识别组件还可以减少对交付的内容和时间的混淆。 因为每个组件都必须被识别和描述，所以也可以安排每个组件的交付。

评估过程的总体目标是使数据仓库的开发工作更加可预测。它有助于证明数据仓库项目的成本是合理的，并确保企业提供进一步的资金。由于正确的评估建立了对开发团队和业务的信任，因此它们是Data Vault 2.0方法论的核心部分。

一旦团队决定了在即将到来的sprint冲刺中要交付什么和多少，重点就会转移到项目执行上，这将在后续文章中讨论。