軟件開發(fā)項目規(guī)范

1、精品軟件項目開發(fā)和管理規(guī)范本文闡述軟件項目開發(fā)和管理的流程規(guī)范，作為軟件項目開發(fā)的高級指引，本規(guī)范定義 了軟件開發(fā)的各個階段以及每個階段的工作活動和工件，但不對活動和工件的細節(jié)作過多規(guī) 定。在項目開發(fā)過程中，每個項目根據(jù)自身的需要確定這些活動和工件的細節(jié)。項目階段項目開發(fā)的五個階段圖2-1項目開發(fā)的五個階段? 啟動階段這個階段的工作目的是決定一個項目是否需要啟動。為了達到這個目的，首先要明確項 目的總體戰(zhàn)略目標，對項目的需要建立認同。即確定到底需要做什么、開發(fā)什么產(chǎn)品或提供 什么服務，以及需要解決什么樣的問題和需要滿足客戶或市場的什么要求等，同時還要總結(jié) 項目工作的范圍、所需資源、大約開支、各

2、種風險，以及該項目不執(zhí)行的其他替代選擇等。 這些代表了對整個項目目標從戰(zhàn)略角度和宏觀層次所進行的分析，通過項目的意向書總結(jié)出 來，由此確證客戶或項目發(fā)起人和贊助者的要求與期望，并幫助他們判定項目是否上馬。項 目意向總結(jié)書的通過及項目被批準上馬形成了這個項目的起始點。? 計劃階段這個階段的工作是為整個項目做計劃。項目開始后，首先要確定項目的具體范圍，明確 定出項目到底要做什么，總結(jié)、歸納并定出產(chǎn)品的功能。然后進一步制定項目的計劃，列出 每項具體工作，并建立所有工作任務的重要性及順序；確定每項工作的執(zhí)行人和所需資源； 根據(jù)人員的配置和能力設定各項工作和整個項目的完成時間表。? 執(zhí)行階段這個階段的工

3、作是通過執(zhí)行項目的計劃來完成項目的任務。它包括落實一切所需資源， 如：人員、設備、費用、技術、信息，由管理者領導全體項目參與者開展各項工作。同時跟 蹤各項具體工作和整個項目的進度，定期向全體項目人員及項目的發(fā)起人報告項目狀態(tài)。? 控制階段這個階段的工作是確證項目工作的結(jié)果符合項目的計劃。它通過對項目結(jié)果的衡量和審 核，與項目計劃所期望的結(jié)果進行比較，找出實際結(jié)果與計劃的差別，并制定處理措施。這 個階段的工作還包括對項目進程中出現(xiàn)的任何更改要求進行審核和批準。同時調(diào)解項目進程 中出現(xiàn)的各種問題，如：對缺乏的資源的補償調(diào)節(jié)；對項目的進度表及各項具體工作的優(yōu)先 級或順序的修訂。? 結(jié)束階段這個階段的

4、工作是確保項目的最終結(jié)果或提交物達到計劃的要求，并對完成的結(jié)果作可 接受的確認。還包括在項目完成之后的收尾工作，對整個項目的經(jīng)歷進行總結(jié)，修訂項目文 檔，用戶培訓等。階段完成標志在項目開發(fā)過程中，當一個階段完成后才會開展下一個階段的工作；另外，“某個階段 完成”通常被定義為項目的一個里程碑，里程碑標識了項目的進度，它是項目開發(fā)和控制的 重要參考，對整個項目有重要的意義。因此，“確證某個階段是否已經(jīng)完成”的工作非常有 重要。? 每一個階段的結(jié)束以它特定任務的完成為象征只有當某個階段中被規(guī)定的所有工作任務都完成了，這個階段才算真正結(jié)束，整個項目 才可以進入到下一個階段中去。反過來說，要是階段中某個

5、任務沒有全部完成，按照項目的 定義，整個階段就不能算是完成，因此項目就不能進入到下一個階段去。? 衡量階段結(jié)束的工作結(jié)果必須是實在的交付品階段中的任務是否完成是透過任務活動中產(chǎn)生的交付品來體現(xiàn)的，交付品必須是可交付 的、非抽象的、實質(zhì)的并且可以通過用衡量的方法來判斷是否真正地完成了的具體事物。 如：某一階段的完成是以建造一個樣品或完成某分文件作為象征。任何項目階段的結(jié)束，都 應該有這樣的實質(zhì)性東西的完成作為象征。? 跨階段的進程以階段結(jié)尾的合格驗證和審核來決定當一個階段結(jié)束時，在進入到下一個階段之前所需要做的工作應包括對交付品進行合格 驗證，并檢查這一階段的工作質(zhì)量和效率，由此判斷是否可以進入

