משבר התוכנה

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

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

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

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

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

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

ראשיתו של המשבר התוכנה בסוף שנות ה-60, אז הדביקו לראשונה מחירי התוכנה את מחירי החומרה הנדרשת להרצתה. כתוצאה מכך, עלתה חשיבותה של התוכנה וכן חשיבותן של דרכים שיטתיות לפיתוח תוכנה איכותית. בארבעים השנים האחרונות הוכפל כוח החישוב מדי שנתיים בממוצע (ראו גם חוק מור) והיקף המערכות שניתן לפתח גדל גם הוא בהתאם. לעומת זאת, לא חל גידול דומה ביכולת השיטתית לפיתוח תוכנה, ומידת ההצלחה בפרויקטים לפיתוח תוכנה גדלה רק באחוזים בודדים, והיא עומדת, נכון לתחילת המאה ה-21 על כ-34%. משנות ה-80 ואילך, ברוב התחומים בהם עוסקת הנדסת תוכנה, הגורם העיקרי המגביל את פיתוח התוכנה הוא האנושי, ולא מהירות או ביצועי המחשבים. נכון לתחילת המאה ה-21, נתגלה שככל שהיקף הפרויקט גדול יותר, כך קטנים סיכויי הצלחתו.

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

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

משבר התוכנה בפתח המאה העשרים ואחת[עריכת קוד מקור | עריכה]

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

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

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

בענף הנדסת התוכנה מקובל כיום שאין בנמצא "תרופת פלא"‏[2] למצבו של התחום, והשינוי יבוא על ידי שיפורים קטנים ומתמשכים (קָ‏איזֶ‏ן) בכל תחומי הנדסת התוכנה.

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

לקריאה נוספת[עריכת קוד מקור | עריכה]

  • פרד ברוקס, "ללא מטה קסם: מהות ומקריות בהנדסת תוכנה" (גרסה עברית של No Silver Bullet), מעשה חושב, אוגוסט 1987.
  • דוד הראל, "בליעת מטה הקסם: לקראת עתיד ורוד בפיתוח מערכות", מעשה חושב, נובמבר 1992.

קישורים חיצוניים[עריכת קוד מקור | עריכה]

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

  1. ^ What Are Your Requirements / Standish Group, 2000
  2. ^ Brooks, Fred (1987) No Silver Bullet