【转载】快速迭代式开发使用方法总结

本文转载自http://blog.csdn.net/dongkui168/article/details/9069407 
------------------------------------------------------------------------------------------------------

   为什么我在这里主要讨论迭代式软件开发?本文在此抛开千篇一律的理论,拟就根据多年的实践,总结出一套比较务实、可操作性强的方法,以期望在有限的资源下确保软件质量得到较大保证。一家之见,纰漏之处还请大家多多指正。

迭代式软件开发模式简要流程如下:

上图绿色大框内,我们就称之为一个迭代周期。每一个迭代,都可以形成一个可交付的小版本。事实上,每一个迭代周期内,对于编码和测试也可以进行多次迭代。通过快速发布测试构建的方式,验证开发完成的新功能,再通过测试发现问题来驱动开发人员对软件进行修改完善,循环往复。即:根据开发情况有针对性地组织测试,根据测试结果反作用于开发人员去完善软件质量。以这种小步快跑的方式,经过若干测试构建后,软件质量可以在较短时间内达到稳定状态。

质量保证,需要系统性的方法。那么在迭代式开发的各个阶段,都需要怎样的措施呢?

1)需求

这个阶段的主要工作是需求制定与评审。该阶段的工作分三步走:收集原始需求 -> 制定产品需求 -> 产品需求评审。具体说来,首先我们通过各种渠道收集原始需求,由于原始需求多半是概念性的、模糊的,不能直接用来指导开发工作,所以需要进行归类、筛选,整合为产品需求。基本原则是,结合当前开发产品的特性,争取以最小的改动以及最大的可扩展性来制定产品需求。降低风险,同时提高灵活性。经验告诉我们,在需求没有考虑透彻的情况下,不要贸然开始设计并实现,可能导致大量返工,费时费力。产品需求制定好后,需要进行评审,一定不要觉得浪费时间而不去评审,磨刀不误砍柴工嘛!

2) 设计

这个阶段的主要工作是将产品需求转化为设计需求,指导后续的编码工作。软件行业有一名老话是:软件质量是设计出来的,对于迭代式开发也是如此。设计的好坏直接决定了软件质量的高低。设计需求一般阐述了产品需求的详细设计方案,包括页面布局、数据结构、算法以及易用性、安全性、可扩展性、健壮性和性能等诸多方面的设计思路。即使让不同的开发人员根据设计需求来进行编码,开发出的功能也八九不离十。有此可见,设计需求是非常必要的。也就是说,我们在正式编码前,必须针对需求写出相应的设计文档来指导后续的编码工作。这样做有两大好处:一是在编码之前就充分预见到将来可能遇到的问题,可以尽早规避风险;二是为开发工作搭好框架,降低因开发人员的差异导致开发过程的不确定性,避免出现“一千个人心中有一千个对需求的理解”。

3) 编码

这个阶段的主要工作是严格按照设计需求来完成编码,并组织进行代码评审。每一行代码都是软件大厦的一砖一瓦,我们拒绝豆腐渣工程,所以我们重视每一行代码。进行代码评审可以有效保证代码质量,借助一些IT管理工具可以轻松进行代码评审和代码管理。笔者曾经使用过青铜器RDM软件来做代码评审(CodeReview),十分方便。代码评审的重点应该是对程序结构的审查,发现深层次的软件错误,而不要停留在表面。同时,建议大家在做代码评审时,以代码的一个“提交”为单位进行评审。这样做的前提是,每个“提交”里包含相对完整的功能。对于迭代式开发,我们要尽量保证,每一个编码-测试迭代里,都要完成相对独立、可测试性强的功能点。

4) 测试

测试实质上是一种鉴定性的工作,是对软件质量的鉴定和最后一道把关。这个阶段的主要工作是,在每一个测试构建中,尽可能多地覆盖需求点,并根据轻重缓急合理安排测试优先级,尽可能将影响较大的缺陷提前暴露出来。测试优先级的安排应遵循以下原则:

a、先测试经过变更的部分,然后测试没有变更的部分

b、先测试程序的核心功能,然后测试一般功能

c、先测试逻辑性的功能,然后测试业务性的功能

d、先测试常规情况,然后测试异常情况

e、先测试功能,然后测试性能

按照上述原则进行测试,可以更快地发现更多软件中的严重错误,这是使软件能尽快稳定下来的一个关键因素。除此以外,在每一个迭代周期结束之前还要进行系统测试。

编码-测试的不断迭代,保证了每个测试构建里的新功能没有问题,但整个软件系统的质量还没有得到充分验证,系统测试就是为此而生。在版本发布前的最后冲刺阶段,“车轮战”是很管用的一个手段,即:调集测试人员、开发人员等全面参与测试,将这些人员分为若干个小组,每个小组分别对系统进行测试。每个测试模块由多人进行测试,可以有效降低缺陷的遗漏率。但需要注意的是,开发人员应该避免测试自己开发的功能,即进行交叉测试。

软件质量保证的实质是,使用一些流程、方法来管控软件开发过程,从而使最终交付的软件产品质量得到最大程度的保证。同时,相信大家可以看出,在整个产品开发过程中会产生很多数据,如需求、设计文档、代码、测试用例、缺陷等。使用IT管理工具可以有效提高工作效率,青铜器RDM全面实现CodeReview+ Testlink + Mantis功能组合,可以管理需求、测试用例、缺陷、代码评审等,对于小规模团队,已经足够用了。

