软件项目标书例文.docx

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

1、软件项目标书例文 中国外汇交易中心数据仓库一期项目建议 其次册 技术部分 安讯软件（上海）有限公司 2008年52008年X月4X日 书目 1 项目目标 1 2 技术解决方案 2 2.1 系统总体架构 2 2.1.1 逻辑架构 2 2.1.1.1 功能层面（上侧面） 2 2.1.1.2 非功能层面（右侧面） 3 2.1.2 设计层面 3 2.1.2.1 ETL数据抽取 3 2.1.2.2 报表设计 3 2.1.2.3 报表呈现 3 2.1.2.4 报表应用 3 2.1.3 物理架构 3 2.1.4 数据架构 5 2.2 系统技术实现方案 6 2.2.1 总体技术实现方案 6 2.2.2 高效的

2、ETL处理 7 2.2.2.1 ETL总体处理流程 7 2.2.2.2 数据仓库模型设计 9 2.2.3 数据质量管理 10 2.2.3.1 数据仓库对数据质量的要求 10 2.2.3.2 数据质量改进目标 10 2.2.3.3 数据质量改进方法 10 2.2.4 报表平台设计 11 2.2.4.1 敏捷的报表查询 12 2.2.4.2 先进的报表开发模式 12 2.2.4.3 高效的报表消费 12 2.2.4.4 老系统统计报表移植 12 2.2.5 认证管理 13 2.2.6 系统牢靠性及可扩展性 13 2.2.7 非功能性设计 14 2.2.7.1 性能需求 14 2.2.7.2 灾备设

3、计 15 2.2.7.3 可获性设计 17 2.2.7.4 易用性设计 17 2.2.7.5 平安性设计 18 3 项目管理 19 3.1 沟通管理 19 3.1.1 项目会议制度 19 3.1.1.1 定期会议 20 3.1.1.2 不定期会议 20 3.1.2 项目状态周报制度 21 3.1.3 沟通手段 21 3.2 配置管理 22 3.2.1 配置管理原则 22 3.2.2 配置库管理 22 3.3 变更管理 22 3.3.1 发起变更 22 3.3.2 评估变更 23 3.3.3 审批变更 23 3.3.4 执行变更 23 3.3.5 变更执行评估 23 3.4 质量管理 24 3.

4、4.1 质量规划 24 3.4.2 质量保证 25 3.4.3 质量检查 26 4 工期进度 26 5 附录 27 其次册 技术部分 1 项目目标 CFETS希望通过数据仓库系统的建设，可以有效地整合各市场业务数据，统一对信息进行利用和管理，对外供应统一的数据视图和综合决策分析支撑环境，为CFETS各部门所需的报表应用、统计分析及信息挖掘供应基础支持平台。详细建设目标如下： （1）技术目标 建立数据仓库基础架构 建立自动数据抽取转换加载（ETL）机制 建立多维分析和数据查询工具和界面已经分析报表生成和展示框架 （2）业务目标 实现一期经营分析的多维分析、查询和报表，供应CFETS各部门所需报表

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

6、统计报表 统一用户界面及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 报表应用 业务人员通过终端界面，可以运用由开发人员

7、开发和设计的报表，同时，业务人员也能同报表进行交互，检索出自己须要的数据。2.1.3 物理架构 对于本，外币不同的数据源，以及不同的物理子系统，基本的物理架构如下： 物理架构说明： A. 本外币数据库向仓库供应对应的数据 B. 仓库为对应的报表服务器供应统一的视图。C. 权限报表服务器部署到同一机器上。2.1.4 数据架构 数据流说明： A. 首先从本外币或者其他系统获得对应的数据. B. 经过ETL对数据进行加工，清洗和标准化。C. 将已经标准化和模型化的数据进入到数据仓库，或者供应须要的数据文件。D. 数据仓库对外暴露数据模型和数据视图以及sql接口。E. 数据仓库为报表管理系统和下游系统