6、到下一個階段。這些檢驗 象征了一個階段的結(jié)尾終點，表示項目的進程離開了上一個階段而進入了下一個階段。啟動階段啟動階段圖3-1啟動階段的任務和工件?產(chǎn)品領域研究研究產(chǎn)品所在領域的狀況，為項目論證提供依據(jù)。研究內(nèi)容包括:0產(chǎn)品領域的現(xiàn)狀和前景0產(chǎn)品領域的商業(yè)模式和業(yè)務流程0產(chǎn)品的價值和盈利空間0產(chǎn)品的特性和復雜度?技術可行性研究welcome研究產(chǎn)品的實現(xiàn)技術，總結(jié)技術可行性。研究內(nèi)容包括:oo 類似產(chǎn)品的當前實現(xiàn)技術和技術趨勢o 實現(xiàn)技術的候選方案o 各個方案的優(yōu)點、成本和風險o 開發(fā)團隊與實現(xiàn)技術的匹配情況?項目論證基于商業(yè)和技術等方面對項目的可行性進行論證，確定項目是否開展。如果開展項目,

7、則進一步論證項目的總體方案。論證的內(nèi)容包括：o 商業(yè)可行性o 技術可行性o 當前產(chǎn)品與類似產(chǎn)品的比較o 項目收益和前景o 項目的成本和風險o 項目的總體方案?確定項目目標和范圍項目開始時，所有相關人員必須對項目的目標和范圍達成共識，形成共同的項目愿景并把愿景敘述為項目開發(fā)大綱向相關人員傳達。項目開發(fā)大綱的內(nèi)容包括:用三到五張圖表來描述產(chǎn)品目標、功能、平臺、客戶、進度表和開發(fā)職責能的功能用一個段落來綜述產(chǎn)品，再用一個段落來描述每個重要的功能 用一個段落來描述每個對產(chǎn)品有用的但本項目不實現(xiàn)的功能 用一個段落來明確每個重要的涉眾群體和他們的風險股本用一個段落來講述每個重要的項目需求按風險暴露量對每個

8、重要的項目風險都用一個段落來討論項目回報一用一個段落綜述產(chǎn)品的回報，其后再對每個重要的項目回報都用一個段落來討論結(jié)論用一到三個段落將上述所有部分聯(lián)系起來，明確項目的需求和風險，再用論點和論據(jù)來總結(jié)為什么這個項目會成功表3-1項目開發(fā)大綱計劃階段計劃階段圖4-1計劃階段的任務和工件?規(guī)模、工作量評估圍繞各項計劃的制定工作對項目的規(guī)模、工作量等進行評估，評估的內(nèi)容包括:00 模塊數(shù)量與復雜度0 輸入、輸出和對外接口等數(shù)量與復雜度0 SLOC和功能點0 非生產(chǎn)性的支持工作量0 開發(fā)工作量（人月）0 進度與里程碑0 進度風險?定制項目開發(fā)計劃項目開發(fā)計劃體現(xiàn)了項目組對整個開發(fā)周期的預期，指定了項目開發(fā)

9、的總體方針。與其 他計劃一樣，項目開發(fā)計劃不是固定不變的，在執(zhí)行過程中要對計劃進行監(jiān)控，可能會根據(jù) 實際情況修改計劃并重新發(fā)布。項目開發(fā)計劃的內(nèi)容包括:用三到五張圖表來描述產(chǎn)品目標、功能、平臺、客戶、進度表和開發(fā)職責（項目開發(fā)計劃的概述部分應該是項目開發(fā)大綱中概述部分的拷貝。當項目變時，修訂項目開發(fā)計劃的概述部分而不是修訂項目開發(fā)大綱。這樣，以后在進 評價時，通過比較 項目開發(fā)大綱和項目開發(fā)計劃的概述，就能看出項目是如何改能用一到五頁的篇幅來概述產(chǎn)品的功能，其中，要包括這些功能的附加信息 者需要這樣的信息來了解實現(xiàn)需求）。員確定軟件工程職能角色，以及分配到這些角色的人員數(shù)量。程概述這個項目中所

