V-Model המכונה גם מודל האימות והאימות. בכך, כל שלב של SDLC חייב להשלים לפני תחילת השלב הבא. זה עוקב אחר תהליך עיצוב רציף זהה למודל המפל. בדיקת המכשיר מתוכננת במקביל לשלב הפיתוח המקביל.
אימות: זה כולל שיטת ניתוח סטטי (סקירה) הנעשית ללא ביצוע קוד. זהו תהליך ההערכה של תהליך פיתוח המוצר כדי למצוא אם הדרישות שצוינו עומדות.
מַתַן תוֹקֵף: זה כולל שיטת ניתוח דינמית (פונקציונלית, לא פונקציונלית), הבדיקה נעשית על ידי ביצוע קוד. אימות הוא התהליך לסיווג התוכנה לאחר השלמת תהליך הפיתוח כדי לקבוע האם התוכנה עונה על ציפיות ודרישות הלקוח.
אז V-Model מכיל שלבי אימות בצד אחד של שלבי האימות בצד השני. תהליך האימות והאימות מצטרף לשלב הקידוד בצורת V. לפיכך הוא ידוע בשם V-Model.
ישנם השלבים השונים של שלב האימות של דגם V:
| ניתוח דרישות עסקיות: | זהו השלב הראשון בו דרישות המוצר מובנות מהצד של הלקוח. שלב זה מכיל תקשורת מפורטת להבנת ציפיות הלקוח ודרישותיו המדויקות.
| עיצוב מערכת: | בשלב זה מהנדסי מערכת מנתחים ומפרשים את העסק של המערכת המוצעת על ידי לימוד מסמך דרישות המשתמש.
| עיצוב אדריכלות: | קו הבסיס בבחירת הארכיטקטורה הוא שהיא צריכה להבין את כל מה שבדרך כלל מורכב מרשימת המודולים, פונקציונליות קצרה של כל מודול, יחסי הממשק שלהם, תלות, טבלאות מסד נתונים, דיאגרמות ארכיטקטורה, פירוט טכנולוגי וכו'. מודל בדיקת האינטגרציה מתבצע לצאת בשלב מסוים.
| עיצוב מודול: | בשלב תכנון המודול, המערכת מתפרקת למודולים קטנים. העיצוב המפורט של המודולים מצוין, הידוע בשם Low-Level Design
| שלב הקידוד: | לאחר התכנון, מתחיל שלב הקידוד. על סמך הדרישות מחליטים על שפת תכנות מתאימה. יש כמה הנחיות ותקנים לקידוד. לפני הבדיקה במאגר, המבנה הסופי עובר אופטימיזציה לביצועים טובים יותר, והקוד עובר ביקורות קוד רבות כדי לבדוק את הביצועים.
ישנם השלבים השונים של שלב האימות של מודל V:
| בדיקת יחידות: | ב-V-Model, תוכניות בדיקת יחידות (UTPs) מפותחות במהלך שלב תכנון המודול. UTPs אלה מבוצעים כדי למנוע שגיאות ברמת הקוד או ברמת היחידה. יחידה היא הישות הקטנה ביותר שיכולה להתקיים באופן עצמאי, למשל, מודול תוכנית. בדיקת יחידות מוודאת שהישות הקטנה ביותר יכולה לתפקד כהלכה כשהיא מבודדת משאר הקודים/יחידות.
| בדיקת אינטגרציה: | תוכניות בדיקת אינטגרציה מפותחות במהלך שלב התכנון האדריכלי. בדיקות אלו מאמתות שקבוצות שנוצרו ונבדקו באופן עצמאי יכולות להתקיים יחד ולתקשר ביניהן.
| בדיקת מערכת: | תוכניות בדיקות מערכת מפותחות במהלך שלב עיצוב המערכת. שלא כמו תוכניות בדיקות יחידות ואינטגרציה, תוכניות בדיקות מערכת מורכבות על ידי הצוות העסקי של הלקוח. בדיקת מערכת מבטיחה שהציפיות ממפתח אפליקציות מתקיימות.
| בדיקת קבלה: | בדיקות קבלה קשורות לחלק ניתוח הדרישות העסקיות. זה כולל בדיקת מוצר התוכנה באווירת המשתמש. מבחני קבלה חושפים את בעיות התאימות למערכות השונות, הזמינות באווירת המשתמש. זה מגלה ביחד את הבעיות הלא פונקציונליות כמו עומס ופגמים בביצועים באווירת המשתמש האמיתית.
מתי להשתמש ב-V-Model?
- כאשר הדרישה מוגדרת היטב ואינה משתמעת לשתי פנים.
- יש להשתמש במודל בצורת V עבור פרויקטים קטנים עד בינוניים שבהם הדרישות מוגדרות וקבועות בבירור.
- יש לבחור את הדגם בצורת V כאשר משאבים טכניים לדוגמה זמינים עם מומחיות טכנית חיונית.
יתרון (יתרונות) של דגם V:
- קל להבנה.
- שיטות בדיקה כמו תכנון, עיצוב בדיקות מתרחשות הרבה לפני הקידוד.
- זה חוסך הרבה זמן. מכאן סיכוי גבוה יותר להצלחה על פני מודל המפל.
- מונע זרימה כלפי מטה של הפגמים.
- עובד היטב עבור תוכניות קטנות שבהן הדרישות מובנות בקלות.
חסרון (חסרונות) של V-Model:
- מאוד נוקשה והכי פחות גמיש.
- לא טוב לפרויקט מורכב.
- תוכנה מפותחת בשלב ההטמעה, כך שלא מייצרים אבות טיפוס מוקדמים של התוכנה.
- אם מתרחשים שינויים באמצע הדרך, יש לעדכן את מסמכי הבדיקה יחד עם המסמכים הנדרשים.
