今天給各位分享aspice軟件開發(fā)組織架構的知識，其中也會對aspice軟件架構設計進行解釋，如果能碰巧解決你現(xiàn)在面臨的問題，別忘了關注本站，現(xiàn)在開始吧！

本文目錄一覽：

• 1、aspice 認證是什么
• 2、ASPICE?VDA?Guideline解讀(18)：SUP.10?變更請求管理
• 3、汽車軟件認證體系有哪些
• 4、工作筆記 aspice基礎知識
• 5、工作筆記 ?ASPICE?VDA?Guideline解讀(20)：MAN.3?項目管理
• 6、工作筆記ASPICE VDA Guideline解讀(19)：SUP.8 配置管理

aspice 認證是什么

ASPICE是Automotive SPICE英文簡稱，是汽車行業(yè)軟件過程改進和能力評價的國際標準。 上海有亞洲遠景科技公司是做ASPICE咨詢認證的。 擴展資料

ASPICE認證能力等級2 級的過程定義文件和3 級的`過程定義文件有什么區(qū)別？

2 級的過程定義是在項目或團隊級別的已管理習慣化（過程活動和工作產(chǎn)品的已管理習慣化），這些過程定義，

還沒有經(jīng)歷從個別項目，到幾個項目的試點，再到公司全部項目的全面推廣。

3 級過程定義，經(jīng)過了試點、推廣過程之后，形成組織級的標準過程定義和裁剪指南等；試點和推廣過程，不斷嘗試不斷總結，過程定義會有修改及調(diào)整。

ASPICE?VDA?Guideline解讀(18)：SUP.10?變更請求管理

SUP.10 變更請求管理"過程的目的是確保變更請求被管理、跟蹤和實施。

在什么場景下需要應用SUP.10來進行變更管理呢？

舉個例子來說明變更請求的各種情況，如下圖所示：

客戶發(fā)布了"客戶需求規(guī)約"基線

產(chǎn)品需求工程師基于"客戶需求規(guī)約"基線，開發(fā)并發(fā)布了"產(chǎn)品需求規(guī)約"基線

開發(fā)工程師基于"產(chǎn)品需求規(guī)約"基線，開發(fā)并發(fā)布了"產(chǎn)品設計和實現(xiàn)"基線

場景1：當已建立基線的"客戶需求規(guī)約"發(fā)生變更時，需要應用SUP.10：

場景2：測試工程師在實施測試活動時，發(fā)現(xiàn)了缺陷（注：按"SUP.9 問題解決管理"處理缺陷），開發(fā)工程師在解決缺陷的過程中，發(fā)現(xiàn)有必要變更已建立基線的產(chǎn)品需求規(guī)約。此時需要觸發(fā)"SUP.10 變更請求管理"過程來請求變更“產(chǎn)品需求規(guī)約”。

場景3：當由于例如"設計重構“的原因，對已建立基線的"產(chǎn)品設計"進行變更。

變更請求管理策略：

a需覆蓋變更請求影響的各個學科(如：軟件、電路）、各個領域（如：應用層軟件、底層軟件）

b需覆蓋變更請求影響的各相關方，如客戶、供應商、內(nèi)部相關方等

c需定義變更請求在各學科、各領域、各相關方之間的傳遞和管理

d需定義變更請求的"狀態(tài)模型"

e需定義活動的目標，如響應時間

f需定義變更請求批準在組織結構層級上的指導，如變更請求的影響到達XX成本時，需要項目經(jīng)理批準，而當變更請求的影響到達XX成本時，需要部門總監(jiān)批準

e可以根據(jù)項目所處的不同階段（如：A樣件、B樣件），定義變更請求處理的不同要求

f需定義確保"變更請求"與"變更請求影響的工作產(chǎn)品及基線"之間的雙向追溯性的機制

[SUP.10.RL.1] If the strategy does not include all aspects above, the indicator BP1 must not be rated F.

老楊解讀：如果策略中沒有包括上述的各點，則BP1的打分不能是F。

[SUP.10.RL.2] If the strategy does not address interfaces between multisite organizations/projects, subprojects, and/or groups in case of correspondingly complex projects, the indicator BP1 must not be rated higher than P.

老楊解讀：如果在項目結構相對復雜的場景下，策略中沒有處理處于不同地點的組織/項目、子項目和/或組之間的接口，則BP1的打分不能高于P。

[SUP.10.RC.1] If the strategy does not include goals according to e) above, the indicator BP1 should be downrated.

老楊解讀：如果策略中沒有包括活動的目標（上述的e），則應降低BP1的打分。

[SUP.10.RC.2] If change request handling is actually different over project life cycle phases but not consistent with the defined strategy, the indicator BP1 should be downrated.

老楊解讀：如果在項目的不同階段，變更請求的處理是不同的，但與已定義的策略不一致，則應減低BP1的打分。

[SUP.10.RC.3] If the use of a strategy is obvious by the implementation in a tool but not explicitly documented this should not be used to downrate the indicator BP1 to N or P.

老楊解讀：如果是使用工具來處理變更請求，但沒有明確的文檔化的策略，不能基于此來降低BP1的打分至N或P。

(2) 變更請求的批準

ASPICE模型要求

SUP.10.BP5: 變更實施前獲得批準 / Approve change requests before implementation

基于分析結果和資源可用性，對變更請求進行優(yōu)先級排序，并根據(jù)策略批準

Change requests are prioritized based on analysis results and availability of resources before implementation and approved according to the strategy.

通常由CCB(Change Control Board)來批準變更請求，CCB是由變更請求影響的所有相關方的代表組成，并具有批準的授權。

[SUP.10.RL.3] If not all relevant disciplines or stakeholders are represented in the actual CCB the indicator BP5 must not be rated F.

老楊解讀：如果CCB中沒有包括所有相關的學科或相關方，則BP5的打分不能為F。

[SUP.10.RC.4] If it is apparent that decisions are not taken or not taken in time by the CCB without justification, the indicator BP5 should be downrated.

老楊解讀：如果CCB沒有及時對變更請求做決定，并缺少正當理由，則應減低BP5的打分。

(3) 影響分析和變更確認

ASPICE模型要求

SUP.10.BP4: 分析和評估變更請求 / Analyze and assess change requests

根據(jù)策略，分析變更請求，包括它們對受影響的工作產(chǎn)品和其它變更請求的依賴。評估變更請求的影響，并建立確認實施的標準。

SUP.10.BP6: 評審變更請求的實現(xiàn) / Review the implementation of change requests

變更請求在關閉前進行評審，以確保滿足已定義的確認標準，并已應用所有相關過程。

[SUP.10.RL.4] If the analysis does not adequately address potential side effects due to specific risks and complexity of the potential changes the indicator BP4 must not be rated F.

老楊解讀：如果不能對由于特定風險和潛在變化的復雜性而產(chǎn)生的潛在副作用進行分析，則BP4的打分不能為F。

[SUP.10.RC.5] If the technical content of the change request or in case of alterntives the decision for one alternative is not properly documented the indicator BP4 should be downrated.

老楊解讀：如果沒有正確記錄變更請求的技術內(nèi)容或備選方案的決策，則應降低BP4的打分。

[SUP.10.RL.5] If the review of implemented changes fails to detect that relevant processes are not applied; the indicator BP6 shall be downrated.

老楊解讀：如果對已實施的變更的評審未能檢測到相關過程未被應用，則應降低BP6的打分。

[SUP.10.RC.6] If the confirmation of a successful implementation of change requests is not based on documented criteria the indicator BP6 should be downrated.

老楊解讀：如果對成功執(zhí)行變更請求的確認不以文檔化的準則為依據(jù)，則應降低BP6的打分。

(4) 變更請求的狀態(tài)模型和工作流

ASPICE模型要求

SUP.10.BP3:記錄變更請求的狀態(tài) / Record the status of change requests

狀態(tài)模型的狀態(tài)被分配給每個變更請求以便于跟蹤

SUP.10.BP7: 跟蹤變更請求至關閉 / Track change requests to closure

跟蹤變更請求至關閉，并給變更發(fā)起者提供反饋。

[SUP.10.RL.6] If the strategy does not include the definition of a status model, workflow, criteria for status changes, stakeholders and their authorization, the indicator BP1 shall be downrated.

老楊解讀：如果策略中沒有包括狀態(tài)模型的定義、工作流、狀態(tài)遷移條件、相關方及其授權，則應降低BP1的打分。

[SUP.10.RL.7] If the status model and workflow does not fit to the actual way of working or is not applied correspondingly, the indicator BP3 must not be rated higher than P.

老楊解讀：如果狀態(tài)模型及工作流沒有被恰當?shù)膽没蚺c實際不符，則BP3的打分不能高于P。

[SUP.10.RC.7] If closed CRs do not reflect a final state, the indicator BP7 should be downrated.

老楊解讀：如果已關閉的變更請求不能反映出最終狀態(tài)，則應降低BP7的打分。

示例場景：狀態(tài)模型中定義了“已解決(Solved)”和“已關閉(Closed)”兩個狀態(tài)。但實際項目中無法進入“已關閉(Closed)”狀態(tài)

汽車軟件認證體系有哪些

汽車軟件的認證有：ASPICE和ISO 26262。

ASPICE是汽車軟件過程改進及能力評定。

ASPICE根據(jù)企業(yè)管理的細致和嚴謹程度不同，將企業(yè)的軟件研發(fā)能力劃分為6個級別。級別越高代表研發(fā)項目出現(xiàn)意外情況的可能性更低，企業(yè)對項目和產(chǎn)品的成功掌控力越強，越有能力按時向客戶交付高質(zhì)量的產(chǎn)品。

ISO 26262是一個定義安全生命周期的標準，用于在道路車輛的所有電氣和電子部件的設計、開發(fā)和測試期間實施安全實踐。

ISO26262標準是一套在軟件、硬件和系統(tǒng)層面上規(guī)范產(chǎn)品生命周期的步驟。汽車安全完整性等級（ASIL）是軟件或硬件組件的分類方案，表示其安全性的重要性。

ASPICE的評估范圍？

ASPICE將過程分成：主要生命周期過程、組織生命周期過程、支持生命周期過程。這三個過程分類中共包含32個過程域。

但由于考慮到性價比和項目范圍，通常評估時不會包括所有過程，而是根據(jù)被評估項目的具體情況選擇被評估的過程域。

目前國內(nèi)外主機廠在對供應商審核時通?？疾?6個過程域，當然，也有個別主機廠會對額外的過程有要求。

工作筆記 aspice基礎知識

最近給某OEM做了一次Automotive SPICE CL2評估，很多朋友就問我關于Automotive SPICE評估的一些事情。本文算是一個科普吧，給不太了解Automotive SPICE的人介紹一下Automotive SPICE和Automotive SPICE評估的事情。

1. Automotive SPICE

1.1? 什么是Automotive SPICE？

Automotive SPICE是一個”過程模型”，適用于”基于軟件的車載系統(tǒng)”的”設計開發(fā)過程”。過程模型是一個集合，是包含了與設計開發(fā)過程相關的優(yōu)秀實踐的集合。既然是一個集合，那就需要按照一定的結構把這些實踐組織起來：

方式一：按照實踐所屬的不同領域進行組織，比如有些實踐是和項目管理相關的，有些實踐是和軟件需求相關的，有些實踐是和軟件單元測試相關的….，不同的領域被稱為“過程”，這就是Automotive SPICE中的“過程緯度”。Automotive SPICE PAM V3.1中包括有32個過程。

方式二：按照做事情的方式進行組織，比如：依靠個人的經(jīng)驗來做，是能力度級別1（CL 1）的實踐；按照可管理的方式（活動管理和工作產(chǎn)品管理）來做，是能力度級別2（CL 2）的實踐；按照組織的要求來做，是能力度級別3（CL 3）的實踐….，這就是Automotive SPICE中的”能力度緯度”。

“能力度”是“過程的能力度”。如果說“某個項目達到了能力度2級”，是不準確的，應該說“某個項目中的某些過程達到了能力度2級”。同樣的，如果說某個組織達到了能力度2級，也是不準確的。

下圖是常見的體現(xiàn)評估結果的形式，評估范圍內(nèi)的過程，分別達到了什么樣的過程能力度。

1.2 怎么用Automotive SPICE？

Automotive SPICE是歐洲車廠在認識到軟件質(zhì)量的重要性之后，制定的一個規(guī)范。目的是希望其供應商能按照Automotive SPICE的要求進行產(chǎn)品的設計開發(fā)，以提供高質(zhì)量的產(chǎn)品。

Automotive SPICE中包括有那么多的過程，那么OEM對供應商的具體要求是什么呢？要求供應商需要應用哪些過程，這些過程需要達到幾級呢？

一般來說，OEM不會要求供應商去遵守Automotive SPICE的所有過程的，為什么呢？

性價比！

實施Automotive SPICE的成本，評估的成本，最后都是產(chǎn)品成本，OEM是需要買單的。

所以OEM會基于其對軟件質(zhì)量的理解，選擇最重要的過程來要求其供應商。

起初的時候，不同的OEM有不同的使用Automotive SPICE的觀點，形成氣候的，如下圖所示：

說明：

HIS是Audi AG, BMW, DaimlerChrysler, Porsche, Volkswagen成立的制定軟件開發(fā)規(guī)則的組織

如上的過程劃分，是基于Automotive SPICE PAM V2.4/V2.5

逐漸的，各OEM的要求開始統(tǒng)一，目前逐漸形成了如下兩類：

說明：

2016年HIS組織解散了，VDA QMC（Automotive SPICE PAM V2.5及其以后版本的Owner）在2017年Automotive SPICE PAM V3.0發(fā)布時，將之前在業(yè)界應用非常廣泛的HIS Scope，改名定義為VDA Scope

如上的過程劃分，是基于Automotive SPICE PAM V3.0/V3.1

各個與汽車軟件相關的供應商在應用Automotive SPICE時，往往最終都是為了滿足OEM的要求，其應用Automotive SPICE的過程范圍及目標級別，遵照其所服務的OEM的要求。

2. Automotive SPICE評估

接下來我們談一談Automotive SPICE評估，在談Automotive SPICE評估之前，需要先談一談與Automotive SPICE相關的組織。

2.1 Automotive SPICE相關的組織

在Automotive SPICE領域，沒有機構去管理“評估”，只是有機構去管理“評估師”。這個管理評估師的機構就是iNTACS（國際評估師認證機構，INTernational Assessor Certification Scheme）。iNTACS定義了評估師的級別劃分，以及級別晉升和級別維持的條件。Automotive SPICE評估師的級別從低到高分別為：Provisional Assessor, Competent Assessor, Principal Assessor。

晉升到competent Assessor或Principal Assessor，或維持competent Assessor或Principal Assessor資質(zhì)時，其條件之一就是需要實施Automotive SPICE評估：

作為Assessor晉升證據(jù)（或維持資質(zhì)的證據(jù)）的評估要求包括：

評估由至少2個評估師來實施，評估組組長需要Competent Assessor或Principal Assessor，評估組組員可以是Provisional Assessor或Competent Assessor或Principal Assessor

評估的過程范圍至少包括項目管理相關的過程、支持類相關的過程和工程類相關的過程

評估的時間需要至少50小時

2.2 Automotive SPICE評估的類型

在1次Automotive SPICE評估時，Automotive SPICE相當于評估的準則（Criteria），而還需要有評估方法，根據(jù)所選擇的評估方法不同，Automotive SPICE評估分為兩種類型，一種是項目能力度評估，一種是組織成熟度評估。

項目能力度評估

遵照ISO/IEC 15504-2 Performing an assessment實施的評估，是項目能力度評估。在這類評估中，是由Sponsor（發(fā)起評估的人）確定評估的模型范圍（選擇哪些過程，這些過程需要評估到幾級）、項目范圍（評估哪個項目），而Assessor是根據(jù)Sponsor的要求實施評估。

（企業(yè)想評價哪個項目，評價哪個過程，評價到幾級，不是Assessor決定的?。?/p>

組織成熟度評估

ISO/IEC 15504-7 TR Assessment of organizational maturity定義的是組織成熟度評估的評估方法，在組織成熟度評估時：Sponsor確定被評估的組織，以及目標級別；由Assessor根據(jù)對被評估組織進行分析，之后進行項目抽樣（使得被抽樣的項目能代表整個組織的水平），然后通過對被抽樣項目進行預定義過程的評估，進而得出組織的過程成熟度水平。

簡單來說：在組織成熟度評估時，是由Assessor確定被評估的項目，而過程范圍也是需要預定義的（應該由Automotive SPICE的Owner來定義，詳細的原因，這里不再贅述，讀者可以思考思考~~）

組織成熟度評估在業(yè)界很少被用到，主要的原因是OEM不太認可組織成熟度評估的方式。我分析有兩個原因：

OEM更關注的是供應商為其開發(fā)的項目的情況如何，而不關注供應商的組織

Automotive SPICE的業(yè)界大咖們不希望Automotive SPICE因為組織成熟度的評估方式而商業(yè)化（Automotive SPICE還是很高冷的，不像CMMI那么商業(yè)化）

基于如上原因ISO/IEC 15504-7在2008年發(fā)布之后，至今也還是TR，始終不是一個正式的ISO標準，本文后續(xù)的描述，不再討論組織成熟度評估。

注：此處的標準號都是15504，15504系列標準正在被330XX標準所替代。

2.3 被認可的Automotive SPICE評估

什么樣的Automotive SPICE評估才是正式的評估，或者說是被認可的評估呢？

經(jīng)常經(jīng)常有人問我這個問題，但這個問題的題干是不完全的。

是被誰認可的評估呢？

舉個例子：如果需要OEM A認可的評估，那么這個認可的條件就需要OEM A來定義。OEM A可以指定某個專業(yè)的軟件過程專家（該專家可能不具備任何Automotive SPICE的Assessor資質(zhì)），然后只要是該專家實施的評估，OEM A都認可。

所以說，這個問題不能問我，你應該去問那個“誰”

這么分析問題，有點杠精的行為了~~

正式的評估或者被認可的評估，在Automotive SPICE領域引申是指“可以做為Assessor資質(zhì)維持或資質(zhì)晉升的證據(jù)的評估”，那這樣的評估需要滿足什么條件呢？這個答案就是在前文（2.1節(jié)）中的闡述。

只要滿足2.1節(jié)所闡述的條件的評估，就可以認為是一個正式的評估和受認可的評估。與實施評估的組織是無關的哦~~，對嗎？

2.4 Automotive SPICE評估結果的有效性和有效期

Automotive SPICE評估是在某個時間點，對某個項目中已經(jīng)實施的過程的能力度進行的評估，評估結果是代表了歷史上的某個項目，在歷史上的某個時間點的過程能力情況。

評估結果只是對被評估項目有效，對其它項目是無效的。

在VDA Guideline中，增加了12個月有效期的說法：在被評估項目中，如果沒有發(fā)生變更，則可以認為評估結果在12個月之內(nèi)是有效的（這個有效是對同一個被評估項目來說的）；這里的變更是指過程的變更，包括：開發(fā)地點的變更、團隊組織結構的調(diào)整、人員的更替、開發(fā)過程的調(diào)整等。

雖然某一次Automotive SPICE評估結果只是對被評估的項目有效，對其它的項目無效。但該次評估結果也往往還是可以在一定程度上反映其它項目的過程能力，特別是當其它項目與被評估項目在項目特征上一致時。

1）比如：某個OEM在考察供應商時，供應商展示了3個月之前實施的一次Automotive SPICE評估結果，則OEM可能會認為：“既然是在這么短的時間之前做的評估，那么該評估結果能代表企業(yè)目前的能力”（接受）。如果供應商展示了10年之前實施的一次Automotive SPICE評估結果，則OEM可能會認為：“這是太久之前的一次評估，很難代表企業(yè)現(xiàn)在的能力”（不接受）。3個月的時間可以接受，10年的時間不可以接受，那么中間的臨界時間點在哪里呢？沒有答案哦~~

2）不同的Automotive SPICE能力度級別也會對評估結果的有效性產(chǎn)生影響。

Automotive SPICE能力度二級時，具備相同項目特征的項目之間，其項目過程可以是不一致的；Automotive SPICE能力度三級時，具備相同項目特征的項目之間，其項目過程是一致的，都是遵照了標準的組織過程?；诖?，企業(yè)的某個項目的某些過程如果達成了Automotive SPICE能力度三級，則客戶可能會相信其它項目的過程能力也是如此的。

2.5 評估通過證書

當?shù)谌綑C構在為某企業(yè)實施了Automotive SPICE評估之后，如果評估范圍內(nèi)的過程都達到了目標級別，則第三方機構會應被評估組織的要求，發(fā)一個通過Automotive SPICE評估的證書。

注：評估通過證書不是Automotive SPICE評估所要求的。是被評估組織為了其Marketing及Business目的，而要求評估機構頒發(fā)的。

Automotive SPICE評估通過證書是Automotive SPICE評估結果的Summary，雖然不同的第三方機構，頒發(fā)證書的格式和內(nèi)容都不盡相同，但為了能客觀全面的反映評估結果，一般需要包括如下信息：

被評估的組織及部門（是對某個部門下的項目進行的評估，項目所在的具體部門信息需要體現(xiàn)出來）

評估所遵照的Automotive SPICE模型信息，目標級別

評估方法

評估的項目名稱，及評估的過程范圍，評估日期

實施評估的組織

評估組組長信息及簽名

工作筆記 ?ASPICE?VDA?Guideline解讀(20)：MAN.3?項目管理

項目管理過程的目的是在項目需求和約束的背景下, 識別、建立和控制項目生成產(chǎn)品所必需的活動和資源。

簡單來說是指：通過對項目實施所必要活動（必要活動能保證輸出質(zhì)量） 和 資源（人力資源、設備資源等）的管理，使項目能達成既定的項目目標，如時間目標、質(zhì)量目標、成本目標等。

接下來我們來看一下VDA Guideline中的相關規(guī)則：

(1) 工作范圍

ASPICE模型要求

MAN.3.BP1: 定義工作范圍 / Define the scope of work

確定項目的目標、動機和邊界

Identify the project's goals, motivation and boundaries.

項目的工作范圍包括項目范圍和產(chǎn)品范圍；項目的內(nèi)容、邊界、限制、項目目標等。

[MAN.3.RL.1] If the scope of work (BP1) is a product description only, the indicator BP1 must not be rated higher than L.

老楊解讀：如果工作范圍僅僅是產(chǎn)品描述，則BP1的打分不能高于L。

[MAN.3.RC.1] If the scope of work (BP1) does not address the responsibilities of all affected parties regarding the project and product, the indicator BP1 should not be rated higher than L.

老楊解讀：如果工作范圍沒有考慮所有項目和產(chǎn)品的相關方的責任劃分，則BP1的打分不能高于L。

[MAN.3.RL.2] If the scope of work (BP1) is not appropriately documented at project start, the indicator BP1 must not be rated higher than L.

老楊解讀：如果工作范圍沒有在項目開始時文檔化，則BP1的打分不能高于L。

(2) 承諾

ASPICE模型要求

MAN.3.BP1: 定義工作范圍 / Define the scope of work

確定項目的目標、動機和邊界

Identify the project's goals, motivation and boundaries.

MAN.3.BP3: 評估項目的可行性 / Evaluate feasibility of the project

在時間、項目估計和可用資源范圍內(nèi)，在技術限制的范圍內(nèi)，評估實現(xiàn)項目目標的可行性。

Evaluate the feasibility of achieving the goals of the project in terms of technical feasibility within constraints with respect to time, project estimates, and available resources.

MAN.3.BP5: 定義、監(jiān)控和調(diào)整項目估計和資源 / Define, monitor and adjust project estimates and resources

根據(jù)項目目標、項目風險、項目理由和邊界，定義、監(jiān)控和調(diào)整項目工作量和資源的估計。

Define, monitor, and adjust project estimates of effort and resources based on project's goals, project risks, motivation and boundaries

MAN.3.BP8: 定義、監(jiān)控和調(diào)整項目進度 / Define, monitor and adjust project schedule

為活動分配資源，并安排整個項目中的每一項活動的日程安排。在項目生命周期內(nèi)，項目日程安排必須持續(xù)更新。

Allocate resources to activities, and schedule each activity of the whole project. The schedule has to be kept continuously updated during lifetime of the project.

[MAN.3.RC.2] If the commitment is not fulfilled by delaying the timeline of the project or by cancelling functionality etc., the indicators BP1 and BP3 should not be rated higher than L.

老楊解讀：如果未能通過延遲項目時間或取消功能等方式履行承諾，則BP1和BP3的打分不應高于L。

[MAN.3.RL.3] If the commitment is not fulfilled by delaying the timeline of the project or by cancelling functionality etc., the indicator BP5 and BP8 must not be rated higher than L.

老楊解讀：如果未能通過延遲項目時間或取消功能等方式履行承諾，則BP5和BP8的打分不應高于L。

注：與相關方達成一致后的項目交付時間延遲或功能取消是可以的。

(3) 活動定義

ASPICE模型要求

MAN.3.BP4: 定義、監(jiān)控和調(diào)整項目活動 / Define, monitor and adjust project activities

根據(jù)定義的項目生命周期和預估，定義、監(jiān)視和調(diào)整項目活動及其依賴關系。根據(jù)需要調(diào)整活動及其依賴關系。

Define, monitor and adjust project activities and their dependencies according to defined project life cycle and estimations. Adjust activities and their dependencies as required

MAN.3.BP8: 定義、監(jiān)控和調(diào)整項目進度 / Define, monitor and adjust project schedule

為活動分配資源，并安排整個項目中的每一項活動的日程安排。在項目生命周期內(nèi)，項目日程安排必須持續(xù)更新。

Allocate resources to activities, and schedule each activity of the whole project. The schedule has to be kept continuously updated during lifetime of the project.

[MAN.3.RC.3] If the activities are not described with input and output artifacts, the indicator BP4 should not be rated higher than P.

老楊解讀：如果活動定義中未包括輸入和輸出，則BP4的打分不能高于P。

[MAN.3.RC.4] If the dependencies between activities are not identified, the indicator BP4 should not be rated higher than L.

老楊解讀：如果未識別活動之間的依賴關系，則BP4的打分不能高于L。

[MAN.3.RC.5] If the work packages are too big (e.g. longer than the update cycle for the schedule), the indicator BP8 should be down-rated.

老楊解讀：如果工作包的顆粒度太大（如：大于Schedule的更新周期），則BP8的打分應降低。

注：Schedule中Work Package的顆粒度需要小于項目的監(jiān)控周期(如：周），如果存在特殊的Case，無法拆分，則也不能超過2個項目監(jiān)控周期。

(4) 工作量和資源估計

ASPICE模型要求

MAN.3.BP5: 定義、監(jiān)控和調(diào)整項目估計和資源 / Define, monitor and adjust project estimates and resources

根據(jù)項目目標、項目風險、項目理由和邊界，定義、監(jiān)控和調(diào)整項目工作量和資源的估計。

Define, monitor, and adjust project estimates of effort and resources based on project's goals, project risks, motivation and boundaries

[MAN.3.RC.6] If the estimation method used is not comprehensible, the indicator BP5 should not be rated higher than P.

老楊解讀：如果使用的估計方法是不可理解的，則BP5的打分不能高于P。

[MAN.3.RC.7] If the estimates are too high level, e.g. based on high-level packages rather than on actual activities, the indicator BP5 should not be rated higher than P.

老楊解讀：如果估計的顆粒度太高，如：基于高層次的工作包，而不是基于實際的活動，則BP5的打分不能高于P。

[MAN.3.RC.8] If there are not sufficient resources to cover the estimated effort, the indicator BP5 should not be rated higher than P.

老楊解讀：如果缺少足夠的資源來滿足預計的工作量，則BP5的打分不能高于P。

[MAN.3.RC.9] If the resources are sufficient to cover the estimates but a monitoring of actual effort versus the estimates is missing, the indicator BP5 should not be rated higher than L.

老楊解讀：如果有足夠的資源來滿足預計的工作量，但是缺少對工作量的監(jiān)控，則BP5的打分不能高于L。

[MAN.3.RC.10] If the rationale for the estimates is missing, the indicator BP5 should not be rated higher than L.

老楊解讀：如果缺失估計的必要理由，則BP5的打分不能高于L。

(5) 變更請求和問題解決(缺陷解決)的估計

ASPICE模型要求

MAN.3.BP2: 定義項目的生命周期 / Define project life cycle

定義項目的生命周期，與項目的范圍、上下文、量級和復雜程度相適應。

Define the life cycle for the project, which is appropriate to the scope, context, magnitude and complexity of the project.

MAN.3.BP4: 定義、監(jiān)控和調(diào)整項目活動 / Define, monitor and adjust project activities

根據(jù)定義的項目生命周期和預估，定義、監(jiān)視和調(diào)整項目活動及其依賴關系。根據(jù)需要調(diào)整活動及其依賴關系。

Define, monitor and adjust project activities and their dependencies according to defined project life cycle and estimations. Adjust activities and their dependencies as required

MAN.3.BP5: 定義、監(jiān)控和調(diào)整項目估計和資源 / Define, monitor and adjust project estimates and resources

根據(jù)項目目標、項目風險、項目理由和邊界，定義、監(jiān)控和調(diào)整項目工作量和資源的估計。

Define, monitor, and adjust project estimates of effort and resources based on project's goals, project risks, motivation and boundaries

MAN.3.BP8: 定義、監(jiān)控和調(diào)整項目進度 / Define, monitor and adjust project schedule

為活動分配資源，并安排整個項目中的每一項活動的日程安排。在項目生命周期內(nèi)，項目日程安排必須持續(xù)更新。

Allocate resources to activities, and schedule each activity of the whole project. The schedule has to be kept continuously updated during lifetime of the project.

[MAN.3.RC.11] If the definition of activities, effort and resource estimation, and the preparation of schedule(s) do not sufficiently reflect expectable change requests and problem resolution, the indicators BP4, BP5 and BP8 should be downrated.

老楊解讀：如果在活動定義、工作量和資源估計、制定進度表等方面沒有充分反映對變更請求或缺陷解決方面的考慮，則BP4, BP5, BP8的打分應降低。

[MAN.3.RC.12] If the project lifecycle does not contain phases that allow for addressing change requests and problem resolution, the indicator BP2 should be downrated.

老楊解讀：如果項目生命周期中未考慮處理變更請求和缺陷解決的階段，那么應該降低BP2的打分。

(6) 進度與跟蹤

ASPICE模型要求

MAN.3.BP4: 定義、監(jiān)控和調(diào)整項目活動 / Define, monitor and adjust project activities

根據(jù)定義的項目生命周期和預估，定義、監(jiān)視和調(diào)整項目活動及其依賴關系。根據(jù)需要調(diào)整活動及其依賴關系。

Define, monitor and adjust project activities and their dependencies according to defined project life cycle and estimations. Adjust activities and their dependencies as required

MAN.3.BP5: 定義、監(jiān)控和調(diào)整項目估計和資源 / Define, monitor and adjust project estimates and resources

根據(jù)項目目標、項目風險、項目理由和邊界，定義、監(jiān)控和調(diào)整項目工作量和資源的估計。

Define, monitor, and adjust project estimates of effort and resources based on project's goals, project risks, motivation and boundaries

MAN.3.BP7: 識別、監(jiān)控和調(diào)整項目的接口和承諾 / Identify, monitor and adjust project interfaces and agreed commitments

項目與其它（子）項目、組織單元和其它受影響的利益相關者的接口，需要確定并達成一致，并監(jiān)督已商定的承諾。

Identify and agree interfaces of the project with other (sub-) projects, organizational units and other affected stakeholders and monitor agreed commitments.

MAN.3.BP8: 定義、監(jiān)控和調(diào)整項目進度 / Define, monitor and adjust project schedule

為活動分配資源，并安排整個項目中的每一項活動的日程安排。在項目生命周期內(nèi)，項目日程安排必須持續(xù)更新。

Allocate resources to activities, and schedule each activity of the whole project. The schedule has to be kept continuously updated during lifetime of the project.

MAN.3.BP9: 確保一致性 / Ensure consistency

確保項目計劃的各部分之間的一致性，包括：項目估計、人員技能、活動、日程安排、相關方之間的接口和承諾。

Ensure that estimates, skills, activities, schedules, plans, interfaces, and commitments for the project are consistent across affected parties

MAN.3.BP10: 項目評審和項目進展報告 / Review and report progress of the project

定期評審和向所有相關方報告項目狀態(tài)，關于項目活動在預計的工作量和日程上的達成情況。防止發(fā)現(xiàn)問題再次發(fā)生。

Regularly review and report the status of the project and the fulfillment of activities against estimated effort and duration to all affected parties. Prevent recurrence of problems identified.

[MAN.3.RC.13] If action items or corrective actions are not properly tracked to closure, the corresponding indicators BP4, BP5, BP7, BP8 and/or BP10 should be downrated.

老楊解讀：如果行動項或糾正措施沒有恰當?shù)母欀敝陵P閉，相應的BP4, BP5, BP7及BP10的打分應降低。

[MAN.3.RL.4] If the schedule is not based on the defined activities (BP4) and estimations (BP5), the indicators BP8 and BP9 must not be rated higher than P.

老楊解讀：如果Schedule沒有基于已定義的活動(BP4)和估計(BP5)，則BP8和BP9的打分不能高于P。

[MAN.3.RL.5] If the schedule does not contain all of the following:

a start and end date,

duration,

degree of fulfillment (for monitoring purposes),

resources,

dependencies

the indicator BP8 must not be rated higher than L.

老楊解讀：如果Schedule中沒有包括：開始和結束時間、持續(xù)時間、進展完成情況、資源、依賴，則BP8的打分不能高于L。

[MAN.3.RL.6] If any of the following:

start and end date,

effort,

degree of fulfillment

is missing, the indicator BP8 must not be rated higher than P.

老楊解讀：如果缺失"開始和結束時間"、"工作量"和"進展完成情況"，則BP8的打分不能高于P。

[MAN.3.RL.7] If the schedule is changed without a documented reason, or the change is not documented, the indicator BP8 shall be downrated.

老楊解讀：如果Schedule發(fā)生了變更但缺少文檔化的原因，或變更沒有被記錄，則BP8的打分應降低。

[MAN.3.RL.8] If the degree of activity fulfillment as tracked in the schedule is not up to date (at least biweekly depending on the project scope and release plan), the indicator BP8 shall be downrated.

老楊解讀：如果活動的進展沒有在Schedule中及時更新，則BP8的打分應降低。

[MAN.3.RL.9] If the critical path in a schedule is not determined, the indicator BP8 shall be downrated.

老楊解讀：如果未確定Schedule中的關鍵路徑，則BP8的打分應降低。

(7) 項目實際進展

ASPICE模型要求

MAN.3.BP10: 項目評審和項目進展報告 / Review and report progress of the project

定期評審和向所有相關方報告項目狀態(tài)，關于項目活動在預計的工作量和日程上的達成情況。防止發(fā)現(xiàn)問題再次發(fā)生。

Regularly review and report the status of the project and the fulfillment of activities against estimated effort and duration to all affected parties. Prevent recurrence of problems identified.

[MAN.3.RL.10] If monitoring does not assess the correlation of actual consumption of resources, meeting of deadlines and fulfillment of activities (i.e. progress of content), the indicator BP10 must not be rated higher than P.

老楊解讀：如果在項目監(jiān)控時，沒有考慮資源的實際消耗、最后期限的滿足和活動的完成（即內(nèi)容的進度）之間的相關性，則BP10的打分不能高于P。

(8) 發(fā)布管理

ASPICE模型要求

MAN.3.BP4: 定義、監(jiān)控和調(diào)整項目活動 / Define, monitor and adjust project activities

根據(jù)定義的項目生命周期和預估，定義、監(jiān)視和調(diào)整項目活動及其依賴關系。根據(jù)需要調(diào)整活動及其依賴關系。

Define, monitor and adjust project activities and their dependencies according to defined project life cycle and estimations. Adjust activities and their dependencies as required

MAN.3.BP7: 識別、監(jiān)控和調(diào)整項目的接口和承諾 / Identify, monitor and adjust project interfaces and agreed commitments

項目與其它（子）項目、組織單元和其它受影響的利益相關者的接口，需要確定并達成一致，并監(jiān)督已商定的承諾。

Identify and agree interfaces of the project with other (sub-) projects, organizational units and other affected stakeholders and monitor agreed commitments.

MAN.3.BP8: 定義、監(jiān)控和調(diào)整項目進度 / Define, monitor and adjust project schedule

為活動分配資源，并安排整個項目中的每一項活動的日程安排。在項目生命周期內(nèi)，項目日程安排必須持續(xù)更新。

Allocate resources to activities, and schedule each activity of the whole project. The schedule has to be kept continuously updated during lifetime of the project.

[MAN.3.RL.11] If product release recipients are not considered as stakeholders, the indicator BP7 must not be rated higher than P.

老楊解讀：如果產(chǎn)品發(fā)布的接受者沒有被考慮為相關方，則BP7的打分不能高于P。

[MAN.3.RL.12] If product release deadlines or milestones are not reflected in schedules (consider also consistency across different schedules), the indicator BP8 must not be rated higher than P.

老楊解讀：如果產(chǎn)品發(fā)布的時間點或里程碑沒有在Schedule中考慮，則BP8的打分不能高于P。

[MAN.3.RL.13] If the scope of the current and next release is not identified in detail (features and/or functions per release), the indicators BP7 and BP8 must not be rated higher than P.

老楊解讀：如果當前發(fā)布及下一次發(fā)布的范圍沒有被詳細識別(每次發(fā)布的功能點)，則BP7和BP8的打分不能高于P。

[MAN.3.RL.14] If the mid and long-term planning of the releases does not at least cover a latest release/milestone for features and/or functions, the indicators BP7 and BP8 must not be rated higher than L.

老楊解讀：如果中期計劃或長期計劃中沒有覆蓋到當前發(fā)布或里程碑，則BP7和BP8的打分不能高于L。

[MAN.3.RL.15] If for the current and next release not all the expected activities are planned and tracked (without a good reason), the indicators BP4, BP7 and BP8 shall not be rated higher than L. If less than 50% of the expected activities are planned, BP4, BP7, BP8 must not be rated higher than P.

老楊解讀：如果當前發(fā)布及下一次發(fā)布中的所有活動沒有被完全策劃（且沒有合適理由），則BP4, BP7和BP8的打分不能高于L；如果少于50%的活動沒有策劃，則BP4, BP7和BP8的打分不能高于P。

(9) 一致性

ASPICE模型要求

MAN.3.BP9: 確保一致性 / Ensure consistency

確保項目計劃的各部分之間的一致性，包括：項目估計、人員技能、活動、日程安排、相關方之間的接口和承諾。

Ensure that estimates, skills, activities, schedules, plans, interfaces, and commitments for the project are consistent across affected parties

[MAN.3.RC.14] If links between different types of planning information are not supported by tools, this should not be used to downrate the indicator BP9.

老楊解讀：如果項目計劃相關的不同類型的信息之間的關聯(lián)性不是依賴于工具，則不能基于此降低BP9的打分。

[MAN.3.RL.15] If the correlation between different plans or between estimates and plans is too high level or weak, the indicator BP9 shall be downrated.

老楊解讀：如果項目計劃相關的不同類型的信息之間的關聯(lián)性的層次太高，則應降低BP9的打分。

(10) 風險

ASPICE模型要求

MAN.3.BP3: 評估項目的可行性 / Evaluate feasibility of the project

在時間、項目估計和可用資源范圍內(nèi)，在技術限制的范圍內(nèi)，評估實現(xiàn)項目目標的可行性。

Evaluate the feasibility of achieving the goals of the project in terms of technical feasibility within constraints with respect to time, project estimates, and available resources.

MAN.3.BP5: 定義、監(jiān)控和調(diào)整項目估計和資源 / Define, monitor and adjust project estimates and resources

根據(jù)項目目標、項目風險、項目理由和邊界，定義、監(jiān)控和調(diào)整項目工作量和資源的估計。

Define, monitor, and adjust project estimates of effort and resources based on project's goals, project risks, motivation and boundaries

MAN.3.BP6: 確保所需的技能，知識和經(jīng)驗 / Ensure required skills, knowledge, and experience

根據(jù)估計，確定項目所需的技能、知識和經(jīng)驗，并確保選定的個人和團隊及時具備這些技能和知識。

Identify the required skills, knowledge, and experience for the project in line with the estimates and make sure the selected individuals and teams either have or acquire these in time.

[MAN.3.RC.15] If risks regarding feasibility are not considered, the indicator BP3 should be downrated.

老楊解讀：如果未考慮與項目可行性相關的風險，則應降低BP3的打分。

[MAN.3.RC.16] If risks regarding estimates or resources are not considered, the indicator BP5 should be downrated.

老楊解讀：如果未考慮與工作量估計及資源相關的風險，則應降低BP5的打分。

[MAN.3.RC.17] If risks regarding skills or knowledge are not considered, the indicator BP6 should be downrated.

老楊解讀：如果未考慮人員技能和知識相關的風險，則應降低BP6的打分。

工作筆記ASPICE VDA Guideline解讀(19)：SUP.8 配置管理

配置管理過程的目的是建立和維護過程或項目的所有工作產(chǎn)品的完整性。

什么是“工作產(chǎn)品的完整性”呢？

下圖是"SWAD(軟件架構設計)"工作產(chǎn)品的創(chuàng)建和維護過程，其每一次變更（如：從Baselined 1.0 -- Baselined 2.0）是可控的，其相關聯(lián)的上下游基線是明確的。這樣就可以說保證了"SWAD(軟件架構設計)"的完整性。

1) 配置管理策略

ASPICE模型要求

SUP.8.BP1: 制定配置管理策略 / Develop a configuration management strategy

制定配置管理策略，包括：/ Develop a configuration management strategy, including

職責 / responsibilities

工具和配置庫 / tools and repositories

配置項(識別的)準則 / criteria for configuration items

命名規(guī)約 / naming conventions

訪問權限 / access rights

基線準則 / criteria for baselines

合并和分支策略 / merge and branch strategy

配置項的修訂歷史方式 / the revision history approach for configuration items

配置管理策略包括：

a) 配置管理的范圍需覆蓋項目中的各學科(如：軟件、硬件)、各地點、各過程(如管理過程、支持過程、工程過程等)

b) 制定整體策略，覆蓋各學科、各過程及各地點等

c) 定義訪問權限

d) 根據(jù)項目的復雜度定義所需的活動和工具

e) 定義配置項的識別準則及命名規(guī)約

f) 定義配置項的修訂條件

g) 定義基線策略

h) 定義Variant及分支策略

i) 定義配置項變更歷史的方式

[SUP.8.RL.1] If the strategy does not include all aspects above, the indicator BP1 must not be rated F.

老楊解讀：如果策略中沒有包括上述的各點，則BP1不能判定為F。

[SUP.8.RL.2] If there is no dedicated configuration management system defined in the strategy but the procedure is adequate for the complexity of the product to be developed this must not be used to downrate the indicator BP1.

老楊解讀：如果沒有專門的配置管理系統(tǒng)，但所建立的配置管理程序是滿足產(chǎn)品復雜度的，則不能基于此來降低BP1的打分。

[SUP.8.RL.3] If major configuration management aspects (according to d) or e)) are missing in the strategy the indicator BP1 must not be rated higher than P.

老楊解讀：如果配置管理的主要方面（如上述的d)或e)）是缺失的，則BP1的打分不能高于P

[SUP.8.RL.4] If major baselining aspects (according to g)) are missing in the strategy the indicator BP1 must not be rated higher than P.

老楊解讀：如果策略中缺少主要的基線方面的考慮（上述的g)），則BP1的打分不能高于P。

[SUP.8.RL.5] If major branching and merging aspects (according to h)) are missing in the strategy the indicator BP1 must not be rated higher than P.

老楊解讀：如果策略中缺少主要的分支和合并方面的考慮（上述的h)），則BP1的打分不能高于P。

[SUP.8.RC.1] If there is only an adequate generic strategy but no project specific implementation, the indicator BP1 should not be down-rated.

老楊解讀：如果有一個適當?shù)耐ㄓ貌呗裕鴽]有為項目定義特定的策略，那么BP1的打分不應該被降低。

(2) 基線

ASPICE模型要求

SUP.8.BP6: 建立基線 / Establish baselines

根據(jù)配置管理策略建立基線，以滿足內(nèi)部目的和外部交付

Establish baselines for internal purposes and for external delivery according to the configuration management strategy

SUP.8.BP8: 驗證配置項的信息 / Verify the information about configured items

驗證配置項及其基線的信息是否完整，并確?；€的一致性。

Verify that the information about configured items, and their baselines is complete and ensure the consistency of baselines.

基線需要：

a) 定義基線中所包括的配置項

b) 根據(jù)策略創(chuàng)建必要的內(nèi)外部基線

c) 創(chuàng)建跨不同學科、地點和過程的整體基線，并保證其之間的一致性

d) 基線中應包括再現(xiàn)工作產(chǎn)品的完整和一致的配置項集合

e) 根據(jù)策略中定義的命名規(guī)范創(chuàng)建基線

[SUP.8.RL.6] If it is not defined for each kind of baseline which configuration items are to be controlled, the indicator BP6 must not be rated higher than P.

老楊解讀：如果基線中沒有識別出所有的需要被控制的配置項，則BP6的打分不能高于P。

[SUP.8.RL.7] If established baselines for different disciplines, sites, processes etc. (according to c) are not consistent or if overall baselines do not exist, the indicator BP6 shall be downrated.

老楊解讀：如果創(chuàng)建的跨不同學科、地點和過程的整體基線(上述的c))之間是不一致的，或不存在，則應降低BP6的打分。

[SUP.8.RL.8] If content of a baseline is not verified (by e.g., a baseline or configuration management audit), the indicator BP8 shall be downrated.

老楊解讀：如果基線的內(nèi)容未進行驗證，則應降低BP8的打分。

[SUP.8.RC.2] If the defined naming convention for baselines is not used, the indicator BP6 should be downrated.

老楊解讀：如果未使用已定義的命名規(guī)范，則應降低BP6的打分。

(3) 分支與合并

ASPICE模型要求

SUP.8.BP4: 建立分支管理 / Establish branch management

根據(jù)配置管理策略建立分支管理，分支管理適用于使用同一基礎進行并行開發(fā)時

Establish branch management according to the configuration management strategy where applicable for parallel developments that use the same base.

SUP.8.BP8: 驗證配置項的信息 / Verify the information about configured items

驗證配置項及其基線的信息是否完整，并確?；€的一致性。

Verify that the information about configured items, and their baselines is complete and ensure the consistency of baselines.

[SUP.8.RL.9] If branches are not created according to the strategy, the indicator BP4 shall be downrated.

老楊解讀：如果未基于策略創(chuàng)建分支，則應降低BP4的打分。

[SUP.8.RL.10] If consistency and completeness of merged items or sets of items is not ensured, the indicator BP8 must not be rated F.

老楊解讀：如果不能確保合并項的一致性和完全性，則BP8的打分不能是F。

(4) 配置管理基礎設施

ASPICE模型要求

SUP.8.BP3: 建立配置管理系統(tǒng) / Establish a configuration management system

根據(jù)配置管理策略建立配置管理系統(tǒng)

Establish a configuration management system according to the configuration management strategy

SUP.8.BP9: 管理配置項和基線的存儲 / Manage the storage of configuration items and baselines

通過適當?shù)恼{(diào)度和資源存儲保證配置項和基線的完整性和可用性，對使用的CM系統(tǒng)歸檔（長期保存）和備份

Ensure the integrity and availability of configuration items and baselines through appropriate scheduling and resourcing of storage, archiving (long term storage) and backup of the used CM systems.

配置管理基礎設施需要：

a) 支持策略中定義的配置管理程序，包括訪問權限

b) 適合于已定義的復雜度，包括適用于多地、項目規(guī)模、多項目或多變體應用等。

c) 了解所用的IT服務(如：文件共享、工具等)屬性，比如存儲、歸檔、備份，并與項目需求進行比較。識別差異并采取糾正措施

[SUP.8.RL.11] If the established infrastructure is not able to support the procedures (according to a)) or the complexity (according to b)), the indicator BP3 shall be downrated.

老楊解讀：如果已建立的基礎設施不能支持配置管理程序(上述的a))，或項目復雜度(上述的b))，則應降低BP3的打分。

[SUP.8.RL.12] If there is no dedicated configuration management system in place but the established procedure is adequate for the complexity of the product to be developed this must not be used to downrate the indicator BP3.

老楊解讀：如果沒有專門的配置管理系統(tǒng)，但所建立的配置管理程序是滿足產(chǎn)品復雜度的，則不能基于此來降低BP3的打分。

[SUP.8.RL.13] If properties of used IT services are not known, or known but in case of deviations from project requirements no corrective actions are established, the indicator BP9 shall be downrated.

老楊解讀：如果IT服務的情況是未知的，或存在偏差但無糾正措施，則應降低BP9的打分。

aspice軟件開發(fā)組織架構的介紹就聊到這里吧，感謝你花時間閱讀本站內(nèi)容，更多關于aspice軟件架構設計、aspice軟件開發(fā)組織架構的信息別忘了在本站進行查找喔。