網(wǎng)游項目開發(fā)風險管理

1、用戶通常不善于精確描述自己的業(yè)務需求，系統(tǒng)分析員需要借助白板、 白紙等 目錄 前沿 參與過大型軟件項目的人都會認識到許多事情都可能出錯， 一但出錯就可能給項目帶來 危害、 損失或其它不利影響。 風險是在項目中發(fā)生的一系列事件或不利結果的可能性。 軟件 開發(fā)是一項高風險的活動， 在項目開發(fā)過程的任何一個階段都可能存在風險。 采取積極的風 險管理方式， 可以使項目進程更加平穩(wěn)， 可以獲得很高的跟蹤和控制項目的能力， 可以規(guī)避、 轉移風險， 或緩解風險帶來的不利影響。 風險管理是對項目風險進行識別、 分析、 應對和監(jiān) 控的過程， 是項目管理中很重要的管理活動， 有效的實施軟件風險管理是軟件項目開發(fā)工

2、作 順利完成的保證。 風險管理的達成必須包括三個要素： 首先， 在項目開發(fā)計劃中必須制定風 險管理計劃；第二，在項目預算中必須包含解決風險所需的經(jīng)費；第三，評估風險時，風險 的影響也必須納入項目計劃中 下面就軟件開發(fā)過程中經(jīng)常發(fā)生的風險，談談我們采取的預防措施。 1. 需求不明確 需求不明確是軟件開發(fā)過程中經(jīng)?？赡苡龅降膯栴}， 這類問題往往表現(xiàn)在需求范圍未界 定、需求未細化、需求描述不清楚、需求遺漏、需求互相矛盾等多個方面。在軟件開發(fā)過程 的生命周期各階段中， 需求不明確所造成的浪費是最大的， 必須盡早盡可能解決。 確定用戶 需求是件非常困難的事情，我們常常從以下幾個方面著手處理需求不明確問題

3、： (1) 讓用戶參與開發(fā) ? 提供一個協(xié)作開發(fā)環(huán)境， 讓用戶參與開發(fā)過程。 如果條件不允許， 至少應該在 每次迭代的需求分析和系統(tǒng)測試階段，讓客戶能夠參與開發(fā)。 ? 在選擇參與開發(fā)過程的用戶時， 一方面， 要盡可能爭取精通業(yè)務或計算機技術 的用戶參與。另一方面，如果開發(fā)的產(chǎn)品要在不同規(guī)模、不同類型的企業(yè)應 用，應該選擇具有代表性的用戶參與。 ? 僅僅讓用戶參與是不夠的， 應該采取一定的激勵措施， 提高用戶參與的積極性。 (2) 開發(fā)用戶界面原型 溝通方式，幫助用戶清楚表述需求。然后，開發(fā)一個用戶界面原型，以便用戶確 認需求。用戶界面原型的作用僅僅是收集用戶需求，不應該再作它用，也不要給 用戶

4、造成系統(tǒng)快要實現(xiàn)的錯覺。 (3) 需求討論會議 對于用戶分布廣、用戶量大的項目， 要全面收集用戶需求，往往很困難，通常 采取需求研計會議方式進行需求確認。通過在會議前幾周調(diào)查各地、各部門用戶 需求意見，然后集中各地或各部門的用戶代表，舉辦一次需求研討會，通過會議 方式收集需求。本方法適合于具有一定信息系統(tǒng)使用經(jīng)驗的用戶。 (4) 強化需求分析與評審 首先， 需求分析是項目成功的基礎， 需要引起足夠的重視， 并分配充足的時間 和人力，要讓有經(jīng)驗的系統(tǒng)分析員負責，切忌讓項目新手或程序員負責。其次， 要進行需求評審， 盡可能讓用戶參與需求評審， 不要讓需求評審流于行式。 第三， 也是最重要的一點，通

5、過評審的需求規(guī)格說明書，要讓用戶方簽字，并作為項目 合同的附件， 對雙方都具有約束力。 在公司內(nèi)部要將通過評審的需求規(guī)格說明書， 納入配置管理。 2. 項目缺少可見性 當一個項目經(jīng)理或一名開發(fā)者說已經(jīng)完成了80%的任務，您必須保持審慎的態(tài)度。 因為剩下的 20%可能還需要 80%的時間，甚至永遠都不能完成 1 。軟件開發(fā)項目，往 往在項目進度和軟件質(zhì)量方面缺少可見性， 項目越缺少可見性， 項目就越難以控制， 項 目就越有可能失敗。 我們可以通過迭代開發(fā)、 技術評審、 持續(xù)集成來增強項目的可見性。 (1) 迭代開發(fā) ? 采用迭代的開發(fā)模型， 將產(chǎn)品的交付過程分為多個階段， 按照功能遞增式 交付。

