Processes make all the difference! This also applies to the creation of software. Particularly to software - because unlike products that you can get hold of, the quality of software cannot be evaluated afterwards. In the near future, mobility without software will not be conceivable. Software provides more comfort, greater safety and controls the vehicle's drive system. More extensive networking and the growing degree of automation are increasing the complexity of the software functions implemented. Stable processes are essential if this complexity in development is to be mastered. Processes create the conditions for collaboration across company boundaries, in international teams and also in remote teams (development from the home office). ASPICE provides a framework for defining our own processes and evaluating their implementation in projects.
To enable the development processes and software quality to be assessed more effectively, several automobile manufacturers, most of them German, agreed on a process reference model for software development, first publishing the Automotive SPICE® (or ASPICE) standard in 2005. Derived from the international ISO 15504 standard for the evaluation of software processes, an industry-specific framework was created, to bundle best practices and facilitate the comparability of projects across companies.
However, ASPICE does not limit itself just to specifications for the software development process, but also, among other things, gives guidelines for project management, support processes such as quality management, problem solving, change management and configuration management.
The level indicates how well the processes are implemented.
In May 2020, EDAG Embedded Systems, part of the EDAG Electronics business unit, reached an important milestone in its process development: evidence that it is able to develop in accordance with ASPICE Level 2. As part of a customer project, an independent ASPICE assessment confirmed that, for each of the processes taken into account, maturity level 2 had been reached consistently. All software engineering processes, the support processes of the VDA scope, the requirements elicitation process and the project management process were evaluated. But what does level 2 actually mean and what did we have to do to achieve it?
The "capability levels" in Automotive SPICE® represent the maturity of processes:
- Level 0: The process is incomplete, unsuitable or non-existent.
- Level 1: The results of the process are available, but it is not possible to reconstruct how these results were arrived at.
- Level 2: The process is planned, monitored and documented. The responsibilities in the project are clear.
- Level 3: A generic standard process is described and, with slight adjustments (tailoring), can be applied to each project. The projects work homogeneously.
ASPICE describes two further levels, Level 4 and Level 5, both of which in practice (still) play a subordinate role. Experience has shown us that although ASPICE Level 2 is required in most cases, there are only a few projects in which every process taken into account can consistently demonstrate compliance with Level 2.
For Level 2, ASPICE always requires a process to be "managed": this means that it can be demonstrated that the processes are planned, monitored, and corrected if necessary. The work results must be drawn up, checked and maintained in an appropriate manner. All process steps must be documented to ensure that they are fully comprehensible (also to an outsider, an assessor, for instance).
This may perhaps sound trivial, but it cannot be achieved in a software development project without a profound understanding of the processes required and great discipline in their day-to-day implementation. For example, expenditure must be recorded every day by every employee, every change to a work result must be documented (who changed what, and when), consistency between documents and across tools must be ensured, and task planning must be updated every day so that it is completely up-to-the-minute. It must be ensured that the team is large enough and sufficiently qualified to be entrusted with the tasks concerned - and, should essential qualifications be lacking, qualification measures must be planned and put into practice. As a rule, this calls for several years of "process work" to develop the necessary maturity in an organisation.
The object of the project assessed is the development of software for a German premium car manufacturer. The software is to control the vehicle's high-voltage components for various operating states, including diagnostic monitoring of the high-voltage system and error reactions. Its development is model-based and hand-coded, entirely within the EDAG processes and tool chain.
What was necessary to achieve this degree of process maturity in the project?
The decisive thing was often the interpretation of the ASPICE standard: what does a particular standard mean, and how can it be implemented in the daily project routine? Although ASPICE asks the right questions, there are many different ways of dealing with the specifications.
The project team was not left to its own devices, but from the start of the project had the support of an existing process team who - in tandem as it were - provided coaching and were able to help with questions. The process team also had the task of regularly comparing the project with the ASPICE specifications, to identify anything the project team might have missed, and point out necessary measures.
What is more, the project team did not have to start from scratch. Since 2014, the organisation's know-how has been successively recorded in a series development process. A process team consisting of process owners, process modellers and a process manager work on the continuous development of the process. External support in the form of an experienced ASPICE consultant also played a role in the development of the process. A process owner is named for each process, and it is the task of this process owner to bundle the organisation's knowledge in a process description and continuously develop "his" process. The process tool we use for the process description and distribution is Methodpark Stages V7. This generic process served as the basis for the project that was assessed.
A third pillar is tool support. The tool-related implementation of the processes was given special credit by the assessors on account of the fact that procedures and ASPICE specifications had been automated. There is a ticket-based system for planning, allocating and tracking tasks. The Atlassian tools Jira and Confluence are at the centre of the tool chain, with corresponding apps for requirements management and test specification. Matlab/Simulink and TargetLink are used for model-based software development. The software version management is handled using the open source software GitLab. Parallel to the process, the tool chain is also to be further developed throughout the projects.
The point of designing the processes has always been to ensure a benefit to either the team, the customer, or the organisation. This enabled us to avoid any non-value-adding "process gratification".
It is all a question of the interaction between the individual actors. Every release was agreed with the customer and the project team with regard to content and deadlines, and coordinated by the project leader. Building on this, the tasks were planned and processed in order of priority, in two-week sprints. The customer receives regular software deliveries every few weeks, allowing the software to be tested in the vehicle, and early feedback to be provided. The customer must also do his share by handing over mature and approved requirements in time for the beginning of each release phase.
What lessons have we learnt?
Following the assessment, the project team were asked what they would now, i.e. after the assessment, leave out. Even the more pragmatic employees said "nothing". There can be no better feedback than that! It can thus be seen that the measures taken to establish the ASPICE process specifications proved to be of use to the project team. And the team is right behind the processes introduced.
These are the findings from our efforts to achieve ASPICE Level 2:
- A project does not achieve Level 2 just like that. The organisation has to put a great deal of intensive and serious thought into its development processes over a period of years (we would say at least 2).
- ASPICE specifications can be practically implemented - without formalism, without having to "satisfy" processes.
- Automation of the processes is a key to efficiency and to reducing complexity.
- Accepted processes are derived from practical applications, and reduced to the essentials.
- Short iterations. Short V-cycles, e.g. every 2 weeks, enable progress to be monitored precisely, and anything that needs correcting to be detected at an early stage.
- ASPICE and agile development do not rule each other out.
- From the very beginning, both the functional and non-functional requirements need to be evaluated and converted into concrete measures.
We regard the following as success factors:
- A basic understanding of the process is created in the project team, for example through coaching or training.
- A precise project order is the starting point for project planning.
- The ASPICE specifications are always interpreted with a view to customer benefit and practical feasibility.
- The goal "ASPICE Level 2" is anchored in the internal target values.
- Not only is the management behind this goal; it actively demands verifications.
- Before the start of each release phase, the stakeholders come to a binding agreement on which requirements are to be implemented.
Conclusion
We regard the consistent assessment of all the processes taken into account with Level 2 (a) as a great accolade for our project team, who not only supported process-related matters, but also helped to develop them further, and (b) as confirmation that we are on the right track with our efforts to create good development processes. As an organisation, our next steps are to establish ASPICE Level 2 in all series projects, and to undertake the verification of ASPICE Level 3 (which, thanks to the generically described series development process, is no longer a major hurdle).
The automotive industry is currently going through a phase of fundamental change, driven by changing customer expectations, the electrification of the drive system, and digitalisation. Increasingly, the solutions are software-based, and this affects the entire development process. The processes must follow the dynamics of this transformation, and even help to shape it.
For us, ASPICE is not a future issue - it is an issue with a future. The increasing complexity in automotive development can only be managed if we have good processes. EDAG Embedded Systems focus on process-oriented working methods and on the continuous adaptation and advancement of the development processes.
Our motto is therefore: Better process. Better projects.
Alin Javorsky, Process Manager for Embedded Systems, is responsible for the ongoing optimisation of the engineering and project management processes and their standardisation across the division's various locations. He can give you more detailed insights into EDAG Embedded Systems' approach to ASPICE projects. Or download our checklist. It provides you with the basic framework you need to prove in a corresponding assessment that you are implementing your processes in accordance with Capability Level 2.
