מדריך זה דן בנושא אב טיפוס (Prototyping) ובאופן בו מומלץ לשלב טכניקה חשובה זו בתהליך פיתוח המערכת. טכניקה זו שימושית מאד להמחשת המערכת, לבדיקה של נושאים קריטיים להצלחה (CSF’s), להגברת שיתוף המשתמש ועוד. לטכניקה זו יש השלכות מרכזיות על ניהול הפרויקט ויש לדעת היטב מתי וכיצד לנצלה. יש גם להבחין בין סוגים שונים של אבטיפוס כמוסבר בקיט זה.
אב טיפוס (Prototyping) היא טכניקה חשובה ביותר לצורך המחשת המערכת, בדיקה של נושאים קריטיים להצלחה (CSF’s), הגברת שיתוף המשתמש, שיפור האפיון, העלאת איכות המערכת, דיון בחלופות, סגירת נקודות פתוחות ועוד. עם זאת, אבטיפוס מסוג זה, הנקרא גם דגם, "אינו בחינם" ויש לדעת היטב מתי וכיצד לנצל טכניקה זו. מפת"ח מעודד שימוש באבטיפוס ומאפשר שילוב מושכל של טכניקה חשובה זו במהלך פיתוח המערכת. היכולת לשלב אבטיפוס או דגם בעבודה לפי מפת"ח נובעת מתפיסת מפת"ח המבוססת על:
· רעיון עץ המערכת המתמקד בתוצרים (Deliverables) – אבטיפוס הוא סוג של תוצר, תוצר מוקדם אשר "מבשר" את התוצרים שיבואו בהמשך (first-cut deliverable)
· עדיפות עץ המערכת על מחזור החיים, היינו, דגש יותר על מה תעשה המערכת ופחות על איך היא תיבנה - אבטיפוס גם הוא שואף להתקדם ולהמחיש את המערכת ולא את תהליך הפיתוח
· המשכיות התוצרים במעבר משלב לשלב - אבטיפוס שואף גם הוא להעביר את תוצריו, פיסית או לפחות לוגית, לשלב הבא
· "דחיפה" לשימוש חוזר בחלקי מערכת והבאת כל רכיב אל המדיום הסופי שלו בדרך הקצרה ביותר – אבטיפוס מעדיף את המדיום "הפיסי" (אם כי לא בהכרח הסופי) על פני מדיום התיעוד
· התמקדות ברכיבים קריטיים להצלחה (CSF’s).
השילוב הפיסי בין תיק המערכת שמפת"ח דורש לבין תוצרי האבטיפוס יכול להיעשות במספר דרכים כשהקו המנחה הוא האפשרות להעביר את תוצרי האבטיפוס לתיק האפיון, או להצביע מהתיק אל האבטיפוס (באמצעות היפר קישור.
ראה קיט אפיון וקיט עיצוב ובנייה בכרך יסודות/מחזור חיים.
באופן טבעי, יש לנושא אבטיפוס קשר הדוק עם נושא ממשק אדם מחשב. חלק ניכר מהמקרים בהם מפותח אבטיפוס הוא עבור המחשת ממשק המשתמש ו\או בדיקת היתכנותו.
ראה הקיט ממשק אדם מחשב בכרך נושאים תומכים.
מקובל להבחין בשני סוגים עיקריים של אבטיפוס:
· אבטיפוס אבולוציוני (מתגלגל)
· אבטיפוס לזריקה
להלן סקירה תמציתית של שני סוגים עיקריים אלה וכן אזכור של סוגים ומונחים נוספים.
זהו מודל ראשוני של המערכת (או של חלקים ממנה) אשר בא להדגים אותה באופן פונקציונלי. בנוסף, במידה שהדגם הראשוני מאושר, משמש אבטיפוס מסוג זה בסיס להמשך הרחבת המערכת ופיתוחה. במילים אחרות, על בסיס אבטיפוס אבולוציוני תיבנה מהדורה פעילה ראשונה של המערכת. מתחייב מכך שאבטיפוס מסוג זה ייבנה על מחשב המטרה או שיש בנמצא כלי הסבה נוחים ואמינים אשר יבצעו את ההסבה ממחשב הפיתוח למחשב המטרה בצורה שקופה. שימוש באבטיפוס מסוג זה ייתכן באחד מהאופנים הבאים:
· בשלב העיצוב והבנייה
· בשלב האפיון, בתנאי שתבוצע הסבה שקופה לסביבת הפיתוח. ביציאה למכרז, מתווסף תנאי שהאבטיפוס, הנלווה למפרט, ייבנה בכלי "אוניברסלי" שאינו מונע מרוב הספקים להשתמש בו.
זהו מודל פונקציונאלי של המערכת (או של חלקים ממנה). השימוש היחיד של אבטיפוס מסוג זה הוא הדגמה פונקציונלית, במטרה לקדם את רמת הוודאות של המערכת (אישור המשתמש למשל). אבטיפוס מסוג זה ייבנה במהלך שלב האפיון ולאחר מכן "ייזרק", היינו, לא ייעשה שימוש ישיר בתוצריו הממוכנים בשלבים הבאים. שימוש באבטיפוס מסוג זה הוא בשלב האפיון בלבד!
חלוקה זו לשני סוגים של אבטיפוס היא נכונה ברמה העקרונית, אך בפועל, ישנם סוגי "ביניים" כגון אבטיפוס להסבה, היינו, אבטיפוס שהכלי עליו הוא נבנה אינו בר-המשך, אך ההגדרות הלוגיות שמוכלות בו הן נכונות ורצוי מאד (אם יש אפשרות טכנית) להסב הגדרות אלה לכלי הפיתוח והבנייה של המערכת. מההיבט הטכני זהו אב טיפוס לזריקה, בעוד שמההיבט הלוגי/פונקציונאלי זהו אב טיפוס אבולוציוני.
בפועל תיתכנה גם "זחילות" מסוג אבטיפוס אחד לאחר. "זחילה" בלתי מבוקרת מאבטיפוס לזריקה לאבטיפוס אבולוציוני (ומהאחרון ל"מהדורה 1" של המערכת וכך הלאה מ"מהדורה" ל"מהדורה"), היא שכיחה אך בלתי רצויה. נוהל מפת"ח מציע את הבקרות הבאות למניעת "זחילה" כזו:
· אבטיפוס בכלל, אבטיפוס לזריקה בפרט, ייבנו ב- single user mode ולא יאפשרו עבודה ב- Multi-user.
· בסיס הנתונים של האבטיפוס (ויכולת האחסון) יוגבל למספר מצומצם של רשומות ואירועים והוא לא יורחב במהלך ההדגמות.
· אבטיפוס יבנה על מחשבים אישיים.
· באבטיפוס לא יטופלו נושאים טכניים כגון: חוסן ואמינות (גיבוי והתאוששות), פעולות Housekeeping, ביצועים, תקשורת וכיוב' - אלא אם כן נושאים אלה הם המטרה של האבטיפוס.
· אבטיפוס הנבנה בשלב העיצוב והבנייה יהיה אך ורק מהסוג האבולוציוני. בשלב האפיון ייבנה אבטיפוס לזריקה בלבד.
· בשלב הבקשה להצעות יצוין קיומו של אבטיפוס והספקים יתבקשו להציע כלי הסבה מהאבטיפוס לכלי הפיתוח הסופיים.
ראה הרחבה לרכיב 3.13 בקיט עץ מערכת אוניברסלי בכרך יסודות.
· אבטיפוס ישתלב באופן ברור במסמך האפיון ו/או העיצוב ויתרום את חלקו לרכיבים מוגדרים.
נוהל מפת"ח מעודד, כאמור, את השימוש באבטיפוס בעצם התפיסה שהנוהל מציג, אך אין הוא מחייב שימוש זה. להוציא מקרה אחד:
דגם הוא סוג של אבטיפוס אבולוציוני בו מצהירים מראש שאין בעצם אבטיפוס, אלא פיתוח הדרגתי של המערכת על בסיס דגם ששימש בהתחלה כאבטיפוס, אבל בהמשך עובר להיות "המערכת עצמה".
בניית אבטיפוס היא משימה הדורשת משאבים גדולים וסובלת, כאמור, מבעיה חמורה של "זחילה כפולה":
· זחילה של האבטיפוס עצמו אשר מתחיל בד"כ ב"משימה קלה של יום-יומיים עבודה" ונגמרת בהשקעה של מס' חודשי אדם
· זחילה של האבטיפוס לתוך הפרויקט עצמו (בין השאר, בעקבות הזחילה הראשונה), היינו, הכתבה של טכנולוגיה וגישה ליישום שלא תוכננו מראש.
זחילות אלה הן מאד מסוכנות משום שהן גורמות לכך שהמערכת נבנית, בעצם, ב"דלת האחורית", תוך עקיפה של ניהול פרויקט מסודר. אם המטרה העיקרית היא הצגה והמחשה של רכיבי מערכת מסוימים: מסכים, דו"חות, תהליכי עבודה וכו', כדאי מאד לשקול, כתחליף טוב וזול לאבטיפוס, שימוש בכלים (גרפיים) המתמחים במצגות והמחשות, כגון: שקפים "חיים", שרטוט "במקום" וכו'. כלים אלה יכולים לתת "80%" ממה שנותן אבטיפוס, בעלות נמוכה בהרבה ובלי לגרום לזחילות למיניהן. בדרך זו, גם למשתמש ברור שזו רק מצגת ולא המערכת עצמה. בנוסף, המצגת תשולב עם תיק האפיון (למשל), כך שיהיה ברור שאין היא באה במקום המסמך הפורמלי והמחייב (שזו שוב בעיה מרכזית של טכניקת אבטיפוס).
עם כל הרצון לא להיסחף ולא להגזים, במקרים מסוימים עשוי האבטיפוס להתפתח למיני-פרויקט בפני עצמו, למעין "פרויקט בתוך פרויקט". זאת בפרט במקרים בהם הוכחת התפיסה (POC) הנדרשת היא מקיפה ורחבה וכוללת מרכיבי יישום, טכנולוגיה ושילוב ביניהם (כולל שילוב משתמשים פוטנציאליים). מקרה זה הוא, אגב, דווקא באבטיפוס לזריקה! באבטיפוס מתגלגל ייעשה הדבר כחלק מפיתוח "מהדורה 0" של המערכת שהיא עצמה הוכחת תפיסה.
תוך כדי האפיון, מקצים צוות מיוחד ש"יבנה במהירות" ובמקביל לאפיון המובנה את האבטיפוס. "בנייה מהירה" זו תכלול בסופו של דבר את אותם שלבים שיש בכל פרויקט אחר, אם כי "במוקטן":
· ייזום – מישהו מעלה את הרעיון. הוא עשוי אפילו להידרש להעלות את הרעיון בכתב. ראה טופס ייזום בקיט ייזום מערכת בכרך יסודות\מחזור חיים.
· אפיון – הגדרה מהירה של התכונות העיקריות הנדרשות מהאבטיפוס. מוצע לעבור מטופס הייזום למסמך הייזום שם. אין צורך במסמך אפיון.
· עיצוב ובנייה – בניית האבטיפוס
· בדיקות – בדיקה זריזה של האבטיפוס. תקלות באבטיפוס אינן "סוף העולם", אבל אבטיפוס שאינו מדגים את מה שנדרש ממנו, או שעושה זאת לא נכון – יצא שכרו בהפסדו.
· תחזוקה!!
אבטחת איכות ובקרה על שימוש באבטיפוס מתבססת על הנקודות הבאות:
א. פירוק האבטיפוס לפי רכיבי עץ המערכת: עבור אלו רכיבים בדיוק נבנה האבטיפוס, מדוע נחוץ האבטיפוס, מה קורה לקשרים עם רכיבים אחרים ועוד:
· 2.4: הדגמת ממשק המשתמש?
· 2.5-2.6: המחשת תהליכים וטרנזקציות מיוחדים?
· 3.0: הוכחת תפיסה (POC) של ארכיטקטורת הפתרון הטכנולוגי? (מקרה קיצוני ומיוחד!)
ב. פירוק האבטיפוס לפי שלבי מחזור החיים:
· משרת את האפיון?
· מתוכננת יציאה למכרז? איך ישתלב האבטיפוס בבקשה להצעות?
· עיצוב ובנייה: חלק מחוזה ההתקשרות עם הספק?
· בדיקות: רלוונטי? ישמש כמודל השוואתי? חלק מהגדרת הדרישות (האפיון)?
ג. הבחנה בין סוגי אבטיפוס שונים ותקפותם לשלבי מחזור החיים, כמוסבר לעיל.
ד. מידת ההשקעה באבטיפוס:
· במונחים אבסולוטיים
· יחסית להשקעה בפרויקט כולו?
ה. שימוש בכלים:
· כלים ייעודיים – חלק מכלי התכנון (CASE)
· כלי הפיתוח הסופיים של המערכת