1. 資訊系統專案的生命周期模型

1.1. 瀑布模型

1.1.1. 預測型生命周期、完全計劃驅動型生命周期

1.1.2. 專案需求明確、充分了解擬交付的產品、有厚實的行業實踐基礎、或者整批一次性交付產品有利于干系人

1.2. 迭代模型

1.2.1. 串行執行

1.2.2. 每次迭代涉及的程序都包括不同比例的所有活動

1.2.3. 每個階段都執行一次傳統的、完整的串行程序串

1.2.4. RUP (Rational Unified Process)軟體統一程序

1.2.4.1. 初始階段(Inception)

1.2.4.1.1. 系統地闡述專案的范圍、確定專案的邊界，選擇可行的系統構架，計劃和準備商業檔案

1.2.4.2. 細化階段(Elaboration)

1.2.4.2.1. 分析問題領域，建立健全體系結構并選擇構件，編制專案計劃，淘汰專案中最高風險的元素

1.2.4.3. 構建階段(Construction)

1.2.4.3.1. 一個制造程序，其重點放在管理資源及控制運作以優化成本、進度和質量

1.2.4.4. 交付階段(Transition)

1.2.4.4.1. 確保軟體對最終用戶是可用的

1.2.4.5. 每個階段，從上到下迭代，亦即從核心程序作業流“商業建模” “需求調研” “分析與設計”……執行到“部署”，再從核心支持作業流“配置與變更管理” “專案管理”執行到“環境”完成一次迭代

1.2.4.5.1. 【22上選27】

1.2.5. 組織需要管理不斷變化的目標和范圍，組織需要降低專案的復雜性

1.2.5.1. 【19上選30】

1.2.6. 產品的部分交付有利于一個或多個干系人，且不會影響最侄訓整批可交付成果的交付

1.3. 敏捷方法

1.3.1. 適應型生命周期、或者變更驅動方法

1.3.2. 以人為核心、迭代、循序漸進的開發方法

1.3.2.1. 【22下選26】

1.3.3. 適用于

1.3.3.1. 一開始并沒有或不能完整地確定出需求和范圍的專案

1.3.3.2. 需要應對快速變化的環境

1.3.3.3. 需求和范圍難以事先確定

1.3.3.4. 能夠以有利于干系人的方式定義較小的增量改進

1.3.4. 目的在于應對大量變更，獲取干系人的持續參與

1.4. V模型

1.4.1. 標明了測驗程序中存在的不同級別

1.4.2. 單元測驗的主要目的是針對編碼程序中可能存在的各種錯誤

1.4.3. 集成測驗主要目的是針對詳細設計中可能存在的問題

1.4.4. 系統測驗主要針對概要設計，檢查系統作為一個整體是否有效地得到運行

1.4.5. 驗收測驗通常由業務專家或用戶進行，以確認產品能真正符合用戶業務上的需要

1.5. 原型化模型

1.5.1. 為彌補瀑布模型的不足而產生的

1.5.1.1. 減少了瀑布模型中因為軟體需求不明確而給開發作業帶來的風險

1.6. 螺旋模型

1.6.1. 一個演化軟體程序模型

1.6.2. 將原型實作的迭代特征與線性順序（瀑布）模型中控制的和系統化的方面結合起來

1.6.3. 一系列的增量發布

1.6.4. 強調了風險分析，特別適用于龐大而復雜的、高風險的系統

2. 單個專案的管理程序

2.1. 專案管理是指在專案活動中綜合運用知識、技能、工具和技術以確保達成專案目標

2.2. 4種程序

2.2.1. 技術類程序

2.2.1.1. 工程類程序

2.2.1.2. 解決“研制特定產品、完成特定成果或提交特定服務的具體技術程序”

2.2.2. 管理類程序

2.2.2.1. 啟動、計劃、執行、監控和收尾程序組

2.2.3. 支持類程序

2.2.3.1. 配置管理程序

2.2.4. 改進類程序

2.2.4.1. 總結經驗教訓、部署改進

