Manapság a különböző gyártó cégek, nevezzük őket OEM-nek (Original Equipment Manufacturer), beszállítók egész hálózatával állnak kapcsolatban. Ezt az amúgy sem egyszerű helyzetet színesítsük tovább extrém rövid fejlesztési határidőkkel, nagy mennyiségű követelményrendszerrel, komplex összetettségű HW (Hardware) és SW (Software) komponensekkel. A kialakult helyzet mind a két oldal számára komoly kihívásokat tartogat. Azért, hogy hatékonyan tudjuk kezelni ezt a szituációt, szükségessé válik egy érett és működő céges szintű folyamatrendszer kifejlesztése, annak minőségi fenntartása, ellenőrzése.

Ezen cél elérése érdekében fejlesztették ki az ISO/IEC 15504 szabványt, közismertebb nevén SPICE^®(Software Process Improvement and Capability dEtermination). Mivel én az autóiparban dolgozok, hozzám közelebb áll ennek egy derivált változata, ami nagyon kreatívan Automotive SPICE^® (még rövidebben ASPICE^®) néven fut. Tulajdonképpen ez nem más, mint egy remekül megfogalmazott útmutató tele kis praktikákkal, amiket nemes egyszerűséggel csak „Base Practice”-eknek neveztek el. Ezek egyrészt használhatók a SW fejlesztési folyamatok fejlesztésére, másrészt pompásan lehet vele értékelni a beszállítókat (a rettegett Assessment). Sajnos én a „fegyver” rossz oldalán állok, mivel mi beszállítói vagyunk a tisztelt autógyártó cégeknek, így az ASPICE^® „assessment”-eken a vizsgázók vagyunk, nem pedig a vizsgáztatók. Emiatt nagyon fontos a hasonló cipőben járó projektvezetőknek, hogy tisztában legyenek a feléjük támasztott követelményekkel, és azok kielégítésével.

Pár gondolatot még írnék az ASPICE^®-ról, ha valaki nem ismerné. A V-modell alapú fejlesztésre épül, ahol a „V” bal oldala felülről lefelé a vevői követelmények (Customer Requirements) analízise  rendszer követelmények (System Requirements) meghatározása  rendszer terv (Sytem Design) készítése  SW követelmények (Software Requirements) meghatározása  SW terv (Software Design) készítése  SW komponens követelmények  (Software Component Requirements) meghatározása  SW komponens terv (Software Component Design) elkészítése  forráskód megírása (Source Code Implementation). A „V” jobb oldalán pedig a bal oldalhoz kapcsolódó tesztek specifikálása és végrehajtása található. Ezenkívül vannak előírások a kiszolgáló és menedzsment folyamatokra is. Mindezeket területekre osztja az útmutató, ezeket kell lefednie egy jól működő beszállító cégnek. Az 1. ábra mutatja a legújabb 3.1-es verzió területeit (Process Reference Model).

1. ábra | ASPICE^® területek (Process Reference Model)
(forrás: http://www.automotivespice.com/fileadmin/software-download/AutomotiveSPICE_PAM_31.pdf,
12. oldal)

Általában a cégek Minőségbiztosítási Osztályának (Quality Department) egyik meghatározó feladata, hogy a területek nagy részét kidolgozza, fenntartsa és fejlessze. Számunkra, mint projekt vezetők a legizgalmasabb rész a jobb felső sarokban pirossal bekeretezett két terület: maga a projekt menedzsment (MAN.3 Project Management) és a kockázat kezelés (MAN.5 Risk Management).

Minden területhez tartozik pár tíz darab úgynevezett „Base Practice” (BP), amik pár mondatban kifejtik, hogy mit is kellene letenni az asztalra. Azt azért zárójelben megjegyezném, hogy néha elég nehéz kitalálni, hogy pontosan mire is gondol a költő… Dióhéjban egy „assessment” menete a következő: Amikor jön az „assessor”, hogy jól megnézze, megfelelően dolgozik-e a cég, beleértve minket menedzsereket is, akkor az egyes folyamatok felelőseinek feltesz különböző keresztkérdéseket, bekér bizonyítékokat, és általában egy különleges hatodik érzékkel mindig rátalál a gyengébb területekre, amiket azután ízekre szed. A vallatás során minden terület minden „BP”-je kap egy osztályzatot (Process Attribute Rating), ennek értékeit a 2. ábramutatja. A teljes vizsgálat izzadós egy hét szokott lenni.

2. ábra | ASPICE^® osztályzat (Process Attribute Rating)
(forrás: http://www.automotivespice.com/fileadmin/software-download/AutomotiveSPICE_PAM_31.pdf,
17. oldal)

