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

附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）啟動或恢復過程

六．非常規過程

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

七．操作命令一覽表

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

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

九．用戶操作舉例

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

軟件開發過程管理規范

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

一、總則.................................................................................................................................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.上述工作完成后，提交項目評估委員會總結會審批后公布。

第三篇：山東08規范軟件開發計劃

山東08規范軟件開發計劃

本軟件是從江蘇提速版本基礎之上根據現有山東地區軟件進行調整。

軟件需要更改的地方我初步填寫了《需求表》，請各位針對自己的工作重點，結合相應的軟件進行分析和代碼設計，并給出時間計劃表

1)軟件基本信息修改及報表更改。

本部分工作由葛亮完成（吳耀武輔助）。具體內容包括：

軟件基本信息的調整：比如顯示上的江蘇更改為山東。以及模板的調整

山東報表的打印。

2)計價程序以及管理費和利潤設置。

本部分工作由陸向榮完成。具體內容包括計價程序相關變量的設置調整和管理費利潤費率按山東需求進行調整。

3)其他項目，規費，稅金項目等界面調整和修改。

本部分工作有張志浩完成。主要將湖南的相關界面及操作等東西搬過來。同時指導招投標接口的更改工作。

4)招投標接口的更改，采用原有山東的招投標接口。

本部分工作有強浩完成。主要任務是將江蘇地區的招投標接口更改為山東接口。另山東現有一個接口規范（試行）及萊蕪有一個接口文件，請一并考慮在內。相關文檔見《山東省建設工程造價計價軟件數據接口標準（試行）》和《萊蕪市建設工程計價數據交換規范》。

以上為現有的初步分工，請各位參考自己已有工作量進行計劃，回復我計劃時間和具體工作內容。對分工任務不明確的請和我聯系，以便調整。

第四篇：我總結的一些軟件開發規范

我總結的一些軟件開發規范

作者：田進恩

為了提高軟件開發質量，降低開發周期，增強代碼的可重用性和易讀性，使軟件便于維護，開發人員間便于交流和協作，特總結出開發規范，以為參考。

一． 原則：

1． 軟件工程化 2． 模塊化

3． 能簡單不復雜 4． 強調團隊協作 5． 強調創新和特色

二． 具體規范：

1． 命名規范

命名應盡量使用匈牙利命名法，變量名或函數名中使用大寫字符來區分各個部分，以便于記憶和閱讀。如bPatchMinute, DeleteDirInfo()。全局(包括類中的)變量用長名字，局部變量用短名字。

類成員變量前一般應加上m_，全局變量加上g_，僅與本模塊有關的變量加上l_,緊接著是變量的類型。整型： n,i 長整型: l 無符號整型： u 無符號長整型：dw 字符： ch 布爾量： b 浮點數: f 雙精度浮點: d 字符串： str,lpsz,sz,p,lp,ac, 指針： p 字節指針： pb 無符號指針： pv 字符指針： lpsz 整型指針： lpn 文件指針： fp 如：

m_nTotalNum,m_strPath,m_bRcving,m_fPrice,g_lOpenDate,g_dwCardNo,lpszNameStr, lpnSysDoomType,uMsgID,m_pProgress

局部變量應盡量易懂簡潔，使用常見的變量，如

Num,nCount,i,j,k,n,len,pos, offset,nReadNum,index,nRet,ret, string,filename

臨時變量，如ltmp,ftmp,tmpStr,tempStr，函數命名也應該見名知意。如CalcAllDataStyle(),ReadDocDataFromTime(),GetIndexInfo()常見的函數

Init, OpenAll, Create_, Get_, Set_, Read_, Load_, Write_, Start_, Stop_, Check_, Test_, Fill_, Process_, Sort_, Do_, Select_, Is_, Exist_,_Ex。

宏命名和typedef定義類型應詳細，避免重復，一律為大寫，如

#define DEL_EMPTY(a){if(a){delete a;a=NULL;}} #define SUCCESS 0 #define FAIL-1

typedef struct { char lpzSource[100];char lpzTitle[100];char lpzURL[194];short nType;long npos;long nlen;}ATTBODY,*LPATTBODY;（指針前加LP）

自定義消息從WM_USER開始

#define MYAPP_MESSAGE WM_USER+0x1001

2． 代碼規范

有些不易理解的變量或函數應作注釋，難懂的代碼要有注解，在文件的開始處有該文件的用途描述。一定要保持注釋的一致性。

