软件项目目标怎么写项目目标怎么写

软件项目标书

中国外汇交易中心数据仓库一期项目建议

第二册技术部分

安讯软件（上海）有限公司

xxxx年xx月xx日

1 项目目标 ...................................................................................................................................... 4 2 技术解决方案 .............................................................................................................................. 5

2.1 系统总体架构................................................................................................................... 5

2.1.1 逻辑架构 ................................................................................................................ 5

2.1.1.1 功能层面（上侧面） ................................................................................ 5 2.1.1.2 非功能层面（右侧面） ............................................................................ 6 2.1.2 设计层面 ................................................................................................................ 6

2.1.2.1 ETL数据抽取 ............................................................................................ 6 2.1.2.2 报表设计 .................................................................................................... 6 2.1.2.3 报表展现 .................................................................................................... 6 2.1.2.4 报表应用 .................................................................................................... 6 2.1.3 物理架构 ................................................................................................................ 6 2.1.4 数据架构 ................................................................................................................ 8 2.2 系统技术实现方案........................................................................................................... 9

2.2.1 总体技术实现方案 ................................................................................................ 9 2.2.2 高效的ETL处理 ................................................................................................. 10

2.2.2.1 ETL总体处理流程 .................................................................................. 10 2.2.2.2 数据仓库模型设计 .................................................................................. 12 2.2.3 数据质量管理 ...................................................................................................... 13

2.2.3.1 数据仓库对数据质量的要求 .................................................................. 13 2.2.3.2 数据质量改进目标 .................................................................................. 13 2.2.3.3 数据质量改进方法 .................................................................................. 13 2.2.4 报表平台设计 ...................................................................................................... 14

2.2.4.1 灵活的报表查询 ...................................................................................... 15 2.2.4.2 先进的报表开发模式 .............................................................................. 15 2.2.4.3 高效的报表消费 ...................................................................................... 15 2.2.4.4 老系统统计报表移植 .............................................................................. 15 2.2.5 认证管理 .............................................................................................................. 16 2.2.6 系统可靠性及可扩展性 ...................................................................................... 16

2.2.7 非功能性设计 ...................................................................................................... 17

2.2.7.1 性能需求 .................................................................................................. 17 2.2.7.2 灾备设计 .................................................................................................. 18 2.2.7.3 可获性设计 .............................................................................................. 20 2.2.7.4 易用性设计 .............................................................................................. 20 2.2.7.5 安全性设计 .............................................................................................. 21

3 项目管理 .................................................................................................................................... 22

3.1 沟通管理 ........................................................................................................................ 22

3.1.1 项目会议制度 ...................................................................................................... 22

3.1.1.1 定期会议 .................................................................................................. 23 3.1.1.2 不定期会议 .............................................................................................. 23 3.1.2 项目状态周报制度 .............................................................................................. 24 3.1.3 沟通手段 .............................................................................................................. 24 3.2 配置管理 ........................................................................................................................ 25

3.2.1 配置管理原则 ...................................................................................................... 25 3.2.2 配置库管理 .......................................................................................................... 25 3.3 变更管理 ........................................................................................................................ 25

3.3.1 发起变更 .............................................................................................................. 25 3.3.2 评估变更 .............................................................................................................. 26 3.3.3 审批变更 .............................................................................................................. 26 3.3.4 执行变更 .............................................................................................................. 26 3.3.5 变更执行评估 ...................................................................................................... 26 3.4 质量管理 ........................................................................................................................ 27

3.4.1 质量规划 .............................................................................................................. 27 3.4.2 质量保证 .............................................................................................................. 28 3.4.3 质量检查 .............................................................................................................. 29

4 工期进度 .................................................................................................................................... 29

第二册技术部分

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和按需ETL 7) 具有自动错误预警功能（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 先进的报表开发模式

在报表的开发中，我们将采用最先进的协同开发模式，开发人员定制业务逻辑，业务人员根据自己需要通过简单的拖动则可形成自己需要的报表。

设计Report模板并发布至服务器

Business

Informationobjects

设计报表

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 工期进度

根据项目生命周期，我们把项目实施分为三个大的阶段，项目整体阶段里程碑工作计划如下：

软件开发人员的简历项目经验怎么写？

许多学习软件开发的学员不知道如何在个人简历中如何填写“项目经验”或“项目描述”，最近接触的一些学习Java的学生在简历中，往往项目经验及描述都只能寥寥几笔完事，这样的简历肯定是不吸引招聘企业HR的。

那么软件开发人员如何才能写好个人简历中的项目经验及描述呢？

首先你要知道招聘企业想从你的项目经验里的描述中获得什么信息？他们真的在乎你的项目用在了那一行业？为这个行业提高了多少效率吗？实际上对方需要知道的无外乎以下几点：

1、你在实际开发中用过什么技术、用了多久；

2、你在项目组中的位置、是否能独立解决问题；

3、你的业务知识与团队合作能力等。

技术显然是最重要的，但你需要非常用心的描述整个项目的技术框架，让招聘人员知道你从对宏观上架构很熟悉，然后突出你解决的技术问题。

下面我们参考一种项目描述：

“本项目采用JSP + JavaBean + Struts开发，采用了MVC模式，表现层与业务层分离，易于维护、扩展”

感觉如何？其实觉得很糟糕，短短的几句话中居然包含了大量的重复，使用Struts了难道能不用JSP吗？难道能不MVC吗？可维护性本该是描述的重点，可是只有简单的一句“表现层与业务层分离”……

下面是我写的一段项目描述（虚拟的）：

“本项目结构上分为表现层、业务层和数据访问层，层次间的依赖关系自下到上。采用的技术有Struts，Spring，Hibernate，Log4J，JDom等。其中表现层采用Struts框架开发；业务层封装业务流程，为适应业务的变更，每一业务模块均有专门的接口及实现类，利用Spring的IoC功能将实现类注入给表现层的Action；数据访问层借助于Hibernate实现，代码简洁且可适应不同的数据库。事务部分利用Spring的声明式事务管理。为提高性能，采用Servlet Filter实现了缓存代理”

