aspice软件开发流程的优点(asp技术的优点和缺点)

软件开发 2105
本篇文章给大家谈谈aspice软件开发流程的优点,以及asp技术的优点和缺点对应的知识点,希望对各位有所帮助,不要忘了收藏本站喔。 本文目录一览: 1、iNTACS认证评估师谈Automotive SPICE标准

本篇文章给大家谈谈aspice软件开发流程的优点,以及asp技术的优点和缺点对应的知识点,希望对各位有所帮助,不要忘了收藏本站喔。

本文目录一览:

iNTACS认证评估师谈Automotive SPICE标准

【传说1】“ASPICE标准要求开发采用瀑布或V模式吗”

据说ASPICE要求采用瀑布或V模型生命周期,而迭代和增量开发是不允许或不适用的。

评估师的观点

首先ASPICE标准定位在what to do层面,不是how to do的改进模型。因此ASPICE不会要求,也不会建议使用者采用瀑布,还是迭代开发模式。即不同的标准使用者,可根据自己的情况,选用适用的开发生命周期,可以是增量、敏捷等开发模式。

ASPICE标准MAN.3-项目管理过程,并没有提及和推荐项目采用V模型的生命周期。V model在ASPICE标准附录D中,只是用于描述各过程间的验证和追溯关系。过程V模型与项目生命周期是二个不同的概念。

新能源WVU怎么检测?

新能源汽车是指纯电动汽车、插电式混合动力汽车和燃料电池汽车。我们常说的新能源汽车指的是混合动力汽车和纯电动汽车。

新能源汽车和燃油汽车相比最大的不同就在于不使用燃油或使用非常少的燃油,既然不使用燃油,那么就是零排放,那么,新能源汽车就不用年检了吗?答案是否定的,新能源汽车也需要年检的。

车辆年检,尾气排放检验只是其中一项,安全技术检验是很重要的环节,新能源汽车也不例外。环检与安检“两检合一后”,环检是安检的前提,环检不达标,不能进行后续的安检。

纯电动汽车因没有尾气排放,故不用进行尾气检测,只用进行安全技术检测即可。

混合动力汽车是要进行尾气排放检测的,有手动行驶模式选择的混合动力汽车应切换到最大燃料消耗模式进行测试,如无最大燃料消耗模式,应采用混合动力模式测试,如测试过程中发动机自动熄火切换到纯电模式 ,无须中止测试,可进行到测试结束。

根据现行的GB21861-2014,新能源汽车的安检项目、方法和技术要求基本与燃油汽车没有区别,但是新能源汽车尤其自身的特点,其电路系统是关键,漏电保护装置是否有效、电压是否稳定、续航能力是否满足要求,GB21861-2014中并没有具体要求,这点已经不能满足要求。

但是,新的GB21861修订工作早已启动,对新能源汽车的安全技术检验项目和方法会更详细和明确,更具有针对性。

纯电动汽车的标志

所以说,在新的GB21861版本发布前,新能源汽车还是按照燃油汽车的安检项目和方法进行。新标准发布后,才会有新能源汽车量身定做的安全检测标准。

工作笔记 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模型信息,目标级别

评估方法

评估的项目名称,及评估的过程范围,评估日期

实施评估的组织

评估组组长信息及签名

如何检测汽车零部件?

以动力电池为例介绍一下新能源汽车动力系统部件的测试,欢迎开发测试工程师一起交流、指正:

动力电池系统作为硬件本体和控制系统结合极为紧密的系统,其测试大致可以划分为两大部分:电池包本体(Pack)测试、电池管理系统(BMS)测试,下面分别介绍这两部分的测试情况;

1. 电池包本体(Pack)测试

电池包本体测试一般在DV/PV(设计验证/生产验证)阶段进行,目的是为了验证电池包的设计/生产是否符合设计要求。其中包含温度测试、机械测试、外部环境模拟测试、低压电气测试、电磁兼容测试、电气安全测试、电池性能测试、滥用试验测试等等。因为大伙都比较关心电池安全问题,在这里主要介绍一下电池包滥用试验的测试方法:

