嵌入式系統(tǒng)軟件的質量保證

IBM中國有限公司軟件部高級技術顧問 靳超

一. 質量是產(chǎn)品的生命

　　當今隨著軟、硬件技術的發(fā)展,嵌入式系統(tǒng)廣泛應用于航空航天、國防軍事、電子通訊等行業(yè)，其中軟件也越來越復雜。而這些領域應用特點，決定了嵌入式系統(tǒng)往往是高安全、任務關鍵的系統(tǒng)，軟件的微小瑕疵，就可能嚴重威脅到生命和國家的安全、天文數(shù)字的巨額財產(chǎn)損失。就使得保證嵌入式軟件的質量和可靠性，變得至關重要。而在這些領域，對產(chǎn)品質量從來就保持著高度的重視，有將“質量視為產(chǎn)品的生命”的傳統(tǒng)。這樣，相關行業(yè)的高層管理人員和開發(fā)人員對于軟件的質量也逐漸提高了重視程度。近年來，在組織上，建立了完善的軟件測試體系，從自檢，到專檢，直到甲方的測試中心；在開發(fā)和測試方法上，沿襲了多年在系統(tǒng)工程和硬件設計中積累的經(jīng)驗，在項目管理中將“兩條指揮線四總”的體制推廣到軟件領域，建立了中國的軟件過程成熟度的評價體系GJB5000；在自動化工具方面，投入了大量的經(jīng)費和人員在測試設備的開發(fā)、購置和建設方面。應該說，軟件，作為嵌入式產(chǎn)品主要的組成部分之一，對其質量的重視，是目前相關行業(yè)內的一個共識 。
　　然而在現(xiàn)實生活中，許多軟件產(chǎn)品卻時常陷入質量低下的旋渦，總是不盡人意，問題常常表現(xiàn)在：
　.　相關產(chǎn)品的領導得不到產(chǎn)品質量的具體信息，不能對軟件研發(fā)體系交付產(chǎn)品的質量建立信心；
　.　項目管理人員無法實時對項目中軟件部分所處的質量狀態(tài)有所了解；
　.　產(chǎn)品在集成階段，常常因為軟硬件混合的集成問題難以解決，而造成延期，甚至由于進度的要求，降低產(chǎn)品的質量基線；
　.　開發(fā)團隊沒有時間和資源繼續(xù)測試，發(fā)布未經(jīng)過完善測試的產(chǎn)品，然后在維護產(chǎn)品上花費更多的時間、經(jīng)費和人員；
　.　于此同時，研發(fā)體系困惑于測試工具的使用，發(fā)現(xiàn)那些購買是良好演示的工具卻無法測試我們開發(fā)出來的系統(tǒng)；
　.　軟件總是由總師設計出來，由開發(fā)人員編寫出來，最后在項目即將交付時，交給測試人員，由他們承擔質量責任。
　.　軟件測試更象一場“運動”，在項目交付階段臨時組織起來的測試團隊，面對交付的壓力，不得不尋求無需學習，無需準備、無需了解被測對象的，無需硬件，無需源碼，最好什么都不需要的“人工智能”的測試工具，只要能出報告，而無暇顧及軟件質量的本質要求。
　　.　現(xiàn)有的工具往往無法滿足這些測試的需求，我們常常找些看似滿足的，但在實際使用中，又會發(fā)現(xiàn)由于我們對工具使用預期不恰當?shù)亩ㄎ?，工具原本的功能由于其他的因素無法發(fā)揮。
　　.　現(xiàn)有的工具常常處于閑置狀態(tài)，而開發(fā)團隊又有很多問題得不到解決，需要更多的工具。
　　究其根源，除了軟件本身故有的復雜性，還和不同的組織對軟件產(chǎn)品質量內涵有著不同的認識，造成不同的工作方式和態(tài)度，養(yǎng)成了不同的工作和思維習慣，和由此帶來不同的產(chǎn)品質量結果。
　　IBM Rational多年來在軟件工程和質量保證方面積累了豐富的方法和經(jīng)驗。本文依據(jù)部分嵌入式開發(fā)機構中對軟件質量保證工作的一些理解，分析相應開發(fā)機構工作中可能的問題，并提出以RUP為核心的全過程的質量管理的思想和具體的實現(xiàn)方式，提出不同單位的過程改進方法，以一種漸進的方式，從簡單的工作開始，逐漸深入的改進組織的軟件質量管理水平
　　但我們也需要看到，盡管可能不需要一個繁重的、一蹴而就的過程來達到高質量的要求，但是關注質量的組織思維傾向是必要的條件，并且這必須由最高管理層驅動。

二. 定義質量

　　對于任何一個組織，定義共同的對質量的理解，是重要的第一步。軟件開發(fā)組織經(jīng)常按照一種不精確的、概括的質量觀念來運轉。
在IBM Rational統(tǒng)一過程中，質量定義如下：
　.　滿足或超出認定的一組需求
　.　使用經(jīng)過認可的評測方法和標準來評估
　.　使用認定的流程來生產(chǎn)。
　　在這個定義中，我們首先看需求，IBM Rational的軟件質量在用戶需求方面的定義分為這樣幾個方面：

　
　　講到質量保證，歸根結底就是為客戶提供更高品質的產(chǎn)品，更好地滿足客戶的需求。而且客戶的需求是多維的，產(chǎn)品的功能性需求應該是客戶首先要考慮的因素，同時還包括其他四個方面。除了這些技術因素之外，用戶的需求還應該包括產(chǎn)品要在指定的時間和預算范圍內完成。