这段项目经验描述简单的勾划出了系统的结构，也表现出你非常熟悉Struts，Spring，Hiberante这几种技术。

同时可以注意到，其中一些重要环节描述的十分简略，比如事务、缓存代理，这其实是故意的。

面试的时候很多人都怕对方突然问一个自己没有准备的问题，往往缺乏应变能力。一方面你需要多进行专门的练习，另一方面要知道面试时你并不总是被动的，等待对方发问。

如果你给对方的只是一份普普通通的简历，里面只提到了大家都会提及的JSP，Struts，那你只好等待对方随机的问题了。但是如果你的项目经验和描述像刚才那么写，对方就很可能会问你到底是如何在Spring中应用事务、如何使用缓存代理（如果对方是技术人员的话），这时你已经变被动为主动啦……当然，前提是你写的这些技术要点一定是自己掌握的，事先已经想好如何表达的！这只是一点面试技巧里面的内容。

总之写好个人简历中项目经验中项目描述也是求职方法的一种。

软件项目经理怎么做？

1 项目经理个人品质

我们这里说说的个人品质，不是指人品，而是指作为项目管理者所应该具备的品质。比如不能冲动、要稳重、不能好发脾气，懂得妥协的艺术等等。

不能冲动，稳重，这牵涉到个人的性格问题，但在做项目的过程中，应尽量避免这些因素对项目的影响，比如，有了问题，应先通过分析确定问题的原因，再根据原因确定出解决问题的办法。而不是冲动的去做某个决定。作为任何一个人来讲，都希望能和一个心理素质好的人打交道，这样他们心里有谱，比较容易建立彼此之间的信任关系。永远要记住，所有的问题不是通过发脾气所能解决的，发脾气也解决不了任何的问题。

在项目管理或者项目组成员管理时，很多时候需要项目经理做为协调人的身份出现，所谓协调也就是一个妥协的艺术，切忌毫无原则的让步，也不能不负责任的抗拒。原则问题决不能妥协，非原则性问题可以在一定的基础上进行妥协，以方便管理和沟通。当然作为管理者来讲，还有很多品质需要具备，比如：

 具备领导魅力

 充分展现自己的能力

 凡事以身作则

 信守诺言

 学会比用户和下属更老练

2 项目经理和项目关系的描述

项目经理和项目的关系，听起来很奇怪，其实很多项目没有做好，就是因为没有把这个关系搞清楚。

作为项目经理，能接到一个项目，表明公司很信任你。从工作的角度上看作项目是工作的一部分，是为了赚钱，但其实完成项目也是为了实现自己在公司和社会中的价值。也就是给用户创造一个产品的同时，给自己创造了一个认识世界和接触世界的机会。每一个项目都有很多需要学习的地方，尤其是定制开发的项目。每当看到自己的产品给用

户带来了应有的效果的时候，那种感觉不是钱所能衡量的。所以说的更明白一点，项目就像自己种的一颗葡萄树，如果成长的不好，不但结不出好的果子，可能连乘凉的目的都达不到。

我觉得项目经理对于项目，应该把它看成自己的孩子，想尽一切办法让它成长好，而且要迅速的成长起来，而不是其他的想法，比如怎么样减少工作量，怎么样糊弄用户和公司。所以归结到一点，对于项目必须有高度的责任心。

3 项目经理和用户的关系描述

项目经理和用户的关系，说起来很复杂，因为大家站的角度不同，所代表的利益放不同，所以很多时候可能搞成水火不相容的关系，这个往往在不成功的项目中尤为明显。

那么项目经理和客户的关系应该是怎么样的呢？很多用户都说，找一个软件公司做项目其实和赌博没有多大区别，说得对也说的不对，对的一部分呢，我认为软件本身就是个良心活，我们可以把软件做的很好，也可以在别人不知道的情况下糊弄用户和公司。所以说，如果用户挑到一个不负责任的，那么就是赌博输了。

很多人也说，软件公司和用户的关系是结亲家的关系，我比较认同这个观点。软件公司和用户就好像是双方父母，项目就好像是两家的儿女。这样描述的话，就说明一个问题，大家的共同目标是一样的。

既然大家的共同目标是一致的，那么问题就好办多了。往往在项目进行的过程中大家会因为一些问题有不同的看法，比如项目经理认为用户不懂系统，或者不懂技术，只是给项目开发找不应有的障碍。而用户则认为项目人员不了解他们的需求，只是想偷懒等等。如果真的是这种情况，那么问题就比较严重了，因为彼此都感觉对方对于项目的出发点有问题了。

作为项目经理一定要仔细的了解和分析用户提出的问题，首先要站在用户的角度分析和处理问题，其次要站在项目的角度去看问题，比如用户提出的问题是否能促进项目更好更快的完成。

所以项目经理和用户是一个紧密合作完成项目的关系。

4 项目经理和领导的关系

总的来说，项目经理对于领导来说，是公司委派的负责完成项目的人员。所以在项目进行的过程当中，领导需要及时准确地了解项目的进展情况，以及项目进行过程中出现的问题。

对于一个项目来讲，要顺利地完成，中间需要商务上的协调，需要开发人员努力的工作，需要客户很好的配合，所以单单凭开发人员是保证不了项目的顺利进行的。这样对于领导来讲，就需要及时地了解项目进行过程中出现的各种问题，以便和用户协调有关问题。

从另一个角度讲，作为项目经理，就需要实事求是地反映项目进行过程中的各种问题，以便领导把握，是不是需要和用户就有关问题进行协调。不能对项目中出现的问题隐瞒，或者不负责任的草率处理。

领导是什么？对于项目经理来说，领导可以理解为一种资源，而且是很有效的资源。公司内的、公司外的资源的调动，有时候领导的出马，会起到意想不到的效果。但是，项目经理切忌把领导当牛马使用，也不要当用户和领导之间简单的传声筒。要知道，领导是资源，而不是工具。