3. PDCA回圈(Plan-Do-Check-Act cycle）

3.1. 戴明環

4. 啟動程序組

4.1. 定義并批準專案或階段

4.2. 選定專案經理

4.3. 識別干系人

4.3.1. 【19下選27】

4.4. 啟動程序組是由正式批準開始一個新專案或一個新的專案階段所必需的一些程序組成的，很多啟動型別的程序經常會超出專案范圍，而受組織、大型專案或專案組合管理程序控制，

4.5. 根據制定專案章程(啟動程序組)的輸入有作業說明書

4.6. 【22上選26】

5. 計劃編制程序組

5.1. 定義和細化目標，規劃最佳的技術方案和管理計劃

5.2. 專案管理計劃不是一成不變的，它是漸進明細、逐步深入具體的

5.2.1. “滾動波浪計劃”方法

5.2.2. 近期的作業計劃得較細，遠期的作業計劃得較粗

6. 執行程序組

6.1. 整合人員和其他資源，在專案的生命期或某個階段執行專案管理計劃，并得到輸出與成果

6.2. 執行程序組會花掉多半的專案預算

6.2.1. 【20下選27】

6.3. 指導與管理專案作業、質量保證、組建專案團隊建設、項日團隊、管理專案團隊、管理溝通、實施采購、管理干系人參與

6.3.1. 【21上選27】

6.3.1.1. 【19上選31】

7. 監督與控制程序組（監控程序組）

7.1. 定期測量和監控進展、識別實際績效與專案管理計劃的偏差、必要時采取糾正措施，或管理變更以確保專案或階段目標達成

7.2. 對照專案管理計劃來監督正在進行的專案活動

7.3. 控制變更，推薦糾正措施，或者對可能出現的問題推薦預防措施

7.4. 對引起整體變更控制的因素施加影響，使得只有經批準的變更才被實施

8. 收尾程序組

8.1. 正式接受產品、服務或作業成果，有序地結束專案或階段

8.2. 正式終止專案或專案階段的所有活動

8.3. 將完成的產品遞交給他人所必需的各個程序

9. 不是所有的專案都需要所有的程序一樣

10. 專案資訊

10.1. 作業績效資料

10.1.1. 在執行專案作業的程序中，從每個正在執行的活動中收集到的原始觀察結果和測量值

10.2. 作業績效資訊

10.2.1. 從各控制程序中收集并結合相關背景和跨領域關系，進行整合分析而得到的績效資料

10.3. 作業績效報告

10.3.1. 為制定決策、提出問題、采取行動或引起關注，而匯編作業績效資訊，所形成的實物或電子專案檔案

轉載請註明出處，本文鏈接：https://www.uj5u.com/gongcheng/550050.html

標籤：其他

上一篇：希望所有計算機專業同學看到這篇大一規劃

下一篇：希望所有計算機專業同學看到這篇大一規劃

學系統集成專案管理工程師（中項）系列04c_專案管理一般知識（下）

1. 資訊系統專案的生命周期模型

1.1. 瀑布模型

1.1.1. 預測型生命周期、完全計劃驅動型生命周期

1.1.2. 專案需求明確、充分了解擬交付的產品、有厚實的行業實踐基礎、或者整批一次性交付產品有利于干系人

1.2. 迭代模型

1.2.1. 串行執行

1.2.2. 每次迭代涉及的程序都包括不同比例的所有活動

1.2.3. 每個階段都執行一次傳統的、完整的串行程序串

1.2.4. RUP (Rational Unified Process)軟體統一程序

1.2.4.1. 初始階段(Inception)

1.2.4.1.1. 系統地闡述專案的范圍、確定專案的邊界，選擇可行的系統構架，計劃和準備商業檔案

1.2.4.2. 細化階段(Elaboration)

1.2.4.2.1. 分析問題領域，建立健全體系結構并選擇構件，編制專案計劃，淘汰專案中最高風險的元素

1.2.4.3. 構建階段(Construction)

1.2.4.3.1. 一個制造程序，其重點放在管理資源及控制運作以優化成本、進度和質量

1.2.4.4. 交付階段(Transition)

1.2.4.4.1. 確保軟體對最終用戶是可用的

1.2.4.5. 每個階段，從上到下迭代，亦即從核心程序作業流“商業建模” “需求調研” “分析與設計”……執行到“部署”，再從核心支持作業流“配置與變更管理” “專案管理”執行到“環境”完成一次迭代

1.2.4.5.1. 【22上選27】

1.2.5. 組織需要管理不斷變化的目標和范圍，組織需要降低專案的復雜性

1.2.5.1. 【19上選30】

1.2.6. 產品的部分交付有利于一個或多個干系人，且不會影響最侄訓整批可交付成果的交付

1.3. 敏捷方法

1.3.1. 適應型生命周期、或者變更驅動方法

1.3.2. 以人為核心、迭代、循序漸進的開發方法

1.3.2.1. 【22下選26】

1.3.3. 適用于

1.3.3.1. 一開始并沒有或不能完整地確定出需求和范圍的專案

1.3.3.2. 需要應對快速變化的環境

1.3.3.3. 需求和范圍難以事先確定

1.3.3.4. 能夠以有利于干系人的方式定義較小的增量改進

1.3.4. 目的在于應對大量變更，獲取干系人的持續參與

1.4. V模型

1.4.1. 標明了測驗程序中存在的不同級別

1.4.2. 單元測驗的主要目的是針對編碼程序中可能存在的各種錯誤

1.4.3. 集成測驗主要目的是針對詳細設計中可能存在的問題

1.4.4. 系統測驗主要針對概要設計，檢查系統作為一個整體是否有效地得到運行

1.4.5. 驗收測驗通常由業務專家或用戶進行，以確認產品能真正符合用戶業務上的需要

1.5. 原型化模型

1.5.1. 為彌補瀑布模型的不足而產生的

1.5.1.1. 減少了瀑布模型中因為軟體需求不明確而給開發作業帶來的風險

1.6. 螺旋模型

1.6.1. 一個演化軟體程序模型

1.6.2. 將原型實作的迭代特征與線性順序（瀑布）模型中控制的和系統化的方面結合起來

1.6.3. 一系列的增量發布

1.6.4. 強調了風險分析，特別適用于龐大而復雜的、高風險的系統

2. 單個專案的管理程序

2.1. 專案管理是指在專案活動中綜合運用知識、技能、工具和技術以確保達成專案目標

2.2. 4種程序

2.2.1. 技術類程序

2.2.1.1. 工程類程序

2.2.1.2. 解決“研制特定產品、完成特定成果或提交特定服務的具體技術程序”

2.2.2. 管理類程序

2.2.2.1. 啟動、計劃、執行、監控和收尾程序組

2.2.3. 支持類程序

2.2.3.1. 配置管理程序

2.2.4. 改進類程序

2.2.4.1. 總結經驗教訓、部署改進

3. PDCA回圈(Plan-Do-Check-Act cycle）

3.1. 戴明環

4. 啟動程序組

4.1. 定義并批準專案或階段

4.2. 選定專案經理

4.3. 識別干系人

4.3.1. 【19下選27】

4.4. 啟動程序組是由正式批準開始一個新專案或一個新的專案階段所必需的一些程序組成的，很多啟動型別的程序經常會超出專案范圍，而受組織、大型專案或專案組合管理程序控制，

4.5. 根據制定專案章程(啟動程序組)的輸入有作業說明書

4.6. 【22上選26】

5. 計劃編制程序組

5.1. 定義和細化目標，規劃最佳的技術方案和管理計劃

5.2. 專案管理計劃不是一成不變的，它是漸進明細、逐步深入具體的

5.2.1. “滾動波浪計劃”方法

5.2.2. 近期的作業計劃得較細，遠期的作業計劃得較粗

6. 執行程序組

6.1. 整合人員和其他資源，在專案的生命期或某個階段執行專案管理計劃，并得到輸出與成果

6.2. 執行程序組會花掉多半的專案預算

6.2.1. 【20下選27】

6.3. 指導與管理專案作業、 質量保證、 組建專案團隊建設、項日團隊、 管理專案團隊、 管理溝通、實施采購、 管理干系人參與

6.3.1. 【21上選27】

6.3. 指導與管理專案作業、質量保證、組建專案團隊建設、項日團隊、管理專案團隊、管理溝通、實施采購、管理干系人參與