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

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

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

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

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

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

היסטוריה[עריכת קוד מקור | עריכה]

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

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

סקירה[עריכת קוד מקור | עריכה]

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










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

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

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

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

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

  • עד אמצע שנות ה-90, העדיפו רוב העובדים בתחום לתאר מקצועם כ-"תוכניתן", "מתכנת" או "מְפַ‏תֵח". במשך הזמן, התגנב גוון שלילי למונח "מתכנת", והוא החל לשמש כינוי לאלה שאין להם הכלים, הכישורים, ההשכלה או האתיקה הדרושים לפיתוח תוכנה איכותית. בעקבות זאת, החלו חלק מאנשי המקצוע לכנות את עצמם "מהנדסי תוכנה", וחברות רבות החליפו, לעתים בן-לילה, את התארים "מתכנת" ו-"מפתח תוכנה" בתואר "מהנדס תוכנה".{{הערה|שם=Dijkstra93}} עם זאת, ההבחנה בין המונחים אינה מקובלת על כולם ויש הדבקים במונחים המקוריים.{{הערה|שם=Salah02}} מחלוקת זו הוסיפה על הבלבול הקיים באשר להגדרה המדויקת של הנדסת התוכנה.
  • בקרב מהנדסים בתחומים המסורתיים של ההנדסה (ובפרט איגוד המהנדסים האזרחיים של ארצות הברית, NSPE), יש הטוענים כי להם זכויות ייחודיות על המונח "הנדסה", וכי השימוש במונח זה דורש את אישורם. ואכן, ב-48 מבין מדינות ארצות הברית, השימוש בתואר "מהנדס תוכנה" אסור על מי שלא הוסמך על ידי ה-NSPE. עם זאת, אנשי מקצוע רבים, אוניברסיטאות רבות ואף לשכת הסטטיסטיקה של משרד העבודה האמריקני (en) משתמשים במונח "מהנדס תוכנה" בחופשיות כדי לתאר את העוסקים בתחום תכנות המחשבים.
  • ה-ACM מתנגד לשימוש במונח "מהנדס תוכנה" ולרישוי העוסקים בתחום. על פי ה-ACM, מהנדס תוכנה מורשה (בדומה למהנדס בניין הרשום בפנקס המהנדסים) יתפס בציבור כמי שמחזיק בידע והכישורים הדרושים לבניית תוכנה אמינה, עקבית ושימושית, למרות שהנדסת תוכנה אינה בשלה דיה כדי להבטיח זאת.[2]

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

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

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

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

מדעי המחשב[עריכת קוד מקור | עריכה]

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

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

המקצוע[עריכת קוד מקור | עריכה]

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

הסמכה[עריכת קוד מקור | עריכה]

תעסוקה[עריכת קוד מקור | עריכה]

הישגים[עריכת קוד מקור | עריכה]

כשלונות[עריכת קוד מקור | עריכה]

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

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

דרישות[עריכת קוד מקור | עריכה]

Postscript-viewer-shaded.png ערך מורחב – דרישות תוכנה

תכנון[עריכת קוד מקור | עריכה]

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

Postscript-viewer-shaded.png ערך מורחב – תכנות

תצורה[עריכת קוד מקור | עריכה]

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

Postscript-viewer-shaded.png ערך מורחב – בדיקות תוכנה

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.[10]

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.[11] 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 5–10× 10× 10–100×
Architecture - 10× 15× 25–100×
Construction - - 10× 10–25×

מושגים[עריכת קוד מקור | עריכה]

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

סוגי בדיקות[עריכת קוד מקור | עריכה]

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

תחזוקה[עריכת קוד מקור | עריכה]

Postscript-viewer-shaded.png ערך מורחב – תחזוקת תוכנה

ראו גם[עריכת קוד מקור | עריכה]

קישורים[עריכת קוד מקור | עריכה]

הערות שוליים[עריכת קוד מקור | עריכה]

{{הערות שוליים|הערות=[1][2]

ניווט[עריכת קוד מקור | עריכה]

ערכים בהנדסת תוכנה
הנדסת תוכנה
P computing.svg
פורטל מחשבים
מושגים בהנדסת תוכנה
נושאים עיקריים
פיתוחבדיקותתפעולתחזוקה
  1. ^ 1.0 1.1 1.2 טקסט ההערה
  2. ^ 2.0 2.1 2.2 טקסט ההערה
  3. ^ 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. "
  4. ^ W.R. Reitman (1964). Heuristics Decision Procedures, Open Constraints, and the Structure of Ill-Defined Problems
  5. ^ V. Goel (1995). Sketches of Thought, The MIT Press, Cambridge MA
  6. ^ 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."
  7. ^ לדוגמה, דונלד קנות' מחבר סדרת הספרים The Art of Computer Programming, המחזיק בתואר "פרופסור לאומנות תכנות המחשב"
  8. ^ Schwaber, K.; Beedle, M. (2002). "Agile Software Development with Scrum". Prentice-Hall, ISBN 0130676349.
  9. ^ 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."
  10. ^ Software errors cost U.S. economy $59.5 billion annually, NIST report
  11. ^ McConnell, Steve (2004). Code Complete (מהדורה שנייה). Microsoft Press. עמ' 29. ISBN 0-7356-1967-0.