本文件為xx公司的開發規範文件，給開發團隊提供開發標準和規範。
在開發規範中包含了兩個部分，第一部分是專案開發流程規範，主要闡述在專案開發過程中的各個階段的規範。第二部分為coding開發規範，coding開發規範闡述了在乙個框架中的各個層的開發規範
（注：在第一版中不包含對工作流開發的規範制定）
1.專案管理人員
2.系統設計人員
3.系統開發人員
略2
專案開發流程規範
l調研的目標
系統層面：
客戶的系統執行環境
業務層面：了解客戶需要什麼樣的系統，具體了解業務目的，業務邏輯，業務資料，客戶的操作習慣，頁面風格習慣等。
l調研的準備工作：
行業知識的準備：
了解客戶的行業背景，行業領域的業務術語，含義。結合客戶行業背景，了解客戶的業務知識。
業務專家需求：
在行業領域的複雜度不高的情況下，業務分析人員直接收集並學習行業知識就可以了，但行業知識的準備工作還是要做的
在行業領域業務複雜度高的情況下，需要業務專家對客戶的業務的進行整理。
l調研的流程：
第一步，專案啟動階段
了解客戶的it環境。
第二步，
討論並具體確定客戶系統的範圍，並獲得客戶業務功能點的原始的單據。在這個過程中準備乙個本和乙隻筆記錄討論的業務資訊
第三步，
整理業務資訊，和原始表單，抽取出有效業務資訊，並對於不明確的業務資訊進行整理和歸類，並製作成問卷形式進一步調研。
第四步，
發放調研問卷，再次進行業務調研（直接轉到三）
第五步，卷寫調研問卷，並內部評審
第六步，調研問卷客戶評審並確認。
l調研階段的交付項（可配置項）
軟體需求說明書
軟體需求說明書的目錄：
1 客戶行業背景
2 客戶系統的意義
3 客戶系統執行的環境
4 業務功能點描述（業務目的，業務邏輯，業務資料，優先級別，使用頻率等）
5 客戶的操作習慣，頁面風格習慣。
概要設計階段主要分兩個步驟： 1 框架設計
2 業務模組概要設計 ,下面分別對兩個步驟進行描述：
2.2.1框架設計
（注：這邊的框架設計是按照傳統的開發方式進行闡述，基於平台的開發方式待補）
l框架設計的目標：
根據客戶需求，設計系統的後台架構，前台介面框架，資料模型。在設計之前要考慮客戶的業務特點，效能要求，已有的it環境，同時還要考慮將來業務的增長，保證系統一定得可擴充套件性。
l框架設計包含的內容：
後台框架：各層的職能劃分，技術實現的方式，層之間的互動規則，異常處理規則，目錄定義規則
介面框架：操作主介面定義
頁面整體風格的定義，頁面流轉關係等
資料模型：系統基礎資料（組織人員結構，許可權設定，字典引數設定）
業務資料
l框架設計階段交付項：
文件：系統架構
介面框架
資料模型
注：三份文件可以融合在乙份文件之中。
2.2.2業務模組概要設計
系統設計人員根據業務分析人員的業務需求文件，進行概要設計。在概要設計過程中主要關注三個關鍵點
1）業務模組的頁面顯示內容：資訊顯示的內容，顯示的方式；互動介面的定義，等
舉例：查詢人員資訊模組
操作說明，查詢條件，顯示字段，排序和顯示方式。
2）業務邏輯描述
對業務邏輯進行詳細的描述。
3）業務資料項
業務模組涉及到資料的描述。
具體的描述包含
資料項名稱，顯示方式，是否必填，輸入方式，相關邏輯
l概要設計階段的交付項
概要設計文件
2.3.1系統設計人員理解需求
在系統設計人員理解需求之前，業務分析人員必須提供相關模組的客戶需求文件。
系統設計人員閱讀並理解客戶需求文件。
l理解需求文件的交付結果（可配置項）
業務需求對於客戶來講，目的是什麼，解決什麼問題，有什麼意義？
具體業務的執行邏輯是什麼？
在業務流轉過程中的業務資料有哪些？
l需求理解時間要求：
簡單的需求，理解時間為2-3 小時
複雜需求：理解需求時間4-8小時
l複雜的業務需求需要需求分析人員確認。
複雜的業務需求按照涉及到的業務的複雜度來決定的。
詳細設計階段分兩個步驟
l 第一步驟，系統設計人員根據業務需求的理解,詳細設計業務模組，並出詳細設計文件
l 第二步驟，核心設計人員對系統設計人員的詳細設計文件進行技術評審。
2.4.1系統設計人員詳細設計階段
系統設計人員根據業務需求，詳細設計模組。
l詳細設計階段的交付結果（可配置項）
詳細設計文件：
業務介面定義
資料庫的資料項定義
web頁面和js介面定義等
注：對於複雜的模組可以在詳細設計文件中可以包含了
uml類圖，和時序圖
，從而進一步描述設計的內容
l詳細設計時間要求：
簡單的業務需求：2-4小時
複雜的業務需求4-12小時
l詳細設計文件的書寫原則：
系統設計人員在文件中能描述清楚業務模組的詳細設計，不拘泥於格式。
2.4.2 技術評審階段
l技術評審流程：
1）系統設計人員在技術評審之前，將自己的詳細設計文件分發給技術評審的與會人員。
2）在技術評審過程中，系統設計人員首先講述詳細設計文件
3）評審人員對詳細設計中各個環節進行詢問和確認，提出修改方案。
4）最後專案技術負責人確認調整後的設計方案。
l技術階段的交付結果（可配置項）
業務確定的詳細設計文件。
注：此文件是交付確認的標準之一。
系統開發人員根據業務的專案詳細設計文件，進行實際coding過程。
在coding過程中的注意事項
1）在coding過程中嚴格按照coding開發規範來執行。
2）在coding過程中，發現詳細設計文件中的嚴重缺陷，則需要和專案設計人員確認，如非常複雜，則需重新技術評審。
3）在詳細設計發生改變時，需要及時更新詳細設計文件。
專案技術負責人和業務分析人員共同對業務模組進行驗收。
驗收步驟：
1）業務分析人員確認功能模組實現功能和客戶需求一致
2）技術負責人對功能模組進行技術上的確認。
3）測試人員的測試報告
注：第三步主要看公司的具體的情況和業務複雜度，
第三步完成流程如下：
1）準備測試階段
測試人員根據業務需求，設定乙個業務環境，寫成測試指令碼，
2）測試階段
根據測試環境和業務需求
進行測試
3）根據測試的結果，出測試報告。
根據客戶業務需求，測試人員設定乙個測試環境，編寫測試指令碼，在測試伺服器上部署好系統。按照測試用例進行業務功能上測試。
測試人員準備工作清單：
測試用例
測試指令碼
當前實現模組
硬體裝置：
等同條件的客戶執行環境
系統整合測試階段交付項（可配置項）：
系統整合測試報告
系統整合測試報告格式
功能點測試人
測試指令碼
測試結果
異常原因
客服安裝人員將系統打包成乙個安裝檔案，供在客戶的系統環境中部署系統
系統整合測試階段交付項（可配置項）：
系統安裝檔案
專案開發流程規範文件
本文件為xx公司的開發規範文件，給開發團隊提供開發標準和規範。在開發規範中包含了兩個部分，第一部分是專案開發流程規範，主要闡述在專案開發過程中的各個階段的規範。第二部分為coding開發規範，coding開發規範闡述了在乙個框架中的各個層的開發規範 注 在第一版中不包含對工作流開發的規範制定 1.專...
介面規範文件
一.我們系統的一般的介面設計和跨域處理 1.前後端token驗證 初始化操作 public function initialize session start parent initialize header access control allow origin header access con...
微信小程式開發規範文件 專案結構
專案結構 project 根目錄 images 小圖示 pages pages目錄 utils 工具，包檔案目錄 project.config.json 專案的編輯器配置頁面目錄 1.由歷史原因和個人習慣導致目錄命名不統一，語義不清晰，不同成員在維護時難以快速識別。示例 錯誤的寫法 pages ab...