1、在下最近和一朋友交談，無意間談起了游戲成本。雖然在下木有接觸過游戲開發的成本計算，但是軟件行業的成本計算應該基本是相同的。 本文將從以下幾個方面討論如何避免增加成本的風險。1。開發過程。2。生命周期。3。支出收入匯總及改良。4。優化團隊。大概以上4點出發，目的就是減少因自身產生的不必要的成本的增加，比如：1。初期需求不確定，后期修改需求，導致反工從而大幅度提高成本。2。團隊的資源浪費。技術工人能做的事，卻讓本科生做。3。其他。再看看必要的成本增加：1。不確認需求，使用原型模型生命周期確認需求分析。2。大規模開發過程中，不斷的跌代。（增量模型）3。超大規模系統開發，螺旋模型。4。工程以外支出（請

2、客，送禮，賄賂等）5。其他（員工工資等）1。開發過程：初步需求分析-可行性分析-需求分析-概要設計-詳細設計-寫代碼-測試-提交1。1過程注釋：開發都離不開客戶，所以什么都得以客戶需求為準。排第一的過程必定是初步需求分析。用戶的要求不一定都是需求，必定有很多用戶不知道當前的技術是否能實現他所要求的，在這一階段。從自己公司情況評估可行性，如果不行，請重新考慮是否接受這個項目或者砍掉這個不合理的需求。（規避這階段的風險的進入）以上步奏完成后，才開始真正的需求分析。如果用戶的水平很高，可以很快的確認需求就是他所要求的。這個階段會省很多的成本。如果用戶的水平不高，獲得的部分需求很模糊，那就得按增量模型

3、。（必要的成本增加）如果用戶的水平很低，基本獲得不了需求，按照原型模型制作針對每一個要求的功能的模型并讓用戶確認。并且反復此過程，直到用戶需求收集完畢。此過程中的模型將被拋棄。（再次規避這階段風險的進入）。概要設計階段：根據需求分析，畫出uml圖，完成基本的架構設定。參與需求分析人員的人員和系統分析師共同完成此階段。（規避此階段因為需求分析人員所描述和系統分析師理解的概念不同而進入的風險）詳細設計：根據需求分析，概要設計的uml圖。完成設定相關類的選定以及功能的實現。參與需求分析人員和系統分析師以及程序人員共同完成。（規避了因程序人員理解和概要設計描述不同進入的風險）代碼階段：這個階段最大的風

4、險就是人員的流失和調動，盡量避免過多的程序組的調動。而這個階段必須擁有規范的編寫方式，以及文檔記錄。減少因人員丟失引起的問題。這個階段的風險在于，人員調動，文檔記錄是否規范。測試階段：測試顧名思義，就是找出問題。而不是測試系統多么完善。天下沒有完善的系統，當交付一個項目的時候只有祈禱用戶使用的時候不會涉及未測試的部分。此階段風險，在于確認需求測試，單元測試，以及集成測試等測試后。必定還有更多的測試用例未被測試。（此風險不可避免，這個也是項目需要后續開發的原因）測試應該盡量多的測試用例，當然，時間也得多。但是測試階段必定不能跳過。大概描述第一個完了。暫時出去。一會回來繼續-華麗分割線-2。生命周

