軟考2.0

阿新 • • 發佈：2020-10-20

不過，可以重複免費報名

02、案例分析、常見專案管理名詞（後續看）

題型介紹
- 中級4個題目滿分均為75分
- 案例分析的題型一般是：
  1. 問答、計算
    - 問答
      - 一般是：找錯、改錯、提升，還有一些很“難，難在基礎知識的默寫。這對於我們成年人來說，確實不應該了
    - 計算
      - 一定要做對
  2. 可能還有；填空、判斷、連線、選擇等。
    - 選擇：
      - 一定要選多個

03、資訊化知識（選擇題）

1.1資訊與資訊化

1.1.1資訊

資訊只有流動起來才能體現其價值，因此資訊的傳輸技術（通常指通訊、網路等）是資訊科技的核心
1. 信源：產生資訊的實體，資訊產生後，由這個實體向外傳播傳送者
2. 信宿：資訊的歸宿或接受者接受者
3. 通道：傳送資訊的通道。傳播途徑（網路）
4. 編碼器：在資訊理論中是泛指所有變換訊號的裝置聲音–>模擬訊號
5. 譯碼器：是編碼器的逆變換裝置，把通道上送來的訊號信宿能接受的訊號，可包括解調器、譯碼器、數模轉換器等模擬訊號–>聲音
6. 噪聲：噪聲可以理解為干擾。干擾
資訊的質量屬性==（這幾個名詞是什麼意思）==
1. 精確性，對事物狀態描述的精準程度。
2. 完整性，對事物狀態描述的全面程度，完整資訊應包括所有重要事實
3. 可靠性，指資訊的來源、採集方法、傳輸過程是可以信任的，符合預期
4. 及時性，指獲得資訊的時刻與事件發生時刻的間隔長短。昨天的天氣資訊不論怎樣精確、完整，對指導明天的穿衣並無幫助，從這個角度出發，這個資訊的價值為零天氣預報
5. 經濟性，指資訊獲取
  
  、傳輸帶來的成本在可以接受的範圍之內
6. 可驗證性，指資訊的主要質量屬性可以被證實或者證偽的程度
7. 安全性，指在資訊的生命週期中，資訊可以被非授權訪問的可能性，安全性越高。

1.1.2資訊系統（軟體）

一般而言，系統具有以下幾個特點==（這幾個名詞是什麼意思）==
1. 目的性。定義一個系統、組成一個系統或者抽象出一個系統，都有明確的目標或者目的，目標性決定了系統的功能。有目標
2. 可巢狀性。系統可以包括若干子系統，系統之間也能夠耦合成一個更大的系統。換句話說，組成系統的部件也可以是系統。這個特點便於對系統進行分層、分部管理、研究或者建設。
3. 穩定性。系統的穩定性是指:受規則的約束，系統的內部結構和秩序應是可以預見的;系統的狀態以及演化路徑有限並能被預測;系統的功能發生作用導致的後果也是可以預估的。穩定性強的系統使得系統在受到外部作用的同時，內部結構和秩序仍然能夠保持。穩定
4. 開放性。系統的開放性是指系統的可訪問性。這個特性決定了系統可以被外部環境識別，外部環境或者其他系統可以按照預定的方法，使用系統的功能或者影響系統的行為。系統的開放性體現在系統有可以清晰描述並被準確識別、理解的所謂介面層面上。開放
5. 脆弱性。這個特性與系統的穩定性相對應，即系統可能存在著喪失結構、功能、秩序的特性，這個特性往往是隱藏不易被外界感知的。脆弱性差的系統，一旦被侵入，整體性會被破壞，甚至面臨崩潰，系統瓦解。可能不穩定
6. 健壯性。當系統面臨干擾、輸入錯誤、入侵等因素時，系統可能會出現非預期的狀態而喪失原有功能、出現錯誤甚至表現出破壞功能。系統具有的能夠抵禦出現非預期狀態的特性稱為健壯性，也叫魯棒性（robustness)。要求具有高可用性的資訊系統，會採取冗餘技術、容錯技術、身份識別技術、可靠性技術等來抵禦系統出現非預期的狀態，保持系統的穩定性。很安全
==*==軟體的生命週期通常包括（要知道有什麼，順序是怎樣的，每個階段是什麼意思）
1. 可行性分析與專案開發計劃、需求分析、概要設計、詳細設計、編碼、測試、維護
2. 可以簡化為系統規劃（可行性分析與專案開發計劃）、系統分析（需求分析）、系統設計（概要設計、詳細設計）、系統實施(編碼、測試）、執行維護等階段
3. 還可以簡化為立項（系統規劃)、開發（系統分析、系統設計、系統實施)、運維及消亡四個階段，在開發階段不僅包括系統分析、系統設計、系統實施，還包括系統驗收等工作。

1.1.3資訊化

*（標註）資訊化的主體是全體社會成員，包括政府、企業、事業、團體和個人;它的時域是一個長期的過程，它的空域是政治、經濟、文化、軍事和社會的一切領域，它的手段是基於現代資訊科技的先進社會生產工具;它的途經是建立資訊時代的社會生產力，推動社會生產關係及社會上層建築的改革;它的目標是使國家的綜合實力、社會的文明素質和人民的生活質量全面提升。

1.4國家資訊化體系要素

==*（位置+標註）==國家資訊化體系包括
- 上鷹下雞左人右龜，糧倉資源，雲網絡
1. 資訊科技應用是資訊化體系6要素中的龍頭，是國家資訊化建設的主陣地，集中體現了國家資訊化建設的需求和效益。
2. 資訊科技和產業是我國進行資訊化建設的基礎。
3. 資訊化人才是國家資訊化成功之本，對其他各要素的發展速度和質量有著決定性的影響，是資訊化建設的關鍵。
4. 資訊化政策法規和標準規範用於規範和協調資訊化體系各要素之間關係，是國家資訊化快速、持續、有序、健康發展的根本保障。
5. 資訊資源、材料資源和能源共同構成了國民經濟和社會發展的三大戰略資源。資訊資源的開發利用是國家資訊化的核心任務，是國家資訊化建設取得實效的關鍵，也是我國資訊化的薄弱環節。
6. 資訊網路是資訊資源開發利用和資訊科技應用的基礎，是資訊傳輸、交換和共享的必要手段。
我國在“十三五”規劃綱要中，將培育人工智慧、移動智慧終端、第五代行動通訊(5G)、先進感測器等作為新一代資訊科技產業創新重點發展，拓展新興產業發展空間。

1.3電子政務

1.3.1電子政務的概念和內容

電子政務的概念
- 政府辦公中採用了資訊化
==*（辨別材料）==電子政務主要包括如下4個方面
1. 政府間的電子政務（G2G)。（GovernmentToGovernment）
2. 政府對企業的電子政務（G2B)。（GovernmentToBusiness）
3. 政府對公眾的電子政務（G2C)。（GovernmentToCitizen）
4. 政府對公務員（G2E)。（GovernmentToEmployee）

1.4企業資訊化和兩化深度融合

1.4.1 企業資訊化概述

==*（口訣）==企業資訊化結構
1. 產品（服務）層;
2. 作業層;
3. 管理層;
4. 策層。
- 直接面向用戶–>產品服務，底層作業，中層管理，高層決策
我們不能等工業化完成後才開始資訊化或停下工業化只搞資訊化，而是應該抓住網路革命的機遇，通過資訊化促進工業化，通過工業化為資訊化打基礎，走資訊化和工業化並舉、融合、互動、互相促進、共同發展之路。（口訣）
- 工業化和資訊化一起爽
推進企業資訊化發展過程中應遵循以下原則==（辨別材料）==
1. 效益原則
2. “一把手”原則
3. 中長期與短期建設相結合原則
4. 規範化和標準化原則
5. 以人為本的原則

1.4.3 客戶關係管理（CRM）（CustomerRelationshipManager）

*（英文+標註）第一，CRM以資訊科技為手段，但是CRM絕不僅僅是某種資訊科技的應用，它更是一種以客戶為中心的商業策略，CRM注重的是與客戶的交流，企業的經營是以客戶為中心，而不是傳統的以產品或以市場為中心;第二CRM在注重提高客戶的滿意度的同時，一定要把幫助企業提高獲取利潤的能力作為重要指標。
==*（有什麼+有幾個+什麼意思）（賣給誰，怎麼賣，賣了什麼）==客戶資料可以分為描述性、促銷性和交易性資料三大類。
1. 關於描述性資料:這類資料是客戶的基本資訊，如果是個人客戶，一定要涵蓋客戶的姓名、年齡、ID和聯絡方式等;如果是企業客戶，一定要涵蓋企業的名稱、規模、聯絡人和法人代表等。
2. 關於促銷性資料:這類資料是體現企業曾經為客戶提供的產品和服務的歷史資料，主要包括使用者產品使用情況調查的資料、促銷活動記錄資料、客服人員的建議資料和廣告資料等。
3. 關於交易性資料:這類資料是反映客戶對企業做出的回饋的資料，包括歷史購買記錄資料、投訴資料、請求提供諮詢及其他服務的相關資料、客戶建議資料等。訂單資料
==*==CRM應用功能的設計
1. 自動化的銷售
2. 自動化的市場營銷
3. 自動化的客戶服務

1.4.5 電子商務

電子商務的概念
1. 原始電子商務概念
  - 使用電子資訊科技工具進行商務活動。凡使用了諸如電報、電話、廣播、電視、傳真以及計算機、計算機網路等手段、工具和技術進行商務活動，都可以稱之為電子商務。
2. 現代電子商務概念
  - 電子商務通常是指在網路環境下，買賣雙方不需見面，實現網上（線上）交易、線上支付(或者貨到付款)、智慧配送以及相關綜合服務的一切活動，是完全創新的或者在一定程度上模擬傳統商務流程的一種以資訊化手段應用為典型特徵的商業運營模式。
==*（有什麼+圖）==電子商務的基礎設施包括四個，即網路基礎設施、多媒體內容和網路出版的基礎設施、報文和資訊傳播的基礎設施、商業服務的基礎設施。此外，技術標準，政策、法律等是電子商務系統的重要保障和應用環境。
- 1. 網路基礎設施
    - 網路基礎設施主要是資訊傳輸平臺，這個資訊傳輸平臺主要執行TCP/IP網路協議，承載在電信通訊網、有線電視網、專線網路之上，接入方式除了傳統計算機有線網路之外，無線網路（4G或WiFi）也是非常便利和普及的接入技術。
  2. 多媒體內容和網路出版的基礎設施
    - 多媒體內容和網路出版的基礎設施主要負責管理電子商務活動涉及的各種資訊，包括文字、語音影象、視訊等，採用的資訊科技主要包括:
      1. 資料庫及資料庫管理系統，負責多媒體資訊的儲存和管理;
      2. Web伺服器系統，負責資訊的釋出和展示，提供客戶與電子商務系統互動的介面;
      3. 搜尋工具，便於客戶快速準確地找到有關資訊;
      4. 內容和出版管理工具，負責網頁內容的編輯和組織。
  3. 報文和資訊傳播的基礎設施
    - 報文和資訊傳播的基礎設施負責提供傳播資訊的工具和方式，包括電子郵件系統、線上交流系統基於HTTP或HTTPS的資訊傳輸系統、流媒體播放系統等。
  4. 商業服務的基礎設施
    - 商業服務的基礎設施負責提供實現標準的網上商務活動的服務，包括:商品目錄和價格目錄、電子支付閘道器、安全認證等。
  5. 技術標準
    - 技術標準是資訊釋出和傳遞的基礎，是網上資訊一致性的保證。技術標準定義了使用者介面、傳輸協議、資訊釋出標準、安全協議等技術細節。
