qileilove

軟件設計

　　軟件也和硬件一樣，它的質量是設計出來的，生產出來的。其中，設計對軟件質量具有關鍵性的影響。設計的重要性可從圖3看出，其中（a）為經歷了設計步驟后的效果，在軟件使用和維修階段，軟件的問題少；反之，（b）為跳過設計步驟，到了使用和維修階段，軟件問題成堆，到了不可收拾的地步。基于這種情況，應強調：軟件設計未完成，不得轉入軟件編碼階段。

　　良好的軟件設計與所采用的軟件設計方法、設計工具和設計準則有關。軟件設計方法主要有面向數據流的設計、面向對象的設計和面向數據的設計方法等。這些方法均有其優缺點和不同的應用領域。目前，大多數嵌入式的實時控制軟件使用的是面向數據流的設計方法。該方法的目標是以一種全局的軟件觀點和體系結構設計的角度派生出程序結構。

　　面向數據流的設計又稱為結構化設計。它強調模塊化、層次化和自頂向下等設計思想。這些思想的根本目的是對復雜問題的解決采用一個簡化過程以獲得滿意的答案。通過這種簡化，縱有千頭萬緒也能理得清清楚楚。一個設計準則是要將復雜的問題簡化，切忌將簡單的問題復雜化。好的程序設計語言，無疑對設計高質量的軟件是有益的。例如，Ada語言，與一般語言比較，它所特有的一些語言成分旨在突出軟件可靠性和安全性，便于軟件維護，便于實行程序的層次式管理和提高程序的易讀性、高效性等。

　　軟件可靠性設計主要將軟件的檢錯、避錯、容錯和異常處理技術灌輸到軟件設計中去，設計時應處處關心：

　　● 控制邏輯的完整性；

　　● 軟件與硬件、軟件與軟件界面之間的協調性；

　　● 人機交互的有效性；

　　● 信息交換的正確性；

　　● 設備控制的安全性；

　　● 時序控制的合理性；

　　● 數學運算中變量定義域的合法性。

　　軟件生產工具

　　軟件生產的主要工具是軟件試驗臺（Software Testbed）或軟件開發平臺。在軟件需求分析的同時，就要考慮到這類軟件開發環境的創造。它應滿足下列要求：

　　（1）它的組成、結構、性能、功能和工作的方式與狀態，力求與實際系統一致。優點是：

　　● 它與實際系統出現的故障現象是一樣的，便于故障隔離。

　　● 軟件試驗臺與實際系統的軟件可彼此互相復制，便于軟件開發過程交替上升。

　　● 具有互補性，試驗臺有局限性的問題可在實際系統解決；實際系統上有困難的，代價太大的檢測活動可在試驗臺上進行。

　　（2）配上多媒體工作站，提供軟件測試過程中綜合信息的顯示和生產真實工作環境中的音響效果。

　　（3）配備實時數據采集器。

　　（4）能支持實時與非實時兩種運行方式的調試活動。

軟件試驗臺是輔助軟件調試、測試、試驗和驗證的重要工具。在某種程度上可以得出這樣的結論：沒有軟件試驗臺就不能順利地開發出實時控制系統軟件。原因在于：

　　（1）這類復雜的軟件在實際系統上開發是不可能的，其代價太大，效率太低，效果太差。

　　（2）軟件開發是個做細致研究、分析和不斷探索的過程，軟件試驗臺能適應這種工作方式。

　　（3）它是軟件編程、調試、測試、集成和試驗的綜合環境。

　　（4）它是支持軟件原型化開發方法的重要手段。

　　一般來說，實時控制系統軟件的第一個原型是在軟件試驗臺上開發出來的。有了軟件原型，就有了與用戶深入討論、分析和確認軟件需求的基礎。實踐證明，經過軟件試驗臺測試通過的軟件，基本上能用于實際實時控制系統的系統聯調、測試、試驗和系統驗收。

　　軟件測試

　　從軟件生存周期看，軟件測試是卡住軟件質量，尤其是卡住軟件可靠性的最后一道關口。但軟件測試并不僅僅局限于這個階段，而應貫穿于軟件開發的全過程（見圖4）。應解決這樣一個認識問題——用于實時控制系統一類的復雜軟件，自認為沒有錯誤的想法是不切合實際的。因此，測試的主要目的是：

　　1）對軟件的質量或可接受性作出判斷；

　　2）發現問題。

