廣州德易計算機科技有限公司軟件項目開發控制程序V1.0

文件編號TE-RD-GLZD-200807文件名稱軟件項目開發控制程序項目名稱管理制度項目代碼GLZD-RJXMKFKZCX運行單位|廣州德易計算機科技有限公司編寫人羅鈞日期2008-07-02審核人日期負責人日期版本號日期描述1.02008-07-02第一版本制定目錄TOC\o"1-5"\h\z\o"CurrentDocument"目錄 3第1章簡介 4目的 4\o"CurrentDocument"范圍 4\o"CurrentDocument"第2章人員職責 4\o"CurrentDocument"組成人員 4\o"CurrentDocument"職能分布表 5\o"CurrentDocument"主要職責描述 5\o"CurrentDocument"第3章工作程序 6\o"CurrentDocument"總體流程圖 6\o"CurrentDocument"需求分析 6\o"CurrentDocument"需求評審 7\o"CurrentDocument"系統設計 7\o"CurrentDocument"設計評審 8\o"CurrentDocument"編碼和單元測試 8\o"CurrentDocument"代碼檢查 8\o"CurrentDocument"集成測試 9第4章跟蹤和監控 9目的 9\o"CurrentDocument"檢查點 9項目周報. 9項目會議 10\o"CurrentDocument"第5章文檔模版 12第1章簡介目的本文檔是為了對廣州德易計算機科技有限公司軟件開發項目進行規范而制定。文檔內容包括人員組織、工作流程與輸出文檔。范圍適用范圍：廣州德易計算機科技有限公司自主開發軟件項目。第2章人員職責組成人員軟件開發項目全過程參與角色包括以下：業務人員部門經理項目經理需求人員設計人員編碼人員實施人員質管人員

職能分布表注：表中“■”表示：主要領導，“。”表示：相關職責;“★”表示：主要執行，“☆”表示：參與執行。序號職能名稱項目經理項目開發組實施小組質管小組需求人員設計人員編碼人員投標立項……客戶服務處理……★☆X.1需求分析?★X.2需求評審?★☆☆☆OX.3系統設計?☆★X.4設計評審?☆★☆☆OX.5編碼實現?☆★X.6代碼檢查?☆★X.7集成測試?☆★X.8編譯發布?☆★X.9實施交付?★☆X.10項目驗收?★主要職責描述部門經理：負責對軟件開發人員進行管理，并對項目經理提供幫助和支持。項目經理：領導項目組成員，協調與項目相關的所有資源，推動項目的運作，保障項目的成功。需求人員：負責客戶需求的調查，對需求進行分析，組織需求評審，并把評審結果與客戶進行確認。設計人員：負責為滿足客戶需求而進行的系統設計工作，組織設計評審。編碼人員：負責軟件開發的編碼實現工作，并進行單元測試和交叉代碼檢查。實施人員：負責對開發的功能進行確認，軟件的安裝部署、交付確認和現場實施，并負責對客戶進行操作培訓。

