הבטחת איכות תוכנה – הבדלי גרסאות
מ בוט החלפות: מדויק; |
הפרדה בין הבטחת איכות לבקרת איכות בתוך המאמר, הוצאת פרסומים מסחריים, תיקון מושגים, חלוקה לפרקים, הוספת קישורים |
||
| שורה 1: | שורה 1: | ||
{{לשכתב|סיבה=תיאור לא שלם ולא מדויק של התחום}} |
{{לשכתב|סיבה=תיאור לא שלם ולא מדויק של התחום}} |
||
{{ניווט בהנדסת תוכנה}} |
{{ניווט בהנדסת תוכנה}} |
||
| ⚫ | '''הבטחת איכות תוכנה''' הינו מקצוע שהעוסקים בו אמונים על מכלול הפעולות הנדרשות להבטיח את איכותה של [[תוכנה|תוכנת]] מחשב, או יישום כל שהוא, בטרם ישווקו לקהל הרחב, או שיעשה בהם שימוש זה או אחר. תחום זה, שנהוג לראות אותו כחלק מתחום [[הבטחת איכות]] ו[[הנדסת תוכנה]], הלך והפך חשוב ברבות השנים. |
||
==כללי== |
|||
| ⚫ | השלב הראשון |
||
| ⚫ | |||
בעבר קרו מקרים של מוות כתוצאה מתוכנות שלא היו איכותיות מספיק: מטוסים שהתרסקו ומכשור רפואי שגרם נזק. ואם פעם לא היה נהוג להשקיע כספים בהעסקת אנשי הבטחת איכות, מהנדסי בדיקות תוכנה, ובודקי תכונה מיומנים, הרי שכיום חברות משקיעות משאבים רבים כדי לוודא שהמוצר שהן מוציאת לשוק בטוח לשימוש ואין בו [[באג|באגים]] רציניים, תוך שימוש בתהליך ייצור המבטיח איכות הנדרשת מהמוצר הסופי. |
|||
| ⚫ | |||
==הבטחת איכות ובקרת איכות== |
|||
לעתים נוצר בלבול בין מושג '''הבטחת איכות תוכנה''' למושג [[בקרת איכות|בקרת איכות תוכנה]]. בזמן ש'''בקרת איכות''' תוכנה זהו תהליך הנועד לבדוק תאימות של המוצר אל מול הדרישות (ספציפיקציות), '''הבטחת איכות''' זהו שם כולל לכלל הפעולות הננקטות על מנת לייצר מוצר ברמת איכות נדרשת. |
|||
השלב הראשון ב'''הבטחת איכות תוכנה''' הוא שימוש בתהליכים מוגדרים, ומתועדים, של פיתוח תוכנה. כמו כל הליך ייצור, ייצור תוכנה מתחיל משלב הייזום, ממשיך דרך התכן, עיצוב, פיתוח, ותחזוקה של המוצר הסופי, וחוזר חלילה. בכל אחד משלבי מחזור החיים הזה, ננקטים אמצעים שונים ומגוונים להבטחת האיכות של המוצר הסופי. |
|||
| ⚫ | |||
דוגמא לתהליך המושפע מעקרונות הבטחת האיכות, למשל, היא שימוש בתקנים עבור מסמכים המתעדים את הפיתוח (לדוגמא - תקן ISO-830, או [[נוהל מפת"ח]], לתיעוד דרישות המערכת (SRS)). |
|||
דוגמא נוספת לתהליך שמושפע מעקרונות הבטחת האיכות הוא [[בקרת איכות|בקרת איכות תוכנה]], הלא הוא תהליך הבדיקות. |
|||
| ⚫ | השלב הראשון בבקרת איכות תוכנה הוא היכרות עם המערכת הנדרשת לבדיקה. השלב השני הוא כתיבת תסריטי בדיקה שמטרתם לבחון את כשירותם של המודלים השונים של התוכנה במצבים שונים. לעתים מתלווה לבדיקה הידנית או מחליפה אותה בדיקה באמצעות כלי בדיקה אוטומטיים (ישנם מספר מוצרים מסחריים, וגם כלים חופשיים תחת רשיון קוד פתוח, כמו CUnit/JUnit/CPPUnit לבדיקות רמת היחידה, BugZilla לניהול תקלות, וכד'). בבדיקה מסוג זה נכתב תסריט המורץ באופן אוטמטי על ידי התוכנה במצבים שונים. בין סוגי כלי הבדיקה הקיימים ניתן לציין כלי בדיקה שמטרתם לבדוק עומסים על אתרי אינטרנט. כלים אלו מדמים כניסה של משתמשים לאתר כדי לבחון את מהירויות הגלישה בעומסים שונים. |
||
| ⚫ | |||
1. צרכי השוק באשר להוציא תוכנה מדובגת היא משימה שיכולה לארוך זמן רב מאוד. לעתים להוציא מוצר נקי מ[[באג|באגים]], אבל באיחור של חודש - עלול לגרום ליותר נזק מלהוציא מוצר עם [[באג|באגים]], אבל בזמן. |
|||
2. לעולם ישארו [[באג|באגים]], זאת משום שכמעט בכל מוצר תוכנה, פרט לאולי הפשוטים ביותר, מספר המצבים האפשריים הוא כה גדול עד כדי שאי אפשר לבדוק את כולם. בתחום מדעי המחשב מוכרת הבעיה כ[[בעיית התפוצצות מצבים]], והיא נחקרת תחת התחום של [[אימות תוכנה]]. |
|||
3. [[באג|באגים]] יכולים להיות "יחסיים" - מה שלאחד נראה תקין, לאחר יראה כתקלה, וכל עוד אין הגדרה מסוימת בדרישות התוכנה (ולעתים גם אם יש), תיקון הבאגים יהיה תוצר של פשרה בין צוותי הפיתוח והשיווק. |
|||
המטרה של בדיקות תוכנה היא לוודא שהמוצר עונה על הדרישות שהוצבו (ולידציה), וכן למצוא [[באג|באגים]] בתחומים שלא מכוסים על ידי הדרישות (או לא מכוסים מספיק). |
|||
==הפן המחקרי== |
|||
| ⚫ | |||
==ראו גם== |
|||
*[[ISO]] |
|||
*[[בקרת איכות]] |
|||
==קישורים חיצוניים== |
|||
* [http://www.graduate.technion.ac.il/eng/Faculties/F080.Html לימודי MSC וPHD בתחום הבטחת איכות בטכניון]. |
|||
{{קצרמר|מחשבים}} |
{{קצרמר|מחשבים}} |
||
| שורה 15: | שורה 45: | ||
[[קטגוריה:תכנות]] |
[[קטגוריה:תכנות]] |
||
[[קטגוריה:תוכנה]] |
[[קטגוריה:תוכנה]] |
||
[[קטגוריה:ניהול]] |
|||
[[קטגוריה:איכות]] |
|||
[[en:Quality assurance]] |
[[en:Quality assurance]] |
||
גרסה מ־03:55, 25 באפריל 2007
שגיאות פרמטריות בתבנית:לשכתב
פרמטרי חובה [ נושא ] חסרים
פרק זה טעון שכתוב. אנא תרמו לוויקיפדיה ועזרו לשכתב אותו. ייתכן שתמצאו פירוט בדף השיחה. הסיבה היא תיאור לא שלם ולא מדויק של התחום.כללי
הבטחת איכות תוכנה הינו מקצוע שהעוסקים בו אמונים על מכלול הפעולות הנדרשות להבטיח את איכותה של תוכנת מחשב, או יישום כל שהוא, בטרם ישווקו לקהל הרחב, או שיעשה בהם שימוש זה או אחר. תחום זה, שנהוג לראות אותו כחלק מתחום הבטחת איכות והנדסת תוכנה, הלך והפך חשוב ברבות השנים.
בעבר קרו מקרים של מוות כתוצאה מתוכנות שלא היו איכותיות מספיק: מטוסים שהתרסקו ומכשור רפואי שגרם נזק. ואם פעם לא היה נהוג להשקיע כספים בהעסקת אנשי הבטחת איכות, מהנדסי בדיקות תוכנה, ובודקי תכונה מיומנים, הרי שכיום חברות משקיעות משאבים רבים כדי לוודא שהמוצר שהן מוציאת לשוק בטוח לשימוש ואין בו באגים רציניים, תוך שימוש בתהליך ייצור המבטיח איכות הנדרשת מהמוצר הסופי.
הבטחת איכות ובקרת איכות
לעתים נוצר בלבול בין מושג הבטחת איכות תוכנה למושג בקרת איכות תוכנה. בזמן שבקרת איכות תוכנה זהו תהליך הנועד לבדוק תאימות של המוצר אל מול הדרישות (ספציפיקציות), הבטחת איכות זהו שם כולל לכלל הפעולות הננקטות על מנת לייצר מוצר ברמת איכות נדרשת.
השלב הראשון בהבטחת איכות תוכנה הוא שימוש בתהליכים מוגדרים, ומתועדים, של פיתוח תוכנה. כמו כל הליך ייצור, ייצור תוכנה מתחיל משלב הייזום, ממשיך דרך התכן, עיצוב, פיתוח, ותחזוקה של המוצר הסופי, וחוזר חלילה. בכל אחד משלבי מחזור החיים הזה, ננקטים אמצעים שונים ומגוונים להבטחת האיכות של המוצר הסופי.
דוגמא לתהליך המושפע מעקרונות הבטחת האיכות, למשל, היא שימוש בתקנים עבור מסמכים המתעדים את הפיתוח (לדוגמא - תקן ISO-830, או נוהל מפת"ח, לתיעוד דרישות המערכת (SRS)).
דוגמא נוספת לתהליך שמושפע מעקרונות הבטחת האיכות הוא בקרת איכות תוכנה, הלא הוא תהליך הבדיקות.
השלב הראשון בבקרת איכות תוכנה הוא היכרות עם המערכת הנדרשת לבדיקה. השלב השני הוא כתיבת תסריטי בדיקה שמטרתם לבחון את כשירותם של המודלים השונים של התוכנה במצבים שונים. לעתים מתלווה לבדיקה הידנית או מחליפה אותה בדיקה באמצעות כלי בדיקה אוטומטיים (ישנם מספר מוצרים מסחריים, וגם כלים חופשיים תחת רשיון קוד פתוח, כמו CUnit/JUnit/CPPUnit לבדיקות רמת היחידה, BugZilla לניהול תקלות, וכד'). בבדיקה מסוג זה נכתב תסריט המורץ באופן אוטמטי על ידי התוכנה במצבים שונים. בין סוגי כלי הבדיקה הקיימים ניתן לציין כלי בדיקה שמטרתם לבדוק עומסים על אתרי אינטרנט. כלים אלו מדמים כניסה של משתמשים לאתר כדי לבחון את מהירויות הגלישה בעומסים שונים.
למרות שחברות המכבדות את עצמן מעסיקות אנשי הבטחת איכות, מהנדסי בדיקות תוכנה, ובודקי תוכנה, במרבית התוכנות היוצאות לשוק ימצאו באגים. דבר זה נובע מכמה סיבות:
1. צרכי השוק באשר להוציא תוכנה מדובגת היא משימה שיכולה לארוך זמן רב מאוד. לעתים להוציא מוצר נקי מבאגים, אבל באיחור של חודש - עלול לגרום ליותר נזק מלהוציא מוצר עם באגים, אבל בזמן.
2. לעולם ישארו באגים, זאת משום שכמעט בכל מוצר תוכנה, פרט לאולי הפשוטים ביותר, מספר המצבים האפשריים הוא כה גדול עד כדי שאי אפשר לבדוק את כולם. בתחום מדעי המחשב מוכרת הבעיה כבעיית התפוצצות מצבים, והיא נחקרת תחת התחום של אימות תוכנה.
3. באגים יכולים להיות "יחסיים" - מה שלאחד נראה תקין, לאחר יראה כתקלה, וכל עוד אין הגדרה מסוימת בדרישות התוכנה (ולעתים גם אם יש), תיקון הבאגים יהיה תוצר של פשרה בין צוותי הפיתוח והשיווק.
המטרה של בדיקות תוכנה היא לוודא שהמוצר עונה על הדרישות שהוצבו (ולידציה), וכן למצוא באגים בתחומים שלא מכוסים על ידי הדרישות (או לא מכוסים מספיק).
הפן המחקרי
במסגרת מדעי המחשב נחקר התחום של אימות תוכנה, שנועד לאפשר הוכחת נכונותה של תוכנה. בנוסף, מתבצעים מחקרים בהבטחת איכות תוכנה תחת המטריה של מנהל עסקים, הנדסה וכתחום בפני עצמו (למשל בלימודי תואר שני ושלישי בטכניון.
