1、儲蓄業務項目管理計劃書1. 簡介1.1 項目概述本項目要開發一個銀行系統，系統一共分為儲蓄業務、貸款業務、外匯交易、 網上銀行、信用卡業務和系統管理六個子系統。本團隊負責其中的有關儲蓄業務 的子系統。通過團隊合作開發整個子系統，使團隊成員獲得軟件工程開發的實際 訓練。本系統采用目前主流的B/S開發架構，將與整個銀行系統一起發布。不單 獨發布。交付的產品包括可執行的文件、源代碼、技術文檔與用戶使用手冊等。 本系統的開發過程中的主要工作是子系統需求分析、系統總體設計、子系統源代 碼開發、子系統測試、交付團長進行最后的集成、整個系統的測試。關鍵里程碑 是制定項目管理計劃書、制定需求設計規格說明書初稿

2、、制定系統設計報告的初 稿、進行子系統運行情況的檢查與測試、進行系統集成后的運 行情況的檢查與測試。項目所需工具是個人電腦和開發工具。進度為11周，工 程量為3人/天。1.2 項目范圍說明（1）提交文檔：項目管理計劃、需求規格說明，設計報告、測試報告、用戶 使用手冊和項目個人總結。其中項目總結為每人一份，每個小組所有成員的總結 裝訂在一起；其余文檔每組提交一份。每個團隊可將各小組的文檔綜合到一起， 各小組也可自行分開提交，具體方式由團隊內部協商確定。所有文檔需要提交電 子版和打印稿。（2）源程序檢查：一共兩次。第一次檢查每個小組的子系統運行情況。第二 次檢查每個團隊內六個小組集成后完整的銀行系

3、統運行情況，檢查完成后需要提 交程序源文件和可執行的系統。程序檢查安排在上機時間進行。1.3 軟件項目計劃書的演化軟件項目計劃書在第三周周末前經由小組討論、共同撰寫、匯總整合三步驟 形成初稿，第四周以后根據項目的進展可以對其進行修改，需要有組員提出修改 意，在全體會上討論通過，并由組長整理修改意見并作出相應的修改。其余組員 同步獲得更新稿。2. 項目組織管理2.1 過程模型表1.過程模型表關鍵時間c任務甲第四周，3月乳日晚12 點之前制定項目管理計劃初稿O管理計劃提交給團長，由團長匯、 匯總檢查、并提交。Q第七周，4.月上.日晚勰 點之前完成需求規格說明 初稿。電子版提交給團長，由團長匯總 檢

4、查、提交，。第十胤5.月.5日晚.12 點之前"完成設計報告初稿電子版提交給團長,由團長匯總、 檢查、提交，/第十二、三周O進行子系統運行檢查丁以小組為單位進行，由團長及其 他組長組成評審團，對子系統進 行運行測試檢查電d第十四周/進行系統集成后的 運行檢查P由團長，組長和主程序開發人員 參加。對整個銀行系統進行集成、 運行測試檢查。并同時對提交各 種文檔的電子版，提交電子版源 代碼和可執行系統進行最后的修 改。小笫十五周。交付軟件項目。Q由團長，組長和主程序開發人員 參加，利用上機時間進行產品的 交付與發柏。提交各種文檔的電 子版和打印稿，提交電子版源代 弱和可執行系統Q 2.2

5、團隊的分工與合作主程序員負責制。本團隊組織關系圖如下。表2組織關系圖成員角色職責張三組長、主程序員領導項目團隊、執行和管理團 隊、負責軟件的交付工作。同時作為主程序員還要負責 軟件設計和編寫代碼。并撰寫 軟件設計報告。李四程序員、文檔維護員整理需求分析并撰寫需求分 析報告、維護并及時修改和發 布已更新技術文檔。作為程序 員還要參與軟件設計與代碼 開發。王五軟件測試員、秘書、美工主要負責軟件代碼測試和用 戶測試、并撰寫測試文檔初稿 并對界而美工付主要責任、作 為秘書要主持每周的討論會以及團內溝通工作。3. 管理過程3.1 管理目標及優先級基本管理原則：每位成員既是積極的建言者，乂是負責的合作者，