5、期。(此部分基本引自各種書籍）這里有必要講一下傳統的軟件工程開發方法-生命周期方法學（這里引自某書）軟件工程采用的傳統方法是生命周期方法學。軟件工程強調使用生命周期方法學和各種結構分析及結構設計技術，它們是在20世紀70年代為了對付應用軟件日益增長的復雜程度、漫長的開發周期以及用戶對軟件產品經常不滿意的狀況而發展起來的。人類解決復雜問題時普遍采用的一個策略就是“各個擊破”，也就是對問題進行分解然后再分別解決各個子問題的策略，便于不同人員分工協作，從而降低了整個軟件開發工程的困難程度。    軟件工程采用的生命周期方法學就是從時間角度對軟件開發和維護的復雜

6、問題進行分解，把軟件生命的漫長周期依次劃分為若干個階段，每個階段有相對獨立的任務，然后逐步完成每個階段的任務。采用生命周期方法學開發軟件的時候，從對任務的抽象邏輯分析開始，一個階段一個階段地進行開發。前一個階段任務的完成是開始進行后一個階段工作的前提和基礎，而后一階段任務的完成通常是使前一階段提出的解法更進一步具體化，加進了更多的實現細節。每一個階段的開始和結束都有嚴格標準，對于任何兩個相鄰的階段而言，前一階段的結束標準就是后一階段的開始標準。    在每一個階段結束之前都必須進行正式嚴格的技術審查和管理復審，從技術和管理兩方面對這個階段的開發成果進行檢

7、查，通過之后這個階段才算結束，如果檢查通不過，則必須進行必要的返工，并且返工后還要再經過審查。審查的一條主要標準就是每個階段都應該交出“最新的”，即和所開發的軟件完全一致的高質量的文檔資料，從而保證在軟件開發工程結束時有一個完整準確的軟件配置及文檔交付使用。文檔是通信的工具，它們清楚準確地說明了到這個時候為止，關于該項工程已經知道了什么，同時確立了下一步工作的基礎。此外，文檔也起備忘錄的作用，如果文檔不完整，那么一定是某些工作忘記做了，在進入生命周期的下一階段之前，必須補足這些遺漏的細節，保證文檔的正確和完整。瀑布模型：（引自互連網）按照傳統的生命周期方法學開發軟件，各階段的工作自頂向下從抽象

8、到具體順序進行，就好像奔流不息的瀑布，一瀉千里，總是從高處依次流到低處。因此，傳統的生命周期方法學可以用瀑布模型(waterfallmodel)來模擬。按照傳統的瀑布模型來開發軟件，有如下幾個特點，這些特點隱含在軟件生命周期各階段的觀點和指導思想中，是比具體任務更根本的東西。     (1) 階段間具有順序性和依賴性    這個特點有兩重含義：第一，必須等前一階段的工作完成之后，才能開始后一階段的工作；第二，前一階段的輸出文檔就是后一階段的輸入文檔，因此只有前一階段的輸出文檔正確，后一階段的工作

9、才能獲得正確的結果。    (2) 推遲實現的觀點    清楚地區分邏輯設計與物理設計，盡可能推遲程序的物理實現，前面階段的工作沒做或做得不扎實，過早地考慮進行程序實現，往往導致大量返工，有時甚至發生無法彌補的問題，帶來災難性后果。瀑布模型在編碼之前設置了系統分析與系統設計階段，這兩個階段主要考慮目標系統的邏輯模型，不涉及軟件的物理實現。    (3) 質量保證的觀點    軟件工程的基本目標是優質、高產。保證所開發

10、的軟件的質量，在瀑布模型的每個階段都應堅持兩個重要做法：    第一，每個階段都必須完成規定的文檔，沒有交出合格的文檔就是沒有完成該階段的任務。完整、準確的合格文檔不僅是軟件開發時期各類人員之間相互通信的媒介，也是運行時期對軟件進行維護的重要依據。    第二，每個階段結束前都要對所完成的文檔進行評審，以便盡早發現問題，改正錯誤。及時審查是保證軟件質量、降低軟件成本的重要措施。瀑布模型這種模型本質上是一種線性順序模型，因此存在著較明顯的缺點，各階段之間存在著嚴格的順序性和依賴性，特別強調預先定義需求的重要性，在著手

11、進行具體的開發工作之前，必須通過需求分析預先定義并“凍結”軟件需求，然后再一步一步的實現這些需求。但是實際項目很少遵循著這種線性順序進行的。雖然瀑布模型也允許迭代，但這種改變往往對項目開發帶來混亂。在系統建立之前很難只依靠分析就確定出一套完整、準確、一致、有效的用戶需求，這種預先定義需求的方法更不能適應用戶需求的不斷變化的情況。   1.需求是可變的   某些應用軟件的需求與外部環境、公司經營策略或經營內容等密切相關，因此需求是隨時變化的。   2.需求是模糊的   對于大多

12、數更常使用的應用系統，例如管理信息系統，其需求往往很難預先準確的指定，也就是說，預先定義需求的策略所做出的假設，只對某些軟件成立，對多數軟件并不成立。許多用戶對他們的需求最初只是模糊的概念，想要求一個對需求只有初步設想的人準確無誤的說出全部需求，顯然是不切實際的。人們為了充實和細化他們的初步設想，通常需要經過在某個能運行的系統上實踐的過程。   3.用戶和開發者難于溝通    大型軟件的開發需要系統分析員、軟件工程師、程序員、用戶、領域專家等各類人員的協調配合。然而大多數用戶和領域專家不熟悉計算機和軟件技術，軟件開發人員也往

13、往不熟悉用戶的專業領域，開發人員和用戶之間很難做到完全溝通和相互理解，在需求分析階段做出的用戶需求常常是不完整、不正確的。傳統的瀑布模型很難適應需求可變、模糊不定的軟件系統的開發，而且在開發過程中，用戶很難參與進去，只有到開發結束才能看到整個軟件系統。這種理想的、線性的開發過程，缺乏靈活性，不適應實際的開發過程。-再次華麗分割線-2?？焖僭湍Ｐ?.原型     原型是指模擬某種產品的原始模型，在其他產業中經常使用。軟件開發中的原型是軟件的一個早期可運行的版本，它反映了最終系統的重要特性。2.快速原型思想的產生   

14、; 由于種種原因，在需求分析階段得到完全、一致、準確、合理的需求說明是很困難的，在獲得一組基本需求說明后，就快速地使其“實現”，通過原型反饋，加深對系統的理解，并滿足用戶基本要求，使用戶在試用過程中受到啟發，對需求說明進行補充和精確化，消除不協調的系統需求，逐步確定各種需求，從而獲得合理、協調一致、無歧義的、完整的、現實可行的需求說明。又把快速原型思想用到軟件開發的其他階段，向軟件開發的全過程擴展。即先用相對少的成本，較短的周期開發一個簡單的、但可以運行的系統原型向用戶演示或讓用戶試用，以便及早澄清并檢驗一些主要設計策略，在此基礎上再開發實際的軟件系統。3.快速原型的原理 

15、   快速原型是利用原型輔助軟件開發的一種新思想。經過簡單快速分析，快速實現一個原型，用戶與開發者在試用原型過程中加強通信與反饋，通過反復評價和改進原型，減少誤解，彌補漏洞，適應變化，最終提高軟件質量。4.原型運用方式    由于運用原型的目的和方式不同，在使用原型時也采取不同的策略，有拋棄策略和附加策略。    (1)拋棄策略是將原型用于開發過程的某個階段，促使該階段的開發結果更加完整、準確、一致、可靠，該階段結束后，原型隨之作廢。探索型和實驗型就是采用此策略的。 

16、0;  (2)附加策略是將原型用于開發的全過程，原型由最基本的核心開始，逐步增加新的功能和新的需求，反復修改反復擴充，最后發展為用戶滿意的最終系統，演化型快速原型就是采用此策略。    采用何種形式、何種策略運用快速原型主要取決于軟件項目的特點、人員素質、可供支持的原型開發工具和技術等，這要根據實際情況的特點來決定。有興趣的可以查-華麗分割線-3。增量模型1.原型的作用  (1)為軟件系統提供明確的需求說明，當用戶要求含糊不清、不完全、不穩定時，通過原型執行、評價，使用戶要求明確。  (2)原型

17、可作為新穎設計思想的思想工具，也可作為高風險開發的安全因素，從而證實設計的可行性。  (3)原型模型支持軟件產品的演化，對開發過程中的問題和錯誤具有應付變化的機制。  (4)原型模型鼓勵用戶參與開發過程，參與原型的運用和評價，能充分地與開發者協調一致。   2.使用原型的建議   能夠使用原型的情況：  (1)開發周期很長的項目，通過原型開發來縮短開發周期。  (2)系統的使用可能變化較大，不能相對穩定，而原型模型具有適應變化的機制。  

18、;(3)用戶對系統的需求較為模糊，對某種要求缺乏信心。  (4)開發者對系統的某種設計方案的實現無信心或無十分把握。  上述這些情況均適合于使用原型模型來開發。   3.原型的優點  (1)可及早為用戶提供有用的產品。  (2)可及早發現問題，隨時糾正錯誤。  (3)減少技術、應用風險，縮短開發實際，減少費用，提高生產率。  (4)通過實際運行原型，提供直接評價系統的方法，促使用戶主動參與開發活動，加強了信息反饋，促進各類人員的協調，減少誤解，適

19、應需求的變化，能有效提高系統質量。   4.存在問題   (1)缺乏豐富而強有力的軟件工具和開發環境。  (2)缺乏有效的管理機制，還未建立起自己的開發標準。  (3)對設計人員水平及開發環境要求較高。  (4)在多次重復改變原型的過程中，程序員會感到厭倦。  (5)系統的易變性對測試有一定影響，難于做到徹底測試，更新文檔較為困難。過程圖：-5.螺旋模型螺旋模型沿著螺線進行若干次迭代，圖中的四個象限代表了以下活動： （1） 制定計劃：確

20、定軟件目標，選定實施方案，弄清項目開發的限制條件； （2） 風險分析：分析評估所選方案，考慮如何識別和消除風險； （3） 實施工程：實施軟件開發和驗證； （4） 客戶評估：評價開發工作，提出修正建議，制定下一步計劃。 螺旋模型由風險驅動，強調可選方案和約束條件從而支持軟件的重用，有助于將軟件質量作為特殊目標融入產品開發之中。但是，螺旋模型也有一定的限制條件，具體如下： （1） 螺旋模型強調風險分析，但要求許多客戶接受和相信這種分析，并做出相關反應是不容易的，因此，這種模型往往適應于內部的大規模軟件開發。&

21、#160;（2） 如果執行風險分析將大大影響項目的利潤，那么進行風險分析毫無意義，因此，螺旋模型只適合于大規模軟件項目。 （3） 軟件開發人員應該擅長尋找可能的風險，準確地分析風險，否則將會帶來更大的風險 過程圖：-6。rup  rup（rational unified process，統一軟件開發過程，統一軟件過程)是一個面向對象且基于網絡的程序開發方法論。根據rational(rational rose和統一建模語言的開發者)的說法，好像一個在線的指導者，它可以為所有方面和層次的程序開發提供指導方針，

22、模版以及事例支持。 rup和類似的產品-例如面向對象的軟件過程（oosp），以及open process都是理解性的軟件工程工具-把開發中面向過程的方面（例如定義的階段，技術和實踐）和其他開發的組件（例如文檔，模型，手冊以及代碼等等）整合在一個統一的框架內一、六大經驗迭代式開發,管理需求,基于組件的體系結構,可視化建模,驗證軟件質量,控制軟件變更。二、統一軟件開發過程rup的二維開發模型 三、統一軟件開發過程rup核心概念角色：描述某個人或者一個小組的行為與職責。rup預先定義了很多角色。      活動

23、：是一個有明確目的的獨立工作單元。      工件：是活動生成、創建或修改的一段信息。四、統一軟件開發過程rup裁剪  rup是一個通用的過程模板，包含了很多開發指南、制品、開發過程所涉及到的角色說明，由于它非常龐大所以對具體的開發機構和項目，用rup時還要做裁剪，也就是要對rup進行配置。rup就像一個元過程，通過對rup進行裁剪可以得到很多不同的開發過程，這些軟件開發過程可以看作rup的具體實例。rup裁剪可以分為以下幾步：1) 確定本項目需要哪些工作流。rup的9個核心工作流并不總是需要的，可以取舍

