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

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

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

3、階段的工作是通過執(zhí)行項目的計劃來完成項目的任務(wù)。它包括落實一切所需資源，如：人員、設(shè)備、費用、技術(shù)、信息，由管理者領(lǐng)導全體項目參與者開展各項工作。同時跟蹤各項具體工作和整個項目的進度，定期向全體項目人員及項目的發(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é)束以它特定任務(wù)的完成為象征 只有當某個階段中被規(guī)定的所有工作任務(wù)都完成了，這個階段才算真正結(jié)束，整個項目才可以進入到下一個階段中去。反過來說，要是階段中某個任務(wù)沒

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

6、。這些檢驗象征了一個階段的結(jié)尾終點，表示項目的進程離開了上一個階段而進入了下一個階段。 啟動階段 圖3-1 啟動階段的任務(wù)和工件 ?產(chǎn)品領(lǐng)域研究 研究產(chǎn)品所在領(lǐng)域的狀況，為項目論證提供依據(jù)。研究內(nèi)容包括： ? o產(chǎn)品領(lǐng)域的現(xiàn)狀和前景 o產(chǎn)品領(lǐng)域的商業(yè)模式和業(yè)務(wù)流程 o產(chǎn)品的價值和盈利空間 o產(chǎn)品的特性和復雜度 ?技術(shù)可行性研究 研究產(chǎn)品的實現(xiàn)技術(shù)，總結(jié)技術(shù)可行性。研究內(nèi)容包括： o o類似產(chǎn)品的當前實現(xiàn)技術(shù)和技術(shù)趨勢 o實現(xiàn)技術(shù)的候選方案 o各個方案的優(yōu)點、成本和風險 o開發(fā)團隊與實現(xiàn)技術(shù)的匹配情況 圖4-1 計劃階段的任務(wù)和工件 ?規(guī)模、工作量評估 圍繞各項計劃的制定工作對項目的規(guī)模、工作量

7、等進行評估，評估的內(nèi)容包括： o o模塊數(shù)量與復雜度 o輸入、輸出和對外接口等數(shù)量與復雜度 o SLOC和功能點 o非生產(chǎn)性的支持工作量 o開發(fā)工作量（人月） o進度與里程碑 o進度風險 ?定制項目開發(fā)計劃 項目開發(fā)計劃體現(xiàn)了項目組對整個開發(fā)周期的預期，指定了項目開發(fā)的總體方針。與其 他計劃一樣，項目開發(fā)計劃不是固定不變的，在執(zhí)行過程中要對計劃進行監(jiān)控，可能會根據(jù) 實際情況修改計劃并重新發(fā)布。 項目開發(fā)計劃的內(nèi)容包括： 用三到五張圖表來描述產(chǎn)品目標、功能、平臺、客戶、進度表和開發(fā)職責 圖4-2 風險管理任務(wù) 風險管理計劃定義這些任務(wù)的執(zhí)行流程和人員分配。 風險管理計劃的內(nèi)容包括： 用文字和圖表

8、概述風險管理任務(wù)的總體執(zhí)行流程。 詳細說明“風險識別”任務(wù)的實施細節(jié)和各項工作的負責人。 詳細說明“風險分析”任務(wù)的實施細節(jié)和各項工作的負責人。 險優(yōu)先級詳細說明“確定風險優(yōu)先級”任務(wù)的實施細節(jié)和各項工作的負責人。 險化解方案詳細說明“定制風險處理方案”任務(wù)的實施細節(jié)和各項工作的負責人。 當風險發(fā)生時，需要采取相應(yīng)的措施化解風險。這部分的內(nèi)容是描述風險 工作的操作規(guī)范和流程。 詳細說明風險監(jiān)控任務(wù)的實施細節(jié)和各項工作的負責人。 表4-2 風險管理計劃 常規(guī)開發(fā)活動（需求分析、架構(gòu)設(shè)計、詳細設(shè)計、編碼和測試、發(fā)布和實施等） 會議（工作例會、進度會議、審查會議等） 評審（方案評審、技術(shù)評審、質(zhì)量評

