מבוא להנדסת תוכנה

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

מאמר זה הוא הראשון בסדרה המוקדשת ליסודות הנדסת תוכנה.

מבוא להנדסת תוכנה: הגדרה ומשמעות

תחילה נגדיר מהי הנדסת תוכנה. ההיסטוריה של הנדסת תוכנה מתחילה בשנות ה-60. ההגדרה שלה פשוטה למדי: הנדסת תוכנה היא דיסציפלינה הנדסית העוסקת בכל ההיבטים של ייצור תוכנה. מה זה אומר? בואו נפענח זאת.

תחום הנדסת התוכנה

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

• תכנון
• ניתוח
• פיתוח
• יישום
• תכנות
• עיצוב
• בדיקות
• V&V (אימות ותיקוף)

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

אם אנחנו מדברים על הנדסת תוכנה, זה רק טבעי שנגדיר גם את המונח "תוכנה". ויקיפדיה, בצטטה את תקן ISO/IEC 2382:2015, מגדירה תוכנה כ"קבוצה של תוכניות מחשב ותיעוד ונתונים נלווים. זאת בניגוד לחומרה, שממנה המערכת בנויה ואשר מבצעת את העבודה".

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

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

שכבות תוכנה

תוכנה היא מונח רחב ועשוי להיות מועיל לחלק אותה למספר שכבות. חלקן של שכבות אלה אינן בהכרח רלוונטיות למה שאנו עושים ב-Spyrosoft, אך טוב לקבל תמונה מלאה ולהבין את ההקשר של כל שכבה. קיימות שמונה שכבות:

חומרה

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

קושחה (BIOS)

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

Hypervisor

היפרוויזור הוא כלי חיוני לניהול תהליכי וירטואליזציה – מדובר בתוכנה שיוצרת ומריצה מכונות וירטואליות.

מערכת ההפעלה

ניתן לחלק זאת לזמן ריצה ומנהלי התקנים, שירותים ולבסוף ממשק משתמש. כולם מכירים מערכות הפעלה כגון Windows, Linux או Android וממשקי המשתמש הגרפיים שלהן. אנו רגילים לאינטראקציות ברמה גבוהה, למשל אנו לוחצים על סמל על שולחן העבודה ומשהו קורה. במציאות, לחיצת עכבר פשוטה כזו תפעיל בדרך כלל עיבוד רב ברכיבי תוכנה שונים. בואו נדמיין שאתם רוצים לשלוח הודעה לחבר באמצעות אחת מאפליקציות ההודעות הפופולריות. זה נראה ממש קל, נכון? פשוט הקלידו את ההודעה, לחצו ENTER והמתינו לתשובה. עם זאת, מתרחש הרבה יותר מאחורי הקלעים. בואו נפרק זאת немного:

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

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

Middleware

ה-middleware מכונה גם "דבק תוכנה". הוא מספק שירותים ליישומי תוכנה מעבר לאלה הזמינים מרמת מערכת ההפעלה. שירותי גישה למסדי נתונים מאופיינים לעתים קרובות כ-middleware. כדי לפשט את הדברים, ניתן לחשוב על middleware כיישומים ללא ממשק גרפי. middleware אינו כלי שניתן ללחוץ עליו. הוא פועל בצד ה-backend. ניתן לתקשר איתו, אך לא באופן שבו אתם כנראה רגילים – עכבר ומסך מגע לא יעבדו במקרה זה. middleware מגיב להודעה הנשלחת בפורמט מסוים דרך ערוץ תקשורת מוגדר, למשל פורט TCP/IP.

היישום

שכבת התוכנה האחרונה היא שכבת האפליקציה. אפליקציות משמשות את רובנו על בסיס יומיומי. דוגמה מושלמת לאפליקציה היא דפדפן web. דוגמאות נוספות הן MS Teams, Outlook או Excel.

פעילויות הנדסת תוכנה בסיסיות

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

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

2. פיתוחבאופן כללי, אם ברור מה התוכנה אמורה לעשות, ניתן להתחיל בשלב העיצוב והפיתוח.

3. אימותבשלב זה, התוכנה בפועל מאומתת מול המפרט המתאים.

4. אבולוציה: תוכנה רבה גוועת עם הזמן מכיוון שעסקים, שווקים ובהתאם לכך הצרכים של חברות והציפיות של משתמשי התוכנה משתנים. לפיכך, יש צורך לפתח באופן קבוע את התוכנה שפותחה. זהו תהליך שיכול להימשך שנים רבות מאוד (האם אתם זוכרים מתי פורסמה הגרסה הראשונה של מערכת ההפעלה Windows? בשנת 1985 והיא עדיין כאן)

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

הנדסת תוכנה לעומת מדעי המחשב

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

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

הנדסת מערכות לעומת הנדסת תוכנה

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

כדי להמחיש את המושג ולהתוות גבול בין החלק התוכנתי לחלק הלא-תוכנתי של המערכת, ניתן לבחון שתי דוגמאות:

No. 1 – מכונית מודרנית ומערכת ה-ABS שלה (מערכת בלימה נגד נעילה)

מבנה מפושט של מערכת כזו כולל:

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

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

מס' 2 – מערכת בנקאית לניהול הלוואות

מבלי להיות מומחה לבנקאות, אני יכול לתאר לעצמי, למשל:

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

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

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

ארכיטקטורת מערכת תוכנה גנרית

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

ארכיטקטורת התוכנה הפשוטה ביותר של מערכת תוכנה מודרנית היא ארכיטקטורת לקוח-שרת. קיימים שני מרכיבים חיוניים:

• הלקוח – לא האדם שמשתמש במחשב, אלא אפליקציה שרצה על אותו מחשב
• השרת – לא השרת הפיזי, אלא האפליקציה הפועלת על השרת שמסוגלת לעבד את הבקשות המגיעות מהלקוח.

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

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

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

ארכיטקטורה תלת-שכבתית

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

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

אז ניתן לתאר את שלוש השכבות בקצרה כדלקמן:

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

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

ללא שרת (ענן)

האם ניתן לקיים מערכת מודרנית ללא שרת? ארכיטקטורה ללא שרת (Serverless)?

במידה מסוימת, כן – הענן הוא מילת המפתח!

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

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

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

גמישות ומדרגיות עם מודל ענן

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

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

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

אם יש לכם עשרות אלפי משתמשים יומיים אך רק כמה מאות בלילה, תוכלו לנהל את המשאבים שלכם בהתאם, ומה שאתם משלמים עליו בסופו של דבר הוא רק כוח המחשוב שבו אתם באמת משתמשים. המשאב שאינכם צורכים במהלך הלילה יועבר למקום אחר ויצרך על ידי מי שמשלם עליו באותו הזמן. כך נוצרת ситуація win-win עבור לקוח הענן וספק הענן, והיא מובילה לניצול מיטבי של המשאבים.

יציבות

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

שלם לפי הצריכה שלך

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

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