AutomotiveSPICE 詳解培訓課件_第1頁
AutomotiveSPICE 詳解培訓課件_第2頁
AutomotiveSPICE 詳解培訓課件_第3頁
AutomotiveSPICE 詳解培訓課件_第4頁
AutomotiveSPICE 詳解培訓課件_第5頁
已閱讀5頁,還剩56頁未讀 繼續(xù)免費閱讀

下載本文檔

版權(quán)說明:本文檔由用戶提供并上傳,收益歸屬內(nèi)容提供方,若內(nèi)容存在侵權(quán),請進行舉報或認領(lǐng)

文檔簡介

1、Automotive SPICE 詳解簡介uAutomotive SPICE簡介、特點與結(jié)構(gòu)u關(guān)于Automotive SPICE的過程、過程能力級別和過程屬性u過程評估模型(PAM)概述u與ISO/IEC 15504、ISO/IEC 330XX、CMMI、ISO26262關(guān)系 過程評估方法u能力級別u評級u評估過程 名詞定義 u1、SPICE:Software process improvement and capability determination 軟件過程改進和能力測定。u2、Automotive SPICE: Automotive Software process improve

2、ment and capability determination 汽車軟件過程改進和能力測定u3. CMMI:能力成熟度模型集成u4. PAM: Process Assessment Model 過程評估模型u5. 嵌入式軟件:嵌入在硬件中的操作系統(tǒng)和開發(fā)工具軟件。汽車行業(yè)典型的嵌入式軟件產(chǎn)品有TCU、EMS、ABS、BCM等等。Automotive SPICE 簡介u在汽車行業(yè),從2007年起,Automotive SPICE已作為實施評估的首選過程模型。Automotive SPICE是一個國際廣泛使用的、評估和改進系統(tǒng)及軟件開發(fā)過程的標準,也是由歐洲主要汽車制造商共同制定的面向汽車行業(yè)

3、的過程評估模型。目的是改善搭載于汽車上的電子控制單元ECU的質(zhì)量。u 歐洲的主要汽車制造商在2005年發(fā)布初版的Automotive SPICE規(guī)格,并用其于指導配件供方的開發(fā)過程的改善活動。Automotive SPICE 特點 uAutomotive SPICE的最大特點是由ECU配件供方的OEM(汽車制造商)所策定的規(guī)范。因此它的意義不僅僅限于【取得評估】,更著重于【改善產(chǎn)品開發(fā)項目的質(zhì)量】。u 奧迪、寶馬、奔馳、保時捷、大眾等OEM制造商要求其供應(yīng)商至少要通過Automotive SPICE中的16個過程(HIS范圍過程)達到能力等級3才能成為其合格供應(yīng)商。隨著新能源汽車行業(yè)的發(fā)展,他

4、們也陸續(xù)支持這個要求。u最近,汽車制造商開始要求供方對應(yīng)Automotive SPICE,以滿足功能安全ISO26262所要求的過程建立。u主要用途:1.作為判斷供應(yīng)商開發(fā)能力的評估指南 =通常用基于Automotive SPICE的評估的說法。 =主要是針對一個開發(fā)項目,而不是組織或部門。Automotive SPICE 特點 2.作為供應(yīng)商改善自身流程活動的實施指南=有時候,汽車制造商會指定改善對象的流程。 =德國BMW公司和其他汽車公司共同推薦的流程組被成為HIS范圍(SCOPE)。3.作為滿足功能安全(ISO 26262)所要求的流程建立的指南=ISO 26262要求建立可以持續(xù)地實施

5、改善活動的組織體系和環(huán)境。 =這相當于達成Automotive SPICE的能力3級。Automotive SPICE 結(jié)構(gòu) uAutomotive SPICE3.0包括32個過程,能力級別分為0到5級,其中HIS 過程包括16個。uHIS:是德國的一個汽車組織,德文Hersteller Initiative Software,翻譯成英文為OEM Initiative Software,中文含義是OEM所倡導的軟件。uHIS包含五個成員:奧迪、寶馬、奔馳、保時捷、大眾;主要致力于軟件產(chǎn)品和過程的標準化。HIS范圍的Automotive SPICE過程是HIS成員對其供應(yīng)商的最低要求。Autom

6、otive SPICE 結(jié)構(gòu) uAutomotive SPICE過程參考模型(PRM)-概括,圖中紅色字體的部分屬“HIS范圍”,為BMW及其他主機廠推薦的過程組。Automotive SPICE 能力等級 uAutomotive SPICE能力等級分為05等級,分別是:不完整級、已執(zhí)行級、已管理級、已建立級、可預(yù)測級和創(chuàng)新級。Automotive SPICE 能力等級 uLevel 1:所有納入評估的過程已經(jīng)被執(zhí)行了。所謂執(zhí)行,就是基礎(chǔ)實踐已經(jīng)做了,相應(yīng)的輸出工作產(chǎn)品已經(jīng)有了。uLevel 2:所有納入評估的過程已經(jīng)被執(zhí)行,且其執(zhí)行過程得到了有效的控制,執(zhí)行后的輸出工作產(chǎn)品進行了配置管理。u

7、Level 3:所有納入評估的過程已經(jīng)被企業(yè)標準化,發(fā)布給所有的項目使用,且項目在使用標準過程時,可以進行適宜性的裁剪。uLevel 4:所有納入評估的過程已經(jīng)可以量化,并且經(jīng)過統(tǒng)計分析,可以針對項目的情況,采取適宜的糾正措施。uLevel 5:企業(yè)可以根據(jù)不同項目的行為進行統(tǒng)計分析,判斷哪方面的過程做的比較好,經(jīng)過相關(guān)決策,進行過程的優(yōu)化或持續(xù)改進。也就是企業(yè)具備了自我創(chuàng)新、自我改進的能力。過程評估模型(PAM)中過程定義示例過過程程IDIDMAN.3MAN.3過程名稱項目管理過程目的項目管理過程的目的是在項目的要求和約束的背景下,識別、建立和控制項目生產(chǎn)產(chǎn)品所需的活動和資源。過程結(jié)果成功實

8、施這一過程的結(jié)果是:【1】項目工作的范圍得到定義;【2】利用現(xiàn)有資源和限制達成項目目標的可行性得到評估【3】完成工作所需的活動和資源得到規(guī)模歸類與估算;【4】項目內(nèi)以及與其他項目和OU組織單位之間的接口被識別和監(jiān)視;【5】項目實施計劃得到開發(fā)、執(zhí)行和維持;【6】項目進展得到監(jiān)視和報告【7】在沒有達成項目目標時,糾正措施獲得實施,項目中被識別問題的重復發(fā)生 得到預(yù)防基本實踐基本實踐(BP)(BP)MAN.3.BP1:MAN.3.BP1:定義工作范圍。定義項定義工作范圍。定義項目的目標,動機和邊界。目的目標,動機和邊界?!窘Y(jié)果結(jié)果1 1】MAN.3.BP2:MAN.3.BP2:定義項目生命周期。定

