软件工程软件系统开发方法PPT课件

第3章软件系统开发方法 1 软件开发生命周期软件过程模型软件工程方法学传统软件开发方法面向对象的开发方法RUP统一软件开发过程敏捷软件开发方法 2 软件生存周期的概念和内容 4种软件开发模型 软件开发方法和开发工具 传统软件工程和面向对象软件工程 RUP和敏捷过程 本章重点 软件开发模型 软件开发方法和开发工具 本章难点 软件开发模型的使用 本章主要内容 3 补充 软件工程方法学 软件工程包括技术和管理两方面的内容 是技术与管理紧密结合所形成的工程学科 通常把在软件生命周期全过程中使用的一整套技术方法的集合称为方法学 methodology 也称为范型 paradigm 在软件工程领域中 这两个术语的含义基本相同 软件工程方法学包含3个要素 方法 工具和过程 4 软件工程方法学 软件工程 一种层次化技术 软件工程三个要素 工具 方法 过程 基础层 综合方法及工具 定义方法使用的顺序 所需要的管理 为软件开发提供 如何做 的技术 为软件开发提供自动或半自动的软件支撑环境 建立计算机辅助软件工程 CASE 的软件开发支撑系统 5 软件过程是为了获得高质量软件所需要完成的一系列任务的框架 它规定了完成各项任务的工作步骤 工作任务 里程碑 交付物 SQA点 AprocessdefinesWhoisdoingWhat When andHow inordertoreachacertaingoal 公共过程框架 辅助活动 框架活动 任务集合 软件过程 6 软件工程过程定义了 方法使用的工具要求交付的文档资料为保证软件质量和协调变化所需要采取的管理措施软件开发各个阶段任务完成的里程碑 7 软件开发方法的概念一般说来 一个软件方法往往规定了 明确的工作步骤 具体的描述方式以及确定的评价标准 软件开发的基本方法1 结构化方法2 面向对象方法软件开发工具目前已经推出很多软件开发工具 如需求分析阶段的PSL PSA系统 编码阶段的各种语言编译工具 编辑程序 连接程序等 都是软件编码阶段的软件工具 测试阶段的测试数据产生程序 动态分析程序 静态分析程序等软件自动测试工具 维护阶段的版本控制系统等 从广义上来讲 软件分析 设计阶段的各种图形工具 如数据流图 DFD图 等也可以称为软件开发工具 8 9 人是有生命期的 那么软件呢 什么是软件生命周期 10 3 1软件生命周期 软件生命周期表明从功能确定 设计到开发成功投入使用 并在使用中不断地修改 增补和完善 直到被新的需要所代替而停止使用该软件的全过程 3 1软件生命周期 问题定义软件定义可行性研究需求分析总体设计详细设计软件生命周期软件开发编码单元测试综合测试运行维护持久满足用户需求 11 12 案例分析 某电力公司A 希望软件公司B为他们制造一种 电费结算系统 该系统用于结算每一户电表1个月期间应该缴纳的电费 B公司得到电力公司A的这个要求之后 开始进入制作 电费结算系统 软件的生命周期 13 问题定义阶段 该阶段的关键任务是要明确 要解决的问题是什么 思考 以下几个选项中 哪个是B公司得出的结论 A 要解决某小区用电总度数问题B 要解决某小区总收电费问题C 要解决电力公司A管辖范围内的所有电表每月每户电费结算问题D 要解决全国区域内电表结算问题 14 可性行研究阶段 该阶段的关键任务是要明确 做不做用最小的代价在尽可能短的时间内从经济 技术 社会因素等方面论证解决方案的可行性 思考 B公司在可行性分析阶段应该做些什么事情 会得出什么结论 15 需求分析阶段 该阶段的关键任务是要明确 做什么通过与客户不断的讨论 协商 对目标系统提出完整 准确 清晰 具体的要求 用正式的文档准确地记录对目标系统的需求 形成软件需求规格说明书 SRS 注意点 B公司在这个阶段应该对用户的要求进行详细的调研与分析 需要去了解电费结算中需要涉及到信息 结算电费的标准与公式 这个电费结算系统的产出文档是什么 等内容 确定该系统需要实现的功能 例如 对使用电表的用户进行管理 对1个用户1个月的电费计算 能够生成结算单 最后以文档的形式描述出需求规格 这些是指导B公司进行下一步工作的依据 16 概要设计 总体设计 阶段 该阶段的关键任务是要明确 怎么做提出实现目标系统的几种方案 制定最佳方案的详细计划系统的体系结构设计阶段性成果 概要设计说明书 数据库或者数据结构说明书 组装测试计划等 根据上一步得到的需求规格说明书 将需求功能进行模块化分 B公司的设计人员开始了对 电费结算系统 的设计 例如 系统管理模块 电费计算模块 生成结算单模块等 17 详细设计阶段 该阶段的关键任务是要明确 具体做法设计出程序的详细规格说明 即详细地设计每个模块 确定实现模块功能所需要的算法和数据结构 阶段性成果 详细设计规格说明书和单元测试计划等 对每一个模块 设计它的实现算法和数据结构 例如 电费计算模块 需要根据计算公式进行电费的计算 B公司的设计人员开始了对 电费结算系统 的设计 18 编码和单元测试阶段 该阶段的关键任务是编码和单元测试编写出正确的 易理解的 易维护的程序模块 仔细测试编写出的每一个模块阶段成果 经过单元测试后的代码 单元测试报告等 B公司程序员们开始对每个模块进行分工 各自负责1个或者多个模块 然后写代码阿写代码 代码写好了 还需要对自己所写模块的代码进行测试 保证自己的正确性 19 综合测试阶段 该阶段的关键任务是通过各种类型的测试 及调试 使软件达到预定的要求组装测试 根据设计的软件结构 把经过单元测试检验的模块按某种策略装配起来 在装配过程中对程序进行必要的测试 验收测试 按照规格说明书的规定 由用户对目标系统进行验收 看其是否达到需求规格说明书中定义的全部功能和性能等方面的需求 验收测试结束后 经过评审的软件产品就可以交付投入使用了 经过上面的几个步骤 B公司的人员终于拿出了 电费结算系统 他们需要对该系统进行各种测试 包括集成测试 系统测试 用户环境测试 验收测试等等 确保该系统能够平稳的运行在A公司中 20 软件维护阶段 该阶段的关键任务是通过各种必要的维护活动使系统持久地满足用户的要求 改正性维护 诊断和改正在使用过程中发现的软件错误适应性维护 修改软件易适应环境的变化完善性维护 根据用户的要求改进或扩充软件使它更完善预防性维护 修改软件为将来的维护活动预先做准备 在电力公司A的实际使用当中 电力结算系统 出现了一些问题 B公司需要派人员进行维护 此外 A公司对B公司所开发的系统比较满意 愿意继续让B公司对其进行其他方面功能的扩充 例如 分小区进行用电量和电费收益的统计分析等 软件开发的这些阶段 是按什么样的顺序排列的呢 经过软件工程领域科学家在实际项目的基础上不断研究和发现 总结出了一些可以遵循的规律 过程模型 21 过程模型的选择 首先 了解每一种过程模型的特点和适用性 其次 根据软件项目的特点选择合适的过程模型 值得注意的是 由于现实中项目的复杂性 通常会在一个项目中选择几种过程模型嵌套使用 22 案例 某个老师 T 想要考察一个同学 S 的学习情况和技术水平 于是交给该学生一个任务 T 我有一个朋友想要一个图象浏览软件 能够查看多种格式的图象 包括BMP TIFF JPG PNG 并且能够支持一般的放大 缩小 漫游 你能做这样一个软件吗 S 就是类似ACDSEE这样的软件吗 T 差不多 不过不需要那么强大的功能 我这个朋友计算机是外行 最好能做的比较方便 傻瓜型的 例如象ACDSEE自动翻页这种功能还是要的 S 我以前学过BMP和JPG的图象格式解析 我想没有问题T 好的 给你30天时间 下周你再来一趟 跟我讲一下你的工作进度 这位同学非常明白老师的意图 回去后想了一下 并列出了一个清单 23 一功能 1 读取 显示 另存四种格式图片 BMP TIFF JPG PNG 2 放大 缩小 漫游3 列出当前目录下所有四种格式图片文件名4 PAGEUP PAGEDOWN 自动调出当前目录上一张 下一张 图片二其它说明 1 界面尽量简介 容易操作2 不要图片预览和打印三开发工具 VC6四开发环境 普通PC机 Window2000 xp五工作量 1 研究一下四种图片的格式2 设计一个解析器类 解析这四种格式3 设计一个文档类 实现读取 另存和目录浏览功能4 设计一个视图类 实现显示 缩放 漫游功能 工作清单 24 软件制造的八个阶段 可行性分析 需求分析 概要设计 详细设计 编码 测试 交付 维护 对话过程 工作清单一 二 工作清单三 四 五 写代码前的思考过程 写代码 提交给老师检查 给老师朋友安装 讲解 修正问题 改进软件 25 PARTONETheProductandtheProcess 实际情况1一切顺利 学生S按期交付了软件 经过一两周的试用 修改 完善后 三方都比较满意 该软件在老师的朋友那里成为一个得心应手的工具 瀑布模型 26 瀑布模型 需求分析7 系统设计6 软件编程7 软件测试13 软件维护67 用户要求 分析报告 系统设计报告 源程序 测试报告 更改要求 UAM ATM MP UTP UAMP A系统分析员M项目管理员P程序员T高级程序员U用户 27 实际的瀑布模型 28 传统瀑布模型的特点 时间上具有顺序性和依赖性推迟实现的观点质量保证的观点1 审核机制2 文档齐全 29 瀑布模型适合于用户需求明确 完整 无重大变化的软件项目开发 瀑布模型的成功在很大程度上是由于它基本上是一种文档驱动的模型 瀑布模型是由文档驱动的 这个事实也是它的一个主要缺点 实际项目很少按照该模型给出的顺序进行 用户常常难以清楚地给出所有需求 用户必须有耐心 等到系统开发完成 瀑布模型的优缺点 30 31 实际情况2一周后 学生去见老师 并提交了工作清单 他发现老师的这位朋友 C 和老师在一起 S 这是工作清单 我已经研究清楚了四种文件的格式 可以写代码了 T 很好 不过我这位朋友有一些新想法 你不妨听听 C 你好 我新买了一个扫描仪 你的程序可不可以直接扫描图片进来 S 你可以自己扫描呀 买扫描仪的时候一般都会送正版软件的 C 是的 可是我一直不太会用 你知道我计算机水平不高 学一些新东西很累 也没有时间 如果你能直接链接扫描仪 我只要学会你的软件就行了 我愿意多支付一些费用 还有 我想建一个图片库 你知道 我工作时需要上百个图片 经常找不到 最好还带模糊查询 PARTONETheProductandtheProcess 32 PARTONETheProductandtheProcess 实际情况2 续 S C 还有一些 现在一时想不起来 我想起来的话会再跟你联系 时间上可以长一些 S T 要不这样吧 你先做一个样子出来给C看看 一边做 一边改 C 这样最好 看见一个基本样子我就知道我想要什么了事情就这样定下来了 S愤怒的撕掉了自己的工作清单 回去后S花1天时间用DELPHI做了个样子 只能读BMP和JPG文件 做了些菜单和工具栏 用ACCESS建了一个图片库 就这个 假 的程序 S和C讨论了一天 S又修改了几次 又讨论了几次 一周后 这个 假 的程序表面看起来和真的一模一样 33 实际情况2 续 于是S打算用VC重写这个程序 但是他很快发现继续用DELPHI写更方便 因为至少界面不用重做了 于是 两个月后 这个事情终于结束了 S顺利的完成了他的毕业设计 JPG压缩优化算法设计 C一直使用这个软件管理他的图片 并庆幸花了这么少的钱得到了这么有用的东西 而T 则正在考虑如何为他下一批学生分派任务 PARTONETheProductandtheProcess 原型模型 2 原型模型 快速原型模型 RapidPrototypeModel 在用户不能给出完整 准确的需求说明 或者开发者不能确定算法的有效性 操作系统的适应性或人机交互的形式等许多情况下 可以根据用户的一组基本需求 快速建造一个原型 可运行的软件 然后进行评估 进一步精化 调整原型 使其满足用户的要求 也使开发者对将要做的事情有更好的理解 建造 修改原型 听取用户意见 用户测试运行原型 原型实现范型 快速原型 验证 规格说明 验证 设计 验证 编码 测试 综合测试 维护 变化的需求 验证 维护过程 开发过程 35 原型模型存在的问题 为了使原型尽快的工作 没有考虑软件的总体质量和长期的可维护性 为了演示 可能采用不合适的操作系统 编程语言 效率低的算法 这些不理想的选择成了系统的组成部分 开发过程不便于管理 有效的使用原型模式建造原型仅是为了定义需求 之后就被抛弃 或被部分抛弃 实际的软件在充分考虑了质量和可维护性之后才被开发 36 3 增量模型 IncrementalModel 是一种渐进地开发逐步完善的软件版本的模型 需求分析 验证 规格说明 验证 设计 验证 维护 针对每个构件完成详细设计 编码和集成 经测试后交付给用户 37 分析 分析 分析 分析 设计 设计 设计 设计 编码 编码 编码 编码 测试 测试 测试 测试 增量1 增量2 增量3 增量4 交付 交付 交付 交付 反复的应用瀑布模型的基本成分和原型模型的迭代特征 每一个线型过程产生一个 增量 的发布或提交 该增量均是一个可运行的产品 早期的版本实现用户的基本需求 并提供给用户评估的平台 增量模型 38 在较短时间内向用户提交可完成部分工作的产品 并分批 逐步地向用户提交产品 从第一个构件交付之日起 用户就能做一些有用的工作 整个软件产品被分解成许多个增量构件 开发人员可以一个构件一个构件地逐步开发 逐步增加产品功能可以使用户有较充裕的时间学习和适应新产品 从而减少一个全新的软件可能给客户组织带来的冲击 采用增量模型比采用瀑布模型和快速原型模型需要更精心的设计 但在设计阶段多付出的劳动将在维护阶段获得回报 增量模型的优点 39 增量模型的困难 在把每个新的增量构件集成到现有软件体系结构中时 必须不破坏原来已经开发出的产品 此外 必须把软件的体系结构设计得便于按这种方式进行扩充 向现有产品中加入新构件的过程必须简单 方便 也就是说 软件体系结构必须是开放的 开发人员既要把软件系统看作整体 又要看成可独立的构件 相互矛盾 多个构件并行开发 具有无法集成的风险 40 4 螺旋模型 SpiralModel 软件风险是任何软件开发项目中都普遍存在的实际问题 项目越大 软件越复杂 承担该项目所冒的风险也越大 对于复杂的大型软件 开发一个原型往往达不到要求 螺旋模型将瀑布模型和增量模型结合起来 加入了风险分析 在该模型中 软件开发是一系列的增量发布 早期的迭代中 发布的增量可能是一个纸上的模型或原型 在以后的迭代中 逐步产生系统更加完善的版本 螺旋模型的基本思想是降低风险 41 快速原型 验证 规格说明 验证 设计 验证 编码 测试 综合测试 维护 变化的需求 验证 风险分析 风险分析 风险分析 风险分析 风险分析 风险分析 可看作在每个阶段之前都增加了风险分析过程的快速原型模型 简化的螺旋模型 42 完整的螺旋模型 43 螺旋模型的优点对可选方案和约束条件的强调有利于已有软件的重用 也有助于把软件质量作为软件开发的一个重要目标减少了过多测试或测试不足维护和开发之间并没有本质区别螺旋模型的特点风险驱动 需要相当丰富的风险评估经验和专门知识 否则风险更大主要适用于内部开发的大规模软件项目 随着过程的进展演化 开发者和用户能够更好的识别和对待每一个演化级别上的风险随着迭代次数的增加 工作量加大 软件开发成本增加 44 45 学以致用 辅导员张老师为了方便管理学生 他委托学生小明帮助他开发一个学生管理系统 用来管理他所带的班级的学生信息 该系统仅供张老师一个人使用 系统功能不是很复杂 张老师对自己需要的系统功能有了明确的认识 并且他本身也对软件开发有一定程度的了解 与小明的沟通过程非常的顺利 在这种情况下 如果你是小明 你会选用哪种过程模型 46 学以致用 张扬是某大学软件技术专业的学生 在寒假中 他为他的邻居开发了一个小型的超市管理系统 他的邻居从来不懂软件开发 也不知道超市管理系统应该是什么样的 那么你建议张扬采用哪种过程模型呢 传统的软件工程采用瀑布模型作为软件工程的基本模型 把软件开发和运行过程划分为六个阶段 软件计划 需求分析 软件设计 程序编码 软件测试 运行和维护等 强调各阶段的完整性和先后顺序 根据不同阶段的工作特点 运用不同的手段完成各阶段的任务 1 传统软件工程存在的问题2 传统结构化技术的缺点 3 3软件工程方法学 传统的方法学 47 计算机世界 现实世界 结构化开发方法 结构化分析 结构化设计 结构化编程 OOA OOD OOP 面向对象开发方法 48 结构化分析结构化设计结构化编程结构化测试 结构化软件开发方法 49 3 4面向对象方法学1 面向对象方法的基本思想面向对象方法的基本思想是从现实世界中客观存在的事物出发来构造软件系统 并在系统构造中尽可能运用人类的自然思维方式 面向对象方法学的出发点和基本原则是 尽可能模拟人类所习惯的思维方式 使开发软件的方法和过程尽可能接近人类认识世界 解决问题的方法和过程 即使描述问题的问题域与实现解法的求解域在结构上尽可能一致 50 2 面向对象方法的主要优点 符合人们通常的思维方式高度连续性重用性好可维护性好 51 面向对象方法学的要点 52 3 面向对象模型 喷泉模型 FountainModel 分析 设计 实现 测试 集成 演化 特点 主要用于支持面向对象开发过程体现了软件创建所固有的迭代和无间隙的特征 53 喷泉模型 该模型是由B H Sollers和J M Edwards于1990年提出的一种新的开发模型 其特点如下 开发过程有分析 系统设计 软件设计和实现4个阶段 各阶段相互重叠 它反映了软件过程并行性的特点 以分析为基础 资源消耗成塔型 反映了软件过程迭代性的自然特性 从高层返回低层无资源消耗 强调增量开发 整个过程是一个迭代的逐步提炼的过程 54 4 面向对象方法学概述 面向对象的方法学可以用下列方程来概括 OO objects classes inheritance communicationwithmessages面向对象就是既使用对象又使用类和继承等机制 而且对象之间仅能通过传递消息实现彼此通信 也可以说 只有同时使用对象 类 继承和消息的方法 才是真正面向对象的方法 55 1 对象 面向对象语言 在问题空间中 对象是 现实世界中存在的实体应用所关心的抽象概念 规则 事件 或者具有明确边界和意义的具体事物在解空间 计算机系统 中 对象是 问题空间中的对象在计算机系统中的表示封装 encapsulation 了数据和行为的通信单位 56 对象的基本特征每个对象均有自己的惟一标识 从而区别于其他对象 对象之间通过消息进行通信 对象总是处于一定的状态 对象有若干种行为 对象的行为分为三类 创建新对象 与其他对象通信 改变自身状态 对象的状态只能被自身的行为所改变 57 2 类在问题空间中 人以类聚 物以群分 类代表着具有类似性质的一组对象类中的每一个对象即为类的不同实例 instance 在解空间 计算机系统 中 类是对一组对象的抽象 集中了该组对象的共同特性 在构造软件时 类实际上是具有特定功能的模块 其代码由该种所有对象所共享 类vs 对象 静vs 动 58 对象状态 张三 30岁 计算机系 讲师 1000元行为 提职称 调工资类 教师 属性 姓名 年龄 系别 职称 工资操作 提职称 调工资方法 指操作的具体代码实现 实际上 类是创建对象的模板 3 类和对象之间的关系 59 60 4 封装 让对象细节受到保护 引入问题 现在让我们来编写一个java小程序 实现在命令行模式下输出以下形式的著名诗词 春晓 你会怎么做 春晓 春眠不觉晓 处处闻啼鸟 夜来风雨声 花落知多少 61 你可能会这么写 publicclassChunXiao1 publicstaticvoidmain String args System out println 春晓 System out println 春眠不觉晓 System out println 处处闻啼鸟 System out println 夜来风雨声 System out println 花落知多少 很简单 但是有时候并不是越简单越好 现在 如果想把 改变为 该怎么办 改5次吗 代码 Chunxiao1 java 62 你可能还会这么写 publicclassChunXiao2 publicStringbuildStar return publicstaticvoidmain String args ChunXiao2c newChunXiao2 System out println c buildStar 春晓 System out println c buildStar 春眠不觉晓 System out println c buildStar 处处闻啼鸟 System out println c buildStar 夜来风雨声 System out println c buildStar 花落知多少 利用方法buildStar 来产生 这样每次只用修改一个地方了 我们把产生 的功能封装了起来 对外界使用者来讲 不需要知道方法内部的细节 只需要知道调用这个方法可以产生 就行了 代码 Chunxiao2 java 63 让对象细节受到保护 封装 当一个对象执行自己的操作时 它对外界隐藏了操作的细节 封装可以提高重用性 并且让程序易于维护 64 封装的程度问题 还是 春晓 刚才我们将产生 的方法写在了类ChunXiao2中 根据前面所讲 类中的方法代表的是类的操作 而产生 和春晓没有直接关系 这样的封装看起来好像不合理 怎么改进一下呢 ChunXiao3 代码 StarFactory javaChunxiao3 java 65 封装的不同 重用也不同了 现在我们不仅可以在 春晓 里面用 了 还可以在 静夜思 里面用 了 ChunXiao3 JingYeSi 代码 JingYeSi java 66 5 面向对象重要概念 消息传递 67 给对象发消息 让它做的更多 消息传递 还是 春晓 有些同学不喜欢刚才的排版 全部是 没有创意 既然StarFactory类是制造 的工厂 那么它应该有更多的产品啊 不能一直是 吧 怎么办 改良版StarFactory2 ChunXiao4 代码 StarFactory2 javaChunxiao4 java 68 6 面向对象重要概念 继承 在客观世界中 类是有着层次关系的 那么程序世界中 也要能够表现这种层次 于是 有了继承 69 用继承改变刚才的 春晓 自从有了StarFactory 春晓 的世界变得丰富起来 既然 可以创造 那么 也应该可以吧 还有 呢 全部都可以 那么让我们创建GraphicFactory类吧 它表示创造上述图形的总厂 而它的子类用来创造每一种图形 70 所有的子类都有build 方法 代表创造不同图形的操作 创造 创造 创造 创造 71 72 7 面向对象重要概念 多态性 不同的类具有相同名称的操作 门 窗 盒子 打开 73 多态性的表现 74 回顾一下 类和对象封装消息传递继承多态 3 5统一软件开发过程 RUPRUP是由Rational公司的Booch Jacobson Rumbaugh提出的软件过程模型 也称RUP RationalUnifiedProcess RUP重复一系列周期 每个周期由一个交付给用户的产品结束 每个周期划分为初始 细化 构造和移交四个阶段 每个阶段围绕着五个核心工作流 需求 分析 设计 实现 测试 分别迭代 模型见下图 75 图RUP软件开发生命周期 76 RUP 初始阶段 进行问题定义 确定目标 评估其可行性 降低关键风险 细化阶段 制定项目计划 配置各类资源 建立系统架构 包括各类视图 构造阶段 开发整个产品 并确保产品可移交给用户 移交阶段 产品发布 安装 用户培训 在每个阶段的每次迭代的最后 用例模型 分析模型 设计模型 实现模型都会增量 每个阶段结束的里程碑处 管理层做出是否继续 进度 预算 是否给下一阶段提供资助等决定 不同阶段工作流的侧重点不同 前两阶段大部分工作集中在需求 分析和架构设计上 在构造阶段 重点转移到详细设计 实现和测试上 77 传统计划驱动的开发方法强调过分过程控制 这种方法的一个后果就是大量的开发时间被用在开发文档的撰写和维护上 而真正花在代码上的时间就相对少了 另外一个后果就是由于主要依赖过程控制 而不是程序员自我管理 开发过程的管理非常复杂和低效 在计划驱动方法中 过程和工具不是为人 指程序员 服务的 而是为管理者服务的 程序员成了工具和过程的奴隶 这些都极大地阻碍了软件生产率的提高 这种开发模式越来越不适应现代瞬息万变的商业需求了 因此 在近几年 一种被成为敏捷方法的开发思想开始流行起来 78 什么是敏捷过程敏捷过程是容易适应变化并迅速做出调整 在保证质量的前提下做到文档适量适度 敏捷开发方法并不是一个具体的过程 而是一个概况性的术语 具有以人为核心 循环迭代 响应变化的特点 着眼于高质量的快速交付令客户满意的工作软件 3 6敏捷 灵活 开发与极限编程 79 开发过程以代码为核心 而不是以文档为核心 代码编写 测试 发布 重构 然后进入第二次迭代 经过多次小型迭代开发过程逐步逼近实际需求 以人为本 程序员在软件开发中不再是单纯被管理的对象 而是开发的主体 所有的主要设计策略的制定 开发方法的选择 需求的确定都由程序员决定 因为他们才是真正生产软件的人 他们最了解如何开发软件 敏捷方法的特征 80 这个问题的答案就是靠人自我的管理 团队自我的管理 敏捷方法抛弃了机械 严格的过程控制 就必须依赖于程序员和开发团队的高标准自我要求 严格的自律 团队合作精神 个人高度自觉的主动性 责任感 敏捷方法的高效和高质量实际上是以程序员的高素质和开发团队的高度合作的开发文化为基础的 敏捷方法如何保证开发进度 开发效率 开发质量 81 1 个体和交互胜过过程和工具2 可以工作的软件胜过面面俱到的文档3 客户合作胜过全同谈判4 响应变化胜过遵循计划 四条基本价值观 82 动态系统开发 DSDM DynamicSystemsDevelopmentMethod特征驱动开发 Feature DrivenDevelopment水晶模型 Crystalscrum模型极限编程 eXtremeProgramming 代表方法 83 极限编程 极限编程是敏捷过程中最有名的一个 适于小型项目 极限编程 XP eXtremeProgramming 对于传统的软件工程中看来是 极端的 实践 XP团队使用现场客户 特殊计划方法和持续测试