אפיון מערכת

אפיון מערכת

אפיון מערכת

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

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

מבוא

הגדרות ועקרונות

הגדרה

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

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

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

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

 ·         רשימת תיוג לבחינת פתרונות מוכנים (חבילות תוכנה).

עקרונות

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

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

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

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

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

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

קלט-תהליך-פלט

קלטים לאפיון

 ·         מסמך ייזום

 ·         ראיונות

 ·         מסמכי אפיון דומים

 ·         תכנית עבודה שנתית מאושרת ותכנית אב.

 ·         כל חומר כתוב המתאר את המערכת הקיימת (ידנית או ממוכנת!).

התהליך

ראה סעיף פעילויות - תכנית עבודה להלן במדריך זה.

פלט

תוצר ראשי: ראה תוצר ראשי - תיק אפיון להלן.

לו"ז ומשאבים

לו"ז

בהתאם להיקף המערכת המשוער ולפי מיטב שפיטה כמפורט להלן.

משאבים

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

כללי אצבע:

עלות סבירה של אפיון היא כ- 10%-20% מהעלות הכוללת של הפיתוח.

היקף מערכת

ימי עבודה

משך הביצוע

מערכות בהיקף ג1

עד 20 ימי עבודה

עד חודש

מערכות בהיקף ג2

21 - 100 י"ע

עד שלשה חודשים

מערכות בהיקף ג3

101 - 400 י"ע

עד שישה חודשים

יש לשקול פיצול לתת-מערכות או מהדורות

למעלה מ- 401 י"ע

מעל שישה חודשים

 

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

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

גורם מאשר

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

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

גורם מבצע

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

גורם אחראי

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

גורם מחליט

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

היקף כולל משוער של המערכת1

הגורם המחליט

כשהביצוע פנימי במשרד

כשהביצוע ע"י גורם חיצוני

קטן, ג1 2

הממונה על ענ"א במשרד

ועדת ענ"א המשרדית

בינוני, ג2

המלצת הממונה על ענ"א – אישור הצוות המינהלי

וועדת ענ"א המשרדית - באישור מנכ"ל המשרד3

גדול, ג3

המלצת הצוות המקצועי והצוות המינהלי - אישור מנכ"ל המשרד ואגף3

ועדת ענ"א המשרדית - באישור מנכ"ל המשרד3

 

מקרא לטבלה:

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

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

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

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

 

החלטה - המשך

אלטרנטיבות להמשך

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

 ·         המשך ישיר לעיצוב ובנייה בפיתוח עצמי.

 ·         בקשה מוגבלת להצעות: רכיבים מסוימים בעץ המערכת בלבד.

 ·         בקשה כוללת להצעות: עץ המערכת המלא: חומרה/תוכנה/תקשורת.

 ·         אין-המשך, הקפאת הפרויקט - סגירה מסודרת.

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

תנאים לאי-ביצוע:

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

הגדרת דרישות

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

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

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

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

סקר דרישות (SRR)

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

טיפול בשינויים בדרישות

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

פעילויות - תכנית עבודה

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

הערה: כפי שצוין לעיל, תכנית עבודה זו היא דוגמא בלבד. כל מאפיין יבנה את תכנית העבודה שלו, בהתאם לצרכיי הפרויקט ולכלים שבשימוש אצלו. עם זאת, שים לב שפעילויות ניהול ובקרה וגם פעילויות תוכן רבות, אינן תלויות בכלי שבשימוש. דוגמאות לפעילויות כאלה: 3, 4, 5, 6, 9-13, 16, 17, 27, 31, ועוד. אין קיצורי דרך או "ניסים", גם בכלי הפיתוח (CASE) החדישים ביותר. אם הכלי יודע לנהל גם את תכנית העבודה - יש בכך סיוע רב. אבל את הפעילויות צריך לבצע בדרך זו או אחרת.

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

 ·         התארגנות,

 ·         מעבר ראשון,

 ·         מעברים נוספים,

 ·         אבטחת איכות וסיכום.

מקרא: פעילויות המסומנות ב- [n] הן פעילויות צומת, אבני דרך או סקרים.

התארגנות

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

1 ארגון תיק האפיון ותיקיית הפרויקט

 ·         בניית תיקיה לפרויקט. ניתן להיעזר בדוגמת התיקייה שבקיט זה (לשונית תוצרים/תיקייה)

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

[2] גיבוש הצוותים

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

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

