软件项目估计:第2版
基本信息
- 作者: (美)Capers Jones [作译者介绍]
- 译者: 刘从越 郝建材 申冬凯
- 丛书名: 软件工程研究院
- 出版社:电子工业出版社
- ISBN:9787121058066
- 上架时间:2008-3-26
- 出版日期:2008 年3月
- 开本:16开
- 页码:475
- 版次:1-1
- 所属分类:
计算机 > 软件工程及软件方法学 > 软件项目管理
编辑推荐
“Capers Jones的工作为从经济学的角度理解软件生产做出了不同寻常的贡献,揭示了计算与作为计算的推动力的软件这二者之间发展不平衡的深层次的原因。对于希望了解技术进展的局限性的读者,此书不可不读。”
——Paul A. Strassmann,Xerox公司,美国国防部和国家航空航天局前CIO
内容简介回到顶部↑
按计划、按预算交付无缺陷的软件
本书将使您清晰、全面地了解如何利用书中提供的实际的信息来估计软件项目的成本、进度和质量,并使您学会如何选择正确的硬件和软件工具,制定评价策略,部署测试和原型,以及进行精确的软件成本估计。此外,本书还将全面为您介绍采用java、面向对象方法和可重用组件的前沿的估计方法。
●策划并进行项目级、阶段级、活动级估计
●对回归测试、部件测试、集成测试和压力测试进行估计
●修正数据收集、计算和分析时出现的误差
●评估交付的软件产品和数据的复杂度
●测试设计原理和使用软件原型的工作特性
●估计配置变更、研究、质量控制和文档的成本
本书将使您清晰、全面地了解如何利用书中提供的实际的信息来估计软件项目的成本、进度和质量,并使您学会如何选择正确的硬件和软件工具,制定评价策略,部署测试和原型,以及进行精确的软件成本估计。此外,本书还将全面为您介绍采用java、面向对象方法和可重用组件的前沿的估计方法。
●策划并进行项目级、阶段级、活动级估计
●对回归测试、部件测试、集成测试和压力测试进行估计
●修正数据收集、计算和分析时出现的误差
●评估交付的软件产品和数据的复杂度
●测试设计原理和使用软件原型的工作特性
●估计配置变更、研究、质量控制和文档的成本
目录回到顶部↑
第1篇 软件项目评估介绍
第1章 介绍
第2章 软件项目评估的起源
第3章 软件项目评估的6种方法
第4章 软件项目评估工具以及项目的成功率和失败率
第5章 软件项目评估错误的来源
第2篇 初步评估方法
第6章 手工软件评估方法
第7章 源于敏捷项目和新环境的手工评估方法
第8章 基于最少数据的自动评估
第3篇 软件交付产品规模评估
第9章 软件交付产品规模评估
第4篇 项目评估调整因素
第10章 薪酬和工作模式调整
第11章 活动模式调整因素
第12章 软件技术调整因素
第5篇 基于活动的
第13章 软件需求评估
第14章 软件原型评估
第15章 软件规格说明和设计评估
第1章 介绍
第2章 软件项目评估的起源
第3章 软件项目评估的6种方法
第4章 软件项目评估工具以及项目的成功率和失败率
第5章 软件项目评估错误的来源
第2篇 初步评估方法
第6章 手工软件评估方法
第7章 源于敏捷项目和新环境的手工评估方法
第8章 基于最少数据的自动评估
第3篇 软件交付产品规模评估
第9章 软件交付产品规模评估
第4篇 项目评估调整因素
第10章 薪酬和工作模式调整
第11章 活动模式调整因素
第12章 软件技术调整因素
第5篇 基于活动的
第13章 软件需求评估
第14章 软件原型评估
第15章 软件规格说明和设计评估
前言回到顶部↑
从本书第1版到第2版的十年间,计算机行业和软件项目估计技术均发生了很大的变化。.
20多种新的开发方法相继涌现,包括大量的“敏捷”开发,面向对象方法也日渐普及,用例和统一建模语言(UML)成为主流的软件设计方法,软件工程研究所(SEI)发布了新的集成能力成熟度模型(CMMI)。所有这些新方法均应用在需要进行精确的成本和进度估计的软件项目中。
部分新方法已经产生了新的用于估计和测量的度量指标。因此,现在的软件项目经理不仅要懂得代码行和功能点度量,还要了解COSMIC功能点、工程功能点、对象点、故事点、Web对象点、用例点及其他30多种度量指标。然而,这些新的度量指标仍处于试验阶段,缺乏大量的历史数据的支撑。标准功能点度量已用于25 000多个软件项目的测量。就目前了解的情况来看,采用所有其他度量的项目不超过300个,即采用每种度量的项目约有10个。
人们还开展了大量的估计方法方面的研究,以及估计不准确的原因方面的研究。尽管估计错误仍然普遍存在,但我们现在已知道了引发这些错误的4个主要原因:
●开发过程中,软件项目以每月2%的速度增长;
●大量的Bug或缺陷使测试进度拖延;
●生成纸质文档的成本经常超过生成源代码的成本;
●随意用乐观的估计来取代精确的估计。
现在我们已经知道了造成软件项目估计错误的主要原因,就可以对它们进行控制。前3种技术原因实际上是可以消除的,但第4种原因,即随意用乐观的估计来取代精确的估计,则比较棘手。
软件估计的结果必须得到软件客户的认可,有时还需要得到高层管理者的认可。当客户和高层管理者面临紧急的业务需要时,他们通常会强烈反对精确的项目估计。这是因为开发大型的、复杂的软件应用程序是既费时又昂贵的。
因此,很多软件项目被迫使用外部的业务日期作为期限,而不是根据团队情况和技术能力进行真实的项目估计。他们还不得不在预算远低于实际需要的情况下实现所需的所有功能。这些是社会学方面的问题,很难解决。
避免精确的估计被取代的最好的解决方法就是采用类似项目的历史数据进行估计。如果历史数据证明某一类项目从未比正式项目估计的进度更早、成本更低地完成,那么估计就有可能保留下来。没有可靠的历史数据,估计就可能被放弃或被取代。这就意味着,基准或精确历史数据的收集是进行精确估计的重要前提条件。
从1971年开始,我就致力于收集历史数据,设计并构建软件项目估计工具。我在估计方面的工作始于在IBM工作的时候,当时我和另一位同事负责收集软件成本影响因素方面的数据。
我们用了一年的时间在IBM内部收集成本数据。阅读了软件成本方面的外部文献后,觉得似乎有可能开发一个用于预测IBM系统软件开发项目的主要活动(包括需求、设计、设计评审、编码、代码审查、测试、用户文档编写和项目管理)的工作量、进度和成本的基于规则的自动化估计工具。
我们向IBM的高层管理者提交了资助开发软件项目估计工具的提议。提议被采纳并于1972年启动。从那时起,我为多家公司或商用估计市场设计并实现了多个软件项目估计工具。本书旨在提供建立软件估计模型所需的信息,并从知情者的角度来介绍软件项目估计行业。
本书尽可能涵盖软件项目估计方面的基本问题,其中包括了估计和度量领域的很多专家的观点和信息,并在书中多次引用。书中介绍了Allan Albrecht,Barry Boehm博士,Frank Freiman,Don Galorath,Randall Jensen博士,Steve McConnell,Larry Putnam,Howard Rubin博士和Charles Symons等专家的工作,尽管作为竞争对手我们很少有机会分享彼此的信息。
从我和我的竞争者的角度来说,精确的软件估计对全球经济都至关重要。每个软件项目经理、每个软件质量保证专家,以及很多的软件工程师、系统分析员、编程人员都应该了解软件项目估计的基本概念。所有商品化软件项目估计开发商也都同意此观点。
商品化软件项目估计行业的所有人都了解很多手工估计算法,也都偶尔在小项目中使用过手工估计方法。但是没有人会认为手工估计方法足以进行大多数软件项目的全生存周期的估计。如果手工方法真的够用,就不会出现商品化软件估计工具。
一个有趣的现象是:大部分的软件灾难和大量超预算是由于随意的、过于乐观的项目估计所造成的,而且通常是手工估计。使用正式估计工具,如COCOMO II,GECOMO,SLIM,PRICE-S,ProQMS,SEER,SoftCost,或SPR公司的工具(SPQR/20,CHECKPOINT,或KnowledgePlan),进行估计的项目,通常会有更好的跟踪记录表明项目在预算范围内相对顺利地完成。..
可以用一个词来说明在大型系统中采用手工估计方法失败的原因:复杂性。影响软件项目结果的因素有几百个,不可能用简单的算法和手工方法对这些因素的组织进行管理。
20多种新的开发方法相继涌现,包括大量的“敏捷”开发,面向对象方法也日渐普及,用例和统一建模语言(UML)成为主流的软件设计方法,软件工程研究所(SEI)发布了新的集成能力成熟度模型(CMMI)。所有这些新方法均应用在需要进行精确的成本和进度估计的软件项目中。
部分新方法已经产生了新的用于估计和测量的度量指标。因此,现在的软件项目经理不仅要懂得代码行和功能点度量,还要了解COSMIC功能点、工程功能点、对象点、故事点、Web对象点、用例点及其他30多种度量指标。然而,这些新的度量指标仍处于试验阶段,缺乏大量的历史数据的支撑。标准功能点度量已用于25 000多个软件项目的测量。就目前了解的情况来看,采用所有其他度量的项目不超过300个,即采用每种度量的项目约有10个。
人们还开展了大量的估计方法方面的研究,以及估计不准确的原因方面的研究。尽管估计错误仍然普遍存在,但我们现在已知道了引发这些错误的4个主要原因:
●开发过程中,软件项目以每月2%的速度增长;
●大量的Bug或缺陷使测试进度拖延;
●生成纸质文档的成本经常超过生成源代码的成本;
●随意用乐观的估计来取代精确的估计。
现在我们已经知道了造成软件项目估计错误的主要原因,就可以对它们进行控制。前3种技术原因实际上是可以消除的,但第4种原因,即随意用乐观的估计来取代精确的估计,则比较棘手。
软件估计的结果必须得到软件客户的认可,有时还需要得到高层管理者的认可。当客户和高层管理者面临紧急的业务需要时,他们通常会强烈反对精确的项目估计。这是因为开发大型的、复杂的软件应用程序是既费时又昂贵的。
因此,很多软件项目被迫使用外部的业务日期作为期限,而不是根据团队情况和技术能力进行真实的项目估计。他们还不得不在预算远低于实际需要的情况下实现所需的所有功能。这些是社会学方面的问题,很难解决。
避免精确的估计被取代的最好的解决方法就是采用类似项目的历史数据进行估计。如果历史数据证明某一类项目从未比正式项目估计的进度更早、成本更低地完成,那么估计就有可能保留下来。没有可靠的历史数据,估计就可能被放弃或被取代。这就意味着,基准或精确历史数据的收集是进行精确估计的重要前提条件。
从1971年开始,我就致力于收集历史数据,设计并构建软件项目估计工具。我在估计方面的工作始于在IBM工作的时候,当时我和另一位同事负责收集软件成本影响因素方面的数据。
我们用了一年的时间在IBM内部收集成本数据。阅读了软件成本方面的外部文献后,觉得似乎有可能开发一个用于预测IBM系统软件开发项目的主要活动(包括需求、设计、设计评审、编码、代码审查、测试、用户文档编写和项目管理)的工作量、进度和成本的基于规则的自动化估计工具。
我们向IBM的高层管理者提交了资助开发软件项目估计工具的提议。提议被采纳并于1972年启动。从那时起,我为多家公司或商用估计市场设计并实现了多个软件项目估计工具。本书旨在提供建立软件估计模型所需的信息,并从知情者的角度来介绍软件项目估计行业。
本书尽可能涵盖软件项目估计方面的基本问题,其中包括了估计和度量领域的很多专家的观点和信息,并在书中多次引用。书中介绍了Allan Albrecht,Barry Boehm博士,Frank Freiman,Don Galorath,Randall Jensen博士,Steve McConnell,Larry Putnam,Howard Rubin博士和Charles Symons等专家的工作,尽管作为竞争对手我们很少有机会分享彼此的信息。
从我和我的竞争者的角度来说,精确的软件估计对全球经济都至关重要。每个软件项目经理、每个软件质量保证专家,以及很多的软件工程师、系统分析员、编程人员都应该了解软件项目估计的基本概念。所有商品化软件项目估计开发商也都同意此观点。
商品化软件项目估计行业的所有人都了解很多手工估计算法,也都偶尔在小项目中使用过手工估计方法。但是没有人会认为手工估计方法足以进行大多数软件项目的全生存周期的估计。如果手工方法真的够用,就不会出现商品化软件估计工具。
一个有趣的现象是:大部分的软件灾难和大量超预算是由于随意的、过于乐观的项目估计所造成的,而且通常是手工估计。使用正式估计工具,如COCOMO II,GECOMO,SLIM,PRICE-S,ProQMS,SEER,SoftCost,或SPR公司的工具(SPQR/20,CHECKPOINT,或KnowledgePlan),进行估计的项目,通常会有更好的跟踪记录表明项目在预算范围内相对顺利地完成。..
可以用一个词来说明在大型系统中采用手工估计方法失败的原因:复杂性。影响软件项目结果的因素有几百个,不可能用简单的算法和手工方法对这些因素的组织进行管理。
序言回到顶部↑
中国在科学和数学方面的研究可以追溯到4000多年以前, 早于除了埃及和印度以外的其他任何国家。.
在计算和数学领域,计算机科学家都知道莱布尼兹(Gottfried Leibniz)在1703年对易经中的数学所做的阐释是西方世界对二进制数的首次描述,而二进制数是计算机和软件的基础。
从某种程度来说,易经的早期历史是不明确的,但据可靠史料记载,应早于公元前8世纪。当然,也有史学家认为易经是早在公元前2852年由伏羲所作。
易经是第一个建立在非偶然的自然现象的基础之上的“计算工具”。易经的六线形模式以及卦辞深刻揭示了人类的自然和社会组织的许多现象。
易经也是计算机编码实现的最早的估计形式。20世纪70年代,易经的软件版本即已出现,早于所有的商品化估计工具。
算盘是第一个高效的机械化计算工具。在中国历史中,公元190年前后的东汉书籍中就有对算盘的早期描述。在现代的电子计算器和后来的数字计算机发明以前,算盘一直是最有效的计算工具。算盘高手的计算速度甚至会超过机械加法器的计算速度。
近年来,中国已成为世界上计算机和软件用户数最多的国家之一,而且跻身世界上最大的定制软件和商品化软件生产国之列。
中国公司现在也开始开发大规模软件应用程序,因此,他们也遇到了美国和欧洲所遇到的同样的问题,如:需求蔓延、进度严重推迟、成本超支、质量低劣,有时甚至因无法交付可运行的软件应用程序而导致项目彻底失败。
这些问题困扰着世界上每一个将计算机用于商业和政府行为,因而会依赖大型软件应用程序的国家。
本书第2版旨在提供5个重要方面的有用信息:
●如何估计软件开发的进度;
●如何估计软件开发的工作量;
●如何估计软件开发的人数;
●如何估计软件开发的成本;..
●如何估计软件开发的质量。
上述5个方面都是密切相关的。总的来说,软件进度的拖延和成本超支是因糟糕的质量控制而造成的。如果软件应用程序没有认真收集需求,没有预防缺陷发生,没有进行适当的测试,也没有测量质量,那么这个应用程序极有可能会进度拖延,成本超出预算,并最终以失败告终。
一旦投入生产后,下一个阶段便是可能持续很多年的长期的维护和改进工作。中国正在成为软件维护和改进的中心,维护和改进的对象不仅包括其自主开发的软件,还包括其他许多国家的外包软件。
从某种程度上来说,对维护和改进工作的估计比对新项目的估计更加复杂,因为软件应用程序的结构性和稳定性会随着时间的流逝而日渐降低。
尽管可以延长已运行了多年的应用程序的使用寿命,但安全地对这些应用程序进行修改的难度却在逐年提高。有些应用程序在25年之后还在继续使用,其最终寿命仍未可知。有些应用程序的寿命甚至比开发人员的寿命还要长。
软件项目估计是一项与软件测量密切相关的技术。准确地测量才能提供进行准确的项目估计所需的数据。
在计算和数学领域,计算机科学家都知道莱布尼兹(Gottfried Leibniz)在1703年对易经中的数学所做的阐释是西方世界对二进制数的首次描述,而二进制数是计算机和软件的基础。
从某种程度来说,易经的早期历史是不明确的,但据可靠史料记载,应早于公元前8世纪。当然,也有史学家认为易经是早在公元前2852年由伏羲所作。
易经是第一个建立在非偶然的自然现象的基础之上的“计算工具”。易经的六线形模式以及卦辞深刻揭示了人类的自然和社会组织的许多现象。
易经也是计算机编码实现的最早的估计形式。20世纪70年代,易经的软件版本即已出现,早于所有的商品化估计工具。
算盘是第一个高效的机械化计算工具。在中国历史中,公元190年前后的东汉书籍中就有对算盘的早期描述。在现代的电子计算器和后来的数字计算机发明以前,算盘一直是最有效的计算工具。算盘高手的计算速度甚至会超过机械加法器的计算速度。
近年来,中国已成为世界上计算机和软件用户数最多的国家之一,而且跻身世界上最大的定制软件和商品化软件生产国之列。
中国公司现在也开始开发大规模软件应用程序,因此,他们也遇到了美国和欧洲所遇到的同样的问题,如:需求蔓延、进度严重推迟、成本超支、质量低劣,有时甚至因无法交付可运行的软件应用程序而导致项目彻底失败。
这些问题困扰着世界上每一个将计算机用于商业和政府行为,因而会依赖大型软件应用程序的国家。
本书第2版旨在提供5个重要方面的有用信息:
●如何估计软件开发的进度;
●如何估计软件开发的工作量;
●如何估计软件开发的人数;
●如何估计软件开发的成本;..
●如何估计软件开发的质量。
上述5个方面都是密切相关的。总的来说,软件进度的拖延和成本超支是因糟糕的质量控制而造成的。如果软件应用程序没有认真收集需求,没有预防缺陷发生,没有进行适当的测试,也没有测量质量,那么这个应用程序极有可能会进度拖延,成本超出预算,并最终以失败告终。
一旦投入生产后,下一个阶段便是可能持续很多年的长期的维护和改进工作。中国正在成为软件维护和改进的中心,维护和改进的对象不仅包括其自主开发的软件,还包括其他许多国家的外包软件。
从某种程度上来说,对维护和改进工作的估计比对新项目的估计更加复杂,因为软件应用程序的结构性和稳定性会随着时间的流逝而日渐降低。
尽管可以延长已运行了多年的应用程序的使用寿命,但安全地对这些应用程序进行修改的难度却在逐年提高。有些应用程序在25年之后还在继续使用,其最终寿命仍未可知。有些应用程序的寿命甚至比开发人员的寿命还要长。
软件项目估计是一项与软件测量密切相关的技术。准确地测量才能提供进行准确的项目估计所需的数据。
媒体评论回到顶部↑
“Capers Jones的工作为从经济学的角度理解软件生产做出了不同寻常的贡献,揭示了计算与作为计算的推动力的软件这二者之间发展不平衡的深层次的原因。对于希望了解技术进展的局限性的读者,此书不可不读。”
——Paul A. Strassmann,Xerox公司,美国国防部和国家航空航天局前CIO ...
——Paul A. Strassmann,Xerox公司,美国国防部和国家航空航天局前CIO ...
书摘回到顶部↑
第1章 介绍
从20世纪40年代计算机诞生至今,软件项目估计一直是一项重要而又艰巨的任务。随着软件应用程序规模和重要性的不断增加,人们对软件项目估计准确度的要求也在不断提高。.
在软件业的早期,计算机程序的规模通常不到1 000条机器指令(或者说少于30个功能点),一名编程人员在不到一个月的时间内即可完成编码,开发的总成本通常低于5 000美元。虽然项目估计做起来很困难,但项目估计的错误并不会带来严重的经济后果。
而如今,一些大型软件系统的源代码已超过2500万行源代码语句(或者说大于30万个功能点),可能需要1 000多名技术人员用5年多的时间来完成,开发成本会超过5亿美元。因此,现在软件项目估计如果出现错误势必造成重大的损失。
更为严重的是,相当一部分的大型软件系统会因为估计的原因而进度延迟、预算超支,甚至由于需求阶段的估计严重过低而导致项目被终止。实际上,过于乐观的软件项目估计一直是造成进度延迟、成本超支、项目失败及引发诉讼的主要原因之一。
如今,软件已成为现代商业、政府和军事行动的主要驱动力之一。这意味着一个“财富500强”的企业或政府机构每年要开发数百个新的应用程序或修改几百个已有的应用程序。软件在现代社会中所占的主导地位使得软件项目估计也成为每个软件开发公司的主要活动之一。
除了用于日常的业务活动外,软件项目估计也成为诉讼的主要因素。在过去的15年中,作者及其同事研究了大量由原告、被告或双方进行软件项目估计的诉讼案。例如,软件项目估计目前在涉及下列争议的诉讼案中起着关键作用:
·客户和承包方之间的违约诉讼案;..
·软件资产的应税价值诉讼案;
·范围扩展所引起的军用软件成本超支赔偿诉讼案;
·软件合同发布中的特惠诉讼案;
·软件人员不正当终止合同的诉讼案。
综上所述,软件在当今时代的普及已使软件项目估计成为21世纪的关键技术之一。
1.1 软件项目估计计工具的工作原理
1.1.1 软件项目估计工具
有经验的项目经理可以使用多种自动化工具来估计软件项目的成本、进度和资源。例如,一名经验丰富的软件项目经理可使用下面任意一种工具来进行项目估计,并制订进度计划:
·电子表格;
·项目管理工具;
·软件项目估计工具。
软件项目估计工具开发商经常被问及的一个问题是:“我们已经有了电子表格和项目管理工具,为什么还需要你们的工具?”
从20世纪40年代计算机诞生至今,软件项目估计一直是一项重要而又艰巨的任务。随着软件应用程序规模和重要性的不断增加,人们对软件项目估计准确度的要求也在不断提高。.
在软件业的早期,计算机程序的规模通常不到1 000条机器指令(或者说少于30个功能点),一名编程人员在不到一个月的时间内即可完成编码,开发的总成本通常低于5 000美元。虽然项目估计做起来很困难,但项目估计的错误并不会带来严重的经济后果。
而如今,一些大型软件系统的源代码已超过2500万行源代码语句(或者说大于30万个功能点),可能需要1 000多名技术人员用5年多的时间来完成,开发成本会超过5亿美元。因此,现在软件项目估计如果出现错误势必造成重大的损失。
更为严重的是,相当一部分的大型软件系统会因为估计的原因而进度延迟、预算超支,甚至由于需求阶段的估计严重过低而导致项目被终止。实际上,过于乐观的软件项目估计一直是造成进度延迟、成本超支、项目失败及引发诉讼的主要原因之一。
如今,软件已成为现代商业、政府和军事行动的主要驱动力之一。这意味着一个“财富500强”的企业或政府机构每年要开发数百个新的应用程序或修改几百个已有的应用程序。软件在现代社会中所占的主导地位使得软件项目估计也成为每个软件开发公司的主要活动之一。
除了用于日常的业务活动外,软件项目估计也成为诉讼的主要因素。在过去的15年中,作者及其同事研究了大量由原告、被告或双方进行软件项目估计的诉讼案。例如,软件项目估计目前在涉及下列争议的诉讼案中起着关键作用:
·客户和承包方之间的违约诉讼案;..
·软件资产的应税价值诉讼案;
·范围扩展所引起的军用软件成本超支赔偿诉讼案;
·软件合同发布中的特惠诉讼案;
·软件人员不正当终止合同的诉讼案。
综上所述,软件在当今时代的普及已使软件项目估计成为21世纪的关键技术之一。
1.1 软件项目估计计工具的工作原理
1.1.1 软件项目估计工具
有经验的项目经理可以使用多种自动化工具来估计软件项目的成本、进度和资源。例如,一名经验丰富的软件项目经理可使用下面任意一种工具来进行项目估计,并制订进度计划:
·电子表格;
·项目管理工具;
·软件项目估计工具。
软件项目估计工具开发商经常被问及的一个问题是:“我们已经有了电子表格和项目管理工具,为什么还需要你们的工具?”

点击看大图

加载中...