10、應用的軟件過程。（具體內(nèi)容可在« 質(zhì)量保證計劃中定義）程方法概述這個項目中所應用的軟件工程方法和技術。（具體內(nèi)容可在« 質(zhì)量保證計劃中定義）工作量這FS分要表達出整個項目進度和工作量的估計。其中要包括：?對固定不義的里程碑和同步點的解釋?在評估中的設想情況、評估中的不準確性的可能來源?隨著項目的進展如何更新評估（具體進度表內(nèi)容可在« 開發(fā)進度表中定義）理計劃概述這個項目中風險管理計劃。（具體內(nèi)容可在«風險管理計劃中定義）概述這個項目中要收集的測量。具列出要使用的每一項軟件工具，以及該工具所支持的任務。持硬件支持 明確所需的硬件，包括那些需要移動、獲取或升

11、級的硬件。軟件支持 明確所需的軟件，包括需要獲取、安裝或升級的軟件件。人力支持由哪個人、部門或團隊為開發(fā)組的哪項任務提供支持。表4-1項目開發(fā)計劃?定制風險管理計劃風險管理任務包括：風險識別、風險分析、確定風險優(yōu)先級、定制風險化解方案、風險化解和風險監(jiān)才S如：圖 4-2】地二嘯也如名鍛議價折W_XKrttt風險管理繞濘科以陶¥電;區(qū)塾降屆"同0詞而總是通"版肥或峰型化再溫 根腰方正細也*!比分田4費甲ft*罪圖4-2風險管理任務風險管理計劃定義這些任務的執(zhí)行流程和人員分配。風險管理計劃的內(nèi)容包括:概述用文字和圖表概述風險管理任務的總體執(zhí)行流程。風險識別詳細說明“風

12、險識別”任務的實施細節(jié)和各項工作的負責人。風險分析詳細說明“風險分析”任務的實施細節(jié)和各項工作的負責人。確定風險優(yōu)先級詳細說明“確定風險優(yōu)先級”任務的實施細節(jié)和各項工作的負責人。定制風險化解方案詳細說明“定制風險處理方案”任務的實施細節(jié)和各項工作的負責人。風險化解當風險發(fā)生時，需要采取相應的措施化解風險。這部分的內(nèi)容是描述風險化解工作的操作規(guī)范和流程。風險監(jiān)控詳細說明風險監(jiān)控任務的實施細節(jié)和各項工作的負責人。表4-2風險管理計劃風險管理中通常會用到Top N 風險列表，風險列表按照風險暴露量排序列出當前項目中主要的 N個風險，Top N 風險列表的內(nèi)容包括:本周的排名（如果本周已被完全化解用“

13、-”表示） 上周排名（如果是新識別的風險用“-”表示） 該風險已上表的周數(shù):風險的名稱或簡述風險類型（只針對進度相關的風險）：o計劃編制o組織和管理0設計和實現(xiàn) o客戶和需求o 承包商o產(chǎn)品o 人員o 過程o技術o 外部環(huán)境o開發(fā)環(huán)境率度案度風險發(fā)生的百分比概率風險發(fā)生時損失的進度（工作日或工作周）一發(fā)生概率X損失程度風險的當前狀態(tài)：未發(fā)生、已發(fā)生、已化解簡述風險的化解方案，如果有具體的化解方案文檔則鏈接到相應文檔 對已發(fā)生的風險，簡述化解進度（未發(fā)生的風險用“-”表示）表4-3風險列表?定制質(zhì)量保證計劃保證工作質(zhì)量的一個重要步驟是制定一套合理的質(zhì)量保證計劃并貫徹執(zhí)行。質(zhì)量保證計劃的內(nèi)容包括：

14、說明編寫的目的、適用范圍以及對相關人員的要求等程詳細說明這個項目中所應用的軟件過程。程方法詳細說明這個項目中所應用的軟件工程方法和技術。對工程方法中的各種工作任務進行規(guī)范，明確執(zhí)行的時機、流程和準則 這些工作任務包括：常規(guī)開發(fā)活動 （需求分析、架構設計、詳細設計、編碼和測試、發(fā)布和實施等十會議（工作例會、進度會議、審查會議等）氾評審（方案評審、技術評審、質(zhì)量評審等）測量（產(chǎn)品規(guī)模測量、進度測量、缺陷率測量、測試覆蓋率測量等）其他活動（技能培訓、資料收集、內(nèi)部流、客戶溝通等）表4-4工作規(guī)范?定制開發(fā)進度計劃基于當前對項目的規(guī)模和工作量評估，定制初步的開發(fā)進度表，作為項目開發(fā)計劃的組成部分。開發(fā)

