Tech Blog – Co je ASPICE? Úvod do světa softwarové kvality v automobilovém průmyslu

Jindřich Balák

System and Software Quality Team Leader, vývojové centrum Valeo v Praze, Certified ASPICE Provisional Assessor

ASPICE

Automotive Software Process Improvement Capability and dEtermination

První věc, která mnoho lidí ve vývoji softwaru napadne ohledně výrazu “softwarové kvality”, jsou zvýšené náklady v projektu, práce nad rámec běžné pracovní náplně (kterou dosud dělat nemuseli), či dokonce některým může přijít na mysl, že oddělení kvality je nutnou přítěží, kterou vyžaduje pouze zákazník.

Co v praxi taková softwarová a systémová kvalita opravdu dělá?

V případě, že žádné problémy na projektu nejsou, všechny procesy jsou správně implementované a žádné nálezy během vyhodnocení či auditů neexistují, pak právě takový je vysněný projekt každého kvaliťáka, protože v takovém případě se může soustředit jen a pouze na doručení svých vlastních úkolů (“deliverables”), provádění vyhodnocení a auditů na projektu, případně revize projektových dokumentů.
Projekty v reálném případě mají mnoho problémů a úskalí, s kterými se musi nejen vývoj, ale take kvalita potýkat.

Pravdou ale je, že softwarová a systémová kvalita řeší mnoho různých dalších aspektů projektu, jako jsou sledování vývoje projektu v čase, plnění předepsaných a odsouhlasených požadavků mezi zákazníkem a projektem, upozorňuje na problémy a také jim předchází, provádí různé audity a posouzení nejen na přidělených projektech, ale i nezávislé posouzení na základě požadavku z jiných Valeo vývojových center (v našem případě se může nacházet i na jiném kontinentu).

Proč potřebujeme ASPICE?

Komplexita v automobilovém průmyslu je čím dál tím větší a to včetně SW částí. Dříve se výrobci zaměřovali nejvíce na kvalitu a vývoj mechaniky, ale nyní se výrobci soustředí na SW automobilů, který se stává hlavní přidanou hodnotou vozů. Právě management a linkování požadavků jsou hlavní problematikou z pohledu komplexnosti, rozdílnosti automotive systémů a redukce rizik s nimi spojených. Vývojový cyklus produktů se zkracuje, tlak na efektivitu, doručování dodávek v čase a požadované kvalitě se stupňuje.

Ve většině případů je Automotive SPICE základním předpokladem pro nové i stávající dodavatele evropských výrobců vozidel.

Představení ASPICE

Automotive SPICE je hlavní model pro posuzování schopnosti a maturity procesů v automobilovém průmyslu. ASPICE v zásadě definuje nejlepší postupy pro embedded software.

ASPICE je standardem používaným pro zlepšování a hodnocení vývojových procesů mechatronických systémů se zaměřením na softwarové a systémové části produktu.

ASPICE je aplikovatelný pro agilní metody i pro oblasti Functional Safety a Security. Aktuální automobily mají mnoho bezdrátových spojení s vnějším světem. Security oblast ve zjednodušeném pojetí automotive znamená, že při vývoji produktu jsou použité takové metody a ochranné mechanismy, které mají za úkol zabránit ovlivňování produktu přístupem zvenčí. Functional Safety se uplatňuje v automobilovém vývoji v systémech, jejichž nefunkčnost či jejich špatná funkce může ohrozit zdraví posádky.

Přehled jednotlivých úrovni maturity, tzv. Capability levelů (CL.x) v pyramidě.

CL 0 – nebyl dosažen žádný level, procesy nejsou implementovány nebo nesplňují jejich účel
CL 1 – implementace procesů splňuje jejich účel
CL 2 – procesy jsou implementované, řízené a všechny WP jsou existující, pod kontrolou a udržovány (aktuálně nejčastěji zákazníky vyžadovaný ASPICE CL. )
CL 3 – procesy jsou implementované na základě definovaných procesů a dosahují požadovaných výstupů
CL 4 – procesy fungují prediktivně v definovaných mezích a dosahují výstupů
CL 5 – processy se stalé zlepšují, aby reagovali na změny v souladu s cíli organizace

ASPICE assessment

