1、【精品文檔】如有侵權，請聯系網站刪除，僅供學習與交流超市管理系統-軟件項目計劃說明書.精品文檔.軟 件 學 院超市管理系統項目計劃書 系（部、中心） 軟件學院 姓 名 朱發軍 學 號 201207082233 專 業 軟件工程 班 級 .net122班 課程名稱 軟件工程項目管理 設計題目名稱 超市管理系統軟件項目計劃書 起止時間 2015年4月25日2010年5月9日 成 績 指導教師簽名 劉風華 中原工學院軟件學院制目錄1.1編寫目的31.2背景31.3定義31.4參考資料31.5重要術語42項目進度計劃編制的背景概述52.1軟件生存期模型選擇與設計52.2項目團隊情況簡述62.3軟件估算

2、情況72.4項目范圍的信息分析與使用72.4.1軟件的工作任務分解結構（WBS）72.4.2基于項目背景的WBS的細化方案82.4.3重要的假設及其說明83實施計劃93.1進度計劃93.2基于進度計劃的成本核算113.3調整后的進度計劃123.4關于進度計劃的其他說明123.5關于其他計劃的說明124項目成果產品144.1軟件程序144.2軟件文檔144.3軟件服務144.4非移交的軟件產品144.5驗收標準145其他151.1 編寫目的此項目開發計劃書的編寫主要是為了給開發超市管理系統做主要的規劃和整合，在開發過程中起到引導作用，以及給使用者提供簡要的說明進度是對執行的活動和里程碑制定的工作

3、計劃日期表1.2 背景a.待開發的軟件系統的名稱: 超市管理系統b.本項目的任務提出者、開發者、用戶及實現該軟件的組織結構（企業）項目的任務提出者：XX超市高層領導本系統的開發者：YY軟件股份有限公司員工朱發軍本系統的用戶：XX超市的高層領導、部門經理及其員工。實現該軟件企業（YY軟件股份有限公司）的組織結構圖：（參考例圖）c.該軟件系統同其他系統或其他機構的基本的相互來往關系。與本系統有關的系統：無1.3 定義WBS :Work Breakdown Structure 任務分解結構。PMI: Project Management Institute 美國項目管理學會 ，成立于1969年一個國

4、際性組織，PDM :Precedence Diagramming Method 單代號網絡圖1.4 參考資料1 軟件項目管理案例教程（第一版），韓萬江 姜立新編著， 機械工業出版社，2009年4月2 軟件項目管理案例教程（第二版），韓萬江 姜立新編著， 機械工業出版社，2009年4月 3 軟件項目估計（第二版）, (美)CAPERS JONES 著，劉從越編譯，電子工業出版社，2008年3月4 軟件需求（第二版），（美）Karl E. wiegers 著，劉偉琴、劉洪濤譯，清華大學出版社，2007年9月1.5 重要術語1.WBS，Work Breakdown Structure，任務分解結構，

5、是面向可交付成果的對項目元素的分組，它組織并定義了整個項目的范圍。2.進度計劃,進度，就是工作計劃日期表3.質量計劃：主要的質量管理對象是針對項目過程中那些對最終產品起著重要的作用的中間產品：需求規格、設計說明書，源程序，測試計劃，測試結果等。2 項目進度計劃編制的背景概述2.1 軟件生存期模型選擇與設計1.選擇增量模型的原因：1）.瀑布模型要求嚴格線性的開發，每個階段開發活動結束后， 通過嚴格的階段性復審與確認，得到該階段的一致、 完整、 正確和無二義性的良好文檔資料，以“凍結”這些文檔資料， 作為該階段的結束標志，保持不變，作為下一階段活動的唯一基礎， 以每一步的正確性和完整性來保證最終系

