进度管理软件开发周期估算及探讨.docx

进度管理软件开发周期估算及探讨.docx

《进度管理软件开发周期估算及探讨.docx》由会员分享，可在线阅读，更多相关《进度管理软件开发周期估算及探讨.docx（9页珍藏版）》请在冰豆网上搜索。

进度管理软件开发周期估算及探讨

进度管理：

软件开发周期估算及探讨

　　1.概述

　　软件开发周期估算是IT人员经常提到的一个概念，那么究竟什么是软件开发周期估算呢?

我们可以把它定义如下：

根据软件的开发内容、开发工具、开发人员等因素对需求调研、程序设计、编码、测试等整个开发过程所花费的时间做的预测。

在这个定义中，“预测”两个字非常关键，它突出体现了估算的含义，同时也隐含表明了结果的不确定性。

有效的软件开发周期估算在软件开发中是非常困难的工序之一，之所以说困难，是因为软件开发所涉及的因素不仅多而且异常复杂，即便是及其类似的软件项目也不能完全照搬，在估算的把握上有一定难度。

估算也是软件开发中很重要的一个环节，如果低估项目周期会造成人力低估、成本预算低估、日程过短，最终人力资源耗尽，成本超出预算，为完成项目不得不赶工，影响项目质量，甚至导致项目失败。

项目周期估计过长表面看来影响不大，但是实际上也会带来成本估计过高，人力资源利用不充分效率低下的后果。

无论哪种情况对于项目经理控制整个项目都会带来很大影响，周期估算如同盖楼房中打地基，是后续工作的基础，它完成质量的好坏所带来的影响会贯穿整个项目，由此可见开发周期正确估算的重要性。

　　2.国内外软件估算比较

　　国内软件开发的管理目前正逐步向规范化发展，但是在开发周期的估算上绝大部分还是处于手工作坊的状态。

所谓的手工作坊指两个方面，一方面是管理人员意识上没有认识到估算的重要性，认为估算就是一个大概的估计，很多还受限于商业行为，比如为了签订合同而不惜减少开发工作量却未经任何评审;另一方面也没有专门的工具来辅助估算，或者说没有专门对它进行研究。

一个软件开发周期究竟要多长基本上是依靠经验来判断，不同经验的人估算出的周期相差很大，而更糟糕的是这种开发周期的判断由于完全凭借经验使得不同意见的人之间很难沟通，因为谁都没有确切的量化标准来支持自己的判断，最终的结果往往是以“专家”的估算为准。

这就有些类似于中式烹调，放多少作料没有依据，一般都是“少许”，这个“少许”靠的就是经验，高级厨师和新手根据这个量炒出的菜味道可能差得很远;实际上国内的软件开发需要的正是定量估算，这样做不仅规范而且精确，十分有助于软件事业的健康发展以及与国际接轨。

　　国外发达国家在软件估算上比国内要成熟的多，不仅有很多先进方法比如代码行估算法、功能点估算法、人力估算法，而且形成了专业化的估算工具来辅助这项工作，比如微软公司开发的项目管理工具软件Project，加拿大SoftwareProductivityCenterInc.公司开发的Estimate，都是比较成熟的估算辅助工具。

Project采用了自下而上的估算法，Estimate更是属于专业化工具，包含常用的各种估算方法、校正方法，使用了PutnamMethodology、CocomoII和MonteCarloSimulation几种成熟算法，估算结果除了项目花费时间、人力，还包括十几种分析报告以及模拟发散图、计划编制选项图、人力图、预计缺陷图、缺陷方差图等等，从各种不同角度辅助管理人员进行分析。

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

长期依靠工具辅助估算可以将大量项目的数据和估算结果积累形成历史经验库，知识成果得以保存，便于以后利用。

　　3.软件估算中的因素探讨

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

　　3.1估算与软件规模

　　软件规模通常指的是软件的大小，这可以通过不同的方式来描述，比如程序代码行的长度、功能函数的数量、数据库中表的数量、数据库的大小等等。

一般而言软件规模越大，所花费的开发周期就越长，但这并不是一个简单的线形函数关系，下表详细列举了实际开发中的一些数据，开发平台为LotusDomino/Notes。

　　表一

　　单个模块的开发周期

