軟件開發的金字塔



 

在軟件開發中，可以用一個金字塔來形容從需求分析到編碼這整個過程。從中來分析整個開發過程以及開發過程當中是否規範的利與弊。

金字塔從下到上依次是由需求分析、概要設計、具體設計、編碼組成，這裏把需求分析又分紅了需求和軟件需求規格說明書，如圖1所看到的：

 

圖1 規範的軟件開發金字塔

如下從下到上開始來分析規範的軟件開發金字塔。

在軟件開發中，無論你的軟件或大或小，需求分析是最重要且不可缺乏的，也是整個軟件開發的基礎。圖1中淺綠色部分即爲需求分析，這裏把需求分析分爲需求和軟件需求規格說明書。在實際的項目開發中，很是多的項目是沒有需求規格說明書的，一方面可能項目過小，一方面對文檔的要求不夠。

需求分析是爲了明白用戶和客戶的需要是什麼，需要咱們的軟件作什麼，解決什麼問題，軟件做成什麼樣子，終於達到什麼效果。這差點兒相同也就是項目所要達到的目標。有了目標以後，咱們才開始對需要解決的問題進行具體的分析，弄清楚問題的要求，包含需要輸入什麼數據，獲得什麼結果，最後應輸出什麼，處理過程當中需要遵循什麼準則等等，最後整理出軟件需求規格說明書。軟件項目屬於project項目，而軟件需求規格說明書就至關於project的設計效果圖，咱們是經過這個設計效果圖來與客戶達成一致，也便於開發者有一個明白的開發目標。假設缺乏了這張效果圖，咱們辛辛苦苦開發出來的軟件有可能終於不是客戶所需要的效果，而致使反工。

有了設計效果圖，現在就該來搭建軟件的架構、表述各模塊功能、模塊接口鏈接和數據傳遞的實現等各項事務了，這個階段就是概要設計，即圖1中棕色部分。在概要設計階段咱們需要把系統從整體的角度按功能進行模塊劃分、創建模塊的層次結構及調用關係、肯定模塊間的接口及人機界面等去進行軟件結構設計。咱們還需要對數據特徵進行描寫敘述、肯定數據的結構特性、以及數據庫的設計來完畢數據結構的設計。經過軟件結構設計和數據結構設計完畢目標系統的邏輯模型。

目標系統的邏輯模型設計好了，接下來咱們就應該開始設計每個模塊的實現算法、所需的局部數據結構，對概要設計中表述的各模塊進行深刻分析，對各模塊組合進行分析等，把程序的具體實現的功能、現象等描寫敘述出來。這就是具體設計所需要咱們作的事情了，圖1中的黃色部分即爲具體設計。

有了需求、設計效果圖、邏輯模型、詳細實現的描寫敘述，咱們就可以依據系統的特色以及公司的人員狀況來肯定最後採用什麼開發語言，由哪一個項目組去編碼實現。到這裏，咱們的軟件開發金字塔也就基本開發完畢。

 

圖2 不規範的軟件開發金字塔

在實際的開發過程當中，無論咱們是否明顯的劃分這些階段去作，咱們都是潛在的依照着這種流程去開發的，僅僅是一些階段，咱們草草的走過了，或者是沒有留下該階段的文檔記錄，過程如同圖2。經過這些金字塔，咱們還可以形象的來表現出咱們需要在這些階段大概花費的時間，以及後期維護過程當中可能存在的風險。

 

圖3 金字塔中各層級的功能

從圖3中，咱們可以看到各個階段的責職，需求是客戶提出的問題，需要咱們的軟件去解決的問題，解決這些問題的時候有什麼準則等等，一切都是環繞着問題。軟件需求規格說明書是爲了解決這些問題設計出來的設計效果圖,咱們用它來與客戶達成一致，客戶愜意了咱們便可以進行下一步的工做。這個設計效果圖也將是指導咱們的開發者進行開發的標準，因爲它的終於效果是與客戶達成一致的，使客戶終於所想要的，咱們僅僅有依照這個標準開發出來的軟件最後才幹順利的經過客戶的驗收。有了設計效果圖咱們是否是就可以直接上手開始編碼了呢？我以爲還欠點火候。儘管說咱們已經有了設計效果圖，但是咱們對整個系統的認識仍是沒有很是清楚，咱們還有很是多模糊的地方。因此咱們需要依據設計效果圖來創建一個目標系統的邏輯模型，經過這個邏輯模型來分析系統的整體架構，數據結構的設計，各個模塊的劃分，以及將來新的問題出現時對系統可能帶來的風險等等。咱們僅僅有從整體去審視這個系統，才幹更好的去搭建系統的架構，使系統更穩健，代碼結構設計更合理，才幹經得起那些未知的問題出現時的考驗。那麼怎麼樣才幹更好的去編碼呢，咱們就來對這個目標系統的邏輯模型進行具體的設計描寫敘述。

