1 概述
目的與概述
本文檔為XX公司的開發(fā)規(guī)范文檔，給開發(fā)團隊提供開發(fā)標準和規(guī)范。
整體說明
在開發(fā)規(guī)范中包含了兩個部分，第一部分是項目開發(fā)流程規(guī)范，主要闡述在項目開發(fā)過程中的各個階段的規(guī)范。第二部分為Coding開發(fā)規(guī)范，Coding開發(fā)規(guī)范闡述了在一個框架中的各個層的開發(fā)規(guī)范
（注：在第一版中不包含對工作流開發(fā)的規(guī)范制定）
覆蓋范圍
閱讀對象
1. 項目管理人員
2. 系統(tǒng)設(shè)計人員
3. 系統(tǒng)開發(fā)人員
參考資料
略
2 項目開發(fā)流程規(guī)范
2.1 業(yè)務(wù)需求調(diào)研階段
l 調(diào)研的目標
系統(tǒng)層面： 客戶的系統(tǒng)運行環(huán)境
業(yè)務(wù)層面：了解客戶需要什么樣的系統(tǒng)，具體了解業(yè)務(wù)目的，業(yè)務(wù)邏輯，業(yè)務(wù)數(shù)據(jù)，客戶的操作習慣，頁面風格習慣等。
l 調(diào)研的準備工作：
行業(yè)知識的準備：
了解客戶的行業(yè)背景，行業(yè)領(lǐng)域的業(yè)務(wù)術(shù)語，含義。結(jié)合客戶行業(yè)背景，了解客戶的業(yè)務(wù)知識。
業(yè)務(wù)專家需求：
在行業(yè)領(lǐng)域的復(fù)雜度不高的情況下，業(yè)務(wù)分析人員直接收集并學(xué)習行業(yè)知識就可以了，但行業(yè)知識的準備工作還是要做的
在行業(yè)領(lǐng)域業(yè)務(wù)復(fù)雜度高的情況下，需要業(yè)務(wù)專家對客戶的業(yè)務(wù)的進行整理。
l 調(diào)研的流程：
第一步 ，項目啟動階段 了解客戶的IT環(huán)境。
第二步， 討論并具體確定客戶系統(tǒng)的范圍，并獲得客戶業(yè)務(wù)功能點的原始的單據(jù)。在這個過程中準備一個本和一只筆記錄討論的業(yè)務(wù)信息
第三步， 整理業(yè)務(wù)信息，和原始表單，抽取出有效業(yè)務(wù)信息，并對于不明確的業(yè)務(wù)信息進行整理和歸類，并制作成問卷形式進一步調(diào)研。
第四步， 發(fā)放調(diào)研問卷，再次進行業(yè)務(wù)調(diào)研（直接轉(zhuǎn)到三）
第五步，卷寫調(diào)研問卷，并內(nèi)部評審
第六步，調(diào)研問卷客戶評審并確認。
l 調(diào)研階段的交付項（可配置項）
軟件需求說明書
軟件需求說明書的目錄：
1 客戶行業(yè)背景
2 客戶系統(tǒng)的意義
3 客戶系統(tǒng)運行的環(huán)境
4 業(yè)務(wù)功能點描述（業(yè)務(wù)目的，業(yè)務(wù)邏輯，業(yè)務(wù)數(shù)據(jù)，優(yōu)先級別，使用頻率等）
5 客戶的操作習慣，頁面風格習慣。
2.2 概要設(shè)計階段
概要設(shè)計階段主要分兩個步驟： 1 框架設(shè)計 2 業(yè)務(wù)模塊概要設(shè)計 ,下面分別對兩個步驟進行描述：
2.2.1框架設(shè)計
（注：這邊的框架設(shè)計是按照傳統(tǒng)的開發(fā)方式進行闡述，基于平臺的開發(fā)方式待補）
l 框架設(shè)計的目標：
根據(jù)客戶需求，設(shè)計系統(tǒng)的后臺架構(gòu)，前臺界面框架，數(shù)據(jù)模型。在設(shè)計之前要考慮客戶的業(yè)務(wù)特點，性能要求，已有的IT環(huán)境，同時還要考慮將來業(yè)務(wù)的增長，保證系統(tǒng)一定得可擴展性。
l 框架設(shè)計包含的內(nèi)容：
后臺框架： 各層的職能劃分，技術(shù)實現(xiàn)的方式，層之間的交互規(guī)則，異常處理規(guī)則，目錄定義規(guī)則
界面框架：操作主界面定義
頁面整體風格的定義，頁面流轉(zhuǎn)關(guān)系等
數(shù)據(jù)模型： 系統(tǒng)基礎(chǔ)數(shù)據(jù)（組織人員結(jié)構(gòu)，權(quán)限設(shè)置，字典參數(shù)設(shè)置）
業(yè)務(wù)數(shù)據(jù)
l 框架設(shè)計階段交付項：
文檔 ：系統(tǒng)架構(gòu)
界面框架
數(shù)據(jù)模型
注：三份文檔可以融合在一份文檔之中。
2.2.2業(yè)務(wù)模塊概要設(shè)計
系統(tǒng)設(shè)計人員根據(jù)業(yè)務(wù)分析人員的業(yè)務(wù)需求文檔，進行概要設(shè)計。在概要設(shè)計過程中主要關(guān)注三個關(guān)鍵點
1） 業(yè)務(wù)模塊的頁面顯示內(nèi)容：信息顯示的內(nèi)容，顯示的方式；交互接口的定義，等
舉例：查詢?nèi)藛T信息模塊
操作說明，查詢條件，顯示字段，排序和顯示方式。
2）業(yè)務(wù)邏輯描述
對業(yè)務(wù)邏輯進行詳細的描述。
3）業(yè)務(wù)數(shù)據(jù)項
業(yè)務(wù)模塊涉及到數(shù)據(jù)的描述。
具體的描述包含
數(shù)據(jù)項名稱 ，顯示方式，是否必填，輸入方式，相關(guān)邏輯
l 概要設(shè)計階段的交付項
概要設(shè)計文檔
2.3 業(yè)務(wù)需求理解階段
2.3.1系統(tǒng)設(shè)計人員理解需求
在系統(tǒng)設(shè)計人員理解需求之前，業(yè)務(wù)分析人員必須提供相關(guān)模塊的客戶需求文檔。 系統(tǒng)設(shè)計人員閱讀并理解客戶需求文檔。
l 理解需求文檔的交付結(jié)果（可配置項）
業(yè)務(wù)需求對于客戶來講，目的是什么，解決什么問題，有什么意義？
具體業(yè)務(wù)的執(zhí)行邏輯是什么？
在業(yè)務(wù)流轉(zhuǎn)過程中的業(yè)務(wù)數(shù)據(jù)有哪些？
l 需求理解時間要求：
簡單的需求，理解時間為2-3 小時
復(fù)雜需求：理解需求時間4-8小時
l 復(fù)雜的業(yè)務(wù)需求需要需求分析人員確認。
復(fù)雜的業(yè)務(wù)需求按照涉及到的業(yè)務(wù)的復(fù)雜度來決定的。
2.4 詳細設(shè)計階段
詳細設(shè)計階段分兩個步驟
l 第一步驟，系統(tǒng)設(shè)計人員根據(jù)業(yè)務(wù)需求的理解,詳細設(shè)計業(yè)務(wù)模塊，并出詳細設(shè)計文檔
l 第二步驟，核心設(shè)計人員對系統(tǒng)設(shè)計人員的詳細設(shè)計文檔進行技術(shù)評審。
2.4.1系統(tǒng)設(shè)計人員詳細設(shè)計階段
系統(tǒng)設(shè)計人員根據(jù)業(yè)務(wù)需求，詳細設(shè)計模塊。
l 詳細設(shè)計階段的交付結(jié)果（可配置項）
詳細設(shè)計文檔：
業(yè)務(wù)接口定義
數(shù)據(jù)庫的數(shù)據(jù)項定義
Web頁面和Js接口定義等
注：對于復(fù)雜的模塊可以在詳細設(shè)計文檔中可以包含了UML類圖，和時序圖 ，從而進一步描述設(shè)計的內(nèi)容
l 詳細設(shè)計時間要求：
簡單的業(yè)務(wù)需求：2-4小時
復(fù)雜的業(yè)務(wù)需求4-12小時
l 詳細設(shè)計文檔的書寫原則：
系統(tǒng)設(shè)計人員在文檔中能描述清楚業(yè)務(wù)模塊的詳細設(shè)計，不拘泥于格式。
2.4.2 技術(shù)評審階段
l 技術(shù)評審流程：
1）系統(tǒng)設(shè)計人員在技術(shù)評審之前，將自己的詳細設(shè)計文檔分發(fā)給技術(shù)評審的與會人員。
2）在技術(shù)評審過程中，系統(tǒng)設(shè)計人員首先講述詳細設(shè)計文檔
3）評審人員對詳細設(shè)計中各個環(huán)節(jié)進行詢問和確認，提出修改方案。
4）最后項目技術(shù)負責人確認調(diào)整后的設(shè)計方案。
l 技術(shù)階段的交付結(jié)果（可配置項）
業(yè)務(wù)確定的詳細設(shè)計文檔。
注：此文檔是交付確認的標準之一。
2.5 Coding階段
系統(tǒng)開發(fā)人員根據(jù)業(yè)務(wù)的項目詳細設(shè)計文檔，進行實際Coding過程。
在Coding過程中的注意事項
1） 在Coding過程中嚴格按照Coding開發(fā)規(guī)范來執(zhí)行。
2）在Coding過程中，發(fā)現(xiàn)詳細設(shè)計文檔中的嚴重缺陷，則需要和項目設(shè)計人員確認，如非常復(fù)雜，則需重新技術(shù)評審。
3）在詳細設(shè)計發(fā)生改變時，需要及時更新詳細設(shè)計文檔。
2.6 業(yè)務(wù)模塊確認交付階段
項目技術(shù)負責人和業(yè)務(wù)分析人員共同對業(yè)務(wù)模塊進行驗收。
驗收步驟：
1）業(yè)務(wù)分析人員確認功能模塊實現(xiàn)功能和客戶需求一致
2）技術(shù)負責人對功能模塊進行技術(shù)上的確認。
3）測試人員的測試報告
注：第三步主要看公司的具體的情況和業(yè)務(wù)復(fù)雜度，
第三步完成流程如下：
1）準備測試階段 測試人員根據(jù)業(yè)務(wù)需求，設(shè)定一個業(yè)務(wù)環(huán)境，寫成測試腳本，
2）測試階段 根據(jù)測試環(huán)境和業(yè)務(wù)需求 進行測試
3）根據(jù)測試的結(jié)果，出測試報告。
2.7 系統(tǒng)集成測試
根據(jù)客戶業(yè)務(wù)需求，測試人員設(shè)定一個測試環(huán)境，編寫測試腳本，在測試服務(wù)器上部署好系統(tǒng)。按照測試用例進行業(yè)務(wù)功能上測試。
測試人員準備工作清單：
測試用例
測試腳本
當前實現(xiàn)模塊
硬件設(shè)備：
等同條件的客戶運行環(huán)境
系統(tǒng)集成測試階段交付項（可配置項）：
系統(tǒng)集成測試報告
系統(tǒng)集成測試報告格式
功能點 測試人 測試腳本 測試結(jié)果 異常原因
2.8 系統(tǒng)打包部署
客服安裝人員將系統(tǒng)打包成一個安裝文件，供在客戶的系統(tǒng)環(huán)境中部署系統(tǒng)
系統(tǒng)集成測試階段交付項（可配置項）：
系統(tǒng)安裝文件
個人項目管理計劃及實施建議個人項目管理計劃及實施建議
一、項目啟動（項目開工會）
了解項目干系人及其利害關(guān)系。
所有項目組成員是否到位，如到位則拿到項目開發(fā)人員的簡歷，詳細了解每個開發(fā)人員的情況（可能會組織到客戶方面試）。
根據(jù)項目需求規(guī)格列出項目功能列表，并根據(jù)開發(fā)人員技術(shù)等情況創(chuàng)建WBS。
根據(jù)項目時間、資源等情況規(guī)劃項目初步開發(fā)計劃（各里程碑時間點的粗略計劃，每個時間段投入多少人力等）。
確定各種軟硬件需求，如：版本控制服務(wù)器、數(shù)據(jù)庫服務(wù)器、開發(fā)服務(wù)器、缺陷管理軟件服務(wù)器、開發(fā)工具等。
參與人員：
項目經(jīng)理、項目總監(jiān)、全體項目組成員、用戶方領(lǐng)導(dǎo)、用戶方參與人員、其它主要項目干系人
項目啟動會議的目標：
讓整個項目組的成員相互認識
建立項目的工作關(guān)系和溝通關(guān)系
讓大家明確團隊的工作目標
讓大家了解項目的當前狀態(tài)
一起審閱項目計劃
找出項目的難點或可能出問題的環(huán)節(jié)
分配小組和個人的角色與責任
獲得小組和個人的承諾
實施建議：
對立項管理過程域產(chǎn)生的所有有價值的文檔如《立項建議書》、《立項調(diào)查報告》、《立項可行性分析報告》、《立項評審報告》進行配置管理。
做好必要的保密工作。
由于每個項目都要占用機構(gòu)的資金和資源，立項評審一定要嚴格。建議對機構(gòu)高層管理人員進行必要的立項管理培訓(xùn)。
輸出文檔包括：
項目風險管理計劃、工作任務(wù)分解結(jié)構(gòu)（WBS）、項目進度計劃、配置管理計劃、質(zhì)量保證計劃、TimeSheet、開發(fā)規(guī)范文檔、測試計劃
二、需求分析
需求調(diào)研：與客戶就其所需要的功能、流程、操作等需要為基礎(chǔ)，而且需求決策者必須是項目經(jīng)理或部門負責人。
列一個需求管理（包括詳細的溝通計劃及要求溝通）計劃，考慮需求溝通中的人員、資源、時間的要求。
雖然有些因素是客戶方造成的，但應(yīng)該站在其角度上，為其考慮一些存在的客觀及主觀因素。
注意與項目成員之間的溝通方式及對團隊的建設(shè)。
把握需求分析的進度及質(zhì)量是否符合要求。
根據(jù)交互設(shè)計原型與客戶交流需求分析是否達到要求及功能點是否有遺漏。
有哪些文檔或數(shù)據(jù)是由客戶提供的，這些數(shù)據(jù)是否需要在新開發(fā)的系統(tǒng)中維護等。
實施建議：
先對項目成員進行培訓(xùn)，讓他們掌握必要的需求開發(fā)技能。(比如需求開發(fā)要做什么，做到什么程度，需要注意哪些問題等)
對需求開發(fā)過程域產(chǎn)生的所有有價值的文檔進行配置管理。
需求的建模分析有較高的技術(shù)難度，項目成員應(yīng)當根據(jù)自身水平進行取舍。
交互設(shè)計中應(yīng)以用戶的易用性為前提然后考慮在這樣設(shè)計的前提下技術(shù)上實現(xiàn)是否有難度或者工作量超過前期設(shè)計的百分之二十.
（多用TAB形式，盡量讓客戶的某個角色的任務(wù)可以在一個頁面中完成，一般用上下文菜單，避免用系統(tǒng)的菜單，一個功能塊一般只需要一個入口）
輸出文檔包括：
產(chǎn)品需求分析說明書、數(shù)據(jù)流程圖、系統(tǒng)應(yīng)用架構(gòu)圖、交互設(shè)計原型、需求分析模型(RQM)
三、概要設(shè)計
確定影響系統(tǒng)設(shè)計的約束因素：本系統(tǒng)應(yīng)當遵循的標準或規(guī)范、軟件、硬件環(huán)境（包括運行環(huán)境和開發(fā)環(huán)境）的約束、接口/協(xié)議的約束、軟件質(zhì)量的約束、隱含約束等。
確定設(shè)計策略：擴展策略、復(fù)用策略、折衷策略。
系統(tǒng)分解與設(shè)計：將系統(tǒng)分解為若干子系統(tǒng)，確定每個子系統(tǒng)的功能以及子系統(tǒng)之間的關(guān)系；將子系統(tǒng)分解為若干模塊，確定每個模塊的功能以及模塊之間的關(guān)系。
數(shù)據(jù)庫概要設(shè)計。
輸出文檔：
產(chǎn)品概要設(shè)計說明書、數(shù)據(jù)概要設(shè)計模型(CDM)
四、詳細設(shè)計
確定功能模塊的參與者、數(shù)據(jù)庫表、輸入?yún)?shù)說明、前置條件、基本流程、異常流程、日志等信息。
各層次結(jié)構(gòu)的接口定義
數(shù)據(jù)庫設(shè)計：邏輯設(shè)計—>物理設(shè)計－>安全性設(shè)計－>優(yōu)化
實施建議：
先對系統(tǒng)設(shè)計人員進行“專題”培訓(xùn)，讓他們掌握必要的系統(tǒng)設(shè)計技能。
由于國內(nèi)絕大多數(shù)的大學(xué)不開設(shè)“用戶界面設(shè)計課程”，這導(dǎo)致大部分軟件開發(fā)人員不善于設(shè)計用戶界面。項目開發(fā)小組應(yīng)當設(shè)法邀請用戶界面設(shè)計專家參與（或指導(dǎo)）本軟件的
界面設(shè)計。
對系統(tǒng)設(shè)計過程中產(chǎn)生的所有有價值的文檔進行配置管理。
輸出文檔：
產(chǎn)品詳細設(shè)計說明書、數(shù)據(jù)物理設(shè)計模型(PDM)、自定義數(shù)據(jù)類型及BO數(shù)據(jù)類型文件、數(shù)據(jù)字典、系統(tǒng)測試用例、對象模型(OOM)
五、Coding
軟件編碼，各接口的實現(xiàn)。
單元測試。
實施建議：
對開發(fā)人員進行“高質(zhì)量程序設(shè)計”培訓(xùn)，讓他們掌握編寫高質(zhì)量程序的技能。
對開發(fā)人員進行“版本控制、代碼審查、測試、改錯”等方面的培訓(xùn)，提高他們的工作效率。
開發(fā)小組根據(jù)項目的資源、時間等限制因素，可以適當?shù)販p少測試的工作量。
對實現(xiàn)與測試過程中產(chǎn)生的所有代碼和有價值的文檔進行配置管理。
輸出：
單元測試報告、代碼評審報告
六、集成測試
根據(jù)系統(tǒng)測試用例測試系統(tǒng)的功能性需求，保證系統(tǒng)的正常功能處理及異常處理是否正確。
用戶界面測試，重點是測試軟件系統(tǒng)的易用性和視覺效果等。
健壯性測試,測試軟件系統(tǒng)在異常情況下能否正常運行的能力。(容錯能力和恢復(fù)能力)
安全性測試(這種測試一般能通過建行的fortify 軟件評測即可)
如果產(chǎn)品需要安裝，那么還得經(jīng)過安裝與反安裝測試
實施建議：
對系統(tǒng)測試人員進行必要的培訓(xùn)，提高他們的測試效率。
項目經(jīng)理和測試小組根據(jù)項目的資源、時間等限制因素，設(shè)法合理地減少測試的工作量，例如減少“冗余或無效”的測試。
系統(tǒng)測試小組根據(jù)產(chǎn)品的特征，可以適當?shù)匦薷谋疽?guī)范的各種文檔模板。
對系統(tǒng)測試過程中產(chǎn)生的所有代碼和有價值的文檔進行配置管理。
為了調(diào)動測試者的積極性，建議企業(yè)或項目設(shè)立獎勵機制，例如：根據(jù)缺陷的危害程度把獎金分等級，每個新缺陷對應(yīng)一份獎金，把獎金發(fā)給第一個發(fā)現(xiàn)該缺陷的人。
輸出：
系統(tǒng)測試報告、缺陷管理報告、操作手冊
七、客戶驗收
成果審查。驗收人員審查開發(fā)方應(yīng)當交付的成果，如代碼、文檔等等。確保這些成果是完整的并且是正確有效的。
驗收測試。驗收人員對交付的產(chǎn)品進行全面的測試，確保產(chǎn)品功能、質(zhì)量符合需求。
及時解決客戶方發(fā)現(xiàn)的問題。
輸出：
客戶驗收計劃、驗收測試用例、客戶驗收報告、驗收操作手冊
實施建議：
在客戶驗收之前，開發(fā)方對驗收人員進行必要的產(chǎn)品培訓(xùn)。
開發(fā)方可以將系統(tǒng)測試用例給驗收人員參考，以減少設(shè)計測試用例的時間。
開發(fā)方人員應(yīng)當熱情地協(xié)助驗收人員。對驗收人員發(fā)現(xiàn)的軟件缺陷馬上予以糾正；對于復(fù)雜的問題應(yīng)當立即請示有關(guān)領(lǐng)導(dǎo)，不可拖延。在驗收期間不可與客戶爭吵，給客戶留下很
好的印象。
對驗收過程中產(chǎn)生的所有有價值的文檔進行配置管理。
八、結(jié)項
計劃與實際情況對比:產(chǎn)品功能、工作成果、產(chǎn)品質(zhì)量、投入人員、工作量、成本等
申請結(jié)項理由和項目自我評價
對項目進行綜合評估，總結(jié)經(jīng)驗教訓(xùn)。
有價值的結(jié)項管理至少包括三項內(nèi)容：
一、對項目的有形資產(chǎn)和無形資產(chǎn)進行清算，既要防止資產(chǎn)流失，又要及時地利用這些資產(chǎn)。
二、對項目進行綜合評估。例如評估項目完成情況、項目質(zhì)量、投入產(chǎn)出分析、項目的市場價值、項目對企業(yè)的貢獻等等。該評估報告可以作為考核項目人員業(yè)績的重要依據(jù)。
三、總結(jié)經(jīng)驗教訓(xùn)，使整個機構(gòu)受益。
實施建議:
對結(jié)項管理過程域產(chǎn)生的所有有價值的文檔進行配置管理。
做好必要的保密工作。
結(jié)項評審工作不能簡化。
對結(jié)項評審委員會進行必要的培訓(xùn)，使他們樹立正確的觀念，從而嚴格把關(guān)
輸出：
結(jié)項申請書、結(jié)項評審報告
下面是這些核心工具的運用經(jīng)驗：
1.必須建立源代碼的版本控制系統(tǒng)，就是cvs，基本的代碼提交原則：
1)程序員盡量每天只在下班前提交一次;
2)提交的代碼必須是在自己的機器上是正常運行的；
3)每次提交都必須用簡短的話說明自己提交代碼的功能描述。
2.建立錯誤追蹤系統(tǒng)，用Bugzilla就很好，配置好郵件系統(tǒng)，使Bugzilla成為測試人員與開發(fā)人員溝通的橋梁。
3.用BAT和Perl腳本，以cvs中的源代碼為核心實現(xiàn)簡單的每日編譯工具，將這個自己寫的自動化工具放到一臺專門的編譯機器上，在每天的半夜開始自動下載代碼，自動編譯代碼
，自動打包安裝程序，自動記錄各種編譯日志，自動將安裝程序放置到一個固定的以日期為目錄名的公共區(qū)。（用cvs2cl.pl得到程序員上傳的代碼更新日志，以便測試人員參考）
4.測試人員的第二天，應(yīng)該到公共區(qū)取得頭天的最新版本，并根據(jù)ChangeLog進行新版本的測試。并將測試中發(fā)現(xiàn)的Bug，通過Bugzilla反饋給程序員。程序員可以根據(jù)自己的情況
，或公司的規(guī)定來決定修改這些Bug的時間。并將這些Bug的修改情況，在代碼提交時，寫入代碼日志。
5.開發(fā)人員的第二天，應(yīng)該到公共區(qū)查看編譯日志，看看自己的模塊是否正常編譯，及時更正，看看自己的郵箱有沒有Bug報告，及時修改。
6.管理人員的第二天，在綜合項目需求與頭天版本進度的上，可以判斷產(chǎn)品的發(fā)展方向，如果有偏航或理解錯誤或有新需求時，可以根據(jù)當前情況及時調(diào)整。
這樣，通過 cvs => bugzilla => daily-build，就能將程序員與測試員，進行互動，各施其責。減少溝通與人為的麻煩。對于管理層，也能做到心中有數(shù)：因為每天都有新版本，
隨時掌握產(chǎn)品的走向。。。等等。
7 樓 caoyanbao 2009-11-06 引用
cs_sehu 寫道
一般的軟件公司能做到一半很不錯了.
我個人認為這是做好一個項目最基本的流程，如果說一般的軟件公司只能做到一半，可以試想下為什么我國的軟件人才那么便宜的原因所在了：（
6 樓 cs_sehu 2009-10-21 引用
一般的軟件公司能做到一半很不錯了.
5 樓 cs_sehu 2009-10-21 引用
我做過ISO質(zhì)量認證,上面的流程跟跟ISO質(zhì)量認證的流程一樣
4 樓 andongoop 2009-10-15 引用
這個流程真是太好了，太值得借鑒了。
盡信書不如無書，誰也沒說必須按這個規(guī)定，只能說一個比較詳細的過程是這樣我們可以根據(jù)自己的實際情況自行調(diào)節(jié)嗎
3 樓 seeckt 2009-10-13 引用
大老板當然不需要關(guān)心，這個是項目經(jīng)理關(guān)心的事情
2 樓 hereyouare 2009-10-09 引用
我們公司是項目經(jīng)理分析，建數(shù)據(jù)庫，安排任務(wù)編碼，測試，寫文檔，驗收~~
1 樓 yuther 2009-10-05 引用
國內(nèi)有這樣執(zhí)行的軟件公司嗎？我見到的公司都是老板只關(guān)心盡快初驗，回款。
最近做完了一個項目，感慨頗深。根據(jù)做項目的經(jīng)驗，現(xiàn)初步擬了一個項目開發(fā)過程及成員組成。還請各位多多指教。
項目過程
1、項目啟動
1）、項目組成立（公司成員、客戶成員）
2）、制定項目預(yù)期目標
3）、制定項目計劃周期
4）、建立好項目組成員溝通機制
2、需求調(diào)研
1）、創(chuàng)建調(diào)研計劃、協(xié)調(diào)調(diào)研時間
2）、收集客戶資料，獲取客戶需求
所有的資料都需要保留一份，資料中存疑的需要及時詢問
3）、編寫需求文檔
重點描述出客戶的業(yè)務(wù)流程和性能要求。
采用Word、Excel、Rose等形式。
4）、需求變更記錄
5）、確定開發(fā)環(huán)境和運行環(huán)境
6）、擴展性要求
7）、與舊系統(tǒng)的接駁要求。
8）、估算出項目工作量
本階段需要一套需求管理系統(tǒng)來進行需求的管理。
本階段的需求文檔也是用戶測試的依據(jù)。
3、系統(tǒng)設(shè)計/詳細設(shè)計
一個系統(tǒng)可以分為基礎(chǔ)平臺和應(yīng)用模塊兩部分。
1）、選擇基礎(chǔ)平臺，無論是采用第三方平臺還是自行開發(fā)平臺，都需要深入了解，查看是否符合要求。
2）、應(yīng)用模塊設(shè)計（針對業(yè)務(wù)流程）
3）、中間件的采用或自行開發(fā)，需要深入了解。
4）、用戶界面的設(shè)計
如果用戶界面設(shè)計完畢并確認，即可初步寫出用戶使用手冊、管理員使用手冊。
5）、變更記錄
本階段的系統(tǒng)設(shè)計是集成測試的依據(jù)。
4、程序開發(fā)
創(chuàng)建開發(fā)任務(wù)計劃表、開發(fā)計劃日程表
1）、優(yōu)先編寫測試用例
2）、按照編碼規(guī)范編寫代碼
3）、按照文檔注釋規(guī)范注釋
以上形成開發(fā)文檔。
本階段需要一套版本管理系統(tǒng)。
本階段的測試用例也是單元測試的依據(jù)。
如果能做到，最好每日構(gòu)建。
5、測試
本階段需要一套Bug管理系統(tǒng)，形成需求、設(shè)計、開發(fā)、測試互動。
1）、編寫測試計劃和測試方案
2）、功能測試
單元測試、集成測試
3）、性能測試
集成測試、壓力測試
如果能做到，最好能進行自動化測試。
如果能做到，做分析統(tǒng)計工作。
最后形成測試報告。
6、試用、培訓(xùn)、維護
本階段需要解決：
1）、解決異地修改和公司修改的同步問題。
2）、用戶測試中的Bug修改問題，按照級別分為
a）、程序Bug
b）、設(shè)計變更
c）、需求變更
盡量按照a b c的順序來進行修改，盡量避免b、c級的修改。
最后形成安裝手冊、維護記錄。
項目成員組成
根據(jù)以上過程，一個項目組中，需要：
1、需求工程師，其要求
善于與客戶溝通，能快速了解客戶的需求，對客戶所在的行業(yè)比較熟悉。
善于學(xué)習新知識。
熟悉Word、Excel、Rose等工具的使用。
熟悉開發(fā)語言和開發(fā)框架
熟悉已積累的產(chǎn)品的功能、性能等。
2、系統(tǒng)分析師/設(shè)計師，其要求
精通開發(fā)語言和開發(fā)框架，部分需要精通數(shù)據(jù)庫
精通已積累的產(chǎn)品的功能、性能等
深入了解客戶行業(yè)特點
能根據(jù)客戶的要求分析出其實質(zhì)
能做出優(yōu)秀的設(shè)計
熟悉Word、Excel、Rose等工具的使用
3、開發(fā)工程師，其要求
熟悉開發(fā)語言，熟悉開發(fā)要求和注釋規(guī)范，部分需要熟悉數(shù)據(jù)庫。
熟悉單元測試。
能根據(jù)設(shè)計做出良好的編碼，保證功能和性能。
部分需要有一定的設(shè)計要求，因為涉及到將來的維護。
4、測試工程師，其要求
熟悉測試工作，能按照測試計劃進行測試。
熟悉開發(fā)語言，能協(xié)助開發(fā)工程師找錯。
能獨立完成黑、白盒測試。
如果是高級測試人員，還要能夠?qū)ο到y(tǒng)能深入進行分析并能制定出優(yōu)秀的測試方案。
5、管理人員
一般由以上人員兼任，主要有
項目經(jīng)理：負責整個項目
開發(fā)經(jīng)理：負責系統(tǒng)設(shè)計、開發(fā)工作
測試經(jīng)理：負責測試工作
6、其他人員
一些項目涉及到其他人員，如頁面設(shè)計人員、頁面制作人員。
部分大的項目，還有專門的維護人員。
由于目前國內(nèi)很多公司并沒有嚴格這么區(qū)分，如果項目小的話，可以一人兼任多項職位。關(guān)于項目管理的一點體會
標簽：項目管理 心得 it
分類：IT項目管理
前段時間，我負責了一個項目的管理與開發(fā)。在時間短、任務(wù)緊，而團隊人員又大部分是沒有經(jīng)驗的菜鳥的惡劣情況下，我?guī)ьI(lǐng)接近40人的團隊，終于在客戶規(guī)定的時間范圍內(nèi)如期交付產(chǎn)品。這其中，經(jīng)歷了需求變更、人員變動（因為其它任務(wù)，先后有近10人離開團隊）等諸多問題，項目仍然取得了成功，不能不說有幾分僥幸，但此外也有一些經(jīng)驗與教訓(xùn)可以與大家分享。
項目開發(fā)方面
項目應(yīng)以需求為核心。一個項目是否能夠成功，對需求的準確把握在成功因素中要占上60%的比例。不管系統(tǒng)的架構(gòu)設(shè)計、團隊管理有多么的成功，如果需求出現(xiàn)偏差，仍然是南轅北轍。由于EAS項目的特殊性，項目開發(fā)過程中能夠與客戶建立有效快速的溝通渠道，是項目成功的關(guān)鍵。
需求必須獲得客戶的確認。通過需求調(diào)研與分析后獲得的用戶需求說明書，以及軟件需求規(guī)格說明書都必須得到客戶的簽字確認。確認的內(nèi)容包括項目的目標、范圍以及項目需求功能點（用例）。EAS項目在前期對需求不夠重視，導(dǎo)致在需求理解上出現(xiàn)了一些偏差，從而影響了項目的進度。幸而得到了及時的糾正，在項目管理部的協(xié)助下，所有需求都得了客戶或客戶代表的簽字確認。從而使得項目在客戶驗收時，有了充分的保證。
項目應(yīng)確立專門的需求分析師。公司沒有專門的需求分析師，不能不說是人員配備上的一大弊端。（軟件開放工作細分的第一步就是要有專門的系統(tǒng)分析員或需求分析師）從EAS項目的開發(fā)過程中，我們就充分地認識到這一問題的嚴重性。需求的不斷更改，客戶遲遲未簽字確認，原因正是在于我們沒有專門的具有豐富經(jīng)驗的需求分析師。普通開發(fā)人員在調(diào)研需求以及撰寫需求規(guī)格說明書時，總是會出現(xiàn)偏差或理解錯誤的地方。軟件需求分析是一項重要且負責的技術(shù)，沒有經(jīng)過專門訓(xùn)練的需求分析師，通常會給項目帶來隱患。
項目應(yīng)指定各個模塊的需求接口人。只有這樣，才能有效地保證項目組與客戶的及時溝通，快速響應(yīng)客戶的請求與反饋。EAS項目在開發(fā)早期及時地確立了需求接口人，在一定程度上規(guī)避了需求變更給項目帶來的風險。但是，確立的需求接口人未經(jīng)過系統(tǒng)培訓(xùn)，在需求調(diào)研以及與客戶溝通的過程中，工作表現(xiàn)只能說是差強人意。
注意維護需求調(diào)研記錄以及需求跟蹤表。這一工作做得不夠好。由于需求調(diào)研人不夠?qū)I(yè)，而項目經(jīng)理以及需求分析負責人對這一過程還欠缺足夠的重視，同時沒有好的工具或流程來監(jiān)控這一過程，使得需求調(diào)研記錄沒有發(fā)揮更大的作用。此外，需求跟蹤也非常重要，畢竟，任何項目的需求都不是固定不變的，需求隨時會發(fā)生變更，而開發(fā)人員實現(xiàn)的需求也可能會與客戶的要求偏差。
注意維護需求矩陣。項目經(jīng)理對這一內(nèi)容缺乏足夠的重視與理解，項目開發(fā)過程體系中也缺乏好的需求矩陣文檔模板。但是在項目中后期，項目及時撰寫了EAS項目需求功能列表，并結(jié)合交付版本與客戶進行了溝通和協(xié)商，從而規(guī)避了需求偏差的風險。(需求追蹤，任何原始需求來有頭就有尾。原始需求->用戶需求->產(chǎn)品需求->軟件需求->設(shè)計->測試等一系列的追蹤。需求追蹤的目的一方面是檢查需求是否都已經(jīng)實現(xiàn)有無遺漏，更多的是為了做變更影響分析使用)
控制需求變更。重視CCB的作用，同時應(yīng)建立需求變更的響應(yīng)機制。EAS項目組對于需求變更的響應(yīng)還不夠及時，這一點項目經(jīng)理與項目管理小組要擔負一定的責任。（范圍管理中范圍控制的內(nèi)容，變更管理是配置管理的一個重要內(nèi)容。需求必須要受到控制，否則容易引起計劃的頻繁調(diào)整而發(fā)生混亂)
設(shè)計
重視架構(gòu)設(shè)計。EAS項目的成功，一定程度是源于我們有個優(yōu)秀的框架開發(fā)小組，我們在項目立項之初就基本確定了整個系統(tǒng)的架構(gòu)。其中雖然發(fā)生了一些變化，但核心架構(gòu)仍然沒有發(fā)生大的變化。由于，我們建立了穩(wěn)定、簡單的系統(tǒng)框架，可以極大地提高開發(fā)效率，規(guī)避了對框架的重復(fù)編碼。(軟件開發(fā)的第二個重要分工就是最好有專門的架構(gòu)設(shè)計人員，架構(gòu)設(shè)計和總體設(shè)計要由1-2個人來完成，以保證高度的概念完整性和設(shè)計統(tǒng)一)
善于對設(shè)計作出取舍。項目開發(fā)的三要素是成本、質(zhì)量與進度。在保證質(zhì)量的前提下，為了項目進度不出現(xiàn)大的偏差，EAS項目組并沒有過分強調(diào)技術(shù)，特別是在考慮進度的情況下，犧牲了系統(tǒng)的部分可擴展性。雖然這為系統(tǒng)的后期維護帶來一定隱患，但卻能夠有效地保證項目的進度。從 EAS最初的架構(gòu)設(shè)計來看，我們引入了 Castle與AOP，試圖簡化ORM以及橫切關(guān)注點例如日志、異常、權(quán)限、事務(wù)等功能的實現(xiàn)。同時，希望采用WCF，利用SOA思想建立松散耦合的面向服務(wù)應(yīng)用程序。但隨著客戶需求的變化，我們果斷地放棄了采用WCF的構(gòu)想，同時又克服了技術(shù)困難，堅持了對Castle與AOP的使用，并為此成立了框架開發(fā)小組。事實證明，在技術(shù)的抉擇上我們作出了正確的決定。
重視UI原型設(shè)計。系統(tǒng)的原型設(shè)計與需求分析相輔相成。如果有好的原型版本交付給客戶，則客戶更能夠理解系統(tǒng)的實現(xiàn)，促進溝通的有效性與準確性。在EAS 項目中，我們從一開始就確立了原型設(shè)計小組，并在分析需求階段，就開始了原型設(shè)計。這一做法無疑在客戶溝通、需求確認、UI設(shè)計等方面都發(fā)揮了很大的作用。但是，我們在這一點上，由于缺乏專門的UI設(shè)計人員，因此，這一工作還存在很大的缺陷，甚至于UI的設(shè)計為迭代版本的交付帶來了很大的障礙。在項目后期，關(guān)于UI的bug是最多。因此，我們認為在開發(fā)類似的WEB應(yīng)用程序時，應(yīng)盡早確立UI設(shè)計規(guī)范，以約束所有的UI設(shè)計。同時，必須培養(yǎng)專門的UI設(shè)計師，在開始原型設(shè)計時，就盡快完成UI交互的設(shè)計。并且，必須成立專門的UI 設(shè)計小組，在需求階段與需求分析師合作，在編碼階段與開發(fā)人員合作。(原型設(shè)計是加強前期用戶需求挖掘和減少后期需求變更的重要手段，不一定需要專門的UI設(shè)計人員，原型設(shè)計可以由需求分析師來完成)
測試
測試成員應(yīng)了解需求。如果不了解需求，測試人員無法編寫正確的測試用例，同時在測試過程中，也可能因為錯誤地理解需求，從而導(dǎo)致報告錯誤的bug，影響開發(fā)人員效率。加強開發(fā)人員與測試人員的合作。開發(fā)人員必須及時響應(yīng)測試人員提交的bug。而測試人員也應(yīng)跟蹤開發(fā)人員對bug的修復(fù)情況。(測試人員應(yīng)該要意識到自己和需求分析人員的區(qū)別，測試人員不用想需求分析人員一樣分析和開發(fā)業(yè)務(wù)，但是他們必須和需求分析人員一樣對已經(jīng)分析出來的需求和業(yè)務(wù)高度熟悉)
測試之初必須確定測試原則，對bug的嚴重程度進行分級。同時，必須確定修復(fù)bug的優(yōu)先級別。
進度管理
保證項目進度不出現(xiàn)大的偏差的前提是制定一個好的項目計劃。必須根據(jù)項目規(guī)模，成員情況，技術(shù)難度等多方面考慮整個項目計劃。如果項目的deadline已經(jīng)確定，則必須采用一些方法來保障項目計劃的完成。首先是選擇符合項目的軟件開發(fā)生命周期。通常情況下，并不建議采用瀑布開發(fā)方式。最佳的辦法，應(yīng)該是 RUP或者敏捷開發(fā)，然后結(jié)合原型法制訂項目計劃。這樣可以規(guī)避因為需求變更產(chǎn)生的風險。
其次，要每日跟蹤項目的進展情況?？梢酝ㄟ^晨會、周會以及項目日報、項目周報了解項目進展情況。同時，需要為各個小組指定進度跟蹤人，根據(jù)各個小組長的日報，判斷實際的進度是否與計劃出現(xiàn)偏差。
要制定項目進度偏差的應(yīng)對方法。一旦項目進度出現(xiàn)了偏差，必須采取相應(yīng)錯誤解決問題?；蛘咄ㄟ^加班、增加人手、申請項目進度等方法及時作出響應(yīng)。
及時向項目成員匯報項目進度情況。只有讓各個項目成員了解到項目現(xiàn)狀，才能夠給每個成員增加壓力，不至于松懈。同時，也能夠使得每個成員能有一個目標，而不至于茫然失措。
制定項目計劃時，必須考慮階段評審與同行評審的時間。這一點在EAS項目中做得不夠好。其中原因也是由于項目進度本身較緊的緣故。注意維護項目進度跟蹤表與項目進度偏差跟蹤表。讓項目管理部以及QA及時掌握項目進度，有利于對項目進度的管理。
變更管理
變更包括需求變更、人員變更。如果不控制好，兩者對項目的進展都會帶來災(zāi)難性的后果。需求變更在前面已經(jīng)敘述，而EAS項目中發(fā)現(xiàn)人員變更的情況也非常嚴重，因此這里重點介紹關(guān)于人員變更的管理。
如果發(fā)生人員進入的情況，那么對項目帶來的通常都會是好的影響。但我們也必須注意如何讓新成員更快地融入團隊。整體上講，如果需要新成員加入，發(fā)生變更的最佳時機是項目前期。如果在項目中后期加入新成員，無疑則意味著項目出現(xiàn)了災(zāi)難性的后果。而新增加的成員，由于不熟悉項目，所能帶來好的影響也是有限的。如果不處理好新成員與老成員之間的合作關(guān)系，反而會帶來負面影響。
人員的退出很多時候是不可控的，同時對項目帶來的影響也是不可估計的。為了將這些影響降到最低，就必須在項目開始之初就要確立編碼規(guī)范。同時，還應(yīng)該重視對文檔的維護與更新。而在人員退出時，必須做好交接工作。同時，還應(yīng)對這種變更進行合理的評估，并及時報告項目管理部，并與客戶及時溝通。如果對項目進度有嚴重影響，應(yīng)爭取最大的努力取得客戶的理解，提出項目延期的申請。
風險管理
要在項目開始之初就考慮到項目過程中可能出現(xiàn)的所有風險，是不現(xiàn)實的。但是，我們必須考慮對風險的管理，尤其是在制訂項目計劃以及創(chuàng)建團隊的時候，考慮這一因素。風險有很多，包括需求的風險、進度的風險、質(zhì)量的風險以及技術(shù)風險等。必須制定一套完整的風險管理計劃，而一旦發(fā)生了風險，則必須及時響應(yīng)，組織相關(guān)人員解決風險。不能忽略任何一個小的風險，否則一個小的風險到最后會造成大的災(zāi)難。風險的把握必須要有項目經(jīng)理與系統(tǒng)架構(gòu)師把關(guān)。
成員管理
不團結(jié)的項目組是無法保證項目的成功地。項目經(jīng)理與項目組長在管理團隊成員時，必須時刻注意成員狀況，即使處理工作出現(xiàn)的矛盾與摩擦，隨時保證團隊合作精神得到最大程度的執(zhí)行。
持續(xù)地保證項目成員的士氣非常重要。項目每取得一個階段性的進展，必須告知全體成員，如此才能收獲成功的信心。項目開發(fā)過程需要注意勞逸結(jié)合。一味地強制性加班，只能降低項目成員的工作效率。項目過程中，如能適當?shù)亻_展一些活動，無疑能夠讓團隊成員感受到項目組的集體氣氛。在階段實現(xiàn)的重要時刻，項目經(jīng)理必須注意通過文字、語言等激勵項目組成員。而項目經(jīng)理的自信也是保證成員士氣的一個關(guān)鍵。
必須注意了解團隊成員的心理狀態(tài)與工作狀態(tài)。項目成員的戰(zhàn)斗力除了是個人的能力發(fā)揮之外，一個好的領(lǐng)導(dǎo)也是至關(guān)重要的。因此，必須選擇合適的項目組長，通過他們掌握整個項目團隊成員的工作進展。同時，還要了解每個成員的能力，以安排合適的角色與崗位。
重視開發(fā)組與測試組以及項目管理小組的合作。項目組是一個整體，每個成員的角色不同，但大家都是團隊的重要一員。
作者:張逸具有多年的軟件開發(fā)與設(shè)計經(jīng)驗，他是兩屆微軟最有價值專家（MVP），著作/譯作包括《軟件設(shè)計精要與模式》、《WCF服務(wù)編程》。張逸熟悉C#，ASP.NET，WCF等技術(shù)，同時深諳面向?qū)ο箢I(lǐng)域的相關(guān)技術(shù)。目前，他主要從事 SOA企業(yè)信息解決方案的設(shè)計與研究，以及敏捷方法的推廣與實踐。張逸是捷道·敏捷堂的創(chuàng)始人。
聯(lián)系客服
