下载
加入VIP
  • 专属下载券
  • 上传内容扩展
  • 资料优先审核
  • 免费资料无限下载

上传资料

关闭

关闭

关闭

封号提示

内容

首页 软件估算—“黑匣子”揭秘

软件估算—“黑匣子”揭秘.pdf

软件估算—“黑匣子”揭秘

真狮王
2011-09-14 0人阅读 举报 0 0 0 暂无简介

简介:本文档为《软件估算—“黑匣子”揭秘pdf》,可适用于IT/计算机领域

软件估算SoftwareEstimation软件估算SoftwareEstimation“黑匣子”揭秘DemystifyingtheBlackArt简介•本书荣获SoftwareDevelopmentMagazine生产力大奖两届SoftwareDevelopmentMagazine软件开发书籍震撼大奖得主!简介()•作者在书中揭开了围绕在软件估算周围的层层迷雾。他在深入浅出地介绍了与软件估算有关的主要概念之后深入、全面地介绍了与软件估算有关的多种估算方法。简介()主要内容•估算与计划和项目控制以及估算与目标和承诺之间的关系•不确定性锥与估算中的误差来源以及影响估算的各种因素•估算基本原则先计数、再计算无法可想时才依靠判断•用于估算软件项目的三个重要部分规模、工作量和进度估算的基本方法简介()主要内容•与规模、工作量和进度估算有关的特殊问题•估算的概率论观点以及如何采用适当的方式来表达估算结果中的不确定性•如何进行与估算有关的沟通从而使技术人员和非技术人员达成共识。关于作者•SteveMcConnell是著名的软件开发书籍作家他又是ConstruxSoftware公司的首席软件工程师负责监督该公司的软件工程实践。软件估算SoftwareEstimation关于作者()•他是软件工程知识体(SoftwareEngineeringBodyofKnowledge)项目的构造知识领域(ConstructionKnowledgeArea)的负责人。•他还是SPCEstimateProfessional的开发负责人该产品获得了软件开发生产力大奖(SoftwareDevelopmentProductivityAward)。关于作者()•他著名著作有:《代码大全第版》(CodeComplete,SecondEdition)等。•他的著作曾两次获得过SoftwareDevelopment杂志的年度卓越软件开发书籍震撼大奖(JoltProductExcellenceAward)。关于作者()•年SoftwareDevelopment杂志的读者们把他选为软件行业最有影响力的三个人之一另外两人分别是BillGates(微软公司的创办人)和LinusTorvalds(Linux的作者)。中文版引言•对于软件项目管理流传着一个经典的“六拍”黑色幽默如图右所示。拍脑袋拍肩膀拍胸脯拍桌子拍大腿拍屁股中文版引言问题所在?•是从业人员敬业精神不高?•是项目经理们不思进取?•是项目过程监控管理不足?•是项目经理经验技能不足?•是各种所需资源投入不足?中文版引言最核心问题•就出在“拍脑袋”上在软件项目管理中缺乏有效的估算方法与过程一直以来是业界的心头之痛!软件估算SoftwareEstimation中文版引言软件估算“黑匣子”•那又是什么原因导致这个大家都意识到的问题长期以来却处于“无解”的状态呢?•幸运的是SteveMcConnell在本书中解开这个软件估算“黑匣子”背后的秘密。中文版引言管理人员•对“财务预算表”不陌生尽管它从来不准确但它却总能为管理提供一个范围。•对于软件项目而言也有其相同的道理。•合理预期是使软件估算结果落在管理上下限之间。若项目执行情况都能够落在该区域那就意味着是可控的而反之就意味着是失控的。中文版引言管理人员(续)•阅读本书你就能够更深入地理解特定于软件估算所遇到的困难更好地理解诸如软件开发人员产能不稳定、不同软件项目存在很大差异等特殊因素以便为项目团队的估算提供更好的行政支持。中文版引言项目经理•首先要理解在项目初期估算的结果是一个靶子而不是马上给出一个靶心也就是说得到的结果应该是“需要~个人月最可能的值是个人月”而不是精确的个人月。中文版引言项目经理(续)•此外还需要建立以下几个关键的理念:–总估算值是不能谈判只对单个估算项进行修改–估算不是玄学–经验数据是提升估算准确率的关键–分解是复杂性的克星–估算的问题不仅困扰你一个中文版引言开发团队成员•嗨别走开这里同样欢迎您!估算并非是“经理”人的特权。•每项开发活动都需要您对其进行估算。若你的估算结果偏离太远那么整个项目估算就是在浮沙之上筑高台。软件估算SoftwareEstimation中文版引言开发团队成员(续)•积累反映自己产能的经验数据以便正确地对完成任务所需时间进行估算从而对团队做出现实的承诺才能够使自己真正远离“无休止”加班的困扰毕竟加班要解决的就是那些不应该设置的最后期限是对不负责任的进度承诺的惩罚!中文版引言开发团队成员(续)•学会记录自己的时间掌握基本的估算方法这些是使自己成长为具有专业素养的开发人员所必备的过程。而从本书中你可以获得你想要的东西。写作目的、面向读者•有关软件估算的文献非常分散数量多。普通从业人员没有时间查找、阅读。•普通从业人员是指那些把估算当作多项工作之一的开发、测试、项目管理和组织管理人员用此书不是为了获得软件估算方面的博士学位而是要提高其自身的估算准确度。适用范围•书中方法基本上适用于所用类型的软件:–因特网和内联网开发–嵌入式、业务系统软件开发–新产品、传代的系统开发–大、中、小型项目(不含超大项目)。重要的估算认识•―估算”的含义。•导出过去准确度不精确的特定因素。•区分估算方法的优劣。•提供建立良好的估算方法。•帮助团队中其他人建立良好的估算方法。•为开发组织建立良好的估算方法。•方法可用于敏捷、传统项目。•适用于大、中、小型项。•如何穿越软件估算周围的危险政策“深潭”。特定属性估算•新开发工作的进度、工作量和成本。•传代系统工作的进度表、工作量和成本。•在特定的开发项目内可以提供多少特性。•在进度和团队规模限制下整个项目可交付多少功能。•所有不同开发活动所占的比例:–管理、需求、构造、测试等比例。软件估算SoftwareEstimation特定属性估算(续)•计划参数数量、开发人员和测试人员比例。–计划参数:成本和进度之间的折衷、团队最佳规模、应急缓冲人物•质量参数以及其他参数。–质量参数:Debug时间、发布时仍存在Bug数•任何其它像估算的内容。全书内容•第一部分估算的关键概念•第二部分基本估算方法•第三部分特定的估算挑战•附录估算合理性检查表第一部分估算的关键概念•―估算”的含义•你的估算水平如何•准确估算的价值•估算误差来源•影响估算的因素―估算”的含义•估算(estimate)–就是对项目将持续多长时间或将花费多少成本的预测。•目标(target)–描述期望达到的业务目的。•承诺(commitment)–许诺在特定日期之前以特定质量水平交付规定的功能。―估算”的含义()•软件项目中估算、业务目标、承诺和控制之间存在着相互影响。提示#:区分估算、目标、承诺。―估算”的含义()•估算和计划的关系–它们是两个相关的话题–估算≠计划–估算:客观的(unbiased)分析过程–计划:主观的(biased)目标求解过程–估算的目的是得到准确的结果不寻求特定的结果–计划的目的是寻求特定的结果软件估算SoftwareEstimation―估算”的含义()–估算的结果构成了计划的基础–计划并不一定要与估算结果相同。–估算结果与目标存在差距进行项目计划时则可能存在较高的风险–估算结果接近于目标进行项目计划时则可认为风险较低。–估算和计划都重要。–两者之间的根本差异意味着如果不对它们加以区分就很可能导致估算和计划都不准确。―估算”的含义()–在计划中要考虑的下面问题在一定程度上依赖估算的准确:•建立详细进度表•确定项目的关键路径•建立完整的工作分解结构•确定要交付的功能的优先级•将项目按多次迭代进行分解―估算”的含义()•估算、目标和承诺的沟通–估算和计划密切相关–但两者的关系也非常令人困惑。–项目相关人(stakeholder)的沟通有时会不恰当的。–沟通的例子(page)–技术负责人就要负责把主管提出的要求翻译成更为明确的技术术语。―估算”的含义()提示#:当有人要求提供估算值时要确定他是期望进行估算还是期望给出如何达到某个目标的计划。―估算”的含义()•以概率的方式表示估算结果–软件估算的核心问题之一:“如果软件项目按时完成可能性不是那么会是多少?”–以单点数值表示估算结果因为没有指出与该点相关联的概率这是没有意义。提示#:看到单点“估算结果”时就要问清楚该数字是估算值还是事实上的目标。―估算”的含义()–要进行准确的软件估算就要认识到软件项目受到各种不确定性的影响。–各种不确定因素共同决定了项目的结果遵循概率分布。提示#:看到单点估算值的时候应该认识到该数值的概率不是。要问清楚该数值的概率。软件估算SoftwareEstimation―估算”的含义()•―良好”估算的常见定义–估算准确度最高可以达到±。CapersJones–应该在的时间内都能提供与实际结果相差不超过的估算结果。Conte,Dunsmore,andShen–后者是评价估算准确度的最常见的标准。Stutzke―估算”的含义()–两种定义都遗漏一个重要概念:•仅仅通过估算实践本身并不能获得准确的估算结果还需要通过有效的项目控制来提供支持。―估算”的含义()•估算与项目控制–在讨论估算时会把它当作纯粹的预测活动。–软件估算中所有事都受其他事情影响。–控制活动:舍去非关键的需求、重新定义等。–由于无法对估算的预测能力进行评估评价“良好”的估算的标准就不能基于它的预测能力而是要基于估算为项目成功提供支持的能力。―估算”的含义()•估算的真正目的–软件项目面临对业务目标与进度、成本两难的局面。–软件估算的首要目标并不是预测项目的结果而是确定项目目标是否足够现实从而让项目在可控的状态下达成这些目标。–估算无需非常准确而是要有用。―估算”的含义()•―良好估算”的初步定义–是对项目实际情况有足够清晰看法的估算它让项目负责人可以做出控制项目达到目标的好的决策你的估算水平如何•简单的估算测验–对下页每个问题给出一个范围边界让它所含正确值的可能性达到–范围设定的不要太窄或太宽–不确定、没有回答视为答案不正确–测验完成的时间为分钟–答案正确则得分。软件估算SoftwareEstimation问题估算值太阳表面温度上海的纬度亚洲大陆的面积亚历山大大帝出生的年份年美国货币总流通量北美五大湖的总水量泰坦尼克号全球票房总收入太平洋海岸线的总长度年以来美国出版书目数量有过记载最重蓝鲸的重量C北纬度km公元前年亿美元km亿美元km万册kg你的估算水平如何()•关于测验结果的讨论–“置信度”的置信度•以的置信度进行估算•题就应大约答对题•谨慎取值较宽:会对题?•草率取值较窄:会对~题?你的估算水平如何()正确答案数受测人比例你的估算水平如何()–平均答对题目数是:个–答对题以上的受测人数:–置信度≈置信度提示#:除非有定量推算的方法否则不要提供“百分率的置信度”形式的估算值(尤其是置信度)你的估算水平如何()•估算的范围应该取多宽?–答对~题人数很少(罕见)–这个人被问及“怎么答对的”回答是“取值太宽”–书作者认为:不并不是太宽。而是不够宽–因为仅答对~题还没有答对应答对的数量你的估算水平如何()–习惯认为用较窄范围表示的估算值比用较宽范围表示的估算值更准确–习惯认为用较宽范围会让自己显得无知或能力不足–但是事实却与此相反(当然有具体数据支持都希望取较窄的范围)提示#:避免使用没有依据的较窄范围。确保在估算值中使用的范围和你给出的估算的置信度相比配。软件估算SoftwareEstimation你的估算水平如何()•使用较窄范围的压力来自何方?–在测验的说明中没有鼓励使用较窄范围–压力来自估算人员自身职业的荣誉感–压力来自估算人员的老板、与客户交道的经历提示#:如果感受到把范围取得更窄的压力就要核实这种压力确实是来自外部而非自身。你的估算水平如何()•该测验对真实软件估算的代表性–在软件项目中常常要求开发人员对下列问题进行估算:•对不熟悉业务领域中的项目•对采用新技术实现的项目•新编程工具对生产率的影响•尚未确定的人员的生产率。–面对不确定性进行估算是软件人员常见的工作准确估算的价值•陈年老问题:软件项目估算不准确受到目标不切实际和无法实现的影响。•导致失败原因:时间不足>所有其他之和•最危险的敌人:最后期限的压力•最具破坏力因素:过度紧张不合理进度准确估算的价值()•高估更好还是低估更好?–反对高估:担心浪费用与完成工作的时间有意压缩估算值灌输紧迫感–反对低估:造成多种问题(明显、隐含)•降低项目计划的有效性•降低按时交付的可能性(从统计角度)•导致实际结果比名义结果更差(前期工作不充分)•导致实际结果比名义结果更差(后期破坏性变因)(变因:page)准确估算的价值()•权衡各种观点–消除“高估”的担心:采用积极的任务跟踪和缓冲管理(即:项目管理)–不应人为降低估算值–估算值过低:计划工作低效实际成本增加进度延长–估算值过高:就会浪费用来完成工作的时间准确估算的价值()软件估算SoftwareEstimation准确估算的价值()提示#:不要故意低估。低估带来的损失比高估带来的损失更严重。应通过计划和控制来解决对高估的顾虑而不要故意降低估算值。准确估算的价值()•软件行业估算情况的详细记录–可以为探究软件估算问题的实质提供一些重要的线索。–按规模统计的结果:功能点(代码行)规模提前按时延期失败取消(,)(,),(,),(,,)<,(,,)准确估算的价值()–项目会延误多少?平均幅度:–估算的误差情况更糟。–软件估算在行业中存在系统性偏差、低估–首先让估算值变大才能让估算结果更精确。–这对很多开发机构来说是一个严峻的挑战。准确估算的价值()•准确估算带来的好处–更准确地显示项目状态–更高的软件质量–更好地与软件外部活动进行协调•活动:测试、文档编写、市场推广、人员培训等等–更好地编制预算–提高开发团队的可信度–更早获得风险信息准确估算的价值()提示#:认清项目业务的目标和估算结果之间存在不一致的含义:这是表明项目可能无法成功的高价值的风险信息。在纠正措施还能起作用的时候应尽早进行纠正。准确估算的价值()•可预测性与项目其他属性的价值比较–软件行业强调投入市场的时间、成本和灵活性–管理层需要向客户、投资者、供应商、市场等等做出承诺–承诺需要可预测性的支持–高层最重视的是可预测性提示#:对很多业务而言可预测性比开发时间、成本或灵活性更有价值。一定要了解哪些方面才是对业务最有价值。软件估算SoftwareEstimation估算误差来源如果还不知道自己在谈论什么那么期望谈论的事达到精确是没有意义的。约翰·冯·诺依曼•软件估算存在挑战的原因在于其本身就存在挑战。估算误差来源()估算值中误差的来源的方面:–有关被估算项目的不准确信息–项目开发组织能力相关的不准确信息–项目混乱而无法为准确估算提供有效支持–估算过程本身带来的误差。估算误差来源()•估算不确定性的来源–只有清楚理解每个详细的特性之后才能准确估算软件项目的成本。(例子page)–对任何给定的特性在如何说明、设计和实现单个特性上的潜在差异导致在实现时间上累积产生倍以上的差异。–软件开发是一个逐步精炼的过程估算误差来源()•不确定性锥估算误差来源()估算误差来源()–是否可以突破不确定锥的限制?•锥形代表了软件估算在项目不同时刻所能够得到的最佳准确度(bestcaseaccuracy)•锥形代表了由有经验的估算人员建立的估算中的误差。•估算结果不可能比不确定锥给出的限制更准确只可能是估算时碰巧很接近实际值。软件估算SoftwareEstimation估算误差来源()提示#:要考虑不确定性锥对估算准确度的影响。估算结果的准确度不会比项目在锥形中当前位置可能的准确度更高。估算误差来源()–锥形不会自行缩小•认为不确定性追代表的最佳估算的另一个原因是:如果项目未收到良好的控制或者估算人员经验不足估算值的准确度可能就不会得到改善。提示#:不要认为不确定性锥会自行缩小。必须通过从项目中排除可变性来源的方法来迫使锥形变窄。估算误差来源()估算误差来源()阶段范围误差最小可能值误差最大可能值误差范围初始概念倍倍倍批准产品定义倍倍倍需求完成倍倍倍界面设计完成倍倍倍详细设计完成倍倍倍按软件开发活动划分的估算误差估算误差来源()–在软件估算中考虑不确定性锥的影响•方法一:从“最可能”估算值开始使用上表预先确定的系数来计算出范围。提示#:通过在估算值中使用预先确定的不确定性范围来考虑不确定性锥的影响。估算误差来源()•方法二:让一个人来估算范围的最好、最差情况然后再让另一个人来估算实际结果落入这个范围的可能性。提示#:由一个人来估算“有多少”由另一个人来估算“有多少不确定”从而考虑不确定性锥的影响。软件估算SoftwareEstimation估算误差来源()–不确定性锥和承诺的关系•在还处不确定锥中较早阶段时就做出承诺其结果往往反而破坏自己项目。此时的承诺没有意义。•在项目的中前期(约进行到时)才有可能作出有意义的承诺这也是恰当的做法。–不确定性锥和迭代开发•迭代项目比顺序项目要复杂•对整体迭代的替代方法不是“不迭代”是“较少”迭代或“不同阶段”不同迭代。•折衷方法在项目开始时定义需求的主体然后使用迭代进行设计、构造、测试和发布。估算误差来源()•混乱的开发过程–项目开始就没有很好地研究需求–在需求阶段缺乏最终用户的参与–导致代码中出现无数错误的不良设计–引发大量排错工作的不良编码实践–缺乏有经验的人员–不完整或不熟悉的项目计划活动估算误差来源()–总是把自己想象成关键影响者或支配人员–在压力下放弃计划工作–开发人员“镀金”为自身利益增加不必要的功能或采取不必要的方法–缺乏自动化的源代码控制(如:未使用SVN)提示#:不要期望单纯采用更好的估算实践就能为混乱的项目提供更准确的估算。不可能准确估算一个失去控制的过程。作为起始步骤消除混乱比改善估算更重要估算误差来源()•不稳定的需求–不稳定的需求会带来各种挑战在估算方面有:•挑战1:代表了特定方式的项目混乱(锥形就不可能缩小)•挑战2:没有对需求变更的跟踪就会在需求变更时遗漏对项目的重新估算–估算方法可以帮助在需求具有高度可变性时“更好地”进行估算估算误差来源()–但更好的估算本身并不能解决需求不稳定带来的问题–在项目控制上做出反应而不是在估算中做出反应才能更好地解决这个问题提示#:处理不稳定的需求时应考虑项目控制策略而不仅是估算策略或者将两者共同考虑。估算误差来源()–对需求增长的估算•考虑到需求增长的问题可以在估算中为需求变化的出现留出适当的“空间”软件估算SoftwareEstimation估算误差来源()•遗漏活动–遗漏会发生项目开发的各个层面上–遗漏的工作主要有三类:•遗漏需求•遗漏软件开发活动•遗漏非软件开发活动估算误差来源()–遗漏需求软件估算中经常遗漏的功能需求和非功能需求()功能需求非功能需求安装程序准确度数据转换工具互操作性使用第三方或开源软件所需的集成代码可修改性帮助系统性能部署方式可靠性估算误差来源()–遗漏需求软件估算中经常遗漏的功能需求和非功能需求()功能需求非功能需求与外部系统的接口响应性可复用性可伸缩性安全性抗毁性易用性估算误差来源()提示#:在估算中要包括声明的需求、隐含的需求和非功能性需求也就是所有需求的时间。没有免费的午餐估算中也不应该暗示能够免费满足某些需求。估算误差来源()软件估算中经常遗漏的软件开发活动()新团队成员做准备的时间项目开发过程中为现有系统提供技术支持指导新团队成员项目开发过程中对以前的系统进行维护管理层协调管理人员会议缺陷纠正工作交接/部署性能调整数据转换学习新开发工具估算误差来源()软件估算中经常遗漏的软件开发活动()安装与缺陷跟踪有关管理工作定制开发人员与测试人员协调需求澄清测试人员与开发人员协调维护修订控制系统回答质量保证部门提出的问题为构建工作提供支持编辑和评审用户文档维护运行每日构建所需的脚本评审技术文档软件估算SoftwareEstimation估算误差来源()软件估算中经常遗漏的软件开发活动()维护与每日构建相关的自动化模拟测试向客户或用户演示软件在用户现场安装测试版本在展会上演示软件生成测试数据向高层、客户和最终用户演示软件管理beta测试版程序与客户或最终用户进行交互为客户场所安装的beta测试版本提供支持估算误差来源()软件估算中经常遗漏的软件开发活动()参与技术评审评审计划、估算、架构、详细设计、阶段设计、代码、测试用例等等集成工作处理变更出席变更控制会诊会议与分包商进行协调估算误差来源()提示#:在估算中包含所有必要的软件开发活动而不只包含编码和测试工作。估算误差来源()软件估算中经常遗漏的非软件开发性活动休假公司会议假日部门会议病假配置新的工作站培训在工作站上安装新版本周末排除软硬件故障估算误差来源()提示#:在持续时间长于数周的项目中同时也要休假、病假、培训和公司会议等活动的开销留出空间。估算误差来源()•没有理由的乐观主义–软件估算在许多方面受到乐观主义的危害。–微软副总裁ChrisReters:•从不担心开发人员建立的估算值过于悲观因为他们总会建立过于乐观的时间进度。–对个项目进行研究后发现开发人员的估算倾向比实际情况乐观~。软件估算SoftwareEstimation估算误差来源()–虽然管理人员会抱怨开发人员给出的估算值太大但开发人员通常不会夸大它往往是过低了。提示#:不要减少开发人员给出的估算值它们可能已经过于乐观了。估算误差来源()–乐观主义同样会影响到管理层。他们不会假设项目可以比实际情况快完成总希望能更快、更便宜的完成。–乐观氛围:•这个项目中的生产率会比上一个项目高•这个项目中不会出现上一个项目中的那么多问题•这个项目启动得很慢得到很多教训这会让我们完成项目的速度比开始时快很多。估算误差来源()–乐观主义是近乎普遍存在的人类本性软件估算有时会受到乐观主义的破坏。–开发人员提出乐观的估算值。–主管们喜欢这些乐观的估算因为这意味着期望的业务目标是可以实现。–管理人员喜欢这些乐观的估算因为这意味着可以支持更高管理层的目标。–于是启动后就无人会认真关注这个估算是否具有可靠的基础。估算误差来源()•主观性(subjectivity)和偏差(bias)–偏差是指试图将估算向某个方向进行(无根据)调整。–就偏差而言客户和管理人员在发现估算值与业务目标不一致时做出的反应就是从估算值开刀、向项目和团队施压。估算误差来源()–主观性是指人的判断受到经验的有意、无意的影响。–就主观性而言在考虑不同估算方法时会认为在估算方法中的“控制按钮”越多就可为匹配特定项目而可以对它进行调整的地方越多估算结果就会越准确。–事实恰恰相反控制按钮越多估算受主观性的影响就越大。–其实简单的方法总体上和复杂方法一样准确。估算误差来源()提示#:避免在估算中有“控制按钮”。虽然控制按钮可能会让人觉得估算更准确但它们往往会带来主观性降低实际准确度。软件估算SoftwareEstimation估算误差来源()•即兴估算–项目团队有时会受到即兴估算的困扰–例子(page)拍脑袋–直觉和猜测在软件估算中都会导致超支和超期–依据“记忆”进行估算时犯的错误是把新项目和记忆中项目进行比较–但是记住的是过去的估算值而不是实际结果–实际就是把新的估算值校准到已造成超期的估算值上估算误差来源()–直觉和猜测会造成项目超出估算但是使用“记录的事实”可以减少项目超出估算。(page)提示#:不要作即兴估算。即便是只经过分钟考虑的估算也会更准确。估算误差来源()•无根据的精度–对软件估算而言“准确度”与“精度”之间的区别是至关重要的。–准确度(accuracy):指数值离真实值有多远。–精度(precision):仅仅指一个数值有多精确。–在软件估算中精度等同于估算值中有多少位有效数字。–测量值可能很精确但不准确或准确但不精确估算误差来源()准确度和精度的例子例子说明PI=准确到位有效数字不精确PI=精确到位有效数字准确只位PI=准确和精确都达位有效数字我的身高=米准确到位有效数字不很精确航班时刻精确到分钟但不准确需天±个月高度精确但不能准确达到的精度需,人时高度精确但可能不能准确达到精度需年不很精确但可能是准确的估算误差来源()提示#:应该让估算值中有效数字的位数(它的精度)和估算值的准确度相匹配。估算误差来源()•其他的误差来源–不熟悉的业务领域–不熟悉的技术领域–从估算时间到项目时间的不正确转换–对统计概念的误解–破坏有效估算的预算编制过程–有准确的规模估算但把规模估算转换成工作量时产生误差软件估算SoftwareEstimation估算误差来源()–有准确的规模和工作量估算但把它们转换成时间进度估算时产生误差–夸大了新开发工具或方法所能节省的成本–在管理层层层上报或进入预算的过程中对估算值的简化–等等影响估算的因素•项目规模–是影响工作量、成本和进度的最具有决定性的因素–常见违背这一事实作法:•在不知道软件会有多大规模的情况下估算工作量、成本和进度•在有意识地增加软件规模时没有相应地调整对工作量、成本和进度的估算影响估算的因素()提示#:应投入适当的精力来评估要构建的软件的规模。软件规模是影响项目工作量和进度的最主要因素。影响估算的因素()–使用代码行表示规模的原因•用代码行表示规模是常见方式•新接触估算时有时会怀疑它是否确实为有效的方式其原因有二:•问题:现代许多编程环境不是面向代码行•问题:许多开发活动(如:需求、分析、测试等等)不能用代码行表示•如何解决用代码行衡量规模的有效性请阅读第章中的“规模估算中的挑战”影响估算的因素()–规模不经济•在软件行业之外如果建立一个更大的制造厂就能降低制造单位产品所需的成本规模经济•在软件行业之内随规模的增加人与人之间交流沟通路径的数目会按参与人员数nx(n)增加影响估算的因素()•沟通路径的增加就带来了工作量/成本会呈现指数增长规模不经济•随着项目规模的扩大项目开发条件会让生产率降低得比一般规模情况下更快项目规模和生产率之间的关系项目规模(LOC)每人年产的LOC(CocomoII模型值)K,~,(,)K,~,(,)M~,(,)M~,(,)软件估算SoftwareEstimation影响估算的因素()提示#:不要认为工作量是随着项目规模的扩大呈线性地增长。实际上工作量是以指数方式增长的。提示#:使用软件估算工具来计算规模不经济所产生的影响。影响估算的因素()–何时可以安全忽略规模不经济•规模不经济有利一面:如果两个规模相近就可以安全地使用一个简单的产能(LOC人月)来估算•如果在有限的规模范围内使用基于产能的方法估算值中的误差就不会太大。•如果使用处于规模范围中间位置的平均产能规模不经济带来的误差不会超过影响估算的因素()提示#:如果以前完成的项目和带估算的项目的规模大致相当(最大规模和最小规模的项目差距不超过倍)就可以安全地使用基于产能(如:每人月完成的代码行数)的估算方法来估算新项目。影响估算的因素()–软件估算中规模不经济的重要性•项目原始规模才是影响估算值的最大因素•规模不经济对估算值的影响只是次要的要将主要精力放在获得良好规模估算上影响估算的因素()•待开发软件的不同类型–这是排在“规模”之后对估算值影响第二大的因素–从下表可看到不同类型之间存在~倍的差距–从下表还能看到规模不经济现象影响估算的因素()软件估算SoftwareEstimation影响估算的因素()–考虑你所在的行业对估算值的影响有三种方法:从上表开始。注意其给出的范围相当大:倍使用CocomoII模型调整估算参数。要注意过多使用“控制按钮”的警告使用所在机构的历史数据。这可以自动加入所在行业的有关的特定开发。这优于前两者影响估算的因素()提示#:在估算中要考虑待开发软件的类型。待开发软件的类型是第二位影响到项目开发工作量和时间的因素。影响估算的因素()•人员因素–人员因素也会对项目结果产生显著的影响影响估算的因素()–个体间的差距意味着如果没有对参与人员有一定的了解就无法准确估算个体间差异有倍–个体间差异隐含着需要知道具体将由谁来处理正在估算的这些工作影响估算的因素()•编程语言–它将由以下四个方面影响估算:团队对将要使用编程语言的经验会对总体生产率产生影响某些编程语言的代码行效率高于其它将使用编程语言的相关支持工具和开发环境是否丰富最差工具会增加约工作量使用解释型语言比编译型的生产率更高影响估算的因素()与C语言比较完成相同功能的语句数量比例语言与C语言语句数量比C:C#:C:Cobol:Fortran:Java:宏汇编:软件估算SoftwareEstimation影响估算的因素()与C语言比较完成相同功能的语句数量比例语言与C语言语句数量比Perl:Smalltalk:SQL:VisualBasic:影响估算的因素()•其它因素CocomoII模型的调节因子–担心不能很好地使用而不是方法本身的错误–以下是几种因素:影响估算的因素()•工作量乘数(EM)因子影响估算的因素()影响估算的因素()影响估算的因素()•再论规模不经济软件估算SoftwareEstimation影响估算的因素()影响估算的因素()–从估算的角度来看不同的项目规模要对不同因子进行不同的加权–从项目计划和控制的角度来看小、中型项目可以在很大程度上依靠能力突出的个人取得成功–大型项目也需要有能力的人但是项目管理的优劣(尤其风险管理)、开发组织是否成熟以及个体是否良好的结合成团队等方面变得更为重要第二部分基本估算方法•估算方法概述•计数、计算和判断•估算校准和历史数据•专家的个人判断•分解和重组•类比估算•基于代理的估算第二部分基本估算方法()•专家小组判断法•软件估算工具•使用多种估算方法•获得良好估算的估算流程•标准化估算规程估算方法概述•选择估算方法时考虑的问题–最有效的方法都是由两种需要共同决定的考虑“影响估算的因素”避免“估算误差的来源”–待估算的内容类型先定特性再估算交付这些特性所需工作量和时间先定限制再估算在这些限制下可交付多少特性(限制:预算和开发时间)估算方法概述()–项目规模(代码行、功能点、用户故事)小型–开发人员数<=–人员模式是“扁平”的(人数基本不变)–个人生产率变化可以掩盖其他因素的影响–最佳方法“自底向上”基于参与人员的个人估算值–不能用较大项目中应用的基于统计的方法软件估算SoftwareEstimation估算方法概述()大型–开发人员数>–项目工作时间将持续~月–早期:不知道参与人最佳方法是基于统计学“自顶向下”–中期:将自顶向下的结果与基于的项目历史数据自底向上结合–后期:自底向上方法可提供最准确的估算估算方法概述()中型–开发人员数:~–项目工作时间将持续~月–可以使用大型项目的所有估算方法–也可以使用几种小型项目估算方法估算方法概述()–软件开发方式就估算而言:顺序开发迭代开发这里关心的是:在早期定义的需求与在构造过程中定义的需求比例的高低常见开发方式(page)开发方式对估算方法选择的影响–顺序、迭代都可能开始于自顶向下的或基于统计学的估算方法最后都迁移到自底向上的方法估算方法概述()–开发阶段早期–对于顺序是从概念起始到需求定义基本完成–对于迭代是初始计划期中期–是从初始计划到早期构造的时间。–对于顺序它覆盖“需求架构”工作–对于迭代最初的~次迭代(可以放心使用自身的生产率)估算方法概述()后期–从中期构造直到项目发布的时间–可能的准确度依赖于:方法本身方法是否应用到适当的问题方法是否应用到适当的阶段提示#:选择估算方法时要考虑待估算的对象、项目规模、开发阶段、项目的开发方式和需要的准确度计数、计算和判断计数计算估算对象规模、特性规模、工作量、进度、特性项目规模小、中、大小、中、大开发阶段早期~后期早期~中期迭代或顺序两者皆可两者皆可可能的准确度高高软件估算SoftwareEstimation计数、计算和判断()•例子估算房间里人数(page)–根据经验()–根据“桌子”数人数桌()–根据空间限制:(~~平均:)–依据上述:–离开查询:扫描计数()计数、计算和判断()•首先计数–例子正确答案:–例子揭示的秘密是:应该避免一些通常被当成是估算的做法!如果可以直接计数得到答案就应该首先那样做。如果无法直接计数得到答案就应该先对某些对象进行计数然后使用某些校准数据计算出答案(桌子数x人数桌)计数、计算和判断()提示#:尽可能使用计数无法计数时就进行计算。判断只是作为最后的手段。计数、计算和判断()•计数的对象–软件项目会产生许多可以计数的对象早期:市场需求、特性、用例、用户故事等中期:工程需求、功能用途、变更请求、Web页面、报告、对话框、显示屏幕、数据库表等在更细的粒度上进行计数后期:编写的代码、报告的缺陷、类、任务、早期已进行过的计数的所有细节在更精细的细节水平上进行计数计数、计算和判断()–找到与待估算软件的规模高度相关的技术对象(如:需求数目)。•要找到能有效体现软件规模的指示器(如:Web页面数、配置的设置项等取决于不同的环境)提示#:寻找在所处环境中能够对工作范畴进行有意义度量的对象作为计数对象。计数、计算和判断()–找到在开发周期中可以更早获得的技术对象•越早找到有意义的技术对象就可以越早提供长期的可预测性。–找到可以产生在统计上有意义的均值的计数对象•要找能产生个以上的计数值对象软件估算SoftwareEstimation计数、计算和判断()–理解正在计数的对象•采用计数作为基础要保证历史数据计数值和估算中使用的计数值采用了同样的假设–找到计数工作量最小的对象•在所有其他条件都相同下最好对计数所需工作量最小的对象进行计数(估算也需成本)计数、计算和判断()•通过计算把计数值转换成估算值–如果收集了与计数值有关的历史数据就可以把计数值转换成更有用的对象(如工作量的估算值)–可以用于估算的计数量提示#:收集历史数据便于由此计算出估算值。计数、计算和判断()–在项目后期对缺陷进行计数的例子•已处理个缺陷平均每个需小时•个缺陷x小时=小时–通过Web页面计数进行估算的例子•如果数据表明:每个Web页平均需要小时完成设计、编码、测试工作•剩余个页面x小时=小时–这两个例子的要点在于这些估算中没有判断。是先计数后计算。计数、计算和判断()提示#:不要小看诸如:每个缺陷、每个Web页面、每个用户故事和每个用例的平均工作量之类的单一、粗略的估算模型的作用。计数、计算和判断()•只把判断作为最后的手段–所谓的专家判断是最不准确的估算方法。–估算值只有和某些具体数据联系在一起时才是最准确的。–把历史数据和计算结合起来可以显著减少估算受到偏见影响的程度。计数、计算和判断()提示#:避免使用专家判断调整通过计算得到的估算值这样的“专家判断”通常会降低估算结果的准确度。软件估算SoftwareEstimation估算校准和历史数据用行业平均数据校准用机构数据校准用项目相关数据校准估算对象规模、工作量、进度、特性规模、工作量、进度、特性规模、工作量、进度、特性项目规模小、中、大小、中、大小、中、大开发阶段早期~中期早期~中期中期~后期迭代或顺序两者皆可两者皆可两者皆可可能的准确度低~中中~高高估算校准和历史数据()校准用于把计数值转换成估算值:–代码行数工作量–用户故事日历时间–需求测试用例数校准的三种类型数据:–行业数据:来自其他开发组织的数据(类型相同)–历史数据:来自开发组织自身的数据–项目数据:来自带估算项目本身先前产生的数据估算校准和历史数据()•历史数据可以提高准确度并带来其他益处–使用历史数据要考虑影响项目结果的开发组织因素软件的复杂性?开发组织能否承诺需求是稳定的?团队人员组成?团队人员稳定?团队资源足够?估算校准和历史数据()

用户评价(0)

关闭

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

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

提示

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

评分:

/12

VIP

在线
客服

免费
邮箱

爱问共享资料服务号

扫描关注领取更多福利