質(zhì)量是產(chǎn)品的生命

　　當今隨著軟、硬件技術的發(fā)展,嵌入式系統(tǒng)廣泛應用于航空航天、國防軍事、電子通信等行業(yè)，其中軟件也越來越復雜。而這些領域應用特點，決定了嵌入式系統(tǒng)往往是高安全、任務關鍵的系統(tǒng)，軟件的微小瑕疵就可能嚴重威脅到生命和國家的安全、天文數(shù)字的巨額財產(chǎn)損失。這就使得保證嵌入式軟件的質(zhì)量和可靠性，變得至關重要。而在這些領域，對產(chǎn)品質(zhì)量從來就保持著高度的重視，有將“質(zhì)量視為產(chǎn)品的生命”的傳統(tǒng)。這樣，相關行業(yè)的高層管理人員和開發(fā)人員對于軟件的質(zhì)量也逐漸提高了重視程度。近年來，在組織上，建立了完善的軟件測試體系；在開發(fā)和測試方法上，建立了中國的軟件過程成熟度的評價體系GJB5000；在自動化工具方面，投入了大量的經(jīng)費和人員在測試設備的開發(fā)、購置和建設方面。應該說，軟件作為嵌入式產(chǎn)品主要的組成部分之一，對其質(zhì)量的重視是目前相關行業(yè)的一個共識。

　　IBM Rational多年來在軟件工程和質(zhì)量保證方面積累了豐富的方法和經(jīng)驗。本文依據(jù)部分嵌入式開發(fā)機構對軟件質(zhì)量保證工作的一些理解，分析相應開發(fā)機構工作中可能的問題，并提出以RUP為核心的全過程質(zhì)量管理的思想和具體的實現(xiàn)方式，提出不同單位的過程改進方法，以一種漸進的方式，從簡單的工作開始，逐漸深入地改進組織的軟件質(zhì)量管理水平。

　　定義質(zhì)量

　　對于任何一個組織，定義共同的對質(zhì)量的理解是重要的第一步。軟件開發(fā)組織經(jīng)常按照一種不精確的、概括的質(zhì)量觀念來運轉。

　　在IBM Rational統(tǒng)一過程中，質(zhì)量定義如下：

　　·滿足或超出認定的一組需求；

　　·使用經(jīng)過認可的評測方法和標準來評估；

　　·使用認定的流程來生產(chǎn)。

　　在這個定義中，我們首先看需求，IBM Rational的軟件質(zhì)量在用戶需求方面的定義分為五個方面：易用性、可靠性、性能、可支持和功能。

　　質(zhì)量保證，歸根結底就是為客戶提供更高品質(zhì)的產(chǎn)品，更好地滿足客戶的需求。另一方面，這個質(zhì)量定義中明確指出，質(zhì)量更體現(xiàn)在軟件開發(fā)的整個過程和一個標準的評價方式上。

　　軟件開發(fā)過程質(zhì)量就是指為了生成工件而對可接受流程的實施和遵守程度，體現(xiàn)在三個層次：

　　·產(chǎn)品本身和用來生產(chǎn)、組裝軟件產(chǎn)品的零部件質(zhì)量；

　　·在軟件開發(fā)過程的標準化、流程化、自動化程度和團隊基本協(xié)作平臺的效率，各個過程對質(zhì)量的承諾；

　　·軟件產(chǎn)品驗收的評測手段應該是被業(yè)界廣泛認可和接受的方法，所構筑的質(zhì)量評價標準。

　　一個軟件生產(chǎn)企業(yè)的過程質(zhì)量一般可以用它的軟件過程成熟度等級來評估。

　　RUP全過程質(zhì)量保證

　　Rational Unified Process(RUP)是一個可以通過Web來使用的軟件工程過程。作為軟件工業(yè)事實上的標準，它回答了我們以下問題：在整個軟件開發(fā)的各個過程中，誰(角色)應該在什么時候(詳細工作流程)做什么(任務)和產(chǎn)生什么樣的開發(fā)結果(工件)，以完成整個項目的開發(fā)目標。建立有效的工作過程，可以提高團隊的生產(chǎn)效率，控制開發(fā)過程中的風險，保證軟件開發(fā)進度并且提高軟件產(chǎn)品質(zhì)量。同時通過為所有重要的開發(fā)活動提供全面的指南、模板和示例，使整個軟件開發(fā)團隊能夠有效共享成功經(jīng)驗，提高團隊效率，最終保證軟件開發(fā)質(zhì)量。

