前言

软件工程(Software Engineering)：

• 是一种层次化技术。
• 将系统化的、规范的、可量化的方法应用于软件的开发、运行和维护，即将工程化的方法应用于软件。
• 研究”建立和使用一套合理的工作原则，以便经济地获得可靠的、可以在实际机器上高效运行的软件”的方法。

敏捷软件开发(Agile software development)：

• 一种应对快速变化的需求的一种软件开发方法。基于迭代和增量开发,通过自组织,跨团队,沟通协作完成开发工作。

一、传统软件工程

（一）产生背景

　　随着计算机硬件的飞速发展，社会对计算机软件的需求增大，软件规模越来越大，结构越来越复杂；软件开发管理困难而复杂； 软件开发费用不断增加；软件开发技术落后；生产方式落后，仍采用手工方式；开发工具落后，生产率提高缓慢。软件开发技术的进步未能满足发展的要求，软件开发中遇到的问题找不到解决的办法，问题积累起来，形态尖锐的矛盾，导致了软件危机。

    软件危机：
    1.经费预算经常突破，完成时间一再拖延。
    2.开发的软件不能满足用户要求。
    3.开发的软件可维护性差。
    4.开发的软件可靠性差。

　　在这种状况下，软件工程在1968年首次被提出，其目标便是付出较低开发成本；达到要求的功能；取得较好的性能；开发的软件易于移植；只需较低的维护费用；能按时完成开发任务，及时交付使用；开发的软件可靠性高。软件工程的管理，直接影响可用资源的有效利用，生产满足目标的软件产品，提高软件组织的生产能力等问题。

（二）软件工程模型

1、通用过程模型

2、惯用过程模型

2.1、瀑布模型

　　瀑布模型（Waterfall Model） 是一个项目开发架构，开发过程是通过设计一系列阶段顺序展开的，从系统需求分析开始直到产品发布和维护，每个阶段都会产生循环反馈，因此，如果有信息未被覆盖或者发现了问题，那么最好 “返回”上一个阶段并进行适当的修改，项目开发进程从一个阶段“流动”到下一个阶段。
瀑布模型核心思想是按工序将问题化简，将功能的实现与设计分开，便于分工协作，即采用结构化的分析与设计方法将逻辑实现与物理实现分开。将软件生命周期划分为制定计划、需求分析、软件设计、程序编写、软件测试和运行维护等六个基本活动，并且规定了它们自上而下、相互衔接的固定次序。
瀑布模型是最早出现的软件开发模型，在软件工程中占有重要的地位，它提供了软件开发的基本框架。其过程是从上一项活动接收该项活动的工作对象作为输入，利用这一输入实施该项活动应完成的内容给出该项活动的工作成果，并作为输出传给下一项活动。同时评审该项活动的实施，若确认，则继续下一项活动；否则返回前面，甚至更前面的活动。

2.2、螺旋模型

　　螺旋模型（Spiral Model）采用一种周期性的方法来进行系统开发。这会导致开发出众多的中间版本。使用它，项目经理在早期就能够为客户实证某些概念。该模型是快速原型法，以进化的开发方式为中心，在每个项目阶段使用瀑布模型法。这种模型的每一个周期都包括需求定义、风险分析、工程实现和评审4个阶段，由这4个阶段进行迭代。软件开发过程每迭代一次，软件开发又前进一个层次。采用螺旋模型的软件过程如下图所示。
螺旋模型基本做法是在“瀑布模型”的每一个开发阶段前引入一个非常严格的风险识别、风险分析和风险控制，它把软件项目分解成一个个小项目。每个小项目都标识一个或多个主要风险，直到所有的主要风险因素都被确定。
螺旋模型强调风险分析，使得开发人员和用户对每个演化层出现的风险有所了解，继而做出应有的反应，因此特别适用于庞大、复杂并具有高风险的系统。对于这些系统，风险是软件开发不可忽视且潜在的不利因素，它可能在不同程度上损害软件开发过程，影响软件产品的质量。减小软件风险的目标是在造成危害之前，及时对风险进行识别及分析，决定采取何种对策，进而消除或减少风险的损害。

2.3、增量模型

　　增量模型融合了瀑布模型的基本成分（重复应用）和原型实现的迭代特征，该模型采用随着日程时间的进展而交错的线性序列，每一个线性序列产生软件的一个可发布的“增量”。当使用增量模型时，第1个增量往往是核心的产品，即第1个增量实现了基本的需求，但很多补充的特征还没有发布。客户对每一个增量的使用和评估都作为下一个增量发布的新特征和功能，这个过程在每一个增量发布后不断重复，直到产生了最终的完善产品。

