软件项目标书.doc

《软件项目标书.doc》由会员分享，可在线阅读，更多相关《软件项目标书.doc（23页珍藏版）》请在淘文阁 - 分享文档赚钱的网站上搜索。

1、软件工程标书Company Document number：WUUT-WUUY-WBBGB-BWYTT-1982GT中国外汇交易中心数据仓库一期工程建议其次册 技术局部安讯软件上海2022 年 5 月 4 日名目其次册 技术局部1 工程目标CFETS 期望通过数据仓库系统的建设，可以有效地整合各市场业务数据，统一对信息进展利用和治理，对外供给统一的数据视图和综合决策分析支撑环境，为CFETS 各部门所需的报表应用、统计分析及信息挖掘供给根底支持平台。具体建设目标如下：（1） 技术目标 建立数据仓库根底架构 建立自动数据抽取转换加载ETL机制 建立多维分析和数据查询工具和界面已经分析报表生成和呈

2、现框架（2） 业务目标 实现一期经营分析的多维分析、查询和报表，供给 CFETS 各部门所需报表 供给下游系统所需要的统计数据 供给中心内部用户以 Ad-Hoc 方式查询所需数据 将业务系统的历史和增量数据加载进入数据仓库，并转换为数据仓库的存储格式 实现用户访问的门户界面并建立相应的访问安全和权限机制 进展老系统统计报表的移植工作，保证数据仓库系统中的报表统计结果与原报表统计结果的全都性基于上述需求，安讯软件上海提出如下技术解决方案来实现本工程的技术目标和业务目标。2 技术解决方案2.1 系统总体架构2.1.1 规律架构总体规律架构如下：2.1.1.1 功能层面上侧面依据 CFETS 对应的

3、功能需求，对应的功能层面上需要建立如下功能： 数据的 ETL 数据存储 固定统计报表 统一用户界面及 Portal 认证治理2.1.1.2 非功能层面右侧面 易用性 响应性 牢靠性 扩展性 安全性2.1.2 设计层面2.1.2.1 ETL 数据抽取通过成熟的 ETL 工具，实现从不同的数据源中抽取出所需要的信息，同时通过数据的加工和格式化，对外供给应其他系统使用。2.1.2.2 报表设计当形成好统一的数据仓库后，基于该仓库模型，可进展对应的报表设计和治理，技术人员设计好根本的报表后，可供给应业务人员使用。2.1.2.3 报表呈现技术人员设计好报表模板后，通过公布到对应的效劳器据，实现对报表的呈

4、现。2.1.2.4 报表应用业务人员通过终端界面，可以使用由开发人员开发和设计的报表，同时，业务人员也能同报表进展交互，检索出自己需要的数据。2.1.3 物理架构对于本，外币不同的数据源，以及不同的物理子系统，根本的物理架构如下： 物理架构说明：A. 本外币数据库向仓库供给对应的数据B. 仓库为对应的报表效劳器供给统一的视图。C. 权限报表效劳器部署到同一机器上。2.1.4 数据架构数据流说明：A. 首先从本外币或者其他系统获得对应的数据.B. 经过 ETL 对数据进展加工，清洗和标准化。C. 将已经标准化和模型化的数据进入到数据仓库，或者供给需要的数据文件。D. 数据仓库对外暴露数据模型和数

5、据视图以及 sql 接口。E. 数据仓库为报表治理系统和下游系统供给所需要的数据F. 报表治理系统呈现对应数据的报表。2.2 系统技术实现方案2.2.1 总体技术实现方案充分考虑到 CFETS 系统存在在本外币等多种数据源，且数据源分散，多分散子系统的状况，同时各个子系统中存在统计口径不全都，影响统一的决策和各个部门信息的全都性。在使用的过程中，会员信息维护简单，且各个系统各自维护一套对应的会员信息，导致会员维护工作量加大。数据仓库一期需求大致可以分成数据库架构的建立、ETL 机制的建立、以及报表分析架构的建立和报表实施。系统可以分成数据仓库和报表系统两大局部。以下是我们建议的系统架构概念图：