8、供应所须要的数据 F. 报表管理系统呈现对应数据的报表。2.2 系统技术实现方案 2.2.1 总体技术实现方案 充分考虑到CFETS系统存在在本外币等多种数据源，且数据源分散，多分散子系统的状况，同时各个子系统中存在统计口径不一样，影响统一的决策和各个部门信息的一样性。在运用的过程中，会员信息维护困难，且各个系统各自维护一套对应的会员信息，导致会员维护工作量加大。数据仓库一期需求大致可以分成数据库架构的建立、ETL机制的建立、以及报表分析架构的建立和报表实施。系统可以分成数据仓库和报表系统两大部分。以下是我们建议的系统架构概念图： 系统包含一个双机组成的数据仓库，和一个双机组成的报表服务平台。

9、数据仓库和报表服务器分别带有自己的外存磁盘阵列。架构中的每个功能节点设计都含冗余度，保证系统不存在单一失败点，满意供应7x24不间断服务的要求。在系统架构不变的前提下，系统的每部分可以用不同的技术实现。比如，数据库管理系统可以运用Oracle的技术，也可以运用IBM的技术。报表技术建议运用Actuate 9。运用我们建议的应用软件，这样的系统架构会有很强的可扩展性，用户可以通过增加硬件的方式扩容，以支持越来越多的用户和应用。 总体方案通过以下步骤实现数据到可用信息的转换： 1. 通过ETL手段对不同的数据源数据进行抽取，转换，清洗，数据格式化。 2. 通过ETL转化后的数据统一进入数据仓库，形

10、成统一的数据视图。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）

11、技术架构 1) 支持全部的主流平台 2) 模块化的架构设计，可按需进行模块添加和扩展 3) 具有错误复原逻辑的功能 4) 支持并行处理 （2） 核心功能 1) 支持本地数据访问模式 2) 支持星型模式 3) 支持打包应用（例如SAP） 4) 支持基本处理（例如SQL） 5) 具有数据自动转换和清洗功能 6) 支持实时ETL和按需ETL 7) 具有自动错误预警功能 （3） 开发环境 1) 图形化界面 2) 支持吩咐行 3) 便于调试和维护 4) 具有代码版本限制功能 （4） ETL管理 1) 支持集中管理 2) 自动产生每日ETL运行报表 3) 具有ETL自动和手工调度功能 我们信任商业ETL工

12、具中INFORMATICA会是一个很好的选择，开源ETL产品Kettle则是INFORMATICA之外一个很好的备选。 2.2.2.2 数据仓库模型设计 数据建模 建模过程：（以常用会计报表为例） 1. 用户须要查看基于时间、机构和科目的报表。2. 建立以数据事实表为中心，须要时间、机构和度量作为其维度。3. 建立好如上的星型模型后，可发觉模型具有如下优点。4. 敏捷的数据查询，可基于时间查询对应的日报，月报和季报。5. 效率最优化，须要查询机构信息，则通过机构和事实表关联即可完成。2.2.3 数据质量管理 2.2.3.1 数据仓库对数据质量的要求 数据仓库对数据质量的要求总体上归纳为：数据完

13、整性，包括数据源是否完整、数据取值是否完整、维度取值是否完整等。数据精确性，包括数据源是否精确、编码映射关系是否精确、处理逻辑是否精确等。数据核对精确的推断是要么结果一样，要么不一样但缘由是可说明的。数据一样性，包括源系统之间同一数据是否一样，源数据与抽取的数据是否一样，数据仓库内部各处理环节数据是否一样等。数据逻辑合理性，主要从业务逻辑的角度推断数据是否正确，如帐目类型的金额、时长、次数的逻辑关系是否满意等。数据时效性，包括数据处理（获得、整理、加载等）的刚好性，数据异样检测的刚好性，数据处理回退的刚好性等。数据仓库服务于经营决策，经营决策依据的数据应当是全面的、真实牢靠的、有意义的。数据时

14、效性假如得不到保证，就可能延误了市场人员的分析，失去商机。从数据仓库的建设过程来看，它本身修复数据以提高数据质量的实力并不是很强，但是它能发觉生产系统存在的一些数据质量问题从而提示用户哪些数据有质量问题，将数据问题反馈到业务支撑系统中，由后者做数据修正。2.2.3.2 数据质量改进目标 数据质量改进的目标是清理、标准化、提高和匹配现有数据。通过数据整合，建立完整的、精确的、一样的统一客户视图，完善共享信息数据，并使共享信息数据服务于经营分析，为生产系统的改进供应标准。建立数据整合流程，实现流程定义、流程配置和流程管控。建立数据整合的规章制度，落实数据质量的分级负责。建立起数据整合队伍，使数据质

