הנדסת תוכנה – הבדלי גרסאות

תוכן שנמחק תוכן שנוסף
מ ניסוח
שורה 30:
* יש המסווגים את פיתוח התוכנה כענף מדעי־מתמטי. ואכן, כל מערכות התוכנה מבוססות על יסודות [[אלגוריתם|אלגוריתמיים]], וחלקן משתמשות בנוסף בענפים שונים של ה[[מתמטיקה שימושית|מתמטיקה השימושית]]. בתהליך פיתוח התוכנה משמשות לעתים שיטות מתמטיות מתחום [[מדעי המחשב]], כגון יעילות אלגוריתמים, מודלים של חישוב ושיטות ל[[אימות תוכנה]]. אף על פי כן, '''הנדסת תוכנה אינה ענף של המתמטיקה''', וידע מתמטי עמוק אינו מבטיח כלל ועיקר את איכות התוכנה. אדרבא, השיטות הפורמליות הקיימות משמשות ל[[אימות תוכנה]] ולא לתכנונה. זאת ועוד, שיטות האימות הקיימות אינן מסוגלות להתמודד עם המורכבות וסדרי הגודל של מערכות התוכנה המודרניות, ובנוסף מוגבלות בשל חסמים תאורטיים מובנים (ראו גם [[בעיית העצירה]]). יש לזכור כי חלקים מהותיים בתהליך פיתוח התוכנה הם עיצוביים באופיים{{הערה|1=W.R. Reitman (1964). '''Heuristics Decision Procedures, Open Constraints, and the Structure of Ill-Defined Problems'''}} ומתבססים על איסוף וארגון מידע שאינו פורמלי או מוגדר־היטב,{{הערה|1=V. Goel (1995). '''Sketches of Thought''', The MIT Press, Cambridge MA}} ופירוש והמרת אלה ל[[שפת מחשב]] כלשהי.
* יש המסווגים את פיתוח התוכנה כמקצוע הדורש [[אומנות|עבודת אומן]]{{הערה|1=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."}} או אפילו כ[[אמנות]].{{הערה|1=לדוגמה, [[דונלד קנות']] מחבר סדרת הספרים The Art of Computer Programming, המחזיק בתואר "פרופסור לאומנות תכנות המחשב"}} ואכן, תהליך פיתוח התוכנה חולק איכויות מסוימות עם תהליך היצירה האמנותית, כגון [[אבסטרקציה (מדעי המחשב)|הפשטה]], [[אסתטיקה]], דרגות חופש גבוהות ועוד. במקרים רבים, העוסקים בתחום חותרים לפתח פתרונות שיהיו אסתטיים, נוסף על היותם מעשיים. בדומה למקצועות אחרים הדורשים עבודת אומן שיטתית (לדוגמה [[אדריכלות]]), גם מקצוע פיתוח התוכנה דורש תקופה ארוכה של [[חניכות]] אצל בעל מקצוע ותיק. עם זאת, יש הטוענים כי הגישה האומנותית לבדה אינה מספיקה לפיתוח שיטתי של תוכנה בקנה מידה גדול.
* יש המסווגים את פיתוח התוכנה כתהליך של יצירת [[קניין רוחני]]. לפי גישה זו, פיתוח תוכנה הוא ביסודו בעיה [[אמפיריציזם|אמפירית]], ולא ניתן לפתור אותה בשיטות המתבססות על חיזוי או תכנון.{{הערה|1=[[קן שוואבר|Schwaber, K.]]; Beedle, M. (2002). "Agile Software Development with Scrum". Prentice-Hall, ISBN 0130676349.}} המצדדים בגישה זו מדמים את פיתוח התוכנה ל[[משחק]] של שיתוף פעולה מוכוון־מטרה, בדומה ל[[טיפוס הרים]].{{הערה|1=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."}} גישה זו שמה דגש רב על סביבת עבודה מתאימה, [[אוסמוזה|זרימת מידע אוסמוטית]] בין חברי הצוות, ו[[תקורה]] פורמלית־טקסית נמוכה. עקרונות אלה מיושמים במתודולוגיות [[פיתוח תוכנה זריז|פיתוח תוכנה זריזוֹת]] כגון [[Extreme Programming|XP]] ו־[[Scrum]]. עם זאת, יש הטוענים כי גישה זו לבדה אינה מתאימה לפיתוח מערכות קריטיות, או כאלה המחייבות צוותי פיתוח גדולים.
 
===השוואה לתחומים קרובים===