軟件應用的需求

2015-03-26 6265

分享至：

截至2009年，假如從應用是否是首次開發的層面來講。80%以上的軟件應用都不是新的。當前，大多數應用都是舊的或過時的應用的替代品。由于這些應用程序都是過時的，因此它們的書面功能規格說明文檔通常會被忽視，并且這些規格說明也是過時的。然而，雖然缺乏當前的文檔，但是舊應用卻包含數百或數千的業務規則和算法，因此需要將這些業務規則和算法轉換到新應用中。

因此，截至2009年，需求分析不應該只涉及新的需求，而且還應包括對遺留代碼進行數據挖掘，以提取隱藏的業務規則和算法。有些工具可以做到這一點，也有很多的維護工作臺可以顯示代碼，并且幫助提取潛藏的業務規則。雖然，清晰的需求是一個值得稱贊的目標，但是對于擁有10000個功能點的軟件應用來說，這個目標只能是個奢望。到目的為止，筆者只觀察到了一個小型項目，它的功能點少于500個。并且該應用的初始需求是清晰的和不變的。

對于大型應用來說，業務需求是動態的，并且不可能是一成不變的。網站制作的許多外部事件都會使軟件應用的需求發生變化，如稅法的變化、企業結構的變化、業務流程的再造以及兼并和收的等。另外，大型應用的開發一般需要幾年的時間，這使得情況變得更加復雜了。一個公司僅僅為了滿足一個軟件項目的需求而凍結其所有的業務規則，顯然是不現實的。最典型的情況是處理擁有10000個功能點應用的需求，收集和分析初始的需求將花費數個月。在隨后的設計過程中，每個月的新需求和變更需求將達到2%左右。最終的需求總量將會達到初始需求的50%。在發布了軟件應用的第一個版本之后。應該終止這些新的和變更的需求，并且在9-12個月之后，在后續的版本中添加新的需求和變更的需求。對于擁有10000個功能點的項目來說，每個月的需求變更比例稍低于0.5%，累計增量不超過原始需求10%，然而，最大的增量可以達到200%。在設計和編碼階段，每個月需求變更的平均比例在1%-3%之間，而之后的變更劇被添加到了以后的版本中了。

同時使用JAD會議、仔細的需求分析、需求審查以及原型可以使需求過程在技術和管理的控制之下。雖然有時需要數月甚至數年才能看到項目的結果，但是大型軟件項目的成敗在需求階段就已經一口了然了。成功的項目在收集和分析需求上，比失敗項目更完整、更徹底。因此，成功的項目變更很少，以及需求蔓延也很少。然而，由于大多數新應用都是遺留應用的翻新，因此需求應該包括數據挖掘，以提取遺留應用的潛在業務規則和算法。

來源聲明：

本文章系尚品中國編輯原創或采編整理，如需轉載請注明來自尚品中國。以上內容部分(包含圖片、文字)來源于網絡，如有侵權，請及時與本站聯系（010-60259772）。