15、量能够得以持续改进。2.2.3.3 数据质量改进方法 数据质量限制要从技术、流程和管理三个方面进行。从技术层面上，生产系统存在的噪音数据、遗漏数据和不一样性数据，须要进行数据清洗；同时须要对源数据做稽核，如总量稽核和重量稽核。在流程层面上，对于源数据的抽取要遵从肯定的业务规则，数据的抽取和转换须要许多步骤来完成，这就须要将过程流程化，并且流程可通过配置来实现。在管理层面上，要求生产系统报送数据，根据“谁供应数据，谁负责”的原则由生产系统保证源数据的完整性、精确性、一样性、时效性。下面是我们在技术层面实行的详细做法。在ETL架构设计中我们会包括数据质量设计，将数据质量检查脚本加入到ETL流程中，

16、分为技术检查和业务规则检查。错误分严峻程度，如主键重复的就停止ETL流程，等待解决，但低级别的错误不会堵塞ETL过程。在这个过程中，全部的错误都会进行记录，最终生成数据质量检查报告。但须要明确的是，许多状况下，很多数据问题在ETL之前都无法知道，只能通过ETL之后的数据核对才能发觉，然后渐渐积累，加到ETL的规则限制中去。2.2.4 报表平台设计 建立报表查询门户，供应各类信息报表的查询，统一查询渠道，统一数据口径，统一用户管理。多个管理信息系统在报表平台上表现为一个个独立的逻辑子系统。通过报表平台，技术人员可以通过敏捷配置逻辑系统集成不同BI工具产生的异构报表资源，业务人员可以进行不同报表资

17、源的集中管理和发布，最终用户可以通过一样的展示环境获得报表信息。详细设计如下： 2.2.4.1 敏捷的报表查询 在报表的查询过程中，可以通过阅读器干脆阅读报表，同时，用户也可以通过简洁的操作，对报表进行重新订制，为了更好的提高好用性，用户可通过阅读器同报表服务器进行交互，查看到须要的报表。2.2.4.2 先进的报表开发模式 在报表的开发中，我们将采纳最先进的协同开发模式，开发人员定制业务逻辑，业务人员依据自己须要通过简洁的拖动则可形成自己须要的报表。 2.2.4.3 高效的报表消费 在运用的过程中，业务人员根本不用关切对应的后台业务逻辑，以及数据信息来源等信息，其只要依据自己的业务须要，通过简

18、洁的拖拽即可完成对报表的定制，获得到自己须要的信息。 2.2.4.4 老系统统计报表移植 对于老系统的统计报表，我们将实行重写的方式移植到统一的报表平台上面。重写后的统计报表基于新建的数据仓库，这样就统一了现存的多个统计系统，统一了统计口径，解决了统计口径不一样所造成的各个部门信息的不一样，并消退这种不一样对管理决策带来的负面影响。 老系统报表迁移的一个难点是如何保证数据仓库系统中的报表统计结果与原报表统计结果的一样性，对此要详细问题详细分析。新报表的统计结果与原报表的统计结果不一样只可能是两种状况：新报表的统计方式是错误的，造成新老报表统计结果不一样；新老报表的统计口径不一样，造成统计结果不

19、一样。假如是前一种状况，采纳正确的统计方式就能修正错误。假如是后一种状况，则须要依据业务的须要选择统计口径，使新报表能够达到业务人员的预期。 我们将会采纳严格的测试手段来保证新报表与老报表统计结果的一样性。测试的目的，是验证对于相同的输入，新老报表得到的输出结果完全一样。实际测试中，我们将采纳等价类划分以及边值分析法来设计测试用例，产生有限的测试用例来覆盖足够多的“任何状况”。对有差异的报表，我们会作进一步的数据集对比，以确定问题的根源究竟是在数据，还是报表逻辑。 2.2.5 认证管理 在对用户信息的管理中，供应以角色和用户为平安模型的统一认证机制，只有具有对应角色的用户才能访问对应的报表。2