代碼組織要清晰，{,},(,),if,else,do,while,for,case等要對應整齊，少用空格，縮進全部用Tab鍵。變量的定義要集中，函數間要有空行分開，一個程序中的空行數目最好占8%-16%。多態函數和功能相近的函數集中放在一起。

代碼應該簡潔、清楚并講述了所發生的一切，我們的目標應該是寫出最清晰的代碼，而不是最巧妙的代碼。例如如果是MFC多文檔程序，就要嚴格按照其生成的框架寫代碼。盡量使用編譯器已經提供的函數，不必花時間另行編寫。例如系統已經有qsort函數，可直接拿來排序用。

某些公用代碼要注意多平臺易移植，最好使用標準C。

代碼的重用要仔細，要將相關的代碼也拷貝過來，注意那段代碼也許不適合你的應用場合。刪掉從來沒有用過的函數或變量，大篇幅注釋掉的代碼行也應刪除，以免使程序混亂難讀。

3． 工程文件組織規范

一個工程往往包含很多很多文件（*.h,*.cpp,*.inc,*.lib,資源文件等），向工程中加入文件或刪除工程中的文件要慎重，避免把工程損壞。工程中不起作用的文件或類應刪除，工程目錄下的非工程文件也應該移走，保持工程的清潔，避免混淆難于管理。工程文件如果很多，應歸類。

在VC環境下，建議將常用的頭文件全部放入stdafx.h中，而在每個cpp開始處嵌入stdafx.h。避免頭文件的交叉引用，如果有嚴重的交叉引用，適當使用類的聲明。

將獨立性比較強的模塊抽出來，做成DLL，控件或COM組件，該模塊可單獨編寫和測試，也增強了其可重用性。

一個比較大的工程應留有一定的消息接口或插件接口等。

工程的版本控制要嚴格，版本格式為xx.xx.xx，必要時使用Build次數或日期。高版本盡量兼容低版本的用法、數據或協議。

工程的編譯宏定義和工程參數設置應正確，每作一個新工程時應檢查工程參數是否正確。建議字節對齊方式為1字節對齊。

工程文件應經常備份，備份時注明備份日期和主要增加的功能。

4． 類組織規范

類一般有兩個文件，一個頭文件，一個實現體CPP。

類力求封裝好，嚴格區分public,private,protect等作用域，如果一個函數與本類有莫大的關系，可以作為該類的靜態成員函數，不用或少用友元函數等破壞類封裝性的方法和技巧。如果一些結構或宏僅與本類有關，可在類頭文件中定義。

類的成員變量在構造函數或初始化函數中應賦初值。指針在構造函數中賦NULL,析構時DEL_EMPTY它，以免內存泄露。

5． 用戶界面規范

有四大類型的用戶界面：對話框、單文檔界面、多文檔界面、其它界面

對話框要易用且簡潔，字體和控件的組織搭配要得體，能簡單不復雜，各控件的焦點、Tab順序等要講究，視應用場合要適當支持鍵盤。在簡潔易用的前提下，力求個性化，設計得更加友好。程序各對話框的風格要保持一致。

單文檔和多文檔界面的程序功能可以做得很強，也便于擴充和管理。其中菜單、工具欄、狀態欄等設計要有特色。菜單按一定的分類彈出，必要時設計成多套菜單，在重要的窗口或區域應能彈出右鍵，實現常見操作。工具欄上放最常用的操作按鈕，必要時動態更換按鈕。狀態欄顯示足夠多的有用信息。

消息主控在Mainframe中，單文檔的主控也可在View中，所有的對話框的彈出或非模態對話框的控制都在主控窗口中完成，具體的數據處理放在單獨的文件中或設計成類。在App類中實現Ini讀寫，各數據對象的定義和析構，全局變量的賦值和初始計算，存盤退出等。各視圖的OnDraw和GDI畫圖盡量使用內存位圖的方式，以免閃爍。

其它還有ATL，控制臺，嵌入式程序界面等，也有作為其它容器如IE中的插件等，此類程序可能不用MFC，而采用COM組件等方法實現。

6． 疑難解答和Bug調試方法

勤問、善于問。在不打擾正常工作的前提下，開發人員間應相互幫助，聚思廣益，也許你的問題或Bug就是他人的前車之鑒。

從各種途徑請求解答。專業書、教材、期刊、電子文檔以及國際標準文獻、RFC等，Internet上專業網站、論壇、專家組等。

Bug的出現總是有一定的原因的，冷靜查找，不要總是拘泥于某一個小局部，換一個想法、從另外一個角度也許讓你柳暗花明。使用一些輔助開發或調試工具，如Spy++,Process Viewer,系統監視器等。

