The Introduction of Calling the Shot



這是人月神話:軟體專案管理之道(20週年紀念版)的第八章:,這裡有兩段開場白,一段是:『練習就是最好的教練。—西流士。』,一段是『經驗的代價是昂貴的,但愚人就只能從經驗中經驗中學習。』,這一篇真的很值得做軟體工作的人員來閱讀,ㄚ琪以前在開工作室的時候,最感困難的就是估價跟報價了,估價牽涉到軟體系統要花多少時間來完成?這對新手來說,確實是很難預估的一件事,因為有時客戶所要求的案子,可能之前自己還沒做過說。

首先,要估計開發軟體的時程,你可以參考The Introduction of The Mythical Man-Month的預估方法。其次,『寫一個獨立的小程式(program)所花的時間不能拿來作為預估整個軟體系統產品(programming systems product)的開發時程之用』,咦,不是直接用嗎?這個經驗ㄚ琪依稀記得,確實不能直接這樣用,依據這樣的公式,當然這公式可查出是經過驗證的,我就不再多說,公式如下:

費力程度 = (常數)× (指令的數量)1.5

之前Portman研究發現,他的軟體開發小組還使用計畫評核圖(PERT chart),這個ㄚ琪在工業工程上是有學過也很推崇的,不過在開發軟體專案時,也會有不切實際的現象產生。

另外一個IBM的系統技術經理,也做過生產力的研究,發現這樣的結論:

溝通很少     10,000指令/人年(man-year)

溝通量中等   5,000

溝通量很多  1,500

Harr的研究發現如下面的簡體文字統計表:

2011-03-02_135640

有了這個表,要預估軟體開發的時程就更方便了!

OS/360的開發驗證了『工作本身的複雜度與困難度將對生產力造成驚人的差異。』作者的經驗估計『編譯器之類的程式會比一般整批處理的應用程式要複雜三倍,而作業系統又要比編譯器複雜三倍。』,這樣的推敲下去,看來ㄚ琪還是繼續寫應用程式就好了,比較簡單。

前面的研究很多都是組合語言開發的生產力,Corbato’的研究則顯示採用高階語言,軟體開發的生產譯可以提昇五倍,難怪用微軟的Visual系列有一定的好處,真的是開發太方便了,想揮之欲去,都很難啊!ㄚ琪最近甚至有點愛上了C#的使用了,太好用了!

Print Friendly, PDF & Email

發佈留言

發佈留言必須填寫的電子郵件地址不會公開。 必填欄位標示為 *

這個網站採用 Akismet 服務減少垃圾留言。進一步瞭解 Akismet 如何處理網站訪客的留言資料