הנדסת תוכנה

ארכיטקטורה

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

ממשקים

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

אמינות

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

על בעיית האמינות של התוכנה עמד דייוויד פרנס:
אנשים המכירים הן את הנדסת התוכנה והן את תחומי ההנדסה הוותיקים יותר הבחינו שאמינות סביבת התוכנה נמוכה במידה משמעותית מזו המאפיינת שטחי הנדסה אחרים. כשמרבית המוצרים ההנדסיים הושלמו, נבדקו ונמכרו, סביר לצפות שתכנון המוצר הוא נכון ושהוא יעבוד בצורה אמינה. במוצרי תוכנה, מקובל לגלות שהתוכנה מכילה שיבושים (bugs) רציניים ואינה מתפקדת בצורה אמינה אצל מספר משתמשים. בעיות אלו עלולות לצוץ במספר גרסאות ובמקרים מסוימים להחמיר את המצב כשמדובר ב"שיפור" התוכנה. בעוד מרבית המוצרים מלווים בתעודת אחריות תקפה ומגינה, הרי מוצרי תוכנה מלווים לעיתים בהצהרה ספציפית על אי מתן אחריות. הציבור הרחב, המודע רק למספר קטן של תקלות תוכנה, יכול להתייחס אליהן כחריגים שנגרמו על ידי מתכנתים בלתי-מנוסים. אלו מבינינו המצויים בתוכנה יודעים טוב יותר; המתכנתים המעולים ביותר בעולם לא יכולים להימנע מבעיות כאלו.
— "היבטי תוכנה במערכות הגנה אסטרטגית", מעשה חושב, אפריל 1986; תרגום לעברית של Software Aspects of Strategic Defense Systems

בדיקות לא-פונקציונליות

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

בדיקוּת

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

כיסוי

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

מיכון

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

ניהול תצורה

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

ניהול תצורת קוד המקור

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