上圖表現(xiàn)了軟件質(zhì)量框架的結(jié)構(gòu)。處于結(jié)構(gòu)核心的是技術(shù)架構(gòu)和管理架構(gòu)。軟件質(zhì)量框架既不是方法學(xué)，也不是一個軟件，更像是兩者的結(jié)合體。技術(shù)架構(gòu)和管理架構(gòu)的融合體現(xiàn)了這一特性。軟件質(zhì)量框架并不關(guān)心單個開發(fā)人員的效率，它關(guān)注的是開發(fā)團(tuán)隊整體的效率。因此，管理架構(gòu)在框架中的意義在于它定義了一套軟件管理的方法，能夠?qū)﹂_發(fā)人員及其他們的工作進(jìn)行管理。從這一點來看，它的作用和軟件工程方法學(xué)是一樣的。但是，在現(xiàn)實中我們發(fā)現(xiàn)軟件組織在邁向軟件過程的途中往往因為現(xiàn)實的困難而止步不前。其中一個主要的原因是在引入方法學(xué)的過程中生產(chǎn)效率降低了，而引起組織成員對變革的懷疑和不滿。

所以，除了管理架構(gòu)之外，軟件質(zhì)量框架還提供了一個技術(shù)架構(gòu)，其目的是明確的定義如何應(yīng)用組織中涉及的軟件技術(shù)，以及管理軟件技術(shù)的方法。技術(shù)架構(gòu)是具體的代碼，相比起方法學(xué)來說，它更加的具體，更容易為開發(fā)人員所理解。而技術(shù)架構(gòu)存在的目的，一方面是進(jìn)行技術(shù)積累，另一方面也是為管理架構(gòu)服務(wù)。

技術(shù)架構(gòu)和管理架構(gòu)的下一層是支撐框架。支撐框架包括代碼、組件、文檔，目的是為技術(shù)架構(gòu)和管理架構(gòu)提供底層的支持。

處于結(jié)構(gòu)最頂層的是業(yè)務(wù)架構(gòu)。這個部分對于任何一個軟件組織來說都是不同的，因為不同的軟件組織的業(yè)務(wù)不同。業(yè)務(wù)架構(gòu)的目的是對業(yè)務(wù)進(jìn)行建模和抽象，提取出可重用的部分，以提高軟件組織的生產(chǎn)率。本文中不涉及該部分的內(nèi)容。

軟件質(zhì)量框架的優(yōu)秀實踐

一個開發(fā)團(tuán)隊要提高效率，就需要思考目前的管理活動中有哪些要素是可以改進(jìn)的：如何把一些事務(wù)性的操作變得自動化，從而節(jié)約人力；如何找到更好的方法，讓開發(fā)過程更為合理，更注重軟件的質(zhì)量；如何在團(tuán)隊中傳播優(yōu)秀的思想，讓團(tuán)隊成員不斷的學(xué)習(xí)和進(jìn)取，自發(fā)的改進(jìn)過程。這些美好的愿望幾乎是所有方法論和各種認(rèn)證的共同心聲，但要完全做到可就太難了。在我們的文章中，提出了一些優(yōu)秀的實踐，優(yōu)秀實踐均是來源于軟件開發(fā)界中的一些新思路和新理論，它們能夠為以上愿望的達(dá)成起到正面的作用。在組織中引入用這些實踐決不是一個容易的過程，但它們確實非常的有效。不論是在成本控制上，還是在質(zhì)量的改進(jìn)上。

每日創(chuàng)建：一個組織應(yīng)當(dāng)擁有一個有效的工作流程，這個工作流程能夠指導(dǎo)軟件開發(fā)的進(jìn)行。這個流程應(yīng)當(dāng)是具體的、可操作的。隨意的計劃和從來不遵循的進(jìn)度決不是一個有效的工作流程。日創(chuàng)建實踐提出了一種對開發(fā)過程進(jìn)行精細(xì)管理的方法，它是量化軟件管理的基礎(chǔ)。有了日創(chuàng)建，你會發(fā)現(xiàn)計劃的制定和進(jìn)度的監(jiān)控是非常容易的一件事情。