拓寬知識面。多參閱其它編程語言、數據庫知識、編譯原理、網絡協議等，熟悉硬件設備、底層匯編、數字邏輯電路等。使用和揣摩其它軟件功能和界面，集百家之長，做出有創新意義和有特色的功能性軟件。

三． 一些習慣：

我認為比較好的習慣：

1.if(0 == GetDataType(…))比if(GetDataType(…)== 0)好，縱使誤將==寫成=，在編譯一層就會報錯。2.#define MAX_DOWNLOADNUM 20 struct DownInfo m_DownInfo[MAX_DOWNLOADNUM];在代碼中盡量不用具體的大小數值，定義成宏，便于以后維護。3.CUSTXG_CONTABLE g_lpCustCon[] = { {“數值串1”,C_ZGB,C_CUSTJBM,C_VT_FBJ,“萬”}, {“數值串2”,C_ZSZ,C_CUSTJBM,C_VT_FBJ,“萬”}, …

{“數值比例”,C_WTB,C_CUSTHQ,C_VT_FBJ,“%”} };int g_nCustNum = sizeof(g_lpCustCon)/sizeof(CUSTXG_CONTABLE);g_ nCustNum自動適應g_lpCustCon的大小。4.函數定義short GetInputType(const char * lpzInput)比short GetInputType(char * lpzInput)好，以免lpzInput在函數體中被破壞。5.協議包頭定義成：

typedef struct tagDataHeader { struct{ unsigned char Version:4;unsigned char HeaderFlag:2;unsigned char Reserved:2;//保留Bits位 }Info;long nOther;long Reserved;//保留4個字節 } DATAHEADER;定義有一定的保留字段，供以后擴充使用。6.變量在定義時賦初值，類析構時或程序退出時判斷釋放所有變量。7.編碼空間一定要充分預留，編碼時注意可擴充性。

我認為不好的習慣：

1.代碼中是“+2”,“+4”,而不是“+sizeof(short)”,“+sizeof(int)”。2.filename[40],而不是filename[MAX_PATH]。

3.GDI資源使用完后不釋放，位圖、筆刷等用完后不Select出來。這樣會將導致系統Gdi資源丟失或內存泄露。

4.大量使用無符號型變量。無符號變量在判斷時易造成錯誤，甚至死循環，盡量少用。5.使用malloc,free不使用new,delete,大量使用realloc。new,delete是規范的C++語法，通用性強，realloc易造成內存抖動。6.#define square(x)(x)*(x)宏的體應加括號，否則容易出問題，如1/square(x)將被替換1/(x)*(x)

以上僅是我總結的一些，比較少，希望能拋磚引玉，請大家補充

第五篇：供電公司軟件開發與測試驗收管理規范

某某供電公司軟件開發與測試驗收管理規范

第一條 為提高某某供電公司計算機應用軟件的開發與測試驗收管理水平，符合國網公司“SG186”軟件系統的質量體系，特制定本規范。

第二條 本規范適用于公司內部開發的應用軟件，也適用于采購定制開發的應用軟件，提供定制開發應用軟件的開發商必須遵循本規范執行。

第三條 本規范的應用軟件研制開發過程采用生命周期法，分為五個階段進行：

1． 分析階段 2． 設計階段 3． 編碼調試階段

4． 工程實施（部署）、測試驗收階段 5． 培訓、試運行階段

第四條 每個階段都有確定的任務，并產生相應的文檔。后一階段應在前一階段提供文檔的基礎上，繼續開展工作。每一階段結束時，必須對產生的文檔，進行仔細復審，發現錯誤，及時糾正。由于理解能力的限制，以及需求情況、環境條件的變化，反復進行修改，是不可避免的，應不厭其煩地，直至修改完善，保證正常運行使用。力戒湊合。

第五條 應用軟件研制開發過程中會出現七個角色：組織機構的設置可根據

第 1頁 , 共 9 頁 開發平臺、開發人員、項目規模等因素有所變化，開發人員也可以隨著項目的連續性和項目的進展賦予不同的職責。

1． 項目經理：在一個或多個應用領域內使用整合了道德、法律和經濟問題的工程方法來設計合適的解決方案。懂得確定客戶需求并將其轉換成軟件需求的過程。履行項目經理的職責，善于處理技術和管理方面的事務。懂得并使用有用的項目管理工具。調諧互相沖突的目標，在成本、時間、知識、現有系統以及組織的限制下找出可接受的折衷辦法。在一個典型的軟件開發環境中談判、有效地工作、在必要時進行領導，并與有關負責人（包含外方）進行良好溝通。從最初創建建議書一直到項目簽收結束都應用國際標準。2． 系統分析員：協助項目經理工作。系統分析員是用戶和開發者之間的橋梁，負責與用戶一起進行需求分析，并對軟件需求進行規格化說明。

3． 系統設計員：系統設計員負責設計軟件的開發策略，配置軟件開發環境，進行數據結構設計和業務系統設計。

4． 程序設計員：負責程序的編寫、調試，以實現系統設計員做出的軟件設計。

5． 系統測試員：負責程序和業務系統兩方面的測試。

6． 文檔管理員：負責管理整個系統開發過程中產生的各種文檔。7． 用戶：應用軟件的接受和使用者。

第六條 分析階段

第 2頁 , 共 9 頁 1． 分析階段任務：在項目經理的帶領下進行業務需求調研。系統分析員與用戶一起充分討論業務需求、安全保密等要求；對有關業務活動，進行詳細分析，切實弄清在滿足業務需求的條件下，軟件系統應該做什么，并進行可行性論證。

2． 本階段的文檔是《業務需求說明書》、《技術方案設計書》、《草圖設計》、《項目開發計劃》和《項目約定書》。

3． 《業務需求說明書》由項目經理和系統分析員編寫。a)闡述業務范圍和內容。

b)分析現行系統的業務概況，系統的不足和用戶對新系統的要求。

