קורס ניתוח מערכות - האם כדאי ?
- פותח הנושא zakozak
- פורסם בתאריך
מנתח מערכות זה תחום די שונה מתכנות
אני זוכר שהדבר הראשון שאמרו לנו בקורס ניתוח מערכות זה "מעכשיו אתם לא תוכניתנים יותר, תפסיקו לחשוב קוד" (או משהו בסגנון). התפקיד העיקרי של מנתח מערכות הוא להגדיר את דרישות המערכת, כלומר, מה המערכת אמורה לבצע, וזאת בהתאם לדרישות אותם מעלה לקוח המערכת ומשתמשי המערכת. התוצר של עבודת מנתח מערכות הוא מה שמכונה "תיק אפיון" שזה מסמך שמפרט את התהליכים שהמערכת אמורה לתמוך בהם, פירוט של איך התהליכים עובדים (מה אמור להתבצע בכל אחד מהם), עיצוב של מסכי המערכת, תיאור המידע שנשמר במערכת, פירוט על אילו ממשקים יש למערכת עם מערכות חיצוניות (בין אם לקבלת מידע או להוצאת מידע) - זה מבחינת התוכן של המערכת. מסמכי אפיון באים בורסיות שונות, בהתאם לנוהל לפיו המסמך נכתב (ישנם נהלים ישראליים כגון נוהל מפת"ח, נהלים בין לאומיים כגון ISO ונהלים ארגוניים כגון ה-MSF של מיקרוסופט), אבל העקרון די דומה. מנתח מערכות לא אמור להתעסק כמעט בשפות תכנות או בטכנולוגיה, אבל הוא כן אמור להיות מודע להם. מה הכוונה ? כשאתה מגדיר תהליך, אתה לא אמור להגדיר איך יראו המתודות ואיך תבוצע חלוקת הקלאסים בקוד, אבל יש יתרון לפעמים לידיעת מגבלות כגון מגבלות טכנולוגיות בעבודה עם דפדפן בתור frontend (מבחינת העיצוב הגרפי של המערכת). המעבר הוא לא מעבר הכי נוח בעולם, אני יודע מנסיון שבהתחלה היה לי קשה להפריד בין קוד לבין אפיון, אבל מסתגלים. הדבר הראשון שאתה צריך להפנים הוא שאתה לא תוכניתן יותר, ואם קשה לך עם זה, אם ימיך בתור מנתח הם ספורים. לגבי האם קורס - אם אתה רוצה להתקבל לעבודה בתור מנתח מערכות, יש יתרון לקורס כי זה מראה שעברת הכשרה מקצועית ולא רק קראת ספר. אם מצד שני, מציעים לך איפה שאתה עובד להתחיל לעבוד בתור מנתח, אפשר לנסות בלי קורס, אבל חשוב להבין שבגלל שלנתח מערכת זה לא "השלב הבא" של תוכניתן אלא תפקיד אחר, ייתכן שבלי קורס או הכשרה כלשהי, אתה תרגיש כמו דג שהוציאו אותו מהמים. לגבי קורס - ישנם הרבה מקומות שמעבירים קורסי ניתוח (כגון ג'ון ברייס, היי-טק ושאר ה"מכללות"), אבל מה שחשוב זה התוכן של הקורס ומה שצריך לחפש בתוכן זה : - הקורס הוא קורס Object Oriented Analysis (בקיצור OOA). היום שיטות ניתוח שאינן OO נתפסות כמיושנות ובהרבה מקומות, עם הכנסת שפות פיתוח OO, ישנה דרישה שגם הניתוח יבוצע ב-OO על-מנת להקל על המעבר מהאפיון לפיתוח - התוצרים נכתבים בשפת UML - שפת UML היא שפה לבניית דיאגרמות המהוות חלק מתוצר האפיון. קורס שאינו בנוי סביב UML הוא קורס ישן מדי - פרויקט "מהחיים" - הדבר הכי חשוב הוא שניתן יהיה להתנסות על פרויקט אמיתי ולא סתם פרויקט "בלוף" שהמציאו לפני הקורס, כי למנתח חשוב להתנסות עם לקוחות אמיתיים ולא עם שחקנים. ישנם מקומות שמבקשים מהאנשים שמגיעים לקורס להביא איתם רעיונות לפרויקטים. - הכרה בקורס - אם חשוב לך שהקורס יחשב, אל תלך לעשות אותו במכללת "אנחנו מלמדים בזול" - תכנס לאתר של לשכת מנתחי המערכות (כן, יש דבר כזה) בכתובת www.sysnan.co.il ותראה איפה מבוצעים הקורסים שמוכרים ע"י הלשכה (לא מחייב, אבל זה בסה"כ אומר שהקורס נבחן ע"י מומחים והוא נראה טוב)
אני זוכר שהדבר הראשון שאמרו לנו בקורס ניתוח מערכות זה "מעכשיו אתם לא תוכניתנים יותר, תפסיקו לחשוב קוד" (או משהו בסגנון). התפקיד העיקרי של מנתח מערכות הוא להגדיר את דרישות המערכת, כלומר, מה המערכת אמורה לבצע, וזאת בהתאם לדרישות אותם מעלה לקוח המערכת ומשתמשי המערכת. התוצר של עבודת מנתח מערכות הוא מה שמכונה "תיק אפיון" שזה מסמך שמפרט את התהליכים שהמערכת אמורה לתמוך בהם, פירוט של איך התהליכים עובדים (מה אמור להתבצע בכל אחד מהם), עיצוב של מסכי המערכת, תיאור המידע שנשמר במערכת, פירוט על אילו ממשקים יש למערכת עם מערכות חיצוניות (בין אם לקבלת מידע או להוצאת מידע) - זה מבחינת התוכן של המערכת. מסמכי אפיון באים בורסיות שונות, בהתאם לנוהל לפיו המסמך נכתב (ישנם נהלים ישראליים כגון נוהל מפת"ח, נהלים בין לאומיים כגון ISO ונהלים ארגוניים כגון ה-MSF של מיקרוסופט), אבל העקרון די דומה. מנתח מערכות לא אמור להתעסק כמעט בשפות תכנות או בטכנולוגיה, אבל הוא כן אמור להיות מודע להם. מה הכוונה ? כשאתה מגדיר תהליך, אתה לא אמור להגדיר איך יראו המתודות ואיך תבוצע חלוקת הקלאסים בקוד, אבל יש יתרון לפעמים לידיעת מגבלות כגון מגבלות טכנולוגיות בעבודה עם דפדפן בתור frontend (מבחינת העיצוב הגרפי של המערכת). המעבר הוא לא מעבר הכי נוח בעולם, אני יודע מנסיון שבהתחלה היה לי קשה להפריד בין קוד לבין אפיון, אבל מסתגלים. הדבר הראשון שאתה צריך להפנים הוא שאתה לא תוכניתן יותר, ואם קשה לך עם זה, אם ימיך בתור מנתח הם ספורים. לגבי האם קורס - אם אתה רוצה להתקבל לעבודה בתור מנתח מערכות, יש יתרון לקורס כי זה מראה שעברת הכשרה מקצועית ולא רק קראת ספר. אם מצד שני, מציעים לך איפה שאתה עובד להתחיל לעבוד בתור מנתח, אפשר לנסות בלי קורס, אבל חשוב להבין שבגלל שלנתח מערכת זה לא "השלב הבא" של תוכניתן אלא תפקיד אחר, ייתכן שבלי קורס או הכשרה כלשהי, אתה תרגיש כמו דג שהוציאו אותו מהמים. לגבי קורס - ישנם הרבה מקומות שמעבירים קורסי ניתוח (כגון ג'ון ברייס, היי-טק ושאר ה"מכללות"), אבל מה שחשוב זה התוכן של הקורס ומה שצריך לחפש בתוכן זה : - הקורס הוא קורס Object Oriented Analysis (בקיצור OOA). היום שיטות ניתוח שאינן OO נתפסות כמיושנות ובהרבה מקומות, עם הכנסת שפות פיתוח OO, ישנה דרישה שגם הניתוח יבוצע ב-OO על-מנת להקל על המעבר מהאפיון לפיתוח - התוצרים נכתבים בשפת UML - שפת UML היא שפה לבניית דיאגרמות המהוות חלק מתוצר האפיון. קורס שאינו בנוי סביב UML הוא קורס ישן מדי - פרויקט "מהחיים" - הדבר הכי חשוב הוא שניתן יהיה להתנסות על פרויקט אמיתי ולא סתם פרויקט "בלוף" שהמציאו לפני הקורס, כי למנתח חשוב להתנסות עם לקוחות אמיתיים ולא עם שחקנים. ישנם מקומות שמבקשים מהאנשים שמגיעים לקורס להביא איתם רעיונות לפרויקטים. - הכרה בקורס - אם חשוב לך שהקורס יחשב, אל תלך לעשות אותו במכללת "אנחנו מלמדים בזול" - תכנס לאתר של לשכת מנתחי המערכות (כן, יש דבר כזה) בכתובת www.sysnan.co.il ותראה איפה מבוצעים הקורסים שמוכרים ע"י הלשכה (לא מחייב, אבל זה בסה"כ אומר שהקורס נבחן ע"י מומחים והוא נראה טוב)
תודה רבה על התשובה - והמשך שאלות ..
קודם כל תודה רבה על התשובה.. שנית - מה מצב שוק המנתחים בארץ ? האם יש בזה עבודה יותר פחות ממתכנתים? איך תנאי השכר בטווחים ? אני מבין שזה תחום אחר לגמרי - אך לי אישית זה נראה מעניין יותר להסתכל על מערכת מלמעלה - להבין את דרישות הלקוחות ולהעבירם לצורה מסודרת שמתכנת יוכל להבין
קודם כל תודה רבה על התשובה.. שנית - מה מצב שוק המנתחים בארץ ? האם יש בזה עבודה יותר פחות ממתכנתים? איך תנאי השכר בטווחים ? אני מבין שזה תחום אחר לגמרי - אך לי אישית זה נראה מעניין יותר להסתכל על מערכת מלמעלה - להבין את דרישות הלקוחות ולהעבירם לצורה מסודרת שמתכנת יוכל להבין
אז ככה
1. שוק המנתחים בארץ הוא קטן יחסית לעומת שוק התוכניתנים, גם מבחינת כמות האנשים במקצוע וגם מבחינת הדרישה. למנתחי מערכות תמיד יש דרישה, אם כי לתחום הזה לרוב נדרש נסיון (רוב המודעות שראיתי דרשו לפחות 3 שנים נסיון) וגם לעתים נדרשת התמקצעות בתחומים מסוימים (תחום הניתוח גם הוא מגוון כתחום התכנות ויש נושאים שונים בהם ניתן להתמקצע כמו ניתוח מערכות מידע, ניתוח מערכות DWH, ניתוח מערכות BI וכו') 2. תנאי השכר של מנתח הם לא בשמים. מנתח מערכות מתחיל מרוויח בערך כמו תוכניתן מתחיל ומנתח מערכות בכיר מרוויח קצת פחות מתוכניתן בכיר. אתה יכול לגשת לפורום "מובטלי הייטק" ולמצוא בקישורים שם הפניות לטבלאות שכר 3. בין תכנות לניתוח יש עוד תחום שמכונה עיצוב. לא הרבה גופים מיישמים את התחום הזה בתור תפקיד פרופר - בהרבה מקומות הוא משתלב יחד עם תפקיד המנתח או תפקיד התוכניתן, אבל לפעמים תוכניתנים מעדיפים את התפקיד הזה כי הוא - א. מסתכל יותר מלמעלה על המערכת ו-ב. קשור מאוד לטכנולוגיה ולסביבת הפיתוח. אם תרצה, אוכל להרחיב יותר לגבי התפקיד.
1. שוק המנתחים בארץ הוא קטן יחסית לעומת שוק התוכניתנים, גם מבחינת כמות האנשים במקצוע וגם מבחינת הדרישה. למנתחי מערכות תמיד יש דרישה, אם כי לתחום הזה לרוב נדרש נסיון (רוב המודעות שראיתי דרשו לפחות 3 שנים נסיון) וגם לעתים נדרשת התמקצעות בתחומים מסוימים (תחום הניתוח גם הוא מגוון כתחום התכנות ויש נושאים שונים בהם ניתן להתמקצע כמו ניתוח מערכות מידע, ניתוח מערכות DWH, ניתוח מערכות BI וכו') 2. תנאי השכר של מנתח הם לא בשמים. מנתח מערכות מתחיל מרוויח בערך כמו תוכניתן מתחיל ומנתח מערכות בכיר מרוויח קצת פחות מתוכניתן בכיר. אתה יכול לגשת לפורום "מובטלי הייטק" ולמצוא בקישורים שם הפניות לטבלאות שכר 3. בין תכנות לניתוח יש עוד תחום שמכונה עיצוב. לא הרבה גופים מיישמים את התחום הזה בתור תפקיד פרופר - בהרבה מקומות הוא משתלב יחד עם תפקיד המנתח או תפקיד התוכניתן, אבל לפעמים תוכניתנים מעדיפים את התפקיד הזה כי הוא - א. מסתכל יותר מלמעלה על המערכת ו-ב. קשור מאוד לטכנולוגיה ולסביבת הפיתוח. אם תרצה, אוכל להרחיב יותר לגבי התפקיד.
מחזור חיים
בעיקרון ישנם מספר סוגים של "מחזור חיים" לשלב הניתוח. זה תלוי במתודולוגיה הנבחרת (ישנן מתודולוגיות רבות שעוסקות בתחום). יתר על כן, המושג מחזור חיים מתייחס למערכת כולה, לאו דווקא לשלב זה או אחר. בעיקרון, ניתן לאמר כי שלב הניתוח/עיצוב בהכללה מתחלק לשלבי המשנה הבאים:ייזום. חקר מצב/מערכת קיימים (כיום בשלב זה משקיעים הרבה פחות מאשר בעבר). מיפוי הבעיות והגדרת דרישות מהמערכת הנדרשת. בניית אב טיפוס (שלב אופציונאלי, תלוי בגודל המערכת). חקר ישימות ובחירת חלופה מועדפת. אפיון המערכת החדשה. אפיון המערכת יכול לכלול הרבה מאוד דברים וברמות פירוט שונות (תלוי בגודל המערכת). כמו כן, לא תמיד ישנה הפרדה ברורה בין שלב זה לבין שלב העיצוב. שלב העיצוב בהכללה כולל: עיצוב בסיס הנתונים (בבסיסי נתונים טבלאיים שלושה מודלים אפשריים: הראשון הוא מודל קוד - שלוש צורות נורמליות. השני הוא מודל BCNF - שיפור של מודל שלוש הצורות הנורמליות. השלישי הוא מודל ERD). עיצוב מימשק תפעולי - תפריטים (השיטה הטובה ביותר לדעתי היא שיטת Addisa של פרץ שובל). תיקי תכנות הכוללים אלגוריתמים בשיטות שונות כמו - תרשימי זרימה, עברית מובנית, טבלאות החלטה ועצי החלטה. עיצוב הקלט (הטפסים). עיצוב הפלט (השאילתות והדוחות).
בעיקרון ישנם מספר סוגים של "מחזור חיים" לשלב הניתוח. זה תלוי במתודולוגיה הנבחרת (ישנן מתודולוגיות רבות שעוסקות בתחום). יתר על כן, המושג מחזור חיים מתייחס למערכת כולה, לאו דווקא לשלב זה או אחר. בעיקרון, ניתן לאמר כי שלב הניתוח/עיצוב בהכללה מתחלק לשלבי המשנה הבאים:ייזום. חקר מצב/מערכת קיימים (כיום בשלב זה משקיעים הרבה פחות מאשר בעבר). מיפוי הבעיות והגדרת דרישות מהמערכת הנדרשת. בניית אב טיפוס (שלב אופציונאלי, תלוי בגודל המערכת). חקר ישימות ובחירת חלופה מועדפת. אפיון המערכת החדשה. אפיון המערכת יכול לכלול הרבה מאוד דברים וברמות פירוט שונות (תלוי בגודל המערכת). כמו כן, לא תמיד ישנה הפרדה ברורה בין שלב זה לבין שלב העיצוב. שלב העיצוב בהכללה כולל: עיצוב בסיס הנתונים (בבסיסי נתונים טבלאיים שלושה מודלים אפשריים: הראשון הוא מודל קוד - שלוש צורות נורמליות. השני הוא מודל BCNF - שיפור של מודל שלוש הצורות הנורמליות. השלישי הוא מודל ERD). עיצוב מימשק תפעולי - תפריטים (השיטה הטובה ביותר לדעתי היא שיטת Addisa של פרץ שובל). תיקי תכנות הכוללים אלגוריתמים בשיטות שונות כמו - תרשימי זרימה, עברית מובנית, טבלאות החלטה ועצי החלטה. עיצוב הקלט (הטפסים). עיצוב הפלט (השאילתות והדוחות).
שיטת Addisa
שיטה זו מוסברת בספרו של פרופ' פרץ שובל "תכנון ועיצוב מערכות מידע", כרך ב' בהוצאת האוניברסיטה הפתוחה. השיטה מתבססת על תרשימי DFD (תרשימי בועות). הגדרות: פונקציה יסודית (המקביל לפעילות בז'רגון הישן) מסומנת בעיגול יחיד היא פונקציה שמנתח המערכות החליט לא לפרקה. (לא אפרט כעת מתי כן מפרקים ומתי לא). פונקציה כללית (גם פעילות בז'רגון הישן) מסומנת בעיגול כפול, היא פונקציה שמנתח המערכות החליט לפרקה בהמשך. טרנזקציה היא אוסף פונקציות יסודיות שמחוברות ביניהן באמצעות אפיקי מידע (חיצים) יסודיים עם לפחות ישות אחת המהווה טריגר להפעלת הטרנזקציה. גבולות הטרנזקציה הם מאגרי המידע שבתרשימים. אלגוריתם ליצירת עץ תפריטי המערכת: בהתאם לתרשימי ה- DFD צור עץ תפריטים ראשוני, כאשר פונקציה כללית הופכת להיות שורת בחירה (תתפרק לתת ענף) ואילו פונקציה יסודית הופכת להיות שורת הפעלה. בעץ התפריטים שיצרת בדוק את כל שורות ההפעלה השייכות לאותה טרנזקציה. כל שורות ההפעלה השייכות לאותה טרנזקציה בטל את כולן מלבד אחת. בצע זאת לכל הטרנזקציות שמצאת בעץ התפריטים. התוצאה היא עץ תפריטים סופי ומצומצם להפעלת המערכת.
שיטה זו מוסברת בספרו של פרופ' פרץ שובל "תכנון ועיצוב מערכות מידע", כרך ב' בהוצאת האוניברסיטה הפתוחה. השיטה מתבססת על תרשימי DFD (תרשימי בועות). הגדרות: פונקציה יסודית (המקביל לפעילות בז'רגון הישן) מסומנת בעיגול יחיד היא פונקציה שמנתח המערכות החליט לא לפרקה. (לא אפרט כעת מתי כן מפרקים ומתי לא). פונקציה כללית (גם פעילות בז'רגון הישן) מסומנת בעיגול כפול, היא פונקציה שמנתח המערכות החליט לפרקה בהמשך. טרנזקציה היא אוסף פונקציות יסודיות שמחוברות ביניהן באמצעות אפיקי מידע (חיצים) יסודיים עם לפחות ישות אחת המהווה טריגר להפעלת הטרנזקציה. גבולות הטרנזקציה הם מאגרי המידע שבתרשימים. אלגוריתם ליצירת עץ תפריטי המערכת: בהתאם לתרשימי ה- DFD צור עץ תפריטים ראשוני, כאשר פונקציה כללית הופכת להיות שורת בחירה (תתפרק לתת ענף) ואילו פונקציה יסודית הופכת להיות שורת הפעלה. בעץ התפריטים שיצרת בדוק את כל שורות ההפעלה השייכות לאותה טרנזקציה. כל שורות ההפעלה השייכות לאותה טרנזקציה בטל את כולן מלבד אחת. בצע זאת לכל הטרנזקציות שמצאת בעץ התפריטים. התוצאה היא עץ תפריטים סופי ומצומצם להפעלת המערכת.
דוגמא
מקווה להכין דוגמא מוחשית בשבוע שבועיים הקרובים הכוללת את כל השלבים שציינת. אודה לכם אם "תלחצו" עלי ותזכירו לי בדוא"ל: [email protected].
מקווה להכין דוגמא מוחשית בשבוע שבועיים הקרובים הכוללת את כל השלבים שציינת. אודה לכם אם "תלחצו" עלי ותזכירו לי בדוא"ל: [email protected].
כמה שאלות ל ERD שלך
אני לא מצליחה לראות את התרשים אבל לפי התוצרים של הטבלאות יש לי כמה הערות : 1. לא מקובל ששמות הם מפתחות מאחר וכל אחד יכול לכתוב אותם בצורה שונה, במיוחד אם יש שם פרטי ושם משפחה שאז צריך לחלק את זה לשני שדות (חוק הנרמול הראשון - אטומיות) או אם יש שני שחקנים שיש להם אותו שם, ולכן יש לעשות טבלת במאים וטבלת שחקנים שהמפתח שלהם הוא קוד. 2. בטבלת סרט למנוי יש לך ימי השאלה. אם אלו ימי השאלה לסרט זה צריך להיות בטבלת סרטים (חוק נרמול שלישי - מאפיין שאינו חלק מהמפתח אינו תלוי במאפיין אחר שאינו חלק מהמפתח) ואם חישוב מספר ימים אז אין צורך כי יש לך תאריך. אלא אם כל מנוי מודיע לכמה זמן הוא לוקח סרט מראש? 3. לנרמול מלא (החוק הרביעי של בדיקה אם יש יותר מקשר יחיד-לרבים אחד בין השדות בטבלה) שמעטים מבצעים אבל הוא יותר אסתטי, יש ליצור טבלת סרטים לבמאי ולהוציא את הבמאי מטבלת סרטים וכן טבלת סרטים לספק ולהוציא את הספק מטבלת סרטים - תאר לך שמחר אומרים לך שמותר שיהיו שני במאים לסרט או שמותר ליותר מספק אחד לספק את אותו סרט ? בשיטה הזו אין לך בכלל שינויים.
אני לא מצליחה לראות את התרשים אבל לפי התוצרים של הטבלאות יש לי כמה הערות : 1. לא מקובל ששמות הם מפתחות מאחר וכל אחד יכול לכתוב אותם בצורה שונה, במיוחד אם יש שם פרטי ושם משפחה שאז צריך לחלק את זה לשני שדות (חוק הנרמול הראשון - אטומיות) או אם יש שני שחקנים שיש להם אותו שם, ולכן יש לעשות טבלת במאים וטבלת שחקנים שהמפתח שלהם הוא קוד. 2. בטבלת סרט למנוי יש לך ימי השאלה. אם אלו ימי השאלה לסרט זה צריך להיות בטבלת סרטים (חוק נרמול שלישי - מאפיין שאינו חלק מהמפתח אינו תלוי במאפיין אחר שאינו חלק מהמפתח) ואם חישוב מספר ימים אז אין צורך כי יש לך תאריך. אלא אם כל מנוי מודיע לכמה זמן הוא לוקח סרט מראש? 3. לנרמול מלא (החוק הרביעי של בדיקה אם יש יותר מקשר יחיד-לרבים אחד בין השדות בטבלה) שמעטים מבצעים אבל הוא יותר אסתטי, יש ליצור טבלת סרטים לבמאי ולהוציא את הבמאי מטבלת סרטים וכן טבלת סרטים לספק ולהוציא את הספק מטבלת סרטים - תאר לך שמחר אומרים לך שמותר שיהיו שני במאים לסרט או שמותר ליותר מספק אחד לספק את אותו סרט ? בשיטה הזו אין לך בכלל שינויים.
תשובות למיכל?
ראשית תודה על ההתייחסויות. הערות כלליות 1 . זהו תרגיל וכך צריך להתייחס אליו. כלומר, רק לפי נתוני התרגיל מבלי להוסיף או לגרוע. 2 . טענת כי לא הצלחת לראות את תרשים ה- ER. האם ניסית להדפיס אותו או לפחות להציגו לפני הדפסה. זהו אובייקט שנוצר בתוכנה אחרת (VISIO), שאינו אמור להיראות במצב רגיל ב- Word. 3 . על תרשימי ER לא מפעילים את חוקי הנרמול שציינת. אלא, טכניקה אחרת שנקראת מיפוי תרשים ER לרלציות מנורמלות. כעת להערותיך הספציפיות. 1 . שם שחקן כמפתח ראשי. בתרגיל כתוב מפורשות ששם שחקן מזהה שחקן, לכן בהגדרה הוא Super Key או Candidate Key. במיפוי התרשים, שם השחקן הפך להיות המפתח הראשי של הטבלה המתאימה. 2 . חלוקת שם שחקן לשם פרטי ולשם משפחה (ערכים אטומיים). שוב זהו תרגיל ובתרגיל אין חלוקה כזאת. מעבר לכך הקביעה אם "מידע" מסויים הוא אטומי (שדה אחד) או ניתן להפרדה למשפר שדות, אינה קביעה טכנית. אלא, היא נובעת מההקשר של אותו מידע במערכת המידע הרלוונטית. דוגמא: נניח שיש לנו במערכת המידע טבלת לקוח ושאנו משתמשים בשם הלקוח רק לצורכי הדפסת שמו ומשלוח דואר אליו. במקרה כזה אין צורך להפריד בין שני חלקי השם. שם המשפחה של הלקוח בצירוף השם הפרטי שלו מהווים ביחד ערך אטומי. 3 . טבלת סרט למנוי: ציטוט מתגובתך, "מספר ימי השאלה צריך להיות בטבלת סרט". זו טעות משתי סיבות. סיבה ראשונה היא שהמשמעות היא שלכל סרט יש מספר קבוע של ימי השאלה,לכל המנויים בכל בפעמים שהסרט מושאל - לא הגיוני לחלוטין, גם לא עם נתוני התרגיל. סיבה שניה (טכנית) היא שאין הפעלה של חוקי הנרמול על תרשים ER. אלא, כפי שצויין לעיל טכניקה אחרת שנקראת מיפוי. בתרשים ה- ER מספר ימי השאלה הוא תכונה של הקשר בין סרט לבין מנוי. לכן, תכונה זו אוטומטית הופכת להיות שדה בטבלת הקשר (סרט-מנוי). 4 . לגבי ההערה האחרונה שלך. כפי שציינתי זהו תרגיל.
ראשית תודה על ההתייחסויות. הערות כלליות 1 . זהו תרגיל וכך צריך להתייחס אליו. כלומר, רק לפי נתוני התרגיל מבלי להוסיף או לגרוע. 2 . טענת כי לא הצלחת לראות את תרשים ה- ER. האם ניסית להדפיס אותו או לפחות להציגו לפני הדפסה. זהו אובייקט שנוצר בתוכנה אחרת (VISIO), שאינו אמור להיראות במצב רגיל ב- Word. 3 . על תרשימי ER לא מפעילים את חוקי הנרמול שציינת. אלא, טכניקה אחרת שנקראת מיפוי תרשים ER לרלציות מנורמלות. כעת להערותיך הספציפיות. 1 . שם שחקן כמפתח ראשי. בתרגיל כתוב מפורשות ששם שחקן מזהה שחקן, לכן בהגדרה הוא Super Key או Candidate Key. במיפוי התרשים, שם השחקן הפך להיות המפתח הראשי של הטבלה המתאימה. 2 . חלוקת שם שחקן לשם פרטי ולשם משפחה (ערכים אטומיים). שוב זהו תרגיל ובתרגיל אין חלוקה כזאת. מעבר לכך הקביעה אם "מידע" מסויים הוא אטומי (שדה אחד) או ניתן להפרדה למשפר שדות, אינה קביעה טכנית. אלא, היא נובעת מההקשר של אותו מידע במערכת המידע הרלוונטית. דוגמא: נניח שיש לנו במערכת המידע טבלת לקוח ושאנו משתמשים בשם הלקוח רק לצורכי הדפסת שמו ומשלוח דואר אליו. במקרה כזה אין צורך להפריד בין שני חלקי השם. שם המשפחה של הלקוח בצירוף השם הפרטי שלו מהווים ביחד ערך אטומי. 3 . טבלת סרט למנוי: ציטוט מתגובתך, "מספר ימי השאלה צריך להיות בטבלת סרט". זו טעות משתי סיבות. סיבה ראשונה היא שהמשמעות היא שלכל סרט יש מספר קבוע של ימי השאלה,לכל המנויים בכל בפעמים שהסרט מושאל - לא הגיוני לחלוטין, גם לא עם נתוני התרגיל. סיבה שניה (טכנית) היא שאין הפעלה של חוקי הנרמול על תרשים ER. אלא, כפי שצויין לעיל טכניקה אחרת שנקראת מיפוי. בתרשים ה- ER מספר ימי השאלה הוא תכונה של הקשר בין סרט לבין מנוי. לכן, תכונה זו אוטומטית הופכת להיות שדה בטבלת הקשר (סרט-מנוי). 4 . לגבי ההערה האחרונה שלך. כפי שציינתי זהו תרגיל.
אני כל כך לא מסכים
אני באתי דווקא מתחום התכנות , עברתי קורס ניתוח מערכות מידע ( לפני כמה שנים טובות ) והספקתי לקחת חלק במגוון פרויקטים במערכות מידע אם זה מערכות לשימוש פנימי ואם זה מערכות שהחברה מייצרת מוכרת ( אמדוקס אלא מה ) . לי כמתחנת היה הרבה יותר קל להבין את נושא הניתוח מאשר מישהו שהגיע מעולם הניהול . כשאתה מכיר את הכלים ואת המושג תכנות וכיצד עושים זאת , קל לך לבצע גם ניתוח. אז נכון שהמנתח אמור לחשוב אחרת אבל מניסיון בפועל תמיד טוב שהמנתח מבין גם כיצד מישמים את הניתוח . אם זה ברמת בסיסי נתונים ואם זה ברמת כתיבת קוד בשכבות הביניים וכמובן ב GUI .
אני באתי דווקא מתחום התכנות , עברתי קורס ניתוח מערכות מידע ( לפני כמה שנים טובות ) והספקתי לקחת חלק במגוון פרויקטים במערכות מידע אם זה מערכות לשימוש פנימי ואם זה מערכות שהחברה מייצרת מוכרת ( אמדוקס אלא מה ) . לי כמתחנת היה הרבה יותר קל להבין את נושא הניתוח מאשר מישהו שהגיע מעולם הניהול . כשאתה מכיר את הכלים ואת המושג תכנות וכיצד עושים זאת , קל לך לבצע גם ניתוח. אז נכון שהמנתח אמור לחשוב אחרת אבל מניסיון בפועל תמיד טוב שהמנתח מבין גם כיצד מישמים את הניתוח . אם זה ברמת בסיסי נתונים ואם זה ברמת כתיבת קוד בשכבות הביניים וכמובן ב GUI .
הייתי מסכים אתך לחלוטין
אלמלא העבר הקשה שלי עם מנתחי מערכות שהיו תוכניתנים לשעבר והעבר שלהם לא הרפה מהם גם כשהיו מנתחים. ואני אסביר - אפיון מערכת לכשעצמו אמור להיות כמה שיותר נטול שיקולי טכנולוגיה (אני אומר כמה שיותר כי ברור שבסופו של דבר המערכת רצה על מחשב ויש לכך השלכות) או מה שמכונה בעגה ה-RUP-ית Platform Independant. הבעיה עם מנתחים אשר לא מצליחים להפריד בין היותם תוכניתנים לבין היותם מנתחים היא שהאפיון שהם נותנים משלב לרוב השלכות טכנולוגיות (בין אם סביבת מחשוב, סביבת פיתוח או אספקטים טכניים אחרים) אשר גורמות לאפיון להיות מקובע לסביבה מסוימת ופחות גמיש לשינויים בעקבות שינויים בסביבת הפיתוח (שינוי שאמור להיות שקוף לאפיון). אני אישית תמיד אעדיף לעבוד עם מנתח שיש לו נסיון בפיתוח - אבל לא ארצה לעבוד עם מנתח שעדין חושב כמו מתכנת !!
אלמלא העבר הקשה שלי עם מנתחי מערכות שהיו תוכניתנים לשעבר והעבר שלהם לא הרפה מהם גם כשהיו מנתחים. ואני אסביר - אפיון מערכת לכשעצמו אמור להיות כמה שיותר נטול שיקולי טכנולוגיה (אני אומר כמה שיותר כי ברור שבסופו של דבר המערכת רצה על מחשב ויש לכך השלכות) או מה שמכונה בעגה ה-RUP-ית Platform Independant. הבעיה עם מנתחים אשר לא מצליחים להפריד בין היותם תוכניתנים לבין היותם מנתחים היא שהאפיון שהם נותנים משלב לרוב השלכות טכנולוגיות (בין אם סביבת מחשוב, סביבת פיתוח או אספקטים טכניים אחרים) אשר גורמות לאפיון להיות מקובע לסביבה מסוימת ופחות גמיש לשינויים בעקבות שינויים בסביבת הפיתוח (שינוי שאמור להיות שקוף לאפיון). אני אישית תמיד אעדיף לעבוד עם מנתח שיש לו נסיון בפיתוח - אבל לא ארצה לעבוד עם מנתח שעדין חושב כמו מתכנת !!
אין 100 אחוז נכונות בשום דבר
ותמיד יש כאלו שהם חריגים . מנתח מערכות לא אמור לחשוב כמו מתכנת אבל הו אמור להבין איך מתכנת חושב כי בסופו של דבר מישהו יצטרך לממש את הניתוח . עבדתי עם מספיק מנתחים שכל קשר בין הניתוח שלהם והמציאות מקרי בהחלט והביע היא עם העקשנים , אלו שלא מסוגלים לקבל ביקורת בונה . המשפט האחרון שלך מסכם הכל לדעתי ואני מסכים איתו ב 100 אחוז .
ותמיד יש כאלו שהם חריגים . מנתח מערכות לא אמור לחשוב כמו מתכנת אבל הו אמור להבין איך מתכנת חושב כי בסופו של דבר מישהו יצטרך לממש את הניתוח . עבדתי עם מספיק מנתחים שכל קשר בין הניתוח שלהם והמציאות מקרי בהחלט והביע היא עם העקשנים , אלו שלא מסוגלים לקבל ביקורת בונה . המשפט האחרון שלך מסכם הכל לדעתי ואני מסכים איתו ב 100 אחוז .
Copyright©1996-2021,Tapuz Media Ltd. Forum software by XenForo® © 2010-2020 XenForo Ltd.