סקרים ושערי איכות

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

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

 

 ·         סטטוס כללי של הפרויקט

 ·         מחזור החיים – תהליך הפיתוח

 ·         עץ המערכת (הרכיבים הרלוונטיים)

סטאטוס כללי של הפרויקט

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

מחזור החיים – תהליך הפיתוח

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

עץ המערכת (הרכיבים הרלוונטיים)

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

מדדי איכות

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

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

 

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

 ·         יעילה - איכותית ובנויה נכון מבחינה הנדסית,

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

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

 

מדדי-איכות אלה מלווים את המערכת לאורך כל הדרך ומשמשים בסיס לכל סקר.

 

 

היכן במחזור החיים

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

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

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

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

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

 

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

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

 

תהליך הסקר

תהליך ביצוע הסקר מורכב ממספר שלבים:

 

 ·         ייזום – העלאת הצורך

 ·         תכנון הסקר

 ·         קביעת המשתתפים

 ·         זימון הסקר

 ·         ניהול הסקר

 ·         סיכום הסקר

 ·         מעקב החלטות

 

ייזום – העלאת הצורך

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

 

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

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

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

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

 ·         מתי נערך הסקר הקודם? האם החלטותיו בוצעו?

 ·         האם אנשי המפתח שבלעדיהם אין טעם בסקר, זמינים?

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

 

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

 

תכנון הסקר

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

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

תכנון הסקר כולל את הפעילויות הבאות:

 

 ·         בדיקה שהתוצר מוכן לסקירה.

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

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

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

 ·         קביעת מיקום ביצוע הסקר.

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

קביעת המשתתפים

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

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

 

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

 ·         בסוג הסקר: סקירה ומצגת, סיעור מוחות, או דיון וקבלת החלטות.

 

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

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

מנהל הסקר

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

 

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

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

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

 ·         אינו חבר בצוות הפיתוח

 

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

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

מתעד הסקר

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

מציג הסקר

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

גודל הצוות

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

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

הרכב הצוות

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

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

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

זימון הסקר

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

טופס (מכתב) הזימון יציין בברור:

 

 ·         הנושא הכללי - מטרת הסקר

 ·         סדר יום ברור - רשימת (תת) הנושאים, לכל (תת) נושא מי המוביל והזמן המוקצב לו

 ·         מיקום הפגישה

 ·         מועד

 ·         חומר לוט

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

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

ניהול הסקר

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

 

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

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

 ·         סבבים ותרבות דיבור - יש להקפיד על תרבות דיאלוג וויכוח:

 ·         סבבי דיון המאפשרים לכל אחד להתבטא.

 ·         מינימום קריאות ביניים.

 ·         רישום הערות בכתב.

 ·         למדבר: אין להאריך בסקירות רחבות. זכור! דקה דיבור ברצף הוא זמן ארוך למדי!

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

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

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

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

כלים ועזרים

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

 

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

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

סדר יום

סדר יום אופייני לניהול הסקר, כולל את הצעדים\פעילויות הבאים:

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

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

 ·         העלאת הערות למוצר

 ·         דיון בהערות וסיכום הליקויים

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

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

             ·         אישור מלא של המוצר שהוצג - ניתנת אפשרות לעבור לשלב הבא וגם אם יש ליקויים הם משניים ויתוקנו ב"תנועה"

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

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

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

 ·         קביעת אחראי מצוות הסקר למעקב אחר ביצוע ההחלטות

תיעוד הסקר

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

 

 ·         מה נסקר

 ·         מי סקר

 ·         מהם הגילויים והמסקנות

 

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

מטרת דו"ח הסקר הנה:

 

 ·         להציג תקלות בתוצר הנסקר

 ·         להציג רשימת משימות למעקב בעקבות הסקר

סיכום הסקר

סיכום הסקר יכלול:

 

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

 ·         רשימת המוזמנים והנוכחים

 ·         שם הפרויקט ופרטי התוצרים שנסקרו

 ·         סיכום הערות שהוצגו ותמצית הדיון

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

 ·         החלטה בדבר אישור התוצר ומהו השלב הבא לביצוע .

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

 

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

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

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

מעקב החלטות

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

טיפים וכללים מנחים

להלן מספר טיפים \ הנחיות לביצוע יעיל של הסקר:

סקור את התוצר ולא את המייצר

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

היצמד לתיעוד ותרשימים

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

היצמד לסדר היום

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

הגבל ויכוחים

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

הצף בעיות תחילה, לא פתרונות

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

הגבל את מספר המשתתפים

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