==*（英語+是什麼）==電子商務的型別
1. 按照交易物件，電子商務模式包括:企業與企業之間的電子商務(B2B）（BusinessToBusiness）、商業企業與消費者之間的電子商務(B2C)（BusinessToCustomer）、消費者與消費者之間的電子商務(C2C）（CustomerToCustomer）。還要加個==企業與行政管理者（政府）==B2A（BusinessToAdministrator）。
2. 電子商務與線下實體店有機結合向消費者提供商品和服務，稱為020（OnlineToOffline）模式。
  - 滴滴打車，美團，消費券，線上付錢線下消費

1.5商業智慧（BI）（BusinessIntelligence）

*（理解技巧）
1. 賣東西，根據收集的資料進行分析，什麼時候多人，決策時應該把自己安排在什麼時間段（需要做出某個決策）
==*（有什麼，是什麼）==商業智慧系統應具有的主要功能
1. 資料倉庫
  - 原始資料長期儲存地
2. 資料ETL
  - 整合，清理，清晰
3. 資料統計輸出（報表）
4. 分析功能
  - 分析一下功能，做出一個決策
==*（有什麼）==商業智慧的實現有三個層次:
- 資料報表、多維資料分析和資料探勘。
OLAP（OnlineAnalyticalProcessing）（線上聯機分析處理）有三種實現方法

1.6新一代資訊科技及應用

1.6.1 大資料（BigData）

*(什麼是大資料)
- 大資料本身沒有價值，需要做一個線上聯機分析處理，並且做一個數據挖掘，進而做出決策才有價值
- 是指無法在可承受的時間範圍內用常規軟體工具進行捕捉、管理和處理的資料集合
*（特點）
- Volume（大量)、Velocity(高速）、Variety(多樣）、Value(價值）、Veracity(真實
  性）
==*（有什麼）==大資料從資料來源經過分析挖掘到最終獲得價值一般需經過5個主要環節
- 包括資料準備、資料儲存與管理、計算處理、資料分析和知識展現。
==*（有什麼產品）==大資料關鍵技術有
1. 大資料儲存管理技術
  - 谷歌BigTable和HadoopHbase等非關係型資料庫(NoSQL)。
2. 大資料並行分析技術
  - 谷歌的MapReduce是主要的大資料分散式平行計算技術之一
  - 開源的分散式平行計算技術Apache HadoopMapReduce

1.6.2雲端計算（CloudComputing）

*（標註）雲端計算是一種基於網際網路的計算方式，通過這種方式，在網路上配置為共享的軟體資源、計算資源、儲存資源和資訊資源可以按需求提供給網上終端裝置和終端使用者。虛擬化是雲的核心
==*（有什麼+是什麼+英語）==按照雲端計算服務提供的資源層次，可以分為laaS、PaaS和SaaS等三種服務型別。
1. laaS(InfrastructureAsAService)(基礎設施即服務)，向用戶提供計算機能力、儲存空間等基礎設施方面的服務。
  - CPU,硬碟
  - 硬體
2. PaaS(PlatformAsAService)(平臺即服務)，向用戶提供虛擬的作業系統、資料庫管理系統、Web應用等平臺化的服務。
  - 作業系統，資料庫
  - 與行業無關
3. SaaS（SoftwareAsAService）(軟體即服務），向用戶提供應用軟體（如CRM、辦公軟體等）、元件、工作流等虛擬化軟體的服務
  - 淘寶
  - 具體的應用軟體

1.6.3網際網路+（InternetPlus）

*（理解）
- 網際網路+”就是“網際網路+各個傳統行業
  - 在網上教育
  - 在網上賣水果

1.6.4智慧城市

*（是什麼）
1. 老傢什麼都沒有，大城市什麼都有
2. 可以滴滴打車，可以叫外賣，可以搖朋友
==*==參考模型
- 功能層
  1. 物聯感知層:提供對城市環境的智慧感知能力，通過各種資訊採集裝置、各類感測器、監控攝像機、GPS終端等實現對城市範圍內的基礎設施、大氣環境、交通、公共安全等方面資訊採集、識別和監測。
    - 採集資訊
  2. 通訊網路層:廣泛互聯，以網際網路、電信網、廣播電視網以及傳輸介質為光纖的城市專用網作為骨幹傳輸網路，以覆蓋全城的無線網路（如WiFi)、移動4G為主要接入網，組成網路通訊基礎設施。
    - 傳輸資訊
  3. 計算與儲存層:包括軟體資源、計算資源和儲存資源，為智慧城市提供資料儲存和計算，保障上層對於資料匯聚的相關需求。
    - 資訊的計算和儲存
  4. 資料及服務支撐層:利用SOA(面向服務的體系架構）、雲端計算、大資料等技術，通過資料和服務的融合，支撐承載智慧應用層中的相關應用，提供應用所需的各種服務和共享資源。
    - 提供服務支援
  5. 智慧應用層:各種基於行業或領域的智慧應用及應用整合，如智慧交通、智慧家政、智慧園區、智慧社群、智慧政務、智慧旅遊、智慧環保等，為社會公眾、企業、城市管理者等提供整體的資訊化應用和服務。
    - 具體的應用
- 支撐體系
  1. 安全保障體系:為智慧城市建設構建統一的安全平臺，實現統一入口、統一認證、統一授權、日誌記錄服務。
    - 構建一個安全的平臺
  2. 建設和運營管理體系︰為智慧城市建設提供整體的運維管理機制，確保智慧城市整體建設管理和可持續執行。
    - 確保可持續的執行
  3. 標準規範體系:標準規範體系用於指導和支撐我國各地城市資訊化使用者、各行業智慧應用資訊系統的總體規劃和工程建設，同時規範和引導我國智慧城市相關IT產業的發展，為智慧城市建設、管理和執行維護提供統一規範，便於互聯、共享、互操作和擴充套件。
    - 做一個標準，便於拓展

04、資訊系統整合及服務管理（選擇題）

2.3ITIL 與 IT 服務管理、 ITSS 與資訊科技服務、 IT系統審計

2.3.2 ITSS資訊科技服務標準（InformationTechnologyServiceStandards,）

==*==ITSS原理
1. ==（有幾個+是什麼+英文）==組成要素。IT服務由人員、流程、技術和資源組成，簡稱PPTR。
  - 人員
    - IT服務需要人的知識
  - 流程
    - 合理利用資源
  - 技術
    - IT服務創造者應該具備的技術能力
  - 資源
    - IT服務需要的資源
2. ==（有幾個+是什麼）==生命週期。IT服務生命週期由規劃設計、部署實施、服務運營、持續改進和監督管理5個階段組成
  - 規劃設計:
    - 從客戶業務戰略出發，以需求為中心，參照ITSS對IT服務進行全面系統的戰略規劃和設計，為IT服務的部署實施做好準備，以確保提供滿足客戶需求的IT服務;
  - 部署實施:
    - 在規劃設計基礎上，依據ITSS建立管理體系、部署專用工具及服務解決方案;
  - 服務運營:
    - 根據服務部署情況，依據ITSS，採用過程方法，全面管理基礎設施、服務流程、人員和業務連續性，實現業務運營與IT服務運營融合;
  - 持續改進:
    - 根據服務運營的實際情況，定期評審IT服務滿足業務運營的情況，以及IT服務本身存在的缺陷，提出改進策略和方案，並對IT服務進行重新規劃設計和部署實施，以提高IT服務質量;
  - 監督管理:
    - 本階段主要依據ITSS對IT服務服務質量進行評價，並對服務供方的服務過程、交付結果實施監督和績效評估。

2.3.3資訊系統審計

==*（什麼是審計）==資訊系統審計的目的是評估並提供反饋、保證及建議（事後做一個評估）
1. 可用性;商業高度依賴的資訊系統能否在任何需要的時刻提供服務﹖資訊系統是否被完好保護以應對各種損失和災難?
2. 保密性:系統儲存的資訊是否僅對需要這些資訊的人員開放，而不對其他任何人開放?
3. 完整性:資訊系統提供的資訊是否始終保持正確、可信、及時?能否防止未授權的對系統資料和軟體的修改?
==*==事件和問題
- 事件
  - 偶爾遲到
- 問題
  - 經常遲到

05、資訊系統整合專業技術知識（選擇題）

3.1資訊系統建設

3.1.1資訊資訊的生命週期

==*（有什麼+是什麼）==資訊系統的生命週期可以分為立項、開發、運維及消亡四個階段。
1. 立項階段:
  - 即概念階段或需求階段，這一階段根據使用者業務發展和經營管理的需要，提出建設資訊系統的初步構想;然後對企業資訊系統的需求進行深入調研和分析，形成《需求規格說明書》（SRS）（SpecificationsForRequirements.）並確定立項。（確定要做專案）
2. 開發階段:
  - 以立項階段所做的需求分析為基礎，進行總體規劃。之後，通過系統分析、系統設計、系統實施、系統驗收等工作實現並交付系統。（實現系統）
3. 運維階段:
  - 資訊系統通過驗收，正式移交給使用者以後，進入運維階段。要保障系統正常執行，系統維護是一項必要的工作。系統的執行維護可分為更正性維護、適應性維護、完善性維護、預防性維護等型別。
    - 更正性：有錯誤
    - 適應性：新的環境（蘋果–>win10）（環境已經改變）
    - 完善性：沒有任何問題，想變的更加好，完善功能
    - 預防性：把錯誤扼殺在搖籃中，預防錯誤
4. 消亡階段:
  - 資訊系統不可避免地會遇到系統更新改造、功能擴充套件，甚至廢棄重建等情況。對此，在資訊系統建設的初期就應該注意系統消亡條件和時機，以及由此而花費的成本。
    - 系統不可能一直使用，會被替代

3.1.2資訊系統開發方法

==*（有什麼+是什麼）==常用的開發方法包括結構化方法、原型法、面向物件方法等。
1. 結構化方法:
  1. 是應用最為廣泛的一種開發方法。把整個系統的開發過程分為若干階段，然後依次進行，前一階段是後一階段的工作依據，按順序完成。每個階段和主要步驟都有明確詳盡的文件編制要求，並對其進行有效控制。
  2. 結構化方法的特點是注重開發過程的整體性和全域性性。但其缺點是開發週期長;文件、設計說明繁瑣，工作效率低;﹔要求在開發之初全面認識系統的需求，充分預料各種可能發生的變化，但這並不十分現實。
  3. 結構化方法的模型是瀑布模型
  - 可行性分析與專案開發計劃、需求分析、概要設計、詳細設計、編碼、測試、維護
    - 一步一步往下做，上一個過程的輸出是下一個過程的輸入，每一個階段結束之後都要進行評審，一開始就要清楚使用者的需求
2. 原型法:
  1. 其認為在無法全面準確地提出使用者需求的情況下，並不要求對系統做全面、詳細的分析，而是基於對使用者需求的初步理解，先快速開發一個原型系統，然後通過反覆修改來實現使用者的最終系統需求。
  2. 原型法的特點在於其對使用者的需求是動態響應、逐步納入的;系統分析、設計與實現都是隨著對原型的不斷修改而同時完成的，相互之間並無明顯界限，也沒有明確分工。原型又可以分為拋棄型原型和進化型原型兩種。
  - 先獲取使用者的基本需求，開發出一個demo，再根據不斷地和客戶交流，開發，交流，形成最終產品
3. 面向物件方法:
  1. 用物件表示客觀事物，物件是一個嚴格模組化的實體，在系統開發中可被共享和重複引用，以達到複用的目的。其關鍵是能否建立一個全面、合理、統一的模型，既能反映需求對應的問題域，也能被計算機系統對應的求解域所接受。
  2. 在系統開發的實際工作中，往往根據需要將多種開發方法進行組合應用，最終完成系統開發的全部任務。
- 實際開發過程中，我們是多種方法混合運用

3.2資訊系統設計

3.2.1方案設計

==*（有什麼+是什麼）==系統方案設計包括總體設計和各部分的詳細設計（物理設計）兩個方面。
1. 系統總體設計:
  - 包括系統的總體架構方案設計、軟體系統的總體架構設計、資料儲存的總體設計、計算機和網路系統的方案設計等。
2. 系統詳細設計:
  - 包括程式碼設計、資料庫設計、人/機介面設計、處理過程設計等。

3.3軟體工程

3.3.1軟體需求分析與定義

==*（好處+標註）==軟體需求
- 是針對待解決問題的特性的描述。所定義的需求必須可以被驗證。
  1. 在資源有限時，可以通過優先順序對需求進行權衡。
  2. 通過需求分析，可以檢測和解決需求之間的衝突;
    - 發現本公司的業務範圍可能不夠那麼寬闊
  3. 發現系統的邊界，並詳細描述出系統需求。
    - 能做什麼，不能做什麼

3.3.2軟體設計、測試與維護

==*（有什麼）==通過軟體設計得到要實現的各種不同模型，並確定最終方案。其可以劃分為軟體架構設計(也叫做高層設計)（概要設計）和軟體詳細設計兩個階段。
==*（是什麼+標註）==軟體測試:測試是為了評價和改進產品質量、識別產品的缺陷和問題而進行的活動。軟體測試是針對一個程式的行為，在有限測試用例集合上，動態驗證是否達到預期的行為。
- 測試不再只是一種僅在編碼階段完成後才開始的活動。現在的軟體測試被認為是一種應該包括在整個開發和維護過程中的活動，它本身是實際產品構造的一個重要部分
- 儘早地和不斷地進行軟體測試，測試用例應當由測試輸入資料和對應的預期輸出結果這兩部分組成。系統測試應儘可能在實際執行使用環境下進行。
  - 既要有條件，又要有結果
- 在測試時大家應該需要注意的一些事項
  1. 程式設計師應避免檢查自己的程式（因為很難發現自己的錯誤）
    - 需要有專業的測試人員
    - 或者是交叉檢查
  2. 在設計測試用例時，應包括合理的輸入條件和不合理的輸入條件
  3. 要充分注意測試中的群集現象。
  4. 經驗表明，測試後程序中殘存的錯誤數目與該程式中已發現的錯誤數目成正比。
  5. 嚴格執行測試計劃，排除測試的隨意性;
  6. 應當對每一個測試結果做全面檢查;妥善儲存測試計劃、測試用例、出錯統計和最終分析報告，為軟體維護提供方便。
  7. 常用的測試方法有黑盒測試和白盒測試。
    - 黑盒測試:不考慮程式的內部結構，主要是在程式的介面上進行測試,它不涉及程式的內部邏輯。除了測試程式外，它還適用於對需要分析階段的軟體文件進行測試。測試用例設計有
      1. 等價類劃分
      2. 邊界值分析
      3. 錯誤推測法
      4. 因果圖
    - 白盒測試:把測試物件看做一個透明的盒子，對程式所有邏輯路徑進行測試。具有代表的邏輯覆蓋包含:
      1. 語句覆蓋
      2. 判斷覆蓋
      3. 條件覆蓋
      4. 判定----條件覆蓋
      5. 條件組合覆蓋
      6. 路徑覆蓋
    - 看到覆蓋，就是白盒
  8. 軟體測試是由一系列不同的測試所組成的，可以分為:單元測試、整合測試、確認測試、系統測試。
    1. 單元測試—模組測試:是對每個模組進行測試。要理解驅動模組和樁模組。主要目的是針對編碼過程中可能存在的各種錯誤，例如使用者輸入驗證過程中的邊界值的錯誤。
      - 每個功能開發完後，就做測試
    2. 整合測試:在單元測試的基礎上，將所有模組按照設計要求組裝成系統，必須精心計劃，應提交整合測試計劃、整合測試規格說明書和整合測試分析報告。主要目的是針對詳細設計中可能存在的問題，尤其是檢查各單元與其他程式部分之間的介面上可能存在的錯誤。
      - 各個功能開發完後，統一起來做的測試
    3. 確認測試:驗證軟體的功能、效能以及其他特性是否與使用者的要求一致。
      - 測試是否和需求一致
    4. 系統測試:將軟體放在整個計算機環境下，在實際執行環境中進行一系列的測試，發現軟體與系統定義不符合或矛盾的地方。
      1. α測試:是在開發環境進行的測試
        內部測試–>內側
      2. β測試:是使用者在實際環境中進行的測試，開發者不在旁邊。
        公開測試–>公測
      - 對百花齊放的系統適應做測試
    5. 驗收測試
      - 甲方的人來做測試
    6. 迴歸測試是指修改了舊程式碼後，重新進行測試以確認修改沒有引入新的錯誤或導致其他程式碼產生錯誤。在給定的預算和進度下，儘可能有效率地進行迴歸測試，需要對測試用例庫進行維護並依據一定的策略選擇相應的迴歸測試包。對測試用例庫的維護通常包括刪除過時的測試用例、改進不受控制的測試用例、刪除冗餘的測試用例、增添新的測試用例等。在軟體生命週期中，即使一個得到良好維護測試用例庫也可能變得相當大，這使每次迴歸測試都重新執行完整的測試包變得不切實際，時間和成本約束可能阻礙執行這樣一個測試，又是測試組不得不選擇一個縮減的迴歸測試包來完成迴歸測試。
      - 通過測試，發現了問題，整改，然後進行迴歸測試
    7. 模糊測試是指將一個隨機的、非預期的資料來源作為程式的輸入，然後系統地找出這些輸入所引起的程式失效。通過模糊測試，你將會搶在別人之前來揭示軟體易受攻擊的弱點。模糊測試現在已經發展成為一種最有效的軟體安全性測試方法。
      - 瞎測

3.3.3軟體質量保證及質量評價

*（有什麼+是什麼+標註）軟體質量指的是軟體特性的總和，是軟體滿足使用者需求的能力，即遵從使用者需求，達到使用者滿意。
- 軟體質量包括“內部質量”“外部質量”和“使用質量”三部分。
  1. 內部人員
  2. 外部人員
  3. 使用人員
*(區別+標註)驗證與確認︰確定某一活動的產品是否符合活動的需求，最終的軟體產品是否達到其意圖並滿足使用者需求。驗證過程試圖確保活動的輸出產品已經被正確構造，即活動的輸出產品滿足活動的規範說明;確認過程則試圖確保構造了正確的產品，即產品滿足其特定的目的。
- 驗證注重結果，確認注重過程
==*(區別+標註)==評審與審計:
- 包括管理評審、技術評審、檢查、走查、審計等。
  1. 管理評審的目的是監控進展，決定計劃和進度的狀態，或評價用於達到目標所用管理方法的有效性。
  2. 技術評審的目的是評價軟體產品，以確定其對使用意圖的適合性。
  - 管理層和技術層
- 軟體審計的目的是提供軟體產品和過程對於可應用的規則、標準、指南、計劃和流程的遵從性的獨立評價。審計是正式組織的活動，識別違例情況，並要生成審計報告，採取更正性行動。
  - 產生獨立評價

3.3.5軟體過程管理

==*（有什麼+是什麼+標註）==程管理涉及技術過程和管理過程，通常包括以下幾個方面。
1. 專案啟動與範圍定義:啟動專案並確定軟體需求。
2. 專案規劃:制訂計劃，其中一個關鍵點是確定適當的軟體生命週期過程，並完成相關的工作。
3. 專案實施:根據計劃，並完成相關的工作。
4. 專案監控與評審:確認專案工作是否滿足要求，發現問題並解決問題。
5. 專案收尾與關閉:為了專案結束所做的活動。需要專案驗收，並在驗收後進行歸檔、事後分析和過程改進等活動。
- 開啟一個專案，確認專案要幹什麼，計劃怎麼做專案，開發專案，檢測專案，收尾專案

3.3.7軟體複用

==*（標註）==軟體複用是指利用已有軟體的各種有關知識構造新的軟體，以縮減軟體開發和維護的費用。複用是提高軟體生產力和質量的一種重要技術。
軟體複用的主要思想是，將軟體看成是由不同功能的“元件”所組成的有機體。
- 不同的模組的結合看出一個整體–>元件
早期的軟體複用主要是程式碼級複用，被複用的知識專指程式，後來擴大到包括領域知識、開發經驗、設計決策、架構、需求、設計、程式碼和文件等一切有關方面。
拿來即用

3.4面向物件系統分析與設計

3.4.1面向物件的基本概念

==*（有什麼+是什麼+標註）==面向物件的基本概念包括物件、類、抽象、封裝、繼承、多型、介面、訊息、元件、複用和模式等。
1. 物件∶由資料及其操作所構成的封裝體，是系統中用來描述客觀事物的一個模組，是構成系統的基本單位。物件是由一組屬性和對這組屬性進行的操作構成的。物件包含三個基本要素，分別是物件標識、物件狀態和物件行為。
  - 老師的名字
  - 老師的年齡
  - 老師的教書
2. 類:現實世界中實體的形式化描述，類將該實體的屬性（資料）和操作（函式）封裝在一起。類和物件的關係可理解為，物件是類的例項，類是物件的模板。如果將物件比作房子，那麼類就是房子的設計圖紙。
3. 抽象︰通過特定的例項抽取共同特徵以後形成概念的過程。物件是現實世界中某個實體的抽象，類是一組物件的抽象。
4. 封裝:將相關的概念組成一個單元模組，並通過一個名稱來引用它。面向物件封裝是將資料和基於資料的操作封裝成一個整體物件，對資料的訪問或修改只能通過物件對外提供的介面進行。
5. 繼承:表示類之間的層次關係，父類與子類這種關係使得某類物件可以繼承另外一類物件的特徵，繼承
  又可分為單繼承和多繼承。
6. 多型∶使得在多個類中可以定義同一個操作或屬性名，並在每個類中可以有不同的實現。多型使得某個
  屬性或操作在不同的時期可以表示不同類的物件特性。
7. 介面:描述對操作規範的說明。
8. 訊息︰體現物件間的互動，通過它向目標物件傳送操作請求。
9. 元件:表示軟體系統可替換的、物理的組成部分，封裝了模組功能的實現。元件應當是內聚的，並具有相對穩定的公開介面。
10. 複用︰指將己有的軟體及其有效成分用於構造新的軟體或系統。元件技術軟體複用實現的關鍵。
11. 模式:描述了一個不斷重複發生的問題，以及該問題的解決方案。其包括特定環境、問題和解決方案三個組成部分。應用設計模式可以更加簡單和方便地去複用成功的軟體設計和架構，從而幫助設計者更快更好地完成系統設計。

3.4.2統一建模語言與視覺化建模

統一建模語言(UML）用於對軟體進行視覺化描述、構造和建立軟體系統的文件。UML適用於各種軟體開發方法、軟體生命週期的各個階段、各種應用領域以及各種開發工具。
UML是一種視覺化的建模語言，而不是程式語言。它比較適合用於迭代式的開發過程，是為支援大部分現存的面向物件開發過程而設計的，
RUP是使用面向物件技術進行軟體開發的最佳實踐之一

3.5軟體架構

3.5.2軟體架構模式

C/S客戶/伺服器模式
B/S瀏覽器/伺服器模式

3.5.4軟體中介軟體

中介軟體是位於硬體、作業系統等平臺和應用之間的通用服務。藉由中介軟體,解決了分佈系統的異構問題。其主要目的是實現應用與平臺的無關性。藉助中介軟體，遮蔽作業系統和網路協議的差異，為應用程式提供多種通訊機制,滿足不同領域的應用需要。
==*（功能+典型產品）==中介軟體的分類
1. 資料庫訪問中介軟體:通過一個抽象層訪問資料庫，從而允許使用相同或相似的程式碼訪問不同的資料庫資源。典型技術如Windows平臺的ODBC和Java平臺的JDBC等。
2. 遠端過程呼叫中介軟體(RPC):是一種分散式應用程式的處理方法。一個應用程式可以使用RPC來“遠端”執行一個位於不同地址空間內的過程，從效果上看和執行本地呼叫相同。
3. 面向訊息中介軟體(MOM):利用高效可靠的訊息傳遞機制進行平臺無關的資料傳遞，並可基於資料通訊進行分佈系統的整合。典型產品如DBM的MQSeries。
4. 分散式物件中介軟體:是建立物件之間客戶/伺服器關係的中介軟體，結合了物件技術與分散式計算技術。該技術提供了一個通訊框架，可以在異構分佈計算環境中透明傳遞物件請求。典型產品如OMG的CORBA、Java的RMI/FJB、Microsoft的DCOM等。
5. 事務中介軟體:也稱事務處理監控器(TPM)。TPM位於客戶和伺服器之間，完成事務管理與協調、負載平衡、失效恢復等任務，以提高系統的整體效能。典型產品如IBM/BEA的Tuxedo。

3.6典型應用整合技術

3.6.1資料庫與資料倉庫技術

==*（例子）==資料庫
- 面向業務的
- 12306票數剩餘,實時更新的
==*（例子）==資料倉庫
- 面向主題的資料
- 糧倉，偶爾更新，不是實時更新
*（標註）資料倉庫(Data Warehouse)是一個面向主題的、整合的、相對穩定的、反映歷史變化的資料集合用於支援管理決策。
- 資料倉庫是對多個異構資料來源（包括歷史資料)的有效整合，整合後按主題重組，且存放在資料倉庫中的資料一般不再修改。
- 面向主題
  - 面向某一個主題（人員）
- 整合的
  - 資料倉庫中的資料從資料庫中獲取，而資料庫的格式是雜亂無章的，通過整合之後就變成了一個整體
- 相對穩定的
  - 很長時間才更新一次
- 反應歷史變化
  - 因為資料倉庫可能會儲存N年，所以會反映歷史變化
- 用於支援管理決策的
大資料分析相比於傳統的資料倉庫應用，具有資料量大、查詢分析複雜等特點。
==*（有什麼）==資料倉庫系統結構
1. 資料來源︰是資料倉庫系統的基礎，是整個系統的資料來源泉。
2. 資料的儲存與管理:是整個資料倉庫系統的核心。
3. OLAP伺服器:對分析需要的資料進行有效整合，按多維模型予以組織，以便進行多角度、多層次的分析，並發現趨勢。
4. 前端工具∶主要包括各種查詢工具、報表工具、分析工具、資料探勘工具以及各種基於資料倉庫或資料集市的應用開發工具。其中資料分析工具主要針對OLAP伺服器，報表工具、資料探勘工具主要針對資料倉庫。

3.6.2 Web Services技術

Web服務的典型技術包括:用於傳遞資訊的簡單物件訪問協議(SOAP)、用於描述服務的Web服務描述語言(WSDL)、用於Web服務註冊的統一描述、發現及整合(UDDI)、用於資料交換的XML。
*（標註）Web服務的主要目標是跨平臺的互操作性，適合使用Web Services的情況包括:跨越防火牆、應用程式整合、B2B整合、軟體重用等。同時，在某些情況下，Web服務也可能會降低應用程式的效能。不適合使用Web服務的情況包括:單機應用程式、區域網上的同構應用程式等。

3.6.6元件及其在系統整合專案中的重要性

元件技術就是利用某種程式設計手段，將一些人們所關心的，但又不便於讓終端使用者去直接操作的細節進行封裝，同時實現各種業務邏輯規則，用於處理使用者的內部操作細節。滿足此目的的封裝體被稱作元件。

3.7計算機網路知識

3.7.1網路技術標準與協議

==*（有什麼+有什麼用+有什麼協議）==OSI協議:OSI採用了分層的結構化技術，從下到上共分七層
1. 物理層∶該層包括物理連網媒介，如電纜連線聯結器。該層的協議產生並檢測電壓以便傳送和接收攜帶資料的訊號。具體標準有RS232、V.35、RJ-45、FDDI。
2. 資料鏈路層∶它控制網路層與物理層之間的通訊。它的主要功能是將從網路層接收到的資料分割成特定的可被物理層傳輸的幀。常見的協議有IEEE802.3/.2、HDLC、PPP、ATM。
3. 網路層︰其主要功能是將網路地址（例如，IP地址）翻譯成對應的實體地址（例如，網絡卡地址MAC），並決定如何將資料從傳送方路由到接收方。在TCP/IP協議中，網路層具體協議有IP、ICMP、IGMP、IPX、ARP、RARP等。
4. 傳輸層∶主要負責確保資料可靠、順序、無錯地從A點傳輸到B點。如提供建立、維護和拆除傳送連線的功能;選擇網路層提供最合適的服務;在系統之間提供可靠的透明的資料傳送，提供端到端的錯誤恢復和流量控制。在TCP/IP協議中，具體協議有TCP、UDP、SPX。
5. 會話層:負責在網路中的兩節點之間建立和維持通訊，以及提供互動會話的管理功能，如三種資料流方向的控制，即一路互動、兩路交替和兩路同時會話模式。常見的協議有RPC、SQL、NFS。
6. （檔案格式）表示層∶如同應用程式和網路之間的翻譯官，在表示層，資料將按照網路能理解的方案進行格式化;這種格式化也因所使用網路的型別不同而不同。表示層管理資料的解密加密、資料轉換、格式化和文字壓縮。常見的協議有JPEG、ASC、GIF、DES、MPEG。
7. ==（具體的應用）==應用層∶負責對軟體提供介面以使程式能使用網路服務，如事務處理程式、檔案傳送協議和網路管理等。在TCP/IP協議中，常見的協議有HTTP（網頁）、Telnet（遠端登入）、FTP（檔案傳輸）,SMTP（簡單郵件傳輸）
*
- 802.3（乙太網的協議）
- 802.11（無線區域網WLAN標準協議)。

3.7.2 Internet技術及應用

==*(中英文)==TCP/IP的層次模型分為四層
1. 其最高層相當於OSI的5~7層，該層中包括了所有的高層協議，如常見的檔案傳輸協議FTP(FileTransferProtocol)、電子郵件協議SMTP（SimpleMailTransferProtocol）、域名系統DNS(DomainNameSystem)、網路管理協議SNMP(SimpleNetworkManagementProtocol)、訪問WWW的超文字傳輸協議HTTP等。
2. TCP/IP的次高層相當於OSI的傳輸層，該層負責在源主機和目的主機之間提供端—端的資料傳輸服務。這一層上主要定義了兩個協議:面向連線的傳輸控制協議TCP和無連線的使用者資料報協議UDP。
3. TCP/IP的第二層相當於OSI的網路層，該層負責將分組獨立地從信源傳送到信宿，主要解決路由選擇、阻塞控制及網際互連問題。這一層上定義了互連網協議IP、地址轉換協議ARP（AddressResolutionProtocol）、反向地址轉換協議隊RARP(ReverseAddressResolutionProtocol)和互連網控制報文協議ICMP等協議。
4. TCP/IP的最底層為網路介面層，該層負責將IP分組封裝成適合在物理網路上傳輸的幀格式併發送出去，或將從物理網路接收到的幀卸裝並取出IP分組遞交給高層。這一層與物理網路的具體實現有關，自身並無專用的協議。事實上，任何能傳輸IP分組的協議都可以執行。雖然該層一般不需要專門的TCP/IP協議，各物理網路可使用自己的資料鏈路層協議和物理層協議，但使用序列線路進行連線時仍需要執行SLIP或PPP協議。
==*（標註）==IPv6具有以下顯著優點:
- 16進位制
- 128位
*（標註）Internet上的域名由域名系統DNS統一管理。DNS是一個分散式資料庫系統，由域名空間、域名伺服器和地址轉換請求程式三部分組成
- 域名<–>IP
- 計算機是不認識域名的，需要通過DNS解析成數字

3.7.3網路分類

==*==按照計算機網路所覆蓋的地理範圍的大小進行分類，計算機網路可分為︰區域網、都會網路和廣域網，再加一個網際網路
- 區域網
  - 一個公司
- 都會網路
  - 一個城市
- 廣域網
  - 多個城市/中國
- 網際網路
  - 全球
==*==網路按照拓撲結構劃分有:匯流排型結構、環型結構、星型結構、樹型結構和網狀結構

3.7.5網路交換技術

網路交換是指通過一定的裝置，如交換機等，將不同的訊號或者訊號形式轉換為對方可識別的訊號型別從而達到通訊目的的一種交換形式，常見的有資料交換、線路交換、報文交換和分組交換。

3.7.6網路儲存技術

==*（有什麼+例子）==目前，主流的網路儲存技術主要有三種，分別是直接附加儲存(DAS)（DirectAttachedStorage）、網路附加儲存(NAS)（NetworkAttachedStorage）和儲存區域網路(SAN)（StorageAreaNetwork）。
- DAS:不需要通過網路即可使用，通過硬體的標準介面進行連線，需要通過載入程式才能儲存（U盤）
- NAS:需要通過網路才能儲存,即插即用
- SAN:本來就是一個網路

3.7.8無線網路技術

*（標註）無線網路是指以無線電波作為資訊傳輸媒介。
無線通訊網路根據應用領域可分為∶無線個域網(WPAN)、無線區域網(WLAN)、無線都會網路(WMAN)、蜂房行動通訊網(WWAN) 。
==*（標註）====4G（第四代行動通訊）==包括TD-LTE和FDD-LTE兩種制式
*（標註）5G正在研發中，計劃到2020年推出成熟的標準，理論上可在28GHz超高頻段以1Gbps的速度傳送資料，且最長傳送距離可達2公里。（頻段越高，距離越短，到時候到處都是基站）

3.7.11網路規劃、設計與實施

==*（有什麼+是什麼+標註+例子）==在分層設計中，引入了三個關鍵層的概念，分別是核心層、匯聚層和接入層。
1. 網路中直接面向用戶連線或訪問網路的部分稱為接入層
  - 將位於接入層和核心層之間的分稱為分佈層或匯聚層。接入層的目的是允許終端使用者連線到網路，因此，接入層交換機（或路由器）具有低成本和高階口密度特性。
2. 匯聚層
  - 是核心層和接入層的分介面，完成網路訪問策略控制、資料包處理、過濾、定址，以及其他資料處理的任務。匯聚
3. 網路主幹部分稱為核心層
  - 核心層的主要目的在於通過高速轉發通訊，提供優化、可靠的骨幹傳輸結構，因此，核心層交換機應擁有更高的可靠性，效能和吞吐量。
- 傳銷組織

3.7.12網路安全

==*（字面理解）==資訊保安的基本要素有
1. 機密性:確保資訊不暴露給未授權的實體或程序。
2. 完整性:只有得到允許的人才能修改資料，並且能夠判別出資料是否已被篡改。
3. 可用性︰得到授權的實體在需要時可訪問資料，即攻擊者不能佔用所有的資源而阻礙授權者的工作。
  - 可以用的時候可以用
4. 可控性:可以控制授權範圍內的資訊流向及行為方式。
5. 可審查性:對出現的網路安全問題提供調查的依據和手段。
*（順序）資訊系統安全分為5個等級，分別是︰自主保護級、系統審計保護級、安全標記保護級、結構化保護級、訪問驗證保護級。（自系安結訪）
==*（是什麼）==安全手段
1. 傳統防火牆無法阻止和檢測基於資料內容的黑客攻擊和病毒入侵，同時也無法控制內部網路之間的違規行為。
  - 只能防止外部對內部的攻擊
2. 掃描器可以說是入侵檢測的一種，主要用來發現網路服務、網路裝置和主機的漏洞,當然，掃描器無法發現正在進行的入侵行為，而且它還有可能成為攻擊者的工具
  - 掃描
3. 防毒軟體對於基於網路的攻擊行為(如掃描、針對漏洞的攻擊）卻無能為力。
4. 安全審計系統通過獨立的、對網路行為和主機操作提供全面與忠實的記錄，方便使用者分析與審查事故原因。

3.8新興資訊科技

3.8.2物聯網

物聯網，指通過射頻識別(RFID)、紅外感應器、全球定位系統、鐳射掃描器等資訊感測裝置，按約定的協議，把物與物、人與物進行智慧化連線，進行資訊交換和通訊，以實現智慧化識別、定位、跟蹤、監控和管理的一種新興網路。
- 智慧家居
==*（有什麼+是什麼+標註）==物聯網從架構上面可以分為感知層、網路層和應用層
1. 感知層︰負責資訊採集和物物之間的資訊傳輸，資訊採集的技術包括感測器、條碼和二維碼、RFID射頻技術、音視訊等多媒體資訊，資訊傳輸包括遠近距離資料傳輸技術、自組織組網技術、協同資訊處理技術、資訊採集中介軟體技術等感測器網路。感知層是實現物聯網全面感知的核心能力，是物聯網中包括關鍵技術。
  - 獲取資訊資料
2. 網路層∶是利用無線和有線網路對採集的資料進行編碼、認證和傳輸，廣泛覆蓋的行動通訊網路是實現物聯網的基礎設施，是物聯網三層中標準化程度最高、產業能力最強、最成熟的部分，關鍵在於為物聯網應用特徵進行優化和改進，形成協同感知的網路。
  - 對獲取的資料進行網路化
3. 應用層:提供豐富的基於物聯網的應用，是物聯網發展的根本目標。
  - 對資訊做出反應
  - 智慧家居的實物
*（有什麼）物聯閘道器鍵技術:感知層作為物聯網架構的基礎層面，主要是達到資訊採集並將採集到的資料上傳的目的，感知層的技術主要包括∶產品和感測器（條碼、RFID、感測器等）自動識別技術，無線傳輸技術(WLAN、Bluctooth、ZigBee、UWB)，自組織組網技術和中介軟體技術

3.8.3移動網際網路

==*（是什麼）==移動網際網路一般是指使用者用手機等無線終端，通過3G或者WLAN等速率較高的行動網路接入網際網路，可以在移動狀態下（如在地鐵、公交車上等）使用網際網路的網路資源。
==*（有什麼+是什麼）==移動終端在處理能力、顯示效果、開放性等方面無法和PC相提並論，但在個性化、永遠線上、位置性等方面強於PC。由於移動終端具有小巧輕便、隨身攜帶兩個特點，決定了移動網際網路應用應具有下列新特徵而不是傳統網際網路應用的簡單複製和移植。
1. 接入移動性∶移動終端的便攜性使得使用者可以在任意場合接入網路，移動網際網路的使用場景是動態變化的。
2. 時間碎片性:使用者使用移動網際網路的時間往往是上下班途中、工作之餘、出差等候間隙等碎片時間，資料傳輸具有不連續性和突發性。
3. 生活相關性:移動終端被使用者隨身攜帶，具有唯一號碼，與移動位置關聯等特性使得移動應用可以進入人們的日常生活，滿足衣食住行吃喝玩樂等需求。
4. 終端多樣性:目前各手機廠商分足鼎立，有各自不同的作業系統和底層硬體，終端型別多樣，尚未形成統一的標準化介面協議。
==*（中英文+標註）==SOA（面向服務的架構）WebService是目前實現SOA的主要技術
*（標註）Web 2.0嚴格來說不是一種技術，而是提倡眾人蔘與的網際網路思維模式
HTML5具有高度互動性、豐富使用者體驗以及功能強大的客戶端。
Android、IOS . window Phone大家應該都很熟悉了，瞭解就好

3.8.4大資料

==*（有什麼+是什麼）==大資料關鍵技術
- 大資料所涉及的技術很多，主要包括資料採集、資料儲存、資料管理、資料分析與
  挖掘四個環節。
  1. 在資料採集階段主要使用的技術是資料抽取工具ETL。
  2. 在資料儲存環節主要有Apache的 Hbase。
  3. 大資料管理主要使用了分散式並行處理技術，比較常用的有MapReduce
1. HDFS
  - Hadoop分散式檔案系統（HDFS）是適合執行在通用硬體上的分散式檔案系統，是一個高度容錯性的系統，適合部署在廉價的機器上。HDFS能提供高吞吐量的資料訪問，非常適合大規模資料集上的應用。
2. HBase
  - HBase是一個分散式的、面向列的開源資料庫，該技術來源於Fay Chang所撰寫的Google論文“Bigtable:一個結構化資料的分散式儲存系統”，HBase在 Hadoop之上提供了類似於Bigtable的能力。利用HBase技術可在廉價PC Server上搭建起大規模結構化儲存叢集。HBase不同於一般的關係資料庫，它是一個適合於非結構化資料儲存的資料庫。另一個不同的地方是HBase基於列的而不是基於行的模式。
3. MapReduce
  - MapReduce是一種程式設計模型，用於大規模資料集(大於1TB)的並行運算。概念“Map(對映)”和“Reduce（歸約)”，和它們的主要思想，都是從函數語言程式設計語言裡借來的。它極大地方便了程式設計人員在不會分散式並行程式設計的情況下，將自己的程式執行在分散式系統上，從而實現對HDFS和HBase上的海量資料分析。
4. Chukwa
  - Chukwa是一個開源的用於監控大型分散式系統的資料收集系統。這是構建在
    Hadoop 的 HDFS和Map/Reduce框架之上的，繼承了Hadoop 的可伸縮性和魯棒性。Chukwa還包含了一個強大而靈活的工具集，可用於展示、監控和分析已收集的資料。

3.9補充

==*（口訣）==TCP、UDP協議:前者是可靠的，後者是不可靠的。TCP沒有UDP傳輸的快。
1. TCP：郵件
  - 因為郵件不需要傳送很快
2. UDP：看視訊
  - 不需要很可靠
- 上帝是公平的
“網際網路+”就是“網際網路+各個傳統行業”，但這並不是簡單的兩者相加，而是利用資訊通訊技術以及網際網路平臺，讓網際網路與傳統行業進行深度融合，創造新的發展生態。它代表一種新的社會形態，即充分發揮網際網路在社會資源配置中的優化和整合作用，將網際網路的創新成果深度融合於經濟、社會各域之中，提升全社會的創新力和生產力，形成更廣泛的以網際網路為基礎設施和實現工具的經濟發展新形態。

07、專案管理一般知識（選擇題）

4.1什麼是專案，什麼是專案管理

4.1.1專案的定義

*(標註+例子)專案是為達到特定的目的，使用一定資源，在確定的期間內，為特定發起人提供獨特的產品、服務或成果而進行的一系列相互關聯的活動的集合。專案有完整的生命週期，有開始，有結束，具有一次性、臨時性的特點。
- 軟考
  - 拿證，人力資源，時間，軟考

4.1.2專案目標

==*（區別）==專案目標包括成果性目標和約束性目標。
1. 專案的約束性目標也叫管理性目標，專案的成果性目標有時也簡稱為專案目標。
2. 專案約束性目標是指完成專案成果性目標需要的時間、成本以及要求滿足的質量。
- 一定期限，一定成本
- 拿到證書
==*（是什麼）==專案目標具有如下特性。
1. 專案的目標有不同的優先順序
  - 先達成，後達成
2. 專案目標具有層次性
  - 目標有層次，有大有小

4.1.3專案的特點

==*（有什麼+是什麼）==專案的特點:
1. 臨時性
  - 不表示生命短
  - 只是表示有明確的開始，有明確的的結束
2. 獨特性
  - 任何一個專案都應該是不一樣的
  - 如果建樓，樓塌了，再建，就是另一個專案
3. 漸進明細
  - 一步一步慢慢來

4.1.4資訊系統整合專案的特點

資訊系統整合專案有以下幾個顯著特點。
1. 資訊系統整合專案要以滿足客戶和使用者的需求為根本出發點。
2. 客戶和使用者的需求常常不夠明確、複雜多變，由此應加強需求變更管理以控制風險。
3. 系統整合不是簡單選擇最好產品的行為，而是要選擇（或開發）最適合使用者的需求和投資規模的產品、技術和服務的活動的集合。
4. 高技術與高技術的整合。
5. 系統工程。系統整合包含技術，管理和商務等方面，是一項綜合性的系統工程，需要相關的各方足夠重視，必要時應“一把手”掛帥，並且多方要密切協作。
6. 專案團隊的成員年輕，流動率高。
7. 強調溝通的重要性。
系統整合專案管理既是-一種管理行為又是一種技術行為。

4.1.5專案管理的定義及其知識範圍

所謂專案管理是指在專案活動中綜合運用知識、技能、工具和技術在一定的時間、成本、質量等要求下來實現專案的成果性目標的一系列行為。

4.1.6專案管理需要的專業知識和技術

軟技能包含:
1. 有效的溝通，即有效地交流資訊。
2. 對組織施加影響，即“讓事情辦成”的能力。
3. 領導能力，即形成一個前景和戰略並組織人員實現它的能力。
4. 激勵，就是激勵相關人員達到高水平的生產率並克服變革的阻力。
5. 談判和衝突管理，就是與其他人談判取得一致或達成協議。
6. 分析和綜合歸納能力人
7. 解決問題，就是首先定義問題、明確問題，然後做出決策並解決問題。

4.1.8專案經理應該具備的技能和素質

一個合格的專案經理，至少應當具備如下的素質。
1. 足夠的知識
2. 豐富的專案管理經驗
3. 良好的協調和溝通能力
4. 良好的職業道德
5. 一定的領導和管理能力
怎樣當好一個優秀的專案經理
1. 真正理解專案經理的角色
2. 領導並管理專案團隊
3. 依據專案進展的階段，組織制訂詳細程度適宜的專案計劃，監控計劃的執行，並根據實際情況、客戶要求或其他變更要求對計劃的變更進行管理。
4. 真正理解“一把手工程”
  - 需要領導參與進來
5. 注重客戶和使用者參與

4.1.9專案干係人

==*（是什麼）==專案干係人是指那些積極參與專案，或是其利益會受到專案執行的影響，或是其利益會受到專案結果影響的個人和組織，他們也可能會對專案及其結果施加影響。
- 影響專案的人或組織+被專案影響的人或組織
每個專案的關鍵干係人除客戶和使用者外，還包括如下一些人。
1. 專案經理
2. 執行組織
3. 專案團隊及其成員
4. 專案發起人
  - 為專案提供資金的人
5. 職能經理
6. 影響者
7. 專案管理辦公室（PMO)
專案經理必須管理專案干係人的期望，因為專案干係人經常會有相互不同甚至是衝突的目標
- 各懷鬼胎

4.1.10專案管理系統

專案管理系統是指用於管理專案的工具、技術、方法、資源和過程組之集合
專案管理系統（可以是正式的或非正式的)，有助於專案經理有效地控制專案順利完成

4.1.11事業環境因素

包括下列這幾項主要因素和系統:
1. 實施單位的企業文化和組織結構;
2. 國家標準或行業標準;
3. 現有的設施和固定資產等;
4. 實施單位現有的人力資源、人員的專業和技能，人力資源管理政策如招聘和解聘的指導方針、員工績效評估和培訓記錄等;
5. 當時的市場狀況;
6. 專案干係人對風險的承受力;
7. 行業資料庫;
8. 專案管理資訊系統（可能是工具，也可能是軟體，總之能幫助人們管理專案）
- 專案經理不可以掌控的

4.1.12組織過程資產

組織過程資產包含:
1. 專案實施組織的企業計劃、政策方針、規程、指南和管理系統，實施專案組織的知識和經驗教訓。
  - 以前專案過程積累的經驗和教訓
  - 專案經理可以掌控的

4.2專案的組織方式

4.2.3組織結構

分類
1. 職能型組織（部門型組織）
- 開發部門/資料庫部門
1. 矩陣型組織
  - 雜交：既有職能型，也有專案型
2. 專案型組織
職能型組織的優缺點體現在如下方面。
- 優點
  1. 強大的技術支援，便於知識、技能和經驗的交流。
  2. 清晰的職業生涯晉升路線。
  3. 直線溝通、交流簡單、責任和許可權很清晰。
  4. 有利於重複性工作為主的過程管理。
- 缺點:
  1. 職能利益優先於專案，具有狹隘性
  2. 組織橫向之間的聯絡薄弱、部門間溝通、協調難度大
  3. 專案經理極少或缺少權利、權威;
  4. 專案管理髮展方向不明，缺少專案基準等。
專案型組織的優缺點體現在如下方面。
- 優點
  1. 結構單一，責權分明，利於統一指揮。
  2. 目標明確單一。
  3. 溝通簡潔、方便。
  4. 決策快。
- 缺點:
  1. 管理成本過高，如專案的工作量不足則資源配置效率低;
  2. 專案環境比較封閉，不利於溝通、技術知識等共享;
  3. 員工缺乏事業上的連續型和保障等。
矩陣型組織的優缺點體現在如下方面。
- 缺點∶
  1. 管理成本增加;多頭領導;
  2. 難以監測和控制;
  3. 資源分配與專案優先的問題產生衝突;
  4. 權利難以保持平衡等。

4.2.4 PMO在組織結構中的作用

根據需要，可以為一個專案設立一個PMO，可以為一個部門設立一-個PMO，也可以為一個企業設立一個PMO（專案管理辦公室）（ProjectManagementOffice）。這三級PMO可以在一個組織內可以同時存在。
資訊系統專案的生命週期，如果詳細劃分，一般可劃分為可行性分析、業務流程優化或變革、資訊系統規劃、系統需求分析、系統設計、系統實現、系統測試、系統實施、系統試執行、驗收等階段。而開發完成的資訊系統的生命週期，除包含前期的專案生命週期外，還包括驗收後的協調運營與維護、系統退役等階段。
根據行業特點、企事業單位的規模、專案特點等對這些階段可以有不同程度的增刪和裁剪。

4.3專案生命週期

4.3.1專案生命週期的特徵

軟考2.0.assets/image-20200929203337297.png

軟考2.0.assets/image-20200929203352771.png

成本的變化是指專案變更的成本隨著時間延續而提高
專案干係人的影響是指專案干係人的影響隨著時間延續而減小

都是越早做改變越好

4.3.3專案生命週期與產品生命週期的關係

產品的生命期比專案生命週期更長

4.4典型的資訊系統專案的生命週期模型

==*（是什麼+標註）==瀑布模型中每項開發活動具有以下特點。
1. 從上一項開發活動接受其成果作為本次活動的輸入。
  - 上一次的輸出為下一次的輸入
2. 利用這一輸入，實施本次活動應完成的工作內容。
3. 給出本次活動的工作成果,作為輸出傳給下一項開發活動。
4. 對本次活動的實施工作成果進行評審。若其工作成果得到確認，則繼續進行下一項殲發活動;否則返回前一項，甚至更前項的活動。儘量減少多個階段間的反覆。以相對來說較小的費用來開發軟體。
  - 需要很多評審
5. 一開始就需要知道全部的設計
==*（是什麼+標註）==迭代式開發模型
- 在迭代模型中，每個階段都執行一次傳統的、完整的序列過程串，執行一次過程串就是一次迭代。每次迭代涉及的過程都包括不同比例的所有活動。
- RUP (Rational Unified Process）軟體統一過程是一種“過程方法”，它就是迭代模型的一種。
- 水平方向為時間維，從組織管理的角度描述整個軟體開發生命週期，分四個階段:初始、細化、構造、移交，可進一步描述為週期(Cycle)、階段(Phase)、迭代(Iteration);核心工作流從技術角度描述迭代模型的靜態組成部分，包括:業務建模、需求獲取、分析與設計、實現、測試、部署。圖中的陰影部分描述了不同的工作流，在不同的時間段內工作量的不同，幾乎所有的工作流在所有的時間段內均有工作量，只是大小不同而已。各階段的主要任務如下。
  1. 初始階段:系統地闡述專案的範圍，選擇可行的系統構架，計劃和準備業務案例。
  2. 細化階段:細化構想，細化過程和基礎設施，細化構架並選擇構件。
  3. 構造階段:資源管理、控制和過程最優化，完成構件的開發並依評價標準進行測試，依構想的驗收標準評估產品的釋出。
  4. 移交階段:同步並使併發的構造增量整合到一致的實施基線中，與實施有關的工程活動（商業包裝和生產、人員培訓等），根據完整的構想和需求集的驗收標準評估實施基線。
敏捷方法
- 是一種以人為核心、迭代、循序漸進的開發方法，適用於一開始並沒有或不能完整地確定出需求和範圍的專案，或者需要應對快速變化的環境，或者需求和範圍難以事先確定，或者能夠以有利於干係人的方式定義較小的增量改進。敏捷方法，也叫適應型生命週期、或者變更驅動方法。敏捷方法的目的在於應對大量變更，獲取干係人的持續參與。
*（圖背下來）V模型（序言+膝蓋+吉祥+單邊）
- V模型從整體上看起來，就是一個V字型的結構，由左右兩邊組成。左邊的下畫線分別代表了需求分析、概要設計、詳細設計、編碼。右邊的上畫線代表了單元測試、整合測試、系統測試與驗收測試。V模型的特點如下:
  1. 單元測試的主要目的是針對編碼過程中可能存在的各種錯誤;
  2. 整合測試的主要目的是針對詳細設計中可能存在的問題;
  3. 系統測試主要針對概要設計，檢查系統作為一個整體是否有效地得到執行;
  4. 驗收測試通常由業務專家或者使用者進行，以確認產品能真正符合使用者業務上的需要。
  5. V模型用於需求明確和需求變更不頻繁的情形。
原型化模型
- 原型化模型第一步就是建立一個快速原型，能夠滿足專案干係人與未來的使用者可以與原型進行互動，再通過與相關干係人進行充分的討論和分析，最終弄清楚當前系統的需求，進行了充分的瞭解之後，在原型的基礎上開發出使用者滿意的產品。
螺旋模型
- 是一個演化軟體過程模型，將原型實現的迭代特徵與線性順序(瀑布）模型中控制的和系統化的方面結合起來。開發過程具有周期性重複的螺旋線狀。四個象限分別標誌每個週期所劃分的四階段:制訂計劃、風險分析、實施工程和客戶評估。螺旋模型強調了風險分析，特別適用於龐大而複雜的、高風險的系統。

4.5單個專案的管理過程

4.5.1專案過程

PDCA

4.5.2專案管理過程組

==*（有什麼）==專案過程組包括如下分類。
1. 啟動過程組:定義並批准專案或階段。
2. 計劃編制過程組:定義和細化目標，規劃最佳的技術方案和管理計劃，以實現專案或階段所承擔的目標和範圍。
3. 執行過程組:整合人員和其他資源，在專案的生命期或某個階段執行專案管理計劃，並得到輸出與成果。
4. 監督與控制過程組（監控過程組）︰要求定期測量和監控進展、識別實際績效與專案管理計劃的偏差、必要時採取糾正措施，或管理變更以確保專案或階段目標達成。
5. 收尾過程組:正式接受產品、服務或工作成果，有序地結束專案或階段。
專案或階段收尾時，可能需要進行以下工作:
1. 獲得客戶或發起人的驗收，以正式結束專案或階段;
2. 進行專案後評價或階段結束評價;
3. 記錄裁剪任何過程的影響;
4. 記錄經驗教訓;
5. 對組織過程資產進行適當更新;
6. 將所有相關專案檔案在專案管理資訊系統中歸檔，以便作為歷史資料使用;
7. 結束所有采購活動，確保所有相關協議的完結;
8. 對團隊成員進行評估，釋放專案資源。

專案立項管理包括以下5個典型環節，分別是專案建議、專案可行性分析、專案審批、專案招投標以及專案合同談判與簽訂5個階段。需要說明的是，系統整合供應商在實際工作中更多地參與專案招投標以及專案合同談判與簽訂方面的工作，而對專案建議、專案可行性分析以及專案審批等方面的工作則參與很少，這些方面的工作主要由專案建設單位組織自行完成。

08、專案立項管理（選擇題）

專案立項管理包括以下5個典型環節，分別是專案建議、專案可行性分析、專案審批、專案招投標以及專案合同談判與簽訂5個階段。需要說明的是，系統整合供應商在實際工作中更多地參與專案招投標以及專案合同談判與簽訂方面的工作，而對專案建議、專案可行性分析以及專案審批等方面的工作則參與很少，這些方面的工作主要由專案建設單位組織自行完成。

5.1專案建議

*（標註）專案建議書(RFP)是專案建設單位向上級主管部門提交的專案申請檔案，是對擬建專案提出的總體設想。在專案建議階段，專案要依次完成專案建議書的編寫、申報、審批等環節，然後才能進入後續的專案可行性分析階段的工作。

5.1.1專案建議書

專案建議書，又稱立項申請，是專案建設單位向上級主管部門提交專案申請時所必須的檔案
專案建議書主要內容
1. 專案簡介
2. 專案建設單位概況
3. 專案建設的必要性
4. 業務分析
5. 總體建設方案
6. 本期專案建設方案
7. 環保、消防、職業安全
8. 專案實施進度
9. 投資估算和資金籌措
10. 效益與風險分析

5.1.2專案建議書的編寫、申報和審批

專案建設單位可以規定對於規模較小的系統整合專案省略專案建議書環節，而將其與專案可行性分析階段進行合併。

5.2專案可行性分析

5.2.1專案可行性研究內容

專案可行性研究內容一般應包括以下內容。
1. 投資必要性
2. 技術可行性
3. 財務可行性
  - 從公司盈利出發
4. 組織可行性
5. 經濟可行性
  - 從社會經濟出發
6. 社會可行性
7. 風險因素及對策
可行性研究報告的內容
1. 專案概述
2. 專案建設單位概況
3. 需求分析和專案建設的必要性
4. 總體建設方案
5. 本期專案建設方案
6. 專案招標方案
7. 環保、消防、職業安全
8. 專案組織機構和人員培訓
9. 專案實施迸度
10. 投資估算和資金來源
11. 效益與評價指標分析
12. 專案風險與風險管理
- 選擇關於錢的

5.2.2專案可行性研究階段

==*（是什麼）==機會可行性研究
- 主要任務是對投資專案或投資方向提出建議，並對各種設想的專案和投資機會做出鑑定，其目的是激發投資者的興趣，尋找最佳的投資機會。
  - 提出建議，判定是不是要投資
==*（是什麼+標註）==初步可行性研究
- 是介於機會可行性研究和詳細可行性研究的一箇中間階段，是在專案意向確定之後，對專案的初步估計。如果就投資可能性進行了專案機會研究，那麼專案的初步可行性研究階段往往可以省去。
- 經過初步可行性研究，可以形成初步可行性研究報告。
- ==*（有什麼）==對於不同規模和類別的專案，初步可行性研究可能出現4種結果，即:
  1. 肯定，對於比較小的專案甚至可以直接“上馬”
    - 省略詳細可行性研究
  2. 肯定，轉入詳細可行性研究，進行更深入更詳細的分析研究;
  3. 展開專題研究，如建立原型系統，演示主要功能模組或者驗證關鍵技術;
  4. 否定，專案應該“下馬”。
詳細可行性研究
- 是在初步可行研究基礎上認為專案基本可行，對專案各方面的詳細材料進行全面的蒐集和分析，對不同的專案實現方案進行綜合評判，並對專案建成後的績效進行科學的預測為專案立項決策提供確切的依據。詳細可行性研究需要對一個專案的技術、經濟、環境及社會影響等進行深入調查研究，是一項費時、費力且需一定資金支援的工作，特別是大型的或比較複雜的專案更是如此。
專案評估
- 指在專案可行性研究的基礎上，由第三方(國家、銀行或有關機構）根據國家頒佈的政策、法規、方法、引數和條例等，從專案(或企業)、國民經濟、社會角度出發，對擬建專案建設的必要性、建設條件、生產條件、產品市場需求、工程技術、經濟效益和社會效益等進行評價、分析和論證，進而判斷其是否可行的一個評估過程。專案評估是專案投資前期進行決策管理的重要環節，其目的是審查專案可行性研究的可靠性、真實性和客觀性，為銀行的貸款決策或行政主管部門的審批決策提供科學依據。
  - 看到評估，就是第三方

5.3專案審批

專案審批部門對系統整合專案的專案建議書、可行性研究報告、初步設計方案和投資概算的批覆檔案是後續專案建設的主要依據。
專案可行性研究報告的編制內容與專案建議書批覆內容有重大變更的，應重新報批專案建議書。專案初步設計方案和投資概算報告的編制內容與專案可行性研究報告批覆內容有重大變更或變更投資超出已批覆總投資額度10%的,應重新報批可行性研究報告。專案初步設計方案和投資概算報告的編制內容與專案可行性研究報告批覆內容有少量調整且其調整內容未超出已批覆總投資額度10%的，需在提交專案初步設計方案和投資概算報告時以獨立章節對調整部分進行補充說明。

5.4專案招投標

5.4.1專案招標

==*（有什麼）==有下列情形之一的，可以不進行招標:
1. 需要採用不可替代的專利或者專有技術;
2. 採購人依法能夠自行建設、生產或者提供;
  - 可以自己做
3. 已通過招標方式選定的特許經營專案投資人依法能夠自行建設、生產或者提供;
  - 可以自己做
4. 需要向原中標人採購工程、貨物或者服務，否則將影響施工或者功能配套要求;
  - 需要原班原馬做
5. 國家規定的其他特殊情形。
資格預審檔案或者招標檔案的發售期不得少於5日。招標人發售資格預審檔案、招標檔案收取的費用應當限於補償印刷、郵寄的成本支出，不得以營利為目的。
未通過資格預審的申請人不具有投標資格。通過資格預審的申請人少於3個的，應當重新招標。
招標人採用資格後審辦法對投標人進行資格審查的，應當在開標後由評標委員會按照招標檔案規定的標準和方法對投標人的資格進行審查。
招標人在招標檔案中要求投標人提交投標保證金的，投標保證金不得超過招標專案估算價的2%。投標保證金有效期應當與投標有效期一致。
招標人可以自行決定是否編制標底。一個招標專案只能有一個標底。標底必須保密。
招標人不得組織單個或者部分潛在投標人踏勘專案現場。

5.4.3開標與評標

依法必須進行招標的專案，招標人應當自收到評標報告之日起3日內公示中標候選人，公示期不得少於3日。

5.4.4選定專案承建方

招標人最遲應當在書面合同簽訂後5日內向中標人和未中標的投標人退還投標保證金及銀行同期存款利息。
招標檔案要求中標人提交履約保證金的，中標人應當按照招標檔案的要求提交。履約保證金不得超過中標合同金額的10%。

5.5專案合同談判與簽訂

5.5.2簽訂合同

合同的條款一般應包括:當事人的名稱和地址;標的;數量;質量;價款和報酬;履行期限、地點和方式;違約責任和解決爭議的方法等。
- 標的：買一個商品，這個商品就是標的
對於系統整合類的技術合同，一般應包括:專案名稱;標的內容、範圍和要求;履行的計劃、進度、期限、地點、地域和方式;技術文件和資料的保密;風險責任的承擔;技術成果的歸屬和收益的分成方法;驗收標準和方法;價款、報酬或者使用費及其支付方式;違約金或者損失賠償的計算方法;解決爭議的方法;名詞術語的解釋等。

5.6供應商專案立項

==*（死背）==一般來說，系統整合供應商主要根據專案的特點和型別，決定是否要在組織內部為所簽署的外部專案單獨立項。例如針對包含軟體開發任務的專案通常需要進行內部立項，而那些單一的裝置採購類專案則無需單獨立項，系統整合商進行專案內部立項主要有幾方面原因。
1. 通過專案立項方式為專案分配資源。
2. 通過專案立項方式確定合理的專案績效目標。
3. 以專案型工作方式，提升專案實施效率。
- 為什麼要立項
==*（死背）==系統整合供應商在進行專案內部立項時一般包括的內容有
1. 專案資源估算
2. 專案資源分配
3. 準備專案任務書
4. 任命專案經理等
  - 權利可能不明確

09、專案整體管理

6.1專案整體管理概述

6.1.1專案整體管理的含義、作用和過程

專案整體管理包括為識別、定義、組合、統一和協調各專案管理過程組的各種過程和活動而開展的工作，是專案管理中一項綜合性和全域性性的管理工作。
==*（是什麼）==專案整體管理包括以下6個過程:
1. 制定專案章程。編寫一份正式檔案的過程，這份檔案就是專案章程。通過釋出專案章程，正式地批准專案並授權專案經理在專案活動中使用組織資源。
  - 寫一個專案章程，批准專案的啟動
2. 制定專案管理計劃。定義、準備和協調所有子計劃，並把它們整合為一份綜合專案管理計劃的過程。專案管理計劃包括經過整合的專案基準和子計劃。
  - 寫一個計劃
3. 指導與管理專案工作。為實現專案目標而領導和執行專案管理計劃中所確定的工作，並實施已批准變更的過程。
  - 實施計劃
4. 監控專案工作。跟蹤、審查和報告專案進展，以實現專案管理計劃中確定的績效目標的過程。
  - 監控實施
5. 實施整體變更控制。審查所有變更請求，批准變更，管理對可交付成果、組織過程資產、專案檔案和專案管理計劃的變更，並對變更處理結果進行溝通的過程。
  - 變更流程
6. 結束專案或階段。完成所有專案管理過程組的所有活動，以正式結束專案或階段的過程。
  - 收尾

6.1.2專案經理是整合者

整合者是專案經理承擔的重要角色之一，他要通過溝通來協調，通過協調來整合。作為整合者，專案經理必須從巨集觀視角來審視專案。
==*（有什麼+必考）==作為整合者，其主要工作包括:
1. 通過與專案干係人主動、全面的溝通，來了解他們對專案的需求
2. 在相互競爭的眾多幹系人之間尋找平衡點
3. 通過認真，細緻的協調，來達到各種需求間的整合與平衡

6.2制定專案章程

6.2.1制定專案章程概述

制定專案章程是編寫一份正式批准專案並授權專案經理在專案活動中使用組織資源的檔案的過程。專案章程宣告一個專案的正式啟動、專案經理的任命，並對專案的目標、範圍、主要可交付成果、主要制約因素與主要假設條件等進行總體性描述。
*（理解）專案章程不能太抽象，也不能太具體。另外，通常由高階管理層簽發專案章程，專案經理可以參與甚至起草專案章程，但專案章程是由專案以外的實體來發布的，如發起人、專案集或專案管理辦公室職員，或專案組合治理委員會主席或授權代表。專案章程遵循“誰簽發，誰有權修改”
- 專案經理只是一個打字員

6.2.2制定專案章程

==*（必考）==專案章程的作用
1. 確定專案經理，規定專案經理的權力。
2. 正式確認專案的存在，給專案一個合法的地位。
3. 規定專案的總體目標，包括範圍、時間、成本和質量等。
4. 通過敘述啟動專案的理由，把專案與執行組織的日常經營運作及戰略計劃等聯絡起來。
- 主要是授權
*（標註）制訂專案章程的輸入
1. 專案工作說明書
  - 專案工作說明書(SOW）是對專案需交付的產品、服務或輸出的敘述性說明。對於內部專案，專案啟動者或發起人根據業務需要及對產品或服務的需求，來提供工作說明書。對於外部專案，工作說明書則由客戶提供，可以是招標檔案(如建議邀請書、資訊邀請書、投標邀請書)的一部分，或合同的一部分。專案工作說明書包括以下內容:(1）業務需要（2）產品範圍描述（3）戰略計劃
2. 商業論證
3. 協議
4. 組織過程資產
5. 事業環境因素
*（標註）制訂專案章程的工具和技術
1. 專家判斷
2. 引導技術:
  - 廣泛應用於各專案管理過程，可用於指導專案章程的制定。頭腦風暴、衝突處理、問題解決和會議管理等，都是引導者可以用來幫助團隊和個人完成專案活動的關鍵技術。
==*（必考）==制訂專案章程的輸出就是專案章程，其主要內容包括:
1. 概括性的專案描述和專案產品描述。
  - 是什麼
2. 專案目的或批准專案的理由，即為什麼要做這個專案。
  - 為什麼
3. 專案的總體要求，包括專案的總體範圍和總體質量要求。
  - 目標
4. 可測量的專案目標和相關的成功標準。
5. 專案的主要風險，如專案的主要風險類別。
  - 風險
6. 總體里程碑進度計劃。
7. 總體預算。
  - 預算
8. 專案的審批要求，即在專案的規劃、執行、監控和收尾過程中，應該由誰來做出哪種批准。
9. 委派的專案經理及其職責和職權。
  - 專案經理職責和職權
10. 發起人或其他批准專案章程的人員的姓名和職權。
  - 專案章程負責人姓名職權

6.3制訂專案管理計劃

6.3.1專案管理計劃的概述

制訂專案管理計劃
1. 是一個收集其他規劃過程的結果，並匯成一份綜合的、經批准的、現實可行的、正式的專案計劃檔案的過程。
2. 專案管理計劃可能不只是要得到管理層的批准，可能還需要得到其他主要專案干係人的批准。例如，其中的進度管理計劃和進度基準，就需要得到相關職能經理的批准，因為他們負責提供專案所需的人員。如果人員不能在需要的時候到位，進度基準肯定無法實現。
3. 專案管理計劃必須是自下而上制訂出來的。專案團隊成員要對與自己密切相關的部分制訂相應計劃，並逐層向上報告和彙總，最後由專案經理進行綜合，形成綜合性的、整體的專案管理計劃。
4. 在制訂專案管理計劃的過程中，專案經理和專案團隊成員也要充分聽取其他主要專案干係人的意見，以便把干係人的需求儘可能地反映在專案管理計劃中，以避免干係人對專案的執行結果產生分歧。
  - 各個干係人的參與
專案管理計劃的主要用途有:
1. 指導專案執行、監控和收尾。
2. 為專案績效考核和專案控制提供基準。
3. 記錄制訂專案計劃所依據的假設條件。
4. 記錄制訂專案計劃過程中的有關方案選擇。
5. 促進專案干係人之間的溝通。
6. 規定管理層審查專案的時間、內容和方式。
在專案執行開始之前，要制訂出盡可能完整的專案管理計劃。但是專案管理計劃也要在專案生命週期的後續階段中不斷審闊、細化、完善和更新。
專案管理計劃制訂的步驟:
1. 各具體知識領域制訂各自的分項計劃。
2. 整體管理知識領域收集各分項計劃，整合成專案管理計劃。
3. 用專案管理計劃指導專案的執行和監控工作，並在執行過程中監控。
4. 對提出的必要的變更請求，報實施整體變更控制過程審批。
5. 根據經批准的變更請求，更新專案管理計劃。

6.3.2制訂專案管理計劃的輸入

專案章程
其他規劃過程的輸出
- 各個子計劃
- 專案管理計劃和各個子計劃互相為輸入
組織過程資產
事業環境因素

6.3.3制訂專案管理計劃的工具和技術

專家判斷
引導技術

6.3.4制訂專案管理計劃的輸出:專案管理計劃

==*（必考）==專案管理計劃還可以包括如下內容:
1. 所使用的專案管理過程。
2. 每個特定專案管理過程的實施程度。
3. 完成這些過程的工具和技術的描述。
4. 專案所選用的生命週期及各階段將採用的過程。
5. 如何用選定的過程來管理具體的專案。包括過程之間的依賴與互動關係和基本的輸入和輸出。
6. 如何執行工作來完成專案目標及對專案目標的描述。
7. 如何監督和控制變更，明確如何對變更進行監控。
8. 配置管理計劃，用來明確如何開展配置管理。
9. 對維護專案績效基線的完整性的說明。
10. 與專案干係人進行溝通的要求和技術。
11. 為專案選擇的生命週期模型。
12. 為解決某些遺留問題和未定的決策，對於其內容、嚴重程度和緊迫程度進行的關鍵管理評審。
- 都是指導工作
專案管理計劃可以是概括的或詳細的，可以包含一個或多個輔助計劃（即其他各規劃過程所產生的所有子管理計劃)。輔助計劃包括:範圍管理計劃、需求管理計劃、進度管理計劃、成本管理計劃、質量管理計劃、過程改進計劃、人力資源管理計劃、溝通管理計劃、風險管理計劃、採購管理計劃、干係人管理計劃等。

6.4指導與管理專案工作

6.4.2指導與管理專案工作的輸入

專案管理計劃
批准的變更請求
事業環境因素
組織過程資產

6.4.3指導與管理專案工作的工具和技術

專案管理資訊系統
會議
專家判斷

6.4.4指導與管理專案工作的輸出

可交付成果
工作績效資料
變更請求
專案管理計劃更新
專案檔案更新

成效

6.5監控專案工作

6.5.1監控專案工作的概述

監控專案工作是跟蹤、審查和報告專案進展，以實現專案管理計劃中確定的績效目標的過程。
- 監察與控制
- 將實際與計劃作對比
監督是貫穿於整個專案的專案管理活動之一
監控專案工作過程主要關注:
1. 把專案的實際績效與專案管理計劃進行比較。
2. 評估專案績效，決定是否需要採取糾正或預防措施，並推薦必要的措施。
3. 識別新風險，分析、跟蹤和監測已有風險，確保全面識別風險，報告風險狀態,並執行適當的風險應對計劃。
4. 在整個專案期間，維護一個準確且及時更新的資訊庫，以反映專案產品及相關檔案的情況。
5. 為狀態報告、進展測量和預測提供資訊。
6. 做出預測，以更新當前的成本與進度資訊。
7. 監督已批准變更的實施情況。
8. 如果專案是專案集的一部分，還應向專案集管理層報告專案進展和狀態。

6.5.2、監控專案工作的輸入

專案管理計劃
進度預測
成本預測
確認的變更
工作績效資訊
事業環境因素
組織過程資產

各個管理領域，凡是監控的過程，輸入都有計劃和績效

6.5.3、監控專案工作的工具和技術

分析技術
1. 迴歸分析:迴歸分析是確定兩種或兩種以上變數間相互依賴的定量關係的一種統計分析方法。
2. 分組方法:通過統計分組的計算和分析，從定性或定量的角度來認識所要分析物件的不同特徵，不同性質及相互關係的方法。根據研究的目的和客觀現象的內在特點，按某個標誌或幾個標誌把被研究的總體劃分為若干個不同性質的組，使組內的差異儘可能小，組間的差異儘可能大。
3. 因果分析
4. 根本原因分析:根本原因分析(RCA）是一項結構化的問題處理法，用以逐步找出問題的根本原因並加以解決，而不是僅僅關注問題的表徵。根本原因分析是一個系統化的問題處理過程，包括確定和分析問題原因，找出問題解決辦法，並制定問題預防措施。在組織管理領域內，根本原因分析能夠幫助利益相關者發現組織問題的癥結，並找出根本性的解決方案。所謂根本原因，就是導致我們所關注的問題發生的最基本的原因。因為引起問題的原因通常有很多，物理條件、人為因素、系統行為或者流程因素等，通過科學分析，有可能發現不止一個根源性原因。根本原因分析
  法的目的就是要努力找出問題的作用因素，並對所有的原因進行分析。常用根本原因分析的工具有:因果圖、頭腦風暴法、因果分析（魚骨圖）等。
5. 預測方法
6. 失效模式與影響分析（FMEA)
  - FMEA是一套流程和工具，幫助人們在概念和設計等早期階段，來識別一個產品或過程的可能失效情形，以及一旦發生這種失敗情形時造成的影響。FMEA還指導人們對可能的失效原因進行排序，並且制定和落實相應的應對措施。
7. 故障樹分析（FTA)，它採用邏輯的方法，形象地進行薄弱環節和風險等危險的分析工作，特點是直觀、明瞭，思路清晰，邏輯性強，可以做定性分析，也可以做定量分析。
8. 儲備分析
9. 趨勢分析:又稱趨勢預測法，用於檢查專案績效隨時間的變化情況，以確定績效是在改善還是在惡化。
10. 掙值管理
專案管理資訊系統
會議
專家判斷

6.5.4、監控專案工作的輸出

變更請求
工作績效資料
專案管理計劃更新
專案檔案更新

各個管理領域，凡是監控的過程，輸出都有變更和更新

6.6實施整體變更控制

6.6.1實施整體變更控制的概述

實施整體變更控制是審查所有變更請求，批准或否決變更，管理對可交付成果、組織過程資產、專案檔案和專案管理計劃的變更，並對變更處理結果進行溝通的過程。
實施整體變更控制過程貫穿專案始終，並且應用於專案的各個階段。專案經理對此負最終責任。
專案的任何干系人都可以提出變更請求。儘管可以口頭提出，但所有變更請求都必須以書面形式記錄，並納入變更管理以及配置管理系統中。
- 但是合同的變更一開始就要是書面的
CCB是一個正式組成的團體，負責審查、評價、批准、推遲或否決專案變更，以及記錄和傳達變更處理決定。
- 變更控制委員會是由主要專案干係人的代表所組成的一個小組，專案經理可以是其中的成員之一，但通常不是組長。
- 最好是各方都派人蔘加，但是也可以只有甲方一人
- 都是兼職
- 只負責決策，不負責任
==*（必考）==整體變更控制過程包括下列變更活動
1. 變更申請
2. 變更影響分析
3. CCB的批准或拒絕
4. 實施變更
5. 驗證變更

6.6.2實施整體變更控制的輸入

專案管理計劃
工作績效報告
變更請求
組織過程資產
事業環境因素

6.6.3、實施整體變更控制的工具和技術

會議
變更控制工具
專家判斷

6.6.4、實施整體變更控制的輸出

批准的變更請求
變更日誌
專案管理計劃更新
專案檔案更新

6.7結束專案或階段

6.7.1結束專案或階段的概述

結束專案或階段是完成並結束所有專案管理過程組的所有活動，以正式結束專案或專案階段的過程。這個過程包括完成所有專案過程中的所有活動以正式關閉整個專案或階段;恰當地移交已完成或己取消的專案或階段;對專案可交付物進行驗證和記錄;協調和配合顧客或出資人對這些可交付物的正式接受。本過程的主要作用是︰總結經驗教訓，正式結束專案工作，為開展新工作而釋放組織資源。
1. 合同收尾
  - 履行合同條款
2. 行政收尾/管理收尾
  - 做好總結，獲取經驗教訓

6.7.2結束專案或階段的輸入

專案管理計劃
驗收的可交付成果
組織過程資產

6.7.3結束專案或階段的工具和技術

專家判斷
分析技術
會議

6.7.4結束專案或階段的輸出

最終產品、服務或輸出移交移交專案所產出的最終產品、服務或輸出(在階段收尾時，則是移交該階段所產出的中間產品、服務或輸出。
組織過程資產更新

10、專案範圍管理

7.1專案範圍管理概念

7.1.1專案範圍管理的含義及作用

通俗地講，專案範圍管理就是要做範圍內的事，而且只做範圍內的事，既不少做也不多做。

7.1.2專案範圍管理的主要過程

專案範圍管理通過以下6個過程來實現:
1. 編制範圍管理計劃過程，對如何定義、確認和控制專案範圍的過程進行描述。
  - 編寫一個範圍管理計劃，關於如何做好範圍管理
2. 收集需求。為實現專案目標，明確並記錄專案干係人的相關需求的過程。
  - 收集需求
3. 定義範圍。詳細描述產品範圍和專案範圍，編制專案範圍說明書，作為以後專案決策的基礎。
  - 編制專案範圍說明書，把收集的需求作一個歸類（範圍內，範圍外），並做一個詳細的描述
  - 需要形成一個文件
4. 建立工作分解結構。把整個專案工作分解為較小的、易於管理的組成部分，形成一個自上而下的分解結構。
  - 把專案分解為各個小模組
5. 確認範圍。正式驗收已完成的可交付成果。
  - 各個模組各自完成之後，確認成果
6. 範圍控制。監督專案和產品的範圍狀態、管理範圍基準變更。
  - 做監控

7.2編制範圍管理計劃

編制範圍管理計劃是專案或專案集管理計劃的組成部分，描述瞭如何定義、制定、監督、控制和確認專案範圍。

7.2.1編制範圍管理計劃過程所用的工具與技術

會議
專家判斷

7.2.2編制範圍管理計劃過程的輸入、輸出

編制範圍管理計劃過程的輸入
1. 專案管理計劃
2. 專案章程
3. 組織過程資產
4. 事業環境因素
編制範圍管理計劃過程的輸出
1. 範圍管理計劃。
  - 範圍管理計劃要對將用於下列工作的管理過程做出規定:
    1. 制定詳細專案範圍說明書。
    2. 根據詳細專案範圍說明書建立WBS。
    3. 維護和批准工作分解結構（WBS)。
    4. 正式驗收已完成的專案可交付成果。
    5. 處理對詳細專案範圍說明書或WBS的變更。該工作與實施整體變更控制過程直接相聯。根據專案需要，範圍管理計劃可以是正式或非正式的，非常詳細或高度概括的。
2. 需求管理計劃

7.3收集需求

收集需求是為實現專案目標而確定、記錄並管理干係人的需要和需求的過程。本過程的主要作用是為定義和管理專案範圍（包括產品範圍）奠定基礎。

7.3.1收集需求過程的工具與技術

訪談:
- 訪談是通過與干係人直接交談來獲取資訊的正式或非正式的方法。訪談經常是一個訪談者和一個被訪者之間的“一對一”談話，但也可以包括多個訪談者或多個被訪者。
焦點小組:
- 焦點小組是召集預定的干係人和主題專家，瞭解他們對所討論的產品、服務或成果的期望和態度。由一位受過訓練的主持人引導大家進行互動式討論。焦點小組往往比“一對一”的訪談更熱烈。
引導式研討會:
- 引導式研討會把主要干係人召集在一起，通過集中討論來定義產品需求。研討會是快速定義跨職能需求和協調幹系人差異的重要技術。由於群體互動的特點，被有效引導的研討會有助於參與者之間建立信任、改進關係、改善溝通，從而有利於干係人達成一致意見。此外，研討會能夠比單項會議更早發現問題，更快解決問題。
群體創新技術
- 可以組織一些群體活動來識別專案和產品需求。下面是一些常用的群體創新技術:
  1. 頭腦風暴法。一種用來產生和收集對專案需求與產品需求的多種創意的技術。
  2. 名義小組技術。用於促進頭腦風暴的一種技術，通過投票排列最有用的創意，以便進一步開展頭腦風暴或優先排序。
  3. 概念/思維導圖。把從頭腦風暴中獲得的創意整合成一張圖的技術，以反映創意之間的共性與差異，激發新創意。
  4. 親和圖。用來對大量創意進行分組的技術，以便進一步審查和分析。
  5. 多標準決策分析。藉助決策矩陣，用系統分析方法建立諸如風險水平、不確定性和價值收益等多種標準，從而對眾多方案進行評估和排序的一種技術。
群體決策技術:群體決策技術就是為達成某種期望結果，而對多個未來行動方案進行評估的過程。本技術用於生成產品需求，並對產品需求進行歸類和優先順序排序。例如:
1. 一致同意。每個人都同意某個行動方案。
2. 大多數原則。獲得群體中超過50%人員的支援，就能做出決策。把參與決策的小組人數定為奇數，防止因平局而無法達成決策。
3. 相對多數原則。根據群體中相對多數者的意見做出決策，即便未能獲得大多數人的支援。通常在候選項超過兩個時使用。
4. 獨裁。在這種方法中，由某一個人為群體做出決策。
問卷調查∶問卷調查是指設計一系列書面問題，向眾多受訪者快速收集資訊。問卷調查方法非常適用於以下情況:受眾多樣化，需要快速完成調查，受訪者地理位置分散，並且適合開展統計分析。
觀察:觀察是指直接察看個人在各自的環境中如何執行工作（或任務）和實施流程。
原型法:原型法是指在實際製造預期產品之前，先造出該產品的實用模型，並據此徵求對需求的早期反饋。原型法支援漸進明細的理念，需要經歷從模型建立、使用者體驗、反饋收集到原型修改的反覆迴圈過程。在經過足夠的反饋迴圈之後，就可以通過原型獲得足夠的需求資訊，從而進入設計或製造階段。
標杆對照:標杆對照將實際或計劃的做法（如流程和操作過程)與其他可比組織的做法進行比較，以便識別最佳實踐，形成改進意見，併為績效考核提供依據。標杆對照所採用的可比組織可以是內部的，也可以是外部的。
系統互動圖:系統互動圖是範圍模型的一個例子，它是對產品範圍的視覺化描繪，顯示業務系統及其與人和其他系統（行動者）之間的互動方式。系統互動圖顯示了業務系統的輸入、輸入提供者、業務系統的輸出和輸出接收者。
- 人機對話
檔案分析:檔案分析就是通過分析現有文件，識別與需求相關的資訊，來挖掘需求。

7.3.2收集需求過程的輸入、輸出

收集需求過程的輸入
1. 範圍管理計劃
2. 需求管理計劃
3. 干係人管理計劃
4. 專案章程
5. 干係人登記冊
收集需求過程的輸出
1. 需求檔案:需求檔案描述各種單一需求將如何滿足與專案相關的業務需求。
2. 需求跟蹤矩陣
  - 需求跟蹤矩陣是把產品需求從其來源連線到能滿足需求的可交付成果的一種表格。使用需求跟蹤矩陣，可以把每個需求與業務目標或專案目標聯絡起來，有助於確保每個需求都具有商業價值。需求跟蹤矩陣提供了在整個專案生命週期中跟蹤需求的一種方法，有助於確保需求檔案中被批准的每項需求在專案結束的時候都能交付。需求跟蹤矩陣還為管理產品範圍變更提供了框架。應在需求跟蹤矩陣中記錄每個需求的相關屬性。需求跟蹤矩陣中記錄的典型屬性包括唯一標識、需求的文字描述、收錄該需求的理由、所有者、來源、優先級別、版本、當前狀態和狀態日期。為確保干係人滿意，可能需要增加一些補充屬性，如穩定性、複雜性和驗收標準。

7.4範圍定義

7.4.1範圍定義

定義範圍是制定專案和產品詳細描述的過程。本過程的主要作用是，明確所收集的需求哪些將包含在專案範圍內，哪些將排除在專案範圍外，從而明確專案、服務或輸出的邊界。
定義範圍最重要的任務就是詳細定義專案的範圍邊界，範圍邊界是應該做的工作和不需要進行的工作分界線。定義範圍可以增加專案時間、成本和資源估算的準確度，定義專案控制的依據，明確相關責任人在專案中的責任，明確專案的範圍、合理性和目標，以及主要可交付成果。
範圍定義的輸入
1. 範圍管理計劃
2. 專案章程
3. 需求檔案
範圍定義的輸出
1. 專案範圍說明書
2. 專案檔案更新
範圍定義的工具和技術
1. 產品分析:產品分析旨在弄清產品範圍，並把對產品的要求轉化成專案的要求。
2. 專家判斷
3. 備選方案生成:備選方案生成是一種用來制定儘可能多的潛在可選方案的技術，用於識別執行專案工作的不同方法。許多通用的管理技術都可用於生成備選方案，如頭腦風暴、橫向思維、備選方案分析等。
4. 引導式研討會

7.5.2範圍說明書

專案範圍說明書是對專案範圍、主要可交付成果、假設條件和制約因素的描述。專案範圍說明書記錄了整個範圍，包括專案和產品範圍。專案範圍說明書詳細描述專案的可交付成果，以及為建立這些可交付成果而必須開展的工作。
==*（必考）==詳細的範圍說明書包含的內容
1. 專案目標
2. 產品範圍描述
3. 專案需求
4. 專案邊界
5. 專案的可交付成果
6. 專案的制約因素
7. 假設條件
雖然專案章程和專案範圍說明書的內容存在一定程度的重疊，但它們的詳細程度完全不同。專案章程包括高層級的資訊，而專案範圍書說則是對專案範圍的詳細描述。專案範圍需要在專案過程中漸進明細。

7.5建立工作分解結構

建立工作分解結構是把專案可交付成果和專案工作分解成較小的、更易於管理的元件的過程。
==WBS（WorkBreakdownStructure）==最低層的工作單元被稱為工作包，是我們進行進度安排、成本估算和監控的基礎。
工作分解結構是用來確定專案範圍的，專案的全部工作都必須包含在工作分解結構當中，而且不包含在工作分解結構中的任何工作都不是專案的組成部分，都不能做,否則就是“鍍金”。
- 既不能多做，也不能少做
工作分解結構的編制需要所有專案千系人的參與，需要專案團隊成員的參與。
- 所有人
工作分解結構是逐層向下分解的。一般情況下，工作分解結構應控制在3~6層為宜。
- 從上到下分解
工作分解結構中的各要素應該是相對獨立的，要儘量減少相互之間的交叉。
==*（必考）==當前較常用的工作分解結構表示形式主要有以下兩種:
1. 分級的樹型結構，類似於組織結構圖。樹型結構圖的WBS層次清晰，非常直觀，結構性強，但是不容易修改，對於大型的、複雜的專案也很難表示出專案的全景。由於其直觀性，一般在一些小的、適中的應用專案中用得較多。
2. 表格形式，類似於分級的圖書目錄。
  - 該表能夠反映出專案所有的工作要素，可是直觀性較差。但在一些大型的、複雜的專案中使用還是較多的，因為有些專案分解後，內容分類較多、容量較大，用縮排圖表的形式表示比較方便，也可裝訂為手冊。
里程碑標誌著某個可交付成果或者階段的正式完成。
- 重要的檢查的是里程碑
- 重要的里程碑是基線
工作包是位於工作分解結構每條分支最低層的可交付成果或專案工作組成部分。作為一種經驗法則，8/80規則(80小時原則）建議工作包的大小應該至少需要8個小時來完成，而總完成時間也不應該大於80小時。
- 如何分解按照工作時間判斷
在製作分解結構的過程中，把每個工作包分配到–個控制賬戶，並根據“賬戶編碼”為工作包建立唯一標識，這些標識為進行成本、進度與資源資訊的層級彙總提供了層級結構。控制賬戶是一個管理控制點。在該控制點上，把範圍、預算、實際成本和進度加以整合，並與掙值相比較，以測量績效。控制賬戶設定在WBS中選定的管理節點上。每個控制賬戶可能包括一個或多個工作包，但是一個工作包只能屬於一個控制賬戶。需要生成一些配套的檔案，這些檔案需要和工作分解結構配合使用，稱為工作分解結構詞典，它包括工作分解結構組成部分的詳細內容、賬戶編碼、工作說明、負責人、進度里程碑清單等，還可能包括合同資訊、質量要求、技術文獻、計劃活動、資源和成本估計等。
- 分解的越詳細，越要對專案非常瞭解
- 如果是一開始還不熟悉，能分到什麼程度，就分到什麼程度，這個結果叫做控制賬戶

7.5.1、WBS建立工作的工具與技術

分解
- ==*（必考）==分解是一種把專案範圍和專案可交付成果逐步劃分為更小、更便於管理的單元，通常需要開展以下活動:
  1. 識別和分析可交付成果及相關工作。
    - 分解什麼
  2. 確定WBS的結構和編排方法。
    - 怎麼分解
  3. 自上而下逐層細化分解。
    - 分解
  4. 為WBS元件制定和分配標識編碼。
    - 編碼
  5. 核實可交付成果分解的程度是否恰當。
    - 檢查
- ==*（必考）==工作結構分解應把握如下原則:
  1. 在層次上保持專案的完整性，避免遺漏必要的組成部分。
    - 既不能多做也不能少做
  2. —個工作單元只能從屬於某個上層單元，避免交叉從屬。
    - 不能有多個父類
  3. 相同層次的工作單元應用相同性質。
  4. 工作單元應能分開不同的責任者和不同的工作內容。
  5. 便於專案管理計劃和專案控制的需要。
  6. 最底層工作應該具有可比性，是可管理的，可定量檢查的。
  7. 應包括專案管理工作，包括分包出去的工作。
專家判斷

7.5.2、建立工作分解結構的輸入、輸出

建立工作分解結構的輸入
1. 專案範圍管理計劃
2. 專案範圍說明
3. 需求檔案
4. 事業環境因素
5. 組織過程資產
建立工作分解結構的輸出
1. 範圍基準:經過批准的範圍說明書、工作分解結構(WBS）和相應的WBS詞典組成了範圍基準，只有通過正式的變更控制程式才能進行變更這個基準，它被用作比較的基礎。範圍基準包括:
  1. 專案範圍說明書。
  2. WBS。
  3. WBS詞典。WBS詞典是針對每個WBS元件，詳細描述可交付成果、活動和進度資訊的檔案。WBS詞典對WBS提供支援。WBS詞典中的內容可能至少包括:賬戶編碼標識、工作描述、假設條件和制約因素、負責的組織、進度里程碑、相關的進度活動、所需資源、成本估算、質量要求、驗收標準、技術參考文獻、協議資訊。
2. 專案檔案更新

7.6專案範圍確認

確認範圍是正式驗收己完成的專案可交付成果的過程。確認範圍需要審查可交付物和工作成果，以保證專案中所有工作都能準確地、滿意地完成。確認範圍應該貫穿專案的始終。本過程的主要作用是，使驗收過程具有客觀性;同時通過驗收每個可交付成果，提高最終產品、服務或成果獲得驗收的可能性。

7.6.1專案範圍確認的工作要點

確認範圍過程與控制質量過程的不同之處在於，前者關注可交付成果的驗收，而後者關注可交付成果的正確性及是否滿足質量要求。控制質量過程通常先於確認範圍過程,但二者也可同時進行。
- 是否可以驗收
- 是否可以滿意
確認範圍的-一般步驟:
1. 確定需要進行確認範圍的時間
2. 識別確認範圍需要哪些投入。
3. 確定範圍正式被接受的標準和要素。
4. 確定確認範圍會議的組織步驟。
5. 組織確認範圍會議。

7.6.2專案範圍確認的工具

檢查是指開展測量、審查與確認等活動，來判斷工作和可交付成果是否符合需求和產品驗收標準，是否滿足專案干係人的要求和期望。檢查有時也被稱為審查、產品審查、審計和巡檢等。在某些應用領域，這些術語具有獨特和具體的含義。
群體決策技術

7.6.3、專案範圍確認的輸入、輸出

專案範圍確認的輸入
1. 專案管理計劃
2. 需求檔案
3. 需求跟蹤矩陣
4. 核實的可交付成果︰核實的可交付成果是指已經完成，並經質量過程檢查為正確的可交付成果。
5. 工作績效資料
專案範圍確認的輸出
1. 驗收的可交付成果
2. 變更請求
3. 工作績效資訊
4. 專案檔案更新

7.7專案範圍控制

變更不可避免，因此在每個專案上，都必須以書面的形式記錄並實施某種形式的變更控制管理

7.7.4、範圍控制的工具和技術

偏差分析

7.7.5、專案範圍確認的輸入、輸出

專案管理計劃
需求檔案
需求跟蹤矩陣
工作績效資料
組織過程資產
專案範圍確認的輸出
1. 工作績效資訊
2. 變更請求
3. 專案管理計劃更新

建議學的補充資料

產品範圍和專案範圍。
1. 產品範圍;表示產品、服務或結果的特性和功能。產品範圍包含產品規格、效能技術指標的描述，即產品所包含的特徵和具體的功能效能情況等。隨著專案的開展，其產品特徵會逐漸細化。
  - 技術
2. 專案範圍:為了完成具有規定特徵和功能的產品、服務或結果，而必須完成的專案工作。專案範圍是否完成以專案管理計劃、專案範圍說明書、WBS、以及WBS字典作為衡量標準，而產品範圍是否完成以產品要求作為衡量標準。兩種範圍管理需要很好地整合起來，以確保專案工作能產生所規定的產品並準時交付。
  - 管理

11、專案進度管理

專案進度管理包括為管理專案按時完成所需的7個過程，具體為:
1. 規劃進度管理過程:制定政策、程式和文件以管理專案進度。
  - 寫一個文件，規劃進度管理過程，關於如何做好進度管理
2. 定義活動過程:識別和記錄為完成專案可交付成果而需採取的具體行動。
  - 定義完成這個專案需要做多少事情
3. 排列活動順序過程:識別和記錄專案活動之間的關係。
  - 給需要做的事情做一個排序
4. 估算活動資源過程:估算執行各項活動所需材料、人員、裝置或用品的種類和數量。
  - 估算每個過程所需要的資源
5. 估算活動持續時間過程:根據資源估算的結果，估算完成單項活動所需工期。
  - 估算每個過程所需要的時間
6. 制定進度計劃過程:分析活動順序、持續時間、資源需求和進度制約因素，建立專案進度模型。
  - 根據以上，進行合併，制定實施計劃
7. 控制進度過程:監督專案活動狀態、更新專案進展、管理進度基準變更，以實現計劃。
  - 監控

8.1規劃專案進度管理

規劃專案進度管理是為實施專案進度管理制定政策、程式，並形成文件化的專案進度管理計劃的過程。本過程的主要作用是，為如何在整個專案過程中管理、執行和控制專案進度提供指南和方向。

8.1.1規劃專案進度管理的輸入

專案管理計劃
專案章程
組織過程資產
事業環境因素

8.1.2規劃專案進度管理的工具與技術

專家判斷
分析技術
會議

8.1.3規劃專案進度管理的輸出

專案進度管理計劃，進度管理計劃會規定:
1. 專案進度模型制定。
2. 準確度。
3. 計量單位
4. 組織程式連結
5. 專案進度模型維護
6. 控制臨界值
7. 績效測量規則
8. 報告格式
9. 過程描述

8.2定義活動

活動，就是為完成工作包所需進行的工作，是實施專案時安排工作的最基本的工作單元。活動與工作包是1對1或多對1的關係，即有可能多個活動完成一個工作包。
定義活動過程就是識別和記錄為完成專案可交付成果而需採取的所有活動。其主要作用是，將工作包分解為活動，作為對專案工作進行估算、進度規劃、執行、監督和控制的基礎。

8.2.1定義活動的輸入

進度管理計劃
範圍基準
組織過程資產
事業環境因素

8.2.2定義活動的工具與技術

分解
滾動式規劃:-近期的計劃安排的詳細一些，遠期的計劃安排的粗略一些。滾動式規劃是一種漸進明細的規劃方式，專案團隊得以逐步完善規劃。
專家判斷

8.2.3定義活動的輸出

活動清單:活動清單是一份包含專案所需的全部活動的綜合清單。
活動屬性
- 在活動屬性編制完成時，可能還包括活動編碼、活動描述、緊前活動、緊後活動、邏輯關係、提前量與滯後量、資源需求、強制日期、制約因素和假設條件。

8.3排列活動順序

排列活動順序是識別和記錄專案活動之間的關係的過程。本過程的主要作用是，定義工作之間的邏輯順序，以便在既定的所有專案制約因素下獲得最高的效率。

8.3.1排列活動順序的輸入

進度管理計劃
活動清單
活動屬性
里程碑清單
專案範圍說明書
事業環境因素
組織過程資產10

8.3.2排列活動順序的工具和技術

前導圖法:單代號網路圖
- 它使用方框或者長方形（被稱作節點）代表活動，節點之間用箭頭連線，以顯示節點之間的邏輯關係。
- A是B的緊前，B是A的緊後
- 前導圖法包括活動之間存在的4種類型的依賴關係。
  1. 結束-開始的關係（F-S 型)。前序活動結束後，後續活動才能開始。例如，只
    有比賽（緊前活動）結束，頒獎典禮（緊後活動）才能開始。
- 最早開始時間（Earliest Start time,ES)、最遲開始時間（Latest Start time，LS)、最早完成時間（Earliest Finish time，EF)和最遲完成時間（Latest Finish time，LF)。
箭線圖法:雙代號網路圖
- 是用箭線表示活動、節點（圓圈）表示事件的一種網路圖繪製方法
  - 節點沒有任何意思
- 為了繪圖的方便，在箭線圖中又人為引入了一種額外的、特殊的活動，叫做虛活動
  (dummy activity)，在網路圖中由一個虛箭線表示。虛活動不消耗時間，也不消耗資源，只是為了彌補箭線圖在表達活動依賴關係方面的不足。藉助虛活動，我們可以更好地、更清楚地表達活動之間的關係，如圖8-5所示。
確定依賴關係
1. 強制性依賴關係:強制性依賴關係是法律或合同要求的或工作的內在性質決定的依賴關係
  - 必須先做這件事，再做那件事
2. 選擇性依賴關係:選擇性依賴關係有時又稱首選邏輯關係、優先邏輯關係或軟邏輯關係。
  - 可以先做這件事，再做那件事
3. 外部依賴關係︰外部依賴關係是專案活動與非專案活動之間的依賴關係。這些依賴關係往往不在專案團隊的控制範圍內。例如，軟體專案的測試活動取決於外部硬體的到貨。
  - 與外部的依賴
4. 內部依賴關係:內部依賴關係是專案活動之間的緊前關係，通常在專案團隊的控制之中。
  - 與內部的依賴
提前量與滯後量;:在活動之間加入時間提前量與滯後量，可以更準確地表達活動之間的邏輯關係。

8.3.3排列活動順序的輸出

專案進度網路圖
專案檔案更新

8.4估算活動資源

估算活動資源是估算執行各項活動所需的材料、人員、裝置或用品的種類和數量的過程。本過程的主要作用是，明確完成活動所需的資源種類、數量和特性，以便做出更準確的成本和持續時間估算。

8.4.1估算活動資源的輸入

進度管理計劃
活動清單
活動屬性
資源日曆:資源日曆是表明每種具體資源的可用工作日或工作班次的日曆。
風險登記冊
活動成本估算:資源的成本可能影響對資源的選擇。
事業環境因素
組織過程資產

8.4.2估算活動資源的工具和技術

專家判斷
備選方案分析
釋出的估算資料:一些組織會定期釋出最新的生產率資訊與資源單位成本，涉及門類眾多的勞務、材料和裝置，覆蓋許多國家及其所屬地區。
專案管理軟體
自下而上估算:自下而上估算是一種估算專案持續時間或成本的方法，通過從下到上逐層彙總WBS元件的估算而得到專案估算。

8.4.3估算活動資源的輸出

活動資源需求:活動資源需求明確了工作包中每個活動所需的資源型別和數量。
資源分解結構:資源分解結構（RBS)是資源依類別和型別的層級展現
專案檔案更新

8.5估算活動持續時間

估算活動持續時間是根據資源估算的結果，估算完成單項活動所需工作時段數的過程。本過程的主要作用是，確定完成每個活動所需花費的時間量，為制定進度計劃過程提供主要輸入。

8.5.1估算活動持續時間的輸入

進度管理計劃
活動清單
活動屬性
活動資源需求
資源日曆
專案範圍說明書
風險登記冊
資源分解結構
事業環境因素
組織過程資產

8.5.2估算活動持續時間的工具和技術

專家判斷
類比估算:類比估算通常成本較低、耗時較少，但準確性也較低。
引數估算:引數估算的準確性取決於引數模型的成熟度和基礎資料的可靠性。引數估算可以針對整個專案或專案中的某個部分，並可與其他估算方法聯合使用。
- 數學建模
三點估算，有專門的課會講。
群體決策技術
- 基於團隊的方法(如頭腦風暴、德爾菲技術或名義小組技術)可以調動團隊成員的參與，以提高估算的準確度，並提高對估算結果的責任感。選擇一組與技術工作密切才目關的人員參與估算過程，可以獲取額外的息，得到更準確的估算。另外，讓成員親自參與估算，能夠提高他們對實現估算的責任感。
儲備分析
- 在進行持續時間估算時，需考慮應急儲備（有時稱為時間儲備或緩衝時間。應急儲備是包含在進度基準中的一段持續時間。應急儲備與“已知-一未知”風險相關。
  也可以估算專案所需要的管理儲備。管理儲備用來應對會影響專案的“未知–未知”險。管理儲備不包括在進度基準中，但屬於專案總持續時間的一部分。

8.5.3估算活動持續時間的輸出

活動持續時間估算
專案檔案更新

8.6制訂進度計劃

8.6.1 進度規劃工作概要

通過把填有專案資料的進度規劃工具看作進度模型，可以把專案進度的呈現形式(進度計劃)與產生專案進度計劃的進度資料和計算工具區分開來。進度模型是專案活動執行計劃的一種表示形式，其中包含持續時間、依賴關係和其他規劃資訊，用以生成專案進度計劃及其他進度資料。
一些耳熟能詳的進度規劃方法包括關鍵路徑法（CPM）和關鍵鏈法(CCM)。
制定可行的專案進度計劃，往往是一個反覆進行的過程。
經批准的最終進度計劃將作為基準用於控制進度過程。隨著專案活動的開展，專案時間管理的大部分工作都將發生在控制進度過程中，以確保專案工作按時完成。

8.6.2制訂進度計劃的輸入

進度管理計劃
活動清單
活動屬性
專案進度網路圖
活動資源需求
資源日曆
活動持續時間估算
風險登記冊
專案人員分派
資源分解結構
事業環境因素
組織過程資產

8.6.3制訂進度計劃的工具和技術

進度網路分析
關鍵路線法，有專門的課會講。
關鍵鏈法:是一種進度規劃方法，允許專案團隊在任何專案進度路徑上設定緩衝，以應對資源限制和專案的不確定性。這種方法建立在關鍵路徑法之上，考慮了資源分配、資源優化、資源平衡和活動歷時不確定性對關鍵路徑的影響。
- 關鍵鏈法增加了作為“非工作活動”的持續時間緩衝，用來應對不確定性。如圖所示，放置在關鍵鏈末端的緩衝稱為專案緩衝，用來保證專案不因關鍵鏈的延誤而延誤。其他緩衝，即接駁緩衝，則放置在非關鍵鏈與關鍵鏈的接合點，用來保護關鍵鏈不受非關鍵鏈延誤的影響。應該根據相應活動鏈的持續時間的不確定性，來決定每個緩衝時段的長短。一旦確定了“緩衝活動”，就可以按可能的最遲開始與最遲完成日期來安排計劃活動。這樣一來，關鍵鏈法不再管理網路路徑的總浮動時間，而是重點管理剩餘的緩衝持續時間與剩餘的活動鏈持續時間之間的匹配關係。

軟考2.0.assets/image-20201002112947993.png

資源優化技術
1. 資源平衡為了在資源需求與資源供給之間取得平衡，根據資源制約對開始日期和結束日期進行調整的一種技術。
2. 資源平滑對進度模型中的活動進行調整，從而使專案資源需求不超過預定的資源限制的一種技術。相對於資源平衡而言，資源平滑不會改變專案關鍵路徑，完工日期也不會延遲。也就是說，活動只在其自由浮動時間和總浮動時間內延遲。因此，資源平滑技術可能無法實現所有資源的優化。
建模技術，建模技術包括（但不限於）
1. 假設情景分析。假設情景分析是對各種情景進行評估，預測它們對專案目標的影響（積極或消極的)。假設情景分析就是對“如果情景X出現，情況會怎樣?
2. 模擬。最常用的模擬技術是蒙特卡洛分析
提前量和滯後量
進度壓縮技術，是指在不縮減專案範圍的前提下，縮短進度工期，以滿足進度制約因素、強制日期或其他進度目標。進度壓縮技術包括（但不限於）:
1. 趕工。通過增加資源，以最小的成本增加來壓縮排度工期的一種技術。趕工的例子包括:批准加班、增加額外資源或支付加急費用，來加快關鍵路徑上的活動。趕工只適用於那些通過增加資源就能縮短持續時間的，且位於關鍵路徑上的活動。趕工並非總是切實可行，它可能導致風險和/或成本的增加。
2. 快速跟進。一種進度壓縮技術，將正常情況下按順序進行的活動或階段改為至少是部分並行開展。例如，在大樓的建築圖紙尚未全部完成前就開始建地基。快速跟進可能造成返工和風險增加。它只適用於能夠通過並行活動來縮短專案工期的情況。
進度計劃編制工具

