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

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

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

3.2估算与项目风险

　　任何一个项目都或多或少存在风险，软件项目开发过程中也避免不了这种情况而且有这类项目自己的特点，常见的风险有以下几种：技术风险，项目技术难度很大，花费的时间超过原先的估计;客户风险，客户需求不定，增加需求，组织协调不畅;人员风险，开发人员突然更换、离职;管理风险，项目经理管理不善、决策失误。对于风险控制，在项目管理中通常是提前做风险分析和预测，制定风险应对措施，这样在风险真的来临时不至于措手不及，提高整个项目的可控性。

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

　　技术风险主要来自于软件本身的技术难度，如果对于一套成熟的产品，定制开发的技术风险相对非常小，因为重要的技术已经成型，客户也很少有新的能带来高难度技术问题的需求，这种风险可以不予考虑。但是对于完全重新开发的项目，或是研发类的项目，技术风险必须特别重视，其中应该考虑的细节主要包括下面几个。

　　开发平台，是否能适合本项目所涉及的软件开发、能否满足终的需求，平台的错误选择将导致庞大的开发工作量，即便满足了用户需求也可能造成系统效率低下，扩展性差的致命问题，软件可能会很快被淘汰。功能实现难度，在切实了解需求的基础上要仔细分析采用的开发工具能否实现其中的难点，是否会耗费大量时间。

　　在实际估算中，建议技术难度分为十级，每一级在初次估算的代码行上增加10%，终估算代码长度=初始估算代码长度×(1+0.1×n)。假设模块A的初次估计代码行为15000行，但考虑技术难度高的风险，设定技术难度级别为二级，终代码行的估算数量为15000X(1+20%)=18000。

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

　　客户风险存在于客户化项目中，不同行业的客户特点不尽相同，技术、理解水平也相差甚远，在我经历开发的项目中，80%的项目延期属于客户方的原因，而且这种风险可控性很低，对项目影响超过技术风险。在开发周期估算前，项目经理要仔细分析客户的具体状况，包括客户的计算机水平、管理水平、可沟通程度，在此基础上结合以往的经验综合判断是否会对开发带来明显的影响，可以按照上述的技术风险的方式将客户分级，终确定开发周期。在这个过程中，项目经理的经验极其重要，对客户的分析基本上要依赖经验做判断，要求管理人员有大量的客户经验和行业分析能力。

3.3估算与人力资源

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

　　人力资源对估算的影响表现在技术水平、理解能力、沟通能力等几个方面，编程水平的高低、速度的快慢、能否适应团队、能否与各成员保持良好的沟通都会对开发进度产生影响，其中技术水平是关键的因素。评价程序员的技术水平可以从编程熟练程度、编程速度、解决技术问题的能力几个因素考虑，编程熟练程度指的是程序员能否很顺畅的使用编程工具实现软件的功能，编程速度指的是完成某个功能的时间，解决技术问题的能力可以反映程序员在遇到技术难点时表现出的技术功底，如果以作为总和，这三个因素分别占70%、15%和15%这样的比例。

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

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

　　依据历史数据估算软件开发周期是一种比较常见的方法，这种方法以历史软件开发周期为依据，在估算时把当前软件项目的情况与历史数据加以对比，从而得出终结果。按照历史数据估算开发周期准确度还是相当高的，但这种方法只适用于对某类软件的开发，比如某个行业业务系统的开发，当要估算的软件与历史软件相差太多，比如开发工具完全不同，或者类型完全不同，不能再依赖这种方法，起码应该辅助使用其它估算法。如果没有历史数据或是开发一种新领域软件，可以使用代码行或功能点估算法，在此基础上再通过其它方法校正。

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

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

B=A×(2×S+R+P+2×C)/6

S：代表软件规模 R：代表风险 P：代表人力资源 C：代表客户

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

　　实际的比较因素应该不止这些，但软件规模、风险、人力资源及客户状况是其中重要的，对软件开发的影响也大，所以这个公式中只考虑了这些因素。其中软件规模和客户两项占的权重大，这也是根据项目管理经验得出的，在实际使用历史数据估算法时还可以灵活加入其它因素。