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

IBM中國有限公司軟件部高級(jí)技術(shù)顧問 靳超

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

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

二. 定義質(zhì)量

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

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

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

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

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

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

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

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

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

四. 用正確的過程和平臺(tái)實(shí)現(xiàn)質(zhì)量

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

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

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

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

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

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

五. 質(zhì)量過程改進(jìn)的步驟

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

{{分頁}}
　
演進(jìn)式的實(shí)施方式。
 
六. 對(duì)質(zhì)量保證的幾種理解

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

6.1. 測(cè)試是重要并應(yīng)該智能的

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

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

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

6.3. 分階段測(cè)試提高測(cè)試效率

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

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

6.4. 完善的質(zhì)量保證的活動(dòng)

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

6.5. 基于組織的高質(zhì)量的過程

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

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

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

6.7. 質(zhì)量是一種文化

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

七. 從上至下驅(qū)動(dòng)質(zhì)量

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

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

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