In Focus: ASTech Process Model

by Stefanie

Dive into the VAIVA process world: With her report Stefanie takes you on a journey to the ASTech process model and explains how APM was developed, why a waiting time was quite important and when the way to the APM was sometimes rocky.

APM – What is it?

The APM is our process model (former: ASTech process model). It provides processes, methods, templates and instructions for embedded system and software development at VAIVA. Our goal is to develop a central standard process model for embedded system and software development at VAIVA, which is compliant with the norms and standards required by us (ASPICE, IOS26262, KGAS). We want to define consistent solutions and clear responsibilities.

APM – How did this come about?

However, the way  going there was not an easy way. 2016 – when we were in the middle of developing the PreSense features: Here we were responsible for the entire development (function and software) of the predictive safety functions, such as PreSenseFront, for the second generation of the safety computer. At peak times a total of around 100 people worked on the implementation.

At that time, we used an external Process Method Tool (PMT) for the development, which was intended to provide both a process and a tool solution. However, we quickly realized that this model unfortunately did not meet the specifications that were required of us as VAIVA. We repeatedly encountered problems where the development team had to define the process and methods in addition to the actual development of our functions. During this time, the software development team came up with the idea of recording best practices and instructions step by step so that they can be used again for subsequent projects. Gradually, the decision to tackle the process topic solidly was consolidated. A process working group was established and the work began.

The biggest problem with the external PMT solution was that that it was not practical. We wanted to avoid this with our own model. Therefore, our process team consisted of employees from different specialist areas (e.g. software development, architecture, integration and testing). It should become a process of developers for developers. In this way, we wanted to ensure that our processes should have a high level of acceptance in the team from the scratch. Our processes should meet the requirements required by us (ASPICE Level 2, KGAS, ISO26262), but also be easy to use.

Not everything went smoothly, none of us has developed processes so far and there were no exact specifications yet. Especially at the beginning, this led to the fact that the individual teams designed the processes very differently both formally and in terms of content. In mid-2019 the System Process Working Group started parallelly with a small team to set up the system process, which did not exist until that time, for VAIVA.

Another project team was to use the new processes for the first time for the upcoming series projects – the first development with our VAIVA processes started. But as expected, not everything went smoothly here at first too. During development, problems repeatedly arose, such as unclear specifications for our SDRS (Software Detailed Requirement Specification). However, since a large part of the project team was also involved in the creation of the processes, we as a team were able to find suitable solutions together again and again. It was also helpful that the processes and methods were our responsibility and in this way we were able to provide solutions quickly.

The biggest reward for the team then followed with the ASPICE assessment, where a level 1 was achieved for all processes, as required. The GAP analysis for Level 2 in November 2021 also shows that we are well on the way to pass the.

APM – What’s next?

Our processes are not yet finished, the gaps found still have to be solved, as well as further improvements for easier applicability, still have to be implemented. We also want to bring the system and software processes closer together. Therefore, in October, the VAIVA processes that had emerged until then officially became the APM (former: ASTech Process Model).

What happens next? The topic of process and method development is further steered into professional paths. We are constantly trying to further develop and improve the APM. We also work together with the DevOps and DevFramework team to provide suitable tools for a holistic VAIVA PMT solution.