9、定義項目生命周期。定義項目的生命周期,這適合于項目義項目的生命周期,這適合于項目的范圍的范圍i i,環(huán)境,規(guī)模和復雜性。,環(huán)境,規(guī)模和復雜性。【結(jié)果結(jié)果2 2】MAN.3.BP3:MAN.3.BP3:評估項目的可行性。評評估項目的可行性。評估在時間,項目估計和可用資源方估在時間,項目估計和可用資源方面的限制內(nèi)的技術(shù)可行性方面達成面的限制內(nèi)的技術(shù)可行性方面達成項目目標的可行性。項目目標的可行性。【結(jié)果結(jié)果2 2】MAN.3.BP4:MAN.3.BP4:定義,監(jiān)視和調(diào)整項目定義,監(jiān)視和調(diào)整項目活動。根據(jù)定義的項目生命周期和活動。根據(jù)定義的項目生命周期和估計,定義、監(jiān)視和調(diào)整項目活動估計,定義、監(jiān)視

10、和調(diào)整項目活動及其依賴性。根據(jù)需要調(diào)整活動及及其依賴性。根據(jù)需要調(diào)整活動及其依賴關(guān)系。其依賴關(guān)系?!窘Y(jié)果結(jié)果3 3,5 5,7 7】輸出工作產(chǎn)品輸出工作產(chǎn)品(WP)(WP)項目計劃項目計劃-【結(jié)果結(jié)果1 1,3 3,4 4,5 5】交流記錄交流記錄-【結(jié)果結(jié)果4 4,6 6】變更請求變更請求-【結(jié)果結(jié)果7 7】評審記錄評審記錄-【結(jié)果結(jié)果2 2,7 7】糾正措施登記糾正措施登記-【結(jié)果結(jié)果7 7】進度表進度表-【結(jié)果結(jié)果3 3,5 5】工作分解結(jié)果工作分解結(jié)果-【結(jié)果結(jié)果3 3,4 4,5 5】利益相關(guān)團體清單利益相關(guān)團體清單-【結(jié)果結(jié)果4 4】項目狀態(tài)報告項目狀態(tài)報告-【結(jié)果結(jié)果4 4,6

11、6】Automotive SPICE與其他標準的關(guān)系A(chǔ)SPICE 最初是完全沿用CMMI的初始版本CMM(能力成熟度模型,Capability Maturity Model ),ASPICE與CMM相似程度99%,最初的CMMI審核結(jié)果與ASPICE的審核結(jié)果可以直接互相轉(zhuǎn)化,而CMMI的審核員可以直接獲得ASPICE審核員資質(zhì)。CMMI目前由美國的CMMI Institute運營,ASPICE由歐洲的VDA QMS運營。而隨著多年的發(fā)展,兩個標準已經(jīng)逐漸發(fā)展成了獨立的體系。CMMI適用于所有研發(fā)團隊,ASPICE僅用于汽車行業(yè)的軟件研發(fā)團隊。ASPICE模型相對于CMMI模型其針對系統(tǒng)需求到

12、軟件需求、系統(tǒng)設(shè)計到軟件設(shè)計、軟件測試到系統(tǒng)測試、需求跟蹤等流程給出了更細節(jié)的要求。另外針對競標、采購、交付等環(huán)節(jié)也提出了更細節(jié)的要求??傮w而言,截止目前最新版本,ASPICE與CMMI模型依然有極大的相似程度,通常而言,企業(yè)實施兩者中任何一個模型,都可以同時滿足另一個模型的要求。ASPICECMMIAutomotive SPICE與其他標準的關(guān)系ISO15504是ASPICE的前身,ISO15504又稱SPICE,包含三個SPICE標準:汽車行業(yè)的SPICE、醫(yī)療設(shè)備行業(yè)的SPICE、航天行業(yè)的SPICE。2005年汽車行業(yè)的SPICE從ISO體系中獨立出來,由德國汽車行業(yè)聯(lián)合會獨立運作,即

13、為現(xiàn)在ASPICE。ASPICEISO15504Automotive SPICE與其他標準的關(guān)系ISO33020是一個過程評估的標準,適用于ISO體系下所有過程評估。該標準參考CMM模型和CMMI的評估流程標準SCAMPI(Standard CMMI Appraisal Method for Process Improvement)而制定。目前最新版ASPICE已經(jīng)既包含了流程要求(PRM)也包含了評估要求(PAM),而其中的評估要求完全符合ISO33020標準。即,執(zhí)行ASPICE審核完全滿足ISO33020標準。ASPICEISO33020Automotive SPICE與其他標準的關(guān)系I

14、SO26262是道路車輛功能安全標準,針對與安全相關(guān)功能的研發(fā)活動中如何進行安全管理,給出了具體操作標準,包含具體的流程和方法。ISO26262中明確要求企業(yè)建立可以持續(xù)的實施改善活動組織體系和環(huán)境。ASPICE三級中明確要求建立相關(guān)流程體系和組織環(huán)境,因此實施ASPICE同時有助于滿足ISO26262中相關(guān)要求。而另一方便ISO26262中給出了研發(fā)生命周期的具體流程和方法指引也有助于企業(yè)實施ASPICE。ASPICEISO26262Automotive SPICE與其他標準的關(guān)系TS16949是根據(jù)汽車行業(yè)特定需要在ISO9001上的擴充,加入了汽車行業(yè)的特定技術(shù)規(guī)范。對汽車零部件開發(fā)的流

15、程和質(zhì)量控方法給出了具體要求,其完全滿足ISO9001。最新版的TS16949中對企業(yè)定期進行過程評估進行了明確要求,企業(yè)可以選擇采用CMMI評估或者ASPICE評估。即,實施ASPICE可以滿足TS16949中關(guān)于過程評估相關(guān)要求。ASPICETS16949AUTOMOTIVE SPICE的過程包括:主要生命周期過程類-20個過程,組織生命周期過程類-5個過程支持生命周期過程類-7個過程奧迪、寶馬、奔馳、保時捷、大眾等主機廠要求至少通過其中的16個過程(HIS范圍過程),其能力達到等級3才能成為其合格供應(yīng)商。其中:主要生命周期過程類-10個過程,組織生命周期過程類-1個過程支持生命周期過程類

16、-5個過程 AUTOMOTIVE SPICE模型-過程要求介紹 AUTOMOTIVE SPICE模型-過程要求介紹主要生命周期過程類-SYS.2:系統(tǒng)需求分析步驟:SYS.2.BP1(指定)明確系統(tǒng)需求。使用利益相關(guān)方(干系方)要求和其要求的變更確定系統(tǒng)所需的功能和能力。在系統(tǒng)需求規(guī)范中指定功能和非功能系統(tǒng)需求。 SYS.2.BP2:結(jié)構(gòu)化系統(tǒng)需求。在系統(tǒng)需求規(guī)范中結(jié)構(gòu)化系統(tǒng)需求。分組到項目相關(guān)群集,為項目安排邏輯順序分類,基于項目的相關(guān)準則進行分類,根據(jù)利益相關(guān)方(干系方)的需求確定優(yōu)先級。SYS.2.BP3:分析系統(tǒng)需求。分析指定的系統(tǒng)需求,包括其相互依賴性,以確保正確性、技術(shù)可行性和可驗

