（计算机应用技术专业论文）基于fpa的软件工作量估算研究与实践.pdf

浙江大学硕士学位论文摘要 摘要 软件工作量估算对软件开发项目起着至关重要的作用，是项目计划和控制的 基础，是保证软件开发顺利完成的重要手段。随着机构公司对项目管理要求的不 断提高，软件工作量估算也越来越受到管理者的重视，并在项目管理中扮演着越 来越重要的角色。 论文详细阐述了软件工作量估算的基本理论，分析了影响工作量估算的因 素，并对现有的估算方法和模型进行了研究。通过分析目前业界使用估算方法和 模型的优缺点，并结合目前流行的规模度量方法p u g 功能点分析法，提出 了构建在机构项目基准数据之上的工作量估算方法。该方法通过基准数据构建规 模与工作量之间的关系，然后利用被估算项目的规模计算得到工作量值。同时， 为了克服项目早期需求不确定下规模计算的困难，采用了标准i f p u g 方法的一个 变种，并根据实际项目的特点对其进行了改进。在此之上，本文进一步提出了一 个工作量估算方法和统一软件开发过程相融合的全生命周期模型。模型包括四个 阶段：初始阶段的早期工作量估算、细化阶段的基线工作量构建、构造阶段的项 目状态跟踪和控制以及交付阶段的项目数据收集和分析。收集的数据将最终用于 改进工作量估算模型和过程。该模型实现了工作量估算方法与项目管理活动的交 互，克服了工作量估算方法和软件开发模型之间的冲突。 关键词： 功能点分析方法，工作量估算，软件开发全生命周期模型，项目管理 浙江大学硕士学位论文a b s t r a c t a b s t r a c t s o f t w a r ee f f o r te s t i m a t i o np l a y sas i g n i f i c a n tr o l ei ns o f t w a r ed e v e l o p m e n tp r o j e c t s i ti st h eb a s i so fp r o j e c tp l a n n i n ga n dc o n t r o la n de n s u r e st h es u c c e s so fp r o j e c t s w i t h t h ec o n t i n u o u si n c r e a s i n ge m p h a s i so np r o j e c tm a n a g e m e n t ，s o f t w a r ee f f o r te s t i m a t i o n g a i n sm o r er e c o g n i t i o nw i t hm a n a g e m e n ta n dp l a y sm o r ei m p o r t a n tr o l ei np r o j e c t m a n a g e m e n t t h i sp a p e re x p a t i a t e so nt h ee l e m e n t a r yt h e o r yo fs o f t w a r ee f f o r te s t i m a t i o n ，a n d a n a l y z e st h ef a c t o r st h a ta f f e c te s t i m a t i o na c c u r a c y t h r o u g hr e s e a r c h i n gt h ee x i s t i n g e s t i m a t i o nm e t h o d sa n dm o d e l sa n da n a l y z i n gt h e i ra d v a n t a g e sa n dd i s a d v a n t a g e s p a p e rp r o p o s e sas o f t w a r ee s t i m a t i o nm e t h o db a s e d o no r g a n i z a t i o n sh i s t o r i c a lp r o j e c t b e n c h r n a r k i n gd a t a ，w h i c hu s e si f p u gf p aa st h es i z em e a s u r e m e n tm e t h o d t h i s m e t h o df i r s tc o n s t r u c t st h er e l a t i o n s h i pb e t w e e ns i z ea n de f f o r tu s i n gh i s t o r i c a lp r o j e c t b e n c h m a r k i n gd a t a ，t h e ne f f o r to fp r o j e c tb e i n ge s t i m a t e dc a l lb ed e r i v e du s i n gi t ss i z e i na d d i t i o n ，t oo v e r c o m et h ed i f f i c u l t i e so fa p p l y i n gi f p u gf p ai ne a r l yl i f ec y c l e w h e nr e q u i r e m e n ti si n s u f f i c i e n t , e a r l y & q u i c kf p , av a r i a n to fi f p u gf p a ，i sa d o p t e d i ti sf u r t h e ra d a p t e dt oi m p r o v ei t sa c c u r a c yi ns i z i n g f u r t h e rm o r e ，t h ep a p e rp r o p o s e s as o f t w a r ed e v e l o p m e n tl i f e c y c l em o d e lw h i c hi n o s c u l a t e st h e e f f o r te s t i m a t i o n m e t h o da n dr a t i o n a lu n i f i e dp r o c e s s f o u rp h a s e s t a s k sa l ec a r r i e do u t ：e a r l y e s t i m a t i o ni ni n c e p t i o n ；e f f o r tb a s e l i n ec o n s t r u c t i o ni ne l a b o r a t i o n ；p r o j e c ts t a t u s t r a c k i n ga n d c o n t r o li nc o n s t r u c t i o n ；d a t ac o l l e c t i o na n da n a l y s i si nt r a n s i t i o n t h ed a t a c o l l e c t e dw i l lu p d a t et h ep r o j e c th i s t o r i c a lb e n c h m a r k i n gd a t aa n db eu s e dt oi m p r o v e e s t i m a t i o nm o d e la n dp r o c e s s t h i sm o d e lo v e r c o m e st h ec o n f l i c t sb e t w e e ne f f o r t e s t i m a t i o nm e t h o da n ds o f t w a r ed e v e l o p m e n tm o d e l ，a n da c h i e v e st h ee f f e c t i v e i n t e r a c t i o nb e t w e e ne f f o r te s t i m a t i o na n dp r o j e c tm a n a g e m e n t k e y w o r d s ：f u n c t i o np o i n ta n a l y s i s ，s o f t w a r ee f f o r te s t i m a t i o n ，s o f t w a r e d e v e l o p m e n tl i f ec y c l em o d e l ，p r o j e c tm a n a g e m e n t 浙江大学硕士学位论文图同录 图目录 图2 1 功能度量在软件工程和项目管理中的用处1 2 图2 2 功能点的益处1 2 图3 1 功能性规模度量方法发展历史【2 l 】_ 1 9 图3 2 基于i f p u gf p a 的系统分解2 0 图3 3 功能点计算流程图2 4 图4 1 一个典型的自动化测试项目架构3 4 图4 2 自动化测试项目生命周期3 5 图4 3 项目工作量估算框架3 6 图5 1 工作量估算的不确定性锥4 3 图5 2 基于f p a 的软件工作量估算全生命周期模型4 4 图5 3 标准估算流程4 5 图5 4 早期功能点估算模型：4 9 图5 5 早期功能点估算项目各聚合等级所占比例5 0 图5 6 基线建立模型一51 图5 7 数据分析过程一5 4 图5 8 工作量估算水平和需求变更水平一5 5 图5 9f p a 系统部署图5 6 图5 1 0f p a 系统用例图5 7 图5 1 1 项目基本信息界面5 8 图5 1 2 项目功能点结果统计界面5 8 图5 1 3 外部输入维护界面5 9 图5 1 4 功能跟踪界面6 0 图5 1 5 项目时间序列报告6 0 图6 1 成产率趋势图6 6 图6 2 比例因子结果6 9 图6 3 成本驱动因子结果7 0 图6 4c o c o m oi i 工作量估算结果7 0 图6 5s p r 估算结果7 1 图6 6 第一次迭代挣值分析数据7 3 图6 7 第二次迭代挣值分析数据7 4 i i i 浙江大学硕士学位论文表目录 表目录 表1 1 历年s t a n d i s hg r o u pr e s e a r c hc h a o s 报告2 表2 1c o c o m oi i 模型中的成本驱动因子一8 表2 2 代码行和功能点的优缺点比较13 表2 3 工作量估算方法的整体介绍和比较1 3 表3 1 内部逻辑文件和外部接口文件复杂度分级表2 l 表3 2 内部逻辑文件和外部接口文件的功能点值2 2 表3 3 外部输出复杂度分级表2 2 表3 4 外部输出和外部查询复杂度分级表一2 3 表3 5 内部逻辑文件和外部接口文件的功能点值2 3 表3 6 十四项通用系统特性及其描述2 4 表4 1 项目的通用系统特性值2 9 表4 2 早期快速功能点方法的基本功能组件3 2 表4 3 不同修改类型的可能情况3 3 表4 4 自动化测试项目外部输出复杂度分级表3 6 表4 5 项目分类列表4 0 表4 6 基于最小数据集的项目历史数据列表4 0 表6 1 项目a 基本特性6 l 表6 2 四个选取项目的最小数据集6 2 表6 3p 3 完成时软件产品的总功能点计数6 3 表6 4p 1 的未调整功能点计数一6 3 表6 5p 2 的未调整功能点计数一6 4 表6 6p 3 的未调整功能点计数6 5 表6 7 项目复杂度等级6 5 表6 8p 4 升级项目的功能点计数结果6 7 表6 9p 4 项目复杂度等级6 8 表6 10s p rk n o w l e d g e p l a n 估算输入域7 l 表6 1 1 四种估算方法估算结果比较7 2 表6 1 2 第一次迭代挣值分析数据7 3 表6 1 3 第二次迭代挣值分析数据7 4 i v 浙江大学研究生学位论文独创性声明 本人声明所呈交的学位论文是本人在导师指导下进行的研究工作及取得的 研究成果。除了文中特别加以标注和致谢的地方外，论文中不包含其他人已经发 表或撰写过的研究成果，也不包含为获得浙江大学或其他教育机构的学位或 证书而使用过的材料。与我一同工作的同志对本研究所做的任何贡献均已在论文 中作了明确的说明并表示谢意。 学位论文作者签名：刍咿绍 签字日期： ) ，? 。年月 日 学位论文版权使用授权书 本学位论文作者完全了解浙江大学有权保留并向国家有关部门或机构 送交本论文的复印件和磁盘，允许论文被查阅和借阅。本人授权浙j 江大学可 以将学位论文的全部或部分内容编入有关数据库进行检索和传播，可以采用影 印、缩印或扫描等复制手段保存、汇编学位论文。 ( 保密的学位论文在解密后适用本授权书) 学位论文作者签名： 、l 上 钞黔 签字日期：沙扣年弓月- t e l 导师签 签字日期：矽护年月7 日 浙江大学硕士学位论文 第1 章绪论 第1 章绪论 1 1 论文研究背景 随着软件产业不断的成熟与向前迈进，软件规模和复杂度也在不断的增加， 这给软件项目的管理带来的前所未有的挑战。混乱的项目管理不仅使软件项目无 法按期完成，更有甚者在花费了大量的时间和金钱后项目不得不被迫取消。因此， 如何进行有效的项目管理越来越受到软件企业的重视。计划和控制是确保项目顺 利有效执行的两个不可缺少的手段，它们也成为了项目管理中的重点。而软件开 发生命周期中规模、工作量、成本及进度等的估算则构成了项目计划和控制的基 础。层出不穷的软件估算技术，模型和工具正在被人们广泛的开发和利用，并在 项目管理中发挥着突出的作用。 以下几节将首先具体讲述软件工作量估算的背景。 1 1 1 软件项目开发的现状 软件工程是从2 0 世纪6 0 年代末迅速发展起来的。计算机的普及以及性能功 能的越发强大，各行各业对于软件应用的大量需求，促进了软件产业和软件工程 学科的飞速发展。“我们都快成为软件公司了。”越来越多的机构诸如财务、 交通、航空、电子和制造公司等等如是说。竞争的优势日益依赖于高质量、 高性能、可剪裁、智能的产品和服务软件的开发，以及比竞争对手更少的成本开 销、更快捷的上市速度和良好的反应快速的售后服务上。一个成功的软件项目必 须在软件成本、进度和质量上寻求一个平衡点在保证客户对产品的满意程度 的同时，节约软件开发成本和缩减软件发布时间。但是作为信息产业核心的软件 产业，有其自身的特点，如目标导向、开发周期长、需求不稳定、过程变化多等。 因此要在软件开发生命周期中做到平衡软件成本、进度和质量三者并非易事。 s t a n d i s hg r o u pr e s e a r c h 在1 9 9 4 的c h a o s 报告【i 】中指出有大概3 1 1 的项目 在它们能够完成之前被取消。报告更进一步指出有5 2 7 的项目在完成时会花费 浙江大学硕士学位论文第1 章绪论 超出预期估算8 9 的成本，只有1 6 2 的项目按时按期的完成。而由于软件项目 的失败、预算超支和超期完成所产生的额外可见成本也仅仅损失的是冰山一角。 更大量的是由于软件无法按期交付所带来的无法估量的成本损失。 从9 4 年到现在将近1 5 年过去了，但是人们似乎并没有从过去的经验中吸取 太多的教训。表1 1 列出了从1 9 9 4 年直到2 0 0 9 年s t a n d i s hg r o u pr e s e a r c h 的历年 软件项目c h a o s 报告。 表1 1 历年s t a n d i s hg r o u pr e s e a r c hc h a o s 报告 1 9 9 4 1 9 9 61 9 9 82 0 0 02 0 0 22 0 0 42 0 0 62 0 0 9 项目成功 1 6 2 7 2 6 2 8 3 4 2 9 3 5 3 2 项目超支 5 3 3 3 4 6 4 9 5 1 5 3 4 6 4 4 超时 项目取消 3 1 4 0 2 8 2 3 1 5 1 8 1 9 2 4 导致软件项目超支、超时或取消的原因有很多，而且通常都是由多个原因共 同作用的结果。下面列出了常见的导致项目无法成功完成的原因： 不充分的项目估算与度量 无法实现的软件目标和承诺，过度的进度压缩 不充分的项目计划、监视、跟踪与控制 大量的软件需求变更 除了以上列出的原因之外还有许多其他导致项目失败的原因。但是归结起 来，大致可以分为不切实际的目标、混乱的项目管理和不准确的项目估算三大类。 1 1 2 准确工作量估算的重要性 软件估算究其本质是对项目将持续多长时间或将花费多少成本也即工作量 多少的预测。工作量估算的结果则构成了项目计划的基础：详细进度表的建立、 项目关键路径的确立、交付功能优先级的确定以及项目的迭代分解等等都要依赖 于准确的估算。但是，软件工作量估算却往往会受到项目不切实际的目标、无法 实现的承诺以及混乱的管理影响，导致最终结果缺乏准确率。而不准确的工作量 估算通过影响项目计划等进而导致项目无法在预算内按时完成甚至被取消。f r e d 2 浙江大学硕士学位论文 第1 章绪论 b r o o k s 在2 0 世纪7 0 年代就已指出“时间不足导致的软件项目失败比所有其他原 因导致的项目失败加在一起还要多”【2 1 。2 0 世纪8 0 年代s c o t tc o s t e l l o 也指出“最 后期限的压力是软件工程最危险的敌人”【3 】o 进入到2 0 世纪9 0 年代之后，c a p e r s j o n e s 也在他的报告中表示“过度紧张的或不合理的进度表可能是对所有软件项目 最具破坏力的影响因素”f 4 】f 5 】。因此一个准确的软件工作量估算是进行合理项目计 划、推进项目前行并顺利完成的基石。 一个准确的估算结果的重要性体现在： 机构外包软件项目的决策支持：当一个公司想要决定是将软件项目外包给 外部公司开发还是自行开发时，估算提供了对“制造还是买”的决策支持。 提供软件产品或服务的竞价支持：当一个公司根据估算的结果向客户提供 对新项目的竞价时，估算的准确度将直接影响公司能否竞价成功和盈利。 提供对项目管理的支持：项目早期估算是项目依据类似项目的历史数据进 行资源分配的核心活动，也是更好的制定项目计划和进度、编制预算的基 础。在项目过程中帮助评估项目变更的影响以及支持项目的计划调整或重 排，同时准确的估算也有助于避免产生和进度压力相关的质量问题，使项 目管理和控制变得简单有效。另外，准确的估算还能提供项目的早期预警 功能估算结果与项目目标的不一致性是表明项目可能无法成功的高 价值风险信息。 1 1 3 工作量估算中的问题 影响软件工作量估算因素有很多，其中最重要的因素无疑是软件规模。软件 规模估算的准确度将直接影响到了软件工作量估算的准确度。在软件开发的整个 生命周期中，都经历着一个需求从模糊与匮乏渐渐变得详尽完备，代码从无到有 的过程。而目前业界使用的规模度量方法如代码行、功能点、对象点、用例点等 都或者依赖于代码或者依赖于需求来计算被开发软件的规模。因此在软件开发生 命周期的不同阶段的规模估算或度量所能达到的准确度是存在着巨大差异的。除 了上面所提到之外，软件开发生命周期中还蕴含着众多变化，如项目需求的变更 3 浙江大学硕士学位论文第1 章绪论 和追加、人员的流动、功能优先级的改变等。项目过程中的这些事件都会使最初 对项目进行的估算时所做的假设失效，并在软件工作量估算中引入巨大的不确定 性，同时也使得对最初项目估算的准确度的进行评估也因为最终交付的项目与估 算时项目的不同而变得不在可行。如何制定一个良好的估算方法和流程来解决形 如什么时候进行估算、估算的频度是多少，以及各个时间段的估算能达到什么样 的准确度等问题，并以此为基础来改善项目计划和控制，旅行有效项目管理成为 了每个项目都必须解决的课题。那么究竟什么是良好的估算呢? s d c o m e 。 h e d u n s m o r e 和v ys h e n 三位教授在1 9 8 6 年给出了一个他们关于良好的估算方 法的定义：在7 5 的时间内都能提供与实际结果相差不超过2 5 的估算结果【6 1 。 而这后来也成为了评价估算准确度的最常见标准i t 。 s t e v em c c o n n e l l 也在软 件估算“黑匣子”揭秘一书中指出“良好的估算是对项目实际情况有足够清晰看 法的估算，它让项目负责入可以做出控制项目达到目标的好的决策【8 1 。” 根据上面的定义，一个良好的估算应该包含一个估算的软件开发生命周期接 合模型和一个应用于模型中的估算方法。 估算的软件开发生命周期接合模型不仅要解决估算在软件开发生命周期中 的哪些阶段进行，如何追踪和控制项目的演迸和变化并对估算进行调整和修正， 还要解决估算模型与开发模型之间可能的冲突。目前在使用的类似于接合模型的 有基于f p a 的s o u t h e ms c o p e 模型【9 1 和n o r t h e r ns c o p e 模型【1 0 1 。其中，后者是对 前者的一个扩展。s o u t h e r ns c o p e 模型意在解决项目的定价方法和交付时的支付 方法：前者通过度量软件规模和确定每单位规模的价格来计算待开发项目的报 价：后者通过不断追踪项目开发进度并严格控制软件需求变更来保证项目在预算 内按时完成，最终的支付将依据软件交付时的规模和每单位成本。而工作量估算 以及后续的项目管理活动并不包含在这两个模型中。 对于估算方法，目前业界使用的有很多，如类比法、专家判断法、c o c o m o i i 、s l i m 等。但这些方法都有着它们的缺陷：类比法中要求的类似项目并不总是 存在；专家判断法则容易引入个人的主观和偏见，同时一定领域的专家也不容易 寻找；c o c o m oi i 和s l i m 都基于代码行进行估算，而项目早期往往没有代码行。 4 浙江大学硕士学位论文 第1 章绪论 虽然c o c o m oi i 采用了功能点以及逆火技术来应对早期估算的问题，但仍然需 要面对逆火技术本身存在的不准确性和偏差。诸如s l i m 的算法型模型还存在的 一个问题是建模的历史数据限制了它们的应用范围。例如。s l i m 因为建模于美国 政府和军方的大规模软件系统，使其在小规模系统的工作量估算上存在较大偏 差。因此，在估算方法的选择上需小心谨慎，本地化和适当的扩展往往不可避免。 1 2 论文研究内容及成果 软件估算的准确度如何将直接影响到项目时间进度的分配和安排。一个不合 理的时间进度的分配和安排很有可能导致项目的延期、预算超支或失败进而影响 到公司的利益。因此研究更适合于自己公司更有效的软件估算流程与方法将是未 来软件估算研究的一个方向。 本文详细研究了软件估算在项目管理中的作用与价值，研究了现有软件估算 包括规模估算和工作量估算在内的模型方法及工具，定义了一个软件工作量估算 模型和它与项目开发生命周期的结合模型并在具体的实际项目中应用了这一模 型。具体研究内容与所获得成果如下： ( 1 ) 对软件估算模型方法进行分析。研究了软件估算在项目管理中的价值 以及引起软件估算误差的因素；分析比较了几种软件规模估算方法以及一些软件 工作量估算方法并介绍了目前业界在使用的一些软件估算模型和工具。 ( 2 ) 对功能点分析方法的分析。研究了功能点分析方法的发展历史以及标准 i f p u g 功能点分析方法和一个为适应早期估算需求的标准i f p u g 功能点方法的 变种，并分析了它们的计算流程以及优缺点。 ( 3 ) 设计了基于f p a 的工作量估算方法，包括f p a 方法的改进、早期项目f p a 方法的采用和改进、本地项目历史数据库的建立及工作量估算公式的确定。 似) 设计定义了与统一软件开发过程模型一致的全生命周期模型，包括初始阶 段的工作量估算、细化阶段的基线工作量构建、构造阶段的项目跟踪和控制以及 交付阶段的项目数据收集和分析。该模型旨在克服软件开发模型和工作量估算方 法的冲突，实现两者的融合。 浙江大学硕士学位论文第l 章绪论 ( 5 ) 通过在选定的实际项目上应用设计的基于功能点分析方法的工作量估算 模型并比较收集到的项目实际数据和估算出的数据验证了本文提出的工作量估 算模型的有效性和可行性。 1 3 论文章节安排 本文章节安排如下： 第一章，绪论。本章内容方面介绍了整个论文写作的背景，另一方面阐述 了本论文的研究内容以及研究成果，并介绍了本文的组织结构。 第二章，软件工作量估算。本章对软件工作量估算进行了综述，即探讨了软 件工作量估算对于有效地进行项目管理的价值，同时也对现存的一些软件规模估 算和工作量估算方法作了介绍，并分析和比较了它们的原理和优缺点，最后本章 对目前软件行业在使用的一些软件估算工具作了概述。 第三章，功能点分析方法介绍。规模估算是软件工作量估算的最至关重要的 一环。本章对论文研究中采用的i f p u gf p a 方法作了整体的介绍。 第四章，基于f p a 的软件工作量估算。本章主要构筑了基于f p a 得软件工 作量估算方法，包括规模计算方法的应用和改进。基准数据的定义、收集和分类和 工作量估算公式的建立。 第五章基于f p a 的软件工作量估算全生命周期模型。本章定义了基于f p a 的软件工作量估算在统一软件开发过程模型的应用，主要内容包括初始阶段的工 作量估算、细化阶段的基线工作量构建、构造阶段的项目跟踪和控制以及交付阶 段的项目数据收集和分析。 第六章，应用案例。本章详细描述了根据在第四、五两章提出的软件工作量 估算流程和模型在本人实习公司选定项目所做的实践工作，内容包括项目的选 定，项目历史数据的收集，规模和工作量的估算。并通过上述工作来验证第四 章提出方法的可行性和有效性。 第七章，总结与展望。对全文进行了总结。并讨论了需要进一步解决的问题 和未来将要完成的工作。 6 浙江大学硕士学位论文第2 章软件工作最估算 第2 章软件工作量估算 2 1 软件工作量估算概述 工作量作为一个度量，描述了完成一个项目所需要的人的工作的量。它可以 帮助确定项目所需要的人员数，也可以帮助建立项目的进度表，是软件项目管理 中最重要的度量之一。工作量估算正是对这一度量进行估算的过程，以满足项目 管理在无法得到实际工作量时对项目工作量数据的需求，是项目管理进行计划和 控制的基石。 软件工作量估算的最早研究工作可以追溯到2 0 世纪6 0 年代f a r r 【】和 n e l s o n 【1 2 】所做的工作。软件工作量估算的大部分研究都集中在了正规估算模型的 构建上，如类比估算法、算法型估算法、自底向上估算法等。而这其中，算法型 估算方法是诸多估算模型研究中的重点。在算法型估算方法中，通过对历史数据 的收集和分析建立了工作量和众多影响因子之间的基于数学公式的关系模型。 c o c o m oi i 和s l i m 是目前软件行业应用最广泛的两种算法型估算模型。 每一种工作量估算方法都有其适用的范围和环境( 特别是基于历史数据建模 的算法型估算方法) ，其所能达到的准确度也不尽相同。如何在数量纷繁众多的 估算方法中选择和扩展出适合自己的估算方法是工作量估算迈向成功的第一步。 接下来的章节中会就影响估算的因素以及现在流行的一些主要估算方法作一个 整体的介绍。 2 2 影响工作量估算的因素 能够对软件开发项目产生影响的因素有很多，如软件项目规模、项目人员、 编程语言、构建项目的环境等等。下面将按重要性顺序介绍一些影响项目工作量 估算的因素并讨论在估算中可能的误差来源。 7 浙江大学硕士学位论文第2 章软件工作量估算 2 2 1 影响工作量估算的因素 对工作量估算最具决定性的影响因素毫无疑问是待构建的软件项目的规模。 但是很多机构的做法确是在不知道软件规模的情况下对工作量进行估算；面对需 求蔓延也没有采取有效的措施来调整工作量的初始估算值。这些做法都会导致项 目超时超支，甚至取消。值的注意的是工作量与规模并非线性的关系，当规模增 长时，工作量往往以更快的速度攀升，即规模不经济性。导致这一现象的主要原 因在于规模增长时沟通成本的指数级增长。 待开发软件类型是影响工作量估算的第二大因素。例如，一个金融公司统计 的数据中，m i s 类型的系统的生产率达到了1 0 1 3 个功能点每人月，而其实时系 统的生产率却只有3 - - , 4 个功能点每人月。两者的差距达到了2 5 4 3 倍。如果扩 展到整个软件行业，这一差距甚至会超过l o 倍。因此，在基于历史数据的工作 量估算方法中，历史数据的选择会极大的影响估算的结果。如何选择符合自身的 历史数据进行估算是提高估算准确度的关键点之一。 其他的影响工作量估算的因素还有很多，如人员、编程语言、工具、产品等 等。表2 1 列出了c o c o m oi i 模型中定义的1 7 个成本驱动因子。它可以帮助我 们理解不同因素对工作量估算的不同影响。 表2 1c o c o m oi i 模型中的成本驱动因子 因素影响度因素影响度 应用经验 1 5 1 软件工具的使用 1 5 0 可复用开发 1 3 1 要求的开发进度 1 4 3 数据库规模 1 4 2 产品复杂度 2 3 8 要求提供文档 1 5 2 程序员能力( 总体) 1 7 6 语言和工具的经验 1 4 3 需求的软件可靠性 1 5 4 多场所开发1 5 6 需求分析帅的能力 2 o o ，人员持续性1 5 9 存储限制 1 4 6 平台经验 1 4 0 时间限制 1 6 3 平台易变性 1 4 9 浙江大学硕士学位论文第2 章软件工作垦估算 2 2 2 工作量估算的误差来源 工作量估算值的误差主要来源有以下几个方面： 不准确的项目信息。正如项目开发是一个细化渐进的过程，能够用来建立 估算的信息如规模等诸多影响因素在开发过程中同样经历了从模糊到详 尽、从缺失到完备的过程：不准确的信息导致了项目估算的不确定性，根 据信息的详尽和完备程度，估算结果从初始概念时4 倍的误差到详细设 计完成时1 2 5 倍的误差，再到软件完成时趋近于真实值，大致上形成了 一个锥形。确保锥形的快速收敛需要采取一系列的决策来消除不准确信息 带来的可变性，如产品定义、详细需求开发、界面设计等等。 混乱的项目管理和开发过程。如不良的需求定义开发、低效的跟踪监控、 混乱的设计和编码等等。这些都会给估算带来不确定性。不同于前一个误 差来源是项目本身固有的，无法避免，混乱的项目管理和开发过程却是可 以控制避免的。建立良好的开发过程和项目控制机制是消除这一误差的有 效办法。 不稳定的需求。很多项目开发都经历着同一个问题：需求蔓延( 不停的需 求变更和增加) 。需求蔓延往往会导致项目规模的增长以及大量的重复工 作。初始的估算以及相应的计划也就失去了效应，项目就会进入混乱的状 态。应对需求蔓延的一种策略是在估算值中留出一定的空间；另一种策略 则是加强需求控制和管理，并实行有效的跟踪控制以及及时的估算调整。 其它的误差来源。除了以上的误差来源，其他的误差来源还包括估算过程 中遗漏的开发活动，估算人员的乐观主义、估算人员的主观性和偏见等等。 削减或消除这些误差来源带来的不确定性都需要一个客观一致的估算流 程以及适合环境的估算方法。 2 3 规模估算方法 软件规模是影响软件工作量的最重要因素，但也是最难确定的因素，特别是 在项目早期需求的软件规模估算。为了解决或者简化软件规模度量或估算上的难 9 浙江大学硕士学位论文第2 章软件工作量估算 题，很多方法被开发了出来，如代码行、功能点、对象点、用例点以及它们的众 多的变种。这里我们将主要介绍目前软件行业中最常用的两种规模度量方法：代 码行和功能点。 2 3 1 代码行 代码行是一种通过计算软件代码行数来度量软件规模的方法。它的历史可以 追溯到1 9 7 4 年，当时w l o v e r t o n 尝试着使用代码行来度量程序员的生产率。虽然 代码行是对软件规模进行科学度量的最早尝试方法之一，确饱受批评：但另一方 面，直到目前为止它仍在软件业中被广泛采用。 在人们刚开始使用代码行的时候，当时最常用的编程语言还是诸如 f o r t r a n 和a s s e m b l e r 等的行导向语言，而穿孔卡片则是主要的数据输入形式。 这些离散对象不仅易于统计，也能够很好地衡量程序员的产出。这使得将代码行 作为度量程序员生产率的方法被项目经理所接受。但是今天，大部分常用的编程 语言都容许了更宽泛的格式化，正文行也不在限制在8 0 或者9 6 个字符内，同时 一行正文行也在必需对应于一行代码了。另外，不同语言中对可执行语句和数据 声明的概念性差异都使得对代码行的定义变得困难。 代码行在这些差异中也渐渐分裂成两种不同的度量：物理代码行和逻辑代码 行。物理代码行是对包括注释在内的文本行数的统计，而逻辑代码则是对“语句” 的统计。两种代码行度量方法即使是对同一段程序进行计数也会产生巨大的差 异。针对这种情况，软件工程协会( s o f t w a r ee n g i n e e r i n gi n s t i t u t e ，s e d 在r o b e r t e p a r k 等的带领下开发了一个逻辑代码语句定义核对表来定义代码行的度量并于 1 9 9 2 年公布。在c o c o m 0i i 模型中采用了s e i 的这一定义来度量或估算被计算 软件的规模。 代码行度量方法的优缺点明显。它的优点包括： 自动化的计算：虽然代码行的定义纷繁多样，但是一旦建立一套统一的定 义，便能够很容易的使用工具来收集项目的代码行数据。 直观的度量：代码行是对项目经理或客户来说都是客观直白的，也是众多 1 0 浙江大学硕士学位论文第2 章软件工作量估算 商用估算工具所采用的规模度量方法。 它的缺点则包含： 缺乏可衡量性：代码行统计的仅仅是编码阶段的产出，而编码一般只占整 个软件生命周期的所有工作量的3 0 到3 5 ，因此用它来度量软件规模， 并估算全生命周期的工作量不是非常适用。 无法在项目早期进行代码行计算：在项目早期如计划需求等阶段需要进行 工作量估算时，代码往往还没有被实现，而对代码的强行估算则会导致估 算结果的不准确。 缺乏可比较性：因为不同的编程语言、编码风格、和代码行定义等都会导 致代码行度量结果的较大差异，使得不同项目间的比较不具备一致性和可 行性。 多语言困难：现代项目的复杂性往往涉及到多种语言的共同应用，这对用 代码行进行工作量估算等带来很大的困难。 2 3 2 功能点 功能点方法对软件规模的度量并不基于像代码行这样的软件“内部”属性，而 是基于用户所描述的外部功能视角或业务视角，一种更接近于产生软件合同的机 制，它度量的是软件的功能规模。功能规模在i s o i e c1 4 1 4 3 1 ：2 0 0 7 中被定义为： 一个通过量化功能性用户需求得到的软件规模。一个功能点是一个描述被提供给 用户的业务功能的量的度量单元。 本文将采用功能点方法是i f p u gf p a 方法，它在1 9 7 9 年由m m 的 a j a l b r e c h t 首先提出【1 3 】，并在1 9 8 6 开始由i f p u g 组织维护，是目前业界最广泛 采用的功能点方法【1 4 1 。作为一种和i s o i e c 定义一致的功能规模度量方法，i f p u g f p a 度量了那些用户要求的并被实现发布的系统功能。这里用户并不严格的指一 个人或最终用户，而是指任何需要和被度量系统交互的人、物、外围系统、硬件 或软件。 功能点方法是对程序规模的综合度量，图2 1 展示了度量的功能点在软件工 浙江大学硕士学位论文第2 章软件工作星估算 程过程和项目管理中的用处。图2 2 则展示了功能点方法的价值。 图2 1 功能度量在软件工程和项目管理中的用处 实现早期工作墨估篝 图2 2 功能点的益处 同时，功能点也存在不足：首先是无法自动化计算，功能点的计算需要理解并分 解需求，目前的技术还不足以达到自动化计算的水平；其次，功能点计算具有主 观性，这主要来源于功能点计算者对功能点计算规则的理解上。表2 2 列出了功 能点和代码行优缺点的一个比较。对于功能点计算的主观性，些研究表明在熟 悉了解功能点计算规则的前提下，不同计算人员的差异可控制在5 以内 1 5 1 。 1 2 浙江大学硕士学位论文 第2 章软件工作量估算 表2 2 代码行和功能点的优缺点比较 比较项代码行功能点 评注 简单 、， 代码行可自动化计算，工作量少 客观 功能点计算规则理解具有主观性 代码不相关 可以在代码没产生就开始计算 语言不相关 、， 剔除了语言对规模计算的影响 面向用户 x 功能点度量的是功能规模，用户可理解 2 4 工作量估算方法 软件行业存在着大量的不同的软件估算模型，同时也存在着大量不同的分类 方法。一些软件模型适用于多个不同的分类，这也使得给这些软件模型指定一个 具体的分类变得很困难。b o e h m 【16 】识别了七种模型类别：类比、专家判断、 p a r k i n s o n l l 7 】、价格制胜、自顶向下、自低向上、算法( 参数) 。我们将着重介绍 其中常用的四种方法：类比、专家判断、自低向上和算法。前三种又可以统归为 非算法型。表2 3 对四种方法做了一个概要介绍和比较。 表2 3 工作量估算方法的整体介绍和比较 估算方法方法描述优点 缺点 类比比较新项目和旧项目，估算是基于实际数据和 项目问总是存在的差异， 并根据项目历史数据确历史经验的使得调整在所难免；类似 定工作量估算值项目缺失时不可用 专家判断 咨询或者和一到多个专 基本不需要历史数据的 在估算中引入了专家的偏 家合作判断工作量估算支持，对唯一的或新项见，而且专家知识也经常 值目很有用有疑问和不可靠 自低向上 累加一定粒度的单个组详细的估算基础可以减在项目早期详细数据一般 件的估算值来得到总的少估算漏洞和改进工作都会缺失，无法提供早期 工作量估算值 量规划的估算 算法型 通过算法模型和项目特估算模型可以根据历史估算人员对参数的偏见会 性来计算出工作量估算数据调整以适应不同的极大地影响估算的结果； 值开发环境和产品特性；估算带有一定的主观性 浙江大学硕士学位论文第2 章软件工作量估算 2 4 1 非算法型估算方法 类比估算：类比估算基于种简单的认知，认为可通过把新项目和过去类似 项目做比较对新项目进行准确的估算。一个简单的类比过程一般包括：获取以前 相似项目的详细数据如规模、工作量等；比较新项目和以前相似项目的规模并根 据两者的比例估算新项目的规模；根据新项目对旧项目规模的情况计算工作量估 算值并检查项目中的假设是否一致来确保估算的有效性。该方法的优点在于它是 基于经验的。同时，这也是它的弱点，因为类似项目在大多数情况下都不存在。 专家判断模型：这一模型中，专家依据他们的知识、经验、以及对项目的理 解来给出工作量估算值。在历史数据不存在的情况下，这一方法是非常有价值的。 但是专家判断法往往会受到专家的经验以及主观性所限制，如个人偏见( 倾向于 乐观的估算) 或对目前项目的不熟悉等。d e l p h i 和w i d e b a n d 方法被用来减弱上 面提到的限制。这一方法步骤一般包括： ( 1 ) d e l p h i 协调人为每个估算专家提供一份说明和估算单。 ( 2 ) 协调人召开小组会议，就当前项目有关估算的问题进行讨论。 ( 3 ) 估算专家匿名提交单独得到的估算值。 ( 4 ) 协调人在一张迭代表单上总结所有专家得到的估算结果并召开小组会议 讨论估算值中的差异。 (