軟件質量框架并不復雜，它由幾個部分組成，第一部分是前提，說明了軟件框架的適用范圍，以及適合的環境，和方法學一樣，沒有泛之四海皆準的方法學，所以軟件質量框架也需要一個上下文環境。第二部分是價值觀，價值觀說明了軟件質量框架中強調的價值，在軟件框架的結構和實踐中，都將充分的的表現出一開始我們定義的價值。第三部分是結構。結構定義了軟件質量框架的組成部分，以及軟件質量框架和開發過程之間的關系。第四部分是文章中著墨最多的部分，即優秀實踐。優秀實踐通過具體、實際的分析、舉例，深入闡述了軟件質量框架的價值觀和結構。
在本文剩下的篇幅中，將會對前三個部分進行闡述，并對軟件質量開發的實踐進行簡單的描述。在剩余的篇章中，將會針對這些實踐進行細致的分析。
軟件質量框架的前提
平臺前提：由于軟件質量框架的實踐將會涉及具體的技術和代碼，所以我們首先為軟件質量框架定義了平臺。軟件質量框架將會運行在J2EE平臺上，使用對象分析技術(并不一定是面向對象技術，我們可以采用以數據為中心的技術)。
組織前提：執行軟件質量框架需要投入，需要付出，軟件質量框架最難的地方不是學習，而是執行。在一個組織中，需要評估應用軟件質量框架需要多少的投入，對目前的開發過程有多大的助益。一般來說，組織的規模越大、其開發過程和產品越復雜，就越適合采用軟件質量框架。
方法學前提：在敏捷方法學中，對規則和秩序有兩種不同的觀點，一種是強調規則和秩序，以XP為代表，它對代碼都有要求;另一種則不那么強調，以自適應軟件開發為代表，它不要求程序員的具體行為。軟件質量框架采用第一種觀點，要求組織中存在嚴謹的規則和秩序。
軟件質量框架的價值觀
明確具體：對軟件的管理必須是明確具體的。軟件開發是工程、也是藝術，需要緊密的協作和溝通，任何一個含糊的指令都可能導致軟件開發中出現錯誤，所以，在軟件開發中，任何一個指令都應該是相對明確的。為什么說是相對呢?是和成本相對，指令越明確，成本就越高。例如，你可以把需求文檔寫的非常的具體，但是你需要付出制作和維護的代價。所以我們的明確性是一個考慮成本前提下的特性。
明確具體要從綜合上考量。怎么理解呢?例如，XP中的用戶故事是非常不精確的，按道理說它是不明確，也是不具體的。但是在整個開發周期中，將會有迭代、測試、現場用戶等多種手段使得用戶故事明確具體起來，所以從整體上看，它并不違反我們的價值觀。產品質量是一個系統工程，決不僅僅是QA部門的工作，這個道理適用于制造業，也適用于軟件開發業。
容錯：軟件開發是人的工作，人是無法避免錯誤的。所以，軟件質量框架中允許犯錯。因為不犯錯是天方夜譚。你就算做了這方面的強制規定也無法避免它的出現，反而會引發其它的問題，例如隱瞞錯誤，或為了隱瞞錯誤而導致的額外成本。所以正確的態度是允許發生錯誤，并建立一套監測、管理、反饋、修改錯誤的體制。
規范：在前提中，我們已經提到了，規范是軟件質量框架的基本態度。所以，軟件質量框架中強調規范，并使用規范來推動框架的運作。
測試：軟件質量框架非常強調測試，測試是保證質量的必由之路。測試要盡可能的多，盡可能的頻繁、測試結果要盡可能快的反饋。這是軟件質量框架對測試的基本態度。測試是綜合性的，軟件開發過程中的所有工件，都需要伴隨著相應的測試工件。這是基于一個簡單的理念，如果你不能夠為你的工作制定一個完成的標準，你又該如何開展你的工作呢?
文章來源于領測軟件測試網 http://www.anti-gravitydesign.com/
