|
|
|
 |
בקרת
עלויות פיתוח ישומים בעזרת כלי ניהול
תצורת תוכנה אין בנמצא ארגון שאיננו עוסק
בין שאר פעילויותיו גם בניהול תצורה, בין אם יש לו כלי לעשות זאת בין אם
לאו. שורה שלמה של הוצאות בארגון קשורות לניהול תצורה, וגובהן תלוי בסביבת
הפיתוח. בפרוייקטים של פיתוח, בערך
15% מהמאמץ היומיומי קשורים לעיסוק בפעילויות ניהול תצורה. מספר זה עולה
עד 25% בפעילויות של אחזקת תוכנה. ניהול תצורה יעיל, מבוסס
על כלים אוטומטיים מתקדמים, יכול להביא לירידה של עד 30% בתקציבי הפיתוח.
תוכן הענינים
1.
מבוא.
2.
תשובה לאתגרים העומדים בפני ארגוני פיתוח תוכנה.
3.
החוליה החסרה.
4.
העלויות הסמויות של פיתוח ישומי תוכנה.
5.
עשרת הפעילויות העיקריות של ניהול התצורה.
6.
המרת עלויות נסתרות לרווח.
7.
תוכנית תלת-שלבית לניהול ובקרה.
8.
עלויות פיתוח.
9.
חישוב החסכון היומיומי בארגון והחזר ההשקעה.
10.
סיכום.
מבוא מטרת מסמך זה היא להראות כיצד יכול ארגון לצמצם את הוצאות הפיתוח שלו בשיעורים של עד 30%, על ידי שימוש נכון ויעיל
בכלי ניהול תצורת תוכנה ושינויים. כן יעזור המסמך בזיהוי עשרת
הפעילויות העיקריות של ניהול תצורה והעלויות הקשורות לכל אחת מהן. החסכון הפוטנציאלי ותקופת
החזר ההשקעה מחושבים גם הם, במטרה לתת בידי המתעניין כלי לקידום ניהול התצורה
האוטומטית בתוך ארגונו
תשובה לאתגרים העומדים
בפני ארגוני פיתוח תוכנה כמה מן הנושאים המציבים כיום
אתגר בפני בתי תוכנה הם:
·
שמירה על רמת איכות גבוהה.
·
הגברת הפריון.
·
בקרת עלויות.
·
עמידה בלוחות זמנים.
·
עמידה בדרישות ובביקורות
תקנים וסרטיפיקציות. כדי לעמוד
בלחצים ובאתגרים אלה, ארגונים רבים הכניסו מגוון טכנולוגיות וכלי ניהול חדשניים,
כולל:
·
סביבות שרת / לקוח.
·
שפות פיתוח מתקדמות, כלי
פיתוח מוכוונים עצמים וכו'…
·
קבוצות וכלי בדיקה.
ועוד.
בתקציבי הפיתוח האופייניים
להיום, כלים ופעילויות אלה הפכו לפריטי הוצאה תקניים, והם מעמיסים בצורה
משמעותית על עלות הפיתוח הכוללת של ישומי תוכנה. למרות זאת, עדיין נשאלת
השאלה: האם הכנסת אסטרטגיות וטכנולוגיות חדשות לארגון מפחיתה במידת מה את
הלחצים ומקטינה את האתגרים? או האם המצב משתפר?
לגבי רוב הארגונים, התשובות
לשאלות אלה הן מעורבות. אולם אין עוררין על העובדה כי, כמעט תמיד, שיפור
בתחום אחד גורר אחריו הרעה בתחומים אחרים.
החוליה החסרה
למרות שרוב תקציבי פיתוח
התוכנה כוללים רבים מפריטי ההוצאה המפורטים לעיל, רק מתי מעט מהם כוללים
גם את קטגורית כלי ניהול התצורה ושינויי התוכנה. כאשר מתעניינים מדוע, רוב
הנשאלים משיבים: "האם כוונתך לכלי ניהול גרסאות? למפתחים שלנו יש כלים
כאלה…" נשאלים רבים אחרים אינם בטוחים באשר למובן
של המונח "ניהול תצורה". ואפילו אלה להם יש סעיף תקציבי מפורש
לניהול תצורה אינם תמיד מודעים לתועלת הרבה שניהול תצורה יכול להביא להם.
ניהול
תצורה, כאשר הוא מתוכנן ומיושם
בעזרת מתודולוגיה נכונה ומקצועית, יכול להפוך הוצאה
לרווח. אפשר לזהות את כל פעילויות ומשאבי ניהול התצורה, גם בהיעדר
כלי כזה בארגון. בהמשך, ננסה להעריך את עלותם של פעילויות ומשאבים אלה, ולכמת
את ההשלכות שיש להיעדר אסטרטגיה מוגדרת של ניהולם. כמוכן נראה כיצד ניהול
תצורה נכון יכול לעזור לארגון ליהנות מהיתרונות הגלומים בשימוש בטכנולוגיות
ובכלים החדשניים של היום.
מחקרים מוכיחים כי ניהול
תצורה יעיל, מבוסס על כלים אוטומטיים מתקדמים, יכול להביא לירידה של 30%
ויותר בתקציבי הפיתוח.
העלויות הסמויות של פיתוח ישומי תוכנה
אין בנמצא ארגון שאיננו עוסק
בין שאר פעילויותיו גם בניהול תצורה, בין אם יש לו כלי לעשות זאת בין אם
לאו. להלן ההגדרה של פעילויות
ניהול תצורה:
<< פעילויות ניהול
תצורה הן המשימות, הכלולות בפרוייקט פיתוח או אחזקה, המאפשרות זיהוי, בקרה
וניהול של שינויים בתוכנה, לאורך כל מחזור החיים של פיתוח או אחזקת התוכנה
>>
המחקרים מגלים שורה שלמה
של הוצאות בארגון הקשורות לניהול תצורה, הוצאות שגובהן תלוי בסביבת הפיתוח.
בסביבות ריכוזיות ולא מבוזרות (לא שרת/לקוח) שאין בהן אסטרטגיה של ניהול
תצורה, בערך 15% מהמאמץ היומיומי קשורים לעיסוק בפעילויות ניהול תצורה בפרוייקטים
של פיתוח. מספר זה עולה עד 25% בפעילויות של אחזקת תוכנה. בסביבות שרת/לקוח, למרות
שהן אמורות להבטיח פריון גבוה יותר, המספרים הללו גדלים עוד יותר, ומגיעים
בהתאמה עד לכדי 20% ו - 40% !!!
עשרת הפעילויות העיקריות של ניהול
התצורה
ברוב סביבות הפיתוח, אפשר למנות עשר פעילויות עיקריות
של ניהול תצורה:
1.
גישה לתוכנה ומשיכתה מן המטמנת (Repository).
2.
התאמת שינויי התוכנה לאורך כל מחזור החיים של המוצר.
3.
הגירה (Migration) של
שינויים לאורך כל מחזור החיים של המוצר.
4.
ניהול תהליכי בנייה והידור (Build and Compile).
5.
ניהול ההפצה של השינויים.
6.
קבלת אישורים.
7.
ניהול בקשות לשינויים בתוכנה.
8.
תיאום תקשורת בין קבוצות ובתוכן.
9.
קבלת דיווחים על מצב (סטטוס) של פרוייקטים.
10.
מעקב תקלות ותיקונן.
א. גישה לתוכנה ומשיכתה מן המטמנת (Repository).
פעילות זו מייצגת את הזמן הדרוש לקביעת גרסת (פיתוח,
בדיקה, הרצה, מוצר…) רכיב התוכנה עליו אמור לעבוד המפתח, והיכן הוא יכול לקבל אותו.
למשל, במקרים מסוימים אין לשנות אלא את גרסת "היצור". במקרים אחרים,
יש לכלול שינויים מפרוייקטים אחרים העשויים להימצא בשלב של פיתוח או בדיקה.
פעילות זו הופכת למורכבת יותר בעת שמפתחים אינם יודעים היכן נמצאים רכיבי
התוכנה "הפעילה" והיכן למצוא את הגרסה הנכונה. ומהו נוהל העבודה
בעת ששני מפתחים או יותר עובדים על אותו רכיב עצמו? האם עליהם לחכות עד הסיום?
והיכן עליהם לשמור את השינויים?
עלויות הגישה אל והמשיכה של תוכנה מהוות
עד - 3% מעלות הפרוייקט.
ב. התאמת שינויי התוכנה לאורך
כל מחזור החיים של המוצר.
ברוב הארגונים המפתחים, יש תמיד יותר מגרסת תוכנה אחת
פעילה במשך מספר שלבים של מחזור החיים של המוצר. במקרים אחרים, מספר גרסאות
עשויות להימצא בשלב של פיתוח או אחזקה בעת ובעונה אחת. בכל המקרים הללו מדובר
בכניסת הארגון לפיתוח מקבילי. תהליך כזה אמנם תורם למאמץ הפיתוח, אולם הוא
מביא עמו בעיות חדשות. למשל: כיצד יהיו המפתחים בטוחים שכל הרכיבים אכן תואמים
(synchronized)? כיצד יש להימנע מכתיבה (וממחיקה) של שינויים שנעשו? וכיצד תובטח
שלמות ואמיתות היישום?
התאמת שינויי התוכנה מהוות עד 10%
מעלות הפרוייקט.
ג. הגירה (Migration)
של שינויים לאורך כל מחזור החיים של המוצר
לאחר שהסתיים פיתוח השינויים, יש להעבירם (Migration) דרך כל שלבי מחזור החיים של המוצר. בדרך כלל, אין מעבירים רק רכיב
אחד, ויש להעביר קבוצה שלמה של קבצים ששונו, אחרת שלמות המוצר היא בסכנה.
שינויים יכולים גם להיות מועברים "לאחור". למשל, בעת פסילת שינויים
לאחר בדיקה, יש להחזיר את השינויים לפיתוח. ככל שמתרבים שלבי הבדיקה השונים,
ניהול המעבר של השינויים הופך ליותר ויותר מורכב וצורך משאבי ניהול תצורה.
הגירה (Migration) של שינויים
מהווה עד 6% מעלות הפרוייקט.
ד. ניהול תהליכי בנייה והידור
(Build and Compile)
רוב פיתוחי התוכנה מסתיימים בבניית קובץ EXE (או מודול אחר) הנוצר על ידי הידור קובצי המקור. רכיבים חסרים או
שגויים פוגמים בשלמות המוצר. ניהול תהליך הבנייה וההידור הוא אם כן אחד החשובים
בארגון. עם התפתחות השימוש בספריות, ניתוח ההשלכות (Impact Analysis) של שינויים בתוכנה הוא צורך חשוב מאין כמוהו.
ניהול תהליכי בנייה והידור (Build and Compile) מהווה עד 5% מעלות הפרוייקט.
ה. ניהול ההפצה של השינויים
הפצת השינויים כוללת את כל המאמצים הדרושים להבטיח שהמוצר
מוכן לעבור ליצור אלקטרוני המוני, והיכולת לדעת איזו גרסה של הישום נמצאת
בשימוש קבוצת משתמשים.
ניהול ההפצה של השינויים מהווה עד 3% מעלות הפרוייקט.
ו. קבלת אישורים
ברוב הפרוייקטים המשולבים לפיתוח יישומים, יש צורך בקבלת
אישורים קודם לנקיטת פעולות כמו העברת נתונים (Migration), הפצה (Distribution) וכו'. איתור האנשים המתאימים יכול להוות
לעתים בעיה של ממש.
קבלת אישורים מהווה עד 2% מעלות הפרוייקט.
ז. ניהול בקשות לשינויים בתוכנה
תהליך ניהול ידני של אינפורמציה על בקשות שינויים בתוכנה
הוא מגושם וצורך זמן רב. האינפורמציה האופיינית לסוג זה של מעקב ידני על
ידי ניירת היא:
·
מפתח / בודק לו הוצמד השינוי.
·
תאריך ההעברה / הסיום.
·
מידע על השינוי.
·
בקשות לשינויים אחרים המתייחסים לבקשה הנוכחית.
·
רכיבי התוכנה המיועדים לשינוי.
ניהול בקשות לשינויים בתוכנה מהווה עד 2% מעלות הפרוייקט.
ח. תיאום תקשורת בין קבוצות ובתוכן
ככל שקבוצות הפיתוח הופכות יותר ויותר מבוזרות בתוך הארגון,
ולעתים קרובות אף מחוצה לו ומרוחקות מאד, התיאום בין הקבוצות והתקשורת ביניהן
הופך ממש קריטי. כמה מן הנושאים עליהם יש לתקשר הם:
·
מי עובד על איזה שינויים ועל איזה רכיבים?
·
מי יכול לאשר תיקון דחוף?
·
כיצד להודיע לאחרים על שינוי שיש לו השלכות על רכיבים
או על פרוייקטים אחרים?
·
כיצד להודיע לקבוצת התמיכה הטכנית (או ליוזם השינוי)
כי התיקון בוצע לבקשתם וכי הוא מועבר לקבוצת אבטחת האיכות?
תיאום תקשורת בין קבוצות ובתוך קבוצות מהווה עד 4%
מעלות הפרוייקט.
ט. קבלת דיווחים על מצב (סטטוס)
של פרוייקטים
ככל שסביבות הפיתוח הופכות יותר ויותר מורכבות, קבלת
דיווחים מדויקים ואמינים על מצב הפרוייקט הופך למשימה קשה וצורכת זמן.
קבלת דיווחים על מצב (סטטוס) של פרוייקטים מהווה עד 3%
מעלות הפרוייקט.
י. מעקב תקלות ותיקונן
בפעילות זו מעורבים בדרך כלל לא רק המפתחים, אלא גם קבוצת
הבדיקה, המנתחים וקבוצת התמיכה. על כל אלה לעקוב אחר תקלות ובקשות לשינויים,
ולקבוע את מצבן וזמינותן. ככל שמספר השינויים גדל, הופכת משימה זו לכבדה
ביותר.
מעקב תקלות ותיקונן מהווה עד 2% מעלות הפרוייקט.
המרת עלויות נסתרות
לרווח
להלן פירוט עלויות לגבי הפעילויות המפורטות לעיל, עם
עלות מטרה הנגזרת משימוש בכלי ניהול תצורה מתקדמים ועדכניים בסביבת שרת/לקוח.
יש לציין כי רבות מפעילויות אלה יוצרות עלויות נלוות של תקורה אדמיניסטרטיבית.
השימוש בכלי ניהול תצורה מוכלל ואוטומטי מצמצם דרסטית עלויות אלה ואף מסלקן
כליל. מחקרים מוכיחים כי שימוש בכלי ניהול תצורה מתקדם עשוי לחסוך 30% ויותר
מתקציבי האחזקה השנתיים, וקצת פחות מזה לגבי תקציבי הפיתוח עצמו.
מעבר להשלכות הכספיות, נשאלת השאלה: מהי התוצאה של ניהול
פעילויות התצורה היומיומיות בצורה בלתי מספקת? בארגונים רבים, הפיתוח יכול
כמעט להיעצר כתוצאה מכך. תוצאה אחרת היא איכות תוכנה ירודה, איחורים לעומת
לוח הזמנים, כשלון בבדיקות פנימיות וכשלון בבדיקות קבלה. עלויות אלה עשויות
להיות גבוהות לאין שיעור מאשר העלויות של פעילויות ניהול התצורה.
מכאן נובע האינטרס הברור שיש לארגון להקטין באופן דרסטי
את ההוצאות הגבוהות הכרוכות בפעילויות ניהול התצורה היומיומיות, במטרה לשחרר
משאבים לייצור מוצרי תוכנה איכותיים. או במלים אחרות: להפוך את העלויות
הנסתרות של פעילויות ניהול התצורה לרווח !!
תוכנית תלת-שלבית
לניהול ובקרה
אנו נגדיר כאן תוכנית תלת-שלבית לשליטה על הוצאות הפיתוח.
יישום נכון ומלא של תוכנית זו יבטיח לארגון שיאמץ אותה צמצום ההוצאות הקשורות
בפעילויות ניהול תצורה ביחס של עד 30%, כפי שהראינו לעיל. תוצאה נלוית של
ישום התוכנית תהיה הקלה בלחצים ובאתגרים העסקיים המשליכים על פעילויות הפיתוח
והאחזקה של הארגון.
א.
הפנמה והבנה מעמיקה של כל עשרת פעילויות
ניהול התצורה שבהן יטפל הכלי האוטומטי
שייושם. ארגונים רבים טועים להאמין כי ניהול תצורה מתחיל ומסתיים בכלים פשוטים
של ניהול גרסאות ושמירת קוד מקור. במקרה הטוב, כלים אלה מטפלים רק באספקט
אחד או שניים של ניהול תצורה כמודגש לעיל. לפני שמחפשים כלי אוטומטי
לניהול תצורה, חשוב מאד להבין כי לניהול תצורה יש השלכות רחבות מאד על כל פעילויות
הפיתוח והאחזקה. בכדי לצמצם בעלויות הפיתוח של הארגון, יש לאתר כלי
ניהול תצורה מוכלל ומקיף שיפקח על וימכן את כל פעילויות ניהול תצורה. רוב כלי
ניהול התצורה מבצעים בצורה מעולה פונקציות של פיקוח וניהול קבצי מקור, אך רק מעטים
תומכים במעקב בעיות, בניהול תהליכים, ובשאר הנושאים המתקדמים של ניהול
תצורה.
ב.
בחירת ורכישת כלי ניהול תצורה אוטומטי, על פי חמשת הכללים
הבאים:
·
האם הכלי המוצע מטפל ביעילות בכל עשרת סוגי הפעילות המתוארים
לעיל?
·
האם מדובר בכלי גמיש, או האם הוא אוכף תהליך ניהול תצורה
קנייני?
·
האם הכלי יתמוך בכל סביבות המחשוב של הארגון (שרת/לקוח,
פלטפורמות שונות)?
·
האם הכלי הוא מודולרי, גדל עם הארגון ומאפשר הרחבות?
·
האם אפשר להתאים את הכלי בקלות לדרישות הספציפיות של
הארגון?
ג.
בניית פרוייקט לישום והטמעת כלי ניהול התצורה האוטומטי.
ארגונים רבים רוכשים ומתקינים
מוצר מדף, טוענים בו נתונים, ומאמינים כי בכך הם כבר מפיקים את המירב מניהול
תצורה נכון. למרבה הצער, רוב המוצרים הללו מסיימים את חייהם בחזרה על המדף.
הישום הנכון של כלי מסוג זה הוא ישום פרוייקטלי הדרגתי.
מחקרים מלמדים
שאחוז ניכר מעלויות ישום והטמעת כלים חדשים הם הפסדי יצור ופריון עבודה ירוד
הנובעים מחוסר הכנה מתאימה. למרות שהכלי מהווה מרכיב חשוב מאד בהצלחת ישום
ניהול התצורה, אין הוא בשום מקרה הפתרון כולו. הצלחת הישום היא מירבית כאשר
היא נבנית על יסודות איתנים הכוללים נהלים, דרישות וסטנדרטים ארגוניים. כאשר כל אלה נלקחים בחשבון, יש
סיכוי טוב להגיע להחזר מקסימלי של ההשקעה.
חישוב
החסכון היומיומי בארגון והחזר ההשקעה
תהליך פיתוח
ואחזקת תוכנה הוא שונה מארגון לארגון. הוצאות הפיתוח של הארגון תלויות במספר
גורמים סביבתיים כמו: מספר המפתחים, פיתוח גרסה חדשה או אחזקת גרסה ישנה,
סביבת מחשוב ריכוזית או סביבת שרת/לקוח ועוד. כדי להקל על חישוב ההוצאות
הנסתרות של ניהול התצורה אפשר להיעזר בגליונות אלקטרוניים מוכנים המפרטים
ומסכמים את הוצאות הפיתוח הנוכחיות. כמוכן מחשבים גליונות אלה את החסכון
המושג ואת נתוני החזר ההשקעה (Return
Of Investment = ROI) על פי ההוצאות
הנוכחיות.
להלן חישוב
לדוגמה: המדובר בפרוייקט
אחזקת תוכנה בסביבת שרת/לקוח, עם 20 מפתחים, ועם תקורת ניהול תצורה בגובה
38.6% מעלות הפרוייקט (בהתאם למה שפורט לעיל). עם משכורת חודשית ממוצעת (כולל
כל העלויות הנלוות) של 7,000 דולר לחודש, או 84,000 דולר לשנה לאדם, תקציב
המשכורות השנתי הוא של 1,680,000 דולר. מטרת ישום והטמעת כלי ניהול התצורה
המתקדם תהיה להוריד את תקורות ניהול התצורה ל - 10% מעלות הפרוייקט, כלומר
לסכום של 168,000 דולר לשנה.
יש לזכור
כי תקורות ניהול התצורה הן הוצאות שהארגון מוציא בפועל עוד
לפני הכנסת הכלי. יתרונות נלוים של הכנסת הכלי יהיו: שיפור רמת האיכות של
המוצר, עמידה בלוחות זמנים, ניצול יעיל יותר של משאבי יצור, עמידה טובה יותר
בבדיקות וכו'. שיפורים אלה יביאו לארגון הכנסה נוספת שלא נלקחה כאן בחשבון.
להלן קוים מנחים להערכת ההוצאות הראשוניות הקשורות בישום פתרון ניהול תצורה
כולל:
·
כ - 2,000 דולר עבור הדרכה / סמינרים להבנת הקונספטים
והעקרונות של פתרון ניהול תצורה כולל ואוטומטי.
·
כ - 30,000 דולר עבור רכישת הכלי עצמו (1,300
לכל רשיון ועוד 4,000 עבור שרת). המדובר בכלי אוטומטי מתקדם הנותן פתרון
כולל. יש לזכור כי כלים פשוטים וזולים יותר לא יתנו פתרון כולל ולא יאפשרו
להגיע לחסכון מירבי.
·
כ - 150,000 דולר הוצאות הטמעה. מחקרים מראים
כי ארגונים המטמיעים פתרונות בעצמם (Do-It-Yourself
Approach)
מוציאים על סעיף זה סכום גדול עד פי שלושה (!!) מארגונים המסתייעים ביועצים
מומחים לנושא ניהול תצורה. סך כל ההוצאות הראשוניות: 182,000 דולר.
הוצאות התקורה של הארגון בגין ניהול תצורה (ללא פתרון אוטומטי מתקדם) הן:
1,680,000 * 0.386 = 648,480
בשנה הראשונה: 1,680,000 * 0.386 = 648,480
בשנה השניה: 1,680,000 * 0.386 = 648,480
בשנה השלישית:
ובסך הכל
1,945,440 דולר.
הוצאות התקורה של הארגון בגין ניהול תצורה (עם פתרון כולל אוטומטי מתקדם)
הן: בשנה הראשונה: 182,000
הוצאות ראשוניות: 1,680,000
* 0.100 = 168,000
הוצאות שוטפות: 182,000 + 168,000 = 350,000
סך ההוצאות לשנה הראשונה:
בשנה השניה: 1,680,000
* 0.100 = 168,000
הוצאות שוטפות: 50,000
הוצאות חוזרות: 168,000
+ 50,000 = 218,000
סך ההוצאות לשנה השניה:
בשנה השלישית: 1,680,000
* 0.100 = 168,000
הוצאות שוטפות: 50,000
הוצאות חוזרות: 168,000
+ 50,000 = 218,000
סך ההוצאות לשנה השלישית:
סך ההוצאות לשלוש שנים:
786,000 החסכון המושג:
בשנה הראשונה:
298,480
בשנה השניה:
430,480
בשנה השלישית:
430,480
סך כל החסכון:
1,159,440
החזר
ההשקעה מושג תוך פרק זמן בסדר גודל של 12 חודש.
סיכום
פתרון ניהול תצורה מיושם כהלכה ומבוסס על כלי
ניהול תצורה אוטומטי מתקדם יכול להפחית את תקורות ניהול התצורה בארגון בשיעורים
של עד 30% בסביבות שרת/לקוח. בנוסף לכך, ניהול תצורה יעיל מקל מאד על האתגרים
והלחצים העסקיים בהם נתון הארגון.
|
|