篩選合適的評估人選

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

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

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

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

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

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

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

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

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

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

　　考慮實(shí)際的測試工作量

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

　　考慮互相依賴的并行開

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

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

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

　　結(jié)論

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