·集成化軟件研發(fā)流程IDP7.0集成化軟件研發(fā)流程IDP7.0文件狀態(tài)：[]草稿[√]正式發(fā)布[]正在修改文件標識：集成化軟件研發(fā)流程IDP當前版本：7.0作者：林銳審核：完成日期：2009年11月上海漫索計算機科技有限公司目錄TOC\o"1-3"\h\zA.集成化軟件研發(fā)流程圖 5B.過程域和主要成果清單 6C.研發(fā)組織結構模型 7D.角色職責表 8第1章營銷客服過程 101.1產(chǎn)品管理 101.1.1產(chǎn)品策劃 101.1.2調(diào)研分析 111.1.3產(chǎn)品立項與開發(fā) 121.1.4產(chǎn)品銷售與服務 131.2銷售管理 131.2.1營銷策劃 131.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.2PMO受理 202.1.3立項評審 212.1.4項目啟動 222.2結項管理 232.2.1結項申請 232.2.2PMO受理 242.2.3結項評審 252.2.4遺留問題跟蹤 252.2.5項目工作總結 262.3項目規(guī)劃與監(jiān)控 262.3.1項目人員角色 262.3.2任務進度管理 272.3.3項目成本管理 282.3.4項目評審（決策評審和技術評審） 282.4變更控制 292.5溝通管理 312.6問題跟蹤 33第3章項目研發(fā)過程 343.1需求開發(fā)與管理 343.1.1需求調(diào)研 343.1.2需求分析 353.1.3需求定義 353.1.4需求評審 363.1.5需求跟蹤 363.2系統(tǒng)設計 363.2.1軟件系統(tǒng)設計 363.2.2設計評審 373.3模塊開發(fā)與集成 373.4測試與缺陷跟蹤 383.4.1提交測試 393.4.2測試準備 393.4.3執(zhí)行測試 403.4.4缺陷跟蹤 403.4.5消除缺陷 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執(zhí)行維護 45第4章支持過程 464.1軟件配置管理 464.1.1軟件配置管理的概念 464.1.2軟件代碼管理的一般規(guī)則 464.2文檔管理 474.2.1文檔管理的特征 474.2.2項目文檔管理的一般規(guī)則 484.3質量保證 489.4日志和周報 494.5績效評估 494.5.1定義績效體系 494.5.2填寫績效表格 504.6知識庫管理 51A.集成化軟件研發(fā)流程圖B.過程域和主要成果清單過程域主要工作成果營銷

客服過程產(chǎn)品管理（產(chǎn)品策劃，調(diào)研分析，立項）產(chǎn)品建議書，產(chǎn)品調(diào)研報告，立項申請書銷售管理（營銷策劃，銷售跟蹤，合同管理）營銷方案，銷售跟蹤表，合同管理表客戶服務（受理，處理，關閉，反饋）客服跟蹤表客戶信息管理客戶信息表項目

管理

過程立項管理（立項申請，PMO受理，立項評審，項目啟動）立項申請書，立項評審報告，項目總體計劃結項管理（結項申請，PMO受理，結項評審，遺留問題跟蹤，項目工作總結）結項申請書，結項評審報告，項目工作總結項目規(guī)劃與監(jiān)控（人員角色，任務進度，項目成本，項目評審）人員角色表，任務進度表，成本表，評審報告變更控制變更控制報告溝通管理溝通記錄問題跟蹤問題跟蹤表項目

研發(fā)

過程需求開發(fā)與管理需求規(guī)格說明書，需求跟蹤表系統(tǒng)設計系統(tǒng)設計說明書模塊開發(fā)與集成模塊文檔（需求和設計），軟件代碼測試與缺陷跟蹤測試用例，測試報告，缺陷跟蹤表交付與驗收安裝手冊，使用手冊，驗收報告維護維護記錄支持

過程軟件配置管理，文檔管理，知識管理軟件配置庫，文檔庫，知識庫質量保證質量保證檢查表，問題跟蹤表日志和周報工作日志，周報績效分析績效報表C.研發(fā)組織結構模型營銷和客服角色營銷和客服角色項目成員角色支持角色管理角色研發(fā)總監(jiān)銷售人員產(chǎn)品經(jīng)理需求分析員系統(tǒng)設計師PMO項目經(jīng)理決策委員會開發(fā)工程師測試人員質量保證員各部門經(jīng)理配置管理員客服人員D.角色職責表角色該角色在研發(fā)流程中的主要職責研發(fā)總監(jiān)（1）參與立項評審，為項目分配合適的人力資源。（2）及時了解所有項目的人力資源、進度、質量情況，協(xié)商處理問題。（3）在項目結束時，對項目進行綜合評估。決策委員會決策委員會一般由部門經(jīng)理以上職位的人員組成，主要職責是參與決策評審（如立項評審）。部門經(jīng)理人力資源分配和協(xié)調(diào)，提升人員的能力，考核人員績效。PMO受理立項申請，受理結項申請，項目過程檢查。產(chǎn)品經(jīng)理（1）通過調(diào)研分析，進行產(chǎn)品策劃，撰寫產(chǎn)品建議書，申請立項。（2）跟蹤產(chǎn)品開發(fā)過程，及時試用產(chǎn)品，糾正偏差，給出優(yōu)化建議。（3）幫助銷售人員宣傳、銷售該產(chǎn)品，及時獲取客戶的反饋，改進產(chǎn)品。銷售員

（1）負責本公司產(chǎn)品的銷售，鑒定合同，跟蹤合同執(zhí)行過程。（2）撰寫合同項目的立項申請書?？头藛T集中受理客戶問題需求，指定合適的處理人，審核關閉問題，獲取客戶反饋。項目經(jīng)理項目經(jīng)理是立項之后的項目主要責任人，主要職責是帶領團隊在預定的時間和成本之內(nèi)，開發(fā)并交付質量合格的項目（產(chǎn)品）。項目經(jīng)理對本項目的進度、質量負主要責任。（1）負責本項目的日常管理（如任務進度管理，項目評審，變更控制，溝通管理，問題跟蹤等），以及可能存在的跨項目、跨部門協(xié)調(diào)。（2）如果本項目沒有專門的需求分析員，那么項目經(jīng)理承擔需求分析工作。如果本項目缺乏足夠的開發(fā)工程師，那么項目經(jīng)理應當承擔某些模塊開發(fā)。（3）在項目結束時，總結知識財富和經(jīng)驗教訓，完善文檔。對項目成員的業(yè)績進行評估。需求分析員（1）負責本項目需求調(diào)研、分析、定義，撰寫詳細的需求文檔。

（2）將需求準確地傳達給相關人員（如開發(fā)、測試、客戶等），隨著項目進展，及時完善需求文檔。系統(tǒng)設計師（1）根據(jù)需求開展系統(tǒng)設計，包括構架設計、數(shù)據(jù)庫設計、用戶界面設計等。（2）撰寫設計文檔，并將設計成果準確地傳達給其他項目成員。開發(fā)人員（1）按照項目經(jīng)理分配的任務執(zhí)行開發(fā)工作，并清楚地交付給測試人員（準備測試）。如果測試人員報告缺陷，應及時消除缺陷。對自己工作成果的質量負最大責任。（2）對自己的源代碼進行配置管理，撰寫自己承擔的模塊文檔。測試人員（1）了解項目需求，和項目經(jīng)理商議測試計劃，設計測試用例。（2）根據(jù)計劃執(zhí)行測試，找出盡可能多的缺陷。使用缺陷跟蹤工具，及時將測試信息反饋給相關責任人。質量保證員（1）跟蹤每個項目的開發(fā)過程，重點檢查需求文檔、設計文檔、變更記錄、用戶文檔是否符合規(guī)范。

（2）參加需求評審和設計評審。

（3）如果發(fā)現(xiàn)項目問題，先和責任人溝通，如果難以解決，則由上級領導協(xié)調(diào)。配置管理員（1）為所有項目創(chuàng)建配置庫，為用戶分配合適的權限，負責信息安全和備份。（2）指導開發(fā)人員使用配置管理軟件。第1章營銷客服過程1.1產(chǎn)品管理♀銷售和客服人員企業(yè)

戰(zhàn)略♀項目經(jīng)理產(chǎn)品立項與開發(fā)調(diào)研分析產(chǎn)品策劃產(chǎn)品銷售與服務♀產(chǎn)品經(jīng)理♀銷售和客服人員企業(yè)

