【正文】 人員參加友誼活動，例如運動、聚餐、娛樂等等。二、 處理不合理的變更項目經(jīng)理（和銷售人員）要設(shè)法“拒絕客戶提出的不合理變更” 。所謂“不合理的變更”是指：客戶提出的變更不是由于開發(fā)方的過錯引起的，此變更造成開發(fā)方承擔(dān)了額外的成本，但是客戶不愿意支付相應(yīng)的費用?？蛻魰氘?dāng)然地以為變更是他的權(quán)利，通常情況下開發(fā)方是不敢得罪客戶的，但是無原則地退讓將使開發(fā)團隊陷入困境。這里建議了三種應(yīng)對方法：方法 1：依據(jù)合同處理變更如果客戶是很有信譽、嚴(yán)格按照合同辦事的企業(yè)，那么雙方應(yīng)當(dāng)依據(jù)合同中的條款處理變更糾紛。這就要求雙方在簽訂合同的時候，要在合同中寫明“變更處理協(xié)議” 。例如：當(dāng)《需求規(guī)格說明書》被雙方確認之后，如果再發(fā)生需求變更的話，那么按照“變更申請－審批－執(zhí)行”的變更管理流程執(zhí)行。如果客戶（或者開發(fā)方）提出的變更對項目進度、成本的影響超過 10%，那么雙方要重新協(xié)商成本、資源和進度，否則開發(fā)方（或者客戶）可以拒絕變更請求。方法 2：設(shè)法拖延到下個版本如果雙方簽訂的合同中沒有“變更協(xié)議” ，或者有變更協(xié)議但是客戶找出很多理由來搪塞，只要雙方還沒有完全鬧僵的話，項目經(jīng)理（和銷售人員）需要一些社交技巧來減緩矛盾：首先承認客戶提出的需求變更請求是合理的（讓客戶面子上過得去） ；再闡述己方的難處和變更對客戶造成的不利影響，例如質(zhì)量問題等等，讓客戶明白隨意變更對他自己也沒有好處；最后建議在開發(fā)新版本的時候?qū)崿F(xiàn)客戶提出的變更。這種方式比直接拒絕有效得多，既不得罪客戶，又為自己爭取了余地。拖延到下個版本實現(xiàn)客戶的變更，有可能讓客戶支付升級費用。即使升級是免費的，也不會延誤當(dāng)26 / 52前項目的進度和客戶驗收，讓開發(fā)方及時拿到合同經(jīng)費。方法 3：讓客戶欠下人情如果客戶提出重大的變更請求，既不愿意支付變更的費用，也不愿意延緩到下個版本中實現(xiàn)，而且客戶也知道自己理虧，但是現(xiàn)實環(huán)境迫使客戶必須那樣做。開發(fā)方?jīng)]有辦法拒絕，因為倘若拒絕的話，就得不到合同余款，怎么辦？在這種情況下，開發(fā)方只能接受讓自己吃虧的變更，但是還有辦法減少損失，這個辦法就是“讓客戶欠下人情” 。銷售人員（和項目經(jīng)理）應(yīng)當(dāng)真誠地和客戶溝通，讓客戶明白“開發(fā)方為了客戶的利益付出了額外的代價” 。只要客戶是個講道理的正常人，那么客戶會感激開發(fā)方的幫助，覺得自己欠下了“人情” ，可以約定在后面恰當(dāng)?shù)臋C會回報開發(fā)方。例如，在客戶驗收的時候，適當(dāng)?shù)胤潘梢?，及時地向開發(fā)方支付合同費用等，這些回報對開發(fā)方而言都是隱形的收益。三、發(fā)掘新的商機項目經(jīng)理（和銷售人員）和客戶交往的過程中，不僅要關(guān)注已經(jīng)簽訂合同的項目進展情況，還要不斷發(fā)掘新的商機，例如：? 發(fā)掘客戶更深層次的需求，吸引客戶繼續(xù)采購（例如不斷升級） 。? 將合同項目的成果轉(zhuǎn)化成為通用的產(chǎn)品或構(gòu)件，賣給其它客戶。? 請老客戶推薦其新客戶。 問題跟蹤問題跟蹤的范圍包括：開發(fā)過程中的各種問題、風(fēng)險和建議，以及結(jié)項后遺留的問題。問題跟蹤的一般步驟如圖 26 所示，問題跟蹤表見表 212。第 1 步。報告者創(chuàng)建問題，指定接收者，此時狀態(tài)為“新的” 。第 2 步。接受者處理問題，狀態(tài)為“正在處理” 。第 3 步。如果已經(jīng)解決了問題，則把狀態(tài)置為“解決待關(guān)閉” 。第 4 步。報告者審核這個問題，如果確定該問題已經(jīng)解決，則把狀態(tài)設(shè)置為“關(guān)閉” 。如果發(fā)現(xiàn)問題沒有解決，則可以“重新打開”問題，回到第 2 步。報告問題♀報告者 ♀接受者 ♀報告者處理問題 解決待關(guān)閉 審核關(guān)閉♀接受者重新打開27 / 52圖 26 問題跟蹤示意圖問題跟蹤表問題編號 問題類型重要性 緊急程度問題描述報告者 報告時間接受者 期望完成日期問題處理方案當(dāng)前狀態(tài) 實際完全日期審核關(guān)閉意見表 212 問題跟蹤表28 / 52第 3 章 項目研發(fā)過程 需求開發(fā) 與管理需求開發(fā)與管理是指通過“調(diào)研、分析、定義、評審、跟蹤”等活動，使開發(fā)方和委托方（客戶或本公司領(lǐng)導(dǎo)）對需求有共同、清晰的理解，并依據(jù)雙方確認的需求開展后續(xù)開發(fā)工作（如設(shè)計、編程、測試等） 。項目經(jīng)理根據(jù)本項目的人力資源來確定需求分析員（可以多人） 。需求分析員負責(zé)開展調(diào)研、分析、定義、評審、跟蹤等活動。 需求調(diào)研需求分析員起草需求問題表，將調(diào)查重點鎖定在該問題表內(nèi)，否則調(diào)研工作將變得漫無邊際。需求分析員確定需求調(diào)研的方式，例如：? 與用戶交談，向用戶提問題。? 參觀用戶的工作流程，觀察用戶的操作。? 向用戶群體發(fā)調(diào)查問卷。? 與同行、專家交談，聽取他們的意見。? 分析已經(jīng)存在的同類軟件產(chǎn)品，提取需求。? 從行業(yè)標(biāo)準(zhǔn)、規(guī)則中提取需求。? 從 Inter 上搜查相關(guān)資料。需求分析員在調(diào)研過程中隨時填寫“客戶需求記錄” ，參考格式如表 31 所示。項目名稱 需求分析員調(diào)研方式 被調(diào)研者時間、地點需求標(biāo)題 客戶需求記錄表 31 客戶需求記錄需求分析員整理所有客戶需求記錄，歸納與總結(jié)共性的需求，為撰寫詳細的《需求規(guī)格說明書》作準(zhǔn)備。調(diào)研過程中獲取的需求信息可以作為《需求規(guī)格說明書》的附件。29 / 52 需求分析需求分析是對各種來源的需求信息進行分析，消除錯誤，刻畫細節(jié)等。常見的需求分析方法有“問答分析法”和“建模分析法”兩類。問答分析最重要的問題是：“是什么”和“為什么” 。每個需求都應(yīng)當(dāng)用陳述句說明“是什么” ，如果“是什么”的內(nèi)涵不夠清晰，則應(yīng)補充說明“不是什么” 。如果“是什么”和“不是什么”并不是“理所當(dāng)然”的，那么應(yīng)當(dāng)解釋“為什么” ，以便加深讀者的理解。追究“是什么”和“為什么”的目的是獲得正確、清楚的需求。對于某些類型的信息，用圖形表示要比文本表示更加有效。所以將圖形與文本結(jié)合起來描述需求是很自然的方法。需求建模就是指用圖形符號來表示、刻畫需求?，F(xiàn)代建模工具如 Rose 有非常豐富的圖形符號和文字標(biāo)注，能很好地表達模型的細節(jié)。要注意的是：在建模時使用花樣過多的圖形符號或文字意味著模型表示的復(fù)雜化，將使開發(fā)人員更難掌握，而且使圖形文檔更加雜亂。世上不存在一個包羅萬象的圖用以完整地描述需求。需求建模不可能取代文字描述。在需求文檔中，文字描述是第一重要的，建模主要是起分析、解釋作用。建議將模型存放在需求文檔的附錄中，便于正文引用。 需求定義需求分析員根據(jù)需求調(diào)查和需求分析的結(jié)果，進一步定義準(zhǔn)確無誤的需求，撰寫《需求規(guī)格說明書》 ，模板見表 32。 提示：若有其它類型的需求規(guī)格說明書，請另定義模板。軟件需求規(guī)格說明書1. 背景介紹2. 軟件系統(tǒng)的用戶介紹 用戶類型和角色職責(zé) 用戶組織結(jié)構(gòu)圖（可選） 用戶的信息化情況3. 用戶業(yè)務(wù)流程介紹4. 軟件系統(tǒng)的約束5. 軟件系統(tǒng)當(dāng)前版本的范圍6. 軟件系統(tǒng)的功能清單7. 模塊需求說明（可以寫在單獨的模塊文檔中）8. 其它需求9. 簽字確認表 32 軟件需求規(guī)格說明書30 / 52 需求評審需求分析員邀請項目成員（包括項目經(jīng)理）和客戶代表共同評審《需求規(guī)格說明書》 ，大家盡最大努力使《需求規(guī)格說明書》能夠正確無誤地反映用戶的真實意愿。需求評審的流程見“項目評審流程” 。一般地，需求分析員為申請人，項目經(jīng)理為評審負責(zé)人，項目成員和客戶代表可以擔(dān)任評審員。所有評審人員認真檢查需求文檔，力求使需求文檔達到正確、清楚、無二義性、一致、必要、完備、可實現(xiàn)、可驗證。 需求跟蹤第 1 步。需求分析員創(chuàng)建需求的目錄結(jié)構(gòu)，便于人們閱讀。第 2 步。需求分析員輸入每條需求的詳細內(nèi)容，可以多次細化修改，每次修改后應(yīng)通知相關(guān)項目成員。第 3 步。需求分析員跟蹤每條需求的進展?fàn)顩r，填寫需求跟蹤記錄（當(dāng)前狀態(tài)和情況說明），需求跟蹤表的格式見表 33。需求跟蹤表需求目錄/名稱 優(yōu)先級 狀態(tài) 責(zé)任人 關(guān)聯(lián)信息（文檔，任務(wù)，缺陷等）表 33 需求跟蹤表 系統(tǒng)設(shè)計 軟件系統(tǒng)設(shè)計軟件系統(tǒng)設(shè)計的主要內(nèi)容有體系結(jié)構(gòu)設(shè)計、用戶界面設(shè)計、數(shù)據(jù)庫設(shè)計等，在需求與代碼之間建立橋梁，指導(dǎo)工作人員開發(fā)能夠滿足用戶需求的軟件系統(tǒng)。項目經(jīng)理根據(jù)本項目的人力資源來確定軟件設(shè)計師（可以多人） 。軟件設(shè)計師撰寫《軟件系統(tǒng)設(shè)計說明書》 ，并構(gòu)造可運行的軟件系統(tǒng)框架，所有的模塊都是在該系統(tǒng)框架上開發(fā)和運行。 《軟件系統(tǒng)設(shè)計說明書》的模板參見表 34。31 / 52軟件系統(tǒng)設(shè)計說明書1. 軟件系統(tǒng)概述2. 設(shè)計約束3. 開發(fā)、測試與運行環(huán)境4. 軟件體系結(jié)構(gòu)圖5. 功能模塊設(shè)計概述 模塊匯總 模塊之間的關(guān)系6. 數(shù)據(jù)庫設(shè)計概述 數(shù)據(jù)庫環(huán)境說明 數(shù)據(jù)庫命名規(guī)則 安全性設(shè)計說明 表匯總和表設(shè)計7. 用戶界面設(shè)計概述8. 綜合考慮（可選） 穩(wěn)定性和可擴展性 性能分析 復(fù)用和移植 防錯與出錯處理 其它表 34 軟件系統(tǒng)設(shè)計說明書 設(shè)計評審設(shè)計評審的目的是在同行專家的幫助下，盡早地發(fā)現(xiàn)本系統(tǒng)中存在的設(shè)計缺陷，及時消除設(shè)計缺陷。當(dāng)軟件設(shè)計師撰寫完成《軟件系統(tǒng)設(shè)計說明書》，并構(gòu)建可運行的系統(tǒng)框架之后，邀請項目成員（包括項目經(jīng)理）和本公司技術(shù)專家開展設(shè)計評審。設(shè)計評審的流程見“項目評審流程” 。 模塊開發(fā)與集成項目經(jīng)理分配合適的模塊開發(fā)任務(wù)給開發(fā)人員，開發(fā)人員對自己承擔(dān)模塊的質(zhì)量和開發(fā)進度負責(zé)。開發(fā)人員閱讀《需求規(guī)格說明書》和《系統(tǒng)設(shè)計說明書》 ，分析并細化自己承擔(dān)的模塊需求，并且進行模塊細節(jié)設(shè)計，撰寫《模板需求和設(shè)計文檔》 ，見表 35。32 / 52所有開發(fā)人員按照既定的規(guī)范（如編程規(guī)范）來實現(xiàn)自己承擔(dān)的模塊，并在系統(tǒng)框架中和其它模塊集成一起。開發(fā)人員完成模塊開發(fā)后，必須先進行自我測試，必須走通模塊的所有功能，消除自己已經(jīng)發(fā)現(xiàn)的缺陷，然后交付給下個環(huán)節(jié)。模塊文檔（需求和設(shè)計）項目名稱 模塊名稱撰寫人 完成日期1. 模塊功能和流程介紹說明模塊用途、主要功能，最好繪制功能結(jié)構(gòu)圖和工作流程。2. 模塊的設(shè)計思路3. 模塊的主要數(shù)據(jù)結(jié)構(gòu)4. 本模塊的主要調(diào)用（1）本模塊主要調(diào)用了其它模塊的哪些接口；（2）本模塊為其它模塊提供了什么接口。5. 其它說明表 35 模塊需求和設(shè)計文檔 測試與缺陷跟蹤測試與缺陷跟蹤的流程見下圖31。圖 31 測試與缺陷跟蹤的流程測試準(zhǔn)備消除缺陷執(zhí)行測試♀測試人員缺陷跟蹤審核關(guān)閉♀開發(fā)人員提交測試♀開發(fā)負責(zé)人 ♀測試負責(zé)人33 / 52 提交測試開發(fā)負責(zé)人把待測試物品（如軟件包）交付給測試組之前，必須完成以下工作（否則測試人員可以拒絕接受）：（1）在配置庫中打標(biāo)記（Label ） ，這個 Label 就是待測試物品（如軟件包）的版本號（建議包含年月日時分的信息） 。（2）說明該版本要測試什么，注意事項等。（3）開發(fā)人員必須測試自己開發(fā)的功能，通過后才可以交付給測試人員。 測試準(zhǔn)備測試準(zhǔn)備主要有三件事情：分配測試任務(wù)，設(shè)計測試用例，構(gòu)建測試環(huán)境。一、分配測試任務(wù)測試負責(zé)人和測試人員商議測試計劃，安排合適的測試人員執(zhí)行測試任務(wù)。二、設(shè)計測試用例測試用例是用于檢驗?zāi)繕?biāo)系統(tǒng)是否符合需求的一種“示例” ，基本要素有：前提條件、輸入數(shù)據(jù)或動作、期望的響應(yīng)。 《測試用例》就是描述各種測試用例的文檔，相當(dāng)于一本“測試操作手冊” 。關(guān)于測試用例的一些常識如下：（1）設(shè)計測試用例的目的是找出需求、設(shè)計、代碼中的毛病，因此最好盡可能早地設(shè)計測試用例。（2）不同的測試用例其用途應(yīng)當(dāng)不一樣，不要累贅。（3）顯而易見的測試用例不必完整地用文字描述，因為此時文字描述的價值不大、反而消耗時間。測試人員根據(jù)模塊的需求和設(shè)計說明書，撰寫《測試用例》 ，格式見表 36。最好由開發(fā)人員審閱《測試用例》 ，提出改進建議，雙方達成共識。測試用例用例名稱 項目名稱對應(yīng)模塊 撰寫人前提條件輸入 / 動作 期望的輸出示例：典型值…示例：邊界值…示例：異常值…34 / 52審閱人 / 意見表 36 測試用例三、構(gòu)建測試環(huán)境測試人員（和開發(fā)工程師）構(gòu)建測試環(huán)境，注意測試環(huán)境要盡可能接近用戶的實際運行環(huán)境。 執(zhí)行測試測試人員執(zhí)行測試，填寫測試報告，見表 37。測試報告目錄/用例名稱 測試人員 測試記錄/結(jié)論 測試時間表 37 測試報告 缺陷跟蹤缺陷跟蹤如圖 32 所示，缺陷跟蹤表見表 38。一般步驟如下：第 1 步。測試人員（報告者）如果發(fā)現(xiàn)缺陷，則記錄缺陷的詳細信息，報告給開發(fā)人員（接受者） 。此時缺陷的狀態(tài)是“新的” 。第2步。開發(fā)人員處理缺陷，此時缺陷的狀態(tài)是“正在處理” 。提示：如果開發(fā)人員把缺陷狀態(tài)設(shè)置為“不做處理或延后處理”，則項目經(jīng)理召集相關(guān)人員評審那些“不做處理或延后處理”的缺陷，給出“處理”還是“不處理”決定。第 3 步。如果開發(fā)人員消除了缺陷，則把缺陷的狀態(tài)設(shè)置為“解決待關(guān)閉” 。第 4 步。測試人員重新測試該缺陷對應(yīng)的功能，如果確定缺陷已經(jīng)消除，則把狀態(tài)設(shè)置為“關(guān)閉” 。如果發(fā)現(xiàn)該缺陷沒有解決，則可以“重新打開”缺陷，回到第 2 步。報告缺陷♀報告者 ♀接受者 ♀報告者處理缺陷 解決待關(guān)閉 審核關(guān)閉♀接受者重新打開35 / 52圖 32 缺陷跟蹤的流程缺陷跟蹤表缺陷編號 缺陷類型嚴(yán)重性 緊急程度缺陷描述報告者 報告時間接受者 期望完成日期缺陷解決方案當(dāng)前狀態(tài) 實際完全日期審核關(guān)閉意見表 38 缺陷跟蹤表 消除缺陷消除缺陷的