前 言
前一篇文章
《軟件開發(fā)基本原則》談?wù)摿塑浖_發(fā)原則方面的問題，而本篇文章嘗試談?wù)勡浖_發(fā)中更具體的一些內(nèi)容 —— 普通軟件項目的開發(fā)過程規(guī)范。本座也知道，如果過程規(guī)范講的太具體對談?wù)撜邅碚f是非常冒險的一件事情，它不像技術(shù)，對就對錯就錯，有一個客觀的評判標準，別人想噴你也得自己先好好研究等拿到了足夠的論據(jù)才能噴，但開發(fā)過程和項目管理就不同了，別人僅憑一點點所謂的管理經(jīng)驗甚至是主觀推斷就能噴得你體無完膚，搖搖欲墜 ~ 因為沒有什么所謂的事實標準與放之四海皆有效的軟件開發(fā)過程和項目管理方法。保守估計，100個人中至少有150種想法。本座也深知其中的兇險，因此避重就輕，從基本原理談起，宏觀的角度闡述相關(guān)問題，盡量減少中彈的機會。歡迎大家暢所欲言 ^_*
本文闡述軟件項目開發(fā)和管理的流程規(guī)范，作為軟件項目開發(fā)的高級指引，本規(guī)范定義了軟件開發(fā)的各個階段以及每個階段的工作活動和工件，但不對活動和工件的細節(jié)作過多規(guī)定。在項目開發(fā)過程中，每個項目根據(jù)自身的需要確定這些活動和工件的細節(jié)。
項目階段
圖 2-1 項目開發(fā)的五個階段
啟動階段
這個階段的工作目的是決定一個項目是否需要啟動。為了達到這個目的，首先要明確項目的總體戰(zhàn)略目標，對項目的需要建立認同。即確定到底需要做什么、開發(fā)什么產(chǎn)品或提供什么服務(wù)，以及需要解決什么樣的問題和需要滿足客戶或市場的什么要求等，同時還要總結(jié)項目工作的范圍、所需資源、大約開支、各種風(fēng)險，以及該項目不執(zhí)行的其他替代選擇等。這些代表了對整個項目目標從戰(zhàn)略角度和宏觀層次所進行的分析，通過項目的意向書總結(jié)出來，由此確證客戶或項目發(fā)起人和贊助者的要求與期望，并幫助他們判定項目是否上馬。項目意向總結(jié)書的通過及項目被批準上馬形成了這個項目的起始點。
計劃階段
這個階段的工作是為整個項目做計劃。項目開始后，首先要確定項目的具體范圍，明確定出項目到底要做什么，總結(jié)、歸納并定出產(chǎn)品的功能。然后進一步制定項目的計劃，列出每項具體工作，并建立所有工作任務(wù)的重要性及順序；確定每項工作的執(zhí)行人和所需資源；根據(jù)人員的配置和能力設(shè)定各項工作和整個項目的完成時間表。
執(zhí)行階段
這個階段的工作是通過執(zhí)行項目的計劃來完成項目的任務(wù)。它包括落實一切所需資源，如：人員、設(shè)備、費用、技術(shù)、信息，由管理者領(lǐng)導(dǎo)全體項目參與者開展各項工作。同時跟蹤各項具體工作和整個項目的進度，定期向全體項目人員及項目的發(fā)起人報告項目狀態(tài)。
控制階段
這個階段的工作是確證項目工作的結(jié)果符合項目的計劃。它通過對項目結(jié)果的衡量和審核，與項目計劃所期望的結(jié)果進行比較，找出實際結(jié)果與計劃的差別，并制定處理措施。這個階段的工作還包括對項目進程中出現(xiàn)的任何更改要求進行審核和批準。同時調(diào)解項目進程中出現(xiàn)的各種問題，如：對缺乏的資源的補償調(diào)節(jié)；對項目的進度表及各項具體工作的優(yōu)先級或順序的修訂。
結(jié)束階段
這個階段的工作是確保項目的最終結(jié)果或提交物達到計劃的要求，并對完成的結(jié)果作可接受的確認。還包括在項目完成之后的收尾工作，對整個項目的經(jīng)歷進行總結(jié)，修訂項目文檔，用戶培訓(xùn)等。
階段完成標志
在項目開發(fā)過程中，當(dāng)一個階段完成后才會開展下一個階段的工作；另外，“某個階段完成”通常被定義為項目的一個里程碑，里程碑標識了項目的進度，它是項目開發(fā)和控制的重要參考，對整個項目有重要的意義。因此，“確證某個階段是否已經(jīng)完成”的工作非常有重要。
每一個階段的結(jié)束以它特定任務(wù)的完成為象征
只有當(dāng)某個階段中被規(guī)定的所有工作任務(wù)都完成了，這個階段才算真正結(jié)束，整個項目才可以進入到下一個階段中去。反過來說，要是階段中某個任務(wù)沒有全部完成，按照項目的定義，整個階段就不能算是完成，因此項目就不能進入到下一個階段去。
衡量階段結(jié)束的工作結(jié)果必須是實在的交付品
階段中的任務(wù)是否完成是透過任務(wù)活動中產(chǎn)生的交付品來體現(xiàn)的，交付品必須是可交付的、非抽象的、實質(zhì)的并且可以通過用衡量的方法來判斷是否真正地完成了的具體事物。如：某一階段的完成是以建造一個樣品或完成某分文件作為象征。任何項目階段的結(jié)束，都應(yīng)該有這樣的實質(zhì)性東西的完成作為象征。
跨階段的進程以階段結(jié)尾的合格驗證和審核來決定
當(dāng)一個階段結(jié)束時，在進入到下一個階段之前所需要做的工作應(yīng)包括對交付品進行合格驗證，并檢查這一階段的工作質(zhì)量和效率，由此判斷是否可以進入到下一個階段。這些檢驗象征了一個階段的結(jié)尾終點，表示項目的進程離開了上一個階段而進入了下一個階段。
啟動階段
圖 3-1 啟動階段的任務(wù)和工件
產(chǎn)品領(lǐng)域研究
研究產(chǎn)品所在領(lǐng)域的狀況，為項目論證提供依據(jù)。研究內(nèi)容包括：
產(chǎn)品領(lǐng)域的現(xiàn)狀和前景
產(chǎn)品領(lǐng)域的商業(yè)模式和業(yè)務(wù)流程
產(chǎn)品的價值和盈利空間
產(chǎn)品的特性和復(fù)雜度
技術(shù)可行性研究
研究產(chǎn)品的實現(xiàn)技術(shù)，總結(jié)技術(shù)可行性。研究內(nèi)容包括：
類似產(chǎn)品的當(dāng)前實現(xiàn)技術(shù)和技術(shù)趨勢
實現(xiàn)技術(shù)的候選方案
各個方案的優(yōu)點、成本和風(fēng)險
開發(fā)團隊與實現(xiàn)技術(shù)的匹配情況
項目論證
基于商業(yè)和技術(shù)等方面對項目的可行性進行論證，確定項目是否開展。如果開展項目，則進一步論證項目的總體方案。
論證的內(nèi)容包括：
商業(yè)可行性
技術(shù)可行性
當(dāng)前產(chǎn)品與類似產(chǎn)品的比較
項目收益和前景
項目的成本和風(fēng)險
項目的總體方案
確定項目目標和范圍
項目開始時，所有相關(guān)人員必須對項目的目標和范圍達成共識，形成共同的項目愿景。并把愿景敘述為《項目開發(fā)大綱》向相關(guān)人員傳達。
《項目開發(fā)大綱》的內(nèi)容包括：
概 述
用三到五張圖表來描述產(chǎn)品目標、功能、平臺、客戶、進度表和開發(fā)職責(zé)
高級功能
用一個段落來綜述產(chǎn)品，再用一個段落來描述每個重要的功能
不實現(xiàn)的功能
用一個段落來描述每個對產(chǎn)品有用的但本項目不實現(xiàn)的功能
涉 眾
用一個段落來明確每個重要的涉眾群體和他們的風(fēng)險股本
項目需求
用一個段落來講述每個重要的項目需求
項目風(fēng)險
按風(fēng)險暴露量對每個重要的項目風(fēng)險都用一個段落來討論
項目回報
用一個段落綜述產(chǎn)品的回報，其后再對每個重要的項目回報都用一個段落來討論
結(jié) 論
用一到三個段落將上述所有部分聯(lián)系起來，明確項目的需求和風(fēng)險，再用論點和論據(jù)來總結(jié)為什么這個項目會成功
表 3-1 項目開發(fā)大綱
計劃階段
圖 4-1 計劃階段的任務(wù)和工件
規(guī)模、工作量評估
圍繞各項計劃的制定工作對項目的規(guī)模、工作量等進行評估，評估的內(nèi)容包括：
模塊數(shù)量與復(fù)雜度
輸入、輸出和對外接口等數(shù)量與復(fù)雜度
SLOC和功能點
非生產(chǎn)性的支持工作量
開發(fā)工作量（人月）
進度與里程碑
進度風(fēng)險
定制項目開發(fā)計劃
項目開發(fā)計劃體現(xiàn)了項目組對整個開發(fā)周期的預(yù)期，指定了項目開發(fā)的總體方針。與其他計劃一樣，項目開發(fā)計劃不是固定不變的，在執(zhí)行過程中要對計劃進行監(jiān)控，可能會根據(jù)實際情況修改計劃并重新發(fā)布。
《項目開發(fā)計劃》的內(nèi)容包括：
概 述
用三到五張圖表來描述產(chǎn)品目標、功能、平臺、客戶、進度表和開發(fā)職責(zé)。
（《項目開發(fā)計劃》的概述部分應(yīng)該是《》中概述部分的拷貝。當(dāng)項目計劃改變時，修訂《項目開發(fā)計劃》的概述部分而不是修訂《項目開發(fā)大綱》。這樣，以后在進行項目評價時，通過比較《》和《項目開發(fā)計劃》的概述，就能看出項目是如何改變的）
高級功能
用一到五頁的篇幅來概述產(chǎn)品的功能，其中，要包括這些功能的附加信息（開發(fā)者需要這樣的信息來了解實現(xiàn)需求）。
項目成員
確定軟件工程職能角色，以及分配到這些角色的人員數(shù)量。
軟件過程
概述這個項目中所應(yīng)用的軟件過程。
（具體內(nèi)容可在《》中定義）
軟件工程方法
概述這個項目中所應(yīng)用的軟件工程方法和技術(shù)。
（具體內(nèi)容可在《》中定義）
進度和工作量
這一部分要表達出整個項目進度和工作量的估計。其中要包括： 對固定不變的里程碑和同步點的解釋
在評估中的設(shè)想情況、評估中的不準確性的可能來源
隨著項目的進展如何更新評估
（具體進度表內(nèi)容可在《》中定義）
風(fēng)險管理計劃
概述這個項目中風(fēng)險管理計劃。
（具體內(nèi)容可在《》中定義）
測 量
概述這個項目中要收集的測量。
軟件工具
列出要使用的每一項軟件工具，以及該工具所支持的任務(wù)。
項目支持
硬件支持 明確所需的硬件，包括那些需要移動、獲取或升級的硬件。
軟件支持 明確所需的軟件，包括需要獲取、安裝或升級的軟件件。
人力支持 由哪個人、部門或團隊為開發(fā)組的哪項任務(wù)提供支持。
表 4-1 項目開發(fā)計劃
定制風(fēng)險管理計劃
風(fēng)險管理任務(wù)包括：風(fēng)險識別、風(fēng)險分析、確定風(fēng)險優(yōu)先級、定制風(fēng)險化解方案、風(fēng)險化解和風(fēng)險監(jiān)控【如：圖4-2】。
圖 4-2 風(fēng)險管理任務(wù)
《風(fēng)險管理計劃》定義這些任務(wù)的執(zhí)行流程和人員分配。
《風(fēng)險管理計劃》的內(nèi)容包括：
概 述
用文字和圖表概述風(fēng)險管理任務(wù)的總體執(zhí)行流程。
風(fēng)險識別
詳細說明“風(fēng)險識別”任務(wù)的實施細節(jié)和各項工作的負責(zé)人。
風(fēng)險分析
詳細說明“風(fēng)險分析”任務(wù)的實施細節(jié)和各項工作的負責(zé)人。
確定風(fēng)險優(yōu)先級
詳細說明“確定風(fēng)險優(yōu)先級”任務(wù)的實施細節(jié)和各項工作的負責(zé)人。
定制風(fēng)險化解方案
詳細說明“定制風(fēng)險處理方案”任務(wù)的實施細節(jié)和各項工作的負責(zé)人。
風(fēng)險化解
當(dāng)風(fēng)險發(fā)生時，需要采取相應(yīng)的措施化解風(fēng)險。 這部分的內(nèi)容是描述風(fēng)險化解工作的操作規(guī)范和流程。
風(fēng)險監(jiān)控
詳細說明風(fēng)險監(jiān)控任務(wù)的實施細節(jié)和各項工作的負責(zé)人。
表 4-2 風(fēng)險管理計劃
風(fēng)險管理中通常會用到《Top N 風(fēng)險列表》，風(fēng)險列表按照風(fēng)險暴露量排序列出當(dāng)前項目中主要的N個風(fēng)險，《Top N 風(fēng)險列表》的內(nèi)容包括：
本周排名
本周的排名（如果本周已被完全化解用“---”表示）
上周排名
上周排名（如果是新識別的風(fēng)險用“---”表示）
上表周數(shù)
該風(fēng)險已上表的周數(shù)
風(fēng) 險
風(fēng)險的名稱或簡述
類 型
風(fēng)險類型（只針對進度相關(guān)的風(fēng)險）： 計劃編制
組織和管理
設(shè)計和實現(xiàn)
客戶和需求
承包商
產(chǎn)品
人員
過程
技術(shù)
外部環(huán)境
開發(fā)環(huán)境
發(fā)生概率
風(fēng)險發(fā)生的百分比概率
損失程度
風(fēng)險發(fā)生時損失的進度（工作日或工作周）
暴露量
發(fā)生概率 X 損失程度
狀 態(tài)
風(fēng)險的當(dāng)前狀態(tài)：未發(fā)生、已發(fā)生、已化解
化解方案
簡述風(fēng)險的化解方案，如果有具體的化解方案文檔則鏈接到相應(yīng)文檔
化解進度
對已發(fā)生的風(fēng)險，簡述化解進度（未發(fā)生的風(fēng)險用“---”表示）
表 4-3 風(fēng)險列表
定制質(zhì)量保證計劃
保證工作質(zhì)量的一個重要步驟是制定一套合理的質(zhì)量保證計劃并貫徹執(zhí)行。
《質(zhì)量保證計劃》的內(nèi)容包括：
概 述
說明編寫的目的、適用范圍以及對相關(guān)人員的要求等
軟件過程
詳細說明這個項目中所應(yīng)用的軟件過程。
軟件工程方法
詳細說明這個項目中所應(yīng)用的軟件工程方法和技術(shù)。
工作規(guī)范
對工程方法中的各種工作任務(wù)進行規(guī)范，明確執(zhí)行的時機、流程和準則等。這些工作任務(wù)包括：
常規(guī)開發(fā)活動（需求分析、架構(gòu)設(shè)計、詳細設(shè)計、編碼和測試、發(fā)布和實施等）
會議（工作例會、進度會議、審查會議等）
評審（方案評審、技術(shù)評審、質(zhì)量評審等）
測量（產(chǎn)品規(guī)模測量、進度測量、缺陷率測量、測試覆蓋率測量等）
其他活動（技能培訓(xùn)、資料收集、內(nèi)部流、客戶溝通等）
表 4-4 工作規(guī)范
定制開發(fā)進度計劃
基于當(dāng)前對項目的規(guī)模和工作量評估，定制初步的開發(fā)進度表，作為項目開發(fā)計劃的組成部分。
《開發(fā)進度表》的內(nèi)容包括：
項目的開始和結(jié)束時間
項目各個階段的開始和結(jié)束時間
每個階段的工作任務(wù)及其開始和結(jié)束時間
每個工作任務(wù)的子任務(wù)的及其開始和結(jié)束時間
里程碑和同步點
角色的定義和任務(wù)分配
作為跟蹤項目進度的重要依據(jù)，進度表在項目推進過程中需要不斷細化。另外，當(dāng)實際進度與計劃進度出現(xiàn)偏差時，需要修改進度表并重新發(fā)布。
執(zhí)行階段
圖 5-1 執(zhí)行階段的任務(wù)和工件
需求分析
分析產(chǎn)品的關(guān)鍵需求、對架構(gòu)設(shè)計有影響的需求和風(fēng)險較高的需求，直到分析的程度能開展足界面原型設(shè)計和架構(gòu)設(shè)計工作。
《需求規(guī)格說明書》的內(nèi)容包括：
商業(yè)或業(yè)務(wù)需求
從商業(yè)或業(yè)務(wù)角度宏觀上對產(chǎn)品或系統(tǒng)的要求。它主要在宏觀的層面歸納總結(jié)為滿足客戶提出的要求或贏得市場競爭所必須實現(xiàn)的功能、性能、質(zhì)量等要求。 做什么
做的范圍
對結(jié)果的要求
使用者需求
從客戶對軟件產(chǎn)品或系統(tǒng)使用方案的角度出發(fā)，描述和總結(jié)使用者利用該軟件產(chǎn)品或系統(tǒng)能夠做的事或能夠完成的任務(wù)。
功能需求
根據(jù)上述使用者需求列出的使用方案，列出開發(fā)者必須為軟件產(chǎn)品或系統(tǒng)實現(xiàn)的功能。
性能需求
運行速度、容量、并發(fā)性能
對資源的利用率
對外界輸入的反饋速度和準確性
對差錯的負荷能力
系統(tǒng)需求
必須適應(yīng)的運行環(huán)境的要求 （包括運行平臺、網(wǎng)絡(luò)及其他硬件要求）
與其他系統(tǒng)兼容的要求 （包括與操作系統(tǒng)、數(shù)據(jù)庫、瀏覽器及其他應(yīng)用軟件的兼容要求）
與外部其他系統(tǒng)和組件的接口要求
質(zhì)量需求
對用戶重要的質(zhì)量標志 （可靠性、效率性、靈活性、安全性、互操作性、穩(wěn)定性、健全性、可用性）
對開發(fā)者重要的質(zhì)量標志 （可維護性、多用轉(zhuǎn)換性、重復(fù)使用性、可測試性）
其他需求
不屬于上述需求范圍的，但受到其他環(huán)境和商業(yè)合同影響的要求。 國家或地區(qū)的任何特別的標準
軟件使用界面的特別要求
與知識產(chǎn)權(quán)有關(guān)的要求
軟件所面對的市場和行業(yè)的規(guī)范
客戶的特別要求
開發(fā)的局限
對開發(fā)的成功與否起很大影響的因素，是開發(fā)能力的局限： 人員的局限
技術(shù)的制約和局限
客戶的特別要求
表 5-1 需求分析告
《需求分析報告》的編制方式可以是多樣的，例如把所有“非功能性需求”組織成“外部接口需求”、“質(zhì)量屬性需求”和“需求約束”。【如：圖5-2】
圖 5-2 需求規(guī)格說明書
界面原型設(shè)計
明確了系統(tǒng)的關(guān)鍵需求后，就可以進行界面原型設(shè)計工作，獲取用戶的反饋，盡快確定產(chǎn)品的界面基調(diào)。同時要編寫一份《界面設(shè)計概要》文檔，作為后續(xù)的界面設(shè)計工作的指導(dǎo)。
《界面設(shè)計概要》的內(nèi)容包括：
設(shè)計的理念
理念的來源或參考
設(shè)計的要點
與類似產(chǎn)品界面的對比
架構(gòu)設(shè)計
架構(gòu)設(shè)計從關(guān)鍵需求開始，建立概念性的架構(gòu)，并逐步細化和驗證。最終生成架構(gòu)設(shè)計說明書和架構(gòu)基線代碼。
架構(gòu)設(shè)計的方法：可以從幾個不同的視角進行架構(gòu)設(shè)計，然后匯總綜合得出完整的設(shè)計。（架構(gòu)設(shè)計的五個視圖【如：圖5-3】）
圖 5-3 架構(gòu)設(shè)計的五視圖
《架構(gòu)設(shè)計說明書》的內(nèi)容包括：
概 述
說明編寫的目的、適用范圍以及設(shè)計原則等。
邏輯架構(gòu)
關(guān)注功能。其設(shè)計著重考慮功能需求。 細化功能單元
發(fā)現(xiàn)通用機制
細化領(lǐng)域模型
確定子系統(tǒng)接口和交互機制
開發(fā)架構(gòu)
關(guān)注程序包。其設(shè)計著重考慮開發(fā)期質(zhì)量屬性，如可擴展性、可重用性、可移植性、易理解性和易測試性等。 確定要開發(fā)或直接利用的程序包之間的依賴關(guān)系
確定采用的技術(shù)、框架等
數(shù)據(jù)架構(gòu)
關(guān)注持久化數(shù)據(jù)的存儲方案。其設(shè)計著重考慮“數(shù)據(jù)需求”。 持久化數(shù)據(jù)存儲方案
數(shù)據(jù)傳遞、數(shù)據(jù)復(fù)制、數(shù)據(jù)同步等策略
運行架構(gòu)
關(guān)注進程、線程、對象等運行時概念，以及相關(guān)的并發(fā)、同步、通信等問題。其設(shè)計著重考慮運行期質(zhì)量屬性，例如性能、可伸縮性、持續(xù)可用性和安全性等。 確定引入哪些進程與線程
確定主動對象、被動對象，以及控制關(guān)系
處理進程線程的創(chuàng)建、銷毀、通信機制、資源爭用等
協(xié)議設(shè)計
物理架構(gòu)
關(guān)注軟件系統(tǒng)最終如何安裝或部署到物理機器。其設(shè)計著重考慮“安裝和部署需求”。 確定物理配置方案
確定如何將目標程序映射到物理節(jié)點
總 結(jié)
基于上述的設(shè)計進行總結(jié)，并描述架構(gòu)基線。
表 5-2 架構(gòu)設(shè)計說明書
架構(gòu)設(shè)計的另一個重要任務(wù)是編寫架構(gòu)基線代碼，基線代碼表述和驗證架構(gòu)，同時也是指導(dǎo)后續(xù)開發(fā)的基礎(chǔ)代碼。架構(gòu)基線代碼的內(nèi)容包括：
所有工程項目
工程目錄結(jié)構(gòu)
軟件包結(jié)構(gòu)
導(dǎo)入所有依賴包
基礎(chǔ)公共代碼
架構(gòu)框架代碼
架構(gòu)框架示例代碼和測試代碼
數(shù)據(jù)庫框架
圖 5-4 和圖 5-5 展示了軟件架構(gòu)師的工作和成功的軟件架構(gòu)設(shè)計包含的內(nèi)容：
圖 5-4 軟件架構(gòu)師的工作
圖 5-5 成功的軟件架構(gòu)設(shè)計
1 軟件構(gòu)建
軟件可以分階段進行構(gòu)建，每個階段可以使用增量的方式開發(fā)，用通過若干個Build構(gòu)建，最后發(fā)布階段性產(chǎn)品成果。
（注意：在這里 ，名詞“階段”的含義和本文其他地方的含義不一樣）
階段計劃
構(gòu)建階段計劃的內(nèi)容包括：
確定本階段要實現(xiàn)的功能
列出階段任務(wù)
計劃Build構(gòu)建數(shù)量
細化《開發(fā)進度表》中本階段的工作內(nèi)容
Build 構(gòu)建
詳見：下一節(jié)
階段產(chǎn)品發(fā)布
構(gòu)建階段完成后發(fā)布階段產(chǎn)品成果，向用戶展示并接受用戶反饋，同時做好階段總結(jié)。
《發(fā)布清單》的內(nèi)容包括：
產(chǎn)品版本號和日期
改正的Bug
修改的功能
實現(xiàn)的新功能
其他說明
《階段總結(jié)報告》的內(nèi)容包括：
階段任務(wù)的完成情況
進度計劃的執(zhí)行情況
用戶的反饋情況
本階段碰到的主要問題
下一階段的改進建議
2 Build 構(gòu)建
Build構(gòu)建以增量的方式執(zhí)行階段的開發(fā)任務(wù)，每個Build構(gòu)建的周期一般不超過兩星期，每一次Build構(gòu)建都會發(fā)布為一個內(nèi)部版本，并提交測試。測試發(fā)現(xiàn)的問題留待以后的Build構(gòu)建解決。
Build計劃
《Build計劃》的內(nèi)容包括：
本次Build的版本號
本次Build的歷時
本次Build的工作任務(wù) 要解決的遺留Bug
本應(yīng)由以前的Build實現(xiàn)的，但推遲到本次Build實現(xiàn)的功能
要實現(xiàn)的新功能
其他工作任務(wù)
工作任務(wù)分配
需求細化
根據(jù)《Build計劃》，細化本次Build要實現(xiàn)的需求，細化到能進行詳細設(shè)計為止。有了細化的需求后就編寫本次Build的測試計劃。
《測試計劃》的內(nèi)容包括：
功能測試 要測試的功能
測試時間
測試方式
驗收標準
其他測試（性能測試、邊界測試、使用界面測試、可用性測試、安全性測試等） 要測試的內(nèi)容
測試時間
測試方式
驗收標準
。。。。。。
界面設(shè)計
根據(jù)細化的需求設(shè)計用戶界面，當(dāng)界面確定后即可編寫測試用例。
《測試用例》的內(nèi)容包括：
測試用例對應(yīng)的功能模塊
測試用例的性質(zhì)（功能測試用例、性能測試用例、。。。。。。）
輸入（或操作步驟）
期望輸出
實際輸出（執(zhí)行測試后再填寫）
是否通過（執(zhí)行測試后再填寫）
詳細設(shè)計
詳細實際每項需求的實現(xiàn)方法，對于重要的設(shè)計決策、算法、公共模塊和外部接口等必須以模塊設(shè)計文檔的形式進行記錄?！赌K設(shè)計文檔》的內(nèi)容包括：
模塊名稱
設(shè)計思想
設(shè)計圖表（類圖、流程圖等）
要點描述（包、接口、類、方法、算法、設(shè)計模式）
測試方式
編碼、單元測試
編碼和單元測試是開發(fā)人員的工作，對于重要的代碼都必須進行單元測試，編寫代碼必須遵守下列準則：
遵守編碼規(guī)范
編碼前必須充分理解相關(guān)的需求
編碼前先進行設(shè)計，把流程理順
注意設(shè)計方法和設(shè)計模式的靈活運用
總體考慮問題，使代碼遵從架構(gòu)并容易測試
設(shè)計時要充分考慮異常情況和臨界條件
嚴禁Copy-Paste，注意提取公共代碼，在編碼過程中實現(xiàn)重構(gòu)
異常處理必須記錄日志，嚴禁草率地直接打印異常信息
靈活運用ASSERT() / VERIFY()等斷言來幫助調(diào)試程序
單元測試是程序員的工作，所以編碼完成后必須對代碼嚴格測試
功能代碼完成后必須先做以下4件事情： 編譯代碼，保證編譯通過
（不運行程序）對代碼進行全面檢查
用調(diào)試模式啟動程序，一行一行單步執(zhí)行代碼，并注意調(diào)試輸出
改變條件，讓代碼盡可能走遍所有程序分支
Check In代碼前必須保證能編譯通過
創(chuàng)建Build
代碼集成發(fā)布前需凍結(jié)代碼，所有人把要提交的代碼Check In，并保證編譯后的程序能在測試服務(wù)器上正常啟動，界面能正常打開。同時還要提交Build清單。
《Build清單》的內(nèi)容包括：
Build版本號和日期
改正的Bug
修改的功能
實現(xiàn)的新功能
其他說明
集成測試
按照《測試計劃》針對《Build清單》執(zhí)行《測試用例》，測試完成后編寫測試報告。
《測試報告》的內(nèi)容包括：
測試用例匯總（用例數(shù)量、通過的用例數(shù)量、未通過的用例數(shù)量等）
Bug匯總（Bug總數(shù)、新增Bug數(shù)量、關(guān)閉Bug數(shù)量、Bug趨勢圖表等）
測試計劃執(zhí)行情況
測試總結(jié)
控制階段
圖 6-1 控制階段的任務(wù)和工件
風(fēng)險管理
開發(fā)期間要對風(fēng)險進行監(jiān)控，定期檢查、更新和發(fā)布《風(fēng)險列表》。
質(zhì)量管理
1） 評審
評審是質(zhì)量保證的重要環(huán)節(jié)，原則上每個重要的工作任務(wù)或階段結(jié)束前都必須經(jīng)過評審，如：方案評審、計劃評審、需求評審、設(shè)計評審和代碼評審等，工作是否被通過、是否需要修改或重做均由評審結(jié)果決定，評審結(jié)果以《評審報告》的形式發(fā)布。
《評審報告》的內(nèi)容包括：
基本信息
評審主題、時間、提交者、評審者等
評審內(nèi)容
評審內(nèi)容的列表和簡述
問答記錄
評審過程中重要的問答記錄
評審結(jié)論
整個評審的結(jié)果，如： 完全通過，無需修改
基本通過，需要作小量修改，但不必再評審
大體通過，需要作一些修改，之后再評審
不通過，需要作大幅修改，之后必須重新評審
評審意見
針對評審結(jié)論提出的意見和建議
表 7-1 評審報告
2） 測試
測試是對被構(gòu)建產(chǎn)品最直接有效的質(zhì)量保證措施，測試結(jié)束后需要提交《測試報告》。
變更管理
開發(fā)過程中經(jīng)常會出現(xiàn)多種變更，如：需求變更、設(shè)計變更或人員變更等。這些變更通常會對開發(fā)進度造成影響，因此要對變更及其處理過程進行跟蹤，最后報告變更的處理結(jié)果。
《變更處理報告》的內(nèi)容包括：
基本信息
變更主題、發(fā)生時間等
詳細信息
變更的詳細描述
變更處理
變更的處理方式和步驟
處理結(jié)果
變更的處理結(jié)果
變更影響
變更對項目造成的影響
表 7-2 變更處理報告
進度監(jiān)控
項目進度會議是了解項目實際進度的有效措施，在會議中評審工作報告，解決遇到的問題并計劃下一步工作：
《工作報告》的內(nèi)容包括：
基本信息： 報告者、匯報時間、工作時間段等
工作情況： 已完成的工作、未完成的工作
遇到的問題：工作中碰到的阻礙
工作計劃： 下一步的工作計劃
項目進度會議的另一個重要議題是審查進度表，了解項目實際進度與計劃進度的差異。為進度表調(diào)整和資源調(diào)配提供重要依據(jù)。
測量
在項目開發(fā)過程中，收集一些關(guān)鍵的測量，對了解項目狀態(tài)和進行項目決策很有幫助，同時也為以后的項目提供歷史數(shù)據(jù)參考。每個測量都要生成測量報告并存檔。
《測量報告》的內(nèi)容包括：
基本信息，包括測量主題、測量時間、測量者等
測量內(nèi)容和測量值
測量分析
結(jié)束階段
圖 7-1 控制階段的任務(wù)和工件
產(chǎn)品測試
因為產(chǎn)品即將驗收和發(fā)布，所以必須對產(chǎn)品進行完整測試，產(chǎn)品測試比其他測試要求更嚴格，當(dāng)產(chǎn)品的質(zhì)量達到發(fā)布的要求后才能發(fā)布。產(chǎn)品的質(zhì)量由《測試報告》體現(xiàn)。
RC版本發(fā)布
發(fā)布RC版本讓用戶體驗并收集反饋意見，為產(chǎn)品驗收作準備。RC版本發(fā)布后，產(chǎn)品不應(yīng)該有大改動，一般只是界面的局部調(diào)整。
編制用戶文檔
針對不同的使用者角色，編制相應(yīng)的用戶文檔，對管理者用戶需要提供《安裝、維護指南》，對普通用戶需要編制《產(chǎn)品使用手冊》。
《安裝、維護指南》的內(nèi)容包括：
產(chǎn)品各組件的說明
產(chǎn)品部署架構(gòu)
安裝、配置和卸載等步驟
啟動、停止和重啟等操作
其它操作：日志、備份、還原等
《產(chǎn)品使用手冊》的內(nèi)容包括：
產(chǎn)品介紹
各個功能的介紹
通過實際案例介紹各個功能的使用方式和操作步驟
產(chǎn)品使用培訓(xùn)
對于為特定客戶開發(fā)的軟件產(chǎn)品，在發(fā)布前需要對用戶進行產(chǎn)品的使用培訓(xùn)。培訓(xùn)前需要部署好操作環(huán)境，編寫培訓(xùn)資料，然后組織培訓(xùn)會議。
產(chǎn)品驗收
對于為特定客戶開發(fā)的軟件產(chǎn)品，通常根據(jù)簽訂的開發(fā)合同和產(chǎn)品方案等條款逐項驗收，驗收時，用戶通常會執(zhí)行驗收測試案例。
最后修訂
在產(chǎn)品驗收通過后，正式發(fā)布前對產(chǎn)品作最后的修訂，可能包括：
開發(fā)文檔修訂
用戶文檔修訂
代碼整理
正式版發(fā)布
正式版的發(fā)布標志著開發(fā)階段的結(jié)束，產(chǎn)品從此時起進入維護階段，正式發(fā)布前可能要做一些準備工作，如：數(shù)據(jù)遷移和環(huán)境配置等。
項目總結(jié)
項目結(jié)束后需要對整個項目開發(fā)階段的工作進行總結(jié)，交流心得，吸取經(jīng)驗和教訓(xùn)，并歸檔為《項目總結(jié)報告》。
《項目總結(jié)報告》的內(nèi)容包括：
總體評價
成本、收益匯總
重要心得
管理總結(jié)
技術(shù)總結(jié)
總結(jié)
圖 8-1 項目階段
軟件項目開發(fā)經(jīng)歷多個階段，每個階段包含多個任務(wù)，每個任務(wù)會產(chǎn)生相應(yīng)的工件。需要相應(yīng)的質(zhì)量保證措施對任務(wù)進行監(jiān)控，保證任務(wù)的執(zhí)行。任務(wù)完成后也需要對任務(wù)進行評審，保證任務(wù)的質(zhì)量。
這些工作均由開發(fā)團隊和相關(guān)人員按照工作流程執(zhí)行。因此，合理的角色任務(wù)分配和溝通制度是軟件項目成功的重要保障。
圖 8-2 列出幾種比較普遍的角色和任務(wù)劃分方案：
圖 8-2 角色和任務(wù)劃分方案
職責(zé)和角色不清楚往往是造成軟件項目團隊管理混亂的一個重要原因，一個好的軟件團隊必須根據(jù)團隊規(guī)模的不同和項目本身的特點對項目成員的角色和崗位進行明確的劃分，這樣團隊中的每個成員才可能有清晰的責(zé)任和目標。
軟件開發(fā)不管采用哪種生命周期模型和開發(fā)方法論，整個過程都會包含需求，設(shè)計，開發(fā)，測試，配置管理等各項活動。而這些活動會對應(yīng)到項目中的不同角色，項目中進行崗位劃分后每個崗位成員可以兼職多個角色。形成相關(guān)的角色崗位矩陣。
方案一 項目負責(zé)人總覽全局
對于小作坊的軟件開發(fā)團隊，可以由一個項目負責(zé)人總覽全局。項目負責(zé)人承擔(dān)從用戶需求->軟件需求->總體設(shè)計的所有工作。同時還需要做到整個團隊進度規(guī)劃，質(zhì)量保證，配置管理和溝通協(xié)調(diào)等相關(guān)工作。所以小型項目團隊對項目負責(zé)人的業(yè)務(wù)，技術(shù)和溝通管理等技能都要求較高，項目負責(zé)人是項目中的總體方案確認者和架構(gòu)師。項目負責(zé)人能力和技能往往決定了整個軟件項目的成敗。
我們這里指的小型團隊并不是只一個人單打獨斗的項目，所以項目負責(zé)人最好不要介入到模塊設(shè)計和編碼活動中，而是應(yīng)該把重點放在進度的控制和質(zhì)量的保證上面。由于項目負責(zé)人一般有較強的技術(shù)能力，所以項目負責(zé)人可以承擔(dān)項目中要使用的一些新技術(shù)的研究，項目中一些疑難問題的解決等相關(guān)工作。項目負責(zé)人還應(yīng)該有計劃的設(shè)計開發(fā)人員的代碼進行Review，對發(fā)現(xiàn)的規(guī)范性，性能，復(fù)用差等問題跟項目成員確認，并寫入到項目開發(fā)規(guī)范中。
方案二 項目負責(zé)人和開發(fā)負責(zé)人分離
在這種方案下項目負責(zé)人和開發(fā)負責(zé)人在軟件需求和架構(gòu)上的工作是重疊的。這兩個崗位的人員共同來確認項目的總體方案和架構(gòu)。項目負責(zé)人的重點在項目管理和與客戶交流溝通上，只有確認清楚第一手的用戶需求，才能開發(fā)出用戶滿意度高的軟件。對于很多小型項目往往是用戶需求都沒有搞清楚就開工，項目成員完全憑借著自己的感覺在做系統(tǒng)，過程中又不注意與用戶及時反饋和迭代，導(dǎo)致開發(fā)出完全不能使用的系統(tǒng)；開發(fā)負責(zé)人的重點是對整個開發(fā)過程負責(zé)，包括對項目經(jīng)理確認的進度目標進行任務(wù)的進一步分解，安排后續(xù)的增量和迭代計劃。方案二的重點是第一次解放項目經(jīng)理，架構(gòu)的核心移動到了開發(fā)負責(zé)人，而項目經(jīng)理僅僅是參與討論和評審。而單獨剝離出開發(fā)負責(zé)人后，可以更好的對開發(fā)過程進行跟蹤和協(xié)調(diào)，開發(fā)負責(zé)人重點放在項目內(nèi)部，而避免過多去和外部干系人溝通和協(xié)調(diào)。
方案三 測試的專職化
對于項目團隊發(fā)展到5-10的時候，項目中的測試工作必須專職化的由測試人員來完成。一般測試人員的配置比例為4-6個開發(fā)人員需要配置一名專職化的測試人員。測試人員站在第三方和模擬使用者角度來進行系統(tǒng)的測試，可以更好的發(fā)現(xiàn)系統(tǒng)的BUG和相關(guān)問題，有效的保證系統(tǒng)的質(zhì)量。
方案三中項目經(jīng)理工作進一步清晰，項目經(jīng)理不在承擔(dān)軟件需求和架構(gòu)的相關(guān)工作。而重點放在項目內(nèi)外的溝通協(xié)調(diào)和整個項目進度計劃的安排上。這個時候項目中的設(shè)計負責(zé)人對整個系統(tǒng)的總體設(shè)計方案和架構(gòu)負責(zé)，而且設(shè)計負責(zé)人也將不在參與具體的功能模塊的設(shè)計和開發(fā)工作。設(shè)計負責(zé)人的重點轉(zhuǎn)化到的軟件需求的開發(fā)和總體設(shè)計上面(如涉及到RUP中的用例建模，用例分析，架構(gòu)設(shè)計，組件接口復(fù)用)。
方案四 項目經(jīng)理和需求角色分離
當(dāng)項目團隊的規(guī)模發(fā)展到12-20人的時候，項目團隊基本上可以算做中小型的項目團隊。這個時候項目經(jīng)理完全專職化做項目管理的工作。包括項目進度計劃制定，項目跟蹤監(jiān)控，風(fēng)險分析和控制，項目度量分析和決策等相關(guān)內(nèi)容。對于需求活動設(shè)置專門的需求工程師崗位來完成需求的開發(fā)。同時項目中設(shè)置專門的架構(gòu)設(shè)計人員，架構(gòu)設(shè)計人員不再負責(zé)需求的開發(fā)工作，而重點在于系統(tǒng)總體設(shè)計方案的確定，系統(tǒng)的4+1視圖的分析，同時架構(gòu)人員要考慮整個系統(tǒng)的集成方案的確定和具體功能單元和模塊的集成。
由于項目規(guī)模的擴大，項目的配置項更加復(fù)雜，項目也需要同時起開發(fā)，測試，集成和BugFix等多個分支。因此需要設(shè)置專門的配置管理員來進行項目的配置管理。
對于項目同時需要開發(fā)新版本，又需要對已經(jīng)發(fā)布的維護版本進行功能改進的時候，項目中要考慮設(shè)置專門的維護人員。由維護人員來完成項目小功能的改進和BUG的修復(fù)。這樣新版本設(shè)計開發(fā)人員可以更專注的進行新功能的開發(fā)。
