1、文件標識：集成化軟件研發流程 IDP當前版本：7.0作 者：林銳審 核：文件狀態： 草稿 正式發布 正在修改完成日期：2009 年 11 月上海漫索計算機科技有限公司上海漫索計算機科技有限公司http:/ 集成化軟件研發流程集成化軟件研發流程 IDPIDP 7.07.0 1目 錄A. 集成化軟件研發流程圖.5B. 過程域和主要成果清單.6C. 研發組織結構模型.7D. 角色職責表.8第 1 章 營銷客服過程.101.1 產品管理.101.1.1 產品策劃.101.1.2 調研分析.111.1.3 產品立項與開發.121.1.4 產品銷售與服務.131.2 銷售管理.131.2.1 營銷策劃.1

2、31.2.2 銷售跟蹤.141.2.3 合同管理.151.3 客戶服務.161.3.1 受理.171.3.2 處理.171.3.3 審核關閉.171.3.4 客戶反饋.171.4 客戶信息管理.18第 2 章 項目管理過程.192.1 立項管理.192.1.1 立項申請.192.1.2 PMO受理.20 22.1.3 立項評審.212.1.4 項目啟動.222.2 結項管理.232.2.1 結項申請.232.2.2 PMO受理.242.2.3 結項評審.252.2.4 遺留問題跟蹤.252.2.5 項目工作總結.262.3 項目規劃與監控.262.3.1 項目人員角色.262.3.2 任務進度

3、管理.272.3.3 項目成本管理.282.3.4 項目評審（決策評審和技術評審）.282.4 變更控制.292.5 溝通管理.312.6 問題跟蹤.33第 3 章 項目研發過程.343.1 需求開發與管理.343.1.1 需求調研.343.1.2 需求分析.353.1.3 需求定義.353.1.4 需求評審.363.1.5 需求跟蹤.363.2 系統設計.363.2.1 軟件系統設計.363.2.2 設計評審.37 33.3 模塊開發與集成.373.4 測試與缺陷跟蹤.383.4.1 提交測試.393.4.2 測試準備.393.4.3 執行測試.403.4.4 缺陷跟蹤.403.4.5 消除

4、缺陷.413.5 交付與驗收.423.5.1 撰寫文檔.423.5.2 軟件部署.423.5.3 用戶培訓.433.5.4 試用和驗收.433.6 軟件維護.443.6.1 接受維護請求.443.6.2 分析維護請求.453.6.3 執行維護.45第 4 章 支持過程.464.1 軟件配置管理.464.1.1 軟件配置管理的概念.464.1.2 軟件代碼管理的一般規則.464.2 文檔管理.474.2.1 文檔管理的特征.474.2.2 項目文檔管理的一般規則.484.3 質量保證.489.4 日志和周報.494.5 績效評估.49 44.5.1 定義績效體系.494.5.2 填寫績效表格.5

5、04.6 知識庫管理.51A. 集成化軟件研發流程圖B. 過程域和主要成果清單過程域主要工作成果產品管理（產品策劃，調研分析，立項）產品建議書，產品調研報告，立項申請書銷售管理（營銷策劃，銷售跟蹤，合同管理）營銷方案，銷售跟蹤表，合同管理表客戶服務（受理，處理，關閉，反饋）客服跟蹤表營銷客服過程客戶信息管理客戶信息表立項管理（立項申請，PMO 受理，立項評審，項目啟動）立項申請書，立項評審報告，項目總體計劃結項管理（結項申請，PMO 受理，結項評審，遺留問題跟蹤，項目工作總結）結項申請書，結項評審報告，項目工作總結項目規劃與監控（人員角色，任務進度，項目成本，項目評審）人員角色表，任務進度表，

6、成本表，評審報告 變更控制變更控制報告溝通管理溝通記錄項目管理過程問題跟蹤問題跟蹤表需求開發與管理需求規格說明書，需求跟蹤表系統設計系統設計說明書模塊開發與集成模塊文檔（需求和設計） ，軟件代碼測試與缺陷跟蹤測試用例，測試報告，缺陷跟蹤表交付與驗收安裝手冊，使用手冊，驗收報告項目研發過程維護維護記錄軟件配置管理，文檔管理，知識管理軟件配置庫，文檔庫，知識庫質量保證質量保證檢查表，問題跟蹤表日志和周報工作日志，周報支持過程績效分析績效報表 1C. 研發組織結構模型營銷和客服角色項目成員角色支持角色管理角色 研發總監銷售人員 產品經理需求分析員系統設計師PMO項目經理 決策委員會開發工程師測試人員

7、質量保證員各部門經理配置管理員客服人員 2D. 角色職責表角色該角色在研發流程中的主要職責研發總監（1）參與立項評審，為項目分配合適的人力資源。（2）及時了解所有項目的人力資源、進度、質量情況，協商處理問題。（3）在項目結束時，對項目進行綜合評估。決策委員會決策委員會一般由部門經理以上職位的人員組成，主要職責是參與決策評審（如立項評審） 。部門經理人力資源分配和協調，提升人員的能力，考核人員績效。PMO受理立項申請，受理結項申請，項目過程檢查。產品經理（1）通過調研分析，進行產品策劃，撰寫產品建議書，申請立項。（2）跟蹤產品開發過程，及時試用產品，糾正偏差，給出優化建議。（3）幫助銷售人員宣傳

8、、銷售該產品，及時獲取客戶的反饋，改進產品。銷售員（1）負責本公司產品的銷售，鑒定合同，跟蹤合同執行過程。（2）撰寫合同項目的立項申請書。客服人員集中受理客戶問題需求，指定合適的處理人，審核關閉問題，獲取客戶反饋。項目經理項目經理是立項之后的項目主要責任人，主要職責是帶領團隊在預定的時間和成本之內，開發并交付質量合格的項目（產品） 。項目經理對本項目的進度、質量負主要責任。（1）負責本項目的日常管理（如任務進度管理，項目評審，變更控制，溝通管理，問題跟蹤等） ，以及可能存在的跨項目、跨部門協調。（2）如果本項目沒有專門的需求分析員，那么項目經理承擔需求分析工作。如果本項目缺乏足夠的開發工程師，

