軟件項目計劃書(模板)

1 赤峰學院 軟件項目計劃書 項目名稱 酒店客房管理系統(tǒng) 年級專業(yè) 信息與計算科學專業(yè) 10 級 3 班 組 長 謝明敏 小組成員 陳冬雪、胡玉蓮、夏喜鋒、 韓永亮 、張瑞剛 指導教師 秦曉薇 二零一三年 十月 二十二日 2 目錄 1 概述.1 1.1 項目概述.1 1.2 項目交付的產(chǎn)品.1 1.3 SPMP 的演化.1 1.4 參考資料.1 1.5 定義、縮寫詞以及簡寫.1 2 項目組織.1 2.1 外部接口.1 2.2 內部組織結構.2 2.3 角色與職責劃分.2 3 管理過程.2 3.1 項目啟動計劃.2 3.2 工作計劃.2 3.3 控制計劃.2 3.4 風險管理計劃.2 3.5 項目收尾計劃.3 4 計劃過程.3 4.1 過程模型.3 4.2 方法、工具和技術.4 4.3 基礎設施.4 5 支持過程.4 5.1 工作包.4 5.2 依賴關系.4 5.3 資源需求.5 5.4 預算和資源分配.5 5.5 進度表.5 -1- 1 概述 1.1 項目概述 項目的目標是開發(fā)一套酒店內部管理系統(tǒng)，同時組員們獲得系統(tǒng)的軟件工程項目訓練，發(fā)布的產(chǎn)品 是軟件的可執(zhí)行程序、源代碼、技術文檔等，主要工作是需求分析、系統(tǒng)分析、開發(fā)測試。關鍵里程碑 分別是需求規(guī)格說明書的發(fā)布，系統(tǒng)設計說明說發(fā)布和系統(tǒng)的交付，項目所需資源為版本控制服務器和 個人開發(fā)工具，進度大約為 9 周。 1.2 項目交付的產(chǎn)品 交付日期 12 月 20 日，主要交付物有：酒店客房管理系統(tǒng)安裝程序、系統(tǒng)源代碼、技術文檔包（包 括需求規(guī)格說明書、系統(tǒng)設計說明書、項目總結文檔等） 1.3 SPMP 的演化 SPMP 于第 12 周周末前經(jīng)由小組討論分工撰寫匯總整合三步形成初稿，由組長上傳至配置文 檔庫，由組長負責維護。 第 13 周以后根據(jù)項目的進展可以對其進行修改需要有組員提出修改意見，在全體會議上討論通過， 并由組長將修改稿上傳至文檔庫。其余組員通過版本同步獲得更新稿。 1.4 參考資料 軟件工程理論、方法與實踐 ，孫家廣 劉強，高等教育出版社 軟件工程導論張海藩，清華大學出版社 軟件工程師指南M張凱，中國電力出版社 Java Web 典型模塊與項目實戰(zhàn)大全M明日科技，電子工業(yè)出版社. Java 數(shù)據(jù)庫系統(tǒng)開發(fā)案例精選M王國輝，人民郵電出版社 1.5 定義、縮寫詞以及簡寫 JDKFM：待開發(fā)的酒店客房管理系統(tǒng)軟件名稱 SPMP:軟件項目管理計劃 SRS：需求規(guī)格 2 項目組織 2.1 外部接口 組織聯(lián)系人聯(lián)系方式 指導老師謝明敏 其余組陳冬雪 -2- 2.2 內部組織結構 民主式組織結構，在這個結構中，小組成員完全平等，名義上的組長與其他成員沒有任何區(qū)別。大 家享有充分的民主，項目共作由全體人員討論協(xié)商決定，并根據(jù)每個人的經(jīng)驗和能力進行適當?shù)姆峙洹?充分激發(fā)大家的創(chuàng)造力，有利于攻克技術難關，雖然缺乏明確的權威領導，但是出現(xiàn)意見分歧時大家都 會盡量協(xié)商解決的。 2.3 角色與職責劃分 需求分析員 整理需求分析并以撰寫需求分析分析文檔，負責人員：謝明敏、陳冬雪 軟件設計員 負責軟件的設計并撰寫設計文檔，負責人員：夏喜鋒 開發(fā)人員 編寫軟件開發(fā)的代碼，負責人員：胡玉蓮，韓永亮 總結人員 負責最后的收尾工作并撰寫總結文檔，負責人員：張瑞剛 3 管理過程 3.1 項目啟動計劃 每位組員既是積極的建言者，又是負責的合作者。決策應在充分的討論基礎上做出，并被及時有效 的執(zhí)行。按時按量完成項目的基本功能，按時發(fā)布產(chǎn)品，遵循規(guī)范的項目運作標準，文檔嚴謹完整，代 碼注釋充分，便于后續(xù)維護。產(chǎn)品要運行穩(wěn)定，界面友好易上手，能很好的管理酒店客房信息。開發(fā)軟 件過程中要注重團隊建設，成員分工合理，合作默契，氣氛融洽。項目設計和開發(fā)商要有創(chuàng)新，更好的 吸引客戶。 3.2 工作計劃 第 11 周第 13 周：完成需求規(guī)格說明并撰寫需求規(guī)格說明 第 14 周：完成系統(tǒng)設計并撰寫軟件設計文檔 第 15 周第 16 周：完成編碼測試 第 17 周第 18 周：完成軟件交付并撰寫總結文檔 3.3 控制計劃 各開發(fā)過程負責人以周為單位記錄工作進展，形成電子文檔報告，上傳至文檔庫。負責人在每周項 目例會作口頭總結，小組會議審核通過給出意見，報告修改后上傳至文檔庫。各風險負責人密切監(jiān)控風 險狀態(tài)，定期提交風險報告。必要時將突發(fā)情況郵件列表通知所有組員，并由組長做出臨時處理決定。 每周例會上小組討論形成一致意見后即為通過，相關負責人針對改進意見開展下一周工作，小組會議持 續(xù)評估其成效。每一項目階段結束之前（里程碑前后） ，組織一次階段評審會，評估整個階段的工作效率 和成果質量。盡量與項目例會合并，并邀請老師和助教參加評議。 -3- 3.4 風險管理計劃 風險標題可能性影響優(yōu)先級規(guī)避或減輕策略負責人預定完成日期 1開發(fā)技術不成熟80%災難的高提前制定好學習計劃； 降低設計難度 胡玉蓮 韓永亮 第 16 周前 2考研課程100%嚴重的中適量少給她分配任務； 開會討論錯開上課時間 胡玉蓮第 16 周前 3考公務員100%嚴重的高適量少給他們分配任務； 開會討論錯開上課時間 謝明敏 陳冬雪 第 13 周 4考銀行100%輕微的中適量少給她分配任務； 開會討論錯開上課時間 謝明敏 陳冬雪 第 13 周 5需求變更頻繁50%嚴重的中需求制定充分預見未來； 多于老師助教討論； 設計方案留有變更余地 謝明敏 陳冬雪 第 13 周 6缺乏設計人才80%嚴重的高組員深入學習相關知識； 尋求外援幫助 夏喜鋒第 14 周 風險的詳細描述如下： 風險一：開發(fā)技術不熟練 沒有組員能熟練運用 JAVA 語言編出程序，僅限于學過，可能導致開發(fā)進度受阻，代碼交流困難。 風險二：考研課程 組員胡玉蓮每天都有考研課要上，又臨近考試可能導致任務分配上的困難。 風險三：考公務員 組長謝明敏和組員陳冬雪每天有公務員培訓課，十一月二十四日有國家公務員考試，既要復習考試 又要完成任務，會導致任務進度變慢。 風險四：考銀行 組長謝明敏和組員陳冬雪參加了農(nóng)業(yè)銀行招聘和民生銀行招聘，預計十一月中上旬會去呼市參加考 試，可能沒辦法監(jiān)督項目正常進度，延緩任務完成時間。 風險五：需求變更頻繁 在設計開發(fā)過程中可能發(fā)現(xiàn)原有需求不容易轉化為設計稿，在測試體驗過程中可能發(fā)現(xiàn)游戲并不好 玩，這都會帶來需求的重新變更。這兩種情況，尤其后一種要盡量避免，以免帶來重復開發(fā)的浪費。 風險六：缺乏設計人才 設計對一個軟件來說很重要，但項目組內沒有這方面的人才，可能導致產(chǎn)品吸引力下降，界面開發(fā) 環(huán)節(jié)上耗費較多時間等。 -4- 3.5 項目收尾計劃 在開發(fā)階段結束后，開發(fā)人員之間會進行代碼走查，減少 bug，并在測試階段更新源代碼，測試人員 根據(jù)測試文檔驚醒軟件測試，提高軟件正確性。 最終交付酒店客房管理系統(tǒng)軟件。 4 計劃過程 4.1 過程模型 應用瀑布模型，軟件開發(fā)的各項活動嚴格按照線性的方式進行，當前活動接受上一活動的工作結果， 實施完成所需的工作內容。當前活動的工作結果需要進行驗證，如果驗證通過，則該結果作為下一項活 動的輸入，繼續(xù)進行下一項活動，否則返回進行修改。因此，這種模型強調文檔的作用，并要求每個階 段都有仔細驗證。 4.2 方法、工具和技術 本小組的團隊組織結構為主程序員式組織結構；編程語言為 java；采用面向對象的分析設計方法； 利用 UML 進行系統(tǒng)建模；統(tǒng)一文件命名、代碼版式、注釋等編碼規(guī)范；編碼人員進行代碼走查后再進 行代碼編譯；測試人員根據(jù)測試文檔進行單元測試；最后實現(xiàn)軟件的交付。 4.3 基礎設施 個人 PC，筆記本、實驗室專用 PC 機 5 支持過程 5.1 工作包 工作包工作包子工作包子工作包預期完成時間預期完成時間負責人負責人最終交付物最終交付物簡單描述說明簡單描述說明 需求初步描述第 11 周 需求規(guī)格說明 原型 第 11 周 需求規(guī)格說明 的進一步修改 第 12 周 需求分析 需求規(guī)格說明 的最終確認 第 13 周 謝明敏 陳冬雪 需求規(guī)格說明 采用組內交流 和與客戶（主 教老師和其他 同學扮演）訪 談的形式確認 需求規(guī)格說明 概要設計第 14 周 詳細設計第 14 周系統(tǒng)設計 系統(tǒng)設計模型 確定 第 14 周 夏喜鋒軟件設計文檔 可以根據(jù)需求 規(guī)格說明的局 部調整進行相 應改變 -5- 編碼開發(fā)第 15 周 編碼測試第 16 周編碼測試 編碼設計模型 確定 第 16 周 胡玉蓮 韓永亮源代碼 為了克服技術 不熟的缺陷， 建議在此之前 加強相關知識 的學習 系統(tǒng)交付第 17 周 軟件交付總結第 18 周 張瑞剛總結文檔負責最后的收 尾工作并撰寫 總結文檔 5.2 依賴關系 1） 組織團隊是完成軟件項目的前提，明確分工負責； 2） 配置管理貫穿于整個軟件開發(fā)和測試過程； 3） 需求分析是軟件項目進入開發(fā)階段的重要標志； 4） 系統(tǒng)設計是基于需求分析的基礎上，又是編碼的原理依據(jù)； 5） 編碼測試是軟件開發(fā)進展的重要過程； 6） 交付階段是軟件獲得客戶的認可，是軟件開發(fā)結束的標志。 5.3 資源需求 人員：小組軟件項目開發(fā)成員、客戶 支持軟件：O