第一篇：淺談軟件質(zhì)量保證

淺談軟件質(zhì)量保證

摘要：

Software Quality Assurance軟件質(zhì)量保證（SQA）是建立一套有計劃，有系統(tǒng)的方法，來向管理層保證擬定出的標準、步驟、實踐和方法能夠正確地被所有項目所采用

前言：

SQA的由來：隨著第一個正式的質(zhì)量保證和控制方案在1916年貝爾實驗室的出現(xiàn)，整個制造業(yè)都認可了這一方案，時至今日每個公司都有其保證其產(chǎn)品質(zhì)量的機制，公司對質(zhì)量的保證也漸漸成為其核心的市場策略。對于軟件開發(fā)來說，一個項目的主要內(nèi)容是：成本、進度、質(zhì)量。軟件本身作為一種無形產(chǎn)品，其質(zhì)量指的是：“系統(tǒng),部件或者過程滿足顧客或者用戶需要或期望的程度”。在20世紀五六十年代，質(zhì)量保證曾經(jīng)只由程序員承擔。而正規(guī)的軟件質(zhì)量保證標準首先在20世紀70年代初軍方的軟件合同中出現(xiàn)，此后迅速傳遍整個商業(yè)世界。提出而隨著市場化發(fā)展的成型，任何軟件公司對自己產(chǎn)品的質(zhì)量問題越來越關(guān)注，測試所花費的成本越來越多。在起初國外很多的大軟件公司公司比如IBM、CA等，SQA的職責就是測試（主要是系統(tǒng)測試）。后來，由于缺乏有效的項目計劃和項目管理，留給系統(tǒng)測試的時間很少。另外由于軟件最終使用者的不專業(yè)性，需求變化太快，沒有完整的需求文檔，測試人員就只能根據(jù)自己的想象來測試。這樣一來，測試就很難保障產(chǎn)品的質(zhì)量，促進了事先預防的SQA職能的產(chǎn)生。隨后隨著軟件開發(fā)模型的不斷演化和發(fā)展CMM模型的出現(xiàn)，它引入了“全面質(zhì)量管理”的思想，至此許多公司將SQA人員獨立于項目組，以保證評價的客觀性。專業(yè)的SQA人員應運而生。

簡介：

軟件質(zhì)量保證（SQA）是建立一套有計劃，有系統(tǒng)的方法，來向管理層保證擬定出的標準、步驟、實踐和方法能夠正確地被所有項目所采用。其根本目的是使軟件過程對于管理人員來說是可見的。它通過對軟件產(chǎn)品和活動進行評審和審計來驗證軟件是合乎標準的。軟件質(zhì)量保證組在項目開始時就一起參與建立計劃、標準和過程。這些將使軟件項目滿足機構(gòu)方針的要求。

SQA的基本目標：

1: 軟件質(zhì)量保證工作是有計劃進行的。

2: 客觀地驗證軟件項目產(chǎn)品和工作是否遵循恰當?shù)臉藴?、步驟和需求。3: 將軟件質(zhì)量保證工作及結(jié)果通知給相關(guān)組別和個人。

4: 高級管理層接觸到在項目內(nèi)部不能解決的不符合類問題。

具體分析：

1：軟件質(zhì)量所包含的因素及軟件質(zhì)量評價標準：

軟件質(zhì)量包含的因素：正確性，可靠性，效率，完整性，可用性可維護

性，靈活性，可測試性，可移植性，可復用性，互操作性等等。

軟件質(zhì)量評價標準：質(zhì)量需求準則，著眼點是是否滿足用戶的要求；質(zhì)量設(shè)計準則，開發(fā)者在設(shè)計實現(xiàn)時是否按軟件需求保證了質(zhì)量。質(zhì)量度量準則，為質(zhì)量度量規(guī)定了一些檢查項目。

從事專業(yè)SQA的人員所應具備的基本素質(zhì)，工作中的基本職能及與其他相似職能的區(qū)別：

SQA人員所應具備的基本素質(zhì)：

按照軟件界已經(jīng)達成的共識：影響軟件項目進度、成本、質(zhì)量的因素主要是 “人、過程、技術(shù)”。首先要明確的是這三個因素中，人是第一位的。SQA小組的成員首先應當時刻以客戶的觀點看待軟件。從事SQA工作由于要按照相應的標準對專業(yè)的行為加以監(jiān)管，深刻了解企業(yè)的工程，并具有一定的過程管理理論知識 對開發(fā)工作的基本情況了解，能夠理解項目的活動，因此首先應具備較高的關(guān)于軟件開發(fā)方面的知識；在工作中過程為中心：應當站在過程的角度來考慮問題，只要保證了過程，QA就盡到了責任；還應具有服務精神即為項目組服務，幫助項目組確保正確執(zhí)行過程；另外應善于溝通，能夠營造良好的氣氛，避免其工作本身成為一種找茬活動。我所在的小組在課程實踐過程中就出現(xiàn)過負責設(shè)計的同學對編碼階段的同學出現(xiàn)質(zhì)疑，最終出現(xiàn)不愉快的事情。

工作中的基本職能以及于其他相似職能的區(qū)別：

要做好SQA工作首先應該明確SQA人員的職能以及與QC、SEPG的區(qū)別。QC：檢驗產(chǎn)品的質(zhì)量，保證產(chǎn)品符合客戶的需求；是產(chǎn)品質(zhì)量檢查者； SEPG：制定過程，實施過程改進；

而SQA人員的主要工作為審計過程的質(zhì)量，是過程質(zhì)量審計者，其基本職能為確保過程被正確執(zhí)行。其本身并不參與過程的制定，A的職責就是確保過程的有效執(zhí)行，監(jiān)督項目按照過程進行項目活動；它不負責監(jiān)管產(chǎn)品的質(zhì)量，不負責向管理層提供項目的情況，不負責代表管理層進行管理，只是代表管理層來保證過程的執(zhí)行。