6、同時也是 決策的制定者。決策應在充分的討論基礎上由大家共同做出，一旦決策做出就必 須被及時有效的執行。禁止再有異議。目標1：按時按量完成項目的基本功能，按時發布產品及文檔，這是本團隊 的最高目標。目標2：遵循規范化的項目運作標準，文檔嚴謹完整，代碼注釋充分，便于 后續維護，這是第二目標。目標3：產品運行穩定，界面友好，用戶易操作，盡量從用戶的角度去看問 題，并提出解決問題的方案。目標4：注重團隊建設，成員分工合理，團隊成員合作默契，氣氛融洽。每 周的討論會積極建言。在開發過程中積極協作。目標5：項目設計和開發上盡量有創新，有亮點。3.2 項目風險管理本次開發過程中存在的風險及規避方法如下表：表

7、3項目風險及其規避方法風險類型存在風險規避方法進度風險由于時間緊張導致項目最后無法按期完成。充分考慮各種潛在因素，適當留 有余地：任務分解要詳細，便于 考核：在執行過程中，應該強調 項目按照進度執行的重要項，再 考慮任何問題時，都要經保持進度作為先決條件：同時，合理利 用趕工期及快速跟進等方法，充 分利用資源。如果出現必須延期 的情況，組長需及時同銀行相關 負責人溝通，并申請延期時間。系統沒有足夠的測試時間持續地監控，項目進度控制隨著 項目的進行而不斷進行的，保證 每個環節都有足夠的時間。技術風險開發軟件結構體系存在問題，使完成的軟件產品未能實現項目預定目標選用正版軟件開發對開發軟件的掌握不夠

8、深入，造 成開發出的產品性能以及質量 低劣。提前制定好兩周的學習計劃，各 組員 要對開 發工具 vs2005+sqlsever2005 , css , photoshop及flash進行快速的學 習。盡快掌握其中的要點。同時 在軟件的設計上盡可能降低難度 使項目最后能成功完成。質量風險質量不符合用戶要求經常和用戶交流工作成果、品牌 管理采用符合要求的開發流程、 認真組織對產出物的檢查和評 審、計劃和組織嚴格的獨立測試 等。工具風險軟件項目開發和實施過程,所必 須用到的管理工具、開發工具、在項目的啟動階段就落實好各項工具的來源或可能的替代工具，測試工具未能及時到位在這些工具需要使用之前跟蹤并 落

9、實工具的到位事宜。在進行項 目開發之前先設計和搭建出系統 的基礎架構并進行性能測試，確 保架構符合性能指標后再進行后 續工作。人力資源風險組員成員因意外無法參加設計事先同用戶商量解決辦法3.3 項目溝通管理報告機制：1 .要求各組員以周為單位記錄工作進展，形成開發日志，并以電子文檔的形 式提交給秘書進行整理，最后由文檔維護員進行維護。2 .每周例會上各位組員積極對當前的開發工作進行積極的評審和建言，由組 長做最后的作口頭總結，由秘書主持會議并記錄和整理會議的內容。文檔維護 員修改和維護相應的文檔。并交由小組進行會議評審并給出意見。3 .小組成員都要密切監控風險狀態，發現風險后提交風險報告。由秘

10、書定期 提交風險報告。必要時將突發風險通知所有組員，并由組長做出臨時處理決定。 然后在該周的例會上由小組成員共同討論對風險的處理意見。并形成風險處理的 日志做為以后的經驗。4 .在項目進行的過程當中，組員之間應該多進行各種形式的非正式溝通，以 使溝通更加的方便、快捷。報告格式：報告主題，時間段，發現人，報告內容，審核意見評審機制：每周例會上小組討論形成一致意見后并，并邀請團長和其他組長 參加評議。對于重大的風險處即為通過，相關負責人針對改進意見開展下一周工 作，嚴格執行例會上所制定的決策。小組會議持續評估其成效。每一項目階段結 束之前（里程碑前后），組織一次階段評審會，評估整個階段的工作效率和

11、成果 質量。盡量與項目例會合理意見，應該由團長及其他組長組成評審團對處理意見 進行審議和評估。并以評審團的決議作為重要參考來制定決策。3.4 項目人力資源管理3.4.1 項目所需人員C#程序員：張三，李四要求：熟悉C#編程和微軟.Net平臺界面設計員：王五要求：熟悉 CSS、Photoshop、.Net平臺數據庫設計員：張三要求：熟悉SQL語句，熟練使用SQL Sevei: 2005文檔維護員：李四要求：熟悉使用VC'oid及Powerpouit溝通交流員：王五要求：較強的溝通能力，能及時調解組內以及組與組之間的矛盾。軟件測試人員：全體組員，有王五付總責要求：熟練使用開發工具的debu

