软件企业CMM实施方案

一 软件企业 CMM 实施方案 1 1 1 CMM 实施的一般过程 1 1 1 1CMM 培训和咨询 1 1 1 2 合理目标的确定 1 1 1 3 工作组的成立 1 1 1 4 制定和完善软件过程 2 1 1 5 内部评审 2 1 1 6 正式评估 3 1 1 7 根据评估结果改进软件过程 5 1 2 CMM 实施中存在的问题 原因及解决办法 5 1 2 1 对 CMM 实施的认识问题分析 5 1 2 2 组织及角色安排 7 1 2 3 实施策略 7 1 2 4 需求管理与需求工程 7 1 2 5 配置管理与工作产品的转化 9 1 2 6 项目计划与数据收集和分析 9 1 2 7 质量保证与实践反馈 9 1 2 8 同行评审 10 二 武汉开目公司 CMM 实施分析及研究 11 2 1 武汉开目公司实施 CMM 前的研发情 11 2 1 1 企业研发管理的优点 11 2 1 2 企业研发管理中存在主要问题 11 2 2 武汉开目公司选 CMM 模型进行过稳改进的原因 12 2 2 1 导入 CMM 理论 12 2 3 武汉开目公司实施 CMM 的程序及具体内容 12 2 3 1 组织机构调整 13 2 3 2 组织 CMM L2 级的过程定义 14 2 3 3 CMM L2 正式运行 16 2 3 4 CMM L3 过程定义 16 结束语 17 1 1 软件企业软件企业 CMMCMM 实实施方案施方案 CMM 提出了各成熟度等级的 KPA 的目标来指导软件企业调整组织结构及业 务流程 各软件企业需要根据自身的业务目标及要求来实施 CMM 本节将具体 介绍 CMM 实施的一般过程并阐述实施中存在的问题或原因 同时 提出了较为 详细的解决方法 1 11 1 CMMCMM 实施的一般过程实施的一般过程 CMM 实施牵涉到企业业务流程的重组 因此 CMM 实施首先要统一认识 并得 到企业高层的强力支持 本节主要介绍 CMM 实施的一般过程 1 1 1CMM 培训和咨询 根据 CMM 模型的要求 一个项目的开发一定要有章可循 而且要做到有章 必循 这两点都离不开培训 培训的内容主要有两个方面 第一 对所有员工 包括经理在内的最基本的软件工程和 CMM 培训知识 第二 对各个工作组的有 关人员提供专业领域知识等方面的培训 此外 在每次开发过程中 还要对普 通人员进行软件过程方面的培训 培训的方式有很多 第一 向有关专业培训咨询机构进行咨询 这些培训 公司为 CMM 知识的导入起着主导作用 他们来源于各种背景 有国家有关研究 所 相关协会 大学 原 Is09000 咨询公司 新创办的 CMM 咨询公司 实施过 CMM 的企业等 第二 利用互联网资源进行咨询和培训 可以报名参加 CMM 网 校等网进行系统的学习 第三 聘请有关 CMM 专家到企业实地指导 CMM 的实施 企业可在被指导过程中逐步掌握 CMM 的要领和实施过程 值得注意的是 企业 最开始阶段必须聘请一位经验丰富的 CMM 专家 但以后一定要培养自己的专家 这样不仅能节约开支 还能使企业自己具有一个对 CMM 深刻理解的 有实践经 验的专家 为企业今后的继续升级打下一个良好的基础 1 1 2 合理目标的确定 CMM 模型划分为 5 个级别 18 个关键过程域 52 个目标 300 多个关键实 践 每一个 CMM 等级的评估周期 从准备到完成 约需 12 30 个月 无论一个软 件企业的软件过程处于什么样的水平 都可以在 CMM 框架的 5 个级别中找到自 己的位置然后有针对性采取与自己所处别相适应的措施 使企业能纳入 CMM 的 进化阶段 使软件过程管理早日得到改善因此 要实施 CMM 首先应该对本企 业的现状有一个准确的评估 企业目前处于什么水平 企业发展的问题是什么 2 借助 CMM 要达到的目的是什么 然后再结合企业的实际情况选择 CMM 的切入点 确定总体目标 这个目标包括在多长时间之内 需要投入多少人力 物力和财 力 要达到哪一级 在总体目标已经确定的前提下 还要制订近期目标和长期 目标 1 1 3 工作组的成立 企业针对 CMM 的实施 应成立专门的 CMM 实施领导小组或专门的机构 领 导层必须真正学习理解软件过程管理和改进的重要性 亲自领导和参与 要保 证过程管理的人员配备 抽调企业中有管理能力 组织能力和软件开发能力的 骨干人员 在 CMM 的实施过程中 工作组的成立是 CMM 的一个关键步骤 有几 个重要的组织是必不可少的 这些组织包括软件工程过程组 软件工程组 系 统工程组 系统测试组 需求管理组 软件项目计划组 软件项目跟踪与监督 软件配置管理组 软件质量保证组 培训组 在 CMM 的实施中组织机构的设置必须完善 但不等于说每一个机构必须是 独立的 有些组织很小时 机构可以适当合并 成员可以身兼数职 但对那些 关键践要求独立性时 组织必须十分小心 例如 软件质量保证组的独立性就 是必须考虑的 否则在技术上或机构上出现的偏差 会无目的地影响到软件过 程 项目质量和风险决策的正确性 在这里还要提到一点 那就是物理组和逻 辑组 在 CMM 中有两种组织 一种叫物理组织 它是客观存在的 例如项目组 技术部等 有众多专职人员 另一种叫逻辑组织 就是说它的人员可以是兼职 的 很多逻辑组只需一两个人就可以了 1 1 4 制定和完善软件过程 CMM 模型强调软件过程的改进 如果企业还没有一个文档形式的软件过程 则首要任务是对当前的工作流程进行分析 整理及文档化 从而制定出 个具 有本企业风格的软件过程 并用该文档化的过程指导软件项目的开发 如果已 经具备了软件过程 则要对这个过程做内部评估 对照 CMM 的要求 找出问题 然后对这个过程进行补充修改 在具体实施的过程中 可以选择有一定代表性 和完善性的项目组或项目进行试点 跟踪 监督改进后的软件过程的实施情况 执行改进活动的状态 同时 过程小组的成员还应该维护过程中的数据库 定 期统计各个过程中的产品和规模 开发周期 修改次数及评估周期 这些数据库可用来分析项目的效率以及存在的问题 以便今后进一步改进 同时还可以为项目开发过程提供咨询 171 总结这些项目组或项目以前成功的 3 经验 从中规划出一个具有实际意义的软件过程 按照 CMM 规范评估这个过程 找出其中的优缺点 对不满足 CMM 要求的地方加以完善 使其成为一个完美的 实施 CMM 的软件过程方案 然后将这个软件过程应用到当前正在承接的或即将 承接的项目上 在实际使用过程中进一步发现其中的不足和错误之处 加以改 进 最后将试点的结果推广到整个企业 1 1 5 内部评审 由于我国在 CMM 评估中要聘请外籍主任评估师 费用较高 据估计 要通 过一个级别的 CMM 评估 费用是通过 Is09000 认证的十多倍 因此 建议软件 企业在进行正式评估之前 先进行内部评审或评估 这种内部评审包含两层含 义 第一种就是软件企业组织自己内部成员 严格 认真地按照 CMM 规范评估 过程 对自己的软件过程进行评审 找出其中的不足点并进行改进 第二种含 义就是在全国范围内 由有关软件工程和 CMM 专家组成一个专门的 内部评审 机构 负责指导协调实旌 CMM 的活动 推进活动的深入开展 对国内软件企业 CMM 评估进行 预先评估 这种预先评估 可降低软件企业通过正式 CMM 评估的风险 减少软件企业 实旌 CMM 的成本 为企业最终获得国际 CMM 认证打下基础 1 1 6 正式评估 目前主要有两种基于 CMM 的评估方法 一种是 CBA SCE CMM Based Appraisal for so Rawer c ability Estimation 它是基于 CMM 对组织的软 件能力进行评估 是由组织外部的评估小组对该组织的软件能力进行的评估 另一种是 CBA 坤 I CMM Based Appraisal for Internal Process Improvident 它是基于 CMM 对内部的过程改进进行的评估 是由组织内部的小组对软件组织 本身进行评估以改进质量 结果归组织所有 目的是引导组织不断改进质量 这两种评估均由 CMU SEI 授权的主任评估师领导 参考 CMM 框架来进行 都要 审查正在使用和将来使用的文件 文档 并对不同的组织员工进行采访 SCE 与球 I 两评估结果应该一致 评估结果的所有资料都将呈报 CMU SEI 针对企 业实施 CMM 的需要 这里主要讲述 CBA IPI 的评估方式 以便企业为提高软件 过程进行内部评审 CBA DI 评估一般为 7 天 在 7 天的时间内 或更长的时间 这主要取决于评估的范围 通过发现组织的优点和缺点 便能准确地描绘出一 个组织的软件能力 一个评估组会检查文档 与项目经理 软件开发者甚至中 层经理面谈 CBAIPI 方法需要一个主评估师和一个评估小组 4 主评估师来自被评估组织之外 评估小组则是由来自组织内部和外部的人 员组成的 评估小组的规模为 4 到 10 人 并且 SEI 要求小组中至少有 1 人来自 通过评估的组织 主评估师负责在评估之前对小组成员进行培训 有一个现场 协调员负责制订围绕 CBA 一口 I 的所有计划 一次评估可以有如下一些目标 1 确认组织的软件过程成熟度符合 CMM 的哪一级别 2 识别需要过程改进小组努力的薄弱领域 3 识别可以移植到组织中其它部分的最好的实践活动 在评估活动开始之前需要拟订一个评估计划 包括目标 范围 时间表 编制 可能发生的评估过程的步骤 评估工作分几步开展 1 文档的审查 评估小组仔细审阅组织的文档 评估小组审查三类文档 1 第一种是组织级文档 是指组织成员都应该了解和执行的文档 2 第二种是项目级文档 是指具体项目程序文件 3 第三种文档是执行文档 这是用来记录工作是如何遵循组织级和项目级规定 的过程执行的 SEI 建议花 80 的文档审核时间来审核执行级文档 这些记录 能表明活动是否遵循 CMM 的要求 2 文档审核完毕后 评估组与参与者面谈 访谈人员覆盖面 60 以上 包括项 目经理 职能部门的代表 中层经理和初级技术人员 通过面谈 评估组开始 全面地了解该组织对于过程的理解并且将观察到的该组织的过程制度化情况 也就是该组织成员是如何理解和执行过程的情况 详细地记录下来 评估员 想听到职员是如何从事与 CMM 相关的工作的 面谈人员的问题十分广泛 目的 在于发现一些特别的回答 由于问题是精心编制的 所以它们的答案是不可预 见的 问题与运用的过程和环境相关 3 制作调查报告 在制作调查报告时 评估组会遵守些确保正确的准则 调查 报告依据的信息是通过两次独立的面谈过程收集的 或者至少一次面谈加一次 文档审查 调查报告的资料一般有多种来源 评估组讨论每个调查报告并通过 表决决定它的有效性 一个有效的调查报告应具有准确性 确定性 并且和其 他的调查报告一致 在保证有效性的前提下 评估会充分地覆盖组织的开发生 命周期和 CMM 的关键实践域 所有的面谈结束后 调查报告也已制作完毕并有 了初步的结论 该结论提交给受评估的组织 这个过程也是一个信息收集阶段 这时被评估组织可以对某个特殊的意见表示赞同或反对 4 完成评估报告 在每个评估报告中 会针对 CMM 的每个关键过程域 指出这个软件过程在什么 地方已经有效地执行了 什么地方还没有有效地执行 只有所有评估人员一致 通过的情况下 这个评估报告才有效 5 5 CMM 与企业的创新文化是不矛盾的 软件企业的有些管理人员 也包括一些开发人员往往抱怨或认为严格的管理束 缚他们的创新 他们认为在 CMM 中提倡的一种按部就班 什么活动都要做计划 按规程标准来做 对企业的创新文化会起负面作用 形成这种观点主要有两个 原因 一是企业在推行 CMM 时 过分机械 没有从实际出发 不能与实践紧密 结合 挫伤了开发人员的积极性 二是这类人员缺少真正的软件工程经验 做 的大项目太少 经历的失败太少 事实上 CMM 本身就是一种软件工程管理的 创新 而技术创新必须通过管理才能使其有效地转化为生产力 转化为企业的 实际效益 达到效益最大化 这是最根本的 6 要勇于实践 允许犯错误 CMM 就是软件工程经验与教训的总结 在实施 CMM 的过程中 肯定会走弯路 甚至于要犯错误 对于软件企业的领导尤其要注意 这一点 不要因为在过程中的一些实践失败 就对项目经理 SEPG 等人员有偏 见 要提倡这种文化 7 过程改进是组织内所有人的事情 而并非仅仅是 SEPG 的事情 SEPG 组专职负 责企业的软件过程改进工作 另外根据需要成成立技术任务组 即 TWG techn0109y work Group 他们会兼职地参与特定过程规程 标准的制定 试点和修改完善工作 但是 推行 CMM 不仅仅是管理人员的事情 每个人都必 须积极参与 而不应是 SEPG 即 SEPG So Rawer Engineering Process C 在使 劲的推进 CMM 的工作 而员工则是不自愿地来实施 CMM 从 SEPG 的角度来看 要做好过程改进工作 首先要解决的是大家的思想认识问题 291 1 1 7 根据评估结果改进软件过程 根据 Ideal 初始化 Initiating 诊断 Diagnosing 建立 Establishing 行动 Acting 扩充 Leveraging 成熟度的评估只是软件过程改进中的一个环 节 如果这个环节与软件过程改进的其他环节不能很好地结合 那么 CMM 评 估对于软件过程改进所应具有的作用就得不到发挥 一般来说 应该在评估之 后很快地做出软件过程改进的计划 因为这时大家对评估结果和存在的问题仍 有一个深刻的认识 计划在软件过程改进中是一个非常必要的阶段 只有有效 的计划 才能确保软件过程得到有效的改进 CBA 评估方法对衡量软件企业的 能力成熟度是一个非常有效的手段 评估结果本身就是一个非常坚实的基础 是制定软件过程改进计划的依据 1 21 2 CMMCMM 实施中存在的问题 原因及解决办法实施中存在的问题 原因及解决办法 以上阐述了 CMM 实施的全部过程 具体包括培训咨询 确定目标 组织成 6 立 过程定义 评估以及后续企业持续改进过程等步骤 这些步骤中都会遇到 很多阻力和问题 下面从九个方面阐述主要的问题和解决办法 1 2 1 对 CMM 实施的认识问题分析 在基于 CMM 实施软件过程改进时 首先要解决思想认识问题 否则 会使 实施周期拉长或效果不好 甚至导致过程改进的失败或中止 软件企业的高层 领导 企业的过程改进主管 销售人员 项目经理及一般的开发人员都需要对 这些问题统一认识 在此基础上才能消除各方面的阻力 把握好过程改进的方 向 控制好过程改进的进度 认识问题主要有以下几点 1 CMM 不是万能的 企业必须使软件过程 工具 开发方法 人员等多种因素一起提高 才能 保证带来经济效益 因为人员 技术和过程是软件开发的 铁三角 缺一不 可 在开始实施 CMM 时 最容易犯的一个错误就是 唯管理论 或孤立地只抓 过程改进 忽略了开发技术与人员的提高 过分强调管理的作用 实施了半年 或一年后 发现企业的生产能力并没有得到明显的改善 这时反对的声音就会 成为主流 过程改进就难继续进行了 有的企业采用面向对象的开发方法进行 软件开发 但是企业内并没有对面向对象技术真正了解的专家 虽然也采用 RUP 过程 也采用 ROSE 等开发工具 但是仪仅是形似 没有做到真正的面向对 象方法 没有得到面向对象方法的精髓 这种问题仅仅依靠过程改进是无法解 决的 有的企业开发人员的积极性很差 工作热情很低 企业的激励机制没有 起到很好的作用 这种问题依靠 CMM 也是无法解决的 2 管理就是预防 管理的作用是隐性的 不可能立竿见影的 在实施 CMM 时 企业的管理层在开始时往往会对过程改进期望值太高 希望短 时问内效果显著 效果显著与否不是由一个方面的要素决定的 需要多个因素 共同改进 而管理的最大作用是预防 防患于未然 任何的管理的改善都是符 合学习曲线的 即在改进的初期企业的运行效率可能会下降 甚至可能会出现 一些混乱的局面 所以在改善的初期要让员工有思想准备 要有耐心 3 坚持活学活用 以我为主 机械照搬 CMM 的条文是在实施 CMM 时常犯的错误 CMM 是软件工程经验的 集大成 是从实践中总结出来 用以指导实践的 CMM 本身也在更新版本 不 断完善 在推行 CMM 时 所以遇到的阻力 很大程度上是由于照搬 CMM 的条文 不切合项目组的实际 没有具体情况具体分析 实际上 一线的管理人员 开 发人员最了解实际 谁了解实际 谁有发言权 所以在制定 CMM 规程标准时 尤其是在制定大家要执行的操作规程 模板和记录报表时 一定要得到执行者 7 的认同 则就容易造成执行和沟通的障碍 导致过程改进工作受阻 4 要改良式不要革命式 以革命的方式来实施 CMM 期望通过一场运动来解决过程能力的问题 可 能的原因之一 是企业不懂 CMM 不知道管理改进是循序渐进的 原因之二可 能是明知故犯 期望在短期内通过 CMM 评估 单纯追求市场上的轰动效应 有 的企业在短时间内虽通过了 CMM 几级评估 我想恐怕由于没有实效而得不到大 家的认同而难以将这种 水平 持续下去 事实上 一个企业引入 CMM 之后会 从本质上影响企业的文化 改变大家的思想与做事方法 5 CMM 与企业的创新文化是不矛盾的 软件企业的有些管理人员 也包括一些开发人员往往抱怨或认为严格的管 理会束缚他们的创新 他们认为在 CMM 中提倡的一种按部就班 什么活动都要 做计划 按规程标准来做 对企业的创新文化会起负面作用 形成这种观点主 要有两个原因一是企业在推行 CMM 时 过分机械 没有从实际出发 不能与实 践紧密结合 挫伤了开发人员的积极性 二是这类人员缺少真正的软件工程经 验 做的大项目太少 经历的失败太少 事实上 CMM 本身就是一种软件工程 管理的创新 而技术创新必须通过管理才能使其有效地转化为生产力 转化为 企业的实际效益 达到效益最大化 这是最根本的 6 要勇于实践 允许犯错误 CMM 就是软件工程经验与教训的总结 在实施 CMM 的过程中 肯定会走弯 路 甚至于要犯错误 对于软件企业的领导尤其要注意这一点 不要因为在过 程中的一些实践失败 就对项目经理 SEPG 等人员有偏见 要提倡这种文化 1 2 2 组织及角色安排 企业上层领导要首先理解建立软件过程管理和改进的重要 并亲自领导这 件工作 同时 企业上层要保证过程管理的人员配备 企业上层领导的持之以 恒的参与是成功的先决条件 其次 专业开发人员要全力支持与参与过程管理 和改进 建议成立 SEPG 组 作为协调过程定义 改进及部署活动 不一定要全 职的 SEPG 人员 但应该明确指派到某人负责 对于 CMM 要求的一些角色 可以灵活安排 不必太过拘泥 小项目未必需要专门的软件配置管理组 但配置管理活动是不 可少的 独立的质量保证组也许不必要 但必须有人完成验证的活动 项目组 成员可以担当多重角色 如项目经理可以同时担任 SCM 的角色 而测试人员也 可同时担负 SOA 的角色 1 2 3 实施策略 8 中小企业在实施 CMM 过程中 组织支持是基础 策略则是步骤有效实施的 粘合剂 不能因为过于繁琐或影响进度而弃之 首先 过程必须文档化是必不 可少的 如果企业还没有一个文档化的软件过程 则首先要总结以往项目成功 的经验 对当前的工作流程进行分析 整理及文档化 制定出一个适合本企业 的软件过程 并用该过程指导软件项目的开发 其次 过程的裁剪 过程需要 裁剪到项目所需的程度 这也是中小企业实施 CMM 过程改进的关键 裁剪的准 则就是一切以实用为主 避免过于繁琐和形式化 最后 是组织培训 只有让 所有员工了解 CMM 才能支持 CMM 的实施 1 2 4 需求管理与需求工程 需求开发和需求管理是需求工程的两部分 如果没有做好需求开发 那么 从需求管理的角度看就会出现重复性的工作 导致需求开发质量不高的主要原 因有以下几点 1 缺乏良好的需求规格说明编写模板 分析一些企业的 CMM 实施过程 从表面上看 它们的确遵循了先推荐方案 再进行评审的基本选择原则 但由于缺乏经验 实际选定的方案常常缺乏客观 性 同时在企业的工程和管理机制里又缺乏实践反馈的方法和过程来不断地改 进原有的方案 一般来说 大家在一起工作的时间长了 就会形成一种 默契 而这很可能给以后的工程和管理工作埋下很多隐患 一旦出现意见分歧时 这种默契就不复存在 如果按 CMM 的要求去做 大量类似的重复工作就会因此 出现 改进的方法就是在整个工程和管理过程中 既保持文档和产品的一致性 又反向追踪需求规格说明更改的程度 并持续改进需求规格说明编写模板 2 较严重地忽略了非功能性需求 目前 国内的软件客户很少主动提出非功能性需求 但随着客户的逐渐成 熟 软件客户对软件的非功能性需求也会越来越高 这就对软件开发商提出了 更高的要求 不做好非功能性需求的规格说明编写工作 同样会陷入大量重复 工作的包围之中 如果缺乏非功能性需求的规格说明 将会使一些基础问题赢 到软件生命的中期才被发现 这将导致大量的文档和产品需要更改 由此带来 严重的工程和管理难题 改进的方法就是调用有相当软件调试和维护背景的资 深人员参与需求规格说明的编写 他们的丰富经验往往可以较好地弥补设计开 发人员在这方面存在的不足 3 缺乏对需求文档的配置管理 很多企业采用两个需求规格说明编写模板 一份给软件客户看 一份留给 软件开发小组内部使用 前者的目标是让客户较容易理解 后者则更加专业化 9 在这种情况下 两个需求规格说明都应纳入配置管理的范畴以便从管理的角度 保持其一致性 从工程角度考虑 企业还应该形成一套从前者到后者的转化规 则 尽管这两个模板的表现形式可能是自然语言 但一个尽可能严谨的规则将 大大缩小转化过程中人为自由发挥的空间 需要注意的是 这套规则的建立应 从一个项目开始 从基础做起 逐渐完善 3 例如 首先确定项目的基本名 词和动词集合 并规定语句书写规则 4 需求规格说明缺乏可测性 在需求说明编写阶段 主观性对其他特性的影响较大 而一个独立且有经 验的测试组对可测性的掌握是从独立于需求规格说明的测试文档出发的 从测 试的角度看 很多需求说明是不可测的 这就要求重写这些需求说明 直到可 测性得到保证 测试组要求的往往是简洁且准确的说明 而这恰恰是开发人员 做得不够好的几个方面之一 5 缺乏较好的需求规格说明转化规范 需求规格说明转化的目的是把用自然语言书写的需求说明转化为更准确的 中间形式 这一转化过程也被称为 软件建模 p 一般来说 建模可以使需 求说明的某些方面更形式化一些 并使设计更加清晰地保持需求继承 通常 不做需求规格说明转化或缺乏较好的需求规格说明转化规范 将造成不同程度 的需求说明丢失 从而增加后续管理工作的难度 需求管理的根本目的是为其 后的工程和管理建立基线并保持相关及衍生文档和产品与需求的一致性 因此 需求工程完成得好坏对需求管理实施的工作量有很大影响 1 2 51 2 5 配置管理与工作产品的转化配置管理与工作产品的转化 软件配置管理的目的是保证项目生成的产品在软件生命周期中的完整性 它需要一个较好的工具 配置管理方面存在的典型问题是 有太多的 CCB 软件 配置控制委员会 配置管理是在软件生命周期中建立和标识软件工作产品并控 制基线的更改 这将保证软件工作产品的完整性和一致性 但是 作为配置项 单元标识的软件工作产品通常为典型的软件生命周期中的工作产品 这些产 品具有一个共同特点 一个产品通常是由另一个产品转化而来 从一些企业配 置管理下的工作产品来看 存在的主要问题是缺乏较好的可转化性 在这里 较好的可转化性 是指把一个产品转化为另一个产品时有较规范的转化规则 可循 其目的是最大程度地保证一种工作产品能被忠实地转化为另一种工作产 品形式 从而最大限度地降低最初的软件需求在转化过程中出现遗漏和被错误 解释的可能性 企业在实施这个关键过程域时 应由 CCB 记录工作产品的更改 以及引发这些更改的原因 这些数据能很好地帮助企业找出问题的症结 36l 10 一般来说 引发类似问题的原因主要有以下三点 1 需求规格说明书编写不好或不全 2 工作产品模板定义不好 3 工作产品之间转化缺乏规范定义 1 2 61 2 6 项目计划与数据收集和分析项目计划与数据收集和分析 项目计划是 CMM 实施一开始就涉及且最后才能相对完善的关键过程域 它 主要包括软件规模估计 工作模块计划 人力资源计划 进度安排和其他资源 计划 在其他关键过程域的实践相对稳定之前 项目计划的实践总是处于需要 改动的状态 这需要经历若干项目的实施才能获得有效数据并据此制定未来项目 的计划 我们知道 配置管理可以保证项目生成的产品在软件生命周期中的完 整性 因此 为了更好地实施项目计划 我们可以把用于项目计划的大部分数 据放在对应的工作产品配置管理之下 必要时 还可将工作产品进一步细化 以保证对应的项目计划数据的准确性 项目完成后 我们还应该对项目计划的 数据进行收集和分析 在此基础上制定下一个项目计划时 准确性就能大大提 高 通过对若干项目进行同样的实践 项目经理就有了比较可靠的数据用于制 定未来的项目计划 通常 项目跟踪和监督实施不好的原因很大程度上是由于 项目计划的频繁更动 同时缺乏良好的项目跟踪工具 使项目管理人员逐渐失 去跟踪项目的兴趣 1 2 71 2 7 质量保证与实践反馈质量保证与实践反馈 实践反馈是质量保证体系得以有效运作的驱动力 企业应该为所有项目建 立一条从 SQA 到项目经理以及更高层经理的反馈渠道 实践反馈是 SQA 组与高 层经理相互沟通的过程 SQA 组定期向高层经理汇报 SQA 的活动 并及时与项 目组沟通 使项目组能尽早改进工作 当沟通不畅 发现项目组运作不力或发 现组问协调困难时 应及时报告高层经理 通过高层经理的协调及时进行修正 有些项目经理认为自己心里有一套计划 只要按计划进行就可以按时保质完成 项目 但事实并非如此 在项目组之间的协调问题上 高层经理的作用是非常 明显的 如果仅仅为满足 CMM 的要求而虚设高层经理 这种做法是不可取的 因为如此一来 实践反馈是不完全的 SQA 组在 CMM 实践中犹如一个司法机构 但这还不够 它还应该为改进过程管理提供资源 1 2 81 2 8 同行评审同行评审 从理论上讲 同行评审这个 KPA 的实施并不难 但实际上大多数企业都掌 11 握得不够好 主要表现在以下方面 1 评审时组问争论过多或过少 这一问题在不同企业的表现也不同 调查表明 争论较多的情况是工作产 品的输入 输出不清楚 组间缺乏沟通的公共平台 因此组问只有通过较多的 讨论甚至争论才能弄清其他组的需求 另一种较极端的情况是 评审一个组的 工作产品时 其他很少发表意见 尽管考些题是十分明显熬 2 缺乏心理练 做好同行评审的最大困难是克服心理障碍 简单地说 同行评审就是被别 人挑错或挑别人的错 因此 评审会就像是答辩会 必须做好充分的准备 当 角色互换 自己成了挑错方时 则应该把被评审的工作产品看成是自己在较早 前完成的 现在再做一次修改 且修改完成后要拿它去参加评审答辩 经历几 次这样的心理角色换位 就会逐渐邋应 如果大家都这么做 评审会形成良好 的氛潮 这将对形成健康的企业文化起促进作用 3 竞争与合作意识不充分 从另一个角度讲 同行评审又是竞争与合作最佳表形式 凡在这种场合话 有理且意中肯的入逐渐会成为核心人物 在这种竞争的环境中 合作是基础 同行评审的目的就是在合作的前提下尽早盈有效魄排除工作产品中的缺陷 把 握好竞争与合作的尺度 将有益于企业文化的发展 否则有可能出现恶性循环 如何把握从大量的案例着 多数消化少数是较好的方法 因为文化足不可创造 的 4 考虑不全面 个别企业选用了一些难度更大的度量 大多数情况下 这些企业并非要达 到高级别的 CMM 而是从产品需求的特性出发 对工作产品进行缺陷分析和预 防 其过程通常是 获取数据 数据整理 度量 发现原因并确定过程的改进 措施 其典型例子包括设计复杂性与测试覆盖及测试深度 模块复杂性与测试 覆盖及测试深度等 这类企业的软件产品一般具有以下特点 软件产品规模较 大 通常在软件产品交付给用户后 通过相当长时阃的不断维护 稳定性才能 达到满意程度 如果在早期对可能产生较多错误的软件模块进行识别 加强对 这些模块的早期关注和测试 就可较早地使系统达到稳定 这种方法常常用在 大型软件开发中 但真正用好的并不多 主要原因有以下几点 1 忽略了使用度量的环境 2 忽略了对度量参数的修改 二二 武汉开目公司武汉开目公司 CMMCMM 实施分析及研究实施分析及研究 12 本章以武汉开目公司实施 CMM 的过程为对象 从开日公司实施 CMM 前的企 业研发情况及公司选择 CMM 作为改进过程能力的原因入手 重点介绍了开目公 司实施 CMM 的详细程序及具体内容 晟后详细总结了实施过程中的经验教训 2 12 1 武汉开目公司实施武汉开目公司实施 CMMCMM 前的研发情前的研发情 CMM 定义了软件成熟度的五个级别 每个软件企业都可以在 CMM 模型中找 到自己的位置 即处于成熟度等级的哪个级别 因此 企业在实施 CMM 前一定 要对组织现状进行调研 了解自己的长处和短处 标识组织与对应的成熟度等 级的差距 有的放矢地进行过程改进工作 开目公司的优点及主要问题分析如 下 2 1 1 企业研发管理的优点 1 企业于 2001 年 6 月通过了 Is090 叫 2000 质量管理体系认证 建立了公 司级的质量方针 研发规范 测试规范及项目实施规范等文档化制度 2 企业高层非常重视信息化基础建设 产品质鼍意识非常强 在人 财 物方面非常支持过程改进工作 3 企业前身为高校院系的教研室 十年来 企业保持着主动教和自愿学的 良好学习氛围 合作意识浓厚 企业人际关系融洽 企业提倡沟通 厌恶保守 的工作作风 4 企业员工年轻富有活力 愿意接受新事物 创新意识强 5 武汉开目公司拥有良好的用户关系 在软件实施过程中能够与用户就软 件需水达成协议 6 在软件工程方面 己在自动化测试 测试用例管理等方面进行了一些有 益的尝试 2 1 2 企业研发管理中存在主要问题 虽然建立了一套 9000 体系 在研发体系的某些局部取得了一些成绩 对软 件业的管理支撑缺麓专业性 对软件研发的各个领域覆盖面不够 软件研发流 程缺乏系统憔 主要问题如下 1 需求变更没有送行必要的控置 2 软件配置管理仅局限于备份屎面 没有建立必要的配项标识规范 版本标识 13 混乱 配置项查找难 代码管理混乱 经常找不到所需的源代码 3 技术类工作产品评审效率低下 评审组成员不知道应该评审什么内容 自己 的评审职资是什么 有效性差 软件缺陷识别率低 4 缺乏有效的评估机制来规范使用开发工具 新的技术和新的工具 5 没肖机构对过程改进直接负责 没有有效的机制保障过程改进的持续进行 2 22 2 武汉开目公司选武汉开目公司选 CMMCMM 模型进行过稳改进的原因模型进行过稳改进的原因 2 2 1 导入 CMM 理论 2003 年 1 月 4 6 日 公司聘请 India 咨询师 Atul Mathul 对公司主要部 门领导进行了 CMM 公开培训 CMM0verview 2003 年 3 月 12 网 16 日 在公司 领导层任务层中有力缝宣传 CMM 对提高软件工程能 力的重要性 基本方法和成功运用的案例 得到了公司领导团队的认同和大力 支持 CMM 过程改进的目标是使开发活动更透明 达到分阶段质量控制 规范 开发活动 减少返工 提高效率 同时有效克服人员流动带来的影响 从而最 大限度地保障客户信息安全 1 自顶向下与自底向上相结合 2 循序渐进 由易副难 3 从改变观念做起 培训 沟通组成 CMM模型进行过程改进基于以下的外部和内部原因 1 国家提倡 2 政府支持 3 操作明确 CMM 针对软件企业而设计 18 个关键过程域 316 个关键实 践规定了具体的活动要求 这些关键过程实践体现了啦界的成功经验 有可信 的指导 参考价值 2 32 3 武汉开目公司实施武汉开目公司实施 CMMCMM 的程序及具体内容的程序及具体内容 武汉开目公司的 CMM 实施是在 QAJ India 公司主任咨询师何博士的指导下 开展 实施工作有计划有节奏地开展 以下关于开目公司实施流程如图 2 1 14 图 2 1 武汉开目公司实施流程图 2 3 1 组织机构调整 基于过程改进的要求 公司对组织结构进行调整 确定 SEOG 组 QA 培训 等工作组 明确了各工作组成员的职责 在 SEPG 组还定义了 KPALoader 职责 由 KpA Leader 负资各关键域的工作 组织机构是在公司现有机构基础上做的调 整 没重大变革 由于历史原因及项目经理能力所限 该公司调熬后的组织机 构为弱矩阵测 职能部门经理负责技术改进 人员培训成绩效考核 项目经理 负责项目管理 其项目成员成绩经理提交部门经理 调整如图强 2 2 示 15 图 5 2 2 3 2 组织 CMM L2 级的过程定义 2003 年 3 月 19 日 27 目 sEPG 组相关人员采取封闭开发的方式执行流程 定义项目 其问研讨了 CMM 的精神要点 讨论了各部门业务流程 确定了采取 迭代模型进行 CMM 实旖工作 由于开目公司同行评审的能力较弱 公司决定 第一步 在进行 CMML2 的过程定义时 同步完成 CMML3 的同行评审的改进工作 定义 CMML2 的全部 CMM L3 的部分过程文件或文件框架 不含支撑文件 第二 步再实施 CMM L3 的其余部分 并优化各类指南 模板 下面详细介绍开目公司 CMM 实旌中比较有特色的 A 1 需求管理 由于武汉开目公司是基于现有产品对多个用户进行个性化服务 因此 一 个研发项目将对应多个用户 为了较好把握用户需求 并对用户项目 研发项 目进行分别跟踪管理 公司成立需求管理部 负责与用户就需求达成一致 同 时 需求管理工作的基本工作 如图 5 3 16 图 5 3 1 在立项启动时 同时建立初始配置库 存放和管理立项阶段到策划阶段产生 的工件及其评审记录 2 在项目正式确定之后 项目经理指定配置管理员编写 配置管理计划 3 根据 配置管理计划 创建配置管理环境 补充和细化配置库 4 配置管理环境创建之后 开展配置管理活动 2 配置管理 配置管理流程 流程图如图 2 4 17 3 同行评审 由于开目公司的问题是评审组成员不知道评审内容是什么 因此 本次流 程定义除了定义标准的评审流程外 重点抓好各类工作产品的评审清单 明确 各类角色的评审职责和内容 起到了很好的效果 4 组织标准软件过程 根据公司业务目标及 CMM 要求 开目公司的组织标准软件过程按业务和管 理支撑划分 业务线有需求调研 需求分析 设计 编码 测试及发行 支撑 流程有需求管理 配置管理 项目管理 同行评审 培训等等 2 1 6 CMM L2 试运行 2003 年 6 月 23 日 9 月 15 日 CMM L2 试运行 试运行重点为 2 级的 6 个 KPA 即 SPP SPTO SQA SCM ISP 其中 SPP 中要求明确项目估计方法 提高项目计划的高效性和有效性 至 2003 年 7 月 CMM L2 的全部和 CMM L3 的 部分过程定义文件 如 SCM RM SQA PR 等过程 包括相关的指南 模板等支 撑文件逐步发布 投入试运行 2 3 3 CMM L2 正式运行 2003 年 9 月 16 日 CMML2 正式运行 在公司领导的肯定和支持下 正式运 行进展顺利 SEPG 组的 KPA Leader 作为规程制定和培训者 随时解决使用中 的问题 与此同时 sEPG 组组长一面稳定 CMM L2 的体系 一面抓紧制订和完 善 CMM L3 的体系文件 在正式运行期间 为保证流程运作 SEPG 组出台正式 运行管理条例 其中明确了具体要求 问题反馈渠道及奖惩条例 2 3 4 CMM L3 过程定义 2003 年 10 月 30 日 12 月 明确了组织级的业务过程框架图 过程定义主 框架图 培训规程 集成软件管理 SPE 规程等 对 SPP 和 SPTO 两个 KPA 中涉 及度量 估算 生命周期选型和裁剪 风险管理等方面进行改进 至 2003 年 12 月 包括 CMM L3 的流程文件定义基本完成 2004 年 1 月 3 月 SEPG 组在 咨询公司的指导下 对 CMML3 的 KPA 重点再次进行清理 找出差距 并进行了 相关改进 并建设完成组织财富库 过程财富库整体结构如图 2 6 18 图 5 6 由图 5 6 可见 公司的财富库包括六个 级子库 1 组织的软件过程数据库 简称过程数据库 内容包括两个三个子库 一 是 原始数据库 包含所有项目的初始数据 二是基础数据库 包括项圈的工作量 规模 运算参数等 三是项目管理文档库 主要存放公司项目所有的管理文档 2 组织的软件过程相关文档库 简称相关文档库 内容包括文档样例 知识库 培训资料库 风险库及工具库等