軟件開發項目總結匯總十篇

序論：好文章的創作是一個不斷探索和完善的過程，我們為您推薦十篇軟件開發項目總結范例，希望它們能助您一臂之力，提升您的閱讀品質，帶來更深刻的閱讀感受。

篇（1）

軟件公司開發項目的是軟件開發公司的實際經營活動，項目的實際成果直接影響企業的持續健康發展。在實際的軟件開發項目進行的過程中，成本是影響項目經濟效益的重要因素。與此同時，軟件開發行業間的市場競爭日益激烈。這也就使得軟件開發企業需要迫切的進行開發項目的成本核算。科學合理的成本核算，有效的成本控制策略，能夠有效的降低軟件開發項目的成本，從而保障軟件開發企業的經營成本。在對軟件開發項目的成本核算時，需要合理的對軟件開發的全過程成本進行核算，準確的對項目的開展狀況進行評估，確保項目的進度和收益，從而增加軟件開發企業的競爭力，增加軟件開發公司的市場份額，促進軟件開發公司的持續健康發展。

 

一、軟件開發項目成本核算內容

 

現階段，軟件開發項目的成本核算內容主要分為直接成本和間接成本。軟件開發項目的直接成本主要包括項目在實際的開發過程中的人工費用和材料費用、各類直接消費。軟件開發項目的間接成本是各項非直接費用的綜合，主要有管理費用、員工福利、各類保險等。在進行軟件開發項目成本核算時，需要對軟件開發項目的全過程進行成本核算。其中在進行項目立項和招投標階段，需要對項目的實際情況：材料、工時、工作量、交貨期的相關情況進行實際分析，此外，和需要有效的對相關合同款項進行審核，避免在軟件開發項目中，相關合同條款不清晰，給軟件開發企業帶來成本增加。在項目的執行過程中，先量化項目，項目進度與動態成本控制，成本偏差與進度偏差，項目預算與項目實際執行每月比較，并關注項目的關鍵點和瓶頸，并合理的進行風險評估。最后進行項目的審核，完成項目收尾。

 

二、軟件開發項目全過程成本核算

 

(一)項目立項和投標階段

 

相關成本核算人員需要實際的清晰軟件開發的具體情況，并合理的配合相關預算人員合理的進行成本預算，從而促進軟件開發項目的成本核算。在實際的項目立項和投標階段，成本核算人員需要對軟件開發項目的材料、工時、控制點(工作量)、交貨期等內容進行科學有效的分析，從而便于成本核算的真實性和有效性。此外，還需要進行嚴格的合同審核工作。在進行合同審核時，不但需要對公司自身的先關條款進行審核，還需要對對方的條款進行有效的審核。并對合同的相關權利和義務、責任進行有效的分析和明了，避免責任不清的情況發生。同時，還需要對合同中的文字、字面表達、相關條款是否完備。還需要注意合同的簽訂手續是否完備，并結合《合同法》的相關內容，對合同的風險防范措施進行優化，從而避免合同糾紛的發生，避免軟件開發企業的不必要成本。

 

(二)項目的風險控制

 

項目的風險控制是確保軟件開發項目進行的重要工作，是避免不合理之處發生的重要工作。首先，在實際的風險控制中，需要注意公司的外匯風險控制，合理的對國際市場外匯走勢進行分析，合理的進行事前、事中、事后控制，避免經營外匯風險的發生。其次，有效的對技術風險進行規避和控制，制定有效的人才留住措施，避免人才的流失，科學合理的對相關技術人員進行培訓，合理的對新的領域進行邁進，客觀公正的對新技術和新開發方案進行評價，從而有效的控制技術風險的發生。再者，安全風險是影響軟件開發公司的重要因素，一旦開發方案泄漏，避免會造成整個項目處于停滯階段，影響項目的交貨期，并造成大量的成本流失。因此，需要采取科學有效的保密措施，并合理的進行知識產權保護，規避安全風險的發生，從而有效的降低不合理的成本支出。

 

軟件開發企業需要建立有效的風險控制措施，并規范風險控制管理過程中，合理的進行風險識別、風險分析、風險計劃，風險控制等等，從而有效的實現風險控制，避免軟件開發企業不合理的成本的發生。

 

(三)項目執行階段

 

在項目的執行過程中，需要合理的對項目的料工費進行分析與核算。對直接人工成本和間接人工成本進行核算，并有效的結合材料費。直接人工成本主要是將參與項目執行人員的工時進行整合，并結合項目人員的工資情況，將參與項目人員的總的人工成本進行累加，從而得到項目的直接成本。而間接人工成本的構成較為復雜，也就使得間接成本核算工作較為困難。在進行間接成本核算時，需要將參與項目開發員工的福利、各類保險、培訓費用等納入到成本核算中。材料費用是項目研發過程中的實際消耗的材料費用，是直接成本。對于其他間接成本也需要有效的進行記錄與核算，從而有效的完成軟件開發項目的成本核算。

 

項目進度與動態成本控制，在實際的軟件開發項目執行過程中，項目的進度與動態成本控制是成本核算中的重要組成部分。現階段，軟件開發行業間的競爭日益激勵，這也就使得軟件開發企業需要合理的控制項目進度，避免出現交貨期到不能實現項目提交的情況，在保證項目質量的基礎上，有效的縮短工期，從而提升企業的競爭力。在有效的控制項目進度的基礎上，有效的展開動態成本控制，從而降低項目執行階段的成本，實現企業的持續健康發展。

 

成本偏差與進度偏差，項目預算與項目實際執行每月比較，合理的對成本偏差與進度偏差的分析。在進行項目預算與項目實際執行進比較，其主要比較內容包括：預算完工與實際完工，預算利潤與實際利潤，預算材料與實際材料，預算工時與實際工時。

 

關注項目的關鍵點和瓶頸，控制不好的差異，針對項目的關鍵點進行有效的分析，針對項目中的關鍵點，進行科學的成本核算，有效的控制項目中不好的差異，從而有效的提高軟件開發項目的成本核算的效果。

 

(四)項目收尾階段

 

在實際的軟件開發項目收尾階段，需要合理的對整個項目的成本進行系統的整合，并最終與初始的預算進行比較。并針對項目中不合理的成本支出進行有效的分析，并做好相關的預案避免下次項目再次出現。還需要對項目的工期，施工進度、暫停等內容進行總結，并有效的總結項目全過程的成本構成，合理分析期間的成本核算的不足之處，有效的促進整個項目的順利完成，實現軟件開發企業的持續健康發展。

 

三、結束語

 

篇（2）

進入21世紀后，伴隨著計算機技術和網絡技術的飛速發展，各種智能終端設備逐漸興起，也使得人們對于軟件的需求達到了一個前所未有的高度，推動了我國軟件產業的發展。而在軟件開發過程中，需要切實做好項目管理工作，提升管理水平，才能夠促進我國軟件產業的進一步發展壯大。

一、軟件開發與項目管理

簡單來講，軟件開發就是依照客戶的需求，構建軟件系統或者系統中的軟件部分，其是一項包括了需求捕捉、需求分析、設計、實現和測試的系統工程，需要借助某種本程序設計語言實現。軟件開發的主要流程包括：需求分析、總體設計、細部設計、編碼、單元測試、綜合測試、運行以及維護。項目管理則是指在一定的約束條件下，為了實現某個特定的目標，依照項目自身的內在邏輯規律所進行的系統管理活動。相對于軟件開發而言，項目管理需要遵循幾個基本的原則，一是依照分階段的生命周期計劃，進行嚴格管理；二是做好相應的階段性評審；三是重視產品控制；四是應用現代程序設計技術；五是確保開發人員的專業素質較高，同時對人數進行控制；六是必須能夠對結構進行清晰地審查；七是必須承認軟件工程實踐持續改進的必要性[1]。

