标签：共享 时间 缺陷 世纪 原则 用户需求 程序员 介绍 进度
软件工程这一术语1968年被提出，之后美国软件工程专家巴利·玻姆对十多年间研究软件工程的专家学者们提出的一些准则与信条，于1983年对提出软件工程的七条基本定理，将软件工程这一学科具体化，软件工程中开发与管理软件的方法也不断完备。而敏捷软件开发于2001年由Kent Beck和其他16位知名软件开发者提出，敏捷开发是人们对于传统软件开发方式的一种提出的新的挑战。本文将具体介绍软件传统工程与敏捷软件开发两种方法，并对两者进行对比分析。
一、传统软件工程
软件工程的产生与二十世纪六十年代的“软件危机”有很大的关系，由于当时的软件开发人员采取的方式未工程化，软件开发中遇到很多难以解决的问题，如软件生产不能满足需求，开发时间与成本难以估计以及软件可维护性差等。这使得人们开始考虑采用工程化方法来研制与维护软件，于是软件工程这一技术就这样诞生了。软件工程具有多层次，软件工程的基础在于软件过程，软件过程是指软件构建过程中执行的一系列活动、动作与任务的集合。软件工程的过程框架定义五种活动：沟通、策划、建模、构建与部署。只有这些活动并不能确定于过程之间的相互关系，因此需要一些模型来定义这些关系。
常见的传统软件工程过程模型:
1、 瀑布模型
瀑布模型提出一个系统的软件开发方法，通过策划，建模，构建和部署的过程，最终生产一个完整的软件并提供软件维护。瀑布模型是软件工程最早的模型，但是在实际的运用中，出现很多问题。瀑布模型需要客户明确需求，但是不能适应需求的不确定性，客户只有在软件完全完成了之后才能得到能够执行的软件，一些早期错误需要等到测试阶段才能发现，这些问题使得瀑布模型被现代软件工程界所抛弃。软件工程开发过程中经常遇到各种的变化，而瀑布模型往往不能够适应这些工作，但是在工作以线性方式完成时，瀑布模型还是一个非常有用的模型。事实上线性方法是人们最容易掌握并使用的方法，当人们遇到用线性方法解决不了的问题是，往往会考虑将问题分解为一系列线性问题，然后逐个解决。
2、 增量模型
增量模型实质就是分段的线性模型，增量模型发布一系列称为增量的版本，逐渐为用户提供更多的功能。增量模型在每个阶段使用线性模型，增量模型在每个增量都能运行，这样能够很好的适应变化，客户也能够一直看到软件的开发，早期发生的错误能够得到解决，降低开发风险。增量模型能够解决瀑布模型的几个问题，但是仍然还是有一定的缺陷:软件的体系架构需要保证在新加构件时，能够对原系统无影响。
3、 螺旋模型
螺旋模型是一种演化过程模型，它结合了原型的迭代性质与瀑布模型的系统性与可控性的特点，能够有快速开发完善软件版本。螺旋模型最大的特点是具有其他模型不具备的风险分析，使得软件在面临重大风险时能够停止，减少损失。螺旋模型从圆心开始顺时针方向演进，第一圈一般开发出软件规格说明，在接下来的每次迭代中逐步完善，最终得到最终版本。螺旋的没圈都会跨过多个区域，需在每个迭代的每个区域中不断调整项目计划，直到迭代结束。螺旋模型适合开发大型的系统级应用。螺旋模型每个迭代都植入软件测试并累计开发成本，使得软件质量得到严格保证，而且开发成本容易掌握。但是螺旋模型的风险管理支出可能会过于庞大。
二、敏捷软件开发
敏捷开发是一种新型的软件开发方法，具有应对快速变化的需求的能力。敏捷开发方法来源于2001年的一次软件开发者的集会，他们在会上成立“敏捷联盟”并签署了“敏捷软件开发宣言”，其中包括以下要点：
1、个人与这些个人之间的交流胜过了开发流程与工具
2、可以工作的软件胜过了详尽的文档
3、客户合作胜过了详细的文档
4、对变化的响应胜过了严格地遵循计划
敏捷联盟定义了12条原则：
1、对我们而言，最重要的是通过尽早和不断交付有价值的软件满足客户需要。
2、我们欢迎需求的变化，即使在开发后期。敏捷过程能够驾驭变化，保持客户的竞争优势。
3、经常交付可以工作的软件，从几星期到几个月，时间尺度越短越好。
4、业务人员和开发者应该在整个项目过程中始终朝夕在一起工作。
5、 围绕斗志高昂的人进行软件开发，给开发者提供适宜的环境，满足他们的需要，并相信他们能够完成任务。
6、在开发小组中最有效率也最有效果的信息传达方式是面对面的交谈。
7、可以工作的软件是进度的主要度量标准。
8、 敏捷过程提倡可持续开发。出资人、开发人员和用户应该总是维持不变的节奏。
9、对卓越技术与良好设计的不断追求将有助于提高敏捷性。
10、简单——尽可能减少工作量的艺术至关重要。
11、最好的架构、需求和设计都源自自我组织的团队。
12、每隔一定时间，团队都要总结如何更有效率，然后相应地调整自己的行为。
敏捷开发相比于其他方法更强调软件的适应性，而不是预见性。从本质上来讲，敏捷软件开发是为了克服传统软件工程中的弱点而形成的。在现实生活中，用户需求不断改变，很多情况下，完全无法充分定义需求。
极限编程是敏捷开发使用最广泛的一个方法，。极限编程包括策划、设计、编码、测试4个阶段。极限编程有12个实践原则：
1.计划的制定：包括客户选择的项目大小、程序功能的优先级、各个版本的合成和发布日期。
2.小版本：用最少的代码工作量带来最大的业务价值。
3.简单设计：通过所有测试，没有重复和费解的逻辑代码，简单的设计能保证代码的简单。
4.测试：一个功能存在的前提是有一个测试能够验证它，任何有被破坏的可能的代码就必须有一个对应的测试。
5.持续整合：大量减少在整合中耗费的时间，减少团队开发问题。
6.重构：确保加入新功能后代码仍保持简单，从而保证简单的代码仍然能够运行所有的测试。
7.配对编程：提供持续的信息反馈和确保正在编程的人进行重构、测试和遵守编码标准，实现代码共享目的。
8.代码共享：在通过测试的前提下，任何一个人都能够对系统做出修改。
9.每周只工作40小时：充分利用你的时间，一个星期工作40小时已经足够了。 10.现场客户：讨论，使用程序员和客户都能够的语言描述功能。
11.隐喻：普通语言和术语的集合，用来预见项目中的功能。
12.编码标准：遵守编码标准，让其它程序员明白代码，减少不必要的沟通。
所有敏捷过程模型中使用最广泛的就是极限编程，当然也有很多其他模型，比如自适应软件开发、Scrum、动态系统开发方法等，这里就不加以讨论了。
三、传统软件工程与敏捷软件开发的对比
敏捷软件开发相对传统软件开发的优势：
1、 敏捷开发强调适应性，因此软件开发适应性更加强。就拿软件变化的成本来说，敏捷开发比传统软件工程少得多，这就是因为敏捷开发适应性更强。
2、 敏捷开发交付周期短，强调尽早将可用的功能交付使用，这样有利于软件在整个项目中持续改善。
3、 敏捷开发的工作效率更加高，人力资源得到更充分使用。
敏捷软件开发相比传统软件工程的劣势：
1、敏捷开发文档也传统软件工程相比显著减少，因此团队之间的交流就需要增加，而一旦工程很大的话，团队之间的交流会变得很困难。
2、对个人能力要求很高，团队人员要求开发能力强，团队之间沟通能力也不能弱。
标签：共享 时间 缺陷 世纪 原则 用户需求 程序员 介绍 进度
原文地址：http://www.cnblogs.com/YQ5683/p/5991517.html
