AI-Native Development

יצירת קשר

AI-Native Development – פיתוח מערכות תוכנה בעידן ה-AI

בית התוכנה Dogma מבוסס AI-Native:
פיתוח מערכות מקצה לקצה בשילוב כלי בינה מלאכותית מתקדמים – ממוצר קונספט ועד ל-Enterprise, במהירות שיא ובאיכות ללא פשרות.

עולם פיתוח התוכנה משתנה במהירות.

פיתוח מערכות מונע בינה מלאכותית
פיתוח מערכות מונע בינה מלאכותית

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

אבל מהירות הפיתוח לבדה אינה מספיקה כדי לבנות מערכת אמיתית.

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

כאן נכנסת גישת AI-Native Development.

במקום להשתמש ב-AI רק ככלי שמייצר קוד מהר יותר, אנו משלבים אותו בתוך תהליך הפיתוח כולו – החל מהבנת המוצר והגדרת הדרישות, דרך Product Design וארכיטקטורה ועד פיתוח, בדיקות, Code Review והכנה ל-Production.

מהו AI-Native Development?

AI-Native Development הוא גישה לפיתוח תוכנה שבה כלי AI ו-Agentic AI משולבים באופן שיטתי בתהליך העבודה של צוותי המוצר והפיתוח.

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

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

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

ההבדל המרכזי הוא שה-AI אינו עובד בחלל ריק.

הוא מקבל Context, Specification, Architecture, Design, Rules ו-Criteria ברורים.
כאן נכנס הצורך במומחה מנוסה מאד בארכיטקטורת תוכנה וסיסטם (System & Software Architecture).

כך ניתן להפוך את המהירות של AI ליכולת פיתוח אמיתית, ולא רק לדרך מהירה יותר לייצר קוד.

 

כדי שהמנוע ה-AI יפיק קוד ברמת Enterprise / Production-Grade ולא חצי-מוצר מתוסבך, ה-Context וה-Specification חייבים להיבנות ביד אומן FDE.

הנה הגדרת הניסיון והכישורים הנדרשים ממומחה שנכנס לרווח הזה:

הניסיון והכישורים הנדרשים מהמומחה המוביל:

1. ניסיון בארכיטקטורת תוכנה וסיסטם (System & Software Architecture)

  • הבנה עמוקה במערכות מורכבות: ניסיון מעשי בהגדרת Structure, Microservices, Data Models, והפרדת אחריות (Separation of Concerns).

  • ראיית Production מקצה לקצה: יכולת לחזות מראש חסמי ביצועים (Scalability), צווארי בקבוק ב-DB, ואתגרי סנכרון בין רכיבי המערכת – עוד לפני שנכתבה שורת קוד אחת.

2. מומחיות באפיון טכנולוגי מבוסס מפרט (Spec-Driven Development)

  • תרגום דרישות עסקיות למפרט טכני מובנה: יכולת לקחת רעיון עסקי מורכב ולהפוך אותו ל-Prompt Context, Technical Spec, ו-API Contracts שחד-משמעיים עבור כלי ה-AI.

  • הגדרת חוקים וגבולות גזרה (Guardrails & Rulesets): ניסיון בהגדרת Coding Standards, Design Patterns, וכללי אבטחת מידע שה-AI מחויב להיצמד אליהם (כדי למנוע "אילוזיות" או קוד מרושל).

3. ניסיון בניהול איכות, אבטחת מידע ו-SecOps

  • אבטחה מקצה לקצה (Security by Design): היכרות עמוקה עם תקני אבטחה, זיהוי חולשות קוד (OWASP Top 10), וניהול הרשאות (IAM / RBAC) – תחומים שבהם AI נוטה לייצר חורי אבטחה אם לא מגדירים לו חוקים קשיחים.

  • בדיקות ואימות (Verification & Testing Frameworks): ניסיון בהגדרת קריטריוני קבלה (Acceptance Criteria), כתיבת טסטים אוטומטיים (Unit, Integration, E2E) וסקירת קוד (Code Review) רצינית לקוד שהופק.