二、基于軟件開發的項目管理實踐

以智能手機系統為平臺，針對手機軟件開發的項目管理實踐進行簡要分析和討論。

2.1需求分析

需求分析是軟件開發的基礎與前提，能夠獲取和記錄系統需求，確保客戶與項目團隊在系統需求變更上的一致性，避免軟件開發過程中不必要的彎路。需求分析法包括了用戶問卷調查、研討會以及原型展示等，需要安排專人做好相應的記錄工作，并及時對其進行總結和歸納，做好應對策略。在該項目中，軟件需要滿足的需求包括：適用于主流手機操作平臺，充分考慮不同硬件配置以及操作系統版本的兼容性；可以跨平臺運行，同時不需要占用過多的系統資源；確保數據連接的速率以及操作的流暢性等。

2.2設計編碼

系統設計包括了總體設計和細部設計兩個不同的階段，其中，總體設計應該大致規劃出軟件的功能模塊，做好相應的功能分區，并對其進行初步的設計分析，細部設計則需要給出每一個功能模塊的控制流程、算法以及數據結構等，確保每一個模塊都有不同的層次。對于一些難度較大、涉及面較廣的模塊，可以交給一些經驗豐富、心細縝密的技術人員完成，并做好模塊的測試與修改，保證其穩定可靠，盡可能降低風險與成本[2]。

設計完成后，需要進行編碼工作，采用代碼版本管理工具SVN，以確保各個子系統的功能都能夠得到最大限度的發揮，實現系統之間的功能互補，從而降低軟件開發的風險和難度，提高軟件過程的跟蹤率。

2.3測試運行

軟件測試并非單純的某個環節，而是貫穿于整個軟件開發項目中，制定出詳細全面的測試計劃，并對測試用例進行用心編寫。軟件中的每一個子模塊都應該由編程人員之外的技術人員進行反復測試，同時對測試過程中出現的問題進行記錄，提出相應的修改意見，由相應的編程人員進行修改。在對測試用例進行編寫時，需要對測試目標、測試環境、測試步驟、預期結果等進行記錄，形成具有代表性的數據信息。在測試完成后，需要首先在小范圍內，對軟件的子模塊進行試運行，確認無誤后再對軟件整體進行試運行，結合運行反饋結果，評估軟件的可靠性，采取相應的完善措施。試運行成功后，需要編寫相應的用戶手冊，制作視頻說明，幫助用戶了解和使用軟件，同時標注聯系方式，方便用戶進行反饋。

2.4后期管理

在系統安裝試用一段時間，具備相應的驗收條件后，需要進行驗收準備工作，對之前的工作進行總結，列出工作成果和相應的文檔，審查相關技術文檔中的內容和信息。應該對系統當前的完成狀況進行明確，對于尚未完成的部分，應該采取有效策略去完成，或者設置相應的回避措施，確保客戶在驗收時不會提出這些未實現的需求。在交付使用后，需要做好軟件維護工作，結合需求變化或者硬件環境變化對程序進行修改，確保其具備良好的實用性和適用性[3]。

三、結語

綜上所述，軟件開發項目管理與一般的項目管理存在著很大的差別，需要相關技術人員結合軟件開發的具體流程，做好全過程管理，保證管理效果，在完成預定功能目標的基礎上，提升軟件的可靠性與安全性，確保軟件的有效應用。

參 考 文 獻

篇（3）

0引言

風險無處不在，它在任何軟件開發項目中都有可能發生。風險有幾種形式：自然災害、安全漏洞、人力資源缺失、第三方供應商問題、金融危機、不穩定的商業環境和項目失敗。因此，在進行軟件開發前，工程師應該制定一個風險管理計劃。該計劃涉及風險評估和風險控制，工程師應列出軟件開發過程中可能發生的問題，并列出這些問題的解決方案。這樣，即使軟件開發過程中遇到問題，風險管理可以幫助把有害影響最小化，從而避免軟件開發項目的失敗。然而，并不是每個人都關注風險管理，人們也很容易忽視風險管理的影響。實際上，風險管理對于軟件開發項目非常重要，因為風險是影響項目成功的重要因素。因此，本文試圖通過對文獻的分析，找出一些有效的風險管理方法，讓開發人員了解風險管理的意義。

1文獻綜述

風險管理是項目成敗的關鍵因素，也是項目管理的本質。因為風險管理可以幫助開發人員發現項目的威脅，并將其最小化(Alhawarietal.,2012)。此外，成功的風險管理可以幫助項目經理按時交付項目(Grantetal.,2006)。有效的風險管理需要找到風險，而不是否認風險、隱藏風險(GrayandLarson,2008)。風險管理有五個主要階段，即風險規劃、風險識別、風險評估、風險響應、風險監控與溝通(Lester,2014)。項目團隊應該關注風險響應、監控和溝通。響應意味著控制，它指的是制定一個風險管理計劃，將風險識別并按級別排序。監控包括標記一個已知的可能發生的風險，并改變該風險的可能性。溝通包括讓項目團隊中的所有人都知道風險管理的結果。風險響應、監控和溝通對于風險管理過程是必要的。項目團隊聚在一起討論并制定最新的風險管理計劃，能提高按時完成項目的機會。Otniel、Nicolae、Claudiu(2012)提出通過對軟件開發項目的分析，發現項目管理的本質是風險管理，而風險管理的方法有多種，最有價值的方法是評估方法和管理方法。評估方法將風險管理視為事后評估過程，該方法旨在找出導致項目失敗的原因。

2分析

2.1風險管理的意義

風險管理是項目管理過程的關鍵因素之一。有些風險是不可避免的，但風險管理可以解決問題。風險管理的主要功能是，如果在項目開發過程中發生較大的風險，風險管理將有助于控制風險，減少對項目的負面影響，以避免項目失敗。它還可以幫助項目團隊按時完成項目。然而，有些人認為在軟件開發項目的過程中進行風險管理是浪費時間和不必要的。我不同意他們的觀點，因為風險是影響軟件開發項目成功的一個重要因素，有效的風險管理可以處理風險，而不是讓項目一定成功。

2.2軟件開發項目中風險管理的基本步驟

軟件開發項目中風險管理有五個主要步驟。首先，開發團隊應該制定風險計劃，在風險管理過程中準備好所有的事情，例如定義項目經理和項目團隊成員的角色和職責。下一步是識別和分類風險，然后在軟件開發項目中標記這些風險。在此之后是風險評估，它與風險分析類似，項目團隊成員應該深入了解風險。風險響應是這5個步驟中最重要的，在這5個步驟中，軟件開發的項目團隊成員應該找到應對風險的解決方案。最后是風險監控和溝通步驟，這一步意味著對風險進行溝通和報告，讓所有開發項目團隊成員了解關于風險管理過程的最新信息。

3風險管理的兩種有效方法

篇（4）

軟件項目管理是指工作人員在軟件開發的全過程中通過引入科學的管理達到降低成本、保證產品質量和提高設計生產進度的目的。在實施軟件項目管理的過程中，相關工作人員首先需要清除項目的根本任務，保證軟件開發在分析、設計、編碼到測試的全過程中可以在管理者的控制下順利進行。軟件項目管理具有其自身的特點，目前常用的項目管理方法多是從原有的例子中總結經驗，這就要求項目管理者不斷總結實際項目中的方式方法，掌握軟件項目管理的理論模型和科學方法，保證軟件開發項目的順利進行。

1軟件項目管理的質量控制

1.1軟件質量概述

