משתמש:רנדום/ארגז חול/2

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

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

הנדסת תוכנה החלה להתגבש כתחום ייחודי בשנות ה-60 המאוחרות, על רקע משבר התוכנה. עד אותה עת נחשבה הנדסת התוכנה לענף משני של מדעי המחשב. כנס ראשון להנדסת תוכנה נערך בשנת 1968 על ידי ועדת המדע של נאט"ו,{{הערה|שם=Naur69}} וציין את תחילת דרכו של הענף כתחום נפרד ועצמאי. עם החלוצים בתחום נמנים פרד ברוקס, בארי בם, טוני הור ודייוויד פרנס. גרסה ראשונה של גוף הידע הרשמי של המקצוע הושלמה בשנת 1999, ובאותה השנה הוענק לפרד ברוקס פרס טיורינג על "תרומותיו פורצות הדרך בהנדסת מחשבים, מערכות הפעלה והנדסת תוכנה",{{הערה|שם=ACM99}} ושני האירועים נחשבים לאבני דרך חשובות בהתפתחות הענף. בארצות הברית, מסלול לימודים אקדמי להנדסת תוכנה (BSc) נפתח לראשונה בשנת 1996, ומסלול דומה מוצע גם בישראל. עם זאת, נכון לשנת 2006, לרוב העוסקים בתחום יש הכשרה אקדמית במדעי המחשב ולא בהנדסת תוכנה.{{הערה|שם=ACM06}}

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

היסטוריה

נושאים שיש לאזכר:

• משבר התוכנה
• OS/360
• UNIX

סקירה

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

נושאים שיש לאזכר:

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

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

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

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

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

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

• עד אמצע שנות ה-90, העדיפו רוב העובדים בתחום לתאר מקצועם כ-"תוכניתן", "מתכנת" או "מְפַ‏תֵח". במשך הזמן, התגנב גוון שלילי למונח "מתכנת", והוא החל לשמש כינוי לאלה שאין להם הכלים, הכישורים, ההשכלה או האתיקה הדרושים לפיתוח תוכנה איכותית. בעקבות זאת, החלו חלק מאנשי המקצוע לכנות את עצמם "מהנדסי תוכנה", וחברות רבות החליפו, לעתים בן-לילה, את התארים "מתכנת" ו-"מפתח תוכנה" בתואר "מהנדס תוכנה".{{הערה|שם=Dijkstra93}} עם זאת, ההבחנה בין המונחים אינה מקובלת על כולם ויש הדבקים במונחים המקוריים.{{הערה|שם=Salah02}} מחלוקת זו הוסיפה על הבלבול הקיים באשר להגדרה המדויקת של הנדסת התוכנה.

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

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

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

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

תחומי ליבה

דרישות

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

תכנות

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

בדיקות

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

Economics

A study conducted by NIST in 2002 reports that software bugs cost the U.S. economy $59.5 billion annually. More than a third of this cost could be avoided if better software testing was performed.

It is commonly believed that the earlier a defect is found the cheaper it is to fix it. The following table shows the cost of fixing the defect depending on the stage it was found. For example, if a problem in the requirements is found only post-release, then it would cost 10–100 times more to fix than if it had already been found by the requirements review. With the advent of modern continuous deployment practices and cloud-based services, the cost of re-deployment and maintenance may lessen over time.

Cost to fix a defect		Time detected
		Requirements	Architecture	Construction	System test	Post-release
Time introduced	Requirements	1×	3×	5–10×	10×	10–100×
	Architecture	-	1×	10×	15×	25–100×
	Construction	-	-	1×	10×	10–25×

מושגים

• בדיקות
• כיסוי
• נסיגה
• מיכון

תחזוקה

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

הערות שוליים

{{הערות שוליים|הערות=