20、.2.6 系统牢靠性及可扩展性 系统的牢靠性及可扩展性对企业级应用来说是特别重要的。我们的设计充分考虑了这两个因素。针对牢靠性，我们的设计是在系统包含一个双机组成的数据仓库，和一个双机组成的报表服务平台。数据仓库和报表服务器分别带有自己的外存磁盘阵列。架构中的每个功能节点设计都含冗余度，保证系统不存在单一失败点，满意供应7x24不间断服务的要求。采纳的这样系统架构，主机系统的维护、系统扩容、升级、系统性能统计、分析、优化以及部件更换就能够在不影响应用系统功能的前提下完成。而全部关键部件能够保证在不停顿数据共享服务的前提下供应热插拔实力。对于可扩展性，运用我们建议的报表服务平台安讯iServer

21、，系统架构会有很强的可扩展性，用户可以通过增加硬件的方式扩容，以支持越来越多的用户和应用。安讯iServer可以运行在由多台服务器组成的集群上，利用任务限制与自动负载平衡技术，将任务平均安排到各台服务器上。安讯iServer具备精彩的可扩展性，用户可以简洁的向集群中添加更多的服务器来满意更高的报表需求，而系统的性能随着服务器数量的增多呈线性增长，这方面的详细数据请参考附录D “安讯9系统性能白皮书”。在集群系统中，安讯iServer可以通过不同的故障转移模(Failover)式来保障iServer各项服务的可用性。对系统可扩展性的考虑能充分保证用户不在初期购买超出业务量需求的处理实力。随着用户

22、业务量的增长，主机系统能随时动态扩展处理实力，且系统性能是线性增长的，任何业务量的增长须要都能够通过对主机的线性扩展得到满意。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. 优化模型设计，好的模型设计能够削减

23、冗余数据量的加载和检索，以及表间关联检索，能大大提高系统数据的响应时间。2. 有效利用数据库的缓存功能，对于常常访问的数据，可将数据缓存于数据库中，削减IO， 3. 利用集群功能，合理安排负载，充分利用各主机的CPU, 内存等硬件资源。4. 优化报表设计，削减报表生成所须要的系统资源。5. 充分利用报表系统的缓存功能，把报表生成任务支配到非高峰时段。6. 充分利用报表系统的对查询的缓存功能，削减对数据源的实时访问。 2.2.7.2 灾备设计 2.2.7.2.1 灾备级别 高: 内部系统核心数据，包括全部连机和脱机数据，须要高级别的备份。 中：系统须要的资料数据。 低：与系统关系不大，间或系统须

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

25、备份。数据仓库的数据和报表服务器的报表，可以每天进行一次热备份。远程备份：供应应付灾难性的系统失败的有效方式。远程备份把数据存放到地理上的远方，以应对主机可能遇到当地灾难性的损毁。我们建议把每天的热备份数据，拷贝到远端备份存储服务器。以上的备份策略，保证在不影响系统服务的条件下，在本地和远程，都保留一份前一天的备份数据，包括数据仓库和报表服务器的数据。当地备份建议保留30天；远程备份建议保留7天。备份可以保存在磁带库、或光盘库。本地备份耗时目标是2小时；远程备份耗时目标是12小时。2.2.7.2.3 复原策略 常规的数据复原流程设计如下： 1) 重启系统的全部服务器和存储设备 2) 如必要，复

26、原系统 3) 从本地备份选取前一天的备份，或最近的备份；假如本地备份丢失，取远程备份 4) 复原数据仓库和报表系统数据 5) 复原系统服务 常规数据复原一般是在文件系统失败（包括磁盘设备失败）导致数据无法运用的情形下必需激活的程序。常规数据复原保证系统回复到前一天的状态，但也意味着当天数据的丢失。一般系统出错的复原，其实不肯定须要用到备份，我们建议应当避开运用常规数据复原，尽量考虑用其他方法把系统回复到最近的可用状态。以下我们以Oracle数据库为例，说明一下可以考虑的复原措施。数据库的复原过程分两步进行，首先将把存放在重做日志文件中的全部重做运用到数据文件，之后对重做中全部未提交的事务进行回