1) 针刺测试

模拟电池遭到尖锐物体刺穿时的场景,因为异物刺入有可能导致内部短路,试验要求不起火不爆炸

2) 盐水浸泡

5%盐水长时间浸没测试,电池功能正常

目前新能源汽车电池包防水防尘等级推荐是IP67(即1米深的水浸泡半小时无损坏,上汽、蔚来的电池包都是IP67)。汽车的使用环境恶劣,再怎么做防水防尘保护也不过分(上海有一年暴雨导致车库积水,传统车都淹挂了,而电动车完好无损)。

3) 外部火烧:

590摄氏度火烧持续130秒电池无爆炸、起火、燃烧并且无火苗残留。

4) 跌落:

1m高度自由落体在钢板上电池壳体完整功能正常

5)振动测试

高频振动模拟测试,要求电池包功能正常。做电池包的同事应该知道,这个也很难通过。

2. 电池管理系统(BMS)测试

电池管理系统的测试更多侧重软件测试,一般在软件功能开发过程中进行。

与尚未量产的自动驾驶系统偏向于使用C语言实现软件设计不同,现今成熟的电动汽车控制系统(如整车控制器、电机控制器、电池管理系统)软件都是以模型为基础的软件开发(Model-Based-Design)。MBD开发相比C的优点是能够以图形化的方式表达复杂的逻辑、代码可读性、可移植性、开发调试便利程度都大大增强,同时利用成熟的代码生成工具链,也避免了手工代码容易产生的低级错误。在基于模型的软件开发环节中规定了MIL/SIL/HIL等多项测试:

1) MIL(Model-In-Loops)既模型在环测试,就是验证软件模型是否可以实现软件功能,测试依据是由系统需求分解而来的软件需求。

2) SIL(Software-In-Loops)软件在环测试,对比模型自动生成的C代码和模型本身实现的功能是否一致,使用Simulink自身工具就可以进行Sil测试。

3) PIL(Processer-In-Loops)处理器在环测试,目的是测试自动生成的代码写入控制器后,功能实现上是否与模型有偏差。PIL看似无关紧要,但不做重视也会引起一些不良后果(如调度问题、CPU Load,堆栈溢出等)

4) HIL(Hardware-In-Loops)硬件在环测试,测试控制器完整系统功能,一般会搭建控制器所在系统的测试台架,使用电气元件模拟传感器(如温度)和执行器(如风扇负载)的电气特性,验证完整的系统功能。

这些测试环节的用例来源于系统需求。在汽车软件开发流程中,开发和测试成V字型进行,俗称软件开发V模型,感兴趣的同学可以查看汽车软件开发流程ASPICE。

统开发流程中非常强调测试软件环节的。要知道手机软件出问题最多也就是秒退而已,车辆软件出问题影响的是人命。

当年丰田刹车门事件,美国政府就派了嵌入式软件专家和卡耐基梅隆的计算机教授详细审查了发动机控制系统的软件代码,丰田对全局变量的滥用(上万个)以及软件安全机制的混乱就遭到了巨额处罚。如果丰田重视软件测试工作的话,这件事也许不会发生。

最后再聊下零部件在整车极限环境下的测试情况:整车耐久测试这部分工作一般是整车厂的测试标定工程师负责。整车耐久试验的花销很大,造工程样车(每辆100万左右)、租用测试场地、工程师团队花销,很考验厂家的资金实力,没有强大的资金池根本无法运行起来。但在极寒、高温、高湿度等各种极限环境下的测试进行的越多,越能充分的验证零部件的功能、性能以及耐久表现,越早发现问题,解决修复所耗费的成本越低。

1. 低温耐久测试,主要测试冷起动性能,一般在黑河/牙克石进行。电池包的低温充放电能力、低温保护策略、电池包加热功能在该项测试中都会进行考核。

