CMM实施手记(页 1) - 行业应用项目实施 - LoveUnix 最强AIX小机技术论坛,UNIX,Linux,存储,数据库,中间件,开发,管理

2003-9-28 18:39 threehair

CMM实施手记之一--国内软件业对CMM认识的阶段性 作者：雅行 2001-10-18 【来源：AMT】 初识CMM，恐怕很多人都会被其陌生的理论结构、枯涩艰奥的文字搞的一头雾水。CMM能否成为医治中国软件业顽疾的灵丹妙药？CMM适合中国国情吗？CMM适合小型软件企业吗？CMM与我们熟悉的ISO9000有何不同？这些问题大多困扰过前期的CMM关注者。 不同的思考，透露着不同的心态：怀疑、担心、观望…… 这时需要“打破神秘，从头学起”。 大凡我们引入西方的新的理论，总是要经历一个神秘期，“众说纷纭，找不着北”。原因在于，这个阶段大家的研究都有限，实施经验更是缺乏，谁都不能说服谁。但过分空谈会误事。尽快冲破迷雾，仔细学习、研究和使用。不管是想实施还是想批驳，都要先把人家的东西弄明白，所以要：“打破神秘，从头学起”。 随着对CMM的学习和认识的深入，眼前的神秘感渐渐散去。“就是订制度么，我们其实并不需要知道为什么，只需要有人告诉我们怎么做”、“跟ISO 9000没有本质差异”...... 。是不是感觉：可以用很短的话，把CMM的精神概括出来？ 批判的学习不是坏事，只是不能走极端。失去神秘感，CMM便由重变轻。可CMM本来就声明自己是common sense。 CMM的价值本来没有变化， 只是我们的认识在变化罢了。 国内软件业的最缺正是管理，CMM恰好可以补上我们的不足。在质量三角形中，技术当然是非常重要的，技术和人这两个因素是影响产品的先决的条件。而过程是影响产品的第三个重要因素，而且随着产品规模和团队规模的增大，以及技术的成熟化，过程瓶颈越来越突出。有人说，“缺乏规范的过程正是国内软件企业的软肋”。 质量三角形： <img src='http://www.sawin.com.cn/doc/SE/SPI/cmmimp1.gif' border='0' alt='user posted image' /> CMM的一个重要价值在于它把众多的common sense整合成完整的知识体系，CMM中贯穿着抓主要矛盾的哲学思想，它的分级思想是与ISO9000的一大不同，就是承认资源总是相对不足的，问题不可能一下子全解决，要分几步（等级）走，每一步要抓一些关键的因素（KPA）。再比如他的先做管理后做工程的思想，用Humphrey的原话来解释："看起来，定义和实施一个工程过程似乎要比定义和实施管理过程容易（特别是在技术人员的眼中），但是如果没有管理过程的规定，工程过程很可能会成为进度和成本等压力的牺牲品"。所以在L2里面全部是项目管理的过程，而产品工程（SPE）则放到了L3。我认为，CMM作为SEI许多专家多年研究的结晶，其中的丰富内涵有待于我们学习和实践的过程中不断认识。它一定会不断的给以我们启示的。 CMM是金矿，乍一看就是一堆砂，但其中蕴藏着金子。 要想得到它，需要付出很大的努力！ CMM不是个别人的事，组织中每个人都应不同程度的参与。每个人都要想想我应该尽到什么职责，要“调整心态，从我做起”。 对于高层经理来说，需要正确认识CMM实施带来的额外工作量，配备必要的资源，CMM实施最直接的后果就是带来了很多的事务性管理工作，这要求设立一些专职的角色，如SQA、SCM，或者配备适当的工具，把相应的工作量从项目经理的身上分离出来。否则一旦技术和管理展开竞争，牺牲的肯定是管理；高层管理有必要改变自己的管理习惯，原来很多事都口头裁决，现在需要先看有没有规范，如果有，就尊重规范，规范就是文档化的组织意志。最后，实施体系就是打破旧平衡，建立新平衡，这个过程中体系会相对混乱，对正在运行的项目会产生一定的影响，甚至于在个别企业中，出现技术人员由于适应不了新的工作方式而离职的例子，这些情况，高层管理者都应该心理上有所准备，对CMM抱有坚定的信心。 对于项目经理来说，要改变技术本位主义，国内的项目管理，大多是技术出身，没有接受过系统的管理知识，心态多是技术带头人而已。CMM本质就是解决管理问题，所以对项目经理来说，做CMM就是，从技术上分出一部分时间来做管理，管理者需要主动调整心态以适应新的情况。 项目经理的从我做起还包括，他们是沟通项目层和管理层的桥梁，对于CMM的贯彻起着承上启下的作用。贯彻CMM不可能奢望全体人员一致拥护，但是项目经理的积极参与却是必要的。CMM实施的内部驱动有两个：高层经理和项目经理。高层经理通过资源和政策驱动，项目经理以实际问题驱动。项目经理要做过程改进的“明白人”，认识到过程改进工作正是为项目服务的,而不单单是被动的服从高层经理的安排和质量经理的规划等等。 对于质量管理人员来说，要增强服务意识，质量部门是主要的制度制定者，但这并不意味着质量管理人员就应该高高在上。一线开发者是为用户服务的，而职能管理部门又是为一线服务。服务意识的增强体现在深入了解项目经理对过程改进的需求，根据实际需要驱动质量工作重点，争取在局部先有所突破。质量宣传要密切接触一线人员，采取多种灵活方式，多了解反馈，这可能比会议形式的宣贯更有效。过程改进需要不断地成功来推动后续的改进。这样，SPI项目要求进行很好的策划。问自己：何时何种方法向大家证明改进已显现效果？ 开发测试人员的“从我做起”包括改变以自我习惯为中心的做事方式，适应遵循过程规范的工作习惯。只有大家关注过程规范，它才有可能得到不断优化和成熟。避免“两张皮”。开发人员还需要通过自身努力，借鉴PSP的方法提升个体软件能力，这是个自我工程，须以个人的上进心为动力等等。 总之，对于CMM，前期“打破神秘，从头学起”后期“调整心态，从我做起”，前期重在学，深入学有利于打破神秘，尽快结束争论和观望；后期鼓励做，要调整心态，改变习惯，从自身开始，方可获得成功。 CMM在中国是个新事物，需要辩论、需要研究、更需要脚踏实地的去做。 我相信只要实事求是的去做，总会有所裨益的。

