管理目標及優(yōu)先級 風險管理

1、L管理目標及優(yōu)先級管理目標及優(yōu)先級基本管理原那么：每位成員既是樂觀的建言者，又是負責的合作者，同 時也是決策的制定者。決策應在充分的爭論基礎上由大家共同做出， 一旦決策做出就必需被準時有效的執(zhí)行。禁止再有異議。目標1：按時按量完成工程的基本功能，按時發(fā)布產(chǎn)品及文檔，這是 本團隊的最高目標。目標2：遵循法律規(guī)范化的工程運作標準，文檔嚴謹完整，代碼注釋 充分，便于后續(xù)維護，這是其次目標。目標3：產(chǎn)品運行穩(wěn)定，界面友好，用戶易操作，盡量從用戶的角度 去看問題，并提出解決問題的方案。目標4：留意團隊建設，成員分工合理，團隊成員合作默契，氣氛融 洽。每周的爭論會樂觀建言。在開發(fā)過程中樂觀協(xié)作。目標5：工

2、程 設計和開發(fā)上盡量有創(chuàng)新，有亮點。工程溝通管理報告機制：1.要求各組員以周為單位紀錄工作進展，形成開發(fā)日志，并以電子文本產(chǎn)品必需能與之互操作的其他產(chǎn)品/系統(tǒng)的數(shù)目？最終用戶的水平如何？必需產(chǎn)生并交付給用戶的產(chǎn)品文檔的量與質(zhì)如何？政府對本產(chǎn)品開發(fā)的約束？延遲交付所造成的本錢消耗是多少？產(chǎn)品缺陷所造成的本錢消耗是多少？對于待開發(fā)產(chǎn)品的每一個回答都必需與過去的閱歷加以比擬。假如消 失了較大的百分比偏差，或者假如數(shù)字相近但過去的結(jié)果很不令人滿 足，那么風險較高。5）客戶相關的風險并非全部客戶都是一樣的。Pressman和Herron PRE91在爭論這個 話題時曾經(jīng)說過：客戶有不同的需要。一些人知道

3、他們需要什么；而另一些人知道他們 不需要什么。一些客戶盼望進行具體爭論，而另一些客戶那么滿足于模 糊的承諾?？蛻粲胁煌墓残?。一些人喜愛享受客戶的身份一一緊急、談判、一 個好產(chǎn)品帶來的心理滿足；而另一些人那么根本不喜愛作為客戶。一些 人會興奮地接受幾乎任何交付的產(chǎn)品，并能充分采用一個不好的產(chǎn) 品；而另一些人那么會對質(zhì)量差的產(chǎn)品猛烈抨擊。一些人會對質(zhì)量好的 產(chǎn)品表示他們的欣賞；而另一些人那么不管怎樣都會埋怨不休?？蛻艉退麄兊墓讨g也有各種不同的通信方式。一些人特別熟識 產(chǎn)品及生產(chǎn)廠商；而另一些人那么可能素未謀面，僅僅通過信件往來和 幾個匆忙的 與生產(chǎn)廠商溝通?？蛻舫３Ｊ菦_突的。他們盼望昨天的

4、一切工作都是免費的。生產(chǎn)廠商 常常陷入客戶自己的沖突之中。一個“不好的”客戶可能會對一個軟件工程組能否在預算內(nèi)按時完成 工程產(chǎn)生很大的影響。對于工程管理者而言，不好的客戶是對工程方 案的巨大威逼和實際的風險。下面的風險檢查表中的條目標識了與客 戶特征相關的常見風險：你以前是否曾與這個客戶合作過？該客戶是否很清晰需要什么？他能否花時間把需求寫出來？該客戶是否同意花時間召開正式的需求收集會議（第11章），以確 定工程范圍？該客戶是否情愿建立與開發(fā)者之間的快速通信渠道？該客戶是否情愿參與復審工作？該客戶是否具有該產(chǎn)品領域的技術(shù)素養(yǎng)？該客戶是否情愿讓你的人來做他們的工作，即，當你的人在做具體 的技術(shù)工