對軟件質量的定義與傳統意義上的質量概念相同，但同時為了提高項目管理中的實用意義，通常會根據軟件開發的特性進行調整。簡單來說，軟件質量可以定義為“無缺陷”的達到軟件開發前期的預想功能，但軟件開發企業通常將客戶需求作為軟件開發的基礎要求，因此軟件開發企業對質量的定義需要進一步擴展，需要根據客戶的需求來制定本軟件開發項目的質量。軟件在開發的過程中必須要滿足用戶的需求，作為一項復雜的系統性工程，為了滿足軟件開發過程中各項定義和性能需求，就需要建立符合文檔化的開發標準，并相應的設計出符合本項目的質量特性及組合，當產品在驗收的過程中都能滿足這些質量特性時，就證明該軟件產量質量較高。

1.2軟件項目管理的質量保證概述

保證軟件項目管理質量是實現軟件開發順利實施的前提，目前，加強軟件項目管理主要可以從兩個方面進行把控：①軟件開發項目立足于客戶驅動，需要注意復審和校核方法的一致性，在這過程中需要通過制定一種客觀的標準來校驗軟件開發過程及其工作成果的質量，通常情況下軟件質量標準由質量保證小組完成。②軟件項目的質量保證需要樹立管理者驅動的觀點，在這過程中清楚的認識到通過何種措施可以提高產品質量，并需要建立何種管理和控制機制才能確保這些措施的順利執行，它必需要包括項目所需要的質量特性、可實現的質量要求以及可顯示的已達到的質量要求。

1.3軟件項目管理的質量保證研究

軟件的質量保證，是貫穿在軟件開發全過程中且具有獨立特性的第三方審查活動，在軟件項目管理的過程中起到重要的作用。由于質量保證措施在軟件開發行業引入時間較短，因此很多軟件企業并沒有建立與軟件項目相配套的管理人員和工作方法，完整的軟件質量保證體系還并未在軟件開發行業中建立起來。軟件質量保證通過引入第三方的角度來監控軟件開發的執行情況，檢測軟件開發項目是否遵循既定的開發計劃，管理層可以通過對反映產品和過程質量的信息和數據審查，及時調整軟件開發的方案和進程，保證軟件可以滿足評審和測試需要，最后實現企業可以開發出具有高質量的軟件產品。

2軟件項目管理控制方法的基本原則

2.1注重項目開發過程中的層次性

軟件開發根據項目的不同具有很大的差異性，根據軟件設計的層次階段不同可將軟件項目計劃分為高級計劃、階段計劃和低級計劃。在軟件項目的前期需要對項目進行階段的劃分，這種計劃稱為早期計劃，這時需要對人、財、物三個要素進行劃分。在進行不同階段交替的過程中，需要對下一階段進行提前的規劃部署，通常稱作階段計劃。在階段計劃中需要明確各項目的負責人、起始時間節點、設備資源以及各個子任務之間的依賴關系等。低級計劃是指軟件開發人員的個人計劃，這部分通常由開發人員根據自身的實際工作情況進行制定。在實際的軟件開發過程中通常可以分為4個級別，而較小的軟件項目也會分為2個級別，因此在進行軟件項目管理的過程中需要注意開發過程中的層次性。

2.2注重運用過程化的思想指導開發

能力成熟模型是目前軟件開發項目中廣泛使用的方法，其核心思想就是將軟件開發看做為一個過程，因此在軟件項目中運用過程化的思想指導開發，可以保證軟件開發更加科學化、標準化，企業能夠更好地實現商業目標。能力成熟模型定義了包括初始級、可重復級、已定義級、已定量管理級、優化級在內的五個等級，當軟件開發進入到可重復級時，這時就可以認為該軟件項目具備了基本的控制能力。當一個項目成功后，即可認為下一個項目也可以成功。通常情況下，在項目實施的過程中需要根據項目的實際運行情況對項目計劃進行修改，對重新策劃的內容都包含在可重復級中。目前，大部分的軟件開發公司都難以達到能力成熟模型可重復級，但也要樹立過程化的思想來保證軟件開發的順利完成。

2.3注重歷史數據的運用和積累

軟件開發通常情況下是對未知項目的創新，因此很多項目在研發初期對需求不能清晰理清，但高質量的項目運作必須建立在對需求的準確把握上，因此在進行軟件項目管理時首先就需要把模糊的需求盡量準確化。為了提高軟件項目管理計劃的準確性，就要充分利用以往類似項目的歷史數據，不僅成功的數據具有參照價值，失敗數據也同樣具有借鑒價值，可以根據這些歷史數據彌補開發前期需求的模糊。通過對這復用資源的積累，可以將以往的成功經驗高效傳承。

3結束語

隨著社會經濟的不斷發展，信息技術行業取得了前所未有的成就，但隨著信息技術的發展不斷進入深水區，社會各界對于信息技術的發展也提出了更高的需求。隨著軟件開發不斷趨向復雜，技術人員在開發的過程中面臨著軟件開發績效差的問題，為了有效提高軟件開發的實際效率，項目管理被人們更多的應用到軟件開發的過程中。

參考文獻

[1]鄧子云.制訂項目計劃的方法與策略.企業技術開發，2004（1）：24~26.

[2]白思俊.現代項目管理（上、中、下）.北京：機械工業出版社，2002：23~37.

篇（5）

近期，我在負責的一個小型軟件開發過程中忽視了小型軟件項目的特點，結果是麻煩事情特別多，差點兒項目要以失敗告終。但從另一個角度來看，項目的大與小并沒有本質的區別，很多方法是共通的，但必須要切合實際來靈活運用。本文結合我在這個小型軟件開發項目中得到的經驗和教訓，首先分析小型軟件開發項目中常見的問題，然后提出相應的解決辦法。

一.小型軟件開發項目中常犯的錯誤

小型軟件開發項目一般具有項目需求相對較少、人員較少、開發周期較短的特點。因此，小型軟件開發看起來都比較簡單，比較容易成功，因而人們往往忽視了小型軟件開發的管理，其實這是一種誤解。例如，由于人員較少就分工不明確或由于開發周期較短就忽視項目計劃和進度表的控制，結果是經常會出現開發流程混亂，重編碼輕設計，甚至到編碼完成后再回頭編寫各種文檔資料等現象。從我這次的開發經驗看來，在小型軟件開發管理中最容易犯以下的錯誤：

(1)沒有重視項目計劃，做一天和尚撞一天鐘

往往由于項目較小，便很草率地制定一個開發日程表，也沒有認真地估計項目難度，結果是實際完成時間與估計完成時間往往有較大差別。還有人是這樣說計劃的："計劃、計劃，紙上畫畫，墻上掛掛，計劃不如變化"。因此，由于觀念的不正確使到計劃管理經常成為空話，特別是在小型軟件開發中影響計劃的因素太多時或加上想省事怕麻煩，結果計劃管理就形同虛設了。

但是，軟件進行項目管理的目的就是綜合各種因素，制定合理的計劃，并通過計劃的實施，使其規范化，從而提高人員效率，降低項目成本。因此，軟件開發無論項目大小，其實都需要計劃過程。只是對于小型軟件項目來說，計劃階段可能切換的很快。例如，有時候項目負責人只是腦海里想一遍就把計劃確定了。但項目負責人必須心里要清楚：有時候想省事兒，可能反而會更加費事兒。俗語有云：一年之計在于春、一日之計在于晨。其意義不是說越早做越好，而是闡述一個目標的實現需要盡早做規劃。

(2)沒有完整的開發文檔，無意之中增大項目風險

一個完整的軟件開發項目應包括有相當多的相關文檔：例如項目開發計劃、軟件需求說明書、概要設計說明書、詳細設計說明書、開發進度月報、測試計劃和開發總結報告等。而在實際中，許多小型軟件項目只有簡單的流水帳式的開發日志。最常見的借口往往是以文檔滯后來解釋文檔的不健全，這似乎沒有什么不妥，而且好象還理直氣壯的。但如果將軟件項目叫做"工程"的話，再將其與建筑工程相比較，那我們也就可以說：大樓有了，圖紙滯后，這是很可笑的。還有許多開發人員認為軟件設計已經在其腦子里完成了，在其意識里工作就只是一堆需要敲出來的程序，既然能直接敲得出來，自然沒必要再做寫文檔的重復工作。