9、那么項目經理應當承擔某些模塊開發。（3）在項目結束時，總結知識財富和經驗教訓，完善文檔。對項目成員的業績進行評估。需求分析員（1）負責本項目需求調研、分析、定義，撰寫詳細的需求文檔。（2）將需求準確地傳達給相關人員（如開發、測試、客戶等） ，隨著項目進展，及時完善需求文檔。系統設計師（1）根據需求開展系統設計，包括構架設計、數據庫設計、用戶界面設計等。（2）撰寫設計文檔，并將設計成果準確地傳達給其他項目成員。開發人員（1）按照項目經理分配的任務執行開發工作，并清楚地交付給測試人員（準備測試） 。如果測試人員報告缺陷，應及時消除缺陷。對自己工作成果的質量負最大責任。（2）對自己的源代碼進行配置管

10、理，撰寫自己承擔的模塊文檔。 3測試人員（1）了解項目需求，和項目經理商議測試計劃，設計測試用例。（2）根據計劃執行測試，找出盡可能多的缺陷。使用缺陷跟蹤工具，及時將測試信息反饋給相關責任人。質量保證員（1）跟蹤每個項目的開發過程，重點檢查需求文檔、設計文檔、變更記錄、用戶文檔是否符合規范。（2）參加需求評審和設計評審。（3）如果發現項目問題，先和責任人溝通，如果難以解決，則由上級領導協調。配置管理員（1）為所有項目創建配置庫，為用戶分配合適的權限，負責信息安全和備份。（2）指導開發人員使用配置管理軟件。 4第 1 章 營銷客服過程1.1 產品管理產品管理流程如圖 6-1 所示，主要活動有：產

11、品策劃，調研分析，產品立項與開發，產品銷售與服務。該流程的主要工作成果和責任人見表 1-1。圖 1-1 產品管理流程主要活動主要工作成果主要責任人產品策劃產品建議書產品經理調研分析產品調研分析報告產品經理產品立項與開發立項申請書，最終產品產品經理，項目經理產品銷售與服務產品宣傳材料，銷售合同，客服單產品經理，銷售人員，客服人員表 1-1 產品管理流程的成果清單和責任人1.1.1 產品策劃產品經理負責產品策劃活動。產品經理應主動尋求研發部門的幫助，由產品經理牽頭，撰寫產品建議書 ，模板見表 1-2。提示：本產品立項之后，項目團隊將進一步細化產品需求、設計方案和開發計劃等。產品建議書1. 產品概述

12、產品概述 用簡練的語言說明本產品“是什么”， “什么用途”。2. 產品開發背景產品開發背景 從內因、外因兩方面闡述產品開發背景，重點說明“為什么”要開發本產品。 （1）內因方面著重考慮：開發方的短期、長期發展戰略；開發方的當前實力。企業戰略調研分析產品策劃產品經理產品立項 與開發產品銷售與服務項目經理銷售和客服人員 5 （2）外因方面著重考慮：市場需求及發展趨勢；技術狀況及發展趨勢。3. 消費群體特征消費群體特征 （1）闡述本產品消費群體的特征； （2）說明消費者對產品的功能性需求和非功能性需求； （3）說明本產品如何滿足消費者的需求，以及給消費者帶來什么好處。4. 產品主要功能和特色產品主要

13、功能和特色 （1）產品的主要功能列表； （2）說明本產品的特色。5. 產品設計方案和關鍵技術產品設計方案和關鍵技術 （1）闡述設計方案及原理，如果有多種方案，需比較優缺點。（2）闡述本產品的一些關鍵技術，評價技術實現的難易程度。（3）確定哪些產品部件應當采購、外包開發或者自主研發，說明理由，分析相應的風險。6. 產品開發和上市計劃產品開發和上市計劃如果產品有多個版本，估算各版本的開發時間和上市時間，以及人員和資金。表 1-2 產品建議書1.1.2 調研分析產品經理在做產品策劃時，應同步進行調研分析。產品經理撰寫產品調研分析報告 ，模板見表 1-3，目的是為公司決策提供充分的、有價值的信息。提示

14、：如果不做調研分析的話，那么產品建議和立項管理都建立在空想之上。調研者應當客觀地對待被調查的事物，不可有意往“好處”或者“壞處”設想。所獲取的數據、圖表等信息要真實并且有據可查，不可憑空捏造。調研分析的主要內容有：消費者（購買者，使用者，影響者）調研； 競爭對手和同類產品調研；政策調研；技術可行性分析；知識產權分析；成本收益分析；產品調研分析報告1. 消費者調研消費者調研（1）購買者的特征和需求。（2）使用者的特征和需求。（3）影響者的特征和需求。 62. 競爭對手與同類產品調研競爭對手與同類產品調研（1）各競爭對手在研發、銷售、資金、品牌等方面的實力。（2）同類產品的功能、質量、價格，以及主

15、要優點和主要缺點。3. 政策調研政策調研（1）有無政策“支持”或者“限制”。（2）有無地方政府（或其它機構）的“扶持”或者“干擾”。（3）如何利用（應對）政策。4. 技術和時間可行性分析技術和時間可行性分析（1）本產品“做得了嗎？”、 “做得好嗎？”。（2）按照正常的運作方式，能及時開發完成本產品嗎？投入市場的時間合適嗎？5. 知識產權分析知識產權分析（1）分析是否已經存在某些專利將妨礙本產品的開發與推廣；（2）分析本產品能否得到知識產權保護，如何獲得？6. 成本成本效益分析效益分析（1）估算總成本。（2）估算總收益。表 1-3 產品調研分析報告1.1.3 產品立項與開發產品經理負責立項申請，

