תיעוד

מבוא

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

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

 ·         אמצעי תקשורת והעברת מידע בין השותפים השונים בפרויקט

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

 ·         אמצעי תכנון והערכה

 ·         אמצעי מעקב ובקרה

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

 

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

שיטה נכונה לתיעוד חייבת להתייחס לנושאים הבאים:

 ·         הבחנה בין סוגי התיעוד השונים: מה חשוב יותר ומה פחות

 ·         יכולת המשכיות ובקרה לאחור

 ·         ניהול ספריות ותיקיות

 ·         יכולת תמצות והרחבה

 

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

 ·         עריכת המסמך, כולל שימוש בתבניות וגלופות

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

 ·         שיתוף (Collaboration, Groupware): כתיבה משותפת, סבב הערות ותיקונים

 ·         ניהול תצורה

 ·         אינדקס וחיפוש

 

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

 

 

סיווג התיעוד

סוג ראשון: תפעול מול פיתוח

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

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

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

תיעוד תפעולי

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

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

4.6 נוהל שינויים

4.7.4 מדריך למשתמש

4.4 תיק תפעול

2.7 תוכניות המקור

2.11 הגדרות בסיס הנתונים

רכיבי יישום אחרים: 2.9 שגרות, 2.10 טבלאות, 2.22 ממשקים וכו' – כל מה שנחוץ לתחזוקת המערכת

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

 

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

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

 ·         משתמשים

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

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

תיעוד הפיתוח

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

 ·         מסמך ייזום

 ·         מסמך אפיון

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

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

 ·         מסמכי שלב הבדיקות: תכנית בדיקות, תיק בדיקות, תסריטי בדיקה, תיק סיכום בדיקות וכו'

 ·         תכנית התקנה והרצה, הסבות והדרכות

 

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

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

 ·         תכתובות שונות

 ·         סיכומי דיון

 ·         תכניות עבודה, כולל תכנית איכות, תכנית ניהול תצורה, ניהול סיכונים וכו'

 ·         סקרים

 ·         כתבי מינוי

 ·         חונכות לעובדים חדשים וכו'.

 

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

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

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

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

 ·         אבטחת איכות

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

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

סיווג שני: מנהלה, מחזור חיים, עץ המערכת

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

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

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

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

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

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

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

 ·         נספח 2.1.1 תמצית מצב קיים

 ·         נספח 2.2: פירוט המשתמשים

 ·         נספח 3.20: מחשב הלקוח (קצה)

 ·         נספח 98: נקודות פתוחות

 

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

 

 

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

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

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

2.19 מסמכי אבטחת מידע (תת רכיב: 2.19.1 סקרי סיכוני אבטחת מידע)

2.4 ממשק המשתמש (מסמכי "קונספט" ודגמים)

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

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

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

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

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

 

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

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

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

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

 

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

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

 

 

ניהול ומנהלה

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

מטריצת התיעוד

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

 

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

 

מקרים מיוחדים

שיטות פיתוח וניהול שונות

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

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

 

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

 

תיקיות הפרויקט

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

 ·         תוצרי תיעוד לסוגיהם השונים

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

 

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

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

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

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

 

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

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

 

מטרות התיקייה

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

 ·         ייעול התהליך של ניהול פרויקטים בארגון.

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

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

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

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

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

 

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

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

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

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

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

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

תיקיית מחזור חיים

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

 

תיקיית עץ מערכת

תיקייה זו היא התיקייה "ההנדסית". בתוכה יאחסנו תוצרי הפרויקט עפ"י רכיבי עץ המערכת:

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

תיקיית ניהול ומנהלה

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

 

תיקיות מתמחות

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

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

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

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

השלב הנוכחי במחזור החיים

מפת"ח ממליץ להקים תיקייה כללית עפ"י המפורט לעיל עם תחילת הפרויקט.

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

שיטת הפיתוח והתחזוקה של המערכת

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

 

 

כתיבת תיעוד

הנחיות כלליות

להלן הנחיות כלליות לכתיבת תיעוד לפי שיטת מפת"ח:

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

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

ג.        בקיטים של מפת"ח מצויים לרוב שני סוגים של גלופות:

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

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

             ·         גלופות עבודה

מסמכים הכתובים בכלים לסביבת MS-Office (Word, Excel, PowerPoint, Project) ומטרתם לשמש תשתית לכתיבת התיעוד המבוקש.

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

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

להלן דוגמא לשימוש בשטח "כותרת עליונה" במסמך  Word:

 

 

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

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

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

כתיבת תיקי מערכת

