NO IMAGE

參加過專案製作的人 都知道一個專案開發過程中 會遇到許多困難,很多事情都會影響一個軟體開發的失敗  風險是在專案中發生的一系列事件或不利結果的可能性。軟體開發是一項高風險的活動,在專案開發過程的任何一個階段都可能存在風險。採取積極的風險管理方式,可以使專案程序更加平穩,可以獲得很高的跟蹤和控制專案的能力,可以規避、轉移風險,或緩解風險帶來的不利影響。風險管理是對專案風險進行識別、分析、應對和監控的過程,是專案管理中很重要的管理活動,有效的實施軟體風險管理是軟體專案開發工作順利完成的保證。風險管理的達成必須包括三個要素:首先,在專案開發計劃中必須制定風險管理計劃;第二,在專案預算中必須包含解決風險所需的經費;第三,評估風險時,風險的影響也必須納入專案計劃中。

   下面就軟體開發過程中經常發生的風險,

    2.需求不明確
需求不明確是軟體開發過程中經常可能遇到的問題,這類問題往往表現在需求範圍未界定、需求未細化、需求描述不清楚、需求遺漏、需求互相矛盾等多個方面。在軟體開發過程的生命週期各階段中,需求不明確所造成的浪費是最大的,必須儘早儘可能解決。確定使用者需求是件非常困難的事情,我們常常從以下幾個方面著手處理需求不明確問題:

(1) 讓使用者參與開發

提供一個協作開發環境,讓使用者參與開發過程。如果條件不允許,至少應該在每次迭代的需求分析和系統測試階段,讓客戶能夠參與開發。

在選擇參與開發過程的使用者時,一方面,要儘可能爭取精通業務或計算機技術的使用者參與。另一方面,如果開發的產品要在不同規模、不同型別的企業應用,應該選擇具有代表性的使用者參與。

僅僅讓使用者參與是不夠的,應該採取一定的激勵措施,提高使用者參與的積極性。

(2) 開發使用者介面原型

使用者通常不善於精確描述自己的業務需求,系統分析員需要藉助白板、白紙等溝通方式,幫助使用者清楚表述需求。然後,開發一個使用者介面原型,以便使用者確認需求。使用者介面原型的作用僅僅是收集使用者需求,不應該再作它用,也不要給使用者造成系統快要實現的錯覺。

(3) 需求討論會議

對於使用者分佈廣、使用者量大的專案,要全面收集使用者需求,往往很困難,通常採取需求研計會議方式進行需求確認。通過在會議前幾周調查各地、各部門使用者需求意見,然後集中各地或各部門的使用者代表,舉辦一次需求研討會,通過會議方式收集需求。本方法適合於具有一定資訊系統使用經驗的使用者。

(4) 強化需求分析與評審

首先,需求分析是專案成功的基礎,需要引起足夠的重視,並分配充足的時間和人力,要讓有經驗的系統分析員負責,切忌讓專案新手或程式設計師負責。其次,要進行需求評審,儘可能讓使用者參與需求評審,不要讓需求評審流於行式。第三,也是最重要的一點,通過評審的需求規格說明書,要讓使用者方簽字,並作為專案合同的附件,對雙方都具有約束力。在公司內部要將通過評審的需求規格說明書,納入配置管理。

3.專案缺少可見性
當一個專案經理或一名開發者說已經完成了80%的任務,您必須保持審慎的態度。因為剩下的20%可能還需要80%的時間,甚至永遠都不能完成[1]。軟體開發專案,往往在專案進度和軟體質量方面缺少可見性,專案越缺少可見性,專案就越難以控制,專案就越有可能失敗。我們可以通過迭代開發、技術評審、持續整合來增強專案的可見性。

(1) 迭代開發

採用迭代的開發模型,將產品的交付過程分為多個階段,按照功能遞增式交付。以下是一些典型的迭代:

一次簡短的先期迭代,以建立規模和前景並確定商業理由;

一次精化迭代,其間將為穩定的構架劃定基線;

一次構建迭代,其間將實現用例並充實構架;

幾次產品化迭代,將產品轉移到使用者群。

每次迭代,都要充分接收使用者的評審意見,以便為自我糾正。漸近式的功能交付,有利於降低開發人員的壓力,增加使用者的滿意度,有利於增強專案的可見性,是最好的進展報告。

(2) 技術評審

技術評審是確保軟體質量的重要環節,技術評審包括程式碼走查、會議評審和同行專家評審。程式碼走審可以是開發人員之間的交叉審查,或者是高階開發人員對普通開發人員的審查;會議評審一般應至少每兩週進行一次,每次評審時間不宜太長;同行專家評審包括技術和業務兩個方面的專家,經常性地讓精通業務的使用者專家參與專案評審,是專案成功的重要保證。

