質量保障措施(軟硬件項目兩篇案例)_第1頁
質量保障措施(軟硬件項目兩篇案例)_第2頁
質量保障措施(軟硬件項目兩篇案例)_第3頁
質量保障措施(軟硬件項目兩篇案例)_第4頁
質量保障措施(軟硬件項目兩篇案例)_第5頁
已閱讀5頁,還剩16頁未讀 繼續(xù)免費閱讀

下載本文檔

版權說明:本文檔由用戶提供并上傳,收益歸屬內容提供方,若內容存在侵權,請進行舉報或認領

文檔簡介

例一:量保障措施硬件設篇)本產品質量保證說明作為我公司對該項目實施過程涉及的產品質量保證的證明。我方承諾提供以下質量保證并承擔相應的法律責任:1、提供的設備是全新的、符合國家相關技術標準或行業(yè)標準、國內相關部門手續(xù)完備,具有制造商質量保證書(或合格證明)的設備;2、提供的設備符合投標文件承諾和所簽合同規(guī)定的技術要求;3、每件設備和器材配件齊全、包裝完整、完好未拆封;4、每個包裝箱內的裝箱清單、使用說明書、質量證書、保修書等相關的所有資料均齊全;5、我方提供貨物的參數(shù)、規(guī)格、型號滿足此項目招標文件與貴方的需求,且經貴方認可后方可安裝調試;6保證嚴格按照國家相關規(guī)范進行安裝和調試并保證所有投標產品質量符合國家相關法律、法規(guī)和規(guī)定的要求,保質期按國家相關規(guī)定執(zhí)行。7、若中標,國產產品提供產品合格證和國家質檢標志,同時提交國家相關部門的質量檢測報告書;所有進口部件、材料必須符合我國相關產業(yè)界產品標準,并提供相關報關證明。8、所有設備和配件均是經過實際運行驗證、性能穩(wěn)定的全新產品,且設備上具有原制造廠商的銘牌、標志。9、所有設備和配件均是經過實際運行驗證、性能穩(wěn)定的全新產品,且設備上具有原制造廠商的銘牌、標志。10標人在招標及中標后生侵犯專利權的行為時侵權責任與采購人無關,應由投標人承擔相應的責任,并不得影響采購人的利益。硬件質量保障機制1)成立項目質量領導小組:設質量檢查組,配專職質檢員,制定質量管理措施,落實質量監(jiān)督檢查制度。2)發(fā)貨告之:貨到前3日內以函電方式告知需方及項目管理人,做好收貨準備。設備的外觀、包裝、運輸均按國家或國際通用規(guī)定或部頒標準執(zhí)行。3)施工:施工期間公司認真執(zhí)行安裝規(guī)范,安全生產,尊重并服從建設單位的指導。推行以質量為中心的技術質量經濟承包責任制。

4)項目管理體系:堅持以質量等級計價核取發(fā)工資獎金,實行優(yōu)質優(yōu)酬,獎優(yōu)罰劣,全面促進和提高工程施工質量,做到合格100%。狠抓施工現(xiàn)場管理,各員工均需持證上崗,做到管理有序,文明施工,積極開展多種形式的質量檢查評定、競賽活動,實行定崗、定人、定責制度,把質量工作抓到實處。5)貨物設備符合國家技術規(guī)范和質量標準的合格產品,滿足需方的使用需求,并具有可靠的售后服務體系,質量可靠、使用安全。6)我方提供的所有設備都具有質量保證書、合格證書。7)保證提供的產品是全新的、未使用過的。保證其產品在正確安裝、正常操作情況下,運行安全、可靠。8)保證采購合同項下所供貨物是原生產制造廠商制造的過合法銷售渠道取得的、全新的、未使用過的,并符合國家技術質量規(guī)范和政府采購合同規(guī)定的質量、規(guī)格、性能和技術規(guī)范等要求。9)保證所提供的貨物在正確安裝、正常使用和保養(yǎng)條件下,在其使用壽命期限內具有符合質量要求和產品說明書的性能。質保期內對其交付的貨物由于設計、工藝或材料的缺陷而產生的故障負責。產品進安裝及調試我方提供全新的設備所有設備均由我方送貨到指定地點并安裝調試貴方不再支付任何費用。在項目終驗前,所有硬件設備損壞,由我方負責。我方所提供設備到達目的地后貴方按我方提供的設備清單及檢驗產品合格證用說明書和其他的技術資料負責開箱檢驗、檢查設備及隨機附件是否完整無損,技術資料是否與貴方的要求相符,如有損壞、缺件等情況,我方在日內更換新產品,相應的費用及責任由我方自行負擔。我方應提供設備所帶專用工具清單并標明其種類用途和生產廠并在貨物到貨時同時提供給貴方。由我方提供調試專用工具,直到項目質保期滿。我方提供產品安裝的詳細實施建議方案和產品安裝實施過程的工作內容、工作日程表、工作方法,并征得貴方認可后嚴格按照日程表執(zhí)行。日程表內容至少包括到貨日期、現(xiàn)場安裝、系統(tǒng)測試、系統(tǒng)聯(lián)調、系統(tǒng)試運行、驗收、技術培訓等。我方允許貴方的工作人員參與項目的安裝測試診斷及解決問題等各項工作并