3 העמדת מחשב לפיתוח המערכת

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

[4] בניית תוכנית עבודה לשלב האפיון עצמו

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

 ·         בצע את סבב האישורים לבצוע שלב האפיון ואישור תכנית זו.

פעולה זו מגדירה את רכיב 0 - מנהלה בתיק האפיון.

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

 ·         תכנית ראשונית נכתבת בשלב הייזום (רכיב 4.3 במסמך הייזום).

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

 ·         תכנית העבודה נבנית סופית ועוברת אישור סופי כאן.

אפיון - מעבר ראשון

פעילויות 5-17 להלן מגדירות את סבב האפיון הראשון. אם יבואו אחריו סבבים נוספים, ימשיך האפיון מפעילות 18 והלאה כמתואר להלן. במידה שזה הסבב הראשון וגם האחרון, מבוצע אפיון-על, יש להמשיך בפעילות 23 כמתואר בהמשך. 

5 ראיון נציגות המשרד והלקוח העיקרי

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

6 איסוף כל חומר כתוב ולימודו

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

7 לימוד ותיעוד מצב קיים

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

8 ניהול תצורה ואבטחת איכות

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

9 סיכוני אבטחת מידע - במ"מ

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

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

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

 ·         יחידות הכפופות להוראות רב"מ/במ"ת יפעלו לפי הנחיות אלה.

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

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

10 הגדרה סופית של רכיב היעדים

 ·         אימות סופי של יעדי המערכת ומטרותיה.

 ·         פעולה זו מגדירה את כל תת-הרכיבים X.1 להוציא את רכיב 1.6.

11 חלוקה כללית לתת-מערכות - תיחום פנימי

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

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

[12] (סקר) קביעת המשתמשים

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

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

בין פעילויות 11 ו- 12 יש יחסי גומלין ברורים והסדר ביניהן עשוי להתחלף.

13 סבב ראיונות ראשון

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

ראה גם קיט שיתוף המשתמש בכרך נושאים תומכים.

שיתוף המשתמשים הוא נושא מרכזי בכל שלב במחזור החיים, בשלב האפיון בפרט.

 

14 סיכום ראשון של הנתונים - ניתוח מערכת I

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

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

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

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

 ·         בכיוון דו"חות - מידע נדרש בהקבצות.

 ·         בנייה ראשונית של רכיבים: 2.3, 2.5, 2.11, 2.13, 2.15, 2.22.

[15] בניית עץ המערכת הפרטי - מבנה תיק האפיון הסופי

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

[16] החלטה על שימוש באבטיפוס ובכלים ממוכנים אחרים

יש לקבל החלטות ברורות בנושאים הבאים:

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

 ·         באיזה סוג אבטיפוס משתמשים, אבטיפוס אבולוציוני או אבטיפוס לזריקה. ראה קיט אבטיפוסPrototyping -  בכרך נושאים תומכים.

 ·         מי מאשר את נכונות הרכיבים שנבנו.

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

בניית אבטיפוס במערכות גדולות (ג3), היא חובה.

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

[17] סקר ראשון

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

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

 

מעברים נוספים - אפיון בסבבים

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

18 בניית אבטיפוס

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

19 הגדרה ראשונית של רכיבי הטכנולוגיה והמימוש

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

20 השלמת הגדרת היישום - ניתוח מערכת II

השלמת רכיבים פונקציונאליים

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

 ·         2.3 - תיחום פנימי: חלוקה לתת-מערכות, כולל חלוקה משנית

 ·         2.22 - ממשקים וקישורים: הגדרה מדויקת, כולל היבטים כמותיים

 ·         2.10/2.13 - מילון פריטי מידע וטבלאות קודים: סימולים ופריטי מידע

 ·         2.11 - קבצים לוגיים: הגדרת רשומות

 ·         2.15/2.16 - דו"חות וקלטים

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

 ·         2.4 - ממשק משתמש ודרישות הנדסת אנוש

 ·         2.19 - אבטחת מידע,  בהנחה שסיכוני אבטחת מידע כבר מוגדרים

השלמת רכיבים אורתוגונליים

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

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

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

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

 ·         ועוד.

סגירת/פתיחת נקודות פתוחות 98.X ודרישות עתידיות 99.X

21 הגדרה חוזרת של רכיבי הטכנולוגיה

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

