軟體專案開發計劃書模板

　　一份好的專案計劃書的特點是:關注產品、敢於競爭、充分市場調研，有力資料說明、表明行動的方針、展示優秀團隊、良好的財務預計等幾點，從而使合作伙伴會更瞭解專案的整體情況及業務模型，也能讓投資者判斷該專案的可盈利性。以下是小編整理的關於軟體專案開發計劃書模板範文。歡迎大家參考!

　　一、專案計劃書格式

　　根據《GB8567-88計算機軟體產品開發檔案編制指南》中專案開發計劃的要求，結合實際情況調整後的《專案計劃書》內容索引如下：(略)

　　二、專案計劃書的編寫說明

　　1引言

　　1.1編寫目的

　　說明編寫這份專案計劃的目的，並指出預期的讀者。

　　作用：本節是為了說明編制“專案計劃書”亦即本文件的意圖和希望達到的效果。注意這裡的“目的”不是“專案目標”，而是為了說明本文件的目的與作用。“專案目標”在2.1中說明。

　　意義：使專案成員和專案干係人瞭解專案開發計劃書的作用、希望達到的效果。開發計劃書的作用一般都是“專案成員以及專案干係人之間的共識與約定，專案生命週期所有活動的行動基礎，以便專案團隊根據本計劃書開展和檢查專案工作。”

　　例如可以這麼寫：為了保證專案團隊按時保質地完成專案目標，便於專案團隊成員更好地瞭解專案情況，使專案工作開展的各個過程合理有序，因此以檔案化的形式，把對於在專案生命週期內的工作任務範圍、各項工作的任務分解、專案團隊組織結構、各團隊成員的工作責任、團隊內外溝通協作方式、開發進度、經費預算、專案內外環境條件、風險對策等內容做出的安排以書面的方式，作為專案團隊成員以及專案干係人之間的共識與約定，專案生命週期內的所有專案活動的行動基礎，專案團隊開展和檢查專案工作的依據。

　　常見的問題：把專案本身的“專案目標”誤作編制專案開發計劃的目的。

　　1.2背景

　　主要說明專案的來歷，一些需要專案團隊成員知道的相關情況。主要有以下內容：

　　專案的名稱：經過與客戶商定或經過立項手續統一確定的專案名稱，一般與所待開發的軟體系統名稱有較大的關係，如針對“XX系統”開發的專案名稱是“XX系統開發”。

　　專案的委託單位：如果是根據合同進行的軟體開發專案，專案的委託單位就是合同中的甲方;如果是自行研發的軟體產品，專案的委託單位就是本企業。

　　專案的使用者(單位)：軟體或網路的使用單位，可以泛指某個使用者群。注意專案的使用者或單位有時與專案的委託單位是同一個，有時是不一樣的。如海關的報關軟體、稅務的報稅軟體，委託單位是海關或稅務機關，但使用的使用者或單位不僅有海關或稅務機關，還包括需要報關、報稅的企業單位。

　　專案的任務提出者：本企業內部提出需要完成此專案的人員，一般是領導或商務人員;注意專案的任務提出者一般不同於專案的委託單位，前者一般是企業內部的人員。如果是內部開發專案，則兩者的區別在於前者指人，後者指單位。

　　專案的主要承擔部門：有些企業根據行業方向或工作性質的不同把軟體開發分成不同的部門(也有的分為不同事業部)。專案的特點就是其矩陣式組織，一般一個專案的專案成員可能由不同的部門組成，甚至可能由研發部門、開發部門、測試部門、整合部門、服務部門等等其中幾個組成。需要根據專案所涉及的範圍確定本專案的主要承擔部門。

　　專案建設背景：從政治環境上、業務環境上說明專案建設背景，說明專案的大環境、來龍去脈。這有利於專案成員更好地理解專案目標和各項任務。

　　例句：根據《某部關於某建設工作的實施意見》精神，為了保障某建設工作的正常實施，必須加強監督考核，建立督查通報制度，某市某建設工作小組辦公室把此項建設工作實施列入督查的重要內容，及時掌握進度，相關部門建立市某建設工作簡報制度，及時反映全市某建設工作動態。

