CMMI文档之软件估计规程

软件估计规程文档编号：FHI_CMMI_PP_PRD_SEST文档信息：软件估计规程文档名称：软件估计规程文档类别：CMMI规程密级：内部秘密版本信息：1.1建立日期：-1-13创建人：EPG批准人：李庆林同意日期：-2-25寄存位置：集成企业组织资产库/组织原则过程编辑软件：MicrosoftOffice中文版

文档修订记录版本编号或者更改记录编号变化状态简要阐明（变更内容和变更范围）修改日期变更人同意日期同意人V1.0C创立-1-13张娜娜-2-25李庆林V1.1M文档编号去掉版本号-4-17邓沛沛-4-17李庆林*变化状态：C――创立，A——增长，M——修改，D——删除目录TOC\o"1-3"1、简介 51.1目的 51.2合用范围 51.3术语表 51.4参照资料 52、 总体描述 62.1概述 62.2参与人员 62.3入口准则 72.4输入 72.5出口准则 72.6输出 72.7资源和能力规定 72.8度量 73、活动与规程 83.1估计软件规模 83.2估计各阶段缺陷数量 83.3估计难度等级 83.4估计工作量 93.5估计成本 103.6估计关键计算机资源 103.7估计软件工程设备和支持工具 103.8估计关键途径和关键依赖关系 103.9建立管理储备 103.10评审估计 113.11制定进度表 113.12建立项目挣值基线 123.13阶段详细估计 123.14形成《软件估计书》 123.15评审《软件估计书》 123、 附录 13a) 估计措施 13i. 历史数据估计措施 13ii. Delphi估计措施 13iii. PertSizingTechnique估计措施 14iv. 代码重用估计措施 15v. 改善项目估计 15vi. 工作量估计的措施 15b) 估计系数 16i. 开发工具系数 17ii. 规模系数 17iii. 生产力系数 17iv. 成本系数 18v. SCM系数 18vi. SQA系数 18vii. 改善项目规模系数 191、简介目的本文档的目的是为了描述对软件产品的规模、工作量、成本、关键计算机资源和进度等进行估计，描述了估计的环节和过程。合用范围本文档合用于企业的所有软件项目。术语表无。参照资料无。总体描述2.1概述每一种项目都要进行估计，并将估计的成果作为项目计划的基础。估计是项目计划的关键。目的是为项目建立合理的预算，确定合适水平的员工，并为项目承诺提供基础。一种没有建立在合理估计基础上的计划会提供一种错误的安全感，也许比主线没有计划更糟。估计的内容一般包括：规模、工作量/成本、外部成本、关键计算机资源、管理储备、进度表等。估计和计划贯穿了整个项目。在项目的初期阶段，使用自上而下（top_down）的方式进行粗略的估计和制定进度表。伴随项目的进展，在每个详细的计划阶段，使用自下而上（bottom_up）的措施为子阶段进行更详细的计划。下一阶段的底层WBS元素必须定义，并在WBS中进行记录。先对WBS的底层元素进行估计，然后汇总到较高层，用来更新总的软件估计。软件估计的流程如下：图表SEQ图表\*ARABIC1软件估计流程本文提供了几种估计措施及有关过程，它们重要应用于企业的软件项目规模、工作量及成本、关键计算机资源等的估计。假如这些估计措施不合用于特定的项目，项目经理必须为该项目提出此外的估计措施。2.2参与人员项目经理：组织召开估计会议，进行软件估计。软件工程组：在项目经理组织下，共同完毕项目的各项估计。有关人员：重要是指对本项目状况较熟悉的人员。CM人员：在项目经理组织下，完毕CM工作的估计。QA人员：在项目经理组织下，完毕QA工作的估计。2.3入口准则《WBS》已完毕（参见《软件估计书模板》）。《风险管理列表》已完毕2.4输入《软件需求规格阐明书》《WBS》（参见《软件估计书模板》）《风险管理列表》2.5出口准则估计活动完毕。估计成果通过评审。2.6输出《软件估计书》2.7资源和能力规定项目经理、项目组员具有类似产品开发的经验。2.8度量项目经理进行如下记录：软件估计所花费的工时；实际成果和软件估计成果的偏差（项目结束时记录计算）。3、活动与规程3.1估计软件规模规模估计的目的是为了判断待开发软件产品的规模，规模是成本估计、进度估计的基础，为了估计成本和进度，因此必须进行规模估计。WBS是软件规模估计的基础。我们常用的估计整个软件产品的规模的单位是：功能点（FP）。代码行（LOC）。其他：如交易数量、表数量等。有时需要估计个别软件工作产品的规模，一般采用如下单位：页：用于估计技术文档规模。字数：用于估计技术文档规模。测试用例的个数：用于估计测试规模。规模度量单位的选用参照《软件规模度量单位选用规程》，且必须记录在《软件开发计划》中。估计软件产品的规模重要依托过去有关的经验，估计人员应当具有相似系统的开发经验，运用自上而下（top-down）或者自下而上（bottom-up）方式进行软件规模的估计。详细环节如下：将软件工作产品拆提成能实现精确估计的较小部分。分析软件产品的WBS。选择合适的度量单位。选择估计措施，结合选择的技术处理方案（开发工具、语言、平台等），对WBS中的产品功能进行估计。估计成果也许是一种最高值和最低值的范围偏差使用合适的历史数据验证估计成果。在项目筹划过程中，评审和修正有关软件规模估计的问题，对软件产品的估计到达一致。将规模估计的成果记录到《软件估计书》中。3.2估计各阶段缺陷数量详细估计措施和环节参见《缺陷管理规程》。3.3估计难度等级估计人员估计任务的难度等级，可以根据如下几种方面：数据通讯（DataCommunications）分布式数据处理（DistributedDataProcessing）性能（Performance）使用强度高的配置（HeavilyUsedConfiguration）交易速度（TransactionRate）在线数据输入（OnlineDataEntry）最终顾客的效率（End-UserEfficiency）在线更新（OnlineUpdate）复杂的处理（ComplexProcessing）可重用性（Reusability）安装的简易性（InstallationEase）运行的简易性（OperationalEase）多场地（MultipleSites）容许变更（FacilitateChange）对于难度，我们现阶段采用较主观的方式去估计。3.4估计工作量完毕项目规模估计后，应当确定完毕这些工作需要的时间（以工时为单位），项目经理应当使用模型、历史数据和软件工作产品大小来确定项目工作量。工作量估计的内容应当包括如下内容：软件开发工作量，包括需求分析、设计、编码、测试、其他技术文档。项目支持活动的工作量，包括：配置管理的工作量，质量保证活动的工作量。项目管理活动的工作量。工作量的估计可以按如下环节进行：选择估计措施，目前提议使用Delphi措施。对WBS中的每个任务分别进行估计。估计项目支持活动的工作量，使用下面公式分别估计CM、QA的工作量：CM工作量=软件的工作量*5%QA工作量=软件的工作量*5%软件工程组应和CM人员、QA人员讨论对配置管理、质量保证活动建立总体的估计。对于在最初使用该估计的项目，其估计大概为开发工作量的5%，然后将此工作量分派到各自WBS的详细活动中。伴随历史数据的不停积累，可重新定义其占有开发工作量的比例，也可先对详细WBS活动进行估计，此时可采用Delphi措施及类比法。估计出培训的工作量，大概是软件工作量的3%。估计出项目管理活动的工作量，近似于软件工作量的15%~20%。将估计的成果记录到《软件估计书》中。3.5估计成本估计出工作量后，应根据企业的财务规定，进行成本的估算。估算的内容有：人力成本：人力成本（按日）*（工作量/8）。直接费用：直接可以报销的费用，如饭费、车费、活动费用等。3.6估计关键计算机资源项目经理应当明确完毕项目所需的关键计算机资源，并进行关键计算机资源估计。关键计算机资源可以是服务器环境、测试环境、目的环境等。估计关键计算机资源的环节如下：关键计算机资源是在软件开发和操作中受到约束的硬件资源，如：计算机内存、磁盘容量、网络容量、处理器性能。项目经理根据《软件需求规格阐明书》中对关键计算机资源的描述，确定关键计算机资源的约束。假如有关键计算机资源，则要估计软件开发或运行中的资源状况。与估计的软件规模、计划的处理负载、估计的数据量、或其他原因相联络，来估计所需的资源的总量，作初始估计。当时始估计做好后，应对每一项资源建立一定的储备。设计或者选用资源的程度作为跟踪的目的，确定跟踪的措施。与有资格的人员讨论估计，并使他们同意到达一致的估计内容。将估计的成果写入到《软件估计书》中。3.7估计软件工程设备和支持工具软件工程设备和支持工具的估计是以软件工作产品和特性的规模估计为基础的。包括设备资源、设施和支持工具，获得或升级软件开发工具，提高网络容量，明确需要的许可证数量，以及关键设备等。项目经理负责详细阐明所需的资源，并且协调影响项目进度和成本等的资源。3.8估计关键途径和关键依赖关系项目经理和软件工程组的有关人员、SQA负责人、SCM负责人、有关组负责人根据各活动间的关系确定关键途径和关键依赖关系。3.9建立管理储备建立管理储备是为了适应那些在项目中不可防止出现的变更。它代表了为用于同意的项目变更而保留的部分项目资金，动用管理储备必须通过高层经理同意。管理储备的估计由项目经理负责完毕。管理储备的总额（在整个项目预算中的比例）应基于估计的需求稳定性和评估的风险，一种有较高风险和不稳定需求的项目应比一种有较低风险和稳定需求的项目有较高的管理储备。对大多数项目来说，管理储备为项目预算的20%，管理储备应包括内部和外部的成本。下图阐明了被同意的项目预算和管理储备是怎样构成总的项目预算的。开发工作量 1000小时开发工作量 1000小时配置管理（5%） 50小时质量保证（5%） 50小时其他（培训） 24小时项目管理（20%） 220小时总的已同意的预算： 1344小时管理储备（20%） 270小时总的项目预算 1614小时项目的管理储备估计成果写入到《软件估计书》。3.10评审估计《软件估计书》作为项目计划的一部分，在项目计划完毕后或者每次估计变更后，项目经理应召集有类似项目经验的人对《软件估计书》的估计部分内容进行评审，内容包括：确认规模、工作量和成本、进度估计所采用的措施是恰当的确定估计的每个环节的输入是对的的确定软件估计成果是合理和对的的确定估计的内容是完整的3.11制定进度表进度表的制定可以按如下流程进行：项目经理和各负责人根据估计的工作量和关键途径确定每个活动的起止日期。根据第2步的成果，结合项目人员的详细状况，项目经理和各负责人调整任务的起始日期、终止日期，甚至是调整某些任务的负责人和关键途径。（如：通过第2步的成果，发现某些项目人员在某个时间段内工作超负荷，而有人员在某些时间段内工作量局限性，这样就需要调整。若实在调整不了，就有也许会调整关键途径）。项目经理在项目进度表中要安排里程碑点（里程碑点一般选在有特定意义的阶段点，如重要阶段的开始或结束），并形成进度表的草稿。将草稿提交给项目组的组员或负责人，得到他们的承诺或根据他们的意见进行修改，直至到达一致。CM人员和QA人员根据到达一致的进度表，确定自己的日程安排。注意：返工的问题：软件项目中的返工工作量是较大的，即在发现工作产品缺陷时的修改工作。一般来说，应在每个阶段为返工的工作留出统一使用的储备时间。有些项目较紧急，规定项目组员加班进行工作。对于这种状况，制定进度表一定要小心。由于若有特殊状况或某项关键任务估计得过于乐观，会导致项目进度迟延，而无法再用加班的方式进行弥补。管理活动的时间占用问题：项目经理根据软件估计中的管理估计和某些技术方面的LOE活动的估计，确定项目各组员在各个阶段可以真正用于完毕技术任务的时间。如：在编码阶段，某项目组员每周工作40小时，但评审、CM工作、项目会议以及某些技术方面的交流、培训就占去了18个小时，那么在安排该项目组员的技术任务时，只能按照他每周工作22（40－18）个小时去安排。3.12建立项目挣值基线挣值基线，也叫做计划工作的预算成本（PV）。是通过把每个任务的预算成本和计划完毕的指定期间段相联络建立起来的。（可参见《EV规程》）在项目的跟踪与监控过程中，通过获得挣值图对成本进行度量，详细参见《项目跟踪与监控过程》。在《软件估计书》的“挣值基线”页绘制挣值基线。3.13阶段详细估计在项目每个阶段开始前，要作阶段详细估计（工作量和时间表）。估计的环节同上述的过程相似。把详细估计合计起来，确定项目和阶段的总估计。完毕后更新总体的软件估计和项目计划。3.14形成《软件估计书》将上述估计的成果记录到《软件估计书》中。（可参见《软件估计书模版》）软件估计要在项目的不一样阶段进行，一般是在本阶段完毕时进行下一阶段的详细估计。《软件估计书》作为项目计划的一部分一起评审。3.15评审《软件估计书》软件工程组内部评审《软件估计书》。4、附录估计措施历史数据估计措施这种软件规模估计措施重要是运用已完毕的项目数据来估计软件的代码量，一般用代码行数表达。使用此措施需注意如下几点：充足理解系统需求判断历史项目对既有软件的合用性基于历史项目的相似性对软件规模进行对应的调整历史数据估计措施的环节如下：环节一：分解软件系统把软件系统模块化，通过系统模块化可以及早理解整个系统。系统分解程度要以历史项目为基础。环节二：确定相似模块使用历史项目要与目前项目有相似的应用和相似的语言。假如相似的模块不存在，也可以用其他措施估计该模块。环节三：确定相似模块规模使用历史项目可以通过原则的代码记录工具实现，在开发和估计目前项目规模时，规定使用同类型记录工具。环节四：调整模块大小软件模块估计的调整基于历史项目模块的相似程度或修改量。环节五：记录估计数据Delphi估计措施鼓励使用此专业估计措施，它可以对软件规模（代码行数）、人员工作量、开发时间、费用等进行估计，其环节如下：环节一项目经理选择三至六名有经验的工程师（可以是项目组外的工程师），他们应具有该项目的背景知识。环节二项目经剪发给每位工程师一份估计参照资料（一般有：《立项汇报》、《软件需求规格阐明书》、《WBS》（参见《软件估计书模板》）、《风险管理列表》等）和一张记录估计值的表格，并进行估计。环节三每位工程师仔细研究估计参照资料的内容，然后项目经理召集小组会议。在会上，工程师与项目经理一起对估计问题进行讨论，填写估计表并交给项目经理。环节四每位工程师对该软件提出三个规模的估计值，即：Ai——该软件也许的最小规模（至少源代码行数或至少功能点数）Mi——该软件最也许的规模（最也许的源代码行数或最也许的功能点数）Bi——该软件也许的最大规模（最多源代码行数和最多功能点数）不记名填写表格，并阐明做此估计的理由。环节五项目经理对每位工程师在表中填写的估计值进行综合和分类，完毕如下内容：计算每位工程师（序号为I,I=1,2,…,n）的估计期望值Ei和估计值的期望平均值E：