3：SQA活動：

軟件質(zhì)量保證由各種任務構(gòu)成，這些任務分別與兩種不同的參與者有關(guān)：做設(shè)計工作的軟件工程師和SQA小組成員。

軟件工程師通過采用可靠的技術(shù)方法和措施，進行正式的技術(shù)評審，執(zhí)行計劃周密的軟件測試來考慮質(zhì)量問題（并完成軟件質(zhì)量保證和質(zhì)量控制活動）

SQA小組成員的職責為輔助軟件工程小組得到高質(zhì)量的最終產(chǎn)品。其主要工作如下：

為項目準備SQA計劃。該計劃在制定項目計劃實制定，由所以感興趣的相關(guān)部門評審。該計劃將控制由項目組和SQA小組執(zhí)行的質(zhì)量保證活動。在計劃中應標識一下幾點：需要進行的評價；需要進行的審計和評審；項目可用的標準；錯誤報告和跟蹤的規(guī)程；由SQA小組產(chǎn)生的文檔；為軟件項目提供的反饋數(shù)量。另外還需明確最終審計的結(jié)果報告給誰。

參與開發(fā)該項目的軟件過程描述。軟件工程小組為要進行的工作選擇一個過程。SQA將評審過程描述以保證該過程與組織政策，內(nèi)部軟件標準，外界所訂標準（如ISO9001）以及軟件項目計劃的其他部分相符。

評審各項軟件工程活動，對其是否符合定義好的軟件過程進行核實。SQA小組識別記錄和跟蹤與過量的偏差，并對是否已經(jīng)改正進行核實。

審計指定的軟件工作產(chǎn)品，對其是否符合定義好的軟件過程中的相應部分進行核實。SQA小組對選出的產(chǎn)品進行評審；識別，記錄和跟蹤出現(xiàn)的偏差；對是否已經(jīng)改正進行核實；定期將工作結(jié)果向項目管理者報告。在審計過程中。注意審計一定要有項目組人員陪同，雙方要開誠布公，坦誠相對。審計的內(nèi)容主要包括：是否按照過程要求執(zhí)行了相應活動，是否按照過程要求產(chǎn)生了相應產(chǎn)品。

確保軟件工作及工作產(chǎn)品中的偏差已被記錄在案并根據(jù)預定規(guī)程進行處理。偏差可能出現(xiàn)在項目計劃，過程描述，采用的標準或技術(shù)工作產(chǎn)品中。

記錄所有不符合的部分并報告給高級管理者。對不符合的部分進行跟蹤直至問題得到解決。

4：軟件評審：軟件評審是軟件工程過程中的過濾器。評審被用于軟件開發(fā)過程的多個不同的點上，起到發(fā)現(xiàn)錯誤和缺陷節(jié)日引發(fā)排錯活動的作用。軟件評審起到的作用是凈化分析，設(shè)計和編碼的軟件工程活動。在課程實踐過程中由于初始需求分析的不明確以及后來概要設(shè)計過程中關(guān)鍵點的遺漏所引發(fā)的錯誤曾經(jīng)導致我們小組代碼的兩次大部分返工，現(xiàn)在看來在課程實踐過程中沒有進行軟件評審所致

5：正式技術(shù)評審（FTR）

正式技術(shù)評審是一種由軟件工程師和其他人進行的軟件質(zhì)量保障活動。

正式技術(shù)評審的目標是：發(fā)現(xiàn)功能、邏輯或?qū)崿F(xiàn)的錯誤；證實經(jīng)過評審的軟件的確滿足需求；保證軟件的表示符合預定義的標準；得到一種一致的方式開發(fā)的軟件；使項目更易管理。

評審會議一般由3-5人參加，不超過2小時，由評審主席、評審者和生產(chǎn)者參加，必須做出下列決定中的一個：工作產(chǎn)品可不可以不經(jīng)修改而被接受；由于嚴重錯誤而否決工作產(chǎn)品；暫時接受工作產(chǎn)品。

評審總結(jié)報告和記錄保存：評審會議結(jié)束時，生成一份評審問題列表，完成一份包括“評審什么？由誰評審？結(jié)論是什么？”的評審總結(jié)報告。

評審總結(jié)報告是項目歷史記錄的一部分，標識產(chǎn)品中存在問題的區(qū)域，作為行政條目檢查表以指導生產(chǎn)者進行改正。

評審指導原則：評審產(chǎn)品，而不是評審生產(chǎn)者。注意客氣地指出錯誤，氣氛輕松；制定日程并且遵守日程；不要離題，限制爭論和辯駁。有異議的問題不要爭論但要記錄在案；對各個問題都發(fā)表見解。問題解決應該放到評審會議之后進行；做書面筆記；限制參與者的人數(shù)并堅持事先做準備；為每個要評審的工作產(chǎn)品建立一個檢查表。應為分析、設(shè)計、編碼、測試文檔都建立檢查表。；為了讓評審有效，為FTR分配資源和時間；為了提高效益對所有評審進行有意義的培訓；評審以前所做的評審。

6結(jié)合課程實踐淺談自己的感受