　　目前對於某建設工作的工作主要採用計劃部門手工編制年度計劃、建設工作主管部門和建設工作實施單位聯合手動編制進度計劃，某建設工作單位手工上報建設工作進度情況的方式，而全市的建設工作有數百個，加上前期建設工作的數量和今後某市建設發展的趨勢，建設工作的數量將越來越多，原來的工作模式已經越來越無法適應市委市政府的要求。因此，充分利用現代資訊化、因特網的優勢，建立“某市某建設工作資訊報送反饋系統”，提高某建設工作資訊報送反饋工作效率，提高資訊的及時性、減輕各級相關工作人員的勞動強度是非常有必要和緊迫的任務。

　　軟體系統與其他系統的關係：說明與本系統有關的其他系統，說明它們之間的相互依賴關係。這些系統可以是這個系統的基礎性系統(一些資料、環境等必須依靠這個系統才能執行)，也可以是以這個系統為基礎的系統，或者是兩者兼而有之的關係、互相依賴的系統。例句：本系統中對外部辦公部分如需要各個建設單位報送材料的子系統應當掛在市政府網站。

　　軟體系統與機構的關係：說明軟體系統除了委託單位和使用單位，還與哪些機構組織有關係。例如一些系統需要遵守那些組織的標準、需要透過那些組織機構的測試才能使用等等、是否需要外包或與那些組織機構合作。

　　1.3定義

　　列出為正確理解本計劃書所用到的專門術語的定義、外文縮寫詞的原詞及中文解釋。注意儘量不要對一些業界使用的通用術語進行另外的定義，使它的含義和通用術語的慣用含義不一致。

　　1.4參考資料

　　列出本計劃書中所引用的及相關的檔案資料和標準的作者、標題、編號、發表日期和出版單位，必要時說明得到這些檔案資料和標準的途徑。本節與下一節的“標準、條約和約定”互為補充，注意“參考資料”未必作為“標準、條約和約定”，因為“參考”的不一定是“必須遵守”的。常用資料如：

　　本專案的合同、標書、上級機關有關通知、經過審批的專案任務書;

　　屬於本專案的其他已經發表的檔案;

　　本文件中各處引用的檔案、資料，包括所要用到的軟體開發標準。

　　1.5標準、條約和約定

　　列出在本專案開發過程中必須遵守的標準、條約和約定。例如：相應的《立項建議書》、《專案任務書》、合同、國家標準、行業標準、上級機關有關通知和實施方案、相應的技術規範等。

　　“參考資料”一般具有“物質”特性，一般要說明參照了什麼，要說明在哪裡可以獲得;“標準、條約和約定”一般具有“精神”特性，一般是必須遵守的，不說明在哪裡可以獲得。參考資料的內容應該涵蓋“標準、條約和約定”。

　　2專案概述

　　2.1專案目標

　　設定專案目標就是把專案要完成的工作用清晰的語言描述出來，讓專案團隊每一個成員都有明確的概念。注意，不要簡單地說成在什麼什麼時間完成開發什麼什麼軟體系統或完成什麼什麼軟體安裝整合任務。注意“要完成一個系統”只是一個模糊的目標，它還不夠具體和明確。明確的專案目標應該指出了服務物件，所開發軟體系統最主要的功能和系統本身的比較深層次的社會目的或系統使用後所起到的社會效果。

　　專案目標應當符合SMART原則：

　　lSSpecific明確的陳述

　　lMMeasurable可以衡量的結果

　　lAAttainable可以達成的目標

　　lRRealistic合理的，現實的或者說是能和實際工作相結合

　　lTTrackable可以跟蹤的

　　專案目標可以進行橫向的分解也可以進行縱向的分解。橫向分解一般按照系統的功能或按照建設單位的不同業務要求，如分解為第一目標、第二目標等等;縱向的分解一般是指按照階段，如分解為第一階段目標、第二階段目標等等，或近期目標、中期目標、遠期目標等等。階段目標一般應當說明目標實現的較為明確的時間。一般要在說明了總目標的基礎上再說明分解目標，可加上“為實現專案的總目標，必須實現以下三個階段目標······”

　　2.2產品目標與範圍

