标签：项目 分析 开发 工程 提高 可行性 情况 拒绝 自身
软件工程是上世纪七十年代提出来的概念，面对开发程序的规模越来越庞大，用户的需求越来越复杂等挑战，提出将软件开发工程化的概念，传统的软件开发方法有瀑布模型、螺旋模型、喷泉模型、RUP四类，它们注重文档的完整，程序的易读性，结构的完整性，属于重型软件开发方法。在过去的一段时间，传统软件工程的方法很好的适应了软件开发的需求，传统软件工程不仅关注软件构造方式的完美型，同时也注重总体的可预测性，以文档为驱动，按照需求分析、概要设计、详细设计、编码、测试、软件交付的流程来进行开发。在软件产业不是很发达、软件开发人员稀少的过去，这样严格的开发流程无疑对于任何软件开发都是适用的。
传统软件的开发分为以下几个阶段：
（1）计划
对所要解决的问题进行总体定义，包括了解用户的要求及现实条件，从技术、经济和社会因素等三个方面研究并论证本软件项目的可行性，编写可行性研究报告，探讨解决问题的方案，并对可供使用的资源 成本，可取的效益和开发进度做出估计。制定完成开发任务的实施计划。
（2）分析
对所要解决的问题进行详细定义，这需要软件开发人员和用户共同讨论决定，哪些需求是可以满足，并加以确切的描述。编写软件需求说明书、初步用户手册、确认测试计划和数据要求说明书等。
（3）设计
根据需求说明书的要求，设计建立相应的软件系统的体系结构，并将整个系统分解成若干子系统或模块，定义子系统或模块间的接口关系，对各个子系统进行具体设计定义。编写软件概要设计和详细设计说 明书，数据库或者数据结构设计说明书，组装测试计划。
（4）编码
把软件设计转换成计算机可以接受的程序，即写成以某一程序设计语言表示的“源程序清单”。
（5）测试
在设计测试用例的基础上对软件进行测试，以验证系统是否按所要求的性能和功能设想运行。编写测试分析报告。
（6）维护
根据软件运行情况，对软件进行适当的修改，以适应新的要求，以及纠正运行中发现的错误。编写软件问题报告、软件修改报告。
在实际的软件开发过程中，并不是严格的从第一步到最后一步，而是有关阶段都会对之前相关阶段进行反馈，然后做出调整，如上图，但是即便如此，在软件产业如此发达的今天，从事于软件开发的人员也越来 越多，应用软件的规模也越来越小，功能越来越细化的今天，传统的软件工程开发方法在很多场合下都显得很是拖沓，因而从传统的软件工程开发方法中诞生出了敏捷编程。
相对于传统软件工程，敏捷方法主要有两个特点。
1、 敏捷型方法是“适应性”而非“预设性”的。传统软件工程试图对一个软件开发项目在很长的时间跨度内做出详细的计划，然后依据计划进行开发。这类方法在计划制定完成后拒绝变化。而敏捷型方法则欢迎变 化。其实，它的目的就是成为适应变化的过程，甚至允许改变自身来适应变化。
2、 敏捷型方法是“面向人的”而非“面向过程的”。它们试图使软件开发工作能够利用人的特点，充分发挥人的创造能力。它们强调软件开发应当是一项愉快的活动。
敏捷编程并不是一个完全独立于传统软件工程的开发方法，敏捷编程是为了适应当今软件开发的需求从传统软件工程中孕育而出的一种适应性开发方法。敏捷开发并不完全是一种全新的理论，是对传统软件工程 的一种改善，而非创新，敏捷开发借鉴了大量传统软件工程中的方法，例如迭代与增量开发，这两种传统的软件工程方法，在敏捷开发模式中也扮演了很重要的角色。再向前追溯，我们还可以见到瀑布式与快速原型 法的影子。由于敏捷开发在原有软件开发方法基础上进行了整合—取其精华，去其糟粕。因此敏捷开发继承了原有方法的优势，提高了软件开发的效率并且允许开发过程中的需求变化、通过早期迭代较早发现风险、 使代码重用变得可行、减少了项目的返工。
敏捷开发是一种轻量级的方法，敏捷开发的关键是在软件质量和开发速度之间找到一个有效的平衡点。敏捷开发并非文档驱动，而是软件产品为驱动的，通常一件给定的工作只需要很少的文档，在软件的开 发过程中，根据用户的需求变化随时调整程序，直到交付使用户满意的软件产品，项目小组和开发人员必须具有“敏捷”特性。
利用传统的软件开发方法，只有在开发的后期用户才能看到开发的产品，虽然在前期有对需求进行非常详细的分析，然而在需求文档成型之后，需求几乎不会再改变，所以期间如果用户的需求发生了变化， 重新更改需求的代价是非常巨大的。而敏捷开发流程不同，用户、设计人员、编码人员参与了整个开发流程，拿出第一个测试版本的软件非常快，通常在第一个迭代周期之后用户就能看到第一个版本，然后通过沟 通、交流、测试，再对产品的功能进行修正，不停的迭代，每个迭代的周期非常短，所产生的文档也非常少，但是这部分文档是必不可少的。敏捷开发是一种非常灵活的方法，随着用户的需求变化为基线进行运作， 往往能在短期内拿出用户比较满意的产品。
然而传统的软件工程并没有过时，只是相对来说传统的软件工程的适用范围狭窄了许多，在一个“快餐”应用横行的今天，传统的软件工程方法用到的地方比较少，现在很多应用的开发周期就只有几个月，开发 好之后放到市场上，运行一两年之后等到用户很少之后废弃不用再接着开发下一个软件，这就是现在很多公司的模式，这种情况下敏捷开发非常实用。但是在某些软件开发中，尤其是重型软件开发中，传统的软件开 发模式依然非常有用，依然有一些软件用敏捷开发的观点来看，相对来说不太适合，尽管利用解耦的方法可以将各个模块尽量的分开，然而重型的软件对于需求的分析要求相对来说就弱化了许多，对于文档的需求来 说更严格，需要长时间的维护，要达到甚至完美的程度，就需要严格的按照开发步骤来，严格的按照工期目标来完成，而且相对来说，功能的修改很是麻烦，很可能会产生牵一发而动全身的状况，所以需要一个严密 的团队按照流程来严格的执行开发过程。
总的来说，敏捷开发方法并不一定和传统的软件工程方法矛盾，就如前面所说，各有各的优点，软件是死的，人是活的，关键在于决策者能否根据软件的特点和自身团队的人员配置来合理安排方法，并没有 必要一定严格按照某个方法来开发，要根据实际情况来调整，既不能低估文档的作用，而使得软件维护起来非常麻烦，也不能由于拖沓导致整个项目进度迟缓或者软件产品不达标。我们的最终目标是拿出优秀的软件 产品（包括程序和必要文档），在此基础之上尽量的节省资源（时间、空间等），在此之上找到一个平衡点，开发方法需要灵活变更。
参考文献：《敏捷软件开发技术研究》周莹莹
《敏捷开发在软件开发中的应用研究》彭志楠
《敏捷软件开发应用研究》范洪涛
《软件工程发展历程即其发展趋势探讨》张忠华
《小规模团队的敏捷开发研究》韩鹏
标签：项目 分析 开发 工程 提高 可行性 情况 拒绝 自身
原文地址：http://www.cnblogs.com/14061196hu/p/5988813.html
