【软件工程∶基于模型开发(MBD)时的验证(Verification)】
(1) 对需求及设计的“验证”
软件需求到模型设计，有如下三类转化(Transform)，为保证转化(Transform)的正确性和完整性，需要进行验证
【系统需求 + 系统架构设计】-> Transform To ->【软件需求】
验证活动：验证软件需求（上图中的黄色背景的活动）
验证对象：软件需求
【软件需求】-> Transform To ->【软件架构设计】
验证活动：验证软件架构设计（上图中的黄色背景的活动）
验证对象：软件架构设计
【软件架构设计】-> Transform To -> 【模型设计】
验证活动：验证模型设计（上图中的黄色背景的活动）
验证对象：模型设计
采用MBD方法的好处是：模型设计的验证方法，可以包括动态验证，即：通过运行模型来验证模型设计。
这可以满足ISO 26262:2018 Part 6 - Table 4中的要求“1c Simulation of dynamic behaviour of the design”.
(2) 对实现的“验证”
模型开发场合，通常不会对模型生成的Source Code进行修改和维护，修改和维护的对象都是“模型”。因此“模型”是设计，也是实现
对”实现(模型)”的测试
测试对象：模型
测试方法：MIL
测试用例的依据：模型设计的依据（即：分配给模型的软件架构设计和软件需求）+ 模型设计
这个部分，我再次请教了董淑成老师，董老师说：MIL测试用例的开发，首先是基于分配给模型的需求（即：黑盒测试），在执行MIL测试后，如果发现覆盖度达不到要求，则需要分析模型，看一下哪些地方没有被覆盖到，是设计有问题，还是测试用例不足，之后根据情况，补充测试用例（白盒测试），目的是提高测试的充分性。
【模型设计】-> Transform To -> 【Source Code】
如果工具是可信赖的，且模型生成的代码不会进行修改和维护，则这个步骤可以通过工具来保证，可以不验证。
26262标准中要求：ASIL C/ASIL D，需要通过Back-to-Back方式进行验证（模型和代码的等效性验证）。（图中所示的SIL Test / B2B Test）
(3) 与ASPICE的映射
模型开发(MBD)时，如果模型生成代码的工具是可信赖的，且模型生成的代码不会被修改和维护，则单元验证，可以只在模型层面来做。
VDA Guideline的相关Rules如下：
[MBD.RL.6] If there is no static verification and unit testing performed on code automatically generated from the model by a qualified tool chain (and without any modification after generation), then SWE.4.BP3 shall not be downrated.
关于SWE.4的补充说明：软件单元验证的通常方法包括：Code Review, Static/Dynamic Analysis, Unit Test，但这不是绝对的。
可参考如下的VDA Guideline的Rules：
[SWE.4.RL.1] If it is made reasonably plausible based on context-specific arguments that a particular verification measure is not necessary, then SWE.4.BP1 shall not be downrated.
（-- 完 --）
转∶
原文链接
https://t.cn/A6H5g3Bk
namo-amitabhaya！
(1) 对需求及设计的“验证”
软件需求到模型设计，有如下三类转化(Transform)，为保证转化(Transform)的正确性和完整性，需要进行验证
【系统需求 + 系统架构设计】-> Transform To ->【软件需求】
验证活动：验证软件需求（上图中的黄色背景的活动）
验证对象：软件需求
【软件需求】-> Transform To ->【软件架构设计】
验证活动：验证软件架构设计（上图中的黄色背景的活动）
验证对象：软件架构设计
【软件架构设计】-> Transform To -> 【模型设计】
验证活动：验证模型设计（上图中的黄色背景的活动）
验证对象：模型设计
采用MBD方法的好处是：模型设计的验证方法，可以包括动态验证，即：通过运行模型来验证模型设计。
这可以满足ISO 26262:2018 Part 6 - Table 4中的要求“1c Simulation of dynamic behaviour of the design”.
(2) 对实现的“验证”
模型开发场合，通常不会对模型生成的Source Code进行修改和维护，修改和维护的对象都是“模型”。因此“模型”是设计，也是实现
对”实现(模型)”的测试
测试对象：模型
测试方法：MIL
测试用例的依据：模型设计的依据（即：分配给模型的软件架构设计和软件需求）+ 模型设计
这个部分，我再次请教了董淑成老师，董老师说：MIL测试用例的开发，首先是基于分配给模型的需求（即：黑盒测试），在执行MIL测试后，如果发现覆盖度达不到要求，则需要分析模型，看一下哪些地方没有被覆盖到，是设计有问题，还是测试用例不足，之后根据情况，补充测试用例（白盒测试），目的是提高测试的充分性。
【模型设计】-> Transform To -> 【Source Code】
如果工具是可信赖的，且模型生成的代码不会进行修改和维护，则这个步骤可以通过工具来保证，可以不验证。
26262标准中要求：ASIL C/ASIL D，需要通过Back-to-Back方式进行验证（模型和代码的等效性验证）。（图中所示的SIL Test / B2B Test）
(3) 与ASPICE的映射
模型开发(MBD)时，如果模型生成代码的工具是可信赖的，且模型生成的代码不会被修改和维护，则单元验证，可以只在模型层面来做。
VDA Guideline的相关Rules如下：
[MBD.RL.6] If there is no static verification and unit testing performed on code automatically generated from the model by a qualified tool chain (and without any modification after generation), then SWE.4.BP3 shall not be downrated.
关于SWE.4的补充说明：软件单元验证的通常方法包括：Code Review, Static/Dynamic Analysis, Unit Test，但这不是绝对的。
可参考如下的VDA Guideline的Rules：
[SWE.4.RL.1] If it is made reasonably plausible based on context-specific arguments that a particular verification measure is not necessary, then SWE.4.BP1 shall not be downrated.
（-- 完 --）
转∶
原文链接
https://t.cn/A6H5g3Bk
namo-amitabhaya！
【软件工程∶给CMMI决策者的十条】
原创 丛斌博士
2024-05-13
上周参加了ISACA CMMI年会，借着这个机会向同行、CMMI的管理者表达了自己的一些意见。不吐不快，尽一份作为一个CMMI、Humphrey铁粉的责任。
01
从SEI到CMMI研究院，再到今天的ISACA，35年的历程，模型版本换了近十次，人换了一茬。但不能忘记历史，更不能割断历史。Humphrey和他的同事们留下的资产，是宝贵的财富。
不谈历史等于自毁根基，在巨人的肩膀上推动CMMI，则是承前启后，真正的发扬光大。
休息时，两个评估师告诉我，听了我的建议后，他们立刻在网上买了Humphrey的“管理软件过程”的书，旧书，花了1.99美金。
02
需要进一步明确CMMI模型的价值定位，如果完全沦为一个资质认证的评估模型，会很容易被替代。
建议重新强调IDEAL（熟悉老版本CMM和CMMI的朋友应该还记得它），强调CMMI模型和CMMI评估在改进中的定位。
03
随着CSMM逐步推广并成为国家标准，参加年会的许多在中国做评估和培训的老师，对CMMI在中国的前途表达了担忧。
在一片脱轨声中，是否应该把CMMI这样一个从美国军工成长出来的东西踢出去。
CMMI是一个方法论，代表了业界优秀实践的集合。2.0的一个重要改进是让CMMI成为了一个动态模型，让它承载了昨天和今天的最优秀实践，也代表了未来优秀方法。
CMMI的内容表述了整个行业的发展，没有国界。和CMMI脱轨，像是和软件工程脱轨一样，和先进的方法论脱轨一样，放弃了一个了解创新的渠道。
目前，从0到1，美国还是有其明显优势，这也包含新的研发模式的进化。
近20年来，敏捷、DevOps、质量理论、数据科学、安全安保、AIGC等方面的创新，美国都是发源地。
ISACA需要做的，是把这个道理和相关的决策者讲清楚。我接触到的（虽然有限）领导，都是极具眼光格局的。
希望CMMI可以和CSMM互相推动，取长补短。没有了CMMI，CSMM的更新改进也会少了一个重要的来源。
04
当年有CMM/CMMI的地方就有SPIN （Software Process Improvement Network），给了CMMI实践者一个沟通交流平台。CMMI年会关注的是实践者的声音，所以之前的会议被称为SEPG大会。
现在是时候应该考虑重建SPIN了，让模型的真正使用者成为CMMI的主人。
05
CMMI 3.0推出的4天 “BOC” 培训，在中国很难做起来。希望能做出改进，解决平衡好模型中不同领域的融合问题。
很高兴听到ISACA会研究解决这个问题。
06
转达了朋友的一个意见：尽可能让公众看到ISACA的评估审计过程，公告一些重要的审计结果，增加评估的可信度。
07
老调重弹：请研究一下2.0发布后，有多少人和组织购买了PDF版的模型？我的猜测是，少的可以忽略。
免费开放模型，开放评估方法，以最快、最广、最方便的方式，让尽可能多的人看到模型。模型的生命力在于其广泛地使用！
很高兴听到研究院愿意重新讨论这个问题，希望至少可以做到先部分开放。
08
ISACA成为了CMMI的守护者，此行一大收获是了解了ISACA的使命和业务。
希望ISACA管理者悟透二者的差异，平衡好CMMI的短期和长期目标、利益。
09
不少有情怀的中国评估师参与了ISACA的各种工作，让决策者听到了来自中国的声音。
希望ISACA能够更加支持、鼓励来自中国的参与，听到CMMI最大市场的一线反馈。
10
我的一点愿望：
20多年前我接触到了CMM，那是一个极具品牌，一个代表先进的东西。
20多年来，CMMI也给了我许多。
在不远的将来，要退休的时候，希望CMMI不要烂在我们手里，哪怕在另一个名头下，它还在继续装载行业的实践积累。
转∶
原文链接
https://t.cn/A6H5GfAC
namo-amitabhaya！
原创 丛斌博士
2024-05-13
上周参加了ISACA CMMI年会，借着这个机会向同行、CMMI的管理者表达了自己的一些意见。不吐不快，尽一份作为一个CMMI、Humphrey铁粉的责任。
01
从SEI到CMMI研究院，再到今天的ISACA，35年的历程，模型版本换了近十次，人换了一茬。但不能忘记历史，更不能割断历史。Humphrey和他的同事们留下的资产，是宝贵的财富。
不谈历史等于自毁根基，在巨人的肩膀上推动CMMI，则是承前启后，真正的发扬光大。
休息时，两个评估师告诉我，听了我的建议后，他们立刻在网上买了Humphrey的“管理软件过程”的书，旧书，花了1.99美金。
02
需要进一步明确CMMI模型的价值定位，如果完全沦为一个资质认证的评估模型，会很容易被替代。
建议重新强调IDEAL（熟悉老版本CMM和CMMI的朋友应该还记得它），强调CMMI模型和CMMI评估在改进中的定位。
03
随着CSMM逐步推广并成为国家标准，参加年会的许多在中国做评估和培训的老师，对CMMI在中国的前途表达了担忧。
在一片脱轨声中，是否应该把CMMI这样一个从美国军工成长出来的东西踢出去。
CMMI是一个方法论，代表了业界优秀实践的集合。2.0的一个重要改进是让CMMI成为了一个动态模型，让它承载了昨天和今天的最优秀实践，也代表了未来优秀方法。
CMMI的内容表述了整个行业的发展，没有国界。和CMMI脱轨，像是和软件工程脱轨一样，和先进的方法论脱轨一样，放弃了一个了解创新的渠道。
目前，从0到1，美国还是有其明显优势，这也包含新的研发模式的进化。
近20年来，敏捷、DevOps、质量理论、数据科学、安全安保、AIGC等方面的创新，美国都是发源地。
ISACA需要做的，是把这个道理和相关的决策者讲清楚。我接触到的（虽然有限）领导，都是极具眼光格局的。
希望CMMI可以和CSMM互相推动，取长补短。没有了CMMI，CSMM的更新改进也会少了一个重要的来源。
04
当年有CMM/CMMI的地方就有SPIN （Software Process Improvement Network），给了CMMI实践者一个沟通交流平台。CMMI年会关注的是实践者的声音，所以之前的会议被称为SEPG大会。
现在是时候应该考虑重建SPIN了，让模型的真正使用者成为CMMI的主人。
05
CMMI 3.0推出的4天 “BOC” 培训，在中国很难做起来。希望能做出改进，解决平衡好模型中不同领域的融合问题。
很高兴听到ISACA会研究解决这个问题。
06
转达了朋友的一个意见：尽可能让公众看到ISACA的评估审计过程，公告一些重要的审计结果，增加评估的可信度。
07
老调重弹：请研究一下2.0发布后，有多少人和组织购买了PDF版的模型？我的猜测是，少的可以忽略。
免费开放模型，开放评估方法，以最快、最广、最方便的方式，让尽可能多的人看到模型。模型的生命力在于其广泛地使用！
很高兴听到研究院愿意重新讨论这个问题，希望至少可以做到先部分开放。
08
ISACA成为了CMMI的守护者，此行一大收获是了解了ISACA的使命和业务。
希望ISACA管理者悟透二者的差异，平衡好CMMI的短期和长期目标、利益。
09
不少有情怀的中国评估师参与了ISACA的各种工作，让决策者听到了来自中国的声音。
希望ISACA能够更加支持、鼓励来自中国的参与，听到CMMI最大市场的一线反馈。
10
我的一点愿望：
20多年前我接触到了CMM，那是一个极具品牌，一个代表先进的东西。
20多年来，CMMI也给了我许多。
在不远的将来，要退休的时候，希望CMMI不要烂在我们手里，哪怕在另一个名头下，它还在继续装载行业的实践积累。
转∶
原文链接
https://t.cn/A6H5GfAC
namo-amitabhaya！
【软件工程，GJB5000∶如何描述软件的可靠性？】
原创 软件工程之思
2024-05-14
可靠性是软件的非功能性需求，指软件在异常情况下或在被非法、非常规使用时维持自身功能的能力。
在软件研制任务书中，可靠性与安全性、保密性一起都是作为关键性要求来描述的。
可是，在实践中，对于可靠性的描述并不准确。常见的描述都不具备可实现、可测试，不符合需求验收准则的要求。
那么，软件可靠性应该如何描述呢？
软件的可靠性体现在容错和健壮性这两个方面，描述可靠性可以从这两个方面考虑。
容错
容错指软件发生故障时仍保持正常运行的能力。
需求开发人员从容错的观点出发，可以这样描述可靠性：
冗余。对某些关键功能提出冗余要求。
弱化。在软件发生某种故障时，软件能够主动缩减它提供的功能，只保留关键功能，保证软件继续运行。
健壮性
健壮性是保护软件不受非正常使用方式或非法输入影响的能力。软件具备可靠性后，一旦出现非正常使用方式或非法输入，软件都能准确迁移至系统定义的状态。
健壮性只保证软件能迁移至系统定义的状态，并不要求软件修复或重新执行引发异常的处理。
需求开发人员从健壮性的观点出发，可以这样描述可靠性：
剥离。可以提出在发生故障时剥离发生故障的部分要求。
保护。可以提出在用户进行了错误操作的情况下也能安全运行的要求。
软件对可靠性的需求是不尽相同的。
比如一些关键的业务系统是不允许出现中断服务的，最多采取弱化的方式——缩减功能，但也要持续提供关键服务。
而供个人使用的软件可能就不需要这种持续性，这类软件大多都是选择保存数据重新启动。
所以，需求开发人员应当根据软件的实际情况分析是否需要给出可靠性需求，给出什么样的可靠性需求。
这正是：
说起需求可靠性，非功能中很关键
描述应从两方面，容错还有健壮性
参考书目：编程的原则：改善代码质量的101个方法，作者：上田勋，译者： 支鹏浩，出版社： 人民邮电出版社
作者简介：王小双，长期从事GJB5000推广、实施、评价、改进的工作，创建《软件工程之思》微信公众号，一直在《软件工程之思》分享GJB5000、CMMI、软件工程的知识和感悟。现致力于GJB5000培训、内外部评价以及软件过程改进、软件工程能力提升的研究工作。
转∶
原文链接
https://t.cn/A6H5bFW4
namo-amitabhaya！
原创 软件工程之思
2024-05-14
可靠性是软件的非功能性需求，指软件在异常情况下或在被非法、非常规使用时维持自身功能的能力。
在软件研制任务书中，可靠性与安全性、保密性一起都是作为关键性要求来描述的。
可是，在实践中，对于可靠性的描述并不准确。常见的描述都不具备可实现、可测试，不符合需求验收准则的要求。
那么，软件可靠性应该如何描述呢？
软件的可靠性体现在容错和健壮性这两个方面，描述可靠性可以从这两个方面考虑。
容错
容错指软件发生故障时仍保持正常运行的能力。
需求开发人员从容错的观点出发，可以这样描述可靠性：
冗余。对某些关键功能提出冗余要求。
弱化。在软件发生某种故障时，软件能够主动缩减它提供的功能，只保留关键功能，保证软件继续运行。
健壮性
健壮性是保护软件不受非正常使用方式或非法输入影响的能力。软件具备可靠性后，一旦出现非正常使用方式或非法输入，软件都能准确迁移至系统定义的状态。
健壮性只保证软件能迁移至系统定义的状态，并不要求软件修复或重新执行引发异常的处理。
需求开发人员从健壮性的观点出发，可以这样描述可靠性：
剥离。可以提出在发生故障时剥离发生故障的部分要求。
保护。可以提出在用户进行了错误操作的情况下也能安全运行的要求。
软件对可靠性的需求是不尽相同的。
比如一些关键的业务系统是不允许出现中断服务的，最多采取弱化的方式——缩减功能，但也要持续提供关键服务。
而供个人使用的软件可能就不需要这种持续性，这类软件大多都是选择保存数据重新启动。
所以，需求开发人员应当根据软件的实际情况分析是否需要给出可靠性需求，给出什么样的可靠性需求。
这正是：
说起需求可靠性，非功能中很关键
描述应从两方面，容错还有健壮性
参考书目：编程的原则：改善代码质量的101个方法，作者：上田勋，译者： 支鹏浩，出版社： 人民邮电出版社
作者简介：王小双，长期从事GJB5000推广、实施、评价、改进的工作，创建《软件工程之思》微信公众号，一直在《软件工程之思》分享GJB5000、CMMI、软件工程的知识和感悟。现致力于GJB5000培训、内外部评价以及软件过程改进、软件工程能力提升的研究工作。
转∶
原文链接
https://t.cn/A6H5bFW4
namo-amitabhaya！
✋热门推荐