{{分頁}}
　　第二方面，這個質量定義中明確指出，質量更體現(xiàn)在軟件開發(fā)的整個過程和一個標準的評價方式上。在過程質量方面，經(jīng)常舉的一個例子就是汽車生產(chǎn)過程。當我們面對推銷員推銷兩款汽車，其中一款是由先進的生產(chǎn)線生產(chǎn)的產(chǎn)品，而另一款是由技術精湛的師傅手工精制而成，在汽車的質量方面，您會作何感想呢？通過了解市場上同型號車的質量狀況，你可以輕松做到對第一輛車心中有數(shù)；但對第二輛呢？由此可見，你對第一輛車的信任，來自于過程質量。
　　.　軟件開發(fā)過程質量就是指為了生成工件而對可接受流程的實施和遵守程度，體現(xiàn)在三個層次：
　.　產(chǎn)品本身和用來生產(chǎn)、組裝軟件產(chǎn)品的零部件質量，包括用來進行軟件開發(fā)或在軟件開發(fā)過程中產(chǎn)生的代碼、文檔、模型和可執(zhí)行系統(tǒng)等工件；
　.　軟件開發(fā)活動本身對標準化軟件開發(fā)過程的遵守和貫徹的程度，主要體現(xiàn)在軟件開發(fā)過程的標準化、流程化、自動化程度和團隊基本協(xié)作平臺的效率，各個過程對質量的承諾；
　　用來對整個軟件產(chǎn)品進行驗收的評測手段，它應該是被業(yè)界廣泛認可和接受的方法，應以優(yōu)先考慮經(jīng)典的測試方式的實現(xiàn)，構筑質量評價的基礎，然后再針對某些低效環(huán)節(jié)補充其他專門的測試手段。
　　一個軟件生產(chǎn)企業(yè)的過程質量一般可以用它的軟件過程成熟度等級來評估，但它依賴我們采取的方法、工具和軟件開發(fā)平臺來決定。
　　我們應該如何達到這一質量目標呢？盡管要求更好質量的下意識反應就是擴大測試團隊，但是這可能不是最好的方法。作為替代，應當在你的過程中關注每一個步驟的質量。RUP全過程的質量保證過程強調的是在RUP的九個工作流程中都要逐漸形成產(chǎn)品的內在質量，是由所有團隊成員按照要求完成自己的工作并按照RUP中提供的手段檢查自己的工作而締造的。而測試流程是由專門的各個測試角色來負責，目的在于評估和改善產(chǎn)品質量，監(jiān)控質量狀態(tài)的方面。
　　有些開發(fā)人員或許會感覺這樣做不現(xiàn)實，做不到，或目標太遠大而不實際，我們在這里想要展示的就是不這樣做，我們僅有的質量保證和測試活動在應對未來復雜的系統(tǒng)開發(fā)測試需求時，將耗費巨大的經(jīng)費和時間，甚至根本無法實施。而同時，我們將提出一個漸進的改進方式，最終達到全過程質量保證體系的要求，我們要做的，僅僅是，開始！

三. RUP全過程質量保證

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

　　.　全過程質量保證思想
　　RUP把整個軟件開發(fā)過程分解成：業(yè)務建模、需求管理、分析設計、實施、測試、部署、配置與變更管理、項目管理和環(huán)境等九個核心工作流程。每個核心工作規(guī)程由多個詳細工作流程組成。RUP使用角色、任務和作為輸入輸出的工件來組織每個詳細工作流程，實現(xiàn)軟件開發(fā)組織內部人、資源和流程的融合。在許多組織中，將測試團隊成員視為缺點的清除者，在生命周期后期將他們放在一個應用軟件上，讓他們去查找其它團隊成員引入的缺陷。為了最有效地測試，測試團隊必須更關注于系統(tǒng)級質量問題上。RUP通過建立完整的軟件開發(fā)過程，使得產(chǎn)品的質量由項目團隊的每個成員所代表的角色共同負責，具體體現(xiàn)在：
　
　　　　.　每個工作流程設定相應的工作指南和工作檢查點
      .　每個角色承擔相應的質量任務
 　　    .　角色的每個任務要產(chǎn)生合格的工件
           .　產(chǎn)品的每個工件建立工件指南、模板和工件檢查點