הגבל את משך הסקר

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

ייצר רשימת תיוג

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

הקצה פעילויות סקרים בתוכנית הפיתוח

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

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

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

 ·         סקר חוזה/סקר משימת פרויקט

 ·         SRR -סקר דרישות מערכת

 ·         SDR -סקר תכנון מערכת

 ·         PDR - סקר אפיון ראשוני

 ·         CDR - סקר עיצוב קריטי

 ·         TRR - סקר מוכנות לבדיקות מערכת

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

 ·         SPRR - סקר מוכנות לייצור

 

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

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

 ·         מטרות הסקר

 ·         עיתוי ביצועו

 ·         תנאי סף לכניסה לסקר

 ·         עיקרי הנושאים להצגה בסקר

 ·         קריטריונים לסיום הסקר

סקר חוזה/סקר משימת פרויקט

הקדמה

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

מטרות סקר חוזה / משימת פרויקט

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

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

עיתוי

סקר חוזה/  משימת פרויקט מבוצע בשני מופעים:

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

 ·        סקר חוזה יבוצע כשלב אחרון לפני יציאה למכרז/בקשה להצעות. סקר זה יבוצע על בסיס מסמכי ההתקשרות (מפרט טכני / אפיון על ומסמךSOW  ו- SLA) אשר הוכנו במהלך השלב האמור.

תנאי סף לכניסה לסקר חוזה / משימת פרויקט

מצע לסקר

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

משימת פרויקט

פורסמה טיוטה של משימת פרויקט ובה פירוט כל מרכיביה

מסמכי התקשרות

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

גורמים משתתפים

הגורמים הקריטיים לסקר זמינים וישתתפו בו.

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

הקדמה

 ·         הצגת יעדי הסקר

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

 ·         פירוט אילוצים ותלויות חיצוניות.

 ·         בסקר חוזה/סקר משימת פרויקט יסקרו כלל ההיבטים של משימת הפרויקט ומחויבויותיהם של כל השותפים בביצוע הפרויקט

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

 ·         הצגת הצורך העסקי כפי שהוגדר במשימת הפרויקט.

 ·         סקירת המערכת

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

 ·         תפיסת התפעול

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

 ·         טכנולוגיה

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

 ·         ממשקים

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

הגדרת פרויקטים ומערכות המשפיעים על פיתוח המערכת וכן מערכות המושפעות מפרויקט זה.

 ·         תכנית עבודה

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

 ·         שילוב, ניסויים ובדיקות

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

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

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

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

 

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

 ·         עץ מוצר

 ·         WBS (Work Breakdown Structure)

 ·         תכנית ILS ראשונית (Integrated Logistics Support - תמיכה כוללת למוצר)

 ·         ניתוח LCC (Life Cycle Cost – העלות הכוללת לרכישה ובעלות של מערכת)

 ·         תכנית GFE (Government furnished equipment – ציוד, חומרה או תוכנה המשמשים ספק חיצוני לארגון לשם ביצוע חלקו בחוזה)

 ·         בטיחות

מחויבות לקוח

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

ניהול סיכונים

זיהוי , אפיון הסיכונים וקיום תכנית לנטרול ולהפחתת הסיכונים.

מדדים

מוצגים מדדים ניהוליים וטכניים רלוונטיים  - מדדי בקרה ומדדי הצלחה כולל יעדים לכל מדד ומדד.

קריטריונים לסיום סקר חוזה / משימת פרויקט

סיכום

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

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

תכנית עבודה

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

מסמכים שיסקרו בסקר

 ·         מסמך משימת פרויקט

 ·         סיכום דיון התנעה

 ·         ניתוח וניהול סיכונים עדכני

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

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

 ·         תכנית ראשונית לניסויים ושילובים.

SRR - סקר דרישות מערכת

הגדרה

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

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

סקר הדרישות מתמקד בתוכן עצמו, קרי, בדרישות המערכת, אך מקובל להצמיד אליו נושאים ותכנים ניהוליים העוסקים בהיבט הארגוני והיערכות הארגון לקראת מימוש הפרויקט. הנושאים הניהוליים יכולים להידון בנפרד במסגרת ועדות ההיגוי /סקרי ניהול (PMR – Project Management Reviews).

מטרות סקר SRR

מטרותיו העיקריות של הלקוח ב- SRR הן:

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

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

עיתוי

 

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

 ·         פרויקט בפיתוח עצמי

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

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

 ·         פרויקט בפיתוח ע"י ספק חיצוני (Outsourcing)

 

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

 

 

