文章目錄

• 10大知識領域
• 項目的概念
• 項目組織結構
• 信息系統項目生命周期
• • 瀑布模型
  • 螺旋模型
  • 迭代模型
  • Ⅴ模型
  • 原型法
  • 敏捷開發模型
  • 小結

參考資料：軟考高級信息系統項目管理師教材

10大知識領域

一：項目整合管理
二：項目范圍管理
三：項目時間管理
四：項目成本管理
五：項目質量管理
進成質范【進城吃飯】是核心知識領域，將形成具體的項目目標。

六：項目人力資源管理
七：項目溝通管理
八：項目風險管理
九：項目采購管理
十：項目干系人管理
風溝采人【瘋狗踩人】是輔助知識領域，項目目標是通過他們的輔助而實現的。

整體形成整合管理。

優秀項目經理應該具備的素質（廣博的知識、豐富的經歷、良好的協調、職業道德、溝通表達、領導）項目經理必須承擔管理者和領導者的雙重角色。真正理解項目經理的角色、重視項目團隊的管理，懲罰分明、計劃、計劃、再計劃、真正理解軟件工程，注重用戶參與。

項目的概念

1、項目是為提供一項獨特產品、服務或成果所做的臨時性努力。
項目目標包括成果性目標（滿足客戶要求的產品、系統、服務或者成功）和約束性目標（時間、成本質量）。
2、項目的目標特性：1）項目的目標有不同的優先級2）項目目標有層次性
3、項目的特點

特點說明

臨時性（一次性	每一個項目都有確定的開始和結束日期
獨特的產品、服務或成果	創造獨特的可交付成果，如產品、服務或成果
逐步完善	分步、連續的積累。例如，在項目的早期，項目范圍的說明是粗略的，隨著項目團隊對目標和可交付成果的理解更完整和深入時，項目的范圍也就更具體和詳細
資源約束	每一個項目都需要具備各種資源來作為實施的保證，而資源是有限的。所以，資源成本是項目成功實施的一個約束條件。
目的性	項目工作的目的在于得到特定的結果，即項目是面向目標的
4、日常運作和項目也有許多共同之處：由人來做，受制于有限的資源，需要規劃、執行和控制。區分：
①日常運作是持續不斷和重復進行的，而項目是臨時性的、獨特的
②項目和日常運作的目標有本質的不同。項目的目標是實現其目標，然后結束項目，而持續進行的日常運作的目標一般是為了維持經營。
③項目的實現機制與日常運作大相徑庭，因為當宣布的目標實現時，項目就結束了。相比之下，日常運作是確定一組新目標，然后持續進行。
不同	項目
–	–
目的	獨特的
責任人	項目經理
持續時間	有限
持續性	一次
組織結構	項目組織
考核指標	目標為導向
資源需求	多變

5、項目經理經常提到在管理互不相讓的要求時遇到的項目范圍、時間和成本的“三重制約”。項目的質量受這三個因素權衡的不利影響。高質量的項目在預算內按時提交滿足要求的產品、服務或成果。
6、企業戰略是層出不窮的，雖然有多種，但基本屬性是相同的，都是對企業的謀略，都是對企業整體性長期性、基本性問題的計謀。戰略管理包括三個過程：①戰略制定②戰略實施③戰略評價；項目經常被當作實現組織戰略計劃的一種手段使用。
7、典型的信息系統項目的特點：①目標不明確②需求變化頻繁③智力密集型④設計隊伍龐大⑤設計人員高度專業化⑥涉及的承包商多⑦各級承包商分布在各地，相互聯系復雜⑥系統集成項目中需研制開發大量的軟硬件系統項目生命期通常較短⑩通常要采用大量的新技術?使用與維護的要求非常復雜。
8、項目管理就是把各種知識、技能、手段和技術應用于項目活動之中，以達到項目的要求。項目管理是通過應用和綜合諸如啟動、計劃、實施、監控和收尾等項目管理過程來進行的。管理一個項目包括：識別要求確定清楚而又能夠實現的目標；權衡質量、范圍、時間和成本方面互不相讓的要求；使技術規格說明書、計劃和方法適合于各種各樣項目干系人的不同需求與期望等內容。
9、理解項目管理
①項目管理是一種已被公認的管理模式，而不是任意的一次管理過程
②項目管理的對象是項目，即一系列的臨時任務
③項目管理的職能與其他管理的職能是完全一致的
④項目管理職能主要是由項目經理執行的。在一般規模的項目中，項目管理由項目經理帶領少量專職項目管理人員完成，項目組織中的其他人員，包括技術與非技術人員負責完成項目任務，并接受管理。如果項目規模很小，那么項目組織內可以只有一個專職管理人員，即項目經理。