5、作時，該客戶是否會堅持在旁邊監(jiān)視？該客戶是否了解軟件過程？假如對于這些問題中的任何一個的答案是否認的，那么需要進行進一步 的調(diào)研，以評估潛在的風險。6）技術(shù)問題是否使用便利易用的規(guī)格說明技術(shù)來幫助客戶與開發(fā)者之間的通 信？是否使用特定的方法進行軟件分析？是否使用特定的方法進行數(shù)據(jù)和體系結(jié)構(gòu)的設計？是否百分之90以上的代碼都是采納高級語言編寫的？是否認義及使用特定的規(guī)章進行代碼編寫？是否使用特定的方法進行測試用例設計？是否使用軟件工具來支持方案和跟蹤活動？是否使用配置管理軟件工具來掌握和跟蹤軟件過程中的變化活 動？是否使用軟件工具來支持軟件分析和設計過程？是否使用工具來創(chuàng)立軟件原型？是否使用軟件

6、工具來支持測試過程？是否使用軟件工具來支持文檔的生成和管理？是否收集全部軟件工程的質(zhì)量度量值？是否收集全部軟件工程的生產(chǎn)率度量值？假如對于上述問題中大多數(shù)的答案是否認的，那么軟件過程是薄弱的， 且風險很高。7）技術(shù)風險突破技術(shù)的限制是極具挑戰(zhàn)性且令人興奮的，這是幾乎每一個技術(shù)人 員的幻想，由于這迫使開發(fā)人員使出他的或她的渾身解數(shù)，但這也是 很有風險的。Murphy定律好像對開發(fā)工作中的這一局部有了掌握， 使得我們難以猜想風險，更不用說對它們進行方案了。下面的風險檢 查表中的條目標識了與建筑的技術(shù)相關的常見風險：該技術(shù)對于你的組織而言是新的嗎？客戶的需求是否需要創(chuàng)立新的算法或輸入、輸出技術(shù)？軟件

7、是否需要使用新的或未經(jīng)證明的硬件接口？待開發(fā)軟件是否需要與開發(fā)商供應的未經(jīng)證明的軟件產(chǎn)品接口？待開發(fā)軟件是否需要與其功能及性能均未在本領域中得到證明的數(shù) 據(jù)庫系統(tǒng)接口？產(chǎn)品的需求中是否要求采納特定的用戶界面？產(chǎn)品的需求中是否要求開發(fā)某些程序構(gòu)件，這些構(gòu)件與你的組織以 前所開發(fā)過的構(gòu)件完全不同？需求中是否要求使用新的分析、設計、或測試方法？需求中是否要求使用非傳統(tǒng)的軟件開發(fā)方法，如形式化方法、基于AI的方法、以及人工神經(jīng)網(wǎng)絡？需求中是否有過份的對產(chǎn)品的性能約束？客戶能確定所要求的功能是“可行的”嗎？假如對于這些問題中的任何一個的回答是確定的，那么需要進行進一步 的調(diào)研，來評估潛在的風險。風險緩解

8、、監(jiān)控和管理 這一步的全部風險分析活動都只有一個目的一一幫助工程組建立處 理風險的策略。一個有效的策略必需考慮三個問題：風險避開。風險監(jiān)控。風險管理及意外大事方案。假如軟件工程組對于風險采納主動的方法，那么避開永久是最好的策 略。這可以通過建立一個風險緩解方案來到達。例如，假設頻繁的人 員流淌被標注為一個工程風險，rOo基于以往的歷史及管理閱歷，人 員頻繁流淌的概率10被估算為0.7 （70%,相當高），而影響xO被猜 測為對于工程本錢及進度有嚴峻的影響。為了緩解這個風險，工程管理必需建立一個策略來降低人員流淌?？?能實行的策略如下：與現(xiàn)有人員一起研討一下人員流淌的緣由（如，惡劣的工作條件，