4. מומחיות מעשית בכלי AI מתקדמים (AI Engineering & Prompt Architecture)

  • שליטה עמוקה בסביבות הפיתוח החדשות: ניסיון מעשי בעבודה עם כלי AI-Native (כגון Cursor, Claude Dev/Windsurf, Bolt, LLM APIs) והבנה של מגבלות ה-Context Window וה-Tokens.

  • טכניקות הנדסת הקשר (Context Engineering): יכולת להזריק ל-AI בדיוק את המידע הנכון בזמן הנכון (RAG, System Prompts, Instruction Files) כדי למנוע הידרדרות של איכות הקוד ככל שהפרויקט גדל.

5. ניסיון בהובלת מוצר ופרויקטים (Product & Tech Leadership)

  • ראייה היקפית של ה-Lifecycle של המוצר: ניסיון בהובלת מפות דרכים (Roadmaps), ניהול סיכונים טכנולוגיים, והבנת חווית המשתמש (UX/UI) לצד הדרישות הטכניות.

  • שילוב בין הנדסה קלאסית לפיתוח מואץ: היכולת לגשר בין ה-Vibe Coding המהיר לבין מתודולוגיות הפיתוח הממוסדות (SDLC / Enterprise Standards).

 איך תחפשו את המומחה שלכם במשפט מסכם?

"דרוש מומחה שמשלב ניסיון של ארכיטקט תוכנה בכיר (System Architect) עם שליטה מתקדמת בהנדסת הקשר (Context Engineering).
מישהו שיודע להגדיר למנוע ה-AI בדיוק מה לבנות, באיזו ארכיטקטורה ובאילו כללים – ולהפוך את כוח המחשוב של ה-AI מתוכנה שמייצרת 'טיוטות' לכלי שמנפיק מוצר יציב, מאובטח ומוכן לשוק."

AI-Native Development מתחיל במוצר ולא בקוד

אחת הטעויות הנפוצות בפיתוח מבוסס AI היא להתחיל מיד בכתיבת קוד.

  • Prompt מוביל לקוד.
  • הקוד מוביל למסך.
  • המסך מוביל לעוד Prompt.

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

ב-Dogma התהליך מתחיל במקום אחר.

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

Product Design ו-UX/UI הם חלק ממהותי בהתהליך הזה.

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

רק לאחר מכן ניתן להעביר את הידע הזה ל-Specification ולתהליך הפיתוח.

מ-Product Design ל-AI-Native Development

החיבור בין Product Design לבין AI-Native Development הוא אחד היתרונות המשמעותיים של התהליך.

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

כאשר השאלות האלה נפתרות לפני הפיתוח, ה-AI מקבל בסיס הרבה יותר איכותי לעבודה.

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

זה בדיוק המקום שבו Product Design, אפיון ו-AI-Native Development מתחברים.

Spec-Driven Development כחלק מהתהליך

אחד המרכיבים המרכזיים בגישת AI-Native Development של Dogma הוא Spec-Driven Development.

הרעיון פשוט:

לא מתחילים מקוד.

מתחילים מ-Specification.

ה-Specification מגדיר מה צריך לבנות ולמה, לאחר מכן ניתן להפוך אותו ל-Plan, למשימות ולבסוף לקוד.

הגישה הזו נתמכת גם על ידי Spec Kit של GitHub, שמספק תהליך מובנה לעבודה עם Coding Agents, כולל Specify, Plan, Tasks, Implement ו-Converge.

היתרון הוא שה-Specification הופך למקור משותף ל-Product, Design, Architecture, Development ול-Agent.

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

למי שרוצה להעמיק, ניתן לקרוא גם את התיעוד הרשמי של GitHub Spec Kit.

פיתוח מערכת חדשה עם AI – Greenfield

AI-Native Development מתאים במיוחד כאשר בונים מערכת חדשה מאפס.

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