6、統的質量。 但是大量的實踐并不是這種理想的線性開發序列，而是在開發過程中逐步完善的。而在增量開發過程：軟件描述、設計和實現活動被分散成一系列的增量，這些增量輪流被開發。先完成一個系統子集的開發，再按同樣的開發步驟增加功能 (系統子集),如此遞增下去直至滿足全部系統需求。要求系統的總體設計在初始子集設計階段就應做出設計。2）增量模型有如下優點：l 可以避免一次性投資太多帶來的風險，將主要的功能或者風險大的功能首先實現，然后逐步完善，保證投入的有效性。l 可以更快地開發出可以操作的系統。l 可以減少開發過程中用戶需求的變更。l 一些增量可能需要重新開發（如果早期開發的需求不穩定或者不完整）。3）增

7、量模型開發適合的項目：q 項目開始，明確了需求的大部分，但是需求可能會發生變化q 對于市場和用戶把握不是很準，需要逐步了解q 對于有龐大和復雜功能的系統進行功能改進，就需要一步一步實施的。我們開發的是酒店管理系統，分客房模塊、餐飲模塊、財務模塊、人力資源模塊。雖然大部分的需求已明確，但是部分需求可能會發生變化；對于用戶需逐步了解才能準確把握；對于復雜功能的系統進行功能改進，就需要一步一步實施的。同時系統具有可擴充性，若使用增量模型，可以保證系統的可擴充性。本項目具備增量模型的其他特點：項目的復雜程度中等；項目的風險較低；產品和文檔的使用率會很高。所以選擇增量式作為我們的開發模型。圖2-1 增量

8、式模型2.具體的設計為：圖2-2 詳細的增量模型2.2 項目團隊情況簡述表2-1 此項目團隊人員的介紹：職位人員項目經理：朱發軍需求分析員：朱發軍概要設計員：朱發軍詳細設計員：朱發軍編碼人員：朱發軍測試人員：朱發軍由于項目初期信息不是很充分，所以初期的項目計劃只存在一個計劃表格，相當于一個大計劃，簡單說明計劃的執行步驟，如表5所示。表2-2 項目初期計劃任 務完成時間負責人資 源備 注項目規劃2015-5-24朱發軍全體人員參與需求獲取2011-01-05同上開發人員，超市領導，部門經理，員工代表參與需求確定2011-01-13同上全體人員參與概要設計2011-02-03同上詳細設計2011-

9、03-04同上全體人員參與項目實施2011-11-17同上朱發軍參與有待細化項目集成、測試2012-01-11同上提交2012-02-07同上朱發軍參與2.3 軟件估算情況此軟件估算結果列表：表2-3 估算列表估算項估算結果功能點估算：該軟件的功能點總數約為20個進度估算：該軟件開發時間30天成本估算：總成本為3900元人員數估算：所需的人員為1個人2.4 項目范圍的信息分析與使用2.4.1 軟件的工作任務分解結構（WBS）表2-4 WBS 分解情況編號任務名稱任務內容定義備注1前臺銷售系統涉及到超市部門員工超市前臺銷售的功能1.1收銀管理收銀業務 1.1.1金額計算銷售金額計算 1.1.2打

10、印清單打印交易收據1.1.2會員卡支持會員卡打折功能1.2顧客信息錄入對顧客購物信息進行管理 1.2.1顧客退貨管理對顧客退貨進行有效統計2后臺管理系統涉及到超市部經理及部門員工的功能2.1人事管理涉及超市人事部部經理的功能模塊 2.1.1員工信息管理顯示員工工作等信息 2.1.2員工操作權限管理規定員工操作守則2.2銷售管理涉及超市銷售部部經理的功能模塊 2.2.1查詢銷售信息查看銷售人員工作成績 2.2.2生成銷售排行榜對銷售人員評優2.3進退貨管理涉及超市貨物購買負責人的功能模塊 3.2.1進貨信息系統查看進貨信息 3.2.2退貨信息系統查看退貨信息2.4庫存管理倉庫負責人功能模塊2.4

