ניהול איכות מה זה בכלל, לשם מה ? עקרונות מערכת ניהול איכות בדיקות קבלה של התוכנה

1. ניהול איכות מה זה בכלל, לשם מה ? עקרונות מערכת ניהול איכות בדיקות קבלה של התוכנה

2. Software Vs. “Industrial” Engineering? SoftwareIndustrial Eng Relatively new Well proven New Methodologies Rigid Method Welcome Changes Rigid, Immovable Predictability is impossible Req. should be changeable Req. are rigid People Oriented Process Oriented Cheap Construction Cheap Planning

3. Software Vs. “Industrial” Engineering? SoftwareInd. Eng Iterative Predictive After all software is supposed to be SOFT

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

5. הגדרות(2) • רמז לשוני בין הבטחת איכות כללית והבטחת איכות תוכנה ניתן לראות במחויבות הספק למוצרים השונים: • במוצרים רגילים מבטיח היצרן מוצר נקי מפגמים. • במוצרי תוכנה מצהיר היצרן שהוא מוכר את התוכנה "כמו שהיא" וללא כל מחויבות שהמוצר נקי משגיאות תוכנה.

6. עקרונות התהליך ההנדסי

7. שילוב האיכות במחזור החיים • תיאור קווי ← עוקב • מפל המים • תהליך V • תיאור איטרטיבי←התפתחותי • אין תהליך טוב או נכון. ההתאמה היא לצוות, לפרויקט.

8. מחזור חיים ← מודל מפל המים תהליך עוקב, סדרתי: דוחה הבדיקות לסופו של התהליך

9. מחזור חיים ← מודלV Verification/Validation=V תהליך עוקב, אך הבדיקות משמשות גם לבדיקה של הדרישות, המסמכים

10. מחזור חיים ← מודלחילזון/ספירלי מבטא את האופי האיטרטיבי←התפתחותי של הפיתוח בניית סדרה של אבי טיפוס עד הגעה לפתרון UML,SCRUM קשה לניהול

11. הבטחת איכות תוכנה מחזור החיים של מוצר איכות המוצר איכות מוצר תוכנה איכות מוצר רגיל מחזור חיים פיתוח ייצור תפעול

12. הבטחת איכות תוכנה • עלות תיקון תקלה על פי סקר שבוצע על ידי IBM

13. כעת, כאשר למדנו: • מה נדרש מן התהליך • כיצד פועל התהליך • כיצד לשפר אותו • עלינו להקים: • מערכת ניהול איכות • Quality Management System

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

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

16. תהליך הפיתוח הבסיסי ← מסגרת • מסגרת ← מודל מחזור החיים • משלבים את נושאי האיכות כחלק ממחזור החיים, במקביל לכולשאר הפעילויות • מה עושים הלכה למעשה ? בשקפים הבאים.

17. תהליך הפיתוח הבסיסי ← מתודולוגיה • = אוסף שיטות עקביות וסבירות המקובלות בענף זה • יתרונות: • שפה אחידה • מניעה של שגיאות בשלבים מוקדמים • צמצום שגיאות אותן יש לתקן לאחר מסירה • כלים לניהול פעולות בשגרה • מסגרת ניהול: זמן, תקציב • רשימת תיוג • חסרון: הוספה של תקורה • דוגמאות:מפרט דרישות Requirement Specification • מפרט מבחן קבלה Acceptance Test Plan

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

19. תהליך הפיתוח הבסיסי ← GMP - Good Practice Manufacturing • הוכחת תקפות Validation← • התאמה לדרישות ביטוי כולל לסדרת פעילויות אשר מטרתן להדגים ולתעד כי מוצר מסוים יכול להיות מיוצר בצורה מהימנה ועל פי התכנון, כולל בתנאים הגרועים ביותר worst case scenario • של כול הפרויקט אל מול דרישות הלקוח • שלמות מול התיעוד • עבודה אחידה לאורך זמן • עבודה על פי התקנים