下面我將結(jié)合課程的實踐講一講個人對于軟件質(zhì)量保證的一些感受，首先說一說每個人所扮演的角色，負責編碼的同學相當于軟件工程師的角色，而負責需求分析及概要設(shè)計的同學責同時兼任了SQA小組成員的角色。在具體實現(xiàn)過程中，在需求分析階段，通過需求調(diào)研我們小組大體明確了客戶即TA對機動車違章管理系統(tǒng)的需求，但由于沒有把需求調(diào)研的工作做到位，在完成需求分析的過程中，我們小組出現(xiàn)了一些問題，主要是對TA要求的理解出現(xiàn)了分歧。此時承擔SQA小組責任的同學并沒有嚴格要求自己進一步與TA溝通，解決理解上的分歧，而是個人主觀的認為自己的理解就是對的。致使在具體實現(xiàn)時與初始需求出現(xiàn)了一些偏差。這個問題的發(fā)生，主要是因為承擔需求分析的同學同時兼任SQA小組工作的原因，致使監(jiān)督的客觀性方面出現(xiàn)了問題。在概要設(shè)計階段由于考慮到后期一些功能在后期具體實現(xiàn)中的困難，沒有嚴格按照獲取的需求進行設(shè)計，主要是出于實現(xiàn)難度的考慮草率的對本已獲得的需求進行了一些修改致使本就出現(xiàn)變差的需求進一步打了折扣。在編碼階段針對出現(xiàn)問題時，更是僅僅是就問題而談問題，把原始的計劃放到了一邊?；仡櫿麄€課程的過程：從在初始人員定位時并沒有認識到SQA小組的重要性，因此并沒有嚴格指定專人負責，只是在出現(xiàn)問題時才想到，而在明確兩人兼任SQA小組工作后，也沒有嚴格制定明確的計劃，也沒有正式的評審各項軟件工程活動，僅僅是想到什么就說什么，不但造成了小組成員間的沖突，更是對問題的解決沒有多大的幫助。而“軟件工程師”即從事編碼的同學雖然對軟件本身進行了一些測試，修正了一些錯誤，改進了一些BUG，但這一切都是通過想當然去做的，并沒有參考設(shè)計文檔。結(jié)論：

無論何種軟件只有在保證其質(zhì)量的前提下才能體現(xiàn)出它的價值。軟件質(zhì)量保證則是保證軟件質(zhì)量的基石。而在軟件質(zhì)量保證的過程中，首先應該明確自己的定位，而后嚴格按照上面提出的步驟與方法去實現(xiàn)才能更好的完成SQA工作。這一切，都需要我們在今后的學習、工作中積極地去實踐。

參考文獻：

軟件工程實踐者的研究方法 Roger S.Pressman

軟件質(zhì)量保證 Schulmeyer,G.G

第二篇：軟件質(zhì)量保證承諾書

軟件質(zhì)量保證承諾書

軟件質(zhì)量保證承諾書1

根據(jù)《中華人民共和國著作權(quán)法》、《計算機軟件保護條例》及單位軟件正版化工作相關(guān)規(guī)定，為確保單位使用軟件的合法性和安全性，營造使用正版軟件的良好氛圍，本人鄭重做出如下承諾：

1、不私自在計算機辦公設(shè)備及系統(tǒng)中安裝或卸載軟件;

2、不私自升級或改動計算機辦公設(shè)備及系統(tǒng)中已安裝的.商業(yè)軟件;

3、因工作需要，確需安裝或卸載軟件、升級或改動商業(yè)軟件的，主動報單位軟件正版化工作牽頭部門或信息化工作部門審核，并由其統(tǒng)一組織維護;

4、不私自將計算機辦公設(shè)備及系統(tǒng)中已安裝的商業(yè)軟件復制或遷移至單位資產(chǎn)以外的計算機設(shè)備及系統(tǒng)中使用。

若有違反以上任何承諾，在單位軟件正版化考核評議、信息安全風險、版權(quán)侵權(quán)違法等方面造成的一切后果，全部由本人負責。

承諾人簽字：

xx年xx月xx日

軟件質(zhì)量保證承諾書2

