幾年前，有乙個關於軟體開發是否可以被稱為軟體工程的大辯論，這源於一篇名為《software engineering: an idea whose time has come and gone?》的文章，作者是tom demarco。demarco認為，短命的軟體開發已經死去，這對於所謂軟體「變革」的建立並不重要。
demarco的**認為由於缺乏測量力度（和「軟體」一詞所代表得深度和廣度），軟體工程已經走向了滅亡。但是我看到的是一種截然不同的現象：軟體工程從未存在過。
首先鄭重宣告，我贊同demarco先生的主要觀點。軟體開發不是工程，因為在傳統的工程中輸出是有把握的，且可被反覆衡量和控制的。demarco的著名論據「你無法控制你不能衡量的東西」是對此理念的完美總結：如果你不能衡量你將要實施的變化的影響，那麼讓我們怎麼相信你能控制它們呢？
這一點，在我看來，正是我們不能將軟體開發稱為「工程」的首要原因：我們不能衡量將要實施的變化的影響。當然，我們可以執行單元測試，整合測試——我們能想到的所有測試，但我們依然無法準確估計當我們實施所有潛在的變化時，它們對現有系統所造成的影響範圍。我們現在根本沒有足夠的工具來做到這一點，並且據我所知，我們一直以來就沒有這樣的工具。
我認為軟體開發可以當作一門手藝。「工藝」一詞或許能夠更好地描述我們開發人員的實際工作。
工藝和工程之間的主要區別是，後者使用已經廣為人知且公認的知識來解決問題，而前者使用的是更專業的知識，懂這些知識的人不如前者那麼多，甚至這些知識可能是不成文的或並不為大眾所認同。因此，我們可以得出軟體工程一說根本不存在的觀點，因為沒有足夠普遍都接受的知識來證明它可以叫做「工程」。
那麼「軟體工程」可以存在嗎？是否有用？
軟體工程這說法是否可行？
假設將軟體開發的整個領域轉換到工程學科是可能的。然而，我們真的想要這麼做嗎？
在我看來，建立有用的軟體需要具備一定層次的藝術技能，有的形式的創造並不能用數學和工程精確地表現出來。創造力能讓我們面對從未見過的問題時，也能想出新穎的解決方案。但是如果我們不小心，它也會讓我們搬起石頭砸自己的腳。
對我而言，將軟體開發制定為工程學科會消弭大量的創造自由（當然並非全部），從而阻礙我們從多方面思考來解決當前問題。
既然這樣，那麼共享和控制所有知識是否值得我們失去一些創造的自由？我認為這不值得，哪怕上述權衡真的可以實現。軟體可用於所有基本的事情，與其說偉大的多元化思維自由是我們解決問題的阻礙，倒不如說它是福音。如果硬是將軟體塞進工程領域，那麼就會有太多的變數，太多的問題，太廣泛的問題範圍需要考慮。對所有軟體開發使用工程策略將會是一場災難。
這篇文章開頭的故事，就是乙個當我們將軟體開發與工程作比較時，常見但不正確的假設：即將軟體設計比作是蓋房子。這嚴重偏離了事實。房子是有形的，受到物理定律如重力的約束，並且我們已經擁有了上千年的築造歷史，知道如何建築適宜居住的房子。而軟體是沒有這些條件的，因此這樣的比較說好聽點是天真，說難聽點就是誤人子弟。
總之，軟體開發永遠不可能是軟體工程。
我們的專業是一門手藝，我們是工匠。軟體開發是乙個過程，作為程式設計師的我們吸取關於專案的專業資訊和設計內容，然後實施滿足客戶需求的解決方案。它是藝術，它充滿了創造性；它不是工程，它也不需要成為工程。這應該成為我們的共識。
軟體工程和軟體開發流程
人們在開發 運營 維護軟體的過程中有很多技術 做法 習慣和思想體系。軟體工程把這些相關的技術和過程統一到乙個體系中，叫 軟體開發流程 軟體開發流程的目的是為了提高軟體開發 運營 維護的效率，並提高軟體的質量 使用者滿意度 可靠性和軟體的可維護性。program data structure algo...
軟體工程 軟體開發過程
軟體工程是研究和應用如何以系統性的 規範化的 可定量的過程化方法去開發和維護軟體,以及如 何把經過時間考驗而證明正確的管理技術和當前能 夠得到的最好的技術方法結合起來。瀑布原型 增量迭代 1 問題分析定義 對實際問題進行分析定義 以便更高效的解決該問題。2 可行性研究 確定這個問題是否值得去解決，避...
軟體工程 開發模型軟體工程 開發模型
瀑布模式 螺旋模型 快速原型模式 增量模式 噴泉模型 演化模型 特點 推遲實現的觀點 質量保證 缺點 限制條件 優點 缺點 很難讓使用者確信這種演化方法的結果是可以控制的.建設週期長,而軟體技術發展比較快,所以經常出現軟體開發完畢後,和當前的技術水平有了較大的差距,無法滿足當前使用者需求.核心 在於...