软件项目估算指南(CMMI5)
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 自顶向下的方法
需求分解开始
估算产品规模估算工作量估算进度估算成本
估算跟踪结束
规模历史信息
生产率历史信息
估算表报价表
工作量、进度分解度量表
根据需要重新估算实际数据
进度历史信息
自顶向下的估算方法估算核准项目管理计划
基于CMMI5的IT项目管理研究及应用
HM改进中后期环节，EPG将商业目标作为基础定期更新 QPPO，之后与更新后的PPB&PPM互相结合，进行信息预估、 信息评审、信息审批后发布信息。如果出现组织商业目标变 化、组织标准过程变化、过程实际性能与质量不相符等情况， 公司会立即重新修订QPPO。
审查与制定组织QPPO时，该公司主要完成了以下内容： 公司管理高层下达具体商业目标，QPPO评审过程参与；高级经 理收到目标指令后对其进行分解，同时会参与建立QPPO与维护 评审工作中；EPG组长同样负责分解商业目标，同时对QPPO进 行建立与维护。
该公司2021年制定了新的愿景与商业目标[2]，其中第一个 愿景为：为行业相关结构、国家提供更加优质的服务与产品， 占据更多市场份额；愿景二为：成为国家最优秀业务总额解决 方案与服务领域战略合作伙伴。商业目标一：产品交付缺陷 密度相比于去年降低10%；目标二：相比去年提升客户满意度 5%。之后公司建立了过程性能基线：
第一步：在Minitab中导入各项收集后的原始数据，利用直 方图更加直观地观察数据正态分布情况，若其中含有较为典型 的双峰或离岛型分布，会先进行分组。
第二步：使用Minitab绘制控制图，对其过程稳定性进行判 断。对于软件项目来说一般都会使用单点值与移动值域。
第三步：确保稳定过程控制图具有以下特点：全部的样本 点均在控制范围中；样本点呈现均匀部分的形态，中心线两侧位 置的样本点约占据整体样本点的二分之一；处于中心线部分的样 本点大约占据三分之二；处于控制接线部分的样本点极少。
软件项目管理第5章 软件项目成本估算
第5章 软件项目成本估算
假设机构内缺乏经验多、技术好、能力强的主程序员， 项目的组织形式恐怕要采用民主制小组的形式，当开发小组 有n个人时，总的通信路径需要n×(n－1)/2条，且联接每个 人的通信路径都是n－1条。
假设一个程序员正常情况下独立开发软件的生产率为L 代码行/人月，当n个人组成一个小组共同开发且耗费在每条 通信路径上的工作量相当于每人月编写LC行源代码时，组 内每个成员的软件生产率就会降低为：
第5章 软件项目成本估算
进度估算是指根据软件工作量估算结果以及用户提出的 进度要求，估算实施一系列软件工程任务的持续时间，即软 件项目历时估计。进度估算涉及人、财、物等项目资源的分 配，形成项目进度计划，用来跟踪和沟通项目进展状态，也 可跟踪变更对项目的影响。
成本估算是根据软件规模及其工作量估算结果，估算完 成该项目要付出的经济代价。软件项目的成本主要体现在人 力资源成本上，但也不能忽视资源配置、软件培训、人员变 动、进度压缩和进度延期等因素产生的其他成本。
软件项目成本估算表54eieo和eq的主要目的对比eieoeq改变应用程序的属性或行为主要目的次要目的不允许维护一个或多个ilf主要目的次要目的不允许显示信息给用户次要目的主要目的主要目的软件项目成本估算表55eieo和eq的主要行为对比eieoeq数学公式或计算被执行可以至少选择一次不可以至少一个ilf被修改至少选择一次至少选择一次不可以至少一个ilf或eif被引用可选可选必选数据被重新恢复可选可选必选派生数据被创建可选至少选择一次可选应用程序的行为或属性被修改至少选择一次至少选择一次可选准备或呈现信息到系统边界外可选必选必选接受进入系统边界内的数据的能力必选可选可选功能点估算法的计算方法项目的功能点数是几个测量参数用户输入数用户输出数用户查询数文件数和外部接口数的功能点之和
CMMI 软件工程
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模型，组织可以建立统一的软件过程，从而提高软件的质量和可靠性。
CMMI5文档之风险管理指南
风险管理指南文档编号：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估算的过程是什么？CMMI估算的过程可分为以下几个步骤：1. 确定估算目标和范围：明确估算的目标和范围，包括评估的过程区域，评估的组织单位等。
2. 收集信息：收集组织的有关过程文档、指南、指标等信息，为估算做准备。
3. 进行现场调查：与组织内的相关人员进行访谈和讨论，了解组织的过程实践和问题。
4. 评估分析：根据CMMI模型的要求和指导，分析和评估组织的过程能力和成熟度水平。
5. 编写估算报告：根据评估结果，编写估算报告，总结组织的过程能力和改进建议。
第四步：CMMI估算的收益是什么？进行CMMI估算可以带来以下几个收益：1. 了解组织的过程能力：通过估算，组织可以清楚地了解自身在软件工程和产品开发方面的能力水平，找到不足之处。
2. 发现问题和瓶颈：估算可以帮助组织发现存在的问题和瓶颈，从而有针对性地进行改进。
3. 提供改进方向和建议：估算结果可以为组织提供改进方向和建议，指导其制定有效的改进计划。
4. 提高过程透明度和控制性：通过估算，组织可以提升过程的透明度和控制性，实现更高效的软件工程和产品开发。
cmmi评定标准
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-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. 计算调整后的功能点数量。
CMMI基础知识5 评估方法
? 大概了解2到5级
38
本次题目的特点
? “体无完肤型” ? “大部分人欢喜少数人愁” ? 主观题、客观题都有
39
样题
? 判断题：2级有8个PA ? 简答题：CMMI2到5级，一共有多少个PA？
多少个Practice？ ? 论述题：请回顾本系列课程的全部内容
? 类似以上的题目全部不会出！
无
Practice2 … … …
…
…
30
例3：
Practice 项 级别 直接证
目
据
Practice1 P1 FI OK
间接证据或者 Weakness 访谈证据
OK
无
P2 PI OK
OK
有
P3 PI OK
OK
有
P4 FI OK
OK
无
Practice2 … … …
…
…
31
例4：
Practice 项 级别 直接证
? A君写了：按时完成了《需求规格说明 书》，并组织通过了评审。
? B君写了：学习了设计模式，有很多收 获。
? 请非部门经理先谈谈。 ? 请部门经理谈谈。
5
证明你做了事情的几种证据
? 直接书面证据
? 《需求规格说明书》 ? 评审记录
? 间接书面证据
? 开发计划
? 访谈证据
? 直接问当时人有没有做这个事情 ? 或者是问参加评审者有没有这回事
? 有明确的书面直接证据
? 有间接书面证据或者是访谈证据
? 有Weakness( 缺点、弱点 )
17
Practice 的4个评估等级 -2
? 部分满足(Partially Implemented)(PI)：
软件公司为什么要做CMMI5级认证？
软件公司为什么要做CMMI5级认证？
第一点，有利于提升公司和员工绩效管理水平，以持续改进效益。
通过度量和分析开发过程和产品，建立公司的效率指标。
第二点，能够解决人员流动所带来的问题。
公司通过过程改进，建立了财富库以共享经验，而不是单纯依靠某些人员。
第三点，助于提高软件开发者的职业素养。
每一个具体参与其中的员工，无论是项目经理，还是工程师，甚至一些高层管理人的做事方法逐渐变得标准化、规范化。
第四点，有利于成本控制。
因为质量有所保证，浪费在修改、解决客户的抱怨方面的成本会降低很多。
绝大多数情况是缺少规范制度，只是求快。
项目完成后，要花很多时间修补bug，费用很容易失控。
第五点，能保证软件开发的质量与进度，能对"杂乱无章、无序管理"的项目开发过程进行规范。
其实CMMI5的价值不光是证书本身，如果一个企业能够完全按照CMMI体系来指导项目的整个过程，那么他本身的作用已经超过意义。
对于一个软件公司，特别是国外用户，这个认证还是必须的，国内虽然也有相关的体系认证，但是对于国外用户来说，他们对于CMMI体系的认同度还是更高的。
最后总结一下，从事软件企业3级肯定是需要的，4、5级看自己的能力，因为CMMI是一个工程量很大的认证，如果公司规模够大影响力够强了，可以试着去做做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会议，提出工作中遇到的问题并积极提供有效可行的建议，并负责在会后将会议纪要发布给其他相关人员。