1、軟件開發商業計劃書點擊率：SJ292198忑G。摘要本文主要對軟件開發項旦計劃書的格式及主要內容的編寫要點 進行說明，對一些內容進行了舉例說明。關鍵詞工程、計劃書、格式、編寫說明正文一、工程計劃書格式 根據GB8567 88計算機軟件產品開發文件編制指南中工程 開發計劃的要求，結合實際情況調整后的項旦計劃書內容 索引如下劃、建設工作主管部門和建設工作實施單位聯合手動編制進度 計劃，某建設工作單位手工上報建設工作進度情況的方式，而 全市的建設工作有數百個，加上前期建設工作的數量和今后某 市建設開展的趨勢，建設工作的數量將越來越多，原來的工作 模式已經越來越無法適應市委市政府的要求。因此，充分利用

2、 現代信息化、因特網的優勢，建立“某市某建設工作信息報送 反應系統”，提高某建設工作信息報送反應工作效率，提高信 息的及時性、減輕各級相關工作人員的勞動強度是非常有必要 和緊迫的任務。軟件系統與其他系統的關系說明與本系統有關的其他系統，說 明它們之間的相互依賴關系。這些系統可以是這個系統的基礎 性系統（一些數據、環境等必須依靠這個系統才能運行），也 可以是以這個系統為基礎的系統，或者是兩者兼而有之的關系、 互相依賴的系統。例句本系統中對外部辦公局部如需要各個建 設單位報送材料的子系統應當掛在市政府網站。軟件系統與機構的關系說明軟件系統除了委托單位和使用單 位，還與哪些機構組織有關系。例如一些系

3、統需要遵守那些組織的標準、需要通過那些組織機構的測試才能使用等等、是否 需要外包或與那些組織機構合作。1.3定義列出為正確理解本計劃書所用到的專門術語的定義、外文縮寫 詞的原詞及中文解釋。注意盡量不要對一些業界使用的通用術 語進行另外的定義，使它的含義和通用術語的慣用含義不一致。1. 4參考資料列出本計劃書中所引用的及相關的文件資料和標準的作者、標 題、編號、發表日期和出版單位，必要時說明得到這些文件資 料和標準的途徑。本節與下一節的“標準、條約和約定”互為 補充，注意“參考資料”未必作為“標準、條約和約定”，因 為“參考”的不一定是“必須遵守”的。常用資料如 本工程的合同、標書、上級機關有關

4、通知、經過審批的工程任 務書;屬于本工程的其他已經發表的文件;本文檔中各處引用的文件、資料，包括所要用到的軟件開發標 準。1. 5標準、條約和約定列出在本工程開發過程中必須遵守的標準、條約和約定。例如 相應的立項建議書、工程任務書、合同、國家標準、 行業標準、上級機關有關通知和實施方案、相應的技術規范等。“參考資料” 一般具有“物質”特性，一般要說明參照了什么,要說明在哪里可以獲得；“標準、條約和約定” 一般具有“精 神”特性，一般是必須遵守的，不說明在哪里可以獲得。參考 資料的內容應該涵蓋“標準、條約和約定”。2工程概述 2.1工程目標設定工程目標就是把理且要完成的工作用清晰的語言描述出 來

5、，讓工程團隊每一個成員都有明確的概念。注意，不要簡單 地說成在什么什么時間完成開發什么什么軟件系統或完成什么 什么軟件安裝集成任務。注意“要完成一個系統”只是一個凝的目標，它還不夠具體和明確。明確的項且目標應該指出了服 務對象，所開發軟件系統最主要的功能和系統本身的比擬深層 次的社會目的或系統使用后所起到的社會效果。晅目標應當符合SMART原那么1 S Specific明確的陳述1 M Measurable可以衡量的結果1 A Attainable可以達成的目標1 R Realistic合理的，現實的或者說是能和實際工作相結合1 T Trackable可以跟蹤的奧旦目標可以進行橫向的分解也可以