　　從圖4看出，會產生錯誤的階段是在需求說明、設計和編程過程中。這些錯誤若不排除，均會遺傳到測試階段，甚至會遺傳到使用階段。利用測試用例測出問題進行故障分類、故障隔離和故障消除等步驟，直到獲得滿意的測試結果為止。

　　測試用例的編寫格式和內容如圖5所示。測試的設計。難就難在試圖利用這組測試用例能找出軟件的全部問題。格式中含有測試管理信息——測試用例標識和執行史。測試用例標識是按一定規律統一為每個測試例賦予的代號，便于需求追蹤。執行史中有測試日期、測試結果（給出結論：通過/失敗）、版本號和主管的測試者簽字，這些都是有保存價值的資料。測試用例是需要精心設計、編寫、評審、使用、管理和保存的。

　　軟件測試要求在測試過程中，采集軟件可靠性數據，并利用軟件可靠性模型進行可靠性評估。分析其是否達到了預期的可靠性要求。并據此作出該軟件能否放行的決斷。若不滿足要求，需繼續進行測試，直到滿足要求為止。可見這是一項十分花精力的活動。

　軟件驗證與確認

　　軟件驗證（Verification）和確認（Validation），簡稱為V＆V 或V2。驗證和確認的區別在于：驗證關心的是確保軟件模塊或功能內在的正確性；確認則表明要與規定的需求進行比較是否滿足要求，它所關心的是該軟件產品的價值。

　　軟件驗證與確認是貫穿于軟件開發過程中十分細致的軟件檢驗活動。每個開發階段的結果可認為是下一開發階段的一個規格文件，但要進入下一階段之前必須對該結果作出確認。驗證和確認的主要方法有：代碼走查、審查、測試和正確性證明等。代碼走查就是對軟件文檔進行書面檢查。它通過人工模擬執行源程序的過程，檢查軟件設計的正確性。人工模擬也像計算機執行那樣，可以仔細推敲、校驗和核實每一步的執行結果，進而確定其執行邏輯、控制模型、算法和使用參數與數據的正確性。

　　審查是軟件驗證和確認中的一個主要方法，可彌補其他方法的一些不足之處。它是一種用形式的、有效的和經濟的方法查找設計和編程中的錯誤。審查的主要目的是1）找出軟件中的缺陷；2）核實是否符合需求；3）早期生產評價；4）過程評價等。由第三方進行軟件評測工作是十分重要的，其評測工具軟件對軟件進行靜態的和動態的評測，能發現軟件設計的缺陷、瓶頸和多余物等。值得指出的是，用于軟件測試的各種方法、技術、工具和措施等，對提高軟件的可靠性都是必要的，但不是充分的。這就表明，其中任何一個手段，均不能絕對保障軟件的可靠性，但只要能發現軟件中任何一個微小的錯誤，就起到了它的作用。

　　軟件評審

　　從某種意義上說，軟件中的多數錯誤是人為的。軟件評審是軟件生產過程中過濾軟件錯誤的一個“濾波器”。軟件評審涉及評審的組織機構、管理、準則、類別、內容、文件和要求等。

　　一般要求在軟件研制階段的里程碑點進行軟件評審。評審的主要類別有：軟件定義評審、軟件需求評審、概要設計評審、詳細設計評審、軟件實現評審和軟件驗收評審等。

　　評審的原則：

　　● 某階段未通過階段評審不得進入下一個軟件研制階段；

　　● 評審時對事不對人，評審的是產品，而不是評審生產者；

　　● 評審就要挑刺，找問題、缺陷和隱患；

　　● 評審組的人員面越廣越好；

　　● 評審組不作無休止的爭論和辯駁，將爭論點記錄下來，供以后甄別；

　　● 評審只是提出問題，沒有解決問題的任務；

　　● 使用“評審檢查單”以提高評審的效果；

　　評審的作用：

　　● 技術把關，避免軟件人員的想當然；

　　● 概念溝通，吸收用戶和總體人員參加，審查軟件人員理解的正確性；

　　● 集思廣益，吸收有關的分系統人員參加，從不同側面確認軟件的協調性；

　　● 總結匯報，使實時控制系統總指揮、總設計師了解軟件生產的進度、問題和要求，作出新的部署。

　　評審很容易走過場、走形式。評審效果的好壞，與當事人（軟件人員）密切相關。基于有問題才需要評審，不能輕信自己的軟件，導致對評審產生對立情緒。對評審出的問題進行整理、分類和匯總，不忽視任何一個細小的疑點。