6、系统包含一个双机组成的数据仓库，和一个双机组成的报表效劳平台。数据仓库和报表效劳器分别带有自己的外存磁盘阵列。架构中的每个功能节点设计都含冗余度，保证系统不存在单一失败点，满足供给 7x24 不连续效劳的要求。在系统架构不变的前提下，系统的每局部可以用不同的技术实现。比方，数据库治理系统可以使用 Oracle 的技术，也可以使用 IBM 的技术。报表技术建议使用Actuate 9。使用我们建议的应用软件，这样的系统架构会有很强的可扩展性，用户可以通过增加硬件的方式扩容，以支持越来越多的用户和应用。总体方案通过以下步骤实现数据到可用信息的转换：1. 通过 ETL 手段对不同的数据源数据进展抽取，

7、转换，清洗，数据格式化。2. 通过 ETL 转化后的数据统一进入数据仓库，形成统一的数据视图。3. 进入数据仓库的数据模型可以为报表平台供给对应的数据来源。4. 通过认证的用户可以登陆报表平台消费和设计对应的报表。2.2.2 高效的 ETL 处理2.2.2.1 ETL 总体处理流程ETL 处理流程：1. 从本币数据源或其他数据源中抽取需要的数据。2. ETL 对抽取到的数据进展必要的增量处理，生成一天的增量数据。3. ETL 对增量数据进展技术性检核、标准化、转换。4. 产生 LDM 落地数据文件。5. 落地数据文件下发到下游系统，同时进展数据入库。6. 整个 ETL 处理过程进展特别处理及监

8、控。ETL 实施我们建议承受成熟的 ETL 工具，所选 ETL 工具需要满足如下根本要求：（1） 技术架构1) 支持全部的主流平台2) 模块化的架构设计，可按需进展模块添加和扩展3) 具有错误恢复规律的功能4) 支持并行处理（2） 核心功能1) 支持本地数据访问模式2) 支持星型模式3) 支持打包应用例如 SAP4) 支持根本处理例如 SQL5) 具有数据自动转换和清洗功能6) 支持实时 ETL 和按需 ETL7) 具有自动错误预警功能（3） 开发环境1) 图形化界面2) 支持命令行3) 便于调试和维护4) 具有代码版本把握功能（4） ETL 治理1) 支持集中治理2) 自动产生每日 ETL

9、运行报表3) 具有 ETL 自动和手工调度功能我们信任商业 ETL 工具中 INFORMATICA 会是一个很好的选择，开源 ETL 产品 Kettle 则是 INFORMATICA 之外一个很好的备选。2.2.2.2 数据仓库模型设计数据建模建模过程：以常用会计报表为例1. 用户需要查看基于时间、机构和科目的报表。2. 建立以数据事实表为中心，需要时间、机构和度量作为其维度。3. 建立好如上的星型模型后，可觉察模型具有如下优点。4. 机敏的数据查询，可基于时间查询对应的日报，月报和季报。5. 效率最优化，需要查询机构信息，则通过机构和事实表关联即可完成。2.2.3 数据质量治理2.2.3.1

10、 数据仓库对数据质量的要求数据仓库对数据质量的要求总体上归纳为：数据完整性，包括数据源是否完 整、数据取值是否完整、维度取值是否完整等。数据准确性，包括数据源是否准 确、编码映射关系是否准确、处理规律是否准确等。数据核对准确的推断是要么结果全都，要么不全都但缘由是可解释的。数据全都性，包括源系统之间同一数据是否全都，源数据与抽取的数据是否全都，数据仓库内部各处理环节数据是否全都 等。数据规律合理性，主要从业务规律的角度推断数据是否正确，如帐目类型的金额、时长、次数的规律关系是否满足等。数据时效性，包括数据处理猎取、整 理、加载等的准时性，数据特别检测的准时性，数据处理回退的准时性等。数据仓库效

11、劳于经营决策，经营决策依据的数据应当是全面的、真实牢靠的、有意义的。数据时效性假设得不到保证，就可能延误了市场人员的分析，失去商机。从数据仓库的建设过程来看，它本身修复数据以提高数据质量的力量并不是很强，但是它能觉察生产系统存在的一些数据质量问题从而提示用户哪些数据有质量问题，将数据问题反响到业务支撑系统中，由后者做数据修正。2.2.3.2 数据质量改进目标数据质量改进的目标是清理、标准化、提高和匹配现有数据。通过数据整合，建立完整的、准确的、全都的统一客户视图，完善共享信息数据，并使共享信息数据效劳于经营分析，为生产系统的改进供给标准。 建立数据整合流程，实现流程定义、流程配置和流程管控。