9、低酬勞，競爭激烈的勞動力市場）。在工程開頭之前，實行行動以緩解那些在管理掌握之下的緣由。一旦工程啟動，假設會發(fā)生人員流淌并實行一些技術(shù)以保證當人員 離開時的工作連續(xù)性。對工程組進行良好組織，使得每一個開發(fā)活動的信息能被廣泛傳播 和溝通。定義文檔的標準，并建立相應的機制，以確保文檔能被準時建立。對全部工作進行具體復審，使得不止一個人熟識該項工作。對于每一個關鍵的技術(shù)人員都指定一個后備人員。隨著工程的進展，風險監(jiān)控活動開頭進行了。工程管理者監(jiān)控某些因 素，這些因素可以供應風險是否正在變高或變低的指示。在人員頻繁 流淌的例子中，應當監(jiān)控以下因素：工程組成員對于工程壓力的一般態(tài)度。工程組的分散力。工程

10、組成員彼此之間的關系。與酬勞和利益相關的潛在問題。在公司內(nèi)及公司外工作的可能性。除了監(jiān)控上述因素之外，工程管理者還應當監(jiān)控風險緩解步驟的效 力。例如，前述的一個風險緩解步驟中要求定義“文檔的標準，并建 立相應的機制，以確保文檔能被準時建立。假如有關鍵的人員離開 了工程組，這是一個保證工作連續(xù)性的機制。工程管理者應當認真地 監(jiān)控這些文檔，以保證每一個文檔內(nèi)容正確，且當新員工加入該工程 時，能為他們供應必要的信息。風險管理及意外大事方案假設緩解工作已經(jīng)失敗，且風險變成了 現(xiàn)實。連續(xù)前面的例子，假定工程正在進行之中，有一些人宣布將要 離開。假如依據(jù)緩解策略行事，那么有后備人員可用，由于信息已經(jīng)文 檔

11、化，有關學問己經(jīng)在工程組中廣泛進行了溝通。此外，工程管理者 還可以臨時重新將資源調(diào)整到那些人員充分的功能上去（并調(diào)整工程 進度），從而使得新加入人員能夠“趕上進度”。同時，應當要求那些 要離開的人員停止工作，并在最終幾星期進入“學問交接模式:這 可能包括：基于視頻的學問捕獲，“注釋文檔”的建立和/或與仍留在 工程組中的成員進行溝通。值得留意的是，RMMM步驟將導致額外的工程開銷。例如，花費 時間去“備份”每一個關鍵的技術(shù)人員是需要花錢的。因此，風險管 理的局部任務是評估何時由RMMM步驟所產(chǎn)生的效益低于實現(xiàn)它們 所花費的本錢。本質(zhì)上是講，工程方案者執(zhí)行一個典型的本錢一效益 分析來估算工程的開銷

12、變化狀況。假如對于頻繁人員流淌風險的緩解 步驟將會增加15%的工程本錢及持續(xù)時間，而主要的本錢因素是“備 份后備人員”，那么管理者可能打算不執(zhí)行這一步驟。另一方面，假如 風險緩解步驟僅增加5%的本錢及3%的持續(xù)時間，那么管理者極有可 能將這一步驟付諸實現(xiàn)。對于一個大型工程，可能標出30或40種風險。假如為每種風險 定義三至七個風險管理步驟，那么風險管理本身就可能變成一個“項 目”！因此，我們將Pareto的80-20規(guī)章用于軟件風險上。閱歷說明： 整個軟件風險的80% （即，可能導致工程失敗的80%的潛在因素） 能夠由僅僅20%的已標出風險來說明。早期風險分析步驟中所實現(xiàn) 的工作能夠關心方案者