22 הגדרה חוזרת של רכיב המימוש

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

 ·         תכנית עבודה כוללת להמשך (רכיב 4.2 כולל סיכונים, ישימות הפרוייקט רכיב 1.6.1)

 ·         תפעול שוטף של המערכת - רכיב 4.4

 ·         שירות ותחזוקה - רכיב 4.6

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

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

23 כתיבה ראשונה של מסמך האפיון

המלצה לצורת הכתיבה:

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

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

 ·         הדפס והקדש זמן מתאים להגהה עצמית.

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

24 עריכת אומדן עלויות וחקר ישימות

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

[25] סגירת רכיבי x.98 - ניתוח חלופות

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

[26] ביצוע סקרים לאפיון המערכת

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

[27] (אבן דרך) דיון ממצה בצוות המקצועי

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

28 בדיקה של אבטחת איכות

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

29 חזרה על פעילויות 17-28 בעקבות הערות

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

 

מצגות וסיכום האפיון

30 עריכה סופית של מסמך האפיון והגשתו לצוות המעקב המינהלי

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

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

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

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

                         ·         מדגימה מסכים/דו"חות/קלטים עיקריים

                         ·         מכילה תרשימים המציגים את עיקרי המערכת: חלוקה לתת-מערכות וכו'.

[31] (אבן דרך) דיון בצוות המעקב המינהלי

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

32 הפצת מסמך האפיון

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

יש להימנע מהפצה לגורמים חיצוניים העשויים להציע עצמם כספקים לביצוע.

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

 ·         הדפסה נאה

 ·         ניהול רשימת תפוצה ועדכונה

 ·         ראה פעולה דומה בשלב הייזום

[33] (אבן דרך) החלטה על המשך הפרויקט

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

תוצרים

תוצר ראשי - תיק אפיון

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

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

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

בכל מקרה, בין אם האפיון הוא המשך של הייזום ובין אם הוא המשך של התחזוקה, חשוב לזכור "לאן מוביל האפיון" ומה בא אחריו. שתי האפשרויות השכיחות הן:

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

 ·         בקשה להצעות. תיק האפיון הופך למפרט (RFP) במטרה לצאת למכרז.

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

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

הנחיות נוספות לשימוש בתיק האפיון

אין שום סיבה שתיק האפיון לא יהיה בנוי ממספר מרכיבים פיסיים שירוכזו בתיקיית הפרויקט:

 ·         תיק תיעוד

 ·         רכיבים שהוגדרו בכלי פיתוח

 ·         חלקי מערכת ממערכות אחרות

 ·         אבטיפוס

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

 ·         פריטי מידע שהוגדרו במילון נתונים

 ·         עץ מסכים שנבנה בעזרת מחולל מסכים

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

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

 ·         כיצד להתייחס לנקודות פתוחות וחלופות (אלטרנטיבות)

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

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

 ·         אילו רכיבים (סעיפים) במסמך האפיון הם חובה, ואילו - רשות

 ·         מידת הפירוט הסבירה לכל רכיב

 ·         היכן לתייק חומר שונה שנאסף במהלך האפיון (ראה קיט תיקיות הפרויקט בכרך נושאים תומכים)

 ·         כיצד להחיל כללי ניהול תצורה כבר בשלב האפיון.

כל טיוטות מסמך האפיון יכתבו במבנה המסמך הסופי. אין ליצור מבנים אחרים.

 

גלופות תיק אפיון

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

 ·         לגלופות עץ מערכת (רמה 2 ו- 3) - ראה קיט עץ מערכת אוניברסלי בכרך זה.

 ·         לגלופה כללית וגלופות ספציפיות למערכות מידע - ראה כרך מערכות מידע.

 ·         לגלופה כללית וגלופות ספציפיות למערכות תשתית - ראה כרך מערכות תשתית.

מסמך אפיון מקוצר

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

איחוד רכיבים

 ·         1.2 ו- 1.3 עם 1.6 בעיות/מטרות/תועלות

 ·         2.3 עם 2.5 תיחום פנימי ותהליכים

 ·         2.3 עם 2.6 פונקציות המערכת

 ·         2.9 עם 2.10 שגרות וטבלאות

 ·         2.11 עם 2.12 קבצים ומודל נתונים לוגיים ופיסיים

 ·         2.22 עם 2.2.2 להגדיר את הממשקים יחד עם המערכות המשיקות

 ·         3.1 עם 3.2 חמרה מרכזית

 ·         3.3 עם 3.4 ציוד קצה

 ·         3.10 - 3.15 תוכנות בסיסיות

 ·         3.30 - 3.32 תקשורת

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

 ·         4.4 עם 4.6 תפעול המערכת ותחזוקתה.

