成熟度级别.pptVIP

1.1 CMM软件能力成熟度模型由来 软件危机的实质：缺乏管理软件过程的能力 我们需要 有效软件过程 有效的软件过程改进途径 软件过程有效性的评价 CMM指导机构控制开发＆维护软件的过程，选择过程改进策略，强调重要实施活动。 软件过程评估(software process assessment) + 软件能力评价(software ability evaluation) = CMM 1.1 CMM由来 CMM的特点 基于实际实践，反映实践情况 满足软件过程改进＆软件过程评估人员的需求 公开可使用的文档 1.2 CMM的基本用途 软件过程评估 分析软件组织当前软件过程的状态，找出其强处和弱处. 软件过程改进 根据评估结果，确定当前软件过程的弱点，按照SW-CMM能力等级的顺序，制定软件过程改进的策略。 软件能力评价 软件采购单位为了减少软件采购的风险（包括资金、周期、特别是产品质量方面的风险），需要在招标时对投标者的软件过程能力进行评价。 1.3 关键概念 CMM强调机构一致地、可预测地生产高质量软件产品的能力。 过程（Process）：为了达到给定目标所实施的一序列步骤。〔人员利用规程、方法、工具和设备将输入转化成产品〕 过程说明和过程 软件过程（Software Process）: 软件开发人员开发和维护软件及其相关产品（如项目计划、设计文档、代码等等）的一套行为、方法、实践及变换过程。 软件产品的质量取决于软件过程质量 软件过程能力（ Software Process Capability ）：遵循某软件过程可能达到的预期结果的范围。 1.3 关键概念 软件过程效能（Software Process Performance）: 遵循一个软件过程所达到的实际结果。 软件过程成熟度（Software Process Maturity）: 针对具体的软件过程进行明确定义、管理、测量、控制以及有效的程度。 软件过程成熟度要求机构改进软件过程 基础设施（ Infrastructure）：机构或系统的基本框架，包括正在执行的软件过程的机构机构、策略、标准、培训、设备和工具。 机构文化(corporate culture) ：做事情的方式。 制度化（ Institutionalization ）：建立起支持方法、实践和规程的基础设施和企业文化。 1.4 成熟机构与不成熟机构的特征 不成熟组织的特征 软件过程一般由实践者及其管理者在项目过程中临时拼凑而成。 即使已规定了软件过程，也不能严格地遵守和贯彻它。 不成熟的软件组织是反应式的，通常经理们集中精力于解决即时危机（称为救火）。 由于制定进度和预算不是基于现实的估计，因而超出进度和预算已成惯例。 当硬性规定时限时，为满足进度要求，常在产品功能和质量上作出让步。 不存在判断产品质量或者解决产品或过程问题的客观基础。因此，产品质量难以预测。 当项目进度退后时，常缩短或取消像评审和测试这些旨在提高质量的活动。 1.4 成熟机构与不成熟机构的特征 成熟软件组织的特征 具有全组织范围的管理软件开发和维护过程的能力。 软件过程被正确无误地通知到现有职员和新雇员，工作活动均按照己规划的过程进行。 所有的工作规范是适用的，而得到严格执行。 需要时就对已定义的过程进行更新，并且通过可控的先导性试验和（或）费效分析使其得到改进。 在已定义的过程中，遍及所有项目和在整个组织中，所有的岗位及其职责都是清楚的。 1.4 成熟机构与不成熟机构的特征 经理监控产品的质量和顾客的满意程度。 在判断产品质量和分析产品及过程问题方面有客观的、定量的基础。 进度和预算是基于以前的性能数据，因而是现实的；通常都能达到产品的成本、进度、功能和质量的预期结果。 所有的参加者能一致地遵循一个有纪律的过程，并了解这样做的价值，且存在支持该过程的必要基础设施 1.5 CMM、TQM和ISO9000 与ISO标准系列相比，CMM更为软件产业所看好 原因是它专门针对软件工程控制而设置的，不仅进行软件企业工程能力的评估，更致力于软件开发过程的管理，强调“对软件开发过程进行持续改进”，引导软件开发过程走向成熟。 相同点 CMM和ISO 9001标准系列都着眼于质量和过程管理，二者都为了解决同样的问题。 不同点 CMM是动态的、开放的和持续改进的，强调没有最好只有更好，强调不断改进，强调人在软件开发方面的思想认识和主动性，适用于软件过程的改进。 CMM模型只关注软件，它能解决“软件危机” 这个世界性的问题， ISO 9001是静态的质量控制，只要达到几个关键指标就能完成质量控制，更适用于硬件制造生产线的质量控制。 ISO 9001的适应范围更广，包括硬件、软件和服务。 2.1 成熟度级别 成