《超市管理系統》項目管理文檔.doc
《《超市管理系統》項目管理文檔.doc》由會員分享,可在線閱讀,更多相關《《超市管理系統》項目管理文檔.doc(23頁珍藏版)》請在裝配圖網上搜索。
《超市管理系統》項目管理文檔 目 錄 一、引言 - 2 - 1.1項目目的 - 2 - 1.2范圍 - 2 - 1.3項目簡介 - 2 - 二、合同 - 2 - 三、項目生存期 - 3 - 四、系統需求 - 4 - 4.1 需求概述 - 4 - 4.2 系統要達到的目標 - 4 - 4.3系統整體結構 - 5 - 4.4 功能需求分析 - 5 - 4.5數據流圖和數據字典 - 6 - 4.5.1基本檔案模塊 - 6 - 4.5.2進貨管理模塊 - 8 - 4.5.3 庫存管理模塊 - 9 - 4.5.4銷售管理模塊 - 12 - 4.5.5資金管理模塊 - 13 - 4.5.6憑證管理模塊 - 14 - 五、項目任務分解 -16 - 5.1. WBS任務分解 - 16 - 5.2繪制WBS圖 - 17 - 六、項目估算 - 17 - 6.1項目估算方法 - 17 - 6.2項目估算步驟 - 18 - 七、項目進度 -19 - 7.1進度管理 - 19 - 7.2項目里程碑 - 21 - 八、 項目測試 - 21 - 8.1測試方法 - 21 - 8.2模塊測試 - 21 - 九、 項目配置管理 - 22 - 9.1組織及職責 - 22 - 9.2用戶及權限 - 22 - 十、 項目風險計劃 - 22 - 10.1項目風險 -23- 10.2管理實踐 - 23 - 一、引言 在我國超市已經成為零售業(yè)的一種重要形態(tài),加快了國民經濟的發(fā)展。隨著超市高速的崛起,其經營管理也變得愈加復雜,早期的售貨員站柜臺的形式早已不能滿足現有銷售業(yè)的發(fā)展,這樣就迫切地需要引入新的管理技術。超市形態(tài)具有種種優(yōu)點,但在目前狀況下,它仍存在零售業(yè)企業(yè)所共有的落后的一面,隨著超市形態(tài)的高速發(fā)展,其經營管理也變得愈加復雜,日常所需要處理的數據量也逐漸增大,商業(yè)運轉的中間環(huán)節(jié)也越來越多,原始的人工管理已無法應對這復雜的市場。為此,我選擇了超市管理系統設計題目,依靠現代化的計算機信息處理技術來管理超市,從而節(jié)省了大量的人力、物力,改善了員工的工作條件,減輕了勞動強度,并且能夠快速反映出商品的進、銷、存等狀況和各種反饋信息分析,使管理人員快速對市場的變化做出相應的決策,加快超市經營管理效率。 1.1項目目的 隨著超市的出現,超市管理系統也隨著出現,并且隨著超市的發(fā)展,超市管理系統的功能和性能也隨著發(fā)展。在早期的超市管理系統中,主要是對正在銷售的商品進行管理,在當前的超市管理系統中已不僅僅有該功能,還要加人超市相關的物流、庫存等相關操作功能。使用最少的人力,完成最大的銷售總額,一直是超市管理系統的目標。 1.2范圍 本文檔適用于《超市管理系統》這一軟件項目。 1.3項目簡介 1.3.1項目名稱 《超市管理系統》 1.3.2項目用戶 用戶是中小型超市戶。 2、 合同 項目名稱:超市管理系統 委 托 方(甲 方): 受 托 方(乙 方): 簽訂時間: 簽訂地點: 有效限: 經協商,甲方就超市管理系統技術項目委托乙方提供技術服務支持;根據《中華人民共和國合同法》有關技術合同的規(guī)定,經甲乙雙方協商,同意就以下條款共同信守執(zhí)行。 第一條:甲方委托乙方進行技術服務的內容如下: 1.技術服務的目標:為甲方提供運行《超市管理系統 》技術服務 2.技術服務的內容:(1)收銀業(yè)務 (2)顧客信息錄入 (3)人事管理 (4)銷售管理 (5)進退貨管理 (6)庫存管理。 3.技術服務的方式:以項目技術顧問的身份組織專業(yè)技術服務,有相關的人員助公司一周,出現問題電話應保持聯通,并且能在制定時間到達現場 。 第二條:乙方應按下列要求完成技術服務工作: 1.技術服務地點: 2.技術服務期限:從雙方簽訂合同起到項目正常運行止; 3.技術服務進度:根據項目實施的進度同步服務 ; 4.技術服務質量要求:保證提供的技術服務滿足項目的質量需要 ; 5.技術服務質量期限要求:合同期內專職技術服務,項目正常運行后長期提供技術咨詢 。 第3條 :合同簽定后3日內甲方支付乙方本合同咨詢費總金額50%的預付款,計人民幣圓整。乙方按照本合同約定如期完成項目并通過甲方評審通過后,甲方于五個工作日內付清余款,計人民幣圓整。 第四條:雙方確定以下列標準和方式對乙方的技術服務工作成果進行驗收: 1.乙方完成技術服務工作的形式: (1)提供項目可行性研究報告; (2)提供項目的設計文件; (3)提供項目實施的全程服務團隊; 2.技術服務工作成果的驗收標準 (1)提供項目可行性研究報告滿足項目要求; (2)提供項目設計文件符合相關規(guī)范要求; (3)提供的服務團隊專職工作 。 3.技術服務工作成果的驗收方法:按照完成項目的需求驗收。 4.驗收的時間和地點:根據項目的實施進度同步驗收,在項目籌備處。 第五條:雙方確定,按以下約定承擔各自的違約責任: 1.任一方違反本合同任意一條約定,應當付對方合同總額的10%的違約金。 2.甲方在合同履行期間,甲方要求終止或解除合同(非一方原因造成),應付合同總額的10%向乙方支付違約金。 3.若由于技術服務的方案缺陷或質量低劣引起返工,乙方必須完善技術服務工作直至滿足要求,負責甲方造成的時間和費用損失,可扣除合同總額的10%的違約金。 第6條 :本合同未盡事宜,由雙方協商解決。 三、項目生存期 根據該項目的特點并結合公司已有的軟件生存期模型定義,本項目生存期采用增量模型如圖所示。 軟件項目規(guī)劃 需求開發(fā) 系統測試 系統集成 項目實施 詳細設計 概要設計 提交 四、系統需求 4.1 需求概述 超市是一家大型商業(yè)零售企業(yè)。管理信息系統將使公司從系統一建立起,就以計算機收款機系統為工具,實現商品流轉的主流處理。系統的最終目標是在采用計算機通訊網絡技術和科學管理方法的基礎上結合國際國內的先進計算機管理經驗和教訓,建立一個覆蓋各級主要業(yè)務功能的人機協調的管理信息系統。實現以商品經營管理、人事勞資管理、商情信息管理等方面數據采集,傳遞、處理、 存欄、查詢輸出一體化,具有一定經濟活動分析能力的管理信息系統。及時、準確反映企業(yè)經濟活動狀態(tài),成為企業(yè)內各級管理人員的有力工具。支持他們進行科學化經營管理,使企業(yè)獲得良好的經濟效益和社會效益。 4.2 系統要達到的目標 現信息的同步,從而方便顧客購物,并且便于管理員、理貨員。進貨員對商品信息的掌握,及時補充商品,避免商品短缺問題。 4.3系統整體結構 超市管理系統 進貨管理系統 庫存管理系統 人事管理系統 銷售管理系統 供貨商信息管理 員工信息管理 銷售信息盤點 銷售信息維護 銷售信息盤點 銷售信息維護 銷售信息查詢 進貨信息維護 進貨信息查詢 整個超市管理系統的功能結構如圖4.1所示: 圖4.1系統整體結構 4.4 功能需求分析 根據對超市的業(yè)務流程分析和需求分析,定義了系統中的的主要模塊及其對應的功能描述: (1)員工信息錄入:對員工的基本信息進行添加、刪除、修改、查看 (2)供應商信息錄入:對供應商的基本信息進行添加、刪除、修改、查看 (3)員工信息查詢:查詢員工信息 (4)供應商信息查詢:查詢供應商信息 (5)進貨信息錄入:對進貨信息進行添加、刪除、修改、查看 (6)進貨信息查詢:查詢進貨信息 (7)付款信息錄入:對付款業(yè)務跟蹤記錄,添加、刪除、修改、查看付款信息 (8)入庫單登記:跟蹤記錄入庫單,添加、刪除、修改、查看入庫單信息 (9)入庫信息錄入:對商品入庫信息進行添加、刪除、修改、查看 (10)出庫單登記:跟蹤記錄出庫單,添加、刪除、修改、查看入庫單信息 (11)出庫信息錄入:對商品出庫信息進行添加、刪除、修改、查看 (12)退貨入庫單登記:跟蹤記錄退貨入庫單,添加、刪除、修改、查看入庫單信 息 (13)退貨入庫信息錄入:對退貨入庫信息進行添加、刪除、修改、查看 (14)報損信息錄入:對商品報損信息進行添加、刪除、修改、查看 (15)報損情況統計:統計報損情況 (16)庫存查詢:按商品分類等查詢庫存,設置報警數量,執(zhí)行庫存報警 (17)銷售單登記:跟蹤記錄銷售單,添加、刪除、修改、查看銷售單信息 (18)銷售信息錄入:對銷售信息進行添加、刪除、修改、查看 (19)銷售情況統計:按日期統計銷售情況 (21)銷售信息查詢:查詢銷售信息 (22)登記收款單:跟蹤記錄收款單,添加、刪除、修改、查看收款單信息 (23)登記付款單:跟蹤記錄付款單,添加、刪除、修改、查看收款單信息 (24)收款統計:按日期統計收款金額 (25)付款統計:按日期統計付款金額 (26)付款憑證填制:跟蹤記錄原始憑證,添加、刪除、修改、查看憑證信息 (27)收款憑證填制:跟蹤記錄原始憑證,添加、刪除、修改、查看憑證信息 (28)記賬憑證查詢:查詢憑證信息 (29)數據管理模塊:數據庫備份 (30)系統設置模塊:密碼修改,退出 4.5數據流圖和數據字典 本節(jié)主要介紹將整個系統的數據流自頂向下逐步分解成各個功能模塊的數據流圖。 4.5.1基本檔案模塊數據流圖和數據字典 ⑴數據流圖 管理員 員工信息表 員工信息錄入 供應商信息表 供應商信息錄入 員工信息表 員工信息查詢 供應商信息查詢 員工信息表 添加、刪除、 修改操作 添加、刪除、 修改操作 查詢操作 查詢操作 圖4.2 ⑵數據字典 ①主要數據流條目說明: 員工基本信息單=姓名+性別+出生日期+聯系電話+住址 員工信息={員工基本信息}+所在部門+職位+超市就職起始日期 供應商信息=姓名+性別+地址+聯系電話+傳真+備注 ②處理描述: 表 1-1描述說明處理1.2.1 加工名稱 員工信息錄入 輸入: 員工信息 處理: 添加員工信息到員工信息表中,從員工信息表中修改或者刪除對應員工信息記錄 輸出: 員工信息 表1-2描述說明處理1.2.2 加工名稱 供應商信息錄入 輸入: 供應商信息 處理: 添加供應商信息到供應商信息表中,從供應商信息表中修改或者刪除對應供應商信息記錄 輸出: 供應商信息 表 1-3描述說明處理1.2.3 加工名稱 員工信息查詢 輸入: 員工的姓名或者員工超市就職起始日期 處理: 根據查詢條件,查詢出對應員工信息記錄 輸出: 員工信息記錄 表 2-4 描述說明處理1.2.4 加工名稱 供應商信息查詢 輸入: 供應商名稱 處理: 根據查詢條件,查詢出對應供應商信息記錄 輸出: 供應商信息 4.5.2進貨管理模塊數據流圖和數據字典 ⑴數據流圖 進貨信息表 付款信息表 進貨信息錄入 進貨管理員 付款信息錄入 進貨信息表 進貨信息查詢 添加、刪除、 添加、刪除、 修改操作 修改操作 查詢操作 圖4.3 ⑵數據字典 ①主要數據流條目說明: 進貨信息=進貨編號+商品名稱+進貨數量+數量單位+進貨員+供應商信息+應付金額 付款信息=付款單單號+付款日期+供應商+付款方+付款方式+應付金額+實付金額 ②處理描述: 表1-5 描述說明處理 1.2.5 加工名稱 進貨信息錄入 輸入: 貨信息記錄 處理: 添加進貨信息到進貨信息表中,從進貨信息表中修改或者刪除對應進貨信息記錄 輸出: 所有進貨記錄 表 1-6 描述說明處理1.2.6 加工名稱 付款信息錄入 輸入: 付款信息記錄 處理: 添加付款信息到付款信息表中,從付款信息表中修改或者刪除對應付款信息記錄 輸出: 所有付款記錄 表 1-7 描述說明處理1.2.7 加工名稱 進貨信息查詢 輸入: 進貨編號、商品名稱、進貨員 處理: 按條件查詢出對應進貨信息記錄 輸出: 進貨信息記錄 4.5.3庫存管理模塊數據流圖和數據字典 ⑴數據流圖 圖4.4 ⑵數據字典 ①主要數據流條目說明: 入庫單=入庫單單號+入庫單日期+入庫人+復核人+庫管員 入庫信息=入庫單單號+商品名稱,型號+數量,數量單位+存放倉庫+入庫人+庫管員+入庫日期 出庫單=出庫單單號+出庫單日期+提貨人+庫管員 出庫信息=出庫單單號+商品名稱+型號+數量+數量單位+存放倉庫+提貨人+庫管員+ 出庫日期 退貨入庫單=退貨入庫單單號+退貨入庫日期+入庫人+庫管員 退貨入庫信息=退貨入庫單單號+商品名稱+型號+數量+數量單位+存放倉庫+入庫人+管員+入庫日期 報損信息=報損日期+商品名稱+型號+數量,數量單位+存放倉庫+報損人+報損描述 報損統計情況=月份+商品名稱+型號+數量單位+總數量 庫存信息=商品名稱+型號+現存數量+存放倉庫+庫管員+數量單位+入庫總數量+出庫總數量+警報下限+警報標志 ②處理描述: 表 1-8 描述說明處理1.2.8 加工名稱 入庫單登記 輸入: 入庫單信息 處理: 添加入庫單信息到入庫單登記表中,從入庫單登記表中修改或者刪除對應入庫單信息記錄 輸出: 入庫單信息記錄 表1-9描述說明處理1.2.9 加工名稱 入庫信息錄入 輸入: 入庫信息 處理: 1)添加入庫信息到入庫信息表中,從入庫信息表中修改或者刪除對應入庫信息記錄 2)入庫確認后,庫存信息做相應更改 輸出: 入庫信息記錄 表 1-10描述說明處理1.2.10 加工名稱 出庫單登記 輸入: 出庫單信息 處理: 添加出庫單信息到出庫單登記表中,從出庫單登記表中修改或者刪除對應出庫單信息記錄 輸出: 出庫單信息記錄 表 1-11 描述說明處理1.2.11 加工名稱 出庫信息錄入 輸入: 出庫信息 處理: 1)添加出庫信息到出庫信息表中,從出庫信息表中修改或者刪除對應出庫信息記錄 2)出庫確認后,庫存信息做相應更改 輸出: 出庫信息記錄 表1-12 描述說明處理 1.2.12 加工名稱 報損信息錄入 輸入: 報損信息 處理: 1)添加報損信息到報損信息表中,從報損信息表中修改或者刪除對應報損信息記錄 2)報損信息確認后,庫存信息做相應更改 輸出: 報損信息記錄 表1-13 描述說明處理 1.2.13 加工名稱 報損信息統計 輸入: 報損信息記錄 處理: 按日期統計報損信息 輸出: 報損統計記錄 表1-14 描述說明處理 1.2.14 加工名稱 退貨入庫單登記 輸入: 退貨入庫單信息 處理: 添加退貨入庫單信息到退貨入庫單登記表中,從退貨入庫單登記表中修改或者刪除對應退貨入庫單信息記錄 輸出: 退貨入庫單信息記錄 表2-15 描述說明處理 1.2.15 加工名稱 退貨入庫信息錄入 輸入: 退貨入庫信息 處理: 1)添加退貨入庫信息到退貨入庫信息表中,從退貨入庫信息表中修改或者刪除對應退貨入庫信息記錄 2) 退貨入庫信息確認后,庫存信息做相應更改 輸出: 退火入庫信息記錄 表2-16 描述說明處理 1.2.16 加工名稱 庫存信息查詢 輸入: 查詢條件,庫存下限 處理: 按查詢條件查詢出對應庫存信息記錄,修改對應商品庫存記錄中的庫存下限,庫存不足是發(fā)出警報 輸出: 對應庫存信息記錄,發(fā)出警報的庫存信息記錄 4.5.4 銷售管理模塊數據流圖和數據字典 ⑴數據流圖 銷售單登記表 銷售信息表 銷售統計表 銷售管理員 銷售單登記 銷售信息錄入 銷售信息查詢 銷售情況統計 銷售信息表 添刪改 添刪改 查詢 統計 圖4.5 ⑵數據字典 ①主要數據流條目說明: 銷售單信息=銷售單單號+銷售單日期+銷售員+銷售金額 銷售信息=銷售單單號,銷售編號,商品名稱,型號,銷售數量,數量單位,銷售單價,銷售時間,銷售員工,應付金額,實付金額 銷售統計信息=商品名稱,型號,銷售日期,總銷售數量,數量單位,總銷售金額) ②處理描述: 處理描述表1-17 加工名稱 銷售單登記 輸入: 銷售單信息 處理: 添加銷售單信息到銷售單登記表中,從銷售單登記表中修改或者刪除對應銷售單信息記錄 輸出: 銷售單信息記錄 處理描述表 1-18 加工名稱 銷售信息錄入 輸入: 銷售信息 處理: 添加銷售信息到銷售信息表中,從銷售信息表中修改或者刪除對應銷售信息記錄 輸出: 銷售信息記錄 處理描述表 1-19 加工名稱 銷售信息查詢 輸入: 查詢條件 處理: 按查詢條件,查詢出對應銷售信息記錄 輸出: 對應銷售信息記錄 處理描述表 1-20 加工名稱 銷售情況統計 輸入: 日期 處理: 按日期統計銷售信息,將統計情況添加到銷售統計表 輸出: 銷售統計記錄 4.5.5 資金管理模塊數據流圖和數據字典 ⑴數據流圖 收款單登記表 付款單登記表 收款統計表 付款統計表 登記收款單 登記付款單 收款統計 付款統計 管理員 添刪改 添刪改 付款統計 收款統計 圖4.6 ⑵數據字典 ①主要數據條目說明: 收款單信息=收款單單號+收款方式+收款日期+收款金額 付款單信息=付款單單號+付款方式+付款日期+付款金額 收款統計信息=日期+總金額+收款方式 付款統計信息=日期+總金額+收款方式 ②處理描述: 處理描述表 1-21 加工名稱 登記收款單 輸入: 收款單信息 處理: 添加收款單信息到收款單登記表中,從收款單登記表中修改或者刪除對收款單信息記錄 輸出: 收款單信息記錄 處理描述表 1-22 加工名稱 登記付款單 輸入: 付款單信息 處理: 添加付款單信息到付款單登記表中,從付款單登記表中修改或者刪除對付款單信息記錄 輸出: 付款單信息記錄 處理描述表 1-23 加工名稱 付款統計 輸入: 日期 處理: 按日期統計付款信息,將統計情況添加到付款統計表 輸出: 付款統計記錄 處理描述表 1-24 加工名稱 收款統計 輸入: 日期 處理: 按日期統計收款信息,將統計情況添加到收款統計表 輸出: 收款統計記錄 4.5.6 憑證管理模塊數據流圖和數據字典 ⑴數據流圖 付款記賬憑證表 收款記賬憑證表 付款憑證填制 收款憑證填制 憑證查詢 付款記賬憑證表 收款記賬憑證表 財務管理人員 添刪改 添刪改 查詢 圖4.7 ⑵數據字典 ①主要數據流條目說明: 付款憑證信息=憑證編號+貸方科目+日期+附件類型+附件張數+摘要+一級科目+二 級科目+金額+財務主管+記賬+出納+復+制單 收款憑證信息=憑證編號+貸方科目+日期+附件類型+附件張數+摘要+一級科目+二 級科目+金額+財務主管+記賬+出納+復核+制單 ②處理描述: 處理描述表 1-25 加工名稱 付款憑證填制 輸入: 原始單據信息 處理: 添加原始單據信息到付款記賬憑證表中,從付款記賬憑證表中修改或者刪除對應付款記賬憑證信息記錄 輸出: 付款記賬憑證信息記錄 處理描述表 1-26 加工名稱 收款憑證填制 輸入: 原始單據信息 處理: 添加原始單據信息到收款記賬憑證表中,從收款記賬憑證表中修改或者刪除對應收款記賬憑證信息記錄 輸出: 收款記賬憑證信息記錄 處理描述表 1-27 加工名稱 憑證查詢 輸入: 查詢條件(憑證類型,憑證編號) 處理: 按查詢條件,查詢出相應類型和編號的憑證信息記錄 輸出: 憑證信息記錄 五、項目任務分解 5.1. WBS任務分解 基于項目背景的WBS的細化方案.如表1 表1.WBS 細化方案 項目階段 各活動下的任務 任務內容定義 需求分析階段 1.對各個子系統進行需求獲取 用多種方式進行需求獲取 2.對獲得的需求進行確認 分階段的開需求評審會議 概要設計階段 1.各個系統的用例描述和圖 各個系統總的用例,分用例和所有的用例解說 2.各個系統的概念數據建模 各個系統的E-R模型和UML模型 3.概要設計評審 分階段開概要評審會議 詳細設計階段 1. 各個系統對象關系建模 各個系統的對象模型建立 2. 各個系統分析類 各個系統的分析類,界面類,控制類 3. 各個系統設計類 設置所有類的屬性值,和方法頭 4. 各個系統物理數據庫設計 對所有關系進行物理數據庫 5.詳細設計評審 分階段開詳細評審會議 編碼階段 1.前臺銷售管理子系統編碼 對前臺銷售子系統的分析類的方法進行編碼 2.前臺銷售管理子系統集成 對前臺銷售子系統所有模塊進行集成 3.后臺管理子系統編碼 對后臺管理子系統的分析類的方法進行編碼 4.后臺管理子系統集成 對后臺管理子系統所有模塊進行集成 系統集成 1.系統集成 對各個子系統進行集成 系統測試系統集成 1.集成測試 對各個子系統的集成進行測試 2.環(huán)境測試 對發(fā)布版本的環(huán)境進行測試 提交 1.編寫用戶使用手冊 包括使用的方法 2.提供給用戶安裝程序 主要是安裝向導 用戶培訓 1.給用戶進行 初期進行系統應用的基本培訓 5.2繪制wbs 圖 圖5.2wbs圖 六、項目估算 6.1項目估算方法 估算是循序漸進的過程,隨著項目的不斷發(fā)展,估算可以重復多次進行的,而且是逐步精確的。本項目采用自下而上和參數法綜合的估算方法,具體過程如下: 1. 簽訂合同前 開始簽訂合同的時候,根據以往類似項目的經驗,采用類比估算方法,進行粗略的估算:根據用戶的要求采用B/S結構,公司JSP+SQLServer的技術比較成熟,以前成功完成過類似的項目,根據SOW的說明,基本上需要2-3個開發(fā)人員,2個月左右的開發(fā)時間,基本上是4-6人月的規(guī)模,所以,10-15萬可以作為合同的參考價格。 2.合同簽署后 合同簽署之后,根據現有的資源和WBS分解的結果,進一步細化估算,由于WBS分解是針對項目的功能進行的分解,在成本估算的時候,首先估算每個任務的開發(fā)規(guī)模,然后在通過系數獲得相應的質量、管理任務的規(guī)模,從而計算直接成本,然后計算間接成本,以及總成本,具體過程如表4.1所示。 注:規(guī)模單位為人/天 表6.1 合同簽署 階段 WBS 名稱 估計值(人天) 小計(人天) 總計(人天) 需求分析階段 1 前臺管理系統 42 84 1.1 收銀 5 1.1.1 金額計算 8 1.1.2 打印清單 6 1.1.3 會員卡 7 1.2 顧客信息錄入 7 1.2.1 顧客退貨管理 9 概要設計階段 2 后臺管理系統 22 2.1 人事管理 5 2.1.1 員工信息管理 9 2.1.2 員工操作權限管理 8 詳細設計階段 2.2 銷售管理 12 2.2.1 查詢銷售信息 3 2.2.2 生成銷售排行榜 9 系統集成 2.3 進退貨管理 15 2.3.1 進貨信息系統 7 系統測試 2.3.2 退貨信息系統 8 提交 2.4 庫存管理 13 2.4.1 庫存信息管理 6 2.4.2 庫存狀態(tài)警告 7 6.2項目估算步驟 1.獲取項目分解結果WBS ①任務分解是根據項目的功能進行分解的, 2.計算開發(fā)成本 ①由于任務分解的結果主要是針對開發(fā)任務的分解,管理任務和質量任務可以通過計算開發(fā)任務得到,根據以往經驗,管理任務和質量任務=20%*開發(fā)任務。 ②從表6-3得知項目規(guī)模是84人天,開發(fā)人員成本參數=480元/天,則內部的開發(fā)成本=480元/天*84天=40320元, ③加上外包外購的部分軟件成本5000+3000+3000=11000元,則開發(fā)成本=40320+11000=51320元。 3.計算管理、質量成本 ①項目的管理和質量成本=開發(fā)成本*20%=10264元, 4.直接成本=51320+10264=61584元, 5.計算間接成本 ①間接成本包括前期合同費用、房祖水電、培訓、員工福利、客戶服務等, ②根據以往經驗,采用公式:間接成本=25%直接成本=15396元, 6.計算總估算成本 ①項目總估算成本=61584+15396=76980元。 7.重新評估項目的報價 ①重新評估一下項目的報價準確性,當然這時候,項目的合同已經簽署了,報價是不能更改的,但是通過再次的評估可以進一步明確企業(yè)的項目運作和利潤情況等, ②如果項目的利潤是30%,其中風險基金10%,利潤15%,稅費5%。則項目的總報價=76980*1.3=100074元,,應該說報價還是比較合適的。 另外,可以采用簡便的算法進行估算,企業(yè)的報價可以通過開發(fā)規(guī)模的估算直接得出,例如如果成本系數為5000元/人月,一個人月28人天,則項目報價=5000*84/28=15000元。 七、 項目進度 7.1進度管理 此處用甘特圖或進度表格描述。 1 進度計劃: ① 本進度計劃是從按照交付日期倒推確定時間,然后安排計劃內容; ② 進度安排提交的日期并非是真實的交付日期,而是留有半個月左右的余量時間,以備變化。如表7.1所示。 表7.1 進度管理 任務名稱 工 期 開始時間 結束時間 資 源 超市管理系統 2016-10-13 2017-1-1 l 軟件項目規(guī)劃 2 2016-10-13 2016-10-14 全體人員參與 —項目規(guī)劃 1 2016-10-13 2016-10-13 全體人員參與 —計劃評審 1 2016-10-14 2016-10-14 全體人員參與 l 需求開發(fā) 9 2016-10-15 2016-10-27 全體人員參與 —用戶界面設計 2 2016-10-15 2016-10-16 全體人員參與 —用戶需求評審 1 2016-10-19 2016-10-19 全體人員參與 —修改需求、修改用戶界面 3 2016-10-20 2016-10-22 全體人員參與 —編寫需求規(guī)格說明書 2 2016-10-23 2016-10-26 全體人員參與 —需求驗證 1 2016-10-27 2016-10-27 全體人員參與 l 概要設計 66 2016-10-28 2016-11-4 全體人員參與 —用例描述圖 2 2016-10-28 2016-10-29 全體人員參與 —概念數據建模 2 2016-10-30 2016-10-31 全體人員參與 —概要設計評審 2 2016-11-3 2016-11-4 全體人員參與 l 詳細設計 9 2016-11-5 2016-11-17 全體人員參與 —對象關系建模 3 2016-11-5 2016-11-9 全體人員參與 —分析類 2 2016-11-10 2016-11-11 全體人員參與 —設計類 1 2016-11-12 2016-11-12 全體人員參與 —物理數據庫設計 2 2016-11-13 2016-11-16 全體人員參與 —詳細設計評審 1 2016-11-17 2016-11-17 全體人員參與 l 項目實施 24 2016-11-24 2016-12-25 全體人員參與 —前臺銷售管理子系統 9 2016-11-24 2016-12-4 全體人員參與 —顧客信息錄入功能 2 2016-11-24 2016-1-25 全體人員參與 ——顧客退貨管理 1 2016-11-24 2016-11-24 全體人員參與 ——顧客信息錄入功能評審 1 2016-11-25 2016-11-25 全體人員參與 —收銀 5 2016-11-26 2016-12-2 全體人員參與 ——交易金額計算 1 2016-11-26 2016-11-26 全體人員參與 ——打印交易清單 1 2016-11-27 2016-11-27 全體人員參與 ——會員卡打折 2 2016-3-21 2016-3-22 全體人員參與 ——收銀評審 1 2016-11-2 2016-11-2 全體人員參與 —前臺銷售子系統集成 2 2016-13-3 2016-12-4 全體人員參與 ——子系統集成測試 1 2016-13-3 2016-13-3 全體人員參與 ——子環(huán)境測試 1 2016-13-4 2016-13-4 全體人員參與 —后臺管理子系統 15 2016-12-7 2016-12-25 全體人員參與 —人事功能 3 2016-12-7 2016-12-9 全體人員參與 ——員工信息管理 1 2016-12-7 2016-12-7 全體人員參與 ——員工操作權限管理 1 2016-12-8 2016-12-8 全體人員參與 ——人事功能評審 1 2016-12-9 2016-12-9 全體人員參與 —銷售管理功能 3 2016-12-10 2016-12-14 全體人員參與 ——查詢打印銷售信息 1 2016-12-10 2016-12-10 全體人員參與 ——生成銷售排行旁 1 2016-12-11 2016-12-11 全體人員參與 銷售管理功能評審 1 2016-12-14 2016-12-14 全體人員參與 —進退貨管理 3 2016-12-15 2016-12-17 全體人員參與 ——進貨信息管理 1 2016-12-15 2016-12-15 全體人員參與 ——退貨信息管理 1 2016-12-16 2016-12-16 全體人員參與 ——進退貨管理評審 1 2016-12-17 2016-12-17 全體人員參與 —庫存管理 3 2016-12-18 2016-12-22 全體人員參與 ——查詢庫存信息 1 2016-12-18 2016-12-18 全體人員參與 ——庫存狀態(tài)自動警告 1 2016-12-21 2016-12-21 全體人員參與 ——庫存管理評審 1 2016-12-22 2016-12-22 全體人員參與 —后臺管理子系統集成 3 2016-12-23 2016-12-25 全體人員參與 子系統集成測試 2 2016-12-23 2016-12-24 全體人員參與 子環(huán)境測試 1 2016-12-25 2016-12-25 全體人員參與 l 系統集成 1 2016-12-28 2016-12-28 全體人員參與 ——系統集成 1 2016-12-28 2016-12-28 全體人員參與 l 系統測試 2 2016-12-29 2016-12-30 全體人員參與 ——系統測試 1 2016-12-29 2016-12-29 全體人員參與 ——環(huán)境測試 1 2016-12-30 2016-12-30 全體人員參與 l 提交 2 2016-12-31 2017-1-1 全體人員參與 ——完成文檔 1 2016-12-31 2016-12-31 全體人員參與 ——驗收、提交 1 2016-1-1 2017-1-1 全體人員參與 7.2項目里程碑 8、 測試計劃 完成對流程的編碼后最重要的事情就是對系統的測試工作了,測試在系統設計階段有兩個時期,通常在編寫每個模塊后做單元測試,另一個時期是對系統的綜合測試。 8.1測試方法 測試任何產品都有兩種方法:如果已經知道了產品應該具有的功能,可以通過測試來檢驗是否每個功能都能正常使用;如果知道產品內部工作過程,可以通過測試來檢驗產品內部動作是否按照規(guī)格說明書的規(guī)定正常進行。前一個方法稱為黑盒測試,后一個方法稱為白盒測試。 8.2模塊測試 1)進/退貨管理模塊測試 對進貨、退貨管理模塊測試,內容包括對進貨、退貨信息輸入進行正確性和合法性的測試,對添加、刪除、修改操作導致數據庫的改變進行正確性和合法性的測試,對查詢進貨、退貨信息結果進行正確性測試,對進貨總金額盤點進行核對測試。 (2)銷售管理模塊測試 對銷售管理模塊測試,內容包括對購買時判斷庫存商品是否足夠的測試,對文本框輸入數據是否合法進行測試,對按商品編號、名稱查詢庫存商品的結果測試,對購買列表顯示是否正確進行測試,對商品價格結算是否正確進行測試,對判斷收款金額是否足夠進行測試,對完成銷售時找零數目進行測試,對完成銷售后的銷售信息盤點進行測試,對銷售排行榜的正確性進行測試。 (3)庫存管理模塊測試 對庫存管理模塊測試,內容包括對查詢庫存商品的不同查詢方式對應的不同查詢結果的測試,對修改庫存商品信息文本框所輸入的新信息的合法性、正確性進行測試,對提交修改信息后庫存信息是否改變進行測試,對庫存商品總值盤點的結果核對是否正確的測試。 (4)人事管理模塊測試 對人事管理模塊測試,內容包括對查詢員工信息/供應商信息的不同查詢方式對應的不同查詢結果的測試,對修改員工信息/供應商信息文本框所輸入的新信息的合法性、正確性進行測試,對提交修改信息是否成功的測試。 (5)系統管理模塊測試 對系統管理模塊測試,內容包括對添加、修改、刪除用戶操作的正確性、合法性的測試,對重置數據信息是否成功進行測試,對備份/還原數據庫的功能進行測試。 (6)測試結果 所有模塊經過測試都可以實現其基本的功能,響應時間都在系統要求的范圍內,存在的部分bug,已經修正。 九、 項目配置管理 9.1組織及職責 (1)根據《項目計劃》中的角色分配,確定配置管理者,SCCB(配置控制委員會)成員。 (2)項目經理是SCCB的負責人。 (3)配置管理的角色和職責見表9.1所示。 表9.1 配置管理角色職責表 角色 人員 職責、工作范圍 配置管理者 A (1)制定《配置管理計劃》 (2)創(chuàng)建和維護配置庫 SCC負責人 B (1)審批《配置管理計劃》 (2)審批重大的變更 SCCB成員 質量保證人員-C 配置管理者-D 審批某些配置項或基線的變更 9.2用戶及權限 用戶及權限具體如表9.2所示。 表9.2 配置庫的用戶權限 類別 人員 權限說明 配置管理者 A 負責項目配置管理,對庫擁有所有權限 項目管理 B 訪問、讀 質量保證人員 C 訪問、讀 開發(fā)人員 D 訪問、讀 高層管理 E 訪問、讀 十、 項目風險計劃 10.1項目風險 項目風險具體如表8.1所示。 表8.1 項目風險 序號 風險識別 風險評估 風險應對措施 潛在的風險事件 風險發(fā)生的后果 可能性 影響 風險值 應對措施 預防措施 1 需求不明確:需求小組沒有真正理解客戶需求 客戶不接受產品或拒絕付款 70% 50% 35% 派遣經驗豐富的需求分析師與客戶進行深入的交流,明確客戶的主要需求,引導客戶對項目做出正確的描述。 事先進行需求評審 2 項目范圍定義不明確 項目沒完沒了 40% 50% 15% 要求需求小組按照客戶的要求變更項目范圍。 需求要在事先定義清楚并獲得客戶的確認。 3 項目目標不明確 導致項目進度拖期或成本超支。 30% 50% 10% 修改項目目標。 事先明確項目目標 4 需求小組對客戶業(yè)務了解不夠 軟件不能實現業(yè)務功能 70% 60% 20% 修改軟件 加強與了解并讓客戶參與 5 需求不斷變化 項目變得沒完沒了 50% 40% 10% 提交CCB討論、決定 建立范圍變更程序 6 任務定義不夠充分 項目不能按時、按預算完成 20% 30% 15% 重新定義 事先與客戶達成共識 7 程序員對系統設計的理解上出現偏差 軟件實現不了設計的功能,客戶拒絕接受 60% 50% 5% 修改代碼 進行設計評審 8 客戶要求增加功能 項目進度拖期、成本超支 80% 50% 10% 修改程序 事先確定范圍目標 9 客戶突然要求增加功能 項目進度拖期、成本超支 70% 15% 15% 作出相應修改 事先確定項目范圍和功能要求 10 出現故障,用戶維護人員解決不了 客戶投訴 15% 10% 20% 派技術人員幫助解決 事先培訓客戶系統維護人員 10.2管理實踐 1.人力資源風險的應對措施 ①和有關資源部門充分溝通,達成共識,建立人員的穩(wěn)定和釋放機制,在開發(fā)周期內保持人員的相對穩(wěn)定,資源線調動資源需要和產品部協調,并將此作為產品線考核資源線的一個指標。 ②針對人員缺乏經驗,需要進行系列的培訓組織,保證項目開發(fā)人員及時了解產品知識。工作交接規(guī)范化,保證產品開發(fā)不會因為人員變動受到大的沖擊。 ③ 對項目組進行良好組織,使得每一個開發(fā)活動的信息能被廣泛傳播和交流。 ④ 對所有工作進行詳細復審,避免只有一個人熟悉該項工作情況出現。 ⑤對于每一個關鍵技術崗位都指定一個后備人員 2.對于需求變動的緩解措施 ①在進行需求分析時和市場人員甚至用戶進行充分溝通。 ②定出基線進行詳細評審。 ③ 周知版本計劃,并用市場銷售指導書指導市場人員簽單時注意公司產品的規(guī)格,引導用戶 ④ 嚴格控制需求的變更,建立需求變更控制機制 ⑤及時調整計劃;并周知所有項目有關人員 3.對于技術因素的緩解措施 ①使用模塊化、層次化開發(fā)模式,盡量降低系統復雜性 ②加強評審 4.進度風險的緩解措施 ①強化周報,月報,例會等措施 ②定期(如月)更新日程表 5.商業(yè)風險的緩解措施 ①重點關注關鍵路徑 ②客戶定期,充分溝通- 配套講稿:
如PPT文件的首頁顯示word圖標,表示該PPT已包含配套word講稿。雙擊word圖標可打開word文檔。
- 特殊限制:
部分文檔作品中含有的國旗、國徽等圖片,僅作為作品整體效果示例展示,禁止商用。設計者僅對作品中獨創(chuàng)性部分享有著作權。
- 關 鍵 詞:
- 超市管理系統 超市 管理 系統 項目 文檔
裝配圖網所有資源均是用戶自行上傳分享,僅供網友學習交流,未經上傳用戶書面授權,請勿作他用。
鏈接地址:http://www.hcyjhs8.com/p-6578337.html