הנדסת תוכנה

הנדסת תוכנה (באנגלית: Software Engineering) היא ענף של הנדסה, העוסק בפיתוח תוכנה.

הנדסת תוכנה
ערך זה שייך לקטגוריית הנדסת תוכנה
פעילויות ושלבים
דרישות • ניתוח • אפיון • ארכיטקטורה • עיצוב • תכנות • ניפוי שגיאות • בדיקה • אימות • בנייה • פריסה • תפעול • תחזוקה
מתודולוגיות
זריזות • מפל המים • תכנת ותקן • Crystal Clear • Scrum • Unified Process • Extreme Programming • אינטגרציה רציפה • DevOps
תחומים תומכים
ניהול פרויקטים • ניהול תצורה • תיעוד • הבטחת איכות • Profiling
כלים
מהדר • מקשר • מפרש • IDE • ניהול גרסאות • אוטומציית בנייה

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

הנדסת תוכנה החלה להתגבש כתחום ייחודי בשנות ה-60 המאוחרות, על רקע משבר התוכנה. עד אותה עת נחשבה הנדסת התוכנה לענף משני של מדעי המחשב. כנס ראשון בהנדסת תוכנה נערך בשנת 1968 על ידי ועדת המדע של נאט"ו,^[3] וציין את תחילת דרכו של הענף כתחום נפרד ועצמאי. עם החלוצים בתחום נמנים פרד ברוקס, בארי בם, טוני הור ודייוויד פרנס. גרסה ראשונה של גוף הידע הרשמי של המקצוע הושלמה בשנת 1999 ובאותה השנה הוענק לפרד ברוקס פרס טיורינג על "תרומותיו פורצות הדרך בהנדסת מחשבים, מערכות הפעלה והנדסת תוכנה".^[4] שני אירועים אלה נחשבים לאבני דרך חשובות בהתפתחות הענף. בארצות הברית, מסלול לימודים אקדמי בהנדסת תוכנה (BSc) נפתח לראשונה בשנת 1996, ומסלול דומה מוצע גם בישראל. עם זאת, נכון לשנת 2006, לרוב העוסקים בתחום יש הכשרה אקדמית במדעי המחשב ולא בהנדסת תוכנה.^[5]

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

הגדרה של הנדסת תוכנה

המונח "הנדסת תוכנה"

