軟考5個高級 難度(軟考 高項 信息化考點匯總總結)
1．兩化融合：工業化與信息化，含義是：一是信息化與工業化發展戰略的融合；二是指信息資源與材料、能源等工業資源的融合；三是指虛擬經濟與工業實體經濟融合；四是指信息技術與工業技術、IT設備與工業裝備的融合。2次
2．信息化與信息系統
（1）信息技術發展趨勢：高速度，大容量；集成化和平臺化、智能化、虛擬計算、通信技術、遙感和傳感技術、移動智能終端、以人為本信息安全。考2次
（2）信息化：主體是企業，而不是程序員、工程師、項目經理、質量管控人員。題考查信息的質量屬性。
（3）信息的質量屬性：
? 完整性：輸入和傳輸的過程，不被非法授權修改和破壞，保證數據的一致性。
? 可靠性：信息與預期行為一致的特性。
? 可驗證性：對自己的動作和做出的決定負責的一種特性。
? 保密性：信息不能被未授權的個人、實體或者過程利用或知悉的特性。
（4）大型信息系統：以信息技術和通信技術為支撐，規模龐大、分布廣闊，采用多級網絡結構，跨越多個安全域，處理海量的，復雜且形式多樣的數據，提供多種類型應用的大系統。
3．網絡存儲技術：DAS NAS SAN
l DAS：很難擴展，存儲容量的升級是瓶頸
l NAS：通過網絡訪問，僅提供文件系統功能，存儲功能完全獨立于網絡中的主服務器，主要用NFS和CIFS來進行訪問，即插即用。
l SAN：通過專用交換機將磁盤陣列與服務器連接起來，沒有采用文件共享存取，采用塊級別存儲。根據數據傳輸過程采用協議，分FC SAN IPSAN IBSAN。
n FC SAN成本和復雜性高，需要每個服務器有FC適配器、專用FC交換機和獨立的布線基礎架構；
n IP SAN 數據塊級別存儲，設備成本低，配置簡單；
n IB SAN是一種交換結構I/O技術，通過一套中心機構（IB交換機）在遠程存儲器、網絡及服務器等設備間建立一個單一連接鏈路，提高系統性能、可靠性和有效性，緩解各硬件設備之間數據流量擁塞。
4．新一代信息技術
（1）區塊鏈技術的模型：數據層、網絡層、共識層、激勵層、合約層和應用層組成。
（2）數據倉庫技術：體系結構包括數據源、數據存儲與管理、OLAP服務器、前端工具。OLAP與OLTP：OLTP是執行基本日常的事務處理，比如數據庫記錄的增刪查改；OLAP是數據倉庫系統的主要應用，支持復雜的分析操作，側重決策支持，且提供直觀易懂的查詢結果。典型的應用就是復雜的動態的報表系統。
（3）大數據的特點，5個V，Volume(大量)、Variety(多樣)、Value(價值)、Velocity (高速)和Veracity(真實性)來概括大數據的特征。
（4）區塊鏈
ü 特點：分布式數據存儲、點對點傳輸、共識機制、加密算法等。
ü 模型：數據層、網絡層、共識層、激勵層、合約層和應用層
l 數據層：封裝了底層數據區塊的鏈式結構，以及非對稱公私鑰數據加密技術和時間戳等技術。
l 網絡層：包括P2P組網機制、數據傳播機制和數據驗證機制等。
l 共識層：各類共識機制算法，區塊鏈的核心技術。共識機制算法：工作量證明機制(PoW，Proof of Work)、權益證明機制(PoS，Proof ofStake)、股份授權證明機制(DPoS，Delegated ProofofStake)等。數據層、網絡層、共識層是構建區塊鏈技術的必要元素。
l 激勵層，將經濟因素集成到區塊鏈技術體系中來，包括經濟激勵的發行機制和分配機制等，主要出現在公有鏈當中。在公有鏈中必須激勵遵守規則參與記賬的節點；在私有鏈當中則不一定需要進行激勵，因為參與記賬的節點往往是在鏈外完成了博弈，通過強制力或自愿來要求參與記賬。
l 合約層，封裝各類腳本、算法和智能合約，是區塊鏈可編程特性的基礎。比特幣本身就具有簡單腳本的編寫功能，而以太坊極大的強化了編程語言協議，理論上可以編寫實現任何功能的應用。
l 應用層，各種應用場景和案例，比如搭建在以太坊上的各類區塊鏈應用即部署在應用層，而未來的可編程金融和可編程社會也將會是搭建在應用層。
5．網絡技術
(1) 網絡規劃分為規劃、設計與實施三個階段;網絡設計原則：規劃可擴展、性能可擴展
(2) 網絡設計分層設計：接入層、匯聚層、核心層。ACL(Access Control List,訪問控制列表)，是一系列運用到路由器接口的指令列表，路由根據ACL中指定的條件對經過路由器接口的數據包進行檢查，主要發生在路由器和匯聚層設備中。
l 核心層——高速轉發通信，更高可靠性、性能和吞吐量
l 匯聚層——訪問策略控制，數據包處理，過濾尋址，及其他數據處理，與接入層相比，更少接口和更高交換速率。
l 接入層——提供用戶到網絡的接入，負責用戶設備接入，防止非法用戶進入網絡。低成本高密度。
(3) 網絡接入：
① 有線：PSTN ISDN ADSL FFTx+LAN HFC；
② 無線包括GPRS、3/4/5G，無線電波、WiFi和4G
(4) 網絡標準協議
l 802.11協議簇：無線局域網絡制定的標準；
n IEEE802.3 以太網；以太網介質訪問控制協議 (CSMA/CD)及物理層技術規范。以太網的幀是數據鏈路層的封裝，網絡層的數據包被加上幀頭和幀尾成為可以被數據鏈路層識別的數據幀(成幀)。雖然幀頭和幀尾所用的字節數是固定不變的，但被封裝的數據包大小的不同，以太網的長度也在變化，其范圍是64~1518字節(不算8字節的前導字)
n IEEE802.4 令牌總線；
n IEEE802.5 令牌環網；
n IEEE802.11 無線局域網，無線局域網(WLAN)的介質訪問控制協議及物理層技術規范；WI-FI使用了802.11的媒體訪問數據鏈路層(DLL)和物理層(PHY)，數據鏈路層和物理層合起來稱其為網絡接口層。
6．OSI模型:OSI安全體系結構：五類安全服務，認證（鑒別）服務、訪問控制服務、數據保密性服務、數據完整性服務和抗否認性服務。
l 物理層:最低層或第一層，物理連網媒介，如電纜連線連接器，RS232 V.35 RJ-45 FDDI
l 數據鏈路層:第二層，控制網絡層與物理層之間的通信從網絡層接收到的數據被分割成特定的可被物理層傳輸的幀，在不可靠的物理線路上進行數據的可靠傳遞。 802.3/.2 HDLC PPP ATM
l 網絡層:將網絡地址翻譯成對應的物理地址，并決定如何將數據從發送方路由到接收方，有IP、ICMP、IGMP IPX ARP和RARP。
l 傳輸層:負責分割、組合數據，實現端到端的邏輯連接,流量控制。TCP UDP SPX
l 會話層:負責在網絡中的兩節點之間建立和維持通信。 RPC SQL NFS
l 表示層:應用程序和網絡之間的翻譯官，數據將按照網絡能理解的方案進行格式化；數據的壓縮、解壓，加密、解密。JPEG ASCII GIF DES MPEG
l 應用層:負責對軟件提供接口以使程序能使用網絡服務，TFTP是TCP/IP協議族中的一個用來在客戶機與服務器之間進行簡單文件傳輸的協議，提供不復雜、開銷不大的文件傳輸服務。端口號為69。HTTP Telnet FTP SMTP
(1) 開放系統互連參考模型(Open System Interconnection Reference Model, OSI/RM),從下往上分別是物理層、數據鏈路層、網絡層、傳輸層、會話層、表示層、應用層7層結構。SNMP是在UDP協議之上的異步請求/響應協議
(2) TCP/IP，一組用于實現網絡互連的通信協議，分為四層：網絡接口層、網絡層、傳輸層、應用層。
l 應用層：為用戶提供所需要服務，FTP、Telnet、DNS、SMTP等
l 傳輸層：為應用層實體提供端到端的通信功能，保證數據包的順序傳送及數據的完整性，分為：傳輸控制協議TCP和用戶數據報協議UDP
n TCP協議，可靠的、三次握手連接的數據傳輸服務；
n UDP協議，不保證可靠的、無連接的數據傳輸服務.
l 網際互聯層，對應OSI的網絡層，解決主機到主機的通信問題，主機的尋址，路由。協議：網際協議(IP)、互聯網組管理協議(IGMP)和互聯網控制報文協議(ICMP)。IP協議提供的是一個可靠、無連接的數據報傳遞服務
n ICMP
l 網絡接入層(即主機-網絡層)，即主機-網絡層，OSI的物理層和數據鏈路層對應，負責監視數據在主機和網絡之間的交換。地址協議(ARP)工作在此層，即OSI參考模型的數據鏈路層。
7．數據庫管理系統：
8．中間件：操作系統與應用程序之間，獨立的系統軟件或服務，與操作系統、數據庫關系系統稱為“三套車”。
? 底層型中間件：JVM CRL ACE JDBC ODBC
? 通用型中間件：CORBA J2EE MOM COM
? 集成型中間件：WorkFlow EAI
CORBA：系統底層傳輸層的集成；消息中間件完成不同系統的消息傳遞；J2EE完成不同硬件和操作系統的集成
9．軟件需求
（1）需求基線：已承諾在特定版本實現功能性和非功能性需求集合。
（2）需求分類：
①業務需求:高層次，投資人、購買產品的客戶,使用前景和范圍文檔來記錄業務需求;
②用戶需求:用戶的目標，或用戶要求系統必須能完成的任務。
③功能需求:在產品中實現的軟件功能，用戶利用這些功能來完成任務，滿足業務需求。
④系統需求:多個子系統的產品(即系統)的頂級需求。
（3）需求工程活動：收集與獲取需求、需求分析、定義需求(編寫需求說明書)、及需求驗證四個階段。其中：需求分析又包括需求提出、需求描述及需求評審三個階段。
① 需求獲取：訪談、問卷、采樣、情節串聯版、聯合需求計劃
② 需求分析：確定對系統的綜合要求、功能要求和性能要求等，檢測和解決需求之間的沖突；發現系統的邊界；并詳細描述出系統需求；
1) SA方法進行需求分析，建立的模型核心是數據字典，E-R 數據模型 STD狀態轉換圖為行為模型；DFD數據流圖為功能模型;
2) 需求評審：需求規格說明和初步的用戶手冊，確保需求無二義、完整、一致、可測試、確定性、可跟蹤、正確性、必要性，使用戶、設計人員對需求的理解達成一致。
③ 需求驗證：需求確認，通過需求評審和需求測試來進行驗證
④ QFD質量功能部署：常規需求、期望需求、意外需求
⑤ SRS需求規格說明書：需求開發活動的產物，包括：范圍、引用文件、需求、合規性規定、需求可追蹤性、尚未解決問題、注解、附錄
10．UML：建模語言，構造塊、規則和公共機制。
14.1 UML中的關系
? 依賴：一個事物發生會影響另一個事物，虛線箭頭，箭頭指向被使用者
? 泛化：一般和特殊，特殊可代替一般，實線空心三角箭頭，指向父類
? 關聯：一組對象之間連接的結構關系，實線箭頭，雙向箭頭或無箭頭
? 實現：類指定由另一類保證執行的契約，封閉空箭頭的虛線，箭頭指向接口
14.2 UML2.0中的圖
? 類圖(class diagram)：一組類、接口、協作和之間的關系，最常見的圖，靜態設計視圖，活動類的類圖給出了系統的靜態進程視圖。顯示信息結構，同時描述系統行為。
? 對象圖(object diagram)：一組對象及它們之間的關系，事物實例的靜態快照。和類圖一樣，系統的靜態設計視圖或靜態進程視圖，但它們是從真實案例或原型案例的角度建立的
? 構件圖：一個封裝的類和它的接口、端口，以及由內嵌的構件和連接件構成的內部結構，用于表示系統的靜態設計實現視圖。對于由小的部件構建大的系統來說，構件圖是很重要的。構件圖是類圖的變體
? 組合結構圖：結構化類內部的結構，包括結構化類與系統其余部分的交互點
? 用例圖 一組用例、參與者與他們之間的關系，系統靜態用例圖，是最基本的需求分析模型 外部執行者(Actor)所理解的系統功能
? 順序圖：交互圖，一組對象及他們之間可能發送消息構成。系統的動態視圖，強調消息的時間次序。
? 通信圖:交互圖，強調收發消息的對象或參與者的結構組織。順序圖強調時序，通信圖強調對象之間的結構(關系）
? 定時圖，交互圖，消息跨越不同對象或角色的實際時間，而不僅關心消息的相對順序
? 狀態圖，一個狀態機，它由狀態、轉移、事件和活動組成，對象的動態視圖。它對于接口、類或協作的行為建模尤為重要，而且它強調事件導致的對象行為，這非常有助于對反應式系統建模
? 活動圖 將進程或其他計算機結構展示為計算機內部一步步的控制流和數據流，系統的動態視圖，強調對象間的控制流程
? 部署圖：對運行時的處理節點及其在其中生存的構建的配置，靜態部署圖。
? 制品圖 ：計算機中一個系統的物理結構，包括文件、數據庫合類似的物理比特集合，與部署圖一起使用，給出他們實現的類和構件
? 包圖：由模型本身分解而成的組織單元，及他們之間依賴關系。
? 交互概覽圖：活動圖和順序圖的混合物。
14.3 UML2.0視圖，它是用來描述某一個抽象層上對系統的一個抽象的表示。
l 邏輯視圖，稱為設計視圖，它表示了設計模型中在架構方面具有重要意義的部分，即類、子系統、包和用例實現的子集。
l 進程視圖，是可執行線程和進程作為活動類的建模，邏輯視圖的一次執行實例，描述了并發與同步結構。
l 實現視圖，對組成基于系統的物理代碼的文件和構件進行建模。
l 用例視圖，需求分析模型，最基本.
l 部署視圖：把構件部署到一組物理節點上，表示軟件到硬件的映射；
11．面向對象分析：OOA做什么，OOD怎么做，面向對象分析核心是建立用例模型和分析模型。用例模型的構建經歷4個過程：識別參與者、合并需求獲得用例、細化用例描述和調整用例模型，期三個必需。
12．類之間的關系
13．虛線箭頭指向依賴；實線箭頭指向關聯；虛線三角指向接口；實線三角指向父類；空心菱形能分離而獨立存在，是聚合；實心菱形精密關聯不可分，是組合；
14．軟件架構風格分為5大類：圖片
l 數據流：批處理、管道/過濾器。
l 調用/返回：主/子程序、數據抽象 面向對象、層次結構
l 獨立構件：進程通信、事件驅動
l 虛擬機風格：解釋器、基于規則的系統
l 倉庫風格：數據庫、黑板
l 其他：特定領域軟件體系結構、狀態轉移、分布式處理、REST。其中分布式有C/S、B/S、CORBA、DCOM和EJB等。
15．架構評估：關注質量，基于問卷（檢查表）、基于場景、基于度量的方式。
16．軟件設計：
? 結構化設計：自頂向下、逐步求精；以SRS與SA
17．設計模式：解決方案、效果、實例代碼和相關設計模式等基本要素
l 處理范圍，類模式和對象模式
l 目的用途，創建型模式、結構型模式和行為型模式
18．移動互聯網的特點：①重視對傳感技術的應用;②有效地實現人與人的連接;③瀏覽器競爭及孤島問題突出。移動互聯網不是傳統桌面互聯網的簡單復制和移植，而是傳統互聯網的延伸和補充
19．企業系統規劃BSP：常用矩陣方法
l 過程/組織矩陣：在定義業務過程的的步驟產生，表達的是企業的業務過程與企業組織機構的關系
l 實體/數據類矩陣：在定義數據類的步驟產生，表達的是數據類與實體、數據類與實體相關類型的關系
l 功能/數據類矩陣：在定義數據類的步驟產生，表達的是企業流程中各項功能與相應數據類的產生與使用關系
20．信息系統生命周期：可以分為4個階段：立項、 開發、運維、消亡。開發階段又可分為總體規劃階段、系統分析階段、系統設計階段、系統實施階段和系統驗收階段。總體規劃向系統分析階段提交可行性分析報告;系統分析階段提交系統方案說明書;系統設計階段提交系統設計說明書;一般來說總體規劃工作量占9%，系統分析占15%，系統設計占20%，系統實施占50% ，運行和評價占6%。
l 系統規劃：對組織的環境、目標及現行系統的狀況進行初步調查，確定信息系統的發展戰略，對建設新系統的需求做出分析和預測，包括信息系統開發目標、總體結構、 管理流程、實施計劃、技術規范，考慮建設新系統所受的各種約束，研究建設新系統的必要性和可能性。
l 系統分析：根據系統設計任務書所確定的范圍，對現行系統進行詳細調查，描述現行系統的業務流程，指出現行系統的局限性和不足之處，確定新系統的基本目標和邏輯功能要求，即提出新系統的邏輯模型。內容包括組織結構及功能分析、業務流程分析、數據和數據流程分析及系統初步方案
l 系統設計：根據系統說明書中規定的功能要求，考慮實際條件，設計實現邏輯模型的技術方案，也就是設計新系統的物理模型。內容包括系 統架構設計、數據設計、處理流程設計、功能模塊設計、安全控制方案設計、系統組織和隊伍設計及系統管理流程設計
l 系統實施：系統實施階段是將設計的系統付諸實施的階段。
l 系統運行和維護：系統投入運行后，需經常進行維護和評價，記錄系統運行情況，根據一定規則對系統進行必要的修改，評價系統工作質量和經濟效益。
21．面向對象特性：多態 繼承 封裝
l 繼承:子類自動共享父類之間數據和方法的機制
l 多態:可以理解為事物存在的多種體現形式(父類類型的變量引用指向子類類型的對象)。
22．消息是對象之間進行通信的一種規格說明。一般它由三部分組成：接收消息的對象、消息名及實際變元。
23．接口就是對操作規范的說明
24．軟件測試類型
l 確認測試：驗證軟件的功能、性能和其他特性是否與用戶需求一致。
25．類模式處理類和子類之間的關系，這些關系通過繼承建立，在編譯時刻被確定下來，屬于靜態關系；對象模式處理對象之間的關系，這些關系在運行時刻變化，更具動態性。
26．干系人管理：受項目影響和影響項目的個人或組織，可能贏得更多的資源，啟動階段影響最大，隨著項目的進行逐漸減弱
27．云資源類型
l SaaS：提供在云計算基礎設施上的應用程序，消費者不需要管理或控制云計算基礎設施，如網絡、服務器、操作系統、存儲等等。
l PaaS：提供開發語言和工具開發的或收購的應用程序，不需要管理或控制底層的云基礎設施，如網絡、服務器、操作系統、存儲等，但能控制部署的應用程序，也可能控制運行應用程序的托管環境配置。
l IaaS: 提供設施，如處理、存儲、網絡和其它基本的計算資源，用戶能夠部署和運行任意軟件，包括操作系統和應用程序。消費者不管理或控制任何云計算基礎設施，但能控制操作系統的選擇、儲存空間、部署的應用，也有可能獲得有限制的網絡組件(例如，防火墻，負載均衡器等)的控制。
l CaaS通訊即服務。CaaS是將傳統電信的能力如消息、語音、視頻、會議、通信協同等封裝成API或者SDK通過互聯網對外開放，提供給第三方使用，將電信能力真正作為服務對外提供。E
28．智能特點:感知能力：感知外部世界、獲取外部信息的能力，前提條件和必要條件；記憶和思維能力，即能夠存儲感知到的外部信息及由思維產生的知識，同時能夠利用已有的知識對信息進行分析、計算、比較、判斷、聯想、決策；學習能力和自適應能力，即通過與環境的相互作用，不斷學習積累知識，使自己能夠適應環境變化；四是具有行為決策能力，即對外界的刺激作出反應，形成決策并傳達相應的信息。
29．面向對象方法
ü 優點：符合人類思維，易于理解；模塊化，復用性好
ü 基本任務，把面向對象分析模型轉化為面向對象的設計模型，包括任務：設計用例實現方案、設計技術支撐設施、設計用戶界面、精化設計模型。
30．2015年，國務院發布了《關于積極推進“互聯網+ ”行動的指導意見》提出，到2018年，互聯網與經濟社會各領域的融合發展進一步深化，基于互聯網的新業態成為新的經濟增長動力，互聯網支撐大眾創業、萬眾創新的作用進一步增強，互聯網成為提供公共服務的重要手段，網絡經濟與實體經濟協同互動的發展格局基本形成。到2025年，“互聯網+ ”新經濟形態初步形成，“互聯網+ ”成為我國經濟社會創新發展的重要驅動力量。
31．針對操作系統的安全威脅按照行為方式劃分，通常有下面四種：
ü 切斷，可用性的威脅，資源被破壞或變得不可用或不能用，如破壞硬盤、切斷通信線路或使文件管理失效。
ü 截取，機密性的威脅，未經授權的用戶、程序或計算機系統獲得了對某資源的訪問，如在網絡中竊取數據，非法拷貝文件和程序。
ü 篡改，完整性的攻擊。未經授權的用戶不僅獲得了對某資源的訪問，而且進行篡改，如修改數據文件中的值，修改網絡中正在傳送的消息內容。
ü 偽造，合法性的威脅。未經授權的用戶將偽造的對象插入到系統中，如非法用戶把偽造的消息加到網絡中或向當前文件加入記錄。
32．信息安全四個層次：設備安全、數據安全、內容安全、行為安全。
33．EAI：企業應用集成技術
? 表示集，界面集成，用戶界面作為公共的集成點，黑盒集成，常用的集成技術主要有屏幕截取和輸入模擬技術。
? 數據集，為了完成控制集成和業務流程集成，必須首先解決數據和數據庫的集成問題，首先對數據進行標識并編成目錄，還要確定元數據模型，保證數據在數據庫系統中分布和共享，白盒集成。相對而言，數據集成比表示集成更加靈活。但是，當業務邏輯經常發生變化時，數據集成就會面臨困難。
? 控制集成，功能集成，應用集成，是在業務邏輯層上對應用系統進行集成的，集成點存于程序代碼中，集成處可能只需簡單使用公開的API就可以訪問，黑盒集成。控制集成與表示集成、數據集成相比，靈活性更高。表示集成和數據集成所適用的環境，都適用于控制集成。由于控制集成是在業務邏輯層進行的，其復雜度更高一些。而且，很多系統的業務邏輯部分并沒有提供API，集成難度就會更大。
? 業務流程集成，過程集成，超越了數據和系統，它由一系列基于標準的、統一數據格式的工作流組成。當進行業務流程集成時，企業必須對各種業務信息的交換進行定義、授權和管理，以便改進操作、減少成本、提高響應速度。
34．商業智能：利用數據倉庫、聯機分析處理(OLAP)工具和數據挖掘。
35．電子政務項目實施機構應在電子政務項目竣工驗收后3個月內，根據建設單位檔案管理規定，向建設單位或本機構的檔案管理部門移交檔案。需經常利用的檔案，可在辦理移交手續后借出。
36．四控：進度控制、質量控制、成本控制、變更控制。
三管：合同管理、安全管理、文檔管理。
一協調：溝通與協調業主、承建方Y設備和材料供應商之間的關系。
37．存儲轉發：以太網交換機的控制器先將輸入端口到來的數據包緩存起來，先檢查數據包是否正確，并過濾掉沖突包錯誤。確定包正確后，取出目的地址，通過查找表找到想要發送的輸出端口地址，然后將該包發送出去。
38．綜合布線系統：工作區子系統、水平子系統、垂直干線子系統、設備間子系統、管理子系統和建筑群子系統。工作區子系統是一個從信息插座延伸至終端設備的區域
39．軟件維護類型，其中(預防性維護 )的目的是檢測并更正軟件產品中的潛在錯誤，防止它們成為實際錯誤。 更正性維護、適應性維護、 完善性維護
40．技術評審的目的是評價軟件產品，以確定其對使用意圖的適合性，表明產品是否滿足要求。
41．聚合:是整體與部分、擁有的關系。OMT法是目前最為成熟和實用的方法之一。它從三個方面對系統進行建模，每個模型從一個側面反映系統的特性，三個模型分別是：對象模型、動態模型和功能模型。
42．移動計算的特點：(1)移動性(2)網絡條件多樣性(3)頻繁斷接性(3)網絡通信的非對稱性(5)移動計算機的電源能力有限（6）可靠性低
43．數據流圖：信息在系統中的流向，包括數據流、加工、數據存儲和外部實體 。
44．技術評審：是評價軟件產品，以確定其對使用意圖的適合性，目標是識別規范說明與標準的差異，并向管理提供證據，以表明產品是否滿足規范說明并遵從標準，而且可以控制變更。
45．質量保證：檢查開發和管理活動是否與已定的過程策略、標準和流程一致，檢查工作產品是否遵循模板規定的內容和格式
46．軟件審計：提供軟件產品和過程對于可應用的規則、標準、指南、計劃和流程的遵從性的獨立評價。
47．軟件過程管理：啟動和范圍定義、軟件項目計劃、軟件項目實施、評審和評價、關閉、軟件工程度量。軟件工程度量：進行在軟件工程組織中有效地開發和實現度量的程序。
48．軟件配置管理：軟件配置項，軟件配置管理的4個活動：配置項標識、配置項控制(變更控制)、配置狀態報告和配置審計。
49．監理機構：(1)技術和質量的要求；(2)主要產品和服務的要求；(3)投標單位資格的要求；(3)驗收方法、接收準則；(5)時間進度的要求。
50．綜合布線：傳輸語音、數據、影像和其他信息的標準結構化布線系統，采用模塊化和分層星型拓撲結構，其中三個子系統：配線(水平)子系統、干線(垂直)子系統、建筑群子系統；外加三個部分：工作區、設備間、管理。
? 工作區子系統：工作區內終端設備連接到信息插座之間的設備組成，包括信息插座、連接軟線、適配器、計算機、網絡集散器、電話、報警探頭、攝像機、監視器、音響等。
? 水平子系統：在同一樓層上，一端接在信息插座，另一端接在配線間的跳線架上，將干線子系統線路延伸到用戶工作區，將用戶工作區引至管理子系統，為用戶提供一個符合國際標準，滿足語音及高速數據傳輸要求的信息點出口。
? 管理子系統：線路管理器件及各種公用設備，系統集中管理，它是干線子系統和水平子系統的橋梁，為同層組網提供條件，包括雙絞線跳線架、跳線。
? 垂直干線子系統：主設備間至各層管理間，實現計算機設備、程控交換機(PBX)、控制中心與各管理子系統間的連接，是建筑物干線電纜的路由。
? 設備間子系統：由設備間中的電纜、連接跳線架及相關支撐硬件、防雷電保護裝置等構成。
? 建筑群子系統：將多個建筑物的數據通信信號連接成一體的布線系統，它采用架空或地下電纜管道或直埋敷設的室外電纜和光纜互連起來，支持提供樓群之間通信所需的硬件。
51．電子標簽RFID，也叫射頻標簽、射頻識別，射頻電信號識別目標對象并獲取相關數據，如自動收費或識別車輛身份等
52．4G：2010年國際電信聯盟把LTE Advanced正式稱為4 LTE是應用于手機及數據卡終端的高速無線通信標準；WCDMA、CDMA2000和TC-SDMA屬于3G；GSM屬于2G。
53．組件：可替換的、物理的組成部分，它封裝了實現體(實現某個功能)，并提供了一組接口的實現方法。
54．ICMP：Internet Control Message Protocol，Internet控制報文協議，用在IP主機、路由器之間傳遞控制消息，路由器報告差錯或提供傳輸路徑上有關傳輸異常情況的信息,但并不傳輸用戶數據。
55．軟件度量：貫穿整個軟件開發生命周期，是軟件開發過程中進行理解、預測、評估、控制和改善的重要載體。軟件質量度量建立在度量數學理論基礎之上。軟件度量包括3個維度，即項目度量、產品度量和過程度量。
56．SOA：Service Oriented Architecture，面向服務的架構，適應復雜業務需求，將開發和運維也納入到企業架構中，和運行架構一同組成了企業架構，實現服務共享的一體化信息系統體系，解決了企業數據一致性差、共享性低、交互成本高的諸多問題。
57．移動網絡：受限于終端數量和傳輸特性，與PC長期共存，但不可能替代。
58．云計算：支持異構基礎資源、動態擴展、、異構多業務體系、、海量信息處理等特征。其資源動態擴展特性與云計算的擴展性低，一旦需要擴展，需要重新構件全部數據模型描述完全相反
59．綜合布線：先進性先進成熟的技術和設備，滿足當前業務需求，兼顧未來的業務需求;可靠和穩定性是指具有髙可靠性，不出現單點故障;可擴充性是擴大設備容量，提高可容納的用戶數量;實用性主要是滿足當前的業務發展需要。
60．常用的傳輸介質有：雙絞線、同軸電纜、光纖、無線傳輸媒介。雙絞線可分為非屏蔽雙絞線UTP和屏蔽雙絞線STP，適合于短距離通信。非屏蔽雙絞線價格便宜，傳輸速度偏低，抗干擾能力較差。屏蔽雙絞線抗干擾能力較好，具有更髙的傳輸速度，但價格相對較貴。雙絞線需用RJ-45或RM1連接頭插接。UTP傳輸距離不超過100米。
61．以太網(Ethernet)指由Xerox公司創建并由Xerox、Intel和DEC公司聯合開發的基帶局域網規范，是當今現有局域網采用的最通用的通信協議標準。以太網絡使用CSMA/CD (載波監聽多路訪問及沖突檢測)技術，并以10Mb/s的速率運行在多種類型 的電纜上。以太網與IEEE 802.3系列標準相類似。包括標準的以太網(lOMbit/s)、快速以太網(100Mbit/s)和10G (10Gbit/s)以太網。它們都符合IEEE 802.3。常見的802.3 應用為：10M: 10 Base-T (銅線UTP模式)；100M: 100 Base-TX (銅線UTP模式)；100Base-FX (光纖線)；1000M: 1000Base-T (銅線UTP模式)。
62．IEEE 802系列常見標準包括：IEEE 802.2邏輯鏈路控制(LLC): IEEE 802.3帶碰撞檢測的載波偵聽多路訪問(CSMA/CD)方法和物理層規范(以太網)；IEEE 802.4令牌傳遞總線訪問方法和物理層規范(Token Bus); IEEE 802.5令牌環訪問方法和物理層規范(Token Ring); IEEE 802.7標準定義了寬帶技術；IEEE 802.8標準定義了光纖技術； IEEE802.il無線局域網(Wireless LAN)訪問方法和物理層規范。
63．軟件設計：結構設計、數據設計、接口設計和過程設計，其中結構設計是指(定義軟件系統各主要部件之間的關系)。
64．軟件配置管理：Software Configuration Management, SCM,為了標識變更、 控制變更、確保變更正確實現并向其他有關人員報告變更。關鍵活動：配置項、工作空間管理、版本控制、變更控制、狀態報告、配置審計等。軟件配置管理的4個活動：配置項標識、配置項控制(變更控制)、配置狀態報告和配置審計。
65．監理規劃：包括項目概況、監理范圍和目標、主要監理措施、監理組織機構、項目監理工作制度用來指導監理機構開展監理工作的指導性文件。
66．電子政務：電子政務總體框架的構成包括：服務與應用系統、信息資源、基礎設施、法律法規與標準化體系、管理體制，服務是宗旨；應用是關鍵；信息資源開發利用是主線；基礎設施是支撐；法律法規、標準化體系、管理體制是保障。 框架是一個統一的整體，在一定時期內相對穩定，具體內涵將隨著經濟社會發展而動態變化。
67．索賠分類：按索賠目的分類，按索賠處理方式分類，按索賠對象分類。
68．按索賠目的分類：工期索賠；經濟索賠。
69．索賠原則：必須以合同為依據；及時、合理地處理索賠，以完整、真實的索賠證據為基礎；加強主動控制，減少索賠。
70．軟件審計:提供軟件產品和過程對于可應用的規則、標準、指南、計劃和流程的遵從性的獨立評價。
71．軟件配置項:軟件生存周期各個階段活動的產物經審批后,配置項包括：與合同、過程、計劃和產品有關的文檔和資料；源代碼、目標代碼和可執行代碼；相關產品，包括軟件工具、庫內的可重用軟件、外購軟件及顧客提供的軟件等。
72．軟件質量保證(SQA):建立一套有計劃、有系統的方法，來向管理層保證擬定出的標準、步驟、實踐和方法能夠正確地被所有項目所采用，目的是使軟件過程對于管理人員來說是可見的，通過對軟件產品和活動進行評審和審計來驗證軟件是合乎標準的。軟件質量保證組在項目開始時就一起參與建立計劃、標準和過程。這些將使軟件項目滿足機構方針的要求。
73．功能測試：黑盒子測試，數據驅動測試，一般從軟件產品的界面、架構出發，按照需求編寫出來的測試用例，輸入數據在預期結果和實際結果之間進行評測，進而使產品更加達到用戶使用的要求。
74．軟件測試及其管理
1) 配置項測試：檢驗配置項與SRS的一致性，依據是SRS(含接口需求規格說明)。
2) Alpha測試和Beta測試：Alpha指用戶在開發環境下測試；Beta指由用戶在實際使用環境下進行測試。
3) 回歸測試，測試軟件變更之后，變更部分的正確性和對變更需求的符合性，以及軟件原有的、正確的功能、性能和其他規定的要求的不損害性。
75．招投標
1）采用邀請招標方式采購：具有特殊性，只能從有限范圍的供應商處采購的；采用公開招標方式的費用占政府采購項目總價值的比例過大的。
2）采用競爭性談判方式采購：招標后沒有供應商投標或者沒有合格標的或者重新招標未能成立的；技術復雜或者性質特殊，不能確定詳細規格或者具體要求的；采用招標所需時間不能滿足用戶緊急需要的；不能事先計算出價格總額的。
3）采用單一來源方式采購：只能從唯一供應商處采購的；發生了不可預見的緊急情況不能從其他供應商處采購的；必須保證原有采購項目一致性或者服務配套的要求，需要繼續從原供應商處添購，且添購資金總額不超過原合同采購金額百分之十的
4）詢價方式采購，貨物規格、標準統一、現貨貨源充足且價格變化幅度小的政府采購項目。
76．可行性研究：初步可行性研究雖然比詳細可行性研究報告粗略但對項目已經有了全面的描述，可作為正式的文獻供決策參考，可依據項目的初步可行性研究報告形成項目建議書。
1）立項：通過審查項目建議書決定項目的取舍，即通常所稱的“立項”決策
2）項目論證：一般分為機會研究、初步可行性研究和詳細可行性研究三個階段，是籌措資金、向銀行貸款的依據，是編制計劃的依據，是否實施的依據。
77．軟技能包含：有效的溝通；影響一個組織；領導能力；激勵；談判和沖突管理；問題解決。
78．CMMI,即軟件能力成熟度模型集成模型。
1) 初始級：開發過程是臨時、有時甚至是混亂的,靠個人能力來取得成功
2) 可重復級：建立基本管理過程來跟蹤成本、進度和功能,過程和方法可重復使用，成功經驗用于當前和今后類似的項目
3) 已定義級：被文檔化、標準化，所有項目都使用一個經批準的、特制的標準過程版本，可以根據項目實際情況適當剪裁。
4) 已管理級：為質量和過程績效建立量化目標，以此作為管理過程的依據。過程和產品都被置于定量的掌控之中
5) 持續優化級：運用從過程、創意和技術中得到的定量反饋，來對軟件開發過程進行持續改進。
79．軟件體系結構評估：基于調查問卷或檢查表的評估方式；基于場景的評估方式；基于度量的評估方式。用一系列軟件的修改來反映軟件體系結構的易修改性方面的需求屬于基于場景的評估方式。
80．數據倉庫系統：數據源、數據存儲與管理、OLAP服務器以及前端工具與應用四個部分。
81．網絡綜合布線:星型、環型、總線型、樹型和網狀型等，其中以星型網絡拓撲結構使用最多。采用按國際標準的結構化布線系統的優點： a)性能價格比;b)具有開放性和充分的靈活性;c)設計思路簡潔，施工簡單，施工費用降低;d)充分適應通訊和計算機網絡的發展;e)大大減少維護管理人員的數量及費用;
82．CRM以客戶為中心的商業策略，注重與客戶的交流，企業的經營是以客戶為中心，而不是傳統的以產品或市場為中心；注重提高用戶滿意度的同時，一定要把幫助提升企業獲取利潤的能力作為重要指標;實施要求企業對其業務功能進行重新設計，并對工作流程進行重組，將業務的中心轉移到客戶，同時要針對不同的客戶群體有重點地采取不同的策略。
83．國家信息化體系：信息技術應用、信息資源、信息網絡、信息技術和產業、信息化人才、信息化法規政策和標準規范6個要素。1）信息技術應用，龍頭，主陣地，體現建設的需求與利益；2）信息資源的開發，核心任務，信息化建設取得實效的關鍵，也是我國信息化的薄弱環節；3)信息網絡是信息資源開發利用和信息技術應用的基礎，是信息傳輸、交換、共享的必要手段；4)信息技術和產業是我國進行信息化建設的基礎；5)信息化人才,成功之本，，是信息化建設的關鍵；6)信息化政策法規和標準規范,根本保障。
84．測試：檢查軟件是否正確、是否滿足需求，而需求包含功能需求、性能需求以及質量需求等成分，因此軟件需求是測試軟件質量的基礎，而軟件分析、軟件設計和軟件實現是為了實現軟件需求而做的技術工作。
85．開發標準：為軟件開發提供了指南并為技術行為規定了準則，開發文檔記錄了開發成果，維護手冊為軟件投入運行后提供維護指導，用戶手冊為用戶提供操作軟件的指南
86．Web Service 中的角色包括:服務提供者、服務請求者和服務注冊中心
87．ABC分析法，巴累托分析法、ABC分類管理法、重點管理法,根據事物在技術或經濟方面的主要特征，進行分類、排隊，分清重點和一般，以有區別地實施管理的一種分析方法,以 A類作為重點管理對象,其關鍵在于區別一般的多數和極其重要的少數。
88．監理實施細則：在監理規劃指導下，具有可實施可操作的業務性文件，用來指導具體監理業務的開展。
89．監理規劃的作用：(1) 監理項目部職能的具體體現。(2) 指導監理項目部全面開展工作的綱領性文件。(3) 是信息系統工程監理管理部門對監理單位進行監督管理的主要內容和依據。(3) 建設單位檢查監理單位是否能夠認真、全面履行信息系統工程監理委托合同的重要依據。
90．總監理工程師代表的職責如下：負責總監理工程師指定或交辦的監理工作；負責本項目的日常監理工作和一般性監理文件的簽發；
91．總監理工程師不得將下列工作委托總監理工程師代表：a.監理人員的調配，調換不稱職的監理人員；主持編寫工程項目監理規劃及審批監理實施方案；簽發工程開工/復工報審表、工程暫停令；工程款支付證書、工程項目的竣工驗收；審核簽認破工結；調解建設單位和承建單位的合同爭議，處理索賠，審批工程延期
92．由于承建單位違反合同的原因導致工程政工時間延長，應由承建單位來承擔責任，監理單位不承擔連帶責任。
93．采用不同的語言和平臺獨立構建而成，需要集成來自不同系統的數據，并使用可定制格式的數據頻繁地、立即地、可靠地、異步地傳輸數據時，通常會選擇最為靈活的消息機制實現這樣的需求
94．信息系統的規劃工具
1）P/0矩陣：把企業組織結構與企業過程聯系起來，說明每個過程與組織的聯系，指出過程決策人
2）R/D矩陣，為定義數據類，在調查研究和訪談的基礎上，可以采用實體法歸納出數據類。實體法首先列出企業資源，再列出一個資源／數據
3）IPO功能法，過程法，它利用所識別的企業過程，分析每個過程的輸入數據類和輸出數據類，與RD矩陣進行比較并調整，最后歸納出系統的數據類
4）CU矩陣。企業過程和數據類定義好后，可以企業過程為行，以數據類為列， 按照企業過程生成數據類關系填寫C (Create),使用數據類關系填寫U (User),形成 CU矩陣（用于表示數據與過程之間的關系）
95．智慧城市：物聯感知層、通信網絡層、計算與存儲層，數據及服務支撐層、智慧應用層。其中數據及服務支撐層：利用SOA（面向服務的體系架構）、云計算、大數據等技術，通過數據和服務的融合，支撐承載智慧應用層中的相關應用，提供應用所需的各種服務和共享資源。
96．信息系統規劃流程：分析企業信息化現狀。(2)制定企業信息化戰略。
97．通用的生命周期結構特征：
l 成本與人力投入在開始時較低，在工作執行期間達到最高，并在項目快要結束時迅速回落。
l 風險與不確定性在項目開始時最大，并在項目的整個生命周期中隨著決策的制定與可交付成果的驗收而逐步降低。
l 變更的代價隨著項目越來越接近完成而顯著增高；成本與人力投入在開始時較低，在工作執行期間達到最高，并在項目快要結束時迅速回落
98．事業環境因素與組織過程資產區別：是否可以修改
99．項目經理具有領導者和管理者的雙重身份。對項目經理而言，管理能力和領導能力二者均不可或缺。對于大型復雜項目，領導能力尤為重要。
100．組織結構：一般分為職能型組織、項目型組織和矩陣型組織(弱矩陣型組織、平衡矩陣型組織、強矩陣型組織)。各組織結構對項目的影響如表所示。
優缺點：
101．軟件開發模型，必須掌握。
l 瀑布模型，特點。(1) 從上一項開發活動接受該項活動的工作對象作為輸入。(2) 利用這一輸入，實施該項活動應完成的工作內容。(3) 給出該項活動的工作成果，作為輸出傳給下一項開發活動。(3) 對該項活動的實施工作成果進行評審。若其工作成果得到確認，則繼續進行下一項 開發活動；否則返回前一項，甚至更前項的活動。盡量減少多個階段間的反復。
l 瀑布模型:需求明確或很少變更的項目，也可用在已有類似項目開發經驗的項目上
l 演化模型:為了解決瀑布模型的上述缺點，演化模型允許在獲取了一組基本需求之后，通過快速分析構造待建系統的可運行版本(即原型)，然后再根據用戶在使用原型的過程中提出的意見對原型進行修改，從而得到原型更新的版本。這一過程重復進行，直到得到用戶滿意的系統,和螺旋模型、噴泉模型等適用于對軟件需求缺乏明確描述的項目。
l 螺旋模型，瀑布和快速原型結合起來，強調風險分析，適合于大型復雜的系統，每個周期都包括需求定義、風險定義、工程實現和評審4個階段，使得軟件的增量版本的快速開發成為可能。兩個顯著特點， 一是采用(循環) 的方式逐步加深系統定義和實現的深度，降低風險；二是確定一系列(里程碑 )，確保項目開發過程中的相關利益者都支持可行的和令人滿意的系統解決方案。
l V模型： V模型測試提前的理念。驗收（需求分析），系統（概要設計），集成（詳細設計），單元（編碼）
l 噴泉模型：以面向對象的軟件開發方法為基礎，以用戶需求為導向，以對象來驅動的模型。該模型主要用于描述面向對象的開發過程，體現了面向對象開發過程的迭代和連續性。
102．需求跟蹤過程中的相互影響能力鏈的局部
變更請求影響系統的方方面面，包括規劃，設計，可交付成果等等。系統測試是針對整個產品系統進行的測試，目的是驗證系統是否滿足了需求規格的定義，找出與需求規格不符或與之矛盾的地方，從而提出更加完善的方案。
103．項目目標SMART原則：Specific明確的 Measurable度量的 Achievable可達到的 Result driven結果驅動的 Timing時間性
104．信息系統項目特點：項目初期目標往往不太明確；需求變化頻繁；智力密集型；系統縫隙和設計所需人員層次高，專業化強；涉及的軟件硬件廠商和承包商多，聯系、協商復雜；軟件和硬件常常需要個性化定制。
105．項目管理辦公室，項目之間共享和協調資源
l 迭代模型：適用于項目事先不能完整定義產品所有需求、計劃多期開發
1）責任與功能：提供行政支援，如各種報表的產生；提供項目管理的咨詢與顧問服務；將企業的項目管理實踐和專家知識整理成適合于本企業的一套方法論，提供在企業內傳播和重用；在企業內提供項目管理相關技能的培訓；PMO可以配置部分項目經理，對重點項目給與重點支持。
106．項目集：獲取單獨項目無法取得收益的一組相關聯項目、子項目集和項目集活動，項目集內項目通過共同目標關聯。若項目集干系人有不同目標，且目標不具有協調收益的交付特征，只是資金、技能、干系人等方面存在關聯，最好采用項目組合。
107．項目集管理：利用知識、技能、工具和技術來滿足項目集的要求，獲得分別管理各項目集組建所無法實現的收益和控制，包括對多個組件的組合調整，以優化或整合成本、進度和工作來實現項目集目標。通過共同成果或一些列集合收益的交付相關聯。
1）項目集路線圖:規劃和制訂更加詳細的時間表而勾勒出的主要項目集事件，不包括項目集組件內部細節。
2）項目集管理與項目管理區別：項目集戰略聚焦，及項目集確保組織收益實現
3）項目集與組織戰略的一致性評估貫穿始終，
108．項目集指導委員會，負責定義并執行恰當的項目治理體系和方法，保障項目集執行與組織戰略目標保持一致，并為指導項目集的正常管理提供支持，由決策層干系人組成，能夠為實現項目集目標收益提供足夠的資源。其職責如下：1）保持項目集與組織愿景和目標一致；2）項目集批準和啟動。項目集決策機構，需批準項目集為實現預期目標所采取的方法和計劃，授權項目集對組織資源的使用，及對組織外資源的方法，還負責批準項目集章程、項目集商業論證；3）項目集籌資。
109．項目組合管理：是對一組或者多組項目組合進行管理，以達成組織的戰略目標。組織為了實現自身的愿景、使命和價值目標遵循一系列相互關聯的過程，對項目組合中的模塊進行評價、選擇以及設定優先級，以便將內部有限的資源以最佳方式分配項目組結合案例，分析該項目適合用那種方式進行管理，并簡述理由。
110．項目組合治理管理包括：制定項目諸管理計劃、(1定義項目組合)、(2優化項目組合)、(3批準項目組合)和執行項目監督5個子過程
111．招投標
1）招標文件開始發出之日起至提交投標文件截止之日止，最短不得少于20日。
2）在招標文件要求提交投標文件截止時間至少15日前，招標人可以以書面形式對已發出的招標文件進行必要的澄清或者修改。
3）招標人和中標人應當自中標通知書發出之日起30日內，按照招標文件和中標人的投標文件訂立書面合同。因此D中的招標人和中標人應當自中標通知書發出之日起10日內是錯誤的。
112．項目論證：一般可分為機會研究、初步可行性研究和詳細可行性研究三個階段
1）論證作用：確定項目是否實施的依據；是籌措資金、向銀行貸款的依據；編制計劃、設計、采購、施工以及機構設備、資源配置的依據;是防范風險、提高項目效率的重要保證；
2）先論證后決策：代項目管理的基本原則
3）項目論證：一個連續的過程，一般包括以下幾個步驟：1、明確項目范圍和業主目標；2、收集并分析相關資料；3、擬定多種可行的能夠相互替代的實施方案；4、多方案分析、比較；5、選擇昀優方案進一步詳細全面地論證；6、編制項目論證報告、環境影響報告書和采購方式審批報告；項目論證報告的結構和內容常常有特定的要求，這些要求和涉及到的步驟，在項目論證報告的編制和實施中能有助于雇主。7、編制資金籌措計劃和項目實施進度計劃
113．項目評估：指在項目可行性研究的基礎上，由第三方(國家、銀行或有關機構)根據國家頒布的政策、法規、方法、參數和條例等，從項目(或企業)、國民經濟、社會角度出發，對擬建項目建設的必要性、建設條件、生產條件、產品市場需求、工程技術、經濟效益和社會效益等進行評價、分析和論證，進而判斷其是否可行的一個評估過程。
114．開發總成本: 研發成本、行政管理費、銷售與分銷費用、財務費用和折舊。前三類成本的總和稱為經營成本。
115．回收期
項目經理制定了項目資產負債表(單位：元)，如下表所示。該項目的靜態投資回收期為( )年，動態投資回收期為( )年。(保留一位小數位
116．可行性研究:信息系統項目開發的可行性研究要從可能性、效益性和必要性入手、項目可行性研究可采用投資估算法、增量凈效益法等方法。技術可行性分析、經濟可行性分析、運行環境可行性分析以及其他方面的可行性分析等。
1) 技術可行性分析:在當前市場的技術、產品條件限制下，能否利用現在擁有的以及可能擁有的技術能力、產品功能、人力資源來實現項目的目標、功能、性能，能否在 規定的時間期限內完成整個項目。
2) 經濟可行性分析：支出分析、收益分析、投資回報分析及敏感性分析。
(1) 支出分析：支出可以分為一次性支出和非一次性支出，其中一次性支出，包括開發費、培訓費、差旅費、初試數據錄入、設備購置費等費用；非一次性支出，包括軟硬件租金、人員工資及福利、水電等公用設施使用費，以及其他消耗品支出等。
(2) 收益分析：直接收益、間接收益以及其他方面的收益等，直接收益通過項目實施獲得的直接經濟效益，如銷售項目產品的收入；間接收益通過項目實施，通過間接方式獲得的收益，如成本的降低。
(3) 收益投資比、投資回收期分析：對投入產出進行對比分析，以確定項目的收益率和投資回收期等經濟指標。
(4) 敏感性分析：當諸如設備和軟件配置、處理速度要求、系統的工作負荷類型和負荷量等關鍵性因素變化時，對支出和收益產生影響的估計。
3) 法律可行性、社會可行性等方面的可行性分析。也會涉及到合同責任、知識產權等法律方面的可行性問題。社會可行性主要分析項目對社會的影響，包括法律道德、民族宗教、社會穩定性等。
117．財務績效評估：靜態分析法和動態分析。靜態分析法包括：投資收益率法，投資回收期法，追加投資回收期法和最小費用法。動態分析法包括凈現值法和內部收益率法。
118．可行性研究的作用：投資決策和編制設計任務書的依據;籌集資金的重要依據；與有關部門簽訂協議和合同的依據；工程設計、施工、設備購置重要依據；申請有關建設許可文件的依據;可行性研究是國家各級計劃綜合部門對固定資產投資實行調控管理、編制發展計劃、固定資產投資、技術改造投資的重要依據；項目考核和后評估的重要依據。應該首先告知客戶注意可能的風險，以減少損失。
119．可行性研究報告內容：
120．輔助研究：只包括項目的某些方面或某一方面，甚至是關鍵方面，可貫穿整個可行性研究階段，輔助研究的費用必須和項目前評價的費用聯系起來考慮。
121．項目評估:根據建議書及其批準文件、項目可行性研究報告、報送單位的申請報告及主管部門的初審意見等文件
122．項目建議書應該包括的核心內容如下：
123．項目的必要性；項目的市場預測；產品方案或服務的市場預測；項目建設必需的條件
124．項目收尾過程：完成所有項目過程組中的所有活動并正式關閉整個項目或某個階段；恰當地移交已完成或已取消的項目和階段。
1) 管理收尾:覆蓋整個項目，在每個階段完成時規劃和準備階段性收尾，詳細描述了在項目和任何階段執行管理收尾涉及到的所有的活動及其交互、項目團隊成員和其他項目干系人的相關角色和職責。
2) 合同收尾:涉及結算和中止任何項目所建立的合同、采購或買進協議，也定義為支持項目的正式管理收尾所需的與合同相關的活動。
3) ？？項目收尾 ITO：
125．監控項目工作是輸出：變更請求、工作績效報告、項目管理計劃更新、項目文件更新；
126．組織過程資產與事業環境因素：凡是可裁剪的、可選擇的均為組織過程資產；凡是不可選擇的、只能適應的均為事業環境因素。
127．項目工作說明書內容——（1）業務要求：可能基于市場需求、技術的進步、培訓需求、法律的要求或政府的標準。（2）產品范圍描述：記錄項目所要創建的產品的需求以及產品或服務等特征。一般情況下，產品需求說明書在項目的啟動過程中并不是很詳細，在項目后續的過程中隨著產品特征的明確會逐漸細化。這些需求說明書也要記錄項目所創造的產品與組織的業務要求之間的關系，或記錄項目所創造的產品與引出產品要求的激發因素之間的關系。雖然產品需求文檔的形式和實質內容因行業而異，但它應該總是保持足夠詳細以支持后續的項目計劃。（3）戰略計劃：所有項；肩都要支持組織的戰略目標。執行組織的戰略計劃作為項目選擇的一個重要因素來考慮。
128．項目監控：圍繞項目實施計劃、跟蹤進度、成本、質量、資源，掌握各項工作現狀，以便進行適當的資源凋配和進度調整，確定活動的開始和結束時間，并記錄實際的進度情況，在一定情況下進行路徑、決策、度量、量化管理、風險等方面的分析。在實施項目的過程中，要隨時對項目進行跟蹤監控，以使項目按計劃規定的進度、技術指標完成，并提供現階段工作的反饋信息，以利后續階段的順利開展和整個項目的完成。
129．項目評估：主要特征可以概括為整體性(綜合集成經濟、技術運行、環境、風險)、目標性、相關性(時間、知識、邏輯三維結構)、動態性(項目生命周期)。
130．項目收尾包括合同收尾和管理收尾兩部分。
（1） 合同收尾：抓起合同，和客戶一項項的核對，是否完成了合同所有的要求，是否可以把項目結束掉，也就是我們通常所講的驗收。
（2） 管理收尾：涉及為了使項目干系人對項目產品的驗收正式化而進行的項目成果驗證和歸檔，具體包括收集項目記錄、確保產品滿足商業需求、并將項目信息歸檔，還包括項目審計。
131．項目管理可劃分為啟動過程組、計劃編制過程組、執行過程組、監督過程組和收尾過程組5個管理過程組。
（1） 啟動過程組：定義并批準項目或階段。
（2） 計劃編制過程組：定義和細化目標，規劃最佳的行動方案，從各種備選方案中選取最優方案，以實現項目或階段的目標范圍。
（3） 執行過程組——整合人員和其他的資源，在項目的生命周期或某個階段執行項目管理計劃。
（4） 監控過程組——定期測量和監控進展，識別與項目管理計劃的偏差，以便在必要時采取糾正措施，確保項目或階段目標達成。
（5） 收尾過程組：正式接受產品、服務或工作成果，有序地結束項目或階段。
132．執行過程組包括：
1. 指導和管理項目執行用于指導存在于項目中不同的技術和組織接口，執行項目管理計劃所定義的活動；執行項目管理計劃所定義的工作過程的結果就是各項可交付物。收集關于可交付物的完成狀態和哪些工作已經完成的信息是項目執行部分的工作，這些信息會被反饋到績效報告過程。
2. 執行質量保證：指應用已計劃好的，系統性的質量活動，如審核和同行評審來確保項目使用了為滿足所有項目干系人的期望所必需的所有過程。
3. 項目團隊建設：培育個人和團隊的能力以提升項目績效。
4. 信息發布：用于及時向項目干系人傳送他們所需的信息
5. 獲取供方響應(詢價)：這一過程指導如何恰當地發布信息、報價、投標、出價或提交建議書。
6. 選擇供方：這一過程用于評標、選擇潛在供方以及與供方協商并簽訂合同。
變更控制委員會：負責批準或拒絕變更請示，角色和職責應在變更控制和配置控制過程中予以明確的定義，所有關鍵項目干系人的認可，可能也需要被買方所批準。 CCB主要是根據影響做出決定，影響的分析不是變更控制委員會的職責，CCB根據分析的結果做決定 。
133．變更可能需要重新進行成本估算、活動排序、進度安排、資源需求、風險應對分析 ，或對項目管理計劃、 項目范圍說明書、項目可交付物進行調整，或對這些內容進行修訂。(教程 p99) 帶有變更控制系統的配置管理系統為在項目中集中管理變更提供了一個標準、有效和高效的過程
134．實施變更的依據:
135．項目章程：反應客戶、發起人或干系人的要求和期望。
（1） 項目必須實現的商業需求、項目概述或產品需求。
（2） 項目的目的或論證結果。項目干系人的需求和期望。
（3） 指定項目經理及制授權級別。 概要的里程碑計劃。
（4） 項目干系人的影響。
（5） 職能組織。
（6） 組織的、環境的和外部的假設。
（7） 組織的、環境的和外部的約束。
（8） 論證項目的業務方案，包括投資回報率。
（9） 概要預算。
二、范圍管理
136．規劃范圍管理：范圍管理計劃與需求管理計劃
137．收集需求；范圍、需求、干系人及登記冊 項目章程，需求文件 跟蹤矩陣
（1）需求跟蹤：逆向需求跟蹤檢查設計文檔、代碼、測試用例等工作產品是否都能在《需求規格說明書》中找到出處；需求跟蹤矩陣可以把每個需求與業務目標或項目目標聯系起來；需求跟蹤矩陣為管理產品范圍變更提供框架。
（2）收集需求的工具方法：
①焦點小組（主題專家，受過訓練的主持人，互動式討論）；
②名義小組技術：Nominal Group Technique，通過投票來排列最有用的創意，以便進行進一步的頭腦風暴或優先排序，使那些不善言辭的參與者也能充分發表自己的意見;
③引導式研討會：跨職能干系人，對產品需求進行集中討論與定義，快速定義跨職能需求和協調干系人差異的重要技術。由于群體互動的特點，被有效引導的研討會有助于建立信任、促進關系、改善溝通，從而有利于參加者達成一致意見。 該技術的另一個好處是，能夠比單項會議更快地發現和解決問題。
（3）需求工程的活動5個階段：
①需求獲取：通過與用戶的交流，對現有系統的觀察及對任務進行分析，從而開發、捕獲和修訂用戶的需求;
②需求建模：為最終用戶所看到的系統建立一個概念模型，作為對需求的抽象描述，并盡可能多的捕獲現實世界的語義
③形成需求規格：生成需求模型構件的精確的形式化的描述，作為用戶和開發者之間的一個協約；
④需求驗證：以需求規格說明為輸入，通過符號執行、模擬或快速原型等途徑，分析需求規格的正確性和可行性，包含有效性檢查，一致性檢查，可行性檢查和確認可驗證性；
⑤需求管理：支持系統的需求演進，如需求變化和可跟蹤性問題。
（4）基線(Baseline)，軟件文檔或源碼(或其他產出物)的一個穩定版本，當基線形成后，項目負責SCM的人需要通知相關人員基線形成，并且哪兒可以找到這基線了的版本，隨后的工作基于此標準，并且只有經過授權后才能變更這個標準。
138．定義范圍：范圍計劃 需求文件 項目章程 組織=>項目范圍說明書 項目文件更新
（1）項目范圍說明書：對項目的定義，是項目范圍的基礎，在向項目干系人說明項目范圍時，要以項目范圍說明書(詳細)為依據。
（2）項目范圍說明書內容：項目和范圍的目標、產品或服務的需求和特性、項目的邊界、產品接受標準、項目約束條件、項目假設、最初的項目組織、最初定義的風險、進度里程碑、費用估算的量級要求、項目配置管理的需求、已批準的需要。
（3）項目范圍說明書:進一步并且正式明確了項目所應該產生的成果和項目可交付的特征，進一步明確和規定了項目利益相關者之間希望達成共識的項目范圍，為未來項目的決策提供一個管理基線。
139．創建WBS：范圍計劃 項目范圍說明書 需求文件 業組=>范圍基準 文件更新
1. 工作分解結構WBS：
①項目→任務→日常活動，以可交付成果為導向，整個工作范圍，每下降一層代表對項目工作的更詳細定義。總是處于計劃過程的中心，也是制訂進度計劃、資源需求、成本預算、風險管理計劃和采購計劃等的重要基礎。WBS同時也是控制項目變更的重要基礎。項目范圍是由WBS定義的。
②控制賬戶：一種管理控制點，把范圍、成本和進度加以整合，與掙值相比，以測量績效，包括一個或多個工作包，但是每一個工作包只能屬于一個控制賬戶。
③工作包：定義工作范圍、定義項目組織、設定項目產品的質量和規格、估算和控制費用、估算時間周期和安排進度的基礎。業內一般把一個人2周能干完的工作稱為一個工作包或把一個人80小時能干完的工作稱為一個工作包。工作包的詳細程度取決于項目的規模和復雜程度。
2. WBS字典：支持性文件，對控制賬戶和工作包做詳細解釋，詳細程度根據具體需要而定，包括編號、名稱、工作說明、相關活動列表、里程碑列表、承辦組織、開始和結柬日期、資源需求、成本估算、負載量、規格、合同信息、質量要求和有關工作質量的技術參考資料。管理儲備是項目管理計劃內容，不在WBS字典中體現。WBS分解原則：
(1) 必須是面向可交付成果的。
(2) 必須符合項目的范圍
(3) 的底層應該支持計劃和控制
(4) WBS中的元素必須有人負責，而且只由一個人負責，盡管實際上可能需要多個人參與
(5) WBS的指導。作為指導而不是原則，WBS應控制在4～6層
(6) 應包括項目管理工作，也要包括分包出去的工作
(7) WBS的編制需要所有(主要)項目于系人的參與，需要項目團隊成員的參與
3. 范圍基準：是經過批準的范圍說明書、工作分解結構(WBS)和相應的WBS詞典，只有通過正式的變更控制程序才能進行變更。
4. 創建WBS方法：(1)使用指導方針。(2)類比方法。(3)自上而下的方法。該方法由于可以將項目工作定義在適當的細節水平，對于項目工期、成本和資源需求的估計可以比較準確。(3)自下而上的方法，主要風險是可能不能完全地識別出所有任務或者識別出的任務過于粗略或過于瑣碎。
5. WBS的表示方式：樹形的層次結構圖、行首縮進的表格表示
6. 面向可交付物的項目元素的層次分解，WBS是一個詳細的項目范圍說明的表示法，WBS的組成元素有助于項目干系人檢查項目的最終產品。
7. WBS的最低層元素是能夠被評估的、安排進度的和被跟蹤的。
8. WBS對項目管理有著重要的意義：把握項目、了解和控制項目過程；保證了項目結構的系統性和完整性；建立完整的項目保證體系;明確項目相關各方的工作界面;可以直接作為進度計劃和控制的工具；信息溝通系統提供依據；各項計劃和控制措施制定的基礎和主要依據
173.范圍確認(scope verification):干系人對于整個項目范圍的正式驗收,通過客戶審查實現，并在關鍵可交付成果上簽字。范圍定義成果是形成詳細項目范圍說明書。以項目范圍說明書、WBS和WBS詞典為主，是有關工作結果的可接受問題，正式被接受的標準和要素屬于范圍確認的活動
（1）輸入輸出：項目計劃 需求文件 需求跟蹤矩陣 確認的可交付成果、工作績效數據==驗收的可交付成果 變更請求 工作績效信息 文件更新
（2）工具技術：檢查（審查、產品評審、審計、走查、巡檢）、群體決策技術
（3）確認范圍是在正式驗收階段才執行的過程，確認范圍貫穿項目始終；
（4）分解技術是確認范圍的主要工具與技術，檢查和群體決策技術是確認范圍的工具；
（5）確認范圍強調的是結束項目所要做的流程性工作，確認范圍包括與客戶或發起人一起審查可交付成果，確保可交付成果已圓滿完成，并獲得客戶或發起人的正式驗收。
（6）管理層主要關注項目范圍對項目進度、資金和資源的影響，是否超過了組織承受范圍，是否在投入產出上具有合理性；客戶主要關心的是產品的范圍，關心項目的可交付成果是否足夠完成產品或服務；項目經理主要關注可交付成果是否足夠和必須完成，時間、資金和資源是否足夠，主要的潛在風險和預備解決的方法；項目團隊成員主要關心項目范圍中自己參與的元素和負責的元素。
140．控制范圍；監督項目和產品的范圍狀態、管理范圍基準變更的過程
（1）工具技術：偏差分析
（2）輸入輸出：項計 需求文件 需求跟蹤矩陣 工作績效數據 組織==工作績效信息 變更請求 3更新；
（3）主要作用：在整個項目期間保持對范圍基準的維護；
（4）控制范圍的活動包括：①影響導致范圍變更的因素，并盡量使這些因素向有利的方面發展；②判斷范圍變更是否己經發生；③范圍變更發生時管理實際的變更，確保所有被請求的變更按照項目整體變更控制過程處理。
141．質量控制：目的是核實工作結果的正確與否
142．OBS BOM RBS WBS區別：
①組織分解結構(OBS)——執行組織的層次結構，以便把工作包同執行組織單元相關聯。
②物料清單(BOM)——生產一個產品所需的實際部件、組件和構件的分級層次表格。
③風險分解結構(RBS)——以層次結構對已識別出的風險進行組織，按照風險類別劃分的。
9. 項目章程：正式批準項目的文件。主管部門必須作出批準或不批準某個項目并且頒發項目章程的決策，決策主要基于項目對于項目所有人和贊助人的價值和吸引力。而其前提則是可行性研究的審查和通過。
10. 績效報告：搜集和傳播績效信息，向利害關系者提供資源如何用于實現項目目標的信息，應當提供有關范圍、進度、成本與質量的信息。
11. 工作說明書：指用書面形式對組織中各類崗位(職位) 的工作性質、工作任務、責任、權限、工作內容和方法、工作環境和條件，以及本職務任職人資格條件所作的統一要求(書面記錄)。它應該說明任職者應做些什么、如何去做和在什么樣的條件下履行其職責。一個名符其實的工作說明書必須包括該項工作區別于其他工作的信息，提供有關工作是什么，為什么做，怎樣做以及在哪里做的清晰描述。
169.需求開發：需求定義、文檔記錄、需求演進，并最終在驗證的基礎上凍結需求。
(1) 需求獲取：對現有系統的觀察及對任務進行分析，從而開發、捕獲和修訂用戶的需求；
(2) 需求建模：建立一個概念模型，作為對需求的抽象描述，盡可能多捕獲現實世界語義；
(3) 形成需求規格：生成需求模型構件的精確的形式化的描述，作為用戶和開發者之間的一個協約；
(4) 需求驗證：以需求規格說明為輸入，通過符號執行、模擬或快速原型等途徑，分析需求規格的正確性和可行性；
(5) 需求管理：支持需求演進如需求變化和可跟蹤性問題,完成需求驗證后確定需求基線
170.需求基線：已承諾將在某一特定產品版本中實現的功能性和非功能性需求的一組集合。經評審批準，這些文檔就定義了開發工作的需求基線，這個基線在客戶和開發人員之間就構筑了計劃產品功能需求和非功能需求的一個約定。
172.項目范圍說明書與工作分解結構的關系
174.范圍控制:監控項目狀態如項目的工作范圍狀態和產品范圍狀態的過程。控制項目范圍以確保所有請求的變更和推薦的糾正行動都要通過整體變更控制過程處理。當變更發生且集成到其他控制過程時，項目范圍控制也被用來管理實際的變更。
175.創建wbs輸入輸出
4.頭腦風暴法，智力激勵法、自由思考法或集思廣益法，是用來產生和收集對項目需求與產品需求的多種創意的一種技術。頭腦風暴法分為直接頭腦風暴法(通常簡稱為頭腦風暴法)和質疑頭腦風暴法(也稱為反頭腦風暴法)。前者是在專家群體決策時盡可能激發創造性，產生盡可能多的設想的方法，后者則是對前者提出的設想、方案逐一質疑，分析其現實可行性的方法。
5.德爾菲技術:是一種組織專家就某一主題達成一致意見的一種信息收集技術。而名義小組技術是通過投票來排列最有用的創意，以便進行進一步的頭腦風暴或優先排序.注意:德菲爾技術是收集信息，而名義小組技術排列創意。
6.群體創新技術(Group Creativity Technique):組織一些群體活動來識別項目和產品需求，群體創新技術包括頭腦風暴法、名義小組技術、德爾菲技術、概念/思維導圖、親和圖和多標準決策分析等。
178. 網絡圖
已知網絡計劃中，工作M有兩項緊后工作，這兩項緊后工作的最早開始時間分別為第15天和第17天，工作M的最早開始時間和最遲開始時間分別為第6天和第9天，如果工作M的持續時間為9天，則工作M( )。
179. 關鍵路徑法：進度網絡分析技術。
1）總浮動時間：在任何網絡路徑上，進度安排的彈性大小由最晚與最早日期間的正差值決定，關鍵路徑的總浮動時間為零或負數。網絡圖中可能有多條次關鍵路徑。
2）自由浮動時間：在不延誤任一緊后活動最早開始日期的前提下，某進度活動可以推遲的時間量。
180. 關鍵鏈法(Critical Chain Method )：一種根據有限的資源來調整項目進度計劃的進度網絡分析技術。首先，根據持續時間估算、給定的依賴關系和制約因素，繪制項目進度網絡圖；然后，計算關鍵路徑。在確定了關鍵路徑之后，再考慮資源的可用性，制訂出資源約束型進度計劃——該進度計劃中的關鍵路徑常與原先的不同。資源約束型關鍵路徑就是關鍵鏈，增加作為“非工作進度活動”的持續時間緩沖，用來應對不確定性。
1）項目緩沖：放置在關鍵鏈末端的緩沖，用來保證項目不因關鍵鏈的延誤而延誤；
2）接駁緩沖：則放置在非關鍵鏈與關鍵鏈接合點，用來保護關鍵鏈不受非關鍵鏈延誤影響。
3）應該根據相應路徑上各活動持續時間的不確定性，來決定每個緩沖的時間長短。一旦確定了“緩沖進度活動”，就可以按可能的最晚開始與最晚完成日期來安排計劃活動。這樣一來，關鍵鏈法就不再管理網絡路徑的總浮動時間，而是重點管理剩余的緩沖持續時間與剩余的任務鏈持續時間之間的匹配關系。簡單地說，關鍵鏈是在考慮了資源制約后進行調整過的關鍵路徑，并引入項目緩沖與接駁緩沖作為項目進度與成本的應急儲備。
181. 資源平衡：進度網絡分析技術，核心在于將稀缺資源首先用到關鍵路線的關鍵活動.
1）可以考慮加班和提高資源的生產率
2）進度壓縮指在不改變項目范圍、進度制約條件、強加日期或其他進度目標的前提下縮短項目的進度時間：(1)趕進度：對費用和進度進行權衡，確定如何在盡量少增加費用的前提下最大限度地縮短項目所需時間。趕進度并非總能產生可行的方案，反而常常增加費用。(2)快速跟進：這種進度壓縮技術通常同時進行按先后順序的階段或活動。
182. 計劃評審技術(PERT)：把工程項目當作一種系統，用網絡圖或者表格或者矩陣來表示各項具體工作的先后順序和相互關系，以時間為中心，找出從開工到完工所需要時間的最長路線，并圍繞關鍵路線對系統進行統籌規劃，合理安排以及對各項工作的完成進度進行嚴密的控制，以達到用最少的時間和資源消耗來完成系統預定目標的一種計劃與控制方法。
183. 標準差=(悲觀Tp-樂觀To)/6；方差=標準差的平方
184. 項目活動排序:識別項目活動清單中各項活動的相互關聯與依賴關系，并據此對項目各項活動的先后順序的安排和確定工作,方法和工具主要有：
1. 順序圖法(Precedence Diagramming Method, PDM):單節點網絡圖法(Activity on Node, AON),單個節點(方框)表示一項活動，用節點之間的箭線表示項目活動之間的相互依賴關系。
2. 箭線圖法(Arrow Diagram Method, ADM):是一種描述項目活動順序的網絡圖方法。這一方法用箭線代表活動，而用節點代表活動之間的聯系和相互依賴關系。
3. 在項目中包含幾個相同或幾乎相同的可交付成果時，項目經理可在進度計劃編制中使用標準化的項目進度網絡圖。
185. 項目活動之間的依賴關系分為四種
(1) 強制性依賴關系是法律或合同要求或工作的內在性質決定的依賴關系。
(2) 選擇性依賴(首選邏輯關系、優選邏輯關系軟邏輯關系)是基于具體應用領域的最佳實踐或者基于項目的某種特殊性質而設定，即便還有其他順序可以選用，但項目團隊仍缺省按照此種特殊的順序安排活動。
(3) 外部依賴關系是項目活動與非項目活動之間的依賴關系。
(4) 內部依賴關系是項目活動之間的緊前關系，通常在項目團隊的控制中。
186. 快速跟進，也叫并行施工，進度壓縮技術，將正常情況下按順序進行的活動或階段改為至少是部分并行開展。它只適用于能夠通過并行活動來縮短項目工期的情況。
187. 趕工，通過增加資源，以最小的成本增加來壓縮進度工期的一種技術。趕工的例子包括：批準加班、增加額外資源或支付加急費用，來加快關鍵路徑上的活動。趕工只適用于那些通過增加資源就能縮短持續時間的，且位于關鍵路徑上的活動。趕工并非總是切實可行，它可能導致風險和/或成本的增加。
188. 資源平衡：為了在資源需求與資源供給之間取得平衡，根據資源制約對開始日期和結束日期進行調整的一種技術。資源平衡往往導致關鍵路徑改變，通常是延長。要縮短項目的工期，應該在關鍵路徑上縮短；如果不在關鍵路徑上，應該在總時差最短
189. 蒙特卡羅分析法(也叫統計模擬法)，是一種采用隨機抽樣統計來估算結果的計算方法。
190. 成本估算工具與技術
1）類比估算法：如果很難獲得項目工作的詳細信息時，以前類似項目工作的完成時間來估計當前工作的完成時間
191. 資源活動估算主要包括輸入、輸出及采用的主要方法和技術。
活動資源估算：什么資源(人力、設備、原料)、資源多少、何時使用，須和成本估算相結合
192. 活動排序:為工作排序，這項工作主要是確定各個活動任務之間的依賴關系，并形成文檔。(教程p133) 活動資源估算的輸入1企業環境因素：活動資源估算過程利用企業環境因素包含的有關基礎設施資源有無或是否可利用的信息(教程p139)。 因此進行活動排序時不需要考慮活動資源估算問題，活動資源估算過程與費用估算過程相關，而活動資源估算的目的不止是確定資源數量，還包括種類，和使用時間。
193. 關鍵路徑法(Critical Path Method, CPM)：用于確定項目進度網絡中各種邏輯網絡路線上進度安排靈活性的大小(時差大小)，進而確定項目總持續時間最短的一種網絡分析技術。使用該法沿著項目進度網絡圖進行正向與反向分析，從而計算出所有計劃活動理論上的最早開始與完成日期、最遲開始與完成日期，也能找到項目的關鍵路線，不考慮任何資源限制。
194. 甘特圖(Gantt Chart),橫道圖或條形圖(Bar Chart),橫線來表示每項活動的起止時間，是一種能有效顯示活動時間計劃編制的方法，主要用于項目計劃和項目進度安排。
195. PERT：某些活動或全部工序的持續時間實現不能準確確定，適用于不可預知因素較多的，過去未曾做過的新項目或復雜項目，或研制新產品的工作中。PERT 技術的理論基礎是假設項目持續時間以及整個項目完成時間是隨機的，且服從某種概率分布。PERT可以估計整個項目在某個時間內完成的概率。
196. 進度控制步驟：
197. (1)分析實際進度與計劃進度；(2)如果進度落后，找出落后的原因；(3)針對進度落后原因，制訂并選擇糾正措施；(3)執行糾正措施。如果是原進度計劃的原因，則：(5)提出進度變更申請，以修改進度計劃；(6)重新計算進度，估計計劃采取的糾正措施的效果。由上述步驟可知，采取“糾正行為”之前，要先“進行原因分析”。
198. 制定進度計劃的技術和工具：
1）可能有多條關鍵路徑；在項目進展中，網絡圖在不斷變化，關鍵路徑也在不斷變化之中
2）關鍵活動的總浮動時間和自由浮動時間為零
3）資源優化技術
①資源平衡(Resource Leveling)：資源需求與資源供給平衡，根據資源制約對開始日期和結束日期進行調整的一種技術。如果共享資源或關鍵資源只在特定時間可用，數量有限，或被過度分配，如一個資源在同一時段內被分配至兩個或多個活動，就需要進行資源平衡。也可以為保持資源使用量處于均衡水平而進行資源平衡。資源平衡往往導致關鍵路徑改變，通常是延長。
②資源平滑(Resource Smoothing)。 對進度模型中的活動進行調整，從而使項目資源需求不超過預定的資源限制的一種技術。相對于資源平衡而言，資源平滑不會改變項目關鍵路徑，完工日期也不會延遲。也就是說，活動只在其自由浮動時間和總浮動時間內延遲。資源平滑無法實現所有資源的優化
4）進度壓縮：趕工和快速跟進
①趕工（crashing）：通過增加資源，以最小的成本增加來壓縮進度工期的一種技術，趕工適用增加資源就能縮短持續時間，且位于關鍵路徑上的活動；趕工可能導致風險和/或成本增加
②快速跟進（fast tracking）：將正常情況下順序進行的的活動或階段改為至少是部分并行開展；只適用于能夠通過并行活動來縮短項目工期的情況；快速更近可能造成質量風險，也有可能增加項目成本
199. 功能性包括：適宜性、準確性、互用性、依從性和安全性等。
200. 試驗設計:是一種統計方法，識別哪些因素會對正在生產的產品或正在開發的流程的特定變量產生影響。實驗設計可以在規劃質量管理過程中使用，以確定測試的數量和類別，以及這些測試對質量成本的影響。
201. SIPOC組織系統模型:戴明認為任何一個組織都是一個由供應者、輸入、流程、輸出、客戶相互關聯、互動的5個部分組成的系統。
202. 績效評價：成本效益分析法、比較法、因素分析法、最低成本法、公眾評判法。
1） 成本效益分析法：將一定時期內的支出與效益進行對比分析以評價績效目標實現程度。適用于成本、效益都能準確計量的項目績效評價。
2） 比較法是 對績效目標與實施效果、歷史與當期情況、不同部門和地區同類支出的比較，綜合分析績效目標實現程度。
3） 因素分析法 綜合分析影響績效目標實現、實施效果的內外因素，評價績效目標實現程度。
4） 最低成本法 對效益確定卻不易計量的多個同類對象的實施成本進行比較，評價績效目標實現程度。適用于公共管理與服務、社會保障、文化、教育等領域項目支出的績效評價。
5） 公眾(專家)評判法 通過專家評估、公眾問卷及抽樣調査等對財政支出效果進 行評判，評價績效目標實現程度
203. 成本管理：包括成本估算、成本預算和成本控制三個過程，成本預算完成后，可能會引起項目管理計劃更新；成本基準計劃可以多為度量項目績效依據；成本基準按時間段計算，通常以s曲線的形式表示
1）成本預算：將批準的項目總成本估算分配到項目各項具體工作與活動中，進而確定、測量項目實際執行情況的成本基準。
2）成本控制：在項目施工成本的形成過程中，對形成成本的要素，即施工生產所耗費的人力、物力和各項費用開支，進行監督、調節和限制，及時預防、發現和糾正偏差，從而把各項費用控制在計劃成本的預定目標之內。這通常是工程項目施工成本管理活動中不確定因素最多、最復雜、最基礎也是最重要的管理內容。以工作包為單位，監督成本的實施情況，發現實際成本與預算成本之間的偏差，查出產生偏差的原因，作好實際成本的分析評估工作
3）德爾菲法成本估算，按照最后一個回合的結果進行估算。
4）項目成本基準包含工作包成本估算和應急儲備，但是不包含管理儲備
5）成本糾正措施：
(1) 對造成成本基準變更的因素施加影響；
(2) 確保所有變更請求都得到及時處理，當變更發生時，管理這些變更；
(3) 管理WBS每個組件的成本；
(4) 監督成本績效，找出并分析與成本基準的偏差；
(5) 防止在成本或資源使用報告中出現未經批準的變更，并向相關當事人報告。
204. 規劃質量管理：識別與該項目相關的質量標準以及確定如何滿足這些標準
1）輸入：；影響質量規劃的事業環境
2）輸出：質量管理計劃、過程改進計劃、質量測量指標、質量核對單、 項目文件更新等；
3）編制范圍說明書在編制質量管理計劃之前
4）質量體系與質量計劃：質量體系是為一個組織而建立，針對一個組織不是其中一個部門或者項目或某個產品；質量計劃針對具體產品、項目、服務或合同制訂的
5）首要工作是識別相關質量標準。
205. 質量保證：建立對未來輸出或正在進行的工作完工時滿足特定的需求和期望的信心，通過用規劃過程預防缺陷，或者在執行階段對正在進行的工作檢查出缺陷，來保證質量的確定性；確保采用合理的質量標準和操作性定義的過程。
1）可由第三方團隊進行監督，適當時提供服務支持
2）質量測量指標是質量保證的輸入。
3）質量保證就是注重過程，質量控制注重結。
4）質量保證活動屬于監控過程組。
5）項目質量保證是預防性，提高性和保障性的質量管理活動
6）QA是質量保證人員，質量保證人員主要職責是保證質量管理過程的符合性。
7）工具與技術：質量審計、過程分析、新、舊七種質量工具、統計抽樣等等，實施質量保證的工具與技術包含規劃質量管理和控制質量的工具與技術，但是不包括儲備分析。
? 新七種：親和圖、過程決策程序圖、關聯圖、樹形圖、優先矩陣、活動網絡圖、矩陣圖。
? 老七種：因果圖、流程圖、核查表、帕累托圖、直方圖、控制圖和散點圖。
? 過程決策程序圖：用于理解一個目標與達成此目標的步驟之間的關系，該工具能幫助團隊預測一部分可能破壞目標實現的中間環節，因此有助于制訂應急計劃。
? 控制圖：可以判斷某一過程處于控制之中還是處于失控狀態。當一個過程處于控制之中時，這一過程產生的所有變量都由隨機事件引發，此時的過程是不需要調整的。
? 魚骨圖，因果圖、石川圖：一項結果的產生，必定有其原因，應充分利用圖解法找出其原因來，通過此圖形的繪制來尋找影響特性(或結果)的各要因(或原因)。
? 散點圖：觀察兩個變量之間的關系。
? 直方圖：條形圖、質量分布圖、矩形圖、頻度分布圖、排列圖等，由事件發生的頻度組織而成，用于顯示多少成果產生于已確定的各種類型的原因。
? 帕累托圖：按事件發生的頻率排序,顯示出由于某種原因引起的缺陷數據的排列順序，是找出影響項目產品或服務質量的主要因素。是質量控制的工具與技術。
206. 質量控制：指監控具體項目結果以確定其是否符合相關質量標準，制定有效方案，以消除產生質量問題的原因。
1) 輸入輸出：==>合核實的可交付成果
2) 核實的可交付成果===>驗收的可交付成果
207. 編制質量計劃的工具和技術有：
1.成本/效益分析：滿足質量要求的成本主要是支出與項目質暈管理活動有關的費用，努力使獲得的收益遠遠超過實施過程中所消耗的成本。
2.基準分析：基準分析就是將實際實施過程中或計劃之中的項目做法同其他類似項目的實際做法進行比較，通過比較來改善與提高目前項目的質量管理，以達到項目預期的質量或其他目標。其他項目可以是執行組織內部的項目，也可以是外部的項目，可以是同一個應用領域的項目，也可以是其他應用領域的項目。
3.實驗設計：一種統計分析技術，可用來幫助人們識別并找出哪些變量對項目結果的影響最大。該技術主要用于項目產品或服務問題，同時實驗設計也可以用于諸如成本和進度計劃平衡的項目管理問題的解決過程。
4.質量成本：指為了達到產品或服務質量而進行的全部工作所發生的所有成本。包括一致成本與不一致成本，一致性成本包括預防成本和評價成本，非一致性成本包括內部失敗成本和外部失敗成本。
208. 質量控制
1）輸入：項目管理計劃、質量測量指標、質量核對表、工作績效數據、批準的變更請求、可交付成果、項目文件、組織過程資產；
2）工具：七種基本質量工具、統計抽樣、檢查、審查
3）輸出： 1)質量控制測量結果 2)確認的變更3)核實的可交付成果4)工作績效信息 5)變更請求 6)項目管理計劃更新 7)項目文件更新8)組織過程資產更新
209. 帕累托分析原理：帕累托圖來自于80/20定律，該定律認為大多數的問題或缺陷產生于相對有限的原因，即20%的原因造成了80%的問題。
210. 質量審計與質量保證
1）質量審計：結構化和獨立的評審方法，判斷活動的執行是否遵從于組織及項目定義的方針、過程和規程，識別在項目中使用的低效率以及無效果的政策、過程和規程。后續對質量審計結果采取糾正措施的努力，將會達到降低質量成本和提高客戶或(組織內的)發起人對產品和服務的滿意度的目的。預先計劃VS隨機的；組織內部VS委托第三方(外部)。還確認批準過的變更請求、糾正措施、缺陷修訂以及預防措施的執行情況。
2）質量保證：為使人們確信某一產品、過程或服務的質量所必須的全部有計劃有組織的活動。也可以說是為了提供信任表明實體能夠滿足質量要求，而在質量體系中實施并根據需要進行證實的全部有計劃和有系統的活動。質量保證就是按照一定的標準生產產品的承諾、規范、標準。由國家質量技術監督局提供產品質量技術標準，即生產配方、成分組成、包裝及包裝容量多少、運輸及貯存中注意的問題，產品要注明生產日期、廠家名稱、地址等。經國家質量技術監督局批準這個標準后，公司才能生產產品。國家質量技術監督局就會按這個標準檢測生產出來的產品是否符合標準要求，以保證產品的質量符合社會大眾的要求。
3）評審環節是不可缺少的，通過階段性的評審可以保證項目的質量，同時評審也是保證質量的一個重要環節。
4）軟件測試是軟件質量保證的重要手段是正確的。
5）“過程和產品質量保證”涉及以下活動：對照使用的過程描述、標準和規程客觀地評價所執行的過程、工作產品和服務；識別不符合問題，并形成文件；向項目工作人員和管理者反饋質量保證活動情況；確保不符合問題得到處理。
211. 6σ管理法是質量控制的一種常用方法，其中σ是指示過程作業良好程度的標尺。在6σ管理法中，σ的值越大，則(故障率越低 )。
212. 項目出現了嚴重的缺陷，項目經理將項目團隊和質量工程師召集在一起分析問題，查找原因，大家就此提出了三種不同的看法。此時宜采用(流程圖 )工具或方法來缺定問題根本原因。
213. 問題：1.1(6分)結合案例，請分析該項目質量管理過程中有哪些做得好的地方？
制定了質量管理計劃，項目經理有質量意識，進行了質量控制
214. 問題：1.2(10分)結合案例，請分析該項目質量管理過程中存在哪些問題？
質量管理計劃不得當；缺乏質量標準和質量規范；沒有實施質量保證過程；沒有進行質量審計和過程分析；質量控制不到位；團隊成員缺乏質量意識；缺乏對質量方面的培訓；缺少對質量方面的控制與監督
215. 問題：1.3(6分)請簡述IS0 9000質量管理的原則。以顧客為中心、領導作用、全員參與、過程方法、管理的系統方法、持續改進、基于事實的決策方法、與供方互利的關系。
216. 國家標準(GB/T 19000 2008)對質量的定義為：一組(固有特性)滿足要求的程度。
217. 質量管理是指確定(2質量方針)、目標和職責，并通過質量體系中的質量管理過程來使其實現所有管理職能的全部活動。
218. 在質量管理的技術和工具中，(3流程圖)用來顯示在一個或多個輸入轉化成一個或多個輸出的過程中，所需要的步驟順序和可能分支；(4帕累托圖)用于識別造成大多數問題的少數重要原因；(5散點圖)可以顯示兩個變量之間是否有關系，一條斜線上的數據點距離越近，兩個變量之間的相關性越密切。
219. 問題：2.1(10分)請指出該項目在質量管理方面可能存在哪些問題？
(1) 沒有制訂項目質量管理計劃。(2) 只考慮了項目交付物的質量控制，未考慮項目管理過程的質量保證。(3) 不應只在項目的重要階段進行質量檢查(不要等產品完成后再檢查)，應加強項目過程中的質量控制或檢查。(4) 沒有根據用戶的質量要求形成項目的質量檢查標準、規范，及配備相應的質量檢查工具(如質量檢查單)，而是以個人經驗(張工的經驗)作為質量要求。(5) 質量管理中，沒有與合適的技術手段相結合。(6) 項目質量保證人員應獨立于項目組。(7) “對于不滿足要求的工作，必須立即進行返工”不符合變更流程。(8) 與客戶溝通不夠。(每項2分，最多得10分)
220. 問題：2.2(8分)請指出張工在質量檢查中可能存在的問題。
(1) 沒有提前編制質量管理計劃(質量檢查單)。(2) 沒有依據相關的質量標準或規范進行檢查，而是憑借個人經驗檢查并開具不符合項。(3) 沒有對質量檢查中的不符合項進行分析，并制定預防或糾正措施。(4) 沒有將質量檢查中出現的問題(如人員不配合等)及時升級給項目經理，請項目經理協調處理。(5) 對項目中發現的質量問題，不能主觀認為是小問題而不去糾正。(每項2分，最多得8分)
221. 問題：2.3(6分)針對上述問題，如果你是項目經理，你會采取哪些措施？
(1) 與客戶確認本項目的質量要求和質量規范。(2) 科學制定項目后續的質量管理計劃。(3) 加強質量保證和質量控制，將項目七付物和項目管理過程都納入質量控制范圍。(4) 合理分配質量職責(任命或調入獨立于項目組的QA人員)。(5) 處理不符合項，必要時進行項目變更(調整項目進度、成本計劃)。(6) 加強與客戶的溝通和交流。(每項2分，最多得6分)
222. 在質量控制的工具和技術有(1)、(2)、(3)、(4)、(5)。候選答案：A、趨勢分析 B、試驗設計 C、因果圖 D、統計抽樣E、帕累托圖 F、質量成本 G、成本/效益分析 H、控制圖
223. 沖突不可避免。項目經理必須能夠找到沖突的原因，然后積極地管理沖突，從而最大程度地降低潛在的負面影響。應該采用直接和合作的方式，盡早并且通常在私下處理沖突。如果破壞性沖突繼續存在，則可使用正式程序，包括采取懲戒措施。
（1）沖突是自然的、而且要找解決辦法。
（2）沖突是團隊問題，不是個人問題。沖突應該聚焦在問題，聚焦在現在，而不是過去。
（3）團隊發生沖突時，應本著解決問題的原則進行調解。并不是本著解決矛盾的原則
（4）有5種常用的沖突解決方法：
? 撤退回避：問題推遲到或推給其他，雙方不積極，也不合作；沖突問題沒有解決。
? 緩和包容：單方面退讓一步，強調一致、淡化分歧；謀求非爭議點與對方協作，暫時性的沖突解決方法。
? 妥協調解：雙方愿意果斷解決沖突；暫時或部分解決沖突；妥協是雙方面的包容，包容是單方面的妥協
? 強迫命令:以犧牲其他方為代價，推行某一方的觀點，權力強行解決緊急問題。
? 合作解決:采用合作的態度和開放式達成共識和承諾。這是沖突雙方最理想的結果，前提是雙方要相互尊重、愿意合作、愿意傾聽對方。雙贏或多贏,最理想
224. 規劃人力資源管理
（1）輸入：項目管理計劃、活動資源需求、事業環境因素、組織過程資產。
（2）輸出：人力資源管理計劃。(2分)，人力資源管理計劃包括：角色與職責、項目組織圖、人員配備管理計劃。
（3）項目組織計劃：為保證工程項目的良好開展，項目有關人員的職位設置構架。組織計劃通常包括四方面的內容：角色和職責安排、人員管理計劃、組織圖表和有關說明。
（4）編制人力資源計劃的工具：。
225. 組建項目團隊：角色和責任；項目的組織結構圖；人員配備計劃；環境和組織因素：組織過程資產。資源日歷和項目人員分配屬于輸出內容。
226. 建設項目團隊：執行過程組，為了實現團隊績效及產出最大化而進行的一系列結構設計及人員激勵等團隊優化行為
1）目標：1.提高團隊成員的知識和技能，以提高他們完成項目可交付成果的能力，并降低成本、縮短工期和提高質量；2.提高團隊成員之間的信任和認同感，以提高士氣、減少沖突和增進團隊協作3.創建富有生氣、凝聚力和協作性的團隊文化，以便：提高個人和團隊生產率，振奮團隊精神，促進團隊合作；促進團隊成員之間的交叉培訓和輔導，以分享知識和經驗。
2）工具技術：人際關系技能、培訓、團隊建設活動(拓展訓練、心理偏好指標)、基本規則、同地辦公(集中)、認可與獎勵和人事評測工具。項目人員分派是建設項目團隊的輸入，不是工具與技術
3）定期召開會議與評價團隊績效是在團隊建設完成后做的工作，所以不屬于團隊建設活動
4）團隊建設的目標就是提高團隊的績效，直接結果建設成一個高效、運行良好的項目團隊
5）輸出包括：團隊績效評價、事業環境因素更新。評價團隊有效性的指標可包括：個人技能的改進，從而使成員更有效地完成工作任務；團隊能力的改進，從而使團隊更好地開展工作；團隊成員離職率的降低；團隊疑聚力的加強，從而使團隊成員公開分享信息和經驗，并互相幫助，來提高項目績效。
227. 管理項目團隊：是跟蹤團隊成員工作表現，提供反饋，解決問題并管理團隊變更，以優化項目績效的過程。本過程的主要收益是：影響團隊行為，管理沖突，解決問題，并評估團隊成員的績效。
1）目的：跟蹤個人和團隊的績效，反饋和解決問題以提高項目績效
2）輸入：人力資源管理計劃、項目人員分派、團隊績效評價、問題日志、工作績效報告、組織過程資產
3）可采用觀察和交談、項目績效評估的方法實現對項目團隊的管理
4）企業組織文化可能會影響團隊管理的方式和結果
228. 馬斯洛需求層次理論：生理、安全、社交、 受尊重和自我實現
（1）社會交往：包括對友誼、愛情以及隸屬關系的需求。當生理需求和安全需求得到滿足后，社交需求就會突出出來，進而產生激勵作用。這些需求如果得不到滿足，就會影響員工的精神，導致高缺勤率、低生產率、對工作不滿及情緒低落。常見的激勵措施：定期員工活動、聚會、比賽、俱樂部等。
229. 赫茨伯格雙因素理論：一類是保健因素；另一類是激勵因素；前者是導致不滿足感的，做得不好就會損害激勵，做得好卻不會提高激勵，如工作條件、工資、同事之間的關系、安全、職位等，相當于馬斯洛理論的較低層次的需求(生理、安全、社會需求)；后者是導致滿足感的因素，是能夠真正起激勵作用的，如責任、自我實現、職業發展、得到承認等，相當于馬斯洛理論的較高層次需求(尊重、自我實現需求)。
230. X理論和Y理論：X理論認為人性是“惡”的，Y理論認為人性是“善”的；
231. 期望理論:努力行為與其所獲得的最終獎酬之間的因果關系來說明激勵過程，并以選擇合適的行為達到最終的獎酬目標的理論。它認為，一個目標對人的激勵程度受目標效價和期望值兩個因素影響。
232. 項目經理五種權力：參照、專家、獎勵、懲罰、職位。職位權力來源于管理者在組織中的職位和職權。獎勵權力來源于使用降薪、扣薪、懲罰、批評的負面手段的能力。專家權力來源于個人的專業技能。參照權力是由于他人對你的認可和敬佩從而愿意模仿和服從你，以及希望自己成為你那樣的人而產生的，這是一種人格魅力。
233. 項目團隊5個階段：新加入少量成員，會退回到形成階段，可能會跳過某個階段
（1）形成期：相互認識，了解項目情況及在項目中的正式角色與職責。團隊成員傾向于相互獨立，不怎么開誠布公。一個個獨立的個體成員轉變為團隊成員，開始形成共同目標；對未來團隊往往有美好的期待。
（2）震蕩期：團隊開始從事項目工作，制定技術決策和討論項目管理方法。如果團隊成員對不同觀點和意見不能采取合作和開放的態度，團隊環境可能惡化成破壞性的。一般會遇到超出預想的困難，希望被現實打破。個體之間開始爭執，互相指責，并且開始懷疑項目經理的能力
（3）規范期：團隊成員開始協同工作，并按團隊的需要來調整各自的工作習慣和行為，團隊成員開始相互隨著相互之間的配合默契和對項目經理的信任，成員積極工作，努力實現目標。這時集體榮譽感非常強，常將團隊換成第一稱謂，如我們那個組、我們部門等，并會努力捍衛團隊聲譽信任。團從成員之間相互熟悉和了解，矛盾基本解決，項目經理能夠得到團隊的認可
（4）發揮期：團隊就像一個組織有序的單位那樣工作。團隊成員之間相互依靠，平穩高效地解決問題。
（5）結束期：在結束期階段，團隊完成所有工作，團隊成員離開項目。
234. 項目績效
1）績效審計:經濟審計、效率審計和效果，三E審計，由獨立的審計機構或人員，依據有關法規和標準，運用審計程序和方法，對被審單位或項目的經濟活動的合理性、經濟性、有效性進行監督、評價和鑒證，提出改進建議，促進其提高管理效益的一種獨立性的監督活動。
2）績效評估：對照統一的標準、一定的程序，通過定量定性對比分析，對項目一定經營期間的經營效益和經營業績做出客觀、公正和準確的綜合評判。
3）績效任務：(1) 對每個崗位的工作內容進行分解；(2) 針對每個崗位的工作在進度、成本、質量等上設定KPI值；(3) 確定KPI評分標準；(3) 確定考核頻率。
4）財務績效評估:
①靜態分析法:投資收益率法、投資回收期法、追加投資回收期法、最小費用法等；
②動態分析法:凈現值法、內部收益率法、凈現值比率法、年值投資回收期法等。
235. 風險識別的工具與技術。
1. 文件審查：從項目整體到范圍細節的層次上對以往項目檔案及其他資料中的項目計劃與假設進行系統的審查。
2. 信息搜集技術：集思廣益會、德爾菲技術、面談和SWOT分析(即優勢、弱點、機會與威脅分析，簡稱惡勢分析)。
3. 核對表：可根據歷史資料、以往項目類型所積累的知識、以及其他信息來源著手制訂。缺點：所制訂核對表不可能包羅萬象，而使用者所考慮的范圍卻被有效地限制在核對表所列范疇之內。應該注意探討標準核對表上未列出的事項，如果此類事項與所考慮的具體項目相關的話。核對表應逐項列出項目所有類型的可能風險。務必要把核對表的審議 作為每項項目收尾程序的一個正式步驟，以便對所列潛在風險清單以及風險描述進行改進。
4. 假設分析。每個項目都是根據一套假定、設想、或者假設進行構思與制訂的。假設分析是檢驗假設有效性(即假設是否站得住腳)的一種技術。它辨認假設的不精確、不一致、不完整對項目所造成的風險。
236. 績效評估：兩方面內容：其一是對個體能力的評估；其二是對工作績效的評估。方法：量表評價法、訪談法和觀察法進行。
237. 責任分配矩陣：是用來對項目團隊成員進行分工，明確其角色與職責的有效工具，通過這樣的關系矩陣，項目團隊每個成員的角色，也就是誰做什么，以及他們的職責，也就是誰決定什么，得到了直觀地反映。項目的每個具體任務都能落實到參與項目的團隊成員身上，確保了項目的事有人做，人有事干
238. 人事評測工具：能讓項目經理和項目團隊洞察成員的優勢和劣勢。這些工具可幫助項目經理評估團隊成員的偏好和愿望，團隊成員如何處理和整理信息，團隊成員如何制訂決策，以及團隊成員喜歡如何與人打交道。有各種可用的工具，如態度調查、細節評估、結構化面談、能力測試及焦點小組討論。這些工具有利于增進團隊成員間的理解、信任、忠誠和溝通，在整個項目期間不斷提高團隊成效。
239. 領導者(Leader) 的工作主要涉及三方面:確定方向、統一思想、激勵和鼓舞。
二、溝通管理
1. 溝通方式：
(1) 交互式溝通：兩方/多方之間進行多向信息交換。這是確保全體參與者對特定話題達成共識的最有效的方法，包括會議、電話、即時通信、視頻會議等。
(2) 拉式溝通：信息量很大或受眾很多的情況，接收者自主自行地訪問信息內容，包括企業內網、電子在線課程、經驗教訓數據庫、知識庫等。
(3) 推式溝通：把信息發送給需要接收這些信息的特定接收方，確保信息的發送，但不能確保信息送達受眾或被目標受眾理解，包括信件、備忘錄、報告、電子郵件、傳真、語音郵件、日志、新聞稿等。
2. 溝通管理過程組；
3.規劃溝通：是識別和記錄與干系人的最有效率且最有效果的溝通方式；
（1）輸入：組織過程資產、項目章程、項目管理計劃、項目范圍說明書
4.管理溝通：是促進項目干系人之間實現有效率且有效果的溝通；
管理項目團隊的輸出:(1）變更請求:人員配備的變化。(2）項目管理計劃更新:項目管理計劃中的人力資源管理計劃可能需要更新。(3）項目文件更新:問題日志、角色描述、項目人員分派。(4）事業環境因素更新:對組織績效評價的輸入、個人技能更新。(5）組織過程資產更新:歷史信息和經驗教訓文檔、相關模板、組織的標準流程。
5.控制溝通：隨時確保所有溝通參與者之間的信息流動的最優化。
6.活動順序排列：②看項目章程和采購文件（識別干系人輸入)③識別干系人及其相關信息（識別干系人輸出)④制定干系人管理計劃（規劃干系人管理)
7.干系人分類模型如下：
(1) 權利/利益方格：職權大小和對項目結果的關注(利益)程度進行分類。
(2) 權利/影響方格：職權大小以及主動參與(影響)項目的程度進行分類。
(3) 影響/作用方格：主動參與(影響)項目的程度及改變項目計劃或者執行的能力進行分類。
(4) 凸顯模型：權力(施加自己意愿的能力)、緊迫程度和合法性對干系人進行分類。
8.溝通方式參與程度與控制能力。
參與程度由強到弱依次是：參與討論—征詢—說明—敘述；
控制程度由強到弱依次是：敘述—說明—征詢—參與討論。
9.需求討論會的人數5～7人,包括客戶、系統設計者、開發者和可視化設計者等主要工程角色。
10.溝通基本原則：溝通內外有別、非正式的溝通有助于關系的融洽、采用對方能接受的溝通風格、溝通的升級原則、掃除溝通的障礙。
①內外有別：
②非正式的溝通有助于關系的融洽。
③采用對方能接受的溝通風格。
④溝通的升級原則。合理把握橫向和縱向溝通，“溝通四步驟”反映了溝通的升級原則：第一步，與對方溝通；第二步，與對方的上級溝通；第三步，與自己的上級溝通；第四步，自己的上級和對方的上級溝通。
⑤掃除溝通的障礙。職責定義不清、目標不明確、文檔制度不健全、過多使用行話等都是溝通的障礙。必須進行良好的溝通管理，逐步消除這些障礙。
11.項目溝通管理，就是為了確保項目信息合理收集和傳輸，以及最終處理所需實施的一系列過程，由溝通計劃編制、信息發布、績效報告、管理收尾四部分組成。
（1）溝通計劃的依據：溝通要求、溝通技術、制約因素和假設三個方面，包含一下信息：
(1) 溝通要求：項目組織和各利益相關者之間的關系；該項目設計技術知識；項目本身的特點決定的信息特點；與項目組織外部的聯系等。
(2) 溝通技術：正式和非正式；單向和雙向溝通，橫向和縱向溝通；書面和口頭溝通等，廣泛使用的口頭溝通最有可能解決復雜問題。
(3) 選用何種溝通技術以到達迅速、有效、快捷地傳遞信息主要取決于對信息要求的緊迫程度；技術的取得性；預期的項目環境；制約因素和假設。
12. 干系人管理：指對項目干系人需要、希望和期望的識別，并通過溝通上的管理來滿足其需要、解決其問題的過程。
（1）干系人管理輸入包括：干系人管理計劃、溝通管理計劃、變更日志、組織過程資產。問題日志屬于干系人管理輸出。
（2）作用：項目干系人管理將會贏得更多人的支持，從而能夠確保項目取得成功；可促使項目沿預期軌道行進；提高團隊成員協同工作的能力；
（3）由項目經理負責項目干系人管理。
（4）干系人分析兩個目的：確定不同干系人的信息需求；辨別項目干系人的影響和收益。
14. 項目評審：評審本階段的任務是否已經完成，決定項目是否從當前階段進入下一階段，是發現和糾正錯誤并保證項目聚焦于它所支持的業務發展的需要。
15.績效報告包括完成的活動、成果、里程碑、發現的事件與問題，狀態報告用來報告關鍵的信息，包括但不限于下列內容：①當前的狀態；②本報告期的重要成果；③計劃的活動；④事件。一份完整的績效報告包括：項目進展和執行情況、成本的使用情況、團隊成員的績效情況、項目存在問題及解決措施、對項目的預測。
16.績效報告：收集并發布項目績效信息的動態過程，包括狀態報告、進展報告和項目預測。項目干系人通過審查項目績效報告，可以隨時掌握項目的最新動態和進展，分析項目的發展趨勢，及時發現項目進展過程中所存在的問題，從而有的放矢地制定和采取必要的糾偏措施，即績效報告通常需要提供有關范圍、進度、 成本和質量的信息。
①狀況報告：在某一特定時間點所處的項目階段，從達到范圍、時間和成本三項目標上表明項目所處的狀態。
②進展報告：項目團隊在某一特定時間段工作完成情況。信息系統項目中，一般分為周進展報告和月進展報告。項目經理根據項目團隊各成員提交的周報或月報提取工作績效信息，完成統一的項目進展報告。
③項目預測：在歷史資料和數據基礎上，預測項目的將來狀況與進展。根據當前項目的進展情況，預計完成項目還要多長時問，還要花費多少成本。
17.項目績效報告：指搜集和傳播績效信息，向利害關系者提供資源如何用于實現項目目標的信息。績效報告通常應當提供有關范圍、進度、成本與質量的信息。項目進展情況和結果的匯總報告，不用于分析，內容包括：狀態報告、進度報告、預測和變更請求
（1）當前報告階段的工作完成情況；
（2）進度偏差的根本原因；
（3）對即將完成的里程碑或項目到期日的影響；
（4）對于進度偏差計劃的糾正或預防措施；
（5）當前報告階段已花費的資金；
（6）成本偏差的根本原因；
（7）成本偏差對整個預算的或應急資金的影響；
（8）對于成本偏差計劃的糾正或預防措施；
（9）當前報告階段的質量情況
18.編寫項目績效報告的依據是項目計劃和工作成果。
①狀態報告：某一特定時間點上所處的位置，即從達到范圍、時間和成本目標的角度上說明項目所處的狀態。其內容：包括已經花費多少資金、完成某項任務要多長時間、工作是否如期完成等。編寫狀態報告要用到項目掙得值分析的詳細資料，掙得值分析是一種綜合范圍、時間和成本數據的項目執行績效測量技術。
②進展報告：在某一特定期間所完成的工作。項目經理以從各個成員那里收集的信息為基礎完成統一的每周、每月和每年的進展報告。
③項目預測：指在過去資料和發展趨勢的基礎上，預測項目未來的狀態和進度，包括根據目前項目的進展情況，預計完成項目要多長時間、完成項目需要多少資金等。采用掙得值分析也能回答這些問題，方法是根據項目目前進展的況，進行完工頂算的估算。
④狀態評審會議：常用的一種評估項目績效的好辦法，促使項目組成員對他們自己的工作負責，以及對重要的項目問題進行面對面的溝通討論。
績效報告，而是用于總結。
19項目績效報告的內容:狀態報告、進度報告、預測和變更請求，它使項目利益相關者知曉為了取得項目的目標，是如何使用資源的，編寫項目績效報告的依據是項目計劃和工作成果。
20.不同類型問題：
（1）封閉式問題----用來確認信息的正確性；
（2）開放式問題----鼓勵應征者詳細回答，表達情緒。
（3）探詢式問題----用來澄清之前談過的主題與信息。
（4）假設性問題----用來了解解決問題的方式。
21.溝通聯絡機制應能夠滿足所有項目干系人的溝通需求。
風險管理
1、風險：既包括對項目目標威脅也包括促進項目目標的機會，風險是一種不確定的事件或條件，但具有不確定性的事件不一定是風險
2、風險類型：
（1）風險類別:提供了一種結構化方法以便使風險識別的過程系統化、全面化，保證組織能夠在一個統一的框架下進行風險識別，目的是提高風險識別的質量和有效性。
（2）商業、社會、組織、技術方面的風險，技術風險如黑客攻擊或病毒入侵；設備硬件損壞；開發方出現問題使進度緩慢；
（3）純粹風險和投機風險，在一定條件下可以相互轉化，必須避免投機風險轉化為純粹風險
（4）按照風險的可預測性劃分：已知風險、可預測風險和不可預測風險
①已知風險：嚴格分析項目計劃后，能夠明確的那些經常發生的、而且后果亦可預見的風險
②可預測風險：可以預見其發生，但不可預見其后果的風險
③不可預測風險：可能發生，但其發生的可能性具有不可預見性的風險。未知風險不可管理。
④附近的河流泛濫，致使開發計算機房被淹，導致所有工作停工2周時間——不可預測風險。
⑤預防原材料價格波動，提前儲備了一批原材料，結果原材料價格出現了下跌——已知風險。
⑥設計時未考慮施工要求——技術風險。
3、風險應對策略：風險可分不利風險和有利風險兩類。不利風險的應對措施:規避、減輕、轉移、接受等四種，有利風險應對措施:開拓、分享、提高(或強大)等三種。。
（1）回避：不做有風險的事，或者在已經識別潛在風險的情況下，通過主觀努力，回避高風險活動，以完全消除風險的威脅。
（2）減輕：把風險事件的發生概率或者影響降低到可接受的臨界范圍內,如在一個系統中加入冗余部件，可以減輕主要部件故障所造成的影響。
（3）轉移：把風險的一部分或者全部消極影響，連同應對責任都轉移給第三方，同時要向風險承擔方支付必要的費用。
（4）接受：包括主動接受和被動接受,決定不會為了處理某風險而變更項目管理計劃，或無法找到任何合理的應對策略。前者是提供必要的風險儲備，包括時間、資金或相應資源來應對風險。后者則不采取任何措施，等待風險發生，并接受結果。
4、風險管理計劃編制：決定了如何動手處理、規劃和實施項目的風險管理活動
（1）基本內容：方法論；角色與職責；預算；計時法；風險分類；風險概率和影響的定義；概率和影響矩陣；修改的利害關系者承受度；匯報格式；跟蹤
（2）風險管理計劃編制的成果：風險應對、風險概率、風險影響力的定義。
5、風險識別：形成風險登記冊的最初記錄，也包括其他風險管理過程的成果，風險識別包括識別并確定有哪些潛在的風險，識別引起這些風險的主要因素，以及項目風險可能引起的后果。
（1）風險識別的依據包括：風險管理計劃、成本管理計劃、進度管理計劃、人力資源管理計劃、范圍基準、活動成本估算和活動持續時間估算、干系人登記冊、項目文件、采購文件、事業環境因素、組織過程資產，沒有風險類別。
（2）輸出：已識別風險清單、潛在應對措施清單、風險根本原因、風險類別更新。
（3）注意事項：①風險識別應該全員參與識別，案例中項目經理獨自制定了項目管理計劃；②沒有風險登記冊；③沒有識別出人力資源風險，選擇剛業兩年的小王擔任項目經理；④沒有識別出技術風險，例如，公司沒有智慧法院的相關項目經驗，公司從未有過智能語音識別方面的相關開發經驗；⑤風險識別過程貫穿項目始終，在項目實施和收尾時，沒有識別風險；⑥沒有識別項目進度風險；⑦沒有識別出更變的風險；⑧沒有識別出趕工會帶來質量風險和人員離職風險；⑨沒有識別配置管理風險。
（4）若識別風險過程是由經驗豐富的風險經理完成的，可直接進入定量分析過程；有些情況下，僅通過風險識別過程即可確定風險應對措施，并對這些措施進行記錄，以便在風險應對規劃過程中進一步分析和實施。
（5）風險登記冊的編制始于風險識別過程，主要包括已識別風險清單、潛在應對措施清單、風險根本原因、風險類別更新。
（6）工具與技術：SWOT、文檔評審、頭腦、德爾菲法、檢查表、訪談、假設分析、圖解技術、檢查表和圖解技術(因果分析圖、流程圖、影響圖)等。
①德爾菲法：是風險識別過程中使用的信息收集技術之一，首先需要確定項目風險專家，匿名參加會議。協調員使用問卷征求重要項目風險方面的意見，然后將意見結果反饋給每一位專家，以便進行進一步的討論，可以在主要的項目風險上達成一致意見。德爾菲法有助于減少數據方面的偏見，并避免了個人因素對結果產生的不適當影響。
②圖解技術包括:
(1）因果圖:又被稱做石川圖或魚骨圖，用于識別風險的成因。
(2）系統或過程流程圖:顯示系統各要素之間如何相互聯系，以及因果傳導機制。
(3）影響圖:顯示因果影響，按時間順序排列的事件，以及變量與結果之間的其他關系的圖解表示法。
④訪談是收集風險識別數據的主要方法之一；
⑤根本原因識別指對風險的根本原因進行調查，通過考慮風險的根本原因，制定有效的風險應對措施；
⑥頭腦風暴的目的是取得一份綜合的風險清單。
6、實施定性風險分析：
（1）定性風險分析對項目的風險進行優先級排序，以便進行后續的深入分析或者根據對風險概率和影響的評估采取適當的措施。
（2）輸入輸出：風險管理計劃、范圍基準、風險登記冊、事業、組織
（3）工具與技術：風險概率影響評估、概率和影響矩陣、風險數據質量評估、風險類別、風險緊迫性評估、專家判斷。
①風險概率影響評估：使定性語言將風險發生概率，及其后果描述為極高、高、中、低、極低 5 級
7、實施定量風險分析
（1）蒙特卡洛技術：用一個模型，將詳細規定的各項不確定性換算為它們對整個項目層次上的目標所產生的潛在影響。項目模擬一般采用蒙特卡洛技術。
（2）訪談、專家判斷、靈敏度分析、期望貨幣價值分析、決策樹分析、建模和仿真，數據收集和表示技術等。
8、風險應對：
（1）編制風險應對計劃：開發一些應對方案和措施以提高項目成功的機會、降低項目失敗的威脅
（2）風險應對計劃內容：風險類別、來源、定義與描述、可能發生時間段、大小、應對策略、應急措施、必要的預算、責任人等。而項目管理人員的表現屬于績效管理的內容，而非風險應對計劃的內容。
9、控制風險：要跟蹤風險，識別剩余風險和新出現的風險，修改風險管理計劃，保證風險計劃的實施，并評估消減風險的效果，從而保證風險管理能達到預期的目標。
（1）工具與技術
①風險再評估:應安排定期進行項目風險再評估,項目團隊狀態審查會的議程中應包括項目風險管理的內容。重復的內容和詳細程度取決于項目相對于目標的績效情況。
②風險審計:是檢查并記錄風險應對措施在處理已識別風險及其根源方面的有效性，以及風險管理過程的有效性。項目經理要確保按項目風險管理計劃所規定的頻率實施風險審計，既可以在日常的項目審查會中進行風險審計，也可單獨召開風險審計會議。在實施審計前，要明確定義審計的格式和目標。
③偏差和趨勢分析:可使用掙值分析及項目偏差與趨勢分析的其他方法，對項目總體績效進行監控。
④技術績效測量:技術績效測量指標可包括重量、處理時間、缺陷數量和存儲容量等
（2）輸出包括：請求的變更，建議的糾正措施，建議的預防措施，組織過程資產和項目管理計劃，新發現的風險是更新在風險登記冊中，風險登記冊是屬于項目管理計劃的，新發現的風險管理知識，同時要記錄到組織過程資產供以后的項目參考，批準的變更請求和建議的變更請求完全不一樣。
（3）風險控制中，經常需要識別新的風險，對現有風險進行再評估，以及刪去已過時的風險，應該定期進行項目風險再評估。反復進行再評估的次數和詳細程度，應該根據相對于項目目標的項目進展情況而定。
13. 風險管理流程為：
（1）風險識別：項目組成員共同實施；
（2）風險分析：項目組成員共同實施；
（3）制定風險應對計劃：項目經理；
（4）風險跟蹤：風險負責人；
（5）分析控制；項目組成員共同實施。
14. 風險審計：檢查并記錄風險應對措施在處理已識別風險及其根源方面的有效性，及風險管理過程的有效性。不必使被識別的和相當有威脅的每一個風險都有計算的預期值。
15. 風險管理時間表：定義風險管理過程在項目整個生命周期中的執行頻度，并定義風險管理活動的計劃的工具或活動。
16. 風險預測一般是從風險發生的可能性和風險發生所產生的后果兩個方面來評估風險
17. 風險曝光度(Risk Exposure，RE)的計算公式為RE=P×C。其中，P是風險發生的概率，C是風險發生時帶來的項目成本。
18. 風險清單中列出的風險并不一定會對項目造成影響，首先需要對列出的風險進行分析，包括定性分析和定量分析。在這之后才進行風險應對。
19. 成本超支，進度落后，需要趕工，增加資料，節約成本。但是增加資源也會帶來成本上面的增加，所以需要進行風險的審計和預防。這時最應該做的是:檢查項目中的風險應對措施是否執行到位，對當前的風險采取進一步措施，這個風險應對就包含了進度、成本等控制，比較全面。
采購管理
1. 采購管理包括規劃采購；實施采購、控制采購、結束采購四個過程，細化包括的步驟：
(1) 需求確定與采購計劃的制訂；
(2) 供應商的搜尋與分析；
(3) 定價；
(4) 擬定并發出訂單；
(5) 訂單的跟蹤和跟催；
(6) 驗收與收貨；
(7) 開票和支付貨款；
(8) 記錄管理
2. 編制采購計劃：決定采購什么，何時采購，如何采購，還要記錄項目對于產品、服務或成果的需求，并且尋找潛在的供應商。
（1）采購計劃編制的工具與技術包括：自制/外購分析、專家判斷和合同類型。
（2）采購計劃編制的輸入包括：(1) 項目章程(2) 項目范圍說明書(3) 項目管理計劃(3) 工作分解結構和字典(5) 環境因素和組織因素(6) 組織過程資產(7) 風險記錄
（3）采購計劃編制的第一步是考慮那些產品或服務由項目團隊提供劃算，還是通過采購更為劃算；每一次采購都要經理從編制采購計劃到完成采購的全過程；編制采購計劃需要考慮的內容包括成本估算、進度、質量計劃、現金流預測等。
（4）規劃采購管理的輸入包括：項目管理計劃、需求文檔、風險登記冊、活動資源需求、項目進度、干系人登記冊、事業環境因素、組織過程資產。其中沒有包括采購工作說明書。
3. 實施采購：從潛在的供應商處獲取適當的信息、報價、投標書或建議書；選擇供方，審核所有建議書或報價，在潛在的供應商中選擇，并與選中者談判最終合同。（選擇合適的供方，實施采購）
(1) 公開招標在開標時，應當由招標人主持，投標人自愿參加。
(2) 政府采購：公開招標、邀請招標、競爭性談判、單一來源采購和詢價等。
4. 控制采購：管理合同以及買賣雙方之間的關系，監控合同的執行情況。審核并記錄供應商的績效以采取必要的糾正措施，并作為將來選擇供應商的參考。管理與合同相關的變更。
（1）供應商分級、緊急采購、重新評定等是項目采購管理過程日常管理和控制的范疇
（2）采購不合格控制
①不合格品識別：不符合采購計劃及采購合同所規定要求、規格、標準。
②經進貨驗證確定為不合格的產品，采購應及時處理：退貨；調換；降級改作他用，但降級處理需主管領導批準，并在相關部門備案。
③進貨驗證的不合格品，由驗貨人進行“不合格”標識。
（3）與供應商先確定評價的頻次和方法，列出日程表，按照計劃進行評價
（4）供應商選擇的三大主要因素是供應商的(產品價格)、(質量)和(服務)。
5. 合同收尾：完成并結算合同，包括解決任何未解決的問題，并就與項目或項目階段相關的每項合同進行收尾工作。
（1）合同管理：管理合同及買賣關系；審核并記錄供應商的績效以建立必需的糾正和預防措施，并作為將來選擇供應商的參考；管理合同相關的變更與項目客戶合同關系
6. 采購文件：是賣方準備采購文件中描述的原材料、產品、貨物或服務的表述的基礎
（1）工作說明書SOW應詳細地規定采購項目，其詳細的程度會因項目的性質、買方需求、預期的合同的格式不同而異。工作說明書描述了由賣方供應的產品和服務。說明書中包括的信息可以包括規格說明書、期望數量、質量等級、績效數據、有效期、工作地點和其他的需求。
（2）采購需求通常包括標的物的配置、性能、數量、服務等，(配置)和(性能)最為關鍵。
7. 采購管理存在的常見問題
（1）規劃采購存的問題：①事先沒有制訂好采購管理計劃；②沒有明確供方選擇標準③采購策略不合理、科學；④采購時只考慮低成本，沒有綜合考慮進度時效、質量等的制約因素；⑤《備件采購清單》(即采購工作說明書)存在缺限，部分核心系統備件并有列入其中。
（2）實施采購中存在的問題：①《備件采購合同》沒有明確備件規格、型號、數量等要求，特別是沒有明確驗收標準、驗收(收貨)流程;②沒有做好備件的配置管理，備件出、入庫不規范;③備件管理員和庫員管理員不稱職，沒有做好驗貨和收貨；④沒有做好采購過程中的風險管理和溝通管理；⑤庫房環境存在問題。
（3）控制采購存在的問題：沒有做好合同管理，及時監督合同績效；采購產品驗證完畢后，檢驗合格的產品，出具《進貨檢驗記錄單》；庫房核對本項目對應采購設備準確無誤；供應商提供的運貨單或到貨證明。
8. 采購法律
（1）提出質疑：供應商在知道或應知其權益受到損害之日起七個工作日內，以書面形式向采購代理機構提出質疑(《政府采購法》52條)。
（2）質疑答復：采購代理機構收到書面質疑后七個工作日內對供應商做出答復(《政府采購法》53條)。
（3）提起投訴：供應商如對答復不滿意或采購代理機構未在規定期限內作出答復的，供應商在答復期滿后15個工作日內，向同級財政部門提起投訴(《政府采購法》55條，《投訴處理管理辦法》第7條)。
（4）審查投訴：財政部門收到投訴書后，在五個工作日內進行審查(《投訴處理管理辦法》第11條)。
（5）受理投訴：財政部門對符合投訴條件的投訴，自收到投訴書之日起即為受理投訴(《投訴處理管理辦法》第11條)。
投標文件中存在對招標文件響應的非實質性的微小偏差，需在評標結束前予以澄清。
9. 建立供應商戰略合作伙伴關系的意義
●可以縮短供應商的供應周期，提高供應靈活性。
●可以降低企業采購設備的庫存水平，降低管理費用、加快資金周轉。
●提高采購設備的質量。
●可以加強與供應商溝通，改善定單的處理過程，提高設備需求的準確度。
●可以共享供應商的技術與革新成果，加快產品開發速度，縮短產品開發周期。
●可以與供應商共享管理經驗，推動企業整體管理水平的提高。
10. 采購計劃(Procurement Plan)：根據生產部門或其他使用部門的計劃制定的包括采購物料、采購數量、需求日期等內容的計劃表格。采購計劃應達到下列目的：
(1) 預估數量與時間，防止供應中斷，影響產銷活動。
(2) 避免儲存過多，積壓資金，占用堆積的空間。
(3) 配合公司生產/采貨計劃與資金的高度。
(4) 使采購部門事先準備，選擇有利時機購入商品和物料。
(5) 確立合理耗用標準，以便控制采購商品和物料的成本。
所以，項目采購計劃編制的結果一經管理層確認，將對項目的實際采購活動產生現實性的指導，是項目采購活動的準繩
11. 項目外包：
（1）承包商是軟件外包部分的第一責任人，但是質量保證活動必然涉及到委托方，委托方有項目監管的責任，并且需配合承包方進行需求跟蹤、質量評審等質量保證活動；
（2）已經確定采取外包，就不需要進行自制外購分析了；
（3）對于進行外包的產品，需要進行過程監控，來確保最后交付的產品的質量。
12. 合同類型：總承包合同、單項項目承包合同、分包合同。
（1）總承包合同，“交鑰匙承包”，發包人把信息系統工程建設從開始立項、論證、施工到竣工的全部任務，一并發包給一個具備資質的承包人。
（2）單項項目合：發包人將信息系統工程建設的不同任務，分別發包給不同的承包人。
（3）分包合同：總承建單位將其承包的某一部分或某幾部分項目，再發包給子承建單位。
（4）成本補償合同：為賣方報銷實際成本，成本補償合同也常常包括對達到或超過既定的項目目標(例如進度目標或總成本目標等)的獎勵。
（5）工時材料合同：對于工作規模或產品界定不是特別清楚的項目
合同管理
1. 合同類型：項目實際情況和外界條件約束選擇合同類型。
（1）按項目范圍劃分：項目總承包合同、項目單項承包合同和項目分包合同三類，其中分包合同需要同時滿足：買房認可、非主體工作、部分分包、具備資質、不能再次分包。
（2）按項目付款方式劃分：總價、成本補償類、混合型的工料合同
①總價合同：Fixed Price Contract
? 固定總價合同：Firm Fixed Price FFP工作范圍明確，且項目的設計已具備詳細的細節；賣方承擔風險
? 總價+激勵：Fixed Price incentice Fee,FPIF，允許有一定的績效偏差,并對實現既定目標給予財務獎勵，要設置一個價格上限，賣方必須完成工作并且要承擔高于上限的全部成本。
? 總價+經濟價格調整合同：Fixed Price with Economic Price Adjustment FP-EPA如果賣方履約要跨越相當長的周期(數年)，就應該使用總價加經濟價格調整合同(FP-EPA)。如果買方和賣方之間要維持多種長期關系，也可以采用這種合同類型。
? 單邊合同：當非大量采購標準化產品時，通常可以由買房直接填寫賣方提供的訂購單。
②成本補償類：實際成本作為付款的基礎，即實報實銷。
? 成本+固定費用合同：CPFF，Cost Plus Fixed Fee成本實報實銷，固定費用作為利潤，該費用以目標成本（目標初始估算成本）的某一百分比計算，費用智能針對已完成的工作來支付。
? 成本+激勵費用合同：CPIF，Cost Plus Incentive Fee成本實報實銷，達到目標績效，向賣方支付預先確定的費用。
實際成本>目標成本：目標成本+目標費用+買方應負擔的成本超支；
實際成本<目標成本：目標成本+目標費用-買方應享受的成本節約；
? 成本+獎勵費用合同：成本實報實銷，買方憑感覺給賣方支付一筆利潤，主觀判斷獎勵費用，賣方通常無權申訴。
③混合型工料合同：按項目工作所花費的實際工時數和材料數，按事先確定的單位工時費用標準和單位材料費用標準進行付款。適用于范圍明確，但具體工作量無法。
2. 合同類型選擇
（3）總價合同:工作范圍明確，且項目設計已詳細細節
（4）工料合同:工作性質清晰，工作環境不復雜，需要快速簽訂合同
（5）成本補償合同:工作范圍不清楚
（6）工料合同:雙方成本風險
（7）成本補償合同:買方承擔風險
（8）總價合同:賣方承擔風險
（9）單邊合同：標準產品且數量不大
3. 合同內容：項目名稱、內容和范圍、質量要求、各種期限、技術情報和資料保密、風險承擔責任、技術成果歸屬、驗收標準和方法、價款與報酬及支付方式、違約金或損失賠償計算方法；爭議解決方法；名詞術語解釋。
4. 合同解釋：主導語言原則、適用法律原則、整體解釋原則和公平誠信原則。
5. 合同管理過程：簽訂管理、履行管理、變更管理、檔案管理、違約索賠管理。
（1）合同簽訂：做好市場調研；潛在競爭對手或合作伙伴的自信調查，正確評判競爭激烈程度；作出正確的風險分析判斷。
①合同理解一致的建議：國家或行業標準合同、質量條款、合同變更、轉讓、解除等內容也詳細說明、合同附件與主合同一致；投標書、附件等列明適用順序、公證、
②合同簽署：郵局的郵戳具有法律效力。
③合同是否成立不是看是否有一份雙方都在上面簽過字的協議。而是看是否已經完成要約和承諾。只要是完成了要約和承諾，即使沒有那份協議，合同也已成立。
（2）合同履行管理：對合同履行情況進行跟蹤管理，對合同當事人按合同規定應盡的義務和應盡的職責進行檢查，及時合理處理和解決合同履行過程中出現的問題，包括合同爭議、違約和索賠等事宜。
①解決爭議：替代爭議解決方法（調解和仲裁）、訴訟，仲裁且規定了總裁終局性，就不能向法院訴訟，一般按照談判（協商）、調解、仲裁、訴訟
③合同變更管理：一般特征，雙方當事人協商一致，改變了合同內容，產生新的債權和債務關系；變更條件：雙方當事人協商且不損害國家和社會利益；由于不可抗力導合同義務不能執行，由于另一方在合同約定的期限內沒有履行合同，且在被允許的推遲履行期限內仍未履行
③合同檔案管理：合同檔案管理系統。檔案管理是合同管理的基礎。
④合同索賠管理：一般先由監理工程師調解，若調解不成，由政府建設主管機構進行調解，若仍調解不成，由經濟合同仲裁委員會進行調解或仲裁。
1）索賠原則：索賠的有理性、索賠依據的有效性、索賠計賬的正確性。
2）遵循的流程
①提出索賠要求——索賠方以書面的索賠通知書形式，在索賠事項發生后的28天以內，向監理工程師正式提出索賠意向通知。
②報送索賠資料——在索賠通知書發出后的28天內，向監理工程師提出延長工期和(或)補償經濟損失的索賠報告及有關資料。
③監理工程師答復——監理工程師在收到送交的索賠報告有關資料后，于28天內給予答復，或要求索賠方進一步補充索賠理由和證據。
④監理工程師逾期答復后果——監理工程師在收到承包人送交的索賠報告的有關資料后28天未予答復或未對承包人作進一步要求，視為該項索賠已經認可。
⑤持續索賠——當索賠事件持續進行時，索賠方應當階段性向工程師發出索賠意向，在索賠事件終了后28天內，向工程師送交索賠的有關資料和最終索賠報告，工程師應在28天內給予答復或要求索賠方進一步補充索賠理由和證據。逾期末答復，視為該項索賠成立。
⑥總裁和訴訟。
3）索賠報告的內容：總論部分、根據部分、計算部分和證據部分。索賠報告編寫的一般要求如下：①索賠事件應該真實。②責任分析應清楚、準確、有根據。③充分論證事件給索賠方造成的實際損失④索賠計算必須合理、正確。⑤文字要精煉、條理要清晰、語氣要中肯。
4）索賠分類
索賠目的：工期索賠和費用索賠
索賠依據：合同索賠和非合同索賠，其中非合同索賠指合同沒有專門描述，但可以根據合同條款推論出一定索賠權。
索賠性質：工程索賠和商務索賠，
處理方式：單項索賠和總索賠
6. 要約——發盤與報價，希望和他人訂立合同的意思表示
7. 要約邀請——是希望他人向自己發出要約的意思。如寄送的價目表、拍賣公告、招標公告、招股說明書、商業廣告等。
8. 承諾——通常是買方，即被要約人無條件、完全同意要約人的要約，愿意按此訂立合同的意思。
9. 編制一份相對應的項目合同。(列出主要的條款內容)
10. 《招投標法》《合同法）規定：
（1）合同是一種民事法律行為；合同是兩方或多方當事人意思一致的民事法律行為；合同是以設立、變更、終止民事權利義務關系為目的的民事法律行為
（2）當事人互負債務，標的物種類、品質不相同，將雙方協商一致，也可以抵消
（3）當事人訂立合同，有書面、口頭和其他形式；書面形式是指合同書、信件和數據電文（包括電報、電傳、傳真、電子數據交換和電子郵件）等可以有形的表現所載內容的形式
（4）承諾通知到達要約人時生效。承諾不需要通知的，根據交易習慣或者要約的要求作出承諾的行為時生效。雖然是由于郵局錯遞而延誤了到達時間，但是畢竟過了要約規定的時間，有可能造成要約人接受了別人的承諾，所以這個時候由要約人來決定是否接受是恰當的。
（5）合同生效后，當事人就質量、價款或者報酬、履行地點等內容沒有約定或者約定不明確的，可以協議補充；不能達成補充協議的，按照合同有關條款或者交易習慣確定。
（6）標的物在訂立合同之前已為買受人占有的，合同生效的時間為交付時間。
（7）當事人對合同變更內容約定不明確的，推動為未變更
（8）執行政府定價或者政府指導價的，在合同約定的交付期限內政府價格調整時，按照交付時的價格計價。逾期交付標的物的，遇價格上漲時，按照原價格執行：價格下降時，按照新價格執行。逾期提取標的物或者逾期付款的，遇到價格上漲時，按照新價格執行;價格下降時，按照原價格執行。
（9）在合同中雙方可約定免責條款，如果免責條款中規定的事件發生導致一方無法履行合同的，可以依規定部分或全部免除責任。一般默認的免責條款是不可抗力(不能預見、不能避免或不能克服的客觀情況)的發生，如災害氣候、戰爭等，除法律上另有規定， 因不可抗力不能履行的根據不可抗力的影響可以部分或全部免除責任。
（10）合同雙方可以通過和解或者調解解決合同爭議。雙方不能和解、調解的，可以根據仲裁協議向仲裁機構申請仲裁。涉外合同的雙方可以根據仲裁協議向中國仲裁機構或者其他仲裁機構申請仲裁。雙方沒有訂立仲裁協議或者仲裁協議無效的，可以向人民法院起訴。當事人應該履行發生法律效力的判決、仲裁裁決、調解書：拒不履行的，對方可以請求人民法院執行。
（11）合同生效后，當事人就質量、價款或者報酬、履行地點等內容沒有約定或者約定不明確的，可以協議補充；不能達成補充協議的，按照合同有關條款或者交易習慣確定，適用下列規定：
①質量要求不明確——按照國家標準、行業標準履行；沒有國家標準、行業標準的，按照通常標準或者符合合同目的的特定標準履行。
②價款或者報酬不明確——按照訂立合同時履行地的市場價格履行；依法應當執行政府定價或者政府指導價的，按照規定履行。
③履行地點不明確——給付貨幣的，在接受貨幣一方所在地履行；交付不動產的，在不動產所在地履行；其他標的，在履行義務一方所在地履行。
③履行期限不明確——債務人可以隨時履行，債權人也可以隨時要求履行，但應當給對方必要的準備時間。
④履行方式不明確——按照有利于實現合同目的的方式履行。
⑤履行費用的負擔不明確——由履行義務一方負擔。。
11. 合同收尾：把項目上的每個合同都了結，包括工作完成、產品驗收和移交、價款結算和爭議解決等
(1)項目核實:確認所有工作和可交付成果都正確、令人滿意完成
(2)管理/行政收尾:記錄經驗教訓、更新記錄反映最終結果并存檔信息以備將來之用。
(3)合同收尾過程支持項目收尾過程，因為兩者都涉及驗證所有工作和可交付成果是否可以接受的工作。
(4)合同收尾的工具和技術:采購審計和合同檔案管理系統。
項目收尾過程、過程審計不是其工具。
12. 信息系統工程監理：依法設立且具備相應資質的信息系統工程監理單位，受業主單位委托，依據國家有關法律法規、技術標準和信息系統工程監理合同，為確保信息系統工程的安全和質量，對信息系統工程項目實施的監督管理。
（1）信息系統工程監理活動的任務由監理合同以及監理公司基于該合同由總監理工程師下達的《監理任務書》所確定。
（2）根據監理范圍及內容的不同，信息系統工程的監理模式可分為咨詢式監理、里程碑式監理及全過程監理，建設單位可根據自己的需要在委托監理合同中約定監理模式。
（3）信息系統工程監理活動的主要內容是“四控、三管、一協調”。
信息文檔管理與配置管理
1. 軟件文檔：開發文檔、產品文檔、管理文檔
（1）開發文檔：開發過程本身，如可研報告、任務書 規格說明書、開發計劃、集成和測試計劃、質量保證計劃、安全和測試計劃
（2）產品文檔：開發過程的產物，如培訓手冊、參考手冊和使用指南、產品手冊和信息廣告
（3）管理文檔：記錄項目管理信息，如每個階段的進度和進度變更記錄，軟件變更情況記錄，開發團隊職責定義，項目計劃、項目階段報告。
2. 文檔質量：最低限度文檔（1級），開發量低于1個人月自用程序；內部文檔（2級）沒有與其他用戶共享的專用程序；工作文檔（3級）適用同一單位若干人聯合開發或被其他單位使用；正式文檔（4級）正式發行普遍使用的軟件產品。
3. 配置管理，SCM是一種標識、組織和控制修改的技術，目的是使錯誤降為最小并最有效地提高生產效率。
（1）配置項：典型的配置項包括項目計劃書、需求文檔、設計文檔、源代碼、可執行代碼、測試用例、運行軟件所需的各種數據，他們經評審后進入配置管理，其中基線配置項可能包括設計文檔和源程序等，非基線配置項包括各類計劃和報告等。
①配置項的操作權由CMO（配置管理員）管理，基線配置項向開發人員開放讀取權限，非基線配置項向PM、CCB及相關人員開放。
②配置項狀態：草稿、正式和修改
③版本管理：配置項版本號規則
l 草稿狀態：0.YZ，YZ數字范圍為01-99。
l 正式發布：X.Y，X為主版本號，Y為次版本號。第一次“正式發布”時，版本號為1.0；升級幅度比較小，一般只增大Y值；升級幅度比較大時，才允許增大X值。
l 正在修改：X.Y.Z，一般只增大Z值，X.Y值保持不變。Z的初值和增幅由用戶自己把握。當配置項修改完畢，狀態重新成為“正式發布”時，去掉Z值，堉加X.Y值。
④配置項的主要屬性：名稱、標識符、文件狀態、版本、作者、日期。
（2）配置基線
由一組配置項組成，這些配置項構成一個相對穩定的邏輯實體，對基線的變更遵循正式的變更控制程序。對于每個基線要定義下列內容：建立基線事件、受控的配置項、建立和變更基線的程序、批準變更基線所需的權限。
①一個產品可以有多個基線，也可以只有一個基線。交付給外部顧客的基線一般稱為發行基線，內部開發使用的基線一般稱為構造基線。
②一般要考慮三個基線——功能基線、分配基線和產品基線。
l 功能基線：在系統分析與軟件定義階段結束時，經過正式評審和批準的系統設計規格說明書中對待開發系統的規格說明；或是指經過項目委托單位和項目承辦單位雙方簽字同意的協議書或合同中所規定的對待開發軟件系統的規格說明；或是由下級申請經上級同意或直接由上級下達的項目任務書中所規定的對待開發軟件系統的規格說明。功能基線是最初批準的功能配置標識。
l 分配基線：在軟件需求分析階段結束時，經過正式評審和批準的軟件需求規格說明。分配基線是最初批準的分配配置標識。
l 產品基線：指在軟件測試階段結束時，對編碼階段產生的可運行工件及相關的文檔，經過正式評審的某一軟件版本；對產品基線的修改需要先修改功能基線與分配基線，即需要走正式的變更流程。
③基線的主要屬性包括標識符、基線名稱、基線版本、預計建立日期、實際建立時間等。基線的屬性一般不包括流程
（3）配置庫有三類：開發庫、受控庫和產品庫。
①開發庫：存放開發過程中需要保留的各種信息，供開發人員個人專用。庫中的信息可能有較為頻繁的修改，只要開發庫的使用者認為有必要，無需對其做任何限制。因為這通常不會影響到項目的其他部分。
②受控庫：在信息系統開發的某個階段工作結束時，將工作產品存入或將有關的信息存入。存入的信息包括計算機可讀的以及人工可讀的文檔資料。應該對庫內信息的讀寫和修改加以控制。
③產品庫：在開發的信息系統產品完成系統測試之后，作為最終產品存入庫內，等待交付用戶或現場安裝。庫內的信息也應加以控制。可見作為最終產品應將其存入產品庫。
（4）配置庫權限設置。
①開發庫，開發者對自己的文件庫有讀寫權，但釋沒有刪除的權限
②基線受控庫，配置管理員有讀寫權限，開發人員只有讀權限
③產品受控庫，只有項目負責人和配置管理員有讀寫權限
（5）對開發文檔可以變更
④QA(質量保證人員)可對項目文檔：追加、重命名、刪除等命令。
⑤項目成員可對代碼變更。
⑥測試人員只對代碼進行測試，不能追加、重命名、刪除等命令。
⑦配置管理員對代碼可以進行清除。
4. 配置管理員(CMO)，負責在整個項目生命周期中進行配置管理活動，具體有：編寫配置管理計劃、建立和維護配置管理系統、建立和維護配置庫、配置項識別、版本管理和配置控制、配置狀態報告、配置審計、發布管理和交付、對項目成員進行配置管理培訓，版本管理與發布由配置管理員執行。
5. 日常配置管理活動
(1) 配置狀態報告應該包含以下內容：①每個受控配置項的標識和狀態；②每個變更申請的狀態和已批準的修改的實施狀態;③每個基線的當前和過去版本的狀態及版本的比較；④其他配置管理過程活動的記錄
(2) 配置管理活動：配置標識、配置控制、配置狀態報告、配置審計、發布管理與交付
(3) 配置控制：。，
6. 軟件配置管理通常包括版本控制、變更控制和過程支持，涉及配置項、工作空間管理、版本控制、變更控制、狀態報告、配置審計等具體活動。
7. 創建基線或發行基線的主要步驟包括：配置管理員識別配置項；為配置項分配標識；為項目創建配置庫，并給每個項目成員分配權限；各項目團隊成員根據自己的權限操作配置庫；創建基線或發行基線，并獲得變更管理委員會(CCB)的授權；形成文件；使基線可用等。
建基線或發現基線的主要步驟是：獲取CCB的授權、創建構造基線或發行基線、形成文件、使基線可用
8. CCB，負責對配置變更作出評估、審批及監督已批準變更的實施，不必是常設機構，通常CCB的工作是通過評審手段來決定項目基準是否能變更，但不提出變更方案。
(1) 根據工作的需要組成，CCB可以只有一個人，甚至兼職人員；
(2) CCB是決策機構，不是作業機構；
(3) 主要負責指導和控制配置管理的各項具體活動的進行，為項目經理的決策提供建議。其具體職責為以下幾項：定制開發子系統、定制訪問控制、制定常用策略；建立、更改基線的設置，審核變更申請；根據配置管理員的報告決定相應的對策。
9. 變更管理的主要任務包括：1.分析變更的必要性和合理性，確定是否實施變更；2. 記錄變更信息，填寫變更控制單；3.做出更改，并交上級審批；4.修改相應的軟件配置項(基線)，確立新的版本；5.評審后發布新版本。
10. 配置審核：
（1）任務是驗證配置項對配置標識的一致性，驗證包括：對配置項的處理是否有背離初始的規格說明或已批準的變更請求的現象；配置標識的準則是否得到了遵循；變更控制規程是否已遵循，變更記錄是否可供使用；在規格說明、項目產品和變更請求之間是否保持了可追溯性。
（2）配置審計(或稱配置審核)工作主要集中在兩個方面，一是功能審計，即驗證配置項的實際功效是否與其需求相一致；二是物理審計，即確定配置項是否符合預期的物理特征(指特定的媒體形式)。變更過程的規范性審核、介質齊備性檢查、配置項齊全性審核屬于物理審計，代碼走查屬于功能審計。
（3）意義：為了確保項目配置管理的有效性，體現配置管理的最根本要求，不允許出現任何混亂現象，如：
①防止出現向用戶提交不合適的產品，如交付用戶手冊版本不正確。
②發現不完善的實現，如開發出不符合初始規格說明或未按變更請求實施變更。
③找出各配置項間不匹配或不相容的現象。
④確認配置項已在所要求的質量控制審查之后作為基線入庫保存。
⑤確認記錄和文檔保持著可追溯性。
（4）實施配置審核的時機：交付或正式發行前；開發工作結束之后；在維護工作中，定期地進行。
（5）變更管理委員會CCB負責審批配置管理計劃，配置管理員制定該計劃
11. 配置標識是配置管理員的職能，基本步驟如下： (1）識別需要受控的配置項。 (2）為每個配置項指定唯一性的標識號。 (3）定義每個配置項的重要特征。 (4）確定每個配置項的所有者及其責任。 (5）確定配置項進入配置管理的時間和條件。 (6）建立和控制基線。 (7）維護文檔和組件的修訂與產品版本之間的關系。
12. 變更管理的原則是項目基準化、變更管理過程規范化。包括以下內容。
(1) 基準管理：在項目實施過程中，基準計劃確定并經過評審后(通常用戶應參與部分評審工作)，建立初始基準。此后每次變更通過評審后，都應重新確定基準。
(2) 變更控制流程化:建立或選用符合項目需要的變更管理流程，所有變更都必須遵循這個控制流程進行控制。流程化的作用在于將變更的原因、專業能力、資源運用方案、決策權、干系人的共識、信息流轉等元素有效綜合起來，按科學的順序進行。
(3) 明確組織分工:至少應明確變更相關工作的評估、評審、執行的職能。
(4) 評估變更的可能影響:變更的來源是多樣的，既需要完成對客戶可視的成果、交付期等變更操作，還需要完成對客戶不可視的項目內部工作的變更，如實施方的人員分工、管理工作、資源配置等等。
(5) 妥善保存變更產生的相關文檔，確保其完整、及時、準確、清晰，配置工具：Rational ClearCase、Visual SourceSafe和Concurrent Versions System。
13. 配置管理常見問題
（1）對配置管理工作不夠重視，配置管理人員是兼職人員；
（2）編制配置管理計劃時，應該邀請項目組成員，建設單位人員，公司管理人員一起參與；
（3）編制的配置管理計劃沒有經過評審和審批；
（4）除配置管理員外，不能對項目組其他成員開放所有配置權限；
（5）配置管理混亂，沒有嚴格執行配置管理計劃；
（6）對配置項的變更，沒有遵循變更管理流程；
（7）配置項變更，應該由CCB進行審批。
14. 配置庫變更控制流程
（1）提出變更申請；
（2）對變更初審；
（3）變更方案論證；
（4）CCB審批；
（5）發出變更通知并組織實施；
（6）變更實施的監督；
（7）變更效果的評估；
（8）判斷發生變更以后的項目是否已納入正軌。
15. 質量審計目標
（9）審查項目執行過程是否遵循了質量管理計劃及相關質量標準規定；
（10）識別正在實施的良好過程及實踐；
知識管理
1. 知識管理：為了增強組織的績效而創造、獲取和使用知識的過程。知識管理主要涉及4個方面：自上而下地監測、推動與知識有關的活動；創造和維護知識基礎設施；更新組織和轉化知識資產；使用知識以提高其價值。
2. 隱性知識于顯性知識的區別
3. 知識管理工具分為知識生成工具、知識編碼工具和知識轉移工具三大類。
(1) 知識生成：工具包括知識獲取、知識合成和知識創新三大功能
(2) 實施合成：標準的形式表現知識，使知識能夠方便地被共享和交流
(3) 知識轉移：知識轉移障礙可分成三類，分別是時間差異、空間差異和社會差異
4. 學習型組織特點：相互影響、溝通和知識共享。知識更新和深化。知識的商品化。掌握對環境的適應能力。團隊合作精神。
5. 扁平化組織結構金字塔組織結構：扁平化組織結構設計有利于知識在組織內部的交流發明，金字塔組織結構。
6. 知識產權：
(4) 發明專利權的期限20年，實用新型專利權和外觀設計專利的期限為10年，均自申請日起計算。
(5) 獨立保護原則：指某成員國民就同一智力成果在其他締約國(或地區)所獲得的法律保護是互相獨立的，外國人在另一個國家所受到的保護只能適用該國的法律，按照該國法律規定的標準實施。
(6) 知識產權在某成員產生、被宣告無效或終止，并不必然導致該知識產權在其他成員也產生、被宣告無效或終止。
變更管理
1. 變更初審
(1) 目的：對變更提出方施加影響，確認變更的必要性，確保變更是有價值的；格式校驗，完整性校驗，確保評估所需信息準備充分；在干系人間就提出供評估的變更信息達成共識。
(2) 常見方式為變更申請文檔的審核流轉。
(3) 整體變更控制：項目管理計劃、工作績效報告、變更請求、事業環境因素、組織過程資產=》批準的變更請求、變更日志、項目管理計劃更新、項目文件更新（更新的文件包括：受制于項目正式變更控制過程的所有文件）
2. 項目變更分類
(1) 根據變更性質可分為:重大變更、重要變更和一般變更，通過不同審批權限控制。
(2) 根據變更的迫切性可分為:緊急變更、非緊急變更，通過不同變更處理流程進行。
3. 變更管理工作程序:（1）提出與接受變更申請（2）對變更的初審:常見方式為變更申請文檔的審核流轉（3）變更方案論證（4）項目管理委員會審查（5）發出變更通知并組織實施（6）變更實施的監控（7）變更效果的評估（8）判斷發生變更后的項目是否已納入正常軌道
(1) 在通知變更結果環節，如果變更申請得到批準，應該及時把變更批準信息和變更實施方案通知給那些正在使用受影響的配置項和基線的干系人。
(2) 基于配置庫的變更控制：系統一處發生變更，經常會連鎖引起多出變更，會涉及參與開發工作的許多人員。
4. 變更注意事項：
(3) 變更提出應當及時以正式方式進行，并留下書面記錄。變更的提出可以是各種形式，但在評估前應以書面形式的提出。
(4) 項目的干系人都可以提出變更申請，但一般情況下都需要經過指定人員進行審批，一般項目經理，或者項目配置管理員負責該相關信息的收集，以及對變更申請的初審。
(5) 變更管理的原則是項目基準化、變更管理過程規范化。
(6) 項目經理對項目整體變更負最終責任
(7) 當客戶明確提出某項需求需要更改時，項目經理應該先評估變更會對項目帶來怎樣的影響，然后再與客戶商量解決措施。
1. 變更控制委員會：角色和職責應在變更控制和配置控制過程中予以明確定義，并應取得所有關鍵項目干系人的認可。很多大型組織規定了一種多級的委員會結構以劃分職責。而變更控制委員會更新項目計劃、任務清單和時間表，反映的是變更對在做或未做工作的影響。
2. 變更管理組織機構：規范的項目實施，提倡出資方與項目實施方之間分權操作。基準計劃中應明確資源的配置約定，通常共識的工作部分由項目實施方按基準執行，操作權授予項目經理；而項目的儲備資源屬未授權部分，支持項目中的變更操作，權利屬于項目出資人，在項目中的代表人為管理委員會。
3. 項目變更控制委員會：項目變更控制委員會或配置控制委員會(Configuration Control Board, CCB),或相關職能的類似組織，是項目的所有者權益代表，負責裁定接受哪些變更。
(1) CCB由項目所涉及的多方人員共同組成，通常包括用戶和實施方的決策人員。
(2) CCB是決策機構，不是作業機構。
(3) CCB的工作是通過評審手段來決定項目是否能變更， 但不提出變更方案。
4. 項目經理：對項目負責，其正式權利由項目章程取得，而資源調度的權力通常在項目基準中明確規定。項目基準中不包括的儲備資源需經授權人批準后方可使用。項目經理在變更中的作用是：響應變更提出者的要求，評估變更對項目的影響及應對方案，將要求由技術要求轉化為資源需求，供授權人決策；并據評審結果實施即調整項目基準，確保項目基準反映項目實施情況。所以，該公司的上述規定是根據公司的實際情況制定的，可以有效運轉。
5. 變更常見問題(每條2分，滿分10分)
(1) 作為項目經理，小張只定義了簡單規則，沒有建立變更控制流程；
(2) 變更的影響不能由工程師或項目經理個人評估；
(3) 沒有對變更和修改進行記錄；
(4) 變更完成后，客戶沒有對變更進行驗證；
(5) 變更沒有通知相關人員；
(6) 變更沒有與配置管理相關聯。
6. 變更管理流程和執行效果。
(1) 變更管理和配置管理相關流程是否符合項目管理理論與實踐：
(2) 項目經理制定的規則是否全面？是否符合變更管理流程？
(3) 客戶需求發生變化時，應首先由工程師對需求變化造成的影響做評估，如果影響不大，工程師可以直接進行修改并更新版本，不需要上報項目經理——是否合理？
(4) 當工程師不能判斷需求變化對項目的影響時，應上報給項目經理，由項目經理作出評估，并安排相關人員進行修改——是否合理？
7. 變更流程(每條2分，滿分10分)
(1) 提出變更申請；對變更進行評估；變更審批并通知相關人員；發出變更通知并實施變更；對變更結果進行驗證；更新配置信息(通知相關人員)。
8. 變更涉及的角色：變更申請人、變更控制委員會、變更執行人和驗證人(二者答其一即可得分)、配置管理員
戰略管理
1. 企業戰略：基本屬性是相同的，都是對企業整體性、長期性、基本性問題的計謀。
(1) 戰略管理包過程:①戰略制定:確定企業任務,認定企業的外部機會與威脅,認定企業內部優勢與弱點，建立長期目標，制定供選擇戰略，以及選擇特定的實施戰略。②戰略實施:樹立年度目標、制定政策、激勵員工和配置資源，以便使制定的戰略得以貫徹執行。③戰略評價:重新審視外部與內部因素;度量業績;采取糾偏措施。
(2) 項目型企業的戰略實施過程中，將企業的戰略轉化為一系列的項目來實施企業的戰略，按多項目或項目群來管理各個項目，達到企業的戰略目標。一個優秀的項目經理應該了解企業的商業戰略目標，與企業高層管理者緊密合作。
(3) 信息系統規劃(ISP)：是從企業戰略出發，構建企業基本的信息系統架構，對企業內、外信息資源進行統一規劃、管理與應用，利用信息系統控制企業行為，輔助企業進行決策，幫助企業實現戰略目標。ISP方法經歷了三個主要階段：
① 第一個階段：以數據處理為核心，圍繞職能部門需求的信息系統規劃，方法包括企業系統規劃法、關鍵成功因素法和戰略集合轉化法；
② 第二個階段：以企業內部管理信息系統為核心，圍繞企業整體需求進行的信息系統規劃，方法：戰略數據規劃法、信息工程法和戰略柵格法；
③ 第三個階段：在綜合考慮企業內外環境的情況下，以集成為核心，圍繞企業戰略需求進行的信息系統規劃，主要的方法包括價值鏈分析法和戰略一致性模型。
2. 組織戰略實施：指揮型、變革型、合作型、文化型、增長型
(1) 指揮型戰略組織模式，特點是組織高層考慮如何制定一個最佳戰略，然后按照該戰略進行實施，相關戰略執行人員要向組織高層提交戰略實施的詳細報告，組織高層根據報告情況，再對戰略進行必要的調整，并對具體的管理和執行人員實施
(2) 變革型戰略組織模式，特點是組織是以如何實施組織戰略這一主題展開的。在戰略實施中，組織高層決策者或在其他方面的幫助下需要對組織進行一系列的變革，如建立新的組織機構，新的信息系統，變更人事，甚至是兼并或合并經營范圍，采用激勵手段和控制系統以促進戰略的實施。在具體的戰略實施過程中，組織領導者往往會利用新的組織機構和參謀人員向全體成員傳遞新戰略的戰略重點；并建立戰略規劃系統、效益評價系統，以及多項激勵政策以支持戰略實施；以達到充分調動組織內部人員的積極性，保證組織戰略的順利實施
(3) 合作型戰略組織模式。要求組織的最高層要與其他高層管理人員分擔相關的戰略責任，組織高層管理人員要對組織戰略進行充分的討論，形成較為一致的意見，然后制定并貫徹新的戰略，使每個高層管理者都能夠在戰略制定及實施的過程中做出各自的貢獻
(4) 文化型戰略組織模式。組織高層是從如何動員全體成員都參與戰略實施活動的角度來考慮戰略的制定和執行。主要是運用組織文化手段，不斷向全體成員傳播戰略思想，以便在組織內部建立起共同的價值觀和行為準則，使所有成員在共同的文化基礎上參與戰略的實施活動。（1）克服了指揮型模式和變革型模式存在的局限性，使組織高層能夠接近一線管理人員，獲得比較準確的信息，使組織各部分人員都在共同的戰略目標下工作，組織戰略實施迅速，風險較小；（2）缺點是由于戰略是不同觀點、不同目的的參與者相互協商折衷的結果，有可能會使戰略的經濟合理性有所降低，同時仍然存在著計劃者與執行者之間的區別，仍未能充分調動全體管理人員的積極性。
(5) 增長型戰略組織模式：組織高層從如何激勵一般管理人員制定實施戰略的積極性及主動性來著眼戰略的制定和實施。組織高層要認真對待一般管理人員提出的一切有利組織發展的方案，只要方案基本可行，符合組織戰略發展方向，就解決方案中的具體問題進行探討后，應及時批準該方案，以鼓勵成員的首創精神。該戰略組織模式不是自上而下推行，而是自下而上產生的
4種戰略組織.必須掌握.考的不多
根據一個組織在解決開創性問題、工程技術問題或行政管理問題時采用的思維方式和行為特點(即戰略傾向)，可以將組織分為防御型、開拓型、分析型和被動反應型4種類型。前三種戰略組織都有其市場和能力相適應的戰略，而第4種戰略組織卻是一種失敗的組織類型。
(1) 防御型戰略組織。防御型戰略組織試圖在解決開創性問題過程中建立一種穩定的經營環境，生產有限的一組產品，占領整個潛在市場的一部分。在這個有限市場中，防御型組織常采用競爭性定價和生產高質量產品來阻止竟爭對手的進入，從而保持自己的穩定。
(2) 開拓型戰略組織。與防御型組織不同，開拓型組織更適合于動態的環境，它的能力主要體現在尋找和開發新的產品和市場的機會上。對于一個開拓型組織來說，在行業中保持一個創新者的聲譽比獲得高額利潤更重要。
(3) 分析型戰略組織。防御型組織有較高的組織效率但適應性差，而開拓型組織正相反，分析型組織是介于兩者之間，試圖以最小的風險和最大的機會獲得利潤。
(3) 反應型戰略組織。以上三種類型的組織雖然各自的形式不同，但都能適應外部環境的變化和市場的需求，并隨著時間的推移，都會形成各自穩定的模式。而反應型組織在外部環境變化時卻采取了一種動蕩不定的調整方式，缺少靈活應變的機制。也就是說，它的適應循環會對環境變化和不確定性做出不適當的反應，并且對以后的經營行為猶豫不決，其結果總是處于不穩定的狀態，所以，反應型組織是一種消極無效的組織形態。
組織級項目管理
1、從業務管理、組織架構、人員配備等多個方面對組織進行項目化管理
2、組織級項目管理是在其內部搭建起項目組合管理、項目集管理和單項目管理的各個領域，以及在這些領域之間支持實現最佳實踐而提供的一個組織全局項目管理的框架體系。
3、組織級項目管理主要包括一下三個方面目的：指導和管理投資決策和恰當的投資組合，實現組織資源的最優化配置；提供透明的組織決策機制，使得組織項目管理的流程合理化和規范化；提高實現期望投資回報率的可能性，加強組織對項目管控的系統性和科學性
4、組織級項目管理內容：
(1) 最佳實踐，一類是組織級項目管理SMCI（標準化、度量、控制和持續改進）最佳實踐，使得組織級項目管理流程都能夠圍繞這樣的循環、不斷持續改進；二類是組織運行潛能方面的最佳實踐，主要包括：組織結構、文化、技術、人力資源等方面的最佳實踐，是支持組織級項目管理流程實施的底層要素
(2) 組織能力
(3) 成果
5、組織級項目管理成熟度模型：
(1) OPM3定義“他是評估組織通過管理單個項目和組合項目來實施自己戰略目標的能力的一種方法，他還是幫助組織提高市場競爭力的工具”，OPM3的目標是提供一種開發組織項目管理能力的基本方法，并使得組織內部項目與組織自身的戰略緊密聯系起來
(2) OPM3是一個三位的模型
① 第一維：是成熟度模型四個梯度，分別是標準化、可測量的、可控制的、持續改進的
② 第二維：項目管理十大領域及五個基本過程
③ 第三維：組織小面積項目管理的三個版圖層次，分別是單個項目管理、項目集管理、項目組合管理。
流程管理；
1、以顧客利益為中心、以員工為中心、以及以效率和效益為中心是業務流程核心;
2、流程要素：
(1) 輸入；運行流程所必須的資源，包括人、財、物、信息、關系、計劃等
(2) 活動：流程運轉環節
(3) 活動之間的相互作用：是環節之間的關系，將流程從頭尾串聯起來
(4) 輸出：流程運作結果，他應該承載流程的價值
(5) 客戶：流程化服務對象，
(6) 價值：流程運作為客戶帶來的好處；
3、流程特點：
(1) 流程是由一系列相關關聯和相互作用的活動組成，這些活動是可以定義、可測量和已結構化；
(2) 流程化的目的是為流程的客戶創造價值
(3) 流程通常一個或多個輸入資源
(4) 流程能夠依據規定要求將它的輸入資源適當轉換為輸出；
4、流程管理過程：良好的業務流程管理步驟包括
(1) 流程設計、執行、評估和改進，這是一個PDCA閉環管理過程
(2) 業務流程的管理不是在流程規劃出來之后才進行，而是在流程規劃之前就要進行管理；
5、流程管理層次：流程管理一般分：生產流程層、運作層、計劃層、戰略層四個層次
6、業務流程分析：為業務流程合理改造提供建議
(1) 業務流程分布步驟：1)調查掌握基本情況；2)描述現有業務流程；3)確認現有業務流程；4)對業務流程進行分析；5)發現問題并提出解決方案；6)提出優化后的業務流程
(2) 業務流程分析方法：價值鏈、客戶關系、供應鏈、基于ERP的分析及業務流程重構等；
① 價值鏈：找出或設計能夠讓顧客滿意，實現顧客價值最大化業務流程
② 客戶關系分析法：
③ 基于ERP：將企業業務流程看作一個緊密連接的供應鏈，將供應商和企業內部采購、生產、銷售及客戶緊密聯系起來，對供應鏈上的所有環節進行有效管理，實現對企業的動態控制和各種資源的集成和優化，從而提升企業基礎管理水平，追求企業資源的合理、高效利用
④ 業務流程重構：；，
(3) 業務流程分析工具：業務流程圖、業務活動圖示、UML活動圖、標桿瞄準、IDEF（建模、仿真）、DEMO（行為角色之間他通信）、Petri（描述和分析復雜系統的模型工具）、業務流程建模語言，主要由BPEL、BPML、BPMN、XPDL和UML五種；
(4) 業務流程設計：工作流管理是人與計算機共同的自動化協調、控制和通信
(5) 流程設計的工具：
① 常見圖形工具包括
1) 程序流程圖：圖框表示各種操作，箭頭不受任何約束，可以隨意轉移控制
2) IPO：系統分析階段產生的數據流圖，將優化和轉換后形成系統模塊結構圖，分析和設計人員應為每個模塊寫一份說明，即可使用IPO描述輸入、輸出和數據加工
3) N-S圖：順序、選擇、WHILE循環
4) 盒圖:
5) 問題分析圖：PAD執行順序從最左主干線上端的節點開始，自上而下依次執行，每遇到判斷或玄幻，就自左而由進入下一次層，從表示下一層的縱線上端開始執行，直到該縱線下端，在返回上一層縱線的轉入處。
6) 判定樹；
② 表格工具工具包括
1) 判定表；表格形式
2) 判斷樹：；
③ 語言工具包括過程設計語言。
(6) 業務流程實施：
(7) 業務流程評估：
①
1) 增值性分析：評價活動三個參數 r——價值系數 f——貢獻 c——成本
2) 流程設計的正確性、
3) 業務流程方案評價
② 業務流程實施條件評估：管理基礎、人本管理傳統、企業信息化
③ 企業業務流程實施成果必然體現在經營管理的績效上，衡量業務了流程實施效果的關鍵指標：產品和服務質量、顧客滿意、銷售增值率、成本、員工工作效率。同時，業務流程實施取得顯著效果的一個標志是帶來企業文化，特別是員工價值觀念的變化。
(8) 流程重構BPR和改進
① BPR 全部生命周期 根本性、徹底性、顯著性和流程是BPR強調的四個核心內容
② BPR原則：以流程為中心、團隊式管理、以顧客為導向
③ BPR實施：
④ BPR與信息系統規劃相互作用，相輔相成：1）信息系統規劃要以BPR為前提，且在系統規劃的整個過程中，以業務流程為主；2）面向流程的信息系統規劃驅動企業的BPR；
(9) 業務流程：管理、操作和支持流程三大類
7、敏捷項目管理：每個項目迭代安排兩周內完成。使用較多的Scrum方法，是一種迭代增量軟件開發過程，主要角色包括：主管、產品負責人、開發團隊、其中主管的職責和項目經理類似，負責維護過程和任務；產品負責人代表利益所有者，開發團隊包括開發人員。
(1) 敏捷項目管理流程包括：構想、推測、探索、適應、結束。構想——啟動；推測——計劃、探索——管理；適應——監控，敏捷項目管理團隊關注構想、監控信息，從而適應當前情況，這就是適應階段；敏捷項目管理模式以結束階段收尾，在這個階段主要目標是傳遞知識
20. 計算題：
1. BAC完工預算，不含管理儲備
2. AC實際成本，已完成工作實際成本；
3. PV計劃價值，完成工作的計劃價值；
4. EV掙值，實際已完成工作的計劃價值；
5. SV進度偏差 Schedule Variance SV=EV-PV<0落后，>0超前
6. CV成本偏差，CV=EV-AC
7. 進度績效指數SPI=EV/PV
8. 成本績效指數CPI=EV/AC
9. 非典型情況：以后還是按照計劃執行，完工尚需估算ETC=BAC-EV；完工估算EAC=AC+ETC；完工總時間：
10. 典型情況：之前的進度成本不是特殊，后面一直保持,ETC=（BAC-EV）/CPI=(BAC-EV)*AC/EV或EAC=AC+ETC=BAC/CPI;完工時間：計劃總工期/SPI
11. 成本估算工具與技術：專家判斷、自下而上估算、三點估算、儲備分析、質量成本、項目管理軟件、投標分析、群體決策技術
12. 成本超支：關注成本超支嚴重的工作；對成本支出細化分析，找出成本超支原因；真不不同的原因，采取對應的措施，如減少不必要的工作，優化工作流程每提高效率，削減不必要的資源；定期對項目的成本績效進行評估，及時按情況進行調整；加強質量管理，及時發現問題，減少返工，從而節約成本；必要時，調整成本基準。
13. 進度糾正措施
趕工，投入更多的資源或增加工作使勁按，以縮短關鍵活動工期
快速跟進，并行施工，以縮短關鍵活動路徑長度
使用高素質資源或經驗更豐富的人員
減小活動范圍或降低活動要求
加強質量管理，及時發現問題，減少返工，從而縮短工期
14. 成本糾正措施
關注成本超支嚴重的工作
針對成本的支出細化分析，找出成本超支原因
真不不同原因，采用對應措施，如減少不必要的工作，優化工作流程每提高效率，削減不必要的資源
定期對項目的成本績效進行評估，及時按情況進行調整
加強質量管理，及時發現問題，減少返工，從而節約成本
必要時，調整成本基準。
15. EMV
16. 溝通渠道
17. 投資回收期=最后一項為負值的累計凈現金流量對應的年數+最后一項為負值的累計凈現金流量絕對值÷下年凈現金流量
18. 投資回報率
19. 凈現值NPV 貼現率/折現率
20. 收益率=年投資收益/投資額
CMMI繼承了CMM的階段表示法和EIA/IS731的連續式表示法，這兩種表示法各有優缺點，均采用統一的24個過程域，他們在邏輯上是等價的；對同一個組織采用兩種模型分別機械能CMMI評估，得到結論應該是相同的。
階段式模型
已管理級：需求管理、項目管理計劃、配置管理、項目監督和控制、供應商合同管理、度量和分析、過程和產品質量保證。
已定義級：需求開發、技術解決方案、產品集成、嚴重、確認、組織級過程焦點、組織級過程定義、組織級培訓、集成項目管理、風險管理、集成化的團隊、決策分析和解決方南、項目組織集成環境。
定量管理級：組織級過程性能、定量項目管理
量化級：組織級改革和實施、因果分析和解決方案
連續式模型
過程管理：組織級過程焦點、組織級過程定義、組織級培訓、組織級過程性能、組織改革域實施；
項目管理：項目計劃、項目監督與計劃、供應商合同管理、集成項目管理、風險管理、基礎啊的團隊、定量項目管理；
工程：需求管理、需求開發、技術解決方案、產品集成、驗證、確認；
支持：配置管理、度量和分析、過程和產品質量保證、決策分析和解決方案、組織級集成環境、因果分析和解決方案
測試：靜態測試與動態測試
1、靜態測試：針對文檔的檢查單；針對代碼的桌面檢查、代碼走查和代碼審查
2、動態測試：
(1) 白盒測試：適用于：單元測試、結構測試。方法：控制流測試、數據流測試和程序變異測試；邏輯覆蓋
(2) 黑盒測試：適用于：功能測試、集成測試、確認測試和系統測試。方法：等價類劃分、邊界值分析、判定表、因果圖、狀態圖、隨機測試、猜錯法
3、單元測試：模塊是否正確實現設計說明書中的功能、性能、接口和其他設計約束條件
4、集成測試：模塊間
5、確認測試：與用戶需求一致
(1) 內部確認測試——軟件組織按照SRS進行測試
(2) Alpha測試——用戶在開發環境下進行
(3) Beta測試——用戶在實際使用環境下進行測試
6、系統測試：對象是完整、集成的計算機系統，目的是在真實系統工作環境下，驗證完整的軟件配置項能否和系統正確連接，并滿足系統/子系統設計文檔和軟件開發合同規定的要求。
7、配置項測試：軟件配置項
8、回歸測試：
軟件調試和軟件測試：找出錯誤VS定位并修正；調試在測試之后；
軟件測試的管理：過程管理、配置管理、評審工作。
EAI 必考1分
1、表示集成：界面集成，黑盒集成，使用的技術包括屏幕截取和輸入模擬技術
2、數據集成：白盒集成，使用不同的中間件工具用于數據集成，如批量文件傳輸、ODBC標志接口、數據庫訪問中間件技術
3、控制集成：功能集成、應用集成、 黑盒集成，是在業務邏輯層對系統集成。
4、業務流程集成 過程集成，復雜性最高，這種集成超越了數據和系統，它由一系列基于標準的、統一數據格式的工作流組成。
5、企業之間的應用集成：