כלי טייס צבאיים המיועדים לעלות לאוויר נדרשים לעמוד בתקני הבטיחות והאיכות בהם תקני בטיחות התוכנה DO-178BC. תקן זה מפרט את כל שלבי פיתוח התוכנה של המערכת עבור כלי הטייס ואת כל שלבי הבדיקות אשר נדרש מכלי הטייס לעבור כדי לקבל את האישור.
כדי שהמהנדסים וחברי צוות שאינם מהנדסים יוכלו להרגיש בטוחים יותר בזמן הטיסה, נכתב לפני כשלושה עשורים מסמך ה-DO-178, שהפך למעשה לתקן בטיחות בינלאומי לתהליכי פיתוח תוכנות המשמשות במטוסי נוסעים, בכלי טייס לא מאוישים ובמערכות מוטסות (מערכות תקשורת, תצוגה, מערכות בקרה וכדומה).
התקן דורש תיעוד מפורט של תהליך הפיתוח, לצד מסמכים תומכים רבים, כאשר מידת הפירוט וכמות המסמכים הנדרשת נקבעת על פי רמת הרישיון הנדרשת. הרמות השונות, D, C, B, A תואמות את ההשלכות האפשריות של כישלון של התוכנה: קטסטרופה (מוות ודאי של כל הנוסעים או חלקם), סכנה חמורה (פוטנציאל למוות של מספר אנשים), סכנה גדולה (פגיעות גופניות קשות), סכנה קטנה (פגיעות גופניות קלות) או העדר השפעה על המשך בטוח של הטיסה והנחיתה, בהתאמה.
תקן ה-DO-178 מכסה את כל מחזור החיים ההנדסי – משלב דרישות התכנון, דרך שלב הפיתוח ועד לשלב הבדיקות של התוכנה. תהליך ההסמכה לפי תקן DO-178 מאריך באופן משמעותי את זמני הפיתוח של תוכנות. כלל האצבע קובע כי בהשוואה למוצר ללא הסמכה, התוספת לזמן הפיתוח הנדרש הוא 75%-150% מהזמן הדרוש לפיתוח מוצר ללא הסמכה, בתלות ברמת ההסמכה אליה מכוונים.
על מנת לקבל את אישור העמידה בתקן יש לעבור 4 מבדקים. בפגישות אלו מהנדסי הפרויקט נפגשים עם הרשויות המוסמכות, הרשויות בודקות את התהליך ומאשרות או לא מאשרות אותו. אם והמבדק עבר בהצלחה ניתן להתקדם לקראת הביקורת הבאה.
להלן ארבעת הביקורות שיש לעבור במסגרת ה DO-178:
1# SOI– ביקורת ראשונה: software planning review
ביקורת תכנון תוכנה צריכה להתנהל כאשר תהליך תכנון התוכנה הראשונית הושלם (כלומר, כאשר רוב התכניות והתקנים הושלמו). בביקורת זו יציגו מתכנני הפרויקט את ארכיטקטורת התוכנה ואת התכניות שלהם עבור הפרויקט וגם את רשימת הבדיקות שעל פיהן הפרויקט ייבדק בהמשך.
2# SOI– ביקורת שניה: software development review
ביקורת פיתוח תוכנה הינה מבדק על כלל הדרישות (בכל הרמות) של התוכנה כולל בדיקות Code review על גרסת התוכנה. הכנה לפגישה זו מהווה את שלב ה Review בו מתבצע תיקוף על כל המסמכים המרכיבים את הפרויקט, לרבות הקוד. כדי לשמור על תהליך סטרילי ונטול השפעות בין מפתחים לבודקים, קווליטסט – המתמחה בתהליכים ושיפורים בתחומים אלה – מבצעת בדיקות וריפיקציה.
דוגמאות לקריטריונים נספים של בדיקה: עמידה בתקני כתיבה מקובלים, אי קיום Dead Code, אי קיום חריגות ממערכים ועוד.
עבור כל אחד משלבי הReview, מציעה חברת קווליטסט סיוע בתיקון החומרים והשבחתם עפ”י ההערות שעלו בזמן בדיקת האיכות חוזרת עד השבת תוצרים באיכות מקסימלית ומסמכי בדיקה נקיים מהערות. אפשרות זו היא הכדאית ביותר ללקוח היות והוא מגיש את החומרים פעם אחת ומקבל אותם חזרה במינימום זמן ובמקסימום איכות.
3# SOI– ביקורת שלישית: software verification review
ביקורת אימות תוכנה הינה הצגת חלק מאימות התוכנה ונתוני הבדיקות שבוצעו. כדי להבטיח שהמוצר יעמוד בתקן הנדרש קווליטסט משלבת בדיקות, הדגמות, סקירות וניתוח הכיסוי מול ניהול תצורת תוכנה. בסוף התהליך יינתן אישור מהרשויות כי מוצר התוכנה שצוין הוא מוצר התוכנה שנבנה. בעקבות הדרישות המחמירות בהם המוצר נדרש לעמוד מול הרשויות, קווליטסט מוכיחה שוב ושוב את יכולתה לעמוד במטרות הבאות:
שלב זה של סקירת אימות תוכנה כולל שני שלבי בדיקות:
Black Box – בדיקות פונקציונליות לצורך אימות דרישות התוכנה באמצעות סימולטורים ומגוון כלים נוספים להזרקת נתונים מהמחשב אל היחידה הנבדקת ולהפך (לצורך וידוא תוצאות הבדיקה). אנשי החברה צברו ניסיון רב שנים והכרות מעמיקה עם מגוון טכנולוגיות וכלים לביצוע בדיקות אלו באופן מיטבי בשילוב עם כלי בדיקות אוטומטיות מגוונים.
White Box – בדיקות פונקציונליות של נכונות רכיבי התוכנה המבוססות על קוד המקור. לצורך ביצוע בדיקות אלו נדרשות יכולות טכניות גבוהות, הכרת קוד מצוינת , פיתוח סקריפטים וכלי עזר. קווליטסט מתאימה בודקים מומחים לכך.
לצורך הבדיקות קווליטסט משתמשת במגוון אפליקציות וכלים ידידותיים למשתמש (יישומי ברמה 5-7 בהיררכיית תוכנה) מה שמאפשר לבודק להתמקד בכתיבת הטסט ולצמצם את הצורך בתחזוקת התוכנה המשמשת לבדיקות. קווליטסט שואפת כל העת לייעל את תהליכי הבדיקות באמצעות מעבר לכלים אוטומטיים, פיתוח כלים ייעודיים ומעטפות התאמה לעבודה מול כלים קיימים, סקריפטים ותוכנות עזר שהוכחו כממלאים את תפקידם נאמנה תוך שהם חוסכים זמן יקר ומשאבים מיותרים. כמו כן הם מספקים תוצאות מדויקות ואמינות פי כמה וכמה.
חברות רבות נהנות ממגוון השירותים של קווליטסט, המחויבת למקצועיות, גמישות ואמינות. מרכיבים אלה הם חלק בלתי נפרד ממכלול בדיקות התוכנה והחומרה, הכוללים בניית תשתית לסביבות טסטים ולסביבות למדידת הכיסוי. כתוצאה מעדכונים שעשויים להתרחש בפרויקט בשלב זה בעקבות גילוי באגים או בשל החלטות מערכת לשינוי העיצוב, נדרשת לעיתים חזרה לתהליך soi#2 הכולל וריפיקציה לדרישות או לקוד עפ”י השינוי שבוצע.
כחלק מתיעוד התהליך מופקים מסמכים רשמיים המתעדים את הטסטים ואת תוצאות הרצתם (STD ו-STR) ומתועדים כלל הכלים והחומרים ששימשו לבדיקות התוכנה וכלל תוצאות ההרצה. קווליטסט מספקת שירותי וריפיקציה גם למסמכים אלו הכוללים בדיקות איכות מקיפות של הטסטים עצמם, קישוריות וכיסוי דרישות, מצבי כשל, בדיקת דוחות כיסוי ועוד.
תהליך סווג הבדיקות עבור High Level Requirements ו- Low Level Requirements מתבצע לרב באופן הבא:
ה-HLRs נבדקים ע”י BB tests וכן דרישות ה-LL מקושרות ונבדקות ע”י אותם טסטים (במידה וניתן).
LLRs שלא ניתן לבדוק באמצעות BB tests יבדקו ע”י WB tests.
התרשים הבא מסכם זאת:
4# SOI– ביקורת רביעית: final certification software review
ביקורת זו תתקיים לאחר השלמת התוכנה הסופית. מטרת ביקורת זו היא להבטיח כי הפרויקט הותאם לכל דרישות ה DO-178 וכל הפעילויות (אימות, ניהול תצורה, אבטחת איכות, קישוריות) הושלמו. בשלב זה יש להוכיח כי 100% מהקוד מכוסה ע”י בדיקות ובמידת הצורך יש להוסיף טסטים. ביקורת תוכנת ההסמכה הסופית צריכה להתבצע כאשר פרויקט התוכנה הושלם ועומד בקריטריונים הבאים :