12、建立数据整合的规章制度，落实数据质量的分级负责。建立起数据整合队伍，使数据质量能够得以持续改进。2.2.3.3 数据质量改进方法数据质量把握要从技术、流程和治理三个方面进展。从技术层面上，生产系统存在的噪音数据、遗漏数据和不全都性数据，需要进展数据清洗；同时需要对源数据做稽核，如总量稽核和重量稽核。在流程层面上，对于源数据的抽取要遵从肯定的业务规章，数据的抽取和转换需要很多步骤来完成，这就需要将过程流程化，并且流程可通过配置来实现。在治理层面上，要求生产系统报送数据，依据“谁供给数据，谁负责”的原则由生产系统保证源数据的完整性、准确性、全都性、时效性。下面是我们在技术层面实行的具体做法。在 E

13、TL 架构设计中我们会包括数据质量设计，将数据质量检查脚本参加到 ETL 流程中，分为技术检查和业务规章检查。错误分严峻程度，如主键重复的就停顿 ETL 流程，等待解决，但低级别的错误不会堵塞 ETL 过程。在这个过程中，全部的错误都会进展记录，最终生成数据质量检查报告。但需要明确的是，很多状况下，很多数据问题在 ETL 之前都无法知道，只能通过 ETL 之后的数据核对才能觉察，然后渐渐积存，加到 ETL 的规章把握中去。2.2.4 报表平台设计建立报表查询门户，供给各类信息报表的查询，统一查询渠道，统一数据口 径，统一用户治理。多个治理信息系统在报表平台上表现为一个个独立的规律子系统。通过报

14、表平台，技术人员可以通过机敏配置规律系统集成不同 BI 工具产生的异构报表资源，业务人员可以进展不同报表资源的集中治理和公布，最终用户可以通过全都的呈现环境猎取报表信息。具体设计如下：2.2.4.1 机敏的报表查询在报表的查询过程中，可以通过扫瞄器直接扫瞄报表，同时，用户也可以通过简洁的操作，对报表进展重订制，为了更好的提高有用性，用户可通过扫瞄器同报表效劳器进展交互，查看到需要的报表。2.2.4.2 先进的报表开发模式在报表的开发中，我们将承受最先进的协同开发模式，开发人员定制业务规律，业务人员依据自己需要通过简洁的拖动则可形成自己需要的报表。2.2.4.3 高效的报表消费在使用的过程中，业

15、务人员根本不用关心对应的后台业务规律，以及数据信息来源等信息，其只要依据自己的业务需要，通过简洁的拖拽即可完成对报表的定制，猎取到自己需要的信息。2.2.4.4 老系统统计报表移植对于老系统的统计报表，我们将实行重写的方式移植到统一的报表平台上面。重写后的统计报表基于建的数据仓库，这样就统一了现存的多个统计系统，统一了统计口径，解决了统计口径不全都所造成的各个部门信息的不全都，并消退这种不全都对治理决策带来的负面影响。老系统报表迁移的一个难点是如何保证数据仓库系统中的报表统计结果与原报表统计结果的全都性，对此要具体问题具体分析。报表的统计结果与原报表的统计结果不全都只可能是两种状况：报表的统计

16、方式是错误的，造成老报表统计结果不全都；老报表的统计口径不全都，造成统计结果不全都。假设是前一种状况，承受正确的统计方式就能修正错误。假设是后一种状况，则需要依据业务的需要选择统计口径，使报表能够到达业务人员的预期。我们将会承受严格的测试手段来保证报表与老报表统计结果的全都性。测试的目的，是验证对于一样的输入，老报表得到的输出结果完全全都。实际测试中，我们将承受等价类划分以及边值分析法来设计测试用例，产生有限的测试用例来掩盖足够多的“任何状况”。对有差异的报表，我们会作进一步的数据集比照，以确定问题的根源到底是在数据，还是报表规律。2.2.5 认证治理在对用户信息的治理中，供给以角色和用户为安

17、全模型的统一认证机制，只有具有对应角色的用户才能访问对应的报表。2.2.6 系统牢靠性及可扩展性系统的牢靠性及可扩展性对企业级应用来说是格外重要的。我们的设计充分考虑了这两个因素。针对牢靠性，我们的设计是在系统包含一个双机组成的数据仓库，和一个双机组成的报表效劳平台。数据仓库和报表效劳器分别带有自己的外存磁盘阵列。架构中的每个功能节点设计都含冗余度，保证系统不存在单一失败点，满足供给 7x24 不连续效劳的要求。承受的这样系统架构，主机系统的维护、系统扩容、升级、系统性能统计、分析、优化以及部件更换就能够在不影响应用系统功能的前提下完 成。而全部关键部件能够保证在不停顿数据共享效劳的前提下供给