דילוג על רכיבים

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

 ·         1.4 הקשר ארגוני\עסקי - אם הקשר לתכנית העבודה השנתית ברור

 ·         2.1.4 מילון מונחים - אם המערכת לא מכילה מינוח שונה מהמקובל בארגון

 ·         2.16 קלטים/טפסים - אם הם מועטים ומובנים באופן ברור במסכים

 ·         3.5 ציוד מתכלה - אם צריכת המערכת נמוכה והיא פועלת בארגון גדול

 ·         3.9 תשתית סביבתית - אם צריכת המערכת נמוכה והיא פועלת בארגון גדול

 ·         4.9 תצורות - אם למערכת יש תצורה אחת בסיסית

 ·         5.3, 5.4 עלות תצורות ומחירון - אם אין תצורות ואין הרחבות מיוחדות.

קיצור

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

 ·         2.1 מאפיינים כלליים - במיוחד אם מדובר ביישום חדש

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

 ·         2.20 הצלבות וחיתוכים - להסתפק בחיתוך משתמשים עם טרנזקציות או עם קבצים

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

 ·         2.23 דרישות מיוחדות - אין

 ·         4.7 השתלבות בארגון - אם לא צפויות הדרכות/הסבות מיוחדות.

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

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

 

אבטיפוס

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

בחירת יועץ

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

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

 

השימוש בעץ המערכת

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

 ·         בחירת גורם חיצוני לאפיון

 ·         מכרזי ייעוץ וכ"א

 ·         בניית תכנית עבודה לאבטחת איכות

 ·         בניית עץ מערכת תשתית (כולל) לאבטחת מידע

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

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

להסבר מפורט על תהליך הבקשה להצעות ראה קיט בקשה להצעות - RFP בכרך מחזור חיים

 

בניית המפרט

בניית מפרט ומפ"ל לבחירת יועץ לאפיון מערכת מורכבים מהפעולות הבאות:

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

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

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

כתיבת פרק המנהלה לפי ההנחיות להלן.

כתיבת מפ"ל בהתבסס על גלופות לימוד ועבודה בקיט זה

פרק המנהלה

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

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

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

מפ"ל

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

בדיקת ההצעות והתקשרות

בדיקת ההצעות

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

 ·         דרישות סף (פרק המנהלה כולו ובפרט סעיפים 0.6, 0.7 במפרט)

 ·         כלים ושיטות (סעיף 0.17 במפרט)

 ·         תכנית העבודה המוצעת (סעיף 0.18 במפרט)

 ·         כישורי היועץ וניסיונו (סעיף 0.15 במפרט)

 ·         התרשמות כללית מתגובת הספק למסמך הייזום (סעיפים 1-5 במפרט, מסמך הייזום הלוט)

 ·         עלות ההצעה (סעיף 0.14 במפרט)

התקשרות

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

סיכום - הערות כלליות

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

 ·         כלל אצבע לעלות האפיון: 10%-20% מעלות הפיתוח (המשוערת) הכוללת של המערכת. ראה סעיף משאבים בפרק כללי לעיל

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

אבטחת איכות ומדדים

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

למידע מפורט יותר, ראה הקיט בדיקת תיעוד בכרך איכות.

תוצרים

מומלץ לבדוק את מסמך האפיון לפי רשימת התיוג הבאה:

 ·         קצר מדי? ארוך מדי? שימוש נכון בנספחים והפניות (קישורים) חיצוניים?

 ·         גלישה לעיצוב?

 ·         מי בדיוק הלקוח (יוזם הפרויקט)? מה מידת מחויבותו?

 ·         האם מכיל מספיק מידע על מנת לקבל החלטה להמשך?

 ·         האם ברור מה הצעד הבא ומה משמעויותיו?

 ·         האם קשור בתכנית העבודה השנתית או בתכנית אב (תכנון אסטרטגי)?

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

תהליך האפיון

 ·         כמה סבבים בוצעו?

 ·         עלות\תועלת של כל סבב?

 ·         חריגות מתכנית העבודה?

 ·         חריגות בעלויות

 ·         תרומת האבטיפוס (אם נבנה)

 ·         מס' מהדורות של תיק האפיון שהוגשו

 ·         מס' סבבי דיונים ופגישות

 ·         מעורבות מומחה היישום