银行软件开发需求开发和管理系统架构设计说明书模板1.doc

银行软件开发需求开发和管理系统架构设计说明书模板1.doc

《银行软件开发需求开发和管理系统架构设计说明书模板1.doc》由会员分享，可在线阅读，更多相关《银行软件开发需求开发和管理系统架构设计说明书模板1.doc（13页珍藏版）》请在冰点文库上搜索。

架构设计

Xxxxx架构设计

版本：

V1.0

文档编号

保密等级

作者

最后修改日期

审核人

最后审批日期

批准人

最后批准日期

修订记录

日期

版本

修订说明

修订人

目录

1 引言 1

1.1 编写目的 1

1.1.1 作用 1

1.1.2 预期读者 1

1.2 编写背景 1

1.2.1 系统名称及版本号 1

1.2.2 任务提出者 1

1.2.3 任务承接者及实施者 1

1.2.4 使用者 1

1.2.5 与其它系统的关系 2

1.3 文档结构 2

1.4 电子文档编写工具 2

1.5 定义说明与符号规定 2

1.6 参考资料 3

2 系统特点分析 3

2.1 用户群 3

2.2 约束 3

2.2.1 技术约束 3

2.2.2 资源约束 4

2.2.3 时间约束 4

2.2.4 未来系统规划 4

2.2.5 已有系统状况 5

2.3 名词解释 5

3 系统技术架构 6

3.1 架构分析 6

3.2 运行环境 6

3.2.1 硬件平台 6

3.2.2 软件平台 6

3.2.3 系统部署架构 7

3.3 系统整体结构概述 7

4 关键技术 7

4.1 ETL 7

5 实施方法 8

5.1 并行开发 8

5.2 分阶段测试 8

5.2.1 报表打印测试 8

5.2.2 数据计算正确性测试 9

5.2.3 系统处理性能测试 9

第9页

1引言

1.1编写目的

1.1.1作用

【说明】《软件概要设计说明书》是在《软件需求规格说明书》的基础上，通过我方与用户方反复沟通形成的。

它必须充分反映《软件需求规格说明书》中的用户需求，如有改动必须征得用户的认可。

它将作为项目验收时重要的的标准和依据。

从另一方面讲，它又是开发人员在下一阶段进行系统详细设计的纲领性文件，也是考核系统总体质量的重要技术文档。

1.1.2预期读者

【说明】本文档的阅读对象是软件开发人员、业务规范设计人员、软件测试人员、系统安装人员及用户代表。

1.2编写背景

1.2.1系统名称及版本号

【说明】形如“北京市地方税务局管理信息系统V3.0”。

其中，版本号的格式为“XX.XX”，X为阿拉伯数字，左“0”可省略。

1.2.2任务提出者

【说明】指《工作说明书》中规定的我方领导机构或项目负责人。

1.2.3任务承接者及实施者

【说明】指承担概要设计的负责人及工作人员名单。

1.2.4使用者

【说明】适应对象和范围。

主要指预期读者，也供有关领导审阅。

1.2.5与其它系统的关系

【说明】在用户现有的及预期的整个应用系统中，给本系统准确定位。

用示意图及相应的文字予以说明。

1.3文档结构

【说明】章节划分原则、内容的取舍、重点的确定等。

1.4电子文档编写工具

【说明】工具名、版本号、操作系统平台。

使用多种工具时，应分别说明。

形如：

MicrosoftWord97forWindows95

Power-Designor6.0forWindows95

PhotoShop4.0forWindows95

Visio或PowerPoint

1.5定义说明与符号规定

【说明】包括对专用术语及缩略语的解释、所用到的图（E-R图/功能层次图）中图符的表示与解释、屏幕界面中图标与按钮的表示与含义等。

如在E-R图中，表示两个实体之间的关系时，我们定义了以下图符（部分举例）：

终结符基数（自左至右）

1

多

终结符基数存在性说明（自左至右）

1强制必须存在且只能存在1个

多强制必须存在1个或多个

1任选可能存在1个，或没有

多任选可能存在1个或多个，或没有

1.6参考资料

【说明】格式：

作者，[版本号，]资料来源，日期[，起止页号]。

其中，《质量保证计划》与《需求规格说明书》是必选的参考资料。

2系统特点分析

2.1用户群

【说明】