16、撰寫立項申請書 ，提交給 PMO，進入立項管理流程。如果本產品被批準立項，則：項目經理將管理本產品的開發過程，對產品的質量和進度負責。產品經理要跟蹤開發過程，及時了解產品的開發進度和工作成果質量。如果產品經理發現開發工作偏離了產品需求和預定的計劃，應當及時和項目經理溝通，糾正偏差。建議開發團隊采用增量模式來開發產品，每次發布新的版本，既要請測試人員進行測試，又要請產品經理來體驗（試用） 。產品經理應當站在客戶的角度來體驗（試用）當前產品：產品經理應當站在客戶的角度來體驗（試用）當前產品：如果發現產品中的缺陷，則向開發人員報告缺陷，開發人員及時消除缺陷。若產品經理向項目經理提出改進建議，雙方應先

17、就需求和改進措施達成共識，然后開發人員執行相應的改進措施。 71.1.4 產品銷售與服務產品開發完成之后，產品經理負責：撰寫產品介紹文件（如 ppt 文件） 。制作本產品的宣傳網頁，設法在更多的網站發布產品信息。可能需要設計和制作宣傳頁（印刷品） 。產品經理對本公司銷售人員進行產品培訓，使銷售人員充分了解本產品的特性。上述工作完成之后，進入銷售管理流程和客戶服務流程。產品經理跟蹤銷售和客服過程，產品經理跟蹤銷售和客服過程，收集并分析客戶意見，及時改進產品策劃。收集并分析客戶意見，及時改進產品策劃。1.2 銷售管理銷售管理流程如圖 1-2 所示，主要活動有：營銷策劃，銷售跟蹤，合同管理。該流程的

18、主要工作成果和責任人見表 1-4。圖 1-2 銷售管理流程主要活動主要工作成果主要責任人營銷策劃營銷方案銷售經理銷售跟蹤銷售跟蹤表，銷售合同銷售人員合同管理合同實施、收款、付款跟蹤表銷售人員表 1-4 銷售管理流程的成果清單和責任人1.2.1 營銷策劃銷售部門商議營銷方案，銷售經理分配任務給執行人（可以多人） 。每個執行人填寫執產品或項目營銷策劃銷售人員- 合同管理 -實施計劃與跟蹤收款計劃與跟蹤付款計劃與跟蹤銷售經理銷售人員- 銷售跟蹤 -接觸客戶客戶分析售前服務與跟蹤簽訂合同 8行情況，模板見表 1-5。營銷方案方案名稱制定人起止日期執行人A, B銷售計劃內容執行人執行情況狀態日期A未開始

19、，進行中，完成B表 1-5 營銷方案1.2.2 銷售跟蹤銷售人員負責：（1）銷售本公司的產品；（2）從客戶那里承接項目。第一步，接觸潛在客戶。第一步，接觸潛在客戶。銷售人員通過各種途徑接觸潛在客戶，了解客戶（公司）信息和客戶的需求。第二步，客戶分析。第二步，客戶分析。銷售人員應當撰寫客戶分析報告 ，為公司提供充分的客戶信息（同時也記錄了自己的工作業績） ，格式參見表 1-6。由于售前服務會消耗公司的資源（人力、金錢、時間） ，如果客戶最終不簽訂采購合同，那么無效的售前服務將給公司增加成本。為了避免浪費公司的資源，節約成本，銷售部門需為了避免浪費公司的資源，節約成本，銷售部門需商議是否為潛在客戶

20、提供進一步的售前服務，以及服務的程度。商議是否為潛在客戶提供進一步的售前服務，以及服務的程度。客戶分析報告客戶分析1. 客戶介紹2. 客戶需求3. 采購可能性4. 成本效益分析5. 風險分析部門意見說明是否為潛在客戶提供進一步的售前服務，以及服務的程度。 9表 1-6 客戶分析報告第三步，售前服務與跟蹤。第三步，售前服務與跟蹤。銷售人員根據潛在客戶需求，提供產品演示、講解、答疑等服務。如果承接客戶的招標項目，則按客戶規定的程序進行“投標、答辯、商務談判” 。如果需要，銷售人員應主動向研發部門申請技術支持。銷售人員填寫銷售跟蹤表，模板見表 1-7。銷售跟蹤表客戶銷售單內容對客戶的承諾跟蹤人銷售單

21、狀態跟蹤說明跟蹤日期表 1-7 銷售跟蹤表第四步，簽訂合同。第四步，簽訂合同。如果客戶確定采購，可能有 2 種方式：（1）商務談判結束后，雙方責任人將簽訂正式的合同。雙方責任人仔細審查 合同中的每個條款，確保合同沒有錯誤和隱患，然后簽字、蓋章，使合同生效。（2）客戶承諾采購，但是目前不能簽訂合同。遇此情況，銷售部門需請示公司領導，決定做還是不做。提示：如果公司銷售產品，則需制定產品銷售合同模板。如果公司承接客戶項目，則需制定項目銷售合同模板。1.2.3 合同管理銷售人員根據合同信息，制定實施計劃、付款計劃、收款計劃，并跟蹤這些計劃的執行情況，模板見表 1-8。合同管理客戶名稱客戶方負責人合同名

22、稱我方負責人 10合同簽訂日期計劃完成日期合同摘要計劃實施日期計劃說明執行人執行狀態/情況說明計劃收款日期金額及用途說明執行人執行狀態/情況說明計劃付款日期金額及用途說明執行人執行狀態/情況說明表 1-8 合同管理表（實施、收款、付款）1.3 客戶服務客戶服務流程如圖 1-3 所示，主要活動有：受理，處理，審核關閉，客戶反饋。該流程的主要工作成果和責任人見表 1-9。圖 1-1 客戶服務流程主要活動主要工作成果主要責任人受理客服人員處理指定處理人審核關閉客服跟蹤表客服人員客戶報告問題需求審核關閉受理客服人員處理客戶反饋指定處理人客服人員客戶生成項目缺陷，項目任務，項目需求等 11客戶反饋客戶表

23、 1-9 客戶服務流程的成果清單和責任人1.3.1 受理客戶通過各種途徑報告問題（包括問題、需求、建議等） 。客服人員記錄客戶問題，并指定處理人，模板見表 1-10。1.3.2 處理如果處理人能夠直接解決客戶問題，則填寫處理說明，把狀態置為“解決待關閉” 。如果問題比較復雜，可以生成“項目任務、項目缺陷、項目需求”等。若“任務、缺陷、需求”都已經完成，再把客戶問題的狀態置為“解決待關閉” 。1.3.3 審核關閉當客戶問題的狀態為“解決待關閉”時，客服人員驗證這個問題，如果的確已經解決，則把狀態置為“關閉” ，并填寫關閉說明。1.3.4 客戶反饋客服人員告知客戶其問題已經解決，并獲取客戶的反饋意