8.6.4 制訂進度計劃的輸出

進度基準:進度基準是經過批准的專案進度計劃，只有通過正式的變更控制程式才能進行變更，用作與實際結果進行比較的依據。
專案進度計劃:可以採用以下一種或多種圖形來呈現:
1. 橫道圖
2. 里程碑圖
3. 專案進度網路圖。
4. 進度資料
5. 專案日曆:在專案日曆中規定可以開展活動的工作日和工作班次
6. 專案管理計劃更新
7. 專案檔案更新

8.7控制進度

控制進度是監督專案活動狀態，更新專案進展，管理進度基準變更，以實現計劃的過程。本過程的主要作用是，提供發現計劃偏離的方法，從而可以及時採取糾正和預防措施，以降低風險。
進度控制關注如下內容。
1. 判斷專案進度的當前狀態;
2. 對引起進度變更的因素施加影響，以保證這種變化朝著有利的方向發展;
3. 判斷專案進度是否已經發生變更;
4. 當變更實際發生時嚴格按照變更控制流程對其進行管理。
通常可用以下一些方法縮短活動的工期:
1. 趕工，投入更多的資源或增加工作時間，以縮短關鍵活動的工期;
2. 快速跟進，並行施工，以縮短關鍵路徑的長度;
3. 使用高素質的資源或經驗更豐富的人員;
4. 減小活動範圍或降低活動要求;
5. 改進方法或技術，以提高生產效率;
6. 加強質量管理，及時發現問題，減少返工，從而縮短工期。

