目的與概述

本文件為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 系統打包部署

    客服安裝人員將系統打包成一個安裝檔案，供在客戶的系統環境中部署系統

系統整合測試階段交付項（可配置項）：

系統安裝檔案