מודל מפל המים
מתודולוגיה לפיתוח תוכנה מוויקיפדיה, האנציקלופדיה החופשית
Remove ads
מתודולוגיה לפיתוח תוכנה מוויקיפדיה, האנציקלופדיה החופשית
מודל מפל-המים היא מתודולוגיה ותיקה לפיתוח פרויקטים מורכבים, ורווחת בתחום הפיתוח של מערכות תוכנה. בשיטה זו, פיתוח התוכנה מתבצע בתהליך שיטתי ולוגי המורכב משלבים מוגדרים־היטב הבאים זה אחר זה, ומתכנסים למערכת מלאה ועובדת. תהליך ההתכנסות של המשימות השונות עד למסירת המערכת מיוצג כגאנט של קווים מקבילים על רצף הזמן שהולכים ומסתיימים כך שנוצר תיאור מדורג הדומה לזרימתו של מפל מים דרך מספר בריכות, מגבוהה לנמוכה, ומכאן שמה של המתודולוגיה.
הנדסת תוכנה |
---|
ערך זה שייך לקטגוריית הנדסת תוכנה |
פעילויות ושלבים |
דרישות • ניתוח • אפיון • ארכיטקטורה • עיצוב • תכנות • ניפוי שגיאות • בדיקה • אימות • בנייה • פריסה • תפעול • תחזוקה |
מתודולוגיות |
זריזות • מפל המים • תכנת ותקן • 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].
Seamless Wikipedia browsing. On steroids.
Every time you click a link to Wikipedia, Wiktionary or Wikiquote in your browser's search results, it will show the modern Wikiwand interface.
Wikiwand extension is a five stars, simple, with minimum permission required to keep your browsing private, safe and transparent.