2. 高温耐久测试,一般在格尔木进行。主要测试电池包在高温下充放电能力、电池包冷却功能和过热保护策略。下图是蔚来在澳大利亚墨尔本进行高温测试,为了整车开发整车厂都是不惜成本。

3. 高温+高湿环境耐久测试,一般在海南进行,海水环境会加速部件腐蚀,零部件的耐久会经受严格考验。(Ps:传统车还有重要的高原测试,主要测试在低气压下发动机的性能表现。电动车一般不需要进行此项测试。)

电池包做的比较好的都会承诺使用寿命内的电池衰减,比如蔚来ES8就承诺10年30万公里电池容量衰减不超过20%,做电池开发的都知道做到这个水平是非常不容易的。敢公开承诺也说明他们的电池包耐久测试做到了非常优秀的水平。

工作笔记  ASPICE VDA Guideline解读(20):MAN.3 项目管理

项目管理过程的目的是在项目需求和约束的背景下, 识别、建立和控制项目生成产品所必需的活动和资源。

简单来说是指:通过对项目实施所必要活动(必要活动能保证输出质量) 和 资源(人力资源、设备资源等)的管理,使项目能达成既定的项目目标,如时间目标、质量目标、成本目标等。

接下来我们来看一下VDA Guideline中的相关规则:

(1) 工作范围

ASPICE模型要求

MAN.3.BP1: 定义工作范围 / Define the scope of work

确定项目的目标、动机和边界

Identify the project's goals, motivation and boundaries.

项目的工作范围包括项目范围和产品范围;项目的内容、边界、限制、项目目标等。