5 项目经理和项目组成员关系的描述

对于项目经理来讲，项目组成员就是完成项目具体工作的主体，项目经理就是管理项目组成员，按照计划顺利完成项目的开发工作。

项目经理对项目组成员负有领导和管理的职能。

 项目经理需要对项目所用到的一切技术向项目组成员阐述清楚

 项目经理需要对项目组成员阐释清楚项目的目标

 项目经理需要对项目组成员在项目中所担任的角色，或者工作阐释清楚，并保证项目组成员清楚地理解了每个人所需要达到的工作目标

 项目经理需要根据项目的具体情况，对项目的计划、质量、进度做一个详细的符合实际的计划，并能清楚地分配工作到人

 项目经理需要根据已有的计划，对每一个成员的工作进行监督、核查

 项目经理有责任对每一个组成员的工作进行分析和评价

 项目经理有责任对每一个组员工作过程中遇见的各种问题掌握，并协助项目组

成员处理

 项目经理需要向项目管理部门负责，和QA、CM等项目相关人员紧密配合，

完成项目度量，控制项目进程，因此，也需要对项目组成员贯彻质量意识、成本意识，以及传授自我管理和计划的能力。

项目组成员对于项目经理所分配的任务要及时地完成，并对所负责的工作的进度以及质量负有直接的责任

 理解项目有遵循的技术路线

 理解项目要达到的整体目标

 理解项目的整体的进度和项目质量要求

 对于工作中所遇到的各种问题，如果处理不了或者有难度，或者有不明白的地

方，需要及时地向项目经理汇报，并应跟踪项目经理对问题的回复

 有义务接受项目经理和项目其他干系人对所做工作进行监督和跟踪

 有义务遵守公司和项目的所有要求

6 项目分阶段分析

这部分主要阐述项目进行过程中的各个阶段项目经理所要注意的问题。

6.1 项目的调研

项目启动后的第一个任务就是调研，主要完成的工作就是搞清楚用户的需求，以及项目最后要达到的目标。必须调研清楚用户在每一个业务功能的需求，如果有些不能完全确定，也应该确定具体的范围。

项目调研首先要了解清楚项目干系人，以及每个干系人在项目中所起的作用，尤其是要了解哪个项目干系人对项目有最终的决定权。比如，哪些干系人能最后确定系统的功能，以及详细要求，哪些项目干系人只是使用系统，以及各项目干系人之间的关系。尤其要确定哪些项目干系人对项目负有最终责任。

为了顺利完成项目调研，需要做好以下的工作：

 确定项目用户方的组织结构

 确定甲乙双方项目的负责人，也就是技术和商务的联络人

 确定项目的组成人员，主要是用户方的项目组成人员

 和用户制定详细的调研计划

 按照计划提前通知有关人员进行调研

 尽量挖掘用户的需求，并进行仔细分析，对于确实不能完成的功能，要明确告

诉用户是什么原因，理由一定要充分，不能以工作量太大，价钱太低作为理由  整理用户的需求，不要漏掉任何可能的需求，写用户调研报告，并得到用户的

确认

 形成系统分析报告，详细阐明系统所要完成的功能，对于需求报告中不能完成

的部分，应详细阐明原因，并得到用户认可。形成分析报告的时候，一定从项目和用户的角度考虑问题

 在调研的过程中，一定要注意收集用户的一些原始资料，包括政策、相关的文

件、表格等等

需要调研报告的格式

收集的资料的清单

6.2 项目设计

项目设计包括几个方面，功能设计、界面设计以及数据库设计。每一个阶段的设计应该最后都要通过用户的确认，数据库设计可能由于用户并不是专家，不一定通过用户的确认。

下面我们就这几个方面的问题做一个详细的阐述：

功能设计功能设计是整个项目设计的基础，其主要依据就是用户的需求调研报告，根据用户的需求，对用户所要求的功能进行分类分析形成功能设计报告，其主要步骤如下：

 确定系统整体的技术框架

 确定用户所提的功能

 确定系统管理或者运行方面必须的功能

 对功能进行分析，整理，归类

 划分出模块，并确定模块的具体功能和目标，根据业务和权限

 对功能进行分类，那些是必须的，哪些是不一定需要的，也就是2、8原则，

对于功能应按照必须功能、非必须功能分类，同时按照常用功能、非常用功能、很少用功能进行分类，分类完成后就可以确定哪些是要着重注意的功能，那些不是了

 在系统功能设计时，要遵循以下的原则：方便性，实用性，安全性。

功能设计完成后，一定要通过用户的审查，让用户了解我们的具体思路和设计结果。界面设计是在功能设计完成后，所进行的工作就是根据功能设计和用户需求分析报告，进行设计：

根据功能，确定界面，遵循方便性，实用性，安全性原则，界面应该大方、明了、简洁。界面设计完成后根据实际情况也需要让用户进行参与，发表意见，降低项目过程中的风险。

界面设计完成后，最好可以出来原始的系统界面模型，让用户有直观的感觉。尽量用用户专业领域的语言来描述需求，少使用计算机领域的术语，因为你是在描述你对用户系统要求的理解，而不是卖弄学识。

在用户对需求进行了确认之后，项目经理要组织公司内的行业领域专家进行需求评审工作，再次落实项目的范围，和用户进行反馈，对于确实难以实现的功能，可以和用户协商分批实现或者变通解决，总之不能抱侥幸心理，期望客户会忘记该需求。

在功能和界面设计完成后就进入到下一个阶段，数据库设计，有关数据库设计的方法和原则我不在这里阐述，因为很多书本已经阐述的很清楚了。

总之一句话，项目设计过程中尽量也让用户参与，同时尽可能的让用户了解你的设计思路。

6.3 项目开发

到了项目开发阶段，项目经理需要做的事情就是管理方面的工作，就这些问题，见仁见智，不可一概而论，但有几点需要注意：

 开发的进度及时和用户沟通

 需要开发团队了解项目的开发计划和目标

 调动起开发团队的积极性

 一定要有，计划，检查，完善的过程，包括对工作结果和计划

 坚决不能采取放羊式的方法，工作分配下去后，不闻不问，必要的周报和日报，