17、證性,并支持風險識別。分析對成本,進度和技術(shù)影響的影響。SYS.2.BP4:分析對操作環(huán)境的影響。識別指定系統(tǒng)與操作環(huán)境的其他元素之間的接口。分析系統(tǒng)需求對這些接口和操作環(huán)境的影響。SYS.2.BP5:開發(fā)驗證準則。為每個系統(tǒng)需求開發(fā)定義用于驗證要求的定性和定量措施的驗證準則。SYS.2.BP6:建立雙向可追溯性。 建立利益相關(guān)方(干系方)要求和系統(tǒng)需求之間的雙向可追溯性。SYS.2.BP7:確保一致性。 確保利益相關(guān)方(干系方)要求和系統(tǒng)需求之間的一致性。SYS.2.BP8:溝通共識的系統(tǒng)需求。 將所共識的系統(tǒng)需求和系統(tǒng)需求的更新通知所有相關(guān)方。定義:系統(tǒng)需求分析過程的目的是將定義的利益相關(guān)

18、方(干系方)的需求轉(zhuǎn)換為一系列系統(tǒng)需求,以指導系統(tǒng)的設(shè)計。 AUTOMOTIVE SPICE模型-過程要求介紹主要生命周期過程類-SYS.3 系統(tǒng)架構(gòu)設(shè)計步驟:SYS.3.BP1:開發(fā)系統(tǒng)架構(gòu)設(shè)計。 開發(fā)和文檔化系統(tǒng)架構(gòu)設(shè)計,系統(tǒng)要素相應(yīng)的功能性和非功能性系統(tǒng)要求。SYS.3.BP2: 分配系統(tǒng)要求。 分配系統(tǒng)要求到系統(tǒng)架構(gòu)設(shè)計的元素。SYS.3.BP3: 確定系統(tǒng)要素界面(接口)。 定義、開發(fā)和文檔化每個系統(tǒng)要素的界面(接口)。SYS.3.BP4: 描述動態(tài)行為。 評價和文檔化系統(tǒng)元素之間交互的動態(tài)行為。SYS.3.BP5: 評價系統(tǒng)構(gòu)架的可選擇性確定構(gòu)架設(shè)計的評價標準。 根據(jù)確定的標準來評

19、價系統(tǒng)構(gòu)架的可選擇性。為選擇的系統(tǒng)構(gòu)架記錄基本原理。SYS.3.BP6: 建立雙向可追溯性。在系統(tǒng)要求和系統(tǒng)構(gòu)建元素之間建立雙向可追溯性。SYS.3.BP7: 確保一致性。保證系統(tǒng)要求和系統(tǒng)構(gòu)架設(shè)計之間的一致性。SYS.3.BP8:溝通一致的系統(tǒng)構(gòu)架設(shè)計。所有相關(guān)方系統(tǒng)構(gòu)架設(shè)計溝通一致,更新系統(tǒng)構(gòu)架設(shè)計。定義:系統(tǒng)構(gòu)建設(shè)計過程的目的在于建立一個系統(tǒng)架構(gòu)設(shè)計,且定義哪一個系統(tǒng)要求被分配給系統(tǒng)的哪一個要素,在特定的標準下評價系統(tǒng)構(gòu)建設(shè)計 。 AUTOMOTIVE SPICE模型-過程要求介紹主要生命周期過程類- SWE.1 軟件需求分析步驟:SWE.1 BP1:詳細說明軟件要求。通過系統(tǒng)要求及系統(tǒng)

20、架構(gòu),和系統(tǒng)要求及系統(tǒng)架構(gòu)的變化,來確定軟件所需的功能和能力。在軟件要求說明中詳細說明軟件的功能和非功能要求。SWE.1 :結(jié)構(gòu)軟件要求。通過以下方面來構(gòu)造軟件要求說明中的軟件要求:1. 分組項目相關(guān)的群集2. 按邏輯指令篩選項目3. 按照項目的相關(guān)標準進行分類4. 根據(jù)相關(guān)利益者的需求,確定優(yōu)先順序。SWE.1 BP3 :分析軟件要求。分析特定的軟件要求,包括他們的相關(guān)性,以確保正確性、技術(shù)可行性和可驗證性,同時也可用于風險識別。分析對成本、進程和技術(shù)效果的影響。SWE.1 BP4 :分析對操作環(huán)境的影響。分析軟件要求對系統(tǒng)元素的接口和操作環(huán)境的影響。SWE.1 BP5 :確定驗證標準。建立

21、每一個軟件要求的驗證標準,明確驗證的質(zhì)性和量性的測量。SWE.1 BP6 :建立雙向追溯性。在系統(tǒng)要求和軟件要求之間建立一致性和雙向追溯性,并且在系統(tǒng)的結(jié)構(gòu)設(shè)計和軟件要求之間建立一致性和雙向追溯性。SWE.1 BP7:確保一致性。確保系統(tǒng)要求和軟件要求的一致性。確保系統(tǒng)構(gòu)架和軟件要求的一致性。SWE.1 BP8:溝通已經(jīng)同意的軟件要求。在所有相關(guān)方中溝通已經(jīng)同意的軟件要求,并適時更新。定義:軟件需求分析程序的目的在于將系統(tǒng)要求中的與軟件相關(guān)的部門,轉(zhuǎn)化為一組軟件要求。 AUTOMOTIVE SPICE模型-過程要求介紹主要生命周期過程類- SWE.2 軟件架構(gòu)設(shè)計步驟:SWE.2. BP1:確

22、定軟件架構(gòu)設(shè)計。關(guān)于功能性及非功能性的軟件要求的軟件元素,在軟件架構(gòu)設(shè)計中得到詳細說明。SWE.2. BP2:軟件要求的配置。根據(jù)軟件架構(gòu)設(shè)計元素分配軟件要求。SWE.2. BP3:確定軟件元素的接口。識別、發(fā)展并歸檔各個軟件元素的接口。SWE.2. BP4:描述動態(tài)行為。SWE.2. BP5:確定資源消耗的目標。在恰當?shù)膶哟危瑳Q定所有軟件架構(gòu)設(shè)計相關(guān)方的資源消耗目標,并將其文件化。SWE.2. BP6:評估可選擇的軟件架構(gòu)。確定架構(gòu)設(shè)計的評估標準。根據(jù)確定的標準來評估可選擇的軟件架構(gòu)。記錄被選擇的軟件架構(gòu)的基本原理。SWE.2. BP7:建立雙向可追溯性。在系統(tǒng)的結(jié)構(gòu)元素和軟件要求之間建立雙

23、向追溯性。SWE.2. BP8:確保一致性。確保軟件架構(gòu)設(shè)計和軟件要求的一致性。SWE.2.BP9:軟件架構(gòu)設(shè)計得到所有相關(guān)方的同意和溝通。軟件架構(gòu)設(shè)計和適時更新,得到所有相關(guān)方的同意和溝通。定義:軟件架構(gòu)設(shè)計程序的目的在于確定架構(gòu)設(shè)計,確定各每一個軟件要求被分配給哪一個軟件元素,并根據(jù)既定的標準來評估軟件架構(gòu)設(shè)計。 AUTOMOTIVE SPICE模型-過程要求介紹主要生命周期過程類- SWE.3 軟件詳細設(shè)計和單元結(jié)構(gòu)步驟:SWE.3. BP1:確定軟件詳細設(shè)計。對每一個在軟件架構(gòu)設(shè)計中確定的軟件組件開發(fā)一個詳細的設(shè)計。軟件架構(gòu)設(shè)計詳細規(guī)定了所有軟件單元的功能性和非功能性的軟件要求。SWE