הנחיות כלליות

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

 ·         מסמך ייזום

 ·         מסמך אפיון

 ·         בקשה להצעות – RFP

 ·         מענה הספקים

 ·         תיק עיצוב

 ·         תיק בדיקות מערכת

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

 ·         תיק תחזוקה (תיק מערכת)

 ·         תיק תחקור

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

להלן הנחיות לכתיבת סוג תיעוד זה, בנוסף להנחיות הכלליות לכתיבת תיעוד שהוזכרו כבר לעיל.

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

3.4  ....

3.5  (N)

3.6  ....

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

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

             ·         במסמך ייזום - ¼ עמוד,

             ·         במסמך אפיון - 3 עמודים,

             ·         בבקשה להצעות RFP - 3 עמודים.

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

ג.        לסיומות X.98, X.97, X.0 ו- X.99 יש משמעות מיוחדת המוסברת להלן:

"0.X" בא לציין סעיף כללי: רשימה, הבהקים וכו',

"97.X" בא לציין "אחר",

"98.X" בא לציין נקודות פתוחות וחלופות,

"99.X" בא לציין דרישות עתידיות.

ניתן להוסיף סיומות אלה לכל סעיף בעץ בכל רמה שהיא.

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

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

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

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

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

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

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

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

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

מבנה כללי

המבנה הכללי של כל מסמכי הביניים נראה כך:

 

עמוד שער

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

 

רכיבי התיק

0	מנהלה
0.1-0.5	הסעיפים הרלוונטיים של המנהלה של התיק (השלב)
1	יעדים
1.0	כללי - הבהקים ביעדים
1.1-1.7	רכיבי היעדים הרלוונטיים
1.98	נקודות פתוחות וחלופות כלליות ביעדים
1.99	דרישות עתידיות כלליות
2	יישום
2.0	ארכיטקטורה כללית  של היישום
2.1-2.23	רכיבי היישום הרלוונטיים
2.97	אחר - הערות והרחבות
2.98	נקודות פתוחות וחלופות של רכיב היישום
2.99	דרישות עתידיות ברכיב היישום
3	טכנולוגיה
3.0	ארכיטקטורה כללית של הטכנולוגיה
3.1-3.33	רכיבי הטכנולוגיה הרלוונטיים
3.97	אחר - הערות והרחבות
3.98	נקודות פתוחות וחלופות של רכיב הטכנולוגיה
3.99	דרישות עתידיות ברכיב הטכנולוגיה
4	מימוש
4.0	עקרונות יסוד והבהקים של המימוש
4.1-4.9	רכיבי המימוש הרלוונטיים
4.97	אחר - הערות והרחבות
4.98	נקודות פתוחות וחלופות של רכיב המימוש
4.99	דרישות עתידיות ברכיב המימוש
5	עלות
5.0	תמצית עלויות המערכת
5.1-5.5	רכיבי העלות הרלוונטיים
5.97	אחר – הערות והרחבות
5.98	נקודות פתוחות וחלופות של רכיב העלות
5.99	דרישות עתידיות ברכיב העלות

 

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

 ·         הסעיף לא יעלה על שני עמודים!

 ·         ליד כל "הבהק" תהיה הפניה לרכיב בעץ המערכת המפרט/מממש אותו.

 

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

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

אבטחת איכות

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

בקרה כללית

 ·         מי יצר את המסמך?

 ·         מי הנחה אותו בארגון (צוות ההיגוי המקצועי)?

 ·         עדכניות המסמך: לאיזה תאריך המסמך נכון?

 ·         האם זו טיוטא או מסמך סופי?

 ·         האם המסמך "נכון למהדורה N" של המערכת?

בקרת מבנה

 ·         האם המסמך כתוב במבנה המחייב בנוהל מפת"ח?

 ·         לאילו סעיפים/רכיבים יש התייחסות חלקית/מלאה ולאילו אין?

 ·         האם ישנם סעיפים כלליים: 1.0, 2.0, 2.98 וכו'?

 ·         האם סעיפים אלה גדולים? אם כן, מדוע?

בקרה ברמת רכיב/סעיף

 ·         בדיקת מאפיינים, ראה קיט עץ מערכת אוניברסלי בכרך יסודות

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

כתיבת תמצית מנהלים

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

 ·         ייזום הפרויקט: מסמך הייזום הוא תמצית המנהלים!

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

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

 ·         עיצוב ובנייה: תמצית תיק העיצוב היא גם תמצית מצב הפרויקט,

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

 ·         תחזוקה: תמצית תיק המערכת השוטף (תיק התחזוקה) היא תמצית מצב המערכת והסטטוס הכללי שלה.

 

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

