软件能力成熟度模型SW-CMM马梅.pptVIP

软件能力成熟度模型SW CMM马梅2002 4 29 内容 SW CMM是什么 SW CMM的由来和发展SW CMM的管理思想与结构SW CMM评估的国内外现状ISO9001与SW CMM异同软件业对SW CMM的认识SW CMM市场存在的问题我们怎么办 什么是SW CMM SW CMM称为软件能力成熟度模型 是CapabilityMaturityModelforSoftware的缩写形式 目前国际上最流行最实用的软件生产过程标准和软件企业成熟度等级认证标准 用于评价软件承包能力并帮助其改善软件质量的方法 美国卡内基 梅隆大学的软件工程研究所 SEI SoftwareEngineeringInstitute 在1987年研制成功 卡内基 梅隆大学的软件工程研究所是美国国防部的软件开发基地之一 CMM就是受美国国防部委托而研制的 SW CMM是什么 续一 SEI给CMM下的定义 对于软件组织在定义 实现 度量 控制和改善其软件过程的各个发展阶段的描述 这个模型便于确定软件组织的现有过程能力和查找出软件质量及过程改进方面的最关键的问题 从而为选择过程改进战略提供指南 如今的行情是 一家软件企业如果不能通过相应等级的CMM评估 他的产品就少了一张进入国际市场的通行证 SW CMM的由来与发展 TheCapabilityMaturityModelforSoftware Version1 1 Mr MarcC Paulk Themajorproblemsinsoftwaredevelopmentaremanagerial nottechnical SW CMM的由来与发展 续一 20世纪60年代中期 大型软件系统生产中爆发的软件危机 使程序中大量的错误难以消除 软件生产的进度无法预测 开发应用费用失去控制 程序员人数增长需求很难满足要求 人们将工程的概念 原理 技术和方法引入了软件系统开发 在一定程度上解决了软件生产过程中遇到的问题 软件工程成为软件产业的重要分支 直至80年代还是没有提出一套管理软件开发的通用原则 软件管理不善的问题依旧在大范围内存在 SW CMM的由来与发展 续二 70年代中期美国国防部曾立题专门研究软件项目做不好的原因 发现70 的项目是因为管理不善而引起 而并不是因为技术实力不够 90年代中期 软件工程管理不善的问题仍然存在 据美国软件工程实施现状的调查 大约只有10 的项目能够在预定的费用和进度下交付 1995年 美国共取消了810亿美元的软件项目 其中31 的项目未做完就取消了 53 的软件项目进度通常要延长50 的时间 通常只有9 的软件项目能够及时交付并且费用也不超支 结论 管理是影响软件研发项目全局的因素 而技术只影响局部 SW CMM的由来与发展 续三 80年代中期 美国联邦政府提出对软件承包商的软件开发能力进行评估的要求 在Mitre公司的帮助下 1987年9月 美国卡内基 梅隆大学软件工程研究所发布了软件过程成熟度框架 并提供了软件过程评估和软件能力评价两种评估方法和软件成熟度提问单 4年之后 SEI将软件过程成熟度框架进化为软件能力成熟度模型 CapabilityMaturityModelForSoftware 简称SW CMM 1991年8月 SEI发布了最早的SW CMMv1 0 经过两年的试用 1993年SEI正式发布了SW CMMv1 1 这是目前使用最为广泛的版本 SW CMM的由来与发展 续四 从1995年 CMM又进入了另一个修改的高峰期 美国政府和软件业界大力支持和积极参与下 SEI先后发表了CMM2 0版的A版 B版和C版草案 1997年 CMM2 0C版草案停止推进 SEI宣布 CMM1 1版和CMM2 0C版草案都有效 并且SEI及其授权的机构为这两种版本提供相应的服务 自CMM1 1发布起 SEI相继研制并发布了 人员能力成熟度模型 P CMM 软件访问能力成熟度模型 SA CMM 和 系统工程能力成熟度模型 SE CMM 及其支持文件 经过试运行 产生了把SM CMM P CMM SA CMM和SE CMM合并在一起的想法 于是开始了名为 综合能力成熟度模型 英文缩写为CMMI 的一个综合性模型投入研制 SW CMM的由来与发展 续五 SEI的CMM为软件工程管理开辟了一条新的途经 其的本质还是软件工程的一个部分 迄今为止 CMM虽然只是美国卡内基 梅隆大学软件工程研究所 SEI 发表的一份技术报告 既不是政府也不是行业协会批准的标准 但它在美国和国际上已成为事实上的软件行业标准 鉴于CMM的巨大应用前景 SEI已在美国注册了CMM CapabilityMaturityModel和CapabilityMaturityModeling的专利和商标 围绕以CMM为基础的软件过程评估和软件能力评价 建立了从审核员培训到提供评估和评价的一整套服务体系 SW CMM的管理思想与结构 SW CMM为软件企业的过程能力提供了一个阶梯式的进化框架 它是基于过去所有软件工程成果的过程改善的框架 吸取了以往软件工程的经验教训 指明了一个成熟的软件组织在软件开发方面需要管理的主要工作 这些工作之间的关系以及以怎样的先后次序 一步一步的做好这些工作使软件组织走向成熟 SW CMM分为五个等级初始级可重复级已定义级已管理级优化级 SW CMM的管理思想与结构 续一 1 初始级 混沌的过程不具备稳定的环境用于软件开发和维护 缺乏健全的管理惯例 其软件过程能力无法预计 软件过程是一片混沌 软件过程总是随着软件开发工作的推进而处于变更和调整之中 现实中有许多这样的软件组织 这种情况被CMM定义为初级 第1级 能力成熟度 SW CMM的管理思想与结构 续二 2 可重复级 定义管理的基本过程软件开发的首要问题不是技术问题而是管理问题 因此 可重复级的焦点集中在软件管理过程上 一个可管理的过程则是一个可重复级的过程 一个可重级的过程则能逐渐进化和成熟 该级管理过程包括了需求管理 项目管理 质量管理 配置管理和子合同管理五个方面 项目管理分为计划过程和跟踪监控过程两个过程 通过实施这些过程 从管理角度可以看到一个按计划执行的且阶段可控的软件开发过程 SW CMM的管理思想与结构 续三 3 定义级 定义执行的步骤标准制定企业范围的工程化标准 将这些标准集成到企业软件开发标准过程中去 所有开发的项目需根据这个标准过程 剪裁出该项目的过程 并执行这些过程 对用于软件开发和维护的标准过程要以文件形式固定下来 针对各个基本过程建立起文件化的 标准软件过程 较普遍的看法是 只有当达到了第3级能力成熟度时 才表明这个软件组织的软件能力 成熟 了 定义级是标准一致的软件过程 SW CMM的管理思想与结构 续四 4 管理级 设定定量的质量目标第四级的管理是量化的管理 所有过程都需建立相应的度量方式 所有产品的质量 包括工作产品和提交给用户的产品 需有明确的度量指标 这些度量是详尽的 且可用于理解 控制软件过程和产品 这种量化控制将使软件开发真正变成为工业生产活动 处于这一级的组织已经能够为软件产品和软件过程设定定量的质量目标 并且能对跨项目的重要软件过程活动的效率和质量予以度量 管理级是可度量的 可预测的软件过程 SW CMM的管理思想与结构 续五 5 优化级 持续优化级第五级的目标是达到一个持续改善的境界 可根据过程执行的反馈信息来改善下一步的执行过程 即优化执行步骤 如果一个企业达到了这一级 那么表明该企业能够根据实际的项目性质 技术等因素 不断调整软件生产过程以求达到最佳 优化级是能持续改善的软件过程 SW CMM的管理思想与结构 续六 除第一级外 SW CMM的每一级都是按完全相同的结构组成的 每一级包含了实现这一级目标的若干关键过程域 KPA 每个KPA进一步包含若干关键实施活动 KP 无论哪个KPA 它们的实施活动都统一按五个公共属性进行组织 关键过程域KPA KeyProcessAreas 一组相关联的活动 通过执行这些活动可以实现既定的过程能力 关键实施KP KeyPractices 使关键过程域得以有效实现和制度化的最大的基础设施和活动 SW CMM的管理思想与结构 续七 各个关键实践按每个关键过程域的5个 公共特性 对执行该过程的承诺 执行该过程的能力 该过程中要执行的活动 对该过程执行情况的度量和分析 及证实所执行的活动符合该过程这种成熟度分级的优点在于 这些级别明确而清楚地反映了过程改进活动的轻重缓急和先后顺序 这一点很重要 因为大多数软件组织只能在某一段时间里集中开展少数几项过程改进活动 SW CMM的管理思想与结构 续八 五个公共属性 1 目标每一个KPA都确定了一组目标 若这组目标在每一个项目都能实现 则说明企业满足了该KPA的要求 若满足了一个级别的所有KPA要求 则表明达到了这个级别所要求的能力 2 实施能力实施能力一般包括资源保证 人员培训等内容 它是企业实施KPA的前提条件 企业必须采取措施 在满足了这些条件后 才有可能执行KPA的活动 3 执行活动执行过程描述了执行KPA所需求的必要角色和步骤 一般包括计划 执行的任务 任务执行的跟踪等 在五个公共属性中 执行活动是唯一与项目执行相关的属性 其余四个属性则涉及企业CMM能力基础设施的建立 4 度量分析描述了过程的度量和度量分析要求 典型的度量和度量分析的要求是确定执行活动的状态和执行活动的有效性 5 实施验证验证执行活动是否与建立的过程一致 实施验证涉及到管理的评审和审计以及质量保证活动 SW CMM的管理思想与结构 续九 SW CMM的管理思想与结构 续十一 结论 初始级是混沌的过程 可重复级是经过训练的软件过程 定义级是标准一致的软件过程 管理级是可预测的软件过程 优化级是能持续改善的软件过程 Wecanneverreachperfection Thefocusisonalwaysdoingbetter SW CMM评估的国内外现状 SEI评估报告1996年 2000年 全球有1012个组织进行了CMM评估 其中64 8 为商业组织 26 7 为美国官方和军方合同商 主要业务为软件开发和维护的组织有922个 有将近一半的组织规模是在100人以下 这些数据表明 CMM认证已经引起软件企业的高度关注 并且这种认证同样适合中小企业 通过CMM4 5级评估的状况截止2001年10月底 全世界共有139个组织通过了CMM4和CMM5的评估 73家组织 CMM4级评估66家组织 CMM5级评估这139家组织中 其中美国占59家 印度占72家 其他国家占8家 SW CMM评估的国内外现状 续一 日本情况日本官方将采用CMM软件客观评价标准 官方已决定到2003年由日本政府机构购入的软件都要经受此模型的评价 日本的经济产业省 将在美国卡内基 梅隆大学软件工程研究所的协助下 结合日本市场的特点 与美方共同开发日本版的软件评价模型 今后日本官方各部门将以此为标准 从优秀的软件开发公司购入自己所需的各种软件 改变固定地从大型企业购买软件的局面 SW CMM评估的国内外现状 续二 国内CMM评估的状况我国政府对CMM认证标准给予的足够的关注和支持 国务院发布的 鼓励软件产业和集成电路产业发展的若干政策 也称18号文件 中第17条中表示 将对软件出口型企业CMM认证费用予以适当支持 鼓励企业实施CMM 珠海开发区规定了通过二级一次性奖励50万元的政策 我国已有软件企业通过了CMM标准认证 如motorala 中国 过了CMM5 联想集团通过了CMM3 鼎新过了CMM2等等 预计未来2 3年内 国内将出现软件业实施CMM的高潮 我国通过CMM的认证情况 ISO9001与CMM异同 与ISO标准系列相比 CMM更为软件产业所看好原因是它专门针对软件工程控制而设置的 不仅进行软件企业工程能力的评估 更致力于软件开发过程的管理 强调 对软件开发过程进行持续改进 引导软件开发过程走向成熟 相同点CMM和ISO9001标准系列都着眼于质量和过程管理 二者都为了解决同样的问题 不同点CMM是动态的 开放的和持续改进的 强调没有最好只有更好 强调不断改进 强调人在软件开发方面的思想认识和主动性 适用于软件过程的改进 CMM模型只关注软件 它能解决 软件危机 这个世界性的问题 ISO9001是静态的质量控制 只要达到几个关键指标就能完成质量控制 更适用于硬件制造生产线的质量控制 ISO9001的适应范围更广 包括硬件 软件和服务 软件业对CMM的认识 并不是实施了CMM 软件项目的质量就能有所保障 CMM不是万能的 它的成功与否 与一个组织内部有关人员的积极参与和创造性活动是密不可分的 而且CMM并未提供实现有关子过程域所需要的具体知识和技能 CMM已经是一套发展相当成熟的方法 但国内要想完全掌握并广泛付诸实践 对绝大多数软件企业来说 可能还需要3 5年的时间 美国曾在1995年做过软件产业成熟程度的调查 发现在美国的软件产业中 CMM成熟度等级为初始级的竟占70 其特征是软件开发过程不能预测 风险度高 为可重复级的占15 其特征是软件开发过程需小心谨慎方能避免失败 为定义级的所占比例小于10 其特征是软件开发过程相当稳定 进展顺利且可以预测 为管理级的所占比例小于5 其特征是软件过程预测准确 值得信赖 为优化级的所占比例小于1 其特征是软件过程能持续改善 实施CMM并非一朝一夕的事情 CMM市场存在的问题 1 CMM工具市场薄弱 缺乏过程管理工具北大青鸟 JBCMRational Clearcase2 我国CMM评估师太少全世界获得CMM主任评估师 LeaderAssessor 资格的有355人 而我国仅有两人 原因CMM的门槛很高 要成为CMM主任评估师的条件 1 具有硕士学历2 十年以上的软件开发经验3 两年以上管理经验4 去美国卡内基 梅隆大学学习 并经过多种考核我们缺乏自己的CMM主任评估师大大制约我国软件事业的发展 请外国评估师做一次CMM评估 花费大约是七八十万元 而且语言问题还会在一定程度上影响到评估 这势必大大阻碍我国软件企业在这方面的发展 CMM市场存在的问题 一 3 存在 牌子 误区CMM是梯子 是镜子 不是牌子 CMM不应该成为软件企业的应试教育 CMM应该是通过改善内部管理为企业带来利益的东西 不能带来利益的CMM 也就不能长久存在 CMM只是一个衡量体系 检验企业的软件工程做得怎么样 并不指导企业怎么做 企业只有有效地实施了软件工程 才能去实施CMM CMM市场存在的问题 二 4 评定牵涉大量人力 财力和时间实施CMM评定将牵涉大量人力 财力和时间 例如 美国的CMM评审机构为进行一次评估 或评价 开出的价码是7 10万美金 从接受评估申请到完成评估跨时2到3个月 如果涉及过程改进 将可能需时18 24个月 为了适应中 小组织的需要 要对CMM进行裁剪和压缩 我们怎么办 由于实施CMM的基础是有效地实施了软件工程 所以BEPCII实时数据信息管理系统以实施软件工程为本 执行过程中借鉴CMM的管理方式 软件按其生命周期分为三个阶段 软件定义期 软件开发期和软件运行维护期 软件定义期包括软件项目的系统定义 可行性研究和详尽的需求定义三个工作阶段 这一时期要为被开发的软件项目解决 做什么 软件开发期包括软件设计 编码 调试 测试和验收 这一时期着重解决开发软件 怎么做 的问题 软件运行维护期着重于因多种原因造成的对软件要作的修改 我们怎么办 续一 系统定义明确所开发软件的总体要求和适用范围 描述所开发软件与外界的接口关系 确定所需的硬 软件支持 对开发的进度和成本作初步估计 确定所开发软件的性能与其内部复杂性之间的折中关系和所开发软件与原有软件系统的兼容性关系 在确定以上任务时 设想多种可能方案 并从中进行比较选择 我们怎么办 续二 可行性研究任务是对系统的可行性进行研究 它包括技术可行性 经济可行性和法律可行性等方面 技术可行性应弄清现有的技术条件能否完成开发工作 参加人员是否胜任开发技术的要求 硬件环境配置能否满足开发的需要 用户提出的开发周期和技术要求是否合理等 经济可行性研究的目的是希望以最小的开发成本获得最佳经济效益的软件产品 因此需要作投资估算 如对人工费用 硬软件支持或其他费用进行估算 对软件投入使用后可能带来的经济效益进行估算 法律可行性研究所开发的软件项目是否涉及到专利权 版权等法律问题 我们怎么办 续三 需求分析软件定义期的关键步骤 主要是理解和表达软件系统的用户需求 它包括所开发软件的功能 性能 可靠性 安全性 成本消耗 开发进度 资源利用 用户接口和所需的数据库等许多方面 在研究用户需求的基础上 将经过分析的软件需求编写成软件需求说明书或软件规格说明书 作为需求分析阶段的主要工作成果 我们怎么办 续四 软件设计分为概要设计 也称为总体设计或结构设计 和详细设计 模块设计 两个阶段 概要设计是从宏观角度解决开发软件 怎么做 的问题 把系统要完成的任务按功能分块 明确各模块的功能以及它们之间的接口 即模块之间的相互关系以及模块之间传递的信息 详细设计则要明确每个模块内部的处理过程 即要给出每个模块的详细说明 流程图 一些典型或重要方法的结构化说明或伪代码等 我们怎么办 续五 总体设计根据需求分析阶段的用户需求说明书 产生具体的实际方案 主要解决 怎样将系统分解成一个个功能独立 大小规模适当的模块 判定各模块之间传递的数据 规定各个模块的功能和模块之间的相互联系 决定各模块间调用的层次关系 审查评价模块结构的质量 产生模块说明书 该阶段常用的方法有 自顶向下逐步求精 原型法 结构化设计方法 即SD方法 Jackson方法 Parnas和LCP方法 我们怎么办 续六 详细设计软件设计的第二阶段 与总体设计相比 它主要考虑每个模块内部的数据加工处理 完成模块内部详细的过程描述 进行详细设计主要使用的工具可分为三种类型 图示工具 常用的有结构化流程图 N S图和PAD图 伪代码语言 表格工具 如判定表 判定树等 我们怎么办 续七 软件测试为了发现错误而执行程序的过程 是软件生存期中的重要阶段之一 它的主要任务是发现并排除需求分析 系统设计和编码等阶段产生的各种类型的错误 得到可靠的可运行的软件系统 软件测试可分为四级 单元测试 集成测试 确认测试 系统测试