接受項目管理培訓至今已經有三年時間瞭，一直沒有機會來整理一下自己在項目管理方面的學習歷程和經驗。好記性不如爛筆頭，從今天開始就一步一步分享一下我在項目管理方面的學習歷程以及一些在工作中累積的經驗，希望可以幫助到從事項目管理的人！

在前面的博文項目管理 之一 軟件開發生命周期（軟件開發過程、瀑佈模型、敏捷開發等） 中我們說過 軟件開發生命周期 ≠ 項目的開發周期。接下來就再進一步，站在整個項目的角度來瞭解一下軟件項目管理。

註意：

這部分僅僅是自己學習記錄的一些總結，所以內容大多數都是來自互聯網或者各種書籍。如果您發現對您構成瞭侵權，請隨時聯系我進行處理。

這部分內容都是一些理論，實際項目中往往與理論有所不同。例如，階段劃分更加詳細，項目活動可裁剪等

項目管理

項目這個概念非常的廣泛，項目管理同樣是個范圍很大的概念。項目管理是管理學的一個分支學科 ，對項目管理的定義是：指在項目活動中運用專門的知識、技能、工具和方法，使項目能夠在有限資源限定條件下，實現或超過設定的需求和期望的過程。所謂管理包含領導、組織、用人、計劃及控制等五項主要工作。

作為一門學科，項目管理從土木施工、工程、重型國防等多個應用領域發展而來。20 世紀 50 年代項目管理被公認為具有工程模式的管理學科所產生的一門獨特的學科。1969 年，項目管理研究所（PMI）在美國成立。PMI 於 1996 年出版瞭第一版《項目知識管理機構指南》（PMBOK 指南）。這本書是必看的！本文的有些內容就是來自這本指南。

項目管理方法可應用於任何類型的項目。它通常根據項目規模、性質、行業或部門為特定類型的項目量身定做。例如，以建築、道路和橋梁等工程的交付為重點的建築行業已經發展瞭自己的專業項目管理形式，稱為建築項目管理；我們軟件行業則有我們的軟件項目管理。

接下來，我們來區分一下三個比較容易混淆的概念：項目生命周期、項目管理生命周期、產品生命周期

項目生命周期

項目的生命周期是描述項目從開始到結束所經歷的各個階段。通常由 啟動階段、組織與準備階段（規劃階段）、實施階段、結束階段 這四階段個組成。每個階段確定瞭開始和結束點，每個階段都有質量保證 QA / 質量測試 QC 人員對階段的裡程碑點進行檢查並進行相應的階段評審。

f54d763cd3786a06b34a2eaf1d5f9363

項目階段是一組具有邏輯關系的項目活動的集合，通常以一個或多個可交付成果的完成為結束。 階段通常有先後的順序（如瀑佈型），也可以有階段的交疊。不同行業，不同規模的項目，項目生命周期可以不同。

項目規劃階段的目的是為瞭管控的需要，每一個階段都可以當成是一個子項目，每一個階段中都可以執行項目管理生命周期定義的五大過程組。階段結束時要進行階段評審。由於項目有特定的目標，在產品生命周期中，一般產品完成後通過驗收則項目生命周期即結束。

項目階段並沒有嚴格的劃分標準。這裡所說的 4 個階段僅僅是指的一般情況。一個具體的項目可以根據項目所屬專業領域的特殊性和項目的工作內容等因素劃分成不同的項目階段。

啟動階段

啟動階段是整個項目生命周期的第一階段。這一階段的目標是確定項目，並獲得批準。在此期間，通常有以下項目活動需要項目經理來處理：

• 需求調研
• 進行可行性研究
• 創建項目章程
• 確定關鍵利益相關者
• 選擇合適的項目管理方法
• 選擇項目管理工具

通常，從項目啟動會議開始，項目經理向所有相關利益相關者概述項目目標。在會議召開之前，項目經理必須執行以下工作：

