将软件开发生命周期应用于Data Vault 2.0方法论

软件开发生命周期作为一个小瀑布应用于Data Vault 2.0方法的冲刺中。
为了执行这个小型瀑布，使用了一个项目计划。
表3.6显示了一个执行新报告的示例。
表3.6敏捷项目计划

ID	WBS	任务名称	期限	前置任务ID
1	3	敏捷交付的单一需求	58小时
2	3.1	选择报告生产（范围）	0.5小时
3	3.2	估计工作努力	0.5小时	2
4	3.3	填写风险评估	0.5小时	3
5	3.4	确定报告的来源/数据表	4小时	4
6	3.4.1	源到需求矩阵	4小时
7	3.5	设计ER数据Vault模型	2小时	3
8	3.6	将属性添加到ER数据漏洞模型中	6小时	7
9	3.7	创建ETL Data Vault工作流	4小时	8
10	3.7.1	创建中心组件工作流	1小时
11	3.7.2	创建链接组件工作流	1小时
12	3.7.3	创建卫星组件工作流	2小时
13	3.8	设计报表的数据集市模型	4小时	3
14	3.9	创建ETL数据Vault到信息集市	16小时	13
15	3.9.1	构建维度工作流	8小时
16	3.9.2	构建事实工作流	8小时	15
17	3.10	建立报告和生产输出	8小时	13
18	3.11	为项目文档创建源到目标报告	2小时	5;8;13
19	3.12	单元测试	4小时	17
20	3.13	记录实际工作	0.5小时
21	3.14	签字	1小时	20
22	3.15	部署到测试环境	2小时
23	3.16	运行用户验收测试	2小时
24	3.17	部署到生产部	1小时	22;23

ID标识项目管理工具中的任务，如Microsoft Project。它主要在内部使用，例如在“前置任务ID”列中，该列提供有关单个任务之间依赖关系的信息。WBS列用于向任务添加项目范围的引用字符串。下一节讨论如何使用此标识符。列任务名称提供了用户可读的名称和持续时间，这是完成任务所需的估计时间。

此外对于持续时间，许多项目添加了一个工作列，用于估计工作工作量。这是必需的，因为当一个以上的全职员工可以在一项任务上工作时，所需的工作与持续时间之间存在差异。 这可以用于功能点分析的估计（参见第3.1.4节）。大多数项目管理工具，包括Microsoft Project，都支持一个可选的Notes列，没有显示在表3.6中，它可以用来包含对附加依赖项的引用（使用它们的技术编号），以便识别工件的其余部分。这个概念等于WBS列中的项目范围参考字符串，并在下一节中描述。

请注意，表3.6中的项目计划显示了为两周冲刺计算的持续时间，总共58小时。此示例还假定自动化工具用于创建ETL Data Vault工作流（项目3.7）。如果不是这样，建议添加中心组件、链接组件和卫星组件工作流的详细任务（在项目3.7.1、3.7.2和3.7.3之下）。如果冲刺的时间长短不同（要么是三周，要么是每周工作时间不同），则可以相应地重新计算持续时间。如果您不使用自动化工具，可能需要重新计算sprint长度，因为没有自动化将很难实现两周的sprint。请注意，一些任务持续时间应该保持表3.6中描述的时间，因为持续时间是静态的（签收过程就是这样的例子）。 在将此表转换为为期三周的冲刺时，增加50%的持续时间是没有意义的。无论如何，需要根据项目的需要调整工期。虽然范围界定(任务ID2至4)对项目的成功至关重要，但应该注意的是，任务不应超过两个小时。

针对sprint的项目计划有一些变化，这些变化集中在实现以外的其他活动上，例如需求收集、用户接受测试或基础设施设置。

项目计划还表明，在项目过程中产生了某些可交付成果。这不仅限于数据库模型或ETL数据流。Data Vault 2.0方法的一个重点是生成对业务和IT都有价值的文档。
必要文件包括：

• 业务术语表：本文档有助于构建信息集市，因为与它们相关的业务对象和术语被识别和记录。
• 需求文档：本文档详细描述了信息集市和报告。数据仓库解决方案中不应有任何功能，在本文档中没有相应的需求记录。该文档应该保持相当短的篇幅，例如，每个需求使用一页左右的用户故事。
• 项目计划：项目计划只关注在一个冲刺期间需要执行的任务。
• 缩略语术语表：本文件提供了业务或数据仓库技术领域的通用缩略语。
• 范围或工作说明文件：本文件描述了冲刺的范围，并反映了商定的内容。它是冲刺结束时签收程序的重要来源。
• 更改需求文档：对于已经实现的需求的每个需求更改都需要一个基于更改需求文档的文档化过程。
• 交付和签收文档：当项目团队在sprint结束时交付新功能时，它需要业务的签收，然后才能推出。本文件指出，交付满足或超过了需求文档或更改需求文档中概述的期望。
• 角色和职责：本文件确定了项目团队中的角色和与它们相关的责任。
• 工作分解结构：将整体交付（数据仓库解决方案）分解为可管理的组件。
• 流程分解结构：数据仓库支持的每个业务流程都应该使用业务流程图进行描述。它应该被建模到一个可以识别数据集及其业务键的详细级别。
• 数据分解结构：对于每个（范围）业务报告，有两个表：一个将报告映射到源表，另一个将报告映射到用于信息集市输出的Data Vault源。
• 组织分解结构：该结构显示组织关系，可用于为项目分配资源。它与工作分解结构一起创建。它还将单个团队成员链接到角色和职责文档中定义的角色。
• 数据模型标准：数据模型标准文档为数据错误实体、事实和维度以及这些实体的属性提供命名约定。它提供关于商定标准的信息，以建模特定实体、系统属性等。
• ETL标准：本文档描述如何控制或实现数据工作流，例如命名约定、文档要求和物理设计问题等。

上面的列表显示，其中一些文档相互引用。为了维护这一过程，建议使用项目范围的技术编号（第1.2.4节中描述的概念）来识别文档和已实现解决方案中的每个工件。否则，不可能在项目中唯一地交叉引用这些工件。图3.17显示了组织分解结构示例。

图3.17 组织分解结构示例

在这个结构中，每个角色都与图中给出名称的团队成员相关联。项目管理标准，如项目管理专业人员(PMP)，要求项目计划跟踪角色，而不是个人，因为个人只能在项目中发挥部分作用，但每个角色必须填补到100%的努力。否则无法满足项目进度。CMMI也是如此。此外，每个角色都通过使用技术编号来识别。请注意，如果有两个ETL开发人员，两者都将有相同的技术编号，因为技术编号是对前面列表中描述的角色和责任文档的交叉引用。个人扮演多个角色并不罕见。我们甚至可以看到个人填补了四个以上的角色！