לאחר מכן ניתן להשתמש ב-AI כדי להאיץ את שלבי הביצוע.

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

המשמעות היא לא רק יותר קוד בפחות זמן.

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

AI-Native Development למערכות קיימות

AI-Native Development אינו מיועד רק למערכות חדשות.
הוא יכול להיות משמעותי במיוחד ב-Brownfield – מערכות קיימות שצריך להרחיב, לתחזק או למודרניזציה.

במערכות כאלה האתגר מורכב יותר.

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

במקרים כאלה אי אפשר פשוט לתת ל-Agent "לשכתב את המערכת".

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

Spec Kit עצמו מגדיר Iterative Enhancement כדרך עבודה עבור מערכות קיימות, כלומר הוספת יכולות ומודרניזציה של מערכות Brownfield.

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

AI App Rescue – כשהאפליקציה כבר נבנתה

אחד השירותים שניתן לשלב במסגרת AI-Native Development הוא AI App Rescue.

בניתם אפליקציה באמצעות Lovable, Bolt, Cursor, Replit, ChatGPT או כלי AI אחר?

המערכת עובדת בדמו, אבל עכשיו מתחילות הבעיות?

זהו מצב שהופך נפוץ יותר ככל שכלי AI מאפשרים לבנות Prototypes ומוצרים במהירות גבוהה.

הבעיה מתחילה כאשר המוצר צריך לעבור מה-Demo ל-Production.

פתאום צריך להתמודד עם Authentication, הרשאות, Database, אבטחה, ביצועים, אינטגרציות, Payments, Monitoring, Deployment ותחזוקה.

בשלב הזה לא תמיד צריך לזרוק את הקוד ולבנות הכול מחדש.

לעיתים חלקים משמעותיים מהמערכת טובים וניתנים לשימור.

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

המטרה היא להפוך Prototype שנבנה במהירות למוצר שניתן לתחזק, להרחיב ולהפעיל ב-Production.

Code Rescue – לא כל קוד צריך להיזרק

כאשר מערכת נבנתה בעזרת AI, הפתרון אינו בהכרח Rewrite.

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

ב-Dogma ניתן לבצע Code Rescue בצורה מדורגת.

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

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

אבטחה ו-Production Readiness

המעבר מ-Prototype למערכת אמיתית מחייב שינוי ברמת הבדיקה.

מערכת יכולה לעבוד מצוין אצל משתמש אחד ועדיין להיות לא מוכנה ללקוחות.

צריך לבחון:

  • Authentication ו-Authorization.
  • הרשאות וגישה למידע.
  • שמירת מידע רגיש.
  • API Security.
  • ניהול Secrets.
  • Database Security.
  • Validation.
  • Logging.
  • Monitoring.
  • Error Handling.
  • Backup ו-Recovery.
  • Performance.
  • Scalability.
  • CI/CD.
  • Deployment.

AI יכול לסייע גם בתחומים האלה, אבל הוא אינו מחליף אחריות הנדסית.

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

AI-Native Development למערכות Enterprise

כאשר מדובר ב-Enterprise, השאלה אינה רק כמה מהר אפשר לכתוב קוד.

השאלה היא האם אפשר להפעיל ולתחזק את המערכת לאורך שנים.

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

לכן השימוש ב-AI צריך להיות מבוקר.

אנחנו משלבים AI בתוך תהליך שבו קיימים Specification, Architecture, Product Design, Testing ו-Code Review.

כך ניתן ליהנות מהמהירות של AI מבלי לוותר על הבקרה הנדרשת במערכות מורכבות.

מהירות בלי לוותר על איכות

היתרון הגדול של AI-Native Development הוא לא "AI כותב קוד".

היתרון הוא היכולת לקצר חלקים רבים ממחזור החיים של הפיתוח.