• 建立目標和可交付成果
• 識別團隊成員並分配任務
• 制定項目計劃草案
• 定義用於衡量項目成功的指標
• 識別和準備潛在的路障
• 建立團隊溝通的物流和時間表
• 選擇首選的項目管理方法
• 確保您的團隊能夠訪問相關工具並瞭解相關工具
• 安排會議
• 設置議程並準備幻燈片

啟動會議議程可能如下所示：

• 簡介：誰是誰？
• 項目背景：您為什麼要進行這個項目？ 目標是什麼？
• 項目范圍：涉及哪種工作？
• 項目計劃：路線圖是什麼樣的？
• 角色：誰負責項目的哪些元素？
• 交流：將使用哪種交流渠道？ 您的團隊應該期望什麼樣的會議或狀態報告？
• 工具：將使用哪些工具來完成項目，以及如何使用它們？
• 後續步驟：需要完成哪些立即行動項目？
• 問答（Q&A）：現場答疑

到此階段結束時，項目經理應對項目的目的、目標、要求和風險有更深入的瞭解。

規劃階段

規劃階段對於創建整個團隊可以遵循的項目路線圖至關重要。為瞭滿足組織提出的要求，所有的細節和目標都在這裡列出。在此階段，通常有以下項目活動需要項目經理來處理：

• 創建項目計劃
• 制定資源計劃
• 評估項目預算
• 定義目標和績效衡量指標
• 向團隊成員傳達角色和責任
• 構建工作流
• 預測風險並制定應急計劃
• 制定溝通交流計劃（可能是會議、交流工具）

執行階段

這個階段是項目投入時間最多的階段。可交付品的構建是為瞭確保項目符合要求。這也是大多數時間、金錢和人被投入的階段。

在執行階段必須時刻對項目進行控制和監測（嚴格來說，項目的每個階段都可以控制和監測）。隨著項目的推進，項目經理必須確保所有活動的部分都朝著正確的方向無縫地進行。如果由於不可預見的情況或方向的改變而需要對項目計劃進行調整，則可能會在這裡進行調整。在控制和監測中，項目經理（有可能是公司中專門的 QA 人員）可能需要做以下工作：

• 管理資源
• 監控項目性能
• 風險管理
• 質量管理
• 成本管理
• 變更管理（更新項目計劃、修改項目計劃）
• 執行狀態會議和報告
• 協作、溝通

項目關閉

• 結束階段是項目生命周期的關鍵一步。它標志著項目的正式結束，並為反思、總結和組織材料提供瞭一段時間。通常有以下項目活動需要項目經理來處理：
• 盤點所有可交付成果
• 處理好任何零碎的事情
• 將項目移交給客戶或負責項目日常運營的團隊
• 進行事後分析，討論並記錄從項目中學到的任何東西
• 集中組織所有項目文件
• 與利益相關者和主管溝通項目的成功
• 慶祝項目完成並感謝團隊成員

階段關口

階段關口在項目階段結束時進行，將項目的績效和進度與項目和業務文件比較，這些文件包括 （但不限於）：

• 項目商業論證
• 項目章程
• 項目管理計劃
• 效益管理計劃

根據比較結果做出決定（例如繼續/終止的決定），以便：

• 進入下個階段；
• 整改後進入下個階段；
• 結束項目；
• 停留在當前階段；
• 重復階段或某個要素。

在不同的組織、行業或工作類型中，階段關口可能被稱為階段審查、階段門、關鍵決策點和階段入口或階段出口。

項目管理生命周期

項目管理生命周期是對項目目標的實現進行管理的過程。項目生命周期每個階段都是通過一系列項目管理活動進行的。這些管理活動被稱為項目管理過程。 每個項目管理過程通過合適的項目管理工具和技術將一個或多個輸入轉化成一個或多個輸出。

項目管理過程組指對項目管理過程進行邏輯分組，以達成項目的特定目標。過程組不同於項目階段。項目管理過程可分為以下五個項目管理過程組：

