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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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