敏捷软件开发与传统软件工程概述比较

翁松秀

北京航空航天大学计算机学院

　　摘要：软件工程的开发过程中有两种截然不同的管理和开发体系，一种是基于“瀑布模型”的预设性传统软件工程，另一种是轻量级的适应性敏捷软件开发，本文简单阐述传统软件工程的开发方法与敏捷软件开发的异同，并通过“瀑布模型”和SCRUM方法的比较来探析传统软件工程与敏捷软件开发的异同。最后得出结论，把传统软件工程和敏捷软件开发相结合，将软件架构“颗粒化”，在简单可快速交付的敏捷软件开发中嵌套系统的传统软件开发方法，实现预见性和适应性折中。

关键词：敏捷软件开发；传统软件工程；瀑布模型；SCRUM方法；嵌套；颗粒化

　　0 前言

　　随着计算机的发展，对软件的需求越来越大，软件的规模也变得越来越大，结构越来越复杂，软件开发管理困难而复杂，在这个“软件危机”背景下产生的传统软件工程，用工程化的方法构建和维护有效和高质量的软件。暂时解决了软件的兵荒马乱时代，但随着社会和科技的发展，对软件的需求变化越来越快，传统的软件工程很难再适应瞬息万变的客户需求，敏捷软件开发应运而生，其轻量级、简单、可快速交付、适应性强收到开发团队的青睐，与传统软件工程并肩，形成软件工程中的两大开发体系。

　　1 传统软件工程

1.1 传统软件工程概述

　　基于“瀑布模型”的传统软件开发方法中，以软件架构(software architecture)为核心，采用结构化的设计和分析方法将软件生命周期划分为制定计划、需求分析、软件设计、程序编写、软件测试和运行维护等六个基本活动。并规定他们自上而下，相互衔接的顺序，如同瀑布的流水一般，各个阶段的通过文档相互流通。前期就要设计好整个软件大厦的框架来指导和支撑后面各个方面的开发和维护工作，后面再根据前期设计的蓝图来逐步实现。由架构师完成软件架构设计，开发人员再根据软件大厦的蓝图进行软件开发。这种开发方法的优点是，超前的预见性和每一阶段都要通过严格的审查才能进行下一个阶段，保证了软件的质量。缺点是，软件的框架一旦确定下来就很难改变，甚至会牵一发而动全身，难以适应变化莫测的客户需求。由于各个阶段要自上而下相互衔接，各个阶段的沟通要通过大量臃肿、复杂的文档来传递信息。

　　1.2 瀑布模型

　　瀑布模型是Winston Royce在1970年提出的一种软件开发模型，瀑布式开发是一种传统的计算机软件开发，是最典型的预见性软件开发方法，严格遵守计划、分析、设计、编码、测试、维护的步骤。阶段之间通过文档流通，每个阶段结束时要进行严格的审查，检查功能设计和实现是否符合上阶段流下来的文档的要求，如果不符合就逆流到上个阶段检查并修正，以此往复，直到流到最后阶段产品通过测试后进行发布以及运行期间的维护。

瀑布模型开发过程（如图）

三个阶段：定义阶段、开发阶段和维护阶段。开发阶段架构师要有预见性地分析客户现在的需求以及以后可能变动的需求，设计规划好大量的功能需求和非功能需求，尽可能多地满足客户后面需求的变动，避免日后重构软件框架带来的成本亏损。设计包括UML图，API接口，数据库表等。开发阶段开发人员根据架构师的对客户需求分析以后设计的蓝图进行软件的开发和测试，实现用户的需求。运维阶段开发团队根据用户使用软件的体验、反馈、软件存在的BUG和新增功能需求对软件进行维护，保证软件在保证鲁棒性的前提下能尽可能地满足客户的需求。
六个流程：制定计划、需求分析、软件设计、程序编写、软件测试和运行维护。

瀑布模型的特点
- 强调文档。瀑布模型每个阶段之间的沟通和交流就是文档，上一个阶段的输出就是下一个阶段的输入，文档就是前后阶段衔接的介质。缺少开发人员之间面对面的沟通与交流，造成文档臃肿现象。
- 结构明显。按需求分析将整个工程划分为完整的阶段集合，每一个阶段都有明确的检查点，当出现问题可以使用顺藤摸瓜式往上检查。当一个阶段结束后通过严格审查，就可以只关注下个阶段，出现问题再逆流检查。

　　2 敏捷软件开发

　　1.2 敏捷软件开发概述

　　2001年由17位业界专家构成的敏捷开发联盟成立，联盟起草了敏捷宣言：个体与交互胜过过程和工具；可用的软件高于复杂的文档；客户的合作胜过合同的谈判；响应变化胜过遵循计划。敏捷软件开发是一组重视人的主观能动性和开发人员、管理层和产品负责人的沟通，通过迭代式和增量式软件，追求便捷，可快速交付，及时响应客户需求变动的软件开发管理方法。

　　敏捷软件开发方法体系主要包括：SCRUM、XP（极限编程）、CRYSTAL（水晶编程）、PDD（特性驱动开发）等。敏捷软件开发的一个精髓就是“刚刚够（Just enough）”思想。用逐步实现的思想替代完整构架，每一步的需求和人员及其沟通、开发成本都刚刚好，通过不断地迭代，在迭代过程中响应客户需求的变化，实现最紧致成本，体现“刚刚好”思想。同时对每次迭代的反馈进行讨论和思考，总结经验和吸取教训。

　　2.2 SCRUM方法

　　在敏捷软件开发中，软件项目被切分成很多个子项目，通过选取优先级较高的一组子项目作为敏捷迭代的球心进行迭代，每次迭代都有明确的需求、目标、人员、并且每次迭代之后都要有可交付的产品。就好比从山顶滚雪球，选取优先级较高的需求作为首次迭代的球心，经过增量式迭代，每次迭代加带一定的需求滚下山，下山就可以形成可交付的产品。

三个角色：管理层（Scrum Master）、产品负责人（Product Owner）和开发团队（Team）。
三种工件：产品列表（Product Backlog）、迭代列表（Sprint Backlog）和燃尽图（Burn Down Chart）。
四个会议：Sprint Plan Meeting（Sprint 计划会议）、Daily Scrum Meeting（Scrum每日会议）和Sprint Review Meeting（Sprint评审会议）和Sprint Retrospective Meeting（Sprint回顾会议）。