24、.3. BP2:確定軟件單元的接口。識別、確定每一個軟件單元的接口,并將其文件化。SWE.3. BP3:描述動態(tài)行動。評估動態(tài)行動及其與相關(guān)軟件單元之間的互相作用,并將其文件化。SWE.3. BP4:評估軟件詳細設(shè)計。根據(jù)互操作性、相互作用、關(guān)鍵性、技術(shù)復雜性、風險可測試性來評估軟件的詳細設(shè)計。SWE.3. BP5:建立雙向追溯性。建立軟件要求和軟件單元之間的一致性和雙向追溯性,建立軟件架構(gòu)設(shè)計和軟件詳細設(shè)計之間的一致性和雙向追溯性,建立軟件詳細設(shè)計和軟件單元之間的一致性和雙向追溯性。SWE.3. BP6:確保一致性。確保軟件要求和軟件單元的一致性,確保軟件架構(gòu)設(shè)計、軟件詳細設(shè)計和軟件單元之間

25、的一致性。SWE.3. BP7:溝通已經(jīng)確定的軟件詳細設(shè)計。與所有相關(guān)方溝通已經(jīng)同意的軟件詳細設(shè)計,并適時更新。SWE.3. BP8:開發(fā)軟件單元。根據(jù)軟件詳細設(shè)計,開發(fā)各個可執(zhí)行的軟件單元,并將其文件化。定義:軟件詳細設(shè)計和單元結(jié)構(gòu)的目的在于提供一個評估過的軟件單元的詳細設(shè)計并生成這個軟件單元。 AUTOMOTIVE SPICE模型-過程要求介紹主要生命周期過程類- SWE.4:軟件單元驗證步驟:SWE.4.BP1:開發(fā)軟件單元驗證策略,包括回歸策略。制定軟件單元驗證策略,包括軟件單元變更時的重新驗證的回歸策略。驗證策略應(yīng)定義如何為軟件單元符合軟件詳細設(shè)計和非功能要求提供證據(jù)。SWE.4.B

26、P2:制定單元核查(驗證)準則。 制定單元驗證準則,以便根據(jù)驗證策略提供軟件單元符合軟件詳細設(shè)計和非功能要求的證據(jù)。 對于單元測試,應(yīng)在單元測試規(guī)范中定義準則。SWE.4.BP3:執(zhí)行軟件單元的靜態(tài)驗證。使用定義的準則驗證軟件單元的正確性。記錄靜態(tài)驗證的結(jié)果。SWE.4.BP4:測試軟件單元。根據(jù)軟件單元驗證策略使用單元測試規(guī)范測試軟件單元。記錄測試結(jié)果和日志。SWE.4.BP5:建立雙向可追溯性。建立軟件單元和靜態(tài)驗證結(jié)果之間的雙向可追溯性。在軟件詳細設(shè)計和單元測試規(guī)范之間建立雙向可追溯性。在單元測試規(guī)范和單元測試結(jié)果之間建立雙向可追溯性。SWE.4.BP6:確保一致性。確保軟件詳細設(shè)計和單

27、元測試規(guī)范之間的一致性。SWE.4.BP7:總結(jié)和溝通結(jié)果??偨Y(jié)單元測試結(jié)果和靜態(tài)驗證結(jié)果,并將其傳達給所有受影響的各方。定義:軟件單元驗證過程的目的是驗證軟件單元,以提供軟件單元與軟件詳細設(shè)計和非功能軟件要求的符合性的證據(jù)。 AUTOMOTIVE SPICE模型-過程要求介紹主要生命周期過程類- SWE.5 軟件集成和集成測試步驟:SWE.5.BP1:確定軟件集成策略。確定與項目計劃和放行計劃一致的軟件集成策略。根據(jù)軟件架構(gòu)設(shè)計,確定軟件項目,并確定集成的順序。SWE.5.BP2:確定軟件集成測試策略,包括回歸測試策略。根據(jù)軟件集成測試策略, 確定集成軟件項目的測試策略。這包括在軟件項目出現(xiàn)

28、變更的情況下,對集成軟件項目進行重新測試的回歸測試策略。SWE.5.BP3:確定軟件集成測試的規(guī)范。根據(jù)軟件集成測試策略,為每一個集成軟件項目確定包括測試案例的集成軟件測試規(guī)范。這個測試規(guī)范必須為集成軟件項目和軟件架構(gòu)設(shè)計的符合性提供證據(jù)。SWE.5.BP4:集成軟件單元和軟件項目。根據(jù)軟件集成策略,將軟件單元集成軟件項目,再將軟件項目集成為一個完整的集成軟件。SWE.5.BP5:選擇測試案例。在軟件集成測試規(guī)范中,選擇測試案例。測試案例必須根據(jù)軟件集成測試策略和放行計劃,有充分的覆蓋范圍。SWE.5.BP6:運行軟件集成測試。通過所選擇的測試案例,運行軟件集成測試,并記錄結(jié)果。SWE.5.B

29、P7:建立雙向追溯性。建立軟件架構(gòu)設(shè)計的元素和包含在軟件集成測試規(guī)范中的測試案例之間的雙向追溯性,建立包含在軟件集成測試規(guī)范中的測試案例和軟件集成測試結(jié)果之間的雙向追溯性。SWE.5.BP8:確保一致性。確保軟件架構(gòu)設(shè)計的元素和包含在軟件集成測試規(guī)范中的測試案例之間的一致性。SWE.5.BP9:總結(jié)和溝通結(jié)果??偨Y(jié)軟件集成測試結(jié)果,并在各相關(guān)方之間傳遞。定義:軟件集成和集成測試的目的在于將軟件單元整合成較大的軟件項目,并上升為一個完整的集成軟件,這個集成軟件與軟件架構(gòu)設(shè)計相符合,并能確保軟件的項目得到測試,可以為集成軟件項目和軟件架構(gòu)設(shè)計的符合性提供證據(jù),包括軟件單元和軟件項目之間的接口。 A

30、UTOMOTIVE SPICE模型-過程要求介紹主要生命周期過程類- SWE.6 軟件一致性測試步驟:SWE.6. BP1:確定軟件一致性測試策略,包括回歸測試策略。根據(jù)項目計劃和放行計劃, 確定軟件一致性測試策略。 這包括在軟件項目出現(xiàn)變更的情況下,對集成軟件項目進行重新測試的回歸測試策略。SWE.6. BP2:確定軟件一致性測試規(guī)范。根據(jù)軟件一致性測試策略,確定包括基于驗證標準的測試案例的集成軟件的質(zhì)量測試規(guī)范,可以為集成軟件和軟件要求的符合性提供證據(jù)。SWE.6. BP3:選擇測試案例。在軟件測試規(guī)范中,選擇測試案例。測試案例必須對于軟件測試策略和放行計劃,有充分的覆蓋范圍。SWE.6.

