軟件方案設計

軟件方案設計

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

　　瀑布式模型

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

　　快速原型法

　　快速原型模型的第一步是建造一個(gè)快速原型，實(shí)現客戶(hù)或未來(lái)的用戶(hù)與系統的交互，用戶(hù)或客戶(hù)對原型進(jìn)行評價(jià)，進(jìn)一步細化待開(kāi)發(fā)軟件的需求。通過(guò)逐步調整原型使其滿(mǎn)足客戶(hù)的要求，開(kāi)發(fā)人員可以確定客戶(hù)的真正需求是什么；第二步則在第一步的基礎上開(kāi)發(fā)客戶(hù)滿(mǎn)意的軟件產(chǎn)品。

　　迭代式開(kāi)發(fā)

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

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

　　軟件設計的總體思路

　　軟件設計的本質(zhì)就是針對軟件的需求，建立模型，通過(guò)將模型映射為軟件，來(lái)解決實(shí)際問(wèn)題。因此軟件設計需要解決的核心問(wèn)題是建立合適的模型，使得能夠開(kāi)發(fā)出滿(mǎn)足用戶(hù)需求的軟件產(chǎn)品，并具有以下特性：

　　靈活性（Flexibility）

　　有效性（Efficiency）

　　可靠性（Reliability）

　　可理解性（Understandability）

　　維護性（Maintainability）

　　重用性（Reuse-ability）

　　適應性（Adaptability）

　　可移植性（Portability）

　　可追蹤性（Traceability）

　　互操作性（Interoperability）

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

　　誰(shuí)來(lái)進(jìn)行軟件設計

　　在我們開(kāi)發(fā)人員中，有很多人這樣理解：“軟件設計文檔就是軟件架構師和設計人員的事情”，其實(shí)不然。設計文檔是整個(gè)軟件開(kāi)發(fā)團隊的產(chǎn)出，其中有些設計文檔由架構師或者設計人員給出，有些文檔由開(kāi)發(fā)人員給出。這并沒(méi)有一定的區分。

　　最佳實(shí)踐

　　我們經(jīng)常聽(tīng)到這樣的話(huà)：

　　“設計文檔沒(méi)有用，是用來(lái)糊弄客戶(hù)和管理層的文檔”；

　　“用來(lái)寫(xiě)設計文檔的時(shí)間，我的開(kāi)發(fā)早就做完了”；

　　“項目緊張，沒(méi)有時(shí)間做設計”；

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

　　設計文檔分類(lèi)與使用

　　通常來(lái)說(shuō)，作為軟件項目，我們需要有這幾類(lèi)文檔

　　需求說(shuō)明文檔

　　功能設計文檔

　　系統架構說(shuō)明書(shū)

　　模塊概要設計文檔

　　模塊詳細設計文檔

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

　　軟件設計文檔是我們在軟件設計開(kāi)發(fā)過(guò)程中形成的，用來(lái)在軟件設計開(kāi)發(fā)團隊內部以及與各干系人之間進(jìn)行溝通的文檔，這些文檔記錄了軟件項目中的各種知識，方案的思路、以及各種決策意見(jiàn)。

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

　　需求分析

　　需求分析是我們進(jìn)行任何一個(gè)軟件項目設計開(kāi)發(fā)過(guò)程中都必須要完成的工作。

　　這個(gè)工作通常與客戶(hù)一起完成。在不同的項目中，這個(gè)“客戶(hù)”可能來(lái)自真正的購買(mǎi)產(chǎn)品的用戶(hù)，使用系統的用戶(hù)，也有可能來(lái)自團隊的某個(gè)人員，如產(chǎn)品經(jīng)理等。軟件設計開(kāi)發(fā)團隊的參與成員根據項目的不同規模，則參與的人員也有所不同。原則上，設計開(kāi)發(fā)人員參與的時(shí)間點(diǎn)越早，對于需求的理解和把握會(huì )更好。這個(gè)階段，通常需要軟件架構師參與其中。從資源優(yōu)化的角度來(lái)說(shuō)，開(kāi)發(fā)人員不必參與需求分析，但需要理解需求。

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

　　所需要開(kāi)發(fā)的軟件系統邊界

　　系統所有的相關(guān)及使用人員角色

　　系統關(guān)鍵的使用場(chǎng)景

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

　　功能設計