　　全過程質(zhì)量保證思想

　　RUP把整個軟件開發(fā)過程分解成：業(yè)務建模、需求管理、分析設計、實施、測試、部署、配置與變更管理、項目管理和環(huán)境等九個核心工作流程。每個核心工作規(guī)程由多個詳細工作流程組成。RUP使用角色、任務和作為輸入/輸出的工件來組織每個詳細工作流程，實現(xiàn)軟件開發(fā)組織內(nèi)部人、資源和流程的融合。RUP通過建立完整的軟件開發(fā)過程，使得產(chǎn)品的質(zhì)量由項目團隊的每個成員所代表的角色共同負責，具體體現(xiàn)在：每個工作流程設定相應的工作指南和工作檢查點，每個角色承擔相應的質(zhì)量任務。

　　在RUP中，整個軟件開發(fā)過程如圖1所示，它以指定的工件為輸入，通過軟件開發(fā)角色和標準化的軟件開發(fā)活動，生產(chǎn)出滿足質(zhì)量要求的輸出工件。


    
　　用正確的過程和平臺實現(xiàn)質(zhì)量

　　IBM提供一個完整的方案以幫助開發(fā)團隊構建更高質(zhì)量的軟件。這個開放和標準的平臺包括IBM軟件的許多工具，包括IBM Rational統(tǒng)一過程。在開發(fā)的每個階段和每個流程都強調(diào)關注質(zhì)量，幫助團隊來識別開發(fā)生命周期中的早期問題。以下部分描述了RUP和IBM軟件開發(fā)平臺中的工具如何支持每個工作流程中的質(zhì)量實踐的。

　　為減少重復描述，先將相關工具的功能統(tǒng)一簡要描述。下面的所有工具都可以以插件的形式集成到開放的Eclipse平臺上，為開發(fā)者提供集成環(huán)境：

　　·IBM Rational System Developer 用于系統(tǒng)建模和開發(fā)的集成環(huán)境；

　　·IBM Rational TestManager 用于計劃、管理和報告任何測試工作要求；

　　·IBM Rational Manual Tester 用以提高手工測試工作的效率；

　　·IBM Rational Test RealTime

　　用于嵌入式系統(tǒng)的靜態(tài)度量、代碼規(guī)則檢查、單元測試、覆蓋率分析、內(nèi)存分析、性能分析、代碼跟蹤、線程分析、基于消息的分布式系統(tǒng)測試的跨平臺解決方案。

　　為了推動團隊溝通、協(xié)作和合作，IBM Rational還提供多種額外的解決方案選項。

　　分析

　　根據(jù)統(tǒng)計得知，引起客戶不滿意問題的80%可以追溯到對需求的糟糕理解上。對于任何嵌入式開發(fā)項目，不論是新的系統(tǒng)開發(fā)，或遺留系統(tǒng)更新集成，質(zhì)量開始于分析業(yè)務，以確保系統(tǒng)需求清晰且準確地反映了業(yè)務和客戶需求。

　　我們可以將被測系統(tǒng)置于其將運行的環(huán)境中，采用建模的方式，將最優(yōu)確認的需求，用條目化的方式管理需求文檔，實現(xiàn)從需求、到分析、到設計、到實現(xiàn)、到測試的雙向跟蹤，以實現(xiàn)測試中發(fā)現(xiàn)缺陷到各層次的跟蹤，和影響范圍的分析。

　　設計

　　在設計中，主要的質(zhì)量集中在構架上，這是軟件的“靈魂”。低質(zhì)量的構架會引起大范圍的質(zhì)量問題，包括（軟件）脆弱、缺乏升級、以及發(fā)現(xiàn)缺陷也難以修改。這些問題隨著應用軟件項目不斷發(fā)展，變得越來越難以解決；并且隨著應用軟件從設計到開發(fā)、測試和部署，糾正缺陷的成本以指數(shù)在增長。如果軟件開發(fā)人員可以有效地發(fā)現(xiàn)、隔離和解決設計和開發(fā)期間的結構上的不足，這項工作會在整個項目期間獲得受益。

　　開發(fā)

　　平均起來，開發(fā)人員在他們寫的每千行代碼中會產(chǎn)生100到150個錯誤。當然，這個數(shù)量隨著開發(fā)人員和項目的不同而不同。即使只有一小段代碼，產(chǎn)生10%的錯誤也是很嚴重的。

