一、需求

軟件項目風險分類整理（軟件項目風險分類整理方法）

二、設計

軟件項目風險分類整理（軟件項目風險分類整理方法）

三、編碼和單元測試

軟件項目風險分類整理（軟件項目風險分類整理方法）

四、集成和測試

軟件項目風險分類整理（軟件項目風險分類整理方法）

五、驗收和維護

軟件項目風險分類整理（軟件項目風險分類整理方法）

六、團隊

軟件項目風險分類整理（軟件項目風險分類整理方法）

七、成本

軟件項目風險分類整理（軟件項目風險分類整理方法）

八、組織和管理

軟件項目風險分類整理（軟件項目風險分類整理方法）

原件：

項目風險分類

1. 需求

需求沒有文檔化

[1] 是否僅有未成文的需求？

如果項目的需求只是通過口頭表達，則需要考慮風險。

需求不穩(wěn)定

[2] 需求是否正在變化或是已經確定下來了？

如果需求正在被增加、變更或是沒有被確定下來，則需要考慮風險。

需求不完全

[3] 需求中所有項目是否都有詳細說明？

如果需求中有未列出詳細說明的項目，則需要考慮風險。

需求可讀性差

[4] 需求文檔的可讀性如何？

如果需求文檔的可讀性差，則需要考慮風險。

需求不清晰

[5] 你是否可以理解需求，如同作者想要表達的？

如果關鍵的需求是模糊的、不明確的，則需要考慮風險。

需求進度緊張

[6] 進度中是否安排了足夠的需求分析時間？

如果需求分析階段的進度緊張，則需要考慮風險。

需求分析能力有限

[7] 需求分析人員的能力是否有限？

如果需求分析人員的能力有限，則需要考慮風險。

需求無經驗可借鑒

[8] 項目需求的關鍵部分是否有以往的經驗可以借鑒？

如果需求的關鍵部分無法借鑒以往項目的經驗，則需要考慮風險。

需求不可行

[9] 是否存在在實現時有技術困難的需求？

如果不能確定某一項需求在所用的開發(fā)語言環(huán)境中實現的方法，則需要考慮風險。

需求不可跟蹤

[10] 是否有計劃在設計、編碼和測試階段對需求進行跟蹤？

如果需求與開發(fā)過程出現偏差，或是在各個階段沒有被把握住，則需要考慮風險

2. 設計

設計的算法有問題

[11] 是否存在沒有滿足需求或是僅僅部分滿足需求的算法？

如果算法有可能是錯誤的、不完整的，或是太復雜，則需要考慮風險。

設計難度大

[12] 是否存在難于設計的需求或是功能？

在某些時候，如一個復雜的樹的查詢可能需要很多的精力來設計，則需要考慮風險。

設計難度偏大過偏小

[13] 設計中的任何一部分是否是基于不切實際的或是樂觀的假設？

如果對需求的設計太樂觀或者太悲觀，則需要考慮風險。

設計的接口定義不完全

[14] 是否內外部接口都已經很好的定義了？

如果在系統(tǒng)內部或是系統(tǒng)間存在復雜的、大量的聯(lián)系，則需要考慮風險

設計不易測試

[15] 軟件是否易于測試？

如果在測試產品時有很大的復雜性，則需要考慮風險。

設計有硬件約束

[16] 開發(fā)或是運行硬件是否對滿足需求有限制？

如果在硬件速度、容量、可用性和功能方面有限制，則需要考慮風險

設計有軟件復用性要求

[17] 是否存在軟件復用？

需要考慮復用軟件時的修改可能導致比設計新軟件更多問題的風險。

3. 編碼和單元測試

編碼和單元測試的可行性

[18] 產品中是否有某些部分沒有在設計說明書中被完全定義？

如果沒有在設計時跟蹤需求就編碼，則需要考慮風險。

[19] 設計說明書是否有足夠的細節(jié)描述代碼？

如果設計處于太高的層次，則需要考慮風險。

編碼進度偏差

[20] 是否存在充分的時間進行編碼？

如果在進度表中沒有安排充分的時間進行編碼，則需要考慮風險。

[21] 是否對項目組在編碼時間和工作量方面的估計有意見？

如果過于低估你的工作量，則需要考慮風險。

