軟體項目風險有哪些

1. 軟體項目管理及風險分析

關於軟體項目管理及風險分析

摘要： 軟體項H的有效管理，對項目的成敗具有至關重要的作用。軟體項目的風險體現存些方血，如何迴避這些風險，存本文中進行了探討，最後指出建立合理的管理流程，對軟體項目的管理來說，是非常重要的。

關鍵詞： 軟體項目：管流程;風險分析

軟體項目管理的提出是在2O世紀70年代中期的美國，當時美國國防部專研究了軟體開發不能按時提交，預算超支和質量達到用戶要求的原因，結果發現70%的項目是因為管理不善引起的，而非技術原因。於是軟體開發者開始逐漸重視起軟體開發中的各項管理。到了20世紀90年代中期，軟體研發項日管理不善的問題仍然存在。據美國軟體工程實施現狀的調查，軟體研發的情況仍然很難預測，大約只有10%的項目能夠在預定的費用和進度下交付。

究竟怎麼樣才能做好軟體項目的管理及風險分析，保證項目順利實施呢?這是個比較復雜的問題，下面就軟體項目的特點，縮合大家的經驗總結，談一點看法。

1、軟體項目管理風險分析

軟體項目管是為了使軟體項目能夠按照預定的成本、進度、質量順利完成，而對人員、產品、過程和項目進行分析和管理的活動。目的是為了讓軟體項目尤其是大型項目的整個軟體生命周期(從分析、設計、編碼、測試、到維護全過程)都能在管理者的控制之下，以預定成本按期，按質的完成軟體交付用戶使用。

怎樣進行有效的項目管理呢?首先我們來分析下影響軟體項目的質量因素。

軟體項目，尤其是大型項目有二項非常重要的因素，會影響整個項目的進度與質量，它們分別是：“人”、“流程” 與“技術”。

“人”是項目中最難預料與掌控的一項要素，人可分成兩部份，一是客戶，二是開發團隊。

“技術”是指軟體項目所使用的開發半台，主要指開發環境及開發語言。是最容易掌握的部份。

“流程”是指軟體開發流程或是項目流程，定義流程的目的是要掌控所有的情況。項目的最大敵人是時間及預算，這兩者都是有限的，如何在有限預算內准時完成項目，可說是一項藝術。

1.1“人”因素分析

“人”是指客戶和開發團隊，其中開發團隊的因素對項目影響很大，對於這方面影響因素主要分析如下：

人員技能未達到要求

在項目開始之初，我們假設項目成員都能夠達到組織級的要求，但往往並不是每個成員都能夠達到要求。而且項目中每個成員的生產率差異可能很大，也給項目進度安排造成影響。所以在項目始之初，應該對項目成員的技能進行一次總體的評估，對於大家都欠缺的技能，應該安排統一的培訓，後續需要對培訓的效果進行跟蹤;對於個別人員技能欠缺的，應該單獨預留自我學習時間或通過以師帶徒的方式進行培養，使其技能能夠盡快達到要求：對於項目新員的工作和任務，應該加強評審和檢查，保證輸出不出現大的偏差而導致後續大量的返工。對於這方影響因素主要分析如下：

項目成員責任心不強

態度決定一切，細節決定成敗。對於項目過程中的各項任務，經常出現由於項目成員責任心不強敷衍了事，導致產出的工件質量較差，引起大量返工的情況。在這種情況下，項目更應該加強項目規范的建設，項目經理應加強同這些成員的單獨溝通，加強項目的團隊建設和集體榮譽感。讓項目成員感覺到做的系統是他們自己的產品，而不是公司的項目，項目經理的項目。

項目溝通問題

