ASPICE 101: כל מה שצריך לדעת על Automotive SPICE

מהו ASPICE?

ASPICE, שפותח כמודל ייחוס לתהליכים במסגרת תקן ISO/IEC 15504, ידוע גם כ-SPICE – שיפור תהליכי תוכנה וקביעת יכולות. הוא נוצר כדי להעריך את הביצועים ולסייע בהערכת תהליכי פיתוח תוכנה של ספקי OEM בתעשיית הרכב. הוא מגדיר שיטות עבודה מומלצות ותהליכים להבטחת האיכות הגבוהה ביותר של פיתוח תוכנה משובצת לרכב. תהליך ההסמכה מבוסס על ביקורת הנערכת על ידי מעריכים חיצוניים ועצמאיים המוסמכים ל-ASPICE.

ASPICE פותח במסגרת תקן ISO/IEC 15504 – שיפור תהליכי תוכנה וקביעת יכולות, הידוע גם כ-SPICE. בעוד SPICE מספק את המסגרת להערכת תהליכי תוכנה, ASPICE מיישם מסגרת זו בתעשיית הרכב.

גלה עוד על האבולוציה של SPICE ל-ASPICE במאמר זה:מ-SPICE ל-ASPICE – התפתחות התקנים ויישומם. 

רמות היכולת של ASPICE

ספקים העוברים הסמכת ASPICE יכולים להיות מדורגים באחת מחמש רמות יכולת:

רמות 2 ו-3 נתפסות בדרך כלל על ידי לקוחות כתקנים האוניברסליים למצוינות, בעוד שרמות 4 ו-5 נתפסות כשאיפות.

מדריך ASPICE: מודל אימות ותיקוף

מודל האימות והתיקוף, הידוע גם כמודל ה-V, הוא הבסיס עליו בנוי Automotive SPICE. מודל ה-V מקפיד על דרישה להערכה ולפיתוח מתמידים, כך שניתן יהיה לזהות בעיות פוטנציאליות כבר בשלב הראשון. מודל ה-V מורכב משני שלבים. כל אחד מהם כולל פאזות שונות, כפי שמתואר בגרפיקה שלהלן:

במודל V, קיים שלב בדיקה לצד כל שלב בפיתוח. לאחר הפיתוח, התוכנה נבדקת בסדר עוקב מול הדרישות שהוגדרו בראשית הפרויקט.
למידע נוסף, קראו:מהו ASPICE?

האם ניתן לשלב בין ASPICE לגמישות?

הגישה הליניארית המשתמעת ממודל ה-V מרמזת שיש לשייך ASPICE למודל פיתוח תוכנה מסוג waterfall. עם זאת, זו אינה הדרך היחידה לשמור על מחזור פיתוח סדרתי.

ASPICE אינו מפרט כיצד יש לנהל את תהליך הפיתוח. הוא קובע מה יש לעשות ואילו תוצאות יש להשיג. לכן, ניתן ליישם חוזקות מסוימות של מתודולוגיית Agile, כך שניתן להשיג את תוצאות היעד במחזורים קצרים יותר עם גמישות להחיל שינויים במהלך התהליך, דבר שהיה קשה מאוד בגישה מסורתית של Waterfall. במילים אחרות, על ידי שילוב ASPICE עם Agile, ניתן לייצר מוצרים עובדים מהר יותר וללא דאגות לגבי איכות התוכנה.

חשוב להדגיש שהגישה האג'ילית לתהליכי פיתוח תוכנה אינה מפריעה לעמידה ב-ASPICE. עם זאת, מתודולוגיה אג'ילית יכולה וצריכה להיות מותאמת לצרכים ולדרישות של תעשיית הרכב. כנראה הגישה הידועה ביותר לשילוב אג'ילי ו-ASPICE היא Agile SPICE ™. היא הוכנה על ידי קבוצת העבודה Intacs כתוספת ל-Automotive SPICE. מטרתה לסייע ביישום שיטות עבודה מומלצות אג'יליות ולהשיג בו-זמנית את ציפיות ASPICE.
Agile SPICE ™ אינו מעדיף פרקטיקה אג'ילית ספציפית אחת, כמו סקראם או קנבן. מטרתו היא לגשר בין תהליכי ותוצאות PAM קיימים ולשמר מאפייני תהליך קיימים או פרקטיקות גנריות ב-CL1-3.

קראו על Agile SPICE ™ בפירוט רב יותר במאמר זה:כיצד שילוב של agile ו-ASPICE הוא מתכון להפחתת עלויות פיתוח תוכנה.  

אילו יתרונות מביא ASPICE?

ASPICE מעניק לארגונים יתרון תחרותי משמעותי בתעשיית הרכב. הוא מסייע בשמירה על פיתוח תוכנה לרכב שיטתי ומתועד היטב ומספק תוצאות חוזרות וצפויות עם סיכון מינימלי לשגיאות. כתוצאה מכך, חברות יכולות לייצר מוצרים באיכות גבוהה יותר וחדשניים יותר.

יתרה מכך, ASPICE פותח את הדלת לחוזים חדשים עם יצרני OEM הגדולים בעולם, מכיוון שהוא מסגרת נפוצה ומוכרת בתעשיית הרכב. יצרני OEM המובילים, כמו BMW ו-Audi, בוחרים את הספקים שלהם על בסיס דירוג הערכת ASPICE שלהם.