תנאי סף לכניסה לסקר SRR

מצע לסקר

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

מסמכי לקוח

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

מסמך דרישות – טיוטת אפיון על

 ·         מסמכי ניתוח הדרישות המהוות טיוטה לאפיון-על. מסמך ניתוח הדרישות נקרא SRS (System Requirement Specifications)) או IRS (Interface Requirement Specifications)) לגבי דרישות הממשקים (נספח 2.22).

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

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

 ·         עלויות - הגדרת יעדי עלות (LCC)

מסמכים נוספים, ניהוליים

 ·         מסמך תכולת עבודה SOW

 ·         חוזה

 ·         תכנית פיתוח ואיכות

גורמים משתתפים

הגורמים הקריטיים לסקר זמינים וישתתפו בו

עיקרי הנושאים להצגה בסקר SRR

הקדמה

 ·         הצגת יעדי הסקר

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

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

 ·         פירוט אילוצים ותלויות חיצוניות.

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

דרישות

 ·         זיהוי הדרישות

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

 ·         ניתוח הדרישות

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

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

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

 ·         עקיבות

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

 ·         טכנולוגיה

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

 ·         שילוב, ניסויים ובדיקות

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

 ·         גאנט הפרויקט

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

 ·         תכנית הפיתוח ואבטחת האיכות

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

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

 ·         מחויבות לקוח

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

 ·         ניהול סיכונים

זיהוי, אפיון הסיכונים וקיום תכנית לנטרול ולהפחתת הסיכונים.

 ·         ניהול סיכונים

זיהוי ואפיון הסיכונים וקיום תכנית לניהול סיכונים ולהפחתתם.

 

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

 ·         עץ מוצר

 ·         WBS (Work Breakdown Structure)

 ·         תכנית ILS ראשונית

 ·         תכנית GFE

 ·         בטיחות

קריטריונים לסיום ה- SRR

סיכום

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

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

 ·        קיימת הסכמה לגבי לוחות זמנים, עלויות וסיכונים

תכנית עבודה

 ·        המשימות הקריטיות שזוהו וסוכמו במהלך ה SRR הוערכו ונקבעה תכנית להשלמתן

 ·        הוגדרו המשימות שאי השלמתן במועד יגרור דחייה בביצוע השלב הבא

SDR - סקר תכנון מערכת

הגדרה

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

מטרות סקר SDR

מטרותיו העיקריות של סקר תכנון מערכת הן:

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

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

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

עיתוי

סקר תכנון מערכתי  (SDR) יבוצע לאחר סקר דרישות SRR.

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

 ·         שילוב  עם סקר SRR (דרישות) ו/או סקר החוזה.

 ·         שילוב סקירת התכנון המערכתי בסקר PDR (בשלב האפיון).

מסמכים להצגה לקראת הסקר

 ·         סקר חלופות לפתרון (נספחי X.98 בתיק המערכת)

 ·         מסמך קונספט התכן הנבחר

 ·         מסמך הגדרת הממשקים החיצוניים (נספח 2.22 ממשקים וקישורים)

 ·         ניתוח פערי הידע וניתוח סיכונים

 ·         תוצאות סקר טכנולוגיות עיקריות

משתתפים בסקר SDR

תנאי סף לכניסה לסקר SDR

מצע לסקר

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

מסמכי לקוח

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

 ·         מסמך ניתוח דרישות

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

סיכום SRR

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

ארכיטקטורה

מסמך הכולל:

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

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

 ·         סיכונים ואילוצים.

ממשקים חיצוניים

מסמך הכולל תיאור ראשוני של הממשקים החיצוניים למערכת.

מסמכים נוספים/ ניהוליים

 ·         מסמך תכולת עבודה SOW

 ·         חוזה

 ·         תכנית פיתוח ואיכות.

גורמים משתתפים

הגורמים הקריטיים לסקר זמינים וישתתפו בו.

עיקרי הנושאים להצגה בסקר SDR

הקדמה

 ·         הצגת יעדי הסקר

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

 ·         סקירת אילוצים ותלויות חיצוניות.

תפיסת התכן

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

 ·         הצגת החלופות השונות שנבחנו והשיקולים לבחירה.

 ·         ממשקים

הצגת ממשקים פנימיים וחיצוניים.

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

 ·         אימות ועקיבות

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

 ·         תכנית עבודה

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

 

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

 ·         עץ מוצר מעודכן.

 ·         WBS (Work Breakdown Structure) מעודכן.

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

 ·         פרמטרים מבוקרים.

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

 ·         משמעויות דיגומים והתקנות.

