1 / 22

מדדים ומטריקות ליעילות תהליכי פיתוח

מדדים ומטריקות ליעילות תהליכי פיתוח. QualiTest Software Testing מאת: אלי מרגולין, מנכ"ל. -Metrics מטריקות. “You can’t control what you cannot measure”. מדדי איכות. הקדמה + פילוסופיה מנקודת הראות ( POV ) של הבדיקות המצגת מתייחסת למקרה לימוד ספציפי ומימצאיו. מדוע יש למדוד איכות ?.

jabir
Télécharger la présentation

מדדים ומטריקות ליעילות תהליכי פיתוח

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. מדדים ומטריקות ליעילות תהליכי פיתוח QualiTestSoftware Testing מאת: אלי מרגולין, מנכ"ל

  2. -Metricsמטריקות • “You can’t control what you cannot measure”

  3. מדדי איכות • הקדמה + פילוסופיה • מנקודת הראות (POV)של הבדיקות המצגת מתייחסת למקרה לימוד ספציפי ומימצאיו

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

  5. הצורך במטריקות • SEI’s SW-CMM (Capability Maturity Model): • Recommend set of measurements for each KPA (Key Process Area). • Level 4 Requires the organization to establish a planned and systematic mechanism for measuring software product and software process quality.

  6. דוגמאות למטריקות

  7. מה היא מטריקה טובה ? • תומכת במטרות הארגון. • משמעותית. • בסיס רחב ומשותף להסכמה. • תיאורית. • חיובית. כאן הקושי

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

  9. POV בדיקות – השתלבות בתהליך • פיתוח פרויקט מהראשית – WF, ספירלי, איטראטיבי • מוצר בתחזוקה + שינויים. תכנון קידוד בדיקות

  10. POV בדיקות – הנחות יסוד • דיווח תקלות (ללא שינויים) אמין • תקלות אפיון נפתחות ע"י הפיתוח, הבדיקות והמשתמש • תקלות אפליקציה נפתחות ע"י הבדיקות והמשתמש • נעשה שימוש קלאסי בדיווח חומרה • כל הבדיקות הנדרשות אכן מתוכננות (כיסוי מלא) • כל הבדיקות המתוכננות אכן מורצות (כיסוי מלא) הערה: אחרת, יש לבצע נירמול.

  11. POV בדיקות – הנחות יסוד מערכת דיווח תקלות מערכת תכנון והרצת בדיקות כתיבת מפרטי הבדיקות מחזור בדיקות -ראשון אפיון ופיתוח המערכת/שינויים מחזור בדיקות -שני מחזור בדיקות -שלישי מערכת מבצעית

  12. POV בדיקות – מטריקות בסיסיות • כמות צעדי תכנון (=מורכבות) ביחס להיקף הפיתוח הכולל • התפלגות תקלות ע"פ החומרה (נזק * סבירות להתרחשות) = התנהגות נורמלית • יחס נורמלי בין תקלות אפיון לתקלות אפליקציה ממצא 2003: 40K צעדי בדיקה על 140ש"א פיתוח (8 בבדיקות) ממצא 2003: 2000 תקלות אפליקציה (מנורמל מ- 33% של סבב 1 לשלושת הסבבים) 1250 תקלות אפיון

  13. מטריקות בסיסיות – ניתוח תקלות במקרה שלנו EEE std 1044 ממיין את רמות החומרה ל- 5 46% השלמה מסבב ראשון 30% מהם לא היה ניתן לבצעם

  14. POV בדיקות – מטריקות מתקדמות • חישוב זמני הרצה להמשך • חישוב זמני תיקון תקלות • איכות האפיון ותרומת צוות הבדיקות • איכות האפליקציה • חישוב זמני תכנון בדיקות נדרשים

  15. מטריקות מתקדמות – חישוב זמני הרצה האם בדקנו את הכול ?כיצד זה ישפיע על לוחות הזמנים של המחזורים הבאים ? ממצא 2003: 3 דקות לצעד 70K= צעדי הרצה העבר למחזור הבא ! Planned Actual

  16. מטריקות מתקדמות – חישוב זמני תיקון • 32% צעדים בלבד הורצו בהצלחה. • 472 תקלות נמצאו. • מסקנה: כ- 1,000 תקלות יתגלו בסבב 2, כלומר יש להיערך בהתאם בצוות הפיתוח. • בחלוקה לרכיבים אפשר למצוא את הרכיבים הבעייתים ולהקדים תרופה למכה. • סבב 3 יתכן ויהיה מלא וידרש סבב רביעי (סבב 1 היה חלקי ביותר) – לפחות עוד 500 תקלות.

  17. מטריקות מתקדמות – איכות האפיון • 1250 תקלות אפיון , מהם 25% שווא התגלו. • לכל 40 צעדי תכנון מתגלה תקלת אפיון אמיתית. • בחלוקה לרכיבים אפשר למצוא את הרכיבים הבעייתים ולבצע פעולה מתקנת. • צוות הבדיקות תרם 60% מתקלות האפיון (אותו יחס בשווא).

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

  19. מטריקות מתקדמות – חישוב זמני בדיקות • בכל יום בדיקה מהנדס בדיקות ממוצע מתכנן 50 צעדי בדיקה. בכלל זה נלקח בחשבון: • עקומת הלימוד • מציאת תקלות אפיון • כתיבת הצעד • תיקון הצעד במקרה של שינוי אפיון הערה: המערכת כולה מנוהלת ב- ClearCase

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

  21. לאחר מספר מחזורים-מידת יציבות המערכת האם המערכת יציבה?מתי המוצר ישוחרר לשוק ?האם זה בטוח?.... Stability Point Production Point Total Closed

  22. t1 t2 t3 TE(t1) = 90.9 TE(t2) = 76.92 Pre-Release defects TE(t3) = 66.66 TE(t) = Pre-Release defects + Post Release defects TE-Testing Effectiveness Metric-Defect Found Percentage Pre-Release Defects Post-Release Defects Time Production

More Related