6、以下是一些典型的迭代： ? 一次簡短的先期迭代，以建立規(guī)模和前景并確定商業(yè)理由； ? 一次精化迭代，其間將為穩(wěn)定的構架劃定基線； ? 一次構建迭代，其間將實現(xiàn)用例并充實構架； ? 幾次產(chǎn)品化迭代，將產(chǎn)品轉移到用戶群。 ? 每次迭代， 都要充分接收用戶的評審意見， 以便為自我糾正。 漸近式的功 能交付，有利于降低開發(fā)人員的壓力，增加用戶的滿意度，有利于增強 項目的可見性，是最好的進展報告。 (2) 技術評審 技術評審是確保軟件質(zhì)量的重要環(huán)節(jié)， 技術評審包括代碼走查、 會議評審和同 行專家評審。代碼走審可以是開發(fā)人員之間的交叉審查，或者是高級開發(fā)人員對 普通開發(fā)人員的審查；會議評審一般應至少每兩周

7、進行一次，每次評審時間不宜 太長；同行專家評審包括技術和業(yè)務兩個方面的專家，經(jīng)常性地讓精通業(yè)務的用 戶專家參與項目評審，是項目成功的重要保證。 另外，充分利用質(zhì)量審查的工具軟件， 也有利于提高代碼質(zhì)量。 例如：在 Eclipse 開發(fā)環(huán)境中，可以集成 Findbug 、 Checkstyle、 PMD 插件檢查代碼編寫質(zhì)量。 (3) 持續(xù)集成 持續(xù)集成能夠把最終的一次大規(guī)模的集成調(diào)試過程分散到項目開發(fā)時間表的 每一周、 每一天、 甚至每個小時。 讓項目中的各個人員都能夠隨時掌握當前的整體 進度，并迅速發(fā)現(xiàn)集成過程中出現(xiàn)的問題并進行解決1 。 開發(fā)小組應制定持續(xù)集成的制度，一般情況下每日構建一次

