תומכים והבטחת איכות תוכנה תהליכים Support Processes and Software Quality Assurance ד, 1999-2008 תהליכים תומכים והבטחת איכות - 1
העניינים תוכן סקרים תוכנה אחזקת שינויים וניהול תצורה ניהול תוכנה איכות איכות תוכנה הבטחת ד, 1999-2008 תהליכים תומכים והבטחת איכות - 2
ב ד, סקר תוצרי הפיתוח לפני הרצה קרת (Review) 1999-2008 הגדרה (IEEE, 1990) תהליך או מפגש שבמהלכו מוצג תוצר, או אוסף של תוצרים, לצוות הפרויקט, למנהלים, למשתמשים, ללקוחות או לבעלי עניין אחרים לצורך קבלת הערות ואישור סקרים סוגי סקרים (סקרי תיכון) פורמאליים Reviews Formal (Design) משמשים כאקט פורמאלי לסיום שלב בפיתוח ולאישור המעבר לשלב הבא בדרך כלל מתבצעים מול הלקוח או מול ההנהלה סקרי עמיתים Reviews Peer משמשים לבחינת תוצרים ספציפיים בפיתוח מתבצעים באמצעות קבוצת "עמיתים מקצועיים" של המפתח, שאינם שותפים פעילים לפיתוח התוצר עצמו דעת מומחים Opinion Expert משמשים לקבלת חוות דעת ממומחים חיצוניים בתחום הספציפי לעריכת סקרים שיטות סריקה (Walkthrough) ביקורת (Inspection) תהליכים תומכים והבטחת איכות - 3
מקובלים בתוכנה סקרים ד, 1999-2008 פורמאליים סקרים סקר דרישות Software Requirements Review (SRR) התוצר הנסקר: מפרט דרישות התוכנה (SRS) סקר תכן Software Design Review (SDR) התוצר הנסקר: מפרטי התכן סקר מוכנות לבדיקות Test Readiness Review (TRR) עמיתים סקרי התוצרים הנסקרים: מפרטי הבדיקות, סביבת הבדיקות סקירת קוד Walkthrough Code Inspection / Code התוצר הנסקר: מקור קוד תהליכים תומכים והבטחת איכות - 4
(walkthrough) סריקה 1999-2008 ד, לאימות תוצרי ביניים בפיתוח שיטה מפורט בתוצר, שורה אחר שורה עיון מפרט דרישות תכן קוד מקור לבדיקת חלק קטן, מתאימה הסריקה מטרות גילוי שגיאות בחינת חלופות שהוצעו מתן משוב לצוות הפיתוח פורום לדיון ולהצעות יחסית, של המערכת (כולל הפרת כללי תיכון/תכנות) כלי פיתוח, טכניקות, נסיון ביישום... ורישומן הסריקה נועדה לאיתור שגיאות, ולא לתיקונן! תהליכים תומכים והבטחת איכות - 5
ביקורת (Inspection) ד, אימות לתוצרי ביניים בפיתוח שיטת כיסוי רחב יותר מאשר סריקה התוצר הנסקר הוא בדרך כלל מסמך, (ניתוח, תכן) או קובץ מסמכים, המסכמים שלב בפיתוח התוצרים מוצגים ע"י האחראים ליצירתם (moderator) הסקר מבוצע ע"י ועדת סקר + יו"ר 1999-2008 סקר מול לקוח סקר מול הנהלה סקר עמיתים ועדת הסקר מורכבת מאנשי מקצוע בדרג ובתחום המקצועי של האחראים לתוצרים תהליכים תומכים והבטחת איכות - 6
ד, (Fagan, 1986) Fagan Inspection קצרה של הנושא הצגה המסמך למשתתפים הפצת מבוא Overview לומדים את המסמך ורושמים הערות המשתתפים רצוי להעביר הערות מראש הכנה Preparation על המסמך מעבר איתור שגיאות (לא תיקון!) והמלצות סיכום (רצוי בהתאם להערות שהועברו מראש) ביקורת Inspection 1999-2008 "שיפוץ" Rework מעקב Follow-up לתוצרים מתייחס לכל ההמלצות האחראי המלצות שאינן מקובלות נימוק מפורט. המלצות מקובלות קביעת הפעולות לביצוע Items),(Action האחראים ומועדי השלמה ביצוע פעולות התיקון שכל ההמלצות זכו להתייחסות לוודא שכל הנושאים לפעולה נסגרו במועד לוודא תהליכים תומכים והבטחת איכות - 7
העניינים תוכן סקרים תוכנה אחזקת שינויים וניהול תצורה ניהול תוכנה איכות איכות תוכנה הבטחת ד, 1999-2008 תהליכים תומכים והבטחת איכות - 8
ד, The Legacy תזכורת: Crisis לא מתות, תוכנות משודרגות... רק החלק היחסי של הה"אחזקה" מסך העלות הכוללת של מחזור החיים? = מהו "אחזקה" = תיקונים, התאמות, שידרוגים. אחזקה פיתוח + אחזקה 1999-2008 100% 90% 80% 70% 60% 50% 40% 30% 20% 10% 0% Early 1970s Early 1980s Late 1980s Early 1990s Source: R.C. Seacord, D.Plakosh, G.A. Lewis, Modernizing Legacy Systems, 2003 תהליכים תומכים והבטחת איכות - 9
אחזקת תוכנה סוגי ד, 1999-2008 תיקונית אחזקה (corrective maintenance) תיקון תקלות שנשארו מהפיתוח שיפורית אחזקה תקלות ניתוח, תכן, מימוש, תעוד או כל תקלה אחרת (perfective maintenance) הלקוח מבקש שינויים לשיפור האפקטיביות של המוצר הוספת פונקציונליות שיפור ביצועים (adaptive maintenance) שיפור אחזקתיות התאמתית אחזקה תגובה לשינויים בסביבת העבודה של המוצר קומפיילר, מערכת-הפעלה, חומרה,... שינוי בלוגיקה-העסקית מעבר למילניום חדש... (למשל, שינויים במיסוי) תהליכים תומכים והבטחת איכות - 10
סוגי אחזקת תוכנה התפלגות 18.0% 4.0% 17.5% תיקונית שיפורית ד, 1999-2008 התאמתית אחרת 60.5% תהליכים תומכים והבטחת איכות - 11
ד, שבאחזקת תוכנה הקושי מהווה עד האחזקה מהעלות הכוללת של המוצר 90% מקור הכנסה משמעותי אז מדוע ארגונים רבים עדיין מציבים לפעולות אחזקה תכנתים חסרי נסיון וללא פיקוח מתאים? 1999-2008 מירב הסיכויים שתכנת חדש יתחיל את הקריירה המקצועית שלו כתכנת אחזקה!!! תהליכים תומכים והבטחת איכות - 12
נדרש מתכנתי אחזקה? מה ד, 1999-2008 הקשים ביותר של פיתוח תוכנה ההיבטים הינה אחד אחזקה עוסקת בהבטים של כל שלבי הפיתוח אחזקה קיבל תכנת תקלה... דו חחו אילו כלים עומדים לרשותו לצורך ניתוח התקלה? דו ח תקלה מהמשתמש תכנית מקור ובמקרים רבים - לא יותר מכך!!! מעולים debug אחזקה צריך להיות בעל כישורי תכנת התקלה יכולה להימצא בכל מקום אי-שם בתוך המוצר מקור התקלה עלול להימצא במפרט דרישות או מסמך תכן שאינו בנמצא תהליכים תומכים והבטחת איכות - 13
תיקונית אחזקה ד, 1999-2008 התקלה... האחזקה איתר את תכנת בעיה: איך לתקן את התקלה מבלי לגרום לתקלות אחרות ניתן לצמצם את תקלות הרגרסיה? כיצד (תקלות רגרסיה)? עיון בתעוד המפורט של המוצר השלם עיון בתעוד המפורט של כל מודול במציאות... אבל אין תעוד בכלל, או התעוד לא שלם, או התעוד שגוי תהליכים תומכים והבטחת איכות - 14
תיקונית אחזקה (המשך) 1999-2008 ד, המקור... משנה את תכנית התכנת בודק שהשינוי פועל כהלכה נדרש test case חדש בודק שלא הוכנסו תקלות רגרסיה ע י שימוש בבדיקות שמורות קודמות מכניס את הבדיקות החדשות לאוסף הבדיקות השמורות לצורך ביצוע בדיקות רגרסיה בעתיד מתעד את כל השינויים עיקריות הנדרשות לצורך אחזקה תיקונית מיומנויות כושר אבחנה מעולה כושר בדיקה מעולה כושר תעוד מעולה תהליכים תומכים והבטחת איכות - 15
שיפורית אחזקה / התאמתית 1999-2008 ד, האחזקה נדרש לעבור דרך כל השלבים תכנת דרישות מפרט תכן (נכתבו ע י מומחי-דרישות) (נכתב ע י מומחי-ניתוח) (נכתב ע י מומחי-תכן) מימוש ושילוב (נעשו ע י מומחי-מימוש) כאשר המוצר הקיים מהווה את נקודת המוצא ולכן, תכנת אחזקה צריך להיות מומחה נושא... בכל מסקנה: אף סוג של אחזקה לא יכול להתבצע ע י תכנתים מתחילים ולא מיומנים, ללא ניהול מתאים! תהליכים תומכים והבטחת איכות - 16
(maintainability) אחזקתיות חד-פעמי איננה אירוע אחזקה ד, מחזור-החיים של המוצר לתכנן את האחזקה לאורך כל יש בשלב הניתוח ארכיטקטורה ברורה צימוד רופף בשלב התכן (loose coupling) טכניקות של הסתרת-מידע בשלב המימוש יש לשמור על עקרונות האחזקתיות גם בשלב האחזקה!!! (information-hiding) קוד ברור ומובן (שמות משתנים, מבנים, הערות) 1999-2008 בתעוד תעוד ברור, שלם, נכון ועדכני תהליכים תומכים והבטחת איכות - 17
של אחזקה מרובה ההשלכות ה מטרה הנעה ה בעיית (moving target) מתסכלת את הצוות לשינויים מרובים יש השפעות הפוכות על המוצר אפשרי פתרון באב-טיפוס - שימוש צריך לדעת מתי להפסיק לערוך טלאי על טלאי ולהתחיל לכתוב מחדש! בדיקת משמעות השינויים בצורה אינטראקטיבית עם המשתמש בפועל כאשר הלקוח מרוצה מהתוצאה - שינוי הדרישות ועריכת התיקונים הלקוח עלול לשנות את הדרישות ביום שלמחרת ד, 1999-2008 תזכורת: השינויים השפעת עקומת התקלות על אם הלקוח מוכן לשלם, הוא עלול לשנות את הדרישות מדי יום השינויים... שמתרבים ככל המוצר מתרחק מהמפרט ומהתכן המקוריים האחזקה נעשית יותר קשה התעוד הופך לבלתי אמין קבצי הבדיקות אינם מעודכנים בפועל העקומה האידיאלית העקומה זמן שינוי קצב תקלות תהליכים תומכים והבטחת איכות - 18
(reverse engineering) חוזרת הנדסה 1999-2008 ד, בעקבות התכן האבוד נקודת המוצא שיחזור התכן - קוד המקור ניתן לביצוע גם באופן אוטומטי שיחזור המודל הקונספטואלי מסובך מאד!!! בעקבות הקוד האבוד נקודת המוצא dis-assembly שיחזור קוד אסמבלי אפשרי dis-compilation - תכנית ההרצה - התוצאה מסובכת שיחזור תכנית המקור קשה מאד (האם ידועה שפת המקור?) חסרים שמות המשתנים! / מפרט הדרישות תהליכים תומכים והבטחת איכות - 19
העניינים תוכן סקרים תוכנה אחזקת שינויים וניהול תצורה ניהול תוכנה איכות איכות תוכנה הבטחת ד, 1999-2008 תהליכים תומכים והבטחת איכות - 20
שינויים ניהול ד, 1999-2008 שינויים סוגי שינוי יזום ע"י אחד מבעלי העניין בפרויקט בדרך-כלל שינוי בדרישות שינוי כפוי אין בתוכנה כתוצאה מתקלה שינוי בתכן או במימוש עקב "כשל רכיבים" "תיקון" תקלה בתוכנה = שינוי אי-עמידה בדרישות ולכן תקלות ושינויים מטופלים בתהליך דומה תהליכים תומכים והבטחת איכות - 21
מצבים אופייני של תקלה תרשים / בקשת שינוי ד, דיווח תקלה שוחזרה? כן נפתחה בקשת שינוי לא בניתוח הקצאה לטיפול בדיון *CCB הוגדרו משמעויות והשפעות השינוי 1999-2008 לא בוצע שינוי נדחתה לא אושרה לביצוע? כן בביצוע בבדיקה סיום ביצוע סיום בדיקות נסגרה בוצע שינוי ועדת שינויים = Board *CCB = Change Control תהליכים תומכים והבטחת איכות - 22
תצורה ניהול התוכנה משתנה באופן מתמיד מוצר ד, נוצרות גרסאות חדשות של המוצר ומרכיביו = תצורה ו/או מרכיביו מזוהה של המוצר ו גרסה ספריה אישית התכנת תצורת בסיס configuration) (baseline יחידות בדוקות 1999-2008 תצורה ש"הוקפאה" התכולה מוגדרת היטב ומוכרת ע"י גורמים שונים שינויים חייבים להיעשות בצורה מבוקרת ספריה משותפת ספריה ראשית צוות התוכנה תוכנה משולבת בדוקה הפרויקט גרסאות משוחררות הלקוח תהליכים תומכים והבטחת איכות - 23
העניינים תוכן סקרים תוכנה אחזקת שינויים וניהול תצורה ניהול תוכנה איכות איכות תוכנה הבטחת ד, 1999-2008 תהליכים תומכים והבטחת איכות - 24
תוכנה איכות הגדרה: ד, מידת העמידה של מערכת, מידת העמידה של מערכת, משתמש רכיב או תהליך בדרישות ממנו רכיב או תהליך בצרכים או בציפיות של לקוח או שונים על איכות התוכנה היבטים איכות התהליך: איכות התהליכים ותוצרי הביניים באמצעותם מופקת התוכנה למשל: שלמות תוכנית הפרויקט, נכונות המודלים, עקיבות בין המודלים לדרישות 1999-2008 איכות פנימית: איכות הקוד, למשל: כשהוא עומד בפני עצמו עריכת הקוד, מודולריות, הסתרת-מידע איכות חיצונית: איכות התוכנה כשהיא מורצת על החומרה למשל: ביצועים, צריכת משאבים, תקשורת וממשקים איכות תוך-שימוש: איכות התוכנה כשהיא מופעלת ע"י משתמשיה בסביבת ההפעלה שלה למשל: אפקטיביות השימוש למילוי המשימה, נוחות ההפעלה תהליכים תומכים והבטחת איכות - 25
ד, *(Software Quality Factors) איכות התוכנה גורמי [איכות פנימית וחיצונית] 1999-2008 פונקציונליות Functionality אמינות האם התוכנה Reliability האם "עושה את העבודה" שלשמה נכתבה? "אפשר לסמוך על התוכנה" שתמשיך לעשות את עבודתה נאמנה במצבים משתנים ולאורך זמן? שימושיות Usability יעילות האם קל, נוח ואפקטיבי להשתמש בתוכנה לצורך מילוי המשימות של המשתמש? Efficiency האם התוכנה מבצעת את עבודתה תוך ניצול אופטימלי של משאבים? תחזוקתיות Maintainability יבילות האם ניתן לערוך בקלות תיקונים, שיפורים והתאמות בתוכנה, Portability האם ניתן להעביר את התוכנה בצורה "חלקה" במידת הצורך? לסביבת הפעלה אחרת? תהליכים תומכים והבטחת איכות - 26 *ISO/IEC 9126-1: Software Engineering - Product Quality - Part 1: Quality Model
ד, Functionality פונקציונליות מאפיינים המתייחסת לקיומו של אוסף פונקציות ותכונותיהן קבוצת המאופיינות. הפונקציות הן אלה המספקות את הצרכים המוגדרים או הנגזרים. 1999-2008 :Suitability מידת ההתאמה של הפונקציות לדרישות :Accuracy מידת הנכונות של פעולת הפונקציות :Interoperability יכולת האינטראקציה של רכיב עם רכיבים אחרים :Security מניעת נגישות אסורה לפונקציות תוכנה :Compliance תאימות לתקנים (במידה ונדרש) תהליכים תומכים והבטחת איכות - 27
Reliability אמינות מאפיינים המתייחסת ליכולת התוכנה לשמר את רמת הביצוע קבוצת תחת תנאים נתונים למשך פרק זמן נקוב. שלה :Maturity התדירות בה מתרחשות תקלות בתוכנה :Fault Tolerance יכולת התוכנה להמשיך לתפקד במקרה של תקלה ברכיב או בסביבה ד, 1999-2008 :Recoverability כולל נתונים ותקשורת יכולת התוכנה להחזיר מערכת שכשלה לתפעול מלא, תהליכים תומכים והבטחת איכות - 28
ד, Usability שימושיות מאפיינים המתייחסת למאמץ הדרוש לשימוש בתוכנה ולהערכה קבוצת ע"י אוסף של משתמשים מוגדרים. של שימוש זה האישית 1999-2008 :Understandability קלות ההבנה של תפקודי המערכת יחסית למודלים מנטליים של משתמשים בשיטות של ממשקי-משתמש :Learnability מאמץ הלמידה ע"י משתמשים שונים, כגון מתחילים, מנוסים, אקראיים וכו' :Operability יכולת התוכנה להיות מופעלת בקלות ע"י משתמש נתון בסביבה נתונה תהליכים תומכים והבטחת איכות - 29
ד, Efficiency יעילות מאפיינים המתייחסת ליחס שבין רמת הביצועים של התוכנה לבין קבוצת המשאבים הנצרכים, תחת תנאים מוגדרים. כמות זמני תגובה לנפח פעילות נתון (למשל קצב :Time Behaviour טרנזקציות) צריכת משאבי מחשוב: זכרון,,CPU דיסק, :Resource Behaviour 1999-2008 תקשורת תהליכים תומכים והבטחת איכות - 30
Maintainability אחזקתיות ד, מאפיינים המתייחסת למאמץ הנדרש לערוך שינויים מוגדרים קבוצת. בתוכנה :Analyzability היכולת לזהות את גורם השורש של תקלה בתוך התוכנה :Changeability כמות המאמץ הנדרשת לשנות את המערכת 1999-2008 :Stability הרגישות לשינויים במערכת נתונה העלולה להיגרם בעקבות שינוי) (ההשפעה השלילית :Testability המאמץ הנדרש לבדיקת שינוי שנעשה במערכת תהליכים תומכים והבטחת איכות - 31
ד, Portability יבילות מאפיינים המתייחסת ליכולת התוכנה להיות מועברת מסביבה קבוצת לאחרת. אחת 1999-2008 :Adaptability יכולת המערכת לעבור שינויים על פי מאפיינים של סביבת הפעלה שונה :Installability המאמץ הנדרש להתקין את התוכנה :Conformance מידת עמידתה של התוכנה בדרישות של סטנדרטים גלובאליים ישימים (למשל (Open SQL :Replaceability מידת הקלות להחליף רכיב במערכת בתוך סביבה נתונה play ) ( plug and תהליכים תומכים והבטחת איכות - 32
העניינים תוכן סקרים תוכנה אחזקת שינויים וניהול תצורה ניהול תוכנה איכות איכות תוכנה הבטחת ד, 1999-2008 תהליכים תומכים והבטחת איכות - 33
ד, איכות התוכנה Assurance Software Quality הבטחת מוצר התוכנה תהליך הפיתוח משפיעים על... משפיעים על... משפיעה על... מאפייני איכות תוך-שימוש מאפייני איכות חיצונית מאפייני איכות פנימית איכות התהליך תלויים ב... תלויים ב... תלויים ב... 1999-2008 בדיקות תיקוף: בחינת פעולת התוכנה בסביבת השימוש מבדקי תהליכים: בדיקות אימות: בחינה דינמית של התוכנה בהרצה סקרי קוד: בחינה סטטית של הקוד הכתוב סקרי תיכון: בחינת תוצרי התכנון, הדרישות, הניתוח והתכן בחינת כל התהליכים במהלך מחזור החיים, כולל תהליכים ניהוליים תהליכים תומכים והבטחת איכות - 34
(In-use תוך-שימוש Quality) איכות מאפייני 1999-2008 ד, אפקטיביות (Effectiveness) פריון השפעת השימוש בתוכנה על הצלחת המשתמש בביצוע משימותיו (Productivity) בטיחות השפעת השימוש בתוכנה על תפוקות המשתמש (Safety) השפעת השימוש בתוכנה על מצבו הגופני והנפשי של המשתמש רצון שביעות (Satisfaction) מידת נכונותו של המשתמש להמשיך ולעבוד עם התוכנה תהליכים תומכים והבטחת איכות - 35
סיכום 1999-2008 ד, סקרים סקרים נועדו לבדיקת תוצרי הפיתוח ללא הרצה תוכנה אחזקת 3 סוגי אחזקה: תיקונית, שיפורית והתאמתית אחזקת תוכנה מתרחשת לאורך כל מחזור החיים (מסמכים, מודלים, לאחזקה השפעה קריטית על פעולת מוצר התוכנה לאורך מחזור חייו שינויים וניהול תצורה ניהול שינויים בתוכנה חייבים להיעשות בצורה מבוקרת ומתואמת וכו') קוד ניהול גרסאות התוכנה מתבצע בכל רמות הפיתוח, באמצעות ספריות שונות תוכנה איכות 6 איכות התוכנה מתבטאת באיכות התהליך, גורמי איכות תוכנה: איכות תוכנה הבטחת פונקציונליות, איכות התוכנה מובטחת באמצעות סקרים, איכות פנימית, איכות חיצונית ואיכות תוך-שימוש אמינות, שימושיות, יעילות, אחזקתיות ויבילות בדיקות ברמות שונות ומבדקי תהליכים תהליכים תומכים והבטחת איכות - 36