• 啟動過程組： 定義一個新項目或現有項目的一個新階段，授權開始該項目或階段的一組過程。
• 規劃過程組： 明確項目范圍，優化目標，為實現目標制定行動方案的一組過程。
• 執行過程組： 完成項目管理計劃中確定的工作，以滿足項目要求的一組過程。
• 監控過程組： 跟蹤、審查和調整項目進展與績效，識別必要的計劃變更並啟動相應變更的一 組過程。
• 收尾過程組： 正式完成或結束項目、階段或合同所執行的過程。

但是，需要註意 階段 ≠ 過程組。不同行業，不同規模項目的項目管理生命周期大致相同。項目管理生命周期的過程是 PMP（Project Management Professional​） 考試的主要考試范圍。

除瞭過程組，過程還可以按知識領域進行分類，分為 10 個知識領域（其中始終關註的是范圍、進度、成本和質量）：

項目整合管理： 包括為識別、定義、組合、統一和協調各項目管理過程組的各個過程和活動而開展的過程與活動。

• 項目范圍管理： 包括確保項目做且隻做所需的全部工作以成功完成項目的各個過程。
• 項目進度管理： 包括為管理項目按時完成所需的各個過程。
• 項目成本管理： 包括為使項目在批準的預算內完成而對成本進行規劃、估算、預算、融資、籌資、管理和控制的各個過程
• 項目質量管理： 包括把組織的質量政策應用於規劃、管理、控制項目和產品質量要求，以滿足相關方的期望的各個過程。
• 項目資源管理： 包括識別、獲取和管理所需資源以成功完成項目的各個過程。
• 項目溝通管理： 包括為確保項目信息及時且恰當地規劃、收集、生成、發佈、存儲、檢索、管理、控制、監督和最終處置所需的各個過程。
• 項目風險管理： 包括規劃風險管理、識別風險、開展風險分析、規劃風險應對、實施風險應對和監督風險的各個過程。
• 項目采購管理： 包括從項目團隊外部采購或獲取所需產品、服務或成果的各個過程。
• 項目相關方管理： 包括用於開展下列工作的各個過程：識別影響或受項目影響的人員、團隊或組織，分析相關方對項目的期望和影響，制定合適的管理策略來有效調動相關方參與項目決策和執行。

下圖顯示瞭管理過程朱與知識領域的對應關系以及在過程中需要的工作：

257d52237c9a2ff0af96378edd344e7e

裁剪

由於每個項目都是獨特的，所以有必要對項目管理過程進行裁剪；並非每個項目都需要《PMBOK® 指南》所確定的每個過程、工具、技術、輸入或輸出。裁剪應處理關於范圍、進度、成本、資源、質量和風險的相互競爭的制約因素。各個制約因素對不同項目的重要性不一樣，項目經理應根據項目環境、組織文化、相關方需求和其他變量裁剪管理這些制約因素的方法。

產品生命周期

產品生命周期管理的是產品，包括一系列產品階段：市場調研、產品研發、試產、量產、運營、維護和退市。產品生命周期通常包含順序排列且不互相交叉的一系列產品階段。

產品生命周期由一個或多個項目生命周期組成，也可能分為多個迭代周期來實現。 而項目生命周期也可開發一個或多個產品。一個項目生命周期通常隻包含在一個產品生命周期中。在項目生命周期結束即項目完成後，而產品生命周期還需進行產品的運營、維護和退市等階段。

與產品生命周期相對應的成本概念是全生命周期成本，包括一次性的項目軟硬件投入（一次性成本），以及 3 - 5 年運營或運維成本（持續成本）。

三重關系

三重約束，又稱項目管理三角，是指適用於每個項目的時間、質量和成本界限。負責控制這些限制的項目管理流程包括進度管理、成本管理和質量管理。下圖顯示瞭軟件項目的三個限制的關系。

我在學習中發現，有部分文章中，質量 被替換為 范圍，即：時間、范圍和成本。

軟件項目管理

到目前為止，仍然有很多人有疑問：軟件開發項目到底能不能稱為項目？這與對於軟件工程能不能算是工程的疑問類似。在某些人的認識中，項目或者說工程更多的是指工業建築中的專有名詞。

