1.4 軟件工程與軟件可靠性

軟件是新經濟的使能因素和驅動器。自20世紀60年代末起，隨著微電子技術的發展，計算機硬件的性能價格比和質量穩步提高，相應的計算機軟件逐步變為以計算機為基礎的系統的核心部件。隨著計算機應用領域的不斷擴大，對軟件的需求不斷增多，軟件數量急劇增長，軟件復雜度和規模越來越大，軟件需求日益繁復，這些都使得手工作坊式的軟件開發方法難以應對軟件的開發任務，同時導致軟件研制費用在整個系統研制費用中所占比例越來越大，軟件開發成本越來越高，軟件維護難度越來越大，軟件研制和軟件可靠性暴露出來的問題越來越突出。例如，進度計劃和成本估算往往很不準確；軟件無文檔或文檔不適當；用戶往往對交付的系統不滿意；軟件質量常被懷疑；軟件常常是不可維護的等。這種由軟件的開發和生產仍停留在手工作坊方式致使出現的開發和生產的軟件產品質量不高、生產率過低、資金大量浪費、進度無法保證的局面，也使得軟件成為計算機發展的關鍵因素，從而導致了所謂的“軟件危機”。軟件危機是指在軟件的研制和維護中所遇到的一系列嚴重的問題，通常來說包括如何開發軟件，怎樣才能滿足對軟件的日益增長的需求，如何維護數量不斷增多的已有軟件等。軟件危機無疑與軟件本身的特性有關。軟件是邏輯的系統部件而不是物理的系統部件，軟件的維護往往意味著要修改設計，而不是簡單地進行備件替換。產生軟件危機的主要原因就是采用不正確的方法進行軟件的研制和維護。據報道，20世紀最后十年里，計算機軟件故障已成為導致系統癱瘓的主要原因，為了擺脫軟件危機所造成的困境，保證開發出優質、高效、低成本的軟件產品，迫切需要采取一系列措施來提高軟件質量。為此，軟件工程這一工程技術學科應運而生。1968年在聯邦德國Garmush召開的計算機軟件技術、管理和維護討論會上，首次以“軟件工程”一詞來標志會議主題。也是在這次會議上，軟件工程作為一門獨立的學科正式誕生，它融合了各個學科的知識和技術，如計算機科學、工程管理、界面設計和知識發現等，其目的是為軟件開發過程建立具有良好定義的工程化原理，以便能夠經濟地獲得可以在實際機器上有效運行的可依賴的軟件。軟件工程關注軟件的設計、開發和文檔化。此后，這一術語很快為科技界所接受。

1.4.1 軟件工程的內涵及目標

軟件工程過程是指為獲得軟件產品，在軟件工具的支持下由軟件工程師完成的一系列軟件工程活動，包括以下四方面。

第一，P（Plan）——軟件規格說明。規定軟件的功能及其運行時的限制。

第二，D（Do）——軟件開發。開發出滿足軟件規格說明的軟件。

第三，C（Check）——軟件確認。確認開發的軟件能夠滿足用戶需求。

第四，A（Action）——軟件演進。在軟件運行過程中不斷改進軟件以滿足用戶新需求。

從軟件開發的觀點看，軟件工程就是使用適當的資源（包括人員、軟硬件資源、時間等），為開發軟件進行的一組開發活動，在活動結束時輸入（用戶需求）轉化為輸出（滿足用戶需求的軟件產品）。

將科學的軟件工程方法應用于軟件生命周期的全過程，可達到以下軟件工程的基本目標。

第一，得到一種定義良好的方法學，該方法學是面向包括計劃、開發和維護等階段的軟件生命周期的。

第二，得到一組可以預測的里程碑，在整個軟件生命周期，每隔一定時間可以對它們進行評審。

第三，得到一組確定的軟件成分，它對軟件生命周期的每一步建立文檔資料，并且具有按步顯示軌跡的能力。

1.4.2 軟件需求工程及需求抽取