27、滚。数据库的复原只能在发生故障之前的数据文件上运用重做，将其复原到故障时刻，而不能将数据文件反向回滚到之前的某一个时刻。数据库的异样、错误可以分为以下几类： SQL语句失败 线程失败 实例失败 用户操作失败 存储设备失败 假如发生前三种失败，不须要人为干涉，系统会自动进行复原。对于用户操作型的失败（如误删除数据），系统实行的补救措施主要有导入最新的逻辑备份或进行到某一时间点的不完全复原。数据库引入了基于表空间的时间点复原(TSPITR)，可以单独将包含错误操作的表空间复原到指定时间，而不必对整个数据库进行不完全复原。当错误操作发觉比较刚好而且数据量不大的状况下也可以考虑运用logminer生成

28、反向SQL。 针对存储设备的失败的状况比较困难，存储设备的失败必定会使放置在其上的文件变为不行用，我们先将数据库所涉及到的文件进行一个划分，主要可分为： 数据库的系统文件，指数据库的运行文件，各种应用程序 数据库限制文件 数据库联机重做日志文件 数据文件 归档日志文件 避开第一种文件失败主要依靠系统管理员进行操作系统级的备份，当发生事故后只能依靠操作系统备份将其复原。 限制文件中记录着整个数据库的结构、每个数据文件的状况、系统SCN、检查点计数器等重要信息，在创建数据库时会让用户指定三个位置来存放限制文件，他们之间互为镜像，当其中任何一个发生故障，只需将其从ini文件中注释掉故障数据文件就可重

29、新将数据启动。当全部限制全部失效时，可以在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

30、 controlfile选项来进行复原，并运用resetlogs选项来打开数据库。 2.2.7.3 可获性设计 根据我们在2.2.1中建议的系统架构，系统包含一个双机组成的数据仓库，和一个双机组成的报表服务平台。数据仓库和报表服务器分别带有自己的外存磁盘阵列。架构中的每个功能节点设计都含冗余度，保证系统不存在单一失败点。此外，高可获性来自于我们建议的软件系统，无论是Oracle, IBM DB2, 或Actuate 9, 都支持失败转移等高级集群功能，满意供应7x24不间断服务的要求，能够保证满意任何时候系统的可获性需求。2.2.7.4 易用性设计 在软件的易用性方面，我们将充分考虑用户的体验

31、性，简洁性，高效率性为客户定制一套更适合客户须要的的系统，依据须要，我们将基于以下方面进行设计： 运用大众化WEB阅读器如IE、Firefox作为客户端的阅读工具。 用户界面友好、同时易操作。 界面操作符合阅读习惯。 界面风格，术语统一。 敏捷的页面布局，支持标签页。 合理的组织操作菜单 查询等出现错误时供应友好的提示。 供应友好的联机帮助界面。2.2.7.5 平安性设计 2.2.7.5.1 身份认证 系统供应身份认证功能。运用系统的用户必需先要经过申请审批管理流程，通过有关部门管理人员的合法性审批，系统管理员在系统管理模块中设置用户名、操作权限和初始密码，并告知用户后，用户才可以用指定的用户

32、名和密码登录进入系统，进行权限范围内的操作。在系统登录界面中，只有输入正确的用户名和密码，才能进入系统，进入系统后用户可随时修改自己的密码。对用户密码可供应更严格的限制功能，如首次登录系统必需修改密码、经过多长时间必需修改密码、多次登录失败锁定用户等，进一步供应系统的身份认证平安性。2.2.7.5.2 用户权限限制 系统供应权限管理功能模块，系统管理员可增加、删除、修改用户、用户组，设置用户的、操作权限、数据权限。通过用户、用户组及权限管理功能，可依据机构、部门、用户类别等建立用户组，用户可以属于某个组或几个组，也可以是独立用户。通过对用户组进行授权，组中的每个用户都拥有组的全部权限，极大便利

