軟體專案管理之風險評估

2021-03-04 08:09:09 字數 2752 閱讀 5285

很多時候不知道大家有沒有發現,專案成為我們見面或茶餘飯後的談資,其中軟體專案開發尤為多,但由於種種原因,這個專案並不能如期的完成。那麼,如何在專案實施過程中進行有效地評估和預防這些風險呢,這就涉及到風險的評估。

專案管理教會我們如何在複雜多變的環境中做好一件事,風險評估是其中非常重要的一項。本文就軟體專案管理中的風險評估方面做詳細介紹。

風險評估

軟體專案風險是指在整個專案週期中所涉及的成本預算、開發進度、技術難度、經濟可行性、安全管理等各方面的問題,以及由這些問題而對專案所產生的影響。專案的風險與其可行性成反比,其可行性越高,風險越低。軟體專案的可行性分為經濟可行性、業務可行性、技術可行性、法律可行性等四個方面。

而軟體專案風險則分為產品規模風險、需要風險、相關性風險、管理風險、安全風險等六個方面:

1. 產品規模風險

專案的風險是與產品的規模成正比的,一般產品規模越大,問題就越突出。尤其是估算產品規模的方法,復用軟體的多少,需求變更的多少等因素與產品風險息息相關:

(1) 估算產品規模的方法

(2) 產品規模估算的信任度

(3) 產品規模與以前產品規模平均值的偏差

(4) 產品的使用者數

(5) 復用軟體的多少

(6) 產品需求變更的多少

2. 需求風險

很多專案在確定需求時都面臨著一些不確定性。當在專案早期容忍了這些不確定性,並且在專案進展過程當中得不到解決,這些問題就會對專案的成功造成很大威脅。如果不控制與需求相關的風險因素,那麼就很有可能產生錯誤的產品或者拙劣地建造預期的產品。

每一種情況對產品來講都可能致命的,這些的風險因素有:

(1) 對產品缺少清晰的認識

(2) 對產品需求缺少認同

(3) 在做需求分析過程中客戶參與不夠

(4) 沒有優先需求

(5) 由於不確定的需要導致新的市場

(6) 不斷變化需求

(7) 缺少有效的需求變化管理過程

(8) 對需求的變化缺少相關分析等

3. 相關性風險

許多風險都是因為專案的外部環境或因素的相關性產生的。控制外部的相關性風險, 能緩解策略應該包括可能性計畫,以便從第二資源或協同工作資源中取得必要的組成部分,並覺察潛在的問題,與外部環境相關的因素有:

(1) 客戶**條目或資訊

(2) 互動成員或互動團體依賴性

(3) 內部或外部轉包商的關係

(4) 經驗豐富人員的可得性

(5) 專案的復用性

4. 技術風險

軟體技術的飛速發展和經驗豐富員工的缺乏,意味著專案團隊可能會因為技巧的原因影響專案的成功。 在早期,識別風險從而採取合適的預防措施是解決風險領域問題的關鍵,比如:培訓、聘請顧問以及為專案團隊招聘合適的人才等。

關於技術主要有下面這些風險因素:

(1) 缺乏培訓

(2) 對方法、工具和技術理解的不夠

(3) 應用領域的經驗不足

(4) 對新的技術和開發方法應用不熟悉

5. 管理風險

儘管管理問題制約了很多專案的成功,但是不要因為風險管理計畫中沒有包括所有管理活動而感到驚奇。在大部分專案裡,專案經理經常是寫專案風險管理計畫的人,他們有先天性的不足——不能檢查到自己的錯誤。因而,使專案的成功變得更加困難。

如果不正視這些棘手的問題,它們就很有可能在專案進行的某個階段影響專案本身。當我們定義了專案追蹤過程並且明晰專案角色和責任,就能處理這些風險因素:

(1) 計畫和任務定義不夠充分

(2) 對實際專案狀態不了解

