Allt du skulle vilja veta om A-SPICE (men varit för skraj att fråga om)

 

 

Hej Nicolas! Du är ju sk Competent Assessor för A-SPICE (Automotive Software Process Improvement and Capability dEtermination) och är ofta ute på uppdrag hos kunder för att antingen utbilda kring A-SPICE eller göra utvärderingar. Men för alla dem som inte riktigt har bakgrunden, kan du berätta lite om vad A-SPICE är och var det kommer från?

N: A-SPICE är en modell anpassad för bilindustrin för att mäta förmågan inom system- och mjukvaru-utveckling. Syftet med en värdering är att mäta processernas förmåga, identifiera kvalitetsrisker samt identifiera processförbättringar.

A-SPICE är en modell som ställer krav på olika områden, som krav, arkitektur och test (dvs VAD som behöver göras), men organisationer behöver bestämma på vilket sätt detta skall realiseras (dvs HUR det ska göras). Ett missförstånd är att organisationer definierar A-SPICE som sin process och ”beordrar” projekt att implementera A-SPICE, vilket sällan, eller snarare aldrig, blir bra. A-SPICE skall ses som en av flera kravställare på en organisations egen utvecklingsprocess.

A-SPICE är en av flera kravställare på en organisations utvecklingsprocess.

Varför behöver man bry sig om A-SPICE?

N: A-SPICE har blivit en de-facto standard i bilindustrin. Som leverantör är det ett krav från de flesta beställare eller OEMer. Man kan samtidigt också se den som en modell som hjälper dig att förstå styrkor och svagheter när man undersöker förbättringspotentialen i sin utvecklingsprocess.

Du gör ju utvärderingar av A-SPICE-efterlevnad, men vem är det som beställer en sådan genomgång?

N: Kunderna till utvärderingar är både leverantörer som har krav på sig att följa denna standard, men även OEMer som antingen själva vill undersöka sin egen efterlevnad eller vill granska sina leverantörer.

Och hur går det typiskt till?

N: Första steget är förberedelsen. Omfattningen och ramarna behöver sättas, tex vilket eller vilka projekt som ska undersökas. Sedan behöver man identifiera nyckelpersoner att intervjua, tex linjechefer, projektledare, arkitekter och utvecklare. Därefter samlar man in dokumentation av olika slag, både projekt-, produkt- och process-dokument som efterföljande granskas.

Därefter sker intervjuer på plats och en mappning mot förväntningar i A-SPICE sker. De som intervjuats får alltid en möjlighet att validera sina svar.

Slutligen görs en analys och det skrivs en rapport som beskriver vad som görs väl, vilka avvikelser som finns och vilken nivå av A-SPICE uppfyllnad man har per processområde (krav, projektledning, osv). Det ges även rekommendationer till möjliga förbättringar.

Vad får man ut av en utvärdering?

N: Man får en extern och oberoende bedömning av styrkor och svagheter avseende hur programvaran utvecklas i relation till A-SPICE. Man får också konkreta förslag till möjliga förbättringar som man kan arbeta vidare med. Detta ger kraft att verkligen ta tag i och gå vidare i sitt förbättringsarbete. Ofta känner man till en hel del av problemen, men har kanske inte kunnat prioritera att göra ett bra underlag.

Som extern assessor så kan man också en referera till hur det ser ut på andra liknande verksamheter, vilket ger en bra möjlighet att förstå eventuella problem och fördelar ur ett större perspektiv.

Vilka områden sticker ut som de med mest problem eller lägst förmåga?

N: Jag tänker främst på tre områden:

Quality Assurance. Ett område som ofta blandas samman med testning. Överlag finns det en låg förståelse för behovet av att objektivt följa upp efterlevnad av arbetssättet.

Integrationstestning. Här förväntas man verifiera sin arkitektur med fokus på gränssnitt. Många väljer att enbart testa systemet som en blackbox och förutsätter att de underliggande kopplingarna därmed är korrekta.

Processanpassning. Många definierar sina processer som ”one-size-fits-all”, medan de i verkligheten ofta behöver tillämpas olika (exempelvis för olika produkter och storlek på projekt). A-SPICE förväntar sig att processerna innehåller stöd för hur anpassningen ska göras. Till exempel genom att förtydliga vilka moment som alltid måste göras i stora projekt och vilka det räcker att göra i små projekt.

