软件开发工作量如何评估？
1、DEADLINE是最高生产力。
2、取法其上，得乎其中，取法其中，得乎其下。你是干嘛的？项目经理都说4人月了，你跟着瞎掺和什么？
你们单位到底谁说了算？
我们一般都是把详细计划做出来，然后每个小计划再去讨论到底花多少时间，工作量在哪里，难点在哪里。
建议题主 找找软件工程方面的书看看。
手机快速回复，恕我不发链接。一个工作或者是项目的工作量的评估，会牵涉到的因素确实比较多。根据我的经验，罗列几种因素，比如使用的方法或者工具、开发者的熟悉程度、以及(部门之间的)利益关系、对项目的理解评估人员的个性。基于各种因素考量最后出现的工作量评估会有比较大的区别。
1.使用的方法或者是工具
对与一个项目，A有些现成的模块，B需要重新开始搭建，A和B对完成时间的评估自然不一样。
或是对于开发一个网站，假设合理的工作量是，做前台展示页面需要1个月，后台管理需要1个月。A会评估为1个月，等前台上线之后，再同步开始做后台管理。B可能会认为需要2个月，B认为前后台都完成，才是工作完成。
2.开发者的熟悉程度
这个容易理解，如果是一般对语言或是技术掌握不熟悉的人，花费的时间和返工的时间、沟通的时间自然就要长一点
3.(部门之间的)利益关系
公司之间的外包项目，服务方就倾向于时间长一点，考虑的因素是假设用户需求会有一部分变化或者希望从中多賺钱。公司的部门之间也是类似，营销部门总是希望越快越好，但是开发部门总是认为营销部门没有更早提出需求等等。
4.对项目的理解或者评估人员的个性
同样一个项目，类似微信，如果1000个用户数和1千万的用户数，做法上会有非常大的区别。将系统按模块划分，每个模块需要多少时间，加上之前沟通的时间和测试、实施的时间，综合在一起的时间多算上30％，是系统总时间。人员水平有高低，按平均算。
如果有技术难点和需求变更，还多需要时间在不同阶段，可能有不同的评估方式
在投标及方案阶段，估工作量更多比较倚重个人经验或历史估算法（有类似的参考项目），更多是基于粗的工作范围去评估。这个工作量评估结果是为了支撑售前用的
在项目立项后的计划阶段，工作量评估会基于前面工作范围分解出的wbs进行评估，同时考虑deadline、技术难点、需求变更风险等等因素。
在实际开发过程中，工作量评估还需要根据多种实际情况随时使用，不同的开发模式或开发模式也是影响工作量评估的因素之一拆分：
方案很简单，负责庞大的东西是无法评估过工作量的。唯一的办法就拆分，洗到每个功能点，程度是能给出时间。
然后汇总统计
当然还跟团队的技术有关。
软件价值评估办法：
软件估值 = 开发成本*物价指数调整系数*利润调整系数
举例： 某《xxx管理系统》经评估工作人员对委托方提供的账目单据等进行核查验定，研制开发期间，工资及福利费用74224.11元，原材料耗费445463.18元，低值易耗品耗用1725元，办公及管理费64695.86元，差旅费19389.5元，累计折旧98470.42元，装修费分摊共37790.68元，房租85000元，财务费用277062.2元，其他费用52871.27元。其研制成开发成本＝74224.11+445463.18+1725+64695.86+19389.5+98470.42+37790.68+85000+277062.2+52871.27=1156692.22(元)
以上的成本费用数据，其主要构成为人工及原材料等费用，考虑到2002-2004年评估基准日较开发研制日的物价指数上涨约为20％，确定物价指数调整系数为1.2。据估价工作人员了解，软件市场利润率较高，但考虑该软件刚刚面市，其应用方面有一定的局限性，开拓销售市场有一定的难度，参考该公司提供的产品规则书中发售计划中，薄利多销、占领市场的宗旨，暂定其产品利润率为30％，利润调整系数为1.3，该软件市场总价值为：1156692.22×1.2×1.3=1804439.8(元)
软件项目工作量和成本估算一般分专家经验法、WBS法、类比类推法、参数方程法。而专家经验法和WBS法都是基于人的经验的一种定性的方法。好处是这种方法简单可行，但是存在的问题也比较明显：1、方法不可复制，对专家的依赖性很强； 2、受专家局限性影响，针对同一个项目不同的专家给出的数额可能相差几倍； 3、估算过程不可见，基本是个黑盒。4、估算结果经不起推敲，缺乏科学性，完全依赖于专家个人的经验。类比类推法依赖于过去有过同类项目的数据，所以局限性比较强。我推荐的是参数法。工业和信息化部2013年发布的标准《软件研发成本度量规范》主要也是这种方法。第一步，按照国际相关标准度量软件项目的规模并根据项目属性对规模进行调整；第二步，根据行业基准数据发布的生产率（功能点耗时率）或者本组织的历史数据，并根据项目特点选取调整参数，计算出工作量（人月），第三部，用工作量乘以人月费率得出软件开发成本。目前一直采用这种方法。但是这种方法要自己学习还是有一定难度。有专门的培训，你可以去了解一下。软件工程造价师的培训。还有一本公开出版物《软件研发成本度量规范释义》，有兴趣可以去买下，各大网店也都有卖，我买过，还挺不错的。
软件开发工作量评估方法，国家这几年已经发布了相关的标准，工信部行标《软件研发成本度量规范》、北京市地标《信息化项目软件开发费用测算规范》等，你可以去看看。我们公司目前也在使用这些标准中规定的方法，效果不错。简单来说，就是先估算功能点规模，再利用估算数据模型估算处工作量，在乘以人月费率。我们使用的数据是 北京软件造价评估技术创新联盟发布的，他们每年发布一次，算是目前最为权威的数据了。
在讨论软件工作量估算方法前，首先要清楚什么事软件工作量估算。
我理解的工作量估算，就是估算软件项目所耗费的资源数，这个资源包含人力和时间，一般用人天、人月的形式来衡量。（而软件的成本=耗费的资源*资源的单价）。而且我个人觉得软件工作量与软件规模是不等的，规模是指大小是固定的，而一个软件开发的工作量与许多因素有关，如公司的效率啊，参与开发人员的编程水平等。
从估算单位角度来说，工作量估算的方法分为两类：直接估算法和间接估算法。直接法指基于WBS的工作量估算方法，直接估算出人天工作量；间接估算法是先估算软件规模，再转换成人天工作量。根据估算角度的不同，间接法又分为基于代码行（SLOC）的工作量估算方法和基于功能点（FP）的工作量估算方法。
1、基于WBS的工作量估算
基于WBS的工作量估算方法，是最常见的一种估算方法，也是厂商最常用的。基于WBS的工作量的估算方法，又称为由底向上法（自下而上法），通常的估算步骤如下：
1）寻找类似的历史项目，进行项目的类比分析，根据历史项目的工作量凭经验估计本项目的总工作量；
2）进行WBS分解，力所能及地将整个项目的任务进行分解；
3）参考类似项目的数据，采用类比法或专家法，估计WBS中每类活动的工作量；
4）汇总得到项目的总工作量；
5）与第1）步的结果进行印证分析，根据分析结果，确定估计结果。
2、基于代码行的工作量估算
基于代码行（SLOC）的工作量估算，是从开发者的技术角度出发来度量软件。代码行数是软件开发者最早进行规模测量的主要方法。进行工作量估算时，先采用WBS法、类比法等统计出软件项目的代码行数，然后将代码行数转换为人天数。其中，将代码行（SLOC）转换成人天数主要有2种方法。
(1）生产率方法：要求有开发商每人天开发的代码行数，估算出代码行数后，直接利用代码行数÷SLOC/人天，即得工作量人天数。
(2）参数模型法：利用模型，将代码行数转换成人天数。
常见的模型有：
Putnam模型
Putnam1978 年提出的一种动态多变量模型。估算工作量的公式是：K = L^3/(Ck^3*td^4)
其中：L 代表源代码行数（以行计），K代表整个开发过程所花费的工作量（以人年计），td 表示开发持续时间（以年计），Ck表示技术状态常数，它反映“妨碍开发进展的限制”，取值因开发环境而异。
COCOMOⅡ模型
COCOMOⅡ模型指出，软件开发工作量与软件规模呈指数关系，并且工作量受16个成本驱动因子的影响。COCOMO Ⅱ的计算步骤如下：
1)估算软件规模Size，这里以千代码行（KSLOC）计。
2)评估比例因子SF，求指数E。
3)求成本驱动因子值EMi。求标称进度工作量PM：
IBM模型
IBM模型是1977年IBM公司的Walston和Felix提出的。其中估算工作量的公式如下：E=5.2×L^0.91 ，L是源代码行数（以千行计），E是工作量（以人月计）
3、基于功能点的工作量估算
基于功能点（FP）的工作量估算，是从用户的角度来度量软件。进行工作量估算时，先估计出软件项目的功能点数，然后将功能点数（FP）转换为人天数。其中，估算功能点数的主要方法有3种：IFPUG法、MarkⅡ法、COSMIC FFP法。这三种方法现在都已经成为国际标准，并有详细的操作手册。
将功能点（FP）转换成人天数主要有2种方法。
1）生产率法：要求有开发商每人天开发的功能点数，估算出功能点数后，直接利用功能点数÷功能点/天，即得工作量人天数。对于开发商每人天开发的功能点数，SPR有统计，中国的值大约在5.5个功能点/人月。
2）经验模型法
可以依照本企业的历史数据得到关于功能点和工作量的统计方程；也可以采用已有的经验模型，例如：COCOMOⅡ模型
某楼的利益相关喷子呵呵了，题主好脾气。
1、需求确定的情况很少，因为客户的需求总是在变，即使确定下来，验收的时候也会提出新的问题，这个要靠项目经理沟通，用户当前的问题在这个版本中解决还是下期合同来做。因此来说，需求大体确定以后，拆分子系统组成---子系统的组成模块--细分模块组成，这个是相对粗粒度的，然后就要考虑你手头队伍对细分模块的开发实现能力，大体就知道工作量了，如果不赶工期，时间要放长，软件开发，没有一帆风顺的，肯定会有很多问题，简单来说就是常见的需求变更。
2、评估成员工作量，首先要了解队伍组成，哪些人规划流程清晰，哪些人对技术攻关能力更好，哪些人适合测试，哪些人编码快速，哪些人对数据库精通，哪些人对界面布局更擅长，哪些人有技术的同时更善于沟通。所以通常都是更善于沟通的做组长，及时把流程清晰的告诉组员，反馈每个组员的工作进度，协同组员进度并决定何时由何人做技术攻坚，何时组织测试。
3、项目完成以后就好统计了，每个小组的代码行数，实现的功能模块数量，供其他小组调用的模块，用时多少天，涉及多少领域等，其实这个统计不能说a组完成项目的40%，b组60%这样，比较合理的应该是在某个方面，各个小组的组成比例的表格，然后有个小组工作的总结比较合适。如代码统计，a组2w行，占40%，b组3w，占60%。 模块数量：a组6个，占60%，b组4个占40%，并附模块结构的说明。当然，各个公司的管理不一样，统计方式不一样，反正一个原则就是尽量兄弟们多说点好话，因为一个软件做成，每个环节都不能差的，再好的汽车，如果没有一个很普通的小小铁板当刹车踏板，你敢开吗。
