1.前言

參與過(guò)大型軟件項(xiàng)目的人都會(huì)認(rèn)識(shí)到許多事情都可能出錯(cuò)，一但出錯(cuò)可能給項(xiàng)目帶來(lái)危害、損失或其它不利影響。風(fēng)險(xiǎn)是在項(xiàng)目中發(fā)生的一系列事件或不利結(jié)果的可能性。軟件開(kāi)發(fā)是一項(xiàng)高風(fēng)險(xiǎn)的活動(dòng)，在項(xiàng)目開(kāi)發(fā)過(guò)程的任何一個(gè)階段都可能存在風(fēng)險(xiǎn)。采取積極的風(fēng)險(xiǎn)管理方式，可以使項(xiàng)目進(jìn)程更加平穩(wěn)，可以獲得很高的跟蹤和控制項(xiàng)目的能力，可以規(guī)避、轉(zhuǎn)移風(fēng)險(xiǎn)，或緩解風(fēng)險(xiǎn)帶來(lái)的不利影響。風(fēng)險(xiǎn)管理是對(duì)項(xiàng)目風(fēng)險(xiǎn)進(jìn)行識(shí)別、分析、應(yīng)對(duì)和監(jiān)控的過(guò)程，是項(xiàng)目管理中很重要的管理活動(dòng)，有效的實(shí)施軟件風(fēng)險(xiǎn)管理是軟件項(xiàng)目開(kāi)發(fā)工作順利完成的保證。風(fēng)險(xiǎn)管理的達(dá)成必須包括三個(gè)要素：首先，在項(xiàng)目開(kāi)發(fā)計(jì)劃中必須制定風(fēng)險(xiǎn)管理計(jì)劃；第二，在項(xiàng)目預(yù)算中必須包含解決風(fēng)險(xiǎn)所需的經(jīng)費(fèi)；第三，評(píng)估風(fēng)險(xiǎn)時(shí)，風(fēng)險(xiǎn)的影響也必須納入項(xiàng)目計(jì)劃中。

下面軟件開(kāi)發(fā)過(guò)程中經(jīng)常發(fā)生的風(fēng)險(xiǎn)，談?wù)勎覀儾扇〉念A(yù)防措施。

2.需求不明確

需求不明確是軟件開(kāi)發(fā)過(guò)程中經(jīng)常可能遇到的問(wèn)題，這類問(wèn)題往往表現(xiàn)在需求范圍未界定、需求未細(xì)化、需求描述不清楚、需求遺漏、需求互相矛盾等多個(gè)方面。在軟件開(kāi)發(fā)過(guò)程的生命周期各階段中，需求不明確所造成的浪費(fèi)是大的，必須盡早盡可能解決。確定用戶需求是件非常困難的事情，我們常常從以下幾個(gè)方面著手處理需求不明確問(wèn)題：

(1) 讓用戶參與開(kāi)發(fā)

提供一個(gè)協(xié)作開(kāi)發(fā)環(huán)境，讓用戶參與開(kāi)發(fā)過(guò)程。如果條件不允許，至少應(yīng)該在每次迭代的需求分析和系統(tǒng)測(cè)試階段，讓客戶能夠參與開(kāi)發(fā)。

在選擇參與開(kāi)發(fā)過(guò)程的用戶時(shí)，一方面，要盡可能爭(zhēng)取精通業(yè)務(wù)或計(jì)算機(jī)技術(shù)的用戶參與。另一方面，如果開(kāi)發(fā)的產(chǎn)品要在不同規(guī)模、不同類型的企業(yè)應(yīng)用，應(yīng)該選擇具有代表性的用戶參與。

僅僅讓用戶參與是不夠的，應(yīng)該采取一定的激勵(lì)措施，提高用戶參與的積極性。

(2) 開(kāi)發(fā)用戶界面原型

用戶通常不善于精確描述自己的業(yè)務(wù)需求，系統(tǒng)分析員需要借助白板、白紙等溝通方式，幫助用戶清楚表述需求。然后，開(kāi)發(fā)一個(gè)用戶界面原型，以便用戶確認(rèn)需求。用戶界面原型的作用僅僅是收集用戶需求，不應(yīng)該再作它用，也不要給用戶造成系統(tǒng)快要實(shí)現(xiàn)的錯(cuò)覺(jué)。

(3) 需求討論會(huì)議