[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.

老杨解读:如果工作范围仅仅是产品描述,则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.

老杨解读:如果工作范围没有考虑所有项目和产品的相关方的责任划分,则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

在时间、项目估计和可用资源范围内,在技术限制的范围内,评估实现项目目标的可行性。

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: 定义、监控和调整项目估计和资源 / Define, monitor and adjust project estimates and resources

根据项目目标、项目风险、项目理由和边界,定义、监控和调整项目工作量和资源的估计。

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

MAN.3.BP8: 定义、监控和调整项目进度 / Define, monitor and adjust project schedule

为活动分配资源,并安排整个项目中的每一项活动的日程安排。在项目生命周期内,项目日程安排必须持续更新。

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: 定义、监控和调整项目活动 / Define, monitor and adjust project activities

根据定义的项目生命周期和预估,定义、监视和调整项目活动及其依赖关系。根据需要调整活动及其依赖关系。

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: 定义、监控和调整项目进度 / Define, monitor and adjust project schedule

为活动分配资源,并安排整个项目中的每一项活动的日程安排。在项目生命周期内,项目日程安排必须持续更新。

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的颗粒度需要小于项目的监控周期(如:周),如果存在特殊的Case,无法拆分,则也不能超过2个项目监控周期。

(4) 工作量和资源估计

ASPICE模型要求

MAN.3.BP5: 定义、监控和调整项目估计和资源 / Define, monitor and adjust project estimates and resources

根据项目目标、项目风险、项目理由和边界,定义、监控和调整项目工作量和资源的估计。

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.

老杨解读:如果有足够的资源来满足预计的工作量,但是缺少对工作量的监控,则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: 定义、监控和调整项目活动 / Define, monitor and adjust project activities

根据定义的项目生命周期和预估,定义、监视和调整项目活动及其依赖关系。根据需要调整活动及其依赖关系。

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: 定义、监控和调整项目估计和资源 / Define, monitor and adjust project estimates and resources

根据项目目标、项目风险、项目理由和边界,定义、监控和调整项目工作量和资源的估计。

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

MAN.3.BP8: 定义、监控和调整项目进度 / Define, monitor and adjust project schedule

为活动分配资源,并安排整个项目中的每一项活动的日程安排。在项目生命周期内,项目日程安排必须持续更新。

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: 定义、监控和调整项目活动 / Define, monitor and adjust project activities

根据定义的项目生命周期和预估,定义、监视和调整项目活动及其依赖关系。根据需要调整活动及其依赖关系。

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: 定义、监控和调整项目估计和资源 / Define, monitor and adjust project estimates and resources

根据项目目标、项目风险、项目理由和边界,定义、监控和调整项目工作量和资源的估计。

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

MAN.3.BP7: 识别、监控和调整项目的接口和承诺 / Identify, monitor and adjust project interfaces and agreed commitments

项目与其它(子)项目、组织单元和其它受影响的利益相关者的接口,需要确定并达成一致,并监督已商定的承诺。

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

MAN.3.BP8: 定义、监控和调整项目进度 / Define, monitor and adjust project schedule

为活动分配资源,并安排整个项目中的每一项活动的日程安排。在项目生命周期内,项目日程安排必须持续更新。

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

定期评审和向所有相关方报告项目状态,关于项目活动在预计的工作量和日程上的达成情况。防止发现问题再次发生。

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.

老杨解读:如果行动项或纠正措施没有恰当的跟踪直至关闭,相应的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中没有包括:开始和结束时间、持续时间、进展完成情况、资源、依赖,则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发生了变更但缺少文档化的原因,或变更没有被记录,则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

定期评审和向所有相关方报告项目状态,关于项目活动在预计的工作量和日程上的达成情况。防止发现问题再次发生。

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.

老杨解读:如果在项目监控时,没有考虑资源的实际消耗、最后期限的满足和活动的完成(即内容的进度)之间的相关性,则BP10的打分不能高于P。

(8) 发布管理

ASPICE模型要求

MAN.3.BP4: 定义、监控和调整项目活动 / Define, monitor and adjust project activities

根据定义的项目生命周期和预估,定义、监视和调整项目活动及其依赖关系。根据需要调整活动及其依赖关系。

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: 识别、监控和调整项目的接口和承诺 / Identify, monitor and adjust project interfaces and agreed commitments

项目与其它(子)项目、组织单元和其它受影响的利益相关者的接口,需要确定并达成一致,并监督已商定的承诺。

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

MAN.3.BP8: 定义、监控和调整项目进度 / Define, monitor and adjust project schedule

为活动分配资源,并安排整个项目中的每一项活动的日程安排。在项目生命周期内,项目日程安排必须持续更新。

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.

老杨解读:如果产品发布的接受者没有被考虑为相关方,则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.

老杨解读:如果产品发布的时间点或里程碑没有在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.

老杨解读:如果当前发布及下一次发布的范围没有被详细识别(每次发布的功能点),则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.

老杨解读:如果中期计划或长期计划中没有覆盖到当前发布或里程碑,则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.

老杨解读:如果当前发布及下一次发布中的所有活动没有被完全策划(且没有合适理由),则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.

老杨解读:如果项目计划相关的不同类型的信息之间的关联性不是依赖于工具,则不能基于此降低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.

老杨解读:如果项目计划相关的不同类型的信息之间的关联性的层次太高,则应降低BP9的打分。

(10) 风险

ASPICE模型要求

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

在时间、项目估计和可用资源范围内,在技术限制的范围内,评估实现项目目标的可行性。

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: 定义、监控和调整项目估计和资源 / Define, monitor and adjust project estimates and resources

根据项目目标、项目风险、项目理由和边界,定义、监控和调整项目工作量和资源的估计。

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

MAN.3.BP6: 确保所需的技能,知识和经验 / Ensure required skills, knowledge, and experience

根据估计,确定项目所需的技能、知识和经验,并确保选定的个人和团队及时具备这些技能和知识。

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软件开发流程的优点和asp技术的优点和缺点的介绍到此就结束了,不知道你从中找到你需要的信息了吗 ?如果你还想了解更多这方面的信息,记得收藏关注本站。

扫码二维码