עץ מערכת אוניברסלי

מבוא - הסבר כללי

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

 ·         היא עקבית לאורך כל מחזור החיים.

 ·         היא מתאימה למגוון רחב של מערכות ממוחשבות.

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

 ·         הדגשה/אי הדגשה של רכיבים בעץ המערכת בשלבים השונים של מחזור החיים (השפעת מחזור החיים)

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

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

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

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

 

עץ מערכת אוניברסלי

רמה שנייה

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

1. יעדים

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

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

1.3 בעיות

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

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

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

1.7 אופק הזמן

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

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.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.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 עלות כוללת ופריסה

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

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

 

הנחיות עבודה

להלן הנחיות מעשיות לעבודה עם גלופת עץ מערכת ברמה השנייה:

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

             ·         רכיב 2.5/2.6 תהליכים וטרנזקציות

             ·         רכיב 3.30/31 תקשורת פרטית מקומית ורחבה

             ·         3.9 – 3.1 מחשב שרת – חומרה

             ·         3.15 – 3.10 מחשב שרת - תוכנה

2.       רצוי להפנות מרכיב לרכיב על מנת לקצר ולמנוע חזרות מיותרות, כגון:

             ·         רכיב 1.3 בעיות - הפנייה לרכיב 1.2 מטרות

             ·         רכיב 2.2 תיחום חיצוני - הפנייה לרכיב 2.22 ממשקים

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

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

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

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

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

 

רמה שלישית

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

עץ המערכת רמה שלישית מכיל "רכיבים נוספים" כגון:

 ·         0.X - הבהקים,

 ·         98.X – חלופות

 ·         99.X - דרישות עתידיות.

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

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

 

הנחיות עבודה

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

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

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

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

 

פירוט נוסף

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

 

הרחבות

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

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

קיט תומך הוא קיט המרחיב את הידע בנושא מסוים.

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

מס'	שם הרכיב	הרחבה	קיט תומך
1.3	בעיות	ניתוח בעיות
1.5.1	תכנית עבודה שנתית		תע"ש – תוכנית עבודה שנתית
1.6.1	סיכונים		ניתוח סיכונים
2.4.0	ממשק אדם מחשב		ממשק אדם מחשב HCI
2.7	תיק תכנות	הרחבה	עיצוב ובניה
2.19.1	סיכוני אבטחת מידע	סיכוני אבטחת מידע
2.19.2	אמצעי אבטחת מידע	אמצעי אבטחת מידע	תשתיות אבטחת מידע ארגונית
2.21	נפחים, עומסים וביצועים	נפחים, עומסים וביצועים
3.9	תשתית סביבתית	תשתית סביבתית
3.10	מערכת הפעלה	מערכת הפעלה
3.11	בסיס נתונים	בסיס נתונים
3.12	מילון נתונים	מילון נתונים
3.13	כלי פיתוח ותחזוקה	כלי פיתוח ותחזוקה
3.15	כלי פיתוח וייצור	כלי פיתוח וייצור
3.22	כלים ותוכנות למשתמש קצה	כלים ותוכנות למשתמש קצה
3.30	רשת תקשורת נתונים	רשת תקשורת נתונים	רשתות תקשורת
4.1.4	פרטי הספק	פרטי הספק	בקשה להצעות RFP
4.4	תיק תפעול	תיק תפעול	תפעול
4.6	שירות ותחזוקה	שירות ותחזוקה	תחזוקה
4.7.4	מדריך למשתמש	מדריך למשתמש	הטמעת מערכת
4.8.1	תכנית בדיקה	תכנית בדיקה	בדיקות מערכת

רכיב 2 - ישום

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

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

 ·         גודל המערכת ומורכבותה

 ·         סוג המערכת ואופייה: מקוונת, ייצור, קניינית, מידע וכו'

 ·         סוג היישום (האפליקציה): כספית, לוגיסטית, משאבי אנוש, GIS, רפואית, צבאית וכו'

 ·         סוג הפרויקט: פיתוח מהמסד, תחזוקה, שכתוב, מהדורה / גרסה נוספת.

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

 ·         מתודולוגית הפיתוח

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

