軟體可靠性是一個特殊的課題，由於軟體的故障機理與硬體存在著本質上的差異，因此，軟體可靠性有其自身的特點，下面從技術和管理兩個層面分別加以說明。
技術層面
從技術層面看，軟體的使用沒有磨損和疲勞等問題，因此，軟體的故障（或者缺陷）是“無耗損”的、是非物理因素造成的。在其開發期（製造期）很難被發現，只有在使用過程中、而且是在特定的應用環境（硬體環境和軟體環境）中才有可能暴露出來，然後再對軟體進行維護（改進），使軟體的可靠性得到提高。可見，軟體是無耗損的，“越用越可靠”，其失效率隨著時間的延伸是單調下降的，形式上類似於電子產品的早期故障模式。
軟體沒有偶然失效期，因此，電子產品的可靠性理論與方法不能直接應用於軟體產品。因為，電子產品的可靠性理論與方法是以恒定失效率（偶然故障模式）為前提的。雖然有些學者也提出了一些有關軟體的定量評價指標及模型，但基本上沒有實用價值，不被工程界認可。到目前為止，工程界普遍認可的還是定性的分析方法，例如，FMEA、FTA、以及軟體的“可靠性設計準則”等。
FMEA和FTA都是用來分析故障因果關係的重要工具。這裡所說的“因果關係”是指“底層產品”（功能單元）的故障與“頂層產品”（系統或設備）故障之間的因果關係，並且將底層產品的故障視作“因”，而將頂層產品的故障視為“果”。FMEA是自下而上，由“因”推“果”的分析過程；而FTA是自上而下，由“果”找“因”的分析過程。這種定性的因果推理過程，不但實用於硬體產品（電子的和非電子的），也同樣適用於軟體產品的故障分析。
對軟體而言，頂層產品就是待分析的軟體本身；最底層的單元就是每一條指令。軟體的FMEA和FTA，就是具體分析軟體的故障（頂層產品的故障）與每一條指令（最底層的單元）之間的因果關係。通過分析找出有問題（有缺陷）的指令，然後再對軟體進行改進（維護），使軟體的可靠性得到提高。
管理層面
大量的事實表明，影響軟體可靠性的主要因素不完全是技術原因，而是管理原因。主要表現在以下三個方面：
⑴ 透明度差：由於很多軟體從設計到程式設計（軟體的生產），都是由一個人全部包攬，出了問題以後，只能由原開發者去處理，別人很難介入。時間久了，恐怕連原開發者自己也不清楚了。不但軟體的品質難以得到保證，而且軟體的維護更加困難；
⑵ 檢驗困難：軟體不像硬體產品那樣，能夠進行直觀、有效的檢驗。目前還沒有專職的“軟體檢驗員”，軟體的檢驗通常是由專門的“軟體檢測站”來完成，用測試代替檢驗；
⑶ 管理粗放：軟體的技術狀態管理（配置項管理）檔不夠細化，監督機制不夠健全，往往在“更改控制”環節上出問題。
統計結果表明，大部分軟體故障與上述三個因素有關。工程界普遍認為，解決這一問題的根本出路在於，將軟體視為產品（包括：文檔和來源程式），對軟體的開發、測試、驗收、使用、維護等過程分別制訂相應的規範，並加強“工程化管理”。軟體既然是產品，就應該和硬體產品一樣，將設計和生產截然分開，而且能夠被檢驗。只有這樣，上述的三個問題才能夠得到克服，特別是“透明度”的問題。為此，建議如下：
① 設計崗位：應明確規定“設計崗”不能夠編寫程式，但必須完成除程式設計以外的全部設計工作：
確定軟體的總體結構（由哪些模組組成、模組的功能說明、不同模組間的相互關係，以及資料結構和演算法等）；繪製軟體流程圖；編制軟體文檔；撰寫“軟體可靠性設計準則”（程式設計時的注意事項：應該如何做、哪些不能做）；參與軟體的設計評審等。
② 生產崗位：軟體的生產，即程式設計，應該在“軟體車間”完成。程式設計人員（生產崗位）在充分理解、消化設計檔（軟體文檔和可靠性設計準則）的基礎上編寫軟體程式。程式設計者不能是本軟體的設計者，但可以是其它軟體的設計者，目的是節省人力資源。
③ 檢驗崗位：“檢驗崗”對軟體的“產品品質”進行把關。這裡所說的“檢驗”是軟體交付使用前的“過程檢驗”，起碼應該做到：文檔審查、來源程式的代碼走查，以及“軟體可靠性設計準則”執行情況的檢查。最後，應提交“文檔審查報告”、“代碼走查報告”和“準則符合性檢查報告”。如果有條件的話，可進一步完成軟體模組的單元測試。檢驗者既非本軟體的設計者，也非本軟體的程式設計者。但可以是其它軟體的設計者或者程式設計者，同樣是為了節省人力資源。
④ 最終確認：軟體的“最終檢驗與確認”，由獨立的、專業的檢測機構（即協力廠商）完成，必須通過嚴格的測試，並給出明確的結論。具體如何操作，按相關規定執行。
小結
綜上所述，建立“軟體可靠性設計準則”、推廣應用FMEA和FTA技術，以及加強軟體的工程化管理，都是提高軟體可靠性的重要手段。如果將這些手段聯合運用，效果會更佳。