33、了授权管理；独立的用户可以独立授权。用户组、用户的权限可以针对机构、业务数据的范围、功能范围等进行授权，实现系统应用的数据平安。2.2.7.5.3 关键数据加密存储 对于存储到系统中的一些关键敏感数据，程序对这些数据进行加密存储，使得在其它任何软件环境中都无法获得明码。2.2.7.5.4 系统操作处理日志 系统对用户登录状况，如登录用户、进入时间、退出时间、操作功能项等进行自动记录；对于数据录入、数据同步、数据抽取和数据分析等应用处理的时间、数据范围、执行状况等也自动记录日志，以便出问题时跟踪追查审计。系统日志还可用于系统操作的防抵赖。2.2.7.5.5 平安管理机构和制度建设 明确系统的平安

34、管理机构/部门、人员及职责，负责管理系统平安保密工作。制定系统平安保密管理制度，并严格加以执行及监督，实现资源的合理配置和统一管理，实现统一的访问限制策略，确保系统的平安运行、平安审查。在外部平安上，企业级的防火墙可以为本系统供应一个平安的运行环境。在系统内部，本系统用户众多，机构、角色、权限各不相同，因此必需具有较高的平安性，防止用户越权访问以及窃取数据。用户的每个动作都要经过身份验证，在身份与权限匹配的状况下才能接着执行其他操作，就可以有效实现平安性目标。操作授权：对不同运用部门运用产品的授权和其中不同级别的用户运用产品功能的授权由系统管理员分级授权，授权信息放在数据库中，操作员的每一个操

35、作均需系统授权。3 项目管理 3.1 沟通管理 3.1.1 项目会议制度 项目会议是服务于项目工作的，是为了更好的加强项目沟通、解决项目实施过程中存在的各种问题。每次会议都要有专人做会议记录，会议纪要的格式参见双方约定文档规范中的会议纪要模板，会后由记录人员将会议纪要分发给相关人员，并上传版本库中。项目组依据项目实际状况拟设立定期会议和不定期会议，分别阐述如下： 3.1.1.1 定期会议 项目周例会 会议目标： 沟通项目状态，提出项目问题、风险和依靠条件；协调项目资源；对项目提出建议，问题的解决方法，行动安排。 日期与时间： 每周四14:00起先。 参与人员： 乙方项目经理；甲方项目经理；项目

36、经理指定的其他成员。 主要议程及责任：更新项目状态，包括：跟踪检查项目遗留问题的解决状况；项目状态信息，时间进度表等；问题，风险，依靠条件（技术和管理）；对提出的问题，探讨和确定行动安排；乙方负责做会议记录，会后分发会议记录，将会议记录上传到版本库中，并负责下一步行动安排。3.1.1.2 不定期会议 项目状态会议 会议目标： 使项目全体人员明确目前项目的状态、问题、解决方法。 日期与时间：依据实际须要确定。 参与人员： 全部项目人员。 主要议程及责任：项目状态，存在的问题及解决方法；下阶段项目安排。 项目领导组会议 会议目标： 审核下阶段项目安排；复查项目状态和里程碑；对项目中的重大问题做出决

37、策；协调项目各方资源；解决项目各方可能发生的重大争议。 日期与时间：依据项目进展实际状况支配。 参与人员：项目领导组成员；乙方项目经理；甲方项目经理；其他有须要参与的人员。 主要议程及责任：项目经理汇报项目状态和下阶段项目安排；项目领导探讨项目中须要决策的重大问题；乙方负责做会议记录，会后分发会议记录，将会议记录上传到版本库中，并负责下一步行动安排。 重大问题汇报会议 会议目标： 汇报项目重大问题，并探讨确定实行何行动。 日期与时间：重大问题出现时。 参与人员：问题发起人；项目经理；高层领导等。 主要议程及责任：汇报项目重大问题，找出解决方案，确定行动安排。 项目组内部探讨/沟通会议 会议目标

38、：对项目组内部遇到的问题进行探讨，找出解决方案，并探讨确定实行何行动。 日期与时间：依据开发的状态。 参与人员：问题发起人；沟通相关人员等。 主要议程及责任：探讨出现的各种相关问题，找出解决方案，确定行动安排。3.1.2 项目状态周报制度 项目组各组员每周一上午提交周报，提交到乙方项目经理，由安讯软件（上海）有限公司项目经理汇总后提交给甲方项目经理；甲方项目经理依据项目状态，总结项目周报，形成项目组的状态周报，并于每周一下午4点之前上传到版本库中的周报书目上。3.1.3 沟通手段 开会或干脆交谈 按须要组织会议进行沟通，或干脆找相关的人进行探讨，留意记录沟通和探讨结果，重要问题探讨必需有书面会