二、敏捷软件开发

（一）产生背景

随着信息时代到来，需求变化更快，交付周期成为企业核心竞争力，轻量级的，更能适应变化的敏捷软件开发方法被普遍认可并迅速流行。随着敏捷开发（Agile Development）的流行，越来越多的公司采用敏捷开发用于软件产品和应用的开发。

（二）敏捷开发原则

敏捷宣言遵循的 12 条原则：
1. 我们最重要的目标，是通过持续不断地及早交付有价值的软件使客户满意。
2. 欣然面对需求变化，即使在开发后期也一样。为了客户的竞争优势，敏捷过程掌控变化。
3. 经常地交付可工作的软件，相隔几星期或一两个月，倾向于采取较短的周期。
4. 业务人员和开发人员必须相互合作，项目中的每一天都不例外。
5. 激发个体的斗志，以他们为核心搭建项目。提供所需的环境和支援，辅以信任，从而达成目标。
6. 不论团队内外，传递信息效果最好效率也最高的方式是面对面的交谈。
7. 可工作的软件是进度的首要度量标准。
8. 敏捷过程倡导可持续开发。责任人、开发人员和用户要能够共同维持其步调稳定延续。
9. 坚持不懈地追求技术卓越和良好设计，敏捷能力由此增强。
10. 以简洁为本，它是极力减少不必要工作量的艺术。
11. 最好的架构、需求和设计出自自组织团队。
12. 团队定期地反思如何能提高成效，并依此调整自身的举止表现。

（三）敏捷开发要点

1、注重概念和架构设计，轻详细设计

　　强调的是产品的路线规划、市场趋势、客户价值、技术趋势等。

2、使用SWOT分析法

　　在敏捷开发中，更加注重客户需求。进行SWOT分析，就能选出付出最小工作量，但能获得最大价值的模块。

SWOT分析法
 　　SWOT分析法常常被用于制定集团发展战略和分析竞争对手情况，在战略分析中，它是最常用的方法之一。 它又称为态势分析法，是由旧金山大学的管理学教授于20世纪80年代初提出来的，SWOT四个英文字母分别代表：优势（Strength）、劣势（Weakness）、机会（Opportunity）、威胁（Threat）。
    -优势，是组织机构的内部因素，具体包括：有利的竞争态势；充足的财政来源；良好的企业形象；技术力量；规模经济；产品质量；市场份额；成本优势；广告攻势等。
    -劣势，也是组织机构的内部因素，具体包括：设备老化；管理混乱；缺少关键技术；研究开发落后；资金短缺；经营不善；产品积压；竞争力差等。
    -机会，是组织机构的外部因素，具体包括：新产品；新市场；新需求；外国市场壁垒解除；竞争对手失误等。
    -威胁，也是组织机构的外部因素，具体包括：新的竞争对手；替代产品增多；市场紧缩；行业政策变化；经济衰退；客户偏好改变；突发事件等。

3、市场和需求驱动，而非技术驱动

　　拥抱变化，但不盲目变化。产品的改动需要经过概念设计、架构设计以及SWOT分析后，三思而后行。

4、时刻考虑版本兼容性

　　时刻考虑产品的架构、规划路线图，老版本的兼容性，及迁移平滑性。否则，随着版本的增多，必将面对着大量的维护工作。

5、轻文档，但非无文档

　　敏捷开发强调沟通的重要性，而轻冗余文档。但敏捷开发并不意味着无文档。在敏捷开发过程中，适量的文档还是很有帮助，有助于整理思路，加快沟通和讨论。

（四）敏捷开发模型

三、传统软件工程与敏捷软件开发对比

（一）具体对比

　　敏捷开发以人为中心，而传统开发以过程为中心。在传统开发中，设计在初始阶段就已经完成了，并且在实现阶段将不再修改。换句话说，实现阶段就是对设计的完成，设计方案是不会改变的。这样就忽略了用户的反馈、忽略了开发人员的设计的主观能动性，使得开发人员只是专注于代码层面的事情。而敏捷开发提倡的是迭代，在每次迭代中都有分析、设计，也就意味着在迭代阶段可以把一部分完成的系统给用户演示，允许用户提意见、需求，也允许开发人员将上一次迭代中得到的想法提出来，并且把这些需求意见想法融入到迭代的分析、设计中，从而在根本上、在理念上，促进了双方的交流沟通，发挥了用户的分析评价和开发人员设计的主观能动性。