2003-9-28 18:41 threehair

CMM实施手记之二：以项目形式管理SPI 北京SPIN 雅行 (本文曾于2002年7月刊载于《计算机世界》周报第25期F5、F6版) 国外的一项有关SPI的调查表明，没有很好的对过程改进进行管理造成了至少70%以上的改进失败或挫折！当我们问自己如下问题的时候，能否迅速给出满意的答案—— SPI强调管理，自身是如何管理的？ SPI提供方法论，自己的方法论如何？ SPI说做事要有计划性，自身计划性如何？ SPI倡导风险管理，自身的风险被很好的识别了吗？ 本文试图给出一种对SPI自身进行管理的方法：“以项目形式管理SPI”。 以项目形式管理SPI通常分为如下五步骤： 第一步体系诊断 第二步方案设计 第三步项目策划 第四步过程管理 第五步项目验收总结 第一步体系诊断 诊断是一切过程改进和管理咨询的前奏，对于不以取证为目的的软件过程改进来说，这一步尤其重要。 我们常讲“理论联系实际”，诊断就是实现此种联系的必要步骤。 “过程诊断”和“过程审计”有着某种程度的相似性，通常的方式为面谈、文档查阅、检查表填写等形式。 典型的基于CMM的检查表举例如下： 等级二可重复级提问单 软件项目跟踪和监督 典型的SPI诊断开销大约为2-3人日，这和组织的成熟度，组织的历史长短，管理和业务的复杂度都有关系。 对诊断过程的漠视是自顶向下改进策略的最大弊端。 第二步方案设计 在了解了组织、项目的实际状态以后，就可以有针对性的提出解决方案了，这一步骤称为方案设计。 面向中小企业解决方案范例之一： <img src='http://www.sawin.com.cn/doc/SE/SPI/cmmimp2-2.gif' border='0' alt='user posted image' /> 在以上方案中，我们可以看到主要的元素来自于CMM、SEBOK（软件工程）、good practice (最佳实践)。这种结果是与该企业的如下现状相适应的： 首先，该企业没有形成基本的软件工程流程； 其次，项目没有生命周期的概念，无明确启动和验收点，正如其项目经理所言“我们的项目结束点要等到下一起项目已经开始，本期项目不得不结束了，才会出现”； 再次，该企业整体管理基础薄弱，资源提供不充分，这种情况下，在大企业顺理成章的事情可能在这里都是问题，所以需要大量的变通和折衷策略，这些都被归纳在GOOD PRACTICE 中。 诸如此类的方案设计，存在两个裁减特征，一是横向裁减，可以在打破现有知识体系的基础上，创造性的构建新体系；其二是纵向裁减，比如对于CMM的具体KPA，也可以分两步或更多步来达到要求。所有这些裁减都会带来更多的灵活性。 SPI方案的编制需要涵盖如下内容： 〉本组织软件过程改进的历史 〉过程诊断 诊断方法 诊断结果和差距分析 〉改进方案 总体目标 总体工程化管理系统设计 详细改进措施 〉资源需求预测 〉计划进度概要 前提和承诺 资源需求预测 〉风险 〉里程碑 附录：过程诊断提问单和原始数据 第三步项目策划 方案得到认可后，可启动项目策划。SPI的项目策划要求与其它项目的策划要求并无多少差异，主要是编制一份项目计划，有如下内容： 〉项目目标 整体目标 本阶段目标 〉假定和约束 〉项目组织 组织结构 接口关系 报告关系 责任矩阵 〉项目进度跟踪方式 〉项目里程碑 〉交付物 文档编制 人员培训 〉风险管理 〉项目激励 〉项目验收 值得一提的SPI风险管理，SPI典型风险及化解策略如下： <img src='http://www.sawin.com.cn/doc/SE/SPI/cmmimp2-3.gif' border='0' alt='user posted image' /> 计划进度则使用诸如MSP之类的工具进行计划和跟踪： <img src='http://www.sawin.com.cn/doc/SE/SPI/cmmimp2-4.gif' border='0' alt='user posted image' /> 第四步、过程管理 计划制定好以后，还要对 SPI的的实施过程进行定期和不定期的过程跟踪，才能确保及时纠正和预防计划执行中的偏差，最终达成项目的成功。 一般可通过“周”和“里程碑”两种周期进行跟踪，周跟踪的内容为进度、完成量、问题、风险，通过周报和周会的形式进行；里程碑跟踪的内容为进度、工作量、人力开销、风险等，还要对项目管理的经验和教训进行总结，里程碑也是识别典型案例和收集最佳实践的良好时机。里程碑跟踪活动通常包括“里程碑总结报告编制”和“里程碑总结会”两种形式。 第五步、项目验收总结 对于自底向上的软件过程改进，并没有标准的验收准则可利用，这要求组织根据自身裁减的体系编制自己的验收准则，验收准则有定性和定量的不同形式，定量适合于有一定管理基础的组织，需要有足够的、可信的、可比的历史数据。但多数中小软件企业可能在起步阶段只能选择定性验收的方式，这种定性验收方式常常是“先僵化、在固化、后优化”理念的一种体现。 定性的检查表可能会由如下问题组成： 项目是否有明确的启动点？ 项目启动后是否对项目进行了策划？ 项目计划是否被周期性维护？ 是否在策划阶段识别了项目的配置项？ 集成测试通过后是否对代码进行了标定？ 修订后的配置项是否被重新审核？ SQA是否按照规定的周期对项目组进行过程审计？ 等等 项目验收后，进行SPI项目的最后一项活动——项目总结，需要提交书面报告并召开总结会，项目总结中要统计汇总SPI本身数据、进度、开销、偏差及分析，还要识别和共享经验教训。这一阶段的工作将为以后的SPI持续改进打下良好的基础。SPI将进入下一个改进循环。 总之，以项目形式管理软件过程改进，特别有利于提高团队凝聚力、规避风险、明确目标、提供效率，而且由于SPI项目组与其它项目组形成了一种矩阵式组织结构，可以有效促进组间交流。所以对于SPI这样一件比较复杂的工程来说，以项目形式进行管理将是成功的重要保证。 下两期预告： “之三：软件过程改进利益分析” “之四：管理体系设计三步曲” [说明：本系列文章由作者在“北京软件过程改进沙龙”的演讲整理而成]

