软件项目的估算历来是比较复杂的事，因为软件本身的复杂性、历史经验的可重复性、估算工具的缺乏以及一些人为错误，都会导致软件项目的估算往往和实际情况相差甚远。据有关机构调查发现，约有60％的软件项目的失败是因为估算偏差引起的，而不是因为技术实力不够。因此，估算偏差已被列为软件项目失败的四大原因之一。
从软件工程学上，我们知道软件需求和估算是软件项目的基础。因为只有准确的了解客户的需求，以之为基础，并使用科学的方法对目标软件系统的规模、工作量和进度做出合理的估算，我们才能在预算内按时按质顺利的完成项目。然而，软件估算作为软件项目的基础领域却常常被人们所忽视。我在近期的一个开发项目中就尝到忽视软件规模估算带来的苦果，结果是项目进行到一半时就发现不但工期严重滞后于计划，而且项目的各种资源也严重的不足和缺乏，项目被迫暂停下马。
常见的项目规模估算失准原因
一直以来，软件项目的规模估算（Size Estimation）是个争论不休的问题。不论是对软件开发团队还是对软件用户，软件规模估算的重要性都是不容置疑的。因为它能极大的影响着甲方对发包软件的成本估算，乙方对自身开发成本的预测，以及乙方对开发过程的量化管理等诸多方面。而且，只有相对合理和相对准确地估算软件规模，才能对项目的进度安排、资源分配等各个环节进行合理的部署。所以，软件项目的规模估算是软件项目中相当重要的一环。但是，以下的原因却使到我在这次项目的实际操作中对项目规模估算失准了：
（1）对项目规模估算认识不足
项目规模估算一般分为两种应用场景：一是招投标的时候用来估价、报价；二是用来安排进度计划和指导项目具体工作的分配。因此，如果对规模估算认识不足的话，将可能会在这两种应用场景中估算失准。例如，如果项目规模低估的话就会造成人力估算低估、成本预算低估、日程过短，最终人力资源耗尽，成本超出预算。最后为了完成项目不得不赶工，不但会影响到项目质量，甚至会导致项目失败。而如果规模高估的话，就会因估价过高而降低了招投标时的竞争力，或在进度安排时提高了开发成本和浪费资源。由于对规模估算的认识不足，使到我在这次项目中就尝到一个大苦果，就是低估项目规模导致项目需要多次的追加预算。我不但多次受到公司领导的批评，而且还受到客户的多次投诉。
（2）个人经验估算法带有一定的局限性
一般来说，依靠历史或个人经验的规模估算方法都有一定的局限性。原因是很难在项目分析和计划阶段就对软件的规模进行相对准确的估算。因为估算是依靠评估人员的经验，所以对评估人员的能力要求比较强，并且难以由第三方对评估人员的工作偏差作出修正。在这次项目的初期，我片面的只是根据个人经验进行估算，结果是轻率的估算了项目规模。这是最后导致项目失利的原因之一。另外，不同软件项目使用的技术不一样，这一点也非常影响到软件规模的估算。例如同一个功能,使用JAVA语言和使用Ruby语言所涉及的代码行相差数十行，甚至数百行。即使同为JAVA语言,使用不用的框架所需要编写的代码行也不一样。
虽然估算是一门科学，更是一门艺术，这个重要的活动不能以随意的方式来进行……因为估算是所有其他项目计划活动的基础，而项目计划又提供了通往成功的软件工程的道路图，所以，没有它我们就会搭错车。——Roger S. Pressman 《软件工程——实践者的研究方法》
1、估算前的规划
当我们的办公室内堆满了杂乱无章的文件时，恐怕无法知道对于我们真正有用的文件在哪里，当我们的软件相目中收集了各种需求、意见、问题时，我们也很难从中估算出整个项目的规模、工作量以及成本。因此，在估算之前我们首先要对众多信息进行整理、归类分析，从而得到一个条理清晰的项目计划，在这个计划提供的框架内，才可能开始正确的估算。精心的规划是任何一个软件开发项目成功与否的关键，有了规划就有如成竹在胸，之后无论风云变幻，都有应对入流的方法。当然只有正确的规划，才能给软件开发指引正确的方向。
软件项目规划的重点是对人员角色、任务进度、经费、设备资源、工作成果等等做出合适的安排，制定出一些计划（包括高层的和细节的），使大家按照计划行事，最终顺利地达到预定的目标。
1．1、规划的第一步：确定软件范围
确定软件范围，就是确定目标软件的数据和控制、功能、性能、约束、接口以及可靠性。这项工作和需求分析是很类似的，如果之前已经达成需求分析规约，那么可以直接从《需求分析说明书》中把有用的部分拿来使用。如果还没有开始需求分析，关于确定软件范围的方法方面，我们可以采用许多需求分析技术（如需求诱导），从客户那里得到一个具体的软件范围。当然如果是一次全新的软件边界探索，就应当考虑软件本身可行性问题，包括团队是否具备在技术、财务、时间、资源上游可靠的保障，软件本身在市场上是否有可靠的竞争优势 ，等等。
获得软件范围，最直接最可靠的来源就是用户对软件的需求描述。例如，在开发一个C/S架构的铁路供电段数据上报系统中，客户向我们提供了以下的目标软件需求描述：
在供电站总部每天结束前要审核下属节点操作员（30~40个）的供电安全数据报表，要求每个节点必须在下午5：30~6：00之间上传数据。总部系统通过自动分析，整理出整个区内的安全形势报表，并自动反馈到每个节点。各个节点之间通过调制解调器拨号（MODEM）用内部电话线相连，每个节点电脑主机配备一个MODEM。上传数据为制式报表出了制式信息外，系统自动附加操作员姓名、上报时间、上报节点名称。信息一旦上传，节点端就不可以对已提交信息进行修改、删除，只能阅读、查询。节点间数据互相隔离，只有总部才具备对各个节点数据的管理权限，但是对于归档数据（一旦审核完毕的数据，就进行归档）总部不具备删改的权限。系统设置数据库管理员，独立于审核权限，其职责是对历史数据的清理维护。
信息化项目是一个烧钱的游戏，这已经是很多企业管理者脑袋对于信息化项目的一个直观的印象。其实呢，信息化项目比起企业其他项目来说，还是小儿科，如一个新产品的研发或者新生产线的投入，都是动辄十万、百万起步的。那为什么偏偏会给信息化项目扣上这么一顶高帽子呢？根据笔者的了解，这其中有两方面的原因。一是这些信息化项目的投资，其回报是无形的，很难利用金钱来衡量信息化项目的投资回报；二是由于很多信息化项目管理人员没有成本预算的相关知识，所以，他们在做项目报告的时候，根本没有做相关的成本预算或者所作的预算跟最后的成本支出相差甚远，他们只知道没钱了就像老板要钱。长久下去，就在投资者心中形成了这么一个坏印象。
没有一个好的成本预算，对于信息化项目的影响，是众所周知的，笔者在这里也就不浪费口舌了。下面笔者结合自己的工作经验，谈谈如何来做好信息化项目成本预算，以及减少预算的一些技巧。
信息化项目的成本，大致可以分为两块，一是有形成本，如软件的授权费用、培训费用、二次开发费用等等；二是无形的成本，如项目所占用的时间、可能给现有生产经营带来的风险、转型过程中的损失等等。前者是可控的、可量化定义的；而后者的话，跟投资回报率一样，很难精确的统计与控制。下面笔者结合一个财物管理软件项目，来谈谈在项目成本预算中，该注意的地方。其实，很多信息化项目的成本预算都是大同小异的，可以相互借鉴。
一、应用软件的授权费用。
企业若要实施财务信息化管理项目的话，则第一笔庞大支出就是财务管理软件的授权费用。虽然说，现在市场上也有一些免费的开源软件，或者是一些盗版的财物管理软件，这些都不在这篇文章的讨论之内。
我们CIO在实施财务信息化管理软件之前，第一件要做的就是打听这个财务管理软件的行情，看看财务管理软件的价格。在打听这个软件价格行情的时候，需要注意几个问题。
一个成功的软件项目首先要有一个好的起点，也就是一个合理的项目计划；一个好的项目计划，离不开一个准确的、可信的、客观的项目估算数据作为基础。如何提高估算的准确性，如何利用项目估算的数据来制定项目计划，本文就将带领大家学习、理解软件项目估算的一些最佳实践。
为什么要对项目进行估算
对于庞大的、多变的软件项目来说有着太多的不确定性。之所以要先制定项目计划，目的就是为了让项目更加可控。如果项目的计划缺乏数据进行支持，或者根本不进行估算，只凭项目管理人员的经验进行管理，那么项目最终就会变成软件项目常见的“三拍”现象：“首先公司领导拍拍某个项目经理的脑袋，说你来负责这个项目；项目经理拍拍胸脯说没问题；最后项目失败的时候项目经理就只能拍拍屁股走人”。
当然，这只是个玩笑。不过由此可见项目估算是项目管理人员深入了解项目的第一步，做到“知己知彼，才能百战不殆”。
常用的软件估算方法
软件可以通过主观和客观两种方法对其进行估算。
主观的估算方法可以通过召集项目团队成员，或者邀请各方面的专家，共同对某个项目的属性进行评估。参与评估的每个人都要单独进行估算，如果发现大家对某个项目属性估算的结果存在较大偏差，那么就需要做进一步的讨论，直到取得共识为止。对个别特殊属性进行主观估算时，一定要有直接干系人的参与，例如：对某个文档工作量进行估算时，最好该文档的负责人参与估算，因为他才是最终的执行人。
客观的估算方法是利用公司提供的各种度量数据进行估算，例如：组织级的生产率，或者其他项目的度量数据。本文主要讲解项目管理人员如何通过客观的方法对项目进行估算。
项目的哪些属性可以进行估算
软件项目的属性有很多，建议至少以下属性要在项目计划时对其进行估算：
1、 项目规模
2、 项目工作量
3、 项目所需资源
[...]
最近评论