摘要：

軟件開發(fā)項目評估是軟件開發(fā)周期中要害又具備挑戰(zhàn)性的一步，它是計劃，進度，人員以及其他相關(guān)步驟的基礎(chǔ)。項目低估會帶來緊張的進度，高度壓力的工作環(huán)境，未可預(yù)料的資源緊缺，低質(zhì)量，項目實施延誤等風(fēng)險， 可以最大限度的破壞客戶的生意以及公司的信譽；而另一方面，帶有過多不合理泡沫的評估也會導(dǎo)致無效率的資源浪費以及引起客戶和公司之間的不信任。評估企業(yè)java項目因為技術(shù)的更新成了一個難題，本文通過幾個方面透視提供了評估企業(yè)Java項目時應(yīng)該考慮的問題

假如你是一個重要軟件項目的項目經(jīng)理，高層給你的預(yù)算已經(jīng)用完，業(yè)務(wù)對軟件的壓力一天天臨近，而CIO也已經(jīng)厭煩了一次次的進度推遲，更要命的是， 你的團隊已經(jīng)被長時間的工作和不合理的進度搞的精疲力盡。這一切聽起來是不是很耳熟？這篇文章調(diào)查了會導(dǎo)致這種困境的項目評估中常見的錯誤并提出建議進行提高。

其中的部分論點與技術(shù)無關(guān)，適用任何軟件項目，他們的共同特征是通過不同的方式來提高項目評估。

篩選合適的評估人選

在任何評估過程中,篩選合適的評估人選第一步也是最重要的一步.你需要始終明確的是由合適的人選,而并不一定是最重要的人選,來負(fù)責(zé)運作分析與評估. 除了正式的評估技術(shù)與知識,該人選同時還應(yīng)當(dāng)具備該項目的商業(yè)領(lǐng)域知識與項目所用的技術(shù)知識.一個非技術(shù)人員永遠(yuǎn)都不會明白一個構(gòu)架約束或技術(shù)抉擇在真正的開發(fā)過程中的含義是什么.

考慮項目建議采用的技術(shù),框架和工具的可用性

Java EE項目可以選擇不同的框架與工具,每一種框架都有自己的功能,限制以及學(xué)習(xí)曲線. 這些因素帶來的影響在項目進入開發(fā)階段后非常顯著. 在預(yù)備一個評估的時候,應(yīng)當(dāng)完成初級階段的調(diào)查并找出這些選擇對項目的適用性以及影響,在團隊目前以及將來的培訓(xùn)中需要適應(yīng)這些選擇.

考慮與 外部/第三方 系統(tǒng)的集成

在軟件應(yīng)用中,外部系統(tǒng)集成是一個千變?nèi)f化并經(jīng)常被低估的部分. 更經(jīng)常的事,在需求文檔中僅僅有一行陳述,系統(tǒng)應(yīng)當(dāng)使用現(xiàn)存的系統(tǒng)和API 發(fā)送/接受 數(shù)據(jù). 這部分尤其需要被小心的驗證確認(rèn), 基于系統(tǒng)細(xì)節(jié)和通訊協(xié)議的復(fù)雜性,很多后續(xù)的工作需要被計算在內(nèi). 假如和外部系統(tǒng)的通信細(xì)節(jié)”how and when”在作評估的時候不具備的話,這一部分在評估則只能作為設(shè)想處理,并且應(yīng)當(dāng)被列為在底層設(shè)計完成后需要被再評估的部分.請記住,在現(xiàn)實世界中,沒有即插即用.

考慮現(xiàn)存的企業(yè)構(gòu)件

大多數(shù)組織已經(jīng)有現(xiàn)成的信息系統(tǒng)的基礎(chǔ)構(gòu)造,一部分可以復(fù)用的企業(yè)構(gòu)件是可以并被授權(quán)使用在新系統(tǒng)中的. 為了一致性,兼容性,以及節(jié)約等不同的原因,客戶總是促進兼容.但是,重要的是需要注重到為了達(dá)到這種要求,評估中應(yīng)當(dāng)包括了解這些構(gòu)件的設(shè)計,和驗證它們在新系統(tǒng)中的可行性需要作出的努力.

舉個例子, 一個客戶可能已經(jīng)有了用戶驗證和授權(quán)框架,而需要集成到新系統(tǒng)中去.這種情況就存在潛在的”運行時的驚異”（一般指運行過程中出現(xiàn)錯誤）。原因是新的業(yè)務(wù)要求并不是由已經(jīng)存在的框架來實現(xiàn)的，而且很可能需要某些增強。另外，假如框架的某些功能與限制在評估時還沒有具備，那么這必須作為假定記入文檔。

考慮已存在的構(gòu)架標(biāo)準(zhǔn)

考慮現(xiàn)存的標(biāo)準(zhǔn)是另一個在評估經(jīng)常被忽視的方面,而且對工作造成顯著影響, 假如現(xiàn)行標(biāo)準(zhǔn)已經(jīng)具備的話很多額外工作是可以避免的. 但另一個方面,標(biāo)準(zhǔn)同樣可以在實際的設(shè)計與實施過程中帶來很多限制. 舉個例子, 一個簡單的要求,獲得企業(yè)的金融信息并顯示在屏幕上,可以簡單的在屏幕上增加一個文本區(qū)來實現(xiàn).但是,假如客戶已經(jīng)有了文檔服務(wù)器來治理整個應(yīng)用中客戶的金融信息就完全是另一回事了. 這樣你需要和文檔服務(wù)器建立通訊協(xié)議,exception處理和其他標(biāo)準(zhǔn).這是一個相當(dāng)大的工作. 你應(yīng)該在評估中把構(gòu)架標(biāo)準(zhǔn)和業(yè)務(wù)要求放到同等重要的地位.

考慮實際的測試工作量

隨著自動測試工具與框架的發(fā)展，實際測試工作量已經(jīng)與學(xué)校里古老的創(chuàng)建和執(zhí)行單元測試的情況大不相同。比如說，假如要求創(chuàng)建和運行JUnit測試案例， 和傳統(tǒng)的單元測試方法不同，額外的開發(fā)時間和學(xué)習(xí)曲線是可能的。因此，測試評估中測試的處理方式需要清楚的表明以避免任何分歧。

考慮互相依靠的并行開發(fā)

當(dāng)多個互相依靠的應(yīng)用在被同時并行開發(fā)的時候，情況就更多變了。假如應(yīng)用依靠于于正在進行的開發(fā)， 都需要被標(biāo)明。每次的交流都應(yīng)當(dāng)驗證目前的可行性，非凡注重給其他開發(fā)項目的風(fēng)險概要。比如，一個應(yīng)用必須顯示用戶的信用具體資料，而這個需要同調(diào)用企業(yè)API通過外部系統(tǒng)獲得，但這個企業(yè)APIs正在由另一個團隊開發(fā)，這個API應(yīng)該在你開發(fā)項目的時候處于完成并可用的狀態(tài)。使用基本的API調(diào)用來測試應(yīng)用然后再用實際調(diào)用來替代比直接用實際調(diào)用一步到位需要更多的時間，評估應(yīng)當(dāng)將這些依靠所產(chǎn)生的影響清楚并專業(yè)的標(biāo)明。

使用 部分-全部 的處理方法

古話說“分而治之”，在軟件評估中同樣也是這樣。將工作分成小塊然后對每個小塊列出要完成的步驟。這樣對每個步驟評估的綜合將會比把整個項目當(dāng)作一個整體來評估精確的多。