13、確定哪些風險在所說的這20%中。因此，一 些已經(jīng)標出、評估過及猜想過的風險可能并不納入RMMM方案之中 它們不屬于那關鍵的20% （具有最高工程優(yōu)先級的風險）。W.RMMM方案的迭代時間支配表V.總結(jié)一旦建立了 RMMM方案，且工程開頭啟動，那么風險緩解及監(jiān)控步驟 也開頭了。正如我們前面爭論過的，風險緩解是一一種問題避開活動。風險監(jiān)控那么是一種工程跟蹤活動，它有三個主要目的：（1）評估一個 被猜想的風險是否真正發(fā)生了；（2）保證為風險而定義的緩解步驟被 正確地實施；以及（3）收集能夠用于將來風險分析的信息。在許多 狀況下，工程中發(fā)生的問題可以追溯到不止一個風險，風險監(jiān)控的另 一個任務就是試圖在

14、整個工程中確定“起源”（什么風險引起了什么 問題）?？偨Y(jié)當對軟件工程期望很高時，一般都會進行風險分析。不過，即使他們 進行這項工作，大多數(shù)軟件工程管理者都是非正式地和外表上地完成 它?；ㄔ跇俗R、分析、和管理風險上的時間可以從多個方面得到回報: 更加平穩(wěn)的工程進展過程；較高的跟蹤和掌握工程的力量；由于在問 題發(fā)生之前已經(jīng)做了周密方案而產(chǎn)生的信念。風險分析需要占用大量工程方案的工作量。標識、猜想、評估、管理、 及監(jiān)控都要花費時間。但這是值得的。引用中國2500多年前的兵法 家孫子的話：“知己知彼，百戰(zhàn)不殆二對于軟件工程管理者而言，這 個“彼”指的就是風險。檔的形式提交給秘書進行整理，最終由文檔維護

15、員進行維護。.每周例會上各位組員樂觀對當前的開發(fā)工作進行樂觀的評審和建 言，由組長做最終的作口頭總結(jié)，由秘書主持會議并紀錄和整理睬議 的內(nèi)容。文檔維護員修改和維護相應的文檔。并交由小組進行會議評 審并給出意見。.小組成員都要親密監(jiān)控風險狀態(tài)，覺察風險后提交風險報告。.在工程進行的過程當中，組員之間應當多進行各種形式的非正式溝 通，以使溝通更加的便利、快捷。報告格式：報告主題，時間段，覺察人，報告內(nèi)容，審核意見評審機制：每周例會上小組爭論形成全都意見后并，并邀請團長和其 他組長參與評議。對于重大的風險處即為通過，相關負責人針對改進 意見開展下一周工作，嚴格執(zhí)行例會上所制定的決策。小組會議持續(xù) 評

16、估其成效。每一工程階段結(jié)束之前（里程碑前后），組織一次階段 評審會，評估整個階段的工作效率和成果質(zhì)量。盡量與工程例會合理 意見，應當由團長及其他組長組成評審團對處理意見進行審議和評 估。并以評審團的決議作為重要參考來制定決策。軟件開發(fā)方案進度時間如表5-1所示表57軟件開發(fā)方案時間表工作集子工作完成時間負責人最終交付物描述預備 工作確定小組第三周劉冬冬小組成員名單成立高校生競賽平臺報名 系統(tǒng)開發(fā)團隊搭建環(huán)境第三周曹啟云劉冬冬Myeelipse6.0 +SQLsever200確定開發(fā)工具及語言2.風險管理5制定工程管理 方案書第三周李洪達工程管理方案 書初稿制定軟件開發(fā)過程管理方 案完成需 求規(guī)

17、格 說明書 的初稿采集用戶需求第五周劉文慧需求規(guī)格說明 書的初稿通過查資料了解和采集用 戶的需求。對需求進行匯 總，制定需求規(guī)格說明初稿分析用戶需求 及制定需求規(guī) 格說明原型第五周需求規(guī)格說明 的進一步完善 與修改第六周需求規(guī)格說明 的最終確認第六周系統(tǒng)設 il-系統(tǒng)總體設計第八周位置軟件設計報告 初稿制定系統(tǒng)總體的設計方案， 并依據(jù)需求說明聯(lián)系實際 進行相應的修改系統(tǒng)具體設計第九周系統(tǒng)模型及架 構(gòu)最終確定第十周開發(fā)系 統(tǒng)源代 碼及源 碼測試系統(tǒng)源碼開發(fā)第十一周劉冬冬曹啟云源代碼要求嫻熟使用java和.jsp 平臺系統(tǒng)源碼測試第十二周韓云測試文檔依據(jù)測試文檔嚴格測試子系統(tǒng)運行檢 查第十三周曹啟

