第3章 教育信息系统的开发方法.pptVIP

* * * 整个团队：客户也是开发团队成员 计划游戏：XP项目计划的主导思想是将业务责任和开发责任相分离。业务人员（客户）确定哪些产品特征是重要的，开发人员确定实现这些特征需花费多少成本。 短交付周期（快速发布）：XP项目每两周向客户交付一次软件，所交付的软件涉及客户的一部分需求，客户要及时作出反馈。 持续集成：不超过两个小时就对改变的地方进行一次集成和测试。团队编程并不是单纯的分而治之，而是分散、解决问题然后集成。 集体所有：代码归集体所有，团队中的所有成员都有权访问和改进项目的所有模块代码。 代码规范：一是希望通过建立统一的代码规范，来加强开发人员之间的沟通，同时为代码走查提供了一定的标准；二是希望减少项目开发过程中的文档，XP认为代码是最好的文档。 可持续的开发速度：软件项目不是短跑，而是马拉松，它需要一个可持续的速度，能够保持能量和敏锐性。极限编程的一个原则是“不要加班”，但也有例外，即在一个发布周期的最后一周加班是允许的，因为这时可能需要加速以达到发布目标。 系统隐喻：通过隐喻来描述系统如何运作、新的功能以何种方式加入到系统。它通常包含了一些可以参照和比较的类和设计模式。XP不需要事先进行详细的架构设计。 结对编程：两个程序员用一台电脑一起工作，其中一人操作键盘，输入程序，另一人与他密切交流，检查错误和需要改进的地方。两人的角色频繁互换。 测试驱动：强调测试先行。在编码开始之前，首先将测试写好，而后再进行编码，直至所有的测试都得以通过。 重构：在不改变既有代码的行为的前提下，改善代码的设计。重构的目的是为了消除代码重的“坏气味”，从而达到防止代码腐烂的目的。 简单设计：认为代码的设计应该尽可能的简单，只要满足当前功能的要求，不多也不少。 * 1. 精确。瀑布模式通常会在产品起点与最终结果之间规划出一条直线,然后沿着直线不断往前走。然而当项目到达终点时,用户通常会发现那已经不是他们想去的地方。而敏捷方法则采用小步快跑,每走完一步再调整并为下一步确定方向,直到真正的终点。 2. 质量。敏捷方法对每一次迭代周期的质量都有严格要求。一些敏捷方法如极限编程等,甚至使用测试驱动开发(test-driven development),即在正式开发功能代码之前先开发该功能的测试代码。这些都为敏捷项目的整个开发周期提供了可靠的质量保证。 3. 速度。敏捷团队只专注于开发项目中当前最需要的、最具价值的部分。这样能很快地投入开发。另外,较短的迭代周期使团队成员能迅速进入开发状态。 4. 丰厚的投资回报率。在敏捷开发过程中,最具价值的功能总是被优先开发,这样能给客户带来最大的投资回报率。 5. 高效的自我管理团队。敏捷开发要求团队成员必须积极主动,自我管理。在这样的团队中工作,每个团队成员的技术能力、交流、社交、表达和领导能力也都能得以提高。 * 敏捷开发优点 自我管理 投资回报 速度 质量 精确 优势 敏捷开发优点 敏捷开发缺点 1 客户环境 客户认同 客户责任 2 团队对敏捷的认识程度 频繁交付 过份关注短期目标 3 成员的能力 要求全能型 沟通要求 害怕暴露能力缺陷 讨论 比较原型化方法和敏捷方法 系统 功能性需求 非功能性需求 3.5 面向方面方法 横切点 横切系统 方面语言——横切关注点 Aspect language 构建语言——功能 Component language 编织器 Aspect weaver 需求阶段 设计阶段 编程实现 开发过程 需求阶段 描述 捕获 分析 需求分析步骤 需求分析方法 需求分析模型 需求分析步骤 需求说明书 需求分析方法 需求分析模型 通用的AORE模型 标识并详细说明需求 确定出候选方面 进行方面与组件的复合 处理冲突 确定方面的影响范围 优点：在早期确定了横切关注对后期分析设计实现阶段的映射和影响，便于对需求的冲突和均衡做出调整。 AORE模型 面向方面的非功能需求框架 需求分析模型 确定NFR之间的相 互关系及优先权 分解非功能性需求NFR 确定需求 确定可能的操作性 分析NFR操作性的映射 选择出操作性 复合方面与功能需求 核心思想 对每一个非功能需求NFR逐级分解 目的 将非功能需求分解成可操作行为 AONFRF框架 模块设计 架构设计 设计阶段 内容：针对需求和体系结构分析面向方面的方法 目的：保持需求、设计和实现之间的一致性 组件模块 方面模块 技术架构 业务架构 模块设计 设计阶段 ——关注点的建模 提出者 关注点建模方法 备注 Wagelaar CoCompose 基于概念的方法 Lohmann Ebert 超空间方法 区分主、次关注点 IBM CME关注点操作环境 关注点管理组件Con