范文一:软件项目标书范本
Actuate Confidential 5/4/2008
中国外汇交易中心数据仓库一期项目建议
第二册 技术部分
安讯软件(上海)有限公司
2008年5月4日
Actuate Confidential 5/4/2008
目录
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
Actuate Confidential 5/4/2008
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
3 项目管
理 ............................................................................................................................... 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
Actuate Confidential
5/4/2008
第二册 技术部分
1 项目目标
CFETS希望通过数据仓库系统的建设,可以有效地整合各市场业务数据,统一对信息进行利用和管理,对外提供统一的数据视图和综合决策分析支撑环境,为CFETS各部门所需的报表应用、统计分析及信息挖掘提供基础支持平台。具体建设目标如下:
(1)技术目标
建立数据仓库基础架构
建立自动数据抽取,转换,加载(ETL)机制
建立多维分析和数据查询工具和界面已经分析报表生成和展示框架
(2)业务目标
实现一期经营分析的多维分析、查询和报表,提供CFETS各部门所需报表
提供下游系统所需要的统计数据
提供中心内部用户以Ad-Hoc方式查询所需数据
将业务系统的历史和增量数据加载进入数据仓库,并转换为数据仓库的存储格式 实现用户访问的门户界面并建立相应的访问安全和权限机制
进行老系统统计报表的移植工作,保证数据仓库系统中的报表统计结果与原报表统
计结果的一致性
基于上述需求,安讯软件(上海)有限公司提出如下技术解决方案来实现本项目的技术目标和业务目标。
- 1 -
Actuate Confidential
5/4/2008 2 技术解决方案
2.1 系统总体架构
2.1.1 逻辑架构
总体逻辑架构如下:
2.1.1.1 功能层面(上侧面)
根据CFETS对应的功能需求,对应的功能层面上需要建立如下功能:
数据的ETL
数据存储
固定统计报表
统一用户界面及Portal认证管理
- 2 -
Actuate Confidential
5/4/2008
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 物理架构
对于本,外币不同的数据源,以及不同的物理子系统,基本的物理架构如下:
- 3 -
Actuate Confidential
5/4/2008
物理架构说明:
A. 本外币数据库向仓库提供对应的数据
B. 仓库为对应的报表服务器提供统一的视图。
C. 权限报表服务器部署到同一机器上。
- 4 -
Actuate Confidential
5/4/2008
2.1.4 数据架构
数据流说明:
A. 首先从本外币或者其他系统获得对应的数据. B. 经过ETL对数据进行加工,清洗和标准化。
C. 将已经标准化和模型化的数据进入到数据仓库,或者提供需要的数据文件。 D. 数据仓库对外暴露数据模型和数据视图以及sql接口。 E. 数据仓库为报表管理系统和下游系统提供所需要的数据 F. 报表管理系统展现对应数据的报表。
- 5 -
Actuate Confidential
5/4/2008
2.2 系统技术实现方案
2.2.1 总体技术实现方案
充分考虑到CFETS系统存在在本外币等多种数据源,且数据源分散,多分散子系统的情况,同时各个子系统中存在统计口径不一致,影响统一的决策和各个部门信息的一致性。在使用的过程中,会员信息维护复杂,且各个系统各自维护一套对应的会员信息,导致会员维护工作量加大。数据仓库一期需求大致可以分成数据库架构的建立、ETL机制的建立、以及报表分析架构的建立和报表实施。系统可以分成数据仓库和报表系统两大部分。以下是我们建议的系统架构概念
图:
- 6 -
Actuate Confidential
5/4/2008
系统包含一个双机组成的数据仓库,和一个双机组成的报表服务平台。数据仓库和报表服务器分别带有自己的外存磁盘阵列。架构中的每个功能节点设计都含冗余度,保证系统不存在单一失败点,满足提供7x24不间断服务的要求。
在系统架构不变的前提下,系统的每部分可以用不同的技术实现。比如,数据库管理系统可以使用Oracle的技术,也可以使用IBM的技术。报表技术建议使用Actuate 9。
使用我们建议的应用软件,这样的系统架构会有很强的可扩展性,用户可以通过增加硬件的方式扩容,以支持越来越多的用户和应用。
总体方案通过以下步骤实现数据到可用信息的转换:
1. 通过ETL手段对不同的数据源数据进行抽取,转换,清洗,数据格式化。
2. 通过ETL转化后的数据统一进入数据仓库,形成统一的数据视图。
3. 进入数据仓库的数据模型可以为报表平台提供对应的数据来源。
4. 通过认证的用户可以登陆报表平台消费和设计对应的报表。
2.2.2 高效的ETL处理
2.2.2.1 ETL总体处理流程
ETL处理流程:
1. 从本币数据源或其他数据源中抽取需要的数据。
- 7 -
Actuate Confidential
5/4/2008
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自动和手工调度功能
- 8 -
Actuate Confidential
5/4/2008
我们相信商业ETL工具中INFORMATICA会是一个很好的选择,开源ETL产
品Kettle则是INFORMATICA之外一个很好的备选。
2.2.2.2 数据仓库模型设计
数据建模
建模过程:(以常用会计报表为例)
1. 用户需要查看基于时间、机构和科目的报表。
2. 建立以数据事实表为中心,需要时间、机构和度量作为其维度。
3. 建立好如上的星型模型后,可发现模型具有如下优点。
4. 灵活的数据查询,可基于时间查询对应的日报,月报和季报。
5. 效率最优化,需要查询机构信息,则通过机构和事实表关联即可完成。
- 9 -
Actuate Confidential
5/4/2008
2.2.3 数据质量管理
2.2.3.1 数据仓库对数据质量的要求
数据仓库对数据质量的要求总体上归纳为:数据完整性,包括数据源是否完整、数据取值是否完整、维度取值是否完整等。数据准确性,包括数据源是否准确、编码映射关系是否准确、处理逻辑是否准确等。数据核对准确的判断是要么结果一致,要么不一致但原因是可解释的。数据一致性,包括源系统之间同一数据是否一致,源数据与抽取的数据是否一致,数据仓库内部各处理环节数据是否一致等。数据逻辑合理性,主要从业务逻辑的角度判断数据是否正确,如帐目类型的金额、时长、次数的逻辑关系是否满足等。数据时效性,包括数据处理(获取、整理、加载等)的及时性,数据异常检测的及时性,数据处理回退的及时性等。
数据仓库服务于经营决策,经营决策依据的数据应该是全面的、真实可靠的、有意义的。数据时效性如果得不到保证,就可能延误了市场人员的分析,失去商机。
从数据仓库的建设过程来看,它本身修复数据以提高数据质量的能力并不是很强,但是它能发现生产系统存在的一些数据质量问题从而提醒用户哪些数据有质量问题,将数据问题反馈到业务支撑系统中,由后者做数据修正。
2.2.3.2 数据质量改进目标
数据质量改进的目标是清理、标准化、提高和匹配现有数据。
通过数据整合,建立完整的、准确的、一致的统一客户视图,完善共享信息数据,并使共享信息数据服务于经营分析,为生产系统的改进提供标准。 建立数据整合流程,实现流程定义、流程配置和流程管控。 建立数据整合的规章制度,落实数据质量的分级负责。建立起数据整合队伍,使数据质量能够得以持续改进。
2.2.3.3 数据质量改进方法
数据质量控制要从技术、流程和管理三个方面进行。
从技术层面上,生产系统存在的噪音数据、遗漏数据和不一致性数据,需要进行数据清洗;同时需要对源数据做稽核,如总量稽核和分量稽核。
- 10 -
Actuate Confidential
5/4/2008
在流程层面上,对于源数据的抽取要遵从一定的业务规则,数据的抽取和转换需要很多步骤来完成,这就需要将过程流程化,并且流程可通过配置来实现。
在管理层面上,要求生产系统报送数据,按照“谁提供数据,谁负责”的原则由生产系统保证源数据的完整性、准确性、一致性、时效性。
下面是我们在技术层面采取的具体做法。在ETL架构设计中我们会包括数据质量设计,将数据质量检查脚本加入到ETL流程中,分为技术检查和业务规则检查。错误分严重程度,如主键重复的就停止ETL流程,等待解决,但低级别的错误不会阻塞ETL过程。在这个过程中,所有的错误都会进行记录,最终生
成数据质量检查报告。但需要明确的是,很多情况下,许多数据问题在ETL之前都无法知道,只能通过ETL之后的数据核对才能发现,然后逐渐积累,加到ETL的规则控制中去。
2.2.4 报表平台设计
建立报表查询门户,提供各类信息报表的查询,统一查询渠道,统一数据口径,统一用户管理。多个管理信息系统在报表平台上表现为一个个独立的逻辑子系统。
通过报表平台,技术人员可以通过灵活配置逻辑系统集成不同BI工具产生的异构报表资源,业务人员可以进行不同报表资源的集中管理和发布,最终用户可以通过一致的展示环境获取报表信息。
具体设计如下:
- 11 -
Actuate Confidential
5/4/2008
2.2.4.1 灵活的报表查询
在报表的查询过程中,可以通过浏览器直接浏览报表,同时,用户也可以通过简单的操作,对报表进行重新订制,为了更好的提高实用性,用户可通过浏览器同报表服务器进行交互,查看到需要的报表。
2.2.4.2 先进的报表开发模式
在报表的开发中,我们将采用最先进的协同开发模式,开发人员定制业务逻辑,业务人员根据自己需要通过简单的拖动则可形成自己需要的报表。
IT设计Report模板并发布至服务器BusinessInformationobjects设计报表
2.2.4.3 高效的报表消费
在使用的过程中,业务人员根本不用关心对应的后台业务逻辑,以及数据信息来源等信息,其只要根据自己的业务需要,通过简单的拖拽即可完成对报表的定制,获取到自己需要的信息。
2.2.4.4 老系统统计报表移植
对于老系统的统计报表,我们将采取重写的方式移植到统一的报表平台上面。重写后的统计报表基于新建的数据仓库,这样就统一了现存的多个统计系统,统一了统计口径,解决了统计口径不一致所造成的各个部门信息的不一致,并消除这种不一致对管理决策带来的负面影响。
- 12 -
Actuate Confidential
5/4/2008 老系统报表迁移的一个难点是如何保证数据仓库系统中的报表统计结果与原报表统计结果的一致性,对此要具体问题具体分析。新报表的统计结果与原报表的统计结果不一致只可能是两种情况:新报表的统计方式是错误的,造成新老报表统计结果不一致;新老报表的统计口径不一致,造成统计结果不一致。如果是前一种情况,采用正确的统计方式就能修正错误。如果是后一种情况,则需要根据业务的需要选择统计口径,使新报表能够达到业务人员的预期。
我们将会采用严格的测试手段来保证新报表与老报表统计结果的一致性。测试的目的,是验证对于相同的输入,新老报表得到的输出结果完全一致。实际测试中,我们将采用等价类划分以及边值分析法来设计测试用例,产生有限的测试用例来覆盖足够多的“任何情况”。对有差异的报表,我们会作进一步的数据集对比,以确定问题的根源到底是在数据,还是报表逻辑。
2.2.5 认证管理
在对用户信息的管理中,提供以角色和用户为安全模型的统一认证机制,只有具有对应角色的用户才能访问对应的报表。
2.2.6 系统可靠性及可扩展性
系统的可靠性及可扩展性对企业级应用来说是非常重要的。我们的设计充分考虑了这两个因素。
针对可靠性,我们的设计是在系统包含一个双机组成的数据仓库,和一个双机组成的报表服务平台。数据仓库和报表服务器分别带有自己的外存磁盘阵列。架构中的每个功能节点设计都含冗余度,保证系统不存在单一失败点,满足提供7x24不间断服务的要求。采用的这样系统架构,主机系统的维护、系统扩容、升级、系统性能统计、分析、优化以及部件更换就能够在不影响应用系统功能的前提下完成。而所有关键部件能够保证在不停顿数据共享服务的前提下提供热插拔能力。
对于可扩展性,使用我们建议的报表服务平台安讯iServer,系统架构会有很强的可扩展性,用户可以通过增加硬件的方式扩容,以支持越来越多的用户和应用。安讯iServer可以运行在由多台服务器组成的集群上,利用任务控制与自动负载平衡技术,将任务平均分配到各台服务器上。安讯iServer具备出色的可扩展性,用户可以简单的向集群中添加更多
- 13 -
Actuate Confidential
5/4/2008 的服务器来满足更高的报表需求,而系统的性能随着服务器数量的增多呈线性增长,这方面的具体数据请参考附录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. 充分利用报表系统的对查询的缓存功能,减少对数据源的实时访问。
- 14 -
Actuate Confidential
5/4/2008
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) 重启系统的所有服务器和存储设备
- 15 -
Actuate Confidential
5/4/2008
2) 如必要,恢复系统
3) 从本地备份选取前一天的备份,或最近的备份;如果本地备份丢失,取远程备份
4) 恢复数据仓库和报表系统数据
5) 恢复系统服务
常规数据恢复一般是在文件系统失败(包括磁盘设备失败)导致数据无法使用的情形下必须激活的程序。常规数据恢复保证系统回复到前一天的状态,但也意味着当天数据的丢失。一般系统出错的恢复,其实不一定需要用到备份,我们建议应该避免使用常规数据恢复,尽量考虑用其他办法把系统回复到最近的可用状态。以下我们以Oracle数据库为例,说明一下可以考虑的恢复措施。
数据库的恢复过程分两步进行,首先将把存放在重做日志文件中的所有重做运用到数据文件,之后对重做中所有未提交的事务进行回滚。数据库的恢复只能在发生故障之前的数据文件上运用重做,将其恢复到故障时刻,而不能将数据文件反向回滚到之前的某一个时刻。数据库的异常、错误可以分为以下几类:
语句失败
线程失败
实例失败
用户操作失败
存储设备失败
如果发生前三种失败,不需要人为干涉,系统会自动进行恢复。对于用户操作型的失败(如误删除数据),系统采取的补救措施主要有导入最新的逻辑备份或进行到某一时间点的不完全恢复。数据库引入了基于表空间的时间点恢复(TSPITR),可以单独将包含错误操作的表空间恢复到指定时间,而不必对整个数据库进行不完全恢复。当错误操作发现比较及时而且数据量不大的情况下也可以
考虑使用logminer生成反向SQL。
针对存储设备的失败的情况比较复杂,存储设备的失败必然会使放置在其上的文件变为不可用,我们先将数据库所涉及到的文件进行一个划分,主要可分为:
数据库的系统文件,指数据库的运行文件,各种应用程序
数据库控制文件
数据库联机重做日志文件
数据文件
- 16 -
Actuate Confidential
5/4/2008
归档日志文件
避免第一种文件失败主要依赖系统管理员进行操作系统级的备份,当发生事故后只能依靠操作系统备份将其恢复。
控制文件中记录着整个数据库的结构、每个数据文件的状况、系统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作为客户端的浏览工具。
用户界面友好、同时易操作。
界面操作符合浏览习惯。
界面风格,术语统一。
灵活的页面布局,支持标签页。
合理的组织操作菜单
- 17 -
Actuate Confidential
5/4/2008
查询等出现错误时提供友好的提示。
提供友好的联机帮助界面。
2.2.7.5 安全性设计
2.2.7.5.1 身份认证
系统提供身份认证功能。使用系统的用户必须先要经过申请审批管理流程,通过有关部门管理人员的合法性审批,系统管理员在系统管理模块中设置用户名、操作权限和初始密码,并告知用户后,用户才可以用指定的用户名和密码登录进入系统,进行权限范围内的操作。
在系统登录界面中,只有输入正确的用户名和密码,才能进入系统,进入系统后用户可随时修改自己的密码。对用户密码可提供更严格的控制功能,如首次登录系统必须修改密码、经过多长时间必须修改密码、多次登录失败锁定用户等,进一步提供系统的身份认证安全性。
2.2.7.5.2 用户权限控制
系统提供权限管理功能模块,系统管理员可增加、删除、修改用户、用户组,设置用户的、操作权限、数据权限。
通过用户、用户组及权限管理功能,可根据机构、部门、用户类别等建立用户组,用户可以属于某个组或几个组,也可以是独立用户。通过对用户组进行授权,组中的每个用户都拥有组的所有权限,极大方便了授权管理;独立的用户可以独立授权。用户组、用户的权限可以针对机构、业务数据的范围、功能范围等进行授权,实现系统应用的数据安全。
2.2.7.5.3 关键数据加密存储
对于存储到系统中的一些关键敏感数据,程序对这些数据进行加密存储,使得在其它任何软件环境中都无法获取明码。
- 18 -
Actuate Confidential
5/4/2008
2.2.7.5.4 系统操作处理日志
系统对用户登录情况,如登录用户、进入时间、退出时间、操作功能项等进行自动记录;对于数据录入、数据同步、数据抽取和数据分析等应用处理的时间、数据范围、执行情况等也自动记录日志,以便出问题时跟踪追查审计。
系统日志还可用于系统操作的防抵赖。
2.2.7.5.5 安全管理机构和制度建设
明确系统的安全管理机构/部门、人员及职责,负责管理系统安全保密工作。制定系统安全保密管理制度,并严格加以执行及监督,实现资源的合理配置和统一管理,实现统一的访问控制策略,确保系统的安全运行、安全审查。
在外部安全上,企业级的防火墙可以为本系统提供一个安全的运行环境。
在系统内部,本系统用户众多,机构、角色、权限各不相同,因此必须具有较高的安全性,防止用户越权访问以及窃取数据。 用户的每个动作都要经过身份验证,在身份与权限匹配的情况下才能继续执行其他操作,就可以有效实现安全性目标。
操作授权:对不同使用部门使用产品的授权和其中不同级别的用户使用产品功能的授权由系统管理员分级授权,授权信息放在数据库中,操作员的每一个操作
均需系统授权。 3 项目管理
3.1 沟通管理
3.1.1 项目会议制度
项目会议是服务于项目工作的,是为了更好的加强项目沟通、解决项目实施过程中存在的各种问题。每次会议都要有专人做会议记录,会议纪要的格式参见双方约定文档规范中的会议纪要模板,会后由记录人员将会议纪要分发给相关人员,并上传版本库中。
项目组根据项目实际情况拟设立定期会议和不定期会议,分别阐述如下:
- 19 -
Actuate Confidential
5/4/2008
3.1.1.1 定期会议
项目周例会
会议目标: 沟通项目状态,提出项目问题、风险和依赖条件;协调项目资源;对项
目提出建议,问题的解决方法,行动计划。
日期与时间: 每周四14:00开始。
参加人员: 乙方项目经理;甲方项目经理;项目经理指定的其他成员。
主要议程及责任:更新项目状态,包括:跟踪检查项目遗留问题的解决情况;项目
状态信息,时间进度表等;问题,风险,依赖条件(技术和管理);对提出的问题,讨论和决定行动计划;乙方负责做会议记录,会后分发会议记录,将会议记录上传到版本库中,并负责下一步行动计划。
3.1.1.2 不定期会议
项目状态会议
会议目标: 使项目全体人员明确目前项目的状态、问题、解决方法。
日期与时间:根据实际需要确定。
参加人员: 所有项目人员。
主要议程及责任:项目状态,存在的问题及解决方法;下阶段项目计划。
项目领导组会议
会议目标: 审核下阶段项目计划;复查项目状态和里程碑;对项目中的重大问题做
出决策;协调项目各方资源;解决项目各方可能发生的重大争议。
日期与时间:根据项目进展实际情况安排。
参加人员:项目领导组成员;乙方项目经理;甲方项目经理;其他有需要参加的人
员。
主要议程及责任:项目经理汇报项目状态和下阶段项目计划;项目领导讨论项目中
需要决策的重大问题;乙方负责做会议记录,会后分发会议记录,将会议记录上传到版本库中,并负责下一步行动计划。
重大问题汇报会议
- 20 -
Actuate Confidential
5/4/2008
会议目标: 汇报项目重大问题,并讨论决定采取何行动。
日期与时间:重大问题出现时。
参加人员:问题发起人;项目经理;高层领导等。
主要议程及责任:汇报项目重大问题,找出解决方案,决定行动计划。
项目组内部讨论/沟通会议
会议目标:对项目组内部遇到的问题进行讨论,找出解决方案,并讨论决定采取何
行动。
日期与时间:根据开发的状态。
参加人员:问题发起人;沟通相关人员等。
主要议程及责任:讨论出现的各种相关问题,找出解决方案,决定行动计划。
3.1.2 项目状态周报制度
项目组各组员每周一上午提交周报,提交到乙方项目经理,由安讯软件(上海)有限公司项目经理汇总后提交给甲方项目经理;甲方项目经理根据项目状态,总结项目周报,形成项目组的状态周报,并于每周一下午4点之前上传到版本库中的周报目录上。
3.1.3 沟通手段
开会或直接交谈
按需要组织会议进行沟通,或直接找相关的人进行讨论,注意记录沟通和讨论结果,重要问题讨论必须有书面会议记录。
电话或电话会议
通过电话的方式进行信息沟通。对比较重要的事情,需要包括开发地点以外的人员,则需要利用电话会议的方式进行讨论,沟通。
电子邮件
建立项目组电子邮件系统及与外界联系的电子邮件系统。
- 21 -
Actuate Confidential
5/4/2008
3.2 配置管理
3.2.1 配置管理原则
所有的项目过程文档、代码或项目最终文档、代码的编制工作,都必须在甲方提供的配置环境中进行,所有人员都必须按甲方的配置管理制度进行工作。
3.2.2 配置库管理
配置库分为文档库和代码库。文档库管理项目的所有文档,而代码库管理项目的所有代码,文档及代码库进行基线化管理,按照项目阶段,对文档库和代码库打基线。经测试以及审核后提交产品库,文档与产品由甲方统一管理,未经甲方
同意,不得对任何项进行任何更改。
3.3 变更管理
为了保证项目开发工作的相对稳定性,提高工作效率,确保开发质量。对影响项目计划的变更,制定出处理变更的规范的、统一的方法和过程,估算出因变更引起的相应的资源、费用、和时间的变化以及变更确立后,变更的发布,执行,和过程质量的控制。
),由甲方 本项目成立变更控制委员会,一般为单数组成(甲方人数,乙方,1指定人员任变更控制委员会主任;
变更的审批由变更控制委员会表决决定,2/3人数通过为表决通过,变更控制委员会主任有最终否决权。
如变更控制委员会无法对变更做出最后决定,由变更控制委员会主任将变更申请提交项目管理高层进行裁决。
3.3.1 发起变更
提出变更要求必须填写《变更申请表》(参见附件C“变更申请表”所附表样)。《变更申请表》由变更申请人填写。变更控制委员会审议变更申请的有效性和变更的必要性,决定拒绝变更申请或者要求乙方对申请的变更进行评估。
- 22 -
Actuate Confidential
5/4/2008
3.3.2 评估变更
乙方指定的评估人员要充分评估变更对项目整体计划、进度、费用及质量的影响,进行全面的评估,在五工作日内,填写变更评估表(参见附件C “变更申请表”所附表样),以书面形式提交甲方。
3.3.3 审批变更
变更控制委员会对变更请求进行审批,由变更控制委员会主任签署书面变更审批单,有效变更审批间必须在审批结论中明确是否通过变更申请。
涉及合同变更的不在变更控制委员会审批范围内,根据购买合同规定的条款进行审批。
3.3.4 执行变更
乙方负责根据变更审批结果,调整相关项目计划,根据新的项目计划和项目进度,重新分配资源,对变更展开工作,并指定变更执行评估人员。
变更有关执行人进行变更执行。执行完成后向变更控制委员会报告变更执行情况。
3.3.5 变更执行评估
变更控制委员会中乙方委员负责填报变更执行结果评估表,对执行结果进行评估跟踪,并将结果向变更控制委员会主任报告。
- 23 -
Actuate Confidential
5/4/2008
3.4 质量管理
3.4.1 质量规划
质量目标:针对数据仓库一期系统,确立以下质量目标,甲乙双方应针对以下质量目
标开展质量管理活动:
保证100%满足业务需求要求的正确性与精确性
用户满意度达90%以上
质量管理原则
客户满意度优先
预防优于检查
管理层的责任
持续改进
质量保证计划:合同生效后,甲乙双方应在质量方针、质量目标、质量原则及项目范
围等的前提下建立质量保证计划,明确相关干系人质量管理职责、项目质量管理任务的定义与责任人、需遵守的制度、规程、规范与标准、质量控制的方法、工具、记录与跟踪等,便以此为基础,有效地开展质量管理活动。
测试要求
测试作为项目最主要的验证方式,应该得到双方的高度重视。应达到以下要求:
所有测试必须有适用的测试管理流程,得到质量控制小组的确认
在需求分析阶段,出具用户测试计划,以保证需求的可测试性
在概要设计阶段,出具集成测试计划、集成测试案例
在详细设计阶段,出具单元测试计划、单元测试案例
编码阶段所有模块必须经过单元测试通过,并出具单元测试报告,经双方项目经理
确认
集成测试计划需经评审通过
集成测试必须有两轮以上的测试,每轮测试必须有集成测试报告
用户测试必须由甲方组织测试通过,出具经相关单位盖章的测试报告后,视为完成 在集成测试完成后的程序修改应有足够的回归测试工作,并得到项目质量控制小组
的确认
- 24 -
Actuate Confidential
5/4/2008
3.4.2 质量保证
甲乙双方在项目实施期间应进行以下质量保证活动:
1. 规则的培训与指导
双方项目经理负责组织在项目启动阶段向项目组成员做有关制度、规程、标准、工具与模板的使用培训。
2. 文档管理
文档规范
文档需遵循一定的规范,由双方参照相关国际与国家标准协商制定,需经甲方项目质量控制人员审核通过。 文档标识方法必须有统一的文档编号; 文档应具有相关的定位信息与参考信息等,如:文档作者、完成日期、批准人
员、批准日期、新发布与修订情况、流通清单、机密性限制等
文档批准:所有文档必须经项目经理或质量保证人员的审核通过,正式提
交件必
须经过相关评审认可,参见提交件管理部分。
文档的存储与检索:
存储:双方明确文档存储管理人员,正式提交文件存储应在甲方统一配置管理平台上进行。 文档的流通与检索:经审核的新文档必须按时流通到指定收件人;保证副本的有效、准确、保密性。 文档保密、包括文档的废止:严格按照文档类型的限制访问;防止非授权人员
改变存储的文档;提供电子或纸质的备份;确定存储期限。
3. 需求跟踪管理:甲乙双方项目人员应在项目开发过程建立需求跟踪矩阵,以对需求进
行有效跟踪。
4. 评审、同行评审与走查:在项目需求分析阶段,需求分析说明书在正式提交前均应进
行内部评审工作。在项目设计阶段,相关技术文档均应进行至少一次的同行评审工作,双方质量保证人员负责跟踪缺陷的解决。在项目编码阶段,开发组长应每半月组织至少进行一次代码的走查的工作,开发组长负责缺陷的跟踪。
5. 变更控制:双方均需遵守定义的变更控制流程,具体流程详见变更控制部分
6. 版本管理:对每一阶段的产品,进入集成阶段后,所有的版本控制工作,由甲方指定
- 25 -
Actuate Confidential
5/4/2008
配置管理员统一按有关流程进行发布,甲乙双方其他人员不得以任何形式在测试环境或生产环境进行发布工作。
7. 问题跟踪:乙方负责指定专人对项目实施过程中出现的问题与缺陷进行跟踪解决,每
周出具相关统计信息。
8. 过程审计:质量控制小组定期对项目质量工作进行审计,双方应就审计结论进行相关
整改。
9. 质量汇报:双方项目经理应本着实事求是的原则,向双方管理层及时准确地汇报项目
情况,保证项目的可视性。
3.4.3 质量检查
甲乙双方应就项目进展情况定期进行质量检查工作,保证项目按既定计划,保
证质量地实施。
乙方应配合甲方有关项目管理部门进行质量检查,并及时根据检查结果,进行跟踪解决。
4 工期进度
根据项目生命周期,我们把项目实施分为三个大的阶段,项目整体阶段里程碑工作计划如下:
- 26 -
Actuate Confidential
5/4/2008
5 附录
A. 软硬件配置方案
B. 开发测试工具一览表
C. 变更申请表
D. 安讯9系统性能白皮书
- 27 -
范文二:软件项目标书范本
中国外汇交易中心数据仓库一期项目建议
第二册 技术部分
安讯软件(上海)有限公司
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
3
项目管理 ............................................................................................................................... 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 项目目标
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 先进的报表开发模式
在报表的开发中,我们将采用最先进的协同开发模式,开发人员定制业务逻辑,业务人员根据自己需要通过简单的拖动则可形成自己需要的报表。
IT
设计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 工期进度
根据项目生命周期,我们把项目实施分为三个大的阶段,项目整体阶段里程碑工作计划如下:
5 附录
A. 软硬件配置方案 B. 开发测试工具一览表 C. 变更申请表
D. 安讯9系统性能白皮书
范文三:软件项目投标技术标书
目录
第1章 设计依据与原则 . .................................................... 2
1.1 功能性 . ............................................................ 2
1.2 可靠性 . ............................................................ 2
1.3 易用性 . ............................................................ 2
1.4 效率 . .............................................................. 3
1.5 可维护性 . .......................................................... 3
1.6 可移植性 . .......................................................... 3
1.7 标准化 . ............................................................ 4
第2章 系统总体架构设计 . .................................................. 5
2.1 总体设计要求 . ...................................................... 5
2.2 系统技术架构 . ...................................................... 6
2.2.1 技术架构图 ..................................................... 6
2.2.2 框架介绍 ....................................................... 6
2.3 系统业务逻辑结构 . .................................................. 7
2.4 J2EE 研发平台 ...................................................... 7
2.5 Web 应用服务环境 ................................................... 8
2.6 系统流程设计 . ...................................................... 9
第3章 关键技术解决方案 . ................................................. 10
3.1 基本技术介绍 . ..................................................... 10
3.1.1 MVC 模式 . ...................................................... 10
3.1.2 三层技术 ...................................................... 11
3.2 技术路线的可行性和解决关键技术的途径 . ............................. 13
3.3 数据资源解决方案 . ................................................. 14
3.4 高性能页面响应解决方案 . ........................................... 14
3.5 安全性解决方案 . ................................................... 14
第4章 系统安全解决方案 ..................................................... 16
4.1 物理安全 . ......................................................... 16
4.2 网络层安全 . ....................................................... 16
第5章 网络系统设计 ......................................................... 17
5.1 基本要求 . ......................................................... 17
5.2 应用设计 . ......................................................... 17
5.3 存储设计 . ......................................................... 17
第6章 软硬件环境设计 . ................................................... 18
6.1 硬件环境 . ......................................................... 18
6.1.1 服务器硬件环境配置 ............................................ 18
6.2 软件环境及开发环境 . ............................................... 18
6.2.1 操作系统的选择 ................................................ 18
6.2.2 开发工具及程序设计语言 ........................................ 19
6.2.4 版本控制工具 .................................................. 19
第1章 设计依据与原则
本项目涉及到系统必须以实用为原则。采用成熟的并且通过实践考验的先进技术和解决方案。
1.1 功能性 与一组功能及其指定的性质有关的一组属性,具体包括:
适合性:与规定任务能否提供一组功能以及这组功能的适合程度有关的软件属性。
准确性:与能否得到正确或相符的结果或效果有关的软件属性。
互用性:与同其他指定系统进行交互的能力有关的软件属性。
依从性:使软件遵循有关的标准,约定,法规及类似规定的软件属性。
安全性:与防止对程序及数据的非授权的故意或意外访问的能力有关的软件属性。
充分考虑系统的安全防护,具备较强的数据管理机制和控制能力
1.2 可靠性
与在规定的一段时间和条件下,软件维持其性能水平的能力有关的一组属性,具体包括: 成熟性:与由软件故障引起失效的频度有关的软件属性。 容错性:与在软件故障或违反指定接口的情况下,维持规定的性能水平的能力有关的软件属性。
易恢复性:与在失效发生后,重建其性能水平并恢复直接受影响数据的能力以及为达此目的所需的时间和能力有关的软件属性充分考虑性价比。
1.3 易用性
与一组规定或潜在的用户为使用软件所需作的努力和对这样的使用所作用的评价有关的一组属性,具体包括:
易理解性:与用户为认识逻辑概念及其应用范围所花的努力有关的软件属性。
易学性:与用户为学习软件应用所花的努力有关的软件属性。
易操作性:与用户为操作和运行控制所花努力有关的软件属性。
1.4 效率 与在规定的条件下,软件的性能水平与所使用的资源量之间关系有关的一组属性,具体包括:
时间特性:与软件执行其功能时响应和处理时间以及吞吐量有关的软件属性。
资源特性:与在软件执行其功能时所使用的资源数量及其使用时间有关的软件属性。
1.5 可维护性 与进行指定的修改所需的努力有关的一组属性,具体包括:
易分析性:与为诊断缺陷或失效原因急为判定待修改的部分所需努力有关的软件属性。 易改变性:与进行修改,排除错误或适应环境变化所需努力有关的软件属性。
稳定性:与修改所造成的未预料结果的风险有关的软件属性。
易测试性:与确认已修改软件所需的努力有关的软件属性。
1.6 可移植性 与软件可从某一环境转移到另一个环境的能力有关的一组属性,具体包括:
适应性:与软件无需采用有别于为该软件准备的活动或手段就可能适应不同的规定环境有关的软件属性。
易安装性:与在指定环境下安装软件所需努力有关的软件属性。
遵循性:使软件遵循与可移植性有关的标准或约定的软件属性。
易替换性:与软件在该软件环境中用来替代指定的其他软件的机会和努力有关的软件属性。
1.7 标准化 本项目涉及到的各个系统模块设计、系统性能、代码编写等应符合中国有关软件项目的标准化的要求:
1. 软件开发过程中作业标准化。
2. 确定每个作业的表示形式。
3. 确定每个文档资料的格式。
4. 规定组符号。
5. 根据软件开发经验,制定出大家能够接受的开发原则和进度。
第2章 系统总体架构设计
2.1 总体设计要求
根据市场反应情况和目前软件系统主流的设计思路和方向,本系统总体设计要求如下:
系统采用B/S架构进行设计。 基于J2EE 平台开发。 采用主流技术框架SSH (Spring 、SpringMVC 、Hibernate )。 系统支持主流的关系型数据库:Mysql 、Oracle 、SqlServer 等。
2.2 系统技术架构
2.2.1 技术架构图
技术框架图
2.2.2 框架介绍
系统中采用SSH (Spring 、SpringMVC 、Hibernate )框架。
Spring+SpringMVC+Hibernate三大框架整合项目,java 代码分为
dao,service,controller 三层,支持注解,事务。数据库默认MySQL ,配置文件为src 下的
config 资源包中的db.properties ,以KEY VALUE 形式保存数据库连接属性,方便移植修改。 Hibernate 是一款优秀的ORM 框架,能够连接并操作数据库,包括保存和修改数据。Spring MVC 是Java
的web 框架,能够将Hibernate 集成进去,完成数据的CRUD 。Hibernate 使用方便,配置响应的XML 文件即可。
2.3 系统业务逻辑结构
开发拓扑图
2.4 J2EE 研发平台
J2EE 为搭建具有可伸缩性、灵活性、易维护性的商务系统提供了良好的机制:
J2EE 是一套全然不同于传统应用开发的技术架构,包含许多组件,主要可简化且规范应用系统的开发与部署,进而提高可移植性、安全与再用价值。
J2EE 核心是一组技术规范与指南,其中所包含的各类组件、服务架构及技术层次,均有共同的标准及规格,让各种依循J2EE 架构的不同平台之间,存在良好的兼容性,解决过去企业后端使用的信息产品彼此之间无法兼容,企业内部或外部难以互通的窘境。
J2EE 组件和“标准的” Java 类的不同点在于:它被装配在一个J2EE 应用中,具有固定的格式并遵守J2EE 规范,由J2EE 服务器对其进行管理。J2EE 规范是这样定义J2EE 组件的:客户端应用程序和applet 是运行在客户端的组件;Java Servlet 和Java Server Pages (JSP) 是运行在服务器端的Web 组件;Enterprise Java Bean (EJB )组件是运行在服务器端的业务组件。 2.5 Web 应用服务环境
严格意义上Web 服务器只负责处理HTTP 协议,只能发送静态页面的内容。而JSP ,ASP ,PHP 等动态内容需要通过CGI 、FastCGI 、ISAPI 等接口交给其他程序去处理。这个其他程序就是应用服务器。
比如Web 服务器包括Nginx ,Apache ,IIS 等。而应用服务器包括WebLogic ,JBoss 等。应用服务器一般也支持HTTP 协议,因此界限没这么清晰。但是应用服务器的HTTP 协议部分仅仅是支持,一般不会做特别优化,所以很少有见Tomcat 直接暴露给外面,而是和Nginx 、Apache 等配合,只让Tomcat 处理JSP 和Servlet 部分。
2.6 系统流程设计
第3章 关键技术解决方案
3.1 基本技术介绍
基于当前Web 应用程序开发面临的问题,项目结合目前比较流行的开源框架SSH
(Spring 、Struts 、Hibernate) ,具体讨论其基本相似性及有关基本概念,提出了一种开发JavaEE Web 应用的轻量级解决方案,此系统架构可以在短期内搭建结构清晰、可复用性好、可扩展性好、维护方便的Web 应用程序。
MVC 模式
MVC 模式是一个用于将用户界面逻辑与业务逻辑分离开来的基础设计模式,它将数据处理、界面以及用户的行为控制分为:Model (模型)-View (视图)-Controller (控制器)。 Model:负责当前应用的数据获取与变更及相关的业务逻辑。可用JAVABEAN 来体现; View :负责显示信息。可以使用JSP 、VELOCITY 模板等技术。
其优点有:
Controller :负责收集转化用户的输入。常用一个SERVLET 来实现;
View 和Controller 都依赖于Model ,但是Model 既不依赖于View ,也不依赖于
Controller ,这是分离的主要优点之一,这样Model 可以单独的建立和测试以便于代码复用,View 和Controller 只需要Model 提供数据,它们不会知道、也不会关心数据是存储在SQL Server 还是Oracle 数据库中或者别的什么地方。
3.1.1 三层技术
3.1.1.1 三层结构框架及功能 由于传统的二层C/S结构存在以下几个局限:它是单一服务器且以局域网为中心的,所以难以扩展至广域网范围或Internet 的大型应用模式;难以管理大量的客户机;受限于供应商,整个系统与特定的应用程序联系紧密;软、硬件的组合及集成能力有限。因此, 在乐清电子政务应用系统中以三层结构体系为主。
三层结构是将应用功能分成表示层、业务逻辑层和数据层三部分。其解决方案是对这三层进行明确分割,并在逻辑上使其独立。各层说明如下:
表示层—担负用户与应用间的对话功能,通过浏览器模式实现表示层,组成的B/S结构;或使用可以自动更新的瘦客户端软件实现表示层,组成基于三层体系的“客户/服务器”结构;
业务逻辑层—包含了具体的业务处理逻辑程序相当于应用的本体;
数据层—负责管理对数据库数据的读写。主要是利用大型关系型数据库进行迅速、大量的数据处理。
3.1.1.2 选用三层结构的优点
选用三层结构具有以下优点:
系统管理简单, 大大减少客户机维护工作量。
基于B/S结构的应用模式无需客户端维护工作;基于“客户/服务器”结构的客户端可以实现自动更新下载,也无需客户端维护工作。
具有灵活的硬件系统构成
对于各个层可以选择与其处理负荷和处理特性相适应的硬件,方便的实现负载均衡。清晰、合理地分割三层结构并使其独立, 可以使系统构成的变更非常简单。因此, 被分成三层的应用基本上不需要修正。
提高程序的可维护性 三层B/S结构中,应用的各层可以并行开发, 各层也可以选择各自最适合的开发语言。因为是按层分割功能, 所以各个程序的处理逻辑变得比较简单。
进行严密的安全管理 涉密的关键应用的安全管理非常重要。在三层C/S结构中, 识别用户的机构是按层来构筑的, 对应用和数据的存取权限也可以按层进行设定。例如, 即使外部的入侵者突破了表示层的安全防线,若在功能层中备有另外的安全机构,系统也可以阻止入侵者进入其他部分。
3.1.1.3 中间技术
消息中间件 采用消息中间件技术、基于J2EE 的三层结构构建面向各级单位的数据交换体系中。消息中间件是位于平台(硬件和操作系统) 和应用之间的通用服务,具有标准的程序接口和协议。针对不同的操作系统和硬件平台,它们可以有符合接口和协议规范的多种实现。消息中间件起到了一个“平台+通信”的作用,一方面使进一步的开发工作可以构建在一个统一的开发环境(平台)之上,不必关心具体的网络编程技术细节,大大简化了设计和编程工作;另一方面,中间件完全负责消息通信,用户只需关注于业务系统的运行、开发,有效地提高了效率。
消息中间件通信传输类型: 可靠传输可以在保证报文的正确性的前提下实现相对的实时传输。每个报文有相对的生命周期,在网络超时或者接受方宕机时终止发送请求,即报文有可能丢失或非顺序到达。可靠传输对处理机和网络的开销较小,一般适用于对传输速率要求较高的准实时系统,而对报文的丢失有一定的冗余度。
确保传送可以保证信息的无丢失、按顺序传送。在信息的发送者与接受者之间的网络出现中断或者接受者方的机器出现故障,在网路恢复连接后,仍然能保证在故障时期内的所有信息按顺序的正确到达。确保传送的高可靠性是以较多的资源开销(处理机、网络)作为代价的。因此,确保传送一般是用于传送频率比较低,但传送可靠性要求高的信息传输,如重要文件的传输等。该传输类型类似于电子邮件的传输方式。
数据中间件 在综合数据支撑平台中,为了整合桌面型数据库成为一个可共享的具有用户和权限管理的虚拟数据库,需要采用数据中间件以屏蔽掉数据节点分布、数据库表异构特性,实现虚拟数据库合理的软件层次结构。
3.1.1.4 安全应用技术 为了在电子政务系统的应用层、网络层实施细粒度的访问控制,实现对用户的身份鉴别、实现信息的保密性、完整性、真实性和抗抵赖性等保护,采用当今流行的高强度安全策略——数字证书技术。应用系统可以基于数字证书以及相关的经国家有关部门认可的密码算法认证登录系统的用户的真实身份,进行数字签名和验证签名,采用数字签名技术解决抗抵赖性和数据完整性的问题,利用安全系统提供的加密算法,解决信息的保密性问题。
对重要数据库的访问,还要通过安全代理,对访问者的身份基于数字证书进行高强度的认证,对其访问应用系统的请求进行确认,如果该用户没有访问的权限,其访问请求将被安全代理拒绝。同时,在安全代理服务器上还可以完成包括包过滤、加密、解密等技术,从而实现权限确认和数据的密存密传功能。
3.2 技术路线的可行性和解决关键技术的途径 三层应用构架是一种成熟的开发模式,可以应用到电子政务中,针对行文应用的特殊要求,建议Domino 平台这一成熟的体系,以确保电子政务的正常运作。
Java 技术是一种成熟的技术,已经得到广泛的应用,J2EE 技术规范已经得到大的中间件生成厂商如BEA 公司、IBM 公司的产品化支持。
中间件技术是软件产品的发展方向,现在市场上已有大量的产品可供选择,因此在结合电子政务需求开发数据中间件是可行的,在数据交换体系中采用消息中间件已是可行的,符合发展方向。
安全应用技术是电子政务中的一种重要指标,国内许多单位进行过大量的研发工作,有的已形成了产品,因此也具有可行性。
虚拟数据库是解决数据共享、系统平滑过渡的必又之路,结合数据库技术和中间件技术,一定能达到目标,创优质工程。
3.3 数据资源解决方案 对不能(不方便)共享的桌面型数据库,为暂时维持现有应用不变且又能提供数据资源共享,提出了一个完备的基于整体应用的数据库解决方案——即虚拟数据库解决方案。其基本思想是将分散的、局部的桌面形数据库(Foxpro 、Access )利用网络资源以及虚拟数据库应用将它们在逻辑上统一起来,实现呈现给用户一个完整的、统一的数据库访问模式,同时提供数据资源的用户和权限管理功能,即对用户以及应用程序来说就好像访问大型关系型数据库一样方便地访问数据资源,而不是在访问分散于不同服务终端的数据库,所有的处理都将在虚拟数据库构架中完成,不需要用户或应用程序涉及任何底层的输入。
3.4 高性能页面响应解决方案 从系统角度来理解软件,确定对所开发系统的综合要求,并提出这些需求的实现条件, 以及需求应该达到的标准。这些需求包括:功能需求(做什么) ,性能需求(要达到什么指标) , 环境需求(如机型, 操作系统等) ,可靠性需求(不发生故障的概率), 安全保密需求, 用户界面需求,资源使用需求(软件运行是所需的内存、CPU 等) ,软件成本消耗与开发进度需求,预先估计以后系统可能达到的目标。
3.5 安全性解决方案
安全性测试主要是测试系统在没有授权的内部或者外部用户对系统进行攻击或者恶意破坏时如何进行处理,是否仍能保证数据和页面的安全。测试人员可以学习一些黑客技术,来对系统进行攻击。 另外,对操作权限的测试也包含在安全性测试中。具体测试内容如下:
o 执行添加、删除、修改等动作中是否做过登录检测。
o 退出系统之后的操作是否可以完成。
o 所有插入表单操作中输入特殊字符是否可以正常输正常存储,特殊字符为:!?#
¥%??—*()~——-+=[]{}、|;:‘”?/《》<>,。
o 在带有参数的回显数据的动作中更改参数,把参数改为特殊字符并加入操
o 测试表单中有没有做标签检测,标签检测是否完整。
第4章 系统安全解决方案
4.1 物理安全
保证计算机系统安全,可靠地运行,确保系统在对信息进行采集、传输、存储、处理、显示、分发和利用的过程中不会受到人为或自然因素的危害而使信息丢失、泄漏和破坏,对计算机系统设备、通信与网络设备、存储媒体设备和人员所采取的安全技术措施,实体安全包括环境安全,设备安全和媒体安全三个方面。
环境安全包括受灾防护、区域防护,设备安全包括设备防盗、设备防毁、防止电磁信息泄露、防止线路截获、抗电磁干扰、电源保护等,媒体安全是媒体数据和媒体本身。
4.2 网络层安全
为保护数据处理系统而采取的技术的和管理的安全措施,保护计算机硬件、软件和数据不会因偶然和故意的原因而遭到破坏、更改和泄露。
4.2.1防火墙策略
防火墙指的是一个由软件和硬件设备组合而成,在内部网和外部网之间专,用网与公共网之间的界面上构造的保护屏障,是一种获取安全性方法的形象说法,它是一种计算机硬件和软件的结合,使Internet 与Intranet 之间建立起一个安全网关(Security Gateway),从而保护内部网免受非法用户的侵入,防火墙主要由服务访问规则、验证工具、包过滤和应用网关4个部分组成,防火墙就是一个位于计算机和它所连接的网络之间的软件或硬件,该计算机流入流出的所有网络通信和数据包均要经过此防火墙。
4.2.2 拒绝服务攻击的防范
分布式拒绝服务(DDoS:Distributed Denial of Service)攻击指借助于客户/服务器技术,将多个计算机联合起来作为攻击平台,对一个或多个目标发动DDoS 攻击,从而成倍地提高拒绝服务攻击的威力。通常,攻击者使用一个偷窃帐号将DDoS 主控程序安装在一个计算机上,在一个设定的时间主控程序将与大量代理程序通讯,代理程序已经被安装在网络上的许多计算机上,代理程序收到指令时就发动攻击,利用客户/服务器技术,主控程序能在几秒钟内激活成百上千次代理程序的运行。
第5章 网络系统设计
5.1 基本要求
本系统所有涉及软件要求基于J2EE 平台开发,并且达到以下要求:
系统将采用B/S结构。
系统将采用多层架构的体系结构。
系统中采用SSH (Spring 、SpringMVC 、Hibernate )框架。
5.2 应用设计 本方案采用多层架构技术,实现项目的可扩展性、可维护性,以及结合其他相关技术保障项目能成功实施。MVC 模式是一个用于将用户界面逻辑与业务逻辑分离开来的基础设计模式,它将数据处理、界面以及用户的行为控制分为:Model (模型)-View (视图)-Controller (控制器)。
1、 Model :负责当前应用的数据获取与变更及相关的业务逻辑,可用JAVABEAN 来体现。
2、 View :负责显示信息,可以使用JSP 、VELOCITY 模板等技术。
3、 Controller :负责收集转化用户的输入,常用一个SERVLET 来实现。 5.3 存储设计
提供高可靠性的数据存放,通过存储系统的可靠性设计以及磁盘镜像、RAID 技术,保证存储介质内数据的可靠性。
第6章 软硬件环境设计
6.1 硬件环境
6.1.1 服务器硬件环境配置
6.2 软件环境及开发环境
软件环境解决方案主要包括操作系统的选择、数据库环境、开发工具及程序设计语言、测试工具、版本控制工具。
6.2.1 操作系统的选择
Windows: 向后兼容性、广泛的外围兼容性、多显示器支持、多任务处理等。
主流操作系统对比表
6.2.2 开发工具及程序设计语言 代码编写:MyEclipse
编写语言:Java (后台)、B-JUI(前端)
数据库开发:MySQL5.5.43
6.2.3 测试工具 功能测试自动化:QTP 、Selenium 、Loadrunner 、Jmeter 等。
测试管理工具:MQC 、禅道、JIRA 等。
6.2.4 版本控制工具 版本控制工具:SVN
版本控制是对已做成的软件在发展过程中的一种质量管理,各大公司对自己的软件均有一套版本控制方法。我们开发的软件系统绝不是“一锤子买卖”,推出了第一期软件的试用版,还会有第二期软件补充进来,两期软件到一定阶段都将定为正式版,而且今后还会继续发展,到一定时候还要更新。何时定为正式版,何时宣布版本升级,都需要有明确的要求和界限,两个版本之间的任何修改和维护都需要一套管理办法。升级也好,更新也好,都需要考虑与原来版本的兼容,以保护用户的投资利益。
范文四:软件项目投标书 软件项目投标技术标书
导读:就爱阅读网友为您分享以下“软件项目投标技术标书”的资讯,希望对您有所帮助,感谢您对92to.com的支持!
第64页
测试项目及方法: (一)、单元测试方法 (二)、单元测试过程 。
6.1.8 系统测试计划
。
6.2 功能测试
1
。
我们将编制测试项目来验证所有系统功能是否满足,在本项目系统的测试中,我们将至少进行以下功能的测试:
表格-功能测试内容列表
测试系统:GGZHJGF信息平台(以下简写为PT);企业端(CMP);手持终端(MV)
第65页
第66页
6.3 数据准确性测试
。
6.4 极限度测试
2
:
6.4.1 负载测试
。
第67页
LOGO
GG市xxxxx管理局
XXXXXXXXXX平台建设项目
招标编号: XXXXXXXX-XXX
技
3
术
文
件
单位全称(公章):浙江某某有限公司
地 址:
邮 编:310000
时 间:2013年06月05日
目录
第一部分 评标响应导
读 .................................................................... 1
第1章 项目名称 ......................................................................
4
2
第2章 技术响应、评审评分应答导读
表 .................................................. 3
2.1 技术响应导读表 ............................................................... 3
2.2 评审评分应答导读表 ........................................................... 4
第二部分 技术解决方
案 .................................................................... 6
第1章 项目描述 ...................................................................... 7
1.1 项目概述 ..................................................................... 7
1.2 建设的必要性 ................................................................. 7
1.3 现状与差距 ................................................................... 7
5
1.4 建设内容 ..................................................................... 7
第2章 我方在本项目上的优
势 .......................................................... 8
2.1 公司优势 ..................................................................... 8
2.2 需求把握优势 ................................................................. 8
2.3 技术团队优势 ................................................................. 8
2.4 服务优势 ..................................................................... 8
第3章 设计依据与原
则 ................................................................ 9
3.1 项目建设参考标准及设计依
据 ................................................... 9
3.2 设计原则 ..................................................................... 9
3.2.1 充分考虑性价比 ......................................................... 9
6
3.2.2 实效性和共享性 ......................................................... 9
3.2.3 标准化 ................................................................. 9
3.2.4 健壮性 ................................................................. 9
3.2.5 扩充性 ................................................................. 9
3.2.6 易维护性 .............................................................. 10
3.2.7 开放性 ................................................................ 10
3.2.8 可移植性 .............................................................. 10
3.2.9 安全性和可靠性 ........................................................ 10
3.3 质量标准与管理规范 .......................................................... 10
3.4 本项目的建设原则 ............................................................ 10
7
第4章 系统总体架构设
计 ............................................................. 11
4.1 总体设计要求 ................................................................ 11
4.2 系统功能、框架构成设
计 ...................................................... 11
8
范文五:软件项目招标文件技术标书
(此文档为word 格式, 下载后您可任意修改编辑!)
12.4.2 供应商针对本项目技术服务类总体要求的理解
在软件开发的过程中,我们一向遵循软件产品的以下原则:
1、功能性:与一组功能及其指定的性质有关的一组属性,具体包括:
适合性:与规定任务能否提供一组功能以及这组功能的适合程度有关的软件属性
准确性:与能否得到正确或相符的结果或效果有关的软件属性
互用性:与同其他指定系统进行交互的能力有关的软件属性
依从性:使软件遵循有关的标准, 约定, 法规及类似规定的软件属性
安全性:与防止对程序及数据的非授权的故意或意外访问的能力有关的软件属性
2、可靠性:与在规定的一段时间和条件下, 软件维持其性能水平的能力有关的一组属性,具体包括:
成熟性:与由软件故障引起失效的频度有关的软件属性
容错性:与在软件故障或违反指定接口的情况下, 维持规定的性能水平的能力有关的软件属性
易恢复性:与在失效发生后, 重建其性能水平并恢复直接受影响数据的能力以及为达此目的所需的时间和能力有关的软件属性
3、易用性:与一组规定或潜在的用户为使用软件所需作的努力和对这样的使用所作的评价有关的一组属性,具体包括:
易理解性:与用户为认识逻辑概念及其应用范围所花的努力有关的软件属性
易学性:与用户为学习软件应用所花的努力有关的软件属性
易操作性:与用户为操作和运行控制所花努力有关的软件属性
4、效率:与在规定的条件下, 软件的性能水平与所使用资源量之间关系有关的一组属性,具体包括:
时间特性:与软件执行其功能时响应和处理时间以及吞吐量有关的软件属性
资源特性:与在软件执行其功能时所使用的资源数量及其使用时间有关的软件属性
5、可维护性:与进行指定的修改所需的努力有关的一组属性,具体包括:
易分析性:与为诊断缺陷或失效原因及为判定待修改的部分所需努力有关的软件属性 易改变性:与进行修改, 排除错误或适应环境变化所需努力有关的软件属性
稳定性:与修改所造成的未预料结果的风险有关的软件属性
易测试性:与确认已修改软件所需的努力有关的软件属性
6、可移植性:与软件可从某一环境转移到另一环境的能力有关的一组属性,具体包括: 适应性:与软件无需采用有别于为该软件准备的活动或手段就可能适应不同的规定环境有关的软件属性
易安装性:与在指定环境下安装软件所需努力有关的软件属性
遵循性:使软件遵循与可移植性有关的标准或约定的软件属性
易替换性:与软件在该软件环境中用来替代指定的其他软件的机会和努力有关的软件属性
基于以上原则,根据项目的不同需求,我们将会考虑采用B/S和C/S两种模式开发。
1、B/S模式
B/S是Brower/Server的缩写,客户机上只要安装一个浏览器(Browser ),如Netscape Navigator 或Internet Explorer,服务器安装Oracle 、Sybase 、Informix 或 SQL Server等数据库。浏览器通过Web Server 同数据库进行数据交互。B/S模式较C/S模式:
C/S模式客户端需要安装专用的客户端软件。首先涉及到安装的工作量,其次任何一台电脑出问题,如病毒、硬件损坏,都需要进行安装或维护。特别是有很多分部的情况,不是工作量的问题,而是路程的问题。还有,系统软件升级时,每一台客户机需要重新安装,其维护和升级成本非常高。C/S模式对客户端的操作系统一般也会有限制,可能适应于Windows 系列操作系统,而不适用于Linux 、Unix 等操作系统。
而B/S最大的优点就是可以在任何地方进行操作而不用安装任何专门的软件。只要有一台能上网的电脑就能使用,客户端零维护。系统的扩展非常容易,只要能上网,再由系统管理员分配一个用户名和密码,就可以使用了。甚至可以在线申请,通过公司内部的安全认证(如CA 证书)后,不需要人的参与,系统可以自动分配给用户一个账号进入系统,这在最大程度上满足了项目要求。
系统采用的是目前较流行的一种Web 应用程序开源框架--Struts+Spring+Hibernate(SSH )。
集成SSH 框架的系统从职责上分为四层:表示层、业务逻辑层、数据持久层和域模块层,以帮助开发人员在短期内搭建结构清晰、可复用性好、维护方便的Web 应用程序。其中使用Struts 作为系统的整体基础架构,负责MVC 的分离,在Struts 框架的模型部分,利用Hibernate 框架对持久层提供支持,业务层用Spring 支持。具体做法是:用面向对象的分析方法根据需求提出一些模型,将这些模型实现为基本的Java 对象,然后编写基本的DAO 接口,并给出Hibernate 的DAO 实现,采用Hibernate 架构实现的DAO 类来实现Java 类与数据库之间的转换和访问,最后由Spring 完成业务逻辑。 系统的基本业务流程是: 在表示层中,首先通过JSP 页面实现交互界面,负责传送请求(Request)和接收响应(Response),然后Struts 根据配置文件
(struts-config.xml)将ActionServlet 接收到的Request 委派给相应的Action 处理。在业务层中,管理服务组件的Spring IoC容器负责向Action 提供业务模型(Model)组件和该组件的协作对象数据处理(DAO)组件完成业务逻辑,并提供事务处理、缓冲池等容器组件以提升系统性能和保证数据的完整性。而在持久层中,则依赖于
Hibernate 的对象化映射和数据库交互,处理DAO 组件请求的数据,并返回处理结果。
采用上述开发模型,不仅实现了视图、控制器与模型的彻底分离,而且还实现了业务逻辑层与持久层的分离。这样无论前端如何变化,模型层只需很少的改动,并且数据库的变化也不会对前端有所影响,大大提高了系统的可复用性。而且由于不同层之间耦合度小,有利于团队成员并行工作,大大提高了开发效率的同时,也保证了软件产品的质量。
2、C/S模式
C/S (Client/Server,客户机/服务器)模式又称C/S结构,是20世纪80年代末逐步成长起来的一种模式,是软件系统体系结构的一种。C/S结构的关键在于功能的分布,一些功能放在前端机(即客户机)上执行,另一些功能放在后端机(即服务器)上执行。功能的分布在于减少计算机系统的各种瓶颈问题。C/S模式简单地讲就是基于企业内部网络的应用系统。与B/S(Browser/Server,浏览器/服务器)模式相比,C/S模式的应用系统最大的好处是不依赖企业外网环境,即无论企业是否能够上网,都不影响应用。
C/S结构服务器通常采用高性能的PC 、工作站或小型机,并采用大型数据库系统,如ORACLE 、SYBASE 、InfORMix 或 SQL Server。客户端需要安装专用的客户端软件。
C/S结构的优点是能充分发挥客户端PC 的处理能力,很多工作可以在客户端处理后再提交给服务器, 因此对应的优点就是客户端响应速度快。
C/S架构软件的优势与劣势:
(1)应用服务器运行数据负荷较轻。最简单的C/S体系结构的数据库应用由两部分组成,即客户应用程序和数据库服务器程序。二者可分别称为前台程序与后台程序。运行数据库服务器程序的机器,也称为应用服务器。一旦服务器程序被启动,就随时等待响应客户程序发来的请求;客户应用程序运行在用户自己的电脑上,对应于数据库服务器,可称为客户电脑,当需要对数据库中的数据进行任何操作时,客户程序就自动地寻找服务器程序,并向其发出请求,服务器程序根据预定的规则作出应答,送回结果,应用服务器运行数据负荷较轻。
(2)数据的储存管理功能较为透明。在数据库应用中,数据的储存管理功能,是由服务器程序和客户应用程序分别独立进行的,并且通常把那些不同的(不管是已知还是未知的)前台应用所不能违反的规则,在服务器程序中集中实现,例如访问者的权限,编号可以重复、必须有客户才能建立定单这样的规则。所有这些,对于工作在前台程序上的最终用户,是“透明”的,他们无须过问(通常也无法干涉)背后的过程,就可以完成自己的一切工作。在客户服务器架构的应用中,前台程序不是非常“瘦小”,麻烦的事情都交给了服务器和网络。在C/S体系的下,数据库不能真正成为公共、专业化的仓库,它受到独立的专门管理。 C/S模式系统的开发:
C/S结构是建立在中间件产品基础之上的,要求应用开发者自己去处理事务管理、消息队列、数据的复制和同步、通信安全等系统级的问题。这对应 用开发者提出了较高的要求,而且迫使应用开发者投入很多精力来解决应用程序以外的问题。这使得应用程序的维护、移植和互操作变得复杂。如果客户端是在不同的操作系统上,C/S结构的软件需要开发不同版本的客户端软件。但是,与B/S结构相比,C/S技术发展历史更为“悠久”。从技术成熟度及软件设计、开发 人员的掌握水平来看,C/S技术应是更成熟、更可靠的。
12.4.3 项目总体架构及技术解决方案
一、项目总体架构
(一)、SSH 框架介绍和分析
大型企业级Web 应用系统的开发通常要求有一个良好的软件架构、便于协作开发和扩展升级,而传统的开发模式不能很好地满足这些要求。
基于当前Web 应用程序开发面临的问题,项目结合目前比较流行的开源框架SSH (Spring 、Struts 、Hibernate) ,具体讨论其基本相似性及有关基本概念,提出了一种开发JavaEE Web 应用的轻量级解决方案,此系统架构可以在短期内搭建结构清晰、可复用性好、可扩展性好、维护方便的Web 应用程序。
1、框架技术
框架一般具有即插即用的可重用性、成熟的稳定性以及良好的团队协作性。JavaEE 复杂的多层结构决定了大型的JavaEE 项目需要运用框架和设计模式来控制软件质量。目前,市场上出现了一些商业的、开源的基于JavaEE 的应用框架,其中主流的框架技术有:基于MVC 模式的Struts 框架、基于IoC 模式的Spring 框架以及对象/关系映射框架Hibernate 等。
2、框架共同点
所有现代的网络开发框架几乎都遵循了模型-视图-控制(MVC)设计模式:商业逻辑和描述被分开,由一个逻辑流控制器来协调来自客户端的请求和服务器上将采取的行动。这条途径成为了网络开发的事实上的标准。每个框架的内在的机制当然是不同的,但是开发者们使用来设计和实现他们的Web 应用软件的API 是很类似的。差别还存在于每个框架提供的扩展方面, 例如标签库,JavaBean 包装器等。
所有的框架使用不同的技术来协调在Web 应用程序之内的导航, 例如XML 配制文件,java 属性文件或定制属性。所有的框架在控制器模块实现的方法方面也存在明显的不同。例如,EJB 可能实例化在每个请求中需要的类或使用Java 反射动态地调用一个适当的行为(Action )类。另外, 不同框架在各自引入的概念上也有所不同。例如, 一个框架可能定义用户请求和反应场所,而另外一个框架可能仅仅定义一个完整的流:从一个请求到多个响答和随后的再请求。
各种Java 框架在它们组织数据流的方法方面是很类似的。在请求发出后,在应用程序服务器上产生一些行动;而作为响应,一些可能包含对象集的数据总是被发送到WEB 层。然后从那些对象:可能是有setter 和getter 方法的简单类、JAVABEANS 、值对象、或者一些集合对象中提取数据。现代的Java 框架还想方设法简化开发者的开发任务,如通过使用简易的API 、数据库连接池、甚至数据库调用包等提供自动化的追踪方式来实现。一些框架或者能够钩进(hooked into )另外的JavaEE 技术中, 例如JMS(Java消息服务) 或JMX, 或把这些技术集成到一起。服务器数据持续性和日志也有可能成为框架的一部分。
3、MVC 模式
MVC 模式是一个用于将用户界面逻辑与业务逻辑分离开来的基础设计模式,它将数据处理、界面以及用户的行为控制分为:Model (模型)-View (视图)-Controller (控制器)。 Model:负责当前应用的数据获取与变更及相关的业务逻辑。可用JAVABEAN 来体现; View:负责显示信息。可以使用JSP 、VELOCITY 模板等技术;
Controller:负责收集转化用户的输入。常用一个SERVLET 来实现;
View 和Controller 都依赖于Model ,但是Model 既不依赖于View ,也不依赖于
Controller ,这是分离的主要优点之一,这样Model 可以单独的建立和测试以便于代码复用,View 和Controller 只需要Model 提供数据,它们不会知道、也不会关心数据是存储在SQL Server 还是Oracle 数据库中或者别的什么地方。
4、 WEB层框架Struts
Struts是一个在JSP Model2基础上实现的MVC 框架,其主要的设计理念是通过控制器将表现逻辑和业务逻辑解耦,以提高系统的可维护性、可扩展性及可重用性。Struts 框架的体系结构如下图所示:
下面就上图所示的体系结构图分析Struts 框架中的MVC 组件。
视图(view):视图部分主要由JSP 页面组成,其中没有流程逻辑、业务逻辑和模型
信息,只有标记。Struts 自身包含了一组标记库(TagLib),这也是Struts 的精华之一,灵活运用它们可以简化JSP 页面的代码,提高开发效率。
控制器(controller):Struts 中的Controller 主要是其自身提供的
ActionServlet 。ActionServlet 接收所有来自客户端的请求并根据配置文件(struts-config.xml)中的定义将控制转移到适当的Action 对象。
模型(model):Struts 没有定义具体Model 层的实现,Model 层通常是和业务逻辑
紧密相关的,有持续化的要求。目前在商业领域和开源世界,都有一些优秀的工具可以为Model 层的开发提供便利。
5、业务逻辑层框架Spring
Spring是一个解决了许多JavaEE 开发中常见问题并能够替代EJB 技术的强大的轻量级框架。这里所说的轻量级指的是Spring 框架本身,而不是指Spring 只能用于轻量级的应用开发。Spring 的轻盈体现在其框架本身的基础结构以及对其他应用工具的支持和装配能力。与EJB 这种庞然大物相比,Spring 可使程序研发人员把各个技术层次之间的风险降低。 Spring框架的核心是控制翻转IoC(Inversion of Control)/依赖注入DI(Dependence Injection) 机制。IoC 是指由容器中控制组件之间的关系(这里,容器是指为组件提供特定服务和技术支持的一个标准化的运行时的环境)而非传统实现中由程序代码直接操控,这种将控制权由程序代码到外部容器的转移,称为“翻转”。DI 是对IoC 更形象的解释,即由容器在运行期间动态地将依赖关系(如构造参数、构造对象或接口) 注入到组件之中。Spring 采用设值注入(使用Setter 方法实现依赖) 和构造子注入(在构造方法中实现依赖) 的机制,通过配置文件管理组建的协作对象,创建可以构造组件的IoC 容器。这样,不需要编写工厂模式、单例模式或者其他构造的方法,就可以通过容器直接获取所需的业务组件。Spring 框架的结构如下图所示。
Spring框架由七个定义明确的模块组成,且每个模块或组件都可以单独存在,或者与