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

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

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

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

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

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

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

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

אחרי השדרוגים מתבצעת בדיקת ATP (acceptance test procedure) המוודאת שהמערכת פועלת בצורה תקינה ובהתאם לתכנון ולדרישות, אשר בסופה מקבל האינטגרטור ATR (acceptance test review)  – מפרט מסכם של תוצאות הבדיקה עבור כל אחת מתתי המערכות.

עכשיו, חוזרים ל"תמונה הגדולה" (אינטגרציה של כל תתי המערכות) – כאשר הATR  תואם את דרישות המערכות נגשים לביצוע ATP מערכתי המתכלל את המערכת המרכזית כאשר תתי המערכות מחוברים אליה.

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

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

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

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

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

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

אנחנו שותפים גם לאחר המסירה. אבל זה כבר לסיפור אחר.

___________________________________________________________________________________________

מאת:
ערן לייבוביץ – מנהל מחלקת אינטגרציה ובדיקות, חטיבת אינטגרציה, ניסויים, מולטימדיה ו-IT