24、見。客服跟蹤表標題編號客戶/聯系人客服類型內容受理人受理時間受理說明處理人處理時間處理說明關閉人關閉時間 12關閉說明客戶反饋表 1-10 客服跟蹤表1.4 客戶信息管理營銷人員和客服人員均可填寫客戶公司信息和客戶聯系人信息（模板見表 1-11） 。客戶信息表客戶公司簡稱客戶狀態客戶公司全稱客戶類型電話所屬區域傳真所屬行業郵政編碼所屬城市地址客戶公司簡介客戶分析聯系人姓名部門/職務聯系電話Email /即時通信表 1-11 客戶信息 13第 2 章 項目管理過程2.1 立項管理立項管理的流程如圖 7-1 所示，主要活動有：立項申請、PMO 受理、立項評審和項目啟動。該流程的主要工作成果和責任人

25、見表 2-1。 圖 2-1 立項管理流程關鍵活動主要工作成果主要責任人自主產品立項申請立項申請書，產品建議書，調研分析報告產品經理合同項目立項申請立項申請書，相關合同文件合同項目的銷售人員PMO 受理立項評審通知PMO 立項評審立項評審結論立項評審委員會項目啟動項目總體計劃項目經理表 2-1 立項管理流程的主要工作成果和責任人2.1.1 立項申請對于自主產品，產品經理撰寫立項申請書 ，并將相關附件（主要是產品建議書，產品調研分析報告）一起提交給 PMO。對于合同項目，銷售人員撰寫立項申請書 ，并將相關附件（主要是合同文件）一起提交給 PMO。立項申請書的格式見表 2-2。合同項目立項申請自主產

26、品立項申請項目啟動產品經理項目團隊銷售人員PMO受理立項評審 14立項申請書項目名稱項目類型合同項目 / 自主產品申請人申請日期1. 項目介紹2. 本項目對公司的價值3. 項目進度要求4. 項目所需人力資源5. 項目成本估算6. 立項可行性分析6.1 技術可行性分析6.2 成本-效益分析6.3 競爭分析6.4 風險分析6.5 SWOT 分析表 2-2 立項申請書的格式2.1.2 PMO 受理PMO 受理人審閱立項申請書和相關附件，如果發現文件內容不合流程要求或者質量不合格，則退還給申請人重新改進，直到文件合格為止。之后，PMO 受理人將文件轉交給研發總監。提示：這樣做的目的是提高立項評審的效率

27、。研發總監根據項目的特征，選定“立項評審委員會” ，確定評審時間。PMO 受理人發起立項評審通知，格式見表 2-3。提示：如果項目涉及面很廣，難以一次性在立項評審會議上決定，那么研發總監可以先召開“預評審”會議，之后再進行正式的立項評審。立項評審通知項目名稱申請人評審文件評審時間地點評審人員部門和職務評審負責人評委其他參加人員評審內容表 2-3 立項評審通知 152.1.3 立項評審PMO 通知相關人員在既定的時間參加立項評審會議， 立項評審報告格式見 2-4。評審負責人主持評審會議，把控會議進程。立項申請人陳述立項申請書和相關文件的主要內容。評審委員提出疑問，立項申請人解答。雙方應當對有爭議

28、的內容提出處理意見、達成共識。每個評委發表（填寫）自己的評審意見。評審負責人匯總所有評審委員的評審意見，給出評審結論：“同意立項”或者“不同意立項” 。提示：評審期間應當商議“項目人力資源計劃” ，避免立項之后人員不能到位的問題。記錄員（PMO 受理人）填寫會議記錄。評審結束后，公司級的項目由公司領導（研發總監）給出“終審結論和意見” ，部門級項目由部門經理給出“終審結論和意見” 。XXX 立項評審報告評委姓名評審意見說明同意或者不同意的理由評審負責人評審結論、匯總意見和人力資源計劃評審結論： 同意立項 不同意匯總意見和人力資源計劃：記錄員會議記錄領導終審結論和意見評審結論： 同意立項 不同意

29、意見：表 2-4 立項評審報告 162.1.4 項目啟動第第 1 步步 確定項目團隊確定項目團隊部門經理根據項目特征和立項評審報告，任命合適的項目經理，并確定該項目的主要成員。項目經理對立項之后的項目進度和質量負責。項目成員向項目經理匯報工作。項目經理向部門經理匯報工作。第第 2 步步 確定項目總體計劃確定項目總體計劃項目經理和項目成員共同商議，制定初步的項目總體計劃 ，格式參見表 2-5。部門經理審批該項目總體計劃 ，如果有修改意見，請項目經理及時修正。提示：在項目開發過程中，項目經理可以不斷細化項目計劃和修改項目計劃，詳見“項目規劃與監控”過程域。項目總體計劃項目名稱計劃開始日期項目經理計

30、劃結束日期1.項目介紹說明項目目標、關鍵因素及優先級2.項目成員表姓名角色說明（主要職責和工作時間）3.任務進度表名稱（ 階段 / 任務 / 評審點）執行人計劃起止日期4.部門經理審批審批意見表 2-5 項目總體計劃第第 3 步步 初始化管理平臺初始化管理平臺（1）PMO受理人或部門經理在管理平臺中創建該項目。 17（2）項目經理登錄管理平臺，進入該項目，執行初始化操作：初始化項目成員表（含角色職責）。把立項會議的相關文件上傳到本項目的文檔庫中。根據項目總體計劃初始化任務進度表。第第 4 步步 初始化軟件配置管理工具初始化軟件配置管理工具（1）部門經理（或指定配置管理員）創建該項目的配置庫，授

