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

2. Software Industrial Eng
Software Vs. “Industrial” Engineering?
Software Industrial 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. After all software is supposed to be SOFT
Software Vs. “Industrial” Engineering?
Software Ind. Eng
Iterative Predictive
After all software is supposed to be SOFT

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

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

6. עקרונות התהליך ההנדסי הנדסה "קלסית" הנדסת תוכנה
תכנן (עד הסוף) לפני בנייה (ביצוע)
הגדר מחזור החיים
ודא התאמה של החלקים
מפרט של הממשקים
תכנן מבחנים לפני התחלת ביצוע
תכנון מראש של בדיקות קבלה – מבחן הקבלה
בדוק תיכון (היתכנות) לפני התחייבות
היתכנות של העיצוב Design
בקרה מתמדת אחר השינויים (בקרת תצורה)
ניהול התצורה הוא חלק מניהול הפרויקט
ודא לספק איכות נכונה (מוגדרת/דרושה)
← בקרת איכות Quality Control
← אבטחת איכות Quality Assurance
איכות של: ביצועים, פונקציונליות, UI
שיפור מתמיד: משוב והיזון חוזר
עיקרון המדידה = הכימות
הגדרת יעדים ← מבחן הקבלה
מדיניות איכות

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

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

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

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

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

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

13. Quality Management System
כעת, כאשר למדנו:
מה נדרש מן התהליך
כיצד פועל התהליך
כיצד לשפר אותו
עלינו להקים:
מערכת ניהול איכות
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. יישום של מערכת ניהול איכות
להכשיר מומחים ומנהלים
להכשיר את כול הצוות ולהניח לו למצוא את דרכו
לתעד באופן מלא, להפוך לתקן עבודה (מחייב)
"סדר וניקיון"
תקן ת"י 2000 ISO [ (01) עמודים 696, 697]
משפחה של תקנים לניהול איכות בכול התעשייה
9001/3 ניהול איכות ב-תוכנה המדגישה:
העיצוב הוא העיקר (לא הייצור)
ייחודיות בתהליך הפיתוח/מחזור החיים
ניהול התצורה

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

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

27. מימוש מערכת האיכות - עצות לדרך -
AGLE/SCRUM/XTREME - שלושת המערכות הללו שעובדות כיום , באים לעבוד עם הלקוח , וכל פעם הלקוח עובד על הקטע שנתנו לו

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

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

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

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

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

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

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

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

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

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

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

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

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

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

42. תוכנית בדיקות קבלה תכנון הבדיקות בסיום שלב האפיון הבסיס:
תיאורי הפונקציות
התהליכים
המדריך למשתמש
תוכנית הבדיקות (עמ' 773)
משאבים, לו"ז, ניהול סיכונים
אישורים
ATP - Acceptance Test Plan atp_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
שאלות ?
חומר רקע (1): חלק 3 פרקים 1 עד 8