31、 BP4:測試集成軟件。通過所選擇的案例對集成軟件進行測試,并記錄軟件測試結(jié)果。SWE.6. BP5:建立雙向追溯性。建立軟件要求和包含在軟件一致性測試規(guī)范中的測試案例之間的雙向追溯性,建立包含在軟件一致性測試規(guī)范中的測試案例和軟件一致性測試結(jié)果之間的雙向追溯性。SWE.6. BP6:確保一致性。確保軟件要求和包含在軟件一致性測試規(guī)范中的測試案例之間的一致性。SWE.6. BP7:總結(jié)和溝通結(jié)果??偨Y(jié)軟件一致性測試結(jié)果,并在各相關(guān)方之間傳遞。定義:軟件一致性測試的目的在于確保集成軟件得到測試,可以為集成軟件項目和軟件要求的符合性提供證據(jù)。 AUTOMOTIVE SPICE模型-過程要求介紹主要

32、生命周期過程類- SYS.4 系統(tǒng)集成和集成測試步驟:SYS.4.BP1:開發(fā)系統(tǒng)集成策略。制定一項戰(zhàn)略,集成系統(tǒng)項目的項目計劃和發(fā)布計劃。識別系統(tǒng)項目基于集成的系統(tǒng)架構(gòu)設(shè)計和定義一個序列。SYS.4.BP2:開發(fā)系統(tǒng)集成測試策略包括回歸測試策略。制定一項戰(zhàn)略,測試后的集成系統(tǒng)項目集成策略。這包括一個回歸測試策略,測試集成系統(tǒng)項目系統(tǒng)項是否改變。SYS.4.BP3: 為系統(tǒng)集成測試創(chuàng)建說明書。 根據(jù)系統(tǒng)一體化測試戰(zhàn)略為系統(tǒng)測試創(chuàng)建說明書包括系統(tǒng)項目測試案例一體化的每一個步驟 。該測試說明書應(yīng)適用于為一體化在系統(tǒng)構(gòu)設(shè)計下的系統(tǒng)項目的順從性提供證據(jù)SYS.4.BP4:集成系統(tǒng)項目。根據(jù)系統(tǒng)一體化戰(zhàn)

33、略將系統(tǒng)項目綜合納入綜合系統(tǒng)項目。SYS.4.BP5: 選擇測試案例。 從測試說明中選擇測試案例。根據(jù)系統(tǒng)一體化測試戰(zhàn)略和發(fā)布計劃制定的測試案例的選擇應(yīng)包含足夠地覆蓋范圍 。SYS.4.BP6: 執(zhí)行系統(tǒng)集成測試。 使用選擇后的測試案例來執(zhí)行系統(tǒng)集成測試。記載集成測試結(jié)果和記錄。SYS.4.BP7:建立雙向可追溯性。在構(gòu)建設(shè)計元素和測試案例中建立雙向可追溯性包含系統(tǒng)一體化測試說明。在測試案例包括和系統(tǒng)一體化測試說明中的測試案例和測試結(jié)果中建立雙向可追溯性。SYS.4.BP8:確保一致性 在系統(tǒng)元素和系統(tǒng)構(gòu)架設(shè)計,測試案例包括系統(tǒng)一體化測試說明中保證一致性。SYS.4.BP9: 總結(jié)和交流結(jié)果。

34、 總結(jié)系統(tǒng)集成測試結(jié)果并且與所有相關(guān)方交流。定義:系統(tǒng)集成和系統(tǒng)集成測試過程的目的,集成系統(tǒng)的項目,來制造一個集成系統(tǒng),與系統(tǒng)構(gòu)架設(shè)計保持一致,確保系統(tǒng)項目得到檢測,同時為系統(tǒng)構(gòu)架設(shè)計包括系統(tǒng)項目間的界面(接口)提供證據(jù)。 AUTOMOTIVE SPICE模型-過程要求介紹主要生命周期過程類- SYS.5 系統(tǒng)一致性測試步驟:SYS.5. BP1:確定系統(tǒng)一致性測試方法包括回歸測試方法。確定與項目計劃一致的系統(tǒng)質(zhì)量測試方法和放行計劃。這包括如果系統(tǒng)項目發(fā)生變化以后,重新測試系統(tǒng)的回歸測試方法。SYS.5. BP2:確定系統(tǒng)一致性測試的規(guī)范。根據(jù)系統(tǒng)測試方法的確認標準,確定系統(tǒng)質(zhì)量測試的規(guī)范,包

35、括測量案例。測試規(guī)范必須要與整個系統(tǒng)的系統(tǒng)要求相符合。SYS.5. BP3:選擇測試案例。根據(jù)系統(tǒng)質(zhì)量測試規(guī)范,選擇測試案例。測試案例的選擇必須充分涵蓋系統(tǒng)測試方法和放行計劃。SYS.5. BP4:測試綜合系統(tǒng)。使用所選擇的測試案例來測試綜合系統(tǒng)。記錄系統(tǒng)測試結(jié)果。SYS.5. BP5:建立雙向追溯性。在系統(tǒng)要求和測試案例包括系統(tǒng)質(zhì)量測試規(guī)范之間,建立一致性和雙向追溯性。在包含了系統(tǒng)質(zhì)量測試規(guī)范的測試案例,和系統(tǒng)質(zhì)量測試結(jié)果之間,建立一致性和雙向追溯性。SYS.5. BP6:確保一致性。確保系統(tǒng)要求和包括系統(tǒng)質(zhì)量測試規(guī)范的測試案例質(zhì)檢的一致性。SYS.5. BP7:總結(jié)并交流結(jié)果??偨Y(jié)系統(tǒng)質(zhì)量

36、測試的結(jié)果并在相關(guān)方之間得到傳遞。定義:系統(tǒng)一致性測試的目的在于確保綜合系統(tǒng)經(jīng)過測試,能夠符合系統(tǒng)要求,并且系統(tǒng)已經(jīng)為輸出做好準備。 AUTOMOTIVE SPICE模型-過程要求介紹主要生命周期過程類- ACQ.4:供應(yīng)商監(jiān)測步驟:ACQ.4.BP.1: 協(xié)商一致并保持聯(lián)合過程、聯(lián)合接口以及信息的交流。建立和保持對信息進行交換,以及關(guān)于聯(lián)合過程和聯(lián)合接口、責任、聯(lián)合活動的類型和頻率、通信、會議、狀態(tài)報告和審查的協(xié)議。ACQ.4.BP.2: 交換所有雙方協(xié)定的信息。 利用客戶和供應(yīng)商雙方所定義的聯(lián)合接口溝通所有雙方協(xié)定的信息。ACQ.4.BP.3. 與供應(yīng)商一起評估技術(shù)開發(fā)。根據(jù)雙方協(xié)商一致定

37、期與供應(yīng)商一起評估技術(shù)開發(fā),包含技術(shù)方面、問題、風險以及全程跟蹤已經(jīng)開始的項目。ACQ.4.BP.4: 對供應(yīng)商的進展進行評估。根據(jù)雙方協(xié)商一致定期對供應(yīng)商的進展進行評估,包括計劃安排你、質(zhì)量以及成本。全程跟蹤已經(jīng)開始的項目,并開展風險消減活動。ACQ.4.BP.5: 采取行動糾正偏差。 當雙方協(xié)商一致的目標未能達成時,采取行動糾正偏離項目計劃的行為,防止已被發(fā)現(xiàn)的問題再次發(fā)生。根據(jù)目標協(xié)商改變行為,并將此改變體現(xiàn)在協(xié)議中。定義:供應(yīng)商監(jiān)督的目的是為了根據(jù)雙方協(xié)定的要求跟蹤及評估供應(yīng)商的執(zhí)行情況。 AUTOMOTIVE SPICE模型-過程要求介紹組織生命周期過程類- MAN.3:項目管理步驟

