מודל מפל המים לפיתוח תוכנה Waterfall

נציג כאן את מודל מפל המים ונבחן את מידת התאמתו לניהול פרויקטים לפיתוח תוכנה בפרט וכגישה או כלי לניהול תהליכים שדורשים מבני אדם, מוטיבציה, חדשנות ורצון לעשות את המיטב. נציג את היתרונות (מה ניתן לאמץ) ואת החסרונות (וגם נציג מה נכון להוסיף כדי לשפר).

רקע על מודל מפל המים לפיתוח תוכנה
שלביו המרכזיים של מודל מפל המים
עקרונותיו המרכזיים של מודל מפל המים Waterfall
מהם חסרונותיו המרכזיים של מודל מפל המים לפיתוח תוכנה?

מודל מפל המים הוא גישה או שיטה לפיתוח תוכנה. מדובר בשיטה נפוצה ומוכרת שמתבססת על תהליך ליניארי (עבודה בטור, דבר אחרי דבר) שניתן לתכננו היטב, לפעול על פי התכנון ולכן שיטה שיטתית ולוגית היא פתרון מיטבי.

כשהכל הולך כשורה "והמים זורמים לכיוון הנכון" המתודולוגיה של מפל המים נהדרת. יחד עם זאת, לא תמיד כל הדרישות לפיתוח זמינות בתחילת התהליך, לא כולן מדויקות ומהודקות ולכן קורים מקרים שלמרות התכנון היסודי והרציני, יש צורך לחזור משלב אחד לשלב אחר כדי לבצע התאמות. דבר שמביא לאובדן זמן והון.

יתכן והסיבה למורכבות או לקושי שהמודל יוצר בפיתוח תוכנה הוא מקור פיתוח המודל. מדובר במודל שפותח לתעשיית הייצור והבנייה. היכן שהסביבה הפיזית (מפעל למשל) מאוד משפיעה על יכולת הביצוע והייצור וכל שינוי בה יכול להיות כה יקר עד שלא יהיה כדאי. כשמודל זה אומץ לפיתוח תוכנה לא היו אפשרויות או מודלים מוכרים אחרים ובוודאי לא מודלים שמתייחסים לעבודה יצירתית מבוססת ידע.

שלבי מודל מפל המים המרכזיים

איסוף והבנה של כל הדרישות וביצוע עיבוד של הדרישות, מדובר במסמך אפיון יסודי ורציני. כאשר המטרה להצליח לאסוף את כל הדרישות כדי להימנע ממצב שלאחר שעוברים לשלב הבא יש צורך בחזרה אחור בשל דרישה חדשה. כבר כאן יש כשל מובנה, בתיאוריה ניתן לומר "איסוף כל הדרישות" בפועל או במציאות כשמתחילים לעצב ולתכנת מתגלים דברים שלא חשבו עליהם בתחילת התהליך, לעיתים אלה דברים שלא ניתן היה לחשוב עליהם בתחילת התהליך והינם חיוניים להצלחת התוכנה או המוצר.

בעצם מדובר בתהליך תכנוני של ה"שלד", המערכת והרעיונות שיהיו מרכיבים במוצר או בתוכנה.

זהו השלב שבו נכנסים לפעולה, כותבים את הקוד, מפתחים את הרכיבים השונים ע"פ השלבים הקודמים (דהיינו עיצוב התוכנה ומסמכי האפיון שנוצרו בשלב הדרישות והניתוח).

שלב חשוב שבו מפעילים את התוכנה במצבים רבים ומשתדלים להריץ מקרי קיצון לצד תהליכים ברורים כדי לבדוק שאכן התוכנה או המוצר מבצע את הדרוש. כאשר יש תקלה "חרק" (Bug) מחזירים לתיקון.

לאחר שמבוצעת ההתקנה של התוכנה או המוצר אצל הלקוח או שילוב המוצר במוצר אחר, מתבצע תהליך קבוע של אחזקה ותחזוקה.

שלבי מודל מפל המים לפיתוח תוכנה
Shutterstock

עקרונותיו המרכזיים של מודל מפל המים Waterfall

  • תכנון – בשלבי התכנון מושקע זמן רב מאוד כדי להכיל כמעט את הכל. מדובר בשלבים שבהם אין כלל כתיבה של הקוד (ליבת העבודה בפיתות תוכנה) אלא בעיקר במסמכי אפיון (שימוש נרחב ביישומי Office). כמו-כן, קיים ניסיון לצפות את הדרישות שיכולות לעלות מתוך תהליך כתיבת הקוד כדי לתת להן ביטוי בשלבי התכנון.
  • עבודה בטור – שלב אחר שלב, מדובר במחזור פיתוח אחד ויחיד.

