CMMI SPP各阶段流程图
CMMI3级软件过程 第3章 立项管理
第3章立项管理立项管理（Project Initialization Management,PIM）的目的是：（1）采纳符合机构最大利益的立项建议被采纳，避免浪费机构的人力资源、资金、时间等。
立项管理是决策行为，其目标是“做正确的事情”（do right things）。
而立项之后的研发活动管理活动的目标是“正确的做事情”（do things right）。
只有“正确的决策”加上“正确地执行”才可能产生优秀的产品。
立项管理过程域是SPP模型的重要组成部分。
本规范阐述了立项管理过程域的三个主要规程：☆立项建议[SPP-PROC-PIM-PROPOSAL]。
☆立项审查[SPP-PROC-PIM-REVIEW]。
☆项目筹备[SPP-PROC-PIM-PREPARE]。
上述每个规程的“目标”、“角色与职责”、“启动准则”、“输入”、“主要步骤”、“输出”、“完成准则”和“度量”均已定义。
本规范适用于国内IT企业的软件研发项目。
建议用户根据自身的情况（如商业目标、研发实力等）适当地修改本规范，然后推广使用。
3.1 介绍立项管理流程分为三个阶段：“立项建议阶段”、“立项评审阶段”和“项目筹备阶段”，如图3-1所示。
1．立项建议阶段立项建议小组应反复地进行立项调查，产品构思和可行性分析。
在深思熟虑之后，立项建议小组撰写《立项建议书》，并申请立项。
要注意的是，由于立项调查工作和可行性分析通常比较费时费力，往往被人忽视。
而草率撰写的《立项建议书》会有比较多的主观臆断，这对项目是有危害的。
产品构思通常不可能快速完成，切不可闭门造车。
深入地进行立项调查与可行性分析不仅对产品构思有帮助，而且对立项审查也有帮助。
2．立项审判阶段机构领导组织一个评审委员会进行立项评审。
评审委员会根据《立项建议书》、《立项调查报告书》以及立项建议小组的答辩，投票决定是否同意立项（按少数服从多数的原则）。
评审委员会根据机构的实际情况（发展战略、资金、人力资源等），对《立项建议书》提出改进意见。
cmmi阶段表示法
cmmi阶段表示法
CMMI阶段表示法
CMMI阶段表示法是一种表示软件开发过程的标准，它用来说明软件开发从起初的概念到最终的完成的过程，从而帮助开发者更好地管理和计划开发项目。
CMMI阶段表示法由不同的阶段组成，每个阶段都有自己的定义，主要目的是为了帮助开发者增强软件产品的质量和可靠性。
CMMI阶段表示法主要分为五个阶段：
一、计划阶段：
计划阶段是开发项目的最初阶段，在这一阶段，需要制定软件开发的项目目标，分析需求和可行性，组建项目团队，安排项目时间，资源分配等。
二、分析阶段：
分析阶段的主要任务是核心系统的原型分析，也就是收集系统的建模，设计函数性和非功能性需求，还有识别不同的技术可能性及技术负荷的估算。
三、设计阶段：
设计阶段的主要任务是设计软件的架构，定义数据结构，以及根据用户需求设计软件，还要定义软件的界面和功能，以及性能测试、集成测试等。
四、实施阶段：
实施阶段的主要任务是开发真实的软件，包括编程、测试、安装、
部署等。
五、维护阶段：
维护阶段的主要任务是协助用户，对软件进行维护和管理，收集用户反馈，进行性能监控和改进，更新软件，修正发现的问题，以及执行安全策略等。
CMMI的22个过程域及其特定目标和实践
CMMI的22个过程域及其特定目标和实践CMMI共含有22个过程域：一、项目管理类：1、项目策划（PP）：SG1 完成参数估计SP1.1 估计项目的范围SP1.2估计项目属性SP1.3确定项目生存周期SP1.4 确定工作量和成本的估计值SG2 拟订项目计划SP2.1 编制预算和进度 SP2.2识别项目风险 SP2.3策划数据管理 SP2.4策划项目资源 SP2.5 策划必要的知识和技能 SP2.6策划共利益者的介入 SP2.7拟订项目计划SG3 获得对计划的承诺SP3.1 审查从属计划 SP3.2使工作与资源配备协调 SP3.3获得计划承诺2、项目监督和控制（PMC）：SG1 对照计划监督项目SP1.1 监督项目策划参数 SP1.2 监督承诺 SP1.3监督项目风险 SP1.4监督资料管理 SP1.5监督共利益者介入情况 SP1.6进行进展审查 SP1.7里程碑审查SG2 管理纠正措施，直到结束SP2.1 分析问题：收集并分析问题，确定处理这些问题所需的纠正措施SP2.2 采取纠正措施：对所识别的问题采取纠正措施3、集成项目管理（IPM）+IPPDSG1运用项目已定义过程SP1.1建立项目已定义过程 SP1.1运用组织过程财务策划项目活动 SP1.1建立项目工作环境综合计划 SP1.1运用综合计划管理项目 SP1.1充实组织过程财富SG2与相关的共利益者协调和合作SP2.1管理共利益者介入 SP2.2管理依存关系 SP2.3解决协调问题SG3IPPD应用（应用IPPD原则）SP3.1 建立项目的共同愿景 SP3.2 建立集成团队架构 SP3.3 分配需求至集成团队 SP3.4 建立集成团队 SP3.5确保跨团队间的合作4、供方协定管理（SAM）SG1 建立供方协定SP1.1分析由项目所决定的需求 SP1.2选择供方 SP1.3 建立供方协定SG2 满足供方协定SP2.1执行供方协定 SP2.2监督选定的供方过程 SP2.3评估选定的供方工作产品 SP2.4接受取得的产品 SP2.5移交产品5、风险管理（RSKM）SG1 准备风险管理SP1.1确定风险来源和类别 SP1.2定义风险参数 SP1.3建立风险管理战略SG2 识别和分析风险SP2.1识别风险 SP2.2对风险进行评价、分类和排列优先顺序SG3 缓解风险SP3.1拟订风险缓解方案 SP3.2实施风险缓解6、定量项目管理(QPM)SG1定量管理项目SP1.1建立项目目标 SP1.2组成已定义过程 SP1.3选择将予以管理的子过程 SP1.4管理项目性能SG2对子过程进行统计管理SP2.1选择度量值和分析技术 SP2.2运用统计方法，以掌握变化情况 SP2.3监督所选择的子过程的性能 SP2.4记录统计管理数据二、工程类1、需求管理（RM）2、需求开发（RD）3、技术解决（TS）SG1 选择产品构建解决方案SP1.1开发详细候选解决方案和选择准则 SP1.2开发操作概念和场景 SP1.3选择产品构件解决方案SG2 设计SP2.1运用有效的设计方法 SP2.2建立完备的技术数据包 SP2.3设计综合性接口 SP2.4进行制作、购买或复用分析SG3 实现产品设计SP3.1实现设计 SP3.2编制产品支持文档4、产品集成（PI）SG1 准备产品集成SP1.1建立产品集成战略 SP1.2建立产品集成环境 SP1.3规定详细的产品集成规程SG2 确保接口兼容性SP2.1审查接口描述的完备性 SP2.2管理接口SG3 组装产品构件和交付产品SP3.1确认集成用的产品构件已经准备就绪 SP3.2组装产品构件 SP3.3核查组装的产品构件 SP3.4打包和交付产品或产品构件5、验证（VER）6、确认（VAL）三、组织过程类：1、组织过程定义（OPD）SG1 建立组织过程资产SP1.1建立标准过程 SP1.2 建立生命周期模型描述 SP1.3建立裁剪准则及指南 SP1.4建立组织度量库 SP1.5建立组织过程资产库 SP1.6建立工作环境标准SG2 促成IPPD管理SP2.1建立授权机制 SP2.2建立集成团队规则与指南 SP2.3平衡团队与原隶属组织的责任2、组织过程聚焦（OPF）SG1 确定过程改进机会SP1.1确定组织的过程需求 SP1.2评估组织的过程 SP1.3识别组织的过程改进项目SG2 策划和实施过程改进活动SP2.1制定过程行动计划 SP2.2实施过程行动计划 SP2.3部署过程和相关的过程财富 SP2.4把过程相关的经验纳入本组织的过程财富3、组织培训（OT）SG1 确定培训需求并且使培训现成可用SP1.1 确定战略培训需求 SP1.2确定有哪些培训需求由组织负责满足 SP1.3 建立组织培训战术计划 SP1.4建立培训能力SG2 提供必要的培训SP2.1交付培训 SP2.2建立培训记录 SP2.3评价培训效果4、组织过程性能（OPP）SG1 建立性能基线和模型SP1.1 选择过程 SP1.2建立过程性能度量值 SP1.3建立质量和过程性能目标 SP1.4建立过程性能基线 SP1.5建立过程性能模型5、组织革新与部署（OID）SG1 选择改进项目SP1.1 收集和分析改进建议 SP1.2 识别革新 SP1.3 试行改进 SP1.4 选择改进建议，用于部署SG2 部署改进SP2.1策划部署 SP2.2管理部署 SP2.3度量改进效果四、支持类1、过程和产品质量保证（PPQA）SG1 客观评价过程和工作产品SP1.1客观评价过程 SP1.2客观评价工作产品和服务SG2 客观提供情况SP2.1通报不符合问题，并且确保解决它们 SP2.2建立记录2、配置管理（CM）SG1 建立基线SP1.1识别配置项 SP1.2建立配置管理系统 SP1.3建立或放行基线SG2 跟踪并控制变更SP2.1跟踪变更 SP2.2控制变更SG3 建立完整性SP3.1建立配置管理记录 SP3.2进行配置审计3、测量和分析（MA）SG1 协调测量和分析活动SP1.1 建立测量目标 SP1.2详细说明度量值 SP1.3说明数据收集和存储规程 SP1.4规定分析规程SG2 提供度量结果SP2.1收集度量数据 SP2.2分析度量数据 SP2.3存储数据和结果 SP2.4通报分析结果4、决策分析和决定（DAR）SG1 评价候选方案SP1.1拟订并运用决策分析的指导原则 SP1.2选择评价技术 SP1.3拟订评价准则 SP1.4确定推荐的侯选方案 SP1.5评价候选方案 SP1.6选择解决方案5、原因分析和决定（CAR）SG1 确定缺陷的原因SP1.1选择缺陷数据，用于分析、选择缺陷和其他问题，以供分析使用 SP1.2分析原因SG2 处理缺陷原因SP2.1实施措施建议 SP2.2评价变更的效果 SP2.3记录数据。
CMMI3级18个过程域
CMMI3级过程域一共有18个PA，分别是：过程管理1、OPD：（Organizational Process Definition）组织级过程定义。
建立和维护有用的组织过程资产。
2、OPF：（Organizational Process Focus）组织级过程焦点。
在理解现有过程强项和弱项的基础上计划和实施组织过程改善。
3、OT：（Organizational Training）组织培训管理。
增加开发人员的技能和知识，使他们能有效地执行他们的任务。
项目管理：4、PP：（Project Plan）项目计划。
保证在正确的时间有正确的资源可用。
为每个人员分配任务。
协调人员。
根据实际情况，调整项目。
5、PMC：（Project Monitoring and Control）项目监督与控制。
通过项目的跟踪与监控活动，及时反映项目的进度、费用、风险、规模、关键计算机资源及工作量等情况，通过对跟踪结果的分析，依据跟踪与监控策略采取有效的行动，使项目组能在既定的时间、费用、质量要求等情况下完成项目。
6、SAM：（Supplier Agreement Management）供应商协议管理。
旨在对以正式协定的形式从项目之外的供方采办的产品和服务实施管理。
7、IPM：（Integrated Project Management）集成项目管理。
根据从组织标准过程剪裁而来的集成的、定义的过程对项目和利益相关者的介入进行管理。
8、RSKM：（Risk Management）风险管理。
识别潜在的问题，以便策划应对风险的活动和必要时在整个项目生存周期中实施这些活动，缓解不利的影响，实现目标。
工程管理：9、REQM：（Requirements Management）需求管理。
需求管理的目的是在客户和软件项目之间就需要满足的需求建立和维护一致的约定。
10、RD：（Requirement Development）需求开发。
需求开发的目的在于定义系统的边界和功能、非功能需求，以便涉众（客户、最终用户）和项目组对所开发的内容达成一致。
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、测试负责人与临时项目组确定项目关键参数。
CMMI v1.3 流程图
过程与产品质量保证 (PPQA)
SG1 客观评估过程和工作产品 (Objectively evaluate processes and work products)
SG2 提供客观的洞察力 (Provide objective insight)
SP1.1 Objectively evaluate processes 客观评估过程 SP1.2 Objectively evaluate work products 客观评估工作产品 SP2.1 Communicate and resolve noncompliance issues 沟通并解决不符合项 SP2.2 Establish records 建立记录
CMMI
支 持 类 过 程 域
配置管理 (CM)
SG1 建立基线 (Establish baseline) SG2 跟踪和控制变更 (Track and control changes)
SG3 建立完整性 (Establish Integrity)
SP1.1 Identify configuration items 识别配置项 SP1.2 Establish a configuration management system 建立配置管理系统 SP1.3 Create or release baselines 建立或发布基线 SP2.1 Track change requests 跟踪变更请求 SP2.2 Control configuration items 控制配置项 SP3.1 Establish configuration management records 建立配置管理记录 SP3.2 Perform configuration audit 执行配置审计
cmmispp各阶段流程图
CMMI SPP各阶段流程图:
•立项管理流程
•结项管理流程
•项目规划流程
4
•项目监控流程
•风险管理流程
•需求管理流程
*需求开发流程
*技术预研流程
工作咸果介鉛
技术评审
*系统设计流程
•实现与测试流程
複块微陷管理与改錯
代码审查
单元测试
软
件
系
蜒
«系统测试流程
甫批审批迭代
制
定
测
试
计
划
设
计
测
试
用
例
执
行
系
统
测
试
缺
陷
筲
理
与
改
错
• Beta测试流程
•客户验收流程
*技术评审流程
•配置管理流程
p------------------------------
3-
—
all
™
—
-
配
置
审
计
------------------------------
*质量保证流程
*外包与采购管理流程
•培训管理流程
•服务与维护流程
客户服务堆备—►接收客户要求—►响应客户要求
产品维护准备一►接收并吏爛錐护要或一►执行维护工作。
CMMI体系知识培训教材PPT-26张课件
修改缺陷 状态
(责任人)
问题记录 跟踪表 [草稿]
批准 (评审主
席)
问题记录 跟踪表 [已批准]
审批活动图
评审成员
提交发现的待定问题
评审主席
否 确认是否为问题
是
状态：待修复
问
题
PR： 项 目 经 理
否 是否要修改
记 录
TR、 MR： 评 审 主 席
状态：遗留
与
跟
是
状态：待修复
踪
流
责任人
修改问题
程
图
无言。缘来尽量要惜，缘尽就放。人生本来就空，对人家笑笑，对自己笑笑，笑着看天下，看日出日落，花谢花开，岂不自在，哪里来的尘埃!
•
5、心情就像衣服，脏了就拿去洗洗，晒晒，阳光自然就会蔓延开来。阳光那么好，何必自寻烦恼，过好每一个当下，一万个美丽的未来抵不过一个温暖的现在。
•
6、无论你正遭遇着什么，你都要从落魄中站起来重振旗鼓，要继续保持热忱，要继续保持微笑，就像从未受伤过一样。
•
9、与其埋怨世界，不如改变自己。管好自己的心，做好自己的事，比什么都强。人生无完美，曲折亦风景。别把失去看得过重，放弃是另一种拥有;不要经常艳羡他人，
人做到了，心悟到了，相信属于你的风景就在下一个拐弯处。
•
10、有些事想开了，你就会明白，在世上，你就是你，你痛痛你自己，你累累你自己，就算有人同情你，那又怎样，最后收拾残局的还是要靠你自己。
SCCB评审变更请求申请 （SCCB会议纪要）
需求角色更改需求文档 修改后的需求文档被批准纳入基线
2.7 系统设计流程
2.8 系统开发流程
软件实现开发过程可以分为三个子阶段： 详细设计 编码 单元测试 详细设计是在系统设计和概要设计的基础上进行函数或方法的详细功能 的设计；编码主要包括测试前的编码工作以及测试后对编码的修复工
CMMISPP各阶段流程图
CMMISPP● 立项管理流程各阶段流程图● 结项管理流程机构领导指示结项申请机构领导审批结项评审资产检查综合评估经 验 总 结● 项目规划流程项目计划变更控制项目估计制定项目 计划审批项目 计划按计划执行 研发与管理工作● 项目监控流程产品构思立项调查可行性分析立项建议阶段项目筹备同意立项评审阶段 项目筹备阶段立项申请否决评审●风险管理流程风险识别风险跟踪风险减缓●需求管理流程需求开发需求调查需求分析需求定义●需求开发流程风险分析需求工程需求管理需求确认需求跟踪需求变更控制周期性地开展偏差控制项目进展总结项目计划跟踪需求开发过程域用户需求调查需求分析产品需求定义输出用户需求说明书产品需求规格说明书输出需求管理过程域需求确认需求跟踪需求变更控制●技术预研流程制定计划开展技术预研撰写预研报告工作成果介绍技术评审.●系统设计流程高层设计阶段需求开发体系结构设计详细设讨阶段用户界面设计数据库设计实现与测试模块设计●实现与测试流程● 系统测试流程● Beta 测试流程● 客户验收流程● 技术评审流程正规技术评审制定技术评审计划非正规技术评审● 配置管理流程验收准备 成果审查与验收测试 问题处理 变付与签字联系Beta 客户 签约与发行 信息反馈 问 题 处 理缺陷管理与改错代 迭执行系统测试设计测试用例制定测试计划审批审 批模块 缺陷管理与改错准备编程代码审查单元测试软件系统集成测试制定配置管理计划配置库管理版本控制 变更控制● 质量保证流程制定质量保证计划周期性地开展过程与产品质量检查 问题跟踪与质量改进技术评审测 试----------表示质量保证与技术评审、测试有机结合● 外包与采购管理流程● 培训管理流程采购管理流程选择供应商自主研发Buy选择 承包商外包管理流程过程监控签订合同签订合同外包开发验收验收采购决 策Mlakeor配置审计确定机构培训需求确定项目培训需求制定机构培训计划执行培训培训效果评估制定项目培训计划执行培训培训效果评估服务与保护流程客户服务准备接收客户要求响应客户要求产品维护准备接收并判断维护要求执行维护工作。
CMMI流程中文整理
CMMI 2级过程域1：需求管理（REQM） SP 1.1 获得对需求的理解 SP 1.2 获得对需求的承诺 SG1 SP 1.3 管理需求的变更 管理需求 SP 1.4 维护需求的双向可追溯性 SP 1.5 识别项目工作与需求的不一致之处 CMMI 2级过程域2：项目规划（PP） SP 1.1 估算项目的范围 SG1 SP 1.2 估算项目属性 项目估算 SP 1.3 定义项目生存周期阶段 SP 1.4 估算工作量和成本 SP 2.1 编制预算和进度 SP 2.2 识别项目风险 SP 2.3 项目数据的管理计划 SG2 SP 2.4 规划项目资源 制定项目计划 SP 2.5 知识和技能的计划 SP 2.6 “项目干系人”的介入计划 SP 2.7 制定项目计划 SP 3.1 审查从属计划 SG3 SP 3.2 协调工作与资源配置 获得对计划的承诺 SP 3.3 获得计划承诺 CMMI 2级过程域3：项目监控（PMC） SP 1.1 监督项目计划的参数 SP 1.2 监督承诺 SP 1.3 监督项目风险 SG1 SP 1.4 监督数据管理 依据计划监督项目 SP 1.5 监督干系人的介入 SP 1.6 项目进展审查 SP 1.7 里程碑审查 SP 2.1 分析问题 SG2 SP 2.2 采取纠正措施 管理纠正措施 SP 2.3 管理纠正措施 CMMI 2级过程域4： 供应商协议管理（SAM） SP 1.1 确定采购方式 SG1 SP 1.2 选择供应商 签订供应商协议 SP 1.3 签定供应商协议 SP 2.1 执行供应商协议 SP 2.2 监督选定的供应过程 SG2 SP 2.3 评价供应商产品 满足供应商协议 SP 2.4 验收采购的产品 SP 2.5 移交产品 CMMI 2级过程域5： 度量分析（MA） SP 1.1 确定度量目标 SG1 SP 1.2 细化度量 协调度量和分析活动 SP 1.3 确定数据收集和存储规程 SP 1.4 确定分析规程 SP 2.1 收集度量数据 SG2 SP 2.2 分析度量数据 提供度量结果 SP 2.3 存储数据和度量结果 SP 2.4 通报度量结果
CMMISPP各阶段的流程图
CMMI SPP各阶段流程图：•立项管理流程•结项管理流程•项目规划流程•项目监控流程•风险管理流程•需求管理流程•需求开发流程•技术预研流程•系统设计流程•实现与测试流程•系统测试流程•Beta测试流程•客户验收流程•技术评审流程•配置管理流程•质量保证流程•外包与采购管理流程•培训管理流程•服务与维护流程CRM系统培训讲座提纲：•CRM产生的背景•CRM的概念•CRM的组成部分•CRM的作用•CRM的主要功能模块•CRM的现状和前景•CRM的战略•呼叫中心与CRM•如何实施CRM•CRM 产生背景1990年前后，许多美国企业为了满足日益竞争的市场需要，开始开发销售力量自动化系统(SFA)，随后又着力发展客户服务系统(CSS)。
1996年后一些公司开始把SFA和CSS两个系统合并起来，再加上营销策划(Marketing)、现场服务(Field service)，在此基础上再集成CTI（计算机电话集成技术）形成集销售(Sales)和服务(Service)于一体的呼叫中心(CallCenter)。
这样就逐步形成了我们今天熟知的CRM。
特别是Gartner Group正式提出CRM（Customer Relationship Management）的概念，也加速了CRM的产生和发展。
狭义来讲，CRM客户关系管理的技术载体就是Call Center,1998年以后随着电子商务的兴起，CRM向eBRM/eCRM方向发展。
二、CRM的概念什么是客户关系管理（CRM）？简单定义，CRM是一个获取、保持和增加可获利客户的过程。
CRM是首先是一套先进的管理思想及技术手段，它通过将人力资源、业务流程与专业技术进行有效的整合，最终为企业涉及到客户或消费者的各个领域提供了完美的集成，使得企业可以更低成本、更高效率地满足客户的需求，并与客户建立起基于学习型关系基础上的一对一营销模式，从而让企业可以最大程度的提高客户满意度及忠诚度，挽回失去的客户，保留现有的客户，不断发展新的客户，发掘并牢牢地把握住能给企业带来最大价值的客户群。
CMMI基本流程(共16张PPT)优秀
第三页，共16页。
项目策划（PP） 项目监督与控制（PMC） 需求管理（RM） 供应商协议管理（SAM） 度量（MA） 配置管理（CM）
产品与过程质量保证（PPQA）
需求开发（RD） 技术解决(TS) 产品集成(PI) 验证(Ver)
确认(Val)
组织过程聚焦(OPF)
在CMMI3中开展项目的流程怎样？
第五页，共16页。
立项的3种类型
产品研发：公司内部提起的，无固定客户的项目
招投标： 经过投标，中标的项目 合同： 基于合同的，主要是由客户找你，让你为他们做项目
产品研发的立项过程
申请人提出立项申请 立项申请书
组织进行立项申请
N
评审
Y
立项调研 （调查市场同类产品和客户等）
输出：
《需求开发计划》 《需求征求稿》 《需求记录表》 《产品需求规格说明书》 《软件需求规格说明书》 《需求模块功能矩阵》 评审准备表、评审报告 阶段报告
需求ห้องสมุดไป่ตู้
第九页，共16页。
该阶段的目的是什么？
为项目的研发和管理工作制定合理的行动纲领（即《项目计划》
以及相关辅助计划），以便所有相关人员按照该计划有条不紊地开展 工作
及相关文档
2.内部验收为在组织内部作的验收，外部验收是与客户作的验收
验收阶段结束进入结项阶段
验收
第十四页，共16页。
结项中要产生一些文档：项目总结、个人总结、项目统计
结项
第十五页，共16页。
监督控制
度量分析
风险管理与跟踪
CM管理
QA管理
项目的管理
第十六页，共16页。
如何进行项目的策划(给项目制定各个计划)？
CMMI3级精简并行过程综述
CMMI3级精简并⾏过程综述“精简并⾏过程”（Simplified Parallel Process，SPP）是基于CMMI以及软件⼯程和项⽬管理知识⽽创作的⼀种“软件过程改进⽅法和规范”，它由众多的过程规范和⽂档模板组成。
SPP主要⽤于指导国内IT企业持续地改进其软件过程能⼒。
此处“精简并⾏”的含义是：（1）对CMMI 3级以内各过程域的内容和要求作了“精简”处理。
（2）在产品⽣命周期之内，项⽬管理过程、项⽬研发过程和机构⽀撑过程“并⾏”开展。
SPP模型SPP模型把产品⽣命周期划分为6个阶段，分别为：产品概念阶段，记为PH0。
产品定义阶段，记为PH1。
产品开发阶段，记为PH2。
产品测试阶段，记为PH3。
⽤户验收阶段，记为PH4。
产品维护阶段，记为PH5。
在SPP模型中，软件项⽬的过程有三⼤类：项⽬管理过程、项⽬研发过程和机构⽀持过程。
上述三类过程可以细分为19个主要过程域，分布在PH0到PH5的各个阶段。
项⽬管理过程包含6个过程域，分别为：² ⽴项管理² 结项管理² 项⽬规划² 项⽬监控² 风险管理² 需求管理项⽬研发过程包含8个过程域，分别为：² 需求开发² 技术预研² 系统设计² 实现与测试² 系统测试² Beta测试² 客户验收² 技术评审机构⽀撑过程包含5个过程域，分别为：² 配置管理² 质量保证² 培训管理² 外包与采购管理² 服务与维护SPP模型如图2-1所⽰。
SPP模型的主要特征和优点有：⼀、直观的过程模型SPP模型将项⽬管理、项⽬研发、机构⽀撑所包含的⼯作划分为相对独⽴的三类过程，各个过程域之间的关系直观明了。
这样，机构领导、项⽬经理、开发⼈员、测试⼈员、质量保证⼈员、外包与采购管理⼈员等⼈根据SPP模型，很容易知道⾃⼰“应该在什么时候、按照什么规范做什么事情”。
CMMI过程域(全)
项目策划——PP
特定目标（SG1）： 建立和维护项目计划参数的估计。 特定实践：
SP1.1 建立顶层的工作分解结构（WBS）来估计项目的范围。 SP1.2 建立和维护对工作产品和任务的属性的估计并且将其
文档化。 SP1.3 定义项目的生命周期阶段，并据此来限定计划的工作
量范围。 SP1.4 根据估计原理，对项目的工作产品和任务所需的工作
公共特性和共性实践
公共特性和共性实践
受管理级——CMMI2
概述
CMMI二级，受管理级。一个组织如果到达 第2成熟度等级，就意味着该软件组织已经 确保有关的过程在项目一级得到策划、形成 文件、执行、受到监督和控制，并且能实现 过程目标。在这个成熟度等级，软件项目是 在受控状态下运行。
CMM2 与CMMI2级对比
需求管理—实施建议
培训人员 管理配置项： 置于配置管理之下的工作产品主要有：需求、需求溯源性度量
项目 使共利益者适时介入 监督和控制该过程 度量项目有：需求变化性（需求变更的百分比） 评价遵循情况 高层管理者审查状态
项目策划——PP
目的：建立并维护规定项目各项活动的计划。 相关的过程域：RD,RM,TS
目监督和控制—特殊实践分析
SP1.2 对照项目计划中标识出的承诺进行监督。 ● 定期审查内部和外部的承诺 ● 识别那些没有得到满足的承诺或那些很可能得不到满足得承诺 ● 把承诺审查的结果形成文件 SP1.3 对照项目计划中标识出的风险进行监督。 ● 定期审查有关项目情况和环境的风险的文件 ● 根据新的情况对有关风险的文件进行修改 ● 把风险状态通知相关共利益者
需求管理——REQM
目的：维护需求并且确保能把对需求的更改反映到项目计划、 活动和工作产品中。
CMMI流程图
项目经理根据实际情况，识别风险，进行风险评 价，制定缓解和应急措施，跟踪风险，同步更新 《风险计划和跟踪表》
立项 项目经理完成《立项报告》 （是否提供《可行性分析》看具体项目要求） 项目经理发起管理评审 评审后项目经理输出《管理评审记录》 （可能进行多次评审） CMO建立配置库 项目经理归档报告 CMO完成《配置状态报告》 PPQA完成《生命周期阶段检查》 MA完成《度量数据检查表》
全周期项目组全员准确填写工时表
全周期内，PPQA通报不符合问题，并跟踪 项目经理安排解决问题；记录评审情况
全周期内，CMO记录《变更一览表》，记录发布 情况
编码集成 *项目经理编写《集成计划》 项目经理安排组员开始编码 每周进行至少一次代码走查；重要功能模块进行重点走查 项目经理安排单元测试，输出《单元测试报告》 *项目经理安排模块测试，输出《模块测试报告》 （以上两个测试可以根据项目组情况合并为一个） 项目经理根据计划确认集成条件，填写《产品集成准备检查表》 执行集成 项目经理安排集成测试，输出《集成测试报告》 编写《用户操作手册》 项目经理组织评审《手册》 PPQA完成《技术评审活动检查单》 项目经理完成《里程碑报告》 项目经理发起里程碑会议 会议结束后归档《里程碑评审报告》 CMO完成《配置审计检查》《配置状态报告》 PPQA完成《生命周期阶段检查》《里程碑评审活动检查单》 MA完成《度量数据检查表》
任一阶段，涉及决策的行为，实施DAR
计划 项目经理完成《团队章程》《过程裁剪》《WBS》《风险计划》《总体计划》《项目估算》《MA计划》 CMO完成《CM计划》 PPQA完成《PPQA计划》 项目经理发起技术评审，会后项目经理输出《评审报告》（可能进行多次评审） PPQA完成《技术评审活动检查单》 相关人员根据评审结果修改相关文档 修改完成后发送结果给相关人员确认 CMO完成《配置状态报告》 PPQA完成《生命周期阶段检查》 MA完成《度量数据检查表》 在评审通过后or之后的阶段，当计划变动影响到了里程碑节点时，提交《计划变更申请》来进行变更 PPQA完成《变更活动检查单》
CMMI项目文档流程图
项目立项阶段销售部门提交《项目交接报告》与《软件开发合同》副本，提交给项目管理中心，申请内部立项。
项目中心经过和开发部门协调后，确定项目承接部门和承接人，成立项目组。
承接人和客户经理沟通，了解合同和客户情况，整理《项目立项报告》。
承接部门召集包括客户经理、部门经理、项目管理中心、项目组成员，公司总工召开项目立项会议，主要由客户经理介绍客户和项目情况，承接人陈述项目组情况，项目进度和项目保证，项目初步风险评估和估算等。
并且简要说明调研计划情况，其它人员就项目的技术、风险、进度等进行初步交流和确认，形成项目立项会议纪要。
需求开发阶段项目经理制定《项目调研计划》，提交部门经理审核，再提交给客户确认。
得到确认后，项目组进入企业，按照《项目调研计划》展开项目调研，填写《项目调研表》，项目调研结束前整理出《用户需求说明书》，交客户确认，经过双方修正后，客户签字确认的《用户需求说明书》带回公司。
项目经理委任一名设计师，并同参与调研的实施人员，对《用户需求说明书》进行理解，开始撰写《产品需求说明书》。
项目经理组织同行评审，要求参加人员有参与调研人员、项目经理、文档撰写的设计师、架构和详细设计师、编码人员、测试人员、QA人员。
对评审不合格的地方，确定责任人和计划消除时间。
再发送给各位评审人进行确认，必要时再进行评审。
由设计师撰写《系统测试用例》提交同行评审。
将所有基线文档进行基线管理。
项目计划阶段项目经理在SQA指导下结合财富库内容，剪裁确定《项目定义的过程清单》。
项目经理编写《项目任务WBS清单》，明确需要完成的任务和工作。
结合《产品需求说明书》，由项目经理进行编写《项目估算表》，对项目规模、费用、资源进行估算。
项目经理识别出项目风险，编写整理《项目风险列表》项目经理制定《项目进度表》，规定具体任务和里程碑，表明任务的依赖关系。
项目经理配合配置管理员编排《配置管理计划》。
项目经理配合QA人员编排《质量保证计划》。