項目風險管理案例分析

1、項目風險管理案例分析1公司背景簡介河北 H-A 會計師事務所是河北省財政廳對國有大中型企業(yè)進行社會審計的 試點所，承擔省直大中型企業(yè)的審計工作。 具有豐富工作經驗， 擁有一批具有豐 富實踐經驗的注冊會計師。河北省某研究所是省直科研單位，現(xiàn)有 50多位員工。在基于 WINDOWS臺 開發(fā)軟件方面， 具備較豐富的實戰(zhàn)技能。 河北 H-A 會計師事務所在審計工作中發(fā) 現(xiàn)，很多企業(yè)都采用了會計電算化軟件， 對審計工作提出新的要求。 社會審計工 作的需要， 對開發(fā)計算機輔助審計軟件的愿望越來越強烈。 所以就聯(lián)合河北省某 研究所進行聯(lián)合開發(fā)2實際項目分析2.1 項目介紹該系統(tǒng)基于 windows 和 sq

2、l server 進行開發(fā)，開發(fā)工具是 powerbulider 。 項目開發(fā)過程中， 共生成程序源代碼約數(shù)萬行， 項目開發(fā)的難度和源代碼行數(shù)都比預 計的要多。計算機輔助審計軟件具有工作底稿制作能力和查證功能； 數(shù)據(jù)可傳遞， 能自 動生成和人工輸入相結合， 產生合并抵銷分錄； 能自動產生勾稽無誤的審計報告 和會計報表附注；有靈活開放的系統(tǒng)，方便用戶進行二次開發(fā)等特點。2.2 開發(fā)隊伍的風險開發(fā)團隊維持在 10 人上下，事務所提供 3 人，開發(fā)單位 6-7 人，有一些人 員只能部分時間工作，開發(fā)人員能夠自始至終地參加整個項目的工作。開發(fā)人 員的流動基本能保證工作的連續(xù)性。2.3 技術風險數(shù)據(jù)結構

3、復雜，關聯(lián)比較多。需要創(chuàng)建新的算法或輸入 , 輸出技術；軟件需 要與其他軟件產品的數(shù)據(jù)庫系統(tǒng)接口； 客戶能確定所要求的功能是可行的。 同時， 由于當時審計軟件在國內的應用尚處于起步階段， 開發(fā)人員普遍對該系統(tǒng)比較陌 生，這也帶來了相當?shù)募夹g風險。2.4 客戶相關風險用戶對自己真正的需求并不是十分明確， 他們認為計算機是萬能的， 只要簡 單的說說自己想干什么就是把需求說明白了， 而對業(yè)務的規(guī)則、 工作流程卻不愿 多談，也講不清楚。 有的用戶日常工作繁忙， 他們不愿意付出更多的時間和精力 向分析人員講解業(yè)務， 這樣加大分析人員的工作難度和工作量， 也可能導致因業(yè) 務需求不足而使系統(tǒng)風險加大。2.5

4、 項目按時完成的風險 另外，這個項目也像許多其它軟件項目一樣， 面臨著竣工日期帶來的巨大壓 力。3 實際的風險管理狀況憑借公司在以往的經驗， 在此軟件項目的整個生命周期中， 任何階段都有可 能有風險存在，WB克完整表示項目，且伴隨整個項目生命周期的項目要素，所 以以WBS為基礎進行風險管理，既可以方便地識別，標識相應的風險來源，又方 便和項日其他工作一起，統(tǒng)一管理。 在軟件項目中，各階段主要工作簡述如下： 啟動階段：進行項目預研， 以確定項目是否立項， 并對項目的范圍進行比較清晰 的定義； 計劃編制階段：進行初步的需求分析， 詳細定義項目的范圍， 并對項目涉及的所 有相關活動，做盡可能細的詳細

