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，经高级管理者同意后更新到系数表中才能够使用。开发工具系数在进行软件工作量的预计时，由于选用的开发工具不同，开发的效率会