15、進度表的內(nèi)容包括：oo 項目的開始和結(jié)束時間o 項目各個階段的開始和結(jié)束時間o 每個階段的工作任務及其開始和結(jié)束時間o 每個工作任務的子任務的及其開始和結(jié)束時間o 里程碑和同步點o 角色的定義和任務分配作為跟蹤項目進度的重要依據(jù)，進度表在項目推進過程中需要不斷細化。另外，當實際 進度與計劃進度出現(xiàn)偏差時，需要修改進度表并重新發(fā)布。執(zhí)行階段圖5-1執(zhí)行階段的任務和工件?需求分析分析產(chǎn)品的關鍵需求、對架構設計有影響的需求和風險較高的需求，直到分析的程度能 開展足界面原型設計和架構設計工作。需求規(guī)格說明書的內(nèi)容包括:業(yè)務需需求求求從商業(yè)或業(yè)務角度宏觀上對產(chǎn)品或系統(tǒng)的要求。它主要在宏觀的層面歸納總 足

16、客戶提出的要求或贏得市場競爭所必須實現(xiàn)的功能、性能、質(zhì)量等要求。1 .做什么2 .做的范圍3 .對結(jié)果的要求從客戶對軟件產(chǎn)品或系統(tǒng)使用方案的角度出發(fā)，描述和總結(jié)使用者利用該軟 或系統(tǒng)能夠做的事或能夠完成的任務。根據(jù)上述使用者需求列出的使用方案，列出開發(fā)者必須為軟件產(chǎn)品或系統(tǒng)實1 .運行速度、容量、并發(fā)性能2 .對資源的利用率3 .對外界輸入的反饋速度和準確性4 .對差錯的負荷能力o必須適應的運行環(huán)境的要求（包括運行平臺、網(wǎng)絡及其他硬件要求）o與其他系統(tǒng)兼容的要求（包括與操作系統(tǒng)、數(shù)據(jù)庫、瀏覽器及其他應求件的兼容要求）o與外部其他系統(tǒng)和組件的接口要求o對用戶重要的質(zhì)量標志 （可靠性、效率性、靈活

17、性、安全性、互操作 穩(wěn)定性、健全性、可用性）o對開發(fā)者重要的質(zhì)量標志 （可維護性、多用轉(zhuǎn)換性、重復使用性、可 性）不屬于上述需求范圍的，但受到其他環(huán)境和商業(yè)合同影響的要求。1.國家或地區(qū)的任何特別的標準2.軟件使用界面的特別要求3.與知識產(chǎn)權有關的要求4.軟件所面對的市場和行業(yè)的規(guī)范5.客戶的特別要求對開發(fā)的成功與否起很大影響的因素，是開發(fā)能力的局限:開發(fā)的局限1 .人員的局限2 .技術的制約和局限3 .客戶的特別要求表5-1需求分析告需求分析報告的編制方式可以是多樣的,例如把所有“非功能性需求”組織成“外部接口需求”、“質(zhì)量屬性需求”和“需求約束”【如：圖一一刑4需求概述Hjft制與假設目的

18、H前言縮巧詞.略語用例摘述軟件需求規(guī)格說明村外部摳口需求用戶接口5凝T軟件按Id具體需求 質(zhì)屎屬性蠱求桂格易用性T發(fā)的口血護性必須遒守的標準用住的收制圖5-2需求規(guī)格說明書?界面原型設計明確了系統(tǒng)的關鍵需求后，就可以進行界面原型設計工作，獲取用戶的反饋，盡快確定 產(chǎn)品的界面基調(diào)。同時要編寫一份界面設計概要文檔，作為后續(xù)的界面設計工作的指 導。界面設計概要的內(nèi)容包括：o 設計的理念0 理念的來源或參考0 設計的要點0 與類似產(chǎn)品界面的對比?架構設計架構設計從關鍵需求開始，建立概念性的架構，并逐步細化和驗證。最終生成架構設計 說明書和架構基線代碼。架構設計的方法：可以從幾個不同的視角進行架構設計，