39、议记录。 电话或电话会议 通过电话的方式进行信息沟通。对比较重要的事情，须要包括开发地点以外的人员，则须要利用电话会议的方式进行探讨，沟通。 电子邮件 建立项目组电子邮件系统及与外界联系的电子邮件系统。3.2 配置管理 3.2.1 配置管理原则 全部的项目过程文档、代码或项目最终文档、代码的编制工作，都必需在甲方供应的配置环境中进行，全部人员都必需按甲方的配置管理制度进行工作。3.2.2 配置库管理 配置库分为文档库和代码库。文档库管理项目的全部文档，而代码库管理项目的全部代码，文档及代码库进行基线化管理，根据项目阶段，对文档库和代码库打基线。经测试以及审核后提交产品库，文档与产品由甲方统一管

40、理，未经甲方同意，不得对任何项进行任何更改。3.3 变更管理 为了保证项目开发工作的相对稳定性，提高工作效率，确保开发质量。对影响项目安排的变更，制定出处理变更的规范的、统一的方法和过程，估算出因变更引起的相应的资源、费用、和时间的改变以及变更确立后，变更的发布，执行，和过程质量的限制。本项目成立变更限制委员会，一般为单数组成（甲方人数乙方1），由甲方指定人员任变更限制委员会主任; 变更的审批由变更限制委员会表决确定，2/3人数通过为表决通过，变更限制委员会主任有最终推翻权。如变更限制委员会无法对变更做出最终确定，由变更限制委员会主任将变更申请提交项目管理高层进行裁决。3.3.1 发起变更 提

41、出变更要求必需填写变更申请表（参见附件C“变更申请表”所附表样）。变更申请表由变更申请人填写。变更限制委员会审议变更申请的有效性和变更的必要性，确定拒绝变更申请或者要求乙方对申请的变更进行评估。 3.3.2 评估变更 乙方指定的评估人员要充分评估变更对项目整体安排、进度、费用及质量的影响，进行全面的评估，在五工作日内，填写变更评估表（参见附件C “变更申请表”所附表样），以书面形式提交甲方。 3.3.3 审批变更 变更限制委员会对变更恳求进行审批，由变更限制委员会主任签署书面变更审批单，有效变更审批间必需在审批结论中明确是否通过变更申请。 涉及合同变更的不在变更限制委员会审批范围内，依据购买合

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

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

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

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

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

47、方其他人员不得以任何形式在测试环境或生产环境进行发布工作。7. 问题跟踪：乙方负责指定专人对项目实施过程中出现的问题与缺陷进行跟踪解决，每周出具相关统计信息。8. 过程审计：质量限制小组定期对项目质量工作进行审计，双方应就审计结论进行相关整改。9. 质量汇报：双方项目经理应本着实事求是的原则，向双方管理层刚好精确地汇报项目状况，保证项目的可视性。3.4.3 质量检查 甲乙双方应就项目进展状况定期进行质量检查工作，保证项目按既定安排，保证质量地实施。乙方应协作甲方有关项目管理部门进行质量检查，并刚好依据检查结果，进行跟踪解决。 4 工期进度 依据项目生命周期，我们把项目实施分为三个大的阶段，项目

48、整体阶段里程碑工作安排如下： 阶段 内容 估计起先日期 估计结束日期 第一阶段 ETL需求采集 2008-06-01 2008-06-15 ETL需求细化与分析 2008-06-16 2008-06-30 用户培训 2008-06-01 2008-06-30 其次阶段 LDM逻辑数据模型设计 2008-07-01 2008-07-07 ETL总体设计 2008-07-08 2008-07-15 LDM维表ETL具体设计 2008-07-16 2008-07-22 LDM事实表ETL具体设计 2008-07-23 2008-07-31 数据仓库SQL脚本及表空间等相关脚本开发 2008-08-01 2008-08-07 报表需求采集 2008-07-01 2008-08-07 报表平台