הנדסת תוכנה
מתוך ויקיפדיה, האנציקלופדיה החופשית
| הערך נמצא בשלבי עריכה הנכם מתבקשים שלא לערוך ערך זה בטרם תוסר הודעה זו כדי למנוע התנגשויות עריכה. שימו לב! אם דף זה לא נערך במשך שבוע, רשאי כל ויקיפד להסיר את התבנית ולהמשיך לערוך אותו. |
הנדסת תוכנה היא הפעילות ההנדסית העוסקת בפיתוח יעיל ושיטתי של תוכנה איכותית.
הנדסת תוכנה היא מקצוע רב־תחומי העוסק בפיתוח ותחזוקה של יישומי תוכנה על־ידי יישום של מדעי המחשב, עקרונות הנדסיים, ניהול פרויקטים, ידע רלוונטי לתחום הבעיה וכישורים וטכנולוגיות אחרות. כבכול הנדסה, גם בהנדסת תוכנה נעשה שימוש במדדים המשמשים לבחינת איכותו של תוצר הפיתוח כגון יעילות, אמינות, גמישות לשינויים וכדומה.
התחום מאופיין בפיתוח מערכות מידע מורכבות הכוללות לרוב תוכנה, חומרה ותקשורת. דוגמאות כוללות יישומים עסקיים מורכבים, מערכות הפעלה, מערכות זמן־אמת, מערכות משובצות־מחשב, תווכה, וכדומה.
תוכן עניינים |
[עריכה] הגדרה של הנדסת תוכנה
[עריכה] המונח "הנדסת תוכנה"
המונח הנדסת תוכנה מפורש כיום במספר דרכים שונות ונבדלות:
- כינוי בן־זמננו למגוון הפעילויות שבעבר נודעו כתכנות וניתוח מערכות.
- מונח רחב המתאר את כל ההיבטים המעשיים של תכנות מחשבים. זאת, בניגוד לתאוריה של תכנות מחשבים הידועה גם כמדעי המחשב.
- מונח המגלם גישה מסוימת לתכנות מחשבים, דהיינו, התייחסות לתכנות מחשבים כמקצוע הנדסי ולא כאומנות או אמנות.
- לפי תקן IEEE 610.12, הנדסת תוכנה היא "(1) החלה של גישה שיטתית, ממושמעת ובת־מדידה לפיתוח, תפעול ותחזוקה של תוכנה, כלומר, החלה של הנדסה על תוכנה; (2) לימוד הגישות השונות ל־(1)."
[עריכה] הנדסה, מדע או אמנות?
קיימת מחלוקת ארוכת שנים בשאלת סיווגו של מקצוע הנדסת התוכנה כענף של ההנדסה, המדע או האמנות. במידה רבה, המחלוקת נובעת מגילו הצעיר של המקצוע ומחוסר הגיבוש של השיטות המשמשות בו.
- יש המסווגים את פיתוח התוכנה כענף מובהק של ההנדסה. המצדדים בגישה זו מצביעים על השיטות המשותפות לדיסציפלינות אלה, כגון איסוף וניהול דרישות, תיכנון ומבדקים. מאידך, המצדדים בגישה זו נוטים להמעיט בחשיבות העדר המרכיב הייצורי והפיסי של הנדסה, שאינו קיים כלל בהנדסת תוכנה.
- לרוב, הגישה הנאיבית להנדסת תוכנה מבלבלת בין התוצר ההנדסי לפיתוחו, ומבקשת לייחס את איכות התוצר ההנדסי לתהליכי הפיתוח של התוכנה. דהיינו, כשם שהתוצר ההנדסי (לדוגמה מטוס) עומד בקריטריונים מחמירים של יעילות, עמידות ודיוק, כך גם תהליכי פיתוח התוכנה עצמם חייבים לעמוד בקריטריונים דומים. גישה זו מיושמת גם במתודולוגיית פיתוח התוכנה הידועה כמודל מפל־המים (ראה בהמשך) המורה על פיתוח תוכנה בתהליך קווי, חד־כיווני הדומה לפס־ייצור של מוצר הנדסי.
- יש המסווגים את פיתוח התוכנה כענף מדעי־מתמטי. ואכן, כל מערכות התוכנה מבוססות על יסודות אלגוריתמיים, וחלקן משתמשות בנוסף בענפים שונים של המתמטיקה השימושית. בתהליך פיתוח התוכנה משמשות שיטות מתמטיות מתחום מדעי המחשב, כגון יעילות אלגוריתמים, מודלים של חישוב ושיטות לאימות תוכנה. אף על פי כן, פיתוח התוכנה עצמו אינו תהליך שיטתי־מתמטי, וידע מתמטי עמוק אינו מבטיח כלל ועיקר את איכות התוכנה. אדרבא, השיטות הפורמליות הקיימות אינן מסוגלות להתמודד עם המורכבות וסדרי הגודל של מערכות התוכנה כיום, ובנוסף מוגבלות בשל חסמים תאורטיים מובנים (ראו גם בעיית העצירה). יש לזכור כי חלקים מהותיים בתהליך פיתוח התוכנה מתבססים על איסוף וארגון מידע שאינו פורמלי, פירושו והמרתו לשפת מחשב כלשהי. בכל מקרה, לא קיימות שיטות להוכחת נכונות האיפיון ביחס לדרישות עצמן.
- יש המסווגים את פיתוח התוכנה כמקצוע הדורש עבודת אומן או אפילו כאמנות. ואכן, תהליך פיתוח התוכנה חולק איכויות מסוימות עם תהליך היצירה האמנותית, כגון הפשטה, אסתטיקה, דרגות חופש גבוהות ועוד. במקרים רבים, העוסקים בתחום חותרים לפתח פתרונות שיהיו אסתטיים, נוסף על היותם מעשיים. בדומה למקצועות אחרים הדורשים עבודת אומן שיטתית (לדוגמה צורפות), גם מקצוע פיתוח התוכנה דורש תקופה ארוכה של חניכות אצל בעל מקצוע ותיק. עם זאת, הגישה האומנותית לבדה אינה מספיקה לפיתוח שיטתי של תוכנה בקנה מידה גדול.
- יש המסווגים את פיתוח התוכנה כתהליך של יצירת קניין רוחני. לפי גישה זו, פיתוח של תוכנה איכותית מחייב תהליך פיתוח שאינו הדיר בהכרח והוא מוכוון-אנשים וכאוטי-מסודר באופיו. גישה זו שמה דגש רב על סביבת עבודה מתאימה, זרימת מידע אוסמוטית בין חברי הצוות, ותקורה פורמלית־טקסית נמוכה. עקרונות אלה מיושמים כיום במתודולוגיות פיתוח תוכנה זריזוֹת כגון XP ו־Crystal Clear (ראה בהמשך). עם זאת, גישה זו לבדה אינה מתאימה לפיתוח מערכות קריטיות, או כאלה המחייבות צוותי פיתוח גדולים.
[עריכה] הנדסת תוכנה לעומת תכנות
קיימת חפיפה מסוימת בין הנדסת תוכנה לתכנות גרידא. שתי הדיסציפלינות עוסקות בצד המעשי של פיתוח תוכנה, אך הנדסת תוכנה עוסקת בפן השיטתי ובמחזור הפיתוח השלם, ואילו תכנות עוסק בקידוד ופיתוח התוכנה. הטבלה הבאה מפרטת את ההבדלים העיקריים בין שתי הדיסציפלינות:
| נושא | הנדסת תוכנה | תכנות |
|---|---|---|
| מיקוד | תכנות הקשור ליישום מסוים | תכנות ולעיתים hacking ללא תלות ביישום מסוים |
| הקשר עסקי | שיתוף פעולה עם מומחים לתחום העסקי | דגש על עבודה אישית |
| גודל הצוות | בודדים עד צוותים גדולים | דגש על יחידים |
| בדיקות | שיטתיות, אוטומטיות - מבדיקות יחידה, דרך בדיקות מערכת ועד מבדקי קבלה | בדיקות מעטות וידניות, לעיתים בדיקות יחידה |
| קריטיות המערכת | כל סוגי המערכות, כולל מערכות קריטיות ומערכות תומכות־חיים | מערכות לא קריטיות |
[עריכה] הנדסת תוכנה לעומת מדעי המחשב
כדרכה של פעילות הנדסית, גם הנדסת תוכנה נלמדת בבתי ספר להנדסה. בין הנדסת תוכנה למדעי המחשב יש חפיפה מסוימת, כשהמבדיל ביניהם הוא שמדעי המחשב נוטים למחקר התיאורטי של פעולת המחשב, ואילו הנדסת תוכנה נוטה לצד המעשי של תחום זה, עם דגש על מתודולוגיות לפיתוח תוכנה. להדגשת ההיבט התאורטי של מדעי המחשב, אמר אחד מהבולטים בו, אדסחר דייקסטרה: "מדעי המחשב אינם עוסקים במחשב יותר משאסטרונומיה עוסקת בטלסקופ". הטבלה הבאה מפרטת את ההבדלים בין שתי הדיסציפלינות:
| נושא | הנדסת תוכנה | מדעי המחשב |
|---|---|---|
| אידאל | פיתוח מערכות תוכנה | גילוי אמיתות כלליות אודות חישוביות, אלגוריתמים ונושאים תאורטיים נוספים |
| דגש | פיתוח תוכנה בעלת ערך למשתמש | אמיתות כלליות, כגון סיבוכיות ונכונות של אלגוריתמים |
| מטרה | תוכניות שימושיות כגון מהדר, מערכות מידע, מערכות בקרה, חבילת יישומים משרדיים | אלגוריתמים כגון אלגוריתמים למיון, בעיות מופשטות כגון בעיית הסוכן הנוסע |
| תקציב ולוח זמנים | תקציב ולוחות זמנים קבועים מראש | תקציבי מחקר ותחרותיות כפי שמקובל באקדמיה |
| ידע נוסף | הנדסה, ניהול פרויקטים, הכרת תחום היישום, ידע בתחומים טכנולוגיים נוספים | מתמטיקה |
| חוקרים ידועים | בארי בוהם, גריידי בוץ' | אלן טיורינג, ג'ון פון נוימן, אדסחר דייקסטרה, דונלד קאנות', דוד הראל, עדי שמיר |
| עוסקים ידועים | לינוס טורבאלדס, ריצ'רד סטולמן, מרטין פולר, דן בריקלין | לא רלוונטי |
[עריכה] הנדסת תוכנה לעומת הנדסה מסורתית
מהנדסי תוכנה שואפים לבנות מוצרים זולים, אמינים ובטוחים, בדומה לעוסקים במקצועות ההנדסה המסורתיים. מהנדסי תוכנה שואלים מטפורות וטכניקות רבות מדסציפלינות ההנדסה המסורתית, לרבות איסוף וניתוח דרישות, הבטחת איכות וטכניקות לניהול פרויקטים. מהנדסים מסורתיים שואלים גם הם כלים ופרקטיקות מהנדסת התוכנה. עם זאת, שתי הדסציפלינות נבדלות, כפי שמתואר להלן:
| נושא | הנדסת תוכנה | הנדסה מסורתית |
|---|---|---|
| יסודות | מבוססת על מדעי המחשב ומתמטיקה בדידה | מבוססת על פיזיקה, כימיה וחשבון דיפרנציאלי ואינטגרלי |
| עלות | לרוב, עלויות הפיתוח ההנדסי והייעוץ מגיעות ליותר ממחצית העלות הכוללת. כלי העבודה כגון מהדרים ומחשבים הם זולים | עלויות הבניה והייצור הן גבוהות, ועלות הפיתוח ההנדסי היא קטנה יחסית |
| שכפול | שכפול תוכנה הוא טריוויאלי. רוב מאמץ הפיתוח מושקע בפיתוח ותכנון מערכות חדשות (לא מוכחות) או בהרחבה של מערכות קיימות | רוב מאמץ הפיתוח מושקע בשכפול של תיכנונים ידועים ומוכחים על ידי ייצור ובניה |
| אורך חיים | דגש על פתרונות בעלי אורך חיים של שנים בודדות או עשור או שניים לכל היותר | דגש על פתרונות בעלי אורך חיים של עשרות שנים ולעיתים אף מאות שנים (סכרים וגשרים, לדוגמה) |
| סטאטוס ניהולי | מהנדסי תוכנה אינם מנהלים אנשים אחרים בדרך כלל. לרוב, מהנדסי תוכנה אינם נחשבים כמנהלים | מהנדסים מסורתיים מנהלים צוותי בניה, ייצור ותחזוקה. רוב המהנדסים המסורתיים נחשבים כמנהלים |
[עריכה] תחומים ושיטות
[עריכה] מתודולוגיה
מתודולוגיה (או תפיסת פיתוח) היא התחום העוסק בחקר וביישום של עקרונות לפיתוח תוכנה באופן שיטתי. המונח מתודולוגיה בהנדסת תוכנה פירושו סט מוסכם של עקרונות, תהליכים, פעילויות וכלים על פיהם מפותחות ומתוחזקות מערכות תוכנה. בתחום הנדסת התוכנה יש כיום כתריסר מתודולוגיות עיקריות (קרי, שפורסמו ברבים וזכו לקבלה מסוימת בתעשיה) המחולקות למספר משפחות נבדלות. המתודולוגיות נבדלות בתשובתן להשערה היסודית של הנדסת תוכנה ("מהי הנדסת תוכנה?") ועקרונות היסוד, המיקוד (ניהול פרויקט, ארכיטקטורה, עיצוב ותכנות, בדיקות), הטכניקות ובהיבטים נוספים. בשל גילו הצעיר של המקצוע ובשל ריבוי המתודולוגיות אין עדיין הסכמה בענף באשר למידת התאמתן של מתודולוגיות מסוימות לבעיות מסוימת, ובמקרים רבים אין כלל מודעות לחשיבות בחירת מתודולוגיה המתאימה לסוג הבעיה.
- ערך מורחב – מתודולוגיות לפיתוח תוכנה
[עריכה] מתודולוגיות קוויות
- תכנת ותקן (ידועה גם בשם מהר ומלוכלך) היא המתודולוגיה המקובלת ביותר לתחזוקת מערכות תוכנה כיום, ובמידה מסוימת גם לפיתוח מערכות חדשות. מתודולוגיה זו שמה דגש רב על המהירות שבה נעשים שינויים ותיקונים למערכת התוכנה, תוך התעלמות מודעת מנושאי התחזוקתיות והאיכות הפנימית של התוכנה. מתודולוגיה זו מאפשרת הוספה מהירה של פונקציונליות חדשה למערכת, אך מחייבת חיזוק של המבנים הפנימיים של התוכנה מעת לעת וערכת בדיקות מקיפה. ללא האחרונים, שימוש עקבי במתודולוגיה זו יגרום בהכרח לשחיקה מעריכית באיכות הפנימית של התוכנה, עד לנקודה שבה עלות הוספת פונקציונליות חדשה שווה או גדולה לעלות בניית התוכנה כולה מחדש, שלאחריה אין הצדקה כלכלית להמשיך לתחזק את התוכנה.
- מפל-המים (ידועה גם בשם מודל מפל-המים) היא מתודולוגיה ותיקה ורווחת לפיתוח מערכות תוכנה. המתודולוגיה הוצעה לראשונה על־ידי וינסטון רויס במאמר שפורסם בכתב העת Proceedings of IEEE בשנת 1970. בהקשרה ההיסטורי, המתודולוגיה נתפסה כתגובה לשיטות אד הוק של 'תכנת-ותקן' שרווחו מאוד בשנות ה־60 של המאה ה־20 (ועדיין רווחות). במודל מפל-המים, פיתוח התוכנה מתבצע בתהליך שיטתי ולוגי המורכב משלבים מוגדרים־היטב שאין לפסוח עליהם. השלבים מבוצעים בטור, אחד אחרי השני, ובכל שלב יש מיקוד במשימה עיקרית אחת בלבד. יש דגש רב על איסוף וניתוח של כל הדרישות כולן קודם לתחילת הפיתוח, ואין חזרה לאחור בתהליך לאחר ששלב מסוים בו הסתיים. השלבים העיקריים בשיטה זו הם איסוף וניתוח דרישות, עיצוב, מימוש, בדיקות, שילוב, התקנה ותחזוקה.
- ערך מורחב – מודל מפל-המים
[עריכה] מתודולוגיות איטרטיביות
- Unified Process (או בקיצור UP) היא מתודולוגיה ששורשיה בעבודתו של בארי בוהם והורחבה על ידי פיליפ קרוצ'טן, גריידי בוץ' ואחרים. המתודולוגיה הוצגה לראשונה בין השנים 1995-1998. UP אינה מתודולוגיה במובן הקלאסי, אם כי מסגרת מתודולוגית שניתן להרחיבה ויש להתאימה לארגון או פרויקט מסוים. UP היא מתודולוגיה איטרטיבית המורה על פיתוח תוכנה בתהליך מחזורי רב-שלבי. המתודולוגיה שמה דגש על ניהול הפרויקט, ניהול השינוי, הארכיטקטורה ותהליכי המידול של התוכנה. ייחודה של UP הוא בדרכים המובנות בה המאפשרות להתאימה לסוגים וגדלים רבים של פרויקטים לפיתוח תוכנה, החל מפרויקטים קטנים ולא-קריטיים ועד לפרויקטי-ענק לפיתוח מערכות קריטיות תומכות-חיים. הטכניקות העיקריות של המתודולוגיה כוללות פיתוח מחזורי תחום-בזמן, ניהול השינוי באמצעות כלי ניהול שינויים ובקרת תצורה, ניהול הדרישות ומידול ויזואלי באמצעות UML.
- ערך מורחב – Unified Process
[עריכה] מתודולוגיות זריזות
מתודולוגיה זריזה (באנגלית: Agile) לפיתוח תוכנה היא מתודולוגיה איטרטיבית שהותאמה לפיתוח תוכנה בצוותים קטנים תוך שימת דגש על יעילות, זריזות ואיכות. ביסודה, משפחה זו מתייחסת לפיתוח תוכנה כאל משחק של שיתוף פעולה מוכוון-מטרה (בדומה לטיפוס הרים)[1]. המתודולוגיות במשפחה זו שמות דגש רב על סביבת עבודה מתאימה, זרימת מידע אוסמוטית בין חברי הצוות, ותקורה פורמלית־טקסית נמוכה. עקרונות היסוד של משפחה זו נקבעו במשותף על־ידי רבים מהמובילים בחקר וביישום מערכות תוכנה, ופורסמו ברבים באתר האינטרנט agilemanifesto.org.
- eXtreme Programming (או בקיצור XP) היא מתודולוגיה שפותחה על ידי קנט בק, ומתוארת בספרו eXtreme Programming Explained שיצא לאור בשנת 2000, ובספרים נוספים שצצו בעקבותיו. שמה ניתן לה בשל העבודה שהשיטות המשמשות אותה הן חמורות מאד, ובעת פרסומה נחשבו כקיצוניות יחסית לשיטות הקיימות בתעשיה. המתודולוגיה, כפי שרומז שמה, מפרטת שורה של טכניקות בתחום התכנות ופחות בתחומים אחרים של הנדסת תוכנה. מערכות המפותחות לפיה הן גמישות מאוד לשינויים, וניתן להרחיבן בקלות ובאופן בטוח. כדי להשיג גמישות זו, XP משתמשת בשיטת תכנות מונחה-בדיקות שעיקריה הם כתיבת דרישות המערכת כסט של בדיקות הניתנות להרצה, ופיתוח הבדיקות קודם לפיתוח הפונקציונליות. שיטה זו דורשת הבנה טובה של עקרונות תכנות מונחה-אובייקטים ומשמעת עצמית גבוהה.
- ערך מורחב – Extreme Programming
- Crystal Clear היא מתודולוגיה שפותחה על ידי אליסטר קוברן ועקרונותיה מתוארים בספרים שפרסם החל משנת 1998. מתודולוגיה זו שמה דגש על יעילות בפיתוח ומפגינה סגלתנות רבה לשוני בדרכי העבודה האנושיות כפי שאלה מתבטאות בפיתוח תוכנה על ידי מתכנתים. המתודולוגיה מפרטת עקרונות לתכנות נכון אך מתמקדת יותר בעיצוב התוכנה וניהול הפרויקט. המתודולוגיה מתאימה לצוותים קטנים המפתחים תוכנה שאינה תומכת-חיים. ייחודה של Crystal Clear הוא בקלות היחסית שניתן להתאימה לאילוצים המופיעים פעמים רבות בפרויקטים לפיתוח תוכנה (לדוגמה, העדרו של לקוח), ובמסגרת נוחה להרחיבה גם לצוותים גדולים יותר.
- ערך מורחב – Crystal Clear
- Scrum היא מתודולוגיה זריזה לניהול פרויקטים לפיתוח תוכנה שפותחה על ידי קן שוואבר ואחרים. המונח "Scrum" מקורו במשחק הרוגבי, שם הוא מתאר את הדרך שבה המשחק מתחיל מחדש לאחר שהכדור יצא מהמגרש. הטכניקה של "התחלה מחדש" היא אחת מאבני היסוד של השיטה - פרויקט Scrum מתחיל את תהליך הפיתוח כל חודש מחדש. כלומר, פעם בחודש מסופקת תוכנה עובדת למשתמשים, והערותיהם, כמו גם הדרישות החדשות, מיושמות במחזורי הפיתוח העוקבים. כיום מקובל להשתמש ב־Scrum כמעטפת לניהול פרויקטים המפותחים במתודולוגיית XP ומתודולוגיות זריזות אחרות.
- ערך מורחב – Scrum
[עריכה] ארכיטקטורה
ארכיטקטורה היא התחום העוסק בתיכנון מערכות תוכנה. המונח ארכיטקטורה בהנדסת תוכנה פירושו ייצוג היבטים שונים של התוכנה באופן מופשט. ארכיטקטורה של מערכות תוכנה היא לפיכך תכנון מפושט של ההיבטים השונים של התוכנה, היחסים בין המרכיבים השונים של התוכנה והחוקים החלים עליהם. מחקרים ראשונים בתחום זה נעשו כבר בשנות ה־60 של המאה ה־20, אבל חשיבותו עלתה מאוד החל משנות ה־80 בשל הגודל והמורכבות של מערכות התוכנה (ראה גם משבר התוכנה). ארכיטקטורה מתמקדת בהגדרת ההיבטים הלא-פונקציונליים של התוכנה, השלד, הממשקים החיצוניים והיבטים נוספים שאינם קשורים רק לקוד. הגדרת המבנים הפנימיים של התוכנה שייכת לתחום העיצוב והתכנות אם כי גם היא מכונה לעיתים ארכיטקטורה. ראוי לציין שאין עדיין הסכמה בתעשיה באשר להיבטים השונים של התוכנה הנדרשים להכלל כחלק מהארכיטקטורה, אם כי יש דרך מתוקננת לתיאור חלק מההיבטים באמצעות שפת המידול המאוחדת UML.
- ערך מורחב – ארכיטקטורת תוכנה
[עריכה] שלד ומבנה
תחום העוסק בשלד התוכנה ובמבנים בקנה מידה בינוני וגדול, יכולת ההרחבה של המבנה ומידת גמישותו לשינויים.
- גמישות לשינויים - היבט העוסק ביכולת לשנות את התוכנה בתגובה לשינויים בדרישות או בשל דרישות חדשות. מחקרים בתחום[2] מצאו שקשה מאוד לשנות מערכות תוכנה לאחר שאלה נמסרו ללקוח. לשם השוואה, שינוי המתבצע בתוכנה לאחר שנמסרה עולה בממוצע פי 200 משינוי המתבצע בזמן האיפיון[3]. לפיכך, הגישה המסורתית לפיתוח תוכנה שמה דגש רב על תכנון תוכנה גמישה, כלומר, תכנון מבני התוכנה באופן כללי ומופשט ככל שניתן. תכנון כזה, אם הוא מצליח לחזות את המקומות בהן תורחב התוכנה, מאפשר את שינוי והרחבת התוכנה באופן קל ובטוח. עם זאת, הניסיון בתעשיה מלמד שמידת הצלחתו של הליך תכנוני זה היא מוגבלת, ומתודולוגיות הפיתוח הזריזות אף ממליצות נגד חלקים מהותיים בו[4].
- יכולת הרחבה וגידול - מערכות תוכנה נדרשות פעמים רבות להגדיל את תפוקת העבודה שלהן בשל גידול צפוי או בלתי-צפוי, רגעי או קבוע באירועי הקלט (לדוגמה, מספר המשתמשים המחוברים למערכת). לפיכך, דגש רב מושם על תכנון מבנה התוכנה באופן שיאפשר את הגדלת התפוקה שלה בעתיד, עם שינויים קטנים ככל שניתן בהיבטי הארכיטקטורה השונים, במבנה הפנימי או במערכות המחשב עצמן.
[עריכה] ממשקים
תחום העוסק באופן שבו התוכנה מתקשרת עם מערכות חיצוניות אחרות, לרבות אנשים. תכנון הממשקים הוא היבט קריטי של מערכת התוכנה מכיוון שזהו הנתיב שדרכו מגיעים אירועים חיצוניים לתוכנה, וכן הצינור שדרכו תפוקת העבודה של התוכנה זורמת החוצה. טיב ממשקי התוכנה משפיע באופן ישיר על תגובתיות התוכנה, קלות החיבור של התוכנה למערכות אחרות, קלות השימוש והנגישות, אורך החיים של התוכנה והסתגלנות שלה לשינויים עתידיים. בשנים האחרונות חלה התקדמות רבה בחלק מההיבטים של תחום ארכיטקטוני זה, והוגדרו בתעשיה דרכים מתוקננות לקישוריות ופעילות הידודית בין מערכות (ראה גם Web Services). כמו כן, חל גיבוש בעקרונות ובשיטות המשמשים בתחום הקישוריות ואלה חוסים כיום תחת המטריה של ארכיטקטורה מוכוונת-שירותים (SOA).
[עריכה] אמינות
תחום העוסק במדידה ותכנון מנגנונים להבטחת האמינות של התוכנה, כלומר נכונות הפלט בכל מצבי התוכנה. התחום קשור באופן הדוק לתחום הבדיקות ולהיבטי הבדיקוּת של התוכנה. עקרונות התחום והשיטות המתמטיות המשמשות בו מקורם בדיסצפלינות ההנדסה המסורתית. עם זאת, בניגוד לדיסצפלינות קרובות (לדוגמה, הנדסת אלקטרוניקה), במערכות תוכנה (אפילו קטנות) מספר הקומבינציות של הקלטים והמצבים עלול להיות אסטרונומי ולפיכך קיים קושי רב להוכיח באופן מתמטי את נכונות התוכנה ומאפייני האמינות שלה. עם זאת, גם בהנדסת תוכנה נהוגות שיטות לאיסוף וניתוח דרישות אמינות, תכנון לאמינות ובעיקר מימוש מונחה-אמינות.
באופן מעשי, יישום מערכת תוכנה אמינה מסתמך על מנגנוני חומרה מתאימים (כגון הרצה זהה במקביל), מערכות תווכה מתאימות (כגון מסד נתונים, מערכת ניהול תנועות ועוד), ספריות פיתוח בדוקות, טכניקות קידוד שונות וערכת בדיקות מקיפה. במערכות תוכנה קריטיות או תומכות-חיים, מתווספים גם תהליכי אימות פורמליים לחלקים בתוכנה, לפרוטוקולים המשמשים בה ולאלמנטים נוספים. במקרים נדירים, רכיבים קריטיים בתוכנה אף מפותחים על ידי שני צוותים נפרדים, ואלה פועלים יחדיו בזמן ריצה, תוך השוואה מתמדת של הפלטים.
[עריכה] זמינות
תחום העוסק בזמינותה של מערכת תוכנה ומכלול השירותים המסופקים על ידה. עקרונות התכנון של היבט זה מקורם בעיקר בדיסצפלינות הנדסה אחרות. זמינות המערכת מושפעת באופן ישיר מהאופן שבו התוכנה מוצבת בסביבת המחשוב, המשאבים העומדים לרשותה ואופן ניהולם. מערכות הנדרשות לעמוד ברמת שירות גבוהה מחייבות תכנון קפדני של זיהוי, ניהול והתאוששות מכשלים במערכת. לרוב, היבטים אלה באים לידי ביטוי בכל רמות התוכנה (והחומרה), מרמת המבנים המערכתיים ועד לרמת הטיפול בשגיאות בקוד.
- זיהוי וניהול כשלים - היבט העוסק בדרכים לזהות אירועים חריגים בתוכנה ובניהולם, אחרי שנתגלו. אירוע חריג בהקשר זה הוא שגיאה תכנותית שלא נצפתה מראש (באג), כשל במערכות עזר או כשל במערכות המחשב עצמן. עקרונות הנדסיים של יתירות ובידוד כשלים הם חלק מעקרונות היסוד המשמשים לתכנון היבט זה.
- התאוששות מאסון - היבט העוסק בשחזור פעילות התוכנה לאחר שהתרחש אירוע כלשהו שמונע ממערכות המחשב והתוכנה לתפקד. בדרך כלל מדובר על אירוע חיצוני שאינו באחריות המערכת, כגון נתק מתמשך במערכות החשמל, שריפה, הצפה וכדומה.
- המשכיות עסקית - היבט העוסק בניתוח והגדרה של תהליכים עסקיים ומחשוביים הדרושים כדי להמשיך ולהפעיל את מערכות המחשוב של הארגון לאחר שהתרחש אירוע כלשהו.
[עריכה] ביצועים
תחום העוסק בתפוקת העבודה המועילה של התוכנה, מדידתה ובדרכים להגדיל תפוקה זו בעתיד. היבט זה בא לידי ביטוי בכל רמות התוכנה, האלגוריתמים, המבנה הפנימי ואיכות הקוד.
- תכנון קיבולת - היבט העוסק בבניית מודל לחישוב כמות משאבי החומרה הנדרשים כדי לתמוך בעומס הצפוי על התוכנה. במערכות תוכנה חדשות, קשה לבנות מודל מדויק קודם להפעלת התוכנה ויש להשתמש בגישה איטרטיבית המטייבת את המודל תוך כדי הפיתוח. בהתאם לתוצאות המודל, נרכשות מערכות המחשוב הנדרשות. במקרים מסוימים, המודל אף משמש להקצאה דינמית של משאבי החומרה בסביבת הייצור. לעומת זאת, תוכנות מדף ותיקות מספקות כמעט תמיד כלים מדויקים לתכנון קיבולת המערכת.
- הסכמי שירות - היבט העוסק במדידת התפוקה המועילה של התוכנה והשוואתה לערכים צפויים כלשהם, בדרך כלל כדי להבטיח את תגובתיות התוכנה עבור צרכן או צרכנים מסוימים.
[עריכה] אבטחת מידע
שומר מקום.
[עריכה] תפעול
- תצורה - תצורה בהנדסת תוכנה היא מכלול הדרכים להתקנת התוכנה, התקנת תיקונים, ותחזוקה שוטפת לאורך מחזור החיים השלם של התוכנה. תכנון התצורה כולל התיחסות להפצת התוכנה למערכת או מערכות היעד, אתחול המערכת, דריכה ראשונית של פרמטרים, גיבוי ושיחזור התצורה ובקשר של ניהול התצורה להיבטי הניטור והבקרה של התוכנה.
- ניטור ובקרה - היבט העוסק בניהול התוכנה אחרי שהיא מופעלת. כדי לאפשר את השליטה והבקרה על התוכנה, יש לתכנן כיצד התוכנה תספק מידע על מצבה למפעילים אנושיים או למערכות אחרות ואת הדרך שבה תקבל התוכנה הוראות תפעוליות מגורמים אלה. תכנון היבט זה נוגע בעיקר לממשקים החיצוניים של התוכנה ולרוב אינו משפיע על המבנה הפנימי של התוכנה. ניהול יעיל של תוכנה מתייחס לתחומים רבים כגון: ביצועים, תצורה, טיפול בתקלות, שחזור תקלות, תפעול ועוד. טיב היבט זה משפיע באופן ישיר על רמת השירות שהתוכנה מספקת.
- גיבוי ושחזור - היבט העוסק בגיבוי ושחזור המידע שבאחריות התוכנה. כיום, מערכות תוכנה רבות מנהלות נפחים גדולים של מידע במסדי נתונים יחסיים. היבט זה עוסק בעיקר בתכנון הדרכים לגיבוי המידע, אירכובו ושיחזורו במקרה הצורך, לדוגמה אחרי ששגיאה בתוכנה גרמה להשחתת מידע.
[עריכה] אלגוריתמיקה
אלגוריתמיקה היא התחום המגשר בין המודל המתמטי של בעיה נתונה לבין פתרונה באמצעות מחשב. אלגוריתמיקה היא תחום יסודי במדעי המחשב ובהנדסת תוכנה, והיא עוסקת במציאת פתרונות לבעיות חישוביות באמצעות אלגוריתמים ומבני נתונים. אלגוריתמיקה מתמקדת בפיתוח מודל מתמטי המתאר, בדרגות שונות של דיוק, את הבעיה שהתוכנה המפותחת אמורה לפתור. בהנדסת תוכנה, אלגוריתמים מתוארים לרוב באמצעות פסבדו-קוד, שהוא ייצוג מופשט של שפת תכנות, ונסמכים על מודל חישובי כלשהו, בדרך כלל זה המייצג מכונת טורינג קלאסית. השימוש באלגוריתמים ומבני נתונים יסודיים אינו נחשב חלק מתחום האלגוריתמיקה, אלא מהווה חלק בלתי נפרד מעבודתו של המתכנת.
- ערך מורחב – אלגוריתמיקה
[עריכה] אלגוריתמים ומבני נתונים יסודיים
תחום העוסק ביישום של אלגוריתמים ומבני נתונים יסודיים בספריות פיתוח וכחלק משפת תכנות מסוימת. עם התקדמות המחקר והפיתוח בתחום האלגוריתמיקה, נצברו מספר רב של תוצאות שימושיות, דהיינו, אלגוריתמים ומבני נתונים נפוצים החוזרים ומופיעים כמעט בכל תוכנה. תחום זה עוסק בארגון ואיסוף תוצאות אלה, תכנון ממשקי תכנות מופשטים ופשוטים המאפשרים התייחסות אחידה לסוגים קרובים של אלגוריתמים ומבני נתונים, ומימוש ממוטב ככל האפשר של האלגוריתמים. ספריות פיתוח טובות מספקות מבחר גדול ומתועד של אלגוריתמים ומימושים הממוטבים לצרכים שונים (זמן-ריצה, זיכרון וכדומה). התחומים שלהלן מכוסים כיום (במידה כלשהי) על ידי ספריות פיתוח המובנות ברוב שפות התכנות המודרניות:
- מבני נתונים - לצרכים שונים, כגון תור, מחסנית, רשימה מקושרת, עץ, טבלת גיבוב וערימה.
- מיון וחיפוש - אלגוריתמים למיון וחיפוש בנתונים ומחרוזות כגון מיון מהיר וחיפוש בינארי.
- בקרת ריצה מקבילית - מבני נתונים לבקרה על פעילויות מקביליות כגון סמפור, מנעול קריאה/כתיבה ותור הפצה.
- גרפים - אלגוריתמים לטיפול בתורת הגרפים כגון מציאת נתיבים, פרישׂת עצים וזרימה מקסימלית.
- דחיסה - אלגוריתמים לדחיסה ופרישה של נתונים.
- הצפנה - אלגוריתמים להצפנה של נתונים, חתימה דיגיטלית וכדומה. נוסף על כך, מבני נתונים ואלגוריתמים יעילים לטיפול בפעולות אריתמטיות על מספרים גדולים מאד.
[עריכה] פיתוח אלגוריתמים
שומר מקום.
[עריכה] ניתוח אלגוריתמים
תחום העוסק בניתוח היעילות של אלגוריתמים, כלומר, קביעת כמות המשאבים הנדרשת להרצת אלגוריתם נתון. לרוב, יעילותו של אלגוריתם מנוסחת כפונקציה המקשרת בין אורך הקלט לבין מספר הצעדים (סיבוכיות זמן) או שטחי האחסון (סיבוכיות מרחב או זיכרון) הנדרשים להרצתו.
- שיערוך של אלגוריתם הוא שיטה העוסקת בהערכת סדר-הגודל של יעילות האלגוריתם (הערכה אסימפטוטית). כלומר, הערכת היעילות כאשר אורך הקלט הוא גדול במידה סבירה. הכלים המתמטיים שפותחו בתחום זה מאפשרים להעריך את יעילותו התיאורטית של אלגוריתם במנותק ממימוש מסוים, ומקלים על בחירתו של אלגוריתם מתאים לבעיה חישובית נתונה. מאידך, הערכת סדר גודל היא מדויקת רק עד כדי קבועים מפורשים או חבויים הקשורים למימוש מסוים, ולעיתים אינה מספיקה כדי לבחור בין אלגוריתמים.
- ניתוח מדויק של אלגוריתם מחייב הנחה בדבר המודל החישובי המסוים המשמש למימוש האלגוריתם. ניתן להגדיר מודל חישובי באופן מופשט, לדוגמה מכונת טורינג, או על ידי הנחות בדבר משך הזמן הדרוש להרצת פעולות מסוימות. לתכנות ממוטב של אלגוריתם נדרש תמיד ניתוח מדויק. במערכות זמן-אמת לדוגמה, שיערוך אסימפטוטי הוא גס מכדי לבחור אלגוריתם ליישום ממוטב של מתזמן.
[עריכה] עיצוב ותכנות
תחום העוסק במבנה הפנימי של התוכנה, תת-המערכות והרכיבים שלה, והיחסים השונים ביניהם. תחום זה הוא קרוב לוודאי המסובך ביותר בהנדסת התוכנה מפאת הדרכים הרבות והשונות לפתרון בעיה נתונה. דהיינו, יש שוני רב בפתרונות האפשריים לבעיה, בכל הנוגע לסוג המבנים הפנימיים, מספרם, סדר הופעתם והיחסים ביניהם. יתר על כן, בניגוד לתחומי ההנדסה המסורתית שבהם יש תשתית מתמטית תיאורטית ואמפירית לתכנון המבנה, אין בהנדסת תוכנה תשתית כזו. העוסקים בתחום נאלצים להשתמש במערכת של עקרונות, כללי-אצבע ותבניות עיצוב, ולהסתמך על ניסיון רב כדי לתכנן את המבנה הנכון במסגרת האילוצים של מערכת התוכנה. כיום מקובל לתאר את המבנים הפנימיים בשיטות מוכוונות-אובייקטים ובאמצעות שפת המידול המאוחדת UML, תבניות עיצוב ועוד.
- ערך מורחב – עיצוב ותכנות תוכנה
[עריכה] תכנות
שומר מקום.
[עריכה] תבניות עיצוב
שומר מקום.
[עריכה] מודל ומטא-מודל
שומר מקום.
[עריכה] ניהול תצורה
ניהול תצורה הוא תחום העוסק בבקרה שיטתית על מצב, מיקום וגרסת הפריטים המעורבים בפיתוח תוכנה. התחום הוא נגזרת של דיסצפלינת ניהול התצורה המקובלת בכל ענפי ההנדסה, ושם דגש על המאפיינים הייחודיים של מערכות תוכנה.
- ערך מורחב – ניהול תצורת תוכנה
[עריכה] ניהול תצורת קוד המקור
בעיה עיקרית בפיתוח תוכנה, ובייחוד בפיתוח תוכנה בקנה מידה גדול, היא ניהול השינויים ובקרת התצורה. במהלך הפיתוח, נעשים באופן שגרתי מאות אלפים, מיליונים ולעיתים אף מאות מיליונים של שינויים בקוד המקור של התוכנה ופריטים אחרים. ניהול השינויים ובקרת תצורה הן למעשה שיטות, תהליכים וכלים לארגון ומעקב אחר שינויים אלו.
[עריכה] בנייה
שומר מקום.
[עריכה] בדיקות
בדיקת תוכנה היא התהליך המסייע לוודא את הנכונות, השלמות, רמת האבטחה והאיכות של מערכת תוכנה באמצעות איתור שגיאות וכשלים המתרחשים בעת הרצת התוכנה, כלומר, השוואת פלט התוכנה לערכים צפויים כלשהם.
תחום בדיקות התוכנה הוא נגזרת של דיסצפלינת הבטחת איכות המקובלת בכל ענפי ההנדסה, ושם דגש על המאפיינים הייחודיים של מערכות תוכנה. בענפי ההנדסה, תוצר איכותי הוא כזה העומד, בגמר תהליך הייצור, בדרישות שהוגדרו. לעומת זאת, בהנדסת תוכנה אין תהליכי ייצור וברוב המכריע של המקרים לא ניתן לפרט מראש ובאופן מדויק את הדרישות (ראה גם הנדסת תוכנה לעומת הנדסה מסורתית), דבר המקשה על פירוש מעשי של המונח 'איכות תוכנה'.
- ערך מורחב – הבטחת איכות תוכנה
ישנן שתי סוגי בדיקות: כאלה הסוקרות את ההתנהגות החיצונית של התוכנה, וכאלה הסוקרות את ההתנהגות הפנימית של התוכנה. הגישה השיטתית לבדיקות תוכנה מנוסחת במודל ה-V שבו מוגדרים סוגי הבדיקות ותהליכי הבדיקה המתאימים לכל תוצר עיקרי בפיתוח - החל מבדיקות יחידה המפותחות כחלק ממשימות התכנות השוטפות, וכלה בבדיקות קבלה הנמשכות לרוב זמן ארוך ומחייבות היערכות נרחבת מצד גורמים רבים. היקף וסוג הבדיקות, כמו גם מיקומן במחזור הפיתוח של התוכנה, נקבעים כחלק ממתודולוגיית הפיתוח המשמשת בפרויקט. בחלק מהמתודולוגיות, מקומן של הבדיקות הוא בסוף תהליך הפיתוח (לדוגמה מפל-המים). באחרות, בדיקות התוכנה הן לב לבו של תהליך התכנות (לדוגמה XP).
- ערך מורחב – בדיקות תוכנה
[עריכה] בדיקות פונקציונליות
בדיקות המשוות את פלט התוכנה לערכים צפויים כלשהם. בדיקות אלה מכונות בדיקות "קופסה שחורה" מכיוון שאינם בוחנות כיצד מבצעת התוכנה את הנדרש ממנה אלא רק את תוצאות הפלט.
- בדיקות יחידה - בדיקות ברמת יחידת המערכת הקטנה ביותר המאמתות את פעילותה התקינה של היחידה. לרוב מדובר על בדיקה של פרוצדורה, מחלקה, קבוצה קטנה של מחלקות הפועלות בתיאום או תת-מערכת קטנה. סבירות התקינות של היחידה הנבדקת תלויה במספר נתיבי הריצה הנבדקים מתוך סה"כ נתיבי הריצה האפשריים. בפועל, בדיקות יחידה איכותיות מכסות בדרך-כלל הנתיב העיקרי של הריצה, הטיפול העיקרי בשגיאות ומקרי קצה בולטים בקלט. כתיבת בדיקות היחידה היא באחריותו של מתכנת היחידה הנבדקת והן לרוב נכתבות באותה שפת-תכנות. כיום מקובלים מספר כלים המסייעים לכתיבה וארגון בדיקות היחידה, שהעיקרי בהם הוא xUnit.
- בדיקות נסיגה - בדיקות לשם השוואת יכולות וביצועים בין גרסאות שונות של אותה תוכנה. מטרת בדיקות הנסיגה היא לוודא כי כל תפקודי התוכנה ויכולותיה מהגרסאות הקודמות לא נפגעו כתוצאה משינויים בגרסה הנוכחית. תיאורטית, יש להריץ את כל תסריטי הבדיקה הקיימים עבור כל גרסת תוכנה, על מנת לוודא כי לא חלה נסיגה בהתנהגות התוכנה או בביצועיה. למעשה, ניתן לצמצם את כמות הבדיקות על ידי ניהול תהליך בדיקות מונחה סיכונים ועל ידי ניתוח השינויים הכלולים בגרסה האחרונה והשפעתם על רכיבים ותהליכים שונים בתוכנה הנבדקת. עם זאת, צמצום כזה כרוך בסיכון מסוים להחמצת נסיגה קיימת בתפקוד התוכנה (בשל השפעות בלתי צפויות של השינויים).
[עריכה] בדיקות לא-פונציונליות
בדיקות הבוחנות את איכות הארכיטקטורה של התוכנה, כלומר את איכות המאפיינים הלא-פונקציונליים של התוכנה כגון ביצועים, תגובתיות, שימושיות וכדומה. הגישה השיטתית לבחינת הארכיטקטורה בודקת את כל סוגי ה-'ilities' של התוכנה.
[עריכה] בדיקות "קופסה לבנה"
בדיקות המניחות שקוד המקור של התוכנה זמין לבודק, ולפיכך ניתן לסקור את ההתנהגות הפנימית של התוכנה, נוסף על השוואת הפלט לערכים צפויים כלשהם.
- סקר קוד - הליך בו קוד המקור של התוכנה נבדק לגילוי הפרה של כללי אצבע בתכנות, טיפול בשגיאות והיבטים אחרים הקשורים לאיכות הקוד. חלק מסוים מבדיקה זו נעשה באמצעות כלים אוטומטיים לסקירת קוד, אך בשל אופיה הסמנטי של הבדיקה, רובה מתבצע באופן ידני על ידי קריאה שיטתית וביקורתית של קוד המקור (וההסברים הנלווים), בדרך כלל על ידי עמית מנוסה של כותב הקוד. בנוסף, נהוגים גם סקרי קוד הממוקדים בהיבטים קריטיים של מערכות תוכנה כגון אבטחת מידע וביצועים.
- סקר עיצוב - הליך בו נבדק המבנה הפנימי של התוכנה. בדיקה זו כוללת בדרך כלל סקירה של מבני הנתונים העיקריים של התוכנה (מודל), אלגוריתמים, פרוטוקולים, היבטים של ריצה בו-זמנית, מערכות עזר (לדוגמה מסד נתונים), היבטי הסדר של עיבוד הקלט והממשקים.
- סקר ארכיטקטורה - הליך בו נבדקת איכותם של ההיבטי הארכיטקטורה השונים ומאומתת התפיסה התפעולית של התוכנה בדגש על מחזור החיים השלם של התוכנה.
[עריכה] בדיקוּת
היבט העוסק ביכולת לבדוק את התוכנה בסביבה מבוקרת ומפוקחת. היכולת לבדוק תוכנה נתונה אינה מובנת מאליה ויש לתכנן, לעצב ולתכנת את התוכנה כדי שתאפשר זאת. הגישה המקובלת היא לפתח את התוכנה באופן שיאפשר את החלפת חלק, או לעיתים את כל, רכיבי התוכנה ברכיבי-דמי המפוקחים ומשופעלים על ידי סביבת הבדיקות. בדרך זו, ניתן לדמות בצורה מדויקת את הקשר-הריצה המתאים קודם לתחילת הבדיקה, להזריק נתוני קלט מדויקים, ולחלץ את הפלט מרכיבי הדמי לאחר ריצת-הבדיקה.
תוכנה המתאפיינת ברמת בדיקוּת גבוהה מתאפיינת כמעט תמיד גם ברמת הפשטה גבוהה, ניתוק צימודים במבנים פנימיים ורמת גרעיניות נכונה. עובדה זו הביאה לפיתוח טכניקת תכנות מונחה בדיקות שנוסף על פיתוח ערכת בדיקות מקיפה מביאה כבדרך אגב גם לשיפור מהותי באיכות התוכנה[5].
[עריכה] כיסוי
היבט העוסק בהגדרת הקלטים, המצבים ונתיבי הריצה שיש לבדוק בתוכנה, וכן בכלים המשמשים לבדיקות אלה. בדיקות כיסוי מאפשרות לבדוק אילו הצהרות ונתיבי ריצה בתוכנית בוצעו בעת הרצת מבדק מסויים, ובדרך זו לוודא שכל החלקים בתוכנה נבדקו. עם זאת, בשל המספר הרב של המצבים האפשריים בתוכנה, לא ניתן לבדוק את כולם ויש להתמקד באזורים ובמצבים אופיניים, כגון טיפול בשגיאות וכדומה.
[עריכה] מיכון
מיכון בדיקות תוכנה הוא היבט העוסק בשימוש בכלים לפיקוח על הרצת בדיקות תוכנה, השוואה שיטתית של תוצאות הפלט לערכים צפויים כלשהם ולהגדרה של הקשר הריצה המתאים ונתוני הקלט קודם לתחילת הבדיקה. מיכון הבדיקות הוא נדבך הכרחי בתחום בדיקות התוכנה בשל הקושי הרב לבדוק מערכות תוכנה באופן ידני על ידי בודקים אנושיים.
[עריכה] אימות
אימות תוכנה הוא תחום העוסק בהוכחה שתוכנה מסוימת נכונה (כלומר מבצעת בדיוק את מה שהוגדר במפרט שלה) או בעלת תכונות מסוימות.
בשל הקושי הרב באימות פורמלי של מערכות תוכנה מורכבות, ובשל העובדה שישנם חסמים תאורטיים המונעים אימות פורמלי מוחלט, ימשיכו מערכות תוכנה להיכשל גם בעתיד הנראה לעין. עם זאת, איכות התוכנה כיום רחוקה מרחק רב מהחסמים התאורטיים, וניתן לנקוט צעדים רבים כדי לשפר את איכותה.
- ערך מורחב – אימות תוכנה
[עריכה] ראו גם
[עריכה] לקריאה נוספת
ספרות בנושא מתודולוגיות פיתוח:
- Agile Software Development / Alistair Cockburn
- Agile Software Development Echo Systems / Jim Highsmith
- Dynamics of Software Development / Jim McCarthy
- Extreme Programming Explained / Kent Beck
- Software Engineering Economics / Barry Boehm
- The Mythical Man-Month / Fred Brooks
- The Rational Unified Process Made Easy / Philippe Kruchten et al
ספרות בנושא איסוף וניתוח דרישות:
- Software Requirements / Karl E. Wiegers
- User Stories Applied / Mike Cohn
- Writing Effective Use Cases / Alistair Cockburn
ספרות בנושא אלגוריתמים ומבני נתונים:
- Algorithm Design / Jon Klienberg et al
- Introduction to Algorithms / Thomas H. Cormen et al
ספרות בנושא בדיקות:
- Testing Computer Software / Cem Kaner et al
- Systematic Software Testing / Craig & Jaskiel
ספרות בנושא אימות:
- Software Reliability Methods / Doron A. Peled
- Systems and Software Verification / B. Berard et al
ספרות בנושא עיצוב:
- Domain-Driven Design / Eric Evans
- Enterprise Integration Patterns / Hohpe & Woolf
- Patterns of Enterprise Application Architecture / Martin Fowler
- Real-Time Systems / Albert M. K. Cheng
ספרות בנושא תכנות:
- Code Complete 2 / Steve McConnell
- Design Patterns / Gang of Four
- Object-Oriented Design Heuristics / Arthur J. Riel
- Refactoring / Martin Fowler et al
- Software Engineering: A Practitioner's Approach / Roger S. Pressman
- Test-Driven Development / Kent Beck
- The Art of Computer Programming / Donald E. Knuth
- The Pragmatic Programmer / Hunt & Thomas
- UML Distilled / Martin Fowler