　　在RUP中，整個軟件開發(fā)過程如上圖所示，它以指定的工件為輸入，通過軟件開發(fā)角色和標準化的軟件開發(fā)活動，生產(chǎn)出滿足質量要求的輸出工件。為確保每個工作環(huán)節(jié)的有效執(zhí)行和每個工作環(huán)節(jié)產(chǎn)生的工件質量，RUP為主要工作流程提供了對應的工作指南和檢查點，為每個工件建立指南、模板和檢查點，從而保證了軟件開發(fā)的過程質量。
　　大家可能都曾注意到，RUP的九個核心工作流程并沒有一個質量保證的流程。原因就在于我們認為質量是在產(chǎn)品各個流程中形成的一種產(chǎn)品的屬性，而不是一件流程，質量就是質量。它意味著，應當在你的過程中關注每一個步驟的質量。理解這個，是創(chuàng)建一個真正成功的應用軟件交付過程的關鍵。
　　我們都曾經(jīng)誓言視質量為產(chǎn)品的生命，在此在回顧一下我們的誓言，將使我們更有信心沿著正確的道路走下去。
　
　　.　過程質量
　　努力建立組織級別的，可以針對不同類型項目，指定項目管理的流程，工作分配和檢查點。在項目較多是，可以考慮使用項目組合管理工具來導入在RUP基礎上裁剪的項目管理模板進行輔助管理，以保障過程的貫徹實施和監(jiān)控。
　　當我們考慮使用RUP時，大家常常因為自己不是迭代化的開發(fā)方式，認為RUP對自己沒有價值。其實，即便我們暫時不準備采用迭代化的開發(fā)方式，我們也可以把一個V型的開發(fā)模式當作一個迭代，來從RUP中吸取其他值得我們參考的思想，改進我們的實際流程。本身在RUP的迭代方式模型中，就有一個類似于瀑布的稱之為“Grand design” 的開發(fā)方式，來應對小型的，或是大型又極端重要的，需求長時間保持清晰穩(wěn)定的項目開發(fā)。
　　實際上大家實際工作中都或多或少的采取了一些迭代開發(fā)的方式，首先在很多關鍵領域的項目開發(fā)中采取的預言、初樣、正樣的方式，本身就是可以認為是某種形式的迭代，我們可以順利的沿用自己習慣的開發(fā)方式，在RUP的過程和工具中吸取對我們有效的部分，并在其他條件成熟時在細化現(xiàn)有開發(fā)模式階段的粒度。
　　美國國防部原本提倡瀑布過程和觀點，在發(fā)現(xiàn)那么多采用了該方法的失敗之后，不但不再強調對它的要求(如1988年的STD-2167A標準)，而且從1994年的報告開始，積極地鼓勵采用更加現(xiàn)代化的迭代式生命周期來取代瀑布型做法。

{{分頁}}
　　
　　.　軟件工程成功經(jīng)驗共同鑄就軟件質量的思想
　　激烈的市場競爭催生高質量的軟件。同時，軟件行業(yè)經(jīng)過幾十年的發(fā)展，軟件生產(chǎn)工藝、軟件開發(fā)方法和工具都大大進步、日趨成熟，這一切使開發(fā)人員盡可采用更給高效的開發(fā)方式，盡享其帶來的好處，開發(fā)高質量的軟件。RUP以迭代式軟件開發(fā)、架構為核心的軟件開發(fā)、用例驅動的軟件開發(fā)和風險驅動的軟件開發(fā)為特色，集中體現(xiàn)了以下六個軟件工程成功經(jīng)驗，通過它們共同鑄就了高品質軟件：
　　　　.　迭代式軟件開發(fā)：能夠有效控制項目風險、增加對項目控制能力、減少需求變更對項目的影響，實現(xiàn)持續(xù)的質量驗證，實現(xiàn)測試技術的早期驗證，提高軟件的可測試性；
 .　有效管理需求：能夠做到質量保證從頭作起，在軟件開發(fā)一開始，就把好需求質量關，實現(xiàn)需求的可追蹤性和需求變更的有效管理；
 .　基于構件的軟件架構：采用可視化建模技術來構建以構件為基礎、面向服務的系統(tǒng)框架，可以有效地管理系統(tǒng)的復雜度，增強系統(tǒng)的靈活性和可擴展性，并解決了大家在采用迭代設計方法時構件不易識別和劃分的問題；
 .　可視化建模：能夠有效解決團隊溝通、管理系統(tǒng)復雜度、提高軟件重用；
 .　持續(xù)的質量驗證：借助迭代式軟件開發(fā)方法，可以大大提前軟件集成測試和系統(tǒng)測試在整個開發(fā)生命周期中的時間，實現(xiàn)持續(xù)地軟件質量驗證，做到盡早測試、盡早反饋，從而確保產(chǎn)品滿足客戶的需求；
 .　管理變更：能夠為整個軟件開發(fā)團隊提供基本協(xié)作平臺，使企業(yè)管理好自己的軟件資產(chǎn)，通過有效管理所有的變更請求，使開發(fā)團隊能夠很好的控制開發(fā)進度、及時了解項目狀況，同時為項目的量化管理提供幫助。
