項目開發流程規範文檔

 

1 概述目的與概述

本文檔為XX公司的開發規範文檔，給Team Dev提供開發標準和規範。

整體說明

    在開發規範中包含了兩個部分，第一部分是項目開發流程規範，主要闡述在項目開發過程中的各個階段的規範。第二部分為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 系統打包部署

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

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

系統安裝檔案

 

註： 網頁看的不是太清晰，
下面是文檔的串連，可以直接下載看
/Files/macroxu-1982/項目開發規範文檔.doc     徐文兵  整理於2009-07-18