ניתוח מול פיתוח Development vs. Design

חברת STKI ערכה מחקר בנושא "פיתוח מערכות תוכנה בארגוני IT". תוצאות המחקר התפרסמו בכנס השנתי שלנו והיוו מחקר ראשון בתחום זה בישראל.
בעקבות שאלות של לקוחות להלן התייחסותנו למאמץ המושקע בניתוח מערכות למול המאמץ המושקע בפיתוח (החל משקף 8) . על פי שאלות של מספר לקוחות, החלק של מנתחי המערכות (ניתוח ועיצוב) במחקרים אחרים גדול יותר מחלקם כפי שהתקבל במחקר STKI. להלן התייחסותנו לשאלה זו:
לקוחות STKI נתבקשו למלא כיצד מתחלק תקציב הפיתוח ב- IT בין מנתחי מערכות, מפתחים, שלב בדיקות וכד'.
ניסוח זה דומה אך לא זהה לשאלה של "כיצד מתחלק תקציב הפיתוח בין שלבי הפיתוח השונים" זאת מכיוון שעל פי הבירור שערכנו בארגונים רבים (למעשה כל הארגונים אתם בצעם את הבירור הנוסף) מסתבר שהחלקים היותר טכניים של העיצוב - Low level detailed design - מתבצעים על ידי צוותי הפיתוח ולא מוגשים על ידי צוותי המנתחים כמקשה אחת. במיוחד בפרוייקטים הקטנים שבהם לא בונים בנפרד אפיון מפורט אלא מעבירים לפיתוח באופן מיידי (לא נתייחס במקום זה האם תופעה זו מבורכת...).
כלומר חלק מפעולות ה"עיצוב" מתבצעות על ידי המפתחים.
נקודה נוספת היא שהחלקים העליונים של האפיון מתבצעים לעיתים על ידי הגוף הדורש שמכיל רפרנטים ברמה גבוהה, תחום BRM – Business Relationship Management, או גוף או"ש (לעיתים אכן יהיו שם מנתחי מערכות אך לא חלק מה- IT) ולכן נקודה זו מעצימה את ההשקעה בפיתוח לעומת הניתוח שמתבצע בגוף ה- IT.

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

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


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

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

מתי צריך להחליף את צוות בדיקות התוכנה?

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

פיתוח עם ראייה תשתיתית

ארגונים רבים משקיעים משאבים רבים לצורך פיתוח מערכות טוב יותר. עיקר המאמץ מושקע בהתאמת המערכת לצרכים העסקיים של המערכת תוך עמידה בלוחות זמנים ובתקציב הפרוייקט. לפיתוח הפרוייקט ישנם גם מטרות נוספות- בניה שמאפשרת תחזוקה קלה, ואבטחת המידע מוגברת.
עם זאת ישנם פרויקטים רבים, הן ברמה של פרויקטים שמבוצעים והן ברמה של כתיבת המכרז או דרישות הפרוייקט שאינם כוללים התייחסות למאפיינים תשתיתיים.
לדוגמה, לעיתים נדירות רואים מפתחים שכותבים מערכת שתרוץ מיטבית ספציפית בסביבת terminal services (כמו CITRIX או WTS) או סביבת thin clients. לעיתים נדירות רואים מפתחים שכותבים מערכת שתרוץ בצורה טובה בסביבה של CLUSTER , בסביבת שבה אין תקשורת מספיק טובה ועוד ועוד. ואז במקרים רבים מסתבר שמערכת שבה הושקע רבות אינה מתאימה לסביבת הריצה הספציפית כאשר הדבר מתגלה או במהלך בדיקות העומסים או בדיקות הקבלה ולעיתים רק כאשר המערכת מוטמעת ותיקון הדבר עולה הון.
יש לציין שרק בתחום מסדי הנתונים מקובל כבר להשקיע בזמן הפיתוח ולכן רואים בארגונים רבים DBA אפליקטיבי אשר מסייע למפתחים גם לבנות את מסד הנתונים וגם לכתוב stored procedures בצורה טובה.

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

May the Force be with You

לאחרונה קיבלתי הדגמה מעניינת של סביבת הפיתוח החדשנית force.com .

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

הפיתוח ב- force מזכיר במידה רבה פיתוח במחוללי יישומים - wizards אשר מלוויים את המפתח במהלך הגדרת האובייקטים וקינפוגם תוך שימוש בהגדרות קיימות כמו לדוגמה rolls מובנים מראש. עם זאת ברמה הגרפית עדיין לא מדובר בעושר שמתקבל ממחוללי יישומים ותיקים ולצורך זאת ולצרכים נוספים כמו לוגיקה מורכבת יש צורך להשתמש בשפת ה- APEX הייעודית לסביבה זו. ההדגמה שקיבלתי הנה הדגמה בסביבה של WEB אך ניתן גם להוריד את כל הסביבה למחשב האישי ולהשתמש בסביבת פיתוח מבוססל eclipse.

גם שילוב של אפליקציות חיצוניות ב- marketplace הקיים סביב salesforce מתאפשר בצורה קלה ולאחרונה יצאה החברה גם בטכנולוגיה בשם sites אשר מאפשרת לבנות אתרים חיצוניים (ללא תמחור לפי משתמש) בצורה קלה ומועילה.

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

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

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

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

