未接觸軟件工程之前一直都很想學這門課程，因為覺得這門課很NB，是那些有工程師稱號的高手才擺弄的東西。但學過之后，最大的感觸卻是：軟件工程方法一定要從娃娃抓起，否則到了后面壞習慣已經養成后再回過頭來修正，那絕對是地獄般的磨難。下面就是我在近兩個月的學習中一些總結和體會，希望對后來者有所補益。由于是初學這門課程，難免淺薄和有所錯漏，還望大家多多指教。
　　軟件工程的由來
　　據說上個世紀60年代的程序員都是天才，寫程式就像寫日記一樣，吃過晚飯沒事干隨手就可以寫幾個出來玩，第二天還可以拿去賣錢。所以那時候程序員在大家眼中，跟那些搞美術，音樂的是一類的，被稱為“藝術家”。
　　但事過境遷，就像任何人都不會嫌錢多一樣，永遠都不會有人嫌CPU快的。于是，隨之而來的就是硬件的迅猛發展和越來越變態的軟件。記得以前常去同學家拷游戲，通常幾張軟盤就可以搞定，而現在的游戲，兩三張CD-ROM都算少的了。像如此龐大復雜的怪物，就算你是如何的天才，一個人肯定是搞不定的，否則，等你把程式寫出來，人家Intel連奔騰N都開發出來了。既要開發大型的軟件還要追求速度(這樣才能賺錢)，于是很自然地，合作的概念被提了出來。
　　在開始合作的初期，由于大家都習慣了當很有個性的“藝術家”，結果可想而知，一個是畢加索派的，而另一個是意大利印象派的，再加上一個畫潑墨山水畫的，要是像這樣湊出來的東西都能不出問題的話，那么Bill早就轉行了。所以，那時侯的大型軟件，據說“藍屏”比WINDOWS 98還多。
　　馬克思告訴我們，萬物都是從量變到質變的。隨著問題的不斷涌現，一些master們開始嘗試去總結經驗，并歸納了一些規范去指導軟件的分析，設計，實現，測試，維護，人員交流協作，項目預算及時限控制等方方面面，這就是軟件工程的前身。
　　軟件工程到現在已發展了30多年，可以說是相當成熟的了。現在開發軟件，據說都是一大幫人排排坐，按著一整套的規章制度來干活。于是，軟件開發成了“工程”，程序員也就淪為“工人”了。
　　最初提出問題的是Dijkstra.他于1968年寫給ACM的一封題為Goto Statement Considered Harmful 的信中，指出了GOTO語句的負面作用，并提出了解決之道，其引發的一系列效應最終帶來了軟件工程的誕生。
　　軟件工程的核心
　　無論是在上個世紀還是在現在，軟件開發所涉及的工作基本上都沒有變化，它們都起始于一個實際需要或某個靈感，然后就是分析，設計，編碼，調試，維護。這些任務以某種方式動態地結合起來就構成了軟件開發的整個過程，這就是所謂的“軟件開發周期”。
　　但對于這些工作，具體怎樣做，什么時候做，每個人都有自己的一套方式，甚至有的人有幾套方式。這樣，當幾個人合在一起干活的時候，最終的結果就只能是一片混亂。所以就需要一套規則，大家都按規則來辦事，問題就會少得多。好的規則就叫做規范，規范都是由一些master們根據經驗總結的，又經過長時間的歷練，不斷地被補充修正，可以說都是精華，按照規范來干活，對于提高軟件質量和工作效率自然大有幫助。
　　而軟件工程，說白了，就是這樣一套用于軟件的團隊開發，以提高軟件質量和程序員工作效率為目的的規范。其核心就是，對于軟件開發的5個重要組成部分：需求分析，設計，編碼，調試，維護，如何組織這5個部分的工作，以及如何完成每一個工作。簡單來說，就是對于總體的組織和對于局部的實現。
　　規范只是提供一個好的例子，以描述一種思想，具體到每一個環節怎樣實現，對于不同的公司或團體則是各有千秋，因為根本就不可能存在一套放之天下皆可行的標準。就像C++，也只是提供了一套標準，不同的編譯器都有各自的實現，對標準的支持程度也互不相同。所以，在不同的公司或團體中，盡管核心思想都是大同小異，但具體到每一個步驟，往往都是不相同的。我手上就有一份GB8567-88的文檔模板，對于那些頂多只有幾千行的小程序來說，假如真按上面的要求全寫上了，簡直就是一種折磨！據說，當前業界最權威的標準是CMM.
　　軟件開發過程的組織
　　如何組織軟件開發過程中的每一個步驟，就是軟件開發周期模型要解決的問題。
　　其實開發軟件，就像是解決一個邏輯問題。想想自己平時是怎樣寫程序的。首先是要有一個想法，即我寫的這個程序是要干什么的；然后就是對要實現的核心功能大概構思一種或多種實現方法，并從中選出一種自認為是較好的；接下來就是將涉及的各種主要或次要功能分成各個模塊；最后就是分模塊來編碼和DEBUG.在我看來，除了第一步外，其余的步驟應該是一個循環的過程。在編碼的過程中，你總是需要不斷地回過頭來修改原先的模塊設計，甚至最初選定的實現算法。例如，最簡單的情況是，你通常都會突然發現在兩個成員函數中有相同的代碼，這時，程序員的直覺告訴你，你應該為你的類再添加一個private成員函數并將公共的代碼放于其中；又或者是，你突然發現一個模塊中的某個功能具有很高的通用性，完全可以提取出來作為一個獨立的功能組件，而你也確實應該這樣做；要是倒霉一點的話，你很有可能會在最后調試的時候突然發現，你的程序跑得太慢了，連你自己都無法忍受。于是你找呀找，終于找到了80/20中的那段可惡的20，原來是用了一個O(N)的算法，這時你就得老老實實地換一個更好的算法。
　　總之，除非你是先知，否則，對于一個具有一定規模和復雜度的軟件來說，在“設計—編碼”這個過程中，實在有太多的不可預知性和變化性，你根本不可能全盤地把握住每一個細節。當然，這是建立在我現時的水平之上的觀點。我不知道是否成為高手以后會有所不同，因為我身邊沒有那樣的人。
　　既然軟件開發是一個具有不可預知性和變化性的動態的過程，那么，對其每一個步驟的組織，即周期模型，就必須包容它的這種性質。
　　現在來看一下最古老，最經典，同時也是最倍受批評的瀑布模型。
　　瀑布模型是一種線性模型，其最大的特點就是簡單直觀。它將軟件開發過程規劃為“分析—設計—編碼—測試—維護”的線性過程，也就是說，你必須首先把你的軟件要干的每一件工作都分析得徹徹底底，再對每一個模塊，每一個接口，事無巨細，都設計得非常完美，然后才開始編碼的工作，并且在編碼的時候就像在對著圖紙砌模型，根本不用再回頭作任何修改，當然，是在把所有的代碼都寫完以后才開始測試的。
　　整個過程，光想一下就覺得冒冷汗！
　　瀑布模型完全忽視了軟件開發過程的動態變化。恐怕只有那些已經發展得非常成熟，且規模不大的系統，例如：用Access做后臺，用VB畫前端的數據庫應用程序，才有瀑布模型一展拳腳的地方。
　　相比之下，現在常用的一些周期模型則更接近于人的自然思維，例如螺旋模型就是一種我比較喜歡的模型。
　　軟件開發過程的實現
　　具體到每一步的工作要怎樣完成，我前面已提到過，是非常靈活的，只要把握住大體的方向就行。在進行分析，設計，編碼，調試，維護這幾部分的工作的時候，最核心的就是文檔的編寫。文檔的作用在于以下3個方面：一是可以幫助整理思路。把要完成的目標，系統的結構，每一個模塊的功能等整理一下，然后分門別類地寫下來，這樣在開發的過程中，就有據可依，在需要回過頭來修改設計的時候，也有證可考。二是便于交流。想象一下開會時的情形。一大幫子人爭先恐后，激烈辯論，然后會終人散，思想靈感也就隨之散了，結果是開了半天會，什么也沒討論出來。這就是后來會議記錄被發明出來的原因。在腦子里的東西一多，就會散而且亂，用語言表達的時候，很容易會丟三落四，別人也很難把握住你的思想。但經過整理寫在紙上以后，則會清晰得多，無論是別人還是自己，看起來都可以一目了然。三是可以作為以后維護時的參考資料。有一句名言：“筆和紙永遠都比大腦可靠”，意思就是說，放在大腦里的東西說不準哪天就忘了，但寫在紙上的東西，只要不發生什么意外，一般是丟不了的。當過了一段時間，你需要再回過頭來修改你的程序的時候，你就會發現，你以前寫下的文檔實在太有價值了。別指望你的源代碼，對于復雜一點的程序來說，單純的源代碼幾乎會扼殺掉你所有的時間。
　　至于文檔怎樣寫，教科書上大多都是一條一條列得滿滿的，就像一些地方政府的規章制度一樣，其實大可不必，只要能滿足需要就行。如果是在公司，則每個公司大多都有一套自己內部的文檔模板，個人沒有選擇的余地。而對于像我這種業余的，寫個程序除了練練手藝，無非就是供自己和親朋好友玩玩，則根本沒必要搞得過于復雜。以下就是我自己的一份文檔模板的概要，麻雀雖小，但五臟俱全。
　　可行性分析 就是關于當前項目能不能干的分析結果。主要考慮的方面包括：是否能把這個項目開發出來；假如可以的話，預計需要多少時間，能否滿足客人的時間要求；需要多少人力和資金的投入；最重要的是，這個項目能否賺錢，能賺多少。還要對可能存在的風險進行評估，例如，萬一項目主管被車撞了要怎么辦。當然，這對于我來說毫無意義，我在這里寫上只是為了保持完整而已。
　　項目描述 這是在決定立項以后，對當前項目的一份扼要說明。必須包括以下幾個方面：(1)項目的名稱或編號；(2)對客戶方的描述；(3)對開發人員的描述；(4)工程任務的描述；(5)工程的輸入和輸出；(6)開發環境；(7)其他的附加條件。在這里，對工程任務的描述是從整體的角度來說的，例如：能對當前的象棋棋局進行分析并作出最優決策的人工智能系統。而工程的輸入輸出則可以這樣