　　功能設計與需求分析差不多同時(shí)在開(kāi)展，在很多軟件項目中，對于功能設計不是特別重視。但對于某些軟件項目而言，這是一個(gè)相當重要的工作。對于主要是用戶(hù)界面的軟件項目來(lái)說(shuō)，功能設計可以看作是畫(huà)出原型界面，描述使用場(chǎng)景，獲得用戶(hù)認可的過(guò)程。而對于沒(méi)有界面的軟件項目來(lái)說(shuō)，則功能設計與需求分析的區分更為模糊。

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

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

　　系統的行為

　　系統架構設計

　　系統架構設計是一個(gè)非常依賴(lài)于經(jīng)驗的設計過(guò)程。需要根據軟件項目的特定功能需求和非功能性需求進(jìn)行取舍，最終獲得一個(gè)滿(mǎn)足各方要求的系統架構。系統架構的不同，將很大程度上決定系統開(kāi)發(fā)和維護是否能夠較為容易的適應需求變化，以及適應業(yè)務(wù)規模擴張。

　　架構設計工作中，用戶(hù)參與程度很低。軟件開(kāi)發(fā)團隊中的需求人員參與程度很低，但團隊中的所有核心設計和開(kāi)發(fā)人員都應該參與其中，并達成一致意見(jiàn)。

　　架構設計的主要成果，是將系統的不同視圖予以呈現，并使之落實(shí)到開(kāi)發(fā)中：

　　系統開(kāi)發(fā)視圖及技術(shù)路線(xiàn)選擇

　　系統邏輯視圖

　　系統部署視圖

　　系統模塊視圖

　　系統的領(lǐng)域模型

　　在軟件開(kāi)發(fā)過(guò)程中，系統的架構不是一成不變的，隨著(zhù)設計人員和開(kāi)發(fā)人員對于系統的理解不斷深入，系統的架構也會(huì )發(fā)生演化。在軟件項目中，架構設計是開(kāi)發(fā)團隊溝通的統一語(yǔ)言，設計文檔必須要隨著(zhù)系統的變化進(jìn)行更新，保障開(kāi)發(fā)團隊對于系統的理解和溝通的一致性。

　　模塊/子系統概要設計

　　模塊/子系統的概要設計，由架構師參與，核心設計和開(kāi)發(fā)人員負責的方式進(jìn)行。

　　在概要設計工作中，我們需要在架構確定的開(kāi)發(fā)路線(xiàn)的指導下，完成模塊功能實(shí)現的關(guān)鍵設計工作。在概要設計階段，需要關(guān)注于模塊的核心功能和難點(diǎn)進(jìn)行設計。這個(gè)過(guò)程中更多推薦的采用UML來(lái)進(jìn)行概要設計，需要進(jìn)行：

　　模塊實(shí)現機制設計

　　模塊接口設計

　　關(guān)鍵類(lèi)設計

　　畫(huà)出時(shí)序圖

　　交互圖等。

　　模塊詳細設計

　　在瀑布式開(kāi)發(fā)模型中，模塊的詳細設計會(huì )要求比較嚴格，將所有類(lèi)進(jìn)行詳細設計。據我所知，除了一些對于系統健壯性要求非常嚴格的軟件項目，如國防項目，金融項目還要求有詳細設計文檔之外。其他的項目大多采用其他方式來(lái)處理這樣的工作，如自動(dòng)化測試等。

　　綜上所述，軟件設計文檔作為軟件開(kāi)發(fā)團隊的溝通、理解、知識共享的手段，具有非常重要的意義。而根據軟件團隊的規模，對于文檔上承載的信息詳細程度可以有不同程度的要求。我們軟件團隊對于*如何使用設計文檔有一個(gè)統一的理解，并堅持更新設計文檔*，這就是軟件設計的最佳實(shí)踐！

　　軟件設計所需要的知識與技能

　　UML 統一建模語(yǔ)言

　　軟件工程

　　面向對象的編程 OOP

　　操作系統

　　數據庫原理

　　設計模式

　　溝通能力

【軟件方案設計】相關(guān)文章：

校園招聘方案設計07-12

《祝�！方虒W(xué)方案設計07-02

祝福教學(xué)方案設計07-02

建筑方案設計步驟05-29

股權轉讓的方案設計07-20

技術(shù)方案設計原則04-25

員工培訓方案設計09-06

股權激勵方案設計07-24

教研活動(dòng)方案設計08-05

校園招聘方案設計問(wèn)題07-12