到20世紀80年代中期，逐步形成了軟件工程的子領域——需求工程。需求工程過程是發現、記錄和管理計算機系統需求的過程。其目標是盡可能產生一組完整的、一致的、相關的、能夠反映用戶真實需求的系統需求。進入20世紀90年代后，需求工程成為軟件界研究的重點之一。從1993年起，每兩年舉辦一次需求工程國際研討會（the International Symposium on Requirements Engineering，ISRE）。從1994年起，每兩年舉辦一次需求工程國際會議（the International Conference on Requirements Engineering，ICRE）。1996年，Springer-Verlag發行新的刊物——Requirements Engineering。2002年，ISRE和ICRE合并為需求工程國際聯合大會（the Joint International Requirements Engineering Conference，Re’02）。

需求工程問題無疑是當前軟件工程中的關鍵問題，由美國Standish Group于1995年開始進行的一項調查的結果就足以看出這一點。在這項調查中，研究人員對全國范圍內的8000個軟件項目進行跟蹤調查，結果表明，從總體上說，項目的成功率只有16.2%，有1/3的項目沒能完成，而在完成的2/3的項目中，又有1/2的項目沒有成功實施。未完成和未成功實施的項目所消耗的經費平均超出預定經費189%，所消耗的時間平均超出規定時間222%，所消耗的經費和時間遠遠超出了預算或計劃。根據這些統計數據估計，當時美國的公司和政府代理在被取消的項目上白白花費了近81億美元。研究人員仔細分析失敗原因后發現，與需求工程相關的原因占45%，而其中缺乏最終用戶的參與及不完整的需求又是兩大首要原因，各占13%和12%。此外，美國麻省理工學院系統與軟件安全性項目組的研究人員通過對大量與軟件相關的事故進行統計分析發現，幾乎所有與軟件相關的事故都涉及軟件需求問題。

從本質上說，軟件開發由若干知識密集型活動組成，其中最難以建模的過程便是需求抽取。因此，需求抽取被認為是軟件開發中最為關鍵的知識密集型活動。需求抽取在傳統的軟件開發過程中扮演了重要角色，這是因為需求定義和構建是需求規約的基礎，并可作為后續設計和編碼的依據。隨著軟件系統規模的擴大，需求抽取與定義在整個軟件生命周期中的作用越來越重要，甚至直接關系到軟件開發的成功與否。人們逐漸認識到需求抽取活動不再僅發生在軟件開發的最初階段，而是貫穿軟件開發的整個生命周期。

從總體上說，需求抽取應完成如下四方面任務。

第一，理解應用領域。應用領域知識是系統將要運行于其中的領域的一般性知識。

第二，理解問題域。根據一般性領域知識發現目前解決方案中的問題，也就是定位待開發系統將要解決的特定領域問題。

第三，理解物理世界運作流程。軟件加強型系統中的軟件的作用一般來說都是使系統能更好地運作，有更好的性能，因此必須理解這些待開發軟件系統如何與整體系統的其他部分發生交互，如何對它們產生影響，以及它們融為一體后如何對提高整體系統的性能做出貢獻。

第四，理解需求相關者的需要和約束。系統如何支持需求相關者工作的特殊需要是進行需求抽取時要特別關注的，必須理解待開發系統須支持的工作流程，以及支持這些工作流程的現有系統所能起到的作用。

需求抽取不僅包括一系列對軟件系統目標和動機充分理解的活動，還包括確認系統為了實現其目標而必須滿足的需求。被抽取需求的范圍為從對易理解問題和系統的修改到對要被自動化實現的新問題的模糊理解，再到相對自由的需求。就此而言，大部分需求抽取的研究關注改善需求細節的精確性、正確性和多樣性的技術，這些技術具體如下。

確認利益相關者（Identifying Stakeholders）的技術。這項技術能夠確保與軟件相關的所有人都能參與到需求抽取過程中。

類推技術（Analogical Techniques），如Metaphors和Personas。這項技術能夠幫助利益相關者對他們的需求進行更為深入和精確的考慮。

上下文和個人需求工程技術（Contextual and Personal RE Techniques）。這項技術分析關于特定上下文、環境及個人用戶的利益相關者需求，以確保最終系統在那種環境下是適用的。

創造需求技術（Techniques for Inventing Requirements），如頭腦風暴（Brain-Storming）和創造力工作組（Creativity Workshops）。這項技術用于確認一些不重要的需求，從而使得產品更具吸引力。

反饋技術（Feedback Techniques）。這項技術使用模型、模型動畫、仿真和腳本來抽取系統早期表示的正面和負面反饋。