另外,充分利用質量審查的工具軟體,也有利於提高程式碼質量。例如:在Eclipse開發環境中,可以整合Findbug、Checkstyle、PMD外掛檢查程式碼編寫質量。

(3) 持續整合

持續整合能夠把最終的一次大規模的整合除錯過程分散到專案開發時間表的每一週、每一天、甚至每個小時。讓專案中的各個人員都能夠隨時掌握當前的整體進度,並迅速發現整合過程中出現的問題並進行解決[1]。

開發小組應制定持續整合的制度,一般情況下每日構建一次,可以利用Ant等構建工具進行Java應用程式的構建。小組成員應在每個功能開發完成後,及時向版本控制系統(如CVS)提交程式碼,而且不應該向版本控制系統提交有問題(編譯通不過)的程式碼。

每日構建、持續整合,讓專案進度跟蹤工作更加容易。當專案小組每天重新編譯系統時,已完成與未完成的功能清楚可見,小組成員能夠簡單地從軟體的表現知道距離整體完成還有多遠。

4.新技術引入
技術創新是一種具有探索性、創造性的技術經濟活動。在開發過程中引入新技術,不可避免地要遇到各種風險。通過T形軟體開發、充分論證、多階段評審、同行經驗等措施可降低新技術風險。

(1) T形軟體開發

在專案開發早期,開發小組應該建立系統的架構,解決關鍵技術難題、開發系統的基礎構件,並對系統所需要應用的技術做深度探索。例如:基於JavaEE5構建全國聯網售票系統,涉及到分散式事務處理、海量資料儲存、異構平臺互連等關鍵問題,應該優先處理這些問題;對開發所涉及到的EJB3、JSF、JBoss
Seam、Eclipse RCP等技術,要做深度探索。

圖1 在第一階段以“T”形開發系統骨架[2]

越是技術複雜度高的專案,就越應該早地處理技術難題。如果在專案開發的中期或後期才發現架構有問題或是關鍵技術難題不能解決,則為時已晚。

(2) 充分論證

新技術開發是探索性很強的工作,潛在著許多失敗的風險。在可行性分析階段,要廣泛蒐集相關資訊,設計多種可行方案,進行充分論證。在制定決策時,情報的數量和質量致關重要。掌握的資訊越多、越準確,才能作出正確的的決策,專案失敗的風險也就相對減少;反之,承擔的風險就會增大。

(3) 同行經驗

針對新技術,由於沒有經驗可借鑑,因此在探索過程中要充分利用網際網路,通過搜尋同行經驗,往往事半功倍。要充分利用世界日益平坦化的優勢,對於不能儘快解決的問題,可以先放一放,可能過不了幾天,網上就有相類似問題的解決方案了。

5.技術相容性風險
硬體產品之間、系統軟體(作業系統、中介軟體、資料庫管理系統)與主機裝置之間、系統軟體之間、應用軟體與系統軟體之間以及應用軟體之間,都可能存在相容性問題。往往系統整合的專案越複雜,相容性問題就越有可能存在。

(1) 設計先行

在做系統的總體設計方案時,務必把好相關產品的選型關,確保網路、主機、系統軟體與應用軟體之間不要存在較大的技術相容性問題。在網路平臺建設方案中,明確相關裝置的技術引數和配置要求。

(2) 售前產品測試

在做專案招投標工作時,要求投標方在售前提供產品相容性測試,以避免在專案實施過程中才暴露技術相容性問題。涉及應用軟體開發的整合專案,要在開發工作的早期,做技術相容性測試,以避免在專案開發後期才暴露技術相容性問題。

例如,我們在開發深圳市汽車客運站售票及站務聯網排程系統時,為了確保技術相容,在做硬體招標時要求小型機裝置廠商提供售前技術相容性測試工作,並將測試結果做為評標指標。在深圳市軟體測試中心對IBM、SUN、HP三家公司提供的小型機進行測試時,暴露了許多應用軟體、應用伺服器、資料庫和作業系統之間的技術相容性問題,如果這些問題在系統實施時才暴露或處理,勢必會拖延專案進度。

6.效能問題
由於先期設計不足,效能問題往往在系統切換或新系統使用一段時間後暴露。出現效能問題往往要進行大量的優化工作,甚至區域性的或全面的重新設計。無論是使用者還是開發者,誰都不希望出現效能問題。

(1) 效能規劃

在系統設計時,應做好前期做效能規劃,對可能出現效能問題的環節做到充足的估計。在做資料庫設計時,應爭取DBA參與。

