有關軟體工程的開發當中，注重開發技術的同時也需要看重其中的風險，今天對有關的風險做乙個小小的總結，也是因為有關**需要寫一篇這個東西。
工程類專案風險的管理：
2.風險的**：風險的**需要對開發專案中的可能發生的風險進行統計和計算，通過資料、概率、經驗去**可能會發生的風險及概率，及影響專案的程度。
3.風險的評估：對其風險進行評估導致的結果是什麼，為降底風險導致專案負面效應的乙個討論過程，風險應對的計畫依據風險管理計畫、風險排序、風險認知等依據，得出風險應對計畫、剩餘風險、次要風險以及為其它過程提供得依據。
4.風險的控制：整個專案開發過程中，管理層可以對其某些因素進行控制及通過評估的風險應對措施、管理方法、技術手段等對專案的風險進行有效管控，降底其風險導致的不良結果，妥善處理風險事件造成的不利後果，以最少的成本保證專案總體目標實現的管理工作。
關於各種軟體開發模式的風險管理的方法：
wwpmm(ibm全球專案管理方法):
軟體專案中的風險
軟體專案的風險無非體現在以下四個方面：需求、技術、成本和進度。iｔ專案開發中常見的風險有如下幾類：
（1）需求風險
1.需求已經成為專案基準，但需求還在繼續變化；
2.需求定義欠佳，而進一步的定義會擴充套件專案範疇；
3.產品定義含混的部分比預期需要更多的時間；
4.在做需求中客戶參與不夠；
5.缺少有效的需求變化管理過程。
（2）計畫編制風險
1.計畫、資源和產品定義全憑客戶或上層領導口頭指令，並且不完全一致；
2.計畫是優化的，是"最佳狀態"，但計畫不現實，只能算是"期望狀態"；
3.計畫基於使用特定的小組成員，而那個特定的小組成員其實指望不上；
4.產品規模(**行數、功能點、與前一產品規模的百分比)比估計的要大；
5.完成目標日期提前，但沒有相應地調整產品範圍或可用資源；
6.涉足不熟悉的產品領域，花費在設計和實現上的時間比預期的要多。
（3）組織和管理風險
1.僅由管理層或市場人員進行技術決策，導致計畫進度緩慢，計畫時間延長；
2.低效的專案組結構降低生產率；
3.管理層審查 決策的週期比預期的時間長；
4.預算削減，打亂專案計畫；
5.管理層作出了打擊專案組織積極性的決定；
6.缺乏必要的規範，導致工作失誤與重複工作；
7.非技術的第三方的工作(預算批准、裝置採購批准、法律方面的審查、安全保證等)時間比預期的延長。
（4）人員風險
1.作為先決條件的任務(如培訓及其他專案)不能按時完成；
2.開發人員和管理層之間關係不佳，導致決策緩慢，影響全域性；
3.缺乏激勵措施，士氣低下，降低了生產能力；
4.某些人員需要更多的時間適應還不熟悉的軟體工具和環境；
5.專案後期加入新的開發人員，需進行培訓並逐漸與現有成員溝通，從而使現有成員的工作效率降低；
6.由於專案組成員之間發生衝突，導致溝通不暢、設計欠佳、介面出現錯誤和額外的重複工作；
7.不適應工作的成員沒有調離專案組，影響了專案組其他成員的積極性；
8.沒有找到專案急需的具有特定技能的人。
（5）開發環境風險
1.設施未及時到位；
2.設施雖到位，但不配套，如沒有**、網線、辦公用品等；
3.設施擁擠、雜亂或者破損；
4.開發工具未及時到位；
5.開發工具不如期望的那樣有效，開發人員需要時間建立工作環境或者切換新的工具；
6.新的開發工具的學習期比預期的長，內容繁多。
（6）客戶風險
1.客戶對於最後交付的產品不滿意，要求重新設計和重做；
2.客戶的意見未被採納，造成產品最終無法滿足使用者要求，因而必須重做；
3.客戶對規劃、原型和規格的審核 決策週期比預期的要長；
4.客戶沒有或不能參與規劃、原型和規格階段的審核，導致需求不穩定和產品生產週期的變更；
5.客戶答覆的時間(如回答或澄清與需求相關問題的時間)比預期長；
6.客戶提供的元件質量欠佳，導致額外的測試、設計和整合工作，以及額外的客戶關係管理工作。
（7）產品風險
1.矯正質量低下的不可接受的產品，需要比預期更多的測試、設計和實現工作；
2.開發額外的不需要的功能(鍍金)，延長了計畫進度；
3.嚴格要求與現有系統相容，需要進行比預期更多的測試、設計和實現工作；
4.要求與其他系統或不受本專案組控制的系統相連，導致無法預料的設計、實現和測試工作；
5.在不熟悉或未經檢驗的軟體和硬體環境中執行所產生的未預料到的問題；
6.開發一種全新的模組將比預期花費更長的時間；
7.依賴正在開發中的技術將延長計畫進度。
（8）設計和實現風險
1.設計質量低下，導致重複設計；
2.一些必要的功能無法使用現有的**和庫實現，開發人員必須使用新的庫或者自行開發新的功能；
3.**和庫質量低下，導致需要進行額外的測試，修正錯誤，或重新製作；
4.過高估計了增強型工具對計畫進度的節省量；
5.分別開發的模組無法有效整合，需要重新設計或製作。
（9）過程風險
1.大量的紙面工作導致程序比預期的慢；
2.前期的質量保證行為不真實，導致後期的重複工作；
3.太不正規(缺乏對軟體開發策略和標準的遵循)，導致溝通不足，質量欠佳，甚至需重新開發；
4.過於正規(教條地堅持軟體開發策略和標準)，導致過多耗時於無用的工作；
5.向管理層撰寫程序報告占用開發人員的時間比預期的多；
6.風險管理粗心，導致未能發現重大的專案風險。
軟體工程之軟體工程管理
乙個好的工程需要配套的管理體系，軟體工程也不列外。軟體工程就我的理解就是對軟體工程的各個階段都一定規範，俗話說 不以規矩，不能成方圓 而這個規矩就由管理來充當。乙個軟體工程管理需要軟體專案計畫 成本估算 進度計畫 風險分析和人員的組織形式 或調動 一 在軟體專案計畫中，專案的任務是研究專案的效能 功...
軟體工程 軟體專案管理
上面部落格描述了軟體工程的全過程，軟體工程最終目的是開發出高質量的軟體，在定義上它與專案管理還是有一定的差別的 兩者差別 軟體工程 研究和應用如何以系統性的 規範化的 可定量的過程化方法去開發和維護軟體 專案管理 在軟體開發過程中對專案的成本 人員 進度 風險 質量等進行分析和控制的管理活動，從而使...
軟體工程 軟體工程的概述
軟體工程是研究和應用如何以系統性的 規範化的 可定量的過程化方法去開發和維護軟體，以及如何把經過時間考 驗而證明正確的管理技術和當前能夠得到的最好的技術方法結合起來的學科，它涉及到程式語言 資料庫 軟體 開發工具 系統平台 標準 設計模式等方面。先從軟體工程的第一章開始說起 軟體工程的概述，這一章是...