הנדסת תוכנה

מתוך ויקיפדיה, האנציקלופדיה החופשית

(הופנה מהדף מהנדס תוכנה)
קפיצה אל: ניווט, חיפוש

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

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

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

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

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

תוכן עניינים

[עריכה] הגדרה של הנדסת תוכנה

[עריכה] המונח "הנדסת תוכנה"

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

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

[עריכה] המונח "מהנדס תוכנה"

בדומה למונח "הנדסת תוכנה", גם פירוש המונח "מהנדס תוכנה" נתון במחלוקת:

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

[עריכה] הנדסה, מדע או אמנות?

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

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

[עריכה] השוואה לתחומים קרובים

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

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

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

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

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

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

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

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

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

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

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

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

[עריכה] תחומי הליבה

[עריכה] תהליכי הנדסת תוכנה

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

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

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

[עריכה] מתודולוגיות קוויות

  • תכנת ותקן (ידועה גם בשם מהר ומלוכלך) היא המתודולוגיה המקובלת ביותר לתחזוקת מערכות תוכנה, נכון לסוף המאה העשרים. המתודולוגיה מקובלת במידה מסוימת גם לפיתוח מערכות חדשות. מתודולוגיה זו שמה דגש רב על המהירות שבה נעשים שינויים ותיקונים למערכת התוכנה, תוך התעלמות מודעת מנושאי התחזוקתיות והאיכות הפנימית של התוכנה. מתודולוגיה זו מאפשרת הוספה מהירה של פונקציונליות חדשה למערכת, אך מחייבת חיזוק של המבנים הפנימיים של התוכנה מעת לעת וערכת בדיקות מקיפה. ללא האחרונים, שימוש עקבי במתודולוגיה זו יגרום בהכרח לשחיקה מעריכית באיכות הפנימית של התוכנה, עד לנקודה שבה עלות הוספת פונקציונליות חדשה שווה או גדולה לעלות בניית התוכנה כולה מחדש, שלאחריה אין הצדקה כלכלית להמשיך לתחזק את התוכנה.
  • מפל-המים (ידועה גם בשם מודל מפל-המים) היא מתודולוגיה ותיקה ורווחת לפיתוח מערכות תוכנה. המתודולוגיה מיוחסת (בטעות) לוינסטון רויס, שהציע את הגרסה המקורית של המתודולוגיה במאמר שפורסם בשנת 1970. עם השנים נשתרשה פרשנות מוטעית למאמרו, והיא זו הידועה בשם "מודל מפל-המים". בהקשרה ההיסטורי, המתודולוגיה נתפסה כתגובה לשיטות אד הוק של 'תכנת-ותקן' שרווחו מאוד בשנות השישים של המאה ה־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 היא מתודולוגיה זריזה לניהול פרויקטים לפיתוח תוכנה שפותחה על ידי קן שוואבר ואחרים. הדגש היסודי של השיטה הוא על צוותים המכווינים את עצמם, וכן על תהליך נסיוני (אמפירי) מחזורי שאינו מוגדר מראש[16]. המונח "Scrum" מקורו במשחק הרוגבי, שם הוא מתאר את הדרך שבה המשחק מתחיל מחדש לאחר שהכדור יצא מהמגרש. הטכניקה של "התחלה מחדש" היא אחת מאבני היסוד של השיטה - פרויקט Scrum מתחיל את תהליך הפיתוח כל חודש מחדש. כלומר, פעם בחודש מסופקת תוכנה עובדת למשתמשים, והערותיהם, כמו גם הדרישות החדשות, מיושמות במחזורי הפיתוח העוקבים. מקובל להשתמש ב־Scrum כמעטפת לניהול פרויקטים המפותחים במתודולוגיית XP ומתודולוגיות זריזות אחרות.

[עריכה] דרישות תוכנה

[עריכה] תכנון תוכנה

[עריכה] בניית תוכנה

[עריכה] בדיקות תוכנה

[עריכה] תחזוקת תוכנה

[עריכה] ניהול תצורת תוכנה

[עריכה] ניהול הנדסת תוכנה

[עריכה] איכות תוכנה

[עריכה] כלים ושיטות בהנדסת תוכנה

[עריכה] ארכיטקטורה

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

[עריכה] שלד ומבנה

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

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

[עריכה] ממשקים

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

[עריכה] אמינות

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

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

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

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

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

[עריכה] זמינות

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

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

[עריכה] ביצועים

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

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

[עריכה] אבטחת מידע

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

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

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

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

[עריכה] תפעול

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

[עריכה] אלגוריתמיקה

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

[עריכה] אלגוריתמים ומבני נתונים יסודיים

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

[עריכה] פיתוח אלגוריתמים

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

[עריכה] ניתוח אלגוריתמים

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

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

[עריכה] עיצוב ותכנות

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

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