מהות היישום - כללי

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

רכיבי היישום המהותיים הם:

 ·         2.1 מאפיינים כלליים: אופי, סוג ומצב כללי של המערכת

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

 ·         2.3 תת-מערכות ופונקציות ראשיות - חלוקה פנימית

 ·         2.4 ממשק המשתמש: מסכים

 ·         2.5 תהליכים

 ·         2.6 טרנזקציות

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

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

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

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

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

 ·         2.12 בסיס הנתונים – מבנה (קבצים) פיסי

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

 ·        2.15 דו"חות ושאילתות

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

 ·        2.22 ממשקים וקישורים (חיצוניים)

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

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

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

 ·         רכיב 2.4 מסכים - User view Oriented

 ·         רכיב 2.5 תהליכים - Process Oriented

 ·         רכיב 2.11 ישויות המידע - Data Oriented

 ·         רכיב 2.11 משולב 2.6 מחלקות התוכן - Object Oriented

 ·         רכיב 2.22 ממשקים ומסרים – Interface &Massaging Oriented

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

מהות היישום - פירוט

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

ללא קשר עם תהליך מחזורי ופתוח זה, והאפשרות שכמעט כל רכיב יהפוך למוביל; אפשר לזהות תת קבוצות ברורות בתוך רכיב היישום:

 ·         רכיבים 2.3 - 2.1 מגדירים את המסגרת והתיחום הכללי של המערכת (חיצוני ופנימי).

 ·         רכיב 2.4 מגדיר את ממשק המשתמש ואת האופן בו הוא רואה את המערכת ועובד אתה.

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

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

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

חלוקה זו כוללת בעיקר שלוש קבוצות ביניים:

1.       ממשק משתמש

2.       כללים עסקיים

3.       מידע

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

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

רכיב 2.2: תיחום חיצוני – משתמשים ומערכות משיקות

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

 מומלץ מאד להיצמד לחלוקה השלישונית של מפת"ח:

2.2.1 משתמשים

 ·          משתמשי פנים (בארגון)

 ·         משתמשי חוץ

2.2.2 מערכות משיקות

 ·         מערכות פנימיות (בארגון)

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

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

 ·         בכל זאת ברכיב זה, בטבלאות תמציתיות: משתמש / מס' התהליך.

 ·         ברכיב 2.5 - עם יכולת הפניה חזרה לרכיב 2.2.

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

כלי עזר לתיעוד רכיב זה הוא תרשים DFD 0, תרשים Use Case Diagram, או טבלאות אקסל.

רכיב 2.3: תיחום פנימי - תת מערכות ופונקציות ראשיות

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

במערכות בינוניות ומטה, ישמש רכיב זה לחלוקת-על של המערכת לפונקציות ראשיות לצורך הבנה ומבט כללי של המערכת. זאת, בעזרת תרשים DFD 1, תרשים Process hierarchy או כל תרשים דומה אחר. רכיב זה ישמש בסיס לחלוקה המעודנת יותר לתהליכים, יחידות תוכנה ומחלקות מידע. הקשר בין רכיב זה לרכיבים המפורטים יותר (2.5 תהליכים או 2.11 מחלקות מידע) יכול להיות:

 ·         קשר היררכי הדוק וצמוד: 2.3.1 מתפרק ל- 2.5.1.1, 2.5.1.2 וכו'

 ·         קשר "רך": התהליכים (או מחלקות המידע) נבנים באופן עצמאי: 2.5.1, 2.5.2 וכו' ולא כפירוק של 2.3. ליד כל תהליך מציינים את הפונקציה הראשית אליה הוא "שייך".

רכיב 2.4: ממשק המשתמש

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

 ·          תמונה כללית וברורה איך יתנהג ממשק המשתמש: פונקציונאלית וחזותית.

 ·         מה הפעולות העיקריות שהמשתמש יכול לבצע במערכת.

 ·         הניווט הכולל של המערכת, היינו, עץ המסכים והמסלולים האפשריים בו (Site Map בלשון האינטרנט)

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

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

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

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

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

 

רכיב 2.5: תהליכים