8.7.1控制進度的輸入

專案管理計劃
專案進度計劃
工作績效資料
專案日曆
進度資料
組織過程資產

8.7.2控制進度的工具與技術

績效審查:績效審查是指測量、對比和分析進度績效
專案管理軟體
資源優化技術:資源優化技術是在同時考慮資源可用性和專案時間的情況下，對活動和活動所需資源進行優化安排。
建模技術:使用建模技術，通過風險監控，對各種不同的情景進行審查，以便使進度模型與專案管理計劃和批准的基準保持一致。
提前量和滯後量
進度壓縮:採用進度壓縮技術使進度落後的活動趕上計劃，可以對剩餘工作使用快速跟進或趕工方法。
進度計劃編制工具

8.7.3控制進度的輸出

工作績效資訊
進度預測
變更請求
專案管理計劃更新
專案檔案更新
組織過程資產更新

建議學的補充資料

招聘新人、加班加點屬於趕工，這是最常用的辦法，加快了進度，增加了成本，加班時間長了還影響質量和士氣。
優化流程屬於快速跟進。這種方法不會引起成本的增加，但要求專案經理有較高的管理水平。
專案經理可以從以下幾個方面科學地檢查及控制專案的進度執行情況:
1. 科學地制定進度計劃，設定恰當的監控點;
2. 進行恰當的工作記錄。例如，專案進展報告及當前進度狀態需包含實際開始與完成日期，以及未完計劃活動的剩餘持續時間;
3. 績效測量和報告。例如，制定統一模版的專案進度報告，檢查當前的完成情況;
4. 偏差分析，將需要關注的偏差按專案績效原因、計劃估算原因和特殊事件原因分類，並分別採取措施;
5. 制定相應的進度控制手段，例如:資源調配（或資源平衡)、趕工，以及對關鍵路徑活動和非關鍵路徑活動設定不同的闕值以決定是否採取糾正措施等;
6. 綜合運用制定進度的工具、專案管理軟體，以減輕管理工作量。例如，使用計劃比較甘特圖，節省用於分析進度的時間。用於制定進度表的專案管理軟體能夠追蹤、比較計劃日期與實際日期，預測實際或潛在的專案進度變更所帶來的後果，是進度控制的有效工具。