20. תהליך הפיתוח הבסיסי ← ניהול תצורה • Configuration Management • ניהול "אינוונטר" של כול המערכת • זיהוי Identification • בקרת שינויים Change Control • יכולת מעקב/עקיבות Traceability

21. תהליך הפיתוח הבסיסי ← ניהול תצורה • זיהוי • זיהוי של כול מרכיב: מסמך, תוכנה, בדיקה, תיעוד • הקמת מנגנון בקרה ורישום אחר זיהוי • עדכון Variant/Patch • מול • גרסא חדשה New version • עקיבות מלאה (קדימה ואחורה") • המוצר (הנמסר) מוגדר ב← Build Status

22. תהליך הפיתוח הבסיסי ← ניהול תצורה • בקרת שינויים • כלים לניהול התצורה (ודאי כאשר יותר מאחד) • ספרייה מנוהלת SourceF • תהליך Workflow ← סקר חוזה • יכולת מעקב/עקיבות Traceability

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

24. יישום של מערכת ניהול איכות • להכשיר מומחים ומנהלים • להכשיר את כול הצוות ולהניח לו למצוא את דרכו • לתעד באופן מלא, להפוך לתקן עבודה (מחייב) • "סדר וניקיון" • תקן ת"י 2000ISO 9000[ (01) עמודים 696, 697] • משפחה של תקנים לניהול איכות בכול התעשייה • 9001/3 ניהול איכות ב-תוכנה המדגישה: • העיצוב הוא העיקר (לא הייצור) • ייחודיות בתהליך הפיתוח/מחזור החיים • ניהול התצורה

25. תמיכה של תקן ISO 9000-3(1) • מחזור החיים ← הנחייה לשימוש באחד המודלים • מתודולוגיה ← כלים, טכניקות, שיטות כלל ארגוניות • עבודת צוות, שקיפות • אימות ← לגבי כול שלב • תקפות ← לגבי כול הפרויקט מול הלקוח • כל דרישה תהיה מוגדרת באופן המאפשר לבדוק כי היא הושגה • דרישות לתיעוד מלא ← המתחיל בזיהוי הדרישות • בדיקות על ידי הספק על בסיס תיעוד • ניהול תצורה: בקרת מסמכים, זיהוי התחילי

26. תמיכה של תקן ISO 9000-3(2) • תחזוקה ← ניהול התצורה • פיתוח תוכנה ← הכול תלוי בהגדרה של מחזור החיים • מתוך מחזור החיים: נהלים, פירוק למטלות • המינון של הנהלים בהתאם לאופי הפרויקט: • גודל הפרויקט • סוג הפרויקט: פיתוח, אחזקה, אבטיפוס • טכנולוגיות הדור הרביעי (אין עיצוב) • חבילות יישומים/תוכנה ← סוגיית ההתאמות • השלב בתוך הפרויקט: תיכון, עיצוב, תכנות • התאמה של הבדיקות אל אופי הפרויקט

27. מימוש מערכת האיכות - עצות לדרך -

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

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

30. הבקרה של מערכת האיכות • התנהגות על פי יעדים: • מדיניות ← המשקפת את התועלת העסקית • נהלים • תפקידים ותחומי אחריות ← כולל נציג הנהלה • תהליך מתמיד של ניטור: • מבדקי איכות Qualiy Audits • מדידהMeasurement • מנגנון לפעולה מתקנת Corrective Action Mechanism • סקרי הנהלה Management Reviews

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

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

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

34. מבדקים פנימיים • Internal Quality Audits • תדירות קבועה מראש כחלק מתוכנית העבודה • ביצוע על ידי בעלי הכשרה + בקרה על ידי נציג הנהלה • שילוב עם מנגנוני הדיווח על תקלות Help desk • פעולות מתקנות • זיהוי בעיות • חקירת הבעיות • תיקון הבעיות • חיפוש מקרים אחרים • ניתוח המשמעות הרחבה • זיהוי הבעיה השורשית • אמידת הסיכון בחזרה על האירועים • פתרון לבעיה השורשית • עדכון תוכנית המבדקים הפנימיים • אמידה של חומרת הבעיה ← העלאה לפתרון הנהלה

35. סקר הנהלה • Management Review • דיון מובנה • תדירות קבועה מראש כחלק מתוכנית העבודה • משתתפים בעלי עניין + בקרה על ידי נציג הנהלה • מבוסס על: • המבדקים הפנימיים • תוצאות המדידה Metrics & Criteria • בקרת התיעוד • רשומות האיכות Quality Records ← תיעוד הביצוע

36. שיפור תהליכים • GQM - Goals, Questions & metrics • מחזור PDCA - Plan, Do, Act & Check • ההנחה כי כול המרכיבים קשורים הירארכית • ניתוח הפגמים, התקלות: • איסוף מכול השלבים ניסיון להבין איך לשפר, הטכניקה: • תרשים שדרת הדג • יומן שגיאות • ניתוח התקלות על פי: • Upstream ← בעיה בתהליך הפיתוח • Downstream ← להתרכז בבדיקה של נקודות החולשה • תוצאות המדידה Metrics & Criteria

37. בדיקות קבלה של התוכנה

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

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

40. קבלת המוצר • תהליך הקבלה Acceptance Test • הלקוח מגדיר את מבחני הקבלה (האובייקטיביים) • הספק מאמת את המוצר המוגמר ((Integration • הלקוח מקבל את המוצר

41. בדיקות תוכנה • רמות של הבדיקה • ע"י צוות הפיתוח: • UNIT • ע"י צוות הבדיקות (חיצוני לצוות הפיתוח): • Functional ← בדיקה פונקציונאלית של כול אוביקט • INTEGRATION ← של כול תת מערכת • SYSTEM ← של כול תתי המערכות גם יחד • על ידי המשתמש • Acceptance

42. תוכנית בדיקות קבלה • תכנון הבדיקות בסיום שלב האפיון • הבסיס: • תיאורי הפונקציות • התהליכים • המדריך למשתמש • תוכנית הבדיקות (עמ' 773) • משאבים, לו"ז, ניהול סיכונים • אישורים • ATP - Acceptance Test Planatp_xxx_#(version) • סיכום תוכנית הבדיקות (עמ' 786) • אישורים • ASUM - Acceptance Summary

43. בדיקות פונקציונאליות • בסיס נתונים נפרד • הבסיס הוא מסמך העיצוב(אשר עבר אימות מול מסמך האפיון) • אירועים והשוואת התוצאה אל זו המוגדרת בעיצוב • פעולות ונתונים לא חוקיים • עבודה על פי טפסים לתכנון וביצוע בדיקות • טבלת CRUD - Create Read Update Delete • מטריצת כיסוי ← תקינות היחס בי שני גורמים: • קלט מול פלט • תוכנית מול משתמשים • תהליך מן האפיון מול פונקציה מן העיצוב • פונקציה מול טבלה בבסיס הנתונים • CRUD מול טבלאות בבסיס הנתונים

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

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

46. בדיקות קבלה • בסיס נתונים נפרד • הבסיס הוא מסמך העיצוב • אירועים והשוואת התוצאה אל זו המוגדרת באפיון • פעולות ונתונים לא חוקיים • עבודה על פי טפסים לתכנון וביצוע בדיקות • טבלת CRUD - Create Read Update Delete • מטריצת כיסוי ← תקינות היחס בין שני גורמים: • קלט מול פלט • תוכנית מול משתמשים • תהליך מן האפיון מול פונקציה מן העיצוב • פונקציה מול טבלה בבסיס הנתונים • CRUD מול טבלאות בבסיס הנתונים

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

48. שאלות ? חומר רקע (1): חלק 3 פרקים 1 עד 8