משבר התוכנה
הנדסת תוכנה |
---|
ערך זה שייך לקטגוריית הנדסת תוכנה |
פעילויות ושלבים |
דרישות • ניתוח • אפיון • ארכיטקטורה • עיצוב • תכנות • ניפוי שגיאות • בדיקה • אימות • בנייה • פריסה • תפעול • תחזוקה |
מתודולוגיות |
זריזות • מפל המים • תכנת ותקן • Crystal Clear • Scrum • Unified Process • Extreme Programming • אינטגרציה רציפה • DevOps |
תחומים תומכים |
ניהול פרויקטים • ניהול תצורה • תיעוד • הבטחת איכות • Profiling |
כלים |
מהדר • מקשר • מפרש • IDE • ניהול גרסאות • אוטומציית בנייה |
משבר התוכנה הוא מונח שנטבע כאשר הנדסת התוכנה הייתה תחום חדש שעדיין לא התבסס. משבר התוכנה מתייחס לפער שבין היכולת לפתח תוכנה איכותית באופן שיטתי לבין הגידול המהיר בכוח החישוב.
ראשיתו של המשבר התוכנה בסוף שנות ה-60, אז הדביקו לראשונה מחירי התוכנה את מחירי החומרה הנדרשת להרצתה. כתוצאה מכך עלתה חשיבותה של התוכנה וכן חשיבותן של דרכים שיטתיות לפיתוח תוכנה איכותית. בארבעים השנים האחרונות של המאה העשרים הוכפל כוח החישוב מדי שנתיים בממוצע (ראו גם חוק מור) והיקף המערכות שניתן לפתח גדל גם הוא בהתאם. לעומת זאת, לא חל גידול דומה ביכולת השיטתית לפיתוח תוכנה, ומידת ההצלחה בפרויקטים לפיתוח תוכנה גדלה רק באחוזים בודדים, והיא עומדת, נכון לתחילת המאה ה-21 על כ-34%. משנות ה-80 ואילך, ברוב התחומים בהם עוסקת הנדסת תוכנה, הגורם העיקרי המגביל את פיתוח התוכנה הוא האנושי, ולא מהירות או ביצועי המחשבים. נכון לתחילת המאה ה-21, נתגלה שככל שהיקף הפרויקט גדול יותר, כך קטנים סיכויי הצלחתו.
משבר התוכנה לאורך השנים
לאורך השנים הוצעו דרכים רבות להתמודדות עם משבר התוכנה. רשימה חלקית של הפתרונות שנוסו: כלים, שפות תכנות, שפות מידול, פרדיגמות תכנות חדשות, שיטות פורמליות, ניהול שינוי, ניהול פרויקטים, ארכיטקטורה, מתודולוגיות, בדיקות ועוד. חלק מהדרכים שנוסו הועילו, והפכו לטכניקות מקובלות בענף (כמו ארכיטקטורה, תכנות מובנה ותכנות מונחה עצמים), אחרות נמצאות בשימוש אך במידה קטנה והולכת (כמו מתודולוגיית מפל-המים), ורבות אחרות לא שרדו את מבחן הזמן ונעלמו, ובמקומן הוצעו דרכים אחרות.
משבר התוכנה בפתח המאה העשרים ואחת
נכון לתחילת המאה העשרים ואחת, מצבו של תחום הנדסת התוכנה טוב יותר ממצבו בסוף שנות ה-60, אך הוא עדיין רחוק מרחק רב ממצבן המבוסס של דיסצפלינות ההנדסה האחרות. פרויקטים מוצלחים לפיתוח תוכנה, דהיינו, שסיפקו תוכנה המשמשת את המזמין ולא חרגו מלוחות התקציב והזמנים הם עדיין נדירים ומהווים כשליש מסך כל הפרויקטים לפיתוח תוכנה בעולם[1].
חברת הייעוץ סטנדיש גרופ סוקרת את תחום הנדסת התוכנה באופן שוטף ומפרסמת מעת לעת סטטיסטיקות שונות באשר למצבו. להלן עיקרי הדוח לשנת 2003:
- רק 34% מהפרויקטים לפיתוח תוכנה מסתיימים בהצלחה ובזמן.
- 15% מהפרויקטים לפיתוח תוכנה נכשלים כמעט מיד עם תחילת הפיתוח.
- 51% מהפרויקטים נקלעים לבעיות ומסתיימים בחריגה משמעותית מתקציב הפיתוח, חריגה מלוחות הזמנים, ואיכות תוצר ירודה.
- בפרויקטים הנמסרים לאחר חריגה מהתקציב, עלות החריגה הממוצעת היא כ-43%.
- רוב הפרויקטים הנמסרים מחייבים שינויים משמעותיים לאחר המסירה.
- בפרויקטים המסתיימים בהצלחה, רק 52% מתכונות המוצר שנדרשו במקור מיושמות. מתוכן, רק במחצית התכונות נעשה שימוש בפועל.
בענף הנדסת התוכנה מקובל כיום שאין בנמצא "תרופת פלא"[2] למצבו של התחום, והשינוי יבוא על ידי שיפורים קטנים ומתמשכים (קָאיזֶן) בכל תחומי הנדסת התוכנה.
ראו גם
לקריאה נוספת
- פרד ברוקס, "ללא מטה קסם: מהות ומקריות בהנדסת תוכנה" (גרסה עברית של No Silver Bullet), מעשה חושב, אוגוסט 1987.
- דוד הראל, "בליעת מטה הקסם: לקראת עתיד ורוד בפיתוח מערכות", מעשה חושב, נובמבר 1992.
קישורים חיצוניים
- רן לוי, באגים, מזוודות וסוכני FBI- על משבר התכנה, באתר "עושים היסטוריה", 9 ביולי 2009 (שידור של הפודקאסט וטקסט מלא שלו)
הערות שוליים
- ^ What Are Your Requirements / Standish Group, 2000
- ^ Brooks, Fred (1987) No Silver Bullet
24361260משבר התוכנה