1．用户群的划分依据，人群范围。

2．用户群的数量，并发数量，访问高峰数量及时间。

3．本系统不同用户群对系统操作的要求，如使用数据录入、数据生成、多维分析。

2.2约束

【说明】本系统建设需要考虑的约束

1．技术约束

2．时间约束

3．资源约束

4．系统现状约束

5．未来系统规划

2.2.1技术约束

目前开发银行的KM系统实际上除了担负Symbols的数据展现之外，同时还承担了数据仓库的部分重担，但是从存储容量到整体规划性上还远不能达到全开发银行未来企业级数据仓库的层次。

本项目只能在已有条件的基础上将未来的影响限制在一个合理的范围之内。

这个影响主要来自于两个方面：

a.数据平台实施后数据源将发生变动。

数据源的变动将影响已经实施的ETL过程，如果采用数据库程序的方式进行ETL开发必然会出现因字段名散布在大量代码中，ETL程序必须进行全面调整的问题。

但是如果考虑使用ETL工具，因为ETL流程定义中的每个阶段都要定义前一步与后一步的字段MAP关系，因此不存在一个字段名从前到后贯穿的情况，因此主要的调整工作量集中在数据源的定义上，可以将变动的工作量降到比较低的程度。

另外通过附加中间接口表，增加转换的ETL过程也可以减少对已开发程序的改动。

但是考虑到系统结构清晰、元数据管理的目标，计划使用ETL工具应对数据源的变动。

b.数据平台实施后将对公共的基础数据提供统一的计算支持，可能出现数据计算结果不一致的问题。

目前多个项目都是从生产系统的流水数据进行计算汇总，已经出现业务理解不同，数据计算不同等诸多问题。

因此本项目中将在原始数据与分析集市之间增加一个中间计算层，负责技术含义的业务流水到业务含义的业务明细数据的计算。

在未来数据平台建立之后，将本项目中的中间计算层作为公共数据计算的基础进行扩充，避免各自形成一套计算体系。

2.2.2资源约束

1．数据不是简单汇总，存在较多的业务规则和处理条件，对业务全面了解的人不多。

2．没有了解Cognos工具的技术人员。

2.2.3时间约束

1．项目的时间紧张，在1月份之前要交付70张左右的报表。

2.2.4未来系统规划

1．本项目在规划中属于管理分析决策系统，负责数据展现

2．数据使用上必须符合数据平台的统一规划

3．未来数据平台必须具备元数据管理的能力

4．目前数据平台项目并没有启动

5．该业务局目前制定了一个BM系统未来开发需求，由DC负责需求整理，目前在收尾阶段

2.2.5已有系统状况

1．该客户在行内前期已经主持过使用Cognos和Hyperin开发的分析型系统，客户明确提出使用Cognos作为本期的报表及分析工具。

2．行内已经开发过KM、总帐、贷款有效发放、信用风险管理等多套与报表相关的系统，使用各自的访问界面，除信用风险管理之外都为DC参与开发，因此本系统不能再增加新的独立用户界面，要考虑和已有系统进行集成。

2.3名词解释

KM：

KnowledgeManagementSystem由SA公司提供的基于Symbols的历史数据库，同时提供部分报表数据计算及OracleDiscoverer下的ROLAP模型。

Symbols：

SA公司提供的银行会计核算系统

经营管理分析：

开发银行综合计划局主导的全行经营管理统计分析项目，目前处于业务需求阶段

II项目：

为了陈元行长的要求，经营管理分析项目中的部分急需报表的开发项目。

GL：

由Oracle公司提供的总账系统

明宇：

由深圳明宇科技有限公司提供的固定报表开发工具，在开发银行的财务报表中广泛使用，适合开发资产负债、等复杂格式报表，开行在核心系统一期项目中已经采购。

3系统技术架构

3.1架构分析

CDBII系统是典型的数据仓库类项目。

CBDII的数据需求面向具体应用的需求，属于数据仓库建设中的一个集市，又因为与BM的分析性需求来自同一个业务部门，在一些实质的目标上也比较接近，都属于总行级的统计分析目的，将来可能考虑以本集市为基础建立更大范围的BM分析应用。

需要建立数据层次，避免数据源波动对最终的集市造成影响…………

通过ETL工具建立数据清洗过程………….

