先來看工程，工程的第一個特點是可預見性。也就是說，在工程還沒有開始以前，已經在人們心目中有了一個具體的形象和標準，工程的目標則是去實現這個已經被設計好的東西。我們知道建筑施是工隊典型的勞動密集型產業，施工隊按照設計好的圖紙施工（用戶是房產商），按照制訂好的標準驗收，這個標準可以定得非常細致，每堵墻，每道梁，每扇窗都可以細微到毫米。而技術密集型的特點則是不可預見性，比如達芬奇在畫蒙娜麗莎以前，絕對沒有人告訴他眼睛應該畫多大，頭發應該畫多長。
軟件粗看起來很類似做房子，前期用戶提需求，建立軟件規格標準，然后可以根據軟件規格來做。但很少有軟件項目最后做出來的樣子是完全和當初寫的規格說明書上一模一樣的。大多數用戶在開發過程中或使用過程中會新提出很多更改的要求，甚至把軟件改得面目全非。這是軟件工程學很不愿意面對的一種事實，因為工程學的理論基礎是目標的可清晰預見性，而在工程中發生不可預見的變化成本非常巨大。因此傳統的軟件工程倡導前期做大量細致的需求和分析工作，企圖減少中途發生變化的可能。
而敏捷開發則是承認軟件的不可預見性，倡導努力提高應對變化的能力來降低甚至消除變化所帶來的成本。不過這是另外一個話題，以后可以專門介紹。
工程的第二個特點是可控性高。幾十年前做一棟房子的成本和現在比起來，除掉貨幣的升貶值并沒有太大的變化。而較好施工隊和較差的施工隊比起來，成產率也不會相差很多。因此做棟房子的成本一般可以估算得很精確。但是軟件不一樣，現在一個人化一個月時間就可以用ASP.NET寫一個電子商務網站，如果用十幾年前的技術，比如匯編語言，投入幾百個人都寫不出來。所以軟件的成本估算很難精確估算，如果幾天前還計劃要花好幾個人幾個月的時間來實現個比較復雜的功能，可能幾天后就突然在某個網站上下載到了已經完美實現這個功能的源代碼。而因為一個關鍵性的技術無法實現，導致整個項目全部被否決的情況也非常常見。
工程的第三個特點是強調過程管理，忽略個人因素。施工隊上的某個工人辭職了對整個工程的進展幾乎沒有什么影響，沒有哪個人是關鍵人物，隨便換誰都無所謂，哪怕全部人都走掉，完全重新換一批也沒什么影響。但是軟件不一樣，如果核心的開發人員離職，對項目有非常嚴重的影響。如果整個開發團隊走掉，對項目來說絕對是致命的。
軟件工程學一直把軟件開發劃分為兩個過程，設計過程和實施過程。這是從傳統工程行業照搬過來的，撰寫軟件規格文檔看作是設計過程，由專門的系統分析人員來完成，類似建筑設計師，只需要寫設計文檔。而把編碼看做是實施過程，由專門編碼人員來完成，類似工程施工隊。
軟件工程設計師企圖讓軟件設計文檔像建筑物的設計圖紙和說明一樣，可以清晰描述軟件的每一個具體的細節規格。其實這是一個可笑的悖論。如果文檔有能力描述每個功能的最細節業務邏輯的需求的話，其實就是源代碼（因為自然語言存在二義性，因此不存在描述嚴密邏輯的可能。而唯一能精確描述業務邏輯需求的就是源代碼，所以描述精確的業務需求的過程其實就是寫代碼）。
而建筑設計師的源代碼就是標準設計嚴密的圖紙，這個圖紙是邏輯精確嚴密的，可以交給任何一個正規施工隊來正確執行的，設計師和施工隊可以不需要任何交流。同樣，程序員寫的代碼也是邏輯精確嚴密的，可以交給任何一臺電腦來正確執行的，程序員和電腦也不需要開會談話。
你能想象一個不會畫標準建筑設計圖紙的建筑設計師嗎？同樣，我也完全無法想象一個不會寫代碼的軟件設計師。
所以，建筑設計師在軟件開發中就是程序員，而建筑施工隊在軟件開發中就是計算機。
企圖將程序員當做施工隊來進行管理是不適合的，傳統行業中對設計師的管理可能更加值得軟件企業的學習。
話說回來，軟件工程學也發展了好多年，難道完全是錯誤的嗎？沒有一點應用價值嗎？我的經驗告訴我，存在必然是合理的。軟件工程也有他的適用范圍，但是我們要加以分析才能利用，首先要看對我們自己是否合適。
我認為軟件工程的確對某些項目是適合的，但是項目要滿足以下四個特點：
◆ 軟件的規格目標是非常清晰確定的，開發過程中幾乎不會發生更改的。
◆ 實施過程中采用的所有技術都是非常熟悉的。
◆ 對穩定性的需求大大超過開發效率的。
◆ 可以不考慮成本的。
有沒有這樣的項目？有，航天飛機的自動控制系統軟件就是滿足這樣要求的工程。事實上，軟件工程誕生的背景也正是美國軍方的一些大型項目。寫軟件工程的一些大師級人物也正是這些項目的領導人。
我們是不考慮事物的變化，采用刻舟求劍的方式來蒙蔽自己的雙眼？還是仔細考察自己的特點，變通的選擇真正適合自己的東西？
文章來源于領測軟件測試網 http://www.kjueaiud.com/