　　根據專案輸入(如合同、立項建議書、專案技術方案、標書等)說明此專案要實現的軟體系統產品的目的與目標及簡要的軟體功能需求。對專案成果(軟體系統)範圍進行準確清晰的界定與說明是軟體開發專案活動開展的基礎和依據。軟體系統產品目標應當從使用者的角度說明開發這一軟體系統是為了解決使用者的那些問題。產品目標如“提高工作資訊報送反饋工作效率，更好地進行工作資訊報送的檢查監督，提高資訊的及時性、彙總統計資訊的準確性，減輕各級相關工作人員的勞動強度。”

　　2.3假設與約束

　　對於專案必須遵守的各種約束(時間、人員、預算、裝置等)進行說明。這些內容將限制你實現什麼、怎樣實現、什麼時候實現、成本範圍等種種制約條件。

　　假設是透過努力可以直接解決的問題，而這些問題是一定要解決才能保證專案按計劃完成。如：“系統分析員必須在3天內到位”或“使用者必須在8月8日前確定對需求文件進行確認”

　　約束一般是難以解決的問題，但可以透過其他途徑迴避或彌補、取捨，如人力資源的約束限制，就必須犧牲進度或質量等等。

　　假設與約束是針對比較明確會出現的情況，如果問題的出現具有不確定性，則應該在風險分析中列出，分析其出現的可能性(機率)、造成的影響、應當採取的相應措施。

　　2.4專案工作範圍

　　說明為實現專案的目標需要進行那些工作。在必要時，可描述與合作單位和使用者的工作分工。

　　注意產品範圍與專案工作範圍的不同含義。

　　產品範圍界定：軟體系統產品本身範圍的特徵和功能範圍。

　　工作範圍界定：為了能夠按時保質交付一個有特殊的特徵和功能的軟體系統產品所要完成的那些工作任務。

　　產品範圍的完成情況是參照客戶的需求來衡量的，而專案範圍的完成情況則是參照計劃來檢驗的。這兩個範圍管理模型間必須要有較好的統一性，以確保專案的具體工作成果，能按特定的產品要求準時交付。

　　2.5應交付成果

　　2.5.1需完成的軟體

　　列出需要完成的程式的名稱、所用的程式語言及儲存程式的媒體形式。其中軟體物件可能包括：源程式、資料庫物件建立語句、可執行程式、支撐系統的資料庫資料、配置檔案、第三方模組、介面檔案、介面原稿檔案、聲音檔案、安裝軟體、安裝軟體源程式檔案等等。

　　2.5.2需提交使用者的文件

　　列出需要移交給使用者的每種文件的名稱、內容要點及儲存形式，如需求規格說明書、幫助手冊等。此處需要移交使用者的文件可參考合同中的規定。

　　2.5.3須提交內部的文件

　　可根據《GB8567-88計算機軟體產品開發檔案編制指南》附錄O：“檔案編制實施規定的例項(參考件)”結合各企業實際情況調整制定《軟體開發文件編制裁減衡量因素表》。根據《因素表》確定專案對應的專案衡量因素取值，以確定本專案應完成的階段成果。將不適用於本專案的內容裁減，以減少不必要的專案任務和資源。

　　根據因素取值列出本專案應完成的階段成果，說明本專案取值所在的區間，將其他因素值區間刪除。

　　2.5.4應當提供的服務

　　根據合同或某重點建設工作需要，列出將向用戶或委託單位提供的各種服務，例如培訓、安裝、維護和執行支援等。具體的工作計劃如需要編制現場安裝作業指導書、培訓計劃等，應當在本計劃“4.3總體進度計劃”中條列出。

　　2.6專案開發環境

　　說明開發本軟體專案所需要的軟硬體環境和版本、如作業系統、開發工具、資料庫系統、配置管理工具、網路環境。環境可能不止一種，如開發工具可能需要針對Java的，也需要針對C++的。有些環境可能無法確定，需要在需求分析完成或設計完成後才能確定所需要的環境。

　　2.7專案驗收方式與依據

　　說明專案內部驗收和使用者驗收的方式，如驗收包括交付前驗收、交付後驗收、試執行(初步)驗收、最終驗收、第三方驗收、專家參與驗收等等。專案驗收依據主要有標書、合同、相關標準、專案文件(最主要是需求規格說明書)。

　　3專案團隊組織

　　3.1組織結構