קריטריונים לסיום ה- SDR

סיכום

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

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

תכנית עבודה מעקב משימות

 ·         המשימות הקריטיות שזוהו וסוכמו במהלך ה- SDR הוערכו ונקבעה תכנית להשלמתן.

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

עדכון מסמכים

עדכון פרק 3 –  טכנולוגיה בתיק המערכת  ורכיב 2.22 ממשקים וקישורים.

PDR - סקר אפיון ראשוני

הקדמה

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

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

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

מטרות סקר PDR

מטרותיו העיקריות של סקר PDR הן:

 ·         תיאום צפיות בין צוות פיתוח הפרויקט לבין הלקוח.

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

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

 ·         אישור האפיון הראשוני ותכנית הבדיקות (STP)  ע"י הלקוח.

עיתוי

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

 

תנאי סף לכניסה לסקר PDR

מצע לסקר

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

בקרת משימות

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

מסמך אפיון העל

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

STP

Software Test Plan, תוכנית הבדיקות (נספח 4.8.1) אושרה.

תכנון הפיתוח והאיכות

תכנית הפיתוח והאיכות עדכנית ומלאה.

גורמים משתתפים

הגורמים הקריטיים לקיום הסקר זמינים וישתתפו בו.

עיקרי הנושאים להצגה בסקר PDR

הקדמה

 ·         הצגת יעדי הסקר

 ·         סקירה כללית של המערכת (יעדים, מטרות)

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

 ·         פירוט אילוצים ותלויות חיצוניות.

 

אפיון ראשוני

 ·         ארכיטקטורה

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

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

תיאור הפתרון הראשוני - מרכיבי המערכת וחלוקתה לתת-מערכות, רכיבי חומרה (HWCI) ותוכנה (CSC ו CSU), כולל שימוש בתרשימי בלוק, תרשימי זרימה וכדו'.

במערכות חומרה – גם עץ מוצר ו- WBS

 ·         תיאור פונקציונאלי

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

 ·         ממשק משתמש

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

 ·         תשתיות

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

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

הצגת מבנה כללי של בסיסי נתונים והקשרים ביניהם

 ·         אבטחת מידע

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

 ·         ממשקים

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

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

             ·         תרשימים חשמליים, תכנון מכני ומיפוי תרמי.

             ·         בדיקתיות ומנגנון  BIT ( Built In Test).

             ·         חיזוי אמינות.

             ·         ניתוח ביצועים ופרמטרים מבוקרים.

             ·         תכנית תאימות אלקטרו מגנטית

             ·         תכנית תנאי סביבה

             ·         תחזוקתיות ותחליפיות (רכיבים חליפיים), כולל רשימת רכיבים קריטיים.

             ·         מפרטי התקנות.

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

             ·         שרידות

             ·         מערכות ניטור, גיבוי והתאוששות (כולל DRP).

 ·         תפיסת התפעול והתחזוקה

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

 ·         בטיחות

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

 

אימות ועקיבות

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

תכנית בדיקות, שילובים וניסויים

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

תכנון הפיתוח והאיכות

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

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

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

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

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

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

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

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

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

 ·         מדדים

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

 ·         ניהול סיכונים

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

מחויבות לקוח

סטאטוס פעילויות ומחויבויות של הלקוח

GFE

סטאטוס תכנית הספקות GFE

LCC

הצגת ניתוח LCC מעודכן למערכת

ניהול הרכש

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

קריטריונים לסיום ה- PDR

סיכום

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

תכנית עבודה

 ·         המשימות שזוהו וסוכמו במהלך ה- PDR הוערכו ונקבעה תכנית להשלמתן, כולל לו"ז ואחראי לביצוע.

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

מסמכים שיש להציג / לאשר בסקר

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

 ·         מסמכי אפיון של ממשקים חיצוניים ופנימיים.

 ·         תכנית פיתוח ואיכות.

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

 ·         תכנית אב לשילובים

 ·         תכנית בדיקות וניסויים (STP).

CDR - סקר עיצוב קריטי

הקדמה

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

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

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

מטרות סקר CDR

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

 ·         הקפאת תצורת המערכת והממשקים.

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

עיתוי

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

 

קריטריונים לכניסה לסקר CDR

מצע לסקר

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

בקרת משימות

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

מסמכי הסקר

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

גורמים משתתפים

הגורמים הקריטיים לסקר זמינים וישתתפו בו.

עיקרי הנושאים להצגה בסקר CDR