自 20 世紀 60 年代以來，軟件制造商自行開發瞭幾種專有的軟件項目管理方法。今天，軟件項目管理方法仍在不斷發展，但是當前的趨勢已從瀑佈模型轉移到瞭模仿軟件開發過程的更具周期性的項目交付模型。

軟件項目管理（Software Project Management）就是為瞭使軟件項目能夠按照預定的成本、進度、質量順利完成，而對人員（People）、產品（Product）、過程（Process）和項目（Project）進行分析和管理的活動。通常，可以將軟件開發項目可以分為兩大類：

• 軟件項目： 運行於已有通用硬件上的軟件系統。例如，PC 上運行的軟件，服務器上運行的網站。
• 系統項目： 運行於特定硬件上的軟件系統，除瞭要開發軟件，還要開發對應的硬件。例如各種嵌入式設備。

如果沒有特殊說明，後文我們所說的軟件項目管理均指這兩種類型的統稱

軟件工程項目管理不同於傳統的項目管理，因為軟件項目具有獨特的生命周期過程，需要多輪測試、更新和客戶反饋。目前，大多數 IT 相關項目都以敏捷的風格進行管理，以跟上業務增長的步伐，並根據客戶和利益相關者的反饋進行重復。

過程方法

2017 年的一項研究顯示，任何項目的成功取決於四個關鍵方面，這些方面被稱為 4P ：

1. 計劃（Plan）：指所有涉及規劃和預測的活動。在這個階段，項目或項目的要素尚未實現；
2. 過程（Processes）：項目管理知識體（PMBOK, Project Management Body of Knowledge）指南中記述，項目主要由一系列預定和結構良好的過程所組成；
3. 人員（People）：人員是項目動態的重要組成部分，一些研究表明，人員是某些項目特有問題的核心。所謂“可怕的結合”，特別是指規劃不善和不適當人員的構成；
4. 權責（Power）：描述當局所有的權力與責任、決策者、組織圖，執行政策和喜好。

組織與完成項目活動有許多方法，包括：分階段、精益、迭代和增量等；也有一些對項目規劃的幾個擴展，例如，針對結果（基於產品）或活動（基於流程）。不論采行何種方法論，必須精心縝密地考慮項目總體的目標，時程和成本，以及所有參與者和利害關系人的作用和責任。

對於軟件開發項目，在博文“項目管理 之一 軟件開發生命周期（軟件開發過程、瀑佈模型、敏捷開發等）“中介紹的各種過程模型，基本就是指導我們軟件開發的方法。但是，由於項目具有獨特性，因此標準的生命周期模型往往難以滿足項目的特殊需要。通常項目在定義生命周期時，可首先選擇一種標準的生命周期模型作為基礎，然後指定出適合自己的方法。

傳統的順序方法

瀑佈式管理方法

規劃項目的最常見方法是對導致最終交付的任務進行排序，並按順序進行工作。這個過程也被稱為瀑佈方法——管理項目的傳統方法，也是最容易理解的方法。

這種方法的強大之處在於，每一步都是預先計劃好的，並按照適當的順序安排好。雖然這可能是最簡單的最初實現方法，但涉眾需求或優先級的任何更改都會破壞一系列任務，使其很難管理。這種方法在可預見性方面很出色，但缺乏靈活性。

關鍵路徑方法（CPM）

關鍵路徑方法（Critical Path Method）是在 20 世紀 50 年代開發的，其基礎是，有些任務在完成上一個任務之前無法啟動。當您從頭到尾將這些依賴任務串在一起時，您會繪制出關鍵路徑。

確定並關註這一關鍵路徑後，項目經理就可以確定優先級並分配資源，以完成最重要的工作，並重新安排可能會阻塞團隊的所有低優先級任務。 這樣，如果您需要更改項目進度表，則可以在不延遲結果的情況下優化團隊的工作流程。

關鍵鏈項目管理（CCPM）

關鍵鏈項目管理（Critical Chain Project Management）將關鍵路徑方法更進一步。CCPM 是一種方法，它側重於通過在關鍵路徑中增加資源可用性來完成項目任務所需的資源。它還在項目計劃中圍繞這些任務建立時間緩沖，確保項目滿足其最後期限。

