软件项目管理-Ch7课件

1Chapter7

软件项目估算主要内容软件项目估算概述软件项目估算的常见方法软件项目成本估算方法软件项目估算公差表示231.1估算中的常见问题不现实的估算没有时间做出估算不完整或不正确的需求没有过去的数据可用不成立的假设——生产率与所施加的进度要求无关4估算中的常见问题（续）没有考虑到其他重要项目因素开发环境的可用性和稳定性团队的能力和经验团队稳定性过程成熟度可复用的软件对需要创建的可复用软件的估算同客户/用户之间可能的交流程度在软件开发和软件维护中使用自动化工具的程度项目相关人员和团队的团结缺少用于估算的培训和技能在项目的进行中对估算的跟踪不好没有使用“公差”的概念1.2估算的时机5可行性分析阶段：决定是否可以立项产品定义阶段：此时的估算有助于组织在进入产品开发之前再次权衡产品的可行性。如果不可行，及时停止项目的执行，以避免后期的项目失败。系统设计阶段：此时的估算工作主要考虑的是如何将设计好的系统开发出来以及有没有被忽视的问题。这个阶段的估算一般不会做出终止项目的决定，但是却会影响以后各个阶段资源的分配。系统实现：对原有的估算进行调整，后期需要完成的工作则是按此新估算进行计划了。系统运行后：此时的估算工作实际上是对估算过程的评价，即用实际的消耗和各个阶段的估算值进行比较，总结估算工作中哪些方面需要提高，为下个项目提供经验。估算的渐进性6初始的产品定义批准的产品定义需求说明书产品设计说明书详细设计说明书产品完工项目成本（工作量和成本）项目进度1.0x1.0x4.0x2.0x1.5x1.25x0.8x0.67x0.5x0.25x1.6x1.25x1.15x1.1x0.9x0.85x0.8x0.6x1.3估算对实际结果的影响7估计过高问题：帕金森定律（Parkinson’sLaw）：工作总是用完所有可以利用的时间。布鲁克斯定律（Brooks’Law）：在一个延迟的工作上投入更多的人，可能导致该项工作更加延迟。估计过低问题：质量问题可靠性零定律（Weinberg’Law）：如果一个系统不要求是可靠的，那么它能满足任何其他目标。估算对实际结果的影响8帕金森法则导致的线性损失规发错误、高风险、质量问题带来的非线性损失100%>100%<100%估算结果相对于准确估算值的百分比高估低估工作量成本进度1.4软件项目估算内容9软件需求规格说明规模估算工作量估算进度估算成本估算其他项目因素客户提出的进度其他成本构成10国际项目管理IPMA1.5软件项目估算步骤1.确定软件项目范围2.估算完成软件开发所需的资源3.估算工作量4.估算成本11估计可用资源资源描述可用性陈述需要该资源的时间该资源被使用的持续时间12估算过程输入：SOW、WBS资源单价（比如每小时人员费用）历史项目数据学习曲线估算处理过程：各种估算工具输出：估算文件或说明13估算说明估算出的各种工作量和成本工作范围的陈述，WBS说明估算的依据和为成本估算所做的任何假设的合理性估算的误差变动141.6软件生产率软件生产率是指人均每月所能生产的有效源代码行数。（生产率＝规模/工作量）影响软件生产率的因素人的因素：开发机构的规模和经验问题因素：问题的复杂性和设计约束或要求更改的次数过程因素：使用的分析和设计技术、应用的语言及评审的过程。生产因素：计算机系统的性能和可靠性资源因素：开发工具、硬件和软件资源15软件生产率根据软件组织的历史数据，按照以下步骤获取软件生产率数据：选择一些最近完成的项目，这些项目在规模、语言、应用类型、团队开发经验等方面与待完成项目类似。获取各个项目的规模数。（功能点、对象点、LOC）计算投入到每个项目中的人员数量计算各个项目的软件生产率，即（功能点、对象点、LOC）/PM（人月）,进而求出平均值作为类型项目的典型软件生产率。16国际项目管理IPMA2软件项目规模估算方法代码行法功能点法自下而上法类比法专家判断法参数估算法简单估算法2.1代码行法17代码行是常用的度量软件规模的一种方法,是对软件产品的源代码的行数进行测量。LOC(LineofCode)：所有的可执行的源代码行数，包括可交付的工作控制语言语句、数据定义、数据类型声明、输入/输出格式声明等。一代码行（1LOC）的价值和人月均代码行数可以体现一个软件生产组织的生产能力。

