繼續(xù)肝吧，爭取本周把項目管理的內容肝完吧，抓緊開啟新章節(jié)，結束基礎知識，進入案例備考，本章主要講的質量管理，風險管理的內容。
1.質量管理
質量是軟件產品特性的綜合，表示軟件產品滿足明確（基本需求）或隱含（期望需求）要求的能力。質量管理是指確定質量方針、目標和職責，并通過質量體系中的質量計劃、質量控制、質量保證和質量改進來使其實現的所有管理職能的全部活動；
主要包括以下過程：
（1)質量規(guī)劃：識別項目及其產品的質量要求和標準，并書面描述項目將如何達到這些要求和標準的過程。
（2)質量保證：一般是每隔一定時間（例如，每個階段末）進行的，主要通過系統的質量審計（軟件評審）和過程分析來保證項目的質量。
（3)質量控制：實時監(jiān)控項目的具體結果，以判斷它們是否符合相關質量標準，制訂有效方案，以消除產生質量問題的原因。
信息技術軟件產品評價質量特性及其使用指南GB/T 16260-2002
注意：6大特性，每個大特性下包含21個子特性！理解記憶吧，考試會考的！
McCall質量模型
軟件評審
質量兩個必要條件：設計的規(guī)格說明書符合用戶標準，稱為設計質量。
程序按照設計規(guī)格說明書所規(guī)定的情況正確執(zhí)行，稱為程序質量。
軟件容錯技術：容錯就是軟件遇到錯誤的處理能力，實現容錯的手段主要是冗余，包括下面四種冗余技術：
結構冗余：分為靜態(tài)、動態(tài)、混合冗余三種，當錯誤發(fā)生時對錯誤進行備份處理。
信息冗余：為檢錯和糾錯在數據中加上一段額外的信息，例如校驗碼原理。
時間冗余：遇到錯誤時重復執(zhí)行，例如回滾，重復執(zhí)行還有錯，則轉入錯誤處理邏輯。
冗余附加技術：是指為實現結構、信息和時間冗余技術所需的資源和技術，包括程序、指令、數據、存放和調動它們的空間和通道等。在屏蔽硬件錯誤的容錯技術中。
真題來嘍：
1.軟件質量保證是軟件項目控制的重要事段，（）是軟件質量保證的主要活動之一。
A.風險評估 B.軟件評審 C.需求分析 D.架構設計
2.ISO/IEC軟件質量模型中，易使用性是指與使用所需的努力由一組規(guī)定或隱含的用戶對這樣使用所作的個別評價有關的一組屬性，其易使用性的子特性不包括（）。
A、易理解性 B、易學性 C、易分析性 D、易操作性
解析：這個就去前邊的定義找就可以了，B C（易分析性屬于可維護性的大類里邊）
2.風險管理
風險管理就是要對項目風險進行認真的分析和科學的管理，這樣，是能夠避開不利條件、少受損失、取得預期的結果并實現項目目標的，能夠爭取避免風險的發(fā)生或盡量減小風險發(fā)生后的影響。但是，完全避開或消除風險，或者只享受權益而不承擔風險是不可能的。
風險管理計劃編制：如何安排與實施項目的風險管理，制定下列各步的計劃。
風險識別：識別出項目中已知和可預測的風險，確定風險的來源、產生的條件、描述風險的特征以及哪些項目可以產生風險，形成一個風險列表。
風險定性分析：對已經識別的風險進行排序，確定風險可能性與影響、確定風險優(yōu)先級、確定風險類型。
風險定量分析：進一步了解風險發(fā)生的可能性具體由多大，后果具體由多嚴重。包括靈敏度分析、期望貨幣價值分析、決策樹分析、蒙特卡羅模擬。
風險應對計劃編制：對每一個識別出來的風險來分別制定應對措施，這些措施組成的文檔稱為風險應對計劃。包括消極風險（避免策略、轉移策略、減輕策略）；積極風險（開拓、分享、強大）
風險監(jiān)控：監(jiān)控風險計劃的執(zhí)行，檢測殘余風險，識別新的風險，保證風險計劃的執(zhí)行，并評價這些計劃對減少風險的有效性。
項目風險：作用于項目上的不確定的事件或條件，既可能產生威脅，也可能帶來機會。
通過積極和合理的規(guī)劃，超過90%的風險都可以進行提前應對和管理。
風險應該盡早識別出來，高層次風險應記錄在章程里。
應由對風險最有控制力的一方承擔相應的風險。
承擔風險程度與所得回報相匹配原則，承擔的風險要有上限。
風險的屬性：
（1)隨機性：風險事件發(fā)生及其后果都具有偶然性（雙重偶然）遵循一定的統計規(guī)律。
（2)相對性：風險是相對項目活動主體而言的。承受力不同，影響不同。風險承受力影響因素：收益大?。ㄊ找嬖酱?，越愿意承（擔風險）投入大?。ㄍ度朐酱螅惺苣芰υ叫。?；主體的地位和資源（級別高的人能承擔較大的風險）
（3)風險的可變性：條件變化，會引起風險變化。包括性質、后果的變化，以及出現新風險。
風險的分類：
按照后果的不同，風險可劃分為純粹風險（無任何收益）和投機風險（可能帶來收益）。
按風險來源劃分，自然風險（天災）和人為風險（人的活動，又可分為行為風險、經濟風險、技術風險、政治和組織風險等）。
按是否可管理劃分，可管理（如內部多數風險）和不可管理（如外部政策），也要看主體管理水平。
按影響范圍劃分，局部風險（非關鍵路徑活動延誤）和總體風險（關鍵路徑活動延誤）。
按后果承擔者劃分：業(yè)主、政府、承包商、投資方、設計單位、監(jiān)理單位、保險公司等。
按可預測性劃分：已知風險（已知的進度風險）、可預測風險（可能服務器故障）、不可預測風險（地震、洪水、政策變化等）。
在信息系統項目中，從宏觀上來看，風險可以分為項目風險、技術風險和商業(yè)風險。
項目風險是指潛在的預算、進度、個人（包括人員和組織）、資源、用戶和需求方面的問題，以及它們對項目的影響。項目復雜性、規(guī)模和結構的不確定性也構成項目的（估算）風險因素。項目風險威助到項目計劃，一旦項目風險成為現實，可能會拖延項目進度，增加項目的成本。
技術風險是指潛在的設計、實現、接口、測試和維護方面的問題。此外，規(guī)格說明的多義性、技術上的不確定性、技術陳舊、最新技術（不成熟）也是風險因素。技術風險威脅到待開發(fā)系統的質量和預定的交付時間。如果技術風險成為現實，開發(fā)工作可能會變得很困難或根本不可能。
商業(yè)風險威脅到待開發(fā)系統的生存能力，主要有以下5種不同的商業(yè)風險：
（1)市場風險。開發(fā)的系統雖然很優(yōu)秀但不是市場真正所想要的。
（2)策略風險。開發(fā)的系統不再符合企業(yè)的信息系統戰(zhàn)略。
（3)銷售風險。開發(fā)了銷售部門不清楚如何推銷的系統。
（4)管理風險。由于重點轉移或人員變動而失去上級管理部門的支持。
（5)預算風險。開發(fā)過程沒有得到預算或人員的保證。
注意：上線的項目風險（項目風險，技術風險，商業(yè)風險）需要記憶財務風險管控小視頻，考試會考！
真題來嘍：
1.以下關于軟件風險的敘述中，不正確的是（）
A、風險是可能發(fā)生的事件
B、如果發(fā)生風險，風險的本質、范圍和時間可能會影響風險所產生的后果
C、如果風險可以預測，可以避免其發(fā)生
D、可以對風險進行控制
2.以下敘述中，（）不是一個風險。
A.由另一個小組開發(fā)的子系統可能推遲交付，導致系統不能按時交付客戶
B.客戶不清楚想要開發(fā)什么樣的軟件，因此開發(fā)小組開發(fā)原型幫助其確定需求
C.開發(fā)團隊可能沒有正確理解客戶的需求
D.開發(fā)團隊核心成員可能在系統開發(fā)過程中離職
答案：C B
補充內容：中級里邊會考，高級考的比較少！
組織結構模式：項目型（項目經理絕對領導）、職能型（部門領導為主）、矩陣型（二者結合，既有項目經理也有部門領導，但權利分割不同）。
程序設計小組的組織方式：
（1)主程序員制小組（主程序員全權負責，后援工程師必要時能替代主程序員，適合大規(guī)模項目）
（2)民主制小組（也即無主程序員小組，成員之間地位平等，任何決策都是全員參與投票，適合于項目規(guī)模小，開發(fā)人員少，采用新技術和確定性較小的項目）
（3)層次式小組（兩個層次，一名組長領導若干個高級程序員，每個高級程序員領導若干個程序員）。
真題來嘍：
1.在進行軟件開發(fā)時，采用無主程序員的開發(fā)小組，成員之間相互平等；而主程序員負責制的開發(fā)小組，由一個主程序員和若干成員組成，成員之間沒有溝通。在一個由8名開發(fā)人員構成的小組中，無主程序員組和主程序員組的溝通路徑分別是（）。
A.32和8 B.32和7 C.28和8 D.28和7
解析：這個在高項里是溝融渠道的計算題，有計算公式的，溝通渠道的總量為n(n-1)/2, 其中n代表干系人的數量。再根據題意主程序員負責制，成員之間沒有溝通的話，溝通渠道就是7條，小組成員只能與主程序員溝通，答案選D
感謝大伙點贊+關注的支持，是我持續(xù)學習更新的動力財務風險管控小視頻，關注公眾號：Coding-9527，跟大伙一起學習，成長，進步！
更多財稅咨詢、上市輔導、財務培訓請關注理臣咨詢 素材來源：部分文字/圖片來自互聯網，無法核實真實出處。由理臣咨詢整理發(fā)布，如有侵權請聯系刪除處理。
400-835-0088