תהליכים הם "מולקולות", או אובייקטים מורכבים (Composite Classes) המפעילים את הטרנזקציות ומתארים תהליכי עבודה בארגון, כולל בקרה ומשוב. רכיב 2.5 עומד "באמצע" בין רכיב 2.3 ורכיב 2.6. במונחי DFD, רכיב זה מקביל לרמה 1-2. במערכות מקוונות, יש נטייה להעביר את מרכז הכובד (רכיב מוביל) לרכיב  2.6 כולל קישורו ישירות ל- 2.3 ולדלג על רכיב 2.5. דבר זה נכון ומוצדק בעיקר במערכות קטנות ופשוטות. רכיב 2.5 לא ייעלם לגמרי, אלא יוקדש לתהליכי אצווה (Batch): פתיחת המערכת, סגירה, עיבודי סוף/תחילת שנה/חודש, לקיחת גיבויים, התאוששות וכו'.

כלי לתיעוד תהליכים הוא תרשימי DFD, Structure Charts, Block Diagrams, תרשימי Use Case ועוד.

בעולם SOA מדובר הרבה על שירותים (Services). שירותים יכולים "ליפול" ברמת על של התהליכים או ברמה הפרטנית של רכיב 2.3 לעיל.

רכיב 2.6: טרנזקציות

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

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

יש כלים רבים לתיעוד טרנזקציות: תרשימי HIPO, תכנות דמה PDL’s, תרשימי זרימה, Block Diagrams, תרשימי  Sequence Diagrams, Activity Diagrams ועוד.

רכיב 2.7: מודולים

זה רכיב פיסי המיועד לתעד את כל המודולים (תכניות) או קבצי הקוד (Code files) של המערכת. רכיב זה הוא בעיקרו המימוש של רכיב 2.6 טרנזקציות (ודרכן של 2.5 תהליכים), בדומה לאופן שבו רכיב 2.12 קבצים פיסיים מממש את רכיב 2.11 קבצים לוגיים. הקשר של מודולים עם טרנזקציות הוא בעיקרון רבים לרבים (M:M), מודול (קובץ קוד) יכול להכיל מספר מחלקות (טרנזקציות) וטרנזקציה (מחלקה) יכולה להתפצל למספר קבצי קוד. אך למעשה הקשר הוא אחד לרבים (1:M) משום שמודול יכול להכיל יותר מטרנזקציה (מחלקה) אחת, אבל טרנזקציה (מחלקה) לא תתפצל בד"כ בין שני מודולים. ברוב המקרים היחס יהיה אפילו אחד לאחד (1:1). מחלקה או טרנזקציה תמומש בקובץ קוד אחד.

הכוונה העיקרית ברכיב זה היא לתכניות המקור (Source Modules \ Programs), אך רצוי להצביע ברכיב זה גם על ספריות ה- OBJ’s וספריות התכניות להרצה - Exe’s ו- Dll's.

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

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

רכיב 2.8: פרוצדורות בקרה

רכיב זה מתעד את מהלכי הבקרה של המערכת (Control procedures), היינו את המעטפת המתפעלת של המערכת. מהלכים אלה נקראים גם: scripts, פקודות מערכת ההפעלה וכו', בהתאם למערכת ההפעלה הספציפית. תיעוד הרכיב יהיה בדומה לרכיב 2.7 ע"י אינדקס והפנייה לספריות המתאימות. בדומה לרכיב 2.7, גם רכיב זה בא לידי ביטוי בפרט משלב עיצוב ובנייה והלאה. ה"טריגר" להפעלת המהלכים הוא ברכיב 2.4 ממשק המשתמש לעיל וברכיב 4.4 תפעול המערכת להלן.

רכיב 2.9: שגרות – אובייקטים משותפים

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

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

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

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

רכיב 2.10: טבלאות קודים