31、予項目經理控制本項目的權限。（2）項目經理再分配權限給其他項目成員。2.2 結項管理結項管理的流程如圖 7-2 所示，主要活動有：結項申請、PMO 受理、結項評審、遺留問題跟蹤和項目工作總結。該流程的主要工作成果和責任人見表 2-6。 圖 2-2 結項管理流程關鍵活動主要工作成果主要責任人結項申請結項申請書項目經理PMO 受理結項評審結項評估報告PMO，結項評審委員會遺留問題跟蹤問題跟蹤表項目經理，PMO項目工作總結個人工作總結，知識庫所有項目成員表 2-6 結項管理流程的主要工作成果和責任人結項申請項目經理PMO 受理結項評審遺留問題跟蹤項目工作總結：個人工作總結 分析提煉 知識入庫所有項目

32、成員 182.2.1 結項申請正常情況下，當項目開發工作結束時，項目經理撰寫結項申請書 ，遞交給 PMO。 結項申請書的格式見表 2-6。對于異常結束的項目，部門經理應當明確指示項目經理，確定何時結束項目。部門經理應當向員工們解釋為什么要異常終止項目。異常中止項目的結項流程與正常結項流程相同。2.2.2 PMO 受理PMO受理人審閱結項申請書和相關附件，如果發現文件內容不合流程要求或者質量不合格，則退還給申請人重新改進，直到文件合格為止。之后，PMO受理人將文件轉交給研發總監。提示：這樣做的目的是提高立項評審的效率。研發總監根據項目的特征，選定“結項評審委員會” ，確定評審時間。PMO受理人發

33、起結項評審通知，格式和立項評審通知相同（見表2-3） 。結項申請書項目名稱項目經理1. 項目完成情況計劃情況實際情況主要功能項目起止日期人員和工作量項目成本應遞交的成果2. 資產清單（資金和設備，軟件等）說明、處理建議3. 專利和版權4. 項目價值體現闡述：項目質量，市場價值，成本效益，對機構的貢獻5. 人員業績工作業績描述評價人人員 A人員 B項目經理簽字 19表 2-6 結項申請書2.2.3 結項評審PMO 通知相關人員在既定的時間參加結項評審會議。評審負責人主持評審會議，把控會議進程。立項申請人陳述結項申請書的主要內容。評審委員提出疑問，立項申請人解答。雙方應當對有爭議的內容提出處理意見

34、、達成共識。每個評委發表（填寫）自己的評審意見。評審負責人匯總所有評審委員的評審意見，給出評審結論：“同意結項”或者“不同意結項” 。記錄員（PMO 受理人）填寫會議記錄。 結項評審報告的格式見表 2-7。XXX 結項評審報告評委姓名評審意見評審負責人評審結論和匯總意見評審結論： 同意結項 不同意匯總意見：（1）項目任務完成情況。（2）項目資產處理意見。（3）發掘可以重復利用的知識財富，給出應用建議。（4）項目的價值：市場價值、成本效益、技術積累等記錄員會議記錄表 2-7 結項評審報告提示：項目結項后，該項目的人力資源和設備資源將被釋放，應用于新的項目。項目成員有義務維護自己參與的項目。 20

35、2.2.4 遺留問題跟蹤項目結項后，尚有一些遺留問題，項目經理填寫“問題表” ，PMO 人員跟蹤該問題表，確保所有問題得到妥善處理。詳見“問題跟蹤”過程域。2.2.5 項目工作總結第 1 步。所有項目成員都要撰寫個人工作總結 ，格式見表 2-8，在公司范圍內共享經驗教訓。第 2 步。項目經理召集所有項目成員，討論每個人的工作總結，提煉出知識財富。第 3 步。把知識財富按照一定的格式保存在集成化管理平臺中。項目名稱 個人工作總結撰寫人日期工作總結1. 本人在項目中的主要任務2. 遇到哪些問題，如何解決3. 經驗教訓和建議表 2-8 個人工作總結2.3 項目規劃與監控項目規劃（Project Pl

36、anning）是指對本項目的人力資源、任務進度、成本等做出合適的安排，制定出一些計劃（包括宏觀的和細節的） ，使大家按照計劃行事，最終順利地達到預定的目標。項目監控是將項目實際情況與項目計劃進行對比，如果發現某些因素（如人力資源、任務進度、成本等）的偏差比較大，那么及時分析原因，給出糾正措施。項目監控至少有兩個好處：（1）避免原本合理的計劃在實施過程時落空；（2）避免“執迷不悟”地按照原本不合理的計劃行事。項目規劃與監控的重點是：“人員角色” 、 “任務進度” 、 “項目成本” 、 “項目評審” 。2.3.1 項目人員角色項目經理向部門爭取“完成本項目充分必要的人員” ，項目人員到位后，項目經

37、理確定每 21個人員在本項目的角色、工作內容和時間，格式見表 2-9。姓名角色工作描述（簡要說明工作內容和時間）表 2-9 項目人員角色表2.3.2 任務進度管理項目經理根據“本項目需求和人力資源”分解任務，和項目成員協商后，把任務交給最合適的人員去執行。簡而言之，就是要“知人善用” 。 “知人”是指領導者應當非常了解他的團隊成員，包括知識技能和性格愛好等等。 “善用”是指讓團隊各成員揚長避短，使團隊戰斗力達到最強。項目經理還要有意識地鍛煉、提升成員們全局開發的能力，要保證至少有一人可以替換別人的工作。否則萬一某人缺席（如離職、休假等） ，將導致工作被中斷。任務進度管理的流程如圖 2-3 所示

38、，主要活動和步驟如下：圖 2-3 任務進度管理的流程第第 1 步步. 制定任務進度計劃制定任務進度計劃項目經理和項目成員們共同協商任務，大家達成共識后制定任務進度計劃，每個任務的主要數據如下：任務名稱，任務描述，預計工作成果開始日期，計劃完成日期任務執行人（可以多個） ，計劃工作量第第 2 步步. 填寫執行信息填寫執行信息每個任務的執行人（可以多個）填寫執行信息，主要數據如下：執行人，填寫日期1. 制定任務計劃2. 填寫執行信息調整3. 糾正偏差 22任務狀態（進行中，已完成）當前進度（百分比）實際工作量，執行說明第第 3 步步. 糾正偏差糾正偏差如果任務的執行情況和計劃之間的偏差比較大（例如