18、云劉冬冬無采用上機時間，由各組長提 前預約時間進行整 個報名 系統(tǒng)的 集成進行整個高校 生競賽平臺報 名系統(tǒng)的集成第十四周劉冬冬 曹啟云無與其他組員之間合作完成 整個系統(tǒng)的集成對整個集成后 的系統(tǒng)進行測 試檢查運行狀 況第十四周曹啟云 劉冬冬 韓云無搭建整個系統(tǒng)的運行平臺 測試整個系統(tǒng)的發(fā)布狀況系統(tǒng) 交付系統(tǒng)交付第十五周劉冬冬一個可以運行 的的系統(tǒng)以及 用戶手冊和關 心。以及最終 確定的技術(shù)文 檔各組之間可以溝通各自的 開發(fā)閱歷和心得體會引言風險是關注將來將要發(fā)生的事情。今日和昨天已不再被關懷, 猶如我們已經(jīng)在收獲由我們過去的行為所播下的種子。問題是：我們 是否能夠通過轉(zhuǎn)變我們今日的行為，而為

19、一個不同的、布滿盼望的、 更美妙的明天制造機會。其次，這意味著，風險涉及轉(zhuǎn)變，如思想、 觀念、行為、或地點的轉(zhuǎn)變,”，第三，風險涉及選擇及選擇本身所包含 的不確定性。因此，就象死亡和稅收一樣，風險是生活中最不確定的 元素之一。當在軟件工程領域考慮風險時,Charette的三個概念定義是顯 而易見的。將來是我們所關懷的一一什么樣的風險會導致軟件工程徹 底失敗呢？轉(zhuǎn)變也是我們所關懷的一一用戶需求、開發(fā)技術(shù)、目標計 算機、以及全部其他與項R相關的因素的轉(zhuǎn)變將會對按時交付和總體 勝利產(chǎn)生什么影響呢？最終，我們必需抓住選擇機會一一我們應當采 納什么方法及工具？需要多少人員參與工作？對質(zhì)量的要求要到達 什

20、么程度才是“足夠的”？Peter Drucker DRU75曾經(jīng)說過：“當沒有方法消退風險， 甚至連試圖降低該風險也存在疑問時，這些風險就是真正的風險了”。在我們能夠標識出軟件工程中的“真正風險”之前，識別出全部對管 理者及開發(fā)者而言均為明顯的風險是很重要的。對于風險管理，我們的策略是主動式的。主動策略早在技術(shù)工 作開頭之前就已經(jīng)啟動了。標識出潛在的風險，評估它們消失的概率 及產(chǎn)生的影響，且按重要性加以排序，然后，軟件工程組建立一個方 案來管理風險。主要的目標是預防風險，但由于不是全部的風險都能 夠預防，所以，工程組必需建立一個意外大事的方案，使其在必要時 能夠以可控的及有效的方式作出反響。風

21、險識別與估量軟件風險雖然對于軟件風險的嚴格定義還存在許多爭議，但在風險中包 含了兩個特性這一點上是已達成了共識的HIG95： 不確定性一一 刻劃風險的大事可能發(fā)生也可能不發(fā)生；即，沒有100%發(fā)生的風險 （100%發(fā)生的風險是加在工程上的約束）。損失一一假如成了現(xiàn) 實，就會產(chǎn)生惡性后果或損失。進行風險分析時，重要的是量化不確 定性的程度及與每個風險相關的損失的程度。為了實現(xiàn)這點，必需考 慮不同類型的風險。工程風險威逼到工程方案。也就是說，假如項 目風險變成現(xiàn)實，有可能會拖延工程的進度，且增加工程的本錢。項 目風險是指潛在的預算、進度、人力（工作人員及組織）、資源、客 戶、及需求等方面的問題以及

