軟件工程設計師企圖讓軟件設計文檔像建筑物的設計圖紙和說明一樣，可以清晰描述軟件的每一個具體的細節規格。其實這是一個可笑的悖論。如果文檔有能力描述每個功能的最細節業務邏輯的需求的話，其實就是源代碼（因為自然語言存在二義性，因此不存在描述嚴密邏輯的可能。而唯一能精確描述業務邏輯需求的就是源代碼，所以描述精確的業務需求的過程其實就是寫代碼）。
而建筑設計師的源代碼就是 標準設計嚴密的圖紙，這個圖紙是邏輯精確嚴密的，可以交給任何一個正規施工隊來正確執行的，設計師和施工隊可以不需要任何交流。同樣， 程序員寫的代碼也是邏輯精確嚴密的，可以交給任何一臺電腦來正確執行的，程序員和電腦也不需要開會談話。
你能想象一個不會畫標準建筑設計圖紙的建筑設計師嗎？同樣，我也完全無法想象一個不會寫代碼的 軟件設計師。
所以，建筑設計師在軟件開發中就是程序員，而建筑施工隊在軟件開發中就是計算機。
企圖將程序員當做施工隊來進行管理是不適合的，傳統行業中對設計師的管理可能更加值得軟件企業的學習。
話說回來，軟件工程學也發展了好多年，難道完全是錯誤的嗎？沒有一點應用價值嗎？我的經驗告訴我，存在必然是合理的。軟件工程也有他的適用范圍，但是我們要加以分析才能利用，首先要看對我們自己是否合適。
我認為軟件工程的確對某些項目是適合的，但是項目要滿足以下四個特點：
◆ 軟件的規格目標是非常清晰確定的，開發過程中幾乎不會發生更改的。
◆ 實施過程中采用的所有技術都是非常熟悉的。
◆ 對穩定性的需求大大超過開發效率的。
◆ 可以不考慮成本的。
有沒有這樣的項目？有，航天飛機的自動控制系統軟件就是滿足這樣要求的工程。事實上，軟件工程誕生的背景也正是美國軍方的一些大型項目。寫軟件工程的一些大師級人物也正是這些項目的領導人。
我們是不考慮事物的變化，采用刻舟求劍的方式來蒙蔽自己的雙眼？還是仔細考察自己的特點，變通的選擇真正適合自己的東西？
文章來源于領測軟件測試網 http://www.kjueaiud.com/