　　序号模块开发周期（中级程序员）代码行长度数据库大小（无数据）

　　1.办事指南0.25人月3001170K

　　2.名片簿0.25人月3001039K

　　3.合同管理0.25人月4602110K

　　4.物控管理0.5人月8502560K

　　5.组织机构0.5人月9001318K

　　6.流程管理0.8人月10002304K

　　7.公告板0.5人月14002560K

　　8.人事管理1人月18003840K

　　9.公文管理1.8人月25002304K项目管理者联盟文章，深入探讨。

　　10.事务审批1.5人月37502110K

　　11.考勤管理1.8人月48003840K

　　12.资源管理1.8人月58003840K

　　13.会议管理2.5人月110004608K

　　表二

　　软件项目的开发周期

　　软件项目开发周期包含的模块备注

　　某政府客户3个人月10个定制开发量较小

　　某媒体客户6个人月17个有3个模块完全重新开发

　　某金融客户10个人月14个80%完全重新开发

　　某保险客户16个人月18个完全重新开发

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

　　表二是软件项目的实际开发周期（不考虑系统实施），从普通意义上说软件项目中包含的功能模块越多、越复杂，或者说软件越大开发周期增长的就越快，这个时间绝不是模块开发时间的简单叠加，因为模块功能数量的增加直接带来了软模块间相互关联度、复杂度的成倍增加，这就直接导致了在需求、设计等阶段需要花费更多的时间，这比单独考虑一个模块复杂的多。

在表二中随着模块数量增加，开发周期增加不是特别明显，这是因为产品化程度高所引起的，由于相当数量的模块可以完全重用，实际开发量大大减少，最后一个例子完全重新开发，开发周期就长的多。

　　在实际进行软件开发周期估算的时候，软件规模肯定是首先考虑的因素，根据我们上面所讨论的情况，在考虑软件规模时一定要去除可重用的部分，由于当今软件在设计上很重视这点，所以这部分会占相当的比重。

另外软件功能之间的关联所造成的复杂性必须足够重视，这样在估算上就不会产生重大偏差。

　　3.2估算与项目风险

　　任何一个项目都或多或少存在风险，软件项目开发过程中也避免不了这种情况而且有这类项目自己的特点，最常见的风险有以下几种：

技术风险，项目技术难度很大，花费的时间超过原先的估计;客户风险，客户需求不定，增加需求，组织协调不畅;人员风险，开发人员突然更换、离职;管理风险，项目经理管理不善、决策失误。

对于风险控制，在项目管理中通常是提前做风险分析和预测，制定风险应对措施，这样在风险真的来临时不至于措手不及，提高整个项目的可控性。

　　软件项目的潜在风险对于开发周期的影响在很多情况下是非常大的，当然好的项目控制会最大限度的减少这种影响，绝对避免是不可能的，所以在开发周期估算时项目风险应该适当考虑，尤其是技术风险和客户风险。

　　技术风险主要来自于软件本身的技术难度，如果对于一套成熟的产品，定制开发的技术风险相对非常小，因为重要的技术已经成型，客户也很少有新的能带来高难度技术问题的需求，这种风险可以不予考虑。

但是对于完全重新开发的项目，或是研发类的项目，技术风险必须特别重视，其中应该考虑的细节主要包括下面几个。

　　开发平台，是否能适合本项目所涉及的软件开发、能否满足最终的需求，平台的错误选择将导致庞大的开发工作量，即便满足了用户需求也可能造成系统效率低下，扩展性差的致命问题，软件可能会很快被淘汰。

功能实现难度，在切实了解需求的基础上要仔细分析采用的开发工具能否实现其中的难点，是否会耗费大量时间。

　　在实际估算中，建议技术难度分为十级，每一级在初次估算的代码行上增加10%，最终估算代码长度=初始估算代码长度×（1+0.1×n）。

假设模块A的初次估计代码行为15000行，但考虑技术难度高的风险，设定技术难度级别为二级，最终代码行的估算数量为15000X（1+20%）=18000。

　　由于技术风险的分析是一项技术性很强的工作，要求做技术风险分析的人必须是技术专家，在相关技术领域有着丰富的经验，对重大技术风险的分析结果必须要经过评审，保证准确性。