18、热插拔力量。对于可扩展性，使用我们建议的报表效劳平台安讯 iServer，系统架构会有很强的可扩展性，用户可以通过增加硬件的方式扩容，以支持越来越多的用户和应用。安讯 iServer 可以运行在由多台效劳器组成的集群上，利用任务把握与自动负载平衡技术，将任务平均安排到各台效劳器上。安讯 iServer 具备精彩的可扩展性，用户可以简洁的向集群中添加更多的效劳器来满足更高的报表需求，而系统的性能随着效劳器数量的增多呈线性增长，这方面的具体数据请参考附录 D “安讯 9 系统性能白皮书”。在集群系统中，安讯 iServer 可以通过不同的故障转移模(Failover)式来保障 iServer 各项

19、效劳的可用性。对系统可扩展性的考虑能充分保证用户不在初期购置超出业务量需求的处理力量。随着用户业务量的增长，主机系统能随时动态扩展处理力量，且系统性能是线性增长的，任何业务量的增长需要都能够通过对主机的线性扩展得到满足。2.2.7 非功能性设计2.2.7.1 性能需求2.2.7.1.1 容量设计依据 1994-2022 年的全部交易数据总容量为 10G byte，或许每年的数据容量在800M 左右，沉着量和可扩展性和灾备等多方面综合考虑，建议每年的数据量安排在左右。2.2.7.1.2 响应设计高的响应能给用户带来效率上的提升 ，加快了工作效率，削减了等待时间，同时加快了系统的处理效率，我们将通

20、过以下几方面手段来保证用户得到高质量的响应：1. 优化模型设计，好的模型设计能够削减冗余数据量的加载和检索，以及表间关联检索，能大大提高系统数据的响应时间。2. 有效利用数据库的缓存功能，对于经常访问的数据，可将数据缓存于数据库中，削减 IO，3. 利用集群功能，合理安排负载，充分利用各主机的 CPU, 内存等硬件资源。4. 优化报表设计，削减报表生成所需要的系统资源。5. 充分利用报表系统的缓存功能，把报表生成任务安排到非顶峰时段。6. 充分利用报表系统的对查询的缓存功能，削减对数据源的实时访问。2.2.7.2 灾备设计2.2.7.2.1 灾备级别 高: 内部系统核心数据，包括全部连机和脱机

21、数据，需要高级别的备份。 中：系统需要的资料数据。 低：与系统关系不大，间或系统需要使用到的数据。由此可见，对于高，中级别的数据，需要进展对应的备份。2.2.7.2.2 备份策略为了保障核心数据和重要数据的完整性和全都性，我们将供给对应的磁盘备份、联机备份和远程备份功能：磁盘备份：通过镜像 (mirrored) 磁盘矩阵, 对每一个写到磁盘的字节，作实时的镜像备份，削减磁盘机出错的几率。磁盘备份一旦设定，由设备实现，无需人工干预。联机备份：供给 24*365 天的备份机制，用户可以基于调度来运行备份，可以基于系统运行的热备份。我们设计方案中使用的 Oracle 10g 或 IBM DB 2 数

22、据库， 都支持热备份；Actuate 9 的报表效劳器 iServer , 也支持联机热备份。 数据仓库的数据和报表效劳器的报表，可以每天进展一次热备份。远程备份：供给应付灾难性的系统失败的有效方式。远程备份把数据存放到地理上的远方，以应对主机可能遇到当地灾难性的损毁。我们建议把每天的热备份数据，拷贝到远端备份存储效劳器。以上的备份策略，保证在不影响系统效劳的条件下，在本地和远程，都保存一份前一天的备份数据，包括数据仓库和报表效劳器的数据。当地备份建议保存 30 天；远程备份建议保存 7 天。备份可以保存在磁带库、或光盘库。本地备份耗时目标是 2 小时；远程备份耗时目标是 12 小时。2.2.

