יום שבת, 5 באפריל 2008

טרייסביליות

כיום יש כלים טובים (למשל ב-Quality Center) למעקב אחרי דרישות. אני אתייחס לצדדים החשובים, תהא ההטמעה אשר תהא.

אביא כאן את העיקר:
  1. כל הדרישות חייבות לבוא משלב ה-MRD עם סעיפים, סעיף פר דרישה, ת-סעיף לתת-דרישה, וכל סעיף צריך להיות עם סמן ייחודי (נניח MRD-403-24-001, MRD זה המסמך, 403 זו הגרסה, 24 הסעיף ו-01 הוא תת-הסעיף). מומלץ לקפוץ בין מספרים בהפרש מסויים, למשל מ-01 ל-05, למקרה שמשהו ישכח.
  2. יש למפות כל דרישת השיווק (MRD) לדרישה של מהנדס המערכת (SysRD). לכן דרישות המערעת אמורות להיות:
    SysRD-403-24-01 בהתאמה. אם יש יותר סעיפים כאן אפשר להוסיף בסוף a, b וכד'.
  3. יש למפות כל דרישת מהנדס מערכת לדרישה של הפיתוח. שוב - אותו פורמט של מספרים.
  4. יש למפות כל דרישת מהנדס מערכת לדרישה של בדיקות. שוב - אותו פורמט של מספרים.
  5. מסמך הבדיקות יכלול קישור גם למהנדס המערכת וגם למסמכי הפיתוח.
  6. יש למפות את הבאגים למסמך הבדיקות.
מה יוצא לנו מזה?
  1. שום דרישה לאורך התהליך אינה הולכת לאיבוד.
  2. יש סטטוס עדכני לכל דרישה (בעיקר אם יש כלים שמגבים את זה): כמה באגים פתוחים, מה החומרה שלהם וכד'.
  3. אפשר לראות פר דרישה כמה באגים היו בה, האם זמני הבדיקות היו כפי שציפינו.
  4. יהיה אפשר לדעת בעתיד מה מצב כל דרישה (למסמך סיכום הבדיקות, או חקירה מהשטח).

אין תגובות:

פרסום תגובה

רשומות פופולריות