Automotive SPICE: Różnice pomiędzy wersjami

Z Encyklopedia Zarządzania
m (→‎Bibliografia: Clean up)
m (cleanup bibliografii i rotten links)
 
(Nie pokazano 3 wersji utworzonych przez jednego użytkownika)
Linia 1: Linia 1:
{{infobox4
|list1=
<ul>
<li>[[Identyfikacja]]</li>
<li>[[Zarządzanie konfiguracją]]</li>
<li>[[Testy akceptacyjne odbiorcze]]</li>
<li>[[Identyfikacja procesów]]</li>
<li>[[Total Quality Control]]</li>
<li>[[Plan jakości]]</li>
<li>[[Jakość wg PRINCE2]]</li>
<li>[[Interpretacja ISO 9001%3A2000]]</li>
<li>[[Metodyka MSF]]</li>
</ul>
}}
'''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.


Linia 22: Linia 8:


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<ref>C. Kreiner 2017, s. 1-2</ref>
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<ref>C. Kreiner 2017, s. 1-2</ref>
<google>t</google>


==Referencyjny model procesów==
==Referencyjny model procesów==
Linia 29: Linia 14:
* procesy organizacyjne
* procesy organizacyjne
* procesy wspomagające
* procesy wspomagające
<google>n</google>


'''[[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:
'''[[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:
Linia 90: Linia 77:
* '''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 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.
* '''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.
{{infobox5|list1={{i5link|a=[[Identyfikacja]]}} &mdash; {{i5link|a=[[Zarządzanie konfiguracją]]}} &mdash; {{i5link|a=[[Testy akceptacyjne odbiorcze]]}} &mdash; {{i5link|a=[[Identyfikacja procesów]]}} &mdash; {{i5link|a=[[Total Quality Control]]}} &mdash; {{i5link|a=[[Plan jakości]]}} &mdash; {{i5link|a=[[Jakość wg PRINCE2]]}} &mdash; {{i5link|a=[[Interpretacja ISO 9001%3A2000]]}} &mdash; {{i5link|a=[[Metodyka MSF]]}} }}


==Przypisy==
==Przypisy==
Linia 98: Linia 87:
* Kreiner C. (red.) (2013), ''Automotive Knowledge Alliance AQUA - Integrating Automotive SPICE, Six Sigma, and Functional Safety''
* 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''
* 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), [https://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 (2017), ''[https://www.automotivespice.com/fileadmin/software-download/AutomotiveSPICE_PAM_31.pdf Automotive SPICE® Process Reference and Assessment Model (release 3.1)]'', VDA
</noautolinks>
</noautolinks>



Aktualna wersja na dzień 23:43, 27 lis 2023

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 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[1]

Referencyjny model procesów

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

  • 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[3]:

  • 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 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.


Automotive SPICEartykuły polecane
IdentyfikacjaZarządzanie konfiguracjąTesty akceptacyjne odbiorczeIdentyfikacja procesówTotal Quality ControlPlan jakościJakość wg PRINCE2Interpretacja ISO 9001:2000Metodyka MSF

Przypisy

  1. C. Kreiner 2017, s. 1-2
  2. VDA 2017, s. 12-15
  3. VDA 2017, s. 15-17

Bibliografia


Autor: Tomasz Sala