戰(zhàn)略♀項目經(jīng)理產(chǎn)品立項與開發(fā)調(diào)研分析產(chǎn)品策劃產(chǎn)品銷售與服務♀產(chǎn)品經(jīng)理產(chǎn)品管理流程如圖6-1所示，主要活動有：產(chǎn)品策劃，調(diào)研分析，產(chǎn)品立項與開發(fā)，產(chǎn)品銷售與服務。該流程的主要工作成果和責任人見表1-1。圖1-1產(chǎn)品管理流程主要活動主要工作成果主要責任人產(chǎn)品策劃產(chǎn)品建議書產(chǎn)品經(jīng)理調(diào)研分析產(chǎn)品調(diào)研分析報告產(chǎn)品經(jīng)理產(chǎn)品立項與開發(fā)立項申請書，最終產(chǎn)品產(chǎn)品經(jīng)理，項目經(jīng)理產(chǎn)品銷售與服務產(chǎn)品宣傳材料，銷售合同，客服單產(chǎn)品經(jīng)理，銷售人員，客服人員表1-1產(chǎn)品管理流程的成果清單和責任人1.1.1產(chǎn)品策劃產(chǎn)品經(jīng)理負責產(chǎn)品策劃活動。產(chǎn)品經(jīng)理應主動尋求研發(fā)部門的幫助，由產(chǎn)品經(jīng)理牽頭，撰寫《產(chǎn)品建議書》，模板見表1-2。提示：本產(chǎn)品立項之后，項目團隊將進一步細化產(chǎn)品需求、設計方案和開發(fā)計劃等。產(chǎn)品建議書1.產(chǎn)品概述 用簡練的語言說明本產(chǎn)品“是什么”，“什么用途”。2.產(chǎn)品開發(fā)背景從內(nèi)因、外因兩方面闡述產(chǎn)品開發(fā)背景，重點說明“為什么”要開發(fā)本產(chǎn)品。

（1）內(nèi)因方面著重考慮：開發(fā)方的短期、長期發(fā)展戰(zhàn)略；開發(fā)方的當前實力。

（2）外因方面著重考慮：市場需求及發(fā)展趨勢；技術狀況及發(fā)展趨勢。3.消費群體特征（1）闡述本產(chǎn)品消費群體的特征；

（2）說明消費者對產(chǎn)品的功能性需求和非功能性需求；

（3）說明本產(chǎn)品如何滿足消費者的需求，以及給消費者帶來什么好處。4.產(chǎn)品主要功能和特色（1）產(chǎn)品的主要功能列表；

（2）說明本產(chǎn)品的特色。5.產(chǎn)品設計方案和關鍵技術 （1）闡述設計方案及原理，如果有多種方案，需比較優(yōu)缺點。（2）闡述本產(chǎn)品的一些關鍵技術，評價技術實現(xiàn)的難易程度。（3）確定哪些產(chǎn)品部件應當采購、外包開發(fā)或者自主研發(fā)，說明理由，分析相應的風險。6.產(chǎn)品開發(fā)和上市計劃 如果產(chǎn)品有多個版本，估算各版本的開發(fā)時間和上市時間，以及人員和資金。表1-2產(chǎn)品建議書1.1.2調(diào)研分析產(chǎn)品經(jīng)理在做產(chǎn)品策劃時，應同步進行調(diào)研分析。產(chǎn)品經(jīng)理撰寫《產(chǎn)品調(diào)研分析報告》，模板見表1-3，目的是為公司決策提供充分的、有價值的信息。提示：如果不做調(diào)研分析的話，那么產(chǎn)品建議和立項管理都建立在空想之上。調(diào)研者應當客觀地對待被調(diào)查的事物，不可有意往“好處”或者“壞處”設想。所獲取的數(shù)據(jù)、圖表等信息要真實并且有據(jù)可查，不可憑空捏造。調(diào)研分析的主要內(nèi)容有：消費者（購買者，使用者，影響者）調(diào)研；競爭對手和同類產(chǎn)品調(diào)研；政策調(diào)研；技術可行性分析；知識產(chǎn)權分析；成本—收益分析；產(chǎn)品調(diào)研分析報告1.消費者調(diào)研（1）購買者的特征和需求。（2）使用者的特征和需求。（3）影響者的特征和需求。2.競爭對手與同類產(chǎn)品調(diào)研（1）各競爭對手在研發(fā)、銷售、資金、品牌等方面的實力。（2）同類產(chǎn)品的功能、質量、價格，以及主要優(yōu)點和主要缺點。3.政策調(diào)研（1）有無政策“支持”或者“限制”。（2）有無地方政府（或其它機構）的“扶持”或者“干擾”。（3）如何利用（應對）政策。4.技術和時間可行性分析（1）本產(chǎn)品“做得了嗎？”、“做得好嗎？”。（2）按照正常的運作方式，能及時開發(fā)完成本產(chǎn)品嗎？投入市場的時間合適嗎？5.知識產(chǎn)權分析（1）分析是否已經(jīng)存在某些專利將妨礙本產(chǎn)品的開發(fā)與推廣；（2）分析本產(chǎn)品能否得到知識產(chǎn)權保護，如何獲得？6.成本—效益分析（1）估算總成本。（2）估算總收益。表1-3產(chǎn)品調(diào)研分析報告1.1.3產(chǎn)品立項與開發(fā)產(chǎn)品經(jīng)理負責立項申請，撰寫《立項申請書》，提交給PMO，進入立項管理流程。如果本產(chǎn)品被批準立項，則：項目經(jīng)理將管理本產(chǎn)品的開發(fā)過程，對產(chǎn)品的質量和進度負責。產(chǎn)品經(jīng)理要跟蹤開發(fā)過程，及時了解產(chǎn)品的開發(fā)進度和工作成果質量。如果產(chǎn)品經(jīng)理發(fā)現(xiàn)開發(fā)工作偏離了產(chǎn)品需求和預定的計劃，應當及時和項目經(jīng)理溝通，糾正偏差。建議開發(fā)團隊采用增量模式來開發(fā)產(chǎn)品，每次發(fā)布新的版本，既要請測試人員進行測試，又要請產(chǎn)品經(jīng)理來體驗（試用）。產(chǎn)品經(jīng)理應當站在客戶的角度來體驗（試用）當前產(chǎn)品：如果發(fā)現(xiàn)產(chǎn)品中的缺陷，則向開發(fā)人員報告缺陷，開發(fā)人員及時消除缺陷。若產(chǎn)品經(jīng)理向項目經(jīng)理提出改進建議，雙方應先就需求和改進措施達成共識，然后開發(fā)人員執(zhí)行相應的改進措施。1.1.4產(chǎn)品銷售與服務 產(chǎn)品開發(fā)完成之后，產(chǎn)品經(jīng)理負責：撰寫產(chǎn)品介紹文件（如ppt文件）。制作本產(chǎn)品的宣傳網(wǎng)頁，設法在更多的網(wǎng)站發(fā)布產(chǎn)品信息。可能需要設計和制作宣傳頁（印刷品）。產(chǎn)品經(jīng)理對本公司銷售人員進行產(chǎn)品培訓，使銷售人員充分了解本產(chǎn)品的特性。上述工作完成之后，進入銷售管理流程和客戶服務流程。產(chǎn)品經(jīng)理跟蹤銷售和客服過程，收集并分析客戶意見，及時改進產(chǎn)品策劃。1.2銷售管理銷售管理流程如圖1-2所示，主要活動有：營銷策劃，銷售跟蹤，合同管理。該流程的主要工作成果和責任人見表1-4。-銷售跟蹤-

接觸客戶

客戶分析

售前服務與跟蹤

簽訂合同-合同管理--銷售跟蹤-

接觸客戶

客戶分析

售前服務與跟蹤

簽訂合同-合同管理-

實施計劃與跟蹤

收款計劃與跟蹤