38、:MAN.3.BP1: 定義工作范圍:定義項目的目標,動機和邊界。MAN.3.BP2:定義項目生命周期。定義項目的生命周期,這適合于項目的范圍,環(huán)境,規(guī)模和復雜性。MAN.3.BP3:評估項目的可行性。評估在時間,項目估計和可用資源方面的限制內(nèi)的技術(shù)可行性方面達成項目目標的可行性。MAN.3.BP4:定義,監(jiān)測和調(diào)整項目活動。根據(jù)定義的項目生命周期和估計,定義、監(jiān)測和調(diào)整項目活動及其依賴性。根據(jù)需要調(diào)整活動及其依賴關(guān)系。MAN.3.BP5:確定,監(jiān)測和調(diào)整項目估計和資源。根據(jù)項目的目標,項目風險,動機和邊界,定義,維護/監(jiān)控和調(diào)整項目的努力和資源估算。MAN.3.BP6:確保所需的技能,知識和

39、經(jīng)驗。識別項目所需的技能,知識和經(jīng)驗,并確保選定的個人和團隊及時擁有或獲得這些。 MAN.3.BP7:識別、監(jiān)測和調(diào)整項目接口和商定承諾。識別和同意項目與其他(子)項目,組織單位和其他受影響利益相關(guān)方(干系方)的接口,并監(jiān)測商定的承諾。MAN.3.BP8:定義,監(jiān)測和調(diào)整項目進度。 為活動分配資源,并安排整個項目的每個活動。 在項目的生命周期中,必須不斷更新進度表。MAN.3.BP9:確保一致性。 確保項目的估計、活動、時間表、計劃、接口、技能和承諾在受影響各方之間保持一致。MAN.3.BP10:評審和報告項目進展情況。 定期評審并向所有受影響的各方報告項目的狀況和活動的執(zhí)行情況,以及估計的努

40、力和持續(xù)時間。 防止識別的問題的再發(fā)生。定義:項目管理程序是為了識別、建立和控制一個項目所需要的行動和資源,在項目的要求和限制條件下,生產(chǎn)出產(chǎn)品。 AUTOMOTIVE SPICE模型-過程要求介紹支持生命周期過程類- SUP.1:質(zhì)量保證步驟:SUP.1.BP1:制定項目質(zhì)量保證策略。制定策略,以確保工作產(chǎn)品(WP)和過程質(zhì)量保證在項目層面獨立和客觀地進行,沒有利益沖突。SUP1.BP2:確保工作產(chǎn)品(WP)的質(zhì)量。根據(jù)質(zhì)量保證策略和項目進度執(zhí)行活動,以確保工作產(chǎn)品(WP)符合定義的工作產(chǎn)品(WP)要求并記錄結(jié)果。 SUP1.BP3:確保過程活動的質(zhì)量。根據(jù)質(zhì)量保證策略和項目進度執(zhí)行活動,以

41、確保過程滿足其定義的目標并記錄結(jié)果。SUP.1.BP4:總結(jié)和溝通質(zhì)量保證活動和結(jié)果。定期向相關(guān)方報告質(zhì)量保證活動的績效,偏差和趨勢,以根據(jù)質(zhì)量保證策略提供信息和采取措施。SUP1.BP5:確保解決不合格。在過程和產(chǎn)品質(zhì)量保證活動中發(fā)現(xiàn)的偏差或不一致應(yīng)該被分析、跟蹤、糾正和進一步防止。SUP1.BP6:實施升級機制。根據(jù)質(zhì)量保證策略建立和維持升級機制,確保質(zhì)量保證可能將問題升級到適當級別的管理層和其他相關(guān)利益相關(guān)方(干系方)以解決這些問題。定義:質(zhì)量保證過程的目的在于:為工作產(chǎn)品和流程能遵守既定條款和計劃,不符合項能得到解決和預(yù)防,提供獨立客觀的保障。 AUTOMOTIVE SPICE模型-過

42、程要求介紹支持生命周期過程類- SUP.8:配置管理步驟:SUP.8.BP1:確定配置管理策略。確定配置管理策略。包括:1.職責和資源; 2.工具和資源庫;3.配置項的識別及其命名慣例;4.訪問權(quán)限;5.配置項和基線的歷史,包括:必須和可選的基線;命名慣例;分化、合并和建立基線的方法;發(fā)布和批準的流程SUP.8. BP2:確定配置項。根據(jù)配置管理策略,識別并記錄配置項。SUP.8. BP3:建立配置管理系統(tǒng)。根據(jù)配置管理策略建立配置管理系統(tǒng)。SUP.8. BP4:建立分支管理策略。建立適用于使用相同基礎(chǔ)的平行項目的分支管理策略。SUP.8. BP5:控制調(diào)整和發(fā)布。根據(jù)配置管理策略建立配置項的

43、控制機制,通過這些機制來控制調(diào)整和發(fā)布。SUP.8. BP6:建立基線。根據(jù)配置管理策略,建立內(nèi)部目標和外部交付的基線。SUP.8. BP7:報告配置狀態(tài)。為支持項目管理和其他相關(guān)流程,記錄并匯報配置項的狀態(tài)。SUP.8. BP8:確認配置項的信息。確認配置項及其基線的信息是完整的,并確定基線的一致性。SUP.8. BP9:管理存儲的配置項和基線。確保配置項和基線的完整性和可用性,通過適當?shù)囊?guī)劃調(diào)度和存儲資源的分配、歸檔的長期存儲和備份使用CM系統(tǒng)。定義:配置管理過程的目的在于建立和維護一個流程或項目所有的工作產(chǎn)品的完整性,并對所有相關(guān)方可用。 AUTOMOTIVE SPICE模型-過程要求介

44、紹支持生命周期過程類- SUP.9 問題解決管理步驟:SUP.9.BP1:建立解決問題的管理策略。建立解決問題的管理策略,包括解決問題的行動、問題的狀態(tài)模型、警報通知、行動的執(zhí)行責任人和緊急情況處理機制。各方的影響因素都很明確,而且也有明確定義。SUP.9.BP2: 確定和記錄問題每一個問題都被獨立的確認、描述和記錄。在問題重現(xiàn)和判定過程中,須提供其他支持性的信息。SUP.9.BP3:記錄問題的狀態(tài)。每一個問題都需要一個指定的狀態(tài)模式來跟蹤狀態(tài),以便追溯。SUP.9.BP4:判定出根本原因,并確定出問題的影響范圍。調(diào)查問題,確定問題的根本原因和影響范圍,以便給該問題分類,并決定合適的解決方案。

45、SUP.9.BP5:授權(quán)緊急情況的解決方案。如果問題管理機制要求一個緊急預(yù)案,則須獲得緊急預(yù)案的許可,這個緊急預(yù)案必須要符合問題解決機制的要求。SUP.9.BP6:建立警報通知。如果問題管理機制要求,其他系統(tǒng)或其他關(guān)聯(lián)方出現(xiàn)了有較大影響問題,則需要建立一個預(yù)警通知機制,這個警報機制必須要符合問題解決機制要求。SUP.9.BP7:開始問題解決根據(jù)問題解決策略,開始問題解決的適當措施,包括評審行動措施,或提出變更申請。SUP.9.BP8:跟蹤并關(guān)閉問題。跟蹤并關(guān)閉問題,包括所有相關(guān)的變更申請。在問題關(guān)閉之前,需要得到關(guān)于變更申請的正式許可。SUP.9.BP9:分析問題趨勢。收集并分析問題解決管理的

