aspice软件开发流程百度文库（aspice2）
本篇文章给大家谈谈aspice软件开发流程百度文库，以及aspice2对应的知识点，希望对各位有所帮助，不要忘了收藏本站喔。
本文目录一览：
- 1、蜂巢智能转向的软件开发怎么样？
- 2、ASPICE VDA Guideline解读(18)：SUP.10 变更请求管理
- 3、工作笔记ASPICE VDA Guideline解读(19)：SUP.8 配置管理
- 4、工作笔记 aspice基础知识
- 5、aspice2级要求权限怎么写
- 6、16款哈佛h6变速箱是钢链吗
蜂巢智能转向的软件开发怎么样？
蜂巢智能转向系统采用标准ASPICE软件开发过程，相关技术人员需要结合Aspice实行具体软件开发。蜂巢智能转向科技有限公司全面把握智能转向系统的开发流程，在此基础上使智能转向系统的开发取得更加理想的成果⌄进而制造出高质量的智能转向系统，满足汽车的应用需求及制造要求，最终实现有效的智能化产品制造，随时进行标定，给整车提供及时有效服务。
ASPICE VDA Guideline解读(18)：SUP.10 变更请求管理
SUP.10 变更请求管理"过程的目的是确保变更请求被管理、跟踪和实施。
在什么场景下需要应用SUP.10来进行变更管理呢？
举个例子来说明变更请求的各种情况，如下图所示：
客户发布了"客户需求规约"基线
产品需求工程师基于"客户需求规约"基线，开发并发布了"产品需求规约"基线
开发工程师基于"产品需求规约"基线，开发并发布了"产品设计和实现"基线
场景1：当已建立基线的"客户需求规约"发生变更时，需要应用SUP.10：
场景2：测试工程师在实施测试活动时，发现了缺陷（注：按"SUP.9 问题解决管理"处理缺陷），开发工程师在解决缺陷的过程中，发现有必要变更已建立基线的产品需求规约。此时需要触发"SUP.10 变更请求管理"过程来请求变更“产品需求规约”。
场景3：当由于例如"设计重构“的原因，对已建立基线的"产品设计"进行变更。
变更请求管理策略：
a需覆盖变更请求影响的各个学科(如：软件、电路）、各个领域（如：应用层软件、底层软件）
b需覆盖变更请求影响的各相关方，如客户、供应商、内部相关方等
c需定义变更请求在各学科、各领域、各相关方之间的传递和管理
d需定义变更请求的"状态模型"
e需定义活动的目标，如响应时间
f需定义变更请求批准在组织结构层级上的指导，如变更请求的影响到达XX成本时，需要项目经理批准，而当变更请求的影响到达XX成本时，需要部门总监批准
e可以根据项目所处的不同阶段（如：A样件、B样件），定义变更请求处理的不同要求
f需定义确保"变更请求"与"变更请求影响的工作产品及基线"之间的双向追溯性的机制
[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
基于分析结果和资源可用性，对变更请求进行优先级排序，并根据策略批准
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
根据策略，分析变更请求，包括它们对受影响的工作产品和其它变更请求的依赖。评估变更请求的影响，并建立确认实施的标准。
SUP.10.BP6: 评审变更请求的实现 / 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.
老杨解读：如果不能对由于特定风险和潜在变化的复杂性而产生的潜在副作用进行分析，则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.
老杨解读：如果没有正确记录变更请求的技术内容或备选方案的决策，则应降低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.
老杨解读：如果对成功执行变更请求的确认不以文档化的准则为依据，则应降低BP6的打分。
(4) 变更请求的状态模型和工作流
ASPICE模型要求
SUP.10.BP3:记录变更请求的状态 / Record the status of change requests
状态模型的状态被分配给每个变更请求以便于跟踪
SUP.10.BP7: 跟踪变更请求至关闭 / Track change requests to closure
跟踪变更请求至关闭，并给变更发起者提供反馈。
[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.
老杨解读：如果策略中没有包括状态模型的定义、工作流、状态迁移条件、相关方及其授权，则应降低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.
老杨解读：如果状态模型及工作流没有被恰当的应用或与实际不符，则BP3的打分不能高于P。
[SUP.10.RC.7] If closed CRs do not reflect a final state, the indicator BP7 should be downrated.
老杨解读：如果已关闭的变更请求不能反映出最终状态，则应降低BP7的打分。
示例场景：状态模型中定义了“已解决(Solved)”和“已关闭(Closed)”两个状态。但实际项目中无法进入“已关闭(Closed)”状态
工作笔记ASPICE VDA Guideline解读(19)：SUP.8 配置管理
配置管理过程的目的是建立和维护过程或项目的所有工作产品的完整性。
什么是“工作产品的完整性”呢？
下图是"SWAD(软件架构设计)"工作产品的创建和维护过程，其每一次变更（如：从Baselined 1.0 -- Baselined 2.0）是可控的，其相关联的上下游基线是明确的。这样就可以说保证了"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) 配置管理的范围需覆盖项目中的各学科(如：软件、硬件)、各地点、各过程(如管理过程、支持过程、工程过程等)
b) 制定整体策略，覆盖各学科、各过程及各地点等
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.
老杨解读：如果策略中没有包括上述的各点，则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.
老杨解读：如果没有专门的配置管理系统，但所建立的配置管理程序是满足产品复杂度的，则不能基于此来降低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.
老杨解读：如果有一个适当的通用策略，而没有为项目定义特定的策略，那么BP1的打分不应该被降低。
(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) 创建跨不同学科、地点和过程的整体基线，并保证其之间的一致性
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.
老杨解读：如果基线中没有识别出所有的需要被控制的配置项，则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.
老杨解读：如果创建的跨不同学科、地点和过程的整体基线(上述的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.
老杨解读：如果基线的内容未进行验证，则应降低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
根据配置管理策略建立分支管理，分支管理适用于使用同一基础进行并行开发时
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.
老杨解读：如果不能确保合并项的一致性和完全性，则BP8的打分不能是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
通过适当的调度和资源存储保证配置项和基线的完整性和可用性，对使用的CM系统归档（长期保存）和备份
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服务(如：文件共享、工具等)属性，比如存储、归档、备份，并与项目需求进行比较。识别差异并采取纠正措施
[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.
老杨解读：如果没有专门的配置管理系统，但所建立的配置管理程序是满足产品复杂度的，则不能基于此来降低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基础知识
最近给某OEM做了一次Automotive SPICE CL2评估，很多朋友就问我关于Automotive SPICE评估的一些事情。本文算是一个科普吧，给不太了解Automotive SPICE的人介绍一下Automotive SPICE和Automotive SPICE评估的事情。
1. Automotive SPICE
1.1 什么是Automotive SPICE？
Automotive SPICE是一个”过程模型”，适用于”基于软件的车载系统”的”设计开发过程”。过程模型是一个集合，是包含了与设计开发过程相关的优秀实践的集合。既然是一个集合，那就需要按照一定的结构把这些实践组织起来：
方式一：按照实践所属的不同领域进行组织，比如有些实践是和项目管理相关的，有些实践是和软件需求相关的，有些实践是和软件单元测试相关的….，不同的领域被称为“过程”，这就是Automotive SPICE中的“过程纬度”。Automotive SPICE PAM V3.1中包括有32个过程。
方式二：按照做事情的方式进行组织，比如：依靠个人的经验来做，是能力度级别1（CL 1）的实践；按照可管理的方式（活动管理和工作产品管理）来做，是能力度级别2（CL 2）的实践；按照组织的要求来做，是能力度级别3（CL 3）的实践….，这就是Automotive SPICE中的”能力度纬度”。
“能力度”是“过程的能力度”。如果说“某个项目达到了能力度2级”，是不准确的，应该说“某个项目中的某些过程达到了能力度2级”。同样的，如果说某个组织达到了能力度2级，也是不准确的。
下图是常见的体现评估结果的形式，评估范围内的过程，分别达到了什么样的过程能力度。
1.2 怎么用Automotive SPICE？
Automotive SPICE是欧洲车厂在认识到软件质量的重要性之后，制定的一个规范。目的是希望其供应商能按照Automotive SPICE的要求进行产品的设计开发，以提供高质量的产品。
Automotive SPICE中包括有那么多的过程，那么OEM对供应商的具体要求是什么呢？要求供应商需要应用哪些过程，这些过程需要达到几级呢？
一般来说，OEM不会要求供应商去遵守Automotive SPICE的所有过程的，为什么呢？
性价比！
实施Automotive SPICE的成本，评估的成本，最后都是产品成本，OEM是需要买单的。
所以OEM会基于其对软件质量的理解，选择最重要的过程来要求其供应商。
起初的时候，不同的OEM有不同的使用Automotive SPICE的观点，形成气候的，如下图所示：
说明：
HIS是Audi AG, BMW, DaimlerChrysler, Porsche, Volkswagen成立的制定软件开发规则的组织
如上的过程划分，是基于Automotive SPICE PAM V2.4/V2.5
逐渐的，各OEM的要求开始统一，目前逐渐形成了如下两类：
说明：
2016年HIS组织解散了，VDA QMC（Automotive SPICE PAM V2.5及其以后版本的Owner）在2017年Automotive SPICE PAM V3.0发布时，将之前在业界应用非常广泛的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资质时，其条件之一就是需要实施Automotive SPICE评估：
作为Assessor晋升证据（或维持资质的证据）的评估要求包括：
评估由至少2个评估师来实施，评估组组长需要Competent Assessor或Principal Assessor，评估组组员可以是Provisional Assessor或Competent Assessor或Principal Assessor
评估的过程范围至少包括项目管理相关的过程、支持类相关的过程和工程类相关的过程
评估的时间需要至少50小时
2.2 Automotive SPICE评估的类型
在1次Automotive SPICE评估时，Automotive SPICE相当于评估的准则（Criteria），而还需要有评估方法，根据所选择的评估方法不同，Automotive SPICE评估分为两种类型，一种是项目能力度评估，一种是组织成熟度评估。
项目能力度评估
遵照ISO/IEC 15504-2 Performing an assessment实施的评估，是项目能力度评估。在这类评估中，是由Sponsor（发起评估的人）确定评估的模型范围（选择哪些过程，这些过程需要评估到几级）、项目范围（评估哪个项目），而Assessor是根据Sponsor的要求实施评估。
（企业想评价哪个项目，评价哪个过程，评价到几级，不是Assessor决定的！）
组织成熟度评估
ISO/IEC 15504-7 TR Assessment of organizational maturity定义的是组织成熟度评估的评估方法，在组织成熟度评估时：Sponsor确定被评估的组织，以及目标级别；由Assessor根据对被评估组织进行分析，之后进行项目抽样（使得被抽样的项目能代表整个组织的水平），然后通过对被抽样项目进行预定义过程的评估，进而得出组织的过程成熟度水平。
简单来说：在组织成熟度评估时，是由Assessor确定被评估的项目，而过程范围也是需要预定义的（应该由Automotive SPICE的Owner来定义，详细的原因，这里不再赘述，读者可以思考思考~~）
组织成熟度评估在业界很少被用到，主要的原因是OEM不太认可组织成熟度评估的方式。我分析有两个原因：
OEM更关注的是供应商为其开发的项目的情况如何，而不关注供应商的组织
Automotive SPICE的业界大咖们不希望Automotive SPICE因为组织成熟度的评估方式而商业化（Automotive SPICE还是很高冷的，不像CMMI那么商业化）
基于如上原因ISO/IEC 15504-7在2008年发布之后，至今也还是TR，始终不是一个正式的ISO标准，本文后续的描述，不再讨论组织成熟度评估。
注：此处的标准号都是15504，15504系列标准正在被330XX标准所替代。
2.3 被认可的Automotive SPICE评估
什么样的Automotive SPICE评估才是正式的评估，或者说是被认可的评估呢？
经常经常有人问我这个问题，但这个问题的题干是不完全的。
是被谁认可的评估呢？
举个例子：如果需要OEM A认可的评估，那么这个认可的条件就需要OEM A来定义。OEM A可以指定某个专业的软件过程专家（该专家可能不具备任何Automotive SPICE的Assessor资质），然后只要是该专家实施的评估，OEM A都认可。
所以说，这个问题不能问我，你应该去问那个“谁”
这么分析问题，有点杠精的行为了~~
正式的评估或者被认可的评估，在Automotive SPICE领域引申是指“可以做为Assessor资质维持或资质晋升的证据的评估”，那这样的评估需要满足什么条件呢？这个答案就是在前文（2.1节）中的阐述。
只要满足2.1节所阐述的条件的评估，就可以认为是一个正式的评估和受认可的评估。与实施评估的组织是无关的哦~~，对吗？
2.4 Automotive SPICE评估结果的有效性和有效期
Automotive SPICE评估是在某个时间点，对某个项目中已经实施的过程的能力度进行的评估，评估结果是代表了历史上的某个项目，在历史上的某个时间点的过程能力情况。
评估结果只是对被评估项目有效，对其它项目是无效的。
在VDA Guideline中，增加了12个月有效期的说法：在被评估项目中，如果没有发生变更，则可以认为评估结果在12个月之内是有效的（这个有效是对同一个被评估项目来说的）；这里的变更是指过程的变更，包括：开发地点的变更、团队组织结构的调整、人员的更替、开发过程的调整等。
虽然某一次Automotive SPICE评估结果只是对被评估的项目有效，对其它的项目无效。但该次评估结果也往往还是可以在一定程度上反映其它项目的过程能力，特别是当其它项目与被评估项目在项目特征上一致时。
1）比如：某个OEM在考察供应商时，供应商展示了3个月之前实施的一次Automotive SPICE评估结果，则OEM可能会认为：“既然是在这么短的时间之前做的评估，那么该评估结果能代表企业目前的能力”（接受）。如果供应商展示了10年之前实施的一次Automotive SPICE评估结果，则OEM可能会认为：“这是太久之前的一次评估，很难代表企业现在的能力”（不接受）。3个月的时间可以接受，10年的时间不可以接受，那么中间的临界时间点在哪里呢？没有答案哦~~
2）不同的Automotive SPICE能力度级别也会对评估结果的有效性产生影响。
Automotive SPICE能力度二级时，具备相同项目特征的项目之间，其项目过程可以是不一致的；Automotive SPICE能力度三级时，具备相同项目特征的项目之间，其项目过程是一致的，都是遵照了标准的组织过程。基于此，企业的某个项目的某些过程如果达成了Automotive SPICE能力度三级，则客户可能会相信其它项目的过程能力也是如此的。
2.5 评估通过证书
当第三方机构在为某企业实施了Automotive SPICE评估之后，如果评估范围内的过程都达到了目标级别，则第三方机构会应被评估组织的要求，发一个通过Automotive SPICE评估的证书。
注：评估通过证书不是Automotive SPICE评估所要求的。是被评估组织为了其Marketing及Business目的，而要求评估机构颁发的。
Automotive SPICE评估通过证书是Automotive SPICE评估结果的Summary，虽然不同的第三方机构，颁发证书的格式和内容都不尽相同，但为了能客观全面的反映评估结果，一般需要包括如下信息：
被评估的组织及部门（是对某个部门下的项目进行的评估，项目所在的具体部门信息需要体现出来）
评估所遵照的Automotive SPICE模型信息，目标级别
评估方法
评估的项目名称，及评估的过程范围，评估日期
实施评估的组织
评估组组长信息及签名
aspice2级要求权限怎么写
ASPICE（汽车软件过程改进与能力评估）是一种用于汽车软件开发的标准。如果您想要编写ASPICE 2级权限要求，下面是一个可能的范例：
1. 软件需求规格书（SDS）：具有对需求进行编辑、更新和批准的权限。
2. 软件设计文档（SDD）：具备对系统架构、模块、接口和模块实现进行编辑、更新和批准的权限。
3. 代码：具备对源代码、库文件、makefile 和构建脚本进行编辑、更新和批准的权限。
4. 单元测试文档：具备编写单元测试用例和对测试文档进行编辑、更新和批准的权限。
5. 集成测试计划：具备规划集成测试、设计测试用例和对测试文档进行编辑、更新和批准的权限。
6. 缺陷管理系统：具备记录和跟踪软件缺陷、问题和改进措施的权限。
7. 变更管理系统：具备跟踪和管理软件变更和版本控制的权限。
以上是一些例子，具体的ASPICE 2级权限要求会根据你的组织、项目和特定情况而异。在编写要求时，请确保将所有需要的权限列出来，并确保明确规定谁有权批准和执行这些操作。
16款哈佛h6变速箱是钢链吗
16款哈佛h6变速箱是正时链条
长城汽车的销量当家车型哈弗H6，在SUV市场里有着颇高的热度，其搭载的就是长城自主研发的7速湿式双离合变速箱，代号为7DCT450，这款变速箱能承受最大450N·m的扭矩输入，性能在同级变速箱当中处于领先行列。接下来便详细看看这款自主品牌变速箱有哪些值得关注的地方。

诞生背景和研发历程
长城汽车作为自主品牌里面的代表性车企，早在2009年就已经实现了首台汽油发动机的量产，但同样作为动力总成之一的变速箱，在当时仍然需要对外采购。
来自德国的格特拉克是全球几大变速箱供应商之一，旗下的湿式双离合变速箱具有技术成熟可靠、传动效率高等优点，加上采购成本相对较低，在相当一段时间内成为了"国产车企变速箱救星"，影响力甚至和爱信齐名。而长城也是格特拉克其中一位大客户，初期的哈弗H6、H6 Coupe等车型均使用了格特拉克的7DCT300变速箱，对于格特拉克的依赖程度非常高。

但变速器供应商根本不会为自主品牌变速器单独设计和开模，只提供现成产品供采购，供应量控制在格特拉克手中。更重要的是，比变速箱本身更重要的调校和匹配，同样掌握在格特拉克手里，长城还需要支付软件匹配的成本。
多方面受制于人，要改变"卡脖子"的命运只能尽快实现自研自产。2013年4月，长城湿式双离合变速器项目正式启动。至于长城为什么选择自研湿式双离合而不是AT或CVT，个中原因也不难理解。
在变速箱自主研发的道路上，实际上不但长城，大部分自主品牌车企也是选择了双离合变速箱作为自研对象，一方面是因为双离合的结构相对简单，底层技术接近"开源"，研发难度和成本低。
另一方面，AT技术和专利基本集中在爱信和采埃孚两大厂商手中，而CVT变速箱的传动钢带只有德国博世和舍弗勒能够生产。
第三方面，双离合变速箱相对AT或CVT也具备换挡速度快、燃油经济性好等自身优势。更重要的是对于长城来说，长期以来与格特拉克的合作也积累了不少双离合变速器的技术经验。实际上格特拉克7DCT300合作项目开始阶段长城已经明确提出自己将平行研发变速箱，格特拉克也签署了相关协议来帮助长城提升变速箱技术。因此长城直接研发双离合变速箱无疑在研发难度、研发成本、周期等方面均具备优势和成熟的条件。
当然了，真正实施，而且还要保证成功，并不是一件容易的事情，特别是自动变速箱对齿轮加工精度、零部件的耐高温性、耐久性要求极高，生产难度和工艺相比发动机还要更难。长城于是采用了更高效率的方法，借力人才。
研发环节，长城请来了变速器领域有着接近30年经验、先后参与大众DSG项目、奔驰9AT项目（参与研发戴姆勒7-Tronic和9-Tronic的AT变速器，）的专家格哈德·亨宁作为研发的总工程师。

最终经过4年时间，到了2017年3月，代号为7DCT450的第一代湿式双离合变速器成功实现量产。
随后在2018年，蜂巢易创科技有限公司成立，推出了经过改良优化的第二代7DCT450，能够进一步适配四驱系统、电子换挡机构，支持机械或电子驻车、自动泊车等功能。

到了2019年10月份，该变速器累计产量正式超过100万台。2021年3月21日，7DCT450第200万台产品正式下线。随后，长城还先后发布了第三代代号为300S和400S的两款7DCT变速箱，预计今年年内实现量产。
长城的7DCT变速箱自13年诞生至今经历了三代，搭载在哈弗H6上的为第二代型号为7DCT450的湿式双离合变速箱，这款变速箱除了搭载在哈弗H6上，还广泛搭载在哈弗系列其他SUV的自动挡车型上。

软硬件构成及生产环节
零部件方面，长城7DCT450由157种零部件组成，其中壳体、齿轮及轴承等18种基础零部件由自己生产，剩下部件则来自进口或外资零部件在华工厂。

在生产环节，长城也采取了引进国外先进生产线、设备或交钥匙工程的方式来实施。

而软件部分，包括需求分析、技术标定、专利、系统匹配等全部环节，具体如新下线变速器在使用过程不同阶段的自主学习功能、变速器易损部位的保护及报警策略、换挡逻辑和策略、基于物理模型的离合器充油策略等等均由长城的技术团队来主导编写实现，把动力总成调校匹配的主动权掌握在自己手里，也让产品更适应中国的路况和车主实际需求。
同时，蜂巢易创也正在进行ASPICE软件开发流程、ISO26262 功能安全等国际标准体系建设，用来规范产品安全生命周期内软硬件和系统层面的开发流程，判定风险等级，以满足产品国际化发展需求。
性能亮点
7DCT450作为一款7挡湿式双离合变速箱，相比以往的干式双离合，其离合片浸泡在变速箱油内，利用油液冷却摩擦片，并通过液压推动高低换挡，散热效果更理想，轴承和离合片等部件的磨损和压力降低，稳定性提升，也能承受更大扭矩。相比AT变速箱，双离合变速箱没有液力变矩器，而是采用了两套离合器，能实现无缝换挡的效果，因此换挡速度更快，发动机的动力输出也更直接，动力损失少，燃油经济性更佳。

具体性能参数方面，7DCT450的速比范围达到了8.0，属于较宽传动比范围的设计，最大可承受450N·m的输入扭矩，综合效率高达 95.6%，另外设计寿命达到30万公里，也超过了欧美24万公里的设计寿命标准。
具体到第三代哈弗H6上，其1.5T发动机最大扭矩285N·m，2.0T发动机最大扭矩325N·m。
变速箱能承受的最大输入扭矩与发动机的峰值扭矩之间的差就是扭矩余量，扭矩余量越大，越有利于提高变速箱的耐用性。相对于第三代哈弗H6 1.5T发动机，7DCT450的扭矩余量为165N·m，而2.0T发动机扭矩余量为125N·m。
关于aspice软件开发流程百度文库和aspice2的介绍到此就结束了，不知道你从中找到你需要的信息了吗 ？如果你还想了解更多这方面的信息，记得收藏关注本站。
