請問何謂軟體可靠度?
與硬體可靠度有何差別?
應依據何種標準發展與測試?
是否需納入FCA與PCA?
應如何在需求文件中展述有關軟體可靠度的需求?
應如何在設計文件中展述有關軟體可靠度的Traceability?
我目前正使用中華電信的MOD，ㄧ周會出問題近4次。如何確認是硬體軟體可靠度的問題?中華電信的研究單位已獲得CMMI Level-3，為何產品仍有軟體不穩的情形?

個人對可靠度的認識不是很深，也一直期望看到專家對此一問題的見解。可是兩個多月過去，等嘸人。

10/22又有朋友來信，要我到協會的網站回答下列問題：

請問何謂軟體可靠度 ? 與硬體可靠度有何差別 ?
應依據何種標準發展與測試 ?
是否需納入 FCA 與 PCA ?
應如何在需求文件中展述有關軟體可靠度的需求 ?
應如何在設計文件中展述有關軟體可靠度的 Traceability ?

因此，個人就不揣淺陋，簡單表達個人意見如下：

首先，我們要瞭解可靠度是產品眾多品質屬性中的一項，它屬於產品的非功能性需求。所以要瞭解可靠度就如同要瞭解其它的需求一樣要“由上往下”的去思考，才能掌握其要義。

吾人之所以需要一件產品或一個系統，就是要它來協助我們處理某一事務或問題，也就是產品就是我賴以處理問題的工具。然而天下任何東西都不完美的，都有其極限，都有其可能失效的時候，而我們使用的工具亦然。當我們想要使用它時，若它不能為我們所用，那麼我們必然會蒙受損失。所以於經營管理上，我們有必要於使用工具前瞭解其可靠的程度。此一可靠程度的表達方式，在以往硬體為主的情況下，通常用以下三個數字來表達。

1. 平均失效時間MTTF(mean time to failure)
2. 平均修復時間MTTR(meat time to repair)
3. 可用性(Availability) = MTTF / (MTTF + MTTR) x 100%

因為有了這樣的數據，我們才能進一步決定，再其失效時間內，我們要如何處理我們原有的問題？如果有替代的方式處理時，它的成本為何？如果沒有替代方式處理時所造成的損失為何？我們有沒有可能再提昇產品的可用性？可提高至何種程度？其成本又為何？…諸如此類的問題，只有再有了可靠度的相關數據後，才有可能做出有根據的理性決定。

在硬體的世界中，產品之所以會失效(撇開設計與製造的因素)，主要有兩大原因，一為磨損，一為材料疲勞，都是自然界物理特性所使然。所以，在硬體系統的領域常使用兩個(或以上)相同的元件互為備援，來提昇系統的可靠度。譬如：系統原本的可靠度為70%，若同時使用個原本的系統互為備援作為一個新的系統。那麼這個新系統的可靠度就可提昇到 91% ( 1- (1 - 70%) x (1 - 70%))。

然而在軟體的領域中，沒有磨損與材料疲勞的問題。造成軟體不能如預期般的運轉，是因為需求規格(SRS)、設計說明(SDD)或程式中有缺陷(fault)(或bug)。並於使用時程式執行時遇到了這些缺陷，才使得軟體失效(failure)。因此，不同的使用者對相同的軟體，可能對該軟體的可靠度有完全不同的感受。另外，軟體提抍可靠度的方式與硬體也截然不同。在對軟體可靠度有嚴苛的要求環境中(通常是要藉由軟體可靠度確保產品的安全性)，譬如：飛航管制系統…等，經常再不容出錯的地方以相同的需求規格，不同設計的模組，做平行的運算，只有當兩組(或更多)模組結果相同時，才往下繼續執行其它的步驟。否則，將不執行這些步驟。藉此來確保軟體的可靠度與安全性。

有了以上的基本認識，現在來看軟體可靠度的定義。有人將它定義成：the probability of a software system to perform its specified functions correctly over a long period of time or for different input sets under the usage environments similar to that of its target customers. 於分析軟體可靠度時，要準備 operation profiles 作為模擬客戶使用的輸入資料(個人認為這是在執行上比較困難的部份)。也要於數種可靠度模型(model)中選用一種，以做為分析軟體可靠度的方法。有關可靠度模型，我不完全瞭解，也就不多做介紹了。