對(duì)于用戶分布廣、用戶量大的項(xiàng)目，要全面收集用戶需求，往往很困難，通常采取需求研計(jì)會(huì)議方式進(jìn)行需求確認(rèn)。通過(guò)在會(huì)議前幾周調(diào)查各地、各部門用戶需求意見(jiàn)，然后集中各地或各部門的用戶代表，舉辦一次需求研討會(huì)，通過(guò)會(huì)議方式收集需求。本方法適合于具有一定信息系統(tǒng)使用經(jīng)驗(yàn)的用戶。

(4) 強(qiáng)化需求分析與評(píng)審

首先，需求分析是項(xiàng)目成功的基礎(chǔ)，需要引起足夠的重視，并分配充足的時(shí)間和人力，要讓有經(jīng)驗(yàn)的系統(tǒng)分析員負(fù)責(zé)，切忌讓項(xiàng)目新手或程序員負(fù)責(zé)。其次，要進(jìn)行需求評(píng)審，盡可能讓用戶參與需求評(píng)審，不要讓需求評(píng)審流于行式。第三，也是重要的一點(diǎn)，通過(guò)評(píng)審的需求規(guī)格說(shuō)明書，要讓用戶方簽字，并作為項(xiàng)目合同的附件，對(duì)雙方都具有約束力。在公司內(nèi)部要將通過(guò)評(píng)審的需求規(guī)格說(shuō)明書，納入配置管理。

3.項(xiàng)目缺少可見(jiàn)性

當(dāng)一個(gè)項(xiàng)目經(jīng)理或一名開(kāi)發(fā)者說(shuō)已經(jīng)完成了80%的任務(wù)，您必須保持審慎的態(tài)度。因?yàn)槭Ｏ碌?0%可能還需要80%的時(shí)間，甚至永遠(yuǎn)都不能完成[1]。軟件開(kāi)發(fā)項(xiàng)目，往往在項(xiàng)目進(jìn)度和軟件質(zhì)量方面缺少可見(jiàn)性，項(xiàng)目越缺少可見(jiàn)性，項(xiàng)目越難以控制，項(xiàng)目越有可能失敗。我們可以通過(guò)迭代開(kāi)發(fā)、技術(shù)評(píng)審、持續(xù)集成來(lái)增強(qiáng)項(xiàng)目的可見(jiàn)性。

(1) 迭代開(kāi)發(fā)

采用迭代的開(kāi)發(fā)模型，將產(chǎn)品的交付過(guò)程分為多個(gè)階段，按照功能遞增式交付。以下是一些典型的迭代：

一次簡(jiǎn)短的先期迭代，以建立規(guī)模和前景并確定商業(yè)理由；

一次精化迭代，其間將為穩(wěn)定的構(gòu)架劃定基線；

一次構(gòu)建迭代，其間將實(shí)現(xiàn)用例并充實(shí)構(gòu)架；

幾次產(chǎn)品化迭代，將產(chǎn)品轉(zhuǎn)移到用戶群。

每次迭代，都要充分接收用戶的評(píng)審意見(jiàn)，以便為自我糾正。漸近式的功能交付，有利于降低開(kāi)發(fā)人員的壓力，增加用戶的滿意度，有利于增強(qiáng)項(xiàng)目的可見(jiàn)性，是好的進(jìn)展報(bào)告。

(2) 技術(shù)評(píng)審

技術(shù)評(píng)審是確保軟件質(zhì)量的重要環(huán)節(jié)，技術(shù)評(píng)審包括代碼走查、會(huì)議評(píng)審和同行專家評(píng)審。代碼走審可以是開(kāi)發(fā)人員之間的交叉審查，或者是高級(jí)開(kāi)發(fā)人員對(duì)普通開(kāi)發(fā)人員的審查；會(huì)議評(píng)審一般應(yīng)至少每?jī)芍苓M(jìn)行一次，每次評(píng)審時(shí)間不宜太長(zhǎng)；同行專家評(píng)審包括技術(shù)和業(yè)務(wù)兩個(gè)方面的專家，經(jīng)常性地讓精通業(yè)務(wù)的用戶專家參與項(xiàng)目評(píng)審，是項(xiàng)目成功的重要保證。

另外，充分利用質(zhì)量審查的工具軟件，也有利于提高代碼質(zhì)量。例如：在Eclipse開(kāi)發(fā)環(huán)境中，可以集成Findbug、Checkstyle、PMD插件檢查代碼編寫質(zhì)量。