付款計劃與跟蹤♀銷售人員♀銷售人員♀銷售經(jīng)理產(chǎn)品或項目營銷策劃圖1-2銷售管理流程主要活動主要工作成果主要責任人營銷策劃營銷方案銷售經(jīng)理銷售跟蹤銷售跟蹤表，銷售合同銷售人員合同管理合同實施、收款、付款跟蹤表銷售人員表1-4銷售管理流程的成果清單和責任人1.2.1營銷策劃銷售部門商議營銷方案，銷售經(jīng)理分配任務給執(zhí)行人（可以多人）。每個執(zhí)行人填寫執(zhí)行情況，模板見表1-5。營銷方案方案名稱制定人起止日期執(zhí)行人A,B銷售計劃內(nèi)容執(zhí)行人執(zhí)行情況狀態(tài)日期A未開始，進行中，完成B表1-5營銷方案1.2.2銷售跟蹤銷售人員負責：（1）銷售本公司的產(chǎn)品；（2）從客戶那里承接項目。第一步，接觸潛在客戶。銷售人員通過各種途徑接觸潛在客戶，了解客戶（公司）信息和客戶的需求。第二步，客戶分析。銷售人員應當撰寫《客戶分析報告》，為公司提供充分的客戶信息（同時也記錄了自己的工作業(yè)績），格式參見表1-6。由于售前服務會消耗公司的資源（人力、金錢、時間），如果客戶最終不簽訂采購合同，那么無效的售前服務將給公司增加成本。為了避免浪費公司的資源，節(jié)約成本，銷售部門需商議是否為潛在客戶提供進一步的售前服務，以及服務的程度。客戶分析報告客戶分析1.客戶介紹2.客戶需求3.采購可能性4.成本－效益分析5.風險分析部門意見說明是否為潛在客戶提供進一步的售前服務，以及服務的程度。表1-6客戶分析報告第三步，售前服務與跟蹤。銷售人員根據(jù)潛在客戶需求，提供產(chǎn)品演示、講解、答疑等服務。如果承接客戶的招標項目，則按客戶規(guī)定的程序進行“投標、答辯、商務談判”。如果需要，銷售人員應主動向研發(fā)部門申請技術支持。銷售人員填寫銷售跟蹤表，模板見表1-7。銷售跟蹤表客戶銷售單內(nèi)容對客戶的承諾跟蹤人銷售單狀態(tài)跟蹤說明跟蹤日期表1-7銷售跟蹤表第四步，簽訂合同。如果客戶確定采購，可能有2種方式：（1）商務（2）客戶承諾采購，但是目前不能簽訂合同。遇此情況，銷售部門需請示公司領導，決定做還是不做。提示：如果公司銷售產(chǎn)品，則需制定《產(chǎn)品銷售合同》模板。如果公司承接客戶項目，則需制定《項目銷售合同》模板。1.2.3合同管理銷售人員根據(jù)合同信息，制定實施計劃、付款計劃、收款計劃，并跟蹤這些計劃的執(zhí)行情況，模板見表1-8。合同管理客戶名稱客戶方負責人合同名稱我方負責人合同簽訂日期計劃完成日期合同摘要計劃實施日期計劃說明執(zhí)行人執(zhí)行狀態(tài)/情況說明計劃收款日期金額及用途說明執(zhí)行人執(zhí)行狀態(tài)/情況說明計劃付款日期金額及用途說明執(zhí)行人執(zhí)行狀態(tài)/情況說明表1-8合同管理表（實施、收款、付款）1.3客戶服務客戶服務流程如圖1-3所示，主要活動有：受理，處理，審核關閉，客戶反饋。該流程的主要工作成果和責任人見表1-9?！庵付ㄌ幚砣恕饪头藛T♀客服人員生成項目缺陷，項目任務，項目需求等客戶報告

問題需求♀客戶客戶反饋審核關閉♀指定處理人♀客服人員♀客服人員生成項目缺陷，項目任務，項目需求等客戶報告

問題需求♀客戶客戶反饋審核關閉處理受理圖1-1客戶服務流程主要活動主要工作成果主要責任人受理客服跟蹤表客服人員處理指定處理人審核關閉客服人員客戶反饋客戶表1-9客戶服務流程的成果清單和責任人1.3.1受理客戶通過各種途徑報告問題（包括問題、需求、建議等）。客服人員記錄客戶問題，并指定處理人，模板見表1-10。1.3.2處理如果處理人能夠直接解決客戶問題，則填寫處理說明，把狀態(tài)置為“解決待關閉”。如果問題比較復雜，可以生成“項目任務、項目缺陷、項目需求”等。若“任務、缺陷、需求”都已經(jīng)完成，再把客戶問題的狀態(tài)置為“解決待關閉”。1.3.3審核關閉 當客戶問題的狀態(tài)為“解決待關閉”時，客服人員驗證這個問題，如果的確已經(jīng)解決，則把狀態(tài)置為“關閉”，并填寫關閉說明。1.3.4客戶反饋客服人員告知客戶其問題已經(jīng)解決，并獲取客戶的反饋意見?？头櫛順祟}編號客戶/聯(lián)系人客服類型內(nèi)容受理人受理時間受理說明處理人處理時間處理說明關閉人關閉時間關閉說明客戶反饋表1-10客服跟蹤表1.4客戶信息管理營銷人員和客服人員均可填寫客戶公司信息和客戶聯(lián)系人信息（模板見表1-11）?？蛻粜畔⒈砜蛻艄竞喎Q客戶狀態(tài)客戶公司全稱客戶類型電話所屬區(qū)域傳真所屬行業(yè)郵政編碼所屬城市地址客戶公司簡介客戶分析聯(lián)系人姓名部門/職務聯(lián)系電話Email/即時通信表1-11客戶信息第2章項目管理過程2.1立項管理立項管理的流程如圖7-1所示，主要活動有：立項申請、PMO受理、立項評審和項目啟動。該流程的主要工作成果和責任人見表2-1。♀項目團隊項目啟動立項

評審PMO

受理♀銷售人員♀♀項目團隊項目啟動立項

評審PMO

