הבטחת איכות בסביבות הענן

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

17/08/2016 09:45
אריה עמית, יועץ אסטרטגי וניהולי בכיר ב-I-amIT

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

בהתבססם על מסרים שיווקיים של ספקים, משתמשים מתפתים לחשוב ששימוש בפתרון SaaS דורש פחות מאמץ בתחום הבדיקות והבטחת איכות (QA) מאשר שימוש בסביבת המחשב של הארגון (On-Premises), דבר שאינו נכון.

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

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

הניתוח

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

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

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

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

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

הבנת עלות-תועלת

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

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

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

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

הבטחת ציות לתקנות (Compliance)

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

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

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

תגובות

(0)

כתיבת תגובה

האימייל לא יוצג באתר. שדות החובה מסומנים *

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

אירועים קרובים