מודל מפת"ח

עץ מערכת

רעיון מרכזי במתודולוגיית מפת"ח הוא הנדסת תוכנה בגישת עץ מוצר. רעיון זה קובע שניתן לפרק מערכות מידע ותשתית בדומה לכל מוצר הנדסי אחר - לרכיבים ותת-רכיבים ברורים ומוגדרים אשר כל אחד לחוד הוא תנאי הכרחי וכולם יחד הם תנאי מספיק לפעולתה התקינה. בזיהוי הרכיבים ובהגדרתם המדויקת יש למערכת IT, כמו לכל מוצר אחר, ייחודיות משלה. ייחודיות זו היא אשר מבדילה למעשה בין מוצר למוצר ומאפיינת אותם. ברם, הרעיון ההנדסי הבסיסי של עץ מוצר, תקף למערכות ממוחשבות כמו לגבי כל מוצר אחר.

רכיבים ראשיים

הרכיבים הראשיים של עץ מערכת ממוחשבת, כפי שהם מוגדרים במתודולוגיית מפת"ח, מופיעים באיור הבא.

נסביר רכיבים ראשיים אלה בקצרה:

יעדים

המערכת צריכה לשרת יעדים ברורים הרלוונטיים לתפקודו התקין של הארגון. ללא יעדים ברורים ומעשיים, בכל נקודת זמן, אין הצדקה לשום מערכת. יעדים מוגדרים כאן במובן רחב הכולל גם את מבנה הארגון עבורו מיועדת המערכת, בעיות שהמערכת באה לפתור, אופק הזמן לפעילות המערכת, קשר לתכנית העבודה השנתית ולתכנית אב (תכנון אסטרטגי), ישימות, עלות/תועלת וכו'.

 

יישום (מהות)

הגדרה פונקציונאלית של המערכת, מה מיועדת המערכת לבצע. במילים אחרות, אילו תת-מערכות, תהליכים, מסכים, טרנזקציות, קבצים, פריטי מידע, דו"חות וכו' מוכלים במערכת. יישום הוא תרגום מאנגלית של המונח Application ולא המונח Implementation (זה האחרון הוא שלב במחזור החיים כמוסבר להלן). משתמש המערכת רואה את המערכת בעיקר "דרך" רכיב היישום. המסכים והדו"חות שהוא רואה, הטרנזקציות שהוא מפעיל וישויות המידע המקופלות בהם - הם עבורו המערכת.

טכנולוגיה (ותשתית)

טכנולוגית המחשוב הזמינה והמקובלת בשוק (בנקודת הזמן הרלוונטית). הכוונה לא רק לחומרה, תקשורת וכיו"ב, אלא גם לתוכנות תשתית כגון: מערכת הפעלה, שפות מחשב, מוניטור ייצור, ניהול ספריות, בסיס נתונים, מחולל יישומים, Middleware וכו'. טכנולוגיה היא אוסף כל רכיבי המדף בעזרתם ימומש היישום. "רכיב מדף" הוא כל פריט אשר ניתן לרוכשו מספק חיצוני המספק גם שירותי התקנה, הדרכה, שירות ותחזוקה לאותו פריט וכו'.

מימוש

מימוש הוא ה"דבק" המחבר את שאר הרכיבים, בעיקר את היישום והטכנולוגיה, לפתרון מעשי ומתפקד, הן בשלבי הפיתוח והן בשלבי התפעול והתחזוקה של המערכת. מימוש משמעו תכניות עבודה, גורמים המעורבים בפיתוח המערכת ותחזוקתה, תיעוד תפעולי (כולל מדריך למשתמש), חוזי שירות ותחזוקה, תוכנית לבדיקת המערכת, הדרכות והטמעת המערכת ועוד. מימוש כולל גם רכיבים לא-פונקציונאליים שהם תכונות של שאר הרכיבים (ושל המערכת בכללותה), כגון אמינות ואבטחת איכות. מימוש מוגדר באופן העונה לכל האפשרויות: פיתוח עצמי, הסתייעות בגורם חיצוני, רכישת חבילות תוכנה ועוד.

עלות

בתפיסת מפת"ח, עלות (הערכת המשאבים של) המערכת אינה רק עניין כלכלי "חיצוני", אלא חלק בלתי נפרד מעץ המערכת. עלות המערכת, עלות ההקמה והעלות השוטפת, מעוגנת עמוק בעצם הגדרת המערכת ומהותה. סדר הגודל של עלות המערכת הוא מדד מרכזי ביותר להערכת מורכבות המערכת והפרויקט. עלות קשורה גם עם ניהול סיכונים, ניתוח חלופות, עמידה בתקני איכות וכמובן במדד המדדים: עלות\תועלת המערכת. עלות מוגדרת כסך כל ההוצאות על המערכת לתקופה של 5 שנים כולל תחזוקה והוצאות שוטפות לתקופה זו ו2-3 סבבי פיתוח (מהדורות) נוספים. יש להביא את סך כל ההוצאות לבסיס משותף של שערוך לפי ערך קניה נוכחי או לפי הוצאה חודשית שוטפת.

רכיבים משניים

בפירוק לרמה השנייה נראה עץ המערכת כך:

1. יעדים

1.0 כללי - הבהקים

1.1 לקוח/מומחה יישום

1.2 יעדים ומטרות

1.3 בעיות

1.4 הקשר ארגוני/עסקי

1.5 תכנית עבודה שנתית

1.6 ישימות ועלות/תועלת

1.7 אופק הזמן

2. יישום - מהות המערכת

2.0 ארכיטקטורה כללית יישום - הבהקים

2.1 מאפיינים כלליים 

2.2 תיחום חיצוני

2.3 תיחום פנימי 

2.4 ממשק משתמש

2.5 תהליכים

2.6 טרנזקציות (פעולות)

2.7 מודולים (תכניות)

2.8 מהלכים (פרוצדורות בקרה)

2.9 שגרות (אובייקטים משותפים)

2.10 טבלאות קודים

2.11 קבצים לוגיים – מודל הנתונים

2.12 קבצים פיסיים – Data Base

2.13 מילון פריטי-מידע (שדות)

2.15 דו"חות (ושאילתות)

2.16 קלטים (טפסים)

2.19 אבטחת מידע

2.20 הצלבות וחיתוכים

2.21 נפחים עומסים וביצועים

2.22 ממשקים וקישורים

2.23 דרישות מיוחדות

3. טכנולוגיה ותשתית

3.0 ארכיטקטורה כללית טכנולוגיה - הבהקים

3.1 חומרה מרכזית

3.2 אחסנת נתונים מרכזית

3.3 ציוד קצה

3.4 ציוד מיוחד

3.5 ציוד מתכלה

3.9 תשתית סביבתית

3.10 מערכת הפעלה

3.11 בסיס נתונים - DBMS

3.13 כלי פיתוח ותחזוקה

3.14 תוכנות מדף

3.15 כלי תפעול וייצור

3.20 מחשב לקוח - חומרה

3.21 מחשב לקוח - תוכנות תשתית

3.22 מחשב לקוח - תוכנות יישומיות

3.30 תקשורת פרטית מקומית

3.31 תקשורת פרטית רחבה

3.32 רשת ציבורית

3.33 טכנולוגיות משיקות

4. מימוש

4.0 מימוש כללי - הבהקים

4.1 גורמים מעורבים

4.2 תכנית עבודה

4.3 השלב הבא /המיידי

4.4 תפעול שוטף

4.5 אינדקס תיעוד

4.6 שירות ותחזוקה

4.7 השתלבות בארגון – הנעת המערכת

4.8 חוסן ואמינות

4.9 תצורות

5. עלות - משאבים

5.0 תמצית העלויות - הבהקים

5.1 עלות הקמה (פיתוח והתקנה)

5.2 עלות שוטפת

5.3 עלות לפי תצורות

5.4 מחירון

5.5 עלות כוללת ופריסה

 

מספור הרכיבים הוא לעתים ב"קפיצות" (עם "חורים"), בשל הצורך לשמור על זיהוי קבוע של הרכיבים ומתן האפשרות להוסיף "רכיבי משתמש" (user components) בלי להסיט את הרכיבים הג'נריים והקבועים של עץ המערכת. להסבר נוסף, ראה הקיט עץ מערכת אוניברסלי בכרך יסודות\עץ המערכת.

רמה שנייה זו של עץ המערכת נקראת גם הסרגל הראשי של מפת"ח. סרגל זה מתאים לכל מערכות המידע והתשתית בתחום המחשוב (IT) - מערכות מסוגים שונים ובהיקפים שונים, בין אם הן נבנות "בבית", בין ע"י גורם חיצוני (מיקור חוץ). רמה שנייה זו היא כמובן פשטנית וכללית למדי, תיאור מלא ופורמלי של עץ המערכת נמצא כאמור בקיט עץ מערכת אוניברסלי.

הסבר נוסף

הגדרה זו של עץ המערכת יסודה בראיית המערכת בפעולה - המערכת המותקנת - כיעד העיקרי אליו שואפים. ההסתכלות היא מ"הסוף להתחלה" ונקודת המבחן היא אילו רכיבים נחוצים כדי שהמערכת תפעל כיאות. מחד גיסא, ראייה זו מוציאה מעץ המערכת אלמנטים רבים שמקומם במקום אחר (כגון פעילויות ותהליכי הפיתוח שמקומם במחזור החיים כמוסבר בהמשך) ומפשטת את הסרגל. מאידך גיסא, נוספים לעץ המערכת רכיבים חיוניים, כגון יעדים ועלות (וחלק מהמימוש), שבלעדיהם אין אפשרות (או טעם) בקיום המערכת.

ברור שעץ המערכת המוצג בנוהל הוא מודל כללי, בעזרתו צריך כל פרויקט לבנות את עץ המערכת הפרטי שלו ולמלאו תוכן. "מילוי תוכן" זה הוא למעשה הפיתוח והתחזוקה של מערכת מסוימת. הקשר בין עץ המערכת הכללי ועץ מערכת פרטי והמעבר מהאחד לשני, כולל האופן בו מפת"ח מסייע למעבר זה, מוסברים בקיט עץ מערכת אוניברסלי, בקיטים המוקדשים למחזור החיים, בקיטים של עצי מערכת ספציפיים ובגלופות הלימוד (למעשה, כל מפת"ח עוסק במעבר זה, בצורה זו או אחרת).

לעץ המערכת יש היבטים תיאורטיים-פנימיים מורכבים כגון:

 ·         יחסי גומלין, קשרים ותלויות בין רכיבים (בין יישום לטכנולוגיה, למשל).

 ·         מאפיינים של רכיבים (המדיום בו "נמצא" הרכיב, למשל).

 ·         הקשר בין רכיבים לא-פונקציונאליים (אורתוגונליים, או "מסדר שני") לרכיבים פונקציונאליים. רכיבים לא-פונקציונאליים (אמינות, למשל) הם רכיבים המסכמים תכונה מסוימת של רכיבים פונקציונאליים (קבצים, למשל) או של עץ המערכת כולו.

 

לעץ המערכת יש השלכות מעשיות חשובות ביותר על נושאים מרכזיים של הנדסת תוכנה וניהול פרויקט תוכנה, כגון:

 ·         יכולת להבחין בין היקפי (גדלי) מערכת שונים - אילו רכיבים מינימאליים נחוצים במערכות קטנות, למשל,

 ·         ניתוח בעיות - אילו רכיבים גורמים לבעיות או עונים על בעיות,

 ·         סקר סיכונים - אילו רכיבים חשופים לסיכונים או חושפים את המערכת לסיכונים,

 ·         ניהול תצורה - אילו רכיבים השתנו

 ·         אמידת עלויות - הערכה לפי רכיבים, בקרת חריגות לפי רכיבים,

 ·         ניתוח חלופות - רכיבים חליפיים, חלופות לרכיבים

 ·         תחזוקה ופיתוח בסבבים – אילו רכיבים זקוקים לתיקונים ושיפורים,

 ·         חקר ישימות - רכיבי CSF,

 ·         בדיקות מערכת ושיקופים - מה מצבו של כל רכיב

 ·        ועוד.

 

להיבטים תיאורטיים אלה ולהשלכותיהם המעשיות יש התייחסות מפורטת וברורה לאורך כל מפת"ח. הקיט עץ מערכת אוניברסלי מרחיב ומעמיק בנושא. הרחבות נוספות נמצאות בגלופות הלימוד שבקיטים בכרך מחזור חיים. בכרך התמחויות, תת-הכרכים מערכות מידע ומערכות תשתית, מוצגים עצי מערכת ספציפיים וייחודים. למעשה, כל מפת"ח דן, באופן זה או אחר, בסוגים והרחבות שונים של עץ המערכת.

עם זאת, המשמעות הבסיסית והמרכזית של רעיון עץ המערכת היא כפולה ופשוטה:

עבור מערכת ספציפית:

 

ועבור הארגון:

מחזור חיים

מחזור חיים (system life cycle) הוא תהליך הפיתוח והתחזוקה של מערכת ממוחשבת המחולק לשלבים. שלבים אלה מגדירים במפורט אילו "תחנות" צריכה המערכת לעבור בדרך פיתוחה ובנייתה, כולל נקודות בקרה ומעקב, אבני דרך, אבטחת איכות, בקרה חוזית וכספית וכו'. ובעיקר, בקרת תוצרים! מה הופק נכון לסיום השלב? האם קבלנו את התוצרים המצופים?