　　客户风险存在于客户化项目中，不同行业的客户特点不尽相同，技术、理解水平也相差甚远，在我经历开发的项目中，80%的项目延期属于客户方的原因，而且这种风险可控性很低，对项目影响超过技术风险。

在开发周期估算前，项目经理要仔细分析客户的具体状况，包括客户的计算机水平、管理水平、可沟通程度，在此基础上结合以往的经验综合判断是否会对开发带来明显的影响，可以按照上述的技术风险的方式将客户分级，最终确定开发周期。

在这个过程中，项目经理的经验极其重要，对客户的分析基本上要依赖经验做判断，要求管理人员有大量的客户经验和行业分析能力。

　　3.3估算与人力资源

　　对于软件开发项目来说，人力资源是核心力量，因为软件开发不同于其它类型的项目，除了电脑它不需要利用其它工具，最终结果的产生完全取决于人脑中的知识，这也是知识经济的最大特点。

　　人力资源对估算的影响表现在技术水平、理解能力、沟通能力等几个方面，编程水平的高低、速度的快慢、能否适应团队、能否与各成员保持良好的沟通都会对开发进度产生影响，其中技术水平是最关键的因素。

评价程序员的技术水平可以从编程熟练程度、编程速度、解决技术问题的能力几个因素考虑，编程熟练程度指的是程序员能否很顺畅的使用编程工具实现软件的功能，编程速度指的是完成某个功能的时间，解决技术问题的能力可以反映程序员在遇到技术难点时表现出的技术功底，如果以100%作为总和，这三个因素分别占70%、15%和15%这样的比例。

　　软件开发周期估算前，应对开发人员定级，建议按新手、初级程序员、中级程序员、高级程序员来划分，每一级人员再评定上述三个因素，初次估算时可以假定开发人员为中级程序员，然后依据项目组实际人员的水平做修正，这样结果的精确度能大大提高。

　　4.历史数据估算法的运用

　　依据历史数据估算软件开发周期是一种比较常见的方法，这种方法以历史软件开发周期为依据，在估算时把当前软件项目的情况与历史数据加以对比，从而得出最终结果。

按照历史数据估算开发周期准确度还是相当高的，但这种方法只适用于对某类软件的开发，比如某个行业业务系统的开发，当要估算的软件与历史软件相差太多，比如开发工具完全不同，或者类型完全不同，就不能再依赖这种方法，最起码应该辅助使用其它估算法。

如果没有历史数据或是开发一种新领域软件，可以使用代码行或功能点估算法，在此基础上再通过其它方法校正。

　　事实上目前项目管理人员对开发周期的估算大部分属于人力时间估算法，凭借的是自己的经验，经验越多估算的结果就越精确，但是大部分项目管理人员对以前很有价值的历史数据缺乏归纳整理，估算的时候凭借感觉的成分多一些，所以精确度相对要低很多，所以要求我们的项目管理人员不仅要有大量软件开发的经验还要不断总结积累，历史项目数据对于以后软件开发周期的估算是非常有价值的。

　　在实际使用历史数据估算法时，建议项目经理建立一个历史项目数据库，在库中包含以前所有项目的开发周期、项目规模、开发人员状况、客户状况等详细数据，当估算时根据当前项目的状况在库中寻找最类似的历史项目，然后再比较两个项目之间在项目规模、项目风险、人力资源之间的区别，我们假定历史项目开发周期为A当前项目的周期可以依据下列公式得出

　　B=A×（2×S+R+P+2×C）/6

　　S：

代表软件规模R：

代表风险P：

代表人力资源C：

代表客户

　　以上值均指当前项目与历史项目的比率。

　　实际的比较因素应该不止这些，但软件规模、风险、人力资源及客户状况是其中最重要的，对软件开发的影响也最大，所以这个公式中只考虑了这些因素。

其中软件规模和客户两项占的权重最大，这也是根据项目管理经验得出的，在实际使用历史数据估算法时还可以灵活加入其它因素。

　　1.概述

　　软件开发周期估算是IT人员经常提到的一个概念，那么究竟什么是软件开发周期估算呢?

我们可以把它定义如下：

根据软件的开发内容、开发工具、开发人员等因素对需求调研、程序设计、编码、测试等整个开发过程所花费的时间做的预测。