受理♀銷售人員♀產(chǎn)品經(jīng)理自主產(chǎn)品立項申請合同項目立項申請圖2-1立項管理流程關鍵活動主要工作成果主要責任人自主產(chǎn)品立項申請立項申請書，產(chǎn)品建議書，調(diào)研分析報告產(chǎn)品經(jīng)理合同項目立項申請立項申請書，相關合同文件合同項目的銷售人員PMO受理立項評審通知PMO立項評審立項評審結論立項評審委員會項目啟動項目總體計劃項目經(jīng)理表2-1立項管理流程的主要工作成果和責任人2.1.1立項申請對于自主產(chǎn)品，產(chǎn)品經(jīng)理撰寫《立項申請書》，并將相關附件（主要是產(chǎn)品建議書，產(chǎn)品調(diào)研分析報告）一起提交給PMO。對于合同項目，銷售人員撰寫《立項申請書》，并將相關附件（主要是合同文件）一起提交給PMO。《立項申請書》的格式見表2-2。立項申請書項目名稱項目類型合同項目/自主產(chǎn)品申請人申請日期1.項目介紹2.本項目對公司的價值3.項目進度要求4.項目所需人力資源5.項目成本估算6.立項可行性分析6.1技術可行性分析6.2成本-效益分析6.3競爭分析6.4風險分析6.5SWOT分析表2-2立項申請書的格式2.1.2PMO受理PMO受理人審閱《立項申請書》和相關附件，如果發(fā)現(xiàn)文件內(nèi)容不合流程要求或者質量不合格，則退還給申請人重新改進，直到文件合格為止。之后，PMO受理人將文件轉交給研發(fā)總監(jiān)。提示：這樣做的目的是提高立項評審的效率。研發(fā)總監(jiān)根據(jù)項目的特征，選定“立項評審委員會”，確定評審時間。PMO受理人發(fā)起立項評審通知，格式見表2-3。提示：如果項目涉及面很廣，難以一次性在立項評審會議上決定，那么研發(fā)總監(jiān)可以先召開“預評審”會議，之后再進行正式的立項評審。立項評審通知項目名稱申請人評審文件評審時間地點評審人員部門和職務評審負責人評委其他參加人員評審內(nèi)容表2-3立項評審通知2.1.3立項評審PMO通知相關人員在既定的時間參加立項評審會議，《立項評審報告》格式見2-4。評審負責人主持評審會議，把控會議進程。立項申請人陳述《立項申請書》和相關文件的主要內(nèi)容。評審委員提出疑問，立項申請人解答。雙方應當對有爭議的內(nèi)容提出處理意見、達成共識。每個評委發(fā)表（填寫）自己的評審意見。評審負責人匯總所有評審委員的評審意見，給出評審結論：“同意立項”或者“不同意立項”。提示：評審期間應當商議“項目人力資源計劃”，避免立項之后人員不能到位的問題。記錄員（PMO受理人）填寫會議記錄。評審結束后，公司級的項目由公司領導（研發(fā)總監(jiān)）給出“終審結論和意見”，部門級項目由部門經(jīng)理給出“終審結論和意見”。XXX立項評審報告評委姓名評審意見說明同意或者不同意的理由評審負責人評審結論、匯總意見和人力資源計劃評審結論：[√]同意立項[]不同意匯總意見和人力資源計劃：記錄員會議記錄領導終審結論和意見評審結論：[√]同意立項[]不同意意見：表2-4立項評審報告2.1.4項目啟動第1步確定項目團隊部門經(jīng)理根據(jù)項目特征和立項評審報告，任命合適的項目經(jīng)理，并確定該項目的主要成員。項目經(jīng)理對立項之后的項目進度和質量負責。項目成員向項目經(jīng)理匯報工作。項目經(jīng)理向部門經(jīng)理匯報工作。第2步確定項目總體計劃項目經(jīng)理和項目成員共同商議，制定初步的《項目總體計劃》，格式參見表2-5。部門經(jīng)理審批該《項目總體計劃》，如果有修改意見，請項目經(jīng)理及時修正。提示：在項目開發(fā)過程中，項目經(jīng)理可以不斷細化項目計劃和修改項目計劃，詳見“項目規(guī)劃與監(jiān)控”過程域。項目總體計劃項目名稱計劃開始日期項目經(jīng)理計劃結束日期1.項目介紹說明項目目標、關鍵因素及優(yōu)先級2.項目成員表姓名角色說明（主要職責和工作時間）3.任務進度表名稱（階段/任務/評審點）執(zhí)行人計劃起止日期4.部門經(jīng)理審批審批意見…表2-5項目總體計劃第3步初始化管理平臺（1）PMO受理人或部門經(jīng)理在管理平臺中創(chuàng)建該項目。（2）項目經(jīng)理登錄管理平臺，進入該項目，執(zhí)行初始化操作：初始化項目成員表（含角色職責）。把立項會議的相關文件上傳到本項目的文檔庫中。根據(jù)《項目總體計劃》初始化任務進度表。第4步初始化軟件配置管理工具（1）部門經(jīng)理（或指定配置管理員）創(chuàng)建該項目的配置庫，授予項目經(jīng)理控制本項目的權限。（2）項目經(jīng)理再分配權限給其他項目成員。2.2結項管理結項管理的流程如圖7-2所示，主要活動有：結項申請、PMO受理、結項評審、遺留問題跟蹤和項目工作總結。該流程的主要工作成果和責任人見表2-6。結項申請結項評審項目工作總結：個人工作總結→分析提煉→知識入庫遺留問題跟蹤♀所有項目成員結項申請結項評審項目工作總結：個人工作總結→分析提煉→知識入庫遺留問題跟蹤♀所有項目成員♀項目經(jīng)理PMO受理圖2-2結項管理流程關鍵活動主要工作成果主要責任人結項申請結項申請書項目經(jīng)理PMO受理結項評估報告PMO，結項評審委員會結項評審遺留問題跟蹤問題跟蹤表項目經(jīng)理，PMO項目工作總結個人工作總結，知識庫所有項目成員表2-6結項管理流程的主要工作成果和責任人2.2.1結項申請正常情況下，當項目開發(fā)工作結束時，項目經(jīng)理撰寫《結項申請書》，遞交給PMO。《結項申請書》的格式見表2-6。對于異常結束的項目，部門經(jīng)理應當明確指示項目經(jīng)理，確定何時結束項目。部門經(jīng)理應當向員工們解釋為什么要異常終止項目。異常中止項目的結項流程與正常結項流程相同。2.2.2PMO受理PMO受理人審閱《結項申請書》和相關附件，如果發(fā)現(xiàn)文件內(nèi)容不合流程要求或者質量不合格，則退還給申請人重新改進，直到文件合格為止。之后，PMO受理人將文件轉交給研發(fā)總監(jiān)。提示：這樣做的目的是提高立項評審的效率。研發(fā)總監(jiān)根據(jù)項目的特征，選定“結項評審委員會”，確定評審時間。PMO受理人發(fā)起結項評審通知，格式和立項評審通知相同（見表2-3）。結項申請書項目名稱項目經(jīng)理1.項目完成情況計劃情況實際情況主要功能項目起止日期人員和工作量項目成本應遞交的成果2.資產(chǎn)清單（資金和設備，軟件等）說明、處理建議3.專利和版權4.項目價值體現(xiàn)闡述：項目質量，市場價值，成本效益，對機構的貢獻5.人員業(yè)績工作業(yè)績描述評價人人員A人員B項目經(jīng)理簽字表2-6結項申請書2.2.3結項評審PMO通知相關人員在既定的時間參加結項評審會議。評審負責人主持評審會議，把控會議進程。立項申請人陳述《結項申請書》的主要內(nèi)容。評審委員提出疑問，立項申請人解答。雙方應當對有爭議的內(nèi)容提出處理意見、達成共識。每個評委發(fā)表（填寫）自己的評審意見。評審負責人匯總所有評審委員的評審意見，給出評審結論：“同意結項”或者“不同意結項”。記錄員（PMO受理人）填寫會議記錄?！督Y項評審報告》的格式見表2-7。XXX結項評審報告評委姓名評審意見評審負責人評審結論和匯總意見評審結論：[√]同意結項[]不同意匯總意見：（1）項目任務完成情況。（2）項目資產(chǎn)處理意見。（3）發(fā)掘可以重復利用的知識財富，給出應用建議。（4）項目的價值：市場價值、成本效益、技術積累等記錄員會議記錄表2-7結項評審報告提示：項目結項后，該項目的人力資源和設備資源將被釋放，應用于新的項目。項目成員有義務維護自己參與的項目。2.2.4遺留問題跟蹤項目結項后，尚有一些遺留問題，項目經(jīng)理填寫“問題表”，PMO人員跟蹤該問題表，確保所有問題得到妥善處理。詳見“問題跟蹤”過程域。2.2.5項目工作總結第1步。所有項目成員都要撰寫《個人工作總結》，格式見表2-8，在公司范圍內(nèi)共享經(jīng)驗教訓。第2步。項目經(jīng)理召集所有項目成員，討論每個人的工作總結，提煉出知識財富。第3步。把知識財富按照一定的格式保存在集成化管理平臺中。項目名稱—個人工作總結撰寫人日期工作總結1.本人在項目中的主要任務

2.遇到哪些問題，如何解決

