ניתוח מקרה: ניהול אינטגרציה בסביבת פרויקטים מורכבת


03 Feb
03Feb

מאת: קרן סגל כהן, מנהלת פרוייקטים ואינטגרציה GlobaLeadPro


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

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

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

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

התהליך התחלק לשלושה שלבים:

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


איך זה בדיוק התבצע (עכשיו הפרטים):

הצעד הראשון היה זיהוי ממשקים בין צמדים/זוגות בפרויקט.

מהו ממשק/צמד?

ממשק הוא נקודת החיבור בין שני רכיבי תוכנה שונים (או יותר) בזמן ריצה.

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

ממשק יכול להיות סינכרוני או אסינכרוני (כלומר מחזיר פידבק / פלט או לא בהתאמה)

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

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

צעד שני – לכל ממשק/צמד נכתב (או על ידי המאפיין או על ידי) תיעוד טכני במסמך IDD (Interface Detailed Design) –

התיעוד הטכני כלל ערכי קלט/פלט אפשריים –

אורך

סוג

חובה? כן/לא

מיפוי הערכים (כלומר "לאן הם הולכים?" מה שדות היעד שלהם?
 Source to target)

לכל IDD יהיה Review משותף לכל המשתתפים בממשק עד "חתימה"

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

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

סוגי הפעילויות שהוחלט לבצע לכל צמד/ממשק:

סוג בדיקה

מטרה

מתי

מי

היכן

Interface Agreement

תיעוד טכני של הממשק

בזמן אפיון

מנתחי מערכות

לא רלוונטי

Dev2dev

בדיקת תאימות. לא בדיקת לוגיקה. לוודא שה"חיבור" עובד

בזמן פיתוח

שני צוותי הפיתוח

סביבת פיתוח

בדיקות E2E

בדיקות אינטגרטיביות שמדמות תהליכים עסקיים

לפני מסירה ללקוח

צוות בדיקות

סביבת בדיקות אינטגרטיבית


 

שם ממשק

אחראי 1

פרוייקט 1

אחראי 2

פרוייקט 2

פעילות

סטטוס

תאריך סיום






1.Interface agreement

הושלם

1.10.19






2.Dev2Dev  test

הושלם

7.11.19






3. Full E2E Test

הושלם

20.1.20


לכל תהליך עסקי שמעורב בו צמד/"זוג" היו 3 שורות במטריצה:

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


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


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

דוגמה לבעיות אינטגרציה שנמצאו בזמן Dev2dev


דוגמה לבעיות אינטגרציה שנמצאו בזמן E2E:


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

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

הערות
* כתובת הדואר האלקטרוני לא תוצג באתר.