軟體工程的核心是什嗎？

     我們經常做一件事情，時間做久了，忘記了當初的旨意。在軟體工程中，人們談過程、談規範、談流程改善，結果將為什麼要搞軟體工程的最初動機給忘了，舍本求末。

做任何事情，都要清楚其目標才能把事情做好。軟體工程旨在提高軟體開發的效率和軟體產品的品質，這是最基本的兩項目標。在任何時刻、做任何事情，“品質”和“生產力”都是工作的核心，也就是時時刻刻要問自己這樣一個問題——如何以低成本、高效率開發出更優秀的軟體？用通俗的語言來概括軟體工程的基本目標，那就是“多、快、好、省”四個字。

• 多——更多地實現客戶所需要的功能，產品的功能特性越強，越能滿足使用者更多的需求。
• 快——開發效率高、開發週期被縮短，項目在預期內完成或提前完成。
• 好——所開發出來的產品品質高，產品效能穩定、實用性強、可擴充性高，能切切實實滿足客戶的需求。
• 省——開發的成本低，用最小的代價開發出特定的功能。

在這4個目標中，“好”是最重要的，也就是說，品質是核心，以品質為中心，在“多、快和省”上面獲得最佳平衡。軟體工程的實施不是虛的，是實實在在的，其結果就是使軟體企業能夠開發出品質好的軟體或提供優質的軟體服務，而且開發速度快、成本低、維護容易，這也是企業所期望的。如果達到這些基本目標，就說明軟體工程在公司專屬應用程式獲得成功。

 

 

     我的新書《軟體工程導論》圍繞軟體工程最基本的核心——“品質和生產率”展開，力求通過一些具體的執行個體來說明軟體工程的思想和方法。這本書內容豐富，構思新穎，突破軟體工程圖書的傳
統架構，使整個軟體工程體系更清晰，從思想和管理出發，自然延伸到流程、方法、工具和環境，重新闡釋了軟體工程體系。而且，吸收了軟體工程的最新進展，適
應軟體即服務（SaaS）的開發模式，增加了相應的內容，符合當今軟體工程的實際需求。

    四十年前，人們就開始討論“軟體工程”這樣一個話題，但至今軟體工程依舊不是很成熟，例如今天的軟體品質水平依舊不高，軟體的開發模式還在探索之中，而這一切主要歸於軟體技術的日新月異的變化和軟體自身的複雜特性。互連網的普及將軟體技術的變化推向新的高潮，人們藉助互連網的力量可以隨時隨地溝通、協作，可以共用知識、技能和經驗，甚至可以積聚全世界的力量共同探討同一個技術主題，所有這些極大地推動軟體技術的發展。而在這同時，軟體產業也在悄悄地發生著巨大的變化，從傳統的軟體產品銷售模式向軟體服務模式轉化，軟體即服務（Software as a Service）或按需服務（On-demand service）的趨勢越來越明顯，其中最具代表性的服務就是Salesforce，每年以80%速度增長，客戶滿意度高達97%。Salesforce為中小型企業提供各種業務應用的線上服務，從銷售團隊自動化到合作夥伴關係管理、市場營銷和客戶服務，Salesforce重新定義客戶關係管理。企業不再需要部署自己的伺服器、不需要購買軟體等，只要按照自己的實際需求，訪問Salesforce.com以獲得自己所需要的業務處理功能，每個月或每年只要付出很低的服務費。軟體開發模式，也自然隨著SaaS模式誕生而正在發生巨大的變化，有必要在這關鍵時刻重新審視軟體工程的思想、方法和實踐，這也是本書寫作的主要理由。

軟體工程不僅面臨著技術突飛猛進的挑戰，還要面臨需求變化頻繁、品質難以控制的巨大挑戰。下面兩個例子，某種程度上說明了這種挑戰的嚴峻性。

 

 

 

