Verification and Validation – האם אנחנו במסלול הנכון?
"סליחה, זה מה שהתכוונת, נכון?" "זה נראה לך בסדר?" "הלוואי שהיה אפשר פשוט ללחוץ על כפתור ולדעת אם המערכת עובדת כמו שהתכוונו" …
יצא לכם פעם להיות עם קבוצת אנשים שכל אחד מדבר שפה אחרת? או שאולי כל אחד מדבר שתי שפות וכל מסר עובר כמה ידיים לפני שהוא מגיע ליעד? נשמע כמו משחק של טלפון שבור, נכון? איזה כיף אם במצב הזה היה מישהו שדובר את כל השפות, ויודע לתרגם אותם בצורה מדויקת. זאת בדיוק הנקודה שאנחנו מדברים עליה ב-Model-Based Design.
בפוסט הבא נתמקד בחלק של הבדיקות האוטומטיות שמלוות את התהליך, מוודאות ומתקפות או התהליך משלב הדרישות ועד שלב ייצור הקוד.
בעבודתי הראשונה לאחר סיום הלימודים, עבדתי ב-V&V (Verification and Validation, אימות ותיקוף) ב-SpaceIL (ניתן לקרוא עוד בקישור), ואני זוכר היטב את קצב הפיתוח המהיר – בכל זאת, היה צריך לעמוד בלוחות זמנים מאוד נוקשים. מצד שני, צריך להוציא מערכת שעובדת בצורה טובה. כלומר, צריך להיות מסוגלים לבדוק את המערכת כל הזמן ולראות שהעדכונים לא פוגעים במקומות אחרים, ושהיא עדיין מתכנסת לדרישות.
בבואכם לאפיין תהליך בדיקות, אתם צריכים לשאול את עצמכם שאלות כגון: מה רמת הבדיקתיות שאנחנו צריכים? אנחנו צריכים לעמוד בתקן מסוים? כמה מתוך התהליך צריך להיות אוטומטי?
בכדי לענות על השאלות הנ"ל, כדאי להסתכל על השלבים השונים, ולהבין איזה תהליכים נכון להפוך לאוטומטיים. בסופו של דבר, אני רוצה ללחוץ על כפתור, שהמערכת תיבדק, וייצא לי דוח (כמובן שאוכל להגדיר את הדוח עם Simulink Report Generator, אבל בזה לא ניגע בפוסט זה).
אבל מה זה למעשה אומר ש"המערכת תיבדק"?
החלק הזה כבר משתנה מארגון לארגון, אבל כנראה שנרצה לראות שאנחנו עונים על הדרישות המערכתיות (שאולי הגיעו ב-Word, אולי ב-Excel, אולי בפלטפורמת ניהול דרישות אחרת כמו Doors), נרצה לבדוק את הפונקציונליות של המודל, את הלוגיקה שלו, האם הוא מכוסה בצורה טובה והאם הקוד שיוצר באופן אוטומטי תואם את המערכת שפיתחנו.
חברת MathWorks מציעה מגוון רחב של כלים לבדיקות V&V, ובהמשך הפוסט המטרה שלי היא לעשות לכם סדר לגבי איזה כלי נותן מענה לאיזה שלב ואיזו בעיה.
שלב ראשון – קישור הדרישות למודל
נרצה לקשר את הדרישות ישירות למודל. נוכל להפריד בין דרישות פונקציונליות לדרישות אינפורמטיביות, אבל נרצה שהכל יהיה זמין ונגיש מתוך המודל שלנו.
Simulink Requirements מאפשר לנו לעשות בדיוק את זה. בנוסף, נוכל לראות עבור כל דרישה כמה ממנה מקושר למודל, לאן היא מקושרת, וכמה ממנה נבדק, כאשר הדרישות יכולות להיות מנוהלות ומסודרות במודל בצורה נוחה (ניתן ללמוד עוד בסרטון).
אבל רגע, מה זאת אומרת כמה מכל דרישה נבדק? מי בודק? לפי מה?
שאלה מעולה ואני שמח ששאלתם אותה! התשובה היא פשוטה מאוד – אתם. כאשר מגדירים את הדרישה, צריך להגדיר קריטריון הצלחה וקריטריון כשל, ואז לקשר לממשק אוטומטי שיריץ עבורכם את הבדיקות ויגיד אם עברתם או לא, ואולי גם יכמת כמה עברתם עבור דרישות מסוימות.
שלב שני – הגדרת הבדיקות וקישורן לדרישות
בחלק הזה נכנס Simulink Test, שבעזרתו נוכל להגדיר את הבדיקות ולקשר אותן גם לדרישות.
הרעיון הוא שנגדיר את הבדיקות פעם אחת (כמובן שניתן לערוך/להוסיף בדיקות), ובכל פעם שנעדכן גרסה, נוכל להריץ את כל הבדיקות דרך ה-Test Manager. נוכל גם להשתמש בכלי על מנת לייעל את זמני הריצה באמצעות עבודה מקבילית, בעבודה באופני העבודה Accelerator ו-Rapid Accelerator, או לרוץ על ה-GPU במקרים מסוימים.
כמובן שנוכל להכניס בדיקות פונקציונליות, בדיקות של תנאים מסוימים, לוגיקות מסוימות, ואפילו לבדוק את הקוד שלנו ב-SIL, PIL ו/או HIL, במידה ויש לנו ממשקים מוכנים ואת הכלים הרלוונטיים (ניתן לקרוא עוד בקישור).
בסוף נקבל דוח נוח ואינטראקטיבי שאומר לנו כמה מהבדיקות עברו, באיזה אחוזים הם עברו, ונוכל גם לראות כמה מהמודל שלנו מכוסה. שמוביל אותנו לחלק הבא – בדיקות ה-Coverage.
שלב שלישי – כיסוי (Coverage) של מצבי המודל ע"י הבדיקות
Simulink Coverage מוסיף לנו עוד רמה של אימות למודל, כאשר נוכל לראות גם בדוח וגם ויזואלית את הכיסוי. בסופו של יום, נרצה מודל יעיל, נרצה לראות שלא הכנסנו סתם דברים שלא באמת צריך או שהם לא נגישים. כמובן ש-Simulink Coverage משתלב מאוד יפה עם Stateflow, פלטפורמה לבניית מכונות מצבים ומערכות לוגיות בצורה ויזואלית ונוחה
באמצעות Coverage נוכל למצוא חוסרים במודל שלנו או פונקציונליות לא מתאימה, ונוכל לבדוק את הקוד שייוצר, כאשר כל זה נעשה בצורה ידידותית וויזואלית.
שלב רביעי – עמידה בתקנים ובדרישות Safety
שני הכלים האחרונים שיעזרו לנו להשלים את הבדיקות הם Simulink Check ו-Simulink Design Verifier. נשתמש בהם בשביל לקבל רמה גבוהה יותר של בדיקות, למשל בשביל לעמוד בתקנים מסוימים או בשביל להגיע למוצר ברמת סמך גבוהה יותר.
Simulink Check מספק לנו בדיקות סטנדרטיות למודל, שמאפשרות לנו למצוא מודלים שניתן לעשות בהם שימוש חוזר, להשתמש ב-model slicer בשביל לייצר חתכים מהמודל שלנו ולבדוק אותם. נוכל להשתמש בו בשביל לפשט את המודל, לייעל אותו ולהתמקד בבעיות בפיתוח.
Simulink Design Verifier מביא את המודל לרמת הבדיקתיות הגבוהה ביותר.
הכלי מאפשר לנו למצוא שגיאות נסתרות במודל, וחלקם אפילו מבלי להריץ את המודל(!). למשל, נוכל לזהות מקומות שבהם יש לנו integer-overflow, dead logic, חלוקה באפס וחריגות בגישה למערכים מסוימים.
בנוסף, הכלי יוכל לייצר עבורנו בדיקות חסרות לכיסוי מלא, או לייצר בדיקות שיענו על דרישות שאנחנו נגדיר בעצמנו, כאשר המטרה הסופית היא לקבל מודל מפושט ובדוק ככל האפשר. הכלי הזה נותן את המענה המקיף ביותר לבדיקות המודל והמערכת משלב הדרישות ועד שלב ייצור הקוד.
לסיכום,
בשביל לענות על השאלות שאיתם פתחתי (מה רמת הבדיקתיות שאנחנו צריכים? אנחנו צריכים לעמוד בתקן מסוים? כמה מתוך התהליך צריך להיות אוטומטי?) – זה תלוי פרויקט ותלוי מטרה, כאשר המחשבה העיקרית היא:
- כמה אני רוצה שהמודל שלי ייבדק?
- כמה מהבדיקות אני רוצה שייכתבו ידנית?
- כמה אני מרוויח בשעות מהנדס כשאני עושה אוטומציה לתהליך הבדיקות?
אתם כמובן מוזמנים לדבר איתנו ונשמח לעזור לכם לאפיין תהליך בדיקות מתאים לפרויקט שלכם, כאשר המטרה הראשית כל הזמן לנגד עינינו: מוצר מוכן ובדוק ככל הניתן, במינימום זמן ומינימום עלות.
אתם כמובן מוזמנים לפנות לתמיכה שלנו בקישור.
