当然，在软件项目实际操作的时候，可能还会遇到另外一个问题，很可能用户会乱用这个数据信任程度的概念，我个人的建议是在项目实施中如果可能的话，优先进入信任等级高的数据，然后才是信任程度低的数据；当然也可以从人员来角度作为切入点，信任等级越低的数据，进入系统需要的业务更熟悉的人员来操作录入，而且经过的业务处理步骤越多。一句话，数据信任程度越低，应该受到的审查/检察越多。

参考：数据信任等级图

6.数据来源管理

在现实中稍微规模大一点的软件系统涉及到的组织机构都是比较大的，有很多还可能是松散的组织管理模式。在这类组织机构中，同样的业务数据可能很多部门都会是数据录入点和数据分析点，为此可以从数据采集/来源角度来描述数据本身。

从当前项目利益来说，数据来源管理方便数据查询分类，长期来说可以建立起数据信任等级。

对于数据来源的识别，一般需要有特定信息来记录数据的来源，特别是一些大型企业当然分支机构较多的公司企业政府，也应该这样来管理。
事实上，数据来源管理是数据信任管理的进一步延伸，是数据信任管理的前置条件。一个数据，可以是来自于A部门的也可能是来自于B部门的。为了方便统计查询和数据信任管理的加强，应该记录下数据的来源地。

具体操方式可以有以下几种：

1) 数据录入人员的工作人员编号，知道了数据录入人员的编号，知道数据的来源地。

当然，实际工作种存在人员调动，替操作（1个人用另外一个人的身份进入系统数录入），这些都有可能需要考虑到，否则可能造成数据来源管理失效。

2)另外一种方式是直接记录数据录入的部门编号。

这种方式弊端是不能记录下数据的具体操作人员。

其它说明：如果系统中引入了工作流产品，数据来源这部分工作可以由工作流来担任。具体例子：在现实的软件系统中可能存在一个主数据库/数据中心，若干分数据库/数据中心，系统在每过一定时间进行数据上传/下载，为了进行数据合并和控制数据的修改，应该每个分数据中心只能处理修改自己的数据，可以查询总数据中心/其他分数据中心的数据。如果没有引入数据来源管理（数据属地管理）和数据版本的控制机制，不知道系统在作数据中心合并会怎样子？

7.数据项的分类编码

数据项的分类编码，实际上是数据项来源管理的一个具体延伸。数据项编码的目的是更快更好的识别数据代表的业务意思。一个典型的例子是ERP中的BOM表（基本物料清单）.

数据项的分类编码，不只是在系统模型建立上有指导意义，在进入系统的业务数据的规范化同样有指导意义。

数据项的业务编码和系统编码分离。业务编码很多时候只是为了识别业务数据的需要，很难保证业务数据的性要求。而且业务编码可能会发生变动，有些单位的总体规划从调研到讨论制订、到项目审批通过，再到终实施，常常几年过去了，需求发生变化，这种编码规则不发生变动几乎不可能。2000年我参与的一个企业软件系统，一个产品编码规则2个月发生了5次变动。从更长的时间范围内来说，应该考虑数据产生时期问题，不同时间阶段产生的业务数据，使用的业务规则不一样，数据编码这个层次很多时候很难识别数据当时的业务环境。

以一个简单的例子来说明：

业务数据表的primary key系统应该是系统定义的，而数据项的业务编码只能作为索引或者备用键使用，这样减少了数据业务编码规则的变动对系统影响减少到更小的程度。

8.算法的版本化

本来我打算在前面的基础上，再谈一下业务流程的管理设置问题，不过，现在工作流思想深入人心，我也跳过了。我打算从数据的核心业务处理，算法处理角度来阐述。

其实在现实中的软件项目中，大家提到的较多的BPR，工作流这些东西，但是很少提到算法这个单词。当然，不可否认，很多软件项目，特别是电子政务/OA的业务主要是体现在流程/文件上，算法这部分比较简单（当然，我这样说，有人可能不认可，暂且不争论它了），没有必要去强调算法的重要性了。

为了避免垃圾数据进入系统，垃圾数据出来，有必要对数据进行分类管理。正如前面提到的那样，对于进入系统的数据，进行信任等级划分，数据来源的分类；但是对于系统出口，为了避免出现垃圾数据，需要在数据处理阶段，也要进行分类处理，这里引入了算法的版本化，来适应不同的数据/业务需要。