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 系统开发流程
软件实现开发过程可以分为三个子阶段： 详细设计 编码 单元测试 详细设计是在系统设计和概要设计的基础上进行函数或方法的详细功能 的设计；编码主要包括测试前的编码工作以及测试后对编码的修复工