這樣做的結果使到設計思路和實現細節在項目團隊內的交流很困難，開發過程會由于需要大量嘗試性、重復性工作而變得緩慢，而且會出現許多意想不到的大大小小的問題，狼煙四起之時最重要的工作就變成了"救火"。所以，在小型軟件項目里會"救火"的技術人員會成為大家推崇和依賴的英雄。但這種"救火"式的行為最終結果卻是項目延期成了普遍現象，產品質量也得不到保證。另外，如果這個英雄半途離開，那沒有任何文檔支持的中間結果對其它人來說基本上就是"一堆垃圾"而已，項目被迫中斷就成了家常便飯。

(3)人員沒有技術分層，職責不清分工不明

許多小型軟件開發項目一直采用個人主義式的開發方式，決定了規范化開發方式的不被認可。對規范化管理的淡漠，抑制了團隊工作效率的提高，甚至扼殺了其生命。所以，小型軟件項目往往要求主要的項目人員從各個方面都得是非常出色的，不僅要全面地掌握系統架構知識、具有業務分析和系統設計能力，而且還得是多種流行開發工具的專家、數據庫的專家、網絡配置的專家等，但這樣的全才和通才往往是可遇不可求的。

因此，小型軟件項目更需要做技術分層，例如系統分析員、需求分析師、程序員、測試員等。在項目開發中相應的角色必須要有相應的專業人員來擔當，當然可依據項目規模大小和現有人員來合理配置。這里強調技術結構分層和技術人員劃分，更多的是技術責任的明細，而非具體個人的技術定位，將技術任務和相應的責任劃分到具體的崗位、將崗位落實到具體的人，這與具體技術人員身兼數職是不矛盾的。

而我們經常看到的是在許多小型軟件開發過程中，人員職責不清、分工不明的現象非常嚴重。有的甚至從調研到分析、設計，到開發、調試，再到測試一氣呵成。先不說工作量有多大，僅從項目的風險來說就是非常可怕的，更不用說最大限度發揮開發人員的長處了。

二.小型軟件實行項目管理的方法和步驟

為什么小型軟件開發項目卻會面臨更多的失敗風險呢?在我所負責的項目面臨下馬前的每一個夜晚，我的腦袋里一直在思考這個問題。也許是多日思考的沉淀，也許是思緒在不停的四處游蕩后的突發靈感。使我明白到原來決定小型軟件項目成敗的核心因素，是有沒有堅持進行實行項目管理。現總結為以下幾個要點：

(1)樹立小型軟件開發也需要項目管理的理念

但凡專業的軟件開發人員都學過《軟件工程》這門課，縱觀這些指導性的理論以及建議。我們應該要樹立即使是小型軟件開發也應該在一定程度不要違背開發理論，必須要遵從于工程化軟件理論的原則和方法，落實規范化的管理。否則，失敗的風險將伴隨著整個開發過程，而且越到后期失敗的可能性會越大。

對小型軟件項目而言，最急需的不是設計方法，也非分析方法，當然也不是開發方法，而是管理方法。因此，無論項目大小都必須要遵循一定的項目管理步驟。

從概念上講，軟件項目管理是為了使軟件開發能夠按照預定的成本、進度、質量順利完成，而對成本、人員、進度、質量、風險等進行分析和管理的活動。實際上，軟件項目管理的意義不僅僅如此，進行軟件項目管理還有利于將"英雄"式的開發人員的個人開發能力轉化成團隊的開發能力，團隊的軟件開發能力越高，就越能減小項目的開發風險。

(2)項目需求的確認

在軟件開發中，最重要的活動是要明確項目的范圍、需求和提出至少一個可用的軟件架構方案。在明確項目范圍的過程中，不能認為是小型軟件開發項目就馬馬虎虎的、想當然的認為已經了解了客戶的真實需求。項目經理應要就項目的邊界、功能、限制條件等與客戶進行協商，并應以需求說明書和功能說明書的形式把客戶的需求記錄下來，并且和客戶達成一致的認識和理解。在此基礎上，再提供至少一個合適的軟件架構方案，并且完成原型系統。原型系統的目的不但是為了驗證技術上的可行性，而且是為了給客戶一個感性的認識，更好地完善對需求的理解和確認。

(3)人員角色的安排和定義

角色定義包括個人或團隊的行為和職責，包括設計人員、編程人員、測試人員、項目管理人員和輔助人員。比較小的項目往往是幾個人來完成，這幾個人基本上從頭到尾參加開發。而且由于項目小，項目負責人除了負責分析、設計和協調的工作外，也要參加編程。但在此過程中必須要合理進行人員角色的安排和定義，將技術任務和相應的責任劃分到具體的崗位，再將崗位責任落實到具體的人身上，避免推卸責任或由不專業的人馬虎應付了事。例如，一個人可以同時擔當幾個角色，一個角色也可以由幾個人來共同承擔，但前提都是要有責任的、有專業技能的。

(4)建立合理的開發流程，注重過程的銜接

一句話形容就是"麻雀雖小，五臟俱全"。也就是說即使是小型軟件的開發，仍然應該遵循軟件開發的一般規律，必須的步驟和合理的開發流程還是不能省略。不但要建立合理的開發流程，而且還要注重分析與設計過程的銜接。當然，小軟件項目也有它自身的一些特點，實行起來可以相對靈活些。

例如：①要強調協調幾個人的工作比某一開發人員完成一段編碼更重要。因為在協調上出了漏洞，就可能導致很大的問題。②是給每個開發人員要有明確的任務書，也就是說每個開發人員必須非常明確自己的任務，而且這些任務是采用文檔來表示。③是要讓每個開發人員都清楚自己所做的工作在整個系統中處于什么地位，避免各人的代碼編寫完畢之后又要重復修改。

(5)重視文檔化過程

在小型軟件項目中有兩個特點：①是由于人員少，意味著不同人員的程序之間交互、接口相對少一些;②是由于人員少，往往是同樣的幾個人從頭到尾負責這個項目。但這兩個特點會讓人容易犯錯誤，就是往往是幾個人碰一下頭，討論一下最基本的任務分工便分頭去做自己的工作了，沒有一份較正式的開發文檔。當有人對任務理解有偏差時或有誤解時，就可能會造成返工。因此，小型軟件開發項目也不應該忽視文檔化過程的作用。

文檔化有三方面的作用：①是有助于團隊溝通，能給別人一個交待以及給自己一個備忘。②是有助于自我理解，一般來說如果你不能寫下它，你就可能沒有真正的理解它。③是有助于連貫一致性，它會使團隊擁有可重復的優勢。雖然文檔是如此重要，但在小型項目中有用的文檔最好也不要太冗長繁雜，一般1-2頁的過程說明就足夠了。

(6)使用好制度與紀律這個工具

篇（6）

中圖分類號：TP311 文獻標識碼：A文章編號：1007-9599 (2011) 13-0000-01

Demands Risk Analysis of Software Development

Sun Huiqing

(Wuhan Institute of Communication Command,Wuhan430010,China)

Abstract:This software development enterprises should be a greater problem.Based on the current status of the software industry's demand risk analysis,the demand for software development projects listed in sources of risk and analysis,summarized the causes of demand risk and the impact on the success of the project,software development projects is given in the demand for risk management and control recommendations.

Keywords:Software development;Demands risk;Risk analysis

一、對需求風險的理解