מחזור חיים הוא כלי הנדסי וניהולי מרכזי המאפשר שליטה ובקרה על הפרויקט. גם אם לפעמים יש נטייה להתעלם ממחזור החיים בטענות מטענות שונות ("עבודה עם מחזור חיים פורמלי ומלא מסורבלת ומאריכה את הפרויקט", "בשיטת הפיתוח הדינמית בה אנו עובדים אין צורך במחזור חיים", "מדובר בפרויקט חדשי המתבסס על חבילת תוכנה קיימת" וכו'), אין בסופו של דבר מנוס ממחזור חיים מסודר, בפרט אם מעורבים בפרויקט גורמים שונים.

שלבים ראשיים

השלבים הראשיים במחזור חיים המוגדר במפת"ח הם:

 

 ·         ייזום

 ·         אפיון

 ·         בקשה להצעות (מכרז)

 ·         עיצוב ובנייה

 ·         בדיקות מערכת (טסטים)

 ·         התקנה והרצה

 ·         תחזוקה ותפעול (לעתים קרובות נפריד ביניהם)

 ·         תחקור והערכת מערכות קיימות

 

ייזום

ייזום הוא שלב ראשוני בו מועלית דרישה למערכת ממוחשבת חדשה, או למהדורה חדשה של מערכת קיימת. מטבעו, זהו שלב ראשוני (היולי) בו המידע לגבי סוג המערכת הנדרשת, אופייה וטיבה, הוא מעורפל. למרות זאת, נדרשת התייחסות מובנית לשלב זה ויש לתעד את כל המידע הידוע במסמך מסודר - מסמך ייזום - הוא התוצר הראשי של שלב זה. מסמך הייזום בנוי כבר בהתאם לעץ המערכת (עץ חלקי!). הניסיון מוכיח, שבידי היזם יש בד"כ מידע רב והכנסתו למסגרת עץ המערכת כבר בשלב הייזום היא פעולה רבת-ערך, המדריכה את היזם לתרגם את חשיבתו היצירתית למונחים מעשיים. בארגון מסודר, ייזום נובע, בד"כ, מתכנית העבודה השנתית.

 

אפיון

אפיון הוא שלב מרכזי בתחילת מחזור החיים של הפרויקט בו מוגדרות הדרישות מהמערכת. מאמץ רב מוקדש, בשלב זה, להגדרת מהות המערכת הנדרשת (רכיב היישום). כל שאר רכיבי המערכת והפעילויות הכרוכות בהקמתה, נובעים מהגדרה זו. כל דיון רציני בטכנולוגיה הדרושה, בביזור מול ריכוז, בעלות המערכת ובישימותה וכו', יכול להיערך רק לאחר ביצוע שלב האפיון. גם פנייה מסודרת לקבלת הצעות (השלב הבא) לא תיתכן בלי מסמך אפיון. מסמך אפיון הוא בד"כ במבנה כמעט מלא של עץ המערכת.

בקשה להצעות

היעד המרכזי של שלב בקשה להצעות (RFP) הוא התקשרות עם ספקים במטרה לרכוש מהם, או לבצע באמצעותם, חלקים משמעותיים של המערכת. בבקשה להצעות (מכרז) מוגשת לספקים-מועמדים הגדרת המערכת הנדרשת במבנה של מפרט (RFP) והספקים מגישים מסמך תשובה למפרט (מענה הספק). המפרט הוא המשך ישיר ופשוט של מסמך האפיון. מענה הספק הוא במבנה של אחד לאחד מול המפרט. שני המסמכים העיקריים של שלב הבקשה להצעות - המפרט ומענה הספק (ומסמך האפיון שקודם להם)  - הם במבנה עץ המערכת. מסמך חשוב נוסף, במבנה מיוחד, הוא מפ"ל (מסמך פנימי לבדיקה), אשר מגדיר את שיטת בדיקת ההצעות והשוואתן.

בפרויקטים המבוצעים באופן פנימי בארגון, בהם אין פנייה לספקים, יש לבצע ניתוח חלופות וחקר-ישימות מורחב במקום שלב זה.

עיצוב ובנייה

בשלב זה מעוצבת המערכת באופן סופי, נבנית ועוברת ניסויים ראשוניים. המסמך העיקרי המלווה שלב זה הוא תיק עיצוב אשר נבנה כהמשך ישיר של תיק האפיון ובסוף שלב זה הופך להיות תיק המערכת. בפיתוח עצמי ("בבית"), יבוצע שלב זה ע"י יחידה פנימית בארגון, זו שאפיינה את המערכת, או יחידה אחרת המתמחית בעיצוב ובנייה. בהתקשרות חיצונית, יבוצע שלב זה ע"י הקבלן (הספק) הראשי של המערכת תחת בקרה צמודה של הארגון (הלקוח). למרות מרכזיות שלב זה, גישת מפת"ח היא להשאיר יד חופשית לגורם המפתח בכל הנוגע לתהליך העיצוב והבנייה ולאפשר לו שימוש בטכניקות עיצוב ובכלים (CASE) שהוא אמון עליהם. זאת, כמובן, בתנאי שתיק המערכת מתעדכן באופן שוטף. "יד חופשית" זו, מאפשרת גם לאחד את העיצוב והבנייה לשלב אינטגרטיבי אחד, להפרידם לתת שלבים ברורים, לשלב דגמים, לפתח בסבבים וכו'. הכל בהתאם לצרכיי הפרויקט ולכלי הפיתוח העומדים לרשותו. בהמשך הנוהל מוצגים העיצוב והבנייה בד"כ כשלב אחד, אך לעתים גם כשני שלבים נפרדים. בכל מקרה, שלב זה כולל את בדיקות היחידה (Unit tests) שהן חלק בלתי נפרד מתכנות המערכת.

בדיקות מערכת (טסטים)

אימות המערכת ובדיקת תקפותה מתבצעים, למעשה, לאורך כל מחזור החיים של הפרויקט: בשיקופים ובסקרים (Reviews) השונים, בבדיקות יחידה (unit tests) בשלב העיצוב והבנייה, בבדיקות התקנה בשלב ההתקנה ועוד. עצם ההקפדה על עבודה לפי מפת"ח, הוא עצמו תרומה איכותית לאימות המערכת ובדיקתה. עם זאת, אין לוותר על בדיקות מערכת כשלב עצמאי ונפרד. שלב הבדיקות כולל שני מרכיבים עיקריים:

 

 ·         בדיקות מערכת – System testing

 ·         בדיקות קבלה – Acceptance tests

בליבה של שלב הבדיקות עומד מאגר מפרטי הבדיקות (תרחישים) המפרט את התסריטים ונתוני הבדיקה המדויקים שיש לבצע. התיעוד המרכזי של שלב הבדיקות הוא תיק הבדיקות הכולל גם את תכנית הבדיקה והנחיות ברורות לצוותים הבודקים כיצד לבצע את סבבי (ומחזורי) הבדיקות, כיצד לדווח על התקלות והפגמים שנמצאו וכיצד לסכם את הממצאים ולהציגם הן לפני הנהלת הפרויקט והן לפני הגורם המפתח שצריך לבצע את התיקונים.

 

התקנה והרצה

בשלב זה מוכנסת (מהדורה X של) המערכת לפעולה, לאחר שעברה בדיקות התקנה ואושרה העברתה לתפעול שוטף ותחזוקה. שלב זה כולל גם הדרכות, הסבות, בדיקת התיעוד התפעולי, היבטים שונים של הטמעה ואו"ש וכן הרצה של המערכת. שלב זה מושפע מאד הפיתוח בסבבים (יחידות מסירה, מהדורות) בהשוואה עם פיתוח סדרתי.

תפעול ותחזוקה

תפעול איננו רק משימה טכנית של "ייצור שוטף", על פי תיק תפעול מוכן, אלא גם מתן שירות שוטף למשתמשים ופתירת בעיות: ניהול helpdesk, "עזרה ראשונה" וכו'. באשר לתחזוקה, יש הבחנה ברורה בין תחזוקה שהיא תיקוני שגיאות או שינויים הכרחיים (כפויים) לבין תחזוקה שהיא "שינויים ושיפורים" (שו"ש). מפת"ח מכיל מספר כלים ומדדים שמטרתם להקל על תחזוקת המערכת ולאתר תחזוקה מסוג שו"ש שאינה אלא מהדורה חדשה של המערכת ומחייבת מעבר מחודש במחזור החיים (הוספת יחידת מסירה או מהדורה\גרסה חדשה). הכלי המרכזי של מפת"ח בשלב זה הוא תיק תחזוקה, מלווה בניהול שינויים, ניהול תצורה וטיפול מוגדר היטב באירועי התחזוקה השונים. תיק תחזוקה הוא, מחד גיסא, המשך תיק האפיון (והעיצוב) ומאידך גיסא, בסיס לתיק אפיון של המהדורה הבאה. שילוב תיק התחזוקה בכלים ממוכנים קיימים בארגון, מקל באופן ניכר על ניהול שלב התחזוקה.

תחקור - הערכת מערכת

הערכה (Software System Assessment) של מערכת קיימת, או תחקור מערכת, מטרתם כפולה: לפרויקט ולארגון (לפרויקטים אחרים). ברמת הפרויקט, מטרת התחקור היא להפיק לקחים מפיתוח המערכת והתקנתה ולבדוק אם כדאי להמשיך לתפעל ולתחזק אותה ובאיזה מחיר. מלבד תשובה פשטנית של: כן/לא, תיתכנה גם תשובות מורכבות יותר כגון: "יש צורך במהדורה חדשה אך רק בתנאים....", או "יש להפסיק את פעולת המערכת באופן הדרגתי ומסודר שמשמעותו...", "מומלץ להעביר את המערכת בהקדם לפלטפורמת חומרה\תוכנה תקניים ..." ועוד. ברמת הארגון, הערכת מערכת היא פעולת איכות מרכזית שמטרתה ללמוד ולהפיק לקחים מהפרויקט הנדון, לטוב ולרע, עבור כל הארגון ופרויקטים אחרים.

חלוקה משנית

שמונה שלבים ראשיים אלה הם היסודות מהן יבנה כל פרויקט את מחזור החיים ושיטת ניהול הפרויקט המתאימים לו. ככלל, מעבר מלא בשמונה שלבים אלה הוא עבור פרויקטים גדולים (במפת"ח יש הבחנה בין שלשה גדלי פרויקטים, כמוסבר בהמשך, הבחנה שיש לה השלכות הן על עץ המערכת והן על מחזור החיים). עבור פרויקטים קטנים ובינוניים מגדיר מפת"ח מחזור חיים זריז ומקוצר - אין צורך ואין צידוק לקיצורי דרך מאולתרים!

ההקפדה במפת"ח היא על שמונה שלבי יסוד אלה ועל השימוש העקבי בשמותם. אין להמציא שמות חדשים! לדוגמא: אין במפת"ח שלב כמו "צורך כללי במערכת" או "קונספט" - יש שלב ייזום. אין "הגדרת דרישות" - יש שלב אפיון. "ניתוח מצב קיים" הוא חלק משלב האפיון, "בדיקות קבלה" הם חלק משלב הבדיקות, "חקר ישימות" אינו שלב עצמאי אלא פעילות המבוצעת בנקודות ברורות במחזור החיים וכו'.

לחלק משלבי היסוד שפורטו בסעיף הקודם מוגדרים תת-שלבים ברורים ומחייבים, למשל, שלב בקשה להצעות נחלק לארבעה תת-שלבים ברורים:

 

 ·         תת-שלב א: כל הפעילויות עד הוצאת מפרט לספקים (וכתיבת מפ"ל)

 ·         תת-שלב ב: הכנת ההצעות ע"י ספקים פוטנציאליים (מועמדים)

 ·         תת-שלב ג: מקבלת ההצעות ועד סיכום וקבלת החלטה

 ·         תת-שלב ד: התקשרות עם הספק שהצעתו התקבלה, הגדרת SOW וחתימת חוזה.

 

שלבים ותת-שלבים מחולקים לפעילויות. אוסף כל הפעילויות של שלב (או תת-שלב) במבנה מסודר ובהערכת לוחות זמנים ומשאבים נקרא תכנית עבודה. מפת"ח מכיל הנחיות מפורטות כיצד מומלץ לפרק את כל אחד משמונה השלבים הראשיים לתת-שלבים ולפעילויות בדידות וכיצד לבנות תכנית עבודה מפורטת לכל שלב. אך האחריות הסופית היא של מנהל הפרויקט, אשר יבנה בעזרת "חומרים" אלה את תכנית העבודה המתאימה לפרויקט שלו.

הסבר נוסף

בעצם הגדרה זו של מחזור חיים אין שום "מהפכה" והיא דומה להגדרות מקובלות בעולם כפי שמראה טבלת ההשוואה בין שלבי הפיתוח:

השלב לפי מפת"ח	השלב לפי IEEE
ייזום	Concept (Initiation)
אפיון	Analysis (Requirements)
בקשה להצעות	RFP
עיצוב	Design
בנייה	Implementation
בדיקות	Testing
התקנה והרצה	Installation
תפעול ותחזוקה	Operation & Maintenance

עם זאת, יש ייחודיות בגישה של מפת"ח למחזור החיים. ייחודיות זו מתבטאת בנקודות הבאות:

 

א.       כיסוי מלא של מחזור החיים כולו, כולל שלבים מאוחרים כבדיקות ותחזוקה והנחיות ברורות כיצד לבצעם. גם שלב בקשה להצעות (מכרז), שבשיטות אחרות כלל לא קיים או מתועד בנוהל נפרד, הוא במפת"ח חלק בלתי נפרד מהמתודולוגיה ומפורט באופן מלא. מיקומו של שלב בקשה להצעות במחזור החיים מוגדר בברור: לאחר שלב האפיון ולפני שלב עיצוב ובנייה.

ב.       מחזור החיים מוגדר בכפיפות לעץ המערכת ונגזר ממנו (נושא זה מוסבר בסעיף הסמוך). כל שלב חייב לתרום לקידום עץ המערכת. זהו "מבחן התוצאה" המרכזי של מחזור החיים: כיצד הוא מקדם את עץ המערכת שהוא אחד ומשותף לכל השלבים.

ג.        מחזור החיים שהוצג לעיל הוא מחזור החיים הבסיסי - הוא היסודות. בפועל, מכיר מפת"ח במגוון מחזורי חיים, כפונקציה של סוג הפרויקט, היקפו, אופק הזמן ומגוון שיקולים טכנולוגיים, ארגוניים ועסקיים. מחזורי החיים שמפת"ח מכיר הם:

             ·         פיתוח סדרתי. בשיטה זו מתנהל הפיתוח, פחות או יותר, לפי השלבים שהוצגו: ייזום, אפיון, [בקשה להצעות], עיצוב ובנייה וכו'. גם בשיטה זו יש חופש פעולה נרחב למנהל הפרויקט באשר לפירוט פעילויות המפורטות ותכניות העבודה של השלבים השונים, שילוב דגמים ואבטיפוס וכו'.

             ·         פיתוח בסבבים או יחידות מסירה. בשיטה זו מתחיל הפיתוח על בסיס ייזום ואפיון-על (ולאחריהם בקשה להצעות) ובהמשך פיתוח בסבבים וביחידות מסירה. שיטות אלה של  מחזורי חיים דינמיים נשענות על כלים מודרניים המסייעים בבניית אבטיפוסים (דגמים) לסוגיהם, בסיסי נתונים גמישים וקשר נכון עם הלקוח שרוצה ומוכן לקבל פתרון בשלבים.

             ·         מקרים מיוחדים: מקרים בהם יש מחזורי חיים מיוחדים הם: מערכות קטנות במיוחד, מערכות גדולות במיוחד, מערכות מתמחות, חבילות תוכנה ופתרונות מוכנים. בכל המקרים האלה, מאפשר מפת"ח שילוב עם מתודולוגיות וכלים ממוכנים המקובלים בשוק.

גמישות זו של מחזור החיים וההכרה במחזורי חיים שונים (יחד עם הגמישות של עץ המערכת שהוזכרה בסעיף הקודם) ממחישה היטב את התפיסה של מתודולוגיה פתוחה (נוהל-מסגרת) המייחדת את מפת"ח. נושא זה מוסבר בהרחבה סעיף האחרון במסמך זה.

ד.       היכולת "להיכנס באמצע", היינו, להחיל על כל מערכת, באופן מיידי, את השלב במחזור החיים בו היא נמצאת. נושא זה מוסבר בהרחבה בקיט זיהוי ומיקום המערכת.

מחזור חיים סדרתי

פיתוח בסבבים

 

היכן במפת"ח

שלבי מחזור החיים מתוארים כולם בכרך יסודות\מחזור חיים. כל שלב מתואר בקיט נפרד. המדריך הראשי (הנוהל) בכל קיטים אלה הוא אחיד ובנוי לפי הסעיפים הבאים:

 

 ·         כללי - מנהלה: עקרונות והסבר כללי, קלטים, משאבים, גורמים מעורבים, קבלת החלטות על המשך הפרויקט ועוד.

 ·         פעילויות - תכנית עבודה: רשימה של פעילויות עיקריות מומלצות לביצוע השלב, כולל אבני דרך, שיקופים, חלוקה לתת-שלבים והנחיות לבניית תכנית עבודה. פעילות "0", היא תמיד בניית תכנית העבודה עצמה.

 ·         תוצרים: הגדרת התוצרים (הפלטים) של השלב.

 ·         נושאים מיוחדים: נושאים מיוחדים לשלב הספציפי (במידה שיש) כגון: הנחיות מקצועיות מיוחדות, העסקת גורם חוץ וכו'.

 ·         אבטחת איכות ומדדים: כללי אבטחת איכות ומדדים לבדיקת איכות הניהול והביצוע של השלב.

 

שלבי מחזור החיים המתוארים בכרך יסודות של מפת"ח עדיין אינן ניהול הפרויקט. שלבים אלה הם אבני בנין ג'נריות – הקומה הראשונה של ניהול פרויקט. הקומה השנייה, מחזורי חיים מעשיים לפיהם מתנהל פרויקט, נמצאים בכרכים הבאים:

 

 ·         בכרך ניהול תת הכרך ניהול פרויקט, יש קיטים המכילים הנחיות ברורות כיצד לבנות תכנית עבודה לניהול פרויקט ספציפי בהתאם לסוגו ומהותו: פרויקט סדרתי, פיתוח בסבבים, פרויקט קטן במיוחד וכו'; וכיצד לנהלה ולעקוב אחרי ביצועה.

 ·         בכרך התמחויות יש קיטים הדנים במערכות מידע ותשתית ספציפיים (מתמחים). מחזור החיים המתואר שם מכיל התייחסויות ברורות למקרה הספציפי של מערכת זו או אחרת, כגון: מערכת GIS, מערכת תשתית אבטחת מידע, מערכת מחסן נתונים (Data warehouse), רשת תקשורת ועוד.

 

לסיכום, למחזור חיים יש משמעות כפולה ופשוטה:

עבור מערכת ספציפית:

 

עבור הנהלת הארגון:

מודל המטריצה - שילוב עץ מערכת ומחזור החיים

בליבה של מודל מפת"ח עומד השילוב של עץ המערכת עם מחזור החיים. שילוב זה מציג את תהליך הפיתוח והתחזוקה של מערכת ממוחשבת בראייה דו-ממדית חדשנית - גישת המטריצה. בגישה זו, משולבים עץ המערכת ומחזור החיים זה בזה באופן הדוק ביותר. האחד יוצר היטל על השני. שילוב זה נכון לא רק בשלבים המוקדמים של מחזור החיים, כמו אפיון ועיצוב, כי אם גם בשלבים המאוחרים כמו בדיקות המערכת, תפעול, תחזוקה ותחקור. בניית מערכת ממוחשבת היא תהליך של התקדמות במקביל בציר מחזור החיים ובציר עץ המערכת!

האיור הבא מציג את עץ המערכת (ציר ה- Y) ומחזור החיים (ציר ה- X) ואת השילוב ביניהם.

 

מטריצת מפת"ח

 

שים לב: התוכן באיור (פנים המטריצה) הוא דוגמא בלבד! כמו כן, שים לב שלא כל שלבי מחזור החיים מוצגים (מחוסר מקום) ושבדוגמא זו עיצוב מופיע כשלב עצמאי ונפרד (שלב הבנייה לא מופיע).

במבט אופקי (משמאל לימין) על המטריצה אפשר לראות כיצד מתפתח כל רכיב במהלך התקדמות הפרויקט. רכיב 2 - יישום בדוגמא, נמצא בשלב הייזום במצב "משוער", בשלב האפיון הוא "מוגדר חלקית" ובשלב הבנייה הוא "גמור". רכיב 4 - מימוש, כדוגמא נוספת, הוגדר סופית בשלב העיצוב, הוכרז "גמור" בשלב הבנייה, ונמצא "לא גמור" בשלב הבדיקות. המבט האופקי ממחיש את הטרנספורמציות השונות שעץ המערכת עובר במחזור החיים, אך ממחיש גם שקיים תמיד אותו מודל עץ מערכת!

במבט אנכי (לפי הטורים), אפשר לראות אילו רכיבים מוכלים במערכת בכל שלב ושלב ומה מצבם. אם נשוב ונתבונן במטריצה נראה שבשלב הייזום נמצאת המערכת במצב מאד לא מוגדר (כפי שניתן היה לצפות), לאחר האפיון מוגדרת המערכת טוב יותר, אך רק בשלב העיצוב הגיעה המערכת להגדרתה הסופית. בראייה אנכית זו אפשר לבחון את תרומתו של כל שלב לקידום המערכת. תרומה זו נמדדת במספר ובסוג הרכיבים שקודמו בשלב מסוים, לעומת השלב הקודם. שלב שבו שום רכיב לא קודם לעומת השלב הקודם, הוא שלב סרק.

גישת המטריצה ניכרת גם במבנה מפת"ח ותכניו. הכרך יסודות, מוקדש ישירות לעץ המערכת ולמחזור החיים. תת-הכרכים מערכות מידע ומערכות תשתית, בכרך התמחויות, דנים בעצי מערכת ומחזורי חיים ספציפיים למערכות ייחודיות; מה השינויים והתוספות בעץ המערכת ומחזור החיים של מערכות אלה לעומת עץ המערכת ומחזור החיים הג'נריים שהוצגו בכרך יסודות. שלושת הכרכים הנותרים: איכות, נושאים תומכים וניהול, דנים במגוון נושאים ניהוליים והנדסיים שתפקידם לתמוך הן בעץ המערכת והן במחזור החיים. עץ המערכת, מחזור החיים והמטריצה המשלבת ביניהם הם, איפוא, הצירים המרכזיים עליהם סובבים המערכת והפרויקט ומפת"ח עצמו.

סרגל אחיד ועקבי

המטריצה מציגה בתמצית את התיאוריה המרכזית של מפת"ח - הגישה הדו-ממדית להנדסת תוכנה וניהול פרויקט תוכנה - שמשמעותה היא: סרגל אחיד לאורך מחזור החיים. סרגל זה הוא עץ המערכת. המטריצה ממחישה את העקביות וההמשכיות בתוצרים המרכזיים, כל תוצר הוא "עיבוי" ו"אימות" של התוצר הקודם.

כיצד זה מבוצע הלכה למעשה? איך מיושם "בשטח" מודל מפת"ח?

במסמך ייזום ההתייחסות לעץ המערכת היא חלקית, הן בתכני הרכיבים והן במספרם. עם זאת כבר בייזום יש התייחסות "בגדול" לכל חמשת הרכיבים הראשיים:

 

1.       יעדים - הגדרה כללית של מטרות המערכת והבעיות שהיא באה לתפור, לקוח, אופק זמן וכו',

2.       יישום – הגדרת משתמשים עיקריים, תת-מערכות ראשיות, דו"חות כלליים וכו'.

3.       טכנולוגיה – מהי הטכנולוגיה הקיימת והמשוערת, אילוצים ידועים וכו'.

4.       מימוש - תיאור כללי של האופן בו סביר שהמערכת תיבנה ותתופעל. תיאור מפורט כיצד ימומש השלב/הצעד הבא (אפיון?).

5.       עלות - חסמים עליון ו/או תחתון להערכת עלות המערכת.

 

במסמך אפיון יש כבר הגדרות ותכנים ברורים יותר במבנה הבא:

 

1.       יעדים - מה מטרות המערכת ולשם מה היא נחוצה, מה עלות\תועלת הצפויה מהמערכת?

2.       יישום - אילו פונקציות ושירותים תיתן המערכת, אילו נתונים היא תתחזק

3.       טכנולוגיה - חומרה/תוכנה בסיסית/תקשורת הנחוצה למערכת

4.       מימוש - כיצד תמומש (תופעל) המערכת, תכנית עבודה ברורה

5.       עלות - אמדן עלות המערכת.

 

מסמך עיצוב מערכת (תיק עיצוב) ייכתב גם הוא לפי אותם הסעיפים ויהיה המשך ישיר וטבעי לתיק האפיון, תוך הדגשת רכיבים פיסיים, ירידה לפרטים ו"סגירת" חלופות.

מסמך הבדיקות יסביר סעיף סעיף (רכיב רכיב) כיצד הוא ייבדק: איך תיבדק עמידה ביעדים, איך ייבדק היישום, אילו תרחישים נחוצים לבדיקת הטכנולוגיה וכו'.

מסמך סיכום בדיקות המערכת יכיל גם הוא את סעיפי עץ המערכת:

 

1.       יעדים - סיכום בדיקת היעדים

2.       יישום - סיכום בדיקת היישום

3.       טכנולוגיה - סיכום בדיקת הטכנולוגיה

4.       מימוש - סיכום בדיקת המימוש

5.       עלות - סיכום בדיקת העלות.

 

כך גם המסמכים המלווים את שלב המכרז (המפרט והצעות הספקים) וכך גם המסמכים להערכת מערכת קיימת, סיכום שיקוף (review) וכו'.

"התיישרות" כל מסמכי המערכת לפי מבנה אחיד ועקבי היא טבעית וברורה ונובעת מכך שמסמכים אלה משקפים אמנם פעילויות שונות ומגוונות סביב מחזור החיים - ייזום, אפיון, עיצוב, בדיקות וכו' - אך מתייחסים כולם, בסופו של דבר, לנושא אחד משותף – המערכת אשר כלי הביטוי המרכזי שלה הוא עץ המערכת. בכל שלב במחזור החיים עוברים רכיבי עץ המערכת הגדרה והבהרה נוספים - לשם כך קיים מחזור החיים - אך בעקרון אלה אותם רכיבים.

אחידות עץ המערכת מתבטאת בשתי רמות שונות אך משלימות:

 ·         ברמה של המערכת\הפרויקט - אחידות בתוך מערכת ספציפית, שפירושה עקיבות (traceability) והמשכיות (continuity) במעבר בשלבים השונים במחזור החיים וחסכון רב בבדיקה שתוצרי כל שלב עברו בשלמותם לשלב הבא.

 ·         ברמה של הארגון - אחידות בין מערכות בארגון או אף בתוך סקטור (בממשלה, למשל). אחידות זו היא הבסיס לשימוש חוזר (Reusability) ומונעת את "המצאת הגלגל".

 

עדיפות עץ המערכת

הדרך להגיע לעץ מערכת סופי ומסודר היא באמצעות מחזור חיים, היינו, מעבר מסודר בתחנות ובשלבים השונים. אך יש לזכור שהדרך היא תמיד משנית למטרה. במפת"ח, עץ המערכת מוביל את מחזור החיים ולא להפך. התוצרים הם העיקר ולא התהליך. במהלך הבנייה, ההסתכלות היא תמיד קדימה אל המבנה הסופי של המערכת בפעולה. עץ המערכת עובר מספר מבני ביניים בדרך אל עיצובו הסופי. התקדמות נכונה של הפרויקט פירושה שמבני ביניים אלה הולכים ומתכנסים אל העץ הסופי של המערכת.

אחת הדרכים לקידום עץ המערכת, גם בשלב האפיון וגם בשלב העיצוב והבנייה, היא שימוש חוזר ברכיבים קיימים (Reusability). שימוש חוזר, נרחב ככל שיהיה, לא מצדיק דילוג על שום שלב במחזור החיים, אך הוא משפיע באורח ניכר על יעילות הביצוע ומאפשר מעבר זריז וחסכוני. בשום שלב לא ממציאים את הגלגל מחדש. שימוש חוזר הוא המחשה טובה לכך שמחזור החיים קיים תמיד, אך יש לעץ המערכת עדיפות והשפעה ניכרת עליו. נושאים מרכזיים אחרים בהם עדיפות עץ המערכת באה לידי ביטוי הם: בקרת המערכת וניהולה ותיעוד המערכת המתוארים להלן.

 

עידון הקשר בין עץ המערכת ומחזור החיים

אחידות עץ המערכת לאורך מחזור החיים, אין פירושה שההתייחסות לרכיבי עץ המערכת היא זהה בכל שלב. אדרבא, ההתייחסות השונה - לעץ המערכת בכללותו ולרכיב הבודד - בשלבים השונים של מחזור החיים, היא אשר מבדילה בין שלב לשלב והיא שנותנת לכל שלב את אופיו המיוחד (גם את הצדקת קיומו!).

שתי הטבלאות הבאות מסכמות את הקשר של עץ המערכת עם מחזור החיים ומציגות, בין השאר, את ההתייחסות לרכיבי עץ המערכת בשלבים השונים של מחזור החיים. בטבלאות אלה נעשה "עידון" ו"חידוד" של הקשר בין רכיבי עץ המערכת ושלבי מחזור החיים - מעין "לכסון" המטריצה הכללית שלעיל. ברור שלכסון זה הוא כללי למדי. עידון נוסף מופיע בקיטים הדנים בסוגי מערכות IT השונים. עם זאת, אין נוסחה המגדירה את התלות המדויקת שבין רכיבי עץ המערכת ושלבי מחזור החיים וכל מערכת תגדיר את הלכסון המתאים לה.

הטבלה מציגה ליד כל שלב במחזור החיים את הקלט העיקרי, את התוצר (הפלט) העיקרי ואת התרומה העיקרית של אותו שלב לקידום רכיבי עץ המערכת. בהתאם להערה לעיל (בדבר חוסר נוסחה), יש להתייחס לטור השמאלי של טבלה זו כאינפורמטיבי בלבד, בעוד שארבעת הטורים הימניים מחייבים.

הערה: בניגוד לתוכן שבמטריצה בסעיף לעיל שהוא דוגמא ולצורך הסבר ראשוני, התכנים בשתי הטבלאות הבאות הם חלק מהנחיות הנוהל.

 

שלבים, קלטים ותוצרים במחזור החיים

שלב	תת-שלב	קלט עיקרי 1	תוצר עיקרי	דגש על רכיבי עץ מערכת
ייזום	-----	תכנית עבודה שנתית, מערכת קיימת, ראיונות	מסמך ייזום	1. יעדים - עיקרי 2. יישום - משני 5. עלות - חסמים
אפיון	-----	מסמך הייזום, ראיונות, מערכת קיימת, מערכות דומות, תכנית עבודה שנתית.	תיק אפיון	1. יעדים - משני 2. יישום - עיקרי 3. טכנו' - משני 4. מימוש - עיקרי 5. עלות - עיקרי
בקשה להצעות	אריזת המפרט	מסמך האפיון	מפרט (RFP) + מפ"ל	2. יישום - עיקרי 3. טכנו' – עיקרי 2
	בדיקת ההצעות	הצעות ספקים מפרט, מפ"ל	מפ"ל ממולא: המלצה והחלטה	3. טכנו' - עיקרי 4. מימוש - עיקרי 5. עלות - עיקרי
	התקשרות	הצעת הספק, מפרט	חוזה התקשרות + תיק מערכת	1. יעדים - משני 2,3,4,5 - עיקרי
עיצוב ובנייה	פיתוח או רכש	חוזה + תיק מערכת ראשוני (SOW)	תיק עיצוב סופי מערכת עובדת	1. יעדים - משני 2. יישום - עיקרי 3. טכנו' - עיקרי
	Unit-test	תיק עיצוב סופי מערכת עובדת	מערכת מוכנה לבדיקה כוללת	4. מימוש - משני 5. עלות - משני
בדיקות מערכת	-----	תיק עיצוב סופי (תיק מערכת). תיק האפיון. מערכת מוכנה לבדיקה	מערכת מאושרת להתקנה	1. יעדים - משני 2. יישום - עיקרי 3. טכנו' - משני 4. מימוש - עיקרי 5. עלות - משני
התקנה והרצה	התקנה	מערכת מאושרת להתקנה. תכנית הסבה, הדרכות	מערכת פועלת	2. יישום - עיקרי
	הרצה תפעול ראשוני	תיעוד תפעולי הדרכות	כיאות	3. טכנו' - עיקרי 4. מימוש - עיקרי
תפעול ותחזוקה	ללא שו"ש	מערכת מתפקדת תכנית לבדיקה	מערכת פועלת כיאות	2,3 - עיקרי 1,4,5 - משני

מקרא:

1 קלט נוסף לכל שלב הוא הקיט המתאים במפת"ח, הנספחים המתאימים וכן מסמכים מקבילים מפרויקטים אחרים (מערכות דומות)

2 בבקשה להצעות הדגש העיקרי הוא על כל ארבעת הרכיבים הקונקרטיים: 2, 3, 4 ו5-. ההבדל הוא רק במידה ומתי מושם דגש - במפרט או בהצעה - על רכיב.

טבלה 2 מציגה עידון נוסף של הקשר בין שלבי מחזור החיים לרכיבי עץ המערכת. זאת, במגבלות שמנינו לעיל. ההצגה הדו-ממדית של עץ המערכת ומחזור החיים במבנה של טבלה מאפשרת להתמקד בטורים, בשורות ואף במשבצות בודדות. התכנים שבטבלה להלן הן המלצות מפת"ח. על ידי החלפת תכני מפת"ח בתכני הפרויקט הספציפי, אפשר להפוך טבלה זו, ודומות לה, לכלי ניהול, מעקב ובקרה מעולים.

בראייה אופקית אפשר לראות את תרומת כל שלב לקידום רכיבי עץ המערכת, בראייה אנכית אפשר לראות כיצד מתפתח כל רכיב בשלבים השונים של מחזור החיים.

 

דגש על רכיבי עץ המערכת במהלך מחזור החיים

השלב	התייחסות לרכיבי עץ המערכת בכל שלב
	1. יעדים	2. יישום	3. טכנולוגיה	4. מימוש	5. עלות
ייזום	מוגדר היטב 1.1, 1.2, 1.7 חובה2 3	הגדרה כללית וראשונית	הגדרה ראשונית וכללית ביותר	מוגדר חלקית. 4.1, 4.3 חובה!	חסמים עליון ותחתון 1
אפיון	מאומת ומוגדר סופית 2 3 4	מוגדר כמעט מלא!	אילוצים /דרישות לפי תקינה או פירוט מלא	מוגדר!	נאמד! 4
בקשה להצעות4	מועבר מהאפיון	מועבר מהאפיון	מועבר מהאפיון	אילוצים, הצעות ספק	הצעת הספק, בדיקה מול אמידה עצמית
עיצוב ובניה	מועבר מהאפיון ונבדק 2	מוגדר סופית, נבנה, בדיקות יחידה ושילוב.	נרכש או מושאל לצורך הפיתוח.	בקרת מימוש שוטפת. השלמת תיעוד תפעולי.	אימות האמידה בקרה לחריגות
בדיקות מערכת	נבדק מול רכיב 1	נבדק לעומק ומאושר	נבדק בהתאמה להצעת הספק ולדרישות	נבדקת ההתארגנות לתפעול	נבדקת ההשקעה עד היום והצפויה
התקנה והרצה	----	מותקן ונבדק כללית	נרכש, מותקן ונבדק כללית	נבדק בשטח, מיושם.	בקרה לעלויות שוטפות
תפעול ותחזוקה	רענון	תיקון תקלות בלבד	תיקון תקלות וטיפול מונע	הגורם המתחזק	נבדק שאינו עולה על (15%)

מקרא

[1] בעקבות פעילות זו תיתכן החלטה על ארגון מחדש של המערכת במבנה ותפיסה שונים לגמרי.

2 בעקבות פעילות זו, תיתכן החלטה על חלוקה למספר מהדורות.

3 בעקבות פעילות זו, ייתכן שינוי בתיחום המערכת, בחלוקה לתת-מערכות והגדרת הקשר עם מערכות שכנות.

4 בשלב בקשה להצעות יש דגש רב על רכיב 0 - מנהלה - שאיננו מופיע בטבלה.

 

אפשר להשתמש בטבלה זו ככלי מעקב ובקרה מרכזי לכל מערכת ספציפית.

 

סיכום ביניים - מתיאוריה לנוהל

מודל מפת"ח בנוי משני צירים מרכזיים. הציר הראשון הוא עץ מערכת, אשר יוצר סרגל אחיד לאורך הפרויקט. סרגל זה מכניס מימד ברור של עקיבות, המשכיות והיצמדות לעיקר - תכולת המערכת, ולא למשני - התהליך. הסרגל מזכיר בכל רגע את המטרה המרכזית של התהליך כולו (הפרויקט) אשר היא, בשלבי הפיתוח:

ובשלב התחזוקה:

 

האמצעי להגיע למטרה זו הוא מחזור החיים - הציר השני של המודל - המגדיר פעילויות ומעבר מסודר בתחנות ובשלבים. מחזור חיים הוא כלי מרכזי לקידום עץ המערכת ואין ספק שהקפדה על ביצוע כל השלבים מניבה מערכות ממוחשבות טובות יותר. אין קיצורי דרך ואין נסים. יש תהליך מסודר ויש שלבים ופעילויות שאי אפשר לדלג עליהם. גם אם לעתים נדמה שאפשר "לחתוך פינות" ולדלג על שלב זה או אחר, מתברר בהמשך הדרך ששכר דילוג זה יצא בהפסדו ובסופו של דבר מבצעים את השלב עליו דילגו באופן לא-נוח ולא-מקצועי. שינויים מוצדקים במחזור החיים, כפונקציה של היקף הפרויקט למשל, מוגדרים במפת"ח ואין צורך "להמציאם". דוגמא לקיצור דרך הוא הקיט הדן במערכות קטנות.

עץ המערכת ומחזור החיים - שניהם חשובים. אין להגזים בעיסוק חד-צדדי באחד משניהם. התעסקות מוגזמת בעץ המערכת מעוררת מייד שאלות כגון: היכן נמצא הפרויקט (המערכת)? מה מנסים כעת להשיג? המשך תחזוקה? אפיון מחודש? יציאה למכרז? התעסקות מוגזמת במחזור החיים מעוררת מצדה תמיהה מוצדקת האם לא הפך האמצעי למטרה. השאלות שמתעוררות במקרה זה הן: מה תכולת המערכת? מדוע דברים לא נגמרים? אילו רכיבים חסרים למערכת כדי שתפעל כיאות, או לפחות כדי שאפיונה יושלם?

הסוד הוא בשילוב נכון, מאוזן ומלוכסן בין עץ המערכת למחזור החיים.

 

כלי עבודה

מושגי היסוד: עץ מערכת, מחזור חיים והמטריצה, אינם רק מודל תיאורטי, אלא גם "כלי עבודה" תכליתיים המכוונים ומדריכים את העבודה המעשית בפיתוח ותחזוקה של מערכות ממוחשבות. לאורך כל הנוהל נעשה שימוש בשלשה מושגי יסוד אלה.

עץ מערכת

עץ מערכת הוא "חוט השדרה" של המערכת (הפרויקט) בדומה לעץ מוצר בהנדסה הכללית. עץ המערכת הוא "המבט" על המערכת, הסמן המרכזי של כל תוצרי הפרויקט והאמצעי המרכזי לתיעוד המערכת, הקרוב ביותר למערכת עצמה. עץ מערכת כללי, המתאים בעקרון לכל מערכת ממוחשבת, מתואר בקיט עץ מערכת אוניברסלי. גלופות הלימוד וההרחבות לעץ המערכת מכילות פירוט נוסף של עץ המערכת האוניברסלי. בנוסף, בתת-הכרכים מערכות מידע ומערכות תשתית, מתוארים עצי מערכת ספציפיים למערכות מידע ולתשתיות ייחודיות, כגון: משרד ממוחשב, מערכות מחסן נתונים, מערכת ממ"ג, מערכות תקשורת, תשתית פיסית ועוד.

מחזור חיים

בניית המערכת נעשית ע"י אוסף של פעילויות ותהליכי העבודה על פני ציר הזמן. בלי פעילויות כגון: העלאת הצורך, לימוד מצב קיים, הערכת עלויות, כתיבת תיעוד, ביצוע שיקופים, ציוות אנשים, קיום מצגות, כתיבת קוד, רכש, בדיקות וכו' - אין פרויקט. את אוסף הפעילויות האלה, רבות מאד במספר, יש נטייה לאגד בשלבים ותת שלבים, המאפשרים תכנון, שליטה ובקרה של ביצוע הפרויקט. אוסף אקראי ולא מאוגד של פעילויות מקשה מאד על תכנון לוחות זמנים ובקרת עלויות וחמור מכל: בקרת תוצרים והגעה לאבני דרך בפרויקט. אגד מסודר של פעילויות הפרויקט נקרא מחזור חיים. כיוון שניתן לאגד ולארגן את פעילויות הפרויקט במספר רב של צורות, מקובל היום (בניגוד לעבר) לדבר על מחזורי חיים. לא מחזור חיים אחד, אלא מגוון רחב של מחזורי חיים: סדרתי, ספירלי, פיתוח בסבבים וכו'. הכרך הדן במחזור החיים, במפת"ח, מתאר את אבני הבנין היסודיות, את שלבי מחזור החיים הבסיסי: ייזום, אפיון וכו' המתאימים בעיקרון לכל פרויקט. הכרך ניהול, תת הכרך ניהול פרויקט, וכן הכרכים הדנים במערכות ייחודיות, מתארים מחזורי חיים מעשיים המתאימים למערכת ולפרויקט הספציפי. מודל מפת"ח תומך לא רק במחזורי חיים שונים (ראה פירוט בהמשך), אלא מאפשר למערכות קיימות ולפרויקטים שכבר יצאו לדרך, "להתחיל באמצע" ולהחיל את השימוש במפת"ח מהשלב בו הם נמצאים.

המטריצה (השילוב)

לאורך כל תהליך העבודה, בכל שלב ובכל נקודת זמן, מנוהל הפרויקט ונבחנת המערכת בחשיבה דו-ממדית של ציר מחזור החיים (פעילויות הפרויקט) וציר התוצרים (עץ המערכת).  חשיבה דו-ממדית זו היא מודל המטריצה של מפת"ח. המעבר משלב לשלב במחזור החיים, תוך שמירה על המשכיות ועקיבות עץ המערכת - היא המשמעות המרכזית של המטריצה. גם היכולת "להתחיל באמצע" נובעת מהמטריצה. תפיסת המטריצה שזורה לאורך כל מפת"ח ולא מוקדש לה קיט מיוחד. קיטים המדגישים את רעיון המטריצה באופן מיוחד הם:

 

 ·         כל הקיטים של מחזור החיים בכרך יסודות

 ·         הקיטים ניהול סיכונים, כלי פיתוח ותחזוקה - CASE אמידת עלויות וחישוב עלויות בכרך נושאים תומכים.

 ·         הקיטים שיקופים - Reviews בכרך איכות.

 ·         הקיטים תכנון אסטרטגי ותכנית עבודה שנתית, בכרך ניהול.

 

מתיאוריה לנוהל

מודל תיאורטי לבד, נכון ככל שיהיה, איננו מספיק. הפיכת תיאוריה לנוהל עבודה מסודר מחייבת התייחסות לנושאים חשובים שטרם הוזכרו - ולכך בדיוק מיועד המשך מסמך זה. בסעיפים הבאים מוצגים הגדרות ומושגים מרכזיים כגון:

 

 ·         סיווג מערכות לפי היקפן

 ·         גורמים מעורבים

 ·         מדדי איכות

 ·         ניהול ובקרה

 ·         שילוב כלים

 ·         מינוח שבשימוש הנוהל

 

כמו גם נושאים חשובים אחרים שאפשר לכנותם בשם כולל "מתיאוריה לנוהל". מנקודת מבט תיאורטית, נושאים אלה הם משניים, שכן הם נגזרים משלשת מושגי היסוד הנ"ל. אך מנקודת מבט מעשית, נושאים אלה הם חשובים ביותר והשפעתם ניכרת לאורך כל הנוהל.

 

ניהול ובקרה

עקרונות הניהול ובקרה המפורטים בפרק זה נכונים לכל ארגון העוסק במחשוב. חלק מההנחיות, בפרט בסעיפים שלשה המדדים הראשונים: פונקציונאליות, יעילות\מבניות וכלכליות, הם איכות המערכת הכוללת והיחסים השונים ביניהם יוצרים חלופות שונות של עלות/תועלת. איכות כוללת זו (העלות/תועלת) צריכה לענות על יעדי המערכת ותיעודה הוא ברכיב 1.6 של עץ המערכת. המדד הרביעי הוא בעיקרו בדיקה שאין במערכת בעיות משפטיות ואתיקה, כגון: פגיעה בזכויות הפרט וצנעתו, עבירה על חוק המחשבים, הפליה, "היגיינה ציבורית" וכו'.

סיווג מערכות לפי היקפן, משמעויות סיווג היקפי מערכות וגורמים מעורבים להלן, כתובים באוריינטציה ברורה למשרדי הממשלה. בארגונים שאינם משרדי ממשלה יוודא הקורא מהם הנהלים המקבילים הרלוונטיים.

ניהול ובקרה של תהליך פיתוח מערכת ממוחשבת ותחזוקתה מחייבים שיתוף פעולה הדוק בין כל הגורמים המעורבים, בפרט ב"משולש": הצוות המקצועי - הצוות המינהלי (ועדת ההיגוי) – הלקוח, בפרט בעבודה עם גורם חיצוני. שיתוף פעולה זה נשען, בין השאר, על כלי ניהול ובקרה, אשר נשענים מצדם על מדדים ושיטות בקרה מוסכמים. כלי הניהול והבקרה המרכזיים הם עץ המערכת ומחזור החיים שכבר הוגדרו לעיל. בסעיף זה מתוארים כלים נוספים וכמו כן מדדים ושיטות ניהול ובקרה חשובים, כגון: גדלי פרויקטים, מדדי איכות, הגדרת הגורמים המעורבים, שיתוף הלקוח (המשתמש) ועוד. ארבעת הסעיפים הראשונים מתייחסים למדדים ולגורמי ניהול ובקרה, שאר הסעיפים מתייחסים לשיטות וכלים.

מדדי איכות

מערכת ממוחשבת טובה היא מערכת המקיימת את התנאים הבאים:

 

 ·         פונקציונאלית - עונה לדרישות הלקוח (ארגון-האם),

 ·         יעילה - בנויה יעיל ונכון מבחינה טכנולוגית והנדסית, כולל גמישות לשינויים,

 ·         כלכלית - עומדת בגבולות המשאבים ולו"ז שהוקצו,

 ·         חוקית - עומדת בדרישות החוק, מינהל תקין וחוקת הארגון.

 

המונחים המקבילים באנגלית, הם:

 

 ·         Functionality

 ·         Efficiency

 ·         Economic

 ·         Legal

 

ארבעה מדדי-איכות אלה מלווים את המערכת לאורך כל הדרך ומסייעים לניהולה ובקרתה. הקשר שלהם למחזור החיים הוא כללי, בכל שלב יש לבדוק אם המערכת עומדת במדדים אלה. הקשר שלהם לעץ המערכת ברור יותר, כפי שמוצג בטבלה הבאה:

 

מדד-איכות	מידת הרלוונטיות לרכיבים בעץ המערכת
פונקציונאליות	בעיקר רכיב 2 יישום: טרנזקציות, מסכים, דו"חות וכו'.
יעילות ומבניות	בעיקר רכיב 3 טכנולוגיה, כולל אופן שילובו עם רכיב 2.
כלכליות	בעיקר רכיבים 5 עלות ו4- מימוש, סיכום ברכיב 1.6
חוקיות	כללית: רכיב 1 יעדים (1.4), רכיב 2.19 אבטחת מידע. פרטנית: תת-רכיבים ביישום (2.22) בטכנולוגיה ובמימוש.

 

שלשה המדדים הראשונים: פונקציונאליות, יעילות\מבניות וכלכליות, הם איכות המערכת הכוללת והיחסים השונים ביניהם יוצרים חלופות שונות של עלות/תועלת. איכות כוללת זו (העלות/תועלת) צריכה לענות על יעדי המערכת ותיעודה הוא ברכיב 1.6 של עץ המערכת. המדד הרביעי הוא בעיקרו בדיקה שאין במערכת בעיות משפטיות ואתיקה, כגון: פגיעה בזכויות הפרט וצנעתו, עבירה על חוק המחשבים, הפליה, "היגיינה ציבורית" וכו'.

סיווג מערכות לפי היקפן

השיטה הבסיסית של מפת"ח תקפה לגבי כל מערכת ממוחשבת ללא קשר לסוגה ולהיקפה. בעקרון, בכל מערכת קיים עץ מערכת וכל מערכת עוברת מחזור חיים כמוגדר לעיל. באופן מעשי, יש להיקף המערכתהשפעה על המעבר בשלבי מחזור החיים, על ההתייחסות המדויקת לרכיבי עץ המערכת וגם על מידת מעורבות הגורמים המוגדרים להלן.

ההגדרות (הכמותיות) בסעיף זה ובסעיפים משמעויות סיווג היקפי מערכות וגורמים מעורבים הסמוכים כתובים באוריינטציה ברורה למשרדי הממשלה. העקרונות נכונים גם עבור ארגונים אחרים, אלא שבהם יש לוודא מהם הנהלים המקבילים הרלוונטיים.

במפת"ח מסווגות מערכות IT לקבוצות הבאות:

 

סוג\היקף	הגדרה\תנאים
ג0 - רכיבי מדף מאושרים	עלות כוללת עד 20,000$, פריטים שאושרו במכרזי החשב הכללי.
ג1: פרויקטים קטנים	עלות כוללת עד 100,000$, כוח אדם לפיתוח תוכנה עד 1 שנת-אדם, עד 3 אנשים בפרויקט, מס' תחנות עבודה פתוחות בו-זמנית עד 8.
ג2: פרויקטים בינוניים	עלות כוללת עד 250,000$, כוח אדם לפיתוח תוכנה עד 4 שנות-אדם, עד 7 אנשים בפרויקט, מס' תחנות עבודה פתוחות בו-זמנית עד 40.
ג3: פרויקטים גדולים	עלות כוללת מעל 250,000$ - או - כוח אדם לפיתוח תוכנה מעל 4 שנות-אדם - או - 8 איש ומעלה בפרויקט - או - מס' תחנות עבודה פתוחות בו-זמנית מעל 40.

 

מקרא:

1.       התנאים בקבוצות הנמוכות (ג0, ג1 ו- ג2) הם חיתוך. היינו, צריך שכל התנאים יתקיימו על מנת שהמערכת תשתייך לקבוצה ומספיק שתנאי אחד לא יתקיים (גדול מהחסם שנקבע) כדי שהפרויקט יסווג בקבוצה גבוהה יותר. התנאים של ג3 הם, כמובן, איחוד, היינו, מספיק שאחד מהם יתקיים על מנת שהפרויקט יסווג כ- ג3.

2.       המדד של מס' האנשים העובדים בפרויקט, כולל עובדים מקצועיים וניהוליים, בין מיחידת המחשוב ובין עובדי חוץ, במשרה מלאה או חלקית. מדד זה משמש אינדיקטור טוב לסביכות המערכת ((complexity.

3.       עלות כוללת מוגדרת כסך כל ההוצאות הכרוכות בפיתוח המערכת ותחזוקתה לתקופה של 5 שנים ממועד תחילת האפיון. ההנחה היא שבתקופה זו תפותח תחילה מהדורה מרכזית אחת של המערכת, בהמשך יפותחו 2-3 מהדורות נוספות, ותבוצע תחזוקה שוטפת. ראה הגדרה מדויקת במילון המונחים המרכזי וכן פירוט רכיב העלות בקיט עץ מערכת אוניברסלי.

 

משמעויות סיווג היקפי מערכות

לסיווג המערכות לפי היקפן יש מספר משמעויות חשובות:

 

 ·         מערכות מסוג ג0 ממלאות "טופס ייזום" ועוברות מסלול קצר במיוחד כמפורט בקיט ועדות רכש והתקשרויות בכרך ניהול.

 ·         במערכות מסוג ג1 יאוחד שלב הייזום עם שלב האפיון. המעבר לעיצוב הוא פשוט והעיצוב עצמו הוא "המשך האפיון". מערכות מסוג ג1 יכולות גם להשתמש בהגדרת "עץ מערכת מקוצר", המאפשרת איחוד מספר רכיבים קרובים לרכיב אחד. ראה פירוט בקיט ייזום ובקיט אפיון.

 ·         מערכות מסוג ג1 ו- ג2 לא יבצעו את שלב הבדיקות כשלב עצמאי אלא יתרכזו בשיקופים, בדיקות יחידה (unit test) ותת מערכת (יחידת מסירה) בשלב עיצוב ובנייה ובדיקות התקנה בשלב ההתקנה.

 ·         מערכות מסוג ג3 חייבות בכל השלבים המוגדרים בנוהל זה.

 

הערכת היקף המערכת עשויה להשתנות במהלך מחזור החיים שלה, למשל, בעקבות ביצוע אמידת עלויות וחקר ישימות. אם מתברר שהיקפה של המערכת שונה ממה שהוערך תחילה, יש להתייחס אליה מאותה נקודת זמן ואילך לפי סיווגה החדש. הטבלה הבאה מסכמת את המעבר בשלבים של מחזור החיים כפונקציה של היקף המערכת (הידוע ברגע נתון).

 

שלב	מערכות קטנות, ג1	מערכות בינוניות, ג2	מערכות גדולות, ג3
ייזום	יאוחדו	חובה, ייזום כללי	חובה, חיוני להגדיר את כל הגורמים המעורבים
אפיון		חובה בפירוט מלא, אבטיפוס - רשות	חובה בפירוט מרבי, אבטיפוס - חובה
בקשה להצעות	אם יש רכש חיצוני	אם יש רכש חיצוני	אם יש רכש חיצוני
עיצוב ובנייה	חובה	חובה, דגש רב על Unit Test	חובה, דגש רב על  Unit Test
בדיקות מערכת	רשות – נדיר	רשות	חובה, הביצוע ע"י גורם עצמאי (נפרד)
התקנה והרצה	דגש על בדיקות קבלה	דגש מיוחד על בדיקות קבלה!	בדיקות קבלה רגילים
תפעול ותחזוקה	תפעול עצמי. בד"כ אפשר לכלול שו"ש  אם  אין חריגה בעלויות	ייתכן תפעול חיצוני. להפריד בין שו"ש לבין תחזוקת תקלות	ייתכן תפעול חיצוני. להפריד בין שו"ש לבין תחזוקת תקלות

 

גורמים מעורבים

הגורמים המעורבים בפיתוח ותחזוקה של מערכת IT בממשלה מתחלקים לשני סוגים:

 

 ·         גורמים הפועלים דרך קבע בארגון בנושאי מחשוב.

 ·         גורמים אד-הוק בפרויקט הספציפי.

 

הגורמים הפועלים דרך קבע במשרדי הממשלה בנושאי IT הם שניים:

 

 ·         ועדת היגוי למחשוב (IT)

 ·         ועדה להתקשרויות ורכישות IT (בקיצור - ועדת IT משרדית)

 

ועדת היגוי קובעת את מדיניות המשרד בנושאי IT, בכפוף למדיניות כלל-ממשלתית. הוועדה מאשרת את תוכנית העבודה השנתית לIT במשרד ועוקבת אחר ביצועה. בראש הוועדה עומד בעל תפקיד ברמה של סמנכ"ל, לפחות. הרכב הוועדה נקבע ע"י מנכ"ל המשרד. לעתים הנהלת המשרד משמשת כוועדת ההיגוי.

ועדה להתקשרויות ורכישות IT, כשמה כן היא, בוחנת ומאשרת רכש והתקשרויות שונות להם נזקקת מערכת IT במהלך פיתוחה ותחזוקתה. החלטות ועדה זו טעונות, לעתים, אישור מנכ"ל המשרד.

שני גורמים אלה פועלים ברמת כלל-המשרד. (ברמה הכלל-ממשלתית פועלים שני גורמים נוספים: רכז המחשוב באגף התקציבים והוועדה להתקשרויות ורכישות IT מרכזית בחשב הכללי - שניהם במשרד האוצר).

ראה הגדרה מלאה בהוראות התכ"ם ובקיט ועדות רכש והתקשרויות בכרך ניהול.

 

הגורמים הקשורים אד-הוק לפרויקט הם שניים:

 

 ·         צוות מינהלי – ועדת היגוי לפרויקט

 ·         צוות מקצועי.

 

הצוות המינהלי ימונה ע"י ועדת ההיגוי למחשוב (IT) ויפעל כוועדת משנה שלה. עיקר תפקידו הוא לאשר ביצוע אבני דרך ומעבר לשלבים הבאים של פיתוח המערכת - אבני דרך ושלבים שאינם כרוכים ברכש. אבני-דרך ושלבים הכרוכים ברכש או התקשרות, יומלצו ע"י הצוות המינהלי ויועברו לאישור ועדת IT המשרדית. בראש הצוות המינהלי יעמוד, בד"כ, הממונה על המחשוב במשרד. לצוות זה ניתן להוסיף גורמים אד-הוק כגון חברים מהצוות המקצועי, נציגי משתמשים, יועצים וכו'. הצוות המינהלי חייב להיות מוגדר במסמך הייזום (רכיב 4.1).

הערה: בארגונים רבים, כולל הממשלה, מקובל לקרוא לצוות המינהלי ועדת היגוי לפרויקט. ולעתים, בקיצור, ועדת היגוי. יש להבחין בין ועדת היגוי זו (לפרויקט) ובין ועדת ההיגוי למחשוב הנ"ל.

הצוות המקצועי הוא הגורם המבצע שלב מסוים בחיי המערכת: אפיון, עיצוב ובנייה, בדיקות וכו'. צוות זה יכול להיות פנימי, חיצוני או משולב. בראש הצוות עומד מנהל הפרויקט וחברים בו מנתחי מערכות, תוכניתנים, משתמשים וכו'. איוש התפקידים שונה מפרויקט לפרויקט ותלוי גם בהיקף המערכת (ראה הגדרה בסעיף ניהול ובקרה), סוג המערכת וכו'. בפרויקטים קטנים ואפילו בינוניים, סביר שמנהל הפרויקט הוא גם מנתח המערכות הראשי. רצוי מאד שמנהל הפרויקט יישאר קבוע לאורך כל מחזור החיים. שאר אנשי הצוות עשויים להתחלף. כל שיקוף וסקר של המערכת הספציפית יבוצע תחילה בצוות המקצועי. צוות זה ייעזר אד-הוק בגורמים מקצועיים שונים כגון: סיוע טכני, יועצים, משתמשים נוספים וכו'.

 

הגורמים המעורבים אד-הוק בפרויקט, בעיקר הצוות המינהלי והמקצועי, מתועדים ברכיב 4.1 בעץ המערכת.

 

משרדי ממשלה: הגדרה רשמית ומלאה של כל גורמים אלה נמצאת בהוראות התכ"מ.

ברכיב 4.1 בעץ המערכת.

 

ה"דרג המחליט", הוא הגורם אשר מקבל את ההחלטות המרכזיות בחיי המערכת, בפרט ההחלטה אם וכיצד להמשיך בפרויקט. גורם זה הוא פונקציה של שני פרמטרים עיקריים:

 

 ·         היקף המערכת (סיווגה)

 ·         ביצוע פנימי במשרד או ע"י גורם חיצוני.

 

הטבלה הבאה מגדירה מי הוא הדרג המחליט בכל מקרה. שים לב שטבלה זו היא כללית ונכונה בעקרון לכל שלב במחזור החיים. הגדרה ספציפית ומדויקת נמצאת בקיטי מחזור החיים המתאימים: ייזום, אפיון, בקשה להצעות וכו'. הטבלה הסופית והמחייבת נמצאת בהוראות התכ"מ של החשב הכללי.

 

היקף כולל משוער של המערכת1	הגורם המחליט
	כשהביצוע פנימי במשרד	כשהביצוע ע"י גורם חיצוני
קטן, ג1	הממונה על IT במשרד	הממונה על IT במשרד
בינוני, ג2	המלצת הממונה על IT - אישור הצוות המינהלי	וועדת IT המשרדית - אישור מנכ"ל המשרד2
גדול, ג3	המלצת הצוות המקצועי והצוות המינהלי - אישור מנכ"ל המשרד ואגף התקציבים2	המלצת ועדת IT המשרדית ומנכ"ל המשרד2- אישור ועדת ITהמרכזית

מקרא:

1.       ראה הגדרת היקף מערכת בסעיף סיווג מערכות לפי היקף הקודם. מערכות מסוג ג0 ("מוצרי מדף") לא מופיעות בטבלה זו. מערכות אלה יטופלו לפי קיט ועדות רכש והתקשרויות בכרך ניהול.

2.       אישורי מנכ"ל המשרד ו/או אגף התקציבים ניתנים, בד"כ, במסגרת תכנית העבודה השנתית. אישורים אד-הוק לפרויקט, כנ"ל, הם למקרים חריגים.

הערה: "מערכות" מסוג ג0- (רכיבי מדף הנרכשים מספקים) מטופלות ע"י ועדת רכש IT משרדית בהליך מזורז מיוחד, ראה קיט ועדות רכש והתקשרויות בכרך ניהול.

 

תוכניות עבודה וניהול פרויקטים

במפת"ח יש דגש רב על ניהול פרויקטים בכלל ועל תוכניות עבודה (ת"ע) בפרט. דגש זה בא לידי ביטוי בשלשה רכיבים בעץ המערכת:

 

 ·         רכיב 0 מנהלה - ניהול השלב הנוכחי

 ·         רכיב 4.2 פיתוח כולל של המערכת - ת"ע כוללת

 ·         רכיב 4.3 השלב הבא - ת"ע לשלב המיידי.

 

הכללת נושאים אלה כרכיבים בעץ המערכת, פירושה שבכל נקודת זמן במחזור החיים יש בקרה על "מה קורה כעת" וגם תכנון של "מה עתיד לקרות", הן בטווח הקצר והן בטווח הארוך. עץ המערכת עוקב לא רק אחרי תכולת המערכת, אלא גם על אופן מימושה (רכיב 4) ועלותה (רכיב 5).

תוכנית עבודה כוללת לבניית המערכת תוגדר לראשונה בשלב הייזום (סעיף 4.2 במסמך הייזום) ותעודכן בשלבים ובמסמכים הבאים, בפרט במסמך האפיון. תוכנית עבודה לשלב המיידי (הבא) תוגדר בסיום כל שלב ותתועד בסעיף 4.3 במסמך המסכם של אותו שלב. הגדרות אלה אינן פוטרות את הגורם המבצע מלהגדיר, בתחילת השלב, תוכנית עבודה סופית ומחייבת משלו. בניית תוכנית זו היא פעילות מיוחדת ("פעילות 0") המתוארת בקיטים של  מחזור חיים המתאימים. תוכנן המדויק של תוכניות העבודה נקבע, בסופו של דבר, בכל פרויקט (ובכל שלב בפרויקט) לגופו. תוכניות "שלדיות" נמצאות בקיטים ייזום, אפיון וכו'.

תוכניות העבודה ייבנו בשיטות ובטכניקות מוכרים לניהול פרויקטים כגון: Gantt Charts, Pert/CPM, מציאת הנתיב הקריטי, החלקת משאבים, ציון אבני דרך וכו'. טכניקות אלה, המקובלות בניהול ובקרת פרויקטים בתחומי הנדסה אחרים, תקפות גם בניהול פרויקטים במערכות ממוחשבות. קיימים בשוק מספר תוכנות וכלים לניהול פרויקטים המיישמים טכניקות אלה ומומלץ מאד להשתמש בהם.

במקרה של ביצוע שלב בפרויקט ע"י גורם חיצוני, יכלול גורם זה כלים לניהול פרויקטים ויגדיר תוכנית עבודה כחלק מהצעתו. במקרים אלה, חלקו של הארגון יתמקד בבדיקה ובבקרה: האם יש לגורם המבצע ניסיון בתחום זה, האם תכנית העבודה היא סבירה ומתועדת לפי דרישות מפת"ח, האם יש שימוש נכון בכלים לניהול פרויקטים והאם מתקבל דיווח שוטף על הביצוע כולל הצבעה על חריגות.

פעילויות מסוימות בתכנית העבודה נקראות אבן-דרך (milestone). אבן דרך היא פעילות אשר מקיימת את הדרישות הבאות:

 

 ·         מסתיימת בתוצר ברור ומוגדר,

 ·         כתוצאה ממס' 1, אם מדובר בהתקשרות חיצונית, ביצוע תשלום לספק

 ·         בסופה, מתקבלת החלטה לגבי המשך הפרויקט (פיתוח המערכת)

 

לפירוט נוסף ראה הקיט הדן בשיטות וטכניקות ניהול פרויקט בכרך ניהול\ניהול פרויקט.

שיקופים וסקרים Reviews -

שיקוף (סקר) הוא פעילות מעקב ובקרה מרכזית בה נבדקים, ככלל, שני היבטים מרכזיים (בהתאם למודל מפת"ח):

 ·         רכיבי עץ המערכת: התאמה לדרישות, מרחק מקו הגמר, מדדי איכות וכו',

 ·         מחזור החיים: אילו פעילויות בוצעו ואילו לא, עמידה בלו"ז ובעלויות וכו'.

 

בשיקוף של עץ המערכת, יש להשתמש במדדי האיכות הנזכרים לעיל. בשיקוף ישתתפו: חברי הצוות המקצועי, מומחה היישום (המשתמש העיקרי - הלקוח), ומשתתפים אחרים לפי הצורך והעניין: נציגים מהצוות המינהלי, משתמשים נוספים וכו'. עריכת שיקוף מסודר ומלא תבוא בד"כ לפני כל אבן דרך. במהלך הפרויקט יתבצעו שיקופים במספר מקומות, כגון:

 

 ·         בשלב הייזום (בד"כ פעם אחת, בסוף)

 ·         בשלב האפיון (מספר פעמים)

 ·         בשלב בקשה להצעות, לאחר סיכום הצעות הספקים (פעם אחת לפחות)

 ·         בשלב עיצוב ובנייה (מספר פעמים)

 ·         שלב הבדיקות: שלב זה הוא כולו פעולת שיקוף מרכזית.

 

הנקודות המדויקות בהן יש לערוך שיקוף מוגדרות היטב בתכניות העבודה השונות בקיטים המתאימים בכרך יסודות \ מחזור חיים. אך יש לזכור את הכלל:

 

לפירוט מלא של נושא השיקופים ראה בקיט שיקופים - Reviews שבכרך איכות.

נקודות פתוחות וחלופות

במהלך הגדרת המערכת ובנייתה, בעקבות עריכת שיקוף למשל, מתעוררות שאלות שיש לתת עליהן תשובה במועד זה או אחר. תשובות שונות לשאלה מסוימת, מייצגות בד"כ חלופות (אלטרנטיבות) שונות ברמת התפיסה של המערכת או ברמה מעשית של בניית רכיב מסוים. כל עוד אין תשובה מוסכמת, נשארת השאלה "פתוחה".

במפת"ח יירשמו השאלות (הנקודות) הפתוחות ברכיב מיוחד בעץ המערכת - 98. ניתן לרשום רכיב זה בכל רמה בעץ המערכת: ברמה הראשית - (98. נספח 98), ברמה המשנית (X.98) ברמה השלישית (X.Y.98) וכו'. ההחלטה באיזו רמה לנהל את הנקודות הפתוחות והחלופות היא ייחודית לכל פרויקט. כלל אצבע:

 

 ·         רישום ברכיב משני בעץ המערכת (X.Y.98) - מומלץ מאד.

 ·         רישום ברכיב ראשי בעץ המערכת (X.98) - מומלץ.

 ·         רישום ברמת עץ המערכת כולו (98.) כסעיף עצמאי ו\או כנספח - אפשרי.

 ·         ע"י כתיבת המסמך (אפיון למשל) כולו מספר פעמים (אפיון א', אפיון ב' וכו') - מקרה נדיר.

 

ליבון הנקודות הפתוחות וקבלת תשובות לגביהן הוא אחת ממטרות השיקופים. הטיוטות השונות, בעיקר של מסמכים כמו מסמך הייזום והאפיון, מקורן, בין השאר, בהתקדמות במתן התשובות לנקודות הפתוחות ובגיבוש החלופות השונות, עד לקבלת ההחלטה על החלופה המועדפת. סגירת הנקודות הפתוחות קודמת לחקר ישימות המוסבר להלן. לעומת זאת, נקודות שלא נסגרו באופן טבעי במהלך הפרויקט, מייצגות חלופות אמיתיות שאותן יש לנתח בתהליך מיוחד הנקרא ניתוח חלופות ושלו מוקדש קיט מיוחד בשם זה בכרך נושאים התומכים.

 

חקר ישימות

חקר ישימות (Feasibility Study) הוא מונח כולל לבדיקה מעמיקה של מידת המעשיות בהקמת המערכת והמשך פיתוחה. בדיקה זו כוללת:

 

 ·         בדיקת היתכנות: האם פיתוח המערכת והתקנתה ניתנים לביצוע (סביר)?

 ·         בדיקת איכות ותועלות: מה איכות הפתרון המוצע ומה התועלות שהוא מכיל. באיזו מידה הוא עונה למטרות ופותר את הבעיות שהוגדרו,

 ·         הערכת עלות/תועלת כוללת

 

כל אחד מהפרמטרים הנ"ל ניתן לבדיקה ישירה או יחסית. בדיקה ישירה, היינו, האם פרמטרים אלה סבירים מול "המקובל בשוק" ושהארגון יכול לעמוד בהם. בדיקה יחסית, פירושה, איך פרמטרים אלה עומדים יחסית לחלופות אפשריות ופתרונות אחרים.

חקר ישימות הוא מונח כללי. באופן מעשי מדובר על:

 

 ·         ניתוח סיכונים (בדיקת היתכנות)

 ·         אמידת עלויות

 ·         הערכת עלות\תועלת (של חלופה X)

 ·         ניתוח חלופות

 

ישימות המערכת היא חלק מהגדרת המערכת ובנייתה ומתועדת ברכיב 1.6 בעץ המערכת. בשיקופים ייבדק רכיב זה בדומה לכל רכיב אחר. עם זאת ישימות המערכת איננה רכיב רגיל. זהו רכיב אורתוגונלי אשר "חותך" ומסכם רכיבים אחרים. (בעץ המערכת יש מספר רכיבים כאלה, ראה הסבר מפורט בקיט עץ מערכת אוניברסלי). לפיכך "יציקת תוכן" לרכיב זה היא אוטומטית פעולת ניהול ובקרה. בנייה של כל רכיב אורתוגונלי היא פעולת בקרה. רכיבים אורתוגונליים אחרים כמו: אבטחת מידע (2.19), הצלבות וחיתוכים (2.20), נפחים וביצועים (2.21), חוסן ואמינות (4.8) ועלות (5) הם רכיבי בקרה טבעיים בדומה לחקר ישימות.

אין במחזור החיים שלב (או תת-שלב) של חקר ישימות. חקר ישימות נעשה בכל שלב, כל פעם שמתייחסים לרכיב 1.6 במהלך חיי המערכת. בקיטים של מחזור החיים להלן, מודגשות נקודות זמן טבעיות לחקר ישימות: סוף שלב הייזום, במהלך האפיון, שלב בקשה להצעות לאחר קבלת הצעות הספקים ועוד. חשוב גם לעמוד על הקשר בין חקר ישימות וניתוח חלופות. הנושאים אמנם קרובים, אך יש להבחין ביניהם. חקר ישימות בוחן עץ מערכת מסוים לאורכו (ולעומקו), ניתוח חלופות בוחן מספר עצי מערכת ומשווה ביניהם. בחקר ישימות נבדקת לעומק ישימות ועלות/תועלת של חלופה ( X מוגדר רכיב 1.6 של חלופה X) ואילו בניתוח חלופות נערכת השוואה של רכיב 1.6 בין החלופות השונות.

ניתוח סיכונים ובדיקת היתכנות

בדיקת היתכנות היא בדיקה האם בכלל ניתן לבנות את המערכת, מבחינה טכנית וכלכלית, בצורה המוצעת. בדיקה זו מאתרת רכיבים קריטיים (Critical Success factors - CSF) אשר עלולים לגרום לעיכוב במימוש המערכת, לייקורה, או לפגיעה בתפקודה. בדיקת היתכנות כוללת גם ניתוח סיכונים במובן של סיכונים לפרויקט ולארגון (לא סיכוני אבטחת מידע למשל), היינו, סיכונים שהמערכת לא תושלם או שהכנסתה לארגון לא תתממש. ניהול סיכונים הוא נושא שנחקר מאד בשנים האחרונות ומחליף, למעשה את הנושא של בדיקת היתכנות. ההנחה היא שבטכנולוגיה של היום אין בעיה לממש כמעט כל מערכת, אלא שהמימוש עשוי לגרום לחריגה משמעותית בלוחות הזמנים ו\או בעלות הפרויקט. זוהי בדיוק ההגדרה של סיכון לפרויקט. מכאן גם ברור הקשר של ניתוח סיכונים (והיתכנות) לנושא אמידת עלויות ולוחות זמנים.

 

אמידת עלויות

אמידת עלויות והערכת ההוצאה על בניית המערכת ותחזוקתה (באופק הזמן שהוגדר למערכת) נמצאת ברקע של כל חקר ישימות, ניתוח חלופות, ניתוח סיכונים, עלות\תועלת וכו'. אמידת עלויות היא הערכת הבסיס לכדאיות הכלכלית והעסקית של המערכת, היא ה"מכנה" בנוסחה של עלות/תועלת. אך יש לה גם מימד הנדסי. לעלות המערכת יש מתאם חיובי עם סביכות המערכת ומורכבותה. ככל שעלות המערכת גדלה וקשה יותר לחיזוי, כך סביר גם שמורכבות המערכת ומידת סביכותה, גדלות. לעלות מוקדש רכיב 5 בעץ המערכת. במפת"ח יש הפרדה בין אמידת עלויות לבין חישוב (או ריכוז) עלויות. ראה פירוט בקיטים אמידת עלויות, חישוב עלויות ועלות תועלת בכרך נושאים תומכים.

 

בדיקת איכות

בדיקה זו מטפלת במקרי הביניים, בהם אין מגבלות טכניות (או כלכליות) קיצוניות (ואלה רוב המקרים), אך עדיין יש לבדוק את "ישימות" המערכת בהיבט של טיב (איכות) הפתרון ואם אין חלופה איכותית (טובה) יותר. בבדיקה זו משתתפים מדדי האיכות שהוזכרו בסעיף מדדי איכות לעיל.

 

הערכת עלות/תועלת

בדיקה זו היא הקשה מכולן ובה מנסים למדוד את התועלת של המערכת (יחידות שירות שהיא מפיקה) ולהעריך את עלותה (כמה עולה כל יחידת שירות): האם המערכת כדאית מהיבט כלכלי ושווה את ההוצאה. המקום טבעי  (וכמעט יחיד) בו מבוצעת הערכת עלות/תועלת הוא שלב בקשה להצעות (מכרז) בהערכת הצעות ספקים.

מעורבות המשתמש

השתתפות פעילה ורציפה של המשתמש (הלקוח), בפרט בשלבים מרכזיים כמו אפיון ובדיקות מערכת, היא חיונית ועם זאת קשה ובעייתית. ישנן שיטות מיוחדות לנושא זה (שיטת JAD למשל) ומפת"ח כנוהל-מסגרת מאפשר ואף מעודד שימוש בשיטות אלה. תרומת מפת"ח לנושא חשוב זה היא במספר אופנים. ראשית, מפת"ח מדגיש את חשיבות מומחה היישום ומקדיש לכך רכיב מיוחד (1.1 - הרכיב הראשון!) בעץ המערכת. מומחה היישום איננו "עוד" משתמש, כי אם "מהנדס היישום" - הגורם המאשר את נכונות היישום (רכיב 2) באפיון, בבנייה, במבדקים וכו'.

 

שנית, שימוש נבון בעץ המערכת עשוי להגביר את מעורבות המשתמשים וקבלת אישורם למערכת. רכיבים בעץ המערכת כמו מסכים, דו"חות ואפילו קבצים, "מדברים אל המשתמש" וממחישים לו את המערכת ההולכת ונבנית. רכיבים רבים מוכרים למשתמשים עקב נפיצות הולכת וגדלה של מחשבים, בפרט מחשבים אישיים. רכיבים אחרים מוכרים ומובנים פחות וצריך להציגם באופן מיוחד. בכל מקרה, הצגת המערכת והסברתה למשתמש באמצעות עץ המערכת איננה מאמץ-שווא. במהלך בניית המערכת יצטרך המשתמש, במוקדם או במאוחר, להתוודע לרכיבים אלה. אם להשתמש באנלוגיה מתחומים אחרים, אין שום סיבה מדוע בני אדם יבינו את הרכיבים של מכונית או דירה (לא את תהליך הבנייה - את המוצר) ולא יבינו את הרכיבים של מערכת ממוחשבת.

צורה מיוחדת של הצגת (עץ) המערכת למשתמש היא תמצית מנהלים. תמצית מנהלים, היא חלק בלתי נפרד מתיק מערכת ומסיום מסודר של כל שלב במחזור החיים.

פירוט נוסף, ראה בקיטים שיתוף המשתמש וכתיבת תיעוד שבנושאים תומכים.

תיעוד

מטרת כל נוהל או מתודולוגיה היא, בין השאר, לפשט את תיעוד המערכת (כתיבתו, ניהולו וקריאתו) ועם זאת להגדירו במבנה ברור ומחייב. מפת"ח משיג מטרה כפולה זו במספר אמצעים, בראשם:

• כלים
• שיטה
• תיקיות

כלים

לכל תיעוד הנדרש במפת"ח, קיימות גלופות לימוד ועבודה מפורטות (שלדי תיעוד) המכילות הנחיות, דברי הסבר ודוגמאות. ניתן לצפות בגלופות אלה ולהפעילן מתוך כל קיט, או באמצעות ספריית הגלופות המרכזית. מפת"ח עושה שימוש מירבי בכלי האופיס, הדפדפן ומערכת החלונות הקיימים על שולחנו של כל משתמש. בנוסף, מתממשק מפת"ח בקלות לכלים ייעודיים לניהול פרויקטים וניהול מסמכים (ניהול תוכן). כלים אלה מצדם, מכילים ממשקים פתוחים המאפשרים חיבור עם שיטות אחרות (דוגמת מפת"ח) והתאמה לגלופות של המשתמש.

 

שיטה

בשיטת מפת"ח מחולק התיעוד לשלוש קבוצות:

 

 ·         תיעוד מחזור חיים (מסמכי המערכת)

 ·         תיעוד עץ המערכת

 ·         ניהול ומנהלה (ושונות)

 

זאת, תחת כל תיקייה (ספרייה) שהמשתמש יבחר (נושא התיקיות מוסבר בסעיף הבא).

 

תיעוד מחזור חיים – מסמכי המערכת

בסוג זה של תיעוד נכללים כל המסמכים המהווים תוצר ראשי של שלבי מחזור החיים: מסמך ייזום, תיק אפיון, בקשה להצעות, תיק עיצוב, תיק בדיקות, תיק תחזוקה וכו' (במערכות קטנות, מדובר במסמך אחד "מתגלגל" אשר נקרא תמ"מ – תיק מערכת מתגלגל). מסמכים אלה נקראים מסמכי מחזור חיים משום שהם "חותמים" כל שלב במחזור החיים של הפרויקט, מאידך הם מכונים מסמכי מערכת משום שהם במבנה עץ המערכת ומשום שהם משקפים את המערכת ו"חותרים" להשלמתה. עץ המערכת המשתקף במסמכים אלה הוא המערכת אליה כולם שואפים. עם השלמת הפיתוח, הופך חלק ניכר מתיעוד זה לתיעוד התפעולי המלווה את התפעול השוטף של המערכת ותחזוקתה. 

שם אחר לסוג זה של תיעוד, שהיה בשימוש במהדורות קודמות של מפת"ח, הוא תיעוד ביניים. בשל העובדה שמסמכים אלה משקפים את המערכת ו"חותרים" אליה, הם מכונים לעתים באנגלית The-system-to-be documents.

 

תיעוד עץ המערכת

בפרויקטים מסוימים נוח לראות רכיבים מסוימים של עץ המערכת לא כסעיפים של מסמכי המערכת, אלא כמסמכים עצמאיים ואפילו כתיקיות נפרדות. כל רכיב שהתיעוד שלו הוא משמעותי, משתנה ומתפתח לאורך מחזור חיי הפרויקט, ינהל "מסמכולוגיה" משלו, כולל קיטלוג ושמירה בתת-תיקייה נפרדת, במקום "לנפח" את תיק המערכת (בגוף התיק או בנספח). מדובר ברכיבים, כגון:

 

 ·         1.6.1 סיכוני הפרויקט

 ·         2.19 אבטחת מידע

 ·         2.4 ממשק המשתמש

 ·         2.5 תהליכים

 ·         2.12 בסיס הנתונים

 ·         2.21 דרישות ותחזית נפחים וביצועים

 ·         3.30 הגדרות רשת התקשורת

 ·         4.2 תוכניות עבודה

 ·         4.7.4 מדריכים למשתמשים

 

היתרון של שיטה זו הוא כפול:

 

 ·         ניתן לראות במקום מרוכז את כל "ההיסטוריה" וההתפתחות של אותו רכיב.

 ·         אנשי המקצוע המטפלים ברכיבים ספציפיים (מומחי ממשק אדם משתמש ברכיב 2.4, מומחי אבטחת מידע ברכיב 2.19 וכו') יתמקדו בתיקייה הרלוונטית – בתיעוד "ההנדסי" שהוא בתחום התמחותם. אנשי הניהול ואבטחת איכות יתמקדו במסמכי המערכת וב"תמונה הכוללת".

 

 

ניהול ומנהלה (שונות)

בקבוצה זו נכללים כל המסמכים הקשורים לתהליכי ניהול, מעקב ובקרה, שאינם כלולים באחת משתי הקבוצות הקודמות. במילים אחרות, מסמכים שאי אפשר לשייכם לרכיב מסוים בעץ המערכת (או לשלב מסוים במחזור החיים). הכוונה למסמכי עבודה שונים, כגון: ועדות היגוי, תכתובות, סיכומי דיון (וזימונים), שיקופים (זימון, ניהול וסיכום), דיווחי שעות, כתבי מינוי, חוזים והתקשרויות, מבדקי איכות וכן תוכניות עבודה ובקרה שונות (אם לא קוטלגו ברכיב 4.2 בעץ המערכת) כגון: תכנית אבטחת איכות, תכנית ניהול תצורה וכו'.

 

תיקיות

שלושת סוגי התיעוד הנ"ל: מחזור חיים, עץ מערכת ומנהלה, יכולים להופיע במספר תיקיות. שתי התיקיות הבסיסיות במפת"ח הן:

 

 ·        תיקיית הפיתוח – כל התיעוד הקשור בניהול הפרויקט ופיתוח המערכת.

 ·         תיקיית התפעול – התיעוד הנחוץ לתפעול המערכת שהוא חלק בלתי נפרד מהמוצר (המערכת),

 

כל תיקייה מכילה את שלושת קבוצות התיעוד הנ"ל, כמוסבר בטבלה הבאה:

 

תיקייה	ניהול ומנהלה (שונות)	מחזור חיים (מסמכי המערכת)	רכיבי עץ המערכת
פיתוח	תכתובות ועדות היגוי, סיכומי דיון (וזימונם), שיקופים וסקרים דיווחי שעות, כתבי מינוי, חוזים והתקשרויות, מבדקי איכות תכנית אבטחת איכות, תכנית ניהול תצורה	מסמך ייזום תיק אפיון מסמכי בקשה להצעות: מפרט\מפ"ל, הצעת ספק תיק עיצוב תיק בדיקות \ סיכום ממצאים תיק מערכת	כל רכיב שניהולו מצדיק פתיחת תיקייה עצמאית, דוגמאות: 1.6.1 ניהול סיכונים 2.19 אבטחת מידע 2.22 ממשקים 3.1 שרתים 3.20 מחשבי לקוח 3.30 רשת התקשורת 4.2 תכניות עבודה
תפעול	אירועי תחזוקה ניהול שינויים (CCB) הדרכות דיונים שונים כתבי מינוי \ שינויי צוותים	תיק מערכת [תיקי יחידות מסירה]	כל רכיב שניהולו מצדיק פתיחת תיקייה עצמאית, דוגמאות: 4.4 תיק תפעול 4.6 שירות ותחזוקה: נהלים וחוזים 4.7.4 מדריך למשתמש 4.8.1 תכנית בדיקה

 

תיקיית הפיתוח משותפת לכל בעלי התפקידים המעורבים בפיתוח המערכת:

 

 ·         הנהלת הפרויקט: מנהל הפרויקט, ועדת ההיגוי

 ·         מנתחי מערכות ומתכנתים

 ·         אבטחת איכות

 ·         צוות הבדיקות

 ·         יועצים ומומחים שונים

 

התיקייה התפעולית משרתת את בעלי התפקידים המעורבים בתפעול המערכת ובאחזקתה:

 

 ·         משתמשים

 ·         הצוות המקצועי המתחזק את המערכת: מנתחי מערכות, תוכניתנים

 ·         גופי תפעול וייצור.

 

תיקיות נוספות אפשריות – תיקיות מתמחות - הן:

 

 ·         תיקיית תחקור

 ·         תיקייה לשלב ספציפי במחזור החיים (מכרזים, בדיקות וכו')

 ·         תיקיית פרויקט קטן במיוחד

 ·         תיקיית פרויקט גדול במיוחד

 ·         תיקיית פיתוח בסבבים

 ·         ועוד

 

נושאים אלה מפורטים בהרחבה בקיט תיעוד בכרך נושאים תומכים ובקיטים השונים בכרך ניהול\ניהול הפרויקט..

סיכום ומידע נוסף

שיטת מפת"ח והכלים הנלווים מאפשרים:

 

 ·         לוודא המשכיות (Continuity) מחד גיסא ועקיבות (Traceability) מאידך גיסא

 ·         להעמיד את התיעוד המלווה את פיתוח המערכת ותחזוקתה על המינימום הדרוש

 ·         להבחין בדרגות שונות של חשיבות ועדיפות

 ·         לעשות שימוש חוזר בקטעי תיעוד.

 

בעץ המערכת מוקדש רכיב מיוחד - 4.5 אינדקס תיעוד - לריכוז כל תיעוד המערכת. חלוקת המשנה של רכיב זה היא:

 

 ·         4.5.1 תיעוד תפעולי (הפניה לתיקיית התיעוד התפעולי)

 ·         4.5.2 תיעוד הפיתוח (הפניה לתיקיית הפיתוח)

 

רכיב 4.5 קיים בכל מסמך ראשי המתאר את המערכת, נכון לשלב מסוים, כגון: מסמך אפיון, מסמך עיצוב, תיק תחזוקה וכו'. כל שנדרש לעשות הוא לברר מהו השלב במחזור החיים בו נמצאת המערכת ומהו מסמך המערכת העדכני, לגשת לרכיב 4.5 שם ומשם לאתר את כל שאר התיעוד. המבנה המלא והמדויק של רכיב 4.5 מפורט בעץ המערכת האוניברסלי ובמסמכי המערכת: תיק אפיון, תיק בדיקות ותיק התחזוקה.

 

 

ראייה מערכתית וכלל ארגונית

מפת"ח מטפל הן במערכת הבדידה והן בארגון. שני תחומים אלה משולבים זה בזה ולעתים קרובות צריך לנוע מהאחד לשני. בכיוון האחד, כאשר מטפלים במערכת ספציפית מגלים שבמקרים רבים ההגדרה "מהי המערכת" כלל איננה פשוטה. המערכת מתפצלת לתת-מערכות, היא מבוזרת בארגון, היא חלק ממערכת מקיפה יותר וכו; בקיצור יש צורך לחזור לרמת הארגון ולברר "על איזו מערכת בכלל מדובר". בכיוון השני, כאשר מתמקדים בניהול יחידת המחשוב מגלים, דרך תכנית העבודה השנתית למשל, שהגדרות גלובליות כמו "מערכת המידע של הארגון" או "corporate database" אינן מציאותיות והדבר התכליתי שיש להתמקד בו הן המערכות הספציפיות. נקודת המוצא צריכה להיות, אפוא, הסכמה ראשונית כלשהי של הגדרת רשימת המערכות הספציפיות. זו המשימה העיקרית של תכנון אסטרטגי ותכנית עבודה שנתית המוסברים בכרך ניהול. המשימה המרכזית היא לפתח מערכות אלה ולתחזקן מתוך ראייה מערכתית המאפשרת טפול דינמי בכל ההתפתחויות האפשרויות שהוזכרו: פיצול לתת-מערכות, מיזוג למערכת "גבוהה" יותר, ביזור, קשר לתשתיות בארגון וכו'.

להלן מספר נושאים והיבטים חשובים בנובעים מראיה מערכתית וכלל ארגונית של המחשוב.

חלוקה לתשתיות ומערכות מידע

מפת"ח מבחין בשני תחומים ראשיים בעולם המחשוב. חלוקה זו איננה מכסה את כל תחום המחשוב, אבל את רובו ואת העיקר. נושאי IT אחרים שאינם נופלים בחלוקה זו, מוגדרים בכרך  ניהול IT

 

 ·         מערכות מידע

 ·         מערכות תשתית.

 

מערכות מידע הן מערכות ייעודיות הבאות לשרת את יחידות הארגון בתפקודן השוטף. שירות זה מתבטא בראש ובראשונה בניהול מידע - ומכאן השם מערכת מידע. מערכות מידע הן התכלית - היעד הסופי - של כל המחשוב בארגון. המונח הלועזי הוא Information Systems - IS או MIS -  Management Information Systems.

מערכות תשתית הן כל המערכות הטכניות אשר תומכות במערכות המידע ומאפשרות את פעילותן. מערכות תשתית כוללות, בין השאר, תשתית פיסית, חומרה, תקשורת, תוכנה בסיסית, מערכת אבטחת מידע כוללת בארגון, כוח אדם ועוד.

מפת"ח מטפל בשני סוגי מערכות אלה, כמפורט בתת-הכרכים מערכות מידע ומערכות תשתית. קיימת נטייה ברורה ומוצדקת להעדיף את מערכות המידע ולטפל בתשתית דרכן (בעיקר באמצעות רכיב הטכנולוגיה בעץ המערכת). נטייה זו מדגישה את מקומה של יחידת המחשוב כספקית שירותי מידע לארגון ומעוגנת היטב בתפיסות ניהוליות וכלכליות מודרניות של פירוק הארגון למרכזי רווח והפסד, תקצוב פרויקטלי ועוד. ברור עם זאת, שבמקרים מסוימים יש לטפל ישירות בתשתית כמערכת ופרויקט בפני עצמם. הטיפול במערכות מידע ותשתית הוא על פי אותה שיטה ואותו מודל המוצגים במסמך זה. עץ מערכת, מחזור חיים, השילוב ביניהם (המטריצה), השיטות לניהול ובקרה וכו' - כל אלה תקפים גם למערכות מידע וגם למערכות תשתית! התועלת בשיטה אחידה איננו רק בנוחיות חשיבתית והקלה בלימוד והבנה (שגם הם חשובים ביותר), אלא בעיקר ביכולת גמישות ושמירה על השקעה בעבודה המעשית. במילים פשוטות, אפשר להתחיל לטפל במערכת גם מבלי לדעת בדיוק האם זו "מערכת מידע" או "מערכת תשתית". במהלך העבודה קורים שינויים ומתברר שהגדרת המערכת משתנה, כולל, למשל, שינוי מהותי מ"מערכת מידע" ל"תשתית" (או ההפך). שינויים אלה יצטרכו לקבל כמובן אישור מהגורמים המעורבים, אך מבחינה הנדסית/ניהולית אין שום בעיה - המודל והשיטה הבסיסיים נשארים בתוקף וההשקעה אינה יורדת לטמיון.

האיור הבא מציג את מקומה של יחידת המחשוב בארגון כספקית שירותי מידע ואת החלוקה הפנימית שלה למערכות מידע, מערכות תשתית והרובד הניהולי.

 

חלוקה למערכות מידע ומערכות תשתית

תכנון אסטרטגי ותכנית עבודה שנתית

תכנון אסטרטגי של צרכי המידע בארגון, נקרא גם תכנית אב למחשוב,  נערך אחת לתקופה מסוימת - 3-5 שנים. מטרתו לתת תשובה לשאלות מרכזיות כגון: אילו מערכות מידע צריך הארגון? באיזה סדר עדיפות אפשר וצריך לבנותן? מה התשתית הדרושה? אילו מערכות תבוזרנה ואילו תופעלנה בשיטה ריכוזית? הפלט העיקרי מתכנון אסטרטגי הוא:

 

 ·          תפיסה מחשובית כוללת לארגון

 ·          הגדרת מערכות המידע הנחוצות, כולל דירוג לפי מאפיינים שונים

 ·          הגדרת התשתית הנחוצה בארגון לקידום מערכות אלו.

 

תכנית עבודה שנתית (תע"ש) היא כלי אופרטיבי תקציבי והבסיס למימוש מערכות IT בארגון. בממשלה, מוגשת תכנית העבודה השנתית בשני מועדים: בחודש יולי במסגרת הכנת התקציב לשנה הבאה (תכנית משוערת) ובחודש ינואר עם תחילת שנת התקציב בה תבוצע העבודה (תכנית סופית ומאושרת לביצוע). הפלט העיקרי של תע"ש הוא:

 

 ·          רשימת מערכות המידע והתשתית שיפותחו או יתוחזקו בשנה הנדונה,

 ·          מיצוב מערכות המידע והתשתית על פני ציר מחזור החיים,

 ·          תקציב פיתוח (לפי מערכות/פרויקטים) ותקציב תחזוקה (לפי נושאים).

 

תכנון אסטרטגי הוא רצוי וחשוב אך אינו חובה. אם יש כזה, תכנית העבודה השנתית צריכה להיגזר ממנו. אם אין, עדיין תכנית העבודה השנתית היא חובה. בממשלה, ועדת ההיגוי המשרדית (ראה סעיף ניהול ובקרה לעיל) מופקדת על שניהם. הקשר בין מערכת IT ספציפית לתכנון האסטרטגי מוגדר ברכיב 1.4 בעץ המערכת והקשר לתכנית העבודה השנתית מוגדר ברכיב 1.5. רכיבים אלה יציינו כיצד נגזרת מערכת מידע ספציפית מהתכנון האסטרטגי ומתכנית העבודה השנתית של הארגון. ראה קיט תכנית עבודה שנתית בכרך ניהול.

PMO – Project Management Office

הפונקציה המרכזית האחראית על ניהול המערכות והפרויקטים בארגון נקראת PMO (Project Management Office). מכשיר מרכזי שעומד לרשותה הוא ניהול כרטסת (פורטפוליו) של המערכות והפרויקטים בארגון – PPM (Project Portfolio Management). להלן תיאור קצר של נושאים שבתחום פונקצית ה- PMO ומכשיר ה- PPM.

 

קשר בין מערכות

במהלך הטיפול במערכת ספציפית, הולך ומתברר הקשר בינה לבין מערכות אחרות "שכנות". קשר זה יכול להיות אחד (או יותר) מהסוגים הבאים:

 

 ·         קשר אסטרטגי

 ·         קשר תפעולי של העברות מידע, מיתוג מסופים וכו'.

 ·         רכיבים משותפים.

 

כל שלשת קשרים אלה מטופלים היטב דרך עץ המערכת. קשר אסטרטגי אפשר למצוא ע"י בדיקת רכיבים 1.4 ו- 1.5 (ודרכם אולי גם רכיבים אחרים ביעדים) במערכות הנדונות ולראות האם הם מתייחסים לאותה תוכנית עבודה שנתית ולאותו תכנון אסטרטגי. אם הקשר מצוין ברכיבים אלה, אבל איננו מתבטא גם ברכיבים מעשיים כמוסבר בהמשך, הקשר הוא "אסטרטגי" אך ללא משמעות קונקרטית. גם רכיב 3.33 טכנולוגיות משיקות, עשוי להצביע על "קשר אסטרטגי", או לפחות על פוטנציאל.

לקשר תפעולי מוקדש רכיב מיוחד - 2.22. מערכות המקיימות קשרים תפעוליים, ישוו רכיב זה (ודרכו אולי רכיבים אחרים ביישום) ביניהן, יאמתו אותו "הלוך וחזור", יוודאו שאיננו פוגע בחוק או בתקנות וייבדקו כיצד ניתן לשכללו ולשפרו. רכיב 2.4 יכול להכיל קשר מסוג "מסוף-יישום".

הקשר השלישי - רכיבים משותפים - יכול להופיע כמעט בכל רכיב של עץ המערכת. להלן מספר דוגמאות:

 

 ·         ברכיבים 2.9 ו- 2.10, תיתכנה שגרות וטבלאות מרכזיות בארגון המשותפות למספר מערכות מידע.

 ·         בכל תת-הרכיבים של רכיב 3 טכנולוגיה ותשתית, ייתכן שהמערכת הנדונה מתבססת על טכנולוגיה קיימת בארגון (ומרחיבה אותה), המשותפת גם למערכות אחרות. שים לב גם לרכיב 3.33 טכנולוגיות משיקות.

 ·         שותפות ברכיבי מימוש: ברכיב 4.6 שירות ותחזוקה, ברכיב 4.7 השתלבות בארגון (הדרכה והטמעה).

 

קשר הדוק באמצעות רכיבים משותפים מעורר כמובן שאלה אם אין לפנינו חלוקה מלאכותית למערכות שצריכות בעצם להתאחד. נקודה זו מביאה אותנו לסעיף הבא.

חלוקה לתת-מערכות

לטיפול בתת-מערכות מוקדש רכיב 2.3 תיחום פנימי. הכוונה הברורה היא לחלוקה פנימית של המערכת המקילה על ניהולה ובקרתה (ניהול תצורה, למשל), בלי לפרק את המסגרת הכוללת. עם זאת, במהלך הפיתוח עשוי להתברר שנושא זה דורש טיפול מיוחד. צריך לזכור שהגדרת תת-המערכות המוכלות במערכת (ואלה שלא), כמוה כהגדרת המערכת עצמה. ולהפך, הגדרת המערכת פירושה הגדרת כל תת-המערכות שלה. אין זה אלא טבעי, שבמהלך האפיון, עשוי לחול שינוי, לעתים שינוי רציני, בתפיסה הבסיסית של המערכת ובהגדרת תת-המערכות שהיא מכילה. שינויים אלה מתבטאים בפיצול או איחודרכיבים בעץ המערכת או אף עץ המערכת כולו, כמוסבר להלן.

תיחום כללי ראשוני של המערכת וחלוקה לתת-מערכות יכול לבוא ממספר מקורות: תכנון אסטרטגי, תכנית עבודה שנתית, ניסיון קודם, מערכות דומות ועוד. על סמך תיחום זה נבנה עץ מערכת ראשוני "לפי מיטב שפיטה", כולל רכיב 2.3 המגדיר את תת המערכות. אם במהלך העבודה מתברר שבמספר רכיבים מרכזיים (רכיבי יישום וטכנולוגיה בד"כ) יש התייחסות חוזרת ונשנית להפרדה לתת מערכות, יש לפצל את המערכת (את התיק) למספר מערכות (תיקים) נפרדים ולבנות לכל תת-מערכת את עץ המערכת שלה. פיצול זה איננו ניתוק, אדרבא, דווקא לאחר הפיצול בא לידי ביטוי הקשר בין (תת) המערכות באמצעות רכיב 2.22 ו/או כל רכיב רלוונטי אחר.

איחוד מספר מערכות (תיקים) יתרחש במקרה הפוך, בו הוגדרו מלכתחילה מספר מערכות עצמאיות (עם קשרים ביניהם). במהלך העבודה התגלו חזרות וכפילויות רבות בין תיקי המערכות ואותרו רכיבים משותפים, במידה כזאת, שמדובר בעצם במערכת אחת עם תת מערכות פנימיות. אגב, ביצוע איחוד כלל אינו פשוט, בוודאי לא מההיבט הניהולי (איחוד שני צוותים ניהוליים לצוות אחד!). ייתכן, כמובן, גם מקרה של שילוב (איחוד למחצה) לפיו יישמר תיק אחד מרכזי המתאר את המערכת הכוללת (הגלובלית) לצד תיקים "מקומיים" כמספר תת המערכות. רכיב 2.3 בתיק המרכזי הוא ה"אבא" של כל המערכת. תיק זה יכיל את כל הרכיבים המשותפים (הגלובליים) וינוהל ע"י פונקציה מרכזית בפרויקט - Data Administrator - הכפופה ישירות למנהל הפרויקט. ההחלטה לאחד, לפצל או לשלב מערכות איננה קלה וצריכה להתקבל בכל פרויקט לגופו. אמת המידה להחלטה היא עץ המערכת. מימוש ההחלטה הוא מפת"ח כולו.

לנושא זה מוקדשים הקיטים מערכות גדולות ותת-מערכות בכרך ניהול. נושא זה גם קרוב מאד למערכות מבוזרות המתואר להלן.

מערכות מבוזרות

מערכות מידע מבוזרות (או מערכות בעלות מרכיב ביזור גבוה) מאופיינות ע"י מספר "מרכזי חישוב" שגם אם הם מבוקרים בתפעול השוטף ע"י מרכז שליטה ובקרה אחד, הם עדיין אוטונומיים למדי בניהול המידע ובמתן שירות למשתמשי הקצה. מערכות מבוזרות הן בדרך כלל מורכבות וסבוכות, לא רק בתפעול השוטף, אלא גם בתהליך פיתוחן ותחזוקתן. ומה שחמור מכל, היא ההחלטה האם וכיצד לבזר. נושא הביזור מקבל משמעות מיוחדת בעידן של נפוצות גבוהה והולכת של מחשבים אישיים, תחנות עבודה ומערכות שרת/לקוח ויש בהחלט סימוכין לטענה שביזור הוא עובדה קיימת והשאלה היא רק מה הדרך היעילה ביותר למסדו. ועם זאת, "תחום הביזור" הוא רחב ויש עדיין מרחב החלטה גדול של כמה והיכן לבזר, לפני ההחלטה איך לבזר.

מפת"ח מציע מספר גישות לפיתוח מערכת מבוזרת, בהתאם ל"רמת הביזור". במהלך הפיתוח אפשר לעבור מגישה אחת לשנייה, אם מתברר ש"רמת הביזור" שונה ממה שנצפה בהתחלה. מפת"ח גם מציע מספר כללי אצבע להחלטה אם בכלל לבזר ובאיזו "רמה", כפונקציה של התנהגות רכיבי עץ המערכת במהלך האפיון. ההחלטה הסופית היא, כמובן, לא רק תוצאה של "התנהגות" רכיבי היישום (דרישות הארגון ואופיו), אלא גם של רכיבי הטכנולוגיה (ההיצע בשוק) ושל המימוש. זיהוי חד-משמעי של תת-מערכת מסוימת - עם משתמשים ייחודיים לה, קבצים ברורים משלה, קשרים חזקים למערכות שכנות וללא קשרים חזקים עם תת-מערכות אחרות - זיהוי כזה יכול להצביע על אפשרות סבירה לביזור.

לנושא זה מוקדשים הקיטים שרת/לקוח בכרך נושאים תומכים, ומערכות מבוזרות בכרך ניהול.

מערכת נושאת ומערכת נישאת

במקרים לא-מעטים מערכת נבנית "על גב" מערכת אחרת. הראשונה נקראת מערכת נישאת והשנייה מערכת נושאת. דוגמא מתחום מערכות מידע, היא מערכת הנבנית בעזרת חבילת תוכנה  (Package) תוך הכנסת התאמות ושינויים מקומיים (קסטומיזציה). דוגמא מתחום מערכות תשתית, היא מערכת תקשורת פרטית הנבנית ע"ג מערכת תקשורת ציבורית. מקרים אלה נעשים שכיחים ככל שעולם המחשבים הולך ומשתכלל ובסה"כ זו תופעה רצויה.

בגישת מפת"ח, יש לייחד את אחד מסעיפי ההבהקים (X.0) להסבר כללי של הקשר בין המערכת הנישאת והנושאת ולאחר מכן, יש לפרט בכל רכיב ורכיב איזה חלק תורמת המערכת הנושאת ואיזה חלק יש להתאים או לפתח במערכת הנישאת.

ראה קיט מערכות מידע - כללי.

מינוח / טרמינולוגיה

חלק בלתי נפרד מכל שיטה היא ה"שפה" - העגה המקצועית - אשר מכילה מינוח שהשיטה משתמשת בו. שפה זו מקבלת משנה חשיבות לנוכח הצפת עולם המחשבים, חדשים לבקרים, בזימזומילים  (Buzzwords) לרוב. במקרים מסוימים, זימזומילים אלה אכן מייצגים תפיסה או רעיון חדשים אשר מחייבים מינוח חדש. במקרים אחרים, אלה שמות חדשים למונחים קיימים  (synonym)ובמקרה הגרוע הם שימוש בשם קיים עבור מושג אחר קיים כבר (homonym). זימזומילים אחרים הם פשוט סיסמאות חסרות משמעות מעשית.

במפת"ח מושם דגש רב על השפה והמינוח שבשימוש וקיימת דרישה ברורה מהמשתמשים במתודולוגייה שידברו אף הם בשפה זו. נעשה מאמץ מרבי להשתמש במונחים קיימים, ולא להמציא חדשים, יחד עם הגדרות ברורות, ניפוי שיבושים, הפחתת synonym ומניעה מוחלטת של homonym. למינוח מוקדש מילון המונחים המרכזי במפת"ח. הסעיף שלהלן איננו תחליף למילון המונחים, אלא חזרה ורענון של מושגים ומונחים שכבר הוזכרו וכן הסבר קצר למספר מצומצם נוסף של מושגים ומונחים חשובים על מנת להראות את שלמות המודל וסגירותו ולאפשר המשך קריאה שוטפת.

רענון מונחים

עץ מערכת

אוסף הפריטים המרכיבים מערכת ממוחשבת. אוסף זה מכיל רכיבים מוחשיים ומופשטים, פיסיים ולוגיים, אשר כל אחד לחוד הוא תנאי הכרחי לקיום המערכת, וביחד הם תנאי מספיק. שמות נרדפים: עץ מוצר ו"רכיבי המערכת". המונח עץ מערכת הוא המונח הרווח, אלא שלעתים הוא במשמעות של מודל עץ המערכת האוניברסלי, לעתים במשמעות של עץ מערכת ספציפי (אנכי) ולעתים במשמעות של עץ מערכת פרטי (של מערכת מסוימת). עץ המערכת מכונה לעתים גם הסרגל או "ציר ה- Y" במטריצת מפת"ח. הקיט עץ מערכת אוניברסלי מרחיב בנושא.

עץ מוצר

עץ מוצר הוא מושג הלקוח מעולם ההנדסה הכללי. במפת"ח, עץ מוצר הוא שם נרדף לעץ מערכת. אנו נשתמש בעיקר במונח עץ מערכת. במקומות בהם מופיע "עץ מוצר" הכוונה היא או לעץ מוצר במובן ההנדסי הכללי או כשם זהה לחלוטין לעץ המערכת.

רכיב

רכיב הוא חלק (פריט) בעץ המערכת. אין להחליף "מרכיב" עם "רכיב". מרכיב הוא פועל, לא שם עצם.

סעיף

על מנת למנוע בלבול בין מבנה נוהל מפת"ח עצמו לבין עץ המערכת, סעיף הוא קטע במדריך שבקיט לעומת "רכיב" שהוא קטע בעץ המערכת. ל"סעיפים" במסמכים הבנויים בשיטת עץ המערכת (מסמך ייזום, תיקי עבודה ועוד) נתייחס בשם רכיב ולא סעיף.

מחזור חיים

אוסף כל השלבים המרכיבים את תהליך בניית מערכת ממוחשבת ותחזוקתה. שמות נרדפים: "תהליך הבנייה והפיתוח", "תהליך העבודה", או "תהליך" סתם (לא לבלבל עם רכיב 2.5 תהליכים של המערכת). מחזור חיים מורכב משלבים (תת-שלבים) ומפעילויות. יש לבנות תכנית עבודה לכל שלב. המונחים "שלב", "פעילויות", "תכנית עבודה" ו"תהליך הפיתוח" הם מונחים קרובים למחזור חיים, אך לא זהים. מחזור חיים מתאר גם את התנועה על ציר הזמן ומכונה לעתים גם "ציר ה- X" במטריצת מפת"ח.

שלב

שלב הוא קטע במחזור החיים. שלבים גדולים מחולקים לעתים לתת-שלבים.

פעילות

פעילות היא חלק משלב (או תת-שלב). פעילות ראשית בה נערכים שיקופים ומתקבלות החלטות נקראת אבן דרך. פעילות יכולה להיות מכמה סוגים: פעילות פיתוח ובנייה, פעילות ניהול ובקרה, פעילות תפעול וייצור ועוד. כל פעילות שייכת לשלב מסוים במחזור החיים וצריך לתמחרה בהתאם. אם הפעילות "נוגעת" באופן ברור ברכיב מסוים בעץ המערכת ניתן לזקוף אותה לא רק לשלב במחזור החיים אלא גם ישירות למערכת. (למשל, חקר ישימות אשר בונה את רכיב 1.6).

תכנית עבודה

אוסף כל הפעילויות של שלב (או תת-שלב) במבנה מסודר ובהערכת לוחות זמנים ומשאבים.

שיקוף (review)

פעילות ניהול ובקרה מרכזית לצורך בדיקה שהמערכת מתאימה לדרישות ובנויה נכון. בשיקוף נסקרים הן עץ המערכת והן מחזור החיים. שם נרדף לשיקוף: סקר.

חקר ישימות וניתוח חלופות

בחקר ישימות נבדקת המערכת בשלשה היבטים עיקריים: היתכנות, איכות ועלות/תועלת. חקר ישימות, שיקוף וניתוח חלופות קשורים זה בזה. חקר ישימות ושיקוף יכולים להתבצע בסדר משתנה. בשיקוף נבדק האם בוצע כבר חקר ישימות. ביצוע חקר ישימות הוא "בנייה" של רכיב 1.6 בעץ המערכת. תוצאות החקר מתועדות ברכיב 1.6 במסמכי הביניים - תיקי המערכת - ועוברות שיקוף בדומה לכל רכיב אחר. ניתוח חלופות במשמעות של סגירת נקודות פתוחות מתבצע באופן שוטף במהלך הפיתוח ובשיקופים. ניתוח חלופות במשמעות של בחירה בין אפשרויות שונות, נעשה ע"י השוואת ישימות, היינו השוואת רכיב 1.6 של החלופות השונות. במובן אחרון זה, ניתוח חלופות בא אחרי חקר ישימות ושיקופים, הגם שתמיד יש מקום לשיקוף סופי שבודק האם בוצע ניתוח חלופות וכיצד. כאמור, שלשה נושאים אלה קרובים ומשולבים זה בזה באופן הדוק.

מונחים ומושגים נוספים

סקר מצב קיים

סקר/חקר מצב קיים (נקרא גם ניתוח מצב קיים או סקר בעיות), מטרתו לתת "תמונה כללית" של המצב הקיים, בתחום בו המערכת עתידה לפעול. המטרה הבסיסית היא נכונה וחשובה, אך יש לזכור שזו פעולה מורכבת אשר עשויה לצרוך משאבים רבים ובד"כ גם איננה מטרה לעצמה. במפת"ח, סקר מצב קיים הוא אחת מפעילויות שלב האפיון וכל פרויקט צריך להחליט עד כמה להשקיע בפעילות זו ובתיעודה. תוצאות פעילות זו ישתלבו במבנה עץ המערכת באחד מהאופנים הבאים:

 

 ·         ברכיבים 1.3 ו- 2.1 בעץ המערכת - מומלץ,

 ·         ליד כל רכיב כחלק מאפיונו. באופן זה, סביר שההתייחסות למצב הקיים תהיה רק במידה הנדרשת לבניית מערכת חדשה - מומלץ מאד,

 ·         כמסמך נפרד - נדיר! מסמך זה יהיה במבנה עץ המערכת ויתאר את מצבו של כל רכיב קיים, כך שניתן לעבור מיידית למסמך האפיון.

 

חשוב להבחין בין מסמך מצב קיים ולימוד מצב קיים. מסמך מצב קיים דורש השקעה רבה ובד"כ גם אין קוראים אותו. לימוד מצב קיים הוא פעולה חיונית לאפיון, שהרי רוב המערכות הנבנות הן פשרה בין הרצוי למצוי (מצב "רמצוי"). לימוד מצב קיים חשוב ככל שהמערכות בארגון הולכות ומשתכללות וצוברות ניסיון והסכמה שאותם יש לדעת לנצל. בבניית מערכות ממוחשבות יש לראיין לא רק אנשים אלא גם מערכות. "ראיון" כזה אפשר לערוך בעזרת עץ המערכת. אפשר "לשאול" את המערכת: מי המשתמשים, אילו דו"חות היא מפיקה, כיצד מוגדרים הקבצים וכו'.

את כל המידע שנצבר מלימוד מצב קיים, מומלץ להבנות ישירות לתוך תיק האפיון שמעצם טבעו מתאר מצב "רמצוי", ולא להשקיע במסמך שאינו מטרה. ואם מחליטים בכ"ז לתעד מצב קיים, יש לוודא שהתיעוד יהיה במבנה עץ המערכת (עץ מערכת של מצב קיים), כך שניתן להמשיכו ישירות לתיק אפיון.

הגדרת דרישות

הגדרת דרישות היא הגדרה מפורטת של עץ המערכת, ברמת כל רכיב ורכיב, ולפיכך היא שם נרדף לאפיון. אין זה עניין של מינוח גרידא. תפיסת מפת"ח היא שהגדרת הדרישות היא ע"י תיאור איך המערכת (הלוגית) צריכה להיראות. טרנזקציה, מסך, או קובץ הם דרישה.

ניהול תצורה ומהדורות

ניהול תצורה  (System Configuration Management), הוא בעיקרו היכולת לפתח, לתפעל ולתחזק מערכת ממוחשבת במספר מהדורות (גרסאות) מסודרות ולשלוט באופן שוטף על תכולתה. לנושא זה חשיבות עצומה הן בשל מורכבות המערכת והן בשל דרישות הלקוח, המשתנות תדיר. עץ המערכת הוא התשתית לניהול תצורה - ניהול מסודר של עץ המערכת הוא הבסיס  (baseline) לניהול תצורה. לעץ המערכת המוצג בתחילת מסמך זה, נוספים רכיבים מיוחדים, X.98 נקודות פתוחות ו- X.99 דרישות עתידיות, שניתן להדביקם לעץ בכל רמה, ואשר מסייעים בניהול תצורה ובשליטה על מהדורות. שימוש נבון ברכיבים אלה מאפשר הפרדה בין ה"מהדורה הנוכחית" לבין מהדורות עתידיות. ניהול מהדורות, בצמוד לרכיבי עץ המערכת, הוא מכשיר מרכזי (אך לא היחידי) לניהול תצורה במפת"ח.

התייחסות מפת"ח לניהול תצורה, מעבר לניהול עץ (תיק) המערכת הכולל, היא במקומות הבאים:

 

 ·         בתיקי העבודה, ברכיב 4.6 וברכיבים הרלוונטיים,

 ·         ברכיב 3.13 - כלי פיתוח ותחזוקה, הכולל דרישות לכלים לניהול תצורה,

 ·         בפעילויות בשלבי מחזור החיים השונים, בעיקר בשלב עיצוב ובנייה.

 

לניהול תצורה מוקדש קיט מיוחד בשם זה בכרך נושאים תומכים.

אבטחת איכות ובקרת איכות

אבטחת איכות (Software System Quality Assurance) מושגת בראש ובראשונה ע"י הקפדה על עבודה מסודרת לפי נוהל מפת"ח. אין "נוהל עבודה" לחוד ו"נוהל איכות" לחוד. נוהל העבודה מכיל אמצעי תכנון, ניהול, מדידה ובקרה וכן תכנים כגון: רשימות תיוג, הפניה לתקנים, שלדי תיעוד, גלופות חוזים וכו' אשר כולם יחד מסייעים להבטחת איכות המערכת א-פריורי ובמהלך הביצוע. זאת, לפי הכלל הידוע:

בקרת איכות (Quality Control) כפונקציה פוסטריורית יכולה גם היא להיעזר בתכני מפת"ח. מלבד הכרך איכות המיועד ישירות לנושאי אבטחה ובקרת איכות, כל מפת"ח הוא מאגר ידע העומד לרשות מבקר האיכות (או מבקר פנים, או כל פונקצית בקרה אחרת) בדיוק כפי שהוא עומד לרשות צוותי הפיתוח של המערכת. שימוש במאגר זה ע"י המבקר לא רק מייעל את עבודתו הוא, אלא גם את עבודת הפיתוח כולה. המבקר איננו בא ב"דרישות חדשות" לצוות הפיתוח הלקוחות מנוהל פנימי שלו, אלא מחדד ומוודא נושאים משותפים. בקרת איכות כפונקציה ארגונית או פרויקטלית, תיקבע ע"י כל ארגון לפי שיקוליו ואיננה מוכתבת ע"י מפת"ח.

ארגון ושיטות (או"ש)

או"ש מוגדר במפת"ח בשתי רמות:

 

 ·         ברמה האסטרטגית: האם המערכת תואמת את חוקת הארגון, כיצד משתלבת המערכת בתפקוד הארגון הכולל, התאמה לכוח האדם בארגון, וכו' - היבט זה נמצא ברכיב 1.4 ביעדים,

 ·         ברמה המעשית: השתלבות בהדרכות, הסבות, הטמעת שינויים, הנעת אנשים וכו' - היבט זה נמצא ברכיב 4.7 במימוש.

פירוט נוסף נמצא בהרחבה לרכיב 4.7 בקיט עץ מערכת אוניברסלי.

כלים להנדסת תוכנה CASE -

השם המודרני לכלים לפיתוח תוכנה ותחזוקתה, מה שנקרא גם "כלי פיתוח", הוא CASE - Computer Aided Software Engineering. להלן מספר הערות חשובות באשר להתייחסות מפת"ח ל- CASE:

 

 ·         מפת"ח מאפשר שימוש במגוון כלי CASE ואינו מכתיב שימוש בכלי זה או אחר. השתמש בכלים הקיימים אצלך. מפת"ח עצמו כבר משוכן במספר כלים קיימים בשוק המאפשרים לעבוד במתכונתם הרגילה ולהפיק את התיעוד הנדרש ע"י מפת"ח.

 ·         מטריצת מפת"ח משמשת רשימת-תיוג לבדיקת כלי CASE ובחירתם. כלים נבחנים לפי ה"כיסוי" שהם נותנים ל"משבצות" שבמטריצה. ראה הרחבה של נושא חשוב זה בקיט כלי פיתוח ותחזוקה - CASEבנושאים התומכים.

 ·         גישת עץ המערכת ה"מושכת" לכוון המערכת עצמה, מדגישה את חשיבות יכולת הכלים לקיים המשכיות  (continuity) ועקיבות  (traceability) ולהעביר בקלות את תוצריהם לשלב הבא. ארגונים שיש להם כבר כלים עבור שלב העיצוב והבנייה (כלי Lowercase), יבחנו את הכלים לאפיון  (Uppercase) לאור דרישה מרכזית זו. בפרויקטים בהם טרם ידוע רכיב הטכנולוגיה (הוא ייקבע רק בשלב בקשה להצעות), יש להעדיף כלי CASE הפועלים על ציוד "נייטרלי", דוגמת PC, ומכילים המשכיות ויכולת העברה לסביבות עבודה מקובלות.

 ·         העלויות הכרוכות בהטמעת כלי CASE הן גבוהות ביותר, הרבה מעבר לעלות הרכישה הישירה. ברוב המקרים קשה להצדיק כלכלית רכישת כלי CASE לצורך פרויקט ספציפי. יש להעדיף כלים קיימים בארגון או כלים בהם הספק מתמחה ומציע אותם כחלק מהעסקה הכוללת של בניית המערכת. במקרה זה יש להעריך בנפרד עלות רכיב זה (ראה רכיב 3.13 בעץ המערכת).

 

ראה פירוט נוסף של נושא זה בקיט כלי פיתוח ותחזוקה - CASE בנושאים תומכים.

כאמור לעיל, סעיף זה איננו בא להחליף את מילון המונחים הרשמי של מפת"ח. מטרתו היחידה היא להראות את שלמות וסגירות המודל, באמצעות האופן בו מפת"ח מתייחס למונחים ומושגים שגורים בפי כל, ולהקל על המשך הקריאה.

 

 

נוהל-מסגרת פתוח

המודל "התיאורטי" העומד בבסיס שיטת מפת"ח, הוא זה שמאפשר את הגמישות המעשית של המתודולוגיה בשטח. מפת"ח הוא מתודולוגיה פתוחה (נוהל-מסגרת) אשר מצפה שהמשתמשים יעשו בה"שימוש מושכל", יבינו את עקרונות השיטה, ייצמדו לעיקר וירגישו חופשיים לפעול במסגרת הנוהל בכלים ובשיטות המקובלים עליהם והמתאימים לסביבתם הטכנית והארגונית.

מפת"ח איננו מחייב אימוץ טכניקות וכלים מסוימים. אדרבא, בכוונה ברורה הושאר מרחב פתוח, המאפשר שילוב עם טכניקות וכלים קיימים. במקומות רבים בהם הותקן מפת"ח בוצעה התאמה בין הנוהל וכלי הפיתוח והתחזוקה והנהלים המקומיים, באופן פשוט. פתיחותו של מפת"ח מאפשרת לשלבו בקלות בכלים שבארגון. מפת"ח איננו כלי CASE והוא יישאר כזה גם במהדורות הבאות שלו. מפת"ח הוא מעיןPreCASE שתפקידו לסייע לכלי ה- CASE שבארגון, לא להחליף אותם. זאת ועוד: בשלב בקשה להצעות יש לקחת בחשבון, בין השאר, גם את הכלים והשיטות להנדסת תוכנה המוצעים ע"י הספק ולשקללם בהערכה הכוללת של ההצעה. חשוב כמובן לוודא שכלים ושיטות אלה מותאמים לעבודה לפי מפת"ח. בשוק קיימים כבר מספר כלים המותאמים לעבוד בשיטת מפת"ח. קביעה זו נכונה גם לבחירת יועצים לאפיון ובדיקות מערכת כמודגש בקיטים אלה, בסעיפים הדנים בבחירת יועץ.

פתיחות מפת"ח והיותו נוהל-מסגרת מומחשים גם בתיקי העבודה. בפירוט ובהנחיות הרבות שתיקים אלה מכילים יש דגש רב על התוצרים, ופחות על האופן בו יש להגיע לתוצר או על הטכניקה והכלים בהם יש להשתמש.

בנוסף ליכולת השילוב עם כלים, יש לנוהל-מסגרת מספר יתרונות חשובים:

 

 ·         דגש עיקרי על המוצר (ה"מה") ופחות על התהליך (ה"איך"),

 ·         נוהל-מסגרת "מלחיץ פחות" ומשאיר מרחב מחיה לשיטות עבודה מקומיות ולסגנון אישי,

 ·         התאמה לתפיסת המערכות הפתוחות (open systems),

 ·         שמירה על השקעות קיימות.

 

יתרונות אלה משמעותיים במיוחד עבור גופים ציבוריים גדולים, דוגמת הממשלה, שכן הם מסייעים למימוש מדיניות מחשוב המושתתת על העקרונות הבאים:

 

 ·         מגוון חומרה/תוכנה ואי-תלות ביצרן אחד,

 ·         שימוש מוגבר בתקינה,

 ·         מרכוז נהלים ותקנות מול ביזור יישומים ותפעול,

 ·         ניצול טכנולוגיות חדישות וכלכליות,

 ·         הסתייעות בסיוע חיצוני - ספקי חומרה/תוכנה.