软件开发周期估算及探讨

文章作者 100test 发表时间 2007:01:15 18:18:41
来源 100Test.Com百考试题网

1.概述

软件开发周期估算是IT人员经常提到的一个概念，那么究竟什么是软件开发周期估算呢?我们可以把它定义如下：根据软件的开发内容、开发工具、开发人员等因素对需求调研、程序设计、编码、测试等整个开发过程所花费的时间做的预测。在这个定义中，“预测”两个字非常关键，它突出体现了估算的含义，同时也隐含表明了结果的不确定性。有效的软件开发周期估算在软件开发中是非常困难的工序之一，之所以说困难，是因为软件开发所涉及的因素不仅多而且异常复杂，即便是及其类似的软件项目也不能完全照搬，在估算的把握上有一定难度。估算也是软件开发中很重要的一个环节，如果低估项目周期会造成人力低估、成本预算低估、日程过短，最终人力资源耗尽，成本超出预算，为完成项目不得不赶工，影响项目质量，甚至导致项目失败。项目周期估计过长表面看来影响不大，但是实际上也会带来成本估计过高，人力资源利用不充分效率低下的后果。无论哪种情况对于项目经理控制整个项目都会带来很大影响，周期估算如同盖楼房中打地基，是后续工作的基础，它完成质量的好坏所带来的影响会贯穿整个项目，由此可见开发周期正确估算的重要性。

2.国内外软件估算比较
国内软件开发的管理目前正逐步向规范化发展，但是在开发周期的估算上绝大部分还是处于手工作坊的状态。所谓的手工作坊指两个方面，一方面是管理人员意识上没有认识到估算的重要性，认为估算就是一个大概的估计，很多还受限于商业行为，比如为了签订合同而不惜减少开发工作量却未经任何评审；另一方面也没有专门的工具来辅助估算，或者说没有专门对它进行研究。一个软件开发周期究竟要多长基本上是依靠经验来判断，不同经验的人估算出的周期相差很大，而更糟糕的是这种开发周期的判断由于完全凭借经验使得不同意见的人之间很难沟通，因为谁都没有确切的量化标准来支持自己的判断，最终的结果往往是以“专家”的估算为准。这就有些类似于中式烹调，放多少作料没有依据，一般都是“少许”，这个“少许”靠的就是经验，高级厨师和新手根据这个量炒出的菜味道可能差得很远；实际上国内的软件开发需要的正是定量估算，这样做不仅规范而且精确，十分有助于软件事业的健康发展以及与国际接轨。

国外发达国家在软件估算上比国内要成熟的多，不仅有很多先进方法比如代码行估算法、功能点估算法、人力估算法，而且形成了专业化的估算工具来辅助这项工作，比如微软公司开发的项目管理工具软件Project，加拿大Software Productivity Center Inc.公司开发的Estimate，都是比较成熟的估算辅助工具。Project采用了自下而上的估算法，Estimate更是属于专业化工具，包含常用的各种估算方法、校正方法，使用了Putnam Methodology、Cocomo II和 Monte Carlo Simulation几种成熟算法，估算结果除了项目花费时间、人力，还包括十几种分析报告以及模拟发散图、计划编制选项图、人力图、预计缺陷图、缺陷方差图等等，从各种不同角度辅助管理人员进行分析。

采用辅助工具对软件开发周期进行估算具有明显的优势，这些辅助工具是在大量不同类型项目数据研究的基础上总结开发出来的，采用的算法、估算的方法已经很成熟，估算结果的准确性有保障，由于这种估算是可以量化的，并非依据个人经验直接得出一个结果，在结果的评审上有据可依。长期依靠工具辅助估算可以将大量项目的数据和估算结果积累形成历史经验库，知识成果得以保存，便于以后利用。

3. 软件估算中的因素探讨
软件开发是一项非常复杂的工程，不仅包含需求分析、设计、编码、测试、实施、维护等完整的过程，还涉及到开发工具、开发人员、项目管理、风险等众多因素，不同因素对估算产生的影响不尽相同，在进行软件估算时（包括利用工具辅助估算）必须考虑到这些方面，否则最终结果就会和实际结果有很大的偏差，影响项目控制，以下对其中几个常见的因素做一些探讨。

3.1估算与软件规模
软件规模通常指的是软件的大小，这可以通过不同的方式来描述，比如程序代码行的长度、功能函数的数量、数据库中表的数量、数据库的大小等等。一般而言软件规模越大，所花费的开发周期就越长，但这并不是一个简单的线形函数关系，下表详细列举了实际开发中的一些数据，开发平台为Lotus Domino/Notes。

表一
单个模块的开发周期

序号 模块 开发周期（中级程序员） 代码行长度 数据库大小(无数据)
1. 办事指南 0.25人月 300 1170K
2. 名片簿 0.25人月 300 1039K
3. 合同管理 0.25人月 460 2110K
4. 物控管理 0.5人月 850 2560K
5. 组织机构 0.5人月 900 1318K
6. 流程管理 0.8人月 1000 2304K
7. 公告板 0.5人月 1400 2560K
8. 人事管理 1人月 1800 3840K
9. 公文管理 1.8人月 2500 2304K
10. 事务审批 1.5人月 3750 2110K
11. 考勤管理 1.8人月 4800 3840K
12. 资源管理 1.8人月 5800 3840K
13. 会议管理 2.5人月 11000 4608K

表二
软件项目的开发周期

软件项目 开发周期 包含的模块 备注
某政府客户 3个人月 10个 定制开发量较小
某媒体客户 6个人月 17个 有3个模块完全重新开发
某金融客户 10个人月 14个 80%完全重新开发
某保险客户 16个人月 18个 完全重新开发

从表一中可以看出，模块的代码行越长，开发周期就越长，对同一开发工具而言基本是一个线形关系，但其中也要考虑代码重用问题，比如一个模块代码很长，但是可能包含了很多公用函数，那么在估算时就应适当减少代码行数量，表中会议管理就是个例子，这个模块的代码行超过一万行，但其中公共函数很多，去除此因素，真正的代码行在9000行左右。

表二是软件项目的实际开发周期（不考虑系统实施），从普通意义上说软件项目中包含的功能模块越多、越复杂，或者说软件越大开发周期增长的就越快，这个时间绝不是模块开发时间的简单叠加，因为模块功能数量的增加直接带来了软模块间相互关联度、复杂度的成倍增加，这就直接导致了在需求、设计等阶段需要花费更多的时间，这比单独考虑一个模块复杂的多。在表二中随着模块数量增加，开发周期增加不是特别明显，这是因为产品化程度高所引起的，由于相当数量的模块可以完全重用，实际开发量大大减少，最后一个例子完全重新开发，开发周期就长的多。

在实际进行软件开发周期估算的时候，软件规模肯定是首先考虑的因素，根据我们上面所讨论的情况，在考虑软件规模时一定要去除可重用的部分，由于当今软件在设计上很重视这点，所以这部分会占相当的比重。另外软件功能之间的关联所造成的复杂性必须足够重视，这样在估算上就不会产生重大偏差。