特征驱动开发的应用研究

合集下载
  1. 1、下载文档前请自行甄别文档内容的完整性,平台不提供额外的编辑、内容补充、找答案等附加服务。
  2. 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
  3. 3、如文档侵犯您的权益,请联系客服反馈,我们会尽快为您处理(人工客服工作时间:9:00-18:30)。
2001 年 以 Kent Beck Martin Fowler Robert Martin 等经验论阵营的头领发起组织了 敏捷联盟 并向全世界发 布了他们的宣言[1]
(1) 个体和交互胜过过程和工具 强调了交互 (2) 可以工作的软件胜过面面俱到的文档 强调了能工作 (3) 客户合作胜过合同谈判 强调了与客户合作 (4) 响应变化胜过遵循计划 强调了适应变化 以上的宣言反映了软件开发方法要适应现代软件多变化 的特征 而敏捷开发方法 就是在这个基础上提出来的 敏 捷方法包括 XP(极限编程) FDD(特征驱动开发) ASD(自适 应的软件开发) Crystal(水晶方法)等 本文将结合一个具体 的项目 论述对 FDD 的认识和理解
View
Command
Communication
1
* Entity * 1 Mission
图 2 指挥系统领域对象模型 3.2 形成特征表
本阶段对建立领域对象模型时得到的信息进行总结 建 立 FDD 开发的主线 特征表 这是从领域划分开始的简单 的功能分解的活动 先将整个问题域分解成几个区域(主特征 集) 然后再将区域分解为一个个活动(特征集) 最后落实到 一个个具体的特征上 这样做同时也解决了开发任务的分解 使得项目进度监控的粒度被细化 便于迭代 自然而然地形 成开发过程的里程碑 这一过程由组员集体采用 头脑风暴 法 即通过创造一个无批评的自由的会议环境 充分交流 产生出大量创造性的意见 找到足够多的特征 再 去伪存 真 形成本项目的特征表
第 31 卷 第 21 期
Vol.31
21
软件技术与数据库
计算机工程 Computer Engineering
文章编号 1000 3428(2005)21 0066 03
文献标识码 A
2005 年 11 月 November 2005
中图分类号 TP311.5
特征驱动开发的应用研究
刘海岩 郑翔宇 陈克进 (西安交通大学计算机软件研究所 西安 710049)
该训练系统分为指挥系统和训练器系统 指挥系统向训 练器系统下达训练任务并且实时监控训练器的状态 接收训 练器的成绩信息 对成绩信息进行分析 该项目指挥系统的 体系结构如表 2 所示
表 2 系统的体系结构 用户界面(UI)层
人机交互 用户交互 表示逻辑
问题领域(PD)层 业务逻辑层
数据管理(DM)层 数据存储逻辑
系统与外部交互(SI)层 系统接口 外部接口层
3.1 建立领域对象模型 首先对问题领域进行建模 指挥系统不仅负责训练任务
的发布 还要实时监控各个任务 因此 指挥系统必须拥有 负责通信的 Communication(通信)类和负责显示的 View(视图) 类 由于同一时刻可能进行多个任务 指挥系统需要动态管 理多个任务 Command(指挥)类负责管理 Mission(任务)类 以及参与任务 Entity(实体)类 于是形成指挥系统领域对象模 型 如图 2
李勇
类所有者分配如表 5 所示 主程序员清楚自己负责开发 的特征集所涉及的类 并且会各自寻找他们喜欢的开发人员
67
万方数据
承担那些类的所有权 主程序员也是开发人员 也要分配一 拟训练器的计算机收到并完整显示 设计不同的参数类型和
些类的所有权
数量来检测程序的正确性和健壮性
结合这两张表即可以形成如图 3 的进度报告
最后 通过不断进行设计 构造 实现的迭代完成开发任务
整个过程如图 1 所示
基金项目 陕西省科技攻关基金资助项目(2003K05-G18) 作者简介 刘海岩(1948 ) 女 副教授 主研方向 软件工程 分 布式系统 郑翔宇 陈克进 硕士生 收稿日期 2004-09-28 E-mail zxy417@sohu.com
传输三维图像
实时监控
2.2 FDD 过程简述 FDD 与其他方法的一个最明显的区别在于 FDD 致力于
软件系统的实际设计和构造 它着重关注进行设计和编写软
件所需的特定活动和输出[1] FDD 与领域专家合作创建一个 领域对象模型 结合需求过程中的信息 为开发人员创建一
个特征表 接着在特征表的基础上制定一个迭代的开发计划
下达训练任务训练 ( 下达 是 action 训练任务 是 object 训练 是 result) 特征有两个属性[2] (1) 它是小的 小得可在 2 个星期内实现 2 个星期是上限 任何一个无法 在 2 个星期内完成的功能要分解为更小的功能 直到每个功 能小到足以被称为特征 (2) 特征具有客户价值 一个特征 可映射到业务过程中某些活动的一个步骤 因此 关注特征 将使软件开发团队在项目启动时不能很快进入技术视角 而
完成 任务下达 特征集后 利用现有成果开发其他特
征集 直至得到客户认可 完成项目
3.5 项目进度管理 在本项目实施中 采用项目进度的 可视化 管理 即
采用了 FDD 方法特有的进度报告格式 以下为进度报告解
析 见图 3
如图 3 还采用了颜色进行直观表示 其中 白色代表
开始 黄色代表正在进行 绿色代表已完成 红色代表落后
表 4 特征集表
F#
主特征集
特征集
特征名 主程序员 计划完成日期
0001 指挥系统 任务下达 添加任务
Leabharlann Baidu
张三
2003.10.20
0002 指挥系统 任务下达 添加实体
张三
2003.10.20
表 5 类所有者分配表
类名 Entity
类所有者 张三
Mission
张三
Command
王涛
Communication
万方数据
图 1 FDD 的 5 个过程及其输出
3 FDD 开发实践
应 用 项 目 是 一 个 基 于 分 布 式 交 互 仿 真 (DIS) 协 议 的 分 布 式交互仿真训练系统 它的客户目标是需要实现仿真协作训 练的单位 该系统的目标是为客户实现以下价值 实现仿真 协同训练以及训练结果信息的管理
(1) 根据需求 确定一个最小的特征集 最优先考虑 这样用 户最早体验到核心的需求特性
(2 )根据特征之间的关联 安排合理的迭代顺序 也就是说对于 某个需要依赖另一个特性的特征放在后面进行
FDD 建立了一个动态的管理方式 负责特征集的主程序
员的主要责任是确保特征按计划完成 同时还需要对参与完
成特征的每个类 根据类与特征的关联性 类的重要性 类
例 在用例中可以发现特征 依靠用例的级别 可能发现一
个用例中所有的特征集甚至是整个特征区域 也可能发现同
一特征出现在多个用例中 但某一特征仅属于一个特征集[2]
表 1 列举了反映特征与用例区别的例子 表 1 特征与用例区别的例子
特征
用例
添加任务
下达训练任务
添加实体
下达训练任务
显示模块访问数据区
实时监控
进入了设计阶段 每个主程序员都可发起 召集与该特征相 有更大的优势 与用例驱动开发相比体现了以下优点
关的类所有者一起进行更加细致的设计 并进行构建 在这 个过程中 可能会发现新的类 因此这个阶段主设计师的作 用就是根据实际的情况对类的所有者进行动态的安排 主设 计师负责组织各种审查 负责对整个迭代计划中的特征进行 集成 配置管理和定期构造
本项目主要特征集
(1) 指挥系统 包括任务制定 动态处理 信息管理 3 个特 征集
(2) 训练器系统 包括三维模拟 作战操作 协同操作 3 个特 征集
(3) 通信系统 包括信息接收 信息发送 2 个特征集 表 3 节选了特征表中 任务下达 特征集部分
表 3 特征表中 任务下达 特征集部分
F# 主特征集
2 特征驱动开发方法简介
2.1 什么是 特征 特征是特征驱动开发(Feature-driven development, FDD)
方法论中核心的概念 在 FDD 的定义中 一个特征就是一个 小的 具有客户价值的功能 它通常是采用 <action> <result> <object> 的形式来描述的 例如用自然语言描述的一句命令
于时间表
图 3 进度报告解析 3.4 设计并实现
完成计划工作后 就通过不断的 设计与构造 的迭代 最终使整个项目完成 主程序员负责确保整个特征集的实现
4 结论
本项目获得了最终的成功 并与总进度相差无几 由于 UML 成为标准 统一软件开发过程(RUP)越来越受 到人们的重视 OO 开发普遍选择用例驱动开发 但对于功 能模块比较多 开发时间比较紧的软件开发 特征驱动开发
3.3 制定迭代计划 形成了完整的特征表后 就需制定计划 将整个开发工
作分成多个迭代 每个迭代完成部分特征 一步步地完成整
个系统的构建 制定迭代计划时 成立了一个特征计划小组
由项目经理 主设计师 所有参与项目的主程序员组成 根
据特征集的大小 依赖关系将特征集分配给程序员 并且按
照以下原则将特征安排到每次迭代中去
Key words Software engineering; Feature-driven development; Agile method; Custom value
1 概述
自软件工程诞生以来 专家们试图通过技术和管理的手 段来降低软件项目的风险 结构化 面向对象 CMM 这些新 技术有助于 软件危机 的解决 然而其繁文缛节的 官僚 过程又使软件业陷入新的低效泥潭[3]
初始化敌方实体数据发送
到此为止 我们没有考虑 UI(用户界面层) DM(数据管
理层) SI(系统交互层) 因为对用户而言 其最关心 最熟
悉的是 PD(问题领域)层的特征 在完成了 PD 的特征表之后
再构建 UI DM SI 层的特性表 它们可以生成单独的一个
主特征表 这样做可以避免开发团队过早陷入技术细节
特征集
特征
1
指挥系统
任务下达
在任务列表中添加一个任务
2
指挥系统
任务下达
3
指挥系统
任务下达
4
指挥系统
任务下达
在任务的我方实体列表中 添加参加训练的我方实体 在任务的敌方实体列表中
添加设定的敌方实体 目标实体分配
5
指挥系统
任务下达
初始化环境数据发送
6
指挥系统
任务下达
初始化我方实体数据发送
7
指挥系统
任务下达
66
将注意力放在 客户价值 的体现上
在现代软件开发方法中 XP 中的 user story(用户故事) 以及 UML 中的 use case(用例) 与这一思想高度一致 它 们都试图从客户的视角 问题域的视角来理解软件的需求
FDD 的创建者认为 Feature 与 user story 十分接近 而 use case 则太复杂 但它们在思想上基本是一致的 其实 use case 是 一种合成技术 将在需求捕获中收集的零散的特性合成为用
Research and Application of Feature-driven Development
LIU Haiyan, ZHENG Xiangyu, CHEN Kejin (Institute of Computer Software, Xi’an Jiaotong University, Xi’an 710049)
摘 要 特征驱动开发是软件工程领域的一种新方法 与现有的方法相比 特征驱动开发使开发人员将注意力放在最能体现 客户价值 的核心模块上 该文通过特征驱动开发在一个具体项目中的应用 对特征驱动开发实践作了详细阐述 并分析了特征驱动开发在明确的职 责分配和精确的进度管理等方面的成功之处 关键词 软件工程 特征驱动开发 敏捷方法 客户价值
Abstract Feature-driven development (FDD) is a new method of the software engineering. Comparing with the existing methods, FDD makes programmer pay more attention to the key module that shows "customer value". This paper gives detailed description of FDD application through a concrete project and successfully analyses FDD on clear responsibility distribution and precise process management.
的大小适当地分配给具体的开发人员开发 由于特征的开发
计划已经列出 因此每个类的开发计划也就很容易得到
在本阶段 将生成两张表 这两张表将指导以后的整个
开发过程
(1) 主程序员负责特征集如表 4 所示 每个主程序员将 负责一系列特征集的开发 一个主程序员的特征集的完成日
期应尽可能均匀地分布在整个项目开发周期
相关文档
最新文档