23、7.2.3 恢复策略常规的数据恢复流程设计如下：1) 重启系统的全部效劳器和存储设备2) 如必要，恢复系统3) 从本地备份选取前一天的备份，或最近的备份；假设本地备份丧失，取远程备份4) 恢复数据仓库和报表系统数据5) 恢复系统效劳常规数据恢复一般是在文件系统失败包括磁盘设备失败导致数据无法使用的情形下必需激活的程序。常规数据恢复保证系统回复到前一天的状态，但也意味着当天数据的丧失。一般系统出错的恢复，其实不肯定需要用到备份，我们建议应当避开使用常规数据恢复，尽量考虑用其他方法把系统回复到最近的可用状态。以下我们以 Oracle 数据库为例，说明一下可以考虑的恢复措施。数据库的恢复过程分两步进

24、展，首先将把存放在重做日志文件中的全部重做运用到数据文件，之后对重做中全部未提交的事务进展回滚。数据库的恢复只能在发生故障之前的数据文件上运用重做，将其恢复到故障时刻，而不能将数据文件反向回滚到之前的某一个时刻。数据库的特别、错误可以分为以下几类： SQL 语句失败 线程失败 实例失败 用户操作失败 存储设备失败假设发生前三种失败，不需要人为干预，系统会自动进展恢复。对于用户操作型的失败如误删除数据，系统实行的补救措施主要有导入最的规律备份或进展到某一时间点的不完全恢复。数据库引入了基于表空间的时间点恢复(TSPITR)， 可以单独将包含错误操作的表空间恢复到指定时间，而不必对整个数据库进展不

25、完全恢复。当错误操作觉察比较准时而且数据量不大的状况下也可以考虑使用logminer 生成反向 SQL。针对存储设备的失败的状况比较简单，存储设备的失败必定会使放置在其上的文件变为不行用，我们先将数据库所涉及到的文件进展一个划分，主要可分为： 数据库的系统文件，指数据库的运行文件，各种应用程序 数据库把握文件 数据库联机重做日志文件 数据文件 归档日志文件避开第一种文件失败主要依靠系统治理员进展操作系统级的备份，当发生事故后只能依靠操作系统备份将其恢复。把握文件中记录着整个数据库的构造、每个数据文件的状况、系统 SCN、检查点计数器等重要信息，在创立数据库时会让用户指定三个位置来存放把握文件，

26、他们之间互为镜像，当其中任何一个发生故障，只需将其从 ini 文件中注释掉故障数据文件就可重将数据启动。当全部把握全部失效时，可以在 Nomount 模式下执行 create controlfile 来重生成把握文件，但必需供给 redo log，data file，文件名和地址以及 MAXLOGFILES，MAXDATAFILES，MAXINSTANCES 等信息。如果失败之前运行过 alter database backup controlfile to trace 或 alter database backup controlfile to xxx对把握文件作备份，恢复时可使用生成的脚原

27、来重建或用备份文件掩盖，假设使用了旧的把握文件在恢复时要使用 recover xxx using backup controlfile 选项来进展恢复，并使用 resetlogs 选项来翻开数据库。2.2.7.3 可获性设计系统包含一个双机组成的数据仓库，和一个双机组成的报表效劳平台。数据仓库和报表效劳器分别带有自己的外存磁盘阵列。架构中的每个功能节点设计都含冗余度，保证系统不存在单一失败点。 此外，高可获性来自于我们建议的软件系统，无论是 Oracle, IBM DB2, 或 Actuate 9, 都支持失败转移等高级集群功能，满足供给 7x24 不连续效劳的要求，能够保证满足任何时候系统的

28、可获性需求。2.2.7.4 易用性设计在软件的易用性方面，我们将充分考虑用户的体验性，简洁性，高效率性为客户定制一套更适合客户需要的的系统，依据需要，我们将基于以下方面进展设计： 使用群众化 WEB 扫瞄器如 IE、Firefox 作为客户端的扫瞄工具。 用户界面友好、同时易操作。 界面操作符合扫瞄习惯。 界面风格，术语统一。 机敏的页面布局，支持标签页。 合理的组织操作菜单 查询等消灭错误时供给友好的提示。 供给友好的联机帮助界面。2.2.7.5 安全性设计2.2.7.5.1 身份认证系统供给身份认证功能。使用系统的用户必需先要经过申请审批治理流程，通过有关部门治理人员的合法性审批，系统治理

