（工商管理专业论文）极限编程在××供电公司物资计划管理信息系统开发中的应用.pdf

南京理工大学硕士学位论文极限 编程在x火 供电公司 物资 计划管理信息系统开发中 的应用 ab s t t a c t s ome of此 叨n “ 甲 tsand m e th ods e x p l o r edinthe 叮 l y s t a g e ofthe com p u t er 对c ” 。 e d o t o 川 yco切l er a d edth e d evei o p m ent ofth c so几 w ar e ， b uta l soare w i d e l y used 奴吻. therefo 低the key i s to加脚rt th e p r a ct l c e- 户 ro v edth co ryofso ft w ar e 即 9 叮 。 闭n g to the so ft w ar e d e v e l o p m ent p ro 璐s an d i n d u e n c 吧 the t h o u ght an d d e c l s in n m 山ngp ro cess of阮 d e v e l 叩er，w b i 比can avo 记the fo n n ationofthe fa u l ty印n 以 争 tsand 也 创 山 叼5 云 o m 由e b um anand p r o c e s s as p 峨， soft w ar e d e v e l 叩吨 m e 田 ”加t ouly the p r o gr 山 ncod ln g b utal som ake pl anand m ana g c th e 二 a ct i vi ti esofso丘 w 别 陷d evel o p m e n t soft w aj 限e n 乡 刀 既 滋 n g res已 ar c b eshowto d e v e l o psoff w are t d o r ce 月 记 c h 功 1 1 y.in so几 w 盯 cengin g，th o 叨 50 几 w ar cp r o a 招 5 m odel s 哪 mostl 侧 portan titisin d i catedth a t di ff 改 。 吐p r o cess escan m ake di 月 七 r ent r esu l ts. ex仃 曰 旧 e p ro gr a “ 助i n g ( x p )isa n e 甲 ， 1 i ghtwd ght so n w ax e d ev e 1 o p mg a p p r 0 a c b a 即已 奴 曰inn 沉 沈 口 t y e ar s . his尔for the ， n al l orm edium p r oj 。 眺 ， x puses ia p l d fe ed b a ck 阴d hi gh七and w l d thc o n u n u 山 口t i 姐to刃 q a x ir 比 以 c d e l i v er edv al 讹， vi a anon- s l 妞.s to mer ， a p articu l ar川 浏加g ap p r o a c 权叻 d 妙 tant t es t in g 加面s p a p 留 ， we d es 侧b e 山 e pro 嘟s d evel o p i n gth e ma l erialpi叻朋dh and l m g s y s t 。 几 using盔 x tr 曰 旧 ep r o 邵 班 山 川 n gm odelswep ra ct i c 目so m einstr u c t i o nin x p.5 o m eofth 助 are: u n d ers加 口 du se r ls r 阅u ir 。 叮 ent usin gthe to ofu 脚 s t o ri es: p ra c 6 份pi 剑 山 ” n gg ame，m ake r e l 已 眨 姆pl an， 劝 “ a t i on pl an，expi ni tati on 讨 阳即dediti on pl an;p air p ro gr 即 叮 目 ” n g othoe x tr 。 力 ep ro gr 刽 国 比 口 ln gc a u 别 沼the com p lex pr ol ect d e v el o p m ent tos l 哪l e an d d i r ec t hi 咧y e 饰 ec t i v e ， 面s h asthe re 丘 犷 enceval加tothe 别 刀 al l 加 伪 而a t i on s y s t 。 叮d c v d o p m ent . key、 v ords : e x tr 。 力 e5 o n w ar e engi n e enn glifec yclemo d d 声明 本学位论文是我在导师的指导下取得的研究成果， 尽我所知， 在 本学位论文中， 除了加以 标注和致谢的部分外， 不包含其他人己经发 表或公布过的研究成果， 也不包含我为获得任何教育机构的学位或学 历而使用过的材料。 与我一同工作的同 事对本学位论文做出的贡献均 己在论文中作 了明确的说明。 研 究 生 扎呈 月 1 心 心 乙 年 明 知日 学位论文使用授权声明 南京理工大学有权保存本学位论文的电 子和纸质文档， 可以借阅 或上网公布本学位论文的全部或部分内 容， 可以向 有关部门 或机构送 交并授权其保存、 借阅或上网公布本学位论文的全部或部分内 容。 对 于保密论文，按保密的有关规定和程序处理。 研究生签名:之 刃 . 乙 年 阵 月弘日 南京理工大学硕士学位论文极限编程在xx供电公司物资计划管理信息系统开发中的应用 1引言 计算机和通信技术的迅猛发展， 特别是功 t 。 刃 et技术的发展与普及， 为企业内 部、 企业与 外部提供了 快速、 准确、 可靠的 信息交流渠道。 信息化企业运作管理系统已 成 为江苏电力的必备支持系统。 这给服务于江苏电 力的软件开发组织带来了空前发展的 机遇， 其中软件项目 管理在其发展过程中占有重要地位。 所谓软件项目 管理， 即对具 体的软件项目 进行整体、范围、 时间、 成本、 质量、 人力资源、 沟通、 风险、 采购等 方面的管理。 软件项目 管理极具挑战性和创造性， 在管理上没有成熟的经验可供借鉴。 对软件 开发团队而言， 提升竞争力， 最重要的是切实加强项目 管理， 从根本上全面提高其管 理水乎，对需求的分析能力，对工作目 标的细化分解能力，对开发项目时间、质量、 成本的控制能力。 通常，在实施项目 管理过程中会面临四个方面的 挑战: 一是项目定义中的问题。 如何合理地定义用户需求， 明确项目 范围是实施项目 管 理面临的首要问题。 用户与软件开发团队之间具有很强的互动性， 信息技术日新月异， 用户需求呈现出多样性、不确定性和个性化的特点， 开发团队要与用户充分沟通， 共 同进行充分挖掘，才能真正贴近用户的需求。 二是项目 组织实施中的问题。 软件开发团队是高智力密集型的， 也是一个比较浮 躁的团队， 不仅易使项目 资源调度复杂化， 进而影响到项目 的实施进度， 而且在实施 过程中还不可避免地存在着功能型部门与项目团队的冲突、 知识员工的个性化与团队 运作模式的冲突等，这也是项目 实施过程中必须考虑的。 三是项目 控制中的问 题。 软件在项目 实施全过程中， 开发团队需要与用户进行充 分沟通与交流， 严格保证和控制各项里程碑的完成时间。 其中任何一个环节、 任何一 个里程碑出现问题， 都会影响到整个项目的进程。 另外， 在软件项目管理中，常常会 面临应用技术、业务需求等方面的变化，这也增加了 项目 控制的难度。 四是项目 评价中的问 题。项目 评价有两个方面，一是评价项目，由于rr项目 用 户需求难以定义清晰，导致项目 范围模糊，这给合理地评价项目 带来了困 难; 二是评 价项目 成员， 对于rr项目 来说， 项目 员工具有较强的 个性，渴望价值创造与自 我实 现， 如何做到公正、 客观、 量化地评价员工的价值， 也是软件项目 管理的 难点。 在近年来江苏电 力提出的“ 硬件集中、 软件集成” 的 指导思想下， 对一个县级供 电企业而言， 其软件开发项目以 投资少、 见效快的小型项目 为主， 因此探寻小型软件 项目 的 项目 管理方法， 控制其开发活 动的复杂性， 解决软件开发过程中的诸如控制风 险、时间、成本、质量等问 题有着积极的实践意义。 南京理工大学硕士学位论文极限编程在xx 供电公司物资计划管理信息系统开发中的应用 l l软件工程概述 2 0 世纪60年代， 随着美国军事扩张和新一代计算机的 面世， 软件开发的 增长速 度在不断加快。 然而， 在如何编写软件、 理解需求以 及如何成功的完成项目 方面， 仍 没有清晰的指导原则。那时开发的系统通常很简单，而且是基于批处理的。 但是， 基于“ 能用即可” 的理念且不采用任何约束条件来开发系统常常导致项目 失 败. 在19 68年的 一 次n 八 了 0( n o “ h atian ti c t r ea t y o r g 画zati on， 北 大西 洋公 约 组 织) 会议中， 人们呼吁解决软件危机， 并首次使用了术语软件工程。 为解决项目 越来 越混乱的问题，将机械和土木工程中的尝试和测试方法用于软件开发中。 软件工程是应用计算机科学、 数学及管理科学等原理开发软件的工程。 它借鉴了 传统工程的原则、 方法， 以提高质量， 降低成本。 在软件工程思想逐渐形成与发展中， 该领域出现了很多软件开发模型与方法， 例如瀑布模型、 快速原型模型、 螺旋模型等 等。 而在 00 年代以 后，卡耐基梅隆软件学院推出的c m m， 更是对于软件开发的过 程管理， 提出了确切的衡量指标。 但是， 最近的研究表明， 有5 0 %的项目 会拖延交付， 有3 0 %以上的项目 会超出预算， 软件开发领域的项目 情况比软件工程刚刚提出的时候 相比，只是有很小的提高。详细的数据如表1 . 1 . 1 所示: 表 1 . l l 软件项目 统计数据 时间成功失败待定 1 9 941 6 %31 % 5 3 % 1 9 9 82 7 %4 0 %3 3 % 2 以刃2 6 %2 8 % 礴 6 % 2 00 22 8 %2 3 %4 男毛 ( 数据来自2 1洲 x 年5 加 口 d i s b g ro u p 的g ro u p c h a o s 歇伪rt ) 从表1 . 1 1 可以看出， 成功的项目 所占百分比得到了稳步的提高。 1 9 94年只有1 6 % 的项目 成功，而在2 (x)0 年有28%的项目 成功。尽管28% 要比1 6 % 好，但是结果还是 不容乐观。 传统的软件开发过程，以r u p( r at i o n a 1 u 山 fi 目 p r o cess) 为代表，强调项目的 可 控 性， 是一 个 用 例 驱 动的 基 于u m l( u 币 fi edmod el ing l 切 邵 坦 s e ) 和构 件式 架 构的 迭代增量式开发过程。 r u p定义了初始、细化、实现和部署4个阶段，分别对应着 关键里程碑的 划分。 r u p对于角色、 流程、 工件和活动的 要求是灵活、可配置的， 所以 它广泛的 适用于各种类型的项目 。 但是， 在r u p的 各个里程碑中，都规定了 要 交付的成果， 尤其是对于需求的变更以 及文档， 它强调及时的更新与同步。 以 上这些 都决定了r u p是一种重量级的软件开发方法，比较适合大中型的软件项目 和产品开 南京理工大学硕士学位论文极限 编程在xx 供电公司物资 计划管理信息系 统开发中 的应用 发。 在软件的开发过程中，人们逐渐认识到消除与客户之间的隔阂是项目 成功的关 键. 也就是说， 最根本的成功在于让客户满意。 在近十年来， 涌现了 大量高 度灵活的、 以 客户为中心的开发方法， 将软件开发融艺术和工程于一体。 通常， 开发小组面临的 最大的挑战在于难以从客户那里获取清晰的需求，因为需求在项目 之初常常是模糊 的， 而且处于不断的变化之中。 开发人员只有清楚地了解了用户需求后， 才能创建满 足这些需求的软件。 近四 十年来， 计算机行业一直在 试图 解决这个难题。 软件能否体 现用户的想法并满足其需求是项目 成功与否的关键. 1 .2软件开发的生命周期模型 软件通常始于一个比 较含糊的概念上的需求， 而一旦这个需求被肯定， 接下来就 会进行一系列开发工作。 对于某个项目 来说， 具体应用的领域的不同会导致需求的不 同， 某个需求的 概念开始时是很模糊的， 需要经过规格化说明、 设计和实现等一些开 发阶段才能将满足这个需求的产品具体的实在的呈现出来。如果得到了用户的认可， 产品就会投入运行并进行一些日 常性的维护。 当软件被淘汰时， 它的使命也就结束了。 软件产品所经历的这一系列阶段被称之为软件生命周期模型。 产品不同， 它所采用的生命周期模型也不尽相同。 有些产品在概念设计上得花几 年时间， 也许只是因为当时的硬件的性能还不能达到所需要的水平， 或者是为了开发 一个高效的算法需要做大量的基础性研究; 有的产品可能很快就能设计和实现， 然而 却要花费很长的时间进行维护和修改以 满足用户不断变更的需求; 还有一些产品是设 计开发出来了， 并进行维护， 但在经过多年的维护以后， 我们会发现与其继续花很高 的成本来维护当前的产品， 不如重新开发一个新的产品. 具体到某个产品的开发， 通 常是有时间的限制， 这样， 在规定的期限内 合理的分配时间和资源用于进行那些对产 品质量等评价标准起作用的活动是项目 成功的关键， 换句话说， 选用合适的生命周期 模型是进行开发之前的 必行步骤。 下面将讨论现在使用较为普遍的几种软件生命周期模型，并分析其各自 的优缺 点. l 2. 1 构建和 修补 模型 构建和修补模型是软件产品最早采用的一种模型， 可能也是使用得最为广泛一个 模型。 产品不经过规格说明 和设计， 开发人员只是简单的构建一个系统， 如果用 户不 满意就进行修改， 重复以 上过程直到用户满意为止。 该 模型如图1 2 . 1 . 1 所示。 南京理工大学硕士学位论 文极限 编程在xx 供电公司物资计划管理信息系统开发中的 应用 图1 .2.1 . 1 构建和修补模型 一般来说这种开发方式对只有1 00到2 00行代码规模的系统很有效， 但是对那些 规模稍微再大一些的系统， 这样的开发方式己经不能满足要求。 越在开发早期对系统 进行修改所需的成本相对来说越少， 而如果当系统己 经完成编码或在维护期间再进行 修改的话， 所花的代价通常是不可接受的。 这样， 用构建并修补模型生产出来的产品 的成本通常要比经过好的规范说明、 精心设计过的软件产品的成本要高. 另外， 对一 个没有规格说明和设计文档的产品进行维护是相当困 难的， 衰退性失效发生的概率也 是很高的。 l 2. 2 澡布模型 典型的瀑布模型 ( w at e r fa l 】 功 州 由 冈)可以 用b.w.b 此知 口的描述，他将软件生命 周期划分为 七个阶段， 每个阶段的 任务分别为: 系统需求分析， 软件需求分析， 概要 设计， 详细设计， 编码， 测试和运行维护。 每一阶段工作的 完成需要确认， 如图1 .2. 2 . 1 所示。 南京理工大学硕士学位论文极限编程在xx 供电公司物资计划管理信息系统开发中的应用 ，:书11. . .- -一 -. - - -.- . -. - .- -.一 一门 -. :，1，:，. 期 问题定义 项目任务书 可行性研究 可行性报告 需求分析需求规格说明书 总体设计总体设计文档 期 详细设计 详细设计文档 编码 程序代码文档 测试 测试文档 寸 期 运行维护 阶 段过程 . -一.-二-二.-.-.-一.-二口-.-.-一-.-.，.- 图1 . 2. 2 . 1 爆布模型 爆布模型的主要特点是: 阶段间的顺序性和依赖性。 开发过程是一个严格的下导 式过程， 即前一阶段的输出是后一阶段的输入， 每一阶段工作的完成需要确认， 而确 认过程是严格的追溯式过程，后一阶段出现了问题要从前一阶段的重新确认来解决， 因此，问 题发现的越晚，解决问 题的代价就越高。 瀑布模型的主要不足有以 下二点: 第一， 从认识论上讲， 人的认识是一个多次反复的过程， 实践 认识 再实 践再认识， 多次认识，多次飞跃， 最后才能获得对客观世界较为正确的认识. 软 件开发是人的一个智力认识活动， 不可能一次完成， 需要多次反复地进行， 但瀑布模 型中划分的几个阶段，没有反映出这种认识过程的反复性。 第二， 软件开发是一个知识密集型的开发活动， 需要人们合作完成，因此， 人员 之间的 通讯和软件工具之间的 联系， 活动之间的并行和串 行等都是必需的， 但在瀑布 模型中也没有体现出这一点。 l z j快速原型模型 快 速原 型 ( 砌p i d p ro t o 悠 ， e)指的 是 在 功能上 和 产品 的 某个子集等效的 一个能 运 作的模型。 借助程序自 动生成工具或软件工程支撑环境， 尽快地构造一个实际系统的 简化模型， 供开发人员和用户进行交流， 以便较准确地获取用户的需求， 该模型如图 6 南京理工大学硕士学位论文极限 编程在x又 供电公司 物资计划管理 信息系统开发中的应用 1 2 3 . 1 所示。 图1 . 2. 3. 1 快速原型 模型 快速原型模型的主要特点是: 首先建立一个能够反映用户主要需求的原型， 为用 户展示未来软件系统的概貌， 使用户可以比 较直观地从最终软件产品的角度出发对原 型提出修改意见， 软件人员反复改进， 最终建立完全符合用户要求的软件系统。 这实 际上是一个软件人员不断向用户提供样品， 而用户对其做出迅速反馈， 以进一步改善 样品的过程， 从而避免了 瀑布模型冗长的开发过程中， 看不见最终软件产品雏形的现 象。 快速原型法在各个阶段用户反馈活动的基础上， 突出了快速的改造过程， 它改变 了 爆布模型的线性结构， 采用逐步求精方法使原型逐步完善， 以满足用户的要求， 是 一种在新的高层次上不断反复推进的过程. 但快速原型法有以下二点不足: 第一， 为了使系统尽快地运行起来， 系统开发初期往往考虑的 不周全， 经常采取 一些折中的方案， 有可能使原型不能成为 最终软件产品的一部分， 只是一个示例而己。 这样. 在实际开发软件产品时，仍然有许多的工作要做. 第二， 快速原型法需要大量完备而实用的软件工具的支持， 即对工具和环境的依 赖性较高。 l 2. 4 螺旋模型 螺旋模型如图1 .2. 4. 1 所示: 南京理工大学硕士学位论文极限编程在xx 供电公司物资计划管理信息系统开发中的应用 图1 一 2. 4 . 1 螺旋模型图 采用螺旋生命周期模型开发应用系统的步骤简单归纳如下: 第一步: 通过访问、面谈或调研后获得用户需求意见。 第二步:基于己 知的需求分析很快设计一个应用系统原型。 第三步:将原型交给最终用户，让其使用。 第四步:从最终用户那里获得反馈，更改用户需求。 第五步:建立下一个原型，加入新的用户需求。 重复上述过程，直到该应用软件完成或报废. 在上述模型中从第一步到第五步就完成一个版本， 每完成一个版本就有一次风险 分析， 螺旋线第一圈的开始点可能是一个概念项目。 从第二圈子开始， 一个新产品开 发项目 开始了， 新产品的演化沿着螺旋线进行若干次迭代， 一直运转到软件生命期结 束。 该模型的特点是将迭代的观点引入软件项目 的管理， 强调风险管理， 强调各开发 阶段的 质量，并提供机会检讨项目 是否有价值继续下去。 l 2. 5 增量模型 逐步增量式的构建软件的方法经过发展被理论化成为叫做“ 增量模型” 的软件生 命周期模型。 产品被作为一系列的增量构件来设计、 实现、 集成和测试， 每个构件是 由多 种相互作用的模块所形成的 提供特定功能的 代码片段构成。 该模型如图 1 2. 5 . 1 尔 . 南京理工大学硕士学位论文 极限 编程在xx 供电公司物资计划管理信息系统开发中的应用 霉淤曝犷 设 计 系 擎 像絮姑构 开发鲜 淤 霭淤霉牙 认系统 图1 .25. 1 增量模型 增量模型在各个阶段并不交付一个可运行的完整产品， 而是交付满足客户需求 的 可运行产品的一个子集。 整个产品被分解成构件， 开发人员一个构件接一个构件地 交付产品。 典型的 产品通常由10到5 0 个构件组成。 每个阶段客户都得到一个完成部分需求 的 可运行产品。从第一个构件交付后开始，客户就能开展一些业务工作。 使用该模型， 整个产品的各个部分可能在几周内 就可使用了， 使用瀑布模型或快 速原型模型时，客户可能要等几个月甚至几年才回收到一个产品。 该模型的困 难在于每个附加的构件在并入现有的软件体系结构时， 必须不破坏原 来已 构造好的东西。 从某种意义上说， 增量模型本身是自 相矛盾的， 有时可能导致构 件无法安装到一起。 l 2. 6 同 步稳定 模型 同步稳定模型也是增量模型的一个版本， 微软公司使用这个模型并取得了巨大的 成功。 在需求分析阶段， 开发人员对一些有代表性的客户进行访问， 从访问中得出一些 有优先级别的功能需求， 完成规格说明。 接着按照优先级来构造那些构件部分。 每个 构 件部分由 一 些小的团 队 并 行完成。 到 交付的 时 刻， 所有的 团 队同 步(s ”cbro mze )， 也就是说把所有的部分集成起来进行测试和调试。 在每个构件部分的收尾阶段进行稳 定性 ( s t abil 此 ation)的工作。所有遗留下来被发现的并且改正了的错误都被冻结 ( fro彻 ) ，也就是说，将不会再对规格说明进行更改。 重复的同步步骤能保证每个组件内 部协调一致。 正规运行每个构件部分的另一个 好处是开发人员可以在开发早期就深入了解系统的运行，并能随时根据需要更改需 求。甚至在初始的规格说明没有完成之前也可以 使用这个模型。 l 2. ， r u p方法 r u p ( r 泊 t io na1 u ul 五 edp ro 昭5 ) 是一种过程，它使用一套标准的工具、 模板和 可交付产品提供了 一种严格有序的开发方法。 r u p与前面介绍的其他方法之间的不 同之处在于， 它由厂商r a ti o n als o n w are 所拥有。 这种标准化方法对要求在整个公司 南京理工大学硕士学位论文极限 编程在xx 供电公司物资 计划管理信息系统开发中的应用 内部使用一种通用的语言和工具的大型组织很有吸引力。 r u 甲使用统一建模语言 ( u ml )来表达需求、构架、设计。 u ml最初是由r j t i o n als o n w are 公司开发的， 现在由 标准 组织o m g ( 。 坷 ectm an a g 。 叮 ent g r o u p ) 维护。 r u p 是另一种迭代式开发方法，重点关注降低项目 风险。图1 2 :71 说明了r u p 方法的流程。 业务建模 分析和设计 配置修改管理环境 初始规划测试 评估 部署 图 1 一 1 7. i r 兀 p流程 对于需要维护用于外部交流和开发小组内部交流标准的组织而言， r u 甲非常有 价值。 但其缺点是需要更多的文档、客户必须对r u p有所了 解、这种方法归一个软 件厂商所有。 1 :2 极限 编程 极限 编 程( 以 廿 曰 叮 e progr a a n n in g ) 是目 前流行的 敏捷开发方 法， 尤 其 适合用于 动 态的加 t ernet开发领域。 在某种程度上来说是一种基于增量模型上的颇具争议的新的 软件开发方法。 它与传统的瀑布模型或快速原型模型的区别在于， 它承认软件生命周 期中充满变化。中小型小组 (6一 2 0 人)同 客户紧密合作， 放弃详细、 预先的规划， 而 通过快速迭代来给客户提供直截了当真正的结果。 大多数开发人员、 程序员和软件工程师认为， 必须避免、 控制和管理变化。 爆布 模型完全是以 此为前提的。 在软件开发周期中，尽可能早地控制变化是不错的想法， 因为产品在实现后， 变化的成本常常会急剧升高。 极限编程提供了一些技巧和实践有 效地压缩了 变化的成本。 图1 .2. 8 . 1 说明了 极限 编程方法的开发流程。 南京理工大学硕士学位论文极限编程在xx 供电公司物资计划管理信息系统开发中的应用 图1 一2. 8 . 1 极限 编程方法 极限编程通过在质量谱系的两端， 准确的需求和健壮的产品， 下功夫来交付高质 量的软件。极限 编程不依赖于单个 “ 高效的” 方法，而是结合使用了12种重要的实 践， 如结对编程、 集体拥有、 持续集成、以一组重点关注的价值为指导。 这些实践协 同工作，使得极限编程人员能够快速、 准确地为其客户开发出高质量的软件。 l 2. ， 回顾并比较生命周期模型 从瀑布模型开始， 各个阶段之间有清楚的反馈循环回路， 到为了减少各个阶段之 间交互的快速原型模型， 再到关注降低项目 风险的r u p方法， 最后到极限编程方法， 可以 看出各阶段之间的交互是软件开发内 在的本质要求。 综合以上论述， 在实际开发中应当尽量避免构建并修补模型。 瀑布模型经过大量 采用已 经成熟，通常能收到很好效果。 快速原型模型可以 弥补瀑布模型的一些缺陷， 即开发出来的产品可能并不能满足用户的实际需求， 然而快速原型模型并不像瀑布模 型发展得那么成熟， 其自 身也存在很多问 题. 一种选择是结合这两种模型的长处， 另 外一种选择是使用新的模型， 即增量模型。 增量模型在其优点之外也有其缺点。 同步 稳定模型只在微软得到很好的应用， 没有证据能说明这种开发方法能被普遍采用。 极 限编程是一种有争议的全新的开发方法。 极限编程通过过早的解决缺陷和不断的提供 有关产品的反馈信息，允许在项目 的整个生命周期进行变更，并改进产品的质量. 1 3论文背景及论文结构 本论文以常州用友安易软件公司为满足武进供电公司生产管理所需联合定制开 发的项目为背景展开研究。 由 于xx 供电公司物资计划管理信息系统是一个小型项目 ，开发团队人员不太 多， 在开发初期项目 需求经常发生变化， 项目 开发小组成员在开发初期运用传统软件 项目 管理方法瀑布模型遭遇失败后， 详细地探讨了开发过程中运用极限编程的方 南京理工大学硕士学位论文极限编程在xx 供电公司物资计划管理信息系统开发中的应用 方面面， 有意识地运用敏捷管理的思想， 希望能为将来类似软件项目 的开发过程管理 提供借鉴， 决定在本项目 中应用极限编程这一全新的开发方法作为一个尝试。 但在项 目 执行过程中并没有完全套用极限编程的所有实践. 本文介绍了将极限编程方法应用于xx供电公司物资计划管理信息系统的开发 过程， 并给出了系统的需求与设计方案。 在xx 供电公司物资计划管理信息系统开发 过程中，本文重点讨论了极限编程在项目开发中的几个最佳实践。 本文一共有六章组成。 第一章引言， 介绍了软件工程的基本概念并分析了现有的 几种生命周期模型。第二章极限编程法， 介绍了极限编程的组成部分及其工作原理。 第三章xx 供电公司物资计划管理信息系统总体设计， 介绍xx 供电公司物资计划管 理信息系统的需求分析， 并进行了总体架构设计。 第四章xx 供电公司物资计划管理 信息系统的开发流程: 实现x p的开发流程， 讨论了 在物资计划管理信息系统项目 开 发中如何实现极限 编程的过程模型。 第五章xx 供电 公司物资计划管理信息系统的开 发管理: 实践x p的过程模型， 概述了在项目 中实践极限编程的一些重要原则。 第六 章极限编程的一些优势， 介绍了极限编程相对于传统开发方法的一些优势。 在结束语 部分对本文的主要工作做了一个总结。 南京理工大学硕士学位论文极限编程在x又 供电公司 物资 计划管理信息系统开发中的应用 2极限 编程法 2 . 1 极限 编程概述 极限编程 ( x p ) 是以开发符合变化的客户需求的软件为目 标而产生的一种方法. 这种开发方法是由k e n t b ec k 在1 9 %年提出的。 k en t b e c k 在九十年代初期与w 汾 d c 助 而 n gh am 合 作时 ， 就 一 直共同 探索 着 新的 软 件开 发 方 法， 希 望 能 使 软 件 开 发 更 加 简单而有效。 k ent 仔细地观察和分析了 各种简化软件开发的 前提条件、可行性以及 面临的困 难。 19 %年3 月， k ed t 终 于 在为d a i m l e rc知 甲 s l er所做的 一个 项目 中 引入了 新的软件开发观念极限编程。 近年来， 国内 应用极限编程的例子也不少， 其中在 工控领域、 公路建设招投标领域、 数字版权保护领域以及外贸管理领域都有相应的研 究与应用。 一般说来， 极限 编程是一种敏捷 ( a gi l e) 开发方法。 供中小型软件开发小组用 于开发需求快速变化的软件。 极限编程由4 部分组成: 价值、 原则、 实践和行为。 图 2 1 . 1 说明了它们彼此之间的依赖关系， 其中行为贯穿于整个生命周期。 图z l i x p 基于核心价值，由 行为、实践和原则支持 极限编程源自 一系列的协作、 潮流 ( s tr e 出 刀 ) 和系统， 建立在价值和指导原则的 基础之上.围绕这一核心的是极限 编程实践和行为。由 图2. 1 .2 可知， 极限 编程是由 协作作用的4 部分组成的， 这4 部分产生于关键的影响因素， 最终获得高质量的产品。 南京理工大学硕士学位论文极限编程在x只 供电公司 物资 计划管理信息系统开发中的应用 影响因素高质量的产品 图2 . 1 2 x r 源自 对创建高 质量产品的需 求 2. l i 极限 编程的 价值 观 极限编程是由一组共享的价值观驱动的，这些价值观决定了极限编程开发的基 调。 极限编程包括4 种价值观， 它们是简单、交流、反馈和勇气. 在极限编程中，简单的定义为 “ 在管用的前提下，做最简单的事情” 。在考虑到 简单性时， 开发小组实现客户实际需要的， 而不是他们预期可能需要的。 简单的系统 交流起来更容易、集成点更少、伸缩性更高。 所有的软件开发方法都需要交流， 而在极限编程中， 交流是其核心价值观。 它侧 重于口 头交流， 而不是文档、 报表和计划。 如果小组成员之间不进行持续的交流， 协 作将无从谈起。极限编程包含诸如结对编程等实践， 它们要求通过交流进行工作。 反馈对于任何软件项目的成功都是及其关键的。 在极限编程中， 有关软件状态的 问题是通过持续、 明确的反馈来实现的。 开发小组必须快速地编写软件， 然后向客户 演示。为确保准确性和高质量，准确获取客户的反馈是至关重要的。 勇气指的是快速工作并在必要时重新进行开发的信心。 在极限编程中， 应在其它 3 种价值观的语境中来理解勇气。 极限 编程人员改变了 尝试性、 不确定编码的开发思 想， 采用以最快速度， 充满信心进行开发的做法。 简单性是支持勇气的另一种价值观。 小组成员了 解系统， 有强大的支持源代码重构的质量标准。 没有其价值观， 勇气只会 导致一大堆混乱的代码，软件复杂而难以维护。 2. l 2 极限 编 程的 原 则 建立在极限编程核心价值观之上的是5 项指导软件开发的主要原则， 它们是快速 反馈、简单性假设、 逐步修改、拥抱变化和高质量的工作。 快速反馈是指开发人员通过简短的反馈循环迅速了 解其当前产品是否满足了客 南京理工大学硕士学位论文极限编程在xx供电公司物资计划管理信息系统开发中的应用 户的需求。 简单性假设是指将每个问题都视为很容易解决， 这意味着只需为当前迭代打算， 而无需洞察未来可能需要什么。 逐步修改是指通过一系列细微的修改来解决问题。这适用于规划、开发和设计。 拥抱变化是指采用保留选项，同时解决紧迫问题的策略. 高质量的工作是指工作质量决不可打折扣.极限编程采用测试先行的编程方式， 强调编码和测试的重要性。 2. i j极限 编程的行为 在极限编程的生命周期中， 贯穿了一系列的行为， 它们包括倾听、 测试、 编码和 设计。 极限 编程以 交流为基础， 其一些实践要求积极的 倾听、 它对正 式的 书面文档的 依赖性更低， 因 此要求高质量的口 头交流。 开发人员不仅需要倾听客户， 开发人员之 间也应相互倾听同伴的看法。极限编程的一些实践将指导如何更好的进行交流。 在极限编程中， 测试并不是在将产品交付给客户之前进行的 惯例， 而是在整个开 发过程中不可或缺的一步。 开发人员在开发代码之前将编写测试。 极限 编程测试不仅 限于准确性和缺陷 测量方面， 还将检查性能和一致性。 极限编程毕竟是关于编码的， 编写代码是一种工艺， 通过诸如重构、 结对编程和 代码复核等实践得以改进。 几乎没有书面设计， 极限 编程开发人员书写表达其意图的 代码。只需通过阅读源代码，其他小组成员便可以理解其中的逻辑、算法和流程。 极限编程的核心思想之一是:在整个项目的进展过程中，设计应是不断演化的。 设计并非固定的， 不能赋予它单个职责， 而是基于小组的、 动态的。 极限编程接受系 统的自 然演进， 而不是通过限制设计行为， 忽视对前面所述的事实。 极限编程同其它 方法之间的区别在于其流动性及对设计特性的响应。 2. l 4 极限 编程的 最佳实践 极限编程将行为表示为12种核心实践。极限编程小组每天都使用这些实践来开 发系统。 这些实践包括: 现场客户 ( 0 匕 份 s i t e c u 劝 o m er) ， 代码规范 (c ode s 恒 。 伽心 ) ， 每周40小时 工作制(40 七 。 近w 比 k ) ， 规划游戏( pi 田 山 ” n g g 呼 ) ， 系统隐喻( 5 ” t eln m e t a p b o r ) ， 简 单设 计 ( 5 加p le d esi，) ， 测 试驱 动( 不 留 t . dri彻 ) ， 代码 重 构 ( refa c t o ri n g ) ， 结 对编程 (pair progr 别 田 口 ” n g ) ， 集体代码所有权 ( c ol l 翻代 。 w n er s hi p ) ， 持续 集成 ( c o n t i nuo ushile 脚t i o n ) ， 小型发布 ( s m a l l r el 七 a s e ) 。 ( 1) 现场客户 极限 编程要求至少有一名实际的客户代表在整个项目 开发周期内 在现场负责确 定需求、 回答团队问 题以 及编写功能验收测试。 现场用户可以 从一定程度上解决项目 团队与客户沟通不畅的问题。 南京理工大学硕士学位论文极限编程在xx 供电公司物资计划管理信息系统开发中的应用 ( 2 ) 代码规范 极限编程强调通过制定严格的代码规范来进行沟通， 尽可能减少不必要的文档。 极限编程对于代码规范的实践，具有双重含义:一是希望通过建立统一的代码规范， 来加强开发人员之间的 沟通，同时为代码复核提供了 一定的 标准; 二是希望减少项目 开发过程中的文档，极限编程认为代码是最好的文档。 (3) 每周40小时 工作制 极限编程要求项目 团队人员每周工作时间不能超过40 小时，加班不得连续超过 两周， 否则反而会影响生 产率。该实践充分体现了 极限编程的“ 以 人为本”的 原则。 ( 4 ) 规划游戏 极限编程要求结合项目 进展和技术情况，确定下一阶段要开发与发布的系统范 围。规划游戏需要快速制定出粗略的 规划，然后随项目 的进展不断对其进行改进. 项目的计划在建立起来以后， 需要根据项目的进展来进行调整， 一成不变的计划 是不存在。因 此， 项目 团队需要控制风险、 预见变化， 从而制定有效、 可行的项目 计 划。 ( 5 )系统隐喻 极限编程通过隐喻来描述系统如何实现新的功能以 及如何将该功能加入到系统。 它通常包含了一些可以 参照和比 较的类和设计模式。 隐喻让技术对客户来说更容易理 解.极限编程不需要事先进行详细的架构设计。 极限编程在系统实现初期不需要进行详细的架构设计， 而是在迭代周期中不断的 细化架构。 对于小型的系统或者架构设计的分析会推迟整个项目的计划的情况下， 逐 步细化系统架构是可以的: 但是， 对于大型系统或者是希望采用新架构的系统， 就需 要在项目 初期进行详细的系统架构设计， 并在第一个迭代周期中进行验证， 同时在后 续迭代周期中逐步进行细化。 ( 6 ) 简单设计 极限编程认为代码的设计应该尽可能的简单， 只要满足当前功能的要求， 不多也 不少。 传统的软件开发过程， 对于设计是自 顶而下的， 强调设计先行， 在代码开始编写 之前， 要有一个完美的设计模型。 它的前提是需求不变化， 或者很少变化。 而极限编 程认为需求是会经常变化的， 因此设计不能一瞰而就， 而应该是一项持续进行的过程。 简单设计应该满足以 下几个原则: . 成功执行所有的测试 . 不包含重复的代码 . 向所有的开发人员清晰地描述编码以及其内 在关系 . 尽可能包含最少的类与方法 南京理工大学硕士学位论 文极限 编程在xx 供电公司物资计划管理信息系统开发中的应用 (7)测试驱动 极限编程强调 “ 侧试先行” 。在编码开始之前，首先将测试写好，而后再进行编 码，直至所有的测试都得以通过。 极限编程是一项测试驱动的软件开发过程， 它认为测试先行使得开发人员对自己 的 代码有足够的信心， 同时也有勇气进行代码重构。 测试应该实现一定的自 动化， 同 时能够清晰的给出测试成功或者失败的结果。 ( 8) 代码重构 极限编程强调代码重构在其中的作用， 认为开发人员应该经常进行重构， 通常有 两个关键点应该进行重构: 对于一个功能的实 现中 和实现后， 代码重构是指在不改变 系统行为的前提下， 重新调整、 优化系统的内 部结构，以 减少复杂性、 消除冗余、 增 加灵活性和提高性能。 重构不是极限编程所特有的行为， 在任何的开发过程中都可能 并且应该发生。 在使用代码重构的时候要注意， 不要过分的依赖重构， 甚至轻视设计， 否则，对于大中型的系统而言， 将设计推迟或者干脆不作设计，会造成严重的后果。 ( 9 )结对编程 极限编程认为在项目中采用结对编程比独自 编程更加有效。 结对编程是由两个开 发人员在同一台电脑上共同编写解决同一问题的代码， 通常一个人负责写编码， 而另 一个负责保证代码的正确性与可读性，而且二人将持续变换角色。 ( 1 0 )集体代码所有权 极限编程认为开发小组的每个成员都有更改代码的权利， 所有的人对于全部代码 负责。 代码全体拥有并不意味者开发人员可以互相推诱责任， 而是强调所有的人都要 负责。 如果一 个开发 人员的 代 码有错 误， 另外一 个开发 人员 也可以 进 行b u g 的 修复. 这一实践的前提是测试先行、编码标准等实践。 ( 1 1 )持续集成 极限编程提倡在一天中集成系统多次， 而且随着需求的改变， 要不断的进行回归 侧试。 因为 这样可以 使得团队 保持一个较高的开发 速度， 同时 避免了系统集成的 难度。 持续 集成不是 极限 编程 专 有的 最佳实 践， 微软公司 就有每日 集成 ( d a i 】 y b u i l d ) 的 成 功实践。 ( 1 2 )小型发布 极限编程强调在非常短的周期内以 递增的方式发布新版本， 从而可以很容易地估 计每个迭代周期的进度， 便于控制工作量和风险; 同时， 也可以及时处理用户的反馈。 小型发布突出体现了敏捷方法的 优点。 如果能够保证测试先行、 代码重构、 持续集成 等最佳实践，实现小型发布也不是一件困 难的事情。 南京理工大学硕士学位论文极限编程在xx供电公司物资计划管理信息系统开发中的应用 2. 2 软件开发中的一些问 题 2. 2. 1 软 件 开发 危 机 缺乏科学指导的软件开发活动表现为软件危机。 软件危机的典型表现为: . 软件不可维护，也不可重用 . 软件质量不能保证 . 缺乏文档，软件不可读，也不可交流 . 软件开发进度难以 估计， 效率难以 提高 为应对项目 失败率越来越高的情况， 软件工程于20世纪60年代应运而生。 表面 上看来，解决方案是采取某些措施，并进行严格控制。30 年后， 在软件开发中项目 失败和费用超支等问题仍然很突出. 软件失败的主要原因有: . 未能全面地确定项目 的目 标 . 不合理的规划和估计 . 技术不熟悉 . 缺乏项目 管理方法 . 项目 组中高级人员过少 . 软硬件供应商表现欠佳 如果缺乏高度灵活和可伸缩的开发策略， 项目 很容易失控。 极限编程通过拥抱变 化并将其视为一种常态， 从根本上解除了 这种风险。 支持动态开发的实践将缺陷消除 在萌芽状态。 z j .2软件项目中的控制变量 在软件项目中，可控制的变量有4 个:时间、 成本、质量和范围。表2 .2 2 . 1 列 出了这些变量以及控制这些变量所带来的副作用。 表2 念 2. 1 控制变量及其影响 变量影响 时间 时间太短显然会降低产品的质量， 因为没有足够的时间倾听客户、 编码和测试。 时间过长也可能得不到期望的结果。 开发小组的职责是尽快实现变化，以便客 户能够提供反馈。 成本 资金和资源有时候不可能完全避免 项目 出 现灾难。 如果追加资 源延 迟， 只会拖 延项目 的完成时间。客户应根据估算提供资金， 而不应期望盲目 追加投资来解 决问题。 质量降低质量可以 缩短开发时间， 但最终只能将测试工作推卸给最终用户去完成。 范围 软件开发的 标准流程是， 仅当在范围 上取得一致并签字确认后才开始工作。 在 这种模型中， 试图 控制需求和范围是不 现实的。 南京理工大学硕士学位