一、軟件質(zhì)量管理的現狀 　　
在現實(shí)軟件開(kāi)發(fā)過(guò)程中，許多軟件產(chǎn)品卻時(shí)常陷入質(zhì)量低下、甚至軟件不符合用戶(hù)需求的旋渦。究其根源，有以下幾個(gè)方面: 　　
1、軟件質(zhì)量保證技術(shù)(審查、復審和測試)沒(méi)有貫穿到整個(gè)軟件開(kāi)發(fā)全過(guò)程中去。 　　
2、在于這些軟件產(chǎn)品對其質(zhì)量?jì)群陌盐?，僅僅停留在減少軟件運行錯誤、加強軟件測試，避免軟件缺陷的一般性層面，而對整個(gè)軟件開(kāi)發(fā)生命周期的全過(guò)程質(zhì)量管理，缺乏總體架構。 　
3、測試管理的一些誤區也會(huì )導致嚴重的質(zhì)量問(wèn)題。沒(méi)有按照測試原則進(jìn)行盡早測試、連續測試與自動(dòng)化測試。是測試本省變得的形式化。 　　
4、質(zhì)量是全過(guò)程的，不僅是測試。質(zhì)量管理者應該將質(zhì)量控制與保證著(zhù)眼于整個(gè)軟件開(kāi)發(fā)生存周期內。而事實(shí)上，質(zhì)量管理者僅僅認為通過(guò)嚴格的測試就可以保證軟件質(zhì)量。 　　
二、軟件質(zhì)量保證 　　
1、在軟件開(kāi)發(fā)中，可以采用以下措施保證軟件的質(zhì)量; 　　
2、審查。在生命周期每個(gè)階段結束之前，都要使用標準對該階段生產(chǎn)的軟件配置進(jìn)行嚴格的技術(shù)審查; 　　
3、復查和管理復審。復查是檢查已有的材料，以斷定某階段的工作是否能夠開(kāi)始或繼續;管理復審是向開(kāi)發(fā)組織或使用部門(mén)的管理人員，提供有關(guān)項目的總體狀況、成本和進(jìn)度等方面的情況，以便他們從管理角度對開(kāi)發(fā)工作進(jìn)行審查。 　　
4、測試。通過(guò)測試計劃、測試過(guò)程與測試結果對軟件質(zhì)量進(jìn)行保證; 　　
5、軟件質(zhì)量保證活動(dòng)。以上各項活動(dòng)內容都須寫(xiě)入質(zhì)量保證計劃，并由質(zhì)量保證小組監督實(shí)施。由此可見(jiàn)，質(zhì)量保證既是技術(shù)活動(dòng)，也是管理活動(dòng); 　　
6、軟件評審。評審是以提高軟件質(zhì)量為目的的技術(shù)活動(dòng)。要通過(guò)對軟件的規格說(shuō)明、可靠性、性能實(shí)現、可修改性、可擴充性、可移植性、可測試性、可復用性以及評審的實(shí)施等方面對軟件項目做好嚴格的評審，以確保軟件質(zhì)量; 　　
7、采用質(zhì)量保證標準。質(zhì)量標準用于實(shí)現質(zhì)量管理的組織結構、責任、規程、過(guò)程和資源。采用ISO質(zhì)量保證模型?？梢杂糜谫|(zhì)量計劃、質(zhì)量控制、質(zhì)量保證和質(zhì)量改經(jīng)所需的組織結構、規程、過(guò)程和資源; 　　
8、結構化的軟件測試。經(jīng)過(guò)嚴格的軟件測試，盡可能找出軟件計劃、總體設計、詳細設計、軟件編碼的錯誤，并加以糾正，才能提高軟件的質(zhì)量。測試要覆蓋整個(gè)軟件的生存周期，而不限于程序的編碼階段。 　　
9、軟件維護。采用結構化維護，完整的軟件配置為基礎，通過(guò)完善性維護、糾錯性維護、適應性維護及預防性維護提高軟件質(zhì)量。 　　
三、質(zhì)量管理實(shí)施 　　
1、項目進(jìn)度的質(zhì)量保證 　　
項目進(jìn)度是項目進(jìn)行是否順利的更直觀(guān)表現。顯然在項目開(kāi)始之前，項目開(kāi)發(fā)計劃是需要的。如果項目開(kāi)發(fā)計劃的制定的是完全合理的，那項目進(jìn)度也就真實(shí)表達了項目與更終的交付使用之間的距離，然而要制定完全合理的項目開(kāi)發(fā)計劃幾乎不太可能?？梢?jiàn)要保證項目進(jìn)度，首先要保證項目開(kāi)發(fā)計劃盡可能合理。 　　
2、項目開(kāi)發(fā)各階段的質(zhì)量保證 　　
2.1需求分析 　　
需求分析是開(kāi)發(fā)人員對系統需要做什么的定義過(guò)程。從系統分析的經(jīng)驗來(lái)看，這個(gè)過(guò)程往往是個(gè)循序漸進(jìn)的過(guò)程，一次性對系統形成完整的認識是困難的。只有不斷地和客戶(hù)領(lǐng)域專(zhuān)家進(jìn)行交流確認，方能逐步明了用戶(hù)的需求。從系統開(kāi)發(fā)的過(guò)程得知，系統分析時(shí)犯下的錯誤，會(huì )在接下來(lái)的階段被成倍的放大，越是在開(kāi)發(fā)的后期，糾正分析時(shí)犯下的錯誤所花費的代價(jià)越是昂貴，也越發(fā)影響系統的工期和系統的質(zhì)量。 　　
2.2系統設計    
優(yōu)良的體系結構應當具備可擴展性和可配置性，而好的體系結構則需要好的設計方法，自然設計選型成為了系統設計首要的工作，究竟是采用哪種設計方法好呢? 　　
對于設計選型不能一概而論，需要針對項目的結構、項目的特征和用戶(hù)的需求來(lái)分析，同樣也要考慮到參與項目小組成員的素質(zhì)，如果其中大部分都沒(méi)有從事過(guò)面向對象的設計且項目進(jìn)對緊迫，這樣沒(méi)有多余的時(shí)間來(lái)培訓小組成員來(lái)掌握面向對象的設計方法，盡管眾所周知面向對象設計方法的優(yōu)勢，我們還是不如采用面向過(guò)程的方式(除用戶(hù)指定開(kāi)發(fā)設計方式外)可以減少項目承擔的技術(shù)風(fēng)險。 　　
2.3實(shí)現 　　
實(shí)現也就是編碼過(guò)程。這里不僅包括代碼的產(chǎn)生，同時(shí)也包括測試用例的產(chǎn)生。針對上一階段提供詳細設計，程序員開(kāi)始編碼并且調試程序，測試人員則根據設計進(jìn)行測試用例的設計，設計出來(lái)的用例需要得到項目組成員認可由項目經(jīng)理審核通過(guò)才能進(jìn)入配置庫。同時(shí)程序員調試完程序提交測試人員進(jìn)行程序正確性檢測。 　　
2.4文檔管理 　　
文檔維護主要是配置管理小組的工作。 　　
如何保證文檔的全方面性，使其真實(shí)為項目的進(jìn)度提供保證，又不因為文檔的寫(xiě)作而耽誤項目的進(jìn)度，這仍然是一個(gè)比較難解決的問(wèn)題。解決此問(wèn)題，其核心仍然是個(gè)“度”的問(wèn)題。