3.經(jīng)驗教訓和建議表2-8個人工作總結2.3項目規(guī)劃與監(jiān)控項目規(guī)劃（ProjectPlanning）是指對本項目的人力資源、任務進度、成本等做出合適的安排，制定出一些計劃（包括宏觀的和細節(jié)的），使大家按照計劃行事，最終順利地達到預定的目標。項目監(jiān)控是將項目實際情況與項目計劃進行對比，如果發(fā)現(xiàn)某些因素（如人力資源、任務進度、成本等）的偏差比較大，那么及時分析原因，給出糾正措施。項目監(jiān)控至少有兩個好處：（1）避免原本合理的計劃在實施過程時落空；（2）避免“執(zhí)迷不悟”地按照原本不合理的計劃行事。項目規(guī)劃與監(jiān)控的重點是：“人員角色”、“任務進度”、“項目成本”、“項目評審”。2.3.1項目人員角色項目經(jīng)理向部門爭取“完成本項目充分必要的人員”，項目人員到位后，項目經(jīng)理確定每個人員在本項目的角色、工作內(nèi)容和時間，格式見表2-9。姓名角色工作描述（簡要說明工作內(nèi)容和時間）表2-9項目人員角色表2.3.2任務進度管理項目經(jīng)理根據(jù)“本項目需求和人力資源”分解任務，和項目成員協(xié)商后，把任務交給最合適的人員去執(zhí)行。簡而言之，就是要“知人善用”?！爸恕笔侵割I導者應當非常了解他的團隊成員，包括知識技能和性格愛好等等。“善用”是指讓團隊各成員揚長避短，使團隊戰(zhàn)斗力達到最強。項目經(jīng)理還要有意識地鍛煉、提升成員們?nèi)珠_發(fā)的能力，要保證至少有一人可以替換別人的工作。否則萬一某人缺席（如離職、休假等），將導致工作被中斷。任務進度管理的流程如圖2-3所示，主要活動和步驟如下：3.糾正偏差3.糾正偏差調(diào)整調(diào)整2.填寫執(zhí)行信息1.制定任務計劃2.填寫執(zhí)行信息1.制定任務計劃圖2-3任務進度管理的流程第1步.制定任務進度計劃項目經(jīng)理和項目成員們共同協(xié)商任務，大家達成共識后制定任務進度計劃，每個任務的主要數(shù)據(jù)如下：任務名稱，任務描述，預計工作成果開始日期，計劃完成日期任務執(zhí)行人（可以多個），計劃工作量第2步.填寫執(zhí)行信息每個任務的執(zhí)行人（可以多個）填寫執(zhí)行信息，主要數(shù)據(jù)如下：執(zhí)行人，填寫日期任務狀態(tài)（進行中，已完成）當前進度（百分比）實際工作量，執(zhí)行說明第3步.糾正偏差如果任務的執(zhí)行情況和計劃之間的偏差比較大（例如工作量、完成日期的誤差超過20％），項目經(jīng)理應當和執(zhí)行人交流，分析原因并給出解決措施：（1）若原計劃太樂觀了，那么適當修改原計劃；（2）若執(zhí)行人工作不得力，那么要求執(zhí)行人加班追趕進度。2.3.3項目成本管理1.制定項目預算1.制定項目預算2.記錄實際開支調(diào)整3.對比分析、控制成本項目經(jīng)理應當懂得“非財務人員”的項目成本管理。項目成本管理的流程如圖2-4所示，主要活動和步驟如下：圖2-4項目成本管理的流程圖第1步.制定項目預算項目經(jīng)理制定項目預算表，每條記錄的主要數(shù)據(jù)有：金額；預算類型（例如硬件、軟件、辦公消耗等）；用途說明。第2步.記錄實際開支項目經(jīng)理和項目成員記錄實際開支，每條記錄的主要數(shù)據(jù)有：經(jīng)辦人，開支時間；金額；預算類型（例如硬件、軟件、辦公消耗等）；用途說明。第3步.對比分析、控制成本項目經(jīng)理隨時對比分析“成本預算表”和“實際開支表”，盡量避免超支。項目經(jīng)理應當向上級領導解釋為什么超支。2.3.4項目評審（決策評審和技術評審）項目評審分兩類：決策評審和技術評審，兩者的流程相同，但是目的不同。決策評審的目的是利用集體（所有評審人員）的智慧，做出正確的決策，決定項目工作繼續(xù)進行還是終止。技術評審的目的是及時發(fā)現(xiàn)工作成果中問題，提出改進建議，使工作成果變得更好。第1步.發(fā)起評審通知發(fā)起人根據(jù)項目計劃（或者項目經(jīng)理的指示）發(fā)出評審通知，明確評審會議的內(nèi)容、參加人員、時間、地點等信息，《評審通知》的格式參見表2-3。一般地，默認的評審負責人是項目經(jīng)理，如果項目經(jīng)理不能做出決定，可以重新指定其他人擔任評審負責人。第2步.評審負責人召開評審會議（1）發(fā)起人講解待評審的成果。（2）評審人員現(xiàn)場提問和討論，發(fā)起人解答疑問。（3）所有評審人員給出評審意見。（4）評審負責人匯總評審意見，給出評審結論。（5）記錄員輸入會議記錄。《評審報告》的格式參見表2-4。2.4變更控制項目開發(fā)過程中發(fā)生變更是司空見慣的事情。這里“變更”是指改變已經(jīng)發(fā)布的工作成果（如文檔、代碼或者計劃等），修改草稿不叫變更。變更控制的目的不是為了“預防變更”，而是為了“防止變更失去控制產(chǎn)生壞的后果”。變更控制的最大困難在于“如何拒絕客戶或上級領導提出的不合理變更要求”。變更控制的流程如圖2-5所示，主要活動有：變更申請、評審和審批和執(zhí)行變更?！庠u審人和審批人執(zhí)行變更變更申請♀執(zhí)行人♀申請人拒絕變更同意變更評審和審批♀評審人和審批人執(zhí)行變更變更申請♀執(zhí)行人♀申請人拒絕變更同意變更評審和審批圖2-5變更控制流程提示：一般情況下，先申請，審批通過后，再執(zhí)行變更。在實際工作中，由于時間緊迫，對于低風險的變更，允許先執(zhí)行變更，后補寫變更申請。《變更控制報告》的參考格式如表2-10所示。第1步.變更申請項目開發(fā)過程中，所有人員（包括銷售人員、項目成員和上級領導）提出的變更申請，必須說明“變更內(nèi)容和原因”。由項目經(jīng)理受理，指定多個評審人和一位“審批負責人”，一般情況下，項目經(jīng)理擔任審批負責人。如果對項目的技術方案、進度、質量、成本產(chǎn)生重大影響的變更，項目經(jīng)理做不了決定，那么可以指定上級領導擔任審批負責人。第2步.評審和審批每個評審人都可以發(fā)表意見（但是不做決定）。由“審批負責人”做決定：“同意變更”或者“拒絕變更”，并給出指示。第3步.執(zhí)行變更審批負責人同意變更后，由項目經(jīng)理安排人員執(zhí)行具體的變更工作，調(diào)整相應的任務進度計劃，通知給受變更影響的相關人員。1.變更申請項目名稱變更原因和內(nèi)容說明變更原因和變更內(nèi)容，估計此變更對項目造成的影響。變更申請人評審人可以多人審批負責人可以逐級審批2.變更審批評審人評審意見審批負責人[√]同意變更[]拒絕變更指示：3.執(zhí)行變更執(zhí)行人說明 表2-10變更控制報告2.5溝通管理溝通管理包括項目內(nèi)部溝通、跨部門溝通、與上級領導溝通、與客戶溝通等，要及時記錄重要的溝通信息，避免遺忘，模板見表2-11。溝通記錄標題溝通日期溝通對象客戶或公司內(nèi)部人員填寫人溝通方式面談/電話/email/網(wǎng)絡交流溝通結果達成共識/存在異議/擱置詳細信息 表2-11溝通記錄項目開發(fā)過程中存在各種各樣的風險，需要項目經(jīng)理（和銷售人員）及時地和客戶溝通。“客戶溝通”主要目的是“消除摩擦、增進關系”、“處理不合理的變更”和“發(fā)掘新的商機”。一、消除摩擦、增進關系項目經(jīng)理（和銷售人員）應經(jīng)常和客戶溝通，盡可能地消除客戶對需求、進度、質量的不滿。如果雙方工作人員之間發(fā)生摩擦，項目經(jīng)理（和銷售人員）應及時消除摩擦。為了不斷改善開發(fā)方和客戶方的人際關系，項目經(jīng)理（和銷售人員）在時間、經(jīng)費允許的前提下，主動邀請客戶方人員參加友誼活動，例如運動、聚餐、娛樂等等。二、處理不合理的變更項目經(jīng)理（和銷售人員）要設法“拒絕客戶提出的不合理變更”。所謂“不合理的變更”是指：客戶提出的變更不是由于開發(fā)方的過錯引起的，此變更造成開發(fā)方承擔了額外的成本，但是客戶不愿意支付相應的費用?？蛻魰氘斎坏匾詾樽兏撬臋嗬?，通常情況下開發(fā)方是不敢得罪客戶的，但是無原則地退讓將使開發(fā)團隊陷入困境。這里建議了三種應對方法：方法1：依據(jù)合同處理變更如果客戶是很有信譽、嚴格按照合同辦事的企業(yè)，那么雙方應當依據(jù)合同中的條款處理變更糾紛。這就要求雙方在簽訂合同的時候，要在合同中寫明“變更處理協(xié)議”。例如：當《需求規(guī)格說明書》被雙方確認之后，如果再發(fā)生需求變更的話，那么按照“變更申請－審批－執(zhí)行”的變更管理流程執(zhí)行。如果客戶（或者開發(fā)方）提出的變更對項目進度、成本的影響超過10%，那么雙方要重新協(xié)商成本、資源和進度，否則開發(fā)方（或者客戶）可以拒絕變更請求。方法2：設法拖延到下個版本如果雙方簽訂的合同中沒有“變更協(xié)議”，或者有變更協(xié)議但是客戶找出很多理由來搪塞，只要雙方還沒有完全鬧僵的話，項目經(jīng)理（和銷售人員）需要一些社交技巧來減緩矛盾：首先承認客戶提出的需求變更請求是合理的（讓客戶面子上過得去）；再闡述己方的難處和變更對客戶造成的不利影響，例如質量問題等等，讓客戶明白隨意變更對他自己也沒有好處；最后建議在開發(fā)新版本的時候實現(xiàn)客戶提出的變更。這種方式比直接拒絕有效得多，既不得罪客戶，又為自己爭取了余地。拖延到下個版本實現(xiàn)客戶的變更，有可能讓客戶支付升級費用。即使升級是免費的，也不會延誤當前項目的進度和客戶驗收，讓開發(fā)方及時拿到合同經(jīng)費。方法3：讓客戶欠下人情如果客戶提出重大的變更請求，既不愿意支付變更的費用，也不愿意延緩到下個版本中實現(xiàn)，而且客戶也知道自己理虧，但是現(xiàn)實環(huán)境迫使客戶必須那樣做。開發(fā)方?jīng)]有辦法拒絕，因為倘若拒絕的話，就得不到合同余款，怎么辦？在這種情況下，開發(fā)方只能接受讓自己吃虧的變更，但是還有辦法減少損失，這個辦法就是“讓客戶欠下人情”。銷售人員（和項目經(jīng)理）應當真誠地和客戶溝通，讓客戶明白“開發(fā)方為了客戶的利益付出了額外的代價”。只要客戶是個講道理的正常人，那么客戶會感激開發(fā)方的幫助，覺得自己欠下了“人情”，可以約定在后面恰當?shù)臋C會回報開發(fā)方。例如，在客戶驗收的時候，適當?shù)胤潘梢?，及時地向開發(fā)方支付合同費用等，這些回報對開發(fā)方而言都是隱形的收益。三、發(fā)掘新的商機 項目經(jīng)理（和銷售人員）和客戶交往的過程中，不僅要關注已經(jīng)簽訂合同的項目進展情況，還要不斷發(fā)掘新的商機，例如：發(fā)掘客戶更深層次的需求，吸引客戶繼續(xù)采購（例如不斷升級）。將合同項目的成果轉化成為通用的產(chǎn)品或構件，賣給其它客戶。請老客戶推薦其新客戶。2.6問題跟蹤問題跟蹤的范圍包括：開發(fā)過程中的各種問題、風險和建議，以及結項后遺留的問題。問題跟蹤的一般步驟如圖2-6所示，問題跟蹤表見表2-12。第1步。報告者創(chuàng)建問題，指定接收者，此時狀態(tài)為“新的”。第2步。接受者處理問題，狀態(tài)為“正在處理”。第3步。如果已經(jīng)解決了問題，則把狀態(tài)置為“解決待關閉”。重新打開♀報告者♀接受者審核關閉報告問題解決待關閉處理問題♀接受者♀報告者重新打開♀報告者♀接受者審核關閉報告問題解決待關閉處理問題♀接受者♀報告者第4步。報告者審核這個問題，如果確定該問題已經(jīng)解決，則把狀態(tài)設置為“關閉”。如果發(fā)現(xiàn)問題沒有解決，則可以“重新打開”問題，回到第2步。圖2-6問題跟蹤示意圖問題跟蹤表問題編號問題類型重要性緊急程度問題描述報告者報告時間接受者期望完成日期問題處理方案當前狀態(tài)實際完全日期審核關閉意見表2-12問題跟蹤表第3章項目研發(fā)過程3.1需求開發(fā)與管理 需求開發(fā)與管理是指通過“調(diào)研、分析、定義、評審、跟蹤”等活動，使開發(fā)方和委托方（客戶或本公司領導）對需求有共同、清晰的理解，并依據(jù)雙方確認的需求開展后續(xù)開發(fā)工作（如設計、編程、測試等）。項目經(jīng)理根據(jù)本項目的人力資源來確定需求分析員（可以多人）。需求分析員負責開展調(diào)研、分析、定義、評審、跟蹤等活動。3.1.1需求調(diào)研需求分析員起草需求問題表，將調(diào)查重點鎖定在該問題表內(nèi)，否則調(diào)研工作將變得漫無邊際。需求分析員確定需求調(diào)研的方式，例如：與用戶交談，向用戶提問題。參觀用戶的工作流程，觀察用戶的操作。向用戶群體發(fā)調(diào)查問卷。與同行、專家交談，聽取他們的意見。分析已經(jīng)存在的同類軟件產(chǎn)品，提取需求。從行業(yè)標準、規(guī)則中提取需求。從Internet上搜查相關資料。需求分析員在調(diào)研過程中隨時填寫“客戶需求記錄”，參考格式如表3-1所示。項目名稱需求分析員調(diào)研方式被調(diào)研者時間、地點需求標題客戶需求記錄表3-1客戶需求記錄需求分析員整理所有客戶需求記錄，歸納與總結共性的需求，為撰寫詳細的《需求規(guī)格說明書》作準備。調(diào)研過程中獲取的需求信息可以作為《需求規(guī)格說明書》的附件。3.1.2需求分析需求分析是對各種來源的需求信息進行分析，消除錯誤，刻畫細節(jié)等。常見的需求分析方法有“問答分析法”和“建模分析法”兩類。問答分析最重要的問題是：“是什么”和“為什么”。每個需求都應當用陳述句說明“是什么”，如果“是什么”的內(nèi)涵不夠清晰，則應補充說明“不是什么”。如果“是什么”和“不是什么”并不是“理所當然”的，那么應當解釋“為什么”，以便加深讀者的理解。追究“是什么”和“為什么”的目的是獲得正確、清楚的需求。對于某些類型的信息，用圖形表示要比文本表示更加有效。所以將圖形與文本結合起來描述需求是很自然的方法。需求建模就是指用圖形符號來表示、刻畫需求。現(xiàn)代建模工具如Rose有非常豐富的圖形符號和文字標注，能很好地表達模型的細節(jié)。要注意的是：在建模時使用花樣過多的圖形符號或文字意味著模型表示的復雜化，將使開發(fā)人員更難掌握，而且使圖形文檔更加雜亂。世上不存在一個包羅萬象的圖用以完整地描述需求。需求建模不可能取代文字描述。在需求文檔中，文字描述是第一重要的，建模主要是起分析、解釋作用。建議將模型存放在需求文檔的附錄中，便于正文引用。3.1.3需求定義需求分析員根據(jù)需求調(diào)查和需求分析的結果，進一步定義準確無誤的需求，撰寫《需求規(guī)格說明書》，模板見表3-2。提示：若有其它類型的需求規(guī)格說明書，請另定義模板。軟件需求規(guī)格說明書1.背景介紹 2.軟件系統(tǒng)的用戶介紹 2.1用戶類型和角色職責 2.2用戶組織結構圖（可選）2.3用戶的信息化情況 3.用戶業(yè)務流程介紹 4.軟件系統(tǒng)的約束 5.軟件系統(tǒng)當前版本的范圍 6.軟件系統(tǒng)的功能清單 7.模塊需求說明（可以寫在單獨的模塊文檔中） 8.其它需求 9.簽字確認 表3-2軟件需求規(guī)格說明書3.1.4需求評審需求分析員邀請項目成員（包括項目經(jīng)理）和客戶代表共同評審《需求規(guī)格說明書》，大家盡最大努力使《需求規(guī)格說明書》能夠正確無誤地反映用戶的真實意愿。需求評審的流程見“項目評審流程”。一般地，需求分析員為申請人，項目經(jīng)理為評審負責人，項目成員和客戶代表可以擔任評審員。所有評審人員認真檢查需求文檔，力求使需求文檔達到正確、清楚、無二義性、一致、必要、完備、可實現(xiàn)、可驗證。3.1.5需求跟蹤第1步。需求分析員創(chuàng)建需求的目錄結構，便于人們閱讀。第2步。需求分析員輸入每條需求的詳細內(nèi)容，可以多次細化修改，每次修改后應通知相關項目成員。第3步。需求分析員跟蹤每條需求的進展狀況，填寫需求跟蹤記錄（當前狀態(tài)和情況說明），需求跟蹤表的格式見表3-3。需求跟蹤表需求目錄/名稱優(yōu)先級狀態(tài)責任人關聯(lián)信息（文檔，任務，缺陷等）表3-3需求跟蹤表3.2系統(tǒng)設計3.2.1軟件系統(tǒng)設計軟件系統(tǒng)設計的主要內(nèi)容有體系結構設計、用戶界面設計、數(shù)據(jù)庫設計等，在需求與代碼之間建立橋梁，指導工作人員開發(fā)能夠滿足用戶需求的軟件系統(tǒng)。項目經(jīng)理根據(jù)本項目的人力資源來確定軟件設計師（可以多人）。軟件設計師撰寫《軟件系統(tǒng)設計說明書》，并構造可運行的軟件系統(tǒng)框架，所有的模塊都是在該系統(tǒng)框架上開發(fā)和運行。《軟件系統(tǒng)設計說明書》的模板參見表3-4。軟件系統(tǒng)設計說明書1.軟件系統(tǒng)概述2.設計約束3.開發(fā)、測試與運行環(huán)境4.軟件體系結構圖5.功能模塊設計概述5.1模塊匯總5.2模塊之間的關系6.數(shù)據(jù)庫設計概述6.1數(shù)據(jù)庫環(huán)境說明6.2數(shù)據(jù)庫命名規(guī)則6.3安全性設計說明6.4表匯總和表設計7.用戶界面設計概述8.綜合考慮（可選）8.1穩(wěn)定性和可擴展性8.2性能分析8.3復用和移植8.4防錯與出錯處理8.5其它表3-4軟件系統(tǒng)設計說明書3.2.2設計評審設計評審的目的是在同行專家的幫助下，盡早地發(fā)現(xiàn)本系統(tǒng)中存在的設計缺陷，及時消除設計缺陷。當軟件設計師撰寫完成《軟件系統(tǒng)設計說明書》，并構建可運行的系統(tǒng)框架之后，邀請項目成員（包括項目經(jīng)理）和本公司技術專家開展設計評審。設計評審的流程見“項目評審流程”。3.3模塊開發(fā)與集成項目經(jīng)理分配合適的模塊開發(fā)任務給開發(fā)人員，開發(fā)人員對自己承擔模塊的質量和開發(fā)進度負責。開發(fā)人員閱讀《需求規(guī)格說明書》和《系統(tǒng)設計說明書》，分析并細化自己承擔的模塊需求，并且進行模塊細節(jié)設計，撰寫《模板需求和設計文檔》，見表3-5。所有開發(fā)人員按照既定的規(guī)范（如編程規(guī)范）來實現(xiàn)自己承擔的模塊，并在系統(tǒng)框架中和其它模塊集成一起。開發(fā)人員完成模塊開發(fā)后，必須先進行自我測試，必須走通模塊的所有功能，消除自己已經(jīng)發(fā)現(xiàn)的缺陷，然后交付給下個環(huán)節(jié)。模塊文檔（需求和設計）項目名稱模塊名稱撰寫人完成日期1.模塊功能和流程介紹說明模塊用途、主要功能，最好繪制功能結構圖和工作流程。2.模塊的設計思路3.模塊的主要數(shù)據(jù)結構4.本模塊的主要調(diào)用（1）本模塊主要調(diào)用了其它模塊的哪些接口；（2）本模塊為其它模塊提供了什么接口。5.其它說明表3-5模塊需求和設計文檔3.4測試與缺陷跟蹤審核關閉♀測試人員♀測試負責人♀開發(fā)負責人提交測試測試準備消除缺陷缺陷

