软件开发中的需求文档由谁来编写_在汽车安全攸关系统软件开发中使用敏捷框架...-CSDN博客

来源：知乎

前言

为了确保汽车中安全攸关(safety critical)系统的安全性和可回溯性(Traceability)，以及为了明确责任认定，汽车软件行业如今普遍采用了ISO 26262和ASPICE等标准，作为软件开发的方法和流程。汽车行业的供应商们多数采用传统的“瀑布式流程”或“V型流程”来进行软件开发，并编制出大量的相关支持文档。这套流程不仅繁琐，而且越来越不适用于如今快速变化的市场需求。

而开发汽车控制软件毫无疑问是一个“系统工程”。像目前的“V型流程”定义的那样，先“冻结”需求，再让软件和测试团队以此开始他们的工作，这在工程实际中其实是一件很难实现的事情。因为客户需求经常是在不断变化的，并且软件团队对需求最初的理解也很可能有误。

事实上，在每个汽车软件项目中，软件团队都必须经过多次“循环迭代”，才能编制出一个合格的软件系统，而工程师们宝贵的时间和资源往往在这些较长的循环迭代中被浪费。为了应对日具挑战的市场，越来越多的软件团队如今倾向于使用敏捷框架进行软件开发，并以此来缩短软件迭代的时间、在保证软件安全性和完备性的前提下，更好地实现跨职能团队之间的协作。

然而，对大多数汽车供应商而言，敏捷开发流程目前往往仅被应用于产品研发的阶段，而不是量产的整个过程，因为敏捷开发流程仍被认为“不能满足安全攸关软件开发的全部要求”。随着通用汽车和沃尔沃等主机厂要求供应商们根据主机厂制定的敏捷流程里程碑(Agile Cadence milestones)来发布软件，敏捷框架也越来越受到重视。但是业界对如何在安全攸关系统的开发中应用敏捷框架基本上还是一头雾水。

那么，应用敏捷框架也能做到与ASPICE合规吗？应用敏捷框架还能继续遵循ISO26262标准吗？

虽然应用ASPICE流程也并不能一定保证产品质量，但每种优质的质量流程(无论是敏捷流程还是传统的V型开发流程)都应该符合ASPICE和ISO 26262的精神和原则。

与任何其他流程一样，敏捷流程只有在开发团队正确应用的的前提下才能高效地发挥作用。在汽车行业生搬硬套其他行业的所谓“敏捷”流程并不一定能成功。把敏捷开发流程应用到汽车行业，则必须根据汽车行业强调安全性和责任性的特点进行修改和剪裁。本文旨在探讨一种在符合ASPICE与ISO26262标准的前提下，将敏捷框架应用到汽车行业软件开发的方法。

汽车软件敏捷团队

和传统的敏捷团队一样，汽车软件敏捷开发团队也必须由“多功能团队”(cross-functional team)组成。另外，如果项目团队由分布在全球各地的不同团队组成，那么这个项目也很难建立敏捷框架。

表1：汽车敏捷团队组成

表1给出了一个应用本文讨论的敏捷框架的汽车敏捷团队规模及其组成。团队成员必须能够对彼此的工作进行同行评议(peer review)，以确每项工作都经过了正确的审核和批准流程。

汽车软件敏捷团队成员

每个敏捷团队成员都必须以成为“全栈专家”(译者注：原文是Generalising Specialist)为目标。这意味着他们对所设计系统的各个方面(系统，软件，测试和安全)都有很好的认识，同时又在他们自己的领域有深刻而专业的理解。对于敏捷的汽车团队而言，这样的团队成员比纯粹的“专家”更有价值。建立这样一个团队成员当然需要时间，但具有“T型[1]”技能的敏捷团队可能会更成功。

(译者按：这一段其实我不太认同。作者把项目团队想得有些理想化了。实际情况往往是，如果一个团队成员被培养成了“全栈专家”，那么他所做的第一件事就是要么跳槽、要么谋求一个技术经理的职位，而不会甘心在团队里继续做一个开发工程师...因为我就是这么一个人哈哈)

汽车软件敏捷开发框架

本文讨论的是如何将敏捷开发应用于任何安全攸关汽车产品开发的典型CV(概念验证，Concept Validation)和DV(设计验证，Design Validation)阶段。在CV阶段，产品开发的重点是开发出一个可工作的系统，并产生“将降适当”数量的文档，以确保在产品开发过程进行了一定程度的“尽职调查”。然后，DV阶段应该将在CV阶段研发的软件进行重构，以符合相关的安全需求以及行业标准、法律法规。DV阶段的测试应偏向于证明系统的安全性，例如通过进行FIT(Fault Insertion Tests，故障注入测试)来证明软件系统不仅功能正确，还具有完备的诊断覆盖。

每个CV / DV阶段可分为三个不同的子阶段，以适应敏捷框架：

Pre-Sprint - 分析，计划和准备阶段
Sprint - 应用敏捷框架开发产品
Post Sprint - 回顾和总结阶段

图1：一个典型的应用敏捷框架的汽车软件CV阶段开发过程

图1展示了一个高度概括的汽车产品开发典型的CV阶段，同时还展示了在每个子阶段完成时所得到的输出产品。图一还对敏捷框架与传统的V型流程进行了比较，以确保在子阶段结束时软件符合ASPICE及IS026262的要求。

Pre-Sprint阶段

在此阶段，软件团队聚合在一起，讨论与编制软件开发所需的关键输入和先导事项。该阶段还将进行Sprint规划。这将有助于团队明确目标，并使所有团队成员有一个清晰而统一的项目计划和项目目标。