提供相關的現(xiàn)場培訓。安裝聯(lián)調過程中我方供給貴方的產品及自己使用的工具進入貴方使用現(xiàn)場后的保管由我方負責;我方在貴方使用現(xiàn)場安裝人員的安全、保險、食宿、交通由我方負責。貴方將確認下列條款后進行驗收簽字:(1)投標文件中提供的產品技術數(shù)據(jù)經核驗證實是真實的;(2)在調試期內所暴露的問題已獲得令采購人滿意的解決;(3)所要求的資料、備件等已按規(guī)定數(shù)量移交完畢;(4)防雷接地需提供第三方檢測報告。

例二:量保障措施軟件開篇)軟件質量保證過程作為一種獨立的審查活動貫穿于整個軟件開發(fā)過程。質量控制人員類似于軟件開發(fā)過程中的過程警察其主要職責:檢查開發(fā)和管理活動是否與制定的過程策略、標準和流程一致;檢查工作產品是否遵循模板規(guī)定的內容和格式。此文檔從軟件開發(fā)過程的各個階段來描述軟件質量保證過程。計劃階段目的和圍:項目計劃過程的目的是計劃并執(zhí)行一系列必要的活動,以便在不超出項目預算和日程安排的前提下,將優(yōu)質的產品交付給客戶。進入標:項目啟動會議已經結束;在項目的生命周期中,根據(jù)項目的跟蹤結果,需要對項目計劃進行修改和完善。輸入:?目啟動報告;?目提案書;?目相關文檔;?織財富庫中以往類似的經驗文檔。退出標:?項目計劃已通過評審、批準并確立。輸出:?評審后的項目計劃文檔括:?軟件開發(fā)質量計劃;?軟件配置管理計劃。過程描:項目計劃包含3個需要在項目中執(zhí)行和管理的主要計劃,如下:?軟件項目管理計劃;?軟件項目質量管理計劃?軟件配置管理計劃。軟件項目管理計劃涉及項目中所有與項目管理相關的問題(從項目開始到結束

軟件項目質量管理計劃涉及與質量相關的需求,這些需要在產品中實現(xiàn),并保證用于構筑產品的項目過程。由于質量是產品創(chuàng)建的一部分,所以將軟件項目管理計劃和軟件項目質量管理計劃合成一個計劃文檔,稱為軟件開發(fā)質量計劃。軟件配置管理計劃用于管理與配置管理相關的需求,這些需求與工作產品和可交付產品有關。該計劃的目的在于:為執(zhí)行軟件工程相關活動提供依據(jù),并在整個開發(fā)和維護過程中對軟件項目進行管理??梢允褂貌煌臋z查表來制定軟件開發(fā)質量計劃和軟件配置管理計劃。如下每個計劃都將包含以下3點:?目標;?執(zhí)行方法;?當前狀態(tài)。前兩點不會經常變更,但第三點則被認為會在執(zhí)行跟蹤時被修改。因此,前兩點通常被直接放到計劃中,而第三點則以鏈接的方法放到計劃中。(1)制訂軟件開發(fā)質量計劃軟件開發(fā)質量計劃包括軟件項目管理計劃、軟件項目質量管理計劃。①制訂軟件項目管理計劃軟件項目管理計劃的主要內容包括基礎設施計劃,進度計劃(包括各種類型的估算風險管理計劃、項目培訓計劃、執(zhí)行計劃、客戶管理計劃?;A設施計劃基礎設施計劃包括項目開始執(zhí)行前必須到位的所有需求,它需要解決以下問題:軟件工程需求、基礎設施需求、角色和職責、內外部接口、過程需求、知識和技能需求。進度計劃進度計劃涉及制定合理可用的項目進度。在制定項目進度時,需要進行下面的估算:規(guī)模(Size工作量(effort項目進度需要描述以下內容:執(zhí)行的活動、估算的人時、投入的人員、責任人和時間線、里程碑事件的標識。

風險管理計劃風險管理包括:標識風險事件(與管理相關的風險、與執(zhí)行相關的風險,與客戶相關的風險等風險并設定風險優(yōu)先級訂風險緩解和應急計劃并跟蹤該計劃。項目培訓計劃根據(jù)項目及人員結構制訂項目培訓計劃,包括業(yè)務領域知識、技術、工具等方面的培訓計劃。執(zhí)行計劃項目執(zhí)行計劃包含了與執(zhí)行當前項目關系最大的生命周期模型。該計劃對組織級執(zhí)行模型進行了裁剪。項目生命周期模型通常包括:項目執(zhí)行的階段、各階段的輸入和輸出、可交付的產品、需要迭代(反復)的階段。②制訂軟件項目質量管理計劃制訂軟件項目質量管理計劃包含如下主要內容:項目設定的質量標準;同級評審計劃同級評審計劃中描述了在不同的軟件生命周期開發(fā)階段不同的工作產品所采用的同級評審類型;測試計劃:測試計劃包括對可執(zhí)行文件塊或整個系統(tǒng)將要進行的各種測試。根據(jù)項目測試過程來制定測試計劃;度量管理計劃:通過裁剪組織級的度量過程來制定項目度量管理計劃。缺陷預防計劃:管理、開發(fā)和測試人員互相配合制訂缺陷預防計劃,防止已識別的缺陷再次發(fā)生;過程改進計劃:項目級過程改進的機會要記錄到過程改進計劃中。這些機會主要來源于度量分析、缺陷預防分析和標識出的好的或可避免的實踐。(2)制訂軟件配置管理計劃軟件配置管理計劃主要包括以下內容:軟件配置管理計劃組織;角色和職責;開發(fā)/護配置管理計劃括可配置項的標識命名約定目錄結構訪問控制、變更管理、基線庫創(chuàng)建、放入/取(Checkin/Checkout)機制、版本控制;產品配置管理包括產品中部件的可跟蹤性產品的版本設定和發(fā)布交付的配置

管理(標識出要交付的產品構成求配置管理(需求基線的確定、產品版本與劃定基線的需求版本之間的關系置審計。驗證:同級評審人員和軟件質量保證人員必須對項目計劃進行評審,批準后項目才能付諸實施。配置控:項目經理保管所有項目計劃文檔。對所有項目計劃文檔都要進行配置管理。項目結束后,所有的項目計劃文檔都要保存到組織財富庫中,仍受配置控制。?檢查清單:?檢查清單包括:?軟件開發(fā)質量計劃;?軟件配置管理計劃。?該階段要確保制定了軟開發(fā)質量計劃和軟件配置管理計劃。需求分階段目的和圍:需求說明和需求管理過程的目的是為了保證開發(fā)組在開發(fā)期間對項目目標和生產出最后產品的目的有一個清晰的理解。軟件需求規(guī)格說明書將作為產品測試和驗證是否適合需要的基礎。對于需求的變更,它可能在開發(fā)項目期間的任何時間點發(fā)生,需求的變更將要影響日程和承諾的變化,這些變化需要和客戶所提出的要求相一致。進入標:?計劃已經被批準,并且目整體的基礎設施是可用的;?軟件的需求已經被需求集小組捕獲;?對已經形成了基線的軟需求規(guī)格說明書有變更的請求時。輸入:?軟件的需求說明書;?變更需求的請求。?退出標準:?軟件需求規(guī)格說明書已經過評審并形成了基線;?對已經形成基線的軟件求的變更進行了處理;

?形成基線的軟件說明書經經過客戶批準;?驗收標準已經完成;?所有評審的問題都已經決。輸出:?經過批準并形成基線的件需求規(guī)格說明書;?對受影響組件的重新估文檔;?驗收測試標準和測試計。過程描:這個過程主要處理以下兩種活動:需求說明和需求管理。需求說明指的是需求過程中形成基線的主體,它是以后進一步的設計和測試的基礎。另外,在軟件開發(fā)過程中,會經常遇到由于客戶又有新需求或開發(fā)組自身對項目有了更清楚的理解或認識,要對需求進行變更。在對最初的需求說明書進行變更時,要用到需求管理過程。()需求說明需求說明過程主要包括以下任務:?執(zhí)行需求分析?定義需求規(guī)格說明書?定義驗收標準?評審說明書和驗收標準①執(zhí)行需求分析分析收集到的需求和在提案中可用的需求。這個任務要求需求說明書應該在完整性、一致性、清晰性和可測試性上達到比較合理的程序。②定義需求說明書基于對需求的分析編寫軟件需求規(guī)格說明書。這個文檔應清晰記錄以下內容:?目標和范圍;?功能需求;?用戶接口;?輸入輸出;?模塊之間的接口;

?性能需求;?特殊用戶需求。如果需求不清晰或模糊,就需要準備原型,通過評估原型來產生需求說明書。③定義驗收標準基于對以前步驟收集的需求規(guī)格說明書,建立測試標準,驗證的解決方案。所有的需求應該可制定測試標準。這個測試標準將成為客戶批準最終產品的依據(jù),因此要求在制定客戶標準時要經常緊密的與客戶進行交流溝通。④評審需求分析說明書和測試標準因為是開發(fā)項目的基礎,所以需求規(guī)格說明書和驗收標準需要由項目組的同級人員進行評審。(2)需求管理需求管理過程包括以下6個任務:?錄變更請求;?析受到影響的組件;?算需求變更成本;?新估算所有產品的交付日期和時間;?審受影響組件;?得客戶的批準。①記錄變更請求;形成基線的需求說明書的變更可能是由客戶提出的,也可能是由于設計或編碼階段開發(fā)人員根據(jù)一些限制或優(yōu)化而提出的。所有需求變更必須經過客戶的批準,并且必須是可行的。任務需求變更可以由組織自己定義開始時間,并且所有需求變更需要記錄到變更登記表中。②分析受到影響的組件;任何經過批準的變更需要在整個項目組范圍內進行受影響組件分析。③估算需求變更成本;項目成本與需求變更有關。任何規(guī)模的變更對于成本來講都是一種損耗。如果一個受影響組件是非常重要的,那么可行性需要重新進行成本估算。④重新估算所有產品的交付日期和時間;

如果沒有考慮有效的緩沖,成本的變化可能會影響整個項目的交付時間。在交付時間內的任何實質的變更都需要再同用戶商議決定。⑤評審受影響組件;在這個步驟中所有相關的受影響組件需要進行評審目負責人根執(zhí)行此項任務。⑥獲得客戶的批準。這個過程的最后一項任務是獲得客戶的簽字。客戶應該同意已經形成基線的軟件需求說明書、驗收標準和已記錄的受影響組件的變更。驗證:?目經理要定期的檢查需求規(guī)格說明書和項目需求管理的各個方面;?件質量保證人員要定期的對需求分析過程執(zhí)行獨立的評估。配置控:?件需求規(guī)格說明書需要嚴格的配置控制;?有的變更請求需要被管理和控制;?于跟蹤的度量文檔需要管理和控制。QA檢查清單質量保證檢查清單包括:?軟件需求規(guī)格說明書;?變更需求跟蹤記錄;?驗收測試標準與測試計。該階段要確??蛻籼岢龅男枨笫强尚械?,確??蛻袅私庾约禾岢龅男枨蟮暮x,并且這個需求能夠真正達到他們的目標,確保開發(fā)人員和客戶對于需求沒有誤解或誤會,確保按照需求實現(xiàn)的軟件系統(tǒng)能夠滿足客戶提出的需求。編碼階段目的和圍:編碼過程的目的是為了實現(xiàn)詳細設計中各個模塊的功能,能夠使用戶要求的實際業(yè)務流程通過代碼的方式被計算機識別并轉化為計算機程序。編碼過程就是用具體的數(shù)據(jù)結構來定義對象的屬性,用具體的語言來實現(xiàn)業(yè)務流程所表示的算法。在對象設計階段形成的對象類和關系最后被轉換成特定的程序設計語言、數(shù)據(jù)庫或者硬件的實現(xiàn)。

進入標:?計文檔已經形成基線;?細設計變更編寫完畢并通過評審,并且代碼需要變更時;?于維護項目,維護需求分析已經形成基線,可進行代碼的變更;?于編碼的測試標準已經制定。輸入:?細設計文檔;?定項目的編碼規(guī)范;?關的軟、硬件環(huán)境;?護分析文檔;?試計劃。退出標:?詳細設計中所有模塊的能全部被實現(xiàn),并通過自我代碼審查,編譯通過。輸出:?完成的、需要進行測試的代碼;?碼編寫規(guī)范的更改建議。過程描:編碼過程是把詳細設計中的各個模塊功能轉化為計算機可識別代碼的過程,因此程序員在進行編碼時,一定要仔細認真,切勿有半點疏忽。編碼過程通常情況下占整個項目開發(fā)時間的右,為了代碼達到高質量、高標準,代碼編寫過程一定要合理規(guī)范。編碼過程主要包括以下幾項活動:?制定編碼計劃;?認真閱讀開發(fā)規(guī)范;?編碼準備;?專家指導,并填寫疑問問題表;?理解詳細設計書;?編寫代碼;?自我審查;?提交代碼;

更改代碼。編碼過程流程如下圖所示。(1)制定編碼計劃在編碼之前一周,項目經理要根據(jù)詳細設計中的模塊劃分情況制定編碼計劃。編碼計劃的主要內容如下。①本次編碼的目的在制定編碼計劃時,必須要明確編碼目的。②編碼人員組成在編碼之前,要確定本次編碼的人員組成:選擇編碼人員時要考慮以下幾點:責任心、技術能力、服從意識、努力程序、編碼效率、編碼質量。③編碼任務分配在編碼之前,一定要為每個編碼人員劃分好自己所負責的模塊,并且要規(guī)定各個模塊的編碼開始,結束日期。(2)認真閱讀開發(fā)規(guī)范為了實現(xiàn)編碼的規(guī)范統(tǒng)一,需要制定編碼規(guī)范。有的項目,客戶也會提供一些開

發(fā)規(guī)范用來對本次編碼進行約束。編碼人員在編寫代碼之前一定要理解并掌握相關編碼規(guī)范的所有內容。這樣有助于以后編碼工作的規(guī)范統(tǒng)一。如果本次編碼采用的是公司自己的開發(fā)規(guī)范,編碼人員在閱讀的過程中,如果發(fā)現(xiàn)編碼規(guī)范有不足或不合理之處,可以編寫開發(fā)規(guī)范建議書提交給項目經理,項目經理再和軟件質量保證人員取得聯(lián)系以決定是否要對目前的編碼規(guī)范進行更改。(3)編碼準備在進行編碼之前還要進行一些相關的準備。①軟硬件環(huán)境配置:包括編碼工具、配置管理工具、數(shù)據(jù)庫和一些必要的輔助工具。②了解程序設計語言的特性,選擇良好的程序設計風格:程序設計風格是程序設計質量的一個重要方面,具有好的設計風格的程序更容易閱讀和理解。(4)理解詳細設計書由于項目模塊功能的復雜性,即使再詳細的設計也會有表達不夠準確之處,因此在編寫代碼之前,一定要把每個模塊的詳細設計思路弄清楚。如果編碼人員在理解詳細設計時有疑惑,一定要詢問詳細設計人員。為了保證編碼人員對詳細設計的理解的正確性,采用以下方法:①詳細設計同級評審時,讓編碼人員參加;②讓編碼人員對詳細設計進行講解;③讓編碼人員根據(jù)自己的理解畫出流程圖,由詳細設計者確認。如果編碼人員在理解詳細設計書的過程中存在疑問,應填寫詳細設計疑問列表提交給項目經理或詳細設計人員。(5)專家指導在編碼之前或編碼過程中,為了保證編碼工作的順利進行以及代碼質量,項目經理要根據(jù)目前編碼人員的技術能力或開發(fā)進度情況邀請本項目組內部或外部專家對編碼人員進行指導。指導的內容主要包括以下兩方面的內容。①對于本次編碼有關的業(yè)務進行指導:對編碼人員進行業(yè)務上的指導,有助于編碼人員對詳細設計的理解。②對技術進行指導:通過對編碼人員的技術指導,可以解答編碼人員在技術上的一些疑問。

(6)編寫代碼在很多的軟件開發(fā)中,客戶為了便于程序的可維護性,往往會對程序代碼編寫過程做出一些規(guī)定,如變量的命名規(guī)則、書寫規(guī)范和公共處理等,所以這就要求編碼人員要熟悉這些要求和規(guī)范,并嚴格的遵守這些規(guī)范,如果客戶沒有規(guī)定,就要按照公司的規(guī)定執(zhí)行。①畫出程序的流程圖程序的流程圖又稱程序框圖,用來描述軟件設計,是歷史最長、使用最廣泛的方法。在編碼之前,一定要先畫好程序的流程圖,這對一個復雜的程序來說是非常必要的,這樣做了以后,可以使你在編碼階段達到事半功倍的效果,而且對于代碼的正確性和質量都是一個很好的保證。②代碼的模塊化模塊化是把系統(tǒng)分割成能完成獨立功能的模塊代碼,明確規(guī)定各個模塊代碼及其輸入輸出規(guī)格,使模塊代碼的接口不會產生混亂。③程序的注解程序的注解對于程序的閱讀與理解起著重要的作用。注解主要分兩部分:?程序塊頭的注解要是模塊功能的說明入輸出變量的說明的說明、程序員姓名和程序完成以及變更的日期列表。這些主要是滿足管理者的需要,管理者易于掌握哪些程序是由哪個編碼人員負責的。?程序內部的注解對程序中的一些難以理解的語句以上注釋以使閱讀者容易理解設計者的意圖,易于理解程序。這樣的程序具有很強的可讀性和可維護性。④數(shù)據(jù)類型/變量說明數(shù)據(jù)說明的次序應標準化,如按數(shù)據(jù)類型或者數(shù)據(jù)結構來確定數(shù)據(jù)說明的次序,次序的規(guī)則在數(shù)據(jù)字典中加以說明,以便在測試調試階段和維護階段可以方便的查找數(shù)據(jù)說明的情況;當對在同一個語句中的多個變量加以說明時,應按英文字母的順序排列;在使用一個復雜的數(shù)據(jù)結構時,最好加注釋語句;變量說明不要遺漏,變量的類型、長度、存儲及其初始化要正確。⑤語句構造

不要為了節(jié)省空間把多個語句寫在同一行;盡量避免復雜的條件;對于多分支語句,應該把出現(xiàn)可能性大的情況放在前面,把較少出現(xiàn)的分支放在后面,這樣可以加快運算時間;避免大量使用循環(huán)嵌套語句和條件嵌套語句;利用括號使邏輯表達式或算術表達式的運算次序清晰直觀;每個循環(huán)要有終止條件,不要出現(xiàn)死循環(huán),也要避免不可能被執(zhí)行的循環(huán)。⑥程序效率程序效率主要指處理工作時間和內存容量這兩方面的利用率,在程序滿足了正確性、可理解性、可測試性和可維護性的基礎上,提高程序的效率也是非常必要的。在編碼過程中,一定要嚴格按照規(guī)定的開發(fā)規(guī)范進行編碼,如果沒有按照編碼規(guī)范進行編碼,再好的程序代碼也不能被接受。另外,在編寫代碼時,如果認為開發(fā)規(guī)范有不合理或有待補充之處,應該填寫開發(fā)規(guī)范建議書提交給項目經理;如果發(fā)現(xiàn)詳細設計中有問題或對詳細設計產生疑問,應該填寫詳細設計疑問列表并提交給項目經理。(7)代碼審查在編碼過程中,每個模塊或程序的自我審查的關鍵環(huán)節(jié)是絕對不能缺少的。無論多么好的編碼人員編寫的代碼,都會或多或少的存在缺陷,從而影響程序的運行。有的缺陷可以在很短的時間內暴露出來;有的缺陷需要很長的時間才能顯現(xiàn)出來。因此在代碼審查過程中,一定要仔細認真,不要遺漏某個條件。編碼人員切勿對自己編寫的代碼過于自信而不去自我審查。在進行代碼審查過程中,并不是盲目地進行審查。而是要按照代碼審查列表中的內容進行審查。審查之后還要把自己審查的內容以及發(fā)現(xiàn)的問題記錄到代碼審查記錄中。代碼審查記錄不作為考核個人的依據(jù)。通過代碼審查記錄,管理人員可以掌握每個編碼人員的代碼審查工作情況以及自我審查的質量效率。如果是比較重要的代碼(如重要的算法、復雜SQL序段、要求性能比較高的模塊等可以讓經驗豐富的設計人員或編碼人員來復查或進行同級評審。(8)代碼測試為了進一步保證代碼的正確性和合理性,編碼人員還要對自己編寫的代碼進行測

試。代碼測試的依據(jù)是詳細設計過程中的單元測試計劃書。編碼人員按照測試計劃書中所提供的每個測試項目的測試用例進行測試。本次測試只是編碼人員對自己所編寫的代碼進行自我測試,測試主要采用白盒與黑盒結合的方法。在代碼測試過程中,應該填寫代碼測試記錄。(9)提交測試編碼人員對自己編寫的代碼審查完畢,并認為代碼不會有任何問題,就可以把代碼提交給相應的測試人員提交代碼時一定要注意自己所提交的代碼是最新的版本。(10)更改代碼更改代碼的情況可以分為兩種:①在測試中發(fā)現(xiàn)代碼有誤或者邏輯不合理出現(xiàn)這種情況的主要原因可能有兩種:一是編碼人員本身的錯誤而造成的缺陷;二是在需求、設計階段的錯誤沒有被查出,被帶到編碼階段而造成的缺陷。②由于需求和設計的變更引起的代碼變更。在變更代碼的過程中一定要注意對代碼的版本管理。驗證:?證編碼的規(guī)范性;?證是否進行了自我審查;?證代碼的一致性和可跟蹤性;?過測試驗證代碼的正確、合理性;?證每個編碼人員的工作能力。配置控:?過相應的配置管理工具對不同版本的代碼進行管理;?編碼規(guī)范進行管理;?項目開發(fā)質量計劃進行管理。QA檢查清單?碼計劃;?發(fā)規(guī)范建議書;?細設計疑問列表;?碼審查檢查列表;

?碼審查記錄;?碼測試記錄。該階段要確保建立了編碼規(guī)范、文檔格式標準,并且按照該標準進行編碼;確保代碼被正確地測試和集成,代碼的修改符合變更控制和版本控制流程;確保按照進度計劃編寫代碼;確保按照進度計劃進行代碼評審。測試階段目的和圍:軟件測試過程的目的是為了保證軟件產品的正確性、完整性和一致性,保證提供實現(xiàn)用戶需求的高質量、高性能的軟件產品,從而提高用戶對軟件產品的滿意程序。在軟件投入運行前,要對軟件需求分析、設計和編碼各階段的產品進行最終檢查和檢測,軟件測試是對軟件產品內容和程序執(zhí)行狀況的檢測以及調整、修正的一個過程種以檢查軟件產品內容和功能特性為核心的測試軟件質量保證的關鍵步驟,也是成功實現(xiàn)軟件開發(fā)目標的重要保障。軟件測試包括:單元測試、集成測試、系統(tǒng)測試、確認收測試。進入標:?過自我檢查過的程序代碼需要進行測試;?試環(huán)境搭建完成;?試計劃完成。輸入:?要測試的程序代碼;?試工具;?試環(huán)境;?試計劃;?試用例;?試數(shù)據(jù);?試檢查列表;?往的經驗與教訓。退出標:?照測試計劃,所有的測試用例都成功地被執(zhí)行了;

?試過的代碼形成基線。輸出:?試記錄;?陷統(tǒng)計表;?經測試過的代碼。過程描:軟件測試是軟件質量保證的關鍵元素,代表了規(guī)約、設計和編碼的最終檢查。軟件測試針對不同的測試階段和測試內容,可以分為單元測試、集成測試、系統(tǒng)測試以及確認/驗收測試,在編碼階段進行單元測試,單元測試的目的是測試單一的功能模塊能否正常運行;集成測試主要是根據(jù)設計階段制定的測試計劃進行,集成測試是測試模塊與模塊之間的連接是否正確;系統(tǒng)測試主要是對系統(tǒng)的整體質量進行測試;確認驗收測試根據(jù)需求分析階段制定的測試計劃進行測試,是測試整個軟件產品是否滿足了用戶的需求。不同階段所使用的測試用例也是不同的。根據(jù)軟件開發(fā)過程的特點。通常情況下單元測試和集成測試使用白盒測試方法;系統(tǒng)測試和確認驗收測試采用黑盒測試方法。軟件測試的目的主要是為了驗確件正確性。驗證是以開發(fā)者的角度來考慮的,是為了驗證軟件是否滿足用戶的需求;而確認是以用戶的角度考慮的,驗證軟件的方便性、友好性、容錯性等。隨著軟件測試各個階段的不斷進行,驗證的成分越來越少,白盒測試方法所占的比例就會越來越??;確認的成分越來越多,黑盒測試的比例就會越來越大。(1)單元測試單元測試集中在檢查軟件設計的最小單——模塊上,通過測試發(fā)現(xiàn)實現(xiàn)該模塊的實際功能與定義該模塊的功能說明不符合的情況,以及編碼的缺陷。由于模塊規(guī)模小、功能單一、邏輯簡單,測試人員有可能通過模塊說明書和源程序,清楚地了解該模塊的I/O條件和模塊的邏輯結構采用結構測(白盒法的用例盡可能達到徹底測試,然后輔之以功能測試(黑盒法)的用例,使之對任何合理和不合理的輸入都能鑒別和響應。高可靠性的模塊是組成可靠系統(tǒng)的堅實基礎。(2)集成測試將已測試的模塊進行組裝并進行檢測,對照軟件設計測試和排除子系統(tǒng)或系統(tǒng)結

構上的缺陷。集成測試一般采用黑盒測試法,重點是檢測模塊接口之間的連接,發(fā)現(xiàn)訪問公共數(shù)據(jù)結構可能引起的模塊間的干擾,以及全局數(shù)據(jù)結構的不一致,測試軟件系統(tǒng)或子系統(tǒng)輸入輸出處理、故障處理和容錯等方面的

溫馨提示

  • 1. 本站所有資源如無特殊說明,都需要本地電腦安裝OFFICE2007和PDF閱讀器。圖紙軟件為CAD,CAXA,PROE,UG,SolidWorks等.壓縮文件請下載最新的WinRAR軟件解壓。
  • 2. 本站的文檔不包含任何第三方提供的附件圖紙等,如果需要附件,請聯(lián)系上傳者。文件的所有權益歸上傳用戶所有。
  • 3. 本站RAR壓縮包中若帶圖紙,網(wǎng)頁內容里面會有圖紙預覽,若沒有圖紙預覽就沒有圖紙。
  • 4. 未經權益所有人同意不得將文件中的內容挪作商業(yè)或盈利用途。
  • 5. 人人文庫網(wǎng)僅提供信息存儲空間,僅對用戶上傳內容的表現(xiàn)方式做保護處理,對用戶上傳分享的文檔內容本身不做任何修改或編輯,并不能對任何下載內容負責。
  • 6. 下載文件中如有侵權或不適當內容,請與我們聯(lián)系,我們立即糾正。
  • 7. 本站不保證下載資源的準確性、安全性和完整性, 同時也不承擔用戶因使用這些下載資源對自己和他人造成任何形式的傷害或損失。

評論

0/150

提交評論