|
|
知识路径： > 项目管理 > 项目进度控制 > 活动历时估算 >
|
被考次数：1次
被考频率：低频率
总体答错率：60%
知识难度系数： 
|
由 软考在线 用户真实做题大数据统计生成
|
|
相关知识点：16个
|
|
|
|
|
活动历时估算直接关系到各项具体活动、各项工作网络时间和完成整个项目所需要总体时间的估算。活动历时估算通常同时要考虑间隔时间。项目团队需要对项目的工作时间做出客观、合理的估计。在估算时，要在综合考虑各种资源、人力、物力、财力的情况下，把项目中各工作分别进行时间估计。若活动时间估算太短，则在工作中会出现被动紧张的局面；反之如果活动时间估算太长，则会使整个项目的完工期限延长，从而造成损失。
|
|
|
|
|
|
软件项目的工作量和工期的估算历来是比较复杂的事，因为软件本身的复杂性、历史经验的缺乏、估算工具缺乏，以及一些人为错误，导致软件项目的规模估算往往和实际情况相差甚远。因此，估算错误已被列入软件项目失败的4大原因之一。
|
|
|
|
软件开发项目通常用LOC（Line of Code）衡量项目规模，LOC指所有的可执行的源代码行数，包括可交付的工作控制语言语句、数据定义、数据类型声明、等价声明、输入输出格式声明等。可以根据对历史项目的审计来核算组织的单行代码价值。
|
|
|
|
例如，软考在线公司开发部王总统计发现，该公司每一万行Java语言源代码形成的源文件约为250KB，视频点播系统项目的源文件大小为3.75MB，则可估计该项目源代码大约为15万行，该项目累计投入工作量为240人月，每人月费用为10 000元（包括人均工资、福利、办公费用公摊等），则该项目中1LOC的价值为：
|
|
|
|
(240×10 000)/150 000=16（元/LOC）
|
|
|
|
|
|
|
|
|
|
德尔菲法（Delphi法）是最流行的专家评估技术，该方法结合了专家判断法和三点估算法，在没有历史数据的情况下，这种方式适用于评定过去与将来，新技术与特定程序之间的差别，但专家“专”的程度及对项目的理解程度是工作中的难点，尽管德尔菲法可以减轻这种偏差，专家评估技术在评定一个新软件实际成本时用得不多，但是，这种方式对决定其他模型的输入时特别有用。
|
|
|
|
|
|
（1）组织者发给每位专家一份软件系统的规格说明书（略去名称和单位）和一张记录估算值的表格，请他们进行估算。
|
|
|
|
（2）专家详细研究软件规格说明书的内容，对该软件提出三个规模的估算值，即：
|
|
|
|
|
|
|
|
|
|
无记名地填写表格，并说明做此估算的理由。在填表的过程中，专家互相不进行讨论，但可以向组织者提问。
|
|
|
|
（3）组织者对专家们填在表格中的答复进行整理，做以下事情：
|
|
|
|
①计算各位专家（序号为i，i=1，2，…，n，共n位专家）的估算期望值Ei，并综合各位专家估算值的期望中值E。
|
|
|
|
|
|
|
|
（4）在综合专家估算结果的基础上，组织专家再次无记名地填写表格。然后比较两次估算的结果。若差异很大，则要通过查询找出差异的原因。
|
|
|
|
（5）上述过程可重复多次。最终可获得一个得到多数专家共识的软件规模（源代码行数）。在此过程中不得进行小组讨论。
|
|
|
|
最后，通过与历史资料进行类比，根据过去完成软件项目的规模和成本等信息，推算出该软件每行源代码所需要的成本。然后再乘以该软件源代码行数的估算值，就可得到该软件的成本估算值。
|
|
|
|
此方法的缺点是人们无法利用其他参加者的估算值来调整自己的估算值。宽带德尔菲法技术克服了这个缺点。在专家正式将估算值填入表格之前，由组织者召集小组会议，专家们与组织者一起对估算问题进行讨论，然后专家们再无记名填表。组织者对各位专家在表中填写的估算值进行综合和分类后，再召集会议，请专家们对其估算值有很大变动之处进行讨论，请专家们重新无记名填表。这样适当重复几次，得到比较准确的估计值。由于增加了协商的机会，集思广益，使得估算值更趋于合理。
|
|
|
|
总的来说，德尔菲法的不足之处在于，易受专家主观意识和思维局限影响，而且技术上，征询表的设计对预测结果的影响较大。德尔菲法对减少数据中人为的偏见、防止任何人对结果不适当地产生过大的影响尤其有用。
|
|
|
|
|
|
类比估算法适合评估一些与历史项目在应用领域、环境和复杂度等方面相似的项目，通过新项目与历史项目的比较得到规模估计。由于类比估算法估计结果的精确度取决于历史项目数据的完整性和准确度，因此，用好类比估算法的前提条件之一是组织建立起较好的项目后评价与分析机制，对历史项目的数据分析是可信赖的。
|
|
|
|
|
|
|
|
（2）标识出每个功能列表与历史项目的相同点和不同点，特别要注意历史项目做得不够的地方。
|
|
|
|
|
|
|
|
软件项目中用类比估算法，往往还要解决可重用代码的估算问题。估计可重用代码量的最好办法就是由程序员或系统分析员详细地考查已存在的代码，估算出新项目可重用的代码中需重新设计的代码百分比、需重新编码或修改的代码百分比，以及需重新测试的代码百分比。根据这三个百分比，可用下面的计算公式计算等价新代码行：
|
|
|
|
等价代码行=[(重新设计%+重新编码%+重新测试%)/3]×已有代码行
|
|
|
|
例如，有10 000行代码，假定30%需要重新设计，50%需要重新编码，70%需要重新测试，那么其等价的代码行可以计算为
|
|
|
|
[(30%+50%+70%)/3]×10 000=5000
|
|
|
|
即重用这10 000代码相当于编写5000代码行的工作量。
|
|
|
|
|
|
功能点测量是在需求分析阶段基于系统功能的一种规模估计方法。通过研究初始应用需求来确定各种输入输出，计算与数据库需求的数量和特性。通常的步骤是：
|
|
|
|
（1）计算输入、输出、查询、主控文件与接口需求的数目。
|
|
|
|
|
|
（3）估计者根据对复杂度的判断，总数可以用+25%、0或-25%调整。
|
|
|
|
统计发现，对一个软件产品的开发，功能点对项目早期的规模估计很有帮助。
|
|
|