是了解和掌握各项目成员工作状态、及时发现项目问题的好办法。

 作为项目经理，一定要掌握项目开发中的各种问题，包括进度，技术以及人员

对项目开发的一些看法

 制定项目开发的周计划，具体到每一天，同时不多于三天检查一次，甚至可以

每天上班之前开个短会，讨论一下项目的进度和情况

 对开发中发现的问题，及时解决，不能拖延

 使用版本控制工具，以及严格版本控制规程（如角色权限、问题提出和修改流

程、文档和代码版本的及时归并等）

6.4 项目实施

项目的实施对于项目的成功与否也是很关键的。在项目实施进行前，需要做以下的工作：

 对于做好的系统，用户必须认可后才能实施，否则的话，会出现很多问题  用户手册是否写好，或者是用户在使用过程中的注意事项是否写好

 用户的运行环境是否具备

 如果需要培训人员，是否有培训场地

 对于培训的人员，是否需要考核，最好能有考核方法，比如考试等，并有惩罚

措施

 和用户指定详细可行的实施计划，保证用户放配合到位

 对于实施中所出现的问题，及时反映给用户，协商解决

 对于系统功能问题，一定要给用户讲清楚什么原因，解决方法，解决的时间，

并及时解决

 同时注意，必要的签名必须进行，比如培训记录，会议纪要等等，对于实施过

程中需要大的改动的地方也要进行文字记录，对于和用户达不成一致的地方，一定要有用户认可的记录

 及时记录项目的变更（包括需求的变更、计划的变更等），在第一时间和用户

达成一致意见并经双方确认。

 加强风险管理，及时分析项目风险，以及对风险的规避措施等。

6.5 项目服务

项目实施并验收完成后，所要进行的工作就是后期服务，服务期的长短一般都是根据合同规定。后期服务要注意的问题主要有以下几点：

 服务一定要及时

 对于大的系统变动，要给用户讲明白，最好能给用户说清楚工作量

 每一次服务要有记录，方便后面对项目的后期服务量进行量化

 尽量创造条件进行远程维护，如果不行，也应该培训用户，可以达到用户根据

我们的指示可以进行系统的维护，比如简单的SQL的执行，问题的排查方法等等

 最好能在维护的过程中，形成一个问题总结记录，以便用户在遇到同样的问题

后可以自己处理，也方便我们处理问题

 对于系统管理员，一定要有系统运维指南，或者管理员手册

 和用户方规范服务流程，比如要求用户方确定一个问题接口人，负责汇总和整

理用户使用的问题，并和项目制定的维护接口人联系处理问题。应避免出现用户方其他操作人员都直接寻找公司维护工程师的情况。

7 项目需求变动

需求变动是一个项目不可避免的问题，从项目开始一直到项目的生命期结束，所以如何控制变动是项目的一个大的方面。

 变动是不可避免的

 对于变动要提前有一个思想准备，也就是提前预计要变动的部分

 对于用户提出的变动，首先要考虑的是是否影响系统的框架，是否对项目进度

影响很大，这个变动是否是用户确实需要的

 对于对系统框架或者进度影响较大的变动，一定要和用户说明影响那些部分，

会对进度有多大的影响

 对于合理的变动，一定要及时地响应并处理

 用户可能一次提出很多问题，我们应该分轻重缓急进行处理，可以只处理一部

分，对一些不重要的说服用户不进行处理，但是考虑问题的出发点一定是对项目有利

 在系统设计的过程中，尽量采用面向对象的方法，保证项目变动时影响面不扩

大

8 项目人员变动

项目人员变动也是不可避免的，可以发生在项目进行的各个阶段中，分成两类，第一是用户项目人员的变动，第二是项目公司项目人员的变动。既然是不可避免，那就必须做好这方面的思想准备和实际中的工作准备。

 用户项目组人员变动，必须进行沟通，让新的人员了解以前的计划，方案以及

制定计划和方案的思路，每一个人的工作方式不一样，肯定有些东西要进行调整，如果不是大的调整，应尽量满足用户的想法

 项目进行过程中，尽量让项目组成员了解项目的整体情况，包括其他人的情况  确定首席技术负责人

 人员变动分成出项目组和进项目组，对于新来的项目组成员，一定要让他了解

项目的整体情况，以及他所要承担部分的详细内容

 做好文档资料，保证交接工作顺利

 确立交接期，制定交接的计划，不一定是长篇大论，但不要漏掉每一个细节在人员变动中出项目的人员,项目经理该如何做呢?.需要做的是与该人员交谈,了解其想法.询问他对目前项目的看法,他可能会说出项目存在的一些问题.这对项目经理和项目来说是很重要的.由于他将离开,往往没有顾忌,会说出项目的真实状态.而不可取的做法是,立即注销该人的所有帐户,不理睬或敌视.认为其不配合,无全局观等等.

9 项目进度变动

项目进度的变化，也是很正常，产生进度变化的原因主要有以下几个：  用户方的原因产生的变动

 计划制定的不好

 碰到了不可解决或者以前没有碰到过的技术问题

 项目组成员不努力工作

 项目设计时考虑欠周到，原来的方案有问题

所以要控制项目进度变动，就应该从以上几个方面进行提前控制或者计划

 首先，和用户制定计划后，尽量不要变动，如果有变动，应给用户讲明变动后的计划情况

 制定可执行的计划，不能拍脑袋制定计划

 对于不可执行的计划，一定要及时调整

 技术方案完备，详细

 对于员工一定要跟踪工作情况，保证及时准确地掌握项目的进度和技术问题  对于大的变动，一定要知会用户，并保证用户的理解和支持

 用户提出的大的变动，最好有书面性的东西

10 项目管理总结

项目完成后，项目经理需要做的就是对项目进行总结，分为两部分：第一是项目管理方面的总结，第二是项目技术方面的总结。

