הנדסת תוכנה

אנחנו מתחילים ממה שהצוות שלכם יכול להפעיל ולגייס עבורו, ממה שהמערכות האחרות שלכם משתמשות בו ומה שהתוכנה חייבת לעשות. עבור רוב התוכנה העסקית זה אומר שפה נפוצה כמו TypeScript, Java, C# או Python, מסד נתונים יחסי והענן שבו אתם כבר משתמשים. אנחנו מתעדים כל בחירה ואת נימוקיה.

לקריאה נוספת: הנדסת יישומים, פלטפורמות ומוצרים קומפוזבילייםקישור לשאלה הזו

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

לקריאה נוספת: הנדסת יישומים, פלטפורמות ומוצרים קומפוזבילייםקישור לשאלה הזו

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

לקריאה נוספת: הנדסת יישומים, פלטפורמות ומוצרים קומפוזבילייםקישור לשאלה הזו

אנחנו משתמשים ב-React עם Next.js ברוב היישומים החדשים, כי היא תומכת ברינדור בצד השרת ובעלת כלים חזקים. אנחנו עובדים גם עם Angular ו-Vue.js, וממשיכים במסגרת שבה אתם כבר משתמשים כשזו הבחירה ההגיונית.

לקריאה נוספת: הנדסת יישומים, פלטפורמות ומוצרים קומפוזבילייםקישור לשאלה הזו

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

לקריאה נוספת: הנדסת יישומים, פלטפורמות ומוצרים קומפוזבילייםקישור לשאלה הזו

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

לקריאה נוספת: הנדסת יישומים, פלטפורמות ומוצרים קומפוזבילייםקישור לשאלה הזו

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

לקריאה נוספת: הנדסת יישומים, פלטפורמות ומוצרים קומפוזבילייםקישור לשאלה הזו

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

לקריאה נוספת: הנדסת יישומים, פלטפורמות ומוצרים קומפוזבילייםקישור לשאלה הזו

אפליקציות נייטיביות ב-Swift וב-Kotlin נותנות את הגישה המלאה ביותר ליכולות המכשיר. אפליקציות חוצות פלטפורמות ב-React Native או ב-Flutter חולקות את רוב הקוד בין iOS ל-Android, מה שמוזיל את הבנייה ואת השינויים. אנחנו ממליצים על נייטיבי כשהאפליקציה תלויה מאוד במכשיר, ועל חוצה פלטפורמות לרוב אפליקציות העסק והצרכן.

לקריאה נוספת: נייד, מחשוב מרחבי ותאומים דיגיטלייםקישור לשאלה הזו

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

לקריאה נוספת: נייד, מחשוב מרחבי ותאומים דיגיטלייםקישור לשאלה הזו

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

לקריאה נוספת: נייד, מחשוב מרחבי ותאומים דיגיטלייםקישור לשאלה הזו

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

לקריאה נוספת: נייד, מחשוב מרחבי ותאומים דיגיטלייםקישור לשאלה הזו

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

לקריאה נוספת: UX והנדסת איכות אוטונומיתקישור לשאלה הזו

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

לקריאה נוספת: UX והנדסת איכות אוטונומיתקישור לשאלה הזו

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

לקריאה נוספת: UX והנדסת איכות אוטונומיתקישור לשאלה הזו

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

לקריאה נוספת: מודרניזציה של מערכות מדור קודם בקצב AIקישור לשאלה הזו

כן. אנחנו מתרגמים או בונים מחדש תוכניות COBOL כשירותים נייטיביים לענן, ומעבירים נתוני DB2 עם התאמה בכל שלב. עבודות אצווה וממשקי קבצים מקבלים מקבילות מודרניות. חלקים יציבים ויקרים להעברה יכולים להישאר מאחורי שכבת API עד שיגיע תורם.

לקריאה נוספת: מודרניזציה של מערכות מדור קודם בקצב AIקישור לשאלה הזו

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

לקריאה נוספת: מודרניזציה של מערכות מדור קודם בקצב AIקישור לשאלה הזו

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

לקריאה נוספת: הנדסת ענן, SovereignTech והגירה היברידיתקישור לשאלה הזו

בדרך כלל בזה שאתם כבר משתמשים בו, אלא אם יש סיבה ברורה לשינוי. הגורמים המכריעים הם מיקום הנתונים, החוזים והכישורים הקיימים שלכם, השירותים המנוהלים שאתם זקוקים להם והאופן שבו המערכות האחרות שלכם מתחברות. אנחנו עובדים עם AWS, Microsoft Azure, Google Cloud, Alibaba Cloud ועננים ממשלתיים אזוריים, ומגבילים קוד ייעודי לספק למקומות שבהם הוא משתלם.

לקריאה נוספת: הנדסת ענן, SovereignTech והגירה היברידיתקישור לשאלה הזו

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

לקריאה נוספת: הנדסת ענן, SovereignTech והגירה היברידיתקישור לשאלה הזו

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

לקריאה נוספת: הנדסת ענן, SovereignTech והגירה היברידיתקישור לשאלה הזו

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

לקריאה נוספת: הנדסת ענן, SovereignTech והגירה היברידיתקישור לשאלה הזו

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

לקריאה נוספת: הנדסת ענן, SovereignTech והגירה היברידיתקישור לשאלה הזו

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

לקריאה נוספת: DevOps, הנדסת פלטפורמה וסביבות הרצה לסוכני קידודקישור לשאלה הזו

בדרך כלל באלה שכבר יש לכם. אנחנו עובדים עם Terraform, OpenTofu ו-Pulumi לתשתית, עם Kubernetes לקונטיינרים, ועם שירותי ה-CI/CD הנפוצים, ובהם GitLab CI/CD, GitHub Actions ו-Argo CD. אנחנו ממליצים על שינוי רק כשכלי חוסם את מה שאתם צריכים.

לקריאה נוספת: DevOps, הנדסת פלטפורמה וסביבות הרצה לסוכני קידודקישור לשאלה הזו

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

לקריאה נוספת: SRE, נראות מערכת ו-FinOps לענן ולטוקנים של AIקישור לשאלה הזו

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

לקריאה נוספת: SRE, נראות מערכת ו-FinOps לענן ולטוקנים של AIקישור לשאלה הזו

התמיכה משתנה לפי דגם וגרסת קושחה. אנחנו בודקים כל HSM בביקורת ה-CBOM ומתכננים שדרוגים או החלפות רק היכן שהם נדרשים.

לקריאה נוספת: קריפטוגרפיה פוסט־קוונטית והצפנה עמידה בפני קוונטיםקישור לשאלה הזו

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

לקריאה נוספת: קריפטוגרפיה פוסט־קוונטית והצפנה עמידה בפני קוונטיםקישור לשאלה הזו

AWS, Microsoft Azure, Google Cloud, Alibaba Cloud ועננים ממשלתיים אזוריים, וגם מרכזי הנתונים שלכם ואשכולות GPU פרטיים. התשתית מוגדרת ב-Terraform, ב-OpenTofu או ב-Pulumi ועומסי העבודה פועלים על Kubernetes, כך שבחירת הספק נשארת פתוחה.

לקריאה נוספת: ענן ותשתיתקישור לשאלה הזו

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

לקריאה נוספת: ענן ותשתיתקישור לשאלה הזו