此外，在需求抽取過程中，模型的使用將有助于促進討論及發現和了解利益相關者需求。這類解釋模型，如用例（Use Cases）、場景（Scenarios）、企業模型（Enterprise Models）和某些策略及目標模型（Policy and Goal Models）是傾向于非正式的和直覺的，并能實現利益相關者處的早期反饋。

從字面意思上看，需求抽取就是一個簡單的信息轉換過程，即需求工程師從需求提供者那里獲得存在的信息并記錄下來。但在實際操作層面上，這個過程卻有相當的難度。一是，需求提供者一般很難清楚地勾畫出他們對待開發系統的期望；二是，不同的需求提供者可能會有不同的期望，這些期望中蘊含著沖突的需求；三是，需求的可實現性還可能受到技術上的限制；等等。同時，隨著軟件規模的不斷增大和復雜性的不斷提高，參與研發的人員日趨龐雜，軟件需求抽取過程的知識密集化趨勢愈演愈烈。這一特征在航電系統領域軟件上表現得尤為明顯，這也是由航電系統的自身特點，如結構復雜、應用面廣，具有高可靠性、高安全性要求，包含大量實時嵌入式軟件，與硬件聯系緊密，與交互環境相關等決定的。因此，如何使軟件需求抽取成為一項知識完備、知識精確的活動，從而為獲得高質量軟件奠定堅實基礎也成為業界面臨的一大難題。需要說明的是，本書的研究將主要在軟硬件綜合系統的子類——航電系統領域內進行。

1.4.3 軟件可靠性

1.4.3.1 軟件可靠性定義

可靠性是軟件的一個質量要素。關于軟件可靠性的確切含義，學術界有過長期的爭論。有人認為軟件的正確性就是可靠性，還有一些軟件工程專家認為軟件具有與硬件不同的性質，不宜將硬件可靠性的定義引申到軟件領域。經過長期的爭論和研究，1983年美國IEEE計算機協會對“軟件可靠性”一詞正式做出了如下定義。

第一，在規定的條件下，在規定的時間內，軟件不引起系統失效的概率，該概率是系統輸入和系統使用的函數，也是軟件中存在的錯誤的函數。系統輸入將確定是否會遇到已存在的錯誤（如果錯誤存在的話）。

第二，在規定的時間周期內，在所述條件下程序執行所要求的功能的能力。

這個定義隨后經美國國家標準與技術研究院批準作為美國國家標準。1989年我國國家標準GB/T 11457采用了這個定義。該定義表明，軟件可靠性具有定性和定量兩層含義。在強調其定量含義時，工程上常用軟件可靠度來代替軟件可靠性。

采用更簡潔的表述為，軟件可靠性是軟件產品在規定的條件下和規定的時間內完成規定功能的能力。該定義中要注意四個要素，即條件、時間、功能和能力。描述軟件可靠性要先規定前三個要素，在此前提下談該軟件的可靠性才有意義。同一個軟件，如果這三個要素不一樣，其可靠性一般也會不同。

條件是指軟件的實際運行條件，即直接與軟件運行相關的計算機系統狀態和軟件的輸入條件，統稱為外部輸入條件，也稱為操作剖面。這些條件與硬件產品的使用條件不同。

時間是指軟件的實際運行時間區間。時間區間是指時間標尺上兩個給定時刻之間的部分，時間標尺可能是連續的日歷時間，也可能是離散的周期數。

功能是指一個實體或其特征動作能實現特定目標的能力，或者動作的方式，通過此動作，系統設計可以實現一個或多個規定的性能特性。規定功能是指為提供給定的服務，產品必須具備的功能。

能力的含義就是一般詞源的給定解釋，沒有特殊的定義。與硬件一樣，用概率來表示這種能力就是軟件可靠度。

1.4.3.2 軟件可靠性工程

軟件可靠性一詞出現后近20年，研究焦點基本局限于軟件可靠性數學模型，真正的工程化應用比較少見，更談不上用軟件可靠性理論指導軟件開發。進入20世紀90年代后，局面發生變化，軟件可靠性工程一詞出現并為IT產業界所接受，表明軟件可靠性迎來了理論和應用相結合的新時代，這是一項意義重大的進展。

