stanford-oval/wikipedia huggingface dataset:
הנדסת תוכנה
תחומי הליבה > תהליכי הנדסת תוכנה > מתודולוגיות איטרטיביות

Unified Process (או בקיצור UP) היא מתודולוגיה ששורשיה בעבודתו של בארי בם והורחבה על ידי פיליפ קרוצ'טן, גריידי בוץ' ואחרים. המתודולוגיה הוצגה לראשונה בין השנים 1995–1998. UP אינה מתודולוגיה במובן הקלאסי, כי אם מסגרת מתודולוגית שניתן להרחיבה ויש להתאימה לארגון או פרויקט מסוים. UP היא מתודולוגיה איטרטיבית המורה על פיתוח תוכנה בתהליך מחזורי רב-שלבי. המתודולוגיה שמה דגש על ניהול הפרויקט, ניהול השינוי, הארכיטקטורה ותהליכי המידול של התוכנה. ייחודה של UP הוא בדרכים המובנות בה המאפשרות להתאימה לסוגים וגדלים רבים של פרויקטים לפיתוח תוכנה, החל מפרויקטים קטנים ולא-קריטיים ועד לפרויקטי-ענק לפיתוח מערכות קריטיות תומכות-חיים. הטכניקות העיקריות של המתודולוגיה כוללות פיתוח מחזורי תחום-בזמן, ניהול השינוי באמצעות כלי ניהול שינויים ובקרת תצורה, ניהול הדרישות ומידול ויזואלי באמצעות UML.
תחומי הליבה > תהליכי הנדסת תוכנה > מתודולוגיות זריזות

מתודולוגיה זריזה (באנגלית: Agile) לפיתוח תוכנה היא מתודולוגיה איטרטיבית שהותאמה לפיתוח תוכנה בצוותים קטנים תוך שימת דגש על יעילות, זריזות ואיכות. משפחה זו מקבלת בברכה שינויים במפרטי התוכנה, ומתייחסת לפיתוח כאל משחק של שיתוף פעולה מוכוון-מטרה (בדומה לטיפוס הרים). המתודולוגיות במשפחה זו שמות דגש רב על סביבת עבודה מתאימה, זרימת מידע אוסמוטית בין חברי הצוות, ותקורה פורמלית־טקסית נמוכה. עקרונות היסוד של משפחה זו נקבעו במשותף על ידי רבים מהמובילים בחקר וביישום מערכות תוכנה, ופורסמו ברבים במנשר לפיתוח תוכנה זריז.
eXtreme Programming (או בקיצור XP) היא מתודולוגיה שפותחה על ידי קנט בק, ומתוארת בספרו eXtreme Programming Explained שיצא לאור בשנת 2000, ובספרים נוספים שצצו בעקבותיו. שמה ניתן לה בשל העובדה שהשיטות המשמשות אותה הן מחמירות מאוד, ובעת פרסומה נחשבו כקיצוניות יחסית לשיטות הקיימות בתעשייה. המתודולוגיה, כפי שרומז שמה, מפרטת שורה של טכניקות בתחום התכנות ופחות בתחומים אחרים של הנדסת תוכנה. מערכות המפותחות לפיה הן גמישות מאוד לשינויים, וניתן להרחיבן בקלות ובאופן בטוח. כדי להשיג גמישות זו, XP משתמשת בשיטת תכנות מונחה-בדיקות שעיקריה הם כתיבת דרישות המערכת כסט של בדיקות הניתנות להרצה, ופיתוח הבדיקות קודם לפיתוח הפונקציונליות. שיטה זו דורשת הבנה טובה של עקרונות תכנות מונחה-עצמים ומשמעת עצמית גבוהה.
Crystal Clear היא מתודולוגיה שפותחה על ידי אליסטר קוברן ועקרונותיה מתוארים בספרים שפרסם החל משנת 1998. מתודולוגיה זו שמה דגש על יעילות בפיתוח ומפגינה סגלתנות רבה לשוני בדרכי העבודה האנושיות כפי שאלה מתבטאות בפיתוח תוכנה על ידי מתכנתים. המתודולוגיה מפרטת עקרונות לתכנות נכון אך מתמקדת יותר בעיצוב התוכנה וניהול הפרויקט. המתודולוגיה מתאימה לצוותים קטנים המפתחים תוכנה שאינה תומכת-חיים. ייחודה של Crystal Clear הוא בקלות היחסית שניתן להתאימה לאילוצים המופיעים פעמים רבות בפרויקטים לפיתוח תוכנה (לדוגמה, העדרו של לקוח), ובמסגרת נוחה להרחבה גם לצוותים גדולים יותר.
Scrum היא מתודולוגיה זריזה לניהול פרויקטים לפיתוח תוכנה שפותחה על ידי קן שוואבר ואחרים. הדגש היסודי של השיטה הוא על צוותים המכווינים את עצמם, וכן על תהליך נסיוני (אמפירי) מחזורי שאינו מוגדר מראש. המונח "Scrum" מקורו במשחק הרוגבי, שם הוא מתאר את הדרך שבה המשחק מתחיל מחדש לאחר שהכדור יצא מהמגרש. הטכניקה של "התחלה מחדש" היא אחת מאבני היסוד של השיטה – פרויקט Scrum מתחיל את תהליך הפיתוח כל חודש מחדש. כלומר, פעם בחודש מסופקת תוכנה עובדת למשתמשים, והערותיהם, כמו גם הדרישות החדשות, מיושמות במחזורי הפיתוח העוקבים. מקובל להשתמש ב־Scrum כמעטפת לניהול פרויקטים המפותחים במתודולוגיית XP ומתודולוגיות זריזות אחרות.
תחומי הליבה > דרישות תוכנה

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

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