　　RUP倡導開發(fā)人員主動地測試和分析。盡管單元測試和運行分析已經(jīng)變得更為主流，但是許多管理人員仍然有這樣的誤解，即這些過程使時間表中增加了不必要的時間。事實上，如果不采用這些措施，開發(fā)時間表通常會一樣或更加延長，這是由于在質(zhì)量保證或客戶發(fā)現(xiàn)問題后，開發(fā)人員在生命周期中調(diào)試代碼要花費更多的時間。

　　測試

　　管理系統(tǒng)級功能和性能測試是持續(xù)保證質(zhì)量的一個主要部分。一個開發(fā)組織既不應當過分強調(diào)，也不應當減少系統(tǒng)測試的重要性。如前所述，保證質(zhì)量不只是測試團隊的職責，測試也不只是質(zhì)量保證的唯一領域。某些測試可以并且應當由開發(fā)人員來運行，在某些情況下，可以由構架師來運行。大量的質(zhì)量保證工作，在RUP的原則下是由其他開發(fā)角色構造的。

　　支持保證質(zhì)量的團隊職責

　　質(zhì)量是開發(fā)團隊中的每個人的職責，但是它也是團隊作為一個整體的職責。在一個迭代的過程中，每個迭代確保了每個工件質(zhì)量的持續(xù)的重新評估，這樣，在迭代的方式下，經(jīng)?？梢员ＷC提交質(zhì)量更高的產(chǎn)品。有效的軟件配置管理和變更管理是保證質(zhì)量的一個基本工具；它幫助組織確保軟件在每次構建時是可重復的和可靠的，并且保證缺陷和變更請求得到正確的管理。
    
　　質(zhì)量過程改進的步驟

　　當我們考慮需要什么來構建任務關鍵和高安全性的系統(tǒng)軟件，并涉及過程質(zhì)量改進時，大家往往想到的是一個復雜的過程。其實，軟件過程質(zhì)量改進，如軟件開發(fā)，可以是一個迭代的過程。你不需要一步就完成所有的事情。即使是小的變化，包括調(diào)整你的組織中對質(zhì)量的看法，也會產(chǎn)生一個切實的改進。

　　我們指出兩條參考的改進的線路圖，遞進式的(或者本質(zhì)的)和演進式的(反應式的)。遞進式的更多考慮工作流程間的依賴性，做到先改善基礎流程，再基于已有的改善基礎，做進一步改進。而演進式的多來自于工作中感知到的問題和瓶頸，依據(jù)問題的表面做反應式的改進?；诟倪M后再發(fā)現(xiàn)新的問題，如此反復。當然，我們也在努力發(fā)現(xiàn)一種可以兼顧工作流程間依賴性，有可以快速顯示改進效果的改進方式。

　　我們可以把質(zhì)量保證工作改善劃分為以下幾個方面：配置管理和變更管理、靜態(tài)分析和單元測試、集成測試和系統(tǒng)測試、迭代開發(fā)和連續(xù)測試、全過程質(zhì)量、組織級質(zhì)量體系、架構分析、需求管理、項目管理。遞進式和演進式的實施方式如圖2和圖3所示。

　　獲得軟件高質(zhì)量的高收益

　　全過程的質(zhì)量保證體系總是比忽略質(zhì)量問題的成本要低。事實上，如果你正確地運用，提高產(chǎn)品質(zhì)量基本上沒有成本。

　　在國際上，隨著軟件質(zhì)量保證理論及應用研究工作的不斷深入，針對軟件質(zhì)量保證工作的工作重點也經(jīng)歷了如下發(fā)展歷程：

　　·1970年以前，采用特定(Ad-hoc)測試，與調(diào)試沒有區(qū)分；

　　·1970年末到1980年中期，測試基礎理論和實用技術形成，軟件測試作為軟件質(zhì)量保證(SQA)的主要手段和職能；

　　·1980年代末到90年代中期，測試工具在質(zhì)量和數(shù)量上不斷增長，測試與SQA分離,注重于工具對測試效率的影響；

　　·1990年后期到目前，重新關注有效的過程管理對于軟件測試的重要性，將軟件工程視為軟件測試的基礎，或形成各種獨立的測試模型、測試能力成熟度模型。

　　現(xiàn)在高品質(zhì)軟件，需要完整的軟件開發(fā)過程和整合的軟件開發(fā)平臺來共同鑄就。IBM Rational軟件開發(fā)平臺，就是以各種國際標準和開放平臺為基礎，為嵌入式系統(tǒng)軟件產(chǎn)品的開發(fā)和生產(chǎn)過程提供了良好的開發(fā)速度和質(zhì)量保證。