软件研发的6sigma案例解析

1、. 假设您不是在cnshu 网站下载此资料的, 不要随意置信. 请访问cnshu, 参与cnshu必要时可将此文件解密：.；软件研发的6sigma案例解析一边是某咨询公司在工程 HYPERLINK globrand/list/2-12.shtml t _blank 管理培训中宣讲：“CMM2级企业不适宜实施6sigma，应该等到CMM4级之后，度量体系比较完善时再进展。一边是2004年世界软件工程大会上，各国专家达成共识：“CMM/CMMI与6sigma可以结合，相互促进。我们怎样办？我以前主张：争论暂放一边，抓紧时间边实际边改良，否那么结果就很能够是：“我们在提高，但是我们与竞争对手相比更加

2、落后。有些同事接受了我的看法，于是又有一问：“他有没有在软件中实施6sigma的 HYPERLINK globrand/list/8-14.shtml t _blank 胜利案例？6个月前我还没有，但是如今我有了几个典型案例，它们各具特征，让我们在此一一分享。 一、6sigma能协助 处理软件技术问题吗？第一个工程是在去年年末，参与一个事业部的6sigma优秀工程发布会看到的。工程称号是，问题是在大量告警上报时，UNIX效力器的告警处置吞吐率仅为8条/秒，同时占用CPU达90，导致其它模块的操作根本上不能进展。用户对此非常不满，要求我公司尽快处理此问题，提高吞吐率到至少48条/秒，而系统本钱不

3、能有较大幅度添加。如何处理这个问题？一个处理方案是提高硬件的配置，从而提高处置性能，但是这样做会大大添加采购本钱，而性能并不会有极大的提升，实践上降低了产品的可销性，这样的投入收益比极不合算，此方案被回绝。工程组在花了大量时间和精神，依然寻觅不到适宜的处理方法之后，想到了6sigma。大家知道，6sigma工程的选择就是那些“难度大、影响力大的问题，于是这个工程组的成员将此问题立项，等待6sigma能在黑暗中带来曙光。除去定义与丈量阶段，此工程的分析思绪是这样的：首先是头脑风暴鱼骨图，罗列一切大家能想到的能够缘由；然后将这些缘由按照告警的逻辑处置流程组织成FMEA，进展RPN分析，挑选出RPN

4、值大于100的少数要素，作为潜在的关键因子；之后对这些潜在因子逐一实验，进展确认。整个工程的突破就出如今第一个因子的实验中，其实验数据如图1所示，横坐标表示输入的告警流量，纵坐标表示告警处置延时。图中的曲线显示有周期性的拐点，而在拐点之后，告警流量添加，效力器的处置延时反而有较大的降低。这个景象假设没有针对此缘由的实验，没有这些数据是无法看到的。分析这个景象的缘由，难不到我们的软件工程师，很快就得出了结论：TCP协议参数设置不当。修正此参数后，重新做同样的实验，得到数据如图2所示，可见其告警吞吐率根本上与输入流量呈线性关系增长，瓶颈曾经消除。这不仅仅是确认了此因子是关键因子，同时也验证了改良措

5、施的有效性。另外几个因子也是类似的，经过针对每一种可疑因子的实验，或确认此因子为关键因子，或挑选影响不大的因子；然后针对每个关键因子寻觅技术上的处理方法，就更不在话下了。此工程的胜利为公司发明了每年166万的收益。回想这个工程，又应验了一句老话：“处理难题经常是99的努力在于寻觅关键缘由所在，而修正只需求1的努力。6sigma本身并不提供技术处理方案，但是它的思绪引导我们向着正确的方向迈进，而数据是保证我们方向正确的重要根据。此工程虽然是软件工程，但是问题本身Y是可以明晰度量的，这也是它可以顺应6sigma特征，得以胜利的一个缘由。图1 某工程针对关键因子一的告警处置流量实验数据图图2 某工程

6、修正了协议参数后的告警处置吞吐率图二、客观判别的结果有压服力吗？这个案例是黑带工程，它从CQ分析的主要缺点类型之一：异常代码缺点率居高不下而来，这表达出担任人自动从失误中学习和提高的精神，也给很多依然为找不到适宜工程的同事一个启示：CQ库是一个很方便的工程宝库。此工程对于缺点分类的丈量系统分析，是离散数据做丈量系统分析的典型。在研发过程中，我们经常遇到“只可意会不可言传的情形，大家都是客观判别“拍脑袋，这样的分析如何具有压服力？客观判别不等于拍脑袋，这个工程可以作为参考，觉得上的东西经过制定一定的准那么，可以将大家的客观判别到达根本一致和准确的规范。以下摘自此工程担任人的总结文章：在确定了缺点