5、計劃；執(zhí)行階段：詳細分析需求， 保證軟件開發(fā)生命周期各階段中不同需求的來源是可 追溯，并按需求進行設計、編碼、測試，以確定軟件產品達到計劃給 定的范圍和標準，并做相應的部署測試；控制階段： 該階段貫穿計劃和執(zhí)行兩個階段， 主要進行各種控制 T 作，如需求變 更、進度、費用控制等； 收尾階段：項目的收尾工作，主要是安裝和維護；在軟件開發(fā)生命周期的四個主要階段中， 通過研究不同階段側重點不同的階 段目標以及衡量不同階段目標的標準， 在軟件開發(fā)的各個階段中， 即需求分析階 段、軟件設計階段、 編碼階段和測試階段， 我們可以發(fā)現(xiàn)存在于各階段中的風險 項。并由項目經理在啟動、計劃、執(zhí)行、控制、結束五個階

6、段予以控制。3.1 需求分析階段、風險識別表 1 需求階段識別的主要風險、風險分析表 2 需求階段風險定性分析、風險解決表 3 需求階段風險解決方案3.2 設計階段、風險識別表 4 設計階段識別的主要風險、風險分析表 5 設計階段風險定性分析、風險解決表 6 設計階段風險解決方案4 實施效果與總結分析4.1 實施效果此項目開發(fā)的目標是為了向審計公司提供輔助審計管理系統(tǒng)。 開發(fā)流程也是 比較遵從軟件工程的規(guī)范的。 但是最終的結果卻不盡人意， 投入了比預料多幾倍 的人力物力。根據(jù)當時參與項目的同事的分析，失敗的原因主要是：、需求不明確由于出發(fā)點和利益不同， 系統(tǒng)開發(fā)者與用戶對于同一問題常有不同看法

7、， 這 樣需求分析的風險就逐漸加大了。 另外對需求變更的控制做得不好。 需求的改變， 就會產生連鎖反應， 有時候這種反應會導致程序的不穩(wěn)定， 嚴重的時候， 一個錯 誤的修改引起另一處程序的錯誤， 而新的錯誤的修改會導致更新的錯誤， 更嚴重 的情況，不是所有的錯誤都能被修改。、技術風險此軟件數(shù)據(jù)結構復雜， 邏輯關聯(lián)性比較強。 軟件需要與第三方財務軟件產品 的數(shù)據(jù)庫系統(tǒng)接口。 帶來了相當?shù)募夹g開發(fā)困難， 阻礙了項目的進行。 由于以上 原因到了測試階段， 未確定的需求和不斷發(fā)現(xiàn)的 bug 成了災難。結果測試當天就 因為一個bug導致數(shù)據(jù)被誤刪和數(shù)據(jù)混亂。于是暫停測試，改為封閉式開發(fā)，并 精品這就意味

8、且繼續(xù)增加人員， 第二次修改時是才發(fā)現(xiàn)整個數(shù)據(jù)結構也要發(fā)生變動， 著無異于從新開發(fā)一次，所以最后不得不投入大量的人員予以彌補。分析原因，為什么這個項目會失?。靠磥砗孟袷切枨鬀]有做好， 其實是沒有 把風險放在整個項目這個大系統(tǒng)下來對待，沒有建立一套完整的風險管理機制， 這樣一來風險因素就容易被忽略。 然而，軟件項目前一階段的失誤會對下一階段 產生嚴重的影響。一旦發(fā)生了變化，就不得不修改設計、重寫代碼、修改測試用 例、調整項目計劃等等，為項目的正常的進展帶來不盡的麻煩。所以，沒有切實 可行的風險管理過程機制， 就很難有效地保證風險管理活動的效率。 建立切實可 行的風險管理過程機制是軟件風險管理理論研究成果最終在實踐中得到應用的 最根本保證4.2 軟件項目風險管理改進IT 項目管理從某種意義上講，就是風險管理。從理論上講，雖然 IT 項目風 險管理開始于項目開發(fā)生命周期的可行性研究階段， 但實際上風險管理應該貫穿 于項目的始終， 并需要持續(xù)的關注和評估。 因此實施項目風險管理就要建立風險 管理機制， 從制度上加以保障， 只有這樣才能夠及時識別風險并且能采取降低風 險的好措施，從而減小1T項目的不確定性和偏差，最終順利地把項目引向成功。 根據(jù)實際情況， 也可通過外部環(huán)境的優(yōu)化對風險管理起到的支持