架構雜談《十》

2022-02-01 16:21:48 字數 2712 閱讀 6257

瀑布式開發是在2023年提出的軟體開發模型,是一種較老的計算機軟體開發模式,也是典型的預見性的開發模式,在瀑布式開發中,開發嚴格遵循預先計畫的需求分析、設計、編碼、整合、測試、維護的步驟進行,步驟的成果作為衡量進度的方法。瀑布式開發最早強調系統開發應有完整的週期,且必須完成完整地經歷每個週期內的每個階段,並系統化地考量分析所設計的技術、時間與資源等。

瀑布式開發的主要問題是它嚴格分級導致自由度降低,在需求不明確並且在專案進行過程中可能有變化的情況下基本上是不可行的。

(瀑布式開發模式圖)

迭代式開發也稱迭代增量式開發,是一種與瀑布式開發相反的軟體開發過程,它彌補了瀑布式開發方式的一些弱點,有更高的成功率。在迭代式開發中,整個開發工作被組織成一系列短小的、固定長度的小專案,每次迭代都包括需求分析、設計、實現與測試。採用迭代式開發時,工作可以在需求被確定之前啟動,並在一次迭代中完成系統的一部分功能或業務,再通過客戶的反饋來細化需求,並開始新一輪的迭代。

(迭代式開發模式圖)

迭代式開發有以下的特點:

1)每次只設計和實現產品的一部分

2)一步一步地完成

3)每次設計和實現乙個階段,這叫作迭代

螺旋式開發兼顧了快速原型的迭代特徵及瀑布模型的系統化和嚴格監控,其最大的特點是引入了其他模型不具備的風險分析,使軟體在無法排除重大風險時有機會停止,以減少損失。同時,在每個迭代階段構建原型是螺旋模型用來減少風險的方法。螺旋模型更適合大型的高昂的系統級的軟體開發,一開始應用的規模很小,當專案被定義得更好、更穩定時逐漸展開。其核心在於不需要在剛開始時就把所有的事情都定義清楚,可以先定義最重要的功能去實現,然後聽取客戶的意見再進行下乙個階段,如此不斷迴圈、重複,直到得到滿意的產品。螺旋模型在很大程度上是一種風險驅動的方法體系,因為在每個階段及經常發生的迴圈之前,都必須先進行風險評估。

(螺旋模型圖)

螺旋模型具有如下的特點:

1)制定計畫:確定軟體目標,選定實施方案,搞清楚專案開發的限制條件

2)風險分析:分析、評估所選方案,考慮如何識別和消除風險

3)實施工程:實施軟體開發和驗證

敏捷軟體開發又成敏捷開發,是一種從2023年開始逐漸引起人們廣泛關注的新型軟體開發方式,具有應對快速變化的需求的軟體開發能力,相對於非敏捷開發,更強調程式設計師團隊與業務專家之間的緊密協作及面對面溝通,比單純通過書面文件溝通更有效,能更頻繁地交付新的軟體版本,使自我組織、自我約束的團隊能夠更好地適應需求的變化,也更關注軟體開發過程中人的作用。

敏捷軟體開發有如下特點:

1)首要任務是盡早地、持續地交付可評價的軟體,使得客戶滿意

2)樂於接受需求變更,即使在開發後期也是如此,敏捷軟體開發能夠駕馭需求的變化,從而為客戶贏得競爭優勢

3)頻繁交付可使用的軟體,交付的間隔越短越好,可以從幾個月縮減到幾個星期

4)在整個專案開發期間,業務人員和開發人員必須朝夕工作在一起

5)圍繞那些有推動力的人們來構建專案。給予他們所需的環境和支援,並且相信他們能夠把工作做好

6)可使用的軟體是進度的主要衡量指標

7)提倡可持續發展

8)為了增強敏捷能力,應持續關注技術上的傑出成果和良好的設計

9)簡潔,最小化那些沒有必要投入的工作量是至關重要的

10)最好的架構、需求和設計都源於自我組織的團隊

對比以上4種開發模式,總結如下:

1)瀑布式開發:在從需求到設計、從設計到編碼、從編碼到測試、從測試到提交的每個開發階段都要做到最好,特別是在前期階段設計得越完美,提交後的損失就越少。然而現在的系統很複雜且多變,所以很難在現實中應用瀑布式開發。

2)迭代式開發:不要求每個階段的任務都做到最好,可以容忍一些不足,先不去完善它,將主要功能先搭建起來,以最短的時間及最少的損失完成乙個不完美的成果直至提交,然後通過客戶或使用者的反饋,在這個不完美的成果上逐步進行完善。

3)螺旋開發:在很大程度上是一種風險驅動的方法體系,因為在每個階段及經常發生的迴圈之前,都必須先進行風險評估。

4)敏捷開發:和迭代式開發相比,兩者都強調在較短的開發周期內提交軟體,但是敏捷開發的週期可能更短且更強調隊伍中的高度協作。敏捷方法有時被誤認為是無計畫性和紀律性的方法,實際上更確切的說法是敏捷方法強調適應性而非預見性,適應性的方法主要用於快速適應需求的變化。當專案的需求有變化時,團隊能夠迅速應對新的需求 。 

在一般公司裡,採用敏捷開發和不斷迭代開發的方式較多,而且效率高、效果明顯。因為之前做的系統業務單

一、邏輯簡單、使用者量少,專案團隊的規模一般在10-30人,現在的系統要面對不同使用者的定製化開發,業務變得越來越複雜,功能越來越多,如果整個系統耦合在一起,必定會牽一髮而動全身,導致系統維護困難,同時每個公司面臨著人員的頻繁流動、系統文件不完善或多次轉手丟失等情況,以至於新來的人員很難快速上手。因而,人們開始思考如何高效地解決複雜的大型系統開發模式。

說明:

2、如有不合適的地方請反饋。綜合後更改。

架構雜談《一》

典型的單體架構分為三個層級,web層 業務邏輯層和資料儲存層,每個層的指責分別如下 將不同的模組化元件聚合後執行在通用的應用伺服器上。單體架構已經對企業級應用的整體架構進行了邏輯分層,包括了上面提到的web層 業務邏輯層和資料儲存層,不同的層級有自己的職責,並從功能型別上劃分層級,每個層級的職責單一...

架構設計雜談004 架構師

什麼是架構設師 架構師是 負責系統架構設計的人 團隊或組織 架構師主要幹什麼 架構師是技術領導,領導並負責架構設計,負責做決策 架構師可以是團隊或組織,這個時候通常會有首席架構師 架構師必須掌握足夠的技術知識 架構師必須掌握足夠的架構設計技能 架構師必須具備很好的程式設計能力,實際參與架構原型的設計...

IT雜談 十年程式設計師

知識庫 程式人生 全屏閱讀 收藏 十年程式設計師 一 2012年,終於可以和人家說,我有十年工作經驗了。幸運的是,十年後,我還在寫 十年前,促使我選擇寫程式作為一生追求的是我對寫程式的好奇以及實現功能後的成就感,但那時,在對自己未來充滿信心的同時,內心深處依然惴惴不安。縈繞心頭的烏雲是所謂30歲程式...