1、精選優質文檔-傾情為你奉上軟件項目風險檢查表專心-專注-專業修改記錄頁NO修改日期修改摘要（涉及頁碼/條款/內容）版本修改原因目 錄1. 引言1.1 目的風險檢查表的目的是提供風險檢查參考列表，在實施項目的過程中，根據本表生成該項目的風險管理卡，識別該項目潛在的風險，以便策劃應對風險的活動和在整個項目生存周期中實施這些活動，緩解并消除潛在的風險。1.2 適用范圍本文檔作為項目風險識別的初始依據和指導，使用者根據本機構和項目的實際情況不斷地完善本表內容。1.3 角色與職責角色職責項目經理(PM)總體負責識別項目的風險并給出應對策略項目成員識別項目的風險并給出應對策略SQA人員參照本表和質量管理流

2、程進行質保活動2. 風險檢查參考列表商業風險風險類型風險來源政治/法律1政府或者其它機構是否對本項目的開發有限制？2項目中間有沒有產品存在版權糾紛？3項目會不會對個人隱私造成干擾？4項目是否使用了非法數據？5項目是否產生了非法數據？6投標商是否可能采用了非法的競爭手段？客戶1客戶合作態度是否友善？2客戶在項目上是否有準備出足夠的時間？3客戶的人員數目是否足夠？4客戶的業務是否足夠熟練并勝任本項目？5客戶的各領導層是否支持本項目？6客戶部門內或者外是否有人對項目持否定態度？7客戶的歷史合作信譽度如何？8客戶是否易反復而不信守承諾？9客戶是否對項目有不符實際的較高要求？10軟件最后用戶數量大大超過

3、最初設計數量？承包商/供應商1與承包商/供應商簽訂的合同公正嗎？互利嗎？2承包商/供應商的信譽好嗎？3承包商/供應商是否容易倒閉？4承包商/供應商的售后服務有保證嗎？5承包商/供應商的人員隊伍穩定嗎？6承包商/供應商的歷史項目是否非常成功？7承包商/供應商的人員結構是否合理？8承包商/供應商能提供給本項目的合適的人員嗎？9承包商/供應商是否為了應對本項目而臨時招聘人員？10承包商/供應商是否可能撤出本項目的市場而轉型？11承包商/供應商是否為了拿到項目而故意降低報價？12承包商/供應商的報價是否已經離我方估算偏差較大？13承包商/供應商是否有追加變更而賺取利潤的企圖？項目風險風險類型風險來源項

4、目計劃1項目組是否能夠準確把握項目規模？2項目組是否真正地理解了客戶需求？3是否根據需求進行了估算，估算方法是否合理？4估算的成本是否高于預算經費卻不能得到足夠經費？5是否需要采購軟硬件開發設備？能否及時到位？6人力資源的配置能夠滿足項目的需要嗎？7進度計劃安排是否過于緊張？8有沒有合理的項目緩沖時間？9進度計劃表是否覆蓋所有研發任務？10任務的分配能夠充分發揮團隊成員的積極能動性嗎？11是否明確項目進度階段里程碑？溝通理解1是否有人對項目或者技術產生抵觸，并進行破壞？2SQA人員是否積極按照制度參與項目的QA工作？3項目成員是否團結？工作氛圍是否活躍？4成員表達溝通能力是否讓管理層滿意？5是

5、否制定獎賞懲罰措施？獎賞懲罰措施是否嚴格執行？6臨時成員是否占項目成員的較大比率？7人員變動包括核心人員嗎？8項目成員是否明確自己的職責？9項目經理或者調研人員能夠及時與客戶進行溝通嗎？10溝通的氛圍是否友好？溝通的效率高不高？11項目的成員有相關工作的經驗嗎？12客戶的表達能力是否強？13我方的理解能力是否強？14客戶是否理解我方對客戶需求的分析說明？15項目組人員是否懂得項目相關的具體業務知識？16具體業務有沒有行業規范參考？17需求文檔能夠正確表達客戶的需求嗎？18需求文檔對開發人員閱讀有困難嗎？19需求有沒有存在爭議？20項目資源的分配會不會隨時被抽調到別的項目？21本項目的合作部門的

6、態度是否積極？22項目組人員是否能夠嚴格遵守項目管理制度？技術風險風險類型風險來源人力資源1開發人員是否有開發相似產品的經驗？2核心人員對技術的熟悉程度是不是達到要求？3項目研發的核心技術是不是為開發人員所掌握？4若技術從來沒有接觸過，開發人員是否有足夠的學習能力？5項目中是否有一些人員只能部分時間工作6開發人員是否接受過必要的培訓?7項目開發人員是否配套？質量控制1開發小組是否采用比較有效的分析、設計、編程、測試工具？2分析與設計工作是否過于簡單、草率，從而讓程序員邊做邊改？3開發人員對測試工作重視嗎？4項目有獨立的測試人員嗎？5測試人員掌握了相關測試工具和方法了嗎？6是否對重要的工作成果進

7、行同行評審？7開發人員有沒有進行版本控制？8管理人員有沒有進行變更控制措施和制度措施保證？9配置人員能夠按照配置管理規范執行嗎？10是否會在進度延誤時降低質量要求？11項目成員是否按照度量規范記錄相關內容?開發環境1待開發的產品是否要與其它軟件有接口？2待開發的產品是否要應用未曾接觸的開發架構？3待開發的產品是否要使用未曾接觸的開發工具？4待開發的產品是否要使用未曾使用過的開發技術？5待開發的產品是否要部署在未曾接觸的硬件環境？6設計工具存在多樣選擇嗎？設計工具統一嗎？7設計文檔樣式有明確規定嗎？8開發小組采用統一的編程規范嗎？9由于功能復雜，導致項目編程語言種類繁多嗎？10維護工作有沒有采用

8、專門工具進行跟蹤管理？11因為維護產生的代碼修改有沒有及時納入版本控制？12維護范圍、進度、人員、規范的定義是否明確？開發階段風險風險類型風險來源需求階段1用戶的需求是否合理？2需求文檔是否整理出use case?3用戶是否對確認的需求做出承諾？4項目成員是否能夠根據需求整理出用戶使用文檔？5用戶需求是否有不斷膨脹、不斷變化的危險？6是否有工作量估算錯誤導致進度安排錯誤的危險?7需求中是否有過分的對產品的性能約束?8對重要復雜的需求有開發的界面原形來解釋嗎？9對需求規格說明書，用戶有正式文檔確認嗎？10對后續階段中需求變更的管理是否能夠按照規范執行？11待開發的軟件是否需要使用新的或未經證實的

9、硬件接口？設計階段1概要設計文檔是否合理？是否敷衍了事？2詳細設計文檔是否合理？是否敷衍了事？3有架構設計文檔嗎？有框架設計代碼嗎？有示例嗎？4設計階段采用的設計工具合適嗎？符合項目的要求嗎？5設計階段成果做了同行評審了嗎？6對同行評審的結果認真貫徹執行了嗎？7相應的工具如報表系統適合本系統嗎？代碼開發1是否能夠按照配置管理規范進行開發？2是否能夠遵守項目代碼開發規范？3項目組是否認真解決周例會發現的問題？4項目組能夠經常做代碼復用和整合的工作嗎？測試1是否認真執行各種測試規范？2是否使用了自動測試工具？3測試人員是否合格？4用戶參與測試是否積極？參與力度是否足夠？SCM1配置管理人員是否有足夠的知識技能？2代碼和文檔的備份能夠達到每