1988年，貝爾實驗室（AT&T）將其內部軟件可靠性系列教程命名為軟件可靠性工程教程，軟件可靠性工程從此登上了學術和工程舞臺。貝爾實驗室在解釋這個詞匯時明確說明，它不僅包括軟件可靠性模型及軟件可靠性度量，還包括應用模型和度量實現軟件可靠性管理。1990年，IEEE計算機協會成立了軟件可靠性分技術委員會，該委員會在成立的第一年就發起召開了第一屆軟件可靠性工程國際會議（International Symposium on Software Reliability Engineering，ISSRE），科技界的反應十分積極。此后這個會議每年召開一次，沿襲至今，會議的影響日益擴大，當代IT產業界的知名企業紛紛成為該會議的贊助者和積極參與者。這個事實說明IT產業界已經認識到軟件可靠性工程應用的價值。但是軟件可靠性工程一詞的準確含義仍有待權威性的標準化機構做出定義。為了幫助讀者認識和理解該詞匯，本書引用1992年貝爾實驗室對軟件可靠性工程內涵的說明。貝爾實驗室的研究人員認為針對重要軟件項目的開發應該制定一個軟件可靠性大綱，一個好的軟件可靠性大綱應當包括下列4個系列20個工作項目。

1.可行性和需求

（1）確定功能剖面。

（2）失效定義和分類。

（3）識別需方的可靠性需求。

（4）進行權衡分析。

（5）設置可靠性目標。

2.設計和實施

（1）在部件中分配可靠性需求。

（2）適應可靠性目標的工程措施。

（3）確定基于功能剖面的重點資源。

（4）進行對故障的引入和傳播的管理。

（5）進行外供軟件的可靠性測量。

3.系統測試和現場試驗

（1）確定運行剖面。

（2）進行可靠性增長測試。

（3）跟蹤測試進展。

（4）進行項目必需的附加測試。

（5）認可可靠性目標。

4.售后及維護

（1）建立必需的售后服務機構。

（2）監視現場可靠性是否滿足可靠性目標。

（3）跟蹤需方對可靠性的滿意程度。

（4）擬定軟件的改進和提高進度。

（5）擬定產品和開發過程改進指南。

由于軟件可靠性工程是為了達到軟件產品的可靠性要求而進行的一系列軟件工程活動，因此也可以認為其內涵涉及以下四方面活動和有關技術。

第一，軟件可靠性分析：進行軟件可靠性需求分析、指標分配、故障樹分析、失效模式和影響分析，以及軟件開發過程中有關軟件可靠性的特性分析等。

第二，軟件可靠性設計和實現：進行防錯設計、容錯設計、糾錯設計、故障恢復設計和軟件可靠性增長設計等。

第三，軟件可靠性測量、測試和評估：在軟件生命周期各階段進行有關軟件可靠性的設計、制造和管理方面的屬性測量，進行軟件可靠性測試、軟件可靠性預計、軟件可靠性評估和軟件可靠性驗證等。

第四，軟件可靠性管理：確定影響軟件可靠性的因素，制定必要的設計和實現準則，以及對軟件開發各階段軟件可靠性相關過程和產品的要求。依據上述第三條所述有關測量數據和分析結果控制與改進開發過程，進行風險管理（不僅要考慮安全性等技術風險，還要考慮進度和經費方面的風險），改進效費比，改進開發過程，對采購或重用的軟件進行可靠性管理等。

實施軟件可靠性工程要解決三個問題，即軟件可靠性指標的確定與分配、軟件可靠性要求的實現和軟件可靠性的驗證。

1.4.4 軟件工程與軟件可靠性的關系

軟件工程與軟件可靠性既有密切關系，又有重要區別。

第一，軟件可靠性低是造成軟件危機的重要原因之一。