現在，先就可靠度本身做一個總結，後面再對衍生的問題加以說明。可靠度是對產品的一項品質屬性所做的客觀描述，只要它是依照與客戶所約定的方式進行，分析的過程也沒有錯誤的話，不論其最後的數字高或低，可靠度本身都不會有問題。可靠度有沒有達到目標或要求，以及如何達到可靠度目標才是問題。不過這個問題，不是可靠度分析可以處理的。另外，可靠度也不能協助我們定位某一次失效的原因，當然也就不能用它來判斷，出問題的是硬體或軟體。

至於，應依據何種標準發展與測試 ?個人不知道。

另外，FCA(產品的功能型態稽核 / Functional Configuration Audit)是確保受稽核的軟體項目與它的規格一致。PCA(實體型態稽核 / Physical Configuration Audit)是確保設計與參考文件和建置出來的軟體產品實體是一致的。因此，從其目的上來看兩者都與可靠度似乎是没有關連的。

應如何在需求文件中展述有關軟體可靠度的需求？我想這最主要要看開發團隊執行軟體可靠度分析的能力，以及與客戶協商的結果(採用什麼樣的可靠度模式)而定。

最後有關可靠度的 Traceability 的問題，個人以為與管理其它需求規格的追溯方式没有什麼不同。

希望以上的說明，能對各位有所幫助。

周茂松 敬上

談一些個人對可靠度與軟體可靠度之心得:

