Waterfall Model - חלק 2
פרקי ההרצאה: Waterfall Model - חלק 2
תמלול ההרצאה: Waterfall Model - חלק 2
הטקסט המלא של הדקות הראשונות בהרצאה «Waterfall Model - חלק 2» בקורס הווידאו של PracticU – כתוביות בעברית עם זמן התחלה לכל פסקה. כך תוכלו לקרוא ולחפש את הנושאים לפני שמתחילים ללמוד.
טוב, זה החלק השני של ההרצאה שמדברת על מודל המפל, על ה-Rotorful. עד עכשיו ראינו את המודל עצמו, דיברנו על שלב בכל המודל, על כל שלב במודל.
מחזרה למודל, Back to the Model. Feedback Slops Allow Corrections in the Model. אז כמו שאמרנו, יש לנו איזושהי קורלציה בין בכל שלב ושלב של מודל.
אם נניח משלב ה-Requirements עברנו לשלב הספציפיקציה, וגילינו בעיה בשלב הספציפיקציות אנחנו נעלה חזרה לשלב ה-requirements ונבדוק האם הבעיה קיימת לא רק ב..אם הבעיה גם קיימת שם.
אם היא קיימת שם נעשה גם את התיקון המתאים. Every time change is being made in a phase, the output document should be updated and if needed the phase above it.
אז כמו שאמרתי אם נעשה שינוי או אם אנחנו מגלים איזושהי בעיה באיזשהו שלב, אנחנו בודקים גם את ה input document של השלב הזה ואם הבעיה גם נמצאת בו או שהבעיה נבעה מה input document אנחנו נעלה לשלב מעל, אותו שלב שיצר לנו את ה input document ונתקן, נעשה את התיקונים הנדרשים.
מה זאת אומרת? אם זה המודל שלנו, אז אם יש לנו בעיה בשלב האימפלמנטציה שהתגלתה בשלב הטסטינג, אנחנו נבדוק אם זו רק בעיה בשלב האימפלמנטציה, כלומר לא הבינו את הדיזיין או המתכנת טעה וכדומה, אז אנחנו, התיקונים
יבוצעו רק בשלב האימפלימנטציה. אם נגלה שבכלל הבעיה היא עמוקה יותר, זאת אומרת היא באמת המתכנת טעה, אבל הטעות שלו נובעת כתוצאה ממה שכתוב במסמך הדיזיין, אנחנו נעלה לשלב הדיזיין, נתקן את המסמך ונורד חזרה לשלב האימפלימנטציה, שהירידה חזרה אומרת שמביאים את המסמך המתוקן,
מסמך הדיזיין המתוקן, שקלט לשלב האימפלמנטציה. Advantages of the model, מה היתרונות של המודל? Inforced Discipline, הוא מחייב משמעת, הוא מחייב משמעת של הארגון.
למה? כי הוא מחייב שיהיה לכל שלב תוצר סופי שבא בצורת ניירת, בא בצורת מסמך. הוא מחייב שכל פעם שאנחנו מגלים טעות או בעיה אנחנו נעלה גם לשלב, אם הבעיה קיימת בשלב מעל, אנחנו נשב ונתקן ונעבוד גם, נחזור חוזר לשלב הקודם, נעשה את התיקונים הנדרשים ונמשיך הלאה לשלב
הבא. Each phase is 100% complete and absolutely correct before proceeding to the next phase of program creation. אז שוב, אי אפשר לעבור לשלב לפני שהקלט או סליחה הפלט של אותו שלב מוכן והפלט של אותו שלב זה אותו תוצר שנעשה בשלב הקודם.
זאת אומרת עד שאין לי מסמך דרישות אני לא מתחיל בכלל להסתכל או לחשוב על שלב הדיזיין ואני בטח לא מתחיל וחושב על שלב הספציפיקציות. אם גיליתי בעיה בשלב הספציפיקציות שנובעת משלב ה-requirements אני הולך ומתקן את שלב ה-requirements וכך חוזר חלילה.
Documents Driven – Each phase has documents as output – knowledge in paper and not in people's. כל שלב התוצר שלו הוא איזשהו מסמך – std, מסמך requirements, מסמך דרישות, מסמך ספציפיקציות, מסמך דיזיין וכדומה.
מה שאומר שהידע נמצא בארגון, הוא נמצא בניירות. זאת אומרת שמחר יכול לבוא מתכנת חדש, לקחת את מסמך הדיזיין ולהבין מה המערכת עושה.
הידע לא נמצא רק באנשים, הוא נמצא בארגון. מה שחוסך מצב שאם מחר המתכנת עוזב, אף אחד לא יודע מה הוא עשה, אף אחד לא יודע מאיפה הוא הביא את הנתונים שהוא הביא על הדיזיין שהוא עשה, שהוא ביצע וכדומה.
יתרון נוסף time spent early on making sure that requirements and design are absolutely correct is very useful in economic terms. It will save you much time and effort later.
אז אנחנו מקדישים, לפי המודל אנחנו משקיעים הרבה מאוד משאבים, הרבה מאוד זמן בכל שלב. אנחנו סוגרים אותו, מנסים לתחום אותו כמה שאפשר, מתקנים אותו כל פעם שיש בו טעויות.
מה שאומר שאם אנחנו מנסים כל הזמן ששלב הדרישות ייתן לנו מסמך דרישות מאוד מאוד נכון ומדויק זה יחסוך לנו זמן כי כל עוד הוא לא מדויק אנחנו לא עוברים הלאה.
כלומר אנחנו מקטינים את ההסתברות לבאגים בשלב הפיתוח כתוצאה מזה שאנחנו מנסים לתחום ולסגור כל שלב בפני עצמו.
Disadvantages of the model החסרונות של המודל Not all requirements are received at once. The requirements from customer goes on getting added to the list even after the end of requirements phase.
This affects the system development process and its success in negative aspects. צריך לזכור שבסך הכל בעולם האמיתי קשה מאוד לבוא ולהגיד בשלב הדרישות את כל הדרישות.
לא תמיד הלקוח ידע לבוא ולהגיד מה הוא באמת רוצה. לא תמיד לפעמים הוא רואה פתאום איזשהו מסך אחרי שבנינו לו אותו ואז הוא אומר אה דווקא הייתי רוצה שזה יעשה ככה וככה.
דווקא הייתי רוצה להוסיף עוד עמודה. דווקא, אני חושב שדווקא הלוגיקה שאמרתי לכם בהתחלה היא לא מספיק טובה. ולכן מאוד מאוד קשה לסגור כל שלב פה באופן הרמטי.
קשה לבוא ולהגיד, אוקיי, עד שאין לי את כל הדרישות אני לא עובר הלאה. כי זה יהיה איזשהו לופ תקוע. כי כדי שיהיה את כל הדרישות לפעמים צריך להתחיל לבנות משהו כדי שהלקוח יוכל להוסיף על זה דרישות.
או להבין עד כמה הדרישות שהוא רצה הן טובות או לא טובות מבחינתו. Not all the problems related to a phase are solved during the same phase. אז הרבה פעמים יכול להיות בעיות שהן כרגע לא פתירות.
אז מה, זה אומר שבגלל זה לא נמשיך הלאה? אז אנחנו נתקע את הפרויקט. יכול להיות שהפתרון הוא תלוי זמן פיתוח יותר גדול. יכול להיות שהוא תלוי דברים אחרים שעוד טרם נבדקו או טרם אושרו וכדומה.
חיסרון נוסף: It is impossible to get one phase of a software or product slice cycle perfected before moving on the next phases and learning from them.
אז שוב קשה מאוד או כמעט בלתי אפשרי בעולם באמת לבוא ולבוא ולהגיד שלפגור שלב שהוא יהיה מושלם אין מושלם אין מושלם לא בעולם ולא בתוכנה בכלל אי אפשר לבוא ולהגיד יש לי מסמך דרישות מושלם אי אפשר לבוא ולהגיד ישבתי עם הלקוח והוצאתי ממנו את כל לדרישות ואין שום סיכוי בעולם שהוא ישנה את הדרישות שלו.
יש יותר סיכוי שהוא ישנה את הדרישות שלו או שהוא יתחרט על דרישות שהוא נתן מאשר שנוכל לבוא ולהגיד לא השתנה שום דבר מדרישות הלקוח. כנ"ל גם לספסיפיקציות, כנ"ל גם לדיזיין, כנ"ל גם לאימפלמנטציה, כנ"ל לכתיבת מסמכי ה-STD וכדומה.
חיסרון נוסף Testing follows directly after the implementation and שלב הטסטינג מתבצע רק למעשה אחרי שיש אימפלמנטציה שאחרי שיש אימפלמנטציה נכנס שלב ה-unit testing ואחרי אינטגרציה למעשה נכנס ה-integration test וה-system test.
למה זה חיסרון? כי החיסרון אומר שאנחנו לא מתחילים לבדוק או אנחנו לא משולבים בתהליך קבלת ההחלטות מההתחלה. הבדיקות כאילו הן בסוף לפי המודל הזה