ניתן להשתמש ב-AI כדי לנתח מידע, ליצור טיוטות, לפרק Features למשימות, לכתוב קוד, ליצור בדיקות, לנתח תקלות ולסייע ב-Refactoring.

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

  1. Product.
  2. Design.
  3. Specification.
  4. Architecture.
  5. Development.
  6. Testing.
  7. Security.
  8. Deployment.
  9. AI.

במילים אחרות, AI מאיץ את התהליך, אבל התהליך הוא זה ששומר על איכות המוצר.

למה לעבוד עם Dogma?

Dogma מביאה לתהליך ניסיון של 27 שנים בפיתוח מערכות, Product Design, UX/UI, אפיון ופיתוח של מערכות מורכבות.

היתרון אינו רק ביכולת להשתמש בכלי AI.

היתרון הוא בחיבור בין הבנה עסקית, Product Design, תכנון טכנולוגי ופיתוח.

הצוותים שלנו עובדים על מערכות שבהן לא ניתן להסתפק ב-Demo שעובד.

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

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

מתי AI-Native Development מתאים לכם?

הגישה מתאימה לארגונים ולחברות שנמצאים באחד מהמצבים הבאים:

  • יש לכם רעיון למוצר חדש ואתם רוצים להגיע ל-MVP במהירות.
  • בניתם Prototype באמצעות כלי AI ואתם רוצים להפוך אותו למוצר Production.
  • יש לכם מערכת קיימת ואתם רוצים להרחיב או למודרנז אותה.
  • צוות הפיתוח שלכם עמוס ואתם רוצים להגדיל Capacity.
  • אתם רוצים לשלב AI בתהליך הפיתוח ולא רק להשתמש ב-Coding Assistant.
  • יש לכם מערכת מורכבת שדורשת Product Design, Architecture ופיתוח תחת תהליך אחד.
  • אתם רוצים לקצר את הדרך מקונספט למוצר עובד בלי לוותר על איכות הנדסית.

מ-Concept ל-Enterprise

AI-Native Development מאפשר לשנות את הדרך שבה תוכנה נבנית.

  • אפשר להתחיל מרעיון.
  • להגדיר את המוצר.
  • לבנות Product Design.
  • לייצר Specification.
  • לתכנן Architecture.
  • להפעיל AI Agents.
  • לפתח.
  • לבדוק.
  • לשפר.
  • ולהגיע ל-Production.

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

זו אינה רק טכנולוגיה חדשה.

זו דרך חדשה לחשוב על תהליך פיתוח התוכנה.

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

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

case_study סימולציית שליטה ובקרה

 

Case Study

פרויקט לתעשיות הביטחוניות

כאשר Prototype הופך למערכת סימולציה מורכבת

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

כאשר Prototype כבר לא מספיק

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

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

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

מגבלות הפיתוח העצמאי

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

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

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

בנוסף, נדרשה התמודדות עם אתגרים כגון:

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

מ-Prototype למערכת שניתן לבנות עליה

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

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

החיבור בין Product Design לבין הטכנולוגיה היה משמעותי במיוחד.

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

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

Product Design, UX/UI, אפיון, ארכיטקטורה ופיתוח צריכים לעבוד יחד כאשר מדובר במערכת מורכבת.

מהירות הפיתוח – בלי לוותר על הבסיס ההנדסי

הפרויקט מדגים את אחד האתגרים המרכזיים של AI-Native Development.

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

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

זהו למעשה תהליך של Code Rescue ו-Modernization: לקחת בסיס קיים, להבין את המגבלות שלו ולהפוך אותו לתשתית שניתן להמשיך לפתח עליה.

התוצאה

העבודה של Dogma מחברת בין Product Design, UX/UI, אפיון, ארכיטקטורה ופיתוח כדי להפוך רעיון או Prototype למערכת שניתן להמשיך לפתח ולהרחיב.

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

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

תחום:
מערכות ביטחוניות | Simulation | Control & Command | 3Dשירותים:
Product Design, UX/UI, אפיון, Architecture, Code Rescue, Modernization

סוג מערכת:
Enterprise | Mission-Critical | Real-Time