软件项目标书范本

中国外汇交易中心数据仓库一期项目建议第二册 技术部分安讯软件（上海）有限公司2008年5月4日目录1项目目标12技术解决方案22.1系统总体架构2逻辑架构2功能层面（上侧面）2非功能层面（右侧面）3设计层面3ETL数据抽取3报表设计3报表展现3报表应用3物理架构3数据架构52.2系统技术实现方案6总体技术实现方案6高效的ETL处理7ETL总体处理流程7数据仓库模型设计9数据质量管理10数据仓库对数据质量的要求10数据质量改进目标10数据质量改进方法10报表平台设计11灵活的报表查询12先进的报表开发模式12高效的报表消费12老系统统计报表移植12认证管理13系统可靠性及可扩展性13非功能性设计14性能需求14 灾备设计15可获性设计17 易用性设计17 安全性设计183项目管理193.1沟通管理19项目会议制度19定期会议20不定期会议20项目状态周报制度21沟通手段213.2配置管理22配置管理原则22配置库管理223.3变更管理22发起变更22评估变更23审批变更23执行变更23变更执行评估233.4质量管理24质量规划24质量保证25质量检查264工期进度265附录27第二册 技术部分1 项目目标CFETS希望通过数据仓库系统的建设，可以有效地整合各市场业务数据，统一对信息进行利用和管理，对外提供统一的数据视图和综合决策分析支撑环境，为CFETS各部门所需的报表应用、统计分析及信息挖掘提供基础支持平台。具体建设目标如下：（1）技术目标 建立数据仓库基础架构 建立自动数据抽取转换加载（ETL）机制 建立多维分析和数据查询工具和界面已经分析报表生成和展示框架（2）业务目标 实现一期经营分析的多维分析、查询和报表，提供CFETS各部门所需报表 提供下游系统所需要的统计数据 提供中心内部用户以Ad-Hoc方式查询所需数据 将业务系统的历史和增量数据加载进入数据仓库，并转换为数据仓库的存储格式 实现用户访问的门户界面并建立相应的访问安全和权限机制 进行老系统统计报表的移植工作，保证数据仓库系统中的报表统计结果与原报表统计结果的一致性基于上述需求，安讯软件（上海）有限公司提出如下技术解决方案来实现本项目的技术目标和业务目标。2 技术解决方案2.1 系统总体架构2.1.1 逻辑架构总体逻辑架构如下：2.1.1.1 功能层面（上侧面）根据CFETS对应的功能需求，对应的功能层面上需要建立如下功能： 数据的ETL 数据存储 固定统计报表 统一用户界面及Portal认证管理2.1.1.2 非功能层面（右侧面） 易用性 响应性 可靠性 扩展性 安全性2.1.2 设计层面2.1.2.1 ETL数据抽取通过成熟的ETL工具，实现从不同的数据源中抽取出所需要的信息，同时通过数据的加工和格式化，对外提供给其他系统使用。2.1.2.2 报表设计当形成好统一的数据仓库后，基于该仓库模型，可进行对应的报表设计和管理，技术人员设计好基本的报表后，可提供给业务人员使用。2.1.2.3 报表展现技术人员设计好报表模板后，通过发布到对应的服务器据，实现对报表的展现。2.1.2.4 报表应用业务人员通过终端界面，可以使用由开发人员开发和设计的报表，同时，业务人员也能同报表进行交互，检索出自己需要的数据。2.1.3 物理架构对于本，外币不同的数据源，以及不同的物理子系统，基本的物理架构如下：物理架构说明：A. 本外币数据库向仓库提供对应的数据B. 仓库为对应的报表服务器提供统一的视图。C. 权限报表服务器部署到同一机器上。2.1.4 数据架构数据流说明：A. 首先从本外币或者其他系统获得对应的数据.B. 经过ETL对数据进行加工，清洗和标准化。C. 将已经标准化和模型化的数据进入到数据仓库，或者提供需要的数据文件。D. 数据仓库对外暴露数据模型和数据视图以及sql接口。E. 数据仓库为报表管理系统和下游系统提供所需要的数据F. 报表管理系统展现对应数据的报表。2.2 系统技术实现方案2.2.1 总体技术实现方案充分考虑到CFETS系统存在在本外币等多种数据源，且数据源分散，多分散子系统的情况，同时各个子系统中存在统计口径不一致，影响统一的决策和各个部门信息的一致性。在使用的过程中，会员信息维护复杂，且各个系统各自维护一套对应的会员信息，导致会员维护工作量加大。数据仓库一期需求大致可以分成数据库架构的建立、ETL机制的建立、以及报表分析架构的建立和报表实施。系统可以分成数据仓库和报表系统两大部分。以下是我们建议的系统架构概念图：系统包含一个双机组成的数据仓库，和一个双机组成的报表服务平台。数据仓库和报表服务器分别带有自己的外存磁盘阵列。架构中的每个功能节点设计都含冗余度，保证系统不存在单一失败点，满足提供7x24不间断服务的要求。在系统架构不变的前提下，系统的每部分可以用不同的技术实现。比如，数据库管理系统可以使用Oracle的技术，也可以使用IBM的技术。报表技术建议使用Actuate 9。使用我们建议的应用软件，这样的系统架构会有很强的可扩展性，用户可以通过增加硬件的方式扩容，以支持越来越多的用户和应用。总体方案通过以下步骤实现数据到可用信息的转换：1. 通过ETL手段对不同的数据源数据进行抽取，转换，清洗，数据格式化。2. 通过ETL转化后的数据统一进入数据仓库，形成统一的数据视图。3. 进入数据仓库的数据模型可以为报表平台提供对应的数据来源。4. 通过认证的用户可以登陆报表平台消费和设计对应的报表。2.2.2 高效的ETL处理2.2.2.1 ETL总体处理流程ETL处理流程：1. 从本币数据源或其他数据源中抽取需要的数据。2. ETL对抽取到的数据进行必要的增量处理，生成一天的增量数据。3. ETL对增量数据进行技术性检核、标准化、转换。4. 产生LDM落地数据文件。5. 落地数据文件下发到下游系统，同时进行数据入库。6. 整个ETL处理过程进行异常处理及监控。ETL实施我们建议采用成熟的ETL工具，所选ETL工具需要满足如下基本要求：（1）技术架构1)支持所有的主流平台2)模块化的架构设计，可按需进行模块添加和扩展3)具有错误恢复逻辑的功能4)支持并行处理（2） 核心功能1)支持本地数据访问模式2)支持星型模式3)支持打包应用（例如SAP）4)支持基本处理（例如SQL）5)具有数据自动转换和清洗功能6)支持实时ETL和按需ETL7)具有自动错误预警功能（3） 开发环境1)图形化界面2)支持命令行3)便于调试和维护4)具有代码版本控制功能（4） ETL管理1)支持集中管理2)自动产生每日ETL运行报表3)具有ETL自动和手工调度功能我们相信商业ETL工具中INFORMATICA会是一个很好的选择，开源ETL产品Kettle则是INFORMATICA之外一个很好的备选。2.2.2.2 数据仓库模型设计数据建模 建模过程：（以常用会计报表为例）1. 用户需要查看基于时间、机构和科目的报表。2. 建立以数据事实表为中心，需要时间、机构和度量作为其维度。3. 建立好如上的星型模型后，可发现模型具有如下优点。4. 灵活的数据查询，可基于时间查询对应的日报，月报和季报。5. 效率最优化，需要查询机构信息，则通过机构和事实表关联即可完成。2.2.3 数据质量管理2.2.3.1 数据仓库对数据质量的要求数据仓库对数据质量的要求总体上归纳为：数据完整性，包括数据源是否完整、数据取值是否完整、维度取值是否完整等。数据准确性，包括数据源是否准确、编码映射关系是否准确、处理逻辑是否准确等。数据核对准确的判断是要么结果一致，要么不一致但原因是可解释的。数据一致性，包括源系统之间同一数据是否一致，源数据与抽取的数据是否一致，数据仓库内部各处理环节数据是否一致等。数据逻辑合理性，主要从业务逻辑的角度判断数据是否正确，如帐目类型的金额、时长、次数的逻辑关系是否满足等。数据时效性，包括数据处理（获取、整理、加载等）的及时性，数据异常检测的及时性，数据处理回退的及时性等。数据仓库服务于经营决策，经营决策依据的数据应该是全面的、真实可靠的、有意义的。数据时效性如果得不到保证，就可能延误了市场人员的分析，失去商机。从数据仓库的建设过程来看，它本身修复数据以提高数据质量的能力并不是很强，但是它能发现生产系统存在的一些数据质量问题从而提醒用户哪些数据有质量问题，将数据问题反馈到业务支撑系统中，由后者做数据修正。2.2.3.2 数据质量改进目标数据质量改进的目标是清理、标准化、提高和匹配现有数据。通过数据整合，建立完整的、准确的、一致的统一客户视图，完善共享信息数据，并使共享信息数据服务于经营分析，为生产系统的改进提供标准。 建立数据整合流程，实现流程定义、流程配置和流程管控。 建立数据整合的规章制度，落实数据质量的分级负责。建立起数据整合队伍，使数据质量能够得以持续改进。2.2.3.3 数据质量改进方法数据质量控制要从技术、流程和管理三个方面进行。从技术层面上，生产系统存在的噪音数据、遗漏数据和不一致性数据，需要进行数据清洗；同时需要对源数据做稽核，如总量稽核和分量稽核。在流程层面上，对于源数据的抽取要遵从一定的业务规则，数据的抽取和转换需要很多步骤来完成，这就需要将过程流程化，并且流程可通过配置来实现。在管理层面上，要求生产系统报送数据，按照“谁提供数据，谁负责”的原则由生产系统保证源数据的完整性、准确性、一致性、时效性。下面是我们在技术层面采取的具体做法。在ETL架构设计中我们会包括数据质量设计，将数据质量检查脚本加入到ETL流程中，分为技术检查和业务规则检查。错误分严重程度，如主键重复的就停止ETL流程，等待解决，但低级别的错误不会阻塞ETL过程。在这个过程中，所有的错误都会进行记录，最终生成数据质量检查报告。但需要明确的是，很多情况下，许多数据问题在ETL之前都无法知道，只能通过ETL之后的数据核对才能发现，然后逐渐积累，加到ETL的规则控制中去。2.2.4 报表平台设计建立报表查询门户，提供各类信息报表的查询，统一查询渠道，统一数据口径，统一用户管理。多个管理信息系统在报表平台上表现为一个个独立的逻辑子系统。通过报表平台，技术人员可以通过灵活配置逻辑系统集成不同BI工具产生的异构报表资源，业务人员可以进行不同报表资源的集中管理和发布，最终用户可以通过一致的展示环境获取报表信息。具体设计如下：2.2.4.1 灵活的报表查询 在报表的查询过程中，可以通过浏览器直接浏览报表，同时，用户也可以通过简单的操作，对报表进行重新订制，为了更好的提高实用性，用户可通过浏览器同报表服务器进行交互，查看到需要的报表。2.2.4.2 先进的报表开发模式在报表的开发中，我们将采用最先进的协同开发模式，开发人员定制业务逻辑，业务人员根据自己需要通过简单的拖动则可形成自己需要的报表。2.2.4.3 高效的报表消费在使用的过程中，业务人员根本不用关心对应的后台业务逻辑，以及数据信息来源等信息，其只要根据自己的业务需要，通过简单的拖拽即可完成对报表的定制，获取到自己需要的信息。2.2.4.4 老系统统计报表移植对于老系统的统计报表，我们将采取重写的方式移植到统一的报表平台上面。重写后的统计报表基于新建的数据仓库，这样就统一了现存的多个统计系统，统一了统计口径，解决了统计口径不一致所造成的各个部门信息的不一致，并消除这种不一致对管理决策带来的负面影响。老系统报表迁移的一个难点是如何保证数据仓库系统中的报表统计结果与原报表统计结果的一致性，对此要具体问题具体分析。新报表的统计结果与原报表的统计结果不一致只可能是两种情况：新报表的统计方式是错误的，造成新老报表统计结果不一致；新老报表的统计口径不一致，造成统计结果不一致。如果是前一种情况，采用正确的统计方式就能修正错误。如果是后一种情况，则需要根据业务的需要选择统计口径，使新报表能够达到业务人员的预期。我们将会采用严格的测试手段来保证新报表与老报表统计结果的一致性。测试的目的，是验证对于相同的输入，新老报表得到的输出结果完全一致。实际测试中，我们将采用等价类划分以及边值分析法来设计测试用例，产生有限的测试用例来覆盖足够多的“任何情况”。对有差异的报表，我们会作进一步的数据集对比，以确定问题的根源到底是在数据，还是报表逻辑。2.2.5 认证管理 在对用户信息的管理中，提供以角色和用户为安全模型的统一认证机制，只有具有对应角色的用户才能访问对应的报表。2.2.6 系统可靠性及可扩展性系统的可靠性及可扩展性对企业级应用来说是非常重要的。我们的设计充分考虑了这两个因素。针对可靠性，我们的设计是在系统包含一个双机组成的数据仓库，和一个双机组成的报表服务平台。数据仓库和报表服务器分别带有自己的外存磁盘阵列。架构中的每个功能节点设计都含冗余度，保证系统不存在单一失败点，满足提供7x24不间断服务的要求。采用的这样系统架构，主机系统的维护、系统扩容、升级、系统性能统计、分析、优化以及部件更换就能够在不影响应用系统功能的前提下完成。而所有关键部件能够保证在不停顿数据共享服务的前提下提供热插拔能力。对于可扩展性，使用我们建议的报表服务平台安讯iServer，系统架构会有很强的可扩展性，用户可以通过增加硬件的方式扩容，以支持越来越多的用户和应用。安讯iServer可以运行在由多台服务器组成的集群上，利用任务控制与自动负载平衡技术，将任务平均分配到各台服务器上。安讯iServer具备出色的可扩展性，用户可以简单的向集群中添加更多的服务器来满足更高的报表需求，而系统的性能随着服务器数量的增多呈线性增长，这方面的具体数据请参考附录D “安讯9系统性能白皮书”。在集群系统中，安讯iServer可以通过不同的故障转移模(Failover)式来保障iServer各项服务的可用性。对系统可扩展性的考虑能充分保证用户不在初期购买超出业务量需求的处理能力。随着用户业务量的增长，主机系统能随时动态扩展处理能力，且系统性能是线性增长的，任何业务量的增长需要都能够通过对主机的线性扩展得到满足。2.2.7 非功能性设计2.2.7.1 性能需求2.2.7.1.1 容量设计根据1994-2007年的所有交易数据总容量为10G byte，大概每年的数据容量在800M左右，从容量和可扩展性和灾备等多方面综合考虑，建议每年的数据量分配在2.5G左右。2.2.7.1.2 响应设计高的响应能给用户带来效率上的提升 ，加快了工作效率，减少了等待时间，同时加快了系统的处理效率，我们将通过以下几方面手段来保证用户得到高质量的响应：1. 优化模型设计，好的模型设计能够减少冗余数据量的加载和检索，以及表间关联检索，能大大提高系统数据的响应时间。2. 有效利用数据库的缓存功能，对于经常访问的数据，可将数据缓存于数据库中，减少IO，3. 利用集群功能，合理分配负载，充分利用各主机的CPU, 内存等硬件资源。4. 优化报表设计，减少报表生成所需要的系统资源。5. 充分利用报表系统的缓存功能，把报表生成任务安排到非高峰时段。6. 充分利用报表系统的对查询的缓存功能，减少对数据源的实时访问。2.2.7.2 灾备设计2.2.7.2.1 灾备级别 高: 内部系统核心数据，包括所有连机和脱机数据，需要高级别的备份。 中：系统需要的资料数据。 低：与系统关系不大，偶尔系统需要使用到的数据。由此可见，对于高，中级别的数据，需要进行对应的备份。2.2.7.2.2 备份策略为了保障核心数据和重要数据的完整性和一致性，我们将提供对应的磁盘备份、联机备份和远程备份功能：磁盘备份：通过镜像 (mirrored) 磁盘矩阵, 对每一个写到磁盘的字节，作实时的镜像备份，减少磁盘机出错的几率。磁盘备份一旦设定，由设备实现，无需人工干预。联机备份：提供24*365天的备份机制，用户可以基于调度来运行备份，可以基于系统运行的热备份。我们设计方案中使用的Oracle 10g 或IBM DB 2 数据库，都支持热备份；Actuate 9 的报表服务器 iServer , 也支持联机热备份。 数据仓库的数据和报表服务器的报表，可以每天进行一次热备份。远程备份：提供对付灾害性的系统失败的有效方式。远程备份把数据存放到地理上的远方，以应对主机可能遇到当地灾害性的损毁。我们建议把每天的热备份数据，拷贝到远端备份存储服务器。以上的备份策略，保证在不影响系统服务的条件下，在本地和远程，都保留一份前一天的备份数据，包括数据仓库和报表服务器的数据。当地备份建议保留30天；远程备份建议保留7天。备份可以保存在磁带库、或光盘库。本地备份耗时目标是2小时；远程备份耗时目标是12小时。2.2.7.2.3 恢复策略常规的数据恢复流程设计如下：1) 重启系统的所有服务器和存储设备2) 如必要，恢复系统3) 从本地备份选取前一天的备份，或最近的备份；如果本地备份丢失，取远程备份4) 恢复数据仓库和报表系统数据5) 恢复系统服务常规数据恢复一般是在文件系统失败（包括磁盘设备失败）导致数据无法使用的情形下必须激活的程序。常规数据恢复保证系统回复到前一天的状态，但也意味着当天数据的丢失。一般系统出错的恢复，其实不一定需要用到备份，我们建议应该避免使用常规数据恢复，尽量考虑用其他办法把系统回复到最近的可用状态。以下我们以Oracle数据库为例，说明一下可以考虑的恢复措施。数据库的恢复过程分两步进行，首先将把存放在重做日志文件中的所有重做运用到数据文件，之后对重做中所有未提交的事务进行回滚。数据库的恢复只能在发生故障之前的数据文件上运用重做，将其恢复到故障时刻，而不能将数据文件反向回滚到之前的某一个时刻。数据库的异常、错误可以分为以下几类： SQL语句失败 线程失败 实例失败 用户操作失败 存储设备失败 如果发生前三种失败，不需要人为干涉，系统会自动进行恢复。对于用户操作型的失败（如误删除数据），系统采取的补救措施主要有导入最新的逻辑备份或进行到某一时间点的不完全恢复。数据库引入了基于表空间的时间点恢复(TSPITR)，可以单独将包含错误操作的表空间恢复到指定时间，而不必对整个数据库进行不完全恢复。当错误操作发现比较及时而且数据量不大的情况下也可以考虑使用logminer生成反向SQL。 针对存储设备的失败的情况比较复杂，存储设备的失败必然会使放置在其上的文件变为不可用，我们先将数据库所涉及到的文件进行一个划分，主要可分为： 数据库的系统文件，指数据库的运行文件，各种应用程序 数据库控制文件 数据库联机重做日志文件 数据文件 归档日志文件 避免第一种文件失败主要依赖系统管理员进行操作系统级的备份，当发生事故后只能依靠操作系统备份将其恢复。 控制文件中记录着整个数据库的结构、每个数据文件的状况、系统SCN、检查点计数器等重要信息，在创建数据库时会让用户指定三个位置来存放控制文件，他们之间互为镜像，当其中任何一个发生故障，只需将其从ini文件中注释掉故障数据文件就可重新将数据启动。当所有控制全部失效时，可以在Nomount模式下执行create controlfile来重新生成控制文件，但必须提供redo log，data file，文件名和地址以及MAXLOGFILES，MAXDATAFILES，MAXINSTANCES等信息。如果失败之前运行过alter database backup controlfile to trace或alter database backup controlfile to xxx对控制文件作备份，恢复时可使用生成的脚本来重建或用备份文件覆盖，如果使用了旧的控制文件在恢复时要使用recover xxx using backup controlfile选项来进行恢复，并使用resetlogs选项来打开数据库。2.2.7.3 可获性设计按照我们在2.2.1中建议的系统架构，系统包含一个双机组成的数据仓库，和一个双机组成的报表服务平台。数据仓库和报表服务器分别带有自己的外存磁盘阵列。架构中的每个功能节点设计都含冗余度，保证系统不存在单一失败点。 此外，高可获性来自于我们建议的软件系统，无论是Oracle, IBM DB2, 或Actuate 9, 都支持失败转移等高级集群功能，满足提供7x24不间断服务的要求，能够保证满足任何时候系统的可获性需求。2.2.7.4 易用性设计在软件的易用性方面，我们将充分考虑用户的体验性，简单性，高效率性为客户定制一套更适合客户需要的的系统，根据需要，我们将基于以下方面进行设计： 使用大众化WEB浏览器如IE、Firefox作为客户端的浏览工具。 用户界面友好、同时易操作。 界面操作符合浏览习惯。 界面风格，术语统一。 灵活的页面布局，支持标签页。 合理的组织操作菜单 查询等出现错误时提供友好的提示。 提供友好的联机帮助界面。2.2.7.5 安全性设计2.2.7.5.1 身份认证系统提供身份认证功能。使用系统的用户必须先要经过申请审批管理流程，通过有关部门管理人员的合法性审批，系统管理员在系统管理模块中设置用户名、操作权限和初始密码，并告知用户后，用户才可以用指定的用户名和密码登录进入系统，进行权限范围内的操作。在系统登录界面中，只有输入正确的用户名和密码，才能进入系统，进入系统后用户可随时修改自己的密码。对用户密码可提供更严格的控制功能，如首次登录系统必须修改密码、经过多长时间必须修改密码、多次登录失败锁定用户等，进一步提供系统的身份认证安全性。2.2.7.5.2 用户权限控制系统提供权限管理功能模块，系统管理员可增加、删除、修改用户、用户组，设置用户的、操作权限、数据权限。通过用户、用户组及权限管理功能，可根据机构、部门、用户类别等建立用户组，用户可以属于某个组或几个组，也可以是独立用户。通过对用户组进行授权，组中的每个用户都拥有组的所有权限，极大方便了授权管理；独立的用户可以独立授权。用户组、用户的权限可以针对机构、业务数据的范围、功能范围等进行授权，实现系统应用的数据安全。2.2.7.5.3 关键数据加密存储对于存储到系统中的一些关键敏感数据，程序对这些数据进行加密存储，使得在其它任何软件环境中都无法获取明码。2.2.7.5.4 系统操作处理日志系统对用户登录情况，如登录用户、进入时间、退出时间、操作功能项等进行自动记录；对于数据录入、数据同步、数据抽取和数据分析等应用处理的时间、数据范围、执行情况等也自动记录日志，以便出问题时跟踪追查审计。系统日志还可用于系统操作的防抵赖。2.2.7.5.5 安全管理机构和制度建设明确系统的安全管理机构/部门、人员及职责，负责管理系统安全保密工作。制定系统安全保密管理制度，并严格加以执行及监督，实现资源的合理配置和统一管理，实现统一的访问控制策略，确保系统的安全运行、安全审查。在外部安全上，企业级的防火墙可以为本系统提供一个安全的运行环境。在系统内部，本系统用户众多，机构、角色、权限各不相同，因此必须具有较高的安全性，防止用户越权访问以及窃取数据。 用户的每个动作都要经过身份验证，在身份与权限匹配的情况下才能继续执行其他操作，就可以有效实现安全性目标。操作授权：对不同使用部门使用产品的授权和其中不同级别的用户使用产品功能的授权由系统管理员分级授权，授权信息放在数据库中，操作员的每一个操作均需系统授权。3 项目管理3.1 沟通管理3.1.1 项目会议制度项目会议是服务于项目工作的，是为了更好的加强项目沟通、解决项目实施过程中存在的各种问题。每次会议都要有专人做会议记录，会议纪要的格式参见双方约定文档规范中的会议纪要模板，会后由记录人员将会议纪要分发给相关人员，并上传版本库中。项目组根据项目实际情况拟设立定期会议和不定期会议，分别阐述如下：3.1.1.1 定期会议 项目周例会 会议目标： 沟通项目状态，提出项目问题、风险和依赖条件；协调项目资源；对项目提出建议，问题的解决方法，行动计划。 日期与时间： 每周四14:00开始。 参加人员： 乙方项目经理；甲方项目经理；项目经理指定的其他成员。 主要议程及责任：更新项目状态，包括：跟踪检查项目遗留问题的解决情况；项目状态信息，时间进度表等；问题，风险，依赖条件（技术和管理）；对提出的问题，讨论和决定行动计划；乙方负责做会议记录，会后分发会议记录，将会议记录上传到版本库中，并负责下一步行动计划。3.1.1.2 不定期会议 项目状态会议 会议目标： 使项目全体人员明确目前项目的状态、问题、解决方法。 日期与时间：根据实际需要确定。 参加人员： 所有项目人员。 主要议程及责任：项目状态，存在的问题及解决方法；下阶段项目计划。 项目领导组会议 会议目标： 审核下阶段项目计划；复查项目状态和里程碑；对项目中的重大问题做出决策；协调项目各方资源；解决项目各方可能发生的重大争议。 日期与时间：根据项目进展实际情况安排。 参加人员：项目领导组成员；乙方项目经理；甲方项目经理；其他有需要参加的人员。 主要议程及责任：项目经理汇报项目状态和下阶段项目计划；项目领导讨论项目中需要决策的重大问题；乙方负责做会议记录，会后分发会议记录，将会议记录上传到版本库中，并负责下一步行动计划。 重大问题汇报会议 会议目标： 汇报项目重大问题，并讨论决定采取何行动。 日期与时间：重大问题出现时。 参加人员：问题发起人；项目经理；高层领导等。 主要议程及责任：汇报项目重大问题，找出解决方案，决定行动计划。 项目组内部讨论/沟通会议 会议目标：对项目组内部遇到的问题进行讨论，找出解决方案，并讨论决定采取何行动。 日期与时间：根据开发的状态。 参加人员：问题发起人；沟通相关人员等。 主要议程及责任：讨论出现的各种相关问题，找出解决方案，决定行动计划。3.1.2 项目状态周报制度项目组各组员每周一上午提交周报，提交到乙方项目经理，由安讯软件（上海）有限公司项目经理汇总后提交给甲方项目经理；甲方项目经理根据项目状态，总结项目周报，形成项目组的状态周报，并于每周一下午4点之前上传到版本库中的周报目录上。3.1.3 沟通手段 开会或直接交谈按需要组织会议进行沟通，或直接找相关的人进行讨论，注意记录沟通和讨论结果，重要问题讨论必须有书面会议记录。 电话或电话会议通过电话的方式进行信息沟通。对比较重要的事情，需要包括开发地点以外的人员，则需要利用电话会议的方式进行讨论，沟通。 电子邮件建立项目组电子邮件系统及与外界联系的电子邮件系统。3.2 配置管理3.2.1 配置管理原则所有的项目过程文档、代码或项目最终文档、代码的编制工作，都必须在甲方提供的配置环境中进行，所有人员都必须按甲方的配置管理制度进行工作。3.2.2 配置库管理配置库分为文档库和代码库。文档库管理项目的所有文档，而代码库管理项目的所有代码，文档及代码库进行基线化管理，按照项目阶段，对文档库和代码库打基线。经测试以及审核后提交产品库，文档与产品由甲方统一管理，未经甲方同意，不得对任何项进行任何更改。3.3 变更管理为了保证项目开发工作的相对稳定性，提高工作效率，确保开发质量。对影响项目计划的变更，制定出处理变更的规范的、统一的方法和过程，估算出因变更引起的相应的资源、费用、和时间的变化以及变更确立后，变更的发布，执行，和过程质量的控制。本项目成立变更控制委员会，一般为单数组成（甲方人数乙方1），由甲方指定人员任变更控制委员会主任;变更的审批由变更控制委员会表决决定，2/3人数通过为表决通过，变更控制委员会主任有最终否决权。如变更控制委员会无法对变更做出最后决定，由变更控制委员会主任将变更申请提交项目管理高层进行裁决。3.3.1 发起变更提出变更要求必须填写变更申请表（参见附件C“变更申请表”所附表样）。变更申请表由变更申请人填写。变更控制委员会审议变更申请的有效性和变更的必要性，决定拒绝变更申请或者要求乙方对申请的变更进行评估。3.3.2 评估变更乙方指定的评估人员要充分评估变更对项目整体计划、进度、费用及质量的影响，进行全面的评估，在五工作日内，填写变更评估表（参见附件C “变更申请表”所附表样），以书面形式提交甲方。3.3.3 审批变更变更控制委员会对变更请求进行审批，由变更控制委员会主任签署书面变更审批单，有效变更审批间必须在审批结论中明确是否通过变更申请。涉及合同变更的不在变更控制委员会审批范围内，根据购买合同规定的条款进行审批。3.3.4 执行变更乙方负责根据变更审批结果，调整相关项目计划，根据新的项目计划和项目进度，重新分配资源，对变更展开工作，并指定变更执行评估人员。变更有关执行人进行变更执行。执行完成后向变更控制委员会报告变更执行情况。3.3.5 变更执行评估变更控制委员会中乙方委员负责填报变更执行结果评估表，对执行结果进行评估跟踪，并将结果向变更控制委员会主任报告。3.4 质量管理3.4.1 质量规划 质量目标：针对数据仓库一期系统，确立以下质量目标，甲乙双方应针对以下质量目标开展质量管理活动： 保证100%满足业务需求要求的正确性与精确性 用户满意度达90%以上 质量管理原则 客户满意度优先 预防优于检查 管理层的责任 持续改进 质量保证计划：合同生效后，甲乙双方应在质量方针、质量目标、质量原则及项目范围等的前提下建立质量保证计划，明确相关干系人质量管理职责、项目质量管理任务的定义与责任人、需遵守的制度、规程、规范与标准、质量控制的方法、工具、记录与跟踪等，便以此为基础，有效地开展质量管理活动。 测试要求测试作为项目最主要的验证方式，应该得到双方的高度重视。应达到以下要求： 所有测试必须有适用的测试管理流程，得到质量控制小组的确认 在需求分析阶段，出具用户测试计划，以保证需求的可测试性 在概要设计阶段，出具集成测试计划、集成测试案例 在详细设计阶段，出具单元测试计划、单元测试案例 编码阶段所有模块必须经过单元测试通过，并出具单元测试报告，经双方项目经理确认 集成测试计划需经评审通过 集成测试必须有两轮以上的测试，每轮测试必须有集成测试报告 用户测试必须由甲方组织测试通过，出具经相关单位盖章的测试报告后，视为完成 在集成测试完成后的程序修改应有足够的回归测试工作，并得到项目质量控制小组的确认3.4.2 质量保证甲乙双方在项目实施期间应进行以下质量保证活动：1. 规则的培训与指导 双方项目经理负责组织在项目启动阶段向项目组成员做有关制度、规程、标准、工具与模板的使用培训。2. 文档管理 文档规范 文档需遵循一定的规范，由双方参照相关国际与国家标准协商制定，需经甲方项目质量控制人员审核通过。 文档标识方法必须有统一的文档编号; 文档应具有相关的定位信息与参考信息等，如：文档作者、完成日期、批准人员、批准日期、新发布与修订情况、流通清单、机密性限制等 文档批准：所有文档必须经项目经理或质量保证人员的审核通过，正式提交件必须经过相关评审认可，参见提交件管理部分。 文档的存储与检索： 存储：双方明确文档存储管理人员，正式提交文件存储应在甲方统一配置管理平台上进行。 文档的流通与检索：经审核的新文档必须按时流通到指定收件人;保证副本的有效、准确、保密性。 文档保密、包括文档的废止：严格按照文档类型的限制访问;防止非授权人员改变存储的文档;提供电子或纸质的备份;确定存储期限。3. 需求跟踪管理：甲乙双方项目人员应在项目开发过程建立需求跟踪矩阵，以对需求进行有效跟踪。4. 评审、同行评审与走查：在项目需求分析阶段，需求分析说明书在正式提交前均应进行内部评审工作。在项目设计阶段，相关技术文档均应进行至少一次的同行评审工作，双方质量保证人员负责跟踪缺陷的解决。在项目编码阶段，开发组长应每半月组织至少进行一次代码的走查的工作，开发组长负责缺陷的跟踪。5. 变更控制：双方均需遵守定义的变更控制流程，具体流程详见变更控制部分6. 版本管理：对每一阶段的产品，进入集成阶段后，所有的版本控制工作，由甲方指定配置管理员统一按有关流程进行发布，甲乙双方其他人员不得以任何形式在测试环境或生产环境进行发布工作。7. 问题跟踪：乙方负责指定专人对项目实施过程中出现的问题与缺陷进行跟踪解决，每周出具相关统计信息。8. 过程审计：质量控制小组定期对项目质量工作进行审计，双方应就审计结论进行相关整改。9. 质量汇报：双方项目经理应本着实事求是的原则，向双方管理层及时准确地汇报项目情况，保证项目的可视性。3.4.3 质量检查甲乙双方应就项目进展情况定期进行质量检查工作，保证项目按既定计划，保证质量地实施。乙方应配合甲方有关项目管理部门进行质量检查，并及时根据检查结果，进行跟踪解决。4 工期进度根据项目生命周期，我们把项目实施分为三个大的阶段，项目整体阶段里程碑工作计划如下：阶段内容估计开始日期估计结束日期第一阶段ETL需求采集2008-06-012008-06-15ETL需求细化与分析2008-06-162008-06-30用户培训2008-06-012008-06-30第二阶段LDM逻辑数据模型设计2008-07-012008-07-07ETL总体设计2008-07-082008-07-15LDM维表ETL详细设计2008-07-162008-07-22LDM事实表ETL详细设计2008-07-232008-07-31数据仓库SQL脚本及表空间等相关脚本开发2008-08-012008-08-07报表需求采集2008-07-012008-08-07报表平台用户界面定制2008-08-082008-08-22固定报表制作2008-08-082008-10-05开发测试2008-07-012008-10-05第三阶段系统集成测试2008-10-062008-10-19用户测试2008-10-202008-11-04运行准备2008-11-052008-11-12正式上线2008-11-132008-11-15项目收尾项目验收、移交2008-11-162008-11-305 附录A. 软硬件配置方案B. 开发测试工具一览表C. 变更申请表D. 安讯9系统性能白皮书