软件项目实施总结
一．空洞的总结
上个星期帮一个朋友看了一个项目实施方案，让我提出一下建议，我刚开始不是很感冒，后来觉得应该给人家意见把，才冒出来系统去整理一下项目实施的东西。先简单回忆一下项目实施的一些东西，然后整理一点东西出来。
1. 项目组组建
1.1多方项目组成员
给出多方项目组成员组成。很多吃过亏的客户，在搭建项目组的时候，甚至在招标书的时候，要求软件公司的项目组里面必须有项目管理专业人员，甚至持有pmp证书，或者有专业的需求分析人员，并持有系统分析证书。
1.2 多方项目小组成员的稳定性
多方项目小组成员的稳定性。人员流动通知对方，申请多方认可。特别是相关负
责人流动，需要多方确认。
2. 实施的进度日程表
给出系统上线日程表
3. 软件模块实施的先后顺序
先上哪些模块，后上哪些模块。新系统和老系统并行运行的机制处理方式。历史数据的处理方式。
4.进入新系统的数据截断日期。
5.实施中多方会晤机制
定期会晤机制？1周几次？还是每几天1次，每天1次？
6.监理方的立场说明
监理方代表的是甲方的利益，出现冲突的时候应该从维护甲方利益出发，考虑问题。
7. 问题诊断机制
实施出现问题时候，监理方应该要协助甲方诊断问题的类别，是来自于硬件提供商，
还是软件提供商，还是甲方的问题。如果不能诊断，应该主持召开多方会议确认问题的来源，类别。
8.问题的响应速度要求
当问题被诊断后，应该要求问题解决的时间，要求相关单位在规定时间内解决。如果问题不能在指定时间内解决，应该要考虑补救措施。
9.需求变更处理
当甲方提出需求变更后，监理方应该作出判断，这个需求是否合理，是否超出了实施前制定的需求基线，如果超出了需求基线，就有可能需要追加预算了。
当然软件需求变更存在一个工作量的问题，如果工作量较小，就不存在甲方追加预算。一般的项目实施都是有1个需求基线，然后免费的需求变更工作量有1个上限，当需求变更的工作量超出这个上限，就需要甲方追加成本了。
10. 甲方2次开发的难度控制
当在设计甲方业务处理流程的时候，应该要考虑到甲方业务流程 更改后，系统的
可配置性。这1点也是j2ee的主要特点体现。当然，如果系统使用了工作流产品的话，可以从工作流角度来考虑解决。
11. 财务核算处理方式的灵活能力
一般的企业单位，财务核算的方式是比较固定的，但是也会作变动，当这一块作出变动时候，应该要求软件系统能够比较好的能够实现。
例如：软件系统以前实行的是集中财务管理，后来改变成为半集中方式，或者分散方式。这写都要秋软件系统能够很好的实现能够很好的进行业务处理方式的平滑过渡。
12.甲方业务流程的整理
监理方作为甲方利益代表，应该和甲方一起协助亿方指定出甲方的业务相关流程，在甲方乙方有争论的地方进行协调，并且在流程指定时候应该就要考虑到流程的更改。监理方当然最好能够先帮助甲方进行流程改那就更好了。或者乙方能够提供工作流工具就好了，否则这部分工作会暂用监理方相当多的时间。另外需求搜集变更也会监理方需要高度关注的一件事情。
软件项目实施总结2---项目实施中的数据管理
软件项目实施总结2---项目实施中的数据管理
管理信息系统实施成功三大因素依次为：人、数据、技术，也许有些人不完全认同，但是数据的重要性是大家不可否认的。
1. 数据管理的组织机构的建立
为了更好的进行软件系统的数据管理，应该从组织机构角度来做考虑，建立单独的组织机构来管理数据相关工作，或者在实施小组里面专人总负责 。
软件开发商和客户核心的业务骨干一起制定数据规范，客户提供符合规范的业务数
据，只有符合规范的数据才能进入系统。
2. 数据管理的原则
强调客户和软件开发商的2方项目组成员做到“不能有‘我以为’的思想”，一旦有如此思想，很容易陷入闭门造车，项目需求很容易走样，因为客户à所有的客户，也是在‘我以为’。项目组要想做到控制住需求，一定要抛开自己的设想。所以任何一个项目组成员，第一句话就告诉他，不要有“我以为”的想法。把’我以为’变成’客户认为’(最好是客户和软件提供商一致认为)，这才是最重要的。
呵呵，这又回到了项目管理上。我在这里实际上只是想从数据管理这个更具体的角度来阐述问题。
3. 数据入口的单一性
同一数据必须一次、一处进入系统，保证其准确性，及时性和完整性和入口的单一性。
管理控制一体化是系统的目的，如果一个数据在多个地方存储，很容易造成数据的不一致。
4. 数据副本管理/数据版本管理
虽然上面提到了数据存储的单一性，但是有些时候也需要存储副本数据。存储这些
副本数据的目的就是为了在使用数据副本的地方不受到数据源的变化的影响。
例如：数据1在业务A进入系统，业务B使用到了数据1，但是为了避免在业务B使用了数据1后，业务A又把数据1的修改影响到业务B，那就需要业务B在使用数据1时候保存副本。
比如：城市拆迁资源计划系统( http://www.netsky-tech.com/)的拆迁合同在使用房源业务录入的房源房屋面积信息时,就使用了副本机制，在合同使用房屋面积时候，把面积信息存储下来，当合同构筑完成时候，如果相应的房屋面积信息发生了变动，就用另外的业务来处理这个数据变动的相应处理（比如，使用房源的差价款合同来处理）。
有朋友建议用配置管理系统，把数据版本机制引入了业务数据里面.做过J2EE的项目，
都知道很多地方可以通过配置来进行管理。其实这个思想延伸到数据库模型的设计时候，就体现出来了业务数据的配置管理的思想的使用。
我们其实也有是用这个思想，但是主要体现在 在基于数据表级别上 用数据级别+历史
编号 来识别有效的数据。1个很简单的例子：
一个员工的姓名原来 是aa, 后来改委bb，可以通过 历史编号 找到原来 的信息是bb
通过数据级别识别现在的有效数据是aa，我们把数据版本控制更多的是采用’数据级别’加’历史编号’另外还加上了一个’生效日期’, ‘截止日期’这2个时间戳.
另外，实际软件系统的历史业务数据进入系统就比较烦，可能需要使用版本管理机制来处理才行得通。
5.建立数据等级制度
软件项目实施中业务规则经常会陷入一个两难的境地，如果业务规则加强，很多数据数据达不到规范化的要求，无法入机；如果放宽控制，很多垃圾数据就进入了，大家都明白一个道理，对于软件系统，垃圾数据进去，肯定是垃圾数据出来，统计查询结果肯定是这样的。
可以建立数据的等级制度，制定数据进入系统的最低要求。达到最低要求才能进入系统，
比如：
业务A,需要数据a1,数据a2,,数据a3, 数据4。我们可以制定进入系统的关于业务A的条件是必须要有数据a1,a2才可以进入系统（也就是最低要求），如果提供的业务数据同时有数据a1,数据a2, ,数据a3,那就是更高一级的数据（第二级数据），如果业务数据在满足第二级数据的基础上，提供了数据4，那就是第三级数据。
如果用过J2EE平台的同行理解起来就比较容易，这实际上就是JMS基于主题的消息管理思想用于软件系统一个具体例子而已，这里不过是强调的是用于管理数据的信任等级而已。
其实很多软件项目开始制定的的数据规范，一般到后来都执行不下去，主要是太理想化了，也许只有到系统真正用起来了，系统数据的信任等级才能上去。所以我觉得应该在系统开始时候就把数据分等级，不同的等级，业务给与适当不同的处理，这样也便于后期的业务进行查询统计分析或者数据挖掘。
这种思想实际上就是将数据可以信任的程度进行分类；而一般的软件系统是把数据定义为两类，可以进入系统，不可以进入系统；我在这里设想的是，从数据可以信任的角度出发，分成多种类别，使用了一个小数来描述信任程度，而不是一个二值逻辑变量来描述；这样从建立软件系统整体模型的时候，把数据信任管理纳入考虑之内，在进一步作业务分析，决策支持或者数据挖掘时候是比较有好处的；当然进一步延伸可能就需要从OLTP/OLAP混合建模来考虑，不过真要到那个高度，可能项目范围就扩大了很多，具体怎样操作，还要看项目具体情形。
当然，在软件项目实际操作的时候，可能还会遇到另外一个问题，很可能用户会乱用这个数据信任程度的概念，我个人的建议是在项目实施中如果可能的话，优先进入信任等级高的数据，然后才是信任程度低的数据；当然也可以从人员来角度作为切入点，信任等级越低的数据，进入系统就需要的业务更熟悉的人员来操作录入，而且经过的业务处理步骤就越多。一句话，数据信任程度越低，就应该受到的审查/检察越多。
参考：数据信任等级图
6.数据来源管理
在现实中稍微规模大一点的软件系统涉及到的组织机构都是比较大的，有很多还可能是松散的组织管理模式。在这类组织机构中，同样的业务数据可能很多部门都会是数据录入点和数据分析点，为此可以从数据采集/来源角度来描述数据本身。
从当前项目利益来说，数据来源管理方便数据查询分类，长期来说可以建立起数据信任等级。
对于数据来源的识别，一般需要有特定信息来记录数据的来源，特别是一些大型企业当然分支机构较多的公司企业政府，也应该这样来管理。
事实上，数据来源管理是数据信任管理的进一步延伸，是数据信任管理的前置条件。一个数据，可以是来自于A部门的也可能是来自于B部门的。为了方便统计查询和数据信任管理的加强，应该记录下数据的来源地。
具体操方式可以有以下几种：
1) 数据录入人员的工作人员编号，知道了数据录入人员的编号，就知道数据的来源地。
当然，实际工作种存在人员调动，替操作（1个人用另外一个人的身份进入系统数录入），
这些都有可能需要考虑到，否则可能造成数据来源管理失效。
2)另外一种方式就是直接记录数据录入的部门编号。
这种方式弊端就是不能记录下数据的具体操作人员。
其它说明：如果系统中引入了工作流产品，数据来源这部分工作可以由工作流来担任。
具体例子：
在现实的软件系统中可能存在一个主数据库/数据中心，若干分数据库/数据中心，系统在每过一定时间进行数据上传/下载，为了进行数据合并和控制数据的修改，应该每个分数据中心只能处理修改自己的数据，可以查询总数据中心/其他分数据中心的数据。如果没有引入数据来源管理（数据属地管理）和数据版本的控制机制，不知道系统在作数据中心合并会怎样子？
7.数据项的分类编码
数据项的分类编码,实际上是数据项来源管理的一个具体延伸。数据项编码的目的就是更快更好的识别数据代表的业务意思。一个典型的例子就是ERP中的BOM表（基本物料清单）.
数据项的分类编码,不只是在系统模型建立上有指导意义，在进入系统的业务数据的规范化同样有指导意义。
数据项的业务编码和系统编码分离。业务编码很多时候只是为了识别业务数据的需要，很难保证业务数据的唯一性要求。而且业务编码可能会发生变动，有些单位的总体规划从调研到讨论制订、到项目审批通过，再到最终实施，常常几年过去了，需求发生变化，这种编码规则不发生变动几乎不可能。2000年我参与的一个企业软件系统，就一个产品编码规则2个月就发生了5次变动。从更长的时间范围内来说，应该考虑数据产生时期问题，不同时间阶段产生的业务数据，使用的业务规则不一样，数据编码这个层次很多时候很难识别数据当时的业务环境。
以一个简单的例子来说明：
业务数据表的primary key系统应该是系统定义的，而数据项的业务编码只能作为索引或者备用键使用，这样就减少了数据业务编码规则的变动对系统影响减少到更小的程度。
8.算法的版本化
本来我打算在前面的基础上，再谈一下业务流程的管理设置问题，不过，现在工作流思想深入人心，我也就跳过了。我打算从数据的核心业务处理，算法处理角度来阐述。
其实在现实中的软件项目中，大家提到的较多的BPR,工作流这些东西，但是很少提到
算法这个单词。当然，不可否认，很多软件项目，特别是电子政务/OA的业务主要是体现在
流程/文件上，算法这部分比较简单（当然，我这样说，有人可能不认可，暂且就不争论它了），就没有必要去强调算法的重要性了。
为了避免垃圾数据进入系统，垃圾数据出来，有必要对数据进行分类管理。正如前面提到的那样，对于进入系统的数据，进行信任等级划分，数据来源的分类；但是对于系统出口，为了避免出现垃圾数据，需要在数据处理阶段，也要进行分类处理，这里就引入了算法的版本化，来适应不同的数据/业务需要。
在实际项目中，可能不同信任等级的数据，采用不同的算法去处理数据，这样才使得数据的处理更有针对性，更符合实际需要。
从需求变更的角度出发，软件开发商可以先实现一些数据信任程度低的算法，然后再根据项目实际情况，决定是否实现更高一级数据等级的算法。在现实软件项目，数据信任等级低的采用的算法也会简单一些，由于需求变更，增加了新的数据信任等级更高的数据，这时候可以考虑暂时采用低等级的算法进行处理，然后再结合人工干预，达到数据处理的要求。大家都明白一点，算法复杂，测试的难度就大，但是使用这些更高等级的算法的几率是很少的，处于成本的原因可以把这些算法的实现滞后。
当然我这样说，并不是意味着放弃高等级的算法，一些根据项目实际情形需要来操作。
数据根据信任程度分成等级，呵呵，这就是所谓工厂方法模式嘛，算法也分成等级结构，这就是所谓的模板方法模式。
数据在处理后，应该记录下被使用的算法版本，这样才便于以后统计查询分析或者数据挖掘之类工作的开展。
例如：在一个商品交易中，一个商品可能被购买的价格是正常价格，节假日优惠价，会员优惠价，在交易流水账中，应该记录下交易时候是采用的那个价格类型，原始价格多少，实际购买价格多少。记录下原始价格，是因为，商品的原始价格本身可能是变化的。
再以拆迁资源计划系统( http://www.netsky-tech.com/))为例，房屋补偿的价格价格可能是来自于管理参数，也可能是来自于申请，实际到底是来自于哪个，算法应该记录下来。
9.业务规则使用的版本化
前面已经提到了数据录入的版本化，还有算法的版本化，也就是计算结果的版本化。但是还没有谈到一点，到底啥时间该采用哪个版本算法。
在J2EE项目中，一般是采用配置文件的方式来控制版本。从配置管理角度的来说，一切都根据配置文件来决定使用哪个版本的数据录入的分级(数据信任程度分级)，然后根据配置文件决定数据处理使用的算法版本。
其实在J2EE项目中，可以采用类似apache commons-validator这样的包，来进行数据录入的信任等级建立。
前面都已经提到了从工厂方法模式的角度来建立数据信任等级制度，但是并没有解决到底啥时间采用哪个方法处理数据。也许有人建议，采用工厂方法模式的思想，把数据当成产品，把算法当成工厂，来处理（注意：不是制造）数据。这个想法也许能够满足一些系统的需要，但是更多时候是失效。
为此，我觉得有必要把算法的分配使用当成为一个业务管理策略来管理，通过单独的业务模块去设置业务的算法管理策略，可以把这些策略保存为配置文件或者直接保存到数据表；在J2EE项目中，常用的方式使用XML的格式保存为配置文件，但是如果这个策略比较复杂的时候建议还是保存到数据表。
10.补充说明
由于最近事情比较多，对于项目实施中的数据管理先整理这些，有空的话，再继续整理。
大家如果有兴趣，可以切磋交流一下.
管理信息系统实施成功三大因素依次为：人、数据、技术，也许有些人不完全认同，但是数据的重要性是大家不可否认的。
1. 数据管理的组织机构的建立
为了更好的进行软件系统的数据管理，应该从组织机构角度来做考虑，建立单独的组织机构来管理数据相关工作，或者在实施小组里面专人总负责 。
软件开发商和客户核心的业务骨干一起制定数据规范，客户提供符合规范的业务数
据，只有符合规范的数据才能进入系统。
2. 数据管理的原则
强调客户和软件开发商的2方项目组成员做到“不能有‘我以为’的思想”，一旦有如此思想，很容易陷入闭门造车，项目需求很容易走样，因为客户à所有的客户，也是在‘我以为’。项目组要想做到控制住需求，一定要抛开自己的设想。所以任何一个项目组成员，第一句话就告诉他，不要有“我以为”的想法。把’我以为’变成’客户认为’(最好是客户和软件提供商一致认为)，这才是最重要的。
呵呵，这又回到了项目管理上。我在这里实际上只是想从数据管理这个更具体的角度来阐述问题。
3. 数据入口的单一性
同一数据必须一次、一处进入系统，保证其准确性，及时性和完整性和入口的单一性。
管理控制一体化是系统的目的，如果一个数据在多个地方存储，很容易造成数据的不一致。
4. 数据副本管理/数据版本管理
虽然上面提到了数据存储的单一性，但是有些时候也需要存储副本数据。存储这些
副本数据的目的就是为了在使用数据副本的地方不受到数据源的变化的影响。
例如：数据1在业务A进入系统，业务B使用到了数据1，但是为了避免在业务B使用了数据1后，业务A又把数据1的修改影响到业务B，那就需要业务B在使用数据1时候保存副本。
比如：城市拆迁资源计划系统( http://www.netsky-tech.com/)的拆迁合同在使用房源业务录入的房源房屋面积信息时,就使用了副本机制，在合同使用房屋面积时候，把面积信息存储下来，当合同构筑完成时候，如果相应的房屋面积信息发生了变动，就用另外的业务来处理这个数据变动的相应处理（比如，使用房源的差价款合同来处理）。
有朋友建议用配置管理系统，把数据版本机制引入了业务数据里面.做过J2EE的项目，
都知道很多地方可以通过配置来进行管理。其实这个思想延伸到数据库模型的设计时候，就体现出来了业务数据的配置管理的思想的使用。
我们其实也有是用这个思想，但是主要体现在 在基于数据表级别上 用数据级别+历史
编号 来识别有效的数据。1个很简单的例子：
一个员工的姓名原来 是aa, 后来改委bb，可以通过 历史编号 找到原来 的信息是bb
通过数据级别识别现在的有效数据是aa，我们把数据版本控制更多的是采用’数据级别’加’历史编号’另外还加上了一个’生效日期’, ‘截止日期’这2个时间戳.
另外，实际软件系统的历史业务数据进入系统就比较烦，可能需要使用版本管理机制来处理才行得通。
5.建立数据等级制度
软件项目实施中业务规则经常会陷入一个两难的境地，如果业务规则加强，很多数据数据达不到规范化的要求，无法入机；如果放宽控制，很多垃圾数据就进入了，大家都明白一个道理，对于软件系统，垃圾数据进去，肯定是垃圾数据出来，统计查询结果肯定是这样的。
可以建立数据的等级制度，制定数据进入系统的最低要求。达到最低要求才能进入系统，
比如：
业务A,需要数据a1,数据a2,,数据a3, 数据4。我们可以制定进入系统的关于业务A的条件是必须要有数据a1,a2才可以进入系统（也就是最低要求），如果提供的业务数据同时有数据a1,数据a2, ,数据a3,那就是更高一级的数据（第二级数据），如果业务数据在满足第二级数据的基础上，提供了数据4，那就是第三级数据。
如果用过J2EE平台的同行理解起来就比较容易，这实际上就是JMS基于主题的消息管理思想用于软件系统一个具体例子而已，这里不过是强调的是用于管理数据的信任等级而已。
其实很多软件项目开始制定的的数据规范，一般到后来都执行不下去，主要是太理想化了，也许只有到系统真正用起来了，系统数据的信任等级才能上去。所以我觉得应该在系统开始时候就把数据分等级，不同的等级，业务给与适当不同的处理，这样也便于后期的业务进行查询统计分析或者数据挖掘。
这种思想实际上就是将数据可以信任的程度进行分类；而一般的软件系统是把数据定义为两类，可以进入系统，不可以进入系统；我在这里设想的是，从数据可以信任的角度出发，分成多种类别，使用了一个小数来描述信任程度，而不是一个二值逻辑变量来描述；这样从建立软件系统整体模型的时候，把数据信任管理纳入考虑之内，在进一步作业务分析，决策支持或者数据挖掘时候是比较有好处的；当然进一步延伸可能就需要从OLTP/OLAP混合建模来考虑，不过真要到那个高度，可能项目范围就扩大了很多，具体怎样操作，还要看项目具体情形。
当然，在软件项目实际操作的时候，可能还会遇到另外一个问题，很可能用户会乱用这个数据信任程度的概念，我个人的建议是在项目实施中如果可能的话，优先进入信任等级高的数据，然后才是信任程度低的数据；当然也可以从人员来角度作为切入点，信任等级越低的数据，进入系统就需要的业务更熟悉的人员来操作录入，而且经过的业务处理步骤就越多。一句话，数据信任程度越低，就应该受到的审查/检察越多。
参考：数据信任等级图
6.数据来源管理
在现实中稍微规模大一点的软件系统涉及到的组织机构都是比较大的，有很多还可能是松散的组织管理模式。在这类组织机构中，同样的业务数据可能很多部门都会是数据录入点和数据分析点，为此可以从数据采集/来源角度来描述数据本身。
从当前项目利益来说，数据来源管理方便数据查询分类，长期来说可以建立起数据信任等级。
对于数据来源的识别，一般需要有特定信息来记录数据的来源，特别是一些大型企业当然分支机构较多的公司企业政府，也应该这样来管理。
事实上，数据来源管理是数据信任管理的进一步延伸，是数据信任管理的前置条件。一个数据，可以是来自于A部门的也可能是来自于B部门的。为了方便统计查询和数据信任管理的加强，应该记录下数据的来源地。
具体操方式可以有以下几种：
1) 数据录入人员的工作人员编号，知道了数据录入人员的编号，就知道数据的来源地。
当然，实际工作种存在人员调动，替操作（1个人用另外一个人的身份进入系统数录入），
这些都有可能需要考虑到，否则可能造成数据来源管理失效。
2)另外一种方式就是直接记录数据录入的部门编号。
这种方式弊端就是不能记录下数据的具体操作人员。
其它说明：如果系统中引入了工作流产品，数据来源这部分工作可以由工作流来担任。
具体例子：
在现实的软件系统中可能存在一个主数据库/数据中心，若干分数据库/数据中心，系统在每过一定时间进行数据上传/下载，为了进行数据合并和控制数据的修改，应该每个分数据中心只能处理修改自己的数据，可以查询总数据中心/其他分数据中心的数据。如果没有引入数据来源管理（数据属地管理）和数据版本的控制机制，不知道系统在作数据中心合并会怎样子？
7.数据项的分类编码
数据项的分类编码,实际上是数据项来源管理的一个具体延伸。数据项编码的目的就是更快更好的识别数据代表的业务意思。一个典型的例子就是ERP中的BOM表（基本物料清单）.
数据项的分类编码,不只是在系统模型建立上有指导意义，在进入系统的业务数据的规范化同样有指导意义。
数据项的业务编码和系统编码分离。业务编码很多时候只是为了识别业务数据的需要，很难保证业务数据的唯一性要求。而且业务编码可能会发生变动，有些单位的总体规划从调研到讨论制订、到项目审批通过，再到最终实施，常常几年过去了，需求发生变化，这种编码规则不发生变动几乎不可能。2000年我参与的一个企业软件系统，就一个产品编码规则2个月就发生了5次变动。从更长的时间范围内来说，应该考虑数据产生时期问题，不同时间阶段产生的业务数据，使用的业务规则不一样，数据编码这个层次很多时候很难识别数据当时的业务环境。
以一个简单的例子来说明：
业务数据表的primary key系统应该是系统定义的，而数据项的业务编码只能作为索引或者备用键使用，这样就减少了数据业务编码规则的变动对系统影响减少到更小的程度。
8.算法的版本化
本来我打算在前面的基础上，再谈一下业务流程的管理设置问题，不过，现在工作流思想深入人心，我也就跳过了。我打算从数据的核心业务处理，算法处理角度来阐述。
其实在现实中的软件项目中，大家提到的较多的BPR,工作流这些东西，但是很少提到
算法这个单词。当然，不可否认，很多软件项目，特别是电子政务/OA的业务主要是体现在
流程/文件上，算法这部分比较简单（当然，我这样说，有人可能不认可，暂且就不争论它了），就没有必要去强调算法的重要性了。
为了避免垃圾数据进入系统，垃圾数据出来，有必要对数据进行分类管理。正如前面提到的那样，对于进入系统的数据，进行信任等级划分，数据来源的分类；但是对于系统出口，为了避免出现垃圾数据，需要在数据处理阶段，也要进行分类处理，这里就引入了算法的版本化，来适应不同的数据/业务需要。
在实际项目中，可能不同信任等级的数据，采用不同的算法去处理数据，这样才使得数据的处理更有针对性，更符合实际需要。
从需求变更的角度出发，软件开发商可以先实现一些数据信任程度低的算法，然后再根据项目实际情况，决定是否实现更高一级数据等级的算法。在现实软件项目，数据信任等级低的采用的算法也会简单一些，由于需求变更，增加了新的数据信任等级更高的数据，这时候可以考虑暂时采用低等级的算法进行处理，然后再结合人工干预，达到数据处理的要求。大家都明白一点，算法复杂，测试的难度就大，但是使用这些更高等级的算法的几率是很少的，处于成本的原因可以把这些算法的实现滞后。
当然我这样说，并不是意味着放弃高等级的算法，一些根据项目实际情形需要来操作。
数据根据信任程度分成等级，呵呵，这就是所谓工厂方法模式嘛，算法也分成等级结构，这就是所谓的模板方法模式。
数据在处理后，应该记录下被使用的算法版本，这样才便于以后统计查询分析或者数据挖掘之类工作的开展。
例如：在一个商品交易中，一个商品可能被购买的价格是正常价格，节假日优惠价，会员优惠价，在交易流水账中，应该记录下交易时候是采用的那个价格类型，原始价格多少，实际购买价格多少。记录下原始价格，是因为，商品的原始价格本身可能是变化的。
再以拆迁资源计划系统( http://www.netsky-tech.com/))为例，房屋补偿的价格价格可能是来自于管理参数，也可能是来自于申请，实际到底是来自于哪个，算法应该记录下来。
9.业务规则使用的版本化
前面已经提到了数据录入的版本化，还有算法的版本化，也就是计算结果的版本化。但是还没有谈到一点，到底啥时间该采用哪个版本算法。
在J2EE项目中，一般是采用配置文件的方式来控制版本。从配置管理角度的来说，一切都根据配置文件来决定使用哪个版本的数据录入的分级(数据信任程度分级)，然后根据配置文件决定数据处理使用的算法版本。
其实在J2EE项目中，可以采用类似apache commons-validator这样的包，来进行数据录入的信任等级建立。
前面都已经提到了从工厂方法模式的角度来建立数据信任等级制度，但是并没有解决到底啥时间采用哪个方法处理数据。也许有人建议，采用工厂方法模式的思想，把数据当成产品，把算法当成工厂，来处理（注意：不是制造）数据。这个想法也许能够满足一些系统的需要，但是更多时候是失效。
为此，我觉得有必要把算法的分配使用当成为一个业务管理策略来管理，通过单独的业务模块去设置业务的算法管理策略，可以把这些策略保存为配置文件或者直接保存到数据表；在J2EE项目中，常用的方式使用XML的格式保存为配置文件，但是如果这个策略比较复杂的时候建议还是保存到数据表。
10.补充说明
由于最近事情比较多，对于项目实施中的数据管理先整理这些，有空的话，再继续整理。
大家如果有兴趣，可以切磋交流一下.
数据分级及算法版本化的思想对于较复杂的业务系统来说是非常重要的.
用户及开发人员都不会希望系统在运行时中有太多的垃圾数据, 但这与现实情况往往是个矛盾,现实数据采集往往是由人手工完成的,故收集回来的数据五花八门,系统如果没有数据分级的处理,那么结果可能是实施不下去导致用户满意度下降,并且开发人员整天处于救火状态(不管是
为了处理无穷尽的垃圾数据还是为了降低数据限制以让现实数据进入系统).算法的版本化与数据
的分级是相关的,不同级别的数据需要不同的算法来处理,不同时期的数据可能需要不同一算法来
处理等等.
用户及开发人员都不会希望系统在运行时中有太多的垃圾数据, 但这与现实情况往往是个矛盾,现实数据采集往往是由人手工完成的,故收集回来的数据五花八门,系统如果没有数据分级的处理,那么结果可能是实施不下去导致用户满意度下降,并且开发人员整天处于救火状态(不管是
为了处理无穷尽的垃圾数据还是为了降低数据限制以让现实数据进入系统).算法的版本化与数据
的分级是相关的,不同级别的数据需要不同的算法来处理,不同时期的数据可能需要不同一算法来
处理等等.
软件项目实施总结3---项目实施中的数据管理2
这算是最后一个软件项目实施总结，写的简单，算是结束这个自己定下的任务了。具体内容如下。
1. 数据精度
数据精度问题，数据单位问题。数量的上下文。
数据处理中的定点数，和float数。实际上在一些数据中间运算中，不管那种方式，都会丢失精度。双方要在这方面做出约定。中间结果四舍五入的使用原则，保留精度，最后结果的精度。
在一些加权计算中，中间计算会丢失精度，为了不影响最后结果，可以考虑使用减法的原则，把结果确保达到业务要求。
说道数据精度，就又牵涉到数据的业务描述的详细程度。当然如果从模糊数学来解释可能更好解释。我在这里引入目录树的数据描述方式，或者说是用基于主题的方式来描述业务数据。
2. 数据单位
一般管理系统中都会存在数据单位问题，如果作一些出口软件。这个那是自然更需要面对和考虑的问题了。
3. 数据盘点
一般业务数据都会存在天/周/月盘点，盘点时候，自然存在物品自然损耗，资金损耗，需要进行坏账处理。而且，从系统实时调度决策的准确性，也需要定期作盘点。
4. 数据收集与准备
静态通用数据的收集整理。
软件项目的这部分数据收集整理是相对比较容易一些的。
一般包含一些基本的组织机构数据，基本的业务数据。例如：
商品条目文件，基本工作流程，供应商基础资料，销售客户数据
5. 数据正确性保证
一般进入的系统的数据都需要手工进行复核，最好至少有1个人
出现有争议数据(如何处理?数据的纠偏机制?)
数据核对数据的准确性
6. 朋友同事对实施的一些看法，主要从管理角度来提出的。
项目风险一般存在:人.技术,意外,数据安全。
6.1.项目组织
项目经理一定要勇于拍板，敢于承担责任，项目经理不应天天坐办公室的,他需要亲自于客户打下交道.和客户打交道,需要找一些能拍板的,或对某一方面特别熟悉的。和客户打交道,需要找一些能拍板的,或对某一方面特别熟悉的。
软件系统实施，双方项目组联系脱节，是否例行沟通坚持下来了
在上线前,需要充分估计可能存在的风险,并定制好应急计划.定制这事应是群策群力的.
其实实施很多时候，或者说本来就应该从管理角度来考虑问题，处理问题。要丛多哥方面来阐述从甲方，乙方，监理公司（咨询公司），还有实施小组的人员搭配，多方项目组成员的搭建，客户投诉管理流程，着很多是从管理角度来考虑 的另外多方会晤机制，开会一定要目的明确，特别是一些问题解决会议，一定要落实到实处，否则这种情况多了，开会成了1个休息的时间，或者干脆有人就不来了，即使来了，也是白搭，没有听进去，人家心理会想参加有什么意义？
6.2. 寻找项目动力
提高系统在客户心中的价值.如对一些实用性的小功能加大力度推行. 发握系统中的闪光点. 说高科技人家不懂,说点易用的好接受. 这实际上是1个易用性的具体执行，还可以适当地在用户群中做一下使用情况的调查.这有利于发现系统中存在的不足. 这实际上是定期上线调查，捕捉系统的问题。
6.3 实施体操作小组不要滥用
不要形成实施人员帮做业务的不恶习,要培养起一批用户骨干. 不然会累死自己. 临时替操做人员，成为了永久替操作人员。
6.4 项目计划
在制定计划时,注意解决那些不急,但很重要的问题. 制定计划时要符合实际, 计划要有阶段性，然后定期调整不要比们草车，不结合实际，注意解决那些不急,也可以丛资源的准备问题来说，如果从项目管理角度来说，这写问题的解决需要一些前提任务，如果在指定计划没有把着一点作好模块定好了上线日期后,就尽量保证时间一到就能用,不要影响客户的业务. 项目任务的排序是肯定需要的。
6.5. 系统上线初期
用户业务手工和系统并行云做是最容易出问题的。
系统上线后,需要客户方统一做法. 明确数据走两条路的造成的影响不负责. 不然老是帮忙补数据,没完没了. 还有一个问题，就是历史数据的划分问题，着部分弄不好，很容易被陷在里面，实施小组很难脱身，依赖性养成；是很难改过来的，他们客户觉得有实施小组存在,有问题也不敢立马解决,需要确认一下才敢做.例行交流会议肯定要开的，那怕加班来开都是应该的2边都是应该这样，否则大家都不止到别人在干啥。
6.6. 数据交割期限的设置：
主要是历史数据的划分问题，这部分弄不好，很容易陷入一直在处理系统历史数据问题。
6.7 QA库的建立
把一些常见的问题，以及应该采取的处理方式，收集起来，形成一个常用问题解答库，也就是一个知识库。
6.8. 培训
培训相关需要的内容：
相关业务培训（当然有培训手册）
培训后的答疑
培训后的考试
培训一定要注意培训顺序和培训重点，还要抓住业务骨干，不要只管范围，不管质量。
6.9. 论系统模拟上线
系统模拟上线的目的要明确，就是为了模拟系统正式运行的环境，发现软件系统问题。实施范围必须明确，实施培训手册到位，培训计划先于模块实施上线。
一般系统上线前都要有模拟上线。
为了得到好的效果，模拟数据一定要有真实行，最好是采用现有的真实数据。
另外模拟一定要让模拟操作人员认识到这是在作真实业务数据一样，或者干脆瞒天过海,就说是真实上线。否则模拟人员不认真对待，很容易让模拟流于形式，很多在模拟中应该出现的问题没有出现，这样就严重了。
模拟上线根据实际需要可能还会分几次进行（同1批人），或者分成几批人进行，也可能分成几
批几次进行。当然这样也可能会造成由于人员分批不当，有些问题或者很多再后面的模拟才能暴露出来，或者由于大家有依赖思想，以为别人会发现问题，自己就可以不用那样用心了，特别是在模拟人员有很多业务工作要做的时候更是如此了。当然，如果有一定奖励措施，就可能好一些了。
7.结束语
我经常写一些技术学习的心得，但是对于一些项目实施/系统分析这类和管理结合比较紧密的东西，我基本是凭兴趣，一时心血来潮去写的。其实现实中的软件项目很多程序员喜欢在工作学习中写学习心得，但是很少有去写管理心得。关于这个项目实施总结，我本来打算主要从项目管理角度来阐述的，
但是由于种种原因放弃了，干脆就从系统分析角度/系统开发根据实施效果去总结。由于最近这几个星期乱七八糟的事情太多，从开始写这个东西到现在已经好几个星期了，差不多写总结的热情也耗光了，也就宣布这个项目实施总结结束了。
8.参考资料
8.1. blog.itpub
搜索”实施”，应该可以找到一堆项目实施的资料
8.2 分析模式：可复用的对象模型
（美）Martin Fowler
http://www.china-pub.com/computers/common/info.asp?id=16605
8.3. 本人实施的相关文章
项目实施总结1
http://blog.itpub.net/post/197/7122
软件项目实施总结2---项目实施中的数据管理
http://blog.itpub.net/post/197/7937
8.4. 大连圣达的网站 http://www.sinoprogress.com/
高复先是这个公司的老板
信息资源规划（IRP）系列讲座之四：营造数据环境（高复先）
http://www.amteam.org/docs/BDDocument.asp?Action=View&ID={A7C57098-1C76-491A-AAE4-FE3288422531}&ReturnTo=BDSearch%2Easp
8.5.实施信息的获取
8.5.1去一些专业网站收集,比如：
http://www.topoint.com.cn/
http://www.ccidnet.com/
http://www.zdnet.com.cn/
http://www.amteam.org/docs/bpwebsite.asp
http://www.uml.net.cn/
http://www.51cmm.com
8.5.2.通过google去搜索了，这个是地球人都知道的.
8.5.3通过朋友介绍信息来源然后去这些地方采集信息.
这算是最后一个软件项目实施总结，写的简单，算是结束这个自己定下的任务了。具体内容如下。
1. 数据精度
数据精度问题，数据单位问题。数量的上下文。
数据处理中的定点数，和float数。实际上在一些数据中间运算中，不管那种方式，都会丢失精度。双方要在这方面做出约定。中间结果四舍五入的使用原则，保留精度，最后结果的精度。
在一些加权计算中，中间计算会丢失精度，为了不影响最后结果，可以考虑使用减法的原则，把结果确保达到业务要求。
说道数据精度，就又牵涉到数据的业务描述的详细程度。当然如果从模糊数学来解释可能更好解释。我在这里引入目录树的数据描述方式，或者说是用基于主题的方式来描述业务数据。
2. 数据单位
一般管理系统中都会存在数据单位问题，如果作一些出口软件。这个那是自然更需要面对和考虑的问题了。
3. 数据盘点
一般业务数据都会存在天/周/月盘点，盘点时候，自然存在物品自然损耗，资金损耗，需要进行坏账处理。而且，从系统实时调度决策的准确性，也需要定期作盘点。
4. 数据收集与准备
静态通用数据的收集整理。
软件项目的这部分数据收集整理是相对比较容易一些的。
一般包含一些基本的组织机构数据，基本的业务数据。例如：
商品条目文件，基本工作流程，供应商基础资料，销售客户数据
5. 数据正确性保证
一般进入的系统的数据都需要手工进行复核，最好至少有1个人
出现有争议数据(如何处理?数据的纠偏机制?)
数据核对数据的准确性
6. 朋友同事对实施的一些看法，主要从管理角度来提出的。
项目风险一般存在:人.技术,意外,数据安全。
6.1.项目组织
项目经理一定要勇于拍板，敢于承担责任，项目经理不应天天坐办公室的,他需要亲自于客户打下交道.和客户打交道,需要找一些能拍板的,或对某一方面特别熟悉的。和客户打交道,需要找一些能拍板的,或对某一方面特别熟悉的。
软件系统实施，双方项目组联系脱节，是否例行沟通坚持下来了
在上线前,需要充分估计可能存在的风险,并定制好应急计划.定制这事应是群策群力的.
其实实施很多时候，或者说本来就应该从管理角度来考虑问题，处理问题。要丛多哥方面来阐述从甲方，乙方，监理公司（咨询公司），还有实施小组的人员搭配，多方项目组成员的搭建，客户投诉管理流程，着很多是从管理角度来考虑 的另外多方会晤机制，开会一定要目的明确，特别是一些问题解决会议，一定要落实到实处，否则这种情况多了，开会成了1个休息的时间，或者干脆有人就不来了，即使来了，也是白搭，没有听进去，人家心理会想参加有什么意义？
6.2. 寻找项目动力
提高系统在客户心中的价值.如对一些实用性的小功能加大力度推行. 发握系统中的闪光点. 说高科技人家不懂,说点易用的好接受. 这实际上是1个易用性的具体执行，还可以适当地在用户群中做一下使用情况的调查.这有利于发现系统中存在的不足. 这实际上是定期上线调查，捕捉系统的问题。
6.3 实施体操作小组不要滥用
不要形成实施人员帮做业务的不恶习,要培养起一批用户骨干. 不然会累死自己. 临时替操做人员，成为了永久替操作人员。
6.4 项目计划
在制定计划时,注意解决那些不急,但很重要的问题. 制定计划时要符合实际, 计划要有阶段性，然后定期调整不要比们草车，不结合实际，注意解决那些不急,也可以丛资源的准备问题来说，如果从项目管理角度来说，这写问题的解决需要一些前提任务，如果在指定计划没有把着一点作好模块定好了上线日期后,就尽量保证时间一到就能用,不要影响客户的业务. 项目任务的排序是肯定需要的。
6.5. 系统上线初期
用户业务手工和系统并行云做是最容易出问题的。
系统上线后,需要客户方统一做法. 明确数据走两条路的造成的影响不负责. 不然老是帮忙补数据,没完没了. 还有一个问题，就是历史数据的划分问题，着部分弄不好，很容易被陷在里面，实施小组很难脱身，依赖性养成；是很难改过来的，他们客户觉得有实施小组存在,有问题也不敢立马解决,需要确认一下才敢做.例行交流会议肯定要开的，那怕加班来开都是应该的2边都是应该这样，否则大家都不止到别人在干啥。
6.6. 数据交割期限的设置：
主要是历史数据的划分问题，这部分弄不好，很容易陷入一直在处理系统历史数据问题。
6.7 QA库的建立
把一些常见的问题，以及应该采取的处理方式，收集起来，形成一个常用问题解答库，也就是一个知识库。
6.8. 培训
培训相关需要的内容：
相关业务培训（当然有培训手册）
培训后的答疑
培训后的考试
培训一定要注意培训顺序和培训重点，还要抓住业务骨干，不要只管范围，不管质量。
6.9. 论系统模拟上线
系统模拟上线的目的要明确，就是为了模拟系统正式运行的环境，发现软件系统问题。实施范围必须明确，实施培训手册到位，培训计划先于模块实施上线。
一般系统上线前都要有模拟上线。
为了得到好的效果，模拟数据一定要有真实行，最好是采用现有的真实数据。
另外模拟一定要让模拟操作人员认识到这是在作真实业务数据一样，或者干脆瞒天过海,就说是真实上线。否则模拟人员不认真对待，很容易让模拟流于形式，很多在模拟中应该出现的问题没有出现，这样就严重了。
模拟上线根据实际需要可能还会分几次进行（同1批人），或者分成几批人进行，也可能分成几
批几次进行。当然这样也可能会造成由于人员分批不当，有些问题或者很多再后面的模拟才能暴露出来，或者由于大家有依赖思想，以为别人会发现问题，自己就可以不用那样用心了，特别是在模拟人员有很多业务工作要做的时候更是如此了。当然，如果有一定奖励措施，就可能好一些了。
7.结束语
我经常写一些技术学习的心得，但是对于一些项目实施/系统分析这类和管理结合比较紧密的东西，我基本是凭兴趣，一时心血来潮去写的。其实现实中的软件项目很多程序员喜欢在工作学习中写学习心得，但是很少有去写管理心得。关于这个项目实施总结，我本来打算主要从项目管理角度来阐述的，
但是由于种种原因放弃了，干脆就从系统分析角度/系统开发根据实施效果去总结。由于最近这几个星期乱七八糟的事情太多，从开始写这个东西到现在已经好几个星期了，差不多写总结的热情也耗光了，也就宣布这个项目实施总结结束了。
8.参考资料
8.1. blog.itpub
搜索”实施”，应该可以找到一堆项目实施的资料
8.2 分析模式：可复用的对象模型
（美）Martin Fowler
http://www.china-pub.com/computers/common/info.asp?id=16605
8.3. 本人实施的相关文章
项目实施总结1
http://blog.itpub.net/post/197/7122
软件项目实施总结2---项目实施中的数据管理
http://blog.itpub.net/post/197/7937
8.4. 大连圣达的网站 http://www.sinoprogress.com/
高复先是这个公司的老板
信息资源规划（IRP）系列讲座之四：营造数据环境（高复先）
http://www.amteam.org/docs/BDDocument.asp?Action=View&ID={A7C57098-1C76-491A-AAE4-FE3288422531}&ReturnTo=BDSearch%2Easp
8.5.实施信息的获取
8.5.1去一些专业网站收集,比如：
http://www.topoint.com.cn/
http://www.ccidnet.com/
http://www.zdnet.com.cn/
http://www.amteam.org/docs/bpwebsite.asp
http://www.uml.net.cn/
http://www.51cmm.com
8.5.2.通过google去搜索了，这个是地球人都知道的.
8.5.3通过朋友介绍信息来源然后去这些地方采集信息.