代碼行分析方法常見的軟件規模估算方法
測試工作量的估計往往和軟件開發的規模是緊密相關的.很多軟件公司往往是在估計了即將要開發的軟件規模后才做測試工作量的估計,然后求和得出項目的最終工作量估計.這種方法比較適用于有經驗積累,測試和開發模式穩定的公司或項目,提供了一個比較準確,有參考的數字.但同時由于其完全依賴其前提-開發工作量的估計,顯得比較脆弱,如果開發工作量出現較大偏差,測試工作量也就變得毫無用處.在加之代碼行本身就存在著許多問題和局限,所以在選擇其做為項目估算方法時需要好好了解它的原理,優缺點進而有選擇性的使用.
代碼行, 是來源與英文line of code.那么代碼行分析方法就是就是對軟件產品的源代碼的行數進行測量.但是仔細想想,可能會有以下疑問:
是計算物理行數,還是程序的命令數量?
空行是否計算?
注釋是否計算?
預定義文件是否計算?
不同版本如何計算?
這里面是否設計到一系列的規則定義問題?
開發過程種的配置腳本,編譯腳本是否計算?
共享文件(例如共享的開發庫文件種的頭部文件)如何計算?
那么現在的一般規則是計算物理行數,不計算空行,不計算注釋.對于其他選項,一般為計算源文件根目錄下的所有文件.所以代碼行指的是指所有的可執行的源代碼行數，包括可交付的工作控制語言 (JCL ： job control language) 語句、數據定義、數據類型聲明、等價聲明、輸入 / 輸出格式聲明等。常使用的單位有： SLOC(single line of code)、KLOC(thousand lines of code)、 LLOC(logical line of code)、PLOC(physical line of code)、NCLOC (non-commented line of code)、DSI(delivered source instruction)。其中SLOC和KLOC比較常用.
代碼行分析方法對技術人員是有意義的,因為它的確從某種程序上反映了軟件的規模,并且是物理上可測量的.但是這種方法也存在如下諸多問題.
在需求、計劃、設計階段因為本身沒有代碼行，需要靠估算來解決�？傮w上估算準確度不高，除非有多年的類似項目經驗。估算的準確程度取決于是否有同類項目的數據和估算人員的經驗。在編碼、測試、實施階段可以直接數出來。
在滿足客戶的要求以及反映進度方面的能力差強人意,對于管理者意義不大.因此項目很難從整體上跟蹤代碼行數的指標采取行動.
近來可視化編程工具的大量采用,以及模板庫,類庫的廣泛采用,在程序的結果中有大量自動生成的代碼或者復雜的自動配置腳本或資源文件設置,在采用這些工具的項目中,用代碼行分析方法得到數值的意義已經大大降低.
對于不同的編程語言來說,代碼行也缺乏可信轉換方式.
盡管代碼行方法有很多缺點,但是由于它容易使用,操作成本低(如果采用適當的支持工具),還是推薦使用代碼行作為軟件項目管理的參考和補充手段.
文章來源于領測軟件測試網 http://www.k11sc111.com/
