<ruby id="rxdll"></ruby><strike id="rxdll"></strike>

    <rp id="rxdll"></rp>
      <del id="rxdll"><meter id="rxdll"></meter></del>
      <pre id="rxdll"><font id="rxdll"></font></pre>
        <pre id="rxdll"></pre>
      <p id="rxdll"><thead id="rxdll"></thead></p><dl id="rxdll"><progress id="rxdll"><form id="rxdll"></form></progress></dl>

      <ol id="rxdll"><thead id="rxdll"><track id="rxdll"></track></thead></ol>
      <i id="rxdll"><dfn id="rxdll"></dfn></i>
      <font id="rxdll"><meter id="rxdll"></meter></font>

        <mark id="rxdll"><dfn id="rxdll"></dfn></mark>
        • 軟件測試技術
        • 軟件測試博客
        • 軟件測試視頻
        • 開源軟件測試技術
        • 軟件測試論壇
        • 軟件測試沙龍
        • 軟件測試資料下載
        • 軟件測試雜志
        • 軟件測試人才招聘
          暫時沒有公告

        字號: | 推薦給好友 上一篇 | 下一篇

        軟件研發的6sigma案例解析

        發布: 2008-9-03 09:20 | 作者: 茹海燕 | 來源: 測試時代采編 | 查看: 92次 | 進入軟件測試論壇討論

        領測軟件測試網


        對于故障分類進行的測量系統分析可采用離散測量系統分析。進行離散測量系統分析的基本步驟為:

        1、 在需要分析的故障中隨機抽取30個故障。
        2、 多個開發經理按故障分類標準共同確定每個故障的分類結果。(作為“真值”——本文作者)
        3、 讓參加故障分類的研發人員按故障分類標準進行分類。(作為“測量值”——本文作者)
        4、 一周后,讓參加故障分類的研發人員重新按故障分類。
        5、 進行離散測量系統分析,確定故障分類的準確性、重復性和再現性。

            如果通過測量系統分析,發現故障分類的重復性有問題,同一個研發人員對于同一個故障的判定結果不相同,則一般是研發人員自身素質的問題,采取的措施是需要加強對分類標準的學習。如果不同研發人員之間的再現性有問題,則一般是由于分類標準不明確造成,需要進一步明確分類標準。若重復性、再現性都符合要求通過,基本可以保證故障分類的標準定義是明確的,參加故障分類的研發人員的技能已經符合要求。
         實際上這種測量系統分析的方法并非第一次使用,去年我們研究所的一個綠帶項目做法極其類似,其原理如圖3所示。


         
        圖3 某綠帶項目的測量系統分析原理圖示


            這是一種典型的離散數據MSA的案例,在展示時,不少研發人員很吃驚:“原來MSA是可以這樣做的”,或者“原來是可以這樣得到量化數據的”。有很多人總是說研發過程中的數據量化不足,所以不適合做6sigma項目。其實不是6sigma不能用于研發領域,而是很多時候是我們沒有找到正確的方法而已。所以多思考、多動手,這個從小老師就教我們的話,在工作中一樣適用。

        三、如何提高執行力?

            記得前不久一位領導說:“我們公司從來不缺好的策劃,我們缺的是好的執行!避浖械膯栴}有些就是執行的問題,如規范的執行不嚴格,流程不合理等等。有人會問:“如果解決方案就是執行的問題,可以依據其影響力選擇合理化建議,或者團隊項目來解決,并不適合做6sigma項目!睂嶋H上,一來6sigma項目在開始時并不知道關鍵因子是什么,二來執行也不簡單,知道和做到是兩碼事,正如一個黑帶所言:“聽到你會忘記,看到你會記住,做到你才會明白!

            言歸正傳,這個案例是另一個黑帶項目《提高功能測試儀的軟件研發效率》,研發效率的定義為單位軟件的軟件開發和維護人力成本。這個項目的特點首先是非常細致,每一個步驟都按照6sigma的思路、方法完整、清晰地描述,可以作為初學者的樣板指導。然而對我而言,它更加重要的特點是它強大的執行力。在分析階段,已經確認了三個關鍵因子:

        1. 模塊化程度不高;
        2. 接口文檔不規范;
        3. 系統部、軟件部、硬件部溝通機制不健全;

            為了解決第一個問題,此項目提出建立10個模塊的目標,而目前它只有3個模塊;為了解決第二個問題,需要建立接口文檔的模板,但是更重要的是得到使用者的認可和操作;而第三個問題更是需要三個部門的最高長官——部長來親自溝通協調解決。以上這些,這個項目都做到了!怎么做到的?看看他的團隊成員,有研究所的所長,一個產品總經理,三個相關部門的部長,還有相關的所有科長、開發經理,以及部分開發人員,這樣的團隊架構,還擔心解決方案得不到執行嗎?

            案就是這么簡單,每個項目負責人都需要慎重選擇您的團隊成員,力爭讓每個人各盡所長。團隊中需要各種人員:首先是各方客戶代表,然后是善于分析者,善于操作者,善于協調者,以及流程主管或組織負責人等等。記得以前有個項目,成員基本上都是項目經理,這樣的團隊溝通倒是通暢了,可是說到做具體的事情,大家都沒有時間做,項目怎么進展呢?最后只有取消。想想有多少項目在到達終點之前倒下去,少有找不到解決辦法的,但是做出來的方案無法兜售給使用方,從而不能達到項目目標,這倒是常見。為什么?多數是因為團隊中沒有使用方的代表,強加的東西誰都不喜歡。

            也許有人會講,其實說到執行,就是要把領導拉進來,搞定了領導,讓領導出面推進執行和追蹤,就一切OK了。這話不對,因為我們不可能把領導搞定的,只會是領導把我們搞定:選擇項目一定要把握領導最關心的問題;即使不是最關心的,也要是在他的問題列表中位于前列的問題。如果你要做的就是領導非常想解決的問題,那么邀請他加入項目團隊,請他做一些追蹤工作自然順理成章;然而如果選擇的課題,在領導問題列表中遠沒有排在前列,讓他分散精力,同時消耗他的資源來做事,他自然不肯。這就是目前我們強調自上而下產生項目的原因。目前,我們公司在一定程度上還是人治的社會,承認這個現實,并且主動調整我們的做法適應現狀,才是做事的明智之舉。

            以上是我近期收集到比較典型和成功的軟件6sigma項目。然而我不得不承認,在公司已經完成的上千個項目中,軟件項目仍然是占非常少的比例。如果是因為沒有成功的案例,影響到大家的信心,或者不知道怎么入手來做,希望本文能夠為大家提供一些參考。CMM/CMMI與6sigma的結合和互相促進,在雙方領域內都是新課題,還有很大的拓展空間。目前我們公司也有不少黑帶身處EPG,選擇的項目正是這個新課題。一年之后,我們再來回顧,希望能有更大的突破,讓我們也在6sigma的歷史上留下光彩的一筆。

         參考資料:
        《讓失敗成為成功的母親》,徐金爐,2004-3

        延伸閱讀

        文章來源于領測軟件測試網 http://www.k11sc111.com/

        22/2<12

        關于領測軟件測試網 | 領測軟件測試網合作伙伴 | 廣告服務 | 投稿指南 | 聯系我們 | 網站地圖 | 友情鏈接
        版權所有(C) 2003-2010 TestAge(領測軟件測試網)|領測國際科技(北京)有限公司|軟件測試工程師培訓網 All Rights Reserved
        北京市海淀區中關村南大街9號北京理工科技大廈1402室 京ICP備2023014753號-2
        技術支持和業務聯系:info@testage.com.cn 電話:010-51297073

        軟件測試 | 領測國際ISTQBISTQB官網TMMiTMMi認證國際軟件測試工程師認證領測軟件測試網

        国产女主播精品_国产片婬乱18一级毛片视频_国产午夜激无码av毛片不卡_国产精品欧美久久久天天影院
          <ruby id="rxdll"></ruby><strike id="rxdll"></strike>

          <rp id="rxdll"></rp>
            <del id="rxdll"><meter id="rxdll"></meter></del>
            <pre id="rxdll"><font id="rxdll"></font></pre>
              <pre id="rxdll"></pre>
            <p id="rxdll"><thead id="rxdll"></thead></p><dl id="rxdll"><progress id="rxdll"><form id="rxdll"></form></progress></dl>

            <ol id="rxdll"><thead id="rxdll"><track id="rxdll"></track></thead></ol>
            <i id="rxdll"><dfn id="rxdll"></dfn></i>
            <font id="rxdll"><meter id="rxdll"></meter></font>

              <mark id="rxdll"><dfn id="rxdll"></dfn></mark>