11、.1庫存信息管理查看商品庫存信息2.4.2庫存狀態警告對貨物存量進行分析警告2.4.2 基于項目背景的WBS的細化方案表2-5 WBS 細化方案項目階段各活動下的任務任務內容定義責任人需求分析階段1對各個子系統進行需求獲取用多種方式進行需求獲取朱發軍2對獲得的需求進行確認分階段的開需求評審會議同上概要設計階段1.各個系統的用例描述和圖各個系統總的用例，分用例和所有的用例解說同上2.各個系統的概念數據建模各個系統的E-R模型和UML模型同上3.概要設計評審分階段開概要評審會議同上詳細設計階段1. 各個系統對象關系建模各個系統的對象模型建立同上2. 各個系統分析類各個系統的分析類，界面類，控制類同

12、上3. 各個系統設計類設置所有類的屬性值，和方法頭同上4. 各個系統物理數據庫設計對所有關系進行物理數據庫同上5.詳細設計評審分階段開詳細評審會議同上編碼階段1.前臺銷售管理子系統編碼對前臺銷售子系統的分析類的方法進行編碼同上2.前臺銷售管理子系統集成對前臺銷售子系統所有模塊進行集成同上3.后臺管理子系統編碼對后臺管理子系統的分析類的方法進行編碼同上4.后臺管理子系統集成對后臺管理子系統所有模塊進行集成同上系統集成1.系統集成對各個子系統進行集成同上系統測試1.集成測試對各個子系統的集成進行測試同上2.環境測試對發布版本的環境進行測試同上提交1.編寫用戶使用手冊包括使用的方法同上2.提供給用戶

13、安裝程序主要是安裝向導同上用戶培訓1.給用戶進行初期進行系統應用的基本培訓同上2.4.3 重要的假設及其說明假設：1.超市領導，公司領導都比較重視。2.酒店里的領導，員工都比較積極主動配合。3.分配的功能點總數為20個，平均每人1個功能點4.每個人每個月人均生產率為1個功能點。3 實施計劃3.1 進度計劃此處用甘特圖或進度表格描述。1） 進度計劃：表3-1 進度計劃表任務名稱工 期開始時間結束時間資 源酒店管理系統30d2015-4-262012-5-26l 軟件項目規劃1 d2015-4-262010-12-24全體人員參與項目規劃1 d2010-12-62010-12-15全體人員參與計劃

14、評審1d2010-12-162010-12-24全體人員參與l 需求開發1d2010-12-272011-1-13全體人員參與用戶界面設計1d2010-12-272010-12-31全體人員參與用戶需求評審1d2011-1-32011-1-5全體人員參與修改需求、修改用戶界面12011-1-62011-1-10全體人員參與編寫需求規格說明書1d2011-1-112011-1-12全體人員參與需求驗證12011-1-132011-1-13全體人員參與l 概要設計12011-1-142011-2-3全體人員參與用例描述圖12011-1-142011-1-20全體人員參與概念數據建模12011-1-

15、212011-1-27全體人員參與概要設計評審12011-1-282011-2-3全體人員參與l 詳細設計12011-2-42011-3-4全體人員參與對象關系建模12011-2-42011-2-9全體人員參與分析類12011-2-102011-2-16全體人員參與設計類12011-2-172011-2-22全體人員參與物理數據庫設計12011-2-232011-3-1全體人員參與詳細設計評審12011-3-22011-3-4全體人員參與l 項目實施12011-3-72011-11-17全體人員參與前臺銷售管理子系統12011-3-72011-5-13全體人員參與顧客信息錄入功能-增量1120

16、11-3-72011-3-11全體人員參與顧客退貨管理12011-3-72011-3-9全體人員參與增量1評審12011-3-102011-3-11全體人員參與收銀-增量212011-3-142011-3-24全體人員參與交易金額計算12011-3-142011-3-16全體人員參與打印交易清單12011-3-172011-3-18全體人員參與會員卡打折12011-3-212011-3-22全體人員參與增量2評審12011-3-232011-3-24全體人員參與前臺銷售子系統集成12011-5-52011-5-13全體人員參與子系統集成測試12011-5-52011-5-9全體人員參與子環境測

