RSS לפוסטים RSS לתגובות 228 מאמרים ו- 1,988 תגובות עד כה מאז 2005

סימסטר א' – פרוייקטים

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

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

1. מודל מקרה-שימוש (Use-case model)

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

דוגמא למודל מקרה-שימוש גרפי

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

2. דיאגרמת מחלקות (Class diagram)

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

דוגמא לדיאגרמת מחלקות

3. דיאגרמת רצף-פעולות (Sequence diagram)

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

דוגמא לדיאגרמת רצף-פעולות

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

הקורס השני אותו אני לומד בסימסטר הנוכחי מהווה מבוא לעיצוב ממוקד משתמש ונקרא Human-Computer Interaction Design. הפרוייקט לקורס הזה הוא קבוצתי וכולל הצעה לתיכנון של מערכת אינטאקטיבית כלשהי. המטרה היא להציע מערכת ולתאר את טכניקות איסוף המידע שייושמו במקביל להכנת אב-טיפוס מנייר (Paper prototypes). הפרוייקט כולל מסמך כתוב הכולל את החלקים הבאים:
1. תיאור המערכת והנושאים השונים שעלו בשלב הניתוח (משתמשים, מטלות, הקשרים תרבותיים-חברתיים-קוגנטיבים וכו').
2. תיאור החלטות עיצוביות-תיכנוניות הקשורות לנגישות המערכת עבור אנשים עם מיגבלות מסויימות ואוכלוסיית המשתמשים הזקנים.
3. תיאור בדיקת אב-הטיפוס המוצע בכדי להבטיח שמישות מירבית.

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

דוגמא לתיאור דמות (Persona)

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

4 תגובות על “סימסטר א' – פרוייקטים”

  1. 29/10/2005 בשעה 13:54 בועז חן

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

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

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

  2. 29/10/2005 בשעה 14:05 אמיר דותן

    היי בועז,

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

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

  3. 29/10/2005 בשעה 14:41 צחי פלד

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

  4. 01/11/2005 בשעה 6:48 אמיר דותן

    היי צחי,

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

RSS לתגובות לפוסט זה

הוספת תגובה