CMM3标准体系项目管理人员
cmmi level3 目标
文章标题：深度解析CMMI Level 3目标概述：在软件工程和项目管理领域中，CMMI（Capability Maturity Model Integration）是一个被广泛接受和应用的标准，用于评估和提高组织的软件和系统工程能力。
CMMI Level 3是CMMI的一个重要水平，它涵盖了一系列目标和实践，旨在帮助组织改进其软件过程能力，提高过程的预测性和可管理性。
本文将深入解析CMMI Level 3目标，帮助读者全面理解其意义和实践价值。
一、目标1：过程改进在CMMI Level 3中，过程改进是一个关键目标。
通过系统地管理和改进软件开发过程，组织能够提高生产力、质量和成本效益。
在实践中，组织应该建立并维护一个有效的软件过程改进计划，并通过实施和监控不断改进。
过程改进不仅包括技术方面的优化，还包括组织文化和人员素质的提升。
二、目标2：工程过程定义工程过程定义是CMMI Level 3的另一个重要目标。
通过明确定义软件工程过程，组织能够确保项目成员对过程的理解和遵循。
工程过程定义涉及到过程文档的编制和维护，以及工程实践的规范化和标准化。
只有当工程过程被准确定义和实施，才能有效管理和改进软件项目的开发过程。
三、目标3：工程过程的管理工程过程的管理是CMMI Level 3的一项重要任务。
通过建立有效的工程过程管理机制，组织能够实现对软件开发过程的有效监控和控制。
工程过程的管理涉及到定量管理、过程绩效度量和过程控制。
通过科学的数据分析和过程监控，组织能够及时发现和解决软件开发过程中的问题，确保项目按时、按质高效交付。
四、目标4：产品集成在CMMI Level 3中，产品集成是一个关键目标。
通过有效地管理和实施产品集成过程，组织能够确保软件产品的质量和稳定性。
产品集成包括需求管理、配置管理、界面管理和过程协同等方面。
只有当软件产品的各个部分能够有效集成和配合，才能确保整体的功能和性能达到预期的要求。
CMM中的需求管理与需求开发
需求管理（Requirements Management ）是属于CMM2中的过程域，简称为REQM ，需求开发（Requirements Development ）是CMM3中的过程域，简称RD 。
这两个过程域是CMMI 体系中关于需求的全部内容，下面分别对这两部分进行介绍。
本文对CMM 的一些基础知识、基础术语不再介绍。
需求管理与需求开发的分界线：市场营销用户需求管理层需求开发需求管理市场营销管理层项目环境项目变更 大家可以这样理解，需求管理是指对需求变更的管理、对需求的跟踪，而获取需求、定义需求则属于需求开发部分。
需求管理在CMMI 中，需求管理的目标定义为：a. 把软件需求建立一个基线供软件工程和管理使用。
b. 软件计划、活动和工作产品同软件需求保持一致。
更高的目标：软件需求的复用需求管理的原则和方法a. 必须与需求工程的其他活动紧密整合b. 需求必须是文档化的、正确的、最新的、可管理的、可理解的c. 只要需求变化了，需求变更的影响就必须被评估d. 需求必须分优先级e. 需求一定要分类管理需求管理的主要工作：特定目标和特定实践特定目标●管理需求管理需求并识别需求与项目计划和工作产品之间的差异。
●SP 1.1 取得需求理解●SP 1.2 取得需求承诺●SP 1.3 管理需求变更●SP 1.4 维护需求的双向追溯性●SP 1.5 识别项目工作与需求间的差异REQM特定目标的关系SP 1.1 取得需求理解SP 1.1 和需求提出者一同来了解需求。
l 识别出谁是需求的提供者l 识别出需求的接受标准：a. Clearly and properly stated得到清晰和恰当的定义b. Complete完整的c. Consistent with each other相互一致的d. Uniquely identified得到唯一标识的e. Appropriate to implement适宜实现f. Verifiable (testable)可以验证（测试）g. Traceable可追溯l 分析需求，确保符合已建立的准则。
CMMI研发流程角色汇总表
序号
角色
固定角色
客户代表
1 需求工程师
2 3 4 5
6 7
8
工程类
9
实施工程师 实施经理
设计工程师 产品经理
系统架构师 开发经理
开发工程师
测试工程师
10
自动化测试工程师 11
测试设计工程师 12
测试经理
13
14
集成负责人
15
集成工程师
16
集成单元组长
项目经理
项目管理
项目管理 类
17
项目组
18
测试人员经过测试设计、测试方法 和测试技能方面的培训，具备搭建 测试环境的能力。
负责测试计划和测试设计计划制订；
负责组织测试需求和测试用例的评审，协助测试工程师进 具有组织协调能力，有丰富的测试
行测试用例规划和用例标准的维护；
设计经验和测试经验。
负责协调软硬件资源；
负责测试计划和测试设计计划制订；
负责组织测试需求和测试用例的评审，协助测试设计工程 师进行测试用例规划和用例标准的维护； 负责协调软硬件资源；
具有组织协调能力，有丰富的测试 设计经验和测试经验。
负责系统测试结果的评估，给出测试结论。
制定集成计划及计划跟进和监控。
ቤተ መጻሕፍቲ ባይዱ
负责集体集成过程
集成单元组长 提供集成单元和接口
参与需求变更评估。
负责分析确定除错单是否为软件缺陷。
确定除错单的引入阶段
具有组织协调的能力，有丰富的项
分配具体的测试人员和开发人员并指定计划工时和完成时 目管理经验。
负责自动化脚本的编写、维护和执行； 参与评审测试用例，主要负责用例驱动和自动化的可实现 性评审。
CMMIL3v1.3培训项目管理
目前市场上虽然有一些CMMI培训课 程，但大多数只关注理论知识的传授 ，缺乏实际操作和案例分析，不能满 足企业的实际需求。
项目目标
培养专业的CMMI3V1.3认证咨询师
通过培训，使学员掌握CMMI3V1.3认证的核心知识和技能，具备为企业进行CMMI评估 和咨询的能力。
提高软件企业的能力成熟度
CMMI3V1.3培训项目管理
• 项目背景求分析 • 培训项目计划与组织 • 培训项目实施与控制 • 培训项目评估与收尾 • 总结与展望
01
项目背景与目标
项目背景
企业需求
随着市场竞争的加剧，企业对于软件 质量的要求越来越高，而 CMMI3V1.3认证作为国际上评估软 件企业能力成熟度的重要标准，受到 了广泛认可。
参加培训。
后续支持
培训结束后，提供一定时间的免 费答疑和后续支持，以确保学员 在实际工作中能够顺利应用所学
知识。
03
培训项目需求分析
培训需求调研
确定调研对象
确定需要调研的对象，包括潜在学员、学员上级、行业专家等， 以确保全面了解培训需求。
设计调研问卷
根据调研对象和培训目标，设计具有针对性的调研问卷，收集关于 培训内容、形式、时间等方面的需求信息。
进度报告
定期向客户提交进度报告，展 示培训项目的进展情况。
06
培训项目评估与收尾
培训项目评估方法
培训反馈表
设计培训反馈表，让参训人员对培训内容、讲师、设施等进行评 分，收集反馈意见。
培训考核
通过考试、实操等方式对参训人员进行考核，评估培训效果。
培训效果跟踪
定期跟踪参训人员在实际工作中对培训内容的运用情况，收集反馈 意见。
CMM-3级
3.1组织过程焦点 - OPF目的：组织应确立软件过程活动的职责，以改进组织的软件过程能力。
(SEPG担负该职责。
)组织过程焦点指：制定并维护组织级和项目级的软件过程的共识，并协调评估、制定、维护和改进过程的活动。
组织以设立一个小组（如软件工程过程组(SEPG)）的形式，为组织提供长期的约定和资源以协调软件过程的制定和维护。
该组负责组织软件过程活动，具体地说，就是制定和维护组织标准软件过程和相关过程财富（在组织过程定义KPA中描述），并协调软件项目的过程活动。
●目标(GOALS)：目标1.组织的过程的制定和改进活动是协调的。
目标2.与过程标准相比，可确定软件过程的长处和不足。
目标3.组织级的过程制定和改进活动是有计划的。
●执行约定（CO）约定1. 组织制定书面规定，用于协调软件过程制定与改进活动。
此规定指出：1)设立一个组，负责组织层的软件过程活动，并就这些活动与项目相协调。
2)定期对项目使用软件过程的情况进行评估，以确定过程的长处和不足。
3)项目使用的软件过程是由组织的标准软件过程剪裁得来的。
4)每个项目可用的软件过程、工具、方法及其改进均可为其他项目共享。
约定2. 高层管理者领导软件过程制定和改进活动。
向组织宣布决定，制定规划和策略。
约定3. 高层管理者监督软件过程制定和改进活动。
保证与组织经营目标和战略的一致性，提出建议，参与制定活动计划。
●执行能力（AB）能力1.存在软件工程过程组（SEPG）。
该组应配备软件技术专业人员，必要时可得到其他技术专家的支持。
组内的专业知识应涵盖软件开发、SQA、SCM。
能力2.为软件过程活动提供充足的资源和经费。
组内具有以下专业知识的人员：软件重用、计算机辅助软件工程技术(CASE)、度量、编制培训课程。
能力3.组员接受必须的培训。
如以下培训：软件工程实践、过程控制技术、组织更改管理、策划、管理和监控软件过程、技术转换。
能力4.项目开发人员和有关人员接受软件过程活动方面的定向培训。
CMMI3级软件过程 第17章 配置管理
第17章配置管理配置管理(Configuration Management,CM)的目的是通过执行版本控制、变更控制等规程，以及使用配置管理软件，来保证所有配置项的完整性和可跟踪性，配置管理是对工作成果的一种有效保护。
☆制定配置管理计划[SPP-PROC-CM-PLANNING]。
☆配置库管理[SPP－PROC－CM-LIB]。
☆配置项版本控制[SPP-PROC－CM－VERSION]。
☆配置项变更控制[SPP－PROC－CM－CHANGE]。
上述每个规程的“目标”、“角色与职责”、“启动准则”、“输入”、“主要步骤”、“输出”、“完成准则”和“度量”均已定义。
本规范适用于国内IT企业的软件研发项目。
建议用户根据自身情况（如商业目标、研发实力等）适当地修改规范，然后推广使用。
17.1 介绍项目研发和管理过程中会产生许许多多地工作成果。
例如文档、程序和数据等，它们都应当背保存起来，以便查阅和修改。
如果把所有文件一股脑地塞进计算机里，那么使用起来肯定很麻烦。
毫无疑问，人们应当将文件分类、有条理地保存起来。
凡是纳入配置管理范畴的工作成果统称为配置项（Configuration Item，CI），配置项主要有两大类：●属于产品组成部分的工作成果，例如需求文档、设计文档、源代码、测试用例等。
●项目管理和机构支撑过程域产生的文档。
这些文档虽然不是产品的组成部分，但是是值得保存。
每个配置项的主要属性有：名称、标识符、文件状态、版本、作者、日期等。
所有配置项都被保存再配置库里，确保不会混淆、丢失。
配置项及其历史记录反映了软件的演化过程。
基线(BaseLine)由一组配置组成，这些配置项构成了一个相对稳定的逻辑实体。
基线中的配置项被“冻结”了，不能再被任何人随意修改（见变更控制规程）。
基线通常对应开发过程中的里程碑(Milestone),一个产品可以有多个基线，也可以只有一个基线。
基线的主要属性有：名称、标识符、版本、日期等。
CMMI3过程基础考试试题及答案
CMMI3过程基础考试试题一、填空（每空1分，共13题，50分）1、CMM是Capability Maturity Model 的缩写，用于衡量软件过程能力的事实上的标准，共分为五级，有：初始级、可重复级、已定义级、已管理级、优化级别。
2、我公司目前通过CMM的级别是：CMM3 ，我公司的过程体系文件有哪四部分？方针、过程、记录、指南。
3、配置管理属于CMM 2 级的KPA，同行评审属于CMM 3 级的KPA。
4、需求管理过程包括需求的开发和需求的管理，需求开发包括：需求获取、需求分析和需求定义；需求管理又包括：需求确认、需求跟踪和需求变更及控制。
5、SCM是什么的缩写软件配置管理；项目组SCM由项目经理指定，负责完成的计划是配置管理计划。
6、SCCB是什么的缩写？配置管理委员会；人员组成中，必须具备的人员有：PM（项目经理）、、SQA（质量保证工程师）、SCM（配置管理员）。
7、我们公司的项目库又分为开发库和配置库，其中基线库中的内容必须经评审通过后才可纳入，在内容变更时，需依据变更流程提交变更申请审批。
8、请根据评审过程中不同角色的职责，描述下列任务应该由什么角色完成：正确地记录评审会议中发现的所有缺陷-- 评审记录员；及时提交待评审的工作产品–作者；检查评审对象，不漏掉细-- 评审专家；负责引导评审会议，确认评审专家的准备-- 评审组织者。
9、依据评审的作用和侧重点不同评审的类型有：同行评审和管理者评审；评审的组织方式又有：会议评审、会签评审、单人评审、走查四种；例：需求评审属于同行评审，建议采用会议的方式进行评审。
10、项目通常排出的进度计划含有下述内容：任务名称、完成百分比、工期、开始时间、结束时间、前置任务和资源名称；其中前置任务一列表明了工作的逻辑关系及时间关系；项目进度完全与计划一致是最理想的状况，实际每个阶段都允许一定的进度偏差，我们公司CMM过程规定时间进度的阈值为15% ，当实际进度超出阈值范围时，项目经理需进行计划调整。
CMMI3级18个过程域
CMMI3级18个过程域CMMI（Capability Maturity Model Integration）是一种用于评价和改进组织的软件工程能力的模型。
CMMI模型将软件工程能力分为不同的级别，目前最高级别是CMMI级别5、在CMMI模型中，共有18个过程域，每个过程域都包含一组过程目标和过程实践。
下面将介绍CMMI级别3中的18个过程域，并对每个过程域进行详细解析。
1. 要求开发（Requirements Development）：该过程域涉及确定、分析和记录系统和软件需求的活动。
它包括需求的获取、管理、分析和验证。
2. 要求管理（Requirements Management）：该过程域涉及组织和控制项目的需求。
它包括需求的识别、跟踪、控制和变更管理。
3. 项目计划和监控（Project Planning and Monitoring）：该过程域涉及制定和维护项目计划，并监控项目活动的执行。
它包括识别和规划项目活动、建立项目计划、监控项目进展和基于此进行调整。
4. 项目监控和控制（Project Monitoring and Control）：该过程域涉及监控和控制项目执行过程中的工作和活动。
它包括收集和分析项目绩效数据、对比实际和计划绩效，对项目进展进行控制。
5. 供应商协议管理（Supplier Agreement Management）：该过程域涉及与供应商达成协议，并管理和监控供应商的活动。
它包括选择供应商、与供应商协商、管理和控制供应商的交付和绩效。
6. 产品集成（Product Integration）：该过程域涉及对各个组成部分进行整合，形成最终产品。
它包括定义和实施产品集成策略、执行产品集成和验证集成后的产品。
7. 风险管理（Risk Management）：该过程域涉及识别、评估和控制项目和产品的风险。
它包括制定风险管理计划、识别和评估风险、并采取相应的风险缓解措施。
8. 决策分析和解决方案评估（Decision Analysis and Resolution）：该过程域涉及通过分析和评估不同的解决方案，制定决策。
CMMI3级过程域
CMMI3级过程域CMMI (Capability Maturity Model Integration) 是由美国国防部发起的一种软件过程成熟度模型，它对软件和系统开发过程进行了评估和改进，旨在提高组织的软件开发能力。
CMMI 将过程分为若干级别，从初始级别到最高级别，即 CMMI5 级，每个级别由一些过程域 (Process Area, PA) 组成。
CMMI3 级是一个中间级别，对于组织来说已经达到了一定的成熟度，具备一定的过程能力。
1. 需求管理 (Requirements Management)：确保需求的准确和及时管理，包括需求的收集、分析、追踪和验证。
2. 项目计划与监控 (Project Planning and Monitoring)：制定和管理项目计划，确保项目按照计划进展，并对项目的进度、资源和风险进行监控和控制。
3. 项目质量管理 (Project Quality Management)：制定和实施项目质量计划，监控和改进项目的质量，确保交付的产品和服务符合质量要求。
4. 项目配置管理 (Project Configuration Management)：管理项目的配置项，包括版本控制、变更控制和配置项的状态管理。
5. 项目度量与分析 (Project Measurement and Analysis)：收集和分析项目数据，评估项目绩效，并通过度量和分析驱动项目改进。
6. 项目风险管理 (Project Risk Management)：在项目各个阶段识别和评估风险，制定和实施风险应对措施，以降低项目风险。
7. 项目决策与问题解决 (Project Decision and Problem Solving)：制定和实施适当的决策和问题解决方法，以支持项目的成功实施。
8. 技术解决方案 (Technical Solution)：开发和维护具有高质量且满足需求的技术解决方案，包括架构设计、系统开发和集成。
论依照CMM3级要求的软件过程裁剪
论依照CMM3级要求的软件过程裁剪摘要：讨论了依照cmm3级要求对软件过程进行裁剪的方法。
裁剪后的软件过程包括：选择迭代增量型与瀑布模型结合软件周期模型、项目总体计划包含的内容与制定方法、过程数据的采集方式、scm、sqa活动方式等。
讨论了执行该软件过程时的效果与不足。
关键词：cmm3；软件过程裁剪；数字化资源库中图分类号：tp301文献标识码：a文章编号：1672-7800（2012）012-0024-020引言近期，笔者所在的软件工程实验室进行了“某数字化教学资源平台”的开发，该系统以学校生物技术及应用专业主干课程《食品检测技术》和生物制药技术、药物制剂技术专业主干课程《药物检测技术》为对象进行教学资源内容开发研究。
实验室要求该项目探索cmm3规范，遵守cmm项目管理体系要求。
cmm对这一级标准过程规定了5个方面的内容，如图1所示。
图1公司cmm3级标准软件过程结合cmm对项目的要求，制定了本项目的裁剪方法，即：首先根据需求产生分配给项目的软件需求，然后根据标准软件过程要求中的第三方面和第四方面确定软件的生命周期模型，接下来结合第二方面和第五方面为本项目过程裁剪，定义本项目的软件过程，编制本项目软件过程说明，如图2所示。
图2项目过程裁剪方法下面从软件生命周期的选择、项目组的组成、项目总体计划的内容与制定方法、过程数据的采集方式、scm与sqa活动方式等5个方面论述对本项目的过程裁剪。
1软件生命周期的选择系统的功能需求分为三部分，第一部分：专业开发部分，该部分综合考虑多专业问题，方便后续专业规模的扩充与修改；第二部分：课程开发部分，该部分主要是在教学资源开发规范下根据课程开发的流程开发各个功能模块；第三部分：资源开发部分，该部分难点是虚拟场景的开发，要求高，工作量大。
根据需求分析后项目可能遇到的变更情况，结合以往的开发经验，确定了迭代增量型与瀑布模型结合的软件开发周期模型。
软件开发周期共包含三次迭代过程，每次迭代过程中又遵循瀑布周期模型的原则，分别定义需求、设计、编码、测试里程碑，以文档作为驱动，每个里程碑都需要进行严格的正式评审。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
第五级 优化级
软件过程的量化反馈和新的思想和技 缺陷预防,过程变更管理和技术变
术
更
促进过程的不断改进
管理
第二部分 公司CMM3软件质量管理体系
公司CMM3软件项目管理体系
过程：30个
流程：24个
指南：44
CMM体系
模板：145个
检查表：111
生命周期：1个
公司CMM3软件项目管理体系结构
启动
需求
况
处理 问题 更新 报告
验证 并实 施问 题解 决方
案
用户 确认 解决 效果
关闭 问题
评审和同行评审过程
SQA工程师
SEPG
评审负责人
评审对象的检查表
分发评审材料
收集评审准备记录
产品评审
其他相关材料 达到评审准备
计划
就绪准则？ 是
否
项目数据分析汇总表
组织评审 分析评审结果
评审缺陷跟踪表
跟踪验证评审缺陷处理
是一个比较重要的分界线
CMM体系结构
➢ 能力成熟度模型的五个等级
▪ 过程的不断改进基于许多小的、进化的步骤，而不是革命性的创新； CMM提供了一个框架，将这些进化步骤组织成五个成熟度等级，它为 过程不断改进奠定了顺序渐近的基础；每一等级包含一组过程目标，当 目标满足时，能使软件过程的一个重要成分稳定。
设计
编码
测试
实施
软件项目启动过程
需求获取过程
需求分析过程
系统设计过程
软件项目方案 设计和立项投
标过程
代码设计过程 产品发布过程 系统测试过程
实施过程
项目产品工程过程（精简版）
维护
维护过程
SSPM PR TP SCM SQA SSM
SPTO SPP RM
项目管理过程（精简版）
评审与同行评审过程
项目培训计划过程
什么区别？
系统设计
实施经理
测试经理
需求管理员
开发经理
项目经理
编写《操作 手册》初稿
操作手册
编写《系统 测试用例》
系统测试用 例
软件需求规 格说明书
制定详细日程
组织系统 设计
项目日程
系统设计技 术流程
系统设计说 明书
编写《集成 测试用例》
集成测试用 例
是否需要同行评审
是 组织同行评审
否 组织评审
填写《需求 跟踪矩阵》
组织实施 需求变更
评估需求 变更影响
是否需部门
否
经理审批
是
往来文件 记录表
审批需求变更申请
是否需要进 行变更评估 是 否
需求变更 需求变更 评估表 评估报告
审批需求变 更评估报告
是否需中心总 监审批否是审批需求 变更评估
报告
需求管理员
需求跟踪 矩阵
变更需求 跟踪矩阵
需求变更处理流程
提交< 变更 申请>
确认用户需求说明 书
需求跟踪 矩阵
是否通 过否?
是
否
制定需 求跟踪 矩阵
是否需要 做数据转
换 是
数据转 换
关键活动
• 需求调研计划 • 需求调研发记录 • 用户需求说明书评审 • 需求跟踪矩阵
想一想
怎样做需求调研更有效? 用户需求说明书的评审工作怎样做才有效 ?
需求分析
需求分析员
开发经理
项目经理
否 用户培训
系统试运行
用户培训效果分 析报告
关键活动
• 现场服务任务书 • 数据转换 • 用户问题的响应及跟踪状态 • 项目总结及数据分析
维护过程
维护管理员/维护经理
接收问 题
用户问题
分析问题
报告
和用户确认《用户问题报告》
录入用户问题
工作安排
软件测试与 发布申请表
编译并提交测试申请
问题关闭
部门经理 任务接受者
需求管理员 测试经理 实施经理
项目日程
制定详细日程
选择开发 方法工具
用户需求说明书
分析用 户需求
是否需要同 行评审 是
否
软件需求规 格说明书
组织同行评审
需求分析工具
是否通
否
过?
是
软件项目计划
填写《需 求跟踪矩
阵》
组织评审
编写《确 认测试用
例》
确认测试 用例
编写《用 户手册》
概要
用户手册
需求分析技 术流程
想一想
• 《项目日程》的各个阶段任务由谁负责维护？ 哪种情况下需要变更？一般来说，项目日程大 概多久细化一次较为合适？
•
第四部分 重点指南和流程介绍
重点指南和流程介绍
重点指南 SPI_OPD_G02_过程裁剪指南.doc SPI_OPD_G04_软件项目组架构.doc SPI_PR01_G01_软件缺陷管理指南.doc SPI_SCM01_G01_配置管理指南.doc SPI_SPE_G01_软件项目产出物版本标识及版本号升级指南.doc SPI_SPE01_G01_ 标准工作产品集.doc SPI_SPE01_G12_业务建模示例.doc SPI_SPE01_G13_用例建模示例.doc SPI_SPE01_G31_需求规格说明书编写指南(OP).doc SPI_SPE01_G51_需求分析指南(OA).doc
CMM3标准体系 普及篇
及现场项目管理
2009/11 过程质量部
总目 录
CMM体系
公司质量管理体系基本结构
公司CMM3标准过程介绍 重点指南和流程介绍
第一部分 CMM基础知识
CMM是什么？
➢ 过程成熟度模型：汇集世界各地软件过程管理者
的经验和智慧
➢ 一组有关软件过程和实践的集合 ➢ CMM一共分为5级，1级最低，5级最高，3级
测试经理/实施经理
制定详细日程
组织评 审
分析测试 纪录
系统测试 纪录
是否通过？
Scarab缺
否 是
陷跟踪 编写《测试
报告》
测试工程师/ 实施工程师
项目日程 安装产品
执行测试
测试技术流 程
系统测试报告
开发经理
软件产品 系统测试用
例
启动产品发 布过程
关键活动
• 对内发布 • 缺陷管理工具 • 缺陷跟踪 • 测试报告 • 需求跟踪矩阵
部门经理
软件 项目 计划
制定项目日 程
项目估算
项目估算纪录
初次制定? 否
是
确定项目组织
会议纪要
中心总监
拟制《软件项目计划》
软件项 目计划
是 初次制定? 否
整合《软件项目计划》
分发《软件项目计划》
组织同行评 审
审
核
评审纪录 否
通过?
否
是
审
批
通过？
是
关键活动
• 过程裁剪申请 • 项目估算 • 相关计划制定 • 计划评审 • 计划变更
培训实施过程
公司年度培训计划过程
配置管理计划过程
配置管理实施过程
配置管理审计过程
SQA计划过程
SQA审计过程
分包商选择过程
分包商监控过程
项目监控过程
制定软件项目计划过程
制定项目日程过程
需求管理过程
第三部分 公司CMM3标准过程介绍
软件项目启动过程
销售人员
合同计划 销售行总/工程主 软件项目执行 管理中心 管/销售主管/总 部门经理
4.已管理级
5. 优化级
3.已定义级
1.初始级
2.可重复级
➢
进阶图： (有纪律-->标准一致-->可预测-->不断改进)
CMM的5个等级
初始级
过程是不正规的、不稳定的 输入
可重复级 项目管理制度化
输入
工程执行和项目
已定义级 执行相结合并已
输入
制度化
已管理级 产品和过程得到定量控制 输入
优化级
过程改进制度化
编码规范
填写《需求 跟踪矩阵》
制定详细日程 系统设计说明书
否
是
是否通过?
重点代码检查
重点代码检查表
程序员
设计《单元测试用例》
设计单元测试脚本
编写模块代码
需要代码
否
走读?
是
执行代码走读
单元测试用例 单元测试脚本
模块源代码
单元测试
否 是
是否通过
单元测试纪录
关键活动
• 编写编码规范 • 代码走查 • 单元测试 • 需求跟踪矩阵
用户需求 说明书
工作落实 是否测试
是 否
修改问题并向 用户提交系统
测试经理
用户需求说 明书(或修改
后加设计) 执行测试
关键活动
• 用户问题的收集 • 缺陷跟踪工具 • 现场服务任务书
项目问题处理流程
提交< 用户 问题 报告>
将问 题录 入缺 陷跟 踪系
统
评估 并受 理用 户问
题
向客 户反 馈受 理情
第三级 确定级
已经将软件管理和过程文档化,标准化, 同时综合成该组织的标准软件过程, 所有的软件开发都使用该标准软件过
程
组织过程定义,组织过程焦点,培训 大纲,软机集成管理,软件产品工程, 组织协调,专家审评
第四级 管理级
收集软件过程和产品质量的详细度量, 定量的软件过程管理和产品质量
对
管
过程和产品质量有定量的理解和控制 理
将变 更录 入缺 陷跟 踪系
统
评估 需求 变更 的影
响
向客 户反 馈受 理情