Ei=(Ai+4Mi+Bi)/6； E=1/4ΣEi对每位工程师的估计成果进行分类摘要。环节六项目经理召开会议，请工程师对其估计值的重大变动之处进行讨论。工程师对此估计值另做一次估计。环节七在综合工程师估计成果的基础上，组织工程师再次不记名填写表格。环节五到环节七可合适反复几次，最终可获得一种得到多数工程师共识的软件规模。最终，通过与历史资料进行比较，根据过去完毕项目的规模和成本等信息，推算出该软件每行源代码所需成本；然后再乘以该软件源代码行数的估计值，得到该软件的成本估计值。环节八将估计数据记录下来。PertSizingTechnique估计措施这种措施共估计三个值：软件产品预期规模的一般值、最大值和最小值。通过这三个值的计算可得到一种记录学上的期望值和一种原则偏差。公式：PERT公式估计的预期规模是E，原则偏差是SD：E=（a+4b+c)÷6SD=（c-a）÷6例如：一种新的通信程序：a=规模的最小值，例如：10KSLOCb=规模的一般值，例如12KSLOCc=规模的最大值， 例如15KSLOC即：E=（10+4*12+15）÷6＝12.167(KSLOC)SD=(15-10)÷6=0.833这就是说，此通信程序的规模也许会在11.334KSLOC（12.167-.833）和13KSLOC（12.167+.833）之间。本估计措施的前提是对规模的估计没有偏见，经验表明，估计偏低的倾向不小于偏高的倾向，使用时应加以考虑。代码重用估计措施本措施仅合用于对可重用模块的规模估计。本措施波及三个参数，分别是新设计的比例（%Redesign）、重新编码的比例（%Recode）和重新测试的比例（%Retest），使用这三个参数可以计算使用重用模块的代码规模计算公式为：[(%Redesign+%Recode+%Retest)/3]*ExistingCode=EquivSLOC例如：假如想重用一种有10000行代码的模块，其中40%需要重新设计，50%需要重新编码，60%需要重新测试，那么等价的新开发的代码量是：[(40%+50%+60%）/3]*10000=5000SLOC改善项目估计本措施合用于估计改善一种项目的规模，改善一种项目的规模和待改善的项目的规模有关，通过将待改善项目的规模乘以改善项目规模系数，可以估计出改善一种项目的规模，可以用如下的公式表达：规模=待改善项目的规模*改善项目规模系数工作量估计的措施运算法（ALGORITHMICCOSTMODELS）运算法是一种简朴直观的估计措施，它根据规模估计的成果和对应的系数运算得到工作量估计：工作量=p*s*l*ep=软件产品的规模（SLOC）s=生产力系数（1/每人月的代码行）l=开发工具系数e=规模系数组织应根据自身的实际状况，定义使用不一样开发语言时的调整系数，并且应当根据历史信息，常常调整开发工具系数，当没有这些信息的时候，可以由组织中有经验的人决定，下表是开发工具系数表的例子：开发工具系数原则C1.2原则C++1.1VB0.8PB0.7VC1.4C#1.0嵌入式C1.5嵌入式汇编软件规模的大小也是影响规模估计的参数之一，系统的规模越大，对工作量估计的影响就越小，这些数据的例子是：规模(KSLOC)系数501.091001.083001.055001.0410001.03….…..专家判断法（EXPERTJUDGEMENT） 本估计措施需要使用者有类似系统的经验，结合规模估计的成果和WBS综合分析，形成对工作量的估计，可以按照下面的环节进行：结合WBS，根据经验和规模来估计WBS中每项原子功能的工作量。根据每个功能点实现难度和风险的大小，合适调整工作量的估计按阶段合计需要的工作量，形成总的工作量的估计估计系数估计过程中需要使用诸多的系数，这些系数在各个项目中是不一样的，每个项目都可以根据实际状况确定自己的系数，可以参照其他项目或由项目内经验丰富的人来确定，伴随软件过程数据库的丰富，不停的进行修正。 当系数表中没有合适的系数时，可以使用最相近的系数或由项目内经验丰富的人来确定，增长到系数表中。所有系数的修改和增长，都应汇报给SEPG，经高级管理者同意后更新到系数表中才可以使用。开发工具系数在进行软件工作量的估计时，由于选用的开发工具不一样，开发的效率会有差