למה אנחנו צריכים הנדסת תוכנה?

admin

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

בימים הראשונים של החישובים הבעיה העיקרית היתה בנייה או רכישת ציוד. החוק כמעט אכפת תוכנה. הקונצנזוס קבע כי "חומרה" היא "קשה" לשנות, ו "תוכנה" הוא "רך" או קל לשנות. לפיכך, רוב האנשים בענף מתוכנן בקפידה את הפיתוח של הציוד, אבל הרבה פחות חשבתי על התוכנה. אם התוכנה לא עובדת, הם האמינו שזה יהיה קל לשנות את זה עד שזה עבד. אז למה אתם מנסים לתכנן?

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

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

מאמץ אישי פינה את מקומו לעבודה בצוות. תקשורת ותיאום, שהתקיימה פעם בראשו של אדם אחד, היתה צריכה להופיע בין ראשי אנשים רבים, מה שהופך את התהליך כולו למסובך הרבה יותר. כתוצאה מכך, התקשורת, הניהול, התכנון והתיעוד הפכו להיות מכריעים.

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

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

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

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

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

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

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

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

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

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

יתר על כן, חשוב כי שפה זו היא פשוטה, כך ניתן ללמוד במהירות.

Leave a Reply