項目管理的三個重要概念-檢查點-里程碑-基線-(全)(共3頁)

1、精選優(yōu)質文檔-傾情為你奉上項目管理的三個重要概念：檢查點、里程碑、基線什么是基線(Baseline)？ 基線是軟件文檔或源碼(或其它產出物)的一個穩(wěn)定版本,它是進一步開發(fā)的基礎。所以,當基線形成后,項目負責SCM的人需要通知相關人員基線已經形成,并且哪兒可以找到這基線了的版本。這個過程可被認為內部的發(fā)布.至于對外的正式發(fā)布,更是應當從基線了的版本中發(fā)布。 基線是項目儲存庫中每個工件版本在特定時期的一個“快照”。它提供一個正式標準，隨后的工作基于此標準，并且只有經過授權后才能變更這個標準。建立一個初始基線后，以后每次對其進行的變更都將記錄為一個差值，直到建成下一個基線。 參與項目的開發(fā)人員將基線

2、所代表的各版本的目錄和文件填入他們的工作區(qū)。隨著工作的進展，基線將合并自從上次建立基線以來開發(fā)人員已經交付的工作。變更一旦并入基線，開發(fā)人員就采用新的基線，以與項目中的變更保持同步。調整基線將把集成工作區(qū)中的文件并入開發(fā)工作區(qū)。為什么要建立基線？1、重現(xiàn)性 重現(xiàn)性是指及時返回并重新生成軟件系統(tǒng)給定發(fā)布版的能力，或者是在項目中的早些時候重新生成開發(fā)環(huán)境的能力。2、可追蹤性 可追蹤性建立項目工件之間的前后繼承關系。其目的在于確保設計滿足要求、代碼實施設計以及用正確代碼編譯可執(zhí)行文件。3、報告 報告來源于一個基線內容同另一個基線內容的比較?；€比較有助于調試并生成發(fā)布說明。 建立基線后，需要標注所有

3、組成構件和基線，以便能夠對其進行識別和重新建立。建立基線有哪些優(yōu)點？ 1、基線為開發(fā)工件提供了一個定點和快照。 2、新項目可以從基線提供的定點之中建立。作為一個單獨分支，新項目將與隨后對原始項目（在主要分支上）所進行的變更進行隔離。 3、各開發(fā)人員可以將建有基線的構件作為他在隔離的私有工作區(qū)中進行更新的基礎。 4、當認為更新不穩(wěn)定或不可信時，基線為團隊提供一種取消變更的方法。 5、您可以利用基線重新建立基于某個特定發(fā)布版本的配置，這樣也可以重現(xiàn)已報告的錯誤。基線如何使用？ 定期建立基線以確保各開發(fā)人員的工作保持同步。但是，在項目過程中，應該在每次迭代結束點（次要里程碑），以及與生命周期各階段結

4、束點相關聯(lián)的主要里程碑處定期建立基線： 生命周期目標里程碑（先啟階段） 生命周期構架里程碑（精化階段） 初始操作性能里程碑（構建階段） 產品發(fā)布里程碑（產品化階段）分類 第一次提出軟件配置項就構成基線配置項。基線分類列表如下：系統(tǒng)功能說明。系統(tǒng)模型，項目計劃，進度安排；軟件需求規(guī)格說明。包括：圖形分析模型、過程、原型、數(shù)學規(guī)格說明；設計規(guī)格說明。包括：數(shù)據設計、體系結構設計、界面設計、對象的描述等；驗收規(guī)格說明；測試規(guī)格說明。包括：測試計劃、測試用例、測試預期結果、測試記錄等；數(shù)據庫描述。包括：數(shù)據模式、記錄結構、數(shù)據項描述；模塊規(guī)格說明。包括：模塊功能、模塊算法、模塊接口等描述；運行系統(tǒng)。包

5、括：模塊代碼、鏈接模塊、數(shù)據庫、支持及工具程序等；用戶文檔。包括：安裝說明、操作說明、用戶手冊等；培訓計劃；維護文檔，包括：故障報告、維護要求、更改記錄等；項目采用的有關標準和規(guī)程。項目生命周期中有三個與時間相關的重要概念，我發(fā)現(xiàn)很多人對這三個概念理解不準確，更不知道如何進行控制。因此把這三個概念論述得比較準確的一段文字貼出來，幫助大家理解。這三個概念分別是： 檢查點（ CheckPoint ）、里程碑（ Mile Stone ）和基線（ Base Line ），他們一起描述了在什么時候（ When ）對項目進行什么樣控制。檢查點指在規(guī)定的時間間隔內對項目進行檢查，比較實際與計劃之間的差異，并

6、根據差異進行調整?？蓪z查點看作是一個 固定 “ 采樣 ” 時點，而時間間隔根據項目周期長短不同而不同，頻度過小會失去意義，頻度過大會增加管理成本。常見 的間隔是每周一次，項目經理需要召開例會并上交周報。里程碑完成階段性工作的標志，不同類型的項目里程碑不同。里程碑在中具有重要意義，我們用一個例子說明：情況一：你讓一個程序員一周內編寫一個模塊，前 3 天你們可能都挺悠閑，可后 2 天就得拼命加班編程序了，而到周末時 又發(fā)現(xiàn)系統(tǒng)有錯誤和遺漏，必須修改和返工，于是周末又得加班了。情況二：實際上你有另一種選擇，即周一與程序員一起列出所有需求，并請業(yè)務人員評審，這時就可能發(fā)現(xiàn)遺漏并即 時修改；周二要求程

7、序員完成模塊設計并由你確認，如果沒有大問題，周三、周四就可讓程序員編程。同時自己準備 測試案例，周五完成測試；一般經過需求、設計確認，如果程序員合格則不會有太大問題，周末可以休息了。 第二種方式增加了 “ 需求 ” 和 “ 設計 ” 兩個里程碑，這看似增加了額外工作，但其實有很大意義：首先，對一些復雜的項 目，需要逐步逼近目標，里程碑產出的中間 “ 交付物 ” 是每一步逼近的結果，也是控制的對象。如果沒有里程碑，中間 想知道 “ 他們做的怎么樣了 ” 是很困難的。其次，可以降低項目風險。通過早期評審可以提前發(fā)現(xiàn)需求和設計中的問 題，降低后期修改和返工的可能性。另外，還可根據每個階段產出結果分期確認收入，避免血本無歸。第三，一般人 在工作時都有 “ 前松后緊 ” 的習慣，而里程碑強制規(guī)定在某段時間做什么，從而合理分配工作，細化管理 “ 粒度 ” ?；€指一個（或一組）配置項在項目生命周期的不同時間點上通過正式評審而進入正式受控的一種狀態(tài)?；€其實是一些 重要的里程碑，但相關