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

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

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

篩選合適的評估人選

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

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

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

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

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

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

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

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

考慮已存在的構(gòu)架標準

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

考慮實際的測試工作量

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

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

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

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

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

結(jié)論

今天的IT行業(yè)，是按時保質(zhì)完成產(chǎn)品的激烈競爭，準確的評估是至關(guān)重要的。經(jīng)常被忽略的項目細節(jié)，會對評估造成顯著的影響。文章中談到的幾點應該與已經(jīng)成熟的評估技術(shù)綜合應用，來最大限度消減評估錯誤的可能。

關(guān)于作者

Chandan作為電子商務顧問為印度塔塔咨詢服務公司工作超過5年，他近距離參與了為遍布世界的大客戶評估，設計以及開發(fā)各種大中規(guī)模Java EE基礎上企業(yè)級應用，Chandan作為參與這些項目整個過程的一員分析了評估對開發(fā)生命周期過程中不同階段的影響。作者在印度Jalgaon工程技術(shù)學院獲得機械工程學士學位。

【?發(fā)表評論?0條?】