Cílem posouzení (assessment) je získání informace o stavu projektu z pohledu procesů a jejich implementace na daném projektu v určitém časovém bodě a podle definovaného standardu. ASPICE assessment je v mnoha případech vyžadován zákazníkem (a také se ho poté i účastní), kdy zákazníka zajímá odhalení problémů a aplikované postupy a procesy na projektu. Také zda je maturita projektu ve fázi slíbené zákazníkovi, tzn. ověření při účasti zákazníka, zda vývoj produktu po dvou ze třech plánovaných let je v pokročilé fázi, nikoliv teprve ve fázi počáteční. Má to souvislost i s tím, že se zákazník může finančně podílet na samotných vývojových nákladech.

ASPICE assessment se skládá z :

R&D tým

Vývojový tým alokovaný na příslušný projekt.

Místní koordinátor ASPICE

Podporuje správnou organizaci assessmentu, kooperuje s Lead assessorem a R&D týmem, ale zároveň by neměl zasahovat do průběhu assessmentu tak, aby ovlivnoval hodnocení R&D týmu. Toto naopak může podpořit během assessmentu Procesní inženýr.

Lead Assessor

Je hlavním členem týmu, řídí assessment a prezentuje výsledky assessmentu R&D týmu a vedení firmy.

Co-Assessor nebo více Co-Assessorů

Může se jednat o zákazníka, který si assessment vyžádal, případně o další interní nezávislé assessory, kteří se podílí na výsledcích hodnocení assessmentů. Ve většině případu se jedná o rozsáhle projekty, kde je alkováno mimo Lead Assessora celkem 3-5 Co-Assessorů, samožřejmě v závislosti na velikosti daného projektu.

Assessor musi mit platnou certifikaci Intacs.

V tabulce níže je možné vidět příklad výsledku hodnocení projektu podle procesů:

Process reference model, přehled jednotlivých procesů dle VDA ,které jsou označené červeným rámečkem. Procesy jsou rozřazeny do tří základních životních cyklů:

Podpůrné VDA: ACQ.4 – monitorování dodavatelů

VDA: SYS.x a SWE.x – Inženýrské procesy vývoje

Organizační VDA: MAN.3 – projektový management
Podpůrné VDA: SUP.x – Kvalita, změnový, konfigurační a problém management.

Klíčový koncept (V-model, standard vs. process, traceability)

Není cílem zde vysvětlovat pravidla vývoje a popis pravidel prolinkování Doors modulů na jednotlivých levelech. Moduly v systému IBM Doors lze v jednoduchosti vysvětlit kupříkladu jako souhrn požadavků a jejich atributů do těchto tzv. modulů podle jejich určení.( Např. SYS.1-5, SWE.1-6, STKHLD, apod.). Provázany mohou být jednotlivé požadavky horizontálně na jednotlivé testy v testovací specifikaci, vertikálně, případně mohou být provázany i v rámci stejného modulu mezi sebou. Důležité z pohledu ASPICE je také sledování nastavených procesů dle standardů v projektu, a také zda jsou projektem následovány a naplňovány.

Časté problémy na projektech z hlediska ASPICE

Omezené lidské zdroje na projektu, kdy se výsledky tvoří způsobem ,,quick and dirty“, což způsobí problémy v budoucích fázích projektu a jejich retrospektivní opravy. Tento způsob je méně efektivní, vice nákladný a zmatený, ale bohužel někdy nevyhnutelný.
systémová a softwarová kvalita není všespásná, konkrétně mám na mysli přístup stylem ,,Ty jsi zodpovědný za ASPICE, takže za nesplnění či nedosažení nastaveného cíle může kvalita.“ , Toto tvrzení je naprostý omyl, a to i naopak: myslet si, že pokud úspěšně projekt dosáhne svých cílů, tak to není zásluhou jen kvality. Vždy jde o spolupráci vývojového týmu a oddělení kvality, ani bez jednoho z nich není možné uspět.
Podcenění monitoringu projektu / implementace nástrojů pro sledování stavu projektu s časovým zpožděním. V tomto případě se jedná především o to zajistit správné nastavení filtrů pro atributy požadavků, implementace V-model reportu, tedy stavu zákaznických požadavků a jejich sledovatelnosti. V takovém případě může projekt mylně nastavit priority pro implementace požadavků, jejich testování a následné doručení softwarového balíčku s jinými funkcionalitami, které v tu danou chvíli nejsou očekávány zákazníkem a naopak nedoručení požadovaných funkcionalit v daném software release.

Pokud vás problematika ASPICE zaujala, doporučuji si podrobně přečíst kompletní ASPICE standard: Automotive SPICE 3.1 a Automotive SPICE for CyberSecurity