הקדמה

 ·         הצגת יעדי הסקר

 ·         סקירה כללית של המערכת (יעדים, מטרות)

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

 ·         פירוט אילוצים ותלויות חיצוניות.

אפיון מפורט

 ·         עיצוב

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

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

יודגשו שינויים, תוספות והשמטות שאושרו מאז ה- PDR.

 ·         ממשקים

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

 ·         ממשק משתמש UI

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

 ·         תשתיות

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

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

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

 ·         תכנית בדיקות, שילובים וניסויים

הצגת עדכונים לתכנית השילובים, הניסויים והבדיקות הראשונית הנסמכת על מסמך תכנית הבדיקות (STP)

 ·         תכנית הפיתוח והאיכות

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

 ·         ILS

הצגת תמיכה כוללת למוצר

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

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

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

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

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

 ·         כלים ונהלים

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

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

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

מדדים

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

ניהול סיכונים

זיהוי , אפיון הסיכונים וקיום תכנית לנטרולם ולהפחתתם.

מחויבות לקוח

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

נושאים נוספים בפיתוח מערכות חומרה

 ·         תאור מפורט של התאמות החומרה שבוצעו בציוד מדף (COTS)

 ·         פירוט יכולת העמידה בדרישות מפרטי המערכת והצבעה על חריגות צפויות.

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

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

 ·         הגדרת ניסוי בדיקת דגם ההנדסה.

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

 ·         עדכון עץ המוצר.

 ·         WBS מעודכן.

קריטריונים לסיום ה- CDR

סיכום

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

תכנית עבודה

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

 ·         הקפאת עיצוב המערכת

 ·         אישור לתחילת ביצוע שלב הבנייה.

מסמכים שיש להציג בסקר

 ·         מסמך אפיון מפורט / עיצוב

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

 ·         מסכים, דוחות ותרשימי תצוגות.

 ·         תכנית תמיכה, תחזוקה ותפעול  מעודכנת.

 ·         תכנית פיתוח ואיכות עדכנית.

TRR - סקר מוכנות לבדיקות מערכת

הקדמה

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

מטרת סקר TRR

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

עיתוי

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

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

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

 

ניתן לערוך סקר מוכנות במתכונת זו גם לפני בדיקות קבלה (ATP).

 

 

תנאי סף לכניסה לסקר TRR

מצע לסקר

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

בקרת משימות

משימות מסקרים קודמים הרלוונטיות לשלב הבדיקות, בדגש על  PDRו- CDR הושלמו בהצלחה.

STP

תוכנית הבדיקות ( STP) אושרה.

STD

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

גורמים משתתפים

הגורמים הקריטיים לקיום הסקר זמינים וישתתפו בו.

אישור ביצוע Unit Tests ובדיקות אינטגרציה

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

בדיקות מקדימות

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

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

עיקרי הנושאים להצגה בסקר TRR

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

 ·         קיימת תוכנית בדיקות מפורטת הכוללת לו"ז.

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

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

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

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

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

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

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

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

מדדי הצלחה לבדיקות

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

 ·         הצגת תוצאות בדיקות האינטגרציה (integration testing)

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

יוצגו מגבלות השימוש בסימולטורים ובקבצי נתונים

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

אימות ועקיבות

 ·         אימות ועקיבות בין הדרישות לבדיקות

הצגה של טבלת העקיבות (Traceability Matrix) המוכיחה כי כל דרישות המערכת הנבחנות בסבב הבדיקות הרלוונטי מכוסות בתסריטי בדיקה.

 ·         ניהול שינויים

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

סביבת הבדיקות

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

ניהול סיכונים

הצגת תוכנית ניהול סיכונים מעודכנת לשלב הבדיקות.

קריטריונים לסיום ה TRR

סיכום

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

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

תכנית עבודה

המשימות הקריטיות שזוהו וסוכמו במהלך ה- TRR הוערכו ונקבעה תכנית פרטנית להשלמתן.

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

 

מסמכים שיוצגו ויאושרו בסקר TRR

במהלך הסקר יסקר ו/או יאושר סופית תיק בדיקות המערכת אשר יכלול:

 ·         תוכנית בדיקות STP

 ·         מסמך תרחישי/ תסריטי בדיקות (STD)

 

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

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

הקדמה

