ניתוח אפיון | ליאור שם טוב

רקע 

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

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

שלב ראשון – קבלת מסמך האפיון

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

מנתח המערכות, לאחר קבלת כל ההערות מעדכן את האפיון בהתאם ולאחר מנגנון של אישורי אפיון הוא מעביר את המסמך לתחילת עבודה של בעלי העניין. הבודק (אשר מכיר את האפיון במסגרת ה-CDR/DR) מגיע עם הבנה גבוהה לגבי מבנה המערכת, הפן העסקי, מחוזק בתשובות אשר קיבל לשאלותיו ויכול לגלוש לשלב השני ביתר קלות, כאשר רכיבי המערכת ומהות המערכת מובנת ובהירה יותר.

 שלב שני – חלוקת האפיון

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

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

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

שלב שלישי – ניתוח נושאים הנדרשים לבדיקה

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

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

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

 שלב רביעי – בקרה

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

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

סיכום

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

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

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