項目組織結構

說明優點缺點

職能型	項目經理無權無資源，所有項目人員還在所屬部門里面供職，僅僅花費小部分的時間來處理項目的事情。還有相應的職能經理，這樣的雙重管理對于項目來說是最可怕的了。當然好處，對公司來說。為這個項目消耗的資源不是很多；對個人來說，還在自己的蘿卜坑職位里面。	1、可以充分發揮職能部門的資源集中優勢 2、部門的專家可以同時為部門內不同項目使用 3、便于相互交流，相互支援，可以隨時增派人員4、可以將項目和本部門的職能工作融為一體	1、項目和部門利益發生沖突，職能部門更重視本部門的目標，會忽視項目目標 2、資源平衡會出現問題 3、權利分割不利于各個職能部門的交流和團結協作 4、行政隸屬關系使得項目經理沒有充分的權利
項目型	將所有的能兵強將集結在一起，財務部、業務部IT管理部等的精英們脫離原有的崗位，形成一個正式的部門，并由項目經理領導。這樣的優勢是項目經理的權利很強、資源充足。對公司而言，單獨團隊對公司整體資源的浪費；對被抽調的個人而言，脫離了原有的崗位。待項目結束之后，精英們將無家可歸。	1、項目經理對項目可以負全責 2、項目目標單一，可以以項目為中心有利于項目順利進行 3、避免多重領導 4、組織結構簡單，交流簡單，快速	1、資源不能共享 2、各個獨立的項目處于相對封閉狀態不利于公司政策的貫徹 3、對項目組織的成員缺少一種事業上的連續性和安全感 4、項目組織之間處于分割狀態，缺少信息交流
矩陣型	兼具項目型和矩陣型的特點；分為弱矩陣，平衡矩陣，強矩陣 項目經理>職能經理=強矩陣 項目經理=職能經理=平衡矩陣 項目經理〈職能經理=弱矩陣	1、專職的項目經理負責整個項目，以項目為中心 2、公司的多個項目可以共享各個職能部門的資源 3、即利于項目目標的實現，又利于公司目標方針的貫徹 4、項目成員的顧慮減少了	1、容易引起職能經理和項目經理權力的沖突 2、資源共享也能引起項目之間的沖突 3、項目成員有多頭領導

職能型弱矩陣平衡矩陣強矩陣項目型

項目經理權力	小or沒有	小	小or中	中or高	高or全權
項目經理角色	聯絡員兼	協調員兼	全職	全職	全職
項目管理行政人員	兼職	兼職	兼職	全職	全職
預算控制人	職能經理	職能經理	混合	項目經理	項目經理
優點	職業路徑清晰、便于知識交流，有利于重復性工作為主的過程管理	資源利用率高，有利于部門協調	同左	同左	項目經理控制度高，利于統一指揮，溝通簡潔方便
缺點	橫向聯系薄弱，部門間溝通協難度大，項目管理發展方向不明確	多頭領導，管理難度大，資源爭奪	同左	同左	重復配置，管理成本高，不利于知識共享
圖源見水印
職能型
矩陣型
項目型

信息系統項目生命周期