מבנה תמצית מנהלים

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

 ·         מבנה 1 - הקצר ביותר

 ·         מבנה 2 - בינוני

 ·         מבנה 3 - מורחב

 ·         מבנה 4 - נקודת מבט מקצועית

 ·         מבנה 5 - רשימת תיוג מול שיטות שאינן מפת"ח

מבנה 1 - הקצר ביותר

תמצית המנהלים תכיל את סעיפי ההבהקים בלבד:

 ·         1.0 הבהקים ביעדים,

 ·         2.0 עקרונות יסוד וארכיטקטורה של היישום,

 ·         3.0 עקרונות יסוד וארכיטקטורה של הטכנולוגיה,

 ·         4.0 עקרונות יסוד והבהקים של המימוש,

 ·         5.0 עקרונות יסוד והבהקים של עלות המערכת.

כולם או חלקם.

מבנה 2 - בינוני

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

 

1 יעדים

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

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

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

1.3 בעיות

1.7 אופק הזמן

 

2 יישום

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

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

2.3 תיחום פנימי

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

2.19 אבטחת מידע

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

 

3 טכנולוגיה

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

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

3.10 מערכת הפעלה

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

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

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

 

4 מימוש

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

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

4.2 תכנית עבודה

 

5 עלות

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

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

5.2 עלות שוטפת

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

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

מבנה 3 - מורחב

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

 ·         מטרות ובעיות - איחוד רכיבים 1.2, 1.3 ו- 1.6

 ·         תהליכים - איחוד רכיבים 2.2, 2.3 ו- 2.5

 ·         נתונים - איחוד רכיבים 2.10, 2.11 ו- 2.13

 ·         התייחסות כוללת לפרק 3 (טכנולוגיה) ללא פירוט לרכיבי המשנה (3.X)

 ·         המשך פיתוח המערכת - איחוד רכיבים 4.2 ו- 4.3

 ·         תפעול המערכת ותחזוקתה - איחוד רכיבים 4.4 ו- 4.6

