一个软件项目如何评估工作量和成本?
展开全部 各阶段工作量比例用于衡量设计项目在分阶段时各阶段的费用额度。
因为根据收费标准计算方法得出的设计费是项目在设计阶段中的全部费用,而大多数的项目一般都分初步设计和施工图设计两个阶段(建筑工程等行业还有方案设计阶段),如果发包方将项目分阶段发包,那么每个阶段各占计算设计费的多少,就需要按照标准中给出的各阶段工作量比例来分摊。
例如,在建筑工程中某家设计单位完成方案设计后,发包方没有继续委托该家设计单位做后续设计,那这家设计单位就只能得到根据方案设计阶段的工作量比例对应的费用,也就是方案设计费=整个项目设计费*工作量比例;如果项目的设计都交给同一家设计单位完成,那么各阶段工作量比例就作为作为按进度支付设计费的分摊比例,比如,在建筑工程中完成了方案设计,就按方案设计的工作量比例支付。
...
如何评估软件项目的工作量(人/天)
一个工作或者是项目的工作量的评估,会牵涉到的因素确实比较多。
根据经验,罗列几种因素,比如使用的方法或者工具、开发者的熟悉程度、以及(部门之间的)利益关系、对项目的理解评估人员的个性。
基于各种因素考量最后出现的工作量评估会有比较大的区别。
1.使用的方法或者是工具对于一个项目,A有些现成的模块,B需要重新开始搭建,A和B对完成时间的评估自然不一样。
或是对于开发一个网站,假设合理的工作量是,做前台展示页面需要1个月,后台管理需要1个月。
A会评估为1个月,等前台上线之后,再同步开始做后台管理。
B可能会认为需要2个月,B认为前后台都完成,才是工作完成。
2.开发者的熟悉程度这个容易理解,如果是一般对语言或是技术掌握不熟悉的人,花费的时间和返工的时间、沟通的时间自然就要长一点3.(部门之间的)利益关系公司之间的外包项目,服务方就倾向于时间长一点,考虑的因素是假设用户需求会有一部分变化或者希望从中多赚钱。
公司的部门之间也是类似,营销部门总是希望越快越好,但是开发部门总是认为营销部门没有更早提出需求等等。
4.对项目的理解或者评估人员的个性同样一个项目,类似微信,如果1000个用户数和1千万的用户数,做法上会有非常大的区别。
软件开发过程中一般会分哪几个阶段
计划对所要解决的问题进行总体定义,包括了解用户的要求及现实环境,从技术、经济和社会因素等3个方面研究并论证本软件项目的可行性,编写可行性研究报告,探讨解决问题的方案,并对可供使用的资源(如计算机硬件、系统软件、人力等)成本,可取得的效益和开发进度作出估计,制订完成开发任务的实施计划。
分析软件需求分析就是对开发什么样的软件的一个系统的分析与设想。
它是一个对用户的需求进行去粗取精、去伪存真、正确理解,然后把它用软件工程开发语言(形式功能规约,即需求规格说明书)表达出来的过程。
本阶段的基本任务是和用户一起确定要解决的问题,建立软件的逻辑模型,编写需求规格说明书文档并最终得到用户的认可。
需求分析的主要方法有结构化分析方法、数据流程图和数据字典等方法。
本阶段的工作是根据需求说明书的要求,设计建立相应的软件系统的体系结构,并将整个系统分解成若干个子系统或模块,定义子系统或模块间的接口关系,对各子系统进行具体设计定义,编写软件概要设计和详细设计说明书,数据库或数据结构设计说明书,组装测试计划。
在任何软件或系统开发的初始阶段必须先完全掌握用户需求,以期能将紧随的系统开发过程中哪些功能应该落实、采取何种规格以及设定哪些限制优先加以定位。
系统工程师最终将据此完成设计方案,在此基础上对随后的程序开发、系统功能和性能的描述及限制作出定义。
设计软件设计可以分为概要设计和详细设计两个阶段。
实际上软件设计的主要任务就是将软件分解成模块是指能实现某个功能的数据和程序说明、可执行程序的程序单元。
可以是一个函数、过程、子程序、一段带有程序说明的独立的程序和数据,也可以是可组合、可分解和可更换的功能单元。
模块,然后进行模块设计。
概要设计就是结构设计,其主要目标就是给出软件的模块结构,用软件结构图表示。
详细设计的首要任务就是设计模块的程序流程、算法和数据结构,次要任务就是设计数据库,常用方法还是结构化程序设计方法。
编码软件编码是指把软件设计转换成计算机可以接受的程序,即写成以某一程序设计语言表示的"源程序清单"。
充分了解软件开发语言、工具的特性和编程风格,有助于开发工具的选择以及保证软件产品的开发质量。
当前软件开发中除在专用场合,已经很少使用二十世纪80年代的高级语言了,取而代之的是面向对象的开发语言。
而且面向对象的开发语言和开发环境大都合为一体,大大提高了开发的速度。
软件测试软件测试的目的是以较小的代价发现尽可能多的错误。
要实现这个目标的关键在于设计一套出色的测试用例(测试数据与功能和预期的输出结果组成了测试用例)。
如何 才能设计出一套出色的测试用例,关键在于理解测试方法。
不同的测试方法有不同的测试用例设计方法。
两种常用的测试方法是白盒法测试对象是源程序,依据的是程序内部的的逻辑结构来发现软件的编程错误、结构错误和数据错误。
结构错误包括逻辑、数据流、初始化等错误。
用例设计的关键是以较少的用例覆盖尽可能多的内部程序逻辑结果。
白盒法和黑盒法依据的是软件的功能或软件行为描述,发现软件的接口、功能和结构错误。
其中接口错误包括内部/外部接口、资源管理、集成化以及系统错误。
黑盒法用例设计的关键同样也是以较少的用例覆盖模块输出和输入接口。
维护维护是指在已完成对软件的研制(分析、设计、编码和测试)工作并交付使用以后,对软件产品所进行的一些软件工程的活动。
即根据软件运行的情况,对软件进行适当修改,以适应新的要求,以及纠正运行中发现的错误。
编写软件问题报告、软件修改报告。
一个中等规模的软件,如果研制阶段需要一年至二年的时间,在它投入使用以后,其运行或工作时间可能持续五年至十年。
那么它的维护阶段也是运行的这五年至十年期间。
在这段时间,人们几乎需要着手解决研制阶段所遇到的各种问题,同时还要解决某些维护工作本身特有的问题。
做好软件维护工作,不仅能排除障碍,使软件能正常工作,而且还可以使它扩展功能,提高性能,为用户带来明显的经济效益。
然而遗憾的是,对软件维护工作的重视往往远不如对软件研制工作的重视。
而事实上,和软件研制工作相比,软件维护的工作量和成本都要大得多。
软件项目的成本如何估算?
展开全部一、系统软件的成本构成 系统软件的成本作为一个经济学范畴,应反映软件产品在其生产过程中所耗费的各项费用,为原材料、燃料、动力、折旧、人工费、管理费用、财务费用待项开支的总和。
从财务角度来看,列入系统软件的成本有如下的项目: (1)硬件购置费如计算机及相关设备的购置,不 间断电源、空调器等的购置费。
(2)软件购置费,如操作系统软件、数据库系统软件和其它应用软件的购 置费。
(3)人工费,主要是开发人员、操作人员、管理人员、的工资福利费等。
(4)培训费。
(5)通讯费,如 购置计算机网络设备、通讯线路器材、租用公用通讯线路等的费用。
(6)基本建设费,如新建、扩建机房、购置计算机机台、机柜等的费用。
(7)财务费用。
(8)管理费用,如办公费、差旅费、会议费、交通费。
(9)材料费,如打印纸、包带、磁盘等的购置费。
(10)水、电、汽、气费。
(11)专有技术购置费。
(12)其它费用,如资料费、固定资产折旧费及咨询费。
从系统软件生命周期构成的两阶段即开发阶段和维护阶段看,系统软件的成本由开发成本和维护成本构成。
其中开发成本由软件开发成本、硬件成本和其他成本组成,包括了系统软件的分析/设计费用(含系统调研、需求分析、系统分析)、实施费用(含编程/测试、硬件购买与安装、系统软件购置、数据收集、人员培训)及系统切换等方面的费用;维护成本由运行费用(含人工费、材料费、固定资产折旧费、专有技术及技术资料购置费)、管理费(含审计费、系统服务费、行政管理费)及维护费(含纠错性维护费用及适应性维护费用)。
二、系统软件成测算 综上所述,系统软件的成本由软件的开发和维护成本所构成,即: C=C1+C2 (1) 式中:C为系统软件的开发成本;C1为系统软件的开发成本所构成;C2为系统软件的维护成本。
1、系统软件的开发成本C1的测算。
我们认为系统软件的开发成本按其工作量及单位工作量成本来测算是可行的,具体测算方法为按系统软 件的软件规模(一般为软件源程序的指令行数,不包括注释行)、社会平均规模指数以及工作量修正因素来 进行。
尤其是CAD系统软件的实际测算,结合国内外研究成果的综合分析和专家咨询,软件社会平均生产率 参数和软件社会平均规模指数可分别确定为3.5和1.3左右;软件工作量订由八个因子、五个等级组成。
2、系统软件维护成本C2的测算。
系统软件的维护为修正现有可运行软件并维护欺其主要功能不变的过程。
系统软件在其交付使用后,其维护阶段在软件生命周期或生存期中占较大比重,有的可达软件生存周期的50-70%。
因此,系统软件的维护成本是软件成本测算中不可忽略的一部分。
系统软件的维护包括三类:A、改正、纠正性维护;B、适应性维护;C、完美性维护。
其中C类是为扩充 功能、提高性能而进行的维护,在软件资产价值评估中一般不计入该系统软件成本,而A、B两类,则与软 件的开发过程有着紧密的联系,应计入软件成本。
在系统软件维护阶段,对软件工作量的影响因素与开发阶段的影响因素基本相同,是开发阶段影响因素 的后的影响。
因此,系统维护的可靠性越大,规模越复杂,隐错越难发现,纠错越难。
系统软件越复杂, 要使其适应软、硬环境变化,进行适应性维护也越困难。
当然,可靠性大、复杂度高的系统软件,其可维 护性要求也越高,软件在运行中出错的可能性也会少些。
基于上述分析,系统软件维护成本的测算,可按 系统软件开发成本乘以一个该系统软件的维护参数来求取。
这一维护参数,可按系统软件的复杂度从简单 到一般、到复杂的顺序,分别取0.15、0.20、0.25及0.30、0.35、0.40等。
计算机系统软件作为计算机系统的组成部分,是信息社会的重要商品,也是知识经济社会中的重要资产。
系统软件同其他计算机软件一样,具有如下的特点: 1、系统软件是由许多人共同完成的高强度智力劳动的结晶,是建立在知识、经验和智慧基础上的具有独 创性的产物。
系统软件的开发可以工程化,软件生产可以工厂化,因此,系统软件具有价值和使用价值。
同时,系统软件具有独创性(即原始性),所以软件著作权人对系统软件产品依法享有发表权、开发者身份权、使用权、许可权、获取报酬权及转让权。
2、系统软件产品是无形的,存在于磁盘等介质的有形载体中,通过载体进行交易。
因此,带有系统 软件的磁盘交换价值,是磁盘自声价值与系统软件之和,而且主要是系统软件的价值。
3、系统软件产品的复制(批量生产)相应简单,其复制成本同其开发成本比较,几乎可以忽略不 计。
因此,系统软件产品易被复制乃至剽窃。
为保护系统软件产品的著作权,必须依法登记。
4、系统软件产品一般没有有形损耗,仅有无形损耗。
系统软件产品的维护,一是由于系统软件自身 的复杂性,特别是为了对运行中新发现的隐错进行改正性维护;二是由于系统软件对其硬、软件环境有依赖性。
硬、软环境改变时,系统软件要进行适应性维护;三是由于需求的变化,要求增强系统软件功能和提高系统软件性能,系统软件要进行完美性维护。
因此,系统软件的维护在...
项目工作量的评估中,“人天”是什么单位?
“人天”指一个人工作一天的工作量,这里的一天指的是8小时,所以就是一个人工作8小时的工作量。
“工作量(人天)”也指一个人工作一天的工作量,这里的一天指的是8小时,所以就是一个人工作8小时的工作量。
拓展资料:1. 工作量期待于雇员或分配给雇员的多少工作或工作时间2. 一个部门或其他集团的工人在一段时间内完成的全部工作3. 每周工作量实际工作任务或可达工作任务工人们愿意接受按计时定额方法所规定的工作量参考资料:工作量--百度百科
软件项目计划的计划制定
展开全部项目计划详细说明了所需软件工作及如何实现。
它定义了每一个主要任务,并估算其所需时间和资源,同时为管理层的评估和控制提供了一个框架。
项目计划也提供了一种很有效的学习途径。
如果能合理建档,它便是一个与实际运行效能比较的基准。
这种比较可以使计划者看到他们的估算误差,从而提高其估算精确度。
我们着重强调对项目规模和资源的估算,是因为低质量的项目资源估算将不可避免地造成资源短缺,进度延迟和预算超支。
又由于项目资源估算是从软件规模估算中直接衍生出来的,所以低质量的规模估算是造成许多软件项目问题的根本原因。
项目计划应在项目开始初期制定出,并随着工程的进展不断地加以精化。
起初,由于软件需求通常是模糊而又不完整的,我们的工作重点应在于明确该项目需要哪些领域的知识,并且如何获取这些知识。
如果不遵循这一指导原则,程序员们通常会积极地投入到那部分已知的工作中去,而把未知部分留滞到以后。
这种工作方式通常会产生很多问题,因为未知部分具有最高的风险系数。
软件项目计划的逻辑如下所述 :由于软件需求在初始阶段是模糊而又不完整的,质量计划只能建立在对客户需求的大致而不确切的理解之上。
因此,项目计划应该从找出含糊不确切与准确恰当的软件需求间的映射关系入手。
接着建立一种概念设计。
项目初始架构的建立要十分谨慎,因为它通常标定了产品模块的分割线,同时描述了这些模块所实现的功能及所有模块间的关系。
这就为项目计划和项目实施提供了组织框架,因此一个低质量的概念设计是不能满足要求的。
在每一次后续的需求精化时,也应同时精化资源映射,项目规模估算和工程进度。
软件项目计划-制订软件项目计划的方法与策略制订软件项目计划的目的在于建立并维护软件项目各项活动的计划,软件项目计划其实就是一个用来协调软件项目中其它所有计划,指导项目组对项目进行执行和监控的文件。
一个好的软件项目计划可为项目的成功实施打下坚实的基础。
软件项目有其特殊性,不确定因素多,工作量估计困难,项目初期难于制定一个科学、合理的项目计划。
我曾主持和参与过大大小小的软件项目十余项,下面我将把我制订软件项目计划的经验分享给大家。
1.注重项目计划的层次性软件项目计划的层次及其关系如下图所示。
高级计划,是项目的早期计划。
高级计划应当是粗粒度的,主要是进行项目的阶段划分,确定重大的里程碑,所需相关的资源,包括人力资源、设备资源、资金资源,即所谓的人、财、物三个要素。
大的阶段交替之前,应做好下一阶段的详细计划,我们称之为二级计划。
详细计划要确定各项任务的负责人,开始时间,结束时间,任务之间的依赖关系,设备资源,小的事件点(即里程碑)。
如果项目规模相对较大,可以有多级的计划,比如说,一个项目组可能分为几个开发组,二级计划是各开发组制订的适合的自己小组的计划。
如果开发组还分了小组,可以有小组的三级计划。
开发人员的个人计划是低级计划,由开发人员根据自己的任务自行制定,要把任务细化到人·日。
一般的,软件项目计划至多有四级就够了,过多的等级将会引发效率的瓶颈。
大的项目不见得要有庞大的组织和人员数量来支撑,合理的划分小组,减少组织的层次,有利于项目计划的制订和实施。
较小的软件项目由于工期不长,人员较少,有二级计划(高级计划与低级计划)也是可行的。
2.重视与客户的沟通与客户的沟通是很重要的。
不必害怕客户知道我们的开发计划,特别是项目进度情况,应当和客户共享这些信息。
首先,客户会提出一些对项目时间、进度、效果上的要求,这个指标往往经不起推敲,有的还带有较强的政策性。
如:在我主持的一个某单位人nnerlink>MIS系统的开发中就发现,客户方对时间上的约束是有成形的文件的,是他们单位领导们开会的决定。
客户给出的从项目启动到验收的时间只有三个月,但是,经过我们认真的需求调研,做出项目进度的粗计划和部分的二级计划后,发现三个月的时间是难于实现的。
我们把做出的调研文档和项目计划摆出来和和客户讨论,最终使项目的开发时间延长为六个月。
站在为了科学地分析和解决问题的立场上来看,项目组和客户的目的是一致的,所以对于合理的项目进度客户是会理解与支持的。
其次,我们有义务要让客户知道项目的计划。
这样才能让客户和用户主动、积极参与项目,达到项目的最终目标。
项目计划取得双方签字认可是一种好的习惯。
客户可能不愿意签正式的文件,那么在文档的封面上签上双方负责人的姓名、联系方式也行,虽然是非正式的,但留下了项目工作的痕迹。
有必要想办法让客户清楚签字意味着什么。
这就意味说双方有了一个约定,既让用户感觉心里踏实,也让自己的项目组有了责任感,有一种督促和促进的作用。
3.该详细的详细,该简略的就简略软件项目计划就如同软件项目本身一样有它特殊性,一个三五个人花两三个月就可以完工的小项目,可能项目计划就四五页纸,包括一个WBS(工作分解结构)和一个Gantee图(甘特图)。
一个需要五六十个人甚至上百人,要花上半年或更...
软件项目中的计划阶段项目目标和范围是什么?
开始一个新项目或版本时候,首先是和用户一起确认需求,进行项目的范围规划。
项目是范围,进度,质量和资源四要素的平衡,用户对项目进度要求和优先级高的时候,我们往往要缩小项目范围,对用户需求进行优先级排序,排除优先级低的需求。
另外我们做项目范围规划的一个重要依据就是我们的历史经验数据,对项目特征的清楚认识,项目范围规划初期需求你进行一个较宏观的估算,否则你很难判断清楚或给用户承诺在现有资源情况下,你3个月时间里面是否可以完成20个或更多用户功能。
正规过程好像是先确认项目范围,然后根据WBS->进度计划确认实际的项目周期,但实际情况往往很难如此,用户往往对进度的关注度大于对范围的关注度,一个项目半年或一年都看不到具体的产品出来用户肯定是无法接受的,所以我们的软件项目一般也是按版本增量迭代进行开发。
另外这里需要强调下项目目标的确定,项目的目标不能简单理解为在某个时间点完成所有功能。
项目另外一个重要目标就是项目的质量目标,你完成的这个项目需要达到那个等级的质量标准,交出的产品BUG泄漏率要控制在什么范围内等内容。
项目的质量目标不会影响到我们的范围,但会影响到我们后续评审,测试等时间的安排,直接影响到项目的进度。
PMBOK里已经明确提到项目范围定义的另一个重要目的就是项目的绩效测量和验收准则,你交付项目的时候用户会根据用户需求说明书内容对项目进行验收,所有我们项目的范围的定义必须是明确,量化,可验证和可测试的,这样才能够避免后期无谓的纠纷。
另外在概述阶段需要分析项目的假设和约束,假设和约束又分为技术方面和非技术方面,在这里我们分析的所有假设都可能成为项目的风险。
2.项目进度的确定 项目的目标和范围确定后,需要开始确定项目的过程,项目整个过程中采用何种生命周期模型?项目过程是否需要对组织级定义的标准过程进行裁剪等相关内容。
项目过程定义是进行WBS分解前必须确定的一个环节,你采用瀑布模型和增量迭代模型对WBS分解和进度计划安排显然是完全不同的。
项目过程确认清楚后开始进行项目的WBS分解,WBS分解一般是项目组的核心成员参加,但项目经理应该是起主导和协调作用。
WBS分解方法一般有基于过程和基于成功两种方式,但两种方式可以混合使用,比如在高层分解的时候先分解出子系统和工作包,在底层的时候再按照需求,设计,编码和测试各个过程进行分解。
WBS的最底层工作单元需要是可以独立核实的产品,需要去下达计划和任务,工作单元需要有明确的责任人,因此有时候在没有做仔细的估算时候我们很难让工作单元满足这些要求,这样就难免在进行估算过程中还要对WBS进行优化和调整。
WBS分解完成后可以开始进行工作单元的估算,估算一般有专家法,三点法和功能点法估算,由于我们的项目采用专家法估算,因此更需要项目核心成员和有经验的成员参加,估算一般会针对工作单元的单位和复杂度进行估算,最后估算出项目的总规模,再除以项目的生产率后得到项目的工作量数据。
专家法估算一般会进行很多轮,直到所有指标都收敛(收敛标准是组织或项目事先确定清楚了,如偏差人员的责任矩阵进行分析,对于关键路径一般直接用运筹学中的关键路径分析法确定ES,EF,LE和LF四个时间即可。
在项目进度计划基本排出来后就可以规划和确定项目的里程碑和基线了,项目的里程碑和基线是项目重要的跟踪控制检查点,在里程碑项目还会做专门的里程碑报告,对项目的当前状态,项目的进度,工作量,规模,缺陷等各项指标的偏离进行分析。
整个项目进度计划基本出来后需要和项目组的所有项目成员确认,获取项目的内部承诺,项目成员应该对整个进度计划安排基本达成一致。
项目计划还有需要支持计划需要制定,项目进度计划出来后整个可以通知QA和配置管理员分别制定质量保证计划和配置管理计划,项目经理协助测试负责人制定项目的系统测试计划。
如何核算一个软件开发项目的成本?
一、项目阶段划分软件项目全过程可分为:立项阶段、建设阶段、完成阶段。
不同阶段工作重点不同。
为保证软件项目开发质量,避免因需求不确定,或者频繁更改所造成的成本上升,同时也利于项目费用概算,软件项目建设最好采取“总体规划、分段实施”的原则。
1、立项阶段:可委托专业技术咨询机构或者专家进行项目的可行性分析,需求分析;根据需求分析,进行系统设计;根据需求分析、系统设计,计算工作量,估算项目建设费(预算);根据项目概算进行招投标,确定软件开发商,签订建设合同。
2、建设阶段:由软件开发商根据前期需求分析和系统设计,进行编码实现,并负责安装实施、运行维护等工作。
项目实施完毕,需委托第三方测试机构进行验收测试。
3、完成阶段:项目完成后,在需求变更较大的情形下,可委托专业技术机构根据实际工作量估算项目建设费(决算),项目结束。
二、 各阶段费用构成各阶段的所有费用可分为四类:1、咨询费:包括立项阶段的可行性分析,需求分析、系统设计、估价、招投标等方面的工作所需要支出的费用。
2、服务费:第三方测试机构的验收测试费、监理单位的监理费、进行数据扫描录入等方面工作的数据处理费等。
3、建设费:软件开发商在开发、实施、维护等方面工作的费用。
其中包括:软件开发费、系统实施费、运行维护费。
4、附加费:针对具有特殊性质的软件开发项目。
如:若需要提交源程序,必须增加知识产权费;若涉及保密方面的工作,则须增加保密费用等。
三、按照各阶段的成本费用内容,进行账务归拢,依据会计准则准确核算并登记各项成本费用数据即可
转载请注明出处51数据库 » 软件项目各阶段工作量比例
外貌協會理事長