1.與軟體可靠度相關之歷史-
a.1957年IBM公司推出第一套高階程式語言FORTRAN，當時一般以Programmer或Programming稱呼有關程式撰寫之人員或工作，Software一辭尚未形成。
b.1957年美國國防部成立有關電子裝備可靠度顧問團（AGREE）的報告對於可靠度的分析，完全未提及有關軟體部份，當時對於可靠度的定義是Reliability：The ability (probability) of a system or component to perform its required functions under stated conditions for a specified period of time.該定義之關鍵字為“probability”與“function”。
c.1972年Jelinski and Moranda推出第一個軟體可靠度模式，晚於1968年於NATO的Software Crisis會議中提出Software Engineering 約四年。迄今所提出有關Software Reliability model依據不同文獻資料分別有40、50與200種三種數據，較常被引用的為40一值，目前在工程領域將之歸類為Software Reliability Engineering (SRE)。Software Reliability較常被引用的定義為Software Reliability：The probability that the software will not cause the failure of the system for a specified time under specified conditions. This is based on system usage and an estimate of the number of faults built into the software. 該定義之關鍵字也有“probability”。
d.1988年AT&T發表Software Reliability Engineering (SRE)。
e.有關軟體可靠度的標準文件目前所知有2008年IEEE-STD-1633與2004年SAE-JA-1002、1003，其中1633係依據ANSI/AIAA-R013-1992所改版制定。
2.軟體可靠度理論之演變-
a.軟體為何失效，早期都將之視為同硬體或傳統可靠度理論，因此努力方向也都直接將硬體可靠度帶入軟體可靠度的分析。
b.與前述同期，也有主張軟體絕對不會出問題的理論，因此在1981年MIL-STD-756B 有一章節為
“2.3.8.1 Software reliability assumption. The assumption that all software is completely reliable shall be stated in instances when software reliability is not incorporated in the item reliability prediction.”
c.近年來有極多研究是由Random Failure與Systematic Failure方向來討論，硬體（HWCI）失效可包含Random Failure與Systematic Failure，軟體（CSCI）失效僅能歸諸於Systematic Failure。以下二份為近年所發布之標準或指引文件相關章節(1)3.6.4、3.6.5、3.6.6 of IEC 61508-4、(2)5.3.9 Markov Modeling of NASA Software Safety Guidebook。
3.Random Failure與Systematic Failure的意義-
a.Random Failure是因為組件在使用或磨損之下因為壞掉所以讓系統功能（function）無法如預期之需要（Needs）或規格書（Requirements Specification）所定義的運作，該隨機性失效的量化表示最常見的是MTBF、MTTF，是屬於Calendar Time的期望值表達方式，MTTF=∫t × f(t)dt，其中f(t)為機率密度函數(probability density function)，因此隨機性失效是存在有組件失效之機率值。隨機性失效的意義是HWCI本身已排除所有設計不當因素且裝置本身可正確執行需求所定義的功能，但因為使用年限、老化、磨耗、等非設計因素以致使裝備損壞，而此等損壞的機率如果以電子零件而言，在進入failure rate以Bathtub顯現之useful life階段其瞬間故障率 (hazard rate)為定值λ，MTTF =1/λ，可靠度值R(t)=exp(-λt)。產品在連續工作一個MTTF時間之後，其預期之可靠度值為R(t)=exp(-λt)=exp(-1)=0.3678794，產品在二倍MTTF時間仍能正常工作的機率為exp(-2)=0.1353352，所以硬體絕對會失效，但不知何時會發生，僅能估計其發生之機率，即便你換上一個全新的零件也有可能會失效。
b.系統性失效Systematic Failure是指由Manufacturing defects、Specification mistakes、Implementation errors,、Operation and maintenance設計所造成的問題（程式撰寫錯誤為最常見者），相對於需求而言是不應該存在的，HWCI也存在有系統性失效，通常要在前述Bathtub的初期Infant Period予以解決，也就是說需求所定義的function在系統中皆應該可以執行。系統性失效是屬於人為設計不當所造成，它不存在有所謂的機率問題、沒有機率的問題等於沒有時間的問題，也等於是MTBF或MTTF是不存在於Systematic Failure。
c.Random Failure與Systematic Failure的另一些具體表徵為前者為無法再複製的non-reproducible但可以預期可能發生的機率或可能性，Systematic Failure為可再複製的reproducible，因為是設計不當，只要是同樣的input condition，系統就會失效，與機率無關，以同樣的CSCI構型提供backup或redundance一樣會失效。所以對於CSCI而言MTBF與MTTF是不存在的。在1.c所提及的Software Reliability定義，就Systematic Failure而言是值得商榷的。另外對於系統性失效與隨機性失效二種失效方式之後續處理也有差別，可參考fig8 of IEC 61508-1。
4.軟體失效案例-
2007年2月11日有6架F-22由夏威夷飛往沖繩島，在飛越國際換日線時6架飛機的GPS/INS電腦全部同時失效，從而影響飛機上其他包括引擎控制的13項系統的電腦出現問題，後來公布的原因是軟體所造成的失效（個人猜測可能與security code有關，且security code通常會設定time zone與area zone二種變數），會6架飛機同時出問題就是屬於系統性失效，後來在48小時內修改軟體解決問題。
5.軟體可靠度工程-
a.196x年代軍用飛機F4有8%藉由軟體達到功能（Functionality），200x年代的F-22由軟體所提供的功能已達到80%，2008年有關F-22的Source code報告為2,200 KSLOC，相較於F-4的2KSLOC軟體規模成長不只百倍，因此軟體可靠度工程日趨重要。
b.可靠度不是一項獨立的性能需求，它事實上是與安全有關的一項因子，詳細內容可參考MIL-STD-882C，與可靠度相關的工作事項包括有Preliminary Hazard Analysis、System Hazard Analysis、Subsystem Hazard Analysis。可選用的方法有FTA、RBD、FMECA等。前述所提及的2.c，確實在198x年有文獻認為上述方法可應用於軟體的發展，但當時幾乎都朝向各種數學Model、defect density、function point能夠與諸如MTBF/MTTF相轉換的研究，也有極多的報告指向calendar time或CPU Execution time的分析。目前在Software Safety Guidebook 則定義有 Software FTA and Software FMEA的工作事項。
6.與採購相關之可靠度事項-
a.採購文件會將可靠度納入性能（performance index）一項，但Acquirer對於可靠度的觀念會影響RFP的撰寫內容，同樣的會影響整個發展與成本。如果主張HWCI與CSCI有同樣的Random Failure，有一項理論是1/MTBFSYS=1/MTBF HWCI + 1/MTBF CSCI，如果考量MTBF HWCI =MTBF CSCI的配當方式，當電腦裝備的MTBF HWCI =50,000hours，MTBFSYS = 2,5000 hours；但如果認為CSCI不存在有Random Failure，也就是類似MIL-STD -756B的內容，則MTBFSYS = 50,000 hours，對於允收測試將有相當的影響。
b.由採購角度對於可靠度方面應於完成RFP前了解User對於系統在可靠度方面的要求、在發展階段應該去確認相關潛在性的失效機制且經由設計變更予以排除、在製造階段應避免製造出瑕疵品、在交付客戶操作階段應監控相關失效現象以供後續設計改善或調整備份作業與維修作業。