敏捷傢族

由於競爭激烈的商業環境和不斷創新，敏捷的項目管理方法越來越受歡迎。一般來說，敏捷方法優先考慮更短的迭期周期和靈活性。

Scrum

Scrum 是最受歡迎的敏捷發展框架，因為它的實現相對簡單。它還解決瞭軟件開發人員過去遇到的許多問題，例如復雜的開發周期、不靈活的項目計劃以及更改生產計劃。

詳細介紹見 項目管理 之二 敏捷開發方法 Scrum 最全指導 .

看板

看板是基於團隊能力實施敏捷的另一個框架。它起源於 20 世紀 40 年代的豐田工廠。各部門使用可視化的卡片系統（“看板”）來表示他們的團隊已經為更多的原材料做好準備，並擁有更多的生產能力。

極限編程 （XP）

極限編程 （Extreme Programming） 是敏捷的另一個分支。XP 是一種旨在提高軟件質量（和簡單性）和開發團隊適應客戶需求的能力的方法。與原始的敏捷開發非常類似，XP 具有工作沖刺短、迭代頻繁以及與利益相關者不斷協作的特點。變化可能發生在沖刺階段。如果特定功能的工作尚未開始，則可以將其更換為類似任務。

自適應項目框架（APF）

自適應項目框架（Adaptive Project Framework）源於由於不確定和不斷變化的需求而難以使用傳統項目管理方法來管理大多數 IT 項目的情況。

APF從需求分解結構（RBS）開始，以根據產品需求，功能，子功能和功能定義戰略項目目標。 該項目分階段進行，在每個步驟的最後，團隊都會評估以前的結果以改善性能和實踐。

變更管理方法

有些方法論用於管理項目，但更側重於變更管理，尤其是風險規劃和在變更發生時進行控制。

事件鏈方法（ECM）

事件鏈方法（Event Chain Methodology）背後的基本理念是，潛在風險往往不在項目范圍之外。必須做好應對這些風險的準備，並計劃您的應對措施，因為意外事件會影響您的項目的進度、交付成果以及潛在的成功。

極限項目管理（XPM）

極限項目管理 （Extreme Project Management） 與瀑佈正好相反。它為您提供瞭一種管理大規模變革的方法，並且仍然朝著項目完成的方向前進。在 XPM 中，無論項目進展有多遠，您都可以更改項目計劃、預算，甚至最終交付，以滿足不斷變化的需求。

基於過程的方法

其中每種方法都側重於將工作作為流程的集合。

精 益

精益（Lean）是一種專註於精簡和減少浪費的方法（精益求精）。第一步是創建工作流程分解，以識別和消除瓶頸和延遲。目標是用更少的人力、更少的錢和更少的時間為客戶提供價值。

Six sigma

Six Sigma 於20 世紀 80 年代中期由摩托羅拉的工程師介紹，通過識別項目中不起作用的內容來提高質量。

Six Sigma 是一種基於統計的方法，旨在通過測量存在的缺陷並消除盡可能多的缺陷來提高過程質量。 如果 99.99966％ 的最終產品（您的項目可交付成果）沒有缺陷，則該過程可以達到 Six Sigma 等級。

其他方法

PRINCE2

PRINCE2 代表受控環境中的項目。 這是一種用於管理英國政府使用的項目的方法，其特點是基於產品的計劃方法。 在 PRINCE2 中，結構化的項目委員會負責高層活動，例如確定業務理由和資源分配。 項目經理負責日程安排等較低級別的日常活動。 這種方法使團隊可以更好地控制資源並有效降低風險。

PRiSM

PRiSM 代表“集成可持續方法的項目”，旨在在將環境可持續性納入其流程的同時管理變更。 PRiSM的目標是完成任務，同時減少公司對環境和社會的負面影響。 從字面上看，它是綠色項目管理。

項目管理的角色

項目經理

項目經理密切監視開發過程，準備並執行各種計劃，安排必要和充足的資源，保持所有團隊成員之間的溝通，以解決成本，預算，資源，時間，質量和客戶滿意度方面的問題。