9、審等） 測量（產(chǎn)品規(guī)模測量、進度測量、缺陷率測量、測試覆蓋率測量等） 其他活動（技能培訓、資料收集、內(nèi)部流、客戶溝通等） 表4-4 工作規(guī)范 ?定制開發(fā)進度計劃 基于當前對項目的規(guī)模和工作量評估，定制初步的開發(fā)進度表，作為項目開發(fā)計劃的組 成部分。 開發(fā)進度表的內(nèi)容包括： o o項目的開始和結(jié)束時間 o項目各個階段的開始和結(jié)束時間 o每個階段的工作任務(wù)及其開始和結(jié)束時間 o每個工作任務(wù)的子任務(wù)的及其開始和結(jié)束時間 o里程碑和同步點 o角色的定義和任務(wù)分配 作為跟蹤項目進度的重要依據(jù)，進度表在項目推進過程中需要不斷細化。另外，當實際 進度與計劃進度出現(xiàn)偏差時，需要修改進度表并重新發(fā)布。 執(zhí)行階段

10、 5.客戶的特別要求 開發(fā)的局限 對開發(fā)的成功與否起很大影響的因素，是開發(fā)能力的局限： 1.人員的局限 2.技術(shù)的制約和局限 3.客戶的特別要求 表5-1 需求分析告 需求分析報告的編制方式可以是多樣的，例如把所有“非功能性需求”組織成“外部接 口需求”、“質(zhì)量屬性需求”和“需求約束”?！救纾簣D5-2】 圖5-2 需求規(guī)格說明書 ?界面原型設(shè)計 明確了系統(tǒng)的關(guān)鍵需求后，就可以進行界面原型設(shè)計工作，獲取用戶的反饋，盡快確定產(chǎn)品的界面基調(diào)。同時要編寫一份界面設(shè)計概要文檔，作為后續(xù)的界面設(shè)計工作的指導。 界面設(shè)計概要的內(nèi)容包括： o設(shè)計的理念 o理念的來源或參考 o設(shè)計的要點 o與類似產(chǎn)品界面的對比