　　說明專案團隊的組織結構。專案的組織結構可以從所需角色和專案成員兩個方面描述。所需角色主要說明為了完成本專案任務，專案團隊需要哪些角色構成，如專案經理、計劃經理、系統分析員(或小組)、構架設計師、設計組、程式組、測試組等等。組織結構可以用圖形來表示，可以採用樹形圖，也可以採用矩陣式圖形，同時說明團隊成員來自於哪個部門。除了圖形外，可以用文字簡要說明各個角色應有的技術水平。

　　注意雖然有一些通用的結構可以套用，但各種不同規模、不同形式的專案組織結構是不一樣的。如產品研發專案可能就不需要實施人員(小組)，但需要知識轉移方面的人員(小組)。而軟體編碼外包的專案則不需要程式設計師，測試人員也可以適當地減少。

　　3.2人員分工

　　確定專案團隊的的每個成員屬於組織結構中的什麼角色，他們的技術水平、專案中的分工與配置，可以用列表方式說明，具體編制時按照專案實際組織結構編寫。以下是一個示例。

　　3.3協作與溝通

　　專案的溝通與協作首先應當確定協作與溝通的物件，就是與誰協作、溝通。溝通物件應該包括所有專案干係人，而專案干係人包括了所有專案團隊成員、專案介面人員、專案團隊外部相關人員等等。

　　其次應當確定協作模式與溝通方式。溝通方式如會議、使用電話、QQ、內部郵件、外部郵件、QuickPlace、聊天室等等。其中郵件溝通應當說明主送人、抄送人，聊天室溝通方式應當約定時間週期。而協作模式主要說明在出現什麼狀況的時候各個角色應當(主動)採取什麼措施，包括溝通，如何互相配合來共同完成某項任務。定期的溝通一般要包括專案階段報告、專案階段計劃、階段會議等

　　3.3.1專案團隊內部協作

　　本節說明在專案開發過程中專案團隊內部的協作模式和溝通方式、頻次、溝通成果記錄辦法等內容。

　　3.3.2專案介面人員

　　應當說明介面工作的人員即他們的職責、聯絡方式、溝通方式、協作模式，包括：

　　a、負責本專案同用戶的介面人員;

　　b、負責本專案同本企業各管理機構，如計劃管理部門、合同管理部門、採購部門、質量管理部門、財務部門等的介面人員;

　　c、負責本專案同分包方的介面人員。

　　3.3.3專案團隊外部溝通與協作模式

　　專案團隊外部包括企業內部管理協助部門、專案委託單位、客戶等等。本節說明在專案開發過程中專案團隊內部與介面人員、客戶溝通的方式、頻次、溝通成果記錄辦法等內容。明確終端使用者、直接使用者及其所在本企業/部門名稱和聯絡電話。明確協作開發的有關部門的名稱、經理姓名、承擔的工作內容以及工作實施責任人的姓名、聯絡電話。確定有關的合作單位的名稱、負責人姓名、承擔的工作內容以及實施人的姓名、聯絡電話。

　　4實施計劃

　　4.1風險評估及對策

　　識別或預估專案進行過程中可能出現的風險。應該分析風險出現的可能性(機率)、造成的影響、根據影響應該採取的對策，採取的措施。風險識別包括識別內在風險及外在風險。內在風險是指專案工作組能加以控制和影響的風險，如人事任免和成本估計等。外在風險指超出專案工作組等控制力和影響力之外的風險，如市場轉向或政府行為等

　　風險的對策包括：避免：排除特定危脅往往靠排除危險起源;減緩：減少風險事件的預期資金投入來減低風險發生的機率，以及減少風險事件的風險係數;吸納：接受一切後果，可以是積極的(如制定預防性計劃來防備風險事件的發生)，也可以是消極的(如某些費用超支則接受低於預期的利潤)。

　　對於軟體開發專案而言，在分析、識別和管理風險上投入足夠的時間和人力可以使專案進展過程更加平穩，提高專案跟蹤和控制的能力，由於在問題發生之前已經做了周密計劃，因而對專案的成功產生更加充分的信心。

　　軟體開發專案常見預估的風險：

　　1)工程/規模/進度上的風險

　　規模大，規模估算不精確甚至誤差很大;就規模而言，使用者要求交付期、費用很緊;預料外的工作(測試未完時的'現場對應等);

　　2)技術上的風險

