1 概述
目的與概述
本文件為網路公司的專案開發規範文件，給開發團隊提供開發標準和規範。
整體說明
在開發規範中包含了兩個部分，第一部分是專案開發流程規範，主要闡述在專案開發過程中的各個階段的規範。第二部分為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 業務需求理解階段12
2.12.3.1系統設計人員理解需求
在系統設計人員理解需求之前，業務分析人員必須提供相關模組的客戶需求文件。系統設計人員閱讀並理解客戶需求文件。
l 理解需求文件的交付結果（可配置項）
業務需求對於客戶來講，目的是什麼，解決什麼問題，有什麼意義？具體業務的執行邏輯是什麼？在業務流轉過程中的業務資料有哪些？
l 需求理解時間要求：
簡單的需求，理解時間為2-3 小時
複雜需求：理解需求時間4-8小時
l 複雜的業務需求需要需求分析人員確認。
複雜的業務需求按照涉及到的業務的複雜度來決定的。
2.4 詳細設計階段
詳細設計階段分兩個步驟
l 第一步驟，系統設計人員根據業務需求的理解,詳細設計業務模組，並出詳細設計文件
l 第二步驟，核心設計人員對系統設計人員的詳細設計文件進行技術評審。
2.22.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 系統打包部署
客服安裝人員將系統打包成乙個安裝檔案，供在客戶的系統環境中部署系統
系統整合測試階段交付項（可配置項）：
系統安裝檔案
專案開發規檔
本文件為xx公司的開發規範文件，給開發團隊提供開發標準和規範。在開發規範中包含了兩個部分，第一部分是專案開發流程規範，主要闡述在專案開發過程中的各個階段的規範。第二部分為coding開發規範，coding開發規範闡述了在乙個框架中的各個層的開發規範 注 在第一版中不包含對工作流開發的規範制定 1.專...
APP開發規範 APP介面開發規檔V1
手機客戶端介面文件 版本歷史 目錄一 概述 1 1.1 有關介面 1 1.1.1介面是純資料的互動 1 1.2 介面的分類 1 1.2.1查詢類介面 1 1.2.2 操作類介面 1 1.2.3上傳 類介面 1 1.2.4推送類介面 1 二 查詢類介面格式規範 1 2.1獲取單條物件資訊 1 2.1....
專案開發流程
新華08 專案產品需求流程書 簽字責任說明 1.需求提交人簽字，對自己提出的需求負責，承諾專案是具有可執行性與必要性，需求是經過合理思考的。2.部門或組長對時間簽字，對專案開展週期與內容核對確認，對專案需求負責。3.專案進入需求分析階段，負責專案開發的產品經理與需求提交人協商協調需求。需求提交人簽字...