敏捷宣言指出，在开发团队内部传达信息最有效的方式是面对面讨论。Pre-Sprint阶段必切实进行充电的面对面讨论，以确保团队具有统一的CV目标、具体的交付日期、里程碑和并以此建立一个明确的计划展示板(Program Board)。

图2：Pre-Sprint 阶段

在CV期间，Pre-Sprint阶段一般持续4-6周，并在所有团队成员的参与下达成一个DIA(Development Interface Agreement, 开发接口协议)，系统级需求和FSC / TSC(Functional Safety Concept 功能安全概念/ Technical Safety Concept 技术安全概念)。这些文档将作为锚点(anchor)，指导敏捷团队完成整个CV sprint，并确保CV阶段具有明确的目标和任务规划。

对于DV阶段，Pre-Sprint需要稍长一些(8-12周)。DV阶段的Pre-Sprint需要在CV阶段产出的可工作系统上对需求进行细致而系统的分析，并进行HARA(Harzard Analysis，Risk Assessment)、软件FMEA，最终形成一个合格的Safety Case。

(译者注：Safety Case 我不太确定要如何翻译，它是指一个全部安全相关文档的总集，一旦编制成功就进入冻结模式，以作为后续软件开发的安全指导。如果将来产品发生安全责任事故，Safety Case也是划分责任的重要依据。另，对于HARA和FMEA的定义，可以阅读我的另一篇文章：

https://www.zhihu.com/question/27719391/answer/183848931)

在此阶段结束时，团队将创建清晰的DV backlog(待执行任务集？)，以指导团队在Sprint阶段实现明确的产品安全目标。

Sprint 阶段：

Pre-sprint阶段为项目设立了明确的目标，而Sprint阶段则是汽车软件敏捷框架的核心。敏捷团队将以此编制软件需求文档和完整的软件并进行完备的测试。每个Sprint将持续4到6周。需要特别注意的是，在每个Sprint都应该迭代出一个新的、可工作或者说“可展示”的软件。如果一个项目阶段没有任何“可工作”的成果软件或者产品，则这个项目是绝对不适用敏捷开发框架的。比如说这个项目阶段的成果不能是DOORS 模块(译者注：DOORS是一个汽车行业通用的需求管理软件)，也不能使Word 文档，而必须是"可工作"的：可以是一个可执行文件，或者是一个可运行的仿真程序。

图1和图4展示了软件Sprint阶段的工作过程。软件在每个Sprint中迭代开发，并随着Sprint的进行而逐渐完备成熟。这种开发流程的一个明显优势是将软件需求文档的编写与软件编制实现结合在了一起。如果某些软件设计不正确，那么相应的需求文档将被重新编写，软件进行重构并快速集成这个新的变更，并且很快就能得到测试的反馈。在某种程度上而言，每个Sprint代表了一个迷你的V型循环。因此，根据定义，当每个Sprint完成时，团队产出一个可工作的软件，以及和该软件内容匹配的需求文档及测试用例文档。这使得整个软件开发过程变得非常灵活，随时可以应对来自各方得任何新要求。当面对新需求时，团队所需要做的就是对其进行评估并，引入到下一个Sprint中即可。

图3. Sprint 阶段

对于CV阶段的Sprint，团队的目标是在所有Sprint完成时拥有一个可工作的软件，并且其相关文档全部完整。也许该系统仍不能应用于公共道路，但是它必须拥有足够的安全机制来满足在封闭的测试场中使用(这也是为什么在CV阶段一定要建立FSC和TSC)。

对于DV 阶段的Sprint，团队的目标是在Sprint结束时对CV阶段的软件进行了基于安全需求分析的重构，并完成了全部诊断功能的编制。这个软件必须经过了充分的测试以验证所有功能和安全性。最终DV阶段产出的软件需要能够在公共道路上使用。

图4：应用敏捷框架的汽车软件DV阶段开发过程

Post-Sprint 阶段

Post-Sprint阶段一般为期4周。它用来审查刚刚完成的Sprint阶段，让团队有时间思考Sprint期间遇到的挑战和获得的成就。整个软件开发团队都必须参与Post-Sprint，并讨论得出一些可以在后续开发中需要改进的事项。Post-Sprint阶段还应进行一些主观与定量相结合的评测评估，以便吸取经验教训，更好的完成后续项目。

另外，Post-Sprint阶段的另一个重要任务是完善从需求文档到测试文档的可回溯性文档，以便在阶段结束时实现对ASPICE过程的合规。

写在最后

通过本文的讨论，在汽车软件开发中应用敏捷框架也可以高度满足ASPICE和ISO26262的要求。与传统的“瀑布式”或“V型”流程相比，这种方法更适合当前快速变化的汽车市场。在CV 过程总中同步编写需求文档和软件并进行迭代测试，将显著减少传统开发流程中的“长循环”所浪费的时间。在DV 过程中对软件进行基于安全分析的重构，保证了软件的安全性，可以完全符合ASPICE和ISO26262的要求。

最后，业界多年来在如何开发安全的汽车系统方面产生了大量的经验教训。如果没有真正将适合汽车行业特点的敏捷框架建立起来，就贸然投身这股“敏捷”的潮流，只会编制出缺乏安全性和完备性的软件系统，并且让公众失去对汽车行业来之不易的信任。我希望这篇文章能够证明在汽车软件开发中应用敏捷框架是可行的，并且应用敏捷框架所带来的收益，将远远超过转变到敏捷框架的过程中所带来的损失。

应原作者，也就是我以前的Mentor的要求把联系方式写在最后