　　使用新的開發技術、新裝置等，或是新的應用組合，沒有經驗;是新的行業或業務，沒有經驗;效能上的要求很嚴;

　　3)使用者體制上的問題

　　使用者管理不嚴，恐怕功能決定、驗收不能順利地完成(或者出現了延遲);或者恐怕功能會多次變更;與使用者分擔開發，恐怕工程會拖延(或者出現了延遲);使用者或其他相關單位承擔的工作有可能延誤;

　　4)其它：應該包含此處沒有、但據推測有風險的專案。

　　4.2工作流程

　　說明專案採用什麼樣的工作流程進行。如瀑布法工作流程，原型法工作流程、螺旋型工作流程、迭代法工作流程，也可以是自己建立的工作流程。不同的流程將影響後面的工作計劃的制定。必要時畫出本專案採用的工作流程圖及適當的文字說明。

　　4.3總體進度計劃

　　這裡所說的總體進度計劃為高層計劃。作為補充，應當分階段制定專案的階段計劃，這些階段計劃不在這份文件中，當要以這份總體計劃為依據。

　　總體進度計劃要依據確定的專案規模，列表專案階段劃分、階段進度安排及每階段應提交的階段成果，在階段時間安排中要考慮專案階段成果完成、提交評審、修改的時間。

　　對於專案計劃、專案準備、需求調研、需求分析、構架設計或概要設計、編碼實現、測試、移交、內部培訓、使用者培訓、安裝部署、試執行、驗收等工作，給出每項工作任務的預定開始日期、完成日期及所需的資源，規定各項工作任務完成的先後順序以及表徵每項工作任務完成的標誌性事件(里程碑)。

　　設計評審

　　表格中檢查點/里程碑等階段劃分為舉例，實際作業階段劃分、階段成果等請根據專案需要確定。

　　制定軟體專案進度計劃可以使用一些專門的工具，最常用的是Microsoft的Project作為輔助工具，功能比較強大，比較適合於規模較大的專案，但無法完全代替專案計劃書，特別是一些主要由文字來說明的部分。小規模的專案可簡便地使用EXCEL作為輔助工具。關於如何使用這些工具不在此作詳細說明。

　　制定軟體專案進度計劃應當考慮以下一些因素:

　　1)對於系統需求和專案目標的掌握程度。如開始時對於系統需求和專案目標只有比較數的瞭解，就只能制定出比較粗的進度計劃，等到需求階段或設計階段結束，就應該進一步細化進度計劃。

　　2)軟體系統規模和專案規模，這兩個不是一個概念。軟體系統規模往往是從功能點的估算或其他估算方式得來的，而專案規模還要考慮對文件數量與質量的要求，使用的開發工具、新技術、多少複用、溝通的方便程度、客戶方的情況、需要遵守的標準規範等等等等。例如，完成一個大型的系統，在一定的時間內一個人或幾個人的智力和體力是承受不了的。由於軟體是邏輯、智力產品，盲目增加軟體開發人員並不能成比例地提高軟體開發能力。相反，隨著人員數量的增加，人員的組織、協調、通訊、培訓和管理方面的問題將更為嚴重。

　　3)軟體系統複雜程度和專案複雜程度：和軟體系統規模和專案規模一樣，軟體系統的複雜程度主要是考慮軟體系統本身的功能、架構的複雜程度，而專案的複雜程度主要是指專案團隊成員的構成、專案任務的複雜程度、專案干係人的複雜程度、需求調研的難易程度，多專案情況下資源保障的情況，等等等等。軟體系統的規模與軟體系統的複雜程度未必是成比例的關係;同樣專案的規模與專案的複雜程度未必是成比例的關係。

　　4)專案的工期要求，就是專案的緊急程度。有些專案規模大，卻因為與顧客簽訂了合同，或者為了搶先佔領市場，工期壓縮得很緊，這時就要考慮如何更好地合理安排進度，多增加人選多采用加班的方式是一種萬不得已的選擇。增加人選除了增加人的成本外必定會增加溝通的成本(熟悉專案任務所需要的時間);加班如果處理不好會造成情緒上的問題，也可能會因為過於忙碌而無法顧及質量，造成質量的下滑。

