CMMI5文档之组织标准过程维护规程
组织标准软件过程维护规程
文档编号：FHI_CMMI_OPD_PRD_OSPMT
文档信息：组织标准软件过程维护规程
文档名称：组织标准软件过程维护规程
文档类别：CMMI规程
密级：内部秘密
版本信息：1.1
建立日期：2016-1-8
创建人：EPG
批准人：李庆林
批准日期：2016.2.25
存放位置：集成公司组织资产库/组织标准过程
编辑软件：Microsoft Office 2003 中文版
文档修订记录
目录
1简介 (4)
1.1目的 (4)
1.2适用范围 (4)
1.3术语表 (4)
1.4参考资料........................................................................... 错误！未定义书签。2过程总体描述.. (5)
2.1过程概述 (5)
2.2过程结构描述 (5)
3过程元素描述 (6)
3.1开发标准组织过程 (6)
3.2工作组成员及EPG成员制定组织标准软件过程的工时 (8)
3.3评审与批准组织标准软件过程 (8)
3.4维护组织标准软件过程 (9)
3.5发布组织标准软件过程 (12)
4附录 (14)
4.1附录A－过程元素表 (14)
4.2附录B－过程元素表 (16)
1简介
1.1目的
依据CMMI级的关键过程域“组织过程定义”的要求，开发和维护一组有用的软件过程资产，这些资产供本公司所有软件开发项目享用，以便统一稳定和改进各类项目的软件开发过程性能，并以收集和积累财富在应用中产生的信息与项目组创造性的应用经验，不断改进财富库的内容，使组织长期受益。
过程资产包括有：组织的标准软件过程，对批准使用的软件生命周期的描述，组织标准软件过程的裁剪指南、组织软件过程数据库和软件过程文档库。
另外一个目的是为了有计划、有组织的指导和规范建立过程资产，故本规程是组织标准软件过程和相关过程财富制定、评审批准、维护、发布和废除的文档化规程，过程财富的描述另见相关规程。1.2适用范围
本过程适用于公司软件部内的组织标准软件过程及相关过程资产的管理。
1.3术语表
1.过程类别：我们将现有的和以后需要增加的组织标准软件过程按属性不同分为开发过程、支
持过程、组织过程、管理过程四大类，并对这四类进行细化；
2.组织标准软件过程：组织标准软件过程是基本过程的可操作的定义，在组织中建立一个针对
所有软件项目的共用的软件过程。它是由多个过程元素组合而成，包含了所有项目的软件过
程均会包含的软件过程元素；
3.过程元素：过程元素是指一个软件过程描述的构成元素。每个过程元素包括一组妥善定义的、
有限制的、紧密相关的活动（如软件估计元素、软件设计元素等）。过程元素的描述可以是
待填充的样板、待完成的片段、待推敲的抽象、待修改的或已使用的无须修改的完整描述。
过程元素的内容包括标题、输入、入口标准、任务、职责、使用的模板和规程、度量、出口
标准、输出等；
4.过程流程图：将一个组织的标准的软件过程分解成若干个过程元素，把这些过程元素间的关
联关系用流程图进行描述；
5.过程元素框图：过程元素框图是对过程元素所有要素及所要执行活动用一种标准流程图的格
式来表达的形式；
6.输入：任务开始之前输入的产品；
7.入口准则：任务开始之前应该被满足的条件；
8.任务：做些什么，谁做，怎么做，什么时间做等内容；是描述一个过程元素时的核心内容；
9.出口准则：可以认为某过程元素已经执行完毕时应该被满足的条件；
10.输出：任务结果后输出的产品；
11.职责：执行任务中的人员的角色和职责；
12.规程和模板：执行任务时使用的规程和模板；
13.度量：任务的度量，度量数据的收集；
14.裁剪指南：对过程元素的裁剪要求及标准。
2过程总体描述
2.1过程概述
本过程覆盖组织标准软件过程的开发、评审和批准、维护和发布四部分。
开发介绍了编写组织标准软件过程的方法及步骤。主要采用的方法是将一个原有的或已初步识别的过程按照一些关联和限制的活动进行分解，分解成若干个相对独立的又有紧密联系的过程元素，每个过程元素按照统一的格式进行书写，使生成的文档清晰易读。过程中涉及到很多新的术语和方法。会在详细的内容介绍中描述。
评审和批准是对最初的组织标准软件过程和变更的过程的评审和批准规程。我们采用的评审方法是同行评审，标准过程需要由高层经理批准。
维护描述了标准的软件过程发生变更时，应遵循的变更过程。
发布描述了经批准的组织的标准的软件过程的发布人、发布时间、发布对象、发布内容。
2.2过程结构描述
结合EPG日常的工作，如果以维护组织的软件过程资产为工作核心得到的流程图如下：
图 1 组织标准软件过程管理流程
3过程元素描述
3.1开发标准组织过程
3.1.1过程元素概述
本过程元素是描述如何编写组织标准的软件过程。介绍了编写的方法及步骤。主要采用的方法是将一个原有的或已初步识别的过程按照一些关联和限制的活动进行分解，分解成若干个相对独立的又有紧密联系的过程元素，每个过程元素按照统一的格式进行书写，使生成的文档清晰易读。过程中涉及到很多新的术语和方法。会在详细的内容介绍中描述。
开发包括分解过程、简介、绘制过程流程图、定义过程元素、裁剪指南、附录等相关内容。
3.1.2参与人员
●EPG和工作组：负责协调和参与过程编制
●工作组：待过程文档初稿形成时进行内部同行评审
3.1.3入口准则
●高层经理批准组织的过程改进计划
●EPG批准工作组计划
●组织标准软件过程相关部分需要新建
3.1.4输入
●组织的过程改进计划
●工作组计划
3.1.5任务
1. 组织标准软件过程的编制由EPG及工作组完成。
2.编写时参照组织方针、本规程以及SPI计划进行。
3.使用恰当方法，获取需要定义的过程在本组织内的实施状况或者恰当的过程描述，必要时组
织讨论会获取素材。
4.方法包括：工程和管理人员的反馈、外部获取的过程描述、经过试用的新过程。
5.将原来在公司中采用的典型的或行之有效的软件开发过程（包括管理与支持过程）分解成过
程元素，且补充必要的CMMII1.2要求的过程元素，并考虑目前公司所能理解、能操作的实
际状况确定过程元素的粒度，已识别的过程分解成的过程元素见附录A 过程元素表。
6.使用《组织标准软件过程模板》进行编写，应定义所有相关的过程元素。
7.只对标准软件过程进行流程图绘制，对过程元素不强制要求必须绘制（但建议尽量绘制），
流程图使用附录B 标准流程图符号进行绘制。
8.对分解出来的过程元素进行阐述，应按照ETVX方法和标准过程模板中的内容进行填写和定
义，内容包括过程元素概述、角色和职责、输入和输出、入口和出口准则、任务、度量、详
细裁剪指南等，其中，详细裁剪指南是针对于该过程元素活动的裁剪；对于某项内容出现不
适用的情况下填写“无”。
9.一些过程元素定义时无法表述完整的内容可整理后纳入附表中。
10.根据已批准的生命周期模型，编制与其相协调的软件过程体系结构，充分考虑过程元素先后
顺序、接口、关联条件和采用的工具和方法。
11.对牵涉到其他过程的内容，如果需要变更其他过程，填写过程变更请求表(请参见《过程变更
请求表模板》)。
12.初稿文档完成后，向EPG汇报，并在工作组内部对其进行同行评审。
3.1.6出口准则
●组织标准软件过程经过工作组人员内部同行评审，且问题均已得到关闭
3.1.7输出
组织标准过程（或其中的部分过程）（初稿）
3.1.8资源和能力要求
●工作组成员接受过组织中关于制定过程方法和标准的培训
●工作组成员和EPG成员接受过关于ETVX方法的培训
3.1.9度量
●工作组成员及EPG成员制定组织标准软件过程的工时
3.2评审与批准组织标准软件过程
3.2.1过程元素概述
本过程元素描述了如何对组织标准软件过程变更进行控制的过程。明确了组织标准软件过程变更的提出、实施、评审与批准等活动的执行人及步骤。
3.2.2参与人员
●外部专家、项目组代表、内部专家：参与制定出的组织标准软件过程的同行评审
●高层经理：批准组织标准软件过程
●EPG：组织标准软件过程的同行评审；对批准后的组织标准软件过程进行配置管理
3.2.3入口准则
●高层经理批准组织的过程改进计划
●EPG批准工作组计划
●组织标准软件过程相关部分需要新建
3.2.4输入
●组织标准过程（或其中的部分过程）（初稿）
3.2.5任务
1.文档编写人员完成后经过自行评审提交EPG，EPG组织相关人员参照同行评审规程对该文档
进行同行评审。
2.评审的规程和步骤参照《评审规程》中关于同行评审的要求进行。同行评审中要包括项目组
的代表等将来会实际使用相关过程的实践人员。
3.SQA组对评审中发现的问题进行跟踪直至解决，修改完成的文档经EPG核准无误后提交高层
审阅。
4.高层审阅后如无问题，在文档上签字批准。
5.批准后的组织过程，交由EPG纳入组织的过程资产库中进行配置，并对其进行管理；组织的
过程资产库的管理详见《软件过程数据和文档库管理过程》。
3.2.6出口准则
●更新的组织标准软件过程得到高层经理的批准，并纳入组织的过程资产库
3.2.7输出
●更新的组织标准软件过程（或其中的部分过程）
3.2.8资源和能力要求
●外部专家、项目组代表、内部专家和EPG成员接受过关于同行评审方法的培训
3.2.9度量
●外部专家、项目组代表、内部专家及EPG成员评审组织标准软件过程的工时
●高层经理审批组织标准软件过程的工时
3.3维护组织标准软件过程
3.3.1过程元素概述
本过程元素描述了如何对组织标准软件过程变更进行控制的过程。明确了组织标准软件过程变更的提出、实施、评审与批准等活动的执行人及步骤。
3.3.2参与人员
●变更请求发起人：提出组织内部的过程改进建议
●EPG及工作组：批准和实施组织标准软件过程的变更
3.3.3入口准则
过程变更请求或过程改进建议信息已提交
3.3.4输入
●过程变更请求或过程改进建议信息
3.3.5任务
1.收集改进建议
EPG工作小组成员负责及时收集软件过程改进建议，信息的来源主要以下几个方面： SCMAPI评估客观指出公司软件过程存在的问题和建议；
组织软件过程的改进目标；
对有关顾客问题和顾客满意度的数据分析；
度量和分析过程和产品得到的数据；
从监控组织和项目的软件过程活动的中得出的经验教训；
使用者提出的改进建议；
SQA对项目进行的过程审计发现的不足。
2.评估
提出者将改进意见填写在《过程改进请求》表中，提交给EPG审批是否作为改进项，并反馈给提出者。
在EPG的领导下，对审批和收集到的的改进建议、组织标准软件过程和项目定义软件过程进行分析评估，必要时，高层领导参加到分析评估活动中。详见《组织过程焦点过程》。
3.SPI计划的维护
由EPG工组小组根据评估的结果，维护SPI计划；
EPG组织受影响的组和个人，对SPI计划进行同行评审，评审过程参见《评审规程》；
经EPG批准后，纳入组织标准软件过程数据和文档库中进行管理。详见《组织过程焦点过程》
4.改进过程的实施
●实施
参与过程改进的成员受到相关方面的培训；
依照SPI计划，EPG工作小组从组织标准软件过程数据和文档库取出相应的文档进行修改；
EPG监督、协调软件过程活动的实施。
●跟踪改进建议的状态
负责人根据“EPG评审问题跟踪表”跟踪每项改进建议的状态，直到改进项全部被关闭；
负责人识别响应时间比较长的软件过程改进建议，并分析原因；
若EPG工作小组内部不能解决的问题，上报给EPG组长，EPG组长协调、解决，由负责人跟踪直至问题被关闭。
●试运行
在合适时，将改进的软件过程纳入组织标准软件过程前，先试运行该改进过程，以确保其效益和有效性；
在试运行中，若发现了问题，使用者将问题记录在改进反馈表中，提交给EPG工作小组；
EPG工作小组内部不能解决的问题，上报给EPG组长，由EPG组长做出决定，并反馈给EPG工作小组；
负责人跟踪至所有问题被关闭。详见《组织过程焦点过程》。
●正式发布运行
正式发布前要经过EPG的审批，具体活动参见本文“评审与批准组织标准软件过程”。
●保存记录
保存软件改进过程中产生的记录，并存放在“组织标准软件过程数据和文档库”中作为过程资产，可定期的生成有关软件过程改进的报告。在过程维护的全程EPG应负责维护《组织标准过程变更记录》。
5.度量过程改进数据
改进过程完毕后，EPG工作小组要对改进过程进行统计，度量数据如下：
实施过程改进的效果与规定目标相比较；
对每个过程区域提交的和实施的软件过程改进建议数目；
每个改进周期建议总数目、已接受数目、未接受数目以及它们的百分比。
3.3.6出口准则
●过程的更新经过高层经理批准
3.3.7输出
●组织标准过程（或其中的部分过程）
●组织标准过程变更记录
3.3.8资源和能力要求
●组织中各级人员接受过如何提供过程改进请求方法和制度的培训
●EPG成员接受过关于如何监控新过程试运行和分析数据的培训
3.3.9度量
●实施过程改进的效果与规定目标相比较
●对每个过程区域提交的和实施的软件过程改进建议数目
●每个改进周期建议总数目、已接受数目、未接受数目以及它们的百分比
●EPG成员关于改进过程活动的工时
3.4发布组织标准软件过程
3.4.1过程元素概述
本过程元素描述如何进行组织标准软件过程的发布。包括按照过程改进计划发布组织标准过程、进行产品审计、发布时创建发布报告，和对过程产品进行版本描述。
3.4.2参与人员
●EPG：发布组织标准软件过程的新版本；废除原有版本
●相关组和个人：接受新版本通知，并使用新版本过程
●高层经理：批准新版本的发布
3.4.3入口准则
●组织过程改进计划预计的发布时间到
●组织标准过程中的文件已经纳入组织资产库
3.4.4输入
●组织过程改进计划
●组织标准过程中的文件
3.4.5任务
1.组织标准软件过程版本的发布
●在发布前对要发布的产品进行审计，确保：
需要发布的所有工作产品都已经在组织资产库中
所有的工作产品都已经经过评审和批准
所有的已经批准的变更请求都已经关闭
●得到高层经理的审批后，EPG从软件过程数据库和文档库中提取要发布的产品发布在公司的内
部网上；
●正式发布时创建发布报告，将发布的产品、时间、对象、以及发布的版本描述等内容按照《组
织标准过程发布报告模板》写到报告中。
●发布要按计划或事件驱动进行。
2.组织标准软件过程版本的废除
●得到EPG批准废除的组织标准软件过程版本，由EPG工作小组及时回收，做好废除标识，并
及时更新公司内部网上的相应内容；
●废除的规范版本纳入软件过程数据库和文档库的停用版本中进行保存，保存时间为三年；
●将废除规范版本的事宜发布在网上。
3.4.6出口准则
●组织标准过程（或其中的部分过程）已经在组织范围内发布/废除
3.4.7输出
●组织标准过程发布报告
3.4.8资源和能力要求
●相关人员接受过关于如何发布和废除组织标准软件过程的培训
3.4.9度量
●发布或废除组织标准软件过程的工时
4附录
4.1附录A－过程元素表
习题8：第8章项目质量管理
习题 请参考课文内容以及其他资料，完成下列选择题： 1）下列都属于项目质量管理，除了（ ）。 A. 执行组织确定质量政策 B. 使项目满足其预定的需求 C. 收集需求，产生需求文件 D. 监督、控制和确保达到项目质量要求 2）下列哪个知识领域不会给质量管理知识领域提供输入？（ ） A. 范围管理 B. 沟通管理 C. 人力资源管理 D. 风险管理 3）下列哪个知识领域不会给质量管理知识领域提供输入？（ ） A. 整合管理 B. 沟通管理 C. 成本管理 D. 采购管理 4）质量管理给哪个知识领域提供输入？（ ） A. 整合管理 B. 沟通管理 C. 采购管理 D. 成本管理 5）规划质量为哪个过程提供“质量测量指标”作为输入？（ ） A. 质量审计 B. 实施质量保证 C. 实施质量控制 D. 实施质量保证和实施质量控制 6）质量管理知识领域和哪个过程组无关？（ ） A. 启动 B. 规划 C. 执行 D. 监控 7）项目组正在使用鱼骨图来决定项目应该采用什么质量标准，请问它们处于什么质量管理过程？（ ） A. 质量规划 B. 实施质量保证 C. 实施质量控制 D. 质量审计 8）下列哪项是实施质量控制的最佳描述？（ ） A. 监测特定的项目成果以确定它们是否符合相关的质量标准 B. 审计项目的整体绩效 C. 采取合理的措施以提高项目的质量 D. 识别哪些质量标准与项目有关 习题 8 项目质量管理
9）你是一个建设公路的项目经理。你正在进行根源分析，确定导致该问题或情况的根本原因，并为类似的问题制定纠正措施。同时，你还邀请团队成员与你一起从组织和技术角度识别项目中所需要的改进。目前你处于以下哪一个过程？（） A. 质量规划 B. 实施质量保证 C. 实施质量控制 D. 质量审计 10）规划质量为哪个过程提供“质量核对表”作为输入？（） A. 质量审计 B. 实施质量保证 C. 实施质量控制 D. 实施质量保证和买施质量控制 11）实施质量控制为哪个过程提供“质量控制测量结果”作为输入？（） A. 规划质量 B. 实施质量保证 C. 质量审计 D. 规划质量和实施质量保证 12）谁负责权衡项目成果的质量与等级水平？（） A. 高级管理层 B. 质量监督员 C. 项目经理与项目管理团队 D. 质量经理 13）项目质量管理的方法适用于（）。 A. 项目管理 B. 项目产品 C. 项目管理与项目产品 D. 两者都不适用 14）下列关于项目质量管理描述错误的是（）。 A. 项目质量管理需要兼顾项目管理和项目产品 B. 项目质量管理的方法适用于所有项目 C. 产品质量测量技术适用于所有项目产品 D. 无论什么项目，未达到产品或项目质量要求，都会给某个或所有项目千系人带来严重的负面后果 15）下列对某软件的描述中，哪项不属于质量问题？（） A. 用户手册不规范，错别字很多 B. 用户手册标明的功能无法实现 C. 程序运行经常出错 D. 功能特征有限 16）下列关于质量与等级的描述中，错误的是（）。 A. 质量是指一系列内在特性满足要求的程度 B. 等级是指对用途相同但技术特性不同的产品或服务的级别分类 C. 质量水平未达到质量要求不一定是个问题 D. 低等级不一定是个问题 17）下列对精确的描述错误的是（）。 A. 测量值非常接近实际值 B. 重复测量的结果非常聚合 C. 测量结果离散度很小 D. 精确的测量未必准确 18）下面关于精确和准确的描述中，错误的是（）。 A. 精确的测量未必准确 B. 准确的测量未必精确
CMMI5文档之产品集成过程
产品集成过程 文档编号：FHI_CMMI_PI_PRS 文档信息：产品集成过程 文档名称：产品集成过程 文档类别：CMMI过程 密级：内部秘密 版本信息：1.1 建立日期：2016-1-5 创建人：EPG 批准人：李庆林 批准日期：2016.2.25 存放位置：集成公司组织资产库/组织标准过程编辑软件：Microsoft Office 2003 中文版
文档修订记录 *变化状态：C――创建，A——增加，M——修改，D——删除
目录 1简介 (5) 1.1目的 (5) 1.2适用范围 (5) 2过程总体描述 (5) 2.1过程概述 (5) 2.2过程结构描述 (5) 3过程元素描述 (5) 3.1策划产品集成 (5) 3.1.1概述 (5) 3.1.2参与人员 (6) 3.1.3入口准则 (6) 3.1.4输入 (6) 3.1.5任务 (6) 3.1.6出口准则 (7) 3.1.7输出 (7) 3.2产品集成接口处理 (7) 3.2.1概述 (7) 3.2.2参与人员 (7) 3.2.3入口准则 (7) 3.2.4输入 (7) 3.2.5任务 (7) 3.2.6输出 (8) 3.3搭建产品集成环境 (8) 3.3.1概述 (9) 3.3.2参与人员 (9) 3.3.3入口准则 (9) 3.3.4输入 (9)
3.3.5活动 (9) 3.3.6出口准则 (9) 3.3.7输出 (9) 3.4实施产品集成 (9) 3.4.1概述 (9) 3.4.2参与人员 (9) 3.4.3入口准则 (9) 3.4.4输入 (10) 3.4.5活动 (10) 3.4.6出口准则 (10) 3.4.7输出 (10) 3.5交付产品 (10) 3.5.1概述 ................................................................................................................... 错误！未定义书签。 3.5.2参与人员 ........................................................................................................... 错误！未定义书签。 3.5.3入口准则 ........................................................................................................... 错误！未定义书签。 3.5.4输入 ................................................................................................................... 错误！未定义书签。 3.5.5活动 ................................................................................................................... 错误！未定义书签。 3.5.6出口准则 ........................................................................................................... 错误！未定义书签。 3.5.7输出 ................................................................................................................... 错误！未定义书签。 4 附录：角色与任务映射表 (10)
CMMI5文档之集成测试用例模板.docx
×××××× 项目集成测试用例模板文档编号： FHI_CMMI_VER_TEM_TUC 文档信息：集成测试用例模板 文档名称：集成测试用例模板 文档类别： CMMI 模板 密级：内部秘密 版本信息： 1.1 建立日期： 2016-1-5 创建人： EPG 批准人：李庆林 批准日期： 2016.2.25 存放位置：集成公司组织资产库 /组织标准过程 编辑软件： Microsoft Office 2003 中文版
文档修订记录（引用时请修改为实际项目的信息） 版本编号或者* 变化简要说明（变更内容和变更范 日期变更人批准日期批准人更改记录编号状态围） V1.0C创建2016-1-5张娜娜2016-2-25李庆林V1.1M文档编号去掉版本号2016-4-17邓沛沛2016-4-17李庆林 * 变化状态： C――创建， A ——增加， M ——修改， D——删除
目录 1.产品 /项目信息 (4) 2.集成测试用例设计 (4) 1.1集成内容描述 (4) 1.2类协作关系描述 (4) 1.3对外接口描述 (4) 1.4测试用例 (5)
1.品 /目信息 产品 / 项目名称产品 / 项目编号 测试阶段用例个数 设计时间测试设计人 测试模块 2.集成用例 1.1集成内容描述 [ 此列出集成版本所包含的 ] 子系构件 子系统名称 1.2作关系描述 [ 此处列出该集成版本所包含的类之间的协作关系，并以表格的形式列出类间的调用] 消息号消息名消息送者消息接收者 [Msg0001] 1.3外接口描述 [ 此处列出该集成版本所提供的对外接口（功能），当没有外部接口设计时，此章节删除。] 接口号作消息号 接口名 Msg0001Msg0002?Msg000n [IF0001]Interface 1√?√
cmmi软件生产过程标准
何谓CMM? CMM是由美国卡内基-梅隆大学的软件工程研究所(SEI)推出的评估软件能力与成熟度的一套模型。它侧重于软件过程开发的管理及软件工程能力的改进与评估，是目前国际上最流行、比较实用的一种软件生产过程标准，成为当今企业从事规模软件生产不可缺少的一项内容。CMM模型共分为五个级别：初始级、可重复级、定义级、管理级和优化级。 软件工程：什么是CMMI? CMMI全称是Capability Maturity Model Integration, 即软件能力成熟度模型集成模型，是由美国国防部与卡内基-梅隆大学和美国国防工业协会共同开发和研制的。CMMI是一套融合多学科的、可扩充的产品集合，其研制的初步动机是为了利用两个或多个单一学科的模型实现一个组织的集成化过程改进 CMMI分为五个等级，二十五个过程区域（PA）（如图所示）。 1．初始级软件过程是无序的，有时甚至是混乱的，对过程几乎没有定义，成功取决于个人努力。管理是反应式的。 2．已管理级建立了基本的项目管理过程来跟踪费用、进度和功能特性。制定了必要的过程纪律，能重复早先类似应用项目取得的成功经验。 3．已定义级已将软件管理和工程两方面的过程文档化、标准化，并综合成该组织的标准软件过程。所有项目均使用经批准、剪裁的标准软件过程来开发和维护软件，软件产品的生产在整个软件过程是可见的。 4．量化管理级分析对软件过程和产品质量的详细度量数据，对软件过程和产品都有定量的理解与控制。管理有一个作出结论的客观依据，管理能够在定量的范围内预测性能。5．优化管理级过程的量化反馈和先进的新思想、新技术促使过程持续不断改进。 每个等级都被分解为过程域，特殊目标和特殊实践，通用目标、通用实践和共同特性： 每个等级都有几个过程区域组成，这几个过程域共同形成一种软件过程能力。每个过程域，都有一些特殊目标和通用目标，通过相应的特殊实践和通用实践来实现这些目标。当一个过程域的所有特殊实践和通用实践都按要求得到实施，就能实现该过程域的目标。 CMMI的原则、目标和方法 一、CMMI的原则： 1．强调高层管理者的支持。过程改进往往也是由高层管理者认识和提出的，大力度的、一致的支持是过程改进的关键。 2．仔细确定改进目标，首先应该对给定时间内的所能完成的改进目标进行正确的估计和定义并制定计划。选择能够达到的目标和能够看到对组织的效益。 3．选择最佳实践，应该基于组织现有的软件活动和过程财富，参考其他标准模型，取其精华去其糟粕，得到新的实践活动模型。 4．过程改进要与组织的商务目标一致，与发展战略紧密结合。 二、CMMI目标:
工作计划管理的重要特性
工作计划管理的重要特性 篇一：计划管理的重要特性 经常听到有人说，“计划没有变化快”，“具备什么条件干什么活”，“计划的再好也会有意想不到的情况发生”等等，这些说法都是片面的，没有计划的管理工作就会像一团乱麻，错误、漏洞百出，效率低下。 我个人认为，计划恰恰是为变化制定的，有了计划才能更有效的应对变化，通过应对变化措施的评估，为再次制定计划时提供参考和依据。 计划、组织、控制，是管理的三项职能，而作为计划，是管理工作之先。一项工作，首先要具有计划，才会有后续的组织和控制，没有计划的工作，不叫管理工作。 一、计划制定的原则： 计划的制定遵循SMART原则。 （一）具体的（Specific）： 对于大的计划，要分阶段、分步骤，准确分析执行过程中的环境、影响因素等，做出周密的对策和行动方案。计划做的周密、具体，可以减少执行中的沟通成本、干扰、困惑。即使一些小的工作项目，计划中也不能忽略细节。比如一场会议，要针对主题，从会议场所的选定、布置，会议议程的安排，会议发言人的提前通知，发言稿的准
备、审核，参会人员通知，参会人员住宿、餐饮安排等等计划具体，并落实到执行人。 （二）可衡量的（Measurable）： 计划的阶段目标结果要可衡量，让执行者明确，以便掌握和控制工作进度、检查、跟踪考核。 （三）达成一致的（Attainable）： 所有的计划都是因一定的目的、目标而定，目标是终点，计划就是设计要达到终点所必须经过的历程。 （四）可实现的(Realistic）： 计划必须是可以实现的，可操作的，不切实际的计划不仅浪费做计划花的时间和精力，还会引起员工抱怨，影响执行，达不到目的，形如空文。 （五）有时间限制的(Time-based)： 企业根据自己的发展设定了目标，我们的工作就要围绕这个目标在规定的时限内去完成。计划要具体地体现工作进度，以便在预期时间完成任务。 以上是针对计划内容的制定原则，作为计划制定的表述，应该要做到简洁。在实际工作中，中层领导者在做工作计划，布置工作任务的时候，不要洋洋洒洒，旁征博引，抓不住主题，而影响了工作的执行。简洁、明确而不乏具体的工作计划，可以让员工很好把握工作重点，开展工作。 二、计划制定的要素：
CMMI5文档之配置项状态报告模板
配置项状态报告 文档编号：FHI_CMMI_CM_TEM_LOG 文档信息：配置项状态报告 文档名称：配置项状态报告 文档类别：CMMI模板 密级：内部秘密 版本信息：1.1 建立日期：2016-1-19 创建人：EPG 批准人：李庆林 批准日期：2016-2-25 存放位置：集成公司组织资产库/组织标准过程 编辑软件：Microsoft Office 2003 中文版
文档修订记录 *变化状态：C――创建，A——增加，M——修改，D——删除
目录 1 基线域 (4) 1.1 需求RMBL (4) 1.2 设计SDBL (4) 1.3 运行PRBL (5) 2 受控域 (5) 2.1 需求开发计划 (5) 2.2 项目计划 (6) 2.3 项目监控 (6) 2.4 沟通管理 (6) 2.5 需求管理 (6) 2.6 产品集成 (6) 2.7 测试 (6) 2.8 配置管理 (6) 2.9 质量保证 (7) 2.10 项目评审 (7) 2.11 项目培训 (7) 2.12 决策分析 (7) 2.13 用户资料 (7) 2.14 项目验收 (7)
1基线域 VSS工具 ***************** Version 1 ***************** User: Admin Date: 08-12-04 Time: 9:50 Created 01基线域 SVN工具 Revision: 1 Author: liuhy Date: 16:43:15, 2008年11月19日 Message: ---- Added : /项目名称/Trunk/Documents/01基线域 1.1需求RMBL ***************** Version 2 ***************** User: Admin Date: 08-12-04 Time: 9:50 Created 01需求RMBL ***************** 01需求RMBL ***************** User: Admin Date: 08-12-04 Time: 9:50 Added项目名称用户需求说明书.doc ***************** 01需求RMBL ***************** User: Admin Date: 08-05-16 Time: 17:10 Added 项目名称软件需求规格说明书.doc ***************** 项目名称用户需求说明书.doc ***************** User: Admin Date: 08-12-04 Time: 9:54 Checked in $/项目名称/02基线域/01需求RMBL Comment:根据变更申请表进行修改。 ***************** 项目名称软件需求规格说明书.doc ***************** User: Admin Date: 08-12-04 Time: 9:54 Checked in $/项目名称/02基线域/01需求RMBL Comment:根据变更申请表进行修改。 1.2设计SDBL ***************** Version 3 ***************** User: Admin Date: 08-12-04 Time: 9:50
全套CMMi软件质量管理体系
XXXXX计算机软件有限公司 XX软件质量管理体系 V1.0 XX软件研发部 2010/12/1
目录 第一篇总则 (5) 一、《XX软件质量管理体系》的实施 (5) 二、目的 (5) 三、背景介绍 (5) 四、体系总体介绍 (7) 第二篇项目管理 (9) 一、立项管理 (9) 二、结项管理 (19) 三、项目计划 (24) 四、项目监控 (36) 五、风险管理 (44) 六、需求管理 (49) 第三篇技术实现过程 (57) 一、技术预研 (57) 二、SCRUM过程 (61) 三、用户验收 (70) 四、技术评审 (74) 第四篇支撑过程 (82) 一、配置管理 (82) 二、质量保证 (90) 三、培训管理 (99)
四、服务与维护 (106)
第一篇总则 一、《XX软件质量管理体系》的实施 XX计算机软件有限公司依据CMMi（软件能力成熟度模型集成）框架，结合公司多年来实施“敏捷开发”的开发方法的经验，以及公司的实际情况，编写的《XX软件质量管理体系》V1.0版已经编写完成。 本体系文档是公司质量管理体系法规性文件，是指导公司建立并实施质量管理体系的行动准则。公司全体员工必须遵照执行。 二、目的 本文档的目的在于： 通过建立软件过程管理体系，提高企业的软件过程能力，保证软件质量，保证商 务目标的实现。 基于精简的CMMi 3级管理体系，结合企业实际情况和经验积累，结合敏捷开发 的SCRUM方法。开发适合XX软件有限公司发展的软件过程管理体系。 使得XX软件的软件开发过程管理基本满足CMMi 3级要求。 三、背景介绍 CMMI-DEV CMMI是个了不起的规范，但是仍然有很多不足之处。CMMI对于项目管理很有指导价值，但是它对技术开发过程的论述却不够深入。对于大多数软件项目而言，技术开发占总工作量的70％以上，而项目管理占总工作量的30％以下。对大多数企业而言，技术开发过程的规范化比项目管理过程的规范化尤为重要与迫切。 软件开发是如此的灵活，如果没有规范来指导与制约，就容易因无序而导致混乱。但
CMMI5文档之产品集成计划模板
XXXXXX 产品集成计划 文档编号：FHI_CMMI_PI_TEM 文档信息：产品集成计划模板 文档名称：产品集成计划模板 文档类别：CMMI模板 密级：内部秘密 版本信息：1.1 建立日期：2016-1-5 创建人：EPG 批准人：李庆林 批准日期：2016.2.25 存放位置：集成公司组织资产库/组织标准过程 编辑软件：Microsoft Office 2003 中文版
文档修订记录（引用时请修改为实际项目的信息） *变化状态：C――创建，A——增加，M——修改，D——删除
目录 1前言 (4) 1.1目的 (4) 1.2范围 (4) 1.3术语 (4) 1.4参考文献 (4) 2产品集成设计 (5) 2.1集成测试过程角色职责映射表 (5) 2.2产品集成顺序设计 (5) 2.3产品集成环境设计 (5) 2.4产品集成规程与准则设计 (6)
1前言 1.1目的 [ 明确给出该产品集成计划的目的。比如，是为了各项目小组或任务分包商对集成任务有一个统一的认识，同时有一个统一的进度安排。] “产品集成”的目的在于将产品构件集成成更复杂的产品构件或完整的产品，确保所集成的产品恰当地发挥作用，确保交付产品。 制定本文档的目的，是为了项目组将项目涉及的产品构件（包括新开发的、重用的）有序、最佳的组装起来，提供可交付的产品。 1.2范围 [ 描述本文档涉及到的系统范围。] 1.3术语 1、产品集成：将产品构件集成成更复杂的产品构件或完整的产品。 2、集成顺序：是产品构件（集成单元）被集成先后顺序。集成顺序应与技术解决方案过程域中解决方案的选择及产品与产品组件的设计和谐一致。 3、集成接口定义：是描述产品构件（集成单元）应遵守的共同约定，例如采用构件构造系统，集成单元应遵循构件系统规范（COM/DCOM/CORBAR/OMS等）。 4、集成环境：能够开展产品集成工作最基础的软硬件环境，集成环境可自外部取得或项目组自行开发。 1.4参考文献 [ 产品集成计划中应用的参考文献。]
CMMI5文档之质量保证计划模板.docx
质量保证计划 文档编号： FHI_CMMI_QA_TEM_PL 文档信息：质量保证计划 文档名称：质量保证计划 文档类别： CMMI 模板 密级：内部秘密 版本信息： 1.1 建立日期： 2016-1-19 创建人： EPG 批准人：李庆林 批准日期： 2016-2-25 存放位置：集成公司组织资产库 /组织标准过程编辑软件： Microsoft Office 2003 中文版
文档修订记录 版本编号或者 变化状态简要说明（变更内容和 修改日期变更人批准日期批准人 更改记录编号变更范围） V1.0C创建2016-1-19张娜娜2016-2-25李庆林V1.1M文档编号去掉版本号2016-4-17邓沛沛2016-4-17李庆林 *变化状态： C――创建， A——增加， M——修改， D——删除
目录 第一章概述 (4) 第二章资源 (4) 2.1 角色和人员 (4) 第三章 QA 活动计划 (4) 3.1 过程评审 (4) 3.2 产品审计 (5) 3.3 对项目开发工作的支持 (6) 3.4 QA 工作日程 (7) 3.5 QA 报告发布 (7)
第一章概述 项目 QA 人员在项目策划期间，就应着手制订项目的质量保证计划（SQAP），以确保质量保证 计划中活动的范围和时间与项目开发计划(SDP)、软件配置管理计划(SCMP) 以及软件测试计划（ STP）保持一致，计划中要确定项目的度量收集计划，同时说明对项目的支持活动。 制定本计划的目的是定义在{ ××项目 } 中 QA 的任务、职责及活动时间表等，为实施QA活动提供指导。 本计划适用于{ ××项目 } 的 QA 工作。 第二章资源 2.1 角色和人员 参见《软件开发计划》中的项目人员部分。 第三章QA 活 动计划 3.1 过程评审 序 评审内容评审对象 号 一、项目策划、集成项目管理 1 项目启动项目经理 项目计划、风项目经理 2险管理 3配置管理配置管理员二、项目执行与集成管理 4风险管理项目经理5度量分析项目经理6配置管理配置管理员7需求管理项目经理8项目监控项目经理9评审活动项目经理10项目培训项目经理三、工程评审过程一览表 评审 参照标准备注时间立项过程 项目策划过程、生命计划 周期模型、过程裁减评审 规程、质量保证过程、完成 风险管理过程 配置管理过程 风险管理过程 度量与分析过程 配置管理过程 定期 / 里 需求管理过程 程碑 项目监督与控制过程 点 验证过程、评审规程 组织培训过程
cmmi软件开发流程
c m m i软件开发流程 Prepare d on 24 November 2020
软件开发流程软件项目生命周期模型
需求分析 需求分析流程图 过程描述 1、由部门经理组建临时项目组，并指定PM、开发人员、测试人员、QA，人数根据项目规模确定。
2、PM制定需求阶段日程表，该表须通过研发经理审核。 3、PM指示配置管理员建立配置库。 4、由PM与测试负责人提出裁剪申请，QA指导临时项目组人员对项目进行裁剪，形成项目裁剪表。 5、EPG和部门经理对裁剪结果进行审批，审批通过项目裁剪表正式生效。 6、PM与测试负责人确定项目管理机制，内容包括组织结构、沟通、跟踪、报告、风险管理、问题管理、QA、CM等。 7、项目组人员与客户进行沟通，编写需求清单列表。 8、PM组织临时项目组成员确定系统架构，编写架构设计书和需求规格书。架构设计过程中的重要的技术方案选择、开发/采购/复用分析等内容要明确体现在架构设计书中。 ?对技术方案选择(例如，系统结构、开发平台、数据库等的选择)，要事先建立评价准则(例如，满足系统需求的能力(例如，功能、性能、可靠性等)、技术的发展前景、供应商资质与实力等)及相对优先级，采用讨论表决的方法选择并确定最终的技术方案。 ?关于自行开发和采购复用的分析， ?如果公司有基本满足系统需要的可复用组件(包括其分析、设计、代码、测试用例等)，一般应进行复用； ?本公司没有能力开发或没有必要开发的非核心技术部分，如果采购成本在项目可接受范围内，可考虑采购； ?否则，由项目组自行开发。 架构设计的总体候选方案选择和供应商选择要使用正式的方法做决策。 9、PM召集临时项目组、测试负责人等技术骨干评审架构设计书和需求规格书。 10、PM组织临时项目组与客户沟通、说明需求，必要时编制系统原型向客户展示，直到临时项目组、客户就需求的真实含义达成共识、客户书面确认需求规格书为止。 11、临时项目组确定项目目标的范围，明确系统边界，建立系统的模块分解结构。 12、PM与测试负责人遵循《项目估算流程》组织人员进行项目估算。 13、PM、测试负责人与临时项目组确定项目关键参数。 ?工作量、工期、日程、人数 ?成本/预算（由于本公司的项目的绝大部分成本是人力成本，对估计成本的管理等同于估计工作量的管理，对实际成本的管理等同于实际工作量的管理，对预算的管理等同于计划工作量的 管理。） ?质量目标 14、PM、测试负责人与部门经理协调人员及资源、计划知识技能、协调相关干系人的参与。 15、项目组基于公司环境标准，结合项目实际情况建立适合的工作环境。 16、PM、测试负责人编制项目计划书。 17、PM、测试负责人编制项目日程表。 18、临时项目组、研发部、QA评审项目计划书，评审通过后正式生效。 19、PM指示配置管理员建立配置基线。 20、PM编制阶段总结报告（项目总结报告中的度量分析页面），召开阶段会议。
CMMI5文档之评审规程
评审规程 文档编号：FHI_CMMI_VER_PRD_SYN 文档信息：评审规程 文档名称：评审规程 文档类别：CMMI规程 密级：内部秘密 版本信息：1.2 建立日期：2016-1-5 创建人：EPG 批准人：李庆林 批准日期：2016-2-25 存放位置：集成公司组织资产库/组织标准过程编辑软件：Microsoft Office 2003 中文版
文档修订记录
目录 s 1.简述 (4) 1.1.目的 (4) 1.2.适用范围 (4) 1.3.术语表 (4) 2.概述 (4) 3.同行评审过程说明 (6) 3.1.正式评审 (6) 3.2.技术评审 (9) 3.3.走查 (10) 3.4.审批 (11) 3.5.审阅 (11) 3.6.邮件评审 (11) 4.分析评审结果 (11) 5.同行评审验证准则 (11) 5.1.同行评审严重程度定义 (11) 5.2.同行评审不通过的准则 (11) 6.QA评审/审计 (12) 7.CM审计 (12)
1. 简述 1.1. 目的 本规程的目的是为了定义在软件生命周期内不同的评审类型，确定评审的时机和评审的一般流程，并规定各项评审的主要内容、入口、出口和评审人员等。 1.2. 适用范围 本规程适用于本公司的所有软件项目。 1.3. 术语表 无 2. 概述 软件生命周期内的评审分为三类：同行评审、QA 评审和审计、CM 审计，如下图所示： ( 经验人员或客户代表CM 人员 QA 人员相关人 员 : 图表 1 评审分类
正式评审活动评审的一般是比较重要的或具有里程碑意义的工作产品。正式评审的目的既是为了发现被评审项的缺陷，也是对重要工作产品的质量验证。评审的结果(通过或不通过)标志着项目是否进入下一个开发阶段。因此，项目评审具备一定意义上承诺的意味。 同行评审是在软件开发过程中按照明确定义的过程对工作产品进行系统检测的方式之一，同行评审分为技术评审、走查两种方式。 技术评审、走查由一组与软件工作产品的作者处于同一级别的、具有类似工作（技术）经验的技术人员来进行。技术评审和走查是作业过程中不可缺少的部分，使得缺陷能及早排除，产生较高的生产率和高质量产品。技术评审和走查关注的是被评审的软件工作产品本身，而不是软件工作产品的作者。与软件工作产品的作者相关的管理人员不应参加技术评审和走查，因为相关的管理人员参加技术评审和走查可能会妨碍评审人提出问题或发现缺陷。技术评审和走查的结果也不应作为管理人员评价个人工作业绩的依据。 ●正式评审的特点： 高层经理通常被邀请参加。 评审对象可是技术工作产品也可是管理工作产品。 重点在于识别问题，不是解决问题。 要给评审做出结论。 ●正式评审和技术评审及走查的区别： 正式评审中，软件工作产品或软件工作产品集要交给管理人员、客户、最终用户或其他相关人员，以征得他们的认可或同意。正式评审一般在任务完成后进行。 技术评审及走查中，软件工作产品或软件工作产品集提交给软件开发单位的同行，以发现其中存在的缺陷。管理人员、客户和最终用户一般不参与技术评审及走查，技术评审 及走查是不可缺少的任务。 有些软件工作产品需要经过正式评审，有些则需要经过技术评审及走查，而还有一些两者都需要。 根据评审对象的性质及项目的重要程度，可选择正式评审、技术评审、走查、审批、审阅、非正式评审六种方式进行评审活动。五者的区别如下：
cmmi软件开发流程
c m m i软件开发流程 公司内部编号：（GOOD-TMMT-MMUT-UUPTY-UUYY-DTTI-
软件开发流程软件项目生命周期模型
需求分析需求分析流程图
过程描述
1、由部门经理组建临时项目组，并指定PM、开发人员、测试人员、QA，人数根据项目规模确定。 2、PM制定需求阶段日程表，该表须通过研发经理审核。 3、PM指示配置管理员建立配置库。 4、由PM与测试负责人提出裁剪申请，QA指导临时项目组人员对项目进行裁剪，形成项目裁剪表。 5、EPG和部门经理对裁剪结果进行审批，审批通过项目裁剪表正式生效。 6、PM与测试负责人确定项目管理机制，内容包括组织结构、沟通、跟踪、报告、风险管理、问题管理、QA、CM等。 7、项目组人员与客户进行沟通，编写需求清单列表。 8、PM组织临时项目组成员确定系统架构，编写架构设计书和需求规格书。架构设计过程中的重要的技术方案选择、开发/采购/复用分析等内容要明确体现在架构设计书中。 对技术方案选择(例如，系统结构、开发平台、数据库等的选择)，要事 先建立评价准则(例如，满足系统需求的能力(例如，功能、性能、可靠 性等)、技术的发展前景、供应商资质与实力等)及相对优先级，采用讨 论表决的方法选择并确定最终的技术方案。 关于自行开发和采购复用的分析， 如果公司有基本满足系统需要的可复用组件(包括其分析、设计、代码、 测试用例等)，一般应进行复用； 本公司没有能力开发或没有必要开发的非核心技术部分，如果采购成本 在项目可接受范围内，可考虑采购； 否则，由项目组自行开发。 架构设计的总体候选方案选择和供应商选择要使用正式的方法做决策。
软件CMMI3过程改进项目计划模板
XXXX软件项目CMMI3过程改进项目计划 XXXX企业有限公司 ____年___月___日
文档信息 修改记录
目录 软件CMMI3过程改进项目计划 (2) 1 引言 (2) 1.1 编写目的 (2) 1.2 背景 (2) 1.3 定义 (2) 1.4 参考资料 (2) 2 项目概述 (2) 2.1 项目目标 (2) 2.2 项目范围 (3) 2.3 客户与最终用户介绍 (3) 2.4 验收标准 (3) 2.5 项目限制和制约 (3) 3 项目组织架构 (3) 3.1 组织架构 (3) 3.2 人员及职责 (3) 4 人力资源计划 (4) 5 沟通计划 (5) 6 风险计划 (5) 7 进度计划 (6) 8 QA计划 (6) 9 配置管理计划 (6)
软件CMMI3过程改进项目计划 1 引言 1.1 编写目的 用于指导，规划整个过程改进过程。 1.2 背景 近年来，CMMI已经在众多软件公司得到成功实施，提高了软件公司的过程能力。鉴于此，公司决定在本公司范围内实施CMMI3级过程改进，旨在提高公司软件开发效率，保证软件研发项目能够有序进行。 1.3 定义 参见《CMMI3过程改进项目词汇表》 1.4 参考资料 《CMMI for Development Version 1.2》 《CMMI 精粹-集成化过程改进实用导论》 2 项目概述 2.1 项目目标 通过CMMI过程改进项目，在本公司建立符合CMMI3级要求的软件研发过程框架，并在本公司所有软件研发项目应用；能够根据组织建立的目标，对过程进行不断完善和改进；最终目的是规范化本公司软件研发过程，从而提高开发效率。
CMMI5文档之项目开发计划模板
[**项目] 项目开发计划模板 文档编号：FHI_CMMI_PP_错误！未指定书签。错误！未指定书签。错误！未找到引用源。_PDP 文档信息：项目开发计划模板 文档名称：项目开发计划模板 文档类别：CMMI模板 密级：内部秘密 版本信息：1.1 建立日期：2016-1-13 创建人：EPG 批准人：李庆林 批准日期：2016-2-25 存放位置：集成公司组织资产库/组织标准过程 编辑软件：Microsoft Office 2003 中文版
文档修订记录（引用时请修改为实际项目的信息）
目录 1.概述 (4) 1.1.项目概述 (4) 1.2.术语定义 (4) 2.项目干系人列表 (4) 3.提交客户的工作产品 (5) 4.项目策划 (5) 4.1.软件生命周期模型定义 (5) 4.2.项目定义软件过程 (5) 4.3.质量目标 (5) 4.4.WBS (5) 4.5.风险管理 (5) 4.6.数据管理 (7) 4.7.软件估计 (7) 4.7.1.估计汇总 (7) 4.7.2.进度估计 (7) 4.7.3.软件工程设备和支持工具估计 (8) 4.7.4.关键计算机资源估计 (8) 4.8.需求管理计划 (8) 4.9.沟通计划 (8) 4.9.1.制定与客户的沟通计划 (9) 4.9.2.制定与其它小组的沟通计划 (9) 4.9.3.制定组内沟通计划 (9) 4.9.4.明确与客户、其他组间关键依赖关系 (9) 4.10.团队建设与维护计划 (10) 4.11.培训计划 (10) 4.12.软件质量保证计划 (10) 4.13.配置管理计划 (10) 4.14.产品验证计划之同行评审计划 (11) 4.15.产品验证计划之软件测试计划 (11) 4.16.项目度量计划 (11) 5.项目跟踪计划 (11)
CMMI5文档之概要设计说明书模板
概要设计说明书 文档编号：FHI_CMMI_TS_TEM_SUMD 文档信息：概要设计说明书 文档名称：概要设计说明书 文档类别：CMMI模板 密级：内部秘密 版本信息：1.1 建立日期：2016-1-5 创建人：EPG 批准人：李庆林 批准日期：2016.2.25 存放位置：集成公司组织资产库/组织标准过程 编辑软件：Microsoft Office 2003 中文版
*变化状态：C――创建，A——增加，M——修改，D——删除
目录 1导言 (4) 1.1目的 (4) 1.2范围 (4) 1.3命名规则 (4) 1.4术语定义 (4) 1.5相关文档 (5) 1.6参考资料 (5) 2总体结构设计 (5) 2.1总体结构图设计 (5) 2.2运行环境设计 (6) 2.3子系统清单 (6) 2.4功能模块清单 (7) 3模块功能分配 (7) 3.1一级模块功能名称 (7) 4外部接口设计 (8) 4.1外部接口模块清单 (8) 4.2外部接口1设计 (8) 4.3外部接口2设计 (8) 5出错处理设计 (9) 5.1出错输出信息 (9) 5.2出错处理对策 (9) 6其它设计 (9)
1导言 本章对该文档的目的、功能范围、术语、相关文档、参考资料、版本更新进行说明。 1.1目的 本文档的目的旨在推动软件工程的规范化，使设计人员遵循统一的概要设计书写规范，节省制作文档的时间，降低系统实现的风险，做到系统设计资料的规范性与全面性，以利于系统的实现、测试、维护、版本升级等。 1.2范围 本文档用于软件设计阶段的概要设计，它的上游（依据的基线）是需求分析规格书，它的下游是系统详细设计说明书，并为详细设计说明书提供测试的依据。 软件概要设计的范围是：软件系统总体结构、外部接口、主要部件功能分配、全局数据结构以及部件之间的接口等方面的内容。 1.3命名规则 1.变量对象命名规则 申明全局变量、局部变量对象的命名规则。 2.数据库对象命名规则 申明数据库表名、字段名、索引名、视图名对象的命名规则。 1.4术语定义
CMMI5文档之决策分析报告模板
决策分析报告 文档编号：FHI_CMMI_DAR_TEM 文档信息：决策分析报告 文档名称：决策分析报告 文档类别：CMMI模板 密级：内部秘密 版本信息：1.1 建立日期：2016-1-19 创建人：EPG 批准人：李庆林 批准日期：2016-2-25 存放位置：集成公司组织资产库/组织标准过程编辑软件：Microsoft Office 2003 中文版
文档修订记录
目录 1概述 (4) 1.1 决策内容描述 (4) 1.2 决策组织结构图 (4) 1.3 参考文件和文献 (4) 2评价标准 (4) 3备选解决方案 (4) 3.1 方案1 (4) 3.2 方案2 (4) 3.3 方案3 (4) 4评价方法 (5) 5评价备选解决方案 (5) 6结论 (7)
1概述 [简要描述编写这个文档的背景和理由] 1.1决策内容描述 [对需要进行决策分析的问题进行描述] 1.2决策组织结构图 [决策专家组成员进行描述，包括决策发起人（项目经理）、决策组专家等] 决策发起人： 专家组成员： 1.3参考文件和文献 [描述进行此次决策分析需要参考和引用的文献] 2评价标准 [建立评价备选的解决方案的标准] [列出头脑风暴法产生的各种评价准则，并加以分类及说明。选择5-7条确定的评价准则，移至前5-7行。推荐等级（权重）的值为1-10分制。] 3备选解决方案 [对于若干可选解决方案进行描述] 3.1方案1 3.2方案2 3.3方案3
4评价方法 [确定对备选解决方案进行评价的方法并进行详细描述] 5评价备选解决方案 [描述对每个备选解决方案的评价过程和结果。请用模板中的辅助表填写，COPY到此。]
cmmi软件开发流程图
软件开发流程软件项目生命周期模型
需求分析 需求分析流程图 过程描述 1、由部门经理组建临时项目组，并指定PM、开发人员、测试人员、QA，人数根据项目规模确定。
2、PM制定需求阶段日程表，该表须通过研发经理审核。 3、PM指示配置管理员建立配置库。 4、由PM与测试负责人提出裁剪申请，QA指导临时项目组人员对项目进行裁剪，形成项目裁剪表。 5、EPG和部门经理对裁剪结果进行审批，审批通过项目裁剪表正式生效。 6、PM与测试负责人确定项目管理机制，内容包括组织结构、沟通、跟踪、报告、风险管理、问题管理、QA、CM等。 7、项目组人员与客户进行沟通，编写需求清单列表。 8、PM组织临时项目组成员确定系统架构，编写架构设计书和需求规格书。架构设计过程中的重要的技术方案选择、开发/采购/复用分析等内容要明确体现在架构设计书中。 ?对技术方案选择(例如，系统结构、开发平台、数据库等的选择)，要事先建立评价准则(例如，满足系统需求的能力(例如，功能、性能、可靠性等)、技术的发展前景、 供应商资质与实力等)及相对优先级，采用讨论表决的方法选择并确定最终的技术方 案。 ?关于自行开发和采购复用的分析， 如果公司有基本满足系统需要的可复用组件(包括其分析、设计、代码、测试用例等)，一般应进行复用； 本公司没有能力开发或没有必要开发的非核心技术部分，如果采购成本在项目可接 受范围内，可考虑采购； 否则，由项目组自行开发。 架构设计的总体候选方案选择和供应商选择要使用正式的方法做决策。 9、PM召集临时项目组、测试负责人等技术骨干评审架构设计书和需求规格书。 10、PM组织临时项目组与客户沟通、说明需求，必要时编制系统原型向客户展示，直到临时项目组、客户就需求的真实含义达成共识、客户书面确认需求规格书为止。 11、临时项目组确定项目目标的范围，明确系统边界，建立系统的模块分解结构。 12、PM与测试负责人遵循《项目估算流程》组织人员进行项目估算。 13、PM、测试负责人与临时项目组确定项目关键参数。 ?工作量、工期、日程、人数 ?成本/预算（由于本公司的项目的绝大部分成本是人力成本，对估计成本的管理等同于估计工作量的管理，对实际成本的管理等同于实际工作量的管理，对预 算的管理等同于计划工作量的管理。） ?质量目标 14、PM、测试负责人与部门经理协调人员及资源、计划知识技能、协调相关干系人的参与。 15、项目组基于公司环境标准，结合项目实际情况建立适合的工作环境。 16、PM、测试负责人编制项目计划书。 17、PM、测试负责人编制项目日程表。 18、临时项目组、研发部、QA评审项目计划书，评审通过后正式生效。 19、PM指示配置管理员建立配置基线。 20、PM编制阶段总结报告（项目总结报告中的度量分析页面），召开阶段会议。
CMMI 3级--EPG的问题及答案
1、EPG的职责是什么？职责在哪个文件定义的？日常工作做些什么？ EPG的职责是：保障CMMI体系在公司有效执行，推动公司过程改进工作 体现在：OPD的《EPG工作过程》文件 日常工作是： 1、制定、维护组织过程资产，并以此为项目提供帮助和指导 2、收集过程改进意见、制定过程改进计划，推动公司过程改进工作； 3、评价过程改进的效果； 4、对组织过程培训工作进行统一管理； 2、组织过程资产库的内容？ 1、标准体系文件 2、组织度量库 3、项目文档库 4、组织知识库（培训资料） 5、公共组件库 6、组织最佳实践库 3、是如何管理体系文件的？ 由组织级CM进行管理。 根据《过程改进计划》制定《基线发布计划》，体系文件更新后按时发布基线（EPG及高层经理审批基线） 4、是如何管理组织经验库的？ -EPG根据项目的度量数据定期更新PAL数据（项目结束时） - 项目结束后的提供的经验教训、共享知识、最佳实践等提交EPG审核后纳入组织PAL。- 定期对PAL进行分析，并向公司公布PAL情况。 5、公司的组织方针是什么？如何制定？谁来批准的？ 《过程改进的方针》，由公司高层管理组和EPG组共同制定。公司高层批准。 6、EPG如何计划和开展组织的过程改进活动的？ 过程改进意见来源： 公司高层的意见（商业目标分解），QA问题分析、小型评估、咨询公司的诊断，EPG的定期审核，项目组提出意见。得到改建项，收录进《过程改进意见收集表单》并进行分析（是否改进、预计解决时间），在《过程改进记录表》中 - 依据改进建议制定改进计划 - 高层批准改进计划后，EPG制定过程行动计划。 - 建立/修改体系文件，评审后发布。 - 对相关人员进行体系文件的培训，培训后先在试点部门和项目中执行。 - 指导和监督过程改进的执行。 - 收集改进建议，完善后在公司推广。 - 按SEI的IDEAL模型持续进行改进。 7、EPG是如何开展工作？