简要描述软件项目管理中工作量估算的专家估计方法和模型方法
1传统意义上的项目管理软件更多的是管理项目的资源、任务、进度、质量,而忽略了项目管理的最终目标——项目成本控制。
诺明软件为例,通过项目管理软件,可全面核算各类项目成本,其中包括人工、费用、材料、设备、管理分摊、外包等项目成本的精细化管理,帮助财务人员轻松完成项目成本核算过程,同时帮助项目经理实时了解项目实际产生的各项成本。
...
软件规模的估算方法有哪几种?
软件规模的估算方法有很多种,如:功能点分析(FPA:functionpointsanalysis)、代码行(LOC:linesofcode)、德尔菲法(Delphitechnique)、COCOMO模型、特征点(featurepoint)、对象点(objectpoint)、3-D功能点(3-Dfunctionpoints)、Bang度量(DeMarcosbangmetric)、模糊逻辑(fuzzylogic)、标准构件法(standardcomponent)等,这些方法不断细化为更多具体的方法
软件项目中的成本构成的估算方法是什么
、系统软件的成本测算程序 1、根据待开发软件的特征、所选用硬件的特征、用户环境特征及以往同类或相近项目的基础数据,进行软件规模测算。
2、由系统软件的成本构成,结合成本影响因素、环境因素以及以往同类或相近项目数据分析,进行软件 成本测算。
其中包括了安装、调试的人力和时间表、培训阶段的人力和时间表。
3、系统软件成本测算的风险分析。
这是基于系统软件成本测算的不确定性、成本测算的理论和测算技术 的不成熟性而提出的工作程序。
系统软件成本测算的风险因素应包括: (1)对目标系统的功能需要、开 发队伍、开发环境等情况的了解的正确性; (2)所运用历史数据及模型参数的可靠性; (3)系统分析 中的逻辑模型的抽象程度、业务处理流程的复杂程度及软件的可度量程度; (4)软件新技术、替代技术的出现和应用对成本测算方法的冲击的影响; (5)用户在系统软件开发中的参 与程度,开发队伍的素质及所采用开发模式对开发成本的影响; (6)对系统软件开发队伍复杂因素认识程度; (7)系统软件开发人员及其组成比便的稳定性; 来源:www.examda.com (8)系统软件开发和维护经费,时间要求等方面的变更等非技术性因素所带来的风险等。
在系统软件价值评估中实施上述程序进行成本测算时,除了应坚持持资产评估操作程序中规定的各项原 则外,还应遵循真实性与预见性原则、透明性与适应性原则和可操作性与规定性原则。
软件规模估算有哪些方法?
软件规模估算的假设和思路: ?软件的规模和其外延成正比 l外延包括: 功能, 数据, 用户操作界面数, 显示界面数等等 ?不同的功能点实现的困难度不同, 但从整个项目来说, 平均的困难度差不多 ?规模估算的目标:是决定工作量的大小。
对于成本模型,规模是计算软件项目的工作量、成本和进度的主要输入 ?规模估算的责任者:程序员、软件工程师、系统分析员负责决定软件项目的规模?规模估算的入口准则 :在规模估算之前,软件功能需求必须被定义。
在项目早期定义需求可能是非常困难任务。
然而,在对需求一无所知的情况下,精确的估算出项目的成本和进度是不可能的。
如果知道部分需求,那么估算基于已知的需求并且相信每一个人都相信估算仅仅是基于那些已知的需求,如果使用了增量或演进的开发策略,那么估算基于增加的已定义需求。
?规模估算输入 :软件需求说明书(SRS) 历史规模数据 ?规模估算活动 : 软件产品规模通常以代码行(SLOC)或千代码行(KSLOC)度量。
软件应该以全新代码或者合并新旧代码进行开发。
对已存在代码接口的估算与新代码的估算是同等重要的。
已存在代码借口通常需要与开发新代码相同的工作量。
?软件产品规模估算应该主要基于历史数据和经验。
历史规模数据可以从组织软件过程数据库中找到。
而且,两个或更多的具有类似经验的软件工程师应该开展自顶向下/自底向上规模估算,步骤如下:A) 基于定义每个计算机软件模块的需求开发系统的高级架构图B) 基于每个计算机软件模块开发功能WBSC) 根据相似项目经验和历史数据,为每一个软件模块手工估算出最底层(自底向上)可能详细的代码行或功能点,规模估算工具可以作为第二个输入D) 估算出期望的规模加上标准偏差,即:规模的最低值和最高值来反映名义值的不确定性。
在项目的早期阶段,最低和最高估算结果之间的范围可能是30-50%,例如:概念阶段。
如果缺乏经验或有较高的技术风险,范围将会更大E) 具有类似经验的软件工程师应该评审并优化估算结果直至达成一致意见。
经验表明,规模估算经常偏低,故最低规模估算结果应该给与特别审查一些规模估算的标准方法和工具如下:Wideband Delphi技术、Pert Sizing技术、功能点方法、类比法和自动化规模估算工具。
这些方法的详细描述在前面功能估算和预算制定中已经提到。
建议至少使用两种方法进行规模估算,不要依赖于任何一种方法提示:项目早期规模估算可能非常难以精确的确定。
对于单一的规模数字,取而代之使用值的范围(最大值、最小值、可能值)。
随着项目的进展,规模的确定越来越精确。
一旦项目的编码完成,就可以使用自动化的代码行工具计算程序的规模了。
目前常用的软件规模评估方法?FPA(Function Points Analyze)(1989) l主要适用于 MIS,前面已做过详细说明 ?FFP(Full Function Points)(1997) l适用于 real-time software, system software, general application, and also MIS applicationl不适用于包含复杂的数学计算的 application(如: 专家系统, 仿真软件, 自学习软件, 媒体播放等)预测性对象点(Predictive Object Points)?预测性对象点是特意为面向对象软件设计的,是通过系统计算面向对象的特征进行度量。
?POPs方法的核心是每类加权方法数(Weighted Methods per Class WMC)。
这种方法测量每个顶层类(或者说,每个在用户的视野中清楚的对象)并且根据类的行为(方法)类型不同进行加权。
一旦得到WMC的值,POPs方法将把它和有关按类分对象组的信息和对象类之间的关系进行联合计算。
=========功能点法回顾面向功能的软件度量是对软件和软件开发过程的间接度量。
面向功能度量的关注点在于程序的“功能性”和“实用性”,而不是对LOC计数。
一种典型的生产率度量法叫做功能点度量,该方法利用软件信息域中的一些计数度量和软件复杂性估计的经验关系式而导出功能点FPs(Function Points)。
功能点通过填写表1所示的表格来计算。
首先确定五个信息域的特征,并在表格中相应位置给出计数。
信息域的值以如下方式定义:§ 用户输入数:各个用户输入是面向不同应用的输入数据,对它们都要进行计数。
输入数据应有别于查询数据,它们应分别计数。
§ 用户输出数:各个用户输出是为用户提供的面向应用的输出信息,它们均应计数。
这里的输出是指报告,屏幕信息,错误信息等,在报告中的各数据项不应再分别计数。
§ 用户查询数:查询是一种联机输入,它导致软件以联机输出的方式生成某种即时的响应。
每一个不同的查询都要计数。
§ 文件数:每一个逻辑主文件都应计数。
这里的逻辑主文件,是指逻辑上的一组数据,它们可以是一个大的数据库的一部分,也可以是一个单独的文件§ 外部接口数:对所有被用来将信息传送到另一个系统中的机器可读写的接口(即磁带或磁盘上的数据文件)均应计数。
日常管理中,如何准确地估算一项工作的工作量?
idodo:敏捷加权平均法解决团队工作量估算难题日常的团队管理中,经常遇到的一个难题是如何准确地估算一项工作的工作量。
最为常见的方法是拍脑袋,如果拍后是走形式用的,也无所谓,一旦与员工的绩效和奖金挂起钩来,问题就会立马暴露出来。
那么,到底有没有什么可行操作的方法呢?做过软件开发的人都知道敏捷开发中有个评估工作量的方法-扑克牌法。
需求方讲解完需求后,几个工程师根据对需求的理解,分别给出完成该项工作的工作量,然后找出最小的工作量和最大的工作量,请他们讲讲需要那么多工作量的理由。
随后,再来重新评估工作量,直到最后达成共识或者取其平均值。
这个方法的优点兼顾了团队的能力,估算出来的工作量准确度高,缺点是达成共识较难,评估工作量占用的时间多。
敏捷法评估工作的方法完全可以拓展到其他行业中,但需要适当的改造。
团队成员评估工作量的方法不变,在完成第二轮工作量评估后,立即通过加权平均法计算出工作量,以节约时间。
笔者在营销策划团队内部进行了试用,取得了良好的效果,基本上解决了工作评估的难题。
...
项目工作量的评估中,“人天”是什么单位?
人天是工作量单位。
含义就是1个人1天做的工作量。
一个工程需要的早期评估有三项:工作量、持续时间、预算。
在这三项中,工作量必须首先评估。
当了解工程所需的工作量,你就可以分配决定工程持续时间的资源,进而可以评估人力资源和非人力资源花费。
用下面的过程来评估你的工程所需总工作量:1.决定评估所需的精确度。
典型的情况是,评估的精确度越高,所需的细节就越多,所需时间也越多。
如果要求你做一个粗略的评估(-25% - +75%),你可能会在较高的水平利用最少量的细节迅速完成工作。
另一方面,如果你必须提供一个精确的评估时(≤10%),可能需要多花一点时间,且在一个较低的水平需要更多的细节完成这项工作。
2.为每一个活动和整个工程的工作量做一个最初的评估。
有很多可用的技巧用于评估工作量,包括任务分解(工作细分结构)、专家意见、类推等。
3.添加专用资源时间。
确保你已经包括兼职人员和专用资源所需的时间。
例如,这一工程可能包括兼职人员、熟练的专家、法律人员、行政人员等。
4.考虑返工(可选的)。
在理想世界中,所有交付的工程一开始都是完美无缺,但在现实世界中,通常并不是这样。
不考虑返工的工作计划可能较容易完成,因为低估了全部的交付工程包含的工作量。
5.添加工程管理时间,这是成功的工程管理所必须的。
一般说来,增加15%的工作量用于工程管理。
例如,如果一项工程评估需要12000个小时(7-8个人),那么一个全职项目经理人(1800小时)是必须的。
如果一项工程评估需要1000小时,工程管理时间应该是150小时。
6.添加意外事故时间。
偶然是用来反映评估的不确定性和风险性,如果要求你做一项并不完全确定的评估工作,那么可能要增加50%、75%或者更多的时间以反映不确定性。
如果以前你已经多次做过这样的工程,你的意外时间可能很小——可能是5%。
7.计算加上所有细节部分的总工作量。
8.如果必要再看一遍,进行适当修改。
有时当你加上工程的所有组成部分时,评估会看起来明显的高一些或低一些。
如果你的评估看起来不正确,再回头看一下你的设想,调整所作评估以更好的反映现实情况。
我把这种情况称为从你的经理和赞助者最初的延期。
如果你的赞助商认为你评估太高,并且你也认为没有理由反对他,那么你还要在评估上作更多的工作。
要确保你的评估看起来是合理的,并且准备好反击那些反对的观点。
9.文档化所有设想。
你永远不会确切地了解一项工程的所有细节,因此,文档化所有你做出的设想和评估,这一点很重要。
10.这类严格的评估方法将会帮助你在可以获得的时间和资源的情况下尽量做出精确的评估。
项目工作量的评估中,“人天”是什么单位?
估算测试工作量的方法:1、 Ad-hoc方法这种方法下的测试工作量不基于任何确定的期限。
工作一直继续直到达到一些由管理或市场人员预先定下的时间表。
或者,一直到用完了预算的经费。
这种情况普遍存在于非常不成熟的组织,并且时常有100%的错误差数。
2、开发时间的百分比法Percentage of development time。
这个方法的基本前提是测试工作量依赖于开发时间/开发工作量。
首先,开发工作量使用例如LOC或FP方法被估算出来,然后使用一些探索性的方法来限制测试的工作量。
这种方法变化比较大而且通常基于以前的经验。
通常预留项目的总花费时间的35%给测试。
? 5-7%给组件和集成测试? 18-20%给系统测试? 10%给接收测试(或回归测试等)3、类比法(经验值法或历史数据法)根据以前或相似项目(主要在项目性质,领域,规模上有相似)所积累的经验或历史数据来估算工作量。
类比法估计结果的精确度取决于历史项目数据的完整性和准确度,因此,用好类比法的前提条件之一是组织建立起较好的项目后评价与分析机制,对历史项目的数据分析是可信赖的。
需要收集以下相关的历史数据:? 在设计和实现阶段花费的时间? 测试工作的规模,例如用户需求的数量,页面数,功能点? 数据样式,例如实体,字段的数量? 屏幕或字段数量? 测试对象的规模,例如KLOC4、WBS(work breakdown structure)估算法将项目或产品分解为具体的工作,然后分别对各个工作进行时间估算,最终求和得出项目或产品的测试工作量/时间。
5、Delphi法Delphi法是最流行的专家评估技术,在没有历史数据的情况下,这种方式可以减轻估算的偏差。
Delphi法鼓励参加者就问题相互讨论。
这个技术,要求有多种相关经验人的参与,互相说服对方……Delphi法的步骤是:1、协调人向各专家提供项目规格和估计表格;2、协调人召集小组会各专家讨论与规模相关的因素;3、各专家匿名填写迭代表格;4、协调人整理出一个估计总结,以迭代表的形式返回专家;5、协调人召集小组会,讨论较大的估计差异;6、专家复查估计总结并在迭代表上提交另一个匿名估计;7、重复4-6, 直到达到一个最低和最高估计的一致。
6、PERT估计法PERT对各个项目活动的完成时间按三种不同情况估计:一个产品的期望规模,一个最低可能估计,一个最高可能估计。
用这三个估计用来得到一个产品期望规模和标准偏差的Pert 统计估计。
Pert 估计可得到代码行的期望值E, 和标准偏差SD项目工作量评估的“人天”是:1个人工作8小时的量就是1人天。
100人天就等于1个人做100天或是100个人做一天
转载请注明出处51数据库 » 软件工作量的估算方法是