时间: 2024-10-17 18:30:31

【转载】快速迭代式开发使用方法总结的相关文章

敏捷开发的26条至理名言 快速迭代式开发使用方法总结

敏捷开发真正的问题是什么?其实敏捷主要还是一种观念,一种意识,通过人来推动. 本文总结了26条有关敏捷开发的关键原则,如何快速迭代式开发,供读者参考借鉴,以指引敏捷软件开发团队. 1.完整地干完一件事后在开始另一件事:用厨房比喻来说就是:"先上这道菜,再开始做下一道".软件开发的最大问题就是同时开始几件事情,这将不可避免的造成某些工作被废弃,从而造成浪费.专注于一件事:完整地实现其功能:运行测试:编写文档:签入所有,把这当做一项工作完成,然后再开始下一件事. 2.不要破坏构建:非常明显

迭代式开发使用方法总结

http://www.cnblogs.com/pangguoming/p/4922422.html http://www.ibm.com/developerworks/cn/rational/rationaledge/content/jun05/bittner/ http://blog.csdn.net/mvpyao/article/details/42741269

Android应用插件式开发解决方法[转]

一.现实需求描述 一般的,一个Android应用在开发到了一定阶段以后,功能模块将会越来越多,APK安装包也越来越大,用户在使用过程中也没有办法选择性的加载自己需要的功能模块.此时可能就需要考虑如何分拆整个应用了. 二.解决方案提出 一般有两种方式,一种是将应用按照功能分拆成多个应用,用户需要哪个就下载哪个,都需要就都下载.应用之间,可以在代码层面做一定的关联,以共享部分信息.另一种方式,类似于其他平台插件的方式,用户可以在主应用中可以选择性的下载需要的插件,不需要该功能,则不需要下载. 第一种

Android应用插件式开发解决方法

Android应用插件式开发解决方法 一.现实需求描述 一般的,一个Android应用在开发到了一定阶段以后,功能模块将会越来越多,APK安装包也越来越大,用户在使用过程中也没有办法选择性的加载自己需要的功能模块.此时可能就需要考虑如何分拆整个应用了. 二.解决方案提出 一般有两种方式,一种是将应用按照功能分拆成多个应用,用户需要哪个就下载哪个,都需要就都下载.应用之间,可以在代码层面做一定的关联,以共享部分信息.另一种方式,类似于其他平台插件的方式,用户可以在主应用中可以选择性的下载需要的插件

迭代式开发技术

迭代是一开发种技术,用来把系统功能传递到一系列的增量的完整版本,每个版本一个特定固定的时间段被开发,该时间段称之为迭代. 每个迭代的经历过程: 整个迭代过程: 图中颜色代表每次开发每项活动所占的比重不同 迭代式开发的优点: 1.降低风险 2.得到早期用户反馈 3.持续测试和集成 4.适应变更 开发特征: 1.在进行大规模的投资前,就解决了关键的风险问题 2.使的早期用户反馈在初始迭代中就能出现 3.连续进行测试和集成. 4.各个目标里程碑提供了短期的焦点. 5.对过程的测量是通过实现的评定来进行

深入浅出软件开发-----(一)超越过程的迭代式开发

(多年前的读书笔记,从ITEYE迁移过来) 近日正在研读<Head First Software Development>一书,很喜欢深入浅出系列的书籍,语言流畅.行文活泼又不失风趣.同时又可以顺便学习一下英文,其实该系列书籍都挺流畅,只要英文不是特别差读起来就不费任何力气. 其实本书根据软件开发的整个流程,讲了很多的切实可行.可用的实践来帮助我们开发出伟大的软件----(Deliver what the customer want,  on time ,on buget!) Greate s

迭代式开发中的禁忌:跨版本修改

最近在做一个项目,这个项目一开始采用的是迭代式的开发模式.但是现在已经乱成一团,乱着乱着开发就变成了测试驱动的开发. 说好的1.0版,改着改着都不知道这是什么版.数据库的结构变化很大.接口规范变化很大.需求变化很多.你可能会想,就算搞个很厉害的架构师,也不见得系统就稳定不变. 是的,确实如此.但是问题是每一次的大改动,根本就是十分随意却没有任何记录的行为.仅靠一个svn(也没用上分支),谁能弄明白到底改了什么鬼? 为什么迭代式的开发,最终变成了依靠测试人员的测试驱动开发?后来我想了一下,发现根本

11.SpringMVC注解式开发-处理器方法的返回值

处理器方法的返回值 使用@Controller 注解的处理器的处理器方法,其返回值常用的有四种类型 1.ModelAndView 2.String 3.void 4.自定义类型对象 1.返回ModelAndView 若处理器方法处理完后,需要跳转到其他资源,且又要在跳转的资源间传递数据,此时处理器方法 返回ModelAndView比较好.当然,若要返回ModelAndView,则处理器方法中需要定义ModelAndView对象 在使用时,若该处理器方法只是进行跳转而不传递数据或只是传递数据而不向

springmvc 注解式开发 处理器方法的返回值

1.返回void -Ajax请求 后台: 前台: