第一篇：軟件開發管理規范

軟件開發過程管理規范

濟南明湖建筑節能技術開發有限公司 軟件開發過程管理規范

一、總則.................................................................................................................................1 1.軟件開發項目管理的目的.........................................................................................1 2.軟件開發項目管理規范適用對象.............................................................................1 3.軟件項目開發組織管理.............................................................................................1

二、軟件項目立項階段.........................................................................................................1

三、軟件項目實施階段.........................................................................................................2

四、項目需求分析過程.........................................................................................................2

五、項目系統設計過程.........................................................................................................3

六、項目開發編碼過程.........................................................................................................3

七、測試提交過程.................................................................................................................4

八、項目驗收總結階段.........................................................................................................4

軟件開發過程管理規范

一、總則

1.軟件開發項目管理的目的

為保障按時、保質、保量完成預期交付的任務，讓整個組織能清楚了解項目實施的目的、影響、進度，做到項目組所有成員都理解項目實施的原因、意義及客戶的要求。通過制度化管理來合理組織安排項目組成員的工作職責和角色轉換。2.軟件開發項目管理規范適用對象

為了達到軟件開發項目管理的根本目的，要求公司全體員工必須嚴格按照本規范執行，同時要求公司業務人員引導合作單位和客戶接受并適應公司本《軟件項目開發管理規范》。3.軟件項目開發組織管理

根據軟件開發的標準流程，結合公司的實際情況對軟件項目分三個主要階段進行組織管理，分別為項目立項階段、項目實施階段和項目驗收總結階段。

二、軟件項目立項階段

1.成立公司項目評估委員會負責公司的項目立項審批。

2.公司項目評估委員會由公司總經理或指定負責人召集，成員為公司管理層人員、商務負責人、市場負責人、技術總監、技術研發經理、財務負責人組成。

3.公司業務部門按照公司發展要求或外部需求形成《軟件項目需求說明書》，確定項目需求管理人或項目申請人。

4.項目申請人填寫《軟件項目立項申請書》向項目評估委員會提出項目立項申請，主要說明項目的背景、目的、效益、成本、需求等方面，并由技術部門提供支持和技術說明。5.項目評估委員會收到《項目立項申請書》后三個工作日內，召開評估會議。給出評估結果。如果批準立項交公司技術總監組織開發。如果不批準，給出理由后項目中止。中止后的項目可根據情況重新申請。

6.評估結果必須包括：建議項目啟動日期，期望項目完成日期，項目等級系數，項目優先級（高中低），資源沖突程度(1~9)。對于資源沖突程度大于5的項目技術總監有權拒絕

軟件開發過程管理規范

接受。

三、軟件項目實施階段

1.公司批準立項的項目交由公司技術總監組織實施。

2.技術總監根據資源情況和項目需求組織相關技術人員進行初步需求討論會，確定項目的等級系數（如分大、中、小對應3、2、1）、指定項目開發負責人。在立項后五個工作日內技術總監和項目開發負責人共同制定《軟件項目開發計劃》，確定項目啟動日并提交項目評估委員會做反饋確認。如果項目評估委員會二位成員以上對計劃有異議，項目評估委員會應該召開項目計劃協調會，協調《軟件項目開發計劃》的修改和通過。如果無異議授權技術總監按照《軟件項目開發計劃》執行。

3.項目啟動日后，項目開發負責人根據《軟件項目開發計劃》的進度每周進行一次分析匯報，形成《項目分析周報》確定項目的狀態、分析風險和對策，交技術總監管控。4.《軟件項目開發計劃》必須按照軟件項目實施過程分解為需求分析、系統設計、開發編碼和測試提交幾個控制過程。

四、項目需求分析過程

1.項目需求分析團隊由技術總監負責，組成人員包括技術研發經理、項目開發負責人、部分高級軟件開發工程師和需求提供人。

2.需求分析第一次會議將在《軟件項目開發計劃》通過后，在項目啟動日2個工作日內召開，提出需求的不足之處交需求提供人完善。

3.分析團隊分工完成提交《軟件項目需求功能列表》及《項目關鍵業務流程》文擋。4.需求分析應該在需求分析第一次會議后的開始，并在（3個工作日*項目等級系數）日內完成。

5.需求分析過程完成后，如果需求變更提供人必須書面提出《項目需求變更通知書》，項目需求分析團隊在2個工作日內完成分析反饋，確定項目變更系數；項目負責人變更對應《軟件項目開發計劃》版本。

6.需求分析階段完成的標志為技術總監召開文擋審查和階段總結會，時間為1個工作日。

軟件開發過程管理規范

五、項目系統設計過程

1.項目設計團隊由技術總監負責，組成人員包括技術研發經理、項目開發負責人、部分高級軟件開發工程師。

2.項目分析設計團隊在收到需求階段文檔后2個工作日內召開設計工作啟動協調會，審查反饋需求階段文檔。

3.協調會明確分工、按計劃完成《項目系統接口說明》、《項目系統數據設計文檔》和《主要操作界面說明》文檔。

4.項目設計應該在啟動協調會后開始，并在（5個工作日*項目等級系數）日內完成。5.項目負責人接到《項目需求變更通知書》后，按照1個工作日*項目變更系數調整對應設計和計劃。

6.項目設計階段完成的標志為技術總監召開設計文擋審查和階段總結會，時間為1個工作日。

六、項目開發編碼過程

1.項目開發編碼團隊由技術研發經理負責，組成人員包括項目開發負責人和軟件開發工程師。

2.項目開發編碼團隊在收到需求和設計階段文檔后2個工作日內召開編碼工作啟動協調會，學習理解并反饋需求和設計階段文檔。

3.技術研發經理按照項目《軟件項目開發計劃》中開發編碼過程的細分階段進行控制。

4.項目開發負責人需負責項目聯調測試，保證《項目關鍵業務流程》和《主要操作界面說明》文檔的實現。

5.技術研發經理要組織項目開發編碼團隊對（項目等級系數）關鍵代碼進行集中解讀，保證編碼的質量和規范。

6.根據項目的情況，要求開發編碼人員對《項目系統接口說明》中接口進行性能測試，并產生接口測試報告。

7.技術研發經理負責做好開發編碼的版本管理工作。

8.開發編碼應該在編碼工作啟動協調會后開始，并在（10個工作日*項目等級系數）內完成。

軟件開發過程管理規范

9.開發編碼階段完成的標志為測試人員接受測試版本后，技術研發經理召開提交和階段總結會，開發人員的所有代碼轉交給項目負責人管理。時間為1個工作日。

七、測試提交過程

1.項目測試團隊由技術研發經理、項目負責人和測試工程師組成。

2.測試工程師首先檢查開發編碼團隊《項目關鍵業務流程》、《主要操作界面說明》和《項目系統接口說明》的測試結果。如果通過才接受，否則將退回。

3.測試工程師在開發編碼階段的同時應該編制好《項目軟件使用說明書》，接受測試版本后按照《項目軟件使用說明書》進行測試。

4.測試工程師重新測試一次《項目關鍵業務流程》、《主要操作界面說明》和《項目系統接口說明》。

5.測試工程師完成對應版本的《項目測試報告》，發現的問題交項目負責人負責組織開發人員修改完善。

6.測試工程師提交完成版本的《項目測試報告》后，由技術研發經理確認并簽字。將對應版本定義為發布版本。

7.測試工作應該在接受測試版本后進行，并在（5個工作日*項目等級系數）內完成。

八、項目驗收總結階段

1.發布版本后，項目負責人打印收集好所有項目過程文擋，并有對應責任人簽字。

2.項目負責人回顧總結《軟件項目開發計劃》，分析總結實際和計劃差異，形成《項目計劃執行情況報告》。

3.技術研發經理總結項目設計、開發、測試過程的質量控制和開發人員開發效率情況，總結經驗教訓并提出項目開發改進措施。

4.技術總監總結分析成本控制、對全部項目人員進行考核，形成《項目總結報告》。并完善本規范流程。

5.上述工作完成后，提交項目評估委員會總結會審批后公布。

第二篇：軟件開發文檔規范（定稿）

附2:

軟件文檔編寫向導

文檔分類

項目包括如下幾類文檔：

項目管理文檔。包括：《軟件項目計劃》、《項目進度報告》、《項目開發總結報告》 軟件開發文檔。包括：《需求規格說明》、《概要設計說明》、《詳細設計說明》、《測試計劃》、《軟件測試分析報告》。

產品文檔。包括：《用戶操作手冊》《演示文件》。

軟件項目計劃

（Software Project Plan）

一．引言

1．編寫目的（闡明編寫軟件計劃的目的，指出讀者對象。）

2．項目背景（可包括：（1）項目委托單位、開發單位和主管部門；（2）該軟件系統與其他系統的關系。）

3．定義（列出本文檔中用到的專門術語的定義和縮略詞的原文。）

4．參考資料（可包括：文檔所引用的資料、規范等；列出資料的作者、標題、編號、發表日期、出版單位或資料來源。）

二．項目概述

1.工作內容（簡要說明項目的各項主要工作,介紹所開發軟件的功能性能等.若不編寫可行性研究報告,則應在本節給出較詳細的介紹。)2.條件與限制（闡明為完成項目應具備的條件開發單位已具備的條件以及尚需創造的條件.必要時還應說明用戶及分合同承包者承擔的工作完成期限及其它條件與限制。）3.產品

（1）程序（列出應交付的程序名稱使用的語言及存儲形式。）

（2）文檔（列出應交付的文檔。）

（3）運行環境（應包括硬件環境軟件環境。）

4．服務（闡明開發單位可向用戶提供的服務.如人員培訓安裝保修維護和其他運行支持。）5．驗收標準

三．實施計劃

1．任務分解（任務的劃分及各項任務的負責人。）

2．進度（按階段完成的項目,用圖表說明開始時間完成時間。）3．預算

4．關鍵問題（說明可能影響項目的關鍵問題,如設備條件技術難點或其他風險因素,并說明對策。）

四．人員組織及分工 五．交付期限

六．專題計劃要點（如測試計劃等。）

項目開發進度報告

一．報告時間及所處的開發階段 二．給出進度

1． 本周的主要活動 2． 實際進展與計劃比較

三．所用工時（按不同層次人員分別計時。）四．所有機時

五．工作遇到的問題及采取的對策 六．本周完成的成果 七．下周的工作計劃 八．特殊問題

項目開發總結報告

一．引言

1．編寫目的（闡明編寫總結報告的目的,指明讀者對象。）

2．項目背景（說明項目的來源、委托單位、開發單位及主管部門。）3．定義（列出報告中用到的專門術語定義和縮寫詞的原意。）

4．參考資料（列出這些資料的作者、標題、編號、發表日期、出版單位或資料來源，可包括：（1）項目開發計劃；（2）需求規格說明書；（3）概要設計說明書；（4）詳細設計說明書；（5）用戶操作手冊；（6）測試計劃；（7）測試分析報告（8）本報告引用的其他資料、采用的開發標準或開發規范。）

二．開發結果

1． 產品（可包括：（1）列出各部分的程序名稱、源程序行數（包括注釋行）或目標程序字節數及程序總計數量、存儲形式；產品文檔名稱等。）2． 主要功能及性能

3． 所用工時（按人員的不同層次分別計時。）4． 所用機時

5． 進度（給出計劃進度與實際進度的對比。）

三．評價

1．生產率評價（如平均每人每周源程序行數、文檔的字數等。）2．技術方案評價 3．產品質量評價

四．經驗與教訓

需求規格說明書

（Requirements Specification）

一．引言

1． 編寫目的（闡明編寫需求說明書的目的,指明讀者對象。）

2． 項目背景（可包括：（1）項目的委托單位,開發單位和主管部門；（2）該軟件系統與其他系統的關系。）

3． 定義（列出文檔中用到的專門術語定義和縮寫詞的原文。）

4． 參考資料（可包括：（1）項目開發計劃；（2）文檔所引用的資料，標準和規范。列出這些資料的作者、標題、編號、發表日期、出版單位或資料來源。）

二．任務概述

1．目標 2．運行環境 3．條件與限制

三．數據描述

1． 靜態數據

2． 動態數據（包括輸入數據和輸出數據。）3． 數據庫描述（給出使用數據庫的名稱和類型。）

4． 數據詞典 5． 數據采集

四．功能需求

1．功能劃分 2．功能描述

五．性能需求

1．數據精確度

2．時間特性（如響應時間、更新處理時間、數據轉化與傳輸時間、運行時間等。）3．適應性（在操作方式運行環境與其他軟件的接口以及開發計劃等發生變化時，應具有的適應能力。）

六．運行需求

1．用戶界面（如屏幕格式、報表格式、菜單格式、輸入輸出時間等。）2．硬件接口 3．軟件接口 4．故障處理

七．其他需求（如可使用性、安全保密、可維護性、可移植性等。）

概要設計說明書

（Architectural Design Specification）

一．引言

1．編寫目的（闡明編寫概要設計說明書的目的，指明讀者對象。）

2．項目背景（可包括：（1）項目的委托單位,開發單位和主管部門；（2）該軟件系統與其他系統的關系。）

3．定義（列出文檔中用到的專門術語定義和縮寫詞的原意。）

4．參考資料（列出這些資料的作者、標題、編號、發表日期、出版單位或資料來源，可包括：（1）項目開發計劃；（2）需求規格說明書；（3）測試計劃（初稿）；（4）用戶操作手冊（初稿）；（5）文檔所引用的資料、采用的標準或規范。）

二．任務概述

1．目標

2．運行環境 3．需求概述 4．條件與限制

三．總體設計

1．處理流程

2．總體結構和模塊外部設計

3．功能分配（表明各項功能與程序結構的關系。）

四．接口設計

1．外部接口（包括用戶界面軟件接口與硬件接口。）2．內部接口（模塊之間的接口。）

五．數據結構設計

1． 邏輯結構設計 2． 物理結構設計 3． 數據結構與程序的關系

六．運行設計

1．運行模塊的組合 2．運行控制 3．運行時間

七．出錯處理設計

1．出錯輸出信息

2．出錯處理對策（如設置后備、性能降級、恢復及再啟動等。）

八．安全保密設計

九．維護設計（說明為方便維護工作的設施,如維護模塊等。）

詳細設計說明書

（Procedural Design Specification）

一．引言

1． 編寫目的（闡明編寫詳細設計說明書的目的,指明讀者對象。）2． 項目背景（應包括項目的來源和主管部門等。）

3． 定義（列出文檔中用到的專門術語定義和縮寫詞的原意。）

4． 參考資料（列出這些資料的作者、標題、編號、發表日期、出版單位或資料來源，可包括：（1）項目開發計劃；（2）需求規格說明書；（3）概要設計說明書；（4）測試計劃(初稿)；（5）用戶操作手冊(初稿)；（5）文檔所引用的其他資料、軟件開發標準或規范。）

二．總體設計

1．需求概述

2．軟件結構（如給出軟件系統的結果圖。）

三．程序描述（逐個模塊給出以下的說明:：）

1．功能 2．性能 3．輸入項目 4．輸出項目

5．算法（模塊所選用的算法。）

6．程序邏輯（詳細描述模塊實現的算法，可采用:：（1）標準流程圖；（2）N-S圖；（3）PAD；（4）判定表等描述算法的圖表。）7．接口 8．存儲分配 9．限制條件

10．測試要點（給出測試模塊的主要測試要求。）

測試計劃（Test Plan）

一、引言

1． 編寫目的（闡明編寫測試計劃的目的,指明讀者對象。）2． 項目背景（說明項目的來源委托單位及主管部門。）

3． 定義（列出測試計劃中用到的專門術語定義和縮寫詞的原意。）

4． 參考資料（列出這些資料的作者、標題、編號、發表日期、出版單位或資料來源，可包括：（1）項目開發計劃；（2）需求規格說明書；（3）概要設計說明書；（4）詳細設計說明書；（5）用戶操作手冊;(6)本測試計劃中引用的其他資料采用的軟件開發標準或規范。）

二．任務概述

1．目標

2．運行環境 3．需求概述 4．條件與限制

三．計劃

1．測試方案（說明確定測試方法和選取測試用例的原則。）

2．測試項目（列出組裝測試和確認測試中每一項測試的內容、名稱、目的和進度。）3．測試準備

4．測試機構及人員（測試機構名稱負責人和職責。）

四．測試項目說明（按順序逐個對測試項目做出說明：）

1．測試項目名稱及測試內容 2．測試用例

（1）輸入（輸入的數據和輸入的命令。）（2）輸出（預期的輸出數據。）

（3）步驟及操作

（4）允許偏差（給出實測結果與預測結果之間允許偏差的范圍。）3． 進度

4． 條件（給出項測試對資源的特殊要求，如設備、軟件、人員等。）5． 測試資料（說明項測試所需的資料。）

五．評價

1．范圍（說明所完成的各項測試說明問題的范圍及其局限性。）2．準則（說明評價測試結果的準則。）

測試分析報告（Test Specification）

一．引言

1．編寫目的（闡明編寫測試分析報告的目的，指明讀者對象。）2．項目背景（說明項目的來源、委托單位及主管部門。）

3．定義（列出測試分析報告中用到的專門術語定義和縮寫詞的原意。）

4．參考資料（列出這些資料的作者、標題、編號、發表日期、出版單位或資料來源，可包括：（1）項目開發計劃；（2）需求規格說明書；（3）概要設計說明書；（4）詳細設計說明

書；（5）用戶操作手冊；（6）測試計劃；（7）測試分析報告所引用的其他資料、采用的軟件工程標準或軟件工程規范。）

二．測試計劃執行情況

1．測試項目（列出每一測試項目的名稱、內容和目的。）

2．測試機構和人員（給出測試機構名稱、負責人和參與測試人員名單。）

3．測試結果（按順序給出每一測試項目的：（1）實測結果數據（2）與預期結果數據的偏差（3）該項測試說明的事實（4）該項測試發現的問題。）

三．軟件需求測試結論

按順序給出每一項需求測試的結論。包括：（1）證實的軟件能力（2）局限性（即項需求未得到充分測試的情況及原因）。

四．評價

1．軟件能力（經過測試所表明的軟件能力。）

2．缺陷和限制（說明測試所揭露的軟件缺陷和不足,以及可能給軟件運行帶來的影響。）3．建議（提出為彌補上述缺陷的建議。）4．測試結論（說明能否通過。）

用戶操作手冊（User Guide）

一．引言

1．編寫目的（闡明編寫手冊的目的，指明讀者對象。）

2．項目背景（說明項目的來源、委托單位、開發單位及主管部門。）3．定義（列出手冊中用到的專門術語定義和縮寫詞的原意。）

4．參考資料（列出這些資料的作者、標題、編號、發表日期、出版單位或資料來源，可包括：（1）項目開發計劃；（2）需求規格說明書；（3）概要設計說明書；（4）詳細設計說明書；（5）測試計劃；（6）手冊中引用的其他資料、采用的軟件工程標準或軟件工程規范。）

二．軟件概述

1．目標 2．功能 3．性能

（1）數據精確度（包括輸入、輸出及處理數據的精度。）（2）時間特性（如響應時間、處理時間、數據傳輸時間等。）

（3）靈活性（在操作方式、運行環境需做某些變更時軟件的適應能力。）

三．運行環境

1．硬件（列出軟件系統運行時所需的硬件最小配置，如：（1）計算機型號、主存容量；（2）外存儲器、媒體、記錄格式、設備型號及數量；（3）輸入、輸出設備；（4）數據傳輸設備及數據轉換設備的型號及數量。）

2．支持軟件（如：（1）操作系統名稱及版本號；（2）語言編譯系統或匯編系統的名稱及版本號；（3）數據庫管理系統的名稱及版本號；（4）其他必要的支持軟件。）

四．使用說明

1．安裝和初始化（給出程序的存儲形式、操作命令、反饋信息及其含義、表明安裝完成的測試實例以及安裝所需的軟件工具等。）2．輸入（給出輸入數據或參數的要求。）

（1）數據背景（說明數據來源、存儲媒體、出現頻度、限制和質量管理等。）

（2）數據格式（如：（1）長度（2）格式基準（3）標號（4）順序（5）分隔符（6）詞匯表（7）省略和重復（8）控制。）（3）輸入舉例

3．輸出（給出每項輸出數據的說明。）

（1）數據背景（說明輸出數據的去向、使用頻度、存放媒體及質量管理等。）（2）數據格式（詳細闡明每一輸出數據的格式,如:首部主體和尾部的具體形式。）（3）舉例

3．出錯和恢復（給出：（1）出錯信息及其含義（2）用戶應采取的措施，如修改、恢復、再啟動。）

4．求助查詢（說明如何操作。）

五．運行說明

1． 運行表 [列出每種可能的運行情況,說明其運行目的.] 2． 運行步驟 [按順序說明每種運行的步驟,應包括:]（1）運行控制

（2）操作信息（（1）運行目的（2）操作要求（3）啟動方法（4）預計運行時間（5）操作命令格式及說明（6）其他事項。）

（3）輸入/輸出文件（給出建立和更新文件的有關信息，如：（1）文件的名稱及編號（2）記錄媒體（3）存留的目錄（4）文件的支配（說明確定保留文件或廢棄文件的準則，分發文件的對象，占用硬件的優先級及保密控制等。）（4）啟動或恢復過程

六．非常規過程

（提供應急或非常規操作的必要信息及操作步驟，如出錯處理操作、向后備系統切換操作以及維護人員須知的操作和注意事項。）

七．操作命令一覽表

（按字母順序逐個列出全部操作命令的格式功能及參數說明。）

八．程序文件（或命令文件）和數據文件一覽表（按文件名字母順序或按功能與模塊分類順序逐個列出文件名稱、標識符及說明。）

九．用戶操作舉例

第三篇：軟件開發管理流程

軟件開發管理流程

根據我公司目前工作現狀，開發管理流程涉及到三個方向的工作管理；一是全新項目開發整體流程；二是二期項目開發管理流程（項目已部分上線，二期進行其它公司或模塊上線）；三是維護工作管理流程；

一、升級項目流程

針對我公司現有的BSP項目，存在有些省份的BSP項目存在部分上線而對于后期需要繼續上線其他部分的情況，提出以下工作流程。

總體流程

計劃階段－》需求分析階段－》軟件開發階段－》測試階段－》部署上線—》驗收完成（一）計劃階段

制定整體開發計劃，計劃體現整個開發周期，包括需求、編碼、測試周期以及資源要求；

（二）需求分析階段

修訂需求版本，提供需求說明書，并提出需求評審申請。

評審：發起需求評審的同時提交評審資料至項目管理部—》項目管理部給相關

人員發放資料并通知評審安排--》記錄評審結果（需整改時整改之后可再次評審）--》確定需求版本。

（三）軟件開發階段

編碼開發前：開發環境搭建，其中包括遷出代碼最新版本，從線上復制出數據庫（或者導出基礎數據庫表數據）；其目的為開發環境與正式環境保持一致，為上線前的部署做好準備。

編碼開發中：開發組長對整個開發過程做好監控，保證質量的同時保證進度；并且要求開發人員做好工作記錄；加強團隊的協作與溝通。

編碼開發完：提交相關資料（操作手冊、部署文檔：sql腳本、代碼文件路徑記錄、流程文件路徑記錄），組長整理部署文檔并且提交測試申請；部署文檔要求寫明部署步驟及部署內容及相應注釋；

（四）測試階段

測試組長根據測試申請中的測試內容安排測試。測試環境模擬線上測試環境，根據部署文檔進行部署，并且記錄所有補丁包。測試過程中開發人員在修改bug的同時需要維護部署文檔。

（五）部署

部署人員根據部署文檔中描述的步驟部署系統。完成之后實施人員安排驗收。

二、全新項目開發管理流程

總體流程

計劃階段－》需求分析階段－》軟件開發階段－》測試階段－》部署上線—》驗收完成(一)計劃階段

項目計劃草案和風險管理計劃作為第一步，確定、分析項目風險并確定其優先級，還要制定風險解決方案。本階段的目的是確立產品開發的經濟理由。當確定開發之后則制定軟件開發計劃、人員組織結構定義及配備、過程控制計劃。

? 項目計劃草案

項目計劃草案應包括產品簡介、產品目標及功能說明、開發所需的資源、開發時間和里程碑。

? 風險管理計劃

就是把有可能出錯或現在還不能確定的東西列出來，并制定出相應的解決方案。風險發現得越早對項目越有利。

? 軟件開發計劃

軟件開發計劃的目的是收集控制項目時所需的所有信息，項目經理

根據項目計劃來安排資源需求并根據時間表跟蹤項目進度。項目團隊

成員根據項目計劃以了解他們的工作任務、工作時間以及他們所依賴的其他活動。

項目管理培訓

可將計劃分成總體計劃和詳細計劃，總體計劃中每個任務為一個里

程碑，詳細計劃中必須將任務落實到個人。

軟件開發計劃還應包括產品的應收標準及應收任務（包括確定需要

制訂的測試用例）。

? 人員組織結構定義及配備

常見的人員組織結構有垂直方案、水平方案、混合方案。垂直方案

中每個成員充當多重角色。水平方案中每個成員充當一到兩個角色。

混合方案則包括了經驗豐富的人員與新手相互融合。具體選擇根據人

員實際技能情況進行選擇。

? 過程控制計劃

過程控制計劃的目的是收集項目計劃正常執行所需的所有信息，用來

指導項目進度的監控、計劃的調整，確保項目按時完成。

(二)需求分析階段

需求分析階段的目的是在系統工作方面與用戶達成一致。

（1）軟件需求規約

詳細說明系統將要實現的所有功能。

（2）用戶界面原型

可以有三種表示方法：圖紙（在紙上）、位圖（繪圖工具）、可執行文件（交互式）。

（三）軟件開發階段

本階段從物理上實現目標系統。采用了面向對象方法。

（1）軟件架構

說明軟件的組織結構、部署結構及運行環境。

（2）功能設計

定義功能點之間的關聯。

（3）數據庫設計

定義數據庫表之間的關聯和各個表的字段。

（4）編碼和單元測試

按照設計文檔進行編碼，每完成一個模塊應進行單元測試。

（5）集成系統

按軟件組織結構的要求將各個子模塊組合起來。

（四）測試階段

測試的目的是在發布之前找出程序的錯誤。包括：核實每個模塊是否正常運行（參考設計文檔）、核實需求是否被正確實施（參考需求文檔）。

（1）測試計劃

收集和組織測試信息，為測試工作提供指導。

（2）測試數據

盡量使用真實數據。

（3）測試報告

記錄測試結果，詳細描述問題，提出解決辦法。

（4）用戶操作手冊

（五）管理軟件開發過程

有以下幾方面地工作：

（1）組織會議

討論會議、總結會議等。

（2）評審程序

對各個階段的工作結果進行審核等。

（3）協調人員

（4）監控進度

軟件項目開發流程

第一個步驟是市場調研，技術和市場要結合才能體現最大價值。

第二個步驟是需求分析，需求人員出需求分析說明書。發起需求評審申請，項目管理部組織開發團隊進行評審；

評審：發起需求評審的同時提交評審資料至項目管理部—》項目管理部給相關人員發放資料并通知評審安排--》記錄評審結果（需整改時整改之后可再次評審）--》確定需求版本。

第三個步驟是概要設計，將系統功能模塊初步劃分，并給出合理的研發流程和資源要求。按照公司現狀，使用快速原型設計方法完成概要設計就可以進入編碼階段了，通常采用這種方法是因為涉及的研發任務屬于新領域，技術主管人員一上來無法給出明確的詳細設計說明書，但是并不是說詳細設計說明書不重要，事實上快速原型法在完成原型代碼后，根據評測結果和經驗教訓的總結，還要重新進行詳細設計的步驟

第四個步驟是詳細設計，這是考驗技術專家設計思維的重要關卡，詳細設計說明書應當把具體的模塊以最‘干凈’的方式提供給編碼者，使得系統整體模塊化達到最大；一份好的詳細設計說明書，可以使編碼的復雜性減低到最低。

第五個步驟是編碼，開發人員需嚴格按照編碼規范及需求文檔編碼，編碼時不同模塊之間的進度協調和協作是最需要小心的，也許一個小模塊的問題就可能影響了整體進度，讓很多程序員因此被迫停下工作等待，這種問題在以前的開發過程中都出現過。編碼時的相互溝通和應急的解決手段都是相當重要的。項目組長需提高對開發過程中問題的管控能力。盡量避免重大問題，提高工作效率。

第六個步驟是測試，測試有很多種：按照測試執行方，可以分為內部測試和外部測試；按照測試范圍，可以分為模塊測試和整體聯調；按照測試條件，可以分為正常操作情況測試和異常情況測試；按照測試的輸入范圍，可以分為全覆蓋測試和抽樣測試。總之，測試同樣是項目研發中一個相當重要的步驟。

第七個步驟是部署，搭建部署環境，按照部署方案進行部署，完成后驗收測試；

第四篇：軟件開發項目管理（范文）

管理目標

1、所有關系人清晰明確地了解項目的需求和期望，努力做到滿足項目所有關系人的不同需求；項目關系人包括：項目團隊成員和項目團隊外(內部/外部客戶，內部/外部合作伙伴，經銷商/客戶等)。

2、項目管理三要素平衡（時間/成本/質量），即開發項目按需按時按質的完成。

3、目標：功能滿足需求，設計支持變化，開發快速迭代，成果持續交付。

執行概述

1、建立有效的工作流程保證項目的順利進行，初期使用傳統RUP過程，引入部分敏捷方法，團隊磨合完成后逐步實現敏捷開發全流程管理。

2、明確項目目標，制定具有可行性的項目計劃，有效明確的分解項目需求。

3、跟蹤設計/開發/測試/回歸/發布全流程，推動項目按預定計劃執行。

4、解決項目過程中出現的問題和沖突，一般集中在需求不明/工作量或時長/開發難度/跨部門協調等幾個方面。

5、調動開發團隊的積極性，創造力，推動團隊成員在項目過程中的學習成長。

6、風險識別、風險控制以及風險的預案。

項目管理

1、需求階段

對項目進行技術可行性分析、技術評估、成本評估以及風險評估。與需求提出方的代表進行需求討論，明確項目的目標、價值。確定項目范圍、功能及優先級。

組建項目團隊，特別要搞清楚項目的關鍵人。項目啟動會議，相關的關系人都必須參加。

2、設計階段

根據確認后的軟件需求規格說明書，制定項目進度計劃，工作任務分解(WBS)；資源申請，項目涉及到的開發資源、測試資源、設計資源(包括人員和軟硬件資源)；數據庫設計；系統設計；文檔(包括系統用例、Demo、測試用例等)；評審會議。

設計階段結果交付一般為系統用例/系統原型/系統設計文檔(概要設計和詳細設計)/數據庫設計文檔等。

該階段交付成果需要進行評審。

3、執行階段(開發和測試)準備開發環境、測試環境。跟蹤，推動項目按計劃進行。

項目成員以日報/項目負責人以周報的形式通報各關系人當前項目的進展情況。按里程碑對階段成果進行評估，以確保該階段完成的質量。代碼審核，包括CS審核、SQL審核、WEB審核等。對需求變更進行控制管理。

測試階段BUG響應及改進、收集反饋意見。對項目風險進行管理。

4、發布階段

包括制定項目發布計劃，用戶培訓，發布上線。

5、試運行階段

數據監控(日志、服務器狀態)，根據監控出現的問題，及時進行處理，改進性能問題，特定情況執行補丁升級。

6、收尾階段

產品交付，項目總結會。

常見問題

1、開發時間的估算

制定項目計劃時，需要估算每個任務所需的時間，其中主要是開發任務中模塊的分配和時間估算，在公司現有的技術框架下，開發人員主要的工作是投入在具體的業務邏輯實現上。通常單個模塊開發時間取決于以下因素：

1、負責模塊的業務邏輯的復雜程度。

2、開發人員的技術水平和對項目所在應用的熟悉程度(包括對框架和應用的熟悉程度)。

3、模塊技術實現上是否存在難點，所謂的技術難點定義是：在現有系統中還未實現的、開發人員自身未沒接觸過的技術。對于這樣的難點，開發者沒有相關的代碼可以參考，自己也沒有經驗，所以需要投入學習時間用于研究解決。

模塊分配和開發時間估算的步驟：

1、在劃分好模塊后，首先項目管理人員預先估算各個模塊所需要的開發時間。

2、召集所有開發人員，討論模塊的分配和開發時間估算。將劃分好的模塊，分配給開發人員，如狀況允許可允許開發人員自主選擇以提高開發人員的主動性和參與性。分配模塊的時為確保開發的速度和質量，基本原則如下：

A、類似的模塊由同一人負責開發，比如用戶信息的增刪改應由同一開發者負責。這樣開發者對相關邏輯會比較熟悉，代碼/接口的定義也會相對明確，溝通的成本低，相應可以降低功能實現的缺陷概率。

B、技術難度較大的模塊由技術水平比較高的人負責。C、業務邏輯比較復雜的由對業務邏輯比較了解的人負責。

3、模塊分配完成后，開發人員評估自己負責開發的模塊所需要的時間。在此過程中應

4、對開發人員估算的時間進行確認。在確認過程中作為，項目管理者將預估時間和開與開發者討論每個模塊的技術實現細節，使時間的估算更加準確。發人員估算時間進行比較。那些差異較大的，與人員探討其中的緣由。對于時間周期比較長的任務，將任務拆分為更小的子任務，每個任務的完成時間為8-24工時，消除時間周期較長的任務，避免不確定性影響項目的進度。

2、CodeReview CodeReview是保證項目中代碼質量非常重要的一個環節，在這一環控制不嚴往往是測試后出現大量bug的主因，有時甚至導致返工；關于CodeReview執行，首先應有編碼規范和代碼審查規范。通過這兩個文檔來規范開發人員的代碼實現，代碼編寫者必須要嚴格按照規范來進行；代碼審核者根據這些標準來CodeReview代碼，同時在CodeReview過程中需要不斷完善該文檔。

CodeReview一般可按以下步驟實施：

1、檢查開發者的代碼實現是否遵循了編碼規范。

2、從代碼的易維護性、可擴展性角度考察代碼的質量，提出修改建議。

3、代碼編寫者和代碼審核者坐在一起，由代碼編寫者按照UseCase依次講解自己負責的代碼和相關邏輯，代碼審核者在此過程中可以隨時提出自己的疑問，同時積極發現隱藏的bug，對這些bug記錄在案。

4、代碼講解完畢后，代碼審核者給自己安排幾個小時再對代碼審核一遍。代碼需要檢查Bug。同時全面兼顧，確保代碼整體上結構優良；審核完畢后，代碼審核者編寫“代碼審核報告”記錄發現的問題及修改建議，提交給相關人員。

5、代碼編寫者根據“代碼審核報告”給出的修改意見，修改好代碼，有不清楚的地方可積極向代碼審核者提出。

6、代碼編寫者bugfixed完畢之后給出反饋。

7、代碼審核者把CodeReview中發現的有價值的問題更新到“代碼審核規范”的文檔中，對于特別值得提醒的問題可群發email給所有技術人員。

3、需求變更管理

需求變更管理也是項目管理中最重要的一個環節，對需求變更管理的有效性將直接影響對待需求變更的正確態度：

1、需求變更是不可避免的。

2、需求變更要必須被管理。

3、積極發現引起變更的因素，促使變更盡可能早的出現，減低變更帶來的風險。需求變更管理的目標：

1、相關的干系人必須清楚地了解發生的變更。

2、變更處于有效的管理中。

3、盡量降低變更帶來的風險。

通過制定需求變更的流程，確保項目中的需求變更有效地進行，實現上述的目標。需求變更流程：

1、確定需求的基準線。將以UserCase作為需求基準線，在UserCase確認之后的任項目的成功與否。何需求改變，都需要走需求變更流程。

2、項目管理者接收到需求變更的要求。需求變更的提出者可以是項目中的任何人包括產品經理、市場人員、開發人員、測試人員等。

3、項目管理者評估該需求變更。針對接收到的需求變更的要求，召集相關人員討論該需求變更的合理性、可行性，實施的代價以及對項目的影響。項目管理者對項目的成功與否負有主要的責任。需求變更的決策應由項目管理者做出。

4、需求變更確認后，由專人將生成需求變更單記錄下來，通知給項目中所有關系人。

5、確定變更的負責人。承擔需求變更的具體工作，比如基線控制，對需求變更的記錄，并通知相關人員。

6、相關人員接收到確認的需求變更后，需求分析人員修改需求說明書和UserCase的相關內容。測試人員修改測試用例的相關內容。開發人員修改代碼中的相關部分。

7、按照變更后的計劃實施項目，并進行檢查，跟蹤，對變更后的實施反饋和可能出現的問題及時溝通和處理。

8、需求凍結。項目越到后期，需求變更對項目的影響就越大，所以在一定時候要進入需求凍結階段，不再接收新需求或需求的變更。

4、風險管理

影響項目成敗的因素涉及方方面面，并且風險伴隨著項目的始終，是客觀存在的，風險引起的負面后果集中體現在進度延后、成本超支、質量不達標等方面，常見風險如下：

1、目標以及需求不明確

為了市場競爭或內部管理決策的需要，業務部門提出的需求往往要求的時間比較緊迫，需求的提出大多停留在幾張紙或口頭的傳達上，沒有正式的業務需求文檔，在沒有明確的需求范圍的情況下，有時為了迎合業務部門的口味匆匆開工，過程中用戶不斷地提出新的想法，技術人員開始疲于奔命和應付，很難保證項目的進度和質量，也難以取得業務部門的認可。

在項目的前期一定要采取相應的手段或措施，與業務部門共同明確項目目標、需求范圍，充分考慮現有的時間和資源約束，將需求排定優先級，對于關鍵的需求優先實現，其他輔助性的根據過程中的具體情況進行滾動式計劃，并取得業務部門的書面確認。在此過程中要注重挖掘用戶的隱性需求，可以通過引導、系統原型等手段讓用戶在前期充分暴露自己的想法和需求。

2、項目目標擴大以及需求變更

在有了明確的目標和需求范圍的情況下，需求的變更還是不可避免的，業務部門在看到具體系統的真實雛形之后，源源不斷地要求、新想法隨之產生，如果不對此加以控制，新的需求的加入通常會影響已實現的需求，并且對項目進度和成本產生很大的影響。項目管理者針對這種情況一定要采取嚴格的變更控制流程，不能礙于面子，否則最終的結果往往是出力不討好。針對用戶提出的新需求，按照正式流程提出變更申請，組織相關團隊成員進行分析及評估，作為是否實施的依據，變更控制負責人根據分析結果判斷是否批準，如果批準，那項目組可以安排實施，否則，正式拒絕用戶的請求。

前期的需求討論要詳細、充分。需求文檔中需求的范圍要明確、功能描述要清楚。找出項目中需求的決策者(通常會是產品經理、相關職能主管、客戶)，所有的需求要經過他們的認可。客戶在項目過程中的全程參與有助于降低此類風險。需求討論、需求確認、UserCase確認、測試階段的客戶驗收等環節，都要要求客戶參與。在發生需求變更時，嚴格按照需求變更流程執行。在分析設計階段的中的確認和評審也是降低此類風險的重要手段。

3、代碼質量風險

質量風險主要指開發代碼的質量。在制定項目計劃時，對開發時間的評估要盡可能的合適。合理的開發時間對開發質量的影響很大。開發人員為了趕進度在比較緊張的時間需要完成指定的任務，可能就存在很大的開發質量問題。在編碼前，開發人員要對框架熟練掌握；一份好的系統設計文檔對指導開發非常重要。

往往有這樣一種情況，每個團隊成員按照項目計劃報告進度都是100%完成，但一到最后系統交互測試或集成的時候就會發現一大堆問題。這需要在項目實施過程中采取有效的措施來規避風險，通常的做法有同行評審，比如概要設計完成之后，邀請其他項目組的技術專家進行技術評審以發現架構設計問題；管理評審，通過組織級的質量審計看產品以及實施過程是否滿足質量要求；代碼走查，在編碼過程中加入至少一次的代碼走查，排查不符合規范或性能要求的代碼，走查通常能夠發現50%-70%的錯誤；每日構建，這是一種非常有效的方法，可以避免把各部分的集成問題拖到最后，并且能夠及時發現相應的錯誤，日構建一般在項目的中后期開始，每天自動從版本服務器上獲取源代碼進行自動編譯和測試。

4、人員技能和資源的不足

項目實施過程中由于人員技能欠缺造成的進度延后和軟件質量問題并不少見，一個熟練的技術人員完成同樣一個任務需要3天，但一個新手可能就需要7-10天。項目管理者應該在前期就分析清楚項目所要采用的技術以及相應的人員技能要求，針對不同的角色，及時采取相應的技能培訓，以保證項目的順利實施。開發過程中遇到技術難題，導致開發時間延遲或者需求不得不發生變更。在項目開始前的技術評估階段，明確技術難點，提前安排人員進行攻克。如果在可預期的時間內無法解決，如果可以，將向需求提出方要求變更需求或尋找可替代方案。這樣的風險應該在項目的前期階段就應該解決在萌芽狀態來避免這樣的風險在后期或中期出現。

5、缺乏良好的團隊協作

軟件項目實施屬于知識型，要發揮團隊成員的創造力，不同于制造業計件生產，各模塊最終要集成在一起形成一個有機的整體，這就需要各小組之間的密切配合，界定清楚工作界面及接口關系，并在實施過程中持續地溝通交流和共享，首先團隊要融為一體，產出的軟件才能融為一體。這是一個團隊的軟實力，團隊之間的協作好壞也將是個潛在的風險問題，在項目啟動和團隊組建的時候就應該加以規避這樣的風險出現。

6、項目會議

組織會議是項目執行過程中一項非常重要的工作任務，項目過程中很多重要的決定都是在會議中做出的，不成功的會議會對項目本身造成了不好的影響。

不成功的會議通常表現為如下形式：

1、會議氛圍不好，參與者發言不踴躍；

2、會議討論常常偏離主題；

3、會議沒有取得預期的結果；

4、會議時間常常一拖再拖。

這些不成功的會議最終的結果就是：既浪費了大家的寶貴時間又沒有達到會議的目的，很多人都對這樣的會議都有抵觸情緒，對此也是深惡痛絕。以下是組織會議時應該注意的問題，也可看作組織會議的最佳實踐。在列出最佳實踐之前有三點我們必須要清楚：