22、它們對軟件工程的影響。工程簡單性、 規(guī)模、及結(jié)構(gòu)不確定性也被定義為工程（估算）風險因素。技術(shù)風 險威逼到要開發(fā)軟件的質(zhì)量及交付時間。假如技術(shù)風險變成現(xiàn)實，那么 開發(fā)工作可能變得很困難或根本不行能。技術(shù)風險是指潛在的設計、 實現(xiàn)、接口、驗證、和維護等方面的問題。此外，規(guī)約的二義性、技 術(shù)的不確定性、陳舊的技術(shù)、及“先進的”技術(shù)也是風險因素。技術(shù) 風險的發(fā)生是由于問題比我們所設想的更加難以解決。商業(yè)風險威 逼到要開發(fā)軟件的生存力量。商業(yè)風險常常會危害工程或產(chǎn)品。五個 主要的商業(yè)風險是：（1）開發(fā)了一個沒有人真正需要的優(yōu)秀產(chǎn)品或系 統(tǒng)（市場風險）；（2）開發(fā)的產(chǎn)品不再符合公司的整體商業(yè)策略（策 略風

23、險）；（3）建筑了一個銷售部門不知道如何去賣的產(chǎn)品；（4）由 于重點的轉(zhuǎn)移或人員的變動而失去了高級管理層的支持（管理風險）;（5）沒有得到預算或人力上的保證（預算風險）。應當留意到的很重 要的一點是：簡潔的分類并不總是行得通。某些風險根本無法事先猜 測。另一種常用的分類方式是由Charette CHA89提出的。 風險是通過認真評估工程方案、開發(fā)工程的商業(yè)及技術(shù)環(huán)境、以及其 他牢靠的信息來源（如，不現(xiàn)實的交付時間，沒有需求或軟件范圍的 文檔、惡劣的開發(fā)環(huán)境）之后可以覺察的那些風險?？刹孪腼L險能夠 從過去工程的閱歷中推斷出來（如，人員調(diào)整、與客戶之間無法溝通、 由于需要進行維護而使開發(fā)人員精力分

24、散）。不行猜想風險就象紙牌 中的大王，它們可能、也會真的消失，但很難事先識別出它們來。識別風險識別風險是試圖系統(tǒng)化地確定對工程方案（估算、進度、資源 安排）的威逼。通過識別的和可猜想的風險，工程管理者 已經(jīng)邁出了第一步一一在可能時避開這些風險，且當必要時掌 握這些風險。每一類風險又分為兩個不同的類型：一般性風險和特定 產(chǎn)品的風險。一般性風險對每一個軟件工程而言都是一個潛在 的威逼。特定產(chǎn)品的風險只有那些對當前工程的技術(shù)、人員、 及環(huán)境特別了解的人才能識別出來。為了識別特定產(chǎn)品的風 險，必需檢查工程方案及軟件范圍說明，并給出以下問題的答 案：“本工程中有什么特別的特性可能會威逼到我們的工程方 案？ ”一般性風險和特定產(chǎn)品的風險都應當被系統(tǒng)化地標識出 來。Tom Gilb GIL88很貼切地表達了這點：“假如你不主動 攻擊風險，風險就會主動攻擊你二識別風險的一個方法是建立風險條目檢查表。該檢查表可以用 于識別風險，并使得人們集中來識別以下常見子類型中的 的及可猜想的風險：產(chǎn)品規(guī)模一一與要建筑或要修改的軟件的總體規(guī)模相關的風 險。商業(yè)影響一一與管理或市場所加諸的約束相關的風險?？蛻籼匦砸灰慌c客戶的素養(yǎng)以及開發(fā)者和客戶定期通信的力量相關的風險。過程定義一一與軟件過程被定義的程度以及它們被開