Automotive SPICE

Automotive SPICE, określany też skrótowo ASPICE, jest adaptacją standardu SPICE (ang. Software Process Improvement and Capability Determination – doskonalenie procesu tworzenia oprogramowania i ocena jego możliwości) opisanego w serii norm ISO/IEC 3300x, zastępującej dokument ISO/IEC 15504, dla branży motoryzacyjnej. Przedmiotem tych dokumentów jest referencyjny model procesów wykorzystywanych w wytwarzaniu oprogramowania wraz z towarzyszącymi im procesami biznesowymi oraz wytyczne do oceniania zgodności procesów wykorzystywanych w organizacji z modelowymi. ASPICE pozwala w sposób ustandaryzowany oceniać zdolność organizacji do wydajnego dostarczania niezawodnego oprogramowania dla branży motoryzacyjnej.

Zastosowanie ASPICE

Zgodność z ASPICE nie jest prawnie wymagana w projektach motoryzacyjnych, ale znaczna część podmiotów działających w branży przyjmuje ją za obowiązującą, zarówno projektach realizowanych wewnętrznie jak i częściowo lub w całości zlecanych innym podmiotom. Przykładem organizacji uznającej ASPICE za obowiązujący model jest VDA (niem. Verband der Automobilindustrie – Stowarzyszenie Przemysłu Motoryzacyjnego), do którego należy ponad 600 przedsiębiorstw, w tym producenci samochodów (m.in. Audi, Volskwagen, Mercedes-Benz i Opel), producenci przyczep i zabudów, dostawcy podzespołów, części zamiennych i akcesoriów oraz inne podmioty. Co istotne, ASPICE definiuje modelowe procesy związane z wytwarzaniem oprogramowania i sposób ich oceny, ale nie pokrywa wymagań innych standardów mających zastosowanie w projektach motoryzacyjnych, jak na przykład ISO 26262 definiujące normy bezpieczeństwa funkcjonalnego (ang. functional safety). W celu zachowania zgodności z dodatkowymi normami, stosowane procesy muszą zostać rozszerzone o elementy niezdefiniowane wprost w ISO/IEC 3300x.

Referencyjny model procesów

Procesy opisywane w modelu referencyjnym są zgrupowane w 3 kategoriach ze względu na rodzaj przedmiotowej aktywności. Są to:

• procesy podstawowe
• procesy organizacyjne
• procesy wspomagające

Kategoria procesów podstawowych zawiera procesy nabywania i dostarczania produktów lub usług, wraz z procesami inżynieryjnymi wykorzystywanymi do ich specyfikowania, projektowania, tworzenia, integrowania i testowania. Kategoria ta została podzielona na 4 funkcjonalne grupy procesów:

• Grupa procesów nabywczych – ACQ (ang. acquisition) – procesy wykonywane przez klienta (lub dostawcę występującego jako klient wobec jego poddostawców) w celu nabycia produktów i/lub usług.

o ACQ.3 – umowa kontraktowa (ang. contract agreement) o ACQ.4 – monitorowanie dostawcy (ang. supplier monitoring)

• • ACQ.11 – wymagania techniczne (ang. technical requirements)
  • ACQ.12 – wymagania prawne i administracyjne (ang. legal and administrative requirements)
  • ACQ.13 – wymagania projektowe (ang. project requirements)

o ACQ.14 – zapytanie ofertowe (ang. request for proposal) o ACQ.15 – kwalifikacja dostawcy (ang. supplier qualification)

• Grupa procesów dostarczania – SPL (ang. supply) – procesy wykonywane przez dostawcę w celu dostarczenia produktu i/lub usługi.

o SPL.1 – przetarg dostawcy (ang. supplier tendering) o SPL.2 – wydanie produktu (ang. product release)

• Grupa procesów inżynierii systemu – SYS (ang. systems engineering) – procesy opisujące pozyskiwanie wymagań od klienta oraz wewnętrznych i zarządzanie nimi, definiowanie architektury systemowej oraz integrację i testy na poziomie systemu.

o SYS.1 – pozyskiwanie wymagań (ang. requirements elicitation) o SYS.2 – analiza wymagań systemowych (ang. system requirements analysis) o SYS.3 – projekt architektoniczny systemu (ang. system architectural design) o SYS.4 – integracja systemu i testy integracyjne (ang. system integration and integration test) o SYS.5 – testy kwalifikacyjne systemu (ang. system qualification test)

• Grupa procesów inżynierii oprogramowania – SWE (ang. software engineering) – procesy opisujące tworzenie wymagań dla oprogramowania (wywodzących się z wymagań systemowych) i zarządzanie nimi, tworzenie odpowiadającej im architektury i szczegółowego projektu oprogramowania, implementację ich w kodzie oraz integrację i testy na poziomie oprogramowania.