6、進行縱向的分解8向分解 一般按照系統的功能或按照建設單位的不同業務要求，如分解 為第一目標、第二目標等等；縱向的分解一般是指按照階段， 如分解為第一階段目標、第二階段目標等等，或近期目標、中 期目標、遠期目標等等。階段目標一般應當說明目標實現的較 為明確的時間。一般要在說明了總目標的基礎上再說明分解目標，可加上“為實現工程的總目標，必須實現以下三個階段目標 2.2產品目標與范品根據工程輸入（如合同、立項建議書、工程技術方案、標書等） 說明此工程要實現的軟件系統產品的目的與目標及簡要的軟件 功能需求。對工程成果（軟件系統）范圍進行準確清晰的界定 與說明是軟件開發工程活動開展的基礎和依據。軟件系統

7、產品 目標應當從用戶的角度說明開發這一軟件系統是為了解決用戶 的那些問題。產品目標如“提高工作信息報送反應工作效率，更好地進行工作信息報送的檢查監督，提高信息的及時性、匯 總統計信息的準確性，減輕各級相關工作人員的勞動強度。”3假設與約束對于工程必須遵守的各種約束（時間、人員、預算、設備等） 進行說明。這些內容將限制你實現什么、怎樣實現、什么時候 實現、本錢范圍等種種制約條件。假設是通過努力可以直接解決的問題，而這些問題是一定要解決才能保證項旦按計劃完成。如“系統分析員必須在3天內到位”或“用戶必須在8月8日前確定對需求文檔進行確認” 約束一般是難以解決的問題，但可以通過其他途徑回避或彌補、

8、取舍，如人力資源的約束限制，就必須犧牲進度或質量等等。假設與約束是針比照擬明確會出現的情況，如果問題的出現具有不確定性，那么應該在風險分析中列出，分析其出現的可能性（概率）、造成的影響、應當采取的相應措施。2.4工程工作范圍說明為實現奧旦的目標需要進行那些工作。在必要時，可描述 與合作單位和用戶的工作分工。注意產品范圍與工程工作范圍的不同含義。產品范圍界定軟件系統產品本身范圍的特征和功能范圍。工作范圍界定為了能夠按時保質交付一個有特殊的特征和功能 的軟件系統產品所要完成的那些工作任務。產品范圍的完成情況是參照客戶的需求來衡量的，而工程范圍的完成情況那么是參照計劃來檢驗的。這兩個范圍管理模型間必

9、 須要有較好的統一性，以確保工程的具體工作成果，能按特定 的產品要求準時交付。2. 5應交付成果2. 5.1需完成的軟件列出需要完成的程序的名稱、所用的編程語言及存儲程序的媒 體形式。其中軟件對象可能包括源程序、數據庫對象創立語句、 可執行程序、支撐系統的數據庫數據、配置文件、第三方模塊、 界面文件、界面原稿文件、聲音文件、安裝軟件、安裝軟件源 程序文件等等。2. 5.2需提交用戶的文檔列出需要移交給用戶的每種文檔的名稱、內容要點及存儲形式, 如需求規格說明書、幫助手冊等。此處需要移交用戶的文檔可 參考合同中的規定。2. 5.3須提交內部的文檔可根據GB計算機軟件產品開發文件編制指南附錄0 “

10、文件 編制實施規定的實例（參考件）”結合各企業實際情況調整制 定軟件開發文檔編制裁減衡量因素表。根據因素表確 定工程對應的工程衡量因素取值,以確定本項且應完成的階段 成果。將不適用于本項且的內容裁減，以減少不必要的工程任 務和資源。根據因素取值列出本工程應完成的階段成果，說明本工程取值 所在的區間，將其他因素值區間刪除。5. 4應當提供的服務根據合同或某重點建設工作需要，列出將向用戶或委托單位提 供的各種服務，例如培訓、安裝、維護和運行支持等。具體的 工作計劃如需要編制現場安裝作業指導書、培訓計劃等，應當 在本計劃“4.3總體進度計劃”中條列出。工程開發環境 說明開發本軟件里旦所需要的軟硬件環