12、專案成本管理

9.1成本管理概念及相關術語

9.1.1成本與成本管理概念

專案全過程所耗用的各種成本的總和為專案成本。
專案成本管理就是要確保在批准的預算內完成專案。
專案成本管理的過程
- 具體的專案成本管理要靠制訂成本管理計劃、成本估算、成本預算、成本控制等4個過程來完成，其中:
  1. 制訂成本管理計劃一制訂了專案成本結構、估算、預算和控制的標準。
    - 寫一個文件關於如何做好成本管理
  2. 成本估算一編制完成專案活動所需資源的大致成本。
    - 估算要多少錢
  3. 成本預算一合計各個活動或工作包的估算成本，以建立成本基準。
    - 詳細計算要多少錢
  4. 成本控制一影響造成成本偏差的因素，控制專案預算的變更。
    - 控制成本

9.1.2相關術語

產品的全生命週期成本就是在產品或系統的整個使用生命期內，在獲得階段（設計、生產、安裝和測試等活動，即專案存續期間)、運營與維護及生命週期結束時對產品的處置所發生的全部成本。
==*（必考）==成本的型別
1. 可變成本:隨著生產量、工作量或時間而變的成本為可變成本。可變成本又稱變動成本。
2. 固定成本:不隨生產量、工作量或時間的變化而變化的非重複成本為固定成本。
3. 直接成本:直接可以歸屬於專案工作的成本為直接成本。如專案團隊差旅費、工資、專案使用的物料及裝置使用費等。
  - 一個專案獨佔的成本
4. 間接成本:來自一般管理費用科目或幾個專案共同擔負的專案成本所分攤給本專案的費用，就形成了專案的間接成本，如稅金、額外福利和保衛費用等。
  - 幾個專案分攤的成本
5. 機會成本:是利用一定的時間或資源生產一種商品時，而失去的利用這些資源生產其他最佳替代品的機會就是機會成本，泛指一切在做出選擇後其中一個最大的損失。
  - 做一個專案就要放棄另一個專案，那個專案可以賺的錢就沒辦法獲得
6. 沉沒成本:是指由於過去的決策已經發生了的，而不能由現在或將來的任何決策改變的成本。沉沒成本是一種歷史成本，對現有決策而言是不可控成本，會很大程度上影響人們的行為方式與決策，在投資決策時應排除沉沒成本的干擾。
  - 花出去了沒作用
應急儲備是是包含在成本基準內的一部分預算，用來應對已經接受的己識別風險，以及已經制訂應急或減輕措施的已識別風險。應急儲備通常是預算的一部分，用來應對那些會影響專案的“已知一未知”風險。
管理儲備是為了管理控制的目的而特別留出的專案預算，用來應對專案範圍中不可預見的工作。管理儲備用來應對會影響專案的“未知一未知”風險。管理儲備不包括在成本基準中，但屬於專案總預算和資金需求的一部分，使用前需要得到高層管理者審批。
- 做正則分析和預測技術的時候一定不要管管理儲備
成本基準是經批准的按時間安排的成本支出計劃，並隨時反映了經批准的專案成本變更（所增加或減少的資金數目），被用於度量和監督專案的實際執行成本。

9.2制訂專案成本管理計劃

9.2.1專案成本管理計劃制訂的輸入

專案管理計劃
專案章程
事業環境因素
組織過程資產

9.2.2專案成本管理計劃制訂的工具與技術

專家判斷
分析技術
會議

9.2.3專案成本管理計劃制訂的輸出

成本管理計劃是專案管理計劃的組成部分，描述將如何規劃、安排和控制專案成本。包含:
1. 精確等級
2. 測量單位:
3. 組織程式連結
4. 控制臨界值
5. 掙值規則
6. 報告格式:
7. 過程說明:
8. 其他細節

9.3專案成本估算

9.3.2專案成本估算的主要步驟

==*(必考)==編制專案成本估算需要進行以下3個主要步驟。
1. 識別並分析成本的構成科目。
  - 哪些地方需要花錢
2. 根據已識別的專案成本構成科目，估算每一科目的成本大小。
  - 各個地方需要花多少錢
3. 分析成本估算結果，找出各種可以相互替代的成本，協調各種成本之間的比例關係。
  - 成本最優化

9.3.3專案成本估算所採用的技術和工具

專家判斷
類比估算
- 自上而下估算
引數估算
自下而上估算
- 由下而上做彙總
三點估算
儲備分析
質量成本
專案管理軟體
賣方投標分析:在成本估算過程中，可能需要根據合格賣方的投標情況，分析專案成本。
群體決策技術

9.3.4專案成本估算所採用的輸入、輸出

成本估算的輸入有以下7項。
1. 成本管理計劃
2. 人力資源管理計劃
3. 範圍基準
4. 專案進度計劃
5. 風險登記冊
6. 事業環境因素
7. 組織過程資產
成本估算的輸出
- 成本估算的輸出有以下3項。
  1. 活動成本估算:活動成本估算是對完成專案工作可能需要的成本的量化估算。
  2. 估算依據
  3. 專案檔案更新

9.4專案成本預算

9.4.1專案成本預算及作用

成本預算指將單個活動或工作包的估算成本彙總，以確立衡量專案績效情況的總體成本基準。專案範圍說明書提供了彙總預算，但活動或工作包的成本估算在詳細的預算請求和工作授權之前編制。
如果首先得到專案的總體估算，則成本預算是在專案成本估算的基礎上，更精確地估算專案總成本，並將其分攤到專案的各項具體活動和各個具體專案階段上，為專案成本控制制訂基準計劃的專案成本管理活動。成本估算的輸出結果是成本預算的基礎與依據，成本預算則是將已批准的專案總的估算成本進行分攤。

9.4.3制訂專案成本預算的步驟

==*（必考）==專案成本預算所必須經過的步驟以下:
1. 將專案總成本分攤到專案工作分解結構的各個工作包。
  - 將總成本分到工作包
2. 將各個工作包成本再分配到該工作包所包含的各項活動上。
  - 講工作包的成本分到活動上
3. 確定各項成本預算支出的時間計劃及專案成本預算計劃。

9.4.4專案成本預算的工具與技術

成本彙總
儲備分析
專家判斷
歷史關係:有關變數之間可能存在一些可據以進行引數估算或類比估算的歷史關係。可以基於這些歷史關係，利用專案特徵（引數）來建立數學模型，預測專案總成本。
- 既可能是類比估算，也可能是引數估算，總之就是和歷史有關係
資金限制平衡:應該根據對專案資金的任何限制，來平衡資金支出。如果發現資金限制與計劃支出之間的差異，則可能需要調整工作的進度計劃，以平衡資金支出水平。
- 花錢比較平穩，沒有較大起伏

9.4.5專案成本預算的輸入、輸出

專案成本預算的輸入
1. 成本管理計劃
2. 範圍基準
3. 活動成本估算
4. 估算依據
5. 專案進度計劃
6. 資源日曆
7. 風險登記冊
8. 協議
9. 組織過程資產
專案成本預算的輸出
1. 成本基準:成本基準是經過批准的、按時間段分配的專案預算，不包括任何管理儲備，只有通過正式的變更控制程式才能變更，用作與實際結果進行比較的依據。成本基準是不同進度活動經批准的預算的總和。
  - 應急儲備在成本基準內
    - 已知的未知事件
2. 專案資金需求

專案檔案重新

軟考2.0.assets/image-20201002114634481.png

專案預算=管理儲備+成本基準
- 未知的未知事件

9.5專案成本控制

9.5.2專案成本控制所用的工具與技術

掙值管理，有專門的課會講。
預測
完工尚需績效指數
績效審查
專案管理軟體
儲備分析

9.5.3專案成本控制的輸入、輸出

成本控制的輸入:成本控制的輸入有如以下幾項。
1. 專案管理計劃
2. 專案資金需求
3. 工作績效資料
4. 組織過程資產
成本控制的輸出
1. 工作績效資訊
2. 成本預測
3. 變更請求
4. 專案管理計劃更新
5. 專案檔案更新
6. 組織過程資產更新

正則分析

從S點到C點
預測分析：從C點到F點

軟考2.0.assets/image-20201012094048934.png

PV（PlannedValue）計劃值
- 計劃中，從開始點到檢查點我們應該完成的工作量的價值
EV（EarnedValue）掙值
- 計劃中，從開始點到檢查點我們已經完成的工作量的價值
AC（ActualCost）實際成本
- 從開始點到檢查點我們的實際的支出
1. PV：200
2. EV：250
3. AC：260
- =單位都是錢

軟考2.0.assets/image-20201012094938876.png 軟考2.0.assets/image-20201012095000699.png

CV（CostVariance）成本偏差
- CV=EV-AC
SV（ScheduleVariance）進度偏差
- SV=EV-PV
CPI（CostPerformanceIndex）成本執行指數
- CPI=EV/AC
SPI （SchedulePerformanceIndex）進度執行指數
- SPI=EV/PV

EV都是在前面/上面
偏差-，執行指數/
成本：AC，進度：PV
好事
- 減法>0
- 除法>1
- 成本節約
- 進度超前

軟考2.0.assets/image-20201012100922580.png

ETC （Estimate (or Estimated) To Complete）完工時尚需成本估算
- 估算從C點到F點還要多少成本
EAC：[Estimate at completion] 完成預估
- 從C點估算S點到到F點的總成本
- EAC=ETC+AC
BAC：（budget at completion）：預算
- 60*5=300
典型與非典型
- 知錯不改（和前面一樣）：典型的SB
- 非典型：特別的
ETC=（BAC-EV）/CPI
- 典型除
- 非典型不除

軟考2.0.assets/image-20201012102947089.png

VAC=BAC-EAC

13、質量管理

10.1專案質量管理概論

10.1.3專案質量管理

==*==具體包括“規劃質量管理”“實施質量保證”和“質量控制”
1. 寫一個文件，關於質量要求/標準是什麼&如何做好質量管理

10.2規劃質量管理

10.2.2規劃質量管理的輸入

專案管理計劃
干係人登記冊
- 登記這個專案有哪些干係人
風險登記冊
- 登記這個專案有哪些風險
需求檔案
事業環境因素
組織過程資產

10.2.3規劃質量管理的工具與技術

成本效益分析法:對每個質量活動進行成本效益分析，就是要比較其可能的成本與預期的效益。達到質量要求的主要效益包括減少返工、提高生產率、降低成本、提升干係人滿意度及提升贏利能力。
- 成本/效益<1
質量成本法
- 達成質量所消耗的成本
七種基本質量工具
1. 因果圖，又稱魚骨圖或石川馨圖，用來追溯問題來源，回推到可行動的根本原因。通過看問題陳述和問“為什麼”來發現原因，直到發現可行動的根本原因，或者列盡每根魚骨上的合理可能性。
  - 用來找到產生問題的全部原因
2. 流程圖，也稱過程圖，用來顯示在一個或多個輸入轉化成一個或多個輸出的過程中，所需要的步驟順序和可能分支。
  - 用來找到在哪一步產生問題
3. 核查表，又稱計數表，是用於收集資料的查對清單。
4. 帕累託圖，用於識別造成大多數問題的少數重要原因。
5. 直方圖，用於描述集中趨勢、分散程度和統計分佈形狀。
6. 控制圖，可以判斷某一過程處於控制之中還是處於失控狀態。
  - 沒有超過上線/上線就出去控制之中
7. 散點圖，可以顯示兩個變數之間是否有關係，一條斜線上的資料點距離越近，兩個變數之間的相關性就越密切。
  - 兩個點越接近，關係越緊密
標杆對照:標杆對照是將實際或計劃的專案實踐與可比專案的實踐進行對照，以便識別最佳實踐，形成改進意見，併為績效考核提供依據。
實驗設計:實驗設計是一種統計方法，用來識別哪些因素會對正在生產的產品或正在開發的流程的特定變數產生影響。
統計抽樣
其他質量管理工具為定義質量要求並規劃有效的質量管理活動，也可使用其他質量規劃工具，包括(但不限於):
1. 頭腦風暴。用於產生創意的一種技術。
2. 力場分析。顯示變更的推力和阻力的圖形。
3. 名義小組技術。先由規模較小的群體進行頭腦風暴，提出創意，再由規模較大的群體對創意進行評審。
會議

10.2.4規劃質量管理的輸出

質量管理計劃:質量管理計劃是專案管理計劃的組成部分，描述如何實施組織的質量政策，以及專案管理團隊準備如何達到專案的質量要求。質量管理計劃可以是正式，也可以是非正式的，可以是非常詳細的，也可以是高度概括的。
過程改進計劃:過程改進計劃是專案管理計劃的子計劃或組成部分。過程改進計劃詳細說明對專案管理過程和產品開發過程進行分析的各個步驟，以識別增值活動。
質量測量指標:質量測量指標專用於描述專案或產品屬性，以及控制質量過程將如何對屬性進行測量。質量測量指標的例子包括準時性、成本控制、缺陷頻率、故障率、可用性、可靠性和測試覆霞度等。
質量核對單:核對單是一種結構化工具，通常具體列出各項內容;用來核實所要求的一系列步驟是否已得到執行。
專案檔案更新

10.3實施質量保證

10.3.1實施質量保證概述