מהכתוב עולה שמודל מפל המים יכול להיות שיטה או גישה טובה לייצור מוצרים שפעילותם דומה לעצם השיטה, דהיינו תהליכים שבו כל שלב מקדים מחייב את השלב הבא בהתקדמות ואין חזרה אחורה. זאת יכול להיות שיטה נהדרת עבור משימות קבועות וברורות שיכולות לפעול כל אחת בנפרד ובמקביל. מדובר בשיטה מאוד פשוטה להבנה ויישום, בה כל שלב מבוצע פעם אחד בתהליך, כל שלב מובחן ומובדל מהשלב שלפניו ומזה שאחריו (יש אבני דרך ברורות). הכל מתועד מהתכנון, דרך התהליך ועד לתוצרים. גם יש היגיון תכנוני שבו הגדרה לפני עיצוב ועיצוב לפני כתיבת קוד.

למשל תוכנה לשיבוץ עובדים בסידור עבודה במפעל או תוכנה לניהול תהליך גיוס לקוחות שמובנית משלבים ברורים וליניאריים. אלו תוכנות פשוטות שבהן כל הדרישות ברורות ונהירות.

ככל הנראה הסיבה לכך שלמרות היותה גישה וותיקה בעולם ההייטק יש חברות שזונחות אותה בשל חסרונותיה ועוברות לגישות אחרות כמו גישת הסקראם (אג'ייל).

חסרונות מודל מפל המים Waterfall Disadvantages

  • דרישות ש"צצות" – היכולת לצפות ולשער את הדרישות שיעלו תוך כדי תהליך הפיתוח אינה יכולה להתקיים במציאות. ניתן להבין זאת בקלות מניסוי הספגטי ולהיווכח עד כמה נכונה הגישה של התנסות ולמידה, ושוב התנסות ולמידה שמאפיינת גישות או מודלים אחרים לפיתוח תוכנה ולניהול.
  • היכולת 'לדלבר' – כלומר להפעיל את התוכנה אצל המשתמש גם כשלא כל הפונקציונליות קיימת.
  • מתודולוגיה קווית – העובדה שמדובר במתודולוגיה קווית שמסתייגת מחזרה שלב אחד אחורה עלולה להוביל לעמידה בדרישות הקדם תוך פגיעה באיכות הביצוע של המוצר או התוכנה. הרי תיקון חשוב וחיוני שלא שוער בשלב הראשון אינו כישלון תכנוני, אלא עשוי להיות גם התפתחות שלא יכלה כלל לעלות כשעוד לא היתה כל התנסות.
  • משאבי זמן – בפיתוח תוכנה, ליבת העבודה מושקעת בכתיבת הקוד עצמו. בגישת מפל המים, משאבי הזמן שמשוקעים בתכנון, ביורוקרטיה, ניירת, אפיון, הם אדירים ובאים על חשבון זמן כתיבה שיכול היה לקדם את התהליך. בנוסף ניתוב הזמן לכתיבת הקוד יכול כבר להציג דרישות או מצבים שעליהם לא ניתן היה לחשוב מראש.
  • המשתמש ומעורבותו – לוקח זמן רב עד שהלקוח (המשתמש) יראה את התוצר או המוצר ומחיר של טעות, סטייה, שגיאה הוא גבוה יותר.

חמשת החסרונות האלה עלולים להפוך את הפרויקט ליקר מעבר לדרוש. העובדה שתהליכי הפיתוח (משלב הדרישות ועד לשלב בדיקה או התחזוקה) ארוכים וממושכים ובהם אין למשתמשי הקצה (הלקוחות למשל) שום שיג ושיח עם המפתחים עלול להביא להיעדר בקרה, היזון חוזר ותיקון שנכון לשלבים מסוימים ויהיה יקר פי כמה בסיום הפרויקט.

הדבר האחרון הוא ההבנה שלא תמיד הגורם המממן (הלקוח) יודע להגדיר את כל צרכיו ורצונותיו. לכן יש חשיבות גדולה לשיח של המשתמש (הלקוח) לבין המפתחים לאורך שלבי התהליך ולא רק בתכנון ובדיעבד בהגשת התוכנה.

  • תכנון יסודי ומקיף שנכון לעשות עם המשתמש (הלקוח).
  • אפיון ברור לפני יצירה לעיצוב.
  • עיצוב ותכנון השלד או המרכיבים המרכזיים לפני כתיבת קוד.
  • תיעוד התהליך.
  • לאפשר בשלב ההטמעה והמימוש (כתיבת הקוד) הצפת דרישות או מצבים שלא תוכננו ולייצר שיח עם המשתמש. דבר שגם מביא את המפתחים להרגיש בעלי משמעות (שהינו אחד ממקורות המוטיבציה של מודל מעש"ה).
  • לייצר חיבור בין שלב לשלב (לטשטש מעט את הגבולות) ובכך להביא לשיפור עצם התהליך.
  • להבין שתפיסת החיזוי של כל התהליך מקצה לקצה בלתי אפשרית והצפת דרישות או מצבים שלא תוכננו תוך כדי התהליך תשפר את המוצר ותקצר את מסגרת הזמן המוקצית לפרויקט.