跟蹤執(zhí)行測試♀審核關閉♀測試人員♀測試負責人♀開發(fā)負責人提交測試測試準備消除缺陷缺陷

跟蹤執(zhí)行測試♀開發(fā)人員測試與缺陷跟蹤的流程見下圖3-1。圖3-1測試與缺陷跟蹤的流程3.4.1提交測試開發(fā)負責人把待測試物品（如軟件包）交付給測試組之前，必須完成以下工作（否則測試人員可以拒絕接受）：（1）在配置庫中打標記（Label），這個Label就是待測試物品（如軟件包）的版本號（建議包含年月日時分的信息）。（2）說明該版本要測試什么，注意事項等。（3）開發(fā)人員必須測試自己開發(fā)的功能，通過后才可以交付給測試人員。3.4.2測試準備測試準備主要有三件事情：分配測試任務，設計測試用例，構建測試環(huán)境。一、分配測試任務測試負責人和測試人員商議測試計劃，安排合適的測試人員執(zhí)行測試任務。二、設計測試用例測試用例是用于檢驗目標系統(tǒng)是否符合需求的一種“示例”，基本要素有：前提條件、輸入數(shù)據(jù)或動作、期望的響應?！稖y試用例》就是描述各種測試用例的文檔，相當于一本“測試操作手冊”。關于測試用例的一些常識如下：（1）設計測試用例的目的是找出需求、設計、代碼中的毛病，因此最好盡可能早地設計測試用例。（2）不同的測試用例其用途應當不一樣，不要累贅。（3）顯而易見的測試用例不必完整地用文字描述，因為此時文字描述的價值不大、反而消耗時間。測試人員根據(jù)模塊的需求和設計說明書，撰寫《測試用例》，格式見表3-6。最好由開發(fā)人員審閱《測試用例》，提出改進建議，雙方達成共識。測試用例用例名稱項目名稱對應模塊撰寫人前提條件輸入/動作期望的輸出示例：典型值…示例：邊界值…示例：異常值…審閱人/意見表3-6測試用例三、構建測試環(huán)境測試人員（和開發(fā)工程師）構建測試環(huán)境，注意測試環(huán)境要盡可能接近用戶的實際運行環(huán)境。3.4.3執(zhí)行測試測試人員執(zhí)行測試，填寫測試報告，見表3-7。測試報告目錄/用例名稱測試人員測試記錄/結論測試時間表3-7測試報告3.4.4缺陷跟蹤 缺陷跟蹤如圖3-2所示，缺陷跟蹤表見表3-8。一般步驟如下：第1步。測試人員（報告者）如果發(fā)現(xiàn)缺陷，則記錄缺陷的詳細信息，報告給開發(fā)人員（接受者）。此時缺陷的狀態(tài)是“新的”。第2步。開發(fā)人員處理缺陷，此時缺陷的狀態(tài)是“正在處理”。提示：如果開發(fā)人員把缺陷狀態(tài)設置為“不做處理或延后處理”，則項目經(jīng)理召集相關人員評審那些“不做處理或延后處理”的缺陷，給出“處理”還是“不處理”決定。第3步。如果開發(fā)人員消除了缺陷，則把缺陷的狀態(tài)設置為“解決待關閉”。 第4步。測試人員重新測試該缺陷對應的功能，如果確定缺陷已經(jīng)消除，則把狀態(tài)設置為“關閉”。如果發(fā)現(xiàn)該缺陷沒有解決，則可以“重新打開”缺陷，回到第2步?！饨邮苷摺鈭蟾嬲咧匦麓蜷_♀報告者♀接受者審核關閉報告缺陷解決待關閉處理缺陷♀接受者♀報告者重新打開♀報告者♀接受者審核關閉報告缺陷解決待關閉處理缺陷圖3-2缺陷跟蹤的流程缺陷跟蹤表缺陷編號缺陷類型嚴重性緊急程度缺陷描述報告者報告時間接受者期望完成日期缺陷解決方案當前狀態(tài)實際完全日期審核關閉意見表3-8缺陷跟蹤表3.4.5消除缺陷消除缺陷的第一步是找出缺陷的根源，如同醫(yī)生治病，必須先找出病因才能“對癥下藥”。開發(fā)人員必須從結果出發(fā)，逆向思考。一旦找到了根源，開發(fā)人員通常知道如何消除缺陷。 查找缺陷的基本方法是“粗分細找”。對于隱藏得很深的Bug，應該運用歸納、推理、“二分”等方法先“快速、粗略”地確定錯誤根源的范圍，然后再用調(diào)試工具仔細地跟蹤此范圍的源代碼。開發(fā)人員在改錯時，要注意以下事項：（1）找到錯誤的代碼時，不要急于修改，先思考一下：修改此代碼會不會引發(fā)其它問題？如果沒有問題，可以放心修改。如果有問題，可能要改動程序結構，而不止一行代碼。（2）有些時候，軟件中可能潛伏同一類型的許多錯誤（例如由不良的編程習慣引起的）。好不容易逮住一個，應當乘勝追擊，全部殲滅。（3）在改錯之后一定要馬上重新測試，以免引入新的錯誤。改了一個程序錯誤固然是喜事，但要防止樂極生悲。更加嚴格的要求是：不論原先程序是否絕對正確，只要對此程序作過改動（哪怕是微不足道的），都要重新測試。（4）上述事情做完后，應當好好反思：我為什么會犯這樣的錯誤？怎么能夠防止下次不犯相似的錯誤？最好能寫下心得體會，與他人共享經(jīng)驗教訓。3.5交付與驗收如果是合同項目，那么由客戶方負責人指定“試用人員和驗收人員”。如果是自主研發(fā)產(chǎn)品，那么由產(chǎn)品經(jīng)理（或公司領導）指定“試用人員和驗收人員”。交付與驗收的流程見圖3-3。驗收試用♀項目成員♀項目成員用戶培訓軟件部署撰寫文檔♀驗收人員♀驗收試用♀項目成員♀項目成員用戶培訓軟件部署撰寫文檔♀驗收人員♀試用人員圖3-3交付與驗收的流程3.5.1撰寫文檔當項目開發(fā)完成并通過測試之后，項目經(jīng)理指定項目成員及時撰寫《安裝手冊》、《使用手冊》、《軟件部署說明書》等必需文檔。3.5.2軟件部署項目經(jīng)理審閱《軟件部署說明書》，模板見表3-9，如果發(fā)現(xiàn)問題，則及時指正。項目經(jīng)理確認無誤后，再指定項目成員為客戶（或者本公司）部署軟件系統(tǒng)：安裝（或更新）軟件系統(tǒng)，遷移數(shù)據(jù)；初始化業(yè)務數(shù)據(jù)，確保軟件能夠正常運行；注意：部署的軟件系統(tǒng)必須是從配置庫中提取已經(jīng)測試通過的軟件包。最好通過Internet進行遠程部署，節(jié)省交通費用和時間。軟件部署說明書軟件名稱撰寫人1.部署環(huán)境說明（硬件和軟件系統(tǒng)）2.需要初始化的數(shù)據(jù)3.需要遷移（升級）的數(shù)據(jù)4.注意事項項目經(jīng)理審閱意見部署過程中的