產品開發過程中，由于產品需求本身的隱含性、用戶與開發者之間的溝通障礙，以及需求隨著時間、用戶的變化而變更等原因，可能使需求分析偏離實際需求而最終導致產品開發的失敗，這種可能性稱為需求風險。軟件開發項目風險是指在軟件生命周期中所遇到的所有的預算、進度和控制等各方面的問題，以及由這些問題而產生的對軟件項目的影響。需求分析是軟件開發過程中最初始、最基礎的工作，也是最重要的工作之一，其成敗將直接并最終決定軟件開發的成敗，并且呈倍增效應。需求分析的關鍵是使隱含的需求明確，使變更的需求可控，采用座談會、需求調查表、需求啟發、角色扮演等方法可以使需求明確化；采用面向對象的方法及UML工具、領域專家的全程參與、需求分級、二次開發接口等方法可以使需求變更處于可控范圍內。實踐證明，這些都是控制需求風險的有效方法。

二、需求的獲取

（一）產品前景和項目范圍。應該在軟件開發項目早期，編寫一份包括業務需求在內的前景和范圍文檔，并將它作為添加新需求和修改現有需求的指導。

（二）需求開發所需的時間。將每個軟件開發項目中需求開發所耗費的實際工作量記錄下來，這樣就可以判斷出需求開發是否充分，并可以改進未來項目的工作計劃。

（三）需求規格說明的完整性和正確性。為了確保需求是客戶真正需要的，應該以用戶任務為中心，應用用例技術來獲取需求。

（四）創新產品的需求。對軟件開發項目中的第1個產品，不太容易把握市場對軟件產品的反映。

（五）定義非功能需求。由于我們一般都會強調產品的功能，所以很容易忽略產品的非功能性需求。

（六）客戶對產品需求意見一致。確定那些主要的客戶，并采用產品代言人的方法，保證有足夠的客戶代表的積極參與

（七）未加說明的需求。一般的客戶會有一些隱含的期望要求，但并未以文檔的方式說明出來。盡量識別客戶可能做出的任何假設。

（八）把已有的產品作為需求基線來源。把通過逆向工程發現的需求編成文檔，讓客戶來評審這些需求，確保其正確性和相關性。

（九）根據需要提出解決方案。軟件產品分析人員必須提煉出隱藏在客戶提出的解決方案背后的真正意圖。

三、需求風險的來源

很多開發項目在確定需求時都面臨著一些不確定性。當在開發項目早期容忍了這些不確定性，并且在項目進展過程當中得不到解決，這些問題就能對項目的成功造成非常大的威脅。如果不控制與需求相關的風險因素，就很有可能產生錯誤的軟件產品或者拙劣地建造預期的軟件產品。每一種情況對產品來講都可能致命的。

需求風險的來源包括：沒有足夠用戶參與、不斷增加的用戶需求、模棱兩可的市場需求、不必要的特性、過于精簡的規格說明、被忽略的用戶分類、不準確的產品開發計劃。

軟件開發項目風險中與客戶相關的風險因素有：（1）對軟件產品缺少清晰的認識；（2）對產品需求缺少認同；（3）開發者在做需求調查中客戶參與不夠；（4）市場中沒有優先需求；（5）不確定的需要導致出現新的市場；（6）不斷變化市場需求；（7）缺少有效的需求變化管理過程；（8）對需求的變化缺少相關分析等。

四、需求風險的管理

（一）制定風險管理計劃。對于一個軟件開發項目，你可以把控制風險的計劃放在軟件項目管理計劃里面。但是一個大項目則需要有一份獨立的風險管理計劃，包括用于識別、評估、編寫、跟蹤產品開發風險的各種方法與途徑。這份計劃還應包括風險管理活動的角色和責任。通常情況下，項目小組為他們的關鍵活動制定了計劃，但是在項目中并沒有按計劃去實施或者沒能按實際情況進行及時的調整。一定要堅持按照所采取的風險管理活動計劃去執行。項目的進度安排上也應該要給風險管理留出足夠時間來確保項目并未浪費早期投資在風險計劃制定上面。工程項目的工作分類細目結構中包括降低風險的活動、狀態報告，與更新風險清單。和其它項目管理活動一樣，需要建立起周期性的監控措施。保持對十來個有最大危害的風險的高度重視，并追蹤降低風險措施的有效性。當完成一項活動后，重新評估那項風險的可能性和影響，更新風險清單和其它相關的計劃。當控制住原本有很高優先級的風險后，必然有新條目會進入前十條。值得注意的是，不要僅僅因為完成了一項降低風險的活動而人為增加一條風險來進行控制。應當想想降低風險的方法是否真的減少了風險的危害，使它減少到了一個可以接受的水平。

（二）具體管理措施

1.首先要明確你當前軟件開發項目面臨的一些與需求有關的風險，不要把當前的問題當作風險，一定要是那些還未發生的事情。將風險的因素編寫成文檔，為每項需求風險推薦至少一種可能的降低風險的方法。

2.召集代表開發、市場、客戶和管理各方面的涉眾召開風險“集體研討”會議。盡力找出更多與需求有關的風險因素。估計每項風險發生的可能性及其影響，兩者乘積就是風險危害值。通過按風險危害值降序排列找到最高的五項風險。為每項風險安排一個負責人負責實施降低風險的活動。

五、結束語

軟件開發項目中的需求風險是所有風險中的一個不可忽視的組成部分，對其認識的必要性不言而喻，應該重視對它的分析，對需求風險的合理管理也是軟件開發項目項目管理中不可或缺的部分。

篇（7）

任務管理――明確任務，是解決沖突的根源

明確的工作任務和職責劃分是項目順利實施的必要前提之一，但軟件項目的特殊性使得項目管理中至關重要的“范圍管理”（Scope Management）遇到了很大困難，某些子系統的開發任務在業主與合作商簽訂的項目合同中進行了明確的定義，但仍然有許多任務需要雙方在實施過程中逐步明確。在合作項目中，這種情況產生的后果相對更為嚴重，因為項目團隊的工作方式是合作方式，當因工作任務不明確而產生問題時，極易在來自不同組織的團隊成員間產生矛盾，從而引發沖突。

由于軟件開發項目本身的特點，在項目啟動階段就給出完整的系統需求是極為困難（甚至是不可能）的，在許多情況下，隨著開發進程逐步確定需求，以滿足實際環境的不斷變化不僅是權宜之計，而且更是現實的需要。另一方面，在大多數軟件開發項目中，需求的逐步細化或更改盡管是不可避免的，但也是可以管理的。一般而言，在某一時點上的需求都包含兩部分的內容：已經明確確定的部分和目前難以明確確定的部分，而“迭代式”軟件開發過程的目標就是隨著開發過程的深入逐步減少尚未明確確定的需求，并同時增加明確確定的需求。

“迭代式”軟件開發過程的主要原理是：在軟件開發項目（尤其是一些大型軟件開發項目）中，在項目開始階段，需求中難以明確確定的部分占有相當大的比例，因此在制定項目計劃時基本上無法準確估算其工作任務的范圍、進度以及相關的費用，這就給項目實施帶來了極大的風險。在這種情況下，軟件產品的第一版本（而不是軟件原型）反映了需求中已經明確的那一部分的功能，此時，用戶可以使用這個第一版本的軟件并在使用過程中提出進一步的需求，然后項目團隊可以根據上述相對更加明確的需求開發第二版本。在第二版本的軟件開發過程中，用戶可繼續使用第一版本的軟件（因為該版本軟件是一個實際的完整產品而非原型，因此除了功能相對較弱外，用戶基本可正常使用）。上述“迭代式”的軟件開發過程能夠在一定程度上有效降低大型軟件開發過程中的風險。