במדעי המחשב, המושג בניית תוכנה (באנגלית: Software build, או בקיצור Build) מתייחס לתהליך של הפיכת קובצי קוד מקור לתוצרי תוכנה עצמאיים (Standalone) הניתנים להרצה על מחשב. כמו כן, המושג יכול להתייחס גם לתוצר עצמו של תהליך זה. אחד השלבים העיקריים של בניית תוכנה הוא תהליך ההידור (קומפילציה), בו קובצי קוד מקור הופכים לקוד הניתן להרצה (Executable code).
תחומי הליבה > בדיקות תוכנה

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

בדיקת תוכנה היא התהליך המסייע לוודא את הנכונות, השלמות, רמת האבטחה והאיכות של מערכת תוכנה באמצעות איתור שגיאות וכשלים המתרחשים בעת הרצת התוכנה, כלומר, השוואת פלט התוכנה לערכים צפויים כלשהם.
תחום בדיקות התוכנה הוא נגזרת של דיסציפלינת הבטחת איכות המקובלת בכל ענפי ההנדסה, ושם דגש על המאפיינים הייחודיים של מערכות תוכנה. בענפי ההנדסה, תוצר איכותי הוא כזה העומד, בגמר תהליך הייצור, בדרישות שהוגדרו. לעומת זאת, בהנדסת תוכנה אין תהליכי ייצור וברוב המכריע של המקרים לא ניתן לפרט מראש ובאופן מדויק את הדרישות מהתוכנה, קל וחומר את מפרטה המדויק (ראו גם אימות), דבר המקשה על פירוש מדויק של המונח 'איכות תוכנה'.
מתחילת המאה ה-21 גובר השימוש בשיטות פורמליות-למחצה להגברת דיוק המפרט. שיטות אלה מיושמות בפיתוח מונחה-בדיקות בשילוב תרחישי שימוש, בתכנות מוכוון היבטים ובמתודולוגיית פיתוח התוכנה Evo.
ישנם שני סוגי בדיקות: כאלה הסוקרות את ההתנהגות החיצונית של התוכנה, וכאלה הסוקרות את ההתנהגות הפנימית של התוכנה. הגישה השיטתית לבדיקות תוכנה מנוסחת במודל ה-V שבו מוגדרים סוגי הבדיקות ותהליכי הבדיקה המתאימים לכל תוצר עיקרי בפיתוח – החל מבדיקות יחידה המפותחות כחלק ממשימות התכנות השוטפות, וכלה בבדיקות קבלה הנמשכות לרוב זמן ארוך ומחייבות היערכות נרחבת מצד גורמים רבים. היקף וסוג הבדיקות, כמו גם מיקומן במחזור הפיתוח של התוכנה, נקבעים כחלק ממתודולוגיית הפיתוח המשמשת בפרויקט. בחלק מהמתודולוגיות, מקומן של הבדיקות הוא בסוף תהליך הפיתוח (לדוגמה מפל-המים). באחרות, בדיקות התוכנה הן לב לבו של תהליך התכנות (לדוגמה XP).
פרק זה לוקה בחסר. אנא תרמו לוויקיפדיה ו. ייתכן שתמצאו פירוט בדף השיחה.
כלים ושיטות בהנדסת תוכנה > בדיקות > בדיקות פונקציונליות

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

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

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

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