29、员在系统治理模块中设置用户名、操作权限和初始密码，并告知用户后，用户才可以用指定的用户名和密码登录进入系统，进展权限范围内的操作。在系统登录界面中，只有输入正确的用户名和密码，才能进入系统，进入系统后用户可随时修改自己的密码。对用户密码可供给更严格的把握功能，如首次登录系统必需修改密码、经过多长时间必需修改密码、屡次登录失败锁定用户等，进一步供给系统的身份认证安全性。2.2.7.5.2 用户权限把握系统供给权限治理功能模块，系统治理员可增加、删除、修改用户、用户组， 设置用户的、操作权限、数据权限。通过用户、用户组及权限治理功能，可依据机构、部门、用户类别等建立用户组，用户可以属于某个组或几个

30、组，也可以是独立用户。通过对用户组进展授权， 组中的每个用户都拥有组的全部权限，极大便利了授权治理；独立的用户可以独立授权。用户组、用户的权限可以针对机构、业务数据的范围、功能范围等进展授 权，实现系统应用的数据安全。2.2.7.5.3 关键数据加密存储对于存储到系统中的一些关键敏感数据，程序对这些数据进展加密存储，使得在其它任何软件环境中都无法猎取明码。2.2.7.5.4 系统操作处理日志系统对用户登录状况，如登录用户、进入时间、退出时间、操作功能项等进展自动记录；对于数据录入、数据同步、数据抽取和数据分析等应用处理的时间、数据范围、执行状况等也自动记录日志，以便出问题时跟踪追查审计。系统日

31、志还可用于系统操作的防抵赖。2.2.7.5.5 安全治理机构和制度建设明确系统的安全治理机构/部门、人员及职责，负责治理系统安全保密工作。 制定系统安全保密治理制度，并严格加以执行及监视，实现资源的合理配置和统一治理，实现统一的访问把握策略，确保系统的安全运行、安全审查。在外部安全上，企业级的防火墙可以为本系统供给一个安全的运行环境。在系统内部，本系统用户众多，机构、角色、权限各不一样，因此必需具有较高的安全性，防止用户越权访问以及窃取数据。 用户的每个动作都要经过身份验证，在身份与权限匹配的状况下才能连续执行其他操作，就可以有效实现安全性目标。操作授权：对不同使用部门使用产品的授权和其中不同

32、级别的用户使用产品功能的授权由系统治理员分级授权，授权信息放在数据库中，操作员的每一个操作均需系统授权。3 工程治理3.1 沟通治理3.1.1 工程会议制度工程会议是效劳于工程工作的，是为了更好的加强工程沟通、解决工程实施过程中存在的各种问题。每次会议都要有专人做会议记录，会议纪要的格式参见双方商定文档标准中的会议纪要模板，会后由记录人员将会议纪要分发给相关人员，并上传版本库中。工程组依据工程实际状况拟设立定期会议和不定期会议，分别阐述如下：3.1.1.1 定期会议 工程周例会 会议目标： 沟通工程状态，提出工程问题、风险和依靠条件；协调工程资源；对工程提出建议，问题的解决方法，行动打算。 日

33、期与时间： 每周四 14:00 开头。 参与人员： 乙方工程经理；甲方工程经理；工程经理指定的其他成员。 主要议程及责任：更工程状态，包括：跟踪检查工程遗留问题的解决状况；工程状态信息，时间进度表等；问题，风险，依靠条件技术和管理；对提出的问题，争辩和打算行动打算；乙方负责做会议记录，会后分发会议记录，将会议记录上传到版本库中，并负责下一步行动打算。3.1.1.2 不定期会议 工程状态会议 会议目标： 使工程全体人员明确目前工程的状态、问题、解决方法。 日期与时间：依据实际需要确定。 参与人员： 全部工程人员。 主要议程及责任：工程状态，存在的问题及解决方法；下阶段工程打算。 工程领导组会议

34、会议目标： 审核下阶段工程打算；复查工程状态和里程碑；对工程中的重大问题做出决策；协调工程各方资源；解决工程各方可能发生的重大争议。 日期与时间：依据工程进展实际状况安排。 参与人员：工程领导组成员；乙方工程经理；甲方工程经理；其他有需要参与的人员。 主要议程及责任：工程经理汇报工程状态和下阶段工程打算；工程领导争辩工程中需要决策的重大问题；乙方负责做会议记录，会后分发会议记录，将会议记录上传到版本库中，并负责下一步行动打算。 重大问题汇报会议 会议目标： 汇报工程重大问题，并争辩打算实行何行动。 日期与时间：重大问题消灭时。 参与人员：问题发起人；工程经理；高层领导等。 主要议程及责任：汇报