但這種“迭代式”軟件開發過程在合作型軟件開發項目中會遇到一些困難，其關鍵在于：在這種方式下，項目實施過程中許多工作任務是逐步確定的，甚至到底要推出多少個版本在項目啟動階段也很難精確確定。另一方面，合作項目的合同卻在項目開始階段就需要簽署，而合同的關鍵部分――項目費用在采用迭代式開發方式下很難在項目的開始階段就確定，當然如果項目費用的支付是按照實際費用進行結算的話，這個問題并不存在。但在目前國內許多軟件項目中，業主方往往傾向于使用“固定價格合同”以控制費用風險，這一合同形式要求對項目費用有相對明確的估算，這恰恰與“迭代式”軟件開發方式產生了矛盾。

解決這一矛盾的方法之一是采用與之相適應的“迭代式合同”，即在項目的第一階段，有關的工作被分為兩部分：已明確確定的工作和尚未明確確定的工作，其工作任務內容分別來自于已經明確的需求和尚未明確的需求，其中明確確定的工作必須在第一階段完成，并給出明確的費用估算，而尚未明確確定的工作在第一階段可以是部分完成并在今后的階段中繼續進行；當第一階段結束后，業主方支付確定的工作任務的費用以及已完成部分的尚未確定的工作任務的費用（這是由于費用結算是分階段進行的，而工作任務的執行則是連續的，因此有可能根據實際的需要，某些尚未明確的、從而未在項目計劃中反映的工作內容也已經在項目實施過程中完成了），并對剩下的工作進行重新估算，這樣反復進行直到項目完成（如圖1所示）。

這種合同制定方法使得業主方與合作商共同承擔項目實施過程中的風險，隨著項目實施進程的不斷推進，產品需求和相關的工作任務變得越來越明確，工作任務中的“已確定”部分比例越來越高，雙方所承擔的風險也隨之降低。

利益管理――建立開放的、互相信任的項目團隊文化，平衡各方利益

當項目團隊成員分別來自于業主方和合作商時，利益沖突幾乎是不可避免的，尤其是對于涉及相對復雜技術的軟件開發項目，利益沖突往往是最難以解決的問題之一。

首先，在技術方案的制定過程中，合作商方面的團隊成員會傾向于選擇那些對于他們自己所在公司而言費用相對較低的方案，而這些方案卻常常不符合業主方的最大利益；另外，合作商方面提出的技術方案也經常會包含一些購買由其生產或經銷的產品或工具等，這些建議的提出并不一定是惡意的，甚至確實存在充分的理由，但在業主方看來，卻有可能成為合作商試圖損害其利益的證據。

在這種情況下，一種開放性的、互相信任的團隊文化的建設就有助于制定一個客觀而準確的項目技術方案和實施計劃。在許多情況下，召集一個由項目各方人士（包括沒有利益關系的第三方人士）參加的評估小組有時是十分必要的，這種評估不僅包括技術方面的評估，更應當包括經濟方面的評估。但從根本上來看，良好的團隊文化與規范化的評估流程相比，同等重要（有時甚至更為重要）。

在項目啟動之初就努力建立一種“項目導向”的思考方式對于解決各方利益沖突也能起到幫助作用，在這種思考方式下，項目本身的成功對于每個項目團隊成員和項目參與各方（包括業主方和合作商）均是首要的：如果項目失敗，則不僅業主方受損，從長遠來看，合作商的利益（其市場地位）也會受到損害。同時，對于那些來自業主方的項目管理人員而言，適當的“換位思考”也是需要的。例如，來自于合作商的工程師可能會建議購買由他們公司生產的產品而不是購買其他公司的（可能是價格相對低廉的）產品，初看起來這一提議自然是損害業主方利益的，但如果考慮到對相關產品的熟悉程度將有助于工作效率的提高從而最終節約人工成本，這種建議也是有一定合理性的。

信息管理――充分的溝通和參與是有效的激勵機制

篇（8）

關鍵詞：PSP；TSPi；UML；軟件開發；軟件工程

中圖分類號：TPG642 文獻標識碼：A

1引言

1.1實踐訓練的目的

在現有計算機軟件專業本科教育中，缺少一種系統的實驗實踐方法，讓學生綜合運用所學計算機理論知識，以適應實際軟件開發項目的需要，其結果是學生走向社會，沒有成熟的開發方法和經驗，需要大量摸索。為解決該問題，我們通過一個學生公寓宿舍管理系統項目，進行小組軟件開發過程方法實踐訓練，使學生掌握數據結構、算法設計、數據庫、軟件工程、程序設計語言等學科的知識和軟件開發的文檔國標，從而能夠融入到軟件開發項目小組工作中或帶領軟件開發小組工作。

1.2 實踐訓練的題目選擇

學生在大學期間都住校，對公寓宿舍的管理很清楚，對需求容易理解，容易做出需求分析，這是我們選擇開發學生公寓宿舍管理系統作為實踐訓練題目的原因。當然也可以選擇職工工資管理系統、學生成績管理系統作為訓練題目，業務需求盡量清晰簡單，而且系統不要太復雜。

1.3實踐訓練所需資料

(1) 教材

人民郵電出版社的《個體軟件過程》和《小組軟件開發過程》。《個體軟件過程》強調了項目的成功，首先建立在個體成員基本素養的基礎上，培養學生按時高效地生產出高質量的軟件產品并可對其工作質量進行預測的能力，提供工程師測量和改進工作方法的框架。《小組軟件開發過程》有助于學生把課本上學習的軟件工程理論轉變成實際開發工程中可操作的過程，重點在于告訴學生一種小組方法，角色分工，每個人在項目中如何承擔自己的崗位職責和積極協助其他成員完成工作，不斷地通過軟件開發工作取得個人進步和小組進步。只有通過個體開發工程師素養的提高和小組開發過程能力的不斷增強，才能實現組織級的CMM級別躍遷。

(2) 軟件工具

利用TSPi EXCEL制作項目計劃和追蹤項目進展，統計工作量，提高效率。利用VISIO制作用戶需求文檔和設計。

1.4實踐訓練評分標準

(1) 小組主要技術文檔是否齊全：30%。

(2) 小組開發過程執行情況：50%，包含項目手冊完整性、過程數據收集與按時提交情況、周例會組織與效果、計劃實際完成情況。

(3) 小組開發過程項目總結報告：20%。

過去實驗課，我們總是對每個學生單獨評分，現在以小組為單位進行訓練，小組每個成員的成績都要和小組項目總成績掛鉤，小組成績占30%，個人角色占70%。即使個人做得很好，但如果小組成績不好，也直接影響到個人成績。讓大家明白，小組項目的成敗與每個成員密切相關，正象一個足球隊一樣，需要全體隊員的相互配合，取得小組的勝利才是最關鍵的。

2實踐訓練重點內容

2.1個體軟件過程訓練

(1) 文檔規模估計方法

進行規模估計是軟件開發人員最基本的素養，掌握規模估計的方法才能對個人開發工作效率、進度有一個估算。文檔(需求、設計、使用說明書、標準制定)規模按文檔頁計算，界面設計以界面個數計算，分別用分鐘/頁、分鐘/個、分鐘/行作為開發文檔、界面、程序行的效率計量單位。先積累規模實驗數據，以后以此計算個人效率。實際項目開發效率的估算按單個練習時效率的30%計算即可。復雜程序或以前沒有做過的效率估算要估得更低一些，循序漸進，估算越來越準確，且不可操之過急、目標太高。

(2) 個人承諾管理的方法

通過具體事例讓學生明白，軟件開發本身有許多不確定性，沒有完全相同的案例可以說明我們能按時完成開發工作。因此，將承諾建立在個人實際工作能力的量化指標上，進行時間任務的計劃管理是十分必要的。一般來說，只要是認真工作，沒有被別的工作打擾，計劃一旦落后，不要指望靠加班完成，需要調整計劃，及時與對方溝通協商。

