עיצוב ותכנות הוא לב-ליבה של הנדסת התוכנה. התחום עוסק בתכנון וקידוד המבנה הפנימי של התוכנה, תת-המערכות והרכיבים שלה, מבני הנתונים והאלגוריתמים והיחסים השונים ביניהם. תחום זה הוא קרוב לוודאי המסובך ביותר בהנדסת התוכנה מפאת הדרכים הרבות והשונות לפתרון בעיה נתונה. דהיינו, יש שוני רב בפתרונות האפשריים לבעיה, בכל הנוגע לסוג המבנים הפנימיים, מספרם, סדר הופעתם והיחסים ביניהם. זאת ועוד, בתחום זה יש עושר גדול של שפות תכנות, ספריות, כלים ושיטות תכנות, שמהן יש לבחור את הנכונים לבעיה נתונה. בניגוד לתחומי ההנדסה המסורתית שבהם יש תשתית מתמטית איתנה המסייעת לתכנון המבנה, אין בהנדסת תוכנה תשתית כזו. העוסקים בתחום משתמשים במערכת של עקרונות, כללי-אצבע (כגון אפס אחד אינסוף) ותבניות עיצוב, ומסתמכים על ניסיון רב כדי לתכנן את המבנה הנכון במסגרת האילוצים של הארכיטקטורה והדרישות. מאז אמצע-סוף שנות ה-80 מקובל לתכנת את המבנים הפנימיים בשיטות מוכוונות-עצמים בהסתמך על תבניות עיצוב. לעיתים נעשה שימוש גם בשפת המידול המאוחדת UML לתכנון ותיעוד התוכנה. בתחום זה פועל המתכנת או מהנדס התוכנה.
בדיקות.
בדיקת תוכנה היא התהליך המסייע לוודא את הנכונות, השלמות, רמת האבטחה והאיכות של מערכת תוכנה באמצעות איתור שגיאות וכשלים המתרחשים בעת הרצת התוכנה, כלומר, השוואת פלט התוכנה לערכים צפויים כלשהם.
תחום בדיקות התוכנה הוא נגזרת של דיסציפלינת הבטחת איכות המקובלת בכל ענפי ההנדסה, ושם דגש על המאפיינים הייחודיים של מערכות תוכנה. בענפי ההנדסה, תוצר איכותי הוא כזה העומד, בגמר תהליך הייצור, בדרישות שהוגדרו. לעומת זאת, בהנדסת תוכנה אין תהליכי ייצור וברוב המכריע של המקרים לא ניתן לפרט מראש ובאופן מדויק את הדרישות מהתוכנה, קל וחומר את מפרטה המדויק (ראו גם אימות), דבר המקשה על פירוש מדויק של המונח 'איכות תוכנה'.
מתחילת המאה ה-21 גובר השימוש בשיטות פורמליות-למחצה להגברת דיוק המפרט. שיטות אלה מיושמות בפיתוח מונחה-בדיקות בשילוב תרחישי שימוש, בתכנות מוכוון היבטים ובמתודולוגיית פיתוח התוכנה Evo.
ישנם שני סוגי בדיקות: כאלה הסוקרות את ההתנהגות החיצונית של התוכנה, וכאלה הסוקרות את ההתנהגות הפנימית של התוכנה. הגישה השיטתית לבדיקות תוכנה מנוסחת במודל ה-V שבו מוגדרים סוגי הבדיקות ותהליכי הבדיקה המתאימים לכל תוצר עיקרי בפיתוח – החל מבדיקות יחידה המפותחות כחלק ממשימות התכנות השוטפות, וכלה בבדיקות קבלה הנמשכות לרוב זמן ארוך ומחייבות היערכות נרחבת מצד גורמים רבים. היקף וסוג הבדיקות, כמו גם מיקומן במחזור הפיתוח של התוכנה, נקבעים כחלק ממתודולוגיית הפיתוח המשמשת בפרויקט. בחלק מהמתודולוגיות, מקומן של הבדיקות הוא בסוף תהליך הפיתוח (לדוגמה מפל-המים). באחרות, בדיקות התוכנה הן לב לבו של תהליך התכנות (לדוגמה XP).
בדיקות פונקציונליות.
בדיקות המשוות את פלט התוכנה לערכים צפויים כלשהם. בדיקות אלה מכונות בדיקות "קופסה שחורה" מכיוון שאינם בוחנות כיצד מבצעת התוכנה את הנדרש ממנה אלא רק את תוצאות הפלט.
בדיקות לא-פונקציונליות.
בדיקות הבוחנות את איכות הארכיטקטורה של התוכנה, כלומר את איכות המאפיינים הלא-פונקציונליים של התוכנה כגון ביצועים, תגובתיות, שימושיות וכדומה. הגישה השיטתית לבחינת הארכיטקטורה בודקת את כל סוגי ה-'ilities' של התוכנה.
בדיקות "קופסה לבנה".
בדיקות המניחות שקוד המקור של התוכנה זמין לבודק, ולפיכך ניתן לסקור את ההתנהגות הפנימית של התוכנה, נוסף על השוואת הפלט לערכים צפויים כלשהם.
בדיקוּת.
היבט העוסק ביכולת לבדוק את התוכנה בסביבה מבוקרת ומפוקחת. היכולת לבדוק תוכנה נתונה אינה מובנת מאליה ויש לתכנן, לעצב ולתכנת את התוכנה כדי שתאפשר זאת. הגישה המקובלת היא לפתח את התוכנה באופן שיאפשר את החלפת חלק, או לעיתים את כל, רכיבי התוכנה ברכיבי-דמי המפוקחים ומשופעלים על ידי סביבת הבדיקות. בדרך זו, ניתן לדמות בצורה מדויקת את הקשר-הריצה המתאים קודם לתחילת הבדיקה, להזריק נתוני קלט מדויקים, ולחלץ את הפלט מרכיבי הדמי לאחר ריצת-הבדיקה.
תוכנה המתאפיינת ברמת בדיקוּת גבוהה מתאפיינת כמעט תמיד גם ברמת הפשטה גבוהה, ניתוק צימודים במבנים פנימיים ורמת גרעיניות נכונה, וזאת מכיוון שעליה לפעול באופן זהה בסביבת הריצה המיועדת וכן בסביבת הבדיקות. עובדה זו הביאה לפיתוח טכניקת פיתוח מונחה-בדיקות שנוסף על פיתוח ערכת בדיקות מקיפה מביאה כבדרך אגב גם לשיפור מהותי באיכות התוכנה.
כיסוי.
היבט העוסק בהגדרת הקלטים, המצבים ונתיבי הריצה שיש לבדוק בתוכנה, וכן בכלים המשמשים לבדיקות אלה. בדיקות כיסוי מאפשרות לבדוק אילו הצהרות ונתיבי ריצה בתוכנית בוצעו בעת הרצת מבדק מסוים, ובדרך זו לוודא שכל החלקים בתוכנה נבדקו. עם זאת, בשל המספר הרב של המצבים האפשריים בתוכנה, לא ניתן לבדוק את כולם ויש להתמקד באזורים ובמצבים אופייניים, כגון טיפול בשגיאות וכדומה.
מיכון.
מיכון בדיקות תוכנה הוא היבט העוסק בשימוש בכלים לפיקוח על הרצת בדיקות תוכנה, השוואה שיטתית של תוצאות הפלט לערכים צפויים כלשהם ולהגדרה של הקשר הריצה המתאים ונתוני הקלט קודם לתחילת הבדיקה. מיכון הבדיקות הוא נדבך הכרחי בתחום בדיקות התוכנה בשל הקושי הרב לבדוק מערכות תוכנה באופן ידני על ידי בודקים אנושיים.
אימות.
אימות תוכנה הוא תחום העוסק בהוכחה שתוכנה מסוימת היא נכונה או בעלת תכונות מסוימות. תוכנה "נכונה" בהקשר זה היא תוכנה המבצעת בדיוק את מה שהוגדר במפרט שלה. בהנדסת תוכנה, המונח אימות תוכנה מתייחס למגוון של טכניקות מתמטיות ומתמטיות-תכנותיות (להלן שיטות פורמליות) המאפשרות לייצג היבטים שונים של התוכנה באופן מדויק ובר-הוכחה. השימוש בטכניקות אלה מסייע להגביר את מידת האמינות והיציבות של התוכנה המפותחת, ולעיתים אף מפחית מעלויות הפיתוח הכוללות (דהיינו, אם אלה כוללות גם את תיקון הבאגים בשלב התחזוקה). עם זאת, בשל חסמים מעשיים ותאורטיים (ראו גם בעיית העצירה) בשיטות האימות הקיימות, ובשל הגודל והמורכבות של מערכות התוכנה המודרניות, לא ניתן לאמת מערכות תוכנה באופן מלא, והשיטות הפורמליות מוחלות לרוב רק על סוגים קריטיים של מערכות תוכנה, וגם אז רק על חלקים נבחרים בתוכנה (ראו גם בעיית התפוצצות מצבים).
רמות אימות.
השיטות הפורמליות נחלקות למספר רמות אימות:
אימות התוכנה.
המפרט הפורמלי משמש לבדיקת נכונות התוכנה, בשני היבטים:
תחומים תומכים.
ניהול פרויקטים.
ניהול פרויקטים הוא ענף במדעי הניהול העוסק בתכנון ובקרה של פרויקטים (מיזמים), לרוב בעלי מרכיב גבוה של אי-ודאות או סיכון כלכלי. פרויקט מוגדר כמאמץ תחום בזמן ליצירת שירות או מוצר או תוצאה ייחודית. הגדרה נוספת של פרויקט היא לקיחת תשומות משאבים ושינויים לתפוקות רצויות באמצעות מערכות ייצור.
מטרות ניהול הפרויקט הן סיומו של הפרויקט בלוח הזמנים הנדרש, עמידה ביעדי הפרויקט, באיכות הנדרשת, אי-חריגה מתקציב והשגת שביעות רצון הלקוח. פרויקטים אופייניים שניתן למצוא בארגונים מכוונים לרוב לשיפור מצבו התחרותי של הארגון באמצעות שיפור מועילות או היעילות שלו.
ניהול תצורה.
ניהול תצורה הוא תחום העוסק בבקרה שיטתית על מצב, מיקום וגרסת הפריטים המעורבים בפיתוח תוכנה. התחום הוא נגזרת של דיסציפלינת ניהול התצורה המקובלת בכל ענפי ההנדסה, ושם דגש על המאפיינים הייחודיים של מערכות תוכנה.
ניהול תצורת קוד המקור.
בעיה עיקרית בפיתוח תוכנה, ובייחוד בפיתוח תוכנה בקנה מידה גדול, היא ניהול השינויים ובקרת התצורה. במהלך הפיתוח, נעשים באופן שגרתי עשרות אלפים, מאות אלפים, ולעיתים אף עשרות מיליונים של שינויים בקוד המקור של התוכנה ופריטים אחרים. ניהול השינויים ובקרת תצורה הן למעשה שיטות, תהליכים וכלים לארגון ומעקב אחר שינויים אלו.
בנייה.
המונח בנייה בהנדסת תוכנה מתייחס לתהליך הממיר את קוד המקור של התוכנה (ופריטים נוספים) לקובץ בר-הרצה. במערכות פשוטות, לרוב מדובר על הידור וקישור של מספר קטן של קבצים המתבצע ישירות מסביבת הפיתוח. לעומת זאת, במערכות תוכנה גדולות תהליך הבנייה עשוי לכלול עשרות ומאות צעדים שונים המתבצעים בסדר מסוים ובמקביל, תוך שימוש במגוון של כלים. מתחילת שנות ה-90 מקובל להתייחס לבניית התוכנה כאל נדבך חיוני בפיתוח תוכנה, ויש אף המדמים אותו לדופק ליבו של אדם, המאפשר להעריך את מידת בריאותו של הפרויקט.
תיעוד.
תיעוד תוכנה או תיעוד קוד המקור הוא טקסט המלווה את התוכנה ומסביר כיצד זו פועלת או איך להשתמש בה. תיעוד הוא חלק חשוב בהנדסת תוכנה, אם כי מוזנח לעיתים.
ישנם מספר סוגי תיעוד:
משפחה
מִשׁפָּחָה היא מוסד חברתי המאגד יחידים בעלי קשרי שארות לקבוצה שיתופית הדוקה. במשמעות הנפוצה של מושג זה משפחה נוצרת על ידי זוג אנשים אשר נישאים זה לזה, וכוללת גם את ילדיהם. משפחה נוצרת גם ללא קשר רשמי של נישואים, כאשר בני הזוג הופכים לידועים בציבור. כאשר אחד מבני הזוג נפטר, או שבני הזוג מתגרשים או נפרדים, המשפחה הופכת למשפחה חד-הורית (מונח שהוחלף בשנת 2014 ל"משפחה שבראשה הורה עצמאי").
המשפחה כוללת שני אנשים או יותר הקשורים בקשרי לידה, נישואים או אימוץ, החיים יחד. במקורו, המושג משפחה מייצג קבוצה של בני אדם שיש להם קרבת אבות. הלשכה המרכזית לסטטיסטיקה מגדירה משפחה גרעינית כשני אנשים או יותר החולקים משק בית אחד וקשורים זה לזה כבעל ואישה, כזוג ללא נישואין או כהורה וילד.