46、數(shù)據(jù),確定趨勢,并根據(jù)問題解決管理機制采取相關(guān)行動。定義:問題解決管理過程的目的在于問題得到確定、分析、管理和控制。 AUTOMOTIVE SPICE模型-過程要求介紹支持生命周期過程類- SUP.10 變更申請管理步驟:SUP.10.BP1:建立變更申請的管理機制建立變更申請的管理機制,包括變更申請行為、變更申請的狀態(tài)模式、分析準則和執(zhí)行這些行動的責任人。影響各方的因素得到明確和維護。SUP.10.BP2:確定和記錄變更申請每一個變更申請都根據(jù)變更管理機制,被單獨識別、描述和記錄,包括變更申請的發(fā)起人和變更理由。SUP.10.BP3:記錄變更申請的狀態(tài)每一個變更申請都有一個指定的狀態(tài)模式,以

47、便進行追溯。SUP.10.BP4:分析并評估變更申請。根據(jù)策略分析變更申請,包括和其他受影響的工作產(chǎn)品和其他變更申請的依賴性。評估變更申請的影響,并建立確認實施的評判標準。SUP.10.BP5:在執(zhí)行之前批準變更申請。在執(zhí)行之前,基于分析結(jié)果和資源的可用性,確定變更申請的優(yōu)先級,并根據(jù)策略獲得認可。SUP.10.BP6:評審變更申請的執(zhí)行變更申請的執(zhí)行在關(guān)閉之前需要被評審,以確保確認執(zhí)行的條件是否滿意,以及其他所有相關(guān)程序是否已經(jīng)得到應(yīng)用。SUP.10.BP7:跟蹤變更申請直至關(guān)閉跟蹤變更申請制止關(guān)閉。跟蹤反饋會提供給發(fā)起人。SUP.10.BP8:建立雙向追溯機制。在已有的變更申請和受影響的工

48、作產(chǎn)品之間建立雙向追溯性。如果是因為出現(xiàn)問題才發(fā)起的變更申請,則需要在相關(guān)的問題報告和相應(yīng)的變更申請之間,建立雙向追溯性。定義:過程的變更申請管理目的在于確保變更申請可以被管理、追溯和執(zhí)行。能力級別實踐中相關(guān)的指標(指示器)類型(能力)實踐中相關(guān)的指標(指示器)類型(能力)=以活動為導向的指標(指示器)=以結(jié)果為導向的指標(指示器)評估指標(指示器)CL1指標(指示器) 即PA1.1CL1*和2至5指標(指示器)BP基本實踐 輸出WP工作產(chǎn)品GP通用實踐*CL1的GP1.1.1僅僅是其BP基本實踐的編輯參考PAMPAM中過程定義的示例中過程定義的示例過程IDMAN.3過程名稱項目管理過程目的項

49、目管理過程的目的是在項目的要求和約束的背景下,識別、建立和控制項目生產(chǎn)產(chǎn)品所需的活動和資源。過程結(jié)果成功實施這一過程的結(jié)果是:1)項目工作的范圍得到定義;2)利用現(xiàn)有資源和限制達到項目目標的 可行性得到評估;3)完成工作所需的活動和資源得到規(guī)模歸類和估算;4)項目內(nèi)以及其他項目和OU組織單位之間的接口被識別和監(jiān)視;5)項目實施計劃得到開發(fā)、執(zhí)行和維持;6)項目進展得到監(jiān)視和報告;7)在沒有達成項目目標時,糾正措施獲得實施,項目中被識別問題的重復發(fā)生得到預(yù)防。PRMPRM元素元素基本實踐(BP)MAN.3.BP1:定義工作范圍。定義項目的目標,動機和邊界。結(jié)果1MAN.3.BP2:定義項目生命周

50、期。定義項目的生命周期,這適合于項目的范圍,環(huán)境,規(guī)模和復雜性。結(jié)果2MAN.3.BP3:評估項目的可行性。評估在時間,項目估計和可用資源方面的限制內(nèi)的技術(shù)可行性方面達成項目目標的可行性。結(jié)果2MAN.3.BP4:定義,監(jiān)視和調(diào)整項目活動及其依賴性。根據(jù)需要調(diào)整活動及其依賴關(guān)系。結(jié)果3,5,7輸出工作產(chǎn)品(WP)08-12 項目計劃 結(jié)果1,3,4 ,5 13-04 交流記錄 結(jié)果4 ,6 13-16 變更請求 結(jié)果713-19 評審記錄 結(jié)果2,714-02 糾正措施登記 結(jié)果714-06 進度表 結(jié)果3,5 14-09 工作分解結(jié)果 結(jié)果3 ,4,5 14-50 利益相關(guān)團體清單 結(jié)果4

51、15-06 項目狀態(tài)報告 結(jié)果4, 6 PAMPAM元素,即元素,即CL1CL1的指標的指標能力級別ISO/IEC 33020ISO/IEC 33020中的中的PAPA過程示例和相應(yīng)的過程示例和相應(yīng)的GP2.1.XGP2.1.X定義定義ISO/IEC 33020ISO/IEC 33020PA2.1PA2.1執(zhí)行管理過程屬性執(zhí)行管理過程屬性執(zhí)行管理過程屬性是對過程的執(zhí)行進行管理的程度的度量。作為完全達成該過程屬性的結(jié)果:a) 過程執(zhí)行的目標得到識別;b) 過程的執(zhí)行被計劃;c) 過程的執(zhí)行得到監(jiān)視;d) 過程的執(zhí)行獲得調(diào)整以滿足計劃;e) 執(zhí)行過程的職責和權(quán)限得到定義、分配和溝通;f) 執(zhí)行過程

52、的人員履行其職責被準備;g) 執(zhí)行過程所需的資源和信息得到識別、提供、分配和使用;h) 相關(guān)方之間的接口被管理,以確保有效溝通和明確的責任分配。ISO/IEC 15504-5ISO/IEC 15504-5GP2.1.1 識別過程執(zhí)行的目標;GP2.1.2 計劃過程的執(zhí)行,以達成確定的目標。GP2.1.3 根據(jù)計劃監(jiān)視過程的執(zhí)行情況。GP2.1.4 調(diào)整過程的執(zhí)行。GP2.1.5 定義執(zhí)行過程的職責和權(quán)限。GP2.1.6 根據(jù)計劃識別、準備和提供可用資源以及執(zhí)行過程。GP2.1.7 管理相關(guān)方之間的接口。能力級別ISO/IEC 33020ISO/IEC 33020中的中的PAPA過程示例和相應(yīng)的

