מודל מפל המים
מתוך ויקיפדיה, האנציקלופדיה החופשית
| הנדסת תוכנה |
|---|
| מאמר זה הוא חלק מקטגוריית הנדסת תוכנה |
| פעילויות ושלבים |
| דרישות | ניתוח | ארכיטקטורה | עיצוב | תכנות | בדיקה | אימות | בניה | הצבה | תחזוקה |
| מתודולוגיות |
| מפל המים | תכנת ותקן |
| תחומים תומכים |
| ניהול פרויקטים | ניהול תצורה | תיעוד |
מפל-המים (ידועה גם בשם מודל מפל-המים) היא מתודולוגיה ותיקה ורווחת לפיתוח מערכות תוכנה. בשיטה זו, פיתוח התוכנה מתבצע בתהליך שיטתי ולוגי המורכב משלבים מוגדרים־היטב שאין לפסוח עליהם. השלבים מבוצעים בטור, אחד אחרי השני, ובכל שלב יש מיקוד במשימה עיקרית אחת בלבד. זרימה זו דומה לזרימתו של מפל מים דרך מספר בריכות, מגבוהה לנמוכה, ומכאן שמה של המתודולוגיה.
מתודולוגיית מפל המים שמה דגש רב על איסוף וניתוח של כל הדרישות כולן קודם לתחילת הפיתוח, וממליצה שתהליך הפיתוח לא יחזור לאחור לאחר ששלב מסוים בו הסתיים. השלבים העיקריים בשיטה זו הם איסוף וניתוח דרישות, עיצוב, מימוש, בדיקות, שילוב, התקנה ותחזוקה.
המתודולוגיה שייכת למשפחת המתודולוגיות הקוויות.
תוכן עניינים |
[עריכה] היסטוריה
המתודולוגיה הוצעה לראשונה על־ידי וינסטון רויס במאמר שפורסם בכתב העת Proceedings of IEEE בשנת 1970. בהקשרה ההיסטורי, המתודולוגיה נתפסה כתגובה לשיטות אד הוק של 'תכנת-ותקן' שרווחו מאוד בשנות ה־60 של המאה ה־20 (ועדיין רווחות). במאמר, רויס ממליץ לפתח מערכות תוכנה בשני מחזורי פיתוח ("Do it twice"), וטוען שבפרויקטים בהם מידת החדשנות גדולה, יש להתייחס למחזור הפיתוח הראשון של המערכת כפיילוט שצריך לזרוק אותו ('Throw-away')[1]. למרבה האירוניה, בעוד שהוגה השיטה צידד בגישה איטרטיבית לפיתוח תוכנה, הפרשנות המודרנית לשיטתו הפוכה לחלוטין והיא מקור עיקרי לבעיות בפרויקטים לפיתוח תוכנה.
מתודולוגיית מפל המים השפיעה עמוקות על ענף התוכנה. לרוע המזל, הפרשנות המוטעת היא זו שהשתרשה בתעשיה, ופעמים רבות אף הפכה לתקן ממשלתי מחייב לפיתוח תוכנה (ראה DoD-STD-2167 ונוהל מפתח).
[עריכה] עקרונות וטכניקות
- גישה קווית לפיתוח תוכנה, דהיינו, מחזור פיתוח אחד.
- פורמליזציה נרחבת ומוקדמת של הדרישות והמפרטים. פעמים רבות, עד כדי שליש או מחצית מזמן הפיתוח מוקדש להפקה של מסמכים ותיעוד ולא לכתיבת קוד.
- בפרויקטים גדולים מקובל לחלק את המערכת לתתי-מערכת ורכיבים לפי גבולות פונקציונליים, אך אין כלל דגש על בניית המערכת מקצה-לקצה.
- דגש רב על עיצוב מוקדם של התוכנה, לפני התכנות בפועל, מתוך ניסיון לצפות שינויים עתידיים בדרישות.
[עריכה] בעד ונגד
יש הטוענים שגישת מפל המים מתאימה לפתוח מערכות מידע מורכבות בעלות היקף גדול, התומכות בפעולות מובנות ומוגדרות היטב. למשל מערכת ניהול הזמנות בחברות תעופה. ניהול הפרויקט יכול להתרכז בהשלמת כל משימה באופן עצמאי בכל שלב ושלב, ולוחות זמנים יכולים להיקבע ולהישמר. הרעיון המרכזי הוא שפיתוח של מערכת מידע ותפעולה חייבים לעבור דרך תהליך שיטתי ולוגי, המורכב משלבים מוגדרים שאין לפסוח עליהם ושאת ביצועם אין לשנות.
אחד החסרונות הבולטים בשיטה זו הוא התארכות התהליך, בשל הדגש על שלב הניתוח והעיצוב דבר שמגדיל גם את עלות הפרויקט. חיסרון נוסף הוא היווצרות נתק בין המפתחים למשתמשים, היות ושלב הפיתוח הוא ארוך חולף זמן רב עד שהמשתמשים מקבלים או רואים את המערכת החדשה ולכן אין להם שום תמריץ לבקר את המפתחים. בעיה נוספת בגישה זו קשורה לשיתוף פעולה בין המשתמשים למפתחים בשלבים הראשונים: לא תמיד ניתן להגדיר מערכת ולנתחה בשיטה מובנית היות והמשתמש לא תמיד יודע להגדיר את צרכיו. ולכן במערכות מידע הנועדות לשימוש הדרג הניהולי שבהן הטכניקות אינן מובנות נדרשת גישת פיתוח שונה, שלא תתבסס (לפחות לא בהתחלה) על ניתוח מובנה אלא על התנסות משותפת של המפתח והמשתמש.
[עריכה] ראו גם
[עריכה] הערות שוליים
- ^ Agile & Iterative Development / Craig Larman, עמודים 102-106.