1、會議是否會取得成功很大程度上取決于會議的組織者。只有組織得有力，會議才有可能取得成功，這是會議成功的充分條件。

2、會議的組織者和參與者的想法通常是不一致的，有時候甚至會大相徑庭。所以不要希望會議的參與者和你一樣，對會議有著如此的期待，對大多數參與者而言，在會議中他只是一個發表想法的人，他不用對會議的成功承擔責任。

3、以下十一條最佳實踐是形式上的約定，具體的實施可以根據實際情況來做。組織會議的十一條最佳實踐：

1、只有需要開會時才開會。有時候兩三個人單獨小范圍溝通會更加有效。

2、提前發出會議議程，以便會議參與者知道他們來做什么。

3、請對人很重要，不要把非必要的人召來開會，當然也不要漏掉那些關鍵人物。在確保必要人物都在的情況下一次會議參與者越少效果越好。

4、提前預約參與者的時間，以確保他們能按時到場。

5、會議的開場很重要。會議組織者要在開始前做好幾件事情。通常我建議有幾點要在開場時說： A、再一次強調會議的目標，我們來做什么。

B、強調會議的主題與基調。比如：本次會議是一個需求確認會，而非需求討論會，主要是討論做還是不做以及告知大家我們要做什么，而不要把太多的精力放在討論如何做上面。

C、說明一下會議的規則。如要發言，請舉手；不要有小圈子討論；不要打斷別人的講話，等別人說完你再說等等。

6、會議過程中時刻注意引導和控制會議，以確保會議按照目標進行。一次會議的氛圍是否良好，討論是否充分，好的引導至關重要。比如多提一些開放式的問題。

7、會議記錄很重要，把一些結論和有價值的內容記錄下來，這些是本次會議的重要成果之一。

8、會議要有結論。我們常在會議上聽到有人說：“大家討論了這么半天，結論呢？”。沒有結論的會議是沒有意義的。

9、會議后別忘發會議紀要，以及一些Action，什么人什么時候做什么。

10、會議后的action執行情況的反饋很重要。反饋是對會議參與者的尊重，同時也告知了會議的效果。否則會讓大家感覺到這是一個可無可無的會議，大家以后參與的積極性也會降低。很多會議往往都不注意這一點。

11、按時結束的會議會受到所有人的歡迎。

第五篇：軟件開發管理規定

軟件開發管理規定

第一條 第二條 第三條 為規范自有軟件研發以及外包軟件的管理工作，特制定本制度。本制度中軟件開發指新系統開發和現有系統重大改造。

本制度中自行開發是指主要依賴公司自身的管理、業務和技術力量進行系統設計、軟件開發、集成和相關的技術支持工作，一般僅向外購置有關的硬件設備和支撐軟件平臺；合作開發是公司與專業IT公司（合作商）共同協作完成IT應用的項目實施和技術支持工作，一般形式是公司負責提供業務框架，合作商提供技術框架，雙方組成開發團隊進行項目實施，IT系統的日常支持由IT管理小組和合作商共同承擔，IT管理小組負責內部（一級）支持，合作商負責外部（二級）支持；外包開發是指將IT應用項目的設計、開發、集成、培訓等任務承包給某家專業公司（可以是專業的IT公司或咨詢公司等），由該公司（承包商）負責應用項目的實施。

第四條 軟件開發遵循項目管理和軟件工程的基本原則。項目管理涉及立項管理、項目計劃和監控、配置管理、合作開發管理和結項管理。軟件工程涉及需求管理、系統設計、系統實現、系統測試、用戶接受測試、試運行、系統驗收、系統上線和數據遷移。

第五條 除特別指定，本制度中項目組包括業務組（或需求提出組）、IT組（可能包括網絡管理員和合作開發商）。

第二節 立項管理

第六條 提出開發需求的信息技術部門參與公司層面立項，進行立項的技術可行性分析，編寫《立項分析報告》，開展前期籌備工作。《立項分析報告》應明確項目的范圍和邊界。

第七條 第八條 應用系統主要使用部門將《立項分析報告》上交公司進行立項審批。《立項分析報告》得到批準后，成立項目組（如果是外包開發，則成立外包商項目組；如果是合作開發，則與外包商共同成立合作開發項目組，以下統稱“項目組”），項目組應包括業務組（由公司相關業務部門組成）和IT組（自行開發為辦公室網絡管理員；外包開發為外包商成員；合作開發為網絡管理員和外包商成員）。公司委派一名員工負責監督項目的進度，進

第九條

第十條

第十一條第十二條第十三條第十四條第十五條第十六條第十七條行項目管理工作，確保開發能及時完成并能滿足業務需要。項目組人員的選擇應滿足項目對業務及技術要求，項目組人員應有足夠的業務和IT技術方面的專業知識來勝任項目各方面的工作。

第三節 需求分析

立項后業務組對用戶需求進行匯總整理，出具《業務需求說明書》，并確保《業務需求說明書》中包含了所有的業務需求。經系統使用部門審批確認，作為業務需求基線。

IT組在獲得《業務需求說明書》后，提出技術需求和解決方案，并對系統進行定義，出具《系統需求規格說明書》。《系統需求規格說明書》需詳細列出業務對系統的要求（界面、輸入、輸出、管理功能、安全需求、運作模式、關鍵指標(KPI)等）。《系統需求規格說明書》需要由業務組提交給相關業務流程負責人確認。

對于合作開發的項目，當業務需求發生變更時，業務組應提交《需求變更申請》，IT組組長審批后交給合作開發商實施。

項目組應對需求變更影響到的文檔及時更新。

第四節 項目計劃和監控

軟件開發采用項目形式進行管理。項目經理負責整個項目的計劃、組織、領導和控制。

需求分析過程中，項目經理組織制定詳細的《項目計劃書》，包括具體任務描述和項目進度表等。

在項目的各個階段，業務組組長和IT組組長需配合項目經理制定階段性項目計劃。業務組組長和IT組組長需配合項目經理對項目計劃執行情況進行監控，確保項目按計劃完成。

項目計劃需要變更時，項目經理填寫《項目計劃變更說明》，并提交公司主管領導審批，通過審批后，交給業務組組長和IT組組長執行。

第五節 系統設計

系統設計應分為概要設計和詳細設計，系統設計要遵循完備性、一致性、第十八條 第十九條

第二十條

第二十一條第二十二條第二十三條第二十四條第二十五條第二十六條第二十七條第二十八條第二十九條擴展性、可靠性、安全性、可維護性等原則。

在系統設計階段中，用戶應充分參與，確保系統設計能滿足系統需求。項目組進行詳細設計，出具《設計說明書》和《單元測試用例》。《設計說明書》中需要定義系統輸入輸出說明和接口設計說明。公司主管領導組織相關人員對概要設計進行評審，出具《設計評審報告》。業務組組長和IT組組長應參加此評審并對評審意見簽字確認。

設計評審均以《業務需求說明書》和《系統需求規格說明書》為依據，確保系統設計滿足全部需求。

對已確認通過的系統設計進行修改需獲得管理部門、業務組組長和IT組組長的審批后方可進行。

對系統設計的修改的文檔須由文檔管理人員進行歸檔管理。

第六節 系統實現