在这个定义中，“预测”两个字非常关键，它突出体现了估算的含义，同时也隐含表明了结果的不确定性。

有效的软件开发周期估算在软件开发中是非常困难的工序之一，之所以说困难，是因为软件开发所涉及的因素不仅多而且异常复杂，即便是及其类似的软件项目也不能完全照搬，在估算的把握上有一定难度。

估算也是软件开发中很重要的一个环节，如果低估项目周期会造成人力低估、成本预算低估、日程过短，最终人力资源耗尽，成本超出预算，为完成项目不得不赶工，影响项目质量，甚至导致项目失败。

项目周期估计过长表面看来影响不大，但是实际上也会带来成本估计过高，人力资源利用不充分效率低下的后果。

无论哪种情况对于项目经理控制整个项目都会带来很大影响，周期估算如同盖楼房中打地基，是后续工作的基础，它完成质量的好坏所带来的影响会贯穿整个项目，由此可见开发周期正确估算的重要性。

　　2.国内外软件估算比较

　　国内软件开发的管理目前正逐步向规范化发展，但是在开发周期的估算上绝大部分还是处于手工作坊的状态。

所谓的手工作坊指两个方面，一方面是管理人员意识上没有认识到估算的重要性，认为估算就是一个大概的估计，很多还受限于商业行为，比如为了签订合同而不惜减少开发工作量却未经任何评审;另一方面也没有专门的工具来辅助估算，或者说没有专门对它进行研究。

一个软件开发周期究竟要多长基本上是依靠经验来判断，不同经验的人估算出的周期相差很大，而更糟糕的是这种开发周期的判断由于完全凭借经验使得不同意见的人之间很难沟通，因为谁都没有确切的量化标准来支持自己的判断，最终的结果往往是以“专家”的估算为准。

这就有些类似于中式烹调，放多少作料没有依据，一般都是“少许”，这个“少许”靠的就是经验，高级厨师和新手根据这个量炒出的菜味道可能差得很远;实际上国内的软件开发需要的正是定量估算，这样做不仅规范而且精确，十分有助于软件事业的健康发展以及与国际接轨。

　　国外发达国家在软件估算上比国内要成熟的多，不仅有很多先进方法比如代码行估算法、功能点估算法、人力估算法，而且形成了专业化的估算工具来辅助这项工作，比如微软公司开发的项目管理工具软件Project，加拿大SoftwareProductivityCenterInc.公司开发的Estimate，都是比较成熟的估算辅助工具。

Project采用了自下而上的估算法，Estimate更是属于专业化工具，包含常用的各种估算方法、校正方法，使用了PutnamMethodology、CocomoII和MonteCarloSimulation几种成熟算法，估算结果除了项目花费时间、人力，还包括十几种分析报告以及模拟发散图、计划编制选项图、人力图、预计缺陷图、缺陷方差图等等，从各种不同角度辅助管理人员进行分析。

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

长期依靠工具辅助估算可以将大量项目的数据和估算结果积累形成历史经验库，知识成果得以保存，便于以后利用。

　　3.软件估算中的因素探讨

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

　　3.1估算与软件规模

　　软件规模通常指的是软件的大小，这可以通过不同的方式来描述，比如程序代码行的长度、功能函数的数量、数据库中表的数量、数据库的大小等等。

一般而言软件规模越大，所花费的开发周期就越长，但这并不是一个简单的线形函数关系，下表详细列举了实际开发中的一些数据，开发平台为LotusDomino/Notes。

　　表一

　　单个模块的开发周期

　　序号模块开发周期（中级程序员）代码行长度数据库大小（无数据）

　　1.办事指南0.25人月3001170K

　　2.名片簿0.25人月3001039K

　　3.合同管理0.25人月4602110K

　　4.物控管理0.5人月8502560K

　　5.组织机构0.5人月9001318K

　　6.流程管理0.8人月10002304K

　　7.公告板0.5人月14002560K

　　8.人事管理1人月18003840K

　　9.公文管理1.8人月25002304K项目管理者联盟文章，深入探讨。

　　10.事务审批1.5人月37502110K

　　11.考勤管理1.8人月48003840K

　　12.资源管理1.8人月58003840K

-全文完-