如何避免Java項目評估中的常見錯誤

如何避免Java項目評估中的常見錯誤，相信很多沒有經驗的人對此束手無策，為此本文總結了問題出現的原因和解決方法，通過這篇文章希望你能解決這個問題。

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

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

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

篩選合適的Java項目評估人選

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

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

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

考慮與外部/第三方 系統的集成

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

考慮現存的企業構件

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

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

考慮已存在的構架標準

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

考慮實際的測試工作量

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

考慮互相依賴的并行開發

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

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

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

看完上述內容，你們掌握如何避免Java項目評估中的常見錯誤的方法了嗎？如果還想學到更多技能或想了解更多相關內容，歡迎關注億速云行業資訊頻道，感謝各位的閱讀！