　　由此可見，在軟件開發(fā)過程中，高品質軟件是由以上軟件工程的成功經(jīng)驗共同鑄就的。
　
　　.　盡早測試
　　作為質量保證工作的一部分，盡早測試是指在整個軟件開發(fā)生命周期中通過各種軟件工程技術盡量早的完成各種軟件測試任務的一種思想。IBM Rational主要在以下三個方面為我們提供的盡早測試的軟件工程技術：
　　首先，軟件的整個測試生命周期是與軟件的開發(fā)生命周期基本平齊的過程，保證當軟件的第一個發(fā)布出來后，測試人員要馬上基于它進行測試腳本的實現(xiàn)，并基于測試計劃中的測試目的執(zhí)行測試用例，對測試結果進行評估報告。這樣，我們可以通過各種測試指標實時監(jiān)控項目質量狀況，提高對整個項目的控制和管理能力。
　
　　其次，通過迭代是軟件開發(fā)把原來的整個軟件開發(fā)生命周期分成多個迭代周期，在每個迭代周期都進行測試，這樣在很大程度上提前了軟件系統(tǒng)測試發(fā)生的時間，這可以在很大程度上降低項目風險和項目開發(fā)成本。
　　最后，IBM Rational的盡早測試成功經(jīng)驗還體現(xiàn)在它擴展了傳統(tǒng)軟件測試階段從單元測試、集成測試到系統(tǒng)測試、驗收測試的劃分，將整個軟件的測試按RUP中的角色和階段，劃分成開發(fā)人員測試和系統(tǒng)測試兩個階段，把軟件的測試責無旁貸地擴展到整個開發(fā)人員的工作過程。通過提前測試發(fā)生的時間來盡早地提高軟件質量、降低軟件測試成本。

　　.　持續(xù)測試
　　作為質量保證工作的一部分，測試成功經(jīng)驗持續(xù)測試是從迭代式軟件開發(fā)模式得來。在迭代的方法中，我們將整個項目的開發(fā)目標劃分成為一些更易于完成和達到的階段性小目標，這些小目標都有一個定義明確的階段性評估標準。每個迭代中都包括需求、設計、編碼、集成、測試等一系列的開發(fā)活動，都會增量式集成一些新的系統(tǒng)功能。通過每次迭代，我們都產(chǎn)生一個可運行的系統(tǒng)，通過對于這個可運行系統(tǒng)的測試來評估該次迭代有沒有達到預定的迭代目標，并以此為依據(jù)來制定下一次迭代的目標。由此可見，在迭代式軟件開發(fā)的每個迭代周期我們都會進行軟件測試活動，整個軟件測試的完成是通過每個迭代周期不斷增量測試和回歸測試實現(xiàn)的。
　　采用連續(xù)測試的軟件成功測試經(jīng)驗，不但能夠持續(xù)的提高軟件質量、監(jiān)控質量狀態(tài)，同時也使系統(tǒng)測試的盡早實現(xiàn)成為可能。從而有效的控制開發(fā)風險、減低測試成本和保證項目進度。

　　.　自動化測試
　　作為質量保證工作的一部分，在整個軟件的測試過程中要想實現(xiàn)盡早測試、連續(xù)測試，可以說完善的測試流程是前提，自動化測試工具是保證。方法是質量保證活動的基礎，工具的作用多體現(xiàn)在對質量保證活動的自動化，以提高工作效率。我們可以體會到，沒有質量保證活動的最佳方法，工具的自動化沒有實現(xiàn)的基礎，工具的作用無法體現(xiàn)；沒有工具輔助的質量保證活動，也會因為太高的工作強度，或過于文檔化、太繁瑣而無法實施貫徹。自動化測試的實現(xiàn)，使軟件測試團隊能夠將更多的經(jīng)歷放在更有創(chuàng)造性的工作上，并且將降低由于規(guī)章制度的遵從性需求給開發(fā)測試人員帶來的額外的工作量。

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

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

{{分頁}}
　　為減少重復描述，先將相關工具的功能統(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ī)則檢查、單元測試、覆蓋率分析、內存分析、性能分析、代碼跟蹤、線程分析、基于消息的分布式系統(tǒng)測試的跨平臺解決方案。
　　要推動團隊溝通、協(xié)作和合作，IBM Rational還提供額外的解決方案：
　　IBM Rational RequisitePro 用于需求和用例管理 。
　　IBM Rational ClearQuest 用于基于工作流的缺陷和變更管理 。
　　IBM Rational ClearCase 用于配置管理。
　　IBM Rational Method Composer 用于組織開發(fā)方法的構造和發(fā)布。
　　IBM Rational ProjectConsole 使管理人員能夠更加形象的了解項目質量狀態(tài)。它支持由開發(fā)環(huán)境自動收集的數(shù)據(jù)，動態(tài)產(chǎn)生有網(wǎng)頁形式發(fā)布的一個項目狀況和數(shù)據(jù)矩陣。
　　IBM Rational SoDA自動地產(chǎn)生和維護全面的項目文檔和報告。
　　順便提一下，在開發(fā)方面，我們還有Apex——針對高安全性嵌入式系統(tǒng)Ada語言開發(fā)工具Rational Ada Developer。
　　
　　.　分析
　　Meta Group報告，引起客戶不滿意問題的百分之八十可以追溯到對需求的糟糕理解上。對于任何嵌入式開發(fā)項目，不論是新的系統(tǒng)開發(fā)，或遺留系統(tǒng)更新集成，質量開始于分析業(yè)務，以確保系統(tǒng)需求清晰且準確地反映了業(yè)務和客戶需求。
　　首先，我們可以將被測系統(tǒng)置于其將運行的環(huán)境中，采用建模的方式，激發(fā)和整理用戶業(yè)務和分析人員的思維，捕獲盡可能完整的需求，并在后續(xù)的迭代中完善；通過建模的分析方式，建立松耦合、接口清晰的架構，為測試的設計提供基礎；通過采用相適應的架構機制，提高系統(tǒng)的可測試性；通過采用流程管理工具，自動化輔助需求的評估和審計；將最優(yōu)確認的需求，用條目化的方式管理需求文檔，實現(xiàn)從需求，到分析，到設計，到實現(xiàn)，到測試的雙向跟蹤，以實現(xiàn)測試中發(fā)現(xiàn)缺陷到各層次的跟蹤，和影響范圍的分析。
　　此活動的工具包括Rational RequisitePro、Rational System Developer、Rational ClearQuest。