4． 《技術方案設計書》由項目經理和系統分析員編寫。a)由開發組負責制定最優技術設計方案

b)業務流程圖：對原系統的描述，為數據流程圖提供依據 c)數據流程圖：系統說明書中的主要文件，按自頂向下的原則分層進行，先把整個系統當作一個功能，畫出最粗略的流程圖，然后逐步向下分解，直到所需要的詳盡程度。d)數據字典：對數據流程圖中的細節，進行描述說明。e)新系統的邏輯模型；提出為達到系統目標，對原系統應作那些修改，系統的人機界面，出錯處理，系統的啟動和結束，系統輸入輸出格式，系統性能等。

5． 《草圖設計》由項目經理和系統分析員編寫。簡化和圖示化技術方案設計書，讓用戶直接了解思路。

第 3頁 , 共 9 頁 6． 《項目開發計劃》由項目經理根據項目任務、人員配置和進度制定。

7． 《業務需求說明書》、《技術方案設計書》、《草圖設計》和《項目開發計劃》在業務部門確認這四個文檔滿足他們的要求后，提交軟件開發部門領導審批，然后由項目經理與業務部門簽訂《項目約定書》，作為業務部門和軟件開發部門之間密切合作的最終文件。（外購軟件參照執行）8． 在《項目約定書》中必須包括：

a)開發和實施過程中的人生、信息、設備的安全條款。b)提供明確數量的技術培訓和服務（質量）的承諾。

第七條 設計階段

1． 設計階段的任務：在設計階段中，項目經理和系統分析員應根據《技術方案設計書》提出的邏輯模型，精心設計系統實施方案，編寫《業務流程總體設計書》盡可能提高系統的安全性、可靠性、可變性、容錯性、工作質量和工作效率。2． 本階段工作是“業務流程總體設計”、“業務流程詳細設計”、《項目開發管理規范書》和《任務分配文檔》。3． “業務流程總體設計”由項目經理和系統分析員完成 a)“業務流程總體設計”是項目經理和系統分析員根據《業務需求說明書》和《技術方案設計書》的要求，運用結構化程序設計思想，將軟件自上而下逐層分解成多個軟件模塊，直

第 4頁 , 共 9 頁 到分解成每一個模塊只具有單一的功能，能用一個或幾個程序實現的樹形結構為止。總體設計還要定義各模塊的數據傳遞關系，設計軟件的編碼方案、文件存儲策略、輸入輸出格式，以及硬件和系統軟件配置，最后編制《概要設計說明書》。b)業務流程總體設計的內容主要包括：

(1)代碼設計(2)文件設計(3)輸入設計(4)輸出設計

(5)系統軟硬件配置設計(6)設計說明書

4． “業務流程詳細設計”由項目經理和系統分析員完成 a)“業務流程詳細設計”是對“業務流程總體設計”中劃分的每個模塊再進行詳細定義和說明。它包括定義每一模塊的詳細功能、輸入數據、使用文件及使用方式，確定輸出內容及格式，模塊實現的詳細算法，每一模塊的程序構成等，其中包括對數據庫關系和流程的設計。“業務流程詳細設計”是軟件功能、結構實現方法的最詳細說明，是程序設計的依據。“業務流程詳細設計”的最終成果是編制《詳細設計說明書》。

