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

כותב המאמר

אהד גניאל

יועץ, מנהל ומייסד

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

שיטת אימ המודל מפל המים Waterfall

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

על היתרונות והחסרונות של מודל מפל המים, כי הקוד לא זורם מעצמו…

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

מודל מפל המים

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

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

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

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

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

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

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

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

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

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

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

1. עבודה בטור – שלב אחר שלב, מדובר במחזור פיתוח אחד ויחיד.

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

3. ניסיון כן לנסות ולצפות את הדרישות שיכולות לעלות מתוך תהליך כתיבת הקוד כדי לתת להן ביטוי בשלבי התכנון.

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

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

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

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

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

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

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

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

5. המשתמש ומעורבותו – לוקח זמן רב עד שהלקוח (המשתמש) יראה את התוצר או המוצר ומחיר של טעות, סטייה, שגיאה הוא גבוה יותר.

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

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

1. תכנון יסודי ומקיף שנכון לעשות עם המשתמש (הלקוח).

2. אפיון ברור לפני יצירה לעיצוב.

3. עיצוב ותכנון השלד או המרכיבים המרכזיים לפני כתיבת קוד.

4. תיעוד התהליך.

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

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

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

מאמרים נוספים מפי המחבר

שיטת התבחינים לגיוס והכשרה

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

קרא עוד »
ניהול ומנהיגות לקחת סיכון

ניהול ומנהיגות לקיחת סיכון

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

קרא עוד »
ניהול פוסט קורונה 5.0

ניהול פוסט קורונה 5.0

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

קרא עוד »