39、工作量、完成日期的誤差超過20） ，項目經理應當和執行人交流，分析原因并給出解決措施：（1）若原計劃太樂觀了，那么適當修改原計劃；（2）若執行人工作不得力，那么要求執行人加班追趕進度。2.3.3 項目成本管理項目經理應當懂得“非財務人員”的項目成本管理。項目成本管理的流程如圖 2-4 所示，主要活動和步驟如下：圖 2-4 項目成本管理的流程圖第第 1 步步. 制定項目預算制定項目預算項目經理制定項目預算表，每條記錄的主要數據有：金額；預算類型（例如硬件、軟件、辦公消耗等） ；用途說明。第第 2 步步. 記錄實際開支記錄實際開支項目經理和項目成員記錄實際開支，每條記錄的主要數據有：經辦人，開支時

40、間；金額；預算類型（例如硬件、軟件、辦公消耗等） ；用途說明。第第 3 步步. 對比分析、控制成本對比分析、控制成本項目經理隨時對比分析“成本預算表”和“實際開支表”，盡量避免超支。項目經理應當向1. 制定項目預算2. 記錄實際開支調整3.對比分析、控制成本 23上級領導解釋為什么超支。2.3.4 項目評審（決策評審和技術評審）項目評審分兩類：決策評審和技術評審，兩者的流程相同，但是目的不同。決策評審的目的是利用集體（所有評審人員）的智慧，做出正確的決策，決定項目工作繼續進行還是終止。技術評審的目的是及時發現工作成果中問題，提出改進建議，使工作成果變得更好。第第1 1步步. . 發起評審通知發

41、起評審通知發起人根據項目計劃（或者項目經理的指示）發出評審通知，明確評審會議的內容、參加人員、時間、地點等信息，評審通知的格式參見表2-3。一般地，默認的評審負責人是項目經理，如果項目經理不能做出決定，可以重新指定其他人擔任評審負責人。第第2 2步步. . 評審負責人召開評審會議評審負責人召開評審會議（1）發起人講解待評審的成果。（2）評審人員現場提問和討論，發起人解答疑問。（3）所有評審人員給出評審意見。（4）評審負責人匯總評審意見，給出評審結論。（5）記錄員輸入會議記錄。評審報告的格式參見表 2-4。2.4 變更控制項目開發過程中發生變更是司空見慣的事情。這里“變更”是指改變已經發布的工作

42、成果（如文檔、代碼或者計劃等） ，修改草稿不叫變更。變更控制的目的不是為了“預防變更” ，而是為了“防止變更失去控制產生壞的后果” 。變更控制的最大困難在于變更控制的最大困難在于“如何拒絕客戶或上如何拒絕客戶或上級領導提出的不合理變更要求級領導提出的不合理變更要求” 。 變更控制的流程如圖 2-5 所示，主要活動有：變更申請、評審和審批和執行變更。變更申請拒絕變更拒絕變更同意變更執行變更申請人評審人和審批人執行人評審和審批 24圖 2-5 變更控制流程提示：一般情況下，先申請，審批通過后，再執行變更。在實際工作中，由于時間緊迫，對于低風險的變更，允許先執行變更，后補寫變更申請。變更控制報告的參

43、考格式如表 2-10 所示。第第 1 步步. 變更申請變更申請項目開發過程中，所有人員（包括銷售人員、項目成員和上級領導）提出的變更申請，必須說明“變更內容和原因” 。由項目經理受理，指定多個評審人和一位“審批負責人” ，一般情況下，項目經理擔任審批負責人。如果對項目的技術方案、進度、質量、成本產生重大影響的變更，項目經理做不了決定，那么可以指定上級領導擔任審批負責人。第第 2 步步. 評審和審批評審和審批每個評審人都可以發表意見（但是不做決定） 。由“審批負責人”做決定：“同意變更”或者“拒絕變更” ，并給出指示。第第 3 步步. 執行變更執行變更審批負責人同意變更后，由項目經理安排人員執行

44、具體的變更工作，調整相應的任務進度計劃，通知給受變更影響的相關人員。1. 變更申請項目名稱變更原因和內容說明變更原因和變更內容，估計此變更對項目造成的影響。變更申請人評審人可以多人審批負責人可以逐級審批2. 變更審批評審人評審意見 同意變更 拒絕變更審批負責人指示： 253. 執行變更執行人說明表 2-10 變更控制報告2.5 溝通管理溝通管理包括項目內部溝通、跨部門溝通、與上級領導溝通、與客戶溝通等，要及時記錄重要的溝通信息，避免遺忘，模板見表 2-11。溝通記錄標題溝通日期溝通對象客戶或公司內部人員填寫人溝通方式面談 / 電話 / email / 網絡交流溝通結果達成共識 / 存在異議 /

45、 擱置詳細信息表 2-11 溝通記錄項目開發過程中存在各種各樣的風險，需要項目經理（和銷售人員）及時地和客戶溝通。“客戶溝通”主要目的是“消除摩擦、增進關系” 、 “處理不合理的變更”和“發掘新的商機” 。一、消除摩擦、增進關系一、消除摩擦、增進關系項目經理（和銷售人員）應經常和客戶溝通，盡可能地消除客戶對需求、進度、質量的不滿。如果雙方工作人員之間發生摩擦，項目經理（和銷售人員）應及時消除摩擦。為了不斷改善開發方和客戶方的人際關系，項目經理（和銷售人員）在時間、經費允許的前提下，主動邀請客戶方人員參加友誼活動，例如運動、聚餐、娛樂等等。二、二、 處理不合理的變更處理不合理的變更項目經理（和銷

