论敏捷开发在企业软件开发中的应用
论基于构件的软件开发 
论软件系统架构评估 
论高可靠性系统中软件容错技术的应用 
论软件系统架构风格 

论软件开发模型的选择与应用

摘要： 

本文以一个招标业务系统的软件开发过程为例，讨论了软件开发模型的选择与应用。文章首先对项目特点进行了分析，然后对目前常用的开发模型——瀑布模型、演化模型、螺旋模型、敏捷开发模型的优缺点做了对比分析。根据项目实际情况，以及模型的特点，最终选定了敏捷开发模型。并说明了项目是如何应用敏捷开发模型完成开发工作的。最后简要叙述了开发模型的演变趋势和特征，和坚持以项目特点为主的开发模型选择策略。 该项目是2010年3月为一家国内大型招标代理机构开发的业务运营系统，特点是：工期要求短、开发团队小、技术难度低、需求不明确或不断变化。我有幸作为技术负责人参与了该项目的开发工作，主要负责承担该项目的需求分析和系统设计工作，并经过合理分析选择采用敏捷开发模型顺利完成任务，获得各方一致好评。

正文： 

本人就职于一家国有大型外贸集团的信息管理部门，主要负责参与整个集团的信息系统的设计开发和维护管理工作。随着人民币汇率不断升值、国内购买力不断增强，外贸集团下属的招标代理公司的招标业务量近年增长迅猛，过去人工管理的业务运作模式无法适应，成为制约公司业务发展的瓶颈。因此，该公司领导要求在较短的时间内迅速建立一套支持招标业务运营的信息系统，加快业务运作流程、提高工作效率和招标服务质量。该项目从2010年3月初开始启动，经过信息部和招标公司的通力合作，历时近6个月，至8月底完成验收，并于9月1日正式启用。我有幸作为技术负责人参与了该项目的开发工作，主要负责承担该项目的需求分析和系统设计工作。 我经过调查分析发现：1、招标在国内尚属比较新颖、特殊的一个行业，目前软件业界尚无成型的招标软件产品可供引进或者借鉴。2、但该项目技术难度要求不高，我们可以依靠本部门技术力量自主研发。3、该公司各业务部门的招标类型不同，操作手法不一，因而需求目标模糊、界定困难，而且随着招标业务的发展，需求还可能不断变化。4、由于业务部门需求迫切，招标公司领导要求尽快实现启用。根据上述情况，我与项目小组的技术人员经过充分的讨论分析，对当前流行的几种开发模型进行了比较和选择： 瀑布模型按软件生存周期各阶段固定顺序开发，要求大量文档配合，工作量大、缺乏灵活性，可能直到开发完成才发现不符合客户需求。该方式比较适合需求明确、有类似成功案例参照模仿的项目，因此不适合招标业务系统的开发需要。 演化模型（原型法）先根据基本需求快速构造可运行版本——原型，再根据客户反馈重复不断改进至令客户满意。它虽然能解决需求不明确的问题，但其风险是：开发效率低、项目进度和预算难以控制，因此也不适合招标业务系统快速开发的需要。 螺旋模型将瀑布模型和演化模型相结合，它强调了其他模型所忽视的风险分析，特别适合于大型复杂的系统，而反复迭代也导致工期较长。而招标业务系统规模有限、技术难度低且工期有限，因此不宜采用螺旋模型。 对于这种工期要求短、开发团队小、技术难度低、需求不明确或不断变化的项目，我经过分析比较后认为最适合采用“敏捷开发”的轻量级开发方法，而实际开发应用过程也证明了这一选择的正确性： 敏捷开发首先要求“客户直接参与”，敏捷宣言中的一句是“客户合作胜过客户谈判”。意思是让客户参与到项目中，通过紧密的合作来实现项目开发，要比合同谈判效果好得多。项目开发过程中需要客户及时地、频繁地进行反馈，因此将客户经常拉到开发现场，就是成功地开始。在项目开发过程中，由于招标公司领导层非常重视，主动召开动员会议，积极发动业务人员参与配合，因而需求调查工作迅速铺开。但在调查的过程中，我觉得客户的代表性很重要： <1>参与的客户必须对自身从事的招标业务非常熟悉，能够对相关问题给出正确而全面的反馈意见。 <2>由于招标公司各业务部门的招标类型不同，操作手法存在差异，客户参与过程中更多的是从部门角度出发考虑问题。因而我们不能偏听一方，需要综合各方意见，全盘考虑。因此，我向招标公司领导要求：每一个部门都安排一名资深业务员参与到项目中来，配合需求分析、模块试用和反馈意见。在招标公司的积极参与配合下，项目开展顺利、没走多少弯路。 <3>敏捷开发的另一个特点是“小版本发布”，要求经常提交可工作的软件，间隔越短越好。由于敏捷开发奉行“客户合作、客户参与”，而要让客户更加有效的参与，经常性地、频繁地交付可工作的中间软件版本，将可以有效地加强开发人员于客户之间的沟通，从而将隐藏的错误和需求变化及早发现和触动。在具体的开发过程中，我们依据招标业务的流程顺序，从“项目立项建档、招标公告发布、评标专家抽选”，到“标书发售、保证金收退、开标评标中标”，直至“结果公示、收中标费、结案评审、项目归档”，逐个环节依次开发提交，平均每周发布一次。因此，招标公司领导能够根据我们不断提供的最新中间版本了解项目进展，配合协同组织工作；各部门的用户代表能够及时参与试用和反馈意见。 敏捷开发还有一个特点是“较少的文档”，敏捷宣言中提出“可以工作的软件胜过面面俱到的文档”。对于开发团队而言，各种文档规范越繁多越细致，真正用于开发的时间就越少，开发速度和效率也就越低；对于客户而言，真正能够产生价值的东西是可以工作的软件，而非这些面面俱到的文档。在实际开发过程中，为节省时间、加快开发效率，我们对要编写的文档类型进行了裁减，例如：由于项目规模小、技术难度低，对项目成功很有把握，因此省略了“可行性研究报告”。我们也对必须编写的文档的进行了简化，例如：我们大量采用草图直接勾画用户操作界面，并附加文字说明的方式，与客户进行直观的沟通交流，经客户认可后的，做成示意图直接加入“需求说明书”和“设计说明书”，简化了文档的文字编写，也更直观清晰。当然，“较少的文档”并不是说不要文档。为了保证项目的开发质量和后继的维护工作，以及客户培训工作的顺利进行，我们对“数据库设计说明书”、“用户操作手册”等文档还是做了认真细致的编辑。 最终这个项目在工期短、需求不明确等困难下，依靠敏捷开发方法的思想指导和实践应用，在有关领导、开发团队和用户的积极配合、共同努力下顺利完成，获得一致好评。 随着软件技术的迅速发展和市场变化，新的软件开发模型也不断出现，如：喷泉模型、RUP模型、智能模型（四代技术4GL）等。这些开发模型都是结合各种新技术、新变化而发展演变的，都有各自的优点和缺点，在实际应用中存在着许多不足和局限性。我们应该注意分析区别各种开发模型的适用对象、范围，坚持以项目为主，根据实际开发的项目特点来选择合适的开发模型。需要考虑的因素包括：需求是否明确或变化；项目的规模、技术难度、风险与开发团队的力量、水平；项目的工期限制等，这样才能选择合适的开发模型，并顺利的应用到项目开发中。