發表文章

目前顯示的是 10月, 2008的文章

Code inspection 的代價 (continued)

本來應該寫在 Code inspection 的代價 一文的意見中,但考慮到內容比較多,故還是以一文說明。 看了許多專家的看法,我也提出自己的看法。我的假設是這樣的 Programmer 的月薪為 35,000/月 資深的 inspector 月薪為 60,000/月 速紀員可能是系統助理,月薪較低,為 28,000/月 主席的月薪為 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 的動作,而是以後續的動態測試才取代。我們知道, 動態測試是治標不治本的方法 ,它 能找到的錯誤是比較少的。假設有有一半的錯誤沒有在動態測試中被找出來而不小心流到使用者手上,那代價可能很難估算。第一:如果造成客戶的業務損失; 第二:維護階段除錯的效

Code inspection 的代價

除了動態測試(執行程式來檢驗是否正確)以外,靜態的檢視也是非常重要的測試方法。檢視的對象可以是 code, 設計文件、需求文件等。當檢視的對象是 code, 我們稱之為 code inspection,一般而言有以下的角色: 撰寫者 (owner) :程式的撰寫者 檢視員 (inspector) :檢視程式的錯誤,通常都是較為資深或領域專家 速記員 (scriber) :在檢視會議中幫忙記錄 主席 (chair/moderator) :仲裁與協調會議的進行 在分工比較細的組織中,甚至還有報告者,但可以撰寫者來兼任。靜態檢視可以分為幾個步驟 簡介 (Overview) : 由撰寫程式者向所有的檢視者簡介系統內容 獨立準備 (Individual Preparation): 每個 inspector 獨立的閱讀與檢視程式碼,並將疑問處圈選出來,預備在會議上討論 檢視會議 (inspection): 檢視程式碼 追蹤 (follow up) : 修正會議上所找出來錯誤,並持續追蹤 依照 Sommerville 書上的資料顯示, 簡介、獨立準備、檢視會議  的速度分別是 500, 125, 90 statement/hour, 假設我們完成了一個 1,000 statement 的程式碼,檢視員有 2 位, 請問一次 code inspection 花公司多少錢?值得嗎? (請假設每個員工的薪水)。有興趣的大家一起算算吧!

Case study and software engineering

這星期聽了一個有趣的演講。談的是如何進行個案教學,其實這個主題對企管的人而言是家常便飯,但對資訊工程的老師而言,卻還蠻新鮮的。特別是身為軟體工程的教育者,深深的感受到軟體工程的傳授是很困難的,原因如下 學生的經歷不夠,很難體會軟體工程所提到的問題。例如我們說『需求難以表達』,學生可能會覺得 -- 口才有這麼差嗎? 資工系的學生覺得寫程式才是王道。卻不知很多的專案失敗在工程方法。 課堂的時間太短,沒有辦法真正的體會軟工的議題。例如一個學期跑一個專案,想要讓學生從專案中體會一些軟工的原理, 但一個學這麼短的時間根本跑不了大專案,而小專案偏偏又很難體會軟工的重要性。 所以我能體會有些老師把軟體工程當成『程式語言』來教,至少寫寫程式還可以讓學生學些什麼。 但如果能夠有 case study 進來,我想軟體工程的課一定會有趣得多。這裡的 case study 和課堂上的『舉例』有極大的差別。Harvard設計一個 case study 給的經費約台幣 30 萬,台灣最近也類似的教學改善計畫,也都是十萬的倍數(企管課程),想當然案例的設計要嚴謹的許多。想想看,如果我們可以聽到並一起探討 google 在設計 gamil 的專案管理、測試、設計,可能比上了十天的軟體工程收穫更多。或是可以參考台灣凌群電腦在軟體流程改善的進行方式,對學生的幫助一定很大。 希望教育部能夠支援像這樣的課程,其實買設備的教改計畫幫助不大。