5． 《項目開發管理規范書》：由項目經理和系統分析員編寫。對開發人員在變量、代碼、編碼、數據文件格式、注釋等方面

第 5頁 , 共 9 頁 作出約定的技術性規范書。

6． 《任務分配文檔》由項目經理編寫，根據《概要設計說明書》、《詳細設計說明書》和《項目開發計劃》分配人員和任務。

第八條 編寫、調試階段

1． 主要任務是由程序人員在系統分析員的帶領下，根據《任務分配文檔》分配的各自的模塊說明書寫出程序《開發文檔》，并以此編寫邏輯正確、易于閱讀和理解的程序。

a)《開發文檔》應該包括：程序框圖、源程序清單、程序說明書、邏輯正確的程序模塊。

2． 高級程序員將程序員開發的模塊按《概要設計說明書》、《詳細設計說明書》集成系統。

3． 在本階段中，模塊級測試可以由程序員自己或相互測試，也可以由測試員參與模塊級測試。

4． 在本階段中，對開發服務器上集成后的系統進行測試，可以由高級程序員到測試員共同參與進行測試，測試結果由程序員對代碼進行消缺，同時編寫《集成測試說明書》。5． 在經過系統集成測試后，可以向用戶展示系統，項目經理和系統分析員要聽取用戶的意見，如果用戶對業務有所變更，項目經理和系統分析員對此進行分析，對于確實需要變更的業務，由項目經理及時提出《問題說明報告》，讓用戶和領導審批，審批通過后，系統分析員立即編寫《業務變更文檔》，第 6頁 , 共 9 頁 同步記錄開發過程中用戶提出的業務需求變更的情況，以便及時讓組員了解。

6． 在向用戶展示系統通過后，系統進入現場安裝部署階段。

第九條 工程實施（部署）、測試驗收階段

1． 在現場部署階段，首先準備運行服務器。同時，由系統分析員根據《業務需求說明書》、《概要設計說明書》、《詳細設計說明書》，編寫《項目測試方案與報告》的初稿，《項目測試方案與報告》包括測試案例，以驗證系統的功能與性能。2． 成立由項目經理、系統分析員、程序員、測試員和用戶在內的測試小組進行現場碼測試。

a)現場碼測試過程是按照《項目測試方案與報告》的初稿的測試案例，逐條進行。現場代碼測試是一個反復的過程，如果沒有通過測試，要進行消缺，再全面測試，直到測試通過為止。

b)現場代碼測試完成后的系統要移植到最終運行環境（部署），將實際數據采集及導入。

3． 成立由項目經理、系統分析員、測試員和用戶在內的測試小組進行現場驗收測試。

a)對實際運行系統進行現場驗收測試。測試過程是按照《項目測試方案與報告》的初稿的測試案例，逐條進行。b)現場驗收測試完成后，測試小組要對被測試系統是否達到

第 7頁 , 共 9 頁 《項目測試方案與報告》的要求，提出意見，完善《項目測試方案與報告》報告，提交領導審批。

4． 在進行系統測試的同時，系統分析員、程序員積極編寫《項目開發文檔》匯總整個項目的使用的技術、思路、過程。5． 在工程實施（部署）、測試驗收階段，系統分析員和高級程序員還要積極編寫《用戶使用手冊》，在系統代碼測試完成后，向用戶進行培訓。

6． 現場驗收測試通過的系統交用戶試運行一段時間（一般要求３～６個月），以進一步發現問題，予以修改、完善。經用戶試運行，滿意認可后，由用戶提出《用戶報告》，項目經理則編寫《項目驗收報告》。

第十條 驗收、運行維護階段

1． 軟件驗收組應由用戶、開發人員和專家三方組成。驗收組要對《項目驗收報告》、《項目測試方案與報告》、《用戶報告》等資料是否完整進行認真審查并作出評價；

2． 在軟件系統通過驗收，并交付用戶正式使用后，用戶應對軟件系統的資產進行分類統計，編制資產清單，標注資產的重要性，并對資產清單定期維護和更新；

3． 要對軟件系統的日常維護工作作出安排。可以委托軟件開發人員日常維護。要建立軟件系統的《日常維護檔案》資料歸

第 8頁 , 共 9 頁 檔，作為今后日常維護的依據。在可能的條件下，也可對業務人員作進一步培訓，逐步做到由業務部門自行維護。

**供電公司

2009年2月

第 9頁 , 共 9 頁