Automotive SPICE: Różnice pomiędzy wersjami

Z Encyklopedia Zarządzania
m (Dodanie MetaData Description)
m (cleanup bibliografii i rotten links)
Linia 14: Linia 14:
}}
}}
'''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.
'''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.
 
==TL;DR==
==TL;DR==
ASPICE to standard oceny zdolności organizacji do dostarczania oprogramowania dla branży motoryzacyjnej. Zawiera modelowe procesy, które są podzielone na trzy kategorie: podstawowe, organizacyjne i wspomagające. Każdy proces ma przypisane atrybuty, które oceniają jego możliwości. ASPICE jest szeroko akceptowane w branży motoryzacyjnej, ale nie pokrywa innych standardów, takich jak ISO 26262 dotyczący bezpieczeństwa funkcjonalnego.
ASPICE to standard oceny zdolności organizacji do dostarczania oprogramowania dla branży motoryzacyjnej. Zawiera modelowe procesy, które są podzielone na trzy kategorie: podstawowe, organizacyjne i wspomagające. Każdy proces ma przypisane atrybuty, które oceniają jego możliwości. ASPICE jest szeroko akceptowane w branży motoryzacyjnej, ale nie pokrywa innych standardów, takich jak ISO 26262 dotyczący bezpieczeństwa funkcjonalnego.
Linia 25: Linia 25:
Procesy opisywane w modelu referencyjnym są zgrupowane w 3 kategoriach ze względu na rodzaj przedmiotowej aktywności. Są to<ref>VDA 2017, s. 12-15</ref>:
Procesy opisywane w modelu referencyjnym są zgrupowane w 3 kategoriach ze względu na rodzaj przedmiotowej aktywności. Są to<ref>VDA 2017, s. 12-15</ref>:
* procesy podstawowe
* procesy podstawowe
* procesy organizacyjne  
* procesy organizacyjne
* procesy wspomagające
* procesy wspomagające


Linia 75: Linia 75:


==Poziomy możliwości procesów i atrybuty procesów==
==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.  
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<ref>VDA 2017, s. 15-17</ref>:
[[Skala]] osiągnięcia prezentuje się następująco<ref>VDA 2017, s. 15-17</ref>:
* '''N''' (ang. not ''achieved'') – nieosiągnięty (0-15%)
* '''N''' (ang. not ''achieved'') – nieosiągnięty (0-15%)
Linia 93: Linia 93:


