Waterfall Model - חלק 1
פרקי ההרצאה: Waterfall Model - חלק 1
תמלול ההרצאה: Waterfall Model - חלק 1
הטקסט המלא של הדקות הראשונות בהרצאה «Waterfall Model - חלק 1» בקורס הווידאו של PracticU – כתוביות בעברית עם זמן התחלה לכל פסקה. כך תוכלו לקרוא ולחפש את הנושאים לפני שמתחילים ללמוד.
ווטרפול מודל, מודל המפל. המודל המפל זה המודל הראשון שמנסה לעשות סדר בכל הנושא הזה של מעגל החיים של פרויקט תוכנה. הוא מודל הרבה יותר מסודר מהמודלים שראינו קודם, שזה ה-code and fixed וה-big bang.
lesson objectives, מטרות השיעור. What is the waterfall model? אנחנו נדבר מה זה מודל המפל, the waterfall model, נדבר על המודל עצמו.
Advantages and disadvantages of the model, היתרונות והחסרונות של המודל, ו-Waterfall in the real world, מכיוון שזה אחד המודלים הראשונים שנתנו איזשהו מבנה די מאורגן ומסודר לפרויקט פיתוח תוכנה, הרבה חברות מימשו אותו.
אחר כך מודלים כמו מודל V, מודל W ומודל ספירל למעשה מנסים לפתור בעיות שיש במודל המפה, לעשות אותו עוד יותר מסודר, נותנים איזשהו מקום ואיחוד בין QA לפיתוח וכדומה.
What is the Waterfall model? מה זה מודל המפל? Waterfall approach was first process model to be introduced and followed widely in software engineering to ensure success of the project.
אז גישת המפל זה איזשהו, זה אחד המודלים הראשוניים שבאמת ניסו להתמודד עם תהליך פיתוח התוכנה על האספקטים השונים שלו ולנסות לגרום לפיתוח התוכנה להיות מסודרת יותר.
Derive its name due to cascading effect from one phase to the other. אז המודל המפה על השם שלו זה בגלל שהצורה הגרפית של המודל היא מעין מדרדות שהן בסופו של דבר מזכירות מעין מפל או צורת זרימה של מפל.
ומה שזה אומר, למעשה שכאילו כל שלב, תהליך הפיתוח קשור לשלב שלפניו. כלומר, השלב x לא יכול להתקיים לפני ששלב y בוצע. Each output phase is used as input for the next phase.
לכל שלב יש איזשהו קלט ופלט. הפלט כלומר האאוטפוט של הפייז הזה של השלב הזה משמש כקלט לשלב הבא אחר כך also known as the linear sequential model אוקיי הוא השם האחר למודל המפל זה המודל הליניארי או השלב הליניארי מודל השלב הליניארי וזה מסיבה פשוטה שבסך הכל המודל הזה הוא מאוד ליניארי זאת אומרת כל שלב מתבצע אחרי שלב מסוים אין ביצוע של עבודה במקביל שזה זה גם אחד החסרונות
שלו, שהוא תמיד מחייב שכלב מסוים מסתיים לפני שאפשר יהיה להתחיל לעבור לשלב הבא. דאוט אופר מודל. עכשיו נראה את הצורה הגרפית של מודל המפל.
אז בהתחלה יש לנו דרישות, אנחנו כמובן בהמשך ההרצאה אנחנו נדבר על כל שלב בצורה יותר מעמיקה. שלב הדרישות, שזה אחרי זה, בתוך השלב הזה גם יש איזשהו שלב של תת שלב של וריפיקציה לדרישות, שבאמת הדרישות הן טובות, הדרישות הן נכונות, דרישות לא סותרות אחת את השנייה וכדומה.
אחרי שסיימנו את שלב ה-requirements, ה-output של השלב הזה נכנס כ-input לשלב הספציפיקציות, שזה השלב שבו בגדול מעמיקים את הדרישות, כותבים את הדרישות יותר לעומק, מנסים לרדת יותר בפרטים קטנים בכל דרישה ודרישה.
שוב, גם לשלב הזה יש שלב של וריפיקציה, לראות שבאמת עברנו על כל הדרישות, שבאמת הרחבנו את כל הדרישות, ועוד הפעם לא הגענו למצב של סתירה וכדומה. Output של שלב הספציפיקציה משמש כקלט לשלב הדיזיין, שבו עושים אפיון לקוד, ולמעשה ראש צוות הפיתוח בגדול מעצב איך הוא רואה את הקוד על מנת לממש את הספציפיקציות.
גם על השלב הזה יש תת שלב של וריפיקציה שלוודאי שהדיזיין הוא נכון ובאמת עשינו דיזיין לכל הספציפיקציות וכו'. האוטפוט של שלב הדיזיין משמש כאינפוט לשלב האימפלמנטיישן שזה השלב שבו המתכנתים כותבים קוד וברגע שהמתכנתים מסיימים מתחיל שלב הבדיקות שלב הטסטינג למעשה זה הלב או השלב הזה שגוזל את מרב הזמן בפרויקט לפי מודל המפל אחרי זה
יש את שלב האינטגרציה שלוקחים את כל המודולים אחרי שבדקנו אותם ועושים להם אינטגרציה למעשה האוטפוט של שלב האימפלמנטציה זה מודלים או מודולים סליחה מודולים מודולים שכתובים כבר בקוד והם מהווים את הקלט לשלב האינטגריישן שבסופו גם כן מבוצע טסטינג כדי לראות שאינטגריישן בוצע כמו שצריך.
אחר כך למעשה משחררים את התוכנה לייצור או ללקוח ואז מתחיל השלב הכי ארוך בתוכנה שזה שלב התחזוקה שבה כל פעם הלקוח מוצא איזשהו באג ומתקנים ומוצאים גרסאות עתידיות ומשפרים את התוכנה ועד הקטע שבו החברה מחליטה שזהו התוכנה עשתה חייתה מספיק בעולם העסקי וצריך לחשוב על דור ב דור ג' או בכלל להפסיק לתמוך בתוכנה.
בשלב הזה למעשה בשלב המנטננס מה שקורה זה שכל שינוי יוצר לנו מצב שאנחנו עושים עדכון ל-requirements שוב עושים ורפיקציה והם יורדים לשלבים למטה עשינו עדכון לדרישה אז כתוצאה מכך צריך לשנות את הספסיפיקציה כתוצאה מכך צריך לשנות
את המסמכי דיזיין כתוצאה מכך עושים שינוי באימפלמנטציה כתוצאה מכך עושים אינטגרציה שוב ובדיקות שוב ועוד הפעם maintenance וחוזר חלילה.
היופי הוא שלמעשה כל שלב בכל שלב אם אני מגלה טעות בשלב האימפלמנטציה אני אעלה למעלה לשלב הדיזיין כי אם אם יש לי אם בשלב האימפלמנטציה אני מגלה איזושהי בעיה סימן שהבעיה נובעת בשלב הדיזיין אם אני רואה שאולי הבעיה היא בשלב הדיזיין היא אפילו מעבר זאת אומרת כבר הבעיה היא לא רק בדיזיין עצמו היא כבר בספציפיקציות אני אעלה
לשלב הספציפיקציות ואני אתקן את כל מה שדרוש תיקון וזה בגדול מודל המפל שאנחנו נדבר על כל שלב בצורה יותר מהותית step by step requirements phase שלב הדרישות All possible requirements of the system to be developed are captured in this phase.
אז בשלב הזה אוספים את כל הדרישות של המערכת מהלקוח שאמורות להיות מפותחות. יושבים ופשוט כותבים את כל מה שהלקוח רוצה שהתוכנה הזאת תעשה. Requirements are set of functionalities and constraints that the end user expects from the system.
דרישות זה למעשה קבוצה אוסף של פונקציונליות של המערכת וכל מיני איסורים שהמערכת צריכה לתמוך כמו היא כן יכולה לעשות ככה והיא לא יכולה לעשות ככה ואני כן רוצה שיוזר מורשה לפעולה בנקאית יוכל לעשות פעולה בנקאית ויוזר שמורשה רק לצפות לא יוכל לעשות פעולה בנקאית וכדומה.
These requirements are analyzed for their validity. אחרי שאספנו את כל הדרישות, אנחנו עושים להם ולידציה כדי לראות שהדרישות שאספנו באמת ברורות, אנחנו מוודאים שאלה כל הדרישות שיש, אין לעודד את התוספות וכדומה.
Requirements Phase Continuum המשך הסבר על שלב ה-requirements Usually, the project manager or system analysis is the main responsibility for the output of the phase.
מי שבדרך כלל אחראי למעשה לאסוף את הדרישות ופחות או יותר לעשות להם גם את הוולידציה זה או מנהל הפרויקט או מנתח המערכות. מנתח מערכות זה גוף, זה איש, זה תפקיד, זה מקצוע, שהתפקיד שלו זה לבוא וללמוד את העסק, ללמוד את הסביבה העסקית, להבין מה הדרישות מהתוכנה שצריכה להיות ולכתוב מסמך אפיון,
מסמך דרישות. The output will be Requirement Document. התוצר, ה-output, הפלט של שלב ה-requirements יהיה מסמך שנקרא Requirement Documents.
מצוינים כל ה-requirements, כל ההשגות, איך צריך לעשות את הדברים מבחינת דרישות, מה הלקוח רוצה שהמערכת תעשה. טסטרס use this document for system and ATP acceptance tests.
אנשי הבדיקות או כל הלאמ"א QA משתמש במסמך הזה. המסמך הזה משמש איזשהו בסיס לכתיבת בדיקות מערכת סיסטמפ טסטס וטסטרים מצד הלקוח או נציגי הלקוח משתמשים במסמך הזה כדי לכתוב את הבדיקות של ATP.
ATP זה בדיקות קבלה, ואלה בדיקות שנעשות על ידי הלקוח עצמו ונציגיו ולא על ידי החברה שפיתחה את התוכנה. Requirements phase continue, המשך על שלב הדרישות.
By analysis this document, the tester can plan and write test cases that will cover each requirement. על ידי הניתוח של המסמך הזה והבנתו, איש הבדיקות למעשה מבין מהם דרישות המערכת.
כתוצאה מזה שהוא מבין, יודע הוא יכול להתחיל לתכנן ולכתוב טסט קייסס או תסריטי בדיקה שיבדקו שבאמת כל דרישה מכוסה שכל דרישה שהלקוח ביקש באמת התוכנה עושה אותה או לא עושה אותה במידה והדרישה היא לא לעשות משהו.
פרוגרמרס usually don't use these documents for the work or so it can help them to see the big picture. מתכנתים בדרך כלל לא משתמשים במסמך הזה.
מי שמשתמש בזה זה ראש צוות הפיתוח שבסופו של דבר משתמש בזה כבסיס לכתיבת מסמך הדיזיין שאיתו עובדים המתכנתים אבל אם המתכנתים ורצוי שהם כן יעברו על המסמך ויכירו אותו כי זה ייתן להם את האפשרות לראות את התמונה הגדולה זה ייתן להם את האפשרות לראות מה הלקוח רוצה ולפעמים נותן להם גם את האפשרות להבין ברמה קצת
יותר גבוהה מה הם למעשה כותבים מה זה הקלאס הזה שהם כותבים למה זה קשור ללקוח איך הלקוח בסופו של דבר ישתמש בקוד שהם כתבו אוקיי כי המתכנת כותבת אחורי הקלעים לא תמיד הוא יודע מה קורה לפני הקלעים specification phase שלב הספציפיקציות אז האינפוט זה requirement