טבלאות הן ישויות/אובייקטים בסיסיים המופעלים ע"י טרנזקציות ותהליכים. בדומה ל2.9 לעיל, אלה מחלקות תכן ו\או בקרה (אובייקטי תכן או בקרה), לא רק של מערכת זו, אלא ייתכן גם של מערכות אחרות בארגון. באופן מעשי, הכוונה היא לטבלאות קודים (Coding tables) שמכילות פרמטרים ופענוח (לא לבלבל עם המונח "טבלאות" בשפה של בסיסי נתונים טבלאיים שהם בעצם קבצי נתונים). רכיב זה נקרא לעתים גם "טבלאות חיצוניות", בשל היכולת לכוונן ולשנות ערכים בטבלאות, בלי לגעת בתוכניות. ברכיב זה מתועדות הטבלאות כישויות בפני עצמן, ברכיבים האחרים, כגון 2.6 הן רק מאוזכרות ומופנות). בניית הטבלאות תיעשה בכלים דומים לאלה שבונים את רכיבים 2.7 מודולים, או את 2.12 קבצים פיסיים, או בכלים מיוחדים לניהול טבלאות, כגון DPT.

רכיב 2.11: קבצים לוגיים / ישויות / מחלקות מידע

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

רכיב זה הוא מודל הנתונים (Data Modeling) של המערכת. כל ישות / מחלקת מידע מייצגת קובץ מנורמל. לצד הסכמה הכוללת של מודל הנתונים (Global Schema), יתוארו סכמות חלקיות (Partial Schema), בהתאם לצורך (לפי תת מערכות או קבוצות משתמשים).

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

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

רכיב 2.12 קבצים פיסיים / בסיס הנתונים

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

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

רכיב 2.22: ממשקים חיצוניים

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

הרחבות נוספות

פתיחות וגמישות בתוך מסגרת

הדרישה העיקרית של מפת"ח היא שמירה על מבנה אחיד של עץ המערכת, רכיב היישום בפרט לאורך מחזור החיים של הפרויקט. מפת"ח דורש הקפדה על מספור ושם קבוע של כל תת-רכיב - בעיקר ברמה השנייה של העץ, רצוי מאד גם ברמה השלישית. הדגש הוא על התוצר, קרי תכולת המערכת, ועל התיעוד הנלווה, קרי תיק אפיון, תיק עיצוב וכו'. תוצר זה צריך להיות עקבי לאורך מחזור החיים (בהתאם למודל המטריצה) ולשרת את כל השותפים בפרויקט. כל שיטה, מתודולוגיה או תוכנה (כלי פיתוח) אשר יפיקו את התיעוד במבנה עץ המערכת (ושהתכנים יהיו נכונים ושלמים) - מקובלים. "מותר" לכלים או למתודולוגיה (וכמובן לפרויקט עצמו) לקבוע מהו הרכיב המוביל, אילו רכיבים הם מרכזיים ועליהם שמים את הדגש ואילו הם משניים ומכילים אינדקס / הפניות בלבד, בכל שלב של מחזור החיים. זאת ועוד, אפשר להיצמד לחלוקה הגסה יותר של רכיב היישום לקבוצות, ולבנות "ענן" סביב רכיבים 2.4-2.7 - המודל הדינמי, ו\או רכיבים 2.10-2.13 - המודל הסטטי, ובלבד שיהיה ברור היכן נמצא כל רכיב. בתוך הענן יכולה להיות חלוקה פנימית אשר נוחה לכלי ולשיטה, אך שומרת על סרגל מפת"ח ומאפשרת ייחוס פשוט ומהיר לעץ המערכת. קביעה זו נכונה לשלב האפיון ובוודאי לשלב עיצוב ובנייה שם הכלים "עושים את המלאכה". ראה גם קיט עיצוב ובנייה בכרך מחזור חיים של מפת"ח. ראה גם הקיט גישת האובייקטים OO/UML. בסעיף הפניות - Reference להלן יש הפניות לדוגמאות רבות, במפת"ח עצמו, של שינויים והתאמות של עץ המערכת בכלל, רכיב היישום בפרט.

סימול הישויות

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

התאמות עם כלי פיתוח

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

ה- SOW של הפרויקט

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

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

מחזור חיים

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

הפניות - References

רכיב 2 בעץ המערכת - יישום - מכוסה בנוהל מפת"ח במספר מקומות:

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

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

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

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

 ·         בכרך נושאים תומכים:

 ·         בקיט גישת האובייקטים - Object Oriented UML.

 ·         בכרך ניהול פרויקטים:

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

             ·         בקיט מערכות קטנות

             ·         בקיט מערכות גדולות ותת מערכות

 

