מדריך זה מנחה כיצד לתכנן, לנהל ובצע את שלב העיצוב ובנייה. בגישת מפת"ח יש לגורם המפתח יד חופשית מירבית בכל הקשור לתהליך המפורט, לטכניקות ולכלים – בפרט אם קדם לשלב זה אפיון מפורט ו\או בקשה להצעות והתקשרות עם ספק חיצוני, בהם נקבע בצורה מפורטת אופן ביצוע עיצוב המערכת ובנייתה, כולל ת"ע מדויקת, שימוש בכלים ומתודולוגיות וכו'.
מבחינת מפת"ח, הדגש בשלב זה הוא על מעקב ובקרה ואבטחת איכות, היינו, על עריכת סקרים, הקפדה על קיום ת"ע ואבני דרך, בקרת עלויות וסיכונים, בדיקות יחידה, ועוד. ההקפדה היא יותר על המוצר ופחות על הדרך לפיה המוצר נבנה, כאשר חלק בלתי נפרד מהמוצר הוא תיק עיצוב = תיק המערכת. תיק זה ניתן לניהול הן כ"אוסף תאים" בהם מתועדים רכיבי חלקי המערכת המרכזיים (ממשק משתמש, תכניות, קבצים, אבטחת מידע וכו') והן כמכלול המאגד תאים אלה ל"מבט" (view) כולל של המערכת ההולכת ונבנית.
בשלב עיצוב ובנייה מוגדרת המערכת באופן סופי, בעיקר בהיבטים הפיסיים, נבנית, עוברת בדיקות יחידה (Unit test), ומשולבת.
פתיחות מפת"ח, מתבטאת בשלב עיצוב ובנייה, בשלשה תחומים:
· כלים
· מתודולוגיה
· תהליך
פתיחות בכלים נדרשת עקב הסביבה הממוחשבת המיוחדת לכל ארגון. סביבה זו כוללת גם את הכלי לניהול מסמך העיצוב (תיק המערכת) עצמו.
פתיחות במתודולוגיה פירושה שניתן להשתמש במגוון טכניקות לעיצוב מפורט של (עץ) המערכת. מפת"ח איננו מחייב מתודולוגיה זו או אחרת!
פתיחות בתהליך מתבטאת בכך שפרק זה מכיל הגדרה של פעילויות בסיסיות בלבד, מהן יבנה כל אחד את תכנית העבודה שלו. גם ההחלטה אם לאחד את העיצוב והבנייה לשלב אחד או להפרידם לשני שלבים עצמאיים, היא של הפרויקט, חוץ מפרויקטים גדולים (ג3) שם חובה להפריד בין עיצוב לבנייה.
אין פתיחות בתיעוד. חובה להפיק מסמך עיצוב במבנה שלהלן. אפשר לחסוך בעבודת תיעוד פיסית: להסתייע בכלים, להפנות לרכיבים המכילים תיעוד מובנה (Built-in) וכמובן להשתמש בגלופות מפת"ח או בתיק האפיון כבסיס. אך אין לוותר על תיק העיצוב שהוא תוצר מרכזי בבניית המערכת ובסיס לתיק התחזוקה!
עיצוב ובנייה איננו תלוי, בעקרון, אם הגורם המפתח הוא פנימי או חיצוני, היינו, אם השלב הקודם היה אפיון או בקשה להצעות. מה שנדרש מספקים, יש גם לדרשו מעצמנו! לאורך הפרק יש התייחסות ותזכורת בכל מקום בו הבדל זה הוא רלוונטי.
הקלט לתהליך הוא מינימלי/בסיסי:
תיק אפיון מאושר. שים לב לרכיבים: 4.8.1 תכנית בדיקה, 3.13 כלי פיתוח ותחזוקה, רכיבי 98.X ו- 99.X, נספחים: סיכומי דיון וסקרים.
תוספות אפשריות:
· אבטיפוס ודגמים, אם נבנו בשלבים קודמים (באפיון).
· תיקי עיצוב ממערכות אחרות.
אם הביצוע ע"י גורם חיצוני:
· המפרט (אם שונה מהותית ממסמך האפיון),
· הצעת הספק (גם הצעות אחרות שנדחו),
· חוזה ההתקשרות
· תיק מערכת ראשי – SOW, שהוא מיזוג המפרט והצעת הספק, תיק עיצוב ראשוני, נספח טכני לחוזה
ראה פעילויות - תכנית עבודה להלן. ראה גם סעיף 4.2 במסמך (תיק) האפיון (ובהצעת הספק).
תוצר ראשי: מערכת עובדת!
תוצר משני: מסמך (תיק) עיצוב.
הערכה ראשונה של המשאבים נמצאת במסמך האפיון בסעיפים 4.2 ו- 4.3, ואם בוצעה בקשה להצעות גם במפרט ובהצעות הספקים בסעיפים אלה. בהערכת המשאבים יש לכלול גם את עלות הכנסת התיקונים עקב ביצוע בדיקות המערכת.
ביצוע שלב עיצוב ובנייה עצמו:
· אם שלב עיצוב ובנייה הוא המשך לשלב האפיון, ראה גורם מחליט על ההמשך בקיט האפיון.
· אם הוא המשך לשלב בקשה להצעות, ראה גורם מחליט על ההמשך בקיט בקשה להצעות.
צוות מקצועי - יחידת מערכות מידע של המשרד/הארגון או ספק חיצוני כפי שהוגדר בשלבים הקודמים. ראה רכיב 4.2.2 (וגם 4.1) במסמך (תיק) האפיון.
מפקח על ביצוע העיצוב והבנייה ומאשר סיומם: הצוות המנהלי.
על המשך (בדיקות מערכת או התקנה) לפי האלטרנטיבות שבטבלה הבאה.
טבלה זו מיועדת למשרדי הממשלה. ארגונים אחרים יחליפו טבלה זו בנוהל פנימי משלהם
|
היקף כולל משוער של המערכת1 |
הגורם המחליט |
|
|---|---|---|
|
כשהביצוע פנימי במשרד |
כשהביצוע ע"י גורם חיצוני |
|
|
קטן, ג1 |
הממונה על ענ"א במשרד |
הממונה על ענ"א במשרד |
|
בינוני, ג2 |
המלצת הממונה על ענ"א - אישור הצוות המנהלי |
וועדת ענ"א המשרדית - אישור מנכ"ל המשרד2 |
|
גדול, ג3 |
המלצת הצוות המקצועי והצוות המנהלי - אישור מנכ"ל המשרד ואגף התקציבים |
המלצת ועדת ענ"א המשרדית ומנכ"ל המשרד - אישור ועדת ענ"א המרכזית |
מקרא לטבלה
1. ראה הגדרת היקף מערכת בערכה המודל בכרך תכולה ושיטה. מערכות מסוג ג0 ("מוצרי מדף") לא מופיעות בטבלה זו. הטיפול במערכות אלה מפורט בערכה ועדות רכש והתקשרויות בכרך ניהול כולל
2. אישורי מנכ"ל המשרד ו/או אגף התקציבים ניתנים, בד"כ, במסגרת תכנית העבודה השנתית. אישורים אד-הוק לפרויקט, כנ"ל, הם למקרים חריגים
אלטרנטיבות להמשך:
· התקנת המערכת לאחר תיקון הליקויים שהתגלו במהלך העיצוב והבנייה ולאחר מבחני קבלה (אפשרי רק במערכות מסוג ג1 או ג2)
· מבחני קבלה בסיסיים והתקנה מיידית של המערכת כמות שהיא (as is). תיקונים, אם ישנם, יבוצעו בהמשך (אפשרי רק במערכות מסוג ג1)
· ביצוע בדיקות מערכת (במערכות מסוג ג3 - חובה) ומבחני קבלה מלאים
· הקפאת מהדורה נוכחית (שנבנתה) וחזרה לעיצוב, לאפיון או לייזום
· אין המשך. הקפאת הפרויקט (סגירה מסודרת). ראה דיון בנושא במדריך של קיט האפיון
תנאים לאי-ביצוע: אין.
ההנחיות בסעיף זה מיועדות הן לעיצוב ובנייה פנימיים והן לעיצוב ובנייה ע"י גורם חיצוני. במקרה הראשון, יש לפעול עפ"י הנחיות אלה ככתבן וכלשונן. במקרה השני, קיימת כבר תכנית עבודה אשר נדרשה במפרט והוצעה ע"י הספק. ההנחיות שלהלן ישמשו בעיקר למעקב ובקרה ולהשלמות
שלב עיצוב ובנייה, כשמו כן הוא, מורכב משני תת-שלבים עיקריים. בתת-שלב הבנייה ניתן לזהות חלוקה נוספת: בנייה עד רמה של תת-מערכת, כולל בדיקות יחידה (Unit Test) ושילוב של המערכת. מדובר אפוא בשלושה תת-שלבים:
1. עיצוב – פעילויות 1-17
2. בנייה עד רמת תת-מערכת ובדיקות יחידה – פעילויות 18-29
3. שילוב (אינטגרציה) של כל רכיבי המערכת – פעילויות 30-38
כמו בשאר השלבים של מחזור חיי המערכת, גם בשלב זה חשוב התוצר (עץ המערכת) יותר מהתהליך (מחזור החיים). אי לכך, כל תכנית עבודה אשר תביא לתוצאה המיוחלת ולא תחרוג ממסגרת המשאבים והזמן שהוקצו לה, תתקבל. להלן מוצעת תכנית עבודה שלדית, בעזרתה יבנה כל פרויקט את תכנית העבודה המתאימה לו, כולל ההחלטה על החלוקה לתת-שלבים. תכנית עבודה ראשונית צריכה להופיע כבר במסמך האפיון ובהצעות הספקים (סעיפים 4.2 ו- 4.3 שם).
להלן פירוט פעילויות (תכנית עבודה) לביצוע שלב עיצוב ובנייה בחלוקה לשלוש קבוצות פעילויות בהתאם לחלוקה לתת שלבים הנ"ל.
פעילויות המסומנות ב- [n] הן פעילויות צומת, אבני דרך או סקרים.
בתחילת שלב העיצוב יש להכין תיקייה לאחסון תוצרי השלב – ראה דוגמא לתיקייה בלשונית תוצרים בקיט זה.
אם תוצרי הפרויקט מנוהלים באמצעות תיקייה מסודרת מהשלבים הקודמים, יש לעדכן את מבנה התיקייה על מנת ליצור מדורים לשלב זה. ראה גם קיט תיקיות הפרויקט בכרך נושאים תומכים.
· ציוות סופי של צוות מקצועי וצוות מנהלי לשלב העיצוב והבנייה, כולל שינויים לעומת השלב הקודם: הוספת מומחים ובעלי מקצוע מיוחדים: אבטחת איכות, או"ש, אבטחת מידע, הנדסת אנוש, ניהול תצורה וכו' וכמובן מתכנתים. חשוב מאד שמומחה היישום (נציג הלקוח/המשתמש העיקרי) לא יתחלף! רצוי גם שהצוות המנהלי (ועדת ההיגוי) לא יתחלף (או תחלופה מינימלית).
· קבלת מחויבות מצוותי הסיוע הטכני, הוספת יועצים חיצוניים.
· קבלת מחויבות מכל גורם חוץ איתו פועלים. מי יהיה איש הקשר של הפרויקט (POC – Point Of Contact).
ארגון, ריכוז ולימוד כל החומר הקיים ובראשו תיק האפיון. אם השלב הקודם היה בקשה להצעות, יקיף הלימוד גם את המפרט, את ההצעה שנבחרה וגם, אם אפשר, הצעות של ספקים אחרים, כולל תכניות העבודה שהוצעו שם. פעולה זו תכלול גם נושאים טכניים של התמרת החומר והעברה לכלים בהם ינוהל ויבוצע הפרויקט (ראה פעילות 6 להלן).
שילוב תיק האפיון, המפרט, הצעת הספק וכל מידע ותיעוד אחר לכלל תיק מערכת ראשי או תיק עיצוב ראשוני, אשר ישמש בסיס לעיצוב המערכת ובנייתה. תיק זה, אשר נקרא גם מסמך קונסולידציה אוSOW (Statement Of Work) מגדיר את תכולת העבודה כולל נקודות פתוחות ואי הסכמה.
בעבודה עם גורם חוץ, תיק עיצוב ראשוני זה הוא הנספח לחוזה וחלק בלתי נפרד ממנו. אי השלמתו מעכבת את חתימת ההתקשרות. נושא זה מוסבר בהרחבה בסוף המדריך בקיט בקשה להצעות RFP בכרך זה.
עבור על כל הפעילויות להלן (5-38). אם צריך, הורד, הוסף, שנה וכו'. קבע משכי זמן וכמות י"ע (או ש"ע) לכל פעילות. קבע תלויות, קשרים ומקביליות בין הפעילויות. היעזר בנספח 4.2 תכנית עבודה או בהצעת הספק (מענה לרכיבים 4.2 תכנית עבודה ו- 4.3 השלב הבא).
בצע את סבב האישורים הנחוצים והזן את התכנית לתכנה לניהול פרויקטים, ניהול משימות, או כל אמצעי רישום ומעקב אחר.
פעולה זו מגדירה את רכיב 0 - מנהלה, בתיק העיצוב.
בכל המקרים בהם יש כבר ת"ע - משלב האפיון או הבקשה להצעות - פעולה זו היא ליטוש סופי וסגירת כל הפרטים האחרונים, או בקרת איכות על התכנית שהוצעה כבר.
יש לבדוק היטב אם נדרשים ריאיונות נוספים. יש להימנע מכפילויות (וסתירות!) עם שלב האפיון.
הכלים והמתודולוגיות שנבחרו לעיצוב המערכת ובנייתה מתועדים כבר ברכיב 3.13 בעץ המערכת וסביר שכבר הוגדרו במסמכים קודמים: תיק אפיון והצעת הספק. פעולה זו מסכמת סופית באילו כלים, מתודולוגיה ונהלי פיתוח תעוצב המערכת ותיבנה. לסיכום זה יש השלכות רבות על שלב העיצוב כולו, כולל תיק העיצוב והפעילויות שלהלן. יש להגדיר במדויק את אופן שילוב הכלים והנהלים בעבודה לפי מפת"ח ונהלי הארגון. פעילות זו עשויה להתרחב לכלל בנייה כוללת של סביבת הפיתוח ולהתלכד עם פעילות 18 שלהלן. ראה שם.
תוצאות פעילות זו יתועדו ברכיב 3.13 בתיק העיצוב.
ניהול תצורה מתבטא בהקפדה על הנושאים הבאים:
א. סימול ישויות המערכת – קודיפיקציה, מסכים, טרנזקציות, קבצים וכו',כמוסבר בתיק האפיון ובקיט תיעוד בכרך נושאים תומכים. אם סימול זה משתנה בעיצוב (בשל אילוצי כלים, למשל), יש להקפיד על קשר לאחור עם האפיון.
ב. סימול ברור של כל טיוטות תיק העיצוב (כולל רכיבי 98 ו- 99!).
ג. קביעת נוהל לבקרת שינויים ואישור של כל השינויים במערכת ובתיק העיצוב החל מנקודת זמן מסוימת בפרויקט. נקודת זמן זו יכולה להיות:
· החל מרגע זה (למחמירים)
· "אי שם" במהלך פעילויות 10-13
· החל מפעילות 13 ניהול תצורה II (למקילים)
ד. שימוש בספריות וכלי פיתוח מתאימים.
ה. הפרדה ברורה בין שטחי עבודה Workspaces השונים: פרטי, מחלקתי, פרויקטלי/מערכתי וכו' ועל נהלי העברה ברורים ביניהם.
ו. העברה מסודרת, לאחר בדיקות יחידה, לספרייה מרכזית (פרויקטלית/מערכתית).
ז. יכולת לדווח, בכל נקודת זמן, בפרט בסקרים, על הסטטוס המדויק של המערכת ועל תכולתה.
ברוב הפרויקטים ניתן לממש נושאים אלה במהלך העבודה השוטף וכחלק מתכנית העבודה הכללית והם אינם דורשים ת"ע נפרדת לניהול תצורה. במערכות גדולות בהן נדרשת תכנית נפרדת ומיוחדת לניהול תצורה, יש להכינה כאן, לשלבה עם תכנית אבטחת איכות של הפרויקט ולתייקה בפרק המנהלה ברכיב המתאים. ראה פעילות 8 הסמוכה.
לעזרה נוספת ראה קיט ניהול תצורה CM בכרך נושאים תומכים.
ברוב הפרויקטים (מערכות), מתבטאת אבטחת איכות בהקפדה על תכנית עבודה מסודרת, ביצוע סקרים, הוצאת טיוטות מסודרות של תיק העיצוב ושילוב גורמי אבטחת איכות בפרויקט, וניתן לבצעה כחלק מתכנית העבודה הכללית. במערכות גדולות בהן נדרשת תכנית נפרדת ומיוחדת לאבטחת איכות, יש להכינה כאן, לשלבה עם תכנית העבודה הכללית ולתייקה בפרק המנהלה ברכיב המתאים. לעזרה נוספת ראה קיט אבטחת איכות QA שבכרך איכות.
המשך האבטיפוס שנבנה באפיון או בניית אבטיפוס חדש. בכל מקרה, אבטיפוס הנבנה בשלב זה יהיה אבולוציוני, על כל המשתמע מכך (ראה קיט אבטיפוס Prototyping בכרך נושאים תומכים). יש להגדיר במדויק עבור אילו רכיבים נבנה אבטיפוס, מה רוצים לבדוק או להדגים, ומדוע בכלל אבטיפוס ולא בניית המערכת עצמה.
פעילות זו איננה חובה ואף לא המלצה. ההחלטה על מידת השימוש באבטיפוס (או מצגות והמחשות, או אפילו פרויקט פיילוט), היא בידי הפרויקט והארגון.
מעבר מדוקדק על כל סעיפי 98.X שבתיק העיצוב הראשוני ומקורותיהם (נספח 98 בתיק האפיון, למשל) ולימוד ההשלכות הנובעות מכך. היעזר בקיט ניתוח חלופות שבכרך נושאים תומכים.
השלמה ופירוט של כל התכנים הפונקציונאליים שהם ברמה של אפיון (לא עיצוב פיסי). פעולה זו נקראת לעתים גם אפיון מפורט.
סגירת שיטת הסימולים והשמות של כל הישויות המשתתפות במערכת: מסכים, קבצים, מודולים, דוחות, משתמשים וכו'.
הקו המדויק העובר בין פעילות זו (10) ופעילות 11 הסמוכה איננו חד-משמעי ומותנה במתודולוגית העיצוב, בחלוקה הפנימית של המערכת ובכלים שנבחרו לפיתוח המערכת.
השלמת רכיבים שהגדרתם הטבעית היא בעיצוב כגון: 2.4 ממשק תפעולי, 2.7 מודולים, 2.9 שגרות, 2.10 טבלאות, ו- 2.12 קבצים פיסיים. זו פעילות העיצוב המרכזית. פעולה זו עשויה להתחלק למספר רב של פעילויות, או חבילות עבודה. החלוקה מושפעת ממספר גורמים מרכזיים, כגון:
· מתודולוגית העיצוב שנבחרה
· סוג המערכת, אופייה ומידת השימוש בחלקי מערכת מוכנים (חבילות תכנה).
· מודולריות המערכת, היקפה וחלוקתה לתת-מערכות
להסבר נוסף ראה פירוט בפרק תוצרים – תיק עיצוב להלן ופעילות 13 להלן.
פעולה זו מגדירה סופית את תיק העיצוב או מעדכנת שינויים שחלו בו. ביצועה מותנה בכלים לפיתוח המערכת וקשור עם פעילות 11 לעיל. המצב המיטבי הוא שפעילות 11 מבוצעת ע"י כלים אשר מסייעים גם בכתיבת תיק העיצוב, היינו, פעילות 13 נגזרת ישירות מפעילות 11. מצב טוב "שני" הוא שפעילויות 11 ו- 13 מבוצעות ע"י כלים שונים, אך בקשר פיסי ולוגי הדדי, כגון תמיכת מערכת ההפעלה. בכל מקרה, לא מדובר בכתיבת תיעוד מבראשית, אלא בגלגול תיק האפיון ועדכונו, כמוסבר בסעיף תיק עיצוב להלן.
עריכת סקרים (ברמות שונות) ובדיקות א"א של הגדרות העיצוב:
· במערכת עצמה
· בתיק העיצוב
סביר שתהיה חזרה על פעילויות 11-14 בעקבות הערות והארות. זאת, בנוסף לסבבים וחזרות שנצפו מראש בתכנית העבודה וכנובע מעצם החלוקה לחבילות עבודה.
גם טיוטות תיק העיצוב יכולות לעבור מספר סבבים ולהיכנס לתוך המחזור של פעילויות 11-14. הכוונה כאן היא לתיק העיצוב הסופי והמחייב של המערכת.
תיק העיצוב שאושר הוא הבסיס (Baseline) לתצורת המערכת. פעילות זו תוודא:
· תכנים - התיק עדכני, מכיל את כל השינויים שאושרו ומשקף נאמנה את מצבה של המערכת נכון לכל רגע (תקופה).
· טכני - תכנו של התיק ומבנהו מקושרים עם הכלים והאמצעים האחרים שנבחרו לנהל ולעקוב אחרי תצורת המערכת, כולל מנגנון בקרת שינויים של התיק עצמו.
· עסקי - בהיבטים העסקיים והמסחריים וביחסי הלקוח/ספק "הכל סגור" ולא צפויות הפתעות (נוספות).
בתיאור תהליך העיצוב הנ"ל מוזכר שוב ושוב שהתהליך מותנה במתודולוגיה, בכלים ובחלוקה לתת מערכות. הגורם האחרון עשוי לגרום לכך שפעילויות 10 עד 15, אפשר אפילו 9 עד 17 יחזרו על עצמן ב"חבילות עבודה" לפי תת המערכות. הערה זו נכונה גם לפעילויות הבנייה שלהלן.
כולל ציוד קצה, תכנות, הגדרת ספריות וכו'. רצוי שמחשב זה יהיה עד כמה שאפשר דומה למחשב הייצור או שלפחות הממשק ביניהם (העברת תכניות, קבצים וכו') יוגדר באופן ברור ואף ינוסה. האם זה אותו מחשב ששימש לאפיון?
הגדרה זו תתועד ברכיב 4.9.1 תצורות הפיתוח והניסוי בעץ המערכת ותילקח בחשבון בהמשך תפעול המערכת ותחזוקתה, כסביבת ניסוי והמשך פיתוח מהדורות וגרסאות של המערכת.
פעילות זו עשויה להיות מוקדמת לתת שלב העיצוב ולהשתלב עם פעילות 6, כולל ביצוע "ניסוי כלים" חי.
הגדרה סופית של שטחי העבודה, ספריות, כללי ניהול תצורה וכן נהלי העבודה: קיטלוג בספריות, פרוצדורות גיבוי שוטף וכו'. אם נושא הסימולים (שמות מסכים, קבצים, מודולים וכו') לא נסגר בעיצוב, זה המועד האחרון לסגירתו.
בניית הישויות "האטומיות" הבסיסיות ביותר: שדות, משתמשים, אובייקטים בסיסיים וכו'.
בדומה לקידוד תכניות בפעילות 26 להלן ובהתאם לכלי הפיתוח.
מימוש קבצים לוגיים (2.11) ע"י קבצים פיסיים (2.12). הגדרת בסיס הנתונים הפיסי.
העלאת נתונים ראשוניים (נתוני מבחן) שישרתו את המשך תהליך הבנייה. טעינת בסיס הנתונים באופן מלא, היא פעילות 27 להלן.
· השלמת אובייקטים גלובליים: חלונות עזר משותפים, תיבות שיחה וכו' בהתאם לכללי הנדסת אנוש (2.4.0) שנקבעו.
· השלמת כל מסכי התפריט.
· השלמת "אובייקטים" מקומיים: חלונות עזר, תיבות שיחה, רשימות אחזור וכו'.
· בניית כל התבניות החוזרות של מסכי הפעולה.
· בניית כל מסכי הפעולה. (כאן או בפעילות 26 הסמוכה)
השלמה סופית של כל תיקי התכנות. מימוש טרנזקציות (2.6) ע"י מודולים (2.7) כמוסבר בסעיף זה בתיק העיצוב.
קיטלוג המודול בספרייה פרטית (הרמה הנמוכה ביותר בהיררכיות ספריות הפרויקט).
פעולה זו טוענת באופן מסיבי את הקבצים בנתוני אמת או ניסוי על מנת לבדוק את פעילות המערכת המלאה. כולל הסבות ניסיוניות של קבצים קיימים, אם צריך ואפשר.
ניסוי טרנזקציות ומודולים בדידים. פעילות זו מתוארת בהרחבה להלן.
קיטלוג המודול בספרייה משותפת (רמה אחת מעל הרמה הנמוכה ביותר בהיררכיות ספריות הפרויקט), לפי נהלי ניהול תצורה שנקבעו בפרויקט.
ניסוי תת-מערכת (שילוב) מתבצע בד"כ בשילוב להלן או בבדיקות מערכת מלאות. ראה פעילות 35 להלן. להוציא מקרים טריוויאליים ופשוטים (2-6 טרנזקציות לתת-מערכת, או מערכת מסוג ג1), בהן "מותר להיסחף" ולבצע ניסויי תת-מערכת כבר כאן וכהמשכיות ישירה של בדיקות היחידה. מודול אחר מודול: Incremental Testing.
יש סדר והיגיון פנימי בהגדרת פעילויות הקידוד כפי שהן מוצגות לעיל:
|
18-19 |
פעילויות הכנה כלליות |
|
20-24 |
פעילויות בנייה בסיסיות ומשותפות |
|
25-26 |
פעילויות בנייה פרטניות |
|
27-29 |
פעילויות בדיקה ואימות |
עם זאת, הכל מותנה כאמור, בכלים, במתודולוגיה ובחלוקה לחבילות עבודה. העיקר שרכיבים 2.2 - 2.23 ייבנו כנדרש ויתועדו בתיק העיצוב.
בדיקה שעד כאן המערכת נוהלה בניהול תצורה מסודר ושהיא מוכנה לאיסוף ולשילוב. ב"מערכת" הכוונה הן למערכת הפיסית והן לתיק העיצוב המלווה אותה. הבדיקה תיעשה ע"י הפקת דוחות מצאי ובקרת תצורה בחתכים שונים.
אם עד כאן לא בוצע ניהול תצורה או שהוא "ברח", יש לבצע כאן ניהול תצורה של הרגע האחרון או יישור קו ע"י:
· זיהוי וסימון כל הרכיבים: בדיקה שיש גם סימון חיצוני (בספריות) וגם סימון פנימי ברכיב עצמו, חותמת פנימית (במסכים למשל).
· אימות ביצוע בדיקות יחידה לכל רכיב.
· זיהוי וסימון כל הספריות הפרטיות מהן תיבנה ספריית הפרויקט הכוללת. במערכות גדולות, ייתכן מעבר בספריות של תת-מערכות.
· עדכון תיק העיצוב כמוסבר לעיל בפעילויות העיצוב ובסעיף תיק עיצוב להלן.
· הפקת דוחות מצאי ובקרת תצורה כנ"ל.
· איסוף כל רכיבי המערכת וכינוסם בספריות הפרויקט המתאימות. הפקת רשימת מצאי.
· הידור וקישור - Compile & Link סופיים של כל התכניות והמודולים.
· שילוב (בנייה) של תת-מערכות
· שילוב (בנייה) של המערכת הכוללת.
· הפקת דוחות בנייה וניהול תצורה: רשימות מצאי של כל רכיבי המערכת: שם, תאריך קיטלוג, ספריית מקור, מתכנת, שפה, גדול וכו'
כחלק אינטגרלי מפעילות 31 או מיד אחריה, מבוצעות בדיקות שילוב כמוסבר בסעיף בדיקות יחידה ושילוב להלן. לבדיקות אלה קשר דו-כיווני עם בדיקות יחידה מחד גיסא ועם שלב בדיקות המערכת המלא מאידך גיסא.
הקשר עם בדיקות יחידה: בדיקות שילוב מניחות שבוצעו בדיקות יחידה ואם לא, ניתן להשלים זאת כאן.
הקשר עם שלב בדיקות המערכת: בדיקות שילוב יסודיות ומקיפות, הנערכות לאחר בדיקות יחידה מסודרות, עשויות לחסוך את שלב בדיקות המערכת בפרויקטים מסוג ג1. במקרים אלה יושם דגש על בדיקות קבלה בשלב התקנה והרצה.
ניסוי של פתיחת המערכת וסגירתה על מחשב הפיתוח, כולל טיול בתפריטים הראשיים וניסוי חלקי ביותר של מספר טרנזקציות. יש להיזהר ולא לגלוש לבדיקות מערכת.
בדיקה כללית לתת-מערכת:
· פתיחה סגירה
· הפעלת 2-3 תהליכים מדגמיים
· בדיקת הרשאות לתת-מערכת: כניסה, יציאה
· הפקת 1-2 דוחות מדגמיים
· הפקת 1-2 ממשקים מדגמיים
בכל מקרה בו ניסוי תת-מערכת מתרחב, יש לדחותו לשלב בדיקות המערכת. ראה רכיב 2.3 בתיק בדיקות מערכת.
כולל ציוד קצה, תכנות, קבצים, ספריות וכו'. אם אי אפשר, או לא רצוי, להעמיד את תצורת הייצור המלאה כבר בשלב זה, יש להעמיד לפחות תצורה חלקית או להקצות את המשאבים הדרושים במחשב קיים.
תרגול העברה מסביבת הפיתוח לסביבת הייצור, כולל ניסוי גיבוי ושחזור של כל המערכת.
ניסוי של פתיחת המערכת וסגירתה על מחשב הייצור, כולל טיול בתפריטים הראשיים וניסוי חלקי ביותר של מספר טרנזקציות. זהירות, לא לגלוש לבדיקות מערכת!
הערה: פעילויות 33-37 הן בדיקה בסיסית ואימות שהמערכת שולבה ומוכנה לבדיקות מערכת מלאות (בנוסף לבדיקות השילוב והיחידה שכבר בוצעו קודם). במהלכן עשויה להיות גלישה (מוצדקת) לבדיקות רחבות יותר. עם זאת, אין זה שלב בדיקות המערכת! אין להיסחף!
למרות שפעילויות השילוב עוסקות, מטבע הדברים, במערכת עצמה ולא בתיעוד, ברור שיש לכך השפעה גם על התיעוד. בגמר השילוב (שהוא גם גמר כל שלב העיצוב והבנייה) יש לשוב ולעדכן את תיק העיצוב (תיק המערכת) ולוודא שהוא מתואם עם המערכת עצמה ויכול לשרת נאמנה את השלבים הבאים, בעיקר לשמש Baseline לשלב התפעול והתחזוקה.
הטבלה הבאה מסכמת את המעבר בתת השלבים של שלב העיצוב והבנייה ואת קיצורי הדרך שניתן לעשות, כפונקציה של היקף המערכת:
|
היקף המערכת |
קיצורי דרך - תת שלבים |
|---|---|
|
ג3 |
אין בד"כ קיצורי דרך. יש לפעול לפי הנ"ל. |
|
ג2 |
ניתן לאחד את העיצוב והבנייה, אם כלי הפיתוח בנויים לכך. |
|
ג1 |
ניתן לאחד את כל תת השלבים ע"י: עיצוב-בנייה-ניסוי יחידה: מודול אחר מודול שילוב הדרגתי: מודול אחר מודול |
|
בכל ההיקפים |
בנייה וניסוי יחידה בד"כ מבוצעים ביחד. |
בנוסף לבדיקות השוטפות המתבצעות לאורך כל עיצוב המערכת ובנייתה: סקרים, בדיקות תיעוד ועוד, מכיל שלב עיצוב ובנייה גם פעולות בדיקה מיוחדות (Per Se). בדיקות אלה נחלקות לשני סוגים עיקריים:
· בדיקות יחידה (Unit Tests)
· בדיקות שילוב (Integration Tests)
הראשון עוסק בבדיקה (ניסוי) של יחידת תכנה בדידה (מודול) והוא קשור קשר הדוק עם תת שלב הקידוד (ראה פעילות 28 לעיל). סוג זה עשוי להתרחב לעתים לבדיקה של מספר יחידות תכנה קרובות. השני עוסק בתהליך שילוב היחידות למערכת כוללת או לחלק ממערכת והוא קשור עם תת שלב השילוב וניהול תצורה (ראה פעילויות 30-32 לעיל).
בדיקות יחידה מתבצעות באופן שוטף במהלך הקידוד, לכל מודול בנפרד, ומנוהלות דרך תיק התכנות. בדומה לשאר סעיפי תיק התכנות, ההנחיות והנתונים לבדיקות היחידה נכתבים ע"י המעצב (מנתח המערכת) והביצוע הוא ע"י המתכנת כחלק מעבודת הקידוד השוטפת. בדיקה זו מורכבת מהצעדים הבאים:
יחידת התכנה נערכת ומקודדת וכל הקוד הקשור לה מקוטלג בספרייה פרטית. שפות תכנות ועורכים (Editors) מתקדמים מגלים שגיאות מסוימות כבר בשלב זה, עוד לפני ההידור.
ביצוע קומפילציה למודול ובדיקה לשגיאות, אזהרות והערות המהדיר. במערכות מסוימות מכיל צעד זה גם קישור סטטי (Link או Early Binding) של אובייקטים נוספים כגון שגרות, חלקי קוד משותפים וכו'.
כל הבדיקות "היבשות" שניתן לעשות מבלי להריץ עדיין את המודול:
· גודל
· מבניות
· סביכות
· מס' כניסות ויציאות
· הסתעפויות ומסלולים
· דרגות קינון (nested IF's)
· קבלה והחזרה של פרמטרים
· תיעוד פנימי (comments)
· פרולוג מסודר
להלן מספר הערות לבדיקת מבניות:
· בשפות מתקדמות בהן הקידוד הוא מילוי ערכים (פרמטרים) למחולל (עבודה עם Templates למשל), חלק מבדיקות אלה קטן או אפילו נעלם. אך חלק ניכר עדיין קיים, אלא שהמינוח הוא שונה. בדוק היטב!
· יש כמובן להעדיף הסתייעות בכלי ממוכן, אשר כמו המהדיר (הקומפיילר), קורא את המודול, מפיק דו"ח מבניות ומציע תיקונים.
· בפרויקטים מסוימים, הבדיקה המבנית עשויה להתרחב לבדיקות-קוד מעמיקות, Code Inspections, ולהתבצע ע"י צוות מיוחד. ראה טופס מיוחד בהמשך. ראה גם קיט בדיקות מערכת.
למרות שמדובר במודול בודד, תמיד קיימת סביבה קרובה: מודולים אחרים, שגרות וכו' הקשורים למודול הנבדק ושהם במישרין או בעקיפין חלק מהבדיקה. ראה הערה מסכמת בסוף סעיף זה.
למרות שמדובר בניסוי ממוקד ומצומצם ברמת מודול בודד, יש להכין קבצי ניסוי (כולל טבלאות!) מולם יפעל המודול וייבדק. פעילות זו איננה קלה ודורשת, לעתים קרובות, תיאום עם מתכנתים אחרים ומנהל הפרויקט (מנתח המערכת). סביר גם שהיא לא תיעשה במיוחד עבור המודול הספציפי אלא לכלל המערכת או לקבוצת מודולים (תת-מערכת).
בנוסף לקבציי הניסוי הנ"ל, יש להכין נתוני בדיקה וכן הערכה של התוצאות הצפויות, על מנת שהניסוי יהיה רטוב וקרוב למציאות עד כמה שניתן:
· קלטים (למסכי הפעולה, למהלכי אצווה)
· תוצאות צפויות או לפחות סבירות.
רצוי שמקרי הבדיקה יכללו מקרים קיצוניים, שגויים ותקינים ויכסו את מירב המסלולים בהם תפעל התכנית (או מדגם מייצג שלהם). המסלולים נקבעים ע"י מעבר סדרתי על התכנית והסתעפויות אפשריות לפי IF, CASE וכד' (עץ זרימה).
הפעלת המודול באופן ישיר או עקיף, בצורת ההפעלה הסופית (הטבעית) או בצורה מלאכותית לצורך הניסוי. ניסוי זה בודק שהאלגוריתם והלוגיקה המבוצעים ע"י הקוד נכונים ושהקוד אכן מיישם את הדרישות שהוגדרו לו. ניסוי זה ייתכן במספר אופנים:
· הרצה מבוקרת עם נקודות-עצירה (Breakpoints) שהוגדרו מראש ובחינת מצב הנתונים והקוד בנקודות אלה. נקודות אלה יכולות להיות מסוגים שונים: כל X שורות קוד, כל מעבר בצומת מסוימת, כל Yיחידות זמן וכו'.
· הרצה חופשית והפעלת נקודות עצירה דינמיות ואקראיות ע"י המתכנת בעזרת מקש break.
· הרצה חופשית "עד הסוף" ובחינת הנתונים והתכנית פעם אחת בלבד בסוף המהלך. שיטה זו מתאימה למודולים פשוטים או למקרה בו מבצעים מספר רב של ריצות חופשיות כאלה.
· שתילת נקודות עצירה מותנות בתכנית. העצירה תהיה כל אימת שמתקבל ערך/נתון חריג, בכל פעם שפונים בהסתעפות (case, if) לכיוון מסוים, או כשעוברים בקטע קוד מסוים.
· ייתכנו כמובן אופני הרצה/בדיקה נוספים ושילוב של הנ"ל. בכל אופן, סביר שלא ניתן יהיה לעבור על כל המקרים ויש להסתפק במדגם מייצג.
בהתאם לתוצאות הניסוי מוכנסים תיקונים במודול (או ברכיב אחר) בעיצוב או בקוד, מתעדכנים קבצי הניסוי וחוזרים על הבדיקה.
רישום תוצאות ניסוי היחידה (הסופיות) בתיק התכנות.
בכפוף לנוהל ניהול תצורה עליו הוחלט (ראה פעילות 7 לעיל), יועבר המודול לספרייה ציבורית (לא זו של המתכנת), או לספריית ביניים. אפשר להשתמש ב- Directory של הספרייה ככלי עזר לניהול תצורה של בדיקות היחידה: כמה ואלו מודולים נבדקו ומתי.
הדגש בניסוי יחידה זה הוא, כאמור, על המודול הבודד. אין אלה בדיקות מערכת אלא חלק מתהליך הקידוד. ניסוי יחידה הוא גמר הקידוד! עם זאת, ברור ששום מודול איננו "קרון בודד" וגם בניסוי הממוקד ביותר נבדקים, בעקיפין, רכיבים אחרים כגון: טבלאות, שגרות, קבצים, מסכים ואף מודולים אחרים. לעובדה זו יש יתרונות אך גם חסרונות. הפתרון הקלאסי הוא שימוש ב- Stubs, בפרט אם הרכיבים האחרים (הסביבה) עדיין אינם קיימים. יש לשקול היטב אם לנקוט בדרך של Stubs או לבדוק מול הסביבה האמיתית, גם אם היא חלקית ולא גמורה (אי אפשר לבדוק את כל המודולים בבת אחת ..)
רשימת התיוג הבאה משמשת לתיעוד וסיכום בדיקת (ניסוי) יחידה. טופס בדיקות יחידה ממולא יתויק בתיק התכנות בסעיף המתאים. (ראה טופס בדיקות יחידה בלשונית תוצרים בקיט זה).
יש לציין בטופס מול כל פרמטר, תוצאות/ערכים מתאימים:
· תאריך, שם המתכנת, מקום ביצוע הבדיקה
· עריכה, קידוד
· הידור (קימפול)
· בדיקה "יבשה": מבניות, מס' כניסות/יציאות, סביכות, שמות סימבוליים תקניים
· סביבת הבדיקה
· קבצי ניסוי
· נתוני הניסוי - ערכים נבדקים
· פעולות מתקנות
· העברה/קיטלוג בספריה
· חתימת מאשר הבדיקות
בדיקות של מספר יחידות תכנה קרובות היא פעולה טבעית המתבקשת מאליה, אם כהרחבה של בדיקות היחידה ואם כחלק מניסוי של תת-מערכת (פעילות 29), או בדיקות שילוב (להלן בסעיף זה). במקרה הראשון יש לפעול ע"ס ההנחיות שבתת הסעיף הקודם הדן בבדיקות יחידה ובמקרה השני ע"ס ההנחיות שבתת הסעיף הבא הדן בבדיקות שילוב.
בדיקות שילוב מתבצעות לאוסף מודולים (יחידות התכנה), בהתאם לתכנית עבודה מסודרת, ובמטרה לשלבן למערכת מסודרת תחת ניהול תצורה מבוקר. ה"מערכת" המשולבת עליה מדובר כאן יכולה להיות תהליך מרכזי, ממשק עם מערכת חיצונית או פנימית, תת מערכת וכמובן המערכת כולה.
בדיקות שילוב יכולות להיעשות בשני אופנים עיקריים:
· "צעד אחד צעד" ובאופן "לא-מתכנן" בשיטת ניסוי ותהייה
· ע"י תכנית שילוב מסודרת ומוגדרת היטב מראש.
משותף לשני האופנים הוא ניהול מסודר של רשימת מצאי, כמוסבר בהמשך. האופן הראשון מתאים למערכות קטנות (ג1 ומטה), בעוד שהשני מתאים למערכות בינוניות וגדולות (ג2 ומעלה). האופן הראשון אינו מוגדר כאן וכל מערכת תגדיר לעצמה את האופן בו יתבצעו בדיקות שילוב כאלה. האופן השני מוסבר בהמשך.
רשימת מצאי מסודרת של כל המודולים, מסכים, קבצים וכו' המרכיבים את המערכת (וכלולים על כן בתהליך השילוב) היא תנאי הכרחי בשני האופנים, גם באופן ה"לא-מתכנן". רשימה זו תכנס בסופו של התהליך לרכיבים המתאימים בתיק המערכת.
טופס רשימת מצאי בלשונית תוצרים, הוא דוגמא לרשימת מצאי שניתן בשינויי התאמה ומיכון לאמץ בעיקר במערכות קטנות - ג1. מערכות בינוניות ומעלה ייעזרו ברשימות המופקות מכלי הפיתוח וניהול התצורה שברשותם.
הכנות לשילוב ולניסוי
א. הגדרת האחראים לתכנון, לביצוע, לרישום ולהעברה.
ב. הגדרת הנושאים (תת המערכות, התהליכים הראשיים) עליהם יושם דגש ב"שילוב ניסוי" זה.
ג. בחירת אוכלוסיית היחידות שתיבדקנה: גודל המדגם, כיצד ייבחר וכו'.
ד. הגדרת תרחישי הבדיקה:
· מקרי הבדיקה: קלטים, תוצאות צפויות וקריטריונים להערכתן,
· פרוצדורות הבדיקות (תסריטים).
דגש הן על המקרים השכיחים והן על מקרים קיצוניים בהם צריכות התכניות לעמוד.
בניית סביבת הניסוי הכוללת:
· חומרה ותכנות תשתית (בסיס הנתונים וכו')
· תקשורת וקשר עם מערכות שכנות
· אכלוס קבצי הניסוי בנתונים רלוונטיים. רצוי בנתוני אמת שנגזרו מקבצים חיים.
· לו"ז ומשאבים לביצוע השילוב והבדיקות.
חלק מפעולות הכנה אלה (וגם פעולות ביצוע הניסוי להלן) ניתן לחסוך אם בוצעו בדיקות יחידה מסודרות, היינו, אם יש תיקי תכנות מסודרים כולל סעיף ניסוי יחידה. כל מידע הקשור בהכנות לשילוב וניסוי נרשם בתיק העיצוב בנספח שילוב וניהול תצורה.
ביצוע הניסוי
· ניסוי יחידה כנ"ל, אם טרם בוצע, כולל הכנסת תיקונים מקומיים. סעיף זה פירושו שאם לא בוצעו בדיקות יחידה ע"י המתכנתים עד כאן, יורה צוות הניסוי והשילוב לעשות כך, כאן.
· שילוב הדרגתי של יחידות התכנה הנבדקות עם יחידות תכנה ששולבו קודם לכן. בצורה זו משולבות ונבדקות בהדרגה כל יחידות התכנה השייכות למודול, תת-מערכת או CSCI (פריט תצורה מבוקר). הבדיקות מוודאות שכל יחידות התכנה פועלות כנדרש, כמקשה אחת, בלי לפגוע בביצועים ותוך שימור הביצוע הפרטני של כל יחידת תכנה.
תיקונים, עדכונים ושילובים חוזרים בהתאם לתוצאות הניסוי מוכנסים תיקונים במודול המשולב (או במודולים ששולבו כבר) בעיצוב או בקוד, מתעדכנים קבצי ומקרי הניסוי ומבוצעים מחדש כל הבדיקות והשילובים הדרושים. שינויים אלו מעדכנים גם את תיק העיצוב והתכנות.
רישום. תוצאות הבדיקות והשילובים נרשמים בנספח מיוחד בתיק המערכת (תיק העיצוב) או במסמך אד-הוק נפרד וכן בכלי לניהול תצורה.
העברה לספרייה ציבורית. פעילות זו היא השילוב עליו מדובר כל הזמן. יש להקפיד על שילוב בהתאם לנוהל ניהול תצורה עליו הוחלט (ראה פעילות ש2 לעיל).
הדגש בבדיקות אלה הוא על שילוב המערכת. בדיקות אלה עדיין אינן שלב בדיקות המערכת, אבל הן הכנה לו! תוצאתן היא מערכת משולבת שגם אם אינה מוכנה עדיין להתקנה והפעלה, היא מוכנה לעריכת בדיקות מערכת מלאות ול- Test run. בבדיקה מסוג זה אין בד"כ מקום לשימוש ב- stubs אלא יש להתמודד כבר עם הסביבה האמיתית.
סקר קוד (Code Review & Inspection) הוא אמצעי חשוב לקיום איכות התכניות הנכתבות בפרויקט. מטרתו לגלות ולתקן תקלות מוקדם ככל האפשר, עוד בשלב העיצוב והבנייה.
בין יעדי הסקר ניתן למנות את הרכיבים הבאים:
· הקטנת עלויות הפיתוח
· שיפור איכות התכנה
· שיפור איכות המערכת בשלב ההתקנה וההרצה
· הכרה מעמיקה של הקוד הקיים
· הכשרת מתכנתים חדשים ולא מנוסים
סקר הקוד בא לאמת:
· כתיבת התכניות עומדת בכללים המקצועיים הנהוגים בארגון, כגון שימוש מקובל בשמות משתנים, כתיבה מבנית, טיפול במקרים חריגים וכו'.
· כתיבת מסכים ודוחות עפ"י תקני הארגון
· שימוש נכון ויעיל בשגרות, אינדקסים, לולאות וכד'
· נעשה שימוש נכון בשגרות תשתיתיות כלליות
· ביצוע הרצה "יבשה" של התכנית - על מנת לוודא: לוגיקה הגיונית של ריצת התכנית, סיום תקין, טיפול בשגויים, הימנעות מ - Deadlocks וכד'.
· בדיקת התיעוד של הקוד
· בדיקת טיפול בשגויים
תהליך סקר הקוד מורכב ממספר שלבים
1. תכנון מקדים
2. הכנות
3. ביצוע הסקר
4. תיקונים בקוד
5. מעקב והפקת לקחים
תכנון הסקר מתבצע כבר בשלב האפיון וכולל:
· קביעת היקף הסקרים שיערכו בשלב הבנייה
· שילוב סקרי הקוד בתכנית העבודה של הפרויקט
· מינוי האחראי לביצוע סקרי הקוד (הבודק)
· התאמת טופס הסקר לסוג הסקר, לארכיטקטורה ולשפת הפיתוח של כל מודול. ראה טופס סקר בלשונית תוצרים בקיט זה.
· קביעת התכניות שישתתפו בסקר באמצעות מדגם שייצג את כל סוגי הקוד בפרויקט
· קביעת המשתתפים - התכניתן שכתב את הקוד, ראש הצוות האחראי על התכניתן והבודק.
· זימון מסודר - באחריות הבודק לידע מראש את המשתתפים לגבי המקום, המועד ומשך הזמן שיוקדש לביצוע הסקר.
· יש להתרכז בעיקר ולא לגלוש לנושאים צדדיים.
· אם במהלך הסקר מתעוררים נושאים חשובים, יש להקפיד לרשום אותם בנפרד, לטיפול מאוחר יותר.
· יש להקפיד על מסגרת הזמן שנקבעה לכל מערכת.
· ביצוע סקר קוד מסוים מתבצע כהמשך לשלב ההכנות. התייחסות מפורטת ומעמיקה תיכתב רק לאחר סיום הסקר.
בשלב התיקונים, מבצע התכניתן את התיקונים והשיפורים בהתאם לתוצאות הסקר. התיקונים עצמם יוצגו לבודק בפגישת מעקב לכשזו תזומן.
במידת הצורך, יקבע מנהל הפרויקט מועד לפגישת מעקב שבה יציג התכניתן את הקוד המתוקן לאחר השלמת פעילות התיקון.
יש לרכז בנפרד הערות רוחביות הנוגעות לפיתוח הקוד בפרויקט ולהפיק מסקנות וניתוחים סטטיסטיים מקיפים ברמת כל הפרויקט.
מסמך (תיק) עיצוב הוא המשך ישיר וטבעי למסמך האפיון, תוך שימת דגש על רכיבי עיצוב (פיסיים) שלא נכללו באפיון ועל פירוט נוסף של רכיבים שלא הוגדרו במלואם. אפיון מפורט הוא חלק מהעיצוב. תיק עיצוב עומד בין תיק אפיון לתיק תחזוקה ושלושתם בנויים באותה שיטה - עץ המערכת. תיק אפיון מהווה כ- 70% מתיק עיצוב ואילו תיק עיצוב הוא 95% מתיק התחזוקה (הראשוני). כל השקעה בתיק עיצוב היא, איפוא, ניצול ההשקעה שנעשתה באפיון, או חסכון בהשקעה עתידית בתחזוקה, או שניהם. הנחיית היסוד היא, איפוא:
על מנת לעמוד בדרישה יסודית זו של ניצול ההשקעה שנעשתה כבר באפיון והימנעות ממאמץ מיותר בעיצוב ומהמצאת הגלגל, יש להיעזר בהנחיות המעשיות הבאות:
א. אפשר "להקיף בענן" את רכיבים 2.4-2.7 ורכיבים 2.10-2.13 ולבנותם בחלוקה פנימית המתאימה לכלי הפיתוח ולסביבת העבודה הטכנית או למתודולוגיה הספציפית איתם עובדים. יש לשמור על קשר בין רכיבי X.2 אלה ורכיבי עץ המערכת המקוריים. למשל, אפשר לסמן רכיב "2.6-2.7 טרנזקציות ומודולים", או, אם בוחרים במתודולוגית האובייקטים, אפשר להכיל את רכיב 2.6 בתוך 2.11 (או ההפך). ראה קיט גישת האובייקטים בכרך נושאים תומכים.
ב. יש לאתר כלי מנהל תיעוד (Documentation Manager) המסוגל לא רק ליצור תיעוד בעצמו ולנהלו, אלא גם לרכז רכיבי תיעוד חלקיים שנוצרו בכלים אחרים ולשלבם לתיק עיצוב (לוגי) אחד. דוגמא לכלי כזה הוא מעבד תמלילים עם יכולת Export/Import, קישוריות OLE ועם תמיכה במסמכי-אב (Outlining) ושילוב מסמכים. רצוי מאד כלי שהשתמשו בו כבר באפיון ושימשיך לתפקד באופן דומה גם בשלב התחזוקה. כלי טוב לניהול תיעוד צריך לתמוך במספר פונקציות:
· יצירת תיעוד (מעבד תמלילים גרפי)
· שילוב תיעוד מ/אל מקורות חיצוניים
· תיעוד של רשימות פריטים (אינדקס) בלבד
· קישוריות המאפשרת שילוב אובייקטים חיצוניים
· יכולת הצבעה וקישור למערכת (לספריות המערכת)
· מיתוג מקוון ונוח ממנהל התיעוד לקטעי מערכת (מאותו המסך)
· הפקה סלקטיבית של תיעוד ולפי פרמטרים.
ג. לא תמיד יש הכרח להעביר פיסית תכנים לתיק העיצוב. תיק העיצוב יכול לשמש Pointer, היינו, אינדקס תיעוד המכיל, בכל רכיב, תיעוד או הפניה לתיעוד. זו אחת היכולות של מנהל תיעוד טוב.
ד. יש להשתמש בכלי העיצוב והבנייה, במירב האפשרי, גם כעזרי תיעוד. כל כלי צריך לתרום את חלקו ולהעביר למנהל התיעוד את תכניו. כלים שגם בונים וגם מתעדים הם רצויים ביותר. מי שבונה את הרכיב צריך לבנות גם את התיעוד המובנה הנלווה, דוגמת מחולל (שפת תכנות) התומך ב- Prolog בראש כל מודול. זכור: תיעודו הטוב ביותר של רכיב הוא קיומו המסודר והתקין, בתנאי שהוא מכיל תיעוד מובנה (Built-in) ושהוא מקושר עם מנהל התיעוד.
ה. כל תיעוד ביניים (טיוטות), הן ברמת הרכיב והן ברמת תיק העיצוב כולו, יהיה במבנה הסופי ובאמצעי (מדיה) הקרוב עד כמה שניתן לאמצעי הסופי (תיעוד מסכים למשל, ייעשה במחולל המסכים עצמו). אין להשקיע בתוצרי ביניים בעלי מבנה שונה.
ו. שימוש באבטיפוס ושילובו בתיק העיצוב יהיו בתנאים אלה:
· ייבדק היטב אם נעשה שימוש באבטיפוס בשלב האפיון, מה עלה בגורלו, במה הועיל ומה הלקח שנלמד.
· האבטיפוס יהיה מסוג אבולוציוני.
· תיעוד האבטיפוס ייעשה בכפוף להנחיות הנ"ל וישמור על קשר ברור עם תיק העיצוב. התוצרים יתכנסו בהדרגה לתוך תיק העיצוב.
ז. ייעשה שימוש מירבי ברכיבים קיימים או גלובליים המוגדרים ברמת הארגון (קובץ טבלאות, שגרות וכו').
ח. במערכות מסוג ג1 ניתן לקצר את תיק העיצוב, בדומה להנחיות לאפיון מקוצר שבפרק האפיון.
ט. ניתן לבנות את תיק העיצוב כתוספת לאפיון (Superimpose). תיק העיצוב המלווה את העבודה השוטפת יכיל רק את רכיבי העיצוב (X.2). בהפקה יארזו שניהם בתיק אחד ותופק גם תמצית מנהלים של התיק הכולל.
לסיכום, ברוב המקרים בניית תיק עיצוב איננה אלא עיבוי והמשך טבעי של מסמך האפיון תוך שימת דגש על הנקודות הבאות:
· פירוט נוסף של רכיבים שלא פורטו במידה מספקת
· דגש על רכיבים פיסיים (האפיון הדגיש את הרכיבים הלוגיים)
· השלמת נתונים מתוך ההצעות שהוגשו לשלב הבקשה להצעות
· בדיקה ואימות שלא חלו שינויים ברכיבי אפיון (רכיבים לוגיים ופונקציונאליים המשפיעים על הגדרת המערכת המהותית).
גלופת תיק עיצוב, בדומה לגלופות אחרות במפת"ח, היא כפולה: גלופת לימוד וגלופת עבודה. גלופת העבודה היא מלאה ומכילה את עץ המערכת ברמה שלישית, כאשר רוב הסעיפים הם שלדיים ומכילים כותרות וטבלאות למילוי בלבד, בלי דברי הסבר. גלופת הלימוד, לעומת זאת בנויה כתוספת על עץ המערכת האוניברסלי (ותיק האפיון). חלק ניכר מהרכיבים נגרר מהאפיון כמות שהוא ועובר הרחבה, עידון ואימות מובנים מאליהם. גלופת הלימוד מתמקדת ברכיבי העיצוב הקלאסיים בהם יש להשקיע את עיקר המאמץ והשלמתם היא עיצוב המערכת.
תיק תכנות הוא תיעוד מודול במערכת. מודולים הם אבני בנין בסיסיות - הם המימוש הפיסי של טרנזקציות המערכת. המודולים מממשים את האלגוריתמים של המערכת ואת אופן פעולתם על בסיס הנתונים, על הקלטים ועל הפלטים. חשיבות מודול היא לכן לא רק בקוד שהוא מכיל אלא בקשר שלו עם רכיבים רבים אחרים: טרנזקציות, מסכים, קבצים, מודולים אחרים וכו'. מודולים הם גורם מרכזי בתחזוקת המערכת ומקור תדיר לשינויים (ולשגיאות!).
תיק תכנות הוא, אפוא, מכשיר חשוב ביותר לפיתוח המערכת ולתחזוקתה. במבנה תיק תכנות אפשר להבחין במספר רמות (שלבים):
· מבנה לוגי כללי של תיק תכנות, אשר הוא סטנדרטי ונכון לכל מערכת מידע.
· מבנה לוגי המתאים לסוג הטרנזקציה אותה מממש המודול: עדכון אצווה, עדכון מקוון, שאילתא וכו'.
· שלד תקני בארגון לתיק תכנות. מבנה שלדי כזה מושפע מסביבת המיכון של הארגון: מדיום התיעוד (מעבד התמלילים), תכנית העורך (Editor), שפת התכנות, תכנת PDL ועוד. מדיום זה איננו רק מימוש פיסי של המבנים הנ"ל (בסעיפים לעיל), אלא משפיע גם על המבנה הלוגי של התיק.
· המבנה הסופי והספציפי של כל מודול בהתאם לדרישות הספציפיות של המערכת הנדונה והטרנזקציה המסוימת. מבנה זה יקבע בכל פרויקט (מערכת) לגופו.
· אם יש בארגון מבנה תיק תכנות תקני או אפילו גלופות מוכנות, עדיף להשתמש בהם מאשר בתבנית כללית חיצונית. אם אין, מומלץ להשתמש בתבנית תיק תכנות המצויה בלשונית תוצרים בקיט זה.
קשה לתת המלצה לגבי המדיום לתיעוד תיק תכנות, היינו, לגבי אופן מיכון התיק המומלץ. כדאי רק לזכור שהמשימה העיקרית של תיק התכנות היא כפולה:
· לגרום לכך שכל שינוי בתכנית ירשם גם בתיק
· לגרום לכך שתיק התכנות לא יהיה רק כלי רישום פסיבי, אלא גם כלי סיוע בהבנת המודול ובתכנון שינויים במודול.
רשימת התיוג מורכת משני חלקים:
· כללי – פרטי המערכת, התכניתן והבודק
· רשימת תיוג לביצוע הסקר
ניתן להתאים את רשימת התיוג לשפות התכנות הקיימות בארגון.
גישת מפת"ח היא, כאמור, להשאיר את שלב העיצוב והבנייה פתוח ולאפשר לגורם המפתח להשתמש בכלים, במתודולוגיות ובידע המקצועי האמונים עליו ביותר. עם זאת, יפורטו להלן מספר כללים מנחים ("כללי אצבע") אשר יסייעו הן למפתח והן לגורם המפקח להגיע למערכת הדרושה במהירות וביעילות ותוך שמירה על אבטחת איכות.
הכלל המנחה העליון הוא שמירה, באופן שוטף, על ארבעת מדדי האיכות.
מערכת מידע איכותית היא מערכת המקיימת את התנאים הבאים:
|
פונקציונאלית: |
עונה לדרישות המשתמש |
|
יעילה: |
איכותית ובנויה הנדסית נכון, כולל גמישות לשינויים |
|
כלכלית: |
עומדת בגבולות משאבים ולו"ז שהוקצו |
|
חוקית: |
עומדת בדרישות החוק, מינהל תקין וחוקת הארגון. |
עיצוב מערכת ובנייתה חייבים להיעשות כהמשך ברור וישיר של האפיון, בייעול המאמץ ובמינימום של שינויים בהגדרה הפונקציונאלית של המערכת:
· חסכון. יש להימנע מחזרות וכפילויות. רכיב שניתן "להצביע" עליו מתיק העיצוב לתיק האפיון (יעדים!) - מה טוב.
· העברות. רכיב שנמצא כבר בצורה ובאמצעי הסופיים, מה טוב. יש להעבירו כמות שהוא.
· הסבות. רכיב שעדיין לא נמצא באמצעי (מדיה) הסופי שלו, יש להביאו לאמצעי זה במינימום שינויי תוכן.
באופן זה יתמקד עיקר המאמץ ברכיבים שבאמת דורשים עיצוב. בדיקה למידת ההמשכיות או השוני בעיצוב מול האפיון תיעזר בהגדרת המאפיינים של הרכיבים: תוכן, צורה (מבנה) ואמצעי (מדיה). ראה הגדרה מפורטת בקיט עץ מערכת אוניברסלי בכרך יסודות. שינויים באמצעי הם טבעיים לעיצוב ואינם כרוכים בד"כ בשינויים פונקציונאליים. שינויי צורה ומבנה הם עיקר העיצוב, אך הם עשויים לגרור בעקבותיהם שינויים פונקציונאליים (שינויי תוכן) ויש לבדוק זאת היטב. שינויי תוכן הם הדורשים תשומת לב מירבית. המצב הרצוי הוא פירוט נוסף שאינו משנה את ההגדרה הפונקציונאלית הבסיסית של המערכת ואינו גורם לחריגה בלו"ז ובמשאבים (כגון: פירוק קבוצות דוחות לדוחות הפרטניים - ראה רכיב 2.15 בתיק האפיון ובתיק העיצוב לעיל). אם השינוי הוא תכני/מהותי כגון שינוי בהגדרת בסיס הנתונים הלוגי, יש לעצור מייד לקבל את הנחיית הצוות המנהלי (מהדורה חדשה? חזרה לאפיון?). לנושא זה מוקדשת פעילות 12 לעיל.
יש להיצמד לתקינה בינלאומית, ישראלית וממשלתית (היכן שיש) ולרשימות התיוג שבקיט תקינה ותקנים בכרך נושאים תומכים.
יש לעשות שימוש מירבי ברכיבי מדף וברכיבים שניתן להעתיקם ממערכות מידע אחרות (בארגון או מחוצה לו). מילת הקסם היא - שימוש חוזר: Reusability!
יש להקפיד על קיום מפגשי סקר ועל עריכתם הנאותה. היעזר בקיט סקרים שבכרך נושאים תומכים. באופן דומה יש להקפיד על אבני הדרך המרכזיות שהוגדרו לפרויקט. בשלב עיצוב ובנייה יש נטייה לברוח מתכנית העבודה, שכן הכלים הדומיננטיים הם כלי הפיתוח ולא הכלים לניהול הפרויקט (גם לא מפת"ח). עם זאת, תקופתית (אחת לחודש?) או לפי אירועים מרכזיים, יש לשוב ולעיין בתכנית העבודה המקורית ולבדוק אם הגיעה אבן דרך מסוימת ואם לא, מדוע. אם צריך לעדכן את תכנית העבודה, יש לעשות זאת.
בכל נקודת זמן יש לוודא שברור לכול הגורמים המעורבים בפרויקט על איזו מהדורה של המערכת מדובר, מה תכולתה, מועד סיומה וכו'. צריך שיהיה גם ברור לכולם שהדרך היחידה להכנסת שינויים היא באמצעות נוהל בקרת שינויים שנקבע בתחילת הדרך. עדיף כמובן ניהול תצורה ובקרת שינויים הנתמכים בכלי ממוכן, אך גם בלי כלי ממוכן אין להזניח נושאים מרכזיים אלה. יש לזכור שניהול תצורה הוא לא רק כלי הנדסי-מקצועי אלא גם כלי ניהולי/עסקי ואמצעי לתקשורת עם הלקוח. ראה הרחבה בנושא זה בקיט ניהול תצורה בכרך נושאים תומכים. כדאי גם לזכור שניהול תצורה בשלב עיצוב ובנייה, הוא הבסיס לניהול תצורה בשלב התחזוקה.
כלים וטכניקות פיתוח אינם בהכרח טובים גם לתצוגה והמחשה. כלים מקצועיים לעיצוב ובנייה עשויים להיות קטלניים בתצוגה והמחשה לפני הלקוח או ההנהלה. האידיאל הוא כלי פיתוח מקצועי שיודע גם להוציא תמציות מנהלים, מערכת לתצוגה והדגמות (tutorial) וכו'. אך לעתים קרובות אין מנוס מלהיעזר בכלי נפרד המיועד לבצע מצגות ולסייע בהסבר ושכנוע. קיימים היום, בפרט במחשבים האישיים ותחנות העבודה, כלים רבים ופשוטים המסייעים במצגות כאלה.
המחשה טובה היא הצגת המערכת עצמה בפעולתה העתידה. מה שאינו ברור בהמחשה זו, לא יהיה ברור גם בעת הפעלת המערכת. ולהפך, כל תיקון ושיפור בהמחשה הוא גם שיפור המערכת הסופית.
שיטות וכלים הנדסיים של תיכון ותכנות מובנים (Structured Design & Programming), תקפים ומחייבים. רצויה ביותר תמיכה ממוכנת של כלים מתאימים בשיטות אלה. כללים אלה מופיעים בהרחבה בספרות הכללית ואין טעם לפרטם במדריך זה. אפשריות, כמובן, גם גישות חדישות יותר כמו גישת האובייקטים (Object Oriented Design). ראה גם קיט גישת האובייקטים בכרך נושאים תומכים.
אין התייחסות בפרק זה למושגים כמו: "עיצוב חיצוני" מול "עיצוב פנימי", "עיצוב כללי" מול "עיצוב מפורט", "עיצוב פונקציונאלי" מול "עיצוב "סטרוקטוראלי" וכו'. מושגים אלה מותנים במתודולוגיות וכלים מסוימים, ומפת"ח איננו מכתיב מתודולוגיה או כלי עיצוב ובנייה אלה או אחרים. בכל מתודולוגיה, כדאי להגדיר תחילה את הממשקים, הן ממשקים חיצוניים עם מערכות מידע אחרות והן ממשקים פנימיים בין תת-מערכות במערכת. ממשקים תוחמים את המערכת ומגדירים את גבולותיה ורכיביה הראשיים.
בנייה של פיילוט (מודל חלוץ) או אבטיפוס תיעשה בלי חיפזון ובהגדרת כוונות ברורה:
· אם הכוונה לאבטיפוס, יש לזכור שבשלב עיצוב ובנייה אין מקום לאבטיפוס (נוסף) לזריקה, אלא לאבטיפוס אבולוציוני בלבד. ראה קיט אבטיפוס Prototyping שבכרך נושאים תומכים.
· אם הכוונה למהדורה ראשונה של המערכת, אין להיחפז ויש לבנותה בצורה מסודרת ובהתאם לכל ההגדרות של השלבים הקודמים: ייזום, אפיון ובקשה להצעות.
בכל מקרה, הפיילוט או האבטיפוס ישתלבו באופן ברור בתכנית העבודה ובתיק העיצוב (ובמערכת עצמה!) ולא ייצרו כפילויות או סתירות.
היה ונשאר נושא מרכזי ביותר, בפרט בעולם GUI והחלונות. ראה הרחבה לסעיף 2.4.0 בקיט עץ מערכת אוניברסלי בכרך נושאים תומכים, הדנה בטכניקות עיצוב ממשק מחשב-אדם. אם עיצוב חיצוני פירושו גיבוש ממשק אדם-מחשב תחילה - הדבר רצוי ונכון. עיצוב הוא הזמן להחליט סופית על התקן' להנדסת אנוש (אם לא נקבע באפיון). ראה גם קיט ממשק אדם מחשב בכרך נושאים תומכים.
מימוש מירב הפרמטרים של המערכת שניתן ע"י טבלאות חיצוניות. בדוק היטב את ההגדרה הקיימת של רכיב 2.10, הרחב-שנה-שכלל בהתאם. וודא שעדכון הטבלאות הוא לא רק קל ונוח אלא גם מבוקר ולא "פרוץ לכל עבר".
בדומה לטבלאות, יש להקפיד על מימוש אלגוריתמים חוזרים ע"י שגרות ואובייקטים משותפים לכלל המערכת. חשוב לנסות אלמנטים משותפים אלה בשלב מוקדם ככל האפשר.
בניית המערכת בשני כיוונים במקביל: "מלמעלה למטה" בעץ המסכים ובעץ המודולים, ו"מלמטה למעלה" בטבלאות, בשגרות ובאובייקטים המשותפים.
ארגון המערכת בספריות (Workspaces, Directories) ציבוריות ופרטיות המוגדרות היטב פיסית ולוגית. ביצוע "פריקה וטעינה" של הספריות והוצאת רשימת מצאי לעיתים תכופות וכן דוחות הממיינים את ה"אובייקטים" השונים (מסכים, מודולים וכו') לפי סימולם (שיוכם לתת-מערכת), תאריך קומפילציה אחרון (וראשון), גודל וכו'.
במערכות גדולות (מסוג ג3) יבוא, לאחר שלב עיצוב ובנייה, שלב בדיקות המערכת. לעובדה זו יש מספר השלכות חשובות על שלב העיצוב:
· רכיבים מסוימים במערכת (רצוי כמה שיותר) חייבים להיבנות כך שהם יהיו ברי-בדיקה (Testable). היינו, ניתן להפעילם בצורה מבוקרת ולוודא שהם מתפקדים נכון וביעילות.
· יש להקפיד על ביצוע מוקדם של בדיקות יחידה וניהול תצורה, בפרט בתת-שלב השילוב. ראה פעילויות 27-35 לעיל. אין טעם למהר להגיע לשלב בדיקות המערכת ולבזבז זמן ומשאבים יקרים על הקמתו, רק בשביל לגלות ממצאים בסיסיים כגון: אין למערכת ניהול תצורה, המערכת נופלת כי חסרות הגדרות קבצים וכיו"ב.
· לאחר שצוות הבדיקות יסיים את עבודתו, יצטרך צוות העיצוב והבנייה להכניס את התיקונים למערכת. יש לתקצב פעולה זו כחלק בלתי נפרד משלב עיצוב ובנייה.
יש לשמור על איזון נכון של נושא הבדיקות תוך כדי העיצוב והבנייה (בדיקות מערכת Online). מחד גיסא זהו דבר רצוי מאד המאפשר לגלות שגיאות בשלב מוקדם. מאידך הצוות העוסק בעיצוב ובנייה צריך לעמוד בלוחות הזמנים והמשאבים שהוקצבו לו ולא להיגרר לבדיקות מערכת "בדלת האחורית". הפתרון: הקפדה על בדיקות יחידה כמוסבר לעיל ובתיק התכנות.
בקש, ביוזמתך, לקיים סקר או דיון אחר כל אימת שחלה סטייה ברורה ממסמך האפיון או שנוצר חשש סביר של חריגה מההערכה המקורית בהיקף של:
· 30% ומעלה לרכיב בודד (טרנזקציה, קובץ וכו')
· 20% ומעלה לתת-מערכת (ראה 2.3 בעץ המערכת)
· 10% ומעלה במערכת כולה (החריגה המקסימלית המותרת בחוזה).
מקד את הסקרים סביב הנקודות הפתוחות, רכיבי 98.X ו- 99.X. קיים את הסקרים כמפורט בקיט סקרים שבכרך נושאים תומכים. וודא שאתה יוצא מהסקר עם תשובות ברורות. אל תוותר! אם במהלך הפיתוח "ברח" הלקוח - רכיב 1.1 כבר לא ברור - התרע מיד!
הבא למערכת את הכלים בהם יש לך ניסיון ומיומנות הגבוהים ביותר. נוהל מפת"ח אינו מגביל גישה זו, אדרבא, מעודד אותה. זאת, בשני תנאים:
· התוצרים (המערכת) יוצגו במבנה עץ המערכת.
· יש להתחשב בכלים קיימים בארגון.
הקפדה על קיום מפגשי הסקר בהתאם לתדירות מוסכמת מראש, ההתקדמות בבניית המערכת (תוצרים) ואבני הדרך שהוגדרו. בכל מקרה, אחת לשבועיים הוא מינימום סביר.
לוודא שהגורם המפתח העלה את כל הנקודות שנשארו פתוחות (רכיבי 99.X) ושניתנה להם תשובה ברורה (ע"י מומחי היישום, הצוות המנהלי וכו').
· בדיקת תיק עיצוב ועקיבות מול האפיון (כולל אב טיפוס), אם הוחלט על בדיקת מסמך עיצוב
· בדיקת השלמות סעיפים רלוונטיים לעיצוב ובמיוחד תיקי תכנון \ תכנות, כולל Unit Test
· פירוט בסיס הנתונים
· בדיקת עמידה בנהלים
· בדיקת עדכון ניתוח סיכונים
· בדיקת תיק בדיקות
· בדיקת מדריך למשתמש (ניתן להיעזר בהרחבה לסעיף 4.7.4: מדריך למשתמש בקיט עץ מערכת אוניברסלי ובגלופת מדריך למשתמש בקיט הטמעת מערכת בכרך נושאים תומכים)
· ביצוע סקרים (סקרים) על תכניות קריטיות
· קבלת אישור לבדיקת מנהלן בסיס הנתונים (DBA), של בסיס הנתונים המתכנן
· בדיקת ביצועים מתכננים
· בדיקת מצב הזמנת ציוד, צפי הגעה
· בדיקת קיום כל התכניות - מול תיק העיצוב
· בדיקת קיום תיעוד בתכניות
· בדיקת ביצוע Unit Test כולל אישור ראש הצוות הנוגע
· בדיקת קיום ניהול תצורה מול מסמך ניהול תצורה - CM
· בדיקת תיעוד שינויים, תוספות רצויות (שו"ש)
· ביצוע סקר קוד (Code Inspection) לתכניות נבחרות
· בדיקת עדכון תיקים רלבנטיים - עיצוב, מדריך למשתמש
· בדיקת ביצועים