11、境和版本、如操作系統、 開發工具、數據庫系統、配置管理工具、網絡環境。環境可能不止一種，如開發工具可能需要針對Java的，也需要針對C+ 的。有些環境可能無法確定，需要在需求分析完成或設計完成 后才能確定所需要的環境。工程驗收方式與依據 說明現包內部驗收和用戶驗收的方式，如驗收包括交付前驗收、 交付后驗收、試運行（初步）驗收、最終驗收、第三方驗收、 專家參與驗收等等。理且驗收依據主要有標書、合同、相關標 準、工程文檔（最主要是需求規格說明書）。3工程團隊組織1組織結構說明現巨團隊的組織結構。工程的組織結構可以從所需角色和 工程成員兩個方面描述。所需角色主要說明為了完本錢工程任 務，工程團隊需要

12、哪些角色構成，如工程經理、計劃經理、系 統分析員（或小組）、構架設計師、設計組、程序組、測試組 等等。組織結構可以用圖形來表示，可以采用樹形圖，也可以 采用矩陣式圖形，同時說明團隊成員來自于哪個部門。除了圖形外，可以用文字簡要說明各個角色應有的技無水平。注意雖然有一些通用的結構可以套用，但各種不同規模、不同 形式的理且組織結構是不一樣的。如產品研發妲可能就不需 要實施人員（小組），但需要知識轉移方面的人員（小組）。而軟件編碼外包的工程那么不需要程序員，測試人員也可以適當 地減少。3.2人員分工確定工程團隊的的每個成員屬于組織結構中的什么角色，他們 的技術水平、工程中的分工與配置，可以用列表方式

13、說明，具 體編制時按照工程實際組織結構編寫。以下是一個例如。1引言編寫目的背景定義4參考資料5標準、條約和約定 2工程概述2.1工程目標2產品目標與范圍3假設與約束2.4工程工作范圍5應交付成果姓名產技術水平d角色F工作描述戶工程管理、前期分析、設計Q分析系統需求、工程計劃、工程E 隊管理、檢查進度。一甲分析、設計、編碼-分析新功能、軟件框架擴展、代工 模塊分配、數據庫設計說明書。口43分析、設計。數據交換、安裝程序、安裝手冊，甲設計、編碼一數據加戟分析研設計二工程后期總體負責、加載程序編1川設計、編碼口數碼相機照片讀取飄切模塊設計，羊測試/對軟件進行測試、軟件測試文檔，文檔編寫、測試一用戶操

14、作手冊二3.3協作與溝通工程的溝通與協作首先應當確定協作與溝通的對象，就是與誰 協作、溝通。溝通對象應該包括所有現目干系人，而工程干系 人包括了所有工程團隊成員、工程接口人員、工程團隊外部相 關人員等等。其次應當確定協作模式與溝通方式。溝通方式如會議、使用電 話、QQ、內部郵件、外部郵件、QuickPlace.聊天室等等。其 中郵件溝通應當說明主送人、抄送人，聊天室溝通方式應當約 定時間周期。而協作模式主要說明在出現什么狀況的時候各個 角色應當（主動）采取什么措施，包括溝通，如何互相配合來 共同完成某項任務。定期的溝通一般要包括工程階段報告、項旦階段計劃、階段會議等3. 1典團隊內部協作本節說

15、明在工程開發過程中項且團隊內部的協作模式和溝通方 式、頻次、溝通成果記錄方法等內容。3.2工程接口人員應當說明接口工作的人員即他們的職責、聯系方式、溝通方式、協作模式，包括a、負責本工程同用戶的接口人員;b、負責本工程同本企業各管理機構，如計劃管理部門、合同管理部門、采購部門、質量管理部門、財務部門等的接口人員;c、負責本工程同分包方的接口人員。3.3 晅團隊外部溝通與協作模式 工程團隊外部包括企業內部管理協助部門、工程委托單位、客 戶等等。本節說明在工程開發過程中工程團隊內部與接口人員、客戶溝通的方式、頻次、溝通成果記錄方法等內容。明確最終 用戶、直接用戶及其所在本企業/部門名稱和聯系 。明

