加入VIP
  • 专属下载特权
  • 现金文档折扣购买
  • VIP免费专区
  • 千万文档免费下载

上传资料

关闭

关闭

关闭

封号提示

内容

首页 软件估算技术

软件估算技术.pdf

软件估算技术

李老师-麦克
2010-02-22 0人阅读 举报 0 0 暂无简介

简介:本文档为《软件估算技术pdf》,可适用于IT/计算机领域

软件估算技术Software Estimation TechniquesJohn Liao  PMP向进度落后的项目增加人手只会使进度更加落后。‐‐‐摘自《人月神话》Adding manpower to a late software project makes it later   ‐‐‐from The Mythical Man Month  前言Agendaƒ概述ƒ软件项目规模的估算方法(Size)ƒ开发工作量估算方法(Effort)ƒCase Studyƒ测试工作量估算方法ƒCase Studyƒ补充说明ƒ建议ƒQA什么是软件估算?(一)ƒ根据软件的开发内容、开发工具、开发人员等因素对需求调研、程序设计、编码、测试等整个开发过程所花费的时间及工作量做的预测。ƒ“预测”两个字非常关键它突出体现了估算的含义同时也隐含表明了结果的不确定性。有效的软件开发周期估算在软件开发中是非常困难的工序之一之所以说困难是因为软件开发所涉及的因素不仅多而且异常复杂即便是及其类似的软件项目也不能完全照搬在估算的把握上有一定难度。¾开发语言(AssembleLanguage,C,C,Java,C#,VB,PLSQL,…)¾开发工具(VC,JBuilder,Eclipse…)¾开发流程(PSP,XP,RUP,…)¾系统架构(CS,WS)¾开发人员的经验¾业务复杂程度¾组件复用程度¾项目特征(产品型研发型维护型…)……什么是软件估算(二)ƒ软件估算已成为软件工程经济学(Software Engineering Economics) 的重要组成部分ƒ估算错误已被列入软件项目失败的四大原因之一范围质量成本时间估算不足工作量增大加班士气低落身心疲惫效率低下不能按时完成任务估算过多成本增加软件估算的内容一个良好的软件项目计划的建立必须估算准备开发的软件项目的任务大小、资源情况、投入的成本、限制因素等进行充分的估算最后根据估算才能制定出合理的项目开发计划。具体来说要估算的内容包括:¾软件工作产品的规模估算¾软件项目的工作量估算¾软件项目的成本估算¾软件项目的进度估算¾项目所需要的人员、计算机等资源估算国内外软件估算比较(一)ƒ国内软件开发的管理目前正逐步向规范化发展但是在开发周期的估算上绝大部分还是处于手工作坊的状态。所谓的手工作坊指两个方面:一方面是管理人员意识上没有认识到估算的重要性认为估算就是一个大概的估计很多还受限于商业行为比如为了签订合同而不惜压缩开发工作量另一方面也没有专门的工具来辅助估算或者说没有专门对它进行研究。一个软件开发周期究竟要多长基本上是依靠经验来判断不同经验的人估算出的周期相差很大而更糟糕的是这种开发周期的判断由于完全凭借经验使得不同意见的人之间很难沟通因为谁都没有确切的量化标准来支持自己的判断最终的结果往往是以“专家”的估算为准。实际上国内的软件开发需要的正是定量估算这样做不仅规范而且精确十分有助于软件事业的健康发展以及与国际接轨。国内外软件估算比较(二)ƒ国外发达国家在软件估算上比国内要成熟的多不仅有很多方法比如代码行估算法、功能点估算法、人力估算法而且形成了专业化的估算工具来辅助这项工作。比如微软公司开发的项目管理工具软件Project加拿大Software Productivity Center Inc公司开发的Estimate都是比较成熟的估算辅助工具。Project采用了自下而上(bottom‐up)的估算法Estimate更是属于专业化工具包含常用的各种估算方法、校正方法使用了Putnam Methodology、CocomoII和Monte Carlo Simulation几种成熟算法估算结果除了项目花费时间、人力还包括十几种分析报告以及模拟发散图、计划编制选项图、人力图、预计缺陷图、缺陷方差图等等从各种不同角度辅助管理人员进行分析。国内外软件估算比较(三)ƒ采用辅助工具对软件开发周期进行估算具有明显的优势这些辅助工具是在大量不同类型项目数据研究的基础上总结开发出来的采用的算法、估算的方法已经很成熟估算结果的准确性有保障由于这种估算是可以量化的并非依据个人经验直接得出一个结果在结果的评审上有据可依。长期依靠工具辅助估算可以将大量项目的数据和估算结果积累形成历史经验库知识成果得以保存便于以后利用。软件项目规模的估算方法概述代码行法类比法Delphi法自顶向下法自底向上法功能点法参数化模型法Putnam法用例点法对象点法软件项目规模的估算方法(一):代码行法代码行法(LineofCode)代码行LOC(LineofCode)指所有的可执行的源代码行数包括可交付的工作控制语言(JCL:JobControlLanguage)语句、数据定义、数据类型声明、等价声明、输入输出格式声明等。(注意:注释及机器自动生成的代码不能包括在代码行计算中)单位编码行(LOC)的价值和人月均编码行数可以体现一个软件生产组织的生产能力。组织可以根据对历史项目的审计来核算组织的单行编码价值。例子:某软件公司统计发现该公司每一万行Java语言源代码形成的源文件约为K。某项目的源文件大小为M则可估计该项目源编码大约为万行该项目累计投入工作量为人月每人月费用为元(包括人均工资、福利、办公费用公摊等)则该项目中单位LOC的价值为:(×)=元LOC该项目的人月均编码行数为:=LOC人月优点:直观可以作为衡量工作量的一个指标缺点:在项目前期往往得不到精确的数据一般要与其他方法结合使用软件项目规模的估算方法(二):类比法类比法(Analogy Approach)适合评估一些与历史项目在应用领域、环境和复杂度的相似的项目通过新项目与历史项目的比较得到规模估计。类比法估计结果的精确度取决于历史项目数据的完整性和准确度。因此用好类比法的前提条件之一是组织建立起较好的项目后评价与分析机制对历史项目的数据分析是可信赖的。采用这个方法的前提是:a 对以前项目规模和工作量的计量是正确的b 至少有一个以前的项目的规模和新项目类似c 新项目的开发周期、使用的开发方法、开发工具与以前项目的类似而且开发人员的技能和经验也不能与原来的人员相差太大。类比法的基本步骤是:、整理出项目功能列表和实现每个功能的编码行数、标识出每个功能列表与历史项目的相同点和不同点特别要注意历史项目做得不够的地方(吃一堑涨一智避免犯同样的错误)、通过步骤和得出各个功能的估计值、产生规模估计。优点:估计较为准确缺点:要依赖于实际经验必须要有类似的项目可供参考软件项目规模的估算方法(二):类比法(Cont’d)ƒ类比法注意事项:采用类比法往往还要解决可重用代码的估算问题。估计可重用代码量的最好办法就是由程序员或系统分析员详细地考查已存在的代码估算出新项目可重用的代码中需重新设计的代码百分比、需重新编码或修改的代码百分比以及需重新测试的代码百分比。根据这三个百分比可用下面的计算公式计算等价新代码行:等价代码行= (重新设计 重新编码 重新测试)×已有代码行比如:有行代码假定需要重新设计需要重新编码需要重新测试那么其等价的代码行可以计算为:(    )×,= , 等价代码行。即:重用这代码相当于编写代码行的工作量。软件项目规模的估算方法(三):Delphi法Delphi法(ExpertJudgment)是一种专家评估技术在没有历史数据的情况下这种方式适用于评定过去与将来新技术与特定程序之间的差别但专家“专”的程度及对项目的理解程度是工作中的难点但是这种方式对决定其它模型的输入时特别有用。Delphi法的步骤是:、协调人向各专家提供项目规格和估计表格、协调人召集小组会各专家讨论与规模相关的因素、各专家匿名填写迭代表格、协调人整理出一个估计总结以迭代表的形式返回专家、协调人召集小组会讨论较大的估计差异、专家复查估计总结并在迭代表上提交另一个匿名估计、重复直到达到一个最低和最高估计的一致。优点:不需要历史数据非常适合新的较为特别的项目估算缺点:主观专家的判断有时并不准确专家自身的技术水平不够时会带来误判软件项目规模的估算方法(四):自顶向下法自顶向下估算法(TopDown)该方法首先对整个系统进行总工作量估算再考虑子系统把总工作量逐步分解为各组成部分的工作量并考虑到开发该软件所需要的资源、人员、质量保证、系统集成安装等的工作量。优点:估算的工作量小速度快。缺点:对项目中的特殊困难估计不足估算出来的工作量盲目性大有时会遗漏被开发软件的某些部分。例如:接到一个周期为六个月的项目项目经理可能做如下估算:一个月:需求分析一个月:设计两个月:编码两个月:测试再根据这个估算对每个阶段进一步估算和规划。软件项目规模的估算方法(五):自底向上法自底向上法(Bottom‐Up)该方法是按组件划分先对每个组件的工作量估算然后总计得到整个项目的规模和工作量。优点:估算各个部分的准确性高能提高参与人的责任心缺点:缺少各项子任务之间相互联系所需要的工作量还缺少许多与软件开发有关的系统级工作量(配置管理、质量管理、项目管理)。所以往往估算值偏低必须用其它方法进行检验和校正软件项目规模的估算方法(六):功能点法功能点分析法(FunctionPointsAnalysisFPA)(后面详细讨论)是在需求分析阶段基于系统功能的一种规模估计方法。步骤:该方法通过研究初始应用需求来确定外部输入、外部输出、外部查询、内部逻辑文件和外部接口文件的数量。将这些数据进行加权乘。下表为一个典型的权值表。功能类型权值外部输入外部输出外部查询内部逻辑文件外部接口文件估计者根据对复杂度的判断总数可以用、、或调整。对一个软件产品的开发功能点对项目早期的规模估计很有帮助。功能点可以转换为软件规模测量更常用的LOC。优点:基于UseCase能保持与需求变化的同步缺点:加权调整需要依赖个人经验软件项目规模的估算方法(七):参数化模型法参数化模型法(Parametric Models)通常基于程序的设计特征来估计系统的总成本。总成本可以被分解到底层的软件单元或生命周期的阶段上。参数模型的优点是易于快速掌握不需要详细信息(校准后)。此外参数估计技术在恰当的校准后可以获得与其他估算技术一样的精度基于这些优点参数化模型常作为美国国防部(DoD)软件估算技术的一个选择。其中结构化成本估算方法(Constructive Cost Model II) COCOMO II是一个典型代表(后面详细讨论)。优点:客观结果是可重复的缺点:如果没有采用适当的校准结果往往不准确用于校准的历史数据可能与被估算的项目关系不大造成估算不准软件项目规模的估算方法(八):Putnam方法ƒ一种动态多变量模型。它是假定在软件开发的整个生命周期中工作量有特定的分布。这种模型是依据在一些大型项目中收集到的工作量分布情况而推导出来的但也可以应用在一些较小的软件项目中。Putnam模型可以导出一个“软件方程”把已交付的源代码(源语句)行数与工作量和开发时间联系起来。其中Td是开发持续时间(以年计)K是软件开发与维护在内的整个生存期所花费的工作量(以人年计)L是源代码行数(以LOC计)Ck是技术状态常数它反映出“妨碍开发进展的限制”并因开发环境而异。Ck典型值的选取如下表所示。dkTKCL⋅⋅=Ck的典型值开发过程开发过程举例差没有系统的开发方法缺乏文档和复审批处理方式好有系统的开发方法有文档和复审交互执行方式优有自动开发工具和技术软件项目规模的估算方法(九):用例点法(Use Case Points)ƒ用例点法(Use Case Points)Objectory(后改名为Rational)的Gustav Karner于年提出在对Use Case 的分析基础之上进行加权调整得出。其步骤如下(后面详细讨论): 对每个用例角色分别赋值加权乘积求和 计算未调整用例点(Unadjusted Use Case Points UUCP)  考虑环境因子和技术因子对UUCP调整以得到调整用例点(Adjusted Use Case Points AUCP)  再根据AUCP和规模‐工作量转换因子得到工作量优点:比较适用于面向对象的软件项目经过调整可用于估算测试工作量缺点:加权调整需要经验软件项目规模的估算方法(十):对象点法ƒ对象点法(Object Points)Banker在 提出主要用于CASE工具辅助开发的项目。ƒ预测性对象点法(Predictive Object Points POPs)由PRICE Systems开发专为面向对象软件设计的通过系统计算面向对象的特征进行度量。每类加权方法(Weighted Methods per Class  WMC)顶层类数(Number of Top Level Classes TLC )子类数(Number of Children NOC)继承树深度(Depth in Inheritance Tree DIT)功能点法FPA (Function Points Analysis)年IBM的工程师Allan Albrecht 首先提出FPA方法年IBM正式向外界公开该方法年国际功能点用户组(International Function Points User Group简称IFPUG)正式成立现已成为世界最大的软件测量研究非盈利性组织详情见:wwwifpugorg目前功能点法已成为具有广泛影响的软件测量方法。功能点是基于应用软件的外部、内部特性以及软件性能的一种间接的软件规模的测量。功能点与软件成本具有明显的成本估计关系(CER:Cost Estimating Relationship)。功能点可以作为经验统计参数化软件成本估计公式和模型的输入以对软件的成本进行估计。功能点方法被广泛的认可在信息系统、数据库密集型、GL应用系统开发的规模测量。由三个逻辑部分组成:未调整的功能点计数、加权因子和功能点。ƒ未调整的功能计数包括对外部输入、外部输出、外部查询、内部逻辑文件和外部接口文件的计数。ƒ加权因子的确定包括划定系统、输入和输出、应用复杂度的级别。ƒ功能点的最终确定包括将未调整的功能点和加权因子整合在一起。功能点法FPA (Function Points Analysis) (Cont’d)ƒ基本概念系统外部输入(EI)外部输出(EO)外部查询(EQ)内部逻辑文件(ILF)外部接口文件(EIF)功能点法FPA (Function Points Analysis) (Cont’d)基本概念ƒ外部输入(External Input):数据由外向内跨越边界的基本处理过程。数据可能来自于数据输入屏幕、电子输入或其它应用程序。数据可以是控制信息或业务信息。如果数据是业务信息它用于维护一个或多个内部逻辑文件。如果数据是控制信息它不必更新内部逻辑文件。ƒ外部输出(External Output):导出的数据由内向外跨越边界的基本处理过程。数据创建发送给其它应用的报表或输出文件。这些报表和文件由一个或多个内部逻辑文件和外部接口文件所创建。ƒ外部查询(External Enquiry):包括输入和输出构件的基本处理过程。输入和输出构件导致一个或多个内部逻辑文件和外部接口文件的数据检索。该信息被发送出应用程序边界。输入过程不会更新任何内部逻辑文件以及输出不包含导出的数据。ƒ内部逻辑文件(Internal Logic File):完全驻留在应用程序内部的逻辑相关数据的用户可识别的组通过外部输入所维护。ƒ外部接口文件(External Interface File):仅用于引用目的的逻辑相关数据的用户可识别的组。数据完全驻留在应用程序外部由其它应用程序所维护。外部接口文件是其它应用程序的内部逻辑文件。功能点(FP)模型(ƒ确定个修正因子的取值ƒFP应用过程确定边界FP(EI,EO,EQ)=f(数据元素逻辑文件)BackfireCOCOMOFP(EIF,ILF)=f(数据元素结构元素)VAF=f(数据,应用,性能等复杂度)SRS+×其他方法比较功能点法FPA (Function Points Analysis) (Cont’d)第一步:确定未调整功能点:决定未调整功能点的数目包括:确定外部输入确定外部输出确定外部查询确定内部逻辑文件确定外部接口文件确定未调整功能点总数功能点法FPA (Function Points Analysis) (Cont’d)确定外部输入:外部输入是数据由外向内跨越边界的基本处理过程。数据可能来自于数据输入屏幕、电子输入或其它应用程序。数据可以是控制信息或业务信息。如果数据是业务信息它用于维护一个或多个内部逻辑文件。如果数据是控制信息它不必更新内部逻辑文件。对于低、平均或高将数目分别乘以、或。确定外部输出:外部输出是导出的数据由内向外跨越边界的基本处理过程。数据创建发送给其它应用的报表或输出文件。这些报表和文件由一个或多个内部逻辑文件和外部接口文件所创建。对于低、平均或高将数目分别乘以、或。确定外部查询:外部查询是包括输入和输出构件的基本处理过程。输入和输出构件导致一个或多个内部逻辑文件和外部接口文件的数据检索。该信息被发送出应用程序边界。输入过程不会更新任何内部逻辑文件以及输出不包含导出的数据。对于低、平均或高将数目分别乘以、或。功能点法FPA (Function Points Analysis) (Cont’d)确定内部逻辑文件:内部逻辑文件是完全驻留在应用程序内部的逻辑相关数据的用户可识别的组通过外部输入所维护。对于低、平均或高将数目分别乘以、或。确定外部接口文件:外部接口文件是仅用于引用目的的逻辑相关数据的用户可识别的组。数据完全驻留在应用程序外部由其它应用程序所维护。外部接口文件是其它应用程序的内部逻辑文件。对于低、平均或高将数目分别乘以、或。确定未调整功能点总数:将带有权重的外部输入、外部输出、外部查询、内部逻辑文件和外部接口文件总和在一起。其结果即为未调整功能点。功能点法FPA (Function Points Analysis) (Cont’d)第二步:确定加权因子:决定加权因子包括划分以下的级别:系统复杂度输入和输出复杂度应用复杂度加权因子的值=系统复杂度+输入和输出复杂度+应用软件复杂度采用~的分值来确定以上三个复杂度分别代表无影响(no influence)=偶尔(incidental)=适度(moderate)=平均(average)=重大(significant)=根本(essential)=功能点法FPA (Function Points Analysis) (Cont’d)划分系统复杂度级别:划分数据通讯复杂度的级别划分分布式处理复杂度的级别划分性能复杂度的级别划分配置项负载复杂度的级别划分输入和输出复杂度的级别划分事务率复杂度划分在线数据项复杂度划分在线更新复杂度划分用户使用效率复杂度划分应用软件复杂度的级别划分复杂处理复杂度划分重用性复杂度划分安装容易程度复杂度划分操作容易程度复杂度划分多个地点复杂度划分修改容易程度复杂度功能点法FPA (Function Points Analysis) (Cont’d)划分数据通讯复杂度的级别:ƒ具有多少数据通讯设备?ƒ数据通讯描述了应用软件与处理器直接通讯的程度。应用软件使用的数据和控制信息在数据设备上发送和接收。局部直接与控制单元连接的终端被认为会使用通讯设备。协议是一系列规约它允许在两个系统和设备之间传输或交换信息。所有的数据通讯链接需要某种协议。ƒ以下是记分的指南:¾应用软件是单纯的批处理或独立的PC。¾应用软件是批处理但具有远程的数据入口或者远程打印。¾应用软件是批处理但具有远程的数据入口和远程打印。¾应用软件包括在线连接至批处理或查询系统的数据搜集或TP(远程处理)终端。¾应用软件不仅仅是终端并且支持一种通讯协议。¾应用软件不仅仅是终端并且支持多种通讯协议。ƒ远程处理现在非常普遍。仅仅的项目是“低于平均”的分值或以下则具有“高于平均”的分值或。ƒ对银行项目和个人PC开发的项目该分值较低。从至它具有持续降低的趋势从高于平均水平降至平均水平。功能点法FPA (Function Points Analysis) (Cont’d)划分分布式处理复杂度的级别:ƒ分布式数据和功能如何被处理?ƒ分布式数据处理描述了应用软件在各个组成部分之间数据传送的程度。分布式数据或功能处理是应用软件边界内部的一种特性。ƒ以下是记分的指南:¾应用软件无系统组件之间的数据传输或功能处理。¾应用软件为系统其它组件上的最终用户处理如PC电子表格或PC DBMS准备数据。¾数据为传输做出准备接着被传输以及在其它系统组件上被处理(并非最终用户处理)。¾单方向的在线的分布式处理和数据传输。¾双向的在线的分布式处理和数据传输。¾功能处理动态的在相应的系统组件上执行。ƒ在所有的常见系统特征中该值取“低于平均值”具有非常大的比例。其统计分布是双峰值的:系统要么是单机或者分布式处理是作为系统一种比较重要的特性。ƒ在工程系统中往往具有更多的分布式处理。分布式处理在中范围的平台上较其它平台上更为普遍。分布式处理在交易生产系统和办公信息系统中较管理信息系统和决策支持系统更为普遍。新的开发项目较改进项目中更重要一些。功能点法FPA (Function Points Analysis) (Cont’d)划分性能复杂度的级别:ƒ用户对响应时间或吞吐量是否有所要求?ƒ性能描述了对响应时间和吞吐量性能方面考虑对应用软件开发的影响程度。用户以响应或吞吐量所陈述或认可的性能目标影响着(或将影响)设计、开发、安装以及支持。ƒ以下是记分的指南:¾用户没有特殊的性能需求。¾性能和设计需求被陈述和评审但不需要特殊的活动。¾响应时间或吞吐量在峰值时间是关键的。对CPU利用没有特殊的设计。处理的极限在日后考虑。¾响应时间或吞吐量在所有的工作时间是关键的。对CPU利用没有特殊的设计。与其它交互系统处理极限方面的需求是强制的。¾迫切的用户性能需求要求在设计阶段进行性能分析方面的工作。ƒ该特征具有较分散的分布:的项目低于平均值的项目处于平均水平的项目高于均值。ƒ性能对于交易生产系统较管理系统更为重要。新的开发项目较改进项目中更重要一些。功能点法FPA (Function Points Analysis) (Cont’d)划分配置项负载复杂度的级别:ƒ对当前的硬件平台的使用程度?ƒ配置项的使用程度描述了计算机资源对应用软件开发的影响程度。需要特殊设计考虑的满负荷运行的操作配置是应用软件的一个特征。例如用户想在现有的或指定的满载设备上使用应用软件。ƒ以下是记分的指南:¾没有明显的或隐式的操作限制。¾存在操作约束但限制较典型的应用较小。限制不需要特殊的工作。¾存在某些安全性或时序的考虑。¾特殊应用软件部分存在特殊的对处理器的需求。¾所要求的操作限制对中心处理器或主要处理器上的应用软件需要特殊的限制。¾另外在系统的分布式组件上存在特殊的限制。ƒ本特性的分值普遍较低:低于均值处于平均水平高于均值。ƒ交易生产系统和办公信息系统的分值较管理信息系统和决策支持系统低。新的开发项目较改进项目中低中等项目较其它平台高工程系统较高。从GL项目至GL项目分值会增高。功能点法FPA (Function Points Analysis) (Cont’d)划分事务率复杂度:ƒ事务执行的频繁程度?ƒ事务率描述了业务交易(事务)影响应用软件开发的程度。如果事物率高它会影响设计、开发、安装和支持。ƒ以下是记分的指南:¾预计没有峰值的事务处理周期。¾预计存在峰值的事务处理周期(如:月、季、年)。¾预计每周存在峰值的事务处理。¾预计每日存在峰值的事务处理。¾用户需求中要求高的事务率或者服务级别的约定足够的高要求在设计阶段进行性能分析。¾用户需求中要求高的事务率或者服务级别的约定足够的高要求在设计阶段进行性能分析。另外需要在设计、开发和或安装阶段使用性能分析工具。ƒ事务率的分值在分布在~的范围内分情况较少。ƒ事务率在银行系统中较一般情况重要性高在工程系统中则较低。在大型机其它平台重要性高。尽管可能期望对于事务生产系统而言重要程度高一些但在应用类型之间没有重大的差别。从年至年该分值有着稳定的提高。功能点法FPA (Function Points Analysis) (Cont’d)划分在线数据项复杂度:ƒ百分之多少的信息是在线输入的?ƒ在线数据项描述了数据通过交互式事务输入的程度。应用软件提供在线数据项和控制功能。ƒ以下是记分的指南:¾所有的事务以批处理的形式处理。¾至的事务是交互式数据项。¾至的事务是交互式数据项。¾至的事务是交互式数据项。¾至的事务是交互式数据项。¾超过的事务是交互式数据项。ƒ直到现在该特性在所有的调整因子中是最高的并且变化是最少的。的项目对该特性的取值为分最大的可能值。ƒ根据IFPUG指南分意味着超过的事务包括交互式数据项。对于现在而言作为阀值可能过低较高的取值可能能够提供更有用的区别。ƒ对于单个机构COBOL主机银行项目该分值较低(通常分)。而分的取值近乎适用于其它一切情况。功能点法FPA (Function Points Analysis) (Cont’d)划分用户使用效率复杂度:ƒ应用软件是否就最终用户使用效率上有所设计?ƒ最终用户使用效率描述了对人为因素和应用软件用户的易用性的考虑程度。此功能强调了最终用户使用效率的设计(如漫游帮助、菜单、在线帮助和文档、自动游标移动、滚动条、在线事务的远程打印以及预定义功能键)。ƒ以下是记分的指南:¾无¾上文中的或项。¾上文中的或项。¾上文中的项以上但无特定相关于使用效率的用户需求。¾上文中的项以上用户使用效率的需求要求就人的因素安排设计任务(例如最少击键次数、最大化默认值、模板的使用)。¾上文中的项以上用户使用效率的需求要求使用特殊的工具以展示达到即定的目标。ƒ该特性具有广泛的分布有些高分值的趋势:低于均值高于平均值。ƒ用户使用效率对于信息管理系统较事务生产系统重要。对于新开发项目该分值较增强项目低并具有较扁平的分布。同样的从GL项目至GL项目分值会增高。功能点法FPA (Function Points Analysis) (Cont’d)划分在线更新复杂度:ƒ多少内部逻辑文件会被在线的事务更新?ƒ在线更新描述了内部逻辑文件在线更新的程度。应用软件为内部逻辑文件提供在线更新。ƒ以下是记分的指南:¾无¾在线更新至个控制文件。更新量较少恢复容易。¾在线更新个或个以上的控制文件。更新量较少恢复容易。¾在线更新大量的控制文件。¾另外遗失数据的保护是关键的并在系统中进行特定的设计和编码实现。¾另外大数据量带来了恢复过程中的成本考虑。需要最少人为干涉的高度自动化的恢复步骤。ƒ在线更新的分值倾向高(半数高于均值)但大多数在~分较少。ƒ事务生产系统的分值较高。个人PC平台比其它平台低。同样的从GL项目至GL项目分值会增高。功能点法FPA (Function Points Analysis) (Cont’d)划分复杂处理复杂度:ƒ应用软件是否具有大量的逻辑或数学处理?ƒ复杂度处理描述了处理逻辑对应用软件开发的影响程度。以下是一些处理情况:灵敏度控制、特殊的监控处理、安全性处理、逻辑处理、数学运算、异常处理、复杂度处理以及设备无关性。ƒ以下是记分的指南:¾无灵敏度控制、逻辑处理、数学运算、异常处理或复杂度处理。¾包括灵敏度控制、逻辑处理、数学运算、异常处理或复杂度处理中的任何一种。¾包括灵敏度控制、逻辑处理、数学运算、异常处理或复杂度处理中的任何两种¾包括灵敏度控制、逻辑处理、数学运算、异常处理或复杂度处理中的任何三种¾包括灵敏度控制、逻辑处理、数学运算、异常处理或复杂度处理中的任何四种¾包括所有的灵敏度控制、逻辑处理、数学运算、异常处理或复杂度处理。ƒ该特性具有正态分布主要分布在均值和的分值较少。ƒ复杂处理的分值在大型机上是最高的而微机上是最低的在GL项目中最高GL项目中最低。该分值在新的项目中较增强型的项目高并具有较扁平的分布。处理复杂度从年~年稳定的增高。功能点法FPA (Function Points Analysis) (Cont’d)划分重用性复杂度:ƒ应用软件开发以满足一个或是多个用户的需要?ƒ重用性描述了应用软件和软件中的代码特定的被设计、开发和支持以在其它软件中重用的程度。ƒ以下是记分的指南:¾无重用代码。¾可重用代码在应用软件中重用。¾以下的应用软件考虑多个用户的需要。¾以上的应用软件考虑多个用户的需要。¾应用软件特定的被打包和或文档化以易于重用应用软件被用户在源代码级别客户化。¾应用软件特定的被打包和或文档化以易于重用应用软件通过用户参数维护的方式被客户化使用。ƒ重用性的重要性通常较低项目低于均值仅有高于平均值但它处于非常混合的状态。ƒ决策支持系统中重用性考虑比其它类型多一些而个人PC上的重用性的考虑较大型机少。功能点法FPA (Function Points Analysis) (Cont’d)划分安装容易程度复杂度:ƒ转换和安装的困难程度多大?ƒ安装的容易程度描述了环境的变化对应用软件开发的影响程度。转换和安装的容易程度是应用软件的特性之一。转换和安装计划和或转换工具在系统测试阶段被提供和测试。ƒ以下是记分的指南:¾用户未提出特殊的要求安装不需要特殊的设置。¾用户未提出特殊的要求但安装需要特殊的设置。¾用户提出转换和安装的要求转换和安装指南被提供和测试。项目中转换的因素不被认为是重要的因素。¾用户提出转换和安装的要求转换和安装指南被提供和测试。项目中转换的因素被认为是重要的因素。¾在的基础上自动转换和安装工具被提供和测试。¾在的基础上自动转换和安装工具被提供和测试。ƒ该特性具有最广泛的分布性总的来说分值较低(低于均值高于均值)但是两种极端的情况均有体现。安装的容易程度在的项目中不被考虑而在的项目中非常重要。ƒ增强型项目的分值比新开发的项目高大型机比其它平台高工程系统比其它业务领域高。功能点法FPA (Function Points Analysis) (Cont’d)划分操作容易程度复杂度:ƒ应用软件在启动、备份和恢复的有效性自动化程度?ƒ操作的容易特征描述了应用软件在操作方面(如启动、备份和恢复过程)的考虑程度。操作的容易程度是应用软件的特性之一。应用软件最小化人工活动如磁盘的mount、文件处理和直接的现场人工干涉。ƒ以下是记分的指南:¾除了平常的备份过程用户没有要求特殊操作上的考虑。¾任意一种人工启动、备份和恢复自动启动、备份和恢复磁盘mount的最小化或文档(paper)处理最小化。¾任意两种人工启动、备份和恢复自动启动、备份和恢复磁盘mount的最小化或文档(paper)处理最小化。¾任意三种人工启动、备份和恢复自动启动、备份和恢复磁盘mount的最小化或文档(paper)处理最小化。¾任意四种人工启动、备份和恢复自动启动、备份和恢复磁盘mount的最小化或文档(paper)处理最小化。¾应用程序设计为无人操作。无人操作意味除了启动和关闭系统系统不需要操作员的干涉。自动错误恢复是应用软件的特色。ƒ操作容易程度是不怎么考虑的问题。该特性的分值近乎最低:低于均值仅有高于平均值。分值分布在~是最普遍的情况。ƒ当项目根据应用类型分组时出现的唯一重大的差异:信息管理系统和决策支持系统的分值较交易生产系统和办公信息系统高。功能点法FPA (Function Points Analysis) (Cont’d)划分多个地点复杂度:ƒ应用软件是否设计支持多个地点场所机构?ƒ多个场所描述了应用软件被开发以适于多个地点和用户机构的程度。应用软件特定的被设计、开发、支持以工不同的组织机构在不同地点安装。ƒ以下是记分的指南:¾用户需求不需要考虑多个用户安装地点的需要。¾设计中考虑了多个场所的需要应用软件设计在相同的软硬件环境中操作。¾设计中考虑了多个场所的需要应用软件设计在相似的软硬件环境中操作。¾设计中考虑了多个场所的需要应用软件设计在不同的软硬件环境中操作。¾文档和支持计划被提供和测试以支持应用软件在不同地点的使用应用软件如或所述。¾文档和支持计划被提供和测试以支持应用软件在不同地点的使用应用软件如所述。ƒ该特性在所有的因素中具有最低的取值:低于均值具有最小的可能值。ƒ分值对于法律系统非常低而对于工程系统较高。新开发的系统比增强或重新开发的系统高GL项目比其它的高中型机比大型机高。同样管理系统和决策系统的分值较交易生产系统和办公系统高。功能点法FPA (Function Points Analysis) (Cont’d)划分修改容易程度复杂度:ƒ应用软件是否被设计以方便于修改?ƒ修改方便描述了应用软件被开发以利于处理逻辑或数据结构修改的程度。下列特性适用于应用软件:处理请求的灵活的查询和报表(如简单、平均和复杂)和使用每日或隔日更新的表保存业务控制数据。ƒ以下是记分的指南:¾无¾任何一种简单、平均或复杂的查询和报表或者即时的或隔日的业务控制数据维护。¾任何两种简单、平均或复杂的查询和报表或者即时的或隔日的业务控制数据维护。¾任何三种简单、平均或复杂的查询和报表或者即时的或隔日的业务控制数据维护。¾任何四种简单、平均或复杂的查询和报表或者即时的或隔日的业务控制数据维护。¾所有五种简单、平均或复杂的查询和报表或者即时的或隔日的业务控制数据维护。ƒ该特性的每个分值均有较好的体现但普遍较低:低于均值高于平均值。分布是双峰值的两个通常的取值是和。ƒ对于GL项目取值较低GL项目较高。新开发的项目低大型机低工程项目高。并不令人奇怪该特性对信息管理系统和决策支持系统较重要而交易生产系统的重要性较低。功能点法FPA (Function Points Analysis) (Cont’d)第三步:确定功能点决定复杂度因子:复杂度因子=加权因子×+决定功能点:将未调整功能点和复杂度因子相乘得到功能点。软件规模向工作量的转换(Conversion from Size to Efforts)工作量估算ƒ估算出软件规模并且对软件的开发周期进行定义后开始估算软件项目的工作量。软件规模的估算结果是代码量但是软件项目的开发、实施过程并不是只有编码的工作编写文档、架构设计、系统设计、测试以及实施发布等将占用大量的工作时间。因此对软件项目工作量的估算就是确定、估算这样一个代码量的项目所需的各种工作相加得到项目的工作量。ƒ目前的估算方法都是通过对大量不同类型组织已完成项目进行研究得出的项目规模与工作量之间的关系和转换方法。这些行业性的模型可能不如自己的历史数据精确但是非常有效。目前还没有一种估算模型能够适用于所有的软件类型和开发环境。在实际应用中从这些模型得到的结果必须根据项目的实际情况慎重使用或者采用多个模型进行估算、掌握工作量的基本范围并与实际的工作量计划比较。ƒ步骤: 功能点转换为代码行 代码行转换为工作量功能点转换为代码行(FP to LOC)ƒSPR方法编程语言代码行功能点CCVisual BasicJavaVCPLSQL                                                ƒ例如:功能点为则所需的Java代码行为,行代码行转换为工作量(LOC to Efforts)ƒIBM模型IBM的Walston和Felix提出了如下的估算公式:E =×LL是源代码行数(以KLOC计)E是工作量(以人月计)S =×ES是人员需要量(以人计)D =×LD是项目持续时间(以月计)例如:使用Java完成一个某个项目(功能点)时将大约需要下列LOC数:L = × = 行=  KLOC工作量E =×L =×× =人‐月项目需要的人员S=×E =××=人项目持续时间D=×L =××=月功能点转换为工作量功能点数每功能点小时数可能的Use Case数‐ or ‐‐,‐‐,‐‐,‐‐经验数据表(from wwwSoftwareMetricscom)COCOM II 方法(Constructive Cost Estimation II)ƒ年由Dr Barry Boehm 创立COCOM方法称为COCOM 。ƒ年Barry经过改进创建COCOM II方法适用于采用面向对象方法的软件项目。详细研究成果见http:sunsetusceduresearchcocomosuiteindexhtmlƒ开发型项目工作量估计ƒ维护型项目工作量估计COCOM II 方法(Cont’d)ƒ开发型项目工作量估计PM:开发所需的人月A:系数缺省值为要根据项目实际情况调整Size = S (  REVL) 其中S为新增的工作量用KLOC表示REVL为需求变化的百分比E =    (SF)    E是指数变量其中SF为个值为‐的调整因子的总和如下表所示ƒEM是如下表所示的个值的乘积ƒPMAT是自动生成的组件的工作量ATEPMEMSizeAPM=**COCOM II 方法(Cont’d)COCOMO II 方法(Cont’d)ƒ维护型项目工作量估计ƒPMm维护型项目工作量(人月)ƒA是系数缺省值为要根据项目实际情况调整ƒSize= (新增代码量 修改代码量) * MAF其中MAF =   UNFM * SU, UNFM为开发人员对软件不熟悉的程度SU为学习(包括理解业务和熟悉开发工具)所付出的工作量ƒE和EM同开发型项目工作量EMSizeAPMEm**=测试工作量估算测试工作量的估算要考虑的因素如下:    测试队伍的工作效率。对于功能测试这主要依赖于应用的复杂度窗口的个数每个窗口中的动作数目。对容量测试主要依赖于建立测试所需数据的工作量大小。  为了完成一个Test Case需要的测试动作数目。  应用的维数:应用的复杂度指标。例如要加入一个记录测试需求的维数就是这个记录中字段的数目。  所处测试周期的阶段:有些阶段主要工作都在设计有些阶段主要是测试执行。 经验公式(用来衡量Test Coverage )估计的Test Case 数= 功能点数Acceptance Test Case数=  * 功能点数如果实际Test Case数少于估计的Test Case数则存在缺陷被漏检的可能测试工作量估算(Cont’d)ƒ使用用例点法(Use Case Points)ƒ首先对角色(Actor)进行加权计算出未调整的角色权值(Unadjusted Actor Weights UAW)ActorTypeDescriptionWeightingFactorSimpleGUIAverageInteractiveorProtocoldriveninterfaceComplexAPILowLevelInteractions测试工作量估算(Cont’d)ƒ 再计算出未调整的用例加权权值(Unadjusted Use Case Weights UUCW)这里Transaction指的是Use Case中的一个步骤UseCaseTypeNoofTransactionsWeightingFactorSimple<=AveragetoComplex>=ƒ 计算出未调整用例点UUCPUUCP = UAW  UUCW测试工作量估算(Cont’d)ƒ 计算技术及环境因子(Technical and Environmental Factor TEF)FactorDescriptionWeightingFactorTTestToolsTDocumentedInputTIntegrationTestEnvironmentTSystemTestEnvironmentTTestwareReuseTDistributedSystemTPerformanceObjectivesTSecurityFeaturesTComplexInterfacingƒ计算调整的用例点(Adjusted Use Case Points AUCP)AUCP = UUCP * (  *TEF)ƒ根据规模工时转换因子计算工作量(man‐hours)如Effort = AUCP *  总结本讲座首先介绍了软件估算的概念及重要性并对国内外的软件估算水平作了比较。在对十种常用的软件估算方法作了简要介绍后重点介绍了功能点法和用例点法并分别作了软件开发工作量和测试工作量估算的案例研究。随后介绍了自己使用这些方法的经验以及需要注意的事项。QAAny questionsThank you!软件估算技术�SoftwareEstimationTechniques��JohnLiaoPMPAgenda什么是软件估算?(一)什么是软件估算

用户评价(0)

关闭

新课改视野下建构高中语文教学实验成果报告(32KB)

抱歉,积分不足下载失败,请稍后再试!

提示

试读已结束,如需要继续阅读或者下载,敬请购买!

文档小程序码

使用微信“扫一扫”扫码寻找文档

1

打开微信

2

扫描小程序码

3

发布寻找信息

4

等待寻找结果

我知道了
评分:

/12

软件估算技术

仅供在线阅读

VIP

在线
客服

免费
邮箱

爱问共享资料服务号

扫描关注领取更多福利