2003-9-28 18:42 threehair

CMM实施手记之三：软件过程改进利益分析 北京SPIN 雅行 ……..基于上述状态，公司特别召开了SPI状态评估会…… ,在会上，只有密切参与SPI实施的部门总工持坚定的支持态度，市场总监担心客户的抱怨，副总则探询SPI能给我们带来什么好处？SPI主管发现，他不得不在SPI已进展到一半的时候回答一系列最基本的问题：为什么要实施SPI？SPI能给各方面带来什么好处？这些好处何时见效…….. 这就是典型的利益分析缺失症！ 利益分析缺失将直接导致对变革的反对。 人们为什么会反对变革？ 原因有三：不了解、不愿意、不会做 之一、不了解目标，感到迷茫，从而产生恐惧，为不了解； 之二、损害了既得利益，为不愿意； 之三、与原来的做事方式有差异，不知道怎么做，为不会做。 分析上述三种原因，可知前两种原因都是与利益相关的，事实上，利益分析是过程改进的重要前提，而实践中却常常被忽视。 SPI是变革管理的一种，凡是变革管理都需要动力- 障碍分析，而利益分析又是动力-障碍分析的前提。 利益分析应该从公司管理层、部门管理、项目经理、项目成员、客户五个层面展开。 利益分析典型案例 —— 只有一部分的利益为可短期获得，而最关键 的项目管理三要素的改善却难以在短期显现 例一：某中小型软件企业的利益分析表如下 环境：某小型软件企业，4个项目组，软件部门人员30-40人，具有1年的基于ISO9000的SPI史。 <img src='http://www.sawin.com.cn/doc/SE/SPI/cmmimp3-1.gif' border='0' alt='user posted image' /> 符号：短期可获得：S 长期可获得：L [短期利益为一个SPI周期，也是一个软件项目周期] 直接受益者：D 间接受益者：U 不受益者：N n 对利益周期的分析： 从表中看出：只有一部分的利益为可短期获得。而最关键的项目管理要素（质量、进度、成本）的改善却难以在短期显现，原因如下： 1、产品质量通常要到项目结束后一段时间才能显现出来 2、由于增加了一定量的管理和文档工作量，通常在CMM第二级产品交付的时间反而增长，再加上计划不能很好的估算，所以进度看起来往往并没有改善。 3、由于人力成本为软件的主要成本，进度因素也导致了成本的不理想。 所以，对于1、5、6、7、9这些方面要特别加以关注，这是你可以在一个项目周期内可以向别人表明SPI成效的重要方面。 n 对不同角色获益比例的分析： <img src='http://www.sawin.com.cn/doc/SE/SPI/cmmimp3-2.gif' border='0' alt='user posted image' /> 上图分析显示： 1、从SPI中获得直接利益最多的是公司管理层，获益最少的是项目组成员和客户。 2、虽然设置了不获益的选项，但是由于SPI的根本目标是提升项目成功的几率，所以，实施SPI可以使项目干系人获得多赢的结果。差别只在于获利的时间长短。 3、多数间接利益很难有稳定的结果，存在着有趣的矛盾现象，比如5、6、7、9这些利益要素，如果以局部和短期的观点来看，这些不是利益，而是风险和损失，反之，站在整体和长期的角度则成为利益。这只取决于人员的素质，所以SPI教育培训的焦点之一就是要求人们具备全局观和注重长远利益。 4、最后需要特别说明的是，不同的企业、不同的部门、不同的人员素质、项目的不同成熟阶段可能得到截然不同的统计结果。比如有的公司的软件部门主管希望透明，另外一些则相反。有的PM不希望成员频繁流动，而另外一些则希望这样。取决要素在于企业利益、部门利益和个人利益到底有多大程度的一致性。这也就是很多SPI人员转而去关注HR的缘故。 n 本节启示： 1、既然公司作为最多的直接利益获得者，SPI应该首先从公司获取支持； 2、既然有些层面的利益需要间接和长期才能获得，则要求SPI推进者要善于分析潜在利益，并向项目干系人不断描绘VISION。 3、公司能够通过什么样的利益机制使得公司的目标和个人的利益能紧密捆绑，短期利益和长期利益合理平衡，看开来对SPI的成功也是至关重要的。 为什么要尽早进行利益分析？ &Oslash; 有利于建立共同远景VISION &Oslash; 有利于识别动力和障碍 &Oslash; 有利于设计针对性的沟通和培训计划 &Oslash; 有利于SPI风险预防 这里提供一个案例，读者不妨进行一个分析： 例二案例：SPI人员的困惑 某软件企业2000年5月遇到了软件部门管理人员大面积辞职的情况，软件团队濒临崩溃，给企业造成巨大的损失。在此情况下，该企业决定实施SPI。初期SPI获得了公司极大的支持，不仅SPI成为公司第一战略，而且在项目目标中，“遵守过程”具有高于“完成客户需求”的优先级。 SPI推进了一段时间后，先后遇到了如下问题，一是部分PM的抵触；二是客户提出了不少的抱怨。公司决定趁季度绩效考评的机会，调查一下项目组对SPI的意见。调查结果发现，项目组也对SPI有很多抱怨。这些抱怨包括： ** 项目经理成天在写计划，影响了开发（用户抱怨） ** SPI人员比较讨厌，活象FBI（用户抱怨） ** SPI部门负责印刷的纸媒介的体系文件过于粗糙，影响公司形象 ** 体系文件中有错字 ** 周报的文件名重复使用日期标识（内文中也有日期标识） ** 项目前期没法做计划，建议在概设完成后做计划 ** SQA总是检查我们，那么谁来检查SQA ** SPI人员太顽固，不听项目组的建议 ** 体系文件大量的缺乏例外程序，实际情况难以遵循 ** 建议SQA的审计报告要经过被审项目经理的“同意”再发布 基于上述状态，公司特别召开了SPI状态评估会，市场部主管和开发部主管和副总们都出席。在会上，只有密切参与SPI实施的部门总工持坚定的支持态度，市场总监担心客户的抱怨，副总则探询SPI能给我们带来什么好处？SPI主管发现，他不得不在SPI已进展到一半的时候回答一系列最基本的问题：为什么要实施SPI？SPI能给各方面带来什么好处？这些好处何时见效…….. 思考问题: 您认为该企业SPI实施中存在什么样的不足？ 您认为应该如何对SPI人员进行业绩考评？ 您认为SPI推进中应该如何有效处理与客户的关系？ SPI利益分析是非常必要的，但也应该注意不要把SPI利益无限扩大化，姑且称为：SPI万能论。 为什么要避免SPI万能论？ 前已述及，SPI利益分析的目的是为了澄清理念，获取尽可能多的人的支持。但是也要防止过度宣传，SPI不是万能的，不能解决所有的问题。我们以配置管理来说明这个问题。 例三组织财富管理的风险 <img src='http://www.sawin.com.cn/doc/SE/SPI/cmmimp3-3.gif' border='0' alt='user posted image' /> 上图显示了配置管理的三种模式： 第一种：是自己开发的产品自己保管，称为“私房软件； 第二种：产品全部开发完成，验收后交付公司； 第三种：各阶段工作产品完成后，经过QC验证后被纳入基线库,全部阶段产品完成后，被纳入产品库。 显然，从第一种到第三种模式，公司产品流失的风险越来越减小。这很好的体现了过程的重要性。但是，假如有人问： 1、私房软件一定就有风险吗？ 2、模式三一定就没有风险了吗？ 仔细一想，发现答案很另人泄气，事实上，SPI并不能解决软件管理的全部问题，比如，对于第三种模式，存在者QC这样的角色，CMM虽然确保了这些人在开展工作前被很好的培训，但是培训保证了资质，有资质不见得就有能力，有能力还的看工作态度。再比如企业中有没有合格的同行评审人员，即使有，这些人愿不愿意不留情面的识别别人的错误？这些，都是光凭过程解决不了的。 n 上述案例给我们的启示是： 1、不可把一切的寄托在SPI上，SPI只能解决SPI应该和能解决的问题 2、实施SPI的同时，要注意人力资源管理和企业文化变革方面的内容，特别是对于中小企业。事实上，很多SPI人员在推进SPI到一定阶段后，不约而同的回过头来补HR方面的课。 3、夸大SPI的好处，最终会SPI的实施带来不良后果。 从利益分析说明为什么要实施SPI？ SPI的最根本利益其实在于，他能够极大的提高项目成功的几率，这是大家都追求的。当然需要明确定义这里的“项目成功”的含义，不是客户要求三个月完工，最后按时交工，就是成功。而是综合平衡进度、交付后质量、成本等若干要素后所达到的最优状态。 在项目管理三要素中，项目干系人通常会把进度当作第一目标，结果相当多赶进度完成的项目，在交付后面临者大量的后续修改，甚至推翻重来。如果把这部分开销算到项目中去，项目早已失败的一塌糊涂了。 对大量失败项目的统计结果表明，最大的原因在于缺乏过程或者没有很好的遵循已定义的过程。我们知道决定项目质量和生产率的要素有人、技术和过程，如果借用木筒的比喻，过程不见得是其中最宽的一条，但是当前它是最短的，所以它决定着木桶的盛水量。我们迫切的需要SPI，就是要把最短的木条尽快补上去。 只有基于良好的过程，人和技术才能发挥出最大的威力。 下两期预告： “之四：管理体系设计三步曲” “之五：选择好PM等于一半的成功” [说明：本系列文章由作者在“北京软件过程改进沙龙”的演讲整理而成]

