【文章內(nèi)容簡介】 識了與商業(yè)影響相關(guān)的常見風險：本產(chǎn)品對公司的收人有何影響？本產(chǎn)品是否得到公司高級管理層的重視9交付期限的合理性如何？將會使用本產(chǎn)品的用戶數(shù)及本產(chǎn)品是否與用戶的需要相符合？本產(chǎn)品必須能與之互操作的其他產(chǎn)品／系統(tǒng)的數(shù)目？最終用戶的水平如何？政府對本產(chǎn)品開發(fā)的約束是什么？延遲交付所造成的成本消耗是多少？產(chǎn)品缺陷所造成的成本消耗是多少？對于上述產(chǎn)品規(guī)模和商業(yè)影響的風險檢查表中的每一個回答都必須與過去∞經(jīng)驗加以比較。如果出現(xiàn)了較大的百分比偏差或者如果數(shù)字接近過去很不令人滿意的緒果，則風險較高。3）需求相關(guān)風險檢查表很多項目在確定需求時都面臨著一些不確定性和混亂。如果在項目早期容忍了這些不確定性，并且在項目進展過程中得不到解決，則這些問題就會對項目的成功造成很大威脅。如果不控制與需求相關(guān)的風險因素，那么就很有可能產(chǎn)生鍇誤的產(chǎn)品或者拙劣地建造正確的產(chǎn)品。每一種情況都會使人不愉怏。例如，需求中潛在的問題包括：對產(chǎn)品缺少清晰的認識。對產(chǎn)品需求缺少認同。在確定需求時客戶參與不夠。沒有優(yōu)先需求。不確定的需要。新的市場不斷變化需求。缺少有效的需求變化管理過程。對需求的變化缺少相關(guān)分析。如果對于這些問題中的任何一個問題的答案是肯定的，則需要進一步的研究，以評估潛在的風險。4）客戶相關(guān)風險檢查表不同的客戶有不同的需要。有些人只知道他們需要什么，而有些人知道他們不需要什么。一些客戶希望跡行詳細的討論，而另外的客戶則滿足子模糊的承諾。不同的客戶有不同的個性。亠些人喜歡享受客戶的身份，而另一些人則根本不喜歡作為客戶。一些人會高興地接受幾乎任何交付的產(chǎn)品饣并能充分利用一個不妤的產(chǎn)品；而另一些人則會對質(zhì)量差的產(chǎn)品猛烈抨擊。一些人會對質(zhì)量好的產(chǎn)品表示贊賞，而另一些人則不管怎樣都抱怨不休。客戶和供應商之間也有各種不同的通信方式。一些人非常熟悉產(chǎn)品及生產(chǎn)廠商！而另一些人則可能綦未謀面，僅僅通過信件來往和電話與生產(chǎn)廠商溝通。一個“不好的”客戶可能會對一個軟件項目組能否在預算內(nèi)完成項目產(chǎn)生很大的影響。對于項目管理者而言，“不好的”客戶是對項目計劃的巨大威脅和實際的風險。下面的風險襝查表中的條目標識了與客戶特征相關(guān)的常見風險：你以前是否曾與這個客戶合作過？該客戶是否很清楚薷要什么；他能否花時間把需求寫出來？該客戶是否同意花時間召開正式的需求收集會議，以確定項目范圍？該客戶是否愿意建立與開發(fā)者之間的快速通信渠道？該客戶是否愿意參加復審工作？該客戶是否具有該產(chǎn)品領(lǐng)域的技術(shù)奏養(yǎng)？該客戶是否愿意讓你的人來做他們的工作？該客戶是否了解軟件過程？如果對于這些問題中的任何一個問題的答案是否定的，則需要進一步的調(diào)研，以評估潛在的風險。5）過程風險檢查表如果軟件過程定義得不清楚，如果分析、設計、測試以無序的方式進行，如果質(zhì)量是每個人都認為很重要的概念但沒有人切實采取行動來保證它，那么這個項目就處在風險之中。過程問題包括：高級管理層是否有一份已經(jīng)寫好的政策陳述，該陳述中強調(diào)了軟件開發(fā)標準過程的重要性？開發(fā)組織是否已經(jīng)擬定了一份已經(jīng)成文的、用于本項目開發(fā)的軟件過程的說明？開發(fā)人員是否同意按照文檔所寫的軟件過程進行開發(fā)工作，并自愿使用它？該軟件過程是否可以用子其他項目？管理者和開發(fā)人員是否接受過一系列的軟件工程培訓？是否為每一個軟件開發(fā)者和管理者提供了印妤的軟件工程標準？是否為作為軟件過程一部分而定義的所有交付物建立了文檔概要及示例？是否定期對需求規(guī)約、設計和編碼進行正式的技術(shù)復審？是否定期對測試過程和測試情況進行復審，是否對每一次正式技術(shù)復審的結(jié)果建立了文襠，其中包括發(fā)現(xiàn)的錯誤及使用的資源？有什么機制來保證按照軟件工程標準來指導工作？是否使用配置管理來維護系統(tǒng)／軟件需求、設計、編碼、測試用例之間的一致性？是否使用一個機制來控制用戶需求的變化及其對軟件的影響？對子每一個承包出去的子合同，是否有一份文檔化的工作說明、一份軟件需求規(guī)約和一份軟件開發(fā)計劃？是否有一個可遵循的規(guī)程，來跟螓及復審子合同承包商的工作？技術(shù)問題包括：是否使用方便易用的規(guī)格說明技術(shù)來輔助客戶與開發(fā)者之間的通信？b是否使用特定的方法進行軟件分析？是否使用特定的方法進行數(shù)據(jù)和體系結(jié)構(gòu)的設計？是否90％以上的代碼都是使用高級語言編寫的？是否定義及使用特定的規(guī)則進行代碼編寫？是否使用特定的方法進行測試用例的設計？是否使用配置管理軟件工具控制和跟蹤軟件過程中的變化活動？是否使用工具來創(chuàng)造軟件原型？是否使用軟件工具來支持測試過程？是否使用軟件工具來支持文檔的生成和管理？是否收集所有軟件項目的質(zhì)量度量值？是否收集所有軟件項目的生產(chǎn)率度量值？如果對于上述問題的答案多數(shù)是否定的，則軟件過程是薄弱的且風險很高。6）技術(shù)風險檢查表采用新技術(shù)是具有挑戰(zhàn)性和令人興奮的，但這也是有風險的。下面的風險檢查表中的條目標識了與建造的技術(shù)相關(guān)的常見風險：該技術(shù)對于你的公司而言是新的嗎？客戶的需求是否需要創(chuàng)建新的算法？待開發(fā)的軟件是否需要使用新的或未經(jīng)證實的硬件接口？待開發(fā)的軟件是否需要與開發(fā)商提供的未經(jīng)證實的軟件產(chǎn)品接口？待開發(fā)的軟件是否需要與功能和性能均未在本領(lǐng)域得到證實的數(shù)據(jù)庫系統(tǒng)接口？產(chǎn)品的需求是否要求采用特定的用戶界面？產(chǎn)品的需求中是否要求開發(fā)某些程序構(gòu)件，這些構(gòu)件與你的公司以前開發(fā)的構(gòu)件完全不同？需求中是否要求采用新的分析、設計、測試方法？ ⒒需求中是否要求使用非傳統(tǒng)的軟件開發(fā)方法？需求中是否有過分的對產(chǎn)品的性能約束？客戶能確定所要求的功能是可行的嗎？如果對于這些問題中的任何一個問題的答案是肯定的，則需要進一步的調(diào)研，以評估潛在的風險。7）開發(fā)環(huán)境風險檢查表軟件工程環(huán)境支持項目組、過程及產(chǎn)品，但是，如果環(huán)境有缺陷，它就有可能成為重要的風險源。下面的風險檢查表中的條目標識了與開發(fā)環(huán)境相關(guān)的風險：是否有可用的軟件項目管理工具？是否有可用的軟件過程管理工具？是否有可用的分析及設計工具？分析和設計工具是否適用于待建造產(chǎn)品？是否有可用的編譯器或代碼生成器？是否有可用的測試工具？是否有可用的軟件配置管理工具？環(huán)境是否利用了數(shù)據(jù)庫或數(shù)據(jù)倉庫？項目組的成員是否接受過每個所使用工具的培訓陽是否有專家能夠回答有關(guān)工具的問題？工具的聯(lián)機幫助及文檔是否適當？如果對于上述問題的答案多數(shù)是否定的，則軟件開發(fā)環(huán)境是薄弱的且風險很高。8）人員數(shù)目及經(jīng)驗風險檢查表下面的風險檢查表中的條目標識了與人員數(shù)目及經(jīng)驗相關(guān)的常見風險：是否有最優(yōu)秀的人員可用？人員在技術(shù)上是否配套？是否有足夠的人員可用？開發(fā)人員是否能夠自始至終地參加整個項目的工作？項目中是否有一些人員只能部分時間工作？開發(fā)人員對自己的工作是否有正確的期望？開發(fā)人員是否接受過必要的培訓？開發(fā)人員的流動是否仍能保證工作的連續(xù)性？如果對于這些問題中的任何一個問題的答案是否定的，則需要進一步的調(diào)研，以評估潛在的風險。當然，檢查表的類別和條目可以根據(jù)企業(yè)或者項目的具體情況來選擇或者開發(fā)。例如，美國的軟件工程研究所（簡稱SEI）的一份研究報告對于軟件風險提出用Class、Elcment、Attributc三個層次描述風險列表（見圖10—5）。對于Class（類）層分三組，即ProductEnginccring、Dcvclopment Environmt和Program Constraints。每個Class組下包含若干Elemt（元素），每個Elemt組下又包含若干Attributc（屬性）