正式的項目經理通常通過美國 PMI 或英國 PRINCE2 之類的機構進行認證。認證後，他們需要通過接受額外的培訓來收集目標數量的 PDU（Professional Development Units）來維持其認證。

在實際的工作中，認證並不總是一個要求，它可以是在以後的職業生涯中獲得的東西。大多數項目經理通常從工商管理學位開始，但實際中並非總是這樣。經驗往往比學位更響亮。

通常，項目經理需要熟練使用 PERT 來對項目進行管理。

軟件項目經理

軟件項目經理是負責執行軟件項目的人員，通常是 PMI 認證的項目管理專業人員 （PMP）。 軟件項目經理完全瞭解軟件將經歷的 SDLC 的所有階段。項目經理可能永遠不會直接參與最終產品的生產，但他會控制和管理生產中涉及的活動。

項目成員

他們是負責完成項目一的人員。 團隊成員是熟練的專業人員，他們致力於為項目目標做出貢獻。

客戶

項目產品的交付者。可能來自內部，也可能來自外部。

利益相關者

這是在項目中有既得利益的人或團體。它可能是一個組織的內部團體或機構，也可能是公共工程項目的公眾。

風險管理

風險管理是對風險（在 ISO 31000 中定義為不確定性對目標的影響）的識別，評估和優先級劃分，然後協調，經濟地使用資源以最小化，監視和控制不幸事件的可能性或影響或最大化機會的實現。風險管理包括與識別、分析和為項目中的可預測和不可預測風險做準備相關的所有活動。

風險評估

軟件項目風險是指在整個項目周期中所涉及的成本預算、開發進度、技術難度、經濟可行性、安全管理等各方面的問題，以及由這些問題而對項目所產生的影響。

項目的風險與其可行性成反比，其可行性越高，風險越低。軟件項目的可行性分為經濟可行性、業務可行性、技術可行性、法律可行性等四個方面。而軟件項目風險則分為產品規模風險、需要風險、相關性風險、管理風險、安全風險等六個方面。

成本預算

自上而下的預算方法（經驗估計技術）

自上而下的預算方法主要是依據上層、中層項目管理人員的管理經驗進行判斷，對構成項目整體成本的子項目成本進行估計，並把這些判斷估計的結果傳遞給低一層的管理人員，在此基礎上由這一層的管理人員對組成項目的子任務和子項目的成本進行估計，然後繼續向下一層傳遞他們的成本估計，直到傳遞到最低一層。

該技術使用經驗導出的公式進行估算。這些公式基於 LOC 或 FP。

• Putnam 模型： 該模型由Lawrence H. Putnam制作，該模型基於Norden的頻率分佈（瑞利曲線）。 Putnam模型映射瞭軟件大小所需的時間和精力。

• COCOMO： COCOMO 是由 Barry W. Boehm 開發的建設性成本模型（COnstructive COst MOdel）的縮寫。它將軟件產品分為三類:有機軟件、半分離軟件和嵌入式軟件。

自下而上的預算方法（分解技術）

自下而上方法要求運用 WBS（Work Breakdown Structure，工作分解結構）對項目的所有工作任務的時間和預算進行仔細考察。最初，預算是針對資源（團隊成員的工作時間、硬件的配置）進行的，項目經理在此之上再加上適當的間接費用（如培訓費用、管理費用、不可預見費等）以及項目要達到的利潤目標就形成瞭項目的總預算。

主要有兩種模式：

• 代碼行： 依據軟件產品中的代碼行數進行估計。
• 功能點： 依據軟件產品中功能點的數量進行估算。

自下而上的預算方法要求全面考慮所有涉及到的工作任務，更適用於項目的初期與中期，它能準備地評估項目的成本，與真實費用相差在 5% ~ 10% 之間。

質量管理

質量管理確保組織、產品或服務是一致的。它包括四個主要組成部分：質量規劃、質量保證、質量控制和質量改進。 質量管理不僅註重產品和服務質量，而且註重實現質量的手段。因此，質量管理利用對工藝和產品的質量保證和控制來實現更一致的質量。