項目組根據《設計說明書》制定系統實現計劃，并提交項目經理對計劃可行性進行審批。

系統實現包括程序編碼、單元測試和集成測試。

項目組保證開發、測試和生產環境獨立，為各環境建立訪問權限控制機制，并明確項目成員的職責分工。對開發環境、測試環境與生產環境在物理或邏輯方面應該做到隔離；如果環境的分隔是通過邏輯形式實現的，應定期檢查網絡設置。項目組對已授權訪問生產環境的人員進行詳細記錄，并對該記錄進行定期檢查，確保只有經授權的人員才能訪問到生產環境。

項目組進行單元測試和集成測試，測試人員簽字確認測試結果。

第七節 系統測試和用戶測試

項目組制定《系統/用戶測試計劃》，并提交項目經理對計劃可行性進行審批。

《系統/用戶測試計劃》必須定義測試標準，并明確各種測試的測試步驟和需要的系統設置要求。

項目組向數據擁有部門申請獲取測試用業務數據的使用權，對獲取的數據進行嚴格的訪問控制，確保只有相關項目人員才能訪問及使用。

第三十條 項目組負責測試數據準備，測試用數據要足夠模擬生產環境中的實際數據。對已評定為敏感信息的數據進行敏感性處理和保護。

第三十一條 IT組或合作開發商建立測試環境進行系統測試。在系統測試中對新系統內部各模塊之間的接口和與其他系統的接口進行充分測試。出具《系統測試報告》，測試人員簽字確認測試結果。

第三十二條 系統測試通過后，IT組配合業務組建立用戶測試環境，業務組根據用戶測第三十三條

第三十四條 第三十五條 第三十六條 第三十七條 第三十八條 第三十九條 第四十條 試用例進行用戶測試，出具《用戶測試報告》，業務組組長和IT組組長應在用戶測試報告中簽字確認。

項目組完成系統幫助文檔（其中包括《用戶操作手冊》和《安裝維護手冊》）。凡涉及應用系統的變更，應對系統幫助文檔及時更新。

第八節 試運行

系統主要使用部門根據項目規模及影響決定試運行策略。

項目組制定《試運行計劃》，并制定試運行驗收指標，上報公司主管領導審批。《試運行計劃》中應包含問題應對機制，明確問題溝通渠道和職責分工。

項目組聯合試運行單位進行相關系統部署工作，準備培訓資料，對相關用戶和信息技術人員進行培訓。用戶培訓的完成度應為實施后評估的指標之一。

項目組根據《試運行計劃》進行系統轉換和數據遷移。系統轉換前，檢查系統環境，確保運行環境能滿足新應用系統的需要。系統轉換時必須詳細記錄原系統中的重要參數、設置等系統信息，并填寫試運行報告相關內容。系統參數、設置的轉換工作作為系統上線的驗收的評估指標之一。

數據遷移前，應制定詳細的《數據遷移計劃》，《數據遷移計劃》中應包含遷移方案、測試方案、數據定義，新舊數據對照表、遷移時間、回退計劃等信息。數據遷移計劃需經項目經理和主管領導簽字審批。

數據遷移后，項目組對數據遷移的完整性和準確性作出檢查，出具《數據遷移報告》，其中包括數據來源、轉換前狀態、轉換后狀態，數據遷移負責人、對完整性檢查情況、對準確性檢查情況等內容。各相關部門驗收轉換結果后在該報告上簽字確認。

系統轉換和數據遷移由試運行單位業務部門和公司主管領導共同監督并進行驗收。

第四十一條 系統轉換和數據遷移驗收通過后，正式啟動試運行。在試運行過程中，試運行單位辦公室把系統運行情況（系統資源使用，反應速度等）記錄到試運行報告中。必要時，項目組應根據系統運行情況對應用系統進行優化。

第四十二條 試運行達到試運行計劃規定的終止條件時，項目組編寫《試運行報告》。此

第四十三條 第四十四條 第四十五條 第四十六條 第四十七條 第四十八條 第四十九條 報告應由項目組和試運行單位簽字確認，并提交公司主管領導審閱。公司主管領導審閱試運行結果，決定試運行結束或延期。

第九節 系統驗收

系統主要使用部門及信息技術部門聯合組成獨立系統驗收小組，也可授權原項目組作為驗收小組。驗收小組從功能需求及技術需求層面對系統進行綜合評估。

驗收小組應根據驗收情況整理形成《系統驗收報告》提交系統主要使用部門和信息技術部門審閱。

系統主要使用部門和信息技術部門負責人根據系統測試、試運行情況簽署驗收意見。

第十節 系統上線

系統上線應遵循穩妥、可控、安全的原則。通常情況下，系統上線包含數據遷移工作。

項目組制定《系統上線計劃》，上報公司主管領導審批。在上線計劃得到批準后才能開始部署上線工作。

《系統上線計劃》內容應包括但不限于：

1、部署方式和資源分配（包括人力資源及服務器資源）；

2、上線工作時間表；

3、上線操作步驟以及問題處理步驟；

4、項目階段性里程碑和成果匯報（項目執行狀態的審閱、進度安排等）；

5、數據遷移的需求和實施計劃；

6、完整可行的應急預案和“回退”計劃；

7、用戶培訓計劃（包括：培訓計劃、培訓手冊、培訓考核等）；

8、公司下發的系統標準參數配置。

第五十條 上線單位在上線初期需加強日常運行狀態監控，出現問題時應及時處理，對重大問題應啟動緊急預案。

第五十一條 在完成上線后要填寫《系統驗收評估報告》，上報公司項目組匯總整理。第五十二條 第五十三條

第五十四條 第五十五條 第五十六條 第五十七條 第五十八條 第五十九條 第六十條

第六十一條 第六十二條 第六十三條 第六十四條 《系統驗收評估報告》內容包括：數據準確性、系統性能及穩定性、接口問題、權限問題、業務操作影響度、問題處理情況、備份、批處理等。

上線單位管理層要對《系統驗收評估報告》進行審批簽字。

公司主管領導批準結項后，業務組和IT組將整理的文檔提交各自部門統一管理。

第十一節 合作開發管理

合作開發商的選擇應遵循公司相關規定，合作商資質認定參見第三方管理制度。

合作開發商必須遵循公司《軟件開發管理制度》。

項目經理同合作開發商明確規定項目變更的范圍和處理方式，重點關注需求和設計變更。

項目經理負責監控合作開發商的項目管理及軟件開發活動。合作開發商應按計劃定期向項目經理報告進展狀態，并提交階段性成果文檔。發生重大問題時，合作開發商需及時向項目經理匯報。

IT組組長派專人監控合作開發商的質量保證過程。項目組同合作開發商商定驗收的標準和方法。以上各要求需要在開發合同中明確。

第十二節 外包開發管理

立項申請得到公司主管領導的審批后，選定開發商，簽訂外包開發合同。項目經理負責監控外包開發商的項目管理及軟件開發活動。外包開發商應按計劃定期向項目經理報告進展狀態，并提交階段性成果文檔。發生重大問題時，外包開發商需及時向項目經理匯報。

項目經理監控外包開發商的質量保證過程。項目組同外包開發商商定驗收的標準和方法。第六十五條 以上各要求需要在開發合同中明確。