46、售人員）要設法“拒絕客戶提出的不合理變更” 。所謂“不合理的變更”是指：客戶提出的變更不是由于開發方的過錯引起的，此變更造成開發方承擔了額外的成本，但是客戶不愿意支付相應的費用。客戶會想當然地以為變更是他的權利，通常情況下開發方是不敢得罪客戶的，但是無原則地退讓將使開發團隊陷入困境。這里建議了三種應對方法： 26方法方法 1：依據合同處理變更：依據合同處理變更如果客戶是很有信譽、嚴格按照合同辦事的企業，那么雙方應當依據合同中的條款處理變更糾紛。這就要求雙方在簽訂合同的時候，要在合同中寫明“變更處理協議” 。例如：當需求規格說明書被雙方確認之后，如果再發生需求變更的話，那么按照“變更申請審批執行

47、”的變更管理流程執行。如果客戶（或者開發方）提出的變更對項目進度、成本的影響超過 10%，那么雙方要重新協商成本、資源和進度，否則開發方（或者客戶）可以拒絕變更請求。方法方法 2：設法拖延到下個版本：設法拖延到下個版本如果雙方簽訂的合同中沒有“變更協議” ，或者有變更協議但是客戶找出很多理由來搪塞，只要雙方還沒有完全鬧僵的話，項目經理（和銷售人員）需要一些社交技巧來減緩矛盾：首先承認客戶提出的需求變更請求是合理的（讓客戶面子上過得去） ；再闡述己方的難處和變更對客戶造成的不利影響，例如質量問題等等，讓客戶明白隨意變更對他自己也沒有好處；最后建議在開發新版本的時候實現客戶提出的變更。這種方式比直

48、接拒絕有效得多，既不得罪客戶，又為自己爭取了余地。拖延到下個版本實現客戶的變更，有可能讓客戶支付升級費用。即使升級是免費的，也不會延誤當前項目的進度和客戶驗收，讓開發方及時拿到合同經費。方法方法 3：讓客戶欠下人情：讓客戶欠下人情如果客戶提出重大的變更請求，既不愿意支付變更的費用，也不愿意延緩到下個版本中實現，而且客戶也知道自己理虧，但是現實環境迫使客戶必須那樣做。開發方沒有辦法拒絕，因為倘若拒絕的話，就得不到合同余款，怎么辦？在這種情況下，開發方只能接受讓自己吃虧的變更，但是還有辦法減少損失，這個辦法就是“讓客戶欠下人情” 。銷售人員（和項目經理）應當真誠地和客戶溝通，讓客戶明白“開發方為了

49、客戶的利益付出了額外的代價” 。只要客戶是個講道理的正常人，那么客戶會感激開發方的幫助，覺得自己欠下了“人情” ，可以約定在后面恰當的機會回報開發方。例如，在客戶驗收的時候，適當地放松要求，及時地向開發方支付合同費用等，這些回報對開發方而言都是隱形的收益。三、發掘新的商機三、發掘新的商機項目經理（和銷售人員）和客戶交往的過程中，不僅要關注已經簽訂合同的項目進展情況，還要不斷發掘新的商機，例如：發掘客戶更深層次的需求，吸引客戶繼續采購（例如不斷升級） 。 27將合同項目的成果轉化成為通用的產品或構件，賣給其它客戶。請老客戶推薦其新客戶。2.6 問題跟蹤問題跟蹤的范圍包括：開發過程中的各種問題、風

50、險和建議，以及結項后遺留的問題。開發過程中的各種問題、風險和建議，以及結項后遺留的問題。問題跟蹤的一般步驟如圖 2-6 所示，問題跟蹤表見表 2-12。第 1 步。報告者創建問題，指定接收者，此時狀態為“新的” 。第 2 步。接受者處理問題，狀態為“正在處理” 。第 3 步。如果已經解決了問題，則把狀態置為“解決待關閉” 。第 4 步。報告者審核這個問題，如果確定該問題已經解決，則把狀態設置為“關閉” 。如果發現問題沒有解決，則可以“重新打開”問題，回到第 2 步。圖 2-6 問題跟蹤示意圖問題跟蹤表問題編號問題類型重要性緊急程度問題描述報告者報告時間接受者期望完成日期問題處理方案當前狀態實際

51、完全日期報告問題報告者接受者報告者處理問題解決待關閉審核關閉接受者重新打開 28審核關閉意見表 2-12 問題跟蹤表 29第 3 章 項目研發過程3.1 需求開發與管理需求開發與管理是指通過“調研、分析、定義、評審、跟蹤”等活動，使開發方和委托方（客戶或本公司領導）對需求有共同、清晰的理解，并依據雙方確認的需求開展后續開發工作（如設計、編程、測試等） 。項目經理根據本項目的人力資源來確定需求分析員（可以多人） 。需求分析員負責開展調研、分析、定義、評審、跟蹤等活動。3.1.1 需求調研需求分析員起草需求問題表，將調查重點鎖定在該問題表內，否則調研工作將變得漫無邊際。需求分析員確定需求調研的方式

52、，例如：與用戶交談，向用戶提問題。參觀用戶的工作流程，觀察用戶的操作。向用戶群體發調查問卷。與同行、專家交談，聽取他們的意見。分析已經存在的同類軟件產品，提取需求。從行業標準、規則中提取需求。從 Internet 上搜查相關資料。需求分析員在調研過程中隨時填寫“客戶需求記錄” ，參考格式如表 3-1 所示。項目名稱需求分析員調研方式被調研者時間、地點需求標題客戶需求記錄表 3-1 客戶需求記錄需求分析員整理所有客戶需求記錄，歸納與總結共性的需求，為撰寫詳細的需求規格說明書作準備。調研過程中獲取的需求信息可以作為需求規格說明書的附件。 303.1.2 需求分析需求分析是對各種來源的需求信息進行分

53、析，消除錯誤，刻畫細節等。常見的需求分析方法有“問答分析法”和“建模分析法”兩類。問答分析最重要的問題是：“是什么”和“為什么” 。每個需求都應當用陳述句說明“是什么” ，如果“是什么”的內涵不夠清晰，則應補充說明“不是什么” 。如果“是什么”和“不是什么”并不是“理所當然”的，那么應當解釋“為什么” ，以便加深讀者的理解。追究“是什么”和“為什么”的目的是獲得正確、清楚的需求。對于某些類型的信息，用圖形表示要比文本表示更加有效。所以將圖形與文本結合起來描述需求是很自然的方法。需求建模就是指用圖形符號來表示、刻畫需求。現代建模工具如 Rose 有非常豐富的圖形符號和文字標注，能很好地表達模型的