另外,在技術方法方面,儘可能採取一些效能優化模式,如DTO、AJAX、延遲載入等,儘可能在開發過程中解決了效能問題。不至於到了專案後期才解決效能問題,既費錢又費時。

(2) 效能測試

在開發過程中,要重視效能測試和壓力測試,儘可能模擬現實使用環境,搭建測試平臺。另外,由於開發環境的計算機往往比生產環境的計算機配置高,在做測試時應儘量找一些配置低的機器、較小的網路頻寬進行測試。

(3) 充足的除錯時間

在專案開發計劃中,為後期效能優化留有餘地。在對系統進行效能優化後,要進行效能測試和壓力測試,可能還要做幾次迴歸測試。因此,應該留有充足的時間和人力。

7.倉促上線
在專案實施過程中,系統切換上線環節最容易出紕漏。專案好不容易開發完成了,卻在最後最後時刻功潰一匱。如果專案小,影響面窄倒不怎麼重要;如果是影響面大的專案,則千萬不可出現問題。在系統切換前,應充分考慮各種可能出現的問題,做好風險對策。

(1) 應急預案

面對各種不可預知的風險,要做好應急預案。正常執行的車站售票系統在春運、旅遊黃金週,都會做好應急預案。新系統切換時,更應該做好應急預案。應急預案中應做好最壞的打算,售票系統不能正常工作時,準備手工票就是最壞的打算。

(2) 分步切換

為了減少風險的影響,可以做系統分步切換的方案。例如:售票系統在切換時,往往用新系統售預售票,或者是用新系統售長途車站,用舊系統暫時售短程票。待新系統執行穩定後,再全面切換到新系統。針對多個使用者單位的系統切換,也可分單位進行。

(3) 交叉培訓

新舊系統切換過程中,使用者都存在適應過程。除了在切換前做好操作培訓外,還要在新舊系統切換過程中做好交叉培訓。讓使用者提前一些時間上班,讓早班的使用者在交班時培訓中班的使用者,中班的使用者培訓晚班的使用者。做好交叉培訓能夠讓系統平衡過渡。

8.可用性問題
軟體的可用性包括軟體的使用是不是高效、是否容易學習、是否容易記憶、是否令人愉快、是否不易出錯等諸多因素。往往由於軟體的可用性差,導致使用者不滿意,甚至被市場淘汰。在專案開發中應注意可用性問題,避免軟體出現可用性方面的風險。

(1) 瞭解使用者

到使用者工作現場,瞭解目標使用者使用軟體的真實目的,從使用者的角度、從使用者的立場出發,瞭解如何通過軟體系統替代使用者的業務處理流程中,最繁瑣、最容易出問題、或者是大量重複勞動的環節,讓軟體提高使用者的工作效能和效率。例如:售票系統中,使用頻度最高的介面是售票介面,售票員最關心的是錢不要出錯(多了沒收、少了要賠),因此,應收款和找餘字型的顯示應該突出、醒目;同樣,票價和到達站也應該較為突出顯示。通過快捷鍵、一鍵復位、數字小鍵盤等設計,儘量減少售票員敲擊鍵盤的次數。否則,在日發旅客流量達七、八萬人次的大型客運站,如果使用者介面設計得不好,售票員一天工作下來,手指都會敲麻木。

(2) 參與型設計

與使用者協作,讓使用者參與使用者介面的設計、評審與測試,確保使用者能夠全面地、及早地發現可用性等方面的問題,並及時糾正。

讓客戶參與設計,而不要讓客戶設計,專案經理或高階設計人員應該主導設計。

(3) 競爭性分析

通過對市場上同類競爭性產品進行分析,或者對這些產品進行實驗性測試,瞭解這些產品的使用者介面問題,從而對新系統的開發提供啟發。競爭性分析並不意味著可以剽竊別人的設計,而是通過分析競爭產品的優勢和弱點,能夠比以前的設計做得更好[5]。

(4) 一致性

如果使用者知道同樣的命令或同樣的操作總會產生同樣的效果,那麼他們在使用系統時就會更加自信,同時也鼓勵他們進行探索性學習,因為他們已經具備了使用系統新部分的基礎知識[Lewis er al.1989]。

開發團隊應遵循公司或小組制定的使用者介面標準,就可以在很多方面保持一致性,切忌不要一個系統存在多種不同的介面風格。

9.結論
在資訊系統整合專案中,風險是多種多樣的,是無處不在的。在專案管理活動中,要積極面對風險,要培養。越早識別風險、越早管理風險,就越有可能規避風險,或者在風險發生時能夠降低風險帶來的影響。特別是在專案參與方多、涉及面廣、影響面大、技術含量高的複雜專案,應加強風險管理。如果不主動駕馭風險,就會面臨風險。