本節書摘來自異步社區《軟件工程（第4版?修訂版）》一書中的第1章1.2節軟件工程取得了哪些進展，作者【美】Shari Lawrence Pfleeger , 【加】Joanne M.Atlee，更多章節內容可以訪問云棲社區“異步社區”公眾號查看。

1.2 軟件工程取得了哪些進展
軟件工程（第4版?修訂版）
編寫軟件既是一門藝術也是一門科學。作為一名計算機專業的學生，深入理解這句話是非常重要的。計算機科學家和軟件工程研究人員研究的是計算機的機制，并建立起使它們具有更高生產率、更有效的理論。但同時，他們也設計計算機系統并編寫程序，執行相關任務，這是一項融合藝術、天賦和技巧的實踐性工作。在具體的系統上執行特定任務，可能會存在很多方法，但是，某一種方法可能更有效、更精確、更易于修改、更容易使用或更便于理解。任何黑客都能夠編寫代碼完成工作，但是，要寫出健壯的、易于理解和維護的并且能以最高效的方式完成工作的代碼，必須具備專業軟件工程師的技巧和洞察力。因此，軟件工程的目標就是設計和開發高質量軟件。

在學習生產高質量軟件系統所需要的知識之前，先回頭了解一下我們取得了哪些成就。考慮這樣一個問題：用戶是否對現有軟件系統感到滿意？答案可能是“滿意”，也可能是“不滿意”。一方面，軟件使我們比以往任何時候都能夠更快、更有效地完成任務。例如，想一下，在字處理、表格處理、電子郵件或網絡電話等現代化技術出現之前，人們的生活是怎樣的呢？軟件支撐著醫學在生命維持治療或生命救治方面的進展，以及農業、交通和其他諸多產業取得進展；另外，軟件已經使我們能夠做到以前從來不敢想象的事情，如顯微外科手術、多媒體教育、機器人等。

但是，軟件也不是完美無缺的，系統的功能通常并不完全符合用戶的期望。我們都聽說過系統幾乎不能運行這樣的事情。我們所有人都編寫過有故障的程序：代碼包含錯誤，但也剛好可用或足以證明一個方法的可行性。顯然，如果開發出這樣的系統交付給客戶，客戶是不能接受的。

課程項目中的錯誤和大型軟件系統中的錯誤不可同日而語。事實上，軟件故障和生產無故障軟件的困難性是文獻和閑談中經常討論的問題。有些故障僅僅是令人討厭，而有一些故障則會耗費大量的時間和金錢，甚至還有一些可能會危及生命。補充材料1-1解釋了故障、錯誤和失效之間的關系。我們在此討論幾個關于故障的例子，看一看問題出在哪里以及其中的原因是什么。

補充材料1-1 描述“bug”的術語

我們常常會談到軟件中的“bug”，根據不同的上下文，它有多種含義。“bug”既可以指解釋需求時犯的錯誤，也可以指一段代碼中的語法錯誤，還可以指由于未知因素引起系統崩潰的原因。IEEE有描述軟件產品（IEEE 1983）中“bug”的標準術語（見IEEE標準729）。

當人們在進行軟件開發活動的過程中出錯時（稱為錯誤（error）），就會出現故障（fault）。例如，設計人員可能誤解了某個需求，創建出與需求分析人員和用戶的實際意圖不相符的設計。這個設計故障是一種錯誤的編碼，可能導致其他故障，如不正確的代碼或用戶手冊中不正確的描述等。因此，單個錯誤可能產生多個故障，并且故障可能駐留在任何開發或維護的產品中。

失效（failure）是指系統違背了它應有的行為。它可能會在系統交付前或交付后被發現，也可能在測試過程中或者在運行和維護的過程中被發現。我們在第4章會看到，需求文檔可能會包含故障，所以即使系統按照需求規格說明來運行，如果它未進行應有的行為，也稱為失效。

因此，故障是系統的內部視圖，這是從開發人員的角度看待系統；而失效是系統的外部視圖，它是用戶所看到的問題。并非每一個故障都對應于一個失效，例如，如果不執行故障代碼，或者不進入某個特定狀態，那么故障就不會使代碼失效。圖1-4所示說明了失效的起源。

20世紀80年代早期，美國國家稅務局（Internal Revenue Service，IRS）雇傭Sperry公司構建一個聯邦收入所得稅表格自動處理系統。根據《華盛頓郵報》的報道，“系統……被證明難以承載當前的工作負荷，成本幾乎是預算的兩倍，必須盡快更換”（Sawyer 1985）。在1985年，還需花費額外的9千萬美元來升級Sperry公司最初價值1.03億美元的設備。另外，因為出現的問題妨礙了IRS在最后期限前及時向納稅人退稅，IRS被迫向納稅人支付4020萬美元的利息，并且要向自己的員工支付2230萬美元的加班工資。到1996年的時候，情況仍未改善。《洛杉磯時報》在3月29日報道：除了6000頁的技術文檔外，目前系統的升級仍未有整體規劃。國會議員Jim Lightfoot把這個項目稱為“因為規劃失當而正在掙扎的40億美元的慘敗”（Vartabedian 1996）。

諸如此類的情況仍然時有發生。在美國，聯邦調查局（FBI）的“三部曲”（Trilogy）項目嘗試著更新FBI的計算機系統。但其結果卻是毀滅性的：“經歷了四年多的艱苦工作，花費了5億美元，但是，據報道：‘三部曲’項目幾乎沒有改善陳舊的案例管理系統，迄今為止，該系統仍然混亂不堪，深陷于帶有綠色屏幕的大型機和大量的紙介檔案之中。”（Knorr 2005）。類似地，在英國，對“國家保健服務”信息系統的大修，耗費了兩倍的預算（Ballard 2006）。第2章將討論為什么項目計劃對于生產高質量的軟件產品是至關重要的。

