מודל מפל המים

מתוך ויקיפדיה, האנציקלופדיה החופשית
קפיצה אל: ניווט, חיפוש
הנדסת תוכנה
מאמר זה הוא חלק מקטגוריית הנדסת תוכנה

Coding Shots Annual Plan high res-5.jpg
מתכנת בעבודתו

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

Crystal Clear | Scrum | Unified Process | Extreme Programming | Continuous integration

תחומים תומכים
ניהול פרויקטים | ניהול תצורה | תיעוד | הבטחת איכות | Profiling
כלים
מהדר | מקשר | IDE | ניהול גרסאות | אוטומציית בנייה

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

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

המתודולוגיה שייכת למשפחת המתודולוגיות הקוויות.

היסטוריה[עריכת קוד מקור | עריכה]

המתודולוגיה מיוחסת (בטעות) לווינסטון רויס, שדברים שכתב במאמר בשנת ‏1970[1] פורשו באופן פשטני ומוטעה. בהקשרה ההיסטורי, המתודולוגיה נתפסה כתגובה לשיטות אד הוק של 'תכנת ותקן' שרווחו מאוד בשנות ה-60 של המאה ה-20 (ועדיין רווחות). במאמר, רויס ממליץ לפתח מערכות תוכנה בשני מחזורי פיתוח ('Do it twice'), וטוען שבפרויקטים בהם מידת החדשנות גדולה, יש להתייחס למחזור הפיתוח הראשון של המערכת כפיילוט שצריך לזרוק אותו ('Throw-away')[2].

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

מתודולוגיית מפל המים השפיעה עמוקות על ענף התוכנה. לרוע המזל, הפרשנות המוטעת היא זו שהשתרשה בתעשייה, ופעמים רבות אף הפכה לתקן ממשלתי מחייב לפיתוח תוכנה (ראה DoD-STD-2167 ונוהל מפת"ח).

עקרונות וטכניקות[עריכת קוד מקור | עריכה]

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

בעד ונגד[עריכת קוד מקור | עריכה]

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

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

ראו גם[עריכת קוד מקור | עריכה]

הערות שוליים[עריכת קוד מקור | עריכה]

  1. ^ 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.
  2. ^ Larman, Craig (2003), Agile and Iterative Development: A Manager's Guide, Addison-Wesley Professional, p. 102-106, ISBN 0131111558