品才網>輔助設計與工程計算>軟件方案設計

軟件方案設計

時間：2022-07-04 02:28:21 輔助設計與工程計算我要投稿

相關推薦

軟件方案設計

　　自從1968年提出“軟件工程”概念以來，軟件開發領域對于借鑒傳統工程的原則、方法，以提高質量、降低成本的探索就從未停止過。而在這個過程中，提出了許多不同的軟件開發模型，典型的有：瀑布式，快速原型法，以及迭代式開發等。下面是小編整理的軟件方案設計，歡迎閱讀參考！

軟件方案設計

　　瀑布式模型

　　是由W.W.Royce在1970年最初提出的軟件開發模型，在瀑布模型中，開發被認為是按照需求分析，設計，實現，測試 (確認)，集成，和維護順序的進行。

　　快速原型法

　　快速原型模型的第一步是建造一個快速原型，實現客戶或未來的用戶與系統的交互，用戶或客戶對原型進行評價，進一步細化待開發軟件的需求。通過逐步調整原型使其滿足客戶的要求，開發人員可以確定客戶的真正需求是什么；第二步則在第一步的基礎上開發客戶滿意的軟件產品。

　　迭代式開發

　　在迭代式開發方法中，整個開發工作被組織為一系列的短小的、固定長度（如3周）的小項目，被稱為一系列的迭代。每一次迭代都包括了需求分析、設計、實現與測試。采用這種方法，開發工作可以在需求被完整地確定之前啟動，并在一次迭代中完成系統的一部分功能或業務邏輯的開發工作。再通過客戶的反饋來細化需求，并開始新一輪的迭代。

　　不同的開發模型，對于設計階段的工作要求也不盡相同。相對來說，瀑布式模型中對于設計文檔的粒度要求得最細，而快速原型法對于設計的要求一般來說比較弱，迭代式開發在每一階段中的設計文檔工作量都相對較少，但在軟件開發完成后，最終的設計文檔完善程度要比快速原型法的好。

　　軟件設計的總體思路

　　軟件設計的本質就是針對軟件的需求，建立模型，通過將模型映射為軟件，來解決實際問題。因此軟件設計需要解決的核心問題是建立合適的模型，使得能夠開發出滿足用戶需求的軟件產品，并具有以下特性：

　　靈活性（Flexibility）

　　有效性（Efficiency）

　　可靠性（Reliability）

　　可理解性（Understandability）

　　維護性（Maintainability）

　　重用性（Reuse-ability）

　　適應性（Adaptability）

　　可移植性（Portability）

　　可追蹤性（Traceability）

　　互操作性（Interoperability）

　　因此，軟件設計并沒有一套放之四海而皆準的方法和模板，需要我們的設計開發人員在軟件的設計開發過程中針對軟件項目的特點進行溝通和協調，整理出對軟件項目團隊的行之有效的方式，進行軟件的設計。并保障軟件設計文檔的一致性，完整性和可理解性。

　　誰來進行軟件設計

　　在我們開發人員中，有很多人這樣理解：“軟件設計文檔就是軟件架構師和設計人員的事情”，其實不然。設計文檔是整個軟件開發團隊的產出，其中有些設計文檔由架構師或者設計人員給出，有些文檔由開發人員給出。這并沒有一定的區分。

　　最佳實踐

　　我們經常聽到這樣的話：

　　“設計文檔沒有用，是用來糊弄客戶和管理層的文檔”；

　　“用來寫設計文檔的時間，我的開發早就做完了”；

　　“項目緊張，沒有時間做設計”；

　　這些言論，并不是正確的觀念，根據軟件項目的實際情況，軟件開發設計團隊可以約定設計文檔的詳細程度。項目團隊需要保障設計文檔的完整性和一致性，在項目進度緊張的情況下，軟件設計文檔可以更初略一些；在項目時間充裕的情況下，相關文檔可以更為詳盡。但是在項目開發過程中，需要軟件設計開發團隊對于設計文檔有共同的理解。

　　設計文檔分類與使用

　　通常來說，作為軟件項目，我們需要有這幾類文檔

　　需求說明文檔

　　功能設計文檔

　　系統架構說明書

　　模塊概要設計文檔

　　模塊詳細設計文檔

　　就像我之前說到的，在某個軟件團隊，對于以上的文檔的要求是可以完全不同的，在簡單項目中，可能所有類型的文檔放在一個文檔中進行說明；在復雜項目中，每一類文檔可能都要寫幾個文檔；而在最極端的情況下，可能每一類文檔都能裝訂成幾冊。因此，在我們軟件設計和開發人員心目中需要明確的是：文檔并不是我們進行設計的目標，也不是我們設計過程中額外的工作。

　　軟件設計文檔是我們在軟件設計開發過程中形成的，用來在軟件設計開發團隊內部以及與各干系人之間進行溝通的文檔，這些文檔記錄了軟件項目中的各種知識，方案的思路、以及各種決策意見。

　　下面我們就軟件設計開發過程中必須要完成的工作進行梳理，而我們需要注意到，這些需要完成的工作，在不同的開發流程模型的指導下可能有不同的時間要求，而我們需要關注的是在這個階段內需要完成的工作，以及這個階段內我們需要溝通的人員。

　　需求分析

　　需求分析是我們進行任何一個軟件項目設計開發過程中都必須要完成的工作。

　　這個工作通常與客戶一起完成。在不同的項目中，這個“客戶”可能來自真正的購買產品的用戶，使用系統的用戶，也有可能來自團隊的某個人員，如產品經理等。軟件設計開發團隊的參與成員根據項目的不同規模，則參與的人員也有所不同。原則上，設計開發人員參與的時間點越早，對于需求的理解和把握會更好。這個階段，通常需要軟件架構師參與其中。從資源優化的角度來說，開發人員不必參與需求分析，但需要理解需求。

　　需求分析的結果通常我們需要使用需求說明文檔來描述，目前主流的需求描述方法包括：用戶例圖、用戶故事等方式。這些方式有所不同的側重，其核心思想就是描述清楚用戶的使用場景。但無論采取何種方式，進行需求的描述，需求說明需要明確以下幾點：

　　所需要開發的軟件系統邊界

　　系統所有的相關及使用人員角色

　　系統關鍵的使用場景

　　系統規模、性能要求以及部署方式等非功能性需求

　　功能設計

　　功能設計與需求分析差不多同時在開展，在很多軟件項目中，對于功能設計不是特別重視。但對于某些軟件項目而言，這是一個相當重要的工作。對于主要是用戶界面的軟件項目來說，功能設計可以看作是畫出原型界面，描述使用場景，獲得用戶認可的過程。而對于沒有界面的軟件項目來說，則功能設計與需求分析的區分更為模糊。

　　參與的人員與需求分析的參與人員類似，架構師更側重于參與此類工作，并給與一些實現層面的判斷和取舍。

　　功能設計需要明確的核心是：

　　系統的行為

　　系統架構設計

　　系統架構設計是一個非常依賴于經驗的設計過程。需要根據軟件項目的特定功能需求和非功能性需求進行取舍，最終獲得一個滿足各方要求的系統架構。系統架構的不同，將很大程度上決定系統開發和維護是否能夠較為容易的適應需求變化，以及適應業務規模擴張。