עצי מערכת ייחודיים ופרטיים

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

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

 

התמחויות

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

מערכות מידע

 ·         לוטוס נוטס  - Lotus Notes

 ·         מיחסון נתונים - Data Warehouse

 ·         מערכות ERP

 ·         מערכות Workflow

 ·         מערכות ארכיב

 ·         מערכות מידע גיאוגרפיות - GIS

 ·         מערכות מידע למנהלים - EIS

מערכות תשתית

 ·         רשתות תקשורת - Networks

 ·         תשתית פיסית - חדר מחשב

 ·         סביבת פיתוח ותחזוקה

 ·         תשתית אינטרנט

 ·         תשתית אבטחת מידע

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

דוגמאות

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

סוגי מערכות

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

 ·         אצווה (Batch)

 ·         טרנזקציות מקוונות (O/L Transaction processing)

 ·         הזנת נתונים (Data entry)

 ·         מחסני נתונים (Data warehouse), מרכז מידע (Information Center) ישירות למשתמשי קצה

 ·         מערכות תומכות החלטה (Decision Support Systems) ומערכות מומחה,

 ·         מערכות ניהול ידע (Knowledgebase Systems)

 ·         ועוד.

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

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

 ·         מערכת תפעולית

 ·         מערכת בקרה ודווח

 ·         מערכת תכנון ומעקב

 ·         ועוד.

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

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

עץ מערכת מקוצר

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

 ·         ראה טופס ייזום בקיט יייזום בכרך יסודות / מחזור חיים.

 ·         ראה קיט אפיון בכרך יסודות / מחזור חיים.

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

 

מאפייני הרכיבים

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

שלשת המאפיינים העיקריים הם:

 ·         תוכן הרכיב: מה הוא מכיל? מה רמת המהימנות של תכולה זו?

 ·         מבנה הרכיב (צורה): מאילו תת-רכיבים הוא מורכב?

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

תוכן הרכיב

מאפיין זה פירושו: "מה מכיל רכיב זה, מה הוא עושה". למשל, בקובץ (רכיבים 2.11 ו- 2.12):

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

 ·         האם ברורים שדות המפתח?

 ·         האם ידוע מקור הנתונים וההיקפים?

או בממשק התפעולי (מסכים, רכיב 2.4):

 ·         האם הוגדרו כל המסכים?

 ·         האם אלה המסכים שהמשתמש צריך?

ובטרנזקציות קלט ועדכון (רכיב X.2.6):

 ·         האם ידועות כל הטרנזקציות?

 ·         האם אלגוריתם הפעולה נכון?

 ·         האם הוגדר הקשר בינם לבין המשתמשים?

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

תוכן הרכיב יכול להיות במספר "רמות מהימנות":

1.       טרם הוגדר

2.       מוגדר ע"י איש מקצוע (מנתח המערכת)

3.       אושר ע"י מומחה היישום (המשתמש/הלקוח)

4.       אושר ע"י הצוות המקצועי, עבר שיקוף מלא לשלמות וסגירות

5.       אושר ע"י הצוות הניהולי - אישור סופי

6.       מאושר בפועל, הרכיב פעיל לפחות 3 חדשים, לשביעות רצון.

מבנה הרכיב (צורה)

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

אמצעי (מדיום) הרכיב

רכיבי המערכת יכולים להימצא באחד מהאמצעים הבאים (לא כל רכיב ימצא בכל אמצעי):