16、確 協作開發的有關部門的名稱、經理姓名、承當的工作內容以及 工作實施責任人的姓名、聯系 。確定有關的合作單位的名 稱、負責人姓名、承當的工作內容以及實施人的姓名、聯系電 話。4實施計劃風險評估及對策 識別或預估工程進行過程中可能出現的風險。應該分析風險出 現的可能性（概率）、造成的影響、根據影響應該采取的對策, 采取的措施。風險識別包括識別內在風險及外在風險。內在風 險是指工程工作組能加以控制和影響的風險，如人事任免和成 本估計等。外在風險指超出工程工作組等控制力和影響力之外 的風險，如市場轉向或政府行為等 風險的對策包括防止排除特定危脅往往靠排除危險起源；減緩 減少風險事件的預期資金投入來減

17、低風險發生的概率，以及減 少風險事件的風險系數；吸納接受一切后果，可以是積極的（如制定預防性計劃來防范風險事件的發生），也可以是消極的（如 某些費用超支那么接受低于預期的利潤）。對于軟件開發項旦而言，在分析、識別和管理風險上投入足夠 的時間和人力可以使項旦進展過程更加平穩，提高工程跟蹤和 控制的能力，由于在問題發生之前已經做了周密計劃，因而對 工程的成功產生更加充分的信心。軟件開發項野見預估的風險1）工程/規模/進度上的風險規模大，規模估算不精確甚至誤差很大；就規模而言，用戶要 求交付期、費用很緊；預料外的工作（測試未完時的現場對應 等）；2）技術上的風險使用新的開發野、新設備等，或是新的應用

18、組合，沒有經驗; 是新的行業或業務，沒有經驗；性能上的要求很嚴；3）用戶體制上的問題用戶管理不嚴，恐怕功能決定、驗收不能順利地完成（或者出 現了延遲）；或者恐怕功能會屢次變更；與用戶分擔開發，恐 怕工程會拖延（或者出現了延遲）；用戶或其他相關單位承當 的工作有可能延誤；4）其它應該包含此處沒有、但據推測有風險的工程j工作流程說明現且采用什么樣的工作流程進行。如瀑布法工作流程，原 型法工作流程、螺旋型工作流程、迭代法工作流程，也可以是 自己創立的工作流程。不同的流程將影響后面的工作計劃的制 定。必要時畫出本工程采用的工作流程圖及適當的文字說明。3總體進度計劃這里所說的總體進度計劃為高層計劃。作為

19、補充，應當分階段 制定工程的階段計劃，這些階段計劃不在這份文檔中，當要以 這份總體計劃為依據。總體進度計劃要依據確定的典規模，列表典階段劃分、階 段進度安排及每階段應提交的階段成果，在階段時間安排中要考慮理旦階段成果完成、提交評審、修改的時間。對于工程計劃、工程準備、需求調研、需求分析、構架設計或 概要設計、編碼實現、測試、移交、內部培訓、用戶培訓、安 裝部署、試運行、驗收等工作，給出每項工作任務的預定開始 日期、完成日期及所需的資源，規定各項工作任務完成的先后 順序以及表征每項工作任務完成的標志性事件（里程碑）。例如起止時間點，責任人及所需資源，完成工作。應提交成果口檢查點/里程碑PPAA砂

20、Ap需求評審設計評審 表格中檢查點/里程碑等階段劃分為舉例，實際作業階段劃分、階段成果等請根據工程需要確定。制定軟件工程進度計劃可以使用一些專門的工具，最常用的是 Microsoft的Project作為輔助工具，功能比擬強大，比擬適 合于規模較大的現且，但無法完全代替項旦計劃書，特別是一 些主要由文字來說明的局部。小規模的工程可簡便地使用 EXCE L作為輔助工具。關于如何使用這些工具不在此作詳細說明。制定軟件工程進度計劃應當考慮以下一些因素：1）對于系統需求和工程目標的掌握程度。如開始時對于系統 需求和工程目標只有比擬數的了解，就只能制定出比擬粗的進 度計劃，等到需求階段或設計階段結束，就應

