精华内容
下载资源
问答
  • 代码量评估
    千次阅读
    2012-08-08 16:49:04

    软件规模估算有哪些方法?

    软件规模估算的假设和思路: 软件的规模和其外延成正比 外延包括: 功能, 数据, 用户操作界面数, 显示界面数等等 不同的功能点实现的困难度不同, 但从整个项目来说, 平均的困难度差不多 规模估算的目标:是决定工作量的大小。对于成本模型,规模是计算软件项目的工作量、成本和进度的主要输入 规模估算的责任者:程序员、软件工程师、系统分析员负责决定软件项目的规模 规模估算的入口准则 :在规模估算之前,软件功能需求必须被定义。在项目早期定义需求可能是非常困难任务。然而,在对需求一无所知的情况下,精确的估算出项目的成本和进度是不可能的。如果知道部分需求,那么估算基于已知的需求并且相信每一个人都相信估算仅仅是基于那些已知的需求,如果使用了增量或演进的开发策略,那么估算基于增加的已定义需求。 规模估算输入 :软件需求说明书(SRS) 历史规模数据 规模估算活动 : 软件产品规模通常以代码行(SLOC)或千代码行(KSLOC)度量。软件应该以全新代码或者合并新旧代码进行开发。对已存在代码接口的估算与新代码的估算是同等重要的。已存在代码借口通常需要与开发新代码相同的工作量。 软件产品规模估算应该主要基于历史数据和经验。历史规模数据可以从组织软件过程数据库中找到。而且,两个或更多的具有类似经验的软件工程师应该开展自顶向下/自底向上规模估算,步骤如下: A) 基于定义每个计算机软件模块的需求开发系统的高级架构图 B) 基于每个计算机软件模块开发功能WBS C) 根据相似项目经验和历史数据,为每一个软件模块手工估算出最底层(自底向上)可能详细的代码行或功能点,规模估算工具可以作为第二个输入 D) 估算出期望的规模加上标准偏差,即:规模的最低值和最高值来反映名义值的不确定性。在项目的早期阶段,最低和最高估算结果之间的范围可能是30-50%,例如:概念阶段。如果缺乏经验或有较高的技术风险,范围将会更大 E) 具有类似经验的软件工程师应该评审并优化估算结果直至达成一致意见。经验表明,规模估算经常偏低,故最低规模估算结果应该给与特别审查 一些规模估算的标准方法和工具如下:Wideband Delphi技术、Pert Sizing技术、功能点方法、类比法和自动化规模估算工具。这些方法的详细描述在前面功能估算和预算制定中已经提到。建议至少使用两种方法进行规模估算,不要依赖于任何一种方法 提示:项目早期规模估算可能非常难以精确的确定。对于单一的规模数字,取而代之使用值的范围(最大值、最小值、可能值)。随着项目的进展,规模的确定越来越精确。一旦项目的编码完成,就可以使用自动化的代码行工具计算程序的规模了。 目前常用的软件规模评估方法 FPA(Function Points Analyze)(1989) 主要适用于 MIS,前面已做过详细说明 FFP(Full Function Points)(1997) 适用于 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所示的表格来计算。首先确定五个信息域的特征,并在表格中相应位置给出计数。信息域的值以如下方式定义: § 用户输入数:各个用户输入是面向不同应用的输入数据,对它们都要进行计数。输入数据应有别于查询数据,它们应分别计数。 § 用户输出数:各个用户输出是为用户提供的面向应用的输出信息,它们均应计数。这里的输出是指报告,屏幕信息,错误信息等,在报告中的各数据项不应再分别计数。 § 用户查询数:查询是一种联机输入,它导致软件以联机输出的方式生成某种即时的响应。每一个不同的查询都要计数。 § 文件数:每一个逻辑主文件都应计数。这里的逻辑主文件,是指逻辑上的一组数据,它们可以是一个大的数据库的一部分,也可以是一个单独的文件 § 外部接口数:对所有被用来将信息传送到另一个系统中的机器可读写的接口(即磁带或磁盘上的数据文件)均应计数。

    更多相关内容
  • 团队开发如何评估工作量

    千次阅读 2018-12-26 11:35:56
    A 一天(除去加班、小憩时间)能完成的工作量定义为 1 人天(也有叫”人日“的,注意两个字合起来是一个量词/单位),同时 A 的战斗力定为 1.0。这个需求按照 A 的标准要几天才能完成,则它的工...

    先划分出各端(前端、客户端、后端),每个端单独评估。需要时间最长的端即为研发所需的最少时间。

    对每个端评估时,列出参与这个项目的所有人员。为了便于描述,我们把其中技术能力最强或工作效率最高的人称为 A。

    A 一天(除去加班、小憩时间)能完成的工作量定义为 1 人天(也有叫”人日“的,注意两个字合起来是一个量词/单位),同时 A 的战斗力定为 1.0。这个需求按照 A 的标准要几天才能完成,则它的工作量可量化为多少人天。

    再把其他人员逐一跟 A 比较做评估,如果 B 一天能完成的工作量是 A 的 70%,则把 B 的战斗力定为 0.7。假如还有 C 的战斗力 0.5,则这个团队的总战斗力为 1.0 + 0.7 + 0.5 = 2.2

    如果某个需求的工作量是 11 人天,则最理想的情况下,这个3人团队需要用 11 / 2.2 = 5 天来完成。

    团队的人数越多,花在沟通上的时间也会增多。再加上可能有技术评估不准、部门会议、临时请假的情况,在估算整体所需时间时,应乘以一个大于1的浮动系数(例如 1.2)来作为最终时间。在上例中,向项目组报备的工作量应为 5 * 1.2 = 6 天。类似地,如果要 996,则可乘以一个小于 1 的系数,可以是 0.85。

    在实际情况下,并非所有团队成员都全天参与此项目,同时参加多个项目的情况很常见。如果 A 对本项目只投入一半的时间,则团队的总战斗力应算成 1.0 * 0.5 + 0.7 + 0.5 = 1.7

    除了编码技能外,影响一个人或团队的战斗力的因素还有:

    • 代码熟悉程度,是否需要先学习前人写的代码
    • 需求是否可拆分给多人合作;多人合作会不会反而更慢
    • 历史遗留问题多不多,会不会踩坑
    • 修改的地方是否重要,牵扯面是否广,引起的回归测试量是否大
    • 是否有技术方案未确定、需要预研的部分
    • 跨团队合作的部分是否有依赖,沟通是否顺畅
    • 代码质量,bug 产出率
    • 工作配套的硬件设施是否满足要求,如电脑配置

    另外特别注意的是如何定义“完成”,“完成”是指编写完代码还是自测完毕还是解bug完毕?要明确好这个概念的意思再向项目组报备所需工作时间。测试过程的时间一般是写代码时间的5%~15%,具体看人的能力。

    把所有技术的部分用对应的领域替换后,这种评估方法也适合产品、测试人员。

    总之要做好团队合作哦~~~
    团队合作

    展开全文
  • 王二是一个非常优秀的程序员,别人100行代码才能完成的事儿,他往往10行搞定,别人一星期才能搞定的任务,他往往半天做完。王二不想揽那么多事情,就总是在每周快结束的时候才工...

    王二是一个非常优秀的程序员,别人100行代码才能完成的事儿,他往往10行搞定,别人一星期才能搞定的任务,他往往半天做完。王二不想揽那么多事情,就总是在每周快结束的时候才工作,其他时间都想办法娱乐。

    领导很是看王二不惯,可又没什么办法。后来领导一统计,这王二的代码量是整个团队最少的。于是,有一天,领导就颁布了一条规定:要按代码行评估绩效,每周统计大家的代码行数,平均前三加绩效,年中和年底根据绩效发奖金

    王二一听,心里明白怎么回事儿。不过他也不生气,很快想到办法:把一行代码能完成的功能,写成 10 行。比如一个给定两点计算矩形面积的函数,原本他写成下面这样一行代码:

    640?wx_fmt=png

    新规定颁布后,他会写成这样:

    640?wx_fmt=png

    一行变40行!

    王二心想,娘希匹,看哪个龟孙的代码行数能超过老子!

    果然,年中一算绩效,我的天呐,王二拿的奖金最高!

    领导一看,不对呀,以往王二的代码量最少。于是,他就来查代码。这一查,勃然大怒,看出其中蹊跷,就取消了王二的奖金,还罚了王二几百块钱。

    领导出了口气,不想和王二计较了,可又不想随便废掉新政,觉得那样太下不来台,就左思右想,琢磨改进的事儿。

    终于,给他想到一个绝妙的办法,于是颁布了一个新规定:还是按代码行数评估绩效,规则更改为,在完成工作任务的同时,谁的代码行数最少,谁的绩效最高;谁的代码行数最多,谁的绩效最低。

    这下,很多程序员傻眼了,没办法,还得适应新龟腚呀,就开始改变,每天都猛琢磨,怎么把原本200行代码可以实现的功能用一行来完成。

    结果呢,整个团队,全变成了思考者,很多人一个月也不写一行代码,一年写不了10行。王二更绝,一年就写一行!

    最后,大家任务都没完成,谁也没拿到奖金。

    这下,领导又发飙了!

    于是,苦思冥想一昼夜,颁布了一个新规定:还是按代码行数评估绩效,规则更改为,在完成任务的前提下,代码行数量越靠近均位数,拿的奖金越多。

    这个法令一出,大家死活想不到办法,整日里愁眉苦脸。

    要说还是王二聪明,熬了一夜,抽掉13包长沙后,写出来一个代码行归一工具:只要你输入一个数字,这个工具就能把你的代码拆成那么多行。比如你输入300,它就可以把你的一行代码拆成300行,还不影响功能。

    王二乐于助人,编译了一个写死300行的工具发给大家使用。这样,每个人提交代码前,都用这个工具跑一下,工具自动完成折行、加空行等操作,把代码行数调整到300行。这样,大家每周代码行数量都变成了300行,半年下来,都有望拿到最高奖金。

    然而,领导狂飙啦!天底下就不该有这种事啊!

    于是,领导就又来查代码,结果发现,每个人的代码都跟加过扰似,根本读不懂!

    最后,领导两天两夜没睡觉,第三天早上,发布了新规定:废除按代码行数评估绩效。

    大家一听,都心安了。

    然后好景不长,第四天,领导颁布了一条新规定:从今天开始,大家的绩效,按每千行代码bug数来计算,bug越多,绩效越低,bug越少,绩效越高。

    王二一听,哇呀,这下难了,可他心高气傲,心想老子还能想不出办法来?于是每日里别事不干,就琢磨怎么降低每千行代码bug数……

    一晃半年过去,王二一行代码没写,结果却发生了意料不到的事情:他的每千行代码bug数为0,最低,绩效最高!

    王二大笑三声,跑去找领导要奖金,领导难以承受巨大的冲击,狂喷三分钟鲜血,被120接走了……


    这是我在知乎回答的一个问题,感兴趣的可以戳阅读原文,看这个回答后面各种有趣的留言。


    最近相关文章:

    展开全文
  • 软件工作量评估方法很多,如代码行法、类比法、WBS、故事点、用例点、NESMA、FPA、cosmic、COCOMOⅡ等。本文只是选取主流评估方法进行简述,每一种方法在实际操作过程中有若干条计数规则,在此并未阐述,并不能作为...

    前言

    本文的目标读者是从事软件行业想快速了解软件开发过程工作量评估的人员。软件工作量评估方法很多,如代码行法、类比法、WBS、故事点、用例点、NESMA、FPA、cosmic、COCOMOⅡ等。本文只是选取主流评估方法进行简述,每一种方法在实际操作过程中有若干条计数规则,在此并未阐述,并不能作为评估工作的实施指南。实际使用方法时,需以各方法发布机构发布的官方文档为准。

    一、 功能点 FPA 方法

    (一) 简介

    FPA 是从用户角度出发度量软件规模的一种方法。它从用户的角度出发,将系统分为数据功能和事物功能两大类,分别根据具体的规则来计算功能点,最后结合系统的特征因子来调整功能点数, 从而得到最终的系统规模。

    FPA 较适用于商业数据处理、管理信息系统的估算,因为它能更好地反映系统需求上的复杂度和数量。从满足客户需求的角度讲,FPA 具有阶段性,对用户早期参与项目管理、项目经理制定项目计划更有意义。

    (二) 重要概念

    功能点估算法是从用户视角出发,对软件的规模从逻辑设计的角度进行度量的标准方法。

    在功能点估算的过程中,以下概念应贯穿始终:

    1、 用户视角

    用户视角(User View)是指功能点被用户所认可,由用户需求书面正式描述,且独立于所采用的开发技术。

    2、 穿越系统边界

    穿越系统边界(Application Boundary)是指数据或控制信息由系统内发送到系统外,或由系统外发送到系统内。
    是否穿越系统边界是 FPA 重要的判断标准。

    3、 IPO 的异同

    输入(Input)、处理过程(Process)和输出(Output)的同与不同亦是FPA 重要的判断标准。

    (三) FPA 估算方法基本步骤

    在这里插入图片描述

    1、 收集可得的文档

    文档可以包括需求、数据/对象模型、类图、数据流图、用例、过程描述、报表显示、界面显示、用户手册,以及其它软件开发文档。

    2、 确定计数范围和边界并识别功能用户需求

    计数范围和边界需识别计数目的。不同的计数目的决定了计数范围和软件边界的划分。实际使用过程中通常为系统的管理边界, 特殊系统会以架构为边界。

    3、 度量数据功能

    数据功能的计算工序(Counting Procedures)包括以下活动:

    在这里插入图片描述

    FPA 将数据功能分为两类,分别为内部逻辑文件(ILF)和外部接口文件(EIF)。

    1) 识别内部逻辑文件 ILF

    内部逻辑文件(Internal Logical File,简称ILF)是在系统边界内部维护的一组用户可识别的逻辑上相关的数据或控制信息。ILF 的首要目的是保存由被度量系统的一个或多个基本流程维护的数据。

    2) 识别外部接口文件EIF

    外部接口文件(External Interface File,简称 EIF)是用户可识别的、逻辑相关的数据组或控制信息组,其由被度量应用所引用,但在另一应用边界内维护。EIF 的主要目的是保存由被度量应用的一个或多个基本过程引用的数据。这意味着一个应用的 EIF 必定是另一个应用的ILF。

    3) 识别数据功能 DET

    数据元素类型(Data Element Types,简称DETs)是指在一个ILF 或EIF 内,用户可认知的、唯一的、非重复的字段。如客户姓名、年龄、地址、联系方式等。

    4) 识别数据功能 RET

    记录元素类型(Record Element Types,简称 RETs)是指在一个ILF 或EIF 内,用户可认知的数据元素子集。如客户的家庭信息为客户信息的 RET 。

    5) 确定ILF 或EIF 的贡献度

    根据每一个已确认的 ILF 和EIF 的复杂度(DETs 和RETs 数量),对其进行分类,并赋予未调节功能点数值(Unadjusted Function Points,简称UFP)的过程,即为确定其贡献度。

    在这里插入图片描述

    6) 确定ILF 或EIF 的贡献度值

    对用户而言,ILF 与EIF 的业务意义是完全不同。因此,对于贡献度相同的 ILF 和EIF,其未调节功能点值是不同的。

    在这里插入图片描述

    4、 度量事物功能

    事物功能的计算工序(Counting Procedures)包括以下活动:

    在这里插入图片描述

    FPA 将事物功能分为三类,外部输入(EI)、外部输出(EO)和外部查询(EQ)。

    1) 识别外部输入(EI):是处理来自系统边界外部的数据或控制信息的一个基本过程。其首要目的(Primary Intent,简称 PI) 是维护一个或多个ILFs 或者去改变系统行为。

    2) 识别外部输出(EO):是发送数据或控制信息到系统边界外部的一个基本过程。其首要目的(PI)是通过处理逻辑呈现信息给用户,并非或者另外检索数据或控制信息。

    3) 识别外部查询(EQ):是发送数据或控制信息到系统边界外部的一个基本过程。其首要目的(PI)是通过从一个 ILF 或EIF 检索数据或控制信息,呈现信息给用户。

    4) 基本过程

    把功能用户需求组合或分解为最小活动单元,满足以下条件:

    1. 对用户有意义,构成一个完整的事务;

    2. 自包含;

    3. 使应用的业务保持持续状态,

    例 :功能用户需求要求提供维护员工信息的功能。该需求被分解为较小的工作单元,如添加员工信息、修改员工信息、删除员工信息和查询员工信息。

    5) 识别事物功能 DET

    数据元素类型(Data Element Types,简称DET)是指在一个EI、EO 或EQ 内,用户可认知的、唯一的、非重复的字段。

    6) 识别事物功能 FTR

    引用文件类型(File Types Referenced,简称FTR)是指一个交易功能读取或维护的一个ILF,或者一个交易功能所读取的一个
    EIF。

    7) 确定EI、EO 和EQ 的贡献度

    根据每一个已确认的 EI、EO 和EQ 的复杂度(FTRs 和DETs 数量),对其进行分类,并赋予未调节功能点数值(Unadjusted Function Points)的过程,即为确定其贡献度。

    在这里插入图片描述

    在这里插入图片描述

    8) 确定EI、EO 和EQ 的贡献度

    我们应注意到,贡献度相同的 EI、EQ,其未调节功能点值是相同的;与EI、EQ 贡献度相同的 EO,其未调节功能点值略高。

    在这里插入图片描述

    5、 计算功能规模

    1) 计算未调整功能点数

    UFP= ILFs+EIFs+EIs+EOs+EQs

    2) 确定系统调节因子

    在实际软件项目开发过程中因技术因素和环境因素会对软件项目工作量有不同程度的影响。可根据组织级基准库设定相关调整因子(System Adjustment Factor,简称SAF)。如应用类型、质量特征、开发语言、团队背景、评估时点等。

    计算调整后的功能点数  AFP=UFP*SAF

    3) 确定生产率PDR

    可根据系统特点测算组织级系统基准生产率。

    4)测算工作量

    工作量  AE=AFP*PDR

    6、 报告功能点计数结果

    将功能点计数过程和工作量计数结果编写报告呈现给读者。

    二、 COSMIC 方法

    (一) 简介

    COSMIC 是通用软件度量国际联盟的简写(Common Software Measurement International Consortium,COSMIC),它成立于1998 年,是一个由全球软件度量专家组成的非盈利自愿性组织,致力于软件规模度量方法的研究与推广。2002 年 1 月COSMIC 所推出的全功能点规模度量方法成为了 ISO 的标准,最新标准为 ISO/IEC 19761:2011“软件工程—COSMIC—功能规模度量方法”。

    COSMIC 方法包含了一组应用模型、原则、规则和过程度量给定软件的功能性用户需求的方法。其结果是一个数字化的“量化数值”,根据 COSMIC 方法得到的软件功能规模。它适用于以下领域的软件功能度量:

    业务应用软件,这类软件通常用于支持业务管理。如银行、保险、电信等。 
    
    实时软件。用于过程控制和自动数据获取软件。如嵌入式程序、中间件。
    
    平台软件,如可复用的构建及设备驱动程序等。
    

    功能规模是通过“数据移动(Data movement)”的个数来度量。

    (二) 原理

    功能规模是通过“数据移动(Data movement)”的个数来度量。

    (三) 度量过程

    COSMIC 方法的度量分为三个阶段:

    1、 度量策略阶段

    确定度量目的 
    
    确定度量范围 
    
    确定功能用户 
    
    确定需求描述详细程度
    

    2、 映射阶段

    识别功能处理 
    
    识别兴趣对象与数据组(兴趣对象指软件要处理的数据对象,如客户;数据组是一组兴趣对象属性的组 合,如客户姓名、年龄,联系方式等)
    
    识别数据属性
    
    识别数据移动(输入、输出、读、写)
    

    3、 度量阶段

    新增需求计数
    
    变更需求计数
    
    本地化规则计数(定制规则)
    
    生成度量报告 
    

    (四) 数据移动种类

    4 种类型的数据移动:输入(Entry)、输出(eXit)、读(Read) 和写(Write)。

    输入(E),是从用户穿越被度量系统的范围传输数据到系统内部,这里提到的用户既包括系统的使用人员,也包括其他软件或者硬件系统。
    
    输出(X),是一个数据组从一个功能处理通过范围移动到需要它的用户。
    
    读(R),是从永久性的存储设备读取数据。
    
    写(W),是存储数据到永久性的存储设备。
    

    (五) 示例

    用户借阅图书,图书管理员需录入借阅人信息并保存到数据库中,同时提供查询登记列表功能。此时录入借阅人信息为一个输入
    CFP,提示信息为一个输出 CFP,保存录入信息为一个写CFP,查询登记列表功能查询条件输入为一个输入CFP 和从数据库读取登记信息为一个读CFP。然后汇总计算出总功能点数为 5 个 FP。

    原则:每一个功能必须有一个输入,一个输出或一个写,即至少2 个CFP

    (六) 工作量测算

    参考FPA 方法和用例点方法工作量测算方法,设定相关技术调整因子和环境调整因子以及生产率,测算软件工作量。

    使用COSMIC 方法要求度量者对软件系统的实现非常清楚,了解系统的内部结构,并对系统能够明确划分出应用层级,以及层级之间的数据处理和数据移动。

    三、用例点方法

    用例点方法(use case point method,UCP),是由Gustav Karner在1993年针对FPA(function point access)方法而提出的一种改进方法,是在面向对象开发方法中基于用例估算软件项目规模及工作量的一种方法。UCP的基本思想是利用已经识别出的用例和执行者,根据他们的复杂度分类计算用例点。

    用例模型(Use-Case Model)是系统功能及系统环境的模型, 它可以作为客户和开发人员之间的契约。用例贯穿整个系统开发的一条主线。同一个用例模型即为需求工作流程的结果,可当做分析设计工作流以及测试工作流程的输入使用。

    UCP 估算是以用例模型为基础,通过计算用例点和项目生产率的取值,计算用例点和工作量的换算,得到项目开发所需的以人小时数为单位的工作量。UCP 算法受到 FPA 和MKⅡ方法的启发,在对Use Case 的分析的基础上进行加权调整得出的一种改进方法。

    UCP 估算方法的基本步骤如下:

    1) 对每个角色进行加权,计算未调整的角色的权值UAW;

    2) 计算未调整的用例权值UUCW;

    3) 计算未调整的用例点 UUCP;

    4) 计算计数和环境因子 TEF;

    5) 计算调整的用例点UCP;

    6) 根据规模和工时的转换因子来计算工作量。

    (一) 估算用角色值UAW

    首先将软件需求用Use Case 方式表达,其次利用参与者的数量乘以相应的权值来计算 UAW。

    在这里插入图片描述
    (二) 估算用例权值 UUCW

    利用Use Case 的数量乘以相应的权值来计算 UUCW。

    在这里插入图片描述

    (三) 估算未调整的用例点 UUCP

    估算未调整的用例点(UUCP),将角色权值和用例权值相加即为未调整的用例点数:

    UUCP=UAW+UUCW

    (四) 估算技术和环境因子 TEF

    UCP 估算方法中有 21 个适用性因子,其中包括开发系统的技术复杂度和开发环境,即分为 13 个技术复杂度和 8 个环境复杂度因子。

    1、技术复杂度因子 TCF:其中权重为该复杂度对系统的影响权值,value 为影响等级 0-5 之间的值来确定。0 表示技术因子与本项目无关;3 表示技术因子对本项目的影响一般;5 表示改技术因子对本项目有很强的影响。
    在这里插入图片描述

    在这里插入图片描述

    2、环境复杂度因子:其中权重为该复杂度对系统的影响权值,value 为影响等级 0-5 之间的值来确定。0 表示项目组成员都不具备该因素;3 表示环境因子对本项目的影响程度为中;5 表示本项目组成员都具有该因素。

    在这里插入图片描述

    在这里插入图片描述

    (五) 估算UCP

    以上UUCP、TCF、ECF 三个参数每个参数都是独立定义和计算。经过技术因子和环境因子对UUCP 调整后得到UCP 完整公式为:

    UCP=UUCPTCFECF

    (六) 估算工作量

    项目工作量估算也就是 UCP 的值乘以相对应的生产率PF。

    工作量  AE=UCP*PF

    展开全文
  • 具体方法请参考《团队开发如何评估工作量》。 本节参考 《需求评审的关注点》 https://blog.csdn.net/hursing/article/details/84633096 《团队开发如何评估工作量》 ...
  • 软件工作量评估方法

    千次阅读 2019-03-20 13:51:10
    软件开发价格与工作量、商务成本、国家税收和企业利润等项有关。为了便于计算,给出一个计算公式: 软件开发价格 = 开发工作量 × 开发费用/人·月 1.1开发工作量 软件开发工作量与估算工作量经验值、风险系数和...
  • 软件开发中如何评估工作量

    万次阅读 2019-04-22 21:45:25
    工作量如何评估(软件的规模、应用的领域、对质量的要求、采用什么技术、开发团队能力) 1、需求(需求调研、需求分析设计、原型设计、需求确认) 业务流程报告/调查报告(对客户方的组织业务概况和企业现状的一些...
  • 软件项目工作量评估方法很多,如代码行法、类比法、WBS、故事点、用例点、NESMA、FPA、cosmic、COCOMOⅡ等。本文主要对功能点方法(FPA)简述。 功能点 FPA 方法 (一) 简介 FPA 是从用户角度出发度量软件规模的一种...
  • 软件工作量评估方法(一)

    万次阅读 2018-10-31 19:16:14
     软件开发价格与工作量、商务成本、国家税收和企业利润等项有关。为了便于计算,给出一个计算公式: 软件开发价格 = 开发工作量 × 开发费用/人·月 1.1开发工作量  软件开发工作量与估算工作量经验值、风险...
  • 首先在认识FPA之前,应该先了解一下软件工作量评估的用途以及诸多方法 软件项目工作量是软件项目成本评估、软件项目工作量估算和合理策划项目进度的基础。可为后期报价、投标、项目管理、规划起到决定性作用。 软件...
  • 目录 研发成本计算方法 1.1开发工作量 1.1.1估算工作量经验值(以A来表示) 1.1.2风险系数(以σ来表示) 1.1.3复用系数(以τ来表示) 1.2开发费用 (/人·月) 1.2.1 P(人头费) ...工作量评估...
  • 工作量评估

    千次阅读 2015-02-25 17:26:28
    为什么必须首先做规模估计?...这个问题客户问过我,我也解答过多次,但是我一直没有更直接的理由说服我自己,认为必须先做规模估计再做工作量估计。  比如:对维护类的项目,或者是维护类的活动,为什么
  • 通过代码分析深度理解代码语义与结构,使得思码逸自创的工作量代码价值等指标具备高于传统指标的深度与精度。比如,相比代码行数,更不易受到空行、死代码等噪音干扰;相比开发流程中的事务统计,更不易受到任务...
  • 工作量评估得过多影响上线节奏,人员工作强度变低影响效率,工作量评估过少,造成的影响更大,如果可以通过加班消化还好,如果消化不了项目会延期,错过活动等等,对测试口碑的影响将是毁灭性的。尤其是一些紧急的...
  • 软件度量 COCOMO工作量估计模型

    千次阅读 2020-08-17 15:55:10
    最近在《软件协同设计》课程中学习了COCOMO工作量估计模型,在此进行总结。
  • 如何精细化估计前后端工作量

    千次阅读 2020-05-19 19:08:30
    对于一个前后端分离项目,如何估算工作量一直都是需要解决的问题。 粗略计算 前端:估计需要画的页面数,页面数*平均单个页面时间=工作时长 后端:估计出项目所需要的接口数量,接口数*平均单个接口时长=工作时长...
  • 简单的说,功能点方法是一种估算软件项目大小的方法,它是从用户视角出发...在2013年由工业和信息化部发布的行业标准《软件研发成本度量规范》中也推荐使用功能点方法进行软件规模度量,进而对软件项目工作量、工期...
  • 软件开发工作量的估算方法

    千次阅读 2019-09-14 17:11:31
    在讨论软件工作量估算方法前,首先要清楚什么事软件工作量估算。 我理解的工作量估算,就是估算软件项目所耗费的资源数,这个资源包含人力和时间,一般用人天、人月的形式来衡量。(而软件的成本=耗费的资源*资源的...
  • 说说软件项目工作量评估

    千次阅读 2012-09-27 09:29:26
    说说软件项目工作量评估 今天刚刚进行了一个小软件的工作量评估,总是觉得评估的不够准确,而且难以明确,把心中的困扰跟实际所使用的做法简单说说, 工作量评估中,困扰我的问题主要有以下几个 1、...
  • 项目管理中,几种工作量评估方法

    万次阅读 2013-10-16 08:54:06
    在测试项目管理中或编写测试计划时,经常需要对某个测试工作进行工作量的预算,很多时候都是凭个人的工作经验进行估算的,如能结合一些常规的估算方法,有助于估算的精确度。  以下是网上找到的一些常规的估算测试...
  • 使用功能点估算模型评估软件测试的工作量 功能点分析法应用在软件测试中,它最核心的价值究竟是什么呢? 让我们先看看软件开发,这是跟测试离得最近的工作类型。开发工程师工作大致可以分为“设计”和“编码”两步...
  • 不是狭义的代码量,用例数。   小规模的代码重构,如修改一个变量名,添加一行注释,在软件维护过程中,在添加新功能的时候随手就做了。没有单独做工作量估计的必要。但如果是做一个模块的重构,或一个子系统的重构...
  • 程序员注意记录你的工作量(人天)

    千次阅读 2019-10-22 14:47:39
    可以自己记录好,为了这整个项目内容,你自己写下了多少Kloc的代码,做出多少贡献,都可以一一记录,以便往日回首时,不会让你抱得失望太大,因为身为程序员的我们,都是一个脚步一块代码,死磕硬肝,通过996的工作模式,挺过去...
  • 如何估算测试工作量 (一)常规的估算测试工作量的方法 作为一个管理者,你是否被询问到某个项目要花多少时间,多少人力测试;或是作为一个普通的测试员,你是否被询问到要花多少时间来完成某个任务或是一次...
  • 测试工作量预估

    千次阅读 2018-12-23 02:22:33
    [需求理解(阅读需求、反馈问题、提炼功能点、归纳测试大纲)-测试范围评估(测试目标评估、测试人员、测试时间排定、测试方法)-测试用例编写-专项测试方案准备-测试环境准备-测试数据准备-测试用例执行(跑case、...
  • 软件项目规模评估

    千次阅读 2017-04-17 07:22:28
    顾名思义软件评估就是对软件项目的规模进度做出一个合适评估以判断软件项目的预算以及项目计划。 软件评估是软件工程的一个最底层基础,也是在软件项目实施时必经非常核心的一个步骤。对于一个软件项目,只有对其...
  • 软件开发工作量/费用估算

    千次阅读 2018-05-03 08:39:20
    [size=large] 软件开发价格与工作量... 软件开发工作量与估算工作量经验值、风险系数和复用系数等项有关: 软件开发工作量 = 估算工作量经验值 × 风险系数 × 复用系数 1.1.1估算工作量经验值(以A来表示) ...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 129,099
精华内容 51,639
关键字:

怎么通过代码量评估工作量