更新時間：2025-06-08 17:50:09
網站建設
519截至2009年，如果是從應用是否是第一次開發的層面。超過80% 的軟件應用程序都不是新的。目前，大多數應用程序都是舊應用程序或過時應用程序的替代品。因為這些應用程序已經過時，所以它們編寫的功能規范文檔常常被忽略，這些規范也已過時。然而，盡管缺少當前文檔，遺留應用程序仍包含成百上千個需要轉換為新應用程序的業務規則和算法。
因此，從2009年開始，需求分析不應只涉及新需求，還應包括遺留代碼的數據挖掘，提取隱藏的業務規則和算法。有一些工具可以做到這一點，并且有許多維護工作臺可以公開代碼并幫助提取底層業務規則。雖然明確的需求是一個值得稱贊的目標，但對于一個擁有10000個功能點的軟件應用來說，這個目標只能是意料之中的。到目前為止，筆者只觀察過一個功能點不到500個的小項目。并且應用程序的初始要求是明確且不變的。
對于大型應用程序，業務需求是動態的，不能是靜態的。許多外部事件都會改變軟件應用程序的要求，例如稅法的變化、公司結構的變化、業務流程的再造以及并購。此外，大型應用程序的開發通常需要數年時間，這使情況更加復雜。一家公司僅僅為了滿足一個軟件項目的需要而凍結所有的業務規則顯然是不現實的。最典型的情況是處理一個應用程序有10000個功能點的需求。收集和分析初始需求需要幾個月的時間。在后續的設計過程中，新增和變更需求將達到每月2%左右。最終總需求將達到初始需求的50%。在發布軟件應用程序的第一個版本之后。這些新的和變更的要求應該被終止，并且在9-12 個月后，新的和變更的要求應該被添加到后續版本中。 10000個功能點的項目，月需求變化率略小于0.5%，累計增量不超過原需求的10%。但是，最大增量可以達到200%。在設計和編碼階段，每月的需求變更平均比例在1%到3%之間，后續的變更劇會添加到以后的版本中。
同時使用JAD 會話、仔細的需求分析、需求審查和原型制作使需求過程處于技術和管理控制之下。雖然有時需要幾個月甚至幾年才能看到項目的結果，但是一個大型軟件項目的成敗在需求階段就已經知道了。成功的項目比失敗的項目更完整、更透徹地收集和分析需求。因此，成功的項目變更很少見，需求蠕變也很少見。然而，由于大多數新應用程序都是遺留應用程序的改造，因此要求應包括數據挖掘以提取遺留應用程序的底層業務規則和算法。
我們專注高端建站，小程序開發、軟件系統定制開發、BUG修復、物聯網開發、各類API接口對接開發等。十余年開發經驗，每一個項目承諾做到滿意為止，多一次對比，一定讓您多一份收獲！