24、。2) 確定每個工作流需要哪些制品。3) 確定4個階段之間如何演進。確定階段間演進要以風險控制為原則，決定每個階段要那些工作流，每個工作流執行到什么程度，制品有那些，每個制品完成到什么程度。4) 確定每個階段內的迭代計劃。規劃rup的4個階段中每次迭代開發的內容。5) 規劃工作流內部結構。工作流涉及角色、活動及制品，他的復雜程度與項目規模即角色多少有關。最后規劃工作流的內部結構，通常用活動圖的形式給出。五、開發過程中的各個階段和里程碑1 初始階段2 細化階段 3 構造階段 4 交付階段 

25、;六、統一軟件開發過程rup的核心工作流(core workflows) 1 商業建模(business modeling) 2 需求(requirements)3 分析和設計(analysis & design)  4 實現(implementation)5 測試(test) 6 部署(deployment) 7 配置和變更管理(configuration & change ma

26、nagement) 8 項目管理(project management) 9 環境(environment) 七、rup的迭代開發模式 與傳統的瀑布模型相比較，迭代過程具有以下優點：降低了在一個增量上的開支風險。如果開發人員重復某個迭代，那么損失只是這一個開發有誤的迭代的花費。降低了產品無法按照既定進度進入市場的風險。通過在開發早期就確定風險，可以盡早來解決而不至于在開發后期匆匆忙忙。 加快了整個開發工作的進度。因為開發人員清楚問題的焦點所在，他們的工作會更有效率。由于用戶的需求并不能在一開始就作出完全的界定，它們