A	בראש של בן-אדם או קבוצת אנשים
B	בנייר, פלט ממעבד תמלילים או כתוב בכתב יד (מלל ותרשימים)
C	ממוכן במעבד תמלילים או כלי גרפי (מלל ותרשימים), Machine Readable
D	באמצעי המאפשר עיבוד ממוכן - Machine Processable (נתונים)
E	באמצעי המאפשר ביצוע ממוכן - Machine Executable (מודולים, מסכי פעולה, שגרות וכו', בכל שפה הניתנת להידור ולביצוע);
F	באמצעי פיסי ממש (חומרה ותשתית).

בפיתוח אבטיפוס, בפרט אבטיפוס "לזריקה" שאינו מיושם על מחשב המטרה (target machine), אפשר לעדן את D ו- E הנ"ל באופן הבא:

D1	עיבוד ממוכן Machine Processable על מחשב האבטיפוס.
D2	עיבוד ממוכן Machine Processable על מחשב המטרה.
E1	ביצוע ממוכן Machine Executable בשפה הניתנת להידור וביצוע, על מחשב האבטיפוס.
E2	ביצוע ממוכן Machine Executable בשפת המטרה על מחשב המטרה.

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

הרכיב בעץ המערכת		אמצעי סופי (הערות)
1.	יעדים	C
2.	יישום
2.1	מאפיינים כלליים	C
2.2	תיחום חיצוני	C,D
2.3	תיחום פנימי	C (במדריך למשתמש)
2.4	ממשק משתמש	C,E (Online Help)
2.5	תהליכים	C
2.6	טרנזקציות	E (Online Help)
2.7	מודולים	C,E (תיק תכנות)
2.8	פרוצדורות (מהלכים)	C,E (תיעוד מובנה)
2.9	שגרות	C,E
2.10	טבלאות קודים	C,D (חלונות)
2.11	קבצים לוגיים	C,D (מודל נתונים ממוכן)
2.12	קבצים פיסיים – Data Base	C,D
2.13	מילון פריטי-מידע (שדות)	D (מילון הנתונים)
2.15	דו"חות	C,E
2.16	קלטים (טפסים)	C,E
2.19	אבטחת מידע	C,D,E
2.20	הצלבות וחיתוכים	C,D (אנציקלופדיה)
2.21	נפחים, עומסים וביצועים	C,D?,E?
2.22	ממשקים וקישורים	C,D
3.	טכנולוגיה	C,F (manuals של היצרן)
4.	מימוש	C,E
5.	עלות	C,E (חשבונאות פנימית)

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

שילוב תוכן (רמת מהימנות) ואמצעי

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

C/1	הוגדר ע"י איש המקצוע בלבד, נמצא במעבד התמלילים
E1/3	אושר ע"י הצוות המקצועי, פועל על מחשב האבטיפוס

ברור שמצב גרוע הוא למשל A0 ומצב טוב למשל הוא E5. ברור גם שרכיב שהמצב הסופי אליו הוא "חותר" הוא D5, למשל, ובשיקוף מתברר שהוא במצב B1, יש להשקיע בו עוד מאמץ והוא רחוק מהשלמה.

שימוש במאפיינים

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

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

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

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

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

הסברים נוספים

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

 ·         האם זהו באמת עץ היררכי פשוט?

 ·         האם יש משמעות לסידור הרכיבים?

 ·         מה מידת הקשרים בין הרכיבים?

 ·         מה קורה לעץ המערכת בפיתוח המערכת והתקדמותה?

 ·         ועוד ועוד

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

אסימטריות וסידור הרכיבים

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

 ·         2.4.0 הנדסת אנוש

 ·         4.8.1 תכנית בדיקה

 ·         1.6.2 עלות/תועלת

גם לסידור הרכיבים אין לייחס משמעות כלשהיא. העובדה שרכיבים 2.5 תהליכים ו-2.6 טרנזקציות מופיעים לפני רכיבים 2.11 קבצים ו-2.13 שדות, אין משמעותה שמפת"ח מעדיף שיטות של ניתוח לפי תהליכים (process-oriented) על פני שיטות של ניתוח לפי נתונים (data-oriented). בוודאי שאין פירושה שזהו "סדר העבודה".

פירוק לרמות נוספות

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

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

מבנה רשת וקשרים בין רכיבים

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

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

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

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

רכיבים אורתוגונליים (רוחביים)

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

הסיבה להכללת רכיבים אורתוגונליים בעץ המערכת (ולא להסתפק ברכיבים הקונקרטיים) היא כפולה:

 ·         חשוב לראות סיכום של תכונות מסוימות במרוכז ובמקום אחד.

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

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