מפגש שולחן עגול בנושא איכות ובדיקות תוכנה Quality and Testing RT

לקוחות נכבדים,
תחום האיכות והבדיקות הוא נדבך מרכזי בפיתוח תוכנה. עם זאת ישנן גישות שונות לביצוע משימות אלו כאשר ארגונים שונים מתייחסים לנושא באופנים שונים. בהמשך למחקר שבצעה חברת STKI על פיתוח תוכנה בארגוני IT ברצוננו להעמיק את ההתיחסות לנושא זה. תחום זה אף עומד להתפתח בצורה משמעותית עם הכניסה של טכנולוגיות חדשות בתחום של Mobile ,רשתות חברתיות וכד'.
סדר היום למפגש:
1. מה הם שלבי הבדיקות השונים, מתי הם מתבצעים ומי מבצע אותם.
2. האם מידת השקעה בבדיקות שונה בין פרוייקטים שונים: פיתוח מול תחזוקה, פרוייקטים פנימיים מול חיצוניים וכד'. האם וכיצד קובעים מראש את מידת ההשקעה בבדיקות.
3. מהם הכלים שנמצאים בשימוש ועד כמה הם מחוברים לכלי ALM אחרים (Requirements, Versioning וכד').
4. TDD - Test Driven Development
5. אבטחת מידע בהקשר של איכות ובדיקות (בהמשך לשולחן עגול שנערך בנושא פיתוח מאובטח).
6. בדיקות ואיכות של פרוייקטים בטכנולוגיות חדשות: Mobile , רשתות חברתיות.

מפגש שולחן עגול הוא מפגש של לקוחות הדנים על נושא שנקבע מראש. המפגש יתקיים יום א' ה- 19 ליוני בשעות 09:30 עד 12:30 לערך במשרדי STKI אשר בבני ציון. על פי מדיניות STKI ספקים או יועצים אינם מורשים להשתתף. בד"כ ארגון יכול לשלוח עד 2 נציגים.
בכדי להשתתף במפגש יש לשלוח מייל ל- etty@stki.info או ortal@stki.info.
פרטים על הגעה לאתר ב- http://www.stki.info/files/9e85ab2145dca6f674e36361a806cef9.doc .

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

בברכה,

פיני

יחסי כ"א בתחום האחסון בבנקים- Storage Ratios

חברת STKI ערכה לאחרונה מחקר בנושא יחסי כ"א בתחום האחסון. תוצאות המחקר כפי שהתפרסמו הנן:

התוצאות המלאות מופיעות לינק הבא.

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

• ערוב סביבות MF ופתוחות. ישנם ארגונים אחרים המערבים סביבות פחותות ו- MF שגם בהם היחסים אף פחותים.
• רמת ה- SLA והשרידות הנדרשת תוך רגישות ל- RPO – Return Point Objective במקרה של תקלה.

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

מפגש שולחן עגול - מעבר לוירטואליזציה Beyond Virtualization

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

סדר היום לדיון הנו:
סבב ראשון – וירטואליזציה בשרתים:
1. עשה ואל תעשה בסביבה וירטואלית. איזה סוג Load לא כדאי להעביר לסביבה וירטואלית.
2. גיבוי בסביבה וירטואלית.
3. High Availability – Cluster מקומי ומרוחק (DRP ) בסביבה ויריטואלית.
4. טיפים בנושא רישוי בסביבה הוירטואלית (הן של VMWARE והן של המוצרים המותקנים)
5. אחסון בהקשר וירטואליזציה
6. שליטה ובקרה בהקשר של וירטואליזציה – מה ראלי לדרוש והאם אפשר לצפות לתמונת שו"ב אמיתית של הסביבה הוירטואלית. האם ניתן לבצע quality of service למערכות שמותקנות בסביבה הוירטואלית?

סבב שני – מעבר לוירטואליזציה –
1. מה מידת הבשלות של פתרונות אוטומציה ו- Self Service בתחום התשתיות (הן כחלק פתרון הוירטואליזציה והן באופן כללי)?
2. מה מידת הבשלות של טכנולוגיות אחסון מתקדמות (FCOE)?
3. מה מידת הבשלות של טכנולוגיות Converged כגון (Cisco UCS, HP Matrix, IBM CloudBurst)?
4. האם יש טכנולוגיות ומתודולויות מומלצות לשיפור היעילות \ מעבר לענן פנימי?
5. באיזה מקרים ניתן לשקול שימוש בענן חיצוני בהקשר תשתיות (כגון Amazon EC2)?


מפגש שולחן עגול הוא מפגש של לקוחות הדנים על נושא שנקבע מראש. המפגש יתקיים ביום א' ה- 29 למאי בשעה 0930 עד לשעה 1230 לערך במשרדי STKI אשר בבני ציון. המפגש מיועד ללקוחות STKI . על פי מדיניות STKI ספקים או יועצים אינם מורשים להשתתף במפגש. בכדי להשתתף במפגש יש לשלוח מייל ל- etty@stki.info או ortal@stki.info . בד"כ ניתן לשלוח עד 2 נציגים מכל ארגון.
סיכומי שולחנות עגולים קודמים נמצאים ב- http://www.scribd.com/people/view/1336427-pini-cohen .
פרטים על הגעה לאתר ב- http://www.stki.info/files/9e85ab2145dca6f674e36361a806cef9.doc .

בברכה,

פיני

ניתוח מול פיתוח 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.