2003-9-28 18:44 threehair

CMM实施手记之四：体系设计三步曲 北京SPIN 雅行 人们常常采用“拿来主义”的方法来完成体系“设计”，就是拿别人的成套模板改改来用。我从前在某企业时，曾有一位顾问师负责给写质量手册，当我阅读时发现，竟有一半的部门和角色那个企业根本没有！这是“拿来主义”的极致。那么体系设计有没有方法？ 通过软件过程改进，得以构建一套系统的工程化管理体系（以下简称SEMP），该体系是以文档形式来体现的，这些文档分三类，其关系如下： SEMP体系文档关系 <img src='http://www.sawin.com.cn/doc/SE/SPI/cmmimp4-1.gif' border='0' alt='user posted image' /> 体系设计过程中，应依次采取三种不同的设计方法：概要设计、详细设计、度量设计。 分别输出三类文档：总体文档、过程文档、支持文档。 总体文档描述描述系统总体，指出系统设计依据、总体目标、方针、策略和系统概貌描述；在ISO9000中称为质量手册；过程文件描述具体的活动、谁、什么时候、做什么事，这是系统的主体部分；支持文档的种类非常多，提供具体的方法、规范、模板和工具。比如“JAVA编码规范”、“配置管理工具使用指南”、“项目开发计划模板”。 概要设计 体系的概要设计要完成如下任务：， &Oslash; 总体方案概述：简述实施方案 &Oslash; 总体策略：自底向上还是自顶向下，一步走还是分步到达 &Oslash; 远景目标：在比较长的一个期限内，比如1-2年，达到什么样的状态 &Oslash; 阶段目标：分解段实施，每阶段的目标 &sup2; 第一阶段 &sup2; 第二阶段 &Oslash; 设计依据 &Oslash; 流程概述：设计哪些流程？各流程完成什么活动的简要叙述，各流程的相互关系 &Oslash; 生命周期：流程相对与项目生命周期、产品生命周期的关系 &Oslash; 度量系统：度量需要达到的总体目标，源数据的获取、处理、报告、周期、角色。 &Oslash; 文档图例：体系特别是过程文件的图例说明 &Oslash; 责任矩阵：体系的面向角色的职责分解 &Oslash; 体系文件清单：体系各层次文件的名录汇总 关于SPI策略选择已有专述论及，（参见《软件过程改进总体策略选择》） 总体文档不仅仅明确了系统设计的总体，而且还可以极大方便使用者快速把握系统概貌。需要特别一提的是责任矩阵，过程文件通常是以过程为中心描述的，各角色的职责分散在不同的过程文件中，这样难以获得具体角色在体系中究竟何时何地做何事的信息。在总体文档中设置责任矩阵，此问题将迎刃而解。 在此阶段，将选择和裁减有关知识域构成体系设计的理论依据。 可利用的知识域—— &Oslash; CMM：能力成熟度模型，由美国卡内基梅隆大学软件工程研究所提出 &Oslash; ISO9000：国际标准，不只适用于软件 &Oslash; SEBOK：软件工程知识体系 &Oslash; PMBOK：项目管理知识体系，美国项目管理协会提出 &Oslash; PSP：个体软件过程 &Oslash; TSP：小组软件过程 &Oslash; P-CMM：人力资源能力成熟度模型 &Oslash; Best practice：介于理论和实践之间的结合层，经验性的知识，散布与各种著作和报道中 上述知识域多数自成完整系统，要想不拘泥于上述体系，希望获得更灵活设计，需要设计者对上述体系都有着深入的掌握。尤其要对CMM、ISO9000、项目管理知识体系的相互关系进行透彻解析，这些已经有专门的文章论述，在此不赘述。 设计需要考虑的三个关键要素是：诊断识别出的组织的实际需求、组织的资源能力、管理基础和成熟度。 大多数情况下，以下要素是优先需要被重视的： &Oslash; 配置管理 &Oslash; 项目计划 进一步扩展后可能会包括： &Oslash; 项目跟踪和监控 &Oslash; 项目启动 &Oslash; 项目收尾 再扩展： &Oslash; 软件质量保障 &Oslash; 同行评审 &Oslash; 培训。。。。。。 在实际情况中，存在很多复杂情况，缺乏基本软件工程的企业可能需要在实施配置管理的同时实施基本软件工程甚至软件技术，避免配置管理的垃圾进垃圾出问题。不少软件企业的部门一级没有足够权利，造成对SPI的推进乏力，可能需要先解决责权明晰这个基本问题。 样例：体系概要设计输出（部分） <img src='http://www.sawin.com.cn/doc/SE/SPI/cmmimp4-2.jpg' border='0' alt='user posted image' /> 详细设计 体系的详细设计阶段需要实现概设中裁定的一系列过程。过程定义有着非常标准的模板： &Oslash; 目的：定义本过程的目的 &Oslash; 角色：本过程中涉及的角色及其职责 &Oslash; 入口准则：什么条件会触发本过程的启动 &Oslash; 输入：文档、资源、数据 &Oslash; 过程步骤：本过程有关的处理步骤 &Oslash; 输出：文档、资源、数据 &Oslash; 出口准则：什么条件会触发本过程的结束 根据需要还可以增加如下的条款，以方便使用： &Oslash; 度量： &Oslash; 过程监控方法： &Oslash; 工具技术和方法： &Oslash; 差距分析： &Oslash; 过程改进历史： &Oslash; 相关过程： &Oslash; 引用摸板： &Oslash; CHKLST： 过程步骤的描述可以采用任何的形式，但是使用图形可以极大的方便阅读。参加下例—— 样例：用图形方式描述过程 <img src='http://www.sawin.com.cn/doc/SE/SPI/cmmimp4-3.gif' border='0' alt='user posted image' /> 一些良好验证过的方法和实践，不妨列入“工具技术方法”中，会对使用者提供不少方便。 度量设计 度量设计常采用所谓GQM方法，即goal-question-measurement，goal同样是从诊断得出的需求而来，通常需要优先采集的度量数据包括：代码缺陷、进度跟踪数据、开销跟踪数据。 以下两例显示GQM的使用方法： 样例：有关缺陷的度量设计 G：能否有重点的消除缺陷 Q：缺陷数据是否被记录 缺陷数据是否被分析 M：文档：评审报告 代码：问题报告单 样例：对SQA工作量度量的设计 G：了解SQA的开销，最终统计新增管理活动的费效比 Q：是否知道SQA过程审计的开销？ 是否知道SQA参与评审的开销？ 是否知道SQA进行培训的开销？ M：审计CHKLST 同行评审报告 培训签到表 样例：对产品缺陷的度量设计输出 <img src='http://www.sawin.com.cn/doc/SE/SPI/cmmimp4-4.gif' border='0' alt='user posted image' /> 度量设计的输出将体现在各类工作表单、过程数据库中，而度量总体的描述可以纳入总体文档中，方便阅读者全局把握。 体系经过概要设计、详细设计、度量设计三步并获得评审通过，标志着文档编制阶段结束。 [说明：本系列文章由作者在“北京软件过程改进沙龙”的演讲整理而成]

页: [1]

查看完整版本: CMM实施手记