项目管理者联盟 | 中国工程管理网 | 中国研发管理网 | 会员中心 | 资料库 | 论坛 | 博客 |
|
|
|
标题:软件项目Bug案例分析及防治举措
楼主
|
|
铁托 PMB:19794 省份:安徽省 行业:综合应用 注册:2006/4/30 |
软件项目Bug是软件产品没有达到预期设计目标,在软件内部存在的一种缺陷。在不影响用户和系统正常运行的情况下处于隐蔽状态,没有表现出来,当Bug发生运行错误时,对银行的影响主要表现在三个方面:一是影响正常的业务需求开发,有不少业务需求都是各个专业部门在争夺客户过程当中亟待开发投产的,一旦停下来,势必对业务发展造成大的影响;二是带有Bug软件造成的错误给银行带来烦恼,工作人员要为此付出大量的精力去处理客户的不满;三是受到影响的客户,一直在做着反面宣传,使银行的信誉会受到损失。本文总结分析以往软件项目研发工作中出现的Bug案例,同时提出防治措施与大家交流分享。 一、软件项目Bug案例分析training.mypm.net (一)软件项目Bug案例 1、软件设计Bug。在某版本投产后,发现零售项目的监控文件导入事后监控系统,由于文件没有排序导致运行时间很长,影响了事后监控系统的工作效率,造成业务人员无法正常操作交易。经过技术人员跟踪分析,造成该问题的原因是在系统设计时,设计人员只是关注了该零售项目主机处理功能的实现,遗漏了对其他系统的影响。 2、软件编码Bug。某版本投产后,营业网点反映某联机交易的反交易日志错误,导致账务横向不平。经过技术人员跟踪分析,原因是程序员在编码时,没有意识到程序之间的相互关联,忘记了对公共程序的修改,结果造成当柜员办理两笔相同金额的业务时,如果冲正其中一笔时,会同时将另一笔冲掉。 3、软件测试Bug。某版本投产后,网点柜员发现远期结售汇系统中一个展期交易,当贷方账号输入的不是基本结算账户时交易报错。经过技术人员跟踪分析,原因是测试人员在编制测试案例时,贷方账号输入时,只考虑基本结算账户,未考虑其他账户类型企业结算账户。 4、软件文档Bug。某版本投产后,网点发现国际卡柜面取款后网点报表双倍挂帐。经过技术人员跟踪分析,发现造成该问题的原因是投产使用的参照表模板中,将该取款交易分离代码记录方向为借方,错误的设置为贷方。 5、外包产品Bug。某一个外包软件产品投产后,出现了联机和批量效率都比较差的情况,导致部分联机交易几乎无法使用,批量时间过长,严重影响了网点的日常业务运营,因为系统的效率问题,导致无法继续在该产品上启用新的功能。 6、版本发布Bug。某版本投产后,柜员在操作某汇款交易时,发现该汇款交易没有授权处理,投产前该交易是有授权的。经过技术人员检查是由于程序人员修改完该程序后,提交了联调环境,忘记更新综合版本环境下该程序版本。项目经理圈子 7、投产方案Bug。在投产一个软件版本时,因技术人员在投产方案中,需要把参数表在版本控制表中的最后下载日期进行大小比较,把前者≥后者错误的写成了前者≤后者,造成投产当日整个上午某分行所有网点不能正常下载参数,无法正常营业。 8、沟通Bug。在某版本投产后,客户服务中心接到多起客户投诉,客户反映信yong卡中客户信息突然丢失。经过查找分析导致该问题由数据中心做客户信息批量清理时,由于该项目是会计部门负责,数据移植完毕只有零售部和信贷部参与结果验证,而负责银行卡的业务部门,因未提出过客户信息清理需求也就没有参加验证,结果造成所有持卡人的客户信息被清理掉。 (二)软件项目案例分析 通过以上案例,我们可以看到在软件项目研发过程中,出现的软件Bug是多种多样的,但分析造成这些软件Bug的原因,主要表现在如下几方面。项目管理培训 1、业务与技术需求讨论不充分,技术人员没有很好的全面识别需求内容,对要开发项目涉及的业务知识不熟悉,造成设计、编码时出现偏差。 2、技术人员由于对系统整体架构、各个应用系统之间关联缺乏深入的了解,造成设计遗漏或编码时修改了老问题,却出现了新问题。 3、程序员在编码时,没有严格执行编码规范,导致软件产品投产后,出现一些异常错误。 4、技术文档内容描述不细致、审核不足或没有对其修改的内容进行验证,造成程序员编码出错或投产后因Bug引发生产事件。 5、对程序代码白盒测试和静态自查不够,导致一些较容易发现的问题没有被及时发现,而是在投产后产生问题后才被发现。 6、由于受到业务知识、技术知识的限制,测试人员编写测试案例不全面,造成测试时一些很容易发现Bug没有被发现。 7、由于受测试环境、测试设备、测试时间等资源的影响,一些软件项目赶时间,没有得到充分的测试便急于投产。 8、版本发布流程存在缺陷或没有认真按流程处理,造成版本发布后存在问题。 9、由于一个大的软件系统,涉及到公司内部的各个研发部门,涉及到需求提出的相关业务部门,由于各部门更多的关注自己的事情,没有一个很好的沟通交流和协调问题流程,容易产生一些问题或对发现的问题相互扯皮,得不到及时的解决。 10、对外包产品在购买前压力测试不足,对其性能不能很好甄别,容易出现与现有系统不能很好的衔接。 11、内部管理方面。软件公司内部管理制度、管理流程和管理方法没有树立科学发展观,企业文化没有体现科技以人为本的思想,是造成软件Bug的直接原因。 12、员工技能培训不足,软件公司忙于软件项目的研发,没有建立员工培训机制,员工对银行新业务、新技术知识的充电补充不足,导致软件产品质量下降。 二、软件项目Bug防治举措 软件Bug并非没有银弹可以消除,加强项目管理和软件测试就是“灭虫”的有效手段。美国商务的国家标准技术研究所报告显示,如果通过强化项目管理和软件测试及早发现软件Bug并得以解决,可以减少1/3以上的损失。 (一)完善组织架构,建立项目管理办公室。 商业银行信息系统大集中以后,不论是自主研发,还是自主研发+外包及单纯的外包方式,每年都会伴随着本行业务的发展、外部相关部门的要求,产生很多软件项目,每一个项目都有自己的特点,同时项目之间具有相似的地方,这样一来就形成了多项目管理格局。因此要管好这些项目,就需要成立专门的机构项目管理办公室,有一些熟悉项目管理人员,专门从事本公司软件项目管理工作。在公司内部实现项目经理负责制度,实行项目成组管理和多项目组合管理。 项目成组管理是软件公司研发的多个项目之间并没有共同的联系,但项目本身类似,在技术实现、工作方法及所需人员等方面具有相似性,项目之间可以互相参照。其规则就是根据项目对企业管理和业务发展的重要程度和紧急程度,通过ABC方法,设置项目的优先级、项目类别、生命周期和项目应用技术。对软件研发不同阶段制定不同的操作流程,而不是定义那个职能部门去操作,这样做的好处表现在即使组织结构发生变化、人员流动,研发流程也不会遭到破坏。同样一个软件公司每天要处理大量的日常业务,处理这些日常业务只能维持企业的日常运转,如果不断有新的项目产生,就可以通过不同类型项目的组合来实现公司经营发展目标。 在同一时间内,公司可能会有很多项目需要完成,如何及时有效地同时管理好众多项目是项目管理的核心问题,多项目组合管理就是同时管理多个项目,在组织中协调所有项目的选择、评估、计划、控制等各项工作。 (二)建立健全软件研发制度和流程 制度和流程是保证软件公司正常运营的基石,在我们日常工作中,不难发现如下存在四个方面的问题:一是有关软件项目研发制度建立的不全面,没有根据公司实际情况制定一些更加细致的制度和操作流程;二是制定的一些制度太多的照搬一些理论方法,没有很好的与公司实际相结合,项目研发流程要么复杂,要么简单,可操作性比较差;三是制度和研发流程没有根据公司发展状况,技术人员的意见,及时的完善修改,影响正常工作效率;四是制定的制度很多,通过公司内部网络公布后,员工真正熟悉的不多,缺乏相应的培训学习机制;五是制度执行不到位。因此,软件公司应该做好如下几方面的工作。 1、建立易于理解、便于操作的各项规章制度。这就需要制度制定部门要善于倾听来自设计、编码、测试、支持推广等一线部门员工的意见,然后进行总结制定相应的制度,并组织大家再进行讨论,不能随便的就版布一个制度,让大家执行,这样结果往往不是很好。在制度建设中,要重点关注软件项目设计、程序编码、测试和投产几个环节制度建设,关注软件项目不同阶段接口的规范的设计,在日常工作中发现,很多软件Bug的发生通常产生在不同部门、不同工序、不同接口交接、传递中。 2、建立高效的研发流程。ISO9000定义流程是一组将输入转化为输出的相互关联或相互作用的活动。软件公司在建立流程时,要遵照认识流程、建立流程、优化流程、E化流程、运作流程的指导方针,针对自身内部资源、组织架构及面对的客户等,建立软件项目需求管理流程、设计开发流程、程序编码流程、测试管理流程、投产运行流程、项目管理、外包商管理等几个大方面,在每一个方面再细分出不同的流程,如需求受理流程、生产问题管理流程、版本管理流程、软件测试流程、功能点分析流程等。同时要善于总结,发现现在流程中存在的问题,不断的完善流程。在设计研发流程时,尽量实行产品研发的并行流程管理(并行工程1988年有美国国家防御分析研究所提出,后经过研发企业的应用,大幅缩短产品研发时间),也就是说把一个新项目分解为多个任务,同时交给不同的部门负责完成,但要注意不同部门的协调,在项目研发流程中加入控制,可以通过E化流程控制,通过公司内部办公网络系统,自行开发一些流程管理系统,可以起到很好的作用。 举例说明建立流程、E化流程、优化流程的重要性。某软件研发公司,在版本投产推广应用以后,对于生产问题起初是采用电话、内部邮件方式管理,问题少时,还能处理完成分行反馈的问题,问题多了很难及时处理,且难以统计分析数据,准确掌握生产问题状况,通过人工受理、转发、答复、统计等方式已经不能完成对全行网点有效支持,于是采用了Help Desk(简称HD)生产问题管理软件工具,生产问题E化后,分行网点直接登陆HD填写问题单提交,及时把生产问题通过HD反馈给技术支持部门,极大的提高了问题解决效率。但通过一段时间的运行后发现,一个生产问题与开发部门(三线岗)交流要经过受理岗、一线岗位、转二线岗、再转三线岗,三线岗答复完毕后转二线岗、二线岗处理完毕转一线岗、一线岗处理完毕转回问题反馈单位,再需要七步才能完成,答复问题也要连续填写多项内容、反转多个画面,花费在这些动作上的时间一个问题最少15分钟,流程处理环节太多、繁琐,直接影响了问题处理的效率,能否优化HD处理效率,经过大家一起讨论,取消三线岗、整合交易内容、去掉多余的处理环节,经过对HD多次的优化, HD生产问题管理系统效率得到了大幅度提高,不但减轻了一线人员工作负担,而且便于问题管理,奥卡姆剃刀在削剪HD繁琐处理流程过程中初显威力。 (三)提高软件项目运营管理水平 1、成立项目研发小组,发挥项目经理的作用。软件公司对实施的软件项目成立专门的项目研发小组,确立项目经理,根据项目的大小确定项目需要的开发人员、测试人员和业务人员,一起参与系统需求讨论、功能评审、参与系统的功能测试,做好相互之间的交流。由项目经理根据软件开发目标和原则,撰写项目开发计划、人员分工、项目目标和各阶段工作任务、保存项目过程中的相关文件和数据、召开有关项目讨论会等,协调解决项目研发过程中出现的问题。 2、确认软件项目的范围。就是要做好业务需求管理,业务与科技要建立良好的交流与合作关系。对于一个新的业务需求,业务人员要向技术人员详细讲解①业务部门撰写的需求说明书要准确、仔细,每一项业务如何处理,结果如何要详细说明;②讲解银行业务术语和业务流程;③业务与技术如对需求有争论时,要尽快对需求做出决策,尽快确定需求内容;④因政策、制度等原因发生需求变化应立即通知技术人员,并按照工作流程进行处理;⑤技术人员要参与业务需求制定,向业务人员讲解本行信息系统整体状况,做好需求分析说明那些需求可以实现,需求不能实现的原因,帮助业务人员撰写出高质量的业务需求说明书。 |
回复 | 引用 发表时间:2015/3/18 9:34:58 |
! 您尚未登录,不能回复主题。 现在 登录 注册 |
|