An ASPICE Overview

Now that you’re well-versed in the Waterfall Model and V-Model, it’s time to take the step up into a wider world of ASPICE.

I won’t bore you with the details of its pedigree but ASPICE descends from a line of ISO documents concerned with setting up standards around software development. ASPICE stands for Automotive SPICE and SPICE stands for Software Process Improvement and Capability dEtermination (sounds better in the original Klingon). SPICE set out to provide a framework for assessors to judge an organization’s capability for software development and delivery. The assessment’s score could then be used by customers when searching for software suppliers. It is akin to ISO 9000, CMMI, and other attempts at putting a fence around your cowboys in the software department. SPICE didn’t really take off except in Germany’s automotive industry, specifically an effort sponsored by the Verband der Automobilindustrie (VDA, in English: “Automotive Industry Association”) that tailored SPICE for their industry, which resulted in ASPICE.

(The Automotive SPICE® Process Assessment Model (PAM) document can be downloaded here: http://www.automotivespice.com/download/)

With the heft of German auto manufacturers using ASPICE on their suppliers, the standard spread. ASPICE became a method for many automotive manufacturers and suppliers to judge how well your organization can develop systems and software using an open standard defining best practices. If your way of system and software development conforms to ASPICE and can be proven with evidence, your customers can be assured that you know what you’re doing and thus decrease the customer’s risk in choosing you as a supplier.

We now know where APSICE came from; so let’s actually dig into it! ASPICE is divided into process groups. We will focus on the System Engineering Process Group (SYS) and the Software Engineering Process Group (SWE) which are based on the V-Model.

Figure 1 – Automotive SPICE process reference model – Overview (Figure 2 in ASPICE PAM)

The ASPICE development model starts with the SYS.1 Requirements Elicitation process where the customer’s stakeholder requirements are received, analyzed, discussed, and understood. Using the customer’s stakeholder requirements as a foundation, the system requirements are created, updated, and reviewed during the SYS.2 System Requirements Analysis process. Trailing a little behind SYS.2 activities, system tests are developed and linked during the SYS.5 System Qualification Test process providing early feedback about the system requirements. Next, during the SYS.3 System Architectural Design process, the system’s architecture is designed and documented. System integration tests are developed in parallel during SYS.4. The cycle repeats in software. SWE.1 develops software requirements, SWE.6 develops their tests. SWE.2 designs the software architecture and SWE.5 works on software integration tests. At the bottom, the tip of the “V”, the SWE.3 Software Detailed Design and Unit Construction process focuses on the details of the software design and actual programming while creating unit tests for the SWE.4 Software Unit Verification process. When looking at the entire development process, a pattern of linking between previous and next processes (and to the right’s tests) emerges. Each link (up/down, left/right) provides traceability to why this or that is the way it is and gives an opportunity for review and feedback.

Defined for each ASPICE process is a set of “base practices”. Following and implementing the base practices, and providing evidence, is essentially how an organization shows compliance with ASPICE. For example, the first base practice for the SYS.2 System Requirements Analysis process is:

SYS.2.BP1: Specify system requirements. Use the stakeholder requirements and changes to the stakeholder requirements to identify the required functions and capabilities of the system. Specify functional and non-functional system requirements in a system requirements specification.

The base practices cover the essential activities that ensure a system and its software is developed in a sane and traceable manner. However ASPICE does not stipulate how to conform to its base practices. Typically heavy-duty industrial (i.e. expensive) tools are used manage the SYS and SWE processes, e.g. DOORS*, IBM’s Engineering Lifecycle Management (ELM) suite, Vector’s PREEvision, Polarion, Jama, just to name drop a few. If you want to store your requirements as sticky notes in a binder (a real suggestion I heard a long long time ago), you’re free to do that as long as you can prove to an assessor they comply with all the relevant base practices. And that’s the hard part: interpretation and implementation. You have to read and understand ASPICE. You have to be familiar with the common methods and tools in the automotive industry. You need to be able to show the evidence during an assessment. You have to bring this all together AND actually make a product!

Tune in next time when I describe why ASPICE compliance presents an interesting challenge for SUSE.

* I simply adore DOORS. A cornerstone of building my career in requirements engineering and fulfilling a dream of living and working in Europe was my deep knowledge of DOORS. If you’ve used DOORS, you probably want to slap me in the face. That’s ok. I’m used to it.