27、通常是在后續階段中不斷細化的。因此，迭代過程這種模式使適應需求的變化會更容易些八、統一軟件開發過程rup的十大要素1. 開發前景 2. 達成計劃 3. 標識和減小風險 4. 分配和跟蹤任務。 5. 檢查商業理由 6. 設計組件構架 7. 對產品進行增量式的構建和測試 8. 驗證和評價結果 9. 管理和控制變化 10. 提供用戶支持 有興趣的可以直接查閱-第2部分完-3。支出收入匯總及改良。（此部分

28、數據僅僅作為引用，不具備參考價值）這個屬于軟件開發管理的范圍。但是說起管理就太多了。而老板們關心的是錢。所以抓出來特別說說。過程問題：軟件開發成本管理過程中的主要問題 （1） 項目成本預算和估算的準確度差。 由于客戶的需求不斷變化，使得工作內容和工作量不斷變化。一旦發生變化，項目經理就追加項目預算，預算頻頻變更，等到項目結束時，實際成本和初始計劃偏離很大。 此外，項目預算往往會走兩個極端：過粗和過細。預算過粗會使項目費用的隨意性較大，準確度降低；預算過細會使項目控制的內容過多，彈性差，變化不靈活，管理成本加大。 （2） 缺乏對軟件成本

