软件估算--“黑匣子”揭秘
点击看大图基本信息
- 作者： (美)Steve McConnell [作译者介绍]
- 译者： 宋锐
- 出版社：电子工业出版社
- ISBN：9787121052958
- 上架时间：2007-12-7
- 出版日期：2007 年12月
- 开本：16开
- 页码：324
- 版次：1-1
- 所属分类：
计算机 > 软件工程及软件方法学 > 软件质量、软件测试及维护
合作专区 > 微软技术图书 > 微软程序设计
编辑推荐
本书荣获Software Development Magazine 2007生产力大奖，两届Software Development Magazine软件开发书籍震撼大奖得主！
内容简介回到顶部↑
在《软件估算——“黑匣子”揭秘》一书中，著名的软件开发书籍的作者steve mcconnell揭开了围绕在软件估算周围的层层迷雾。作者在深入浅出地介绍了与软件估算有关的主要概念之后，深入、全面地介绍了与软件估算有关的多种估算方法。
本书的主要内容包括：估算与计划和项目控制，以及估算与目标和承诺之间的关系；不确定性锥与估算中的误差来源以及影响估算的各种因素；先计数、再计算，无法可想时才依靠判断的基本估算原则；用于估算软件项目的三个重要部分——规模、工作量和进度估算的基本方法；与规模、工作量和进度估算有关的特殊问题；估算的概率论观点以及如何采用适当的方式来表达估算结果中的不确定性；如何进行与估算有关的沟通，从而使技术人员和非技术人员达成共识。
本书主要面向软件开发项目中要进行估算的开发人员和技术管理人员。但本书所涉及的与软件估算有关的背景知识，以及有关估算谈判和表达方式的讨论，对于非技术人员出身的主管和项目的其他有关人员同样大有裨益。
本书的主要内容包括：估算与计划和项目控制，以及估算与目标和承诺之间的关系；不确定性锥与估算中的误差来源以及影响估算的各种因素；先计数、再计算，无法可想时才依靠判断的基本估算原则；用于估算软件项目的三个重要部分——规模、工作量和进度估算的基本方法；与规模、工作量和进度估算有关的特殊问题；估算的概率论观点以及如何采用适当的方式来表达估算结果中的不确定性；如何进行与估算有关的沟通，从而使技术人员和非技术人员达成共识。
本书主要面向软件开发项目中要进行估算的开发人员和技术管理人员。但本书所涉及的与软件估算有关的背景知识，以及有关估算谈判和表达方式的讨论，对于非技术人员出身的主管和项目的其他有关人员同样大有裨益。
作译者回到顶部↑
本书提供作译者介绍
Steve McConnell被认为是软件开发群体中最主要的作者和明星代言人之一。他是Construx Software公司的首席软件工程师，是Construx Estimate和SPC Estimate Professiona产品的开发负责人，后一个产品获得过Software Development杂志的生产力大奖。他还是多本书籍的作者，其作品包括Code Complete和Rapid Development，这两本书获得了Software Development杂志软件开发书籍震撼大奖。.
如果想获得更多开发人员学习所需的资料，请访问：microsoft．com／mspress。...
.. << 查看详细
如果想获得更多开发人员学习所需的资料，请访问：microsoft．com／mspress。...
.. << 查看详细
目录回到顶部↑
第一部分 估算的关键概念
第1章 “估算”的含义
第2章 你的估算水平如何
第3章 准确估算的价值
第4章 估算误差的来源
第5章 影响估算的因素
第二部分 基本估算方法
第6章 估算方法概述
第7章 计数、计算和判断
第8章 估算校准和历史数据
第9章 专家的个人判断
第10章 分解和重组
第11章 类比估算
第12章 基于代理的估算
第13章 专家小组判断法
第14章 软件估算工具
第15章 使用多种估算方法
第16章 获得良好估算的软件项目中的估算流程
第17章 标准化估算规程
第三部分 特定的估算挑战
第1章 “估算”的含义
第2章 你的估算水平如何
第3章 准确估算的价值
第4章 估算误差的来源
第5章 影响估算的因素
第二部分 基本估算方法
第6章 估算方法概述
第7章 计数、计算和判断
第8章 估算校准和历史数据
第9章 专家的个人判断
第10章 分解和重组
第11章 类比估算
第12章 基于代理的估算
第13章 专家小组判断法
第14章 软件估算工具
第15章 使用多种估算方法
第16章 获得良好估算的软件项目中的估算流程
第17章 标准化估算规程
第三部分 特定的估算挑战
译者序回到顶部↑
软件估算是是项目计划和控制的基础。任何一个软件项目在开始实施之前和实施的过程中，都需要对软件的规模、成本、工作量和进度，等等方面进行估算。但是由于软件开发是一个非常复杂的过程，故软件估算具有极高的复杂性和不确定性，以至于估算过程往往被看做是一种“黑匣子过程”。在本书之前，还没有哪本书籍能够如此全面、深入地阐述如何才能对软件项目进行有效和准确的估算。以往那些涉及软件估算的书更多的是对一些相当成熟的开发组织的估算方法进行理论分析。这些开发组织采用的方法虽然很科学，但是对大多数开发组织而言可能并不具有很高的效费比。
本书的作者Steve McConnell是资深的软件开发人员和久负盛名的软件开发书籍作家，他领导开发的软件曾荣获Software Development杂志的生产力大奖，他的著作也曾两度荣获Software Development杂志的软件开发书籍震撼大奖。在《软件估算——“黑匣子”揭秘》一书中，他为软件开发组织和开发人员获得基本的估算技能提供了有效的实践指南，并为他们指出了持续提高估算能力的基本途径。本书虽然涉及一些数学计算（这在估算中是不可避免的），但它尽可能地避免了过于复杂的公式推导，并提供众多的提示，以帮助读者通过建立较少的工作来获得更准确的估算结果。用作者的话说，本书关注的重点是实用的估算术，而不是复杂的估算学方法。
就在本书的翻译过程中，还传来了本书荣获Software Development杂志2007年生产力大奖的消息。这再次肯定了本书提供的那些实际的、经过作者验证的亲身经验的价值。
本书主要由宋锐翻译，如果广大读者需要对本书的内容或与软件估算有关的问题进行讨论，可以发送电子邮件至coldmoon75@163.com。Be Flying工作室负责人肖国尊负责本书译员的确定，翻译质量和进度的控制与管理。此外，本书的出版离不开电子社编辑许艳所做的大量协调工作，没有她的积极推动，本书有可能延迟半年以上出版，在此予以特别感谢。敬请广大读者提供反馈意见，读者可以将意见E-mail至be-flying@sohu.com，我们会仔细查阅读者发来的每一封邮件，以求进一步提高今后译著的质量。同时欢迎各位进入Be Flying工作室博客http://blog.csdn.net/be_flying/，或者China-Pub互动网上的宣传链接http://www. china-pub.com/main/sale/renwu/ GetInfo.asp?theID=64，来了解Be Flying工作室的所有其他译著。
译 者
2007年7月于湖南长沙
本书的作者Steve McConnell是资深的软件开发人员和久负盛名的软件开发书籍作家，他领导开发的软件曾荣获Software Development杂志的生产力大奖，他的著作也曾两度荣获Software Development杂志的软件开发书籍震撼大奖。在《软件估算——“黑匣子”揭秘》一书中，他为软件开发组织和开发人员获得基本的估算技能提供了有效的实践指南，并为他们指出了持续提高估算能力的基本途径。本书虽然涉及一些数学计算（这在估算中是不可避免的），但它尽可能地避免了过于复杂的公式推导，并提供众多的提示，以帮助读者通过建立较少的工作来获得更准确的估算结果。用作者的话说，本书关注的重点是实用的估算术，而不是复杂的估算学方法。
就在本书的翻译过程中，还传来了本书荣获Software Development杂志2007年生产力大奖的消息。这再次肯定了本书提供的那些实际的、经过作者验证的亲身经验的价值。
本书主要由宋锐翻译，如果广大读者需要对本书的内容或与软件估算有关的问题进行讨论，可以发送电子邮件至coldmoon75@163.com。Be Flying工作室负责人肖国尊负责本书译员的确定，翻译质量和进度的控制与管理。此外，本书的出版离不开电子社编辑许艳所做的大量协调工作，没有她的积极推动，本书有可能延迟半年以上出版，在此予以特别感谢。敬请广大读者提供反馈意见，读者可以将意见E-mail至be-flying@sohu.com，我们会仔细查阅读者发来的每一封邮件，以求进一步提高今后译著的质量。同时欢迎各位进入Be Flying工作室博客http://blog.csdn.net/be_flying/，或者China-Pub互动网上的宣传链接http://www. china-pub.com/main/sale/renwu/ GetInfo.asp?theID=64，来了解Be Flying工作室的所有其他译著。
译 者
2007年7月于湖南长沙
前言回到顶部↑
中文版引言
对于软件项目管理，“坊间”流传着一个经典的“六拍”黑色幽默，如图1所示。在此我略做演绎：在项目开始之前，你总是先“拍脑袋”得出进度和成本的承诺；在开工大会上领导“拍拍你肩膀”，是那样的语重心长、充满期待；而小酒刚下肚、春风正得意时，你不由得“拍胸脯”以表决心和能力；但在项目进展过程中遇到这样、那样的困难时，客户和业主不能不“拍桌子”了；这时充满悔意的你，只能“拍大腿”以示自责；而到了一切都腹水难收时，恐怕也只能“拍屁股”另谋高就了；不过却也总能够重新找个地方东山再起，再“拍脑袋”去了。
如上所示的六拍“怪圈子”已经将尚显稚嫩的软件行业折磨得心焦力竭，如何才能冲破这个行业的“紧箍咒”呢？
从业人员敬业精神不高？非也！虽然拍屁股走人后总能够再次上岗，一则因为软件项目成功率本来就不高，二则因为大家实际上“已尽人事”了。
项目经理们不思进取？非也！每当遇到项目超期、成本失控时，项目经理大凡都会真心地“拍大腿”，都不愿意自己的苦心最终收获苦果。
项目过程监控管理不足？不全是！没有过程数据、没有中间管理，哪能会有人半道“拍桌子”？另则，大多失败的项目也并非源于大家不够努力。
项目经理经验技能不足？不全是！“没有金刚钻，不揽瓷器活”，敢“拍胸脯”的项目经理，绝不会都是纸上谈兵的赵括吧！
各种所需资源投入不足？也不全是！“拍拍你肩膀”的人恐怕也绝不会让你一个人独自承担所有的问题吧！
那么问题在哪里？显然最为核心的问题就出在“拍脑袋”上，在软件项目管理中缺乏有效的估算方法与过程，一直以来是业界的心头之痛！那又是什么原因导致这个大家都意识到的问题，长期以来却处于“无解”的状态呢？
也许“规划规划全是糊话，计划计划全是鬼话”这一说法从另一个侧面道出了从业人员的无奈，计划情况与实际情况的严重偏离导致整个行业对“软件估算”产生了不信任感，高级管理人员不敢采用，项目管理者也不愿意把时间花在软件估算这个“黑匣子”上。幸运的是，Steve McConnell在本书中打开了这个潘多拉之盒背后的秘密。
如果你是一名管理人员
如果你是一名管理人员，相信对“财务预算表”不陌生吧，虽然财务预算也从来没有准确过，但它却总能够为管理提供一个范围。对于业务管理、软件项目而言，其道理也是相同的，戴明博士在TQM理论中提出的管制图（如图2所示）就高度概括了这一思想：
管理层的合理预期是使软件估算结果在一个可以控制的范围之内，即管理下限和管理上限之间。如果今后的项目执行情况都能够落在这个区域，那么就意味着是可控的；而如果有大量的数据点都落在管理上限之上，或管理下限之下，就意味着控制性很差。
我想有着丰富管理理论的你，当从项目经理那里听到整个项目需要35.2个人月的估算时，你的理解可能是类似于“需要30~40个人月”的概念吧！鬼才相信一开始就能够给出如此精确的估算值哩。
你肯定知道，项目的估计准确度是随着项目进展而不断提高的，是一个“瞄准靶心”的过程，一开始要做的是确定出“1环”和“脱靶”之间的边界，然后才能确定“2环、3环、…、10环”，这种被Steve McConnell定义为“不确定性锥”的理念是使软件估算有意义的基础。但项目经理似乎没有发现这种“观念”，这就让问题从一开始就深深埋下了，因此你该告诉他！本书就能够完成这个任务，因为它围绕着这一观念展开了有效、深入的讲解。
当然如果你有时间翻阅本书，就能够更深入地理解特定于软件估算所遇到的困难，更好地理解诸如软件开发人员产能不稳定、不同软件项目存在很大差异等特殊因素，以便为项目团队的估算提供更好的行政支持。
如果你是一名项目经理
如果你是一名项目经理，首先要理解在项目初期，估算的结果是一个靶子，而不是马上给出一个靶心，也就是说得到的结果应该是“需要30~40个人月，最可能的值是36个人月”，而不是精确的35.2个人月。如果对这个概念还有些模糊，建议你回头看看上一小节，理解理解“管制图”的概念，不管怎么说你也是一个“经理”，算是个管理岗位吧！
除此之外，还需要建立以下几个关键的理念，而如果你开始有了点感觉，那么就不要等待，马上翻开正文，让自己接受一次全新的思维洗礼吧。
对于软件项目管理，“坊间”流传着一个经典的“六拍”黑色幽默，如图1所示。在此我略做演绎：在项目开始之前，你总是先“拍脑袋”得出进度和成本的承诺；在开工大会上领导“拍拍你肩膀”，是那样的语重心长、充满期待；而小酒刚下肚、春风正得意时，你不由得“拍胸脯”以表决心和能力；但在项目进展过程中遇到这样、那样的困难时，客户和业主不能不“拍桌子”了；这时充满悔意的你，只能“拍大腿”以示自责；而到了一切都腹水难收时，恐怕也只能“拍屁股”另谋高就了；不过却也总能够重新找个地方东山再起，再“拍脑袋”去了。
如上所示的六拍“怪圈子”已经将尚显稚嫩的软件行业折磨得心焦力竭，如何才能冲破这个行业的“紧箍咒”呢？
从业人员敬业精神不高？非也！虽然拍屁股走人后总能够再次上岗，一则因为软件项目成功率本来就不高，二则因为大家实际上“已尽人事”了。
项目经理们不思进取？非也！每当遇到项目超期、成本失控时，项目经理大凡都会真心地“拍大腿”，都不愿意自己的苦心最终收获苦果。
项目过程监控管理不足？不全是！没有过程数据、没有中间管理，哪能会有人半道“拍桌子”？另则，大多失败的项目也并非源于大家不够努力。
项目经理经验技能不足？不全是！“没有金刚钻，不揽瓷器活”，敢“拍胸脯”的项目经理，绝不会都是纸上谈兵的赵括吧！
各种所需资源投入不足？也不全是！“拍拍你肩膀”的人恐怕也绝不会让你一个人独自承担所有的问题吧！
那么问题在哪里？显然最为核心的问题就出在“拍脑袋”上，在软件项目管理中缺乏有效的估算方法与过程，一直以来是业界的心头之痛！那又是什么原因导致这个大家都意识到的问题，长期以来却处于“无解”的状态呢？
也许“规划规划全是糊话，计划计划全是鬼话”这一说法从另一个侧面道出了从业人员的无奈，计划情况与实际情况的严重偏离导致整个行业对“软件估算”产生了不信任感，高级管理人员不敢采用，项目管理者也不愿意把时间花在软件估算这个“黑匣子”上。幸运的是，Steve McConnell在本书中打开了这个潘多拉之盒背后的秘密。
如果你是一名管理人员
如果你是一名管理人员，相信对“财务预算表”不陌生吧，虽然财务预算也从来没有准确过，但它却总能够为管理提供一个范围。对于业务管理、软件项目而言，其道理也是相同的，戴明博士在TQM理论中提出的管制图（如图2所示）就高度概括了这一思想：
管理层的合理预期是使软件估算结果在一个可以控制的范围之内，即管理下限和管理上限之间。如果今后的项目执行情况都能够落在这个区域，那么就意味着是可控的；而如果有大量的数据点都落在管理上限之上，或管理下限之下，就意味着控制性很差。
我想有着丰富管理理论的你，当从项目经理那里听到整个项目需要35.2个人月的估算时，你的理解可能是类似于“需要30~40个人月”的概念吧！鬼才相信一开始就能够给出如此精确的估算值哩。
你肯定知道，项目的估计准确度是随着项目进展而不断提高的，是一个“瞄准靶心”的过程，一开始要做的是确定出“1环”和“脱靶”之间的边界，然后才能确定“2环、3环、…、10环”，这种被Steve McConnell定义为“不确定性锥”的理念是使软件估算有意义的基础。但项目经理似乎没有发现这种“观念”，这就让问题从一开始就深深埋下了，因此你该告诉他！本书就能够完成这个任务，因为它围绕着这一观念展开了有效、深入的讲解。
当然如果你有时间翻阅本书，就能够更深入地理解特定于软件估算所遇到的困难，更好地理解诸如软件开发人员产能不稳定、不同软件项目存在很大差异等特殊因素，以便为项目团队的估算提供更好的行政支持。
如果你是一名项目经理
如果你是一名项目经理，首先要理解在项目初期，估算的结果是一个靶子，而不是马上给出一个靶心，也就是说得到的结果应该是“需要30~40个人月，最可能的值是36个人月”，而不是精确的35.2个人月。如果对这个概念还有些模糊，建议你回头看看上一小节，理解理解“管制图”的概念，不管怎么说你也是一个“经理”，算是个管理岗位吧！
除此之外，还需要建立以下几个关键的理念，而如果你开始有了点感觉，那么就不要等待，马上翻开正文，让自己接受一次全新的思维洗礼吧。
)
加载中...
