Automotive SPICE: Różnice pomiędzy wersjami
mNie podano opisu zmian |
Nie podano opisu zmian |
||
Linia 1: | Linia 1: | ||
'''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. | ||
==Zastosowanie ASPICE== | ==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<ref>https://www.vda.de/en/association/members.html</ref>. | 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<ref>https://www.vda.de/en/association/members.html</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> | 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> | <google>t</google> | ||
==Referencyjny model procesów== | ==Referencyjny model procesów== | ||
Linia 11: | Linia 11: | ||
* procesy wspomagające | * 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: | '''[[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. | * '''[[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.3 – [[umowa]] kontraktowa (ang. ''contract agreement'') | ||
** ACQ.4 – monitorowanie dostawcy (ang. ''supplier monitoring'') | ** ACQ.4 – [[monitorowanie]] dostawcy (ang. ''supplier [[monitoring]]'') | ||
** ACQ.11 – wymagania techniczne (ang. ''technical requirements'') | ** ACQ.11 – wymagania techniczne (ang. ''technical requirements'') | ||
** ACQ.12 – wymagania prawne i administracyjne (ang. ''legal and administrative requirements'') | ** ACQ.12 – wymagania prawne i administracyjne (ang. ''legal and administrative requirements'') | ||
** ACQ.13 – wymagania projektowe (ang. ''project requirements'') | ** ACQ.13 – wymagania projektowe (ang. ''project requirements'') | ||
** ACQ.14 – zapytanie ofertowe (ang. ''request for proposal'') | ** ACQ.14 – [[zapytanie ofertowe]] (ang. ''request for proposal'') | ||
** ACQ.15 – kwalifikacja dostawcy (ang. ''supplier qualification'') | ** 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. | * '''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.1 – [[przetarg]] dostawcy (ang. ''supplier tendering'') | ||
** SPL.2 – wydanie produktu (ang. ''product release'') | ** 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. | * '''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.1 – pozyskiwanie wymagań (ang. ''requirements elicitation'') | ||
** SYS.2 – analiza wymagań systemowych (ang. ''system requirements analysis'') | ** SYS.2 – analiza wymagań systemowych (ang. ''[[system]] requirements analysis'') | ||
** SYS.3 – projekt architektoniczny systemu (ang. ''system architectural design'') | ** SYS.3 – [[projekt]] architektoniczny systemu (ang. ''system architectural design'') | ||
** SYS.4 – integracja systemu i testy integracyjne (ang. ''system integration and integration test'') | ** SYS.4 – integracja systemu i testy integracyjne (ang. ''system integration and integration test'') | ||
** SYS.5 – testy kwalifikacyjne systemu (ang. ''system qualification test'') | ** SYS.5 – testy kwalifikacyjne systemu (ang. ''system qualification test'') | ||
Linia 32: | Linia 32: | ||
** SWE.1 – analiza wymagań oprogramowania (ang. ''software requirements analysis'') | ** SWE.1 – analiza wymagań oprogramowania (ang. ''software requirements analysis'') | ||
** SWE.2 – projekt architektoniczny oprogramowania (ang. ''software architectural design'') | ** 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.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.4 – weryfikacja jednostek oprogramowania (ang. ''software unit verification'') | ||
** SWE.5 – integracja oprogramowania i testy integracyjne (ang. ''software integration and integration testing'') | ** SWE.5 – integracja oprogramowania i testy integracyjne (ang. ''software integration and integration testing'') | ||
Linia 39: | Linia 39: | ||
'''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: | '''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 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. | ||
** MAN.3 – zarządzanie projektem (ang. ''project management'') | ** MAN.3 – [[zarządzanie projektem]] (ang. ''project management'') | ||
** MAN.5 – zarządzanie ryzykiem (ang. ''risk management'') | ** MAN.5 – [[zarządzanie ryzykiem]] (ang. ''risk management'') | ||
** MAN.6 – pomiary (and. ''measurement'') | ** 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ą. | * '''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'') | ** 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). | * '''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'') | ** 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. | '''Kategoria procesów wspomagających''' składa się z pojedynczej grupy procesów, które mogą zostać wykorzystane w trakcie wykonywania innych procesów. | ||
Linia 51: | Linia 51: | ||
** SUP.1 – zapewnianie jakości (ang. ''quality assurance'') | ** SUP.1 – zapewnianie jakości (ang. ''quality assurance'') | ||
** SUP.2 – weryfikacja (ang. ''verification'') | ** SUP.2 – weryfikacja (ang. ''verification'') | ||
** SUP.4 – wspólny przegląd (ang. ''joint review'') | ** SUP.4 – wspólny [[przegląd]] (ang. ''joint review'') | ||
** SUP.7 – dokumentacja (ang. ''documentation'') | ** SUP.7 – [[dokumentacja]] (ang. ''documentation'') | ||
** SUP.8 – zarządzanie konfiguracją (ang. ''configuration management'') | ** SUP.8 – [[zarządzanie konfiguracją]] (ang. ''configuration management'') | ||
** SUP.9 – zarządzanie rozwiązywaniem problemów (ang. ''problem resolution management'') | ** SUP.9 – zarządzanie rozwiązywaniem problemów (ang. ''problem resolution management'') | ||
** SUP.10 – zarządzanie żądaniem zmiany (and. ''change request management'') | ** SUP.10 – zarządzanie żądaniem zmiany (and. ''change request management'') | ||
Linia 59: | Linia 59: | ||
==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%) | ||
* '''P''' (ang. ''partially achieved'') – częściowo osiągnięty (15-50%) | * '''P''' (ang. ''partially achieved'') – częściowo osiągnięty (15-50%) | ||
* '''L''' (ang. ''largely achieved'') – osiągnięty w znacznej części (50-85%) | * '''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%) | * '''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: | 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''' | * '''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 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 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 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 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. | ||
==Przypisy== | ==Przypisy== |
Wersja z 08:03, 25 lut 2022
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[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.
- MAN.3 – zarządzanie projektem (ang. project management)
- MAN.5 – zarządzanie ryzykiem (ang. risk management)
- 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ą.
- 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 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.
Przypisy
- ↑ https://www.vda.de/en/association/members.html
- ↑ C. Kreiner 2017, s. 1-2
- ↑ VDA 2017, s. 12-15
- ↑ 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