54、細節。要注意的是：在建模時使用花樣過多的圖形符號或文字意味著模型表示的復雜化，將使開發人員更難掌握，而且使圖形文檔更加雜亂。世上不存在一個包羅萬象的圖用以完整地描述需求。需求建模不可能取代文字描述。在在需求文檔中，文字描述是第一重要的，建模主要是起分析、解釋作用。需求文檔中，文字描述是第一重要的，建模主要是起分析、解釋作用。建議將模型存放在需求文檔的附錄中，便于正文引用。3.1.3 需求定義需求分析員根據需求調查和需求分析的結果，進一步定義準確無誤的需求，撰寫需求規格說明書 ，模板見表 3-2。提示：若有其它類型的需求規格說明書，請另定義模板。軟件需求規格說明書1. 背景介紹2. 軟件系統的用

55、戶介紹2.1 用戶類型和角色職責2.2 用戶組織結構圖（可選）2.3 用戶的信息化情況3. 用戶業務流程介紹4. 軟件系統的約束5. 軟件系統當前版本的范圍6. 軟件系統的功能清單7. 模塊需求說明（可以寫在單獨的模塊文檔中）8. 其它需求9. 簽字確認 31表 3-2 軟件需求規格說明書3.1.4 需求評審需求分析員邀請項目成員（包括項目經理）和客戶代表共同評審需求規格說明書 ，大家盡最大努力使需求規格說明書能夠正確無誤地反映用戶的真實意愿。需求評審的流程見“項目評審流程” 。一般地，需求分析員為申請人，項目經理為評審負責人，項目成員和客戶代表可以擔任評審員。所有評審人員認真檢查需求文檔，力

56、求使需求文檔達到正確、清楚、無二義性、一致、必要、完備、可實現、可驗證。3.1.5 需求跟蹤第第 1 1 步。步。需求分析員創建需求的目錄結構，便于人們閱讀。第第 2 2 步。步。需求分析員輸入每條需求的詳細內容，可以多次細化修改，每次修改后應通知相關項目成員。第第 3 3 步。步。需求分析員跟蹤每條需求的進展狀況，填寫需求跟蹤記錄（當前狀態和情況說明），需求跟蹤表的格式見表 3-3。需求跟蹤表需求目錄/名稱優先級狀態責任人關聯信息（文檔，任務，缺陷等）表 3-3 需求跟蹤表3.2 系統設計3.2.1 軟件系統設計軟件系統設計的主要內容有體系結構設計、用戶界面設計、數據庫設計等，在需求與代碼之

57、間建立橋梁，指導工作人員開發能夠滿足用戶需求的軟件系統。項目經理根據本項目的人力資源來確定軟件設計師（可以多人） 。軟件設計師撰寫軟件設計師撰寫軟件系統設計說明書軟件系統設計說明書 ，并構造可運行的軟件系統框架，所有的模塊都，并構造可運行的軟件系統框架，所有的模塊都 32是在該系統框架上開發和運行。是在該系統框架上開發和運行。 軟件系統設計說明書的模板參見表 3-4。軟件系統設計說明書1. 軟件系統概述2. 設計約束3. 開發、測試與運行環境4. 軟件體系結構圖5. 功能模塊設計概述5.1 模塊匯總5.2 模塊之間的關系6. 數據庫設計概述6.1 數據庫環境說明6.2 數據庫命名規則6.3 安

58、全性設計說明6.4 表匯總和表設計7. 用戶界面設計概述8. 綜合考慮（可選）8.1 穩定性和可擴展性8.2 性能分析8.3 復用和移植8.4 防錯與出錯處理8.5 其它表 3-4 軟件系統設計說明書3.2.2 設計評審設計評審的目的是在同行專家的幫助下，盡早地發現本系統中存在的設計缺陷，及時消除設計缺陷。當軟件設計師撰寫完成軟件系統設計說明書，并構建可運行的系統框架之后，邀請項目成員（包括項目經理）和本公司技術專家開展設計評審。設計評審的流程見“項目評審流程” 。3.3 模塊開發與集成項目經理分配合適的模塊開發任務給開發人員，開發人員對自己承擔模塊的質量和開發開發人員對自己承擔模塊的質量和開

59、發進度負責進度負責。 33開發人員閱讀需求規格說明書和系統設計說明書 ，分析并細化自己承擔的模塊需求，并且進行模塊細節設計，撰寫模板需求和設計文檔 ，見表 3-5。所有開發人員按照既定的規范（如編程規范）來實現自己承擔的模塊，并在系統框架中和其它模塊集成一起。開發人員完成模塊開發后，必須先進行自我測試，必須走通模塊的所有功能，消除自己已經發現的缺陷，然后交付給下個環節。模塊文檔（需求和設計）項目名稱模塊名稱撰寫人完成日期1. 模塊功能和流程介紹說明模塊用途、主要功能，最好繪制功能結構圖和工作流程。2. 模塊的設計思路3. 模塊的主要數據結構4. 本模塊的主要調用（1）本模塊主要調用了其它模塊的

60、哪些接口；（2）本模塊為其它模塊提供了什么接口。5. 其它說明表 3-5 模塊需求和設計文檔3.4 測試與缺陷跟蹤測試與缺陷跟蹤的流程見下圖3-1。測試準備消除缺陷執行測試測試人員缺陷跟蹤審核關閉開發人員提交測試開發負責人測試負責人 34圖 3-1 測試與缺陷跟蹤的流程3.4.1 提交測試開發負責人把待測試物品（如軟件包）交付給測試組之前，必須完成以下工作（否則測試人員可以拒絕接受）：（1）在配置庫中打標記（Label） ，這個 Label 就是待測試物品（如軟件包）的版本號（建議包含年月日時分的信息） 。（2）說明該版本要測試什么，注意事項等。（3）開發人員必須測試自己開發的功能，通過后才可