　　.　設計
　　在設計中，主要的質量集中在構架上，這是軟件的“靈魂”。低質量的構架會引起大范圍的質量問題，包括（軟件）脆弱，缺乏升級，以及發(fā)現(xiàn)缺陷也難以修改。這些問題隨著應用軟件項目不斷發(fā)展，變得越來越難以解決；并且隨著應用軟件從設計到開發(fā)、測試和部署，糾正缺陷的成本以指數(shù)在增長。如果軟件開發(fā)人員可以有效地發(fā)現(xiàn)、隔離和解決設計和開發(fā)期間的結構上的不足，這項工作會在整個項目期間獲得受益。開發(fā)人員也應該確保，軟件是按照一種保持構架完整性和靈活性的方式來實現(xiàn)的，因此，隨著業(yè)務需求變化，開發(fā)人員可以快速地進行變更。
　　針對此工作流程的工具有Rational System Developer、Rational RequisitePro。

　　.　開發(fā)
　　平均起來，開發(fā)人員在他們寫的每千行代碼中會產(chǎn)生100到150個錯誤。當然，這個數(shù)量隨著開發(fā)人員和項目不同而不同。即使只有一小段代碼，產(chǎn)生百分之十的錯誤也是很嚴重的。
　　RUP倡導開發(fā)人員主導的測試和分析上。盡管單元測試和運行時分析已經(jīng)變得更為主流，但是許多管理人員仍然有這樣的誤解，即這些過程向時間表中增加了不必要的時間。事實上，如果不采用這些措施，開發(fā)時間表通常會一樣或更加延長，這是由于在質量保證或客戶發(fā)現(xiàn)問題后，開發(fā)人員在生命周期中調試代碼后所花費的時間。對于那些想要減少風險和增加可預測性的團隊來說，開發(fā)團隊采用一種良好結構的、主動的質量保證方法是一個好的解決方案。
　　針對此工作流程的工具有Rational System Developer、Rational Test RealTime、IBM Rational TestManager、IBM Rational RequisitePro。

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

　　.　支持保證質量的團隊職責
　　質量是開發(fā)團隊中的每個人的職責，但是它也是團隊作為一個整體的職責。在一個迭代的過程中，每個迭代確保了每個工件質量的持續(xù)的重新評估，這樣，迭代的方式下，經(jīng)常可以保證提交質量更高的產(chǎn)品，也就不奇怪了。團隊必須做他們可以做的任何事情，來控制迭代中的活動和工件，建立可追溯性，并簡化溝通。有效的軟件配置管理和變更管理是保證質量的一個基本工具；它幫助組織確保軟件在每次構建是可重復的和可靠的，并且保證缺陷和變更請求得到正確的管理。
　　針對此工作流程的工具有IBM Rational Team Unifying Platform，一套完整的基本工具和過程，這個平臺包括 Rational Unified Process、Rational RequisitePro、Rational ClearCase、Rational ClearQuest、Rational ProjectConsole。

五. 質量過程改進的步驟

　　當我們考慮需要什么來構建任務關鍵和高安全性的系統(tǒng)軟件，并聽說過程質量改進時，大家往往想到的一個復雜的過程。其實，軟件過程質量改進，如軟件開發(fā)，可以是一個迭代的過程。你不需要一步就完成所有的事情。即使是小的變化，包括調整你的組織中對質量的看法，也會產(chǎn)生一個切實的改進。
　　我們將給大家指出兩條參考的改進的線路圖，我們分別稱之為遞進式的（或者可以稱之為本質的）和演進式的（我也稱之為反應式的）。遞進式的更多考慮工作流程間的依賴性，做到先改善基礎流程，在基于已有的改善基礎，做進一步改進。而演進式的多來自于工作中感知到的問題和瓶頸，依據(jù)問題的表面做反應式的改進?；诟倪M后再發(fā)現(xiàn)新的問題，如此反復。當然，我也在努力發(fā)現(xiàn)一種可以兼顧工作流程間依賴性，有可以快速顯示改進效果的改進方式。
　　從個人角度看，由于理解有局限，我的建議常常還是反應式的。即使在這樣很難考慮到太多前瞻性的工作方式中，我們需要注意：1. 我們是不是了解自己現(xiàn)在的瓶頸，并以此確定方向，并始終堅持自己的方向。2. 我們是不是可以做的更好，我們的改善有更多的預見性，對問題分析，從表面到本質，而不僅僅是反映式的。
　　質量保證工作改善我們可以簡單的劃分為以下幾個方面：
　　配置管理和變更管理、靜態(tài)分析和單元測試、集成測試和系統(tǒng)測試、迭代開發(fā)和連續(xù)測試、全過程質量、組織級質量體系、架構分析、需求管理、項目管理。我們將在以后的文章中詳細描述每種改進的內容。
遞進式的改進方式。

