代碼行， 是來源與英文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比較常用.
代碼行分析方法對技術人員是有意義的，因為它的確從某種程序上反映了軟件的規模，并且是物理上可測量的.但是這種方法也存在如下諸多問題.
在需求、計劃、設計階段因為本身沒有代碼行，需要靠估算來解決。總體上估算準確度不高，除非有多年的類似項目經驗。估算的準確程度取決于是否有同類項目的數據和估算人員的經驗。在編碼、測試、實施階段可以直接數出來。
在滿足客戶的要求以及反映進度方面的能力差強人意，對于管理者意義不大.因此項目很難從整體上跟蹤代碼行數的指標采取行動.
近來可視化編程工具的大量采用，以及模板庫，類庫的廣泛采用，在程序的結果中有大量自動生成的代碼或者復雜的自動配置腳本或資源文件設置，在采用這些工具的項目中，用代碼行分析方法得到數值的意義已經大大降低.
對于不同的編程語言來說，代碼行也缺乏可信轉換方式.
盡管代碼行方法有很多缺點，但是由于它容易使用，操作成本低(如果采用適當的支持工具)，還是推薦使用代碼行作為軟件項目管理的參考和補充手段.
(三) COCOMO模型
代碼行分析方法作為一種度量估計方法，在20世紀80和90年代得到非常廣泛的發展，在業界開發了又許多中估算工作量和進度的參數模型，其中的COCOMO模型，它的新版本是COCOMO II模型.
COCOMO，英文全稱為constructive cost model，中文為構造性成本模型.它是一種精確、易于使用的，基于模型的成本估算方法，早由勃姆 (Boehm) 于 1981 年提出。從本質上說是一種參數化的項目估算方法，參數建模是把下那個目的某些特征作為參數，通過建立一個數字模型預測項目成本(類似于居住面積作為參數計算的整體的住房成本).
在COCOMO模型中，工作量調整因子(Effort Adjustment Factor， EAF)代表多個參數的綜合效果，這些參數使得項目可以特征化和根據COCOMO數據庫中的項目規格化.每個參數可以定位很低，低，正常，高，很高.每個參數都作為乘數，其值通常在0.5到1.5之間，這些參數的乘積作為成本方程中的系數.
COCOMO用3個不同層次的模型來反映不同程度的復雜性，他們分別為
基本模型 (Basic Model). 是一個靜態單變量模型，它用一個以已估算出來的源代碼行數 (LOC) 為自變量的函數來計算軟件開發工作量。
中間模型 (Intermediate Model). 則在用 LOC 為自變量的函數計算軟件開發工作量的基礎上，再用涉及產品、硬件、人員、項目等方面屬性的影響因素來調整工作量的估算。
詳細模型 (Detailed Model) 包括中間 COCOMO 模型的所有特性，但用上述各種影響因素調整工作量估算時，還要考慮對軟件工程過程中分析、設計等各步驟的影響。
同時根據不同應用軟件的不同應用領域，COCOMO模型劃分為如下3種軟件應用開發模式:
組織模式(Organic Mode).這種應用開發模式的主要特點是在一個熟悉穩定的環境種進行項目開發，蓋項目與近開發的其他項目有很多相似點，項目相對較小，而且并不需要許多創新.
嵌入式應用開發模式 (Embedded Mode).在這種應用開發模式種，項目受到接口要求的限制.接口對整個應用的開發要求非常搞，而且要求項目有很大的創新，例如開發一種全新的游戲.
中間應用開發模式 (Semidetached Mode).這時介于組織模式和嵌入式應用開發模式之間的類型.
COCOMO 模型具有估算精確、易于使用的特點。在該模型中使用的基本量有以下幾個： (1)DSI( 源指令條數 ) ，定義為代碼行數，包括除注釋行以外的全部代碼。若一行有兩個語句，則算做一條指令。 (2)MM( 度量單位為人月 ) 表示開發工作量。 (3)TDEV( 度量單位為月 ) 表示開發進度，由工作量決定。 (4)COCOMO 模型重點考慮 15 種影響軟件工作量的因素，并通過定義乘法因子，從而準確、合理地估算軟件的工作量。
但是COCOMO也存在一些很嚴重的缺陷，例如分析時的輸入時優先的，不能處理意外的環境變換，得到的數據往往不能直接使用，需要校準，只能得到過去的情況總結，對于將來的情況無法進行校準等.
（四）功能點分析方法之一-原理篇
功能點分析法 (FPA：function point analysis) 是一種相對抽象的方法，是一種”人為設計”出的度量方式，主要解決如何客觀，公正，可重復地對軟件地規模進行度量的問題.
FPA 法由 IBM 的工程師艾倫 · 艾爾布策 (Allan Albrech) 于 20 世紀 70 年代提出，隨后被國際功能點用戶協會 (IFPUG：The International Function Point Users' Group) 提出的 IFPUG 方法繼承，從系統的復雜性和系統的特性這兩個角度來度量系統的規模，其特征是： “ 在外部式樣確定的情況下可以度量系統的規模 ” ， “ 可以對從用戶角度把握的系統規模進行度量 ” 。功能點可以用于 “ 需求文檔 ” 、 “ 設計文檔 ” 、 “ 源代碼 ” 、 “ 測試用例 ” 度量，根據具體方法和編程語言的不同，功能點可以轉換為代碼行。經由 ISO 組織已經有多種功能點估算方法成為國際標準，如： ① 加拿大人艾倫 · 艾布恩 (Alain Abran) 等人提出的全面功能點法 (full function points) ； ② 英國軟件度量協會 (UKSMA ： United Kingdom Software Metrics Association) 提出的 IFPUG 功能點法 (IFPUG function points) ； ③ 英國軟件度量協會提出的 Mark II FPA 功能點法 (Mark II function points) ； ④ 荷蘭功能點用戶協會 (NEFPUG：Netherlands Function Point Users Group) 提出的 NESMA 功能點法，以及軟件度量共同協會 (COSMIC：the Common Software Metrics Consortium) 提出的 COSMIC-FFP 方法，這些方法都屬于艾爾布策功能點方法的發展和細化。
功能點分析方法具體包括兩部分，一部分是測量的具體步驟和方法，通常稱為功能點規模測量方法(Functional Size Measurement， FSM)，另一部分則是功能點分析方法的具體應用.除非特別說明，通常的情況下并不分開討論，而是統稱為功能點分析方法(Functional Point Analysis， FPA)，包括對應用軟件的規模測量活動和后續應用測量結果進行適當的項目管理活動.
功能點分析方法有一些相對完整的，自成體系的概念，主要包括基礎功能部件(Base Function Component， BFC)， BFC類型，邊界，用戶，本地化，功能領域，功能規模，功能點規模測量的范圍，功能點規模測量過程，功能點規模測量方法，功能性需求，質量需求，技術性需求，數值調整以及調整因子等15個關鍵概念.
功能點分析的基本計數是依據標準計算出的系統 ( 或模塊 ) 中所含每一種元素的數目：
① 外部輸入數 (EI ： external input) ：計算每個用戶輸入，它們向軟件提供面向應用的數據。輸入應該與查詢區分開來，分別計算。
② 外部輸出數 (EO ： external output) ：計算每個用戶輸出，它們向軟件提供面向應用的信息。這里，輸出是指報表、屏幕、出錯信息，等等。一個報表中的單個數據項不單獨計算。
③ 外部查詢數 (EQ ： external query) ：一個查詢被定義為一次聯機輸入，它導致軟件以聯機輸出的方式產生實時的響應。每一個不同的查詢都要計算。
④ 內部邏輯文件 (ILF ： internal logical file) ：計算每個邏輯的主文件，如數據的一個邏輯組合，它可能是某個大型數據庫的一部分或是一個獨立的文件。
⑤ 外部接口文件 (EIF ： external interface file) ：計算所有機器可讀的接口，如磁帶或磁盤上的數據文件，利用這些接口可以將信息從一個系統傳送到另一個系統。
