網(wǎng)上書城項目計劃書

1、項目幵發(fā)計劃書網(wǎng)上書城系統(tǒng)成都朗沃信息技術有限公司編寫說明標題：項目開發(fā)計劃書版本歷史:版本作者日期備注1. 01項目1組2011/9/28新建1. 引言1.1. 編寫目的網(wǎng)上書城系統(tǒng)建設項目于 20011年 8 月 17日正式啟動，本計劃書對網(wǎng)上書 城系統(tǒng)建設項目做出總體上的規(guī)劃， 以使得系統(tǒng)的開發(fā)和實施能夠按部就班、 保 質(zhì)保量地完成。本計劃書的預期讀者為項目 1 組項目組成員、 朗沃信息開發(fā)部人員、 朗沃管 理部人員。1.2. 背景為進一步鞏固JavaScript以及AJAX課程中所學的知識，提升編碼能力。以及 對JavaScript和AJAX識的擴展，項目經(jīng)理帶領我們完成網(wǎng)上書城系統(tǒng)項

2、目。1.3. 參考資料列出參考資料，并說明得到這些文件資料的來源。資料類型包括： 1本項目的經(jīng)核準的計劃任務書和合同、上級機關的批文；2. 屬于本項目的其他已發(fā)表的文件；3. 本文件中各處引用的文件、資料，包括所要用到的軟件開發(fā)標準。列出 這些文件資料的標題、文件編號、 發(fā)表日期和出版單位， 說明能夠得到這些文件 資料的來源。網(wǎng)上書城開發(fā)合同API 文檔朗沃項目部JAVA編程規(guī)范2. 項目概述2.1. 項目目標網(wǎng)上書城系統(tǒng)建設按時完成之后，應首先具備以下功能：1. 圖書基礎數(shù)據(jù)的采集錄入和維護。2. 銷售報文的生成和管理。3. 反饋報文的管理和分析。同時應考慮到以后以此為基礎擴展開發(fā)圖書管理系

3、統(tǒng)2.2. 工作內(nèi)容設計、編碼、測試、答辯。2.3. 項目組織結構項目經(jīng)理：XXX項目組長：XXX項目成員： XXXXXX人員說明:姓名職責描述XXX （組長）督促組員對整個項目進度的掌控。XXX編程及測試XXX編程及測試XXX編程及測試XXX編程及測試2.4. 產(chǎn)品2.4.1. 程序本項目程序開發(fā)遵循J2EE開發(fā)規(guī)范，采用eclipse。項目建設中開發(fā)的程序源代碼，以磁介質(zhì)的形式于項目結束時，由項目組向 用戶方予以提交。2.42 文檔序號文檔名稱文檔類型提交時間1項目計劃書管理類項目之初2項目開發(fā)日志文檔類項目開發(fā)過程中2.4.3. 服務無服務。2.4.4. 非移交的產(chǎn)品源代碼。2.5. 驗

4、收標準老師滿意。2.6. 項目期限本項目應于2011年9月26日以前進入測試階段，并于2011年9月28日正 式提交。2.7. 本計劃的批準者和批準日期白德科，2011年8月17日3. 實施計劃3.1. 項目生命周期本項目周期共分為以下5個階段：1. 需求調(diào)研分析階段。主要完成工作：就需要完成網(wǎng)上書城系統(tǒng)的所有功能與白德科老師 交流。階段時間安排：2011年8月17日至2011年8月18日。2. 系統(tǒng)設計階段。系統(tǒng)設計階段分為概要設計和詳細設計兩部分，概要設計主要完成 系統(tǒng)功能模塊的劃分及系統(tǒng)業(yè)務操作流程的設定。詳細設計主要完 成數(shù)據(jù)庫設計和系統(tǒng)業(yè)務邏輯實現(xiàn)的流程實現(xiàn)。階段時間安排：2011年

5、8月18日至2011年8月19日。3. 編碼階段本階段除完成程序的主要編碼工作之外，各程序員還應對自己開發(fā) 的功能模塊完成功能測試。編碼階段時間安排：2011年8月19日至2011年9月24日。4. 系統(tǒng)測試階段對系統(tǒng)的功能進行全面的測試。系統(tǒng)測試階段時間安排：2011年9月24日至2011年9月27日5. 系統(tǒng)提交階段2011年9月28日將網(wǎng)上書城系統(tǒng)項目提交給項目經(jīng)理3.2. 關鍵問題主要是組員對項目中的業(yè)務分層，不能很好的掌握。關鍵技術：JavaScriptAJAX請求信息與響應信息的封裝持久層的封裝業(yè)務組件的封裝Jdbc連接數(shù)據(jù)庫操作4. 質(zhì)量保證計劃4.1. 項目風險分析及應對風險名

6、稱嚴重性發(fā)生概率應對措施高中低高中低4.2. 關鍵問題XXX的工作內(nèi)容很有可能出現(xiàn)不能完成。如果不行將它的工作由 XXX分擔完 成。如果項目中有疑問問XXX或項目經(jīng)理。43質(zhì)量控制點列出開發(fā)過程中確定的質(zhì)量控制點包括各階段評審和其它與項目相關的控 制點，強制性要求的評審有：計劃、需求、設計、測試，指出在控制點上的過程 輸出，采取的評審方式或驗證方法、 評審組織機構或人員等，在項目計劃詳細列 表中應列出所有需評審、驗證的內(nèi)容，并留出執(zhí)行時間。質(zhì)量控制點的選擇應根據(jù)項目的特點， 除了公司要求在計劃、需求、概要設 計、測試階段采取正式評審的方式進行外，可根據(jù)需要在其它階段進行。并在項 目計劃詳細列表

7、或詳細任務清單中列出所有需評審、 驗證的內(nèi)容，并留出執(zhí)行時 間（正式評審一般需要2- 3天）。質(zhì)量控制點一般包括，但不限于:質(zhì)量控制點要求控制方法評審機構項目計劃書必須正式評審需求規(guī)格說明書必須正式評審概要設計說明書必須正式評審測試計劃書、報告必須正式評審詳細設計說明書必須內(nèi)部評審項目組/用戶數(shù)據(jù)庫設計說明書必須內(nèi)部評審項目組/用戶源代碼必須內(nèi)部審查項目組/用戶系統(tǒng)投產(chǎn)計劃書建議內(nèi)部評審項目組/用戶系統(tǒng)應急計劃書建議內(nèi)部評審項目組/用戶手冊（操作、管理）建議內(nèi)部評審項目組/用戶驗收報告必須正式評審用戶定義:正式評審由sepg或用戶正式組織的對需審核物的會議評估， 一般有正式 的評估標準和評審表格。內(nèi)部評審/審查由項目組內(nèi)部進行的對需審核物的評估，形式可以是會 議、多人信息交互等，可以用會議紀要、規(guī)范的表格（代碼審查）或參照正式評 審表格設計的表格