（计算机软件与理论专业论文）基于敏捷思维的系统综合开发方法的研究与实践.pdf

太原理工大学硕士研究生学位论文 基于敏捷思维的系统综合开发方法 的研究与实践 摘要 传统的传统方法认为过程是解决软件问题的核心，重视过 程、重视文档是这些方法的特征。本文从传统的传统开发方法 ( 以瀑布模型为代表) 开始，简单分析了瀑布模型、演进模型、 反复模型、螺旋模型、c m m 的特点。 瀑布模型在2 0 世纪7 0 年代被认为是理想的软件开发方式， 以解决当时编码一修正模式所带来的问题，它在历史上起过很重 要的作用。演进模型为瀑布模型的一些问题( 如消除需求中存 在的缺点) 提供了部分解决方案。可以把它看作软件生命周期 向灵活的、非单调型方法迈出的一步。反复模型最主要优点是 能把一个阶段要做的改动反馈到一个更早的阶段。这些改动在 这个较早阶段中体现并向前传递，这样可以保证改动的可回溯 性并能产生一个满足用户需求的软件系统。演进式和反复式的 过程结合，并加入两者所忽略的风险分析，就形成了螺旋模型。 和前几个模型不同，c m m 强调的是软件过程的稳定、可预测和可靠 性，过程改进是一个持续不断、逐步优化的过程。 在分析传统方法的基础上，研究分析了敏捷思维的观点。 敏捷思维换了个角度看问题，它认为人是解决软件问题的核心。 首先对敏捷宣言进行了分析研究，提出了敏捷开发的原则。然 后提出了支持敏捷思维的基础理论：“充分交流的不可能性”， 提出了交流的不完美性、不完全性，是敏捷思维重视交流的理 论基础；“开发过程是理论构建过程”是敏捷思维重视人的理论 基础；“变化的成本”是敏捷思维的技术前提；“方法论的设计 原则”则提出了设计方法的基本原则，可以指导实际开发过程。 最后讨论了敏捷思维的具体实践( 极限编程、s c r u m 、水晶方 法、特征驱动开发、精益开发、动态系统开发方法、敏捷建模) 以及它们共同的缺点。 结合传统方法和敏捷思维，作者提出了一个新的开发方法： 太原理工大学硕士研究生学位论文 系统综合方法，并通过自己在电子政务开发的实践，验证了新 方法。 关键词：敏捷思维，传统方法，综合，实践 2 太原理工大学硕士研究生学位论文 t h es t u d ya n dp r a c t i c eo fas y s t e c a n ds y n t h e t i c a l l ym 匣t h o d o l o g y b a s e do na g i l ed e v e l o p 匝n t a b s t r a c t t h eh e a v ym e t h o d o l o g yb e l i e v e st h a tt h ec o r eo fs o l v i n gs o f t w a r ep r o b l e mi sp r o c e s s t h e r e f o r ei tp a y sm o r ea t t e n t i o nt op r o c e s s a n dd o c u m e n t t h eh e a v ym e t h o d o l o g y , s u c ha sw a t e r f a l lm o d e l e v o l u t i o n a r ym o d e l i t e r a t i v em o d e l s p i r em o d e la n dc m ma r e a n a l y z e d w 乱e r f a um o d e lh a db e e nl p o k e do na sap e r f e c tm e t h o d o l o g y w h i c hs u b s t i t u t e df o rc o d e f i xm o d e lo n19 7 0 s a n di te v e rp l a y e d a ni m p o r t a n tr o l ei ns o f t w a r eh i s t o r y e v o l u t i o n a r ym o d e la p p e a r s a si tc o u l ds u p p l ys o m es o l u t i o nt ow a t e r f a l lm o d e l ss o m et r o u b l e s s u c ha sr e q u i r e m e n tc h a n g e w 色m a ys e ei ta st h ef i r s ts t e dt h a t s o f f w a r el i r e c y c l em o d e lc o n v e r ti n t of l e x i b l ea n dn o n m o n o t o n y m e t h o d o l o g y i t e r a t i v em o d e l sm a i nv i r t u ei st h a ti tm a yf e e d b a c k o n ec h a n g ei nap h a s et oa ne a r l i e rp h a s e t h o s ec h a n g e sm a t e r i a l i z e di nt h i se a r l i e rp h a s ea n dt r a n s f e r r e df o r w a r ds ot h a ti tc a nb e t r a c e da n dp r o d u c eas o f t w a r es y s t e mm e e tu s e r s c o m b i n e dw i t h e v o l u t i o n a r ym o d e la n dr e p e a tm o d e l ，a n dr i s ka n a l y s i sw e r ei p i n e d ， t h e ni tf o r m ss p i r em o d e l d i f 凳rf r o mo t h e rm o d e l c 埘e m p h a s i z e so nc o n t i n u a ls o f t w a r ep r o c e s si m p r o v e m e n t s o f t w a r ep r o c e s s i m p r o v e m e n ti sa c o n t i n u a lo p t i m i z e sp r o c e s s b a s e do na n a l y z eo ft r a d i t i o n a lm e t h o d a g i l ei sp u tf o r w a r d a g i l em e t h o d o l o g yt h i n kt h a tp e o p l ei sc o r eo fs o l v i n gs o f t w a r e p r o b l e m a t i e ra g i l em a n i f e s t ow a sr e s e a r c h e d ，s o m er u l e sw e r e b r o u g h tf o r w a r d t b e n w ea d v a n c et h eb a s et h e o r yo fa g i l e ：“t h e i m p o s s i b i l i t yf o rc o m m u n i c a t i o n p o i n to u tt h a tc o m m u n i c a t i o n c a l l b ei m p e r f e c ta n di tm a k e sa g i l et h i n k sm u c ho fc o m m u n i c a t i o n “p r o g r a m m i n ga st h e o r yb u i l d i n g i sab a s et h e o r yo fa g i l ea b o u t v i e w p o i n to fh u m a n ；“c o s to fc h a n g e i sp r e c o n d i t i o no fa g i l et e c h n i q u e “m e t h o d o l o g yd e s i g np r i n c i p l e s i sa ni n s t r u c t o ro fp r a c t i c e 3 太原理工大学硕士研究生学位论文 d e v e l o p m e n tp r o c e s s i t sc o r et h i n k i n gi st h em a n i f e s t o f i n a l l y , t h e p r a c t i c e so fa g i l ew e r ed i s c u s s e d i nt h el a s tp a r t ，w et r ys o m ew a yt oh a n ga g i l em e t h o da n d h e a v ym e t h o dt o g e t h e rb a s e do no u re g o v e r n m e n tp r a c t i c e k e yw o r d s ：a g i l e ，h e a v ym e t h o d o l o g y ，i n t e g r a t i o n ， p r a c t i c e 4 太原理工大学硕士研究生学位论文 第一章引言 从1 9 世纪6 0 年代开始，人们就在谈论“软件危机”，并且都在为解 决软件危机面临的困难问题而进行坚持不懈的努力。软件工程作为一个学 科方向，愈来愈受到人们的重视。然而，现在再来空谈所谓的软件危机已 经显得很乏味了。大家都知道，软件社会已经发生r 一场革命，以软件组 件复用为代表，基于组件的软件工程技术正在使软件开发方式发生巨大的 变化。早年软件危机中提出的严重问题，许多方面已找到了可行的解决途 径。 1 1 软件开发面临的困难 但是，现实的情况并不能过分乐观，由于软件产品本身的特殊性和多 样性，使得大规模软件工程开发时，在如何协调合理预算、控制进度以及 满足客户需求和期望等方面，软件开发者们仍然面临困难境地： 第一，对软件工作量和开发成本的估计常常很不准确，实际成本比估 计成本有可能高出一个数量级。随着技术的进步和生产规模的扩大，计算 机硬件的价格在不断下降。相反，随着软件社会需求的增长和软件人才的 短缺，使得软件成本和软件价格不断上升。软件成本在计算机系统总成本 中所占的比例也越来越大。在发达国家，计算机系统中软件费用的比例已 提高到8 0 以上。在发展中国家，人力资源成本相对较低，软件成本尚能 保持在一个较低的水平。问题在于，软件开发成本的估计难以有统一的标 准，发展中国对软件成本的认知程度不足，加之市场的恶性竞争，导致软 件价格可能低于它应有的开发成本，软件企业为了压缩开发成本所采取的 权宜之计最终会损害软件质量和客户利益。 第二，难于控制开发进度。通常对于一个软件任务要根据其复杂度、 工作量及进度要求来安排人力资源。但是这种安排是不确切的。软件是一 种逻辑产品，据有人估计，软件设计与硬件设计相比，使用的逻辑量要多 1 0 i 0 0 倍。为了完成一个复杂的软件，常要建立庞大的逻辑体系。这往 往实际只存在于人的头脑当中。一个同样的软件算法，可以用差别甚大的 程序形式来实现。此外，软件开发过程中遇到的各种意想不到的情况层出 不穷。这些都使得软件开发过程很难按预定的计划实现。 第三，软件产品的质量往往靠不住。花费了大量资金和人力开发出来 的软件，其结果往往与预期有相当差距。软件的质量问题，与其它工业品 的质量问题有者很大的不同。软件设计人员对客户需求的理解和认识与用 7 太原理工大学硕士研究生学位论文 户的想法可能有着很大距离，因为技术人员几乎总是习惯以技术的角度去 理解用户需求。一般说来，用户对他自己所想使用的软件的功能和性能在 事前是难以确切地表述清楚的，即使用户本人是技术人员也不例外。从软 件项目开始，就存在软件开发人员与客户理解的概念差异。 软件设计带有太多的灵活性和随意性，这使软件质量控制成为一个很 难解决的课题。投入了巨大的人力和资金而开发出来的软件产品，最终却 不能达到预期的目标，这在软件业是一个普遍现象。如何控制和管理软件 的质量，是软件工程面临的主要难题。 这些困难的出现，归根到底，是因为，应用领域的不断扩大，功能的 不断增强，导致软件项目的规模越来越大。以往的软件项目完成后编写的 源程序有l 万行已被认为是十分庞大的项目，然而现在几十万行的项目并 不稀奇。以h p 的激光打印机驱动程序为例，在l o 年前它的源程序有4 万 彳亍，可是现在它已有1 1 0 多万行，l o 年增长了2 8 倍。据报道，w i n d o w2 0 0 0 的源码总数已经达到了一个天文数字：4 0 g 。 规模的扩大，使软件项目更加复杂。项目开发的复杂程度与项目的规 模不无关系。项目规模小，参与开发的人员少，问题处理起来也简单得多； 项目大了，参与的人员多了，需要解决的问题自然也就复杂了。除了技术 问题、资源配置问题外，还会遇到大量的组织和管理问题：不仅要考虑开 发队伍内部的问题，还会涉及到客户、市场的关系问题，甚至可能涉及到 知识产权等法律问题。 通过以上分析，我们可以看出，现代软件工程开发中面临的问题，不 仅包括传统的工程问题：时间、成本、质量，还有越来越严重的复杂性和 用户需求的频繁改变。每个软件开发组织都要对此找到适合自己的开发方 法。 1 2 现有的软件开发方法 现有的软件开发方法呈现出两种发展方向： 一是朝着规范、严谨、全面而细致的标准化方向发展，如c m m 、i s 0 9 0 0 0 、 b o o t s t r a p 、s p i c e 等等。它所遵循和实施的是一种工业化、工程化的发展 指导原则。在本文统称这类方法为传统方法。 另一种则是近年来出现的敏捷思维，向着简洁小巧、实用且灵活发展。 它所强调的是一个实用性原则，即以人为主导，尽量削减其它阻碍发挥人 的主观能动性的规则、规范。 应该说，上述软件工程的两种发展趋势都有其存在的意义。传统方法， 一直是主宰着全世界软件行业发展到现在的主流方向，它的益处和优势是 明显的。相对而言，敏捷思维的出现时间没有那么久，但它却有着相当迅 8 太原理工大学硕士研究生学位论文 猛的发展势头，受到了广大开发人员的欢迎。这其中存在着非常深刻的道 理。 然而盲目地选择一种方向并全盘接受是危险的，我们应该认真分析这 两种方向各自的优缺点，并结合自己的实际灵活应用，才能取得较好的效 果。本文对这两种方向进行了研究，在综合二者长处的基础上提出了自己 的观点，然后通过实践进行验证。 9 太原理工大学硕士研究生学位论文 第二章传统方法 2 1 软件开发方法的两个基础 在计算机发展的早期，软件玎发者就是最终用j 二一，采用的是编码一修 正模式( c o d ea n df i xm o d e l ) 。开发只有两个阶段：编写代码和修改代 码“1 。随着硬件能力的增长和应用领域的扩大，这种方法逐渐显现出弊端： 首先，代码缺少统一规划，低估了设计的重要性，使得代码结构随着 修改次数的增加而变得越来越坏。以致错误越来越难改，最后导致无法修 改。 其次，即使有的软件设计得很好，但由于开发者与用户的分离，往往 其结果并非用户所需要的。 最后，由于对测试、维护修改方面考虑不够，使得代码的维护修改非 常困难。 2 1 1 软件工程的七条基本原理 为了解决上述问题，人们提出了“软件工程”的概念，b w b o e h m 在 2 中总结了软件工程的七条基本原理： 用分阶段的生命周期计划严格管理； 坚持进行阶段评审； 实行严格的产品控制： 采用现代程序设计技术； 结果应能清楚地审查： 开发小组的人员应该少而精： 承认不断改进软件工程实践的必要性。 应该说，这七条原理是软件开发方法的基础。所有的传统方法，从最 初的瀑布法到现代的c m m ，都严格遵循上述规定。即便是敏捷思维，从 表面已经看不到这些原理的影子，但如果仔细分析它的创造思想，也无不 建立在这些原理的基础上。但是，敏捷思维对这些原理有一定发展，有一 些“放松”。二者的不同在于“是否严格遵守”这些原理，而不在于“是 否遵守”。 1 0 太原理工大学硕士研究生学位论文 2 1 2 软件生命周期 借用传统工程中产品生存周期的概念，软件工程中引入了软件生命周 期。软件生命周期是指一个软件从提出开发要求到该软件报废为止的艇个 阶段。就是从时间角度对软件开发和维护的复杂问题进行分解，把软件生 存的漫长周期依次划分为若干个阶段。每个阶段有相对独立的任务，同一 个阶段各项任务的性质尽可能相同。然后再逐步完成每个阶段的任务。 软件生命周期一般分为：软件定义( 问题定义、可行性研究、需求分 析) 、软件开发( 总体设计、详细设计、编码和单元测试、综合测试) 、 软件维护等三个时期。 以结构化软件开发为例，软件生命周期各阶段的任务如表2 一l ”1 所示： 表2 - 1 软件生命周期各阶段的任务 t a b l e2 - 1p h a s et a s k so f s o f t w a r el i f e c y c l e 阶段 问题定义 关键问题 问题是什么? 可行性研究有可行的解吗? 需求分析 总体设计 详细设计 编码和单元测试 综合测试 维护 结束标准 关于规模和目标的报告书 系统的高层逻辑模型；数据流图、成本 效益分析 系统必须做什么? 委萋鐾鬈辑模型：数据流图、数据字典、 如何解决已提出的问可能的解法：系统流程图、成本效益分 题?折；推荐的系统结构；层次图或结构图 囊篡尹体地实现这个编码规格说明 正确的程序模块 源程序清单：单元测试方案和结果 符台要求的软件篓合测试方案和结果；完整一致的软件配 慧久地满足需要的软 完整准确的维护记录 软件生命周期的提出符合人类的思考习惯。人类解决复杂问题时普遍 采用的一个策略是“各个击破”，也就是对问题进雩亍分解，然后再分别解 决各个子问题的策略。这样降低了软件开发的复杂性，简化了不同阶段之 间的联系，有利于软件开发过程的组织管理。 2 1 3 敏捷思维对基础理论的发展 在所有的开发方法中，无不包含着“七原理”以及“生命周期”的内 容。传统方法严格遵守这些理论。但是，敏捷思维就不是这样 太原理工大学硕士研究生学位论文 对“七原理”的重视程度不同。传统方法严格执行每一条规则、对 “生命周期”的每一步都有严格的要求。而敏捷思维对某些理论就不那么 看重，比如在极限编程( x p ) 中就没有“七原理”中第二条评审过程， 在应对需求变化时也没有严格遵守第三条实行严格的产品控制，而是 根据方法发明者自身的具体情况不同作了相应的权衡取舍。 对文档和过程的观点不同。传统方法严格执行软件生命期过程，在 每个阶段结束后都提交相应的文档。而敏捷思维不注重文档，以面对面的 交流代替人多数的文档，希望文档越少越好；在敏捷思维的方法族中经常 运用迭代递增开发方法，各个阶段之间没有明显的界限。 2 2 软件开发模型的发展 模型是为了理解事物而对事物做出的一种抽象，它忽略了不必要的细 节，是事物的一种抽象形式、一个规划、一个程式。人们在实际开发中运 用软件工程的七条基本原理和生命周期理论，创造出各种各样的开发模 型。敏捷思维和传统方法不是截然对立的，从敏捷思维中能看到传统方法 的影子。下面先选出几个具有代表性的传统方法进行讨论。 2 2 1 瀑布模型 在“生命周期”的基础上，w i n s t o nr o y c e 在 4 中提出了“瀑布模 型”。它将软件生命周期的各项活动规定为自上而下、相互衔接的固定次 序，形如瀑布流水。如图2 - 1 图所示： 这种模型在2 0 世纪7 0 年代被认为是理想的软件开发方式，以解决当 时编码一修正模式所带来的问题。它在历史上起过很重要的作用，以至于 十年后成为美国国防部的标准( d o d s t d 一2 1 6 7 ) 。需要说明的是，1 9 9 4 年 后，美国国防部取消了对瀑布模型的支持，而力推迭代递增开发 ( m i l s t d 一4 9 8 ，d o d 5 0 0 0 2 ) 。而迭代递增正是敏捷方法的特征之一。 根据运用该模型的组织和项目的不同，瀑布模型可以有很多不同的变 体；即使各变体的阶段数和阶段性质上存在差异，但是根本的原则是相同 的。所有变体都坚持认为，在进入下一阶段前，应该完成当前阶段的所有 任务，每一阶段产生一个或多个作为下一阶段输入的文档。所有的瀑布模 型都有以下三个特征：瀑布模型是顺序的、基于阶段的并且是文档驱动的。 该模型对于我们理解软件过程做出了两个根本贡献【5 j ： 软件开发过程应当遵守规范、规划和管理： 实现产品应当延迟到很好地了解了这样做的目的后再进行。 从现代软件工程的观点看，瀑布模型是一个理想化的模型，所以实际 】2 太原理工大学硕士研究生学位论文 开发只能接近它。它的缺点是：在完全实现完整的产品之前，不允许对正 在开发的产品有充分的可见性。瀑布模型在过程中引入严格的规范， 图2 1 瀑布模型 f i g u r e2 - 1w a t e r f a l lm o d e l 由此产生了新的问题： 当只有有限的信息时，很难精确地估计资源。瀑布模型通常要求在 仅仅执行了有限量的分析后进行成本估计和项目计划； 用户很难根据需求规范判断最终构造的系统将满足期望。真正的反 馈信息总是在真正的系统交付以后才出现。 用户通常不知道确切的应用需求。在某些情况下，用户甚至不知道 需求。 瀑布模型没有强调预测变更的必要性。恰恰相反，该模型的基本原 理是，应当在早期阶段是尽量多的需求固定下来，力求线形的开发过程。 现实表明，需求的变化比预期的要频繁得多。 以文档驱动为特征的开发导致了大量文档的产生。这就需要开发者 填写和批准许多表单。同时软件工程师除了要注重语义外，还要注意语法。 无疑这个极大地增加了软件开发的工作量； 瀑布模型强调线性开发。前面未发现的错误传到后面的开发活动中 时，将会扩散，进而造成更大的损失。而现实中错误是无法避免的。 现在这种模型一般用于做用户需求已明确的并很少变化的软件，不适 于需求不明确或是容易变化的软件( 如果你正在开发一个陌生的领域的软 1 3 太原理工大学硕七研究生学位论文 件，这时就不应该使用瀑布模型，但是如果你正在开发自己很熟悉领域的 软件，就可以使用瀑布模型来加快开发速度) 。 2 2 2 演进模型 软件开发的演进模型也称为增量模型。它与瀑布模型的阶段划分相 同，但在各阶段的范围和工程的管理上则有区别。它首先完成一部分的功 能，然后在每次反复中扩充这些功能。此外，各个步骤之间也可以有反复。 这种方法为瀑布模型的一些问题( 如消除需求中存在的缺点) 提供了 部分解决方案。可以把它看作软件生命周期向灵活的、非单调型方法迈出 的一步。一个严格的、单调的方法一瀑布法非常详细地描述了一个给定 的开发阶段的所有方面：在开发周期完全结束之前，一切皆不能工作，也 不会交付任何东西。相反，演进方式由逐步开发组成，目的是为了在项目 开发的早期建立某些有用的功能集，而某些阶段的某些部分被推迟执行。 演进模型可以定义为：其阶段由一个可操作软件产品的扩展增量组成 的模型，演进的方向由开发经验确定。一般过程如图2 2 所示： 图2 - 2 演进模型 f i g u r e2 - 2e v o l u t i o n a r ym o d e l 演进模型是在瀑布模型的基础上加以修改而形成的。他与瀑布模型之 间的本质区别是：瀑布模型属于整体开发模型，它规定在开始下一个阶段 的工作之前，必须完成前一阶段的所有细节。而演进模型正好相反，它采 用增量实现。整个应用的设计遵循瀑布模型，而实现增量地完成。推迟某 1 4 太原理工大学硕士研究生学位论文 些阶段或所有阶段中的细节，从而较早地产生工作软件。 增量实现只为瀑布模型的内在问题提供了部分解决方案。然而也可 能，提供增量的最早时刻仍然太晚，需求分析的结果以后可能失效。 为了在过程中实现更细的粒度，可以把增量方法扩展到生命期的所有 阶段。这样，开发从对一个增量进行需求分析开始；然后分别设计、编码、 测试、继承和交付每个增量。换句话说，对于每个不同的增量，仍然遵循 瀑布模型；因此，总的过程模型是一系列微型瀑布过程。增量根据客户的 反馈信息一个接一个地丌发。实际上，当用户实际使用交付的部分时，他 们开始更加清楚真正需要什么。这就导致未来增量的需求变化以及原计划 的修改。从开发者的角度看，因为每个增量比整个系统更简单，所以更容 易可靠地预测开发任务需要的资源。 快速原型法是演进模型的一种形式。它是在开发真实系统之前，经过 简单快速分析，迅速构造一个原型。在试用原型的基础上，用户与开发者 相互沟通，通过反复评价和改进原型，弥补遗漏，适应变化，逐渐完成整 个系统的开发工作。 快速原型法起源于需求分析技术的研究。由于种种原因，在需求分析 阶段要得到完全、一致、准确和合理的需求说明是很困难的。因此在开发 过程的早期，在获得一组基本需求说明后，就快速地使其“实现”，通过 原型反馈，加深对系统的理解，并满足用户基本要求，使用户在试用过程 中受到启发，对需求说明进行补充和精确化。使比较含糊的软件需求和功 能明确化，发现和消除不协调的系统需求，从而获得合理、协调一致、无 二义的、完整的和切实可行的需求说明。 以后，又把快速原型法思想用到软件开发的其他阶段，并向软件开发 的全过程扩展。即先用相对较少的成本，较短的周期开发一个简单的、但 可以运行的系统原型向用户演示或让用户试用，以便及早澄清并检验一些 主要设计策略，在此基础上再开发实际的软件系统。 根据我们的理解，演进模型提供了透明的过程，支持对某种正在开发 的内容进行连续的确认。演进模型有助于开发者了解和分析一个项目设计 的主要风险、支持在早期识别出需求错误，以及自然的适应需求的演进。 他们满足现代软件工程的需求，即要求缩短上市时间。 2 2 3 迭代模型 迭代模型最主要优点是能把一个阶段要做的改动反馈到一个更早的 阶段。这些改动在这个较早阶段中体现并向前传递，这样可以保证改动的 可回溯性并能产生一个满足用户需求的软件系统。在完全的迭代模型中， 对反馈链没有任何限制；它可以从任何一个任务到任何其它任务。一般说 1 5 太原理工大学硕士研究生学位论文 来，迭代的方式更适用于面向对象模式，当然也可以用顺序的开发过程开 发面向对象的应用。 迭代模型的缺点”1 是反馈过程可能很难控制，因此要给出迭代次数的 上下限。大多数实践者把下限定在三次左右。一个典型的迭代式开发方法 包括一系列的迭代，其中每一次迭代都包括计划、生产和评估阶段。 开发计封 2 2 4 螺旋模型 需求变动 日程安排 图2 - 3 迭代模型 f i g u r e2 - 3i t e r a t i v em o d e l s 质量性能 可复用性 演进式和反复式的过程结合，并加入两者所忽略的风险分析，就形成 了螺旋模型。这种模型特别适用于庞大而复杂、高风险的系统。对于这些 系统，风险是软件开发不可忽视的、潜在的不利因素。 螺旋模型如图2 _ 4 所示。螺旋模型的主要特征是环状。图中的螺旋线 代表时间的推进，工作的进展。4 个象限分别标志每个周期所划分的4 个 阶段：制定计划、风险分析、开发实施、用户评估。半径的长度代表累计 的成本多少，角度表示过程( 或时间) 的进展。开发过程虽然具有周期性 的特点，但在模型中考虑了成本因素。随着时间的推移，花费总是不断增 加，因此，图形成螺旋线状。不同的项目特点不同，螺旋线的周期数、具 体内容也有所不同。 和演进模型不同，螺旋模型避免提前决定系统的整体和细节。当系统 根据功能的优先级别逐块构建时，螺旋模型根据风险确定需求的优先级。 1 6 旷、多r 太原理工大学硕士研究生学位论文 与反复模型相比，螺旋方法在敏捷性上提高了一大步，但是一些业内人士 认为，与迅速发展的社会需求相比，它们对变化的反映仍然不够敏捷。冗 长的计划和分析过程，对大量文档的持续重视，应用螺旋技术的工程与当 今的敏捷思维相比仍然缺少敏捷。 螺旋模型的目标是，为开发过程提供一个在项目的风险等级指导下进 行设计的框架。如果对应用的需求有着非常好的了解，则可以采用普通的 瀑布模型，它只产生一条单圈螺线。然而，如果对终端用户的应用理解甚 差，则下阶段的工作本质上具有演进性。即，为了实现期望的结采，可 能需要经历多圈螺线。 螺旋开发可以被看作一种元模型，因为它能包容任何一个开发过程模 型。通过用它作为一个参考模型，可以选择最合适的开发模型。这种选择 背后的指导原则是风险等级，因此，螺旋模型提供了一种支持风险管理的 生产过程视图。 螺旋模型基本的做法是在“瀑布模型”的每一个开发阶段之前，引入 非常严格的风险识别、风险分析和风险控制。直到采取了消除风险的措施 之后，才开始计划下一阶段的开发工作。否则，项目就很可能被取消a 另外，如果有充足的把握判断遗留的风险已降低到一定的程度，项目 管理人员可做出决定让余下的开发工作采用另外的生命周期模型，如“演 化模型”，“瀑布模型”，或自定的混合模型。 螺旋模型的优点： 强调严格的全过程风险管理。 强调各开发阶段的质量。 提供机会检讨项目是否有价值继续下去。 螺旋模型的缺点： 引入非常严格的风险识别，风险分析，和风险控制，这对风险管理 的技能水平提出了很高的要求。这需要人员，资金，和时阆的投入。 吸收了软件工程“演化”的概念，但要求许多客户接受和相信演化 方法并不容易。 1 7 太原理工大学硕士研究生学位论文 图2 - 4 螺旋模型 f i g u r e2 - 4s p i r a lm o d e l 项目实施螺旋模型的关键是对项目的认识和风险的掌控。螺旋模型更 适合于大型软件的开发，它对于具有高度风险的大型复杂软件系统的开发 是比较实际的方法。 2 2 5 能力成熟度模型( o m m ) 能力成熟度模型( c m m ) 是s e i 为了向美国联邦政府提供评价软件 开发商生产能力而产生的。它一问世就受到了广泛的支持。 c m m 提供了一个良好的工程和管理实践的五级模型，为软件企业提 供了改进的优先顺序。这个模型对象为五级的组织定义了1 8 个关键过程 区域、5 2 个目标、3 1 6 个关键实践及众多的子实践和例子。大多数软件组 织的成熟度级别都是“混乱”( c m m 一级) ，只有极少数是“优化”( c m m 五级) 。c m m 主要面向大型项目和大型软件组织。但是由于它是用非常通 用的方法定义的，适合不同组织的需要，所以经过剪裁后可以适合小项目。 c m m 的目标是达到过程一致、结果可预测、质量可靠。 和前面几个模型不同，c m m 强调的是软件过程的持续改进。过程改进 是一个持续不断、逐步优化的过程。尽管软件工程师和管理者可能对自己 存在的问题知之甚深，但在决定改进步骤和策略上却难以达成一致。这需 要组织视具体的情况，制定合适的改进策略，使组织通过过程改进走向更 1 8 太原理工大学硕士研究生学位论文 加成熟的发展。c m m 正式提供了一个这样的框架来管理软件组织逐步优化 的过程，它将一个组织的成熟能力分为5 个等级，每一较低等级都是其上 一等级的基础，从而使每一等级的实现具有连续、坚实的基础。 持续的过程改进包含许多小的、循序渐进的改进步骤，而不是跳跃式 的变革。c m m 提供了一个框架将这些渐进的步骤组织成5 个成熟度的级别， 为持续的过程改进奠定基础。5 个成熟度级别定义了度量组织软件过程和 评估软件过程能力的尺度，形成一个良好定义的，并螺旋式上升的阶梯式 的层次结构。 c m m 的各个级别都建立了一组的关键过程区域( k p a ) 。这些k p a 定义 了一组过程目标，对软件工程的过程能力提出了明确的要求。如果满足了 这组目标，则说明软件过程的某些重要活动已经稳定。随着成熟度级别的 上升，目标要求也逐步提高。促使组织有计划、有系统地走向更加成熟和 完美。c 删模型的5 级体系结构和5 个级别的k p a 如图2 5 所示。 当前，c m m 在软件工程的实践方面有很大影响，在工业界己得到广泛 接受，成为衡量软件公司组织管理软件产品开发能力的事实上的工业标 准，并为软件公司改善其生产过程提供了重要的依据。在c m m 的实施中， 有大量的成功案例，但也出现了不少的负面意见，下面是其中一些： c m m 模型提供了一个用于改进管理和软件产品的开发得详尽的结构 化模型。但它并没有提供如何去开发一个成功的软件产品的所有问题。 c 删定义了成熟的软件过程的实践活动，以及时间的例子，但它们 并不是完备的和独一无二的。c 删定义了一个有效的软件过程的特性，但 对于要达到软件成熟的复杂性来说，仅仅有过程是不够的。人的因素和技 术的因素也同样重要。 基于c m m 的过程改进即不便宜，也不迅速，使得不少企业对它望而 却步。根据一项调查，一个企业把成熟度提升一级平均需要两年，每年每 个软件工程师所需费用为1 3 7 5 美元。 2 2 6 传统方法的缺陷 软件开发工程化思想原本是起源于其他行业的工程化思想，由于借鉴 了工程化开发方式，在8 0 年代到9 0 年代这一个时期，软件产品开发质量 得到了巨大的、本质上的改善和提高。但到了当今，虽然我们的开发经验 越来越丰富，技术手段越来越高明，辅助工具越来越强大，相应的开发方 法学也越来越多，但我们的软件产品质量及生产效率却没有得到相应程度 的提高，似乎又进入了一个停滞阶段。分析其原因有三个： 1 9 太原理工大学硕士研究生学位论文 优化级( 5 ) 关注不断改进过程 过程变动管理 技术变动管理 缺陷防范 管理级( 4 ) 关注产品和质量 软件的质量管理 定量的过程管理 确定级( 3 ) 关注工程过程和组织支持 伙伴审查 组间协调 软件产品工程 综合软件管理 培训程序 组织的过程定义 组织的过程重点 可重复级( 2 ) 关注过程管理 软件配置管理 软件质量保证 软件子合同管理 软件项目的跟踪与监督 软件项目管理 需求管理 初始级( 1 ) 关注有竞争力人员和英雄 图2 - 5c m i i 的5 个成熟度等级以及它们的k p a f i g u r e2 - 5c m m s5m a t u r i t yg r a d e sa n d 乜k p a 首先一个问题就是分析和设计之间，以及设计和实现之问的鸿沟。其 2 0 太原理工大学硕士研究生学位论文 根本原因就是分析师、设计师和程序员活在不同的“世界”里。系统分析 人员不懂设计和实现，编程人员不懂分析和设计。它们之间在沟通上存在 着很大的问题。这个矛盾在软件开发行业的早期并不突出。当时系统没有 这么复杂，由于文档传递而造成的信息失真可以迅速得以更正。但随着系 统越来越大，功能越来越复杂，为保证正常开发的文档资料种类、级别越 来越多，内容越来越冗杂。大量的中间文档分散了开发者的精力，使他们 陷于文档的海洋而不能自拔。由于文档描述的不准确，以及个人理解上的 错误而产生的信息丢失越来越严重，导致开发的功能并非用户所需要的。 其次，标准、正规的开发方法在强调和实施一系列标准化的规程，用 他们来对丌发人员以指导和约束，使他们能够遵循规定的方法来理解和处 理问题，从而保证软件开发成功的时候，有意无意地在忽视、甚至是抹煞 软件开发本身是一个高度复杂的逻辑聚合体，它是开发人员不断思考和创 新的产物。软件开发人员本身积极、主动的创造性，以及整个软件开发小 组的高昂的士气，对于软件开发的成功同样是必不可少的。将软件开发等 同于其它领域已经发展的比较完善的工程建设，将软件开发人员简单的等 同于其他行业的随时可以替换掉的普通蓝领工人，无疑都是存在着相当大 的偏颇的。 最后，在开发过程中用户的“需求变化”受到了极大的限制。然而需 求变化是客观存在的，需求变化符合客户的利益。 当今，项目投资人为了适应经济全球化的激烈竞争，使开发出的软件 更有价值，在软件开发过程中可能主动进行以下选择，使用户需求变化更 为频繁、剧烈： 放弃的选择小至项目中的某些部分、大至整个项目都可以放 弃。只要能获得更大的利益，项目就可以不按照最初设想的形式交付使用。 转换的选择可以改变项目的方向。如果在项目完成的中途用 户可以改变需求，那么这个项目就更有价值。需求的改变越频繁、越剧烈， 这个项目就越有价值。 延期的选择可以等到形式明了后再投资。如果可以等待时机， 又不会完全失去投资机会，这个时候的项目价值就高。能够推延的时间越 长、能够延期投入的资金越多，效益就越好。 增加投资的选择如果某一市场即将腾飞，投资者可以快速增加投 资以便从中获得更大的利益。一个项目的伸缩性良好，在有更多投资的时 候能够适度成比例地扩大生产规模，那么这个项目就更有价值。项目扩张 得越快，时间越长，项目就越有价值。 人为限制需求变化在定程度上违反了客户的意愿，损害了客户的利 益，也间接损害了自身的利益。 2 1 太原理工大学硕士研究生学位论文 3 1 简介 第三章敏捷思维的基本理论 瀑布模型极力避免变化。传统方法起源丁瀑布模型，虽然为了适应现 实变化的需要，采取了很多措施来应对变化，但由于先天不足，面对实际 的需求变化常常疲于奔命，狼狈不堪。 世界在不断发展变化，传统方法很难保持不落伍。很明显它们不会永 远在任何环境下都适用。软件开发者认识到，为了更好地处理需求变化， 有必要采用新的实践。这些新实践应该是以人为本的、灵活的、有生产效 率的规则，而不应是包含一切、很容易在动态环境中被打破的规则。 c o c k b u m 和h i g h s m i t h 总结了新实践对传统方法的挑战冽： 1 顾客满意优先于按计划行事； 2 变化一定会发生。焦点是：不是怎样来阻止它的发生，而是怎样圆 满处理变化，在整个开发期降低变化的成本。 3 早期消除变化意昧着对业务条件的反应迟钝换句话说，业务将 失败。 4 市场需求和期望在上升，能够迅速交货的高质量软件才能满足市场 的需要。 作为对传统软件开发方法的反思，敏捷思维应运而生。它是文档驱动 的传统开发方法的替代物。在采用传统方法时，工作从试图得到全套的需 求文档开始，紧接着是结构设计、详细设计、编码、测试。在上世纪9 0 年代中期，一些软件界人士发现这些最初的步骤可能妨碍了他们的成功。 行业和技术在快速前进，需求在变化；用户越来越不能提前明确表达他们 的需求，同时却希望从软件中得到更多的功能，这使传统方法陷入了泥沼， 动弹不得。在这种情况下，为了应对他们遇见的不可避免的变化，少数业 界资深人士开始独立研究新方法、探索新实践，由此产生了敏捷思维。 g o l d m a n 对敏捷思维的目的做了一个很好的描述拶j ： 敏捷愚维是动态的、适直予具体情况的、拥艳变纯的和自我完善的， 它的目的不是提高效率、鹃减战本、做好准备扶两铯安全度过可怕昀金融 丽| 暴( 当然在开发实践中会起翻这些作甫) 而是在意业竞争中获得成 功。在激烈钓隶场竞争中赢得翻益、碾褥京场份额、赢得客户， 太原理= l = 大学硕士研究生学位论文 3 1 1 敏捷宣言l l o i 2 0 0 1 年初，一些反对文档驱动开发方法的新方法创造者在美国犹他 州举行会议，成立敏捷联盟。这些新方法包括极限编程( x p ) 、s c r u m ，水 晶方法、特征驱动开发( f d d ) 、动态系统开发( d s d m ) 、自适应开发( a s d ) 、 p r a g m a t i cp r o g r a m m i n g 等。会议后发表了他们的观点敏捷宣言： 敏捷思维不是反对力法论实际上。我们中的大多数希望恢复“方法“ 这个词的司信性：我们希望恢复平衡：我们欢迎模式但不是为7 把图表 归档放入满是荻尘的公司仓痒：我们欢迎文档，但不是数西页的钛来漫人 维护、a 乎没舂任饲甬处的厚睁的文档：我们许蛾但我们7 解在一个动 荡的环境中计翔的局限。宣言如下： 我们通过亲自傲这些和指导飘人实施找韵7 开发软件的较好方法， 通过i 终我们实现7 以下价值： ( 1 ) 较2 于过程和i 具更注重人及其相互作甬的价值： ( 2 ) 较之于面萄惧蓟的各类文档更注重司运行的软件的价值： n ) 较之于合同谈翔。更注重s 客户合作的价值； ( 4 ) 较2 于按计粕行事更注重响瘦需求变化的价值， 敏捷宣言已经成为敏捷运动的重要文件，它刻画了敏捷思维的价值， 将敏捷思维与传统方法区分开来。 个体和交互胜过过程和工具 人是获得成功的最为重要的因素。如果团队中没有优秀的成员，那么 就是使用好的过程也不能从失败中挽救项目，但是，不好的过程却可以使 最优秀的团队成员失去效用。如果不能作为一个团队进行工作，那么即使 拥有一批优秀的成员也一样会惨败。一个优秀的团队成员未必就是一个一 流的程序员。一个优秀的团队成员可能是一个平均水平的程序员，但是却 能够很好地和他人合作。合作、沟通以及交互能力要比单纯的编程能力更 为重要。一个由一般水平程序员组成的团队，如果具有良好的沟通能力， 将会比那些虽然拥有一批高水平程序员，但是成员之间却不能进行交流的 团队更有可能获得成功。 合适的工具对于成功来说是非常重要的。像编译器、i d e 、源代码控 制系统等，对于团队的开发者正确地完成他们的工作是至关重要的。然而， 工具的作用可能会被过分地夸大。使用过多的庞大、笨重的工具就和缺少 太原理工大学硕+ 研究生学位论文 工具一样，都是不好的。不要认为更大的、更好的工具可以自动地帮你做 得更好。通常，它们造成的障碍要大于带来的帮助。 我们认为，团队的构建要比环境的构建重要得多。许多团队和管理者 就犯了先构建环境，然后期望团队自动凝聚在一起的错误。相反，应该首 先致力于构建团队，然后再让团队基于需要来配置环境。 可以工作的软件胜过面面俱到的文档 没有文档的软件是一种灾难。代码不是传达系统原理和结构的理想媒 介。团队需要编制易于阅读的文档，来对系统及其发讨决策的依据进行拙 述。然而，过多的文档比过少的文档更糟。编制众多的文档需