[22] 編碼的實際進度是否與計劃相比有比較大的偏差？

如果編碼的實際進度與計劃相比有比較大的偏差，則需要考慮風險。

測試進度偏差

[23] 是否存在充分的時間進行全部的單元測試？

如果在進度表中沒有安排充分的時間進行測試，則需要考慮風險。

[24] 如果進度出現問題，是否會妥協(xié)，對單元測試進行調整？

考慮誰將妥協(xié)，在什么模塊，考慮什么可能被遺漏。

[25] 是否對項目組在編碼時間和工作量方面的估計有意見？

如果過于低估你的工作量，則需要考慮風險。

[26] 測試的實際進度是否與計劃相比有比較大的偏差？

如果測試的實際進度與計劃相比有比較大的偏差，則需要考慮風險。

編碼工具問題

[27] 開發(fā)語言是否適合開發(fā)的軟件產品？

如果開發(fā)語言不適合開發(fā)的軟件產品，則需要考慮風險。

[28] 項目組是否在開發(fā)語言、開發(fā)平臺或是開發(fā)工具方面有足夠的經驗？

如果項目組在開發(fā)語言、開發(fā)平臺或是開發(fā)工具方面沒有良好的開發(fā)經歷，則需要考慮風險。

編碼缺乏配置管理

[29] 是否有代碼的配置管理計劃？

如果沒有版本控制或是代碼修改不受控，則需要考慮風險。

4. 集成和測試

集成和測試硬件支持不足

[30] 是否有足夠的硬件做充分的集成和測試工作？

如果沒有足夠的硬件資源，則需要考慮風險。

集成和測試進度緊張

[31] 是否有足夠的產品集成方面的說明，是否安排了充分的時間做集成工作？

需要考慮滿足進度和足夠測試覆蓋率要求的風險。

5. 驗收和維護

產品驗收標準不一致

[32] 是否對全部需求的驗收標準都已經達成一致？

如果不確切明了什么是用戶所期望得到的，則需要考慮風險。

產品的可維護性不好

[33] 產品設計和相關文檔是否可以充分滿足另外一個組維護代碼的要求？

如果產品設計和相關文檔不能充分滿足另外一個組維護代碼的要求，則需要考慮風險。

6. 團隊

員工經驗不足

[34] 在項目組中是否有很多新員工？

如果新員工比較多，則需要考慮風險。

[35] 項目經理和開發(fā)組長的工作經驗是否豐富？

如果項目經理或開發(fā)組長在以往沒有相應的工作經驗，則需要考慮風險。

員工流動性大

[36] 項目組成員在項目結束前是否有流動的可能性？

如果項目組成員在項目結束前有流動的可能性，則需要考慮風險。

內部缺乏交流

[37] 在項目組中是否缺乏方便的、有效的交流？

如果進度表與項目會議沖突，則需要考慮風險。

[38] 是否和上級缺乏有關項目的方便、有效的交流？

在缺乏完整的信息情況下，需要考慮工作產品的質量風險。

項目組內部合作缺乏氛圍

[39] 項目是否以前合作過？

如果項目組不能很好的合作，或是以前沒有很好合作的經歷，則需要考慮風險。

[40] 項目組是否對任務有清楚的認識？

如果項目組內存在分歧，則需要考慮風險。

7. 成本

缺乏成本管理和跟蹤

[41] 是否對成本有測量和跟蹤？

如果沒有對成本進行測量和跟蹤，則需要考慮風險。

[42] 預算偏差

如果實際成本和預算有比較大的出入，則需要考慮風險。

8. 組織和管理

組織缺乏管理

[43] 組織是否有專門的人員負責管理？

如果組織沒有人負責管理，則需要考慮風險。

決策者能力有限

[44] 管理層是否有威信，是否果斷，決策人是否有很高的素質？

如果管理層沒有威信，處理事務優(yōu)柔寡斷，素質不高，則需要考慮風險。

軟件項目風險分類整理（軟件項目風險分類整理方法）

一、需求

二、設計

三、編碼和單元測試

四、集成和測試

五、驗收和維護

六、團隊

七、成本

八、組織和管理

相關推薦

二、設計

三、編碼和單元測試

四、集成和測試

六、團隊

八、組織和管理