IT项目管理模板
**系统建设方案
项目组人员:寿安庆
项目经理:寿安庆,软工0908,200926630814 ,章节:
2013年 06月
目 录
1. 项目概述 ................................................................................................................................... 1 1.1. 项目背景 ........................................................................................................................... 1 1.2. 建设目标 ........................................................................................................................... 1 1.3. 建设内容 ........................................................................................................................... 1 1.4. 建设原则 ........................................................................................................................... 1
........................................................................................................ 1 1.4.1.先进性与成熟性
....................................................................................................................... 2 1.4.2.开放性
....................................................................................................................... 2 1.4.3.实用性
........................................................................................................ 2 1.4.4.安全性和可靠性
................................................................................................................... 3 1.4.5.可扩展性
1.4.6. 可维护性 ................................................................................................................... 3 2. 需求分析 ................................................................................................................................... 4 2.1. 卡务系统功能需求 ............................................................................................................ 4 2.1.1. 卡制作发行需求分析 ................................................................................................ 4 2.1.2. 卡管理系统软件需求分析 ......................................................................................... 6 2.2. 标准规范需求分析 .......................................................................................................... 12 3. 总体设计方案 .......................................................................................................................... 14 3.1. 指导思想 ......................................................................................................................... 14 3.1.1. 统筹规划,统一标准,统一管理............................................................................ 14 3.1.2. 注重安全,分步实施,扩展应用............................................................................ 14 3.2. 社会保障卡系统总体结构 ............................................................................................... 14 3.3. 社会保障卡系统业务架构 ............................................................................................... 16 3.3.1. 社会保障卡系统功能架构 ....................................................................................... 16 3.3.2. 社会保障卡系统数据架构 ....................................................................................... 16 3.4. 社会保障卡系统技术架构 ............................................................................................... 18 3.4.1. 应用系统架构选择 .................................................................................................. 18
.................................................................. 19 3.4.2.J2EE 技术在社会保障卡系统中的应用
3.5. 社会保障卡系统数据系统 ............................................................................................... 19 4. 应用软件设计方案 .................................................................................................................. 21 4.1. 社会保障卡管理系统 ...................................................................................................... 21 4.1.1. 卡申领管理 .............................................................................................................. 21 4.1.2. 制卡系统 ............................................................................... 错误~未定义书签。23 4.1.3. 发卡系统 ................................................................................................................. 22 4.1.4. 发放管理 ................................................................................................................. 22 4.1.5. 补卡换卡管理 .......................................................................................................... 23 4.1.6. 卡交易管理 .............................................................................................................. 23 4.1.7. 卡系统维护 .............................................................................................................. 24
I
.......................................................................................................... 24 4.1.8.用户权限管理
.............................................................................................................. 26 4.1.9.卡库存管理
5. 卡系统接口方案 ...................................................................................................................... 31 5.1. 与银行对接 ...................................................................................................................... 31 5.1.1. 社保卡和银行卡结合方式 ....................................................................................... 31 5.1.2. 网络对接 ................................................................................................................. 31 5.1.3. 业务对接 ................................................................................................................. 31 5.1.4. 系统对接 ................................................................................................................. 32 5.1.5. 社保卡部门与银行部门职责分工............................................................................ 33 5.2. 与业务系统对接 .............................................................................................................. 35
............................................................................... 35 5.2.1.社会保障卡在业务领域的应用
................................................................................... 38 5.2.2.卡系统与外部系统主要对接
6. 性能保障方案 .......................................................................................................................... 40
6.1. 本项目性能要求 .............................................................................................................. 40
6.2. 性能调优方案 .................................................................................................................. 40 6.2.1. 系统配置调优 .......................................................................................................... 40 6.2.2. 数据库与中间件的优化 ........................................................................................... 41 6.2.3. 应用系统的优化 ...................................................................................................... 41 6.3. 从架构设计解决系统性能问
题
快递公司问题件快递公司问题件货款处理关于圆的周长面积重点题型关于解方程组的题及答案关于南海问题
....................................................................................... 42
...................................................................................................... 44 6.3.1.分层的设计方法
6.3.2. 同步与异步处理相结合的系统体系架构 ................................................................ 46 6.3.3. 缓存、池化技术的使用 ........................................................................................... 46 6.3.4. 分布式业务处理模式 .............................................................................................. 47 6.4. 从数据库配置及优化解决系统性能问题 ........................................................................ 48 6.4.1. 分区表和索引(partition table and index)技术 ........................................... 49 6.4.2. 并行化(parallelism)技术 ................................................................................. 50 6.4.3. 实体化视图(materialized view)技术 .............................................................. 54 6.4.4. 位图索引(bitmap index)技术............................................................................ 55 6.4.5. 海量数据VLDB的管理............................................................................................. 56 6.4.6. 数据库配置与优化 .................................................................................................. 58 6.5. 从软件解决系统性能问题 ............................................................................................... 66 6.5.1. 软件设计基于构件,尽量简单化............................................................................ 66 6.5.2. 代码编写质量直接关系到系统的性能 .................................................................... 66 6.5.3. 软件运行性能监控 .................................................................................................. 67
............................................................................ 67 6.5.4.软件数据库SQL的编程注意事项
.............................................................................................. 68 6.5.5.中间件编程注意事项
7. 项目实施方案 .......................................................................................................................... 69 7.1. 项目实施组织机构 .......................................................................................................... 69 7.1.1. 项目实施组织体系 .................................................................................................. 69 7.1.2. 项目组织各角色职责 .............................................................................................. 69 7.2. 人员配置策略 .................................................................................................................. 71 7.3. 项目实施计划 .................................................................................................................. 71
II
.......................................................................................................... 71 7.3.1.实施进度目标
........................................................................................... 72 7.3.2.总体进度与关键里程碑
7.3.3. 进度安排 ................................................................................................................. 72 7.4. 项目文档提交件管理 ...................................................................................................... 72 7.4.1. 项目交付物 .............................................................................................................. 72 7.4.2. 递交成果的签署 ...................................................................................................... 73 7.4.3. 递交成果的拒绝 ...................................................................................................... 74 7.5. 保障措施 ......................................................................................................................... 74 8. 项目测试及验收方案 .............................................................................................................. 75 8.1. 系统测试方案 .................................................................................................................. 75
.......................................................................................................... 75 8.1.1.测试方法概述
............................................................................... 75 8.1.2.测试任务理解分析及应对策略
............................................................................... 76 8.1.3.单元模块测试与联调测试设计
.......................................................................................................... 79 8.1.4.性能测试设计
8.1.5. 测试过程控制 .......................................................................................................... 85 8.1.6. 测试工具 ................................................................................................................. 95 8.1.7. 测试过程文档控制 .................................................................................................. 97 8.2. 系统验收方案 ................................................................................................................ 101 8.2.1. 社会保障卡系统验收概述 ..................................................................................... 101 8.2.2. 初验方案 ............................................................................................................... 102 8.2.3. 终验方案 ............................................................................................................... 108 9. 项目管理方案 ........................................................................................................................ 112 9.1. 配置与变更管理 ............................................................................................................ 112 9.1.1. 配置管理资源配备 ................................................................................................ 112 9.1.2. 项目配置策略 ........................................................................................................ 113 9.1.3. 创建项目配置环境 ................................................................................................ 116 9.1.4. 变更与交付工件 .................................................................................................... 116 9.1.5. 管理基线 ............................................................................................................... 117 9.1.6. 管理软件系统交付 ................................................................................................ 118 9.1.7. 变更请求管理 ........................................................................................................ 118 9.1.8. 监测与报告配置状态 ............................................................................................ 124 9.2. 范围管理 ....................................................................................................................... 124 9.3. 项目过程管理 ................................................................................................................ 124 9.3.1. 项目启动过程 ........................................................................................................ 126 9.3.2. ............................................................................................................... 126 需求分析
9.3.3. ............................................................................................................... 127 开发策划
9.3.4. 设计与编码实现 .................................................................................................... 128 9.3.5. 系统测试 ............................................................................................................... 129 9.3.6. 实施 ....................................................................................................................... 130 9.3.7. 总结验收 ............................................................................................................... 132 9.3.8. 运行维护管理 ........................................................................................................ 132 9.3.9. 项目管理监控 ........................................................................................................ 135 9.4. 项目沟通管理 ................................................................................................................ 139
III
9.4.1. ................................................................................................ 140 项目实施各方职责
9.4.2. .......................................................................... 142 需要用户和原承建商配合的建议
9.4.3. 沟通内容 ............................................................................................................... 144 9.4.4. 客户交互的安排 .................................................................................................... 145 9.5. 项目风险管理 ................................................................................................................ 145 9.5.1. 风险管理过程 ........................................................................................................ 146 9.5.2. 项目风险管理计划 ................................................................................................ 146 9.5.3. 本项目风险和对策 ................................................................................................ 148 10. 质量保证方案 ........................................................................................................................ 151 10.1. 项目质量目标 ............................................................................................................ 151 10.2. 项目质量范围和标准 ................................................................................................ 151 10.2.1. ............................................................................................................... 151 质量范围
10.2.2. ............................................................................................................... 151 质量标准
10.3. 质量管理 ................................................................................................................... 151
10.3.1. 质量保证的基本思想 ............................................................................................ 152 10.3.2. 软件生产过程中主要的工作活动.......................................................................... 154 10.3.3. 质量过程管理 ........................................................................................................ 155 10.3.4. 质量保证专项活动SQA ........................................................................................ 156 10.3.5. 软件工作产品质量审计和相关文档 ...................................................................... 157 11. 培训方案 ............................................................................................................................... 161 11.1. 培训需求分析 ............................................................................................................ 161 11.1.1. 培训目标 ............................................................................................................... 161 11.1.2. 培训项目 ............................................................................................................... 162 11.2. 培训课程体系设计 .................................................................................................... 162 11.2.1. 项目管理知识培训 ................................................................................................ 163 11.2.2. 专业技术培训 ........................................................................................................ 164 11.2.3. 计算机知识及系统操作培训 ................................................................................. 164 12. 售后服务方案 ........................................................................................................................ 166 12.1. 售后服务体系简介 .................................................................................................... 166 12.1.1. 售后服务体系理念 ................................................................................................ 166 12.1.2. ................................................................................................ 166 服务支持体系构架
12.1.3. 技术支持服务形式 ................................................................................................ 166 12.2. 售后服务流程 ............................................................................................................ 167 12.2.1. 技术支持服务流程 ................................................................................................ 167 12.2.2. ................................................................................................ 169 客户服务质量文件
12.2.3. ........................................................................................................ 170 售后服务内容
12.3. 应急维护方案及时间安排 ......................................................................................... 172 12.3.1. 应急预案目标 ........................................................................................................ 172 12.3.2. 应急预案保障 ........................................................................................................ 173 12.3.3. 应急预案具体措施及时间安排 ............................................................................. 173 12.3.4. 应急处理流程 ........................................................................................................ 174 12.4. 维护期后服务方案 .................................................................................................... 175
IV
12.4.1. .............................................................. 175 为本项目提供长期服务和技术支持保证
12.4.2. ................................................................................................ 175 系统维护服务方式
V
1. 项目概述
1.1.项目背景
随着我国老龄化程度不断加深,参加老年活动的人数逐年递增、各个老年协会蓬勃发展,社会对老干部工作部门的要求越来越高。在这老干部工作不断变化的新形势下,江西省老干部活动中心在管理和服务方面的压力日益凸显,引发了活动认输巨大难于管理、活动协会过多不好组织、正常业务缺乏规范等一系列问题。
1.2.建设目标
江西省老干部活动中心提出了中心业务处理系统建设要求,希望通过系统建设实现有效的证件管理、仓库管理、工作人员管理、活动管理、协会管理、保修流程管理、采购流程管理以及工作任务管理等。根据江西省老干部活动中心对中心业务处理系统管理要求,并结合我公司多年的软件建设经验,我们提出以下解决方案。
1.3.建设内容
按照江西省老干部活动中心的要求,建设中心业务处理系统,满足江西省老干部活动中心对业务处理系统的证件管理、仓库管理、工作人员管理、活动管理、协会管理、保修流程管理、采购流程管理以及工作任务管理等功能的需求。 1.4.建设原则
1.4.1. 先进性与成熟性
先进性:采用先进的.net技术架构,系统基于vs2008+sql2008开发,支持大型复杂应用。目前市场大部分车辆管理系统采用的都是早期的开发技术,如
1
VB,PB等,采用的数据库一般是SQL SERVER 2000,这些技术在满足小型应用上没有问题,不能满足大型应用。
成熟性要求所选择的技术和产品必须有规模化的成功应用实例系统,系统的效率和可靠性可预测。
1.4.2. 开放性
系统的数据层、业务逻辑层、功能表示层相互分离,业务功能数据通过业务逻辑层和数据层进行交互。各个业务功能以模块化的方式架构,功能模块架构要采用统一标准的接口规范,实现功能的扩展和定制。模块划分采用高内聚,低耦合原则进行。当应用系统的的业务或是功能要求发生变化时,可以通过简单的对相应模块的修改来实现功能的扩展。当需要与外界系统做接口时,通过统一的标准即可完成服务的提供和接收。目前市场上很多系统的架构局限性都很大,需求的细小变更都要导致大量的修改或是重新设计,也没有考虑其他系统地接口,客户需要扩展或与其他系统整合的时候,往往要付出巨大的代价。 1.4.3. 实用性
中心业务处理系统必须考虑系统的实用性,保证系统的良好应用,不能选择只有先进技术,但没有实用价值的产品。实用性要从技术实现的难易程度、产品的稳定性和效率、厂商的本地服务和支持能力等方面衡量。
1.4.4. 安全性和可靠性
中心业务处理系统的安全性和可靠性是系统成功应用的基本前提。安全性和可靠性设计主要基于以下方面:
? 能够针对业务的各项约束进行自定义配置,使计算机自动根据配
置实施约束,减轻业务处理人员工作负担的同时,降低人为操作失误。
? 利用多种手段(内、外防火墙、入侵
检测
工程第三方检测合同工程防雷检测合同植筋拉拔检测方案传感器技术课后答案检测机构通用要求培训
、安全认证、基于角色
的授权等等)加强对资源的有效保护。
? 系统支持接收工作的自动提醒,提醒方式可以在软件中以醒目窗
2
体提示,也可以用手机短信方式、电子邮件方式通知责任人,用户在不登
陆系统的情况下也可以得到提醒信息。
1.4.5. 可扩展性
系统的数据层、业务逻辑层、功能表示层相互分离,业务功能数据通过业务逻辑层和数据层进行交互。各个业务功能以模块化的方式架构,功能模块架构要采用统一标准的接口规范,实现功能的扩展和定制。模块划分采用高内聚,低耦合原则进行。当应用系统的的业务或是功能要求发生变化时,可以通过简单的对相应模块的修改来实现功能的扩展。当需要与外界系统做接口时,通过统一的标准即可完成服务的提供和接收。目前市场上很多系统的架构局限性都很大,需求的细小变更都要导致大量的修改或是重新设计,也没有考虑其他系统地接口,客户需要扩展或与其他系统整合的时候,往往要付出巨大的代价 1.4.6. 可维护性
中心业务处理系统系统要求具有良好的可维护性,在系统维护、安全策略维护、应用变化维护等方面具备简便易行的维护功能。
3
2. 需求分析
2.1.卡务系统功能需求
2.1.1. 卡制作发行需求分析
2.1.1.1. 卡制作需求分析
对社会保障卡统一完成初始化和个人化,确保卡片数据结构和写入信息的一致性、唯一性和标准化。
2.1.1.1.1. 制卡设备控制
开发对制卡设备的发卡控制软件,包括按制卡设备要求转换打印数据和写入数据格式。对多台小型制卡设备的集群制卡管理。
2.1.1.1.2. 制卡流程管理
考虑数据安全性及制卡成本、印相效果、工作量等多方面因素,先由制卡厂商统一印制社会保障卡的裸卡,包括卡面公共信息和图案,再由卡管理中心完成卡面个性信息的印制和卡内信息的写入工作,并最终完成信封封装和下发。
制卡必须完成以下主要步骤:
1. 洗卡:将生产商提供卡的主控密钥(厂家密钥)替换为发卡方主控密钥
的过程。
2. 建卡结构(初始化):在发卡方主控密钥的控制下,按照社会保障卡的
数据标准建立卡片的文件结构和安全结构,划分各应用区,写入各应用
控制密钥。
3. 个人信息写入(个人化):写入持卡人的基本数据和公用信息文件。
4. 卡面印刷制作:将用户的照片、姓名、卡号等信息印刷在卡面上。
具体流程如下图:
4
制卡开始
卡面公共信息印刷
洗卡
建卡结构(初始化)
卡内信息写入
卡面个性化信息印刷
制卡完成
图 2-1制卡流程图
由于系统需要使用专用硬件(制卡设备、加密机等),因此软件还应提供对这些硬件的设置与通讯操作。
2.1.1.1.3. 制卡统计
卡管理中心应对每次制卡情况予以详细的记录,并保存归档,以便日后能根据统计分析情况改进制卡的质量和效率。记录的对象应针对制卡设备、制卡数量、用卡地区情况而进行。记录的内容可分批次保存。
记录制卡设备的使用情况:应统计每个制卡设备的已制卡数量、出错日志,以便日后分析设备的性能、利用效率、磨损程度等指标,并根据指标对制卡设备及时做出维护或调整。
制卡数量统计:应统计出每次制卡量。
用卡情况统计:应统计出制卡批次、COS厂商信息、制卡开始日期、制卡完成日期等信息,发卡类型。
2.1.1.2. 卡发行需求分析
卡管理中心根据各采集点的采集信息和办卡申请,进行集中制卡,制卡后将所制卡批量返回各受理点,由申请人或代申请单位到相应的采集点凭公民身份证
5
等证明领取,换领者需填写回执并进行新卡开卡操作。
2.1.2. 卡管理系统软件需求分析
2.1.2.1. 卡管理
1、用户个人密码(PIN)维护
(1)PIN修改。用户输入旧PIN及新PIN,在旧PIN认证通过后将其替换为新PIN。
(2)PIN重装。当用户忘记了个人密码后,管理人员在授权的情况下可重装PIN,即将用户卡内原有密码替换为用户指定的新密码。
(3)PIN解锁。当用户认证PIN多次出错误后,IC卡内的PIN会被置为锁定状态,不允许用户再次认证,此时管理人员在授权的情况下可以解锁PIN,即将卡内PIN从锁定状态变为允许认证状态,使客户可以再次执行PIN认证。
2、用户资料变更
该交易请求由前台社会保障卡管理系统终端发起,持卡人可凭身份证户口本等证明材料中的相关信息,并记录用户资料信息变更表,用于更新其他业务部门的相应基本资料。
3、卡挂失
持卡人丢失卡片,需要及时向卡管理中心挂失,系统接受口头(电话)挂失和当面挂失。但口头挂失后,需持有效证件在7天内办理当面挂失,否则系统自动解挂。持卡人找到已挂失的卡片,要到卡管理中心办理解挂失手续。
该交易请求由前台社会保障卡管理系统终端发起,社会保障卡管理系统在接收到交易请求后,将修改数据库中的卡片状态信息为挂失状态,并记录黑名单变更表。
同时社会保障卡管理系统将黑名单数据更新下发给终端设备和卡鉴权系统。
卡挂失流程如下图所示:
6
社会保障卡管
理系统数据库
社会保障卡鉴社会保障卡管
权系统理系统
成功
挂失提交
失败
卡挂失处理
卡挂失请求
业务办理资料审核
业务办理点,,卡挂失申请
资料不合格$$$
持卡人
图 2-2 卡挂失流程图
4、卡解挂
该交易请求由前台社会保障卡管理系统终端发起,社会保障卡管理系统在
接收到交易请求后,将修改数据库中的卡片状态信息为正常状态,并记录黑名
单变更表。
同时社会保障卡管理系统将黑名单数据更新下发给终端设备和卡鉴权系
统。
卡解挂流程如下图所示:
7
社会保障卡管
理系统数据库
社会保障卡管社会保障卡鉴
理系统权系统
成功
卡解挂提交
失败
卡解挂处理
卡解挂请求
业务办理资料审核
业务办理点,,卡解挂申请
资料不合格$$$
持卡人
图 2-3 卡解挂流程图
5、补卡
持卡人将卡片丢失后,需持相关证件到卡管理中心办理补卡业务。业务经办人员核对持卡人相关证件,若合法,则将持卡人原卡号放入黑名单并补发新卡。补卡时系统从数据中心读取持卡人个人信息、单位信息及其他基本信息,同时将持卡人的当前账户余额写入卡片内。补卡不补交易明细记录。
6、卡注销
卡注销的操作是在各业务停用的条件下来完成的,该交易请求由前台社会保障卡管理系统终端发起,卡管理系统将修改卡状态为注销状态,卡管理系统回收该卡资源数据以便用于新发卡,并回收该卡片。
8
卡注销流程如下图所示:
社会保障卡管
理系统数据库
社会保障卡管
理系统服务器
成功
卡注销提交
失败
卡注销处理
卡注销请求
业务办理资料审核
业务办理点,,卡注销申请
资料不合格$$$
持卡人
图 2-4 卡注销流程图
7、换卡
卡片发生损坏或其他原因卡片不能使用,需持坏卡及相关证件到卡管理中
心办理换卡业务。业务经办人员需先将坏卡收回,之后另换新卡。 该交易请求由前台社会保障卡管理系统终端发起,卡管理系统将更新卡片
状态为换卡,并增加换卡记录表中的记录,并转入制卡流程。 换卡完成后,收回的坏卡必须在一定条件下销毁,防止密钥外泄。 换卡流程如下图所示:
9
社会保障卡管
理系统数据库
制卡流程社会保障卡管制卡部门理系统服务器
成功
换卡提交
失败
换卡处理
换卡请求
业务办理资料审核
业务办理点,,换卡申请
资料不合格$$$
持卡人
图:换卡处理流程
图 2-5 换卡处理流程图
8、异常卡处理
交易过程中若用户卡内数据与数据库数据不一致,则表明该卡出现了异常,此时业务端应停止交易,并将该异常卡送往卡管理中心进行处理。卡管理中心应从数据中心提取数据与异常卡的卡内数据进行比对,以确定卡片出错的原因。
9、终端管理
卡管理中心应对所有的IC卡读写器进行统一的管理和备案。为保证卡片的全国通用,所有用于社保卡业务处理的读写器,应符合《社会保障(个人)卡规范》——终端规范的要求。读写器的权限由PSAM卡决定,PSAM卡由卡管理中心统一发放。PSAM卡与终端读写机具一一对应,不可互换。
10
2.1.2.2. 鉴权系统
持卡人在卡应用终端上进行联网交易时,需要进行卡鉴权和交易鉴权,验证卡和交易的合法性。需要进行密钥效验时将密钥将密钥发往加密机校验。持卡人在卡应用终端上进行脱网交易时,卡鉴权和交易鉴权在卡终端和卡上进行。
图 2-6 鉴权系统流程图
2.1.2.3. 黑名单管理
黑名单是指由于持卡人因故对卡挂失,终止其卡的功能的所有卡的数据库。卡管理中心必须对直属单位用卡卡黑名单进行统一、集中管理,以保证单位用卡时的校验需求。黑名单管理主要是指对黑名单的收集、分发、存储、检索和更新等的处理。在所有交易前必须进行黑名单校验。黑名单在终端签到时自动下载更新,黑名单校验由系统在交易被处理前自动完成。
1、收集:各业务经办网点将其每天产生的黑名单汇总到卡管理
中心的过程。
2、分发:卡管理中心将汇总的黑名单分别发送给各业务经办网
点的过程。
11
2.1.2.4. 卡服务与运维
社会保障卡工程是一个复杂的系统工程,其所涉及的内容范围广、对象多、专业强、要求高,其中的不确定因素复杂。光建立一套社保卡系统平台是远远不够的,与之配套的服务体系和运维体系建设是确保社会保障卡项目长期有效运行和可持续发展的关键。
社保卡服务体系的建设要涵盖省级、各地市、区县业务经办机构、服务网点等各种服务手段,同时利用的政府便民设施,构建覆盖省、市、区县、街(社区)的服务网络,并通过建立电话服务中心、自助查询系统、网站等各种信息化技术手段为参保人提供全方位的服务。
2.2.标准规范需求分析
本项目建设严格遵循人保部社会保障(个人)卡规范,其设计、开发和实施符合相关的规范,同时应用系统的指标体系标准、数据接口标准、网络通信方式、业务规范、信息数据项、信息分类编码等标准严格执行国家、人保部、四川省有关规定。
社会保障卡将遵循以下标准规范及相关要求:
1、人力资源和社会保障部《社会保障(个人)卡规范》
2、关于印发社会保障卡建设总体规划的通知(劳社部函〔1999〕213号)
3、关于印发《〈社会保障(个人)卡规范〉补充说明》的通知(劳社信息函〔2001〕09号)
4、关于印发社会保障(个人)卡规范和安全要求的通知(劳社厅函〔2000〕76号)
5、关于印发社会保障卡发行注册流程等4项工作流程的通知(劳社信息函〔2003〕14号)
6、劳动和社会保障部办公厅关于社会保障卡建设有关问题的通知(劳社厅函[2001]197号)
12
7、《中国人民银行 人力资源社会保障部关于社会保障卡银行业务应用有关事宜的通知》(银发〔2010〕348号)
8、中国人民银行《中国金融集成电路(IC)卡规范》
13
3. 总体设计方案
3.1.指导思想
3.1.1. 统筹规划,统一标准,统一管理
中心业务处理系统是方便老干部、老百姓,支持中心活动处理服务的应用管理系统。因此为保证工程建设的统一性、完整性,对有关的技术标准和规范要制定统一的标准,进行统一管理。
3.1.2. 注重安全,分步实施,扩展应用
中心业务处理系统的建设应从最急需的工作入手,再根据业务需求和信息系统建设状况逐步扩大系统功能和应用,在统一规划下分步分阶段实施,逐步扩大应用的范围,更好地为老干部服务。
3.2.社会保障卡系统总体结构
中心业务处理系统主要是实现五个部分的功能:
1、面向所有用户的公共服务子系统;
2、面向办公室工作人员的办公中心子系统;
3、面向活动科工作人员的活动中心子系统;
4、面向
安全管理
企业安全管理考核细则加油站安全管理机构环境和安全管理程序安全管理考核细则外来器械及植入物管理
员的安全中心子系统;
5、面向系统管理员的配置中心子系统;
中心业务处理系统是由上述多个物理上分散但相互有逻辑关系的多个分系统构成。
中心业务处理系统的结构示意图如下:
14
基于社会保障卡的社保应用基于社会保障卡的其他应用
卡中心接口系统服务网点系统经办机构业务办理运行维护管理体系安全保障体系用户自助查询服务黑名单管理卡信息查询发卡数据管理接口 自助圈存服务修改卡基本信息CA认证
其它自助服务应急补换卡系统外部用户权限管理指纹认证接口其它相关业务安全管理机制卡资料管理数据数据采集系统制卡系统接口密钥安全管理
基本数据采集卡片维护管理制卡数据管理数据安全管理硬件访采集表打印数据录入卡片初始化问接口系统安全照片扫描采集数码相机采集运行监控管理卡片个人化应用安全内部指纹采集出入库管理接口容灾备份恢复数据校验比对网络物理安全
网络平台
机房工程网络工程服务器存储系统硬件设施
图 3-1 社会保障卡系统结构图
老干部活动中心业务处理系统
公共服务子系办公中心子系活动中心子系安全中心子系配置中心子系统统统统统
修改个人资站内信箱证件事务活动事务系统配置料任务管理人员事务协会事务角色管理数据库配置
仓库事务用户管理
流程查询
保修流程
采购流程
图 3-2 功能结构图
15
3.3.社会保障卡系统业务架构
3.3.1. 社会保障卡系统功能架构
社会保障卡系统从卡片应用逻辑功能上可分为三级应用架构,分别由业务应用系统、卡应用系统、业务应用终端构成。
其中卡应用系统需要卡系统接口和密钥管理系统和接口系统作为支持和保障。卡应用系统也是业务应用系统和业务应用终端的主要桥梁,在保证业务应用安全和高效运行起到重要作用;各应用系统间关联和数据通讯通过大量的数据接口和应用接口来完成,保证数据准确安全的在个系统间传递;社会保障卡系统架构详见下图:卡系统功能架构图。
数据接口卡社会保障卡应用系统应社用业会功务能保应用编程接口信模障社会保障卡制卡系统息块卡系
密钥管理系统系统
统卡系统接口
社会保障卡
业务系统终端/卡系统终端/查询终端
江苏省社会保障卡系统架构图
图 3-3 卡系统架构图
3.3.2. 社会保障卡系统数据架构
社会保障卡应用按应用功能划分主要有以下类别:身份识别、数据存储、人机交互接口、业务触发、专用帐户交易,通过对这些应用功能类别进行分析,各类别中涉及到的多种数据类型;对社会保障卡应用系统进行分析可以总结出以下
16
系统数据架构,卡系统数据框架包括:
, 卡资源数据
, 用户基础数据
, 安全校验数据
, 业务数据
, 制卡数据
社会保障卡系统数据框架关系如下图所示: 社会和劳动社会保障卡系统保障系统
应用编程接口制卡数据安
全
校卡资源数据 业务数据 验
数提取数据接口据用户基础数据
卡系统终端/查询终端
江苏省社会保障卡数据架构图
图 3-4 卡数据结构图
综合考虑整个系统的各操作环节,系统形成了完整的数据流,系统数据
结构如下图:
17
社保应用数据民政等其他业务应用数据医疗保险数据
卡信息查询系统
养老保险数据卡中心(制卡、管理)数据劳动应用数据
失业保险数据个人基本信息劳动就失业劳动就失业数据
工伤保险数据
职业技能培训职业技能数据生育保险数据卡片数据.
.城镇居民.医疗保险数据再就业数据其它数据再就业培训农村养老保险数据
个人日解资常挂销补换挂料管失卡卡卡失变理更
图 3-5 系统结构图
3.4.社会保障卡系统技术架构
3.4.1. 应用系统架构选择
多层结构为网络计算平台上软件开发提供了强有力的解决方案,在开发大型分布式应用系统中表现出强大的生命力。社会保障卡系统采用J2EE 技术作为系统应用架构。主要从集成性、可用性、可扩展性三个方面考虑其特点。
1、集成性:集成性主要反映在基础平台对应用程序互操作能力的支持上。它要求分布在不同机器平台和操作系统上、采用不同的语言或者开发工具生成的各类商业应用必须能集成在一起,构成一个统一的企业计算框架。这一集成框架必须建立在网络的基础之上,并且具备对于遗留应用的集成能力;
2、可用性:要求所采用的软件构件技术必须是成熟的技术,相应的产品也必须是成熟的产品,在至关重要的企业应用中能够稳定、安全、可靠地运行。另外,由于数据库在企业计算中扮演着重要角色,软件构件技术应能与数据库技术紧密集成;
3、可扩展性:集成框架必须是可扩展的,能够协调不同的设计模式和实现策略,可以根据企业计算的需求进行裁剪,并能迅速反应市场的变化和技术的发
18
展趋势。通过保证当前应用的可重用性,最大程度地保护企业的投资。
根据社会保障卡系统系统的特点和对集成性、可用性、可扩展性的需求,卡系统对联机事务和管理事务的综合应用特征,以及技术发展的方向,采用当前最活跃、最具生命力的J2EE 技术作为遂宁市社会保障卡系统系统系统框架。 3.4.2. J2EE 技术在社会保障卡系统中的应用
社会保障卡系统采用J2EE 技术作为系统建设核心技术,结合人力资源和社会保障业务系统,构建以卡管理应用和卡鉴权应用的核心服务器实现社会保障卡系统的表现逻辑层和业务逻辑层;以人力资源和社会保障信息和卡信息作为社会保障卡作为系统企业信息系统层,以卡后台管理应用和前台/服务机构应用作为系统客户层。
系统的接口确保系统遵从一定的标准并向业务系统提供公用功能,使系统具
应用组件。有良好互操作性。根据实际的业务情形,适当地选用和搭配各种J2EE 对于每一种应用组件,明确定义它在应用中应当担负的角色,为合理构建社会保障卡应用体系提供坚实的基础。
不同类型的客户都可以访问J2EE 环境提供的各种服务,客户类型由社会保障卡系统开发商根据自己的软件架构进行设计,具有非常好的选择性和灵活性,开发商可以选择合适的软件架构为客户提供良好的服务。
3.5.社会保障卡系统数据系统
社会保障卡管理中心的数据系统应严格遵循人力资源和社会保障业务系统的数据系统建设的指导思想、设计原则、标准规范和管理规定设计。
对数据中心已有的数据库将不再重复建设。对数据中心没有或不能满足卡管理需要的部分信息,应在数据中心扩充建立。
社会保障卡管理信息系统的数据主要由业务数据、卡发放与运行管理数据和系统管理数据构成。其中卡的业务数据包括个人基本信息和专业信息,主要由相应的业务系统生产与使用。卡发放与运行管理数据包括卡管理数据库、卡黑名单数据库,必须由卡管理中心生产与管理,提供给其他业务系统使用;系统管理数
19
据库是指支持和保护卡管理信息系统安全运行的操作人员管理数据库,它也由卡管理中心维护与使用。
1、卡管理数据库:包括社会保障(个人)卡、PSAM卡等的发放、运行和终止全部生命周期各阶段的有关信息。以确保卡管理中心对卡安全运行的了解与掌握。
2、卡黑名单数据库:主要包含直属单位用卡人产生的黑名单。以保证用卡时的校验需求。
3、卡系统操作管理数据库:是指对利用社会保障卡管理信息系统对卡进行操作与管理人员的数据库。
20
4. 应用软件设计方案
4.1.公共服务子系统
4.1.1. 后台首页
1、基本信息介绍:用户首次登陆进入首页吗,主要内容包括为本系统的概述,老干部活动中心的简介、主要职责、基础设施和版权声明。
2、最新公告:登陆进入主页面,在页面中将看到小时老干部活动中心的通知,以便用户一目了然看到老干部活动中心的最新公告信息。
3、待办事项:用户登录进入管理首页,可以在第一时间了解未完成任务,主要内容包括任务的发布、接受、处理等功能,以便用户清楚地知道未完成的任务,任务内容包括发布人、发布时间、是否处理完毕、是否审批通过、详情等信息。
4.1.2. 站内信箱
制卡系统建设内容主要包括:制卡方式的选择、数据采集、制卡流程、制卡统计等。
主要负责社保卡制作批次形成,批量制卡,零星制卡,补换卡业务的管理控制
各模块的具体功能描述如下:
制卡批次维护模块:根据发卡计划形成发卡制卡批次,以后统一按制卡批次来管理社保卡,提供制卡批次的信息的录入和维护;
制卡批次人员维护模块:发卡人员按制卡批次来统一管理社保卡制作、发放,按单位或个人添加人员到制卡批次中;包括制卡批次批量人员维护、制卡批次零星人员维护。
批量制卡信息生成模块:生成该批次的批量制卡信息(和卡商商量制定制卡信息格式);
21
批量制卡信息导出模块:把批量制卡信息导出生成文件,给银行、卡商;
零星制卡模块:日常零星新参保制卡模块;包括零星制卡批次生成、制卡信息生成。
换卡、补卡模块:提供持卡人因社保卡物理损坏或丢失,而所需的换卡补卡功能;持卡人补卡换卡后领卡,联机启用卡和应用,并圈存个人账户。换卡时如果旧卡能够读取电子钱包余额,则将余额转入新卡,否则同补卡处理流程,即电子钱包余额为约定免责期之后的账户余额。包括老卡的停用、新卡制作。
社保卡照片采集模块:包括照片扫描、照片处理、照片入库。 4.1.3. 发卡系统
发卡系统主要完成社会保障卡的发放、注销以及业务指标扩充、数据结构修改等功能。由于遂宁市发卡人数多,为了统一管理,采取以下步骤:
1、由各服务网点通过人工采集和公共基础数据库相结合的方式完成数据采集工作。
2、按照社会保障卡要求生成制卡数据文件。
3、制卡数据文件生成后,导入发卡系统,并由发卡系统将数据加载到卡片当中。
实现对社保卡的发行管理,对社保卡的发放全程跟踪;
1、社保卡网点领卡登记
2、记录每张社保卡的流向,便于追踪社保卡;提供网点分级领用
3、社保卡激活、启用
4、社保卡发放查询
4.1.4. 发放管理
1、发放登记管理子模块:记录发放卡片的卡号,更新到卡监控数据集中。
2、资源应用监控子模块:根据应用锁定名单,记录锁定卡号、锁定应用,更新资源应用监控数据集。
22
3、持卡人信息管理子模块:更新持卡人信息数据集,记录卡片对应的持卡人基本信息,包括姓名、性别、年龄、户籍所在地地址和联系电话等,输出卡发放地点,记录持卡人申领纪录(包括补卡、换卡申请时间、地点、申请人等信息)。
4、发卡进度管理子模块:对从卡片个人化到发卡的整个过程的控制,制定相关的卡片个人化计划,控制卡片的发放实现均衡生产。
、发放申请管理子模块:审核市民的补卡换卡申请,发送批准指令到现场5
发卡子系统。
6、统计查询子模块:卡片发放应用数据统计查询。
4.1.5. 补卡换卡管理
1、权限管理子模快:输入管理员id和密码,验证合格才能进入系统。
2、申请子模块:输入身份证号码、姓名或原卡号,调出持卡人信息数据集中对应的持卡人基本信息表单,并打印成申请信息核对表。
3、数据提取子模块:输入原卡号,输出卡应用管理数据档案集和卡片状态数据档案集的对应信息,连同持卡人信息数据集的基本信息,并根据应用管理数据档案集中的数据格式信息进行打卡输入数据格式的转换和组织。
4、卡个人化子模块:通过装入打卡数据生成发卡数据送给台式制卡机处理卡片个人化制作。
5、密钥管理子模块:用于为发卡系统提供安全机制,访问并提取密钥内容,用于卡内密钥装载。
4.1.6. 卡交易管理
社保卡交易管理系统对业务系统与社保卡中心产生的交易进行管理。从交易的发起发业务需求,存在以下几类交易管理功能:
23
4.1.6.1. 银行交易
提供银行金融应用的交易业务管理,包括银行卡与社保卡绑定交易管理、医保现金交易数据结算管理(账户圈存、社保卡挂失通知、社保卡注销通知、结算明细核对)
4.1.6.2. 社保卡信息更新交易
提供业务系统发起的个人信息勘误等交易管理
4.1.6.3. 社保卡制卡交易
批量制卡信息导出接口(与卡商协调制定),零星制卡与制卡设备之间的数据交换接口
4.1.7. 卡系统维护
进行平台运行所需的配置维护修改,数据字典的维护;
1、读卡配置维护
2、社保卡网点信息维护
3、卡商信息维护
4、单位信息维护
5、数据字典维护
4.1.8. 用户权限管理
主要针对不同用户不同的操作权限,为便于管理,为他们分配不同的用户角色,包括后台操作员、网点操作员和普通用户,基于卡的应用规划和密钥应用的服务,都由后台操作员来管理操作。具体可以自定义各种权限组合方式。应用单位共享此安全特性的接口,纳入统一管理。系统采用CA证书的方式来实现用户角色的分配。它主要包括四个业务模块:
24
4.1.8.1. 用户管理模块
这里的用户是指能够使用该社保卡管理平台的合法操作者,只有这样的操作者才能够使用该平台执行相关制卡、发卡和数据交换等功能。
1、用户信息的新增、修改、注销;
2、用户的密码修改;
3、用户的登录管理;
4.1.8.2. 权限管理模块
约束每个用户的操作权利范围,使系统的安全性更高;
1、权限的管理;
2、权限的划分;
3、角色权限的分配;
4.1.8.3. 角色管理模块
具体的职责权限按岗位角色来管理,每类用户设置一个角色,系统的功能模块操作划分统一分配角色来赋予用户权限;
1、角色的新增、修改、注销;
2、用户角色的赋予
4.1.8.4. CA验证管理模块
通过CA验证用户的登录,保证系统的高安全性;
提供的功能主要有:
1、统一用户管理
与社保卡系统的用户相结合,实现用户统一管理、统一使用、统一存储
2、统一用户证书
25
登录社保卡的各个业务系统,一个用户只需要一个证书,不必记多组用户名和密码
3、统一用户认证
可对用户登录、关键业务(如:交易、卡信息变更、申请)等关键操作进行用户签名
4、统一用户访问日志
对于用户登录、用户签名等操作都进行统一日志管理,并提供日志查询、分析、审计功能,对可疑日志进行报警。
4.1.9. 卡库存管理
实现对出入库物品资料和操作员操作的精量化管理。具体功能包括:白卡、成品卡、补卡、换卡等卡片的出入库登记和操作员验收登记;各类卡片申领登记核准;入库记录、出库记录、库存记录的综合查询;入库情况、出库情况、库存情况的日报、月报和年报的生成与打印等功能。
4.1.9.1. 空白卡管理
, 空白卡入库
从卡片供货商处购进空白IC卡片时,要当面进行清点。然后按重要空白凭证的管理要求将领回的空白IC卡卡片登记入库。
由于每批卡的制造密钥不相同,因此在存放空白卡片时应保持原包装并登记卡片批号。
, 空白卡出库
发卡中心制卡领用空白IC卡片时,应填写领用申请单。库房要登记空白卡片领用登记簿。
, 空白卡查询
日志查询
26
4.1.9.2. 坏卡、废卡管理
对于过期或作废的卡片应予以销毁,销毁时需多人在场共同执行。
各级密钥管理中心要建立废卡管理档案,注明回收日期,并将废卡做破坏性处理后,统一入库保管,定期销毁。
销毁时,应核对簿实,由销毁小组监督销毁,防止作废的社保卡散失在外。 4.1.9.3. 成品卡管理
成品卡指已经经过制卡的各种密钥卡、管理卡、社保卡、PSAM卡。
各种密钥母卡必须由专人按卡和密钥分开保管原则管理和使用。
所有成品卡必须建帐登记,按重要空白凭证的管理制度调入调出。 4.1.9.4. 应用终端管理模块
应用终端主要记录所有社保卡终端社保的拥有、使用情况。
终端档案子模块:系统纪录卡片应用的终端设备,包括:终端设备的使用地址、终端设备的厂家型号、驱动版本号、PSAM卡类型等。
终端日志子模块:系统记录针对终端的操作日志。
4.1.9.5. 卡接收管理
对于满足异地业务社会保障卡制作或者零星补卡的业务,将采用由卡商制作半成品空白卡,完成卡结构初始化和密钥加载后,根据实际卡制作需求,由零星制卡设备进行零星制卡。
4.1.9.5.1. 半成品卡接收管理
对于半成品卡,在卡流转过程中需要进行发送接收管理,确保每张卡状态的跟踪和发放,主要的管理内容包括:
1、批次管理:根据社保卡制卡数据的提交结果,确认每批社保卡的制作完
27
成入库;
2、发放数据比对:将制作完成的半成品卡内数据与提供卡制作商的个人数据进行比对,确保卡内数据准确有效;
3、坏卡标识管理:对于半成品个性化卡的质量进行检查,整理出坏卡无效卡,进行标识管理,重新制作发放;
4、发放/激活管理:对半成品个性化卡通过各级医保经办机构、街道、社区、单位等进行发放到个人,并通过激活手段正式使用社会保障卡。 4.1.9.5.2. 空白卡接收管理
对于省厅进行初始化完成的空白卡,尚未写入个性化数据,运送到各区市后需要进行接收管理,确保每张卡领用管理、状态的跟踪和发放,主要的管理内容包括:
1、坏卡标识管理:对于空白卡的质量进行检查,整理出坏卡无效卡,进行标识管理;
2、批次入库管理:根据空白卡预定申请,按照批次进行社保卡卡片的入库;
3、空白卡领用管理:根据各地劳动保障部门的要求,进行空白卡的领用登记;
4、空白卡制卡管理:通过整理的个人个性化信息,写入空白卡,形成半成品卡;
5、发放/激活管理:对半成品卡通过各级医保经办机构、街道、社区、单位等进行发放到个人,并通过激活手段正式使用社保卡。
4.1.9.6. PSAM卡管理
根据遂宁市各用卡区域的实际应用需要,确定所需PSAM卡数量、用途和密钥清单,由省厅负责向人力资源和社会保障部统一申领、代购已加载国家级密钥的PSAM卡,并按照密钥清单加载省级密钥。
各地区需增发或更换PSAM卡,应向省厅及时进行申请和订购。各地区对社会保障PSAM卡要严格管理,对下发使用PSAM卡的单位和操作人员进行严格审定
28
和登记,已损坏的PSAM卡要集中回收、销毁。
对于PSAM卡的生命周期进行管理,确保每张PSAM卡能够进行唯一地址和使用的跟踪。
终端设备的授权通过安全模块PSAM卡实现。二级密钥管理中心负责统一制作和发行管理社保卡配套的PSAM卡。
PSAM卡管理主要包括PSAM卡申请、PSAM卡权限管理、PSAM卡发放管理等。
终端设备的授权通过安全模块PSAM卡实现。二级密钥管理中心负责统一制作和发行管理遂宁市社保卡配套的PSAM卡,包括各个政府应用的PSAM。 4.1.9.6.1. 业务流程
业务处理流程如下图所示:
申请
N新增应用,
Y
权限组定义
PSAM卡制作
PSAM卡发放
图 4-1 业务处理流程
相关应用的主管部门提出PSAM需求申请。
如果是新增应用,还应当详细指明业务所需求的社保卡操作权限(组)种类,以及每种类别的详细权限要求。
4.1.9.6.2. 功能模块
功能模块图如下所示:
29
PSAM卡发行管理模块
申请子模快
权限管理子模快
发放管理子模快
PSAM卡信PSAM卡发放
息数据集信息数据集
图 4-2 功能模块图
各个子模块功能如下:
申请子模块:输入业务id号、PSAM卡申请数量。如果是新增业务,则创建新业务id号。
权限管理子模块:分配社保卡应用操作权限种类,以及具体权限类型,包括可读、可读写,存入到PSAM卡信息数据集中。
发放管理子模块:在PSAM卡发放信息数据集中,录入所有者信息,包括应用单位名称、终端种类、终端编号、账户号、发放时间等。
30
5. 卡系统接口方案
5.1.与银行对接
5.1.1. 社保卡和银行卡结合方式
根据《中国人民银行 人力资源社会保障部关于社会保障卡银行业务应用有关事宜的通知》(银发〔2010〕348号)的文件精神,过渡期间安排是具有金融功能的社会保障卡是在社会保障卡上加载隐蔽磁条的方式实现,金融功能仅限借记应用功能。银行卡和社会保障功能相结合的功能主要有:
1、提供银行支付额度,实现自付部分的支用;
2、实现社保费用的代收代缴;
3、实现有关个人资金的直接发放、报销;
银行卡的使用按照金融系统的现有要求进行使用,社保卡与银行卡的对接主要体现在社保、财政补贴等政府类服务的相关金融功能服务方面。 5.1.2. 网络对接
为实现社保卡与银行卡的对接,需要保障网络方面的互连互通,以支撑应用的对接。
银行体系的网络保持不变,增加社保特色业务平台作为对接的前置设备和应用,社保提供前置数据交换平台与银行进行对接。两台牵制设备通过专线连接,确保各类接口应用。
5.1.3. 业务对接
5.1.3.1. 批量发卡对接
, 社保统一制卡模式
社保提供给银行制卡清单,银行产生加密后的制卡文件,交换给社保,社
31
保在芯片个人化时的同时,根据银行提供的制卡文件写二磁道信息,在卡面上打印银行卡卡号。银行卡的密码为统一的初始密码,需修改后才能使用。
, 银行统一制卡模式
社保提供给银行空白卡片和社会保障卡个人信息,由银行打卡机统一来完成照片印制、芯片的个人化,银行卡的磁道初始化。
, 分别个人化
社保将空白卡给银行,银行写二磁和印卡号,后返回给社保,社保进行芯片个人化。(考虑到大部分制卡机写磁模块头在前,写芯片模块在后)。 5.1.3.2. 即时制卡(零星制卡)对接
对于零星的挂失换卡或损坏换卡,在集中的换卡点,银行提供即时制卡功能。 5.1.4. 系统对接
5.1.4.1. 银行卡绑定功能
刷银行卡取得银行卡卡号、银行账户密码,银行后台核验密码,并取得客户信息,前端再输入社保卡卡号,送社保系统,取得社保信息,做身份核对,如果一致,则登记社保号、银行卡卡号的签约关系。(同时签约关系送社保)
业务约定:一张社保卡只能绑定一张银行卡,要求为同一个人。允许修改银行账户的绑定关系。
5.1.4.2. 资金划进功能(从银行到社保)
刷银行卡,输银行账户密码,划转金额,送银行主机冻结账户指定金额,冻结成功后,发社保系统,社保系统增加该账户的银行支付额度,如果社保返回成功。打印额度划转单,如果返回不成功,送银行主机解冻指定的金额。
32
5.1.4.3. 资金划出功能(从社保到银行)
刷银行卡,输银行账户密码,划转金额,发社保系统,社保系统检查银行支付额度,如果社保系统的银行可用支付大于或等于划转金额,则扣减该账户的银行可用支付额度,返回成功信息给银行,银行端则送主机解冻指定金额,解冻成功后,打印银行支付额度划转单。如果社保系统的银行可用支付额度小于划转金额,返回额度不足信息给银行。
5.1.4.4. 银行支付额度查询功能
刷银行卡,输银行账户密码,送社保系统查询社保系统中银行可用支付额度。 5.1.4.5. 日间记账
在进行社保卡金融应用时,从社保账户上扣除,如果银行支付额度足够,个人自付的部分直接从银行卡可用信用额度中扣除,并登记支付流水,信息包括社保卡卡号、消费地点、消费金额等内容。如果银行支付额度不足,需客户现金支付或电子现金支付。
5.1.4.6. 日终清算
社保和银行约定一个日切点,日切后,社保将前一日的支付流水信息按签约银行发给银行,银行根据流水文件个人账户的解冻扣款,并将资金清分到各资金使用单位。
5.1.5. 社保卡部门与银行部门职责分工
5.1.5.1. 金融机构
金融机构作为社保卡建设的参建单位,在社会保障卡建设中起到关键作用,主要的职责包括:
33
5.1.5.1.1. 项目建设职责
1、社会保障卡加载金融机构隐形磁条;
2、金融机构承担社保卡工程建设费用和社会保障卡制作发行费用;
3、建设覆盖全市的营业网点,确保持卡人能在所在地办理各类金融业务,最大程度方便持卡人,确保持卡人能正常收付;
4、免银行卡账户管理费
5.1.5.1.2. 社保卡发行职责
1、金融机构负责向制卡厂商提供用于社会保障卡磁条的账号号码区段,及磁条数据,用于卡商制卡;
2、对于批量制卡,金融机构接收制卡厂商返回的参保人与银行账号对应的回盘文件;
3、金融机构通过相应营业网点、网上、手机、自助终端等多种途径,负责为持有社保卡和本人身份证的参保人进行银行账户的开通;
5.1.5.1.3. 社保卡应用职责
1、金融机构满足持卡人的各类金融业务;
2、金融机构能够提供社会保险费的缴纳业务;
3、金融机构能够提供社会保障待遇的发放业务;
5.1.5.2. 省级社保卡中心
5.1.5.2.1. 项目建设职责
1、市级社保卡中心负责社保卡系统的规划和建设,包括卡功能规划、金融功能规划、发行模式和流程规划、确定金融机构和制卡厂商,完成信息系统建设等;
34
2、市级社保卡中心负责接收省级公安等部门的数据,并根据地市发卡需求将市级集中数据进行转发;
3、市级社保卡中心建设集中的全市社保卡档案库;
5.1.5.2.2. 社保卡发行职责
1、市级社保卡中心负责审核各地市社保卡中心的发行申请,并提交部信息中心进行审核,并代为采购PSAM卡、提交样卡检测等事项;
、市级社保卡中心管理省级密钥,并代为管理地市级密钥; 2
3、市级社保卡中心根据地市卡发行需求,集中提交批量制卡数据至制卡厂商,并集中接收完成制卡的社保卡;
4、市级社保卡中心根据地市发行需求,集中制作空白社保卡,并由各地市根据零星制卡需求进行领用;
5.2.与业务系统对接
5.2.1. 社会保障卡在业务领域的应用
5.2.1.1. 个人参保关系
服务描述:个人参保关系服务是指个人办理社会保险各险种的新参保、中断缴费、续保、转移、退保、终止等业务,个人参保关系的变化,直接影响到个人的社会保险缴费、待遇、个人账户等。
服务网点:个人参保关系服务可以通过各级社会保险经办窗口办理,也可以通过网上申报、窗口确认的方式办理,以加快办事效率,提高服务的便捷性。
服务过程:个人参保关系服务以社会保障卡为介质,在服务窗口刷卡后,个人可以选择参保关系变更类型,并经业务人员审核后,完成个人参保关系的更改。
服务效果:由于社会保障卡记录了与个人参保关系相关的就业信息、工作经历信息、以往缴费情况等,为人员参保关系的变更提供准确完整的依据信息,
35
参保人员不再需要填写复杂冗长的申请表格就可以办理业务,从而提升社会保险经办机构的办事效率和服务形象。
5.2.1.2. 自由职业者缴费
服务描述:自由职业者缴费是指灵活就业人员在参加社会保险后要定期缴纳社会保险费的业务。
服务网点:自由职业者缴费可以通过多种途径完成,可以通过银行网点、社会保险经办机构网点、网上银行等进行。比如从银行储蓄账户中由银行代扣代缴、从社会保障卡账户中扣缴、现金缴纳等。
服务过程:自由职业者缴费服务以社会保障卡为介质,可以在银行网点办理代扣代缴业务,也可以在银行ATM机上自助完成转账缴费操作。社会保险经办机构可以授权银行网点读取社会保障卡信息,银行与个人签订代扣代缴协议后,每月从自由职业者的储蓄账户(或社会保障卡账户)自动扣缴社会保险费。
服务效果:社会保障卡兼具的社会保障卡账户和银行账户功能,大大简化了社会保险经办机构与银行的接口过程,提高了办事效率和便捷性。 5.2.1.3. 养老待遇申请
服务描述:养老待遇申请业务是指符合退休条件的参保人员,办理退休手续,并按月领取养老待遇的业务。
服务网点:养老待遇领取包括养老待遇的申请和发放过程。养老待遇的申请需要到社会保险经办机构办理,养老待遇发放通过社会保障卡发放。
服务过程:参保人员持社会保障卡办理退休手续,业务人员通过确认参保人员的缴费信息、工作经历信息、职称职务信息、以及其他待遇相关的特殊资格信息等,然后由信息系统判断参保人员是否符合退休条件,并计算退休待遇。符合退休条件的人员,从办理退休手续的下月起,可以通过社会保障卡直接支取养老金。
服务效果:退休人员通过社会保障卡支取养老金,可以实现养老金的领取与日常消费无缝衔接,退休人员可以直接持社会保障卡购物、消费、看病等,
36
方便了退休人员操作。
5.2.1.4. 失业待遇申请
服务描述:失业待遇申请是指符合条件的失业人员,申请并领取失业保险金的业务,以及与失业保险相关的医疗补助金等业务。
服务网点:失业待遇的领取需要到社会保险经办机构或街道社区服务网点办理申请手续。
服务过程:失业人员持卡到服务网点办理申请手续。业务人员根据人员的就业情况、缴费情况、待遇享受情况、培训情况、职业介绍情况等判断人员是否就业、是否从事有偿劳动、是否有就业意愿等失业保险金享受条件。对于符合条件的,计算人员可以享受到失业保险金标准和可享受时间。失业保险金通过社会保障卡发放。
服务效果:失业人员通过社会保障卡可以直接支取失业保险金,并可以直接刷卡消费,方便了失业人员操作。
5.2.1.5. 工伤待遇申请
服务描述:工伤待遇申请是指符合条件的工伤人员,申请工伤认定、劳动能力鉴定、申请并领取工伤医疗费、伤残津贴、辅助器具费等业务。
服务网点:工伤待遇的领取需要到社会保险经办机构或街道社区服务网点办理申请手续。工伤治疗时发生的医疗费也可以在定点医院直接刷社会保障卡结算。
服务过程:工伤人员持卡到服务网点办理申请手续。业务人员根据人员的就业情况、工伤保险参保缴费情况、工伤认定情况、劳动能力鉴定情况等判断人员是否符合领取工伤待遇的条件。对于符合条件的,计算人员可以享受到工伤待遇标准。工伤待遇通过社会保障卡发放。
服务效果:工伤人员通过社会保障卡可以办理工伤认定、劳动能力鉴定、工伤医疗费报销、伤残津贴领取等业务,可以通过社会保障卡直接支取工伤待遇、刷卡进行康复治疗等,也可以直接刷卡消费,方便了工伤人员操作。
37
5.2.1.6. 生育待遇申请
服务描述:生育待遇申请是指符合条件的生育人员,申请并领取生育医疗费、生育津贴等生育保险待遇的业务。
服务网点:生育待遇的领取需要到社会保险经办机构或街道社区服务网点办理申请手续。生育医疗费也通过定点医疗刷社会保障卡结算。
服务过程:生育人员持卡到服务网点办理申请手续。业务人员根据人员的就业情况、生育保险费参保缴费情况、配偶参保缴费情况等判断人员是否符合领取生育待遇的条件。对于符合条件的,计算人员可以享受到生育待遇标准。生育待遇通过社会保障卡发放。
服务效果:生育人员通过社会保障卡可以直接支取生育医疗费、生育津贴等,并可以直接刷卡消费,方便了生育人员操作。
5.2.1.7. 医疗待遇申请
服务描述:医疗待遇领取是指符合条件的人员,在发生医疗费用时,申请并领取医疗费的业务。
服务网点:医疗待遇的领取需要到社会保险经办机构办理申请手续,也可以通过门户网站实现网上申报。医疗待遇也通过定点医疗机构刷社会保障卡结算。
服务过程:参保人员在定点医院看病,或者在定点药店购药,可以通过刷社会保障卡付费。参保人员在非定点机构诊疗的,可以凭发票到医疗保险经办机构办理报销,报销后的医疗保险费用通过社会保障卡发放。
服务效果:人员通过社会保障卡在定点机构就诊或购药,也可以持社会保障卡到医保经办机构保险医疗费,并可以直接刷卡消费,方便了参保人员操作。 5.2.2. 卡系统与外部系统主要对接
卡系统与外部系统主要对接的需求包括:
1、数据采集与各业务系统间的接口
38
用卡交易强验证(如医保实时交易类)、数据异步同步 2、卡信息与各业务系统间的接口
卡信息更新、卡信息勘误
3、与制卡系统间的接口
批量制卡:制卡数据按格式导出,制卡完成后数据的导入 零星制卡:与制卡设备间的交互,制卡数据传送,完成制卡后数据的返回
和制卡状态的更改
4、黑名单管理与各业务系统间的接口
黑名单搜集、黑名单发布
5、与公安系统间的接口,数据定期更新
6、与银行系统间的接口
账户绑定;账户挂失、解冻;卡中心与银行接口;各业务系统与卡中心金
融接口
7、各业务系统对卡信息和卡状态的查询接口 8、卡状态变化通知各业务系统的接口
9、与卡管理分中心间的信息上传接口
39
6. 性能保障方案
6.1.本项目性能要求
在总体系统方案的设计中,充分考虑业务应用的特殊性和复杂性,确保系统的总体性能满足用户要求,不发生长时间业务中断、阻塞、死锁等情况。采用相应的技术保证整个系统高效运行,并制定系统优化策略和方案,保证在今后一段时期内业务增长的情况下,系统仍具有较高的性能。
6.2.性能调优方案
复杂应用系统的性能,涉及较多因素,硬件设备配置、网络带宽、软件环境、以及应用系统的性能等。基于多年的系统建设经验,我公司将会提出基于本项目性能调优方案。
我们的调优方案分别分为系统配置调优、数据库与中间件优化与应用优化三个方面。同时,我们还将结合统一测试平台来不断对于调优后的系统性能进行测试,以达到更好的性能指标。
6.2.1. 系统配置调优
一般来讲,我们会针对用户所提出性能指标,对系统集成过程中对系统的数据量、数据流量、访问频度、访问压力进行科学、全面的评测,并考虑到未来几年中的业务模式及规模,确保硬件指标满足系统的运行性能要求。据此进行硬件配置、网络带宽等估算,提出配置方案。
同时,还包括对于部署模式的优化。将业务应用分布到不同的应用服务器中,均衡了并发访问的压力,对于一些复杂业务过程(例如复杂报表统计)采用单独应用分布的处理方式也可以提高该过程的效率,降低复杂应用对日常业务操作的影响。另外,对于更大规模并发访问的门户操作,将采用多级部署的方式实现,以分担业务压力。
40
6.2.2. 数据库与中间件的优化
应用系统的数据核心就是数据库,因此数据库的性能优化策略至关重要,包括数据库系统参数的优化、存储文件的合理分布、归档方案的科学设计、分区表,索引等数据库对象的合理使用、大批量历史数据的处理等等。另外在数据模型设计过程中对于关键业务的表可以适当采取“以空间换取时间”的冗余策略。
数据库性能优化另外一个相对独立的方面是:对联机事务处理(OLTP)和分析处理(OLAP)提出解决方案,确保决策分析业务的执行对联机业务的处理降至最低。这一方案最基本的原则就是:将OLTP与OLAP进行“库”分离,采用定时同步的技术确保生产结果性数据一致。这样做的根本原因是OLTP与OLAP对数据库的操作模式有本质区别,OLTP以高并发、短事务为特点;而OLAP以低并发、大块I/O为特点,所以要进行库分离,这样即保证了OLTP与OLAP的各自的性能指标,同时也避免了OLAP对OLTP的性能影响。
三层结构较之两层结构最大的优势是有了一个共同的业务逻辑处理的“中间层”,因此必须确保中间层的性能发挥到最佳状态。大致包括以下几方面:中间件的集群策略、中间件系统参数调优、cache机制的合理使用(如系统中使用最为频繁的代码表可以一直缓存在应用服务器上,只占用一条数据库连接定时保证Cache与Database 的同步)等。
6.2.3. 应用系统的优化
应用系统是直接面向最终用户的一层,设计、开发人员在建设业务系统的过程中将全面考虑到性能优化,包括科学利用各种设计模式、采用高效的编程实现、多进程/线程技术的利用等。在针对应用系统优化中,主要采用以下方法:
数据库结构优化。针对实际的组织人员结构特点,对应用系统的数据库结构进行优化设计,目的的是提高日常80,业务操作的效率,并对复杂业务操作进行专门的数据库优化考虑,例如对于时间戳相关数据采用备份表的方式,以提高运行效率。
采用定时调度的模式合理安排任务运行。应用系统提供任务管理机制,该机制对于一些复杂业务的性能提升很有帮助。对于这样一些业务逻辑复杂、非常耗
41
费资源的操作,如复杂报表、BI分析等,事先定义好任务调度计划,应用在资源空闲时候自动启动相应任务。
利用数据Cache机制,对频繁访问的数据进行处理,提高数据访问效率。
其他。针对社会保险信息管理系统项目特点与性能瓶颈的其他应用系统的优化措施,这些措施主要基于对应用系统的性能测试的结果基础上提出。
性能测试是检验系统性能,提出优化措施的基础,内部测试主要用于系统的性能调优。
6.3.从架构设计解决系统性能问题
(1)面向性能的业务流程分析
明确性能问题在整个软件生产与运行过程中的重要意义,在考虑架构分析与设计的时候,出发点与指导原则是帮助用户使用某种技术手段来高效地完成业务流程,其本质是“高效的业务流程”,而不是一个计算机系统或计算机应用。在这一原则之下,我们的应用开发是围绕着开发高效“业务流程”展开的,Java或其他技术只是我们的一种技术手段而已。避免由于具体的技术实现方案对业务流程分析中的性能指标的束缚。
(2)“化整为零”的领域模型设计
领域模型分析与设计过程中,抽取、抽象出稳定的领域模型,并且剥离出严重影响系统性能的长事物处理与批量事物处理,针对长事务处理采用“化整为零”的处理模式,将集中式处理过程中的具体环节分散到日常的业务处理功能中,对于批量业务处理采用多线程并行独立处理。月末批量结算业务采用存储过程方式,多进程、多线程并行处理,提高数据处理能力 月末批量结算对业务经办系统是负载较大、占用时间较长的业务应用。建议采用存储过程方式,在主机系统上采用多进程、多线程的并行处理方式,提高结算的效率,减少结算业务对系统的时间占用同时,可对核心业务数据建立台账表,在业务经办或者月末批量结算过程中产生,集中各类查询、统计数据,并以合理的表结构为查询、统计提供高效的服务。这种“化整为零”领域模型设计在面对业务流程与模型的自然变化面前,可以通过最少,最小的程序变动,降低对应用性能的影响。
(3)面向性能的架构关键技术选型
42
在架构设计的时候要时刻围绕着系统的QoS需求,并将这些需求转化到Service的设计上,真正做到“面向性能的架构关键技术选型”,如下内容概述出在架构设计部分关键技术选择是如何围绕“性能”进行考虑的。
, RIA(Rich Internet Application)客户端架构
在保证良好的用户体验的同时,处理UI界面的展现与渲染过程中充分利用客户机的运算与处理能力。
, 数据交互格式定义
精简的客户端与应用服务器端数据交互格式,在不丢失数据语义的同时,尽量降低在网络中传输的数据内容。
, 自动事物管理
利用面向切面的技术进行事物管理的切入,从而实现自动化的事物处理,避免编程式事物导致的事物与数据库连接问题
, 并行处理
并行处理是通过利用J2EE层执行模式的多线程和多CPU特点来提高性能。与使用一个线程或CPU处理任务相比,以并行方式处理多个子任务可以使操作系统在多个线程或处理器中进行分配这些子任务。
, 异步处理
异步处理只处理那些非常重要的任务部分,然后将控制立即返回给调用者,其他任务部分将在稍后执行。异步处理是通过缩短那些在将控制返回给用户之前必须处理的时间来提高性能的。虽然都做同样多的事情,但是用户不必等到整个过程完成就可以继续发出请求了
, 缓存机制
缓存中存放着频繁访问的数据,在应用的整个生命周期中,这些数据存放在持久性存储器或存放在内存中。在实际环境中,典型的现象是在分布式系统中每个JVM中有一个缓存的实例或者在多个JVM中有一个缓存的实例。缓存数据是通过避免访问持久性存储器来提高性能的,否则会导致过多的磁盘访问和过于频繁网络数据传输。在架构设计过程中,针对待实现系统中的实际业务特色,剖析出客户端与中间件中频繁使用的但又很少变化的数据。通过一些技术手段,将这
43
些数据在合适的时机(系统启动,用户登录,第一次使用等)以一定的数据结构存放客户端或者中间件内存中。避免每一次使用都进行发送远程调用请求或者数据库访问,提高系统的运算与处理速度。
, 资源池,对象池
在应用系统运行过程中,特别对于一个高并发的应用系统资源的频繁地创建都一个高成本的动作,在架构设计过程中对数据库连接,业务逻辑组件等高并发,高成本的对象与资源采用池化技术,在应用系统启动过程中以对象池,资源池的方式,初始化到池中,降低频繁的创建与销毁,同时也降低内存碎片的产生。
(4)持续性的性能管理
持续性的性能管理主要是指,在系统构建过程中持续性地性能测试。持续性能管理的前提条件是有一套完整定义的单元测试用例,健壮的测试框,以及明确的,量化的性能需求。除了必不可少的单元测试,集成测试,压力测试以外,持续性的性能管理更突出了自动化测试的重要意义,自动化方式可以创建重复的测试过程并迅速报告应用代码的质量。只有自动化方式才能保证正确地遵循这些测试过程,并且保证准确和一致地测试应用组件。
6.3.1. 分层的设计方法
分层应用是将组件等分隔到不同的层中,每一层中的组件保持内聚性,并且大致在同一抽象级别。每一层都应与它下面的各层保持松散耦合,避免使较低级别依赖于较高级别。
通过分层,可以限制子系统间的依赖关系,使系统以更松散的方式耦合,从而更易于维护。分布式服务层依赖较低层,但是较低层的细节不会显示在包含应用程序和业务逻辑层的较高层中。应用程序开发人员在较高抽象级别工作时不必考虑诸如 TCP/IP 数据包和网络字节排序之类的细节。它还可以在替换较低层时不对较高层造成任何影响。
采用从整体架构层次来看,系统可分为表示层、业务逻辑层、数据持久层。见下图:
44
数据库客户端展现逻辑业务逻辑
Application Web ServerServer
BrowserSJeDrBvJAVAClJSPeDataBasetBrowser
图 6-1应用软件层次构架示意图
1)表示逻辑(客户层)为第一层:它的主要功能是实现用户交互和数据表示,为以后的处理收集数据,向第二层的业务逻辑请求调用核心服务处理,并显示处理结果。
2)业务逻辑(服务器组件)为中间层:这些组件由中间件管理,实现核心业务逻辑服务并将这些服务按名字广播,管理并接受客户的服务请求,向资源管理器提交数据操作,并将处理结果返回给请求者——即客户或其他服务器。
3)数据(资源管理器)构成模型的第三层。比如关系数据库,负责管理应用系统的数据资源,完成数据操作。服务器组件在完成服务的过程中通过资源管理器存取它管理的数据,或者说请求资源管理器的数据服务。
在三层客户机/服务器模式上架构的应用系统不但具备了大型机系统稳定、安全和处理能力高等特性,同时拥有开放式系统成本低、可扩展性强、开发周期短等优点。
对于其中最关键的业务逻辑层,又可以分为控制框架层、业务组件层、数据访问层和相关资源层。
控制框架层管理业务组件的装配和调用,是业务逻辑层的核心引擎。业务组件层集中了各种实现业务逻辑的组件;数据访问层封装对数据存储的各类访问操作;相关资源层包括了各种相关应用支撑功能,如:缓存、对象池、线程池、消息、日志等。
控制框架层与相关资源层构成系统的分功能属性部件,业务组件层和数据访
45
问层构成系统的功能属性部件。
通过系统分层,改变了传统信息系统的大一统结构,区别系统的功能属性与非功能属性,将不同的功能交给相应的功能组件来完成。在单笔业务或者小用户量的情况下,分层的系统架构并不具备优势,其关键优势在于对并发的大数据量业务的响应和处理方面,通过在各层中合理的分布系统压力,改变了传统信息系统压力集中的缺点。同时,采用分层技术架构,可以根据系统性能的具体需求,对不同的层次进行有针对性的优化处理。
6.3.2. 同步与异步处理相结合的系统体系架构
传统的业务处理模式通常采用直接的请求/应答方式进行同步处理,在业务高峰发生的时候,由于对资源的集中使用造成系统的响应速度急剧下降。通过在系统架构中加入异步业务处理模式的支持,将一些业务通过异步方式放入工作队列中,在系统空闲的时候再从队列中获取工作任务进行处理,减少对资源的集中占用,保证在业务高峰期的系统响应性能。
6.3.3. 缓存、池化技术的使用
在实际业务处理过程中,数据库访问、网络传输以及新建对象都是成本较高的资源开销,对于性能要求很高的业务系统来说,采用合理的技术减少高开销的资源访问是必须考虑的内容。采用缓存、池化技术,将频繁访问的资源放在I/O性能较高的载体上,减少集中的和缓慢的I/O访问,从而达到提高系统性能的目的。
46
图 6-2 缓存、池化技术
6.3.4. 分布式业务处理模式
多层体系结构将业务逻辑与数据存储和显示分开,使得系统层次更加分明,可扩充性、安全性得到大大提高,同时它也使得分布式计算得到广泛应用,使得系统的性能由于采用分布式计算而大大提高。
采用分布式计算有着多方面的技术优势,包括:
, 逻辑封装性
这是分布式模式中最具诱惑力的特征,这种模式将以往C/S结构中全部由客户机完成的事务逻辑中的一部分从客户端分开。当使用户需要动态改变一个应用软件的商业逻辑规则时,只要改变一个应用服务器的程序即可,而不需要更改客户端用户界面,这样就无需中断用户,为最终用户重新发放新的界面软件或亲自上门为其安装调试并重新培训用户,提高了工作效率。这种多级模式对于需经常、快速改变应用程序的行业很有帮助。
, 性能
性能的提高是三层模式最终被用户采用的主要原因。将复杂的应用和商业逻辑分离出来由专门的一台或多台应用服务器来处理,既可以提高应用的执行速度,也可以减少网络调用的通讯量。不过这种性能提高是有一定代价的。这就是开发时要将应用逻辑分割为客户端逻辑和服务器端逻辑,这就增加了设计的复杂性。
47
, 安全性管理
在分布式计算模式中,由于所有的商业逻辑都驻留在服务器端,信息管理部门就可以十分方便地监控服务器的运行情况,很容易地控制访问服务器以及与服务器应用打交道人员的数量。这可以大大简化管理员对系统的管理,减轻系统维护的工作量,并确保系统的可靠运行。
针对本项目的特点,在构架系统时,应充分考虑分布式计算的特点,在数据大集中的模式,通过应用服务器及其群集技术,将计算逻辑合理分布以保证系统的性能。
6.4.从数据库配置及优化解决系统性能问题
数据库是应用的核心,做好数据库的设计与优化是保证系统性能的关键。数据库的设计和优化通常包括如下内容:
1、数据库的设计,包括表的设计、索引的设计等。表的设计要兼顾灵活性和易用性;
2、根据表、索引的设计情况,估算每个表的基准数据量及大小,还有表数据的增长情况,合理设计每个表的参数值。对于数据量大的表,采用分区表和物化视图等技术,以及在设计上考虑历史表等方法来提高性能;
3、根据表、索引的设计情况,合理设计表空间的大小、在磁盘上的分布以及相关的参数;
4、合理调整数据库的初始化参数以及操作系统的内核参数等;
、合理规划客户端/连接池对数据库的连接数目; 5
6、根据现场实际情况,定期监测和检查数据库的使用情况,并对不合理参数做出调整。同时,也定期对数据库中的碎片进行整理。
社会保险信息管理系统项目规模大(海量数据),连接点、实时性要求高,因此如何处理海量数据,是保证系统性能的关键。本节根据海量数据的特点阐述系统性控制措施。
本项目采用Oracle数据库,因此,数据系统性能的控制将结合Oracle展开。
“海量”数据库的概念一直在不断变化,1995 年时,容量大于100GB 的
48
数据库就被认为是大型数据库。仅仅几年之后,数万亿字节的数据库已投入市场。VLDB 是超大型数据库的(very large database)简称。
6.4.1. 分区表和索引(partition table and index)技术
根据实际经验,在一个大数据库中,数据库空间的绝大多数是被少量的表所占有。如何简化大数据库和管理,如何改善应用的查询性能,一般可以使用分区这种手段。
所谓分区就是动态地将表中记录分离到若干不同的表空间上,使数据在物理上被分割开来,便于维护、备份、恢复、事务及查询性能。当使用的时候可建立一个连接所有分区的视图,使其在逻辑上仍以一个整体出现。
ORACLE引进了数据分区的技术,以加强对VLDB的支持。
当表的数据增大时,数据的载入/载出、备份/恢复占用了大量的时间,也使数据库管理员的任务变得复杂、繁琐,直接影响系统的可用性。所以,为了便于管理、提高关键数据的可用性、提高查询的性能,ORACLE可基于一定的关键值把表和索引分为若干可管理的小块—分区,由于每个分区的操作是相对独立的,从而避免因一部分数据的无法访问而影响其他分区的数据的使用。这带来两方面的好处:第一、提高性能,只对存有被查数据的分区进行查找,从而加快速度;第二、高可用性,备份/恢复可以以分区为单位进行,减少管理时间;另外,数据是基于分区管理的,硬件的失败只会影响本地分区,不影响其他分区上的数据的操作,从而提高系统的可用性。这种分区的机制,对应用系统是透明的。
图 6-3Oracle分区机制
Oracle的分区( Partitioning Option)方式有 hash,range和composite 多种。
49
这种灵活的分区方式好处是:
, 目标准确的数据服务器管理
, 高可用性
, 应用性能提高
由于结构的限制,多数服务器的分区导致为提高性能以牺牲目标准确的数据服务器管理和高可用性为代价。 必须在它们之间作出选择。Oracle的composite 分区方法则消除了这种情况。
采用Oracle的分区,数据的存储、管理、访问和备份都完全按你的业务要求。例如许多公司喜欢按日期分区 ,当数据到达一定的日期后,数据就不能再被查询。Oracle的Range 分区使过期的分区,仍然可被查询。
Oracle的分区显著地改进了数据的可用性。单一分区可被单独离线,不影响其它数据运行。查询永远是在所有分区正常的情况下才进行。 Oracle决不会提供不完整的查询结果。
6.4.2. 并行化(parallelism)技术
具有大内存与CPU资源的巨型系统已经出现十几年了,这些系统多采用MPP或SMP结构,具有大计算能力,并且有很好的扩充性,然而,如果应用软件不能有效地利用这些计算机的特点,那么计算的能力将受到限制。
Oracle早在7. 1 版本中就引入了并行查询选项(PQO),以充分使用这些系统中可用的硬件资源。Oracle 并行查询选项允许长时间运行的SQL操作(主要是查询),以协同方式在多个CPU间运行,这使系统减少了资源密集型SQL 操作的运行时间。
并行执行选项使多个服务器进程可以并行执行一定的操作。进程,称为查询协调器,将一条语句的执行调配到多个服务器执行,协同所有服务器的结果,并将结果返回给用户。
50
图 6-4并行技术
1、并行SQL(parallel SQL execution)技术
Oracle 数据库是一个由不同的进程维护的物理数据文件的集合。这样一套后台进程与共享内存段,统称为Oracle 实例,使并发用户可以与数据库交互。当一个用户需要使用(select、insert、update或delete)数据库中的数据时,他需要连接到数据库。在大多数UNIX 系统中,Oracle使用两任务体系结构。在这个模式中,当一个用户连接到数据库时,派生一个附加的进程,通常称为影子进程、前台等等。影子进程代表用户存取共享内存段与数据文件。
在VLDB环境中,用户通常需要处理大量数据,影子进程完成必需的工作需要花费一段时间。由于影子进程操纵数据工作时间很长,很辛苦,系统很可能有空闲的CPU与内存资源。这正是Oracle 并行查询选项发挥作用的地方。通过使用这个选项,Oracle 可以将一个用户的大量数据处理请求分解为多个、相对较小的工作单元,这些工作单元可以由不同的进程并发执行。它使用一套专有后台进程,称为并行查询伺服(服务器),完成这项工作。影子进程被提升为管理的角色,并称为查询协调器,查询协调器的职责如下:
1) 将功能分解为并行的小片。
2) 确保可以得到足够数量的并行查询伺服器。
) 为给定的工作初始化伺服器进程,并在PQO服务器的进程之间分派工3
作。
4) 从伺服器进程收集输出并将输出返回。
5) 当完成预期的工作后,查询伺服器进程被释放,并可由其他的工作获得。
在最有利的情况下,并行执行减少了执行时间,执行时间的因子是使用的查
51
询伺服器的个数。然而,由SQL语句消耗的总时间并没有减少。并行执行比顺
序执行使用更多的系统资源,这样可使的系统的资源得到有效的利用,而不是浪
费。
Oracle服务器概念手册指出Oracle可以并行执行以下的操作:
1、表扫描;
2、嵌套循环连结;
3、排序合并连结;
4、哈西连结;
5、“Not in ”;
6、Group by ;
7、Select distinct;
8、Union 与union all;
9、集合;
10、从SQL 调用的PL / SQL 函数; 11、Order by;
12、Create table as select;
13、Create index;
14、Rebuild index;
15、Move partition;
16、Split partition;
17、Update;
18、Delete;
19、Insert . . . select;
20、Enable约束(表扫描是并行化的); 21、星形变换。
22、并行数据装载(parallel load)技术
52
在VLDB中快速的数据装载速度显得非常重要,ORACLE的SQL * LOADER工具可以并行执行,从而可提高数据装载的速度。Oracle的并行装载有以下特点:
, 每个SQL * Loader会话分派了一个新的区间并将数据载入新区间中,为
优化系统的I / O性能,强烈建议在OPTIONS子句中使用FILE与
STORAGE关键字控制新区间的位置与大小。FILE关键字可以在命令行
或控制文件中定义,然而,存储子句只能在控制文件中定义。 , 并行加载要求没有本地或全局索引。如果存在任何索引,会产生一个错
误信息并退出加载操作。在加载之前需要手工删除索引,在加载完成后,
再重建索引。
, 每个加载会话需要一个表上的共享锁。
, 每个加载会话都是独立的,在加载会话之间没有任何联系。 , 当一个会话完成加载后,Oracle将加载的区间与已有的区间连接到一起,
上次加载区间中没有使用的块作为空区间返回,这导致加载之后非标准
大小的区间。即使通过加载控制文件中的存储子句选项指定了区间大
小,截断也会发生。
, 并行恢复(parallel recovery)技术
, 在VLDB中中当数据库出现意外损坏而需要恢复时,ORACLE提供了并
行恢复的机制使系统的恢复进间尽量缩短。
Oracle 的基本读-写单位是数据块。每当对块进行修改时,Oracle 将这些改变以重做日志的形式记录下来,如果需要时,可以使用这些日志重建这些块。如果由于介质失效或任何其他的原因而造成当前数据文件的内容丢失,那么这些文件可以从适当的备份拷贝中重建,然后进行恢复。恢复过程包括以下步骤: 1 )读日志文件并获得数据块的修改序列号。
2 )决定哪一个数据块需要改变。
3 )在高速缓存中读这些数据块。
4 )从重做日志中将相应的改变应用到这些数据块。
5 )将修改完成的数据块写回硬盘。
53
为在并行状态下进行恢复,需要设置初始化参数RECOVERY_PARALLELISM。也可以使用RECOVER 命令的PARALLEL 子句代替。在并行恢复过程中,服务器管理器或SQLDBA 会话读重做日志文件并将改变传递给并行服务器进程。然后这些进程读相应的数据文件并应用改变。
并行传播(parallel propagate)技术
复制使你可以维护多个数据库中的一个或多个数据库对象映象。ORACLE 服务器在这些数据库之间通过数据库链传送数据,以传播对复制对象的改变。SNP后台进程执行数据复制。然而,如果要复制的数据卷非常大,同步这个对象会花费很长时间。ORACLE 8 使用并行复制,其中可以使用多个并行服务器进程传播事务。
6.4.3. 实体化视图(materialized view)技术
实体化视图的基本技术与创建和维护快照的技术类似。实体化视图是一个存储派生数据的表。创建它时,指定用来提供实体化视图的SQL 。
对于VLDB,实体化视图可以提供一些性能优势。根据基本SQL 的复杂性,可以提供具有增量变化的实体化视图(通过一个实体化视图日志)而不是在数据刷新期间重建它。与快照不同,实体化视图可以被优化程序用来动态改变查询的执行路径。即使实体化视图在查询中没有被命名,这种称作查询重写的特性也可以使优化程序使用实体化视图来代替被实体化视图查询的表。例如,如果你有一个大型SALES 表,就可以创建一个按区域汇总SALES 数据的实体化视图。如果用户为获得一个区域的汇总SALES 数据查询SALAS 表,Oracle 就可以使这个查询使用实体化视图来取代SALES 表。这样就可以减少对一些最大表的访问量,从而改进系统性能。若要启动查询重写的实体化视图,实体化视图的全部主表都必须处于实体化视图的模式,并且你必须有QUERY REWRITE 系统权限。如果视图和表处于不同的模式,就必须有GLOBAL QUERY REWRITE 系统权限。通常,应按与其所基于的表相同的模式创建实体化视图,否则就必须管理创建和维护实体化视图所需要的权限与授权。
与快照一样,实体化视图创建一个存储数据的局部表和访问该数据的视图。根据实体化视图的复杂性,Oracle 也可能在实体化视图的局部表上创建一个索
54
引。可以搜索实体化视图的局部表来改进针对实体化视图的查询的性能。 6.4.4. 位图索引(bitmap index)技术
通常,索引创建在选择性很高的那些列上,即,在这些列上的行很少有相同的值。对于一个索引来说,其值只有“Y”或“N”的列是非常糟糕的,因为该索引只含有两个值,所以通过这个列的任何访问都将返回表的一半记录。不过,如果这些索引列中的值属于一个完全静态的数值组,就应该考虑使用位映射索引。
例如,如果在非常大的表EMPLOYEE中只有很少几个不同的State_Code值,即使在where子句中经常使用这个列,通常也不在State_Code上创建一个B*tree索引。然而,State_Code列可以利用位映射索引。
位图索引在内部将列的不同值映像到每个记录上。在这个例子中,假设在一个非常大的EMPLOYEE表中只有两个State_Code值(NH和DE)。由于只有两个State_Code值,所以State_Code位映射索引只有两个不同的位映射条目,如果表中前5行的State_Code值为“DE”,后面5行的State_Code值为“NH”,那么State_Code位映射条目就如下面所示:
State_codebitmap
De:< 1 1 1 1 1 0 0 0 0 0 >
NH:< 0 0 0 0 0 1 1 1 1 1 >
在上面的程序清单中,每一个数字代表EMPLOYEE表中的一个行。由于这里只考虑10行,所以只有10个位映射值显示出来。通过读取State_Code的位映射,前5个记录的值为“DE”(用1表示),后5个记录的值则不为“DE”(用0表示)。对这个列可能有更多的值。在这种情况下,对应每一个值都将有一个独立的位映射条目。
Oracle优化程序能够在查询进程中动态地将位映射索引内容转换为RowID。这种转换能力使优化程序可以使用那些有许多不同值的列上的索引(通过B*tree索引)和那些有很少不同值的列上的索引(通过位映射索引)。
在创建位映射索引时,Oracle将存储的位映射进行压缩。其结果是位映射索
55
引需要的空间只是正常索引所占空间的5,,10,。因此,对于频繁出现在where子句中的任何非选择性列(假定该列的不同值数量有限制),应考虑使用位映射索引。如果不断地向列的值清单中添加新值,就必须经常调整位图。
在一个VLDB中,位映射索引使用在事务表及聚集表的列上时将产生最大的效果。代码表采用完全索引是较好的选择;较大的表能够从位映射索引中受益。对于同一个表,可以既创建位映射索引又创建常规(B*tree)索引。Oracle在查询进程中将对所需的索引进行动态转换。
6.4.5. 海量数据VLDB的管理
在VLDB中如何管理庞大的数据是一个至关重要的问题,它既影响到数据的安全性也涉及到数据库的性能,oracle在采用如下手段进行管理。
1、数据移动技术
Oracle采用了大量改进数据移动操作性能的特征。如本章前面几节所述,这些数据移动特征包括:
, 供批量删除用的truncate命令。
, 供插入用的APPEND提示和SQL*LoaderDirectPath装载。
, 用于将表和索引分成更小数据集的分区。
, nologging操作。
在Oracle中,可以使用另一个新特征—可迁移表空间—来改善数据移动操作的性能。可迁移表空间应改善数据库之间大量移动数据的操作性能。可以移动数据和索引,但不能移动位映射索引或含有收集程序的表(嵌套表和可变数组)。
若要移动表空间,必须生成一个表空间集,将这个表空间集移动到新数据库,并把它插入新数据库。下节,将介绍要执行的步骤及实现提示。数据库应在同一个操作系统上,具有相同版本的Oracle、数据库块大小和字符集。
2、数据备份
Oracle中引入的恢复管理器(RMAN)很有可能开创了一个全新的方法用于执行VLDB数据库的备份。它提供了从命令行与GUI用户界面执行的所有热备份和冷备份功能。恢复管理器同磁盘和磁带备份介质一同工作并提供了如下优于
56
传统的基于操作系统的物理备份方法的特点:
, 热备份不会导致与传统的BEGIN/END备份方法有关的重做日志产生
率。
, 作为备份过程的一个集成部分,检查数据库块是否残缺不全。这可以减
少对整个数据库频繁使用ANALYZETABLEVALIDATESTRUCTURE语
句的要求。
, 支持增量物理备份。
, 支持多线程备份(仅限版)。
, 恢复管理器提供一个集成的分类系统,该分类系统在鉴别所需的备份磁
带时能够把混乱减到最小。
RMAN的一些新特性可加速数据库的恢复时间。
1、快速启动错误修复
快速启动错误修复特性允许Oracle服务器快速地从系统错误中修复并且将对用户冲击降低到最小。它由多个方面构成。
2、快速启动检查点
这一特性通过允许DBA指定在向前滚动期间需要执行的I,O操作数上限来控制向前滚动所需的时间。使用这一特性在正常处理期间会引起检查点频繁发生并且通知DBWR对附加的缓冲区进行写操作。这限制了在任一给定时间缓冲Cache中的脏缓冲区的个数。在故障期间,脏缓冲区数目很少,这样就加速了恢复期间的向前回滚操作,使数据库可以快速地打开。DBA通过动态性能视可以得到收集的统计数字,这样他就可以在常规的运行时性能和修复速度之间做出明智平衡。
一个新的动态参数FAST_START_IO_TARGET被引入以控制快速启动检查点。在修复期间DBWR应当处理的缓冲区的个数等于该参数值。FAST_START_IO_TARGET允许对整个修复时间进行很大程度的控制,这是因为修复时间直接与所要求的I,O操作数相关。将FAST_START_IO_TAGET设置为较小数值会提高修复时间,但是在正常处理期间会有较高的开销。
3、快速启动按需回滚
57
快速启动按需回滚或者非阻塞回滚延缓了恢复期间的回滚阶段。它允许放弃的事务按需修复。在早期的Oracle版本中,用户是处于阻塞状态直到整个放弃的事务处理完毕后。因此不可能访问包含在这些事务中的任何对象直到未提交的改变被完全回滚后。当事务很大时,这就会令人沮丧。有了快速启动按需回滚特性后,用户会话立刻修复那些新事务需要的块,那些死事务在后台恢复,这样会话可以继续进行。
4、快速启动并行回滚
快速启动并行回滚允许事务以并行方式执行修复。早期版本的事务修复在向前滚动阶段利用了并行机制,但是随后进行的回滚是串行进行的。这就会对故障事务相关数据库的一部分的可用性造成冲击。
并行回滚提高了整个修复吞吐量。只有当时机成熟时,SMON才会初始化快速启动并行回滚(也即串行回滚的代价远大于并行回滚的代价)。
SMON基于初始化参数FAST_START_PARALLEL_ROLLBACK(也即以前的PARALLEL_PRANSACTION_RECOVERY)值做出相应决策。这一参数指明SMON将启动多少个从系统以执行并行修复。对这一特性的使用可以通过虚拟视v$fast_start_servers和v$fast_start_transactios监控。
6.4.6. 数据库配置与优化
以上从Oracle的本身功能上介绍了海量数据的优化和管理技术,以下从实用的角度总结数据库配置与优化的方法。
1、优化操作系统
为了获得最佳的服务器性能,对操作系统的优化是很必要的,。因为操作系统性能问题通常会涉及到进程管理、内存管理、调度等,所以需要确保有足够的I/O带宽、CPU的处理能力、交换空间来尽可能的降低系统时间。
2、磁盘布局优化和配置
磁盘布局的目标是:磁盘性能是不能阻碍实现数据库性能,数据库磁盘必须专用于数据库文件,否则非数据库将会影响到该数据库,且这种影响是不可预测的。
58
3、创建数据库初始化参数的选择
管理数据库的第一阶段就是初始化数据库的创建,尽管可以在数据库创建好以后再来调整性能,但是有些参数是不能修改的或很难修改,比如:Db_block_size、Db_name、Db_domain、Compatible、Nls_language、Nls_characterset、Nls_nchar_characterset。
, Db_block_size
该参数决定Oracle数据库块的大小,一般可以选择的范围是2K、4K、8K、16K、32K,使用下一个较大值数据库块大小的效果一般可以集中查询中性能提高50%。但是按常规来说对于一般服务器不提倡把这个值设的很大,小型机除外,因为这样一来数据库块中将会有更多的行,在数据库维护期间发生块级竞争的可能性比较大,避免这种竞争的办法是在表级和索引级增大Freelists、maxtrans和initrans的设置值,通常Freelists设置为大于4会带来更多的好处。
, Db_name
该参数指定一个数据库标识符,一般在Create Database中指定的名称,改参数是可选的(在Oracle9i实时应用集群时是必选的,多个实例有相同的参数值),但是建议在Create Database之前设置它,如果不指定则要出现在Startup或Alter Database mount命令中。
, Db_domain
该参数指定全局数据库名的扩展部分,在Oracle9i实时应用集群时是必选的,多个实例有相同的参数值。
, Compatible
该参数指定Oracle服务器维护版本的兼容性,保证与早期的版本向下兼容的时候允许用户使用新的版本,在Oracle9i实时应用集群时是必选的,多个实例有相同的参数值。
, Nls_language和Nls_characterset及Nls_nchar_characterset
这三个参数是数据库的字符集参数,在数据库创建完成后一般也不能改变或很难改变,所以在创建数据库的时候要先设置好。
4、设置和管理内存
59
Oracle使用共享内存来管理其内存和文件结构,Oracle常使用的内存结构如下:
, 系统全局区(System Global Area,SGA)
SGA随着不同的环境而不同,没有一种普通的最佳方案,在设置它直前要先考虑以下的几个方面:物理内存多大;操作系统是那种及占多大的内存,数据库系统是文件系统还是裸设备;数据库运行的模式。
SGA包括:Fixed size、Variable size、Database Buffers、Redo Buffers。SGA占有物理内存的比例没有严格的规定,只能遵从一般的规则:SGA占据物理内存的40%--60%左右。如果通过直观的公式化来表达则为:OS使用内存+SGA+并发进程数*(Sort_area_size+Hash_area_size+2M)<0.7RAM,这个公式也只是参考,实际情况可以自由发挥。
初始化参数文件中的一些参数对SGA的大小有决定性的影响。参数Db_block_Buffers(SGA中存储区高速缓存的缓冲区数目),参数Shared_pool_size
(分配给共享SQL区的字节数),是SGA大小的主要影响者。
, Database Buffers 参数
是SGA大小和数据库性能的最重要的决定因素。该值较高,可以提高系统的命中率,减少I/O。每个缓冲区的大小等于参数Db_block_size的大小。Oracle数据库块以字节表示大小。Oracle SGA区共享池部分由库高速缓存、字典高速缓存及其他一些用户和服务器会话信息组成,共享池是最大的消耗成分。调整SGA区各个结构的大小,可以极大地提高系统的性能。
, 数据块缓冲缓存区(Data block buffers cache)
Data buffers在8i中是Db_block_buffers*Db_block_size,9i中用Db_cache_size来代替这个参数。在内存的配置中把别的参数设置完成后,应该把能给的都给Data buffers。Oracle 在运行期间向数据库高速缓存读写数据,高速缓存命中表示信息已在内存中,高速缓存失败意味着Oracle必需进行磁盘I/O。保持高速缓存失败率最小的关键是确保高速缓存的大小。Oracle中初始化参数Db_block_buffers控制数据库缓冲区高速缓存的大小。可通过查询V$sysstat命中率,以确定是否应当增加Db_block_buffers的值。
60
SELECT name,value FROM V$sysstat
WHERE name in (’dbblock gets’,’consistent gets’,’physical reads’);
通过查询结果命中率=1-physical reads/(dbblock gets+consistent gets) 如果命中率<0.6,0.7,则应增大Db_block_buffers。
, 字典缓存区(Dictionary CACHE)
数据字典缓存区的大小由数据库内部管理,大小由参数Shared_pool_size来设置。数据字典高速缓存包括了有关数据库的结构、用户、实体信息等。数据字典的命中率对系统有很大的影响。命中率的计算中,getmisses 表示失败次数,gets表示成功次数。查询V$ROWCACHE表:
SELECT (1-(SUM(getmisses)/(SUM(gets)+SUM(getmisses))))*100
FROM V$rowcache;
如果该值>90%,说明命中率合适。否则,应增大共享池的大小。
重做日志缓冲区(Read log buffer),下面将有陈述,在此就不做说明。
, SQL共享池(Shared pool size)
该共享池包括包括执行计划及针对数据库执行SQL语句的语法分析用的,在第二次运行相同的SQL语句时可用SQL中的语法分析来加快执行速度。如果它太小,语句会连续不断地再装入到库缓存区,从而影响性能。可以通过Alter system命令来修改此参数,9I以后的版本可以动态地修改其大小。
, 大池(Large pool size)
是一个可选的内存区。如果选择可对数据库象备份/恢复这些大的操作提高性能。如果不选择此参数,则系统会使用共享池。
, JAVA池(Java pool size)
由其名字而言可知,是为满足JAVA命令语法分析的需求。在UNIX系统中如果区组的大小为4MB,则默认大小应该为24M,如果区组大小为16MB,则默认大小为32M。如果数据库没有使用JAVA,则保持在10M—20M足够。
, 多缓冲区池(Multiple buffer pools)
可以使用多缓冲区池把大数据集与应用的剩余部分分开,以减少它们争夺缓
61
存区内相同资源的可能性,创建时需要在初始化参数中设定其大小。
, 程序全局区(Program global area,PGA)
是Oracle的一个私有的内存区,9i以后的版本中,如果Workarea_size_policy=auto,则所有的会话共用一块内存,该内存在参数Pga_aggregate_target设置,它的一个好的初始设置是:对于一个OLTP系统Pga_aggregate_target=(totalL_mem*80%)*20%;对于一个DSS系统Pga_aggregate_target=(total_mem*80%)*50%。这里的total_mem是物理内存。在调整Pga_aggregate_target参数时,下面的几个动态视图会有帮助的:V$sysstat和V$sesstat;V$sql_workarea_active;V$pgastat;V$sql_workarea; V$process。
5、设置和管理CPU
在设置和安装数据库的过程中,基本不用对CPU做什么配置的,系统会自动默认的,但是在管理过程中可以利用操作系统监控工具来监控CPU的状况。例如在UNIX系统中,可以运行sar–u的工具来检查整个系统使用CPU的水平。其统计信息包括:用户时间、系统时间、空闲时间、I/O等待时间。在正常工作负载的情况下,如果空闲时间和I/O等待时间接近于0或少于5%,那就表示CPU的使用存在问题。
对于Windows系统可以通过性能监视器(Performance monitor)来检查CPU的使用状况可以提供以下信息:处理器时间、用户时间、特权时间、中断时间、DPC时间。
如果CPU的使用存在问题,则可以通过以下的方式来解决:优化系统和数据库;增加硬件的能力;对CPU资源分配进行划分优先级,Oracle数据库资源管理器(Database Resource Manager)负责在用户和应用程序之间分配和管理CPU资源。
6、设置和管理表空间
数据库文件之间的I/O竞争是数据库之大忌,所以对数据库规划之前要先对数据文件的I/O进行初步的评估。
通常情况下,应用的产品数据库表所在的表空间会很活跃,索引表空间和数据字典之类的表空间也很活跃的,对于事物比较频繁的应用中,重做表空间也很
62
活跃的,所以对不同类型的数据库其数据文件的I/O竞争也会略有不同的。
关于设置和管理表空间基本上还是遵从以下的原则比较好:
, 应用的表和索引通常应该被分配或分区到多个表空间中,以降低单个数
据文件的I/O,最好把每一种功能相同的区域对象建立单独的表空间;
, 没有理由把除数据字典表和系统回退段外的其他东西放到系统表空间
中,要把能移出系统表空间的对象都移出;
, 索引段不应该和相关表放在同一表空间中,因为他们在数据管理和查询
时会产生很多的并发I/O;临时表空间是用以存储大量的排序,所以其
它的应用对象是不能放在临时表空间。
数据库和表空间可以是一对多的关系,表空间和数据文件也可以是一对多的关系,数据文件和数据对象也可以是一对多的关系。当创建一个数据对象(如表或索引)时,可以通过默认值或特殊命令将其赋予一个表空间,这样就会在该表空间中创建一个段(Segment)来存储与该对象有关的数据。一个段由一些称作区间(Extent,一组连续的Oracle块)的区段组成,一但现有的区段不能存储数据时,这个段就要获得另一个区间来支持将数据插入到对象中。因此这个段所使用的空间由它的参数决定的,这些参数可以在创建时指定,也可以在以后更改。如在Create table,Create index,Create cluster,Create rollback segment命令中没有指定存储参数,则数据库会默认它存储所在的表空间的参数,这些参数有initial,next,pctincrease,maxextents,minextents等。在创建后不能修改initial和minextents值,每个表空间的存储参数默认值可以在Dba_tablespaces视图中查询出来。
磁盘I/O是系统性能的瓶颈,解决好磁盘I/O,可明显提高性能。通过查询V$filestat可以知道每个物理文件的使用频率(phyrds表示每个数据文件读的次数,phywrts表示每个数据文件写的次数)
SELECT name,phyrds,phywrts FROM V$datafile df,V$filestat fs
WHERE df.file# =fs.file#;
对于使用频率较高的物理文件,可以采用以下策略: 将I/O尽可能平均分配在尽可能多的磁盘上;为表和索引建立不同的表空间;将数据文件与重做日志
63
文件分离在不同的磁盘上;减少不经Oracle server的磁盘I/O。
7、设置和管理回滚段
回滚段一般可以处理任意大小的事物,所以也就需要大小不同的回滚段。回滚段的大小是通过创建回滚段时指定存储子句来设置,但一般会遵从下面原则:
(1)OLTP事物特征有许多并发的事物,每个可能只修改少量的数据,可以建立10KB到20KB大小的回滚段,每个有2到4的范围;对于时间很长的查询为了维护读一致性有大量的回滚信息,所以需要较大的回滚段,建立回滚段的大小最好为最大表的10%左右(大多数查询只影响到表约10%的数据量)。设置回滚段的大小可以通过Create rollback segment和Alter rollback segment语句来实现。一般情况下,initial=next ,设置Optimal参数来节约空间的使用 , 不要设置maxextents为unlimited,回滚段应创建在一个特定的回滚段表空间内 。
(2)回滚段的目标容量可以用存储参数Optimal来定义,它指定回滚段要缩小到的尺寸。如果发现回滚段由于Optimal的缘故持续地收缩,那么很可能是回滚段设置不恰当,这种可以通过动态性视图V$rollstat来确定是否有问题。
8、设置和管理联机重做日志
重做日志的大小也能影响性能,因为数据库的写入和归档取决于重做日志的大小,通常情况下,更大的重做日志文件可以提供好一些的性能,小的能增加检查点的活动和降低频率。
不可能为一个重做日志文件提供特定大小的建议,重做日志文件在几百兆字节到几GB字节都被认为是合理的,根据系统产生的联机重做数量决定日志文件的大小,一般情况下应保持在约20分钟交换日志文件一次。
如果发生重做日志缓冲区竞争,对数据库的性能影响也将是很大的。为了减少重做日志缓冲区竞争,我们可以通过查询V$sysstat表判定redo log 文件缓冲区是否足够。
SELECT name,value FROM V$sysstat WHERE name=‘redo log space
request’;
此处value的值应接近于0,否则,应增大初始化参数文件的Log_buffers的值
64
重做日志文件被创建后大小不能被改变,但是可以增加新的、更大的文件,并且原来的文件能被删除。
9、设置和管理归档重做日志
当Oracle以archivelog模式运行时,数据库在每个联机重做日志文件写满后,对它进行拷贝,通常是写入磁盘,也可以写入别的设备,但这需要人为的干预的。arch后台执行归档功能,如果有大量频繁的事物的时候,会产生重做日志文件磁盘方面的竞争,避免这种竞争的方式是将联机重做日志文件分布到多个磁盘上。为了提高归档的性能,可以创建具有多个成员的联机重做日志文件组,但是必须考虑到每个设备的I/O。
rbs、data、temp、indexes表空间等存储归档重做日志文件不应与system、
在同一个设备中,更不能与任何的联机重做日志文件存储在同一个设备中,以免发生磁盘的竞争。
归档重做日志文件备份之后是可以删除或移走的,否则会占据比较大的空间影响硬盘使用和降低系统的性能。
10、段的碎片整理
当生成一个数据库对象时(一个表或一个索引),通过用户缺省值或指定值来为它指定表空间。一个在表空间中所生成的段,用于存储对象的相关数据。在段被关闭、收缩、截断之前,段所分配的空间将不被释放。
一个段是由范围组成,而范围是由相邻的 Oracle 块组成。一旦存在的范围不能再存储新的数据,那这个段就会去获得新的范围,且并不要求这些范围是彼此相邻的。这样的扩展会一直继续下去,直到表空间中的数据文件不能提供更多的自由空间,或者范围数量已达到极限。
因此,一个碎片太多的数据段,不仅会影响运行,也会引发表空间中的空间管理问题。所以,每个数据段只含有一个范围是十分有益的。借助监控系统,可以通过检查 DBA_SEGMENTS 数据字典视图来了解哪些数据库对象含有 10 个或更多范围的段,确定其数据段碎片。
若一个段的碎片过多,可用两种方法解决这个问题:
, 用正确的存储参数建立一个新表,将旧表中的数据插入到新表中,再删
65
除旧表;
, 利用 Export/Import 工具。
11、自由范围的碎片整理
表空间中的一个自由范围是表空间中相连自由(空间)块的集合。当一个段关闭时,它的范围将被释放,并被标记为自由范围。然而,这些自由范围再也不能与相邻的自由范围合并,它们之间的界线始终存在。但是当表空间的缺省值 pctincrease 设置不为 0 时, SMON 后台进会定期的将这些相邻的自由范围合并。若 pctincrease 设置为 0 ,那相邻自由范围不会被数据库自动合并。但可以使用 altertable 命令 coalesce 选项,来强迫进行相邻自由范围的合并。
不进行自由范围合并,在日后的空间请求中,会影响到表空间中的空间分配。当需要一个足够大的范围时,数据库并不会合并相邻的自由范围,除非没有其他选择。这样,当表空间中前面较小自由范围已被相关使用时,将使用表空间中后面部分最大的一个自由范围。结果,会因为它们没有足够多的使用空间,从而导致表空间中速度上的矛盾。由于这样的进程出现,使数据库的空间分配距理想越来越远。自由空间碎片常会出现在那些经常关闭又重新生成的数据库表和索引中。
6.5.从软件解决系统性能问题
6.5.1. 软件设计基于构件,尽量简单化
应用系统的设计应利用基于构件的开发理念,增加程序代码的可重用性。此外,程序应使用简单的逻辑和算法来获取结果,避免复杂以及深层次的对象调用,提高运行效率,以获得快速的相应速度。
6.5.2. 代码编写质量直接关系到系统的性能
编程的质量有经验的积累也有个人的技巧,在一个用软件整个开发过程的指导思想是:“按照规范来进行开发,而不是按照个人习惯,应用服务器等其他因素来进行开发”。
66
根据我们的经验,在多层体系结构的业务应用系统开发中,关键是数据库的操作编程以及涉及到中间件的编程将对系统性能影响很大。因此我们在系统设计开发过程中增加系统性能及压力测试,根据客户现场实际参保情况,历史数据情况及未来5-10数据变化情况,客户端连接数的情况,在系统正式使用前进行性能和压力模拟测试。保证为客户提供高可用的系统。
6.5.3. 软件运行性能监控
除了应用软件本身的缺陷外,运行过程中业务模型的自然变化或人为更改,系统环境的改变,以及应用软件执行过程中内在的变化特性,使得应用性能问题在生产环境仍然普遍发生。根据应用软件的业务特点,结合技术构架的实现方案,在应用软件中实施与部署性能监控,分析组件,发现应用软件中存在的性能问题,借助于性能监控,分析组件可以快速定位与解决性能问题,但并不能避免应用性能问题不发生。
6.5.4. 软件数据库SQL的编程注意事项
1、确定一个SQL语句的书写规范,以提高SQL语句在Oracle的高速缓存中的命中概率;
2、降低单个SQL语句的复杂度,保证SQL的执行效率。对于复杂SQL语句,采用转换成PL/SQL块或其他方式进行处理;
3、合理设计应用程序,尽量降低所需要执行的SQL语句数量,降低与数据库的大量交互;
4、采用绑定变量的方式,提高SQL执行效率;
5、尽量采取数据库中本身具有的功能来实现相关处理,而不是通过自己单独开发代码来处理;
6、对应用程序中的所有SQL语句进行整体的规划管理,以尽可能的发现存在缺陷的SQL语句;
7、对于每一个事务,都尽量降低事务的大小,以提高效率;
8、合理使用SQL语句的hints,以提高SQL语句执行效率;
67
9、根据现场实际情况,定期对主要SQL语句进行优化。
10、合理使用索引,丰富查询条件提供SQL语句的命中率。 6.5.5. 中间件编程注意事项
1、在系统框架完整、类任务明确、单一的前提下尽量减少框架中类的调用层次
2、使用DAO代替EntityBean访问数据库
3、业务层的EJB入口采用Stateless SessionBean,避免使用statefull session
bean
4、尽量避免EJB的嵌套调用
5、在系统启动初始化过程中缓存EJB的home接口
6、适当地使用数据库的存储过程来提高效率
7、一些简单读取的请求使用FastLaneReader模式
8、在WEB及APP层做集群
9、利用应用服务器提供的connection pool连接数据库
68
7. 项目实施方案
7.1.项目实施组织机构
7.1.1. 项目实施组织体系
项目经理
软实质
件施量技
开术维管
发小护理
小小小组
组组组
图7-1项目实施组织体系 7.1.2. 项目组织各角色职责
7.1.2.1. 项目经理
项目经理是整个项目组织中的核心角色,负责整个项目的实施。项目经理将
负责所有的管理工作,以及其它相关的工作,如交付物、财务、合约等。他对系
69
统将承担最终的职责。项目经理将参与日常的系统实施管理,监控项目的进度,与软件项目经理一起工作以确保开发可以跟踪和控制。项目经理负责向领导小组汇报开发进度和开发相关的问题。
项目经理一方面作为我公司的统一接口,协调用户,另一方面协调和管理公司内容各类小组,减轻用户在项目执行工程中发生的对公司的协调。无论何时,项目经理都将得到项目领导小组在技术和处理实施问题上的强力支持。
由于该项目建设涉及方面较多,时间紧,工作量大,因此为了更好地完成本项目的实施工作,项目经理负有如下职责:
1、作为我公司与用户之间的高级代表,与用户直接接触,第一时间获取用户信息、意见和需求,并协调我公司内部各方面关系,对发现的问题做出及时的响应;
2、作为整个项目实施计划的执行负责人和监督者,负责协调、监督我公司各部门资源,保证工程进度,保证工程质量达到项目要求;
3、作为整个项目的项目经理,在现场担任现场实施的总负责人,协调人员安排、问题协商与解决等工作。
4、制定工程质量方针、目标和标准,控制项目质量环节。在项目推进的关键部位上设置质量检查环节和改进通道,通过建立岗位工作规范,强化质量意识和服务意识,确保项目质量、工期、成本和客户满意度都达到预期的目标。
5、组织召开项目的周会、例会和技术碰头会等工作,参与各项文档组织等。 7.1.2.2. 软件开发小组
, 软件设计:负责软件的概要设计和详细设计;
, 软件开发:负责软件的开发;
, 软件测试组:负责软件的测试,以保证软件产品的质量符合设计要求,
确保软件产品的顺利释放。
70
7.1.2.3. 技术小组
, 系统架构师:最终确认和评估系统需求,给出开发规范,搭建系统实现
的核心构架,并澄清技术细节、扫清主要难点的技术人员。
, 咨询:针对用户的需求,为客户量身制造合理的解决方案。 7.1.2.4. 实施维护小组
在项目经理的领导下,负责系统实施和维护工作。下设:
, 实施:负责硬件规划、硬件采购、硬件安装及软件部署、系统培训和配
合用户测试等工作;
, 维护:负责系统上线后的售后服务;
7.1.2.5. 质量管理小组
, 文档及配置管理
文档及配置管理组负责为项目开发团队提供全面的配置管理基础设施和环境,确保配置有效支持项目的开发,所有项目成员的工件(源代码和文档等)都进行了版本管理,还必须确保配置环境有利于进行产品复审、更改和缺陷跟踪等活动。负责评审软件开发计划,软件活动和工作产品,制定SCM计划,软件基准库的构造和管理,系统地控制基线的修改。
, 质量管理
对项目建设过程的质量进行管理跟踪。
7.2.人员配置策略*********************** 7.3.项目实施计划*********************** 7.3.1. 实施进度目标******************
2012年9 月初完成需求调研,9月中旬完成卡制作发放使用的主体功能开
71
发,12月底完成应用系统实施,再根据进度安排完成软件附加功能的开发实施。 7.3.2. 总体进度与关键里程碑***************
1、2012年9月份初完成需求调研工作。
2、2012年11月中旬完成卡制作发放功能的研发工作。
5、2012年12月底完成应用实施工作。
7.3.3. 进度安排*******************
2012年8月31日2012年12月31日需求调研实施完成
2012年9月1日2012年10月1日2012年11月1日2012年12月1日2012年8月1日2012年12月31日
应用开发完成2012年11月17日
图 7-2 进度安排
7.4.项目文档提交件管理
7.4.1. 项目交付物
根据项目需求和计划确定对项目交付物的定义,由此确定产生这些交付物所需的项目活动和他们的次序。用户对提交的项目交付物要进行评审,每个文档要符合一定的格式要求、内容要求,并针对开发的系统编写。
项目交付物分成三个部分:管理的、技术的和质量的。管理交付物包括所有的计划、报告、对计划/报告的接受确认。质量交付物包括所有的质量标准定义、交付物的检查及检查的文档记录。技术交付物根据工作范围及项目的技术活动来定义。
序号 工作阶段 各阶段提交成果
1 前期阶段 项目开发计划和方案
2 需求分析 软件需求分析说明书
72
概要设计说明书、详细设计说明书、软件接口规范、3 应用系统设计
信息交换标准
4 软件测试 系统测试报告、用户操作手册、软件安装维护手册 5 系统验收 项目总结报告及相应源码
6 培训 培训计划、培训材料
7 其他 项目工作月报、周报
7.4.2. 递交成果的签署
1. 签署的目的
签署指的是评审人在验收文档上签字,表明评审人已对递交的成果进行了评阅,并认为递交的成果满足要求,同时成果递交者已解决评审人对递交成果提出的意见。
2. 评审和签署程序
我公司提出了以下评审和签署程序
, 在评审过程中,评审人将完成以下各项程序:
, 检查递交的成果是否满足要求
, 在意见表中填写评审意见
, 在评审之后,评审人将意见表交给项目经理。如果评审人对递交的成果
提出重要意见或需求,需要对递交的成果进行修改。递交的成果修改之
后,评审人将重新进行评审。评审人将对递交的成果进行完整的评审,
并在两个评审循环中完成评审。如果安排的评审周期结束,将不再重复
这个过程。
, 在评审周期内任何时间,如果评审人认为递交的成果已经满足所有需
求,并提出了评审意见,评审人将通知用户方项目协调人。在这种情况
下,用户方项目协调人将签署递交的成果。
, 如果在评审周期结束后,递交的成果仍然不能满足规定的需求或不能解
73
决评审人提出的意见,评审人将把这种情况记录在意见表中,并将意见
表交给项目协调人。评审人将认为递交的成果不可接受。
, 接收/拒绝表将由项目协调人递交给项目经理。
7.4.3. 递交成果的拒绝
如果评审人没有依据评审准则,对递交的成果进行评审或没有给出任何特殊的或客观的理由,评审人就不能拒绝递交的成果。
如果递交的成果已经签署,就不能做任何修改,项目协调人则将接受/拒绝表归档。如果有任何问题,则由业主方项目协调人与项目经理协商解决。
如果发现由于递交的成果没有满足质量标准要求,或在评审周期结束之日所有作者没有解决评审人提出的意见而被拒绝,拒绝的递交成果必须退回给成果递交者进行修改。如果用户方项目协调人与项目经理无法协商解决问题,将上报到相关部门解决。
7.5.保障措施
1、我公司通过了ISO 9001:2000的质量体系认证,公司形成了完整规范的质量管理体系,并应用到所有项目的实施过程中。
2、为本项目配置大量专业的技术人员和管理人员,优秀的团队是保证项目质量的一面旗帜。
3、针对本项目设计的培训课程新颖独特,强化对领导层、管理层和业务人员的培训,提高整体素质。
74
8. 项目测试及验收方案
8.1.系统测试方案
8.1.1. 测试方法概述
基于用户所关注的项目建设质量问题,根据遂宁市社会保障卡项目的具体要求、结合我公司在实施ISO9000、CMM过程中积累的测试实践,对本项目所采购的相关系统功能、性能、可靠性、安全性等方面的测试,力求在测试过程中,发现项目中存在的问题,为技术人员提供系统完善的依据,以保证系统功能、安全性、可靠性及并发数量、处理时间等性能指标能满足用户实际业务需求,最终向用户交付出实用、可靠的高质量的工程。
通过标准:所有需求设计功能全部正确实现,系统安全性、稳定性、性能等指标满足需求。
8.1.2. 测试任务理解分析及应对策略
本项目系统测试需要考虑综合需求、实施以及系统性能、安全等等,所以本项目测试难度高,任务重,本项目的测试任务包括如下内容:
, 社会保障卡系统开发过程中的单元测试和集成测试等测试内容
, 社会保障卡系统开发完成后,需要对系统进行压力测试、性能测试、安
全测试、UI测试、可扩展性测试等非功能性测试
, 模拟实际情况进行虚拟部署实施测试,测试系统的适应性、灵活性等方
面测试内容
本项目系统测试任务的重要性、艰巨性,系统测试效果将直接决定产品的质量和今后产品实际应用与推广,为保证系统高起点、高可靠性和高可用性,保证本项目的社会保障卡系统在正式运行时功能正确、性能稳定、具备良好的易用性,满足用户需求和相关设计要求,针对本项目的测试工作制定如下策略:
, 组建最专业的测试队伍
75
, 坚持统一规划、审慎论证、精心设计、分步执行的测试原则
, 充分利用多年来总结的一套完整地测试方法,从不同的角度和维度,对
软件系统的各个方面实施测试和评价工作
, 充分利用大项目的测试经验,利用自动化测试管理工具对测试过程进行
全程管理,使缺陷的发现、跟踪、关闭全部实现自动化、透明化、科学
化,严格控制项目测试过程中的每一个环节
, 本项目测试过程中所要使用的测试工具,详见本章“测试工具”相关内
容
, 本项目测试过程文档控制详见本章“测试过程文档控制” 8.1.3. 单元模块测试与联调测试设计
本项目测试不仅要对软件进行单元模块测试、联调测试、性能测试等测试,还需对软件进行模拟实施进行统一系统测试,在本项目开发阶段测试工作做如下安排:
, 开发周期阶段测试
项目的测试组将在本项目约定的交付周期不同阶段,对不同类型的中间系统或最终系统进行测试。这些阶段的递进是于项目开发生命周期模型相吻合的,亦即从单元测试,到集成测试,最后到系统测试不断向前发展的,最后还将与相关负责人一起进行项目的验收测试。
, 单元测试
单元测试在迭代的早期实施,主要侧重于软件系统的最小可测试元素的符合性。单元测试通常应用于实施模型中的构件,核实是否已覆盖控制流和数据流,以及构件是否可以按照预期工作。这些期望值建立在构件参与执行用例的方式的基础上,实施员在单元的开发期间执行单元测试。
, 集成测试
集成测试(也叫组装测试,联合测试)是单元测试的逻辑扩展。它的最简单的形式是:两个已经测试过的单元组合成一个组件,并且测试它们之间的接口。从这一层意义上讲,组件是指多个单元的集成聚合。在现实方案中,许多单元组
76
合成组件,而这些组件又聚合成程序的更大部分。方法是测试片段的组合,并最终扩展进程,将您的模块与其他组的模块一起测试。最后,将构成进程的所有模块一起测试。此外,如果程序由多个进程组成,应该成对测试它们,而不是同时测试所有进程。
, 系统测试
当社会保障卡系统作为整体运行,即可进行系统测试。这种情况下的目标是系统的整个实施模型。通常在应用集成测试结束后,进行系统测试。依据《系统需求分析报告》、《系统设计报告》,采用黑盒测试的方法、模拟实际运行环境进行功能、性能、安全性、可用性、数据转换、压力等方面的测试。
, 联调测试
本项目系统除将做统一应用模拟测试,模拟实际情况,模拟实施部署,测试统一系统对个性化业务的适应性。
, 软件系统质量测试
质量达标不是简单地“满足需求”或生产出满足用户需要或期望的软件系统。更确切地说,质量还包含确定证明质量达标所使用的评测方法和标准,以及如何实施流程,以确保由此流程生产的软件系统已达到预期的质量水平(而且能够管理该流程并重复使用)。项目将从以下软件系统质量的维度进行测试:
按照分层的原则,界面的层次上不应该拥有业务逻辑,界面层负责的事情是收集用户的动作,将用户的动作请求委托给后端的业务层,并对动作进行响应。所以,和业务相关的逻辑已经被剥离到了业务层了。它的自动化测试属于业务层。同时,我们还发现,在测试的推动下,软件的结构变得更加的合理。
其次,虽然业务逻辑大量的迁移出界面层,但是界面层中还有状态,还有控制逻辑。这些因素都是和界面的控制的表现息息相关的。既然有逻辑,就需要测试。根据MVC的思路,界面层中包含了模型、视图和控制器。模型是对业务层数据的封装,在J2EE的应用中,可能是普通的JavaBean,也可能是离线的数据封装,或是简单的数据集合。视图负责表现模型,而控制器的职责则比较多,它需要负责处理和检查请求参数,负责调用业务对象并传递请求中所包含的数据,负责创建模型,负责生成视图并把模型传递给它。
77
所以,在一个真正的MVC界面设计中,测试的重点在于控制器。模型的测试是很容易的,大部分的模型仅仅包含了数据,所以甚至都不需要测试。一个完美的视图,它应该没有包含任何的逻辑,仅仅只是将模型以某种方式表现出来而已。一个设计优秀的视图,可以很容易的进行替换,而不会造成任何的影响。例如,一个JSP视图可以用一个XSLT视图进行替换。所以,结构合理的视图也是不需要测试的(但对页面要素的检查是必要的)。注意,这里的讨论也同样表明,测试驱动设计向合理的方向发展。
, 安全性测试
安全性测试的目的是检验系统中的安全保障措施、保密措施是否发挥作用,系统是否存在安全漏洞。在开展测试时,项目将充分了解软件系统应用领域,以及软件系统本身对安全性的要求灵活制定安全性测试策略。安全可靠性测试要考察以下几方面:
1、用户权限限制
2、输入数据有效性检查
3、数据传输的安全。
一般情况下,安全防护系统采用防火墙、入侵检测、漏洞扫描、安全审计、病毒防治、Web信息防篡改、物理安全等技术保证社会保障卡的安全。针对不同的安全技术,测试要点也有所不同:
防火墙:是否支持交换和路由两种工作模式;是否支持对HTTP、FTP、SMTP等服务类型的访问控制;是否考虑到防火墙的冗余设计;是否支持对日志的统计分析功能,同时,日志是否可以存储在本地和网络数据库上;对防火墙本身或受保护网段的非法攻击系统,是否提供多种告警方式以及多种级别的告警。
病毒防治:能否支持多种平台的病毒防范;能否支持对服务器的病毒防治;能否支持对电子邮件附件的病毒防治;能否提供对病毒特征信息和检测引擎的定期在线更新服务;防病毒范围是否广泛,是否包括UNIX系列、Windows系列、Linux系列等操作系统。
系统的安全防护能力,而侦听技术则是在数据通信或数据交互过程中,对数据进行截取分析的方法。
78
, 可靠性测试
软件健壮性和可靠性(故障预防能力,如崩溃预防、内存合理分配和释放等能力)、有效的资源利用率和代码完整性以及结构(语言和语法的技术兼容性)测试。
, 功能测试
按照客户既定意图和需求,执行指定用例,完成客户对系统功能需求的能力测试。这部分测试主要包括:配置测试、功能测试、安装测试。安全测试、容量测试等方面的测试。
, 易用性测试
验证系统是否易被业务人员所接受。这部分主要测试:界面是否美观、友好、合乎常规操作习惯,用户手册、培训资料内容是否完整、与软件系统一致并易于阅读。
8.1.4. 性能测试设计
性能测试是通过自动化的测试工具模拟多种正常、峰值以及异常负载条件来对系统的各项性能指标进行测试。负载测试和压力测试都属于性能测试,两者可以结合进行。通过负载测试,确定在各种工作负载下系统的性能,目标是测试当负载逐渐增加时,系统各项性能指标的变化情况。压力测试是通过确定一个系统的瓶颈或者不能接收的性能点,来获得系统能提供的最大服务级别的测试。
性能测试在软件的质量保证中起着重要的作用,它包括的测试内容丰富多样。性能测试可以概括为三个方面:
, 应用在客户端性能的测试
, 应用在网络上性能的测试
, 应用在服务器端性能的测试。
通常情况下,三方面有效、合理的结合,可以达到对系统性能全面的分析和瓶颈的预测。
1、应用在客户端性能的测试
应用在客户端性能测试的目的是考察客户端应用的性能,测试的入口是客户
79
端。它主要包括并发性能测试、疲劳强度测试、大数据量测试和速度测试等,其中并发性能测试是重点。
并发性能测试的过程是一个负载测试和压力测试的过程,即逐渐增加负载,直到系统的瓶颈或者不能接收的性能点,通过综合分析交易执行指标和资源监控指标来确定系统并发性能的过程。负载测试(Load Testing)是确定在各种工作负载下系统的性能,目标是测试当负载逐渐增加时,系统组成部分的相应输出项,例如通过量、响应时间、CPU负载、内存使用等来决定系统的性能。负载测试是一个分析软件应用程序和支撑架构、模拟真实环境的使用,从而来确定能够接收的性能过程。压力测试(Stress Testing)是通过确定一个系统的瓶颈或者不能接收的性能点,来获得系统能提供的最大服务级别的测试。
并发性能测试的目的主要体现在三个方面:以真实的业务为依据,选择有代表性的、关键的业务操作设计测试案例,以评价系统的当前性能;当扩展应用程序的功能或者新的应用程序将要被部署时,负载测试会帮助确定系统是否还能够处理期望的用户负载,以预测系统的未来性能;通过模拟成百上千个用户,重复执行和运行测试,可以确认性能瓶颈并优化和调整应用,目的在于寻找到瓶颈问题。
2、并发性能测试的种类与指标
并发性能测试的种类取决于并发性能测试工具监控的对象,以LR自动化负载测试工具为例。软件针对各种测试目标提供了DB2、DCOM、ODBC、ORACLE、NETLoad、Corba、QARun、SAP、SQLServer、Sybase、Telnet、TUXEDO、UNIFACE、WinSock、WWW、Java Script等不同的监控对象,支持Windows和UNIX测试环境。
采用自动化负载测试工具执行的并发性能测试,基本遵循的测试过程有:测试需求与测试内容,测试案例制定,测试环境准备,测试脚本录制、编写与调试,脚本分配、回放配置与加载策略,测试执行跟踪,结果分析与定位问题所在,测试报告与测试评估。
并发性能测试监控的对象不同,测试的主要指标也不相同,主要的测试指标包括交易处理性能指标和UNIX资源监控。其中,交易处理性能指标包括交易结果、每分钟交易数、交易响应时间(Min:最小服务器响应时间;Mean:平均服
80
务器响应时间;Max:最大服务器响应时间;StdDev:事务处理服务器响应的偏差,值越大,偏差越大;Median:中值响应时间;90,:90,事务处理的服务器响应时间)、虚拟并发用户数。
3、疲劳强度与大数据量测试
疲劳测试是采用系统稳定运行情况下能够支持的最大并发用户数,持续执行一段时间业务,通过综合分析交易执行指标和资源监控指标来确定系统处理最大工作量强度性能的过程。
一般情况下以服务器能够正常稳定响应请求的最大并发用户数进行一定时间的疲劳测试,获取交易执行指标数据和系统资源监控数据。如出现错误导致测试不能成功执行,则及时调整测试指标,例如降低用户数、缩短测试周期等。还有一种情况的疲劳测试是对当前系统性能的评估,用系统正常业务情况下并发用户数为基础,进行一定时间的疲劳测试。
大数据量测试可以分为两种类型:针对某些系统存储、传输、统计、查询等业务进行大数据量的独立数据量测试;与压力性能测试、负载性能测试、疲劳性能测试相结合的综合数据量测试方案。大数据量测试的关键是测试数据的准备,可以依靠工具准备测试数据。
4、应用在网络上性能的测试
应用在网络上性能的测试重点是利用成熟先进的自动化技术进行网络应用性能监控、网络应用性能分析和网络预测。
网络应用性能分析的目的是准确展示网络带宽、延迟、负载和TCP端口的变化是如何影响用户的响应时间的。利用网络应用性能分析工具,能够发现应用的瓶颈,我们可知应用在网络上运行时在每个阶段发生的应用行为,在应用线程级分析应用的问题。可以解决多种问题:客户端是否对数据库服务器运行了不必要的请求,当服务器从客户端接受了一个查询,应用服务器是否花费了不可接受的时间联系数据库服务器,在投产前预测应用的响应时间;利用网络管理工具调整应用在广域网上的性能。
5、应用在服务器上性能的测试
对于应用在服务器上性能的测试,可以采用工具监控,也可以使用系统本身
81
的监控命令,例如Tuxedo中可以使用Top命令监控资源使用情况。实施测试的
目的是实现服务器设备、服务器操作系统、数据库系统、应用在服务器上性能的
全面监控。
UNIX资源监控指标和描述
, 平均负载 系统正常状态下,最后60秒同步进程的平均个数
, 冲突率 在以太网上监测到的每秒冲突数
, 进程/线程交换率 进程和线程之间每秒交换次数
, CPU利用率 CPU占用率(,)
, 磁盘交换率 磁盘交换速率
, 接收包错误率 接收以太网数据包时每秒错误数
, 包输入率 每秒输入的以太网数据包数目
, 中断速率 CPU每秒处理的中断数
, 输出包错误率 发送以太网数据包时每秒错误数
, 包输入率 每秒输出的以太网数据包数目
, 读入内存页速率 物理内存中每秒读入内存页的数目
, 写出内存页速率 每秒从物理内存中写到页文件中的内存页数
, 内存页交换速率 每秒写入内存页和从物理内存中读出页的个数
, 进程入交换率 交换区输入的进程数目
, 进程出交换率 交换区输出的进程数目
, 系统CPU利用率 系统的CPU占用率(,)
, 用户CPU利用率 用户模式下的CPU占用率(,)
, 磁盘阻塞 磁盘每秒阻塞的字节数
6、验证稳定性(resilience)可靠性(reliability)
在一个生产负荷下执行测试一定的时间是评估系统稳定性和可靠性是否满
足要求的唯一方法。
, 性能测试类型包括负载测试,强度测试,容量测试等
, 负载测试:负载测试是一种性能测试指数据在超负荷环境中运行,程序
82
是否能够承担。
, 强度测试: 强度测试是一种性能测试,他在系统资源特别低的情况下
软件系统运行情况。
, 容量测试:确定系统可处理同时在线的最大用户数 观察指标:
针对BS结构程序一般会关注的通用指标如下
Web服务器指标指标:
* Avg Rps: 平均每秒钟响应次数,总请求时间 / 秒数; * Avg time to last byte per terstion (mstes):平均每秒业务角本的
迭代次数;
* Successful Rounds:成功的请求;
* Failed Rounds :失败的请求;
* Successful Hits :成功的点击次数;
* Failed Hits :失败的点击次数;
* Hits Per Second :每秒点击次数;
* Successful Hits Per Second :每秒成功的点击次数; * Failed Hits Per Second :每秒失败的点击次数;
* Attempted Connections :尝试链接数;
CS结构程序,由于一般软件后台通常为数据库,所以我们更注重数据库的
测试指标:
* User 0 Connections :用户连接数,也就是数据库的连接数量; * Number of deadlocks:数据库死锁;
* Butter Cache hit :数据库Cache的命中情况
当然,在实际中还同步地察看多用户测试情况下的内存,CPU,系统资源调
用情况。这些指标其实是引申出来性能测试中的一种----竞争测试。 竞争测试是软件竞争使用各种资源(数据纪录,内存等)与其他相关系统对
资源的争夺能力。
83
, 可扩展性测试
系统的可扩展性,即可伸缩性可以从硬件和软件两个方面来理解:
1、硬件的可伸缩性,是否可以通过硬件设备的增加来支持更多的用户,比如通过增加cpu个数或者存储器空间大小等。
2、软件的可伸缩性,是否可以通过运行更多的实例或者采用分布式处理来支持更多的用户或更多的业务负荷。
一个可伸缩的系统必须具有随负荷增加响应时间也线性增加的特点。这样就可以通过线性的增加硬件设备、实例个数或者分布式处理点来处理更多的数据量。也就能更好的在不增加响应时间的前提下支持更多的用户。
可伸缩性测试具体的测试过程为:进行负载测试,记录不同负载下的平均响应时间,然后查看平均响应时间是否线性增加。如线性增加,说明系统具有可伸缩性,否则说明系统可伸缩性较差或者没有可扩展能力。
软件可扩展能力与软件架构和设计有着密切的关系,可扩展性测试仅能验证社会保障卡系统是否具体可扩展性、在某个具体范围内具有可扩展性。在Java EE应用中,软件的可扩展性是组件可伸缩性决定的。在准生产环境中检验每个组件来确定其事务(或者说容量)的限度是非常必要的。一旦有足够的应用功能来创建业务相关的事务,事务特征测试(transcation characterization testing)就被用来确定业务事务中的各个定量描述,包括消耗的带宽和后台 CPU 以及内存的占用率。资源测试(Resource testing)将这个概念扩展到多用户测试,从而确定应用程序和子系统或模块中全部的资源消耗。最后,配置测试(configuration testing)可以用来确定哪些硬件、操作系统、软件、网络、数据库或者其他配置上的变更可以优化性能。
, 可支持性测试
可支持性测试包括系统的可维护性、可扩展性、兼容性、是否易于安装及升级。
, 测试度量数据的统计、分析和评价
项目组对测试质量的统计、分析和评价方法是过程改善领域度量与分析领域的能力积累而形成的一套行之有效的方法论。
84
测试组会及时分析在测试过程中所收集的缺陷数据,及时发现项目测试质量方面的问题,以采取有效的质量控制措施。测试组负责定期对缺陷数据进行分析,主要的分析包括:
, 缺陷趋势分析:主要用于分析测试过程中缺陷发现和修正的进展状况。
, 未对应的BUG数分析:主要体现当前测试过程中未对应完的bug状况,
以协调资源处理长期未对应的bug。
, 帕雷托分析:Pareto的原则是将大的问题分解成小的问题并识别出最重
要的部分,使我们利用有限的资源集中解决关键的因素以得到最大的收
益。项目组将按照从大到小的顺序描述了各类缺陷的分布情况,并按照
帕雷托的原则分析占项目80%缺陷数量的少数几类缺陷,分析缺陷产生
的根本原因并执行相应的预防措施以提高软件系统质量。
, 缺陷等级分析:用于描述了项目不同错误等级的缺陷百分比情况。其分
析结果将帮助项目组重点对影响项目质量的缺陷采取措施。测试组将为
所有缺陷评定问题解决的优先级。
, 缺陷分布分析:描述项目各个版本、各个模块和阶段等多个角度考察缺
陷分布情况,用于分析项目状态。
8.1.5. 测试过程控制
, 编制测试计划
编制测试计划的目的是确定和描述要实施和执行的测试。测试负责人编制测试计划,用于描述所要执行的不同测试类型。同时,在这个基础上为每种测试类型制定一个详细的测试进度安排。
项目测试阶段的测试和管理工作将按照测试计划的指导严格进行。
测试设计员在编制测试计划时的工作步骤如下:
, 确定测试需求
测试计划活动一开始,测试设计员会确定测试需求,以确定测试对象以及测试工作的范围和作用。除此之外还确定整个测试工作(如安排时间表、测试设计等)并作为测试覆盖的基础。项目组要求被确定的测试需求项必须是可核实的。
85
即,它们必须有一个可观察、可评价的结果。
, 进行风险评估
在进行测试时,项目组和测试设计员需要在有限的资源和风险之间进行权衡,往往最重要的测试需求能够反映出最高级别的风险。
相关风险的确定可以通过以下几个方面进行:
, 效果 – 测试用例(需求等)失效造成的影响或后果。
, 原因 - 确定不合需要的结果,并确定哪些测试用例或需求一旦失效将
产生该结果。
, 可能性 – 测试用例或需求失效的概率。
我们知道,大多数应用程序都有某些功能是经常使用的,而另外一些则是较少使用的。测试组要对应用程序进行合理的测试,不仅确保对具有最高风险的测试需求进行测试,而且还将对经常使用的功能进行严密的测试(因为这些功能通常是最终用户最频繁使用的)。
, 制定测试策略
测试设计员将制定测试策略,来确定和描述测试的手段和工具,以及判断软件系统质量和测试工作是否完整实施的评价方法。测试策略的目的是向测试人员传达如何进行测试以及采用何种评价标准来确定测试的完成和成功程度。策略不会非常详尽,但是策划会描述进行测试的方法。
制定测试策略的步骤将会包括:
, 确定和描述测试方法
, 确定测试标准
, 确定测试的特殊事项
1、确定和描述测试方法
测试方法是对如何实施测试的说明。它应该说明或指出测试对象、测试时采取的主要操作以及如何核实结果等。说明应该为读者提供足够的信息以便他们能够理解测试的对象。
2、确定测试标准
86
测试标准是关于测试的客观说明,它指明那些用于确定/识别测试完成时间
的值和被测试应用程序质量。测试标准可能包括一系列说明或对其他文档(比如
方法指南或测试标准等)的引用。测试标准确定的内容为:
, 测试对象(具体测试目标)
, 评价方法
, 评估评价方法所采用的标准
3、确定测试的特殊事项
应列出所有关于测试或者依赖关系的特殊事项,例如:
, 测试数据库将由操作资源恢复。
, 测试(性能)必须在办公结束后开始(不受日常的正常操作影响)
并且在凌晨 5:00 以前结束。
, 必须与遗留系统同步(或模拟同步)。
, 人员组织
我公司将组建最专业的测试队伍,来完成本项目不同阶段的测试工作,测试
人员考核必需具备以下能力:
, 具有管理和制定测试计划能力
, 具有大型网络系统测试经验
, 具有多人异地联合测试经验
, 具有设计测试用例和设计制定实验数据能力
, 熟练应用测试工具能力
, 执行测试并评估结果能力
, 管理和维护测试系统能力
, 确定资源
测试经理和测试设计人员在确定了测试对象、测试方法和人员组织之后,将
会确定测试活动所需的资源支持。这里提到的资源包括如下: , 测试环境(包括硬件和软件)
, 工具
87
, 数据
1、测试环境
, 执行测试管理、设计和实施活动的实施硬件环境;
, 执行所有测试的执行硬件环境,它是一个独立的执行系统。
, 进行测试的软件软件系统在包括所测试的应用程序、客户端和服务
器端配置软件、以及网络相关程序之外,还包括精确模拟/复制生
产环境的软件,这类软件有:
, 文件服务器和网络中常驻或运行的其他应用程序。
2、工具
这里的工具包括测试辅助软件工具和测试过程统计分析工具;测试设计人员会确定这些工具,并指明工具的使用人、使用方法、和使用周期、以及使用工具将带来的益处。
统计分析工具将辅助收集测试数据,并对数据进行分析,作为依据来帮助测试经理和开发人员判断测试过程问题的处理。
3、数据
数据分为测试输入数据和结果输出数据。软件测试在很大程度上取决于输入数据(或测试条件和场景)和输出结果数据的使用。在该阶段,测试设计人员会:
, 收集或生成用于测试的数据(输入和输出);
, 测试场景和测试步骤的顺序;
, 数据库构架(隔离外界影响的手段以及在测试完成后将数据返回初
始状态的方法);
, 确定测试日程表
项目组的测试设计人员将依据项目开发的整体日程制作和确认测试的日程表。这项工作主要分为两个部分:
, 估计测试工作
, 制定测试进度
1、估计测试工作
88
在估计测试工作时,会考虑如下条件的限制:
, 投入到项目中的人力资源的生产率和技能/知识水平;
, 要构建的应用程序的相关参数;
, 测试覆盖率(测试密度)
2、制定测试日程
测试设计人员和测试经理通过工作的估计和资源的分配来制定测试日程。针对项目的迭代开发模型,测试设计人员将对每一个迭代过程制定一个独立的测试日程表。所有测试活动将会在每一轮迭代过程中重复进行。
首次迭代将主要以新功能和新测试为对象。随着集成活动的推进,新功能测试的数量将减少,而需要执行以检验累计功能的回归测试的数目将增加。因此,测试设计人员将在早期迭代中更多地在测试计划和设计上进行工作,而后期迭代则偏重于测试执行和评估。
基于以上原理,测试设计人员会使用估计好的工作和已分配的资源创建测试工作日程表。
图 8-1迭代开发中的生命周期测试过程
, 生成测试计划
在以上工作的基础上,测试设计人员按照以下步骤生成测试计划:
, 评审现有材料
, 确定测试可交付工件
, 生成测试计划
89
1、评审现有材料
在生成测试计划之前,应该复审所有现有项目信息以确保测试计划包含最新和最准确的信息。如果需要,应修改测试相关信息(测试需求、测试策略、资源等)以反映所有变更。
2、确定测试可交付工件
测试可交付工件部分的目的在于落实和规定创建、维护以及如何向其他人提供测试工件的方法。这些工件包括:
, 测试模型
, 测试用例
, 测试过程
, 测试脚本
, 变更请求
3、生成测试计划
制定测试计划活动的最后步骤是生成测试计划。它通过集中收集到的所有测试信息来完成,并生成一份报告。
, 进行测试设计
项目的测试设计人员在完成测试计划制定之后,将进行测试设计工作。这项工作主要步骤描述如下:
, 性能测试的工作量分析
针对项目的性能测试设计,测试设计人员将首先执行工作量分析,生成工作量分析文档。工作量分析内容包括:
, 明确性能测试的目标与用例
, 确定性能测试中要模拟的角色及特征
, 确定性能测试中要模拟的工作量(数据库访问数据量、网络流量负载等)
, 确定性能评价方法与标准
, 选择最常使用和最大负载用例
, 生成测试用例
90
, 为每个测试用例确定评价焦点
, 确定并描述测试用例
在这部分工作中,测试设计人员首先了解、分析、明确、和描述测试角色和系统之间的交互操作或步骤。这些内容将进一步用于确定与描述测试应用程序所需的测试用例。
在此之后,测试设计人员将为每一项测试需求编写适当的测试用例。如果已测试过以前的版本,则测试用例已经存在。这种情况下将会对这些测试用例再次评审,以保证它们可以在新一轮的测试中适用。回归测试用例应包括在当前迭代中,并应与处理新行为的新测试用例结合使用。
在以上两项工作基础上,测试设计人员还需要确定测试需要用到的测试用例数据。测试用例数据主要包括以下三种数据:
, 用作输入的数据值
, 用作预期结果的数据值
, 用作支持测试用例所需的数据
, 检查评估测试覆盖
在该项工作过程中,测试设计人员将通过确定测试覆盖评测方法和生成并分发测试覆盖报告的手段对测试用例的覆盖度进行检查评估。测试覆盖评测方法用于确定测试当前或将要达到的完全程度。确定测试覆盖的方法有二:
, 基于需求的覆盖
, 基于代码的覆盖
, 创建和确认测试脚本
测试设计人员将依据项目的实际情况创建或通过工具自动生成适当的测试脚本,以便按照预期的方式实施并执行测试用例和测试过程。
对于测试模型中的每个结构化测试过程,需创建或生成至少一个测试脚本。在创建、生成或获取测试脚本时,会考虑以下因素对工作的影响:
, 尽量增大测试脚本的复用程度
, 尽量减小测试脚本的维护程度
91
, 可行的话,尽量使用现有脚本
, 可行的话,使用测试工具(而不通过编程)创建测试脚本
, 可行的话,以最稳定的方法访问应用程序GUI对象和操作
在测试脚本创建完毕之后,测试设计人员还需要对脚本进行测试或者调试,以保证这些测试脚本能正确地实施和执行测试。
, 创建和维护外部数据集
外部测试用数据是指将数据保存在测试脚本的外部,由测试脚本在执行测试时调用。创建和维护外部测试用数据的好处在于脚本与数据分离,测试过程中数据可以灵活修改调整,提高了复用性。
创建和维护外部数据集将按照以下步骤进行:
, 复审测试模型、测试用例和结构化测试过程
, 使用适当的工具和方法创建数据集
, 修改测试脚本以便使用数据集
在测试脚本创建完毕之后,测试设计人员还需要对脚本进行测试或者调试,以保证这些测试脚本能正确地实施和执行测试。
, 执行测试过程
这里描述的测试过程主要是指项目的集成测试和系统测试过程,单元测试已经在项目实施一章中进行了描述,验收测试过程将有独立章节描述。
集成测试阶段的目的是确保各构件组合在一起后能够按既定意图协作运行,并确保增量的行为正确。系统集成员在各增量中编译并链接系统。每一增量都需要测试增加的功能,并进行以前版本测试过的所有测试(回归测试)。
系统测试阶段的目的是确保整个系统按既定意图运行。系统集成员在各增量中编译并链接系统。每一增量都需要测试增加的功能,并进行以前版本测试过的所有测试(回归测试)。
这两个测试阶段所用到的测试流程基本上类似的,主要包括执行测试过程、评价测试执行情况、对比核实测试结果等内容,详细内容描述如下:
, 执行测试过程
92
测试组在执行测试过程时将遵循以下步骤:
, 设置测试环境,确保所需的全部构件(硬件、软件、工具、数据等)都
已准备就绪并处于测试环境中
, 将测试环境初始化,以确保所有构件都处于正确的初始状态,可以开始
测试
, 依据测试用例,逐步执行测试过程
注:测试过程的执行方式将依据测试是自动测试还是手工测试而有所不同。
, 自动测试:执行在实施测试活动中创建的测试脚本。
, 手工测试:按照在设计测试活动中制定的结构化测试过程来手工执行测
试。
, 评价测试的执行情况
一般来说,测试执行活动结束或终止时,以下两种情况之一会出现:
, 正常终止:所有测试过程(或脚本)按预期方式执行至结束。
, 异常或提前结束:测试过程(或脚本)没有按预期方式执行或没有完全
执行。当测试异常终止时,测试结果可能不可靠。在执行任何其他测试
活动之前,应确定并解决异常/提前终止的原因,然后重新执行测试。
测试组会针对测试活动结束或者终止的结果,根据具体情况对此作出评价,并对结果进行核实。
, 核实测试结果
测试完成后,测试组将评审测试结果以确保测试结果可靠,确保所报告的故障、警告或意外结果不是(对测试对象的)外部影响造成的。如果所报告的故障是在测试工件中确定的错误导致的,或者是测试环境的问题造成的,则应当采取适当的纠正措施进行纠正,然后重新执行测试。
, 测试意外中断的处理
测试过程中,可能会出现意外中断测试进程的错误,因此测试组会针对这种情况,确定问题的实际原因,并纠正问题,重置测试环境,然后重新执行测试。
一般来说,这种情况可能由以下两种错误导致:
93
, 致命错误 - 系统故障(网络故障、硬件崩溃等)。
, 测试脚本命令故障 - 针对自动测试,指测试脚本无法执行某条命令(或
代码行)。
, 评价测试结果
评价测试结果是指通过评价测试结果、确定并记录变更请求,以及计算主要测试评测方法来完成的。评价步骤和内容主要包含:
, 分析测试结果并提交变更请求,以保证测试已执行完全,并确保报告的
测试结果没有受到非测试对象因素的影响;
, 评估基于需求的测试覆盖,来确定:
a) 需求的测试(测试用例)的数量与测试对象的总测试数量的比例
b) 成功执行的测试用例的比例
这个工作的目的在于确保要在本次迭代中进行的基于需求的测试能够百分之百成功执行。如果这是不可能或不可行的,则应确定一个不同的测试覆盖标准,该标准的基础可以是:风险或优先级,也可以是可接受的覆盖百分比。
, 评估基于代码的测试覆盖,来确定测试期间执行的代码(如代码行或语
句)与测试对象中总代码的比例。
目的是要确保要在本次迭代中测试的代码百分之百成功执行。如果这是不可能或不可行的,则应确定一个不同的测试覆盖标准,该标准的基础可以是:风险或优先级,也可以是可接受的覆盖百分比。
, 分析缺陷,目的在于通过队缺陷密度、趋势等的分析,将本次迭代的评
测方法与先前各次迭代的分析结果进行比较,判断缺陷的走势,为缺陷
修正和下一次迭代测试提供可资借鉴的依据。其中:
a) 缺陷密度 – 单位代码量测试发现的缺陷数量
b) 缺陷趋势 – 以图表形式表现的缺陷数目以随时间变化的函数曲线
, 确定是否达到了测试的完成标准和成功标准
一轮迭代测试结束,测试组会在QA指导下,根据测试覆盖和/或缺陷评估结果,来检验测试结果、缺陷与缺陷分析,判断是否已达到预定的测试目的。如果没有达标,则可以根据项目实际情况,建议安排进一步测试,手段包括:
94
a) 实施新测试以进一步执行测试用例
b) 实施新测试以扩大测试覆盖面
, 生成测试评估摘要
测试结束后,测试组将依据上述信息内容撰写测试评估报告,并将其分发给相应的角色进行评审。
8.1.6. 测试工具
为了保障测试质量,提高测试效率,我公司在测试过程中,广泛的应用国际上主流的测试工具,一般而言,我们将测试工具分为白盒测试工具、黑盒测试工具、性能测试工具、测试管理工具等几个大类。我公司测试工具的使用情况如下: 8.1.6.1. 白盒测试工具
白盒测试工具主要是针对代码进行测试,测试中发现的缺陷可以定位到代码级,根据测试工具原理的不同,又可以分为静态测试工具和动态测试工具。
静态测试工具:直接对代码进行分析,不需要运行代码,也不需要对代码编译链接,生成可执行文件。静态测试工具一般是对代码进行语法扫描,找出不符合编码规范的地方,根据某种质量模型评价代码的质量,生成系统的调用关系图等。
动态测试工具:动态测试工具与静态测试工具不同,动态测试工具的一般采用"插桩"的方式,向代码生成的可执行文件中插入一些监测代码,用来统计程序运行时的数据。其与静态测试工具最大的不同就是动态测试工具要求被测系统实际运行。
我公司使用的白盒测试工具为Apache JMeter, JMeter是100,的Java桌面应用程序,它被设计用来加载被测试软件功能特性、度量被测试软件的性能。设计Jmeter的初衷是测试Web应用,后来又扩充了其它的功能。Jmeter可以完成针对静态资源和动态资源(Servlets, Perl脚本, Java对象, 数据查询等)的性能测试。 Jmeter可以模拟大量的服务器负载、网络负载、软件对象负载,通过不同的加载类型全面测试软件的性能。Jmeter提供图形化的性能分析。
95
8.1.6.2. 黑盒测试工具
黑盒测试工具适用于黑盒测试的场合,黑盒测试工具的一般原理是利用脚本
(Playback),模拟用户的操作,然后将被测系统的输出记的录制(Record)/回放
录下来同预先给定的标准结果比较。黑盒测试工具可以大大减轻黑盒测试的工作量,在迭代开发的过程中,能够很好地进行回归测试。
我公司使用的黑盒测试工具为MaxQ。
8.1.6.3. 性能测试工具
我公司使用的性能测试工具为MercuryInteractive公司的LoadRunner,LoadRunner是一种适用于各种体系架构的自动负载测试工具,它能预测系统行为并优化系统性能。LoadRunner的测试对象是整个企业的系统,它通过模拟实际用户的操作行为和实行实时性能监测,来帮助您更快的查找和发现问题。 8.1.6.4. 其他相关测试工具
我公司使用的其他相关测试工具有:
, 单元测试工具:JUNIT
, Web测试工具:WebInject
, 测试管理工具:TestLink
, TPTEST工具可以方便的测试Internet连接速度
, ??????
96
8.1.7. 测试过程文档控制
图 8-2阶段计划进度表
图 8-3测试任务跟踪表
图 8-4项目风险管理表
97
图 8-5评审记录
图 8-6问题确认记录表
图 8-7测试问题卡
98
图 8-8测试总结报告
图 8-9软件问题统计分析表
99
图 8-10性能问题分析表
图 8-11遗留问题分析表
100
图 8-12测试结束检查表
8.2.系统验收方案
8.2.1. 社会保障卡系统验收概述
8.2.1.1. 验收管理
用户阶段的验收条件、验收流程、周期控制、风险分析、验收后续工作内容等。
8.2.1.2. 验收条件
验收条件是依据
合同
劳动合同范本免费下载装修合同范本免费下载租赁合同免费下载房屋买卖合同下载劳务合同范本下载
条款,双方共同确认的软件验收所满足前提条件。针对本项目:
初验的条件是满足招标文件要求的前提下,完成了一个试点地区上线,并连续无重大故障运行1个月后,由开发商以书面的形式提交初验申请报告,并经过监理公司和业主方批准后,即达到初验条件。
101
终验条件是在完成了其余地区上线,并连续无重大故障运行1个月后,由开发商以书面的形式提交终验申请报告,并通过监理公司和业主批准后,即达到终验条件。
8.2.1.3. 第三方测试机构的测试
A. 系统通过甲方指定的第三方测试机构测试确认是系统通过最终验收的必要条件。对于第三方测试机构的测试工作,我公司会对第三方测试机构的测试行为给予配合。
(第三方测试机构提供的系统测试结果的知识产权归用户方所有。 B
8.2.1.4. 验收程序
按照以下程序进行系统验收工作:
1、提出系统验收申请;
2、制定系统验收计划;
3、成立系统验收委员会;
4、准备项目验收环境和文档;
5、按照验收标准,进行系统验收测试;
6、进行系统验收评审;
7、形成系统验收报告,并签署证书;
8、产品移交。
8.2.2. 初验方案
8.2.2.1. 初步验收条件
系统安装调试通过后,并同时满足以下条件,我公司向监理方提出书面验收申请,经监理方审核同意,并报用户方批准后进行初步验收,初步验收由用户方组织进行。
102
A(完成了一个试点发卡任务后,并连续无重大事故1个月后;
B.系统各项要求基本达到招标文件中的要求;
C.系统的功能达到建设方案中描述的需求和功能;
D.系统在调试期间出现的问题已经解决,对部分不影响系统正常运行的功能性问题我公司承诺解决;
E.根据招标文件及系统建设方案要求,我公司需要向用户方提交的各类文档必须齐全;
8.2.2.2. 初验标准
初验标准将在项目需求和概要设计完成后,依据合同当事人共同签署的需求说明书以及合同,由我公司先制定一份系统初验标准(草案),经过合同当事人共同评审后,形成最后的验收标准。
验收标准至少包括:
, 验收的内容(系统,源代码,相关的技术文档)
, 验收的环境要求
, 测试用例和判断标准等
, 初验内容
招标明确要求的全部内容。
, 验收环境要求
对验收执行的环境进行规定,主要包括:
, 数据库服务要求;
, 应用服务器要求;
, 用户终端要求;
, 数据库参数配置要求;
, 中间件参数配置要求;
要求测试环境尽量符合实际运行环境,当不能满足时,对系统性能指标应作适当调整。
103
, 测试用例和判断依据
系统总体功能合格的判断依据是:需求说明书所规定的各子系统都开发完成,并基本达到功能和性能要求。
功能模块合格判断依据是:各功能模块满足了需求说明书规定的功能。
判断依据是建立在验收测试用例的基础上,因此在验收标准中应当附带测试用例。(测试用例也可以附带在验收计划的附件中)
, 测试用例
根据测试的模块功能,对每一条规定的验收要求,确定测试用例,明确系统输入信息和期望的输出结果。每个测试用例还应包括测试条件(包括生成测试条件需要的测试数据类型),而且每个测试用例都应该是唯一确定的(例如,赋一个数值)。
, 设计测试大纲
依据测试范围生成测试大纲。对每一种业务情况类型,生成尽可能多的测试用例来完善测试大纲。为了保证测试大纲包含所有的测试用例,将测试用例的条件映射为测试大纲是非常必要的。
测试大纲中测试用例的顺序安排是非常重要的,它应考虑多种方面的因素,主要考虑的因素是:在测试大纲中安排测试用例的顺序,使得一个测试的结果作为另一个测试前提。
8.2.2.3. 初验的组织与前期准备
, 初验的组织
验收组织工作有用户负责,由用户相关部门组织的专家组对软件系统进行全面的验收和鉴定,本公司在此过程中将全程参与,在现场进行验收前的维护工作。
为了使系统验收过程顺利进行,需要建立一个独立的系统验收领导小组。验收领导小组对制定验收和验收标准进行最后确认。
为了提高验收工作效率,应提早向用户或验收专家提交相关文档(测试计划、测试用例、测试报告),以保证验收是在有准备的条件进行。
104
, 前期准备工作
1、提出验收申请报告,最后确定验收标准
验收工作开始前,有开发商向监理方提出验收申请,并提交社会保障卡系统的程序及相关文档。监理方审核同意后,提交用户方批复,用户方相关部门对提交的应用程序及文档进行初步检查,并在约定时间内对验收申请进行批复,如申请获得批准后,则可开展下一步工作。申请批准后,由合同当事人依据合同,双方签署的功能需求说明书和制定验收标准草案,确定最后的验收标准,并确定验收的方法。
2、制定验收计划,确定验收时间,准备相关验收文档
验收前开发商先制定验收计划,列出模块清单,准备相应的测试用例。并且安排好每个模块验收的时间段。
按照双方确定的验收标准,准备提交的相关技术文档和商务文档。
3、搭建和确定验收运行环境
按照验收标准中对运行环境的要求,准备验收环境。
8.2.2.4. 用户测试验收
按照确定验收计划,事先商定验收过程要求及参加人员,必要时邀请行业专家和相关领导参与。用户根据验收计划和列出模块清单,用户进行测试验收。
为了保证每一个业务流程准备测试用例和数据的正确性,在测试计划中应遵循下列过程,并完成以下步骤:
, 用户测试计划
, 明确测试内容,其中包括功能、性能、可用性、安全性、兼容性、与其
他系统集成
, 确定测试范围:确定业务情况类型是是非常重要的。每一种业务情况类
型都对应一个实际商业业务。业务情况类型可以被表达成多种状况(例
如,简单情况、或需要进行复杂处理的例外情况)。
, 测试小组成员确定:由用户领导、业务人员、技术人员等组成,我方提
105
供验收测试过程中的技术支持。
, 明确问题分类标准:
系统的功能通过功能测试进行验证。在功能测试过程中发现的问题根据其严
重程度进行分类。下表列出了功能测试问题的分类。
严重程度 问题说明
a. 不能提供任何系统能力
b. 不能完成操作或基本任务能力,但其它功能仍然可用 A
c. 影响操作完成或基本任务能力,没有替代方案 B 影响操作完成或基本任务能力,有替代方案
a. 给用户或操作者带来不便或厌烦,但不影响要求的操作
成或基本任务能力 C
b. 给支持人员带来不便或厌烦,但不影响工作的执行
任何其它影响或所提建议 D
, 明确功能测试验收标准
测试标准 测试成果 验收标准
将测试结果与测试计划和功新系统可执行程序 不存在B及以上
级别的问题 能描述进行对照检查,确定系功能描述
统满足功能描述的要求 接口描述
操作手册
, 用户测试设计
, 设计测试用例:确定每个要求的测试用例,明确系统输入信息和期望的
输出结果,对每一条规定验收要求,确定测试用例。每个测试用例包括
测试条件(包括生成测试条件需要的测试数据类型)和期望的结果。每
个测试用例都应该是唯一确定的(例如,赋一个数值)。
106
, 设计测试大纲:依据测试范围生成测试大纲
对每一种业务情况类型,生成尽可能多的测试用例来完善测试大纲。为了保证测试大纲包含所有的测试用例,将测试用例的条件映射为测试大纲是非常必要的。
测试大纲中测试用例的顺序安排是非常重要的,它应考虑多种方面的因素,主要考虑的因素:按照系统产生的数据,在测试大纲中安排测试用例的顺序,使得一个测试的结果作为另一个测试前提。
, 测试环境准备:为了预防出现问题,如数据损坏或对系统资源的争用,
需要建立一个独立的测试环境。在进行测试之前,根据测试计划中确定
的时机建立一个独立的测试环境。其准备工作包括:
, 建立不同的服务器或在一台服务器上建立多个数据库实例,将相应
的程序迁移到适当的程序库中;
, 准备活动:包括加载数据表,建立用户访问权限;
, 建立版本控制程序,保证有效的控制对系统的修改;
, 建立文档控制程序,保证随着系统的修改,有效地控制文档的修改
(如培训文档、联机帮助和用户手册)
, 用户测试
验收测试人员依据制定的测试大纲进行测试执行,测试执行的目的是发现不满足用户要求的任何问题,在真实的环境中,客户的工作人员按照准备好的测试大纲来对系统进行测试。用户方测试人员针对检查项进行相应的测试并客观记录测试结果。其中以下几点需测试小组成员完成:
, 测试过程中发现的所有错误都必须记录下来
, 对测试过程中发现的错误进行分类和确定级别
, 测试小组内部应定期进行交流与共享在测试过程中得到的经验,应善于
接受改进建议,监测过程变化,保证达到正确的结果。验收测试小组可
以定期召开小组会议或采用其它方法进行沟通。项目经理和团队成员必
须以统一的方式检查每一周期的测试结果。在随后的测试周期再检查详
细测试结果,确认在正常和非正常条件下每项功能是否正常执行。这在
107
回归测试阶段尤为重要,因为同样的代码要用数据不断进行测试和再测
试,直到确认所有详细测试结果正常无误。
, 测试结果由指定的测试人员签字
, 集成其他系统时,重点在于新系统与所有外部接口通信准确无误,不会
影响其他系统运行。
, 用户验收报告
测试结束后,用户测试小组提交验收测试报告
测试结果说明软件满足下列要求:
, 在认可的外部设计文档中表述的功能要求
, 在认可的系统描述文档中表述的非功能要求
, 提出系统改进意见
, 验收测试小组根据测试数据,制定并向验收工作领导小组提交《用户验
收测试报告》
8.2.2.5. 验收报告的签署
, 签署“系统验收证书”
系统由开发商提交给用户后,用户应根据开发商提交的系统清单进行逐项验收,内容包括系统部分、系统相关构件、系统文档、系统源程序。然后共同签署“系统验收证书”。
, 签署“系统测试证书”
开发商将全套系统提交给用户,用户应根据其与开发商共同签署的系统模块、子系统、系统的确认测试文件,与开发商签署“系统测试证书”。 8.2.3. 终验方案
8.2.3.1. 最终整体验收条件
试运行期满后,如同时满足以下条件,我公司向监理方提出书面验收申请,
108
经监理方审核同意,并报用户方批准后进行最终验收,最终验收由用户方组织进行。
A. 各项技术要求须达到招标文件中的要求;
B(系统通过用户方指定的第三方测试机构测试确认;
C(系统的功能必须全部覆盖建设方案中描述的需求和功能;
D(系统的试运行期间出现的问题已经解决,我公司此前承诺的对部分不影响系统正常运行的功能性问题已获解决;
E. 根据招标文件及系统建设方案要求,我公司需要向用户方提交各类文档必须齐全;
F(系统全部上线试运行通过后;
8.2.3.2. 验收标准
开发商根据签订的合同及功能需求,性能需求制定验收标准草案,经双方评审确认后形成正式的验收标准。
8.2.3.3. 验收内容和方式
, 验收的内容
, 招标文件要求系统系统的全部内容。
, 以上系统的非功能性验收
, 性能和压力验收;
, 易操作性验收;
, 安全性,包括用户权限及口令,数据输入的约束及有效性,数据传
输的完整性,以及防病毒软件及其它安全产品是否按要求安装和配
置等;
, 系统性能验收(包括压力)。满足性能需求,并能稳定运行;
, 系统实施过程文档验收。由于是省统一开发,此处的验收只提供在实施
过程产生的有关技术文档。
109
, 验收的方式
采用用户方指定的第三方测试机构测试验收方式进行,测试验收通过后,请相关专家参加,对测试过程进行检查。
8.2.3.4. 用户测试验收
用户测试验收的过程与前述的初验相似。由于终验是在系统试运行3个月以后进行,因此验收的重点验证整个系统是否满足业务功能需求,同时发现还存在的问题,为后续维护提供依据。因此此处对用户测试验收过程不做过多描述。
系统的功能通过功能测试进行验证。在功能测试过程中发现的问题根据其严重程度进行分类。下表列出了功能测试问题的分类。
严重
问题说明
程度
a. 不能提供任何系统能力
A b. 不能完成操作或基本任务能力,但其它功能仍然可用
c. 影响操作完成或基本任务能力,没有替代方案
B 影响操作完成或基本任务能力,有替代方案
a. 给用户或操作者带来不便或厌烦,但不影响要求的操作成或
基本任务能力 C
b. 给支持人员带来不便或厌烦,但不影响工作的执行
无任何其它影响或所提建议 D
验收过程中发现的所有问题或程序错误都必须记录下来,并对问题或错误进行分类并确定级别;根据问题或错误对系统运行影响程度,制定相应的处理办法和修改计划。
测试结束后,用户测试小组提交验收测试报告。
110
8.2.3.5. 专家验收
系统通过用户测试验收合格后,由用户方邀请IT专家及业务专家对社会保障卡系统及项目提交物进行评审,并于评审结束后提交《专家验收报告》
1、在评审过程中,评审人将完成以下各项程序:
, 检查递交的成果是否满足要求
, 在意见表中填写评审意见
2、在评审周期内任何时间,如果评审人认为递交的成果已经满足所有需求,并提出了评审意见,评审人将通知用户方项目协调人。在这种情况下,用户方项目协调人将签署递交的成果。
、如果在评审周期结束后,递交的成果仍然不能满足规定的需求或不能解3
决评审人提出的意见,评审人将把这种情况记录在意见表中,并将意见表交给项目协调人。评审人将认为递交的成果不可接受。
4、接收/拒绝表将由项目协调人递交给项目经理。
5、项目验收总结
验收工作领导小组分析《用户验收测试报告》、《专家验收报告》,对系统进行全面评估,最终确定系统是否可以通过验收,并制定《项目验收总结报告》。
如果发现由于递交的成果没有满足质量标准要求,或在评审周期结束之日所有作者没有解决评审人提出的意见而被拒绝,拒绝的递交成果必须退回给成果递交者进行修改。如果用户方项目协调人与项目经理无法协商解决问题,将上报到相关部门解决。
8.2.3.6. 第三方测试机构的测试
系统通过用户方指定的第三方测试机构测试确认是系统通过最终验收的必要条件。对于第三方测试机构的测试工作,我公司会对第三方测试机构的测试行为给予配合。
111
9. 项目管理方案
9.1.配置与变更管理
配置与变更管理是是保证版本的统一性,项目产品的完整性,变更的可管理性和可追溯性的一项重要管理工作。
配置与变更管理的范围包括交付给客户的产品以及与之相关的产品项:开发与测试环境:软件工具、硬件设备等;项目文档资料:需求分析报告或软件功能规格说明、系统设计报告、总结报告、维护文档、往来传真件或电子邮件等;软件产品或子系统:计算机程序、用户手册等。
通常在开发策划阶段制定配置管理计划,明确配置管理的组织与职责,确定配置管理活动及其配置管理工具。软件配置管理负责人在开发策划阶段根据PM/PSM的任务分解及进度安排情况制定配置管理计划。需要在项目经理与软件项目经理的配合下参照我公司体系《项目计划模板》、《配置库结构层次图》完成配置管理计划内容;在项目进行中,由于用户需求或项目组需要,还可能根据实际情况由CML对配置管理计划的相关内容进行修正。
9.1.1. 配置管理资源配备
这里给出项目开发中配置管理相关的角色和职责分配。具体人员的映射将在项目初始阶段的配置管理计划中细化明确。见下表:
112
配置管理角色 配置活动 与工具相关的活动 配置经理 设置配置环境 定义开发组件
制定配置策略 创建配置管理库
编写配置计划 定义访问控制
创建部署单元 定义总体策略
报告配置状态
执行配置审核
项目经理 安排日程 定义集成里程碑
分配工作 分配活动
变更控制经理 建立变更控制流程 定义变更控制流程(由配置经理或其
他熟悉CQ开发的人员辅助) 复审变更请求
确认变更请求被接受或拒绝或视为重确认重复或拒绝的
复 变更请求
创建集成空间 确定候选构造 项目集成人员/
版本工程师 计划系统的集成 建立软件系统基线
创建基线 建立对外部的发布
集成系统 与外部项目集成
提升基线 为发布工件选择位置 开发人员 创建个人工作空间 创建开发视图
进行修改 在配置项上工作
提交修改 提交变化
更新开发空间 变基工作空间
提交变更请求
更新变更请求
CC/CQ 管理员 ClearCase/ClearQuest备份和恢复
ClearCase/ClearQuest 维护
ClearCase/ClearQuest 用户管理
9.1.2. 项目配置策略
该过程要制定配置管理策略,建立变更控制流程,并在配置管理计划中记录
此信息。
1)项目构件
113
通过配置软件构件从而使项目成为由构件构成的体系结构。构件可以是软件系统中相对独立的模块、子系统或包。
将多个工件组织为构件(在UCM中构件指一个VOB的根目录或VOB的某个第一层子目录)从而扩展了软件工件管理的版本控制能力,即用基线对构件而不是构件中众多的版本进行标识,然后用这一基线作为新的开发起点并更新开发人员的工作空间。
基于多个构件的组合基线,即多个构件之间可以建立依赖关系,一旦底层构件的基线发生变化,如生成一条新基线,其上层构件相应地也自动建立起一条基线,该基线自动包含底层构件基线。
如上节所描述的,开发人员在交付变更到公共集成流时可以周期性地更新他们私有开发流中的构件。然后开发团队可以根据开发过程的当前阶段和质量级别对构件进行评级。项目策略确定了在开发人员变基之前构件基线必须达到的质量级别以及其他开发团队成员(如测试人员)应该如何同构件基线交互。在稍后会对项目以及项目策略做更多描述。
2)对于不同特性的并行开发
本项目的系统系统包含多个相对独立的子系统和组件,开发时会由不同的相对独立的开发小组来实现。这样就会出现在集成或“合版本”时正常的开发被迫停止,或者因个别特性无法按期完成而影响整个项目的进度。结合我们的经验建议使用的ClearCase工具的特性,建议项目配置采用针对不同特性的并行开发策略:
以下图为例进行说明,首先在主分支(main分支)上建立一个集成分支,
114
然后在集成分支上再根据不同特性进行分支,每个特性拥有自己独立的分支,如分支“特性1”对应软件特性1,所有关于特性1的开发都在该分支上进行,不同特性的开发由于在各自的特性分支上进行,因此相互独立、互不影响。开发完成的特性通过智能的、自动化的合并功能集成到集成分支上,显然,该集成过程不影响其他特性的正常开发,全部业已完成的特性进一步合并到主分支进行测试和发布,从而实现“完成多少,发布多少”的管理目标。
3)基线和提升级别
基线在项目的里程碑或适当时间点被创建,对某个时间点构成软件系统所有物件的版本描述。这些物件在打基线后可以被更改,但更改是作为变更控制委员会过程的一部分来记录和控制的。
本项目中,将在集成流或特性流上创建基线。项目集成人员是在集成流上唯一合法能够打基线的人员。在特性流上,可以由小组的集成人员负责创建基线,并且负责向集成流上提交合并。
它们包括被拒绝(rejected),初始(initial),通过构建(built),已测试(tested)和已发布(released)。另外,UCM允许开发团队用他们自己的命名规范和提升策略对这些预定义基线级别进行定制。
基线提升级别标识了一个基线的质量,下表定义了本项目的提升级别
115
提升级别 描述
已发布 系统已经通过了所有级别的测试,准备发布
已测试 系统已经通过功能,装载,性能和压力测试
通过构建 成功编译和连接
初始 初始状态
被拒绝 坏基线,不使用的基线
9.1.3. 创建项目配置环境
在项目的先启阶段,需要创建项目的配置环境,在此环境中,项目组可以对整个软件系统进行开发、构建。
该过程主要包括以下步骤:
, 安装配置管理工具。
, 设置开发环境,创建构件的储存库、设置软件系统目录结构,导入所有
的已有文件。
, 设置配置策略,如安全访问策略、开发策略等。
, 定义基线晋升级别。
9.1.4. 变更与交付工件
项目工件的控制版本通常在限制访问权限的中心储存库中维护。借助于检入和检出操作,项目组的所有成员都可以得到授权访问的工件的特定版本,对其作出变更,重新提交并生成工件的最新控制版本。
变更与交付工件包括以下步骤:
, 加入项目,创建个人工作空间。
个人工作空间为角色提供了一个变更工件的环境,在此环境中所作的变更可以被其他角色立刻见到。
, 提交变更请求。
116
使用标准的、已记录的变更控制流程,确保在项目中进行统一的变更,并将软件系统的状态、对其所做的变更以及这些变更对成本和计划的影响通知给项目相关成员。任意角色在整个项目生命周期内都可以提交对任何配置项的变更请求。
, 进行变更。
每个人对于指派给自己的任务,执行不同的活动,来更新或添加工件。
借助配置管理工具的检入和检出操作,项目组成员可以得到工件的特定版本,对其作出变更,重新提交并生成工件的最新控制版本。这一步骤的目的在于确保开发人员遵循“检入和检出”流程,对进行版本控制的工件作出变更。
在使用基于活动的配置管理工具时,每个人可以在自己的桌面上看到指派给自己的任务,对工件的变更将关联到相应的任务上,即通过活动来组织工件的版本。
, 更新工作空间。
用推荐使用的基线中的文件来更新显示在角色的个人工作空间中的文件,确保使用最新版本的项目文件。当有文件版本发生冲突时,进行合并操作。
执行单元测试核实变更是正确的,没有缺陷。
, 交付变更内容。
在确认变更和集成版本没有冲突时,将变更从个人工作空间交付到集成工作空间。
, 更新变更请求的状态。
将变更活动通知给项目组相关成员。
9.1.5. 管理基线
软件集成人员在集成工作空间负责管理基线的活动。管理基线的活动包括建立基线和晋升基线。
当子系统达到指定的成熟度后为其建立基线,可以在随后的项目迭代中重复使用,或者用作发布。
117
根据项目配置管理策略晋升基线。晋升基线反映基线达到的软件成熟度、稳定性和质量级别。
基线的命名要遵循命名规范,便于其他人员的使用。
9.1.6. 管理软件系统交付
软件系统交付管理流程是确保向客户提交了正确的软件系统版本,包括源代码和相关的文档。
项目开发过程中的所有工件(源代码、可执行软件系统和相关文档)都进行了统一标识和版本管理,并且有变更请求管理流程控制变更,保证了源代码、可执行软件系统和相关文档的一致性。
每次的软件系统交付,至少包含可执行的软件系统、发布说明、用户支持材料。
软件系统交付流程为:
1)配置经理取得可以发布的软件系统(可以是最终软件系统的部分)版本的拷贝。该软件系统是集成了系统多个构件、可执行的并通过了所有测试,通常被标记在已发布基线中。
2)测试组执行测试/再测试。测试结果反馈给项目经理和项目配置经理。如果存在缺陷,则项目经理负责组织项目组进行修复,更新源代码和相关基线。重复1~2活动,直到测试通过或者经项目经理评估确定软件系统可以提交。
3)项目配置经理将可以发布的软件系统(包括源代码、可执行文件和相关文档)晋升基线为已发布,并生成软件系统发布说明,描述软件系统版本的相关信息。
4)项目经理按照约定方式交付软件系统,并接收客户方的反馈。 9.1.7. 变更请求管理
提供组织级的标准的变更控制流程管理项目的变更,确保项目中所做的变更保持一致,并将软件系统的状态、对其所做的变更以及这些变更对成本和时间表的影响通知给有关的涉众。
118
1)变更控制委员会
组建变更控制委员会 (CCB),由他们批准对已建立基线的配置项的所有变更。该团队的目的在于确保所有提出的变更都得到了妥善的技术分析与复审,并已记录备查。
CCB由所有受影响的组织或涉众的代表组成,主要包括客户方代表、项目软件经理、配置经理、架构师、设计师、测试设计师。
CCB 的基本任务是明确软件系统的基线、复审对基线的变更、最后批准、否决变更或延期执行。CCB 必须每周或定期按需召开会议,以此确保变更提议及时得到了复审和处理。开发团队必须将该小组视为解决问题的可靠团体,否则项目将停滞不前。
在考虑是否同意某个变更请求时,CCB将主要从以下方面综合考虑和平衡:
, 大小
必须要变更的现有工作量是多少,
需要添加的多少新工作量,
, 备选方案
是否有备选方案,
, 复杂程度
提议的变更是否容易实现,
变更可能导致哪些连锁反应,
, 严重性
不实施这个请求的会导致哪些影响,
是否涉及到工作或数据丢失,
是否为扩展请求,
是否为次要的错误,
, 进度
何时需要进行变更,
是否可行,
119
, 影响
进行变更的后果如何,
不进行变更的后果如何,
, 成本
进行变更的成本或节约的资金是多少,
与其他变更的关系
其他变更是否可以取代此变更或使其无效吗,或者此变更是否依赖于其他变
更,
, 测试
是否存在任何特殊的测试需求,
2)变更请求流程
变更请求的来源是多方面的,包括了项目相关的所有人员可能就所开发系统
提出的任何类型的请求。将这些请求经常两个大类:增强请求和缺陷。对这两种
变更请求使用定义的流程:
, 缺陷流程
状态转换参见下图
下表描述在缺陷请求上执行的流程
120
活动 描述 角色 Submit 项目的任何有关人员都能提交变更请求(CR Change 测试人员
Request)CR被提交到ClearQuest后进入CCB评审队
列,状态为Submitted
Assign 将缺陷分配给相关人员,状态为assigned状态 项目经理 Open 缺陷负责人将分配给自己的缺陷打开,进行缺陷修改,开发人员
状态为opened
Postpon项目人员根据项目目前的进度要求,资源,优先级等项目经理、e 开发人员 因素可以考虑把处于submitted、assigned、opened
状态的请求推迟到以后的开发阶段中处理,状态为
postponed。
Duplica项目人员判断提交的缺陷请求是重复的,执行项目经理、te Duplicate,状态为duplicated 开发人员 Resolve 开发人员对缺陷修改并通过单元测试。状态为开发人员
resolved
Reject 测试人员对已修改的缺陷测试没有通过,执行reject测试人员
操作,状态为opened
Validat在变更被Resolved后,变更进入测试队列,分配给测测试人员 e 试员进行软件系统测试,测试通过执行validate操
作,状态为closed
Close 对那些延期执行的缺陷根据项目的情况决定关闭操项目经理
作,状态为closed
, 增强请求流程
在需求变更请求流程中不包括任务分配活动,只进行变更的搜集和确认。与
需求变更相关的任务分配在任务管理中进行。这种方式适合变更大多覆盖面较
121
大,不能由一个人完成的项目。跟踪需求变更与相关工件的关联通过任务(利用CQ的Record Type间的parent-child实现)间接实现来实现。
下表描述在增强请求上执行的流程
活动 描述 角色 Submit 项目的任何有关人员都能提交需求变更请求,需求变更项目经理
请求被提交到ClearQuest后进入CCB评审队列,状态
为Submitted
Duplicate 判断提交的增强请求是重复的,执行Duplicate,状态CCB
为duplicated
Open 将确定变更的增强请求打开,状态为opened CCB Close 对于开发完成的需求变更请求,根据项目的情况决定关CCB
闭该请求,状态为closed
Re_open 将已经解决的请求重新打开,状态为 opened CCB , 任务流程
计划的项目任务,在Project中定义后,将任务导入ClearQuest中,用于关联活动影响的工件版本。
122
下表描述在任务上执行的流程
活动 描述 角色
Submit 项目经理的任务计划从Project导入ClearQuest 项目经理
Assign 将任务分配给相关人员,状态为assigned状态 项目经理
Activate 开发人员激活分配给自己的任务,生成或修改相应的工开发人员
件,状态为Active
Postpone 开发人员根据项目目前的进度或变更可以考虑把处于开发人员
Active状态的请求推迟到以后的开发阶段中处理,状
态为Submitted。
Complete 开发人员完成任务并通过单元测试。状态为Complete 开发人员
Reopen 将已经完成的任务重新打开,状态为 Assign 项目经理
3)管理贯穿生命周期的工件
贯穿生命周期的变更不只是开发人员对源代码和相关工件的管理,也可以由非开发人员进行管理。这些非开发人员包括分析人员,设计人员以及测试人员。相应的工件包括他们在相关领域产生的工件,例如分析人员所创建的需求文档和用例(use cases),设计人员所建立的设计模型和用例,测试人员建立的测试脚本,测试数据和测试结果。
123
9.1.8. 监测与报告配置状态
监测与报告配置状态,主要包括:
, 确定软件满足功能需求和物理需求
, 确定工件存储在受控制的库中。
, 确保工件和基线可用。
, 支持项目配置状态统计活动。这些活动基于正式化的记录,并报告已提
议变更的状态以及这些变更的实施状态。
, 通过缺陷追踪和报告活动来辅助软件系统复审。
确保为追踪进展和趋势而“积累”数据并报告数据。
9.2.范围管理
定义项目范围是定义项目过程的关键一环,管理项目范围是项目管理重要组成部分。
软件项目的范围管理主要包括界定项目需求边界,定义及控制项目应该包括或不包括的内容,以及发生范围变更时的处理办法,保证项目完成所有应该完成的工作,并且不会蔓延。
9.3.项目过程管理
经过多年的开发实践,本公司根据自己的业务特点,形成自己的项目开发实施过程,可分为八个阶段,即项目启动、需求分析、原型开发与策划、设计与编码实现、测试、安装实施、总结验收和运行维护。每个阶段对应着不同的活动内容和工作任务。在具体项目中有时为了提高效率或稳定性而采用原型、迭代开发方法,各阶段的工作在时间上可能有部分并行或重叠。
阶段 工作内容与方法 文件交付 约束条件 项目启动 主要进行内部项目组的正式调研计划 合同已经签定
组建和用户现场由用户领导
124
阶段 工作内容与方法 文件交付 约束条件
组织的所有相关人员参加的
项目启动动员会。
需求分析 主要进行用户现场需求调研软件需求说明书、软提前执行申请
批准通过 以获取用户需求,并对需求调件需求确认书、项目
研结果进行分析。 总体计划
原型开发策划 根据需求分析结果选取复用软件开发计划、培训以用户对需求
计划、例会记录模板 源(本公司有丰富的社会保障分析结果的签
系统原型库可供复用),确定字确认为需求
分析完成标志 项目进度的安排,编制开发计
划,从公司规程文件库选择适
合本项目的规程文件作为管
理控制标准,进行风险分析。
设计与编码实进行系统架构设计、功能和数系统设计说明书、数需求分析调研现 据库设计说明书 完成 据库结构设计,遵循规范进行
编码。
系统测试 测试组对开发组提交的阶段测试计划、测试记录、需要用户及时
测试报告 软件产品和最终产品进行独确认模糊细
立测试,以保证产品符合需求节,作为对需
求的补充 分析结果。软件交付使用前交
由用户方测试组进行接受测
试,以检验软件是否可用。
安装实施 为系统运行作好准备,包括完试运行/上线计划、试
成数据采集和数据转换、软件运行/上线报告、用户
的交付与安装、对操作员培训手册、系统安装维护
和系统管理员进行培训等。 手册
项目总结验收 本公司项目组对开发实施过项目总结报告、用户
125
阶段 工作内容与方法 文件交付 约束条件
程进行经验和教训总结,作为使用报告、验收报告、
将来其他项目的参考历史资整理项目沟通与活动
料。与客户一起对已经运行的记录(质量、培训、
会议记录等) 系统进行评审验收,并对验收
中发现的问题制定改进措施。
运行维护 系统验收后与客户一起制定售后服务规范
系统详细的维护策略。运行期
间系统出现故障时,对所有问
题及其修改结果都要形成书
面记录,建立系统维护档案。
9.3.1. 项目启动过程
项目启动过程意味着项目组正式成立,本公司领导在内部项目启动会上任命项目负责人,激励项目组成员,并介绍项目和客户背景,以便项目组顺利开展工作。
用户现场启动会议建议由客户方领导组织项目成员和相关人员参加,是一个项目正式开始的动员会,宣告项目启动,明确各方责任,说明注意事项,并要求所有相关人员和部门配合项目开展。我公司项目负责人简要介绍开发实施的过程和方法。
执行中参照的规程或标准:本公司质量体系文件《产品与解决方案策划过程》和《项目软件过程定义规程》。
9.3.2. 需求分析
调研与需求分析的任务主要是获取用户需求,分析用户需求特点和要求,形成系统需求,作为项目开发工作的基准。
首先需要经双方协调,制定《需求调研计划》及《需求调研大纲》,确定准
126
备工作、需求调研的内容、方法方式以及人员和日程安排等内容,用户也须做好准备工作,经双方同意后按此计划开始调研。调研正式开始前,项目开发组应检查所有必要的准备工作已经圆满完成。
按调研计划的进度进行现场调研,主要任务是用业务语言描述客户需求。尽可能及早落实主要算法,确定关键参数,掌握客户政策文件,收集需要打印的报表等。每天应将当天调研的内容整理成文档,并及时与用户确认,提高工作效率。及时将访谈记录、用户政策材料整理成规范格式的需求分析报告,向客户项目组长汇报调研结果,共同对需求分析报告内容进行确认。同时明确今后需求变更控制的规程需求变更控制流程。对于调研期间未落实的问题,以待明确问题的形式体现在需求报告中,并确定落实期限。
项目开发组根据调研编写《系统需求分析报告》,并由项目组评审,不合格的部分进一步完善调研;评审通过后由双方共同签署评审意见,并正式生效。
对于软件生产过程而言,需求阶段是整个过程中最重要的阶段,需求分析成果的好坏将直接导致项目的成功与否。评审通过后的需求报告将成为系统的设计、开发、测试、实施、试运行和项目验收的基本依据之一,因此原则上用户需求将不再因为其它因素的改变而变更,如需进行此种变更,需经双方项目负责人协商确定。
开发组与客户一起制定总体项目计划,共同确定本项目的各项工作进度安排,明确每一阶段的工作内容,以及需要用户配合完成的具体工作。执行中参照的规程或标准:本公司质量体系文件《软件需求管理规范》、《软件需求规格说明书模板》、GB8567-88* 计算机软件产品开发文档编制指南、GB9385-88* 计算机软件需求说明编制指南。
9.3.3. 开发策划
需求调研结束后,根据当前掌握的项目信息进行项目开发过程的策划,软件开发组对用户需求进行深入分析,并和我公司项目原型库各原型进行对比分析,选出和本项目模式接近的复用源作为原型,以便能快速架构和开发出符合本项目特点的稳定适用的原型系统。必要时给项目组成员培训原型系统。
127
将系统需求各部分功能进行分解,估算分解后各子功能的根据各成员的特长和业务发展方向分配任务。将开发过程分为几个阶段,把某些重要任务的完成作为检查点。根据任务划分结果制定开发计划进度表,并标记出各阶段检查点,作为项目跟踪监控的依据。开发计划要符合公司的模板模范,并与前面提到的总体项目计划保持一致,不可预知事务建议采用日程表记录,不再制定计划。
《项目开发计划》制定出来后,要提交给部门进行评审和风险分析,评审通过后纳入配置管理。开发计划一般作为开发过程进度安排,在执行中根据实际情况变化应及时调整修改计划,并将实际执行结果与最初的计划相比较,作为考评开发负责人的一项内容。开发计划进度表参见《软件实施计划书》
执行中参照的规程或标准:本公司质量体系文件《软件需求管理规范》、《软件需求规格说明书模板》、GB8567-88* 计算机软件产品开发文档编制指南、GB9385-88* 计算机软件需求说明编制指南。
9.3.4. 设计与编码实现
9.3.4.1. 系统设计
项目经理召集项目组全体成员一起讨论和明确系统设计、数据结构、每个人的工作内容、各部分之间的接口关联等。做到每个项目组成员对项目的总体情况、整体工作目标和个人工作目标、工作时间、与其他人的关系、工作的方式方法等都有个清晰的概念,为项目的顺利开展及项目组成员间的良好沟通做好铺垫。
应全面考虑调研时用户提出的每个功能模块,开发出的程序应贴近用户需求,开发人员应从用户的角度来考虑问题。做到定期检查和总结,来保证整体程序的完整性、一致性和协调性,保证项目按计划进行。如果发现有重大问题可能影响项目进展,PSM要及时向PM和部门负责人员提出。在开发过程中有不明确的需求,应该尽量以书面的形式与用户交流。
项目开发组通过对系统的功能、运行和性能要求加以分析,产生一个高层次的系统结构、软件结构、接口和数据格式的设计,形成《系统设计报告》(其中包括数据库设计),提交项目组评审。对其中评审不合格的部分进一步完善和重新策划,评审通过后,作为后续软件开发和测试的基础。
128
9.3.4.2. 编码实现
根据系统设计输出结果和公司编码规范的要求进行代码编写,实现软件功能。制定二级开发计划,作为软件编码阶段的项目管理和监控依据,项目开发小组要严格据此计划控制项目进度,按时向工程领导小组汇报工作进展。为保证质量软件开发组应每周进行代码审查,提前发现问题,减少测试工作量。
为了使用户能够及时获知项目的进展情况,开发小组向客户项目组长或相关领导提交项目周报。在编码实现过程中,也欢迎客户业务和技术负责人对阶段结果进行检查,以便及早发现问题,纠正偏差。
9.3.5. 系统测试
测试是检验软件开发结果质量的重要手段之一,根据阶段不同,可将测试划分为三个阶段:单元测试、集成测试和系统测试。
首先是单元测试,侧重于核实软件的最小可测试元素。单元可以是一个窗口(窗体),也可以是一个函数、菜单、报表或一个存储过程。单元测试应对单元内所有重要的控制路径设计测试用例,以便发现单元内部的错误,保证模块自身的准确性和流畅性。
集成测试是把通过单元测试的各个模块组装在一起之后,按设计要求进行的测试,以便发现与接口有关的各种错误,保证系统的初步正确和稳定。
系统测试在单元测试和集成测试后,基于系统的整体需求说明书而对系统进行的准确性和完整性的测。
根据测试的内容和侧重点不同又可将测试分为:功能测试、性能测试和安全性测试。
功能测试是对软件系统的功能需求进行的测试。主要暴露由于系统说明写的不明确或开发人员对系统说明的误解或理解不足造成的功能错误。
性能测试是为描述测试对象与性能相关的特征并对其进行评价,而实施和执行的一类测试,如描述和评价计时配置文件、执行流、响应时间以及操作的可靠性和限制等特征。包括负载测试、强度测试、并发测试、恢复测试等内容:
129
, 负载测试:核实在保持配置不变的情况下,测试对象在不同操作条件(如
不同用户数、事务数等)下性能行为的可接受性;
, 压力测试:核实测试对象性能行为在异常或极端条件(如资源减少或用
户数过多)之下的可接受性;
, 并发操作测试:核实测试对象在处理多个并发请求时的可接受性;
, 恢复测试:恢复测试可确保测试对象能成功完成故障转移,并能从导致
意外数据损失或数据完整性破坏的各种硬件、软件或网络故障中恢复。
通过加强性能测试提高软件可靠性,使系统每年中断工作次数不超过3次,累计时间不超过1小时。
安全性测试是测试系统在防止非授权的内部或外部用户的访问或故意破坏等情况时的表现。
测试人员在软件开发过程中开始编写测试用例和测试大纲,根据制定的《测试计划》,在软件功能模块完成后,根据需求和设计结果的要求对软件进行测试,填写《测试问题卡》,并进行测试总结编制《测试总结报告》,对测试所发现的问题进行追踪修改和确认测试,直到彻底修改完成并对其它模块没有任何影响。测试过程尽量能够模拟用户环境测试几个周期。测试组测试时,开发人员应密切配合,及时改正测试出的问题,对问题应做备忘录,以便将来查询。测试资料作为项目验收的重要内容之一。为加快项目进度,建议用户方测试组及早介入测试,最晚也应在我方的系统测试完成之前介入,并按事先双方约定的规范方式进行测试。
9.3.6. 实施
系统安装完成后,先进行一段时间的试运行,通过模拟数据的运行检查系统的可靠性,包括系统、系统软件及服务器的融合与一致性,网络性能等。同时也让客户对实际系统有感性认识。
用户方人员负责基础数据的采集,并协助我方技术人员完成数据转换工作,提供系统需求等辅助性工作,以保证项目能够保质保量地完成。
系统正式运行前,要认真检查数据库对象是否完整、正确,基础数据是否齐
130
备,要与用户一起认真对照每一个参数维护得是否准确,要保证运行程序与源码的一致性,要保证网络的连通性,要对所有安装过程序的机器做记录,以便程序升级时及时更新。还有很关键的一点,就是要保证整个网络系统中没有计算机病毒。所有环节核对准确后,要做一次初始状态的数据备份。以上事项PSM最好拉一个任务清单,在系统上线运行前和用户开一个准备会议,把每项工作逐一落实到人头负责,经双方交流协调,形成《项目实施计划》,确定现场实施的准备工作、人员和日程安排、培训计划、阶段目标等内容,经双方负责人签字后生效,按此计划开始现场实施。正式开始现场实施前,项目开发组应检查所有必要的准备工作是否已经完成。
现场工作首先要进行软件在服务器端的安装和调试,包括数据库中各类对象的生成,初始化数据,原有系统的重要数据的转换导入,前后台软件的安装,配置参数调整等工作。
软件安装完成并确认可以正常运行后,开始相关业务人员的培训,在培训开始之前双方协商形成《培训计划》,明确培训环境、条件及方式,参加人员,课程课时等详细内容,由双方现场实施负责人签字后生效,并分别开始着手准备,在既定时间内完成。
培训过程中要对每个操作员培训效果进行考核,严格把关,这对我们系统能否平稳启动和运行有很大关系。培训过程中由工程师提供《培训考勤记录》,培训应该脱产、集中、封闭进行,并要求所有参加人每日必须两次考勤;培训完成后由双方共同进行《培训总结》,针对培训效果确定是否达到目标,是否再增加培训课程。
培训顺利完成后将开始软件在试点部门试用,试用期内各业务和技术人员可以再冷次检查软件功能和性能是否满足业务和管理需要,列出未完成及含有较严重、明显错误的模块清单形成软件问题及修改记录并提交给开发组继续完善。
系统正式运行前应将试运行期间产生的无效数据清理,重新导入基础数据。上线运行初期,项目组成员分别跟踪各子系统的运行状态,一旦发现问题及时解决。系统启动后一周内,应确定一个时间每天和用户一起沟通和落实当天发现的问题。随着问题的减少,以后可以一周一次。
系统实施是项目过程的关键阶段,整个实施阶段需要用户和我方项目组双方
131
很好地沟通,遇到问题选出可行的方案。系统实施前双方落实需要准备的各项工作是否到位,应制定好实施计划,并商讨和落实实施计划,按计划行事。实施过程中,要有书面文档,在每个里程碑要有备忘录,清楚记载每件事情的原因,经过及解决结果。以系统能够成功运行为目标,一旦出现严重的问题应该实事求是的分析问题,将事故的原因详尽的写出报告,并且在第一时间向用户和我方领导汇报。积极解决问题,决不回避。
9.3.7. 总结验收
验收分两个阶段:安装运行前的用户测试;系统正式运行后的实际业务操作的检验。系统运行满足约定时间后,进行软件的验收工作。验收前和用户沟通好验收的时间和方式,制定验收计划,列出模块清单,并且安排好每个模块验收的时间段,按照这个时间列表与用户逐个模块验收。双方事先商定验收过程要求及参加人员,必要时邀请行业专家和相关领导参与。
软件验收以符合需求分析、合同和标书作为验收标准。验收结果说明软件满足下列要求:符合通过审核的需求和设计文档中表述的功能要求,以及符合性能和安全性等非功能要求。
问题处理:将验收过程中发现的所有错误都必须记录下来;对错误进行分类和确定级别;报告的错误得到修改/处理,或修改错误的计划得到同意。
验收工作建议由用户相关部门组织的专家组对软件系统进行全面的验收和鉴定,并出具项目验收小组领导签字的项目验收报告,并签署验收意见,本公司在此过程中将全程参与,在现场进行验收前的维护工作。
9.3.8. 运行维护管理
维护工作使软件的生存期限得以延伸,价值得到提升,也是软件质量得以保持的重要条件之一。对运行中的系统进行维护时,要严格按流程操作,以防带来意想不到的后果。系统维护一个很重要的事情就是我们要与用户沟通好工作的方式和方法,即系统基本稳定后,如果有问题,由用户定期书面提交问题报告,我们根据问题情况,制定问题解决方案及提交时间,并书面反馈。有秩序、心平气
132
和而又很理智去思考和解决问题。
9.3.8.1. 系统维护流程
, 系统维护请求
客户如有业务变更或增加的要求,须填写变更请求单对变更或新增的需
求进行详尽的描述,在得到客户领导签字确认后,由客户反相关负责人
提交给我公司项目组,并由双方各保留一份。对于用户口头提出的应予
以记录,并请客户确认。
对用户提出的问题明确的答复时间,一般不超过一天。项目组根据用户
方提出的需求要求,从客户业务办理、技术实现难度、对现有系统的冲
击等方面,对用户维护请求内容进行可行性分析和风险评估,给出分析
结果和相关建议。
, 维护请求的接受
客户的维护请求属于合同规定的范围内或项目仍在免费维护期内的,项
目组在与客户沟通的基础上自动接受维护请求。超出维护期或合同规定
范围外的维护请求,项目组必须通报上级主管,由部门负责人与客户沟
通后决定。
紧急问题:对于可能导致系统难以继续运行的重大故障,我方维护人员
可以立即着手工作,首先进行数据备份,然后才能查找并修改问题,事
后及时补充相关记录,落实其他事项。
, 系统修改
针对本次维护制定系统修改和实施计划。与客户业务人员及相关负责人
共同制定合理的维护计划。明确维护范围、进度和责任人,以及测试与
更新实施的安排和需要用户配合的工作,估算本次维护成本。对于较简
单(三天以内能完成)的维护维护
工作计划
幼儿园家访工作计划关于小学学校工作计划班级工作计划中职财务部门工作计划下载关于学校后勤工作计划
的形式可以非常简化,但不能
省略。
系统修改前认真阅读客户的维护请求,明确维护涉及的范围。正式开始
修改前必须在项目组内或向PSM阐明设计思路。对新增、变更的模块应
133
补充相关的说明文档和技术文档,以备案检查;
, 系统测试
修改完成后必须经过项目组其他成员的测试,有条件时可请客户参与测
试,确认无误后,才可进行更新。最好与用户一起制定出修改验收的标
准,让用户对每个标准逐一确认。如果条件发生变更,须在实施前修改
维护计划,以确保实施成功,降低风险。
, 系统维护与更新实施
将修改后的结果更新到实际系统前,需要通知客户本次要更新的内容,
并在客户系统管理人员在场的情况下,才能对软件进行更新。
系统更新必须选择客户下班或不使用系统的期间进行备份数据(必须)备
份将被更新的文件(可以单个或全部)运行新文件或替换被更新文件任何
软件的维护,包括经过严格的测试也有出错的可能,用户方需要确认清
楚这种风险的存在,因此建议用户方在作新的需求修改时需要对社会公
告,将由于系统升级造成的影响降低到最小。
, 系统更新确认
请客户确认更新后的内容,并在更新记录上签字,标明本次维护工作完
成,维护请求关闭。
9.3.8.2. 系统维护日常管理
, 安全意识管理
, 对项目组开发人员和客户系统管理工作人员加强经常性的信息系统
安全管理教育和培训,增强系统安全防范意识;
, 要求客户严格执行系统管理工作流程、业务需求变更处理流程,通
过良好的制度管理,将引发故障的可能性降低到最小,同时,通过
快速故障响应,将事故的影响降低到最小;
, 进一步提高系统的备份、恢复的能力,从完善的平台设计,提高系
统的稳定性。
, 数据安全性管理
134
, 对操作系统以及数据库的各级用户的口令严格管理,一律采用加密
存储的方式,并且定期修改各级口令,杜绝任何形式的密码盗用;
, 根据信息管理职责划分,可分为计算机系统管理员与业务操作人员。
其中需要严格规范每一级别计算机系统管理员的数据操作权限,同
时根据不同业务操作人员所操作的业务模块的不同,进行角色划分
和表操作的合理授权;
, 加强数据备份工作的检查和管理,防止在出现任何数据故障时,能
够进行快速、完整的数据恢复。
9.3.9. 项目管理监控
9.3.9.1. 阶段评估
在每个阶段结束时都进行生命周期里程碑评估,以确定在完成该阶段的最终迭代后是否应该让项目进入下一阶段。它标明了应使管理和技术期望重新同步的阶段点,但要考虑的问题应当主要与项目管理有关:主要的技术问题应当已经在该阶段的最终迭代和阶段收尾中得到解决。
在默认情况下,需考虑的问题主要是以下方面:
, 经过该阶段后,项目是否取得了适当的进展(在交付能力、质量和所计
划的工件等方面),
, 要进入下一阶段,项目的风险状况是否可以接受,
, 是否所有涉众都充分了解并接受项目的规模,
, 根据配置审核,项目的基线是否处于已知状态,
, 已执行项目的成本和进度是否可以接受,
如果阶段的结束也标志着合同的结束,财务状况将是尤其需要考虑的重要事项。
阶段评估可能会得到以下结果之一:
阶段评估结果表
135
阶段评估结果 说明
阶段被接受 客户代表同意项目实现了该阶段的预期目标,可以进入下一阶段。
有条件接受 客户代表同意项目可进入下一阶段,但必须先完成指定的纠正操作
阶段不被接受 项目没有实现该阶段的预期目标,需要安排进一步迭代,或者各涉
众根据合同重新确定项目规模或终止项目。 9.3.9.2. 迭代评估
每次迭代结束,项目经理都要组织项目组进行迭代评估。评估迭代结果,主要就以下方面检查:
是否成功实现迭代目标,
风险是否降低或排除,
此次发布是否实现了预期的功能和质量目标,是否实现性能和容量目标,
是否需要对项目和未来迭代计划进行变更,
当前发布版的哪些部分被认可,哪些部分必须返工,
是否发现了新的风险,
是否发生外部变更(客户或需求本身的变更),
根据针对迭代计划制定的评估标准,对迭代结果进行评估。需要评测以下几方面:功能、性能、容量、质量。依据从测试活动与收集指标步骤得到的指标对评估进行量化;在先启阶段(也许还可在迭代初期),有定性评测就已足够;但在随后的精化、构建与移交阶段,则必须依赖特定的测试评测来评估质量、性能、容量等方面。
如果所有风险都已缓解到可承受的程度,所有功能都得以实施,且所有质量目标都已达到,则软件系统即告完工。妥善的计划与执行对于在移交阶段后期实现上述目标至关重要。
依据评估结果,就风险列表、项目计划、迭代计划与需求提出变更方案。
136
9.3.9.3. 状态评估
状态评估是评估正在进行的迭代/阶段的进度。
项目经理负责定期(一般是每周)状态评估,以便解决进展和质量指标,确保不断关注项目的动态变化,以及保持所有项目相关人员之间的坦城沟通。
状态评估提供:
开放地处理、交流和解决管理、技术问题和项目风险的机制
从正在进行中的活动和进化中的软件系统配置中直接产生的客观数据
在所有项目相关人员间传播过程、进展、质量趋势、实践和经验信息的机制 9.3.9.4. 资源监控
资源是指在项目运行过程中所需要的人力资源。资源监控是指项目充分、有效地利用所涉及人员的过程,包括识别并管理这些资源以及在不同阶段需要的数量、状态等信息,确保项目的正常开展。在项目策划阶段,策划合适的资源安排到各项项目任务中,形成完整的人员配备管理计划;在项目实施过程中,通过邮件、周例会和里程碑总结等正式和不正式的手段对人员的状态进行监控。一旦出现不可避免的人员变更问题,按照规定的流程进行工作交接。
项目的资源监控有两个主要特点:
, 工作匹配原则:保证为项目配备符合项目活动能力要求的工程和管理人
员;
, 动态人员结构:根据不同阶段项目对人员的不同需求考虑投入不同能力
和不同数量的人员。
, 人员策划
需要识别为完成项目所涉及的所有人员角色、所需的经验技能、数量要求以及投入时间等信息,建立人员需求表。
基于以上需求,获取符合项目以上需求的技术和管理人员;获取的途径包括本事业部内部、公司内部其他事业部或社会招聘。获取人员的主要考虑人员的工作能力和熟练程度,具有类似项目的技术和管理经验背景优先,同时也要考虑个
137
人爱好和个人特点以及时间上可能性。
根据项目进度的要求和任务的安排,为每项任务分配人力资源以及每项资源在各个时间段内(天、周、月或者其它时间间隔)完成的工时,形成完整的人员配备管理计划。
在人员配备管理计划中,以图或表的形式描述了资源分配和人员负荷等情况,包括有:
, 甘特图:用于为每项任务分配资源。
, 任务分配状况图:描述了每项任务的资源分配状况。
, 资源图表:描述了各项资源的负荷情况。
, 资源使用状况图:描述各项资源在每项任务上所花费的工时。
, 人员变更
项目经理跟踪人员配备管理计划以监控项目人员的投入状况,并在每周和每里程碑上进行总结,监控的主要内容包括:
, 人员投入的数量以及投入的人员技能是否可以满足项目实施要求;
, 是否需要为项目人员提供必要的培训;
, 人员负荷是否不平衡;
, 人员是否流失或有流失的可能;
在项目周会和里程碑会议上,高级管理者、客户方和项目经理评审以上人员状况,制定合理的措施以处理人员管理中遇到的一些问题。
由于人员离职或工作变动会引起项目中人员的变更。项目经理会分析人员变更所带来的影响,尽量控制人员变动,对于不可避免的人员变动要处理好工作交接,以使工作能够全面、顺利的交接,降低工作交接对项目工作带来的风险和问题。
下图描述了人员变更主要活动的流程:
138
图 9-1 人员变更流程图
对于以上人员变更活动需要注意以下内容:
, 新负责人应尽量选择在相关领域有经验的人员(由于是中途接手,难度
较大);
, 如果选择本项目中已承担其他工作任务的人员作为新负责人,则一定要
准确度量其负荷,并要明确其接手后的责任;
, 交接期限的确定应以工作能够有效交接为中心,可能的情况下部门应在
工作交接结束后,才最终同意原担当离职或变动工作; , 交接计划要与项目经理和被交接者商讨制定,计划中应包含要进行哪些
交接活动、时间、内容及相关人员安排等,应该包括相关培训和自学的
内容。
项目经理要对工作交接的结果进行检查,判断相关工作是否都已经顺利交接;如果存在问题,需要与相关人员商讨后续计划。
9.4.项目沟通管理
合作双方建立良好的沟通很重要,使彼此相信对方正为成功而有效工作。项目执行过程中肯定会出现意料之外的问题,双方都需要对方的合作以解决这些问
139
题。与客户间建立交流的渠道方法有多种。书面报告也需要,但决不能完全代替面对面的会谈。
及时高效的沟通有利于增强双方的信任,提高工作效率,缩短工期。项目经理与客户之间频繁有效的联络非常重要。建立共同的信心与合作的气氛,在项目的不同阶段,需要交流技术信息,向客户报告项目的进程,控制变化,同时确保在时间与预算限制下,尽量符合客户的要求,以及共同为接受测试作准备,为投入正式运行作准备等等。
9.4.1. 项目实施各方职责
明确各方职责是沟通管理的基础和前提,在项目开发和实施的各个阶段,需定义各方的分工职责,明确各自的工作责任,按照项目实施计划和工作责任进行分工合作,从而保证项目的顺利实施。在项目实施中(如果我们有幸中标),我公司与业主方在项目各阶段的主要职责见下表。
工程项目内容 我公司的工作、责任范围 业主方的工作、责任范围
组织制定项目相关规范和标准; 参与组织制定项目相关规范和标
准; 制定项目计划;
参与制定项目计划; 管理项目组内的工作,控制项目在
计划的进度、成本下达到预定目负责协调业主方各相关部门、系统
标; 的配合工作,确保项目在计划的进
度、成本下达到预定目标; 负责参与项目的我公司人员的考
核; 负责参与项目的业主方人员的考项目管理
核。 负责组织主要技术问题和业务问
题的讨论和方案确定。 负责重大业务、技术问题的决策。
负责项目组外部的沟通。 负责项目组内部的沟通;配合项目
组外部的沟通。 配合质量管理。
负责质量管理。 配合项目风险管理。
负责项目风险控制
140
参与需求调查; 负责组织业主方各相关部门和系统
的需求调查; 负责编写需求文档;
负责各师级中心业务需求的统一。 负责与业主方确认需求变更及其
需求管理
影响。 负责需求评审;
负责需求变更及其影响的审查、确
认。
软软件开发 负责软件开发及开发管理工作。 参与软件开发工作。 件
参与需求分析、概要设计、测试验负责需求分析、概要设计、测试验开
收方案的评审; 收方案的评审; 阶段评审
发
负责详细设计、代码的评审。
负责单元测试、集成测试、系统测负责用户确认测试。
试。 测试 参与集成测试、系统测试。
参与用户确认测试。
配合各阶段的验收。 负责各阶段的验收;
验收
负责签署验收证书。
数据准备 提供数据准备规范。 负责数据准备。
提供软件培训教材和培训课程; 负责业主方参加培训的人员的组
织; 负责软件培训考核;
系
负责提供业主方培训场地和环境。 负责提供公司基地的培训场地和
人员培训 统
环境。 负责提供有关规范的培训。 上
负责组织项目组人员参加有关规线
范的培训。
负责协调各相关部门和系统,组织
上线组织 配合上线的组织工作。
系统上线工作。
负责系统上线后的操作和维护管
操作、维护 负责提供技术保障。
理。 系
141
统 系统软件 负责提供技术支持。 负责日常维护、管理。 维负责提供技术保障; 负责日常维护、管理; 护 负责软件故障处理; 负责需求变更的确认;
系统
负责版本更新的用户测试、确认。 负责需求变更的软件开发维护、版
本升级。
9.4.2. 需要用户和原承建商配合的建议
为保证项目顺利进行,在软件开发以及指定地方软件实施中,我们建议用户方在以下几个方面给予配合。
9.4.2.1. 项目管理方面
1、参入项目管理,成立与我公司相对应的项目管理组织结构,做到在项目实施的各个层面都有相应的人员给予配合;
2、负责协调用户方各相关部门的沟通和协调,在项目实施的各阶段能积极配合,确保项目在计划的进度、成本下达到预定目标;
3、负责重大业务问题的决策,参入重大技术问题的决策;
4、配合质量管理,配合项目风险管理等。
9.4.2.2. 开发阶段
1、负责提供江苏人力资源和社会保障相关的政策、管理办法、办事流程等方面的指导性文件和相关资料;负责提供软件开发的相关标准和规范;
2、在需求调研和分析阶段,相关部门应做好组织、联络和协调工作,确保有专人负责进行业务需求的交流,保证业务需求的完整性;
3、在需要原承建商配合时,请相关领导协调,请原承建商提供原有系统的数据结构设计文档、系统实施配置参数文档、原系统的用户手册,原有系统的开发接口说明文档,原有系统的各种系统管理级用户和口令等。
142
4、负责需求变更及其影响的审查和确认;
5、负责软件需求、设计和软件开发完成后的评审工作;
6、配合开发商提供系统测试所必需的数据及测试场景;
7、负责组织软件的用户测试,并对测试结果予以确认;
8、负责组织系统初步验收,以及系统最终验收工作等。
9.4.2.3. 实施部署阶段
1、省厅及相关部门,在实施前应配合做好设备和基础环境场地(机房,设备等)的准备工作。
2、在实施前,应做好数据准备工作,此时需要原承建商在数据分析和转换上,给予配合并提供一定咨询服务;
3、在系统试运行时应认真组织相关业务部门积极配合软件的试用,并对运行中出现的问题能客观记录和提出,确保系统试运行的效果和软件的进一步完善。
9.4.2.4. 培训组织工作
1、应做好培训的组织工作,特别是各地市的用户培训,确保参加人员能到位并有充裕的时间;
2、提供培训的建议和指导工作,包括:培训方式的指导,培训内容的指导,培训教材的审核,培训课程的安排等。
9.4.2.5. 项目验收阶段
1、负责项目的初步验收组织工作和评审工作;
2、负责项目的最终验收组织工作和评审工作;
3、及时对验收结果给与确认并签署验收报告等。
143
9.4.3. 沟通内容
在明确各方应配合的工作后,沟通将更加明确和有效。我公司项目组在项目
开发过程中需要就以下几方面的内容与客户及时沟通,达成共识。 序号 沟通内容 范围 说明
客户项目组、我公司
项目开始前应由双方负责人1 项目开工会 项目组、双方有关领
召集相关责任人举行开工会
导
客户项目组、我公司项目计划可能分多个,其中总2 项目总体计划 项目组、双方有关领体计划必须由双方共同制定、
导 确认
系统设计及原型开发完成后
客户项目组、我公司
3 项目阶段交互(一) 我公司项目组到客户现场再
项目组
次确认业务细节
客户项目组、我公司任一方提出的进度计划或需4 计划或需求变更
项目组 求范围的变更应向各方通报
软件开发完成后客户业务和
客户项目组、我公司技术人员到我公司对开发阶5 项目阶段交互(二)
项目组 段进行确认审查,为上线作准
备
客户项目组、我公司
6 系统安装实施计划
项目组
客户项目组、我公司
7 项目验收会议
项目组相关领导
我公司件项目组、客在整个开发过程中信息中心8 全部开发过程
户信息中心人员 人员从项目管理到开发到测
144
测全部有人一起参与,使用户
方明白整个项目状态和技术
细节
9.4.4. 客户交互的安排
除了日常工作中的沟通外,我们另安排两到三次正式的客户交互,第一次客户交互主要目的是根据开发工作进展需要,与客户项目组再次明确各项业务需求的细节,落实需求调研尚未明确或存有疑问的细节。由我公司项目组主要成员到客户现场进行沟通。第二次交互时机是开发工作完成后,请用户方各业务和技术骨干与我公司开发组针对已开发的结果,进行细致深入的评测,对照需求分析和业务运行要求来评判、测试软件功能。本次评测通过后才能进行下一步的安装实施,上线运行。
多个项目的实践经验表明,安排这两次交互对软件系统质量的稳定,以及双方取得一致认识有很大的促进作用。
另一方面,在整个开发过程中,建议用户方也要配备相应人员全程跟踪,在项目管理、架构设计、系统设计、应用开发、应用测试整个软件开发过程中相应角色全程跟踪配合。
9.5.项目风险管理
在软件开发实施中,风险是某种不确定因素,在其正常分布范围内,它可以危及项目成功或导致项目失败。因此有效的管理项目风险是项目成功的关键。
风险管理的目的是对没有达到项目计划目标或与项目计划存在差异的情况进行识别、分析并采取应对措施,以增大机会或减少负面影响。
风险管理过程包括以下内容:
1)风险识别:确定可能对项目造成影响的风险,并把第一风险的特性编制成文档。
2)风险分析:根据风险对项目潜在的影响程度,对风险进评估并区分优先级。
145
3)风险应对措施制定:定义增大机会和应对威胁的措施。
4)风险应对措施控制:执行风险管理计划以应付项目过程中的风险事件。 9.5.1. 风险管理过程
9.5.1.1. 风险管理计划
风险管理计划用于识别和管理风险,项目经理负责制定风险管理计划(风险管理计划是项目计划的一部分)。所有的风险以应包括风险名称、严重程度、负责人、预防及补救方案。
9.5.1.2. 项目风险的跟踪
项目经理负责跟踪项目的风险,软件质量保证员审核风险跟踪活动。其风险跟踪活动如下:
, 风险管理计划修改
, 项目会议
, 项目里程碑评审会
, 项目总体汇报
9.5.2. 项目风险管理计划
软件开发和实施的每个阶段都应在项目启动时作风险评估和风险规避计划。项目管理领导小组将存在的共性的风险组织各方讨论并共同制定项目风险规避计划。
风险管理计划是对项目中识别出的风险的减轻、紧急处理和预备等计划的总称。每个单独的风险计划都代表了一个或一类风险(因为每个或每类风险都有一个以上的计划响应)。
风险是负面影响项目的潜在事件或将来情形,它包含风险识别、分析和作出反应。负面影响包含降低项目质量、增加项目成本、造成项目延期、对项目不满
146
意或项目失败。同时可以把风险划分为内部引起的风险和外部环境引起的风险。 , 内部风险:能够受控或影响项目团队,例如:对项目交付成果的质量要
求层次;
, 外部风险:不能受控或影响项目团队,例如:市场环境与政府法律法规。 项目风险管理计划目标是备档所有与风险相关的计划。主要包含了: , 风险减轻计划:降低风险发生的可能性或使风险对项目的负面影响最小
而计划的行动;具体包括计划目的,执行计划的责任人,批准计划执行
授权人员,减轻风险活动/行动,计划执行有效的尺度,以及计划成本
估计。
, 风险紧急处理计划:针对特殊的风险或发生的风险而计划的处理策略、
活动和预算;具体包括:计划目的,执行计划责任人,批准计划执行授
权人,紧急处理行动,引起执行紧急处理的风险尺度,计划成本。 , 风险预备计划:针对影响项目成本和进度的风险而计划的管理行为/或
紧急处理预备;具体包括批准风险预备计划授权人,如果风险发生或需
要对不能预计的风险进行预备计划的理由,使用预备计划的尺度和计划
成本
为了能更好的管理风险,要求各方按照以下表格把发现的风险报告,同时,
按照表格要求的进行处理。所有的风险报告都必须反馈到项目管理办公室,高优
先级、影响的风险必须由PMO直接协调解决。
我公司在本项目中的用于风险计划的风险列表如下:
147
项目风险列表
QMS2005表格编号:FD401-项目编号-两位顺序号
项目经理PM:项目SQAL:项目名称:项目软件经理PSM:风险分析风险控制风险监管风险关闭编号风险等级风险描述和影响所属迭代风险类型风险降低策略应急计划关闭日期状态
图 9-2项目风险列表
9.5.3. 本项目风险和对策
根据风险发生的可能性和对项目影响的严重程度,定义风险等级:高、重大、中等、较小、低。
风险对策:主要描述应对风险的策略。风险管理的核心思想不是被动地等待(等到风险变成现实、成为问题或导致项目失败),而是决定如何对付风险。对于每个风险,有 3 种主要的可行措施:
, 风险规避:重新组织项目,使风险无法影响项目。
, 风险转移:重新组织项目,让其他方承担该风险(客户、厂商、银行、
其他主体等)。
, 风险接受:决定接受这种可能发生的风险。监视风险征兆,如果风险出
现,则制订应急计划,决定要采取的措施。
如果接受风险,还要采取两种措施及:风险减轻:采取一些及时的、正面主动的步骤来减小风险发生的可能性或影响。制定应急计划:如果风险变成实际问题,应当采取的措施。
本项目主要风险和对策如下表:
风险 风险估计 风险规避计划 风险应急计划
148
项目进项目不能按1、采用产品化和客户化开发策当项目进度与项目
度风险 略,以保证项目的质量和进度; 时完成,影响要求发生重大偏到用户使用。 差,影响到项目执2、详细制订项目计划,分解各
行时,项目经理或项工作;
项目领导小组将调3、保证足够的合格人力资源完
配资源,抢回进度。 成任务。
4、每天项目组成员都有工作日
志,每周项目组有工作进度报
告,一个阶段有项目进度报告。
通过这些,对项目进度进行监
控,使项目过程中的进度偏差
得到提前预警和控制。
系统需用户需求及1、全面理解客户需要解决的问利用在其它省需求
求 需求 变化是题:通过业务建模,了解客户分析的经验和方
的业务流程和业务需求 系统开发中法,在需求分析阶最大的风险,段把工作做细,在2、增强与客户的沟通:用例建其来源于需评审后一般不做大模立足用户角度描述,为具体求定义不完的调整。在技术上的需求提供了充分的上下文信整和用户业采用方法库和配置息,是衔接用户和开发者的纽务发生变化。 技术保证在一定限带和沟通方式。
度内对需求变化的3、及早收集客户的反馈:通过
适应性。 及早部署演示来挖掘用户的反
馈意见,改进对于需求理解的
偏差
4、控制需求变更:变更请求可
能来自于客户和最终用户、设
计人员、开发人员、测试人员、
技术支持部门等,建立变更控
149
制流程管理变更。
5、通过需求评审和确认保证需
求定义的完整性。
数据整数据整合和1、制定详细的数据整合计划 数据整理时加强数合、转换转换将直接据质量的控制工2、制定数据指标规范
作。 和协调影响数据质3、提前开始数据整理工作
切换风量和信息的数据转换时加强数4、加强同原开发商的合作
险 准确性,同时据的保护工作,加5、用户的密切配合
对原有开发强数据备份,确保
商数据库分数据转换中原始数
析需要比较据不丢失。
多的时间,这
些都会对项
目的进度和
系统上线运
行造成较大
风险
150
10. 质量保证方案
10.1. 项目质量目标
本项目的质量目标是:提供优质产品,在工程施工必备条件满足的情况下,确保该工程按照预定的工期投入正式运行,达到国家、行业或设计的质量验收评定标准和规范,并一次验收合格。
10.2. 项目质量范围和标准
10.2.1. 质量范围
结合招标文件,本项目的质量范围:
, 全市统一开发的软件应能满足通过双方共同确定业务需求,确保其运行
正常,正确地开展相关业务;
, 确保相关软件的数据库长期稳定、安全运行;
, 确保所开发的系统能够符合江苏人力资源和社会部门制订的指标体系、
数据接口、业务规范、信息数据项、信息分类编码标准,有关技术标准
严格执行国家有关规定,并与国家标准、部标准保持一致。 10.2.2. 质量标准
此次我公司为本项目所做的项目设计,将严格遵循公司的质量规定,并全面采用公司做为国内第一家通过的由国际著名的挪威船级社(DNV)承担外审的ISO9000:2000最新版的质量保证体系的管理方法。
10.3. 质量管理
软件质量管理的目的是建立对软件产品质量的定量了解和实现特定的质量目标。软件质量管理包含确定软件产品的质量目标,制定实现这些目标的计划,并监控计划的执行,根据情况变化调整计划及目标。以保证最终提交的产品能满
151
足顾客和最终用户的需要及愿望。
通过对用户发展状况和变化需求的充分了解,并从软件是客户的基础设施的角度出发选择合适的技术,控制用户的投资规模,把用户的需求与技术优化融合。以有生命的软件,来保证用户永远的价值。通过遍及全国的服务网络,为用户提供及时周到的服务构建了一个坚实的平台。
良好的项目质量管理是软件企业长期成功的根本保证,本公司实施正式的质量管理与规范的项目管理制度已经有多年的历史。在项目的整个实施过程中,严格按照公司的政策和规范要求执行。我们一直坚持贯彻执行体系要求,谋求不断改进,致力于项目管理与质量管理体系的提升。
10.3.1. 质量保证的基本思想
本软件开发项目在软件开发的全过程将采用最新国际标准的质量保证体系,使开发的产品得到可靠的保证。
质量保证过程中的基本思想是“戴明环”质量控制思想体系,即著名的PDCA原则,如下图说明:
图 10-1 采用PDCA原则进行质量保证示意图
对其中的几个工作环节进行说明:
1. 计划(Plan)——实施过程中的各阶段工作需要合作双方先经过协商制
定出完整的工作计划;例如:当进行实施工作时,需要制定每周的具体
152
工作计划;所有的工作计划都需要双方正式签字,生效,并按照执行。 2. 实现(Do)——计划完成的及时性和圆满性需要合作双方共同努力,双
方都将监督本方人员按时高效地完成既定计划;都应制定必须的考核和
奖惩制度,制定专职人员负责相关工作,使计划能够得以确切的落实;
双方还都有考察对方计划执行情况的义务和权利。
3. 检查与评审(Check)——每个工作计划到期时都将由双方进行评价,对
其中未完成的内容找出具体原因,制定改善和补救措施;项目实施过程
中所产生的全部文档、问题反馈、会议及交流记录等都必须以规范的文
档化的形式出现,同时都必须经过双方的确认和评审,签字后才能正式
生效;尤其是对于过程中所出现的问题需要双方进行多次的确认评价,
直至修改完成。
4. 改善(Act)——在整个的项目实施过程中能否具有“持续改善的能力”
一定程度将决定项目的成功与否,因此项目实施中双方需要多沟通交流,
尽早发现问题和不足,并立即改善,保证整个项目的顺利完成;实施中
工程领导小组将负责全局性的工程进展,对出现的问题和不足协商解决,
改进。
具体地说,对本开发项目应用系统主要有如下几点:
1. 在每个阶段开始时,需要对准备情况进行认真审查,并向工程领导小组
汇报,确认已经具备了开始当前阶段工作所必须的条件后,才可开始该
阶段的具体工作;
2. 实施中的每个阶段有阶段工作计划,具体工作中每周有工作周计划,所
有计划需要经双方讨论确认并签字生效;
3. 实施中双方都应按时、圆满完成任务,并督促对方的工作; 4. 实施中每阶段结束,每周工作结束,需对原定计划进行双方参与的总结,
形成总结报告,对其中未按时完成部分制定补救措施和整改计划,为下
一阶段的工作做好准备;
5. 实施中所产生的需求分析文档、软件总体设计、数据库设计都必须按时
评审,尽早发现问题所在,及时进行修改使后续工作能够正常进行;
153
6. 以上文件评审合格后由双方签署评审意见后生效,将作为下一步工作的
规范和标准,用户需求原则上不应再发生变更;如遇特殊情况需要改变
需求,届时由双方再协商解决;
7. 充分考虑到本开发项目应用系统社会保障卡系统的高安全性和数据量较
大的特点,开发组人员在进行软件功能测试时,需要有关部门提供大力
帮助;同时用户项目组可查看功能测试和系统测试情况数据,协商确定
系统测试安排,并根据测试结果调整后续工作计划和进度;
8. 实施过程中加强沟通,包括现场工作周报,用户周报等,通过充分的信
息交流了解彼此的进展情况,保证计划按时完成。
根据以上原则,在整个开发过程中,将运用一系列的质量保证手段保证开发质量。运用CASE工具进行需求分析及软件设计,使软件易于理解、易于维护、易于测试。确保系统的正确性、完整性、实用性和高效性。
10.3.2. 软件生产过程中主要的工作活动
下图为公司在软件生产过程中主要的工作活动,其中每一项工作活动都必须按照公司质量体系文件的规定执行,都会产生相应的符合规定的软件文档和记录。
154
质 量 体 系
产品策划及总体结构开发活动支持活动可行性分析
管理评审合同评审配置管理
质量体系文档控制需求
分析
内部质量质量记录体系审核开发策划
度量纠正和预质量策划防措施规则、惯
例和约定设计实现
设备、工软件测试具和技术
客户验收采购
复制、交配套产品
付和安装管理
维护管理培训
图 10-2软件生产过程中主要的工作活动
10.3.3. 质量过程管理
通过先进的过程管理方法来提高个人和团队的工作质量。PSP/TSP即个人软件过程和团队软件过程(Personal Software Process & Team Software Process)。采用PSP/TSP过程管理有助于每个人和小组工作质量的稳步提高,从而达到项目整体质量的提高。PSP用一系列的步骤解释个人软件过程的改进,每一步包含前一步所有元素并且有所增加。在设计阶段,PSP方法的着眼点在于软件缺陷的预防,具体办法是强化设计结束准则。PSP的研究结果表明:绝大多数软件缺陷是由于对问题的错误理解或简单的失误造成的,只有很少一部分是由于技术问题而产生的。因此,PSP保障软件产品质量的一个重要途径是提高设计质量。
TSP方法交由大家共同分担问题,以及定期找一个局外人来协助设计审查。解决了项目规模扩大时PSP方法中个人工作量过大的问题,并通过集体管理和全员规划等方法,提高团队工作质量和效率。
采用PSP/TSP过程方法大大提高了各阶段产品第一次交付的质量,有助于降
155
低初期故障率。
软件质量保证工作涉及软件生存周期各阶段的活动,将贯彻到日常的软件开发活动中,包括各阶段的评审和测试工作。质量保证组派成员参加所有的评审与检查活动。评审与检查的目的是为了确保在软件开发工作的各个阶段和各个方面都认真采取各项措施来保证与提高软件的质量。在社会保障系统软件开发过程中,要进行如下几类评审与检查工作:
, 阶段评审
在软件开发过程中,要定期地或阶段性地对某一开发阶段或某几个开发阶段的阶段产品进行评审。主要包括软件需求、设计评审;对功能测试与演示进行评审,并对前次评审复核;功能检查、物理检查和综合检查。
阶段评审工作要组织专门的评审小组,评审小组成员可包括用户方领导和项目组主要成员、我方质量保证人员以及监理方,其他参加人员视评审内容而定。每一次评审工作都应填写评审问题记录和总结报告。
, 日常检查
在本项目的开发过程中,各子系统应该填写项目进展报表,包括项目周报、月报和软件阶段进度表等,以表明软件阶段产品完成情况表。质量保证组可以通过日常检查有关软件质量的问题。
, 软件验收
组织专门的验收小组对本项目所属各个子系统进行验收。可邀请相关专家或国家相关部门参与本项目的验收工作,按照双方都认可的验收规程正式履行验收手续。验收内容应包括文档验收、程序验收、测试结果评审以及系统使用报告等几项工作。
10.3.4. 质量保证专项活动SQA
质量管理的主要内容之一是进行质量控制,保证各项工作无偏差的进行。差异控制可以等同于质量控制,是为了保证每一件工作产品都满足对它的需求而应用于整个开发周期中的一系列审查、复审和测试。质量控制在创建工作产品的过程中包括一个反馈循环。比较和反馈相结合,使得我们能够在得到的工作产品不
156
能满足其规约时调整开发过程。这种方法将质量控制视为整个开发过程的—部分。
质量保证的目标是为管理层提供为获知产品质量信息所需的数据,从而获得产品质量是否符合预定目标的认识和信心。目的是通过形式化的方法来保证规章制度的落实和质量目的的达成,由开发活动的审查和报告构成。
本项目的软件质量保证(SoftWare Quality Assurance,简称SQA)由公司质量保证部经验丰富的专人负责。SQA小组既代表管理层检查公司质量制度的贯彻及执行结果,以获得内部决策信息,又代表客户来监督软件质量指标在各阶段的落实结果。SQA小组的成员以双重身份看待软件开发过程,而不仅关注最终产品本身。软件开发是否依照预先设定的标准进行,是否充分满足公司质量规定和客户要求的各项质量因素,作为SQA活动的一部分的技术规程是否恰当的发挥了作用,SQA小组将通过自己的一套工作流程和方法跟踪软件开发过程,以确保软件质量得到维护。
软件质量保证是对软件过程的每一步都进行的预防活动。SQA包括对方法和工具有效应用的规程、正式技术复审、测试策略和技术、变化控制规程、保证与标准符合的规程,以及度量和报告机制。
软件质量保证由各种任务构成,这些任务分别与两种不同的参与者相关——做技术工作的软件工程师和负责质量保证的计划、监督、记录、分析及报告工作的SQA小组。
软件工程师通过技术评审、代码审查和软件测试来考虑质量问题。SQA小组的职责是辅助软件工程小组执行这些活动,并检查活动的结果是否预期的目标一致。
10.3.5. 软件工作产品质量审计和相关文档
审计类型 目的 审核对象 输出 软件工作产评估软件产品是SQA审计软件工作产品主要应用于SQA审品 否符合组织 下列工作产品,但不限于此。 核报告
157
立项(PIR、FAR、PTK)
和项目规定的规需求(SOW,RAR、FSR) 程与标准,鉴别偏策划(SIP、SDP、SQP) 差、疏漏并作出报
设计(SDR)
告以对其进行跟
编码实现(SRC、TRR、SRR) 踪。
测试(TP、TD、TS)
交付产品(EXE、UMN)
配置(SCMP、SCML、SCMR)
其它软件工作产品
确保项目选用适SQA要对现有的与计划选用的用于当的软件开发技软件开发和技术支撑的软件工具进术和软件工具 行评估。对软件工具的评估要同时
考虑其适用性与可行性。
适用性:首先考虑软件工具的功能
软件工具
是否满足项目的需要,二要考虑软
件工具所具有的功能是不是项目所
需要的。
可行性:确定技术可行性以及所需
计算机资源的可用性。 确保项目选用适SQA要对现有的与计划选用的设备当的设备 进行评估。
适用性:主要是通过考查提供的装
设备
备是否能够满足软件开发和技术支
撑的要求以评定其适用性。
资源共享:从组织的范围考虑资源
158
共享问题。
采购计划:帮助管理部门综合考虑
采购计划。
软件过程的评审
评审过程类目的 审核任务 输出
型
确保项目启动阶段需求经评审和/SQA审
后确认,变更得到有效控制。 核报告
确保SDP的编制与评审符合《软件策
在项目启动与策划过程》的要求,并符合项目的需
软件策划过
要。 划阶段,SQA协助
程
并参与质量策划。 评审软件策划阶段的各项活动符合
相应的过程与规范。(《软件策划过
程》、《质量策划过程》、《质量保证
过程》、《配置管理过程》等)
确保设计经评审,变更得到有效控
制。
编码实现有确定的规范与标准,进
行代码检查与单元测试。
评审设计与实现
建立项目级的SCM(SCM Leader、SCM 软件设计与过程的活动,保证
Library)。 实现过程 其符合SDP和相关
过程与规范 评审软件设计与实现阶段的各项活
动符合相应的过程与规范。(《软件
设计与实现过程》、《质量策划过
程》、《质量保证过程》、《配置管理
过程》等)
159
包含测试计划、测试设计、测试执
行、测试总结,需进行风险管理。
评审各级软件测
软件测试过评审软件测试阶段的各项活动符合试活动是否符合
程 相应的过程与规范。(《软件测试过相关过程与规范
程》、《质量保证过程》、《配置管理
过程》等)
软件产品/项目、系统集成项目在交
付、实施、验收、维护阶段可考虑
评审软件产品/项不同特点与需求可裁剪相应的过交付、实施、目的交付、实施、程,但需取得客户的确认。 验收、维护过验收、维护等活动
评审各项活动符合相应的过程与规程 符合相关过程与
范。(《软件交付、实施、验收、维规范
护过程》、《系统集成过程》、《客户
满意度测量过程》等)
评审软件释放与评审软件释放与制作活动符合《软软件释放与
件释放与制作过程》及相应规程。 制作活动符合相
制作过程
关过程与规范
保证SCM的一系列保证配置标识活动以及版本的控制SCM过程(定
活动符合有关的符合《配置管理过程》及相应的规期进行)
过程、规程和标准 范。
保证软件声明周期中需要评审已在
计划中明确,并得到执行,且评审
保证需要的评审
评审 的进行符合有关的规程和标准,有
得到执行
关评审的分类和详细内容请参考组
织的《评审规程》。
160
11. 培训方案
11.1. 培训需求分析
11.1.1. 培训目标
11.1.1.1. 参加系统建设的相关人员培训
为了保证社会保障卡工程建设的质量,使社会保障卡更好的满足遂宁市人力资源和社会保障管理和应用的需要,提高项目建设人员的业务水平和技术水平,在项目建设的同时,应聘请项目管理专家、社会保险业务人员、信息系统建设专家等专业人员,对相关人员进行多方面、多层次的培训。培训主要分为管理知识培训、社保业务培训、专业技术培训等内容。
1(项目管理知识培训
项目管理知识培训的对象是卡项目实施管理组成员,培训内容包括项目管理的基本原理、项目范围管理、项目时间管理、项目成本管理、项目质量、项目风险管理等,培训目标是保证项目管理小组的项目管理人员对先进的项目管理知识有比较全面、深刻的了解,并且能把这些知识应用到卡工程的项目管理中,确保卡工程建设在可控的范围下进行。
2(技术培训
技术培训分为基础知识培训和专业知识培训两种,培训对象分别为项目管理人员和专业技术人员。
基础知识的培训内容包括系统建设的理论、信息系统建设项目管理、信息系统建设项目监理等,目的是使项目管理人员从总体技术实现对系统建设有深刻的认识,保证他们更好的完成项目管理工作。
专业知识培训主要包括IC卡技术的基本知识、社会保障(个人)卡规范的相关知识、密钥管理系统与加密机的使用维护知识、IC卡和读写器使用常见问题、故障和解决办法、遂宁市社会保障(个人)卡与应用管理软件系统的使用讲解和卡经办流程的操作和应用问题的解答等内容。
161
11.1.1.2. 各市人员培训
培训目的:提高市本级、区县级人力资源和社会保障部门的业务领导、业务管和计算机技术人员的整体技术水平,建设一支既掌握信息技术又熟悉业务的主
高素质的管理队伍和技术队伍,使他们能够适应和掌握社会保障卡应用的管理要求和技术要求。
11.1.2. 培训项目
1、项目管理知识培训
2、技术培训
、计算机知识及系统操作培训 3
11.2. 培训课程体系设计
为了保证系统的正常运转,对人员分别有不同程度的要求。为用户提供全面、优质的技术培训服务,努力提高全体工作人员的技术水平,以便系统建成后,用户能够熟练地进行操作。
在签定合同之后,可以根据培训的计划对部门及单位领导进行项目的预培训、过程培训等,在项目的建设初期和项目的进行中对相关人员进行培训,安装调试前会对专业技术人员进行脱产培训,在系统升级和其他改动较大的情况下均要进行相关的培训。总之培训是贯穿整个系统建设全过程的一件非常重要的工作。
针对我们对人员结构及计算机应用水平的分析,我们编制了详细的培训计划。对以上人员预期的培训目标,即是系统对人员素质的要求。所以在这里,对人员素质要求不再展开论述。
针对本项目,提供培训计划如下:
培训课程 课程内容 课时 人数 项目管理保证项目管理小组的项目管理人员对先进的项目管3天 5
162
知识培训 理知识有比较全面、深刻的了解,并且能把这些知识
应用到卡工程的项目管理中,确保卡工程建设在可控
的范围下进行。
专业技术专业知识培训主要包括IC卡技术的基本知识、社会保5天 5 培训 障(个人)卡规范的相关知识、密钥管理系统与加密
机的使用维护知识、IC卡和读写器使用常见问题、故
障和解决办法、遂宁市社会保障(个人)卡与应用管
理软件系统的使用讲解和卡经办流程的操作和应用
问题的解答等内容,具有卡管理系统配置和二次开发
能力。
操作培训 初步了解计算机的使用方法,熟练掌握本应用系统的1天 不限
操作。 人数 11.2.1. 项目管理知识培训
项目管理知识培训
学时数 3天
内容 , 项目管理的基本原理
, 项目范围管理
, 项目时间管理
, 项目成本管理
, 项目质量管理
, 项目风险管理
授课人员资历 有实践经验的副教授以上职称的高级培训教师 培训大纲 保证项目管理小组的项目管理人员对先进的项目管理知识有
比较全面、深刻的了解,并且能把这些知识应用到卡工程的项
目管理中,确保卡工程建设在可控的范围下进行。
163
教材(中文版) 根据授课内容定制培训教材
培训人数 10人
培训方式 课堂讲解研讨
培训时间 与用户协商确定
培训地点 与用户协商确定
11.2.2. 专业技术培训
学时数:20天
授课人员资历:本公司高级培训教师(三年以上同类课程教学经验,中文授课)或原厂高级讲师
培训内容:
基础知识的培训内容包括系统建设的理论、信息系统建设项目管理、信息系统建设项目监理等,目的是使项目管理人员从总体技术实现对系统建设有深刻的认识,保证他们更好的完成项目管理工作。
专业知识培训主要包括IC卡技术的基本知识、社会保障(个人)卡规范的相关知识、密钥管理系统与加密机的使用维护知识、IC卡和读写器使用常见问题、故障和解决办法、遂宁市社会保障(个人)卡与应用管理软件系统的使用讲解和卡经办流程的操作和应用问题的解答等内容。
培训人数:40人
培训地点:与用户协商确定
考核办法:课堂讲解研讨
11.2.3. 计算机知识及系统操作培训
学时数:5天/每批次
培训教师:本公司高级培训教师(三年以上同类课程教学经验,中文授课)
培训效果:初步了解计算机的构造与使用方法,熟练掌握本应用系统的操作。
164
培训人数:不限
培训地点:项目实施地
考核办法:课堂讲解研讨
165
12. 售后服务方案
12.1. 售后服务体系简介
12.1.1. 售后服务体系理念
为用户提供易用、可靠的产品和满意的售后服务。
12.1.2. 服务支持体系构架
我公司十分重视对客户的服务,在过去的十几年的时间里,我公司逐渐建立起了集中管理与分布实施相结合的一套完整的技术支持与服务体系。
为了更好地快速响应客户的服务请求,同时严格执行ISO9000体系所要求的客户服务流程,公司在整个公司层面建立有客户服务中心(CSC)、项目管理办公室(PMO)和解决方案技术中心(STC)。
由CSC对应客户服务(包括需求、申请、投诉、反馈等)响应机制和客户满意度调查机制,从而达到对整个技术支持与服务机制的运营管理和检控职能。
由PMO负责公司全部在线实施项目的整体的项目管理与监控,包括开发流程、QA保证、统一配置管理、合同执行、现场项目状态、项目周报、项目资源协调等。
由STC负责对解决方案或者产品在出厂前的压力容量测试、业务功能验证、生产过程测试等。
12.1.3. 技术支持服务形式
我公司服务体系目前拥有大量专业技术服务人员,其中获得专业技术认证的人员占40%,大部分人员是具有丰富行业经验和项目实施经验的资深专业技术人员,他们主要是面向具有关键任务应用的客户提供专业技术服务。
我公司已经建立了全国分布式的服务体系,能够为全国性、地区性大客户提供每周7天、每天24小时的全面的技术支持和专业服务。
166
我公司非常重视客户满意度工作,公司的质量目标是客户满意度要达到95%,服务流程的全过程都有监控管理措施,客户服务代表会定期的与客户保持联系,进行客户满意度调查,及时协调处理客户遇到的各类支持请求,然后跟踪服务过程,最后形成客户满意度调查报告上报公司领导。
根据本项目的技术支持服务要求,我公司为客户提供技术服务主要有两种方式:
1、远程方式
我公司将提供服务热线电话,以便客户可以及时通过该热线提出服务请求,我公司将对服务请求情况通过专门的管理系统进行记录和跟踪。同时作为热线电话的补充,还将提供专门的传真和电子邮箱以便服务请求信息的更准确交流。
对于客户的服务请求,我公司将通过电话、传真和电子邮箱提供技术咨询和支持、问题分析和技术指导及相关技术文档和工具的支持。在客户的许可下,我公司将通过远程拨号方式进入客户相关系统分析系统状况、协助客户分析和解决系统问题。
2、现场方式
对于客户的服务请求,我公司能够保证其解决时效和质量的基础上以远程方
但在下述条件下,我公司会派出技术服务人员到现场提供技术式作为优先选择。
支持和服务:
, 远程方式不能满足服务时效要求、或服务任务必须到现场才可完成
, 客户系统出现非常严重的故障(如系统停机或其故障严重危及关键应用
的运行)
, 应客户要求且我公司的项目经理同意的现场服务。
12.2. 售后服务流程
12.2.1. 技术支持服务流程
我公司为用户提供400免费技术服务热线(400-655-6789),在接到用户请求后,根据请求情况协调公司资源,第一时间给用户反馈并解决问题。
167
用户
接线员登记和查询
应用软件系统平台系统
工程师工程师
项目组
汇总解决
售前技术支持高级
工程师培训教师
系统专家
1、诊断故障并提交故障诊断报告
根据系统运行过程中出现的系统故障或其它异常情况,及时进行故障诊断,疑难问题
并提出故障诊断报告。故障诊断报告的主要内容包括:故障现场情况记录、故障的级别和紧急处理过程记录等。
2、制定系统维护和故障恢复的实施计划
根据提交的故障诊断报告,制定系统维护和故障恢复的实施计划。按照制定的计划实施系统维护工作。
3、管理、监督维护计划的实施
组成系统维护工程管理和监督工作组,全面负责管理和监督系统维护工作实施过程(应包含用户方与项目承包商双方)。并根据系统维护实施的各个阶段提交维护工作报告。
4、确认维护工作完成并提交维护报告
在系统维护工作完成后,由系统维护人员提交系统维护工作报告,由用户方项目组的技术人员对系统维护情况进行测试并予以确认。
5、提交成果
每次系统维护工作完成后,都应提交如下的报告、记录等文档等资料:
, 故障诊断报告
168
, 系统维护和故障恢复的实施计划
, 维护工作阶段报告
, 系统维护工作报告
说明:紧急情况下,以排除故障,满足用户需要为首要任务,可以进行紧急
处理,但事后要补充相应文档与记录。
12.2.2. 客户服务质量文件
在客户服务中,我公司通过以下文件来保证服务的规范和质量: , 客户服务管理:
, 《客户服务管理》,售后技术维护,客户问题管理 , 客户问题办理:
, 《客户问题受理规范》,问题记录,问题分发、办理监督,问题回复,
问题月报
, 《故障诊断报告》,故障现场情况记录、故障的级别和紧急处理过程
记录等
, 《系统维护和故障恢复的实施计划》
, 《维护工作阶段报告》、《维护工作总结报告》
, 《系统维护验收测试计划》
, 《维护工作验收报告》
, 客户满意度测量:
, 《客户满意度测量》,收集满意度,统计分析(月、季、半年、全年),
提出改进措施
, 客户培训的相关表格:(为把客户培训工作做得更好的辅助性表格)
, 《客户培训申请表》
, 《客户培训费用确认表》
, 《客户培训邀请函》
, 《客户培训邀请函回执》
169
, 《客户培训计划》
, 《客户培训记录》
, 《客户培训调查表》
, 《客户培训评估表》
, 《客户培训总结》
根据以上的质量保证体系规定,我公司为本项目设计的执行一次较完整的系统维护过程的基本步骤如下:
1) 根据本项目运行过程中软硬件出现的系统故障或其它异常情况,双方合作及时进行故障诊断,并提出《故障诊断报告》;
2) 根据提交的《故障诊断报告》,制定《系统维护和故障恢复的实施计划》,我公司按照制定的计划实施维护工作;
3) 双方共同组成系统维护工程管理和监督工作组,全面负责管理和监督系统维护工作实施过程;
4)我公司根据系统维护实施的各个阶段具体情况提交《维护工作阶段报告》,在系统维护工作完成后,由系统维护人员提交《维护工作总结报告》;
5)最后根据《故障诊断报告》、《系统维护和故障恢复的实施计划》、《维护工作阶段报告》和《维护工作总结报告》,我公司技术人员和用户方项目组的技术人员一起,讨论确定《系统维护验收测试计划》;并依此对系统进行测试验收,测试合格提交《维护工作验收报告》维护工作完成,否则继续整改。
几年来的实践证明,基于ISO9000:2000和CMM的质量保证体系的规范化质量管理为我公司的发展创新、为客户提供更高质量的软件产品发挥着至关重要的作用。我公司仍将充分利用规范化的客户服务体系,依靠多年来的成功经验,在项目的全过程中为本项目的建设提供最优良的服务。
12.2.3. 售后服务内容
众所周知,最优的售后服务是一个项目的承建商必须做出的承诺。但是,如何根据用户的实际情况(人员素质、计算机应用水平、系统的要求等),做出切合实际的项目售后服务计划书,才是用户关注的问题。优质的售后服务也一直是
170
我公司在经营活动中最基本的原则。我公司的技术支撑部门担负着专业的服务工作,无论是在系统的安装调试过程中还是在系统投入运行之后,无论发生任何问题用户都可以得到最快的响应,售后服务流程如下图所示:
针对本项目,结合对项目的组织结构、计算机应用水平、系统对人员素质要求等情况的分析,我们认为:为本项目提供本地化服务,是保证本项目建设成功的一项关键因素。
我公司提供的服务内容包括:
, 社会保障卡运行维护:社会保障卡系统自身缺陷的调整,为客户及
时解决日常运行中出现的问题。
, 根据政策和经办规程调整,及时响应需求变更,并在客户要求的时
限内完成对社会保障卡的修改或调整。
, 技术改造与升级服务:主动或应客户要求,将最新的技术成果和先
171
进的管理模式升级到原有系统,使应用系统的永远保持先进性。
, 数据库支持服务:我公司提供通过Oracle OCP认证的专职工程师为
客户提供长期的数据库优化及技术支持服务,以及异常数据修正、
批量数据处理等数据维护工作。
, 定期系统巡检:在系统维护期过后,按照签订的维护合同,定期等
到现场对系统运行情况,主机运行情况,数据库系统情况进行检查
和维护。
, 客户新技术培训服务:为使客户技术人员能及时掌握最新技术,每
年组织客户进行技术学习。
, 现场诊断与客户回访:我公司启动心贴心客户服务计划,每年选一
批客户,由我公司领导组团对客户进行回访和现场系统诊断,对诊
断发现的问题跟踪解决。
, 客户端服务
(1)收集最终用户对系统的使用意见和建议;
(2)对最终用户进行操作指导;
(3)客户端故障判断和排除指导;
(4)单机版数据转入系统的操作指导和技术支持;
(5)服务方式以提供远程服务为主。
12.3. 应急维护方案及时间安排
系统在运行过程中一旦出现紧急重大问题,导致系统不能正常运行的情况下,就需要启动售后服务紧急预案,以保证业务经办的正常进行。 12.3.1. 应急预案目标
在一旦出现紧急情况下,需要启动应急预案的情况下,应急预案必须以保证业务经办正常运行为目标。
172
12.3.2. 应急预案保障
可依靠本地化力量提供更加全面可靠的应急响应服务能力,保障系统数据的高质量整理迁移和实施、维护服务。
12.3.3. 应急预案具体措施及时间安排
应急预案需要从社会保障卡管理系统、接口系统、数据交换平台等来考虑应急处理措施,在出现紧急重大问题的情况下,我公司会在最短时间内作出故障响应,第一时间由驻现场维护人员启动备份系统,同时将指派具有解决故障能力的软件工程师、数据库工程师以及硬件网络工程师组成的紧急服务小组解决问题。
173
12.3.4. 应急处理流程
接受故障报告
启动应急预案
应急处理小组
调派资深专家、用户
No解决故障
东软技术支持中心原厂家技术支持中心Yes
紧急事件处理报告
提交报告
应急行动结束
流程说明:
, 系统出现故障,我公司接受故障,并确定为紧急情况。 , 启动应急处理服务流程。
, 紧急情况处理小组的领导(由用户和我公司人员共同组成)立刻调派
我公司的资深专家和用户相关人员。首先尽最大可能收集事件相关信
息,确定事件类别、事件来源,保护证据,以便缩短应急响应时间。 , 根据收集的信息,紧急情况处理小组立刻采取措施抑制事件的影响进
一步扩大,限制潜在的损失与破坏。
174
, 根据实际情况,技术专家进行系统的恢复工作。
, 如果是系统故障,我公司保证2小时内解决问题,恢复故障系统。
, 如果项目组难以短时间内解决故障,及时申请公司技术支持中心派专
家,必要时申请相关软件厂家的技术专家到现场协助排除故障。
, 在问题得到解决、系统恢复工作后,回顾并整理该事件的各种相关信
息,尽可能地把所有情况记录到文档中,并完成《紧急事件处理结果
报告》。
, 提交《紧急事件处理结果报告》。
, 应急行动结束。
12.4. 维护期后服务方案
12.4.1. 为本项目提供长期服务和技术支持保证
我公司充分利用自身在软硬件集成和先进技术研发的综合优势,为用户提供长期免费的技术咨询。并在今后的系统升级、拓展方面给予用户最优惠、便捷的服务。在系统质保期后我公司承诺以最优惠的价格为用户提供最优的售后服务。 12.4.2. 系统维护服务方式
白金服务为您提供资深系统工程师现场派驻服务,负责为您提供白金服务的服务工程师,会定期为您做系统优化,不断对系统进行完善,在系统出现故障和问题时,会即时做故障判断和处理,如遇棘手问题,将增派专家级工程师现场服务;另将提供一年一度的专家级系统会诊服务。
金牌服务为您提供最快的响应,负责为您提供金牌服务的服务工程师,在接到您及其他用户同时的服务请求时,最先对您提出的服务请求进行响应。金牌服务提供了24小时内对服务请求进行响应的速度。
银牌服务为您提供较快的响应,服务工程师在接到您及其他用户同时的服务请求时,将判断所面临每一事件的优先级别,以便决定响应的顺序和响应方式,在判断中,您享有较高的优先级别。银牌服务提供了72小时(3日)内对服务
175
请求进行响应的速度。
12.4.2.1. 白金服务
, 被CALL服务
完全现场响应即时服务。
, 收费方式
以年为单位向用户提供。以签定服务合同的方式与用户合作。
收费方式:项目合同额度的10%,具体收费方式可根据服务的内容、人员类型、数量等因素另行商议。
12.4.2.2. 金牌服务
, 被CALL服务
电话请求记录,7日/每星期,24小时
座位电话响应,正常工作时间(8:30-17:30, 周一至周五)
与用户共同定义的响应时间
加急请求: 立即 -- 6小时内,电话响应 / 动身出发
紧急请求: 0 – 12小时内,电话响应 / 动身出发
一般请求: 0 – 24小时内,电话响应
服务内容:系统维护请求内容
, 收费方式
以年为单位向用户提供。以签定服务合同的方式与用户合作。
收费方式:项目合同额度的8%,具体收费方式可根据服务的内容、人员类型、数量等因素另行商议。
, 用户请求的分级
加急请求内容:与核心数据一体的产品,包括主服务器、安装在主服务器上的系统。
176
紧急请求内容:主要网络设备、经常使用的非主服务器上的系统。 一般请求内容:普通业务软件。
12.4.2.3. 银牌服务
, 被CALL服务
电话请求记录,正常工作时间(8:30-17:30, 周一至周五) 座位电话响应,正常工作时间(8:30-17:30, 周一至周五) 与用户共同定义的响应时间
加急请求: 12小时 – 24小时内,电话响应 / 动身出发 紧急请求: 24小时 – 48小时内,电话响应 / 动身出发 一般请求: 48小时 – 72小时内,电话响应
, 收费方式
以年为单位向用户提供。以签定服务合同的方式与用户合作。 收费方式:项目合同额度的5%,具体收费方式可根据服务的内容、人员类
型、数量等因素另行商议。
, 用户请求的分级
加急请求内容:与核心数据一体的产品,包括主服务器、安装在主服务器上
的数据库和系统。
紧急请求内容:主要网络设备、经常使用的非主服务器上的系统。 一般请求内容:普通业务软件。
177