19、然后匯總綜合得出完整的設 計。（架構設計的五個視圖【如：圖 5-3】）精品表5-2架構設計說明書welcome系比底或戶 編附玄捽的服務一丈注點是行為成覘責的電）辦關注羯戶碑見的功懶 I提供輔勤功能耀* 它們可能址上輯層*功悵以或前奏U J卜發(fā)姒百）1運行顰鞫卜 »I .11 -I UE時架構設計的石視圖行電號晦開發(fā) 雨威*理性關注蓋軟件模塊 .m工可擴展if4.更E色則移帖性里也包導蛔處源郡岸文件|型置文件源耨庠包詞-n史【第文-一 建糧層會映眥到程序自耳揖有之運行剛 過建同性也能 不溫件安金煌 美注點她墓的笄發(fā)。而而他 關法邊理，境程，對斡厚崖行時搬離 考電探藏，同小，埴信等問堀

20、 慎重林序包住斯越時刷的價本依賴其索就血上“用如：一些£，1比:K：注讓八七1交次皮部»工物座機器部野機器知網(wǎng)熱配冷軾件系統(tǒng)和 w養(yǎng)性.川伸縮性等匕術市覘n標用序的靜態(tài)何解倒地芯慮整個軟背票*之間優(yōu)如何h柑黑響的ai54iiasa®i_關注京晶軟件的耳標季元如何眠時到硬件總注相入的.研累洞性若重號1晅數(shù)題志求可帝性現(xiàn)抻螂牲掙糕可川性，性能紅”升久化也用的何誦n效據(jù)存獨格式霞型傳逅 數(shù)四復制 薪忖力飛同號肝火心處春.；圖5-3架構設計的五視圖架構設計說明書的內(nèi)容包括:說明編寫的目的、適用范圍以及設計原則等。 關注功能。其設計著重考慮功能需求。1 .細化功能單元2 .

21、發(fā)現(xiàn)通用機制3 .細化領域模型4 .確定子系統(tǒng)接口和交互機制關注程序包。其設計著重考慮開發(fā)期質(zhì)量屬性，如可擴展性、可重用性、可移 易理解性和易測試性等。1 .確定要開發(fā)或直接利用的程序包之間的依賴關系2 .確定采用的技術、框架等關注持久化數(shù)據(jù)的存儲方案。其設計著重考慮“數(shù)據(jù)需求”1 .持久化數(shù)據(jù)存儲方案2 .數(shù)據(jù)傳遞、數(shù)據(jù)復制、數(shù)據(jù)同步等策略關注進程、線程、對象等運行時概念，以及相關的并發(fā)、同步、通信等問題。 著重考慮運行期質(zhì)量屬性，例如性能、可伸縮性、持續(xù)可用性和安全性等。1 .確定引入哪些進程與線程2 .確定主動對象、被動對象，以及控制關系3 .處理進程線程的創(chuàng)建、銷毀、通信機制、資源爭用

22、等4 .協(xié)議設計關注軟件系統(tǒng)最終如何安裝或部署到物理機器。具設計著重考慮“安裝和部署 求。1 .確定物理配置方案2 .確定如何將目標程序映射到物理節(jié)點基于上述的設計進行總結(jié)，并描述架構基線。架構設計的另一個重要任務是編寫架構基線代碼，基線代碼表述和驗證架構，同時也是 指導后續(xù)開發(fā)的基礎代碼。架構基線代碼的內(nèi)容包括:所有工程項目工程目錄結(jié)構軟件包結(jié)構導入所有依賴包 基礎公共代碼 架構框架代碼架構框架示例代碼和測試代碼 數(shù)據(jù)庫框架5-4和圖5-5展示了軟件架構師的工作和成功的軟件架構設計包含的內(nèi)容:劃分哪些模域軟件系統(tǒng)的分齷將個模塊的職責為何 E個模塊舟橫口加軻定義 模烘間果用何種交互機制 如何滿