温故而知新，只有做好了项目的总结，才能更好的做下一个项目。项目完成后，项目经理应该首先和项目组成员总结项目中出现的各种问题，进行分析，确定当时的处理手法是否合理，并思考是否有更好的方法处理此类问题，如果下次在其他项目中遇见同类问题，应该要考虑哪些因素，然后进行处理。要能形成文字性的东西，这也是对个人能力提高的一个很大促进。

其次要总结项目中用到的一些新的技术，分析优缺点，以便下一个项目中使用。同时应做好和其他项目经理的沟通，彼此互相交流，尽快提高自己处理问题和解决

问题的能力。

项目管理其实是一个很复杂的工程，不但要对事，还要对人，不但要面对用户还要面对公司内人员。没有一种方法可以适应所有的项目，也不能解决所有的问题，应该具体问题具体分析。在项目进行过程中及时地进行总结，加强责任心，一切以项目顺利完成为最高目标，这样的话才有可能做好一个项目。

软件项目标准开发流程

1、需求分析是怎样做的？（自己理解着说）

需求分析是构建软件系统的一个重要过程。

一般，把需求类型分成三个类型：

1、业务需求（business requirement）反映了组织机构或客户对系统、产品高层次的目的要求，它们在项目视图与范围文档中予以说明。

2、用户需求(user requirement) 文档描述了用户使用产品必须要完成的任务，这在使用实例文档或方案脚本说明中予以说明。

3、功能需求(functional requirement)定义了开发人员必须实现的软件功能，使得用户能完成他们的任务，从而满足了业务需求。

业务需求和用户需求是软件需求分析的基础，也是软件构建的前提。系统分析员通过对业务需求和用户需求的分解，将其转换成克一形式化描述的软件功能需求。开发软件系统最为困难的部分，就是准确说明开发什么。这就需要在开发的过程中不断的与用户进行交流与探讨,使系统更加详尽,准确到位。这就需要确定用户是否需要这样的产品类型以及获取每个用户类的需求。

4、客户也经常是矛盾的。事实上，很少有客户能够明确的知道怎样的一个系统对自己是最有益处的，他们往往在集中方案之间徘徊，于是经常产生需求的变动。生产厂商经常陷入客户自己的矛盾之中。

客户的负面影响可能对于能够在预算内按时完成项目产生很大的影响。尽管客户需要对需求的质量负责任，但是，当一个软件项目因为客户事先没有预料到的情况而导致失败的时候，即使客户不会追究开发方的责任，就软件项目本身而言，也已经是失败的。总结：

良好的需求分析是软件成功的基础。以上是作者对需求分析工作实践的一次小结以及综合性的思考，是对需求分析本身所做的一次分析。在此基础上，作者提出了逆向沟通的设想，即系统分析员主动进行沟通，提出指导性意见。当软件融合了客户和系统分析员双方智慧，其质量将会进一步得以提高。

2、

6周

（比较合理的代码行数是多少，如果多了，我是怎么切割的）500行，例如：实现数据

3、如何将用户登录的信息保存？

