软件需求分析案例【性能需求分析案例】

  1. 1、下载文档前请自行甄别文档内容的完整性,平台不提供额外的编辑、内容补充、找答案等附加服务。
  2. 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
  3. 3、如文档侵犯您的权益,请联系客服反馈,我们会尽快为您处理(人工客服工作时间:9:00-18:30)。

软件需求分析案例【性能需求分析案例】性能需求分析

3.2.1. 概述

? 首先对xx年和xx年的全年税收业务量进行了统计,出税收业务量的增长趋势,

? 对xx至xx年的全年税收业务量进行了估算

以此为依据,同时结合税收业务量分布特点,按照省集中和全国集中两种模式,对用户访问量、系统处理能力、存储容量、网络流量等4个主要方面进行初步分析估算。

有必要指出的是,网络流量的估算与联网机构的接入方式密切相关,但是哪些联网机构可以集中接入,集中接入的层次,及集中接入机构的业务量在总业务量的占比各地差异很大;从地域上考虑,各联网机构在各省的集中程度也不尽相同,比如说,国税在部分省做到了省集中、而在另一部分省尚未做到省集中,至于地税、财政和部分城市商业银行的情况就更为复杂。

另外,在进行后续的估算中,考虑到税票业务量是本系统处理的主要业务,其他业务与税票相比,业务量相对较小。因此,我们暂以税票业务量作为估算的基础。

3.2.2. 业务量统计

通过对国库局综合业务报表系统提供的全国各省税票业务量进行分析统计,得出如下结论,xx年全国税票业务总量大约有2.1

亿笔,xx年全国税票业务总量大约有2.4亿笔;全国税票业务年增长率大约在15%左右。同时对各地上横向联网后,税票业务量变化趋势进一步考察发现,上横向联网后的第一年,某些地区税票业务量有突发性增长因素(如浙江,在上横向联网后的第一年,税票业务量增长了100%),所以我们假设税票业务量每年增长趋势在20%左右。

税票业务量的大小直接影响到对系统处理能力、存储容量、网络流量等性能指标的高端要求,由于各省经济发达程度和税收体制的差异,造成各省的税票业务量存在很大差异。为了做到按需投资,合理配备资源,避免浪费,我们将各省根据xx年税票业务量大小分为4类:

1.按分库级分类

(1) 特大型,税票年业务量达到3500万及以上

包括上海、广州、南京、北京4个分库。

(2) 大型,税票年业务量达到1500万及以上,3500万以下

包括石家庄、沈阳、杭州、福州、济南、武汉、成都、大连、宁波、重庆、天津11个分库或营管部管辖分库。

(3) 中型,税票年业务量达到1000万及以上,1500万以下

包括太原、呼和浩特、长春、哈尔滨、合肥、南昌、郑州、长沙、南宁、西安、兰州、贵阳、昆明、乌鲁木齐、青岛、海口、深圳、厦门18个分库或营管部管辖分库。 (4) 小型,年业务量在1000 万以下

包括银川、西宁、拉萨3个分库。 2.按中心支库级分类

(1) 特大型,税票年业务量达到1000万及以上

如:佛山市中心支库。

(2) 大型,税票年业务量达到500万及以上,1000万以下

如:苏州市中心支库。

(3) 中型,税票年业务量达到100万及以上,500万以下

如:常熟市中心支库。 (4) 小型,年业务量在100万以下如:安顺市中心支库。 3.按县支库级分类

(1) 特大型,税票年业务量达到500万及以上

如:广东佛山顺德。

(2) 大型,税票年业务量达到100万及以上,500万以下

如:江苏苏州吴江。

(3) 中型,税票年业务量达到30万及以上,100万以下

如:山东淄博淄川。

(4) 小型,税票年业务量在30万以下

如:陕西咸阳长武县。

3.2.3. 省集中模式性能需求

3.2.3.1. 税票业务量分省估算

表3-1 xx—xx年税票业务量统计及增长情况估算表

3.2.3.2. 用户访问量估算

表3-2 用户访问量计算

3.2.3.3. 系统处理能力计算

? 省集中模式数据中心处理能力计算

根据以上税票业务量统计及增长情况估算表,同时考虑到扣税业务的发生在时间上分布存在不规则性的特点,作如下假设:

? 高峰交易日业务量假定

假设全年税票业务量集中在11个月处理,每月处理全年业务量的1/11,每月的业务量平均分布在三旬当中,每旬业务量的80%集中发生在每旬的后三天。在最不理想的情况下,假定后三天的业务量的80%集中在每旬的最后一天处理。则高峰交易日业务量计算公式为:

高峰日交易量 = 年业务量/11/3*80%*80%(笔/天) ? 平均交易日业务量假定

假设每年的正常工作日为200天,则平均交易日业务量计算公式为:

平均日交易量 =年业务量/200(笔/天)

? 系统处理能力TPM-C值计算公式为:TPM-C = M*M0/T/M1 M为日交易量,包括对数据库更新、查询、增加、删除等操作。

计算TPM-C的目的是为了确定机器的处理能力,由于在每天的业务处理过程中,业务发生的频度不尽相同,一般情况下是按照8/2原则,具体来说,在20%的工作时间内业务人员要处理80%的业务。

M0为一个应用交易所对应的标准交易个数,推荐值为8-20,由于系统体系结构的不同、应用服务器的结构不同,各个厂商的推荐值也不同,如:HP公司推荐为10。

T为交易的高峰时间,使用2/8原则,如:每日工作时间为8小时,那么交易的高峰时间T=8*20%=1.6小时。

M1为机器实际为系统提供的处理能力,机器需要预留一部分处理能力,这一部分的处理能力是为了分配给操作系统、中间件应用服务器及数据库服务器的。M1一般来说为80%。

? 说明:

M0=10,参考目前厂商与TPC组织推荐的标准8~20,及借鉴相关类似系统(主要是中国现代化支付系统和中国银联交换系统)的取值情况,同时考虑到国库处理系统的单笔交易需要实时转发以及销号审核等信息,处理环节较多,自身交易有一定的复杂性。经估

算,我们认为TIPS的交易复杂度系数M0取值10为宜。

T=96分钟,按照每天工作8个小时计算,同时根据2/8原则,即8*20%=1.6小时=96分钟内完成每天的工作量。

相关文档
最新文档