文章《将软件开发生命周期应用于Data Vault 2.0方法论》介绍了一个称为技术编号的概念,该概念在项目文档中用于识别单个工件。
技术编号是将基于小数点的数字分配给描述工件和其他重要信息的文本文档和段落。又称科学编号。目标是在项目中唯一地识别文档和已实现解决方案中的每个工件。它应该应用于每个项目或sprint中产生或使用的每个文档或工件。
工件的例子有:
- 角色和职责文件中的一个单一角色
- 需求变更文档中的一个变更需求
- 需求文档中的单个需求
- 项目计划中的一项任务
- 业务术语表中的一个业务对象
- 缩写词汇表中的一个缩写
当为这些工件分配技术编号时,使用分层和增量方法。编号被递增地分配给每个工件,同时也反映了层次结构。表3.6显示了这种方法,将点分隔的数字分配给每个任务。每个子任务被分配一个以父任务的WBS号为前缀的数字,由一个点与子任务的递增数分隔。
表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 |
如果在文档处理软件(如MicrosoftWord)中应用技术编号,则手动分配数字并避免使用标题的自动编号是一个很好的做法,因为当一个标题插入到其他两个标题之间或它们被重新排列时,这些自动编号被重新分配。重要的是,一旦技术数字被分配到工件上,就必须避免更改它们。为了支持应用程序之间的交叉引用,不应该重新编号这些工件。在不同的应用程序中,这些工件被其技术编号交叉引用:
- 对源表的需求:这可能是最强大的交叉引用映射,因为它标识了源表和特定需求使用的属性。每个需求应该有一行来确定所有需求的来源。这是3.2.2中提到的数据分解结构之一。
- Data Vault表的源表:此映射是在创建加载Data Vault表的ETL作业之前创建的,并指示源表和 Data Vault目标。
- Data Vault表到信息集市表:与以前的映射类似,本文档显示了如何将数据从 Data Vault表映射到信息集市。此文档应该是一个简单的矩阵,而不需要指示业务规则。它们应该记录在需求文档中。
- 对信息集市表的要求:此矩阵类似于第一个映射,并指示指定需求使用的信息集市表。同样,每个需求应该有一行。这是3.2.2中提到的第二个数据分解结构。
最好的方法是在建模工具中提供这些映射作为交叉引用矩阵表,或者(如果没有更好的选项)在电子表格程序中提供,例如Microsoft Excel。表3.7举例说明了数据分解结构的外观。
表3.7显示了对目标映射的需求,也称为对信息集市表的需求,它描述了给定报告或OLAP项目使用哪些信息集市维度或事实表。在这个例子中有三个报告:乘客,飞机利用情况和联系信息。乘客报告只使用信息集市中的乘客信息表,而联系信息报告使用联系信息和飞机表。 这些实体名称是逻辑名称;物理名称也作为参考提供。此外,此表引用了需求文档,其中更详细地定义了报告(例如,如果团队决定将需求拆分,项目中可能有多个需求文档、多个功能等)
使用缩略词作为技术编号的前缀是一种很好的做法,以提供正在编号的工件类型的简单指示器。表3.8只列出了此类缩略语的例子。通常,组织已经有一套缩略语,应该加以利用。
识别单个文档和工件的能力是测量它们的先决条件。没有适当的识别,这是不可能的,因为实际的工作量不能正确地与它们联系在一起。如果没有衡量实际工作量的能力,就不可能将其与计划的工作量进行比较,反过来也不可能优化开发过程。这种开发过程的优化是在sprint的评审和改进阶段进行的。