8、，可以利用 Ant 等構建工具進行 Java 應用程序的構建。小組成員應在每個功能開發(fā)完成后，及時 向版本控制系統(tǒng)(如 CVS提交代碼，而且不應該向版本控制系統(tǒng)提交有問題(編 譯通不過)的代碼。 每日構建、 持續(xù)集成， 讓項目進度跟蹤工作更加容易。 當項目小組每天重新編 譯系統(tǒng)時， 已完成與未完成的功能清楚可見， 小組成員能夠簡單地從軟件的表現(xiàn)知 道距離整體完成還有多遠。 3. 新技術引入 技術創(chuàng)新是一種具有探索性、創(chuàng)造性的技術經(jīng)濟活動。在開發(fā)過程中引入新技術， 不可避免地要遇到各種風險。通過 T 形軟件開發(fā)、 充分論證、多階段評審、 同行經(jīng)驗等 措施可降低新技術風險。 (1) T形軟件開發(fā)

9、在項目開發(fā)早期， 開發(fā)小組應該建立系統(tǒng)的架構， 解決關鍵技術難題、 開發(fā)系 統(tǒng)的基礎構件，并對系統(tǒng)所需要應用的技術做深度探索。例如：基于JavaEE5勾建 全國聯(lián)網(wǎng)售票系統(tǒng)， 涉及到分布式事務處理、 海量數(shù)據(jù)存儲、 異構平臺互連等關鍵 問題，應該優(yōu)先處理這些問題；對開發(fā)所涉及到的EJB3、JSF、JBoss Seam、Eclipse RCP等技術，要做深度探索。 圖1在第一階段以“T”開發(fā)系統(tǒng)骨架2 越是技術復雜度高的項目， 就越應該早地處理技術難題。 如果在項目開發(fā)的中 期或后期才發(fā)現(xiàn)架構有問題或是關鍵技術難題不能解決，則為時已晚。 (2) 充分論證 新技術開發(fā)是探索性很強的工作， 潛在著許

10、多失敗的風險。 在可行性分析階段， 要廣泛搜集相關信息，設計多種可行方案，進行充分論證。在制定決策時，情報的 數(shù)量和質(zhì)量致關重要。掌握的信息越多、 越準確， 才能作出正確的的決策， 項目失 敗的風險也就相對減少；反之，承擔的風險就會增大。 (3) 同行經(jīng)驗 針對新技術， 由于沒有經(jīng)驗可借鑒， 因此在探索過程中要充分利用互聯(lián)網(wǎng)， 通 過搜索同行經(jīng)驗， 往往事半功倍。 要充分利用世界日益平坦化的優(yōu)勢， 對于不能盡 快解決的問題， 可以先放一放， 可能過不了幾天， 網(wǎng)上就有相類似問題的解決方案 了。 4. 技術兼容性風險 硬件產(chǎn)品之間、 系統(tǒng)軟件(操作系統(tǒng)、 中間件、 數(shù)據(jù)庫管理系統(tǒng)) 與主機設備之

11、間、 系統(tǒng)軟件之間、應用軟件與系統(tǒng)軟件之間以及應用軟件之間，都可能存在兼容性問題。 往往系統(tǒng)集成的項目越復雜，兼容性問題就越有可能存在。 (1 )設計先行 在做系統(tǒng)的總體設計方案時， 務必把好相關產(chǎn)品的選型關， 確保網(wǎng)絡、 主機、 系統(tǒng)軟件與應用軟件之間不要存在較大的技術兼容性問題。在網(wǎng)絡平臺建設 方案中，明確相關設備的技術參數(shù)和配置要求。 (2) 售前產(chǎn)品測試 在做項目招投標工作時，要求投標方在售前提供產(chǎn)品兼容性測試，以避免在 項目實施過程中才暴露技術兼容性問題。涉及應用軟件開發(fā)的集成項目，要 在開發(fā)工作的早期，做技術兼容性測試，以避免在項目開發(fā)后期才暴露技術 兼容性問題。 例如 :我們在開

12、發(fā)深圳市汽車客運站售票及站務聯(lián)網(wǎng)調(diào)度系統(tǒng)時，為了確保技 術兼容，在做硬件招標時要求小型機設備廠商提供售前技術兼容性測試工 作，并將測試結果做為評標指標。在深圳市軟件測試中心對IBM 、SUN、HP 三家公司提供的小型機進行測試時，暴露了許多應用軟件、應用服務器、數(shù) 據(jù)庫和操作系統(tǒng)之間的技術兼容性問題，如果這些問題在系統(tǒng)實施時才暴露 或處理，勢必會拖延項目進度。 5. 性能問題 由于先期設計不足， 性能問題往往在系統(tǒng)切換或新系統(tǒng)使用一段時間后暴露。 出現(xiàn)性能 問題往往要進行大量的優(yōu)化工作，甚至局部的或全面的重新設計。無論是用戶還是開發(fā)者， 誰都不希望出現(xiàn)性能問題。 (1) 性能規(guī)劃 在系統(tǒng)設計時

13、， 應做好前期做性能規(guī)劃， 對可能出現(xiàn)性能問題的環(huán)節(jié)做到充足 的估計。在做數(shù)據(jù)庫設計時，應爭取 DBA 參與。 另外，在技術方法方面，盡可能采取一些性能優(yōu)化模式，如DTO AJAX延遲 加載等， 盡可能在開發(fā)過程中解決了性能問題。 不至于到了項目后期才解決性能問 題，既費錢又費時。 (2) 性能測試 在開發(fā)過程中， 要重視性能測試和壓力測試， 盡可能模擬現(xiàn)實使用環(huán)境， 搭建 測試平臺。 另外， 由于開發(fā)環(huán)境的計算機往往比生產(chǎn)環(huán)境的計算機配置高，在做測 試時應盡量找一些配置低的機器、較小的網(wǎng)絡帶寬進行測試。 (3) 充足的調(diào)試時間 在項目開發(fā)計劃中， 為后期性能優(yōu)化留有余地。 在對系統(tǒng)進行性能優(yōu)

14、化后， 要 進行性能測試和壓力測試， 可能還要做幾次回歸測試。 因此， 應該留有充足的時間 和人力。 6. 倉促上線 在項目實施過程中，系統(tǒng)切換上線環(huán)節(jié)最容易出紕漏。項目好不容易開發(fā)完成了， 卻在最后最后時刻功潰一匱。 如果項目小， 影響面窄倒不怎么重要； 如果是影響面大的 項目， 則千萬不可出現(xiàn)問題。在系統(tǒng)切換前， 應充分考慮各種可能出現(xiàn)的問題，做好風 險對策。 (1) 應急預案 面對各種不可預知的風險， 要做好應急預案。 正常運行的車站售票系統(tǒng)在春運、 旅游黃金周，都會做好應急預案。新系統(tǒng)切換時， 更應該做好應急預案。應急預案 中應做好最壞的打算，售票系統(tǒng)不能正常工作時，準備手工票就是最壞

15、的打算。 (2) 分步切換 為了減少風險的影響， 可以做系統(tǒng)分步切換的方案。 例如：售票系統(tǒng)在切換時， 往往用新系統(tǒng)售預售票， 或者是用新系統(tǒng)售長途車站， 用舊系統(tǒng)暫時售短程票。 待 新系統(tǒng)運行穩(wěn)定后， 再全面切換到新系統(tǒng)。 針對多個用戶單位的系統(tǒng)切換， 也可分 單位進行。 (3) 交叉培訓 新舊系統(tǒng)切換過程中，用戶都存在適應過程。除了在切換前做好操作培訓外， 還要在新舊系統(tǒng)切換過程中做好交叉培訓。 讓用戶提前一些時間上班， 讓早班的用 戶在* 時培訓中班的用戶， 中班的用戶培訓晚班的用戶。 做好交叉培訓能夠讓系統(tǒng) 平衡過渡。 7. 可用性問題 軟件的可用性包括軟件的使用是不是高效、 是否容易

16、學習、 是否容易記憶、 是否令 人愉快、是否不易出錯等諸多因素。 往往由于軟件的可用性差，導致用戶不滿意， 甚至 被市場淘汰。在項目開發(fā)中應注意可用性問題，避免軟件出現(xiàn)可用性方面的風險。 (1) 了解用戶 到用戶工作現(xiàn)場， 了解目標用戶使用軟件的真實目的， 從用戶的角度、 從 用戶的立場出發(fā)， 了解如何通過軟件系統(tǒng)替代用戶的業(yè)務處理流程中， 最繁瑣、 最容易出問題、 或者是大量重復勞動的環(huán)節(jié)， 讓軟件提高用戶的工作效能和效 率。例如： 售票系統(tǒng)中，使用頻度最高的界面是售票界面， 售票員最關心的是 錢不要出錯(多了沒收、少了要賠) ，因此，應收款和找余字體的顯示應該突 出、醒目；同樣， 票價和到

17、達站也應該較為突出顯示。 通過快捷鍵、 一鍵復位、 數(shù)字小鍵盤等設計， 盡量減少售票員敲擊鍵盤的次數(shù)。 否則， 在日發(fā)旅客流量 達七、 八萬人次的大型客運站， 如果用戶界面設計得不好， 售票員一天工作下 來，手指都會敲麻木。 (2) 參與型設計 與用戶協(xié)作， 讓用戶參與用戶界面的設計、 評審與測試， 確保用戶能夠全 面地、及早地發(fā)現(xiàn)可用性等方面的問題，并及時糾正。 讓客戶參與設計， 而不要讓客戶設計， 項目經(jīng)理或高級設計人員應該主導 設計。 (3) 競爭性分析 通過對市場上同類競爭性產(chǎn)品進行分析，或者對這些產(chǎn)品進行實驗性測 試，了解這些產(chǎn)品的用戶界面問題， 從而對新系統(tǒng)的開發(fā)提供啟發(fā)。 競爭性

18、分 析并不意味著可以剽竊別人的設計， 而是通過分析競爭產(chǎn)品的優(yōu)勢和弱點， 能 夠比以前的設計做得更好 5 。 (4) 一致性 如果用戶知道同樣的命令或同樣的操作總會產(chǎn)生同樣的效果， 那么他們在 使用系統(tǒng)時就會更加自信， 同時也鼓勵他們進行探索性學習， 因為他們已經(jīng)具 備了使用系統(tǒng)新部分的基礎知識 Lewis er al.1989 。 開發(fā)團隊應遵循公司或小組制定的用戶界面標準， 就可以在很多方面保持 一致性，切忌不要一個系統(tǒng)存在多種不同的界面風格。 8. 結論 在信息系統(tǒng)集成項目中，風險是多種多樣的，是無處不在的。在項目管理活動中， 要積極面對風險，要培養(yǎng)。越早識別風險、越早管理風險，就越有可能規(guī)避風險，或者 在風險發(fā)生時能夠降低風險帶來的影響。 特別是在項目參與方多、 涉及面廣、 影響面大、 技術含量高的復雜項目，應加強風險