1.如何快速记忆SWE中的那么多BP？SWE是Software engineering process group的缩写，也就是说它本质上是个功能组。SWE下辖6个过程。在过程评估模型中，过程实施指标包含两个，一个是BP，一个是WP。 BP（Basic Practice）面向活动，讲的是你需要做的事，即这个活动在开发过程中有没有做这几件必要的事？比如你说你去打扫厕所，那你需要擦马桶、擦水龙头、擦花洒、拖地面......总之是个事儿。这个在Automotive SPICE官方文档中对应的是绿区，讲的是How。 WP（Work Product）面向结果，即最终呈现给评审员的材料。你说你把厕所打扫干净了，那你自己记录的Checklist呢？照片呢？总之是可被审查的成果。这个在Automotive SPICE官方文档中属于蓝区的范畴，讲的是What。 我们今儿这篇文章只讨论BP，因为BP的活如果都干了，大多数的WP你手里也就有了。SWE中包含多少个BP呢？一共是4 (5 6 5 3 4 3) 3*6=48个BP。这个计算式子是怎么来的呢？ 之前@东晓一家介绍过PDCA管理法（见先决知识点），定策略肯定属于Plan的范畴，建立双向可追溯性和确保一致性则属于Check，沟通与总结测试结果属于Act/Adjust的范畴。剩下的这些BP比如画架构、定接口、写测试用例肯定就算是Do的范畴了。 对于Check和Adjust，我们需要做三件事，即建立双向可追溯性、确保一致性、沟通和总结测试结果。我们发现SWE中的六个过程（Process），每个过程都有这三件事需要做。算下来一共是3*6=18个BP。 对于Plan，我们需要做策略，SWE中有4个策略需要制订，即软件单元验证策略、软件集成策略、软件集成测试策略和软件合格性测试策略。 剩下的26个BP就都是Do了。我们可以采用东晓一家的三字法。这里我有小部分用的不是东晓老师的说法，关于用词每个人都有自己的喜好吧。  现在我们知道了，以前不画架构，不写每个函数具体的流程图，不写开机序列的顺序图，一心想写好代码，直接发给黑盒测试组测试的流程是不正规的，是不符合功能安全的。那遵循软件开发的6个过程，48个基本实践，怎么这么繁琐？第一次执行时有没有重点可寻？是否满足二八原则呢？即能否只把20%的BP做好就能达到80%的效果呢？库乐玛公司（KUGLER MAAG CIE）提供了的Automotive SPICE的免费视频教程，我们看看能否快速地理解Automotive SPICE软件开发6大过程的核心要点。 2.库乐玛公司Video Campus翻译稿SWE.1 软件需求分析这个过程可帮助您的组织将系统需求中与软件相关的部分转化为一组软件需求。 为什么我们要用文档来记录软件需求？ 通常来说，您已经有了系统需求或客户需求，那为什么还要投入时间和精力来记录其他软件需求呢？在一个项目中，你希望按时、在预算内、以客户要求的质量交付商定过的结果。如果不记录软件需求，可能会忽略掉功能或完全误解客户的期望。这会导致额外的工作、成本和延迟。您还可以忽略对软件的功能或非功能方面至关重要的软件方面。这可能导致错误的开始，甚至是额外的开发周期。 这一过程与SYS的上下游都有紧密的联系，上游即系统需求分析（SYS.2），系统架构设计（SYS.3），下游即软件架构设计（SWE.2）和软件合格性测试（SWE.6）。其他依赖性强的流程是项目管理（MAN.3）和配置管理（SUP.8），例如，因为发布管理和缺陷管理（SUP.9）和变更请求管理（SUP.10）。这里的联系是，测试中发现的缺陷必须得到解决，错误修复和更改请求必须在回归测试中得到解决。 以下是Automotive SPICE®软件需求分析中最重要的三个关键点。 1-1 你需要考虑的不仅仅是客户的要求 文本化记录软件需求的一个重要原因是，你需要考虑的不仅仅是客户的期望。软件必须符合标准、规范和其他增加需求数量的规定。出于文档目的，将系统需求或仅在软件开发的情况下、客户和其他利益相关者的需求映射到反映软件内部视图的软件需求中。软件需求反过来构成了软件合格性测试（SWE.6）和所有下游流程的基础，例如软件架构设计（SWE.2）。 1-2 确保你分析并理解需求的含义 顾名思义，这个过程的另一个面是需求分析。您应分析需求的可行性或风险。这两者紧密相连。如果您不确定某个需求的可行性，则存在固有的风险，因为可能需要时间才能找到解决方案，或者根本没有解决方案。显然，这与我们在项目管理（MAN.3）中必须执行的评估有着密切的联系，尤其是MAN.3 BP5。另一个需要分析的主题是可测试性(testability)。当然，测试人员的支持可以用来确保这一点。通常，测试人员还被要求评审(review)需求。此外，分析应涵盖技术影响。这包括评估需求之间的依赖关系。 我在关于系统需求分析（SYS.2）的视频中加入了一个例子。 最后，分析还应涵盖需求的业务方面。因此，应确定各种要求的实施如何影响成本和时间。现在，你可以说你不能在需求数据库中记录所有这些。请记住，Automotive SPICE®没有说明您应在何处文本记录这些信息。 例如，您可以在需求数据库中介绍分析的第一部分（可行性和风险）、相应和相关变更请求中的技术含义，以及项目管理工具中对成本和进度的影响。 1-3 建立可追溯性和一致性 该过程还要求您确保软件需求、系统需求和系统架构之间的可追溯性。 然而，Automotive SPICE®明确表示不需要冗余。您可以决定是希望跟踪系统需求、系统架构还是两者的组合。这取决于哪种方法以最佳方式支持您的开发，而不是哪种方法对您更容易。 可追溯性可通过DOORS等超链接、Rectify等特定的可追溯性工具、可追溯性矩阵或你们公司工具环境支持的其他可管理方式来建立。 可追溯性的目的是支持以下3项： ——一致性检查，即验证软件需求的完整性和准确性。 ——变更请求或缺陷情况下的影响评估。 ——报告的执行情况。 这个点的另一部分是确保一致性。 一致性意味着您可以根据系统需求和系统架构分别证明软件需求的完整性和正确性。 这只能通过评审（review）来确定。 如果您跳过此评审，您可能有不完整或错误的软件需求。最糟糕的是，您甚至可能没有注意到软件合格性测试（SWE.6）中的缺陷，因为该测试是根据您的软件需求执行的。如果这些都是错误的，你的测试可能不会显示任何错误的行为。所以，请不要跳过评审这个环节！ SWE.2 软件架构设计这个过程有助于组织搭建和记录软件产品的内部逻辑。 软件架构的目标是什么？期望是既然您已经有了软件需求（SWE.1），这些需求描述了软件应该做什么。软件架构设计的目的是定义如何实现软件需求中记录的功能。简而言之，需求描述了“什么what”，架构则描述了“如何how”。 许多组织和项目在理解如何记录体系结构以及需要哪些元素方面存在问题。 软件架构的三个关键点 ——恰当的视图 ——接口 ——可追溯性 2-1 架构视图 通常，软件架构只包括软件的物理视图、框图等。在如今大多数复杂的项目中，这显然是不够的。当然，您希望对软件进行分层分解，以演示和解释如何在不同组件和子组件中实现功能性和非功能性需求。 其他的视图包括： ——动态视图， ——显示特定功能分解的特定功能视图， ——状态流程图， ——接口等等。 通常，系统越复杂，需要的视图就越多。 由于不同的视图必须保持一致，因此应该使用适当的UML或SysML工具。该工具需要支持一致性检查。 2-2 接口 评估中经常遇到的一个陷阱就是缺乏对接口的详细描述。 评审员希望看到的接口文档的内容包括： ——名称 ——类型 ——单位 ——Resolution ——范围 ——默认值 等等。 如果没有这些信息，就不可能在集成测试中对接口进行适当的测试。同样，在适当的UML或SysML工具中描述这些接口才能够支持不同视图之间的一致性。 作为对SYS.2中定义的补充，当前章节从进程间通信机制和总线通信机制的角度考虑了软件组件之间的特定软件接口。 2-3 可追溯性 这个过程还要求您确保软件架构和软件需求之间的可追溯性。 通常情况下，需求和架构之间存在工具造成的不连续，这会使证明可追溯性变得困难。 可追溯性的目的是： ——支持一致性检查，即检查软件需求覆盖范围的完整性和准确性。 ——支持变更请求或有缺陷情况下的影响评估。 ——支持利益相关者的期望报告，并确定需求是否已在架构中实现。 SWE.3 软件详细设计Automotive SPICE中的软件详细设计和单元构造过程（也称为SWE.3）帮助您的组织为软件组件（SWC）提供经过评估的详细设计，并指定和生产软件单元。 软件详细设计的目标是什么？许多组织和项目在理解如何记录详细设计方面存在问题。那么，在这个过程中你应该管理的三个方面是什么呢？ 以下是Automotive SPICE®中软件详细设计的最重要方面。 3-1 细节的层次 通常，组织很难确定详细设计应该有多么具体。一个很好的办法是记住详细设计的目的是什么。它是实现代码和单元测试的基础。尤其是单元验证需要详细描述。在这方面，必须要考虑覆盖范围。 在安全方面，ISO26262中的关键软件可提供指导。在非安全软件中，通常至少需要C0-或声明（statement）覆盖，一些客户要求C1-或分支覆盖。覆盖率目标越高，详细设计所需的细节就越多。如果您有ASIL-B的分类模块，则需要C1覆盖。这意味着您的详细设计应该识别软件的不同分支。 3-2 接口 我在评估中经常遇到的一个陷阱是缺乏对外部和内部接口的详细描述。 接口文档的预期内容包括： 1.名字 2.类型 3.单位 4.resolutions 5.取值范围 6.默认值 如果没有这些信息，就不可能在单元测试中对接口进行适当的测试。 如果外部接口是在架构级别中描述的（SWE.2），并在软件集成测试（SWE.5）中进行测试，那这当然是可以的。 3-3 文档的时间安排 在实现代码之前描述详细设计。通常情况下，详细设计是在事后描述的，也就是在编写代码之后。 为什么这样做是一个问题？单元测试应该检查代码是否满足详细设计。如果在写代码之后再写详细设计，那么单元测试的关键点就丢失了。 现在，你可以说你可能不需要单元测试。关键是，您应该从软件架构而不是代码中派生出软件详细设计。如果这个链条断了，那么文档的内容和所有的测试就会突然变得毫无意义。因此，在开始编写代码之前，必须先编写软件详细设计。 循序渐进地迭代开发软件详细设计和代码并没有什么错。
|
|
|