23、足溝束和所醇屬性的宗 如何J5和閨俄發(fā)生的變化劃分不同的子看統(tǒng)圖5-4軟件架構師的工作精品好個相戰(zhàn)職貴明州良好的模塊也卜會植映之同槍轉(zhuǎn)行你舞川樸美校1夬¥校3用模域的分營外火化數(shù)摳打儲方案welcomeI瓦亞令選盤由t.Jl交制羽暗默據(jù)同步潴腦'些咖.速至I1碉雌嫩8,明福，靈話的部X跳劃| 城矮小.旌黑珞什黑fmm圖5-5成功的軟件架構設計Build 構1軟件構建軟件可以分階段進行構建，每個階段可以使用增量的方式開發(fā)，用通過若干個 建，最后發(fā)布階段性產(chǎn)品成果。（注意：在這里，名詞“階段”的含義和本文其他地方的含義不一樣）階段計劃構建階段計劃的內(nèi)容包括：o確定本階段要實現(xiàn)的功

24、能o列出階段任務o計劃Build構建數(shù)量o 細化開發(fā)進度表中本階段的工作內(nèi)容? Build 構建詳見：下一節(jié)?階段產(chǎn)品發(fā)布構建階段完成后發(fā)布階段產(chǎn)品成果，向用戶展示并接受用戶反饋，同時做好階段總結(jié)。發(fā)布清單的內(nèi)容包括：o 產(chǎn)品版本號和日期o 改正的Bug0 修改的功能0 實現(xiàn)的新功能0 其他說明階段總結(jié)報告的內(nèi)容包括：0 階段任務的完成情況0 進度計劃的執(zhí)行情況0 用戶的反饋情況0 本階段碰到的主要問題0 下一階段的改進建議2 Build 構建Build構建以增量的方式執(zhí)行階段的開發(fā)任務，每個 Build構建的周期一般不超過兩星 期，每一次Build構建都會發(fā)布為一個內(nèi)部版本，并提交測試。測試

25、發(fā)現(xiàn)的問題留待以后的 Build構建解決。? Build計劃Build計劃的內(nèi)容包括：o本次Build的版本號o本次Build的歷時o本次Build的工作任務? 要解決的遺留Bug? 本應由以前的Build實現(xiàn)的，但推遲到本次 Build實現(xiàn)的功能?要實現(xiàn)的新功能?其他工作任務o工作任務分配?需求細化根據(jù)Build計劃，細化本次Build要實現(xiàn)的需求，細化到能進行詳細設計為止。有了細化的需求后就編寫本次Build的測試計劃。測試計劃的內(nèi)容包括：o 功能測試? 要測試的功能? 測試時間? 測試方式? 驗收標準o 其他測試（性能測試、邊界測試、使用界面測試、可用性測試、安全性測試等）? 要測試的內(nèi)

26、容? 測試時間? 測試方式? 驗收標準o 00000 G?界面設計根據(jù)細化的需求設計用戶界面，當界面確定后即可編寫測試用例。測試用例的內(nèi)容包括：o 測試用例對應的功能模塊o 測試用例的性質(zhì)（功能測試用例、性能測試用例、。）o 輸入（或操作步驟）o 期望輸出o 實際輸出（執(zhí)行測試后再填寫）o 是否通過（執(zhí)行測試后再填寫）? 詳細設計詳細實際每項需求的實現(xiàn)方法，對于重要的設計決策、算法、公共模塊和外部接口等必須以模塊設計文檔的形式進行記錄。模塊設計文檔的內(nèi)容包括：o 模塊名稱o 設計思想o 設計圖表（類圖、流程圖等）o 要點描述（包、接口、類、方法、算法、設計模式）o 測試方式?編碼、單元測試編碼

27、和單元測試是開發(fā)人員的工作，對于重要的代碼都必須進行單元測試，編寫代碼必須遵守下列準則：o 遵守編碼規(guī)范o 編碼前必須充分理解相關的需求o 編碼前先進行設計，把流程理順o 注意設計方法和設計模式的靈活運用o 總體考慮問題，使代碼遵從架構并容易測試o 設計時要充分考慮異常情況和臨界條件o 嚴禁Copy-Paste ,注意提取公共代碼，在編碼過程中實現(xiàn)重構o 異常處理必須記錄日志，嚴禁草率地直接打印異常信息o 靈活運用ASSERT（） / VERIFY（） 等斷言來幫助調(diào)試程序o 單元測試是程序員的工作，所以編碼完成后必須對代碼嚴格測試o 功能代碼完成后必須先做以下 4件事情：? 編譯代碼，保證編