Legvégül pedig az adott folyamat területekhez rendelnek egy-egy képességi szintet (Process Capability Level) az osztályzatok alapján (3. ábra). A teljes osztályozás és szint meghatározás ennél jóval összetettebb, az érdeklődő olvasók a részleteket az ASPICE^® PAM (Process Assessment Model) dokumentumban lelhetik meg, legfrissebb verzió:

http://www.automotivespice.com/fileadmin/software-download/AutomotiveSPICE_PAM_31.pdf.

3. ábra | ASPICE^® folyamat képességi szint (Process Capability Level)
(forrás: http://www.automotivespice.com/fileadmin/software-download/AutomotiveSPICE_PAM_31.pdf,
15-16. oldal)

Az egység sugarú cégek számára a „Level 3” elérése a cél, de már a stabil „Level 2”-nek is nagyon tudunk örülni. A „Level 4” és „Level 5” szinteket meghagyjuk az unatkozó indiai cégeknek.

Most, hogy tudjuk, hova kellene eljutni, nézzük meg, hogy mit kell(ene) ehhez tennünk az okosak szerint (hogy autentikus legyek, „kopipészt” a fentebb linkelt pdf dokumentumból):

• 3 Project Management
  • 3.BP1: Define the scope of work.
  • 3.BP2: Define project life cycle.
  • 3.BP3: Evaluate feasibility of the project.
  • 3.BP4: Define, monitor and adjust project activities.
  • 3.BP5: Define, monitor and adjust project estimates and resources.
  • 3.BP6: Ensure required skills, knowledge, and experience.
  • 3.BP7: Identify, monitor and adjust project interfaces and agreed commitments.
  • 3.BP8: Define, monitor and adjust project schedule.
  • 3.BP9: Ensure consistency.
  • 3.BP10: Review and report progress of the project.
• 5 Risk Management
  • 5.BP1: Establish risk management scope.
  • 5.BP2: Define risk management strategies.
  • 5.BP3: Identify risks.
  • 5.BP4: Analyze risks.
  • 5.BP5: Define risk treatment actions.
  • 5.BP6: Monitor risks.
  • 5.BP7: Take corrective action.

Ismerjük a célt, ismerjük, hogy mit kell tennünk, de nem tudjuk, hogy hogyan csináljuk. És ez az, amit az ASPICE^® nem köt az orrunkra. Eljutottunk a hídhoz, most már csak át kell kelnünk rajta.

Ekkor csillan fel a jól képzett projekt menedzser szeme, és gyullad ki a villanykörte a feje felett: „Heuréka, én ismerem a hogyan-t!”. Ahogy a matematikusok szokták mondani az egyenletek felírása után, „vegyük észre, hogy” a listában szereplő szavak és szókapcsolatok kísértetiesen hasonlítanak a PMI^® mátrixban lévő folyamat megnevezésekre, egyes helyeken meg is egyeznek. És ezzel el is érkeztünk az egész blog lényegi mondanivalójához. A PMI^® által definiált, a PMBOK^® 6. kiadásában is szereplő folyamatokat összegző mátrix pontosan megfeleltethető az ASPICE^® követelményeinek, és segíti a projektvezetőket, hogy sikeresen vegyék az akadályokat. Készítettem egy összerendelést, hogy miként lehet a kettőt egymásnak megfeleltetni (4. ábra).

4. ábra | PMI^® vs. ASPICE^® összerendelés

Az üres folyamat lépések pedig választ adnak más területek „hogyan” kérdéseire is (5. ábra), egyszóval egy nagyon hatékony keretrendszer áll rendelkezésünkre, csak alkalmaznunk kell.

5. ábra | Egyéb lefedett ASPICE^® területek

Természetesen az ASPICE^® nem követeli meg, hogy a PMI^® módszertanát használjuk. De miért küszködnénk, ha van egy bizonyítottan bevált és jól használható „receptkönyvünk”?

 

Megjegyzés és felelősség kizárása: Ezen Blogbejegyzés szerzője Simon Gábor, PMP®, a pmi.hu vendégszerzője. Az írás a szerző saját szakmai véleményét, megállapításait, következtetéseit tükrözi, amely nem feltétlenül egyezik meg a PMI Budapest, Magyar Tagozat álláspontjával, illetve nem tekinthető hivatalos ajánlásnak, állásfoglalásnak, véleménynek a PMI Budapest részéről. Az írás szerzői és megjelenési jogai az eredeti szerzőt illetik.