7、的分类规那么后，对于缺点进展分类，对于同一个缺点不同的研发人员分类能够出现不同的结果。出现这种问题能够是有两个缘由：(1)缺点分类的规范还不够明确，参与缺点分类的研发人员对于缺点了解不同。(2)参与缺点分类的研发人员没有才干按分类规范对缺点进展分类。处理的方法是在缺点分类前进展丈量系统分析，确认缺点分类规范能否曾经明确，参与分类缺点的研发人员能否具备了缺点分类才干。对于缺点分类进展的丈量系统分析可采用离散丈量系统分析。进展离散丈量系统分析的根本步骤为：1、 在需求分析的缺点中随机抽取30个缺点。2、 多个开发经理按缺点分类规范共同确定每个缺点的分类结果。作为“真值本文作者3、 让参与缺点分类的

8、研发人员按缺点分类规范进展分类。作为“丈量值本文作者4、 一周后，让参与缺点分类的研发人员重新按缺点分类。5、 进展离散丈量系统分析，确定缺点分类的准确性、反复性和再现性。假设经过丈量系统分析，发现缺点分类的反复性有问题，同一个研发人员对于同一个缺点的断定结果不一样，那么普通是研发人员本身素质的问题，采取的措施是需求加强对分类规范的学习。假设不同研发人员之间的再现性有问题，那么普通是由于分类规范不明确呵斥，需求进一步明确分类规范。假设反复性、再现性都符合要求经过，根本可以保证缺点分类的规范定义是明确的，参与缺点分类的研发人员的技艺曾经符合要求。实践上这种丈量系统分析的方法并非第一次运用，去年我

9、们研讨所的一个绿带工程做法极其类似，其原理如图3所示。图3 某绿带工程的丈量系统分析原理图示这是一种典型的离散数据MSA的案例，在展现时，不少研发人员很吃惊：“原来MSA是可以这样做的，或者“原来是可以这样得到量化数据的。有很多人总是说研发过程中的数据量化缺乏，所以不适宜做6sigma工程。其实不是6sigma不能用于研发领域，而是很多时候是我们没有找到正确的方法而已。所以多思索、多动手，这个从小教师就教我们的话，在任务中一样适用。三、如何提高 HYPERLINK globrand/list/2-6.shtml t _blank 执行力？记得前不久一位指点说：“我们公司从来不缺好的谋划，我们缺

10、的是好的执行。软件中的问题有些就是执行的问题，如规范的执行不严厉，流程不合理等等。有人会问：“假设处理方案就是执行的问题，可以根据其影响力选择合理化建议，或者团队工程来处理，并不适宜做6sigma工程。实践上，一来6sigma工程在开场时并不知道关键因子是什么，二来执行也不简单，知道和做到是两码事，正如一个黑带所言：“听到他会忘记，看到他会记住，做到他才会明白。言归正传，这个案例是另一个黑带工程，研发效率的定义为单位软件的软件开发和维护人力本钱。这个工程的特点首先是非常细致，每一个步骤都按照6sigma的思绪、方法完好、明晰地描画，可以作为初学者的样板指点。然而对我而言，它更加重要的特点是它强

11、大的 HYPERLINK globrand/list/2-6.shtml t _blank 执行力。在分析阶段，曾经确认了三个关键因子：1 模块化程度不高；2 接口文档不规范；3 系统部、软件部、硬件部沟通机制不健全；为理处理第一个问题，此工程提出建立10个模块的目的，而目前它只需3个模块；为理处理第二个问题，需求建立接口文档的模板，但是更重要的是得到运用者的认可和操作；而第三个问题更是需求三个部门的最高长官部长来亲身沟通协调处理。以上这些，这个工程都做到了！怎样做到的？看看他的团队成员，有研讨所的所长，一个产品总经理，三个相关部门的部长，还有相关的一切科长、开发经理，以及部分开发人员，这样的

12、团队架构，还担忧处理方案得不到执行吗？案就是这么简单，每个工程担任人都需求慎重选择您的团队成员，力争让每个人各尽所长。团队中需求各种人员：首先是各方客户代表，然后是擅长分析者，擅长操作者，擅长协调者，以及流程主管或组织担任人等等。记得以前有个工程，成员根本上都是工程经理，这样的团队沟通倒是通畅了，可是说到做详细的事情，大家都没有时间做，工程怎样进展呢？最后只需取消。想想有多少工程在到达终点之前倒下去，少有找不到处理方法的，但是做出来的方案无法兜售给运用方，从而不能到达工程目的，这倒是常见。为什么？多数是由于团队中没有运用方的代表，强加的东西谁都不喜欢。也许有人会讲，其实说到执行，就是要把指点拉

13、进来，搞定了指点，让指点出面推进执行和追踪，就一切OK了。这话不对，由于我们不能够把指点搞定的，只会是指点把我们搞定：选择工程一定要把握指点最关怀的问题；即使不是最关怀的，也要是在他的问题列表中位于前列的问题。假设他要做的就是指点非常想处理的问题，那么约请他参与工程团队，请他做一些追踪任务自然顺理成章；然而假设选择的课题，在指点问题列表中远没有排在前列，让他分散精神，同时耗费他的资源来做事，他自然不肯。这就是目前我们强调自上而下产生工程的缘由。目前，我们公司在一定程度上还是人治的社会，成认这个现实，并且自动调整我们的做法顺应现状，才是做事的明智之举。以上是我近期搜集到比较典型和胜利的软件6sigma工程。然而我不得不成