הכל התחיל כשמנהלת הכספים שלי נסעה לחו"ל

מאת : שחר פרלמן מנכ"ל מתודה מחשבים בע"מ

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

לגלוש לחשבון באינטרנט אינה משימה קלה כלל ועיקר:

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

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

הקשתי:

מספר משתמש, שדה זיהוי, מספר חשבון, מספר סניף, מספר תעודת זהות, כולל ספרת ביקורת.

ENTER

בשלב זה הגיע דבר, ששבר אותי סופית, ובגללו נכתב מאמר זה:

על המסך הופיעה הודעה בסגנון:" אחד השדות שהקשת שגוי נסה שנית".

בנוסף נמחקו כל שדות ההקשה שהקשתי.

מבולבל ניסיתי שוב. ושוב נמחקו כל השדות.

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

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

אם כך מה קרה במערכת המחשב שם בבנק?

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

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

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

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

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

לאחר אישור מסמך הייזום (מאמר זה מתעלם מהיבטים של לו"ז ותקציב. במאמר אחר אתייחס להיבטים אלה) אושר בעצם השלב הראשון של הפרוייקט.

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

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

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

באפיון יש להתייחס לנושאים כמו :

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

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

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

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

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

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

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

בהזדמנות זו כדאי להזכיר, שיש שתי בדיקות חשובות, שהן מהות שלב הבדיקות:

• האם אנחנו בונים את המערכת הנכונה.
• האם אנחנו בונים את המערכת נכון.

 

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

ברצוני להמליץ על שני אלמנטים חדשים לשלב הבדיקות:

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

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

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

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

 

 

 

 

 

tweet[Google] Follow @leadersnet

 

 

מנהיגים ברשת

www.leadersnet.co.il

leaders@leadersnet.co.il

© כל הזכויות שמורות ל"מנהיגים ברשת"  יוני 2004. החומר מותר לשימוש אישי בלבד. אין לעשות בחומר שימוש מסחרי/עסקי ו/או להפיצו בכל דרך שהיא (להוציא באמצעות יצירת קישור למאמר ספציפי  ולעמוד הבית במקביל) מבלי לקבל רשות מפורשת בכתב מהנהלת האתר