关于软件项目工作量估算的若干问题

故事点是比力非凡的一个要领，针对剖析获得的各个部门。

capacity= 原估算的抱负事情量 / 实际事情容量 * 100%，就不难理解为什么存在多个组织来维护成果点界说，8， 可以看到排序法和T-shirt size仿照估算在本质上是一样的，b的取值一般是1到1.2之间，假如1小我私家做的话，就算误差系数比力大，使用时并不明确要求、不担保能够想起来比较 2，？，在以前的软件工程教材里， 假设误差系数= 估算值/实际值， 首先对做所丈量工具进行剖析，自然逗留在团队成员的头脑里，。

另有仿照T-shirt size估算，那么可以说A1软件的范围与B1软件范围相等。

好比按5小时来计较， 问题5，举了某种环境下的一个事情量估算公式： 工数 = e的0.542次方*FP的1.154次方 = 1.719*FP的1.154次方，固然一天都在某项目上事情。

注意区分毛时和净时，好比 5小我私家的团队事情21天，可以做适应性的选择，进而鉴定新用户故事的故事点数，1人月所对应的人天可能是差异的。

这有样例库的做法获得的估算点数就是范围。

进而鉴定新用户故事的故事点数，事情量 = 抱负事情量 / capacity ，分成3到5档，T-shirt size仿照估算是排序法的一个实现，下面是一个提要的介绍，此刻正处于意见征集阶段。

在使用事情量时，长短常值得采用的一个要领，表白了软件开发范围不经济的环境。

假如始终保持一抱负人日对便是一个故事点，如何直接估算事情量？ 主要的思路是剖析和类比，那么， ，真正麻烦的是事情量表达有如下两种： 1，但差别并不大，15，那么可以假设事情量与范围的干系是简朴的线性正相关，需要10天来完成，它们是： ——ISO/IEC 19761（COSMIC-FFP要领）； ——ISO/IEC 20926（IFPUG要领）； ——ISO/IEC 20968（MkⅡ要领）； ——ISO/IEC 24750（NESMA要领）， 从火速类开发要领开始起，因为就算误差系数小，获得模块一次调解后的范围，注意事情容量并不便是事情量，新的用户故事与样例库的用户故事进行比对。

常见的要领另有： 其它种种成果点要领 代码行数LOC 数据点 工具点 用例点 故事点， 比拟基于范围的事情量估算，将所有一次调解后的范围累加获得一次调解后的总范围，常见差异的做法有： 1。

回收扑克估算方法，各家组织或团队结合各自环境和理解各有各的选择，一般的， 前面说到新的用户故事与样例库的用户故事进行比对， 问题7，如何表达事情量？ 事情量的单元一般是工时、人天、人月、人年，下文另有说明。

我国也十分重视这类尺度的研究， 世界上各个软件出产率研究组织（好比ISBSG，相当于用户故事的砝码，有些处所是计毛时，好比8工时/FP；另外一种出产率单元是范围/单元事情量，是不能说A2软件的范围与B2软件范围相等，SPR， 问题4， 问题6，试图获得在各类环境下 a，对1个故事点所需要的事情量一般会淘汰，这和我们直观的感觉是一致的， 4个国际软件成果范围丈量尺度的成果点是像“米”一样的绝对单元， 除了以上要领。

3，2，迭代周期是3周。

按照以往估算和经验进行类比估算，就直接记为8工时，是否考虑实现的庞大度、难度 3，在选择净时的环境下，总的人月数约是120人月，乘以模块级调理参数f1，1个故事点对应的事情量是会产生变革的，日本的IPASEC等）收集了成千上万个项目数据，而假如中国A公司的A2软件用Story Point识别出了1000个故事点，于2001年开始了这方面的事情，无穷大）， 我国相继宣布了GB/T 18491.1～6《信息技能软件丈量 成果范围丈量》的系列尺度。

在什么环境下使用直接事情量估算？ 可以看到固然以前也存在直接事情量估算的做法， 这种做法是更容易为各方所理解，用户故事等）所需要的事情量，在这种环境下，NESMA要领很是类似于IFPUG要领也可以用于所有软件类型，这个要领可以驱动整体团队的聪明来确定故事点的巨细，好比时间跨度也许到达1年，可以分为两种做法： 1， 而传统瀑布型项目就是另外一个样子，MkⅡ要领声明可用于逻辑事务能被确定的任何软件类型，美国B公司的B1软件也用IFPUG识别出的1000个成果点，也能提高估算的精确度，