例一：交通紅綠燈的需求變化 大家都非常熟悉街道上的紅綠燈，可以根據不同方向的車流量和人流量，進行調節，實施智能控制。但早期的紅綠燈，可不是這樣的，非常簡單，一個方向紅的時候則另一個方向綠，每隔60秒交替變化，這時用簡單的定時類比電路控制就可以了。 後來，人們覺得這樣的設計不夠人性化，中途經過十字路口的行人或駕駛員不知道要等多少時間，綠燈才會亮。所以，加上一個數字計時器，顯示剩下的等待秒數。這時，類比電路控制就必須改為數字電路，需要重新設計和實現。 再到後來，人們發現一個十字路口的兩個方向，車/人流量是不一樣的，需要調整不同方向的紅綠燈切換的間隔時間，例如一個方向是75秒而另外一個方向是25秒。而且，將來的車流量會發生變化，即紅綠燈間隔時間使用者可自行設定，這樣要求原來的數字電路或控製程序進行修改，這種改動可能很大，需要修改設計和修改實現。

 

例二：簡單又挖苦地諷刺軟體工程的現狀 (1)程式員寫出自認為沒有Bug（缺陷）的代碼。 (2)軟體測試，發現了100個Bug。 (3)程式員修改了50個Bug，並告訴測試組另外50個Bug不是Bug。 (4)在已修正的50個Bug中，測試組驗證時，發現其中20個仍然存在，同時又發現了30個新Bug。 (5)不斷重複上面的步驟⑶和步驟⑷。 (6)鑒於市場方面的壓力，為了配合當初制定的過分樂觀的發布時間表，產品還是按時上市了。 (7)使用者發現了不少問題（近百個Bug），反饋到研發部。 (8)已經領了項目獎金的程式員不知跑到哪裡去了。 (9)新組建的項目組差不多修正了全部Bug，但測試組又發現了80多個Bug。 (10)早先離開的程式員打電話給測試組，將他們挖走。 (11)公司的軟體發布更快來了，因為現在是開發人員自己來測試自己寫的程式，發現的缺陷很少。 (12)客戶發現的問題越來越多，抱怨越來越多。 (13)客戶開始減少得很快，公司很快倒閉。 (14)新的公司被組建，新進來的程式員寫出自認為沒有Bug的代碼。

 

軟體需求總是變化的，這種變化來源於客戶需求的變化，其中許多變化不是使用者驅動的而是由競爭者驅動的。許多需求的變化導致產品架構變化，原先的設計和實現不能適應這種變化，就必須重新設計和重新實現，這就是重構。軟體的反覆式開發法或重構，正是適應這種特定的需求，並日益受到重視，最終導致軟體工程思想和方法的變化。

  軟體品質的改善，也迫在眉睫，招聘大量的測試人員可以部分地解決問題，但不能徹底地解決問題，因為品質是構建出來的，而不能靠測試測出來。當軟體中存在大量的缺陷，雖然經過充分的測試，但軟體發布時漏掉的缺陷可能還會不少，而且測試、開發人員的返工引起的代價很大。所以，要真正提高品質，要將需求、設計和編碼等各項工作做好，歸納起來，做每項工作的時候，第一次就把它做對，這就是缺陷預防的思想。

  本書在交待了軟體危機、軟體過程內容、軟體工程目標和要求等基礎之上，強調建立正確的軟體工程思想，思想是萬物之源，思想會決定流程和方法。另一方面，思想需要藉助特定的方法來實現，而方法需要付諸於實踐、由實踐來檢驗。這就是本書的基本構思，從思想到方法，從方法到建模，再到軟體環境、工具，逐步向前推進，不斷揭示軟體工程的內涵。通過軟體工程的思想、方法、技術和工具的全面介紹，協助讀者瞭解完整的軟體工程體系，為將來深入地學習需求工程、軟體設計、軟體測試等課程打下堅實的基礎。

 

 

 

 

 

 

 什麼是軟體工程？