軟件產(chǎn)品質(zhì)量保證措施

軟件產(chǎn)品質(zhì)量保證措施XXX:軟件開發(fā)質(zhì)量保證方案1軟件開發(fā)質(zhì)量保證方案1.1質(zhì)量管理內(nèi)容1.1.1編制和評審質(zhì)量計劃制定質(zhì)量保證計劃:依據(jù)項目計劃及項目質(zhì)量目標確定需要檢查的主要過程和工作產(chǎn)品，識別項目過程中的干系人及其活動，估計檢查時間和人員，并制定出本項目的質(zhì)量保證計劃。質(zhì)量保證計劃的主要內(nèi)容包括:例行審計和里程碑評審，需要監(jiān)督的重要活動和工作產(chǎn)品，確定審計方式，根據(jù)項目計劃中的評審計劃確定質(zhì)量保證人員需要參加的評審計劃。明確質(zhì)量審計報告的報送范圍。質(zhì)量保證計劃的評審:質(zhì)量保證計劃需要經(jīng)過評審方能生效，以確保質(zhì)量保證計劃和項目計劃的一致性。經(jīng)過批準的質(zhì)量保證計劃需要納入配置管理。當(dāng)項目計劃變更時，需要及時更改和復(fù)審質(zhì)量保證計劃。11.1.2“過程和工作產(chǎn)品”的質(zhì)量檢查根據(jù)質(zhì)量保證計劃進行質(zhì)量的審計工作，并發(fā)布質(zhì)量審計報告。審計的主要內(nèi)容包括:是否按照過程要求執(zhí)行了相應(yīng)的活動，是否按照過程要求產(chǎn)生了相應(yīng)的工作產(chǎn)品。本項目中對質(zhì)量的控制主要體現(xiàn)在不同階段的審計當(dāng)中。1.1.3不符合項的跟蹤處理對審計中發(fā)現(xiàn)的不符合項，要求項目組及時處理，質(zhì)量保證人員需要確認不符合項的狀態(tài)，直到最終的不符合項狀態(tài)為“完成”為止。1.2質(zhì)量管理責(zé)任分配我公司在開發(fā)項目上按照規(guī)范化軟件的生產(chǎn)方式進行生產(chǎn)。每個項目除配備了項目開發(fā)所需角色外，還專門配備了質(zhì)量保證小組、配置管理小組、測試小組來確保質(zhì)量管理的實施，下面針對這三種角色進行說明:1.2.1質(zhì)量保證小組職責(zé)質(zhì)量保證小組作為質(zhì)量保證的實施小組，在項目開辟的過程中幾乎所有的部門都與質(zhì)量保證小組有關(guān)。質(zhì)量保證小組的主要職責(zé)是:以獨立審查方式，從第三方的角度監(jiān)控軟件開辟任務(wù)的履行，闡發(fā)項目內(nèi)存在的質(zhì)量題目，審查項目的質(zhì)量活動，給出質(zhì)量審計報告。就項目是否遵循已制訂的計劃、標準和規(guī)程，給開辟人員和管理層提供反映產(chǎn)品和過程2質(zhì)量的信息和數(shù)據(jù)，使他們能了解整個項目生存周期中工作產(chǎn)品和過程的情況，提高項目透亮度，從而支持其托付高質(zhì)量的軟件產(chǎn)品。質(zhì)量保證人員依據(jù)質(zhì)量保證計劃，通過質(zhì)量審計報告向項目經(jīng)理及有關(guān)人員提出已經(jīng)識別出的不符合項，并跟蹤不符合項的解決過程，通過審計周報或者審計月報向項目經(jīng)理提供過程和產(chǎn)品質(zhì)量數(shù)據(jù)，并與項目組協(xié)商不符合項的解決辦法。質(zhì)量保證小組的檢測范圍主要包括:項目的進度是否按照項目計劃履行，用戶需求是否得到了用戶的簽字確認，軟件需求是否正確的反映了用戶的需求，是否將每一項用戶需求都映射到軟件需求;系統(tǒng)設(shè)計是否完全反映了軟件需求;實現(xiàn)的軟件是否正確的體現(xiàn)了系統(tǒng)設(shè)計;測試人員是否進行了較為徹底的和周全的測試;客戶驗收和交接清單是否完備;對于系統(tǒng)運行中出現(xiàn)的題目，維護人員是否記實了詳細的維護記實;配置管理員是否按照配置管理計劃建立了基線，是否嚴格控制變換過程，是否對配置庫進行了維護。1.2.2配置管理小組職責(zé)配置管理活動的目的是通過履行版本控制、變換控制、基線管理等規(guī)程，借助配置管理工具的使用，來保證整個生命周期過程產(chǎn)生的所有配置項的完整性、一致性和可追溯性。配置管理是對工3作成果(階段工作成果和產(chǎn)品成果、進展狀態(tài)成果)的一種有效保護形式，是反映項目及其工作產(chǎn)品的過去、現(xiàn)在、動態(tài)的資料和數(shù)據(jù)集中管理體現(xiàn)。配置管理小組的主要職責(zé)包括:根據(jù)項目計劃制定配置管理計劃，建立配置庫，為項目組人員分配配置庫權(quán)限，創(chuàng)建需求、設(shè)計、開發(fā)、測試、交付階段的基線。當(dāng)納入基線庫的工作產(chǎn)品發(fā)生變更時，嚴格按照配置項變更控制過程執(zhí)行變更，變更后建立新的基線。1.2.3測試小組職責(zé)作為質(zhì)量控制的主要手段，如同軟件開發(fā)一樣，測試在執(zhí)行之前，測試小組制定軟件測試計劃、測試用例的編寫和執(zhí)行工作。本項目中，測試可以分為如下幾種類型:代碼走查、單元測試、集成測試、系統(tǒng)測試。為了保證程序的質(zhì)量，開發(fā)人員需要對同伴的代碼進行代碼走查，同時對自己編寫的程序進行單元測試，確保程序編譯、運行正確。測試人員根據(jù)軟件需求分析報告進行軟件集成測試用例和系統(tǒng)測試用例的編寫。對編寫完成的測試用例提交項目組進行評審，同時質(zhì)量保證人員對評審過程和工作產(chǎn)品進行監(jiān)測。測試人員根據(jù)測試計劃和測試用例執(zhí)行測試用例，并對發(fā)4現(xiàn)的缺陷進行記實，只有這樣才能確保項目組開辟的軟件產(chǎn)品滿足用戶需求。在完成集成測試之后，可以進行軟件系統(tǒng)測試，系統(tǒng)測試包括對軟件進行功能測試、性能測試、安全測試、壓力測試。只有進行了系統(tǒng)測試軟件測試才是完整的。系統(tǒng)測試在本項目中占有重要的地位，性能要求有可能改變軟件的設(shè)計，為避免造成軟件的后期返工，測試在性能上需要較大的側(cè)重。1.3質(zhì)量保證措施通過質(zhì)量管理責(zé)任的分配，通過以下幾個方面來進行質(zhì)量保證的實施過程:1.3.1項目進度項目計劃的制訂為工程項目實施、管理和支持工作、項目進度、成本、質(zhì)量及過程產(chǎn)品的有效控制打下了良好的基礎(chǔ)，以便所有相關(guān)人員能夠按照該計劃有條不紊地開展工作;制訂《項目計劃》，必須獲得相關(guān)干系人的認可，并以此作為項目跟蹤的基礎(chǔ)。項目進度是項目進行是否順利的最直觀表現(xiàn)。制訂合理的項目計劃首要前提是選擇從事類似規(guī)模和類似業(yè)務(wù)項目的有經(jīng)驗的項目負責(zé)人參加制訂項目進度計劃。項目計劃由項目負責(zé)人制定，由項目各小組組長、項目成員、干系人、質(zhì)量保證人員參加一起進行評審。評審過程主要討論項目計劃的可行性，對其中不合理的地方提出修改意5見，對計劃中不合理的地方進行修改完善，并由質(zhì)量保證人員對其結(jié)果進行跟蹤處理，以確保項目計劃完整性、可行性，項目計劃評審?fù)ㄟ^后，交由配置管理人員進行配置管理。在計劃實施過程中，按項目計劃中里程碑為界限，將整個開發(fā)周期劃分為若干階段。根據(jù)里程碑的完成情況，適當(dāng)?shù)恼{(diào)整每一個較小的階段的任務(wù)量和完成的任務(wù)時間，動態(tài)跟蹤和動態(tài)調(diào)整，以利于項目質(zhì)量保證的實施。實際運作中，質(zhì)量保證人員在對項目執(zhí)行過程進行檢查時，對于發(fā)現(xiàn)的項目偏差，以質(zhì)量審計報告的形式提交項目負責(zé)人。由項目負責(zé)人組織人員對計劃進行維護，對于已經(jīng)變動的項目計劃，由配置管理進行配置管理。1.3.2需求分析需求分析是開發(fā)人員對系統(tǒng)需要做什么和如何做的定義過程。從系統(tǒng)分析的經(jīng)驗來看，這個過程往往是個循序漸進的過程，一次性對系統(tǒng)形成完整的認識是困難的。只有不斷地和客戶領(lǐng)域?qū)＜疫M行交流確認，方能逐步明了用戶的需求。從系統(tǒng)開發(fā)的過程得知，系統(tǒng)分析時犯下的錯誤，會在接下來的階段被成倍的放大，越是在開發(fā)的后期，糾正分析時犯下的錯誤所花費的代價越是昂貴，也越發(fā)影響系統(tǒng)的工期和系統(tǒng)的質(zhì)量。本項目中，將邀請招標方技術(shù)負責(zé)人參與需求調(diào)研，以便保證需求調(diào)研質(zhì)量，同時形成用戶需求說明書。需求評審時6會同單方管理層、項目實施層配合進行，對于通過用戶確認的需求，交由配置管理員形成需求基線。用戶需求在招標方確認后，由系統(tǒng)闡發(fā)人員形成軟件需求闡發(fā)報告，同時對軟件需求闡發(fā)報告進行評審，對于評審?fù)ㄟ^的軟件需求闡發(fā)報告可以交由測試人員進行測試計劃和測試用例的編寫。對于開辟過程存在的需求變動，招標方填寫變換申請單發(fā)給項目經(jīng)理，在質(zhì)量保證人員參加的情況下，對這個變換進行評審，由項目經(jīng)理組織項目組成員一起討論實施變換的可行性及實施后所帶來的影響，對于影響小的變換直接記實，大的變換則需要形成正式的變換報告，不管那種變換都需要對相應(yīng)的文檔實施同步變換(包括需求闡發(fā)報告、系統(tǒng)設(shè)計、安裝手冊、操作手冊等)。但是對于沒法實現(xiàn)或是變換會帶來宏大的影響而將導(dǎo)致進度的延期，這時，我們將變換報告提交給招標方并召開協(xié)調(diào)會議，討論變換取舍題目或是項目進度變換題目。決定變換之后，由項目負責(zé)人組織實施變換，測試人員檢測變換結(jié)果，而質(zhì)量保證人員監(jiān)督變換實施過程，并協(xié)助配置管理員對變換后的成果進行配置管理。變換實施完后，運行前還需要協(xié)助用戶一同測試并由招標方簽字后贊成方可上線。1.3.3系統(tǒng)設(shè)計7優(yōu)良的體系結(jié)構(gòu)該當(dāng)具備可擴大性和可配置性，而好的體系結(jié)構(gòu)則需要好的設(shè)計方法，需要針對項目的結(jié)構(gòu)、項目的特征和用戶的需求來闡發(fā)。本項目中將安排我公司高級系統(tǒng)架構(gòu)師擔(dān)當(dāng)項目總體設(shè)計師，匯同總體設(shè)計組完成系統(tǒng)設(shè)計。另外對公共類模塊的開發(fā)。由總體設(shè)計組通過對用戶需求的仔細研究，盡可能的識別出公共類，并進行定義和設(shè)計，以減少重復(fù)工作。對于項目組提供的設(shè)計文檔，由項目經(jīng)理組織，質(zhì)保小組成員參與，對其設(shè)計文檔進行評審，及時發(fā)現(xiàn)設(shè)計中可能存在的錯誤，降低項目開發(fā)風(fēng)險，同時確保設(shè)計文檔能為開發(fā)人員、XXX:軟件產(chǎn)品質(zhì)量控制方法表1軟件產(chǎn)品質(zhì)量控制方法XXX:軟件項目質(zhì)量保證的策略與實踐軟件項目質(zhì)量保證的策略與理論摘要:對軟件項目實施全過程的質(zhì)量管理作了詳細論述:在需求分析階段通過結(jié)對分析與需求評審來保證需求分析的質(zhì)量;在設(shè)計與開發(fā)階段，制訂相應(yīng)的軟件開發(fā)規(guī)范，并嚴格執(zhí)行，保證實現(xiàn)代碼的質(zhì)量;在測試環(huán)節(jié)上，強調(diào)測試與軟件實現(xiàn)同步，強化Bug管理。以進一步提高軟件質(zhì)量。軟件開發(fā)全程要做到“有法可依，有法必依”。以上措施是開發(fā)出高質(zhì)量軟件系統(tǒng)的重要保證。8關(guān)鍵詞:質(zhì)量保證;結(jié)對闡發(fā);軟件項目;需求闡發(fā)XXX2008年，對某絨毛有限公司的生產(chǎn)控制系統(tǒng)組織了開辟與實施。在項目團隊中，本人承擔(dān)了系統(tǒng)闡發(fā)與技術(shù)總監(jiān)的職責(zé)。本系統(tǒng)的主要任務(wù)是實現(xiàn)從商務(wù)部接單、生控辦配料、倉庫備料、車間生產(chǎn)，到倉庫入倉、最后出倉托付給客戶的業(yè)務(wù)工作流，并建立商務(wù)部管理系統(tǒng)、倉庫管理系統(tǒng)。生產(chǎn)控制系統(tǒng)對質(zhì)量要求較高，自托付運行以來，用戶反饋表明，質(zhì)量特性上較好地滿足了生產(chǎn)需要。在軟件開辟過程中，我們實行了全過程的質(zhì)量管理，圍繞軟件的6個質(zhì)量特性因子，形成了軟件項目開辟團隊的束縛文件，針對不同角色制訂了不同的質(zhì)量主題，做到了軟件質(zhì)量的可控。1需求分析階段，通過結(jié)對分析與需求評審來保證需求分析的質(zhì)量需求分析的質(zhì)量是否優(yōu)良，決定著后繼各工作環(huán)節(jié)能否按既定方向進行。由于客戶方生產(chǎn)較為繁忙，計算機應(yīng)用水平不高等因素，與中層管理人員、基層操作人員的交流有很大困難，參與項目的時間與精力得不到保障，因此，作者制訂了結(jié)對分析的策略，以提高需求分析的效率與質(zhì)量。結(jié)對是敏捷軟件開發(fā)一個最佳編程實踐，作者創(chuàng)造性地將其引入到需求分析階段。需求分析各個環(huán)節(jié)(包括需求獲取、分析，與用戶溝通)均由兩個開發(fā)人員來共同完成，能取得較高的需求分析質(zhì)量。例如，這一策略在倉庫備料及庫存管理9這一關(guān)鍵環(huán)節(jié)的需求闡發(fā)上發(fā)揮了重要作用。倉庫管理人員年紀較長，對計算機概念恍惚，溝通上存在很大障礙，通過兩個需求闡發(fā)人員配合來完成該項工作，做到了闡發(fā)人員的優(yōu)勢互補。通過結(jié)對闡發(fā)不僅得到較高的需求闡發(fā)質(zhì)量，并且節(jié)省了用戶的工夫，對用戶也有一定的推動。只有兩個闡發(fā)人員達成一致，才將相應(yīng)需求嵌入基線庫中，保證了需求的科學(xué)性。這樣做雖然增加了人力成本，但提高了需求闡發(fā)效力。強化需求評審。需求評審分為三個層次:?全局評審。參與人員主要是用戶方中心管理層，業(yè)務(wù)領(lǐng)域?qū)＜?，開辟方闡發(fā)人員。主要任務(wù)是評審需求與公司方針、高層想法是否一致。這一評審至關(guān)重要，它把握了軟件系統(tǒng)實施方向的正確性。?局部評審。參與人員主要是用戶方業(yè)務(wù)中層及一線操作人員，開辟方業(yè)務(wù)領(lǐng)域開辟工程師。主要任務(wù)是就業(yè)務(wù)層相關(guān)業(yè)務(wù)流程進行再次確認。因為需求過程中相應(yīng)部門的業(yè)務(wù)人員站在自己的角度看待題目，對于整個流程關(guān)心不夠，需要糾正各部門用戶需求不一致的題目。?內(nèi)部評審。全體開辟人員、闡發(fā)人員參與。闡發(fā)人員建立初步的UML用例圖，工作流程圖，活動圖等供全體討論。任務(wù)是澄清一部分恍惚的需求。在需求階段，還采取了其它措施來保證需求分析的質(zhì)量，如強調(diào)需求分析工具的使用等。2設(shè)計、編碼階段，強調(diào)紀10律與規(guī)范編碼人員分成二類角色:業(yè)務(wù)領(lǐng)域工程師和中心代碼工程師。業(yè)務(wù)領(lǐng)域工程師針對具體的業(yè)務(wù)功能進行編碼。在設(shè)計時我們要求業(yè)務(wù)領(lǐng)域工程師要有這樣的意識:變換不可避免，在設(shè)計盡可能考慮到未來變換的可能性，盡可能做到模塊之間的松耦合，模塊內(nèi)部的高內(nèi)聚。中心代碼工程師完成大眾代碼的實現(xiàn)與維護。中心代碼質(zhì)量在系統(tǒng)中至關(guān)重要。對中心代碼工程師加以分組，每組兩位工程師實行結(jié)對編程。以克服思維局限，配合完成設(shè)計、UML圖、實現(xiàn)，保11證代碼質(zhì)量。實踐證明，采取這些辦法后，在用戶提出相應(yīng)功能變更時，軟件修改相對較輕松，能較好地適應(yīng)業(yè)務(wù)變化。3強調(diào)測試與軟件實現(xiàn)同步，強化Bug管理測試是保證軟件質(zhì)量較為重要的一個環(huán)節(jié)。針對開辟團隊部分成員測試意識不強，項目部有針對性地進行培訓(xùn);強調(diào)測試與設(shè)計同步，測試用例與功能代碼的體例同步;實時進行單位測試，統(tǒng)一用VS2005forTester作為測試工具;Bug管理統(tǒng)一存放在服務(wù)器中，嚴格控制Bug的開啟與關(guān)閉，并把Bug數(shù)據(jù)作為工程師查核依據(jù)之一，指派兼職文員進行Bug管理。所有測試中出現(xiàn)的題目，經(jīng)整理后在項目團隊例會上進行總結(jié);在團隊內(nèi)部交流并在平臺WSS中建立一個專門的警示網(wǎng)站，發(fā)布已經(jīng)暴露的Bug解決方案，讓項目團隊共享，避免題目重復(fù)出現(xiàn);構(gòu)建項