繼續(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)相對性：風險是相對項目活動主體而言的。承受力不同，影響不同。風險承受力影響因素：收益大小（收益越大，越愿意承（擔風險）投入大小（投入越大，承受能力越?。?/span>主體的地位和資源（級別高的人能承擔較大的風險）

（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，跟大伙一起學習，成長，進步！