⑴ 軟體質量保證過程
SQA人員類似於軟體開發過程中的過程警察,其主要職責是:檢查開發和管理活動是否與制定的過程策略、標准和流程一致﹔檢查工作產品是否遵循模板規定的內容和格式。
計劃階段目的和范圍:項目計劃過程的目的是計劃並執行一系列必要的活動,以便在不超過項目預算和日程安排的前提下,將優質的產品交付給客戶。項目計劃過程適用於組織中的所有項目,但每個項目可以根據各自的不同情況對該過程進行裁剪。進人標准:項目啟動會議已經結束﹔在項目周期中,根據項目的跟蹤結果,需要對項目計劃進行修改和完善。輸入:項目啟動報告,項目提案書、項目相關材料、組織資料庫中以往類似的經驗文檔。輸出:評審後的文檔,包括軟體開發質量計劃、軟體項目質量管理計劃、軟體配置管理計劃。過程描述:制定軟體管理計劃﹑軟體質量管理計劃﹑軟體配置管理計劃。
驗證:同級評審人員和軟體質量保證人員必須對項目計劃進行評審,經批准後項目才能付諸實施。
QA檢查清單:軟體開發質量計劃、軟體配置管理計劃。該階段應確保制訂了軟體開發質量計劃和軟體配置管理計劃。
⑵ 軟體測試中如何保證軟體質量
由此看來每一個階段的質量都起著決定性的作用。 以上提及的四個階段的質量將引出以下幾個軟體質量保證的關鍵要素。 完備的需求分析 需求分析的目的是讓項目組明白要做什麼，是決定所開發出來的軟體應當是「長什麼樣的」，顯然完備的需求分析是高質量軟體的前提。如果所開發出來的軟體與用戶所希望的並不一致，那不可能讓用戶說「這個軟體的質量很好」 。如果方向不對，軟體開發得再「好」也沒有意義。需求分析失誤所帶來的開發成本是高昂的，這一點在《軟體工程》這類書籍中都會提及，因此，整個行業對於需求分析的重要性都具有足夠的認識。當然，知道其重要性與如何獲得完備的需求分析又是兩回事，至於如何做好需求分析請讀者參考相關書籍。 需求分析如果出現失誤的話有一個特點—— 它一定會暴露！只不過存在是暴露在軟體開發過程中還是在用戶手中之別。因此，需求分析所造成的問題盡管嚴重，但它能被發現進而能得到項目組的重視，從而也一定能被修復，只是不同階段發現這類問題所花費的成本將有所不同。 設計 設計階段是通過設計方法找出軟體實現更好的方法，注意這里是「更好」兩個字，而不是強調最好。 不良設計並不會象需求分析失誤那樣很容易暴露出其本質，相反，它所暴露出的更多是表象，比如邏輯復雜、維護時舉步為艱等等。如果參與者不具備一定的洞察力以發現隱藏在現象背後的不良設計本質，則很有可能身受其害卻不能自拔，還以為「本來就有那麼復雜」。 項目的開發是一個逐步演進的過程，項目組成員對於需求的理解也是逐步加深的，一開始合適的設計到後面看來很有可能就不夠全面或顯得力不從心，如果仍沿用以前的設計則自然將暴露出它的不足，進而會出現需要更高的維護成本。重構思想的提出，就是用於幫助項目演進設計的，當然，在運用重構方法時，應盡可能保證項目有足夠的單元測試用例，以預防重構時又引入新的缺陷。重構不只是一個詞，其核心應當是一個方法論，一個用於優化設計的方法論。 編程好習慣 設計階段輸出的結果就是藍圖，但好的藍圖並不能保證最後的質量一定就好。拿造房子打個比方，圖紙設計得再好，如果建造時用的材料不過關，那最終的房子一定好不了。那軟體開發中的「建築材料」又是什麼呢？就是程序員所編寫的代碼。如何保證其質量呢？這需要通過良好的編程習慣去保證。 在現實的項目中，設計有可能與編碼會有一定的揉合，即通過進行一定的編碼來輔助設計。這種實踐方式並不影響這里將設計與編碼分為兩個質量保證關鍵要素。 驗證 驗證很容易讓人想到質量保證的常用方法之一，即測試。但驗證應當包含更多的內涵，比如求證軟體需求是用戶所希望的就是其中的一種。 對於驗證的理解仍需要拿房屋的建造作為一個比方，以便加深理解。在房屋的建造過程中，當建築材料到了工地以後，需要對其進行檢驗，以保證它的質量是合格的，否則不能用於建造。對應於軟體開發，這個階段就是單元測試。當軟體工程師編寫了代碼以後如何保證代碼的行為是其所希望的呢？那隻能通過單元測試去驗證。房子建造好了以後，還得對房子進行整體的驗收以確保其最終是合格的。比如抽查牆壁所使用的水泥與沙的配比是合適的。雖然水泥和沙在進入工地時都經過了質檢且是合格的，但在建造的過程中需要按一定的比例混合它們以作建築粘合劑，而混合比例將確定粘合強度。在軟體開發過程中，軟體集成測試就如同房子在建造好了以後的驗收。 從上面的比方能得出幾個結論。第一，在軟體開發過程中單元測試是必不可少的。它的缺少如同將沒有檢驗過的建築材料用於建造一樣。第二，單元測試應當在集成測試之前完成。有的項目在一開始時並沒有單元測試流程，但後來發現需要增加這個環節，於是出現了集成測試完成了以後，再進行單元測試這種情形。這種情形還是有點怪怪的，這如同房子已造好了，再將牆打掉去檢查裡面的磚是否是好的一樣。「將牆打掉檢查磚」這種行為的勇氣雖然可佳，但是如果盡早地在項目中部署單元測試就能避免這種怪現象的發生。 集成（包括開發集成和系統集成）測試在軟體行業被廣泛採用以保證軟體質量，但單元測試對於軟體質量保證的重要性在整個行業還缺乏廣泛的、深刻的認識，其更多地被當作是負擔而不是一種有效的質量保證手段。
⑶ 如何保證軟體質量
國產軟體在最近10年來發展迅速，從最早的應用軟體開發，到現在擁有自己國產品牌的操作系統、資料庫、中間件，以及自己的集成應用商，已經可以滿足企業的一般辦公需求。「可能在穩定性上或者兼容性上還存在一些問題，但是這並不影響它的日常使用和在一些領域的推廣和應用。」 國家應用軟體產品質量監督檢驗中心副主任左家平如是說。但她也強調，軟體的正版化肯定是有利於自身行業的發展。「如果你做一個東西很快就被盜版，沒有了價值，大家就都不去做了，行業也就亂了。」她說。 談到測試，左家平給出了一個簡單明了的解釋：「系統測試其實起到一個連接作用。」即完成從操作系統到中間件，到資料庫，到Office應用中所有相關介面、功能、性能等的一連串測試，以保證這個系統的可用性。從解決方案的角度來說，就是先要對單個軟體產品進行測試，再把相關的軟體集成起來進行測試，這樣才能對整個解決方案是否可用進行評價。 軟體的質量分三部分：內部質量、外部質量和使用質量。 內部質量是由廠商內部做的，就是廠商通過自己內部的測試方式來進行保證。每一個源代碼要開放，然後看有沒有死循環，有沒有語法錯誤，有沒有其他問題，是通過這種完全開放源代碼的形式進行測試的。外部質量度量主要是通過測試用例的輸入，來驗證輸出結果能不能達到預期要求，在測試工具應用、測試思路設計、測試重點選擇和人才技能需求等方面都與內部質量度量有很大的差異。而使用質量，實際上也就是用戶質量，是通過模擬用戶使用來進行評價的。國家應用軟體產品質量監督檢驗中心現有的人員和技術能夠對軟體的內部質量、外部質量，以及使用質量進行全面度量，因為只有這樣才能把軟體產品質量測試做成一條線，才能形成系統的質量評測方法，這也是國際標准中通常所採用的方法。 雖然叫做軟體質量監督檢驗中心，但在左家平看來，中心更多的工作是在做服務，是從服務角度來推動軟體產業的發展。按照國家《產品質量法》的相關要求，如果要開展對一種產品的監督抽查工作，就必須依據相應的標准、規范，因此監督抽查是要標准先行的。如果標准滯後，就會影響到抽查結果的判定和評價。對於軟體產業中產品標准嚴重滯後的現象，中心更多的工作還是從服務需求方、開發方角度來做軟體產品的質量監督。比如，通過軟體質量測試服務告訴用戶，產品中有什麼樣的問題，它技術瓶頸在哪裡，然後再提出改進方案。
⑷ 如何做好軟體的質量管理
在實際的項目質量管理中，質量管理總是圍繞著質量保證(Quality?Assurance)過程和質量控制(Quality?Control)過程兩方面。這兩個過程相互作用，在實際應用中還可能會發生交叉。正如引言所述，關於軟體的質量，很難下一個非常明確的定義。本文主要針對軟體工程中的質量管理來進行討論。
1、做軟體「大餐」的工序
軟體質量保證（Software?Quality?Assurance，以下簡稱SQA）的目的是驗證在軟體開發過程中是否遵循了合適的過程和標准。軟體質量保證過程一般包含以下幾項活動：
首先是建立SQA組；其次是選擇和確定SQA活動，即選擇SQA組所要進行的質量保證活動，這些SQA活動將作為SQA計劃的輸入；然後是制定和維護SQA計劃，這個計劃明確了SQA活動與整個軟體開發生命周期中各個階段的關系；還有執行SQA計劃、對相關人員進行培訓、選擇與整個軟體工程環境相適應的質量保證工具；最後是不斷完善質量保證過程活動中存在的不足，改進項目的質量保證過程。
獨立的SQA組是衡量軟體開發活動優劣與否的尺度之一。SQA組的這一獨立性，使其享有一項關鍵權利――「越級上報」。當SQA組發現產品質量出現危機時，它有權向項目組的上級機構直接報告這一危機。這無疑對項目組起到相當的「威懾」作用，也可以看成是促使項目組重視軟體開發質量的一種激勵。這一形式使許多問題在組內得以解決，提高了軟體開發的質量和效率。
⑸ 誰知道如何提高軟體質量
【摘要】 軟體質量是軟體產品的靈魂。本文全面介紹了質量的概念，提出了從流程、技術、組織管理、人員技能發展等多個角度提高軟體質量的重要性；並對目前國際上流行的 CMM 標准進行了介紹，提出了使用 PSP 和 TSP 來實現 CMM 的方法。本文最後還給出了中小型軟體公司在提高軟體質量方面的一個初步思路。【關鍵字】 質量管理，軟體開發過程模型，軟體分析和設計方法，軟體測試， CMM 如何提高軟體的質量已經不是一個純粹的技術問題，而是一個工程的問題。自從計算機誕生以來，相應的軟體開發就存在了。由於早期的計算機運行性能較低，軟體的可編程范圍也較狹窄，因此質量問題就沒有那麼突出。 50 年代後期到 60 年代，高級語言的相繼誕生並得到了廣泛的應用，隨之而來的是軟體規模也越來越龐大，越來越復雜。伴隨著軟體應用的越來越廣泛，軟體的質量問題就變得越來越突出。根據美國國家宇航局 NASA 的統計，在 80 年代初，軟體引起的故障與硬體引起的故障，其比率約為 1.1:1.0 ，到了 80 年代末，這一比率已達到 2.5:1.0 。因此如何提高軟體的質量成為軟體工程研究的一個重點。自從軟體危機產生以來，出現了很多提高產品質量的理論和方法，有的從技術角度出發，例如：面向對象技術的產生和推廣，第四代語言的誕生等等；有的從自動化工具入手，例如： CASE 工具、過程式控制制軟體、自動化管理平台等；有的從過程模型角度出發，例如：迭代模型、螺旋模型、 RUP 、 IPD 、凈室軟體工程等；也有從管理角度出發的，例如：團隊管理、績效管理、 PSP 、 TSP 等；也有從測試角度出發的，例如：加強全流程的測試等；一些相應的規范和標准也孕育而生，例如： ISO9000 系列、 CMM 、 QMS 等。然而每一種技術都不是絕對的，軟體質量的提高應該是一個綜合的因素，需要從每個方面進行改進，同時還需要兼顧成本和進度。一、什麼是質量？ 作為軟體產品的銷售人員，市場人員或維護人員經常會受到客戶這樣那樣的指責或抱怨，客戶說：你們產品的質量太差，不穩定等等。那麼什麼是質量呢？我們該如何來衡量質量呢？質量具有三個維度：" 符合目標。目標是客戶所定義的，符合目標即判斷我們是不是在做需要做的事情。" 符合需求。即產品是不是在做讓它做的事情。" 符合實際需求。實際的需求包括用戶明確說明的和隱含的需求。ISO 關於質量的定義表示如下：「 一個實體（產品或服務）的所有特性，基於這些特性可以滿足明顯的或隱含的需要。 」 注意，在這個定義中包含明顯的需求和隱含的需求。而往往我們會忽略隱含的需求。因此在控制一個產品的質量的過程中必須關注這些隱含的需求，並給予應有的驗證。 另一方面因為我們的產品是為客戶提供服務的，因此凡是不滿足客戶需求的，我們都認為是一個失效（ failure ）。所以我們的產品必須始終圍繞著客戶的需求進行開發和驗證。 這里我們談到客戶，其實在一個軟體的需求收集過程中需要關注客戶和用戶。而我們經常會忽略客戶與用戶之間的區別。那麼誰是客戶？誰是用戶呢？簡單的來說， 客戶是真正能夠決定是否購買你軟體的人，而用戶是實際使用軟體的人。了解了這個區別，對於你在分析需求的重要性的時候就可以進行參考。同時在產品質量驗證 的時候也可以做出不同的權衡。另一方面我們在考慮我們用戶需求的時候，往往只考慮了實際使用軟體的人員，而忽略了其它一些人員對軟體的要求或對軟體造成的 潛在競爭，這包括維護人員的要求、系統管理人員的要求、軟體上下遊人員的要求、先前版本的情況、市場上競爭對手的軟體情況等。 每個人提到質量的時候，經常會遇到下列矛盾，在這些矛盾中隱含著對質量的承諾【 5 】：" 質量需要一個承諾，尤其是高層管理者的承諾。但為了得到質量，高層管理者必須和其僱用的員工進行緊密合作；" 許多人相信沒有缺陷的產品和服務是不可能的。但是控制在一定級別的缺陷數是正常並可接受的；" 質量經常是和成本緊密聯系在一起，一個高質量的產品同時也意味著高投入。這是設計的質量和一致性質量的一個矛盾；" 一個高的質量要求需求規格說明書足夠詳細，以便產品可以根據這些規格說明書進行定量的分析。然而許多組織沒有能力或者不願意產生如此詳細程度的規格說明書；" 技術人員經常相信規范和標准會束縛他們的創造力，因此就不遵照標准做事。然而如果要得到高質量的產品，就必須遵循良好定義的標准和過程。二、流程對質量的貢獻 好了，既然已經了解了什麼是質量，那麼怎麼才能改進軟體產品的質量呢？從一個企業的長遠發展來看，首先應當從流程抓起，規范軟體產品的開發過程。這是一個 軟體企業從小作坊的生產方式向集成化、規范化的大公司邁進的必經之路，也是從根本上解決質量問題，提高工作效率的一個關鍵手段。 軟體產品的開發同其它產品（如汽車）的生產有著共同特性，即需要按一定的過程來進行生產。在工業界，流水線生產方式被證明是一種高效且能夠比較穩定地保證 產品質量的一種方式。通過這種方式，不同的人員被安排在流程的不同位置，最終為著一個目標共同努力，這樣可以防止人員工作間的內耗，極大的提高工作效率。 並且由於其過程來源於成功的實例，因此其最終的產品質量能夠滿足過程所設定的范圍要求。軟體工程在軟體的發展過程中吸取了這個經驗並把它應用到了軟體開發 中，這就形成了軟體工程過程，簡單的說就是開發流程。 無論做什麼事情，都有一個循序漸進的過程，從計劃到策略再到實現。軟體流程就是按照這種思維來定義開發過程，它根據不同的產品特點和以往的成功經驗，定義 了從需求到最終產品交付的一整套流程。流程告訴我們該怎麼一步一步去實現產品，可能會有那些風險，如何去避免風險等等。由於流程來源於成功的經驗，因此， 按照流程進行開發可以使得我們少走彎路，並有效的提高產品質量，提高用戶的滿意度。 目前流行的流程方法有很多種，不同的過程模型適合於不同類型的項目。瀑布模型是應用的最為廣泛的一種模型，也是最容易理解和掌握的模型，然而它的缺陷也是 顯而易見的。遺漏的需求或者不斷變更的需求會使得該模型無所適從。然而，對於那些容易理解但很復雜的項目，採用瀑布模型會是比較適合的，因為你可以按部就 班的去處理復雜的問題。在質量要求高於成本和進度要求的時候，該模型表現的尤其突出。螺旋模型是也是一個經典模型，它關注於發現和降低項目的風險【 8 】。螺旋型項目從小的規模開始，然後探測風險，制定風險控制計劃，接著確定下一步項目是否還要繼續，然後進行下一個螺旋的反復。該模型的最大優點就是隨著成本的增加，風險程度隨之降低。然而螺旋模型的缺點是比較復雜，且需要管理人員有責任心，專注以及有管理方面經驗。RUP （ Rational Unified Process ）是 Rational 公司提出的一套開發過程模型，它是一個面向對象軟體工程的通用業務流程【 9 】。它描述了一系列相關的軟體工程流程，它們具有相同的結構，即相同的流程構架。 RUP 為在開發組織中分配任務和職責提供了一種規范方法，其目標是確保在可預計的時間安排和預算內開發出滿足最終用戶需求的高品質的軟體。 RUP 具有兩個軸，一個是時間軸，這是動態的。另一個是工作流軸，這是靜態的。在時間軸上， RUP 劃分了四個階段：初始階段、細化階段、構造階段和發布階段。每個階段都使用了迭代的概念。在工作流軸上， RUP 設計了六個核心工作流程和三個核心支撐工作流程，核心工作流軸包括：業務建模工作流、需求工作流、分析設計工作流、實現工作流、測試工作流和發布工作流。核心支撐工作流包括：環境工作流、項目管理工作流和配置與變更管理工作流。具體可以參考圖 1 。 RUP 匯集現代軟體開發中多方面的最佳經驗，並為適應各種項目及組織的需要提供了靈活的形式。作為一個商業模型，它具有非常詳細的過程指導和模板。但是同樣由於該模型比較復雜，因此在模型的掌握上需要花費比較大的成本。尤其對項目管理者提出了比較高的要求。圖1 RUP 工作流程示意圖IPD （ Integrated Proct Development ）流程是由 IBM 提出來的一套集成產品開發流程，非常適合於復雜的大型開發項目，尤其涉及到軟硬體結合的項目。 IPD 從整個產品角度出發，流程綜合考慮了從系統工程、研發（硬體、軟體、結構工業設計、測試、資料開發等）、製造、財務到市場、采購、技術支援等所有流程。是 一個端到端的流程。在 IPD 流程中總共劃分了六個階段（概念階段、計劃階段、開發階段、驗證階段、發布階段和生命周期階段），四個個決策評審點（概念階段決策評審點、計劃階段決策評 審點、可獲得性決策評審點和生命周期終止決策評審點）以及六個技術評審點，具體可以參考圖 2 。 IPD 流程是一個階段性模型，具有瀑布模型的影子。該模型通過使用全面而又復雜的流程來把一個龐大而又復雜的系統進行分解並降低風險。一定程度上，該模型是通過 流程成本來提高整個產品的質量並獲得市場的佔有。由於該流程沒有定義如何進行流程回退的機制，因此對於需求經常變動的項目該流程就顯得不大適合了。並且對 於一些小的項目，也不是非常適合使用該流程。圖2 IPD 流程示意圖三、流程與技術 流程和成功不是等價的。沒有流程就成功是不可能得到保證，但有了流程並不意味著肯定能夠成功。這恐怕是很多迷信於流程的人所不能接受的。但這的確是個事實。記得有個做了將近 30 多年的需求分析專家說過：即使是一個已經達到 CMM4 級的公司，也完全有可能做不好需求分析。為什麼？技術，技術是成功的另外一個必要條件。就好比現在你要從上海到北京去，流程給你指出了最短的路徑，技術提供給你最快的交通工具。兩者結合就是完美。 對於軟體開發來說，要保證軟體的質量，需要掌握多方面的技術，包括分析技術、設計技術、編碼技術和測試技術等等。在國內有一個普遍的非正常現象，就是大家 覺得只有編程能力才是玩電腦的真正技能。就好像造一套房子，其它都不重要，只要磚瓦匠有高超的技能就行了。盡管這個比喻會打擊很多程序員的自尊心，但這的 確是一個事實。我們缺少系統級的工程師，在分析和設計方面的工作做得很不扎實。需求是一個項目的靈魂。模稜兩可的需求帶來不可避免的後果便是返工 —— 重做一些你認為已做好的事情。返工會耗費開發總費用的 4 0 % ，而 7 0 % ～ 8 5 % 的重做是由於需求方面的錯誤所導致的（ l e ff i n g w e l l1 9 9 7 ）【 10 】。想像一下如果你能減少一半的返工會是怎樣的情況？你能更快地開發出產品，在同樣的時間內開發更多、更好的產品，甚至能偶爾回家休息休息。在《軟體需求》一書中關於如何進行需求分析給出了比較詳細的介紹【 7 】， RUP 中關於需求的指導也是很實用的。 設計是最能體現一個工程師能力和水平的環節。一個好的設計基本上決定了產品的最終質量。設計是把需求轉換成系統的一個關鍵步驟，它需要從自然語言描述的需求中尋找出設計的基礎單元，構建出整個系統的構架。在 RUP 中關於系統構架師和設計師的定位是相當高的。關於設計方面的技能涉及面是很廣的，包括傳統的結構化設計到面向對象設計。設計人員需要掌握一定的建模技術。 UML 是國際上比較流行的一種建模語言【 11 】。在嵌入式方面， SDL 也是一種非常好的選擇。《設計模式》是在設計思想方面總結的非常出色的一本書【 6 】，作為一名設計人員（尤其是面向對象設計人員）必須要好好研究一下。但是對這些模式的應用應當講究一種自然的應用，千萬不要因為模式而去設計模式，否則會適得其反。 現在的程序員熱中於掌握多種編程語言，或者講究語言的過分技巧化，而往往忽略了編程語言的規范化。不規范的語言應用給程序的可理解性、可維護性以及可測試 性帶來了大的傷害，進而損害了產品的質量。某公司曾對中國程序員和印度程序員做過一個測驗，這個測驗要求參加者對一組數進行排序。測試結果發現，印度程序 員設計的程序使用的演算法並不是最優，但卻是最不容易出錯的，並且幾個程序員寫出來的代碼如出一轍。而幾個中國程序員寫出的代碼，有的非常漂亮，很精練，效 率很高；有的卻很冗雜，還有錯誤。如果大家是在做研究性的項目或純粹興趣性的項目，那麼充分發揮自己的編程天才也無可厚非。然而，對於一個軟體公司，產品 最終是要交給用戶的，需要遵循的是一個軟體產品的開發工程。因此這類軟體的開發需要遵循一定的編程規范，畢竟開發的軟體不是自己用，還需要和別人的集成， 還需要給以後版本重用和維護。 測試的技術將在第五節進行闡述。總之流程很關鍵，技術也很重要，我的觀點是：魚和熊掌，兩者都不能放。
⑹ 保證軟體質量所應關注的幾個方面.txt
，軟體質量就是「軟體與明確的和隱含的定義的需求相一致的程度」。具體地說，軟體質量是軟體符合明確敘述的功能和性能需求、文檔中明確描述的開發標准、以及所有專業開發的軟體都應具有的隱含特徵的程度。 影響軟體質量的主要因素，這些因素是從管理角度對軟體質量的度量。可劃分為三組，分別反應用戶在使用軟體產品時的三種觀點。正確性、健壯性、效率、完整性、可用性、風險（產品運行）；可理解性、可維修性、靈活性、可測試性（產品修改）；可移植性、可再用性、互運行性（產品轉移）。
軟體質量保證是建立一套有計劃，有系統的方法，來向管理層保證擬定出的標准、步驟、實踐和方法能夠正確地被所有項目所採用。軟體質量保證的目的是使軟體過程對於管理人員來說是可見的。它通過對軟體產品和活動進行評審和審計來驗證軟體是合乎標準的。軟體質量保證組在項目開始時就一起參與建立計劃、標准和過程。這些將使軟體項目滿足機構方針的要求
軟體質量管理可以說是一個制度或者一個體系，對於一個軟體的全局把控