המאמר המקורי מכאן.
הצורך בפיתוח מהיר הותיר פשרות בתהליך הפיתוח, כמו גם חוסר במיומנות. זה מעלה את מספר הבאגים כולל אלו שלא נמצאים ומציב קשים בתחזוק התוכנה, וזה מצדו גרר השקעה בבדיקות (כמו ביכולות הבודקים, כלים אוטומאטיים וכד'). אבל בנוסף צריך להעריך את התהליך הבדיקות, חוזקות וחולשות, ולהבין את הסיכונים בו.
ה-ODC זו שיטה למיון (קלסיפיקציה) של באגים כמו גם מושגים העוזרים לנתח את המידע מהקלסיפיקציה. ביחד עם טכניקות ניתוח מידע המתאימות לתהליך הפיתוח, ODC נותן כלים להעריך את התהליך ואת המוצר. הכוונה ב"אורתוגונלי", או "מצטלב בזוויות ישרות", היא לאופי הבלתי-מיותר של האינפורמציה הקיימת במאפייני הבאג ובערכים שלהם שמשתמשים בהם למיון של באגים. המאפיינים האלה וערכיהם מסוגלים לחשוף בעיות בפיתוח. הכינון וההערכה של ה-ODC נעשה לא על-ידי מנהלים אלא על-ידי האנשים הטכניים (פיתוח, בדיקות וכד').
תהליך הישום של ה-ODC:
- התחייבות ההנהלה ליישום התהליך והלקחים שינבאו ממנו.
- המיון חייב להיעשות על-ידי הצוותים הטכניים ולהישמר בבסיס נתונים קל להפעלה.
- הבאגים הממוינים מאומתים על בסיס קבוע בכדי להבטיח עקביות ונכונות המיון.
- הערכה של המידע הנ"ל צריך להתבצע במחזוריות קבועה. שוב – איש טכני המכיר את המוצר צריך לעשות זאת. כלי ויזואלי חייב להיות לרשותו.
- יש לתת לממיינים פידבק על המיון, ועל התוצאות שלו – בכדי שימצאו צעדים לשיפור.
- יש לעשות פריוריטיזציה של הטעון שיפור, ולהמציא צעדים לתיקון.
מיון ואימות של הבאגים
ישנן שתי נקודות של מיון.
הראשונה כשהבאג מתגלה. מגלה הבאג ממלה מאפיינים של הפעילות (activity) בה התגלה הבאג, מה שעורר (trigger) אותו, והשפעה (impact) שלו.
- הפעילות היא הפעילות בה הבאג התגלה, כמו קוד review, בדיקות פונקציונליות וכד'.
- הטריגר הוא הסביבה או התנאים שהיו חייבים לקרות בכדי שיחשפו את הבאג, או הצעדים לשחזור.
- ההשפעה היא ההשפעה הנראית או האקטואלית ללקוח.
השנייה היא בעת תיקון הבאג. המאפיינים הם המטרה (target), סוג הבאג (type), המתאר (qualifier), מקור (source) וותק (age).
- מטרה היא הזיהוי במישור הגבוה (בעיית דיזיין, קוד וכד') של הישות המתוקנת.
- הסוג מתייחס לטבע התיקון של הבאג.
- מתאר: האם התיקון הוא בגלל קוד או אינפורמציה חסרים, לא נכונים או חיצוניים.
- מקור: האם הקוד הוא פנימי של הפיתוח, שימוש חוזר מספריה, מיובא מפלטפורמה אחרת, אאוטסורס או ונדור.
- ותק: האם הקוד חדש – גרסה אחרונה? ישנה? שנכתב מחדש או מתוקן?
למידע נוסף לחצי כאן.
יש להשתמש המיון בשדות מתאימים בכלים הקיימים, ולהדריך היטב את הממלאים. ניתן לאמת את הנתונים ב-אגריגציה (aggregation): אם אנו מוצאים סתירות בנתונים יש לבחון את המיון מחדש.
הערכת המידע
אחרי אימות הנתונים אנו בוחנים אותם, לא דיווח באג אחד בכל פעם אלא ברמה גבוהה יותר של מגמות ותבניות. הניתוח מתבסס על היחס בין מאפיינים של מיון דיווח הבאגים של ה-ODC כמו גם נתונים נוספים של דיווח הבאג: קומפוננטה, חומרה ותאריך פתיחה. למשל בכדי להעריך יציבות גרסה יש לנתח את היחס בין סוג (type) הבאג, מתאר (qualifier), תאריך פתיחה וחומרת הבאג. לעומת זאת טרנד של באגים המתויגים כ"פונקציה חסרה" או גדילה בכמות דיווחי הבאגים בחומרה גבוהה עלולים להוות אינדיקציה שיציבות המוצר נגרעת.
ברור שיש בעיה בנתוני הפיתוח לאותה גרסה – כנראה שהנתונים, המוכנסים בתיקון הבאג, יגיעו לכמות מספקת לניתוח רק בשלב מתקדם בפרויקט. לכן רק בסוף גרסה נקבל תמונה מלאה באמת.
מי שרוצה כללים יותר פרקטיים ליישום ילחץ כאן.
בהמשך המאמר יש דוגמאות. אני מקווה להרחיב בהמשך, כולל יישום שאני הייתי שותף לו.
אין תגובות:
הוסף רשומת תגובה