מנהיגים ברשת שולחן העבודה למנהלים בישראל
מאת: ד"ר דניאל גלין, ניתוב מערכות
תקציר
בתחום הבטחת איכות תוכנה, כמו בהבטחת איכות בתחומי התעשייה האחרים, מיוחסת חשיבות רבה למדידת האיכות, וספרים לא מעטים הוקדשו לנושא.
כמו בתחומים האחרים, ישנה טענה הגורסת כי הפעלת מדדי איכות בתחומי פיתוח התוכנה ואחזקת תוכנה היא תנאי הכרחי להפעלת הבקרה ולביצוע פעולות מתקנות הנובעות מממצאי הבקרה.
הניסיונות להפעלת מדדי איכות תוכנה נעשים, בדרך כלל, על פי התפישה הכללית, במסגרת מעגל בקרה הכולל את המרכיבים הבאים: קביעת יעדי איכות, בחירת מדדי איכות מתאימים עבור כל אחד מיעדי האיכות, תכנון מערך המדידות בשטח, ביצוע המדידות בשטח, איסוף הנתונים ועיבודם, ניתוח הנתונים וביצוע פעולות מתקנות במידת הצורך.
המאמר מוקדש לבחינה עיונית של הפעלת מדדי איכות תוכנה ולניתוח תהליך היישום, הלכה למעשה, בבית תוכנה גדול. הבחינה העיונית וגם הניתוח של הממצאים מניסיונות היישום מורים על קשיים ייחודיים וחמורים, במיוחד ביישום מדדי איכות בתחום פיתוח התוכנה ובתחום אחזקת התוכנה. קשיים ייחודיים אלה מתמקדים בשני מרכיבים במעגל הבקרה:
- קשיים בבחירת מדדי איכות מתאימים עבור כל אחד מיעדי האיכות.
- קשיים בניתוח הממצאים שנתקבלו לגבי מדדי האיכות.
בהמשך מראה הניתוח, כי קשיים ייחודיים אלה בהפעלת מדדי איכות תוכנה נובעים בעיקר מהשוני העקרוני של תהליך פיתוח התוכנה מתהליכי הייצור ה"רגילים" (לגבי פיתוח תוכנה), ומאופיו המיוחד של מוצר התוכנה (לגבי אחזקת תוכנה). המסקנה המתקבלת היא כי על אף הקשיים הייחודיים והגדולים, יש מקום להפעלת מדדי איכות תוכנה, אך זאת תוך זהירות יתר. בסיכום מוצגות דרכים להתגברות על הקשיים והמגבלות בהפעלת מדדי איכות תוכנה בארגון.
א. מבוא
בתחום הבטחת איכות תוכנה, כמו בתחומי הבטחת איכות האחרים, מוקדשת חשיבות רבה למדידת האיכות. כאמור, ספרים לא מעטים, המוקדשים לנושא מדידת איכות תוכנה, פורסמו בשנים האחרונות, שמהם נזכיר שניים:.
Fenton (1995), Moller and Paulish (1993)., כמו בתחומים האחרים, מאמינים כי הפעלת מדדי איכות בתחומי פיתוח התוכנה ואחזקת תוכנה היא תנאי הכרחי להפעלת הבקרה ולביצוע פעולות מתקנות הנובעות מממצאי הבקרה. כך, תום דמרקו (1982) קובע בפתח ספרו הקלאסי "אינך יכול להפעיל בקרה על מה שאינך יכול למדוד" ("You can't control what you can't measure"). הנושא זכה לעניין רב בכנסים הלאומיים והבינלאומיים של איגוד האיכות, ובשלושת הכנסים האחרונים הוצגו 4 מאמרים המוקדשים למדדי איכות תוכנה וליישומם: בר-גד (1994), בר דוד, וינוקור ולביא (1995), קנת, ופרמינגר (1995), פלורסקו, גלושקובסקי, והרשקוביץ (1995).
הניסיונות להפעלת מדדי איכות תוכנה נעשים, בדרך כלל, על פי התפישה הכללית, במסגרת מעגל בקרה הכולל את המרכיבים הבאים: קביעת יעדי איכות, בחירת מדדי איכות מתאימים עבור כל אחד מיעדי האיכות, תכנון מערך המדידות בשטח, ביצוע המדידות בשטח, איסוף הנתונים ועיבודם, ניתוח הנתונים וביצוע פעולות מתקנות במידת הצורך. דיון מפורט במתודולוגיה של הפעלת מדדי איכות מובא במאמר של בר-גד (1996) ובספרם של גלין ובלובבנד (1995).
לנו, בישראל, יש עניין רב בניסיון שנצבר בארץ בהפעלת מדדי איכות, הלכה למעשה. שלושה מהמאמרים שהוצגו בכנסי האיגוד האחרונים הנ"ל עוסקים ביישום המעשי של מדדי איכות תוכנה בחברות תעשייתיות. מאמרם של בר דוד, וינוקור ולביא (1995) מציג קשיים רבים בהתנעת התהליך של הפעלת מדדי איכות תוכנה בצוותי פיתוח תוכנה בתעשייה האווירית, ורואה כסיבה עיקרית את הלחץ הגדול על משאבי כוח האדם בפרויקטים האלה. המאמר מתבסס על הניסיון המצומצם שנרכש בהפעלת פרויקט פנימי של צוות הבטחת האיכות. כבר בפרויקט ייחודי זה נחשפו קשיים רבים ביישום. המסקנות המוצגות במאמר מצביעות על קשיים ארגוניים ומקצועיים של בחירת המדדים, השוני בין הפרויקטים השונים המחייב בניית מערכות מדדים ייחודיות לכל פרויקט או יחידה, הצורך בהקצאת משאבי כוח אדם רבים ומתן עדיפות לביצוע המדידה, ההתנגדות למדידה ואמינות הנתונים.
במאמרם של קנת ופרמינגר (1995) מוצגת הפעלת מדדי איכות תוכנה ככלי להכוונת מאמצי ההנהלה של חברה בינלאומית לשיפור תפקודם של צוותי פיתוח תוכנה שנקלעו לקשיים. במאמר מוצגת הדרך בה פותחו מדדי האיכות המודדים את ניהול הפרויקט, את ניהול הדרישות והתצורה ואת הבטחת האיכות, כאשר מקורות הנתונים הם הבטחת איכות, הנהלת פיתוח התוכנה ונתוני דיווח התקלות של לקוחות.
יישום מדדי איכות תוכנה בטלרד מוצג במאמרם של פלורסקו, גלושקובסקי והרשקוביץ (1995). מדדי האיכות שנבחרו עוסקים בעמידה בלוחות זמנים, בהפרש הזמן בין שלב היווצרות הליקוי לשלב גילויו ובאחוז הליקויים המתגלים לפני מסירת מוצר התוכנה ללקוח. במאמר מתוארים המדדים שנבחרו, אך לא מוצגים קשיים ביישום ודרכי התגברות על קשיים כאלה (אם היו).
ב. קשיים מתודולוגיים בהפעלת מדדי איכות תוכנה
את הקשיים בהפעלת מדדי איכות תוכנה אפשר לחלק לסוגים הבאים:
- קשיים בהשגת המשאבים הנדרשים (כוח אדם, משאבי מיחשוב, מימון) להקמת מערכת מדדי איכות ולתפעול השוטף שלה.
- קשיים הנובעים מגורמי אנוש, ובמיוחד התנגדות עובדים למדידת ביצועיהם.
- קשיים של אמינות הנתונים, הנובעים מדיווח חלקי או אף מוטה.
- קשיים מבניים ייחודיים בהגדרת מדדי איכות לפיתוח תוכנה ולאחזקתה.
שלושת סוגי הקשיים הראשונים אינם ייחודיים לתחום התוכנה ונדונים בהרחבה בספרות המקצועית הכללית העוסקת במדדי איכות, וגם בזו העוסקת במדדי איכות תוכנה. קשיים אלה נדונו גם בחלק מהמאמרים העוסקים בנושא, אשר הוצגו בכנסי האיגוד (והוזכרו לעיל). לפיכך, אין מקום להרחיב עליהם את הדיבור כאן. ברצוננו להתמקד בקשיים המבניים הייחודיים להפעלת מדדי איכות תוכנה.
ג. קשיים מבניים ייחודיים לתחום תוכנה
בחינה עיונית של הפעלת מדדי איכות תוכנה מצביעה על קשיים מבניים ייחודיים לתוכנה בהגדרת מדדים ברי יישום. בהמשך נתייחס למדדי תפוקה ולמדדי איכות. לא נתייחס למדדי עמידה בתקציב ובהקצאת משאבים ולמדדים של עמידה בלוח הזמנים, אשר ברובם אינם ייחודיים לפיתוח תוכנה.
במסגרת מאמר זה נתייחס למדדים בתחומים הבאים:
- מדדי תפוקה בפיתוח תוכנה
- מדדי איכות בפיתוח תוכנה
- מדדי פריון בתחזוקת תוכנה
קשיים במדדי תפוקה בפיתוח תוכנה
המדד הנפוץ, ואולי הטבעי ביותר לתפוקה הוא מספר אלפי שורות תוכנה KLOC – K Lines of Code)) או מדידה חליפית של נפח התוכנה שפותחה. למול הפשטות היחסית של המדידה של מדד כזה ניצבים קשיים מבניים בשימוש במדד שהעיקריים בהם הם:
- ההשפעה הקיצונית של סגנון התכנות על נפח התוכנה שפותחה, כאשר היחס בנפח בין "כתיבה חסכונית" ל"כתיבה בזבזנית" של אותה תוכנה יכול להיות 1 : 2 ואף יותר .
- ההשפעה של היקף ההערות הנכללות בתוכנה על נפח התוכנה, כאשר גם כאן לסגנון התכנות יש השפעה רבה.
- השלכות אופי התוכנה ומידת מורכבותה על ה"הספק", כאשר צפוי שתוכניתן העוסק בפיתוח תוכנה מורכבת ומסובכת יוגדר על פי מדד התפוקה הזה כבעל תפוקה נמוכה.
- השלכות היקף מיחזור התוכנה הנכלל בתוכנה, כאשר תוכניתן המשלב קטעי תוכנה ממוחזרים רבים בתוכנה שהוא מפתח צפוי שיימדד כבעל תפוקה גבוהה מזו של חברו העוסק בפיתוח תוכנה "מקורית".
- קושי בהשוואת התפוקה של תוכניתנים המפתחים בשפות תכנות שונות או בכלי פיתוח שונים במסגרת פרויקטים שונים או אף במסגרת אותו פרויקט.
קשיים במדדי איכות בפיתוח תוכנה
המדד הנפוץ הוא צפיפות הפגמים, הנמדדת במספר הליקויים המתגלים באלף שורות תוכנה (N / KLOC), כאשר N הוא מספר הליקויים שהתגלו. את הקשיים המתודולוגיים הכרוכים במדד הנפח KLOC כבר מנינו קודם. נבדוק, אפוא, את הקשיים המתודולוגיים הקשורים במספר הליקויים. כאן, גם אם נתבסס על ממצאים אובייקטיבים, על מנת לקבל מדידה בלתי מוטה, ככל האפשר, דהיינו, נתבסס על דו"חות של סקרי תיכון ומבחני תוכנה, עדיין נותרו כמה קשיים מבניים. להלן תיאור העיקריים מביניהם:
- השלכות רמת הסקר והמבחן והיקפן. מספר הפגמים המתגלים בסקר תיכון או במבחן תוכנה תלוי בהכרח ברמת הבדיקה ובהיקף הבדיקה. ככל שהבדיקה תהיה מעמיקה יותר ותכסה מספר רב יותר של נושאים, יש לצפות שיתגלו פגמים רבים יותר. כלומר, יתגלה אחוז גבוה יותר של הליקויים המצויים במסמכי התיכון של מערכת המידע או בתכנות שלה. כתוצאה, הערכת איכות התוכנה תהיה מותנית ברמת הבדיקה והיקף הבדיקה. באופן פרדוכסלי, ככל שרמת הבדיקה והיקפה ,תהיינה נמוכות יותר, כך תזכה התוכנה להערכה גבוהה יותר על פי המדד המוצע.
- השלכות של מורכבות התכנה, כאשר צפוי שבתוכנה מורכבת ומסובכת תהיה צפיפות הליקויים גבוהה יותר מאשר בתוכנה פשוטה.
- השלכות היקף מיחזור התכנה הנכלל בתוכנה, כאשר ככל שישולבו קטעי תוכנה ממוחזרים רבים יותר, כן צפויים פחות ליקויים.
- קושי בהשוואת האיכות של תוכניתנים המפתחים בשפות תכנות וכלי פיתוח שונים, בגלל הרמה השונה של תמיכה בחשיפת ליקויים המסופקת ע"י כלי התכנה וסביבות הפיתוח השונות.
- השלכות סגנון הסיכום של צוותי הבדיקה. מספר הליקויים שיוזכרו בדו"ח סקר או מבחן תוכנה מושפע לא מעט מסגנון ניסוח הממצאים: ניסוח תמציתי, המאגד בהערה אחת מספר ממצאים, לעומת ניסוח מפורט המונה בנפרד כל ליקוי שאותר.
קשיים במדדי פריון בתחזוקת תוכנה
אחד המדדים המקובלים, AMH / KLOC (Annual Maintenance Hours per KLOC), מחושב על פי מספר שעות התחזוקה השנתיות המושקעות באלף שורות תוכנה מתוחזקת. ההנחה המונחת כבסיס למדד זה היא כי צוות תחזוקה יעיל יותר יבצע את התחזוקה הנדרשת בפחות שעות שנתיות. את הקשיים המתודולוגיים הכרוכים במדד הנפח KLOC כבר מנינו קודם. נבדוק, אפוא, את הקשיים המתודולוגיים הקשורים במספר שעות התחזוקה המושקעות. להלן תיאור הקשיים העיקריים:
- השלכות איכות התכנה שנמסרה לתחזוקה. ככל שאיכות התכנה שנמסרה לתחזוקה נמוכה יותר, כן יגבר העומס המוטל על המתחזקים, זאת ללא קשר לרמת הפריון של המתחזקים. כאן המקום להזכיר כי עקב הקשיים בהערכת איכות התכנה, הערכה גבוהה שניתנה לתוכנה בשלב הפיתוח לא בהכרח תתאים למצב הממשי.
- השלכות של מספר ההתקנות ומספר המשתמשים בתוכנה. ככל שיגדל מספר ההתקנות של התכנה וככל שיגדל מספר המשתמשים בכל אתר שהותקנה בו התכנה, כן צפוי שיגדל מספר הפניות לתחזוקה. במילים אחרות, תוכנה המותקנת במספר אתרים מצומצם ומשמשת מספר משתמשים קטן "תזכה" את המתחזקים בהערכת פריון גבוהה יותר מאשר אותה תוכנה המותקנת במספר אתרים גדול ומופעלת ע"י משתמשים רבים.
- השלכות עומק היישום של התכנה. ככל שהמשתמשים מעמיקים את השימוש בתוכנה ומפעילים שימושים מתקדמים יותר, יופעלו מודולים רבים יותר בתוכנה (ובדרך כלל גם המורכבים והמסובכים יותר), וצפויים שייחשפו ליקויים רבים יותר. ומכאן, שהעמקת היישומים עלולה לגרום להורדת הפריון של המתחזקים, ללא קשר לרמתם המקצועית ויעילותם בביצוע התחזוקה.
- השלכות אופי התכנה ומידת מורכבותה על עומס התחזוקה, כאשר צפוי שצוות העוסק בתחזוקת תוכנה מורכבת ומסובכת יוגדר על פי מדד פריון התחזוקה הזה כבעל פריון נמוך.
- השלכות היקף מיחזור התוכנה הנכלל בתוכנה. צוות תחזוקה האחראי לתוכנה שמשולבים בה קטעי תוכנה ממוחזרים רבים, צפוי שיימדד כבעל פריון גבוה מזה של צוות העוסק בתחזוקת תוכנה "מקורית".
- קושי בהשוואת האיכות של צוותים האחראים לתחזוקת תוכנה בשפות תכנות וכלי פיתוח שונים, בגלל הרמה השונה של תמיכה בחשיפת ליקויים המסופקת ע"י כלי התוכנה וסביבות הפיתוח השונים.
מדד פריון תחזוקה אחר יתייחס למספר פניות לתחזוקה שמטפל בהן איש צוות בשנה. מדד זה מבוסס על ההנחה שככל שהוא גבוה יותר, כן גבוהה יותר רמת הפריון של העובד. גם מדד זה "סובל" מקשיים אחדים, השונים מאלו שמהם "סובל" קודמו:
- השלכות אופי התוכנה ומידת מורכבותה על "הפריון", כאשר צפוי שתוכניתן העוסק בתחזוקת תוכנה מורכבת ומסובכת, יצטרך להשקיע בממוצע זמן רב יותר בטיפול בפניה לטיפול בתקלה מאשר חברו העוסק בתחזוקת תוכנה "פשוטה", וכתוצאה, ימצא, על פי מדד פריון התחזוקה הזה, כבעל פריון נמוך יותר.
- השלכות שיטת התחזוקה – תחזוקה טלפונית במוקד שרות, לעומת תחזוקה "באתר הלקוח". ככל שמאפייני התוכנה והמשתמש מחייבים אחוז גבוה יותר של תחזוקה באתר הלקוח, כן צפוי שמדד הפריון של העובד יימצא נמוך יותר. זאת ללא תלות ברמתו המקצועית או ביעילותו.
- קושי בהשוואת האיכות של צוותים האחראים לתחזוקת תוכנה בשפות תכנות וכלי פיתוח שונים, בגלל הרמה השונה של תמיכה בחשיפת ליקויים המסופקת ע"י כלי התוכנה וסביבות הפיתוח השונות.
- השלכות צורת התארגנות הלקוח לפניה לשירות: פניה מרוכזת דרך אחראי תוכנה של הארגון לעומת פניה אישית ישירה של המשתמשים. בפניות מרוכזות צפוי שייכללו נושאים אחדים, ובמקרה שפניה כזאת נרשמת כפניה אחת, הרי שמספר הפניות הנצבר ל"זכות" המתחזק יהיה נמוך יותר. יש גם לצפות שבהתארגנות כזאת אצל המשתמשים, יפתור האחראי את רוב התקלות הפשוטות בכוחות עצמו ויעביר לאיש תחזוקת התוכנה בעיקר את הטיפול בתקלות מורכבות יותר, שרבות יותר מתוכן דורשות טיפול באתר הלקוח.
כל הקשיים המתודולוגיים שפורטו לעיל, לגבי המדדים השונים, מתבטאים בהכרח בקשיים בעת ניתוח הממצאים.
ד. קשיים בתהליך היישום הלכה למעשה בבית תוכנה גדול
התצפיות על תהליך היישום של מדדי איכות נערכו בבית תוכנה ישראלי במהלך כשנתיים (1995-1997). בית התוכנה מעסיק כ – 300 עובדים ועוסק בפיתוח תוכנה, במתן שירותי מוקד ללקוחות שרכשו את התוכנה ומפעילים אותה בעצמם ובביצוע תפעול שוטף ותחזוקת תוכנה עבור לקוחות אחרים שהעדיפו תפעול ע"י גורם חיצוני. לצורך הערכת יישום מדדי האיכות נתייחס למערך היחידות וצוותים שהוקם במסגרת מערכת האיכות לצורך הפעלתה, ומשמש, בין היתר, למבדקי איכות פנימיים. סה"כ נכללו במערכת האיכות 38 פרויקטים ויחידות. מאחר ותעסוקת היחידות מתייחסת לתחומים שונים ומגוונים, הוחלט כי כל יחידה תגדיר את מדדי האיכות המתאימים לה, כאשר יחידת הבטחת האיכות הדריכה את אנשי היחידות וסייעה בייעוץ במהלך הגדרת מדדי האיכות. בתחילת 1996 הגיע "אחוז כיסוי" במדדי איכות ל – 74%, כאשר 28 מתוך כלל 38 היחידות והצוותים הפעילו מדדי איכות, והעבירו דו"חות חודשיים בנושא באופן סדיר. רוב רובן של היחידות הפעיל מדדי איכות המתייחסים ליחידה אחת, ורק באחד מאגפי החברה הונהג דיווח מרכזי שריכז דיווח על 8 יחידות באגף (יחידת תחזוקה, צוות מכירות ו – 6 צוותי פיתוח תוכנה, שעבורם הופעלו מדדים משותפים שחושבו על פי צרוף הנתונים). בנוסף, באגף אחר צורפו הדיווחים של 4 יחידות העוסקות בתפעול ותחזוקה למדדים משותפים. שנה לאחר מכן ירד מספר היחידות המפעילות מדדי איכות ל – 20 בלבד (53%). הסיבה לכך הייתה שאותו האגף שהנהיג דיווח מרכזי מצא כי אפשרויות ההסקה והפעלת פעולות מתקנות, על פי מדדי האיכות שהופעלו, היו מצומצמות ביותר, ובפועל, בלתי מעשיות. כתוצאה, הוחלט לתכנן מערך חדש של מדדי איכות ליחידות האגף.
התפלגויות לפי סוג העיסוק של כלל היחידות והצוותים שבמערך האיכות ושל היחידות שהפעילו מדדי איכות מוצגות בטבלה 1.
טבלה 1: היחידות והצוותים של בית התוכנה והפעלת מדדי איכות לפי סוג העיסוק.
| סוג העיסוק של היחידה/הצוות | סה"כמספר היחידות/ | מספר היחידות/ הצוותים שהפעילו מדדי איכות | |
| הצוותים | 1996 | 1997 | |
| פיתוח תוכנה | 8 | 6 | 0 |
| תפעול שוטף ותחזוקת תוכנה | 16 | 10 | 9 |
| מוקד שירות ללקוחות (משתמשי תוכנה) | 2 | 1 | 1 |
| שירותים אחרים ללקוחות | 2 | 2 | 2 |
| מכירות של פיתוח תוכנה ושירותי תוכנה | 3 | 2 | 1 |
| מוקד שירות ותחזוקה לחומרה ותוכנות התשתית של בית התוכנה | 5 | 5 | 5 |
| שירותים תומכים של בית התוכנה | 2 | 2 | 2 |
| ס ה " כ | 38 | 28 | 20 |
לצורך סקירת מדדי איכות התוכנה נבדקו הדיווחים שהעבירו היחידות השונות ליחידת הבטחת האיכות בשתי תקופות:
- תקופה א': ינואר עד יוני 1996 (6 חודשי דיווח)
- תקופה ב': ינואר עד מאי 1997 (5 חודשי דיווח)
יחידה נחשבה כמפעילה בתקופת סקר אם העבירה דיווח סדיר של מדדי האיכות עבור כל אחד מחודשי התקופה.
לצורך הדיון אפשר למיין את מדדי איכות התוכנה לארבעה סוגים:
- מדדים לעומס על היחידה.
- מדדים לפריון העבודה של עובד/צוות.
- מדדים לאיכות של הפיתוח או התחזוקה של תוכנה.
- מדדים לעמידה בלוח זמנים (לו"ז).
סה"כ הופעלו בתקופה הראשונה 86 מדדי איכות ביחידות ובצוותים השונים, מהם 12 (14%) היו מדדים לעומס, 48 (56%) היו מדדים לאיכות ו – 26 (30%) היו מדדים לעמידה בלו"ז.
התפלגות לפי סוג היחידה של מדדי האיכות שהופעלו בתקופה א' מוצגת בטבלה 2.
טבלה 2: התפלגות לפי סוג היחידה של סוגי מדדי האיכות שהופעלו (בתקופה א')
| ס ו ג ה מ ד ד | ||||
| ס ו ג ה י ח י ד ה | מדדים לעומס | מדדים לפריון | מדדים לאיכות | מדדים לעמידהבלו"ז |
| פיתוח תוכנה | — | — | 2 | 1 |
| תפעול שוטף ותחזוקת תוכנה | 7 | — | 14 | 5 |
| מוקד שירות ללקוחות (משתמשי תוכנה) | — | — | 10 | 15 |
| שירותים אחרים ללקוחות | — | — | 3 | 2 |
| מכירות של פיתוח תוכנה ושירותי תוכנה | 2 | — | 4 | — |
| מוקד שירות ותחזוקה לחומרה ותוכנות התשתית של בית התוכנה | 2 | — | 8 | 2 |
| שירותים תומכים של בית התוכנה | 1 | — | 7 | 1 |
| ס ה " כ | 12 | — | 48 | 26 |
השוואת הממצאים שנתקבלו לגבי היחידות השונות בהשוואת המדדים שחושבו עבור שתי התקופות הראתה מגמה של יציבות במדדי האיכות ומדדי העמידה בלו"ז ברוב רובן של היחידות.
ליווי תהליך הפעלת מדדי איכות תוכנה ביחידות של בית התוכנה, דיונים עם בכירי היחידות וניתוח הממצאים הביאו למסקנות הבאות:
- למרות המאמצים שהושקעו במהלך 1995 ו – 1996, ברבע מהיחידות והפרויקטים לא הושגה הצלחה בהגדרת מדדי איכות תוכנה. הדבר נבע בעיקר מהקשיים המבניים הטמונים בהגדרת מדדי איכות תוכנה, כאשר הנושאים שהועלו בדיונים היו כמעט כולם מתוך אלה שפורטו בפרק הקודם.
- לכל היחידות שהצליחו להגדיר מדדי איכות תוכנה היה קושי בקביעת מדדי פריון לעבודות פיתוח תוכנה או לתחזוקת תוכנה, כפי שהתבטא בכך שלא נמצאה אפילו יחידה או צוות אחד שיגדיר מדד פריון עבודה. היחידות העדיפו, בשלב זה, להפעיל מדדים לעומס, בהנחה שבהמשך, לאחר שייצברו ניסיון וידע לגבי העומס המוטל על היחידה, אפשר יהיה לפתח מדדים לפריון שיתבססו על המדדים לעומס. מצב זה, המצביע על הקושי ליישם מדדי איכות לפריון העובד, תואם את הקושי המבני של קביעת מדדי פריון בתחום התוכנה, אשר הוצג בפרק הקודם.
- היחידות הצביעו על חוסר אפקטיביות של חלק ניכר מהמדדים שנבחרו, כאשר שינויים שחלו בין התקופות לא אובחנו כלל במדדים הרלבנטיים. בכל המקרים הצביעו ביחידות על קשיים מבניים עקרוניים המבטלים את האפשרות להתייחס לתוצאות ולהסיק מהן מסקנות מעשיות.
- היחידות הצביעו על אילוצים בבחירת המדדים, עקב ההכרח לבצע איסוף ועיבוד נתונים ידניים. במילים אחרות, העדר מיחשוב בתחום מדדי האיכות הביא להעדפת מדדים נחותים, אך ברי-ביצוע ללא מיחשוב.
- רוב היחידות לא שינו את מתכונת המדדים בין תקופה א' לתקופה ב', והצביעו על עצם הפעלת המדדים במשך כשנתיים כצעד הכרחי של התנסות ולימוד לקראת קביעת מדדים נאותים. רוב היחידות יעדו את המחצית השנייה של 1997 וראשית 1998כתקופה שבה יוגדרו מדדי איכות תוכנה משופרים. ברוב היחידות צפו כי יחולו שינויים רחבים ומהותיים בהגדרת מדדי האיכות.
מעניין להציג את השינויים שחלו במפת המדדים של יחידה, אשר במקביל לשינויים ארגוניים, ערכה שידוד מערכות בתחום המדדים בין תקופה א' לתקופה ב'. הרכב המדדים השתנה באופן משמעות: 2 מדדים בוטלו, ומשאר 4 המדדים רק 2 מדדים מתקופה א' הופעלו שוב בתקופה ב'. להלן, בטבלה 3, מוצג אופיו של השינוי שחל במדדי האיכות המופעלים ע"י היחידה:
טבלה 3: השוואת מדדי האיכות שהופעלו בשתי התקופות ע"י יחידה בבית התוכנה
| סוג מדד האיכות | הופעל ללא שינוי בתקופה א' ובתקופה ב' | הופעל רק בתקופה א' | הופעל רק בתקופה ב' |
| מדדים לעומס | 1 | 1 | |
| מדדים לפריון | |||
| מדדים לאיכות | 3 | 2 | |
| מדדים לעמידה בלו"ז | 1 | ||
| ס ה " כ | 2 | 4 | 2 |
אף שאין זו אלא דוגמא המתייחסת ליחידה אחת, אפשר לראות בעומק ובהיקף השינוי המוצגים כאן את היקף ומהות השינויים הצפויים גם במרבית היחידות האחרות לאחר שיערכו ניתוח של הניסיון שהצטבר אצלן בהפעלת מדדי איכות.
ה. סיכום
הניתוח העיוני של מדדי איכות תוכנה והניתוח של הניסיון שנצבר בבית תוכנה גדול, אשר הוצגו במאמר, מצביעים על קשיים מתודולוגיים רבים, הייחודיים לתחום הפיתוח והתחזוקה של תוכנה.
נראה כי הגורם העיקרי לקשיים ייחודיים אלה נעוץ בשוני המהותי של התהליכים הנמדדים. בעוד שבתחום "ייצור" התוכנה מתייחסים מדדי איכות לשלב הפיתוח של המוצר במחזור החיים של המוצר, בענפים האחרים, כגון ייצור מזון או יצור מכונות, ההתייחסות של מדדי האיכות היא בעיקר לשלב הייצור במחזור החיים של המוצר. במילים אחרות, כאשר מפעילים מדדים, המשותף לתהליכי "ייצור" של תוכנות היא מתודולוגיה משותפת, בעוד שבענפים אחרים המדדים מופעלים לגבי חזרה מדויקת על תהליך הייצור של המוצר.
הבדל מהותי קיים גם במדדי האיכות של התחזוקה. זאת מאחר ותחזוקת תוכנה עוסקת בתיקון פגמים שנוצרו בשלב הפיתוח של התוכנה ולא נחשפו עד למועד ההתקנה אצל הלקוח, כאשר איכות המוצר נשארת קבועה מיום שנמסרה ללקוח ואינה נתונה לשינוי לרעה עקב הזדקנות התוכנה. לעומת זאת, התחזוקה בענפים האחרים מתייחסת בעיקר לקלקולים הנובעים מהשימוש במוצרים ומהזדקנות המוצרים.
למרות הקשיים המתודולוגיים הניכרים יש חשיבות רבה להפעלת מדדי איכות גם בתחום התוכנה. להערכתנו, הדבר ניתן לביצוע, כלומר, ניתן להגדיר מדדי איכות שיאפשרו הסקת מסקנות מהשוואת ממצאים של מדידות שנעשו ביחידות שונות או בזמנים שונים. בהתחשב בקשיים שהוצגו לעיל, הפעלת מדדי איכות תוכנה במסגרת הארגון צריכה להיעשות במשנה זהירות ובשלבים המבוססים על מדרג קושי יישומי. רק לאחר צבירת ניסיון והצלחה בשלב מדרג מסוים אפשר לשקול יישום בשלב מדרג גבוה יותר. שלבי המדרג המוצעים הם:
השוואת הישגי איכות נוכחיים עם:
- יעדי איכות שנקבעו לפרויקט או ליחידה.
- הישגים של אותה יחידה או פרויקט בתקופה קודמת.
- הישגים של אותו צוות בפרויקטים אחרים המבוצעים על ידו באותם כלי פיתוח ובאותה סביבת פיתוח.
- הישגים של אותו צוות בפרויקטים אחרים המבוצעים על ידו בכלי פיתוח ו/או בסביבת פיתוח אחרים.
- הישגים של צוותים אחרים המבוצעים באותם כלי פיתוח ובאותה סביבת פיתוח.
- הישגים של צוותים אחרים המבוצעים בכלי פיתוח ו/או בסביבת פיתוח אחרים.
- הישגים של צוותים בארגונים אחרים המבוצעים באותם כלי פיתוח ובאותה סביבת פיתוח.
- הישגים של צוותים בארגונים אחרים המבוצעים בכלי פיתוח ו/או בסביבת פיתוח אחרים.
פעילות נוספת לקידום הפעלת מדדי איכות תוכנה היא פיתוח מדדים מתקדמים שיתבססו על מחקר בתחום. כדוגמא אפשר להביא את מדד "הניקוד הפונקציונלי" (function points) כמדד לתפוקה בפיתוח תוכנה. מדדים מתקדמים כאלה יוכלו לסייע גם לשיפור ההערכות של תשומות דרושות ואיכות צפויה בפיתוח ותחזוקת תוכנה.
ביבליוגרפיה
- (1) בר-גד שוקי (1996) "מדדי איכות ככלי להכרה עצמית", ספר המאמרים של הכינוס הבינלאומי ה11- של האיגוד הישראלי לאיכות, עמ' 269 – 274.
- (2) גלין דניאל ובלובבנד זיגמונד (1995) "הבטחת איכות תוכנה", הוצאת "אופוס", תל-אביב, עמ' 221 – 240.
- (3) בר-דוד אשר, וינוקור מיכאל, לביא יצחק (1994) "מדידות תוכנה בתעשייה האווירית", ספר המאמרים של הכינוס הבינלאומי ה10- של האיגוד הישראלי לאיכות, עמ' 288 – 294.
- (4) קנת רון, פרמינגר יהושע (1995) "מדדים כמותיים של תהליכי פיתוח תוכנה: דוגמאות יישום", ספר המאמרים של הכינוס הלאומי ה3- של האיגוד הישראלי לאיכות, עמ' 260 – 266.
- (5) פלורסקו רדו, גלושקובסקי אלי, הרשקוביץ ענת (1995) "מדדים לפיתוח תוכנה בטלרד", ספר המאמרים של הכינוס הלאומי ה3- של האיגוד הישראלי לאיכות, עמ' 267 – 271.
tweet[Google]
Follow @leadersnet
| מנהיגים ברשת |
| www.leadersnet.co.il |
| leaders@leadersnet.co.il |
| © כל הזכויות שמורות ל"מנהיגים ברשת" דצמבר 2005. החומר מותר לשימוש אישי בלבד. אין לעשות בחומר שימוש מסחרי/עסקי ו/או להפיצו בכל דרך שהיא (להוציא באמצעות יצירת קישור למאמר ספציפי ולעמוד הבית במקביל) מבלי לקבל רשות מפורשת בכתב מהנהלת האתר |