　　軟件管理

　　科學的管理能夠出可靠性、出效果、出效益。軟件的管理工作不完善、不嚴格，是引起意外事故的原因之一。軟件管理主要包括軟件項目管理、軟件配置管理、軟件可靠性管理和軟件質量管理等方面。

　　軟件項目管理的內容包括軟件開發過程管理、軟件可靠性度量、風險管理（包括風險分析和估計）、確定項目任務、建立可操作的工程計劃等。軟件項目管理是軟件管理工作的第一層。需要強調的是，它不是一個階段，也不僅僅是個步驟，而是貫穿于整個軟件開發工程中的一個層次。從其管理內容來看，這是一種十分重要的管理工作。其管理的好壞，直接影響產品的質量。這項管理尚處于起步狀態，是個薄弱環節。軟件配置管理是軟件人員和管理人員確定、組織和開展軟件修改的手段，目的是在軟件修改過程中設法少犯差錯來最大限度地提高軟件產品的生產率。軟件配置管理涉及軟件配置項和基線的確定。

　　軟件配置項可理解為在軟件生產的某個階段應具備的軟件文檔和保存軟件的介質等。軟件基線（基準）又稱里程碑。軟件配置項經軟件驗證、確認、評審和認定后，形成了軟件基線，也就成了該階段的一個基準。下一個階段只能在這個基準上進行開發活動。

軟件配置管理要求：

　　● 軟件修改必須遵循軟件更改規范；

　　● 未經批準的更改，任何人無權修改；

　　● 更改后必須測試、驗證和確認；

　　● 軟件驗收，必須對相應的軟件進行評審。

　　具備評審的條件包括：相對該基線的軟件配置項齊全、有測試結果和測試分析報告及軟件優化報告。

　　文檔管理是一項十分艱巨而又瑣碎的工作，要求：文檔編寫必須規范、文實相符、文文相符、描述具有一致性、確切性和簡明性、簽署完整、職責明確。軟件可靠性管理作了一些初步的嘗試。在軟件生產過程中，設計了軟件可靠性數據采集表格。對軟件中的需求、模型、設計、編碼和定義域等方面的錯誤均要填表。填寫產生該錯誤的時間（計算機執行的累計時間）、錯誤性質、出錯原因和排除錯誤的結果等。

　　主要問題與解決方法

　　對實時控制系統軟件工程化的重要性的認識尚處于起步階段，重視程度也不平衡。主要問題：

　　（1）部分系統的軟件開發由硬件人員承擔。硬件、軟件、模型設計均由一個組完成，仍是典型的“自編、自導、自演”小作坊的工作方式。

　　（2） 還不太習慣于軟件工程化、規范化、結構化和模塊化的軟件生產方法。往往跳過了軟件設計階段，而是先有編碼，為了軟件檢查才補設計。

　　（3）缺少配套的軟件測試工具。試圖利用實時控制系統進行軟件的調試、測試、驗證、確認和試驗工作，這樣的軟件測試必然是不完整的，也是有局限性的，更是不科學的。

　　（4）實時控制系統軟件可靠性工程的研究是自發的，未納入實時控制系統研制計劃，影響這項工作的深入開（5）需要解決實時控制系統軟件工程化方面的若干模糊認識：

　　● 軟件就是編程；

　　● 沒有測試工具照樣可以開發出軟件；

　　● 舍不得在軟件可靠性上化成本；

　　● 出了問題，才發現軟件似乎比硬件更重要。

　　（5）實時控制系統軟件可靠性指標不好定。原因是軟件可靠性的評估涉及模型、方法、工具和條件等問題。當前，要求軟件的可靠性為100％，對軟件是不公正的，也是過于苛刻的。

　　建議

　　（1）軟件可靠性工程也是一項涉及面很廣的系統工程，應加強這項技術的研究力度。尤其要結合具體實時控制系統設置研究課題，使實時控制系統軟件的生產過程同時也是軟件可靠性工程的實施過程。使自發的可靠性工作成為有計劃、有組織和有目標的研究工作。

　　（2）適用于嵌入式計算機的實時軟件，例如實時操作系統、Ada語言等，應像美國國防部那樣，要強制推行。

　　（3）計算機技術發展很快，軟件技術及軟件可靠性工程技術也發展很快，應對重點實時控制系統的軟件人員定期組織培訓。

　　（4）為了解決軟件生產的小作坊問題，可否考慮逐步推行實時控制系統軟件人員考核制，作出資格認證。