A-SPICE – The journey continues
Hi there,
It´s Denis again and welcome back to my series of A-SPICE related thoughts and findings. In case you find it hard to follow, please read my first post. This should help you understand what I´m writing about.
What do we know so far?
In our last post we´ve learned what A-SPICE roughly means, who is affected by it, what each Level means and how each Level is defined.
A-SPICE – Process
Let´s get to the other half of A-SPICE, the process level. A-SPICE basically follows the approach of a V-Model, which means on the left hand side you define your requirements, architecture, software etc. and on the right hand side you deliver the proper testing/evidence showing that your product is working as specified.
From my perspective the V-Model is not really a new development approach. A lot of companies do already know it or develop based on it. So you may ask “why do we need A-SPICE, if V-Model is already established?”. The challenge is that its being used differentially by everyone. With A-SPICE the purpose is to standardize it so a minimum set of deliverables is guaranteed throughout the development supply chain. So if a OEM receives a externally developed component, he knows that at least all relevant documentation work products were generated and can be invoked if needed.
The processes within A-SPICE are divided into three areas.
– Primary Life Cycle Processes
– Organizational Life Cycle Processes
– Supporting Life Cycle Processes
Primary Life Cycle Processes
They mainly contain processes in the area of acquisition and delivery of products. It includes the development processes like engineering, design, development, integration and testing. In A-SPICE language spoken it affects ACQ, SPL, SYS, SWE groups.
Organizational Life Cycle Processes
It provides all relevant processes, resources, products to help the project achieve the companies business goals. It only uses the SUP group.
Supporting Life Cycle Processes
As the name already lets you suggest it “supports” all the other processes within the A-SPICE universe. For this you will use MAN, PIM, REU groups.
V-Model
As I mentioned the norm uses the V-Model, but there is much more!
In general we have following groups within A-SPICE:
- ACQ = Acquisition Process Group
- SPL = Supply Process Group
- SYS = System Engineering Process Group
- SWE = Software Engineering Process Group
- SUP = Supporting Process Group
- MAN = Management Process Group
- PIM = Process Improvement Group
- REU = Reuse Process Group
Within every group you will find sub-processes. So in the SYS process group you will find processes like “SYS.1 – Requirements Elicitation” or in MAN process group “MAN.3 – Project Management”. Those processes describe in a more granular way what you have to do to fulfill the process/norm.
But maybe let me visualize this a bit more so it gets clearer.
Based on how I understand it, it should look something like this:
So this looks like a lot of work, and it is!
But I have some good news as well. From this set of processes there was a subset created which is being focused on when assessing. So from my understanding if you are being assessed than its possible that it only will happen on the so called HIS/VDA scope.
“What´s that?” you ask. Let me help you.
HIS/VDA-Scope
HIS (Hersteller-Initiative-Software) is a German automobile manufacturers working group who work together in the field of non-competitive issues relating to software development for control units, on the subject of process assessments. They have defined a subset of processes which describes the minimum set of assessed processes. Later it was renamed and taken over by the VDA, but both terms are being used today. So don´t get confused, they talk about the same stuff
But what processes do we now need
Based on our wonderful picture we can now see the red highlighted processes, which are relevant for the HIS/VDA Scope.
Thank you
so far for your time. I will continue in the next post with getting into each process and explaining the purpose and deliverables you need to fulfill.
NEXT UP
- SYS.2 – System Requirements Analysis