系统需要建立在xxx、yyy系统的数据基础之上………..

3.2运行环境

3.2.1硬件平台

【说明】指出本系统对硬件设备的需求、我们选型的原则和依据、推荐的型号与配置、性能综述、技术优势、特殊约定等。

3.2.2软件平台

【说明】使用操作系统的名称、生产厂家、版本号等。

使用数据库的名称、生产厂家、版本号等。

如使用了多种数据库，则要说明如何实现互连。

其它支撑软件：

指出开发与运行时需要的工具软件的情况，如4GL等。

对于选用的各类软件，均应着重说清其技术特点、与国内外同类产品的比较，明确阐述我方选择的理由。

3.2.3系统部署架构

【说明】写明网络设计原则、技术要求、产品选型、拓扑结构、基本部件与配件、传输介质、接口情况、通信协议、约束条件、结构化综合布线方案等。

画出网络结构图。

图中应标出各类服务器与客户机、网管机、路由器、网关等的数量与分布；应反映出局域网、广域网及其互连的情况；如使用国内的公用数据网或Internet，也须具体标出。

用文字说明各个服务器/客户机的作用、配置与具体位置。

例如：

Oracle数据库服务器1台，位于局信息中心，用于支撑征管业务信息处理、领导决策辅助支持、各征管业务科室的信息采集、查询及统计工作。

它安装在IBMRS6000小型机上，操作系统是AIX3.2。

说明拟采取的网络保护技术，如防火墙等。

3.3系统整体结构概述

【说明】说明本系统的各层模块、公用模块的划分原则。

如果系统复杂而开发者又有比较多的技术积累，应说明其分层构造（如组件层、构件层与应用子系统层）。

对于大的系统，应画出体系结构图并予以说明。

4关键技术

5实施方法

制定《报表类项目开发流程指南.doc》

5.1并行开发

因为项目中要使用Congos、ETL工具等新技术，并且要建立公共数据的中间计算层，因此对于项目组的挑战较大，因此需要制定可操作的实现方案。

考虑到报表类应用开发的特点与操作型应用不同，因此准备采取按照展现、数据计算切段并行开发的方法，分为报表展现、公共数据计算、展现集市计算3个环节同时开发。

并行实施的核心是数据库模型。

在具备数据库模型的基础上，就可以进行报表开发，在验证报表样式和操作方法的同时进行报表数据的计算处理。

1．根据需求分析结果提取对展现层面相关的数据模型

2．建立与报表展现相关的数据表，报表开发开始

3．根据进一步的需求分析结果，抽象公共指标

4．建立指标模型表

5．使用ETL工具逐步建立指标数据

6．使用ETL工具逐步集市数据

5.2分阶段测试

从报表制作、数据计算、整体性三个层次进行测试。

对于每一项测试，测试数据要存档，每份测试数据对应的打印报表经过验证后也要存档，便于回归测试。

5.2.1报表打印测试

验证报表样式、格式化、数据宽度、合计项宽度、报表计算关系、多维模型关系。

测试步骤：

1．准备数据。

每个代码都要准备数据，按照所有代码中数据最多的一个代码准备数据，机构号也是代码，如果某个代码根本不会出现数据，在与业务人员确认后删除测试记录。

2．测试的指标要有足够的数据宽度和小数位，原则上每个指标的值应该具有代表性，如一个表有10个数值字段，第一个1000001.01第二个1000002.01，第二条第一个2000001.01第二个2000002.01。

数据的宽度要符合实际可能的业务情况。

3．对于可能出现多页的报表，特别是明细报表，一定要准备一页以上的数据，并打印输出到第二页。

5.2.2数据计算正确性测试

模拟测试

1．针对设计文档中的边界情况、CASE情况、过滤条件，在第一步数据的基础上设计例外数据

2．从报表中直接检查例外情况是否发生

实际业务数据测试

1．对指标的总额与科目余额进行一致性检查

2．对各种分段情况通过SQL语句与报表数据进行分组合计检查。

3．与业务人员核对数据是否与预期、分行手工结果、系统数据是否一致

5.2.3系统处理性能测试

通过模拟程序生成足够批量的源数据，并且在最终的报表数据表中要预存至少2年的数据。

1．比较计算性能与数据量之间的潜在关系。

2．计算过程是否足够快

3．报表查询是否还是足够快