實施質量保證是審計質量要求和質量控制測量結果，確保採用合理的質量標準和操作性定義的過程。本過程的主要作用是，促進質量過程改進。
質量保證旨在建立對未來輸出或未完輸出(也稱正在進行的工作）將在完工時滿足特定的需求和期望的信心。
質量保證部門或類似部門經常要對質量保證活動進行監督。

旨在建立資訊
有質量保證部門

10.3.2實施質量保證輸入

質量管理計劃
過程改進計劃
質量測量指標
質量控制測量結果︰質量控制測量結果是質量控制活動的結果，用於分析和評估專案過程的質量是否符合執行組織的標準或特定要求。
專案檔案

10.3.3實施質量保證方法與工具

質量審計:質量審計，又稱質量保證體系稽核，是對具體質量管理活動的結構性的評審。質量審計的目標是:
1. 識別全部正在實施的良好及最佳實踐;
2. 識別全部違規做法、差距及不足;
3. 分享所在組織或行業中類似專案的良好實踐;
4. 積極、主動地提供協助，以改進過程的執行，從而幫助團隊提高生產效率;
5. 強調每次審計都應對組織經驗教訓的積累做出貢獻。
- 質量審計可以是事先安排，也可隨機進行。在具體領域中有專長的內部審計師或第三方組織都可以實施質量審計可由內部或外部審計師進行。
過程分析:過程分析是指按照過程改進計劃中概括的步驟來識別所需的改進。它也要檢查在過程執行期間遇到的問題、制約因素，以及發現的非增值活動。過程分析包括根本原因分析----用於識別問題、探究根本原因，並制訂預防措施的一種具體技術。
==*==質量管理和控制工具
1. 親和圖。針對某個問題，產生出可聯成有組織的想法模式的各種創意。在專案管理中，使用親和圖確定範圍分解的結構，有助於WBS的制訂。
  - 思維拓展
  - 範圍制定
2. 過程決策程式圖(PDPC)。用於理解一個目標與達成此目標的步驟之間的關係。PDPC有助於制訂應急計劃，因為它能幫助團隊預測那些可能破壞目標實現的中間環節。
  - 那些過程會造成那些結果
3. 關聯圖。它是關係圖的變種，有助於在包含相互交叉邏輯關係的中等複雜情形中創新性地解決問題。
  - 在錯綜複雜的邏輯關係中創新性的解決問題
4. 樹形圖。它也稱系統圖，可用於表現諸如WBS、RBS和OBS的層次分解結構。
5. 優先矩陣。用來識別關鍵事項和合適的備選方案，並通過一系列決策，排列出=備選方案的優先順序。先對標準排序和加權，再應用於所有備選方案，計算出數學得分，對備選方案排序。
6. 活動網路圖。
7. 矩陣圖。一種質量管理和控制工具，使用矩陣結構對資料進行分析。在行列交叉的位置展示因素、原因和目標之間的關係強弱。

10.3.4實施質量保證輸出

變更請求
專案管理計劃更新
專案檔案更新
組織過程資產更新

10.4質量控制

10.4.1質量控制概述

質量控制是監督並記錄質量活動執行結果，以便評估績效，並推薦必要的變更的過程。本過程的主要作用，包括:
1. 識別過程低效或產品質量低劣的原因，建議並採取相應措施消除這些原因;
2. 確認專案的可交付成果及工作滿足主要干係人的既定需求，足以進行最終驗收。

10.4.2質量控制輸入

專案管理計劃
質量測量指標
質量核對單.
工作績效資料
批准的變更請求
可交付成果
專案檔案
組織過程資產

10.4.3質量控制工具與技術

七種基本質量工具
統計抽樣:可以降低質量控制的成本
檢查︰檢查是指檢驗工作產品，以確定是否符合書面標準。檢查的結果通常包括相關的測量資料。檢查可在任何層次上進行，例如可以檢查單個活動的成果，或者專案的最終產品。檢查也可稱為審查、同行審查、審計或巡檢等。檢查也可用於確認缺陷補救。
審查已批准的變更請求

10.4.4質量控制輸出

質量控制測量結果
確認的變更
核實的可交付成果
工作績效資訊
變更請求
專案管理計劃更新
專案檔案更新
組織過程資產更新

建議學的補充資料

一些關於質量管理方面的理論:
1. 以實用為核心的多元要求
2. 系統工程
3. 職工參與管理
4. 管理層和第一把手重視
5. 提高顧客滿意度
6. 預防勝於檢查-----質量是計劃出來的，而不是檢查出來的。
7. P、D、C、A
8. IS09000系列
9. 持續改進
10. 全面質量管理(TQM)是一種全員、全過程、全企業的品質管理。全員參加的質量管理、全過程的質量管理、全面方法的質量管理和全面結果的質量管理。
11. 六西格瑪:每一百萬產品中有3.4個產品有缺陷是可以接受的。
  - 六西格瑪的優越之處在於從專案實施過程中改進和保證質量，而不是從結果中檢驗控制質量。這樣做不僅減少了檢控質量的步驟，而且避免了由此帶來的返工成本。更為重要的是，六西格瑪管理培養了員工的質量意識，並且把這種質量意識融入企業文化中。
  - 六西格瑪管理法的核心是將所有的工作作為一種流程，採用量化的方法分析流程中影響質量的因素，找出最關鍵的因素加以改進從而達到更高的客戶滿意度，即採用DMAIC(確定、測量、分析、改進、控制）改進方法對組織的關鍵流程進行改進，而DMAIC又由下列4個要素構成:最高管理承諾、有關各方參與、培訓方案
    和測量體系。
質量保證:主要是提供信心，分為2種，內部質量保證和外部質量保證，一個是忽悠內部領導，一個是忽悠客戶。
專案質量保證活動包括:如何建立質量標準，如何確立質量控制流程，如何進行質量體系的評估。
質量保證人員，在整個專案中應該完成哪些工作??
1. 計劃階段制定質量管理計劃和相應的質量標準
2. 按計劃實施質量檢查，是否按標準過程實施專案工作。注意專案過程中的質量檢查，每次進行檢查之前準備檢查清單（checklist），並將質量管理相關情況予以記錄
3. 依據檢查的情況和記錄，分析問題，發現問題，與當事人協商進行解決。問題解決後要進行驗證;如果無法與當事人達成一致，應報告專案經理或更高層領導，直至問題解決
4. 定期給專案干係人髮質量報告
5. 為專案組成員提供質量管理要求方面的培訓或指導
質量保證(QA）過程實施質量計劃中確定的、系統的質量活動，如審計或同行審查，評價專案的整體績效，以確保專案能夠滿足相關的質量標準，同時，確保專案為了滿足專案干係人的期望實施了所有必需的過程，換而言之，實施質量保證是審計質量要求和質量控制測量結果，確保採用合理的質量標準和操作性定義的過程。專案質量保證活動是質量管理的一個更高層次，是對質量規劃和質量控制過程的質量控制。
專案質量保證的提供物件通常是專案管理班子和執行組織的管理層，而專案質量保證活動的參與者應是專案的全體工作人員。通常，質量保證人員(QA）的作用不僅限於發現和報告專案的問題。典型的QA的職責包括過程指導、過程評審、產品審計、過程改進和過程度量等。具體而言:
1. 在專案前期充當導師的角色，即QA輔助專案經理制訂專案計劃，包括根據質量體系中的標準過程裁剪得到的專案過程，幫助專案進行估算，以及設定質量目標等;對專案成員進行過程和規範的培訓，以及在過程中進行指導等;
2. 在專案實施過程中充當警察的角色，即QA有選擇性地參加專案的技術評審，定期對專案的工作產品和過程進行審計和評審;
3. 在專案實施過程中還充當醫生的角色，即QA也可能承擔收集、統計和分析度量資料的工作，用於支援管理決策。
專案質量控制過程一般要經歷以下基本步驟:
1. 選擇控制物件。專案進展的不同時期、不同階段，質量控制的物件和重點也不相同，需要在專案實施過程中加以識別和選擇。質量控制的物件，可以是某個因素、某個環節、某項工作或工序，以及專案的某個里程碑或某項階段成果等一切與專案質量有關的要素。
2. 為控制物件確定標準或目標。
3. 制定實施計劃，確定保證措施。
4. 按計劃執行。
5. 對專案實施情況進行跟蹤監測、檢查，並將監測的結果與計劃或標準相比較。
6. 發現並分析偏差。
7. 根據偏差採取相應對策:如果監測的實際情況與標準或計劃相比有明顯差異，則應採取相應的對策。
8. 質量管理方面可能存在的不足，應該怎麼解決?
  1. 沒有嚴格執行公司完善的質量管理體系;
  2. 沒有制定質量管理計劃;
  3. 沒有進行質量保證工作;
  4. 前期測試工作不充分。
  - 應該怎麼解決?
    1. 嚴格執行公司的質量管理體系規範工作流程;
    2. 制定質量管理計劃;
    3. 執行質量保證計劃;
    4. 調配相關資源（如:人、財、物等）加強後續質量保證工作;
    5. 加強後期的質量控制和測試;
    6. 提前加強產品互動後的客戶服務和維護工作;
    7. 加強溝通;
    8. 建議必要時修改質量基準爭取以最小的代價獲得使用者認可。
9. 如何提升專案質量?
  1. 強有力的領導;
  2. 建立組織級專案管理體系
  3. 建立組織級質量管理體系
  4. 建立組織級激勵制度
  5. 理解質量成本
  6. 提高專案文件質量
  7. 發展和遵從成熟度模型
  8. 軟體質量問題的產生原因可能有（根據實際背景來）:
    1. 管理者缺乏質量觀念，未從一開始就強調質量
    2. 開發者未將質量作為最重要而且必須完成的任務
    3. 沒有真正執行“決不把不合格的中間產品帶到下一階段”的規定;
    4. 沒有良好的激勵機制;
    5. 開發人員看不到提高質量對企業生存與發展的重要性，缺乏主人翁責任感;
    6. 沒有解決好質量管理者和開發者的關係;
    7. 對使用者的質量要求不瞭解，缺乏使用者滿意的思想;
    8. 使用者對軟體需求不清晰，缺乏二義性;
    9. 開發人員對使用者的需求理解有偏差甚至錯誤;
    10. 質量保證與質量控制的關係不清楚;
    11. 開發文件與管理文件對質量控制的作用不大;
    12. 軟體開發工具引發質量控制困難;
    13. 不遵守軟體開發標準和規範
    14. 缺乏有效的質量控制和管理
提升專案質量的基本步驟:
1. 建立專案質量目標;
2. 建立工作中的質量保證和質量控制規範;
3. 建立對質量（過程和產品）引數的度量體系;
4. 在專案中對過程和產品進行測量/檢查，將實際情況與目標和規範進行對比以發現質量問題，並對質量問題的處理進行監督和控制;
5. 對質量問題的出現次數和影響程度依次進行分析，找出原因並提出改進措施;
6. 在上述基礎上，不斷迴圈，堅持不懈地提升專案質量。
質量保證和質量控制的工作內容、區別;
- 區別:實施質量保證是針對過程改進和審計的，強調的是過程改進和信心保證。
  實施質量控制是按照質量要求、檢查具體可交付成果的質量，強調的是具體的可交付成果。
- 溫馨提示:質量保證是一項管理職能，包括所有的有計劃的系統地為保證專案能夠滿足相關的質量標準而建立的活動，應該貫穿於專案的整個生命期，一般由質量保證部門或者類似的專案來完成，而專案經理(PM)是不可以擔任質量保證人員（QA的）。

14、人力資源管理

11.1專案人力資源管理的定義及有關概念

11.1.1專案人力資源管理及其過程的定義

==*==專案人力資源管理包括如下過程。
1. 編制專案人力資源計劃:確定與識別專案中的角色、所需技能、分配專案職責和彙報關係，並記錄下來形成書面檔案，其中也包括專案人員配備管理計劃。
  - 寫一個文件，關於需要什麼人，需要什麼人做什麼事，什麼人向什麼人彙報，如何做好人力資源管理
2. 組建專案團隊:通過調配、招聘等方式得到需要的專案人力資源。
  - 組建好專案團隊
3. 建設專案團隊:培養提高團隊個人的技能，改進團隊協作，提高團隊的整體水平以提升專案績效。
  - 提高專案團隊能力，提高環境水平，增強互幫互助
4. 管理專案團隊:跟蹤團隊成員個人的績效和團隊的績效，提供反饋，解決問題並協調變更以提高專案績效
  - 做好團隊管理

11.2編制專案人力資源計劃

11.2.1編制專案人力資源計劃的工具與技術

==*==組織結構圖:組織結構圖用圖形表示專案彙報關係。最常用的有層次結構圖、矩陣圖、文字格式的角色描述等三種。
1. 人員關係
2. 責任分配
  - 任務分配矩陣或稱責任分配矩陣(RAM):用來表示需要完成的工作由哪個團隊成員負責的矩陣，或需要完成的工作與哪個團隊成員有關的矩陣。
3. 總體融合
RACI圖

11.2.2編制專案人力資源計劃的輸入

專案管理計劃
活動資源需求:通過估計專案各個活動使用的資源來決定整個專案所需的人力資源，可以確定所需的人員數量、專業和技能水平，對專案成員的數量及其能力的初步估計可以在專案人力資源計劃編制過程中再逐步細化。
事業環境因素
組織過程資產

11.2.3編制專案人力資源計劃的輸出:專案人力資源計劃

角色和職責的分配
專案的組織結構圖
人員配備管理計劃

11.3專案團隊組織建設

11.3.1組建專案團隊

輸入:
1. 專案人力資源管理計劃
2. 事業環境因素
3. 組織過程資產
工具和技術
1. 事先分派:在某些情況下，可以預先將人員分派到專案中。這些情況常常是:由於競標過程中承諾分派特定人員進行專案工作，或者該專案取決於特定人員的專業技能。
2. 談判
3. 招募:當執行組織缺少內部工作人員去完成這個專案時，就需要從外部獲得必要的服務，包括聘用或分包。
4. 虛擬團隊:虛擬團隊為團隊成員的招募提供了新的途徑。通過虛擬團隊的形式，我們可以:
  - 不需要面對面
  - 好處
    1. 在公司內部建立一個由不同地區員工組成的團隊。
    2. 為專案團隊增加特殊技能的專家，即使這個專家不在本地。
    3. 把在家辦公的員工納入虛擬團隊，以協同工作。
    4. 由不同班組（早班、中班和夜班）員工組成一個虛擬團隊。
    5. 把行動不便或殘疾的員工納入團隊。
    6. 可以實施那些原本因為差旅費用過高而被忽略的專案。
  - 壞處
    1. 虛擬團隊也有一些缺點，例如，可能產生誤解、有孤立感、團隊成員之間難以分享知識和經驗、採用通訊技術也要花費成本等。
    2. 在建立一個虛擬團隊時，制訂一個可行的溝通計劃就顯得更加重要。
5. 多維決策分析:在組建專案團隊過程中，經常需要使用團隊成員選擇標準。通過多維決策分析，制定出選擇標準，並據此對候選團隊成員進行定級或打分。根據各種因素對團隊的不同重要性，賦予每種因素不同的權重
輸出
1. 專案人員分配表:當適當的人選被分配到專案中併為之工作時，專案人員配置就完成了。
2. 資源日曆
3. 可能做出的專案管理計劃更新

11.3.2專案團隊建設

成功的專案團隊的特點
1. 團隊的目標明確，成員清楚自己的工作對目標的貢獻。
2. 團隊的組織結構清晰，崗位明確。
3. 有成文或習慣的工作流程和方法，而且流程簡明有效。
4. 專案經理對團隊成員有明確的考核和評價標準，工作結果公正公開、賞罰分明
5. 共同制訂並遵守的組織紀律。
6. 協同工作，也就是一個成員工作需要依賴於另一個成員的結果，善於總結和學習。
==*==優秀的團隊不是一蹴而就的，一般要依次經歷以下5個階段。
1. 形成階段:一個個獨立的個體成員轉變為團隊成員，開始形成共同目標，對未來團隊往往有美好的期待。
2. 震盪階段:團隊成員開始執行分配的任務，一般會遇到超出預想的困難，希望被現實打破。個體之間開始爭執，互相指責，並且開始懷疑專案經理的能力。
3. 規範階段:經過一定時間的磨合，團隊成員之間相互熟悉和了解，矛盾基本解決，專案經理能夠得到團隊的認可。
4. 發揮階段:隨著相互之間的配合默契和對專案經理的信任，成員積極工作，努力實現目標。這時集體榮譽感非常強，常將團隊換成第一稱謂，如“我們那個組”“我們部門”等，並會努力捍衛團隊聲譽。
5. 結束階段:隨著專案的結束，團隊也被遣散了。
- 不管目前團隊處於什麼階段，新增加一個人或減少一個人，都是從形成階段重新開始。
輸入:
1. 專案人力資源管理計劃
2. 專案人員分派表
3. 資源日曆
工具和技術
1. 人際關係技能
2. 培訓
3. 團隊建設活動:團隊建設活動包括專門的活動和個人行動，首要目的是提高團隊績效。團隊建設可以有多種形式，如日常的評審會議中5分鐘的議事日程、為了增進關鍵性專案的相關人員之間的人際關係而設計的專業的團隊拓展訓練等。
4. 基本規則:用基本規則對專案團隊成員的行為做出明確規定，規定哪些行為是可接受的，哪些是不可接受的。越早建立清晰的規則，就越能減少誤解、提高工作效率。
5. 集中辦公:集中辦公是指將所有或者幾乎所有重要的專案團隊成員安排在同一個工作地點，以增進他們作為一個團隊工作的能力。
6. 認可與獎勵
7. 人事測評工具:人事評測工具，能讓專案經理和專案團隊瞭解團隊成員的優勢和劣勢。有各種可用的工具，如態度調查、細節評估、結構化面談、能力測試及焦點小組討論。這些工具有利於增進團隊成員間的理解、信任、忠誠和溝通。
  - 專案經理通過小測試瞭解團隊人員
輸出
1. 團隊績效評估
2. 事業環境因素更新

11.4專案團隊管理

11.4.2專案團隊管理的工具和技術

觀察和交談:觀察和交談用於隨時瞭解團隊成員的工作情況和思想狀態。
專案績效評估∶在專案實施期間進行績效評估的目的是澄清角色、責任，從團隊成員處得到建設性的反饋，發現一些未知的和未解決的問題，制訂個人的培訓和訓練計劃，為將來一段時間制定具體目標。
衝突管理:在專案環境中，衝突不可避免。衝突的來源包括資源稀缺、進度優先順序排序和個人工作風格差異等。
人際關係技能

11.4.3衝突管理

在管理專案過程中，最主要的衝突有7種:進度、專案優先順序、資源、技術、管理過程、成本和個人衝突。
==*==當在一個團隊的環境下處理衝突時，專案經理應該認識到衝突的下列特點。
1. 衝突是自然的，而且要找出一個解決辦法。
  - 衝突是不可避免的
2. 衝突是一個團隊問題，而不是某人的個人問題。
3. 應公開地處理衝突。
  - 早期衝突–》私下
  - 晚期衝突–》公開
4. 衝突的解決應聚焦在問題，而不是人身攻擊。
5. 衝突的解決應聚焦在現在，而不是過去。
- 衝突有利有弊
- 衝突不是越少越好
衝突的根源還有如下因素。
1. 專案的高壓環境
2. 責任模糊
3. 存在多個上級
4. 新科技的使用。
衝突管理的6種方法
1. 問題解決:問題解決就是衝突各方一起積極地定義問題、收集問題的資訊、制定解決方案，最後直到選擇一個最合適的方案來解決衝突，此時為雙贏或多贏。但在這個過程中，需要公開地協商，這是衝突管理中最理想的一種方法。
2. 合作:集合多方的觀點和意見，得出一個多數人接受和承諾的衝突解決方案。
  - 少數服從多數
3. 強制:強制就是以犧牲其他各方的觀點為代價，強制採納一方的觀點。
4. 妥協:妥協就是衝突的各方協商並且尋找一種能夠使衝突各方都有一定程度滿意、但衝突各方沒有任何一方完全滿意、是一種都做一些讓步的衝突解決方法。
  - 各方都讓步·
5. 求同存異:求同存異的方法就是衝突各方都關注他們一致的一面，而淡化不一致的一面。一般求同存異要求保持一種友好的氣氛，但是迴避瞭解決衝突的根源。也就是讓大家都冷靜下來，先把工作做完。
6. 撤退:撤退就是把眼前的或潛在的衝突擱置起來，從衝突中撤退。

11.4.4專案團隊管理的輸入、輸出

輸入
1. 專案人力資源管理計劃
2. 專案人員分派表
3. 團隊績效評估
4. 問題日誌
5. 績效報告
6. 組織文化和組織過程資產
輸出
1. 變更請求
2. 已更新的專案管理計劃
3. 專案檔案更新
4. 事業環境因素更新
5. 已更新的組織過程資產
- 延伸閱讀:現代激勵理論及專案經理所需具備的影響力
1. 激勵理論
  1. 馬斯洛需要層次理論
  2. 赫茨伯格的雙因素理論
    - 第–類是保健因素，這些因素是與工作環境或條件有關的，能防止人們產生不滿意感的一類因素，包括工作環境、工資薪水、公司政策、個人生活、管理監督、人際關係等。當保健因素不健全時，人們就會產生不滿意感。但即使保健因素很好時，也僅僅可以消除工作中的不滿意，卻無法增加人們對工作的滿意感，所以這些因素是無法起到激勵作用的。
      - 人工
    - 第二類是激勵因素，這些因素是與員工的工作本身或工作內容有關的、能促使人們產生工作滿意感的一類因素，是高層次的需要，包括成就、承認、工作本身、責任、發展機會等。當激勵因素缺乏時，人們就會缺乏進取心，對工作無所謂，但一旦具備了激勵因素，員工則會感覺到強大的激勵力量而產生對工作的滿意感，所以只有這類因素才能真正激勵員工。
      - 飛機美女
  3. 期望理論
    - 期望理論認為，一個目標對人的激勵程度受兩個因素影響。
      1. 目標效價，指實現該目標對個人有多大價值的主觀判斷。如果實現該目標對個人來說很有價值，個人的積極性就高;反之，積極性就低。
        中獎金額
      2. 期望值，指個人對實現該目標可能性大小的主觀估計。只有個人認為實現該目標的可能性很大，才會去努力爭取實現，從而在較高程度上發揮目標的激勵作用;如果個人認為實現該目標的可能性很小，甚至完全沒
        有可能，目標激勵作用則小，以至完全沒有。
        中獎人數
  4. X理論、Y理論
    1. X理論
      - X理論主要體現了獨裁型管理者對人性的基本判斷，這種假設認為:
        一般人天性好逸惡勞，只要有可能就會逃避工作。
        人生來就以自我為中心，漠視組織的要求。
        人缺乏進取心，逃避責任，甘願聽從指揮，安於現狀，沒有創造性。
        人們通常容易受騙，易受人煽動。
        人們天生反對改革。
      - X叉錯惡
    2. Y理論
      - Y理論對人性的假設與X理論完全相反，其主要觀點為:
        一般人天生並不是好逸惡勞，他們熱愛工作，從工作得到滿足感和成就感。
        外來的控制和處罰對人們實現組織的目標不是一個有效的辦法，下屬能夠自我確定目標，自我指揮和自我控制。
        在適當的條件下，人們願意主動承擔責任。
        大多數人具有一定的想象力和創造力。
        在現代社會中，人們的智慧和潛能只是部分地得到了發揮。
      - YYes對善
5種基本的權力分別介紹如下。
1. 合法的權力，是指在高階管理層對專案經理正式授權的基礎上，專案經理讓員工進行工作的權力。
2. 強制力，是指用懲罰、威脅或者其他消極手段強迫員工做他們不想做的事。然而，一般強制力在專案團隊的建設中不是一個很好的方法，通常會帶來專案的失敗，建議不要經常使用。
3. 專家權力，與泰穆汗和威廉姆的影響因素中的專門技術類似，就是用個人知識和技能讓員工改變他們的行為。如果專案經理讓員工感到他在某些領域有專長，那麼他們就會遵照專案經理的意見行事。
4. 獎勵權力，就是使用一些激勵措施來引導員工去工作。獎勵包括薪金、職位、認可度、特殊的任務以及其他的獎勵員工滿意行為的手段。大部分獎勵理論認為，一些特定的獎勵，如富有挑戰性的工作、工作成就以及認可度才能真正引導員工改變行為或者努力工作。
5. 感召權力。權力是建立在個人感召權力的基礎上。人們非常尊重某些具有感召權力的人，會按照他們所說的去做。
- 以上是專案經理的5個權力型別，建議專案經理最好用獎勵權力和專家權力來影響團隊成員去做事，儘量避免強制力。並且專案經理的合法權力、獎勵權力和強制力是來自公司的授權，而其他的權力則是來自專案經理本人。

建議學的補充資料

對於一個新分配來的專案團隊成員，專案經理應該負責確保他得到適當的培訓
人力資源管理中常見問題極其解決方式

15、溝通管理和干係人管理

12.1溝通的基本概念

12.1.1溝通的定義

溝通模型
溝通渠道計算:M=n* (n—1)/2，n為需要溝通是人數(5–>10)

11.1.2溝通的方式

==*(順序)==在進行溝通過程中，要根據溝通目標、參與者的特點選擇適合的溝通方式。一般溝通過程所採用的方式分為以下幾類:
1. 參與討論方式
2. 徵詢方式
3. 推銷方式（說明)
4. 敘述方式
1
- 從參與者（傳送資訊方）的觀點看，參與討論方式的控制力最弱，隨後逐步加強，以敘述方式的控制力最強。
- 從參與者（傳送資訊方）的觀點看，其他參與者的參與程度恰巧相反，也就是討論方式下參與程度最高，然後逐步減弱，以敘述方式下參與程度最弱。

12.2制訂溝通管理計劃

12.2.1制訂溝通管理計劃的輸入

專案管理計劃
干係人登記冊:干係人登記冊為專案的溝通計劃提供了干係人的資訊，從干係人登記冊中，可以知道專案中干係人的資訊:主要溝通物件（主要干係人)、關鍵影響人、次要溝通物件（次要干係人)。
事業環境因素
組織過程資產

12.2.2制訂溝通管理計劃的工具

分析溝通需求
溝通技術
溝通模型
溝通方法
- 可以使用多種溝通方法在專案干係人之間共享資訊。這些方法可以大致分為:
  1. 互動式溝通。在兩方或多方之間進行多向資訊交換。這是確保全體參與者對特定話題達成共識的最有效的方法，包括會議、電話、即時通訊、視訊會議等。
  2. 推式溝通。把資訊傳送給需要接收這些資訊的特定接收方。這種方法可以確保資訊的傳送，但不能確保資訊送達受眾或被目標受眾理解。推式溝通包括信件、備忘錄、報告、電子郵件、傳真、語音郵件、日誌、新聞稿等。
    - 傳送了資訊就不管了
  3. 拉式溝通。用於資訊量很大或受眾很多的情況。要求接收者自主、自行地訪問資訊內容。這種方法包括企業內網、電子線上課程、經驗教訓資料庫、知識庫等。

12.3.1管理溝通輸入

專案溝通管理計劃
工作績效報告
事業環境因素
組織過程資產

12.3.2管理溝通的工具

溝通技術
溝通模型
溝通方法
資訊管理系統
績效報告
- 專案經理在專案進行中，按照計劃要求，定期或不定期的要進行以下工作:
  1. 收集和釋出資訊;
  2. 分析現狀、進展以及預測結果的彙報績效的工作。

12.3.3管理溝通的輸出

專案溝通
更新的專案管理計劃
專案檔案更新
更新的組織過程資產

12.4控制溝通

在專案執行的過程中，需要對溝通過程進行適當的監督和控制，確保溝通過程的目的能夠實現。在進行溝通控制的過程中，有可能需要重新調整、更新或者重新制訂溝通管理計劃，也有可能需要重新調整、更新溝通過程的管理過程。

12.4.1溝通過程控制的輸入

專案管理計劃
專案溝通
問題日誌
工作績效資料
組織過程資產

12.4.2控制溝通的技術和方法

資訊管理系統
專家判斷
會議
- 專案的例會通常是專案中最重要的會議之一，一般以周為單位召開，是專案團隊內部溝通的主要平臺。對於某些大型專案也可以雙週或月為週期。一般來講，專案例會由專案經理主持召開，主要議題如下:
  1. 專案進展程度調查和彙報;
  2. 專案問題的解決;
  3. 專案潛在鳳險的評估;
  4. 專案團隊人力資源協調。
    - 專案啟動會議一般在專案團隊內部和外部分別舉行，內部啟動會議重要解決內的資源調配和約束條件的確認，而外部啟動會議主要是協調甲方和乙方的專案介面工作。
==*==專案總結會議的目的如下:
1. 瞭解專案全過程的工作情況以及相關的團隊或成員的績效狀況;
2. 瞭解出現的問題並提出改進措施;
3. 瞭解專案全過程中出現的值得吸取的經驗並進行總結;
4. 對總結過後的文件進行討論，通過後就存入公司的知識庫，從而形成公司的知識積累。

12.4.3控制溝通的輸出

工作績效資訊
變更請求
更新的專案管理計劃
更新的其他專案檔案
組織過程資產

12.5專案干係人管理

溝通管理和專案干係人管理的聯絡和區別:
1. 溝通管理強調對專案資訊的計劃、收集、儲存、組織、釋出，以及監控溝通以保證它的高效性。
2. 專案干係人管理強調的不僅是要管理干係人的期望，更要保證他們的適度參與，而後者是專案成功非常關鍵的因素之一。

12.5.1專案干係人管理所涉及的過程

專案干係人管理，並不是領導專案的干係人，而是對專案干係人的需要、希望和期望的識別，並通過溝通上的管理來滿足其需要、與干係人一起解決問題的多個過程。專案干係人管理努力爭取更多關係人的支援、努力降低干係人中的反對者的阻力，持續不斷地推動專案向目標前進，從而能夠確保專案取得成功。
由專案經理負責專案干係人管理
專案干係人管理的具體內容:
1. 識別干係人:首先，專案存在眾多專案干係人，專案干係人從專案中獲利或受損，對專案的開展會有推進或阻礙的作用。我們要分類找出所有的專案干係人，分析他們對專案的影響或者專案對他們的影響，還要知道影響有多大，因此需要“識別干係人”過程來完成這些任務。
  - 有哪些干係人+他們的需求是什麼
2. 編制專案干係人管理計劃
  - 識別出干係人後，專案經理還有依據專案跟干係人之間互相影響的大小、專案干係人的需要，確定干係人管理的思路，確定對專案干係人進行溝通的措施，並制定資訊溝通等級，為此要“編制專案干係人管理計劃”。
3. 管理干係人蔘與
  - 在專案的整個生命週期中，還要與專案的干係人維持不斷地溝通，解決他們之間的問題，這就需要“管理干係人蔘與”過程。
4. 專案干係人蔘與的監控
  - 在依據專案干係人管理計劃在專案整個生命週期中管理專案干係人時，還要根據需要定期地或者及時地監控干係人之間的關係，觀察計劃和實際之間的偏差，管理干係人之間的衝突，為專案推進助力，並儘量減少對專案的干擾。這個過程就是“專案干係人蔘與的監控”。

12.5.2識別專案干係人

在專案啟動時，就識別出關鍵干係人是非常重要的。
在專案的初期、在制定專案計劃之前，就要識別專案的干係人，並分析他們的利益層次、個人期望、重要性和影響力，這對專案成功非常重要。應該定期審查和更新早期所做的初步分析。
識別干係人的輸入
1. 專案章程
2. 採購檔案:如果專案是簽訂合同後才實施的，或者專案的一部分任務需要外包才能完成，那麼合同各方都是關鍵的專案干係人，合同就是重要的採購檔案。
3. 事業環境因素
4. 組織過程資產
識別干係人所使用的工具和技術
1. 組織相關會議
2. 專家判斷
3. 干係人分析:干係人分析是系統地收集和分析各種定量與定性資訊，以便確定每類干係人在整個專案中有哪些利益?有哪些要求?有哪些影響?受到哪些影響?.
*(可以自己畫出來)
識別干係人的輸出:干係人登記冊
- 識別出項目的所有干係人後，要把結果整理、記錄在干係人登記冊裡。干係人登記冊是識別干係人過程的主要成果，用於記錄已識別的干係人的所有詳細資訊，包括但不限於:
  1. 基本資訊如干系人的姓名、職位、地點、專案角色、聯絡方式。
  2. 用於評估的干係人資訊如主要需求、主要期望、對專案的潛在影響、與生命週期的哪個階段最密切相關。
  3. 干係人分類如關鍵干係人/非關鍵干係人、內部/外部、支持者/中立者/反對者等。因為一次識別不能窮盡所有的專案干係人，況且專案在動態地變化著，因此應定期檢查干係人登記冊，必要時補充、更新干系人登記冊，因為可能會識別出新的干係人、也可能調整登記冊。

12.5.3編制專案干係人管理計劃

在識別干係人之後、開始干係人管理工作之前，要先制訂一個計劃，以確定干係人的管理恩路。
隨著專案的進展，干係人及其參與專案的程度可能發生變化，因此編制干係人管理計劃是一個反覆的過程，是專案經理例行工作之一。
編制干係人管理計劃的輸入
1. 專案管理計劃
2. 干係人登記冊
3. 事業環境因素
4. 組織過程資產
編制干係人管理計劃的工具與技術
1. 組織相關會議
2. 專家判斷
3. 分析技術
在進行干係人識別過程中，專案經理已通過干係人分析技術把干係人分為如下各類:
1. 不瞭解。對專案和潛在影響不知曉。
2. 抵制。瞭解專案和潛在影響，抵制專案。
3. 中立。瞭解專案，既不支援，也不反對。
4. 支援。瞭解專案和潛在影響，支援專案。
5. 領導。瞭解專案和潛在影響，積極致力於保證專案成功。
- 可以使用“干係人蔘與評估矩陣”這個工具記錄干係人的當前參與程度，如圖12-7所示。其中，C表示干係人當前參與程度，D表示所需干係人蔘與程度。專案經理和專案管理團隊應該基於可獲取的資訊，確定專案當前階段所需要的干係人蔘與程度。
編制干係人管理計劃的輸出
1. 干係人管理計劃
2. 專案檔案更新

12.5.4管理干係人蔘與

管理干係人蔘與，就是依據干係人管理計劃，在整個專案生命週期中，與干係人進行日常的溝通和協作，以滿足其需要與期望，解決實際出現的問題，並促進干係人合理參與專案活動的過程。
管理干係人蔘與過程，實際上就是“實施干係人管理”的過程，本過程的主要作用:幫助專案經理提升來自干係人的支援、並把反對者的抵制降到最低，從而顯著提高專案成功的機會。
通過管理干係人蔘與，不僅讓干係人中的支持者清晰地理解專案目的、目標、收益和風險以爭取其支援，還要讓干係人中的反對者降低敵意，從而提高專案成功的概率。必要時還要請干係人協助指導專案活動和專案決策。
通常，干係人對專案的影響能力通常在專案啟動階段最大，而後隨著專案的進展逐漸降低。因此，專案經理負責調動各干係人蔘與專案時，應儘早開展，並對他們進行管理，必要時可以尋求專案發起人的幫助，以降低專案的風險和阻力。
管理干係人蔘與的輸入
1. 干係人管理計劃
2. 溝通管理計劃
3. 變更日誌
4. 組織過程資產
管理干係人蔘與的工具與技術
- 一般說來，管理干係人蔘與時要使用恰當的溝通方法、人際關係技能和管理技能等軟技能，在管理干係人蔘與過程中涉及的活動如下:
  1. 調動干係人適時參與專案，以獲取或確認他們對專案成功的持續承諾。
  2. 及時化解反對者的敵意、降低他們對專案的阻力、保證專案的持續開展。
  3. 通過協商和溝通，管理干係人的期望，確保實現專案目標。
  4. 處理尚未成為問題的干係人關注點，預測干係人在未來可能提出的問題。需要儘早識別和討論這些關注點，以便評估相關的專案風險。
  5. 澄清和解決已識別出的問題。
- 溝通方法
  1. 常用的溝通方法有:
    1. 互動式溝通。在兩方或多方之間進行多向資訊交換。這是確保全體參與者對特定話題達成共識的最有效的方法，包括會議、電話、即時通訊、視訊會議等。
    2. 推式溝通。把資訊傳送給需要接收這些資訊的特定接收方。這種方法可以確保資訊的傳送，但不能確保資訊送達受眾或被目標受眾理解。推式溝通包括信件、備忘錄、報告、電子郵件、傳真、語音郵件、日誌、新聞稿等。
    3. 拉式溝通。用於資訊量很大或受眾很多的情況。要求接收者自主自行地訪問資訊內容。這種方法包括企業內網、電子線上課程、經驗教訓資料庫、知識庫等。在管理干係人蔘與時，應該使用在溝通管理計劃中確定的針對每個干係人的溝通方法。基於干係人的溝通需
      求，專案經理決定在專案中如何使用、何時使用及使用哪種溝通方法。
  2. 人際關係技能
  3. 管理技能
管理干係人蔘與的輸出
1. 問題日誌
2. 變更請求
3. 專案管理計劃更新
4. 專案檔案更新
5. 組織過程資產更新

12.5.5控制干係人蔘與

控制干係人蔘與是一個監控過程:這個過程實時觀察計劃與實際之間的偏差，全面監督專案干係人之間的關係。發現問題時，及時調整策略和計劃，以調動干係人蔘與的過程。
在專案生命週期中，應該對干係人蔘與進行持續控制，並隨著專案進展和環境變化,維持並提升干係人蔘與活動的效率和效果。
控制干係人蔘與的輸入
1. 專案管理計劃
2. 問題日誌
3. 工作績效資料
4. 專案檔案
控制干係人蔘與的工具與技術
1. 資訊管理系統
2. 專家判斷
3. 組織相關會議
控制干係人蔘與的輸出
1. 工作績效資訊
2. 變更請求
3. 專案管理計劃更新
4. 專案檔案更新
5. 組織過程資產更新

建議學的補充資料

阻礙有效溝通的因
1. 溝通雙方的物理距離
2. 溝通的環境因素
3. 缺乏清晰的溝通渠道
4. 複雜的組織結構
5. 複雜的技術術語
6. 有害的態度
常用的溝通方式的優缺點或特點介紹如下:
溝通的原則:
1. 溝通內外有別
2. 非正式的溝通有利於關係的融洽
3. 採用對方能接受的溝通風格
4. 溝通的升級原則
  - 叫領導來幫忙溝通
5. 掃清溝通的障礙
如何召開一個高效的會議
1. 事先制定一個例會制度。
2. 放棄可開可不不開的會議
3. 明確會議的目的
4. 釋出會議通知
5. 在會議之前將會議材料發到參會人員
6. 明確會議規則

16、合同管理

13.1專案合同

13.1.2合同的法律特徵

合同是一種民事法律行為。
合同是一種雙方或多方或共同的民事法律行為。
合同以在當事人之間設立、變更、終止財產性的民事權利義務為目的。
訂立、履行合同，應當遵守相關的法律及行政法規。
合同依法成立，即具有法律約束力。

13.1.3有效合同原則

無效合同通常需具備下列任一情形:
1. 一方以欺詐、脅迫的手段訂立合同用來損害國家利益。
  - 一方以欺詐、脅迫的手段訂立合同沒有損害國家利益不算無效合同
2. 惡意串通，損害國家、集體或者第三人利益。
3. 以合法形式掩蓋非法目的。
4. 損害社會公共利益。
5. 違反法律、行政法規的強制性規定。

13.2專案合同的分類

13.2.1按資訊系統範圍劃分的合同分類

總承包合同，也稱“交鑰匙合同”，發包人把資訊系統工程建設從開始立項、論證、設計、採購、施工到竣工的全部任務，一併發包給一個具備資質的承包人。
- 這種承包方式有利於充分發揮那些在工程建設方面具有較強的技術力量、豐富的經驗和組織管理能力的大承包商的專業優勢，保證工程的質量和進度，提高投資效益。採用總承包的方式進行承包，發包人和承包人要簽訂總承包合同。這種總承包合同既可以用一個總合同的形式，也可以用若干個合同的形式來簽訂。
- 一個專案給一個承包商
單項工程承包合同，發包人將資訊系統工程建設的不同工作任務，分別發包給不同的承包人。單項工程承包方式有利於吸引較多的承包人蔘與投標競爭，使發包人有更大的選擇餘地;也有利於發包人對建設工程的各個環節、各個階段實施直接的監督管理。缺點是各個單項工程在技術標準、工作範圍、進度、資源等方面的協調和銜接容易出現問題。這種發包方式較適用於那些對工程建設有較強管理能力的發包人。
- 一個專案分模組給不同的承包商
分包合同，總承包單位將其承包的部分專案，再發包給子承包單位。簽訂分包合同應當同時具備兩個條件:第一，承包人只能將自己承包的非關鍵、非主體部分工程分包給具有
相應資質條件的分包人，而且不可以進行二次分包;第二，分包工程必須經過發包人同意。
- 一承包商做不完後再分給其他承包商，一承包商需要和發包人籤分包合同

13.2.2按專案付款方式劃分的合同分類

總價合同，這種合同型別能夠使建設單位在評標時易於確定報價最低的承包商，易於進行支付計算。適用於工程量不太大且能精確計算、工期較短、技術不太複雜、風險不大的專案，同時要求發包人必須準備詳細全面的設計圖紙和各項說明，使承包人能準確計算工程量。
- 小專案
成本補償合同，此類合同是由發包人向承包人支付為完成工作而發生的全部合法實際成本（可報銷成本)，並且按照事先約定的某一種方式外加一筆費用作為賣方的利潤。成本補償合同也可為承包人超過或低於預定目標（如成本、進度或技術績效目標）而規定財務獎勵條款。在這類合同中，發包人須承擔專案實際發生的一切費用，因此也承擔了專案的全部風險。承包人由於無風險，其報酬往往也較低。這類合同的缺點是發包人對工程造價不易控制，承包人也往往不注意降低專案成本。這類合同主要適用於以下專案。
- 花了多少成本+獎勵（約定）
1. 需立即開展工作的專案。
  - 火神山+雷神山
2. 對專案內容及技術經濟指標未確定的專案。
3. 風險大的專案。
工料合同，這類合同的適用範圍比較寬，其風險可以得到合理的分攤，並且能鼓勵承包人通過提高工效等手段從成本節約中提高利潤。這類合同履行中需要注意的問題是雙方對實際工作量的確定。
- 單價合同
- 網線–>5塊一條，最後算用了多少條網線

13.3專案合同簽訂

13.3.1專案合同的內容