　　需求变化是不可避免的，传统开发模式采取“堵”的思想来控制变更，变更对项目进度、质量造成不利影响，而敏捷面对变化采取“疏”的思想坦然面对，通过多次短期迭代快速响应变更。

　　传统方法开发软件的过程，往往是用户与开发团队的利益博弈的过程，所以在开发过程中用户的参与度不高。这也往往会是导致最终开发软件与用户理想软件有差距的重要原因。 而在敏捷开发中，要求用户和开发团队一起开发，这在一定程度上解决了两方之间的“断层”，提高了效率。

　　传统方法中集成是在后期的一个重要阶段，而且是一个独立的阶段。 由于通常很长时间才会做一次集成，所以这个时候问题往往会非常多，如果要进行调试的话，难度很大。而在敏捷开发中，集成很频繁，因此每一次集成的改变也有限，即使集成失败也容易定位错误。

　　传统方法往往要到最后才能得到可执行的产品，而敏捷开发很早就可以得到可执行的产品。

（二）传统软件工程优势

　　在上世纪六七十年代，软件行业从无到有地慢慢发展起来，但是由于当时尚处于启蒙阶段，落后的制造技术、复杂的操作以及高昂的成本使得软件还无法面向普通民众推广，而是只能用在某些大型的、国家控制的行业中，像是宇航业、导弹业等等，而这些行业的第一要素显然是高准确度与高安全性，因此，传统的以瀑布模型为代表的软件开发理念以其比较稳健的、不易改变的特性而备受青睐。直到现在也是这样，对软件的可靠性与质量有极高要求，而且需求固定（或者不频繁变化）的行业，还是以传统的软件工程设计思想为主。

（三）敏捷开发的优势领域

　　随着时代的发展，如今家家户户都有自己的电子设备，开发面向大众的软件已是众望所归。比起之前所说的那些国家组织开发的高精度项目，这些面向大众的软件在复杂程度的层级上一般要远远低于前者，安全性要求也没有那么高，但是突出了客户的个性化需求，并且存在着客户在开发的不同阶段变更要求的可能性。因此，相比较而言，更经常与客户进行交流，且对客户的需求变化也能积极应对的敏捷软件开发在此类情景中更占优势。

四、个人体会

　　传统软件工程是一种预见性方法，然而“计划赶不上变化”，所以传统软件工程在当下快速发展的电子产品开发中，过程显得过于臃肿。相反，敏捷软件开发是一种迭代方法，它更强调适应性，软件一直处于可使用状态，迭代周期短，很容易根据需求的改变进行更改。我认为敏捷软件开发更为贴切当下日常生活电子应用产品的现状，它肯定了需求存在变化这一现象，避免了传统软件工程中因需求更改而付出的巨大代价。

　　现在很多开发团队正在尝试由传统软件工程开发方法转变为敏捷开发，我认为尝试新技术固然是好的，但还是需要先从自身角度理解并分析新技术，并根据自身团队条件和开发需求选择真正合适自己的开发方法，避免得不偿失。

　　虽然与传统软件工程相比，敏捷软件开发仍存在许多争议，这种争议并不是否定敏捷开发，而是在于如何更好地解决问题，如何构建满足用户当前需求的软件，同时展示具有能满足客户长期需求的扩展能力，这些争议会有助于我们提出更多用于分析和设计的软件工程建模方法和表示方法，推动软件工程的发展。

五、参考文献

1. 软件开发——工程模型，http://www.cnblogs.com/kzloser/archive/2012/07/06/2578835.html
2. 敏捷软件开发（Agile Software Development）的上位史，http://www.fawwheel.com/LewisMen/p/5975324.html
3. 瀑布模型，百度百科，http://baike.baidu.com/view/551037.htm
4. 螺旋模型，百度百科，http://baike.baidu.com/view/551040.htm
5. 增量模型，百度百科，http://baike.baidu.com/view/1449573.htm
6. 敏捷开发，百度百科，http://baike.baidu.com/view/309926.htm
7. 小议敏捷软件开发与传统软件工程，http://www.mamicode.com/info-detail-1578723.html
8. （美）普雷斯曼（Pressman，R.S.)著，《软件工程：实践者的研究方法（原书第7版·本科教学版）》

软件工程：传统软件工程 vs 敏捷软件开发