敏捷开发在大型核心银行系统中的应用,本文是敏捷开发有关硕士论文范文与敏捷开发和银行和核心类论文范例.
敏捷开发论文参考文献：
核心银行系统一直是银行信息系统中逻辑最复杂、开发难度最大和影响范围最广的系统,同时也是模块化和参数化要求最高的系统.随着银行业竞争加剧、金融产品的不断创新以及海外业务系统整合加速,核心银行系统涵盖的业务功能越来越多,系统的应用架构也越来越复杂,开发难度逐年递增.如何降低复杂度和耦合度,提升开发效率和减少产需矛盾,是摆在银行核心系统开发人员面前重要且迫切的问题.最近三年来,中国银行软件中心开发团队一直在学习和吸收敏捷开发中的最佳实践成果.我们发现,一些诸如SCRUM 等迭代式增量软件开发过程难以适应当前大型主机的结构化编程方式,这是由于大型系统的结构化编程更加注重应用架构和模块的复用,导致很难适应频繁的变化.然而,敏捷开发中的测试驱动开发（TDD）、结对编程、持续集成等最佳实践却能给团队的开发活动在效率提升和质量提升上带来很多惊喜,敏捷开发的主旨和方法能够帮助我们解决很多大型系统开发中的不确定因素.
在开发过程中,我们不断开展结对编程、测试驱动开发（TDD）的实践和推广,并在大批次开发期间深入开展了新工艺方法及敏捷开发中的“持续集成”开发实践,取得了显著成果.原定封闭目标为模块开发任务完成率达到70%,实际完成率为96.4%,且在短短一个月内完成10 万余个单元测试案例,圆满完成封闭目标任务.在本批次的开发中,团队面临了需求数量多、改造工作量巨大、需求间关联性强、人员变动频繁、新员工及新引入外援多等重重困难.如何将强耦合的代码切分为每个人的工作任务？如何确定每个人的工作完成标准？如何进行经验传受？如何避免大规模协同开发中的相互影响？如何保障新功能的开发不影响原有功能？如何并行开发提高效率？如何将缺陷的发现前移以降低风险？团队基于前期已完善的测试驱动开发方法（TDD）,大胆创新出主机系统下的“持续集成”开发流程,同时参考敏捷开发的管理思想,编制了燃尽图,对任务进行跟踪,不但有效保障了开发质量,还极大提高了开发效率.
一、“持续集成”开发方法的实践
1. 为什么要采取“持续集成”的开发方式
众所周知,当开发规模扩大到一定程度后,协同开发的难度会呈几何级数的增加.因为模块的功能之间、需求之间的影响及开发的不同步会极大地降低开发效率.集成整个产品的代码是一项非常复杂的工作.当程序最开始的模块出现BUG,会导致后续模块均处于等待验证的状态,而任何一项BUG 的修正可能会毁掉之前的大部分测试成果.解决这一问题的最好途径是采取划清边界、小步前进的方式来降低复杂度.在复杂度极高的当前批次的开发中,如果仍然采取原来瀑布式开发模式,先编完所有代码再开始内部测试.复杂的公共模块面临着简单模块的各种缺陷导致的无法被驱动的窘境.这种情况下,团队采取“持续集成”的开发方式很好地解决了这一问题.
2.“持续集成”的应用
“持续集成”比较通俗的说法就是提供一个持续可测试验证的集成环境.一天完成两三次程序编译,让开发人员一边编码一边测试验证.很多人经常将“持续集成”等同于“自动构建”,而我们认为,“持续集成”的目标应该是持续的测试验证.那么,按软件中心要求,编码完成后要做的是单元测试.一边编码一边做单元测试的瓶颈,一方面是并行开发的相互影响会导致测试环境遭到持续性破坏; 另一方面,开发环境中的开发缺陷会导致数据库数据不完整,降低测试的效率.对于核心系统的结构化编程方式来说,编译一个程序且调用起来,并不需要太多的步骤,因此在持续集成开发方法下,提供一套快速的自动化单元测试工具,保证持续进行“单元测试”环境的意义要远大于反复构建一个可持续进行“验收测试”的集成环境.基于这样的思路,团队将“持续集成”基础建设的重点放在了使用测试驱动开发方法（TDD）和研发“自动化单元测试工具”上.三年前团队就开始自主研发“COBOL 自动化测试平台”,之后经过持续的改进优化,逐步形成了一个集成了案例管理、自动化生成测试代码、报告单、问题单管理及数据自动备份等功能的自动化测试框架.在本批次开发过程中,我们首先在很短时间内构建了一个持续集成环境,类似于根据验收测试驱动开发(ATDD) 的成果构建了一个可运行的当前批次的DEMO.然后持续地在这个集成环境添加我们的模块,团队要求使用“COBOL 自动化单元测试工具”验证所添加模块的所有功能后,才能添加下一个模块.在TDD 建立的基线下,团队每天不断集成增量的模块代码到集成环境,始终保持当前环境是可测试的,并快速地进行自动化测试,再迭代集成下一个模块的代码,从而保证了只要是进入到集成环境的代码,都是通过了测试验证的代码,而不是将BUG 留到全部代码都集成后再去解决.“持续集成”的开发流程如图1 所示.
3.“持续集成”的优势
“持续集成”的关键作用在于持续可验证性.团队利用前期一直在实践的TDD 方法和自主研发的“COBOL自动化单元测试工具”完美演绎了这一过程.“COBOL自动化单元测试工具”要求测试分析中包含模块的设置点、输入值和预期结果等.设置点和输入值模拟了模块所有输入数据来源可能出现的各种场景,模块间的耦合关系因此被完全解构.当待验模块的输入必须依赖其他未开发完的模块输出时, 我们就可以用设置点和输入值来模拟其他模块的返回数据,达到“桩模块”的效果.从而使团队的开发不再受开发顺序的限制,变串行测试为并行测试.同时,在并行测试中,不同测试人的测试案例对于数据输入的要求是不同的,因此测试代码还需要针对不同的测试人或案例对输入值进行隔离.“COBOL 自动化单元测试平台”提供了柜员级和案例级的隔离功能,使七十多人的开发队伍同时进行持续集成的开发及测试工作却不会互相影响,保证了随时集成进来的代码能够立即测试,也保证了所有人的测试验证工作均能够并发执行.持续集成的开发方式让每个集成的模块都经过案例全覆盖验证,保障集成环境不会被不断注入的缺陷所破坏.
正因为有了先进的以模块为测试目标的测试方法,使得开发部门新员工和外援发挥出极大的作用.我们现在采取的“持续集成”开发方式,如同将一台复杂的机器解构为无数的小零件,按规格完成各个简单的零件,每完成一个零件就实时拼装上去,检查零件是否满足标准.因此缺陷总能及时得以发现并纠正,如图2 所示.
4. 燃尽图在“持续集成”中的效果
在大规模的开发项目中,如何均衡分配工作、调配资源、跟踪完成情况以及在过程中的监督与激励都是非常复杂的问题.对于软件开发的活动,所有问题都集中在如何准确地衡量任务的工作量.因为在编码前我们并不知道代码行数,代码所覆盖的逻辑也无法量化.我们在当前批次中使用了敏捷开发中一项重要实践：测试驱动开发（TDD）.该项实践要求团队在编码前提供代码对应的测试用例.测试用例既是用于验证成果的标准,又是团队的设计文档.团队可以使用测试用例数来衡量每个开发人员的工作量.同时,团队也使用了敏捷开发中的另一工具：燃尽图.当前批次中团队共完成851 个程序模块,每个模块都有对应的预估案例数,每个开发人员会每天更新自己已完成的案例数.跟踪工具会自动根据这些数据生成个人、开发组和全团队的燃尽图及下周的计划完成数.燃尽图的跟踪方法让每个开发人员知道自己每天应完成的工作量以及小组和团队任务完成的进度,这极大地激发了开发人员的主观能动性.在图3 中可以看到,前6 个集成小批次我们没有使用燃尽图跟踪,完成的速率非常缓慢,进入封闭开发后,第7 批次开始使用燃尽图进行跟踪,出现了令人振奋的加速现象.原定完成70% 开发任务的封闭开发目标已被我们远远赶超.封闭开发结束时,测试用例完成率达到96.4%.
二、“持续集成”的基础建设
1.“持续集成”依赖于TDD
TDD 是敏捷开发中一项核心实践和技术,也是一种设计方法论.在传统的开发活动中,开发人员习惯于先实现一个功能,再去调用它进行测试.而TDD 要求先确定如何使用,再去实现.编码前几乎将所有编码时会遇到的问题以测试用例推演的方式加以明晰,再开始编码.编码完成后,用设计阶段推演的测试用例进行验证,既保证了开发人员在编码前对模块功能的理解清晰无误,又保证了每一个设计都能得到验证,避免了很多弯路.将“确定如何使用”这一过程提前到编码之前,让每个开发人员心中都有一个完整的目标产品原型,这就是我们实践TDD 开发方法的初衷.
2.TDD 依赖于自动化测试工具
TDD 的开发方法并不是简单地将测试分析工作前移到编码之前就能称之为敏捷的TDD 方法.TDD 方法其中一个核心要求就是先写测试代码再写产品代码.但是,如果写测试代码耗费的时间过多,则会使开发效率大幅度下降.没有高效,谈何敏捷！三年前,我们开始打造自主开发的“COBOL 自动化单元测试平台”,用于支持TDD 开发流程.该平台的核心功能是将团队在设计阶段的测试用例分析结果直接转换为可执行的测试代码.一方面,团队创新了COBOL 程序的产品代码和测试代码分离的技术,将测试代码分离为可随时装载和卸载的部件；另一方面,我们参考了业内对单元测试的标准定义——“写测试”( 即编写测试程序来检验产品代码,由程序自动判断结果是否满足预期),开发出能够自动生成测试代码的“自动化测试平台”.在本批次的开发中,一共生成8920 个测试用例的测试代码,通过自动测试发现编码缺陷312 个.从三年前由开发人员手工编写测试代码,到当前批次由工具自动生成测试代码,团队的开发效率得到极大的提高.自动生成的测试代码如图4 所示.
3. 测试用例的复用是TDD 的必要能力
说到自动化测试,就必然会谈到测试用例的复用.业界大多数自动化测试软件所提供的功能仅仅是一个交易发起模拟工具,根据产品发布的接口,在不具备客户端的情况下快速驱动交易进行测试.然而,对于复杂的产品应用系统,大部分的测试准备数据来源于表数据的读取,显然无法满足测试案例的复用要求.例如：当我们要测试贷款产品的透支账户还款交易,必须要先经历建立贷款额度、透支额度、贷款*和透支存款*以及放款、跑批结息等等交易流程才能准备好所需要的测试数据.如果更换测试环境,这种案例就无法复用.而团队设计的“COBOL 自动化测试工具”的测试单位是“程序模块”.将“程序模块”的接口输入数据以测试分析表格的方式集中录入,模拟外部接口输入.同时,为了使测试不再依赖数据库现有数据,团队在工具中创新了“循环赋值”功能,用测试分析表格模拟出支持测试的数据库数据.至此,模块分析设计的表格能够模拟模块所有输入来源的数据,并且能够记录各种场景下的预期结果.同时还可以在自动比较完预期结果后,设置特殊的错误值将测试中更新的数据库数据全部回退,使测试的过程不再依赖于外部环境和测试数据准备,因此可以在任何环境下进行案例复用.开发的每一行代码都有一套可复用的测试用例支持,确保将来的更改不会损害目前的功能.输入数据、预期结果的录入如图5 所示.
4.TDD 能有助于设计更优化的体系架构
TDD 是以测试为中心的开发方法,它能够帮助我们更好地理解代码.当团队的外援或新员工无法理解代码时,它能有助于理清思路,使沟通变得更加有效.同时,TDD 还帮助我们规范了代码的结构.如果开发应用程序时,开发人员能够时刻思索如何测试这段代码,那么所设计的模块功能将变得更加单一,紧耦合将被移除,因为紧耦合会增加单元测试的难度.所得到的代码一定是一种开放的、灵活的以及可扩展的结构体系.这样的体系结构会更可靠、易于修改并能对抗缺陷.
5. 平台的流程改进带来了效率的提升
“COBOL 自动化单元测试平台”提供了自动对比产品代码的运行结果和测试分析的预期结果的功能,并清晰地体现在测试报告中.结果相符即会自动生成测试记录单,结果不相符则自动生成测试问题单.同时,自动导入到中心的内部测试库.本批次的开发中,通过“COBOL 自动化单元测试平台”在中心内部测试库共生成记录单8920 个,问题单312 个.根据2016 年生产线任务,“COBOL 自动化单元测试平台”新增了自动化产生案例单、记录单、问题单的功能及自动导入中心内部测试库的功能,极大地提高了测试效率.测试报告如图6 所示.
6. 工具的使用有助于性能问题被提前发现
“COBOL 自动化单元测试平台”提供了性能监控的功能.我们一般会在被测试模块的开始处设置设值点,在模块结束处设置观测点.工具能够监控每个设置点到观测点之间的运行时间,这也正好可以测试增量的产品代码每次运行的时间.团队以300 毫秒为界限,对超过300 毫秒的增量代码在报告中显示“警告”信息.同时,团队在开发阶段就重点分析报出“警告”的产品代码,首先排除环境因素,其次将问题分为可优化、待观察和关闭等状态继续跟踪,无法在应用层优化的问题则提交给IBM 专家分析.在此过程中,团队将以前在功能测试后期才能发现的性能问题提前在编码阶段就开始解决,避免在项目后期才发现性能问题,再修改代码,导致无法充分测试的风险.性能的监控数据和分析参见图7 和图8.
三、“持续集成”过程中的难点和误区
1. 如何解决TDD 中的“过度测试”
TDD 开发方法应避免过度测试的问题.传统开发人员在单元测试中更加习惯针对代码逻辑进行测试.而TDD 的开发方法在编写测试案例时,还没有编写出产品代码,编写测试案例的方法是针对模块的所有输入项的取值范围,排列组合出各种可能发生的场景及该场景经过模块处理后的预期结果.特别是在结构化编程中,根据输入值排列组合出的案例数量将会远远大于经过重构后的代码逻辑对应的案例数量.也就是说传统方法的测试案例数少,但无法测试出逻辑合并过程中产生的问题.TDD 方法测试案例数多,测试更加完整,但容易造成过度测试.“COBOL 自动化单元测试平台”中提供的案例继承功能,仅需要在基础案例的基础上改变少量的设置就可完成一个新案例的设置.当完成一个基础案例后,仅用极少的时间就可以完成几十个或几百个的扩展案例.这一机制在我们当前批次的开发中被普遍应用,既避免了过度测试,又节省了大量测试时间.测试用例的继承如图9 所示.
2. 如何避免自动化测试的脚本维护
以模拟交易接口发起为基础的自动化测试工具最大的问题是当交易接口发生变更时,案例脚本的维护量非常大.当脚本维护的工作量超过了开发工作量一定比例后,开发人员已经不再倾向使用自动化测试工具.“COBOL 自动化单元测试平台”中提供了案例继承的功能.一个基础案例一般会对应几十个甚至几百个扩展案例,而基础案例对应的驱动接口都将被扩展案例继承.当交易接口发生变动后,仅需要变动基础案例的驱动接口,就可使其下的扩展案例都能够正常运行.例如测试“计息”模块时,可以将“还款计划”等模块与计息无关的要素在基础案例中用设值点屏蔽,这样无论接口增加了多少种“还款计划“或其他要素,“计息”模块都不会受任何影响.
3. 如何解决测试案例复用中案例索引
在以交易接口发起为核心的自动化测试工具中,案例复用的过程经常存在一个难题,即修改了某段代码后,如何将受该段代码影响的案例筛选出来进行复测？这一问题在结构化编程中尤为突出.在结构化编程中,所谓的程序架构就是子过程和子程序的复用.而一段代码的修改影响到哪些功能的实现尤其难以确定.在设计“COBOL 自动化单元测试平台”时充分考虑了案例复用的问题.所有案例的管理均以程序模块为单位,当修改到任何一段代码时,均可以在平台中快速索引出对应的测试用例.随着测试案例的不断累积,产品代码逻辑将逐渐实现被自动化测试用例全覆盖,以期达到在任何一个模块被修改时,都能快速地索引到对应的测试用例,通过测试用例的复用来保证修改过程不破坏系统原有功能.测试用例的索引如图10 所示.
4. 如何避免TDD 中的基线错误
TDD 开发方法有一个缺点是开发人员既制定检验标准又制定验收标准.虽然这样保证了制定的标准线和编写的产品代码间不出现偏差,但是,当制定的标准线本身出现了偏差时,则会导致测试失效.如何能保证模块的输入数据分析不出现缺漏,同时保证测试用例的预期结果正确无误？这就需要引入一个更高层次的实践：验收测试驱动开发(Acceptance Test Driven Development,ATDD).在总体设计阶段,团队在业务流程层面上根据具体实现方案,划分程序模块,编制模块梳理表,并为每个模块编写验收测试的标准.需要注意的是,这里不是单元测试的标准,所有ATDD 模板要素均来源于业务要素.通过业务要素的边界分析,在边界内、边界外和边界上均列出了可能的业务输入,然后根据各要素的排列组合,得出各种业务场景和业务预期结果,形成ATDD 三份模板文档——模块梳理表、模块分析表和约束值关系分析表（如图11 所示）.ATDD 分析的成果一方面作为下一步TDD 单元测试分析的指导文档,另一方面也提供了自动转换工具,可将ATDD 分析文档转换为组装测试案例,使总体设计阶段分析出的所有业务场景在组装测试中都得以验证.由于这是一份以业务为中心的文档,团队可以邀请功能测试的同事和业务人员一起排查,与测试人员一起对照功能测试案例查漏补缺,尽力做到业务逻辑全面覆盖.同时,这份以测试案例为中心的基线会在系统维护期间发挥重要作用,任何一个系统运行中发现的疑问都可以在这份基线中迅速找到对应的答案.
四、总结
三年前,中国银行软件中心开发团队积极响应 “引入敏捷思想,优化开发流程,提升开发效率”的号召,主动研究和创新开发工艺,逐步开展了TDD、ATDD 的开发实践,自主开发了支持TDD 的“COBOL 自动化测试平台”,创新并持续完善了ATDD 分析模板,借助软件中心2015 年和2016 年的生产线建设立项任务,持续完善了“COBOL 自动化测试平台”.本批次中成功实践了“持续集成”的开发方式,克服了时间紧、任务重、新员工和新外援比例高等重重困难,超预期地完成了开发任务.
三年来,团队不断在核心银行系统的开发过程中进行敏捷开发的实践,开发效率和产品质量都得到较大的提高.这得益于开发过程中团队依据自身的产品特征,结合敏捷的思想不断地进行优化调整.团队始终认为每一种过程论（瀑布、迭代）都有其本身的优势,不能脱离实际而评判其优缺点.例如,在银行核心产品开发中,核心开发是所有系统的关键,牵一发而动全身,频繁变更核心系统的需求,对系统将是一个灾难.我们必须用更高的标准去要求需求分析人员提高自身的需求分析能力,尽量将需求变化的可能控制在项目早期,所以团队没有选择包括了用户故事在内的全敏捷流程,而是选择了在程序开发阶段（详细设计、编码和内部测试）进行迭代.在方案制定和总体设计阶段团队仍采取瀑布开发的流程进行开发.我们学习的是解决实际问题的敏捷思想,而非形式上的照搬敏捷方法.
综上所述,在大型的银行核心系统开发中,敏捷开发的最佳实践为我们提供了大量的解决问题的思路,为我们指引了一条充满希望的道路.我们也需要清醒地认识到,只有最适合自己产品的流程才是最有效的流程.我们所作的一切流程优化都应该围绕着是否能提升效率,是否能帮助我们更早识别问题、发现缺陷并有效解决问题.相比于学习敏捷开发的各种工具和流程,笔者更欣赏敏捷宣言中的一个原则：“每隔一段时间,回顾和反思如何让团队变得更高效,并相应地调整其行为.”我们应致力于利用敏捷方法帮助解决目前最迫切的问题,所有的流程改进应该以价值为导向.只有将敏捷开发的思维方式灵活运用,并创新出最适合自身产品的最佳实践,才能真正发挥敏捷开发的强大优势.
总而言之,上述文章是一篇关于敏捷开发和银行和核心方面的敏捷开发论文题目、论文提纲、敏捷开发论文开题报告、文献综述、参考文献的相关大学硕士和本科毕业论文.
基于单片机控制的金属和非金属氧化还原反应现象电子检测系统开发
摘要开发基于单片机控制器的监控化学反应过程的下位机硬件,选取典型金属与非金属氧化还原反应实验现象和实验条件可控的电子硬件与软件检测系统的设计、制作、调试、优化形成一套能实时跟踪测量或控制氧化还原反应变.
信息管理和信息系统专业计算机开发技术课程体系的重构和
李莹,李广庆(吉林医药学院,吉林吉林132013)摘要为适应全面改革的高……教育课程模式,培养符合社会需要的创新型人才,重构与研究信息管理与信息系统专业计算机开发技术类课程体系变得尤为重要,文章从教学.
恒丰银行分布式核心系统-API网关技术原型落地实践
随着微服务架构的流行以及服务拆分粒度的精细化,RPC、分布式事务、服务注册 发现、负载均衡、集群容错、服务治理和API 网关……概念逐渐成为了构建微服务架构的基础组件 本文将结合恒丰银行分布式核心系统.
基于社会主义核心价值观培育的中学德育资源开发和应用
社会主义核心价值观对中学生人格培育有着重要的引导作用 并且在社会文化多元化的环境下,中学生这一特殊学生群体,同样受到多元思想的影响 尤其是中学时期正是学生价值观培育启蒙的重要时期,在这一时期,学生的价.