用户登陆页面将每个用户的信息使用session保存下来,例如: session.setAttribute(

如果用到用户的登陆信息，再从session根据session.getAttribute(

4．软件项目开发流程应该是什么样子的？

1。需求分析和获取；

2。界面的设计和修改，直到用户可以接受；

3。后台数据库的建立，做成几张表，写几个存储过程；

4。前台模块的编写和调试；

5。项目的实施和维护；

5、有哪些人员干什么工作，你参与过什么工作？

1、项目经理2、系统分析员3、开发人员4、测试人员5、维护培训人员

1、项目经理：具备项目管理经验，领导才能，协调能力，丰富的技术知识，善于与用户沟通协调，能够承担工作压力

2、系统分析员：具备丰富的行业应用知识，系统分析设计能力，具备丰富的项目开发经验，做过多种软件系统，熟悉系统分析设计规范

3、开发人员：具备专业开发技术，熟练掌握一种开发工具，熟知常见的各种管理系

统的开发过程，能够读懂设计文档和需求文档，有很好的编码规范和习惯，善于沟通和交流

4、测试人员：熟知各种测试技术，熟练掌握一种工具，具备丰富的项目开发经验，熟知测试规范

5、维护培训人员：熟悉操作系统配置管理，具备基本的网络知识，善于编写培训手册，善于讲解，能够很好地与用户沟通，熟知项目开发过程

6、你是怎样设计 o/r-mappinmg的。

用Hibernate实现。例如在Letdoo网的开发中，用户和他对应的爱好，我使用了多对多映射的方式，这种方式在数据库中体现出来的是，产生一个关联表，存放用户id和爱好id的对应关系。（在映射文件中的体现是，在每个类的映射中都建立与关联表的对应关系）

7、第一个项目中用户权限你是怎么设计的？

需求陈述



 不同职责的人员，对于系统操作的权限应该是不同的。优秀的业务系统，这是最基本的功能。可以对“组”进行权限分配。对于一个大企业的业务系统来说，如果要求管理员为其下员工逐一

分配系统操作权限的话，是件耗时且不够方便的事情。所以，系统中就提出了对“组”进行操作的概念，将权限一致的人员编入同一组，然后对该组进行权限分配。



 权限管理系统应该是可扩展的。它应该可以加入到任何带有权限管理功能的系统中。就像是组件一样的可以被不断的重用，而不是每开发一套管理系统，就要针对权限管理部分进行重新开发。满足业务系统中的功能权限。传统业务系统中，存在着两种权限管理，其一是功能权限的管理，

而另外一种则是资源权限的管理，在不同系统之间，功能权限是可以重用的，而资源权限则不能。关于设计

在设计阶段，系统设计人员无须考虑程序结构的设计，而是从程序流程以及数据库结构开始入手。为了实现需求，数据库的设计可谓及其重要，无论是“组”操作的概念，还是整套权限管理系统的重用性，都在于数据库的设计。

首先，action表（以下简称为“权限表”），gorupmanager表（以下简称为“管理组表”），以及master表（以下简称为“人员表”），是三张实体表，它们依次记录着“权限”的信息，“管理组”的信息和“人员”的信息。

这三个表之间的关系是多对多的，一个权限可能同时属于多个管理组，一个管理组中也可能同时包含多个权限。同样的道理，一个人员可能同时属于多个管理组，而一个管理组中也可能同时包含多个人员。

由于这三张表之间存在着多对多的关系，那么它们之间的交互，最好使用另外两张表来完成。而这两张表起着映射的作用，分别是“actiongroup”表（以下简称“权限映射表”）和“mastergroup”表（以下简称“人员映射表”），前者映射了权限表与管理组表之间的交互。后者映射了人员表与管理组表之间的交互。

另外，还需要一张表来控制系统运行时左侧菜单中的权限分栏，也就是“权限分栏表”。综上所述，这样设计数据库，系统是完全可以重用的，并且经受得住“变更”考验的。

此套系统的重点在于，三张实体表牢牢地抓住了系统的核心成分，而两张映射表完美地映射出三张实体表之间的交互。其难点在于，理解映射表的工作，它记录着关系，并且实现了“组”操作的概念。而系统总体的设计是本着可以在不同的MIS系统中“重用”来满足不同系统的功能权限设置。

1、需求分析是怎样做的？（自己理解着说）

需求分析是构建软件系统的一个重要过程。

一般，把需求类型分成三个类型：

1、业务需求（business requirement）反映了组织机构或客户对系统、产品高层次的目的要

求，它们在项目视图与范围文档中予以说明。

2、用户需求(user requirement) 文档描述了用户使用产品必须要完成的任务，这在使用实例文档或方案脚本说明中予以说明。

3、功能需求(functional requirement)定义了开发人员必须实现的软件功能，使得用户能完成他们的任务，从而满足了业务需求。

2、

6周

（比较合理的代码行数是多少，如果多了，我是怎么切割的）500行，例如：实现数据

3、如何将用户登录的信息保存？

用户登陆页面将每个用户的信息使用session保存下来,例如: session.setAttribute(

如果用到用户的登陆信息，再从session根据session.getAttribute(

4．软件项目开发流程应该是什么样子的？

1。需求分析和获取；

2。界面的设计和修改，直到用户可以接受；

3。后台数据库的建立，做成几张表，写几个存储过程；

4。前台模块的编写和调试；

5。项目的实施和维护；

5、有哪些人员干什么工作，你参与过什么工作？

1、项目经理2、系统分析员3、开发人员4、测试人员5、维护培训人员

1、项目经理：具备项目管理经验，领导才能，协调能力，丰富的技术知识，善于与用户沟通协调，能够承担工作压力

2、系统分析员：具备丰富的行业应用知识，系统分析设计能力，具备丰富的项目开发经验，做过多种软件系统，熟悉系统分析设计规范

3、开发人员：具备专业开发技术，熟练掌握一种开发工具，熟知常见的各种管理系

统的开发过程，能够读懂设计文档和需求文档，有很好的编码规范和习惯，善于沟通和交流

4、测试人员：熟知各种测试技术，熟练掌握一种工具，具备丰富的项目开发经验，熟知测试规范

5、维护培训人员：熟悉操作系统配置管理，具备基本的网络知识，善于编写培训手册，善于讲解，能够很好地与用户沟通，熟知项目开发过程

6、你是怎样设计 o/r-mappinmg的。

7、第一个项目中用户权限你是怎么设计的？

需求陈述



而另外一种则是资源权限的管理，在不同系统之间，功能权限是可以重用的，而资源权限则不能。关于设计

1、需求分析是怎样做的？（自己理解着说）

需求分析是构建软件系统的一个重要过程。

一般，把需求类型分成三个类型：

1、业务需求（business requirement）反映了组织机构或客户对系统、产品高层次的目的要

求，它们在项目视图与范围文档中予以说明。

2、用户需求(user requirement) 文档描述了用户使用产品必须要完成的任务，这在使用实例文档或方案脚本说明中予以说明。

3、功能需求(functional requirement)定义了开发人员必须实现的软件功能，使得用户能完成他们的任务，从而满足了业务需求。

2、

6周

（比较合理的代码行数是多少，如果多了，我是怎么切割的）500行，例如：实现数据

3、如何将用户登录的信息保存？

用户登陆页面将每个用户的信息使用session保存下来,例如: session.setAttribute(

如果用到用户的登陆信息，再从session根据session.getAttribute(

4．软件项目开发流程应该是什么样子的？

1。需求分析和获取；

2。界面的设计和修改，直到用户可以接受；

3。后台数据库的建立，做成几张表，写几个存储过程；

4。前台模块的编写和调试；

5。项目的实施和维护；

5、有哪些人员干什么工作，你参与过什么工作？

1、项目经理2、系统分析员3、开发人员4、测试人员5、维护培训人员

1、项目经理：具备项目管理经验，领导才能，协调能力，丰富的技术知识，善于与用户沟通协调，能够承担工作压力

2、系统分析员：具备丰富的行业应用知识，系统分析设计能力，具备丰富的项目开发经验，做过多种软件系统，熟悉系统分析设计规范

3、开发人员：具备专业开发技术，熟练掌握一种开发工具，熟知常见的各种管理系

统的开发过程，能够读懂设计文档和需求文档，有很好的编码规范和习惯，善于沟通和交流

4、测试人员：熟知各种测试技术，熟练掌握一种工具，具备丰富的项目开发经验，熟知测试规范

5、维护培训人员：熟悉操作系统配置管理，具备基本的网络知识，善于编写培训手册，善于讲解，能够很好地与用户沟通，熟知项目开发过程

6、你是怎样设计 o/r-mappinmg的。

7、第一个项目中用户权限你是怎么设计的？

需求陈述



而另外一种则是资源权限的管理，在不同系统之间，功能权限是可以重用的，而资源权限则不能。关于设计

软件项目标书范本

中国外汇交易中心数据仓库一期项目建议

第二册技术部分

安讯软件（上海）有限公司

2008年5月4日

1 2

项目目标 ................................................................................................................................. 1 技术解决方案 ......................................................................................................................... 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 2.1.4 2.2

物理架构........................................................................................................... 3 数据架构........................................................................................................... 5

系统技术实现方案 .................................................................................................. 6 2.2.1 2.2.2

总体技术实现方案 ........................................................................................... 6 高效的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 2.2.6

认证管理......................................................................................................... 13 系统可靠性及可扩展性 ................................................................................. 13

2.2.7 非功能性设计 ................................................................................................. 14

2.2.7.1 性能需求 ................................................................................................ 14 2.2.7.2 灾备设计 ................................................................................................ 15 2.2.7.3 可获性设计 ............................................................................................ 17 2.2.7.4 易用性设计 ............................................................................................ 17 2.2.7.5 安全性设计 ............................................................................................ 18

项目管理 ............................................................................................................................... 19 3.1

沟通管理 ................................................................................................................ 19 3.1.1

项目会议制度 ................................................................................................. 19

3.1.1.1 定期会议 ................................................................................................ 20 3.1.1.2 不定期会议 ............................................................................................ 20 3.1.2 3.1.3 3.2

项目状态周报制度 ......................................................................................... 21 沟通手段......................................................................................................... 21

配置管理 ................................................................................................................ 22 3.2.1 3.2.2

配置管理原则 ................................................................................................. 22 配置库管理 ..................................................................................................... 22

3.3 变更管理 ................................................................................................................ 22 3.3.1 3.3.2 3.3.3 3.3.4 3.3.5

发起变更......................................................................................................... 22 评估变更......................................................................................................... 23 审批变更......................................................................................................... 23 执行变更......................................................................................................... 23 变更执行评估 ................................................................................................. 23

3.4 质量管理 ................................................................................................................ 24 3.4.1 3.4.2 3.4.3

质量规划......................................................................................................... 24 质量保证......................................................................................................... 25 质量检查......................................................................................................... 26

4 5

工期进度 ............................................................................................................................... 26 附录 ....................................................................................................................................... 27

第二册技术部分

1 项目目标

（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对数据进行加工，清洗和标准化。

2.2 系统技术实现方案

2.2.1 总体技术实现方案

使用我们建议的应用软件，这样的系统架构会有很强的可扩展性，用户可以通过增加硬件的方式扩容，以支持越来越多的用户和应用。

总体方案通过以下步骤实现数据到可用信息的转换：

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) 支持星型模式

1) 图形化界面 2) 支持命令行 3) 便于调试和维护 4) 具有代码版本控制功能（4） ETL管理

1) 支持集中管理

