- 相關(guān)推薦
試析軟件工程系統(tǒng)項(xiàng)目開發(fā)的質(zhì)量控制
為達(dá)到質(zhì)量要求所采取的作業(yè)技術(shù)和活動(dòng)稱為質(zhì)量控制。這就是說，質(zhì)量控制是為了通過監(jiān)視質(zhì)量形成過程，消除質(zhì)量環(huán)上所有階段引起不合格或不滿意效果的因素。以達(dá)到質(zhì)量要求，獲取經(jīng)濟(jì)效益，而采用的各種質(zhì)量作業(yè)技術(shù)和活動(dòng)。那么，軟件工程系統(tǒng)項(xiàng)目開發(fā)的質(zhì)量控制有哪些方法呢?請(qǐng)看本文介紹。
論文摘要：依據(jù)GB/T16260<信息技術(shù)軟件產(chǎn)品評(píng)價(jià)質(zhì)量特性及其使用指南》，結(jié)合某軟件工程的項(xiàng)目開發(fā)，通過過程質(zhì)量控制，認(rèn)識(shí)質(zhì)量特性，選擇適當(dāng)開發(fā)控制模型，對(duì)工作內(nèi)容在質(zhì)量控制方法、控制措施和控制流程的一點(diǎn)認(rèn)識(shí)。
論文關(guān)鍵詞：質(zhì)量控制 內(nèi)容 方法 措施
1 項(xiàng)目概況
整個(gè)工程項(xiàng)目要完成兩個(gè)系統(tǒng)的建設(shè)：
1.1 行政辦公自動(dòng)化系統(tǒng)
行政辦公自動(dòng)化系統(tǒng)基于WEB，采用B/S多層結(jié)構(gòu)設(shè)計(jì)。以JAVA、JSP、XML、.NET等為核心編程技術(shù)。整個(gè)系統(tǒng)能夠充分保證數(shù)據(jù)的安全，可根據(jù)需要提供數(shù)字簽名、電子印章、加密驗(yàn)證，保證系統(tǒng)安全。具有靈活的權(quán)限設(shè)置功能。系統(tǒng)能滿足長(zhǎng)時(shí)間穩(wěn)定運(yùn)行的要求，具有高度容錯(cuò)性，能夠?yàn)檗k公提供科學(xué)高效的工作計(jì)劃管理和監(jiān)督檢查功能及方便的數(shù)據(jù)收集查詢服務(wù)。同時(shí)提供高度的系統(tǒng)自適應(yīng)性。
1.2 行政網(wǎng)站系統(tǒng)
本網(wǎng)站定位在電子政務(wù)門戶網(wǎng)站，其基本功能有：信息發(fā)布、對(duì)外宣傳、信息查詢、便民服務(wù)、網(wǎng)上辦事等。整個(gè)網(wǎng)站著重于先進(jìn)性、實(shí)用性、安全性、可擴(kuò)充性、兼容性、經(jīng)濟(jì)性和科學(xué)性等原則。
2 軟件產(chǎn)品質(zhì)量特性
軟件產(chǎn)品質(zhì)量特性一般分6類：功能性、可靠性、易使用性、效率、可維護(hù)性和可移植性。
2.1 功能性
與一組功能及其指定的性質(zhì)有關(guān)的一組屬性。這里的功能是指滿足明確或隱含的需求的那些功能。
2.2 可靠性
與在規(guī)定的一段時(shí)間和條件下，軟件維持其性能水平的能力有關(guān)的一組屬性。
2.3 易使用性
與一組規(guī)定或潛在的用戶為使用軟件所需作的努力和對(duì)這樣的使用所作的評(píng)價(jià)有關(guān)的一組屬性。
2.4 效率
與在規(guī)定的條件下，軟件的性能水平與所使用資源量之間關(guān)系有關(guān)的一組屬性。
2.5 可維護(hù)性
與進(jìn)行指定的修改所需的努力有關(guān)的一組屬性。
2.6 可移植性
與軟件可從某一環(huán)境轉(zhuǎn)移到另一環(huán)境的能力有關(guān)的一組屬性。
3 軟件產(chǎn)品開發(fā)模型
軟件產(chǎn)品常用的開發(fā)模型有：瀑布模型(V模型、噴泉模型)、螺旋模型、原型模型(鋸齒模型、快速原型)、構(gòu)件組裝模型(增量模型)、統(tǒng)一軟件過程RUP模型等。在實(shí)際開發(fā)不是使用單一模型，本項(xiàng)目中就使用了多模型的集合控制的方法。
4 質(zhì)量控制工作內(nèi)容、方法和措施
1.質(zhì)量控制是項(xiàng)目開發(fā)過程的重點(diǎn)，開發(fā)過程中的質(zhì)量控制是把好質(zhì)量關(guān)的重要一環(huán)。質(zhì)量工程師必須熟悉設(shè)計(jì)方案，熟悉施工規(guī)范、軟件規(guī)范和質(zhì)量驗(yàn)收規(guī)范。
2.在本項(xiàng)目開發(fā)中，質(zhì)量人員應(yīng)采用軟件工程的思想，對(duì)所開發(fā)的軟件、系統(tǒng)、網(wǎng)站進(jìn)行一系列的軟件測(cè)試。
3.軟件測(cè)試是在一定控制的條件下，圍繞一個(gè)系統(tǒng)或應(yīng)用的操作并且評(píng)價(jià)其結(jié)果(一個(gè)最簡(jiǎn)單的例子：如果用戶使用硬件A，在應(yīng)用接口B上做了操作C，那么結(jié)果D應(yīng)當(dāng)出現(xiàn))，控制的條件應(yīng)當(dāng)包括正常和異常的條件。測(cè)試企圖使事情變得很糟糕，從而來檢測(cè)出一些應(yīng)當(dāng)發(fā)生而沒有發(fā)生，或者不應(yīng)當(dāng)發(fā)生而發(fā)生的事情。
4.關(guān)于如何安排QA和測(cè)試的任務(wù)時(shí)，不同的承包方變化是很大的。有時(shí)它們可以有一個(gè)組或一個(gè)人來負(fù)責(zé)，共同的是一個(gè)項(xiàng)目組混合了測(cè)試人員和開發(fā)人員，并且他們一起緊密的工作，而QA過程有項(xiàng)目經(jīng)理來監(jiān)督。所有這些是同承包方的大小和商業(yè)結(jié)構(gòu)有關(guān)的。在本項(xiàng)目中，質(zhì)量人員會(huì)與承包方南京擎天科技有限公司進(jìn)行充分的溝通，確認(rèn)他們?cè)谲浖_發(fā)中慣用的測(cè)試組織和測(cè)試手段，并力圖將質(zhì)量人員的質(zhì)量行動(dòng)和軟件質(zhì)量意圖滲透到整個(gè)項(xiàng)目的開發(fā)過程中去。
5.本項(xiàng)目中可能出現(xiàn)問題或者缺陷的來源：
(1)缺乏或者沒有進(jìn)行溝通，如對(duì)于一些我們?cè)陂_發(fā)過程中應(yīng)當(dāng)或者不應(yīng)當(dāng)實(shí)現(xiàn)的細(xì)節(jié)問題。
(2)軟件復(fù)雜度—— 在當(dāng)今的軟件開發(fā)中，對(duì)于一些沒有經(jīng)驗(yàn)的人來說，軟件復(fù)雜性可能是難以理解的。圖形化界面，客戶/服務(wù)器和分布式的應(yīng)用，數(shù)據(jù)通信，大規(guī)模的關(guān)系數(shù)據(jù)庫(kù)，應(yīng)用程序的規(guī)模等指數(shù)般的增加了軟件的復(fù)雜度。面向?qū)ο蠹夹g(shù)也有可能增加軟件復(fù)雜度，除非能夠被很好的工程化。
(3)編程錯(cuò)誤——任何一個(gè)編程人員都可能產(chǎn)生錯(cuò)誤。
(4)不斷變更的需求——用戶可能不知道變更的影響，或者知道影響卻還是需要進(jìn)行變更，這些會(huì)引起重新設(shè)計(jì)與重新安排，并對(duì)其它項(xiàng)目產(chǎn)生影響，使已完成的工作可能不得不重做或推翻，硬件需求可能也會(huì)受到影響。如果存在許多小的變更或者任何大的改動(dòng)，由于項(xiàng)目中不同部分間可知和不可知的依賴關(guān)系，這樣就會(huì)產(chǎn)生問題，跟蹤變更的復(fù)雜性也可能引入錯(cuò)誤。項(xiàng)目開發(fā)人員的積極性也會(huì)受到打擊。在這種情況下，質(zhì)量人員必須了解結(jié)果的風(fēng)險(xiǎn)，必須適應(yīng)和計(jì)劃進(jìn)行大規(guī)模的測(cè)試來防止不可避免的BUG出現(xiàn)無法控制的局面。
(5)時(shí)間的壓力——軟件項(xiàng)目的時(shí)間安排是最難的，通常是需要很多猜測(cè)的工作。當(dāng)最后期限來臨的時(shí)候，錯(cuò)誤也就伴隨發(fā)生了。
(6)缺乏文檔的代碼——維護(hù)和修改很差的代碼或缺乏文檔的代碼是很困難的。最終結(jié)果將導(dǎo)致BUG的出現(xiàn)。
(7)軟件開發(fā)工具——視圖工具，類庫(kù)，編譯器，腳本工具等等通常會(huì)把它們自身的BUG 引入到本項(xiàng)目中。
6.質(zhì)量人員視情況應(yīng)該實(shí)施的測(cè)試類型：
(1)黑盒測(cè)試— —不是基于內(nèi)部代碼和設(shè)計(jì)的知識(shí)，而是基于需求和功能。
(2)白盒測(cè)試——基于應(yīng)用程序的內(nèi)部邏輯的知識(shí)，通過語(yǔ)句，分支，路徑和條件的覆蓋率。
(3)單元測(cè)試——測(cè)試中的最小單位，測(cè)試特殊的功能或代碼模塊。由于需要對(duì)內(nèi)部代碼和設(shè)計(jì)的詳細(xì)知識(shí)，該測(cè)試一般由開發(fā)者完成而不是由質(zhì)量人員完成。該測(cè)試的容易程度同代碼設(shè)計(jì)的好壞直接相關(guān)。
(4)增量型的集成測(cè)試——隨著新功能的增加，不斷的對(duì)應(yīng)用程序進(jìn)行測(cè)試。在程序的所有部分完成之前，需要一個(gè)應(yīng)用程序的各個(gè)部分之間能夠相對(duì)獨(dú)立的進(jìn)行工作。這類型測(cè)試可以由開發(fā)者或質(zhì)量人員完成。
(5)集成測(cè)試—一測(cè)試應(yīng)用程序結(jié)合的部分來確定它們的功能結(jié)合到一起是正確的。在這里‘部分’的概念可能是代碼模塊，獨(dú)立的應(yīng)用程序，在網(wǎng)絡(luò)上的客戶端和服務(wù)器斷程序等等。這類型測(cè)試典型的是于客戶/服務(wù)器和分布式系統(tǒng)相關(guān)。這類測(cè)試通常應(yīng)該由開發(fā)者在質(zhì)量人員的指導(dǎo)和監(jiān)督下完成。
(6)功能測(cè)試—— 是一種黑盒測(cè)試，同應(yīng)用程序的功能需求緊密相關(guān)。這類型測(cè)試應(yīng)當(dāng)由質(zhì)量人員來完成。這并不意味著開發(fā)人員在發(fā)布版本之前就不需要檢查他們的代碼。
(7)端到端測(cè)試— — 同系統(tǒng)測(cè)試類似，包括模擬現(xiàn)實(shí)世界對(duì)一個(gè)完整的應(yīng)用環(huán)境進(jìn)行測(cè)試。例如同數(shù)據(jù)庫(kù)進(jìn)行交互、使用網(wǎng)絡(luò)通信，或者其他的軟件、硬件和系統(tǒng)進(jìn)行交互。這類測(cè)試通常應(yīng)該由開發(fā)者在質(zhì)量人員的指導(dǎo)和監(jiān)督下完成。在某些情況下，可以和某些測(cè)試合并進(jìn)行。
(8)理智測(cè)試——這是一種典型的原始測(cè)試，其目的是要確定一個(gè)新的軟件版本在一些主要的測(cè)試努力下表現(xiàn)的足夠好并且可以接受。例如：如果一個(gè)OA軟件每五分鐘當(dāng)機(jī)一次，使系統(tǒng)執(zhí)行速度極其緩慢，或者破壞系統(tǒng)數(shù)據(jù)，那么該軟件就處于不夠‘理智’狀態(tài)，必須保證在當(dāng)前狀態(tài)下進(jìn)行進(jìn)一步測(cè)試。
(9)可接受性測(cè)試—～基于最終用戶的規(guī)格進(jìn)行的最后測(cè)試�；蛘呋谧罱K用戶在一定的時(shí)間范圍內(nèi)的測(cè)試。
(10)壓力測(cè)試——該術(shù)語(yǔ)通常同負(fù)荷測(cè)試和性能測(cè)試是可交換的。也可用于描述這樣一些測(cè)試，如：在不正常的負(fù)荷狀態(tài)下，過分的重復(fù)某些動(dòng)作或輸人情況下進(jìn)行的系統(tǒng)功能測(cè)試。
(11)安裝和反安裝測(cè)試——測(cè)試完全、部分或升級(jí)的安裝/反安裝過程。
(12)安全性測(cè)試——測(cè)試系統(tǒng)對(duì)于內(nèi)部和外部非法人侵、故意損壞時(shí)的表現(xiàn)情況�？赡苄枰獜�(fù)雜的測(cè)試技術(shù)。
(13)兼容性測(cè)試——測(cè)試系統(tǒng)在不同的平臺(tái)/硬件/操作系統(tǒng)/網(wǎng)絡(luò)上的表現(xiàn)情況。
7.質(zhì)量人員或者承包方軟件測(cè)試人員執(zhí)行軟件測(cè)試需要執(zhí)行的步驟：
(1)獲取需求、功能設(shè)計(jì)、詳細(xì)設(shè)計(jì)規(guī)格和其他必須文檔;
(2)獲取預(yù)算和時(shí)間安排需求;
(3)確定項(xiàng)目相關(guān)人員和他們的責(zé)任，匯報(bào)需求，必須的標(biāo)準(zhǔn)和過程(如版本過程、變更過程等);
(4)確認(rèn)應(yīng)用高風(fēng)險(xiǎn)的部分，設(shè)定優(yōu)先級(jí)，確定測(cè)試的范圍和限制;
(5)確定測(cè)試的方法——單元測(cè)試、集成測(cè)試、功能測(cè)試、負(fù)荷測(cè)試、可用性測(cè)試等;
(6)確定環(huán)境需求(軟件/硬件/通信等);
(7)確定測(cè)試用具環(huán)境(記錄/回放工具、覆蓋率分析器、測(cè)試跟蹤、問題跟蹤等等);
(8)確定測(cè)試輸入需求;
(9)確定任務(wù)，任務(wù)責(zé)任和相應(yīng)的工作量;
(10)設(shè)定時(shí)間安排估計(jì)、時(shí)間表、里程碑等;
(11)確定輸入的等價(jià)類、邊界值分析、錯(cuò)誤類;
(12)準(zhǔn)備測(cè)試計(jì)劃文檔和需要的評(píng)審;
(13)寫測(cè)試用例;
(14)對(duì)測(cè)試用例進(jìn)行必須的評(píng)審;
(15)準(zhǔn)備測(cè)試環(huán)境和測(cè)試用具，獲取需要的用戶手冊(cè)/參考文檔/配置指導(dǎo)/安裝指導(dǎo)，建立跟蹤過程，日志和存檔過程，獲取測(cè)試數(shù)據(jù);
(16)獲取和安裝軟件版本;
(17)執(zhí)行測(cè)試;
(18)評(píng)價(jià)和匯報(bào)測(cè)試結(jié)果;
(19)跟蹤問題和修改;
(20)如果需要進(jìn)行再測(cè)試;
(21)在整個(gè)生命周期內(nèi)維護(hù)和修改測(cè)試計(jì)劃、測(cè)試用例、測(cè)試環(huán)境和測(cè)試用具。
8.本項(xiàng)目因?yàn)椴捎昧薟EB開發(fā)技術(shù)，因此還需要進(jìn)行特定于WEB開發(fā)的軟件測(cè)試。其控制方法及措施：
(1)功能測(cè)試
a)鏈接測(cè)試.b)表單測(cè)試;c)Cookies測(cè)試;d)設(shè)計(jì)語(yǔ)言測(cè)試;e)數(shù)據(jù)庫(kù)測(cè)試
(2)性能測(cè)試
a)連接速度測(cè)試.b)負(fù)載測(cè)試;c)壓力測(cè)試
(3)可用性測(cè)試
a)導(dǎo)航測(cè)試Ib)圖形測(cè)試;c)內(nèi)容測(cè)試;d)整體界面測(cè)試
(4)客戶端兼容性測(cè)試
a)平臺(tái)測(cè)試.b)瀏覽器測(cè)試
(5)安全性測(cè)試以上質(zhì)量控制過程中所描述的任何測(cè)試和流程，并不意味應(yīng)該完全由質(zhì)量人員完成。在大多數(shù)情況下，質(zhì)量人員只需要審核承包方的開發(fā)人員或者測(cè)試人員的測(cè)試計(jì)劃和測(cè)試結(jié)果報(bào)告。承包方的開發(fā)人員和測(cè)試人員應(yīng)該自行完成上述測(cè)試和流程，并向質(zhì)量人員提交詳細(xì)的計(jì)劃和報(bào)告，等待質(zhì)量人員復(fù)核和簽認(rèn)。
5 結(jié)語(yǔ)
質(zhì)量管理可以說是一個(gè)企業(yè)、一個(gè)項(xiàng)目的關(guān)鍵命脈，質(zhì)量控制隨著數(shù)字化、信息化的技術(shù)革命其模式已發(fā)生結(jié)構(gòu)性變化，本文觀點(diǎn)是對(duì)近幾年的在軟件開發(fā)項(xiàng)目質(zhì)量工作總結(jié)的淺見。
參考文獻(xiàn)(略)
【試析軟件工程系統(tǒng)項(xiàng)目開發(fā)的質(zhì)量控制】相關(guān)文章：
試析項(xiàng)目可行性研究06-11
甘肅會(huì)展中心項(xiàng)目工程質(zhì)量控制措施分析08-13
試析如何提高有機(jī)化學(xué)教學(xué)質(zhì)量08-22
試析油圖書館知識(shí)資源管理系統(tǒng)構(gòu)建研究06-15
加強(qiáng)病案質(zhì)量控制 持續(xù)提高醫(yī)療質(zhì)量08-06
試析構(gòu)建學(xué)校特色的本科教學(xué)質(zhì)量監(jiān)控體系08-20
淺談項(xiàng)目管理者在項(xiàng)目成本控制中的作用06-13
電力工程管理質(zhì)量控制05-30