質管人員：參與并控制各階段的評審，負責項目的配置管理工作，以及開發軟件的集成測試、編譯和版本發布。第3章工作程序總體流程圖項目組并明確項目組成員工作職責。需求分析需求來源：客戶需求來源于和客戶接觸的公司成員，如業務人員，客服人員，工程實施人員、需求調研人員等。需求類型：包括新系統需求、已有系統升級需求（需求變更、已有系統BUG修正要求等。需求分析的目的是：確保客戶的需求被充分、正確地理解，使軟件的開發有一個準確無誤的依據，并為系統設計提供一個明確的方向。需求人員根據調研結果進行需求分析。必要時可以聯系需求提出人員（客戶），通過訪談、問卷、體驗、查閱等各種需求調查手段，明確用戶需求。在明確客戶需求的基礎上，可以提出初步的處理意見，必要時可以先組織項目組成員對用戶需求進行討論，最后形成《需求規格說明書》。需求評審需求人員提交《需求規格說明書》時提出進行需求評審，項目經理及時安排和召集需求評審會。評審會的參與人員包括：項目經理、需求人員、設計人員、編碼人員、質管人員、實施人員。需求評審由需求人員主講《需求規格說明書》，其他人員提出意見和建議。如果通過評審則進入系統設計，否則重新進行需求分析，待下次評審。質管人員記錄評審結果，形成《評審記錄表》。對不通過評審的需求分析，質管人員有權要求并監督項目經理不得擅自安排進行系統設計。系統設計系統設計的目的是找到一個最優的方法來實現客戶需求，用以指導程序員進行編碼實現。設計人員根據《需求規格說明書》進行系統設計工作。系統設計工作，需要先進行概要設計，形成《系統概要設計說明書》；再進行詳細設計，形成《系統詳細設計說明書》。設計說明的主要內容包括：總體設計：對需求進行整體分析，描述總體的解決方案；令功能設計：描述軟件的外部功能和用戶操作界面；令對象/模塊設計：描述構成軟件系統的各個對象/模塊、及其之間的關系。設計評審設計人員提交《設計說明書》時提出進行設計評審，項目經理及時安排和召集設計評審會。評審會的參與人員包括：項目經理、需求人員、設計人員、開發人員、質管人員、實施人員。設計評審由設計人員主講《設計說明書》，其他人員提出意見和建議。如果通過評審則進入編碼實現，否則繼續進行系統設計。質管人員記錄評審結果，形成《評審記錄表》。對不通過評審的系統設計，質管人員有權要求并監督項目經理不得擅自安排進行編碼實現。編碼和單元測試編碼人員根據《設計說明書》進行代碼編寫和單元測試。程序代碼的命名約定、排版格式等，要遵從編程語言對應的《編碼規范》。在進行單元測試時記錄測試過程并形成《單元測試報告》。測試報告的主要內容包括：測試步驟，各步驟的輸入、預期輸出、實際輸出，測試結論。代碼檢查代碼檢查是一種簡單形式的同行評審，在開發人員之間交叉進行。通過代碼檢查，提高代碼的規范性，使代碼清晰易讀、易于維護；也能在一定程度上提高編碼質量，使大家互相學習、互相督促、共同進步。編碼人員完成編碼實現后，提交工作成果，由其他開發人員閱讀、執行代碼，對編碼工作進行確認。代碼檢查依據的主要標準如下：令程序代碼符合編碼規范。令遍歷執行了所有代碼分支之后，沒有發生錯誤，沒有冗余代碼。代碼檢查的結果由檢查人填寫到《代碼檢查表》。檢查通過的，提交進入集成測試步驟；檢查不通過的返回給編碼人進行修正。集成測試在系統開發達到目標基線時，由質管和實施人員組織集成測試。第4章跟蹤和監控目的項目監控的目的是為軟件項目開發過程提供足夠的可見性，以便當項目嚴重偏離計劃時及時采取糾正措施。檢查點.1項目周報項目組必須每周填寫項目周報匯報工作情況。■匯報對象：1、部門經理2、直接主管3、業務部項目對口人員4、客戶（發給客戶的文檔與發給公司內部人員的文檔有差異，刪除部分對項目不利的描述）■項目周報描述內容：1、完成情況這部分應簡要描述從上次報告以來的工作進度。應簡要描述完成情況并標注任務的完成。還可以包括對工作進度的主觀度量，但不要用于計算進度。2、問題描述遇到的可能會嚴重妨礙項目目標的實現的新問題及解決問題所采取的步驟。還要報告早先識別出來的在上次報告時還沒有解決的問題的狀態。3、風險類似的，應該對發現的重大的新風險和早先識別的風險的變更進行報告。也要描述采取的風險減緩步驟。4、變更注意本報告期內處理的重要的項目或配置變更（如，提出，評價，批準，完成）5、下階段計劃6、項目提交物.2項目會議項目組定期評審項目技術進展、結果和問題（根據項目計劃進行階段性的會議）定期與客戶溝通，匯報工作情況（根據項目計劃進行階段性的會議）發生嚴重問題或偏離項目計劃時召開項目會議需求變更的時候舉行項目會議項目會議應形成會議記要，并分發給相關人員，發送對象一、內部會議：a）部門經理b）直接主管c）業務部項目對口人員d）參加會議人員二、與客戶會議:a）部門經理b）直接主管c）業務部項目對口人員d）參加會議人員e）客戶項目管理人員第5章文檔模版對文檔的格式與內容進行規范：[010-商務]----[011-用戶需求]----[012-建議書]----[013-招標]----[014-投標]----[015-合同][020-計劃]項目計劃.DOC項目計劃.MPP[030-需求]需求規格說明書.DOC[040-設計]總體設計.DOCDATABASE.PDM數據庫設計說明書.DOC（內容由DATABASE.PDM的REPORT模版生成）[050-測試