根據合同法及工程實踐，主要有以下4種違約責任的承擔方式。
1. 繼續履行。
2. 採取補救措施(如質量不符合約定的，可以要求修理、更換、重作、退貨、減少價款或報酬等）。
3. 賠償損失。
4. 支付約定違約金或定金。

13.3.2專案合同簽訂的注意事項

在簽訂IT專案合同時應特別注意以下幾點
1. 質量驗收標準
2. 驗收時間
3. 技術支援服務
  - 對於開發完成後發生的技術性問題，如果是因為開發商的工作質量所造成的，應當由開發商負責無償地解決。一般期限是半年到一年。如果沒有這個期限規定，就視為企業所有的維護要求都要另行收費。
4. 保密約定

13.3.3專案合同談判與簽訂

關於合同不明確情況的處理
1. 當事人對標的物的質量要求不明確的，按國家標準和行業標準。沒有這些標準的，按產品通常標準或符合合同目的的標準執行。
2. 履行地點不明確時，按標的性質不同而定:接受貨幣在接受方，交付不動產的在不動產所在地，其他標的在履行義務方所在地。履行地在法律上具有非常重要的意義，它可以確定由誰負擔，貨物的所有權何時何處轉移，貨物丟失風險由誰承擔等，在訴訟中，也是確定管轄權的重要依據，所以簽訂合同對履行地條款要特別注意。
3. 履行期限不明的，債務人可隨時履行，債權人可隨時要求履行，但應給對方必要的準備時間。在這裡特別提醒債權人要注意訴訟時效（我國民事訴訟的一般訴訟時效為兩年)，關於隨時履行受不受訴訟時效的制約目前仍有爭議，不過最好在訴訟時效以內主張權利。
4. 履行費用負擔不明確的，由履行義務一方負擔。履行費用是履行義務過程中各種附隨發生的費用。在合同中應該考慮各種費用的分擔，如果沒有約定，視為由履行義務一方承擔。以上關於處理各種條款不明情況的法定標準，是根據長期交易形成的規律確定下來的，不管對誰有利和不利，都得按這個規定去履行。當然，最好還是把合同條款定得明確且嚴密，以免造成不必要的損失。

13.4專案合同管理

13.4.2合同管理的主要內容

主要包括合同簽訂管理、合同履行管理、合同變更管理以及合同檔案管理。作為一個重要的管理過程，合同管理有自己的依據、工具和技術，以及交付物。
1. 合同簽訂管理
  - 簽訂合同的前期調查每一項合同在簽訂之前，應當做好以下幾項工作。
    1. 應當做好市場調查。主要了解產品的技術發展狀況、市場供需情況和市場價格等。
    2. 應當進行潛在合作伙伴或者競爭對手的資信調查，準確把握對方的真實意圖，正確評判競爭的激烈程度。
    3. 瞭解相關環境，做出正確的風險分析判斷。
2. 合同履行管理
  - 按照條款履行
3. 合同變更管理
  - 變更申請、變更評估和變更執行等必須以書面形式呈現。
  - 合同變更控制系統的–般處理程式如下:
    1. 變更的提出。
    2. 變更請求的審查。
    3. 變更的批准。
    4. 變更的實施。
  - “公平合理”是合同變更的處理原則，變更合同價款按下列方法進行。
    1. 首先確定合同變更量清單，然後確定變更價款。
    2. 合同中已有適用於專案變更的價格，按合同已有的價格變更合同價款。
    3. 合同中只有類似於專案變更的價格，可以參照類似價格變更合同價款。
    4. 合同中沒有適用或類似專案變更的價格，由承包人提出適當的變更價格，經監理工程師和業主確認後執行。
4. 合同檔案管理
  - 合同檔案的管理，即合同檔案管理，是整個合同管理的基礎。專案經理使用合同檔案管理系統對合同文件和記錄進行管理。

13.5專案合同索賠處理

13.5.1索賠概念和型別

索賠是指承建單位在合同實施過程中，對非自身原因造成的工程延期、費用增加而要求建設單位給予補償損失的一種權利要求。而建設單位對於屬於承建單位應承擔責任造成的，且發生了實際損失的，向承建單位要求賠償，稱為反索賠。索賠的性質屬於經濟補償行為，而不是懲罰。索賠在一般情況下都可以通過協商方式友好解決，若雙方無法達成一致時，可通過仲裁或者訴訟解決。
按索賠的目的分類可分為工期索賠和費用索賠。
1. 延遲工期
2. 補償費用
不屬於經濟懲罰,是補償

13.5.2索賠構成條件和依據

合同索賠構成條件
- 合同索賠的重要前提條件是合同一方或雙方存在違約行為和事實，並且由此造成了損失，責任應由對方承擔。對提出的合同索賠，凡屬於業主也無法預見到的客觀原因造成的延期，如特殊反常天氣達到合同中特殊反常天氣的約定條件、地震等，承包商可能得到延長工期補償，但得不到費用補償。對於屬於業主自身方面的原因造成拖延工期的，不僅應給承包商延長工期，還應給予費用補償。

13.5.3索賠的處理

專案發生索賠事件後，一般先由監理工程師調解，達成索賠認可共識，索賠認可遵循的一般流程如圖
- 可以不調節，直接訴訟
- 28天

17、採購管理

14.1採購管理的相關概念和主要過程

14.1.1概念和術語

採購是從專案團隊外部獲得產品、服務或成果的完整的購買過程。

14.1.2採購管理的主要過程

採購管理包括如下幾個過程。
1. 編制採購計劃。決定採購什麼,何時採購，如何採購，還要記錄專案對於產品、服務或成果的需求，並且尋找潛在的供應商。
2. 實施採購。從潛在的供應商處獲取適當的資訊、報價、投標書或建議書。選擇供方，稽核所有建議書或報價，在潛在的供應商中選擇，並與選中者談判最終合同。
3. 控制採購。管理合同以及買賣雙方之間的關係，監控合同的執行情況。稽核並記錄供應商的績效以採取必要的糾正措施，並作為將來選擇供應商的參考。管理與合同相關的變更。
4. 結束採購。完成單次專案採購的過程。

14.2編制採購管理計劃

編制採購計劃過程的第一步是要確定專案的哪些產品、服務和成果是專案團隊自己提供合算，還是通過採購來滿足更為合算。如果需採購還要確定採購的方法和流程以及找出潛在的賣方，以確定採購多少、何時採購，並把這些結果都寫到專案採購計劃中。
- 自制/外購分析
在編制採購計劃過程期間，專案進度計劃對採購計劃有很大的影響。

14.2.1編制採購計劃的輸入、輸出

輸入
1. 專案管理計劃
2. 需求文件
3. 風險登記冊
4. 活動資源要求:活動資源要求裡有對人員、裝置或地點的具體需求的資訊，可以使用活動資源要求進行活動成本估算，進而判斷有關的專案工作是自制合算還是外購合算。
5. 專案進度
6. 活動成本估算
7. 干係人登記冊
8. 事業環境因素
9. 組織過程資產

一般來說，可把合同分成三種，即總價合同、成本補償合同和工料合同。總價合同，進一步細分為:固定總價合同和變動總價合同兩種。變動總價合同可以進一步劃分為總價加激勵費用合同和總價加經濟價格調整合同成本補償合同:最常見的3種成本補償合同是:成本加固定費用合同、成本加激勵費用合同和成本加獎勵費用合同

輸出
1. 採購管理計劃
  - 採購什麼，什麼時候去採購，怎樣採購，採購管理
2. 採購工作說明書==（SOW）==
  1. 前言。對專案背景等資訊作簡單描述。
  2. 專案工作範圍。詳細描述專案的服務範圍，包括業務領域、流程覆蓋、系統範圍及其他等。
  3. 專案工作方法。專案擬使用的主要方法。
  4. 假定。專案進行的假定條件，具體內容需雙方達成。
  5. 工作期限和工作量估計。專案的時間跨度和服務期限，對於按人天計算費用的專案.需評估服務工作人天，並估算專案預算。
  6. 雙方角色和責任。分為供應商的職責和發包商的職責，並對關鍵角色的工作職責進行描述。
  7. 交付件。列出專案的主要交付物的資料，並對交付件的內容與質量要求進行描述。
  8. 完成以及驗收標準。列出專案的完成標準和階段完成標準，完成標準作為專案驗收的依據內容。
  9. 服務人員。列出供應商的人員名單及顧問資格資訊。描述在什麼情況下可進行供應商人員的變更。
  10. 聘用條款。對聘用供應商人員的級別要求、經驗要求及其他相關條款。
  11. 收費和付款方式。專案的付款方式、費用範圍和涉稅條款等。
  12. 變更管理。專案變更的管理過程、相關規定與約束條件等。
  13. 承諾。雙方承諾均已閱讀，理解並同意遵循上述協議書及其條款的約束。而且雙方同意，所提到的服務條款及其附件（包括工作說明書、變更授權以及雙方協議中的任何獨立完整的陳述)，取代所有的建議書或其他在此之前的書面或口頭協議等。
  14. 保密。遵守保密協議（保密條款另行簽署）。
3. 採購檔案
  - 相當於招標檔案=
  - 採購檔案用來得到潛在賣方的報價建議書。常見的採購檔案有方案邀請書(RFP)、報價邀請書(RFQ).徵求供應商意見書(RFI)、投標邀請書(IFB)、招標通知、洽談邀請以及承包商初始建議徵求書。
  1. 方案邀請書
    - 方案邀請書是用來徵求潛在供應商建議的檔案，有人稱RFP為請求建議書
  2. 報價邀請書
    - 報價邀請書是一種主要依據價格選擇供應商時，用於徵求潛在供應商報價的檔案。一般專案執行組織多在涉及簡單產品的招標中使用RFQ。有人稱RFQ為請求報價單。
  3. 詢價計劃編制過程常用到的其他檔案
    - 用於不同型別採購的檔案還包括徵求供應商意見書、投標邀請書、招標通知、洽談邀請以及承包商初始建議徵求書。
    - RFI用來徵求供應商意見，以使需求明確化。如果需求很明確，則用方案邀請書，徵求供應商的建議書。
  4. 供方選擇標準
  5. “自制/外購”決策
  6. 變更申請
  7. 可能的專案檔案更新

14.2.3用於編制採購計劃過程的技術和方法

“自制/外購”分析
專家判斷
市場調研
會議

14.3實施採購

實施採購過程要做的工作如下:
1. 從潛在的賣方處獲取如何滿足專案需求的答覆，如投標書和建議書。通常在這個過程中由潛在的賣方完成大部分實際工作，專案或買方無需支付直接費用。
2. 接受多個潛在的賣方的標書或建議書後，運用供方選擇標準選擇一個或多個合適的賣方，並與選中的賣方簽訂合同。

14.3.1實施採購的輸入

採購管理計劃
採購檔案
供方選擇標準:這個標準在編制採購管理計劃過程中制訂，用來評價賣方的建議書或為其評分。
賣方建議書∶每一個賣方或者供方，在買方詢價過程中都會提供建議書。建議書提供評審的基本資訊。評價小組將對其進行評價，來選擇一個或多箇中標人（賣方)。
專案檔案
自制/外購決策
採購工作說明書
組織過程資產

14.3.2實施採購的方法和技術

投標人會議:投標人會議（也稱為投標前會議）是指在準備建議書之前與潛在供應商舉行的會議。投標人會議用來確保所有潛在供應商對採購目的(如技術要求和合同要求等）有一個清晰的、共同的理解。對供應商問題的答覆可能作為修訂條款包含到採購檔案中。在投標人會議上，所有潛在供應商都應得到同等對待，以保證一個好的招標結果。
建議書評價技術:對於複雜的採購，如果要基於賣方對既定加權標準的響應情況來選擇賣方，則應該根據買方的採購政策，按正式的建議書評審流程對各個潛在賣方的建議書進行評價，建議書評價委員會將做出他們的選擇，在授予合同之前，還要報管理層批准。
獨立估算:對於很多采購事項而言，採購組織能夠對其成本進行獨立的估算以檢查賣方建議書中的報價。如果報價與估算成本有很大差異，則可能表明合同工作說明書不適當、或者潛在賣方誤解或沒能完全理解和答覆工作說明書、或者市場已經發生了變化。獨立估算常被稱為“合理費用”估算。
專家判斷
刊登廣告
分析技術
採購談判

14.3.3實施採購的輸出

選中的賣方
合同
資源日曆
變更請求
專案管理計劃更新
專案檔案更新

14.4招投標

有專門的講課。

14.5控制採購

控制採購是管理採購關係、監督合同執行情況，並根據需要實施變更和採取糾正措施的過程。
控制採購過程是買賣雙方都需要的。該過程確保賣方的執行過程符合合同需求，確保買方可以按合同條款去執行。
對買方來說，控制採購過程的主要目標如下。
1. 保證合同的有效執行。專案執行組織在採購合同簽訂後，應該定時監督和控制供應商的產品供貨和相關的服務情況。要督促供應商按時提供產品和服務，保證專案的工期。
2. 保證採購產品及服務質量的控制。為了保證這個專案所使用的各項物力、人力資源是符合預計的質量要求和標準的，專案執行組織應該對來自於供應商的產品和服務進行嚴格的檢查和驗收工作，可以在專案組織中設立質量小組或質量工程師，完成質量的控制工作

14.5.1控制採購的輸入

專案管理計劃
採購檔案
合同
批准的變更請求
工作績效報告
工作績效資料

14.5.2控制採購過程使用的工具與技術

合同變更控制系統
檢查與審計:在專案執行過程中，應該根據合同規定，由買方開展相關的檢查與審計，賣方理應對此提供支援。通過檢查與審計，驗證賣方的工作過程或可交付成果對合同的遵守程度。如果合同條款允許，某些檢查與審計團隊中可以包括買方的採購人員。
採購績效審查:績效審查的目標在於發現履約情況的好壞、相對於採購工作說明書的進展情況，以及未遵循合同的情況，以便買方能夠量化評價賣方在履行工作時所表現出來的能力。
報告績效:根據合同要求，評估賣方提供的工作績效資料和工作績效報告，形成工作績效資訊，並向買方管理層報告。報告績效為管理層提供了賣方的執行資訊
支付系統:依據經檢查核實後的賣方績效，通常先由負責的專案團隊成員證明賣方的工作合格，再通過買方的應付賬款系統向賣方付款:依據合同賣方完成多少就付多少，支付過程要留下文字記錄。
索賠管理
記錄管理系統:專案經理採用記錄管理系統來管理合同、採購文件和相關記錄。

14.5.3控制採購的輸出

工作績效資訊
變更請求
專案管理計劃更新
專案檔案更新
組織過程資產更新

14.6結束採購

結束採購是完結本次專案採購的過程。完成每一次專案採購，都需要結束採購過程。
輸入
1. 專案管理計劃
2. 採購檔案
工具與技術
1. 採購審計
  - 從編制採購計劃過程一直到結束採購過程的整個採購過程中，採購審計都對採購的完整過程進行系統的審查。採購審計的目標是找出本次採購的成功和失敗之處，以供買方組織內的其他專案借鑑。
2. 採購談判
3. 記錄管理系統
輸出
1. 結束的採購
2. 組織過程資產更新

18、文件和配置管理

15.1資訊系統專案相關資訊（文件）及其管理

15.1.1資訊系統專案相關資訊

軟體文件分為三類:開發文件、產品文件、管理文件。
1. 開發文件描述開發過程本身，基本的開發文件是:
  1. 可行性研究報告和專案任務書;
  2. 需求規格說明;
  3. 功能規格說明;
  4. 設計規格說明，包括程式和資料規格說明;
  5. 開發計劃;
  6. 軟體整合和測試計劃;
  7. 質量保證計劃;
  8. 安全和測試資訊。
2. 產品文件描述開發過程的產物，基本的產品文件包括:
  1. 培訓手冊;
  2. 參考手冊和使用者指南;
  3. 軟體支援手冊;
  4. 產品手冊和資訊廣告。
3. 管理文件記錄專案管理的資訊，例如:
  1. 開發過程的每個階段的進度和進度變更的記錄;
  2. 軟體變更情況的記錄;
  3. 開發團隊的職責定義。
文件的質量可以分為四級:
1. 最低限度文件(1級文件)，適合開發工作量低於一個人月的開發者自用程式。該文件應包含程式清單、開發記錄、測試資料和程式簡介。
2. 內部文件(2級文件)，可用於沒有與其他使用者共享資源的專用程式(自用)。除1級文件提供的資訊外，2級文件還包括程式清單內足夠的註釋以幫助使用者安裝和使用程式。
3. 工作文件(3級文件)，適合於由同一單位內若干人聯合開發的程式，或可被其他單位使用的程式。
4. 正式文件(4級文件)，適合那些要正式發行供普遍使用的軟體產品。關鍵性程式或具有重複管理應用性質（如工資計算）的程式需要4級文件。

15.1.2資訊系統專案相關資訊（文件）管理的規則和方法

資訊系統文件的規範化管理主要體現在文件書寫規範、圖表編號規則、文件目錄編寫標準和文件管理制度等幾個方面。

15.2配置管理

配置管理定義:應用技術的和管理的指導和監控方法以標識和說明配置項的功能和物理特徵，控制這些特徵的變更，記錄和報告變更處理和實現狀態並驗證與規定的需求的遵循性
配置管理包括6個主要活動:制定配置管理計劃、配置標識、配置控制、配置狀態報告、配置審計、釋出管理和交付。

15.2.1配置管理的概念

典型配置項包括專案計劃書、需求文件、設計文件、原始碼、可執行程式碼、測試用例、執行軟體所需的各種資料，它們經評審和檢查通過後進入配置管理
所有配置項都應按照相關規定統一編號，按照相應的模板生成，並在文件中的規定章節(部分）記錄物件的標識資訊。在引入配置管理工具進行管理後，這些配置項都應以一定的目錄結構儲存在配置庫中。
在資訊系統的開發流程中需加以控制的配置項可以分為基線配置項和非基線配置項兩類，例如，基線配置項可能包括所有的設計文件和源程式等;非基線配置項可能包括專案的各類計劃和報告等。
所有配置項的操作許可權應由CMO(配置管理員）嚴格管理，基本原則是:基線配置項向開發人員開放讀取的許可權;非基線配置項向PM、CCB及相關人員開放。
配置項的狀態可分為“草稿”“正式”和“修改”三種。配置項剛建立時，其狀態為“草稿”。配置項通過評審後，其狀態變為“正式”。此後若更改配置項,則其狀態變為“修改”。當配置項修改完畢並重新通過評審時，其狀態又變為“正式”。
配置項版本號
- 配置項的版本號規則與配置項的狀態相關。
  1. 處於“草稿”狀態的配置項的版本號格式為0.Yz,
    - YZ的數字範圍為01～99。隨著草稿的修正，
    - YZ的取值應遞增。YZ的初值和增幅由使用者自己把握。
  2. 處於“正式”狀態的配置項的版本號格式為X.Y，X為主版本號，取值範圍為1~9。
    - Y為次版本號，取值範圍為0～9。配置項第一次成為“正式”檔案時，版本號為1.0。如果配置項升級幅度比較小，可以將變動部分製作成配置項的附件，附件版本依次為1.0，.1.1;……。當附件的變動積累到一定程度時，配置項的Y值可適量增加，Y值增加一定程度時，X值將適量增加。當配置項升級幅度比較大時，才允許直接增大X值。
  3. 處於“修改”狀態的配置項的版本號格式為X.YZ。配置項正在修改時，一般只增大Z值，X.Y值保持不變。當配置項修改完畢，狀態成為“正式”時，將Z值設定為0,增加X.Y值。參見上述規則（2)。
配置項版本管理
- 配置項的版本管理作用於多個配置管理活動之中，如配置標識、配置控制和配置審計、釋出和交付等。在專案開發過程中，絕大部分的配置項都要經過多次的修改才能最終確定下來。對配置項的任何修改都將產生新的版本。由於我們不能保證新版本一定比舊版本“好”，所以不能拋棄舊版本。版本管理的目的是按照一定的規則儲存配置項的所有版本，避免發生版本丟失或混淆等現象，並且可以快速準確地查詢到配置項的任何版本。
配置基線（常簡稱為基線）由一組配置項組成，這些配置項構成一個相對穩定的邏輯實體。基線中的配置項被“凍結”了，不能再被任何人隨意修改。對基線的變更必須遵循正式的變更控制程式。
一組擁有唯一標識號的需求、設計、原始碼文卷以及相應的可執行程式碼、構造文卷和使用者文件構成一條基線。產品的一個測試版本（可能包括需求分析說明書、概要設計說明書、詳細設計說明書、已編譯的可執行程式碼、測試大綱、測試用例、使用手冊等）是基線的一個例子。
基線通常對應於開發過程中的里程碑，一個產品可以有多個基線，也可以只有一個基線。交付給外部顧客的基線-一般稱為發行基線,內部開發使用的基線一般稱為構造基線。
配置庫可以分為開發庫、受控庫、產品庫3種類型。
- 存放配置項的倉庫
1. 開發庫，也稱為動態庫、程式設計師庫或工作庫，用於儲存開發人員當前正在開發的配置實體，如:新模組、文件、資料元素或進行修改的已有元素。動態中的配置項被置於版本管理之下。動態庫是開發人員的個人工作區，由開發人員自行控制。庫中的資訊可能有較為頻繁的修改，只要開發庫的使用者認為有必要，無需對其進行配置控制，因為這通常不會影響到專案的其他部分。
2. 受控庫，也稱為主庫，包含當前的基線加上對基線的變更。受控庫中的配置項被置於完全的配置管理之下。在資訊系統開發的某個階段工作結束時，將當前的工作產品存入受控庫。
  - 階段性產品
  - 要修改要走流程
3. 產品庫,也稱為靜態庫、發行庫、軟體倉庫，包含已釋出使用的各種基線的存檔，被置於完全的配置管理之下。在開發的資訊系統產品完成系統測試之後，作為最終產品存入產品庫內，等待交付使用者或現場安裝。
  - 最終產品
配置庫的建庫模式有兩種:按配置項型別建庫和按任務建庫。
1. 按配置項的型別分類建庫，適用於通用軟體的開發組織。使用這樣的庫結構有利於對配置項的統一管理和控制，同時也能提高編譯和釋出的效率。但由於這樣的庫結構並不是面向各個開發團隊的開發任務的，所以可能會造成開發人員的工作目錄結構過於複雜，帶來一些不必要的麻煩。
2. 按開發任務建立相應的配置庫，適用於專業軟體的開發組織。在這樣的組織內，使用的開發工具種類繁多，開發模式以線性發展為主，所以就沒有必要把配置項嚴格地分類儲存，人為增加目錄的複雜性。對於研發性的軟體組織來說，採用這種設定策略比較靈活。
配置管理員負責為每個專案成員分配對配置庫的操作許可權，另外，課本里的圖是錯的
配置控制委員會(CCB)，負責對配置變更做出評估、審批以及監督已批准變更的實施。
CCB建立在專案級，其成員可以包括專案經理、使用者代表、產品經理、開發工程師、測試工程師、質量控制人員、配置管理員等。CCB不必是常設機構，完全可以根據工作的需要組成，例如按變更內容和變更請求的不同，組成不同的CCB。小的專案CCB可以只有一個人，甚至只是兼職人員。通常，CCB不只是控制配置變更，而是負有更多的配置管理任務，例如:配置管理計劃審批、基線設立審批、產品釋出審批等。
配置管理員
- 配置管理員(CMO)，負責在專案的整個生命週期中進行配置管理活動，具體有:
  1. 編寫配置管理計劃;
  2. 建立和維護配置管理系統;
  3. 建立和維護配置庫;
  4. 配置項識別;
  5. 建立和管理基線;
  6. 版本管理和配置控制;
  7. 配置狀態報告;
  8. 配置審計;
  9. 釋出管理和交付;
  10. 對專案成員進行配置管理培訓。

15.2.2制定配置管理計劃

配置管理計劃是對如何開展專案配置管理工作的規劃，是配置管理過程的基礎，應該形成檔案並在整個專案生命週期內處於受控狀態。配置控制委員會負責審批該計劃。

15.2.3配置標識

配置標識也稱配置識別，包括為系統選擇配置項並在技術文件中記錄配置項的功能和物理特徵。配置標識是配置管理員的職能，基本步驟如下
1. 識別需要受控的配置項;
2. 為每個配置項指定唯一性的標識號;
3. 定義每個配置項的重要特徵;
4. 確定每個配置項的所有者及其責任;
5. 確定配置項進入配置管理的時間和條件;
6. 建立和控制基線;
7. 維護文件和元件的修訂與產品版本之間的關係。

15.2.4配置控制

配置控制即配置項和基線的變更控制，包括下述任務:標識和記錄變更申請，分析和評價變更，批准或否決申請，實現、驗證和釋出已修改的配置項。
變更評估
- CCB負責組織對變更申請進行評估並確定以下內容。
  1. 變更對專案的影響。
  2. 變更的內容是否必要。
  3. 變更的範圍是否考慮周全。
  4. 變更的實施方案是否可行。
  5. 變更工作量估計是否合理。

15.2.5配置狀態報告

配置狀態報告也稱配置狀態統計，其任務是有效地記錄和報告管理配置所需要的資訊，目的是及時、準確地給出配置項的當前狀況，供相關人員瞭解，以加強配置管理工作。
配置狀態報告應該包含以下內容:
1. 每個受控配置項的標識和狀態。一旦配置項被置於配置控制下，就應該記錄和儲存它的每個後繼進展的版本和狀態。
2. 每個變更申請的狀態和已批准的修改的實施狀態。
3. 每個基線的當前和過去版本的狀態以及各版本的比較。
4. 其他配置管理過程活動的記錄。
配置狀態報告應著重反映當前基線配置項的狀態，以向管理者報告系統開發活動的進展情況。配置狀態報告應定期進行，並儘量通過CASE工具自動生成。

15.2.6配置審計

配置審計也稱為配置稽核或配置評價，包括功能配置審計和物理配置審計，分別用以驗證當前配置項的一致性和完整性。
配置審計的實施是為了確保專案配置管理的有效性，體現了配置管理的最根本要求—不允許出現任何混亂現象,例如:
1. 防止向用戶提交不適合的產品，如交付了使用者手冊的不正確版本;
2. 發現不完善的實現，如開發出不符合初始規格說明或未按變更請求實施變更;
3. 找出各配置項間不匹配或不相容的現象;
4. 確認配置項己在所要求的質量控制稽核之後納入基線併入庫儲存;
5. 確認記錄和文件保持著可追溯性。
功能配置審計
- 功能配置審計是審計配置項的一致性（配置項的實際功效是否與其需求一致)，具體驗證以下幾個方面。
  1. 配置項的開發已圓滿完成。
  2. 配置項已達到配置標識中規定的效能和功能特徵。
  3. 配置項的操作和支援文件已完成並且是符合要求的。
物理配置審計
- 物理配置審計是審計配置項的完整性（配置項的物理存在是否與預期一致)，具體驗證如下幾個方面。
  1. 要交付的配置項是否存在。
  2. 配置項中是否包含了所有必需的專案。

15.2.7釋出管理和交付

釋出管理和交付活動的主要任務是:有效控制軟體產品和文件的發行和交付，在軟體產品的生存期內妥善儲存程式碼和文件的母拷貝。
大家去把儲存、複製、打包、交付、重建瞭解下。

建議學的補充資料

各角色在配置管理活動中的許可權

19、變更、安全管理

16.1專案變更的基本概念

16.1.2專案變更的分類

專案變更有多種分類方式，如:
1. 按變更性質分為重大變更、重要變更和一般變更，可通過不同審批許可權控制。
2. 按變更的迫切性分為緊急變更和非緊急變更，可通過不同的變更處理流程進行控制。

16.1.3專案變更產生的原因

專案變更的原因很多，常見的有:
1. 產品範圍（成果）定義的過失或者疏忽;
2. 專案範圍（工作）定義的過失或者疏忽;
3. 客戶提出新需求;
4. 應對鳳險的緊急措施或規避措施;
5. 專案執行過程與專案基準要求不一致帶來的被動調整（如進度、質量、成本等）;
6. 專案團隊人員調整;
7. 技術革新的要求;
8. 外部事件（例如政策變動或自然環境變化等）。

16.3變更管理角色職責與工作程式

16.3.1角色職責