28、譯通過?（不運行程序）對代碼進行全面檢查? 用調(diào)試模式啟動程序，一行一行單步執(zhí)行代碼，并注意調(diào)試輸出? 改變條件，讓代碼盡可能走遍所有程序分支o Check In代碼前必須保證能編譯通過? 創(chuàng)建Build代碼集成發(fā)布前需凍結(jié)代碼，所有人把要提交的代碼Check In ,并保證編譯后的程序能在測試服務器上正常啟動，界面能正常打開。同時還要提交 Build清單。Build清單的內(nèi)容包括：o Build版本號和日期o 改正的Bugo 修改的功能o 實現(xiàn)的新功能o 其他說明?集成測試按照測試計劃針對Build清單執(zhí)行測試用例，測試完成后編寫測試報告。測試報告的內(nèi)容包括：o 測試用例匯總（用例數(shù)量、通過

29、的用例數(shù)量、未通過的用例數(shù)量等）o Bug匯總（Bug總數(shù)、新增Bug數(shù)量、關閉Bug數(shù)量、Bug趨勢圖表等）o 測試計劃執(zhí)行情況o 測試總結(jié)控制階段圖6-1控制階段的任務和工件? 風險管理開發(fā)期間要對風險進行監(jiān)控，定期檢查、更新和發(fā)布風險列表。? 質(zhì)量管理1 ) 評審評審是質(zhì)量保證的重要環(huán)節(jié)，原則上每個重要的工作任務或階段結(jié)束前都必須經(jīng)過評 審，如：方案評審、計劃評審、需求評審、設計評審和代碼評審等，工作是否被通過、是否 需要修改或重做均由評審結(jié)果決定，評審結(jié)果以評審報告的形式發(fā)布。評審報告的內(nèi)容包括：評審主題、時間、提交者、評審者等評審內(nèi)容評審內(nèi)容的列表和簡述問答記錄評審過程中重要的問答記

30、錄評審結(jié)論整個評審的結(jié)果，如：1 .完全通過，無需修改2 .基本通過，需要作小量修改，但/、必再評審3 .大體通過，需要作一些修改，之后再評審4 .不通過，需要作大幅修改，之后必須重新評審評審意見針對評審結(jié)論提出的意見和建議表7-1評審報告2）測試測試是對被構建產(chǎn)品最直接有效的質(zhì)量保證措施，測試結(jié)束后需要提交測試報告。? 變更管理開發(fā)過程中經(jīng)常會出現(xiàn)多種變更，如：需求變更、設計變更或人員變更等。這些變更通 常會對開發(fā)進度造成影響，因此要對變更及其處理過程進行跟蹤，最后報告變更的處理結(jié) 果。變更處理報告的內(nèi)容包括：息變更主題、發(fā)生時間等息變更的詳細描述理變更的處理方式和步驟果變更的處理結(jié)果響變更

31、對項目造成的影響表7-2變更處理報告? 進度監(jiān)控項目進度會議是了解項目實際進度的有效措施，在會議中評審工作報告，解決遇到的問 題并計劃下一步工作：工作報告的內(nèi)容包括：1.1 .基本信息： 報告者、匯報時間、工作時間段等2 .工作情況：已完成的工作、未完成的工作3 .遇到的問題：工作中碰到的阻礙4 .工作計劃：下一步的工作計劃項目進度會議的另一個重要議題是審查進度表，了解項目實際進度與計劃進度的差異。 為進度表調(diào)整和資源調(diào)配提供重要依據(jù)。? 測量在項目開發(fā)過程中，收集一些關鍵的測量，對了解項目狀態(tài)和進行項目決策很有幫助， 同時也為以后的項目提供歷史數(shù)據(jù)參考。每個測量都要生成測量報告并存檔。測量報

32、告的內(nèi)容包括：1 .基本信息，包括測量主題、測量時間、測量者等2 .測量內(nèi)容和測量值3 .測量分析結(jié)束階段圖7-1控制階段的任務和工件? 產(chǎn)品測試因為產(chǎn)品即將驗收和發(fā)布，所以必須對產(chǎn)品進行完整測試，產(chǎn)品測試比其他測試要求更嚴格，當產(chǎn)品的質(zhì)量達到發(fā)布的要求后才能發(fā)布。產(chǎn)品的質(zhì)量由測試報告體現(xiàn)RC版本發(fā)布發(fā)布RC版本讓用戶體驗并收集反饋意見，為產(chǎn)品驗收作準備。RC版本發(fā)布后，產(chǎn)品不應該有大改動，一般只是界面的局部調(diào)整。? 編制用戶文檔針對不同的使用者角色，編制相應的用戶文檔，對管理者用戶需要提供安裝、維護指 南，對普通用戶需要編制產(chǎn)品使用手冊。安裝、維護指南的內(nèi)容包括：1.1 .產(chǎn)品各組件的說明2