軟件作為一種產品，是計算機系統的靈魂，也是許多復雜系統的神經中樞和關鍵部分。由軟件缺陷造成系統癱瘓、失效、人員傷亡和重大經濟損失的例子時有發生。1963年，在美國發射金星探測火箭的控制程序中，有一條循環語句中的“，”誤寫為“.”，僅這一點之差，就釀成發射失敗、損失達上千萬美元的事故。1996年6月4日，阿麗亞娜5型運載火箭首航，原計劃運送4顆太陽風觀察衛星到預定軌道，但因軟件引發的問題導致火箭在發射39秒后偏離軌道，從而激活了火箭的自毀裝置。后來查明事故原因是，阿麗亞娜5型運載火箭的發射系統代碼直接重用了阿麗亞娜4型運載火箭的相應代碼，而阿麗亞娜4型運載火箭的飛行條件和阿麗亞娜5型連載火箭的飛行條件截然不同。此次事故造成的損失約為3.7億美元。2011年7月23日20時30分05秒，甬溫線浙江省溫州市境內，由北京開往福州的D301次列車與由杭州開往福州的D3115次列車發生動車組列車追尾事故，造成40人死亡、172人受傷，中斷行車32小時35分鐘，直接經濟損失達19371.65萬元。“7·23”動車事故原因是溫州南站信號設備在設計上存在嚴重缺陷，遭雷擊發生故障后導致本應顯示為紅燈的區間信號機錯誤地顯示為綠燈。軟件可靠性是軟件質量的重要特性之一。軟件質量不高首先反映為軟件可靠性低從而被人們廣泛關注和重視，也自然成為人們討論軟件危機的一個熱點。

第二，軟件工程是保障軟件可靠性的基礎。

優質、高效、低成本是軟件工程的三大目標。保證和提高軟件可靠性是開展軟件可靠性活動的目標。實施軟件工程，包含保證和提高軟件可靠性這一重要的子目標。

軟件可靠性與技術、社會、經濟、文化等各種因素密切相關，即與軟件開發方法、測試策略、程序設計語言、運行環境、開發工具、參與開發項目的各類人員的能力和經驗等密切相關。因而在軟件可靠性多年的研究過程中，人們逐步認識到要確保和提高軟件可靠性，必須要求軟件行業全體人員積極自主地工作和廣泛協作。1990年前后，形成了軟件可靠性工程的概念。在美國，每年都要舉辦一屆國際軟件可靠性工程學術年會?？梢哉J為，軟件可靠性工程是預計、度量和管理以軟件為基礎的系統的可靠性，以最大限度地滿足用戶要求的應用科學。也可以認為，軟件可靠性工程是軟件工程與軟件可靠性的結合，是為保證經濟、及時地實現軟件可靠性目標而采取的系統的活動和方法。沒有軟件工程，便沒有軟件可靠性。在軟件可靠性工程中須堅持以下6條原則。

（1）系統地考慮軟件生命周期全過程。選用最適合的軟件開發方法學（如結構化方法、面向對象方法、形式化方法等）和相應的軟件生命周期模型，作為軟件開發和組織管理的統一依據。

（2）根據選定的軟件生命周期模型，制訂軟件開發計劃，認真實施，不輕易變更。

（3）加強開發過程與產品的控制，逐階段明確轉移準則，進行驗證或評審。

（4）重視人的因素，配備適當的人員，明確職責，制定獎優罰劣政策。

（5）規范開發過程，切忌隨意化，開發過程持續改進。美國卡內基梅隆大學軟件工程研究所（SEI）研制的軟件工程能力評估模型（CMM）是評估、改進軟件過程的一種科學的系統化模型。

（6）采用先進技術和工具，并且及時組織相應培訓，充分發揮先進技術和工具的作用。

第三，軟件可靠性具有專門的技術和方法。

為保證軟件可靠性，除以軟件工程為基礎，遵循軟件工程的一般規范之外，還需要某些專門的軟件可靠性技術和方法。

（1）軟件可靠性分析與設計。確定軟件可靠性指標（含總指標及其分配），進行軟件故障模式及影響分析（FMEA）和故障樹分析（FTA），進行軟件可靠性設計（如避錯、查錯、容錯設計，通常采用N文本法及恢復塊法）。

（2）軟件可靠性度量與評估。在軟件生命周期進行有關軟件可靠性設計、制造、管理的度量、評估和預計，用失效數據和軟件可靠性模型評估（或預計）軟件可靠性。

（3）軟件可靠性增長與驗證測試。設計軟件可靠性測試環境，進行軟件可靠性增長及驗證測試。

（4）軟件可靠性管理與控制。確定影響軟件可靠性的因素，利用質量數據和其他信息來控制和改進軟件開發過程，改進效費比，并對采購或重用的軟件進行管理。