הבטחת איכות תוכנה – הבדלי גרסאות
תוכן שנמחק תוכן שנוסף
מ הוספת קישור לקוד פתוח |
Matanyabot (שיחה | תרומות) מ בוט החלפות: לעיתים |
||
שורה 5:
==הבטחת איכות ובקרת איכות==
השלב הראשון ב'''הבטחת איכות תוכנה''' הוא שימוש בתהליכים מוגדרים ומתועדים של פיתוח תוכנה. כמו כל הליך ייצור, ייצור תוכנה מתחיל משלב הייזום, ממשיך דרך התכן, עיצוב, פיתוח, ותחזוקה של המוצר הסופי, וחוזר חלילה. בכל אחד משלבי מחזור החיים הזה, ננקטים אמצעים שונים ומגוונים להבטחת האיכות של המוצר הסופי.
שורה 11:
דוגמה לתהליך המושפע מעקרונות הבטחת האיכות הוא שימוש ב[[תקן|תקנים]] עבור מסמכים המתעדים את הפיתוח (לדוגמה - תקן ISO-830, או [[נוהל מפת"ח]], לתיעוד דרישות תוכנה (SRS)).
דוגמה נוספת לתהליך שמושפע מעקרונות הבטחת האיכות הוא [[בקרת איכות|בקרת איכות תוכנה]], הלא הוא תהליך הבדיקות. השלב הראשון בבקרת איכות תוכנה הוא היכרות עם המערכת הנדרשת לבדיקה. השלב השני הוא כתיבת תסריטי בדיקה שמטרתם לבחון את כשירותם של המודלים השונים של התוכנה במצבים שונים.
למרות שחברות העוסקות בייצור תוכנה מעסיקות אנשי הבטחת איכות, מהנדסי בדיקות תוכנה ובודקי תוכנה, במרבית התוכנות היוצאות לשוק נמצאים באגים. דבר זה נובע מכמה סיבות:
* יצירת תוכנה מדובגת היטב היא משימה שיכולה לארוך זמן רב מאוד, תוך התנגשות עם צורכי השיווק (Time to market).
* כמעט בכל מוצר תוכנה, פרט אולי לפשוטים ביותר, מספר המצבים האפשריים הוא כה גדול עד כדי שאי אפשר לבדוק את כולם. בתחום מדעי המחשב מוכרת הבעיה כ[[בעיית התפוצצות מצבים]], והיא נחקרת תחת התחום של [[אימות תוכנה]].
* באגים יכולים להיות "יחסיים" - מה שלאחד נראה תקין, לאחר יראה כתקלה, וכל עוד אין הגדרה מסוימת בדרישות התוכנה (
המטרה של בדיקות תוכנה היא לוודא שהמוצר עונה על הדרישות שהוצבו (ולידציה), וכן למצוא באגים בתחומים שלא מכוסים על ידי הדרישות (או לא מכוסים מספיק).
|