1、項目生命周期（產品導向過程）–項目從啟動到收尾所經歷的一系列階段，階段通常按順序排列，有時也會交疊，階段名稱和數量視具體項目而定。（技術工作維度）
例如：建筑項目-可行性硏究、初步設計、詳細設計、施工、移交
軟件項目-需求分析、框架設計、詳細設計、編程、測試、部署、移交
項目通用生命周期-啟動項目；組織與準備；執行項目工作；結束項目
項目管理生命周期（項目管理過程組）-啟動、規劃、執行、監控、收尾（管理工作維度）
產品生命周期-從項目開始到項目結束再到項目產品運行生命終止（退出市場）的全過程。
注意：產品生命周期>項目管理生命周期=項目通用生命周期

2、生命周期結構具有以下特征：
①成本與人力投入在開始時較低，在工作執行期間達到最高，并在項目快要結束時迅速回落。
②風險與不確定性在項目開始時最大，并在項目的整個生命周期中隨著決策的制定與可交付成果的驗收而逐步降低。
③在不顯著影響成本前提下，改變項目產品最終特性的能力在項目開始時最大

3、項目階段都具有以下類似特征：
①各階段的工作重點不同，通常涉及不同的組織，處于不同的地理位置，需要不同的技能組合
②為了成功實現各階段的主要可交付成果或目標，需要對各階段及其活動進行獨特的控制或采用獨特的過程。重復執行全部五大過程組中的過程，可以提供所需的額外控制，并定義階段的邊界。
③階段的結束以作為階段性可交付成果的工作估項目活動，并變更或終止項目（如果必要）的一個當然時點。這個時點可稱為階段關口、里程碑、階段審查、階段門或關鍵決策點。
4、階段與階段的關系有兩種基本類型：①順序關系②交疊關系

瀑布模型

1、瀑布模型是一個經典的軟件生命周期模型，一般將軟件開發分為：可行性分析（計劃）、需求分析、軟件設計（概要設計、詳細設計）、編碼（含單元測試）、測試、運行維護等幾個階段
2、瀑布模型中每項開發活動具有以下特點：–對應結構化開發
①從上一項開發活動接受該項活動的工作對象作為輸入
②利用這一輸入，實施該項活動應完成的工作內容。
③給出該項活動的工作成果，作為輸出傳給下一項開發活動。
④對該項活動的實施工作成果進行評審。
3、適用：需求明確或很少變更的項目；開發團隊比較弱的情況；有厚實的行業實踐基礎；整批一次性交付有利于干系人。

圖來自藍皮書，下同

螺旋模型

螺旋模型是一個演化軟件過程模型將原型實現的迭代特征與線性順序（瀑布）
模型中控制的和系統化的方面結合起來。
使得軟件的增量版本的快速開發成為可能。
①在螺旋模型中，軟件開發是一系列的增量發布。在早期的迭代中，發布的增量可能是一個紙上的模型或原型；在以后的迭代中，被開發系統的更加完善的版本逐步產生；
②四階段（四個象限）：制訂計劃、風險分析、實施工程和客戶評估。螺旋模型強調了風險分析，特別適用于龐大而復雜的、高風險的系統。

迭代模型

4、迭代式開發模型水平方向為時間維，分四個階段：初始、細化、構造、移交，核心工作流從技術角度描述迭代模型的靜態組成部分，包括：業務建模、需求獲取、分析與設計、實現、測試、部署。圖中的陰影部分描述了不同的工作流，在不同的時間段內工作量的不同，幾乎所有的工作流在所有的時間段內均有工作量，只是大小不同而已。

各階段的主要任務如下。
①初始階段：系統地闡述項目的范圍，選擇可行的系統構架，計劃和準備業務案例。
②細化階段：細化構想，細化過程和基礎設施，細化構架并選擇構件。
③構造階段：資源管理、控制和過程最優化，完成構件的開發并依評價標準進行測試，依構想的驗收標準評估產品的發布。
④移交階段：同步并使并發的構造增量集成到一致的實施基線中，與實施有關的工程活動根據完整的構想和需求集的驗收標準評估實施基線。