主要事項記錄表3-9軟件部署說明書3.5.3用戶培訓項目經(jīng)理指定項目成員（即講師）負責給用戶培訓。講師和用戶商定培訓計劃（確定時間、地點、人員批次等）。講師按照計劃給客戶培訓，并填寫《客戶培訓記錄》，模板見表3-10，作為培訓服務的依據(jù)?？蛻襞嘤栍涗浿v師課程名稱培訓時間地點客戶名稱學員培訓內(nèi)容介紹相關資料客戶簽字確認表3-10客戶培訓記錄3.5.4試用和驗收項目成員把軟件部署到用戶指定的機器上，用戶試用軟件。在試用期間內(nèi)，如果用戶發(fā)現(xiàn)軟件中存在嚴重的Bug（如死機、數(shù)據(jù)丟失、無法運行等），則開發(fā)方應當在24小時之內(nèi)給出解決問題的措施。如果超過試用期，開發(fā)方仍然沒有完全消除用戶報告的Bug，那么試用期順延，直到開發(fā)方完全消除用戶報告的Bug為止。如果用戶在試用期間內(nèi)沒有報告嚴重Bug，那么試用期結束時，視為順利通過試用。如果試用期間，用戶提出改進需求、以及報告了一些不嚴重的缺陷，開發(fā)方作為正常維護工作來處理，不延誤用戶驗收產(chǎn)品。用戶在試用軟件的過程中，將發(fā)現(xiàn)的Bug以及對軟件的建議及時告知開發(fā)方。項目經(jīng)理和開發(fā)人員及時處理用戶反饋來的Bug和建議。對于用戶發(fā)現(xiàn)的Bug，開發(fā)方應當立即糾正。對于一些難以馬上實現(xiàn)的有益建議，由項目經(jīng)理（或上級領導）決定如何處理。開發(fā)方應當及時把處理結果回復給用戶，否則用戶可能因得不到開發(fā)方的重視而降低試用的積極性。3.6軟件維護軟件維護可以劃分為兩大類：糾錯性維護。由于前期的測試不可能揭露軟件系統(tǒng)中所有潛伏的Bug，用戶在使用軟件時仍將會遇到Bug，診斷和改正這些Bug的過程稱為糾錯性維護。完善性維護。在軟件的正常使用過程中，用戶還會不斷提出新的需求。為了滿足用戶新的需求而增加軟件功能的活動稱為完善性維護。如果需求變更很大，那么完善性維護將轉變?yōu)檐浖掳姹镜拈_發(fā)（即新的項目）。軟件維護的一般流程見圖3-4，主要活動有“接受維護請求”、“分析維護請求”和“執(zhí)行軟件維護”。維護負責人維護人員客服人員接受維護請求維護負責人維護人員客服人員接受維護請求執(zhí)行軟件維護分析維護請求圖3-4軟件維護的一般流程3.6.1接受維護請求公司應當建立通暢的軟件維護通信渠道，包括網(wǎng)站、電話、Email等手段。客戶通過各種渠道向公司的客服人員提出軟件維護請求。本公司客服人員記錄這些維護請求，然后指定維護負責人：如果公司有專門的維護小組，那么客服人員把維護請求轉發(fā)給維護小組負責人。如果公司沒有專門的維護小組，那么客服人員把維護請求轉發(fā)給該軟件的項目經(jīng)理，如果項目已經(jīng)結束，則轉交給開發(fā)部門的領導。3.6.2分析維護請求維護負責人接受到維護請求后，進行分析：（1）對于“糾錯性維護”，首先確認Bug的真實情況，然后指定維護人員，協(xié)商安排修改Bug的任務進度。然后告知客戶相應的維護計劃。（2）對于“完善性維護”，負責人要綜合分析“客戶需求建議”的價值，以及本公司的開發(fā)資源，然后決定“何人、何時”修改軟件。3.6.3執(zhí)行維護維護人員根據(jù)商定的計劃執(zhí)行維護（修改Bug或改進軟件）。注意事項：（1）維護人員修改軟件后，必須通過測試，確保沒有引入新的錯誤之后，再去更新那些受影響的客戶的軟件，例如發(fā)行“軟件補丁”。（2）維護人員必須嚴格遵循“軟件配置管理”規(guī)范，避免軟件代碼版本發(fā)生混亂。（3）維護人員及時填寫“維護記錄”，說明自己做了什么事情和相應的工作量，不僅便于對維護工作進行統(tǒng)計分析，將來在業(yè)績考核時候也用得上。格式見表3-11。軟件維護記錄所屬項目/產(chǎn)品所屬客戶維護內(nèi)容維護工作量維護日期表3-11維護記錄第4章支持過程4.1軟件配置管理4.1.1軟件配置管理的概念軟件配置管理（SoftwareConfigurationManagement,SCM）是指通過執(zhí)行版本控制、變更控制等規(guī)程，以及使用合適的配置管理軟件，來保證所有配置項的完整性和可跟蹤性。配置管理是對工作成果的一種有效保護。軟件開發(fā)和管理過程中會產(chǎn)生許許多多的工作成果，例如文檔、程序和數(shù)據(jù)等，它們都應當被妥善地保管起來，以便查閱和修改。如果把所有文件一股腦地塞進計算機里，那么使用起來肯定很麻煩。毫無疑問，人們應當將文件分門別類、有條理地保存起來。凡是納入配置管理范疇的工作成果統(tǒng)稱為配置項（ConfigurationItem），配置項主要有兩大類：軟件代碼（包括源代碼和二進制代碼）和文檔。每個配置項的主要屬性有：名稱、標識符、文件狀態(tài)、版本、