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

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

在學(xué)習(xí)生產(chǎn)高質(zhì)量軟件系統(tǒng)所需要的知識之前，先回頭了解一下我們?nèi)〉昧四男┏删汀？紤]這樣一個問題：用戶是否對現(xiàn)有軟件系統(tǒng)感到滿意？答案可能是“滿意”，也可能是“不滿意”。一方面，軟件使我們比以往任何時候都能夠更快、更有效地完成任務(wù)。例如，想一下，在字處理、表格處理、電子郵件或網(wǎng)絡(luò)電話等現(xiàn)代化技術(shù)出現(xiàn)之前，人們的生活是怎樣的呢？軟件支撐著醫(yī)學(xué)在生命維持治療或生命救治方面的進(jìn)展，以及農(nóng)業(yè)、交通和其他諸多產(chǎn)業(yè)取得進(jìn)展；另外，軟件已經(jīng)使我們能夠做到以前從來不敢想象的事情，如顯微外科手術(shù)、多媒體教育、機(jī)器人等。

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

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

補(bǔ)充材料1-1 描述“bug”的術(shù)語

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

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

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

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

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

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

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

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

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

很容易找到類似的意想不到的使用方式的例子。例如，最近使用一些商業(yè)現(xiàn)貨構(gòu)件（作為節(jié)省開支的手段，而不是對軟件的定制加工）導(dǎo)致以一種原先設(shè)計(jì)者未曾設(shè)想的方式使用這些構(gòu)件的設(shè)計(jì)。許多許可協(xié)議明確地指出這種意想不到的使用方式所帶來的風(fēng)險：“因?yàn)槊恳粋€終端用戶系統(tǒng)都是定制的，并且與該軟件所使用的測試平臺不同；還因?yàn)橛脩艋驊?yīng)用設(shè)計(jì)人員將其他產(chǎn)品結(jié)合在一起，以廠商或供應(yīng)商未曾評估或未曾考慮過的方式使用該軟件，因此，用戶或應(yīng)用設(shè)計(jì)人員最終對該軟件的驗(yàn)證和確認(rèn)負(fù)責(zé)。”（Lookout Direct，未注明出版日期。）

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

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

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

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

本文僅用于學(xué)習(xí)和交流目的，不代表異步社區(qū)觀點(diǎn)。非商業(yè)轉(zhuǎn)載請注明作譯者、出處，并保留本文的原始鏈接。

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

總結(jié)

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

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。