代码行法18缺点：在需求、计划、设计阶段因为本身没有代码行，需要靠估算来解决。总体上估算准确度不高。在满足客户的要求以及反映进度方面的能力差强人意。当在程序的结果中有大量自动生成的代码或者复杂的自动配置脚本或资源文件设置时，用代码行分析方法得到数值的意义已经大大降低。对于不同的编程语言，代码行也缺乏可信转换方式。优点：容易使用，非常直观，操作成本低2.2功能点法19该方法是由AllanAlbrecht(艾伦.艾尔布策)20世纪70年代在IBM工作时发明的自顶向下方法,后来被国际功能点协会提出的IFPUG集成。可以在项目早期使用，实在需求分析阶段基于系统功能的一种估算发放，与编程语言无关功能点法（FunctionPoints）的基础是基于计算机信息系统由5个主要构件组成：外部输入：应用数据，更新计算机内部文件，不同于查询外部输出：提供给用户的面向应用的信息，指报表、屏幕和出错信息等内部逻辑文件：逻辑主文件外部接口文件：与其它系统交换信息外部查询：在线的输入以获得立即的结果20功能点分析计算公式:FP=UFC*TCFUFC(UnadjustedFunctionPointCount):未调整功能点计数TCF(TechnicalComplexityFactor)：技术复杂度因子计算过程：1.求出5个功能项的数量，然后按照复杂性得出加权和，即为UFC2.评估14个技术复杂度因子，带入TCF公式求TCF21UFC计算简单一般复杂外部输入346外部输出457外部查询346外部接口文件5710内部逻辑文件710156×3×2×7×0×5×9×7×2×2×0×0×4×3×2×UFC＝3015类功能计数项的复杂度权重22技术复杂度因子技术复杂度因子F1可靠的备份和恢复F2数据通信F3分布式函数F4性能F5大量使用的配置F6联机数据输入F7操作简单性F8在线升级F9复杂界面F10复杂数据处理F11重复使用性F12安装简易性F13多重站点F14易于修改相当的影响2不显著的影响1不存在或没有影响0描述调整系数强大的影响5显著的影响4平均的影响3描述调整系数23TCF计算TCF=0.65+0.01*(Sum(Fi)),其中i＝1,2,3,…,14,因为Fi取值范围0-5，所以TCF结果范围0.65-1.35假设前面例子中此软件项目的技术复杂影响程度都是平均程度，则：TCF＝0.65+0.01*（14*3）＝1.07则：FP＝UFC*TCF=301*1.07＝322242.3自下而上法利用WBS进行估计优点：如果活动划分的很好就容易估算缺点：活动本身很费时间，而且很多细节的活动可能没有想到，也缺少活动集成的工作量252.4类比法自顶向下类推法:将估算项目的总体参数与类似项目进行直接相比。自底向上类推法:比较类似的工作单元优点：简单易行，适合项目初期信息不足时候使用（比如合同期和市场招标）缺点：准确性差26类比法中重用代码的估算类比法中要解决可重用代码的估算问题。一般估算出：新项目可重用的代码中需重新设计的代码百分比、需重新编码或修改的代码百分比以及需重新测试的代码百分比。则等价新代码行为：等价代码行=[(重新设计%+重新编码%+重新测试%)/3]×已有代码行比如：有10,000行代码，假定30%需要重新设计，50%需要重新编码，70%需要重新测试，那么其等价的代码行可以计算为：[(30%+50%+70%)/3]×10,000=5,000等价代码行。意即：重用这10000代码相当于编写5000代码行的工作量。

272.5专家判断法(Deiphi法)专家判断法是通过专家对项目成本做出估算。这种方法的精确性取决于专家对估算项目的定性参数的了解和经验。现在比较常用的专家判断法是德尔菲法(Delphitechnique)。

