הנדסת תוכנה
מתוך ויקיפדיה, האנציקלופדיה החופשית
הנדסת תוכנה (באנגלית: Software Engineering) היא יישום של גישה שיטתית, מבוקרת ומדידה לפיתוח, תפעול ותחזוקה של תוכנה[1]. הנדסת תוכנה עוסקת בכל ההיבטים המעשיים של פיתוח התוכנה, וכוללת ידע, שיטות וכלים להגדרת דרישות תוכנה, תכנון תוכנה, עיצוב ותכנות תוכנה, בדיקות תוכנה ותחזוקת תוכנה[2]. כדסיצפלינה הנדסית, ייעודה העיקרי של הנדסת התוכנה הוא לפשט את הפיתוח, לבססו על יסודות שיטתיים ולשפר את איכות התוצרים. כבכל תחומי ההנדסה, גם בהנדסת התוכנה יש מדדים המשמשים לבחינת איכותם של תוצרי הפיתוח, כגון יעילות, אמינות, גמישות לשינויים וכדומה.
הנדסת תוכנה מתבססת על מדעי המחשב ושורשיה נטועים בתחום זה. בתחילת דרכה, הנדסת תוכנה נחשבה כענף משני של מדעי המחשב, אך מאז שנות ה-80 המאוחרות היא נחשבת לתחום עצמאי[3], והשניים משלימים זה את זה. נוסף על מדעי המחשב, הנדסת תוכנה נסמכת על ידע, שיטות וכלים מתחומים רבים ומגוונים ובכלל זה הנדסת מערכות, הנדסת מחשבים, הנדסת אנוש, ניהול פרויקטים, הבטחת איכות, מתמטיקה ועוד[2].
המונח "הנדסת תוכנה" נטבע בשנת 1968 על ידי פרידריך באוור במהלך כנס נאט"ו להנדסת תוכנה[4].
חלוצים בתחום כוללים את פרד ברוּקס, בארי בם, טוני הור ודייוויד פרנס.
מאפיין בולט של הנדסת תוכנה הוא פיתוח מערכות מורכבות, הכוללות לרוב חומרה, תוכנה ותקשורת. דוגמאות שכיחות הן יישומים עסקיים מורכבים, מערכות שליטה ובקרה, מערכות תקשורת, מערכות הפעלה, מערכות זמן־אמת, מערכות משובצות־מחשב ותווכה.
תוכן עניינים |
[עריכה] הגדרה של הנדסת תוכנה
[עריכה] המונח "הנדסת תוכנה"
נכון לתחילת המאה העשרים ואחת, המונח הנדסת תוכנה מפורש במספר דרכים שונות ונבדלות:
- כינוי בן־זמננו למגוון הפעילויות שבעבר נודעו כתכנות וניתוח מערכות[5].
- מונח רחב המתאר את כל ההיבטים המעשיים של תכנות מחשבים. זאת, בניגוד לתאוריה של תכנות מחשבים הידועה גם כמדעי המחשב.
- מונח המגלם גישה מסוימת לתכנות מחשבים, דהיינו, התייחסות לתכנות מחשבים כמקצוע הנדסי ולא כאומנות או אמנות.
- לפי תקן IEEE 610.12, הנדסת תוכנה היא "(1) יישום של גישה שיטתית, מבוקרת ומדידה לפיתוח, תפעול ותחזוקה של תוכנה, כלומר, החלה של הנדסה על תוכנה; (2) לימוד הגישות השונות ל־(1)"[1].
[עריכה] הנדסה, מדע או אמנות?
קיימת מחלוקת ארוכת שנים בשאלת סיווגו של מקצוע הנדסת התוכנה כענף של ההנדסה, המדע או האמנות. במידה רבה, המחלוקת נובעת מגילו הצעיר של המקצוע ומחוסר הגיבוש של השיטות המשמשות בו.
- יש המסווגים את פיתוח התוכנה כענף מובהק של ההנדסה[3]. המצדדים בגישה זו מצביעים על השיטות המשותפות לדיסציפלינות אלה, כגון איסוף וניהול דרישות, תכנון ומבדקים. מאידך, המצדדים בגישה זו נוטים להמעיט בחשיבות העדר המרכיב הייצורי והפיסי של הנדסה, שאינו קיים כלל בהנדסת תוכנה. אחרים טוענים שייתכן והנדסת תוכנה אינה דיסצפלינה הנדסית, אך עליה להיות כזו[6].
- לרוב, הגישה הנאיבית להנדסת תוכנה מבלבלת בין התוצר ההנדסי לפיתוחו, ומבקשת לייחס את איכות התוצר ההנדסי לתהליכי הפיתוח של התוכנה. דהיינו, כשם שהתוצר ההנדסי (לדוגמה מטוס) עומד בקריטריונים מחמירים של יעילות, עמידות ודיוק, כך גם תהליכי פיתוח התוכנה עצמם חייבים לעמוד בקריטריונים דומים. גישה זו מיושמת גם במתודולוגיית פיתוח התוכנה הידועה כמודל מפל־המים (ראו בהמשך) המורה על פיתוח תוכנה בתהליך קווי, חד־כיווני הדומה לפס־ייצור של מוצר הנדסי.
- יש המסווגים את פיתוח התוכנה כענף מדעי־מתמטי. ואכן, כל מערכות התוכנה מבוססות על יסודות אלגוריתמיים, וחלקן משתמשות בנוסף בענפים שונים של המתמטיקה השימושית. בתהליך פיתוח התוכנה משמשות שיטות מתמטיות מתחום מדעי המחשב, כגון יעילות אלגוריתמים, מודלים של חישוב ושיטות לאימות תוכנה. אף על פי כן, פיתוח התוכנה עצמו אינו תהליך שיטתי־מתמטי, וידע מתמטי עמוק אינו מבטיח כלל ועיקר את איכות התוכנה. אדרבא, השיטות הפורמליות הקיימות משמשות לאימות תוכנה ולא לתכנונה. זאת ועוד, שיטות האימות הקימות אינן מסוגלות להתמודד עם המורכבות וסדרי הגודל של מערכות התוכנה המודרניות, ובנוסף מוגבלות בשל חסמים תאורטיים מובנים (ראו גם בעיית העצירה). יש לזכור כי חלקים מהותיים בתהליך פיתוח התוכנה הם עיצוביים באופיים[7] ומתבססים על איסוף וארגון מידע שאינו פורמלי או מוגדר־היטב[8], ופירוש והמרת אלה לשפת מחשב כלשהי.
- יש המסווגים את פיתוח התוכנה כמקצוע הדורש עבודת אומן[9] או אפילו כאמנות[10]. ואכן, תהליך פיתוח התוכנה חולק איכויות מסוימות עם תהליך היצירה האמנותית, כגון הפשטה, אסתטיקה, דרגות חופש גבוהות ועוד. במקרים רבים, העוסקים בתחום חותרים לפתח פתרונות שיהיו אסתטיים, נוסף על היותם מעשיים. בדומה למקצועות אחרים הדורשים עבודת אומן שיטתית (לדוגמה אדריכלות), גם מקצוע פיתוח התוכנה דורש תקופה ארוכה של חניכות אצל בעל מקצוע ותיק. עם זאת, הגישה האומנותית לבדה אינה מספיקה לפיתוח שיטתי של תוכנה בקנה מידה גדול.
- יש המסווגים את פיתוח התוכנה כתהליך של יצירת קניין רוחני. לפי גישה זו, פיתוח של תוכנה איכותית מחייב תהליך פיתוח שאינו הדיר בהכרח והוא מוכוון־אנשים וכאוטי־מסודר באופיו[11]. המצדדים בגישה זו מדמים את פיתוח התוכנה למשחק של שיתוף פעולה מוכוון־מטרה (בדומה לטיפוס הרים)[12]. גישה זו שמה דגש רב על סביבת עבודה מתאימה, זרימת מידע אוסמוטית בין חברי הצוות, ותקורה פורמלית־טקסית נמוכה. עקרונות אלה מיושמים במתודולוגיות פיתוח תוכנה זריזוֹת כגון XP ו־Crystal (ראו בהמשך). עם זאת, גישה זו לבדה אינה מתאימה לפיתוח מערכות קריטיות, או כאלה המחייבות צוותי פיתוח גדולים.
[עריכה] הנדסת תוכנה לעומת תכנות
קיימת חפיפה מסוימת בין הנדסת תוכנה לתכנות גרידא. שתי הדיסציפלינות עוסקות בצד המעשי של פיתוח תוכנה, אך הנדסת תוכנה עוסקת בפן השיטתי ובמחזור הפיתוח השלם, ואילו תכנות עוסק בקידוד ופיתוח התוכנה. הטבלה הבאה מפרטת את ההבדלים העיקריים בין שתי הדיסציפלינות:
| נושא | הנדסת תוכנה | תכנות |
|---|---|---|
| מיקוד | תכנות הקשור ליישום מסוים | תכנות ולעתים האקינג ללא תלות ביישום מסוים |
| הקשר עסקי | שיתוף פעולה עם מומחים לתחום העסקי | דגש על עבודה אישית |
| גודל הצוות | בודדים ועד לצוותים גדולים ומתואמים | דגש על יחידים |
| בדיקות | שיטתיות, ממוכנות - מבדיקות יחידה, דרך בדיקות שילוב, מערכת ועד מבדקי קבלה | בדיקות מעטות וידניות, לעתים בדיקות יחידה |
| קריטיות המערכת | כל סוגי המערכות, כולל מערכות קריטיות ומערכות תומכות־חיים | מערכות לא קריטיות |
[עריכה] הנדסת תוכנה לעומת מדעי המחשב
היחס בין מדעי המחשב להנדסת תוכנה הוא נושא הנתון במחלוקת מתמשכת. יש המצדדים בגישה הטוענת שהנדסת תוכנה היא ענף משני של מדעי המחשב. לעומתם, יש הטוענים שהמיקוד העיקרי של מדעי המחשב הוא לימוד וגילוי אמיתות כלליות בתחום החישוביות, ואילו הנדסת תוכנה מתמקדת בתכנון ויישום מקרים פרטניים של בעיות חישוביות, להשגת מטרה מעשית. תומך מובהק בגישה זו הוא דייוויד פרנס[3].
בין הנדסת תוכנה למדעי המחשב יש חפיפה רבה בתחומי האלגוריתמיקה והאימות. עם זאת, מדעי המחשב נוטים למחקר תיאורטי בתחומי החישוביות והאלגוריתמיקה, ואילו הנדסת תוכנה נוטה לצד המעשי של תחומים אלה, ושמה דגש על נושאי העיצוב בפתרון הבעיות. להדגשת ההיבט התאורטי של מדעי המחשב, אמר אחד מהבולטים בו, אדסחר דייקסטרה:
| "מדעי המחשב אינם עוסקים במחשב יותר משאסטרונומיה עוסקת בטלסקופ" | ||
הטבלה הבאה מפרטת את ההבדלים בין שתי הדיסציפלינות:
| נושא | הנדסת תוכנה | מדעי המחשב |
|---|---|---|
| אידאל | פיתוח מערכות תוכנה | גילוי אמיתות כלליות אודות חישוביות, אלגוריתמים ונושאים תאורטיים נוספים |
| דגש | פיתוח תוכנה בעלת ערך למשתמש | אמיתות כלליות, כגון סיבוכיות ונכונות של אלגוריתמים |
| מטרה | תוכניות שימושיות כגון מהדר, מערכות מידע, מערכות בקרה, חבילת יישומים משרדיים | אלגוריתמים כגון אלגוריתמים למיון, בעיות מופשטות כגון בעיית הסוכן הנוסע |
| תקציב ולוח זמנים | תקציב ולוחות זמנים קבועים מראש | תקציבי מחקר ותחרותיות כפי שמקובל באקדמיה |
| ידע נוסף | הנדסה, ניהול פרויקטים, הכרת תחום היישום, ידע בתחומים טכנולוגיים נוספים | מתמטיקה |
| חוקרים ידועים | בארי בֶם, גריידי בוץ' | אלן טיורינג, ג'ון פון נוימן, אדסחר דייקסטרה, דונלד קאנות', דוד הראל, עדי שמיר |
| עוסקים ידועים | לינוס טורבאלדס, ריצ'רד סטולמן, מרטין פולר, דן בריקלין | לא רלוונטי |
[עריכה] הנדסת תוכנה לעומת הנדסה מסורתית
מהנדסי תוכנה שואפים לבנות מוצרים זולים, אמינים ובטוחים, בדומה לעוסקים במקצועות ההנדסה המסורתיים. מהנדסי תוכנה שואלים מטפורות וטכניקות רבות מדסציפלינות ההנדסה המסורתית, לרבות איסוף וניתוח דרישות, הבטחת איכות וטכניקות לניהול פרויקטים. מהנדסים מסורתיים שואלים גם הם כלים ופרקטיקות מהנדסת התוכנה. עם זאת, שתי הדסציפלינות נבדלות, כפי שמתואר להלן:
| נושא | הנדסת תוכנה | הנדסה מסורתית |
|---|---|---|
| יסודות | מבוססת על מדעי המחשב ומתמטיקה בדידה | מבוססת על פיזיקה, כימיה וחשבון דיפרנציאלי ואינטגרלי |
| עלות | לרוב, עלויות הפיתוח ההנדסי והייעוץ מגיעות ליותר ממחצית העלות הכוללת. כלי העבודה כגון מהדרים ומחשבים הם זולים | עלויות הבניה והייצור הן גבוהות, ועלות הפיתוח ההנדסי היא קטנה יחסית |
| שכפול | שכפול תוכנה הוא טריוויאלי. רוב מאמץ הפיתוח מושקע בפיתוח ותכנון מערכות חדשות (לא מוכחות) או בהרחבה של מערכות קיימות | רוב מאמץ הפיתוח מושקע בשכפול של תכנונים ידועים ומוכחים על ידי ייצור ובניה |
| אורך חיים | דגש על פתרונות בעלי אורך חיים של שנים בודדות או עשור לכל היותר | דגש על פתרונות בעלי אורך חיים של עשרות שנים ולעתים אף מאות שנים (סכרים וגשרים, לדוגמה) |
| סטאטוס ניהולי | מהנדסי תוכנה אינם מנהלים אנשים אחרים בדרך כלל. לרוב, מהנדסי תוכנה אינם נחשבים כמנהלים | מהנדסים מסורתיים מנהלים צוותי בניה, ייצור ותחזוקה. רוב המהנדסים המסורתיים נחשבים כמנהלים |
[עריכה] תחומים ושיטות ליבה
[עריכה] מתודולוגיה
מתודולוגיה (או תפיסת פיתוח) היא התחום העוסק בחקר וביישום של עקרונות לפיתוח תוכנה באופן שיטתי. המונח מתודולוגיה בהנדסת תוכנה פירושו סט מוסכם של עקרונות, תהליכים, שיטות וכלים על פיהם מפותחות ומתוחזקות מערכות תוכנה.
נכון לתחילת המאה העשרים ואחת, יש בתחום הנדסת התוכנה כתריסר מתודולוגיות עיקריות (קרי, שפורסמו ברבים וזכו לקבלה מסוימת בתעשיה) המחולקות למספר משפחות נבדלות. רוב המתודולוגיות מונות את השיטות העדכניות ביותר, אך אינן מרחיבות אותן באופן משמעותי. מתודולוגיות נבדלות ביחסן למקצוע הנדסת התוכנה ועקרונות היסוד שלו, המיקוד (ניהול פרויקט, ארכיטקטורה, עיצוב ותכנות, הבטחת איכות ועוד), השיטות ובהיבטים נוספים. בשל גילו הצעיר של המקצוע ובשל ריבוי המתודולוגיות, אין עדיין הסכמה בענף באשר למידת התאמתן של מתודולוגיות מסוימות לבעיות מסוימות.
ערך מורחב – מתודולוגיית פיתוח תוכנה
[עריכה] מתודולוגיות קוויות
- תכנת ותקן (ידועה גם בשם מהר ומלוכלך) היא המתודולוגיה המקובלת ביותר לתחזוקת מערכות תוכנה, נכון לסוף המאה העשרים. המתודולוגיה מקובלת במידה מסוימת גם לפיתוח מערכות חדשות. מתודולוגיה זו שמה דגש רב על המהירות שבה נעשים שינויים ותיקונים למערכת התוכנה, תוך התעלמות מודעת מנושאי התחזוקתיות והאיכות הפנימית של התוכנה. מתודולוגיה זו מאפשרת הוספה מהירה של פונקציונליות חדשה למערכת, אך מחייבת חיזוק של המבנים הפנימיים של התוכנה מעת לעת וערכת בדיקות מקיפה. ללא האחרונים, שימוש עקבי במתודולוגיה זו יגרום בהכרח לשחיקה מעריכית באיכות הפנימית של התוכנה, עד לנקודה שבה עלות הוספת פונקציונליות חדשה שווה או גדולה לעלות בניית התוכנה כולה מחדש, שלאחריה אין הצדקה כלכלית להמשיך לתחזק את התוכנה.
- מפל-המים (ידועה גם בשם מודל מפל-המים) היא מתודולוגיה ותיקה ורווחת לפיתוח מערכות תוכנה. המתודולוגיה מיוחסת (בטעות) לוינסטון רויס, שהציע את הגרסה המקורית של המתודולוגיה במאמר שפורסם בשנת 1970. עם השנים נשתרשה פרשנות מוטעית למאמרו, והיא זו הידועה בשם "מודל מפל-המים". בהקשרה ההיסטורי, המתודולוגיה נתפסה כתגובה לשיטות אד הוק של 'תכנת-ותקן' שרווחו מאוד בשנות השישים של המאה ה־20 (ועדיין רווחות). במודל מפל-המים, פיתוח התוכנה מתבצע בתהליך שיטתי ולוגי המורכב משלבים מוגדרים־היטב שאין לפסוח עליהם. השלבים מבוצעים בטור, אחד אחרי השני, ובכל שלב יש מיקוד במשימה עיקרית אחת בלבד. יש דגש רב על איסוף וניתוח של כל הדרישות כולן קודם לתחילת הפיתוח, ואין חזרה לאחור בתהליך לאחר ששלב מסוים בו הסתיים. השלבים העיקריים בשיטה זו הם איסוף וניתוח דרישות, עיצוב, מימוש, בדיקות, שילוב, התקנה ותחזוקה.
- ערך מורחב – מודל מפל-המים
[עריכה] מתודולוגיות איטרטיביות
- Unified Process (או בקיצור UP) היא מתודולוגיה ששורשיה בעבודתו של בארי בם והורחבה על ידי פיליפ קרוצ'טן, גריידי בוץ' ואחרים. המתודולוגיה הוצגה לראשונה בין השנים 1995 - 1998. UP אינה מתודולוגיה במובן הקלאסי, אם כי מסגרת מתודולוגית שניתן להרחיבה ויש להתאימה לארגון או פרויקט מסוים. UP היא מתודולוגיה איטרטיבית המורה על פיתוח תוכנה בתהליך מחזורי רב-שלבי. המתודולוגיה שמה דגש על ניהול הפרויקט, ניהול השינוי, הארכיטקטורה ותהליכי המידול של התוכנה. ייחודה של UP הוא בדרכים המובנות בה המאפשרות להתאימה לסוגים וגדלים רבים של פרויקטים לפיתוח תוכנה, החל מפרויקטים קטנים ולא-קריטיים ועד לפרויקטי-ענק לפיתוח מערכות קריטיות תומכות-חיים. הטכניקות העיקריות של המתודולוגיה כוללות פיתוח מחזורי תחום-בזמן, ניהול השינוי באמצעות כלי ניהול שינויים ובקרת תצורה, ניהול הדרישות ומידול ויזואלי באמצעות UML.
- ערך מורחב – Unified Process
[עריכה] מתודולוגיות זריזות
מתודולוגיה זריזה (באנגלית: Agile) לפיתוח תוכנה היא מתודולוגיה איטרטיבית שהותאמה לפיתוח תוכנה בצוותים קטנים תוך שימת דגש על יעילות, זריזות ואיכות. משפחה זו מקבלת בברכה שינויים במפרטי התוכנה, ומתייחסת לפיתוח כאל משחק של שיתוף פעולה מוכוון-מטרה (בדומה לטיפוס הרים). המתודולוגיות במשפחה זו שמות דגש רב על סביבת עבודה מתאימה, זרימת מידע אוסמוטית בין חברי הצוות, ותקורה פורמלית־טקסית נמוכה. עקרונות היסוד של משפחה זו נקבעו במשותף על־ידי רבים מהמובילים בחקר וביישום מערכות תוכנה, ופורסמו ברבים במנשר לפיתוח תוכנה זריז.
- ערך מורחב – פיתוח תוכנה זריז
- eXtreme Programming (או בקיצור XP) היא מתודולוגיה שפותחה על ידי קנט בק, ומתוארת בספרו eXtreme Programming Explained שיצא לאור בשנת 2000, ובספרים נוספים שצצו בעקבותיו. שמה ניתן לה בשל העבודה שהשיטות המשמשות אותה הן מחמירות מאד, ובעת פרסומה נחשבו כקיצוניות יחסית לשיטות הקיימות בתעשיה. המתודולוגיה, כפי שרומז שמה, מפרטת שורה של טכניקות בתחום התכנות ופחות בתחומים אחרים של הנדסת תוכנה. מערכות המפותחות לפיה הן גמישות מאוד לשינויים, וניתן להרחיבן בקלות ובאופן בטוח. כדי להשיג גמישות זו, XP משתמשת בשיטת תכנות מונחה-בדיקות שעיקריה הם כתיבת דרישות המערכת כסט של בדיקות הניתנות להרצה, ופיתוח הבדיקות קודם לפיתוח הפונקציונליות. שיטה זו דורשת הבנה טובה של עקרונות תכנות מוכוון עצמים ומשמעת עצמית גבוהה.
- ערך מורחב – Extreme Programming
- Crystal Clear היא מתודולוגיה שפותחה על ידי אליסטר קוברן ועקרונותיה מתוארים בספרים שפרסם החל משנת 1998. מתודולוגיה זו שמה דגש על יעילות בפיתוח ומפגינה סגלתנות רבה לשוני בדרכי העבודה האנושיות כפי שאלה מתבטאות בפיתוח תוכנה על ידי מתכנתים. המתודולוגיה מפרטת עקרונות לתכנות נכון אך מתמקדת יותר בעיצוב התוכנה וניהול הפרויקט. המתודולוגיה מתאימה לצוותים קטנים המפתחים תוכנה שאינה תומכת-חיים. ייחודה של Crystal Clear הוא בקלות היחסית שניתן להתאימה לאילוצים המופיעים פעמים רבות בפרויקטים לפיתוח תוכנה (לדוגמה, העדרו של לקוח), ובמסגרת נוחה להרחיבה גם לצוותים גדולים יותר.
- ערך מורחב – Crystal Family
- Scrum היא מתודולוגיה זריזה לניהול פרויקטים לפיתוח תוכנה שפותחה על ידי קן שוואבר ואחרים. המונח "Scrum" מקורו במשחק הרוגבי, שם הוא מתאר את הדרך שבה המשחק מתחיל מחדש לאחר שהכדור יצא מהמגרש. הטכניקה של "התחלה מחדש" היא אחת מאבני היסוד של השיטה - פרויקט Scrum מתחיל את תהליך הפיתוח כל חודש מחדש. כלומר, פעם בחודש מסופקת תוכנה עובדת למשתמשים, והערותיהם, כמו גם הדרישות החדשות, מיושמות במחזורי הפיתוח העוקבים. מקובל להשתמש ב־Scrum כמעטפת לניהול פרויקטים המפותחים במתודולוגיית XP ומתודולוגיות זריזות אחרות.
- ערך מורחב – Scrum
[עריכה] ארכיטקטורה
ארכיטקטורה היא התחום העוסק בתכנון מערכות תוכנה. המונח ארכיטקטורה בהנדסת תוכנה פירושו ייצוג היבטים שונים של התוכנה באופן מופשט. ארכיטקטורה של מערכות תוכנה היא לפיכך תכנון מפושט של ההיבטים השונים של התוכנה, היחסים בין המרכיבים השונים של התוכנה והחוקים החלים עליהם. מחקרים ראשונים בתחום זה נעשו כבר בשנות השישים של המאה ה־20, אבל חשיבותו עלתה מאוד החל משנות ה־80 בשל הגודל והמורכבות של מערכות התוכנה (ראו גם משבר התוכנה). ארכיטקטורה מתמקדת בהגדרת ההיבטים הלא-פונקציונליים של התוכנה, השלד הטכנולוגי, הממשקים החיצוניים והיבטים נוספים שאינם קשורים רק לעיצוב התוכנה ולקוד. תכנון ופיתוח המבנים הפנימיים של התוכנה שייך לתחום העיצוב והתכנות אם כי גם הוא מכונה לעתים ארכיטקטורה. ראוי לציין שאין עדיין הסכמה בתעשיה באשר להיבטים השונים של התוכנה הנדרשים להכלל כחלק מהארכיטקטורה, אם כי יש דרך מתוקננת לתיאור חלק מההיבטים באמצעות שפת המידול המאוחדת UML ובאמצעות SysML.
- ערך מורחב – ארכיטקטורת תוכנה
[עריכה] שלד ומבנה
תחום העוסק בשלד התוכנה ובמבנים בקנה מידה בינוני וגדול, יכולת ההרחבה של המבנה ומידת גמישותו לשינויים.
- גמישות לשינויים - היבט העוסק ביכולת לשנות את התוכנה בתגובה לשינויים בדרישות או בשל דרישות חדשות. מחקרים בתחום[13] מצאו שקשה מאוד לשנות מערכות תוכנה לאחר שאלה נמסרו ללקוח. לשם השוואה, שינוי המתבצע בתוכנה לאחר שנמסרה עולה בממוצע פי 200 משינוי המתבצע בזמן איפיון התוכנה[14]. לפיכך, הגישה המסורתית לפיתוח תוכנה שמה דגש רב על תכנון תוכנה גמישה, כלומר, תכנון מבני התוכנה באופן כללי ומופשט ככל שניתן. תכנון כזה, אם הוא מצליח לחזות את המקומות בהן תורחב התוכנה, מאפשר את שינוי והרחבת התוכנה באופן קל ובטוח. עם זאת, הניסיון בתעשיה מלמד שמידת הצלחתו של הליך תכנוני זה היא מוגבלת, ומתודולוגיות הפיתוח הזריזות אף ממליצות נגד חלקים מהותיים בו[15][16].
- יכולת הרחבה וגידול - מערכות תוכנה נדרשות פעמים רבות להגדיל את תפוקת העבודה שלהן בשל גידול צפוי או בלתי-צפוי, רגעי או קבוע באירועי הקלט (לדוגמה, מספר המשתמשים המחוברים למערכת). לפיכך, דגש רב מושם על תכנון מבנה התוכנה באופן שיאפשר את הגדלת התפוקה שלה בעתיד, עם שינויים קטנים ככל שניתן בהיבטי הארכיטקטורה השונים, במבנה הפנימי או במערכות המחשב עצמן.
[עריכה] ממשקים
תחום העוסק באופן שבו התוכנה מתקשרת עם מערכות חיצוניות אחרות, לרבות אנשים. תכנון הממשקים הוא היבט קריטי של מערכת התוכנה מכיוון שזהו הנתיב שדרכו מגיעים אירועים חיצוניים לתוכנה, וכן הצינור שדרכו תפוקת העבודה של התוכנה זורמת החוצה. טיב ממשקי התוכנה משפיע באופן ישיר על תגובתיות התוכנה, קלות החיבור של התוכנה למערכות אחרות, קלות השימוש והנגישות, אורך החיים של התוכנה והסתגלנות שלה לשינויים עתידיים. החל מסוף המאה העשרים חלה התקדמות רבה בחלק מההיבטים של תחום ארכיטקטוני זה, והוגדרו בתעשיה דרכים מתוקננות לקישוריות ופעילות הידודית בין מערכות (ראו גם Web Services). כמו כן, חל גיבוש בעקרונות ובשיטות המשמשים בתחום הקישוריות ואלה חוסים תחת המטריה של ארכיטקטורה מוכוונת-שירותים (SOA).
[עריכה] אמינות
תחום העוסק במדידה ותכנון מנגנונים להבטחת האמינות של התוכנה, כלומר נכונות הפלט בכל מצבי התוכנה. התחום קשור באופן הדוק לתחומי האימות, הבדיקות ולהיבטי הבדיקוּת של התוכנה. עקרונות התחום והשיטות המתמטיות המשמשות בו מקורם בדיסצפלינות ההנדסה המסורתית. עם זאת, בניגוד לדיסצפלינות קרובות (לדוגמה, הנדסת אלקטרוניקה), במערכות תוכנה (אפילו קטנות) מספר הקומבינציות של הקלטים והמצבים עלול להיות אסטרונומי ולפיכך קיים קושי רב להוכיח באופן מתמטי את נכונות התוכנה ומאפייני האמינות שלה. בפועל, הדגש מושם על איסוף וניתוח דרישות האמינות, תכנון לאמינות ובעיקר מימוש מונחה-אמינות.
באופן מעשי, יישום מערכת תוכנה אמינה מסתמך על מנגנוני חומרה מתאימים (כגון הרצה זהה במקביל), מערכות תווכה מתאימות (כגון מסד נתונים, מערכת ניהול תנועות ועוד), ספריות פיתוח בדוקות, טכניקות קידוד שונות וערכת בדיקות מקיפה. במערכות תוכנה קריטיות או תומכות-חיים, מתווספים גם תהליכי אימות פורמליים לחלקים בתוכנה, לפרוטוקולים המשמשים בה ולאלמנטים נוספים. במקרים נדירים, רכיבים קריטיים בתוכנה אף מפותחים על ידי שני צוותים נפרדים, ואלה פועלים יחדיו בזמן ריצה, תוך השוואה מתמדת של הפלטים (ראו גם טייס אוטומטי).
על בעיית האמינות של התוכנה עמד דייוויד פרנס:
| אנשים המכירים הן את הנדסת התוכנה והן את תחומי ההנדסה הוותיקים יותר הבחינו שאמינות סביבת התוכנה נמוכה במידה משמעותית מזו המאפיינת שטחי הנדסה אחרים. כשמרבית המוצרים ההנדסיים הושלמו, נבדקו ונמכרו, סביר לצפות שתכנון המוצר הינו נכון ושהוא יעבוד בצורה אמינה. במוצרי תוכנה, מקובל לגלות שהתוכנה מכילה שיבושים (bugs) רציניים ואינה מתפקדת בצורה אמינה אצל מספר משתמשים. בעיות אלו עלולות לצוץ במספר גרסאות ובמקרים מסוימים להחמיר את המצב כשמדובר ב"שיפור" התוכנה. בעוד מרבית המוצרים מלווים בתעודת אחריות תקפה ומגינה, הרי מוצרי תוכנה מלווים לעתים בהצהרה ספציפית על אי מתן אחריות. הציבור הרחב, המודע רק למספר קטן של תקלות תוכנה, יכול להתייחס אליהן כחריגים שנגרמו ע"י מתכנתים בלתי-מנוסים. אלו מבינינו המצויים בתוכנה יודעים טוב יותר; המתכנתים המעולים ביותר בעולם לא יכולים להימנע מבעיות כאלו. | ||
| -- "היבטי תוכנה במערכות הגנה איסטרטגית", מעשה חושב, אפריל 1986; תרגום לעברית של Software Aspects of Strategic Defense Systems | ||
[עריכה] זמינות
תחום העוסק בזמינותה של מערכת תוכנה ומכלול השירותים המסופקים על ידה. עקרונות התכנון של היבט זה מקורם בעיקר בדיסצפלינות הנדסה אחרות. זמינות המערכת מושפעת באופן ישיר מהאופן שבו התוכנה מוצבת בסביבת המחשוב, המשאבים העומדים לרשותה ואופן ניהולם. מערכות הנדרשות לעמוד ברמת שירות גבוהה מחייבות תכנון קפדני של זיהוי, ניהול והתאוששות מכשלים במערכת. לרוב, היבטים אלה באים לידי ביטוי בכל רמות התוכנה (והחומרה), מרמת המבנים המערכתיים ועד לרמת הטיפול בשגיאות בקוד.
- זיהוי וניהול כשלים - היבט העוסק בדרכים לזהות אירועים חריגים בתוכנה ובניהולם, אחרי שנתגלו. אירוע חריג בהקשר זה הוא שגיאה תכנותית שלא נצפתה מראש (באג), כשל במערכות עזר או כשל במערכות המחשב עצמן. עקרונות הנדסיים של יתירות ובידוד כשלים הם חלק מעקרונות היסוד המשמשים לתכנון היבט זה.
- התאוששות מאסון - היבט העוסק בשחזור פעילות התוכנה לאחר שהתרחש אירוע כלשהו שמונע ממערכות המחשב והתוכנה לתפקד. בדרך כלל מדובר על אירוע חיצוני שאינו באחריות המערכת, כגון נתק מתמשך במערכות החשמל, שריפה, הצפה וכדומה.
- המשכיות עסקית - היבט העוסק בניתוח והגדרה של תהליכים עסקיים ומחשוביים הדרושים כדי להמשיך ולהפעיל את מערכות המחשוב של הארגון לאחר שהתרחש אירוע כלשהו.
[עריכה] ביצועים
תחום העוסק בתפוקת העבודה המועילה של התוכנה, מדידתה ובדרכים להגדיל תפוקה זו בעתיד. היבט זה בא לידי ביטוי בכל רמות התוכנה, האלגוריתמים, המבנה הפנימי ואיכות הקוד.
- תכנון קיבולת - היבט העוסק בבניית מודל לחישוב כמות משאבי החומרה הנדרשים כדי לתמוך בעומס הצפוי על התוכנה. במערכות תוכנה חדשות, קשה לבנות מודל מדויק קודם להפעלת התוכנה ויש להשתמש בגישה איטרטיבית המטייבת את המודל תוך כדי הפיתוח. בהתאם לתוצאות המודל, נרכשות מערכות המחשוב הנדרשות. במקרים מסוימים, המודל אף משמש להקצאה דינמית של משאבי החומרה בסביבת הייצור. לעומת זאת, תוכנות מדף ותיקות מספקות כמעט תמיד כלים מדויקים לתכנון קיבולת המערכת.
- הסכמי שירות - היבט העוסק במדידת התפוקה המועילה של התוכנה והשוואתה לערכים צפויים כלשהם, בדרך כלל כדי להבטיח את תגובתיות התוכנה עבור צרכן או צרכנים מסוימים.
[עריכה] אבטחת מידע
פרק זה לוקה בחסר. אתם מוזמנים לתרום לוויקיפדיה ולהשלים אותו. ראו פירוט בדף השיחה.
תחום העוסק בהגנה על התוכנה מסיכונים שונים על ידי יישום עקרונות אבטחת מידע במערכות מחשב. תחום זה הוא נגזרת של תחום אבטחת המידע והוא עוסק בתכנון תת-המערכות הנדרשות ליישום ההיבטים העיקריים של אבטחת המידע. במערכות בהן אבטחת המידע היא קריטית לפעולת המערכת נעשה שימוש גם בשיטות אימות תוכנה פורמליות כדי להגביר את מידת האמינות של התכנון.
- הזדהות והעברת הזהות - היבט העוסק בתכנון תהליך ההזדהות למערכת, אימות הזיהוי ובדרכים להעברת זהות זו בין חלקי המערכת ולמערכות אחרות.
- בקרת גישה - היבט העוסק בתכנון הדרכים בהן הרשאות השימוש במערכת יאוחסנו ויאכפו.
- יומנים וביקורת - היבט העוסק בתכנון מערכת רישום יומן האירועים של המערכת והעברה מאובטחת של מידע זה למערכות ייעודיות. היבט זה קשור להיבטי התפעול של המערכת ובפרט להיבטי הניטור והבקרה.
- ערך מורחב – אבטחת מידע
[עריכה] תפעול
- תצורה - תצורה בהנדסת תוכנה היא מכלול הדרכים להתקנת התוכנה, התקנת תיקונים, ותחזוקה שוטפת לאורך מחזור החיים השלם של התוכנה. תכנון התצורה כולל התיחסות להפצת התוכנה למערכת או מערכות היעד, אתחול המערכת, דריכה ראשונית של פרמטרים, גיבוי ושיחזור התצורה ובקשר של ניהול התצורה להיבטי הניטור והבקרה של התוכנה.
- ניטור ובקרה - היבט העוסק בניהול התוכנה אחרי שהיא מופעלת. כדי לאפשר את השליטה והבקרה על התוכנה, יש לתכנן כיצד התוכנה תספק מידע על מצבה למפעילים אנושיים או למערכות אחרות ואת הדרך שבה תקבל התוכנה הוראות תפעוליות מגורמים אלה. תכנון היבט זה נוגע בעיקר לממשקים החיצוניים של התוכנה ולרוב אינו משפיע על המבנה הפנימי של התוכנה. ניהול יעיל של תוכנה מתייחס לתחומים רבים כגון: ביצועים, תצורה, טיפול בתקלות, שחזור תקלות, תפעול ועוד. טיב היבט זה משפיע באופן ישיר על רמת השירות שהתוכנה מספקת.
- ערך מורחב – ניטור ובקרת תוכנה
- גיבוי ושחזור - היבט העוסק בגיבוי ושחזור המידע שבאחריות התוכנה. מערכות תוכנה רבות מנהלות נפחים גדולים של מידע במסדי נתונים יחסיים. היבט זה עוסק בעיקר בתכנון הדרכים לגיבוי המידע, אירכובו ושיחזורו במקרה הצורך, לדוגמה אחרי ששגיאה בתוכנה גרמה להשחתת מידע.
- ערך מורחב – גיבוי ושחזור תוכנה
- חשבונאות - היבט העוסק בהגדרת מודלים לחיוב המשתמשים בגין פעילותם בתוכנה, מדידת הפעילות העסקית של התוכנה, ובסופו של דבר, חיוב המשתמשים על השימוש בתוכנה. במערכות תוכנה העושות שימוש במשאבי חומרה משותפים, יישום היבט זה מחייב תמיכה מתאימה במערכת ההפעלה, התווכה ובמערכת הניטור והבקרה.
- ערך מורחב – חשבונואות מערכות מידע
[עריכה] אלגוריתמיקה
אלגוריתמיקה היא התחום המגשר בין המודל המתמטי של בעיה נתונה לבין פתרונה באמצעות מחשב. אלגוריתמיקה היא תחום יסודי במדעי המחשב ובהנדסת תוכנה, והיא עוסקת במציאת פתרונות לבעיות חישוביות באמצעות אלגוריתמים ומבני נתונים. אלגוריתמיקה מתמקדת בפיתוח מודל מתמטי המתאר, בדרגות שונות של דיוק, את הבעיה שהתוכנה המפותחת אמורה לפתור. בהנדסת תוכנה, אלגוריתמים מתוארים לרוב באמצעות פסבדו-קוד, שהוא ייצוג מופשט של שפת תכנות, ונסמכים על מודל חישובי כלשהו, בדרך כלל זה המייצג מכונת טורינג קלאסית. השימוש באלגוריתמים ומבני נתונים יסודיים אינו נחשב חלק מתחום האלגוריתמיקה, אלא מהווה חלק בלתי נפרד מעבודתו של המתכנת.
- ערך מורחב – אלגוריתמיקה
[עריכה] אלגוריתמים ומבני נתונים יסודיים
תחום העוסק ביישום של אלגוריתמים ומבני נתונים יסודיים בספריות פיתוח וכחלק משפת תכנות מסוימת. עם התקדמות המחקר והפיתוח בתחום האלגוריתמיקה, נצברו מספר רב של תוצאות שימושיות, דהיינו, אלגוריתמים ומבני נתונים נפוצים החוזרים ומופיעים כמעט בכל תוכנה (ראו גם רשימת אלגוריתמים). תחום זה עוסק בארגון ואיסוף תוצאות אלה, תכנון ממשקי תכנות מופשטים ופשוטים המאפשרים התייחסות אחידה לסוגים קרובים של אלגוריתמים ומבני נתונים, ומימוש ממוטב ככל האפשר של האלגוריתמים. ספריות פיתוח טובות מספקות מבחר גדול ומתועד של אלגוריתמים ומימושים הממוטבים לצרכים שונים (זמן-ריצה, זיכרון וכדומה). התחומים שלהלן מכוסים במידה כלשהי על ידי ספריות פיתוח המובנות ברוב שפות התכנות המודרניות:
- מבני נתונים - לצרכים שונים, כגון תור, מחסנית, רשימה מקושרת, עץ, טבלת גיבוב וערימה.
- מיון וחיפוש - אלגוריתמים למיון וחיפוש בנתונים ומחרוזות כגון מיון מהיר וחיפוש בינארי.
- בקרת ריצה מקבילית - מבני נתונים לבקרה על פעילויות מקביליות כגון סמפור, מנעול קריאה/כתיבה ותור הפצה.
- גרפים - אלגוריתמים לטיפול בהיבטים שונים של תורת הגרפים כגון מציאת נתיבים, פרישׂת עצים וזרימה מקסימלית.
- דחיסה - אלגוריתמים לדחיסה ופרישה של נתונים.
- הצפנה - אלגוריתמים להצפנה של נתונים, חתימה דיגיטלית וכדומה. נוסף על כך, מבני נתונים ואלגוריתמים יעילים לטיפול בפעולות אריתמטיות על מספרים גדולים מאד.
[עריכה] פיתוח אלגוריתמים
פרק זה לוקה בחסר. אתם מוזמנים לתרום לוויקיפדיה ולהשלים אותו. ראו פירוט בדף השיחה.
[עריכה] ניתוח אלגוריתמים
תחום העוסק בניתוח היעילות של אלגוריתמים, כלומר, קביעת כמות המשאבים הנדרשת להרצת אלגוריתם נתון. לרוב, יעילותו של אלגוריתם מנוסחת כפונקציה המקשרת בין אורך הקלט לבין מספר הצעדים (סיבוכיות זמן) או שטחי האחסון (סיבוכיות מרחב או זיכרון) הנדרשים להרצתו.
- שיערוך של אלגוריתם הוא שיטה העוסקת בהערכת סדר-הגודל של יעילות האלגוריתם (הערכה אסימפטוטית). כלומר, הערכת היעילות כאשר אורך הקלט הוא גדול במידה סבירה. הכלים המתמטיים שפותחו בתחום זה מאפשרים להעריך את יעילותו התיאורטית של אלגוריתם במנותק ממימוש מסוים, ומקלים על בחירתו של אלגוריתם מתאים לבעיה חישובית נתונה. מאידך, הערכת סדר גודל היא מדויקת רק עד כדי קבועים מפורשים או חבויים הקשורים למימוש מסוים, ולעתים אינה מספיקה כדי לבחור בין אלגוריתמים.
- ניתוח מדויק של אלגוריתם מחייב הנחה בדבר המודל החישובי המסוים המשמש למימוש האלגוריתם. ניתן להגדיר מודל חישובי באופן מופשט, לדוגמה מכונת טיורינג, או על ידי הנחות בדבר משך הזמן הדרוש להרצת פעולות מסוימות. לתכנות ממוטב של אלגוריתם נדרש תמיד ניתוח מדויק. במערכות זמן-אמת לדוגמה, שיערוך אסימפטוטי הוא גס מכדי לבחור אלגוריתם ליישום ממוטב של מתזמן.
[עריכה] עיצוב ותכנות
פרק זה לוקה בחסר. אתם מוזמנים לתרום לוויקיפדיה ולהשלים אותו. ראו פירוט בדף השיחה.
עיצוב ותכנות הוא לב-ליבה של הנדסת התוכנה. התחום עוסק בתכנון וקידוד המבנה הפנימי של התוכנה, תת-המערכות והרכיבים שלה, מבני הנתונים והאלגוריתמים והיחסים השונים ביניהם. תחום זה הוא קרוב לוודאי המסובך ביותר בהנדסת התוכנה מפאת הדרכים הרבות והשונות לפתרון בעיה נתונה. דהיינו, יש שוני רב בפתרונות האפשריים לבעיה, בכל הנוגע לסוג המבנים הפנימיים, מספרם, סדר הופעתם והיחסים ביניהם. זאת ועוד, בתחום זה יש עושר גדול של שפות תכנות, ספריות, כלים ושיטות תכנות, שמהן יש לבחור את הנכונים לבעיה נתונה. בניגוד לתחומי ההנדסה המסורתית שבהם יש תשתית מתמטית תיאורטית ואמפירית לתכנון המבנה, אין בהנדסת תוכנה תשתית כזו. העוסקים בתחום משתמשים במערכת של עקרונות, כללי-אצבע ותבניות עיצוב, ומסתמכים על ניסיון רב כדי לתכנן את המבנה הנכון במסגרת האילוצים של הארכיטקטורה והדרישות. מאז אמצע-סוף שנות ה-80 מקובל לתכנת את המבנים הפנימיים בשיטות מוכוונות-עצמים בהסתמך על תבניות עיצוב. לעתים נעשה שימוש גם בשפת המידול המאוחדת UML לתכנון ותיעוד התוכנה. בתחום זה פועל המתכנת או מהנדס התוכנה.
- ערך מורחב – עיצוב ותכנות תוכנה
[עריכה] תכנות
פרק זה לוקה בחסר. אתם מוזמנים לתרום לוויקיפדיה ולהשלים אותו. ראו פירוט בדף השיחה.
[עריכה] תבניות עיצוב
פרק זה לוקה בחסר. אתם מוזמנים לתרום לוויקיפדיה ולהשלים אותו. ראו פירוט בדף השיחה.
[עריכה] מודל ומטא-מודל
פרק זה לוקה בחסר. אתם מוזמנים לתרום לוויקיפדיה ולהשלים אותו. ראו פירוט בדף השיחה.
[עריכה] בדיקות
פרק זה לוקה בחסר. אתם מוזמנים לתרום לוויקיפדיה ולהשלים אותו. ראו פירוט בדף השיחה.
בדיקת תוכנה היא התהליך המסייע לוודא את הנכונות, השלמות, רמת האבטחה והאיכות של מערכת תוכנה באמצעות איתור שגיאות וכשלים המתרחשים בעת הרצת התוכנה, כלומר, השוואת פלט התוכנה לערכים צפויים כלשהם.
תחום בדיקות התוכנה הוא נגזרת של דיסצפלינת הבטחת איכות המקובלת בכל ענפי ההנדסה, ושם דגש על המאפיינים הייחודיים של מערכות תוכנה. בענפי ההנדסה, תוצר איכותי הוא כזה העומד, בגמר תהליך הייצור, בדרישות שהוגדרו. לעומת זאת, בהנדסת תוכנה אין תהליכי ייצור וברוב המכריע של המקרים לא ניתן לפרט מראש ובאופן מדויק את הדרישות מהתוכנה, קל וחומר את מפרטה המדויק (ראו גם אימות), דבר המקשה על פירוש מדויק של המונח 'איכות תוכנה'.
מתחילת המאה העשרים ואחת גובר השימוש בשיטות פורמליות-למחצה להגברת דיוק המפרט. שיטות אלה מיושמות בתכנות מונחה בדיקות בשילוב תרחישי שימוש, בתכנות מוכוון היבטים ובמתודולוגיית פיתוח התוכנה Evo.
- ערך מורחב – הבטחת איכות תוכנה
ישנן שתי סוגי בדיקות: כאלה הסוקרות את ההתנהגות החיצונית של התוכנה, וכאלה הסוקרות את ההתנהגות הפנימית של התוכנה. הגישה השיטתית לבדיקות תוכנה מנוסחת במודל ה-V שבו מוגדרים סוגי הבדיקות ותהליכי הבדיקה המתאימים לכל תוצר עיקרי בפיתוח - החל מבדיקות יחידה המפותחות כחלק ממשימות התכנות השוטפות, וכלה בבדיקות קבלה הנמשכות לרוב זמן ארוך ומחייבות היערכות נרחבת מצד גורמים רבים. היקף וסוג הבדיקות, כמו גם מיקומן במחזור הפיתוח של התוכנה, נקבעים כחלק ממתודולוגיית הפיתוח המשמשת בפרויקט. בחלק מהמתודולוגיות, מקומן של הבדיקות הוא בסוף תהליך הפיתוח (לדוגמה מפל-המים). באחרות, בדיקות התוכנה הן לב לבו של תהליך התכנות (לדוגמה XP).
- ערך מורחב – בדיקות תוכנה
[עריכה] בדיקות פונקציונליות
בדיקות המשוות את פלט התוכנה לערכים צפויים כלשהם. בדיקות אלה מכונות בדיקות "קופסה שחורה" מכיוון שאינם בוחנות כיצד מבצעת התוכנה את הנדרש ממנה אלא רק את תוצאות הפלט.
- בדיקות יחידה - בדיקות ברמת יחידת המערכת הקטנה ביותר המאמתות את פעילותה התקינה של היחידה. לרוב מדובר על בדיקה של פרוצדורה, מחלקה, קבוצה קטנה של מחלקות הפועלות בתיאום או תת-מערכת קטנה. סבירות התקינות של היחידה הנבדקת תלויה במספר נתיבי הריצה הנבדקים מתוך סה"כ נתיבי הריצה האפשריים. בפועל, בדיקות יחידה איכותיות מכסות בדרך-כלל הנתיב העיקרי של הריצה, הטיפול העיקרי בשגיאות ומקרי קצה בולטים בקלט. כתיבת בדיקות היחידה היא באחריותו של מתכנת היחידה הנבדקת והן לרוב נכתבות באותה שפת-תכנות. מסוף שנות ה-90 מקובלים מספר כלים המסייעים לכתיבה וארגון בדיקות היחידה, שהעיקריים הם JUnit ו-XUnit.
- בדיקות נסיגה - בדיקות לשם השוואת יכולות וביצועים בין גרסאות שונות של אותה תוכנה. מטרת בדיקות הנסיגה היא לוודא כי כל תפקודי התוכנה ויכולותיה מהגרסאות הקודמות לא נפגעו כתוצאה משינויים בגרסה הנוכחית. תיאורטית, יש להריץ את כל תסריטי הבדיקה הקיימים עבור כל גרסת תוכנה, על מנת לוודא כי לא חלה נסיגה בהתנהגות התוכנה או בביצועיה. למעשה, ניתן לצמצם את כמות הבדיקות על ידי ניהול תהליך בדיקות מונחה סיכונים ועל ידי ניתוח השינויים הכלולים בגרסה האחרונה והשפעתם על רכיבים ותהליכים שונים בתוכנה הנבדקת. עם זאת, צמצום כזה כרוך בסיכון מסוים להחמצת נסיגה קיימת בתפקוד התוכנה (בשל השפעות בלתי צפויות של השינויים).
[עריכה] בדיקות לא-פונקציונליות
בדיקות הבוחנות את איכות הארכיטקטורה של התוכנה, כלומר את איכות המאפיינים הלא-פונקציונליים של התוכנה כגון ביצועים, תגובתיות, שימושיות וכדומה. הגישה השיטתית לבחינת הארכיטקטורה בודקת את כל סוגי ה-'ilities' של התוכנה.
[עריכה] בדיקות "קופסה לבנה"
בדיקות המניחות שקוד המקור של התוכנה זמין לבודק, ולפיכך ניתן לסקור את ההתנהגות הפנימית של התוכנה, נוסף על השוואת הפלט לערכים צפויים כלשהם.
- סקר קוד - הליך בו קוד המקור של התוכנה נבדק לגילוי הפרה של כללי אצבע בתכנות, טיפול בשגיאות והיבטים אחרים הקשורים לאיכות הקוד. חלק מסוים מבדיקה זו נעשה באמצעות כלים אוטומטיים לסקירת קוד, אך בשל אופיה הסמנטי של הבדיקה, רובה מתבצע באופן ידני על ידי קריאה שיטתית וביקורתית של קוד המקור (וההסברים הנלווים), בדרך כלל על ידי עמית מנוסה של כותב הקוד. בנוסף, נהוגים גם סקרי קוד הממוקדים בהיבטים קריטיים של מערכות תוכנה כגון אבטחת מידע וביצועים.
- סקר עיצוב - הליך בו נבדק המבנה הפנימי של התוכנה. בדיקה זו כוללת בדרך כלל סקירה של מבני הנתונים העיקריים של התוכנה (מודל), אלגוריתמים, פרוטוקולים, היבטים של ריצה בו-זמנית, מערכות עזר (לדוגמה מסד נתונים), היבטי הסדר של עיבוד הקלט והממשקים.
- סקר ארכיטקטורה - הליך בו נבדקת איכותם של ההיבטי הארכיטקטורה השונים ומאומתת התפיסה התפעולית של התוכנה בדגש על מחזור החיים השלם של התוכנה.
[עריכה] בדיקוּת
היבט העוסק ביכולת לבדוק את התוכנה בסביבה מבוקרת ומפוקחת. היכולת לבדוק תוכנה נתונה אינה מובנת מאליה ויש לתכנן, לעצב ולתכנת את התוכנה כדי שתאפשר זאת. הגישה המקובלת היא לפתח את התוכנה באופן שיאפשר את החלפת חלק, או לעתים את כל, רכיבי התוכנה ברכיבי-דמי המפוקחים ומשופעלים על ידי סביבת הבדיקות. בדרך זו, ניתן לדמות בצורה מדויקת את הקשר-הריצה המתאים קודם לתחילת הבדיקה, להזריק נתוני קלט מדויקים, ולחלץ את הפלט מרכיבי הדמי לאחר ריצת-הבדיקה.
תוכנה המתאפיינת ברמת בדיקוּת גבוהה מתאפיינת כמעט תמיד גם ברמת הפשטה גבוהה, ניתוק צימודים במבנים פנימיים ורמת גרעיניות נכונה. עובדה זו הביאה לפיתוח טכניקת תכנות מונחה בדיקות שנוסף על פיתוח ערכת בדיקות מקיפה מביאה כבדרך אגב גם לשיפור מהותי באיכות התוכנה[17].
- ערך מורחב – בדיקוּת תוכנה
[עריכה] כיסוי
היבט העוסק בהגדרת הקלטים, המצבים ונתיבי הריצה שיש לבדוק בתוכנה, וכן בכלים המשמשים לבדיקות אלה. בדיקות כיסוי מאפשרות לבדוק אילו הצהרות ונתיבי ריצה בתוכנית בוצעו בעת הרצת מבדק מסוים, ובדרך זו לוודא שכל החלקים בתוכנה נבדקו. עם זאת, בשל המספר הרב של המצבים האפשריים בתוכנה, לא ניתן לבדוק את כולם ויש להתמקד באזורים ובמצבים אופיניים, כגון טיפול בשגיאות וכדומה.
- ערך מורחב – בדיקות כיסוי קוד
[עריכה] מיכון
מיכון בדיקות תוכנה הוא היבט העוסק בשימוש בכלים לפיקוח על הרצת בדיקות תוכנה, השוואה שיטתית של תוצאות הפלט לערכים צפויים כלשהם ולהגדרה של הקשר הריצה המתאים ונתוני הקלט קודם לתחילת הבדיקה. מיכון הבדיקות הוא נדבך הכרחי בתחום בדיקות התוכנה בשל הקושי הרב לבדוק מערכות תוכנה באופן ידני על ידי בודקים אנושיים.
[עריכה] אימות
אימות תוכנה הוא תחום העוסק בהוכחה שתוכנה מסוימת היא נכונה או בעלת תכונות מסוימות. תוכנה "נכונה" בהקשר זה היא תוכנה המבצעת בדיוק את מה שהוגדר במפרט שלה. בהנדסת תוכנה, המונח אימות תוכנה מתייחס למגוון של טכניקות מתמטיות ומתמטיות-תכנותיות (להלן שיטות פורמליות) המאפשרות ליצג היבטים שונים של התוכנה באופן מדויק ובר-הוכחה[18]. השימוש בטכניקות אלה מסייע להגביר את מידת האמינות והיציבות של התוכנה המפותחת[19], ולעתים אף מפחית מעלויות הפיתוח הכוללות[20] (דהיינו, אם אלה כוללות גם את תיקון הבאגים בשלב התחזוקה). עם זאת, בשל חסמים מעשיים ותיאורטיים (ראו גם בעיית העצירה) בשיטות האימות הקיימות, ובשל הגודל והמורכבות של מערכות התוכנה המודרניות, לא ניתן לאמת מערכות תוכנה באופן מלא, והשיטות הפורמליות מוחלות לרוב רק על סוגים קריטיים של מערכות תוכנה, וגם אז רק על חלקים נבחרים בתוכנה.
- ערך מורחב – אימות תוכנה
[עריכה] רמות אימות
השיטות הפורמליות נחלקות למספר רמות אימות:
- רמה 0 - מפרט פורמלי. בשיטה זו, מפרט התוכנה, או חלקים קריטיים בו, מוגדרים באופן פורמלי, והתוכנה מפותחת ממפרט זה כרגיל כאילו מדובר בתרחיש שימוש. רף הכניסה לשימוש בשיטה זו הוא נמוך יחסית, ורבים מחשיבים אותה כבעלת התשואה הגבוהה ביותר בתחום אימות התוכנה. שפות מפרט פורמליות מוקדמות (כגון שפת Z) היו קשות לשימוש ונעדרו כלי תוכנה המסייעים בפיתוח, אך עם זאת הדגימו היטב את היתרונות הגלומים בשיטה זו. החל מראשית המאה העשרים ואחת גובר השימוש בתיווי פורמלי למחצה ובכלי תוכנה המקלים על תהליך פיתוח המפרט, וקיימים כלים מתוחכמים לשפות המפרט העיקריות - VDM, Alloy ושפת B, כולן צאצאיות של שפת Z.
- רמה 1 - פיתוח פורמלי. בשיטה זו, התוכנה מפותחת באופן פורמלי על ידי סדרה מדורגת של טרנספורמציות עידון, מייצוג מתמטי-מפושט של התוכנה לקוד מקור מסוים הניתן להרצה. בדרך זו ניתן להוכיח שלקוד התוכנה, המסתמך על מודל חישובי כלשהו, יהיו תכונות מסוימות בזמן ריצת התוכנית. שיטה זו מחייבת ידע מתמטי עמוק מהמקובל בהנדסת תוכנה ועושה שימוש במספר שיטות פורמליות להגדרה מפושטת של מבני הנתונים, הפעולות ותנאי ההתחלה והסיום בחלקים השונים של התוכנה.
- רמה 2 - הוכחה ממוכנת של טענות (ATP). בשיטה זו נעשה שימוש במוכיחי טענות ממוכנים.
[עריכה] אימות התוכנה
המפרט הפורמלי משמש לבדיקת נכונות התוכנה, בשני היבטים:
- פעולות - אם המפרט הפורמלי כולל סמנטיקה תפעולית של התוכנה, וניתן להריץ את המפרט או לדמות את ריצתו, הרי שניתן להשוות את התנהגות התוכנה בזמן ריצה לזו של המפרט. בנוסף, ניתן לחולל מהמפרט חלקים מקוד המקור של התוכנה.
- נכונות אקסיומטית - אם המפרט הפורמלי כולל סמנטיקה אקסיומטית, ניתן לחולל קוד וגם טענות נכוֹנוּת (Assertions) לבדיקת תנאי התחלה ותנאי הסיום של חלקים בתוכנה.
[עריכה] תחומים תומכים
[עריכה] ניהול פרויקטים
פרק זה לוקה בחסר. אתם מוזמנים לתרום לוויקיפדיה ולהשלים אותו. ראו פירוט בדף השיחה.
[עריכה] ניהול תצורה
ניהול תצורה הוא תחום העוסק בבקרה שיטתית על מצב, מיקום וגרסת הפריטים המעורבים בפיתוח תוכנה. התחום הוא נגזרת של דיסצפלינת ניהול התצורה המקובלת בכל ענפי ההנדסה, ושם דגש על המאפיינים הייחודיים של מערכות תוכנה.
- ערך מורחב – ניהול תצורת תוכנה
[עריכה] ניהול תצורת קוד המקור
בעיה עיקרית בפיתוח תוכנה, ובייחוד בפיתוח תוכנה בקנה מידה גדול, היא ניהול השינויים ובקרת התצורה. במהלך הפיתוח, נעשים באופן שגרתי עשרות אלפים, מאות אלפים, ולעתים אף עשרות מיליונים של שינויים בקוד המקור של התוכנה ופריטים אחרים. ניהול השינויים ובקרת תצורה הן למעשה שיטות, תהליכים וכלים לארגון ומעקב אחר שינויים אלו.
[עריכה] בנייה
המונח בנייה בהנדסת תוכנה מתייחס לתהליך הממיר את קוד המקור של התוכנה (ופריטים נוספים) לקובץ בר-הרצה. במערכות פשוטות, לרוב מדובר על הידור וקישור של מספר קטן של קבצים המתבצע ישירות מסביבת הפיתוח. לעומת זאת, במערכות תוכנה גדולות תהליך הבנייה עשוי לכלול עשרות ומאות צעדים שונים המתבצעים בסדר מסוים ובמקביל, תוך שימוש במגוון של כלים. מתחילת שנות ה-90 מקובל להתייחס לבניית התוכנה כאל נדבך חיוני בפיתוח תוכנה, ויש אף המדמים אותו ל-"דופק" של ליבו של אדם שבאמצעותו ניתן למדוד את מידת בריאותו הפרויקט.
- ערך מורחב – בניית תוכנה
[עריכה] תיעוד
תיעוד תוכנה או תיעוד קוד המקור הוא טקסט המלווה את התוכנה ומסביר כיצד זו פועלת או איך להשתמש בה. תיעוד הוא חלק חשוב בהנדסת תוכנה, אם כי מוזנח לעתים.
ישנם מספר סוגי תיעוד:
- ארכיטקטורה/תכנון - תיעוד הכולל תיאור כללי של התוכנה, רכיבים עיקריים, תיאור ההחלטות הטכניות המשמעותיות (נקרא גם "החלטות ארכיטקטוניות"), קשרים לסביבת הריצה ועקרונות הבניה של התוכנה. בחלק ממתודולוגיות הפיתוח ובעיקר ב-RUP, תיעוד הארכיטקטורה, כלומר, הגדרתה, הוא אחד מאבני הדרך העיקריות בפרויקט. במערכות גדולות, מקובל להשתמש בשפת המידול המאוחדת UML לתיעוד התוכנה.
- טכני - תיעוד של קוד המקור, אלגוריתמים, ממשקים וממשקי תכנות היישומים של התוכנה. תיעוד זה הוא באחריותו של המתכנת.
- משתמש קצה - תיעוד זה כולל מדריך למשתמשי הקצה בתוכנה, טקסט העזרה, ומדריך למנהלנים ותומכים ("Help Desk"). סוג זה של תיעוד נכתב לרוב על ידי כתב טכני המלווה את הפרויקט.
- שיווק - במידה ומדובר במוצר מדף, תקצירים המתארים את תכונות המוצר וטקסט אחר המסייע לשיווקו.
- ערך מורחב – תיעוד תוכנה
[עריכה] ראו גם
[עריכה] לקריאה נוספת
- Sommerville, Ian [1982] (2007). Software Engineering, 8th ed., Harlow, England: Pearson Education.
- Pressman, Roger S. (2005). Software Engineering: A Practitioner's Approach, 6th ed., Boston, Mass: McGraw-Hill.
- Larman, Craig (2003). Agile and Iterative Development: A Manager's Guide, Addison-Wesley Professional.
[עריכה] קישורים חיצוניים
- Computer Software Engineers - הגדרות וסטטיסטיקה של משרד העבודה האמריקאי
- עשרת המיתוסים הנפוצים על הנדסת תוכנה
- Big Ball of Mud - דיון בנושאי עיצוב וארכיטקטורת תוכנה
- Scientific American Magazine (June 2006 Issue) Dependable Software by Design
- SWEBOK - המדריך ל-"גוף הידע" של הנדסת תוכנה
[עריכה] הערות שוליים
- ^ 1.0 1.1 “IEEE Standard Glossary of Software Engineering Terminology,” IEEE std 610.12-1990, 1990.
- ^ 2.0 2.1 Guide to the Software Engineering Body of Knowledge (2004)
- ^ 3.0 3.1 3.2 Parnas, David (1998). Software Engineering Programmes are not Computer Science Programmes, Annals of Software Engineering, vol. 6, p. 19: "Rather than treat software engineering as a subfield of computer science, I treat it as an element of the set, {Civil Engineering, Mechanical Engineering, Chemical Engineering, Electrical Engineering,...}."
- ^ 1968 NATO Software Engineering Conference
- ^ Salah, Akram I. (2002). Annual Midwest Instruction and Computing Symposium: "For some, software engineering is just a glorified name for programming. If you are a programmer, you might put 'software engineer' on your business card — never 'programmer' though."
- ^ McConnell, Steve (2003). Professional Software Development: Shorter Schedules, Better Projects, Superior Products, Enhanced Careers, Addison-Wesley, ISBN 0-321-19367-9. p. 39: "In my opinion, the answer to that question is clear: Professional software development should be engineering. Is it? No. But should it be? Unquestionably, yes. "
- ^ W.R. Reitman (1964). Heuristics Decision Procedures, Open Constraints, and the Structure of Ill-Defined Problems
- ^ V. Goel (1995). Sketches of Thought, The MIT Press, Cambridge MA
- ^ A. Hunt, D. Thomas (1999), The Pragmatic Programmer
- ^ Knuth, Donald (1974). Computer Programming as an Art , Communications of the ACM, 17 (12): 667-673. Transcript of the 1974 Turing Award lecture
- ^ H. Takeuchi, I. Nonaka (1986). The New New Product Development Game
- ^ A. Cockburn (2001). Agile Software Development
- ^ B.W. Boehm, J.R. Brown, M. Lipow (1976), Quantitative Evaluation of Software Quality
- ^ G. Booch (1986), Object-Oriented Development
- ^ W. Cunningham, Do The Simplest Thing That Could Possibly Work
- ^ W. Cunningham, You Ain't Gonna Need It
- ^ K. Beck (2002), Test-driven Development
- ^ R. W. Butler (2001) What is Formal Methods?
- ^ C. Michael Holloway, Why Engineers Should Consider Formal Methods
- ^ I. Houston, S. King, CICS project report, experiences and results from the use of Z in IBM, volume 551 of LNCS, Springer-Verlag, 1991
