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

האתגרים שבתכנון מערכות

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

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

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

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

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

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

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

התמודדות וחדשנות

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

קהילת השירותים הפתוחים (OSLC open-services.net) היא התאגדות תעשייה החותרת לפשט את שיתוף המידע בין כלים שונים. העיקרון שמאחורי OSLC הוא החתירה לאפשר לצוותים להמשיך ולהשתמש בכלי התוכנה הקיימים שלהם – ולהפעיל סוג של "מסלקת ידע" במקום ליצור ממשק נקודתי נפרד בין כל שני כלים כאלה. עקרונות הארכיטקטורה של ה- Web מיושמים כאן על מנת לספק שילוב בצימוד רופף (loosely coupled) בין הכלים השונים.

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

יבמ, המבססת את סביבת הפיתוח שלה על תקנים פתוחים, מקפידה גם הפעם לאמץ את OSLC כתשתית המנחה של כלי הפיתוח השיתופיים שלה, במסגרת תפיסת ה- Jazz.

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

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

חזון משותף ומחובר

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

כך למשל, ניתן לאחסן מידע לגבי תכנון מערכות בסביבת Rational ו-Mathworks  של יבמ במאגר מרכזי אחד ולנהל את העבודה המשולבת בעזרת כלי Rational Rhapsody.

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

נכתב ע"י IBM  ישראל פברואר 2012.