מדריך זה בנושא ניהול תצורה (CM - Configuration Management) לצד מבוא ודברי הסבר של תורת ניהול תצורה, מכיל הנחיות מעשיות כיצד לשלב נושא מורכב וחשוב זה הן בתוצרים (עץ המערכת) והן בניהול הפרויקט (מחזור החיים). כמו כן, מדריך זה דן בכלים ממוחשבים לניהול תצורה ומפנה לגלופות רלוונטיות, מילון מונחים קצר, הפניות לספרות מקצועית וקישורים לאתרים העוסקים בנושא.
ניהול תצורת תוכנה - נת"ת (SCM- Software Configuration Management), הוא כלי הנדסי וניהולי שמטרתו לסייע הן בשליטה טכנית/הנדסית על המערכת והן בקשר עם הלקוח, במערכות ממוחשבות בכלל ובמערכות גדולות ומורכבות בפרט. הקשר עם הלקוח, אשר נקרא גם ההיבט העסקי, תקף לגבי כל סוגי המערכות, גם קטנות, מתוך ההכרה שלמערכות קטנות ישנה נטייה לגדול מהר מאד וניהול תצורה מהווה טכניקה לבקר ולתעל נטייה זו, קודם כל בהיבט העסקי-יישומי ואח"כ בהיבט הטכני.
ניהול תצורה עוסק בבקרת תהליכי הכנסת שינויים ברכיבי תוכנה, בהגדרה ושמירה על גרסאות ומהדורות תוכנה, פיתוח מקבילי ומתן מידע אמין על התוכנה בכל רגע נתון במהלך מחזור חיי המערכת.
ניהול תצורה מכיר בעובדה שמערכת ממוחשבת היא מוצר דינמי המושבח ומשתכלל כל הזמן. דווקא בשל כך, צריך לדעת לסגור את המערכת ולנהל דינמיות זו תחת בקרה הדוקה, קרי ניהול תצורה. סגירה זו פירושה, בראש ובראשונה, ניהול מהדורות. כל הגדרה (אפיון), בנייה, תפעול ותחזוקה של המערכת, תמיד נכונים למהדורה N. אך עצם ההכרזה על מהדורות איננה תרופת פלא. ניהול מהדורות חייב להתמודד עם סגירה וניהול שינויים במספר תחנות מרכזיות לאורך מחזור החיים:
· סגירת המערכת בשלב האפיון: הקפאת הדרישות (Requirements freeze).
· סגירת המערכת בשלב העיצוב והבנייה: הקפאת תצורה (Configuration Freeze).
· ניהול שינויים (Change Management) בשלב התחזוקה. בשלב זה חיוני להבחין בין תחזוקה אמיתית שחייבים לטפל בה לבין שו"ש (שינויים ושיפורים) שצריך לתעל אותם לכיוון של מהדורה חדשה (ראה קיט תפעול ותחזוקה). כיוון שאבחנה זו איננה חד-משמעית, נוצרות לעתים גם גרסאות (תת-מהדורות) למערכת. בכל מקרה, שלב התחזוקה הוא שדה הקרב מרכזי של ניהול תצורה.
ניהול תצורה חולש על שלושה רבדים עיקריים (הן מבחינת תוצרי תיעוד והן מבחינת ישויות המערכת):
· פיתוח מערכות
· תפעול ותחזוקת מערכות
· כלל ארגוני \ תשתית
התיקייה המרכזית של פרויקט יכולה להכיל סוגים רבים של מידע: מודולים של קוד מקור, קבצי תיעוד, קבצי מידע, קבצי שרטוט, דגמי מערכת (אב-טיפוס) וכו', תוך מתן מענה לסביבות מבוזרות ומחשב מרכזי ותוך מחשבה על סביבות מרובות מפתחים, גרסאות ולקוחות. ניהול מבוקר של תיקיית הפרויקט (ולמעלה במבנה הארגון: מדור, מחלקה וכו') הוא מרכיב מרכזי בניהול תצורה בכל שלושת הרבדים הנ"ל.
ראה הקיט תיעוד בכרך נושאים תומכים והקיט ניהול מונחה תוצרים בכרך ניהול.
ניהול תצורה נובע מהצורך לתת מענה לבעיות השכיחות הבאות:
· החזקת גרסאות שונות, לאותו מוצר, אצל לקוחות רבים ושונים.
· שלב הבדיקות הסתיים בהצלחה וכל הבאגים נתגלו ותוקנו. ולמרות זאת, בעת ההעברה לייצור, מתגלים באגים חדשים.
· חוסר יכולת שחזור מדויק לאחור.
· חוסר יכולת לאפשר לשני מפתחים לעבוד על אותו קובץ בו זמנית מבלי לדרוס זה עבודתו של זה.
· סגירת מערכת לצורך ביצוע בדיקות. תיאום בין צוות הפיתוח לצוות הבדיקות.
· שחרור מוצר ללקוח עם באגים שכבר תוקנו בעבר.
· השקעת זמן מיותר בעת ביצוע אינטגרציה של ישויות וחלקי מערכת.
על מנת לתת מענה לבעיות אלה, נדרש ממערך ניהול תצורה יעיל לקיים מספר תכונות בסיסיות:
· שליטה בכל תהליך השינויים שנעשים ברכיבי התוכנה.
· זיהוי חד ערכי וברור של גרסאות, קשרים, פרטי תצורה וכו'.
· ניהול גרסאות והיסטוריה לכל סוג של קובץ.
· בנייה ושחזור של כל גרסה של היישום.
· ביצוע מעקב אחרי קשרים בין רכיבי תוכנה.
· דיווח (Report) והעברת מידע שוטף בין כל הגורמים הקשורים במערכת (פיתוח, ייצור, שיווק, QA , תמיכת לקוחות וכד').
· יכולת חזרה לגרסה קודמת של המוצר תוך ביצוע השינויים הנדרשים.
ניהול תצורה הוא נושא מורכב ביותר שאין לו פתרונות קלים וגם מפת"ח אינו מתיימר להציגו כנושא פשוט וסגור. הסיבות לבעייתיות זו הן רבות וכבדות:
· חוסר ידע, הבנה ומודעות לנושא. מסיבה זו נובעים באופן ישיר חוסר מיומנות מקצועית מתאימה (חוסר בכ"א מתאים) וחוסר יכולת לתמחר נכון את הנושא ולהכלילו בתכנית העבודה של הפרויקט. בעקיפין, נובעות מסיבה מרכזית זו, חלק ניכר מהבעיות הנזכרות בהמשך.
· בעיה מרכזית נוספת היא מתי יש להתחיל בניהול תצורה? כבר בייזום? מאמצע האפיון? או אולי רק החל משלב העיצוב? בעיה נלווית לבעיית נקודת ההתחלה היא ההחלטה אילו שינויים מחייבים ניהול תצורה ואילו שינויים הם קלים ולא כדאי בגללם להפעיל את מנגנון ניהול התצורה. במילים אחרות, מהם סוג ורמת פירוט השינויים המחייבים ניהול תצורה אחרי נקודת ההתחלה.
· תכולת ניהול תצורה. אין הגדרה ברורה לרכיבים והישויות הנכללים בניהול תצורה. השימוש בטכנולוגיות וארכיטקטורות חומרה-תוכנה-תקשורת מורכבות ורבות שכבות (שרת-לקוח, רשתות ציבוריות, תחנות עבודה, מחשבים אישיים וכו') מעצים ומחריף את הבעיה.
· הצורך להגדיר סביבת עבודה מבוקרת תצורה המנהלת באופן שוטף את כל הרכיבים והישויות (האובייקטים) הכלולים בנת"ת. סביבה זו היא המקור הפורמלי, המעשי והיחיד לבניית המערכת. סביבה זו חייבת להיתמך בכלים ממוכנים לניהול תצורה. בעיה נוספת היא שחלק מכלים אלה אינו בשל והם לא תמיד משולבים בכלי הפיתוח והתחזוקה האחרים שכבר, אולי, קיימים בארגון.
אזכור בעיות אלה אינו פותר אותן, אך נותן תזכורת חשובה הן לגורם המפתח והן לגורם המפקח לפקוח עין עליהם ולנקוט בפעולות מתקנות כגון:
· הגברת המודעות והידע בתחום (קורסים והשתלמויות) תוך מעורבות מלאה של הדרג הניהולי, ציוות מומחה לנושא בפרויקטים גדולים והכללת הנושא בתמחור המערכת. הגדרת פונקצית אחראי ניהול תצורה בארגון היא פתרון מומלץ (למי שיכול).
· הגדרה ברורה של נקודת ההתחלה וסוג ופירוט השינויים שינוהלו בניהול תצורה - גם במחיר פשרות! מוטב התחלה מאוחרת (בעיצוב) שאפשר לעמוד בה, מאשר התחלה מוקדמת (באפיון) שאי אפשר לעמוד בה.
· הגדרה ברורה של תכולת ניהול תצורה: קבצים (רק פיסיים או גם לוגיים?), דוחות (כל הדוחות?), מודולים, מסכים, מסמכים וכו'.
· הגדרה חד-משמעית של ספריות ותיקיות, פרוצדורות קטלוג, זיהוי ישויות ונהלי עבודה אחרים, תוך שילובם בכלי הפיתוח. קליטת כלים ייעודיים לניהול תצורה ושילובם בסביבת העבודה והכלים הרגילים.
· בסביבות פיתוח של שרת-לקוח, בהן רמת המורכבות עלתה וקיימות מספר פלטפורמות של פיתוח וייצור מסתמן הכרח אמיתי בהטמעת כלי ניהול תצורה.
למרות כל הבעיות והקשיים הנ"ל, חשוב להדגיש את היתרונות והתועלות שבניהול תצורה:
· שיפור יכולות הפיתוח
· צמצום כמות התקלות המתגלות בגרסאות המשוחררות ללקוח
· ביצוע ניטור סטטוס התוכנה בכל רגע נתון.
· ניהול פיתוח מקבילי בין מפתחים וצוותים שונים.
· טיפול אפקטיבי בכל השינויים וההיסטוריה של כל אחד מהם ( מתי בוצע, ע"י מי, מה בוצע, למה וכו').
· ביצוע רגרסיה בין גרסאות שונות.
· בנייה נכונה יותר של המוצר
· שליטה ברורה ומוגדרת על סביבות העבודה השונות והמעבר ביניהן
· שיפור הקשר עם הלקוח (שביעות רצון לקוח)
מחקרים מראים כי ניהול נכון של נושא ניהול התצורה לאורך הפיתוח ותחזוקת המערכת מביא לחיסכון כספי ישיר הן בעלויות כ"א, הן בעלויות תשתית והן בעלויות חומרה/תוכנה ולבסוף מתבטא בקיצור זמן הפיתוח.
מדריך זה מפרט כללים מנחים אשר בכוחם לקדם את המודעות הכללית לניהול התצורה של מערכות ממוחשבות בארגון, יחד עם נוהלי עבודה וכלים מעשיים. כללים אלה תקפים הן לניהול תצורה המבוצע ידני והן לניהול תצורה ממוחשב.
ניהול תצורה פירושו:
מנקודת מבט טכנית-הנדסית, ניהול תצורה בנוי מהפונקציות הבאות:
נסביר בקצרה פונקציות אלה ונציין לידן מספר כללי אצבע.
בשלב ראשון, יש להגדיר ולזהות את פרטי התצורה ואת הישויות שיכללו בניהול תצורה, היינו את כל ה- CSCI's (Computer Software Configuration Item) שיוכנסו תחת ניהול תצורת המערכת. כל ישות כזו: מודול, רכיב, מנגנון, מסך, Component ,Package, דו"ח, טופס וכו' מקבלת סימול ברור המכיל את סוג הישות ומס' מזהה עצמאי וכך גם המערכת כמערכת סגורה.
נושא סמול ישויות – קודיפיקציה מכוסה בקיט תיעוד בכרך נושאים תומכים.
סימול זה וכן המהדורה אליה שייך הרכיב ייטבעו בישות עצמה, במסך, במודול, בדו"ח, בטופס וכו' (בראש המסך, בכותרת הדו"ח, ב- Prolog שבתחילת המודול וכו') בקשרים ובתלויות. זיהוי כוללני יותר יעשה באמצעות ניהול שטחי עבודה (workspace) וספריות. זיהוי התיעוד נעשה באמצעות ניהול מסודר של תיקי העבודה כמוסבר בקיטים של מחזור החיים. בהקשר זה של ניהול תצורת התיעוד, ראה גם הקיט תיעוד בכרך נושאים תומכים.
במערכות מורכבות הדורשות ניהול תצורה מדוקדק מקובל להוסיף לסימול הישות גם מתארים שונים (Software Configuration Attributes) כגון קוד רמה (level code) המציין באיזה שלב בבניית המערכת משתלב הרכיב (באיזו רמה של עץ המוצר הוא נמצא).
כל בנייה (אריזה) של המערכת, או חלקי מערכת, חייבת להיעשות בתהליך מסודר (רצוי ממוכן!) של קומפילציה-חיבור, עריכה-הטענה ושילוב שהוא עצמו מקבל זיהוי ברור. כל בנייה יוצרת מהדורת בסיס חדשה(baseline) והיא כוללת:
· הקפאת תצורה לוגית של המערכת
· איסוף לוגי של כל הרכיבים ומיונם לפי המתארים (קוד רמה למשל)
· איסוף פיסי של כל הרכיבים לספריות המתאימות (אינטגרציה)
· הקפאת תצורה פיסית של המערכת
· יצירת מהדורת הדגמה (אימון)
· יצירת מהדורה מלאה, או חלקית, לצורך ביצוע בדיקות או התקנה והרצה ניסיוניות
· יצירת מהדורת ייצור סופית ומלאה (העברה לייצור)
· יצירת חלקי מערכת (אופציונאלי)
· הפצה והתקנות (כולל תמיכה).
פונקציה זו מתמודדת עם ניהול תצורה שוטף של המערכת כשהיא בשלב תפעול ותחזוקה, לאחר שנבנתה. פונקציה זו כוללת שתי תת-פונקציות עיקריות:
· ניהול בעיות/תקלות (Problem/Bugs Management)
· ניהול שינויים (Change Management).
ניהול בעיות הוא התהליך של דיווח על תקלות: מי רשאי לדווח, איך מדווחים, למי מדווחים וכו'. ניהול שינויים הוא תהליך הטיפול בדרישות חדשות ושיפורים לרכיבים קיימים במערכת, כולל גם הכנסת שינויים במערכת כתוצאה מתקלות (המנוהלות בתהליך ניהול הבעיות/תקלות).
אחת הבעיות המרכזיות של ניהול תקלות ושינויים הוא שבמסלול זה מוכנסות גם דרישות לשינויים ושיפורים (שו"ש) שאינן תקלות ממש ויש צורך לסנן ולהפריד בין תקלות אמיתיות ובין שו"ש שמקומם במהדורות וגרסאות חדשות של המערכת. נושא זה מטופל בקיט תפעול ותחזוקה בכרך יסודות\מחזור חיים.
כמו כן, הבקרה מאפשרת לבצע נעילות שמטרתן למנוע עדכון מקבילי.
פונקציה זו חותכת את שלש הפונקציות הקודמות ומשמעותה היא:
· היכולת לדעת בכל רגע מה מותקן והיכן
· היכולת לשאול על מערכת X מה בדיוק מותקן שם, וכמובן לקבל תשובה אמיתית
· היכולת לבצע מעקב לאחור (Trace Back) ולאתר כל רכיב במערכת מהיכן בדיוק הגיע ומה מקורו (Traceability)
פונקציה זו תומכת בכל שלושת הפונקציות הקודמות ובפרט ביכולת לנהל שינויים ותקלות.
מימוש ניהול התצורה ההנדסי – ארבע הפונקציות הנ"ל - יהיה באחד משלושה התחומים (המקרים) הבאים (כולם או חלקם):
· בתהליך פיתוח מערכת
· בתחזוקת מערכות
· כתשתית טכנולוגית בארגון
ראה איור להלן. בפיתוח מערכות, כל ארבע הפונקציות הן בשימוש מלא. ההחלטה העיקרית שצריך לקבל היא שילוב של: הגדרת הישויות המוכלות בניהול התצורה ושלב במחזור החיים בו הוא מתחיל. גם בתחזוקה, קיימות, בעקרון, כל ארבע הפונקציות, הגם שחלק ניכר מהן (בפרט הזיהוי) מתקבל בירושה מהפיתוח. בהקמת תשתית, היינו מיסוד הנושא בארגון כהכנה לקראת מימושו בפרויקטים, תשומת הלב תהיה בעיקר בזיהוי ובסטטוס. הבנייה והבקרה יבואו עם הפרויקטים.
הטכניקות והכלים לניהול תצורה חייבים לתת מענה ברור לארבעת הפונקציות הנ"ל, בשלושת התחומים: פיתוח (לכל אורך מחזור חיי המערכת וכולל הוספת יחידות מסירה חדשות), תחזוקה (כולל בקרת שינויים וייצוב baseline) ורמת הארגון (תשתית). על כלים אוטומטים לניהול תצורה ראה סעיף כלים ממוחשבים להלן במדריך זה.
ניהול תצורה יכול לסייע רבות בהסדרת הקשר עם הלקוח (והמשתמשים) ע"י הגדרה ברורה של: מה יפותח, מתי, את מי ישרת (ואת מי לא), כמה יעלה וכו'. לצורך זה, מבוצע רישום שוטף של כל פנייה של כל משתמש (הכול נרשם), בין אם מדובר בתקלות/הפרעות בשירות ובין אם מדובר בבקשות לשינויים ושיפורים. נציג הלקוח (מומחה היישום) הוא חבר בוועדת השינויים (CCB) ושותף בכל הקשור לניתוב החלטות לגבי תקלות ושינויים, כגון:
· יבוצע במסגרת חבילת תיקונים הבאה/נוכחית,
· השינויים יכנסו לתוקף החל מהמהדורה הבאה או במוצר חדש
מומלץ גם לשתף את הלקוח בבניית תוכנית העבודה השנתית.
קשר זה עם הלקוח נקרא לעתים גם ניהול תצורה עסקי. ניהול תצורה עסקי הוא אמצעי מעולה להמחשת הכלל שאין ארוחות חינם מחד גיסא ולשיווק המערכת והדגשת החידושים והשיפורים שהוכנסו בה מאידך גיסא. הטבלה הבאה מהווה דוגמא לכלי ניהולי מרכזי להסדרת הקשר עם הלקוח.
דרישות |
מהדורה |
תושלם לתאריך |
אומדן משאבים |
101 |
2.4 |
01/06/2012 |
ימי עבודה: ..... |
211 |
2.5 |
31/10/2012 |
ימי עבודה: ..... |
112 |
3.0 |
01/08/2013 |
ימי עבודה: ..... |
|
99 |
--/--/---- |
---------- |
טבלה זו מבוססת על הכלל:
דרך טובה לנהל מהדורה מסוימת היא להגדיר במקביל מהדורות עתידיות
מהדורה 99 היא מאגר לתוכו אפשר לזרוק כל דרישה שהיא, בכל נקודת זמן, ללא כל קשר למהדורות אחרות (יש לבדוק, כמובן, שאין כפילויות). הגדרת מהדורה לביצוע פירושה פתיחת כניסה חדשה בטבלה (מהדורה 4 בדוגמא הנ"ל) והעברת חלק מהדרישות שבמהדורה 99 לכניסה החדשה (מה שלא כלול במהדורה 99, לא ידוע ואינו קיים). לשיטה זו שני יתרונות חשובים:
· הרישום השוטף של דרישות למהדורה 99 נותנת ללקוח הרגשה שיש אוזן קשבת ויד רושמת לדרישותיו.
· העברת דרישות ממהדורה 99 למהדורה לביצוע ממחישה ללקוח שכל דבר עולה זמן וכסף ומשתפת אותו בהחלטות באשר להמשך פיתוח המערכת.
טבלה זו מנוהלת תחת רכיבי 99.X בעץ (בתיק) המערכת.
הקשר המלא עם המשתמש אינו מצטמצם לרכיבי 99.X, אלא הוא באמצעות תיק המערכת כולו המגדיר את תכולת המערכת - המערכת העתידית (תיק אפיון) והמערכת הקיימת (תיק תחזוקה).
ביטוי מעשי של ניהול תצורה עסקי הוא הקפדה על מעורבות המשתמש (מומחה היישום) לאורך מחזור החיים של הפרויקט. בפרט במקומות הבאים:
· בשלב הייזום: היקף וסוג כללי- שם ומהדורה, אופק הזמן, עיגון בתוכנית העבודה השנתית.
· בשלב האפיון: הקפאת דרישות, סגירת מסמך האפיון (Baseline), דרישות עתידיות, שיתוף בהחלטה על שיטת פיתוח הפרויקט ושחרור מוצרים, חתימת חוזה ואמנת שירות.
· בשלב עיצוב ובנייה: הקפאת תצורה, סבבי פיתוח, יחידות מסירה, הכנסת שינויים במהלך הפיתוח, שחרור גרסאות תוך כדי תהליך.
· בשלב בדיקות מערכת: תוצאות ודוחות סבבי בדיקות (סטטוס), ביצוע פיילוט ובדיקות קבלה, הוספת רעיונות חדשים ייכנסו לסעיפי 99.
· בשלב הטמעה ותחזוקה: יד ביד לאורך ההטמעה, ביצוע הדרכות, הלקוח יהיה שותף לקביעת המהדורה בייצור, קביעת נוהל לניהול שינויים בתחזוקה, נציג ב- CCB (היה ויש כזה), שותף מלא לאישור ביצוע השינוי ובקטלוגו.
·
כפי שציינו בעיה מרכזית בניהול תצורה היא מאיזה שלב רצוי להתחיל בו. מחד גיסא, ניהול תצורה בשלבים המוקדמים (ייזום/אפיון) עשוי להיות מאמץ עצום שאין שכרו בצדו - אין הצדקה לנהל את תצורת כל החלופות שהוצעו, נשקלו ונדחו בשלבים אלה ואת כל הטיוטות שהופקו. מאידך גיסא, ניהול תצורה בשלבים המאוחרים עשוי להיות מאוחר מדי. הפתרון המאוזן שמפת"ח מציע הוא כדלהלן:
בשלב זה בא לידי ביטוי ניהול תצורת מסמך הייזום בלבד.
עקרונית, ניהול תצורה מתחיל בשלב האפיון. ניהול תצורה בשלב האפיון פירושו:
· ניהול תצורה בסיסי של תיק האפיון עצמו כמוסבר בקיט אפיון ובגלופת תיק האפיון, בכרך יסודות (ניהול סדרות תיקי אפיון ומעקב מדוקדק מי שינה ,מתי ובאיזה רכיב).
· ההתייחסות לפיתוח ובניית המערכת במספר מהדורות, כולל אפיון במהדורות, היינו, היכולת לציין אילו רכיבים יאופיינו בשלב מאוחר יותר ולקצר באפיון.
· הקפאת גרסאות אפיון תוך כדי ביצוע שינויים במהלך פיתוח.
בסוף שלב האפיון, תיק האפיון מגדיר תצורה פונקציונאלית ברורה של המערכת.
בשלב זה בא לידי ביטוי ניהול תצורת המסמכים בלבד (בקשה להצעות, מפ"ל, מענה הספקים, חוזה התקשרות וכד').
ניהול תצורה טכני/פורמלי מתחיל משלב עיצוב ובנייה. בשלב זה חיוני שימוש בכלים ממוכנים ורישום ברור של תצורת המערכת ולהקפיד על ארבעת הפונקציות הנ"ל: זיהוי, בנייה (ניסוי הבנייה), בקרה (הגדרת המנגנון) וסטטוס. ניהול תצורה זה כולל לא רק את רכיבי המערכת עצמם (הישויות), אלא גם את התיעוד (המסמכים) התפעולי המלווה אותם (תיק עיצוב, תיקי תכנות וכו'). ניהול תצורה בשלב עיצוב ובנייה בא לידי ביטוי במספר נקודות חשובות:
· סגירת תצורה - עצם החלוקה של שלב עיצוב ובנייה לתת-שלבים, כולל בדיקות יחידה ושילוב, שבהם יש דגש חזק על ניהול תצורה.
· שילוב נושאי ניהול תצורה בתכנית העבודה לשלב זה
· ניהול שוטף של תיק העיצוב
· דרישה לתכנית לניהול תצורה (בפרויקטים גדולים)
לפירוט נוסף, ראה קיט עיצוב ובנייה בכרך יסודות\מחזור חיים.
ניהול תצורה בשלב הבדיקות פירושו:
· בדיקה שאכן המערכת נוהלה עד כאן בשיטות ניהול תצורה ברורות ונכונות (הבטחה שמה שעומד להיבדק הוא אכן המעודכן האחרון ביותר)
· בדיקה ששיטות ניהול התצורה שנוהלו עד כה יכולות להמשיך גם לשלב התחזוקה
· הקפדה שתוצאות והערות סבבי הבדיקות עצמם יתוקנו במערכת בשיטות ניהול תצורה נכונות (ששלב הבדיקות עצמו לא יפגע בניהול תצורה)
· ניהול נכון של מסמכי ה- STP, STD ו- STR
לפירוט נוסף, ראה קיט בדיקות מערכת.
הקפדה על בדיקות מוכנות והתקנה כמפורט בקיט התקנה והרצה.
ניהול תצורה בשלב התחזוקה מתבטא בשתי פעולות עיקריות:
· תיק התחזוקה עצמו נכון תמיד למהדורה/תאריך מסוימים עבור מערכת במהדורה X
· ניהול שינויים ואירועי תחזוקה תוך שמירה על כל כללי ניהול תצורה.
לפירוט נוסף, ראה קיט תחזוקה.
ניהול תצורה עוסק בבקרת תוצרים. למערכת מידע (בדומה למערכות אחרות) יש שני סוגי תוצרים עיקריים: תוצרים פיסיים ותוצרי תיעוד.
בתוצרים פיסיים הכוונה היא לכלל ישויות המערכת כפי שתוארו בפרק ניהול תצורה הנדסי. בתוצרי תיעוד הכוונה לכל המסמכים המבוקרים המלווים את פיתוח המערכת לאורך מחזור החיים ומתעדים את תכולתה ומצבה. לתוצרים אלו יש זיהוי עצמאי בדומה לכל ישות אחרת וקיים קשר ברור בינם ובין התוצר הפיסי.
עמוד השדרה של שני סוגי תוצרים אלה הוא עץ המערכת.
ניהול תצורה אינו רכיב מסוים בעץ המערכת או משהו חיצוני לו. ניהול התצורה הוא בעצם עץ המערכת כולו המהווה את התיעוד המרכזי- העוגן. הקפדה על עבודה נכונה עם עץ מערכת הנה אמצעי מרכזי בניהול התצורה, הן של התיעוד והן של רכיבי המערכת הפיסית.
תיקי המערכת נכונים תמיד למהדורה/תאריך מסוימים המצוינים בברור בראש כל דף (עצי מערכת בגרסאות קודמות הנם רשומות איכות). בתיקים יש הנחיות ברורות, ליד כל רכיב, כיצד לסמן את הישויות המוכלות בו (ראה תיק האפיון). רכיבים מסוימים, בעץ המערכת, מסייעים במיוחד ומהווים עוגנים לניהול תצורה:
· רכיב 2.3 – תיחום פנימי משמש לניהול תצורת תוכנה כוללת באמצעות חלוקה לתת-מערכות עיקריות (CSCI במונחי DOD-2167).
· רכיב 3.13 - כלי פיתוח ותחזוקה, מקבל משמעות מרבית כשניהול התצורה בארגון מבוצע בעזרת כלים אוטומטים.
· רכיב 4.5 - אינדקס תיעוד, מעיד על כל גלגולי המערכת בעבר ומה נדרש בעתיד.
· רכיב 4.6 - שירות ותחזוקה, משמש בסיס לניהול השינויים בשלב תחזוקת המערכת ודרכו יש הפניה לרכיבים האחרים, היינו, לתיק כולו. ראה רכיב זה בתיק התחזוקה.
· רכיב 4.9 – תצורות, מיועד למקרים של התקנות שונות של המערכת ופריסת ציוד הדרגתית, בפרט במערכות מבוזרות, מימוש הדרגתי (הצטיידות השלבים), אם ע"י הרחבה הדרגתית של מערכת מרכזית (הגדלת המחשב המרכזי ו/או הוספת ציוד קצה), או הרחבה של מערכת מבוזרת. מאפשר לדעת בכל רגע נתון: אילו מהדורות מותקנות, היכן ומהי תכולתן.
· רכיבים 98.X - נקודות פתוחות ו- 99.X - דרישות עתידיות, הניתנים לשתילה בכל רמה בעץ, מסייעים בניהול תצורה כמוסבר בסעיף השני לעיל.
מומלץ להכין תוכנית תצורה מלאה לפחות במקרים הבאים:
· ע"פ דרישות חוקתיות (תקן)
· פרויקט פיתוח גדול (סוג ג3)
· כשיש דרישה לניהול תצורה מלא בארגון
· כשאין כלים אוטומטים לניהול תצורה
· כאשר לארגון אין נהלי תצורה מפורטים וברורים
ראה גלופת לימוד ועבודה בלשונית תוצרים קיט זה.
כשמדברים על ניהול תצורה ברמה רוחבית (תשתית) בארגון יש לקחת בחשבון את סביבות העבודה הנהוגות בארגון ודרישותיהן הבסיסיות.
אם נסתכל על סביבת הפיתוח נדאג לדרישות מינימום, כגון:
· זיהוי וסימון הישויות המבוקרות (תוכניות מקור, קבצי EXE , אובייקטים וכו') ומתן חותמות (תאריך, כותב, סטטוס).
· ניהול שטחי וספריות עבודה
· ערוצי תקשורת- היינו Workflow.
· ניהול התיעוד – ניהול ארכיב.
אם נסתכל על ניהול תצורה בסביבת הייצור והתחזוקה, נדאג לדרישות מינימום, כגון:
· נוהל העברה לייצור
· קטלוג בספריות הייצור
· תיעוד תפעולי מסודר
· ניהול תקלות
· ניהול שינויים כולל בקרות כניסה ויציאה ויכולת חרטה
מעל כל אלה יש לקחת החלטות ברמת הארגון כולו – ניהול תצורה בארגון. הכוונה להחלטות שיש לקבל על היקף ביצוע ניהול התצורה, היינו:
· היקפי קטלוג מרכזי (כל המערכות והפרויקטים בארגון?)
· טכנולוגיה ותשתיות (חומרה/תוכנה)
· ממשקים וממסרים: פנימיים (מערכות בארגון) וחיצוניים (עם העולם החיצון)
הכוונה לעזרי CM כלל ארגוניים:
· נהלים, מתודולוגיות ושיטות עבודה
· כלים ייעודים
· שילוב עם כלי הפיתוח
· ערוצי תקשורת ארגוניים: פגישות, החלטות, סיכומי דיון וכיוב'
· איוש בסיוע טכני
· מודעות העובדים והדרכתם
חשוב מאד שניהול תצורה ייתמך וינוהל בכלים ממוחשבים ולא רק בטפסים וחשוב עוד יותר שתמיכה זו תהיה לא רק בכלים ייעודיים לניהול תצורה, אלא משולבת בכל כלי התשתית של המערכת: מערכת ההפעלה, ניהול ספריות, בסיס הנתונים, כלי הפיתוח וכו'. מחקרים מוכיחים כי ניהול תצורה יעיל המבוסס על כלים ממוכנים מתאימים, יכול להביא לירידה של לפחות 30% בתקציבי הפיתוח. לפיכך, יש לעשות כל מאמץ להיעזר בכלים ממוחשבים לניהול תצורה, כלים שהם חלק אינטגרלי מהטכנולוגיה הכוללת עליה נשענת המערכת, היינו, רכיב הטכנולוגיה בכללותו.
כלים ממוחשבים לניהול תצורה משלימים את הנהלים הקיימים בנושא ומהווים אוטומציה שלהם (לפחות חלקית). שימוש בכלים ממוחשבים מאפשר שליטה טובה יותר, פישוט וזירוז תהליכי עבודה ובהכרח מגביר את האיכות הכוללת של הפרויקט הן בשלבי הפיתוח ובעיקר בשלב התחזוקה.
בבחירת כלי לניהול תצורה עבור הארגון/פרויקט יש לבצע מהלך מסודר של:
· הגדרת דרישות מפורטות (תוך בדיקה מעמיקה בסביבת הפיתוח)
· בדיקה יסודית של יכולות הכלים
· פנייה לספקים- RFI
· ביצוע בדיקת עלות/תועלת (ROI)
· יציאה ל- RFP מסודר.
להלן רשימת קריטריונים כלליים לבחירת כלי לניהול תצורה:
· עמידה ברשימת התכונות הספציפיות שלהלן.
· עבודה על הפלטפורמות השונות המשמשות לפיתוח מערכות בארגון ותחזוקתן.
· גמישות וקלות ביישום ושימוש.
· מכיל מחולל דוחות גמיש ודוחות קבועים למתן סטטוס ואחזור נתונים.
· שיווק והפצה ע"י חברה רצינית המספקת תמיכה והטמעה.
בכל מקרה, כלים לניהול תצורה צריכים לקיים, לפחות, את הדרישות הבאות:
· הגדרה ברורה של הרכיבים (ישויות) הנכללים בניהול תצורה (ואלו שאינם!): תוכנה, חומרה, סביבה.
· שיטת זיהוי ברורה לרכיבים הנכללים בניהול תצורה.
· הגדרה ברורה של השלב במחזור החיים ממנו מתחיל לפעול ניהול תצורה.
· יכולת בניית מהדורה (איסוף).
· בקרה כוללת: אילו מהדורות מותקנות היכן (חשוב ביותר למערכות מידע מבוזרות).
· ניהול בעיות.
· ניהול שינויים.
· יכולת לנהל מספר מהדורות שונות במקביל.
· תמיכה בריבוי משתמשים (מפתחים, מתכנתים, מנתחי מערכות).
· שילוב מרבי בתהליך הפיתוח השוטף של המערכת (מחזור החיים, כלי CASE).
· שילוב מרבי במערכת ההפעלה (ארגון קבצים, ספריות).
התכונות הספציפיות הנדרשות מכלי לניהול תצורה, הן:
· מוודא שהמפתח עובד עם גרסת התוכנה האחרונה.
· מוודא ששינויים לא נדרסים.
· מאפשר ניהול קוד במקום אחד בלבד.
· מאפשר לדעת אילו רכיבים השתנו.
· מאפשר לדעת מי ביצע את השינוי ומי אישר אותו.
· מתעד מדוע בוצע השינוי.
· שומר היסטוריה אודות השינויים כולל כל הפרטים על השינוי.
· השוואה בין גרסאות.
· יכולת לחזור לגרסאות קודמות ולגלגל שינויים לאחור (Rollback)
· מנהל את כל היישום כיחידה אחת.
· נותן אפשרות לניהול מחזור החיים כולל כניסת משתמש לשלב הרצוי.
· מנהל העברה והגירה של שינויים מסביבה X לסביבה Y.
· ניהול התלויות והקשרים בין רכיבים , יישומים ומארזים.
· ניהול רשימת רכיבים קשורים בתהליך מסוים (ואלו שאינם) לצורך קביעת השפעת השינוי טרם ביצועו.
· אמור לאפשר הגדרת תהליך העבודה הרצוי לניהול תצורה בהתאם לסביבת העבודה.
· מאפשר להתייחס לכל רכיב בנפרד מבחינת ניהול גרסאות ושינויים.
· מאפשר תמיכה ובקרה בפעולות פיתוח מקביליות.
· רשימת שינויים נדרשת.
· סטטוס השינויים.
· נתונים על משימה וצפי סיום הפעילות.
· קשר בין מודול זה לבין לניהול השינויים בתוכנה.
כמובן שבחירת כלי לניהול תצורה, נכונה ככל שתהיה, אינה גוררת הצלחה אוטומטית מאחר ויישום כלי ממוחשב דורש משמעת, נהלי עבודה, משאבים והטמעה מקצועית על מנת לשלבו בצורה חלקה בתהליך הפיתוח ועבודת הצוותים וללא פגיעה בישויות המערכת הקיימות.
בשוק קיים מגוון רחב של כלים לניהול תצורה הנחלקים לשני סוגים עיקריים בהתאם לשפות ולסביבות הפיתוח:
· באוריינטציה לניהול גרסאות, שינויים ותצורה.
· באוריינטציה לניהול תהליכי פיתוח.
קיימים כ- 50 ספקים עיקריים של תוכנות לניהול תצורה. שבעה מהם מהווים 85% מהשוק.
התוכנות הנפוצות בארץ (לפי סדר אלפבתי) הם:
· CCC/Harvest
· ClearCase
· Continuus
· Endevor
· PVCS Dimensions
· StarTeam
· Visual SourceSafe
שאלה מרכזית העולה בהקשר עם כלי לניהול תצורה היא החזר ההשקעה (Return Of Investment): כמה זה יעלה לנו?, האם אי פעם ההשקעה הזו תחזיר עצמה? וכו'. קשה לתת תשובה או נוסחה מדויקת לשאלה זו. להלן מספר נקודות עזר שעשויות לסייע בהחלטה כמה להשקיע בכלים לניהול תצורה אל מול התועלת הצפויה.
את התועלת בשימוש בכלי ממוחשב לניהול תצורה ניתן למדוד על פי הנקודות הבאות:
· חסכון בזמני שחרור גרסה
· מוצר יציב: Baseline מסודר עם כמה שפחות טלאים (Patches)
· הפחתת כמות הפעמים שיש צורך בביצוע חזרה לאחור
· חסכון בזמן פיתוח כתוצאה מהתייעלות עבודת הצוותים. למשל, אפשרות לבצע פיתוח מקבילי מבלי להרוס קבצי מקור
· מתן האפשרות להיות גמיש יותר ללקוח מבחינת תכולת והתקנות המוצרים
במקרים מסוימים החישוב קשה לביצוע עד בלתי אפשרי, כגון:
· פרויקט בעל לו"ז צפוף במיוחד הנמצא בשלבי סיום או בכל נקודה על הנתיב הקריטי
· כשיש מעצורים שיווקיים אל מול הלקוח (התחייבות לשחרור גרסה במועד קרוב)
· כששיטת הפיתוח בארגון אינה ברורה וישימה
· כשאין לארגון אפשרות/יכולת לבצע מדידות (שעות עבודה) או לחשב עלויות השקעה.
ניהול תצורה הוא חלק אינטגרלי מנושא אבטחת איכות לפרויקטים וכך הוא גם בא לידי ביטוי בעץ המערכת של מפת"ח.
ניהול התצורה מתבטא בשלשה נושאים עיקריים בניהול פרויקט:
· שלב האפיון – סגירת דרישות לקוח.
· שלב העיצוב והבנייה - קביעת תצורה ומעקב אחר שינויי פיתוח
· שלב התחזוקה – ניהול תצורה וניהול שינויים.
נוהל מפת"ח מתייחס לנושא ניהול תצורה לכל אורך מחזור החיים של מערכת בפיתוח –הן מבחינת ישויות המערכת והן מבחינת התיעוד המלווה אותה (הגדרת פורמט אחיד למסמכים, תיאור מפורט של רכיבי התוכנה וניהול גרסאות מסמכי מחזור החיים). כמו כן, מפת"ח מטפל באופן מפורט בכל הקשור לניהול תחזוקת מערכת (כולל ניהול שינויים ותקלות והתיעוד המלווה אותם) במסגרת קיט תפעול ותחזוקה.
מומלץ, כי הגוף האחראי על אבטחת האיכות בארגון יהווה חלק בלתי נפרד מתהליך ניהול ה- CM בארגון. הראייה הכוללת והרוחבית של אבטחת איכות חיונית בכל הקשור להטמעת שיטה וכלים אוטומטים לניהול תצורה.
על הגוף האחראי על אבטחת האיכות בארגון להוות חלק אינטגרלי מפרויקטים של בחירת כלי ממוחשב לניהול תצורה והטמעתו תוך דגש על הנקודות הבאות:
1. כלים ממוחשבים לניהול תצורה מהווים בעצם הפעלתם אבטחת איכות לתחום בהם הם מופעלים.
2. ראייה מאוזנת וכוללת:
· בין צרכים פונקציונליים של המשתמש לבין קשיים טכניים.
· בין הפרויקט לכלל הארגון
· בין סביבות עבודה שונות ומגוונות בארגון
3. הטמעת כלים ממוחשבים מלווה בנהלי עבודה חדשים ובשינוי והתאמה של נהלים קיימים הנוגעים בתחומי פעילות הכלי. פעילויות אלה הנן באחריות אבטחת איכות ולכן שילובה בפרויקטים אלה יגביר את יכולת ביצוע פעילויות אלו בצורה נכונה, מהירה ואיכותית.
· ת"י ISO 9001-2000 (מדריך ISO 9000_3) – ראה קיט תקן ISO9000 בכרך איכות וקיט תקינה ותקנים בכרך נושאים תומכים
· MIL STD 498, DOD STD – 2167 A
· קיט שיטת CMMI בכרך איכות