{{分頁}}
　
演進式的實施方式。
 
六. 對質量保證的幾種理解

　　一下主題，僅是我們所見到和所希望達到的對軟件質量的幾種不同的理解，沒有順序關系，也不涉及改進先后的建議。

6.1. 測試是重要并應該智能的

　　在這樣的嵌入式系統(tǒng)開發(fā)團隊中，團隊成員已經(jīng)認識到軟件質量的重要性，并努力謀求在軟件質量方面的改善，并且積極的尋求適當?shù)姆椒?，提高測試的效率和易用性，并且意圖構建可以無縫融入原有開發(fā)流程中的測試方法。這些目標，也是我們的目標。
　　我們也應該看到，無論什么樣的方法和工具，目前，都無法改變這樣一個事實，軟件開發(fā)和測試工作是艱苦的?！耙子眯浴爆F(xiàn)在常常是個被過度使用的概念?，F(xiàn)在還不存在這樣的工具，他能成為軟件測試的精靈手杖和魔術子彈。軟件開發(fā)團隊不應寄希望于只要自己使用了某種軟件測試工具，那么就應該可以獲取測試帶來的種種好處。當一個工具給大家這樣的印象時，我們只需要回顧軟件質量在客戶需求方面的幾個需要考慮的維度上，它滿足的那些？一個按鈕的解決方案是存在的，但我們可以看看這樣的測試工具主要完成了什么類型的測試工作，我們應該如何使用他們，應該在什么情況下引進他們才是最有效果的。采取與所處階段不相符的測試方法，實際上不但無法達到提高產(chǎn)品質量的目的，而且往往由于實施的環(huán)境不具備，這些工具本身應該具有的功能也無法實現(xiàn)。這樣的工具，在研發(fā)團隊中被束之高閣也就變得在所難免了。
　　在這一過程中，我們建議在于，回顧組織對軟件質量的定義；并圍繞這一定義，結合組織的特點，找到目前工作的著眼點（以文中反應式的改進路線看，就是發(fā)現(xiàn)工作中的質量瓶頸，可參考文中提到的改進路線圖）；緊緊圍繞這一著眼點，來指定相關的流程方法（對流程有疑問，可以致電IBM Rational）；圍繞這一方法，發(fā)現(xiàn)方法實施中可以通過自動化工具有效提高效率的地方；依此尋求工具支持。而不應反而以易用性選工具，以工具定測試需求，以需求來配套方法。

6.2. 系統(tǒng)測試保證產(chǎn)品質量

　　在這樣的嵌入式系統(tǒng)開發(fā)團隊中，團隊成員解決了原來的系統(tǒng)測試可視化程度不高的問題，在原有的測試激勵環(huán)境下，構建了相應的測試系統(tǒng)，提供可以量化的覆蓋率、性能等指標。并且把量化的系統(tǒng)測試當成對整個開發(fā)過程健康狀況的評審和反饋，提出以測試促進軟件工程的思想，這些是值得我們借鑒的。
　
　　我們也應該看到，由于缺乏早期的測試活動，產(chǎn)品的質量問題在集成和系統(tǒng)階段被發(fā)現(xiàn)，往往造成修改代價過高，有時對一個早期沒有建立良好架構的系統(tǒng),甚至由于害怕的修改引入新的更嚴重的故障而保留缺陷發(fā)布；由于沒有統(tǒng)一的工具用于單元和系統(tǒng)測試階段，甚至沒有單元測試，使測試工具在系統(tǒng)級需要解決很多和用戶編碼風格兼容性問題；同時發(fā)現(xiàn)由于早期未采用迭代化的開發(fā)方式下，而且即便是瀑布式的開發(fā)方式，在早期也沒有注意測試技術的考慮和驗證，知道產(chǎn)品即將交付時，才發(fā)現(xiàn)測試技術未經(jīng)過實際的驗證，不適應系統(tǒng)測試的需求，尋求新的測試方式無疑是為即將到來的發(fā)布雪上加霜；即便有可用的測試方法，由于在系統(tǒng)設計早期，測試團隊沒有介入到系統(tǒng)開發(fā)中去，我們所構建的系統(tǒng)不具備可測試的條件；同時，早期設計時，急于開展編碼，沒有對系統(tǒng)進行清晰的需求分析和設計，只能為測試提供含糊的需求；沒有預先準備的測試計劃和測試用例；這樣的系統(tǒng)測試,往往不得已又陷入了只能做“一個按鈕，一本報告”的輕松局面；這種測試，甚至起到的相反的示范效應，增強了開發(fā)團隊對測試效果的懷疑，同時開發(fā)團隊也沒有意識到自己其實就是質量形成的主體。
　　在這一過程中，我們建議在于，加強單元測試，不但可以消除一些可以在單元階段可以消除的問題，而且可以通過在單元和系統(tǒng)階段使用相同的工具，這樣，即使是瀑布式的開發(fā)方式，系統(tǒng)測試技術也能及早的加以驗證，提高可用性；加強系統(tǒng)需求分析和架構設計，是系統(tǒng)架構強內聚、弱耦合、接口明確，提高系統(tǒng)的可測試性；在系統(tǒng)開發(fā)的早期，測試人員作為系統(tǒng)開發(fā)團隊的重要部分，參與系統(tǒng)設計流程，解決測試相關問題（有那些問題，RUP中有詳述），為測試對設計提出要求；加強軟件開發(fā)過程的管理，為測試提供清晰明確的需求和架構；