2) 自动产生每日ETL运行报表 3) 具有ETL自动和手工调度功能

我们相信商业ETL工具中INFORMATICA会是一个很好的选择，开源ETL产品Kettle则是INFORMATICA之外一个很好的备选。

2.2.2.2 数据仓库模型设计

数据建模

建模过程：（以常用会计报表为例）

1. 用户需要查看基于时间、机构和科目的报表。

2.2.3 数据质量管理

2.2.3.1 数据仓库对数据质量的要求

2.2.3.2 数据质量改进目标

数据质量改进的目标是清理、标准化、提高和匹配现有数据。

2.2.3.3 数据质量改进方法

数据质量控制要从技术、流程和管理三个方面进行。

从技术层面上，生产系统存在的噪音数据、遗漏数据和不一致性数据，需要进行数据清洗；同时需要对源数据做稽核，如总量稽核和分量稽核。

在管理层面上，要求生产系统报送数据，按照“谁提供数据，谁负责”的原则由生产系统保证源数据的完整性、准确性、一致性、时效性。

2.2.4 报表平台设计

具体设计如下：

2.2.4.1 灵活的报表查询

2.2.4.2 先进的报表开发模式

在报表的开发中，我们将采用最先进的协同开发模式，开发人员定制业务逻辑，业务人员根据自己需要通过简单的拖动则可形成自己需要的报表。

设计Report模板并发布至服务器

Business

Informationobjects

设计报表

2.2.4.3 高效的报表消费

2.2.4.4 老系统统计报表移植

老系统报表迁移的一个难点是如何保证数据仓库系统中的报表统计结果与原报表统计

我们将会采用严格的测试手段来保证新报表与老报表统计结果的一致性。测试的目的，

2.2.5 认证管理

在对用户信息的管理中，提供以角色和用户为安全模型的统一认证机制，只有具有对应角色的用户才能访问对应的报表。

2.2.6 系统可靠性及可扩展性

系统的可靠性及可扩展性对企业级应用来说是非常重要的。我们的设计充分考虑了这两个因素。

2.2.7 非功能性设计

2.2.7.1 性能需求 2.2.7.1.1 容量设计

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 备份策略

为了保障核心数据和重要数据的完整性和一致性，我们将提供对应的磁盘备份、联机备份和远程备份功能：

以上的备份策略，保证在不影响系统服务的条件下，在本地和远程，都保留一份前一天的备份数据，包括数据仓库和报表服务器的数据。

当地备份建议保留30天；远程备份建议保留7天。备份可以保存在磁带库、或光盘库。本地备份耗时目标是2小时；远程备份耗时目标是12小时。

2.2.7.2.3 恢复策略

常规的数据恢复流程设计如下：

1) 重启系统的所有服务器和存储设备

2) 如必要，恢复系统

3) 从本地备份选取前一天的备份，或最近的备份；如果本地备份丢失，取远程备份 4) 恢复数据仓库和报表系统数据 5) 恢复系统服务

 SQL语句失败  线程失败  实例失败  用户操作失败  存储设备失败

 数据库的系统文件，指数据库的运行文件，各种应用程序  数据库控制文件  数据库联机重做日志文件  数据文件

 归档日志文件

避免第一种文件失败主要依赖系统管理员进行操作系统级的备份，当发生事故后只能依靠操作系统备份将其恢复。

