軟件項目計劃書范文
日子如同白駒過隙，不經意間，我們又將續寫新的詩篇，展開新的旅程，讓我們對今后的工作做個計劃吧。你所接觸過的計劃都是什么樣子的呢？以下是小編收集整理的軟件項目計劃書范文，僅供參考，希望能夠幫助到大家。
軟件項目計劃書范文1
一、項目實施方案概述
軟件產品，特別是行業解決方案軟件產品不同于一般的商品，用戶購買軟件產品之后，不能立即進行使用，需要軟件公司的技術人員在軟件技術、軟件功能、軟件操作等方面進行系統調試、軟件功能實現、人員培訓、軟件上線使用、后期維護等一系列的工作，我們將這一系列的工作稱為軟件項目實施。大量的軟件公司項目實施案例證明，軟件項目是否成功、用戶的軟件使用情況是否順利、是否提高了用戶的工作效率和管理水平，不僅取決于軟件產品本身的質量，軟件項目實施的質量效果也對后期用戶應用的情況起到非常重要的影響。項目實施規范主要包括項目啟動階段、需求調研確認階段、軟件功能實現確認階段、數據標準化初裝階段、系統培訓階段、系統安裝測試及試運行階段、總體驗收階段、系統交接階段等八個階段工作內容，每個階段下面有不同的工作事項，各個階段之間都是承上啟下關系，上一階段的順利完成是保證下一階段的工作開展的基礎。下面將按照每個項目實施階段分別介紹。
二、項目實施方案介紹
(一)項目啟動階段
此階段處于整個項目實施工作的最前期，由成立項目組、前期調研、編制總體項目計劃、啟動會四個階段組成。
此階段主任務：
公司：在合同簽定后，指定項目經理，成立項目組，授權項目組織完成項目目標。
公司項目組：進行前期項目調研，與用戶共同成立項目實施組織，編制《總體項目計劃》，召開項目啟動會。
商務經理：配合公司項目組，將積累的項目和用戶信息轉交給項目組。將項目組正式介紹給用戶，配合項目組建立與用戶的聯系。
用戶：成立項目實施組織，配合前期調研和召開啟動會，簽署《總體項目計劃》和《項目實施協議》。
1、成立項目組
部門經理接到實施申請后，任命項目經理，指定項目目標，由部門經理及項目經理一起指定項目組成員及成員任務，并報總經理簽署《項目任務書》。
2、前期調研
項目經理及項目組成員，在商務人員配合下，建立與用戶的聯系，對合同、用戶進行調研。填寫《用戶及合同信息表》。在項目商務談判中，商務經理積累了大量的信息，項目組首先應收集商務和合同信息，并與商務經理一起識別那些個體和組織是項目的干系人，確定他們的需求和期望，如何滿足和影響這些需求、期望以確保項目能夠成功。
3、編制《項目總體計劃》
《項目總體計劃》是一個文件或文件的集合，隨著項目信息不斷豐富和變化，會被不斷變更，主要介紹項目目標、主要項目階段、里程碑、可交付成果。通常包括以下幾方面內容：
項目描述，項目目標、主要項目階段、里程碑、可交付成果。所計劃的職責分配(包括用戶的);
溝通管理計劃，確定項目干系人對信息和溝通的需要：即什么人何時需要什么信息以及通過什么方式將信息提供給他們。質量管理計劃，確定適合于項目的質量標準和如何滿足其要求。如果有必要，可以包括上述每一個計劃，詳細程度根據每個具體項目的要求而定。未解決事宜和未定的決策。
4、啟動會
項目組與用戶共同召開的宣布項目實施正式開始的會議。
會程安排如下：
共同組建項目實施組織，實施組織的權利和職責;雙方簽署《項目實施協議》。
項目組介紹《項目總體計劃》和《項目實施協議》，包括以下內容：
項目目標、主要項目階段、里程碑、可交付成果。所計劃的職責分配(包括用戶的);
項目實施中項目管理的必要性和如何進行項目管理，項目的質量如何控制;
項目實施中用戶的參與和領導的支持的重要作用;
階段驗收、技術交接和項目結束后如何對用戶提供后續服務。
(二)需求調研確認階段
此階段的主要工作是軟件公司的項目實施人員向用戶調查用戶對系統的需求，包括管理流程調研、功能需求調研、報表要求調研、查詢需求調研等，實施人員調研完成后，會編寫《需求調研分析手冊》，并交付用戶進行確認，待用戶對《需求調研分析手冊》上所提到的需求確認完畢后，項目實施人員將以此為依據進行軟件功能的實現。如果用戶又提出新的需求，實施人員將分析需求的難度及對整個系統的影響程度來確定是否給予實現。需求調研階段具體包括如下內容：
1、進行需求調研準備
2、編制《需求調研計劃》
3、內部評審是否通過《需求調研計劃》，項目組、部門經理、商務等人員根據合同要求和項目實際情況對《需求調研計劃》草稿進行評審，如評審通過，則在稍后的時間內簽署，如評審不通過則重新修改。
4、用戶是否簽署《需求調研計劃》，如用戶簽署《需求調研計劃》，則作為以后需求調研工作的指南。否則重新修改。
5、《需求調研計劃》是否有變更，如果計劃存在變更，則執行變更控制流程，否則按計劃進行后續工作。
6、編寫及發出《需求調研通知》，項目組編寫《需求調研通知》，確定進行需求調研的相關事宜，發給用戶，為順利完成需求調研工作做準備
7、需求調研，項目組以《需求調研手冊》為依據，從業務流程、單據使用、打印格式、報表查詢幾個方面展開深入和全面的調研，并搜集用戶的個性化需求。
8、需求調研分析根據調研的結果，項目組和公司其他技術部門將進一步進行分析，確定合理、可行的需求，將分析結果形成《需求分析報告》草稿。
9、內部評審是否通過《需求分析報告》。項目組、部門經理、公司其他技術部門的人員對《需求分析報告》草稿進行評審，如評審通過，則在稍后由用戶簽署，如評審不通過則重新修改，直至內部評審通過。
10、編寫及發出《需求分析報告確認通知》。項目組編寫《需求分析報告確認通知》，發給用戶，確定進行需求確認的相關事宜，告之相關部門及人員安排好工作，準時參與需求確認工作，為順利完成需求確認工作做準備。
11、用戶是否確認《需求分析報告》。如果用戶確認，并簽署了《需求分析報告》，則需求調研階段工作結束，進行后續的軟件功能實現的工作;如沒有確認，則進一步進行調研、分析，直至用戶最終確認并簽署《需求分析報告》。雙方簽署了《需求分析報告》，需求調研工作結束之后，如果用戶提出新的需求或是變更已有的需求，則執行需求新增及變更流程。
(三)軟件功能實現確認階段
此階段的主要工作是項目實施人員根據需求調研階段確認的《需求調研分析手冊》中的用戶需求內容進行具體軟件功能的實現工作。在軟件功能實現的過程中，項目實施人員將記錄軟件實現的詳細過程。便于公司售后服務之用。每一個實施技術人員必須嚴格按照要求記錄、存檔。按照調研要求的所有功能實現完畢后，項目實施人員將編制《軟件功能確認表》，將定制好軟件功能待用戶確認，用戶根據《軟件功能確認表》上的功能逐一確定軟件功能是否達到要求，對不滿足要求的功能，項目實施人員將會記錄下來并進行功能修改，直到滿足用于要求。
(四)數據標準化初裝階段
此階段的主要工作是項目實施人員指導用戶進行系統標準化資料的準備工作，并對用戶進行初裝資料的軟件操作培訓，以便用戶能夠及時的將標準資料錄入系統，初裝完成后，項目實施人員會對資料初裝的情況進行核查，為以后具體業務功能的開展做好基礎。
(五)系統培訓階段
系統培訓階段工作是整個項目實施工作中比較重要的工作，用戶對軟件的操作功能是否熟練將直接影響到后面的軟件應用效果，所以軟件公司和用戶雙方要對此階段的工作給予足夠的重視。要充分認識培訓的重要性和艱巨性。在項目實施之前對用戶的相關人員進行系統和規范的產品培訓是非常必要的，達到讓用戶了解軟件產品，最終自己能夠解決使用中的具體的問題。
此階段的培訓工作中將用戶參加產品培訓的人員劃分為三個層次：決策層、技術層、操作層，對不同層次的用戶參加產品培訓人員的培訓內容分別是：
決策層：領導在實施中的作用與重要性、決策查詢。
維護層：系統維護知識、操作方法。
操作層：操作方法。
具體的培訓工作流程為：
1、調研培訓信息：在培訓開始前3天由用戶實施負責人，將參加培訓的部門和人員情況填入《受訓部門匯總表》、《受訓人員情況一覽表》。
2、編制培訓計劃：結合調研結果，與用戶實施負責人商議具體培訓內容、時間，場地，人員等。項目組編制《培訓計劃》。
3、簽署培訓計劃：用戶簽署《培訓計劃》，進一步確認培訓安排。
4、發培訓通知：培訓開始前2天，按照簽署的《培訓計劃》，將培訓內容、時間，場地，人員等信息通知用戶實施負責人。
5、搭建培訓環境：公司項目組在培訓開始前，將培訓環境搭建及檢查妥當，將培訓提綱及培訓手冊準備好。
6、組織培訓：公司項目組培訓負責人與用戶實施負責人組織相關人員參加培訓，按培訓制度嚴格考核。由用戶將考勤情況填入《培訓人員簽到表》。
7、培訓考核：公司項目組培訓負責人與用戶實施負責人組織受訓人員參加上機及理論考試。
8、培訓總結：公司項目組培訓負責人與用戶實施負責人一起將出勤情況及考核情況做出總結，填入《培訓及考核統計表》，及時向相關負責人匯報。
(六)系統安裝測試及試運行階段
此階段的主要工作是在用戶真實環境下，對用戶網絡及硬件設備進行測試，對軟件系統進行容量、性能壓力等測試測試及試運行的目的在于確保系統各項功能均能正常使用，并且符合用戶簽署的《需求分析報告》中描述的需求，同時把盡可能多的.潛在問題在正式運行之前發現并改正;同時目的還在于在正式運行前用戶的有關人員能進一步提高操作水平，掌握操作規范。此階段的主要工作內容為：
1、編制計劃： 與用戶實施負責人商議具體測試及試運行時間，地點，人員等安排，項目組編制《測試及試運行計劃》。
2、簽署計劃： 用戶簽署《測試及試運行計劃》，進一步確認測試及試運行安排。
3、發測試及試運行通知： 在測試及試運行開始前2天，按照簽署的《測試及試運行計劃》，將時間，地點，人員等信息通知用戶實施負責人。
4、搭建環境及數據準備： 在試運行開始前搭建好軟件環境、硬件環境、網絡環境、調通線路;檢查軟件、硬件、網絡、線路等各個環節是否有問題;
5、組織測試及試運行： 用戶相關各級領導給予全面配合，組織相關人員進行測試及試運行。公司項目組負責擔當指揮，檢查用戶人員組織情況并給予指導，跟蹤檢查如下情況：
跟蹤單據流轉狀況。
跟蹤新資料登錄環節。
觀察業務流程執行狀況。
觀察操作人員操作表現。
觀察系統運行速度及異常表現。
觀察關鍵數據的正確性。
及時糾正錯誤操作、對于新發生的問題及時與相關人員溝通，確定解決辦法。
6、測試及試運行總結： 測試及試運行完成，總結試運行中設備、軟件的運行情況，總結試運行中業務流程和操作環節的情況，以書面總結形式將測試及試運行結果通知相關負責人。
(七)總體驗收階段。此階段是對項目總體的完成情況進行驗收。驗收分階段進行，在每一項目階段結束時，用戶對這一階段的可交付成果進行驗收，在測試及試運行結束后，對系統進行總體驗收。
(八)系統交接階段。此階段是項目實施的最后一個階段，主要工作是軟件公司項目組向用戶移交軟件項目，包括軟件產品、項目實施過程中所生成的各種文檔，并簽署《售后服務協議》，項目將進入售后服務階段。軟件公司項目組還需要讓用戶填寫《用戶滿意度調查表》，對軟件公司項目實施人員的整個項目實施情況進行評價，軟件公司將聽取用戶的意見，再今后的項目實施管理中進行加強和改進。
三、軟件實施的成功之道
(一)軟件必須能滿足和適應企業需求
這一點是整個項目能否成功實施的最關鍵的一環。很多企業都在這一方面吃過虧，在選型時見到的軟件有很多功能模塊，在樣板企業里數據也能跑起來，但當軟件買回來了以后，卻發現了軟件的很多功能與企業的現實差別很大，所以根本就用不起來。不同企業之間的管理流程和對數據的要求差別很大，基本上兩個完全相同的企業是不存在的，世界上絕對不會有一種“萬能軟件”能滿足所有企業的需求。企業在選型軟件時，要充分考慮各種管理流程的特點、數據的來源、統計報表不同功能模塊的關系、企業員工的接受能力及與其它系統的接口等很多問題，所以企業選擇的必須是軟件提供商為企業訂制開發出來的。如果軟件提供商不為企業做前期需求分析和訂制開發，只是把現成的軟件賣給企業，它的實施成功率幾乎為零，如果是這樣的服務，企業還不如買一套盜版軟件。所以我們可以得出這樣的結論，企業買軟件提供商的不是它的軟件，而是它的開發能力。
(二)軟件是否能進行二次開發
因為企業現有的流程不是一成不變的，需不斷完善與改進，所以軟件的功能也需要能進行相應的修改，而且企業在第一次做項目需求時，有些問題可能忽略掉了，所以必須要求選型的軟件有強大的二次開發能力。如果軟件的結構過于僵死或二次開發能力不強，它未來可能會變成一塊“雞肋”，讓企業有種“食之無味、棄之可惜”的感覺。測試軟件是否具有快速二次開發能力的方法也不難，就是企業在選型時，不僅要看軟件提供商如何演示，還要提出一些個性化需求，看看對方能否迅速開發出來。
(三)軟件和實施費用應相對便宜
企業第一次實施由于經驗上的不足，風險不是沒有，確實有許多優秀的企業是通過第二次實施才獲得了成功。因此企業在第一次選型軟件時，不要只注意軟件提供商的品牌和規模，因為價格越高，企業自身的風險就越高。我們建議企業最好還是購買那些物美價廉的產品，也就是當所選軟件都能滿足企業現實需求且能進行二次開發時，企業最好選擇價格便宜的那家，就好像一個人剛學會開車，就要買一輛奔馳轎車，無論這個人是否真正有錢都不是明智的選擇。現在出現了平臺化組構的軟件產品，它可以通過建模工具迅速按照客戶的需求進行軟件開發，這樣就大量地節約軟件開發周期和成本，而且二次開發工作也變得十分的簡單，所以企業最好選擇這樣的產品。
(四)軟件操作要簡單、易學
由于許多企業過去沒有信息化建設的經驗，員工一下子由過去的手工工作轉為計算機工作肯定有一個適應過程，如軟件組構和操作過于復雜，那么一定會加大培訓和實施的難度。
軟件項目計劃書范文2
1、引言
1、1編寫目的
本報告的主要作用是確定各個項目模塊的開發情況和主要的負責人，供各項目模塊的負責人閱讀，做到及時協調，按步有序進行項目的開發。減少開發中的不必要損失。
便于項目團隊成員更好地了解項目情況，使項目工作開展的各個過程合理有序，因此以文件化的形式，把對于在項目生命周期內的工作任務范圍、各項工作的任務分解、項目團隊組織結構、各團隊成員的工作責任、團隊內外溝通協作方式、開發進度、經費預算、項目內外環境條件等內容做出的安排以書面的方式，作為項目團隊成員以及項目干系人之間的共識與約定，項目生命周期內的所有項目活動的行動基礎，項目團隊開展和檢查項目工作的依據。
具體步驟：擬訂開發計劃書，分配項目工作，安排項目進度
計劃對象：網上書店開發小組
2、項目概述
2、1項目背景
隨著網絡技術的發展，Internet已成為最具市場潛力的技術領域，使用Web技術設計的數據庫應用軟件，是目前Internet市場的技術中堅，各種Web應用如電子商務，網上購物等都采用這種方式實現。互聯網的優勢在于用戶能同時從不同地點、不同數據庫中存取數據。
網上購物系具體是指利用各種電子工具與網絡，高效率，低成本地從事以商品交換為中心的各種商務貿易活動。電子商務應用的興起已經促使商品流通領域發生了一場巨大的`革命。
它打破了時空的界限，加速了整個社會的商品流通，有效地降低了企業生產成本，提高企業競爭力。電子商務的一個重要技術特征。是利用Web技術來傳輸與處理商業信息，因此有人稱：電子商務=web+IT。因此我們將開發一個典型的電子商務系統：網上書店。
2、2項目目標與范圍
2、2、1目標和范圍描述
項目：網上購書系統
該系統適用于在網上書籍交易，網上書店的管理，通過此軟件系統對書籍進行有效管理，靈活的滿足自己客戶需要。
問題：實地購書比較麻煩，購書范圍小，能購書的種數也有限。
項目目標：開發一個網上購書系統是項目的總目標，為實現項目的總目標可按以下三個階段目標來進行：
第一階段目標：實現網上購書系統的基本功能，小組個成員進行各個模塊的開發，形成初步的系統。
第二階段目標：攻克技術上的難題，實現網上購書系統的一些特殊功能，進一步完善系統。
第三階段目標：讓系統投入到實際運用中，做好系統的維護工作。
項目范圍：利用現有的微型計算機，借鑒前人的網上購書系統開發經驗、徐州博庫網上書城和資料中的電子商鋪系統的開發模式，預計軟件開發費用不超過***元。
初步設想：建議在系統中增加一個BBS的模塊，方便用戶發表言論。
2、2、2主要功能
(1)概述
可行性分析：這個系統沒有經濟效益，不能收回成本，但可以得到知識，熟悉做項目的過程;現有的技術能夠完成系統的基本功能，但做BBS論壇還有一定的技術困難，開發這個新系統，只是借鑒前人的開發模式，做出有個人特色的網上購書系統，僅供平時學習用。不會引起任何的侵權問題。通過對用戶的進一步訪問，用戶希望能夠通過互連網，能夠瀏覽書籍，查找他們想要的書籍，并能夠訂購要買的書，這不僅很方便，還節省了用戶的時間。
(2)傳統購書系統流程圖
網上購書流程
(3)功能描述
圖書查詢和瀏覽功能：當進入網上書店后，無需登錄，就可以瀏覽書籍，而電子書店還可以提供一個更好的功能，即通過圖書名稱、類別等信息從浩瀚的書海中迅速的找到的書。
用戶登錄注冊功能：在用戶購買的圖書時，系統將判斷其是否登錄，如果沒有，則轉向登錄界面，登錄后，系統還將轉向原來用戶瀏覽的頁面。
購物車功能：用戶登錄后，就可以把圖書放入購物籃中，可以對購物籃進行管理，包括修改所購圖書數量、刪除圖書等。
圖書信息管理功能：管理人員可以添加圖書，修改圖書的類別，價格，上傳圖書的相關圖片等。
定單信息管理功能：用戶確認購買圖書，將形成一條訂單信息，用戶可以查詢自己的定單。管理員可以查看定單，售出書籍。
2、2、3性能
2、2、4管理和技術約束
由于沒有做過項目的經驗，在加上編程技術的限制，小組人員少，時間的限制只能實現一個具有簡單功能的網上購書系統。
2、項目估算
2、1使用的歷史數據
徐州博庫網上書店、電子商鋪系統
2、2使用的評估技術
軟件規模估算：采用類比的方法，根據歷史數據來進行估算
工作量估算：基本COCOMO模型
成本估算：基本COCOMO模型
時間估算：基本COCOMO模型
2、3工作量、成本、時間估算
軟件規模：LOC=[(50(重新設計)%+50(重新編碼)%+重新測試(100)%)/3]×已有代碼行(20000)=13000
工作量估算：人員：六人
成本估算：資料費(資料費、復印費)
通信費(移動通信費、上網費、電費)
時間估算：
基本COCOMO模型把工作量作為軟件規模的函數來計算，其計算公式為：
E=aS^bS是以千源代碼行(KLOC)計數的程序規模，a，b為開發模式因子
在我們的項目中，我們采用半分離式，因此a取值為3、0，b取值為1、12
即E=3、0*13^1、12=53、056
根據計算的工作量，我們由下面公式計算所需的開發時間：
t=cE^dE為我們所計算的工作量人月為單位，c，d是隨開發模式而改變的因
子，在這里我們同樣采用半分離式，c取值為2、5，d取值為0、35
即t=2、5*53、056^0、35=10、036
在小組中，我們共六人，大約2個月完成任務。
軟件項目計劃書范文3
計算機軟件特別是數據庫軟件已成為當今計算機應用的核心力量，因此軟件開發人員需掌握精準的開發技巧，了解整個開發過程，這樣才能使他們對軟件項目有清晰的認識，從而獲得事半功倍的效果。
1 開發前的準備工作
一般來說，每個軟件項目在開發之前都會有一份系統任務書，明確了軟件的開發目標、主要任務、功能、性能指標，還有研究人員和經費、進度等方面的安排，這將是系統設計開發和驗收的基本依據。
然而，系統任務書只是對軟件項目的基本要求。面對具體情況，軟件開發人員和需求分析師需要共同探討并詳細分析軟件項目的細節。必要時還需要進行實地考察，最后共同制定出系統的需求分析。需求分析的`目標在于：
確保軟件在軍事、技術、經濟和社會環境上的可行性和必要性；
分析現有系統（工作環境）的狀態，描繪待開發系統的具體需求，為用戶提供與開發人員之間的交流基礎，并提供項目設計的基本信息。
需求分析報告的基本框架包括：
概述：包括編寫的目的、背景、參考資料和術語縮寫；
現有系統的分析；
待開發系統的詳細需求；
使用環境；
可行性分析；
結論意見。
2 軟件開發過程
擁有系統任務書和需求分析報告后，軟件設計師就需要對軟件項目的實現進行系統分析，系統分析包括系統的整體方案、系統設計說明，它們是軟件設計的重要參考。
2.1 系統總體方案
基于系統開發單位和用戶的深入互動和理解，我們需要提出系統的技術架構，明確系統的功能、性能等主要指標，規定實現方法和要求，這些都是系統進行詳細設計的基礎。
系統總體方案基本框架包括：
引言：包括編寫的目的、背景、參考資料和術語縮寫；
項目概述；
實施總計劃。
2.2 系統設計說明
根據《系統總體方案》提出的系統架構、功能、性能及數據要求，我們需要確定系統的物理結構，闡述系統主要技術方面的設計和采用的技術方法以及系統的標準化約束等，這些都是系統實施的基本依據。
2.3 軟件開發
開發語言的選擇因人而異，開發數據庫系統我更傾向于DELPHI，因為它對數據庫開發的支持非常完善。
在軟件實現方面，我們已經說明了一種客戶/服務器結構，但這種結構本身也有一些問題，例如客戶/服務器結構經常將應用系統的企業邏輯編寫在客戶端的應用程序中，因此當應用系統需要改變時，所有在客戶端的應用系統都必須改變，這對MIS系統的維護來說成本太高了。為了解決這些問題，我們必須導入所謂的應用程序服務器，軟件開發人員以一種特定的組件形式，如Microsoft的COM/DCOM，CORBA對象，或EnterpriseJavaBean等，組裝企業的邏輯程序代碼。這種經過組裝，能夠執行特定企業功能的對象便稱為"企業對象"，然后把這些企業對象分發到此應用程序服務器。
關于程序設計中的技巧有很多，這里不再贅述。
3 軟件開發后的工作
軟件項目在開發完成后還需要進行系統測試，以驗證開發出來的軟件的功能和性能是否達到預期要求。
3.1 軟件測試大綱
這是軟件設計人員用來自測系統的。包括：
測試環境；
功能測試內容；
性能測試內容；
附錄：附表一 系統功能測試表；附表二 系統性能測試表。
3.2 用戶應用測試
由用戶在實際使用過程中進行測試，并給出應用證明。
4、總結
開發軟件項目是一個龐大的系統工程，上述只是介紹了通用軟件特別是數據庫軟件的開發過程和設計理念。它要求軟件開發者對其有深入的理解，熟悉軟件開發的思路。
通常一個人難以完成所有工作，需要一個優秀的合作團隊來協同完成。其中，需求分析師和系統分析師負責提供軟件項目的具體要求和設計理念，由軟件開發組把這些要求轉化為易于維護和持續發展的系統資源。
軟件項目計劃書范文4
計算機軟件尤其是數據庫軟件，成為了當代計算機應用的主流。因此軟件開發人員就必須掌握正確的開發手段，了解軟件開發的主要過程，這樣心中對軟件項目才有清醒的認識，才能達到事半功倍的效果。本文就軟件開發過程中的一些方法，結合本人開發過的一些軟件項目做一些詳細論述。
1 開發前的準備工作
一般軟件項目在開發前都有系統任務書，主要規定軟件的開發目標、主要任務、功能、性能指標及研制人員和經費、進度等安排，作為系統設計開發和檢驗的基本依據。
系統任務書的基本框架如下：
(1)引言
包括編寫目的，背景，參考資料。
(2)系統的目標及任務
包括系統建設目標，系統的主要任務，系統性能指標，系統標準化要求。
(3)系統的結構及功能
包括系統應用組成及結構，系統主要功能。
(4)系統的規模及進度要求
包括系統規模，系統研制進度，人員計劃。
但是系統任務書只是這個軟件項目的一個基本要求，針對具體情況，軟件開發人員和需求分析人員就要聯合對軟件項目的細節進行具體分析，必要時還要進行實地調研，然后共同商討寫出系統的需求分析，需求分析的編寫目的在于：
a. 說明系統在軍事方面、技術方面、經濟方面和社會條件方面實現的可行性和必要性;
b. 分析原系統(工作環境)現狀,描述待開發系統的詳細需求，提供用戶和開發人員之間溝通的基礎，提供項目設計的基本信息。
需求分析報告的基本框架如下：
(1) 概述
包括 編寫目的，背景，參考資料，術語及縮寫詞。
(2) 對現有系統的分析
(3)待開發系統的詳細需求
包括 功能需求，使用范圍，業務流程，用戶界面，輸出要求，故障處理。
(4)使用環境
包括 網絡環境，硬件環境，軟件環境，與其他系統的關系，安全與保密。
(5) 可行性分析
包括 技術可行性分析，經濟可行性分析，人員可行性分析，影響待開發系統的主要因素。
(6)結論意見
2 軟件開發過程
有了系統任務書和需求分析報告，軟件設計人員就要對軟件項目的實現進行系統分析，系統分析包括系統的總體方案，系統的設計說明，作為軟件設計的依據。具體說明如下。
2.1 系統總體方案
在系統開發單位和用戶充分交互、理解的基礎上，提出系統的技術構架，對系統功能、性能等主要指標作描述，對實現方法和要求作規定，是系統進行詳細設計的依據。
系統總體方案基本框架包括：
(1)引言
包括 ：編寫目的，背景，參考資料，術語及定義。
(2)項目概述
包括 ：
--項目的主要內容
--系統需求分析：①用戶需求調查分析②現行系統的現狀調查分析。
--系統功能：①系統的功能要求②系統主要技術性能。
--系統的數據要求：①基礎數據②業務數據③交換數據④其它數據。
--系統的設計要求：①技術結構要求②系統劃分及其接口要求③系統運行環境要求④系統標準化綜合要求。
(3)實施總計劃
包括 ：進度，預算，問題和措施。
2.2 系統設計說明
根據《系統總體方案》提出的系統構架、功能、性能及數據要求，確定系統的物理結構，說明系統主要技術方面的設計和采用的技術方法以及系統的標準化約束等，是系統實施的基本依據。就本人曾經開發過的一個軟件項目，說明其基本框架：
(1) 引言
包括 ：編寫目的;背景;條件和限制;參考資料;術語及定義。
(2) 系統總體技術方案
包括：
--概述：①系統目標②基本要求。
--系統設計：
①系統結構
a、 應用結構。
b、 功能結構。
c、 技術結構。
② 系統功能設計：根據以上的分析，功能設計自然
包括業務管理功能設計、綜合查詢功能設計、郵件收發功能設計、數據庫接口設計、文電接口設計。在對這些功能進行綜合分析的基礎上，開始進行數據庫表的設計。在對表的設計過程中，既要考慮到關系數據庫冗余字段的處理，又要考慮到系統運行的速度和實現的方便性等綜合因素，筆者在實際開發后認為這兩種考慮比例可以為7：3。
③系統安全設計：可以考慮以下一些安全設計思想，例如系統的數據傳輸通過電子郵件實現，要求電子郵件內部只傳代碼，不傳涉密數據;系統的數據庫操作需要充分利用Oracle數據庫的事務提交和回滾機制，確保業務處理的完整性和一致性;系統的數據結構應充分利用存儲空間，在不同的用戶之間通過數據冗余提高整個系統的數據安全性;系統中存貯的用戶口令、備份口令、數據庫連接信息等重要數據，必需經過安全加密。
④ Oracle數據庫自動優化設計：對于Oracle數據庫可以進行數據庫配置，可以大大提高大數據量查詢速度，筆者已經做過嘗試，并已經成功應用。
⑤ 友好界面設計：對于一個良好的應用系統當然需要設計良好的使用界面。
2.3 軟件開發
對于開發語言的選擇因人而易，開發數據庫系統我比較傾向于DELPHI，因為它對于數據庫開發的支持是很完善的。在軟件實現方面，上面已經說明了一種客戶/服務器結構，但是這種結構本身也包含了一些問題，例如客戶/服務器結構經常把應用系統的企業邏輯編寫在客戶端的應用程序中，因此當應用系統需要改變時，所有在客戶端的應用系統都必須改變，這對于MIS系統的維護來說成本太高了;為了解決這些重復開發應用系統的.成本以及為了增加應用系統的重復使用性發揮面向對象分析/面向對象設計的功能，就必須導入所謂的應用程序服務器，軟件開發人員以一種特定的組件形式，例如Microsoft的COM/DCOM，CORBA對象，或是EnterpriseJavaBean等，組裝企業的邏輯程序代碼。這種經過組裝，能夠執行特定企業功能的對象便稱為"企業對象"，然后把這些企業對象分發到此應用程序服務器。由于本文不是專門討論多層系統的文章，所以只是簡單提一下，不再贅述。
程序設計中要注意合理的程序設計結構，可以將所有的公用組件放在一起。例如Delphi語言中可以新建一個單元，將所有編寫的函數放在這個單元里，其他單元均可以調用，還可以新建一個數據模塊(Datamodule),將所有的公共數據庫控件放在這里，可以減少系統資源浪費，優化數據庫程序設計。
關于程序設計中的技巧很多，這里也不再贅述。
3 軟件開發后的工作
軟件項目在開發完成后還要進行系統測試，以測試開發出的軟件的功能和性能是否達到預定要求。
3.1 軟件測試大綱
這是軟件設計人員用來自測系統的。包括：
(1)測試環境①硬件環境②軟件環境③數據環境④網絡環境。
(2)功能測試內容①模擬現場測試②應用現場測試。
(3)性能測試內容
另有附表：附表一 系統功能測試表;附表二 系統性能測試表。
3.2 用戶應用測試
由用戶在實際使用過程中進行測試，并給出應用證明。
4、總結
開發軟件項目是一個龐大的系統工程，以上只是介紹了一般性軟件主要是數據庫軟件的開發過程和設計思想，它要求軟件開發者對此要有精深的理解，熟悉軟件開發的思路。
通常一個人難以完成所有工作，需要一個良好的合作團隊來協作完成，其中需求分析員和系統分析員要提供軟件項目的具體要求和設計思想，由軟件開發組把這些要求創建出便于維護和可持續開發的系統資源。
軟件項目計劃書范文5
一、引言
撰寫此文檔的目的在于保證項目順利完成所需的所有工作，同時僅包含必要的過程。它是項目管理團隊用來確定、記錄、驗證、管理和控制項目范圍的指導。本文涵蓋了創建工作分解結構以及確定如何維護和批準這個結構的方式；還規定了如何正式核實和接受項目的已完成可交付成果。
二、參考資料
韓萬江，姜立新編著，《軟件項目管理案例教程》，機械工業出版社。
張海藩編著，《軟件工程導論》(第五版)，清華大學出版社。
王宏編著，《酒店管理工作——細化執行與模板》，人民郵電出版社。
三、重要術語
SQL Server 20xx：數據庫管理軟件。
DBMS：數據庫管理系統。
Windows XP：運行環境。
vb.net 20xx：軟件開發語言。
visual studio 20xx：軟件開發環境。
四、項目概述
五、系統與項目的定義
該系統是在C/S系統架構基礎上，利用SQL Server數據庫，使用vb.net技術構建的酒店信息化管理系統。它基本滿足了酒店管理的需求，具有友好的用戶界面。系統通過對用戶（主要是酒店管理層和員工）的數據進行有效的電子化處理，降低了人工勞動并增加了信息的準確性。該系統主要包括客房、餐飲、財務和人力資源等方面的信息，用戶登錄后可根據權限操作這些信息。
六、系統開發背景與目標
在當今信息高度發達的時代，酒店業務已經不再局限于傳統的住宿和結算業務，而是變得更加廣泛和全面的服務行業。為了提高酒店管理水平，簡化復雜的操作，需要在最短的時間內完成酒店業務的規范化操作，讓客戶感到舒適和滿意。對于酒店業的'競爭形勢，許多酒店都在嘗試通過信息技術擴展其服務能力。雖然信息化并不是決定酒店成功的關鍵因素，但它可以幫助那些真正影響成功的因素發揮更大的作用。因此，采用全新的酒店管理系統將是提高酒店管理效率和改善服務質量的重要手段之一。
七、用戶需求概述及系統主要功能
八、項目范圍界定
九、開發技術選擇與理由
開發酒店管理系統時，選擇了可視化Visual 20xx和SQL Server 20xx數據庫，Windows XP操作系統等作為軟硬件平臺。VB具有圖形用戶界面（GUI），可以輕松地使用ADO連接數據庫。程序員可以通過使用VB提供的組件快速建立一個應用程序。這些都是團隊成員熟悉的語言和技術，因此技術方面完全可以實現酒店管理系統的最終目標。綜上所述，我們的團隊完全有能力完成酒店管理系統的最終實現。
十、開發團隊與開發環境、工作方式
軟件項目計劃書范文6
一、項目計劃書格式
根據《gbxxx計算機軟件產品開發文件編制指南》中項目開發計劃的要求，結合實際情況調整后的《項目計劃書》內容索引如下：xxx
二、項目計劃書的編寫說明
1 引言
1.1 編寫目的
說明編寫這份項目計劃的目的，并指出預期的讀者。
作用：本節是為了說明編制"項目計劃書"亦即本文檔的意圖和希望達到的效果。注意這里的"目的"不是"項目目標"，而是為了說明本文檔的目的與作用。"項目目標"在2.1中說明。
意義：使項目成員和項目干系人了解項目開發計劃書的作用、希望達到的效果。開發計劃書的作用一般都是"項目成員以及項目干系人之間的共識與約定，項目生命周期所有活動的行動基礎，以便項目團隊根據本計劃書開展和檢查項目工作。"
例 如可以這么寫：為了保證項目團隊按時保質地完成項目目標，便于項目團隊成員更好地了解項目情況，使項目工作開展的各個過程合理有序，因此以文件化的形式， 把對于在項目生命周期內的工作任務范圍、各項工作的任務分解、項目團隊組織結構、各團隊成員的工作責任、團隊內外溝通協作方式、開發進度、經費預算、項目 內外環境條件、風險對策等內容做出的安排以書面的方式，作為項目團隊成員以及項目干系人之間的共識與約定，項目生命周期內的所有項目活動的行動基礎，項目 團隊開展和檢查項目工作的依據。
常見的問題：把項目本身的"項目目標"誤作編制項目開發計劃的目的。
1.2 背景
主要說明項目的來歷，一些需要項目團隊成員知道的相關情況。主要有以下內容：
項目的名稱：經過與客戶商定或經過立項手續統一確定的項目名稱，一般與所待開發的軟件系統名稱有較大的關系，如針對"xx系統"開發的項目名稱是"xx系統開發"。
項目的委托單位：如果是根據合同進行的軟件開發項目，項目的委托單位就是合同中的甲方；如果是自行研發的軟件產品，項目的委托單位就是本企業。
項目的用戶（單位）：軟件或網絡的使用單位，可以泛指某個用戶群。注意項目的用戶或單位有時與項目的委托單位是同一個，有時是不一樣的。如海關的報關軟件、 稅務的報稅軟件，委托單位是海關或稅務機關，但使用的用戶或單位不僅有海關或稅務機關，還包括需要報關、報稅的企業單位。
項目的任務提出者：本企業內部提出需要完成此項目的人員，一般是領導或商務人員；注意項目的任務提出者一般不同于項目的委托單位，前者一般是企業內部的人員。如果是內部開發項目，則兩者的區別在于前者指人，后者指單位。
項 目的主要承擔部門：有些企業根據行業方向或工作性質的不同把軟件開發分成不同的部門（也有的分為不同事業部）。項目的特點就是其矩陣式組織，一般一個項目 的項目成員可能由不同的部門組成，甚至可能由研發部門、開發部門、測試部門、集成部門、服務部門等等其中幾個組成。需要根據項目所涉及的范圍確定本項目的 主要承擔部門。
項目建設背景：從政治環境上、業務環境上說明項目建設背景，說明項目的大環境、來龍去脈。這有利于項目成員更好地理解項目目標和各項任務。
例句：根據《某部關于某建設工作的實施意見》精神，為了保障某建設工作的正常實施，必須加強監督考核，建立督查通報制度，某市某建設工作小組辦公室把此項建設工作實施列入督查的重要內容，及時掌握進度，相關部門建立市某建設工作簡報制度，及時反映全市某建設工作動態。
目 前對于某建設工作的工作主要采用計劃部門手工編制年度計劃、建設工作主管部門和建設工作實施單位聯合手動編制進度計劃，某建設工作單位手工上報建設工作進 度情況的方式，而全市的建設工作有數百個，加上前期建設工作的數量和今后某市建設發展的趨勢，建設工作的數量將越來越多，原來的工作模式已經越來越無法適 應市委市政府的要求。因此，充分利用現代信息化、因特網的優勢，建立"某市某建設工作信息報送反饋系統"，提高某建設工作信息報送反饋工作效率，提高信息 的及時性、減輕各級相關工作人員的勞動強度是非常有必要和緊迫的任務。
軟件系統與其他系統的關系：說明與本系統有關的其他系統，說明它們之間的相 互依賴關系。這些系統可以是這個系統的基礎性系統（一些數據、環境等必須依靠這個系統才能運行），也可以是以這個系統為基礎的系統，或者是兩者兼而有之的 關系、互相依賴的系統。例句：本系統中對外部辦公部分如需要各個建設單位報送材料的子系統應當掛在市政府的網站。
軟件系統與機構的關系：說明軟件系統除了委托單位和使用單位，還與哪些機構組織有關系。例如一些系統需要遵守那些組織的標準、需要通過那些組織機構的測試才能使用等等、是否需要外包或與那些組織機構合作。
1.3 定義
列出為正確理解本計劃書所用到的專門術語的.定義、外文縮寫詞的原詞及中文解釋。注意盡量不要對一些業界使用的通用術語進行另外的定義，使它的含義和通用術語的慣用含義不一致。
1.4 參考資料
列 出本計劃書中所引用的及相關的文件資料和標準的作者、標題、編號、發表日期和出版單位，必要時說明得到這些文件資料和標準的途徑。本節與下一節的"標準、 條約和約定"互為補充，注意"參考資料"未必作為"標準、條約和約定"，因為"參考"的不一定是"必須遵守"的。常用資料如：
本項目的合同、標書、上級機關有關通知、經過審批的項目任務書；屬于本項目的其他已經發表的文件；本文檔中各處引用的文件、資料，包括所要用到的軟件開發標準。
1.5 標準、條約和約定
列出在本項目開發過程中必須遵守的標準、條約和約定。例如：相應的《立項建議書》、《項目任務書》、合同、國家標準、行業標準、上級機關有關通知和實施方案、相應的技術規范等。
"參考資料"一般具有"物質"特性，一般要說明參照了什么，要說明在哪里可以獲得；"標準、條約和約定"一般具有"精神"特性，一般是必須遵守的，不說明在哪里可以獲得。參考資料的內容應該涵蓋"標準、條約和約定"。
2 項目概述
2.1 項目目標
設定項目目 標就是把項目要完成的工作用清晰的語言描述出來，讓項目團隊每一個成員都有明確的概念。注意，不要簡單地說成在什么什么時間完成開發什么什么軟件系統或完 成什么什么軟件安裝集成任務。注意"要完成一個系統"只是一個模糊的目標，它還不夠具體和明確。明確的項目目標應該指出了服務對象，所開發軟件系統最主要 的功能和系統本身的比較深層次的社會目的或系統使用后所起到的社會效果。
項目目標應當符合smart原則：
s specific 明確的陳述
m measurable 可以衡量的結果
a attainable 可以達成的目標
r realistic 合理的，現實的或者說是能和實際工作相結合
t trackable 可以跟蹤的
項 目目標可以進行橫向的分解也可以進行縱向的分解。橫向分解一般按照系統的功能或按照建設單位的不同業務要求，如分解為第一目標、第二目標等等；縱向的分解 一般是指按照階段，如分解為第一階段目標、第二階段目標等等，或近期目標、中期目標、遠期目標等等。階段目標一般應當說明目標實現的較為明確的時間。一般 要在說明了總目標的基礎上再說明分解目標，可加上"為實現項目的總目標，必須實現以下三個階段目標......"
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/t 12504 計算機軟件質量保證計劃規范，內容包括：
引言（本章節包括質量計劃的目的、定義、參考資料）
管理（描述負責軟件質量管理的機構、任務及其相關的職責）
文檔（列出在該軟件的開發、驗證與確認以及使用與維護等階段中需要編制的文檔，并描述對文檔進行評審與檢查的準則）
標準、條例和約定（列出軟件開發過程中要用到的標準、條例和約定，并列出監督和保證執行的措施）
評審和檢查（規定所要進行的技術和管理兩個方面的評審和檢查工作，并編制或引用有關的評審和檢查規程，以及通過與否的技術準則。至少要進行軟件需求評審、概要設計評審、軟件驗證與確認評審、軟件系統功能檢查、程序和文檔物理檢查）
軟件配置管理（編制有關配置管理條款，或在"4.4.4 配置管理計劃"中說明，或引用按照《gb/t 12505 計算機軟件配置管理計劃規范》單獨制定的文檔）
工具、技術和方法（指明用于支持特定軟件項目質量管理工作的工具、技術和方法，指出它們的目的和用途）
媒體控制（說明保護計算機程序物理媒體的方法和設施，以免非法存取、意外損壞或自然老化）
對供貨單位的控制（供貨單位包括項目承辦單位、軟件銷售單位、軟件開發單位。規定對這些供貨單位進行控制的規程，從而保證項目承辦單位從軟件銷售單位購買的、其他開發單位開發的或從開發單位現存軟件庫中選用的軟件能滿足規定的需求。）
記錄的收集、維護和保存（指明需要保存的軟件質量保證活動的記錄，并指出用于匯總、保護和維護這些記錄的方法和設施，并指明要保存的期限）
4.4.2 進度控制計劃
（可直接引用以下描述或根據項目情況制定本節內容）
本項目的進度監控執行本企業《項目管理規范》，由本企業過程控制部門如質量管理部統一進行監控，并保留在監控過程中產生的日常檢查記錄。
4.4.3 預算監控計劃
說明如何檢查項目預算的使用情況。根據項目情況需要制定。
4.4.4 配置管理計劃
編 制有關軟件配置管理的條款，或引用按照gb/t 12505單獨制訂《配置管理計劃》文檔。在這些條款或文檔中，必須規定用于標識軟件產品、控制和實現軟件的修改、記錄和報告修改實現的狀態以及評審和檢 查配置管理工作等四方面的活動。還必須規定用以維護和存儲軟件受控版本的方法和設施；必須規定對所發現的軟件問題進行報告、追蹤和解決的步驟，并指出實現 報告、追蹤和解決軟件問題的機構及其職責。
5 支持條件
說明為了支持本項目的完成所需要的各種條件和設施。
5.1 內部支持
逐項列出項目每階段的支持需求（含人員、設備、軟件、培訓等）及其時間要求和用途。
例如，設備、軟件支持包括客戶機、服務器、網絡環境、外設、通訊設備、開發工具、操作系統、數據庫管理系統、測試環境，逐項列出有關到貨日期、使用時間的要求。
5.2 客戶支持
列出對項目而言需由客戶承擔的工作、完成期限和驗收標準，包括需由客戶提供的條件及提供時間。
5.3 外包（可選）
列出需由外單位分合同承包者承擔的工作、完成時間，包括需要由外單位提供的條件和提供的時間。
6 預算
6.1 人員成本
列出產品/項目團隊每一個人的預計工作月數。
列出完成本項目所需要的勞務（包括人員的數量和時間）
勞務費一般包括工資、獎金、補貼、住房基金、退休養老金、醫療保險金
6.2 設備成本
設備成本包括：原材料費，設備購置及使用費
列出擬購置的設備及其配置和所需的經費
列出擬購置的軟件及其版本和所需的經費
使用的現有設備及其使用時間
6.3 其它經費預算
列出完成本項目所需要的各項經費，包括差旅費、資料費、通行費、會議費、交通費、辦公費、培訓費、外包費等，包括：
（1） 差旅費（旅費、出租）（含補貼）
（2） 資料費（圖書費、資料費、復印費、出版費）
（3） 通信費（市話長話費、移動通信費、上網費、郵資）
（4） 會議費（鑒定費、評審會、研討費、外事費等）
（5） 辦公費（購買辦公用品）
（6） 協作費（業務協作招待費、項目團隊加班伙食費）
（7） 培訓費（培訓資料編寫費、資料印刷費、產地費、設備費）
其他（檢測、外加工費、維修費、消耗品、低易品、茶話會等）
6.4 項目合計經費預算
列出完成本項目需要的所有經費預算（上述各項費用之和）。
7 關鍵問題
逐項列出能夠影響整個項目成敗的關鍵問題、技術難點和風險，指出這些問題對項目成敗的影響。
8專題計劃要點
專題計劃也就是因為項目的需要在本文檔之外獨立建立的計劃，本節說明本項目開發中需要制定的各個專題計劃的要點。專題計劃可能包括分合同計劃、分項目計劃、項目團隊成員培訓計劃、測試計劃、安全保密計劃、質量保證計劃、配置管理計劃、用戶培訓計劃、系統安裝部署計劃。
【軟件項目計劃書】相關文章：
軟件創業計劃書05-27
軟件創業計劃書范文02-12
關于軟件項目實訓報告12-09
軟件開發項目個人總結03-18
商業項目計劃書07-02
項目計劃書范文03-06
商業或項目計劃書11-22
項目商業計劃書06-15
項目計劃書范文[精選]12-12