範文齋

位置:首頁 > 行業範文 > 工程

軟件方案設計

工程4.19K

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

軟件方案設計

  瀑布式模型

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

  快速原型法

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

  迭代式開發

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

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

  軟件設計的總體思路

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

靈活性(Flexibility)

有效性(Efficiency)

可靠性(Reliability)

可理解性(Understandability)

維護性(Maintainability)

重用性(Reuse-ability)

適應性(Adaptability)

可移植性(Portability)

可追蹤性(Traceability)

互操作性(Interoperability)

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

  誰來進行軟件設計

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

  最佳實踐

我們經常聽到這樣的話:

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

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

“項目緊張,沒有時間做設計”;

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

  設計文檔分類與使用

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

需求說明文檔

功能設計文檔

系統架構說明書

模塊概要設計文檔

模塊詳細設計文檔

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

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

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

  需求分析

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

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

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

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

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

系統關鍵的使用場景

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

  功能設計

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

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

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

系統的行爲

系統架構設計

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

架構設計工作中,用戶參與程度很低。軟件開發團隊中的需求人員參與程度很低,但團隊中的所有核心設計和開發人員都應該參與其中,並達成一致意見。

架構設計的主要成果,是將系統的不同視圖予以呈現,並使之落實到開發中:

  系統開發視圖及技術路線選擇

系統邏輯視圖

系統部署視圖

系統模塊視圖

系統的領域模型

在軟件開發過程中,系統的架構不是一成不變的,隨着設計人員和開發人員對於系統的理解不斷深入,系統的架構也會發生演化。在軟件項目中,架構設計是開發團隊溝通的統一語言,設計文檔必須要隨着系統的變化進行更新,保障開發團隊對於系統的理解和溝通的一致性。

  模塊/子系統概要設計

模塊/子系統的概要設計,由架構師參與,核心設計和開發人員負責的方式進行。

在概要設計工作中,我們需要在架構確定的開發路線的指導下,完成模塊功能實現的關鍵設計工作。在概要設計階段,需要關注於模塊的核心功能和難點進行設計。這個過程中更多推薦的採用UML來進行概要設計,需要進行:

  模塊實現機制設計

模塊接口設計

關鍵類設計

畫出時序圖

交互圖等。

  模塊詳細設計

在瀑布式開發模型中,模塊的詳細設計會要求比較嚴格,將所有類進行詳細設計。據我所知,除了一些對於系統健壯性要求非常嚴格的軟件項目,如國防項目,金融項目還要求有詳細設計文檔之外。其他的項目大多采用其他方式來處理這樣的工作,如自動化測試等。

綜上所述,軟件設計文檔作爲軟件開發團隊的溝通、理解、知識共享的手段,具有非常重要的意義。而根據軟件團隊的規模,對於文檔上承載的信息詳細程度可以有不同程度的要求。我們軟件團隊對於*如何使用設計文檔有一個統一的理解,並堅持更新設計文檔*,這就是軟件設計的最佳實踐!

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

UML 統一建模語言

軟件工程

面向對象的編程 OOP

操作系統

數據庫原理

設計模式

溝通能力

標籤:方案設計 軟件