53、過程示例和相應(yīng)的GP2.2.XGP2.2.X定義定義ISO/IEC 33020ISO/IEC 33020PA2.2PA2.2工作產(chǎn)品(工作產(chǎn)品(WPWP)管理過程屬性)管理過程屬性工作產(chǎn)品(WP)管理過程屬性是對由過程產(chǎn)生的工作產(chǎn)品(WP)被適當管理的程度的度量。作為完全達成該過程屬性的結(jié)果:a) 過程工作產(chǎn)品(WP)的需求得到定義;b) 過程工作產(chǎn)品(WP)的文件化和控制需求得到定義;c) 過程工作產(chǎn)品(WP)被適當?shù)刈R別、文件化和控制;d) 過程工作產(chǎn)品(WP)根據(jù)計劃被安排評審并根據(jù)需要得到調(diào)整以滿足需求。ISO/IEC 15504-5ISO/IEC 15504-5GP2.2.1 定義W

54、P工作產(chǎn)品的需求。定義工作產(chǎn)品(WP)的需求。GP2.2.2 定義WP工作產(chǎn)品文件化和控制的需求。GP2.2.3 識別、文檔化和控制WP工作產(chǎn)品。GP2.2.4 評審和調(diào)整WP工作產(chǎn)品以滿足定義的需求。能力級別ISO/IEC 33020ISO/IEC 33020中的中的PAPA過程示例和相應(yīng)的過程示例和相應(yīng)的GP3.1.XGP3.1.X定義定義ISO/IEC 33020ISO/IEC 33020PA3.1PA3.1過程定義過程屬性過程定義過程屬性過程定義過程屬性是維護標準過程以支持定義的過程部署的程度的度量。作為完全達成該過程屬性的結(jié)果:a) 一個標準過程,包括適當?shù)牟眉簦ǘㄖ疲┲改系玫?定義

55、和維持,描述必須納入定義過程的基本要素;b) 標準過程與其他過程的順序和相互作用得到?jīng)Q定;c) 執(zhí)行過程所需的能力和崗位被識別為標準過程的一部分;d) 執(zhí)行過程所需的基礎(chǔ)設(shè)施和工作環(huán)境被識別為標準過程的一部分;e) 用于監(jiān)視方法的有效性和適用性的合適的方法和措施得到?jīng)Q定。ISO/IEC 15504-5ISO/IEC 15504-5GP3.1.1 定義和維持支持已定義過程部署的標準過程。GP3.1.2 決定過程間的順序和交互,以使其能夠作為過程的整體系統(tǒng)工作。GP3.1.3 識別執(zhí)行標準過程的角色和能力、職責和權(quán)限。GP3.1.4 識別執(zhí)行標準過程所需的基礎(chǔ)設(shè)施和工作環(huán)境。GP3.1.5 決定適

56、當?shù)姆椒ê痛胧?,以監(jiān)視標準過程的有效性和適用性。能力級別ISO/IEC 33020ISO/IEC 33020中的中的PAPA過程示例和相應(yīng)的過程示例和相應(yīng)的GP3.2.XGP3.2.X定義定義ISO/IEC 33020ISO/IEC 33020PA3.2PA3.2過程部署過程屬性過程部署過程屬性過程部署過程屬性是衡量標準過程部署為已定義過程以達成其過程結(jié)果的程度的度量。作為完全達成該過程屬性的結(jié)果:a) 基于適當選擇和/或裁剪(定制)的標準過程,已定義過程得到部署;b) 執(zhí)行已定義過程所需的崗位、職責和權(quán)限得到指派并溝通;c) 執(zhí)行已定義過程的人員基于適當?shù)慕逃嘤柡徒?jīng)驗具備能力;d) 執(zhí)行

57、已定義過程所需的必要資源和信息被提供、分配和使用;e) 執(zhí)行已定義過程所需的基礎(chǔ)設(shè)施和工作環(huán)境獲得提供、管理和維護;f) 作為理解過程行為的基礎(chǔ),以證明過程的適用性和有效性,并用以評估過程可以持續(xù)改進的地方,適當?shù)臄?shù)據(jù)得到收集和分析。ISO/IEC 15504-5ISO/IEC 15504-5GP3.2.1 部署已定義過程滿足標準過程使用環(huán)境特定要求的過程。GP3.2.2 指派并溝通執(zhí)行已定義過程的崗位、職責和權(quán)限作。GP3.2.3 確保執(zhí)行已定義過程的必要能力。GP3.2.4 提供資源和信息以支持已定義過程的執(zhí)行。GP3.2.5 提供充分的過程基礎(chǔ)設(shè)施以支持已定義過程的執(zhí)行。GP3.2.6

58、收集并分析關(guān)于過程績效的數(shù)據(jù)以證明其適用性和有效性。能力級別評級結(jié)果有評級結(jié)果有6 6級級CL1已執(zhí)行PA1.1過程執(zhí)行(*)CL2已管理PA2.1 執(zhí)行管理PA2.2工作產(chǎn)品管理CL3已確立PA3.1過程定義PA3.2 過程部署CL4 可預(yù)測PA4.1 定量分析PA4.2 定量控制CL5可創(chuàng)新PA5.1 過程創(chuàng)新PA5.2 過程創(chuàng)新落實CL0 不完整能力級別過程能力級別及過程屬性過程能力級別及過程屬性存在6個能力級別 ,表現(xiàn)為 9個過程屬性級別0:不完整過程過程沒有執(zhí)行,或無法達成其過程目的。級別1:已執(zhí)行過程執(zhí)行的過程達成其過程目的。級別2:已管理過程先前描述的所執(zhí)行的過程現(xiàn)在以受管理的方

59、式(計劃、監(jiān)視和調(diào)整)實施,并且其工作產(chǎn)品(WP)被適當?shù)亟?、控制和維護。級別3:已建立過程先前描述的管理過程現(xiàn)在使用能夠達成其過程結(jié)果的定義的過程來執(zhí)行。級別4:可預(yù)測過程先前描述的已建立的過程現(xiàn)在在定義的范圍內(nèi)可預(yù)見性地運行達成其過程結(jié)果。定量管理需求識別,測量數(shù)據(jù)被收集和分析以識別可歸因的變差原因。采取糾正措施來解決可歸因的變差原因。級別5:可創(chuàng)新過程先前描述的可預(yù)測過程正持續(xù)改進以相應(yīng)組織變化。注意:評級是評過程屬性注意:評級是評過程屬性能力級別過程能力級別及過程屬性過程能力級別及過程屬性在這個過程評估模型中,能力的定義是基于ISO/IEC33020定義的9個過程屬性,如表:級別0:

60、不完整過程級別1:已執(zhí)行過程PA1.1過程執(zhí)行過程屬性級別2:已管理過程PA2.1執(zhí)行管理過程屬性PA2.2工作產(chǎn)品(WP)管理過程屬性級別3:已建立過程PA3.1過程定義過程屬性PA3.2過程部署過程屬性級別4:可預(yù)測過程PA4.1定量分析過程屬性PA4.2定量控制過程屬性級別5:可創(chuàng)新過程PA5.1過程創(chuàng)新過程屬性PA5.2過程創(chuàng)新落實過程屬性能力級別評級PAPA可以獲得什么等級值?(可以獲得什么等級值?(ISO/IEC33020ISO/IEC33020)NPLF未達成未達成 0%0%至至15%15%“很少或根本沒有證據(jù)表明達成被評估過程,定義的屬性。”部分達成部分達成 15%15%至至5

溫馨提示

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

評論

0/150

提交評論