המונח "הנדסת תוכנה" נטבע בשנת 1968 על ידי פרידריך באוור (אנ') במהלך כנס שערכה ועדת המדע של נאט"ו, ונמצא בשימוש נרחב מאז. נכון לתחילת המאה ה-21, הוא מפורש במספר דרכים שונות ונבדלות:

• כינוי בן־זמננו למגוון הפעילויות שבעבר נודעו כתכנות וניתוח מערכות.
• מונח רחב המתאר את כל ההיבטים המעשיים של תכנות מחשבים. זאת, בניגוד לתאוריה של תכנות מחשבים הידועה גם כמדעי המחשב.
• מונח המגלם גישה מסוימת לתכנות מחשבים, דהיינו, התייחסות לתכנות מחשבים כמקצוע הנדסי ולא כאמנות.
• לפי תקן IEEE 610.12, הנדסת תוכנה היא "(1) יישום של גישה שיטתית, מבוקרת ומדידה לפיתוח, תפעול ותחזוקה של תוכנה, כלומר, החלה של הנדסה על תוכנה; (2) לימוד הגישות השונות ל־(1)".^[1]

המונח "מהנדס תוכנה"

בדומה למונח "הנדסת תוכנה", גם משמעות המונח "מהנדס תוכנה" נתונה במחלוקת:

• עד אמצע שנות ה-90, העדיפו רוב העובדים בתחום לתאר מקצועם כ-"תוכניתן", "מתכנת" או "מְפַתֵח". בהמשך, עם תפוצתו הרחבה של המחשב האישי והגידול החד במספר העוסקים בתחום, התואר "מתכנת", קיבל גוון שלילי ושימש ככינוי לאלה שאין להם הכלים, הכישורים, ההשכלה או האתיקה הדרושים לפיתוח תוכנה איכותית. בעקבות זאת, החלו חלק מאנשי המקצוע לכנות את עצמם "מהנדסי תוכנה", וחברות רבות החליפו את התארים "מתכנת" ו-"מפתח תוכנה" בתואר "מהנדס תוכנה".^[7] עם זאת, ההבחנה בין המונחים אינה מקובלת על כולם ויש הדבקים במונחים המקוריים.^[8] מחלוקת זו מוסיפה על הבלבול הקיים באשר להגדרה המדויקת של הנדסת התוכנה.
• בקרב מהנדסים בתחומים המסורתיים של ההנדסה (ובפרט איגוד המהנדסים האזרחיים של ארצות הברית, NSPE (אנ')), יש הטוענים כי להם זכויות ייחודיות על המונח "הנדסה", וכי השימוש במונח זה דורש את אישורם. ואכן, ב-48 מבין מדינות ארצות הברית, השימוש בתואר "מהנדס תוכנה" אסור על מי שלא הוסמך על ידי ה-NSPE. עם זאת, אנשי מקצוע רבים, אוניברסיטאות רבות ואף לשכת הסטטיסטיקה של משרד העבודה האמריקני (אנ') משתמשים במונח "מהנדס תוכנה" בחופשיות כדי לתאר את העוסקים בתחום תכנות המחשבים.
• ה-ACM מתנגד לשימוש במונח "מהנדס תוכנה" ולרישוי העוסקים בתחום. על פי ה-ACM, מהנדס תוכנה מורשה (בדומה למהנדס בניין הרשום בפנקס המהנדסים) ייתפס בציבור כמי שמחזיק בידע והכישורים הדרושים לבניית תוכנה אמינה, עקבית ושימושית, אף על פי שהנדסת תוכנה אינה בשלה דיה כדי להבטיח זאת.^[6]

הנדסה, מדע או אמנות?

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

• יש המסווגים את פיתוח התוכנה כענף מובהק של ההנדסה. המצדדים בגישה זו מצביעים על השיטות המשותפות לדיסציפלינות אלה, כגון איסוף וניהול דרישות, הבטחת איכות וניהול פרויקטים. מאידך, המצדדים בגישה זו נוטים להמעיט בחשיבותו של המרכיב הייצורי והפיזי של הנדסה, שאינו קיים כלל בהנדסת תוכנה. אחרים טוענים שייתכן והנדסת תוכנה אינה דיסציפלינה הנדסית, אך עליה להיות כזו.^[9] מנגד, עמדתו של ה-ACM היא שהנדסת התוכנה אינה בשלה דיה כדי להיחשב דיסציפלינה הנדסית, מכיוון שלא ניתן להבטיח שתוצריה יהיו עקביים, אמינים או שימושיים. לרוב, הגישה הנאיבית להנדסת תוכנה מבלבלת בין התוצר ההנדסי לפיתוחו, ומבקשת לייחס את איכות התוצר ההנדסי לתהליכי הפיתוח של התוכנה. דהיינו, כשם שהתוצר ההנדסי (לדוגמה מטוס) עומד בקריטריונים מחמירים של יעילות, עמידות ודיוק, כך גם תהליכי פיתוח התוכנה עצמם חייבים לעמוד בקריטריונים דומים. גישה זו מיושמת במתודולוגיית פיתוח התוכנה מודל מפל־המים המורה על פיתוח תוכנה בתהליך קווי, חד־כיווני הדומה לפס־ייצור של מוצר הנדסי.
• יש המסווגים את פיתוח התוכנה כענף מדעי־מתמטי. ואכן, כל מערכות התוכנה מבוססות על יסודות אלגוריתמיים, וחלקן משתמשות בנוסף בענפים שונים של המתמטיקה השימושית. בתהליך פיתוח התוכנה משמשות לעיתים שיטות מתמטיות מתחום מדעי המחשב, כגון יעילות אלגוריתמים, מודלים של חישוב ושיטות לאימות תוכנה. אף על פי כן, הנדסת תוכנה אינה ענף של המתמטיקה, וידע מתמטי עמוק אינו מבטיח כלל ועיקר את איכות התוכנה. אדרבא, השיטות הפורמליות הקיימות משמשות לאימות תוכנה ולא לתכנונה. זאת ועוד, שיטות האימות הקיימות אינן מסוגלות להתמודד עם המורכבות וסדרי הגודל של מערכות התוכנה המודרניות, ובנוסף מוגבלות בשל חסמים תאורטיים מובנים (ראו גם בעיית העצירה). חלקים מהותיים בתהליך פיתוח התוכנה הם עיצוביים באופיים^[10] ומתבססים על איסוף וארגון מידע שאינו פורמלי או מוגדר־היטב,^[11] ופירוש והמרת אלה לשפת מחשב כלשהי.
• יש המסווגים את פיתוח התוכנה כמקצוע הדורש עבודת אומן^[12] או אפילו כאמנות.^[13] ואכן, תהליך פיתוח התוכנה חולק איכויות מסוימות עם תהליך היצירה האמנותית, כגון הפשטה, אסתטיקה, דרגות חופש גבוהות ועוד. במקרים רבים, העוסקים בתחום חותרים לפתח פתרונות שיהיו אסתטיים, נוסף על היותם מעשיים. בדומה למקצועות אחרים הדורשים עבודת אומן שיטתית (לדוגמה אדריכלות), גם מקצוע פיתוח התוכנה דורש תקופה ארוכה של חניכות אצל בעל מקצוע ותיק. עם זאת, יש הטוענים כי הגישה האומנותית לבדה אינה מספיקה לפיתוח שיטתי של תוכנה בקנה מידה גדול.
• יש המסווגים את פיתוח התוכנה כתהליך יצירת קניין רוחני. לפי גישה זו, פיתוח תוכנה הוא ביסודו בעיה אמפירית, ולא ניתן לפתור אותה בשיטות המתבססות על חיזוי או תכנון.^[14] המצדדים בגישה זו מדמים את פיתוח התוכנה למשחק של שיתוף פעולה מוכוון־מטרה, בדומה לטיפוס הרים.^[15] גישה זו שמה דגש רב על סביבת עבודה מתאימה, זרימת מידע אוסמוטית בין חברי הצוות, ותקורה פורמלית־טקסית נמוכה. עקרונות אלה מיושמים במתודולוגיות פיתוח תוכנה זריזוֹת כגון XP ו־Scrum. עם זאת, יש הטוענים כי גישה זו לבדה אינה מתאימה לפיתוח מערכות קריטיות, או כאלה המחייבות צוותי פיתוח גדולים.

השוואה לתחומים קרובים

הקשר שבין מדעי המחשב, הנדסת מחשבים והנדסת תוכנה

הנדסת תוכנה לעומת תכנות

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

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

הנדסת תוכנה לעומת מדעי המחשב

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

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

"מדעי המחשב אינם עוסקים במחשב יותר משאסטרונומיה עוסקת בטלסקופ."

הטבלה הבאה מפרטת את ההבדלים בין שתי הדיסציפלינות:

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

הנדסת תוכנה לעומת הנדסה מסורתית

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

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

תחומי הליבה

תהליכי הנדסת תוכנה

ערך מורחב – מתודולוגיית פיתוח תוכנה

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

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

מתודולוגיות קוויות

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

מתודולוגיות איטרטיביות

• Unified Process (או בקיצור UP) היא מתודולוגיה ששורשיה בעבודתו של בארי בם והורחבה על ידי פיליפ קרוצ'טן, גריידי בוץ' ואחרים. המתודולוגיה הוצגה לראשונה בין השנים 1995–1998. UP אינה מתודולוגיה במובן הקלאסי, כי אם מסגרת מתודולוגית שניתן להרחיבה ויש להתאימה לארגון או פרויקט מסוים. UP היא מתודולוגיה איטרטיבית המורה על פיתוח תוכנה בתהליך מחזורי רב-שלבי. המתודולוגיה שמה דגש על ניהול הפרויקט, ניהול השינוי, הארכיטקטורה ותהליכי המידול של התוכנה. ייחודה של UP הוא בדרכים המובנות בה המאפשרות להתאימה לסוגים וגדלים רבים של פרויקטים לפיתוח תוכנה, החל מפרויקטים קטנים ולא-קריטיים ועד לפרויקטי-ענק לפיתוח מערכות קריטיות תומכות-חיים. הטכניקות העיקריות של המתודולוגיה כוללות פיתוח מחזורי תחום-בזמן, ניהול השינוי באמצעות כלי ניהול שינויים ובקרת תצורה, ניהול הדרישות ומידול ויזואלי באמצעות UML.

מתודולוגיות זריזות

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

• eXtreme Programming (או בקיצור XP) היא מתודולוגיה שפותחה על ידי קנט בק, ומתוארת בספרו eXtreme Programming Explained שיצא לאור בשנת 2000, ובספרים נוספים שצצו בעקבותיו. שמה ניתן לה בשל העובדה שהשיטות המשמשות אותה הן מחמירות מאוד, ובעת פרסומה נחשבו כקיצוניות יחסית לשיטות הקיימות בתעשייה. המתודולוגיה, כפי שרומז שמה, מפרטת שורה של טכניקות בתחום התכנות ופחות בתחומים אחרים של הנדסת תוכנה. מערכות המפותחות לפיה הן גמישות מאוד לשינויים, וניתן להרחיבן בקלות ובאופן בטוח. כדי להשיג גמישות זו, XP משתמשת בשיטת תכנות מונחה-בדיקות שעיקריה הם כתיבת דרישות המערכת כסט של בדיקות הניתנות להרצה, ופיתוח הבדיקות קודם לפיתוח הפונקציונליות. שיטה זו דורשת הבנה טובה של עקרונות תכנות מונחה-עצמים ומשמעת עצמית גבוהה.
• Crystal Clear היא מתודולוגיה שפותחה על ידי אליסטר קוברן ועקרונותיה מתוארים בספרים שפרסם החל משנת 1998. מתודולוגיה זו שמה דגש על יעילות בפיתוח ומפגינה סגלתנות רבה לשוני בדרכי העבודה האנושיות כפי שאלה מתבטאות בפיתוח תוכנה על ידי מתכנתים. המתודולוגיה מפרטת עקרונות לתכנות נכון אך מתמקדת יותר בעיצוב התוכנה וניהול הפרויקט. המתודולוגיה מתאימה לצוותים קטנים המפתחים תוכנה שאינה תומכת-חיים. ייחודה של Crystal Clear הוא בקלות היחסית שניתן להתאימה לאילוצים המופיעים פעמים רבות בפרויקטים לפיתוח תוכנה (לדוגמה, העדרו של לקוח), ובמסגרת נוחה להרחבה גם לצוותים גדולים יותר.
• Scrum היא מתודולוגיה זריזה לניהול פרויקטים לפיתוח תוכנה שפותחה על ידי קן שוואבר ואחרים. הדגש היסודי של השיטה הוא על צוותים המכווינים את עצמם, וכן על תהליך נסיוני (אמפירי) מחזורי שאינו מוגדר מראש.^[17] המונח "Scrum" מקורו במשחק הרוגבי, שם הוא מתאר את הדרך שבה המשחק מתחיל מחדש לאחר שהכדור יצא מהמגרש. הטכניקה של "התחלה מחדש" היא אחת מאבני היסוד של השיטה – פרויקט Scrum מתחיל את תהליך הפיתוח כל חודש מחדש. כלומר, פעם בחודש מסופקת תוכנה עובדת למשתמשים, והערותיהם, כמו גם הדרישות החדשות, מיושמות במחזורי הפיתוח העוקבים. מקובל להשתמש ב־Scrum כמעטפת לניהול פרויקטים המפותחים במתודולוגיית XP ומתודולוגיות זריזות אחרות.

דרישות תוכנה

ערך מורחב – מפרט דרישות תוכנה

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

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

ישנם שני סוגי דרישות עיקריים:

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

הגדרה של דרישה "טובה" היא שתהיה (לפי IEEE830):

• נכונה
• מוגדרת היטב
• מוחלטת
• עקיבה
• מדורגת
• ניתנת לבדיקה
• ניתנת לשינוי
• ניתנת למעקב

תכנון תוכנה

ערך מורחב – ארכיטקטורת תוכנה

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

בניית תוכנה

ערך מורחב – בניית תוכנה

במדעי המחשב, המושג בניית תוכנה (באנגלית: Software build, או בקיצור Build) מתייחס לתהליך של הפיכת קובצי קוד מקור לתוצרי תוכנה עצמאיים (Standalone) הניתנים להרצה על מחשב. כמו כן, המושג יכול להתייחס גם לתוצר עצמו של תהליך זה. אחד השלבים העיקריים של בניית תוכנה הוא תהליך ההידור (קומפילציה), בו קובצי קוד מקור הופכים לקוד הניתן להרצה (Executable code).

בדיקות תוכנה

ערך מורחב – בדיקות תוכנה

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

תחזוקת תוכנה

ערך מורחב – תחזוקת תוכנה

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

ניהול תצורת תוכנה

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

ניהול הנדסת תוכנה

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

איכות תוכנה

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

כלים ושיטות בהנדסת תוכנה

ארכיטקטורה

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

שלד ומבנה

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

• גמישות לשינויים – היבט העוסק ביכולת לשנות את התוכנה בתגובה לשינויים בדרישות או בשל דרישות חדשות. מחקרים בתחום^[19] מצאו שקשה מאוד לשנות מערכות תוכנה לאחר שאלה נמסרו ללקוח. לשם השוואה, שינוי המתבצע בתוכנה לאחר שנמסרה עולה בממוצע פי 200 משינוי המתבצע בזמן אפיון התוכנה.^[20] לפיכך, הגישה המסורתית לפיתוח תוכנה שמה דגש רב על תכנון תוכנה גמישה, כלומר, תכנון מבני התוכנה באופן כללי ומופשט ככל שניתן. תכנון כזה, אם הוא מצליח לחזות את המקומות בהן תורחב התוכנה, מאפשר את שינוי והרחבת התוכנה באופן קל ובטוח. עם זאת, הניסיון בתעשייה מלמד שמידת הצלחתו של הליך תכנוני זה היא מוגבלת, ומתודולוגיות הפיתוח הזריזות אף ממליצות נגד חלקים מהותיים בו.^[21][22]
• יכולת הרחבה וגידול – מערכות תוכנה נדרשות פעמים רבות להגדיל את תפוקת העבודה שלהן בשל גידול צפוי או בלתי-צפוי, רגעי או קבוע באירועי הקלט (לדוגמה, מספר המשתמשים המחוברים למערכת). לפיכך, דגש רב מושם על תכנון מבנה התוכנה באופן שיאפשר את הגדלת התפוקה שלה בעתיד, עם שינויים קטנים ככל שניתן בהיבטי הארכיטקטורה השונים, במבנה הפנימי או במערכות המחשב עצמן.

ממשקים

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

תא-הטייס של מטוס האיירבוס A380 שמערכות התוכנה שלו מכילות מיליוני שורות קוד, ובטיחות המטוס תלויה במידה רבה בנכונות התוכנה

אמינות

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

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

על בעיית האמינות של התוכנה עמד דייוויד פרנס:

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

— "היבטי תוכנה במערכות הגנה אסטרטגית", מעשה חושב, אפריל 1986; תרגום לעברית של Software Aspects of Strategic Defense Systems

זמינות

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

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

ביצועים

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

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

אבטחת מידע

ערך מורחב – אבטחת מידע

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

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

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

תפעול

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

אלגוריתמיקה

ערך מורחב – אלגוריתמיקה

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

אלגוריתמים ומבני נתונים יסודיים

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

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

פיתוח אלגוריתמים

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

ניתוח אלגוריתמים

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

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

עיצוב ותכנות

ערך מורחב – עיצוב תוכנה

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

בדיקות

ערכים מורחבים – הבטחת איכות תוכנה, בדיקות תוכנה

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

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

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

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

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

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

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

• בדיקות יחידה – בדיקות ברמת יחידת המערכת הקטנה ביותר המאמתות את פעילותה התקינה של היחידה. לרוב מדובר על בדיקה של פרוצדורה, מחלקה, קבוצה קטנה של מחלקות הפועלות בתיאום או תת-מערכת קטנה. סבירות התקינות של היחידה הנבדקת תלויה במספר נתיבי הריצה הנבדקים מתוך סה"כ נתיבי הריצה האפשריים. בפועל, בדיקות יחידה איכותיות מכסות בדרך-כלל הנתיב העיקרי של הריצה, הטיפול העיקרי בשגיאות ומקרי קצה בולטים בקלט. כתיבת בדיקות היחידה היא באחריותו של מתכנת היחידה הנבדקת והן לרוב נכתבות באותה שפת-תכנות. מסוף שנות ה-90 מקובלים מספר כלים המסייעים לכתיבה וארגון בדיקות היחידה, שהעיקריים הם JUnit ו-XUnit.
• בדיקות נסיגה – בדיקות לשם השוואת יכולות וביצועים בין גרסאות שונות של אותה תוכנה. מטרת בדיקות הנסיגה היא לוודא כי כל תפקודי התוכנה ויכולותיה מהגרסאות הקודמות לא נפגעו כתוצאה משינויים בגרסה הנוכחית. תאורטית, יש להריץ את כל תסריטי הבדיקה הקיימים עבור כל גרסת תוכנה, על מנת לוודא כי לא חלה נסיגה בהתנהגות התוכנה או בביצועיה. למעשה, ניתן לצמצם את כמות הבדיקות על ידי ניהול תהליך בדיקות מונחה סיכונים ועל ידי ניתוח השינויים הכלולים בגרסה האחרונה והשפעתם על רכיבים ותהליכים שונים בתוכנה הנבדקת. עם זאת, צמצום כזה כרוך בסיכון מסוים להחמצת נסיגה קיימת בתפקוד התוכנה (בשל השפעות בלתי צפויות של השינויים).

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

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

בדיקות "קופסה לבנה"

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

• סקר קוד – הליך בו קוד המקור של התוכנה נבדק לגילוי הפרה של כללי אצבע בתכנות, טיפול בשגיאות והיבטים אחרים הקשורים לאיכות הקוד. חלק מסוים מבדיקה זו נעשה באמצעות כלים אוטומטיים לסקירת קוד, אך בשל אופייה הסמנטי של הבדיקה, רובה מתבצע באופן ידני על ידי קריאה שיטתית וביקורתית של קוד המקור (וההסברים הנלווים), בדרך כלל על ידי עמית מנוסה של כותב הקוד. בנוסף, נהוגים גם סקרי קוד הממוקדים בהיבטים קריטיים של מערכות תוכנה כגון אבטחת מידע וביצועים.
• סקר עיצוב – הליך בו נבדק המבנה הפנימי של התוכנה. בדיקה זו כוללת בדרך כלל סקירה של מבני הנתונים העיקריים של התוכנה (מודל), אלגוריתמים, פרוטוקולים, היבטים של ריצה בו-זמנית, מערכות עזר (לדוגמה מסד נתונים), היבטי הסדר של עיבוד הקלט והממשקים.
• סקר ארכיטקטורה – הליך בו נבדקת איכותם של היבטי הארכיטקטורה, בהם מכלול רכיבי חומרה, תוכנה והממשקים ביניהם. בנוסף מאומתת התפיסה התפעולית של התוכנה בדגש על מחזור החיים השלם של התוכנה. לסקר ארכיטקטורה נשתמש בכלים כמו ADL – שפה תיאור ארכיטקטורה. ונענה על השאלות הבאות: כיצד תורכב המערכת מחלקים שונים, היכן הממשקים העיקריים בין החלקים, ומהם מאפיינים עיקריים של החלקים.
• סקר התיכון – שם כולל לסדרת דיוני בקרה טכניים מקובלים בפיתוח מערכות. סקר התיכון הוא מפגש טכני בו מציגים הגורמים המעורבים בתכן המערכת את פתרונות התכן ללקוח ולקבוצת מומחים המשמשים כמבקרים. בדיונים אלה בוחנים את התכן המוצע ומחליטים על כיווני ההמשך של פיתוח המערכת. סקרי התיכון העיקריים המקובלים הם: סקר תיכון מערכת (SDR), סקר תיכון ראשוני (PDR), סקר תיכון קריטי (CDR).

בדיקוּת

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

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

כיסוי

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

מיכון

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

אימות

ערך מורחב – אימות תוכנה

אימות תוכנה הוא תחום העוסק בהוכחה שתוכנה מסוימת היא נכונה או בעלת תכונות מסוימות. תוכנה "נכונה" בהקשר זה היא תוכנה המבצעת בדיוק את מה שהוגדר במפרט שלה. בהנדסת תוכנה, המונח אימות תוכנה מתייחס למגוון של טכניקות מתמטיות ומתמטיות-תכנותיות (להלן שיטות פורמליות) המאפשרות לייצג היבטים שונים של התוכנה באופן מדויק ובר-הוכחה.^[25] השימוש בטכניקות אלה מסייע להגביר את מידת האמינות והיציבות של התוכנה המפותחת,^[26] ולעיתים אף מפחית מעלויות הפיתוח הכוללות^[27] (דהיינו, אם אלה כוללות גם את תיקון הבאגים בשלב התחזוקה). עם זאת, בשל חסמים מעשיים ותאורטיים (ראו גם בעיית העצירה) בשיטות האימות הקיימות, ובשל הגודל והמורכבות של מערכות התוכנה המודרניות, לא ניתן לאמת מערכות תוכנה באופן מלא, והשיטות הפורמליות מוחלות לרוב רק על סוגים קריטיים של מערכות תוכנה, וגם אז רק על חלקים נבחרים בתוכנה (ראו גם בעיית התפוצצות מצבים).

רמות אימות

השיטות הפורמליות נחלקות למספר רמות אימות:

• רמה 0 – מפרט פורמלי. בשיטה זו, מפרט התוכנה, או חלקים קריטיים בו, מוגדרים באופן פורמלי, והתוכנה מפותחת ממפרט זה כרגיל כאילו מדובר בתרחיש שימוש. רף הכניסה לשימוש בשיטה זו הוא נמוך יחסית, ורבים מחשיבים אותה כבעלת התשואה הגבוהה ביותר בתחום אימות התוכנה. שפות מפרט פורמליות מוקדמות (כגון שפת Z) היו קשות לשימוש ונעדרו כלי תוכנה המסייעים בפיתוח, אך עם זאת הדגימו היטב את היתרונות הגלומים בשיטה זו. החל מראשית המאה ה-21 גובר השימוש בתיווי פורמלי למחצה ובכלי תוכנה המקלים על תהליך פיתוח המפרט, וקיימים כלים מתוחכמים לשפות המפרט העיקריות – VDM,‏ Alloy ושיטת B, כולן צאצאיות של שפת Z.
• רמה 1 – פיתוח פורמלי. בשיטה זו, התוכנה מפותחת באופן פורמלי על ידי סדרה מדורגת של טרנספורמציות עידון, מייצוג מתמטי-מפושט של התוכנה לקוד מקור מסוים הניתן להרצה. בדרך זו ניתן להוכיח שלקוד התוכנה, המסתמך על מודל חישובי כלשהו, יהיו תכונות מסוימות בזמן ריצת התוכנית. שיטה זו מחייבת ידע מתמטי עמוק מהמקובל בהנדסת תוכנה ועושה שימוש במספר שיטות פורמליות להגדרה מפושטת של מבני הנתונים, הפעולות ותנאי ההתחלה והסיום בחלקים השונים של התוכנה.
• רמה 2 – הוכחה ממוכנת של טענות (ATP). בשיטה זו נעשה שימוש במוכיחי טענות ממוכנים.

אימות התוכנה

המפרט הפורמלי משמש לבדיקת נכונות התוכנה, בשני היבטים:

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

תחומים תומכים

ניהול פרויקטים

ערך מורחב – ניהול פרויקטים

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

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

ניהול תצורה

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

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

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

בנייה

ערך מורחב – בניית תוכנה

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

תיעוד

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

ישנם מספר סוגי תיעוד:

• ארכיטקטורה/תכנון – תיעוד הכולל תיאור כללי של התוכנה, רכיבים עיקריים, תיאור ההחלטות הטכניות המשמעותיות (נקרא גם "החלטות ארכיטקטוניות"), קשרים לסביבת הריצה ועקרונות הבניה של התוכנה. בחלק ממתודולוגיות הפיתוח ובעיקר ב-RUP, תיעוד הארכיטקטורה, כלומר, הגדרתה, הוא אחד מאבני הדרך העיקריות בפרויקט. במערכות גדולות, מקובל להשתמש בשפת המידול המאוחדת UML לתיעוד היבט זה.
• טכני – תיעוד של קוד המקור, בדגש על אלגוריתמים, ממשקים וממשקי תכנות היישומים של התוכנה. תיעוד זה הוא באחריותו של המתכנת.
• משתמש קצה – תיעוד זה כולל מדריך למשתמשי הקצה בתוכנה, טקסט העזרה, ומדריך למנהלנים ותומכים ("Help Desk"). סוג זה של תיעוד נכתב לרוב על ידי כתב טכני המלווה את הפרויקט.
• שיווק – אם מדובר במוצר מדף, תקצירים המתארים את תכונות המוצר וטקסט אחר המסייע לשיווקו.

ראו גם

• מדעי המחשב
• קטגוריה:מהנדסי תוכנה
• הנדסה

לקריאה נוספת

• Roger S.Pressman, Software Engineering: a Practitioner's Approach, 7th Ed.,Mc-Graw Hill 2009 ISBN 978-0073375977

קישורים חיצוניים

מיזמי קרן ויקימדיה
ערך מילוני בוויקימילון: הנדסת תכנה
תמונות ומדיה בוויקישיתוף: הנדסת תוכנה

• Computer Software Engineers – הגדרות וסטטיסטיקה של משרד העבודה האמריקאי
• Scientific American Magazine (June 2006 Issue) Dependable Software by Design
• מה ההבדל בין מדעי המחשב להנדסת תוכנה? באתר מה ההבדל, 11 באוקטובר 2014
• הנדסת תוכנה, דף שער בספרייה הלאומית

הערות שוליים

1. IEEE 610.12-1990 (1990). A Glossary of Software Engineering Terminology, Institute of Electrical and Electronic Engineers, Inc. p.67: "Software Engineering. (1) The application of systematic, disciplined, quantifiable approach to the development, operation and maintenance of software; that is, the application of engineering to software. (2) The study of approaches as in (1)."
2. Guide to the Software Engineering Body of Knowledge (2004). Institute of Electrical and Electronic Engineers, Inc. p.1-2
3. Naur, Peter, Randell, Brian (1969). Report on a conference sponsored by the NATO Science Committee: "...The report summarises the discussions at a Working Conference on Software Engineering, sponsored by the NATO Science Committee. The Conference was attended by more than fifty people, from eleven different countries, all concerned professionally with software, either as users, manufacturers, or teachers at universities."
4. "Frederick P. Brooks Jr. has made landmark contributions to computer architecture, operating systems, and software engineering ' contributions that have stood the test of time and shaped the way we think about computing."
5. Computing Careers, Software Engineering (2006). Association for Computing Machinery: "Most people who now function in the U.S. as serious software engineers have degrees in computer science, not in software engineering. In large part this is because computer degrees have been widely available for more than 30 years and software engineering degrees have not."
6. Association for Computing Machinery (July 17, 2000): "A Summary of the ACM Position on Software Engineering as a Licensed Engineering Profession", p.7: "One of the central purposes of licensing is to provide assurances to the public that a licensed person is competent at their professional duties. In the case of software engineering, a license would be interpreted as an authoritative statement that the licensed engineer would be capable of producing software systems of consistent reliability, dependability, and usability. The ACM Council concluded that our state of knowledge and practice is too immature to give such assurances"
7. Dijkstra, Edsger W (1993-12-03). "There is still a war going on (manuscript Austin, 3 December 1993)". E. W. Dijkstra Archive (transcription). transcribed by Mario Béland. The University of Texas at Austin, Department of Computer Sciences. נבדק ב-2007-02-17. When the term was coined in 1968 by F.L. Bauer of the Technological University of Munich, I welcomed it. [. . .] In the mean time, software engineering has become an almost empty term, as was nicely demonstrated by Data General who overnight promoted all its programmers to the exalted rank of “software engineer”!
8. 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."
9. 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."
10. W.R. Reitman (1964). Heuristics Decision Procedures, Open Constraints, and the Structure of Ill-Defined Problems
11. V. Goel (1995). Sketches of Thought, The MIT Press, Cambridge MA
12. McBreen, Pete (2001). Software Craftsmanship: The New Imperative, Addison-Wesley Professional, ISBN 978-0201733860. p.XIII: "Is software engineering appropriate for projects of less than 100 developer-years? Is the specialization inherent in software engineering a good idea? Can software development even be expressed in engineering terms? ... The book has some controversial answers: It suggests that we've lost sight of simple truth - large methodologies and format structure don't write software: people do. To fix a growing crisis in software development, we need to start by producing better developers. To do that, Pete looks back to a system that has worked well for hundreds of years - Craftsmanship."
13. לדוגמה, דונלד קנות' מחבר סדרת הספרים "The Art of Computer Programming", המחזיק בתואר "פרופסור לאומנות תכנות המחשב"
14. Schwaber, K.; Beedle, M. (2002). "Agile Software Development with Scrum". Prentice-Hall, ISBN 0130676349.
15. Cockburn, Alistair (2001). Agile Software Development, Addison-Wesley. p.27: "Of all the comparison partners for software development that I have seen, rock climbing has emerged as the best."
16. Parnas, David L. (1998). "Software Engineering Programmes are not Computer Science Programmes". Annals of Software Engineering. 6: 19–37. doi:10.1023/A:1018949113292., 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, ....}."
17. Schwaber, K., and Beedle, M. 2002, Agile Software Development With Scrum. Prentice-Hall.
18. Meilir Page-Jones (1980). The Practical Guide to Structured Systems Design. New York: Yourdon Press. ISBN 0-917072-17-0.
19. B.W. Boehm, J.R. Brown, M. Lipow (1976), Quantitative Evaluation of Software Quality
20. G. Booch (1986), Object-Oriented Development
21. W. Cunningham, Do The Simplest Thing That Could Possibly Work
22. W. Cunningham, You Ain't Gonna Need It
23. דוגמה לכך היא מערכת האוויוניקה של מעבורת החלל. במערכת זו, התוכנה פותחה בנפרד על ידי שני צוותים, ובזמן הטיסה התוכנה העיקרית של הצוות הראשון מורצת במקביל על שלושה מחשבים שונים, והפלט נקבע בהחלטת רוב. במקביל ובתיאום, התוכנה המשנית של הצוות השני רצה על מחשב נפרד, ומקבלת פיקוח בזמן כשל קריטי בתוכנה הראשית.
24. K. Beck (2002), Test-driven Development
25. R. W. Butler (2001) What is Formal Methods?
26. C. Michael Holloway, Why Engineers Should Consider Formal Methods
27. I. Houston, S. King, CICS project report, experiences and results from the use of Z in IBM, volume 551 of LNCS, Springer-Verlag, 1991