1 概述
目的與概述
本文檔為XX公司的開發規范文檔，給開發團隊提供開發標准和規范。
整體說明
在開發規范中包含了兩個部分，第一部分是項目開發流程規范，主要闡述在項目開發過程中的各個階段的規范。第二部分為Coding開發規范，Coding開發規范闡述了在一個框架中的各個層的開發規范
（注：在第一版中不包含對工作流開發的規范制定）
覆蓋范圍
閱讀對象
1. 項目管理人員
2. 系統設計人員
3. 系統開發人員
參考資料
略
2 項目開發流程規范
2.1 業務需求調研階段
l 調研的目標
系統層面： 客戶的系統運行環境
業務層面：了解客戶需要什么樣的系統，具體了解業務目的，業務邏輯，業務數據，客戶的操作習慣，頁面風格習慣等。
l 調研的准備工作：
行業知識的准備：
了解客戶的行業背景，行業領域的業務術語，含義。結合客戶行業背景，了解客戶的業務知識。
業務專家需求：
在行業領域的復雜度不高的情況下，業務分析人員直接收集並學習行業知識就可以了，但行業知識的准備工作還是要做的
在行業領域業務復雜度高的情況下，需要業務專家對客戶的業務的進行整理。
l 調研的流程：
第一步 ，項目啟動階段 了解客戶的IT環境。
第二步， 討論並具體確定客戶系統的范圍，並獲得客戶業務功能點的原始的單據。在這個過程中准備一個本和一只筆記錄討論的業務信息
第三步， 整理業務信息，和原始表單，抽取出有效業務信息，並對於不明確的業務信息進行整理和歸類，並制作成問卷形式進一步調研。
第四步， 發放調研問卷，再次進行業務調研（直接轉到三）
第五步，卷寫調研問卷，並內部評審
第六步，調研問卷客戶評審並確認。
l 調研階段的交付項（可配置項）
軟件需求說明書
軟件需求說明書的目錄：
1 客戶行業背景
2 客戶系統的意義
3 客戶系統運行的環境
4 業務功能點描述（業務目的，業務邏輯，業務數據，優先級別，使用頻率等）
5 客戶的操作習慣，頁面風格習慣。
2.2 概要設計階段
概要設計階段主要分兩個步驟： 1 框架設計 2 業務模塊概要設計 ,下面分別對兩個步驟進行描述：
2.2.1框架設計
（注：這邊的框架設計是按照傳統的開發方式進行闡述，基於平台的開發方式待補）
l 框架設計的目標：
根據客戶需求，設計系統的后台架構，前台界面框架，數據模型。在設計之前要考慮客戶的業務特點，性能要求，已有的IT環境，同時還要考慮將來業務的增長，保證系統一定得可擴展性。
l 框架設計包含的內容：
后台框架： 各層的職能划分，技術實現的方式，層之間的交互規則，異常處理規則，目錄定義規則
界面框架：操作主界面定義
頁面整體風格的定義，頁面流轉關系等
數據模型： 系統基礎數據（組織人員結構，權限設置，字典參數設置）
業務數據
l 框架設計階段交付項：
文檔 ：系統架構
界面框架
數據模型
注：三份文檔可以融合在一份文檔之中。
2.2.2業務模塊概要設計
系統設計人員根據業務分析人員的業務需求文檔，進行概要設計。在概要設計過程中主要關注三個關鍵點
1） 業務模塊的頁面顯示內容：信息顯示的內容，顯示的方式；交互接口的定義，等
舉例：查詢人員信息模塊
操作說明，查詢條件，顯示字段，排序和顯示方式。
2）業務邏輯描述
對業務邏輯進行詳細的描述。
3）業務數據項
業務模塊涉及到數據的描述。
具體的描述包含
數據項名稱 ，顯示方式，是否必填，輸入方式，相關邏輯
l 概要設計階段的交付項
概要設計文檔
2.3 業務需求理解階段
2.3.1系統設計人員理解需求
在系統設計人員理解需求之前，業務分析人員必須提供相關模塊的客戶需求文檔。 系統設計人員閱讀並理解客戶需求文檔。
l 理解需求文檔的交付結果（可配置項）
業務需求對於客戶來講，目的是什么，解決什么問題，有什么意義？
具體業務的執行邏輯是什么？
在業務流轉過程中的業務數據有哪些？
l 需求理解時間要求：
簡單的需求，理解時間為2-3 小時
復雜需求：理解需求時間4-8小時
l 復雜的業務需求需要需求分析人員確認。
復雜的業務需求按照涉及到的業務的復雜度來決定的。
2.4 詳細設計階段
詳細設計階段分兩個步驟
l 第一步驟，系統設計人員根據業務需求的理解,詳細設計業務模塊，並出詳細設計文檔
l 第二步驟，核心設計人員對系統設計人員的詳細設計文檔進行技術評審。
2.4.1系統設計人員詳細設計階段
系統設計人員根據業務需求，詳細設計模塊。
l 詳細設計階段的交付結果（可配置項）
詳細設計文檔：
業務接口定義
數據庫的數據項定義
Web頁面和Js接口定義等
注：對於復雜的模塊可以在詳細設計文檔中可以包含了UML類圖，和時序圖 ，從而進一步描述設計的內容
l 詳細設計時間要求：
簡單的業務需求：2-4小時
復雜的業務需求4-12小時
l 詳細設計文檔的書寫原則：
系統設計人員在文檔中能描述清楚業務模塊的詳細設計，不拘泥於格式。
2.4.2 技術評審階段
l 技術評審流程：
1）系統設計人員在技術評審之前，將自己的詳細設計文檔分發給技術評審的與會人員。
2）在技術評審過程中，系統設計人員首先講述詳細設計文檔
3）評審人員對詳細設計中各個環節進行詢問和確認，提出修改方案。
4）最后項目技術負責人確認調整后的設計方案。
l 技術階段的交付結果（可配置項）
業務確定的詳細設計文檔。
注：此文檔是交付確認的標准之一。
2.5 Coding階段
系統開發人員根據業務的項目詳細設計文檔，進行實際Coding過程。
在Coding過程中的注意事項
1） 在Coding過程中嚴格按照Coding開發規范來執行。
2）在Coding過程中，發現詳細設計文檔中的嚴重缺陷，則需要和項目設計人員確認，如非常復雜，則需重新技術評審。
3）在詳細設計發生改變時，需要及時更新詳細設計文檔。
2.6 業務模塊確認交付階段
項目技術負責人和業務分析人員共同對業務模塊進行驗收。
驗收步驟：
1）業務分析人員確認功能模塊實現功能和客戶需求一致
2）技術負責人對功能模塊進行技術上的確認。
3）測試人員的測試報告
注：第三步主要看公司的具體的情況和業務復雜度，
第三步完成流程如下：
1）准備測試階段 測試人員根據業務需求，設定一個業務環境，寫成測試腳本，
2）測試階段 根據測試環境和業務需求 進行測試
3）根據測試的結果，出測試報告。
2.7 系統集成測試
根據客戶業務需求，測試人員設定一個測試環境，編寫測試腳本，在測試服務器上部署好系統。按照測試用例進行業務功能上測試。
測試人員准備工作清單：
測試用例
測試腳本
當前實現模塊
硬件設備：
等同條件的客戶運行環境
系統集成測試階段交付項（可配置項）：
系統集成測試報告
系統集成測試報告格式
功能點 測試人 測試腳本 測試結果 異常原因
2.8 系統打包部署
客服安裝人員將系統打包成一個安裝文件，供在客戶的系統環境中部署系統
系統集成測試階段交付項（可配置項）：
系統安裝文件