軟件質(zhì)量管理的體系
一個(gè)開發(fā)團(tuán)隊(duì)要提高效率，就需要思考目前的管理活動(dòng)中有哪些要素是可以改進(jìn)的:如何把一些事務(wù)性的操作變得自動(dòng)化，從而節(jié)約人力;如何找到更好的方法，讓開發(fā)過程更為合理，更注重軟件的質(zhì)量，下面小編為大家整理了關(guān)于軟件質(zhì)量管理的體系，希望能為你提供幫助：
一、軟件開發(fā)的有效管理:日創(chuàng)建
一個(gè)組織應(yīng)當(dāng)擁有一個(gè)有效的工作流程，這個(gè)工作流程能夠指導(dǎo)軟件開發(fā)的進(jìn)行。這個(gè)流程應(yīng)當(dāng)是具體的、可操作的。隨意的計(jì)劃和從來不遵循的進(jìn)度決不是一個(gè)有效的工作流程。日創(chuàng)建實(shí)踐提出了一種對(duì)開發(fā)過程進(jìn)行精細(xì)管理的方法，它是量化軟件管理的基礎(chǔ)。有了日創(chuàng)建，你會(huì)發(fā)現(xiàn)計(jì)劃的制定和進(jìn)度的監(jiān)控是非常容易的一件事情。
我們傳統(tǒng)開發(fā)軟件的流程一般是這樣，理解領(lǐng)域問題，然后分配任務(wù)，由不同的人負(fù)責(zé)不同的軟件部件，在開發(fā)完成之后，再把各人的部件整合起來，形成完整的軟件。這個(gè)思路看起來并沒有什么問題，但是在實(shí)踐中卻問題多多。
首先，這種方式適合開發(fā)人員之間工作彼此沒有交集的情況，以前這種現(xiàn)象很常見，但是現(xiàn)在，隨著軟件規(guī)模的擴(kuò)大、分工合作的加深，開發(fā)人員間的相互依賴程度越來越高，這種清晰的職責(zé)劃分已經(jīng)變得越來越難了。
其次，在軟件集成時(shí)，往往會(huì)出現(xiàn)各種各樣的問題，可是卻很難發(fā)現(xiàn)到底問題在哪里?公說公有理，婆說婆有理。每個(gè)人的代碼都沒有問題，結(jié)合到一起就出現(xiàn)大量的問題。
所以日構(gòu)建就將平時(shí)難得一見的集成工作轉(zhuǎn)換成頻繁進(jìn)行的一件工作，從而使得原先如同噩夢(mèng)般的集成變成了一件簡(jiǎn)單的工作。這也是很容易理解的，如果集成工作幾個(gè)月才進(jìn)行一次，誰能夠記起幾個(gè)月前的細(xì)節(jié)呢?但是如果集成以天，甚至以分鐘為單位進(jìn)行，排除bug就變成一件很容易的事情了。
二、測(cè)試驅(qū)動(dòng)開發(fā)
軟件質(zhì)量的根源來源于測(cè)試，測(cè)試做好了，軟件質(zhì)量就會(huì)好。這是毫無疑問的。問題的關(guān)鍵在于怎么做測(cè)試，才能保證測(cè)試的投入能夠帶來軟件質(zhì)量的有效提升。測(cè)試驅(qū)動(dòng)開發(fā)正是為了解決這個(gè)問題而出現(xiàn)的。它不是一個(gè)完整的方法論，可以和任何一種開發(fā)流程進(jìn)行融合。測(cè)試驅(qū)動(dòng)開發(fā)不但能夠改善測(cè)試效果，還能夠改進(jìn)軟件的設(shè)計(jì)。
測(cè)試驅(qū)動(dòng)開發(fā)起源于XP法中提倡的測(cè)試優(yōu)先實(shí)踐。測(cè)試優(yōu)先實(shí)踐重視單元測(cè)試，強(qiáng)調(diào)程序員除了編寫代碼，還應(yīng)該編寫單元測(cè)試代碼。在開發(fā)的順序上，它改變了以往先編寫代碼，再編寫測(cè)試的過程，而采用先編寫測(cè)試，再編寫代碼來滿足測(cè)試的方法。這種方法在實(shí)際中能夠起到非常好的效果，使得測(cè)試工作不僅僅是單純的測(cè)試，而成為設(shè)計(jì)的一部分。
在編寫程序之前，每個(gè)人都會(huì)先進(jìn)行設(shè)計(jì)工作�？赡苡行┤说脑O(shè)計(jì)比較正式，繪制模型，編寫文檔。有些人的設(shè)計(jì)只是存在于腦海之中。且不論設(shè)計(jì)是精細(xì)還是粗糙，你都為隨后的編碼活動(dòng)制定了一個(gè)標(biāo)準(zhǔn)。這個(gè)標(biāo)準(zhǔn)的明確程度和你的設(shè)計(jì)的細(xì)致程度有關(guān)。但應(yīng)該承認(rèn)，這個(gè)標(biāo)準(zhǔn)是不夠細(xì)化的。因?yàn)槟愕脑O(shè)計(jì)不可能精細(xì)到代碼級(jí)的程度。而標(biāo)準(zhǔn)不夠明確則會(huì)產(chǎn)生一些問題，例如，在編寫代碼的過程中，你還可能會(huì)發(fā)現(xiàn)原先的設(shè)計(jì)出現(xiàn)問題，從而中途改變代碼的編寫思路。這將會(huì)導(dǎo)致成果難以檢驗(yàn)，進(jìn)度難以度量。
既然以設(shè)計(jì)為導(dǎo)向的標(biāo)準(zhǔn)不夠明確、不夠具體。那什么樣的標(biāo)準(zhǔn)才是合適的呢?只能是代碼。因?yàn)榇a是最明確、最具體的.。所以測(cè)試優(yōu)先的本質(zhì)其實(shí)是目標(biāo)管理。編寫測(cè)試代碼其實(shí)是在制定一個(gè)小目標(biāo)。這個(gè)小目標(biāo)非常明確，它規(guī)定了你需要設(shè)計(jì)的類、方法，以及方法需要滿足的結(jié)果。這些目標(biāo)制定完成之后，你才開始編寫代碼來達(dá)成該目標(biāo)。測(cè)試的目標(biāo)要比設(shè)計(jì)的目標(biāo)粒度更小，但是成本上卻更為經(jīng)濟(jì)。
測(cè)試優(yōu)先是軟件開發(fā)中一種細(xì)粒度的目標(biāo)管理方法，通過明確的目標(biāo)，推動(dòng)軟件開發(fā)的進(jìn)行。
三、建立核心框架
框架是一種具有高度重用性的軟件，這個(gè)特性決定了它非常適合成為軟件組織積累知識(shí)的一種有效手段。傳統(tǒng)的知識(shí)積累的方法是文檔，但是文檔容易產(chǎn)生歧異，開發(fā)人員往往也不愿意去閱讀和理解文檔�？蚣芴峁┑氖且环N綜合的手段，包括文檔、模型和代碼。更容易理解，更重要的是，開發(fā)人員必須在日常的工作中使用框架，這使得他們對(duì)框架中的知識(shí)非常熟悉，并根據(jù)工作的需要來改進(jìn)框架。
四、面向組件編程
有效的組織在于有效的分工。體力活動(dòng)容易進(jìn)行分工，腦力勞動(dòng)則比較難，而軟件開發(fā)似乎就更難了。所以，長(zhǎng)久以來我們都習(xí)慣采用以功能塊為單位的粗粒度劃分方式。面向組件編程采用更加細(xì)密的劃分方式，并以服務(wù)作為組件之間相互依賴的契約，不但定義了組件和組件之間的關(guān)系，也規(guī)定了組件開發(fā)者、組件使用者、組件測(cè)試者的權(quán)利和義務(wù)。從而能夠進(jìn)行軟件開發(fā)工作的分配、管理、QA等工作。
【軟件質(zhì)量管理的體系】相關(guān)文章：
質(zhì)量管理體系的理解06-20
質(zhì)量管理體系的建立08-23
質(zhì)量管理體系的基本理念11-16
華為質(zhì)量管理體系分析11-08
質(zhì)量管理體系重在執(zhí)行06-17