软件研发的6sigma案例解析

  仪器信息网 ·  2011-04-14 21:33  ·  37176 次点击
一边是某咨询公司在项目管理培训中宣讲:“CMM2级企业不适合实施6sigma,应该等到CMM4级之后,度量体系比较完善时再进行。”一边是2004年世界软件工程大会上,各国专家达成共识:“CMM/CMMI与6sigma能够结合,互相促进”。我们怎么办?我以前主张:争执暂放一边,抓紧时间边实践边改进,否则结果就很可能是:“我们在进步,但是我们与竞争对手相比更加落后。”有些同事接受了我的看法,于是又有一问:“你有没有在软件中实施6sigma的成功案例?”6个月前我还没有,但是现在我有了几个典型案例,它们各具特色,让我们在此一一分享。
一、6sigma能帮助解决软件技术问题吗?
第一个项目是在去年年末,参加一个事业部的6sigma优秀项目发布会看到的。项目名称是《XX网管系统提高告警吞吐率》,问题是在大量告警上报时,UNIX服务器的告警处理吞吐率仅为8条/秒,同时占用CPU达90%,导致其它模块的操作基本上不能进行。用户对此非常不满,要求我公司尽快解决此问题,提高吞吐率到至少48条/秒,而系统成本不能有较大幅度增加。如何解决这个问题?一个解决方案是提高硬件的配置,从而提高处理性能,但是这样做会大大增加采购成本,而性能并不会有极大的提升,实际上降低了产品的可销性,这样的投入收益比极不合算,此方案被拒绝。项目组在花了大量时间和精力,仍然寻找不到合适的解决办法之后,想到了6sigma。大家知道,6sigma项目的选择就是那些“难度大、影响力大”的问题,于是这个项目组的成员将此问题立项,期待6sigma能在黑暗中带来曙光。
除去定义与测量阶段,此项目的分析思路是这样的:首先是头脑风暴鱼骨图,罗列所有大家能想到的可能原因;然后将这些原因按照告警的逻辑处理流程组织成FMEA,进行RPN分析,筛选出RPN值大于100的少数因素,作为潜在的关键因子;之后对这些潜在因子逐一试验,进行确认。整个项目的突破就出现在第一个因子的试验中,其试验数据如图1所示,横坐标表示输入的告警流量,纵坐标表示告警处理延时。图中的曲线显示有周期性的拐点,而在拐点之后,告警流量增加,服务器的处理延时反而有较大的降低。这个现象如果没有针对此原因的试验,没有这些数据是无法看到的。分析这个现象的原因,难不到我们的软件工程师,很快就得出了结论:TCP协议参数设置不当。修改此参数后,重新做同样的试验,得到数据如图2所示,可见其告警吞吐率基本上与输入流量呈线性关系增长,瓶颈已经消除。这不仅仅是确认了此因子是关键因子,同时也验证了改进措施的有效性。另外几个因子也是类似的,通过针对每一种可疑因子的试验,或确认此因子为关键因子,或筛选影响不大的因子;然后针对每个关键因子寻找技术上的解决办法,就更不在话下了。此项目的成功为公司创造了每年166万的收益。

0 条回复

暂无讨论,说说你的看法吧!

 回复

你需要  登录  或  注册  后参与讨论!