(3) 專案所有者和決策者分不清

(4) 不切實際的承諾

(5) 不能與員工之間的進行充分地溝通

6. 安全風險

軟體產品本身是屬於創造性的產品,產品本身的核心技術保密非常重要。但一直以來,我們在軟體這方面的安全意識比較淡薄,對軟體產品的開發主要注重技術本身,而忽略了專利的保護。軟體行業的技術人員流動是很普遍的現象,隨著技術人員的流失、變更,很能會導致產品和新技術的洩密,致使我們的軟體產品被它公司竊取,導致專案失敗。

而且在軟體方面關於智財權的認定目前還沒有明確的乙個行業規範,這也是我們軟體專案潛在的風險。

了解了軟體專案管理中的風險評估,相信大家更想了解的是如何規避這些風險吧。規避風險的方式有:

(1) 以開發方誘導能保證需求的完整,使需求與客戶的真實期望高度一致。再以書面方便形成《使用者需求》這一重要的文件,避免疏漏造成的損失在軟體系統的後續階段被逐步地放大。

(2) 設立監督制度,專案開發中任何較大的決定都必須有客戶參與進行的,在該專案中專案監督由專案開發中的質量監督組來實施。

(3) 需求變更需要經過統一的負責人提出,並且要使用者需求的審核領導認可,需求變更應該是定期而不是隨時的提出,而且開發方應該做好詳細的記錄,讓客戶了解需求變更的實際情況。

(4) 控制系統的複雜程度,過於簡單的系統結構,對使用者來使用比例會有明顯的折扣,甚至造成軟體壽命過短。反之,軟體結構的過於靈活和通用,必然引起軟體實現的難度增加,系統的複雜度會上公升,這又會在實現和測試階段帶來風險。適當控制系統的複雜程度有利於降低開發的風險。

(5) 從軟體工程的角度看,軟體維護費用約佔總費用的55%~70%,系統越大,該費用越高。對系統可維護性的輕視是大型軟體系統的最大風險。在軟體漫長的運營期內,業務規則肯定會不斷發展,科學的解決此問題的做法是不斷對軟體系統進行版本公升級,在確保可維護性的前提下逐步擴充套件系統。

(6) 設定應急計畫,每個開發計畫都至少應該設定乙個應急預案去應對出現突發情況和不可遇知的風險。

以上就是針對軟體專案管理中的風險評估做的相關介紹,從上文的介紹中也不難看出,系統的學習專案管理pmp認證也是非常有必要的,而且pmp對專案管理者來說,是含金量最高的證書,更是專案管理者的必要通行證!

風險評估之風險識別

風險管理工作的起點就是風險識別,即風險主體要弄清楚哪些經濟指標未來的不確定性可能需要加以管理,這些指標的不確定性是由什麼事由導致,這些事由的原因是什麼等等。風險識別為風險分析和風險評價提供物件和基礎,從而也為風險管理對策提供工作方向。第一節風險要素與風險分類 分類是識別的基礎。我們先簡單了解一下風險...

軟體專案風險管理模版

文件對軟體開發過程中遇到的預算 進度 開發不成功等發面的問題引起的損失的可能性進行管理,為降低軟體產生的風險提供相關的依據。識別軟體開發過程中的風險 分析軟體開發過程中的風險 緩解軟體開發過程中的風險 建立和維護用於風險管理的策略。規模風險 商業影響風險 客戶相關風險 過程風險 技術風險 開發環境風...

軟體開發專案的風險管理

作者 蘭燕子 1月27日參加了專案管理聯盟組織的 北京專案管理愛好者聚會 我被易風邀請做了乙個主題演講,其實不是什麼演講,只是結合理論談了自己的一些想法和工作中遇到過的經驗教訓,更主要的目的是給大家出乙個討論和交流的主題,希望能起個拋磚引玉的作用。我講的主題是 軟體開發專案的風險管理,因為我認為風險...