מבנה 4 - נקודת מבט מקצועית ((Professional View

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

מבנה 5 - רשימת תיוג מול שיטות שאינן מפת"ח

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

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

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

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

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

 ·         המשתמש (המיוצג ע"י מומחה היישום!),

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

 ·         הדרג הניהולי.

 

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

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

 ·         הצגת הרכיבים תהיה סלקטיבית והדרגתית - אין להראות את כל הרכיבים ב"מכה אחת".

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

תבניות הבסיס של מתודה

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

א.       צורה ואסתטיקה

             ·         אחידות מסמכים

             ·         כל רכיב במקום קבוע ובעיצוב אחיד (תאריך, תוכן, חתימה)

ב.       קלות קריאה וכתיבה

             ·         חוקיות ואחידות

             ·         הבנת הנקרא

ג.        הידור אלקטרוני ופרסום

             ·         זיהוי כל מרכיב להסבה

             ·         קומפילציה אוטומטית

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

סגנונות וטיפוגרפיה

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

 ·         סוג וגודל אות

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

 ·         כותרות

 ·         רשימות ממוספרות ותבליטים

 ·         סימנים מיוחדים

 

הסגנונות מתחלקים למספר קבוצות:

 ·         קבוצת כותרות המסמך

 ·         קבוצת פסקאות לכתיבת טקסט ורשימות

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

בכל קבוצת סגנונות מוגדרות עד שש רמות של כניסת שוליים (Indentation) ומספר הסגנון שונה בהתאמה (Style0 - Style5)

תבניות בסיס למסמכי מפת"ח

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

 

 ·         כותרת מסמך העבודה והמעטפת שלו תהיה ברמה הראשונה (Heading1) ותכיל את סוג המסמך – מסמך (תיק) יזום, תיק תחזוקה וכו'. אחריה, יבואו סגנונות ברמה "0" – Normal  לטקסט רגיל, Listלרשימה ממוספרת וכו'.

 ·         פרקי המסמך יוגדרו כ- Heading2 ויהוו נקודות שבירה שלו לעמודים. כל פרק (פרק מנהלה, פרק יעדים) יתחיל בדף חדש. בהתאמה, שאר הסגנונות אחרי שם הפרק יהיו ברמה 1. הטקסט ב- Normal1והתבליטים ב- B1.

 ·         סעיפי המסמך (1.0 הבהקים, 2.19 אבטחת מידע) יוגדרו כ- Heading3 ואחריהם סגנונות רמה 1, כגון Normal1.

 ·         תת סעיפים (רמה שלישית בעץ המערכת (1.1.1 לקוח עיקרי, 1.2.2 מטרות מעשיות) יוגדרו כ- Heading4 והסגנונות אחריהם ברמה 2 (Normal2 וכד').

 ·         תת-תת סעיפים (רמה רביעית בעץ המערכת (2.4.2.1 מסך תפריט מס' 1, 2.10.1.3- טבלת קודים שלישית) יוגדרו כ- Heading5 והסגנונות אחריהם ברמה 3 (Normal3 וכד').

 

בלשונית תוצרים בקט זה ניתן לצפות ולהוריד תבניות בסיס אלה, המיועדות לעבודה ב Word במהדורות 2007-2010. שם התבניות MethodA_H14, MethodA_E14 (בעברית ובאנגלית בהתאמה)

 

תבנית בסיס לשימושים כלליים

תבניות בסיס אלה נועדו לשימוש בכתיבת תיעוד שאינו מתבסס על עץ המערכת.

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

בלשונית תוצרים בקט זה ניתן לצפות ולהוריד את תבניות בסיס אלה, המיועדות לעבודה ב Word במהדורות 2007-2010. שם התבניות MethodDoc_H14, MethodDoc_E14 (בעברית ובאנגלית בהתאמה)

רצועת הכלים

להגברת היעילות בעבודה עם מעבד התמלילים MS-Word עיצבה חב' מתודה רצועת כלים (Tools Ribbon) בה הותקנו הסגנונות העיקריים בצורת צלמיות (Icons). רצועה זו מאפשרת להחיל בקלות רבה חלק גדול של הסגנונות השכיחים בעת כתיבת מסמכי Word.

תמ"ר - תעוד מונחה רכיבים

הצורך והפתרון

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

 

השיטה מתבססת על:

 ·         תיעוד "בזמן" (JIT) של רכיבים חיוניים בלבד בהתאם לצורך, לתקציב ולמחזור החיים של המערכת

 ·         שיטה אחידה לשימור הידע לתחזוקת המערכת באמצעות תבניות מובנות וקבועות

 ·         ניהול מרכזי של רכיבי התיעוד באמצעות כלים ארגוניים

 

יתרונות השיטה:

 ·         מענה לדרישות עסקיות ורגולטוריות

 ·         שילוב יעיל בכלים לניהול תכנים

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

 

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

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

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

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

·         גורמים מעורבים בתחזוקה (פנימיים וחיצוניים) ·         משתמשי המערכת ויחידות עסקיות ·         יעדים ומטרות ·         הפנייה לחוזי שירות ותחזוקה רלוונטיים ·         פרוט עלויות - תקציב תחזוקת המערכת ·         ישויות המידע העיקריות / תרשימי ERD ·         ממשקי המערכת ·         מסכי המערכת ·         תהליכים

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

התהליך

תמ"ר מורכב מארבעה שלבים:

1.       יצירת הרכיבים

2.       הכנה לשילוב

3.       מאגר רכיבים ארגוני

4.       כלים לניהול ותצוגה

 

יצירת הרכיבים

יש מספר דרכים לייצר את הרכיבים הרלבנטיים, למשל:

 

כלי Office

 ·         עבודה עם רכיבים ייעודיים ותבניות בסיס בכל תוכנות ה- Office  הקיימות

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

 

כלים ייעודיים לבניית טפסים

 ·         עיצוב טפסים ממוחשבים באמצעות תוכנות שונות (Adobe Formcentral; MS InfoPath ועוד)

 

הכנה לשילוב

בניית Metadata

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

 ·         מנגנון אוטומטי לשמירה ואחזור של מאפייני מסמך בכלי ה-Office השונים

 

חוקים לשמות הרכיבים

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

 

תקנים ותקינה

יכולות הטיפול במאפייני הרכיב מאפשר התאמת הרכיבים לתקני כתיבה ועריכה מגוונים (Dita Oasis ואחרים)

מאגר רכיבים ארגוני

 ·         הרכיבים נאגרים במאגר פרויקטלי/ארגוני

 ·         כל רכיב מזוהה באמצעות שמו והמידע המיוחס לו (Metadata)

 ·         כלי הניהול והתצוגה "מתלבשים" על מאגר זה או מייבאים אותו לבסיס הנתונים הייעודי שלהם

 

כלים לניהול ותצוגה

כלי ניהול

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

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

 ·         חיפוש טקסטואלי מלא על מאגר הרכיבים הארגוני

 ·         שליטה אנכית ברמת מערכת על כל רכיביה או אופקית ברמת רכיב על כל מופעיו במערכות השונות

 

בין הכלים ניתן למנות את כלי ה- Office ומגוון כלים ייעודיים כגון SharePoint ועוד. למעשה כל כלי לניהול תכנים ארגוני (ECM) יצלח למלאכה.

 

כלי תצוגה ודיווח

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

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

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