מודל מפל המים
מתוך ויקיפדיה, האנציקלופדיה החופשית
| הנדסת תוכנה |
|---|
| מאמר זה הוא חלק מקטגוריית הנדסת תוכנה |
| פעילויות ושלבים |
| דרישות | ניתוח | ארכיטקטורה | עיצוב | תכנות | בדיקה | אימות | בניה | הצבה | תחזוקה |
| מתודולוגיות |
| מפל המים | תכנת ותקן |
| תחומים תומכים |
| ניהול פרויקטים | ניהול תצורה | תיעוד |
מפל-המים (ידועה גם בשם מודל מפל-המים) היא מתודולוגיה ותיקה ורווחת לפיתוח מערכות תוכנה. בשיטה זו, פיתוח התוכנה מתבצע בתהליך שיטתי ולוגי המורכב משלבים מוגדרים־היטב שאין לפסוח עליהם. השלבים מבוצעים בטור, אחד אחרי השני, ובכל שלב יש מיקוד במשימה עיקרית אחת בלבד. זרימה זו דומה לזרימתו של מפל מים דרך מספר בריכות, מגבוהה לנמוכה, ומכאן שמה של המתודולוגיה.
מתודולוגיית מפל המים שמה דגש רב על איסוף וניתוח של כל הדרישות כולן קודם לתחילת הפיתוח, וממליצה שתהליך הפיתוח לא יחזור לאחור לאחר ששלב מסוים בו הסתיים. השלבים העיקריים בשיטה זו הם איסוף וניתוח דרישות, עיצוב תוכנה, תכנות, בדיקות, שילוב, התקנה ותחזוקה.
המתודולוגיה שייכת למשפחת המתודולוגיות הקוויות.
תוכן עניינים |
[עריכה] היסטוריה
המתודולוגיה מיוחסת (בטעות) לוינסטון רויס, שדברים שכתב במאמר בשנת 1970[1] פורשו באופן פשטני ומוטעה. בהקשרה ההיסטורי, המתודולוגיה נתפסה כתגובה לשיטות אד הוק של 'תכנת ותקן' שרווחו מאוד בשנות ה-60 של המאה ה-20 (ועדיין רווחות). במאמר, רויס ממליץ לפתח מערכות תוכנה בשני מחזורי פיתוח ('Do it twice'), וטוען שבפרויקטים בהם מידת החדשנות גדולה, יש להתייחס למחזור הפיתוח הראשון של המערכת כפיילוט שצריך לזרוק אותו ('Throw-away')[2].
את המאמר עיטרו מספר דיאגרמות שביארו את המודל, ואחת מהן, אחרי פרשנות נאיבית שעשו לה אחרים (בעיקר בארגון NATO), הפכה לדיאגרמה המקובלת המציגה את מודל מפל-המים. יש לציין שרויס לא השתמש כלל במטאפורה "מפל-מים" במאמר. למרבה האירוניה, בעוד שהוגה השיטה צידד בגישה איטרטיבית לפיתוח תוכנה, הפרשנות לשיטתו הפוכה לחלוטין והיא היתה, ונכון לתחילת המאה העשרים ואחת - עודנה, מקור עיקרי לבעיות בפרויקטים לפיתוח תוכנה.
מתודולוגיית מפל המים השפיעה עמוקות על ענף התוכנה. לרוע המזל, הפרשנות המוטעת היא זו שהשתרשה בתעשיה, ופעמים רבות אף הפכה לתקן ממשלתי מחייב לפיתוח תוכנה (ראה DoD-STD-2167 ונוהל מפתח).
[עריכה] עקרונות וטכניקות
- גישה קווית לפיתוח תוכנה, דהיינו, מחזור פיתוח אחד.
- פורמליזציה נרחבת ומוקדמת של הדרישות והמפרטים. פעמים רבות, עד כדי שליש או מחצית מזמן הפיתוח מוקדש להפקה של מסמכים ותיעוד ולא לכתיבת קוד.
- בפרויקטים גדולים מקובל לחלק את המערכת לתתי-מערכת ורכיבים לפי גבולות פונקציונליים, אך אין כלל דגש על בניית המערכת מקצה-לקצה.
- דגש רב על עיצוב מוקדם של התוכנה, לפני התכנות בפועל, מתוך ניסיון לצפות שינויים עתידיים בדרישות.
[עריכה] בעד ונגד
יש הטוענים שגישת מפל המים מתאימה לפתוח מערכות מידע מורכבות בעלות היקף גדול, התומכות בפעולות מובנות ומוגדרות היטב. למשל מערכת ניהול הזמנות בחברות תעופה. ניהול הפרויקט יכול להתרכז בהשלמת כל משימה באופן עצמאי בכל שלב ושלב, ולוחות זמנים יכולים להיקבע ולהישמר. הרעיון המרכזי הוא שפיתוח של מערכת מידע ותפעולה חייבים לעבור דרך תהליך שיטתי ולוגי, המורכב משלבים מוגדרים שאין לפסוח עליהם ושאת ביצועם אין לשנות.
אחד החסרונות הבולטים בשיטה זו הוא התארכות התהליך, בשל הדגש על שלב הניתוח והעיצוב דבר שמגדיל גם את עלות הפרויקט. חיסרון נוסף הוא היווצרות נתק בין המפתחים למשתמשים, היות ושלב הפיתוח הוא ארוך חולף זמן רב עד שהמשתמשים מקבלים או רואים את המערכת החדשה ולכן אין להם שום תמריץ לבקר את המפתחים. בעיה נוספת בגישה זו קשורה לשיתוף פעולה בין המשתמשים למפתחים בשלבים הראשונים: לא תמיד ניתן להגדיר מערכת ולנתחה בשיטה מובנית היות והמשתמש לא תמיד יודע להגדיר את צרכיו. ולכן במערכות מידע הנועדות לשימוש הדרג הניהולי שבהן הטכניקות אינן מובנות נדרשת גישת פיתוח שונה, שלא תתבסס (לפחות לא בהתחלה) על ניתוח מובנה אלא על התנסות משותפת של המפתח והמשתמש.
[עריכה] ראו גם
[עריכה] הערות שוליים
- ^ 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, ISBN 0131111558