35、工程重大问题，找出解决方案，打算行动打算。 工程组内部争辩/沟通会议 会议目标：对工程组内部遇到的问题进展争辩，找出解决方案，并争辩打算实行何行动。 日期与时间：依据开发的状态。 参与人员：问题发起人；沟通相关人员等。 主要议程及责任：争辩消灭的各种相关问题，找出解决方案，打算行动打算。3.1.2 工程状态周报制度工程组各组员每周一上午提交周报，提交到乙方工程经理，由安讯软件上海工程经理汇总后提交给甲方工程经理；甲方工程经理依据工程状 态，总结工程周报，形成工程组的状态周报，并于每周一下午 4 点之前上传到版本库中的周报名目上。3.1.3 沟通手段 开会或直接交谈按需要组织会议进展沟通，或直接

36、找相关的人进展争辩，留意记录沟通和争辩结果，重要问题争辩必需有书面会议记录。 或 会议通过 的方式进展信息沟通。比照较重要的事情，需要包括开发地点以外的人员，则需要利用 会议的方式进展争辩，沟通。电子邮件建立工程组电子邮件系统及与外界联系的电子邮件系统。3.2 配置治理3.2.1 配置治理原则全部的工程过程文档、代码或工程最终文档、代码的编制工作，都必需在甲方供给的配置环境中进展，全部人员都必需按甲方的配置治理制度进展工作。3.2.2 配置库治理配置库分为文档库和代码库。文档库治理工程的全部文档，而代码库治理工程的全部代码，文档及代码库进展基线化治理，依据工程阶段，对文档库和代码库打基线。经测

37、试以及审核后提交产品库，文档与产品由甲方统一治理，未经甲方同 意，不得对任何项进展任何更改。3.3 变更治理为了保证工程开发工作的相对稳定性，提高工作效率，确保开发质量。对影响工程打算的变更，制定出处理变更的标准的、统一的方法和过程，估算出因变更引起的相应的资源、费用、和时间的变化以及变更确立后，变更的公布，执行，和过程质量的把握。本工程成立变更把握委员会，一般为单数组成甲方人数乙方1，由甲方指定人员任变更把握委员会主任;变更的审批由变更把握委员会表决打算，2/3 人数通过为表决通过，变更把握委员会主任有最终拒绝权。如变更把握委员会无法对变更做出最终打算，由变更把握委员会主任将变更申请提交工程

38、治理高层进展裁决。3.3.1 发起变更提出变更要求必需填写变更申请表参见附件 C“变更申请表”所附表样。变更申请表由变更申请人填写。变更把握委员会审议变更申请的有效性和变更的必要性，打算拒绝变更申请或者要求乙方对申请的变更进展评估。3.3.2 评估变更乙方指定的评估人员要充分评估变更对工程整体打算、进度、费用及质量的影响，进展全面的评估，在五工作日内，填写变更评估表参见附件 C “变更申请表”所附表样，以书面形式提交甲方。3.3.3 审批变更变更把握委员会对变更恳求进展审批，由变更把握委员会主任签署书面变更审批单，有效变更审批间必需在审批结论中明确是否通过变更申请。涉及合同变更的不在变更把握委

39、员会审批范围内，依据购置合同规定的条款进展审批。3.3.4 执行变更乙方负责依据变更审批结果，调整相关工程打算，依据的工程打算和工程进度，重安排资源，对变更开放工作，并指定变更执行评估人员。变更有关执行人进展变更执行。执行完成后向变更把握委员会报告变更执行状况。3.3.5 变更执行评估变更把握委员会中乙方委员负责填报变更执行结果评估表，对执行结果进展评估跟踪，并将结果向变更把握委员会主任报告。3.4 质量治理3.4.1 质量规划 质量目标：针对数据仓库一期系统，确立以下质量目标，甲乙双方应针对以下质量目标开展质量治理活动： 保证 100%满足业务需求要求的正确性与准确性 用户满足度达 90%以

40、上 质量治理原则 客户满足度优先 预防优于检查 治理层的责任 持续改进 质量保证打算：合同生效后，甲乙双方应在质量方针、质量目标、质量原则及工程范围等的前提下建立质量保证打算，明确相关干系人质量治理职责、工程质量治理任务的定义与责任人、需遵守的制度、规程、标准与标准、质量把握的方法、工具、记录与跟踪等，便以此为根底，有效地开展质量治理活动。 测试要求测试作为工程最主要的验证方式，应当得到双方的高度重视。应到达以下要求： 全部测试必需有适用的测试治理流程，得到质量把握小组确实认 在需求分析阶段，出具用户测试打算，以保证需求的可测试性 在概要设计阶段，出具集成测试打算、集成测试案例 在具体设计阶段