6.3. 分階段測試提高測試效率

　　在這樣的嵌入式系統(tǒng)開發(fā)團隊中，建立了在經(jīng)典測試理論體系中包含的靜態(tài)分析，單元測試，集成測試，系統(tǒng)測試的測試工作和相應的配套的自動化工具，對各種測試的責任人有認識上的理解和劃分，有一些測試過程中需要的和產(chǎn)生相關文檔，對測試流程有一些零散的制度和自發(fā)的實施行為。
　　我們也應該看到，在這樣的組織中，常常存在由于不恰當?shù)膶卧獪y試的理解，導致為覆蓋率而編寫測試用例的傾向，促使開發(fā)人員認為單元測試流于形式，沒有實際作用；對單元測試的不理解，根據(jù)代碼編寫用例的工作方式，從態(tài)度上滋生的抵觸情緒，認為單元測試和單元測試工具是增加工作負擔的形式主義；由于在設計時沒有考慮測試的需要，測試人員也從未介入過設計工作，軟件的可測試性需求得不到體現(xiàn)，甚至測試人員也認為良好的測試就應該是對開發(fā)毫無影響的測試；被測試的軟件本身并不具備可測試性，使用多么昂貴的測試工具也很難發(fā)揮作用；對設計文檔的需求，包括需求文檔到詳細的軟件規(guī)格說明的需求得不到滿足，開發(fā)人員也往往是更具模糊的、口頭達成的設計開始編碼；沒有組織級別的測試體系和度量標準；測試行為和對工具的使用多出自于人為的自覺；工具散落在組織各處，項目間測試經(jīng)驗、甚至測試工具使用經(jīng)驗都得不到整理和傳承；在組織內，沒有人負責測試流程和測試工具支持的工作。

{{分頁}}
　　在這一過程中，我們建議在于，建立基于組織的開發(fā)測試體系和輔助工具管理方式，制度化并通過使用工具幫助在組織中貫徹實施；大家可以參考rational的RUP統(tǒng)一過程的最佳實踐，和Rational Method Composer定制和部署適合自己的工具；使用各類管理工具，對軟件開發(fā)過程的基礎管理實現(xiàn)盡可能高的自動化，使用IBM Rational ProjectConsole，將基礎項目數(shù)據(jù)形象的展現(xiàn)管理者；重視軟件測試團隊的作用，在系統(tǒng)設計時，要理解和鼓勵測試人員參與到早期設計的需要；測試人員積極介入系統(tǒng)的設計，提高對系統(tǒng)的把握能力，在系統(tǒng)設計時期，加入系統(tǒng)可測試性的屬性，驗證系統(tǒng)測試方法。

6.4. 完善的質量保證的活動

　　在這樣的嵌入式系統(tǒng)開發(fā)團隊中，作為一個單獨的活動，建立的獨立的V&V（驗證和確認）的流程，通過驗證評估各個開發(fā)階段產(chǎn)出的工件的質量，包括各種形式的設計文檔和工件，通過確認，評價各個開發(fā)階段于對本階段需求的符合程度，建立的對開發(fā)各個階段完善的評估和反饋體制。
　
　　在這一過程中，我們建議在于，我們鼓勵組織成員，將軟件質量不要僅僅限于測試團隊或僅僅某些過程，我們要力求引到組織邁向全過程質量管理之路；，檢測僅僅是項目質量狀態(tài)的審查和反饋的過程；我們可以將視野放在RUP的整個九個工作流程，從中提取我們可以采納的提高質量的工作方法，和基于每個角色和每個任務的檢查方式；加強系統(tǒng)的架構設計，建立高質量、易于維護、易于改進的體系架構；考慮采用迭代的設計方法，將強調早期文檔的驗證工作，轉向到更強調對每個迭代結束以后的可執(zhí)行系統(tǒng)的驗證。

6.5. 基于組織的高質量的過程