建立實際工作時間日志、程序開發時間表、缺陷管理日志等，認真對待PSP項目計劃與總結表，是掌握個人開發技能狀況的重要手段，也是兌現承諾的可靠依據。

2.2小組角色組成與分工

根據每個學生的個人愛好、性格、專長，知識結構，安排個人在項目中扮演不同的角色，承擔不同的職責，迅速掌握角色工作。

小組成員由項目經理、計劃經理、開發經理、質量經理、技術支持經理組成，計劃經理可以由項目經理兼任。項目組學生由4~5人組成。小組成員之間的關系參見圖1，角色職責參見表1。

圖1 項目組角色關系

表1 小組角色職責

2.3小組人員和諧工作的方法

以小組周例會溝通交流、目標管理、流程化管理，激勵組員為完成目標而工作，不斷取得進步。因開發實習工作時間集中，我們把周會議定為2天一次會議，養成及時溝通，使遇到的問題及時得以解決，同時把小組合作的意識培養起來。強調軟件開發的質量、功能范圍、進度三要素的管理方法，把目標管理與過程管理結合起來。

2.4多周期開發方法

學生們在軟件工程中學習了一些開發過程模型，最簡單的過程模型是瀑布模型，但瀑布模型要求一次把階段文檔都做好，而在實際開發中往往很難達到，且瀑布模型也沒有組織過程模型，可操作性差。TSPi多周期過程模型有組織過程模型，即使由于訓練時間短，不能進行多個周期開發，也可以通過把任務分配在多個周期中，分清主次功能和項目風險，把主要功能和高風險部分放在周期1中，提高項目的成功率。見圖2。

2.5軟件質量標準

學生對軟件質量的理解更多地停留在軟件是否能使用上，沒有軟件性能指標是否達標的概念，更沒有開發過程質量的概念。通過提供過程質量標準，質管經理監控小組在開發過程中是否達到過程質量標準，使學生掌握過程質量的相關知識，加深認識個體質量的重要性，不斷提高個人的開發能力。每個過程都有入口和出口標準，沒有達到入口標準的不能進行下一步，沒有通過出口標準的，該過程不能結束。

2.6項目總結

我們過去參與企業軟件開發活動比較多，項目總結往往留于形式。或者項目出現問題，非要找出責任人，總結會上項目組人員相互指責，最后不歡而散的情況較多，不利于今后的項目開發工作。該實習訓練強調過程總結，不把問題留到最后。每個過程階段的總結，重點強調要對角色不對人，肯定成績，發現角色不足，使小組成員在開發項目訓練中得到進步，建立學習型組織。

3實踐訓練具體步驟

實踐訓練的具體步驟如表2所示：

表2 實踐訓練的具體步驟

注：每個工作日8小時。

每個步驟都是一個實驗實踐項目，每個項目都有開始和結束條件，而且要求在安排的工作日內要完成指定的項目。即使完不成，通過開周例會總結分析原因，改進工作。通過這種把開發工作劃分成一個個小項目，培養了學生如何做項目任務分解、如何完成任務，要求有許多過程文檔，使學生真正理解軟件=算法+數據結構+文檔。

4實踐總結

學生通過該過程訓練，明顯感到實際開發過程和做作業有很大不同，開發訓練內容規范、過程可操作性強，把課堂所學書本知識一下串了起來，同時又學習了許多新知識，學生知道了如何組織實際軟件開發項目了。這種模式非常值得推廣。

參考文獻

[1] Watts S.Humphrey著. 韓丹,袁昱譯. 小組軟件開發過程[M]. 北京:人民郵電出版社,2000.

[2] Watts S.Humphrey著. 吳超英,車向東譯. 個體軟件過程[M]. 北京:人民郵電出版社,2001.

篇（9）

doi：10.3969/j.issn.1673 - 0194.2017.04.047

[中圖分類號]TP311.5 [文獻標識碼]A [文章編號]1673-0194（2017）04-00-02

隨著信息技術的不斷發展及普及，移動互聯網、云計算、大數據及物聯網等與現代制造業結合，越來越多的軟件項目立項。在軟件項目開發過程中，無論是用戶還是開發人員都會遇到各種各樣的問題，這些問題會導致開發工作停滯不前甚至失敗。軟件項目能否有效管理，決定著該項目是否成功。因此，如何做好軟件項目管理中的進度控制工作就顯得尤為重要。

1 軟件開發項目的管理現狀

國內外軟件開發行業競爭越來越激烈，軟件項目投資持續增加，軟件產品開發規模和開發團隊向大規模和專業化方向發展。因為起步晚，國內絕大多數軟件公司尚未形成適合自身特點的軟件開發管理模式，整個軟件行業的項目管理水平偏低，與國際知名軟件開發公司有一定的差距，綜合競爭能力相對較低。首先，缺乏專業的項目管理人員，軟件項目負責人實施管理主要依靠技術和經驗積累，缺少項目管理專業知識；其次，在項目開始階段缺少全局性把控，制訂的項目計劃趨于理想化，細節考慮不周，無法進行有效的進度控制管理，導致工作進度滯后；再次，項目團隊分工不合理，項目成員專業能力與項目要求不匹配，成員各行其是，出現重復甚至無效的工作，從而影響項目進展；最后，項目負責人不重視風險管理，沒有充分意識到風險管理的重要性，面對風險時缺少應急預案，使原本可控的風險演變成導致項目受損甚至失敗的事件。因此，必須在整個軟件開發項目周期內保持對項目的進度控制，當遇到問題時給出合理的解決措施，將重復工作、錯誤工作的概率降到最低，使項目目標能夠順利實現，使企業能夠獲得最大利潤。

2 軟件開發過程中影響進度管理的因素分析

項目管理的五大過程：啟動、計劃、執行、控制與收尾。軟件項目管理是為使軟件項目按時成功交付而對項目目標、責任、進度、人員以及突況應對等進行分析與管理。影響軟件開發項目進度的因素主要有：人的因素、技術的因素、設計變更的影響、自身的管理水平及物資供應的因素，等等。對項目進行有效的進度控制，需要事先對影響項目進度因素進行分析，及時地使用必要的手段，盡可能調整計劃進度與實際進度之間的偏差，從而達到掌握整個項目進度的目的。

2.1 進度計劃是否合理和得到有效執行

項目在開發過程中都會制訂一個進度計劃，項目進度和目標都比較理想化，在面對突況時沒有相應的應急處理預案，無法保證項目進度計劃的有效執行。主要體現在制訂項目進度計劃時由于管理人員自身專業局限性，對項目目標、項目責任人和研發人員和項目周期都有明確劃分，但對項目開發難度和開發人員能力考慮不足，假如因項目出現重大技術難題而引起項目延期，同時又沒有做相應的應急處理，勢必影響項目進度順利實現。

此外，沒有詳細的開發計劃和開發目標，開發計劃簡單不合理。比如：項目目標不清晰，項目組織結構和職責不明確，項目成員缺少溝通，不同功能模塊出現問題相時互推諉；每個開發階段任務完成情況不能量化；開發計劃沒有按照里程碑計劃進行檢查，進度出現延誤沒有相應處罰措施和應急措施，導致項目進度管理無法正常進行。

2.2 項目成員專業能力和穩定性

項目成員專業能力和穩定性是項目進度計劃順利實施的主要因素。在項目過程中，項目成員專業能力與項目要求不匹配，項目成員離開或者新加入都會對項目的進度造成不良的影響。

項目成員專業能力偏低，不能對自己的工作難度和周期有一個明確的認識，編寫的軟件代碼質量較差，可靠性不高，重復工作比較嚴重，就會延長研發時間，脫離原計劃制定的目標，導致實際項目進度與原計劃規定的進度時間點相差越來越遠。