2.2.7.3 可获性设计

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 项目状态周报制度

3.1.3 沟通手段

 开会或直接交谈

按需要组织会议进行沟通，或直接找相关的人进行讨论，注意记录沟通和讨论结果，重要问题讨论必须有书面会议记录。  电话或电话会议

通过电话的方式进行信息沟通。对比较重要的事情，需要包括开发地点以外的人员，则需要利用电话会议的方式进行讨论，沟通。  电子邮件

建立项目组电子邮件系统及与外界联系的电子邮件系统。

3.2 配置管理

3.2.1 配置管理原则

3.2.2 配置库管理

3.3 变更管理

本项目成立变更控制委员会，一般为单数组成（甲方人数＝乙方＋1），由甲方指定人员任变更控制委员会主任;

变更的审批由变更控制委员会表决决定，2/3人数通过为表决通过，变更控制委员会主任有最终否决权。

如变更控制委员会无法对变更做出最后决定，由变更控制委员会主任将变更申请提交项目管理高层进行裁决。

3.3.1 发起变更

3.3.2 评估变更

3.3.3 审批变更

变更控制委员会对变更请求进行审批，由变更控制委员会主任签署书面变更审批单，有效变更审批间必须在审批结论中明确是否通过变更申请。

涉及合同变更的不在变更控制委员会审批范围内，根据购买合同规定的条款进行审批。

3.3.4 执行变更

乙方负责根据变更审批结果，调整相关项目计划，根据新的项目计划和项目进度，重新分配资源，对变更展开工作，并指定变更执行评估人员。

变更有关执行人进行变更执行。执行完成后向变更控制委员会报告变更执行情况。

3.3.5 变更执行评估

变更控制委员会中乙方委员负责填报变更执行结果评估表，对执行结果进行评估跟踪，并将结果向变更控制委员会主任报告。

3.4 质量管理

3.4.1 质量规划

 质量目标：针对数据仓库一期系统，确立以下质量目标，甲乙双方应针对以下质量目

标开展质量管理活动：

 保证100%满足业务需求要求的正确性与精确性  用户满意度达90%以上  质量管理原则

 客户满意度优先  预防优于检查  管理层的责任  持续改进

 质量保证计划：合同生效后，甲乙双方应在质量方针、质量目标、质量原则及项目范

围等的前提下建立质量保证计划，明确相关干系人质量管理职责、项目质量管理任务的定义与责任人、需遵守的制度、规程、规范与标准、质量控制的方法、工具、记录与跟踪等，便以此为基础，有效地开展质量管理活动。  测试要求

测试作为项目最主要的验证方式，应该得到双方的高度重视。应达到以下要求：  所有测试必须有适用的测试管理流程，得到质量控制小组的确认  在需求分析阶段，出具用户测试计划，以保证需求的可测试性  在概要设计阶段，出具集成测试计划、集成测试案例  在详细设计阶段，出具单元测试计划、单元测试案例

 编码阶段所有模块必须经过单元测试通过，并出具单元测试报告，经双方项目经理

确认

 集成测试计划需经评审通过

 集成测试必须有两轮以上的测试，每轮测试必须有集成测试报告

 用户测试必须由甲方组织测试通过，出具经相关单位盖章的测试报告后，视为完成  在集成测试完成后的程序修改应有足够的回归测试工作，并得到项目质量控制小组

的确认

3.4.2 质量保证

甲乙双方在项目实施期间应进行以下质量保证活动： 1. 规则的培训与指导

双方项目经理负责组织在项目启动阶段向项目组成员做有关制度、规程、标准、工具

与模板的使用培训。 2. 文档管理

 文档规范

  

文档需遵循一定的规范，由双方参照相关国际与国家标准协商制定，需经甲方项目质量控制人员审核通过。文档标识方法必须有统一的文档编号;

文档应具有相关的定位信息与参考信息等，如：文档作者、完成日期、批准人员、批准日期、新发布与修订情况、流通清单、机密性限制等

 文档批准：所有文档必须经项目经理或质量保证人员的审核通过，正式提交件必

须经过相关评审认可，参见提交件管理部分。

 文档的存储与检索：

  

存储：双方明确文档存储管理人员，正式提交文件存储应在甲方统一配置管理平台上进行。

文档的流通与检索：经审核的新文档必须按时流通到指定收件人;保证副本的有效、准确、保密性。

文档保密、包括文档的废止：严格按照文档类型的限制访问;防止非授权人员改变存储的文档;提供电子或纸质的备份;确定存储期限。

3. 需求跟踪管理：甲乙双方项目人员应在项目开发过程建立需求跟踪矩阵，以对需求进

行有效跟踪。

4. 评审、同行评审与走查：在项目需求分析阶段，需求分析说明书在正式提交前均应进

配置管理员统一按有关流程进行发布，甲乙双方其他人员不得以任何形式在测试环境或生产环境进行发布工作。

7. 问题跟踪：乙方负责指定专人对项目实施过程中出现的问题与缺陷进行跟踪解决，每

周出具相关统计信息。

8. 过程审计：质量控制小组定期对项目质量工作进行审计，双方应就审计结论进行相关

整改。

9. 质量汇报：双方项目经理应本着实事求是的原则，向双方管理层及时准确地汇报项目

情况，保证项目的可视性。

3.4.3 质量检查

甲乙双方应就项目进展情况定期进行质量检查工作，保证项目按既定计划，保证质量地实施。

乙方应配合甲方有关项目管理部门进行质量检查，并及时根据检查结果，进行跟踪解决。

4 工期进度

根据项目生命周期，我们把项目实施分为三个大的阶段，项目整体阶段里程碑工作计划如下：

5 附录

A. 软硬件配置方案 B. 开发测试工具一览表 C. 变更申请表

D. 安讯9系统性能白皮书

软件项目目标怎么写

软件项目标书

软件开发人员的简历项目经验怎么写？

软件项目经理怎么做？

软件项目标准开发流程

软件项目标书范本

扫一扫手机访问

发表评论