17、試12011-5-102011-5-13全體人員參與后臺管理子系統12011-5-162011-7-13全體人員參與人事功能-增量112011-5-162011-6-16全體人員參與員工信息管理12011-5-162011-5-19全體人員參與員工操作權限管理12011-5-202011-5-25全體人員參與增量1評審12011-6-132011-6-16全體人員參與銷售管理功能-增量212011-6-172011-7-1全體人員參與查詢打印銷售信息12011-6-172011-6-23全體人員參與生成銷售排行旁12011-6-242011-6-28全體人員參與增量2評審12011-6-292

18、011-7-1全體人員參與進退貨管理-增量312011-7-142011-7-26全體人員參與進貨信息管理12011-7-142011-7-18全體人員參與退貨信息管理12011-7-192011-7-21全體人員參與增量3評審12011-7-222011-7-26全體人員參與庫存管理-增量412011-7-272011-8-8全體人員參與查詢庫存信息12011-7-272011-7-29全體人員參與庫存狀態自動警告12011-8-12011-8-3全體人員參與增量4評審12011-8-42011-8-8全體人員參與后臺管理子系統集成12011-11-82011-11-17全體人員參與子系統集

19、成測試12011-11-82011-11-14全體人員參與子環境測試12011-11-152011-11-17全體人員參與l 系統集成12011-11-182011-12-21全體人員參與系統集成12011-11-182011-12-21全體人員參與l 系統測試12011-12-222012-1-31全體人員參與系統測試12011-12-222012-1-11全體人員參與環境測試12012-1-122012-1-31全體人員參與l 提交12012-2-12012-2-7全體人員參與完成文檔12012-2-12012-2-3全體人員參與驗收、提交12012-2-62012-2-7全體人員參與備

20、注：安排的時間范圍已包含節假日2）項目進度圖圖3-1 進度計劃網絡圖3）項目進度計劃的甘特圖：圖3-2 進度計劃甘特圖4）項目甘特圖實施部分的計劃展開如下：圖3-3 實施部分的甘特圖5）里程碑高層領導可能更加關注里程碑的進展，所以需要一個里程碑的圖示，如下表所示。表3-2 里程碑表事件時間增量1收銀業務2011-03-11增量2顧客信息錄入2011-03-24增量3人事管理2011-04-06增量4銷售管理2011-04-19增量5進退貨管理2011-05-04增量6庫存管理2011-05-133.2 基于進度計劃的成本核算表3-3 基于進度計劃的成本核算表任務名稱開始時間結束時間比較基準酒店

21、管理系統2015-4-262015-5-26340，000l 軟件項目規劃2010-12-62010-12-2412，000項目規劃2010-12-62010-12-157，000計劃評審2010-12-162010-12-245，000l 需求開發2010-12-272011-1-1330，000用戶界面設計2010-12-272010-12-3110，000用戶需求評審2011-1-32011-1-59，000修改需求、修改用戶界面2011-1-62011-1-104，000編寫需求規格說明書2011-1-112011-1-123，000需求驗證2011-1-132011-1-134，00

22、0l 概要設計2011-1-142011-2-313，000用例描述圖2011-1-142011-1-204，000概念數據建模2011-1-212011-1-276，000概要設計評審2011-1-282011-2-33，000l 詳細設計2011-2-42011-3-440，000對象關系建模2011-2-42011-2-98，000分析類2011-2-102011-2-1611，000設計類2011-2-172011-2-2211，000物理數據庫設計2011-2-232011-3-16，000詳細設計評審2011-3-22011-3-44，000l 項目實施2011-3-72011-1

23、1-17210，000前臺銷售管理子系統2011-3-72011-5-1360，000收銀業務-增量12011-3-72011-3-1813，000顧客信息錄入-增量22011-3-212011-3-2510，000前臺銷售管理子系統集成2011-11-82011-11-175，000后臺管理子系統2011-5-162011-7-1350，000人事管理-增量12011-7-142011-7-2015，000銷售管理-增量22011-7-212011-8-311，000進退貨管理-增量32011-8-42011-8-1111，000庫存管理-增量42011-8-122011-8-3013，00

