מדריך זה מיועד לתת מבט רחב על ניהול איכות תוכנה בכלל ואבטחת איכות (א"א) במפת"ח בפרט. המדריך מוקדש להסבר של יסודות ניהול האיכות ומקומו בפרויקטי מחשוב. כמו כן קיימות הפניות לקיטים אחרים המכילים הנחיות מעשיות ונהלי עבודה.
מפת"ח כולו הוא למעשה "מדריך ניהול איכות" אחד גדול. להלכה, ביצוע הנחיות מפת"ח, בכל הקיטים הוא קיום אבטחת איכות. למעשה, נדרשת הקמת פונקצית (תחום) ניהול איכות בארגון שבלעדיו עלולות הנחיות מפת"ח (ונהלי איכות אחרים) "להישאר על הנייר". בכך עוסק מדריך זה – באופן הקמת תחום (פונקצית) ניהול איכות בארגון, הגדרת תפקידיו, כולל מבנה רצוי, משאבים, איוש וכו' ויחסיו עם צוותי הפיתוח (והתחזוקה) של הפרויקטים.
איכות היא מילת מפתח בתהליכי ייצור ומתן שירות. המטרה היא לפתח מוצרים ושירותים שיעמדו בקריטריונים מוגדרים מראש. מערכת מחשוב היא שילוב של מוצר ושירות. פיתוח המוצר ומתן השירות בעקבותיו, נעשים בתהליך ("פס ייצור") מיוחד אשר מכיל תחנות ושלבים ברורים במחזור חיי מערכת ממוחשבת. קיט זה מציג את מכלול הנושאים הקשורים בפס ייצור זה מהיבט האיכות.
ניהול איכות תוכנה מתייחס לכל הפעילויות הקשורות בפיתוח ובתחזוקת תוכנה. את הפעילויות ניתן לחלק לשתיים - פעילויות הפיתוח, שתוצאתן המוצר, ופעילויות האיכות המוודאות את הצלחת הפיתוח. רשימה חלקית של פעילויות האיכות: שיקופים, תיעוד, ניתוח חלופות, ניהול סיכונים, מדידה, נהלים, ניהול תצורה, בדיקות וכו'.
ניהול איכות מתייחס להנחיה כיצד לבצע את כל אותן פעילויות. ניהול איכות תוכנה מבטיח ששום דבר חשוב לא נשכח, וכל אחד יודע מי עושה מה, מתי, איך, למה והיכן. במסגרת ניהול איכות מוודאים שהפעילויות בוצעו, אחרת - מופצת התרעה. ניהול איכות פירושו מדידת אפקטיביות הפעילויות - הפיתוח והאיכות, ומידת השפעתן על המוצר, ניתוח התוצאות, הפקת הלקחים ויישומן בעבודה השוטפת.
אבטחת איכות (א"א) היא מכלול של פעילויות ותוצרים המיועדים לוודא שהמערכת נבנית תוך שימוש בשיטות עבודה, כלים לניהול ובקרה ותהליכי פיתוח, אשר יגרמו למערכת להיות איכותית. מערכת איכותיתהיא מערכת העומדת בדרישות מדדי האיכות שהוגדרו לה.
בקרת איכות (ב"א) הינה חלק מנושא אבטחת איכות אשר עוסק בבדיקת איכות התוצר בדיעבד (לאחר ייצורו) לעומת אבטחת איכות אשר דואגת לביצוע תהליכים והפקת תוצרים איכותיים כחלק מהעשייה עצמה. במסגרת בדיקת המוצר בדיעבד מתבצעות: בדיקות יחידה של תוכניות, בדיקות אינטגרציה של מספר יחידות יחדיו, בדיקות מערכת המוודאות עבודה תקינה של כלל המערכת על בסיס הדרישות ועוד.
ניהול האיכות נוגע לבעלי תפקידים שונים המעורבים בפיתוח מערכות:
· מנהלי IT – מעקב סטטוס הפרויקטים, סקרים, אישורי מסמכים
· מנהל פרויקט – תוכנית עבודה, סקרים, ניתוח סיכונים, אמידת עלויות, אישור סוגי הבדיקות, אישור התקנת המערכת ועוד
· מנתחי/מעצבי מערכות – כתיבת מסמכי מחזור חיים על פי מפת"ח
· תוכניתנים – תיעוד תוכניות, ביצוע בדיקות יחידה
· בודקים – תוכנית בדיקות וביצוע בדיקות מערכת
· משתמשים – סקירת מסמכים, אישור תוצרים, ביצוע בדיקות קבלה.
· אנשי אבטחת איכות – כתיבת והטמעת נהלים, מבדקי איכות ועוד.
עבור המשתמשים אבטחת איכות משמשת לשפה משותפת עם אנשי הפיתוח ומהווה כלי בקרה ופיקוח, עבור מנתחי המערכות היא מגדירה סטנדרטים לעבודה וצורת תיעוד אחידה, עבור מנהלי הפרויקטים היא מגדירה כלי עבודה ועבור מנהלים בתחום מערכות המידע והארגון כולו היא מהווה בקרה על כל התהליכים והפעילויות – ניהול כולל של באיכות בארגון.
ארבעה יעדי איכות ברורים עומדים לנגד עיננו תמיד בכל פרויקט פיתוח:
· עמידה בלו"ז
· עמידה בתקציב
· עמידה בדרישות שהוגדרו
· שביעות רצון לקוח
בשלב התחזוקה יש יעדים ברורים לא פחות:
· שמירה על איכות התוצרים ואבטחת התחזוקה לאורך זמן
· ניהול מסודר של דרישות המשתמש תוך תעדוף ברור
· הכנסת שינויים למערכת ללא גרימת זעזועים ותקלות
· שביעות רצון לקוח מהשירות
· יכולת לשחרר משאבים לצורך קידום פרויקטים חדשים
החדרת התרבות של ניהול איכות בתחום המחשוב תורמת לא רק ליחידת מערכות המידע אלא לארגון כולו. יחידת מערכות מידע איכותית גורמת לשילוב משתמשים וגורמים נוספים בתהליך פיתוח מערכות ולמעורבותם בתהליכי העבודה האיכותיים. חלק ניכר מזה ניתן להעתקה ול"שימוש חוזר" בארגון האם.
ליצירת תרבות איכות כוללת יש צורך בהקמת מערכת איכות בארגון שתשתמש באחד או יותר מתקני האיכות, כגון ISO9000, או במודלים לשיפור תהליכים, כגון CMMI, ליישומה בצורה יעילה ואפקטיבית.
תקנים אלה, עוזרים לארגון להכנס למסגרת איכות מובנית, יחד עם מחויבות הנהלה ברורה. תהליך זה סוגר תהליכים, שנשארו קודם לכן פתוחים ולא מנוהלים. תרבות האיכות החדשה גורמת לשיפור הניהול בארגון, והתוצאות לא יאחרו לבוא: פרויקטים איכותיים, שביעות רצון לקוח, שיפור קשר עם ספקים וארגון יציב וחזק.
מטרות מדריך זה הן:
· להגדיר את נושא ניהול האיכות ומקומו בתוך מפת"ח.
· לשמש הפנייה לקיטים אחרים במפת"ח המכילים הנחיות מעשיות ונהלי עבודה.
· לספק כלים למנהלי האיכות לפעילותם השוטפת.
שימוש במפת"ח יכול לפשט ולהקל על כניסה לעולם האיכות.
אבטחת איכות היא תחום מקצועי שניתן לאיישו במגוון רחב של אפשרויות והיקפים, החל ממקרה בו א"א משולבת באופן מלא בצוות הפיתוח וכלה במקרה בו א"א מבוצעת ע"י גוף מטה נפרד. מגוון האפשרויות הוא אפוא רחב ביותר. להלן מספר אפשרויות שכיחות:
· ניהול איכות מרכזי בארגון המיושם על ידי גוף מטה המשרת את הפרויקטים (ראה קיט ניהול יחידת המחשב בכרך ניהול/ניהול הארגון)
· אבטחת איכות המיושמת בפרויקטים מובילים על ידי אנשי אבטחת איכות ייעודיים
· אבטחת איכות המיושמת בכל הפרויקטים על ידי אנשי אבטחת איכות יעודיים
· לווי פרויקטים קטנים על ידי נאמני אבטחת איכות או גוף המטה
הפעילויות השונות בכל אחת מהאפשרויות מפורטות בהמשך המדריך. ההחלטה על מידת מעורבות אנשי אבטחת איכות בפרויקטים נתונה בידי הנהלת הארגון ומתוך מידת מעורבות זו ייגזרו הפעילויות בתחום אבטחת האיכות.
אבטחת איכות לא יכולה להתבצע רק ע"י פונקצית אבטחת איכות.
איכות פירושה לעשות את הדברים נכון "בפעם הראשונה" וכחלק אינטגרלי מבניית המערכת.
ועדת ההיגוי לפרויקט (הצוות המנהלי, או כל גורם אחר שהוא בעל הסמכות הגבוהה ביותר בפרויקט) בשיתוף עם מנהלת הפרויקט יגדירו היטב את מעמדו של צוות א"א וסמכויותיו. הגדרה זו תופיע בברור הן במנדט (כתב האמנה) שניתן לצוות א"א והן בתכנית העבודה המרכזית של הפרויקט. האם הערות א"א הם בגדר המלצה בלבד, או שבנקודות צומת מסוימות, למשל באישור תיק האפיון ומעבר לעיצוב ובנייה, יש להערות אלה תוקף מחייב ואי ביצוען יכול לעכב את המשך הפרויקט.
צוות א"א יכול "להטות כתף" ולגלות מעורבות גבוהה, אך לא למלא "תקנים" ומשאבים החסרים בצוות הפיתוח עצמו.
האחריות הסופית על איכות הפרויקט היא בידי צוות הפיתוח, לא צוות א"א.
ניתן לבחון את מידת מעורבות א"א בפרויקט בהיבט של מידת האקטיביות וה"ביצועיזם" של אבטחת איכות, האם היא א"א פסיבית: מבקרת, בודקת, מעירה ומסייעת, או שהיא א"א אקטיבית אשר נוטלת חלק ממשי בביצוע מטלות פיתוח וניהול.
מסיבות רבות, בעיקר בארץ, יש נטייה להיות "תכליתי" ולהטיל על צוות א"א משימות מעשיות ולא להסתפק בביקורת והערות לפרויקט. לגישה זו יש יתרונות רבים מובנים מאליהם, אך החסרון המרכזי הוא שמעורבות יתר של צוות א"א בעשייה היום-יומית של הפרויקט, עשויה לנטרל את יכולתו "להשקיף מהצד" ולנהל את האיכות בצורה אובייקטיבית. ובסופו של דבר יתגלה צורך בגורם חיצוני נוסף שיבצע בקרה כי פונקצית א"א "נבלעה" בפרויקט.
דוגמא קלאסית היא נושא הסקרים (reviews). אחד מתפקידיו המרכזיים של צוות א"א (ראה להלן) הוא לוודא שבפרויקט מתקיימים באופן שוטף סקרים מסודרים. צוות א"א צריך גם להשתתף בפועל בחלק ניכר מהם (לא בכולם!) ולהעיר את הערותיו "בזמן אמת". אך האחריות לקיום מפגשי הסקרים, זימון המשתתפים, ניהול הדיון, הוצאת סיכום דיון וכו', הם באחריות צוות הפיתוח ומנהל הפרויקט. להרחבה בנושא זה, ראה הקיט סקרים Reviews בכרך איכות.
אין מדד ברור באשר להיקף המשאבים הנדרש לביצוע א"א. כלל אצבע מקובל בעולם הוא 5% מעלות פיתוח המערכת, או במילים אחרות איש א"א אחד על כל 20 איש העוסקים בפיתוח. בארץ מקובל מספר נמוך בהרבה, אחד ל- 30 או אפילו אחד ל- 40. ברור שהמספר האמיתי הוא פועל יוצא לא רק של היקף המערכת, אלא גם של גורמים רבים אחרים כגון: מידת חדשנות המערכת, מידת הקריטיות שלה, מיומנות הצוותים, מודעות צוות הפיתוח והצוות המנהלי לנושא האיכות וכו'.
פעילויות ניהול האיכות כגוף מטה מתמקדות בשני מישורים עיקריים:
· רמת הארגון: פעילויות רוחביות ברמה הכלל ארגונית
· רמת הפרויקט: ליווי פרויקטים בפיתוח, ליווי מערכות בתחזוקה, הוספת יחידות מסירה למערכת קיימת וכו'.
להלן פירוט מירב הפעילויות שבהן עוסק גוף מטה של ניהול איכות.
ככלל, תשתית אבטחת איכות ארגונית מכילה את הפעילויות הבאות:
1. הכנת תוכנית עבודה במספר רמות אפשרויות:
· רב שנתית (תכנית אב!)
· שנתית (תקציב)
· תקופתית (רבעון, למשל)
2. כתיבה ועדכון נהלים כלל ארגוניים (המשלימים את מפת"ח) והטמעתם ביחידות הפיתוח:
· בחינת מידת ההטמעה והשימוש הקיימים
· עדכון נהלים
· ביטול נהלים מיותרים והשלמת חסרים
3. סיוע וארגון פגישות הנהלה המוקדשות לנושא האיכות, כולל סקרי הנהלה במקומות בהם מוטמע תקן איכות כגון ISO 9000 או CMMI.
4. ביצוע מעקב סטטוס פרויקטים כללי (לו"ז, תקציב, עמידה בדרישות) – מצבת פרויקטים בארגון (פגישות סטטוס עם מנהלת הפרויקט – ראה ליווי פרויקטים להלן)
5. הטמעת מפת"ח (או שיטות אחרות \ משלימות)
6. הגדרת מדדי איכות רוחביים לארגון:
· הגדרת שיטה לאיסוף נתונים וניתוח התוצאות
· קביעת יעדים
· ביצוע
7. הגדרת מתודולוגית בדיקות בארגון כולל הטמעתה בין אנשי הפיתוח
8. הכנה/סיוע בהכנה של מתודולוגיה לניהול פרויקטים והטמעתה
9. סיוע בבחירת כלים ממוחשבים לנושאים הבאים:
· בדיקות
· ניהול פגישות, תכתובות, מעקב החלטות
· ניהול תצורה, ניהול שינויים וניהול תקלות
· ניהול פרויקטים
· כלי פיתוח ו- CASE (Computer Aided Software Engineering)
· כלי לתוכניות עבודה
· ניהול ספריות ותכנים (תיעוד)
· כלים לניהול אבטחת איכות עצמה
10. הקמת פורומים בנושאים מיוחדים אשר נמצאים ב"קדמת הפיתוח" ויכולים לשמש מנוף לקידום איכות בכלל, הנושא הספציפי בפרט, כגון: פורום אבטחת מידע, אינטרנט, פיתוח בסבבים, גישת האובייקטים(UML) וכו'
11. ביצוע הפקת לקחים לפרויקטים שהסתיימו. ניתן לבצע לחלק מהפרויקטים או לכולם. הפקת לקחים משמשת כמנוף לשיפור בפרויקטים הבאים.
רשימה זו נראית רחבה ומקיפה, אך יש לזכור שהיא "איננה ממציאה שום גלגל חדש". כל הנושאים האלה היו ויהיו תמיד ויש לטפל בהם. ניהול האיכות מכנס אותם למסגרת מקצועית וניהולית, אך בעצם "איננו מחדשת דבר". ניהול האיכות הוא חלק אינטגרלי מניהול הארגון והפרויקט (כפי שנראה בהמשך).
ליווי פרויקטים מתבצע, בדרך כלל על ידי אנשי אבטחת איכות המלווים מספר פרויקטים בו זמנית. גוף המטה מחלק את מגוון הפרויקטים הקיים בין אנשי אבטחת האיכות. איש אבטחת איכות (הנקרא מנהל האיכות בפרויקט) מלווה את הפרויקט ומבצע את הפעולות הבאות: (בסוגריים ראה הפנייה לקיט המתאים במפת"ח התומך בביצוע הפעילות הספציפית)
· סיוע בהגדרת מדדי איכות ושערי איכות בפרויקט, ליווי תפעול שוטף של מערכת המדדים וסיוע בניתוח התוצאות והפקת המסקנות הנכונות מהנתונים (ראה קיט מדדים בכרך זה)
· ביצוע מעקב סטטוס הפרויקט (לו"ז, תקציב, עמידה בדרישות) כולל פגישות סטטוס עם בעלי התפקידים במנהלת הפרויקט
· בדיקת תיעוד באבני דרך כחלק מהגורמים המאשרים בתהליך ואף סיוע וקבלת מסמכים כטיוטות לפני הפצה – מסמך יזום, תיק אפיון על, תיק אפיון, בקשה להצעות, מפ"ל, הצעות ספקים, תיק עיצוב, תיקי תכנות, תיק בדיקות ותיק סיכום בדיקות, מדריך למשתמש, תיק תפעול, תוכניות הדרכה והטמעה, תיק תחזוקה ועוד (ראה קיט בדיקת תיעוד בכרך זה)
· הטמעת נושא עלות/תועלת בפרויקטים (ראה קיט ישימות ועלות/תועלת בכרך נושאים תומכים)
· סיוע בבנייה נכונה יותר של אומדן עלויות לפרויקט (ראה קיט אמידת עלויות בכרך נושאים תומכים)
· הטמעה וסיוע בתהליך ניהול סיכונים לפרויקט (ראה קיט בשם זה בכרך נושאים תומכים)
· סיוע והנחית צוות הפרויקט בכל הקשור לתיעוד שינויים וניהול תצורה במהלך הפרויקט (ראה קיט ניהול תצורה בכרך זה)
· השתתפות בועדות היגוי וועדות מקצועיות
· סקירה והטמעת תהליך בחינה ובחירת חלופות (ראה קיט ניתוח חלופות בכרך נושאים תומכים)
· סיוע וליווי תהליך בקשה להצעות החל מהפיכת האפיון למפרט, שילוב פרק מנהלה סטנדרטי, כתיבת המפ"ל (מסמך קריטריונים), כנס ספקים, תהליך בחינת ההצעות, בחירת הספק ועד לכתיבת מסמך קונסולידציה, כתיבת חוזה וחתימתו (ראה קיט בקשה להצעות בכרך יסודות/מחזור חיים)
· סיוע בתכנון ומעקב אחר ביצוע בדיקות המערכת: אימות והוכחת תקפות, (ראה קיט בדיקות בכרך יסודות/מחזור חיים)
· השתתפות בסקרים Reviews בתהליכי הפיתוח (ראה קיט סקרים Reviews בכרך זה)
· בקרה על ביצוע סקרי קוד ובדיקות יחידה (ראה קיט עיצוב ובניה בכרך יסודות/מחזור חיים)
· סיוע וביצוע של בדיקות מוכנות (ראה קיט בדיקות בכרך יסודות/מחזור חיים)
· ליווי התקנת המערכת והטמעתה, כולל הדרכות והסבות (ראה קיט התקנה והרצה בכרך יסודות/מחזור חיים)
ליווי מערכות בשלב התחזוקה כולל את הפעילויות הבאות:
1. סיוע בהגדרת מדדי איכות
2. סיוע בכתיבת תיקי תחזוקה
3. ניהול ועדת שינויים ותקלות (CCB, Change Control Board):
· הגדרת תהליך ניהול שינויים, הטמעה ומעקב תוך דגש על תיעוד הדרישות והשינויים
· השתתפות פעילה בפעילויות ה- CCB
· הפקת דו"חות סטטיסטיים
4. סיוע בתהליכי ניהול תצורה, ניהול גרסאות
5. סיוע בהגדרת מהדורות ויחידות מסירה חדשות
6. הגדרה וסקירת תהליך העברה לייצור
7. סיוע ומעקב אחר תוכניות התקנה והטמעה
8. סיוע בהכנת סקרי שביעות רצון לקוחות
נושאי הדרכות והטמעה בארגון המפתח ומתחזק מערכות מידע כולל בין היתר את הפעילויות הבאות:
1. ארגון כנסים והדרכות בנושא אבטחת איכות לאנשי פיתוח, מנהלים ומשתמשים.
2. הדרכות בנושא מפת"ח לאוכלוסיות שונות
3. סדנאות רענון למנהלי פרויקטים בנושאים מתקדמים, כגון:
· שיטות וטכניקות מתקדמות לניהול פרויקטים
· אומדן עלויות, ניתוח סיכונים
· שיטת UML
· ניהול שיקופים וסקרים
· ניהול זמן ועוד
4. הנחיית נאמני א"א
5. סיוע בהגדרה ומימוש תהליכי חניכה של עובדים חדשים
6. סיוע בהגדרת מסלולי הכשרה לעובדים על פי סוגי אוכלוסיות ותפקידים
תפקיד מרכזי של אבטחת איכות הוא לוודא שבפרויקט מעורבים כל הגורמים הרלוונטיים, כולל פונקצית אבטחת איכות עצמה. גורמים אלה חייבים להיות מוגדרים היטב ברכיבים 1.1 ו- 4.1 והם חייבים לכלול לפחות את:
· מומחה היישום אשר מסוגל ומוסמך לייצג את הלקוח - המשתמש העיקרי
· צוות מקצועי קבוע - גרעין הפרויקט
· סיוע טכני חיצוני או פנימי לפי דרישה
· ייעוץ חיצוני במגוון נושאים מתמחים אפשריים: ממשק אדם מחשב, אבטחת מידע, חיזוי עומסים וביצועים וכו'
· סיוע משפטי ורכש
· ועדת ההיגוי (הצוות המנהלי) שהיא הגוף העליון המנחה את הפרויקט
גורמים אלה הם פונקציות ולא בהכרח "משרות" – ודאי לא משרה מלאה לכל פונקציה. בחלקם, הם גם מעורבים בפרויקטים אחרים בו זמנית. כל פונקציה תאויש בדרך כלל ע"י אנשים שונים (במשרה מלאה או חלקית, כאמור). ייתכן, עם זאת, שהצוות המקצועי, למשל, הוא מקצועי ועצמאי ואיננו זקוק לסיוע טכני נוסף (הוא מכיל בתוכו את הסיוע הטכני הנדרש לפרויקט). במקרים אחרים, מומחה היישום משתתף באופן הדוק בפיתוח המערכת והוא חלק בלתי נפרד מהצוות המקצועי.אפשרות חריפה יותר היא שהצוות המקצועי מדווח ישירות למנהל ענ"א וביחד הם מתפקדים כ"ועדת ההיגוי". ל"התכנסות" כזו של הגורמים המעורבים יש יתרון בכך שיש פחות "ידיים מעורבות" בפרויקט, אך מתפקידה של אבטחת איכות לעמוד על המשמר גם בתחום זה ולהתריע במקרים בהם ישנה אי-בהירות של הגורמים המעורבים: חסר, כפל תפקידים, כפילות פונקציות, חוסר תקשורת וכו'.
כל ארגון קובע לעצמו את סדרי הגודל של הפרויקטים וסדר ביצועם (במסגרת תכנית העבודה השנתית, למשל). במסגרת החלטות אלה, נקבעת בדרך כלל גם מידת מעורבות פונקצית א"א בפרויקטים.
בדרך כלל יש לארגון מספר פרויקטים מובילים וחשובים, שלרוב הם גם עתירי משאבים. פרויקטים אלה, הם מועמדים טובים להטמעת אבטחת איכות. ההחלטה על איוש תפקיד א"א בפרויקט גדול תתקבל בכל ארגון לגופו על בסיס הפרמטרים המומלצים הבאים:
· מספר כולל של אנשים בפרויקט
· מספר הצוותים בפרויקט
· האם עובדים במקביל
· התמחויות הצוותים
· היקף תקציבי
· משך זמן בפרויקט
בפרויקט גדול, איש אבטחת האיכות יכול להיות כפוף לגוף המטה או למנהל הפרויקט. כפיפות לגוף המטה מקנה לפעילות אבטחת האיכות דרך פעולה אחידה בכל הפרויקטים הכוללת מדיניות מוגדרת וקבועה והנחיה מקצועית צמודה. לעומת זאת, כפיפות למנהל הפרויקט יוצרת זיקה חזקה יותר בין איש אבטחת האיכות לצוות הפרויקט ואף מחברת את מנהל הפרויקט לפעילות זו. בכל מקרה, מדובר בתפקיד ייחודי (משרה מלאה) המוקצה לפעילות אבטחת איכות פרויקטלית. לעיתים יש צורך בסיוע נוסף של גוף המטה.
כאשר איש אבטחת איכות פרויקטלי מלווה ומנחה כתיבת מסמכים לפרויקט מומלץ לבצע בקרה צולבת על מסמכים אלה, כלומר, סקירת התיעוד תתבצע על ידי גוף המטה לאבטחת איכות. זאת כדי לנטרל השפעות של מעורבות יתר של איש אבטחת האיכות הפרויקטלי בכתיבת מסמכי הפרויקט. קיימים הבדלי סגנון בין פרויקט לפרויקט ולכן יש צורך לעבור על עיקרי הפעילות שמפורטים לעיל ולעגן בצורה מסודרת את תפקידי מנהל א"א בפרויקט, יחד עם מנהל הפרויקט. יש לשים לב שכל פעילות ניתנת לביצוע ברמות שונות: יעוץ, בקרה, ביצוע, פיקוח ועוד. כהמלצה בלבד: א"א בפרויקט גדול משלבת הרבה פעילויות ברמה של ביצוע ולא ברמה של יעוץ או ליווי, כפי שנהוג ברמת מטה.
להלן רשימה מומלצת ולא מחייבת של עיקרי הפעילות של אבטחת איכות פרויקטלית:
# |
נושא |
ייעוץ |
בקרה |
ביצוע |
---|---|---|---|---|
1. |
סיוע בביצוע אמידת עלויות בפרויקט. סיוע בניתוח עלות/תועלת וניתוח חלופות. בקרה על תהליך אישור הפרויקט ועל סקר הדרישות, כדי לוודא כי לא ניתנות התחייבויות בלתי ריאליות לאור המשאבים המוקצים. (הרמת דגל אדום במידה וכן). |
Ö |
Ö |
|
2. |
יעוץ בהגדרת והטמעת מתודולוגיות וכלים לפיתוח. |
Ö |
|
|
3. |
יעוץ בהגדרת המבנה הארגוני של הגוף המפתח והגדרת התפקידים השונים בו. בקרה על מימוש הגדרות אלה. |
Ö |
Ö |
|
4. |
סיוע וליווי תהליך בקשה להצעות החל מהפיכת האפיון למפרט, שילוב פרק מנהלה סטנדרטי, כתיבת המפ"ל (מסמך פנימי לבדיקה, קריטריונים לבחירת הספק), כנס ספקים, תהליך בחינת ההצעות, בחירת הספק ועד לכתיבת תיק מערכת SOW, כתיבת חוזה וחתימתו |
Ö |
|
|
5. |
סיוע בהגדרת תוכניות החונכות בפרויקט, כדי לוודא כי כל בעל תפקיד מקבל את ההכשרה הדרושה לו לצורך תפקידו (הן הכשרה תיאורטית, והן הכשרה תוך כדי התפקיד – On the Job Training). בקרה על אפקטיביות החונכות, ושיפורה במידת הצורך |
Ö |
Ö |
|
6. |
הגדרת יעדי האיכות לפרויקט (יחד עם ראש הפרויקט וראשי הצוותים), וגזירת מדדים ופעילויות האיכות הרלוונטיות (אשר יתרמו להשגת אותם יעדים) לתוך תוכנית העבודה של הפרויקט. בקרה על אותן פעילויות, והצפת חריגים לראש הפרויקט. סיוע בניתוח תוצאות המדידה והפקת המסקנות המתאימות מהתוצאות. |
|
Ö |
Ö |
7. |
בקרת עמידה ביעדים ופתרון הבעיות שהוגדרו (רכיבים 1.2 ו- 1.3 בעץ המערכת) |
|
Ö |
|
8. |
סיוע לראש הפרויקט בביצוע מעקב סטטוס פעילויות הפרויקט בדגש על פעילויות איכות. ייעוץ בנושאי איכות כלליים. |
Ö |
|
Ö |
9. |
בדיקת תיעוד באבני דרך כחלק מהגורמים המאשרים בתהליך ואף סיוע וקבלת מסמכים כטיוטות לפי הפצה וסיוע בכתיבתם – מסמך יזום, תיק אפיון על, תיק אפיון, בקשה להצעות, מפ"ל, הצעות ספקים, תיק עיצוב, תיקי תכנות, תיק בדיקות ותיק סיכום בדיקות, מדריך למשתמש, תיק תפעול, תוכניות הדרכה והטמעה ועוד |
Ö |
Ö |
|
10. |
כתיבה או סיוע בכתיבה של הוראות עבודה בפרויקט, וגלופות לשימוש שוטף. רענון ועדכון הוראות במידת הצורך (שימור ידע שהינו תורה שבעל-פה). הטמעת ההוראות ושיטות העבודה בקרב אנשי הפרויקט (כולל סיוע לראשי הצוותים בביצוע הטמעה זו). |
Ö |
Ö |
Ö |
11. |
ייעוץ וסיוע בהגדרת ארבעת תהליכי הליבה של הפיתוח: תהליך הפיתוח, ניהול תצורה, ניהול שינויים, ניהול תקלות. סיוע בהטמעת התהליכים הנ"ל ובקרה על מידת יישומם בפרויקט. |
Ö |
Ö |
Ö |
12. |
זיהוי בעיות בתהליכי הפיתוח, וסיוע בשיפור התהליכים |
Ö |
|
Ö |
13. |
ייעוץ וסיוע בהגדרת שיטות לאימות (Verification) כל שלב בפיתוח לעומת השלב הקודם. למשל: כיצד לוודא שהעיצוב תואם את האפיון? כיצד לוודא שהקוד תואם את העיצוב? סיוע בהטמעת שיטות אלה, ובקרה על מימושן. |
Ö |
Ö |
|
14. |
סיוע בניהול הסיכונים בפרויקט. בקרה על ניהול הסיכונים, תוך שימת דגש על הפחתה אמיתית של הסיכונים הקריטיים בשלבים המוקדמים של הפרויקט |
Ö |
Ö |
|
15. |
השתתפות בועדות ההיגוי למיניהן |
Ö |
|
|
16. |
סיוע וליווי תהליכי רכש: ייעוץ בכתיבת המפרט והמפ"ל (מסמך קריטריונים), סיוע בבחינת ההצעות ובחירת הספק. בדיקת מסמכים שונים (מפרט, מפ"ל) במהלך תהליך זה. |
Ö |
Ö |
|
17. |
ייעוץ בנושא שיטות לביצוע אפקטיבי של בדיקות יחידה (Unit Tests) ובדיקות שילוב (Integration Tests). סיוע בהגדרה השיטות בפרויקט, ובקרה על יישומן. בחינת האפקטיביות שלהן (האם מתגלים בבדיקות המערכת הרבה תקלות שהיה אפשר לגלות מוקדם יותר?) ושיפורן במידת הצורך. |
Ö |
Ö |
|
18. |
סיוע וייעוץ בתכנון בדיקות המערכת. מנהל האיכות מוודא כי מנהל הבדיקות מכין תוכנית בדיקות הנותנת מענה לצרכים (כיסוי דרישות, כיסוי נושאים בלתי פונקציונאליים כמו ביצועים, זמני תגובה, וכו') , וכי היא מיושמת באופן מלא ואפקטיבי. |
Ö |
Ö |
|
19. |
סיוע בהכנת סקרים, מתוך מטרה לוודא את האפקטיביות שלהם (סקרי דרישות/אפיון/עיצוב/קוד) בקרה על אפקטיביות הסקרים: האם הזמן המוקדש להם מנוצל באופן תכליתי? האם מנהלים את הסקר לפי קריטריונים ברורים ומוגדרים מראש? האם יוצא סיכום והאם עוקבים אחר ביצוע המשימות? האם מגלים בסקר בעיות אמיתיות בתוצרי הביניים? (ולא סתם מבזבזים את הזמן?) |
Ö |
Ö |
|
20. |
בקרה על קבלת אישורים של הגורמים הרלוונטיים במעבר משלב לשלב במחזור החיים וכן כל תוצרים מבוקרים. |
|
Ö |
|
21. |
ליווי מבדקי איכות פנימיים, סיוע בהגדרת תוכנית פעולה מתקנת, ובקרה על ביצוען, כולל בדיקת אפקטיביות הפעולות (האם הליקויים אינם חוזרים על עצמם?) |
Ö |
Ö |
Ö |
ה"סכנה" הגדולה של אבטחת איכות פרויקטלית צמודה, היא "סחיפתו" של איש א"א לתוך צוות הפיתוח. יש לכך יתרונות אך גם חסרונות רבים. הרבה מאד תלוי באיכות אבטחת איכות (ושאר הגורמים המעורבים). הפתרון? מעורבות אבטחת איכות גוף מטה.
אבטחת איכות בפרויקטים קטנים היא בעייתית, מסיבות מובנות:
· "כל הפרויקט כולו הוא בהיקף קטן ואין לנו זמן וכסף להשקיע גם בליווי של אבטחת איכות"
· "מדובר במערכת זמנית המשרתת גוף מצומצם וממוקד בארגון"
· "לא כדאי להשקיע בא"א במערכת כזו קטנה" וכו'.
הליווי מתבצע, בדרך כלל, על ידי אנשי אבטחת איכות המוקצים לליווי מספר פרויקטים בו זמנית. גוף המטה מחלק בין אנשי תחום אבטחת איכות את מגוון הפרויקטים הקיים.
בכל מקרה, אבטחת איכות של פרויקט קטן תלווה את הפרויקט מקרוב ותבצע את הפעולות הבאות:
· בדיקות יחידה תוך כדי הפיתוח (דגש ראשי)
· בדיקות מערכת מקיפות (דגש משני)
· סיוע בתיעוד (דגש ראשי)
· בדיקת תיעוד (משני)
· ניתוח סיכונים (ראשי)
· אמידת עלויות (משני, קביעת חסמים)
· ביצוע סקרים – Reviews (ראשי).
בפרויקטים קטנים, אולי יותר מכל פרויקט אחר, אבטחת איכות היא חלק אינטגרלי מהפרויקט.
למידע נוסף ראה הקיט מערכות קטנות בכרך ניהול\ניהול הפרויקט.
תכנון הפיתוח קובע את הפעילויות הנדרשות לצורך קבלת מוצרי תוכנה העונים על דרישות הלקוח.
תכנון הפיתוח מתועד במסגרת תוכנית פיתוח. תוכנית פיתוח תגדיר איך יתנהל הפרויקט, מהם סקרי ההתקדמות הדרושים, אילו סוגי דוחות יש להכין עבור ההנהלה, הלקוח וצדדים רלוונטיים אחרים, ובאיזו תדירות, כאשר מביאים בחשבון את כל הדרישות החוזיות.
תוכנית האיכות תספק את האמצעים להתאים את יישום מערכת האיכות לכל פרויקט, מוצר או חוזה. המסמך המתאר תוכנית איכות יכול להיות מסמך עצמאי (שכותרתו תוכנית איכות) או חלק ממסמך מחזור חיים ובו, בין היתר, תוכנית עבודה מפורטת.
היות שהאיכות היא חלק בלתי נפרד מהעשיה מומלץ לשלב פעילויות אבטחת איכות בתוך תוכנית הפיתוח. תוכנית זאת תיקרא אם כך תוכנית הפיתוח והאיכות.
עצם כתיבת תיק מערכת לפי מפת"ח, תוך הקפדה על הגדרת הסעיפים המפורטים בטבלה להלן, מהווה מענה מלא לדרישות בנושא תכנון הפיתוח והאיכות.
ניתן לכתוב תוכנית פיתוח ואיכות בנפרד מתיק המערכת, תוך הפניה בסעיפים הרלוונטיים מתיק המערכת לכיוון תוכנית הפיתוח והאיכות. ניתן גם לכתוב את תוכנית הפיתוח והאיכות כחלק מתיק המערכת ולא כמסמך נפרד.
עם תחילתו של שלב האפיון בפרויקט, לאחר קבלת האישור הראשוני לפרויקט (סיום שלב הדמ"ץ/אפיון-על), יש לגשת לכתיבת תוכנית הפיתוח והאיכות של הפרויקט. תוכנית זו תיכתב ע"ב גלופת תיק אפיון של מפת"ח, ותכיל את כל הסעיפים המוגדרים בטבלה להלן.
יש לאשר תוכנית זו באופן רשמי ע"פ נוהל האישורים הקיים בארגון. יש לשים לב שגם לאחר האישור, חלק מהנספחים של התוכנית (למשל: תוכנית העבודה של הפרויקט, גיליון ניהול תקציב הפרויקט, וכו') ממשיכים להתעדכן באופן שוטף. נספחים מעודכנים אלה הופכים להיות רשומות איכות של הפרויקט.
בסיום שלב האפיון, כחלק מהכנת תיק המערכת, יש לעדכן את תוכנית הפיתוח והאיכות הנ"ל. אם היא נכתבה כמסמך נפרד, יש לעדכנה. אם היא נכתבה כחלק מתיק המערכת, יש לעדכן את הסעיפים הרלוונטיים בתיק המערכת.
באופן דומה מעדכנים את תוכנית הפיתוח והאיכות גם במהלך שלב עיצוב (כחלק מהכנת תיק מערכת לשלב העיצוב) ולקראת סיום הבדיקות (כחלק מהכנת תיק המערכת לשלב התחזוקה).
להלן פירוט סעיפי עץ המערכת של מפת"ח הרלוונטיים לתכולה הנדרשת של תוכנית פיתוח ואיכות:
רכיב/סעיף |
תוכנית |
הערות |
|
---|---|---|---|
פיתוח |
איכות |
||
1.2 מטרות ויעדים |
הגדרת מטרות ויעדי המערכת. יעדי המערכתיתורגמו למדדי הצלחה לפרויקט (כימות המטרות) בסעיף 1.6.1. |
הגדרת יעדי האיכות בפרויקט, הפעילויות שתבוצענה להשגתן, ומדדי האיכות בפרויקט. יש להגדיר מדדי איכות לתהליכים ולמוצר (כולל יעדיםמדידים) |
|
1.5 קשר לתוכנית עבודה שנתית |
הפנייה לתוכנית עבודה מחלקתית שנתית בה הפרויקט מופיע. |
|
|
1.6.1 תועלות כמותיות |
הגדרת התועלות הכמותיות אותן צריכה המערכת לספק. ניתן להפנות בסעיף זה למשימת הפרויקט (בה אמורה להיות הגדרה כזאת). |
|
|
1.6.2 סיכונים |
הפניה לנספח ניתוח וניהול סיכונים העדכני של הפרויקט. יש לפרט תדירות ביצוע ניתוח סיכונים, ולהכניס פעילויות אלה לתוכנית העבודה. קיימים מספר מקורות לסיכונים: - טופס הערכת סיכונים במפת"ח (ראה קיט ניתוח סיכונים) - אתר הפקת לקחים |
|
|
2.2 משתמשים ומערכות משיקות |
הגדרת סעיף זה, ע"פ המוגדר במשימת הפרויקט. |
|
|
2.5 תהליכים |
הגדרת סעיף זה, ע"פ המוגדר במשימת הפרויקט. |
|
|
3.13 כלי פיתוח ותחזוקה |
פירוט כל הכלים אשר ישמשו לפיתוח, כולל זיהוי גירסה מדויקת. |
|
|
4.1 גורמים מעורבים |
ראה פירוט בסעיפים הבאים |
|
|
4.1.1 צוות מנהלי - ועדות היגוי |
יש לפרט לכל ועדה את יו"ר, משתתפים, תדירות התכנסות, נושאים לדיון וכו', או להפנות להוראה רלוונטית. יש לציין את שיטת ביצוע מעקב ההחלטות המתקבלות בוועדות. יש להכניס את פעילויות ההכנות והתכנסות הוועדות כפעילויות בתוך תוכנית העבודה. |
|
המצע וסיכומי דיונים של ועדות היגוי ישמרו כרשומות איכות. יש לפרט את המיקום המדויק בתיקיית הפרויקט בו נמצאות רשומות אלה. |
4.1.2 צוות מקצועי - |
תיאור מבנה ארגוני של הפרויקט, פירוט תפקידים ותחומי אחריות וסמכות לכל תפקיד. הפניה לנספח שמות בפועל אשר מפרט לכל תפקיד בפרויקט מי ממלא אותו בפועל (בדרך כלל בפרויקט קיימים תפקידים רבים, חלקם מבוצעים בו-זמנית ע"י אותו אדם. חשוב לתחזק רשימה כזאת הממפה את התפקידים ושמות ממלאי התפקידים). |
פירוט פעילויות איכות שכל בעל תפקיד בפרויקט יבצע. ניתן להפנות להוראות רלוונטיות. יש להכניס את הפעילויות הרלוונטיות לתוך תוכנית העבודה. |
|
4.1.3 סיוע טכני |
פירוט כל הגורמים המסייעים לפרויקט, כולל צוותי ממשקים במערכות משיקות, ואופן העברת המידע בין הגורמים. |
|
|
4.2.3 מימוש כולל - תוכנית עבודה |
יש להגדיר מראש את שיטת הפיתוח ואת סוג מחזור החיים (ראה קיט מחזורי חיים דינאמיים במפת"ח). יש להפנות לנספח תוכנית עבודה מפורטת של הפרויקט. |
יש להגדיר בתוכנית העבודה של הפרויקט את כל פעילויות האיכות הרלוונטיות, בדגש על סקרים, בדיקות, התכנסויות של ועדות, ניהול סיכונים וכל הפעילויות המופיעות בטבלה הנוכחית. |
|
4.5 אינדקס תיעוד |
תכנון תוצרי התיעוד אשר יופקו בכל שלב של מחזור החיים. |
פירוט מיקום רשומות האיכות השונות המופקות במהלך הפרויקט. |
|
4.6 שירות ותחזוקה |
פירוט ראשוני של השיטה המתוכננת לשירות ותחזוקת המערכת. |
פירוט (או הפניה לנספח) של השיטה לניהול התצורה בפרויקט. |
|
4.7.1 מערכי הדרכה ותוכנית הדרכה |
תכנון להדרכת האנשים בפרויקט בנושאים הדרושים להם לשם ביצוע תפקידם. |
תכנון פעילויות ההדרכה שהאנשים בפרויקט יעברו בנושא איכות. |
|
4.8.1 תוכנית בדיקות |
|
פירוט סוגי הבדיקות המתוכננות לביצוע בפרויקט. |
|
5. עלות |
פירוט עלויות הפרויקט כפי שמופיעות במשימת הפרויקט המאושרת |
תכנון העלויות הישירות של ביצוע פעילויות האיכות. |
|
ע"פ תקן ISO 9000:2000 וההנחיות הנלוות אליו ליישום בפרויקטי פיתוח תוכנה (תקןISO 90003), נדרש כל פרויקט לתכנן תוכנית פיתוח (Development Plan) ותוכנית איכות (Quality Plan). לכל תוכנית מגדיר התקן תכולה מינימלית נדרשת.
פירוט נושא זה כלול בקיט תקן ISO 9000 בכרך זה, כולל השוואה מפורטת בין דרישות התקן והסעיפים הרלוונטיים במפת"ח.
קיימות מספר גישות להתחלת הטמעת מפת"ח בארגון. להרחבה, ראה קיט הטמעת מפת"ח בארגון בכרך ניהול:
· מהארגון לפרויקטים
· פרויקט או מערכת נבחרת
ניתן לשלב בין גישות אלה תוך בחירת פרויקט אחד ומערכת אחת כדי להכיל את תחילת ההטמעה הן על שלבי הפיתוח והן על תחזוקה או להתחיל את העבודה במקביל. הטמעה מלאה בפרויקט מסוים ובמקביל להתחיל ולבנות בצורה רוחבית את תשתית אבטחת האיכות הארגונית.
הטמעה מרמת ההנהלה כלפי רמת הפרויקטים, המערכות והתהליכים הארגוניים. בגישה זו מתבצעות, בין היתר, הפעילויות הבאות:
· הגדרת אחראי מטעם הארגון לתהליך
· קבלת מחויבות הנהלה מפורשת לנושא
· ביצוע תיאום צפיות בין המעורבים השונים כולל סקירת הבעיות הקיימות
· מיפוי פרויקטים ומערכות: סטטוס, שלב במחזור חיים, ועדות, נהלים והוראות עבודה קיימים וכו'
· ביצוע Gap Analysis בין המצב הקיים למצב הרצוי בנושא הטמעת נושאי אבטחת איכות (קיום נהלים, הגדרת תפקידים מסודרת, ניהול תקלות וכו'). שלב זה יסתיים במסמך Gap Analysis
· אימוץ נוהל מפת"ח ובחירת פרויקט/ים ומערכת/ות אשר בהם תחל הטמעתו
· כתיבת נהלים בסיסיים כגון: נוהל שו"ש (שינויים ושיפורים) ונוהל פיתוח אשר בו ישולב נוהל מפת"ח
· ביצוע הדרכות לפי סוגי עובדים: מנהלים, משתמשים, מנתחי מערכות ועוד.
כל הפעילויות האלה הינן תחילת ההטמעה של ניהול האיכות בארגון.
לאחר סיום השלב הראשון בתהליך ההטמעה וסיכומו ניתן להמשיך ולהרחיב את הפעילות בנושא. במסגרת זו יש לבצע בין היתר את הפעילויות הבאות:
· הקמת פורום אבטחת איכות להצגת נושאים שונים
· הרחבת הטמעת נוהל מפת"ח ביתר הפרויקטים והמערכות
· כתיבת נהלים והוראות עבודה הן ברמה ארגונית והן ברמה פרויקטלית
· הגדרת מדדים אשר בעזרתם ניתן למדוד את שיפור האיכות בנושאים שונים בפיתוח ובתחזוקה
· שילוב כלים אוטומטיים בעבודת הפיתוח והתחזוקה.
בהמשך, ניתן לאמץ תקן כגון ISO9000 ולשלבו במערכת האיכות הארגונית.
בחירת פרויקט אחד אשר בו ניתן להדגים ולהוכיח את תרומת ניהול האיכות והעבודה לפי מפת"ח. בגישה זו מתבצעות, בין היתר, הפעילויות הבאות:
· הדרכת צוות הפרויקט בנושאי מפת"ח ואבטחת איכות
· "מפתוח" (התמרה למבנה של סרגל מפת"ח) מסמך הפרויקט האחרון (אם הפרויקט אינו בראשיתו) והמשך העבודה לפי מפת"ח
· כתיבת נהלים והוראות עבודה לפרויקט
· ליווי מלא של הפרויקט כמפורט בסעיף העוסק בכך לעיל.
מתוך לימוד העבודה בפרויקט הנבחר ניתן להרחיב את העבודה לפרויקטים ומערכות נוספות תוך בנייה במקביל של תשתית אבטחת איכות ארגונית.
אבטחת איכות לניהול האיכות ("אבטחת איכות בריבוע") היא בדיקה של אבטחת איכות עצמה:
· כיצד היא מתפקדת?
· מה תרומתה?
· האם היא מוצדקת?
· האם היא מחזירה את ההשקעה?
אין אלה שאלות "פילוסופיות", אלא שאלות מעשיות ביותר! אין תשובה פשוטה לשאלה זו משום שמדובר ביצירת נדבך נוסף אשר "בודק את הבודק" שייתכן שהוא עצמו מיותר ולא כדאי.
הצעת מפת"ח היא לבדוק את ניהול האיכות עצמו ותועלתו בשיטות הפשוטות, יחסית, המפורטות להלן:
1. אינטראקציה בין צוותי הפיתוח ואבטחת איכות. האופן בו אנשי הפיתוח (והתחזוקה) מתייחסים לאבטחת איכות היא מדד פשוט שיכול ללמד על תרומת א"א לפרויקטים.
2. מצגת תקופתית להנהלה. אין מנוס ממצגת תקופתית של ניהול האיכות לפני הנהלת המחשוב בארגון. מצגת כזו תיעשה, למשל, במסגרת תכנית העבודה השנתית, הן בהכנות (תכנון התכנית) והן במעקב ביצוע. במצגת כזו תפרט תסקור א"א את פעילותה ותצביע על מדדים ברורים, כגון:
· מס' פרויקטים מלווים
· מס' תיעודים שנכתבו \ נבדקו
· השתתפות בשיקופים וסקרים
· מס' סיכונים שאותרו ונוטרלו
· הדרכות שבוצעו
· נהלים שנכתבו, הופצו והוטמעו
3. מדדים תקניים: אפשר למדוד את א"א ב"גדול" מול מדדים 'מקובלים בשוק', כגון:
· מדד 1:20 הקובע שעל כל 20 ש"ע פיתוח (או 20 שקל הוצאה), יש להקצות 1 ש"ע (1 ₪) לא"א. בארץ, המדד המקובל נמוך יותר: 1:30 ולעתים אף פחות. החסרון של מדד זה הוא שהוא רק בצד ההוצאה ואינו מודד את התפוקה. תיתכן א"א שנמצאת במדד גבוה יותר (1:10), אבל משתתפת באופן פעיל ביותר בפיתוח!
· השוואה עם א"א בארגונים אחרים: בצד ההוצאה ובצד התפוקות. יש לנסות ולאתר ארגון דומה ככל האפשר, משום שההבדלים בין ארגונים שהם מסקטור שונה במשק, עשויים להיות משמעותיים.
4. פירוק תקציב א"א בין הפרויקטים. שיטה זו היא הרחבה משמעותית של 1 לעיל. תקציב א"א בנוי, בחלקו לפחות, מהעברות תקציביות של הפרויקטים אליו, בגין שירותים שא"א מספקת להם.
5. מדדים חיצוניים 1: פעילויות עסקיות חיצוניות של יחידת המחשוב (בתוך הארגון או מחוצה לו) בהם הייתה למערכת ניהול האיכות מעורבות ותרומה בולטת:
· כנסים
· הדרכות
· מתן שירות ללקוחות
6. מדדים חיצוניים 2: פעילויות עסקיות חיצוניות של ארגון האם בהם למערכת ניהול האיכות היתה מעורבות ותרומה בולטת:
· כנסים
· הדרכות
· מתן שירות ללקוחות