==Bibliografia==
==Bibliografia==
* Kreiner C. (red.) (2013), [https://d1wqtxts1xzle7.cloudfront.net/42459142/Automotive_Knowledge_Alliance_AQUA__Inte20160209-14765-u31p70.pdf?1455017229=&response-content-disposition=inline%3B+filename%3DAutomotive_Knowledge_Alliance_AQUA_Integ.pdf&Expires=1619559185&Signature=Mvn3VWzsni6a2yb2~ZPL34RAay3YhQHl69cx4pTB-o21I0OYA8x3wtin4MnDv9E1AmRFnPkIccvQET7kyFXR~oqcYQxrvHQE55dT07akW~xn5~5LZAEi1r3usoKA2Hgd4mYBNdIJeSRJISSbjzzzOU3By34HrWKm2yW59ykVkTtQtVjhDOFGc2L1NNhzDepDLY8evToR7ANUijonp23REY0wwixV0W-16fSLJLBIBX2p7~C9MM9IB8Q3lyLCIwKyvqlo1vPAIb9ksXQ8f3ci7mf4A44PjR9kcIZzpFfpqiNTZ65m87FsWA~tGk7UT437mJNrcGiyYbJFIExqOwvnJQ__&Key-Pair-Id=APKAJLOHF5GGSLRBV4ZA ''Automotive Knowledge Alliance AQUA – Integrating Automotive SPICE, Six Sigma, and Functional Safety'']
<noautolinks>
* Macher G., Much A., Riel A., Messnarz R., Kreiner C. (2017), [https://www.researchgate.net/profile/Andreas-Riel/publication/319453667_Automotive_SPICE_Safety_and_Cybersecurity_Integration/links/59bbc71e0f7e9b48a28de28a/Automotive-SPICE-Safety-and-Cybersecurity-Integration.pdf ''Automotive SPICE, Safety and Cybersecurity Integration'']
* Kreiner C. (red.) (2013), ''Automotive Knowledge Alliance AQUA – Integrating Automotive SPICE, Six Sigma, and Functional Safety''
* Macher G., Much A., Riel A., Messnarz R., Kreiner C. (2017), ''Automotive SPICE, Safety and Cybersecurity Integration''
* VDA QMC Working Group 13, Automotive SIG (2017), [http://www.automotivespice.com/fileadmin/software-download/AutomotiveSPICE_PAM_31.pdf ''Automotive SPICE® Process Reference and Assessment Model (release 3.1)'']
* VDA QMC Working Group 13, Automotive SIG (2017), [http://www.automotivespice.com/fileadmin/software-download/AutomotiveSPICE_PAM_31.pdf ''Automotive SPICE® Process Reference and Assessment Model (release 3.1)'']
</noautolinks>


{{a|Tomasz Sala}}
{{a|Tomasz Sala}}

Wersja z 13:10, 26 paź 2023

Automotive SPICE
Polecane artykuły

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.

TL;DR

ASPICE to standard oceny zdolności organizacji do dostarczania oprogramowania dla branży motoryzacyjnej. Zawiera modelowe procesy, które są podzielone na trzy kategorie: podstawowe, organizacyjne i wspomagające. Każdy proces ma przypisane atrybuty, które oceniają jego możliwości. ASPICE jest szeroko akceptowane w branży motoryzacyjnej, ale nie pokrywa innych standardów, takich jak ISO 26262 dotyczący bezpieczeństwa funkcjonalnego.

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 AutomobilindustrieStowarzyszenie 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[1]. 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[2]

Referencyjny model procesów

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

  • 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.
    • ACQ.3 – umowa kontraktowa (ang. contract agreement)
    • 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)
    • ACQ.14 – zapytanie ofertowe (ang. request for proposal)
    • 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.
    • SPL.1 – przetarg dostawcy (ang. supplier tendering)
    • 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.
    • SYS.1 – pozyskiwanie wymagań (ang. requirements elicitation)
    • SYS.2 – analiza wymagań systemowych (ang. system requirements analysis)
    • SYS.3 – projekt architektoniczny systemu (ang. system architectural design)
    • SYS.4 – integracja systemu i testy integracyjne (ang. system integration and integration test)
    • 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.
    • SWE.1 – analiza wymagań oprogramowania (ang. software requirements analysis)
    • SWE.2 – projekt architektoniczny oprogramowania (ang. software architectural design)
    • SWE.3 – szczegółowy projekt i implementacja jednostek oprogramowania (ang. software detailed design and unit construction)
    • SWE.4 – weryfikacja jednostek oprogramowania (ang. software unit verification)
    • SWE.5 – integracja oprogramowania i testy integracyjne (ang. software integration and integration testing)
    • 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.
  • 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ą.
    • 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).
    • 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 processes)
    • SUP.1 – zapewnianie jakości (ang. quality assurance)
    • SUP.2 – weryfikacja (ang. verification)
    • SUP.4 – wspólny przegląd (ang. joint review)
    • SUP.7 – dokumentacja (ang. documentation)
    • SUP.8 – zarządzanie konfiguracją (ang. configuration management)
    • SUP.9 – zarządzanie rozwiązywaniem problemów (ang. problem resolution management)
    • 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[4]:

  • N (ang. not achieved) – nieosiągnięty (0-15%)
  • P (ang. partially achieved) – częściowo osiągnięty (15-50%)
  • L (ang. largely achieved) – osiągnięty w znacznej części (50-85%)
  • F (ang. fully achieved)– w pełni osiągnięty (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 0proces 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 5proces innowacyjny – opisany powyżej przewidywalny proces jest w sposób ciągły udoskonalany aby odpowiedzieć na zmiany zachodzące w organizacji.

Przypisy

  1. https://www.vda.de/en/association/members.html
  2. C. Kreiner 2017, s. 1-2
  3. VDA 2017, s. 12-15
  4. VDA 2017, s. 15-17

Bibliografia

  • Kreiner C. (red.) (2013), Automotive Knowledge Alliance AQUA – Integrating Automotive SPICE, Six Sigma, and Functional Safety
  • Macher G., Much A., Riel A., Messnarz R., Kreiner C. (2017), Automotive SPICE, Safety and Cybersecurity Integration
  • VDA QMC Working Group 13, Automotive SIG (2017), Automotive SPICE® Process Reference and Assessment Model (release 3.1)


Autor: Tomasz Sala