מטרת משימה זו היא להגדיר את מפרט התיכון (לפעמים נקרא גם תכן) – Software Design Specification - של הפרויקט שלכם, מפרט שעליו יתבסס בהמשך המימוש. המפרט ייכתב בויקי במאגר הפרויקט (ויתבצע סקר הנדסי על תיכון זה). בנוסף, תעדכנו את תכניות הפיתוח ותדווחו על התקדמות בנושאי סיכונים להצלחת הפרויקט ופיתוח תשתיות.
השפעה על התהליך: מסמכי התיכון מגדירים את מוצר התוכנה שיספק את הדרישות. ההחלטות המתקבלות בהם נסמכות על הדרישות וכן על ההבנה של האפשרויות הטכנולוגיות והרכיבים הזמינים. העבודה על התרשימים השונים עוזרת לתכנן את הרכיבים השונים במערכת, הממשקים והקשרים בינהם ולאחר מכן ניתן לעבור כבר למימוש ובדיקות.
נפגשתם ועבדתם כבר עם הלקוחות כדי לאסוף ולנתח את דרישות המוצר. המשימה הבאה היא לתכנן את המימוש ע”י בחירת ארכיטקטורה מתאימה וניתוח מונחה עצמים ראשוני של התוכנה. פעילויות אלו יעזרו להמשך תכנון ומימוש המוצר שלכם. כשתשלימו את מפרט התיכון ולאחריו ואת רשימת המשימות תוכלו לשכנע את הלקוחות ש:
המפרט נכתב כאוסף דפי ויקי במטרה להגיע לתיכון דינמי ומשותף ככל האפשר. חישבו על דפים אלו כמצגת נושמת המאפשרת לגורם חיצוני להתרשם מהתיכון המוצע.
אפשר להיעזר במאגר התבנית לראשי הפרקים לדפי התיכון וכן להתרשם מפרויקטים קודמים.
עד ערב ההרצאה הבאה עדכון ויקי הפרויקט והגשה בפתיחת כרטיס מוקצה למתרגל ובהודעה מתאימה בפורום הקבוצה.
שתי קבוצות יכולות להירשם לסדר כיתתי על מפרט התיכון.
הניקוד יינתן לפי עמידה בדרישות המשימה שהוגדרו לעיל לפי הסעיפים הבאים כדלקמן:
מבוא ותיאור התוכן העיקרי של המידע, בעיקר:
ראו הפניות במקורות המשימה [1] וההרצאה.
ספקו לפחות: דיאגראמת UML אחת המתארת את הרכיבים הפיסיים (כגון dll, exe, jar) שמתוכננים למוצר שלכם ואת סוג הממשקים ביניהם. את הדיאגרמות יש להכין במוצר ייעודי ל-UML, לשמור את תוכנו ולייצא ממנו תמונות של דיאגרמות הניתנות להצגה בויקי. בנוסף לתרשים יש לתאר בקצרה את הרכיבים השונים ולצרף דיון באשר לשיקולים העיקריים בבחירתם (ראו עקיבות לעיל).
בפרט דיאגרמה זו צריכה להיות מפורטת וטכנית יותר מאשר זו שהגשתם במשימה ראשונה של הצעת הפרויקט.
ספקו לפחות: “תרשים” עם 3-4 “כרטיסי CRC” למחלקות עיקריות שזיהיתם במוצר שלכם, לכל אחת רשימת האחריות והקשרים ביניהן. כמו כן דיאגראמת UML אחת המתארת את הקשרים העיקריים בין המחלקות. אין צורך לפרט ברמה של שדות וארגומנטים אלא בעיקר מתודות חיצוניות (=אחריות) של כל מחלקה.
לצרכי המשך הקורס – חובה שלפחות מחלקה אחת תהיה אחראית על לוגיקת חישוב שאינה טריוויאלית.
השפעה על התהליך: כנראה תמצאו כפילות בין התוצרים בשיטת CRC לבין תרשים המחלקות. אלו שיטות שפותחו בנפרד אך יכולות להשלים אחת את השניה. מטרת המשימה היא שתכירו שיטות שונות ותוכלו בעתיד לבחור את המתאימה ביותר למשימה הנתונה.
ספקו לפחות: דיאגראמת רצף ו\או מצב המציגות את האינטראקציה בין חלקים שונים של המערכת תוך כדי ביצוע פונקציונאליות מסוימת.
תארו כיצד נשמרים נתונים של המערכת, אלו קבצים ייווצרו ומה יהיה המבנה שלהם (ייתכן שתצטרכו תרשים מחלקות נוסף). במקרה שאתם גם מתכננים בסיס נתונים רלאציוני, ספקו תכנון ראשוני של הטבלאות והקשרים ביניהן.
תארו בכמה משפטים כיצד התיכון שהצעתם במסמך זה עונה גם על דרישות כאלו.
עכשיו כשהתמונה ברורה יותר אתם נדרשים לפתח את תכנית ניהול הסיכונים. הוסיפו בעמוד הפיתוח טבלה הכוללת לכל סיכון: - חומרת ההשפעה על הפרויקט (1-3) - הסבירות שהסיכון יתרחש (1-3) - אלו צעדים בוצעו להנמכת הסיכון, בעיקר ברמת התיכון - מה תעשו אם הסיכון יתממש לגבי הסיכון העיקרי דווחו על בדיקה מעמיקה יותר ו\או כיצד אב-טיפוס לתשתית שבניתם עוזר להתמודד עם הסיכון ומה תוצאות הבדיקה כרגע (במשימה הבאה תתבקשו להעלות את הקוד לאתר הפרויקט). במידה ואתם משתמשים בסביבה שונה מזו הנלמדת בקורס יש לספק גם קישורים למקורות ומדריכים בנושא – אחרת אפשר לקשר למצגות התרגול.
יש להתחיל לפתח את התיעוד למשתמש בויקי לפחות ברמה של ראשי פרקים.
תארו אלו מאפיינים של המערכת מתוכננים להיבדק ומדוע זה מספיק. פרטו כיצד יעשו בדיקות אלו. תארו בדיקות יחידה (עבור רכיבים בודדים אך משמעותיים במערכת), בדיקות שילובים (אינטגרציה), בדיקות פונקציונליות\מערכתיות ובדיקות שמישות (usability). כמו כן נסו לקשר את הבדיקות ככל האפשר לדרישות המופיעות במסמך ה-SRS. תארו כיצד תעקבו אחרי תקלות המתגלות תוך כדי שימוש ובדיקות. הערה: מכיוון שנושא הבדיקות טרם נלמד, עשו כמיטב יכולתכם ותכננו לעדכן דף זה באיטרציה שבהמשך הפיתוח. הנה דוגמא אפשרית למבנה הדף: