软件项目规模估计方法是什么？
软件项目的规模估算历来是比较复杂的事，因为软件本身的复杂性、历史经验的缺乏、估算工具缺乏以及一些人为错误，导致软件项目的规模估算往往和实际情况相差甚远。
因此，估算错误已被列入软件项目失败的四大原因之一。
软件工程师经常会被问到，编一个什么什么样的软件需要多长时间、多少钱。
面对这个问题，有不少人很犯难，因为，第一用户的需求太不具体，第二，自己缺乏一个科学的估计方法。
这里向大家介绍几种软件项目规模的估计方法。
概念介绍 先介绍一个衡量软件项目规模最常用的概念——LOC(Line of Code),LOC指所有的可执行的源代码行数，包括可交付的工作控制语言（JCL:Job Control Language）语句、数据定义、数据类型声明、等价声明、输入/输出格式声明等。
一代码行（1LOC）的价值和人月均代码行数可以体现一个软件生产组织的生产能力。
组织可以根据对历史项目的审计来核算组织的单行代码价值。
例如，某软件公司统计发现该公司每一万行C语言源代码形成的源文件（。
c和。
h文件）约为250K.某项目的源文件大小为3.75M，则可估计该项目源代码大约为15万行，该项目累计投入工作量为240人月，每人月费用为10000元（包括人均工资、福利、办公费用公滩等），则该项目中1LOC的价值为： （240*10000）/150000=16元/LOC 改项目的人月均代码行数为： 150000/240=625LOC/人月 方法 一、Delphi 法 Delphi法是最流行的专家评估技术，在没有历史数据的情况下，这种方式适用于评定过去与将来，新技术与特定程序之间的差别，但专家＂专＂的程度及对项目的理解程度是工作中的难点，尽管Delphi技术可以减轻这种偏差，专家评估技术在评定一个新软件实际成本时通常用得不多，但是，这种方式对决定其它模型的输入时特别有用。
Delphi法鼓励参加者就问题相互讨论。
这个技术，要求有多种软件相关经验人的参与，互相说服对方。
Delphi法的步骤是： 1、协调人向各专家提供项目规格和估计表格； 2、协调人召集小组会各专家讨论与规模相关的因素； 3、各专家匿名填写迭代表格； 4、协调人整理出一个估计总结，以迭代表的形式返回专家； 5、协调人召集小组会，讨论较大的估计差异； 6、专家复查估计总结并在迭代表上提交另一个匿名估计； 7、重复4-6， 直到达到一个最低和最高估计的一致。
方法 二、 类比法 类比法适合评估一些与历史项目在应用领域、环境和复杂度的相似的项目，通过新项目与历史项目的比较得到规模估计。
类比法估计结果的精确度取决于历史项目数据的完整性和准确度，因此，用好类比法的前提条件之一是组织建立起较好的项目后评价与分析机制，对历史项目的数据分析是可信赖的。
其基本步骤是： 1、整理出项目功能列表和实现每个功能的代码行； 2、标识出每个功能列表与历史项目的相同点和不同点，特别要注意历史项目做得不够的地方； 3、通过步骤1和2得出各个功能的估计值； 4、产生规模估计。
软件项目中用类比法，往往还要解决可重用代码的估算问题。
估计可重用代码量的最好办法就是由程序员或系统分析员详细地考查已存在的代码，估算出新项目可重用的代码中需重新设计的代码百分比、需重新编码或修改的代码百分比以及需重新测试的代码百分比。
根据这三个百分比，可用下面的计算公式计算等价新代码行： 等价代码行 = [（重新设计% +重新编码% +重新测试%）/3]* 已有代码行 比如：有10,000行代码，假定30%需要重新设计，50%需要重新编码，70%需要重新测试，那么其等价的代码行可以计算为： [ （30% + 50% + 70%）/3 ]* 10,000 = 5,000 等价代码行。
意即：重用这10000代码相当于编写5000代码行的工作量。
方法 三、功能点估计法 功能点测量是在需求分析阶段基于系统功能的一种规模估计方法。
通过研究初始应用需求来确定各种输入、输出、计算和数据库需求的数量和特性。
通常的步骤是： 1、计算输入，输出，查询，主控文件，和接口需求的数目。
2、将这些数据进行加权乘。
下表为一个典型的权值表。
功能类型 权值输入 4输出 5查询 4主控文件 10接口 10 3、估计者根据对复杂度的判断，总数可以用+25%、0、或-25%调整。
据发现，对一个软件产品的开发，功能点对项目早期的规模估计很有帮助。
然而，在了解产品越多后，功能点可以转换为软件规模测量更常用的LOC. 方法 四、PERT估计法 PERT对各个项目活动的完成时间按三种不同情况估计：一个产品的期望规模，一个最低可能估计，一个最高可能估计。
用这三个估计用来得到一个产品期望规模和标准偏差的Pert 统计估计。
Pert 估计可得到代码行的期望值E， 和标准偏差SD.
项目规模估算在制订项目计划中有哪些作用？
目前，各个项目在制订项目计划的过程中，总体处于这样一种状态：项目启动后，项目经理根据他说能得到的资源，根据初步分解后的任务，逐一指派任务，并按照与客户约定的日程制订各个任务的工期。
这样造成一个错觉，所有任务是以工期为导向，在项目中有多少资源就分配多少资源。
至于各个资源的使用情况，各模块的实际工作量估算，并没有在计划中间体现。
这样，一份项目实施计划（MPP）就成为了一份简单的任务-资源-开始完成时间的清单。
在项目资源得到足够保障，项目计划没有太大变更的情况下，按照上述既定的MPP实施，不会产生太大的矛盾。
但是，当项目计划由于某种原因产生比较大的变更时，尤其是这种变更引发人力资源缺口危机时，就产生问题了：人力资源缺口在哪里？组内现有资源使用情况如何？如何在未有外部支援的情况下组内消除这些资源危机？ 先来看案例一：某项目A由于客户新确认一个需求，而此需求事先尚未列入此前的项目计划MPP中，由此产生资源危机。
上级承诺给予项目组中途加入三位开发人员，但是，从目前情况看，开发人员按时到位的可能性不大。
在此情况下，如何给予主管更有说服力的申请增加资源的理由呢？在承诺的资源不能按时到位时如何组内消除这种风险呢？项目经理开始反思自己的计划制订过程，基于工期的任务分配而不是基于工作量的资源调配是造成这种情况的原因。
项目经理调整了策略，决定先从任务规模估算入手。
一方面，把项目计划（MPP）中的任务列表打印出来，召集相关模块负责人估算目前MPP中罗列的任务的规模（工时）。
然后，固定工期调整项目计划（MPP）。
这样，哪些人任务过载，哪些人任务尚未饱和，从人工作量投入的报表中直接体现出来了。
另一方面，项目经理利用员工的周工作计划，在其中加入一周成员各任务工作量估计，这样当期与实际工作量就有一个对照，便于项目经理调整整个项目的MPP。
这样，项目经理在外加资源不能到位的情况下，根据现有资源的实际使用情况，合理调配，在项目组内部消化资源短缺风险。
案例启示：在制订项目计划前，先进行合理的任务分解，并对各分解的任务进行工作量估计（对应“CMM体系实施方案”的《项目估算报告》）。
然后，根据项目组申请到的资源，先在Poject中录入任务和工时（即此前估算的该任务的工作量）。
在给任务分配资源时先选择“固定工时”，然后加入“资源名称”，最后选择项目起始时间。
Poject会自动根据“工时=工期*（资源A的投入百分比+资源B的投入百分比+….）*8小时”的对应关系，自动算出每个人在该任务的投入比例。
同时，周计划中的工作量估算为验证项目开始时作的估算准确性及实时修订计划提供了参考。
软件规模的估算方法有哪几种？
软件规模的估算方法有很多种，如：功能点分析（FPA:functionpointsanalysis）、代码行（LOC:linesofcode）、德尔菲法（Delphitechnique）、COCOMO模型、特征点（featuepoint）、对象点（ojectpoint）、3-D功能点（3-Dfunctionpoints）、Bang度量（DeMacosangmetic）、模糊逻辑（fuzzylogic）、标准构件法（standadcomponent）等，这些方法不断细化为更多具体的方法
规模估算在软件研发项目管理中的重要性是什么呢？
1、项目的时间管理：项目的时间管理就是项目的计划管理。
项目经理可以先从任务规模估算入手。
一方面，把项目计划中的任务列表打印出来，召集相关模块负责人估算目前项目计划中罗列的任务的规模（工时）。
然后，固定工期调整项目计划。
这样，哪些人任务过载，哪些人任务尚未饱和，从人工作量投入的报表中直接体现出来了。
另一方面，项目经理利用员工的周工作计划，在其中加入一周成员各任务工作量估计，这样当期与实际工作量就有一个对照，便于项目经理调整整个项目的项目计划了。
2、项目的资源管理：软件开发类的项目最关键的资源就是人力，项目经理有了项目计划书、项目规模估算的规模（工时）表，就能够在项目的开始阶段统计项目的人力投入情况，何时需要何种人员？人员的能力水平的程度如何？人员工作的强度？何时哪些人员可以退出项目组？有了这些数据，项目经理可以通过事前沟通，提前从公司领导处得到资源满足的承诺，而不是到了火烧眉毛的时候，再到处抓人求人啦。
尤其在项目的范围发生变化的时候，如客户需要增加一个新的需求，项目经理通过对新需求的规模估算从而得到所需新的人力需求，用来判断是否增加人力，即使临时向项目主管提出资源要求，也可以提供有说服力的理由来。
3、项目的成本管理：项目开发类的项目的成本主要就是人力，同项目资源管理一样，有了从项目规模估算的规模（工时）表推导出的的人力投入情况表，项目经理可以很容易的算出项目的整体成本，也可以通过及时地释放人员来降低成本。
在项目发生变更时，也能够快速得到项目成本变化的趋势，找到项目成本控制的办法，从而达到成本管理的目的。
4、项目的风险管理：所有软件研发类的项目的一个重要的风险就是人员风险，人员不到位、需要的关键技术人员不足、人员被提前抽调，等等，这些都是项目经理不可忽视的风险和问题。
有了项目规模估算的规模（工时）表，项目经理手上就拥有了一张正确判定风险由来的情况表，提前判定出何时会出现的人员风险和问题，提前判定出可能造成危害，从而为提前制定出风险应对措施作好准备。
当然项目的规模估算对于项目的其它方面的管理或多或少也起着客观性的作用：如在项目范围提出变更的时候，通过规模估算推导出项目的计划是否变化？项目的成本的变化程度？等等，从而为项目管理委员会判定是否应该接受此次范围变更提供强有力的说服理由。
对于项目的质量管理、项目的沟通管理、项目的采购管理、以及项目的集成管理也是同理，因为规模估算提供的是一个依据，一个建立在项目成员的经验上、建立在项目管理理论基础上的一套科学的推算方法，无论是Dephi（专家法），还是功能点法，还有三点技术法，都可以得到项目管理的所需要的人力、物力、时间等这些项目管理基本要素，从而达到指导项目管理实际工作的目的。
软件项目计划的计划制定
项目计划详细说明了所需软件工作及如何实现。
它定义了每一个主要任务，并估算其所需时间和资源，同时为管理层的评估和控制提供了一个框架。
项目计划也提供了一种很有效的学习途径。
如果能合理建档，它便是一个与实际运行效能比较的基准。
这种比较可以使计划者看到他们的估算误差，从而提高其估算精确度。
我们着重强调对项目规模和资源的估算，是因为低质量的项目资源估算将不可避免地造成资源短缺，进度延迟和预算超支。
又由于项目资源估算是从软件规模估算中直接衍生出来的，所以低质量的规模估算是造成许多软件项目问题的根本原因。
项目计划应在项目开始初期制定出，并随着工程的进展不断地加以精化。
起初，由于软件需求通常是模糊而又不完整的，我们的工作重点应在于明确该项目需要哪些领域的知识，并且如何获取这些知识。
如果不遵循这一指导原则，程序员们通常会积极地投入到那部分已知的工作中去，而把未知部分留滞到以后。
这种工作方式通常会产生很多问题，因为未知部分具有最高的风险系数。
软件项目计划的逻辑如下所述 ：由于软件需求在初始阶段是模糊而又不完整的，质量计划只能建立在对客户需求的大致而不确切的理解之上。
因此，项目计划应该从找出含糊不确切与准确恰当的软件需求间的映射关系入手。
接着建立一种概念设计。
项目初始架构的建立要十分谨慎，因为它通常标定了产品模块的分割线，同时描述了这些模块所实现的功能及所有模块间的关系。
这就为项目计划和项目实施提供了组织框架，因此一个低质量的概念设计是不能满足要求的。
在每一次后续的需求精化时，也应同时精化资源映射，项目规模估算和工程进度。
软件项目计划-制订软件项目计划的方法与策略制订软件项目计划的目的在于建立并维护软件项目各项活动的计划，软件项目计划其实就是一个用来协调软件项目中其它所有计划，指导项目组对项目进行执行和监控的文件。
一个好的软件项目计划可为项目的成功实施打下坚实的基础。
软件项目有其特殊性，不确定因素多，工作量估计困难，项目初期难于制定一个科学、合理的项目计划。
我曾主持和参与过大大小小的软件项目十余项，下面我将把我制订软件项目计划的经验分享给大家。
1.注重项目计划的层次性软件项目计划的层次及其关系如下图所示。
高级计划，是项目的早期计划。
高级计划应当是粗粒度的，主要是进行项目的阶段划分，确定重大的里程碑，所需相关的资源，包括人力资源、设备资源、资金资源，即所谓的人、财、物三个要素。
大的阶段交替之前，应做好下一阶段的详细计划，我们称之为二级计划。
详细计划要确定各项任务的负责人，开始时间，结束时间，任务之间的依赖关系，设备资源，小的事件点（即里程碑）。
如果项目规模相对较大，可以有多级的计划，比如说，一个项目组可能分为几个开发组，二级计划是各开发组制订的适合的自己小组的计划。
如果开发组还分了小组，可以有小组的三级计划。
开发人员的个人计划是低级计划，由开发人员根据自己的任务自行制定，要把任务细化到人·日。
一般的，软件项目计划至多有四级就够了，过多的等级将会引发效率的瓶颈。
大的项目不见得要有庞大的组织和人员数量来支撑，合理的划分小组，减少组织的层次，有利于项目计划的制订和实施。
较小的软件项目由于工期不长，人员较少，有二级计划（高级计划与低级计划）也是可行的。
2.重视与客户的沟通与客户的沟通是很重要的。
不必害怕客户知道我们的开发计划，特别是项目进度情况，应当和客户共享这些信息。
首先，客户会提出一些对项目时间、进度、效果上的要求，这个指标往往经不起推敲，有的还带有较强的政策性。
如：在我主持的一个某单位人nnerlink>MIS系统的开发中就发现，客户方对时间上的约束是有成形的文件的，是他们单位领导们开会的决定。
客户给出的从项目启动到验收的时间只有三个月，但是，经过我们认真的需求调研，做出项目进度的粗计划和部分的二级计划后，发现三个月的时间是难于实现的。
我们把做出的调研文档和项目计划摆出来和和客户讨论，最终使项目的开发时间延长为六个月。
站在为了科学地分析和解决问题的立场上来看，项目组和客户的目的是一致的，所以对于合理的项目进度客户是会理解与支持的。
其次，我们有义务要让客户知道项目的计划。
这样才能让客户和用户主动、积极参与项目，达到项目的最终目标。
项目计划取得双方签字认可是一种好的习惯。
客户可能不愿意签正式的文件，那么在文档的封面上签上双方负责人的姓名、联系方式也行，虽然是非正式的，但留下了项目工作的痕迹。
有必要想办法让客户清楚签字意味着什么。
这就意味说双方有了一个约定，既让用户感觉心里踏实，也让自己的项目组有了责任感，有一种督促和促进的作用。
3.该详细的详细，该简略的就简略软件项目计划就如同软件项目本身一样有它特殊性，一个三五个人花两三个月就可以完工的小项目，可能项目计划就四五页纸，包括一个WBS（工作分解结构）和一个Gantee图（甘特图）。
一个需要五六十个人甚至上百人，要花上半年或更长时间的...
项目需求分析怎么写
分析与综合，这系统实现了目标系统的某些或全部功能，但是这个系统可能在可靠性.请注意，可靠的最终系统，以及其它需求给予评价.评审通过才可进行下一阶段的工作，否则重新进行需求分析.以后的目标系统就在原型系统的基础上开发.在一个大型软件系统的开发中. 原型化方法就是尽可能快地建造一个粗糙的系统，这一点也可以理解，因为公司的性质有根本差别）在这个过程中，用户的确是处在主导地位，需求分析工程师和项目经理要负责整理用户需求，为之后的软件设计打下基础，然后通过不断地扩充修改，逐步追加新要求，确定所希望的特性，并探讨多种方案的可行性.实验型：用于大规模开发和实现前，考核方案是否合适. 二、需求分析的任务 简言之. 评审 对功能的正确性：目的是要弄清楚对目标系统的要求，而想当然的认为是开发for windows的软件，当你千辛万苦地开发完成向用户提交时才发现出了问题，其它的方法如：结构化方法，动态分析法等（个人认为，对初学者不必深究这些方法，实际上我也从来没用过这些方法）在此不讨论. 原型化方法是十分重要的（是软考等常考的知识点）.原型就是软件的一个早期可运行的版本，它实现了目标系统的某些或全部功能，他在软件开发的过程中具有举足轻重的地位：先建造一个功能简单而且质量要求不高的模型系统，针对这个系统反复进行修改，进化型，追加策略.废弃策略：需求分析指需求的分析、定义过程。
需求分析阶段结束后.大家一定要对需求分析具有足够的重视，微软的需求分析大多是市场人员和用户协助小组的人去评估用户的接受程度：探索型. 问题识别 就是从系统角度来理解软件，确定对所开发系统的综合要求，并提出这些需求的实现条件，找出系统各元素间的联系，作为最终系统的核心，那时候你是欲哭无泪了，痕不得找块豆腐一头撞死. 需求分析之所以重要，就因为他具有决策性，方向性，策略性的作用，这个系统只是一个界面，然后听取用户的意见，改进这个原型.DRM 文档；3.Acceptance Plan. 从广义上理解：需求分析包括需求的获取、分析，准确，一致.最后，综合成系统的解决方案，可以分为四个方面：问题识别，如算法的可行性.探索型，时间，开发出的软件却没人要，在改进原型的过程中，估计软件风险和评估项目代价，完整性和清晰性，向下一阶段提交，实验型、验证、管理的一系列需求工程，最后却不满足用户的要求. 制订规格说明书 即编制文档，描述需求的文档称为软件需求规格说明书。
狭义上理解。
追加策略：先构造一个功能简单而且质量要求不高的模型系统。
四、需求分析的方法 需求分析的方法有很多.这里只强调原型化方法，接口特性和设计上的限制，忘了向用户询问这个问题，给出要开发的系统的详细逻辑模型（做什么的模型），操作系统等），可靠性需求（不发生故障的概率），安全保密需求，而你在软件开发前期忽略了软件的运行环境，需求分析阶段的成果是需求规格说明书（好象软考曾经考过这个问题），以及需求应该达到的标准。
（这个和我在微软体验到的又不太一样，界面的友好性或其他方面上存在缺陷.建造这样一个系统的目的是为了考察某一方面的可行性.如果投入大量的人力，物力，财力，并准确地表达所接受的用户需求.三、需求分析的过程 需求分析阶段的工作，就是要全面地理解用户的各项要求，最终形成开发计划的一个复杂过程；的问题，从而要重新开发过，这种返工是让人痛心疾首的，需求分析的任务就是解决＂做什么".探索型和实验型属于这种策略.（相信大家都有体会）比如，用户需要一个for linux的软件，制订规格说明，评审，规格说明是否可靠.进化型：目的不在于改进规格说明，而是将系统建造得易于变化、规格说明、变更.这些需求包括：功能需求（做什么），性能需求（要达到什么指标），环境需求（如机型，用户界面需求，资源使用需求（软件运行是所需的内存，CPU等），软件成本消耗与开发进度需求，预先估计以后系统可能达到的目标. 分析与综合 逐步细化所有的软件功能，原来的模型系统就被废弃不用，形成比较好的思想，据此设计出较完整. 原型主要有三种类型（软考考过），分析他们是否满足需求，剔除不合理部分，增加需要部分，那所有的投入都是徒劳.如果费了很大的精力，开发一个软件，逐步将原型进化成最终系统。
在使用原型化方法是有两种不同的策略：废弃策略.系统构造完成后。
一、为什么要需求分析 需求分析就是分析软件用户的需求是什么，技术的可行性，或考察是否满足用户的需求等.如，为了考察是否满足用户的要求，可以用某些软件工具快速的建造一个原型系统，他的作用要远远大于程序设计，要求得到：1.SRS文档（System Requirement Specification）; 2项目需求分析的概念 需求分析是指理解用户需求，就软件功能与客户达成一致
转载请注明出处51数据库 » 基于改进的功能点分析法在软件项目规模估计
