aspice軟件開(kāi)發(fā)組織架構（軟件開(kāi)發(fā)公司架構）
今天給各位分享aspice軟件開(kāi)發(fā)組織架構的知識，其中也會(huì)對(duì)軟件開(kāi)發(fā)公司架構進(jìn)行解釋，如果能(néng)碰巧解決你現在面(miàn)臨的問題，别忘了關注本站，現在開(kāi)始吧！
本文目錄一覽：
- 1、工作筆記 aspice基礎知識
- 2、蜂巢智能(néng)轉向(xiàng)的軟件開(kāi)發(fā)怎麼(me)樣(yàng)？
- 3、aspice是什麼(me)意思啊
- 4、aspice2級要求權限怎麼(me)寫
- 5、工作筆記ASPICE VDA Guideline解讀(19)：SUP.8 配置管理
工作筆記 aspice基礎知識
最近給某OEM做了一次Automotive SPICE CL2評估，很多朋友就問我關于Automotive SPICE評估的一些事(shì)情。本文算是一個科普吧，給不太了解Automotive SPICE的人介紹一下Automotive SPICE和Automotive SPICE評估的事(shì)情。
1. Automotive SPICE
1.1 什麼(me)是Automotive SPICE？
Automotive SPICE是一個”過(guò)程模型”，适用于”基于軟件的車載系統”的”設計開(kāi)發(fā)過(guò)程”。過(guò)程模型是一個集合，是包含了與設計開(kāi)發(fā)過(guò)程相關的優秀實踐的集合。既然是一個集合，那就需要按照一定的結構把這(zhè)些實踐組織起(qǐ)來：
方式一：按照實踐所屬的不同領域進(jìn)行組織，比如有些實踐是和項目管理相關的，有些實踐是和軟件需求相關的，有些實踐是和軟件單元測試相關的….，不同的領域被(bèi)稱爲“過(guò)程”，這(zhè)就是Automotive SPICE中的“過(guò)程緯度”。Automotive SPICE PAM V3.1中包括有32個過(guò)程。
方式二：按照做事(shì)情的方式進(jìn)行組織，比如：依靠個人的經(jīng)驗來做，是能(néng)力度級别1（CL 1）的實踐；按照可管理的方式（活動管理和工作産品管理）來做，是能(néng)力度級别2（CL 2）的實踐；按照組織的要求來做，是能(néng)力度級别3（CL 3）的實踐….，這(zhè)就是Automotive SPICE中的”能(néng)力度緯度”。
“能(néng)力度”是“過(guò)程的能(néng)力度”。如果說“某個項目達到了能(néng)力度2級”，是不準确的，應該說“某個項目中的某些過(guò)程達到了能(néng)力度2級”。同樣(yàng)的，如果說某個組織達到了能(néng)力度2級，也是不準确的。
下圖是常見的體現評估結果的形式，評估範圍内的過(guò)程，分别達到了什麼(me)樣(yàng)的過(guò)程能(néng)力度。
1.2 怎麼(me)用Automotive SPICE？
Automotive SPICE是歐洲車廠在認識到軟件質量的重要性之後(hòu)，制定的一個規範。目的是希望其供應商能(néng)按照Automotive SPICE的要求進(jìn)行産品的設計開(kāi)發(fā)，以提供高質量的産品。
Automotive SPICE中包括有那麼(me)多的過(guò)程，那麼(me)OEM對(duì)供應商的具體要求是什麼(me)呢？要求供應商需要應用哪些過(guò)程，這(zhè)些過(guò)程需要達到幾級呢？
一般來說，OEM不會(huì)要求供應商去遵守Automotive SPICE的所有過(guò)程的，爲什麼(me)呢？
性價比！
實施Automotive SPICE的成(chéng)本，評估的成(chéng)本，最後(hòu)都(dōu)是産品成(chéng)本，OEM是需要買單的。
所以OEM會(huì)基于其對(duì)軟件質量的理解，選擇最重要的過(guò)程來要求其供應商。
起(qǐ)初的時候，不同的OEM有不同的使用Automotive SPICE的觀點，形成(chéng)氣候的，如下圖所示：
說明：
HIS是Audi AG, BMW, DaimlerChrysler, Porsche, Volkswagen成(chéng)立的制定軟件開(kāi)發(fā)規則的組織
如上的過(guò)程劃分，是基于Automotive SPICE PAM V2.4/V2.5
逐漸的，各OEM的要求開(kāi)始統一，目前逐漸形成(chéng)了如下兩(liǎng)類：
說明：
2016年HIS組織解散了，VDA QMC（Automotive SPICE PAM V2.5及其以後(hòu)版本的Owner）在2017年Automotive SPICE PAM V3.0發(fā)布時，將(jiāng)之前在業界應用非常廣泛的HIS Scope，改名定義爲VDA Scope
如上的過(guò)程劃分，是基于Automotive SPICE PAM V3.0/V3.1
各個與汽車軟件相關的供應商在應用Automotive SPICE時，往往最終都(dōu)是爲了滿足OEM的要求，其應用Automotive SPICE的過(guò)程範圍及目标級别，遵照其所服務的OEM的要求。
2. Automotive SPICE評估
接下來我們談一談Automotive SPICE評估，在談Automotive SPICE評估之前，需要先談一談與Automotive SPICE相關的組織。
2.1 Automotive SPICE相關的組織
在Automotive SPICE領域，沒(méi)有機構去管理“評估”，隻是有機構去管理“評估師”。這(zhè)個管理評估師的機構就是iNTACS（國(guó)際評估師認證機構，INTernational Assessor Certification Scheme）。iNTACS定義了評估師的級别劃分，以及級别晉升和級别維持的條件。Automotive SPICE評估師的級别從低到高分别爲：Provisional Assessor, Competent Assessor, Principal Assessor。
晉升到competent Assessor或Principal Assessor，或維持competent Assessor或Principal Assessor資質時，其條件之一就是需要實施Automotive SPICE評估：
作爲Assessor晉升證據（或維持資質的證據）的評估要求包括：
評估由至少2個評估師來實施，評估組組長(cháng)需要Competent Assessor或Principal Assessor，評估組組員可以是Provisional Assessor或Competent Assessor或Principal Assessor
評估的過(guò)程範圍至少包括項目管理相關的過(guò)程、支持類相關的過(guò)程和工程類相關的過(guò)程
評估的時間需要至少50小時
2.2 Automotive SPICE評估的類型
在1次Automotive SPICE評估時，Automotive SPICE相當于評估的準則（Criteria），而還(hái)需要有評估方法，根據所選擇的評估方法不同，Automotive SPICE評估分爲兩(liǎng)種(zhǒng)類型，一種(zhǒng)是項目能(néng)力度評估，一種(zhǒng)是組織成(chéng)熟度評估。
項目能(néng)力度評估
遵照ISO/IEC 15504-2 Performing an assessment實施的評估，是項目能(néng)力度評估。在這(zhè)類評估中，是由Sponsor（發(fā)起(qǐ)評估的人）确定評估的模型範圍（選擇哪些過(guò)程，這(zhè)些過(guò)程需要評估到幾級）、項目範圍（評估哪個項目），而Assessor是根據Sponsor的要求實施評估。
（企業想評價哪個項目，評價哪個過(guò)程，評價到幾級，不是Assessor決定的！）
組織成(chéng)熟度評估
ISO/IEC 15504-7 TR Assessment of organizational maturity定義的是組織成(chéng)熟度評估的評估方法，在組織成(chéng)熟度評估時：Sponsor确定被(bèi)評估的組織，以及目标級别；由Assessor根據對(duì)被(bèi)評估組織進(jìn)行分析，之後(hòu)進(jìn)行項目抽樣(yàng)（使得被(bèi)抽樣(yàng)的項目能(néng)代表整個組織的水平），然後(hòu)通過(guò)對(duì)被(bèi)抽樣(yàng)項目進(jìn)行預定義過(guò)程的評估，進(jìn)而得出組織的過(guò)程成(chéng)熟度水平。
簡單來說：在組織成(chéng)熟度評估時，是由Assessor确定被(bèi)評估的項目，而過(guò)程範圍也是需要預定義的（應該由Automotive SPICE的Owner來定義，詳細的原因，這(zhè)裡(lǐ)不再贅述，讀者可以思考思考~~）
組織成(chéng)熟度評估在業界很少被(bèi)用到，主要的原因是OEM不太認可組織成(chéng)熟度評估的方式。我分析有兩(liǎng)個原因：
OEM更關注的是供應商爲其開(kāi)發(fā)的項目的情況如何，而不關注供應商的組織
Automotive SPICE的業界大咖們不希望Automotive SPICE因爲組織成(chéng)熟度的評估方式而商業化（Automotive SPICE還(hái)是很高冷的，不像CMMI那麼(me)商業化）
基于如上原因ISO/IEC 15504-7在2008年發(fā)布之後(hòu)，至今也還(hái)是TR，始終不是一個正式的ISO标準，本文後(hòu)續的描述，不再讨論組織成(chéng)熟度評估。
注：此處的标準号都(dōu)是15504，15504系列标準正在被(bèi)330XX标準所替代。
2.3 被(bèi)認可的Automotive SPICE評估
什麼(me)樣(yàng)的Automotive SPICE評估才是正式的評估，或者說是被(bèi)認可的評估呢？
經(jīng)常經(jīng)常有人問我這(zhè)個問題，但這(zhè)個問題的題幹是不完全的。
是被(bèi)誰認可的評估呢？
舉個例子：如果需要OEM A認可的評估，那麼(me)這(zhè)個認可的條件就需要OEM A來定義。OEM A可以指定某個專業的軟件過(guò)程專家（該專家可能(néng)不具備任何Automotive SPICE的Assessor資質），然後(hòu)隻要是該專家實施的評估，OEM A都(dōu)認可。
所以說，這(zhè)個問題不能(néng)問我，你應該去問那個“誰”
這(zhè)麼(me)分析問題，有點杠精的行爲了~~
正式的評估或者被(bèi)認可的評估，在Automotive SPICE領域引申是指“可以做爲Assessor資質維持或資質晉升的證據的評估”，那這(zhè)樣(yàng)的評估需要滿足什麼(me)條件呢？這(zhè)個答案就是在前文（2.1節）中的闡述。
隻要滿足2.1節所闡述的條件的評估，就可以認爲是一個正式的評估和受認可的評估。與實施評估的組織是無關的哦~~，對(duì)嗎？
2.4 Automotive SPICE評估結果的有效性和有效期
Automotive SPICE評估是在某個時間點，對(duì)某個項目中已經(jīng)實施的過(guò)程的能(néng)力度進(jìn)行的評估，評估結果是代表了曆史上的某個項目，在曆史上的某個時間點的過(guò)程能(néng)力情況。
評估結果隻是對(duì)被(bèi)評估項目有效，對(duì)其它項目是無效的。
在VDA Guideline中，增加了12個月有效期的說法：在被(bèi)評估項目中，如果沒(méi)有發(fā)生變更，則可以認爲評估結果在12個月之内是有效的（這(zhè)個有效是對(duì)同一個被(bèi)評估項目來說的）；這(zhè)裡(lǐ)的變更是指過(guò)程的變更，包括：開(kāi)發(fā)地點的變更、團隊組織結構的調整、人員的更替、開(kāi)發(fā)過(guò)程的調整等。
雖然某一次Automotive SPICE評估結果隻是對(duì)被(bèi)評估的項目有效，對(duì)其它的項目無效。但該次評估結果也往往還(hái)是可以在一定程度上反映其它項目的過(guò)程能(néng)力，特别是當其它項目與被(bèi)評估項目在項目特征上一緻時。
1）比如：某個OEM在考察供應商時，供應商展示了3個月之前實施的一次Automotive SPICE評估結果，則OEM可能(néng)會(huì)認爲：“既然是在這(zhè)麼(me)短的時間之前做的評估，那麼(me)該評估結果能(néng)代表企業目前的能(néng)力”（接受）。如果供應商展示了10年之前實施的一次Automotive SPICE評估結果，則OEM可能(néng)會(huì)認爲：“這(zhè)是太久之前的一次評估，很難代表企業現在的能(néng)力”（不接受）。3個月的時間可以接受，10年的時間不可以接受，那麼(me)中間的臨界時間點在哪裡(lǐ)呢？沒(méi)有答案哦~~
2）不同的Automotive SPICE能(néng)力度級别也會(huì)對(duì)評估結果的有效性産生影響。
Automotive SPICE能(néng)力度二級時，具備相同項目特征的項目之間，其項目過(guò)程可以是不一緻的；Automotive SPICE能(néng)力度三級時，具備相同項目特征的項目之間，其項目過(guò)程是一緻的，都(dōu)是遵照了标準的組織過(guò)程。基于此，企業的某個項目的某些過(guò)程如果達成(chéng)了Automotive SPICE能(néng)力度三級，則客戶可能(néng)會(huì)相信其它項目的過(guò)程能(néng)力也是如此的。
2.5 評估通過(guò)證書
當第三方機構在爲某企業實施了Automotive SPICE評估之後(hòu)，如果評估範圍内的過(guò)程都(dōu)達到了目标級别，則第三方機構會(huì)應被(bèi)評估組織的要求，發(fā)一個通過(guò)Automotive SPICE評估的證書。
注：評估通過(guò)證書不是Automotive SPICE評估所要求的。是被(bèi)評估組織爲了其Marketing及Business目的，而要求評估機構頒發(fā)的。
Automotive SPICE評估通過(guò)證書是Automotive SPICE評估結果的Summary，雖然不同的第三方機構，頒發(fā)證書的格式和内容都(dōu)不盡相同，但爲了能(néng)客觀全面(miàn)的反映評估結果，一般需要包括如下信息：
被(bèi)評估的組織及部門（是對(duì)某個部門下的項目進(jìn)行的評估，項目所在的具體部門信息需要體現出來）
評估所遵照的Automotive SPICE模型信息，目标級别
評估方法
評估的項目名稱，及評估的過(guò)程範圍，評估日期
實施評估的組織
評估組組長(cháng)信息及簽名
蜂巢智能(néng)轉向(xiàng)的軟件開(kāi)發(fā)怎麼(me)樣(yàng)？
蜂巢智能(néng)轉向(xiàng)系統采用标準ASPICE軟件開(kāi)發(fā)過(guò)程，相關技術人員需要結合Aspice實行具體軟件開(kāi)發(fā)。蜂巢智能(néng)轉向(xiàng)科技有限公司全面(miàn)把握智能(néng)轉向(xiàng)系統的開(kāi)發(fā)流程，在此基礎上使智能(néng)轉向(xiàng)系統的開(kāi)發(fā)取得更加理想的成(chéng)果⌄進(jìn)而制造出高質量的智能(néng)轉向(xiàng)系統，滿足汽車的應用需求及制造要求，最終實現有效的智能(néng)化産品制造，随時進(jìn)行标定，給整車提供及時有效服務。
aspice是什麼(me)意思啊
aspice的意思是：汽車行業軟件過(guò)程改進(jìn)與能(néng)力評定的過(guò)程評估模型。
ASPICE是Automotive SPICE的簡稱，即汽車行業軟件過(guò)程改進(jìn)與能(néng)力評定的過(guò)程評估模型。
ASPICE包括32個過(guò)程，三個生命周期過(guò)程，主要是生命周期過(guò)程，組織生命周期過(guò)程，支持生命周期過(guò)程，進(jìn)一步可以細分爲需求獲取組、供應管理組系統組、軟件組、支持組、管理組、過(guò)程改進(jìn)組等。
過(guò)程評估模型：使用過(guò)程評估模型來确定過(guò)程能(néng)力的概念，在APICE是基于如下圖的二維框架。第一個維度是由過(guò)程參考模型定義的過(guò)程來提供，即滿足參考模型要求以及參考模型指定成(chéng)果要求；第二個維度是由過(guò)程屬性的能(néng)力等級所構成(chéng)。
過(guò)程參考模型：指的是按照一定的過(guò)程類别分組，針對(duì)每個過(guò)程，描述其目的，獲得其結果清單等。
aspice的能(néng)力成(chéng)熟度的劃分：
ASPICE根據企業管理的情況，將(jiāng)企業的軟件研發(fā)能(néng)力劃分爲6個級别，0級爲最低級，5級爲最高級。
0級：代表一種(zhǒng)混亂的狀态。
1級：代表企業已經(jīng)能(néng)夠完成(chéng)産品研發(fā)相關的工作，但缺乏管理，雖然偶爾能(néng)夠成(chéng)功，但項目中存在大量不确定的因素，對(duì)項目缺乏掌控能(néng)力，無法确保一定能(néng)夠按時交付高質量的産品。
2級：代表企業不僅能(néng)夠完成(chéng)産品研發(fā)相關工作還(hái)能(néng)有提前制定嚴謹和周全的工作計劃，并能(néng)有效根據計劃實施項目監控和管理，各項目能(néng)夠有序進(jìn)行。
3級：代表不僅各項目能(néng)夠管理得很好(hǎo)，而且能(néng)夠有效的從曆史項目中積累經(jīng)驗和教訓，形成(chéng)公司的知識資産和标準工作流程，用于對(duì)今後(hòu)項目的參考和指導以及公司管理的持續改善。
4級：引入統計學(xué)知識和技術，對(duì)項目相關各項數據進(jìn)行統計和分析，并將(jiāng)之運用于未來的項目管理之中，達到對(duì)項目結果的預測，并根據預測結果對(duì)項目進(jìn)行實時的調整，确保達成(chéng)項目目标。
5級：代表企業能(néng)夠基于商業目标的需要，主動的對(duì)過(guò)程進(jìn)行調整，對(duì)變革管理有很強的管理能(néng)力，能(néng)夠基于對(duì)過(guò)程的量化分析設定明确有效的過(guò)程改進(jìn)目标，并能(néng)對(duì)過(guò)程改進(jìn)結果進(jìn)行有效的量化監控和分析。
aspice2級要求權限怎麼(me)寫
ASPICE（汽車軟件過(guò)程改進(jìn)與能(néng)力評估）是一種(zhǒng)用于汽車軟件開(kāi)發(fā)的标準。如果您想要編寫ASPICE 2級權限要求，下面(miàn)是一個可能(néng)的範例：
1. 軟件需求規格書（SDS）：具有對(duì)需求進(jìn)行編輯、更新和批準的權限。
2. 軟件設計文檔（SDD）：具備對(duì)系統架構、模塊、接口和模塊實現進(jìn)行編輯、更新和批準的權限。
3. 代碼：具備對(duì)源代碼、庫文件、makefile 和構建腳本進(jìn)行編輯、更新和批準的權限。
4. 單元測試文檔：具備編寫單元測試用例和對(duì)測試文檔進(jìn)行編輯、更新和批準的權限。
5. 集成(chéng)測試計劃：具備規劃集成(chéng)測試、設計測試用例和對(duì)測試文檔進(jìn)行編輯、更新和批準的權限。
6. 缺陷管理系統：具備記錄和跟蹤軟件缺陷、問題和改進(jìn)措施的權限。
7. 變更管理系統：具備跟蹤和管理軟件變更和版本控制的權限。
以上是一些例子，具體的ASPICE 2級權限要求會(huì)根據你的組織、項目和特定情況而異。在編寫要求時，請确保將(jiāng)所有需要的權限列出來，并确保明确規定誰有權批準和執行這(zhè)些操作。
工作筆記ASPICE VDA Guideline解讀(19)：SUP.8 配置管理
配置管理過(guò)程的目的是建立和維護過(guò)程或項目的所有工作産品的完整性。
什麼(me)是“工作産品的完整性”呢？
下圖是"SWAD(軟件架構設計)"工作産品的創建和維護過(guò)程，其每一次變更（如：從Baselined 1.0 -- Baselined 2.0）是可控的，其相關聯的上下遊基線是明确的。這(zhè)樣(yàng)就可以說保證了"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
命名規約 / naming conventions
訪問權限 / access rights
基線準則 / criteria for baselines
合并和分支策略 / merge and branch strategy
配置項的修訂曆史方式 / the revision history approach for configuration items
配置管理策略包括：
a) 配置管理的範圍需覆蓋項目中的各學(xué)科(如：軟件、硬件)、各地點、各過(guò)程(如管理過(guò)程、支持過(guò)程、工程過(guò)程等)
b) 制定整體策略，覆蓋各學(xué)科、各過(guò)程及各地點等
c) 定義訪問權限
d) 根據項目的複雜度定義所需的活動和工具
e) 定義配置項的識别準則及命名規約
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.
老楊解讀：如果策略中沒(méi)有包括上述的各點，則BP1不能(néng)判定爲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.
老楊解讀：如果沒(méi)有專門的配置管理系統，但所建立的配置管理程序是滿足産品複雜度的，則不能(néng)基于此來降低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.
老楊解讀：如果配置管理的主要方面(miàn)（如上述的d)或e)）是缺失的，則BP1的打分不能(néng)高于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.
老楊解讀：如果策略中缺少主要的基線方面(miàn)的考慮（上述的g)），則BP1的打分不能(néng)高于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.
老楊解讀：如果策略中缺少主要的分支和合并方面(miàn)的考慮（上述的h)），則BP1的打分不能(néng)高于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.
老楊解讀：如果有一個适當的通用策略，而沒(méi)有爲項目定義特定的策略，那麼(me)BP1的打分不應該被(bèi)降低。
(2) 基線
ASPICE模型要求
SUP.8.BP6: 建立基線 / Establish baselines
根據配置管理策略建立基線，以滿足内部目的和外部交付
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) 根據策略創建必要的内外部基線
c) 創建跨不同學(xué)科、地點和過(guò)程的整體基線，并保證其之間的一緻性
d) 基線中應包括再現工作産品的完整和一緻的配置項集合
e) 根據策略中定義的命名規範創建基線
[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.
老楊解讀：如果基線中沒(méi)有識别出所有的需要被(bèi)控制的配置項，則BP6的打分不能(néng)高于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.
老楊解讀：如果創建的跨不同學(xué)科、地點和過(guò)程的整體基線(上述的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.
老楊解讀：如果基線的内容未進(jìn)行驗證，則應降低BP8的打分。
[SUP.8.RC.2] If the defined naming convention for baselines is not used, the indicator BP6 should be downrated.
老楊解讀：如果未使用已定義的命名規範，則應降低BP6的打分。
(3) 分支與合并
ASPICE模型要求
SUP.8.BP4: 建立分支管理 / Establish branch management
根據配置管理策略建立分支管理，分支管理适用于使用同一基礎進(jìn)行并行開(kāi)發(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.
老楊解讀：如果未基于策略創建分支，則應降低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.
老楊解讀：如果不能(néng)确保合并項的一緻性和完全性，則BP8的打分不能(néng)是F。
(4) 配置管理基礎設施
ASPICE模型要求
SUP.8.BP3: 建立配置管理系統 / Establish a configuration management system
根據配置管理策略建立配置管理系統
Establish a configuration management system according to the configuration management strategy
SUP.8.BP9: 管理配置項和基線的存儲 / Manage the storage of configuration items and baselines
通過(guò)适當的調度和資源存儲保證配置項和基線的完整性和可用性，對(duì)使用的CM系統歸檔（長(chá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) 适合于已定義的複雜度，包括适用于多地、項目規模、多項目或多變體應用等。
c) 了解所用的IT服務(如：文件共享、工具等)屬性，比如存儲、歸檔、備份，并與項目需求進(jìn)行比較。識别差異并采取糾正措施
[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.
老楊解讀：如果已建立的基礎設施不能(néng)支持配置管理程序(上述的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.
老楊解讀：如果沒(méi)有專門的配置管理系統，但所建立的配置管理程序是滿足産品複雜度的，則不能(néng)基于此來降低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軟件開(kāi)發(fā)組織架構和軟件開(kāi)發(fā)公司架構的介紹到此就結束了，不知道(dào)你從中找到你需要的信息了嗎 ？如果你還(hái)想了解更多這(zhè)方面(miàn)的信息，記得收藏關注本站。