Händer det att man tar sig igenom en utvärdering helt utan anmärkningar?

N: Nej, oavsett hur hög processförmåga man har så finns det alltid anmärkningar, även om det kan röra sig om detaljer. Dessa anmärkningar behöver inte påverka vilken A-SPICE nivå verksamheten når men kan ändå vara intressanta för organisationen att åtgärda ur ett effektiviseringsperspektiv.

Om man har ett önskemål om att nå en viss A-SPICE nivå men utvärderingen visar att organisationen just nu når en lägre nivå, hur lång tid tar det typiskt att stänga gapet till den önskade nivån?

Generellt så säger vi att det tar 6–12 månader att gå från en nivå av A-SPICE uppfyllnad till en annan. Det skiljer sig dock rätt mycket då det förstås beror på vilken utgångspunkt man har. Vi rekommenderar att inte blint fokusera på gapet mot modellen utan att fokusera på de förbättringar som ger störst affärsnytta.

Det låter som att det kan vara lite pressande att bli utfrågad om detaljer kring hur utvecklingen verkligen går till – är det vanligt att man framställer sig som bättre än man egentligen är?

N: Det kan man tro, men min uppfattning är att det nästan alltid finns en väldig öppenhet kring vad som görs och inte görs. Ibland kan processägare och projektledare hamna lite i försvarsställning, men det finns alltid en vilja att få reda på hur saker ligger till. Det kan ibland vara lite skillnad i uppfattning kring hur väl saker är på plats mellan tex chefer och utförare, men i min erfarenhet är det i så fall alltid baserat på en ärlig, om än personlig, bedömning.

Det kan vara bra att veta att man kan jobba på så många olika sätt och ändå uppfylla A-SPICE, och detta är samtidigt en av de största utmaningarna för en assessor.

I dessa tider när agil utveckling vinner alltmer mark även i traditionella industriföretag – hur fungerar en utvecklingsmodell som A-SPICE tillsammans med detta?

N: A-SPICE och agil utveckling kan mycket väl fungera tillsammans även om de har delvis olika bakgrundsfilosofi. Vissa eftergifter kan behöva göras på den agila sidan, främst att man måste tillse att dokumentationsdelen sköts men också att vissa processer måste följas⁽*⁾. Men trots dessa eftergifter så kan man applicera en hel del principer och bli avsevärt mer agil än vad man var från början.

(* Jämför med de agila värderingarna: fungerande mjukvara viktigare än detaljerad dokumentation, individer och interaktioner viktigare än processer och verktyg).

Finns det någonting i A-SPICE standarden som du anser skulle behöva förbättras eller utvecklas vidare?

N: Det finns några områden som man skulle behöva titta vidare på, exempelvis Agila tillämpningar som skulle kunna bli ännu tydligare.

Det är dock viktigt att känna till att A-SPICE inte täcker allt. Områden som Safety och Security saknar egentligen täckning i A-SPICE, men låter sig utmärkt hanteras vid sidan av. Är man en aktiv användare av Open Source så täcks det i viss mån under intag (som vilken tredjepartskomponent som helst) men en komplett hantering av Open Source saknas.

Det som kanske är den största utmaningen för framtiden är AI och Machine Learning som kan innebära system som fortsätter utvecklas även efter den formella systemvalideringen.

Som sades inledningsvis är du det som kallas Competent Assessor, men vad innebär det och hur blir man det?

N: Competent Assessor innebär att man har rätt att leda en formell utvärdering. (Teamet består även av en eller flera så kallade Provisional Assessors som under ledning av en Competent Assessor - huvudassessorn - bistår med olika uppgifter.)

För att bli Competent Assessor så krävs rätt bakgrund inom mjukvara och systemutveckling. Man behöver gå ett flertal kurser och ha varit aktivt deltagande i ett antal utvärderingar som Provisional Assessor. En blandning av teoretisk och praktisk erfarenhet behövs alltså.

Avslutningsvis – vad tror du om framtiden för A-SPICE?

N: Jag är säker på att A-SPICE kommer fortsätta vara en de-facto standard för företag som verkar inom bilindustrin. Det förutsätter naturligtvis att man ser till att fortsätta utveckla standarden i samma takt som den snabba utveckling som just nu sker i området. Man behöver inte bara hantera det som är relevant och aktuellt utan även identifiera områden som man kan behöva en koppling till (som tex Safety via 26262 och AI) för att täcka in helheten.