场景一:合同前的工作量估算
场景描述:
(1)没有实施过CMMI2级
(2)合同未签,需要给客户报价
(3)有客户的概要需求,有类似的项目数据可供参考
(4)需要估计整个项目的总工作量,以便于估算总成本,给客户报价
估算步骤:
(1)寻找类似的历史项目,进行项目的类比分析,根据历史项目的工作量凭经验估计本项目的总工作量;
(2)进行WBS分解,力所能及地将整个项目的任务进行分解;
(3)参考类似项目的数据,采用经验法估计WBS中每类活动的工作量;
(4)汇总得到项目的总工作量;
(5)与第(1)步的结果进行印证分析,根据分析结果,确定估计结果。
场景二:基于详细需求的经验估计
场景描述:
(1)只有详细需求,没有历史数据
估算步骤:
(1)WBS分解,将任务分解到一个人或者一个小团队可以执行的颗粒度;WBS分解时要识别出所有的交付物、项目管理活动、工程活动等。
(2)采用经验法估计每个活动的工作量;
(3)汇总得到:每个阶段的工作量、项目的总工作量。
其他说明:
在该场景下,只使用了经验法,无法对结果进行印证,难以判断结果的合理性。
场景三:由编码估算整体
场景描述:
(1)有类似项目的历史数据
(2)有编码活动的生产率数据
(3)有详细需求
(4)实施了CMMI2级,但是没有积累历史项目的工作量分布数据
估算步骤:
(1)产品分解,将系统分为子系统,子系统分解为模块;
(2)WBS分解,将任务分解到一个人或者一个小团队可以执行的颗粒度;WBS分解时要识别出所有的交付物、项目管理活动、工程活动等。
(3)建立WBS分解中的活动与产品元素的映射关系,识别出WBS中哪些活动可以采用模型法估算;
(4)估计产品元素的规模,可以采用代码行法或功能点法,并估计每个产品元素的复杂度、复用率等;
(5)根据历史的编码阶段的生产率数据和产品元素的规模估计、复杂度、复用率等采用模型法计算每个产品元素的编码工作量;
(6)根据历史的类似项目的数据及估算人的经验估计其他活动的工作量,可以采用经验法。
(7)汇总得到:每个阶段的工作量、项目的总工作量。
其他说明:
在该场景下,混合使用了经验法与模型法,这2种方法互相补充,而不是互相印证。
场景四:由总体印证基于WBS的估计
场景描述:
(1)有类似项目的历史数据
(2) 有类似项目的全生命周期的生产率数据(含管理工作量)
(3)有详细需求
(4)实施了CMMI2级,但是没有积累历史项目的工作量分布数据
估算步骤:
(1)产品分解,将系统分为子系统,子系统分解为模块;
(2)估计产品元素的规模,可以采用代码行法或功能点法;
(3)累计出整个产品的总规模,并估计产品总体的复杂度、复用率等;
(4)根据类似项目的全生命周期的生产率数据和产品的总规模、复杂度、复用率等采用模型法计算总的开发工作量;
(5)WBS分解,将任务分解到一个人或者一个小团队可以执行的颗粒度;WBS分解时要识别出所有的交付物、项目管理活动、工程活动等。
(6)根据历史的类似项目的数据及估算人的经验估计所有活动的工作量,可以采用经验法。
(7)汇总得到:每个阶段的工作量、项目的总工作量。
(8)与第(4)步得出的工作量进行比较印证,如果偏差不大,则以第(7)步的结果为准,如果偏差比较大,要仔细分析原因,可能的原因举例如下:
类似项目的生产率数据不适合本项目;
WBS分解的颗粒度不够详细;
估算专家的经验不适合本项目;
具体任务的估计不合理;
针对原因,对估算的结果进行调整,使其趋向合理。
其他说明:
在该场景下,对于项目的总工作量有2个结果或者多个结果,这些结果可以互相印证,以发现估算过程中的不合理之处,是估计更加合理。
场景五:三维印证基于WBS的估计
场景描述:
(1)有类似项目的历史数据
(2) 有类似项目的全生命周期的生产率数据(含管理工作量)
(3)有详细需求
(4)实施了CMMI3级,有历史项目的工作量分布数据(阶段分布、工种分布)
估算步骤:
(1)产品分解,将系统分为子系统,子系统分解为模块;
(2)估计产品元素的规模,可以采用代码行法或功能点法;
(3)累计出整个产品的总规模,并估计产品总体的复杂度、复用率等;
(4)根据类似项目的全生命周期的生产率数据和产品的总规模、复杂度、复用率等采用模型法计算总的开发工作量;
(5)根据历史项目的工作量分布数据及第(4)步估算的项目总工作量,计算:
? 每个阶段的工作量
? 每个工种的工作量
(6)WBS分解,将任务分解到一个人或者一个小团队可以执行的颗粒度;WBS分解时要识别出所有的交付物、项目管理活动、工程活动等。
(7)根据历史的类似项目的数据及估算人的经验估计所有活动的工作量,可以采用经验法。
(8)汇总得到:每个阶段的工作量、每个工种的工作量、项目的总工作量。
(9)与第(4)、(5)步得出的工作量进行比较印证,如果偏差不大,则以第(7)步的结果为准,如果偏差比较大,要仔细分析原因,可能的原因举例如下:
类似项目的生产率数据不适合本项目;
WBS分解的颗粒度不够详细;
估算专家的经验不适合本项目;
具体任务的估计不合理;
针对原因,对估算的结果进行调整,使其趋向合理。
其他说明:
在该场景下,对于项目的总工作量有2个结果或者多个结果,并且采用2种方法都得到了每个阶段、每个工种的工作量、项目的总工作量,可以从上述的3个维度对这些结果进行互相印证,以发现估算过程中的不合理之处,是估计更加合理。
场景六:四维印证基于WBS的估计
场景描述:
(1)有类似项目的历史数据
(2) 有类似项目的编码活动的生产率数据(不含管理工作量)
(3)有详细需求
(4)实施了CMMI3级,有历史项目的工作量分布数据(阶段分布、工种分布、阶段工种分布)
(5)项目采用了瀑布模型
估算步骤:
(1)产品分解,将系统分为子系统,子系统分解为模块;
(2)估计产品元素的规模,可以采用代码行法或功能点法,并估计每个产品元素的复杂度、复用率等;
(3)根据类似项目的编码活动的生产率数据和产品元素的规模、复杂度、复用率等采用模型法计算每个产品元素的编码工作量;
(4)根据历史项目的按工种的工作量分布数据及第(3)步的估算的编码工作量依次计算:
i)根据历史项目的编码的工作量占编码阶段的工作量的百分比与第(3)部计算出的编码工作量计算编码阶段的总工作量;
ii)根据历史项目的编码阶段各工种的工作量分布百分比计算编码阶段每个工种的工作量;
iii)根据历史项目的其他阶段的工作量与编码阶段的工作量比例计算其他阶段的总工作量;
iv)根据历史项目的其他阶段的每个工种的工作量分布百分比及第iii)步的结果计算其他阶段的每个工种的工作量;
(5)WBS分解,将任务分解到一个人或者一个小团队可以执行的颗粒度;WBS分解时要识别出所有的交付物、项目管理活动、工程活动等。
(6)根据历史的类似项目的数据及估算人的经验估计所有活动的工作量,可以采用经验法。
(7)汇总得到:每个阶段每个工种的工作量、每个阶段的工作量、每个工种的工作量、项目的总工作量。
(8)与第(4)步得出的工作量进行比较印证,如果偏差不大,则以第(6)步的结果为准,如果偏差比较大,要仔细分析原因,可能的原因举例如下:
类似项目的生产率数据不适合本项目;
WBS分解的颗粒度不够详细;
估算专家的经验不适合本项目;
具体任务的估计不合理;
针对原因,对估算的结果进行调整,使其趋向合理。
其他说明:
在该场景下,对于项目的总工作量有2个结果或者多个结果,并且采用2种方法都得到了每个阶段的工作量、每个工种的工作量、每个阶段每个工种的工作量、项目的总工作量,可以从上述的4个维度对这些结果进行互相印证,以发现估算过程中的不合理之处,是估计更加合理。
场景七:需求变更的工作量估计
场景描述:
(1)有变更的需求描述
(2)项目进行到了编码阶段
(3)有本项目的编码的生产率
估算步骤:
(1)进行需求变更的波及范围分析
(2)进行本次变更的的WBS分解
(3)对于变更引起的代码变化进行规模、复杂度等其他属性的估计
(4)根据本项目的编码的生产率及估计的规模采用模型法估计工作量
(5)对于WBS分解中其他活动进行经验估计
(6)汇总所有的工作量得到本次变更的工作量估计
Source URL:
http://www.51testing.com/?action_viewnews_itemid_71871.html
分享到:
相关推荐
以下根据提供的七种场景详细阐述软件工作量估算的步骤: 场景一:合同前的工作量估算 在这种情况下,由于没有实施CMMI2级,且没有签合同,需要基于客户的概要需求和类似项目数据来估算总工作量。首先,通过类比分析...
这种方法特别适用于软件开发项目的计划与预算制定阶段,通过量化软件的功能需求来预测项目的复杂度和工作量。 #### 二、COSMIC功能点测量方法概述 COSMIC功能点测量方法版本3.0是基于ISO/IEC 19761:2003标准的一个...
它可以在多个场景下发挥作用,包括编制软件项目预算、审批软件工程项目、在招评标过程中处理投标价格差异巨大的情况,以及在软件项目实施中进行项目开发过程的规模、工作量和工期等计划数据的估算。 该标准的主要...
通过 WBS,可以清晰地识别项目中的各个组成部分,从而进行更精确的工作量估算。 **7. 入口准则 (Entry Criteria) 和出口准则 (Exit Criteria)** - **入口准则**:定义了项目启动之前必须满足的条件,如需求规格...
**功能点估算方法**是一种软件规模度量技术,用于量化软件系统的规模,并为项目的计划和管理提供支持。该方法主要关注于软件的功能,而不是代码行数等传统的度量指标。功能点估算方法能够帮助项目团队在项目的早期...
使用用例点数(UCP)是一种广泛使用的项目估算方法,它使用项目的用例来准确地估算项目规模和工作量。用例点数用例建模是一种得到广泛使用的技术,用来获取软件应用的业务过程和需求。 用例点数根据一个应用程序的...
场景一:合同前的工作量估算场景描述:(1)没有实施过CMMI2级(2)合同未签,需要给客户报价 场景一:合同前的工作量估算 场景描述: (1)没有实施过CMMI2级 (2)合同未签,需要给客户报价 (3)有客户的概要需求...
在这个场景中,它可能包含了关于如何安装和使用FPAPal工具的详细步骤,可能还涉及了软件的许可证协议、系统要求和其他重要提示。 **四、FPA工具的使用** FPA工具帮助项目经理和开发团队通过以下方式提升效率: 1....
3. **估算指标**:列举了各种估算指标,如工作量、工时、成本、质量、进度等,并解释了如何计算这些指标,以及它们对项目决策的重要性。 4. **估算工具**:可能提到了一些常用的估算工具和技术,如甘特图、网络图、...
在软件测试领域,准确估算测试工作量对于确保项目按时完成、控制成本至关重要。然而,单个专家进行测试估算时,往往会出现高估或低估的情况。为解决这一问题,本文介绍了一种基于专家团队的测试估算方法——WideBand...
在实际场景中,工作量估算可能涉及以下几种情况: - **场景一**:在没有CMMI2级认证且无合同的情况下,基于概要需求和历史项目进行类比分析进行估算。 - **场景二**:有详细需求但无历史数据时,仅依赖经验进行工作...
这种方法基于国际功能点用户组织(IFPUG)的标准,能够帮助项目团队更好地理解和规划软件开发工作量,从而有效控制项目成本和进度。 #### 三、基本概念 1. **基本处理过程(Elementary Process)**:这是IFPUG定义中的...
2. **估算步骤**:可能包括收集历史项目数据、选择可比性高的参考项目、分析这些项目的关键参数(如工作量、资源使用、时间周期等)、调整因项目差异产生的偏差,最后得出新项目的预计工期。 3. **参考因素**:在...
功能点计数是一种常用的软件规模估算方法,主要用于衡量软件项目的复杂度和工作量。这种方法由IBM的研究员Allan Albrecht在1970年代提出,并通过一系列开创性的研究发现了源代码量与功能点之间的相关性。随着技术的...
2. **工作量估计**:估算软件项目的工时是关键。这可以通过功能点分析、历史数据比较、专家判断或使用特定的估算工具来完成。 3. **定价策略**:不同的企业有不同的定价策略,如成本加成法(基于成本加上期望利润率...
“软件工作量估计”章节则关注如何对软件开发的工作量进行估算,包括使用专家判断、类比估计、功能点分析、对象点和COCOMO参数模型等多种技术,以确保项目的进度和预算规划准确无误。 课程的其他部分如“活动策划”...
- 可以有效解决电池组的在线均衡问题,减少极端工作条件下对电池寿命的负面影响; - 为智能电池管理系统的设计提供了可靠的依据,有助于优化电池管理策略。 #### 结论 综上所述,ΔQ/ΔV法作为一种新型的SOC估算...
如果项目负责人对项目的规模没有一个比较客观的认识,没有对工作量、所需资源、完工时间等因素进行估算,那么项目计划也就没有存在的意义。 功能点估算法的特点 功能点估算法常用在项目开始或项目需求基本明确时...