在軟體項目中，保證項目各種角色和成員中的高效溝通是很重要的，如何建立起快捷順暢的溝通渠道，採用最佳的溝通方式來解決問題，必須在項目中經常強調。如果一周的項目任務花存實際做事情上有2天，而花在溝通上卻佔用了3天，這時必須及時分析和總結原因。溝通最重要的`就是要在最短的時間裡面，採用各種方法或工具，使交流雙方或多方達成一致。

項目人員流失

項目人員特別是項目關鍵成員在項目進行過程中的流失，對項目影響很大，對於這種情況，應該在項目開始之初，就作為專門的風險進行跟蹤，並考慮具體的應對措施。

1.2“流程”因素分析

軟體的開發流程般定義為：

需求分析一可行性分析一概要設計一結構化設計一詳細設計一編碼一軟體測試一軟體維護。

“流程”中軟體項目的風險，主要體現存4個階段：軟體需求階段、軟體設計階段、軟體實現階段和軟體維護階段

軟體需求階段

軟體的開發是以用戶的需求開始，在大多數情況下，用戶需求要靠軟體開發方誘導，才能保證需求的完整，再以的形式形成《用戶需求》這一重要的文檔。需求分析更多的是開發方確認需求的可行性和一致性的過程，在此階段需要和用戶進行廣泛的交流和確認。需求和需求分析的任何疏漏造成的損失，會在軟體系統的後續階段被一級級地放大，因此本階段的風險最大。

軟體設計階段

設計的主要目的在於軟體功能正確地反映了需求，需求的不完整和對需求分析的不完整或者錯誤，在設計階段將被成倍地放大。設計階段的主要任務是完成系統體系結構的定義，使之能夠完成需求階段的即定目標;另一方面也是檢驗需求的致性和需求分析的完整性和正確性。

設計階段的風險主要來自於系統分析人員。分析人員存設計系統結構時過於定製，系統的可擴展性較弱，會給後期維護帶來巨大的負擔和維護成本的激增。對用戶來說系統的使用比例會有明顯的折扣，甚至會造成軟體壽命過短。反之，軟體結構的過於靈活和通用，必然引起軟體實現的難度增加，系統的復雜度上升，可靠性降低，給實現和測試階段帶來風險，系統的穩定性也會受到影響。從另一個角度上看，用戶需求和將來軟體運行環境的變化都是必然的，目前軟體設計的所渭的“通用性”是否就能很好的適應將來需求和運行環境的變化，都是需要認真折衷的，而這種折中也蘊涵著很大的風險。

設計階段蘊涵的另一種風險來自於設計文檔。文檔的不健全不僅會造成實現階段的困難，更會在後期的測試和維護造成災難性的後果，例如根本無法對軟體系統進行版本級，甚至是發現的簡單錯誤都無從更正。

2. 軟體項目管理中項目風險的三要素包括

項目風險的三要素包括風險事件的存在、風險事件發生的概率、風險事件可能帶來損失,風險發生的概率越高,造成的影響越大,就越是高風險﹐否則就是中等風險或低風險。風險因素是指能夠引起風險事件發生或影響損失程度的因素,這是造成損失的直接原因。風險因素應包括所有已識別的條目,而不論頻率、發生的可能性、盈利或損失的數量等。在軟體項目中,一般風險因素包括:需求的變化;設計錯誤、疏漏和理解錯誤;狹義定義或理解角色和責任;不充分估計的工作量和不勝任的技術人員、供應商因素、硬體/軟體因素、環境因素等。例如在工程中負責人員起草錯誤的招標文件、合同條件,下達錯誤的指令,這是由項目的行為主體(如項目管理者)產生的風險。對風險因素的描述應包括由一個因素產生的風險事件發生的可能性、可能的結果范圍、預期發生的時間、一個風險因素所產生的風險事件的發生頻率。

3. 軟體項目風險管理控制措施

摘要 ：軟體項目開發需要投入大量的人力、物力和財力，但在開發的過程中存在著諸多不確定性和可變性，因而有必要對軟體項目風險進行管理與控制。本文通過對軟體項目全程的風險識別、分析、應對及監測，在項目開發各階段積極做好風險防控工作，以達到降低項目風險、減少風險損失的目的。

關鍵詞 ：軟體項目開發；風險管理；風險防控

1引言

風險是指在某項活動開展的過程中，一些突發的、不確定的因素對活動參與者造成損害、對自然環境造成破壞的概率[1]。與其他工程項目一樣，軟體項目的開發也存在著各種各樣的風險，如項目資金透支、工期延長、系統不能滿足需求等。因而在軟體開發的過程中，做好風險管理將有助於降低開發風險，保證開發質量。

2軟體項目風險分類

2.1技術風險

軟體在分析、設計、測試及實施過程中，可能發生的潛在技術問題給軟體項目帶來的危害稱為技術風險，如採用了陳舊或尚不成熟的技術、系統文檔編制不規范等。

2.2管理風險

管理風險是指由於項目在預算、人員、進度、資源等方面缺乏計劃、控制與管理，從而對軟體項目產生的不良影響。

2.3商業風險

商業風險又稱為市場風險，包括開發出來的軟體產品不符合市場需求、對軟體產品定位不清從而缺乏市場競爭力、市場競品較多競爭激烈等。

2.4安全風險

安全風險主要包括自然風險、人為風險、外部環境風險，如盜版、病毒等。

3軟體項目風險管理步驟

3.1風險識別

風險識別階段需要識別出哪些風險會影響軟體項目的開發，包括這些風險的類別、因素、出處、後果等內容[2]。風險識別的常用方法包括以下幾種。

（1）專家調查法。就軟體項目開發風險問題，征詢項目相關行業領域專家的意見，將收集到的意見和建議整理形成報告，隨後將報告發送給各位專家再次進行征詢。如此反復，經歷數輪後，當專家們的意見趨於一致時就可以得出最後結論。

（2）頭腦風暴法。將項目開發小組成員、立項單位代表、邀請的專家顧問召集起來，通過會議的方式，就項目開發風險展開討論交流，以期對項目風險進行准確識別、分析和預測。

（3）風險檢測表法。設計並使用各類條目式風險檢測表，幫助項目小組識別各種風險。如開發人員風險檢測表，可以羅列出諸如開發人員技術水平如何、開發人員是否具有類似項目開發經驗、開發人員的人數是否合適、開發人員是否能夠自始至終地參加軟體開發工作、開發人員是否能集中全部精力投入軟體開發工作、開發人員是否接受過必要的培訓、開發人員的人員流動是否能保證工作的連續性等條目。通過對這些問題的分析與回答，可以識別出人員因素對軟體項目帶來的風險。

3.2風險分析

風險分析主要是針對風險事件發生概率及其後果進行評估[3]。為完成對各種風險的評估，需建立風險度量指標體系，明確各種風險帶來的後果與損失，估算風險對軟體項目的影響程度，最終給出風險估算的結果[4]。風險分析時，常使用四元組[R,P,I,W]來對風險進行描述。其中R代表風險，P代表風險發生的概率，I代表風險帶來的影響，W代表風險對項目影響的權重。由於能否按照合同規定的軟體性能、時間和金額等條款完成軟體開發工作，對項目的順利驗收起著至關重要的作用。因而重點選取成本、進度、軟體性能三個方面對軟體項目風險進行度量，當某一方面的度量值達到或超過臨界點時，軟體項目將被迫終止。

通常風險評估的過程可分為四步：

（1）根據風險識別的結果，分析每種風險的發生概率，每種風險對項目成本、進度、軟體性能三方面影響的大小，依據風險後果的嚴重程度為每種風險賦予不同的風險權重。

（2）定義每種風險的四元組[R,P,I,W]。

（3）定義項目被迫終止的臨界點。

（4）預測風險組合對項目的綜合影響[5]。

3.3風險應對

對可能發生的各種風險需擬定相應的應對策略。常用的應對策略有預防風險、風險轉移、風險迴避等。預防風險通常指通過提高軟體項目各階段的可靠性和規范性，從而降低風險發生的概率。風險轉移是指利用合同、保險、擔保、出售、發包等方式[6]，將風險發生時的部分損失轉移至第三方，以降低己方風險損失。風險迴避是指當某些風險的發生不可避免且後果較嚴重時，可對項目方案進行調整，更甚者則主動放棄該項目，以免造成不可挽回的損失。在完成風險識別、分析和應對策略選擇後，應形成一個易於理解的風險分析與應對表，如表1所示。

3.4風險監控

風險監控是指依據前期風險分析結果，監控風險應對措施的實施情況，加強對項目全過程風險的管控[7]。風險監控的目的是監測風險管理策略和應對措施的實際執行效果，看其是否達到預期目標，同時根據當前風險監控結果及時修正風險分析與應對表，或對項目中新識別的風險進行分析並制定相應的風險應對措施[8]。

4風險防控措施

4.1需求分析階段

軟體需求是軟體開發的依據，也是軟體驗收的標准，因此對軟體需求的精準確定就屬於軟體項目開發的重點和難點。一方面用戶開始時很難完整且清楚地對軟體系統的功能、性能、運行環境等方面的需求進行准確表達。但隨著項目的深入，用戶對軟體的需求可能會越來越明確，也越來越多，甚至有時到測試階段還會出現有用戶要求更改軟體需求的情況。這對系統分析人員和軟體開發人員來說是難以接受的。另一方面，用戶、系統分析人員和軟體開發人員對軟體需求描述的方式也各不相同。用戶希望使用自然語言對軟體需求進行描述，而專業人員則希望採用結構化的說明語言，如數據流圖、數據字典等。這樣既可以避免自然語言容易引起的二義性和不確定性，又能為下一步軟體設計工作提供便利。

針對這類情況的防控措施包括：

（1）加強對立項單位的組織結構、工作流程和現有軟體系統的了解。

（2）系統分析人員需掌握一些獲取用戶需求的技術和方式。

（3）可將公司已投入使用的類似軟體作為軟體原型，提交給用戶使用，便於系統分析人員對用戶需求的收集。

（4）組織由立項單位、系統分析人員和系統設計人員共同參與的需求評審會，最終形成達成一致的需求分析階段的結果——需求規格說明書。

（5）對需求分析階段完成後用戶提出的新需求，可採取留在以後版本升級中處理，如立項單位要求必須加入的，則可與客戶商量延長開發時間、增加合同金額。

4.2設計與開發階段

如果軟體產品採用原型法進行開發，雖能降低因需求不明確帶來的項目風險，但由於原型法採用循環迭代的方式來不斷滿足用戶需求，這樣可能會導致軟體的設計與開發超出預期的花費和時間，並且在反復修改的過程中，容易使客戶對項目是否能夠順利完成產生疑慮。針對這類風險，一方面可將生命周期法與原型法結合在一起，互為補充，軟體開發中以結構化生命周期法為主要方法，在部分環節則利用原型法來快速獲取用戶反饋信息[9]。另一方面做好與客戶的溝通，及時告知客戶軟體設計與實現的進度與過程[10]。

4.3測試階段

測試階段常面臨的風險為測試用例不完善。這樣可能導致測試不夠全面，軟體中存在的錯誤未能發現，使得軟體性能降低。可採取的防控措施包括：

（1）對測試人員進行軟體需求的培訓。

（2）加強對測試用例的評審。

（3）在條件允許的情況下，可以邀請用戶參與軟體測試。

4.4實施階段實施階段可能會面臨客戶過於依賴技術人員，遲遲不肯驗收項目的風險。採取的防控措施包括：

（1）形成規范的《用戶手冊》，加強對軟體用戶的培訓。

（2）做好領導層的工作。

（3）宣講公司後期的服務范圍和服務管理的規范性。新舊系統切換的過程中也存在一定的風險。如果轉換工作缺乏規范的管理和可靠的安全保障，勢必會造成嚴重的後果，甚至影響正常工作。面對這種情況，一是需要特別注意原系統和新系統的文件保護工作，加強人員的管理和數據的備份；二是根據用戶要求、立項單位狀況、轉換過程中的進展情況調整系統切換進程。

5結束語

軟體開發過程中存在著各式風險，對每種風險都需要實施風險管理。由此可見，風險管理本身也可構成軟體項目中的一個子項目。科學地制定軟體項目風險管理計劃，在必要的人力資源和經費的支持下，持續完成風險識別、分析、應對和監控等風險管理步驟[11]，做好項目開發各階段的風險防控工作，從而達到將風險控制在最低限度，減少風險對軟體項目的影響，更好地控制軟體開發成本和進度的目的。

參考文獻

[1]楊一平,盧山.管理信息系統.北京:機械工業出版社,2018

[2]索紅軍.軟體項目風險分析與研究.軟體導刊,2017,16(08):128-131

[3]顧單.S公司戰略型物料采購策略研究[碩士學位論文].上海交通大學,上海,2015

[4]網路文庫.軟體項目的風險分析.

[5]韓最蛟.軟體工程基礎.北京:清華大學出版社,2009

[6]王慧.公路工程施工階段成本風險管理與分析控制.建材與裝飾,2019(24):259-260

[7]梅旭東.M公司卡拉奇核電站項目風險管理研究[碩士學位論文].東華大學,上海,2018

[8]劉強管理.基於國際工程項目全生命周期的風險管理.土木工程與管理學報,2017,34(06):1-9+16

[9]苑隆寅.圖書館在城鄉統籌發展中的作用與知識服務研究[碩士學位論文].重慶大學,重慶大學,2012

[10]馬興鵬.高校綜合分析平台項目的系統分析與設計[碩士學位論文].東北大學,遼寧,2011

[11]詹紅艷.軟體項目管理中風險控制策略研究.軟體,2019,40(06):230-232

作者：楊輝 單位：湖北交通職業技術學院交通信息學院

4. 打車軟體開發過程中存在的十大風險有哪些

項目風險、技術風險和商業風險。
1、市場需求被縮減，市場競爭明朗化，品牌優勢同質化，打車軟體的盈利模式上尚不清晰，質量風險。
2、打車軟體企業限制每天的補貼單數，但依然有大量套取補貼的司機存在，潛在的維護、驗證、介面、實現以及設計等環節出現的問題，存在技術空白及未知領域，為軟體開發工作帶來較大的風險。
3、來自於外包項目組、客戶、國家政策以及市場等方面的變化及壓力，這類風險具有明顯的不可控特點，一旦遭遇，應謹慎對待，及時制定解決策略，打車軟體競爭給市場造成一定的混亂，並可能引發法律風險。

5. 軟體項目風險管理的存在風險

識別風險是系統化地識別已知的和可預測的風險，在可能時避免這些風險，且當必要時控制這些風險。根據風險內容，我們可以將風險分為：
(1)產品規模風險：與軟體的總體規模相關的風險。
(2)商業影響風險：商業風險影響到軟體開發的生存能力。商業風險包含的五個主要的風險是：
l 市場風險：開發了一個沒有人真正需要的優秀產品或系統；
l 策略風險：開發的產品不符合公司的整體商業策略；
l 銷售風險：開發了一個銷售部門不知道如何去賣的產品；
l 管理風險：由於重點的轉移或人員的變動而失去了高級管理層的支持的風險；
l預算風險：沒有得到預算或人力上的保證。
(3)客戶特性風險：與客戶的素質以及開發者和客戶溝通能力相關的風險。
(4)過程定義風險：與軟體過程定義相關的風險。
(5)開發環境風險：與開發工具的可用性及質量相關的風險。
(6)技術風險：技術風險是指在設計、實現、介面、驗證、維護、規約的二義性、技術的不確定性、陳舊的技術等方面存在的風險。技術風險威脅到軟體開發的質量及交付的時間，如果技術風險變成現實，則開發工作可能變得很困難或根本不可能。
(7)人員數目及經驗帶來的風險：與參與工作的軟體工程師的總體技術水平及項目經驗相關的風險。
在進行具體的軟體項目風險識別時，可以根據實際情況對風險分類。但簡單的分類並不是總行的通的，某些風險根本無法預測。在這里，我們介紹一下美國空軍軟體項目風險管理手冊中指出的如何識別軟體風險。這種識別方法要求項目管理者根據項目實際情況標識影響軟體風險因素的風險驅動因子，這些因素包括以下幾個方面。
(1)性能風險：產品能夠滿足需求和符合使用目的的不確定程度。
(2)成本風險：項目預算能夠被維持的不確定的程度。
(3)支持風險：軟體易於糾錯、適應及增強的不確定的程度。
(4)進度風險：項目進度能夠被維持且產品能按時交付的不確定的程度。
每一個風險驅動因子對風險因素的影響均可分為四個影響類別——可忽略的、輕微的、嚴重的及災難性的。 在進行了風險辨識後，我們就要進行風險估算，風險估算從以下幾個方面評估風險清單中的每一個風險：
(1)建立一個尺度，以反映風險發生的可能性；
(2)描述風險的後果；
(3)估算風險對項目及產品的影響；
(4)標注風險預測的整體精確度，以免產生誤解。
對辨識出的風險進行進一步的確認後分析風險，即假設某一風險出現後，分析是否有其他風險出現，或是假設這一風險不出現，分析它將會產生什麼情況，然後確定主要風險出現最壞情況後，如何將此風險的影響降低到最小，同時確定主要風險出現的個數及時間。進行風險分析時，最重要的是量化不確定性的程度和每個風險可能造成損失的程度。為了實現這點，必須考慮風險的不同類型。識別風險的一個方法是建立風險清單，清單上列舉出在任何時候可能碰到的風險最重要的是要對清單的內容隨時進行維護，更新風險清單，並向所有的成員公開，應鼓勵項目團隊的每個成員勇於發現問題並提出警告。建立風險清單的一個辦法是將風險輸入缺陷追蹤系統中，建立風險追蹤工具，缺失追蹤系統一般能將風險項目標示為已解決或尚待處理狀態，也能指定解決問題的項目團隊成員，並安排處理順序。風險清單給項目管理提供了一種簡單的風險預測技術，下表事一個風險清單的例子：
風險 類別 概率 影響
資金將會流失商業風險40% 1
技術達不到預期效果技術風險30% 1
人員流動頻繁 人員風險 60% 3
在風險清單中，風險的概率值可以由項目組成員個別估算，然後加權平均，得到一個有代表性的值。也可以通過先做個別估算而後求出一個有代表性的值來完成。對風險產生的影響可以對影響評估的因素進行分析。
一旦完成了風險清單的內容，就要根據概率進行排序，高發生率、高影響的風險放在上方，依次類推。項目管理者對排序進行研究，並劃分重要和次重要的風險，對次重要的風險再進行一次評估並排序。對重要的風險要進行管理。從管理的角度來考慮，風險的影響及概率是起著不同作用的，一個具有高影響且發生概率很低的風險因素不應該花太多的管理時間，而高影響且發生率從中到高的風險以及低影響且高概率的風險，應該首先列入管理考慮之中。
在這里，我們需要強調的是如何評估風險的影響，如果風險真的發生了，它所產生的後果會對三個因素產生影響：風險的性質、范圍及時間。風險的性質是指當風險發生時可能產生的問題。風險的范圍是指風險的嚴重性及其整體分布情況。風險的時間是指主要考慮何時能夠感到風險及持續多長時間。可以利用風險清單進行分析，並在項目進展過程中迭代使用。項目組應該定期復查風險清單，評估每一個風險，以確定新的情況是否引起風險的概率及影響發生改變。這個活動可能會添加新的風險，刪除一些不再有影響的風險，並改變風險的相對位置。 在風險評估過程中，我們可以採取以下的步驟：
(1)定義項目的風險參考水平值。要使風險評估發生作用，就要定義一個風險參考水平值，對於大多數項目而言，通過對性能、成本、支持及進度等因素的分析，可以找出風險的參考水平值，對於性能下降、成本超支、支持困難或進度延遲（或者這四種的組合）等情況，超過這一參考水平值項目就會被終止。
(2)建立每一組（風險、風險發生的概率、風險產生的影響）與每一個參考水平值的關系。
(3)預測一組臨界點以定義項目終止區域，該區域由一條曲線或不確定區域界定。
(4)預測什麼樣的風險組合會影響參考水平值。 風險駕馭包括對策指定、風險緩解、風險監控、風險跟蹤等內容。
所有風險分析活動都只有一個目的——輔助項目組建立處理風險的策略。如果軟體項目組對於風險採取主動的方法，則避免永遠是最好的策略。這可以通過建立一個風險緩解計劃來達到即制定對策。
對不同的風險項要建立不同的風險駕馭和監控的策略比。如對於開發人員離職的風險項目開始時應作好人員流動的准備採取一些措施確保人員一旦離開時項目仍能繼續；制定文檔標准並建立一種機制保證文檔及時產生；對每個關鍵性技術崗位要培養後備人員。對於技術風險，可以採用的策略有，對採用的關鍵技術進行分析，避免軟體在生命周期中很快落後；在項目開發過程中保持對風險因素相關信息的收集工作，減少對合作公司的依賴尤其是對延續性強的項目應該盡可能地吸收合作公司的技術並變為自己的技術，避免因為可能發生的與合作公司合作的終止帶來的影響和風險降低投入成本。
一個有效的策略必須考慮風險避免、風險監控和風險管理及意外事件計劃這樣三個問題。風險的策略管理可以包含在軟體項目計劃中，或者風險管理步驟也可以組成一個獨立的風險緩解、監控和管理計劃（RMMM計劃）。RMMM計劃將所有風險分析工作文檔化，並且由項目管理者作為整個項目計劃的一部分來使用，RMMM計劃的大綱主要包括：主要風險，風險管理者，項目風險清單，風險緩解的一般策略、特定步驟，監控的因素和方法，意外事件和特殊考慮的風險管理等。一旦建立了RMMM計劃，我們就開始了風險緩解及監控，風險緩解是一種避免問題的活動，風險監控則是跟蹤項目的活動。它有三個主要目的：評估一個被預測的風險是否真的發生了；保證為風險而定義的緩解步驟被正確地實施；收集能夠用於未來的風險分析信息。
軟體開發是高風險的活動。如果項目採取積極風險管理的方式，就可以避免或降低許多風險，而這些風險如果沒有處理好，就可能使項目陷入癱瘓中。因此在軟體項目管理中還要進行風險跟蹤。對辨識後的風險在系統開發過程中進行跟蹤管理，確定還會有哪些變化，以便及時修正計劃。具體內容包括：
(1)實施對重要風險的跟蹤；
(2)每月對風險進行一次跟蹤；
(3)風險跟蹤應與項目管理中的整體跟蹤管理相一致；
(4)風險項目應隨著時間的不同而相應地變化。
通過風險跟蹤，進一步對風險進行管理，從而保證項目計劃的如期完成。

6. 軟體開發過程中會有哪些風險

1、未經權威部門確認的功能標准、開發規范以及質量技術標准，均可能導致軟體無法達到預期標准，從而引起質量風險。

2、在理解項目標准及范圍等問題上，企業管理層、項目組以及技術性人員的接不一致，導致計劃與資金安排有所改變，因而極易引發風險。

3、潛在的維護、驗證、介面、實現以及設計等環節出現的問題，存在技術空白及未知領域，為軟體開發工作帶來較大的風險。

4、來自於外包項目組、客戶、國家政策以及市場等方面的變化及壓力，這類風險具有明顯的不可控特點，一旦遭遇，應謹慎對待，及時制定解決策略。

風險防範與控制措施

1、出台合理的軟體開發模式與相關規程，確保開發工作合理、有序進行，並符合國家出台的相關標准及要求。

2、對於項目組全體成員的開發行為進行嚴格規范，加強小組成員之間的交流與互動，以免由於溝通與交流不當，引發軟體開發風險。

3、定期開展業務和技術交流大會，引導技術人員摒除過於落後、陳舊的工作思想，通過引進先進的技術、設備與驗證方式，明確技術人員的預期發展目標，令其不斷的改進自我、完善自我，提升技術及設備的質量及效果。

4、對開發所用的方法及技術進行客觀、合理的評價，避免由於無法把握技術而引發風險。

5、建立完善的風險應對程序與管理計劃，如此一來，才能確保在發生風險的時候，能夠快速、合理、技術的作出反映，並通過制定適宜的策略，對風險進行專業性處理。

7. 軟體項目風險有哪些

問題一：軟體項目風險 在項目的建設過程中，風險幾乎無處不在（約定：本文談到的風險，專指給項目帶來不利影響的風險）。如何有效地識別、控制和管理風險，對項目的成功起著至關重要的影響。
一個項目有可以預料的（包括已知的）風險和不可預料的風險，以下作者總結自己多年的軟體項目工程經驗，整理出軟體項目經常遇到的15種可預料的（包括已知的）風險及其預防措施，期望能為項目經理制定項目風險計劃和進行風險預防、控制等提供富有價值的參考。
（1）合同風險
簽訂的合同不科學、不嚴謹，項目邊界和各方面責任界定不清等是影響項目成敗的重大因素之一。
預防這種風險的辦法是項目建設之初項目經理就需要全面准確地了解合同各條款的內容、盡早和合同各方就模糊或不明確的條款簽訂補充協議。
（2）需求變更風險
需求變更是軟體項目經常發生的事情。一個看似很有「錢途」的軟體項目，往往由於無限度的需求變更而讓項目承建方苦不堪言，甚至最終虧損（實際上項目建設方也面臨巨大的風險）。
預防這種風險的辦法是項目建設之初就和用戶書面約定好需求變更控制流程、記錄並歸檔用戶的需求變更申請。
（3）溝通不良風險
項目組與項目各干係方溝通不良是影響項目順利進展的一個非常重要的因素。
預防這種風險的辦法是項目建設之初就和項目各干係方約定好溝通的渠道和方式、項目建設過程中多和項目各干係方交流和溝通、注意培養和鍛煉自身的溝通技巧。
（4）缺乏領導支持風險
上層領導的支持是項目獲得資源（包括人力資源、財力資源和物料資源等）的有效保障，也是項目遇到困難時項目組最強有力的「後台支撐」。
預防這種風險的辦法是主動爭取領導對項目的重視、確保和領導的溝通渠道暢通、經常向領導匯報工作進展。
（5）進度風險
有些項目對進度要求非常苛刻（進度要求不高的項目，我們同樣要考慮該風險），項目進度的延遲意味著違約或市場機會的錯失。
預防這種風險的辦法一般是分階段交付產品、增加項目監控的頻度和力度、多運用可行的辦法保證工作質量避免返工。
（6）質量風險
有些項目，用戶對軟體質量有很高的要求，如果項目組成員同類型項目的開發經驗不足，則需要密切關注項目的質量風險。
預防這種風險的辦法一般是經常和用戶交流工作成果、品牌管理採用符合要求的開發流程、認真組織對產出物的檢查和評審、計劃和組織嚴格的獨立測試等。
（7）系統性能風險
有些軟體項目屬於多用戶並發的應用系統，系統對性能要求很高，這時項目組就需要關注項目的性能風險。
預防這種風險的辦法一般是在進行項目開發之前先設計和搭建出系統的基礎架構並進行性能測試，確保架構符合性能指標後再進行後續工作。
（8）工具風險
軟體項目開發和實施過程，所必須用到的管理工具、開發工具、測試工具等是否能及時到位、到位的工具版本是否符合項目要求等，是項目組需要考慮的風險因素。
預防這種風險的辦法一般是在項目的啟動階段就落實好各項工具的來源或可能的替代工具，在這些工具需要使用之前（一般需要提前一個月左右）跟蹤並落實工具的到位事宜。
（9）技術風險
在軟體項目開發和建設的過程中，戰略管理技術因素是一個非常重要的因素。項目組一定要本著項目的實際要求，選用合適、成熟的技術，千萬不要無視項目的實際情況而選用一些雖然先進但並非項目所必須且自己又不熟悉的技術。如果項目所要求的技術項目成員不具備或掌握不夠，則需要重點關注該風險因素。
預防這種風險的辦法是選用項目所必須的技術、在技術應用之前，針對相關人員開展好技術培訓工作。
（10）團隊......>>

問題二：軟體開發過程中會有哪些風險？ 軟體項目成果的需求分析方和軟體項目的承擔者都十分關心這樣的一個問題：什麼樣的因素會導致軟體項目的失敗？與項目有關的因素的改變將對按時、按經費預算交付符合預定質量要求的軟體成果產生什麼樣的影響？這些都屬於軟體項目開發過程中考慮的風險問題。
軟體項目的風險是指在軟體開發過程中可能出現的不確定因而造成損失或者影響，如資金短缺、項目進度延誤、人員變更以及預算和進度等方面的問題。風險關注未來的事情，這意味著，軟體風險涉及選擇及選擇本身包含的不確定性，軟體開發過程及軟體產品都要面臨各種決策的選擇。風險是介於確定性和不確定性之間的狀態，是處於無知和完整知識之間的狀態。另一方面，風險將涉及思想、觀念、行為、地點等因素的改變。
軟體項目風險會影響項目計劃的實現，如果項目風險變成現實，就有可能影響項目的進度，增加項目的成本，甚至使軟體項目不能實現。因此有必要對軟體項目中的風險進行分析並採取相應的措施加以管理，盡可能減少風險造成的損失。風險是在項目開始之後才對項目的執行過程其負面的影響，所以軟體項目開始之前風險分析的不足，或者是軟體項目實施過程中風險應對措施不得力，都有可能造成軟體失敗。
如果對項目進行風險管理，就可以最大限度的減少風險的發生。它是為了將不確定因素出現的概率控制到最低，將不確定性所造成的損失減少到最低限度，對軟體項目全過程中的風險識別、分析和應對的過程。在整個軟體項目的實施過程中，可能形成項目風險的因素有很多，如在項目啟動階段可能存在項目目標不明確，與用戶溝通少導致項目范圍不明確等分先因素；在系統設計階段可能因為缺乏有經驗的分析人員、設計人員導致和設計的結果不能直接用於程序員的開發；在項目實施階段可能因為開發環境沒有準備好，程序員開發能力差，或者因為用戶提出新的功能需求導致原有設計實效、開發費用超支，還有可能因為開發人員的流動導致項目延期，客戶不滿意等情況。
軟體項目運用專家調查法和頭腦風暴法分析軟體開發項目中，並將其進行整理分類。
由於與客戶溝通不暢對客戶的需求了解不足造成的風險在軟體開發項目整個生命周期的中都存在的風險，主要包括需求變更風險，涉及風險，過程風險，安裝及維護風險。
由於管理人員素質不夠，經驗不足，溝通不暢，任務或其分配不合理，對項目的控制力度不夠造成的各種風險，主要包括進度風險，預算風險，管理能力風險，信息安全風險。
由於技術力量不足，開發環境工具不足造成的。主要包括技術風險，質量風險，軟體設計工具風險，軟體開發工具風險，員工技能風險。
由於公司或項目組內外部環境變化所導致的風險，主要包括人力資源風險，政策風險，市場風險，營銷風險。
軟體項目中的風險永遠不能全部消除，而只能採用避免、減輕、和接受三種因對策略。
避免：通過分析找出發生風險事件的原因，消除這些原因來避免一些特定風險事件的發生。
減輕：通過降低風險事件發生的概率或得失衡量來減輕風險對項目的影響，也可採用風險轉移的方法來減輕風險對項目的影響。
接受：對於一些無法避免的風險，應當接收風險造成的後果或者提前設計相應的應對措施，但這需要一定的資金做後盾。

問題三：軟體項目計劃的風險分析 風險分析對於軟體項目管理是決定性的，然而目前現在還是有很多項目不考慮風險就著手進行。

問題四：找第三方開發標准軟體產品的風險有哪些 軟體項目開發會遇到各種形式的風險，所以要避免分析就需要選擇正規的開發團隊，質量和功能就有保障了。
問題總結
計劃忽略了必要的任務和活動。
基於特定的項目組人員，而這樣的項目組人員得不到。
目標日期提前，但沒有相應地調整產品范圍和可用資源。
需求定義欠佳：不清晰、不準確、不一致。
前期的質量保證行為不真實，導致後期的重復工作。

問題五：找第三方開發標准軟體產品的風險有哪些 如果某個庫文件存在漏洞，那麼，大量使用了該庫文件的軟體程序都將面臨安全威脅。這種場景，在現實世界中已經有了血淋淋的證明：如OpenSSL中出現的心臟滴血漏洞（Heartbleed）、GNU Bash出現的破殼漏洞（Shellshock）和Java中的反序列化漏洞（Deserialization），這些都是實際應用程序中，存在第三方資源庫或應用框架漏洞的典型案例。
據Veracode的安全研究分析，97%的Java程序都至少存在1個已知的安全漏洞，高級研究主管Tim Jarrett說「出現這種問題的原因比較明確，而且不只局限於Java程序「。另外，據Gartner預測，到2020年，99%的可利用漏洞發現期限，將仍然是安全專業人士已知至少1年以上的，所以，建議企業必須盡快修復那些已知的存在漏洞。這些漏洞很容易被忽略，但與事後彌補相比，修復這些漏洞的代價更低，也更容易。

問題六：軟體項目風險如何做規避計劃 風險評價是識別並分析潛在風險區域的過程。可以通過列舉通常的軟體項目風險因素以使風險識別更加明析。製作風險評估表是識別風險的好辦法，在風險評估表中我們統計特定風險對項目可能造成的潛在後果，風險計劃的要素有： 風險描述 對於風險情況的介紹。 可能性風險發生的可能性。風險不是必然要發生的，如果一個對項目存在危害的事件是必然要發生的，那這個事件就不能作為風險。對於風險可能性的標識有助於對那些高可能性的風險投入更大的關注。 嚴重性風險如果發生對於項目的危害程度。 危害值一個綜合考慮可能性和嚴重型後對風險的一個評估，這個評估反應了風險應該被關注的程度。 對策對策分為兩個部分：一是對於採取預防措施以阻止風險的發生，另一方面也要考慮如果風險發生後需要採取什麼措施。這兩方面的計劃構成了完整的風險對策。 觸發標志風險是一種可能性，並且制定風險主要的出發點是預防它，但也要考慮到風險發生後情況。對於風險發生後的應對策略，需要爭取一定的提前時間以啟動必要的各項工作，設立觸發標志是為設立一個判別標識，在該觸發標志所標明的條件具備時，說明風險已經越來越可能成為現實了。 風險責任人風險預防和跟蹤需要有人的參與，在風險計劃中責任明確是一個重要的原則，對每一個列入了視線的風險都要指定對風險預防和跟蹤負責的人員。 風險計劃不是一個靜止的文件，它應該隨著項目狀況的變化而變化。所以在任何項目中，風險管理都必須被作為一個日常的正式活動列入項目工作計劃，成為項目管理人員的一個重要工作。在下一節風險跟蹤中將對風險的動態變化作出更詳細的闡述。 在標定風險可能性和危害時，重要的是清楚地標明風險之間重要性的相對比較，所以採取一個簡明的標注標准十分重要。

問題七：什麼是軟體開發風險分析，風險預測，風險評估 開發風險1技術風險，技術導致無法完成2工期風險，未及時交工3人員風險，人員變更4需求不一致，交付物有問題

問題八：軟體項目開發風險 C，既然用戶同意開發這個軟體，那麼這個軟體出了風險，那就和開發者無關，這是用戶同意的。

問題九：ERP軟體開發存在哪些風險 大哥，能問這種問題，還不給分。。。
那就簡單的說一下啊，首選，你得找個熟悉ERP的懂業務的軟體產品經理
然後你需要一些懂得基本財務的程序員
最後你還得開發一套流程引擎
風險管理在PMP里是獨立敘述的，但是在軟體開發里是糅合在過程里
為啥呢？因為你會發現，拋開BUG率不說，我們只對ERP開發來說，這無時無刻不涉及到業務流，財務流，數據流。
不是捏幾個程序員，拍下腦袋做出來的軟體就叫ERP的

8. 什麼軟體推廣過程可能有風險並對此設計風險應對措施

有以下幾點風險和措施：
1、邊界風險：在與需求方溝通時，項目邊界和各方面責任界定不清等是影響項目成敗的重大因素之一。
2、需求變更風險：需求變更是軟體項目經常發生的事情。
3、溝通不良風險：項目組與項目各干係方溝通不良是影響項目順利進展的一個非常重要的原因。