软件项目估算指南(CMMI5)
- 格式:doc
- 大小:326.50 KB
- 文档页数:11
CMMI 软件工程CMMI 软件工程1. 简介CMMI(Capability Maturity Model Integration)是一种软件工程模型,旨在评估和改进组织的软件开发和维护过程。
它提供了一系列的最佳实践和指南,帮助组织提高软件开发的可预测性和质量。
CMMI软件工程模型由CMMI研究所开发并维护,它整合了CMM 和其他多个软件工程模型的优点,创建了一个通用的、可定制的评估框架。
2. CMMI框架CMMI框架分为五个不同的成熟度级别和数十个过程领域。
每个成熟度级别定义了一组特定的目标和实践,以帮助组织逐步实现良好的软件工程实践。
以下是CMMI的五个成熟度级别:2.1 初始级别(Level 1 - Initial)初始级别代表了一个没有定义和建立过程能力的状态。
在初始级别,组织的软件过程通常是不可预测的和不稳定的,由个人技能和直觉来驱动。
2.2 管理级别(Level 2 - Managed)管理级别代表了一个在某些项目中建立了稳定的软件开发过程的组织。
管理级别的关键特征是过程的可重复性和能力的量化。
2.3 定义级别(Level 3 - Defined)定义级别代表了一个为整个组织定义和标准化了软件开发过程的组织。
在定义级别,组织已经建立了一套标准的过程,并通过培训和监督来确保过程的遵循。
2.4 管理和测量级别(Level 4 - Quantitatively Managed)管理和测量级别代表了一个在对软件过程的量化管理上有更高水平的组织。
在此级别,组织借助统计分析和量化技术来管理和优化软件开发过程。
2.5 优化级别(Level 5 - Optimizing)优化级别代表了一个不断追求卓越并对软件过程进行主动改进的组织。
在优化级别,组织的重点是通过创新和持续改进来提高软件开发过程。
3. CMMI的优势3.1 改进软件质量通过CMMI模型,组织可以建立统一的软件过程,从而提高软件的质量和可靠性。
风险管理指南文档编号:F HI_CMMI_RSKM_GUI文档信息:风险管理指南文档名称:风险管理指南文档类别:C MMI 指南密级:内部秘密版本信息:1.1建立日期:2016-1-13创建人:E PG批准人:李庆林批准日期:2016-2-25存放位置:集成公司组织资产库/组织标准过程编辑软件:M icrosoft Office 2003 中文版变化状态:创建,——增加,修改,一—删除1目的本指南对项目风险的来源、分类、参数、优先级和控制阈值的定义进行描述。
目的是为了便于项目分管高层经理、项目经理、以及项目相关人员在进行风险识别、分类、计划、监控的交流时提供帮助和指导。
2术语和定义风险:是指某个事件出现非期望的负面后果的潜在可能性,是对有害结果的可能性和严重程度的度量。
持续风险管理:是指一种借助过程、方法和工具来管理项目中风险的工程实践。
它提供了一种能对如下问题作出预测式决策的规范化环境:持续地评估可能导致错误的因素(风险) ;决定哪些风险有处理的重要性;处理这些风险的实现策略。
SEI: ( Software Engineering Institution ) ,世界上著名的旨在改善软件工程管理实践的组织。
3风险模型风险管理是一个持续的、预见性的过程,它是项目管理的重要组成部分。
SEI 提出了持续风险管理模型CRM( Continuous Risk Management ) 。
SEI 的风险管理原则是:不断地评估可能造成恶劣后果的因素;决定最迫切需要处理的风险;实现控制风险的策略;评测并确保风险策略实施的有效性。
CRM莫型要求在项目生命期的所有阶段都关注风险识别和管理。
它将风险管理划分为5个步骤:风险识别、分析、计划、跟踪、控制。
下图所示的框架显示了应用CRM勺基础活动及其之间的交互关系,强调了这是一个在项目开发过程中反复持续进行的活动序列。
每个风险因素一般都需要按顺序经过这些活动。
上图中的箭头标识了信息的逻辑流,而沟通则是信息流的核心和手段。
cmmi 估算-回复CMMI是软件工程中用来评估和改进组织过程能力的一种国际标准模型。
它涵盖了软件、系统工程和产品开发等领域,帮助组织评估自身的过程,并提供改进建议。
本文将逐步回答关于CMMI估算的主题。
第一步:什么是CMMI估算?CMMI估算是指使用CMMI模型对组织过程进行评估和估算,以了解组织在软件工程和产品开发等方面的能力水平。
通过对组织过程的评估,估算可以帮助组织识别其存在的问题和缺陷,并提供改进方向和建议。
第二步:为什么进行CMMI估算?进行CMMI估算的目的是帮助组织识别存在的问题和瓶颈,并提供改进建议。
估算可以帮助组织了解其软件工程和产品开发过程的能力,找到差距并制定改进计划。
通过实施CMMI估算,组织可以提高过程的透明度和可控性,提升软件和产品质量,减少成本和风险。
第三步:CMMI估算的过程是什么?CMMI估算的过程可分为以下几个步骤:1. 确定估算目标和范围:明确估算的目标和范围,包括评估的过程区域,评估的组织单位等。
2. 收集信息:收集组织的有关过程文档、指南、指标等信息,为估算做准备。
3. 进行现场调查:与组织内的相关人员进行访谈和讨论,了解组织的过程实践和问题。
4. 评估分析:根据CMMI模型的要求和指导,分析和评估组织的过程能力和成熟度水平。
5. 编写估算报告:根据评估结果,编写估算报告,总结组织的过程能力和改进建议。
第四步:CMMI估算的收益是什么?进行CMMI估算可以带来以下几个收益:1. 了解组织的过程能力:通过估算,组织可以清楚地了解自身在软件工程和产品开发方面的能力水平,找到不足之处。
2. 发现问题和瓶颈:估算可以帮助组织发现存在的问题和瓶颈,从而有针对性地进行改进。
3. 提供改进方向和建议:估算结果可以为组织提供改进方向和建议,指导其制定有效的改进计划。
4. 提高过程透明度和控制性:通过估算,组织可以提升过程的透明度和控制性,实现更高效的软件工程和产品开发。
cmmi评定标准摘要:一、CMMI简介1.CMMI的定义2.CMMI的发展历程3.CMMI的重要性二、CMMI的等级划分1.等级一:未完成级2.等级二:已执行级3.等级三:已定义级4.等级四:已管理级5.等级五:优化级三、CMMI的评定流程1.准备工作2.评估过程3.评估结果四、CMMI在我国的应用1.我国CMMI的应用现状2.我国CMMI的应用优势3.我国CMMI的应用挑战与对策五、CMMI的未来发展趋势1.CMMI与敏捷开发的结合2.CMMI在人工智能和大数据领域的应用3.CMMI的全球发展趋势正文:CMMI(Capability Maturity Model Integration,能力成熟度模型集成)是一种针对软件开发和维护过程的成熟度模型,旨在帮助组织提高其软件开发和维护过程的质量和效率。
CMMI的提出和发展,为全球软件产业提供了一套统一的、可量化的评估标准。
CMMI将软件过程成熟度分为五个等级,分别为未完成级、已执行级、已定义级、已管理级和优化级。
这五个等级分别代表了组织在软件开发和维护过程中所处的不同阶段,以及在这些阶段中所需要具备的能力。
评定CMMI等级的过程通常包括准备工作、评估过程和评估结果三个阶段。
在准备工作阶段,组织需要确保其软件过程数据和文档的完整性和准确性;在评估过程中,评估师将对组织的软件过程进行现场评估,以确定其成熟度等级;在评估结果阶段,评估师将向组织提供评估报告,详细说明评估结果和建议。
在我国,CMMI的应用日益广泛,不仅在软件开发和维护领域取得了显著成果,还在一定程度上推动了我国软件产业的发展。
我国在CMMI应用方面的优势主要表现在政策支持、企业需求和人才培养等方面。
然而,我国在CMMI 应用过程中也面临着一定的挑战,如组织内部对CMMI的理解和重视程度不够、评估师资源短缺等。
为应对这些挑战,我国政府和产业界需要加大CMMI 的宣传和培训力度,提高组织内部对CMMI的认识和重视程度,同时加强评估师队伍建设,提高评估师的专业水平。
功能点估算(CMMI-FP)含例子功能点估算法是软件项目管理众多知识中比较有技术含量的一个。
在软件项目管理中项目计划制定的优劣直接关系到项目的成败,项目计划中对项目范围的估算又尤为重要。
如果项目负责人对项目的规模没有一个比较客观的认识,没有对工作量、所需资源、完工时间等因素进行估算,那么项目计划也就没有存在的意义。
功能点估算法的特点项目范围的估算在CMMI的“MA”度量分析管理和“PP”项目计划中均有涉及。
对软件项目范围的估算有很多种方法,常见的是LOC代码行和FP功能点法。
它们之间的区别和关系如下:•功能点估算法常用在项目开始或项目需求基本明确时使用,这时进行估算其结果的准确性比较高。
假如这个时候使用LOC代码行估算法,则误差会比较大。
•使用功能点估算法无需懂得软件使用何种开发技术。
LOC代码行估算法则与软件开发技术密切相关。
•功能点估算法是以用户为角度进行估算,LOC代码行估算法则是以技术为角度进行估算。
•通过一些行业标准或企业自身度量的分析,功能点估算法是可以转换为LOC代码行的。
在项目刚开始的时候进行功能点估算可以对项目的范围进行预测。
在项目开发的过程中由于需求的变更和细化可能会导致项目范围的蔓延,计算出来的结果会与当初估计的不同。
因此,在项目结束时还需要对项目的范围情况重新进行估算,这个时候估算的结果才能最准确反映项目的规模。
功能点分析的步骤本文将以国际标准IFPUG(International Function Point Users Group)组织提供的功能点估算法V4.1.1为基础进行讲解。
如下图所示,首先大家应该了解功能点估算法的使用步骤。
图1 功能点估算法的步骤具体步骤包括:1. 识别功能点的类型。
2. 识别待估算应用程序的边界和范围。
3. 计算数据类型功能点所提供的未调整的功能点数量。
4. 计算人机交互功能所提供的未调整的功能点数量。
5. 确定调整因子。
6. 计算调整后的功能点数量。
软件公司为什么要做CMMI5级认证?
第一点,有利于提升公司和员工绩效管理水平,以持续改进效益。
通过度量和分析开发过程和产品,建立公司的效率指标。
第二点,能够解决人员流动所带来的问题。
公司通过过程改进,建立了财富库以共享经验,而不是单纯依靠某些人员。
第三点,助于提高软件开发者的职业素养。
每一个具体参与其中的员工,无论是项目经理,还是工程师,甚至一些高层管理人的做事方法逐渐变得标准化、规范化。
第四点,有利于成本控制。
因为质量有所保证,浪费在修改、解决客户的抱怨方面的成本会降低很多。
绝大多数情况是缺少规范制度,只是求快。
项目完成后,要花很多时间修补bug,费用很容易失控。
第五点,能保证软件开发的质量与进度,能对"杂乱无章、无序管理"的项目开发过程进行规范。
其实CMMI5的价值不光是证书本身,如果一个企业能够完全按照CMMI体系来指导项目的整个过程,那么他本身的作用已经超过意义。
对于一个软件公司,特别是国外用户,这个认证还是必须的,国内虽然也有相关的体系认证,但是对于国外用户来说,他们对于CMMI体系的认同度还是更高的。
最后总结一下,从事软件企业3级肯定是需要的,4、5级看自己的能力,因为CMMI是一个工程量很大的认证,如果公司规模够大影响力够强了,可以试着去做做5级。
1组织过程-组织过程聚焦(OPF)和定义(OPD)1.1模板-EPG章程-角色及职能(EPG)1.1.1工程过程组(EPG)组长1.1.1.1EPG组长要求EPG组长是EPG的最高领导,是公司过程改进的直接负责人,由MSG直接授权任命。
EPG组长要求:(1)具有较高的威望,并在组织中受尊重(2)具有项目管理经验(3)具有软件开发的经验和知识(4)具有推广软件过程、方法和工具的经验(5)具有团队管理和人员沟通的知识以及出色的沟通能力1.1.1.2EPG组长职责EPG组长职责包括:(1)获取MSG的支持(2)主持推动公司软件过程改进以及认证工作;(3)制定组织级过程改进计划(SPI计划),并监督实施;(4)负责组织建立和维护组织过程资产库;(5)协调与推动过程改进相关活动,对可能的风险和出现的问题给予及时的汇报和解决;(6)协调EPG和MSG以及项目组之间的工作(7)领导EPG执行内部过程审核,并根据情况在公司内部组织软件过程改进培训(8)跟踪、监控和报告改进活动的状态,并每月定期向MSG汇报进展情况(9)组织EPG日常工作。
1.1.2工程过程小组(EPG)1.1.2.1EPG成员任命要求EPG成员要求包括:(1)对过程改进有浓厚的兴趣,愿意承担相应的任务(2)EPG中至少要包括具有丰富的开发经验、项目管理经验的成员(3)具有应用领域(如设计、测试、质量、配置等)的专业知识(4)在组织中受大家的尊重,具有较强的亲和力和沟通能力(5)具有丰富的团队协作经验(6)具有组织性、耐心、适应能力强(7)EPG成员专职和兼职均可1.1.2.2EPG的任务和职责EPG的任务和职责包括:(1)制定过程改进的战略计划和战术计划(2)策划、跟踪、推动和协调组织的软件过程改进活动(3)组织公司标准过程的制定、制定组织级标准软件流程;(4)定期评估、诊断新的软件过程体系在整个公司的使用情况(5)协调促进各工作组(6)收集业界最佳实践的资料和著作(7)负责建立和维护组织过程资产库,积累组织的过程财富,如规程、模板、检查清单、工作样品,并在组织范围内共享(8)选择、评审工作组创建的新过程、规程、方法、工具和模板(9)组织过程改进工作的内部评审并形成内审报告(10)针对内审中所发现的问题有权责成相关人员提出改进措施并跟踪验证(11)监督新软件过程体系的实施,并收集反馈意见(12)每季度定期,必要时则由事件驱动地向MSG呈报过程改进进展报告(13)对软件项目和项目组提供过程咨询和支持(14)向公司内所有员工提供过程改进方面的相关培训1.1.2.3EPG成员的任务与职责EPG成员的任务与职责包括:(1)按时参加EPG会议,提出工作中遇到的问题并积极提供有效可行的建议,并负责在会后将会议纪要发布给其他相关人员。
功能点估算法是软件项目管理众多知识中比较有技术含量的一个。
在软件项目管理中项目计划制定的优劣直接关系到项目的成败,项目计划中对项目范围的估算又尤为重要。
如果项目负责人对项目的规模没有一个比较客观的认识,没有对工作量、所需资源、完工时间等因素进行估算,那么项目计划也就没有存在的意义。
功能点估算法的特点项目范围的估算在CMMI的“MA”度量分析管理和“PP”项目计划中均有涉及。
对软件项目范围的估算有很多种方法,常见的是LOC代码行和FP功能点法。
它们之间的区别和关系如下:•功能点估算法常用在项目开始或项目需求基本明确时使用,这时进行估算其结果的准确性比较高。
假如这个时候使用LOC代码行估算法,则误差会比较大。
•使用功能点估算法无需懂得软件使用何种开发技术。
LOC代码行估算法则与软件开发技术密切相关。
•功能点估算法是以用户为角度进行估算,LOC代码行估算法则是以技术为角度进行估算。
•通过一些行业标准或企业自身度量的分析,功能点估算法是可以转换为LOC代码行的。
在项目刚开始的时候进行功能点估算可以对项目的范围进行预测。
在项目开发的过程中由于需求的变更和细化可能会导致项目范围的蔓延,计算出来的结果会与当初估计的不同。
因此,在项目结束时还需要对项目的范围情况重新进行估算,这个时候估算的结果才能最准确反映项目的规模。
功能点分析的步骤本文将以国际标准IFPUG(International Function Point Users Group)组织提供的功能点估算法V4.1.1为基础进行讲解。
如下图所示,首先大家应该了解功能点估算法的使用步骤。
图1 功能点估算法的步骤具体步骤包括:1. 识别功能点的类型。
2. 识别待估算应用程序的边界和范围。
3. 计算数据类型功能点所提供的未调整的功能点数量。
4. 计算人机交互功能所提供的未调整的功能点数量。
5. 确定调整因子。
6. 计算调整后的功能点数量。
识别项目的类型国际IFPUG组织将软件项目分为三类,功能点估算法适用于任何一类项目:•新开发项目•二次开发的项目•功能增强的项目识别项目的范围和边界使用UML的“UseCase”用例图是以用户角度进行识别项目范围和边界的最好方法,在画用例图时就必须明确系统的边界。
cmmi 估算管理
CMMI(Capability Maturity Model Integration)是软件能力成熟度模型集成,是一种评估和管理软件过程的方法。
在CMMI中,估算管理是其中一个重要组成部分,它涉及到对软件开发项目的工作量、成本和进度的估算。
估算管理在CMMI中的重要性在于,它可以帮助组织了解项目所需资源、制定计划、安排进度以及合理分配资源。
在CMMI的估算过程中,可以使用一些技术和方法,如FP功能点估算法,通过分析项目需求、工作量、所需资源等因素,为项目提供客观的估算。
FP功能点估算法是一种基于功能点的方法,它通过分析项目的功能需求来确定项目的规模和工作量。
该方法将项目划分为不同的功能模块,并对每个模块进行估算,最终得出项目的总工作量和成本。
在估算过程中,需要考虑项目的复杂性、技术难度、人员技能等因素。
除了FP功能点估算法外,CMMI还提供了其他估算方法,如LOC(Lines of Code)估算法、专家判断法等。
这些方法可以根据项目的特点和需求选择使用。
总之,估算管理是CMMI中不可或缺的一部分,它可以帮助组织有效地管理和控制软件项目的开发过程,确保项目的成功实施。
度量与分析过程文档编号:FHI_CMMI_MA_PRS文档信息:度量与分析过程文档名称:度量与分析过程文档类别:CMMI过程密级:内部秘密版本信息:1.1建立日期:2016-1-19创建人:EPG批准人:李庆林批准日期:2016-2-25存放位置:集成公司组织资产库/组织标准过程编辑软件:Microsoft Office 2003 中文版文档修订记录目录1.简介 (4)1.1.目的 (4)1.2.适用范围 (4)1.3.引用文件 (4)1.4.术语表 (4)1.5.角色与职责 (4)1.6.参考资料 (4)2.工作过程概述 (4)2.1.过程概述 (4)2.2.过程结构描述 (5)3.工作过程描述 (5)3.1.定义度量与分析规格说明 (5)3.2.实施项目度量与分析活动,并提供相应的结果 (7)3.3.实施公司度量与分析活动,并提供相应的结果 (7)4.支持文件 (10)1.简介1.1.目的开发和维持软件过程的度量能力,以便支持商业目标和管理信息的需要。
1.2.适用范围项目和公司度量与分析工作。
1.3.引用文件●《项目策划过程》1.4.术语表测量(Measure):是对一个项目或过程的某个特性(例如:规模、工作量、复杂性和缺陷)采度量(Measurement):是对一个项目或过程具有的某个特性的度的一个测量。
例如:对产品规分析(Analysis):是整理、比较和解析度量结果并形成报告的行为。
例如:对产品规模与工作1.5.角色与职责●Goal-Driven Software Measurement–A Guidebook [SEI-HB02]2.工作过程概述2.1.过程概述度量与分析过程的功能是从各种工程和管理过程中收集和分析度量数据并为相关的干系人报告度量结果,提供用于监控和改进项目过程和产品质量的管理信息。
度量与分析过程包括下列活动:●定义度量与分析规格说明;●实施项目度量与分析活动,并提供相应的结果;●实施公司度量与分析活动,并提供相应的结果;2.2.过程结构描述3.工作过程描述3.1.定义度量与分析规格说明3.1.1.概述度量分析人员采用“目标-问题-度量(Goal-Question-Metric,GQM)”的软件度量方法,建立和维护项目和公司的度量数据收集、分析、存储和报告方法。
参与实施CMMI5的经验总结文/质安部一、心得感受一年前,我开始了我的CMMI5旅程。
顺境、逆境,坎坷的、平坦的,处处碰壁的死胡同、豁然开朗的桃花源,我们一路走来,风雨过后终见彩虹。
刚刚接触CMMI时,对基本术语的理解还很含混,感觉就像进入另一个工作领域。
什么是PA,什么是CAR,什么是PPB和PPM,什么是Minitab、水晶球和蒙特卡洛,CMM与CMMI 有什么区别,要通过CMMI5要哪些方面的工作,我们还有哪些方面需要改进,收集了一堆看似杂乱、不规则的数据,如何应用到项目中,并给项目带来实质性的效用,所有这些问题都要得以解决,在整个CMMI5实施过程中,我们从众多数据入手,分析并挖掘它们之间的关系,结合相关培训,在咨询顾问的指导下,我从略知一二到理解掌握了CMMI5的基础知识,并开始慢慢地理清思路。
其实学习CMMI5是个融会贯通的过程,而在工作中,CMMI5的思想又是触类旁通的,过程改进的思想在工作中、生活中各个方面皆可运用。
我们将有用的数据抽离,并建立了基线和模型,在反复的实验中得到验证,用数据说话,指导项目实施。
为了实现CMMI5,我们深入地参与到CMMI5试点项目中,实际运用基线和模型、数据和模板,在实践中不断完善表格模板和体系文件,规范项目实施工作和管理机制,并做好公司过程改进,组织相关培训,在公司自上而下落到实处。
用实例证明我们的实力,成功地说服了主任评估师,最终华丽地完成CMMI5认证目标!宝剑锋从磨砺出,梅花香自苦寒来。
历尽千辛,最终尝到甜头,这次的胜利可以说是我职业旅途中的一座里程碑。
前方还有很长的路要走,持续的过程改进还在继续,我也会保持CMMI5工作的劲头,坚定地走下去!二、基线建立基线建立的前提是公司的项目管理过程趋于稳定,项目过程数据趋于可控。
基线反映了公司的过程性能能力。
我们是用Minitab工具以控制图的方式做出基线的,需要注意的是:控制图中的异常点不能随意删除,需进行根原因分析;表现差异较大的项目不能放在一起,应分类做出基线;项目经理在制定项目目标时,应参考组织级基线,结合项目特性确定本项目的目标;MiniTab的I-MR图对数据的检验规则如下:1)1个点距离中心线大于3个标准差2)连续9个点在中心线同一侧3)连续6个点,全部递增或递减4)连续14个点,上下交错5)2个点中有1个点,距离中心线(同侧)大于2个标准差6)4个点中有3个点,距离中心线(同侧)大于2个标准差7)连续15个点,距离中心线(任一侧)1个标准差以内8)连续8个点,距离中心线(任一侧)大于1个标准差三、模型建立3.1模型建立的八步骤:(一)获取组织目标1)获取商业目标:结合往年的市场投入、同行竞争力分析得出当年的商业目标。
Eacr CMMI过程体系项目估算指南广东×××技术股份有限公司文档控制记录文档修订记录修订类别:C = 创立,A = 增加,M = 修改,D = 删除1.概述软件估算方法归根结底分为两类:●基于专家经验的估算方法●基于历史数据类比的估算方法其中基于历史数据类比的估算方法也结合专家经验。
本指南主要内容是介绍四种软件估算方法,包括:●业务功能数估算法。
属于基于历史数据类比的估算方法。
●功能点估算法。
属于基于历史数据类比的估算方法。
●PROBE估算法。
属于基于历史数据类比的估算方法。
●WB-Delphi估算法。
属于基于专家经验的估算方法。
项目可根据实际情况选择使用这些估算方法的一种或者多种。
【注意事项】CMMI 3级要求使用历史数据帮助进行项目估算,因此项目使用单纯依赖专家经验的估算方法会被认为不能满足3级的评估要求。
2.估算时机估算是项目计划的一部分,因此理论上讲,在整个项目启动、执行过程的任何时间都可以进行。
通常,执行估算的时机包括:●产品概念提出此时,对项目的需求还没有比较准确的理解,估算的目的是为了大致理解项目成本和开发周期,经常由专家根据经验直接估计一个大致的工作量和开发周期。
估算不准确,与实际的偏差通常达100%,甚至高达400%。
●客户需求已经理解完成此时,对客户需求已经有比较详细的理解,估算的目的是为项目建立工作量、开发周期基准。
本指南中定义的业务功能数估算法、功能点估算法都适合于客户需求理解完成后的项目估算。
估算比较准确,与实际的偏差通常可控制在50%以内。
●产品需求已经开发完成此时,待开发产品的架构已经基本建立,功能和性能需求都已经经过完整的分析,项目对需求的理解、各方面约束和限制的理解都已经非常细致。
估算的目的是为下一步的开发活动建立更加准确的计划。
本指南中定义的业务功能数估算法、功能点估算法都适合于这种情况下的项目估算。
估算很准确,与实际的偏差通常可控制在20-30%以内●概要设计已经开发完成此时,项目已经对产品各个部件的设计、实现方法具备了完整的理解,估算的目的是为详细设计和实现建立更加准确的时间计划。
Page 1 of 11 项目估算指南 Version 1.1 文档名称:CMMI5-项目估算指南-V1.1.doc 项目估算指南 Version 1.1
Page 2 of 11 修订历史记录
日期 版本号 修改说明 修改人 核准人 项目估算指南 Version 1.1
Page 3 of 11 目录 1 目的 ................................................................................................................................ 4 2 范围 ................................................................................................................................ 4 3 术语、缩写词.................................................................................................................... 4 4 估算过程 .......................................................................................................................... 4 4.1 简要说明 ......................................................................................................................... 4 4.2 流程图 ............................................................................................................................. 5 4.2.1 自顶向下的方法 ................................................................................................... 5 4.2.2 自底向上的方法 ................................................................................................... 6 4.3 估算规程 ......................................................................................................................... 6 4.4 裁剪指南 ......................................................................................................................... 7
5 估算方法 .......................................................................................................................... 7 5.1 UCP估算算法 ................................................................................................................... 7 5.1.1 估算UUCP ........................................................................................................... 8 5.1.2 估算TCF调整因子 ................................................................................................ 8 5.1.3 估算EF调整因子 .................................................................................................. 9 5.1.4 估算UCP ........................................................................................................... 10 5.1.5 估算工作量 ....................................................................................................... 10 5.1.6 估算进度 ........................................................................................................... 10 5.1.7 估算成本 ........................................................................................................... 10
6 附录 .............................................................................................................................. 11 6.1 生产率数据来源 ............................................................................................................. 11 6.2 进度估算数据来源 .......................................................................................................... 11 项目估算指南 Version 1.1
Page 4 of 11 项目估算指南
1 目的 本文用于估算软件项目的规模、进度、工作量、成本,以指导项目作出合理的估算。 2 范围 本文件包括软件项目估算的各个方面,包括规模、进度、工作量、成本,并包括其在项目的中的分布估算。本文件适用于公司所有项目。
3 术语、缩写词 UCP Use Case Point,用例点
4 估算过程 4.1 简要说明 准确的估算是最大可能加快开发速度的基础,没有准确的进度估算,再有效的进度计划也无从谈起。不切实际的估算、不正确的期望是带来项目问题的主要原因。
估算是一个不断改进的过程,只有当详细地理解了每个功能,你才有可能准确估算出软件开发的进度和成本。因此,能够提前做出的决策越多,估算的精确度就越高。
准确的估算可以更好的控制项目的规模、进度、成本。工作量和进度估算通常在提交建议书及制定项目计划时进行,在项目实施过程中,也可能要对工作量和进度重新估计。
对于软件规模的估算主要有三种方法:代码行,功能点,用例点。本公司现在主要使用用例点方法。
对于工作量的估计,主要有两种方法: 自顶向下的方法(Top-down approach),用一个简单的方程从估计的规模求出估计的总工作量,各阶段的工作量可以根据它们占总工作量的百分比而得到。在需求不太明确时,规模估计比较困难,这时估算的误差会比较大。
自底向上的方法(Bottom-up approach),首先获得项目各部分估计的规模,然后得到整个项目估计的规模。在这种方法主要依据WBS来估算,首先将项目进行分解,列出主要工作,然后估计每件工作的工作量,汇总就可以得到整个项目的工作量。
对以上两种方法比较如下: 方法类别 优点 缺点 适用情况 自顶向下的方法 可以较好的利用过程数据库及历史数据 需求不明确时,规模不容易估算 项目情况与组织标准能力可能有需求比较明确(一般在需求分析完成之后) 项目估算指南 Version 1.1 Page 5 of 11 不需要进行工作分解 较大差别 自底向上的方法 不需要估算规模 在WBS中可能会忽略某些重要的任务,工作分解比较困难 对某管理性工作不容易直接估算 不容易积累经验 需求不明确时(一般在撰写建议书或需求分析完成之前)
当工作量已经知道或确定以后,就可以根据历史数据,计算项目最适合的总进度,然后根据项目的人力分配情况及历史数据,计算出各主要进程碑的进度计划。
4.2 流程图 4.2.1 自顶向下的方法
需求分解开始
估算产品规模估算工作量估算进度估算成本
估算跟踪结束
规模历史信息
生产率历史信息
估算表报价表
工作量、进度分解度量表
根据需要重新估算实际数据
进度历史信息
自顶向下的估算方法估算核准项目管理计划