11、 ?架構(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】） o所有工程項目 o工程目錄結(jié)構(gòu) o軟件包結(jié)構(gòu) o導入所有依賴包 o基礎(chǔ)公共代碼 o架構(gòu)框架代碼 o架構(gòu)框架示例代碼和測試代碼 o數(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

12、構(gòu)建，最后發(fā)布階段性產(chǎn)品成果。 （注意：在這里，名詞“階段”的含義和本文其他地方的含義不一樣） ?階段計劃 構(gòu)建階段計劃的內(nèi)容包括： o確定本階段要實現(xiàn)的功能 o列出階段任務(wù) o計劃Build構(gòu)建數(shù)量 o細化開發(fā)進度表中本階段的工作內(nèi)容 ?Build 構(gòu)建 詳見：下一節(jié) ?階段產(chǎn)品發(fā)布 構(gòu)建階段完成后發(fā)布階段產(chǎn)品成果，向用戶展示并接受用戶反饋，同時做好階段總結(jié)。 發(fā)布清單的內(nèi)容包括： o產(chǎn)品版本號和日期 o改正的Bug o修改的功能 o實現(xiàn)的新功能 o其他說明 階段總結(jié)報告的內(nèi)容包括： o階段任務(wù)的完成情況 o進度計劃的執(zhí)行情況 o用戶的反饋情況 o本階段碰到的主要問題 o下一階段的改進建議

13、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)容包括： o本次Build的版本號 o本次Build的歷時 o本次Build的工作任務(wù) ?要解決的遺留Bug ?本應(yīng)由以前的Build實現(xiàn)的，但推遲到本次Build實現(xiàn)的功能 ?要實現(xiàn)的新功能 ?其他工作任務(wù) o工作任務(wù)分配 ?需求細化 根據(jù)Build計劃，細化本次Build要實現(xiàn)的需求，細化到能進行詳細設(shè)計為止。有了細化的需求后就編寫本次Build

14、的測試計劃。 測試計劃的內(nèi)容包括： o功能測試 ?要測試的功能 ?測試時間 ?測試方式 ?驗收標準 o其他測試（性能測試、邊界測試、使用界面測試、可用性測試、安全性測試等） ?要測試的內(nèi)容 ?測試時間 ?測試方式 ?驗收標準 o。 ?界面設(shè)計 根據(jù)細化的需求設(shè)計用戶界面，當界面確定后即可編寫測試用例。 測試用例的內(nèi)容包括： o測試用例對應(yīng)的功能模塊 o測試用例的性質(zhì)（功能測試用例、性能測試用例、。） o輸入（或操作步驟） o期望輸出 o實際輸出（執(zhí)行測試后再填寫） o是否通過（執(zhí)行測試后再填寫） ?詳細設(shè)計 詳細實際每項需求的實現(xiàn)方法，對于重要的設(shè)計決策、算法、公共模塊和外部接口等必須以模塊設(shè)

15、計文檔的形式進行記錄。模塊設(shè)計文檔的內(nèi)容包括： o模塊名稱 o設(shè)計思想 o設(shè)計圖表（類圖、流程圖等） o要點描述（包、接口、類、方法、算法、設(shè)計模式） o測試方式 ?編碼、單元測試 編碼和單元測試是開發(fā)人員的工作，對于重要的代碼都必須進行單元測試，編寫代碼必須遵守下列準則： o遵守編碼規(guī)范 o編碼前必須充分理解相關(guān)的需求 o編碼前先進行設(shè)計，把流程理順 o注意設(shè)計方法和設(shè)計模式的靈活運用 o總體考慮問題，使代碼遵從架構(gòu)并容易測試 o設(shè)計時要充分考慮異常情況和臨界條件 o嚴禁Copy-Paste，注意提取公共代碼，在編碼過程中實現(xiàn)重構(gòu) o異常處理必須記錄日志，嚴禁草率地直接打印異常信息 o靈活運

16、用ASSERT() / VERIFY()等斷言來幫助調(diào)試程序 o單元測試是程序員的工作，所以編碼完成后必須對代碼嚴格測試 o功能代碼完成后必須先做以下4件事情： ?編譯代碼，保證編譯通過 ?（不運行程序）對代碼進行全面檢查 ?用調(diào)試模式啟動程序，一行一行單步執(zhí)行代碼，并注意調(diào)試輸出 ?改變條件，讓代碼盡可能走遍所有程序分支 o Check In代碼前必須保證能編譯通過 ?創(chuàng)建Build 代碼集成發(fā)布前需凍結(jié)代碼，所有人把要提交的代碼Check In，并保證編譯后的程序能在測試服務(wù)器上正常啟動，界面能正常打開。同時還要提交Build清單。 Build清單的內(nèi)容包括： o Build版本號和日期

17、o改正的Bug o修改的功能 o實現(xiàn)的新功能 o其他說明 ?集成測試 按照測試計劃針對Build清單執(zhí)行測試用例，測試完成后編寫測試報告。 測試報告的內(nèi)容包括： o測試用例匯總（用例數(shù)量、通過的用例數(shù)量、未通過的用例數(shù)量等） o Bug匯總（Bug總數(shù)、新增Bug數(shù)量、關(guān)閉Bug數(shù)量、Bug趨勢圖表等） o測試計劃執(zhí)行情況 o測試總結(jié) 控制階段 圖6-1 控制階段的任務(wù)和工件 ?風險管理 開發(fā)期間要對風險進行監(jiān)控，定期檢查、更新和發(fā)布風險列表。 ?質(zhì)量管理 1）評審 評審是質(zhì)量保證的重要環(huán)節(jié)，原則上每個重要的工作任務(wù)或階段結(jié)束前都必須經(jīng)過評審，如：方案評審、計劃評審、需求評審、設(shè)計評審和代碼評

18、審等，工作是否被通過、是否需要修改或重做均由評審結(jié)果決定，評審結(jié)果以評審報告的形式發(fā)布。 評審報告的內(nèi)容包括： 評審主題、時間、提交者、評審者等 評審內(nèi)容的列表和簡述 評審過程中重要的問答記錄 整個評審的結(jié)果，如： 1.完全通過，無需修改 2.基本通過，需要作小量修改，但不必再評審 ?測量 在項目開發(fā)過程中，收集一些關(guān)鍵的測量，對了解項目狀態(tài)和進行項目決策很有幫助，同時也為以后的項目提供歷史數(shù)據(jù)參考。每個測量都要生成測量報告并存檔。 測量報告的內(nèi)容包括： 1.基本信息，包括測量主題、測量時間、測量者等 2.測量內(nèi)容和測量值 3.測量分析 結(jié)束階段 圖7-1 控制階段的任務(wù)和工件 ?產(chǎn)品測試 因

19、為產(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)品不應(yīng)該有大改動，一般只是界面的局部調(diào)整。 ?編制用戶文檔 針對不同的使用者角色，編制相應(yīng)的用戶文檔，對管理者用戶需要提供安裝、維護指南，對普通用戶需要編制產(chǎn)品使用手冊。 安裝、維護指南的內(nèi)容包括： 1. 1.產(chǎn)品各組件的說明 2.產(chǎn)品部署架構(gòu) 3.安裝、配置和卸載等步驟 4.啟動、停止和重啟等操作 5.其它操作：日志、備份、還原等 產(chǎn)品使用手冊的內(nèi)容包括： 1

20、.產(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.代碼整理 ?正式版發(fā)布 正式版的發(fā)布標志著開發(fā)階段的結(jié)束，產(chǎn)品從此時起進入維護階段，正式發(fā)布前可能要做一些準備工作，如：數(shù)據(jù)遷移

21、和環(huán)境配置等。 ?項目總結(jié) 項目結(jié)束后需要對整個項目開發(fā)階段的工作進行總結(jié)，交流心得，吸取經(jīng)驗和教訓，并歸檔為項目總結(jié)報告。 項目總結(jié)報告的內(nèi)容包括： 1. 1.總體評價 2.成本、收益匯總 3.重要心得 4.管理總結(jié) 5.技術(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ù)劃分方案： 圖

22、8-2 角色和任務(wù)劃分方案 職責和角色不清楚往往是造成軟件項目團隊管理混亂的一個重要原因，一個好的軟件團隊必須根據(jù)團隊規(guī)模的不同和項目本身的特點對項目成員的角色和崗位進行明確的劃分，這樣團隊中的每個成員才可能有清晰的責任和目標。 軟件開發(fā)不管采用哪種生命周期模型和開發(fā)方法論，整個過程都會包含需求，設(shè)計，開發(fā)，測試，配置管理等各項活動。而這些活動會對應(yīng)到項目中的不同角色，項目中進行崗位劃分后每個崗位成員可以兼職多個角色。形成相關(guān)的角色崗位矩陣。 方案一項目負責人總覽全局 對于小作坊的軟件開發(fā)團隊，可以由一個項目負責人總覽全局。項目負責人承擔從用戶需求-軟件需求-總體設(shè)計的所有工作。同時還需要做到

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

24、認，并寫入到項目開發(fā)規(guī)范中。 方案二項目負責人和開發(fā)負責人分離 在這種方案下項目負責人和開發(fā)負責人在軟件需求和架構(gòu)上的工作是重疊的。這兩個崗位的人員共同來確認項目的總體方案和架構(gòu)。項目負責人的重點在項目管理和與客戶交流溝通上，只有確認清楚第一手的用戶需求，才能開發(fā)出用戶滿意度高的軟件。對于很多小型項目往往是用戶需求都沒有搞清楚就開工，項目成員完全憑借著自己的感覺在做系統(tǒng)，過程中又不注意與用戶及時反饋和迭代，導致開發(fā)出完全不能使用的系統(tǒng)；開發(fā)負責人的重點是對整個開發(fā)過程負責，包括對項目經(jīng)理確認的進度目標進行任務(wù)的進一步分解，安排后續(xù)的增量和迭代計劃。方案二的重點是第一次解放項目經(jīng)理，架構(gòu)的核心移動到了開發(fā)負責人，而項目經(jīng)理僅僅是參與討論和評審。而單獨剝離出開發(fā)負責人后