41、，出具单元测试打算、单元测试案例 编码阶段全部模块必需经过单元测试通过，并出具单元测试报告，经双方工程经理确认 集成测试打算需经评审通过 集成测试必需有两轮以上的测试，每轮测试必需有集成测试报告 用户测试必需由甲方组织测试通过，出具经相关单位盖章的测试报告后，视为完成 在集成测试完成后的程序修改应有足够的回归测试工作，并得到工程质量控制小组确实认3.4.2 质量保证甲乙双方在工程实施期间应进展以下质量保证活动：1. 规章的培训与指导双方工程经理负责组织在工程启动阶段向工程组成员做有关制度、规程、标准、工具与模板的使用培训。2. 文档治理 文档标准 文档需遵循肯定的标准，由双方参照相关国际与国家

42、标准协商制定，需经甲方工程质量把握人员审核通过。 文档标识方法必需有统一的文档编号; 文档应具有相关的定位信息与参考信息等，如：文档作者、完成日期、批准人员、批准日期、公布与修订状况、流通清单、机密性限制等 文档 全部文档必需经工程经理或质量保证人员的审核通过，正式提交件必需经过相关评审认可，参见提交件治理局部。 文档的存储与检索： 存储：双方明确文档存储治理人员，正式提交文件存储应在甲方统一配置治理平台上进展。 文档的流通与检索：经审核的文档必需按时流通到指定收件人;保证副本的有效、准确、保密性。 文档保密、包括文档的废止：严格依据文档类型的限制访问;防止非授权人员转变存储的文档;供给电子或

43、纸质的备份;确定存储期限。3. 需求跟踪治理：甲乙双方工程人员应在工程开发过程建立需求跟踪矩阵，以对需求进展有效跟踪。4. 评审、同行评审与走查：在工程需求分析阶段，需求分析说明书在正式提交前均应进展内部评审工作。在工程设计阶段，相关技术文档均应进展至少一次的同行评审工作，双方质量保证人员负责跟踪缺陷的解决。在工程编码阶段，开发组长应每半月组织至少进展一次代码的走查的工作，开发组长负责缺陷的跟踪。5. 变更把握：双方均需遵守定义的变更把握流程，具体流程详见变更把握局部6. 版本治理：对每一阶段的产品，进入集成阶段后，全部的版本把握工作，由甲方指定配置治理员统一按有关流程进展公布，甲乙双方其他人

44、员不得以任何形式在测试环境或生产环境进展公布工作。7. 问题跟踪：乙方负责指定专人对工程实施过程中消灭的问题与缺陷进展跟踪解决，每周出具相关统计信息。8. 过程审计：质量把握小组定期对工程质量工作进展审计，双方应就审计结论进展相关整改。9. 质量汇报：双方工程经理应本着实事求是的原则，向双方治理层准时准确地汇报工程状况，保证工程的可视性。3.4.3 质量检查甲乙双方应就工程进展状况定期进展质量检查工作，保证工程按既定打算，保证质量地实施。乙方应协作甲方有关工程治理部门进展质量检查，并准时依据检查结果，进展跟踪解决。4 工期进度阶段阶 第段 一内容ETL 需求采集ETL 需求细化与分析估量开头日

45、期2022-06-012022-06-16估量完毕日期2022-06-152022-06-30依据工程生命周期，我们把工程实施分为三个大的阶段，工程整体阶段里程碑工作打算如下：用户培训2022-06-012022-06-30第LDM 规律数据模型设计2022-07-012022-07-07系统集成测试2022-10-062022-10-19用户测试2022-10-202022-11-04段运行预备2022-11-052022-11-12正式上线2022-11-132022-11-15工程收工程验收、移交2022-11-162022-11-30尾二阶段ETL 总体设计LDM 维表 ETL 具体设计LDM 事实表 ETL 具体设计数据仓库 SQL 脚本及表空间等相关脚本开发报表需求采集报表平台用户界面定制固定报表制作开发测试2022-07-082022-07-162022-07-232022-07-152022-07-22