The V Model
פרקי ההרצאה: The V Model
תמלול ההרצאה: The V Model
הטקסט המלא של הדקות הראשונות בהרצאה «The V Model» בקורס הווידאו של PracticU – כתוביות בעברית עם זמן התחלה לכל פסקה. כך תוכלו לקרוא ולחפש את הנושאים לפני שמתחילים ללמוד.
The V-Model, מודל ה-V, Lesson Objectives, מטרות השיעור, Introduction, נדבר קצת מבוא ככה על מודל ה-V, What is the V-Model, מהו מודל ה-V, The V-Model, נראה את היורוגרפי שלו ונדבר על כל שלב ושלב בו,
Advantages and Disadvantages of the Model, נדבר על היתרונות והחסרונות של המודל, Introduction, מבוא, Developed to regulate the development process within the German Federal Administration, אז ה-V-Model שהוא כפי שהזכרנו בעבר הוא שיפור של מודל המפ"ל הוא פותח על מנת להוות איזושהי רגולציה
לתהליך פיתוח התוכנה בפדרציה הגרמנית. A graphical representation of the software development process הוא למעשה יש לו צורה גרפית לתיאור תהליך פיתוח תוכנה. ובדומה למודל המפ"ל שראינו שהוא הולך בצורת מדרגות, הזווי מוסיף עוד מדרגות עולות מהצד השני כך שנוצר לנו מעין סמל של v, dv מודל, זהו מודל ה-v, אם אתם רואים אתם יכולים לדמיין שכאילו יש
פה מעין v. מודל ה-v הולך מאתמול לימין, כשהוא מלמעלה למטה, כשהוא מתחיל משלב ה-requirements, עובר לשלב ה-specifications, עובר לשלב ה-design, עובר לשלב ה-implementation, עד כאן מאוד מאוד דומה למודל המפל, עובר ל-unitest, תשימו לב,
Implementation ב-Unitest זה באותה רמה. משם עולה ל-Integration Tests, משם ל-System Tests ומשם ל-ATP Tests. דרך אחרת לראות את זה זה שה-Unitest בודק את האימפלימנטציית הקוד.
Integration Tests בודק את שלב הדיזיין. System Tests בודק את שלב הספציפיקציות. ATP Tests בודק את שלב ה-Requirements. Left Tail Represents the Specification Stream.
אז Right Tail Represents the Testing Stream. The documents on the left side are the baseline for the testing on the right side.
אז תחזור לציור, החלק השמאלי הוא שייך לספסיפיקיישן סטרים, לזרם הספסיפיקציות של דרישות, ספקים, אפיון ומימוש והחלק השמאלי הזנב השמאלי הוא שייך לבדיקות.
כל קלט, כל מסמך של כל אחד מהשלבים האלה, מסמך או תוצר מהווה בסיס לכל חלק בשלב הבדיקות לכל חלק בזנב הבדיקות כלומר מסמך הדרישות הוא הבסיס לבדיקות ה-ATP לתכנון וביצוע בדיקות ה-ATP מסמך הספסיפיקציות הוא בסיס לתכנון וביצוע סיסטם טסט מסמך הדיזיין הוא בסיס לתכנון וביצוע
בדיקות האינטגרציה והמודואים עצמם הקוד הוא בסיס לביצוע ה-Unitest ולתכנון ה-Unitest. Step by step, נעבור עכשיו שלב אחרי שלב במודל.
Requirement phase, שלב הדרישות All possible requirements of the system to be developed are captured in this phase. Requirements are set functionalities and constraints that the end user expects from the system.
These requirements are analyzed for their validity. אוקיי, אז בגדול הדרישות זה, אנחנו אוספים את כל הדרישות מהלקוח, מה הוא רוצה מהמערכת כאשר הדרישות זה אוסף זה קבוצה של יכולות פונקציונליות ואיסורים ומותרות שהמערכת רוצה יכולה לעשות לפי הדרישות של משתמש הקצה או של הלקוח ועושים איזושהי ולידציה על הדרישות האלה שהן נכונות
שהן ברורות וכדומה. Requirement phase continue המשך לשלב הדרישות. Usually the project manager system analysis is the main responsibility for the output of the phase.
The output will be requirements document. Testers use these documents for system and ATP tests. אז בדרך כלל לא השתנה הרבה ממודל המפ"ל. מי שעושה את השלב הזה, מי שאחראי עליו בדרך כלל זה מנהל הפרויקט או מנתח המערכות.
התוצר של השלב הזה זה מסמך הדרישות ואנשי הבדיקות משתמשים, אם זה אנשי הבדיקות של הלקוח הם משתמשים בזה ל-ATP. לכתיבה ולתכנון של ה-ATP ואנשי הבדיקות או צוות הבדיקות של החברה המפתחת משתמש בזה לטובת כתיבה של תסריטים בדיקות לבדיקות מערכת ל-System Tests.
ב-Analysis this document the tester can plan and write test cases that will cover each requirement. Programmers usually don't use this document for the work or so it can help them to see the big picture.
אנחנו כאנשי בדיקות מנתחים את מסמך הדרישות ונעזרים בזה לכתוב תסריטי בדיקות שיבדקו שאכן או שייחסו כל דרישה ודרישה. בדרך כלל מתכנתים לא מסתכלים או קוראים את המסמך על זה.
כמו שהזכרנו בעבר במודל המפל, שווה היה שהם כן יסתכלו על זה כי זה יכול לתת להם אפשרות לראות את התמונה הכללית ואת התמונה הגדולה. ספסיפיקיישן פייז, שלב הספציפיקציות, הקלט זה מסמך הדרישות.
The specification phase defined the product functionality. שלב הספציפיקציות למעשה מחדד ומרחיב את שלב, את הדרישות. These specifications are analyzed for their validity and verified that there is a reference for each requirement.
שוב, עושים איזשהו תהליך ולידציה על מסמך הספציפיקציות, שהן ברורות, שבאמת הן מכסות כל requirements וכדומה. Specification phase continued, המשך של שלב הספציפיקציות.
Usually the project manager system analysis is the main responsibility for the output of the phase. שוב, באחריות מנהל הפרויקט או מנתח המערכות לעשות את השלב הזה ולכתוב את המסמך.
The output will be specification document. המסמך יהיה מסמך ספציפיקציות. This document helps the testers to understand the functionality of the entire system.
המסמך הזה עוזר לנו כאנשי בדיקות להבין את הפונקציונליות או להבין את הדרישות יותר לעומק ברמה יותר עמוקה את דרישות המערכת. Specification phase continue, המשך של שלב הספציפיקציות.
טסטרס use this document to help them in designing and writing integration and system test cases. אנחנו משתמשים בזה לסייע לנו בתכנון ובכתיבה של מסמכי הבדיקות עבור בדיקות אינטגרציה ועבור בדיקות מערכת.
Programmers usually don't use this document for the work, although it can help them to see the big picture. שוב, אם המתכנתים ישתמשו במסמך הזה, זה יעזור להם לקבל הבנה עמוקה יותר על המערכת שהם כותבים.
Design phase, שלב ה-Design, שלב התכנון. Input specification document, הקלט לשלב הזה הוא מסמך הספציפיקציות. Translate the specification document to software representation ספציפיקציות כמו ספציפיקציות דאטה, ארכיטקטורה, אלגוריתם, אינטרפייסים, זכויות חובה, אנחנו מתרגמים את
הספציפיקציות למובנים תכנותיים, לשפה תכנותית יותר, שהמתכנתים יבינו, כמו המבנה נתונים, קשרים בין טבלאות, אלגוריתמים, ארכיטקטורת תוכנה, ממשקים, דרישות חומרה, עבודה עם תוכנות אחרות וכדומה.
Specifications are analyzed for their validity and verified that there is a reference for each requirement. שוב עושים איזשהו תהליך ולידציה לוודא שלא פספסנו כלום, שהדיזיין מספיק ברור ונהיר ושמתכנת יכול להבין אותו וכדומה.
Design phase continuous, המשך שלב האפיון. Usually the programmer team leader is the main responsibility for the output of the