SQA ומקומו בארגון ../images/Emo39.gif
ערן ביקש ממני לכתוב על ההבדל בין QA לבין SQA, ומקומם בארגון. במסרים נוספים בעתיד אני מקווה להרחיב על ה-SQA עצמו ומהותו, כל מה שלא אספיק לסקור במסר זה שגם הוא אינו קצר... QA – Quality Assurance – אבטחת איכות, הוא מונח המתייחס לכלל אבטחת האיכות בארגון כלשהו. הוא מתייחס לאיכות וליעילות של פעולות שונות כגון רכש, גיוס וניהול כח אדם, ועוד כהנה וכהנה. כמובן, התכלית העיקרית של אבטחת האיכות היא אבטחת איכותה של הפעילות המהווה את ליבת העיסוק (Core Business) של הארגון. בעידן התקנים כגון ISO, שנדרשים כיום כמעט מכל ארגון בינוני ומעלה, חלק מהותי מהפעילות הוא הטמעת התקנים בארגון, כתיבת נהלים ספציפיים לאור תקנים אלו, ווידוא יישומם. בחברה שליבת פעילותה היא פיתוח תוכנה, אבטחת איכותה של התוכנה היא כמובן מרכיב מרכזי של אבטחת האיכות בכלל, כשכל שאר פעולות ניהול האיכות (QM – Quality Management) מכוונות בעצם לתמוך ביעילות וברווחיות הכלכלית של פיתוח התוכנה. פיתוח או "ייצור" תוכנה דומה אמנם מהיבטים מסויימים לכל ייצור תעשייתי אחר, אבל יש בו כידוע לכולנו כאן הרבה היבטים ייחודיים. לפיכך, ולאור משקלה העולה של תעשיית התוכנה בעשורים האחרונים, התפתח התחום הספציפי שלנו. SQA – Software Quality Assurance – אבטחת איכות התוכנה, הוא בעצם ענף של כלל אבטחת האיכות (QA) בחברה. אולם בעוד שכלל ה-QA מתמקד בעיקר ב"צורה": בכתיבת נהלים, ווידוא שפעילות הארגון מתנהלת לפיהם, הרי ה-SQA מתמקד ב"תוכן": וידוא שהתוצר מתאים לדרישות, וככל הניתן נקי מתקלות. SQA פועל לפי נהלי אבטחת איכות ובדיקה שעליהם אחראי ה-QA, אבל בתוך מסגרת פורמלית זו הוא אחראי לפתח ולבצע דרכי פעולה וטכניקות של בדיקה ואבטחת איכות, שילוו את התוכנה בכל שלבי פיתוחה (מודל ה-V עליו ידובר בפעם אחרת) מהדרישות הראשוניות ועד אחרי המסירה המוצלחת ללקוח(ות). ה-QA של חברה מסודרת אמור להיות כפוף ישירות למנכ"ל, אם דרך סמנכ"ל בקרה ואיכות (או כדומה לו) ואם באופן אחר. הכפיפות הישירה למנכ"ל הכרחית שהרי תפקיד ה-QA לבקר את כל המערכת, ואסור שיהיה כפוף למחלקה כלשהי שאותה עליו לבקר. מקומו של ה-SQA בארגון ברור הרבה פחות במרבית המקרים (ולמרבה הצער). הרצוי כאן הוא אחת משתי אפשרויות. אפשרי ש-SQA יהיה מחלקה מרכזית בתוך גוף ה-QA המרכזי של החברה. כך כל היבטי אבטחת האיכות ירוכזו במחלקה אחת, המדווחת כאמור ישירות למנכ"ל ולהנהלה. למרות שפתרון זה נשמע ההגיוני ביותר, יש בו גם כשל מובנה מסויים. כשל זה נובע מכך שה-SQA – ממש כמו הפיתוח – מחוייב גם הוא לעבוד לפי התקנים והנהלים שקבעה מחלקת ה-QA, ולפיכך יש יתרון שיבוקר על ידה מבחוץ (מבחינת עמידה בנהלי העבודה וכדומה). לפיכך האפשרות השניה, הרצויה ביותר לדעתי, וכנראה גם הנדירה ביותר, היא קיומו של גוף SQA לצד ובמקביל לגוף ה-QA, כאשר גם הוא עצמאי לחלוטין וכפוף ישירות למנכ"ל. עבודתו של גוף ה-SQA תיבדק כך מבחוץ על ידי גוף ה-QA, ואילו הוא עצמו (ה-SQA) יבדוק את פעילות ייצור התוכנה במחלקות הפיתוח השונות, הן ייצור התוכנה ה"גנרית" והן הפיתוח והיישום המיועדים לפרוייקטים השונים של החברה (בתקווה שיש כאלו...). בפועל, כנראה כמעט תמיד לא זה המצב. לא רק שה-SQA אינו עצמאי מכל הגופים אותם הוא בודק ומבקר וגם מגוף ה-QA שאמור לבקר אותו, אלא תכופות הוא אפילו אינו כפוף ל-QA (שזה הרע במיעוטו) אלא למחלקות הפיתוח – כן, אלה שאותן הוא אמור לבדוק ולבקר ללא מורא וללא משוא פנים. יתירה מזו, בחברות שאינן קטנות מאד, תכופות ה-SQA אף מפוצל בין גופי הפיתוח והאינטגרציה השונים, ו/או בין מחלקות הפרוייקטים השונות. לכך יש כמובן סיבות, שעיקרן ההיבט הפונקציונלי הצר. לכל מנהל פיתוח נוח יותר לקבל שליטה מליאה על משאבי ה-SQA המוקצים לו, להעבירם בגמישות בין הפעילויות השונות לפי סדרי העדיפויות שלו, ולקיים את פעילות הבדיקה בצמידות הגבוהה ביותר למפתחים שלו. אין להתעלם מכך שיתרונות אלו הם ממשיים. אולם הבעיות הכרוכות במצב עניינים זה חמורות. עבודה צמודה מדי של אנשי בקרת האיכות עם המפתחים יוצרת את התופעה שאני קורא לה "הבודק המבין". הבודקים מרויחים אולי היכרות אינטימית יותר עם הפיתוח אבל גם מתחילים "להבין" את הקשיים (שאין להכחישם), נכנס אלמנט אישי לעבודתם מול המפתחים, ונפגמת היכולת לביקורת ודווקא בתחומים החשובים שבהם הדרישות והאיפיונים עמומים במקצת (ותמיד יהיו כאלה) ובקרת האיכות צריכה לדרוש את המירב ולהיות "פרקליטת השטן". וכמובן, מהיותה כפופה למנהל או אף מנהל משנה של פיתוח התוכנה, אין לה את העצמאות והאפקטיביות להתריע מחוץ למחלקה זו על "דגלים אדומים" בנושא איכות הגרסאות, איכות הפיתוח בכלל או היבטים שלו, וכדומה. ואילו הפיצול לכמה גופי SQA, כאשר הוא קורה, מונע התמקצעות אופטימלית שמאפשר גוף SQA גדול אחד אשר יכול ליזום תוכנית הדרכה אפקטיבית, השתלמויות, הקצאת משאבים לפיתוח מתודולוגיות וטכניקות בדיקה ייעודיות בתחום המסויים של החברה, וכדומה. (בפעם הבאה: מחזור החיים של בדיקת התוכנה)
ערן ביקש ממני לכתוב על ההבדל בין QA לבין SQA, ומקומם בארגון. במסרים נוספים בעתיד אני מקווה להרחיב על ה-SQA עצמו ומהותו, כל מה שלא אספיק לסקור במסר זה שגם הוא אינו קצר... QA – Quality Assurance – אבטחת איכות, הוא מונח המתייחס לכלל אבטחת האיכות בארגון כלשהו. הוא מתייחס לאיכות וליעילות של פעולות שונות כגון רכש, גיוס וניהול כח אדם, ועוד כהנה וכהנה. כמובן, התכלית העיקרית של אבטחת האיכות היא אבטחת איכותה של הפעילות המהווה את ליבת העיסוק (Core Business) של הארגון. בעידן התקנים כגון ISO, שנדרשים כיום כמעט מכל ארגון בינוני ומעלה, חלק מהותי מהפעילות הוא הטמעת התקנים בארגון, כתיבת נהלים ספציפיים לאור תקנים אלו, ווידוא יישומם. בחברה שליבת פעילותה היא פיתוח תוכנה, אבטחת איכותה של התוכנה היא כמובן מרכיב מרכזי של אבטחת האיכות בכלל, כשכל שאר פעולות ניהול האיכות (QM – Quality Management) מכוונות בעצם לתמוך ביעילות וברווחיות הכלכלית של פיתוח התוכנה. פיתוח או "ייצור" תוכנה דומה אמנם מהיבטים מסויימים לכל ייצור תעשייתי אחר, אבל יש בו כידוע לכולנו כאן הרבה היבטים ייחודיים. לפיכך, ולאור משקלה העולה של תעשיית התוכנה בעשורים האחרונים, התפתח התחום הספציפי שלנו. SQA – Software Quality Assurance – אבטחת איכות התוכנה, הוא בעצם ענף של כלל אבטחת האיכות (QA) בחברה. אולם בעוד שכלל ה-QA מתמקד בעיקר ב"צורה": בכתיבת נהלים, ווידוא שפעילות הארגון מתנהלת לפיהם, הרי ה-SQA מתמקד ב"תוכן": וידוא שהתוצר מתאים לדרישות, וככל הניתן נקי מתקלות. SQA פועל לפי נהלי אבטחת איכות ובדיקה שעליהם אחראי ה-QA, אבל בתוך מסגרת פורמלית זו הוא אחראי לפתח ולבצע דרכי פעולה וטכניקות של בדיקה ואבטחת איכות, שילוו את התוכנה בכל שלבי פיתוחה (מודל ה-V עליו ידובר בפעם אחרת) מהדרישות הראשוניות ועד אחרי המסירה המוצלחת ללקוח(ות). ה-QA של חברה מסודרת אמור להיות כפוף ישירות למנכ"ל, אם דרך סמנכ"ל בקרה ואיכות (או כדומה לו) ואם באופן אחר. הכפיפות הישירה למנכ"ל הכרחית שהרי תפקיד ה-QA לבקר את כל המערכת, ואסור שיהיה כפוף למחלקה כלשהי שאותה עליו לבקר. מקומו של ה-SQA בארגון ברור הרבה פחות במרבית המקרים (ולמרבה הצער). הרצוי כאן הוא אחת משתי אפשרויות. אפשרי ש-SQA יהיה מחלקה מרכזית בתוך גוף ה-QA המרכזי של החברה. כך כל היבטי אבטחת האיכות ירוכזו במחלקה אחת, המדווחת כאמור ישירות למנכ"ל ולהנהלה. למרות שפתרון זה נשמע ההגיוני ביותר, יש בו גם כשל מובנה מסויים. כשל זה נובע מכך שה-SQA – ממש כמו הפיתוח – מחוייב גם הוא לעבוד לפי התקנים והנהלים שקבעה מחלקת ה-QA, ולפיכך יש יתרון שיבוקר על ידה מבחוץ (מבחינת עמידה בנהלי העבודה וכדומה). לפיכך האפשרות השניה, הרצויה ביותר לדעתי, וכנראה גם הנדירה ביותר, היא קיומו של גוף SQA לצד ובמקביל לגוף ה-QA, כאשר גם הוא עצמאי לחלוטין וכפוף ישירות למנכ"ל. עבודתו של גוף ה-SQA תיבדק כך מבחוץ על ידי גוף ה-QA, ואילו הוא עצמו (ה-SQA) יבדוק את פעילות ייצור התוכנה במחלקות הפיתוח השונות, הן ייצור התוכנה ה"גנרית" והן הפיתוח והיישום המיועדים לפרוייקטים השונים של החברה (בתקווה שיש כאלו...). בפועל, כנראה כמעט תמיד לא זה המצב. לא רק שה-SQA אינו עצמאי מכל הגופים אותם הוא בודק ומבקר וגם מגוף ה-QA שאמור לבקר אותו, אלא תכופות הוא אפילו אינו כפוף ל-QA (שזה הרע במיעוטו) אלא למחלקות הפיתוח – כן, אלה שאותן הוא אמור לבדוק ולבקר ללא מורא וללא משוא פנים. יתירה מזו, בחברות שאינן קטנות מאד, תכופות ה-SQA אף מפוצל בין גופי הפיתוח והאינטגרציה השונים, ו/או בין מחלקות הפרוייקטים השונות. לכך יש כמובן סיבות, שעיקרן ההיבט הפונקציונלי הצר. לכל מנהל פיתוח נוח יותר לקבל שליטה מליאה על משאבי ה-SQA המוקצים לו, להעבירם בגמישות בין הפעילויות השונות לפי סדרי העדיפויות שלו, ולקיים את פעילות הבדיקה בצמידות הגבוהה ביותר למפתחים שלו. אין להתעלם מכך שיתרונות אלו הם ממשיים. אולם הבעיות הכרוכות במצב עניינים זה חמורות. עבודה צמודה מדי של אנשי בקרת האיכות עם המפתחים יוצרת את התופעה שאני קורא לה "הבודק המבין". הבודקים מרויחים אולי היכרות אינטימית יותר עם הפיתוח אבל גם מתחילים "להבין" את הקשיים (שאין להכחישם), נכנס אלמנט אישי לעבודתם מול המפתחים, ונפגמת היכולת לביקורת ודווקא בתחומים החשובים שבהם הדרישות והאיפיונים עמומים במקצת (ותמיד יהיו כאלה) ובקרת האיכות צריכה לדרוש את המירב ולהיות "פרקליטת השטן". וכמובן, מהיותה כפופה למנהל או אף מנהל משנה של פיתוח התוכנה, אין לה את העצמאות והאפקטיביות להתריע מחוץ למחלקה זו על "דגלים אדומים" בנושא איכות הגרסאות, איכות הפיתוח בכלל או היבטים שלו, וכדומה. ואילו הפיצול לכמה גופי SQA, כאשר הוא קורה, מונע התמקצעות אופטימלית שמאפשר גוף SQA גדול אחד אשר יכול ליזום תוכנית הדרכה אפקטיבית, השתלמויות, הקצאת משאבים לפיתוח מתודולוגיות וטכניקות בדיקה ייעודיות בתחום המסויים של החברה, וכדומה. (בפעם הבאה: מחזור החיים של בדיקת התוכנה)