1.功能安全软件开发模型的要求与敏捷的冲突
功能安全标准是确保系统或模块在故障条件下能够可靠运行并避免不可接受的风险的标准。不同的行业和应用领域有不同的功能安全标准，以 ISO 26262, IEC 61508, EN 50128, DO-178C 为例，这些标准对软件开发模型的定义有共通点，在具体规定中也有一些不同。
1. ISO 26262（道路车辆 - 功能安全）: ISO 26262 是针对汽车行业的国际标准，它涵盖了从概念阶段到生产再到报废阶段所有方面。对于软件开发，ISO 26262 强调了基于风险的安全生命周期管理，并要求采用 V-model 或其他等效模型来确保安全相关软件的质量。
2. IEC 61508（电气/电子/可编程电子安全相关系统的功能安全）：IEC 61508 是一个广泛适用的标准，适用于所有行业的电气、电子和可编程电子系统。它定义了一个完整的安全生命周期，包括需求分析、设计、实施、集成、验证、确认和维护。该标准推荐使用 V-model 或其他迭代开发方法论。
3. EN 50128（铁路控制和防护系统的软件）：EN 50128 是专门为铁路行业制定的标准，规定了铁路控制系统中使用的软件开发过程。它遵循与 ISO 26262 类似的 V-model 方法，但更专注于铁路特定的应用场景和技术。
4. DO-178C（机载系统和设备认证 - 软件方面的考量）：DO-178C 是航空业中的关键标准，为机载软件提供了指导方针。它强调通过严格的验证和确认活动来保证软件的安全性，通常采用瀑布模型或 V-model 进行开发。
这些功能安全标准对软件开发过程的要求主要集中在确保系统的安全性、可靠性和可追溯性。尽管每个标准的具体要求有所不同，但它们都强调以下几个关键方面：
1. 安全生命周期管理
所有提到的标准都要求采用一个明确的安全生命周期模型来管理整个项目，从概念阶段直到退役。这包括风险评估、需求分析、设计、实现、测试、部署、维护和报废。
2. 分类与定级
根据潜在危害的风险水平对系统或模块进行分类（例如，在 IEC 61508 中为 SIL 等级，在 ISO 26262 中为 ASIL 等级）。不同的等级决定了需要采取的安全措施的严格程度。
3. 需求跟踪能力 (Traceability)
必须能够追踪所有安全相关的需求到最终的产品实现，并且在整个生命周期内保持这种追踪关系。通过双向追踪保证所有需求被实现和验证了。
4. 严格的验证与确认 (V&V)
验证确保产品正确地实现了指定的功能；确认则保证该产品满足用户需求并能在预期环境中安全运行。
5. 配置管理
对软件版本进行严格的控制，以确保项目中的所有工件都经过良好的版本控制，所有配置项和变更都有明确的记录和管理，任何时候都能清楚知道当前使用的代码基线是什么状态。
6. 文档化
开发过程中产生的所有重要信息，如需求规格说明书、设计文档、测试计划和报告等，都需要被详细记录下来，并易于访问以便审核。
7. 工具认证
如果使用了软件工具辅助开发，则这些工具本身也需要经过适当的验证，以证明它们不会引入新的错误或影响最终产品的安全性。
8. 人员资质
涉及安全关键型软件开发的团队成员应该具备必要的技能和经验。
9. 持续改进
建立反馈机制，用于识别和纠正开发流程中的不足之处，从而不断优化过程以提高产品质量。
10. 软件验证
软件验证的步骤包括：
a) 确定集成步骤并集成软件元素，直至嵌入式软件完全集成；
b) 验证软件结构层面的安全分析所确定的安全措施是否得到正确实施；
c) 提供证据，证明集成软件单元和软件组件按照软件架构设计满足了其要求；以及
d) 提供充分证据，证明集成软件在功能安全方面既不包含不需要的功能，也不包含不需要的特性。
通常，功能安全标准中会要求采用 V 模型进行开发。V 模型的特点在于其内置的验证和确认活动确保在开发过程中不断进行检查。这种模型采用 V 形图示表示，“V 模型”可以简单概括为：1. 确定需求；2. 实现需求；3. 验证需求。
对于确定需求 specification of software safety requirements 和实现需求 Software architectural design 以及 Software unit design and implementation 集中在“V 模型”的左边，验证需求集中“V 模型”的右边。随着开发过程从左向右推进，测试活动从软件单元验证（Software Unit Verification），软件集成和验证（Software Integration and Verification），软件测试（Testing of the embedded Software），到系统集成测试（System and item integration and testing），以确保产品符合 FSR 的要求。在开发功能安全产品时，由于客户往往要求快速响应，需要在敏捷方法和 V 模型间获得平衡。这种结合的结果就是 “敏捷 V 模型”。
2.敏捷 V 模型的工作原理
● 需求分析与分解：敏捷方法通过故事地图（包括史诗、主题、功能和用户故事）对需求进行逻辑分解，这与 V 模型中的左侧阶段相对应，即定义和分解需求的过程。
● 集成、测试与交付：敏捷实践中的持续集成/持续测试/持续交付（CI/CT/CD），优化了人力消耗，加速了产品的发布周期，这一过程完美映射到了 V 模型的右侧，涵盖了模块集成测试等环节。
● 迭代开发：关键在于，敏捷 V 模型并不遵循传统大型瀑布式方法的路径。相反，它要求每个冲刺（Sprint）都遵循一个小型的 V 模型，这意味着每个冲刺都包含从需求到部署的完整流程，并且在这个过程中不断进行验证和确认。
为什么选择敏捷 V 模型？
对于功能安全项目来说，敏捷 V 模型提供了一种灵活而严谨的开发方式，既能应对快速变化的需求，又能确保产品质量和安全性。这种方法允许团队在保持灵活性的同时，针对特定阶段进行深入的质量保证活动，从而有效地管理复杂性和风险。此外，它促进了跨职能团队之间的紧密合作，提高了项目的透明度和响应速度，最终使得功能安全产品能够更迅速地适应市场和技术的变化。
通过这种方式，敏捷 V 模型为开发团队提供了一个强有力的工具，使他们能够在满足严格的安全和性能标准的同时，也能够快速响应市场需求的变化。
后者的两种实施方案
在将敏捷方法与 V 模型相结合的过程中，存在两种主要的实施策略：
1. 每个冲刺都成为一个完整的 V：包括开发和集成/测试。这意味着每个冲刺都涵盖从需求分析到最终验证的整个过程。
2. 引入专用集成冲刺的概念：一个完整的 V 被拆分为两个冲刺——一个用于开发，另一个专门用于集成和测试。这种模式更适合复杂度和依赖性非常高的项目，例如涉及多个组织开发的不同模块之间的协作。
本文主要讲第一种方法。这种方法较为灵活，在开发周期中保持效率。对于特别复杂或跨组织边界的项目，第二种方法可能会是较为有效的解决方案，但它可能会增加降低开发效率。
Sprint 0：准备阶段
Sprint 0 作为项目的启动冲刺，其主要目标是为后续工作奠定基础。在这个阶段，团队通常会产生两项关键成果：
- 初始故事地图：根据功能安全框架提出的结构，故事地图涵盖了顶层的故事和功能。
- 初始模块架构：定义了产品的关键功能模块。
根据敏捷原则，“工作的代码重于详尽的文档”，因此模块架构不需要过于详细。如果项目需要，可以根据具体情况添加必要的细节和依赖关系。
Sprint n：开发阶段
进入具体的开发阶段，以“sprint n”为例，团队将专注于实现某一项特定功能。这不仅有助于展示整体方法，还能够确保每项功能都能得到充分的关注和优化。
过渡到下一个冲刺（“sprint n+”）
完成当前冲刺后，团队将评估已完成的工作，并根据反馈调整计划，为下一冲刺做准备。这个过程中，团队要做好持续改进和适应变化，确保项目始终朝着正确的方向前进。
在敏捷开发过程中，故事地图和完成定义（DoD）是重要工具。故事地图从“冲刺 0”开始创建和维护，不仅是需求工程的核心工具，还应设定每个用户故事的验收标准。DoD 则明确了每个用户故事能够被视为 Done 必须达到的标准。这些标准构成了我们每个迭代的起点。
模块架构同样从“冲刺 0”开始构建，提供了一个概览，展示了功能模块及其交互方式，这对于理解产品的整体结构至关重要。
对于每个用户故事，需要简明扼要的需求，定义时需要符合 INVEST 原则，并附上具体的验收标准（AC）。这些用户故事是在每次冲刺计划会议中选定的，旨在确保它们能够适配于一个冲刺周期内完成。
接下来，每个用户故事与实现该故事所需的模块相映射。这一步骤帮助我们确定哪些人员需要加入到负责实施用户故事的功能团队中来。这些模块可以是现有的，也可以是为了满足新的用户故事而创建的新模块。
模块集成阶段的重点在于将特定用户故事所需的所有模块整合在一起进行测试。这通常意味着要在模拟环境中嵌入这些模块，或使用生产数据进行测试。可以使用持续集成（CI）自动处理这一过程。
验证阶段借助持续测试（CT）基础设施，专注于单元测试和确保特定用户故事范围内模块之间的兼容性得到测试。
系统集成阶段则致力于将当前冲刺期间更改或创建的所有模块集成为系统的下一个可交付增量。
最后，在用户验收测试（UAT）阶段，我们将重点放在确认产品是否满足用户的实际需求。如果涉及到物理模块，还会在测试实验室或现场进行额外测试。由于现场测试可能较为复杂，可能会专门安排一次冲刺来进行。
在敏捷 V 模型中，验证分为微观层面和宏观层面。微观层面由单个用户故事的验收标准定义，而宏观层面则侧重于 “完成的定义”，它通常适用于单个用户故事。另一方面，验证侧重于用户接受度：
在敏捷 V 模型中，验证过程分为微观层面和宏观层面：
- 微观层面：由单个用户故事的验收标准（AC）定义，确保每个用户故事都满足特定的功能性和非功能性要求。
- 宏观层面：侧重于“完成的定义”（DoD），它不仅适用于单个用户故事，还涵盖了整个产品的质量标准。宏观层面的验证特别关注用户的接受度，确保产品符合用户的实际需求。
冲刺回顾与迭代改进
在每次冲刺结束时，团队应进行冲刺回顾会议，总结 V&V 任务中的关键发现，并确定哪些需要延续到下一个冲刺：
- 用户验收测试中的发现：如果在用户验收测试（UAT）过程中发现了问题，可能需要调整用户故事的定义或验收标准。例如，用户反馈可能导致对清洁模式选择界面的设计进行修改，或者增加新的功能选项。
- 架构变更：有时，研发团队可能会根据实际情况决定对计划的模块架构做出临时性调整。这类变更应当反映在待办事项列表（backlog）中，更新相关的用户故事定义，同时也要更新架构计划和文档，以确保信息透明且最新。
通过定期的冲刺回顾，团队可以识别哪些做法有效，哪些需要改进，从而持续提升产品质量和团队效率。
3.敏捷 V 模型中的职责分工与具体实施
在遵循功能安全标准的敏捷开发环境中，每个角色都有明确的责任，以确保产品的功能安全和高质量。在开发过程中，各个角色的具体职责以及与功能安全相关的敏捷工作流程如下：
角色职责
- 产品负责人（PO）：
对产品的整体安全性和 ISO 26262 合规性负责。
在安全经理的支持下，创建与安全相关的积压工作（Backlog），如安全机制开发等。
- Scrum Master (SM)：
确保团队遵守组织特定的安全相关流程。
分享与功能安全成就相关的信息，促进团队内部的知识交流和最佳实践传播。
- 开发团队：
推导、实施和测试软件安全要求（SSR）
确保测试覆盖范围、遵循功能安全标准的编程指南、验证工具置信度等。
- 安全经理：
确保团队遵守安全计划和组织特定流程。
支持 PO 开展活动，包括创建与安全相关的待办事项列表。
在所有与安全相关的活动中与开发团队紧密合作。敏捷与功能安全标准的工作流程和工件
冲刺计划
- 冲刺计划 I：PO 向团队介绍主要的冲刺任务，重点是解释涉及安全的关键用户故事及其验收标准。
- 冲刺计划 II：团队细化这些任务，创建详细的 Sprint Backlog，并规划如何实现它们，确保安全需求得到适当处理。
每日 Scrum 会议
- 这是一个简短的每日沟通会，用于同步进度、解决问题并调整当天的工作计划。安全专家必须参与，以评估已完成工作的安全性影响，确保任何潜在的安全问题能够及时被识别和解决。
冲刺审查（Sprint Review）
- 在每个冲刺结束后举行，团队展示经过编码和测试的功能或增量。此阶段要对各种错误（如建模错误、工具错误或源代码错误）进行审查，特别关注是否符合 ISO 26262 的要求。
回顾（Retrospective）
- 这是在一个或多个冲刺结束时进行的反思活动，旨在评估团队的工作方式，识别改进点，并制定行动计划来提升未来的效率和质量。
完善代办事项列表（Backlog Refinement）
- 在冲刺计划之前进行，PO、SM 和安全经理共同对需求进行细化，区分安全关键和非安全关键的需求。安全需求根据 ASIL 级别（Automotive Safety Integrity Level）进行标记，确保优先级设置合理且资源分配得当。
通过这种方式，团队能够在保持敏捷灵活性的同时，严格遵守功能安全要求，从而保证产品的安全性和可靠性。这种协作模式有助于在整个开发周期中持续地管理和减轻风险，确保最终产品既满足市场需求又符合严格的安全标准。
END
作者：vova zhu
文章来源：sasetech
推荐阅读
更多物联网安全，PSA 等技术干货请关注平台安全架构(PSA)专栏。欢迎添加极术小姐姐微信（id:aijishu20)加入PSA 技术交流群，请备注研究方向。
