【正文】 往往起到監(jiān)督和管理工作的作用?！癤P”中的一個思想“人比過程更重要”可以說這兩個思想是CMM背后的基礎(chǔ)。SQA計劃進(jìn)行SQA審計工作，按照規(guī)則發(fā)布審計結(jié)果報告。SEPG（軟件工程過程）要負(fù)責(zé)開發(fā)和維護(hù)級配置管理工作的相關(guān)流程及模版，并負(fù)責(zé)對配置管理員進(jìn)行培訓(xùn)和過程指導(dǎo)，參與審計軟件配置管理的過程，并協(xié)助相關(guān)人員制訂軟件配置管理的過程改進(jìn)方案。配置審計主要是對基線和配置庫的完整性、正確性和基線間的一致性進(jìn)行審計。l 灰盒測試：介于白、黑兩者之間，是兩者的結(jié)合。自動化測試有如下優(yōu)點Error! Reference source not found.：(1) 一旦積累了一套自動化測試程序，日后自動化測試節(jié)省大量的時間和資源；(2) 沒有時間限制——一般安排在下班后；(3) 可以反復(fù)執(zhí)行；(4) 保證測試執(zhí)行過程的一致性及準(zhǔn)確性；(5) 有較高的功能測試覆蓋率；(6) 有模擬操作，進(jìn)行壓力測試，這是手測很難實現(xiàn)的。帕累托圖是一種柱狀圖，如圖13所示。內(nèi)部文檔的及時產(chǎn)生和規(guī)范，是保證項目開發(fā)各小組能夠更好的接口和溝通的重要前提，從另一個方面講，也是保證工程不被某個關(guān)鍵路徑所阻塞而延滯的前提。在項目開發(fā)的過程中幾乎所有的部門都與質(zhì)量保證小組有關(guān)。 項目計劃的合理程度與項目計劃制定者從事類似規(guī)模和類似業(yè)務(wù)的項目的經(jīng)驗有直接關(guān)系，通過經(jīng)驗往往能夠預(yù)見潛在的阻礙，這樣要求項目計劃制定者需要集眾人之力來完善計劃。對于開發(fā)過程存在的需求變動，我們要求用戶填寫變更申請單發(fā)送給項目配置管理員，在通過配置管理員轉(zhuǎn)交質(zhì)量保證小組，負(fù)責(zé)組織專家小組和項目組成員一起討論實施變更的可行性及實施后所帶來的影響，小的變更則直接記錄入變更記錄原因分析項和風(fēng)險項欄，大的變更則需要形成正式的變更報告，無論那種變更都需要對相應(yīng)的文檔實施同步變更（包括需求規(guī)格說明書、詳細(xì)設(shè)計文、安裝手冊、操作手冊等）。在公司，維護(hù)小組的任務(wù)一方面是保證對項目客戶的跟蹤服務(wù)，另一方面是確保該項目其它的開發(fā)人員從項目中盡快的解脫出來以便投入到下一個項目的開發(fā)中。構(gòu)件接口及調(diào)用說明；系統(tǒng)操作索引。文檔的管理是一個非常煩瑣的工作，但是長遠(yuǎn)來看它不僅使項目的開發(fā)對單個主要人員的依賴減少，從而減少人員流動給項目的帶來的風(fēng)險，更重要的是在項目進(jìn)行到后百分之十的時候起到拉動項目的作用。如果書寫文檔的人員認(rèn)為文檔的更細(xì)致的部分可以由他人幫助完成，則該文檔即交由他人完成，但此時文檔并不算被正式提交，當(dāng)他人書寫完畢之后，必須由文檔的初寫者進(jìn)行復(fù)審，復(fù)審?fù)ㄟ^后方可以正式提交，進(jìn)入軟件配置管理的循環(huán)中。軟件安裝手冊；體系結(jié)構(gòu)設(shè)計說明；通過測試活動，盡可能早得發(fā)現(xiàn)每個階段中軟件存在的缺陷，以方便后續(xù)階段的實施。這要求我們再設(shè)計階段通過對用戶需求的仔細(xì)研究，盡可能的識別出公共類，并進(jìn)行定義指定專人負(fù)責(zé)設(shè)計通知其它設(shè)計人員，以減少重復(fù)工作。顯然在項目開始之前，項目開發(fā)計劃是必須的。 測試人員只有根據(jù)軟件需求規(guī)格說明書所提及的功能進(jìn)行檢測，才能確保項目組開發(fā)的軟件產(chǎn)品滿足用戶需求。本人一直在公司任軟件質(zhì)量管理工作。(5) 確定各缺陷原因。該測試用例通過技術(shù)評審后，進(jìn)入一步工作，根據(jù)測試用例執(zhí)行測試。按軟件測試特性可以把軟件測試分為白盒測試、灰盒測試和黑盒測試三種，其特征及包含的內(nèi)容如下。在軟件配置管理中要實現(xiàn)有效地進(jìn)行變更控制就需要通過配置庫來完成，配置庫分為以下三種：開發(fā)庫是指給開發(fā)和測試人員日常使用的，需要頻繁對其內(nèi)容進(jìn)行修改的，或者說開發(fā)庫中存放的是正在開發(fā)而未完成的工作產(chǎn)品，開發(fā)庫也會有權(quán)限控制的功能，但比較寬松。在一些管理不規(guī)范的項目中，經(jīng)常會出現(xiàn)一些被修復(fù)的缺陷又再次發(fā)生，一些新開發(fā)的功能又不見了，之前測試通過的項目又出現(xiàn)問題等情況，這些情況都有可能因為開發(fā)人員把代碼互相覆蓋造成的，也就是說軟件產(chǎn)品版本出現(xiàn)混亂。 l 明確審計結(jié)果報告的規(guī)則：審計的結(jié)果報告給誰。CMM關(guān)注的軟件生產(chǎn)有如下特點：質(zhì)量重、規(guī)模較大。 現(xiàn)在許多實施通過項目質(zhì)量計劃和總結(jié)，項目過程中的經(jīng)驗和教訓(xùn)將得到完整的記錄和升華，成為“組織財富”。對于見證點或停工待檢點要防止跳過檢查，因為避免錯誤的成本總是大大低于補救錯誤的成本。編制質(zhì)量計劃通常采用流程圖、因果分析圖等方法對項目進(jìn)行分析，確定需要監(jiān)控的關(guān)鍵元素，設(shè)置合理的見證點（W點）、停工待檢點（H點），并制定質(zhì)量標(biāo)準(zhǔn)： 1) 流程圖： 顯示系統(tǒng)的各種成分是如何相互關(guān)系的，幫助我們預(yù)測在何處可能發(fā)生何種質(zhì)量問題，并由此幫助開發(fā)處理他們的辦法。充分認(rèn)識項目屬性，有利于做好項目管理。自從1986年在聯(lián)邦德國召開的一次國際會議上正式提出并采用“軟件工程”Error! Reference source not ，研究軟件工程的專家學(xué)者們陸續(xù)提出了100多條關(guān)于軟件工程的準(zhǔn)則或“信條”。通過預(yù)防產(chǎn)生質(zhì)量，要求資源的配置能保證工作正確地完成，而不是把資源浪費在問題的查找和補救上面。(4) Action(糾正)：實施糾正行動。3) 社會屬性，質(zhì)量很多時候體現(xiàn)的是一種理念，是哲學(xué)而不僅僅是方法，它與社會的價值觀有直接的關(guān)系。質(zhì)量控制是對階段性的成果進(jìn)行檢測、驗證，為質(zhì)量保證提供參考依據(jù)，它是一個PDCA循環(huán)過程。正如著名的質(zhì)量管理專家朱蘭()1994年在美國質(zhì)量管理學(xué)會年會上所說，20世紀(jì)將以“生產(chǎn)率的世紀(jì)”載入史冊，未來的21世紀(jì)將是“質(zhì)量的世紀(jì)”。我們應(yīng)該學(xué)習(xí)國外企業(yè)的成功經(jīng)驗，但不能脫離了政治、經(jīng)濟、歷史、文化因素孤立地去學(xué)。2) 統(tǒng)計質(zhì)量控制階段：隨著現(xiàn)代應(yīng)用數(shù)學(xué)的發(fā)展，數(shù)理統(tǒng)計原理、概率論被應(yīng)用到質(zhì)量管理中，在有條件的地方廣泛推行抽樣檢驗，利用控制圖對生產(chǎn)的工序進(jìn)行動態(tài)控制，有效地防止了廢品的產(chǎn)生，減少了不合格品，降低了成本。 Crosby理論零缺陷管理之父——菲利浦基本原則四：質(zhì)量的衡量，質(zhì)量是用不符合要求的代價（Price of Nonconformance, PONC）來衡量的，而不是用指數(shù)。以上7條只是基本原理，對每一個軟件企業(yè)而言，如何根據(jù)這幾條原理管理和改進(jìn)軟件產(chǎn)品的開發(fā)和維護(hù)過程，問題還是不少，主要是可操作性差，缺少評價標(biāo)準(zhǔn)，以及缺少相互之間的可比性。項目管理的基本職能有9個，分別為：項目整體管理、項目范圍管理、項目時間管理、項目成本管理、項目質(zhì)量管理、項目人力資源管理、項目溝通管理、項目風(fēng)險管理、項目采購管理。第四章 軟件項目質(zhì)量管理論述作為國內(nèi)軟件企業(yè)，要想在同行業(yè)樹立自己的品牌，在國際軟件外包業(yè)務(wù)中取得更多的市場份額，僅靠以往的人力資源優(yōu)勢已經(jīng)不太現(xiàn)實，提高軟件質(zhì)量才是軟件企業(yè)的唯一出路。質(zhì)量控制階段應(yīng)根據(jù)驗收數(shù)據(jù)做出驗收決定，確定是否進(jìn)入下一步工序。SQA人員一般需要有豐富的技術(shù)和管理經(jīng)驗，不同能力的SQA可以在質(zhì)量管理過程扮演不同角色。是值得我們思考的。 上面這些內(nèi)容形成了我們對軟件過程地位、價值的基本理解；在這個基礎(chǔ)上我們可以引申討論變更控制委員會CCB（Change Control Board）負(fù)責(zé)審批基線的變更，并確保每個基線的變更都經(jīng)過所有項目相關(guān)人員的認(rèn)可，通過正式的評審活動對變更進(jìn)行分析、評估風(fēng)險工作量，并對是否變更做出結(jié)論。審時的時機有2個：階段性里程碑處和基線變更之后。測試工程師對軟件工程結(jié)構(gòu)有一定了解，但了解的程度又不需要達(dá)到白盒測試的深度。自動化測試并不能完全取代手測，與任何事物一樣，自動化測試也有它的不完美之處。帕累托圖對問題發(fā)生的頻率或影響按照從大到小的方式進(jìn)行排列，從而確定解決問題的先后順序。如上所述，配置管理小組還是保證質(zhì)量保證小組得以發(fā)揮作用的基礎(chǔ)。質(zhì)量保證小組對項目經(jīng)理提供項目進(jìn)度與項目真正開發(fā)時的差異報告，提出差異原因和改進(jìn)方法。 當(dāng)項目計劃制定初期，由質(zhì)量保證小組組織召開的項目計劃評審會，邀請公司技術(shù)專家、用戶以及項目組小組成員一起討論項目計劃的可行性，會議通常采用頭腦風(fēng)暴法，各抒己見，會后由指定的記錄員形成質(zhì)量記錄，發(fā)送給相關(guān)人員，對其計劃中不合理的地方進(jìn)行修改完善，并由質(zhì)量保證人員對其結(jié)果跟蹤，以確保項目計劃完整性、可行性，完善后的計劃交由配置管理人員進(jìn)行版本控制。但是對于無法實現(xiàn)或是變更會帶來巨大的影響而將導(dǎo)致進(jìn)度的延期，這時，我們將變更報告提交給用戶或邀請用戶進(jìn)行協(xié)調(diào)會議，討論變更取舍問題或是項目進(jìn)度變更問題。 實現(xiàn)也就是代碼的生產(chǎn)過程。所以通常項目維護(hù)小組成員主要由項目組的少部分開發(fā)人員承擔(dān)完成。組件索引；如何保證文檔的全面性，使其真正為項目的進(jìn)度提供保證，又不因為文檔的寫作而耽誤項目的進(jìn)度，這仍然是一個比較難解決的問題。 從以往做大項目的經(jīng)驗來看，寫作文檔在項目開發(fā)的早期可能會使項目的進(jìn)度比起不寫文檔要稍慢，但隨著項目的進(jìn)展，各個部門需要配合越來越多，開發(fā)者越來越需要知道其他人員的開發(fā)思路和開發(fā)過程，才能使自己的開發(fā)向前推進(jìn)。當(dāng)有文檔模板后需要書寫文檔的人員只剩下填空的工作，從某種意義上講，書寫文檔的速度會加快。 外部文檔主要包括：需求分析；測試活動要盡可能覆蓋整改項目過程，從最初的需求到部署階段，都應(yīng)該制訂詳細(xì)的計劃并編制相應(yīng)的文檔，如測試計劃、測試用例文檔、測試報告等。公共類開發(fā)可以減少工作中的重復(fù)工作，降低開發(fā)成本。從系統(tǒng)開發(fā)的過程得知，系統(tǒng)分析時犯下的錯誤，會在接下來的階段被成倍的放大，越是在開發(fā)的后期，糾正分析時犯下的錯誤所花費的代價越是昂貴，也越發(fā)影響系統(tǒng)的工期和系統(tǒng)的質(zhì)量。 項目進(jìn)度是項目進(jìn)行是否順利的最直觀表現(xiàn)。 測試人員根據(jù)詳細(xì)設(shè)計的文檔對軟件要實現(xiàn)的功能進(jìn)行一一測試，保證軟件的執(zhí)行正確的實現(xiàn)設(shè)計要求，在此也只證明了軟件正確的反映了設(shè)計思想，但是否真正反映了用戶的需求仍需要進(jìn)一步的功能性測試。因此，作為一個好的軟件項目過程，必須針對企業(yè)和項目的實際情況，確定軟件項目運作流程，定義軟件功能及相關(guān)性能，明確各階段的進(jìn)入條件和退出條件，進(jìn)行有效的過程控制與管理，在提高軟件開發(fā)的效率和項