測試驅(qū)動開發(fā)：軟件質(zhì)量的根源來源于測試，測試做好了，軟件質(zhì)量就會好。這是毫無疑問的。問題的關(guān)鍵在于怎么做測試，才能保證測試的投入能夠帶來軟件質(zhì)量的有效提升。測試驅(qū)動開發(fā)正是為了解決這個問題而出現(xiàn)的。它不是一個完整的方法論，可以和任何一種開發(fā)流程進(jìn)行融合。測試驅(qū)動開發(fā)不但能夠改善測試效果，還能夠改進(jìn)軟件的設(shè)計。

建立核心框架：框架是一種具有高度重用性的軟件，這個特性決定了它非常適合成為軟件組織積累知識的一種有效手段。傳統(tǒng)的知識積累的方法是文檔，但是文檔容易產(chǎn)生歧異，開發(fā)人員往往也不愿意去閱讀和理解文檔?？蚣芴峁┑氖且环N綜合的手段，包括文檔、模型和代碼。更容易理解，更重要的是，開發(fā)人員必須在日常的工作中使用框架，這使得他們對框架中的知識非常的熟悉，并根據(jù)工作的需要來改進(jìn)框架。

面向組件編程：有效的組織在于有效的分工。體力活動容易進(jìn)行分工，腦力勞動則比較難，而軟件開發(fā)似乎就更難了。所以，長久以來我們都習(xí)慣采用以功能塊為單位的粗粒度劃分方式。面向組件編程采用更加細(xì)密的劃分方式，并以服務(wù)作為組件之間相互依賴的契約，不但定義了組件和組件之間的關(guān)系，也規(guī)定了組件開發(fā)者、組件使用者、組件測試者的權(quán)利和義務(wù)。從而能夠進(jìn)行軟件開發(fā)工作的分配、管理、QA等工作。

以上的幾個優(yōu)秀實踐看起來似乎并沒有多大的關(guān)系，他們的提出者也大都不同。但是有一點卻是共同的，就是他們都能夠?qū)浖|(zhì)量的改進(jìn)起積極的作用。此外，他們?yōu)檐浖|(zhì)量框架結(jié)構(gòu)的實現(xiàn)提供了一個明確的實現(xiàn)方式。從軟件結(jié)構(gòu)的角度來看，日創(chuàng)建和測試驅(qū)動開發(fā)似乎偏向于管理架構(gòu)，而建立核心框架和面向組件編程則偏向于技術(shù)架構(gòu)。事實上，他們既包含了技術(shù)架構(gòu)，也包含管理架構(gòu)，彼此之間也有相互關(guān)聯(lián)。例如，面向組件編程在合理劃分組件之后，就需要一個有效的核心框架來集成組件，通過每個組件都需要采用測試驅(qū)動開發(fā)方法來保證質(zhì)量，同時，日創(chuàng)建將會以組件為單位來進(jìn)行每日的創(chuàng)建，從而為進(jìn)度估算提供有效數(shù)據(jù)。

隨著軟件設(shè)計技術(shù)的發(fā)展，新的實踐將會出現(xiàn)，取代舊的實踐。因此，以上的實踐也會落伍，當(dāng)可以肯定的是，以上的實踐和具體的技術(shù)并沒有直接的關(guān)系，更側(cè)重于開發(fā)思想，因此他們的生命力會很長。而隨著新技術(shù)的出現(xiàn)，他們更可能將新的技術(shù)融合如自身，呈現(xiàn)出一種嶄新的形態(tài)。例如，未來的一種可能性是UML2.0和MDA技術(shù)的普及，以上的幾個實踐從以代碼為核心轉(zhuǎn)變?yōu)橐栽O(shè)計為核心，而另一種可能性是隨著以AspectJ為代表的AOP技術(shù)的普及和J2SE1.5中引入的元數(shù)據(jù)機(jī)制，面向組件編程將把Aspect作為組件的一種，而測試驅(qū)動開發(fā)也會加入測試Aspect的相關(guān)內(nèi)容，在日創(chuàng)建中也會增加相應(yīng)的處理AOP的步驟。