Admin Side
מס' רכיב כינוי מקוצר סיכום (שמש) 19.1.2016 התייחסות בנסאיי 3.2.2016
4 Euro משמש כמטבע מחדל מצב בו המערכת אינה עובדת פר מטבע-לקוח אלא ביורו היא קשה אופרטיבית. יש לשנות לוגיקה של המערכת. לפי בנסאיי הדבר יבוצע כשעות נוספות ובתשלום נוסף. לפי שמש הדבר כבר שולם. העניין עלה עתה לראשונה. לא מונע הפעלת הפיילוט. יעשה כנגד תשלום נפרד.
5 לינקים שבורים נמצא באג. לתיקון. לא מונע פיילוט. עם זאת מסכים לתקן לפני פיילוט
7 תבניות לא מחיקות נמצא באג שלא מאפשר למחוק תבניות (באג אחר, תוקן). [אין התייחסות]
84. מן המקובץ עולה כי מתוך הסוגיות שנותרו לאחר סיכום 19.1.2016, לפי התייחסותו של בנסאיי (מיום 3.2.2016): סוגיה אחת תוקנה (קוד לא חד ערכי); סוגיה אחת טרם הובררה ובנסאיי סבר שאינה מונעת פיילוט (API); לגבי סוגיה אחת לא נמצאה התייחסות (תבניות לא מחיקות); לגבי שש סוגיות (1+5) הביע בנסאיי הסכמה לבצע או לתקן לפני פיילוט ללא תשלום נוסף (אף שלדעתו הן אינן מונעות פיילוט); לגבי סוגיה אחת (אפליקציה) נכתב כי היא תבוצע בד בבד עם הפיילוט; לגבי שאר הסוגיות (1+3), בין אם מדובר לפני הפיילוט ובין אם לאחריו, מבחינת בנסאיי מדובר בביצוע כנגד תשלום נפרד.
85. הודעת הביטול נמסרה, כזכור, ביום 15.2.2016. אין צורך להתמקד בסוגיות שטופלו או שבנסאיי הביע הסכמה לבצע לפני פיילוט וללא תשלום נוסף עוד ביום 3.2.2016 (גם אם סבר כי הן אינן דרושות לצורך יציאה לפיילוט).
86. הדבר מותיר מספר סוגיות אשר אחת מהן לא לובנה עד לשלב הודעת הביטול וכן הוחרגה מחוות דעתו של המומחה (API).
87. להלן ממצאיו של המומחה לגבי הסוגיות שנותרו, לפי הסדר הטכני בו נזכרו בטבלאות:
א. אפליקציית המובייל (User Side, מס' 3) – מדובר בחסר בתכולה ומגבלה משמעותית בנוחות השימוש גם ביחס למקובל בשנת 2015. התשתית הנדרשת להקמת אפליקציה קיימת ובמאמץ משותף ניתן היה להשלימה בתוך כחודש.
ב. העדר תצוגה ללקוח על כסף שהועבר ויכולת טעינת כסף ללא חשבון בנק (User Side, מס' 6A ו-16) – מתאפשר מצב (רכיב 6A) שאינו מציג ללקוח העברה שבוצעה אליו כאשר אינו בעל חשבון (ההעברה נכנסת למאזן ורשומה במערכת האדמיניסטרטור, אך הלקוח לא רואה); לא שוחזר מצב של טעינת כסף ללא חשבון (רכיב 16), ניסיון נבלם על ידי המערכת כנדרש עם הודעה מתאימה.
מיפוי בעיה: קיימת תשתית במערכת המאפשרת הגדרת סוגי לקוחות ברמות הרשאה שונות אך התשתית אינה מחוברת אוטומטית ללקוח בעת אקטיבציה של החשבון אלא משויכת לו ידנית ע"י מנהל המערכת.
במסמך האפיון ובחוזה אין אזכור ספציפי לדרישות אלה. על בסיס דיון מקצועי מאוחר יותר (3.5.15) נשלח מסמך הנחיות/בקשות מקצועי לתובע הכולל את תיאור, הגדרות פרטניות והצרכים בנושא זה (ובלשונו: "Processes & Decision required”). מתשובת בנסאיי ניתן לפרש כי אינו פוסל אך גם לא מתחייב לקבל את שהתבקש ע"י שמש (ובלשונו: “I’ll send you our decision b4 I start :) …first basic processes”). לא קיים מסמך אפיון פונקציונלי, לוגיקה עסקית, פרטני. הדרישות עצמן לגיטימיות מבחינה מקצועית, המחלוקת עסקית. לא מוסד בין הצדדים נוהל מסודר לשינויים והתאמות (CR) כנהוג. הצדדים פעלו א-פורמלית כשותפים ונוצרה אי בהירות אם מדובר רק ב"איך" לממש את האפיון או שמדובר גם ב"מה" נדרש עוד ליישם שהנו בבחינת תוספת חדשה. הבאג הספציפי בעניין העדר תצוגה הוא תקלה. יתר המשמעויות יוצרות אי נוחות ועבודה ידנית למנהל המערכת אך אינן מונעות עבודה מהלקוח. היות ולא סוכמו באפיון )או מפורשות לאחר מכן) לא ניתן להגדיר זאת בגדר תקלה טכנולוגית, אם כי היה רצוי לציין בזמן אמת (מרץ 2015) ע"י בנסאיי כי הוא מצפה תמורתן לתשלום נפרד או לחילופין לחדד כי יבצען רק בשלב ב' ולא בלו"ז הפרויקט.
ג. בקרת תקינות נתוני בנק Swift & IBAN (User Side, מס' 7) – מברור משלים עלה כי בגרסה מתקדמת של האפיון ותכתובת נלווית סוכם על בקרה תפעולית ידנית שתבוצע מחוץ למערכת ע"י העברת סכום קטן ללקוח אשר יאשר בהיזון חוזר את הסכום המדויק שקיבל. היזון חוזר שכזה יכול שיהיה במייל אך רצוי שיהיה כאינדיקציה המוזנת במערכת. גם במימוש של אינדיקציה ניתן להשלמה באופן פשוט יחסית, הוספת שדה ובדיקה לוגית.
ד. אבטחת מידע בהשוואה למוסכם (User Side, מס' 12) – המחלוקת הייתה אם כלול בתכולה מרכיב אבטחה נוסף מעבר לקיים (קוד משתמש וסיסמא וכןPincode לקשר בין לקוח לסוחר), למשל כמו Two Factor Authentication הנהוגים בחלק מהתעשייה הפיננסית. אף כי הבקשה לגיטימית מבחינה מקצועית, לא נמצאה עדות להיותה חלק מהאפיון או להסכמה מאוחרת.
ה. Euro כמטבע מחדל (Admin Side, מס' 4) – המערכת אופיינה נבנתה כרב מטבעית ללקוחות אך תוכננה ועוצבה פנימית וחישובית כעובדת ביורו כמטבע "מכנה משותף", הן להגדרת פרמטרים וברירות מחדל ע"י המתפעל והן בעת ביצוע טרנזקציות: הסכומים מומרים בשער חליפין ועוברים דרך יורו וחזרה. הדבר יוצר אתגר/קושי תפעולי במצבים שונים כגון: (I) עיגולים חישוביים שגויים של שברי סנטים מעבר לנקודה עשרונית בעת המרה כפולה ומיותרת של העברות באותו מטבע; ו-(II) בעיית תצוגה בהגדרת limits למשיכה והעברה או של עמלות מינימום: מנהל המערכת מגדיר סכום עגול ביורו והלקוח רואה סכומים לא יפים ולא ברורים לו במטבע בו מנהל את חשבונו.
סוגית עיגולים שיוצרת סכום לא מדויק הינה בגדר תקלה כספית שחייבת תיקון. לעניין הטענה המרכזית: מדובר בתהליך המאופיין באופן לא אלגנטי ולא ידידותי לשימוש. ניתן לפותרו חלקית במסגרת הקיים ע"י הודעות מתאימות ללקוח וחינוך מנהל מערכת להתחשב במטבע המקור בעת קביעת סכומי המגבלה. הפתרון המיטבי הוא תכנון שונה, אך זה מחייב שינוי תשתיתי ומשמעותי. לא מדובר בסוגיה המונעת שימוש במערכת והיות ואינה סותרת את מסמכי האפיון ועלתה רק בשלב מאוחר יחסית אין לסווגה כתקלה, אלא כנושא שמומלץ היה לשפרו בהמשך.
ו. תבניות לא מחיקות (Admin Side, מס' 7) – שוחזר במפגש ובמבדק – לא ניתן למחוק תבנית. תקלה.