如果我公司在貴單位組織的項目名稱：長沙市地方稅務局機關(guān)及稽查局大院安全技術(shù)防范設(shè)備采購項目招標中獲取中標，應項目投標的`有關(guān)要求，我方對該項目做出如下產(chǎn)品質(zhì)量承諾：

（1）技術(shù)規(guī)范及相關(guān)產(chǎn)品標準：按國家標準執(zhí)行。

（2）產(chǎn)品都是廠家原裝正品產(chǎn)品。

（3）所有的附件及零配件是正規(guī)廠商生產(chǎn)的產(chǎn)品。

（4）產(chǎn)品“三包”內(nèi)容：實行包退、包換、包修服務。

（5）質(zhì)量問題的處理：按廠家質(zhì)量保證實行。

（6）質(zhì)量投訴的處理：由專人負責本次項目投訴處理。

（7）質(zhì)保期內(nèi)所有軟件維護、升級和設(shè)備維護等免費上門服務。

20xx年xx月xx日

xxx

軟件質(zhì)量保證承諾書3

本公司秉持以“優(yōu)質(zhì)的產(chǎn)品，合理的價格，周到的服務”的.原則和宗旨，向用戶莊嚴承諾：

一、本公司保證出廠的產(chǎn)品嚴格按國家有關(guān)標準執(zhí)行，不合格的產(chǎn)品決不出廠。

二、本公司產(chǎn)品質(zhì)量保證期為一年。保修期內(nèi)，用戶對產(chǎn)品質(zhì)量有異議的，本公司在24小時之內(nèi)作出處理意見，并負責缺陷產(chǎn)品免費召回、更換或按訂貨價退款;保修期外，用戶對產(chǎn)品質(zhì)量有異議的，本公司在48小時之內(nèi)作出處理意見，并負責缺陷產(chǎn)品有償更換。

三、本公司產(chǎn)品質(zhì)量由中國人民財產(chǎn)保險公司承保。

浙江××有限公司

20xx年xx月xx日

第三篇：軟件質(zhì)量保證管理

1、V模型：V模型是在RAD模型的基礎(chǔ)上演變而來的，由于開發(fā)過程構(gòu)造成一個V字形而得名。V模型強調(diào)軟件開發(fā)的協(xié)作和速度，將軟件實現(xiàn)和驗證有機地結(jié)合起來，在保證較高的軟件質(zhì)量情況下縮短開發(fā)周期。V模型具有面向客戶、效率高、質(zhì)量防范意識等特點。

左邊是設(shè)計和分析，是軟件設(shè)計實現(xiàn)的過程，同時伴隨著質(zhì)量保證活動---審核過程，也就是靜態(tài)的測試過程；右邊是對左邊結(jié)果的驗證，是動態(tài)的過程，即對設(shè)計和分析的結(jié)果進行測試，以確認是否滿足用戶的需求。V模型避免了瀑布模型所帶來的誤區(qū)-----軟件測試是在代碼完成之后進行的。p302、什么是變更控制？（P111）

軟件開發(fā)過程中都會產(chǎn)生許多變更，如配置項，配置，基線，構(gòu)建的版本，發(fā)布的版本的變更，對于這些變更，都要有一個控制機構(gòu)，以保證所有的變更都是可控的，可跟蹤的，可重現(xiàn)的。這樣的一類機構(gòu)對變更的管理，就是變更控制。

3、軟件可靠性概念？（P176）

軟件可靠性是指在給定時間內(nèi)，特定環(huán)境下軟件無錯運行的概率，軟件可靠性包含了以下三個要素：規(guī)定的時間，規(guī)定的環(huán)境條件，規(guī)定的功能。

4、CMM（P195）

CMM：能力成熟度模型，用來衡量組織軟件過程成熟度和評價其軟件過程能力。能力成熟度是指一個特定過程被明確定義，管理，測量，控制并且是有效的程度。分為五個等級： 初始級 軟件過程的特點是無序的，甚至是混亂的。幾乎沒有什么過程是進過定義的?？芍貜图?關(guān)鍵過程區(qū)域集中關(guān)注軟件項目所關(guān)心的，與建立基本項目管理控制有關(guān)的事情。

已定義級 將軟件生命周期的各個階段嚴格的劃分出來，從組織這個層次來保證過程質(zhì)量該進

已管理級 軟件產(chǎn)品的質(zhì)量目標被量化管理，它遵循了全面質(zhì)量管理活動的科學程序，關(guān)鍵過程域的關(guān)注焦點是建立起對軟件過程和正在構(gòu)造的軟件工作產(chǎn)品的定量了解。

優(yōu)化級 關(guān)鍵過程域包括那些為了實施連續(xù)不斷的和可測的軟件過程改進，組織和項目都必須解決的問題。

5、TQM的實施步驟（P265）

（1）建立質(zhì)量小組，負責過程改進，流程完善，不斷發(fā)現(xiàn)質(zhì)量問題提出并實施解決方案。

（2）進行TQM思想的教育，通過教育，要讓每個員工深刻認識到“滿足顧客的需求是第一的”的思想，理解“什么是顧客需求”，如何讓顧客滿意等內(nèi)容。

（3）了解市場，明確顧客需求，了解目前研發(fā)的軟件產(chǎn)品的市場，包括競爭對手，客戶群等，讓員工明白什么是質(zhì)量好的軟件產(chǎn)品或軟件服務，認真對待質(zhì)量要求，開發(fā)出合格的產(chǎn)品。

（4）建立明確的質(zhì)量基準和質(zhì)量評估機制，以便和實際質(zhì)量水平進行對比，識別質(zhì)量的目標和工作的重點區(qū)域，采取相應措施。

（5）建立相對完善的獎勵機制，在認可和給予獎勵的過程中，應力求公正，真實，選擇恰當?shù)臅r間，恰當?shù)膱龊希‘數(shù)姆绞健?/p>

2、版本控制的目的:是在于對軟件開發(fā)過程中文件或目錄的發(fā)展過程提供有效的追蹤手段，保證在需要時找到舊的版本，避免文件的丟失，修改文件的丟失和相互覆蓋，通過對版本庫的訪問控制避免未經(jīng)授權(quán)訪問和修改。另外軟件的控制是實現(xiàn)團隊開發(fā)，提高效率的基礎(chǔ)。

3、PDCA包括4個部分：計劃、執(zhí)行、檢查、行動描述總結(jié)

(1)計劃計劃：就是分析當前狀況，發(fā)現(xiàn)問題，找出原因和主要原因，制定質(zhì)量方針、質(zhì)量

目標、質(zhì)量計劃書和管理原則。管理原則有：過程方法、管理的系統(tǒng)方法、持續(xù)改進

(2)執(zhí)行：執(zhí)行時計劃的履行和實現(xiàn)，主要按計劃實施地去做，去落實具體對策，并實施過

程的監(jiān)控，使活動按預期設(shè)想前進，最終達到計劃設(shè)定的目標。

(3)檢查：是對執(zhí)行后效果的評估。檢查是伴隨著實施過程自始至終的，不斷收集數(shù)據(jù)、信

息獲取的過程，并通過數(shù)據(jù)分析、結(jié)果度量來完成檢查。

行動：重點在于檢查完結(jié)果，要采取措施，即總結(jié)成功的經(jīng)驗，吸取失敗的教訓，實施標準化，以后依據(jù)標準執(zhí)行。

4、階段性開發(fā)模型：增量模型和迭代模型

(1)增量模型描述軟件產(chǎn)品的不同階段是按產(chǎn)品所具有的功能進行劃分的，先開發(fā)主要

功能或用戶最需要的功能，然后隨著時間的推進，不斷增 加新的輔助功能或次要功能，最終開發(fā)出一個功能完善的，穩(wěn)定的產(chǎn)品。

(2)迭代模型描述軟件產(chǎn)品的不同階段是按產(chǎn)品深度或細化程度來劃分，先將產(chǎn)品的整個框架都建立起來，在系統(tǒng)的初期，已經(jīng)具有用戶所需要的全部功能。然后隨著時間推進,不斷細化已具有的功能或完善已具有的功能,這個過程是一個迭代的過程

6、零缺陷質(zhì)量管理的實施步驟：（P268）

（1）建立推行零缺陷質(zhì)量管理的組織事情的推行都需要組織的保證，通過建立組織，可以動員和組織全體職工積極的投入零缺陷管理，提高他們參與管理的自覺性也可以對每個人的合理化建議進行統(tǒng)計分析，不斷進行經(jīng)驗交流，公司的最高管理者要親自參加，表明決心，做出表率，要任命相應的領(lǐng)導人，建立相應的制度，要教育和訓練員工

（2）確定零缺陷管理的目標，確定零缺陷小組在一定時期內(nèi)所要達到的具體要求，包括確定目標項目，評價標準和目標值

（3）進行績效評價，（4）建立相應的提案機制

（5）建立表彰制度

SQA組織的責任是審計軟件經(jīng)理和軟件工程組的質(zhì)量活動中出現(xiàn)的偏差。

7、SQA計劃（P283）

SQA在項目早期要根據(jù)項目計劃制定與其相應的SQA計劃，定義各階段的檢查點。標識出檢查審計的工作產(chǎn)品對象，以及在每個階段SQA的輸出產(chǎn)品。具體實施步驟如下：

（1）了解項目的需求，明確項目SQA計劃的要求和范圍

（2）選擇SQA任務

（3）估計SQA的工作量和資源

（4）安排SQA任務和日程

（5）形成SQA計劃

（6）協(xié)商，評審SQA計劃

（7）批準SQA計劃

（8）執(zhí)行SQA計劃

SQA計劃包含以下內(nèi)容：

（1）目的，SQA計劃的目的和范圍（2）參考文件，該SQA計劃參考的文件列表（3）管理，組織，任務，責任（4）文檔，列出所有的相關(guān)文檔，如程序員手冊，測試計劃，配置管理計劃等（5）標準定義，文檔標準，邏輯結(jié)構(gòu)標準，代碼編寫標準，注釋標準等（6）評審/審核（7）配置管理，配置定義，配置控制，配置評審（8）問題報告和處理（9）工具，技術(shù)，方法（10）代碼控制（11）事故/災難控制，包括火災，水災，緊急情況等。

8、評審和審核的區(qū)別？（P285）

評審：過程進行時，SQA對過程的檢查，SQA的角色在于確保當執(zhí)行工程活動時，各項計劃所規(guī)定的過程得到遵循，評審通常通過評委會的的方式進行，是對工作流程的評審

審核：在軟件工作產(chǎn)品生成時，SQA對工作產(chǎn)品進行的檢查，SQA的角色在于確保開發(fā)工作產(chǎn)品中各項計劃所規(guī)定的過程得到遵循，審核通常通過對工作產(chǎn)品的審查來執(zhí)行。側(cè)重于產(chǎn)品本身。

SQA報告應遵循三條原則SQA和高級管理者之間應有的溝通渠道，SQA報告必須發(fā)布給軟件工程組織但不必發(fā)布給項目管理人員，在可能的情況下向關(guān)心軟件質(zhì)量的人發(fā)布。

SQA度量是記錄花費在SQA活動時間人力數(shù)據(jù)。涉及以下三方面：軟件產(chǎn)品評估度量、軟件產(chǎn)品質(zhì)量度量、軟件過程審核度量。

SQA的評估任務是軟件開發(fā)前期對目標的軟件和硬件資源進行評估，以確保其充分性和適合性。

9、白盒測試、黑盒測試（P390）

白盒測試將被測試程序看做一個盒子，測試者能夠看到被測程序，可以分析被測程序的內(nèi)部結(jié)構(gòu)。

白盒測試可以用來對代碼結(jié)構(gòu)進行全面測試，常用的有語句覆蓋，判定覆蓋，條件覆蓋，判定/條件覆蓋，條件組合覆蓋，路徑覆蓋，循環(huán)測試

黑盒測試常用來驗證軟件或模塊功能是否得到實現(xiàn)，主要運用單元的性能和功能方面的測試除了測試其功能外，還需確保代碼在結(jié)構(gòu)上可靠，健全并能夠有良好的響應。黑盒測試主要運用于單元的功能和性能方面的測試。功能測試包括用戶界面測試各種操作的測試不同的數(shù)據(jù)輸入邏輯思路，數(shù)據(jù)輸出和存儲的測試。

區(qū)別：關(guān)鍵區(qū)別應該就是測試對象不一樣，白盒測試主要針對的是程序代碼邏輯，黑盒測試主要針對的是程序所展現(xiàn)給用戶的功能，簡單的說就是前者測試后臺程序后者測試前臺展示功能

10、測試的原則概括為10項：

（1）所有測試的標準都是建立在用戶需求之上2軟件測試必須基于“質(zhì)量第一”的思想去開展各項工作3實現(xiàn)定義好產(chǎn)品的質(zhì)量標準4軟件項目一啟動。軟件測試也就是開始5窮舉測試是不可能的6第三方進行測試會更客觀，更有效7軟件測試計劃是做好軟件測試工作的前提8測試用例的設(shè)計出來的，不是寫出來的9不可將測試用例置之度外，排除隨意性10對發(fā)現(xiàn)錯誤較多的程序段，應進行更深入的測試

39、功能測試的概念：是基于產(chǎn)品功能說明書，是在已知產(chǎn)品所應具有的功能，從用戶角度來進行功能驗證，以確認每個功能是否能正常使用、是否實現(xiàn)了產(chǎn)品規(guī)格說明書要求、是否能適當?shù)亟邮蛰斎霐?shù)據(jù)而產(chǎn)生正確的輸出結(jié)果等。

5、風險管理法：SEI（軟件工程研究所）風險控制一般分5個步驟：P80

(1)風險識別：試圖系統(tǒng)化的方法來確定威脅項目計劃的因素。識別方法包括：風險檢

測表、頭腦風暴會議、流程圖分析、與項目人員面談。

(2)風險分析：可以分為定性風險分析和定量風險分析。定性風險分析是評估已經(jīng)識別

風險的影響和可能性的過程。定量風險分析是量化分析每一風險的概率及其對項目目標造成的后果，同時也要分析項目總體風險的程度。

(3)風險計劃：制定風險行動計劃，應考慮以下部分：責任、資源、時間、活動、應對

措施、結(jié)果、負責人。

(4)風險控制：方法：風險避免、風險弱化、風險承擔、風險轉(zhuǎn)移。

(5)風險跟蹤：監(jiān)視風險的狀況，檢查風險的對策是否有效、跟蹤機制是否在運行，不

斷識別新的風險并制定對策。

6、評審的內(nèi)容：分為管理評審、技術(shù)評審、文檔評審、過程評審（P217簡答）

(1)管理評審是以實施質(zhì)量方針和目標的質(zhì)量體系的適應性和有效性為評論基準,對體系文

件的適應性和質(zhì)量活動的有效性進行評價。目標：按規(guī)定的時間間隔對質(zhì)量體系進行評審，確保持續(xù)的適宜性和有效性，以滿足本標準要求和提供的質(zhì)量方針和目標。輸入：體系審核的結(jié)果。輸出：《管理評審報表》

(2)技術(shù)評審是對產(chǎn)品以及各階段的輸出內(nèi)容進行評估。目的：確保需求說明、設(shè)計說明書

與最初的說明書保持一致，并按照計劃對軟件進行了正確的開發(fā)。輸入：需求文檔、源代碼、測試用例、評審檢查單、其它文檔。輸出：技術(shù)評審報告

(3)文檔評審分為格式評審和內(nèi)容評審。

(4)過程評審是對軟件開發(fā)過程的評審，其主要任務是通過對流程的監(jiān)控，保證SQA組織

定義的軟件過程在項目中得到了遵循，同時保證質(zhì)量方針能得到更快更好的執(zhí)行。

40.朱蘭三部曲：

質(zhì)量策劃：為建立有能力滿足質(zhì)量標準化的工作程序，質(zhì)量策劃是必要的質(zhì)量控制：為了掌握何時采取必要措施糾正質(zhì)量問題就必須實施質(zhì)量控制

質(zhì)量改進：質(zhì)量改進有助于發(fā)現(xiàn)更好的管理工作方式

40、從軟件開發(fā)的各階段論述如何提高軟件產(chǎn)品的質(zhì)量？

1、需求

我們知道人與人的交流總是會存在一些誤會，同樣一句話，心情不好與心情好的時候聽起來的感覺可能會截然相反，正是因為人們之間存在著理解上的偏差，在描述需求的語言上就應該注意盡量避免歧義的產(chǎn)生。如果對UML比較熟悉的話，需求分析可以利用UML工具進行，這樣可以減少一些自然語言引起的歧義，但是UML可能與用戶溝通起來有一些障礙，因為并不是所有的用戶都了解UML各種圖形的意思。除了工具之外，我們可以從以下幾個方面來保證需求描述的質(zhì)量。

1、看句子和段落是否簡短，一個很長的句子，看起來會非常困難，因此無法弄懂真正的需求，另外過長的句子和段落容易讓人忽視一些需求，所以如果一個句子不能完全描述清楚需求，應該將其拆分成多個小句子。

2、句子是否有語法錯誤，還要注意標點符號，有時，標點符號點錯了，就完全成了另外一個意思了。

3、是否存在模糊不清的需求，出現(xiàn)類似于可能，大概，或者等詞匯表述的需求。

4、另外注意引用的術(shù)語和詞匯是否前后一致。

5、是否存在一些形容詞、比較性詞語，比如：容易的、快速的、方便的、有效的、許多、很少、簡單、復雜、最新的，界面友好的，減少、擴大，不小于等等，需要將描述性詞語進行量化，并且給出具體值或者范圍，要不然不同的人根據(jù)不同的理解就會得出不同的結(jié)果，最終可能跟用戶最初的要求有偏差，那“炒回鍋肉”的事情就不可避免地會發(fā)生。

另外保證需求質(zhì)量的一個很重要的因素就是需求是否細化，如果需求不細化也會很容易造成代碼的返工，于是就出現(xiàn)了我們的程序員盡管總是加班加點卻總是不能如期的完成任務的情景。那么我們怎樣才能判斷需求細化的程度呢?需求細化程度確實很難把握，什么樣的需求可以算是比較細了，不用再進行細化了呢?哪些需求又太粗了呢?答案是需求是否可以寫出相應的測試用例，如果寫不出來，就說明需求還不是很細，還需要再進行細化。

2、設(shè)計

軟件架構(gòu)設(shè)計在軟件產(chǎn)品開發(fā)周期中占有很重要的位置，我們開發(fā)出來的軟件產(chǎn)品在開發(fā)伊始到產(chǎn)品發(fā)布會涉及到方方面面的角色，例如：用戶、項目管理人員、程序員、測試員、維護人員等等。不同的角色對架構(gòu)設(shè)計的要求也不相同。例如用戶關(guān)心的是需求，因此我們的設(shè)計對需求的覆蓋率是多少?對于程序員來說模塊是否清晰，類的功能是否單一等等，對于測試人員來說系統(tǒng)的是系統(tǒng)的可測試性。對于維護人員來講系統(tǒng)的擴展性、可維護性如何?一個高質(zhì)量的軟件架構(gòu)，應該最大限度的考慮并滿足不同角色的不同要求。正

是因為有這些要求，我們在進行軟件設(shè)計的時候，應該進行全面的考慮。一般用來衡量軟件設(shè)計質(zhì)量的標準可以從以下幾個方面來考慮：

1)、功能性：包括完全性、正確性、安全性、兼容性、互用性。完全性包括功能點覆蓋率，重點功能點覆蓋率，優(yōu)先功能覆蓋率。正確性包括需求一致度。安全性根據(jù)軟件需求的不同有不同的安全性要求。

2)、效率：包括產(chǎn)品運行的時間效率和利用的硬件資源兩方面來考慮。

3)維護性：包括架構(gòu)的可改正性，可擴充性以及可測試性。如果用戶的一個很小的需求變更會引起架構(gòu)設(shè)計很大的變化，那么這樣的架構(gòu)設(shè)計的可改正性和可擴充性就比較差。

4)可移植性：包括硬件的獨立性、軟件獨立性、可安裝性、可重用性。軟件設(shè)計是否模塊化、每個模塊的可復用性如何都是應該考慮的因素。

5)可靠性：包括缺陷數(shù)量、容錯性、可用性。

6)使用性：包括可理解性、易學習性、可操作性、易溝通性。我們軟件的最終目的是讓用戶來使用的，如果易用性不好，可操作性不好都會影響用戶對軟件的接納程度。因此在軟件的可使用性也是非常重要的。

3、編碼

代碼質(zhì)量的一個很重要的標準就是代碼的可讀性及規(guī)范性，可讀性不一定是簡單的代碼，而是容易理解的代碼，因為過于復雜的代碼難以測試和維護，同時出錯的幾率也會更高。如果一個方法內(nèi)部的代碼很長，而且使用了很多令人難以理解的數(shù)據(jù)集，這樣就會帶來代碼維護的困難，因為很少有人能夠有效地分析它們，因此也就是最容易出現(xiàn)缺陷和錯誤的地方。類之間的耦合度會造成類與類之間的相互關(guān)聯(lián)，當一個類發(fā)生改變時會使其他的類發(fā)生意想不到的變化，一般從導入類的個數(shù)判斷類之間的耦合度，如果導入類的個數(shù)很多，每一個導入類發(fā)生變化都會影響到該類本身，另外如果該類的public方法太多也會導致類之間的高耦合性增加。

也許有的程序員會認為寫出可讀、規(guī)范的代碼會影響工作進度。的確，對于程序員個體短時間來說為代碼寫上注釋是要花費些時間，但如今軟件開發(fā)是多人協(xié)作

周期很長的過程，寫過程序的人都知道，如果自己寫了不規(guī)范的代碼，隨著自己所寫的代碼越來越多，到后來需要修改某個前期寫的模塊時都不知道自己當初是怎么想的了，讀自己的代碼也需要花很長時間才讀懂。況且如果隨著人員的調(diào)動等其他原因，往往維護代碼的程序員已不是當初寫代碼的人，很多情況就是讀懂了一段糟糕的代碼還比重新寫出一段代碼花費的時間還長，嚴重影響工作效率(有些時候還影響維護人員的心情)，反過來，如果大家都講究把代碼寫成規(guī)范可讀的，無疑對于整個組織來說提高總體工作效率是非常有用的。

代碼質(zhì)量另一個非常重要的衡量手段就是測試，通過統(tǒng)計測試代碼所產(chǎn)生的缺陷情況，如嚴重等級分布、缺陷曲線的變化等可以從一個方面來簡單地評估代碼質(zhì)量。

4、測試

測試人員在測試過程中，需要站在不同的利益相關(guān)者的角度，對測試對象的質(zhì)量進行檢查和驗證，例如：測試人員除了關(guān)注需求文檔中明確描述的需求條目之外，還應該關(guān)注隱現(xiàn)的需求，比如：競爭對手的產(chǎn)品特征、用戶的群體特征和使用習慣等。因此，在測試過程中，測試人員除了關(guān)注測試對象的功能測試之外，還需要針對其他非功能特性進行測試。

為了在測試過程中盡量多的覆蓋質(zhì)量特性，測試人員需要清楚的了解產(chǎn)品有哪些質(zhì)量特性是客戶最關(guān)注的因此，測試人員在進行具體的測試用例設(shè)計和執(zhí)行之前，需要定義該產(chǎn)品應該滿足的質(zhì)量特性集。

第四篇：軟件質(zhì)量保證承諾書(精)

軟件質(zhì)量保證承諾書

如果我公司在貴單位組織的項目名稱:長沙市地方稅務局機關(guān)及稽查局大院安全技術(shù)防范設(shè)備采購項目招標中獲取中標,應項目投標的有關(guān)要求,我方對該項目做出如下產(chǎn)品質(zhì)量承諾:(1技術(shù)規(guī)范及相關(guān)產(chǎn)品標準:按國家標準執(zhí)行。(2產(chǎn)品都是廠家原裝正品產(chǎn)品。

(3所有的附件及零配件是正規(guī)廠商生產(chǎn)的產(chǎn)品。本篇文章來自資料管理下載。

(4產(chǎn)品三包內(nèi)容:實行包退、包換、包修服務。(5質(zhì)量問題的處理:按廠家質(zhì)量保證實行。(6質(zhì)量投訴的處理:由專人負責本次項目投訴處理。

(7質(zhì)保期內(nèi)所有軟件維護、升級和設(shè)備維護等免費上門服務。

第五篇：軟件質(zhì)量保證工程師職責

軟件質(zhì)量工程師的職責

隨著科學技術(shù)的不斷發(fā)展進步，企業(yè)之間的競爭越來越激烈。軟件企業(yè)要想在競爭中發(fā)展生存，提高軟件產(chǎn)品質(zhì)量已成為必要條件。在一些高能力成熟度軟件企業(yè)中，專門成立了質(zhì)量保證和控制職能部門，起著提高項目管理透明性和確保軟件產(chǎn)品質(zhì)量的雙重作用。軟件質(zhì)量工程師是隸屬于質(zhì)量監(jiān)控部門的工程師，他們獨立于項目對質(zhì)量保證經(jīng)理負責，以獨立審查的方式監(jiān)控軟件生產(chǎn)任務的執(zhí)行，給開發(fā)人員和管理層提供反映產(chǎn)品質(zhì)量的信息和數(shù)據(jù)，輔助軟件工程組得到高質(zhì)量的軟件產(chǎn)品。每位軟件質(zhì)量工程師可以同時介入多個項目。

軟件質(zhì)量工程師的工作原則是“用過程質(zhì)量確保產(chǎn)品質(zhì)量”。軟件質(zhì)量工程師在軟件生存期的各個階段起著不同的作用，是軟件項目開發(fā)過程中不可或缺的重要成員。軟件質(zhì)量工程師的分為組織相關(guān)的和項目相關(guān)的職責。

1.組織相關(guān)的?與客戶及時溝通，確?？蛻魸M意

軟件質(zhì)量工程師應當擔當“客戶代表”的角色，及時與客戶進行溝通，了解客戶對產(chǎn)品質(zhì)量、開發(fā)進度、開發(fā)費用等方面的需求。定期進行客戶滿意度調(diào)查，對客戶反饋信息進行分析，為項目管理提供分析結(jié)果，及時根據(jù)客戶需求協(xié)助項目經(jīng)理調(diào)整項目開發(fā)計劃。?內(nèi)部評審

軟件質(zhì)量工程師參與項目的內(nèi)部評審活動，其包括確定評審員，為評審組織確定評審內(nèi)容，確保評審按既定的過程執(zhí)行，并向管理團隊通報評審結(jié)果。?審計

軟件質(zhì)量工程師參與改進并跟蹤現(xiàn)有審計制度以適應項目和產(chǎn)品解決方案發(fā)展的需要。軟件質(zhì)量工程師相互協(xié)作以確保不斷地改進現(xiàn)有的審計內(nèi)容和審計制度，提高管理的透明性。?度量

其職責主要是進行量化過程管理，包括完善和執(zhí)行統(tǒng)計過程控制，貫徹執(zhí)行度量標準，通過數(shù)據(jù)采集和分析完善度量基準。

2.項目相關(guān)的?為相關(guān)項目提供過程管理和質(zhì)量保證咨詢

軟件質(zhì)量工程師參加項目啟動會議，為制定項目開發(fā)計劃提供相關(guān)歷史數(shù)據(jù)。為項目開發(fā)人員提供質(zhì)量保證相關(guān)知識的咨詢。

?幫助項目建立切實可行的質(zhì)量保證目標，選擇適當?shù)馁|(zhì)量保證基準

軟件質(zhì)量工程師根據(jù)客戶需求、企業(yè)內(nèi)部質(zhì)量審查標準、行業(yè)標準，按照項目類別建立項目質(zhì)量保證目標，與項目成員一起討論并進行必要的修改。明確度量標準和數(shù)據(jù)收集方法，在項目實施過程中根據(jù)建立的目標對項目進行實時監(jiān)控。

?制定項目質(zhì)量保證計劃

軟件質(zhì)量工程師根據(jù)項目類別、質(zhì)量保證目標、項目開發(fā)進度制定相應的質(zhì)量保證計劃。?項目審查

軟件質(zhì)量工程師應當參與必要的項目審查。審查內(nèi)容包括：

-產(chǎn)品需求說明書

-軟件項目開發(fā)計劃

-測試計劃

-測試總結(jié)報告

?數(shù)據(jù)收集和分析

軟件質(zhì)量工程師負責按軟件質(zhì)量保證計劃收集與項目相關(guān)的數(shù)據(jù)，通過對數(shù)據(jù)進行分析，及時將與質(zhì)量相關(guān)的反饋和建議匯報給項目負責人和高級主管。項目負責人根據(jù)反饋數(shù)據(jù)調(diào)整項目開發(fā)計劃。

?項目審計

軟件質(zhì)量工程師負責鑒別項目開發(fā)中與項目質(zhì)量保證計劃中規(guī)定的標準和過程不相符的內(nèi)容，當這些內(nèi)容與計劃偏離比較多，以至于可能影響到項目的及時高質(zhì)量完成時，可以考慮召開項目審計會議。

軟件質(zhì)量工程師負責會議的計劃、主持，確保審計所有偏離內(nèi)容，并匯報審計結(jié)果。?系統(tǒng)測試

軟件質(zhì)量工程師可以介入系統(tǒng)測試，確保軟件產(chǎn)品符合質(zhì)量要求，滿足客戶需求。軟件質(zhì)量工程師幫助系統(tǒng)測試工程師收集數(shù)據(jù)，將數(shù)據(jù)分析結(jié)果反饋給項目負責人、系統(tǒng)測試工程師和項目組其他成員。

?錯誤預防

軟件質(zhì)量工程師負責提供歷史和當前數(shù)據(jù)，幫助項目了解項目所處狀態(tài)、進度和存在的弱點。所有的錯誤預防工作都應由項目負責人計劃并跟蹤，軟件質(zhì)量工程師負責監(jiān)督。