חזרה לעמוד ראשי
מטרת משימה זו היא להגדיר את מפרט התיכון (לפעמים נקרא גם תכן) – Software Design Specification - של הפרויקט שלכם, מפרט שעליו יתבסס בהמשך המימוש. המפרט ייכתב בויקי במאגר הפרויקט (ויתבצע סקר הנדסי על תיכון זה). בנוסף, תעדכנו את תכניות הפיתוח ותדווחו על התקדמות בפיתוח תשתיות ובכלל בהורדת סיכונים בפרויקט .
ראו בהמשך
השפעה על התהליך: מסמכי התיכון מגדירים את מוצר התוכנה שיספק את הדרישות. ההחלטות המתקבלות בהם נסמכות על הדרישות וכן על ההבנה של האפשרויות הטכנולוגיות והרכיבים הזמינים. העבודה על התרשימים השונים עוזרת לתכנן את הרכיבים השונים במערכת, הממשקים והקשרים בינהם ולאחר מכן ניתן לעבור כבר למימוש ובדיקות. המפרט לא מתוכנן להיות סופי אלא צעד ראשון בתהליך מתמשך.
נפגשתם ועבדתם כבר עם הלקוחות כדי לאסוף ולנתח את דרישות המוצר. המשימה הבאה היא לתכנן את המימוש ע"י בחירת ארכיטקטורה מתאימה וניתוח מונחה עצמים ראשוני של התוכנה. פעילויות אלו יעזרו להמשך תכנון ומימוש המוצר שלכם. כשתשלימו את מפרט התיכון ולאחריו ואת רשימת המשימות תוכלו לשכנע את הלקוחות ש:
- אתם מבינים מהו המוצר שאתם בונים
- יש לכם רעיונות מוצקים כיצד לבנות אותו
- יש לכם את המשאבים המתאימים לעשות זאת (נרחיב זאת במשימה הבאה)
המפרט נכתב כאוסף דפי ויקי במטרה להגיע לתיכון דינמי ומשותף ככל האפשר. חישבו על דפים אלו כמצגת נושמת המאפשרת לגורם חיצוני להתרשם מהתיכון המוצע.
אפשר להיעזר במאגר התבנית לראשי הפרקים לדפי התיכון וכן להתרשם מפרויקטים קודמים.
עד ערב ההרצאה הבאה עדכון ויקי הפרויקט והגשה בפתיחת כרטיס מוקצה למתרגל ובהודעה מתאימה בפורום הקבוצה.
שתיים-שלש קבוצות יכולות להירשם לסקר כיתתי על מפרט התיכון.
הניקוד יינתן לפי עמידה בדרישות המשימה שהוגדרו לעיל לפי הסעיפים הבאים כדלקמן:
- 10% - כללי: מבוא וארגון ה-SDS, האם קריא וברור?
- 60% - היבטי תיכון (תרשימים) – כ-15% לכל היבט, לכל אחד: האם התרשים ברור ופשוט? האם יש עקיבות לדרישות ולסיכונים? האם הוא מביא לידי ביטוי שיקולים שונים? רמת הפירוט בהסבר לכל הביט.
- 20% - סעיפים נוספים - לכל סעיף כ- 5%: שמירת נתונים, דרישות לא-פונקצ', ניהול סיכונים, תיעוד (תכנית בדיקות ראשונית). מספיק תוכן ראשוני אך משמעותי.
- 10% עדכון בעקבות המשוב
- עד להרצאה הבאה - מפרט תיכון כדפי ויקי באתר הפרויקט. המפרט יכיל דף SDS ראשי (מקושר מהעמוד הראשי) עם תוכן כדלקמן והפניות לדפים או פסקאות המכילים דיאגרמות תיכון מזוויות שונות. יש לכלול לפחות ארבעה היבטים הכוללים דיאגראמות UML עם דיון, מתוך הבאות לפי העניין, כמפורט בסעיפים הבאים. כמו כן במסגרת ה-SDS עליכם לעדכן את ניהול הסיכונים בפרויקט להתחיל כבר לתכנן את הבדיקות הנדרשות מהמוצר ואת התיעוד שיימסר ללקוח (בדרך זו תוכלו בהמשך להעריך יותר נכון את המאמץ הכולל הנדרש).
- יומיים אחרי קבלת המשוב, פרסום רשימת משימות נגזרות כתוצאה מהסקרים, עדכון מסמכי התיכון כתוצאה מהסקר (הגשת המשימה בטופס כולל סיכום ו\או קישור לדפי היסטוריה שבהם ניתן לראות בהערות את השינוי שהתבצע).
מבוא ותיאור התוכן העיקרי של המידע, בעיקר:
- תיאור המטרות העיקריות של דפי התיכון (בסדר יורד), למשל הכנה למימוש, בדיקת נכונות, בדיקתיות, יעילות וכדו'.
- רשימה כללית של יכולות (capability) עיקריות של המוצר ממוינות לפי סדר מימוש ראשוני מתוכנן ובהתאם לסיכון שבאי-מימושן. היכולות הן בעיקר עסקיות (צרכי הלקוח העיקריים) אבל גם טכניות (ביצועים, מהירות וכדו׳). דוגמאות:
- גישה מבוססת ווב על בסיס ספק PaaS (למשל Microsoft Azure).
סיכון עיקרי: טרם התנסינו בכתיבת מחסנית מליאה מבוססת ווב. באמצעות אב-הטיפוס שאנחנו בונים והשרותים הניתנים ע"י הספק (כגון אחסון נתונים) נוכל לספק פונקציונליות עיקרית בהקדם (דרישה מקורית: גישה לשרות ללא צורך בהתקנות). - אימות שהמשתמש אנושי
סיכון משני: לא צפויים משתמשים רבים בשלב ראשון ובנוסף אפשר לתת מענה טוב ע"י שימוש ב- reCAPTCHA (דרישה מקורית: מניעת התקפות Denial of Service)
**עקיבות**: בהמשך למבוא, לכל דיאגראמה שבחרתם לשרטט בסעיפים הבאים הסבירו במידת הצורך את הרכיבים המופיעים בה ופרטו על אלו דרישות וסיכונים ממפרט הדרישות היא עונה. בד"כ יש להראות שכל הדרישות מכוסות ע"י התיכון, אך אנו נסתפק בעיקריות שבהן. 3. הפניות לתיעוד נוסף: דיאגרמות UML, ניהול סיכונים מעודכן, מדריך למשתמש ותוצאות סקר תיכון.
ראו הפניות במקורות המשימה וההרצאה.
ספקו לפחות: דיאגראמת UML אחת המתארת את הרכיבים הפיסיים (כגון dll, exe, jar) שמתוכננים למוצר שלכם ואת סוג הממשקים ביניהם. את הדיאגרמות יש להכין במוצר ייעודי ל-UML, לשמור את תוכנו ולייצא ממנו תמונות של דיאגרמות הניתנות להצגה בויקי. בנוסף לתרשים יש לתאר בקצרה את הרכיבים השונים ולצרף דיון באשר לשיקולים העיקריים בבחירתם (ראו עקיבות לעיל).
בפרט דיאגרמה זו צריכה להיות מפורטת וטכנית יותר מאשר זו שהגשתם במשימה ראשונה של הצעת הפרויקט.
ספקו לפחות: "תרשים" עם 3-4 "כרטיסי CRC" למחלקות עיקריות שזיהיתם במוצר שלכם, לכל אחת רשימת האחריות והקשרים ביניהן. כמו כן דיאגראמת UML אחת המתארת את הקשרים העיקריים בין המחלקות. אין צורך לפרט ברמה של שדות וארגומנטים אלא בעיקר מתודות חיצוניות (=אחריות) של כל מחלקה.
לצרכי המשך הקורס – חובה שלפחות מחלקה אחת תהיה אחראית על לוגיקת חישוב שאינה טריוויאלית.
השפעה על התהליך: כנראה תמצאו כפילות בין התוצרים בשיטת CRC לבין תרשים המחלקות. אלו שיטות שפותחו בנפרד אך יכולות להשלים אחת את השניה. מטרת המשימה היא שתכירו שיטות שונות ותוכלו בעתיד לבחור את המתאימה ביותר למשימה הנתונה.
ספקו לפחות: דיאגראמת רצף ו\או מצב המציגות את האינטראקציה בין חלקים שונים של המערכת תוך כדי ביצוע פונקציונאליות מסוימת.
תארו כיצד נשמרים נתונים של המערכת, אלו קבצים ייווצרו ומה יהיה המבנה שלהם (ייתכן שתצטרכו תרשים מחלקות נוסף). במקרה שאתם גם מתכננים בסיס נתונים רלאציוני, ספקו תכנון ראשוני של הטבלאות והקשרים ביניהן.
תארו בכמה משפטים כיצד התיכון שהצעתם במסמך זה עונה גם על דרישות כאלו.
עכשיו כשהתמונה ברורה יותר אתם נדרשים לפתח את תכנית ניהול הסיכונים. הוסיפו בעמוד הפיתוח טבלה הכוללת לכל סיכון:
- חומרת ההשפעה על הפרויקט (1-3)
- הסבירות שהסיכון יתרחש (1-3)
- אלו צעדים בוצעו להנמכת הסיכון, בעיקר ברמת התיכון
- מה תעשו אם הסיכון יתממש לגבי הסיכון העיקרי דווחו על בדיקה מעמיקה יותר ו\או כיצד אב-טיפוס לתשתית שבניתם עוזר להתמודד עם הסיכון ומה תוצאות הבדיקה כרגע (במשימה הבאה תתבקשו להעלות את הקוד לאתר הפרויקט). במידה ואתם משתמשים בסביבה שונה מזו הנלמדת בקורס יש לספק גם קישורים למקורות ומדריכים בנושא – אחרת אפשר לקשר למצגות התרגול.
יש להתחיל לפתח את התיעוד למשתמש בויקי לפחות ברמה של ראשי פרקים.
תארו אלו מאפיינים של המערכת מתוכננים להיבדק ומדוע זה מספיק. פרטו כיצד יעשו בדיקות אלו. תארו בדיקות יחידה (עבור רכיבים בודדים אך משמעותיים במערכת), בדיקות שילובים (אינטגרציה), בדיקות פונקציונליות\מערכתיות ובדיקות שמישות (usability). כמו כן נסו לקשר את הבדיקות ככל האפשר לדרישות המופיעות במסמך ה-SRS. תארו כיצד תעקבו אחרי תקלות המתגלות תוך כדי שימוש ובדיקות. הערה: מכיוון שנושא הבדיקות טרם נלמד, עשו כמיטב יכולתכם ותכננו לעדכן דף זה באיטרציה שבהמשך הפיתוח. הנה דוגמא אפשרית למבנה הדף:
- תכנון בדיקות יחידה (לרכיב\ים משמעותי\ים) א. מהי הבדיקה (מטרה וכיסוי) ב. אופן פיתוח הבדיקה ועל ידי מי ג. תדירות שימוש בבדיקה
- תכנון בדיקות מערכתיות א. כנ"ל
- תכנון בדיקות שמישות \ חווית משתמש
- כיצד תעקבו אחרי תקלות שייתגלו
- Amber, Introduction to Object-Orientation and the UML, Especially see:
- deployment diagrams (and guidelines),
- class diagrams (and guidelines),
- sequence diagrams (and guidelines),
- CRC Models (and another good explanation).
- Hiranabe, Modeling in the Agile Age: What to Keep Next to Code to Scale Agile Teams