סקר סיכום בדיקות תוכנה ((STR- Software Test Review הנו אבן דרך במחזור החיים של הפרויקט המציין את סיום שלב בדיקות התוכנה.

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

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

מטרת סקר STR

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

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

עיתוי

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

תנאי סף לכניסה לסקר STR

מצע הסקר

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

תיק סיכום בדיקות

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

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

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

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

 

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

משתתפים

הגורמים הקריטיים לסקר זמינים וישתתפו בו.

עיקרי הנושאים להצגה בסקר STR

תיאור כללי של המערכת

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

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

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

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

 ·         רשימת הנושאים שנבדקו

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

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

ממצאי הבדיקות

 ·         ריכוז התקלות שנתגלו והמשמעויות הנובעות מהן.

 ·         פילוח התקלות לפי סבב/ סוג/ חומרה/ קטגוריה...

 ·         סיווג התקלות לפי תקלות תוכנה, תקלות תשתית, חומרה וכדו'.

מדדי איכות

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

המלצות להמשך לקראת בדיקות הקבלה (ATP)

החלופות להמשך הן:

 ·         התקנה מיידית של המערכת כמות שהיא (as-is)

 ·         התקנה מיידית וביצוע תיקונים תוך כדי תפעול שוטף

 ·         התקנה רק לאחר ביצוע התיקונים ובדיקה חוזרת

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

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

קריטריונים לסיום ה STR

סיכום

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

החלטה

קיימת הסכמה לגבי המשך העבודה.

תכנית עבודה

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

SPRR - סקר מוכנות לייצור

הקדמה

סקר מוכנות לייצור – SPRR – System Production Readiness Review הנו אבן דרך במחזור החיים של הפרויקט המציין את סיום בדיקות המערכת. בסקר SPRR יציג צוות פתוח הפרויקט את עיקרי התוצרים והפעילויות הנדרשים לקראת העברת המערכת לייצור או במילים אחרות – להביא את המערכת למצב שיפעלו בסביבת הייצור באתר הלקוח כחלק שוטף של פעילות הארגון.

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

מטרת סקר SPRR

מטרותיו העיקריות של סקר SPRR הן:

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

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

עיתוי

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

 ·         לאחר ביצוע מבדקי קבלה (ATP), גם במקרה שזה התקיים באתר הלקוח.

 ·         לקראת התקנה/פריסה בסביבת הייצור.

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

תנאי סף לכניסה ל SPRR

מצע לסקר

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

דו"ח סיכום בדיקות

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

מסמכי הסקר

נכתבו ההוראות לקראת הסקר.  (הוראות יכולות לקבל אישור במסגרת הסקר):

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

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

גורמים משתתפים

הגורמים הקריטיים לסקר זמינים וישתתפו בו.

עיקרי הנושאים להצגה ב- SPRR

הקדמה

 ·         הצגת יעדי הסקר

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

 ·         בקרת משימות

משימות קודמות הרלוונטיות לשלב המעבר לייצור הושלמו בהצלחה.

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

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

העברה לייצור

 ·         מוכנות תשתיות וסביבת הייצור

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

 ·         פעולות הכנה

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

 ·         מיפוי רכיבים מותקנים

פירוט כל הרכיבים (או רכיבים עיקריים שיועברו לסביבת הייצור במסגרת העברה לייצור. לדוגמא קבצי INI קבצי BAT, וכו'

 ·         שלבי העברה לייצור

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

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

 ·         ניהול הרשאות

יפורט הטיפול בנושא ניהול ההרשאות בסביבת הייצור.

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

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

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

בדיקות  חסינות של המערכת בפני פריצה, DOS (Denial of Service, זליגת נתונים וכו'

 ·         יישום לקחים

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

 ·         השפעות צפויות

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

 ·         תכנית נסיגה

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

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

 ·         הדרכות

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

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

 ·         נהלים

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

 ·         מרכז תמיכה

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

 ·         אמנת השירות

SLA

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

 ·         ניטור

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

יוגדרו thresholds  להבטחת תפקוד תקין והתרעות מוקדמות לפני קרות תקלות.

 ·         תמיכה

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

 ·         גורמים מאשרים

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

 ·         קריטריונים להצלחה

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

 ·         מחויבות לקוח

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

 

ניהול סיכונים

זיהוי , אפיון הסיכונים וקיום תכנית לנטרול ולהפחתת הסיכונים.

קריטריונים לסיום ה- SPRR

סיכום

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

 ·        קיימת הסכמה לגבי ת"ע המוצעת בסקר, קיימת הסכמה לגבי לוחות זמנים, עלויות וסיכונים.

תכנית עבודה

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

סקרי עץ מערכת

סקרים הסוקרים את עץ המערכת – היינו תכולת המערכת – הם משלושה סוגים:

 ·         כלליים

 ·         פרטניים: רכיבים ספציפיים של העץ

 ·         אורתוגונליים - רכיבים החוצים את העץ

סקר כללי של עץ המערכת

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

בקרה כללית לתיק המערכת העדכני

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

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

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

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

 ·         האם זו טיוטה או מסמך סופי? האם הוא מנוהל תחת בקרת שינויים?

 ·         האם המסמך נכון למהדורה N של המערכת (איזו)?

 ·         האם חלו במסמך שינויים מהסקר הכללי האחרון? מהם בקצרה?

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

 ·         האם ישנם סעיפים כלליים: 0.X, 98.X, 99.X? האם סעיפים אלה גדולים? אם כן, מדוע?

 ·         האם צורפה למסמך תמצית מנהלים?

בקרה כללית למערכת הפיסית

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

 ·         האם יש הגדרה ברורה של ספריות עבודה ונהלי העברה וקטלוג?

 ·         האם מתקיים ניהול תצורה שוטף?

 ·         האם המודולריות הכללית של המערכת וחלוקתה לתת מערכות ותהליכים ראשיים (רכיבים 2.3 ו- 2.5) ידועה? האם השתנתה לאחרונה? מדוע?

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

 ·         מה מצב עץ המסכים (2.4)?

 ·         מה מצב הטבלאות (2.10)?

 ·         מה מצב בסיס הנתונים הלוגי והפיסי (2.11, 2.12)?

 ·         מה מצב אבטחת מידע (2.19)? האם יש שינויים/דרישות מיוחדים?

 ·         מהו היקף המערכת, נפחים, עומסים וביצועים (2.21) נכון לרגע זה?

 ·         מה מצב הממשקים (2.22)? האם קשרי המערכת עם מערכות חיצוניות אחרות ידועים ומתועדים היטב? האם השתנו לאחרונה? מדוע?

 ·         מה קורה עם הטכנולוגיה (3)? מה הוזמן? מה נרכש? מה הותקן?

 ·         מה מצב המימוש (4)?

 ·          

 

סקר מפורט של עץ המערכת

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

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

בקרה מפורטת לתיעוד עץ המערכת

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

בקרה מפורטת למערכת הפיסית

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

 

1.       סקירה לפי מאפייני עץ המערכת, שהם:

             ·         תוכן הרכיב

             ·         צורת הרכיב

             ·         רמת הוודאות של הרכיב: בעיות ו"נקודות פתוחות"  - סעיפי 98.X, חלופות?

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

             ·         אמינות הרכיב

למידע נוסף, ראה קיט עץ מערכת אוניברסלי בכרך יסודות\עץ המערכת

כל מאפיין נבדק לפי:

             ·         מצבו הנוכחי (מצב ביניים)?

             ·         התקדמות מהסקר שעבר

             ·         מרחק מקו הסיום?

2.       סקירה לפי ארבעת מדדי האיכות:

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

             ·         יעילות (מבנה הנדסי נכון)

             ·         כלכליות (עמידה באומדן עלויות ולו"ז)

             ·         חוקיות (עמידה בדרישות החוק ומינהל תקין)

3.       מה חשיבותו/תרומתו/ערכו הכולל של הרכיב במערכת:

             ·         האם הוא גורם קריטי (CSF) חיובי?

             ·         האם הוא CSF שלילי?

4.       כמה הושקע בו עד עכשיו?

5.       מי עוסק בו?

6.       שינוי משמעותי בהשוואה לסקר/מסמך הקודם?

7.       היסטוריה (אם נחוץ).

8.       השוואה עם מערכות אחרות בארגון או מחוצה לו.

סקר רכיבים אורתוגונליים

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

 ·         2.19 אבטחת מידע

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

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

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

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

 

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

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

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

סקר קוד

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

 

מטרות ביצוע סקר קוד:

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

 ·         לאתר תקלות שהבדיקות לא גילו

 ·         לשתף ידע בין המתכנתים

 

נקודות לבדיקה בסקר קוד

 ·         האם הקוד עומד בנהלי הכתיבה

 ·         האם ניתן להבין את הקוד מתוך קריאתו

 ·         האם הערות מתועדות עם תאריך

 ·         האם הערות ברורות ונכונות

 ·         האם הערות מתמקדות בהסבר "למה" ולא "איך"

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

 ·         האם ניתן להבין מה פעולה עושה מתוך שמה

 ·         האם שמות הפרמטרים מתארים את תפקידם

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

סקר מהדורה

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

מטרות ביצוע סקר מהדורה

 ·         לוודא תקינות המהדורה לפני הוצאתה

 ·         לתאם בין כל הגורמים המעורבים במהדורה

 ·         לוודא מוכנות הלקוח

 ·          אישור הוצאת המהדורה

 

נקודות לבדיקה בסקר מהדורה

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

 ·         האם קיים דו"ח סיכום בדיקות

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

 ·         האם המהדורה מחייבת הסבות נתונים

 ·         האם מופו כל סביבות ההתקנה

 ·         האם עודכנו תיקי התחזוקה

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

 ·         האם קיימים כל האישורים הנדרשים

 ·         האם בוצעו הדרכות

 ·         האם עודכן מוקד הסיוע בשינויים.

סקר תשתיות

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

 

מטרות ביצוע סקר תשתיות

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

 

נקודות לבדיקה בסקר תשתיות

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

 ·         האם בסיסי הנתונים מוגדרים בצד הלקוח ובצד השרת

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

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

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

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

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

 ·         האם מוגדרת זמינות המערכת

 ·         נפח נתונים הכולל

 ·         צפי גידול שנתי

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

שערי איכות לפרויקט

כללי

שערי איכות (Quality Gates) הם צמתי בקרה ראשיים Go/No Go במחזור חיים של הפרויקט, בהם ממלאים שאלון ועונים על מספר שאלות מרכזיות ומקבלים ציון מספרי או הערכה עבר \ לא עבר.

בעקבות זאת ייתכנו שלושה מצבים:

 

 ·         Go - המשך הפיתוח

 ·         No Go - עצירה

 ·         Conditional Go - המשך בתנאי שתוך פרק זמן מוגדר יתוקנו הליקויים.

 

שערי איכות קלאסיים הם:

 

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

 ·         החלטה על המשך פיתוח - בסוף האפיון

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

 ·         החלטה על העברה לייצור

 

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

 

 ·         אבן דרך - השלמת תוצר (אצל ספק, קבלת תשלום)

 ·         Quality or Project Gate - החלטה על המשך הפרויקט, הקצאת משאבים נוספת

 ·         Checkpoint - בקרה קלנדרית: שבועית, חודשית וכו'.

 

אך למעשה הם כולם דומים אם לא זהים.

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

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

מונחים

 ·         שומר השער (Gate Keeper) - הגורם המחליט לגבי מוכנות הפרויקט לשלב הבא

 ·         מקבל השער (Gate Receiver) - הגורם האחראי על השלב שאליו עובר הפרויקט

 ·         מוסר השער (Gate Provider) - הגורם האחראי למסירת הפרויקט לשלב הבא ולהעברתו למקבל השער

שערי האיכות בפרויקט

מקובל להגדיר מספר שערים עיקריים במחזור חיי הפרויקט:

 

 ·         אישור סופי להתנעת פרויקט

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

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

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

אישור סופי להתנעת פרויקט

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

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

 

 ·         החלטה על ביצוע הפרויקט

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

 ·         החלטה על דחיית הפרויקט.

 

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

מוכנות לפיתוח

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

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

 

 ·         החלטה על מעבר לשלב הפיתוח

 ·         החלטה על מעבר לשלב הפיתוח במועד מאוחר יותר, תוך השלמת חוסרים

 ·         החלטה על חזרה לשלב הייזום

 

מוכנות לבדיקות מערכת

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

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

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

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

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

תהליך ביצוע השער

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

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

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

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

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

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

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

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

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

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

יא.     בכל פגישת שער חייב להיות נוכח נציג הנהלה.

גורמים מעורבים בפגישות / שער

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

גורמים מעורבים: מוסר השער, מקבל השער, שומר השער, אחראי שערים

נוכחות: נוכחות נדרשת, נוכחות רצויה, מכותב  לסיכום הדיון

תוצרים

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

             ·         טופס זימון דיון – ראה גלופת לימוד ועבודה בקיט ניהול פגישות

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

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

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

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

 

סיכום

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

 

 ·         הקיטים אבטחת איכות, מדדים  ובדיקת תיעוד בכרך איכות

 ·         תיק בדיקות בקיט בדיקות, כרך יסודות\מחזור חיים

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

 

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

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

 

אבטחת איכות

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

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

 

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

 ·         האם משתתפים בהם האנשים הנכונים, הקובעים?

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

 ·         אילו נושאים מובאים לסקר? האם יש נושאים שבולטים? סקרים חוזרים?

 ·         אילו קלטים מובאים לסקר? תיעוד? חלקי מערכת?