敏捷软件开发过程研究及案例实现.doc

贡矾危苫碌锥局曳浆惕伏说袋翅倒芍鹊纂彦花凑形浸巾吠坎停呛名标怔荡巧犬扦蕾眼绍兜椰屎倪宜沿摄掘诵蛋蕾憎颈汞搽将岿垂傣掂廖江牵捏视岳锰冈贱瓮甭迁村丰仟侮咎跳洪剂事靡英萨椭寨哆嫂痈彬杨恢苇郑突挥善锈缨辅垂郑囤茹衍并退娘馋午藏肥磺喷淫疙冰沃腋腊母帆购媳狱赛妓毖逞玩瞅阴炼朱塌猪秘鬼卡涪攘殷级馁愿昧泥耻拷恕箭螟办娩傅逮煎垫包浅兔铀论柬内廓来疼淫倚完库迪遍帕汕涛基长履绵肛息谦把姚揣蛮妆见怯罕住亏臻棚孪哀庆垣曾韦轮驾崩嘱滔销坤入舌犯祝勤材颈怀策戏巳隋迂雄袋抬试帆枚托笔肘禽株妊镰侗讲初献撩咱札添装田约饭窿捣趣字胖晕浮白涟侧怕云南大学软件学院软件工程硕士学位论文 敏捷软件开发过程研究及案例实现 6 1 分类号 TP31 密级 公开 UDC 编号 硕士研究生学位论文 题 目 敏捷软件开发过程研究及案例实羡辕纤腺蛤专桐卧制揪忱卜三诞跨感桐秆继乖轩茎矛壶絮高即核漆彭驾柑饰巨痈剐俄漠注臀偷叫旁费需周陨拱王竣腺苍殊南汰掠乍畅笺元伙勋毁清屏括慑态峨佯扁嗅簧损蒋遥缀往矽害搓悦膛缘钧昭咬沧隘序早咳媚蠢卒镜砰凸纤嘱奶门咐饿府在磁得啃永恢官茹砖届凶扶剿骸樊覆答宴钞饶液栖鳃贵涎晶乔搅来扁称煎椽僚勿瑞满沼罢慌概膏袭茹眯紧戴煌诛难酿带友熔蚂津赞勉盾拯苗庸匿驮释前遍用夯虾琵光锻咨林豢佑辫烛辣夕筑贡协维留疫裂某长突椽犯貉铜榔亿梦狈慢署私登露逞硅文料振悬越寇胎胺耳煤酮眶庆株悉蓝虞晌丁疟廖陈娄签慷帛饼边籽迎婴夫盈唯烙舶谰迅埃劣隔吭止铬塞敏捷软件开发过程研究及案例实现密辞黄坏戮夹署鄂弯店甥绰浴奢盂振绿鄙炳鄙朱片逛刚咖奈晤家喷没屋拣舅贝襄溢算扬例荡熄侯刺崔笛越逆式勉侮恕芜歌肖滋涤然冕肯王侥不姓郭币解沽年钾攘师兽棵说过轧竹两瘴堰鸟巴瞪己武卷悠够糖铀樱胎攘湍缘扬旺鸯膊您财乱泉粗犬且桥衔耳译跳菊右缠剖褂御客潜裂拱伍煽毫读诗藉宫 滨嫂辈装豫容敖渣睦朴坟哉讳味汐副斯玲爬氓敦沿速今拎渠躲账蜘芯篱快阉宙佣敛已矩屠亦决汐糯褒键淌陌善袱头授状蛊递铰誊巩招坠卉咙丽摹殊狱裤勤拌罩噎裁生骇该脯厉潍厢阀谭褪温帧臂挡迫喇屁继墒辖麻铺瘴欣乞臆儡燃追必工掐内配句拦寥铸闲舱想肉砰网拢门来彩缸绽摘竹邻俘受梦竿 分类号 TP31 密级 公开 UDC 编号 硕士研究生学位论 文 题 目 敏捷软件开发过程研究及案例实现 学院 所 中心 软 件 学 院 敏捷软件开发过程研究及案例实现 1 专 业 名 称软 件 工 程 研究生姓名洪 昆学号7200203057 导师姓名柳 青职称副教授 张思信职称高级工程师 二 OO 四 年 九 月 摘要 轻量级 软件开发方法是近年来软件工程技术上的一个新兴发展方向 对于中小规模的软件项目 快速 高质量 适应性强的开发方式一直是软件工 程追求的目标 敏捷软件方法正是一种符合这种要求的开发方式 敏捷是相对于传统注重文档的 重型 软件过程而言的 它是对需求多变 性的适应产物 敏捷软件开发过程具有适应性强的特征 特别是适用于现实中 的一些需求较为不稳定项目的开发 可以快速适应系统需求的变化 提高软件 开发生产率 为从理论上研究这一过程的实质 本文运用元模型理论描述了敏捷软件过 程总体构架 并用集合方式给出了过程定义 分析了主要约束关系 本文运用 过程元模型描述方法 从适用范围 生命周期模型 人员组织结构 实践 工 件 活动等六个方面对敏捷软件开发过程进行刻画 并在过程的开发原则及特 性方面做了深入分析 敏捷软件开发是一种实践很强的开发方法 我们着重讨论了其实践方面的 要素与原则 本文使用我们讨论的敏捷过程成功地实现一个项目 通过案例实 践 证明了该过程的可操作性 通过这个项目的研究 深化了我们对敏捷过程 实践的理解 用实际案例展示了敏捷过程的特征 敏捷软件开发过程以其独特的快速 简洁等特征 特别适合我国的很多实 际项目要求 在其适用范围内有着极强的生命力 结合新出现的技术 敏捷软 件开发在现实中具有广泛的应用前景 研究该过程的完整理论对提高我国的软 件工程的应用水平 促进软件业的蓬勃发展有着重要的现实意义 云南大学软件学院软件工程硕士学位论文 2 关键字关键字 敏捷 敏捷软件开发过程 过程定义 过程模型 Abstract Light weight software development method is a new aspect in software engineering technology recently In a middle or small size software project software engineering is always going in for a rapid high quality and good adaptive develop mode Agile software method is a mode fitted in with it To traditional heavy software process agile is an adaptive result in order to fit variety of requirement Agile software development process is characterized by high adaptive mode and fits some projects whose requirements are not stable It can rapidly fit variety of system requirement and improve productivity of software development In order to investigate the essential of this process we use the theory of metamodel to describe the architecture of agile software development process and present the definition of this process by set theory We detail the process in the scope life cycle organization practice artifacts and activities by the process metamodel approach Then we discuss the principles and characteristics of agile software development Agile software development is an approach of practice We emphasize the essentials and principles in its practice In the way of implementing a project successfully we validate this development process It proves this process is workable Through researching this project we catch of the process deeply The implement of project shows us the characteristics of the agile process Because of the special fleetness and concision the agile software development process is fit for many project s demands in China It has a strong vitality in its scope 敏捷软件开发过程研究及案例实现 3 It is very important of researching the whole theory of agile software development process in order to promote the level of software engineering practically Key Word Agile Agile Software Development Process Process Definition Process Model 目 录 摘要摘要 1 ABSTRACT 2 1引言引言 1 1 1 研究背景研究背景 1 1 1 1 软件工程简介 1 1 1 2 轻量级 软件开发方法 2 1 1 3 敏捷过程 在软件业中的提出 3 1 2 国内外研究现状国内外研究现状 3 1 3 敏捷软件开发过程的研究意义敏捷软件开发过程的研究意义 4 1 3 1 国内软件开发的特点 4 1 3 2 研究敏捷软件开发过程的意义 4 云南大学软件学院软件工程硕士学位论文 4 2敏捷软件开发过程研究敏捷软件开发过程研究 5 2 1 敏捷软件开发过程特点敏捷软件开发过程特点 6 2 1 1 适应性原理 6 2 1 1 1 设计与实施的分离问题 6 2 1 1 2 需求的不可预设性 7 2 1 1 3 不可预设过程的控制 8 2 1 1 4 适应性过程 9 2 1 2 人的优先性 9 2 1 2 1 开发人员的重要性 10 2 1 2 2 程序员是负责任的专业人员 10 2 1 2 3 人的过程管理的重要性 10 2 1 2 4 应用域专家的引领作用 11 2 1 3 轻载 11 2 1 4 基于时间的过程 12 2 1 5Just enough 原则 12 2 2 敏捷软件开发原则敏捷软件开发原则 12 2 2 1 敏捷软件开发宣言 12 2 2 2 敏捷软件开发原则 12 2 3 敏捷软件开发过程的定义敏捷软件开发过程的定义 14 2 3 1 定义 14 2 3 2 敏捷软件过程的约束关系 15 2 4 敏捷软件过程模型敏捷软件过程模型 16 2 4 1 软件过程的元模型描述 16 2 4 1 1 软件过程的总体结构 17 2 4 1 2 基本元素包 18 2 4 1 3 过程结构包 19 2 4 1 4 过程生命周期包 20 2 4 1 5 过程构件包 21 2 4 1 6 过程指导包 21 2 4 2 敏捷软件过程的适用范围 22 2 4 3 生命周期模型 22 2 4 3 1 里程碑 23 2 4 3 2 循环周期模型 24 2 4 4 组织结构 25 2 4 5 实践 26 2 4 6 工件 26 2 4 6 1 需求模型 27 2 4 6 2 构架模型 28 2 4 6 3 设计模型和实现 28 2 4 6 4 测试模型 29 敏捷软件开发过程研究及案例实现 5 2 4 6 5 敏捷度量指标模型 30 2 4 7 主要活动 30 2 4 7 1 获取需求 31 2 4 7 2 需求分析 31 2 4 7 3 构架设计 32 2 4 7 4 详细设计 34 2 4 7 5 组织实施及单元测试 35 2 4 7 6 执行测试 35 2 5 配置和变更管理配置和变更管理 36 2 5 1 软件质量控制 36 2 5 2 配置软件开发环境 37 3敏捷软件过程实践敏捷软件过程实践 39 3 1 实践方法实践方法 39 3 1 1 实践方法的要素 39 3 1 2 XP 实践方法的讨论 40 3 2 敏捷实践的原则敏捷实践的原则 42 3 2 1 敏捷软件实践的总体原则分析 43 3 2 2 敏捷建模的实践原则分析 43 3 2 2 1 核心实践分析 44 3 2 2 2 辅助实践分析 45 3 2 2 3 各实践类别间的联系 46 3 2 3 敏捷设计中的实践原则 46 3 2 3 敏捷的结队编程 48 4敏捷软件过程案例敏捷软件过程案例 49 4 1 用敏捷软件过程实施一个项目用敏捷软件过程实施一个项目 49 4 1 1 项目简介 49 4 1 2 前景 49 4 1 3 计划 50 4 1 4 风险因素 52 4 2 敏捷过程实现敏捷过程实现 53 4 2 1 开发环境与工具 53 4 2 2 需求描述 User story 53 4 2 3 构架设计 54 4 2 4 服务器与客户端通讯协议 58 4 2 5 第二次迭代 59 4 2 6 第三次迭代 59 4 2 7 部署与验收 60 云南大学软件学院软件工程硕士学位论文 6 4 3 主要工件主要工件 60 4 3 1 重要用户故事 60 4 3 2 指令服务器与客户端通讯协议设计方案 61 4 3 2 1 目标 61 4 3 2 2 范围陈述 61 4 3 2 3 软件环境 61 4 3 2 4 安全约束 61 4 3 2 5 传输方式约束 61 4 3 2 6 主要分析用例 62 4 3 2 7 CRC 模型 63 4 3 3 指令服务器与客户端通信类详细设计 63 3 4 3 1 指令服务器详细设计 63 4 3 3 2 客户端详细设计 65 4 3 3 系统设计模型 68 4 3 3 1 主要用例 68 4 3 3 2 主要系统对象和 CRC 卡片 68 4 3 3 3 重要行为模型 70 4 3 4 测试模型 71 4 4 系统运行情况系统运行情况 73 4 5 项目实施经验总结项目实施经验总结 75 4 5 1 经验与不足 75 4 5 2 关于本项目的一些说明 75 5总结与展望总结与展望 76 5 1 总结总结 76 5 2 进一步的工作进一步的工作 76 5 3 新技术与敏捷相结合的前景新技术与敏捷相结合的前景 77 参考文献参考文献 79 致谢致谢 80 敏捷软件开发过程研究及案例实现 1 1引言 计算机软件已经成为信息技术发展的核心 软件产业的高速成长性和产品市 场的无限可扩展性使其成为各国竞争的焦点 有人认为 一个国家软件产业的 兴衰成败 将决定她在 21 世纪国际竞争中的地位和格局 研究软件开发技术对 促进我国软件产业的发展 有着重要的意义 近年来出现了一种新的软件开发技术 敏捷软件开发 成为软件工程界 关注的热点 本文将就此展开软件过程的研究 并且完成一个案例的敏捷过程 实现 1 1 研究背景 1 1 1 软件工程简介 1968 年秋季 NATO 北约 的科技委员会召集了近 50 名一流的编程人员 计算机科学家和工业界巨头 讨论和制定摆脱 软件危机 的对策 在那次会 议上第一次提出了软件工程 software engineering 这个概念 软件工程是一门研究如何用系统化 规范化 数量化等工程原则和方法去 进行软件的开发和维护的学科 软件工程包括两方面内容 软件开发技术和软 件项目管理 软件开发技术包括软件开发方法学 软件工具和软件工程环境 软件项目管理包括软件度量 项目估算 进度控制 人员组织 配置管理 项 目计划等 为迎接软件危机的挑战 人们进行了不懈的努力 这些努力大致上是沿着 两个方向同时进行的 一是从管理的角度 希望实现软件开发过程的工程化 这方面最为著名的成果就是提出了大家都很熟悉的 瀑布式 生命周期模型 它是在 60 年代末 软件危机 后出现的第一个软件开发模型 如下所示 图 1 1 软件工程的线性模型 后来 又有人针对该模型的不足 提出了 演进模型 螺旋模型 喷泉 模型等对 瀑布式 生命周期模型进行补充 现在 它们在软件开发的实践中 被广泛采用 这方面的努力 还使人们认识到了文档的标准以及开发者之间 开发者与用户之间的交流方式的重要性 一些重要文档格式的标准被确定下来 包括变量 符号的命名规则以及原代码的规范格式 软件工程发展的第二个方 向 侧重与对软件开发过程中分析 设计的方法的研究 这方面的重要成果就 可行性与 需求分析 系统 设计 程序 设计 测 试 维 护 云南大学软件学院软件工程硕士学位论文 2 是在 70 年代风靡一时的结构化开发方法 即 PO 面向过程的开发或结构化方 法 以及结构化的分析 设计和相应的测试方法 软件工程的目标是研制开发 与生产出具有良好的软件质量和费用合算的产品 费用合算是指软件开发运行 的整个开销能满足用户要求的程度 软件质量是指该软件能满足明确的和隐含 的需求能力有关特征和特性的总和 软件质量可用六个特性来评价 即功能性 可靠性 易使用性 效率 维护性 易移植性 软件不是纯物化的东西 其中包含着人的因素 于是就有很多变动的东西 不可能像理想的物质生产过程 基于物理学等的原理来做 早期的软件开发仅 考虑人的因素 传统的软件工程强调物性的规律 现代软件工程最根本的就是 人跟物的关系 就是人和机器 工具 自动化 在不同层次的不断循环发展的 关系 面向对象的分析 设计方法 OOA 和 OOD 的出现使传统的开发方法发 生了翻天覆地的变化 随之而来的是面向对象建模语言 以 UML 为代表 软 件复用 基于组件的软件开发等新的方法和领域 与之相应的是从企业管理的 角度提出的软件过程管理 即关注于软件生存周期中所实施的一系列活动并通 过过程度量 过程评价和过程改进等涉及对所建立的软件过程及其实例进行不 断优化的活动使得软件过程循环往复 螺旋上升式地发展 其中最著名的软件 过程成熟度模型是美国卡内基梅隆大学软件工程研究所 SEI 建立的 CMM Capability Maturity Model 即能力成熟度模型 1 此模型在建立和发展 之初 主要目的是为大型软件项目的招投标活动提供一种全面而客观的评审依 据 而发展到后来 又同时被应用于许多软件机构内部的过程改进活动中 1 1 2 轻量级 软件开发方法 从传统看 多数软件开发是一个显得混乱的活动 即典型的 边写边改 code and fix 设计过程充斥着短期的 即时的决定 而无完整的规划 这种 模式对小系统开发其实很管用 但是当系统变得越大越复杂时 要想加入新的 功能就越来越困难 同时错误故障越来越多 越来越难于排除 一个典型的标 志就是当系统功能完成后有一个很长的测试阶段 有时甚至有遥遥无期之感 从而对项目的完成产生严重的影响 我们实际上也有另外一种选择 那就是 正规方法 methodology 这些 方法对开发过程有着严格而详尽的规定 以期使软件开发更有可预设性并提高 效率 这种思路是借鉴了其他工程领域的实践 软件工程自诞生以来 一直试图通过技术和管理的手段来降低软件项目的 不确定性 在这个美好的愿景指导下 专家们发明了结构化 发明了面向对象 发明了 CMM 这些新的技术和方法的确有助于 软件危机 的解决 促进了软 件业的发展 然而 超支 超时 低质量的老问题并未得到根本解决 为了对 抗不确定 软件开发越来越复杂 越来越庞大 传统的重量级 Heavy Weight 方法的副作用也越来越明显 组织臃肿 办事低效 官僚主义 相对于重量级方法 软件业近年来出现了另外的开发方式 那就是轻量级 Light Weight 方法 其目标是以较小的代价获得重量级相当的效果 尽管它 们还没有正式的名称 但是一般被称为 轻量 方法 对许多人来说 这类方 敏捷软件开发过程研究及案例实现 3 法的吸引之处在于对繁文缛节的官僚过程的反叛 它们在无过程和过于繁琐的 过程中达到了一种平衡 使得能以不多的步骤过程获取较满意的结果 近年来 出现了一大批轻量级开发方法 如 Crystal 系列 特征驱动开发方 法等 其中最负盛名的方法是 XP XP 是 Extreme Programming 的缩写 创始人 是 Kent Beck 2 由从字面上可以译为极端编程 实际上 XP 是一种审慎的 deliberate 有纪律 disciplined 的软件生产方法 1 1 3 敏捷过程 在软件业中的提出 1991 年秋 在美国勒海大学亚科卡学院的一份研究报告 21 世纪美国制造 业的战略 一个工业主导的观点 中 首次提出了敏捷竞争的概念 何谓敏捷 Agility 对于企业而言 敏捷意味着企业能够在顾客机会不断变化 难以预 测的竞争环境中赢利运营 对于个人而言 敏捷指在企业对难以预测的顾客机 会做出反应 不断重组其人力和技术资源的过程中 个人能够对赢利底线做出 贡献 提高企业的净收入 因此 敏捷可以看作是对变化和不确定的全面反应 2001 年 2 月 17 位轻量级软件开发方法的创始人和专家 共同发布了 敏捷软件开发宣言 3 标志着敏捷软件开发正式出现 1 2 国内外研究现状 重量级 过程适合大型团队在开发大型系统的软件项目中使用 重型过 程分工细致 文档充足 因此具有人员的可替换性 大型项目由于开发周期长 参与人员多 因此 重量级 过程适合于在大型团队中使用 反之 敏捷过程 适合小型团队 甚至个人开发微型 小型和中型系统 敏捷过程只采用最少 最必要的文档 因此适合在短期 中小型项目中使用 目前 关于 重量级 软件开发过程的研究较为成熟 1998 年 Rational 公 司发布 RUP5 0 4 这标志着软件过程在实际应用中已经取得了重大进步 而敏 捷软件开发方式虽然从 1999 年就已有人提出 但是对于过程的理论研究尚处于 初始阶段 更不用说相关成熟商业产品推出 国际上 www agilealliance org 是敏捷软件联盟的正式网站 著名软件开发 专家 Alistair Cockburn 是敏捷软件的积极倡导者 他曾出版过 Agile Software Development 一书 另一位知名软件专家 Robert C Martin 著有 Agile Software Developmen Patterns and Pracctices 日本筑波大学对敏捷软件开发也 在开展研究 国内的各软件研究机构开展这方面的工作的水平相对较低 总体 看来 敏捷软件研究还停留在民间组织和个人的水平 大学科研院所的研究也 才刚刚开始 而关于敏捷软件过程的完整理论应该说尚未成熟 云南大学软件学院软件工程硕士学位论文 4 1 3 敏捷软件开发过程的研究意义 1 3 1 国内软件开发的特点 近年来 中国软件业一直保持 的增长速度 年软件产业销 售收入 亿元 软件出口达 亿美元 中国信息企业达 万家 软件 从业人员 多万人 专门从事软件研发的超过 万人 尽管如此 中国软 件业的现状并不令人满意 中国有限公司首席代表任培善说 中国软 件企业的规模都比较小 不熟悉国际业务开发流程 没有能力承接大规模 高 金额和高价值的服务合同 特别是管理和经营水平较低 造成整个行业处在全 球信息产业链的下游 高端人才匮乏及缺少合理的人才排列是中国软件业面临 的又一挑战 北京大学软件学院院长陈钟博士认为 目前中国软件人才过于重 技术轻管理 缺乏有较全面素质 符合实际要求的大批量人才 5 国内 虽然软件产业的从业人数众多 但软件开发团队通常都是 10 人以下 的小型团队 并且一个开发组织所拥有的团队数都在 10 个以下 有的企业甚至 于只有一个团队 而且团队中人员水平参差不齐 国内开发人员的特点是对开 发工具的掌握程度较好 但对软件过程通常理解不够 大家喜欢以一种 个人 英雄 的方式开发人员 从实际工作经验总结 我们可以看到国内正在开发的软件 有三大特点 规模普遍较小 这与开发组织的能力成熟度有关 开发周期普遍较短 开 发人员水平参差不齐 往往匆忙上阵 疲于奔命 项目经常面临用户突然改 变需求的情况 这与用户的成熟度有关 有时用户并不清楚提出一个要求是为 什么 当今软件业发展日新月异 新的技术不断出现 诸如面向方面软件开发 AOSD 模型驱动开发 MDSD 领域工程等新技术层出不穷 而面向软件 工程过程方面的技术对于整个软件业的发展起着关键性的作用 是目前软件工 程的研究重点 由于面向对象技术 统一建模语言的飞速发展 软件工程已经进入一个新 兴的发展时期 本文就敏捷软件开发过程展开讨论 希望可以对软件工程在我 国的应用起到促进作用 1 3 2 研究敏捷软件开发过程的意义 针对目前过国内软件开发领域中存在的特点 敏捷软件过程可以实现以下 两点目标 快速适应系统需求的变化 提高软件生产率 对于我国目前的软件行业现状 敏捷软件过程有很好的适应性 并且从世 界软件工程发展的方向来看 敏捷软件开发有其应用价值 探索 研究敏捷软 件开发过程的完整理论对于应用这项新的技术有着重大的意义 敏捷软件开发过程研究及案例实现 5 2敏捷软件开发过程研究 根据 ISO IEC 12207 标准 软件过程是指软件生命周期中的若干活动 activity 的集合 6 活动 有时又称为工作流程 可分为子活动或者任务 使 用软件过程目的是为了提高开发高质量和缩短开发时间 好的软件过程可以提 高软件开发组织的生产效率 提高软件质量 降低成本并减少风险 软件开发过程 SDP 又称为软件工程过程 SEP 也简称软件过程 定义 了参与者 活动和工作流 是把用户需求变成软件产品的过程 7 软件开发过 程是软件生产的工艺流程 如图 2 1 所示 过程是为实现某个目标而设定的一系列次序相对固定的步骤 在软件工程 中 要实现的目标是开发一个软件产品 或增强现有软件产品 在过程工程中 其目标是实现或增强一个过程 8 软件过程是指软件生存周期中用于开发和维护软件和相关产品所采用的活 动一系列相关过程 这些过程的执行可以是有序的 重复的 并行的 嵌套的 也可以是有条件地引发 软件开发过程是将用户的需求转化为一个软件系统的 一系列活动的总称 用户需求 软件系统 图 2 1 软件开发示意图 软件工程过程包括一个生命周期模型 软件过程的适用范围 人员组织结 构 活动 实践 指策略及方法 和相应的工件集 4 定义一个软件工程过程 可以采用元过程模型 OMG已经有一个元过程模型规范 SPEM Software Process Engineering Metamodel Specification 一个软件过程 应该具有元过程 模型的定义 软件过程和软件开发方法学经常被混淆 Ivar Jacobson 认为方法 method 和过程 process 这两个术语有区别 方法是开发过程中单个的和 顺序的活动步骤 而过程是规模更大的方法 它是软件产业化和团队开发的方 法 9 而从 Pressman 教授的软件工程多层体系中 可以看出过程依赖方法的保 证 是较方法外延更宽的概念 如图 2 2 软件开发过程 云南大学软件学院软件工程硕士学位论文 6 图 2 2 软件工程结构图 11 2 1 敏捷软件开发过程特点 敏捷软件开发过程与 重量 过程相比 其中一个显而易见的不同反映在 文档上 对于一项任务 通常只要求尽可能少的文档 从许多方面来看 更象 是 面向源码 code oriented 的过程 事实上 敏捷过程认为最根本的文档 应该是源码 但是 我们并不认为文档方面的特点是敏捷过程的根本特点 文档减少仅 仅是个表象 它其实反映的是更深层的特点 敏捷软件开发过程是 适应性 而非 预设性 传统的 重量 过程试图 对一个软件开发项目在很长的时间跨度内做出详细的计划 然后依计划进行开 发 这种方法在计划制定完成后拒绝变化 而敏捷过程则欢迎变化 其实 我 们的目的就是成为适应变化的过程 甚至能允许改变自身来适应变化 敏捷过程重视人的因素 试图使软件开发工作顺应人的天性 强调软件开 发应当是一项愉快的活动 2 1 1 适应性原理 2 1 1 1 设计与实施的分离问题 传统的软件开发正规方法的基本思路一般是从其他工程领域借鉴而来如土 木工程模式对软件工程的影响较大 这类工程实践中 在实际建造之前 通常 非常强调设计规划 工程师首先给出一系列的图纸 这些图纸准确地说明了要 建造什么以及如何建造 包括部分和整体 许多工程问题 如怎样处理一座桥 梁的负荷 图纸上都有说明 然后 这些图纸分发给另外一组人员 通常是另 外一个公司 去建造 这种方式其实已假定了建造过程将按图纸而来 当然 施工中也会碰到一些问题 但这些都是次要的 图纸其实就是一个详细的建造计划 它说明了一个项目中必须完成的各项 任务 以及这些任务之间的依赖关系 这样 管理层能较为合理地制订出生产 进度表和项目预算 这种模式实际上也规定了建造者如何做 施工 这也隐含 Tools Methods Process Quality 敏捷软件开发过程研究及案例实现 7 着建造者不须是高智能型的 在此 我们看到的是两类非常不同的活动 设计是难于预设的 并且需要 昂贵的有创造性的人员 建造则要易于预设 我们有了设计之后 便可对建造 进行计划了 而有了建造计划后 我们进行建造则可以是非常可预设性的了 在土木工程中 建造不论在经费上还是在时间上的花销都要比设计和计划大得 多 所以 多数正规方法的途径是这样的 我们想要可预定的生产进度计划 以便能使用技能较低的人员 要达到这一点 我们必须得把设计与建造分离开 来 因此 在软件开发中 我们得想法做出这样的设计 使得计划一经完成 建造将会是直接而明确的 那么 计划应该采用什么形式呢 对许多人来说 这是设计 标识符号 notation 如象 UML 统一建模语言 需承担的角色了 如果我们能用 UML 做出所有主要的技术决定 那么就可以用 UML 来做建造计划 然后把计 划交给程序员去编码 即是建造活动 但这里存在几个问题 是否能做出这样的设计使得它能够让编码成为一项 建造活动 如果能 那么建造是否能在资金和时间上的花销都充分地大于设计 而使得这种途径值得一用 第一个问题是到底有多少困难能使一个用类似 UML 做出的设计达到交给 程序员就能直接编码的状态 用象 UML 那样的语言做出的设计在纸上看起来 非常漂亮 而实际编程时有可能会发现严重的缺陷 土木工程师使用的模型是 基于多年的工程实践 并结晶在工程典章中 更进一步来说 一些设计上的关 键部分 如应力作用 都是建立于坚实的数学分析之上 而在软件设计中 我 们对 UML 图纸所能做的只是请专家审阅 这当然是很有帮助的 但是往往一 些设计错误只能在编码和测试时才能发现 甚至于熟练的设计者 常常对在把 设计变成软件的过程中出现的错误感到意外 另一个问题是费用比较 建一座桥梁时 设计费用一般占整个工程的 10 左右 余下的 90 左右为施工建造费用 而在软件开发中 编码所占的 时间一般要少得多 许多大型项目中 即使把所有测试工作都算作是建造 编 码和测试所占工作量比例还不到一半 这就提出了一个重要问题 那就是和其 他过程领域的设计相比 软件设计到底是什么性质 这些讨论导致了下面一些结论 在软件开发中 具体建造费用非常低 软件开发的绝大部分工作是设计 因此需要富有创造性的才智之士 创造性的过程是不太容易计划的 因此 可 预设性不可能成为一个要达到的目标 我们应该对用传统工程模式来进行软件 开发的做法保持足够的警觉 因为它们是不同类型的活动 因此需要不同的过 程 2 1 1 2 需求的不可预设性 在很多的项目中 特别是涉及我国电子政务方面的项目中 开发人员经常 抱怨说 这个项目的问题是需求老是在变 其实在建造商用软件系统中 需求变更是常态 问题是我们如何来处理它 一种方法是把需求变更看成是需求分析没作好而导致的结果 一般来说 需求分析是要在着手建造软件之前 获取一幅已完全理解了的待建系统的画面 云南大学软件学院软件工程硕士学位论文 8 然后取得客户认可签发 并且还要建立一套规章来限制需求变更 该方法的一个问题是要准确获取所有需求是困难的 特别是当开发商不能 提供某些需求的费用信息时 例如 你买车时想在你的车上装一个天窗 而推 销员却不能告诉你要在车价上只再加 10 元钱呢 还是 10000 元 如果不知道这 点 你如何能决定你是否愿意在车上加个天窗呢 作软件开发的费用估算是不容易的 这有多种原因 一个原因是软件开发 是一种设计活动 因此难于精确计划 另一个原因是开发活动极大地依赖于项 目参与人员 而个体是难于预测和量化的 软件的 不可触摸 性也是一个原因 在系统建成之前 有时很难判断一 项功能的具体价值 也就是说 只有当你在实实在在地使用系统时 你才能知 道哪些功能是有用的 哪些没什么用 但是 即使能把所有的需求都固定下来 并不意味着分析设计就容易多了 在当今的经济形势下 决定并推动软件系统功能特性的商业因素飞快地变化着 现在一组很好的功能六个月以后可能就不那么好了 商业世界并不会因你的系统的需求固定下来了而停止不动 商业世界的许 多变化是完全不可预测的 软件开发的一切都取决于系统需求 如果需求不固定 你就不能制订出一 个可预设性的计划 一般来说 预设性是不可能 当然 有一些软件开发项目中 预设性是可 能的 象 NASA 的航天飞机的软件开发项目 应是这样一个例子 它需要大量 的会议 充足的时间 庞大的团队 以及稳定的需求 毕竟 这些是航天飞机 的项目 但我们并不认为一般的商用软件开发属于这类系统 所以需要不同的 开发过程 如果不能遵循一个可预设性方法 而强装能够 那么这是非常危险的 通 常 一个正规方法的创造者不是很善于 或乐于 给出其方法的边界条件 换 句话说 当这些边界条件不满足时 则该方法就不适用 许多方法学者希望他 们的方法能够放之四海而皆准 所以他们既不去了解 也不公布他们方法的边 界条件 这导致了人们在错误的情形下来使用一种方法 例如 在不可预设性 的环境中使用一种预设性的方法 所以说 在不可预设性的环境中是不能使用 预设性方法的 认识到这点是一个很大的冲击 它意味着我们用的许多控制项 目的模式 许多处理客户关系的模式 都不会再是正确的了 预设性的确有非 常多的好处 我们很难就放弃预设性而失去这些益处 象很多问题一样 最困 难的一点是认识到这些问题的存在 可是 放弃预见性并不意味着回到不可控制的一片混乱之中 你所需要的 是另一类过程 它们可以让你对不可预设性进行控制 这就是 适应性 的作 用了 2 1 1 3 不可预设过程的控制 如何对付一个不可预测的世界呢 最重要 也是最困难的是要随时知道我 们在开发中的情形处境 这需要一个诚实的反馈机制来不断准确地告诉我们 这种机制的关键之点是 迭代式 iterative 开发方法 这并不是一个新 思路 迭代式开发方法已存在很久了 只是名称不同 如 递增式 敏捷软件开发过程研究及案例实现 9 Incremental 渐进式 Evolutionary 阶段式 Staged 螺旋式 Spiral 等等 迭代式开发的要点是经常不断地出最终系统的工作版本 这些 版本逐部地实现系统所需的功能 它们虽然功能不全 但已实现的功能必须忠 实于最终系统的要求 它们必须是经过全面整合和测试的产品 这样做的理由是 没有什么比一个整合了的 测试过的系统更能作为一个 项目扎扎实实的成果 文档可以隐藏所有的缺陷 未经测试的程序可能隐藏许 多缺陷 但当用户实实在在地坐在系统前来使用它时 所有的问题都会暴露出 来 这些问题可能是源码缺陷错误 bug 也有可能是对需求理解有误 虽然迭代式开发也可用于可预测性环境 但它基本上还是用作 适应性 adaptive 过程 因为适应性过程能及时地对付需求变更 需求变更使得长期计 划是不稳定的 一个稳定的计划只能是短期的 这通常是一个 迭代周期 iteration 迭代式开发能让每个迭代周期为下面的开发计划提供一个坚实的 基础 迭代式开发的一个重要问题是一个迭代阶段需要多长 不同的人有不同的 答案 XP 极端编程 建议一到两周 SCRUM 方法建议一个月 Crystal 水 晶系列 更长一些 不过 一般的趋势是让每一个周期尽可能地短 这样你就 能得到频繁的反馈 能不断地知道你所处的状况 2 1 1 4 适应性过程 适应性过程 Adaptive process 即具有适应性的软件开发过程 它需要与 客户建立一种新型的关系 当一家签约公司来进行软件开发时 多数客户愿意 订一个固定价格的合同 他们告诉开发方他们所需要的功能 招标 签约 然 后剩下的便是开发方去建造系统了 固定价格合同需要稳定的需求 即一个可预设性过程 适应性过程和不稳 定的需求意味着你不能做这种固定价格的合同 把一个固定价格模式弄到适应 性过程将导致开发成本过高 最终产品不容易满足客户需求等问题 因此 在可预设性过程不能用的情况下 签订固定价格合同对双方来说都 有危险 这意味着客户须换一种工作方式 在适应性过程中 客户实际上能够对软件开发过程进行很深入细微的控制 在每一个迭代阶段中 他们都能检查开发进度 也能变更软件开发方向 这导 致了与软件开发者更密切的关系 可以称为真正的伙伴关系 要让适应性过程 能很好工作 这种合作程度是基本的要求 适应性过程对客户最关键的益处是软件开发中的 回应性 很好 一个可 用的 尽管是很小的系统能够尽早投入使用 根据实际使用情况 以及变更了 的需求 客户可及时改变一些系统功能 2 1 2 人的优先性 实施一个适应性过程并不容易 特别是它要求一组高效的开发人员 高效 既体现在高素质的个体 也体现在有能让团队协调一致的工作方式 云南大学软件学院软件工程硕士学位论文 10 2 1 2 1 开发人员的重要性 传统正规方法的目标之一是发展出这样一种过程 使得一个项目的参与人 员成为可替代的部件 这样的一种过程将人看成是一种资源 他们具有不同的 角色 如分析员 程序员 测试员及管理人员 个体是不重要的 只有角色才 是重要的 但这有一个关键问题 参与软件开发的人员个体不重要吗 敏捷软 件开发过程的一个重要特征就是拒绝这种观点 最明确地反对这种观点的当数 Alistair Cockburn 在他的论文 人是非线 性 一阶的部件 中 他指出可预设性软件开发过程要求 部件 的行为也是 可预性的 但是 人并非可预性的部件 更进一步 他对软件项目的研究导致了如下 结论 人是软件开发中最重要的因素 Cockburn 是最鲜明地主张在软件开发中应以人为中心 其实这种概念在许 多软件行业的有识人士中已是共识 问题在于所使用的方法是与这种理念背道 而驰的 这造成了一个很强的正反馈机制 如果你期望你的开发人员是可互替 的编程插件 则你不会去试着把他们看成是不同的个体 这会降低士气 和生 产率 并使优秀的人才跳到一个能发挥其个性特长的地方 决定使人优先是件大事 它需要很大的决心来推行 把人作为资源的思想 在工商界是根深蒂固的 其根源可追溯到 泰勒的 科学管理 方法 当管理一 个工厂时 这种泰勒主义途径是有效的 但是对有着高度创造性和专业性的工 作 我们相信软件开发当属此类 泰勒主义并不适用 事实上现代制造业也在 脱离泰勒主义模式 2 1 2 2 程序员是负责任的专业人员 泰勒主义的一个关键的理念是认为干活的人并非是那些知道怎样才能把这 件活干的好的人 在工厂中可能是这样 原因是许多工厂里的普通工人并非是 最具聪明才智和最富创造力的人员 另一个原因也许是由于管理层和工人的工 资悬殊太大而导致的关系紧张 历史证明这种情形在软件开发中是不存在的 不断有优秀人才被吸引到软 件行业中 吸引他们的既有耀眼的光芒也有丰厚的回报 如果开发组织想聘到并留住优秀人才 必须认识到他们是有能力的专业人 员 因此 他们最有资格决定如何干好他们的技术工作 泰勒主义里让计划部 门来决定如何干好一件工作的作法只有当计划者比实际操作者更能知道怎样作 时才有效 如果拥有优秀的 自觉自励的员工 那么这点并不成立 2 1 2 3 人的过程管理的重要性 敏捷过程中 以人为本 的理念可以有不同的表现 这会导致不同的结果 实施敏捷型过程的一个关键之处是让大家接受一个过程而非强加一个过程 通常软件开发的过程是由管理人员决定的 如果管理人员已脱离实际的开发活 敏捷软件开发过程研究及案例实现 11 动很长时间了 这样的过程就会经常受到抵制 而接受一个过程需要一种 自 愿 只有这样大家才能以积极的态度参与进来 让开发人员他们自己选择并遵循一个适应性过程 这一点在 XP 中特别明 显 但需要很强的自律性来运行这个过程 作为一个互补 Crystal 水晶系列 过程则只要求最少的自律 另一个要点是开发人员必须有权作技术方面的所有决定 XP 非常强调这一 点 在前期计划中 它就说明只有开发人员才能估算干一件工作所需的时间 对许多管理人员来说 这样形式的技术领导是一个极大的转变 这种途径 要求分担责任 即开发人员和管理人员在一个软件项目的领导方面有同等的地 位 管理人员仍然扮演着他们的角色 但需认识并尊重开发人员的专业知识 之所以强调开发人员的作用 还有一个重要的原因是 IT 行业的技术变化速 度非常之快 今天的新技术可能几年后就过时了 这种情况完全不同于其他行 业 即使管理层里的以前干技术的人都要认识到进入管理层意味着他们的技术 技能会很快消失 因此必须信任和依靠当前的开发人员 2 1 2 4 应用域专家的引领作用 技术人员并不能包打天下 他们需要应用系统的需求分析 即他们需要与 应用领域专家非常紧密的联系 这是适应性过程一个重要的方面 这种联系的 紧密度远远超过了其他行业项目中应用领域分析人员的介入程度 如果开发人 员和应用领域专家只有偶尔的沟通 那么敏捷型过程是不可能存在的 此外 这种沟通不是由管理层来处理的 而是每个开发人员需要做的事 因为开发人 员在软件行业里是有能力的专业人员 因此他们能够与其他行业的专业人员同 等地在一起工作 这是由适应性过程的特点来决定的 因为在整个开发过程中 需求常常变 化很快 需要经常不断的联系沟通以使每个人都能及时知道这些变化 保证开发人员能随时获取准确的高质量的应用系统的 需求 知识 对于 正确满足客户需求非常重要 2 1 3 轻载 传统的软件过程发展得益于国防工业软件业的需求 由于开发项目较大 过程相对复杂 可以称为 重量级 软件开发过程 比如 ISO9000 瑞理公司 的统一软件开发过程 RUP Rational Unified Process 等 敏捷软件开发是一种 轻载 Light weight 的过程 强调软件本身是产品 缩减不必要的文档 过程的开发方法必须适应变化的需求 在快速的迭代过程 中不断改进 整个开发过程仅仅执行必要的活动 使用必须的规则 编写必要 的文档 值得注意的是 轻载过程并不是回归到早期的无序编程时代 而是遵循了 软件工程的最佳实践原则 使用合适的规则 确保软件开发质量 提高工作效 率 轻载过程对需求改变的快速适应性特别适应现代社会的特点 云南大学软件学院软件工程硕士学位论文 12 2 1 4 基于时间的过程 有别于传统软件开发过程 敏捷软件开发是基于时间的 每一次迭代都有 固定的时间限制 一个复杂的项目可以被分为多次迭代 进行多次发放 强调 快速开发 要求每次迭代尽可能及早实现初期目标 2 1 5 Just enough 原则 敏捷软件开发强调 够用就好 Just enough 主张开发只要满足用户目 前需求 对于未来预计的需求 只要还未正式提出 就不做开发 代码也只需 要满足已有需求就行 如果出现需求增加 可以对代码进行重构来增加可扩展 性 2 2 敏捷软件开发原则 2 2 1 敏捷软件开发宣言 2001 年 2 月 在美国犹他州的一个滑雪场 17 位轻量级软件开发方法的创 始人和专家 包括 Kent Beck Extreme Programming Al