在迭代式的過程中，每個階段都包括不同比例的所有活動重復的循環，屬于“完善型迭代”
適用于：不能完整定義產品的所有需求、計劃多期開發的、在開發早期需求可能有所變化、需要降低項目復雜性的、部分交付有利于千系人的項目。

Ⅴ模型

Ⅴ模型左邊的分別代表了需求分析、概要設計、詳細設計、編碼。右邊的代表單元測試、集成測試、系統測試與驗收測試

①單元測試：驗證軟件單元是否按照單元規格說明（詳細設計說明）正確執行，即保證每個最小的單元能夠正常運行。單元測試一般由開發人員來執行，首先設定最小的測試單元，然后通過設計相應的測試用例來驗證各個單元功能的正確性。
②集成測試：檢査多個單元是否按照系統概要設計描述的方式協同工作主要關注點是系統能夠成功編譯，實現了主要的業務功能，系統各個模塊之間數據能夠正常通信等。
③系統測試：驗證整個系統是否滿足需求規格說明。
④驗收測試：從用戶的角度檢查系統是否滿足合同中定義的需求或者用戶需求。
V模型的特點：
1.Ⅴ模型體現的主要思想是開發和測試同等重要，左側代表的是開發活動，而右側代表的是測試活動。
2.V模型針對毎個開發階段，都有一個測試級別與之相對應。
3.測試依舊是開發生命周期中的階段，與瀑布模型不同的是，有多個測試級別與開發階段對應。
4.Ⅴ模型適用于需求明確和需求變更不頻繁的情形。

原型法

原型法認為在很難一下子全面準確地提岀用戶需求的情況下，首先不要求一定要對系統做全面、詳細的調查、分析，而是本著開發人員對用戶需求的初步理解，先快速開發一個原型系統，然后通過反復修改來實現用戶的最終系統需求。

原型的特點：①實際可行②具有最終系統的基本特征③構造方便、快速，造價低。
原型法的特點在于原型法對用戶的需求是動態響應、逐步納入的，系統分析、設計與實現都是隨著對一個工作模型的不斷修改而同時完成的，相互之間并無明顯界限，也沒有明確分工。系統開發計劃就是一個反復修改的過程。適于用戶需求開始時定義不清、管理決策方法結構化程度不高的系統開發，開發方法更易被用戶接受；但如果用戶配合不好，盲目修改，就會拖延開發過程。
可以將原型分類：①拋棄型原型②進化型原型

敏捷開發模型

1.是一種以人為核心、迭代、循序漸進的開發方法，更強調程序員團隊與業務專家之間的緊密協作、面對面的溝通、頻繁交付新的軟件版本、緊湊而自我組織型的團隊、能夠很好地適應需求變化的代碼編寫和團隊組織方法，也更注重軟件開發中人的作用。
2. Scrum是一種迭代式增量軟件開發過程，通常用于敏捷軟件開發（三個角色、三個物件、四個會議）
3.特點：較小增量、快速迭代（2~4周）、變更驅動、每次交付最有價值成果。
4.適用：小型或中型軟件開發團隊并且客戶的需求模糊或多變。

小結

模型適用范圍

瀑布模型	面向過程的結構化方法；需求明確、很少變更、行業基礎厚實、低風險、計劃驅動
螺旋型	需求不明確的新開發；大型復雜項目；高風險、風險驅動
迭代模型	不能完整定義所有需求；計劃多期開發需要降低項目復雜性的；
增量模型	已有產品升級或新版本開發；對所開發的領域熟悉且已有原型；
敏捷開發	小型或中型軟件開發團隊，井且客的需求模糊或多變。變更驅動
原型化模型	需求不清；結構化要求不高；
統一過程模型	大型軟件項目和開發團隊；用例驅動
噴泉模型	面向對象；對象驅動；
V模型	需求明確和需求變更不頻繁的傳統信息系統

總結

以上是生活随笔為你收集整理的01.项目管理基础的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。