變更申請人
- 是提出變更申請的相關人員，專案的任何干系人都可以提出變更申請
專案經理
- 對專案負責，也對整個專案變更管理過程負責。專案經理負責變更申請的影響分析，負責召開變更控制委員會會議，負責監控變更及已批准變更的正確實施等。
變更控制委員會(CCB）
- 是一個正式的組織，負責審查、評價、批准、推遲或否決專案變更。CCB由專案所涉及的多方人員共同組成，通常包括甲方和乙方的決策人員。作為決策機構，CCB在變更管理過程中負責對提交的變更申請進行審查，並對變更申請做出批准、否決或其他決定。
配置管理員:
- 變更過程的相關產物應納入配置管理系統中。配置管理員負責把變更後的基準納入整個專案基準中，變更過程中的其他記錄檔案也應納入配置管理系統。

16.3.2工作程式

==*==變更程式是
1. 提出變更中請
2. 變更影響分析
  - 專案經理在接到變更申請以後，首先要檢查變更申請中需要填寫的內容是否完備，然後對變更申請進行影響分析。變更影響分析由專案經理負責，專案經理可以自己或指定人員完成，也可以召集相關人員討論完成。
3. CCB審查批准
4. 實施變更
5. 監控變更實施
6. 結束變更

17.1資訊保安管理

17.1.1資訊保安含義及目標

保密性是指“資訊不被洩露給未授權的個人、實體和過程或不被其使用的特性。”資料的保密性可以通過下列技術來實現:(1）網路安全協議;(2）身份認證服務;(3）資料加密。
完整性是指“保護資產的正確和完整的特性。”簡單地說，就是確保接收到的資料就是傳送的資料。資料不應該被改變，這需要某種方法去進行驗證。確保資料完整性的技術包括:
(1）CA認證(2）數字簽名;(3）防火牆系統;(4）傳輸安全（通訊安全)(5）入侵檢測系統。
可用性是指“需要時，授權實體可以訪問和使用的特性。”可用性確保資料在需要時可以使用。可用性的技術如以下幾個方面:(1）磁碟和系統的容錯;(2）可接受的登入及程序效能;(3）可靠的功能性的安全程序和機制;(4）資料冗餘及備份。
不可抵賴性是指建立有效的責任機制，防止使用者否認其行為，這一點在電子商務中是極其重要的;而可靠性是指系統在規定的時間和給定的條件下，無故障地完成規定功能的概率，通常用平均故障間隔時間(MTBF）來度量。

17.2資訊系統安全

17.2.2資訊系統安全屬性

保密性
- 保密性是應用系統的資訊不被洩露給非授權的使用者、實體或過程，或供其利用的特性。即防止資訊洩漏給非授權個人或實體，資訊只為授權使用者使用的特性。應用系統常用的保密技術如下。
  1. 最小授權原則:對資訊的訪問許可權僅授權給需要從事業務的使用者使用。
  2. 防暴露:防止有用資訊以各種途徑暴露或傳播出去。
  3. 資訊加密:用加密演算法對資訊進行加密處理，非法使用者無法對資訊進行解密從而無法讀懂有效資訊。
  4. 物理保密:利用各種物理方法，如限制、隔離、掩蔽和控制等措施，保護資訊不被洩露。
完整性
- 完整性是資訊未經授權不能進行改變的特性。即應用系統的資訊在儲存或傳輸過程中保持不被偶然或蓄意地刪除、修改、偽造、亂序、重放和插入等破壞和丟失的特性。保障應用系統完整性的主要方法如下。
  1. 協議:通過各種安全協議可以有效地檢測出被複制的資訊、被刪除的欄位、失效的欄位和被修改的欄位
  2. 糾錯編碼方法:由此完成檢錯和糾錯功能。最簡單和常用的糾錯編碼方法是奇偶校驗法。
  3. 密碼校驗和方法:它是抗篡改和傳輸失敗的重要手段。
  4. 數字簽名:保障資訊的真實性。
  5. 公證:請求系統管理或中介機構證明資訊的真實性。
可用性
- 可用性是應用系統資訊可被授權實體訪問並按需求使用的特性。即資訊服務在需要時，允許授權使用者或實體使用的特性，或者是網路部分受損或需要降級使用時，仍能為授權使用者提供有效服務的特性。可用性還應該滿足以下要求:身份識別與確認、訪問控制（對使用者的許可權進行控制，只能訪問相應許可權的資源，防止或限制經隱蔽通道的非法訪問。包括自主訪問控制和強制訪問控制)、業務流控制（利用均分負荷方法，防止業務流量過度集中而引起網路阻塞)、路由選擇控制（選擇那些穩定可靠的子網、中繼線或鏈路等)、審計跟蹤（把應用系統中發生的所有安全事件情況儲存在安全審計跟蹤之中，以便分析原因，分清責任,及時採取相應的措施。審計跟蹤的資訊主要包括事件型別、被管資訊等級、事件時間、事件資訊、事件回答以及事件統計等方面的資訊）。
不可抵賴性
- 不可抵賴性也稱作不可否認性，在應用系統的資訊互動過程中，確信參與者的真實同一性。即所有參與者都不可能否認或抵賴曾經完成的操作和承諾。利用資訊源證據可以防止發信方不真實地否認已傳送資訊，利用遞交接收證據可以防止收信方事後否認已經接收的伯息。

17.2.3資訊系統安全管理體系

==*==資訊保安技術體系包含物理安全、執行安全、資料安全。分別都有什麼，請大家自己看教程P525-527，能做選擇區分

17.5應用系統安全管理

17.5.2應用系統執行中的安全管理

==*(按順序必背)==應用系統執行中涉及的安全和保密層次包括系統級安全、資源訪問安全、功能性安全和資料域安全。這4個層次的安全，按粒度從大到小的排序是:系統級安全、資源訪問安全、功能性安全、資料域安全。
1. ==*(必背)==資料域安全包括兩個層次，其一，是行級資料域安全，即使用者可以訪問哪些業務記錄，一般以使用者所在單位為條件進行過濾;其二，是欄位級資料域安全，即使用者可以訪問業務記錄的哪些欄位。
2. 使用者許可權的分配是否遵循“最小特權”原則。
企業要加強對應用系統安全執行管理工作的領導，每年至少組織有關部門對系統執行工作進行一次檢查。部門每季度進行一次自查。要加強對所轄範圍內應用系統執行工作的監督檢查。檢查可採取普查、抽查、專項檢查的方式定期或不定期地進行。
安全等級可分為保密等級和可靠性等級兩種，系統的保密等級與可靠性等級可以不同。保密等級應按有關規定劃為絕密、機密和祕密。可靠性等級可分為三級，對可靠性要求最高的為A級，系統執行所要求的最低限度可靠性為C級，介於中間的為B級。

17.6資訊保安等級保護

《資訊保安等級保護管理辦法》將資訊系統的安全保護等級分為以下五級。
1. 第一級，資訊系統受到破壞後，會對公民、法人和其他組織的合法權益造成損害，但不損害國家安全、社會秩序和公共利益。第一級資訊系統運營、使用單位應當依據國家有關管理規範和技術標準進行保護。
2. 第二級，資訊系統受到破壞後，會對公民、法人和其他組織的合法權益產生嚴重損害，或者對社會秩序和公共利益造成損害，但不損害國家安全。第二級資訊系統運營、使用單位應當依據國家有關管理規範和技術標準進行保護。國家資訊保安監管部門對該級資訊系統資訊保安等級保護工作進行指導。
3. 第三級，資訊系統受到破壞後，會對社會秩序和公共利益造成嚴重損害，或者對國家安全造成損害。第三級資訊系統運營、使用單位應當依據國家有關管理規範和技術標準進行保護。國家資訊保安監管部門對該級資訊系統資訊保安等級保護工作進行監督、檢查
4. 第四級，資訊系統受到破壞後，會對社會秩序和公共利益造成特別嚴重損害，或者對國家安全造成嚴重損害。第四級資訊系統運營、使用單位應當依據國家有關管理規範、技術標準和業務專門需求進行保護。國家資訊保安監管部門對該級資訊系統資訊保安等級保護工作進行強制監督、檢查。
5. 第五級，資訊系統受到破壞後，會對國家安全造成特別嚴重損害。第五級資訊系統運營、使用單位應當依據國家管理規範、技術標準和業務特殊安全需求進行保護。國家指定專門部門對該級資訊系統資訊保安等級保護工作進行專門監督、檢查。
==*（用系安結訪）==計算機系統安全保護能力的五個等級，即:使用者自主保護級、系統審計保護級、安全標記保護級、結構化保護級、訪問驗證保護級。

建議學的補充資料

計算機網路上的通訊面臨以下的四種威脅:
1. 截獲—從網路上竊聽他人的通訊內容。
2. 中斷—有意中斷他人在網路上的通訊。
3. 篡改―故意篡改網路上傳送的報文。
4. 偽選一偽造資訊在網路上傳送。
安全服務
1. 對等實體認證服務。對對方實體的合法性、真實性進行確認，以防假冒。
2. 資料保密服務。
3. 資料完整性服務。資料完整性服務用以防止非法實體對交換資料的修改、插入、刪除以及在資料交換過程中的資料丟失
4. 資料來源點認證服務。資料來源點認證服務用於確保資料發自真正的源點，防止假冒。
5. 禁止否認服務。
6. 犯罪證據提供服務。
數字證書:這是由認證機構經過數字簽名後發給網上資訊交易主體（企業或個人、裝置或程式）的一段電子文件。數字證書提供了PKI的基礎。
對稱與非對稱密碼演算法都可以用於加密，但是由於對稱密碼演算法加解密效率比非對稱演算法高很多，因此常用於對大量資料的加密。
1. 對稱加密技術:加密和解密函式都使用同一個金鑰的加密方式。常見的對稱加密方法有IDEA、DES、3DES等，其中IDEA金鑰長度為128位，DES有效金鑰長度為56位，3DES為112位。對稱加密具有:加/解密速度快，金鑰管理簡單，適宜一對一的資訊加密傳輸過程等優點，但是具有加密演算法簡單，金鑰長度有限，加密強度不高，金鑰分發困難，不適宜一對多的加密資訊傳輸等確定。
2. 非對稱加密技術:加密和解密函式使用不同的金鑰的加密方式。常見的非對稱加密方法有RSA。非對稱加密具有加密演算法複雜，金鑰長度任意，加密強度很高，適宜一對多的資訊加密交換等優點，但是具有加/解密速度慢，金鑰管理複雜的缺點。
病毒是一些可以自我複製到可執行檔案中的程式碼段。
特洛伊木馬是一種程式，可以隱藏在正常程式中，執行某種破壞功能。
蠕蟲是一種可以自我複製傳播且不需要宿主的完整的程式。程式可以自動生成一個自我拷貝並執行它，不需要任何的人為干預。
指令碼病毒出現在網頁中，木馬病毒分為潛入受害者計算機(Client客戶端）的木馬病毒程式和遠方遙控主程式（Server端），巨集病毒一般是感染office檔案。

20、風險管理

18.1風險概述

18.1.2風險的分類

按照性質劃分
1. 純粹風險
  - 純粹風險是指只有損失可能性而無獲利可能性的風險。
2. 投機風險
  - 投機鳳險是相對於純粹風險而言的，是指既有損失的可能又有獲利機會的風險。

18.1.3風險的性質

客觀性
- 風險是一種不以人的意志為轉移，獨立於人的意識之外的客觀存在。
偶然性
- 由於資訊的不對稱，未來風險事件發生與否難以預測。
相對性
- 風險性質會因時空各種因素變化而有所變化。
社會性
- 風險的後果與人類社會的相關性決定了風險的社會性，具有很大的社會影響力。
不確定性
- 發生時間的不確定性。

18.2專案風險管理

==*==專案風險管理包括規劃風險管理、識別風險、實施風險分析、規劃風險應對和控制風險等各個過程。專案風險管理的目標在於提高專案中積極事件的概率和影響，降低專案中消極事件的概率和影響。
1. 規劃風險管理
  - 它是定義如何實施專案風險管理活動的過程。
2. 識別風險
  - 它是判斷哪些風險可能影響專案並記錄其特徵的過程。
3. 實施定性風險分析
  - 它是評估並綜合分析風險的發生概率和影響，對風險進行優先排序，從而為後續分析或行動提供基礎的過程。
4. 實施定量鳳險分析
  - 它是就已識別風險對專案整體目標的影響進行定量分析的過程。
5. 規劃風險應對
  - 它是針對專案目標，制定提高機會、降低威脅的方案和措施的過程。
6. 控制鳳險
  - 它是在整個專案中實施風險應對計劃、跟蹤已識別風險、監督殘餘風險、識別新風險，以及評估風險過程有效性的過程。
組織和干係人的風險態度受多種因素影響，這些因素大體可分為以下三類。
1. 風險偏好。為了預期的回報，一個實體願意承受不確定性的程度。
2. 風險承受力。組織或個人能承受的風險程度、數量或容量。
3. 風險臨界值。干係人特別關注的特定的不確定性程度或影響程度。低於風險臨界值，組織會接受風險;高於風險臨界值，組織將不能承受風險。

18.3規劃風險管理

規劃風險管理是定義如何實施專案風險管理活動的過程。本過程的主要作用是確保風險管理的程度、型別和可見度與風險及專案對組織的重要性相匹配。

18.3.1規劃風險管理的輸入

專案管理計劃
專案章程
干係人登記冊
事業環境因素
組織過程資產

18.3.2規劃風險管理的工具與技術

分析技術
專家判斷
會議

18.3.3規劃風險管理的輸出

風險管理計劃是專案管理計劃的組成部分，描述將如何安排與實施風險管理活動。風險管理計劃包括以下內容。
1. 方法論:確定專案風險管理將使用的方法、工具及資料來源。
2. 角色與職責:確定風險管理計劃中每個活動的責任者和支持者，以及風險管理團隊的成員，並明確其職責。
3. 預算
4. 時間安排:確定在專案生命週期中實施鳳險管理過程的時間和頻率，
5. 風險類別
6. 風險概率和影響的定義
7. 概率和影響矩陣
8. 修訂的干係人承受力
9. 報告格式
10. 跟蹤

18.4識別鳳險

識別風險是判斷哪些風險可能影響專案並記錄其特徵的過程。本過程的主要作用是把識別出的風險記錄在案，併為專案團隊預測未來事件積累知識和技能。
專案經理應鼓勵全體專案人員參與潛在風險的識別工作
風險識別的原則包括:
1. 由粗及細，由細及粗。
2. 嚴格界定風險內涵並考慮鳳險因素之間的相關性。
3. 先懷疑，後排除。
4. 排除與確認並重。對於肯定不能排除但又不能肯定予以確認的風險按確認考慮。
5. 必要時，可作實驗論證。

全員參與，全過程參與

18.4.1識別風險的輸入

風險管理計劃
成本管理計劃
進度管理計劃
質量管理計劃
人力資源管理計劃
範圍基準
活動成本估算
活動持續時間估算
干係人登記冊
專案檔案
採購檔案
事業環境因素
組織過程資產

18.4.2識別風險的工具與技術

文件審查
資訊收集技術，可用於風險識別的資訊收集技術如下。
1. 頭腦鳳暴
2. 德爾菲技術
3. 訪談
4. 根本原因分析
核對單分析
假設分析
圖解技術
- 風險圖解技術可包括:
  1. 因果圖，又稱石川圖或魚骨圖，用於識別風險的起因。
  2. 系統或過程流程圖，顯示系統各要素之間的相互聯絡及因果傳導機制。
  3. 影響圖，用圖形方式表示變數與結果之間的因果關係、事件時間順序及其他關係。
sWOT分析:優勢、劣勢、機會和威脅
專家判斷

18.4.3識別風險的輸出

風險登記冊，最初的風險登記冊包括如下資訊。
1. 已識別風險清單
2. 潛在應對措施清單

18.5實施定性鳳險分析

實施定性風險分析是評估並綜合分析風險的概率和影響，對風險進行優先排序，從而為後續分析或行動提供基礎的過程。本過程的主要作用是，使專案經理能夠降低專案的不確定性級別，並重點關注高優先順序的風險。
實施定性風險分析根據風險發生的概率或可能性、風險發生後對專案目標的相應影響及其他因素（如應對時間要求，與專案成本、進度、範圍和質量等制約因素相關的組織風險承受力),來評估已識別風險的優先順序。
實施定性風險分析通常可以快速且經濟有效地為制訂風險應對措施建立優先順序，可以為實施定量風險分析(如果需要的話）奠定基礎。

18.5.1實施定性風險分析的輸入

風險管理計劃
範圍基準
風險登記冊
事業環境因素
組織過程資產

18.5.2實施定性風險分析的工具和技術

風險概率和影響評估
概率和影響矩陣旳風險值=風險發生的概率*風險發生後的後果
風險資料質量評估:風險資料質量評估是評估風險資料對風險管理的有用程度的一種技術，用來考察人們對風險的理解程度，以及考察風險資料的準確性、質量、可靠性和完整性。風險資料的質量，直接影響定性分析的結果。
風險分類
風險緊迫性評估:綜合考慮風險的緊迫性及從概率和影響矩陣中得到的風險等級，從而得到最終的風險嚴重性級別。
專家判斷

18.5.3實施定性風險分析的輸出

風險登記冊。
假設條件日誌。

18.6實施定量風險分析

實施定量風險分析是就已識別鳳險對專案整體目標的影響進行定量分析的過程。本過程的主要作用是，產生量化鳳險資訊，來支援決策制定，降低專案的不確定性
實施定量風險分析的物件是在定性風險分析過程中被確定為對專案的競爭性需求存在重大潛在影響的風險。實施定量風險分析過程就是分析這些風險對專案目標的影響，主要用來評估所有風險對專案的總體影響。在進行定量分析時，也可以對單個風險分配優先順序數值。
實施定量風險分析一般在實施定性風險分析過程之後開展，在沒有足夠的資料建立模型的時候，定量風險分析可能無法實施。

18.6.1實施定量風險分析的輸入

風險管理計劃
成本管理計劃
進度管理計劃
風險登記冊
事業環境因素
組織過程資產

18.6.2實施定量風險分析的工具與技術

資料收集和展示技術
1. 訪談
2. 概率分佈
定量風險分析和建模技術
1. 敏感性分析:敏感性分析有助於確定哪些風險對專案具有最大的潛在影響。
2. ==*==預期貨幣價值分析:預期貨幣價值(EMV）分析是當某些情況在未來可能發生或不發生時，計算平均結果的一種統計方法（不確定性下的分析）。
3. ==*==建模和模擬:專案模擬旨在使用一個模型，計算專案各細節方面的不確定性對專案目標的潛在影響。模擬通常採用蒙特卡洛技術。
專家判斷

18.6.3實施定量風險分析的輸出

風險登記冊

18.7規劃應對鳳險

18.7.1規劃風險應對的輸入

風險管理計劃
風險登記冊

18.7.2規劃風險應對的工具與技術

消極風險或威脅的應對策略
1. 規避
  - 如延長進度、改變策略或縮小範圍等。最極端的規避策略是關閉整個專案。在專案早期出現的某些風險，可以通過澄清需求、獲取資訊、改善溝通或取得專有技能來加以規避。
2. 轉移
  - 風險轉移可採用多種工具，包括(但不限於）保險、履約保函、擔保書和保證書等。可以利用合同或協議把某些具體風險轉移給另一方。例如，如果買方具備賣方所不具備的某種能力，為謹慎起見，可通過合同規定把部分工作及其風險再轉移給買方。在許多情況下，成本補償合同可把成本風險轉移給買方，而總價合同可把風險轉移給賣方。
3. 減輕
  - 減輕措施的例子包括採用不太複雜的流程，進行更多的測試，或者選用更可靠的供應商。它可能需要開發原型，以降低從實驗臺模型放大到實際工藝或產品過程中的風險。如果無法降低風險概率，也許可以從決定風險嚴重性的關聯點入手，針對風險影響來採取減輕措施。例如，在一個系統中加入冗餘部件，可以減輕主部件故障所造成的影響。
4. 接受
  - 風險接受是指專案團隊決定接受風險的存在，該策略可以是被動或主動的。被動接受策略不採取任何措施，只需要記錄本策略，而無需任何其他行動，待風險發生時再由專案團隊處理。不過，需要定期複查，以確保威脅沒有太大的變化。
    如果採取主動接受的策略，則要在風險發生前制定應急計劃。最常見的主動接受策略是建立應急儲備，安排一定的時間、資金或資源來應對風險。
積極風險或機會的應對策略
1. 開拓
  - 如果組織想要確保機會得以實現，就可對具有積極影響的風險採取本策略。本策略旨在消除與某個特定積極風險相關的不確定性，確保機會肯定出現。直接開拓包括把組織中最有能力的資源分配給專案來縮短完成時間，或者採用全新或改進的技術來節約成本，縮短實現專案目標的持續時間。
2. 提高
  - 本策略旨在提高機會的發生概率和積極影響。識別那些會影響積極風險發生的關鍵因素，並使這些因素最大化，以提高機會發生的概率。提高機會的例子包括為儘早完成活動而增加資源。
3. 分享
  - 分享積極風險是指把應對機會的部分或全部責任分配給最能為專案利益抓住該機會的第三方。分享的例子包括建立風險共擔的合作關係和團隊，以及為特殊目的成立公司或聯營體，以便充分利用機會，使各方都從中受益。
4. 接受
  - 接受機會是指當機會發生時樂於利用，但不主動追求機會。
應急應對策略
- 可以針對某些特定事件，專門設計一些應對措施。對於有些風險，專案團隊可以制定應急應對策略，即只有在某些預定條件發生時才能實施的應對計劃。
專家判斷

18.7.3規劃風險應對的輸出

專案管理計劃更新
專案檔案更新

18.8控制風險

控制風險是在整個專案中實施風險應對計劃、跟蹤已識別風險、監督殘餘風險、識別新風險，以及評估風險過程有效性的過程。本過程的主要作用是，在整個專案生命週期中提高應對風險的效率，不斷優化風險應對措施。

18.8.1控制風險的輸入

專案管理計劃
風險登記冊
工作績效資料
工作績效報告

18.8.2控制風險的工具和技術

風險再評估:在控制風險中，經常需要識別新風險，對現有風險進行再評估，以及刪去已過時的風險。應該定期進行專案風險再評估。反覆進行再評估的次數和詳細程度，應該根據相對於專案目標的專案進展情況而定。
風險審計:風險審計是檢查並記錄風險應對措施在處理已識別風險及其根源方面的有效性，以及風險管理過程的有效性。
偏差和趨勢分析
技術績效測量:技術績效測量是把專案執行期間所取得的技術成果與計劃取得的技術成果進行比較。
儲備分析
會議

18.8.3控制風險的輸出

工作績效資訊
變更請求
專案管理計劃更新
專案檔案更新
組織過程資產更新

建議學的補充資料

從客戶的角度來看，如果沒有管理好質量風險,將會造成最長久的影響
風險識別的特點:（1）全員性(2）系統性（3）動態性(4）資訊依賴性（5）綜合性。風險識別是一項反覆過程。隨著專案生命週期的推進，新鳳險可能會不斷出現
三點估算能評估時間與概率的關係，也可以用於風險評估

21、收尾管理、智慧財產權、職業道德

在實際工作中，廣義的系統整合專案收尾管理工作通常包含了四類典型的工作，即專案驗收工作、專案總結工作、系統維護工作以及專案後評價工作，此外專案團隊成員的後續工作也應在收尾管理時妥善安排。

19.1專案驗收

專案驗收是專案收尾管理中的首要環節，只有完成專案驗收工作後，才能進入後續的專案總結、系統維護以及專案後評價等工作階段。
具體而言，系統整合專案在驗收階段主要包含以下四方面的工作內容，分別是驗收測試、系統試執行、系統文件驗收以及專案終驗。
1. 驗收測試
  - 驗收測試是對資訊系統進行全面的測試，依照雙方合同約定的系統環境，以確保系統的功能和技術設計滿足建設方的功能需求和非功能需求，並能正常執行。驗收測試階段應包括編寫驗收測試用例，建立驗收測試環境，全面執行驗收測試，出具驗收測試報告以及驗收測試報告的簽署。
2. 系統試執行
  - 資訊系統通過驗收測試環節以後，可以開通系統試執行。系統試執行期間主要包括資料遷移、日常維護以及缺陷跟蹤和修復等方面的工作內容。為了檢驗系統的試執行情況，客戶可將部分資料或配置資訊載入到資訊系統上進行正常操作。
3. 系統文件驗收
  - 對於系統整合專案，所涉及的文件應該包括如下部分:
    1. 系統整合專案介紹;
    2. 系統整合專案最終報告;
    3. 資訊系統說明手冊;
    4. 資訊系統維護手冊;
    5. 軟硬體產品說明書、質量保證書等。
4. 專案終驗
  - 最終驗收報告就是業主方認可承建方專案工作的最主要檔案之一，這是確認專案工作結束的重要標誌。對於資訊系統而言，最終驗收標誌著專案的結束和售後服務的開始。

19.2專案總結

專案總結屬於專案收尾的管理收尾。而管理收尾有時又被稱為行政收尾，就是檢查專案團隊成員及相關干係人是否按規定履行了所有職責。實施行政結尾過程還包括收集專案記錄、分析專案成敗、收集應吸取的教訓，以及將專案資訊存檔供本組織將來使用等活動。
專案總結的主要意義如下。
1. 瞭解專案全過程的工作情況及相關的團隊或成員的績效狀況。
2. 瞭解出現的問題並進行改進措施總結。
3. 瞭解專案全過程中出現的值得吸取的經驗並進行總結。
4. 對總結後的文件進行討論，通過後即存入公司的知識庫，從而納入企業的過程資產。
專案總結會需要全體參與專案的成員都參加，並由全體討論形成檔案。

20.1智慧財產權概念

20.1.1智慧財產權的基本概念與範圍

狹義的智慧財產權就是傳統意義上的智慧財產權，包括著作權（含鄰接權)、專利權、商標權三個主要組成部分。

20.1.2智慧財產權的特性

智慧財產權的特性是從它的本質屬性即無體性派生出來的，具體包括無體性、專有性、地域性和時間性。

20.2智慧財產權的內容

20.2.2專利權

發明專利權的期限為20年，實用新型專利權、外觀設計專利權的期限為10年，均自申請日起計算。申請日是指向國務院專利行政主管部門提出專利申請之日。

20.2.3商標權

註冊商標的有效期為10年，自核準註冊之日起計算。註冊商標有效期滿，需要繼續使用的，應當在期滿前6個月內申請續展註冊;在此期間未能提出申請的，可以給予6個月的寬展期。每次續展註冊的有效期為10年，自該商標上一屆有效期滿次日起計算。寬展期滿仍未提出申請的，登出其註冊商標。

十大管理

每個管理領域有什麼過程

上一個過程的輸出就是下一個過程的輸入
還有其他

每一個過程有什麼輸入輸出，工具和技術

每一個過程有什麼問題，什麼原因，如何解決

每一個管理領域和其他領域有什麼關係

軟考2.0

不過，可以重複免費報名 02、案例分析、常見專案管理名詞（後續看）題型介紹

安踏雙 11 預售：小白鞋 69 元探底、C37 2.0 軟跑鞋 234 元

天貓安踏官方網店雙 11 預售活動開啟，店內休閒鞋、運動鞋（跑步鞋、籃球鞋、網球鞋等）等爆款商品限時低價，提前預定享受付定金立減優惠。部分優惠活動：店鋪首頁或商品價格下方領券享全店滿 400 元減 120 元、滿 4

不推薦使用Spring Boot 2.2.0 ，這個問題你肯定會遇到

專案推薦:Spring Cloud 、Spring Security OAuth2的RBAC許可權管理系統歡迎關注最近升級專案的依賴到最新版本

不推薦使用Spring Boot 2.2.0 ，這個問題你肯定會遇到（二）

專案推薦:Spring Cloud 、Spring Security OAuth2的RBAC許可權管理系統歡迎關注最新版本實踐

Spring Boot 2.0 整合 redis

從 Spring Boot 2.x 開始 Lettuce 已取代 Jedis 成為首選 Redis 的客戶端。當然 Spring Boot 2.x 仍然支援 Jedis，並且你可以任意切換客戶端。

Redis Manager(2.0) —— Redis 運維利器

Redis 作為一個基於記憶體的可持久化的日誌型、Key-Value 資料庫，以其出色的效能表現以及高可用性在許多公司有著舉足輕重的地位。伴隨著業務量的增長，Redis 叢集的規模不可避免的需要擴大，此時 Redis叢集的運維成

Spring Interceptor 自動注入FeignClient導致迴圈依賴2.0

1，bug現場還原問題描述我在寫攔截器的時候，多個類都是通過構造器注入，並且也在攔截器中通過構造器顯示宣告瞭依賴FeignClient，在專案啟動後，Spring依賴分析顯示，這些類產生了迴圈依賴

Swoft 2.0.7 如期而至

什麼是 Swoft ? Swoft 是一款基於 Swoole 擴充套件實現的 PHP 微服務協程框架。Swoft 能像 Go 一樣，內建協程網路伺服器及常用的協程客戶端且常駐記憶體，不依賴傳統的 PHP-FPM。有類似 Go 語言的協程操作方式，有類

Django 2 0 釋出，都有哪些新特性要注意？

Django 是 Python Web 開發最常用的框架之一，跟進它的最新變化絕對是必須的。 2017年12月2日，Django官方釋出了2.0版本，成為多年來的第一次大版本提升，那麼2.0對廣大Django使用者有哪些變化和需要注意的地方呢？

分散式任務排程框架 Azkaban —— Flow 2.0 的使用

一、Flow 2.0 簡介 1.1 Flow 2.0 的產生 Azkaban 目前同時支援 Flow 1.0 和 Flow2.0 ，但是官方檔案上更推薦使用 Flow 2.0，因為 Flow 1.0 會在將來的版本被移除。Flow 2.0 的主要設計思想是提供 1.0 所沒有的流級定

Swoft 2.0.6 正式版本釋出

Swoft 2.0.5 更新，新增高效秒級定時任務、異常管理元件

【最簡OAuth 2.0 教程】開發認證中心及資源伺服器接入

背景：網上很多講配置 oauth2 ，配置方法複雜紛繁對於初學者很不友好，讓人望而卻步

Mybatis-Plus3.2.0 MetaObjectHandler 無法進行公共欄位全域性填充

問題描述最近在做的這個專案架構組對於配置檔案決定，採取的是 .xml 配置檔案

Oracle 11.2.0.4打補丁的方法

所需補丁及高版本opatch image上傳後將p6880880_112000_Linux-x86-64.zip解壓覆蓋$ORACLE_HOME/OPatch目錄即可

Linux 7.4上安裝配置Oracle 11.2.0.4圖文教程

1. 配置Yum源及關閉SeLinux [root@localhost ~]# mkdir /media/rhel [root@localhost ~]# mount /dev/cdrom /media/rhel

CentOS 7.4下安裝Oracle 11.2.0.4資料庫的方法

在Linux下安裝Oracle資料庫是一件較為麻煩的事情。由於Linux的安裝過程中可能會選擇不同的安裝包，會導致Oracle安裝過程中缺失或多一些軟體包，很難一次性的安裝成功。所以，本文詳細記錄了Oracle在Linux上的安裝過

.netcore 2.0 System.Drawing

CentOS 下報錯 1.Unable to load shared library ‘libdl‘ 解決方法：建立軟連結 #locate libdl

win7上tensorflow2.2.0安裝成功引用DLL load failed時找不到指定模組 tensorflow has no attribute xxx 解決方法

Tensorflow2.2.0安裝成功引用時顯示DLL load failed:找不到指定模組解決方法電腦配置

C#（99）：二、.NET 2.0基於事件的非同步程式設計模式(EAP)

一、非同步程式設計模型(APM) 二、基於事件的非同步程式設計模式(EAP) 三、基於任務的非同步模式(TAP)，推薦使用