項目成員穩定性包括人員離職或者參與其他項目和增加新人。原項目成員離開項目，項目分配的工作需要由新成員或其他項目成T來接手，接手人員需要對項目的整體和進度進行了解，消化吸收原項目成員已經完成的工作成果，同時占用一定時間與原項目成員交流與溝通，并且，每個人的理解能力和專業技術能力不同，在一定的時間內無法馬上投入工作，也會影響他們完成相同工作需要的時間，進而影響進度。

2.3 項目需求設計變更

項目需求設計變更對于軟件項目進度會造成極其嚴重的影響。由于項目負責人對項目目標理解不清晰，沒有充分理解用戶需求；或者為了中標需要，對項目技術難度考慮不深；或者用戶對需求定義的不認可，感覺不夠全面，提出修改意見，重新規劃，造成需求范圍變更。

項目負責人對于項目需求把控不嚴，不充分考慮用戶增加變更的功能對整個系統框架內容的影響，缺乏與客戶的溝通，忽略團隊協作和團隊成員之間的溝通，輕易修改需求，嚴重需求變更可能會導致整個系統架構的推倒重來，一般需求變更多了也會影響整個項目進度，造成項目延遲交付。

2.4 進度落后時的處理措施

在實際的軟件項目開發中，還有許多因素會影響和制約項目進度，沒有人能將所有可能發生的事情都考慮周全，在條件允許范圍內盡可能對項目開發過程按最壞情況多做預案，做到未雨綢繆，達到項目進度管理的預期效果。

項目管理人員在發現項目出現進度延遲后，需要及時與項目負責人進行溝通，查找問題根源并進行補救控制。同時，一定時間內了解項目組成員工作完成情況以及需要解決的問題，根據需要分解進度目標，做到日事日畢，嚴格按照項目進度計劃時間點實施，盡量減少進度延遲偏差出現的次數。按階段總結項目情況，評估本階段項目實現狀況是否與計劃要求一致，協調處理遇到的困難問題，對項目進度進行檢查和跟蹤分析，隨著項目開發的不斷深入，找到提高工作效率、加快項目進度的方法。

3 “智慧人社”管理信息系統項目的實現

3.1 “智慧人社”管理信息系統項目進度計劃的制訂

3.1.1 項目整體進度計劃的制訂

項目啟動初期，項目組成員使用里程碑計劃法，對整個項目的里程碑進行了標記，按軟件項目開發的生命周期將項目整體劃分為幾個階段：需求分析階段、系統開發階段、系統測試階段及系統試運行階段等。

3.1.2 項目開發階段進度計劃的制訂

在項目的每個階段中，其實都貫穿著許多階段性進度計劃，“智慧人社”管理信息系統項目的每個階段計劃也是通過使用進度管理方法來制訂的。同時，在開發階段中，項目組將每個功能模塊的開發任務進行了更詳細的分解，具體到每個子功能，規定了功能實現責任人，并標注了計劃用時。項目管理人員可以直觀地了解到每個子功能的計劃用時，在實施階段用于與實際使用時間進行對比考核，就很容易得出進度是否延遲或提前的結論。

3.1.3 “智慧人社”管理信息系統項目進度計劃的控制

項目進度控制的流程就是定期或不定期接收項目完成狀況的數據，把現實進展狀況數據與計劃數據做比對，當實際進度與計劃不一致時，就會產生偏差，如影響項目達成就需要采取相應的措施，對原計劃進行調整來確保項目順利按時完成。這是一個不斷進行的循環的動態控制過程。

在“智慧人社”管理信息系統項目開始后，在整體計劃中設置了一系列的報告期和報告點，用以收集實際進度數據。分別是項目周會、項目月度會議、階段完成會議。

4 結 語

本文通過對具體軟件開發項目過程中的進度管理進行研究與實踐，綜合運用科學的項目管理及“智慧人社”管理信息系統的軟件思想和方法提出了有效的進度管理方法，不僅可以保證項目的質量，還能在約定期限內完成并交付成果，為今后其他軟件開發公司開發類似項目提供參考，從而幫助提高軟件項目開發和進度控制的綜合管理能力。

主要參考文獻

篇（10）

1.1大型軟件的開發

大型軟件開發具有髙失敗率的特點，一般在70%上下，高失敗率給我國的大型軟件開發造成了很大的打擊，很多企業對大型軟件的開發都失去了信心。一般都把大型軟件的開發與中小型軟件的開發一樣，看成了管理信息系統，屬于技術的范疇，而忽略了項目管理在軟件開發的重大作用。中小型的軟件開發一般業務比較簡單，處理的邏輯很少，并且也相對穩定。在開發前能夠清晰的界定需求分析，是一種技術產品，但是大型軟件具有復雜的業務流程，需要進行大量的數據處理，無法明確、清晰的界定具體的業務發展屬性，具有動態性，與其說大型軟件是一種技術產品，不如說這是一種管理產品。

1.2項目管理和流程能管理

項目管理是一種管理科學，在項目活動中運用專業的技能、工具和知識，使項目在有限的資源限定條件下能夠達到預期的效果，在限定時間和條件下一次性的完成任務。項目管理中包括運用相關的技能、方法和工具針對目標所展開的計劃、組織、領導和控制。流程管理是意見具體的工程或管理任務中，分析所有的主流和直流之間的關系，使所有的因素都能發揮應有的作用，相互協調與配合。流程管理是以整個工程工序為管理對象，關注流程中每一步驟的效率以及和上下游之間的配合。使整個工作開發的流程具有完整性和流暢性。

2大型軟件項目管理流程設計與分析

2.1流程設計目標

首先我們要對整個大型軟件的流程能夠開發進行分析，分析應該在大型軟件的開發中流程管理應該達到怎樣的效果。每一流程都是由具體的活動所組成的，在軟件開發的過程中，每一流程都有特定的指向性，有明確的起始活動和終止活動，具有四個基本的要素，即活動、活動的邏輯從屬、活動的實現方式以及活動的承擔者。大型軟件的開發就是一件由各種活動組成的工程，包括項目的計劃編制、系統的分析、概要的設計、詳細的設計、程序編碼、測試和維護等。在整個大大型軟件項目管理流程中，主要對以下幾個因素進行控制。首先，要具有明確的目標指向性，要引導開發的成功；其次，制定的流程必須滿足整個軟件開發的全過程；第三，必須進行量化的設計，有具體的管理目標，能夠對每一步驟進行監控；第四，構建分析每一步驟之間的聯系，能夠在第一時間找到項目運行困難的第一因素并進行管理；第五，在流程管理中對每一活動的開始、終止條件進行明確的劃分與規定，提高管理的效率最后，流程中每一活動都是可度量與評價的，具有可操作性。

2.2流程設計

首先進行項目的搜尋，對市場信息以及用戶的需求進行具體的分析，對潛在的項目進行篩選和分析，在此進出上進行項目的立項，提出立項的建議，并估算所需要的資金和資源。然后制定與客戶的交流計劃，全面的了解客戶的背景信息以及項目啟動的原因、目的和期望，根據當前的市場和技術水平編制方案建議書，并準備合同的藍本。然后確立合同，包括項目的評估與確定、技術合同、商務合同的確定、評估及簽署。執行合同，包括應該履行的所有義務，如軟件開發、測試執行、項目驗收、系統的維護等。

測試執行的目的是為了保證系統的開發符合合同任務書中的具體要求，測試過程可以分為集成測試和系統測試兩個部分，模擬運行的環境測試系統的性能、用戶界面、安裝和反安裝測試等。接下來進行項目的驗收，在進行驗收前先進行內部的驗收，準備好具體的驗收計劃、項目開發總結的報告、財務預算報告、產品清單等。然后進行內部驗收的測試與評定。然后進行具體的驗收，同樣制定相關的計劃，并準備好中間產品，進行現場的調試，最終得到客戶的確認。