מודל מפל המים
| הנדסת תוכנה |
|---|
| ערך זה שייך לקטגוריית הנדסת תוכנה |
| פעילויות ושלבים |
| דרישות • ניתוח • אפיון • ארכיטקטורה • עיצוב • תכנות • ניפוי שגיאות • בדיקה • אימות • בנייה • פריסה • תפעול • תחזוקה |
| מתודולוגיות |
| זריזות • מפל המים • תכנת ותקן • Crystal Clear • Scrum • Unified Process • Extreme Programming • אינטגרציה רציפה • DevOps |
| תחומים תומכים |
| ניהול פרויקטים • ניהול תצורה • תיעוד • הבטחת איכות • Profiling |
| כלים |
| מהדר • מקשר • מפרש • IDE • ניהול גרסאות • אוטומציית בנייה |
מודל מפל-המים היא מתודולוגיה ותיקה לפיתוח פרויקטים מורכבים, ורווחת בתחום הפיתוח של מערכות תוכנה. בשיטה זו, פיתוח התוכנה מתבצע בתהליך שיטתי ולוגי המורכב משלבים מוגדרים־היטב הבאים זה אחר זה, ומתכנסים למערכת מלאה ועובדת. תהליך ההתכנסות של המשימות השונות עד למסירת המערכת מיוצג כגאנט של קווים מקבילים על רצף הזמן שהולכים ומסתיימים כך שנוצר תיאור מדורג הדומה לזרימתו של מפל מים דרך מספר בריכות, מגבוהה לנמוכה, ומכאן שמה של המתודולוגיה.
מתודולוגיית מפל המים שמה דגש רב על איסוף וניתוח של כל הדרישות כולן קודם לתחילת הפיתוח, וממליצה שתהליך הפיתוח לא יחזור לאחור לאחר ששלב מסוים בו הסתיים. השלבים העיקריים בשיטה זו הם איסוף וניתוח דרישות, עיצוב תוכנה, תכנות, בדיקות, שילוב, התקנה ותחזוקה.
המתודולוגיה שייכת למשפחת המתודולוגיות הליניאריות.
היסטוריה
המתודולוגיה מיוחסת (בטעות) לווינסטון רויס, שדברים שכתב במאמר בשנת 1970[1] פורשו באופן פשטני ומוטעה. בהקשרה ההיסטורי, המתודולוגיה נתפסה כתגובה לשיטות אד הוק של 'תכנת ותקן' שרווחו מאוד בשנות ה-60 של המאה ה-20 (ועדיין רווחות). במאמר, רויס ממליץ לפתח מערכות תוכנה בשני מחזורי פיתוח ('Do it twice'), וטוען שבפרויקטים בהם מידת החדשנות גדולה, יש להתייחס למחזור הפיתוח הראשון של המערכת כפיילוט שצריך לזרוק אותו ('Throw-away')[2].
את המאמר עיטרו מספר דיאגרמות שביארו את המודל, ואחת מהן, אחרי פרשנות נאיבית שעשו לה אחרים (בעיקר בארגון NATO), הפכה לדיאגרמה המקובלת המציגה את מודל מפל-המים, על אף שרויס לא השתמש כלל במטפורה "מפל-מים" במאמר. למרבה האירוניה, בעוד שהוגה השיטה צידד בגישה איטרטיבית לפיתוח תוכנה, הפרשנות לשיטתו הפוכה לחלוטין והיא הייתה, ונכון לתחילת המאה העשרים ואחת - עודנה, מקור עיקרי לבעיות בפרויקטים לפיתוח תוכנה.
מתודולוגיית מפל המים השפיעה עמוקות על ענף התוכנה. הפרשנות המוטעית היא זו שהשתרשה בתעשייה, ופעמים רבות אף הפכה לתקן ממשלתי מחייב לפיתוח תוכנה (ראה DoD-STD-2167 ונוהל מפת"ח).
עקרונות וטכניקות
- גישה קווית לפיתוח תוכנה, דהיינו, מחזור פיתוח אחד.
- פורמליזציה נרחבת ומוקדמת של הדרישות והמפרטים. פעמים רבות, עד כדי שליש או מחצית מזמן הפיתוח מוקדש להפקה של מסמכים ותיעוד ולא לכתיבת קוד.
- בפרויקטים גדולים מקובל לחלק את המערכת לתתי-מערכת ורכיבים לפי גבולות פונקציונליים ולחלק את העבודה לצוותים בהתאם, אך אין כלל דגש על בניית המערכת מקצה-לקצה.
- דגש רב על עיצוב מוקדם של התוכנה, לפני התכנות בפועל, מתוך ניסיון לצפות שינויים עתידיים בדרישות.
בעד ונגד
יש הטוענים[דרושה הבהרה] שגישת מפל המים מתאימה לפתוח מערכות מידע מורכבות בעלות היקף גדול, התומכות בפעולות מובנות ומוגדרות היטב. למשל מערכת ניהול הזמנות בחברות תעופה. ניהול הפרויקט יכול להתרכז בהשלמת כל משימה באופן עצמאי בכל שלב ושלב, ולוחות זמנים יכולים להיקבע ולהישמר. הרעיון המרכזי הוא שפיתוח של מערכת מידע ותפעולה חייבים לעבור דרך תהליך שיטתי ולוגי, המורכב משלבים מוגדרים שאין לפסוח עליהם ושאת ביצועם אין לשנות. לא תמיד המתכנת מודע לכל העבירות של התהליך המורכב וכלן רצוי לבצע את כול התהליך באופן הדרגתי עם בדיקות בניקודות קריטיות[3].
אחד החסרונות הבולטים בשיטה זו הוא התארכות התהליך והמורכבות הרבה שלו, בשל הדגש על שלב הניתוח והעיצוב דבר שמגדיל גם את עלות הפרויקט.
חיסרון נוסף הוא היווצרות נתק בין המפתחים למשתמשים, היות ששלב הפיתוח הוא ארוך חולף זמן רב עד שהמשתמשים מקבלים או רואים את המערכת החדשה ולכן אין להם שום תמריץ לבקר את המפתחים.
בעיה נוספת בגישה זו קשורה לשיתוף פעולה בין המשתמשים למפתחים בשלבים הראשונים: לא תמיד ניתן להגדיר מערכת ולנתחה בשיטה מובנית היות שהמשתמש לא תמיד יודע להגדיר את צרכיו. ולכן במערכות מידע הנועדות לשימוש הדרג הניהולי שבהן הטכניקות אינן מובנות נדרשת גישת פיתוח שונה, שלא תתבסס (לפחות לא בהתחלה) על ניתוח מובנה אלא על התנסות משותפת של המפתח והמשתמש.
על רקע חסרונות אלו, החל מראשית המאה ה-21 הגישה הדוגלת בפיתוח תוכנה זריז החלה להפוך לפופולרית יותר, היות שהיא מתבססת על איטרציות פיתוח קצרות, בצוותים מגוונים, שבסופן מוצר חלקי אך עובד מוגש למשתמשים, ומתאפשר משוב מהיר יותר ותיקון טעויות אפיון בזמן אמת.[4]
ראו גם
קישורים חיצוניים
הערות שוליים
- ^ Royce, Winston W. (1970): Managing the Development of Large Software Systems: Concepts and Techniques. In: Technical Papers of Western Electronic Show and Convention (WesCon). August 25-28, 1970, Los Angeles, USA.
- ^ Larman, Craig (2003), Agile and Iterative Development: A Manager's Guide, Addison-Wesley Professional, p. 102-106, מסת"ב 0131111558
- ^ סטיב מקדודל, ספר Code Complete
- ^ מתן רוטמן, יותם הכהן, יואל יפה, פיתוח (תוכנה) אג׳ילי, באתר מאגר הידע של דואלוג, 2019
מודל מפל המים33238591Q478175