　　在這樣的嵌入式系統(tǒng)開發(fā)團隊中，開發(fā)機構建立了完善的開發(fā)流程和各個階段的管理手段。建立了基于軟件開發(fā)全過程檢測，力爭在開發(fā)過程本階段修正錯誤能力。組織對于質量的理解，已經(jīng)從減少軟件運行錯誤、加強軟件測試、避免軟件缺陷的一般性層面，發(fā)展到對整個軟件開發(fā)生命周期的全過程質量管理；這樣組織中的質量管理部門，主要負責開發(fā)流程的執(zhí)行，并專門負責制定產(chǎn)品開發(fā)流程，他針對整個軟件開發(fā)流程，關心的是怎樣在軟件開發(fā)生命周期中來保證好軟件的質量。
　
　　在這一過程中，我們可以相互學習，來追逐軟件開發(fā)過程管理的更高目標，從在開發(fā)過程中盡早發(fā)現(xiàn)與修正錯誤，進展到盡量預防錯誤的出現(xiàn)。通過對錯誤的分析，完善各階段的檢測手段，做到在本開發(fā)階段發(fā)現(xiàn)及修正錯誤。這是軟件過程改進的一項重要內容，是開發(fā)機構可以預期有一個高質量的產(chǎn)品及一個低成本、高效率的軟件過程的重要標志。

6.6. 迭代開發(fā)持續(xù)測試保證軟件質量

　　迭代式軟件開發(fā)，能夠有效控制項目風險、增加對項目控制能力、減少需求變更對項目的影響，實現(xiàn)持續(xù)的質量驗證，實現(xiàn)測試技術的早期驗證，提高軟件的可測試性；保證持續(xù)地質量保證的實現(xiàn)。主要說明，所有的開發(fā)活動和工件都需要通過持續(xù)的測試和復審來檢查質量。這意味著測試不僅僅是軟件構建之后的一個階段。測試是在整個迭代開發(fā)周期中執(zhí)行的，每次都有一個不同的目標，依照RUP這是大家都知道的一個任務。例如，測試在精化階段，可以集中在確認構架上，而在構建階段中，測試可以集中在查找最重要的軟件缺陷上。

6.7. 質量是一種文化

　　在這樣的組織中，我們專注于我們的客戶和客戶的客戶的價值，并以此為產(chǎn)品質量的最終衡量標準，了解軟件交付的質量，不僅僅是軟件會出多少個故障，這很重要，但不只是這些，更多的要幫助我們的用戶了解最終客戶業(yè)務的價值。
質量改進本質上是一種思維習慣問題。

七. 從上至下驅動質量

　　續(xù)保證質量要求管理和工作的付出，這些需要從領導高層至下驅動的，它要求領導和組織復雜事務的管理能力。質量改進本質上是一種思維習慣問題；當來自上層的管理人員在整個組織慢慢灌輸質量文化時，質量就會滲透到每個項目中。
　　在這樣一種文化中，工作會給管理人員提供極大的好處。他們不再必須考慮帶有已知或未知缺陷而發(fā)貨的產(chǎn)品運行可能的后果，。并且促使產(chǎn)生質量的嚴格過程、團隊責任心和目標矩陣也創(chuàng)建了項目進度和質量的可預言性。與那些不斷地重新確定項目范圍，并且仍然錯過期限的團隊不同，高質量的團隊可以精確地確定范圍、估算和確定時間，并且順利地在計劃的經(jīng)費和工期內交付。這樣的開發(fā)體系，可以有助于你的產(chǎn)品的質量水平和產(chǎn)品功能有別于你的競爭對手。

八. 獲得軟件高質量的高收益

　　最重要的是，全過程的質量保證體系總是會比忽略考慮質量成本要低。事實上，提高產(chǎn)品質量基本上沒有成本，如果你正確地做的話。
在國際上，隨著軟件質量保證理論及應用研究工作的不斷深入，針對軟件質量保證工作的工作重點也經(jīng)歷了如下發(fā)展歷程：
　　1. 70年代以前，Ad-hoc testing，與調試沒有區(qū)分；
　　2. 70年代末到80年代中期，測試基礎理論和實用技術形成，軟件測試作為軟件質量保證（SQA）的主要手段和職能；
　　3. 80年代末到90年代中期，測試工具在質量和數(shù)量上不斷增長，測試與SQA（注重于過程和質量監(jiān)督）分離。注重于工具對測試效率的影響；SQA為另一專業(yè)領域。
　　4. 90年后期到目前，重新關注有效的過程管理對于軟件測試的重要性，將軟件工程視為軟件測試的基礎，或形成各種獨立的測試模型、測試能力成熟度模型。
　　我們現(xiàn)在哪里呢？
　　高品質軟件，需要完整的軟件開發(fā)過程和整合的軟件開發(fā)平臺來共同鑄就。IBM Rational軟件開發(fā)平臺，就是以各種國際標準和開放平臺為基礎，為嵌入式系統(tǒng)軟件產(chǎn)品的開發(fā)和生產(chǎn)過程提供了前所未有的開發(fā)速度和質量保證。
　　本文的很多思想都來源于IBM developerWorks Web上的文章，對細節(jié)有興趣的開發(fā)人員可以在此網(wǎng)站上瀏覽更多相關文章。IBM也提供了許多服務，幫助開發(fā)團隊交付高質量軟件。開發(fā)人員可以參加面對面和基于Web的培訓課程，這些課程都通過IBM developerWorks Web門戶，集中在工具使用和技巧改進上，并且專業(yè)服務咨詢可以與開發(fā)團隊一起創(chuàng)建定制質量實施計劃，生成初始的項目評估、安裝、指導、培訓和維護。