33、 .產(chǎn)品部署架構3 .安裝、配置和卸載等步驟4 .啟動、停止和重啟等操作5 .其它操作：日志、備份、還原等產(chǎn)品使用手冊的內(nèi)容包括：1 .產(chǎn)品介紹2 .各個功能的介紹3 .通過實際案例介紹各個功能的使用方式和操作步驟? 產(chǎn)品使用培訓對于為特定客戶開發(fā)的軟件產(chǎn)品，在發(fā)布前需要對用戶進行產(chǎn)品的使用培訓。培訓前需 要部署好操作環(huán)境，編寫培訓資料，然后組織培訓會議。? 產(chǎn)品驗收對于為特定客戶開發(fā)的軟件產(chǎn)品，通常根據(jù)簽訂的開發(fā)合同和產(chǎn)品方案等條款逐項驗 收，驗收時，用戶通常會執(zhí)行驗收測試案例。? 最后修訂在產(chǎn)品驗收通過后，正式發(fā)布前對產(chǎn)品作最后的修訂，可能包括：1.1 .開發(fā)文檔修訂2 .用戶文檔修訂3

34、. 代碼整理? 正式版發(fā)布正式版的發(fā)布標志著開發(fā)階段的結(jié)束，產(chǎn)品從此時起進入維護階段，正式發(fā)布前可能要 做一些準備工作，如：數(shù)據(jù)遷移和環(huán)境配置等。? 項目總結(jié)項目結(jié)束后需要對整個項目開發(fā)階段的工作進行總結(jié)，交流心得，吸取經(jīng)驗和教訓，并 歸檔為項目總結(jié)報告。項目總結(jié)報告的內(nèi)容包括:1.1 .總體評價2 .成本、收益匯總3 . 重要心得4 .管理總結(jié)5 .技術總結(jié)總結(jié)圖8-1項目階段軟件項目開發(fā)經(jīng)歷多個階段，每個階段包含多個任務，每個任務會產(chǎn)生相應的工件。需 要相應的質(zhì)量保證措施對任務進行監(jiān)控，保證任務的執(zhí)行。任務完成后也需要對任務進行評 審，保證任務的質(zhì)量。這些工作均由開發(fā)團隊和相關人員按照工作

35、流程執(zhí)行。因此，合理的角色任務分配和溝 通制度是軟件項目成功的重要保障。圖8-2列出幾種比較普遍的角色和任務劃分方案:圖8-2角色和任務劃分方案職責和角色不清楚往往是造成軟件項目團隊管理混亂的一個重要原因，一個好的軟件團 隊必須根據(jù)團隊規(guī)模的不同和項目本身的特點對項目成員的角色和崗位進行明確的劃分，這 樣團隊中的每個成員才可能有清晰的責任和目標。軟件開發(fā)不管采用哪種生命周期模型和開發(fā)方法論，整個過程都會包含需求，設計，開 發(fā)，測試，配置管理等各項活動。而這些活動會對應到項目中的不同角色，項目中進行崗位 劃分后每個崗位成員可以兼職多個角色。形成相關的角色崗位矩陣。方案一 項目負責人總覽全局對于小

36、作坊的軟件開發(fā)團隊，可以由一個項目負責人總覽全局。項目負責人承擔從用戶 需求-> 軟件需求?？傮w設計的所有工作。同時還需要做到整個團隊進度規(guī)劃，質(zhì)量保證，配 置管理和溝通協(xié)調(diào)等相關工作。所以小型項目團隊對項目負責人的業(yè)務，技術和溝通管理等 技能都要求較高，項目負責人是項目中的總體方案確認者和架構師。項目負責人能力和技能 往往決定了整個軟件項目的成敗。我們這里指的小型團隊并不是只一個人單打獨斗的項目，所以項目負責人最好不要介入 到模塊設計和編碼活動中，而是應該把重點放在進度的控制和質(zhì)量的保證上面。由于項目負 責人一般有較強的技術能力，所以項目負責人可以承擔項目中要使用的一些新技術的研究， 項目中一些疑難問題的解