这本文章详细为你讲解了复杂汽车软件缺陷管理的思考与探索的题和一些关于汽车厂管理软件相关的话题，希望对大家有帮助!
项目正在逐步上线，但是最近被bug卡住了，出不来。
这种无法逃避自己的含义有两个第一是很难逃避自己，尤其是到了后期，因为大多数人把大部分精力集中在写bug、测试bug、分析bug、计算bug上。第二个层次是不愿意走出自我。最后，跟踪一个有详细记录的错误相对简单且相对值得。
当今汽车软件项目的前五个关键词是什么？其中，Bug是不可避免的一部分，毫不夸张地说，即使在项目的中后期，Bug也决定了项目的运行。
本文将对此进行简要反思和探讨。
一
流程——错误管理
没办法，但是在研发管理方面，对bug的评价和鉴赏还是相当不错的。错误管理是当前汽车软件开发流程的示例，从根本上讲是流程标准化和数字化。或者说在合作方面。
总结起来，可能有以下三个原因
11软件的预期效果和传播
前景效应是一种行为心理学模型，表明大多数人在面临利益时会规避风险。
在出现Bug的情况下，早期的规范管理、优化设计和测试可以减少以后出现Bug的可能性，这是一个潜在的好处，但不做这些活动可以立即减少工作量并提高交付速度。这是一个明显的好处.利润。
也就是说，当今天的某个利益与未来更大的潜在利益进行比较时，每个人仍然更喜欢前者。在当前的“长期”环境中尤其如此，创新今年可能无法生存。当然，错误最常在中后期暴露出来。
另外，随着汽车上安装的软件数量的增加，软件bug的数量自然也会增加，并且在实际项目中这一数字非常明显。过去，消除bug似乎是传统ECU开发和量产中的常规要求。生产交付，但现在留下数十个、数百个甚至数千个bug已成为越来越不可避免的常态。
大量的Bug为Bug管理提供了充足的原材料。
12汽车软件错误很复杂
汽车软件不是单一的，错误通常也不是单一的题。多个ECU可能会引入错误，尤其是在当今多样化的跨模块、跨系统和跨域功能定义架构中。您至少需要几个ECU。只有稍后你才能得出结论。
即使重点关注单个ECU，也必须将其分解为多个软件模块并逐层分析。此外，汽车软件往往不仅包括软件题，还包括算法、校准、硬件甚至机械结构的综合影响。
这种技术复杂性需要良好的错误管理。
13个汽车软件错误包括很多方面
bug的复杂性主要在技术层面，而简化技术复杂性的方法就是将其拆分、拆分，但是拆分之后，显然会涉及到很多人，很多人有不同的需求。功能。
不同的职能，比如工程、质量、生产、市场等，会有不同的立场，不同的立场会把一个技术题变成政治题，而一旦变成政治题，解决的方法有很多。
利益相关者的这种复杂性继续对顺畅的错误流和信息透明度提出要求。
这就是当前汽车软件缺陷管理的背景，它似乎正在迫使缺陷管理成为更好的模式。
但这并不能阻止bug仍然是开发中的一个题，因此有必要继续深入钻研一些优化方向。
2
题和错误
考虑到上述汽车软件的特点，可以尝试另一种更系统、更复杂的想法。
首先，我们先建立两个概念题和bug。
ProbIem是指产品没有达到预期的行为，可以面向项目、面向系统、面向车辆、发现题等，而且还是在汽车管理层面。
Bug是指偏离技术层面、组件导向、子系统导向、软件导向、题解决者导向等的偏差，属于软件工程维度。
Bug充当精子来解决粗父题，两者可以是n对n的关系。
这种拆分至少有三个优点，主要体现在解耦上。
将汽车制造和软件分开，以便复杂的汽车制造活动和更简单的软件规则不会相互干扰。
管理和工程分离，允许复杂的管理人员和简单的工程师执行单独的任务。
它将软件与软件分开，并允许涉及题的每个人同时前进，即使他们负责不同的软件。
当然，这种划分还具备以下前提
组织足够大。
题够复杂的
角色划分足够详细
ALM工具非常熟悉。
如果一个小型开发团队只解决通过自己的测试发现的题，那么题和错误之间的区别就变得没有意义了。
三
有一天，出现了一个题。
理论上，每个人都可能面临产品性能与预期不符的情况，而这种情况自然会发生在日常测试，以及开发、审批、试驾、生产、售后服务等各个环节。因此，任何发现题的人都可以访提及你的题。
当然，根据我们的项目经验，我们会重点关注两个角色PM和Tester，他们基本上处理外部题并提出内部题。
我们还应该努力满足两个原则提出题时更细粒度和以价值观为导向的观点。陷入题战的汪洋大海汽车的存在就是要有牵引力，这对于当今功能多、题多的座舱产品来说至关重要。特征。
提出题时撰写和传播具体内容并不容易，一般至少应体现以下基本内容
完整题描述一点测试你的中文水平。最好能用一句话说出来，用一句话明白需要做什么，真正的题是什么。换句话说，确切的题是什么。基本原则是解释可以在组织内和项目内轻松传达。
存在题的组织如今，许多汽车软件都是跨多方和组织协作开发的。从供应链角度看待复杂题时，了解题存在于哪个组织级别非常重要。软件、芯片或软件提供商，无论是OEM、Ter1还是第三方。当题跨越多个组织时，通常会涉及不同的流程系统要求。
题发现阶段从V链角度看。这取决于题在整个开发周期中的哪个位置，从代码到车辆销售后。不同阶段的题自然面临不同的参与方，有不同的处理策略。
题级别一般可以从产品本身的严重程度和项目进展的时间优先级两个角度来评估级别，但实际判断基本是鱼龙混杂。高严重性题通常具有高优先级。通常有3到5个级别，这对于统一组织的沟通语言和标准化流程非常有帮助。例如，不同严重程度的题需要不同的分析和反馈周期。
经理经理可分为团队和个人两个单位，团队经理综合考核团队绩效和包管理，个人经理是具体题进展的负责人。由于题通常以交付为中心，因此主要担任PM类型的角色是有意义的。
时间信息各种时间要求或时间戳有助于定义题目标和分析题，通常包括截止日期、计划日期、发生日期、建议日期等。
支持信息对于题，重点关注建议。专注于清楚、完整地解释事情。除了传统的预期结果外，还可以提供实际结果、发生环境、软硬件版本信息、车辆性能或型号等。假如。此外，总线或ECU内部的日志数据以及视频、录音和照片是后续分析的重要数据。
分析和解决方案信息当涉及到一个题时，整体的分析和最终的结论当然是关键信息，经过分析，你可能认为这不是题，应该被拒绝，也可能是有题，但反之，实际上可能存在题，需要维修。在所有情况下，都必须有清晰的书面记录。
更改状态不需要将题的状态设置得很复杂，可以分为几类新建、分析中、已获得解决方案、已获得解决方案、已关闭等。
其他驱动因素在汽车行业，有时会根据题本身的重要性和复杂性来驱动8D、DFMEA和LL等其他任务。
通常，题被认为是与汽车软件相关的题，重点是通过管理解决汽车题或系统题。
4
输入有题的错误
当出现系统性题时，迫切需要对系统架构师、系统工程师、软件专家或具有系统知识和经验的角色进行初步分析和任务分配。
当然，有时将题的第一位分析师分配给直接受影响的特定软件模块或功能的所有者可能会更有效。
具体的分析和分配结果可能会反映为一个或多个错误，然后开始解决这些错误，直到子服务的父螺旋桨，从那里开始实际的软件错误解决。在这里，有时还需要将题与其他现有的错误关联起来，以便收集资源。
与发布者相比，题是由题发现者提出的，而错误是由题解决者提出的。
另外，从Bug的具体演化过程来看，除了题类的信息类别外，更应该注重Bug的根源分析和解决方案的识别，也应该更加技术化、软件化、更加化。详细的。包括但不仅限于
缺陷详细信息哪个状态机阶段、哪个模式、哪个配置、具体用例、违反了哪些要求或设计要求以及底层技术机制是什么。
受缺陷影响的工件，例如软件组件、各种文件版本等。这些都是缺陷的一部分，需要维护和服务来解决题。
缺陷的影响评估维度可能包括监管、安全、功能、下游测试、生产线启动、消费者投诉以及相关项目或产品线。这个内容本身不是软件，但是可以深入。一定深度的软件技术可以让你更深入地了解其影响。这也决定了题的响应策略，因此在错误分析阶段需要更高的系统级角色参与或提供输入。
临时措施和长期措施当面临项目或下游客户压力时，有时需要采取临时权宜之计或权宜之计，以解决样品交付、车辆建造和测试等紧急需求。此后，长期措施的出台将在相对充足的时间内完成。
缺陷验证状态还应体现验证方法、测试用例、测试结果等相关信息，以明确缺陷实际上已被修复。
缺陷引入阶段这部分的信息可以认为是一次经验回顾，确定是否需求不明确，设计不合理，程序员编码马虎，或者题进行了沟通，这对后续工作会有帮助。改进。
详细的风险评估如果Bug所面临的题比较严重，并且无法及时修复集成，则可能需要进行详细的风险评估，其中可能包括详细的FMEA评估、PPM计算、特定用例的测试等。
状态更改与题不同，错误的状态可以随软件而变化，并且可以标记为新的、已分析的、已识别的根本原因、已编码、已审查的代码、已集成、已测试或已完成，通常取决于软件开发过程。关闭等
一旦所有子错误都被关闭，父题也可以被关闭和转发。
5
可能的挑战
与上述想法相关，在今天的现实中，您更有可能面临以下挑战
题太多了，我没有精力在这个层面上去解决。
项目很紧急，我没有时间做这样的计划。
No Comment