Code inspection 的代價 (continued)

本來應該寫在 Code inspection 的代價 一文的意見中,但考慮到內容比較多,故還是以一文說明。

看了許多專家的看法,我也提出自己的看法。我的假設是這樣的
  1. Programmer 的月薪為 35,000/月
  2. 資深的 inspector 月薪為 60,000/月
  3. 速紀員可能是系統助理,月薪較低,為 28,000/月
  4. 主席的月薪為 60,000/月
雖然一天工作八小時,但扣掉一些喝水、聊天的時間,一天工作有六小時應該不錯了,所以
這些角色分別的時薪應該分別為 182 (35000/((30-8)*6)), 312, 145, 312。真的是蠻低的吧。
  • overview 階段 review 的速度為 500/statement, 所以共需 2 小時,假設 overview 的階段 scriber 不需參加,則成本為:(1*182+2*312+312*1)*2 = $2,236
  • individual preparation 階段 review 的速度為 125/statement, 所以共需 8 小時,因為此階段 scriber 與 chair 不需參加,則成本為:(1*182+2*312)*8 = $6,448
  • inspection 階段每個人都要參加,因為 review 的速度為 90/statement, 所以共需 11 小時,則成本為:(1*182+2*312+145*1+312*1)*11 = $13,893
  • follow up 的階段進行除錯,假設錯誤率為 3%,亦即有 30 個錯誤,而程式員除錯的效率為每個錯誤需要五小時除錯,則需要 5*182*30=27,300。
加總以上的成本則共為 $49,877。但這可不是這 1,000 行程式的成本,這僅是 code inspection 的成本,不包含分析、設計、實作與後續動態測試的成本啊。光這樣看來,每行程式的價值就有將近 50 元,Szuwulin 所言『行一塊錢』似乎是少了些。

問題是台灣很少執行 code inspection 的動作,而是以後續的動態測試才取代。我們知道,動態測試是治標不治本的方法,它能找到的錯誤是比較少的。假設有有一半的錯誤沒有在動態測試中被找出來而不小心流到使用者手上,那代價可能很難估算。第一:如果造成客戶的業務損失; 第二:維護階段除錯的效率差很多,通常以平均10倍來算(有些錯誤會在兩三年後才被發現,屆時維護者都已經換人了,除錯會相當困難)。則除錯的成本為:(5*10)*15*182 = $136,500。遠比 code inspection 的成本還高。在這種狀況下,code inspection 的代價是絕對值得的。當然,大家會質疑這裡頭的一些參數的正確性,我的重點是其實這裡頭可以有一個 model 去計算軟體工程的重要性,組織可以自己去記錄這些參數,慢慢的磨出一個對自己最有利的流程。

黃教授 提出以 MDA 的架構來降低成本是更棒的解決方法。設計師應該著重在設計的錯誤的檢驗上,程式錯誤的檢驗應該留給機器去做才對。事實上,目前也有許多 static test analyzer 的工具也可以輔助 code inspection,但還是很難完全摒除人工的。這方面的研究應該是各軟體公司競相追逐的項目吧。

其實這篇文章主要談的 code inspection, 而不是工程師的時薪。但談到工程師的時薪,的確是蠻令人辛酸的。國外一些知名軟體(例如 Oracle),一年的軟體使用權就可以賣個好幾百萬,我想他們的時薪的確就如劉教授所言的30,000。這表示:(1) 軟體是賺錢的; (2) 軟體要好好寫。

留言

  1. 依照Michael Guttman與John Parodi在"Real-Life MDA"一書的說法,大約有15-40%的系統程式是發展者有興趣的部分,其他都是較易錯誤的「沉悶無趣」(drudgery)的程式,這個部分可以用自動化處理,而讓發展者集中在有興趣的部分。照這種說法,我看最好讓發展者少寫程式,這樣也就減輕code inspection的工作,也就是較少有時薪多少的問題。其實,軟體是一種資本密集的產物(Wagner 1986?)(這一點可以談談),其價格的訂定有一因素是使用量(但不是唯一的因素),試想如果Windows的用量不大,可能大家都用不起,也可能產生不了大富翁比爾蓋茲先生,如果大家同意這種說法,code inspection的時薪就不必有確定的公式,就看老板們如何訂定。
    (註) "Real-Life MDA"中舉6種使用MDA技術發展軟體系統的case study,謹提供有興趣的人參考。

    回覆刪除
  2. 昨天學生剛好報告了一篇在 今年刊載在 IEEE transaction on SE 的論文,"NDT, A Model-Driven Approach for Web Requirements",談的就是利用 MDA 的技術來開發 web 系統; 上週則是討論到一篇 MDA 與設計樣式相關的論文。感覺起來最近 MDA 的研究越來越多,我們的產業是否應該現在趕快切進去呢?還是這種好東西只能一直留在學界?

    回覆刪除
  3. 實在忍不住這個想再寫一點的意圖。依據微軟提供的資訊,Windows Vista 是由 1500 人以 5 年的時間完成的,程式行數是 1500 萬行。如果這些人的年薪是美金 5 萬到 10 萬之間,則每一行程式的人力成本就是美金 25 元到 50 元之間。假設測試工作的比例佔 40%,那就是美金 10~20 元。這不是時薪,更不是新台幣,而是每一行程式以美金計算出的數字。換句話說,一個專家若每小時可以有效檢查 10 行程式,就有資格收新台幣 3000 元;當他有能力檢查 100 行程式(印出來大約 2 頁不到)時,就可收新台幣 30000 元。

    另外,MDA 要用在大型軟體系統的開發功效才會凸顯,譬如廉能政府的年度預算編列相關的資訊系統,各單位的狀況及條件限制等一定都不同而且要能保有彈性,以往的開發經驗可能也是慘不忍睹;如果用 MDA 來試試,或許會有很大的不同效果。

    回覆刪除
  4. 薛念林老師的意見提到,我們的產業應該趕緊切入MDA,不要將MDA這種好東西一直留在學界。如果看看本部落格問卷,其中「軟體公司對軟體工程的認識不足」有高達67%的人同意,所以要推展MDA技術到業界(不僅是軟體公司),可能必須推行認識軟工的重要性,對象不只是業界,同時也是大小官員以及部分學界的大員。此外,要使用MDA技術發展軟體,MDA工具十分重要,因自動化是作業所必須,這些工具有些價格不低,老板們是否願意出這種錢(包含訓練),大小官員是否願給這種預算,不無疑問,雖然有心人士必須努力,但短期內恐希望不大,我看還是留在學界研究研究較實在吧!

    回覆刪除

張貼留言

這個網誌中的熱門文章

CMMI是什麼?

TCSE 2017

加油站與小鎮