24、0后臺管理子系統集成2011-9-82011-9-215，000l 系統集成2011-11-182011-12-2115，000系統集成2011-11-182011-12-2115，000l 系統測試2011-12-222012-1-3115，000系統測試2011-12-222012-1-119，000環境測試2012-1-122012-1-316，000l 提交2012-2-12012-2-75，000完成文檔2012-2-12012-2-33，500驗收、提交2012-2-62012-2-71，500項目開發人員為1個人員。項目開發用到1個人月。預算總成本為340，000元（見上表），與

25、估算的成本333，900元基本持平（有一點差距）。這樣340，000元可以作為項目的成本控制參考。3.3 調整后的進度計劃逐項列出影響初始計劃的因素和調整的條目（包括影響項目成敗的關鍵問題、技術難點和風險），指出這些問題對項目的影響然后給出調整后的進度計劃。由于系統規模不是很大，開發團隊的人員對本系統也很熟悉，所以開發的過程中風險較小。所以進度計劃沒有太大的改動。3.4 關于進度計劃的其他說明1.本進度計劃是從按照交付日期倒推確定時間，然后安排計劃內容； 2.進度安排提交的日期并非是真實的交付日期，而是留有半個月左右的余量時間，以備變化。3.5 關于其他計劃的說明質量管理計劃、1.軟件質量是設

26、計出來的不是檢查出來的。所以質量管理的關鍵是預防重于檢查，事前計劃好質量，而不是事后檢查。2. 軟件質量計劃的主要內容為：針對項目過程中那些對最終產品起著重要的作用的中間產品：需求規格、設計說明書，源程序，測試計劃，測試結果等的管理。配置管理計劃1.管理的主要內容為：版本信息。2.管理的主要目標：軟件配置的完整性和可追溯性。項目跟蹤管理計劃1.基本原理：2.項目跟蹤的主要目的是：保證正確的人在正確的時候得到正確的信息。4 項目成果產品4.1 軟件程序程序名稱：酒店管理系統安裝程序所用的編程語言：Visual Basic 存儲程序的媒體形式: 移動硬盤本系統能夠完成用戶所提的基本功能需求和非功能

27、需求，安全性能比較高，且能同時容納2000人同時訪問服務器。4.2 軟件文檔驗收報告：客戶對產品的驗收情況的記錄用戶安裝手冊：指導用戶怎樣安裝產品用戶使用手冊：指導用戶怎樣使用本系統幫助：提供給用戶在使用過程中的參考4.3 軟件服務服務名稱服務的級別服務開始日期服務期限是否收費安裝培訓低軟件提交給用戶時1d不收系統維護高每年寒假開始2d視情況而定運行支持高軟件提交給用戶時1d不收4.4 非移交的軟件產品項目計劃質量保證計劃配置管理計劃項目范圍說明書概要設計說明書詳細設計說明書設計術語及規范源程序編碼規則測試計劃測試用例測試報告4.5 驗收標準1.驗收測試的對象：軟件包括程序、數據和文檔。2.驗

28、收測試要注意問題：（1）驗收測試始終要以雙方確認的需求規格說明和技術合同為準，確認各項需求是否得到滿足，各項合同條款是否得到貫徹執行。（2）驗收測試和單元測試、集成測試不同，它是以驗證軟件的正確性為主，而不是以發現軟件錯誤為主。（3）對驗收測試中發現的軟件錯誤要分級分類處理，直到通過驗收為止。（4）驗收測試中的用例設計要具有全面性、多維性、效率性，能以最少的時間在最大程度上確認軟件的功能和性能是否滿足要求。 3.驗收測試的目的是確認系統是否滿足產品需求規格說明和技術合同的相關規定。通過實施預定的測試計劃和測試執行活動確認軟件的功能需求、性能需求和文檔需求。安裝測試、功能測試、界面測試、性能測試、文檔測試、負載壓力測試、恢復測試、安全性測試、兼容性測試等。（1）安裝測試 ：安裝測試的目的在于驗證軟件能否在不同的配置情況下完成安裝，并確認能否正常運行。（2）功能測試 ：功能測試是驗收測試中的主要內容。功能測試要包含以下項目：單個模塊的查詢、增加、刪除、修改、保存等操作；數