社区
研发管理
帖子详情
关于工作量估算,我提一个自己的看法
dxymm
2004-05-08 11:37:09
我们公司的项目都是差不多,很多时候可以套用,但是因为通用性没做好,导致很多时候要重写
经常做此类项目
我提一个工作量估算的公式
工作量=复杂度的平方 / 旧模式的相近度(0.1 - 0.9)
大家认为如何?
...全文
775
8
打赏
收藏
关于工作量估算,我提一个自己的看法
我们公司的项目都是差不多,很多时候可以套用,但是因为通用性没做好,导致很多时候要重写 经常做此类项目 我提一个工作量估算的公式 工作量=复杂度的平方 / 旧模式的相近度(0.1 - 0.9) 大家认为如何?
复制链接
扫一扫
分享
转发到动态
举报
AI
作业
写回复
配置赞助广告
用AI写文章
8 条
回复
切换为时间正序
请发表友善的回复…
发表回复
打赏红包
linnet2000
2004-06-11
打赏
举报
回复
功能点的计算由于开发工具的不同,参数也不同,诸如COCOMO模型等经验公式,没有实际意义。
rolandash
2004-06-08
打赏
举报
回复
都是经验公式而已,不可能强求一致
sxzz
2004-06-08
打赏
举报
回复
我不知道用你的公式最后得出的工作量是什么或多少。
我认为:
工作量的度量单位:人时、人天、人月、人年,1人年=12人月,1人月=22人天,1人天=8人时;
工作量的种类:研发工作量、管理工作量、支撑工作量。
研发工作量≈新开发软件规模*难度系数/人均生产率。
管理工作量≈项目研发工作量*比例系数。
支撑工作量≈项目研发工作量*比例系数。
在这里“新开发软件规模、难度系数、人均生产率、比例系数”将会因为各公司各团队的不同而有差别,具体的取值会因人而异,更多的会是经验数据。
软件规模的定义方法有很多文献介绍,大家可以选一些参照,较常见的定义方法是代码行定义法:
1. 小规模软件源程序行数小于5000的软件;
2. 中规模软件源程序行数为10000~50000的软件;
3. 大规模软件源程序行数为100000—500000的软件;
4. 特大规模软件源程序行数大于500000的软件。
难度系数就更主观了,可以说完全由团队实际情况根据经验给出。
我觉得这样的量化也许直观一些。
dxymm
2004-05-09
打赏
举报
回复
Good,我没从头到尾读过《人月神话》,只大致翻阅了一下,有时间一定仔细研究。
至于是1.5还是2,我觉得这是一个对开发工具熟悉的程序
如果对开发工具异常熟悉,1.5有可能,但是如果不是非常熟悉(我感觉国内大部分如此),2还是比较合理,甚至取2.5也不为过
once168
2004-05-08
打赏
举报
回复
COCOMO
zhf_karen
2004-05-08
打赏
举报
回复
嘿嘿,复杂度如何衡量?相近度如何衡量?而且,某些模块不仅仅是复杂和相近的问题,还有很多其他的问题,比如相对过于少的时间,就需要把某个模块的工作量扩大几倍,因为大家承担了过于多的压力。那么你最好还是有个系数来平衡,但是这些要素如果没有大量的用例来证明,还是会出现不是量化而是定性的问题。
不管如何工作量的考核,至少在现在,落实在最后就是主管的主观感受。仅此而已。
stonespace
2004-05-08
打赏
举报
回复
根据《人月神话》的数据,工作量和代码行数的关系是1.5次方,不是平方。复杂度和代码行数的关系应该是线性的。所以复杂度的幂用1.5可能更接近事实。
相近度的幂是不是-1就很难说了,再说感觉搂主对相近度也没有一个精确定义,很难分析相近读的影响。我感觉相近度的幂不应该是-1,相近之所以能够节省工作量,是因为可以重用,而重用导致工作量减少,应该是一个差值,比如我可以重用1000行代码,那么工作量就可以减去1000行代码的工作量。所以用减可能比用除好。
dxymm
2004-05-08
打赏
举报
回复
我的观点
复杂度可拆分成两点
1、模块数、模块功能点
2、技术难点
这里需要做一些研究,搞出一些公式或者数据表出来
相近度可以这样核算
旧模式中可利用的功能点)/旧模式的所有功能点
各位,再想想,还有什么要素要考虑进去
始终只有
一个
职业倦怠估计员与卫生保健
提
供者对工作需求和资源问题的
看法
有关
通常使用五个“高”倦怠
估算
器。 每个模型都基于“倦怠综合症”三个方面的不同子集,因此每个模型都给出了人群中“高”倦怠发生率的不同估计。 经理们常常不知道这些流行率是无与伦比的。 经理们对于组织的倦怠措施与员工对工作需求和工作环境中资源问题的
看法
如何相关的了解也很少,这在组织健康调查中经常被查询到。 在当前的研究中,我们证明了使用五个“高”倦怠估计量中的每
一个
所获得的“高”倦怠发生率的差异。 我们还评估并比较了五个职业倦怠估计员协会与员工感知的问题,这些问题涉及31个工作需求和人力资源功能方面的资源。 我们通过感知到的人所报告的倦怠方面比没有感知的人(积极似然比,LR +)更多地报告了估计值,以衡量这些关联。 我们检查了五种类型的医师(6599),执业医师(2158)和医师助理(786)。 我们发现,在“高”倦怠估计中,有四个与员工对工作需求或资源问题的
看法
很少相关,而在
一个
估计中-“高”(即频繁)情绪疲惫,“高”人格解体和“低”的个人成就感(通过对三个Maslach工作倦怠量表的有效检验的单项替代指标来衡量)-在至少一项研究中,与97%(30)的工作需求和资源问题在临床上显着相关健康
提
产品经理内容分享(四):需求的
工作量
估算
以及价值如何度量
度量交付需求的数量和时间相对容易,但度量每个需求的大小则比较难落地,我们需要统一的方法来度量各个团队的需求交付规模,它有利于精细化的组织改进,推动团队以比较舒服的节奏完成承诺,还能稳妥处理紧急需求插入,潜在收益远大于成本。按照敏捷理论,迭代计划会议要对本迭代的需求进行合理拆解,
工作量
估算
,结合PO决策的需求优先级,确认本迭代要完成的用户故事有哪些。建议测试任务的划分也不要太粗,单个任务的完成时间不超过一人天,这样有利于团队找到测试效率可以
提
升的地方,同理,不同测试人员的任务也建议分开
估算
。
关于
工作量
估算
,你知道的和你不知道的一切
本文首次发布于 IEEE Software 杂志,由 InfoQ 和 IEEE Computer Society 为您呈现。 越来越多证据表明这样
一个
趋势:软件项目的成本和
工作量
超出限度,泛滥成灾。平均来看,这种泛滥大约在 30% 左右【1】。而且,对比 1980 年代和最近的调查中的
估算
准确程度,可以看出基本上没有改善。(只有 Standish Group 的分析指出
估算
准确度有显著
提
软件开发量评估法之一---德尔菲评估法
软件开发量
估算
、核算实在是太难了,方法不少但真正可用、好用实在难觅。 德尔菲法是业界流行的专家评估技术,有时还是可以参考使用,在没有历史数据的情况下,德尔菲法确实可以减少
估算
的偏差。 德尔菲法采用匿名发表意见的方式,即专家之间不互相讨论和联系,只能与调查员(组织者)通信,通过多轮次调查专家对问卷所
提
问题的
看法
,经过反复征询、归纳、修改,最后汇总成专家基本一致的
看法
,作为预测的结
软件工程复试——十三、软件项目管理
十三、软件项目管理 管理就是通过计划、组织和控制等一系列活动,合理地配置和使用各种资源用以达到既定目标的过程。 软件项目管理先于任何技术活动之前开始,并且贯穿于软件的整个生命周期之中。软件项目管理过程从一组项目计划活动开始,而制定计划的基础是
工作量
估算
和完成期限
估算
。
估算
软件规模 代码行技术 代码行技术依据以往开发类似产品的经验和历史数据,估计实现
一个
功能所需要的源程序行数。是一种比较简单的定量...
研发管理
1,268
社区成员
28,284
社区内容
发帖
与我相关
我的任务
研发管理
软件工程/管理 管理版
复制链接
扫一扫
分享
社区描述
软件工程/管理 管理版
社区管理员
加入社区
获取链接或二维码
近7日
近30日
至今
加载中
查看更多榜单
社区公告
暂无公告
试试用AI创作助手写篇文章吧
+ 用AI写文章