28德尔菲法的具体步骤(1)协调人向各专家提供项目规格和估算表格，并且告知各专家与项目规模相关的因素；(2)各专家匿名填写估算表格；(3)协调人根据各个专家估算的结果整理出一个估算总结，如果对同一个工作单元估算结果在可以接受的误差范围之内，那么此估算结束，否则进入下一步；(4)协调人再次就估算差异较大的项制定估算表格反馈给专家，并且把其他专家的估算结果和原因作为可选项列在表格中供专家参考；(5)专家复查估算结果并提交另一个匿名估算；(7)重复3～5，直到最终的估算结果是项目小组可以接受的误差范围内的数据。

292.6参数估算法参数估算法是基于一种建模统计技术，如回归分析和学习曲线等。用于估算的算式通常由理论或经验导出。

估算模型的结构：E=A+B*(X)CA、B、C是由经验导出的常数，E是以人月为单位的工作量X

是估算变量30COCOMO:参数化模型COCOMO：ConstructiveCostModel构造性成本模型Boehm在二十世纪70年代采用他的模型对63个项目进行了研究，由于其中只有7个是商务系统，因而它们不仅仅能被用于信息系统。31成本估算模型COCOMO模型（ConstructiveCostMOdel）软件估算模型的层次体系模型1：基本COCOMO模型，将软件开发工作量及成本作为程序规模的函数进行计算，程序规模由已估算的代码来表示。模型2：中级COCOMO模型，将软件开发工作量及成本作为程序规模及一组“成本驱动因子”的函数来进行计算，其中“成本驱动因子”包括对产品、硬件、人员、及项目属性的主观评估。模型3：高级COCOMO模型，包含了中级模型能够的所有特性，并结合了成本驱动因子对软件工程过程中每一步骤的影响评估。32基本COCOMO模型基本COCOMO模型的公式为：Effort=c×sizek其中effort采用“人月”pm来度量，size采用kdsi即千行交付源代码指令(thousandsofdeliveredsourcecodeinstructions)DSI-源指令条数。不包括注释。1KDSI=1000DSI开发工作量（以人月计）1pm=19人日=152人时=1/12人年33COCOMO系数C,k的取值根据系统的分类而定：根据系统的技术特性和开发环境可以分为：有机模式（organicmode):相对小的团队在一个高度熟悉的内部环境中开发规模较小，接口需求较灵活的系统。(规模小于5万行)嵌入式模式（EmbeddedMode)开发的产品在高度约束的条件下进行，通常与某种复杂的硬件设备紧密结合在一起。对接口、数据结构、算法要求都比较高，对系统改变的成本很高。软件规模任意。半分离模式（Semi-detachedMode):两者之间,规模和复杂度都属于中等，最大可达30万行。信息系统是有机模式，而实时系统是嵌入式模式。34COCOMO系数系数表：K的值反映了项目越大，则工作量成指数增加，因为大项目需要更多的协调和安排。系统类型ck有机模式2.41.05嵌入型3.61.20半分离型3.01.1235中等COCOMO模型中级COCOMO模型将软件开发工作量及成本作为程序规模及一组“成本驱动因子”的函数来进行计算，其中“成本驱动因子”包括对产品、硬件、人员、及项目属性的主观评估，共15个成本驱动因子。