29、事先估計的有效控制。 在開發初期，對成本不夠關心，忽略對成本的控制，只有在項目進行到后期，實際遠離計劃出現偏差的時候，才進行成本控制，這樣往往導致項目超出預算。 （3） 缺乏成本績效的分析和跟蹤。 傳統的項目成本管理中，將預算和實際進行數值對比，但很少有將預算、實際成本和工作量進度聯系起來，考慮實際成本和工作量是否匹配的問題。 成本管理方法的改進 目前常用的軟件項目管理工具都側重于某一方面的功能，如微軟的 project2000側重管理、規劃任務，并在項目執行過程中跟蹤這些任務，偏向于進度安排與跟蹤控制；rup側重于用戶需求

30、的描述；pvcs側重于軟件變更管理。這些軟件項目管理工具都在不斷的完善其功能，雖然也有成本管理的功能，但總的來說大多數都不能用來進行軟件成本估計，缺乏事先成本控制，不能和估計數據自動化協調，不能自動化地利用歷史數據庫中的數據。當前的項目管理工具并不能滿足成本管理的需要。 針對以上成本管理過程中出現的問題，以及目前軟件項目管理工具的不足，文章提出了一種改進的管理方法，將進度和成本聯系起來考慮使工作量和實際成本匹配的方法。并且結合已有的成本估算方法，同時將過程數據庫引入到軟件項目管理中，給出成本管理系統的原型設計。系統采用先進的估算方法解決了成本估算準確度差的問題，工作量和實際成本匹配的

31、方法進行成本的績效分析和跟蹤使得項目成本能夠控制在預算范圍之內。 2.1系統總體設計 雖然目前已有不少項目管理軟件，但一般只是管理軟件進度和跟蹤監督，和軟件估算是項目獨立的，而且目前還沒有成型的軟件項目成本管理軟件，我們以 為指南，研究軟件開發過程中的特殊性，結合現有的軟件成本估算技術和一般行業的項目管理技術，以進度、人員、成本，變更為中心，提出了軟件成本管理的具體實施方案。并以此為基礎對系統的功能進行分析和設計。 2.2 系統功能設計 （1）成本估算是項目成本管理的一個非常重要的部分，精確的軟件成本估算是進行有效的軟件管理的一個必不

32、可少的組成部分。常用的軟件估算方法有：算法模型法、專家判定法、類比估算法等，這些方法各有優缺點。本文采用文獻2中提到的方法，即將各方法結合起來，互相取長補短，由層次分析法得到各種估算法的權重，再由權重合成法得到估算成本。它可以提高軟件成本估算的精確度。 定義 設f1，f2，fm為m個不同模型所得的估算值，wi（i=1，2，m）為第i個模型的權重，則 f 且 即為權重組合估算模型。 假設用cocomo模型3估算成本為mm1，tdev1，用delphi技術估算成本為mm2，tdev2，用類比估算法估算成本為mm3，tdev3，則由權重組合估算得： mmw1mm1w2mm2w3mm3 tdevw1 tdev1w2 tdev2w3 tdev3 這里mm是軟件開發需要的人月數，tdev是軟件開發周期。 （2）預算變更管理可以記錄每一次資源和成本的變化，保持完整的有注釋的歷史記錄。&#