21、該進一步細化進 度計劃。2）軟件系統規耐工程規模，這兩個不是一個概念。軟件系統規模往往是從功能點的估算或其他估算方式得來的，而工程規模 還要考慮對文檔數量與質量的要求，使用的開發工具、新技術、 多少復用、溝通的方便程度、客戶方的情況、需要遵守的標準 規范等等等等。例如，完成一個大型的系統，在一定的時間內 一個人或幾個人的智力和體力是承受不了的。由于軟件是邏輯、2. 5.1需完成的軟件 2. 5.2需提交用戶的文檔2. 5.3須提交內部的文檔2. 5. 4應當提供的服務6工程開發環境工程驗收方式與依據3工程團隊組織組織結構人員分工作與溝通3.1內部協作3.2外部溝通智力產品，盲目增加軟件開發人員

22、并不能成比例地提高軟件開 發能力。相反，隨著人員數量的增加，人員的組織、協調、通 信、培訓和管理方面的問題將更為嚴重。3）軟件系統復雜程度和工程復雜程度和軟件系統規那么工程規 模一樣，軟件系統的復雜程度主要是考慮軟件系統本身的功能、 架構的復雜程度，而項旦的復雜程度主要是指工程團隊成員的 構成、工程任務的復雜程度、現目干系人的復雜程度、需求調 研的難易程度，多工程情況下資源保障的情況，等等等等。軟 件系統的規模與軟件系統的復雜程度未必是成比例的關系；同 樣過目的規模與工程的復雜程度未必是成比例的關系。4）工程的工期要求，就是工程的緊急程度。有些工程規模大, 卻因為與顧客簽訂了合同，或者為了搶先

23、占領市場，工期壓縮 得很緊，這時就要考慮如何更好地合理安排進度，多增加人選 多采用加班的方式是一種萬不得已的選擇。增加人選除了增加 人的本錢外必定會增加溝通的本錢（熟悉工程任務所需要的時 間）；加班如果處理不好會造成情緒上的問題，也可能會因為 過于忙碌而無法顧及質量，造成質量的下滑。5） 遜成員的能力。這些能力包括項E經理的管理能力，系 統分析員的分析能力、系統設計人員的設計能力、程序員的編 碼能力、測試人員的測試能力，以及企業或工程團隊激發出這 些能力的能力。從另外一個角度看還有總體上對客戶行業業務 的熟悉程度；對于建模工具、開發工具、測試工具篁技術的掌 握程度；企業內部對行業業務知識和主要

24、技術的知識積累。4工程控制計劃4.1質量保證計劃執行質量評審活動，對過程質量進行控制。規模較大的奧旦應 當單獨編寫軟件開發項旦質量計劃。根據GB/T 12504計 算機軟件質量保證計劃規范，內容包括1引言（本章節包括質量計劃的目的、定義、參考資料）1管理（描述負責軟件質量管理的機構、任務及其相關的職責）1文檔（列出在該軟件的開發、驗證與確認以及使用與維護等階段中需要編制的文檔，并描述對文檔進行評審與檢查的準那么）1標準、條例和約定（列出軟件開發過程中要用到的標準、條例和約定，并列出監督和保證執行的措施）1評審和檢查（規定所要進行的野和管理兩個方面的評審和檢查工作，并編制或引用有關的評審和檢查規

25、程，以及通過與 否的技術準那么。至少要進行軟件需求評審、概要設計評審、軟 件驗證與確認評審、軟件系統功能檢查、程序和文檔物理檢查）1軟件配置管理（編制有關配置管理條款，或在配置 管理計劃”中說明，或引用按照GB/T 12505計算機軟件配置 管理計劃規范單獨制定的文檔）1工具、技術和方法（指明用于支持特定軟件工程質量管理工作的工具、技術和方法,指出它們的目的和用途）1媒體控制（說明保護計算機程序物理媒體的方法和設施，以免非法存取、意外損壞或自然老化）1對供貨單位的控制（供貨單位包括現旦承辦單位、軟件銷售 單位、軟件開發單位。規定對這些供貨單位進行控制的規程， 從而保證工程承辦單位從軟件銷售單位

