מערכות גדולות ותת-מערכות

כללי, מבוא

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

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

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

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

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

 ·         פיצול לתת-מערכות,

 ·         איחוד ומיזוג למערכת אחת כוללת,

 ·         ביזור והתקנות בהדרגה,

 ·         צורך במענה זריז ומיידי

 ·         קשר לתשתיות בארגון.

הדברים הנ"ל נכונים לניהול השוטף של כל יחידת מחשוב בכל ארגון, אך הם תקפים עוד יותר לארגונים בהם יש "מערכת גדולות" – LSS Large Scale Systems.

 

ההיבט המערכתי

מערכות גדולות הנחלקות לתת מערכות מציגות אתגר ניהולי והנדסי מיוחד:

 ·         כיצד לנהלן?

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

 ·         כיצד לשלב בפיתוח ותחזוקת מערכות LSS שיטות מודרניות של פיתוח בסבבים ויחידות מסירה (Iterative Development)?

 

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

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

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

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

 

אפיון מערכת מסוימת

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

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

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

 ·         2.4 ממשק משתמש.

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

 ·         2.5 תהליכים.

תהליכי העבודה המרכזיים ממשיכים את החלוקה לתת מערכות שברכיב 2.3. כל תהליך משויך באופן ברור לתת מערכת ובין התהליכים יש ממשקים ברורים.

 

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

 

אפיון שתי מערכות נפרדות

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

 ·         בסיס נתונים,

 ·         מילון נתונים,

 ·         קשר עם מערכות חיצוניות,

 ·         טכנולוגיה,

 ·         מימוש וכו'.

 

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

 

חלופות לניהול הפרויקט

מפת"ח מציע שלוש חלופות ראשיות לניהול פרויקט של מערכות גדולות - LSS.

 ·         ריכוז מלא - הכול בתיק (עץ מערכת) אחד תוך הדגשת תת המערכות בכל סעיף וסעיף.

 ·         הפרדה למספר מערכות - אין תיק (עץ מערכת) מרכזי, אלא תיק (עץ מערכת) נפרד לכל תת מערכת תוך שמירה על הרכיבים המקשרים והמשותפים כגון: 2.4 – ממשק המשתמש, 2.13 – פריטי מידע,  2.22 - ממשקים וכו'.

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

 ·          

ריכוז מלא

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

חלופה א-1 חלוקה ברמה השלישית של עץ המערכת

בתת-חלופה זו, השפעת תת המערכות באה לידי ביטוי ברמה השלישית של עץ המערכת. מהתבוננות ברמות 1-2 של העץ (להוציא רכיב 2.3), לא בולטת העובדה שיש תת-מערכות

2.3 תיחום פנימי

 ·         הסבר כללי על החלוקה לתת מערכות

 ·         תרשים קשרים כללי, כגון: DFD 0, Business Processes Activity Diagram וכו'

2.5 תהליכים

 ·         2.5.1 רשימת התהליכים של תת מערכת 1

             ·         2.5.1.X תהליך X של תת מערכת 1

 ·         2.5.N רשימת התהליכים של תת מערכת N

             ·         2.5.N.X תהליך X של תת מערכת N

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

 ·         2.11.1 רשימת הקבצים של תת מערכת 1

             ·         2.11.1.X קובץ X של תת מערכת 1

 ·         2.11.N רשימת הקבצים של תת מערכת N

             ·         2.11.N.X קובץ X של תת מערכת N

 

ובאופן דומה, כל שאר הרכיבים.

חלופה א-2 שימוש בנספחים

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

2.3 תיחום פנימי

·         2.3.1 תת מערכת 1 - תיאור כללי והפניה לנספח 2.3.1

 ·         2.3.X תת מערכת X - תיאור כללי והפניה לנספח 2.3.X

 

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

 

נספח 2.3.1 תת מערכת 1

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

 ·         2.5 תהליכים

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

נספח 2.3.X: תת מערכת X

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

 ·         2.5 תהליכים

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

 

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

הפרדה למספר מערכות

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

באיור הבא מודגמת מטריצה רוחבית - ניהול מערכת LSS

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

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

 

תיק (עץ מערכת) מוביל

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

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

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

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

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

 

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

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

האיור הבא מספק מבט רוחבי על מערכת המורכבת מספר תת-מערכות:

פיתוח בסבבים ויחידות מסירה מיוחדת

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

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

האיור הבא מציג את המערכת הראשית ותת-המערכות שמגיעות "יחד" לקו הסיום:

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

סיכום - שורה תחתונה

כאמור לעיל, ישנם מספר פתרונות לסוגיית מערכות גדולות כמוסבר לעיל:

ריכוז מלא	הכול בתיק אחד תוך הדגשת תת המערכות בכל סעיף וסעיף
ביניים	תיק אחד בתוספת נספחי 2.3.x
הפרדה למספר מערכות	אין תיק מרכזי, אלא תיק נפרד לכל תת מערכת תוך שמירה על הרכיבים המקשרים והמשותפים כגון: 2.22, 2.13 וכו'.
תיק מוביל	תיק מוביל המכיל את התיאור הכללי של המערכת ואת הרכיבים המשותפים ותיק לכל תת מערכת המכיל רק את הרכיבים  המיוחדים לה

 

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

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

תהליך הפיתוח

חלוקה למספר מערכות

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

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

 ·         בשלב האפיון תאופיינה כל תת-המערכות,

 ·         בשלב הבקשה להצעות תוגשנה לספקים כל תת-המערכות וכו'.

 

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

 

שמירה על הגדרה של מערכת אחת

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

החלטה על ביזור/ריכוז

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

 ·         רכיב 1.1 מומחה היישום/הלקוח - יש יותר מאחד?

 ·         רכיב 1.7 אופק הזמן - לכל מערכת אופק זמן שונה?

 ·         רכיב 2.2 הגדרת המשתמשים - יש אשכולות ברורים?

 ·         רכיב 2.3 תיחום פנימי - יש הרבה תת מערכות ובהיקף נרחב?

 ·         רכיב 2.11 קבצים -יש הרבה קבצים ומעט קשרים?

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

 

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

אשכולות (clustering) של משתמשים או מידע, משולבים עם מבנה ארגוני מבוזר הם אינדיקאטור טוב לביזור.

 

ביזור חלקי

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

 ·         רכיבי ההבהקים (X.0)

 ·         רכיב 3.4 - ציוד קצה

 ·         רכיב 4.9 - תצורות

 ·         רכיבים נוספים כגון: 2.3 - תת-מערכות, 3.30 - תקשורת, 3.20 - כלים למשתמש קצה ועוד.