个同样软件所花的费用。 (4)分解技术 当一个待解决的问题过于复杂时,可以把它进一步分解,直到分解后的子问题变得容易 解决为止。然后,分别解决每一个子问题,并将这些子问题的解答综合起来,从而得到原问 题的解答。通常,这是我们解决复杂问题的最自然的一种方法 软件项目估算是一种解决问题的形式,在多数情况下,要解决的问题(对于软件项目来 说,就是成本和工作量的估算)非常复杂,想一次性整体解决比较困难。因此,对问题进行分 解,把其分解成一组较小的接近于最终解决的可控的子问题,再定义它们的特性 ①LOC和FP估算 LOC和FP是两个不同的估算技术。但两者有许多共同特性。项目计划人员首先给出 个有界的软件范围的叙述,再由此叙述把软件分解成一些小的可分别独立进行估算的子功能。 然后对每一个子功能估算其LOC或FP(即估算变量)。接着,把根据以往完成项目得到的(基 线)生产率度量(如,LOC/PM或FP/PM)用做特定的估算变量,导出子功能的成本或工作 量。将子功能的估算进行综合后就能得到整个项目的总估算 LOC或FP估算技术对于分解所需要的详细程度是不同的。当用LOC做为估算变量时, 功能分解是绝对必要的且需要达到很详细的程度。而估算功能点所需要的数据是宏观的量, 当把FP当做估算变量时所需要的分解程度不很详细。 应注意,LOC是直接估算的,而FP是通过估计输入、输出、数据文件、查询和外部接 口的数目,以及在表9.3中描述的14种复杂性校正值间接地确定的 计划人员可对每一个分解的功能提出一个有代表性的估算值范围。利用历史数据或凭实 经验,对每个功能分别按最佳的、可能的、悲观的三种情况给出LOC或FP估计值。记作 a、m、b。当这些值的范围被确定之后,也就隐含地指明了估计值的不确定程度。接着计算 LOC或FP的期望值E (a+4m+b)/6 (加权平均) 确定了估算变量的期望值,就可以用作LOC或FP的生产率数据 作为LOC和FP估算技术的一个实例,考察一个为计算机辅助设计(CAD)应用而开发 的软件包。在这个实例中,使用LOC做为估算变量。 根据对软件范围的叙述,对软件功能进行分解,识别出主要的几个功能:用户界面和控 制功,二维几何分析,三维几何分析,数据库管理,计算机图形显示功能,外设控制以及设 计分析模块。通过下述的分解技术,可得到如表95所示的估算表 表9.5估算表 功能 E每行成本生产率成本工作量 最佳值可能值悲观值期望值(元/行)(行/PM)(元 用户接口控制1800240026502340 二维几何造型410002007405380 三维几何造型4600690086006800 数据库管理29503400360035018 终端图形显示4050490062004950 外部设备控制20002100 1405992015.2 设计分析 6600850098008400 33360 144.5 表中给出了LOC的估算范围。计算出的各功能的期望值放入表中的第4列。然后对该
11 个同样软件所花的费用。 (4) 分解技术 当一个待解决的问题过于复杂时，可以把它进一步分解，直到分解后的子问题变得容易 解决为止。然后，分别解决每一个子问题，并将这些子问题的解答综合起来，从而得到原问 题的解答。通常，这是我们解决复杂问题的最自然的一种方法。 软件项目估算是一种解决问题的形式，在多数情况下，要解决的问题(对于软件项目来 说，就是成本和工作量的估算)非常复杂，想一次性整体解决比较困难。因此，对问题进行分 解，把其分解成一组较小的接近于最终解决的可控的子问题，再定义它们的特性。 ① LOC 和 FP 估算 LOC 和 FP 是两个不同的估算技术。但两者有许多共同特性。项目计划人员首先给出一 个有界的软件范围的叙述，再由此叙述把软件分解成一些小的可分别独立进行估算的子功能。 然后对每一个子功能估算其 LOC 或 FP(即估算变量)。接着，把根据以往完成项目得到的(基 线)生产率度量(如，LOC／PM 或 FP／PM)用做特定的估算变量，导出子功能的成本或工作 量。将子功能的估算进行综合后就能得到整个项目的总估算。 LOC 或 FP 估算技术对于分解所需要的详细程度是不同的。当用 LOC 做为估算变量时， 功能分解是绝对必要的且需要达到很详细的程度。而估算功能点所需要的数据是宏观的量， 当把 FP 当做估算变量时所需要的分解程度不很详细。 应注意，LOC 是直接估算的，而 FP 是通过估计输入、输出、数据文件、查询和外部接 口的数目，以及在表 9.3 中描述的 14 种复杂性校正值间接地确定的。 计划人员可对每一个分解的功能提出一个有代表性的估算值范围。利用历史数据或凭实 际经验，对每个功能分别按最佳的、可能的、悲观的三种情况给出 LOC 或 FP 估计值。记作 a、m、b。当这些值的范围被确定之后，也就隐含地指明了估计值的不确定程度。接着计算 LOC 或 FP 的期望值 E。 E ＝ （a＋4m＋b）／6 （加权平均） 确定了估算变量的期望值，就可以用作 LOC 或 FP 的生产率数据。 作为 LOC 和 FP 估算技术的一个实例，考察一个为计算机辅助设计（CAD）应用而开发 的软件包。在这个实例中，使用 LOC 做为估算变量。 根据对软件范围的叙述，对软件功能进行分解，识别出主要的几个功能：用户界面和控 制功，二维几何分析，三维几何分析，数据库管理，计算机图形显示功能，外设控制以及设 计分析模块。通过下述的分解技术，可得到如表 9.5 所示的估算表。 表 9.5 估算表 a 最佳值 m 可能值 b 悲观值 E 期望值 每行成本 (元∕行) 生产率 (行∕PM) 成本 (元) 工作量 (PM) 用户接口控制 1800 2400 2650 2340 14 315 32760 7.4 二维几何造型 4100 5200 7400 5380 20 220 107600 24.4 三维几何造型 4600 6900 8600 6800 20 220 136000 30.9 数据库管理 2950 3400 3600 3350 18 240 60300 13.9 终端图形显示 4050 4900 6200 4950 22 200 108900 24.7 外部设备控制 2000 2100 2450 2140 28 140 59920 15.2 设计分析 6600 8500 9800 8400 18 300 151200 28.0 总计 33360 656680 144.5 表中给出了 LOC 的估算范围。计算出的各功能的期望值放入表中的第 4 列。然后对该 功 能
列垂直求和,得到该CAD系统的LOC估算值33360。 从历史数据求出生产率度量和每行成本,即行/PM和元/行。在表中的成本和工作量 这两列的值分别用LOC的期望值E与元/行相乘,及用LOC的期望值E与行/PM相除得 到。因此可得,该项目总成本的估算值为657,000元,总工作量的估算值为145人月(PM)。 ②工作量估算 每一项目任务的解决都需要花费若干人日、人月或人年。每一个工作量单位都对应于 定的货币成本,从而可以由此做出成本估 表96工作量矩阵 算。 类似于LOC或FP技术,工作量估算 任务总计 开始于从软件项目范围抽出软件功能。接 着给出为实现每一软件功能所必须执行的 系列软件工程任务,包括需求分析、设 功能 计、编码和测试。表9.6中的表格部分表 (人月 示各个软件功能和相关的软件工程任务 总计 计划人员针对每一软件功能,估算完费用率(元 成各个软件工程任务所需要的工作量(如 戎本(元) 人月),并记在表96表格的中心部分。同 时,把劳动费用率(即单位工作量成本)加 到每个软件工程任务上。最后,计算每一个功能及软件工程任务的工作量和成本。如果工作 量估算不依赖LOC或FP估算,那么,就可得到两组能进行比较和调和的成本与工作量估算 如果这两组估算值合理地一致,则估算值是可靠的。如果估算的结果不一致,就有必要做进 步的检查与分析。 以上面所介绍的CAD软件为例,列出它的一个完全的工作量估算表(如表9.7所示) 表中对每一个软件功能提供了用人月(PM)表示的每一项软件工程任务的工作量估算值。横向 和纵向的总计给出所需要的工作量。 表97工作量估算表 任务需求分析设计 编码测试总计 用户接口控制 二维几何造型 维几何造型 31.5 数据库管理 图形显示功能 10.5 27 外设控制功能 总工作 设计分析功能 140 量估算 50.5 费用率(元) 4250 总成本 成本(元) 92800 112625 除特别指出外,工作量都按人月(PM)估算 与每个软件工程任务相关的劳动费用率记入表中费用率(元)这一行,这些数据反映了 负担”的劳动成本,即包括公司开销在内的劳动成本 如果工作量估算法与LOC估算法所得结果之间的一致性很差,就必须重新确定估算所
12 表 9.6 工作量矩阵 列垂直求和，得到该 CAD 系统的 LOC 估算值 33360。 从历史数据求出生产率度量和每行成本，即行／PM 和元／行。在表中的成本和工作量 这两列的值分别用 LOC 的期望值 E 与元／行相乘，及用 LOC 的期望值 E 与行／PM 相除得 到。因此可得，该项目总成本的估算值为 657,000 元，总工作量的估算值为 145 人月(PM）。 ② 工作量估算 每一项目任务的解决都需要花费若干人日、人月或人年。每一个工作量单位都对应于一 定的货币成本，从而可以由此做出成本估 算。 类似于 LOC 或 FP 技术，工作量估算 开始于从软件项目范围抽出软件功能。接 着给出为实现每一软件功能所必须执行的 一系列软件工程任务，包括需求分析、设 计、编码和测试。表 9.6 中的表格部分表 示各个软件功能和相关的软件工程任务。 计划人员针对每一软件功能，估算完 成各个软件工程任务所需要的工作量(如 人月)，并记在表 9.6 表格的中心部分。同 时，把劳动费用率(即单位工作量成本)加 到每个软件工程任务上。最后，计算每一个功能及软件工程任务的工作量和成本。如果工作 量估算不依赖 LOC 或 FP 估算，那么，就可得到两组能进行比较和调和的成本与工作量估算。 如果这两组估算值合理地一致，则估算值是可靠的。如果估算的结果不一致，就有必要做进 一步的检查与分析。 以上面所介绍的 CAD 软件为例，列出它的一个完全的工作量估算表(如表 9.7 所示)。 表中对每一个软件功能提供了用人月(PM)表示的每一项软件工程任务的工作量估算值。横向 和纵向的总计给出所需要的工作量。 表 9.7 工作量估算表 任务 功能 用户接口控制 1.0 2.0 0.5 3.5 7.0 二维几何造型 2.0 10.0 4.5 9.5 26.0 三维几何造型 2.5 12.0 6.0 11.0 31.5 数据库管理 2.0 6.0 3.0 4.5 15.0 图形显示功能 1.5 11.0 4.0 10.5 27.5 外设控制功能 1.5 6.0 3.5 5.0 16.0 设计分析功能 4.0 14.0 5.0 7.0 30.0 总计 14.5 61.0 26.5 50.5 152.5 费用率(元) 5200 4800 4250 4500 成本(元) 75400 292800 112625 227250 708075 除特别指出外，工作量都按人月(PM)估算。 与每个软件工程任务相关的劳动费用率记入表中费用率(元)这一行，这些数据反映了 “负担”的劳动成本，即包括公司开销在内的劳动成本。 如果工作量估算法与 LOC 估算法所得结果之间的一致性很差，就必须重新确定估算所 需求分析 设 计 编 码 测 试 总 计 总工作 量估算 总成本 估算
使用的信息。如果要追寻产生差距的原因,不外乎以下两个原因之一: 计划人员没有充分了解或误解了项目的范围 用于LOC估算的生产率数据不适合于本项目,过时了(即使用这些数据不能正确反映 软件开发机构的情况),或者是误用了。 计划人员必须确定产生差距的原因再来协调估算结果 5、软件开发成本估算 软件开发成本主要是指软件开发过程中所花费的工作量及相应的代价。它不同于其它物 理产品的成本,它不包括原材料和能源的消耗,主要是人的劳动的消耗。人的劳动消耗所需 代价就是软件产品的开发成本。另一方面,软件产品开发成本的计算方法不同于其它物理产 品成本的计算。软件产品不存在重复制造过程,它的开发成本是以一次性开发过程所花费的 代价来计算的。因此软件开发成本的估算,应是从软件计划、需求分析、设计、编码、单元 测试、组装测试到确认测试,整个软件开发全过程所花费的代价作为依据的 (1)软件开发成本估算方法 对于一个大型的软件项目,要进行一系列的估算处理。主要靠分解和类推的手段进行 基本估算方法分为三类 ①自顶向下的估算方法:这种方法的主要思想是从项目的整体出发,进行类推。即估 算人员根据以前已完成项目所消耗的总成本(或总工作量),来推算将要开发的软件的总成本 (或总工作量),然后按比例将它分配到各开发任务单元中去。 这种方法的优点是估算工作量小,速度快。缺点是对项目中的特殊困难估计不足,估算 出来的成本盲目性大,有时会遗漏被开发软件的某些部分 ②自底向上的估计法:这种方法的主要思想是把待开发的软件细分,直到每一个子任 务都已经明确所需要的开发工作量,然后把它们加起来,得到软件开发的总工作量。这是一 种常见的估算方法。它的优点是估算各个部分的准确性高。缺点是缺少各项子任务之间相互 联系所需要的工作量,还缺少许多与软件开发有关的系统级工作量(配置管理、质量管理、 项目管理)。所以往往估算值偏低,必须用其它方法进行检验和校正 ③差别估计法:这种方法综合了上述两种方法的优点,其主要思想是把待开发的软件 项目与过去已完成的软件项目进行类比,从其开发的各个子任务中区分出类似的部分和不同 的部分。类似的部分按实际量进行计算,不同的部分则采用相应的方法进行估算。这种的方 法的优点是可以提高估算的准确程度,缺点是不容易明确“类似”的界限 (2)专家判定技术 专家判定技术就是由多位专家进行成本估算。由于单独一位专家可能会有种种偏见,譬 如有乐观的、悲观的、要求在竞争中取胜的、让大家都高兴的种种愿望及政治因素等。因此, 最好由多位专家进行估算,取得多个估算值。Rand公司提出 Deiphi技术,作为统一专家意 见的方法。用 Deiphi技术可得到极为准确的估算值。 Deiphi技术的步骤是 ①组织者发给每位专家一份软件系统的规格说明书(略去名称和单位)和一张记录估 算值的表格,请他们进行估算 ②专家详细硏究软件规格说明书的内容,对该软件提岀三个规模的估算值,即: 该软件可能的最小规模(最少源代码行数); 该软件最可能的规模(最可能的源代码行数); b1 该软件可能的最大规模(最多源代码行数)。 无记名地填写表格,并说明做此估算的理由。在填表的过程中,专家互相不进行讨论但可以 向组织者提问
13 使用的信息。如果要追寻产生差距的原因，不外乎以下两个原因之一： ▪ 计划人员没有充分了解或误解了项目的范围； ▪ 用于 LOC 估算的生产率数据不适合于本项目，过时了(即使用这些数据不能正确反映 软件开发机构的情况)，或者是误用了。 计划人员必须确定产生差距的原因再来协调估算结果。 5、软件开发成本估算 软件开发成本主要是指软件开发过程中所花费的工作量及相应的代价。它不同于其它物 理产品的成本，它不包括原材料和能源的消耗，主要是人的劳动的消耗。人的劳动消耗所需 代价就是软件产品的开发成本。另一方面，软件产品开发成本的计算方法不同于其它物理产 品成本的计算。软件产品不存在重复制造过程，它的开发成本是以一次性开发过程所花费的 代价来计算的。因此软件开发成本的估算，应是从软件计划、需求分析、设计、编码、单元 测试、组装测试到确认测试，整个软件开发全过程所花费的代价作为依据的。 (1) 软件开发成本估算方法 对于一个大型的软件项目，要进行一系列的估算处理。主要靠分解和类推的手段进行。 基本估算方法分为三类。 ① 自顶向下的估算方法：这种方法的主要思想是从项目的整体出发，进行类推。即估 算人员根据以前已完成项目所消耗的总成本(或总工作量)，来推算将要开发的软件的总成本 (或总工作量)，然后按比例将它分配到各开发任务单元中去。 这种方法的优点是估算工作量小，速度快。缺点是对项目中的特殊困难估计不足，估算 出来的成本盲目性大，有时会遗漏被开发软件的某些部分。 ② 自底向上的估计法：这种方法的主要思想是把待开发的软件细分，直到每一个子任 务都已经明确所需要的开发工作量，然后把它们加起来，得到软件开发的总工作量。这是一 种常见的估算方法。它的优点是估算各个部分的准确性高。缺点是缺少各项子任务之间相互 联系所需要的工作量，还缺少许多与软件开发有关的系统级工作量（配置管理、质量管理、 项目管理）。所以往往估算值偏低，必须用其它方法进行检验和校正。 ③ 差别估计法：这种方法综合了上述两种方法的优点，其主要思想是把待开发的软件 项目与过去已完成的软件项目进行类比，从其开发的各个子任务中区分出类似的部分和不同 的部分。类似的部分按实际量进行计算，不同的部分则采用相应的方法进行估算。这种的方 法的优点是可以提高估算的准确程度，缺点是不容易明确“类似”的界限。 (2) 专家判定技术 专家判定技术就是由多位专家进行成本估算。由于单独一位专家可能会有种种偏见，譬 如有乐观的、悲观的、要求在竞争中取胜的、让大家都高兴的种种愿望及政治因素等。因此， 最好由多位专家进行估算，取得多个估算值。Rand 公司提出 Deiphi 技术，作为统一专家意 见的方法。用 Deiphi 技术可得到极为准确的估算值。 Deiphi 技术的步骤是： ① 组织者发给每位专家一份软件系统的规格说明书（略去名称和单位） 和一张记录估 算值的表格，请他们进行估算。 ② 专家详细研究软件规格说明书的内容，对该软件提出三个规模的估算值，即： ai ── 该软件可能的最小规模（最少源代码行数）； mi ── 该软件最可能的规模（最可能的源代码行数）； bi ── 该软件可能的最大规模（最多源代码行数）。 无记名地填写表格，并说明做此估算的理由。在填表的过程中，专家互相不进行讨论但可以 向组织者提问
③组织者对专家们填在表格中的答复进行整理,做以下事情: a)计算各位专家(序号为i,i=1,2…n,共n位专家)的估算期望值E1,并综合各 位专家估算值的期望中值E: E.=a+4m1+b E=∑E b)对专家的估算结果进行分类摘要。 ④在综合专家估算结果的基础上,组织专家再次无记名地填写表格。然后比较两次估 算的结果。若差异很大,则要通过查询找出差异的原因, ⑤上述过程可重复多次。最终可获得一个得到多数专家共识的软件规模(源代码行数)。 在此过程中不得进行小组讨论 最后,通过与历史资料进行类比,根据过去完成软件项目的规模和成本等信息,推算出 该软件每行源代码所需要的成本。然后再乘以该软件源代码行数的估算值,就可得到该软件 的成本估算值 此方法的缺点是人们无法利用其他参加者的估算值来调整自己的估算值。宽带 Deiphi 技术克服了这个缺点。在专家正式将估算值填入表格之前,由组织者召集小组会议,专家们 与组织者一起对估算问题进行讨论,然后专家们再无记名填表。组织者对各位专家在表中填 写的估算值进行综合和分类后,再召集会议,请专家们对其估算值有很大变动之处进行讨论, 请专家们重新无记名填表。这样适当重复几次,得到比较准确的估计值 由于增加了协商的机会,集思广益,使得估算值更趋于合理。 3)软件开发成本估算的早期经验模型 软件开发成本估算是依据开发成本估算模型进行估算的。开发成本估算模型通常采用经 验公式来预测软件项目计划所需要的成本、工作量和进度数据。还没有一种估算模型能够适 用于所有的软件类型和开发环境,从这些模型中得到的结果必须慎重使用 ①IBM模型 1977年,IBM的 Walston和Felⅸx提出了如下的估算公式: E=5.2×L091,L是源代码行数(以KLOC计),E是工作量(以PM计) D=41×L036=1447×E03,D是项目持续时间(以月计) S=0.54×E06,S是人员需要量(以人计) DOC=49×101。DOC是文档数量(以页计) 在此模型中,一般指一条机器指令为一行源代码。一个软件的源代码行数不包括程序注 释、作业命令、调试程序在内。对于非机器指令编写的源程序,例如汇编语言或高级语言程 序,应转换成机器指令源代码行数来考虑。 IBM模型是一个静态单变量模型,但不是一个通用的公式。在应用中有时要根据具体 实际情况,对公式中的参数进行修改。这种修改必须拥有足够的历史数据,在明确局部的环 境之后才能做出。 ② Putnam模型 这是1978年 Putnam提出的模型,是一种动态多变量模型。它是假定在软件开发的整个 生存期中工作量有特定的分布。这种模型是依据在一些大型项目(总工作量达到或超过30个 人年)中收集到的工作量分布情况而推导出来的,但也可以应用在一些较小的软件项目中。 Putnam模型可以导出一个“软件方程”,把已交付的源代码(源语句)行数与工作量和开 发时间联系起来。其中,ld是开发持续时间(以年计),K是软件开发与维护在内的整个生存 期所花费的工作量(以人年计),L是源代码行数(以LOC计),Ck是技术状态常数,它反映 出“妨碍程序员进展的限制”,并因开发环境而异。其典型值的选取如表9.8所示。 14
14 ③ 组织者对专家们填在表格中的答复进行整理，做以下事情： a) 计算各位专家（序号为 i，i＝1,2,…,n，共 n 位专家）的估算期望值 Ei：，并综合各 位专家估算值的期望中值 E： 6 a 4m b E i i i i + + = = = n i 1 Ei n 1 E b) 对专家的估算结果进行分类摘要。 ④ 在综合专家估算结果的基础上，组织专家再次无记名地填写表格。 然后比较两次估 算的结果。若差异很大，则要通过查询找出差异的原因。 ⑤ 上述过程可重复多次。最终可获得一个得到多数专家共识的软件规模（源代码行数）。 在此过程中不得进行小组讨论。 最后，通过与历史资料进行类比，根据过去完成软件项目的规模和成本等信息，推算出 该软件每行源代码所需要的成本。然后再乘以该软件源代码行数的估算值，就可得到该软件 的成本估算值。 此方法的缺点是人们无法利用其他参加者的估算值来调整自己的估算值。宽带 Deiphi 技术克服了这个缺点。在专家正式将估算值填入表格之前，由组织者召集小组会议，专家们 与组织者一起对估算问题进行讨论，然后专家们再无记名填表。组织者对各位专家在表中填 写的估算值进行综合和分类后，再召集会议，请专家们对其估算值有很大变动之处进行讨论， 请专家们重新无记名填表。这样适当重复几次，得到比较准确的估计值。 由于增加了协商的机会，集思广益，使得估算值更趋于合理。 (3) 软件开发成本估算的早期经验模型 软件开发成本估算是依据开发成本估算模型进行估算的。开发成本估算模型通常采用经 验公式来预测软件项目计划所需要的成本、工作量和进度数据。还没有一种估算模型能够适 用于所有的软件类型和开发环境，从这些模型中得到的结果必须慎重使用。 ① IBM 模型 1977 年，IBM 的 Walston 和 Felix 提出了如下的估算公式： E ＝ 5.2×L0.91， L 是源代码行数(以 KLOC 计)，E 是工作量(以 PM 计) D ＝ 4.1×L0.36 ＝ 14.47×E0.35， D 是项目持续时间(以月计) S ＝ 0.54×E0.6， S 是人员需要量(以人计) DOC ＝ 49×L1.01。 DOC 是文档数量(以页计) 在此模型中，一般指一条机器指令为一行源代码。一个软件的源代码行数不包括程序注 释、作业命令、调试程序在内。对于非机器指令编写的源程序，例如汇编语言或高级语言程 序，应转换成机器指令源代码行数来考虑。 IBM 模型是一个静态单变量模型，但不是一个通用的公式。 在应用中有时要根据具体 实际情况，对公式中的参数进行修改。这种修改必须拥有足够的历史数据，在明确局部的环 境之后才能做出。 ② Putnam 模型 这是 1978 年 Putnam 提出的模型，是一种动态多变量模型。它是假定在软件开发的整个 生存期中工作量有特定的分布。这种模型是依据在一些大型项目(总工作量达到或超过 30 个 人年)中收集到的工作量分布情况而推导出来的，但也可以应用在一些较小的软件项目中。 Putnam 模型可以导出一个“软件方程”，把已交付的源代码(源语句)行数与工作量和开 发时间联系起来。其中，td 是开发持续时间(以年计)，K 是软件开发与维护在内的整个生存 期所花费的工作量(以人年计)，L 是源代码行数(以 LOC 计)，Ck 是技术状态常数，它反映 出“妨碍程序员进展的限制”，并因开发环境而异。其典型值的选取如表 9.8 所示。 L = Ck K td 1 3 4 3
表98技术状态常数Ck的取值 Ck的典型值开发环境 开发环境举例 没有系统的开发方法,缺乏文档和复审,批处理方式。 好。有合适的系统开发方法有充分的文档和复审,交互执行方式 11000 有自动开发工具和技术 (4) COCOMO模型( COnstructive COst MOdel) 这是由TRW公司开发。 Boehm提出的结构型成本估算模型。是一种精确、易于使用的 成本估算方法。在该模型中使用的基本量有以下几个:DSI(源指令条数)定义为代码或卡 片形式的源程序行数。若一行有两个语句,则算做一条指令。它包括作业控制语句和格式语 句,但不包括注释语句。KDSI=100DSI。MM(度量单位为人月)表示开发工作量。TDEV (度量单位为月)表示开发进度。它由工作量决定 ①软件开发项目的分类 在 COCOMO模型中,考虑开发环境,软件开发项目的总体类型可分为三种:组织型 ( Organic)、嵌入型( Embedded)和介于上述两种软件之间的半独立型( Semidetached)。 ② COCOMO模型的分类 CO℃OMO模型按其详细程度分成三级:即基本 COCOMO模型、中间 COCOMO模型、 详细 COCOMO模型。基本 COCOMO模型是一个静态单变量模型,它用一个以已估算出来 的源代码行数(LOC)为自变量的(经验)函数来计算软件开发工作量。中间 COCOMO模型则 在用LOC为自变量的函数计算软件开发工作量(此时称为名义工作量)的基础上,再用涉及产 品、硬件、人员、项目等方面属性的影响因素来调整工作量的估算。详细 COCOMO模型包 括中间 COCOMO模型的所有特性,但用上述各种影响因素调整工作量估算时,还要考虑对 软件工程过程中每一步骤(分析、设计等)的影响 ③基本 COCOMO模型 基本 COCOMO模型的工作量和进度公式如表99所示。 表99基本 COCOMO模型的工作量和进度公式 总体类型 工作量 组织型 MM=2.4(KDSI)I.05 TDEV=2.5(MM)0.38 半独立型 MM MM=36(KDSI)1-20 TDEV=2.5(MM)0.32 利用上面公式,可求得软件项目,或分阶段求得各软件任务的开发工作量和开发进度 ④中间 COCOMO模型 进一步考虑以下15种影响软件工作量的因素,通过定下乘法因子,修正 COCOMO工 作量公式和进度公式,可以更合理地估算软件(各阶段)的工作量和进度 中间 COCOMO模型的名义工作量与进度公式如表9.10所示 表910中间 COCOMO模型的名义工作量与进度公式 总体类型 工作量 组织型 MM=3.2(KDSD)05 TDEV=2.5(MM)0.38 半独立型 MM=3.0(KDSI)L12 TDEV=2.5(MM)O35 嵌入型 MM=2.8 (KDSD)20 TDEV=2.5(MM)0.32
15 表 9.8 技术状态常数 Ck 的取值 Ck 的典型值 开发环境 开 发 环 境 举 例 2000 差 没有系统的开发方法，缺乏文档和复审，批处理方式。 8000 好 有合适的系统开发方法，有充分的文档和复审，交互执行方式。 11000 优 有自动开发工具和技术。 (4) COCOMO 模型（COnstructive COst MOdel） 这是由 TRW 公司开发。Boehm 提出的结构型成本估算模型。是一种精确、易于使用的 成本估算方法。在该模型中使用的基本量有以下几个：DSI（源指令条数）定义为代码或卡 片形式的源程序行数。若一行有两个语句，则算做一条指令。它包括作业控制语句和格式语 句，但不包括注释语句。KDSI＝1000DSI。MM（度量单位为人月）表示开发工作量。TDEV （度量单位为月）表示开发进度。它由工作量决定。 ① 软件开发项目的分类 在 COCOMO 模型中，考虑开发环境，软件开发项目的总体类型可分为三种：组织型 (Organic)、嵌入型(Embadded)和介于上述两种软件之间的半独立型(Semidetached)。 ② COCOMO 模型的分类 COCOMO 模型按其详细程度分成三级：即基本 COCOMO 模型、中间 COCOMO 模型、 详细 COCOMO 模型。基本 COCOMO 模型是一个静态单变量模型，它用一个以已估算出来 的源代码行数(LOC)为自变量的(经验)函数来计算软件开发工作量。中间 COCOMO 模型则 在用 LOC 为自变量的函数计算软件开发工作量(此时称为名义工作量)的基础上，再用涉及产 品、硬件、人员、项目等方面属性的影响因素来调整工作量的估算。详细 COCOMO 模型包 括中间 COCOMO 模型的所有特性，但用上述各种影响因素调整工作量估算时，还要考虑对 软件工程过程中每一步骤(分析、设计等)的影响。 ③ 基本 COCOMO 模型 基本 COCOMO 模型的工作量和进度公式如表 9.9 所示。 表 9.9 基本 COCOMO 模型的工作量和进度公式 总体类型 工 作 量 进 度 组 织 型 MM ＝2.4 (KDSI)1.05 TDEV＝2.5 (MM)0.38 半独立型 MM ＝3.0 (KDSI)1.12 TDEV＝2.5 (MM)0.35 嵌 入 型 MM ＝3.6 (KDSI)1.20 TDEV＝2.5 (MM)0.32 利用上面公式，可求得软件项目，或分阶段求得各软件任务的开发工作量和开发进度。 ④ 中间 COCOMO 模型 进一步考虑以下 15 种影响软件工作量的因素，通过定下乘法因子，修正 COCOMO 工 作量公式和进度公式，可以更合理地估算软件(各阶段)的工作量和进度。 中间 COCOMO 模型的名义工作量与进度公式如表 9.10 所示。 表 9.10 中间 COCOMO 模型的名义工作量与进度公式 总体类型 工 作 量 进 度 组 织 型 MM＝3.2 (KDSI)1.05 TDEV＝2.5 (MM)0.38 半独立型 MM＝3.0 (KDSI)1.12 TDEV＝2.5 (MM)0.35 嵌 入 型 MM＝2.8 (KDSI)1.20 TDEV＝2.5 (MM)0.32