o SWE.1 – analiza wymagań oprogramowania (ang. software requirements analysis) o SWE.2 – projekt architektoniczny oprogramowania (ang. software architectural design) o SWE.3 – szczegółowy projekt i implementacja jednostek oprogramowania (ang. software detailed design and unit construction) o SWE.4 – weryfikacja jednostek oprogramowania (ang. sotware unit verification) o SWE.5 – integracja oprogramowania i testy integracyjne (ang. software integration and integration testing) o SWE.6 – testy kwalifikacyjne oprogramowania (ang. software qualification testing) Kategoria procesów organizacyjnych składa się z procesów opisujących rozwijanie procesów, produktów i zasobów organizacji, mających pomagać w osiągnięciu celu biznesowego. Kategoria ta podzielona jest na 3 grupy procesów:

• Grupa procesów zarządczych – MAN (ang. management) – zawiera procesy, które mogą być stosowane przez wszystkie osoby zarządzające dowolnym projektem lub procesem w obrebie organizacji.

o MAN.3 – zarządzanie projektem (ang. project management) o MAN.5 – zarządzanie ryzykiem (ang. risk management) o MAN.6 – pomiary (and. measurement)

• Grupa procesów usprawniania procesów – PIM (ang. process improvement) – składa się z jednego procesu opisującego praktyki usprawniania procesów wykorzystywanych przez jednostkę organizacyjną.

o PIM.3 – usprawnianie procesu (ang. process improvement)

• Grupa procesów ponownego wykorzystania – REU (ang. reuse) – składa się z jednego procesu opisującego odnajdywanie szans na ponowne wykorzystywanie zasobów w organizacji (np. uniwersalnych komponentów oprogramowania).

o REU.2 – zarządzanie procesem ponownego wykorzystania (ang. reuse program management) Kategoria procesów wspomagających składa się z pojedynczej grupy procesów, które mogą zostać wykorzystane w trakcie wykonywania innych procesów.

• Grupa procesów wspomagających – SUP (ang. supporting)

o SUP.1 – zapewnianie jakości (ang. quality assurance) o SUP.2 – weryfikacja (ang. verification) o SUP.4 – wspólny przegląd (ang. joint review) o SUP.7 – dokumentacja (ang. documentation) o SUP.8 – zarządzanie konfiguracją (ang. configuration management) o SUP.9 – zarządzanie rozwiązywaniem problemów (ang. problem resolution management) o SUP.10 – zarządzanie żądaniem zmiany (and. change request management)

Poziomy możliwości procesów i atrybuty procesów

Atrybut procesu to jego cecha, która może być oceniana w skali osiągnięcia dająca miarę możliwości procesu. Przyjęty w normie zestaw atrybutów ma zastosowanie do wszystkich opisanych procesów. Skala osiągnięcia prezentuje się następująco:

• N (ang. not achieved) – nieosiągnięta (0-15%)
• P (ang. partially achieved) – częściowo osiągnięta (15-50%)
• L (ang. largely achieved) – osiągnięta w znacznej części (50-85%)
• F (ang. fully achieved)– w pełni osiągnięta (85-100%)

Atrybuty reprezentują poszczególne aspekty procesu i łącznie mogą opisywać poziom możliwości procesu mówiący o ogólnej zdolności jednostki organizacyjnej do wykonywania procesu i osiągania z niego dobrych rezultatów. Zgodnie z normą ISO/IEC 33020 przyjmuje się 6 poziomów możliwości:

• Poziom 0 –proces niekompletny – proces nie jest wdrożony lub nie realizuje swojego celu.
• Poziom 1 – proces wykonywany – wdrożony proces pozwala na osiągniecie jego celu.
• Poziom 2 – proces zarządzany – opisany powyżej wykonywany proces jest zarządzany (planowany, monitorowany i dostosowywany), a jego produkty wyjściowe są prawidłowo ustanowione, kontrolowane i utrzymywane.
• Poziom 3 – proces ustanowiony – opisany powyżej proces zarządzany jest wdrażany poprzez ustanowiony proces zdolny do realizacji jego celów.
• Poziom 4 – proces przewidywalny – opisany powyżej ustanowiony proces osiąga przewidywalne wyniki w określonych zakresach wartości. Pomiary ilościowe są zdefiniowane i wykonywane, a dane są analizowane w celu identyfikacji przyczyń wahań wartości. W razie potrzeby przypisuje się też akcje korekcyjne.
• Poziom 5 – proces innowacyjny – opisany powyżej przewidywalny proces jest w sposób ciągły udoskonalany aby odpowiedzieć na zmiany zachodzące w organizacji.