ASPICE לעומת ISO 26262

ISO 26262 הוא התקן הבינלאומי לבטיחות תפקודית של מערכות חשמל ואלקטרוניקה ברכבי כביש. מטרתו של ISO 26262 היא לכסות את כל ההיבטים של בטיחות תפקודית בתהליך הפיתוח. בטיחות היא המוקד העיקרי של ISO 26262.

קראו את המדריך שלנו ל-ISO 26262כדי לגלות עוד על תקן זה.

ASPICE שונה מ-ISO 26262 במטרתו, ביישומו ובמיקודו. חשוב מכל, ASPICE מגדיר שיטות עבודה מומלצות ותהליכים לפיתוח תוכנה לרכב שאינם קשורים בהכרח לבטיחות. הוא משמש להערכת האם ארגון עומד ברמת איכות מסוימת ובתקני בטיחות וביצועים מסוימים.

ASPICE מתמקד בשיפור תהליכים מתמשך כדי להעלות את רמת היכולת של הספק. ב-ISO 26262, המיקוד הוא בסגירת כל פערי העמידה בדרישות שזוהו בביקורת. כמו כן, ASPICE מתחשב בעלות ובלוח הזמנים של לוח הזמנים של הפיתוח. לעומת זאת, ISO 26262 מתמקד בעיקר בבטיחות תפקודית.

גלה עוד עלההבדלים בין ASPICE ל-ISO 26262. 

לסיכום, הגישה הטובה והמומלצת ביותר היא עמידה בתקני ASPICE ו-ISO 26262 כאחד, לצורך עמידה מלאה ב-ASPICE. זוהי הדרך האופטימלית לשמור על הסיכונים לכשלים פוטנציאליים במינימום, במיוחד עבור מערכות רכב קריטיות.

ASPICE לעומת CMMI 2.0 – תהליכי פיתוח תוכנה

CMMI 2.0 (Capability Maturity Model Integration) הוא מודל לשיפור ביצועים עסקיים ואספקת מוצרים או שירותים טובים יותר. הוא משמש גם כמודל להערכת תהליכים של רמת בגירות. הוא מגדיר תחומי practice שונים המשויכים לכל רמה מ-0 עד 5: ככל שהרמה גבוהה יותר, כך ההבנה של התהליכים בתוך הארגון עמוקה יותר. ארגונים המגיעים לרמה 4 או 5 נחשבים לבגירים גבוהים.

גם ASPICE וגם CMMI כוללים את קבוצת תהליכי הנדסת התוכנה, ומכסים את ארבע הקטגוריות של תחומי תהליך בפיתוח תוכנה לרכב (ניהול תהליכים, ניהול פרויקטים, הנדסה ותמיכה), אך בעומק שונה. כמו כן, ל-CMMI יש היקף יישום רחב יותר מאשר ל-ASPICE. CMMI מכסה תחומי תהליך מסוימים ש-ASPICE אינו מכסה.

ASPICE מתמקד בשיטות הנדסה בהתאם למודל V ברמת הפרויקט – לא רק הנדסת תוכנה, אלא גם הנדסת מערכות (תוכנה + חומרה, אלקטרוניקה, מכנית וכו'). CMMI מכוון לניהול פרויקטים ולשיטות ארגוניות אחרות ברמת החברה.

כדי לגלות עוד על ההבדלים בין ASPICE ל-CMMI והאם כדאי ליישם את שניהם, קראו:ASPICE מול CMMI 2.0: תקני הרכב מפוענחים.  

ASPICE: אבטחת סייבר בתעשיית הרכב

בפברואר 2021, איגוד תעשיית הרכב הגרמני (VDA) פרסם הנחיות Automotive SPICE for Cybersecurity. מסמך זה סיים תקופה ארוכה שבה סקטור הרכב פיגר אחרי כמעט כל תעשייה אחרת ולא התייחס כראוי לאיומי סייבר. הוא מוסיף שכבה חשובה לתקן ASPICE הקיים ולמודל ה-V עצמו. קבוצה חדשה זו נקראת Cybersecurity Engineering Process Group (SEC), וכוללת ארבעה מרכיבים:

• SEC.1: איסוף דרישות אבטחת סייבר,
• SEC.2: יישום אבטחת סייבר,
• SEC.3: אימות טיפול בסיכונים,
• סעיף 4: אימות טיפול בסיכונים.

קראו עוד על כיצד למזג הנחיות אבטחת סייבר עם Automotive SPICE ומודל ה-V במאמר זה בבלוג שלנו >>>סייברס�キュリティ כתוסף ל-ASPICE ולמודל V

נסייע לכם להתכונן לתהליך הסמכת ASPICE

אם אתם מתכננים לעבור את תהליך הסמכת ASPICE, המומחים שלנו יכולים לספק לצוות שלכם הדרכת ASPICE לכל תפקיד ובכל רמה. אנו יכולים גם לבצע ביקורת וניתוח פערים כדי לזהות תחומים לשיפור ולסייע לכם ליישם את השינויים הנדרשים. 

ראה אתהצעת ASPICE ו-FuSaאו צרו איתנו קשר באמצעות הטופס שלהלן.