（工商管理专业论文）银行软件项目管理及质量控制.pdf

摘要 随着全球经济一体化的发展， 银行业务将会以更加多样化的形式 出现， 企业间的各种结算将会更加复杂和频繁， 银行业的竞争也越来 越多 地体现在运用新的科技手段之上。 怎样能将银行机构原有的计算 设备和网络系统进行改造和更新， 并建立一套更 加先进、 稳定而又具 有较大的 业务扩展空间的银行业务处理系统来满足当前及未来很长 一段时期内的业务需求， 提高工作效率是很多金融机构需要解决的当 务之急。 因为银行的企业性质， 决定了银行业对软件的依赖。 银行业的软 件素来以 高质量、 高可靠、 高安全、 高效率著称。 因此软件质量是银 行业最为关心的问题之一。 软件质量管理是建立在软件项目 管理的基础上， 它贯穿于软件开 发的各个阶段并且与软件项目 管理紧密相连。 它是对基于软件工程之 上的软件项目 开发流程的一个延伸和补充。 我们知道， 软件工程的提 出是为软件开发提出一个科学的定义和流程， 它使得软件开发变得更 加规范和有章可循; 软件质量控制则是以如何保证软件产品的质量作 为重点，以 提供品质可靠的软件产品作为根本目 标。 软件项目 管理着眼于按照软件工程标准下的软件项目开发的各 阶段。 软件项目 开发的一般流程包括需求分析、 系统整体设计、 系统 详细设计、 程序设计及编码、 软件测试 ( 单元测试、 集成测试) 等阶 段。每一个阶段都要按相应的标准来进行操作和管理。 软件质量管理从始至终存在于软件项目开发之中， 它主要包括以 下内容: 首先是从项目 立项时就要提出项目 的 质量指标， 并据此拟定 开发计划;在需求分析时应按照有利于提高软件质量的方法进行设 计，进入项目 设计阶段时，需要对本阶段产生的总体设计进行评审， 同时产生下一阶段 ( 程序设计)的开发编码规范;程序设计完成后， 应该按照此编码规范进行程序代码的审查; 综合测试后产生质量评价 表，对项目作一综合评价。 本文以软件项目 管理作为出发点， 遵循软件项目开发的流程， 研 究软件项目管理的过程和特点， 着重于软件质量体系建立的原理和方 法， 并且结合我行软件质量控制的项目一公司贷款审批系统的实施来 探讨银行软件项日质量控制的问题。 关键词:软件质量 项目软件工程 银行 贷款 ab s t r a c t wi t h t h e d e v e l o p m e n t o f t h e w o r l d e c o n o m y . t h e b a n k i n g s e r v i c e w i l l a p p e a r v a r i o u s f o r m s . s e t t l e m e n t b e t w e e n e n t e r p r i s e s w i l l b e c o m e m o r e c o m p l i c a t e d a n d fr e q u e n t l y . a n d t h e c o m p e t i t i o n b e t w e e n b a n k s w i l l f o c u s o n t h e u s e o f u p d a t e s c i e n c e a n d t e c h n o l o g y . h o w c o u l d w e u p d a t e t h e e x i s t i n g c o m p u t i n g e q u i p m e n t , a n d e s t a b l i s h a n e w a d v a n c e d s t a b l e a n d e x p a n d a b l e b a n k i n g s e r v i c e s y s t e m i s o u r m a j o r p r o b l e m . d e c i d e d b y t h e e n t e r p r i s e p r o p e rt y o f t h e b a n k , c o m p u t e r s o ft w a r e i s s e r i o u s n e e d e d . a s w e a l l k n o w n , t h e s o ft w a r e u s e d b y b a n k s i s m o r e s t a b l e s e c u r e a n d e f f i c i e n t . f o r t h i s r e a s o n t h e q u a l i t y o f t h e s o ft w a r e i s o n e o f t h e i m p o r t a n t p r o b l e m s t h a t t h e b a n k s n e e d t o f a c e u p . q u a l it y c o n t r o l o f t h e s o ft w a r e i s b a s e o n t h e m a n a g e m e n t o f s o ft w a r e i t e m s . i t c o m e s t h r o u g h a l l t h e p h a s e o f s o ft w a r e d e v e l o p m e n t . a n d it i s a l s o t h e s u p p l e m e n t o f s o ft w a r e d e v e l o p m e n t . w e k n o w t h a t s o ft w a r e p r o j e c t p r e s c r i b e t h e d e f i n it i o n a n d fl o w o f s o ft w a r e d e v e l o p i n g s c ie n t i f i c a l l y . i t m a k e s t h e s o ft w a r e d e v e l o p m e n t n o r m a t i v e l y . t h e m a i n p u r p o s e o f q u a l it y c o n t r o l o f t h e s o ft w a r e i s t h e s o ft w a r e s q u a l i t y . t h e m a n a g e m e n t o f s o ft w a r e i t e m i s a c c o r d i n g t o t h e p h a s e o f s o ft w a r e p r o j e c t d e v e l o p m e n t . s u c h a s r e q u i r e m e n t a n a ly s i s , w h o l e s y s t e m d e s ig n , d e t a i l e d s y s t e m d e s i g n , p r o g r a m d e s i g n , a n d s o ft w a r e t e s t i n g e t c . ma n a g e m e n t o f s o ft w a r e q u a l i t y a l w a y s e x i s t s in t h e s o ft w a r e d e v e l o p m e n t . i t i n c l u d e s t h e s e c o m p o n e n t s : f ir s t , p u t f o r w a r d t h e q u a l i t y t a r g e t a n d t h e p l a n ; s e c o n d , a t r e q u i r e m e n t a n a l y s i s p h a s e , d e s i g n m u s t b e a v a i l e d t h e s o ft w a r e q u a l i t y ; t h i r d , a t t h e d e s i g n i n g p h a s e , e v a l u a t e a n d e x a m t h e e n t i r e l y d e s i g n , a n d p u t f o r w a r d n e x t p h a s e s d e s ig n c r it e r i o n ; l a s t , e x a m t h e c o d e a c c o r d i n g t o p r e v i o u s c r i t e r i o n . a ft e r t h e f u l l t e s t , b r i n g f o r w a r d a f o r m o : t h e q u a l i t y e v a l u a t i n g . a n d m a k e a s u m m a r y e v a l u a t i n g o f t h e p r o j e c t . t h e a r t i c l e i s f o l l o w i n g t h i s c l u e : m a n a g e m e n t o f s o ft w a r e p r o j e c t , fl o w o f s o ft w a r e p r o j e c t d e v e l o p m e n t , c h a r a c t e r i s t i c a n d p r o c e s s o f m a n a g e m e n t o f s o ft w a r e p r o j e c t , e m p h a s i z e t h e p r i n c ip l e o f s o ft w a r e q u a l i t y s y s t e m , c o m b i n e w i t h t h e r e a l e x a m i n e a n d a p p r o v e s y s t e m o f e n t e r p r i s e l o a n . k e y wo r d s : s o f t w a r e q u a l i ty, i t e m, s o f t w a r e p r o j e c t , b a n k , l o a n 1 、前言 银行与软件 随着全球经济一体化的发展， 银行业务将会以更加多样化的形式 出现， 企业间的各种结算将会更加复杂和频繁， 银行业的竞争也越来 越多地体现在运用新的科技手段之上。 怎样能将银行机构原有的计算 设备和网络系统进行改造和更新， 并建立一套更加先进、 稳定而又具 有较大的 业务 扩展 空间的 银 行业 务处 理系 统 来满 足当 前 及未 来很长 一段时期内的业务需求， 提高工作效率是很多金融机构需要解决的当 务之急。 因为银行的企业性质， 决定了银行业对软件的依赖。 银行业的软 件素来以高质量、高可靠、 高安全、 高效率著称。因此软件质量是银 行业最为关心的问题之一。 银行软件研发的组织管理模式 面对银行对软件研发的大量需求， 目 前银行主要有两种组织项目 的模式:软件的自 主研发、软件的外包与分包。 软件自 主研发是指由总行统一组织开发或由各一级分行自行开 发的模式。 软件的外包与分包是指由银行指定软件规范， 然后将软件的部分 或全部内 容指定某软件开发商进行开发。 软件自 主研发的质量关键是组织大规模的软件开发队伍， 这同一 般的软件供应商在质量管理这一点上基本相同。 软件外包和分包的质 量关键是软件的规范制作、开发商的选择和软件开发结果质量的验 收。 软件质量管理 软件组织的最高管理层根据组织所面临的形势和社会需要， 制定 出较长时期内组织经营活动所要达到的质量目 标， 然后层层落实， 要 求下属各部门管理者以至每个员工根据上级制定的质量目标制定出 自己工作的质量目 标和相应的保证措施， 形成一个质量目 标体系， 并 把质量目标完成的情况作为各部门或个人工作绩效评定的依据。然 而， 企业的质量目的和任务必须转化成质量目 标， 各级管理者必须通 过质量目 标对下级进行领导并以 此来保证企业质量目 标的实现。 简言 之， 软件质量目 标管理就是通过组织的管理者和员工亲自 参与质量目 标的制定， 并在工作中实行“ 自 我控制” 以完成工作目 标的一种管理制 度或方法。 软件项目 质量管理不是简单的结果检查， 它是一套建立在质量管 理思想基础上的一整套体系， 它是贯穿于软件项目 实施的事前、 事中、 事后的整个过程。 本文将根据 r s 行软件项目 管理的特点，从软件质量控制必要性作 为出发点， 遵循软件项目 开发的流程， 着重探讨软件质量体系建立的 原理和方法， 并且结合我行软件质量控制的项目一公司贷款审批系统 的实施来探讨银行软件项目 质量控制的问题。 软件质量管理体系 软件开发项目 是智力密集型的项目， 其质量保证历来让人大伤脑 软件项目 的质量保证不像传统制造业的质量检查， 软件项目 大多 么筋 是投入巨资来实现一个特定的应用软件， 如果在工程即将竣工时再进 行质量检查与确认， 显然为时已晚。 所以， 决定软件质量的不仅仅是 人和技术， 过程控制被提到越来越突出的地位， 严谨的过程控制不仅 可以在每个阶段回顾和纠正项目的偏差， 识别项目 的风险甚至果断中 止项目 ， 而 且 可以 将人 才 流动所带 来的 不 利 影响 减 少 到 最小。 2 . 1 软件质量管理的属性 影响软件质量的因素可以分为两大类:( 1 ) 可以直接测度的因素 ( 例如， 每 个功能点 的 错误 ) 和 ( 2 ) 只能间 接测 度的因 素( 例如， 可用 性和可维护性) 。以下是对影响软件质量的主要因素的分类。这些软 件质量因素， 集中在软件产品的三个重要方面: 它的操作性、 它承受 改变的能力、以及对新环境的适应能力。 .对用户最为重要的质量属性 正确性与精确性排在质量因素的第一位， 如果软件运行不正确或 者不精确， 就会给用户造成不便甚至造成损失。 产品的正确与精确满 足用户最根本的需求。 可靠性是软件无故障执行一段时间的 概率。 衡量软件可靠性的方 法包括正确执行操作所占的比例， 在发现新缺陷之前系统运行的时间 长度和缺陷出 现的密度。 高质量的软件产品必须在功能上满足用户的需求， 并且能可靠和 稳定地执行。 随着对软件质量的要求愈来愈高， 有缺陷的软件给人们 带来越来越多的麻烦。 对于一个大系统而言， 任何一个局部的缺陷都 潜在地可能造成严重的问题。 系统变得日 益快速化、 复杂化、 自 动化， 因而也就越可能发生灾难性的事故， 而且这些事故潜在地具有更大的 破坏力。 效率是用来衡量系统如何优化处理器、磁盘空伺或通信带宽的。 在定义性能、能力和效率目 标时，考虑硬件的最小配置是很重要的。 灵活性表明了在产品中增加新功能时所需工作量的大小。 灵活性 对于通过一系列连续的发行版本， 并采用渐增型和重复型方式开发的 产品是很重要的。 安全性主要涉及: 防止非法访问系统功能、 防止数据丢失、 防止 病毒入侵并防止私人数据进入系统。 易用性是指用户感觉使用软件的难易程度。 你必须权衡易用性和 学习如何操纵产品的简易性。 .对开发者最为重要的属性 可维护性表明了在软件中纠正一个缺陷或做一次更改的简易程 度。 可维护性取决于理解软件、 更改软件和测试软件的简易程度， 可 维护性与灵活性密切相关。 可移植性是度量把一个软件从一种运行环境转移到另一种运行 环境中所花费的工作量。 可移植性对于工程的成功是不重要的， 对工 程的结果也无关紧要。 可以 移植的目 标必须陈述产品中可以 移植到其 它环境的那一部分，并确定相应的目 标环境。 可重用性从软件开发的长远目 标上看， 可重用性表面了一个软件 组件除了在最初开发的系统中使用之外， 还可以在其它应用程序中使 用的程度。 可测试性指的是测试软件组件或集成产品时查找缺陷的简易程 度。 如果产品中包含复杂的算法和逻辑， 或如果具有复杂的功能性的 相互关系，那么对于可测试性的设计就很重要。 .质量属性的取舍 用户和开发者必须确定那些属性比 其它属性更为重要， 并定出优 先级。 在他们作决策时， 要始终遵照那些优先级。 必须在性能代价和 你所提出的解决方案的预期利益之间做出权衡， 以确保做出合理的取 舍。 为了达到产品特性的最佳平衡， 你必须在需求获取阶段识别、 确 定相关的质量属性， 并且为之确定优先级。 当你为项目定义重要的质 量属性时， 不仅形成了制订质量计划的依据， 可以防止发生与目 标冲 突的行为口 例如: 重复使用的软件构件能普遍适用于多 种环境中， 因 此，不能达到特定的容错 ( 可靠性)或完整目 标。 在需求获取的过程中， 加入对质量属性期望的讨论， 并把你所了 解的写入软件需求规格说明中。 者满意的产品。 这样， 才有可能提供使所有项目 参与 2 . 2 产品质量控制的目 标和职责 软件质量管理目 标是建立软件产品生产环节中的质量控制管理 体系， 对产品生产周期内的全过程进行质量监控， 提高整体软件产品 质量， 促进产品开发健康有序进行。 主要任务是建立一套软件质量管理规范，制定软件质量控制标 准， 跟踪检测软件产品生产，同时通过产品的模拟运行测试来验证产 品质量，向 生产部门反馈产品性能、 质量和安全指标， 完成产品版本 控制，向运行部门提交上线产品内容。具体内容包括: 第一、建立产品质量责任制。 具体任务包括: .明确产品质量责任制 .建立质量控制管理组织 .逐步完善产品质量约束机制 第二、建立一套系统的、可操作的质量控制标准、步骤和方法 具体任务包括: . 制定 和 完 善 软 件 产品 生 产周 期内 的 质 量 管 理实 施 规 程 .推广已 制定的软件质量管理规程 .评审软件质量管理过程的实施情况 .制定提高和改进整体软件质量的计划和工具手段 第三、 建立一套相对完备的产品质量测试体系， 检测软件产品质 国 巨 软件测试是软件产品 质量控制的重要手段， 也是目 前开发项目中 广泛使用的质量保证工具，具体任务包括: 制定产品测试规范 完成产品综合测试，反馈产品质量、性能和安全方面的指标情 况 制定提高和改进测试效果的工具手段 第四、建立软件项目计划跟踪制度和标准执行监控机制，及时反 映质量标准执行情况 软件过程控制是软件质量控制的手段之，它包括审核软件项目 的各项工作，验证它们是否遵循相关的步骤和标准，并且将审核的结 果提供给项目人员及其他相关负责人。 第五、建立规范化的软件版本管理办法，保证软件版本的完整性 和一致性 制定和完善软件版本的内部管理 向生产运行部门提交经过测试的软件产品上线内容 2 3 整体质量管理 基于软件项目开发流程的特点和我们从事银行软件项目开发工作 的实践出发，我们更倡导软件的整体质量管理。软件整体质量管理包 含两方面的内容，首先是静态的概念，即建立一套完整的质量管理体 系，其中包括各种标准、规范和制度；第二是基于过程的动态的概念， 它涉及到从软件需求到软件上线这个过程中的一切事件，我们按事 前、事中、事后来划分成质量计划、质量控制、质量保证三个阶段。 如图1 所示： 质量计划编制 质量计划编制包括确认与项目有关的质量标准以及实现方式。将 质量标准纳入项目设计是质量计划编制的重要组成部分。对于一个i t 项目，质量标准可能包括允许系统升级、为系统计划一个合理的响应 时间、或确保产生一致的和准确的信息。质量标准也适用于信息技术 服务。例如，你可以运送一个保修硬件的部件应当多长时间。 质量保证 质量保证包括对整体项目绩效进行预先的评估以确保项目能够 满足相关的质量标准。质量保证过程不仅要对项目的最终结果负责， 而且还要对整个项目过程承担质量责任。高级管理层应带头强调全体 员工在质量保证活动中发挥作用，尤其是高级管理者要发挥作用。 质量控制 质量控制包括监控特定的项目结果，确保它们遵循了相关质量标 准。并识别提高整体质量的途径。这个过程常与质量管理所采用的工 具和技术密切相关。例如，帕累托图、质量控制图和统计抽样。 _ = 三 一、 型攀塑 一一一一一1 p ，一 i 图l 2 ，3 1 质量计划编制 质量计划编制是确保项目质量的第一步。计划编制暗示了预料形 势和准备采取产生希望结果的措施的能力。现代质量管理的要点是： 通过选择合适的材料、培训与教导人们的质量观念、计划一个确保产 生相应结果的过程，来预防缺陷。在项目质量的计划编制中，重要的 是确定每个独特项目的相关质量标准，把质量规划到项目的产品和管 理项目所涉及的过程之中。 计划编制还包括，以一种能理解的、完整的形式传达为确保质量 而采取的纠正措施。在项目的质量计划编制中，描述能够直接促成满 足客户需求的关键因素是重要的。关于质量的组织政策、特定的项目 范围说明书和产品描述、以及相关标准和准则都是质量计划编制过程 的重要输入。质量计划编制的重要输出是，质量管理计划和为确保整 个项目生命周期质量的各种检查表。以下是软件质量b t - j i z 编制必须考 虑的范围： ( 一) 目的和指标 本条必须指出该软件质量保证计划所针对的软件项目( 及其所属 的各个子项目) 的名称和用途，指出制定该计划的具体目的，还必须 提出项目要完成的质量指标，包括功能指标、性能指标、综合测试错 误率等。 ( 二) 机构组织 本条必须明确软件质量保证有关的机构的组成。在本软件系统整 个开发期间，需成立软件质量保证小组或指定质量保证人员负责质量 保证工作。软件质量保证小组或软件质量保证人员必须检查和督促本 计划的实施。 ( 三) 任务 本条必须描述计划所涉及的软件开发周期中有关阶段的任务，重 点描述这些阶段为完成各项质量指标所应进行的软件质量保证措施。 如：必要的业务培训和技术培训、制定项目组的开发规范、各阶段应 完成的各类文档及其管理、内部代玛审核、内部版本的管理、单元测 试及集成测试。 ( 四) 职责 本条必须指踢软件质量保证计划中规定的每一个任务的负责单 位或成员的责任。如：质量保证小组中，组长全面负责有关软件质量 保证的各项工作；项目的专职质量保证人员协助组长开展各项软件质 量保证活动，负责审查所采用的质量保证工具、技术和方法，并负责 汇总、维护和保存有关软件质量保证活动的各项记录。 c 五) 评审和检查 规定开发周期中所必须要进行的技术和管理两方面的评审和检 查工作。阶段评审 ( 总体设计) 、日常检查 ( 周报、质量抽查) 、软件 验收 ( 代码审核、综合测试) 。 ( 六)工具、技术和方法 若在开发周期中使用了支持该软件项目 质量保证工作的工具、 技 术和方法，必须指出它们的目的，描述它们的 用途。 项目 范围的这些方面仅仅是几个与质量计划编制有关的需求问 题。 项目 组在确定项目 的质量目标和编制计划时， 需要考虑所有这些 项目 范围问题。 项目 的主要客户也必须意识到他们在定义项目 最关键 的质量需要中的作用， 并经常把他们的需要和期望与项目团队进行沟 通。 2 .3 .2 质量控制 软件项目的整体质量管理中最重要的环节就是在开发过程中的 质量控制， 它既包括系统实现时的 质量控制， 也包括系统分析、 系统 设计时的质量控制; 包括对系统实现时软件的质量控制: 还包括对文 档、开发人员和用户培训的质量控制。如图2 所示 图2 2 . 3 . 3 质量保证 制定一项计划确保一个项目 的质量是一回事， 确保实际 交付高质 量的产品和服务则是另一回事。 质量保证包括与满足是一个项目 相关 的质量标准有关的所有活动。 质量保证的另一个目 标是不断地质量改 进。 质量保证涉及到软件开发过程的各个方面， 结合到本部门 运用的 实际，我们认为，综合测试与软件版本管理是尤为关键的两个环节。 综合测试分为项目 集成测试和项目 综合测试两个阶段。 集成测试 主要是在项目开发阶段完成了内部单元测试后， 项目 组内部将系统连 接成为一个整体后的测试。 它的主要目的是发现系统各个单元的联结 问题及系统功能性问题。 综合测试系主要由业务人员按系统需求来完 成整体应完成业务功能性的测试。 测试是质量保证的重要手段。 任何系统在完成开发阶段后都或多 或少存在一些问题，良好的测试能为系统提供一道屏障， 以此发现并 处理在开发过程中未解决的问题口 软件版本管理对于软件开发、 系统上线及、 系统运行维护及系统 的更新升级都至关重要。 进行软件开发的人员， 或许都经历过由于软 件管理无序给项目 开发带来的不良 影响， 甚至是灾难性的后果。 例如: 不同人对同一程序进行修改， 由于没有进行版本管理， 会造成后修改 的程序将开始修改的程序进行覆盖的情况; 系统上线到生产上的程序 并非最新的程序， 诸如此类， 举不胜举。 版本管理可包含程序、开发 文档、 开发规范及与项目 相关的各类文档， 可采用有关软件工具来进 行管理。 2 .4 软件质量管理流程 2 .4 . 1 流程概述 软件质量管理贯穿于软件项目 开发的各个阶段， 首先是从项目 立 项时就要提出项目的质量指标， 并据此拟定开发计划; 在需求分析时 应按照有利于 提高软件质量的方法进行设计; 进入项目 设计阶段时， 需要对本阶段产生的总体设计进行评审， 同时产生下一阶段 ( 程序设 计)的开发编码规范。 程序设计完成后， 应该按照此编码规范进行程 序代码的审查;综合测试后产生质量评价表，对项目 作一综合评价; 版本管理是对程序代码进行的管理。 2 .4 .2 质量保证计划 项目 负责人应在 开发计划中提出产品质量目 标和保证计划， 在完成项目 总结报告时对产品实现质量目 标的情况进行评价。 在计划书中应明 确软件质量保证由有关的机构的组成。 在本软件 系统整个开发期间， 需成立软件质量保证小组或指定质量保证人员负 责质量保证工作。 软件质量保证小组或软件质量保证人员必须检查和 督促本计划的实施。 计划书的主要内容应该是涉及软件开发周期中有关阶段的任务， 重点 描述 这些阶 段为 完成 各 项质 鼻指标所应 进行的 软 件质 量保证措 施。 如; 必要的业务培训和技术培训、 制定项目 组的开发规范、 各阶 段应完成的各类文档及其管理、内部代码审核、内部版本的管理 单 元测试、集成测试等等。 在计划书中还应指明软件质量保证计划中规定的每一个任务的 负责单位或成员的责任。 如: 质量保证小组中， 组长全面负责有关软 件质量保证的各项工作; 项目的专职质量保证人员协助组长开展各项 软件质量保证活动，负责审查所采用的质量保证工具、技术和方法， 并负责汇总、维护和保存有关软件质量保证活动的各项记录。 3 . “ 公司贷款审批系统” 的应用背景 3 . 1 背景分析 为了保持对公信贷业务稳定持续发展， 防范多头贷款风险 和超授 权经营风险，降低经营成本， 建立我行对公信贷业务申 请、 审批、 发 放流程的管理控制系统， 我行于今年重点实施了“ 公司贷款审批系统” 的设计和实现。 作为重要的业务系统， 我们按照软件质量管理体系作 了严格的控制。以下是本系统的产生背景。 ( 一)为有效遏止多头授信现象的产生，防范贷款风险 多头授信是指我行两个或两个以上分支机构对同一客户提供贷 款或其他信用支持。 多头授信现象使我行对客户的整体经营状况难以 进行准确的把握， 客户的整体风险难以判断， 增大了 我行的经营风险。 同时， 多头授信也不符合 贷款通则 第四章第二十条关于借款人“ 不 得在一个贷款人同一辖区内的两个或两个以 上同级分支机构取得贷 款”的规定。 近年来接连发生的蓝田股份、 “ 上海首富”周正毅案，都曾因为 集团客户的“ 多头贷款” 而让商业银行面临巨大贷款风险。 据一位供 职于某国有商业银行风险管理部的专家介绍， 目 前关联企业集团是商 业银行当前面临的最大谜团。 仅以周正毅案为例， 周所控制的“ 农凯 系”关联公司就达4 0 家左右，在周事发后，位于上海的多家银行总 计大约 6 0 亿元贷款突然悬空，银行要想全部收回贷款几乎不可能。 更有专家预计， 周正毅案很可能只是集团客户利用关联公司过度贷款 的冰山一角，还没有暴露的巨大风险仍在迅速累积。 为了防范商业银行给集团客户多头授信、过度授信形成的风险， 银监会即将出台强化风险管理的 商业银行集团客户授信业务风险管 理指引 。银监会人士表示，即将出台的 指引 ， 正是针对集团客户 组织结构复杂， 信用状况参差不齐， 给商业银行信贷管理带来很大风 险等问题而制定的。 指引将引导商业银行从人员、组织机构和业 务运作上构建与集团客户授信业务风险管理特点相适应的信贷管理 机制， 从机制上保证商业银行加强对有信贷关系的集团客户信息的追 踪收集、 授信额度的控制、 授信的管理、 风险的预警和对集团客户授 信行为的监督检查; 引导商业银行在全系统建立健全信贷管理信息系 统， 并建立与之相适应的运行机制， 加强集团客户有关信息的收集和 传递， 加强商业银行之间的合作和商业银行与社会咨询机构之间的合 作。 同时， 加强对商业银行集团客户授信行为的监管和加强对集团客 户授信的信息服务。 近 年 来， 省分 行 在 不同 场 合强 调防 止多 头 授 信 产生， 两 次 对多 头 授信进行了较全面的检查、 督促、 ， 整改， 从两次清理效果来看，原有 的多头授信部分已 纠正， 但是随着我行信贷体制变化， 新的多头授信 又有抬头趋势， 难以 得到较为彻底的杜绝。 所以急需一套新的系统来 支撑控制多头授信的功能。 ( 二)为加强对授权授信管理，避免分支行违规发放信贷业务 目 前， 现有信贷管理已得到较大的加强， 各行违轨发放办理信贷 业务的现象己 较少发生。 但是，由于各行管理水平和信息沟通存在一 定的差异， 也存在超授权超授信发放办理信贷业务的现象。 现有的人 工检查监督机制是事后监督， 在时效上难以保证对超授权超授信发放 信贷业务的事前控制，从根本上避免违规现象的发生。 ( 三)为拓宽信息沟通和共享渠道，实现监控的实时性 现有的贷款管理系统各行只能查询本行的贷款客户信息， 不能实 现对其他行的查询， 各支行客户经理难以 对客户在我行的全貌有更深 的了解， 我行收集的客户资料未能得到充分的共享。同时， 现有的行 查系统和贷款管理系统提供的数据分别有2 天和 1 0 天的滞后期，随 着管理力度的加大，实现信贷监控的实时化有重要意义。 综上所述， 建立对公贷款审批控制系统十分必要。 通过这套系统 能够建立对现有全部对公贷款客户的监控， 解决目 前难以实现的事前 控制、 集团客户监控等诸多问题。 能够建立信贷审批流程的数据化管 理模式， 通过设置授信和授权的控制参数， 有效的将超授信授权信贷 业务 拒之门 外，同 时提高了 审批的效率， 提高了 我 行资 源利用效率， 有利于加强我行的竞争能力。 3 . 2 系统目标及主要功能 ( 一)业务目 标 建立我行对公信贷业务申 请、 审批、 发放的系统控制流程， 在各 支行与省分行信贷管理部门间建立信贷申请和审批的系统控制流程。 基层行信贷人员通过方便的浏览器方式录入信贷申 请资料， 管理部门 根据申请资料进行审核， 省分行审批部、房信部、 公司业务部可以实 时进行监控。 系统将所有客户的基本资料、 贷款基本资料归集在一起， 对每个客户的 贷款基本信息进行统计， 根据系统统一设定的审批检查 流程和授信、 授权控制参数进行检查和区分， 避免各支行发放多头贷 款， 同时根据客户情况、申 请贷款情况、 各行的贷款审批权限等情况 自 动将贷款申请信息传送到有关有权审查审批部门。 同时， 将信贷管 理系统和会计系统通过接口 进行连接， 控制贷款开户， 并能访问到最 新贷款台帐。 ( 二)系统 应 用范围 本系统使用范围 主要包括: 各分支行对公客户经理、 各支行信委 办、 各分支行行领导、 省分行公司 业务部、 房地产金融业务部、 信贷 审批部、风险管理部。 ( 三)系统主要功能 本系统功能包括客户信息维护、 信贷申 请、复核、审批 ( 分为支 行审批和省分行审批) 、审查 ( 公司部和房信部) 、 贷款开户、 辅助功 能、系统管理、系统查询等功能。 3 .3 质量控制计划 ( 一) 、项目 质量保证总体目 标: 1 、完成需求说明书中的功能，如有需求变更，以最后需求为准 2 、综合测试每万行源代码平均程序错数在2 0 个以下达到a级 3 、有较好的 操作性 ( 二) 、机构组织 由 质量保证科室为项目 设置专职质量保证人员， 并由 项目 经理协 助其工作。 主要职责: 开展软件质量保证的各项工作， 审查所采用的质量保 证工具、技术和方法。 ( 三) 、项目 实施过程中各阶段的质量保证计划: 1 , 需求分析阶段:确定需求的范围、合理性、迫切性和可行 性，与业务部门一起讨论并编写出需求分析说明书。 2 、设计阶段:根据 软件开发文档规范进行总体设计和详 细设计并组织评审。 3 、编码阶段:根据 软件开发编码规范规范编码过程和行 为。开发人员根据编码审查表审查代码，各组负责人负责抽查 代码，与开发人员交流单元测试结果，保证单元测试质量。 4 . a !1 试阶段:制定集成测试方案和综合测试方案，反复进行 模拟生产周期的完整测试，记录测试情况。并对综合测试各阶 段的测试结果进行统计，对产品的测试结果进行评估，整理出 产品上线清单， 完善上线安装手册。 完成技术手册和操作手册。 ( 四)职责 1 、项目 负责人负责督促本组成员遵循质量控制的要求进行软 件开发;抽查本组成员代码质量;负责与本组成员交流单元测 试情况，保证单元测试结果;负责制定本组集成测试方案并组 织实施; 2 、版本管理员:负责项目 组版本管理，包括源码和各类文档 3 、开发人员:负责按照详细设计、编码规范和代码审查表要 求进行编码;负责单元测试并保证单元测试质量;负责相关文 档编写; 4 、质量控制人员:监督并执行软件质量保证的各项工作。 ( 五)评审核检查 1 、 总体设计提交中心进行设计评审 2 、代码审查 3 、 综合测试 ( 六)工具、技术和方法 1 、版本管理工具: s o u r c e s a f e 4 . 需求分析 4 . 1 为什么要进行需求分析? 软件工程中包含需求、设计、编码和测试四个阶段， 其中需求工 程是软件工程第一个也是很重要的一个阶段。 软件需求是整个软件项 目的最关键的一个输入， 和传统的生产企业相比较， 软件的需求具有 模糊性、 不确定性、变化性和主观性的特点， 他不像生产汽车、电脑 等硬件的需求， 是有形的、客观的、 可描述的、 可检测的，软件需求 是软件项目 最难把握的问题，他的复杂性体现在以下方面: 第一:需求的完备程度问题 需求如何做到没有遗漏?如何准确划定系统的范围?这确实是 一个两难问题， 稍微大一点的系统要想穷举需求几乎是不可能的， 每 次开需求评审会时， 总会冒出新的需求， 以至于系统没有一个准确的 范围界定。 即使是这样， 系统还是要开发， 系统的范围还要硬性的划 定一个，从而建立一个基线。 第二:需求开发的工期问题 为了确保需求的正确性， 完备性， 项目 经理往往坚持要在需求阶 段花费大量的时间， 但是客户与公司的高层领导却会为项目 迟迟看不 到实际可运行的软件担心不己! 他们往往会逼迫项目组尽快往前推 进， 而项目 组的成员往往也会为系统复杂的善变的需求折腾的筋疲力 尽，他们也希望尽快结束此阶段。 第三:需求的细致程度问题 需求到底描述到多细，才算可以结束了? 仁者见仁，智者见智， 并没有定论， 如果时间允许， 要想细总可以细下去的。 但是，需求的 周期越长， 可能的变化越多， 对设计的限制越严格， 对需求的共性提 取要求越高， 所以 只要大家( 客户、 用户、 需求分析人员、 设计人员、 测试人员)认为描述清楚了，就可以 进入设计阶段了。 第四:需求的变化问题 在软件开发过程中如果只有一条真理的话， 那一定是: 需求的变 化是永恒的， 需求不可能是完备的。 软件开发的过程实际上是同变化 做斗争的过程。 一旦发生了需求变化， 你不得不来修改你的设计、 重 写你的代码、 修改你的测试用例、 调整你的项目 计划等等， 需求的变 化好比是万恶之源， 为项目的正常的进展带来不尽的麻烦， 怎么办? 管理它! 使需求在受控的状态下发生变化， 而不是随意变化， 需求管 理就是要按照标准的流程来控制需求的变化。 第五:软件需求的复用问题 没有对需求进行有效的管理， 己 经形成的需求文档没有很好的复 用。所以需求管理一个很重要的目 标应是提高软件需求的复用率。 基于上述的问题， 必须对需求进行管理， 使需求能够真正成为软 件工程和管理的基线， 使软件计划、 活动和工作产品同软件需求保持 一致，使需求可以复用。 4 . 2 需求分析如何管理? 需 求开 发的 结果 应该 有 项目 视图 和 范围 文 档、 使 用实 例 文 档、 软 件需求规格说明及相关分析模型。 经评审批准， 这些文档就定义了开 发工作的需求基线。 这个基线在客户和开发人员之间就构筑了 计划产 品功能需求和非功能需求的一个约定。 需求约定是需求开发和需求管 理之间的桥梁， 需求管理包括在工程进展过程中维持需求约定集成性 和精确性的所有活动，见图3 : 央泛 校州 . 理以侧廷 * 分析形响 * 作 出决黄 . 空泥 幸 台井 一“ 79# * x tk 段本脸州 1 确理百农又 - 档陷* . .定草个祠 术文性版本 蔺求旅甘 举 足又用蕊悦而求 的准 该 砧 . 定义对拼 艳草俄 元欢的健怕性 铂* 执恋 雄林 . 定又翻术状班 * 报斗礴京倪个 状奋 图 3 必须与需求工程的其它活动紧密整合 谈需求管理一定不能脱离需求工程。 从完整意义上讲， 需求工程 包括了需求获取、 需求分析、 需求描述、需求验证、需求管理。 狭义 上， 需求管理关心的是需求管理过程的建立， 在企业或项目 组中需要 有一套规范的需求管理过程。 而实际上从项目 经理的角度上看， 可能 还有5 0 % 甚至更多的精力是用于关注结果的， 所以 对需求内容的管理 与对需求形式的管理是密不可分的。 第一:需求必须是文档化的、 正确的、 最新的、 可管理的、 可理 解的 需求必须有文档来记录，该文档必须是正确的，是经过验证的， 是在受控的状态下变更的。而很多开发人员往往会问:“ 简单的系统 就不用写需求了吧?”很多需求在提出者看来是理所当然的， 却被开 发人员全部忽略了。 其实简单的系统未必简单， 只有想清楚、 写清楚、 说清楚才说明已经真正把需求整理清楚了。 第二:只要需求变化了，需求变更的影响就必须被评估 无论需求变化的程度如何， 只要需求变化了 就必须进行评估， 这 是基本的原则。 此外， 在一个项目 组中必须明确定义一个需求管理员， 由 他负责整个项目的需求管理工作， 确保在发生需求变更时， 受影响 的产品能得到修改并与需求的变更保持一致， 受影响的其它组也必须 与客户协商一致。 第三:需求必须分优先级 需求的优先级可能比需求本身更加重 要 在每一次产品开发过程中， 都会遇到这样一个问 题: 负责产品需 求的领域专家罗列了长长的功能列表，每个功能似乎都是不可或缺 的， 而当排出进度表后， 却发现工期是公司不能接受的，没办法， 必 须裁剪需求。 没有需求就不会有产品， 而没有产品就没有利润。 如果 需求过多， 反而可能是陷阱只有投入， 没有产出。 一个好的项目 需求，必须有需求的优先级，便于进行项目的整体平衡。 第四:需求一定要分类版本管理 在做工程项目的时候一定要将需求分出层次， 不同层次的需求侧 重点是不一样的， 描述的方式是不同的， 管理的方式也是不同的。 维 护需求变更的历史记录记录变更需求文档版本的日期以及所做的变 更、 原因， 还包括由 谁负责更新和更新的新版本号等。 版本控制是管 理需求的一个必要方面。 需求文档的每一个版本必须被统一确定。 组 内每个成员必须能够得到需求的当前版本， 必须清楚地将变更写成文 档， 并及时通知到项目 开发所涉及的人员。 为了尽量减少困惑、 冲突、 误传， 应仅允许指定的人来更新需求。 这些策略适用于所有关键项目 文档。 第五:需求跟踪 跟踪所有受需求变更影响的工作产品当进行某项需求变更时， 参 照需求跟踪能力矩阵找到相关的其它需求、 设计模板、 源代码和测试 用例， 这些相关部分可能也需要修改。 这样能减少因疏忽而不得不变 更产品的机会，这种变更在变更需求的情况下是必须进行的。 4 . 3 公司贷款审批系统的需求分析 4 .3 . 1 系统需求分析简介 软件需求说明书作为需求分析的结果性文档， 是为了 使用户和软 件开发者双方对该软件的初始规定有一个共同的理解， 使之成为整个 项目 开发工作的基础，供项目 开发组和用户使用。 公司贷款审批系统的软件需求说明书主要内容包括系统立项背 景、 系统目 标、 系统功能详述等， 其中功能描述所占 篇幅最大。以下 介绍系统涉及的几个关键名词， 有助于我们对系统的深入理解: 信贷授权: 指省分行对分支行转授的信贷业务