· לקוח אשר מקיים מערכת שחייבת להיות מאוד זמינה ובעלת ביצועים מאוד גבוהים תוך אפשרות לטפל בעומסים בלתי שגרתיים מבסס את עצמו על טכנולוגיות Legacy ברמה הגבוהה ביותר (למרות שהנפחים הממוצעים לא מחייבים זאת) תוך שימוש בקוד המאפשר ביצועים הטובים ביותר (C ו- C++ ) כאשר מערכות משיקות מפותחות ב- .NET . למערכות הקריטיות הלקוח גם פיתוח מערכת ניטור ובקרה ייעודית אשר מספקת מידע על הביצועים בשכבות השונות עד לרמה של מילי שניות!
· מספר לקוחות דיברו על כך שה- GUI המועדף על ידם הוא WEB עקב יתרונות בהפצה ועקב יתרונות באבטחת מידע. ישנם לקוחות אשר מריצים אפליקציות client server אשר עקב אילוצים של אבטחת מידע משתמשים בטכנולוגיה של Citrix.
· לקוח אשר יישם מתודולוגיות פיתוח מתקדמות דיבר על השימוש שלהם במתודולוגיה של Agile Software Development תוך שימוש ב- best practices של SCRUM . הלקוח דיבר על כך שגם בפרויקטים אשר לא מבוצעים ב- SCRUM ישנה גישה של מסירות קטנות וקשר צמוד ותמידי עם המשתמש הסופי.
· אחד מהארגונים שבו יש צוות של ארכיטקטורה ופרויקטים דיבר על כך שהם פתחו "ארכיטקטורה מומלצת" למספר סוגים של פרויקטים דבר המקל בצורה משמעותית על בחירה של ארכיטקטורה לפרויקטים. הארגון הזכיר את המושג "חממה מעצבת" לפרויקטים ייחודיים או גדולים כשמדובר על ליווי צמוד של צוות הארכיטקטים הארגוניים.
· ניהול פרויקטים – לקוח ציין שהם פתחו מערכת שלהם מבוסס SPS – אתרים לפרויקטים. ואז יש כל המסמכים של הפרויקטים במקום אחד. בקשות ואישורים וכד'- במקום אחד.

פיתוח אפליקציות בארגון ציבורי

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


הארגון משתדל לעבוד על פי תוכנית עבודה שנתית של ה –IT כאשר לאחרונה עקב מורכבות ואורך הזמן שלוקח לפתח פרויקטים ישנה נטייה לעבוד לתוכנית דו שנתית (פעם בשנתיים).
הארגון מחולק לאגפים (אגף בריאות, אגף לוגיסטיקה, אגף כ"א, וכד'). כאשר לקראת דיוני התקציב של השנה החדשה, נציג מכל אגף אוסף ומרכז את כל הדרישות ממערכות המידע של אותו אגף כאשר תעדוף ראשוני מתבצע ברמת מנהל האגף.
לאחר מכן ברמת מנכ"ל הארגון, ישנו תעדוף סופי של הדרישות השונות כאשר מנסים להסתכל על נושאים של כלל הארגון. לדוגמה לאחרונה דובר בארגון על מוטיב מרכזי של "החבר במרכז" וזה מוטיב זה העלה את העדיפות של כל האפליקציות שקשורות לנושא זה. בארגון פותחה מערכת של תוכניות עבודה ב- .net
מראש מקצים בתוכנית העבודה אחוז מסיים לתחזוקה של פרויקטים ואפילו יש חלוקה לתחזוקה ולתיקון תקלות. באופן כללי 60% זה תחזוקה – כולל תקלות ושיפורים קטנים. תקלות מתוך זה כ- 20%. ישנם תחומים שעם השנים מבינים שהם תחומים בעייתיים כי יש הרבה הנחתות עסקיות כלומר הרבה בלת"מים. ואז מראש מקצים יותר זמן (כסף) בתוכנית העבודה לשינויים ותקלות בתחום זה.
כאשר מתחילים פרויקט יש שלב של התנעה – יושבים כל המנהלים ומחליטים מי מבצע מה ולאחר מכן השלבים הרגילים: אפיון, ייזום, סקר ייזום, פיתוח, בדיקות – הכול לפי נוהל ISO.
נקודה חשובה מאוד. בארגון החליטו כבר לפני זמן מה לעבור ל- 4 גרסאות בשנה בלבד (שינויים ושיפורים). משתדלים שלא יהיה יותר. פעם היה שחרור תמידי. היום עברו לגרסאות. הסיבה היא שישנם קשרים רבים בין המערכות דבר שמחייב סנכרון בעייתי. מסתבר, שלמרבה הפלא גם מקבלי השירות קיבלו שינוי זה בהבנה ושביעות הרצון מהתוצרים של מערכות מידע עלתה!
אין בארגון גוף של ארכיטקטים אבל יש בתהליך התנעת הפרויקט יש נציגים של תקשורת\תשתיות. אבל מנהל הפרויקט הוא אחראי לערב את הגופים הטכנולוגיים שלדעתו רלוונטיים אבל אין סטנדרטים מחייבים לזה. כמו כן באופן כללי מנסים לערב את המשתמשים כמה שיותר במהלך חיי הפרויקט.