משבר התוכנה
מתוך ויקיפדיה, האנציקלופדיה החופשית
| הנדסת תוכנה |
|---|
| מאמר זה הוא חלק מקטגוריית הנדסת תוכנה |
| פעילויות ושלבים |
| דרישות | ניתוח | ארכיטקטורה | עיצוב | תכנות | בדיקה | אימות | בניה | הצבה | תחזוקה |
| מתודולוגיות |
| מפל המים | תכנת ותקן |
| תחומים תומכים |
| ניהול פרויקטים | ניהול תצורה | תיעוד |
משבר התוכנה הוא מונח שנטבע כאשר הנדסת התוכנה הייתה תחום חדש שעדיין לא התבסס. משבר התוכנה מתייחס לפער שבין היכולת לפתח תוכנה איכותית באופן שיטתי לבין הגידול המהיר בכוח החישוב.
ראשיתו של המשבר התוכנה בסוף שנות ה-60, אז הדביקו לראשונה מחירי התוכנה את מחירי החומרה הנדרשת להרצתה. כפועל יוצא, עלתה חשיבותה של התוכנה וכן חשיבותם של דרכים שיטתיות לפיתוח תוכנה איכותית. בארבעים השנים האחרונות הוכפל כוח החישוב מידי שנתיים בממוצע (ראה גם חוק מור) והיקף המערכות שניתן לפתח גדל גם הוא בהתאם. לעומת זאת, לא חל גידול דומה ביכולת השיטתית לפיתוח תוכנה, ומידת ההצלחה בפרויקטים לפיתוח תוכנה גדלה רק באחוזים בודדים. זאת ועוד, במחקרים שנעשו בשנים האחרונות נתגלה שככל שהיקף הפרויקט גדול יותר, כך קטנים סיכויי הצלחתו[1].
[עריכה] משבר התוכנה לאורך השנים
לאורך השנים הוצעו דרכים רבות להתמודדות עם משבר התוכנה. רשימה חלקית של הפתרונות שנוסו: כלים, שפות תכנות, שפות מידול, פרדיגמות תכנות חדשות, שיטות פורמליות, ניהול שינוי, ניהול פרויקטים, ארכיטקטורה, מתודולוגיות, בדיקות ועוד. חלק מהדרכים שנוסו הועילו, והפכו לטכניקות מקובלות בענף (כמו ארכיטקטורה, תכנות מבני ותכנות מונחה עצמים), אחרות נמצאות בשימוש אך במידה קטנה והולכת (כמו מתודולוגיית מפל-המים), ורבות אחרות לא שרדו את מבחן הזמן ונעלמו, ובמקומן הוצעו דרכים אחרות.
[עריכה] משבר התוכנה כיום
מצבו הנוכחי של תחום הנדסת התוכנה טוב יותר ממצבו בסוף שנות ה-60, אך הוא עדיין רחוק מרחק רב ממצבן המבוסס של דיסצפלינות ההנדסה האחרות. פרויקטים מוצלחים לפיתוח תוכנה, דהיינו, שסיפקו תוכנה המשמשת את המזמין ולא חרגו מלוחות התקציב והזמנים הם עדיין נדירים ומהווים כשליש מסך כל הפרויקטים לפיתוח תוכנה בעולם[2].
חברת הייעוץ סטנדיש גרופ סוקרת את תחום הנדסת התוכנה באופן שוטף ומפרסמת מעת לעת סטטיסטיקות שונות באשר למצבו. להלן עיקרי הדוח לשנת 2003:
- רק 34% מהפרויקטים לפיתוח תוכנה מסתיימים בהצלחה ובזמן.
- 15% מהפרויקטים לפיתוח תוכנה נכשלים כמעט מיד עם תחילת הפיתוח.
- 51% מהפרויקטים נקלעים לבעיות ומסתיימים בחריגה משמעותית מתקציב הפיתוח, חריגה מלוחות הזמנים, ואיכות תוצר ירודה.
- בפרויקטים הנמסרים לאחר חריגה מהתקציב, עלות החריגה הממוצעת היא כ- 43%.
- רוב הפרויקטים הנמסרים מחייבים שינויים משמעותיים לאחר המסירה.
- בפרויקטים המסתיימים בהצלחה, רק 52% מתכונות המוצר שנדרשו במקור מיושמות. מתוכן, רק במחצית התכונות נעשה שימוש בפועל.
בענף הנדסת התוכנה מקובל כיום שאין בנמצא "תרופת פלא"[3] למצבו של התחום, והשינוי יבוא על ידי שיפורים קטנים ומתמשכים (קָאיזֶן) בכל תחומי הנדסת התוכנה.
[עריכה] ראו גם
[עריכה] סימוכין והערות שוליים
- ^ CHAOS: A Recipe for Success / Jim Johnson et al., Standish Group, 1998
- ^ What Are Your Requirements / Standish Group, 2000
- ^ No Silver Bullet / Fred Brooks

