準確度量(1)

    準確度量——軟體專案規模估計有法可效

    軟體專案的規模估算歷來是比較複雜的事，因為軟體本身的複雜性、歷史經驗的缺乏、估算工具缺乏以及一些人為錯誤，導致軟體專案的規模估算往往和實際情況相差甚遠。因此，估算錯誤已被列入軟體專案失敗的四大原因之一。

    軟體工程師經常會被問到，編一個什麼樣的軟體需要多長時間、多少資金。對於這個問題，不少人會犯難，原因有兩個：一是用戶的需求太不具體，二是自己缺乏一個科學的估計方法。這里向大家介紹幾種軟體專案規模的估計方法。

    概念介紹

    先介紹一個衡量軟體專案規模最常用的概念—— LOC(line of code)，LOC指所有的可執行的源代碼行數，包括可交付的工作控制語言(JCL：job control language)語句、數據定義、數據類型聲明、等價聲明、輸入/輸出格式聲明等。一行代碼(1LOC)的價值和人月均代碼行數可以體現一個軟體生產組織的生產能力。組織可以根據對歷史專案的審計來核算組織的單行代碼價值。

    例如，某軟體公司統計發現該公司每一萬行C語言源代碼形成的源文件(.c和.h文件)約為250K。某專案的源文件大小為3.75M，則可估計該專案源代碼大約為15萬行，該專案累計投入工作量為240人月，每人月費用為10 000元(包括人均工資、福利、辦公費用公攤等)，則該專案中1LOC的價值為：

    (240×10 000)/150 000＝16元/LOC

    該專案的人月均代碼行數為：

    150 000/240=625LOC/人月

    方法一：Delphi法

    Delphi法是目前最流行的專家評估技術，在沒有歷史數據的情況下，這種方式適用於評定過去與將來、新技術與特定程序之間的差別，但專家“專”的程度以及對專案的理解程度是工作中的難點，盡管Delphi技術可以減少這種偏差，但通常在評定一個新軟體的實際成本時用得不多，這種方式在決定其他模型的輸入時特別有用。Delphi法鼓勵參加者根據問題進行相互讨論。這個技術要求有多種軟體相關經驗的人參與，互相說服對方。

    Delphi法的步驟是：

    (1) 協調人向各專家提供專案規格和估計表格；

    (2) 協調人召集小組會的各專家讨論與規模相關的因素；

    (3) 各專家匿名填寫叠代表格(如下圖2-2所示)；

    (4) 協調人整理出一個估計總結，以叠代表的形式返回專家；

    (5) 協調人召集小組會，讨論較大的估計差異；

    (6) 專家复查估計總結並在叠代表上提交另一個匿名估計；

    (7) 重複(4)～(6)步驟，直到最低和最高估計達到一致。

    Delphi法規模估計叠代表

    專案名稱：  

    估計日期：

    估計者：

    估計論次：

    結果：

本文摘自《ERP專案管理散記》

---

　　 形散而神聚。因為是散文，所以沒有框架結構的限制，作者寫起來輕鬆，讀者讀起來方便，數千字成一文，每篇文章都是一個獨立主題的探讨，又都緊密圍繞ERP專案實施這一主題。
　　事異而理同。雖然多數文章的標題冠以ERP專案實施的大標題，但文中所闡述的很多道理，不僅僅只適合於ERP專案管理，更適合於所有的專案管理，甚至可以推而廣之到企業管理中去。