軟件質量保證

軟件質量保證（SQA，Software Quality Insurance）是在軟件過程中的每一步都進行的“保護性活動”。SQA 主要有基於非執行的測試（也稱為評審）、基於執行的測試（即通常所說的測試）和程序正確性證明。

軟件評審是最為重要的 SQA 活動之一。它的作用是，在發現及改正錯誤的成本相對較小時就及時發現並排除錯誤。審查和走查是進行正式技術評審的兩類具體方法。

配置管理

配置管理是根據產品的需求，設計，功能和開發來跟蹤和控制軟件更改的過程。IEEE 將其定義為：the process of identifying and defining the items in the system, controlling the change of these items throughout their life cycle, recording and reporting the status of items and change requests, and verifying the completeness and correctness of items。

配置管理是組織管理的一門學科，它負責處理階段性基礎化後發生的任何變化（流程、要求、技術、戰略等）。CM 會不斷檢查軟件中所做的任何更改。

軟件配置管理

軟件配置管理（SCM，Software Configuration Management）是應用於整個軟件過程中的保護性活動，它是在軟件整個生命周期內管理變化的一組活動。是配置管理這個更大的跨學科領域的一部分。

軟件配置管理包括版本控制和基線的建立。如果出現問題，SCM 可以確定更改瞭什麼以及是誰更改瞭它。如果配置工作良好，SCM 可以決定如何在許多主機上復現它。

軟件配置管理系統

庫是軟件配置管理系統的根本。庫是集中控制的文件庫，並提供對庫中所存儲文件的版本控制。任何庫中的文件都被視為在確定的軟件配置管理之下。

在項目實際工作中，可以用 SVN、Git 等工具來建立配置庫。

基線

在配置管理中，基線是在某個時間點對產品屬性達成的一致描述，可作為定義更改的基礎。更改是從此基準狀態到下一個狀態的移動。 識別基線狀態的重大變化是基線識別的主要目的。

如果 SDLC 的一個階段已經建立瞭基線，那麼就假定它已經完成瞭，例如，基線是定義一個階段完整性的度量。當與階段有關的所有活動都已完成並得到良好的文檔記錄時，階段就被確立為基線。如果它不是最後階段，它的輸出將用於下一個直接階段。

版本控制

在軟件工程中，版本控制（也稱為修訂控制，源代碼控制或源代碼管理）是一類負責管理對計算機程序，文檔，大型網站或其他信息集合的更改的系統。 版本控制是軟件配置管理的組成部分。

在軟件開發中，版本控制系統的使用是必不可少的。詳細見博文 版本控制系統 之一 概念、分類、常見版本控制系統（CVS、SVN、BitKeeper、Git 等） 。

變更管理

變更管理（Change management）是對所有支持和幫助個人或團隊進行組織變更的方法的集合術語。變更的驅動因素可能包括技術的不斷演變、流程的內部審查、危機應對、客戶需求變化、競爭壓力、收購和兼並以及組織重組。 它包括重定向或重新定義資源使用、業務流程、預算分配或其他顯著改變公司或組織運營模式的方法。

變更控制

變更控制（Change Control）是質量管理系統（QMS）和信息技術（IT）系統中的一個過程，用來確保以受控和協調的方式引入產品或系統的變更。它減少瞭在沒有預先考慮的情況下對系統進行不必要的更改、在系統中引入錯誤或撤銷其他軟件用戶所做的更改的可能性。變更控制過程的目標通常包括最小化對服務的幹擾，減少回退活動，以及對實現變更所涉及的資源的低成本利用。

不要與版本控制相混淆。

參考

軟件項目管理 - MBA智庫百科

http://learnfuture.com/PMP/902

軟件項目管理流程總結 - 風塵浪子 - 博客園

Software Project Management

Understanding the Project Lifecycle | Project Management Guide

Choose Your Project Management Methodology | Project Management Guide

http://en.wikipedia.org/wiki/Software_project_management

Project Management

內容分享自網絡，如有侵權請聯系刪除！