依照整個規範的過程下來，真正編碼前所花費的時間，要比編碼的時間多得多。然而咱們的工期倒是有限的，所以很是多公司都把當中的很是多過程都草草而過，採用的是圖2不規範的軟件開發金字塔，前期的工做花費的時間很是少，大部分的時間都放在了編碼中。事實上這樣的不規範的金字塔中的編碼過程也包括了概要設計和具體設計，僅僅是他們是同步進行的。

不規範的金字塔漏洞百出，存在的問題也很是多，看似能很是快的把系統作出來了，儘管存在很是多問題，之後也可以慢慢的去改動，總之能在工期結束時能給客戶交個系統，大致的功能實現便可。然而，咱們對一個軟件，所花費最多的時間在哪呢？是開發嗎？很是顯然不是。咱們開發出一個系統不是給了客戶就完事了，之後不用再管了，咱們還要對它進行維護，對它出現的問題進行解決，咱們所花費在對系統後期維護上的時間要遠遠大於開發的時間。

很是明顯，咱們作好了前期的工做，也與客戶達成了一致，也對系統的各個方面作好了分析，能經過整體全面的去分析系統。那麼，無論後期維護中，有什麼新需求的添加，也不會對整個系統的結構形成多大的影響。後期維護人員即便是一點都不瞭解系統的，前人也都留下了「設計效果圖」，目標系統的邏輯模型，以及系統實現的描寫敘述，很是快他就能瞭解整個系統，也能給好的參與到系統的維護中去。即便有新的需求，他也能依據系統的整體架構去又一次設計和開發，保證系統的整體架構，性能以及代碼結構的質量。這樣就能很是大程度的減小了維護成本。

而不規範的金字塔，則把大部分的時間花在了編碼上，前期工做也就匆匆的作了一下，也沒留下多少實用的設計文檔。對系統的很是多地方都是模糊的，也有可能因爲這些模糊而在編碼過程當中遇到很是多問題，而沒有很是好的解決方式，或者解決方式僅僅考慮了當前模塊的，忽略了系統的整體，從而又產生了別的問題，如此惡性循環下去。終於作出來的系統，很是有可能還不是客戶所指望的效果，還存在很是多問題和漏洞，從而產生了很是多的bug。後期維護時，什麼實用的文檔也沒有留下。這樣一來，開發成本很是有可能沒有減小下來，維護成本卻很是大程度上添加了。

即便後期維護時纔來編寫設計文檔，儘管很是大程度上利於後期開發維護，但是編寫出來的文檔或多或少都會受到已成型的系統的干擾，比方理解不夠準確，缺乏一些重要的分析等等都會對後期的維護形成影響，致使編寫出來的文檔可能存在設計上的問題，致使不瞭解系統的後期維護人員在後期開發維護中形成很是多不良的影響。比方華北票據系統的分公司機打票管理模塊和分公司定額票管理模塊的功能基本都是同樣的，從瀏覽器的地址欄來看，路徑是不同的，這兩個模塊應該是分開了單獨寫的，從實現的角度來講，這兩個模塊是可以放在一塊兒來處理和顯示的，然然後期編寫的文檔僅僅能依照分開的來寫，那麼假設後面再有別的類型的票據添加，添加新的模塊，功能也是差點兒相同的，那麼依照文檔來開發，已經實現的模塊代碼僅僅因票據類型不一樣而又得再寫一遍，無疑是添加了維護成本。相似於這種問題，其它的老系統也存在。

綜上，咱們的開發過程和文檔的編寫越規範，從長遠的角度來講更利於咱們的軟件產品的開發和維護，也能保障咱們軟件產品的質量，從而減小開發成本和維護成本。