在項目的開發過程中，我們或多或少都會遵循一定的模式。最常見的就是瀑布模型了（也許平時沒有注意，但你確實在遵循這個模型）。
瀑布模型的典型表現就是遵循以下順序：需求調研/分析，詳細設計/概要設計，編碼階段，測試階段，整體優化/運行維護。
遵循瀑布模型的好處是我們能夠嚴格按照軟件開發的工序順序進行，瀑布模型的好處是能夠清晰劃分軟件開發整個生命週期的各個階段，便於控制開發進度，只需要關注當前階段（當然在實際的項目管理過程中還是要全盤考慮多一點）。對於一箇中小型的系統（需求明確且清晰）來說使用該模型不失爲很好的方法。當然，遵循該模型一定要注重需求的確認，反覆確認需求尤爲重要。
瀑布模型有人說會產生大量的文檔，並將其作爲它的一項缺點，但我覺得軟件開發過程中產生較多的文檔對於一個成功的項目來說也未嘗不是件好事（當然這只是個人觀點，歡迎大家拍磚）。
但對於一個大型系統來說（幾千萬上億的投入），如何高效完成而又控制住可能產生的風險呢。敏捷開發或許能夠幫到我們，一般一個大型系統往往是由很多小的系統組成的，它可以是支撐系統，也可以是業務系統。就算是隻有一個系統，那它一定包含很多模塊（耦合度很低的）。當然既然是一個系統，那不管是小系統還是模塊之間肯定有關聯的，至於如何處理這方面的問題就不再此處討論了，後期我會單獨寫一篇文章。既然可以劃分，那我們就可以將其劃分爲單個的小系統或模塊，每個小系統或模塊可以單獨開發，這時候單獨的小系統或模塊就可以遵循瀑布模型了。
看似寫了這麼多，實際是很淺薄（往拍磚的時候多多收下留情），這篇文章後期會不斷補充更新。總的來說，遵循一個好的模型可以幫助我們提高效率，減少風險。但風險的把控更多的是靠的前期的準備和經驗的積累。