　　5)專案成員的能力。這些能力包括專案經理的管理能力，系統分析員的分析能力、系統設計人員的設計能力、程式設計師的編碼能力、測試人員的測試能力，以及企業或專案團隊激發出這些能力的能力。從另外一個角度看還有總體上對客戶行業業務的熟悉程度;對於建模工具、開發工具、測試工具等技術的掌握程度;企業內部對行業業務知識和主要技術的知識積累。

　　4.4專案控制計劃

　　4.4.1質量保證計劃

　　執行質量評審活動，對過程質量進行控制。規模較大的專案應當單獨編寫《軟體開發專案質量計劃》。根據GB/T12504計算機軟體質量保證計劃規範，內容包括：

　　l引言(本章節包括質量計劃的目的、定義、參考資料)

　　l管理(描述負責軟體質量管理的機構、任務及其相關的職責)

　　l文件(列出在該軟體的開發、驗證與確認以及使用與維護等階段中需要編制的文件，並描述對文件進行評審與檢查的準則)

　　l標準、條例和約定(列出軟體開發過程中要用到的標準、條例和約定，並列出監督和保證執行的措施)

　　l評審和檢查(規定所要進行的技術和管理兩個方面的評審和檢查工作，並編制或引用有關的評審和檢查規程，以及透過與否的技術準則。至少要進行軟體需求評審、概要設計評審、軟體驗證與確認評審、軟體系統功能檢查、程式和文件物理檢查)

　　l軟體配置管理(編制有關配置管理條款，或在“4.4.4配置管理計劃”中說明，或引用按照《GB/T12505計算機軟體配置管理計劃規範》單獨制定的文件)

　　l工具、技術和方法(指明用於支援特定軟體專案質量管理工作的工具、技術和方法，指出它們的目的和用途)

　　l媒體控制(說明保護計算機程式物理媒體的方法和設施，以免非法存取、意外損壞或自然老化)

　　l對供貨單位的控制(供貨單位包括專案承辦單位、軟體銷售單位、軟體開發單位。規定對這些供貨單位進行控制的規程，從而保證專案承辦單位從軟體銷售單位購買的、其他開發單位開發的或從開發單位現存軟體庫中選用的軟體能滿足規定的需求。)

　　l記錄的收集、維護和儲存(指明需要儲存的軟體質量保證活動的記錄，並指出用於彙總、保護和維護這些記錄的方法和設施，並指明要儲存的期限)

　　4.4.2進度控制計劃

　　(可直接引用以下描述或根據專案情況制定本節內容)

　　本專案的進度監控執行本企業《專案管理規範》，由本企業過程控制部門如質量管理部統一進行監控，並保留在監控過程中產生的日常檢查記錄。

　　4.4.3預算監控計劃

　　說明如何檢查專案預算的使用情況。根據專案情況需要制定。

　　4.4.4配置管理計劃

　　編制有關軟體配置管理的條款，或引用按照GB/T12505單獨制訂《配置管理計劃》文件。在這些條款或文件中，必須規定用於標識軟體產品、控制和實現軟體的修改、記錄和報告修改實現的狀態以及評審和檢查配置管理工作等四方面的活動。還必須規定用以維護和儲存軟體受控版本的方法和設施;必須規定對所發現的軟體問題進行報告、追蹤和解決的步驟，並指出實現報告、追蹤和解決軟體問題的機構及其職責。

　　5支援條件

　　說明為了支援本專案的完成所需要的各種條件和設施。

　　5.1內部支援

　　逐項列出專案每階段的支援需求(含人員、裝置、軟體、培訓等)及其時間要求和用途。

　　例如，裝置、軟體支援包括客戶機、伺服器、網路環境、外設、通訊裝置、開發工具、作業系統、資料庫管理系統、測試環境，逐項列出有關到貨日期、使用時間的要求。

　　5.2客戶支援

　　列出對專案而言需由客戶承擔的工作、完成期限和驗收標準，包括需由客戶提供的條件及提供時間。

　　5.3外包(可選)

　　列出需由外單位分合同承包者承擔的工作、完成時間，包括需要由外單位提供的條件和提供的時間。

　　6預算

　　6.1人員成本

　　列出產品/專案團隊每一個人的預計工作月數。