12、g工具，有耐心。3.4.2 技能培訓C#以及Net編程培訓培訓對象：全體組員。培訓內容：熟練掌握C#編程、基本了解.Net平臺的特性、并掌握食2005的調 試工具。于第6周完成。美工培訓：全體組員培訓內容：熟悉Css及Photoshop、/解Flash以及Dreanievei:的基本操作。 于第8周完成。4. 技術過程4.1 開發工具、方法和技術：本小組的團隊組織結構為主程序員式組織結構；編程語言為C#；采用面向對象的分析設計方法；利用NkdowsNet平臺作為開發平臺；使用SqlSever 2005作 為數據庫管理系統圖；并采用統一的C#標準的文件命名方式、代碼版式、注釋 等編碼規范；編碼人

13、員對代碼進行嚴格檢查后再進行代碼編譯；測試人員根據測 試文檔進行單元測試；最后實現軟件的交付。開發環境：Sqlsever 2005+ .Net 2.0 + 'Visual Studio 2005。4.2 軟件需交付的文檔：1 .軟件項目管理計劃該文檔由組長完成，介紹項目的整個管理過程。該文檔在軟件設計需求分析 初級階段完成，后續階段由文檔維護員進行相應的更新。2 .需求規格說明初稿在需求分析階段，由全體小組成員采集分析用戶的需求，并在例會上作出決 策，有文檔維護員撰寫整理需求規格說明初稿，并在后續各個階段進行需求變更 的更新。3 .設計報告初稿在總體設計階段，小組根據需求規格說明文檔，

14、完成軟件體系結構的設計， 由組長編寫軟件體系結構設計文檔初稿，并在后續開發階段補充和更新。該文檔 由文檔維護員負責維護更新。4 .測試文檔在軟件開發階段，測試人員需要編寫測試規格說明文檔，并在后續測試階段 更新。開發人員將根據測試規格說明文檔建立測試環境、準備測試數據。5 .用戶手冊在更新用需求分析階段，測試人員需要開始著手編寫用戶手冊，并在需求分 析結束后需要形成初稿；在后續階段不斷由文檔維護員戶文檔；并在系統交付階 段隨著系統一起被交付。6 .個人項目總結由組內成員各自獨立完成，對開發過程中獲得的工作經驗進行總結。在提交系統時一并提交。7 .其他文檔軟件開發過程中的其他文檔，如開發日志（按

15、組員意見選擇公開與否），風 險報告及其處理意見等，由秘書進行整理與匯聚。作為以后軟件開發以及交流的 經驗。5. 項目進度及成本管理5.1 進度描述項目進度描述如下表：表4進度表格描述工作集子工作完成時間負責人最終交付物描述準備工作確定團長及組長第二周劉建民組長及團長名單成立整個銀行系統的開發團隊確定小組第三周張三小組成員名單成立貸款業務子系統開發團隊搭建環境第三周組內各成員Vs2005+SQLsever2005確定開發工具及語言制定項目管理計劃書第四周張三項目管理計劃書初稿制定軟件開發過程管理計劃完成需求采集用戶需求第五周張三需求規格說明書的初通過查資料規格說明書的出稿分析用戶需求及制定需求規

16、格說明原型第五周李四稿了解和采集用戶的需求。對需求進行匯總，制定需求規格說明初稿需求規格說明的進一步完善與修改第六周需求規格說明的最后確認第七周系統設計系統總體設計第八周張三軟件設計報告初稿制定系統總 體的設計方 案，并根據 需求說明聯 系實際進行 相應的修改系統詳細設計第九周系統模型及架構最后確定第開發系統源代碼及源碼測試系統源碼開發第十一周張三李四源代碼要求熟練使 用C#和.Net 平臺系統源碼測試第!.周王五測試文檔根據測試文檔嚴格測試系統源碼復查第十三周李四無對代碼進行復查，盡量減少bug進行整個銀行系統的集成進行整個銀行系統的集成第十四周張三無與其他小組 長無間協作 完成整個系 統的

17、集成對整個集成后 的系統進行測 試檢查運行情 況第四周張三上配置好IIS 服務，搭建 整個系統的 運行平臺測試整個系統 的發布情況系統交付系統交付第十五張三一個可以運行的的系各組之間可周統以及用戶手冊和幫以交流各自助。以及最后確定的的開發經驗技術文檔和心得體會5.2 開發過程中的資源需求人員：小組軟件項目開發成員支持軟件：jLciosoft Visixal Studio 2005> .Net 2.0> Office> Sqlsever 2005開發地點：宿舍或者機房實驗設備：個人PC機、筆記本、實驗室PC機項目資源維護需求的數目和類型：3臺個人電腦（Pentium DI 800以上CPU,