继续看《AUTOSAR_RS_Methodology_20190826_145121》，继续看这个方法论。
方法论应该对现在已经存在的产品输出给出变化描述
方法论应包括活动的输出不是新创建的场景，而是从工作产品的旧版本更新。
使用案例：软件更新：该方法应描述软件更新所需的工作流程以及 AUTOSAR ECU 的现有数据（例如 NVRAM 数据）所需的转换。
看这意思，应该是能够继承的就继承一下。
应该能够进行产物的版本控制
应该可以为工作产品分配版本号并将它们存储在版本控制数据库中。
这里还提到了基线的处理，我觉得这应该是版本管理的艺术，也是一个应该掌握的技能。在版本管理上，我掌握的技能太肤浅了。
应该可以为每个工作输出添加精确的和可读性好的文档
该方法应允许将精确的和可读性好的文档添加到每个工作产品中。 该文档应是工作产品的一部分或唯一引用。
这对于记录设计决策或限制是必要的，这显然不能从正式内容中推断出来，例如。 从名字。 此类文件将增加质量或安全标准所要求的可追溯性。
方法论应定义明确的指导术语
活动可以参考指导来协助活动的执行。 指导可以采用清单、教程或工具的形式。 使用工具时，应为其命名。 实际的工具实现可能会执行许多其他任务，但在活动的上下文中，该工具仅执行指定的指导。
讲得太好了，可是我怎么看到一群人看着ETAS的配置工具愁的不行呢？难道是这个教程指导没有找到？
方法论应结合行业标准工具的使用
如果存在行业标准工具，例如编译器和链接器，则方法论应包含它们。
小结：这个又一次刷新了我的认识了，最初我认为如此，后来看文档觉得可能不是如此，现在再次回到就是如此。
方法论应该定义角色
方法论应捕捉（或许应该叫做提取）人们在 Autosar 中扮演的典型角色。
角色的定义将允许区分在 AUTOSAR 活动中工作的不同方的责任，并将所有权分配给工作输出。 通过考虑“所有者”和“执行者”，它还有助于定义活动和工作产品的粒度级别。
角色应有描述
方法论应提取人们在 Autosar 中扮演的典型角色。软件开发人员就是其中的一个典型角色。“软件开发人员”是精通建模或编程语言并且能够将需求转换为软件并解决缺陷的工程师。
AUTOSAR 方法不应绑定到特定的生命周期模型
AUTOSAR 方法不应绑定到特定的生命周期模型。活动在执行它们的开发过程的时间和阶段方面必须是独立的。
与公司特定生命周期模型的连接：该方法应能够使用不同的生命周期模型，例如 V 模型，Rational 统一过程。后面这个是一种与V流程相对的另一种开发模式？
使用的案例：如果类似使用极限编程，在实现之前创建测试用例。 对于大多数其他开发过程，实现是在创建测试用例之前生成的。
这里，又接触了一个新的开发模式：极限编程，在开发之前完成测试用例。
AUTOSAR 方法应支持对外部工件的可追溯性
外部工件是未在 AUTOSAR 上下文中定义的工件，例如需求或测试用例。
外部工件到 AUTOSAR 工作产品的映射必须是可能的。
方法论需要模型化
方法论应该使用一致的关系建模。
对方法进行建模将允许精确的关系，并将允许工具自动生成已发布的文档。
方法论应定义将方法论模型转换为文档的规则
从使用案例看，AUTOSAR也是支持LaTeX的？
方法论文件应包括活动、角色、工作产品和指南之间的超链接
通过创建指向所有引用的超链接，该方法论可以快速回答许多常见问题，例如“向我展示角色 X 拥有的所有工作产品”或“向我展示需要工作产品 Y 作为输入的所有活动”。 这对于快速学习方法论或进行下游影响分析以确定利益相关者非常有帮助。
这个其实从阅读文档就能够体验出来了，比如每一条后面跟着的编号都是一个超链接。
方法论应指定绑定时间
AUTOSAR 方法应指定工作流程中可以解决变化的特定点。
在 Autosar 系统和 ECU 的开发过程中，需要创建并最终选择特定的变体，例如预编译或后构建。
方法论应规定解决变体的任务
AUTOSAR 方法应指定将解决变异的特定任务/活动。
如果两个软件组件在系统的不同变体中提供相同的接口，则需要一项任务来选择一个提供者来解决该系统变体。
方法论应为变体选择器的值指定工作输出物
AUTOSAR 方法论应指定特定的工作输出物来维护变体选择器的值。
这使得变量选择器的值存储和维护的位置很清楚。
可能的变体是预先知道的：它们在特定时间创建并作为工作产品拥有，最后在选择变体时使用。
文档的剩余部分是修改记录，直接跳过了。这样，终于又完成了一个文件的梳理。长路漫漫，我感觉关于AUTOSAR的学习，都还谈不上算是起步的阶段。
