在軟件開發中，可以用一個金字塔來形容從需求分析到編碼這整個過程。從中來分析整個開發過程以及開發過程中是否規範的利與弊。
金字塔從下到上依次是由需求分析、概要設計、詳細設計、編碼組成，這裏把需求分析又分成了需求和軟件需求規格說明書，如圖1所示：
圖1 規範的軟件開發金字塔
下面從下到上開始來分析規範的軟件開發金字塔。
在軟件開發中，無論你的軟件或大或小，需求分析是最重要且必不可少的，也是整個軟件開發的基礎。圖1中淺綠色部分即爲需求分析，這裏把需求分析分爲需求和軟件需求規格說明書。在實際的項目開發中，很多的項目是沒有需求規格說明書的，一方面可能項目太小，一方面對文檔的要求不夠。
需求分析是爲了明確用戶和客戶的需要是什麼，需要我們的軟件做什麼，解決什麼問題，軟件作成什麼樣子，最終達到什麼效果。這差不多也就是項目所要達到的目標。有了目標之後，我們纔開始對需要解決的問題進行詳細的分析，弄清楚問題的要求，包括需要輸入什麼數據，得到什麼結果，最後應輸出什麼，處理過程中需要遵循什麼準則等等，最後整理出軟件需求規格說明書。軟件項目屬於工程項目，而軟件需求規格說明書就相當於工程的設計效果圖，我們是通過這個設計效果圖來與客戶達成一致，也便於開發人員有一個明確的開發目標。如果缺少了這張效果圖，我們辛辛苦苦開發出來的軟件有可能最終不是客戶所需要的效果，而導致反工。
有了設計效果圖，現在就該來搭建軟件的架構、表述各模塊功能、模塊接口連接和數據傳遞的實現等各項事務了，這個階段就是概要設計，即圖1中棕色部分。在概要設計階段我們需要把系統從整體的角度按功能進行模塊劃分、建立模塊的層次結構及調用關係、確定模塊間的接口及人機界面等去進行軟件結構設計。我們還需要對數據特徵進行描述、確定數據的結構特性、以及數據庫的設計來完成數據結構的設計。通過軟件結構設計和數據結構設計完成目標系統的邏輯模型。
目標系統的邏輯模型設計好了，接下來我們就應該開始設計每個模塊的實現算法、所需的局部數據結構，對概要設計中表述的各模塊進行深入分析，對各模塊組合進行分析等，把程序的具體實現的功能、現象等描述出來。這就是詳細設計所需要我們做的事情了，圖1中的黃色部分即爲詳細設計。
有了需求、設計效果圖、邏輯模型、具體實現的描述，我們就可以根據系統的特點以及公司的人員情況來確定最後採用什麼開發語言，由哪個項目組去編碼實現。到這裏，我們的軟件開發金字塔也就基本開發完成。
圖2 不規範的軟件開發金字塔
在實際的開發過程中，無論我們是否明顯的劃分這些階段去做，我們都是潛在的按照着這樣的流程去開發的，只是一些階段，我們草草的走過了，或者是沒有留下該階段的文檔記錄，過程如同圖2。通過這些金字塔，我們還可以形象的來表現出我們需要在這些階段大概花費的時間，以及後期維護過程中可能存在的風險。
圖3 金字塔中各層級的功能
從圖3中，我們可以看到各個階段的責職，需求是客戶提出的問題，需要我們的軟件去解決的問題，解決這些問題的時候有什麼準則等等，一切都是圍繞着問題。軟件需求規格說明書是爲了解決這些問題設計出來的設計效果圖,我們用它來與客戶達成一致，客戶滿意了我們便可以進行下一步的工作。這個設計效果圖也將是指導我們的開發人員進行開發的標準，因爲它的最終效果是與客戶達成一致的，使客戶最終所想要的，我們只有按照這個標準開發出來的軟件最後才能順利的通過客戶的驗收。有了設計效果圖我們是不是就可以直接上手開始編碼了呢？我認爲還欠點火候。雖然說我們已經有了設計效果圖，但是我們對整個系統的認識還是沒有很清楚，我們還有很多模糊的地方。所以我們需要根據設計效果圖來建立一個目標系統的邏輯模型，通過這個邏輯模型來分析系統的整體架構，數據結構的設計，各個模塊的劃分，以及未來新的問題出現時對系統可能帶來的風險等等。我們只有從整體去審視這個系統，才能更好的去搭建系統的架構，使系統更穩健，代碼結構設計更合理，才能經得起那些未知的問題出現時的考驗。那麼怎麼樣才能更好的去編碼呢，我們就來對這個目標系統的邏輯模型進行詳細的設計描述。
按照整個規範的過程下來，真正編碼前所花費的時間，要比編碼的時間多得多。然而我們的工期卻是有限的，因此很多公司都把其中的很多過程都草草而過，採用的是圖2不規範的軟件開發金字塔，前期的工作花費的時間很少，大部分的時間都放在了編碼中。其實這種不規範的金字塔中的編碼過程也包含了概要設計和詳細設計，只是他們是同步進行的。
不規範的金字塔漏洞百出，存在的問題也很多，看似能很快的把系統做出來了，雖然存在很多問題，以後也可以慢慢的去修改，總之能在工期結束時能給客戶交個系統，大體的功能實現就行。然而，我們對一個軟件，所花費最多的時間在哪呢？是開發嗎？很顯然不是。我們開發出一個系統不是給了客戶就完事了，以後不用再管了，我們還要對它進行維護，對它出現的問題進行解決，我們所花費在對系統後期維護上的時間要遠遠大於開發的時間。
很明顯，我們做好了前期的工作，也與客戶達成了一致，也對系統的各個方面做好了分析，能通過整體全面的去分析系統。那麼，無論後期維護中，有什麼新需求的增加，也不會對整個系統的結構造成多大的影響。後期維護人員即使是一點都不瞭解系統的，前人也都留下了“設計效果圖”，目標系統的邏輯模型，以及系統實現的描述，很快他就能瞭解整個系統，也能給好的參與到系統的維護中去。即使有新的需求，他也能根據系統的整體架構去重新設計和開發，保證系統的整體架構，性能以及代碼結構的質量。這樣就能很大程度的降低了維護成本。
而不規範的金字塔，則把大部分的時間花在了編碼上，前期工作也就匆匆的做了一下，也沒留下多少有用的設計文檔。對系統的很多地方都是模糊的，也有可能因爲這些模糊而在編碼過程中遇到很多問題，而沒有很好的解決方案，或者解決方案只考慮了當前模塊的，忽略了系統的整體，從而又產生了別的問題，如此惡性循環下去。最終做出來的系統，很有可能還不是客戶所期望的效果，還存在很多問題和漏洞，從而產生了很多的bug。後期維護時，什麼有用的文檔也沒有留下。這樣一來，開發成本很有可能沒有降低下來，維護成本卻很大程度上增加了。
即使後期維護時纔來編寫設計文檔，雖然很大程度上利於後期開發維護，但是編寫出來的文檔或多或少都會受到已成型的系統的干擾，比如理解不夠準確，缺少一些重要的分析等等都會對後期的維護造成影響，導致編寫出來的文檔可能存在設計上的問題，導致不瞭解系統的後期維護人員在後期開發維護中造成很多不良的影響。比如華北票據系統的分公司機打票管理模塊和分公司定額票管理模塊的功能基本都是一樣的，從瀏覽器的地址欄來看，路徑是不一樣的，這兩個模塊應該是分開了單獨寫的，從實現的角度來說，這兩個模塊是可以放在一起來處理和顯示的，然而後期編寫的文檔只能按照分開的來寫，那麼如果後面再有別的類型的票據增加，增加新的模塊，功能也是差不多的，那麼按照文檔來開發，已經實現的模塊代碼只因票據類型不同而又得再寫一遍，無疑是增加了維護成本。類似於這樣的問題，其他的老系統也存在。
綜上，我們的開發過程和文檔的編寫越規範，從長遠的角度來說更利於我們的軟件產品的開發和維護，也能保障我們軟件產品的質量，從而降低開發成本和維護成本。