26、購買的、其他開發單位開發的或從開發單位現存軟件庫中選用的軟件能滿足規定的需求。）1記錄的收集、維護和保存（指明需要保存的軟件質量保證活 動的記錄，并指出用于匯總、保護和維護這些記錄的方法和設 施，并指明要保存的期限）4. 2進度控制計劃（可直接引用以下描述或根據工程情況制定本節內容） 本變旦的進度監控執行本企業更且管理規范，由本企業過 程控制部門如質量管理部統一進行監控，并保存在監控過程中 產生的日常檢查記錄。4. 3預算監控計劃說明如何檢查項1預算的使用情況。根據項旦情況需要制定。4. 4配置管理計劃編制有關軟件配置管理的條款，或引用按照GB/T 12505單獨制訂配置管理計劃文檔。在這些條

27、款或文檔中，必須規定用于標識軟件產品、控制和實現軟件的修改、記錄和報告修改實 現的狀態以及評審和檢查配置管理工作等四方面的活動。還必 須規定用以維護和存儲軟件受控版本的方法和設施；必須規定 對所發現的軟件問題進行報告、追蹤和解決的步驟，并指出實 現報告、追蹤和解決軟件問題的機構及其職責。根據GB/T 12505計算機軟件配置管理計劃規范，軟件配置管理計劃內容如下1引言（本章節包括質量計劃的目的、定義、參考資料） 1管理（描述負責軟件配置管理的機構、任務、職責及其有關的接口控制。）1軟件配置管理活動（描述配置標識、配置控制、配置狀態記錄與報告以及配置檢查與評審等到四方面的軟件配置管理活動 的需求

28、。）1工具、技術和方法（指明為支持特定項旦的軟件配置管理所 使用的軟件工具、技術和方法,指明它們的目的，并在開發者 所有權的范圍內描述其用法）1對供貨單位的控制（供貨單位是指軟件銷售單位、軟件開發單位或軟件子開發單位。必須規定對這些供貨單位進行控制的 管理規程，從而使從軟件銷售單位購買的、其他開發單位開發 的或從開發單位現存軟件庫中選用的軟件能滿足規定的軟件配 置管理需求）1記錄的收集、維護和保存（指明要保存的軟件配置管理文檔,指明用于匯總、保護和維護這些文檔的方法和設施，并指明要 保存的期限）4實施計劃風險評估及對策工作流程4. 3總體進度計劃4. 4工程監控4. 4.1質量控制計劃4. 4

29、. 2進度監控計劃4. 4. 3預算監控計劃4. 4. 4配置管理計劃5支持條件內部支持（可選）客戶支持（對工程而言）外包（可選）6預算（可選）6. 1人員本錢6.2設備本錢3其它經費預算4 妲合計經費預算7關鍵問題8專題計劃要點二、螞計劃書的編寫說明1引言編寫目的說明編寫這份工程計劃的目的，并指出預期的讀者。作用本節是為了說明編制“工程計劃書”亦即本文檔的意圖和希望到達的效果。注意這里的“目的”不是 遮I目標”,而 是為了說明本文檔的目的與作用。“工程目標”在2.1中說明。意義使項旦成員和奧旦干系人了解工程開發計劃書的作用、希 望到達的效果。開發計劃書的作用一般都是“項旦成員以及項 旦干系人之間的共識與約定，現且生命周期所有活動的行動基 礎，以便工程團隊根據本計劃書開展和檢查工程工作。” 例如可以這么寫為了保證工程團隊按時保質地完成工程目標, 便于工程團隊成員更好地了解工程情況，使工程工作開展的各 個過程合理有序，因此以文件化的形式，把對于在工程生命周 期