COCOMO的發展歷程和很多IT管理相關模型的產生一樣有著十分傳奇的色彩，和其國的Levi’s品牌牛仔褲一樣有著悠久的歷史。1981年的一天，師出TRW湯普森·拉莫·伍爾德里奇公司[美]計算機科學部從事軟件開發成本估算研究工作的Barry Boehm博士——一個為成全天下軟件開發事業而投生到歷史的洪流中去,決意用智慧為世界迎來嶄新的明天的人。工夫不負有心人，在歷經日以繼夜的無數次失敗后，終于在這一天提出的結構型成本估算模型——“構建式成本模型”(COCOMO)，它是一種精確、易于使用的成本估算方法，而且是一個和Putnam一樣已經得到業界數據的驗證的模型。時過境遷，在隨后的10年歲月里，在美國空軍任職的Ray Kile先生,對其進行了修訂改良，形成了中級COCOMO增強版，同時也是美軍使用的標準版本。Boehm重來沒有放棄成為一個偉大軟件成本估算模型專家的理想，而一直從事如何有效地將COCOMO有效的運用到軟件項目成本估算工具當中，他意識到IT界的發展極為迅速，如果沒有發展和創新COCOMO終究有一天將會被社會所淘汰，被世人所遺忘，所以到了1996年，Boehm博士根據軟件發展情況，終于發布了改進版，將COCOMO升級為COCOMOII，而COCOMO II是對經典COCOMO模型的徹底更新，反映了現代軟件過程與構造方法。美軍國防部在1999年春季公布的參數模型指導手冊中將此模型作為軟件評估模型的首選，Boehm終于把COCOMO從浩瀚的同類工具中脫穎而出并推上世界巔峰，期間其著作《軟件成本估算：COCOMOn模型方法》和《軟件工程經濟學》更成為無數IT項目管理人員所景仰的經典之作，終于智慧爆發,慘悟透了老子《道德經》中“大有則無”的思想,發現自己再強也只不過是凡俗人間的一片過眼云煙,所以看破紅塵就此歸隱。
然而他卻給世人留下COCOMOII這個巨大的財富，為軟件開發事業做出無法估計的貢獻，也許是對他為軟件世界付出辛勤汗水的一點告慰吧。要使用COCOMOII模型進行成本估算，首先必須了解一些關于它的用法和需要注意的地方，這樣我們才能有效的將它應用當管理工作當中。
首先我們應該了解一下COCOMO模型中用到的一些變量，當然還有COCOMOII模型的類型和分類，這是估算軟件成本的重要環節：
（1）COCOMO模型中的變量。
DSI-------源指令條數。不包括注釋。1KDSI = 1000DSI。
MM-------開發工作量（以人月計） 1MM = 19 人日 = 152 人時 =1/12 人年
TDEV-----開發進度。(以月計)
（2）COCOMO模型的類型：
COCOMO模型中，考慮開發環境，軟件開發項目的類型可以分為3種：組織型(organic): 相對較小、較簡單的軟件項目。開發人員對開發目標理解比較充分，與軟件系統相關的工作經驗豐富，對軟件的使用環境很熟悉，受硬件的約束較小，程序的規模不是很大（<50000行）
嵌入型(embedded): 要求在緊密聯系的硬件、軟件和操作的限制條件下運行，通常與某種復雜的硬件設備緊密結合在一起。對接口，數據結構，算法的要求高。軟件規模任意。如大而復雜的事務處理系統，大型/超大型操作系統，航天用控制系統，大型指揮系統等。
半獨立型（semidetached）：介于上述兩種軟件之間。規模和復雜度都屬于中等或更高。最大可達30萬行。
（3）COCOMO模型的分類：
COCOMO模型按其詳細程度可以分為三級：基本COCOMO模型，中間COCOMO模型，詳細COCOMO模型。其中基本COCOMO模型是是一個靜態單變量模型，它用一個以已估算出來的原代碼行數(LOC)為自變量的經驗函數計算軟件開發工作量。中級COCOMO模型在基本COCOMO模型的基礎上，再用涉及產品、硬件、人員、項目等方面的影響因素調整工作量的估算。詳細COCOMO模型包括中間COCOMO模型的所有特性，但更進一步考慮了軟件工程中每一步驟（如分析、設計）的影響。
COCOMOII不僅可以評估開發工作量，而且可以對項目的進度進行具體估計。 COCOMOII擁有規模計算，工作量估算，進度估算等重要能力能很好地幫助我們軟件維護和進行軟件決策。對我們在對項目的范圍，時間，成本等管理是十分有利的條件，使我們擁有更多時間去關心項目的質量和使得人力資源更有效分配和利用起到極其重要的作用�？梢詮漠a品大小估計的結果中計算出項目的總體人員工作量和時間表。除了大小輸入，另一項關鍵輸入是對團隊生產率的評測。該輸入值可確定項目的總工作量�？偟捻椖繒r間表與總工作量之間存在非線性的關系。遺憾的是，這些模型從數學的角度來看非常復雜，但是COCOMOII模型正好給我們的工作簡化其中復雜的過程，為我們贏得更多的有效時間。
圖片附件: 012901.jpg (2007-1-29 10:37, 4.68 K)
PM nominal = Person months effort of the project (人月工作量)
A = Constant representing the nominal productivity (工作量調整因子)
B = accounts for the relative economies/ diseconomies of scale (規模調整因子)
Size = Size of the project (規模,千代碼行或功能點數目)
首先這里我們可以看到COCOMO是一個典型的參數估算模型。其中重要的就是兩個調整因子和規模的確定上面。
對于軟件項目的規模，最適合的還是采用功能點法進行估算，在估算出功能點后可以根據功能點和代碼行的折算關系得到代碼行的估算數據。因此我們看到COCOMO本身并不能夠解決規模估算的問題，更重要的是根據系統已經有的規模來確定項目的工作量和項目周期。
B是規模調整因子，也叫做過程調整參數，當B=1時候說明了工作量和規模之間是線性的關系，這個時候就等同到了我們平時通過規模/生產率來確定項目的工作量的情況上面。但根據實踐經驗，項目工作量并不是完全由簡單的個體生產率來確定的，還涉及到開發靈活性，架構風險，團隊，過程成熟度等很多的影響因素。因此需要對B進行適當調整,具體的調整規則參考下表： 圖片附件: 012902.jpg (2007-1-29 10:37, 27.03 K)
B = 1.01 + 0.01 ( PREC + FLEX + RESL + TEAM + PMAT)
這里一般B一般都是大于1.01的。
當B<1時候，說明項目架構，開發環境，團隊都足夠健壯和穩定。這個時候項目表現出來了對規模的經濟性，當規模成倍增加的時候，工作量反而不要翻倍。
當B>1時候，說明了項目工作量對規模的非經濟性。當規模增加的時候可能會導致工作量的成倍增加。
對于調整因子A一般都是常量，這個需要總結歷史項目的度量數據進行反推來計算。因此說要使用COCOMO成本估算模型，必須積累足夠多的歷史經驗數據。
在工作量估算出來后，就可以根據工作量來估算項目的進度。個人認為COCOMO最大的貢獻在于對項目進度的估算，如果說對工作量估算還存在當B=1的時候工作量和規模會成為線性關系的話，那對于進度估算則基本上不會出現簡單的線性關系�；旧隙颊f明了項目的進度不是簡單的根據工作量除以資源的投入而得到的。 圖片附件: 012903.jpg (2007-1-29 10:37, 2.8 K)
TDEV代表項目的進度，其中單位仍然按月計算。通過Excel繪制出工作量與進度的關系曲線如下： 圖片附件: 012904.jpg (2007-1-29 10:37, 14.11 K)
應用PSM進行軟件度量的經驗-整理
1.度量是一致但靈活的過程，可以根據信息收集和項目或組織的需求進行裁剪。
2.決策者必須理解要度量哪些度量元，并信任收集到的信息
3.度量必須被用來產生價值
度量的信息分類
1.進度和過程
2.資源和成本
3.產品的規模和穩定性
4.產品的質量
5.過程性能
6.技術有效性
7.客戶滿意度
圖片附件: 012905.jpg (2007-1-29 10:44, 27.65 K)
度量計劃
1.度量可以從一個小的度量集做起，然后逐步增加
2.度量計劃不僅要定義度量什么，還要定義具體的收集，分析等過程
3.可以根據項目的實際需求對組織級度量過程進行裁剪
4.成功的度量過程應該整合了所以決策者需求
執行度量
1.收集度量數據，執行分析和展現結果
2.度量數據的分析可以包括估算，計劃可行性，實際數據與計劃數據偏差性能分析
3.盡可能的采用自動收集系統收集數據
4.當需要對度量進行裁剪的時候，一種集結方法需要事先定義。
圖片附件: 012906.jpg (2007-1-29 10:44, 23.26 K)
評價度量
1.度量過程和度量數據本身都應該周期性和定時的進行評估和改進。
2.度量是一個迭代的過程，而且會隨著信息需求變化和組織級目標不斷精練。
理解和信任度量信息
1.應該明確定義和提供清晰的度量元保持度量的一致性和連貫性。
2.展現度量結果和數據時候應該用一種決策者很容易理解的方式。
3.執行度量的人一般不直接做決策，因此度量信息展現必須簡單明了。
4.僅僅是因為度量信息是準確和客觀的，并不能說明度量一定起作用.
度量數據必須使用
1.度量數據必須盡可能早的收集和提供，以便管理者決策
2.度量結果必須在整個組織內實時的溝通和共享
3.決策并不一定期待完美的數據，但數據本身必須是準確的。
4.度量的結果應該幫助決策者優化整個過程性能
文章來源于領測軟件測試網 http://www.kjueaiud.com/
