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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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



Source by Edeh Chijioke

You may also like...

כתיבת תגובה

האימייל לא יוצג באתר.