Effort=(c×sizek)*dem公式中(c×sizek)结果称为名义工作量dem（developmenteffortmultiplier),是每个成本驱动因子所选择的系数相乘来产生每个组合的系数36驱动因子类型编码驱动因子产品属性RELY重要的软件可靠性DATA数据库规模CPLX产品复杂度计算机属性TIME执行时间限制STOR主存限制VIRT虚拟机易变性：操作系统变更的程度TURN计算机往返时间人员属性ACAP分析员能力AEXP应用经验PCAP程序员能力VEXP虚拟机（OS）经验LEXP编程语言经验项目属性MODP现代编程实践的使用TOOL软件工具的使用SCED需要的开发进度dem非常低1.46低1.19正常1.00高0.80非常高0.7137高级COCOMO模型高级COCOMO模型包括了中级COCOMO模型的所有特性，其工作量以及进度的估算公式和中级COCOMO模型一致，但是高级COCOMO模型中引入了两种主要功能：阶段敏感工作系数。高级COCOMO模型还要考虑软件工程过程中分析、设计等各步骤的影响，认为某些阶段（设计、编码和调试）比其他阶段有关因素的影响可能更大。高级COCOMO模型为每个因素提供了一个“阶段敏感工作权数”。三层产品分级结构。三个产品层次是模块、子系统和系统。所以高级COCOMO模型工作量因素分层、分阶段给出。针对每一个影响因素，按模块层、子系统层、系统层，有三张工作量因素分级表，供不同层次的估算使用，每一张表中工作量因素又按开发各个不同阶段给出。38COCOMOII针对COCOMO的不足，Boehm开始和其合作者发展了新的模型。该方法利用多种乘法算子和指数。此模型适合于各种类型的软件项目。一个明显的特点是该模型适应了项目在执行过程中变得越来越确定的状态，因而是一种渐进性评估。39COCOMOIICOCOMOII被分为三个阶段性模型：应用构成阶段（ApplicationComposition)：用于软件开发早期，支持对原型开发项目所需工作量的估算，同时也支持基于已有构件进行开发的软件项目。在这个阶段设计了用户将体验的系统的外部特征。早期设计（EarlyDesign):基本的软件结构被设计。后架构阶段（Postarchitecture):软件构造经历了最后的构造、修改，并在需要时候开始创建要执行的系统。40COCOMOII在应用构成阶段，采用对象点计算的方法在早期设计阶段，采用功能点和成本驱动因素计算的方法。功能点可以转换为SLOC。41COCOMOII后架构阶段在后架构阶段，采用功能点或者代码行计算工作量，使用5个规模度量因子和17个成本驱动因素进行调整。公式：Pm=A×sizesf×em1×em2×……emnPm为“人月”工作量，A是一个常数2.55，size以LOC为单位，sf是规模指数。Sf＝1.01+0.01×SUM（wi）其中，Wi是规模度量因子42COCOMOII计算规模因素Wi的因子：先前经验:是否有先前的经验。新系统的新颖性越大，不确定性就越大，赋予这个指数驱动因子的值就越高。

开发的灵活性:是否需求能够以多种方式来满足。越缺乏灵活性，这个指数驱动因子得值就越高。

体系结构/风险解决：这个属性和需求的不确定性程度有关，如果需求很有可能要变更，则这个指数驱动因子可能要赋予较高得值。

团队的凝聚性：这个属性反映了一个大型分散群组（也许在几个国家）紧密结合得程度，越低值越高过程的成熟性：软件越是按结构化得、有组织得方式生产，不确定性就越低，这个指数驱动因子得值就越低

432.7简单估算方法简单估算方法，实际是“专家判断法”的变形，采用项目组成员作为项目的“专家”来进行估计。因为项目组的成员对项目的了解程度是比项目组外任何人都强的，而且项目组对于项目的各种功能是达成一致共识的，因此能够让他们作为项目的“专家”来进行估算。

44规模简单估算方法1.项目规划小组先分解产品的功能，制定“产品功能分解与规模估计表”。软件规模的度量单位主要有：代码行、对象个数等等。2.规划小组各成员独立填写表格。3.汇总每个成员的表格，进行对比分析。如果各人估计的差额小于20％，则取平均值。如果差额大于20％，则转向第（2）步，让各成员重新估计产品的规模，直到各人估计的差额小于20％为止。45产品规模简单估算方法46工作量简单估算方法1.先估算开发工作量。一般地可以把开发过程划分为需求开发、系统设计、实现、测试四个阶段，分别估计每个阶段的工作量，然后累计得出总的工作量2.再估算管理工作量。一般地，项目的80％以上的工作量用于开发，20％以下的工作量用于管理。473.1软件项目成本综合估算法1.创建WBS，并估算每个活动的规模（人月）Qi2.估算直接成本：Ei=Qi*人力成本参数所以直接成本＝E1+….+En管理成本＝比例系数*开发成本比例系数约20％-25％3.估算间接成本：间接成本＝直接成本*间接成本系数4.估算总成本：总成本＝直接成本+间接成本如果项目合同中包含一些固定价格的采购，比如硬件设备，这些在计算总成本时候需要加入5.项目报价=项目总成本+风险利润＝项目