标签：软件需求 可行性 责任 软件 结构化 一个人 所有权 投资 交互
本文将介绍传统软件开发与敏捷软件开发，并简单分析二者的优缺。
首先我查阅相关资料大致了解了下为什么会爆发“软件危机”和什么是“软件危机”。由于在早期的软件开发活动中有明显的个体化特征，开发流程不规范，人们没有将软件与程序加以详细的区别，对程序之外的数据和相关文档资料没有给予重视，对编写程序之外的软件活动也没有给予重视，因此出现了“软件危机”。“软件危机”的特点有：开发成本急剧上升、不能按时交付软件、软件难以维护、无法保证软件质量、无法满足用户需求。故人们开始研究软件开发方法，1968年提出“软件工程”的概念。在这种情况下，1970年瀑布模型被推出。
到此我们引出传统软件开发。传统软件主要包括过程、工具和方法3要素。软件工程方法主要有形式化方法、面向对象方法、结构化方法。传统软件工程方法很大一个缺陷是软件可能没有完全满足客户的需求，由此造成成本剧增、软件质量下降、软件延期等问题。为什么这样讲？我们需要了解传统的软件开发流程。其大致分为七步：1.可行性分析与项目开发计划。2.需求分析。3.概要设计。4.详细设计。5.编码过程。6.软件测试。7.软件维护。 从这个流程我们可以知道传统的软件开发开发流程是一个文档驱动的流程，它将整个软件开发过程划分为顺序相连的几个阶段。每个阶段都有特定的任务，只有在完成一个阶段的所有任务（文档）后，才能进入下一个阶段。这就意味着只有当所有系统模块全部开发后，我们才能进行系统集成，对于由模块众多的复杂系统来讲，这是一个非常艰巨而漫长的工作。也就是说用户需要等相当长一段时间才能得到一个可用的软件，而这个软件可能存在潜在的bug。用户在这段等待时间内，他的需求可能发生了变化，此时再告知开发团队，这就将造成开发成本与周期都大大增加。所以在这个商业经济的信息时代，这样的开发过程有时会显得“跟不上节奏”。但是对于一些需求在确定的软件开发工作，传统软件开发也是具有很大优势的。
典型的传统软件开发模型有：瀑布模型、增量过程模型、演化过程模型、螺旋模型、协同模型等等。
既然传统软件开发存在着或多或少的问题，那么在2001年，kent Beck和其他16位知名软件开发者、软件工程作家以及软件咨询师共同签署了“敏捷软件开发宣言”。至此，敏捷软件开发思想诞生。从本质上讲，敏捷方法是为了克服传统软件工程中认识和实践的弱点而形成的。敏捷软件开发有许多有优点，但并不是适用于所有的项目、所有的人。敏捷软件开发特点是鼓励沟通、重视软件开发效率、适用于软件需求不确定、用户易于沟通并且能参与开发、开发人员有责任感并且积极向上、十个人一下的项目开发、以保证软件开发有成功的产出为前提，尽可能减少在开发过程中制成品的方法、根据具体的产品类型和运行环境，尽可能快的将切实可行的软件交付给用户。个体和交互胜过过程和工具、可以工作的软件胜过面面俱到的文档、客户合作胜过合同谈判、相应变化胜过循环计划是敏捷开发的核心价值观。
为更好说明敏捷软件开发，下面简要介绍一种敏捷开发方法。
极限编程是一个灵活、轻量、周密、严谨的敏捷软件开发方法。它的开发方法接近螺旋式，是将复杂的开发过程分解为一些相对简单的小的周期。极限编程是一个客户和开发人员都可以清楚了解软件变化、进度、潜在困难和待解决问题，可以让客户和开发人员有及时交流和反馈的开发过程。极限编程强调的是人与人之间的相互合作的过程，其开发过程突出了人在软件开发过程中的优势。极限编程是为了满足计算机软件下载需要的软件，甚至在软件生命周期的后期都能有效相应客户的需求变化。极限编程采用以下方式：系统隐喻、编码规范、小型发布、现场客户、持续集成、代码集体所有权、简单设计、测试、规划策略方法。从极限编程的介绍中我们可以隐约看出它和传统软件开发方法的不同，下面我们将详细讨论二者的优缺点。
敏捷方法对于复杂的需求不明确的项目能够快速、廉价地成功完成，主要强调团队、可用的软件、客户合作、随时响应变化；而传统方法则在开发早期和客户洽谈，获取详细需求，主要强调协议、计划过程、文档等。
传统软件存在的缺陷：
1.测试阶段往往是整个代码编写完成后进行，测试无问题后将产品交付给客户。假如在测试阶段发现了问题，则有可能需要对整个模块进行返工来修改。
2.由于开发早期客户往往不能明确自己需要实现什么，因此早期建立的需求模型往往不能准确包含系统所需的功能，而在整个产品按照线性模式开发完后，客户则提出改变需求的要求，这样对系统进行频繁修改后，将导致整个系统的兼容性受到影响，尤其在大型系统中更是表现突出。
3.从商业的观点看，传统开发没有将投资回收率作为最优先的考虑，并不是一个最有效的开发方法。
在介绍敏捷开发开发时，我们已经大概了解了其相对于传统软件开发的优点，但是在实际应用中敏捷软件开发也存在一些问题：
1.敏捷方法明显地降低了文档的数量，甚至声明代码本身就是文档。这就需要开发人员为代码添加更多的注释，但是对于不习惯敏捷开发或团队新成员则很难做到，他们必须不断询问有经验的开发人员，这样会导致延迟迭代交付时间，甚至增加开发费用。而传统开发则强调文档对团队成员的指导作用，开发人员可以在不知道项目细节的情况下完成开发。
2.敏捷开发中强调交互和客户的参与。每次迭代前，团队和客户都将召开一个会议，团队成员将介绍在这次迭代中所作的工作，而客户则根据成员的介绍给出新的功能要求。实际中大部分情况，这种例会是非常乏味和沉闷的，因为团队成员必须重复地向其他成员和客户展示自己负责的模块，接受给出各种对需求的更改，而且每次迭代都是如此，通常为迭代分配的时间都是以周为单位的，开发人员经常感到时间不够用，尤其是自己负责的模块中包含一些复杂的算法时，时间就变得越紧，经常使得迭代延迟。而传统开发中客户不会参与开发过程，实现过程中开发人员只是根据文档编写代码，然后交付最终产品。这样开发人员不必关心那些频繁的迭代会议，而且时间上更加宽泛，有利于开发出更好的产品。
3.敏捷开发对开发人员的个人技能要求更高。前面提到过，敏捷开发强调交互和客户的参与，这就意味着每个团队成员都要具备一定的个人能力和社交技能。每次迭代都必须给客户提供完整的功能模块，并且需要让客户明白当前的开发进程以及开发中遇到的一些问题，开发人员不但需要将自己的工作描述清楚，还得正确理解客户提出的新需求，这需要具备较好的沟通技能。而实际中，不一定每一个开发人员都能具备这样的技能，一旦某一个人不能正确理解一些重要信息，将可能导致下一次迭代不能准确交付，更糟糕的是，如果理解有误，会使得开发的模块中包含多余的功能，结果是对模块进行修改，从而增加开发费用。因此，开发人员社交技能的提升将增加开发过程的稳定性。
【参考文献】
标签：软件需求 可行性 责任 软件 结构化 一个人 所有权 投资 交互
原文地址：http://www.cnblogs.com/yanghao14061017/p/5986264.html