多年來，公眾在日常生活中不斷被灌輸：軟件不存在問題。但里根總統提出的主動戰略防御（Strategic Defense Initiative，SDI）增強了公眾對開發無故障軟件系統的困難性的認識。報紙和雜志上一些有影響的報道（比如Jacky 1985, Parnas 1985, Rensburger 1985）描述了計算機科學界中的懷疑論的觀點。20年后，當美國國會被要求撥款來建立一個類似系統的時侯，許多計算機科學家和軟件工程師仍然認為，在編寫和測試軟件時，沒有辦法確保它具備充分的可靠性。

例如，許多軟件工程師認為反彈道導彈系統至少需要1千萬行代碼，有些人甚至估計其代碼量會高達1億行。相比較而言，支持美國航天飛機的軟件只包含300萬行代碼，包括控制發射和飛行的地面控制計算機所用的程序。1985年，航天飛機上只有10萬行代碼（Rensburger 1985）。因此，反導彈軟件系統將需要海量的代碼測試。再者，可靠性約束是無法測試的。要了解其中的原因，考慮安全攸關（safety-critical）軟件的概念。通常我們說某些事情是安全攸關的（即這些事情的失敗會對生命或健康構成威脅），則其可靠性至少應當是10?9。正如我們將在第9章中看到的那樣，這意味著系統在109小時的運行期間其失效不能超過一次。要觀察可靠性的程度，這個系統應運行至少109小時來驗證它不會失效，但是109小時是114 000多年——作為一個測試時間段來說，它實在是太長了！

我們在第9章中還將看到，當軟件設計有誤或編程有誤的時候，原本有用的技術可能會變成致命的。例如，當Therac-25（一種射線療法和X光設備）發生故障并致使幾個病人死亡的時候，醫學界變得驚恐萬狀。軟件設計人員沒有預料到會有不按操作規范使用幾個方向鍵的情況。其結果是，當需要低劑量的射線束時，軟件卻保持高劑量的設置并發出了極為集中的射線束（Leveson and Turner 1993）。

很容易找到類似的意想不到的使用方式的例子。例如，最近使用一些商業現貨構件（作為節省開支的手段，而不是對軟件的定制加工）導致以一種原先設計者未曾設想的方式使用這些構件的設計。許多許可協議明確地指出這種意想不到的使用方式所帶來的風險：“因為每一個終端用戶系統都是定制的，并且與該軟件所使用的測試平臺不同；還因為用戶或應用設計人員將其他產品結合在一起，以廠商或供應商未曾評估或未曾考慮過的方式使用該軟件，因此，用戶或應用設計人員最終對該軟件的驗證和確認負責。”（Lookout Direct，未注明出版日期。）

在整個軟件設計活動的過程中，必須考慮對系統意想不到的使用方式。至少可以用兩種方式來處理這些非正常的使用：一是通過你的想象來考慮系統可能如何被濫用（以及正確使用），二是假定系統將被濫用并設計軟件來處理這種濫用。我們將在第8章討論這些方法。

盡管許多廠商努力設計零缺陷的軟件，但事實上，大多數軟件產品都不是無故障的。市場壓力促使軟件開發人員快速交付產品，幾乎沒有時間進行完全的測試。通常，測試小組只能測試那些最有可能用到的功能，或那些最有可能危及用戶或激怒用戶的功能。基于這樣的原因，許多用戶在安裝系統的第一個版本時都很謹慎。他們知道，直到第二個版本，這些“bug”才會得到解決。此外，對已知故障進行修復有時是非常困難的，甚至重寫整個系統都要比改變現有代碼更加容易。我們將在第11章中探討軟件維護過程中所涉及的問題。

盡管在現實生活中，有些軟件取得了巨大成功并被全面接受，但是，我們生產的軟件的質量仍然有很大的改進余地。例如，缺乏質量的代價是高昂的，一個故障未被檢測到的時間越長，改正它的花費就越大。尤其是，在項目最初的分析階段改正一個錯誤，比起把系統移交給客戶后再去改正，所需成本只有后者的1/10。不幸的是，我們沒有在早期捕捉到大多數的錯誤。改正在測試和維護過程中發現的故障的一半成本，是來自于系統生命周期的更早階段所犯的錯誤。在第12章和第13章中，我們將討論評估開發活動有效性的方法，以及對過程加以改進以盡可能早地捕捉到錯誤的方法。

我們提出的一種簡單而有效的技術是使用評審和審查。許多學生習慣于自己開發和測試軟件，但是他們的測試并沒有他們想象的那么有效。例如，Fagan研究了故障的檢測方法。他發現，采用以測試數據運行程序的方法只能找出開發階段故障的1/5。然而，同行評審（由同事檢查和評論彼此的設計和代碼的過程）能夠揭示出其余4/5的故障（Fagan 1986）。因此，請你的同事來評審你的工作，軟件質量會有大幅度的提高。在后面的章節中，我們將學習如何在每個主要開發步驟之后，利用評審和審查的過程盡可能早地發現并修復故障。并且，我們將在第13章了解到如何改進審查過程。

本文僅用于學習和交流目的，不代表異步社區觀點。非商業轉載請注明作譯者、出處，并保留本文的原始鏈接。

與50位技術專家面對面20年技術見證，附贈技術全景圖

總結

以上是生活随笔為你收集整理的《软件工程（第4版?修订版）》—第1章1.2节软件工程取得了哪些进展的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。