Transcript תרשימי זרימה (Flow Charts) ותרשימי DFD

‫ניתוח מערכות מידע א'‬
‫הרצאה ‪2‬‬
‫שלבי תהליך הפיתוח‬
‫מידול תהליך הפיתוח‬
‫ניתוח דרישות (אם נספיק)‬
‫‪1‬‬
‫שלבי תהליך הפיתוח‬
‫מדרישת הלקוח ועד שאין יותר שימוש בתוכנה‬
‫‪2‬‬
‫שלבי הפיתוח‬
‫‪ ‬התחלה‪ :‬דרישת לקוח‬
‫‪ ‬סיום‪ :‬אין יותר שימוש בתוכנה‬
‫‪ ‬שלבים בחייה של תוכנה‬
‫‪‬‬
‫‪‬‬
‫‪‬‬
‫‪‬‬
‫‪‬‬
‫‪‬‬
‫‪‬‬
‫‪3‬‬
‫שלב הדרישות ‪Requirement phase -‬‬
‫שלב הניתוח ‪Analysis phase -‬‬
‫שלב התכן ‪Design phase -‬‬
‫שלב המימוש ‪Implementation phase -‬‬
‫שלב השילוב ‪Integration phase -‬‬
‫שלב האחזקה ‪Maintenance phase -‬‬
‫פרישה ‪Retirement -‬‬
‫שלב הדרישות ‪Requirement phase -‬‬
‫‪ ‬הבנה והגדרה של דרישות הלקוח‬
‫‪‬‬
‫כולל ניתוח בעיות‪ ,‬ניתוח הזדמנויות שיווקיות וכדו'‬
‫‪ ‬מורכב משני היבטים‪:‬‬
‫‪‬‬
‫‪‬‬
‫‪Business modeling‬‬
‫‪ ‬הכרת הסביבה העיסקית שבה תפעל התוכנה‬
‫‪System modeling‬‬
‫‪ ‬הגדרה של מה התוכנה תעשה\לא תעשה‬
‫‪ ‬נגדיר שני סוגי דרישות‬
‫‪‬‬
‫‪‬‬
‫שירות (‪ – )service‬פעולות שהמערכת צריכה לבצע‬
‫אילוץ (‪ – )constraint‬הגבלות על פעילות המערכת‬
‫‪ ‬התוצר – מסמך מילולי (בלתי פורמלי) המתאר את הדרישות‬
‫‪4‬‬
‫שלב הניתוח ‪Analysis phase -‬‬
‫‪ ‬זיהוי הישויות הפועלות במערכת‬
‫‪ ‬הכרת התכונות של הישויות הנ"ל‬
‫‪ ‬הכרת הקשרים בין הישויות‬
‫‪ ‬שלב זה נקרא לפעמים‪requirements specification :‬‬
‫‪ ‬התוצר משלב זה (נלמד בהמשך)‬
‫‪‬‬
‫‪‬‬
‫‪5‬‬
‫בשלב זה מתחילים להשתמש בכלי מידול (‪)CASE‬‬
‫ובוחרים שפת מידול (‪)UML‬‬
‫בסוף הניתוח יתקבלו התרשימים הבאים‪:‬‬
‫‪‬‬
‫‪class diagrams, use case diagrams‬‬
‫שלב התכן ‪Design phase -‬‬
‫‪ ‬תכנון פתרון הבעיה‬
‫‪‬‬
‫כולל גם תכנון התוכנה וגם תכנון מרכיבים נוספים במערכת‬
‫‪ ‬מבוסס על הגדרות שלב הניתוח‪.‬‬
‫‪ ‬תכנון ארכיטקטוני (חומרה)‬
‫‪‬‬
‫מחשבים‪ ,‬שרת‪/‬לקוח‪ ,‬מסד נתונים‪ ,‬תקשורת‪ ,‬וכו'‬
‫‪ ‬תכנון מפורט (תוכנה)‬
‫‪‬‬
‫‪‬‬
‫‪6‬‬
‫אלגוריתמים‪ ,‬מבני נתונים‪ ,‬ממשק למשתמש‪ ,‬וכו'‬
‫תיאור ההתנהגות הצפויה מרכיבי התוכנה‬
‫שלב המימוש ‪Implementation phase -‬‬
‫‪ ‬פיתוח התוכנה‬
‫‪‬‬
‫‪‬‬
‫‪‬‬
‫‪‬‬
‫התקנה של סביבת פיתוח התוכנה‬
‫תיכנון התוכנה על סמך השלבים הקודמים‬
‫קידוד התוכנה‬
‫תיעוד התוכנה (‪)help, web sites with FAQ‬‬
‫‪ ‬בדיקות תוכנה‬
‫‪‬‬
‫‪‬‬
‫‪‬‬
‫‪7‬‬
‫בדיקה של יחידות התוכנה השונות‬
‫בדיקת התוכנה של המערכת כולה‬
‫תיקונים והרחבות‬
‫שלב השילוב (הטמעה)‪Integration phase -‬‬
‫‪ ‬יש לתכנן את השילוב בתחלית מחזור החיים‬
‫‪ ‬הרכבת חלקי המערכת (‪)integration‬‬
‫‪‬‬
‫יש לבצע באופן הדרגתי‬
‫‪ ‬פריסה (‪)deployment‬התקנת המערכת כולה‬
‫‪ ‬הדרכת משתמשים‪ ,‬הסבת נתונים ושיטות עבודה‪.‬‬
‫‪ ‬בעיות נפוצות‬
‫‪‬‬
‫‪‬‬
‫קשיים בשילוב בין הרכבים עקב תלות מעגלית‬
‫רכיב אחד מוכן לפני‪/‬אחרי האחרים‬
‫‪‬‬
‫‪8‬‬
‫טוב שתהיה מערכת גיבוי לעבודה לתקופת השילוב‬
‫שלב האחזקה ‪Maintenance phase -‬‬
‫‪ ‬לאחר המסירה ללקוח יש להמשיך לתחזק את המערכת‬
‫‪ ‬האחזקה היא חלק חשוב של הפרויקט ומהווה אחוז ניכר‬
‫של פעילות אנשי מערכות המידע‬
‫‪ ‬אחזקה מורכבת מ‪:‬‬
‫‪‬‬
‫‪Housekeeping‬‬
‫‪‬‬
‫‪‬‬
‫‪Adaptive maintenance‬‬
‫‪‬‬
‫‪‬‬
‫ניתור‪ ,‬כיול‪ ,‬הוספת משתמשים וכדו'‬
‫‪Perfective maintenence‬‬
‫‪‬‬
‫‪9‬‬
‫ביצוע פעולות אחזקה סדירות לאפשור נגישות למערכת‬
‫תכנון מחודש של תתי מערכות‬
‫פרישה ‪Retirement -‬‬
‫‪ ‬בסוף המערכת יוצאת משימוש‬
‫‪ ‬סיבות אפשריות‬
‫‪‬‬
‫‪‬‬
‫‪‬‬
‫‪‬‬
‫‪10‬‬
‫שינויים מעבר למסגרת אחזקה‬
‫המערכת יוצאת משליטה ואין אשפרות לנבא כיצד תפעל‬
‫מחסור בתיעוד המאפשר שינויים‬
‫שינויים בחומרה או תוכנה שאינה מאפשרת את העברת‬
‫המערכת‬
‫המתודה ותהליך הפיתוח‬
‫‪ ‬תכנון (‪)planning‬‬
‫‪‬‬
‫‪‬‬
‫‪‬‬
‫‪‬‬
‫הגדרת תוצרים‬
‫לוחות זמנים‬
‫משאבים דרושים (כוח אדם‪ ,‬תקציבים‪ ,‬ציוד‪ ,‬כלי פיתוח וכו')‬
‫הערכת סיכונים‬
‫‪ ‬בדיקות (‪)testing‬‬
‫‪‬‬
‫‪‬‬
‫‪‬‬
‫תיכנון הבדיקות החל מתחילת התהליך‬
‫בדיקת הקוד (‪)walkthrough‬‬
‫בדיקות של כל יחידה‪ ,‬בדיקות של המערכת‬
‫‪ ‬לפעמים מוגדרים כשלבים נפרדים‪ ,‬אבל בעצם מדובר בפעילויות‬
‫המבוצעות לאורך כל זמן החיים‬
‫‪11‬‬
‫מידול תהליך הפיתוח‬
‫(מודלים של זמן החיים)‬
‫מפל המים‪ ,‬מודל ספירלי‪ ,‬מונחה עצמים וכו'‬
‫‪12‬‬
)build & fix( ‫בנה ותקן‬
‫בנה גרסה‬
‫ראשונה‬
,‫ערוך שינויים‬
‫עד שהלקוח‬
‫מרוצה‬
If you don't
have time
to do it right,
Where would you take
the time to do it
again???
‫הפעלה‬
‫מבצעית‬
‫פרישה‬
‫פיתוח‬
‫אחזקה‬
13
‫בנה ותקן ‪ -‬תכונות‬
‫‪ ‬רק חסרונות‬
‫‪‬‬
‫‪‬‬
‫‪‬‬
‫אין מפרט‬
‫אין תכן‬
‫מתאים לתוכנה קטנה מאד (‪ 200-300‬שורות?)‬
‫‪ ‬לכל תוכנה בגודל סביר נדרשים‪ ,‬לפחות‪:‬‬
‫‪‬‬
‫‪‬‬
‫‪‬‬
‫‪14‬‬
‫תכנית פעולה ("‪)"game plan‬‬
‫שלבים בפיתוח‬
‫אבני‪-‬דרך (‪)milestones‬‬
‫מודל מפל המים (‪)waterfall‬‬
‫‪Royce, 1970‬‬
‫דרישות‬
‫אימות‬
‫שינוי בדרישות‬
‫אימות‬
‫ניתוח‬
‫אימות‬
‫תכן‬
‫אימות‬
‫מימוש‬
‫אימות‬
‫שילוב‬
‫אימות‬
‫הפעלה מבצעית‬
‫‪15‬‬
‫פרישה‬
‫פיתוח‬
‫אחזקה‬
‫מודל מפל המים ‪ -‬תכונות‬
‫‪ "feedback" ‬בין שלבים עוקבים‬
‫‪ ‬תהליך מונחה‪-‬תיעוד‪:‬‬
‫‪‬‬
‫המעבר לשלב הבא מותנה (ותלוי!) בתיעוד השלב הקודם‬
‫‪ ‬יתרונות‬
‫‪‬‬
‫‪‬‬
‫תהליך מתועד‬
‫אחזקה קלה יותר‬
‫‪ ‬חסרונות‬
‫‪‬‬
‫‪‬‬
‫‪‬‬
‫‪16‬‬
‫פורמאליות‪-‬יתר (המוצר מאופיין אך ורק באמצעות התיעוד)‬
‫מציאות רחוקה מהמודל‪ ---‬אין פיתוח כזה !!‬
‫בפועל מתעלמים מחזרה לשלב קודם ורצים קדימה‪...‬‬
‫אב‪-‬טיפוס מהיר‬
‫‪ ‬דגם עובד‬
‫‪ ‬מכיל תת‪-‬קבוצה של הפונקציונליות של המוצר‬
‫‪ ‬דוגמה‪:‬‬
‫‪‬‬
‫המוצר‪ :‬תוכנה לניהול תקבולים‪ ,‬תשלומים ואחסנה‬
‫‪‬‬
‫אב‪-‬טיפוס מהיר יכיל‪:‬‬
‫‪ ‬מסכים להכנסת נתונים‬
‫‪ ‬הדפסת דו"חות‬
‫‪‬‬
‫אב‪-‬טיפוס מהיר לא יכיל‪:‬‬
‫‪ ‬עדכון קבצים‬
‫‪ ‬הודעות שגיאה‬
‫‪ ‬נועד לסייע בגיבוש הדרישות לצורך מפרט‬
‫‪17‬‬
‫מודל אב‪-‬טיפוס מהיר (‪)rapid prototype‬‬
‫אב‪-‬טיפוס‬
‫אימות‬
‫שינוי בדרישות‬
‫אימות‬
‫ניתוח‬
‫אימות‬
‫תכן‬
‫אימות‬
‫מימוש‬
‫אימות‬
‫שילוב‬
‫אימות‬
‫הפעלה מבצעית‬
‫‪18‬‬
‫פרישה‬
‫פיתוח‬
‫אחזקה‬
‫אב‪-‬טיפוס מהיר ‪ -‬תכונות‬
‫‪ ‬אב‪-‬טיפוס הוא אב‪-‬טיפוס הוא אב‪-‬טיפוס!‬
‫‪ ‬אב‪-‬טיפוס נועד להדגים את המוצר הסופי ולא‬
‫לממש אותו‪:‬‬
‫‪ ‬אין להפוך אב‪-‬טיפוס למוצר!‬
‫‪‬‬
‫‪‬‬
‫‪19‬‬
‫אב‪-‬טיפוס יכול לשמש כמפרט ‪ ,‬אבל לא כתכן!‬
‫עדכן‪ ,‬שנה‪ ,‬בדוק ‪ -‬אבל בסוף השלך לפח!‬
‫מודל אינקרמנטלי‬
‫מבנה ‪1‬‬
‫ניתוח‬
‫מבנה ‪2‬‬
‫ניתוח‬
‫מבנה ‪n‬‬
‫תכן‬
‫ניתוח‬
‫תכן‬
‫מימוש‬
‫ושילוב‬
‫מסירה‬
‫תכן‬
‫מימוש‬
‫ושילוב‬
‫מימוש‬
‫ושילוב‬
‫מסירה‬
‫מסירה‬
‫קבוצת ניתוח‬
‫קבוצת תכן‬
‫‪20‬‬
‫קבוצת מימוש‬
‫מודל אינקרמנטלי ‪ -‬תכונות‬
‫‪ ‬יתרונות‬
‫‪‬‬
‫‪‬‬
‫ניתן להתחיל בעבודת הפיתוח מבלי להמתין להשלמת הנדסת‬
‫המערכת‬
‫עבודה במקביל ע”י קבוצות מקצועיות‬
‫‪ ‬חסרונות‬
‫‪‬‬
‫‪‬‬
‫סיכון גבוה‬
‫‪ ‬החלטות תכן ומימוש מתבססות על ניתוח חלקי בלבד‬
‫‪ ‬עלול לגרום סבבי שינויים ארוכים ויקרים‬
‫זהירות ממהירות מופרזת‬
‫‪CABTAB = Code A Bit Test A Bit ‬‬
‫‪ ‬המלצה‪ :‬שחרור גירסא ללקוח רק אחרי מספר סבבים‬
‫‪21‬‬
‫המודל הלוליני (‪)spiral‬‬
‫‪22‬‬
‫המודל הלולייני ‪ -‬תכונות‬
‫‪ ‬יתרונות‬
‫‪‬‬
‫ניתן להתאים את ההיקף של כל איטרציה לפי‪:‬‬
‫‪‬‬
‫‪‬‬
‫‪‬‬
‫‪‬‬
‫כושר הפיתוח‬
‫היקפי הבדיקות‬
‫אילוצי זמנים‬
‫הסתכלות אחידה על פיתוח ‪ /‬מימוש ‪ /‬אחזקה‬
‫‪ ‬חסרונות‬
‫‪‬‬
‫‪‬‬
‫‪23‬‬
‫מתאים לתוכנה בהיקף גדול (‪)large-scale‬‬
‫מתאים לפיתוח פנימי (‪)in-house‬‬
‫תכנות קיצוני‬
‫)‪(Extreme Programming‬‬
‫‪ ‬ריבויי בניה (מספר פעמים ביום!!)‬
‫‪ ‬עבודת צוות עם נהלים מיוחדים‬
‫‪ ‬תכנות בזוגות מתחלפים‬
‫‪ ‬בדיקות רצופות בעזרת כלים ליצירה וניהול‬
‫‪ ‬מערכת "עובדת" עם יכולות מוגבלות‬
‫‪ ‬תכנון ומימוש מינימליים –לדרישות עד כה‬
‫‪ ‬תכנון מחדש )‪(refactorization‬‬
‫‪24‬‬
‫פיתוח מונחה‪-‬עצמים‬
‫(‪)Object-Oriented Development‬‬
‫‪ ‬מאפייני פיתוח מונחה‪-‬עצמים‬
‫‪‬‬
‫‪‬‬
‫‪‬‬
‫‪‬‬
‫מידה גבוהה של מודולריות‬
‫פיתוח במקביל‬
‫אינקרמטלי ואיטרטיבי מטבעו‬
‫שימוש חוזר (‪)reuse‬‬
‫‪ ‬מודלים מונחי‪-‬עצמים‬
‫‪‬‬
‫‪‬‬
‫‪25‬‬
‫תומכים באיטרטיביות בתוך כל שלב ובין השלבים‬
‫משלבים מקביליות ופיתוח אינקרמנטלי‬
‫מידול תהליך הפיתוח ‪ -‬סיכום‬
‫‪ ‬קיים מגוון גדול של מודלים‬
‫‪ ‬בפועל על כל חברה לייצר את המודל שמתאים לצרכיה‬
‫‪ ‬יש להתחשב בגורמים הבאים‪:‬‬
‫‪‬‬
‫‪‬‬
‫‪‬‬
‫‪‬‬
‫הארגון (מטרות‪ ,‬אילוצים‪ ,‬תשתיות‪)... ,‬‬
‫ההנהלה (פתיחות‪ ,‬הבנה מקצועית‪ ,‬גיבוי‪)... ,‬‬
‫העובדים (הכשרה מקצועית‪ ,‬יחסי‪-‬אנוש‪)... ,‬‬
‫המוצר (מורכבות‪ ,‬ייחודיות‪ ,‬מספר וסוג המשתמשים)‬
‫‪“ ‬שלב והתאם” (‪)mix & match‬‬
‫‪‬‬
‫‪‬‬
‫‪26‬‬
‫מודלים שונים לרמות פיתוח שונות (מקרו‪ ,‬מיקרו)‬
‫מודלים שונים למרכיבים שונים‬
‫ניתוח והגדרת דרישות‬
‫‪27‬‬
‫שלב הדרישות ‪Requirement phase -‬‬
‫‪ ‬הבנה והגדרה של דרישות הלקוח‬
‫‪‬‬
‫כולל ניתוח בעיות‪ ,‬ניתוח הזדמנויות שיווקיות וכדו'‬
‫‪ ‬מורכב משני היבטים‪:‬‬
‫‪‬‬
‫‪‬‬
‫‪Business modeling‬‬
‫‪ ‬הכרת הסביבה העיסקית שבה תפעל התוכנה‬
‫‪System modeling‬‬
‫‪ ‬הגדרה של מה התוכנה תעשה\לא תעשה‬
‫‪ ‬נגדיר שני סוגי דרישות‬
‫‪‬‬
‫‪‬‬
‫שירות (‪ – )service‬פעולות שהמערכת צריכה לבצע‬
‫אילוץ (‪ – )constraint‬הגבלות על פעילות המערכת‬
‫‪ ‬התוצר – מסמך מילולי המתאר את הדרישות‬
‫‪28‬‬
‫סוגי דרישות‬
‫‪ ‬דרישות שירות (‪)service‬‬
‫‪‬‬
‫‪‬‬
‫‪‬‬
‫‪‬‬
‫היקף המערכת‬
‫פונקציונליות ‪ -‬מה המערכת מבצעת‬
‫מבני נתונים‬
‫מימוש‬
‫‪ ‬אילוצים (‪)constraint‬‬
‫‪‬‬
‫‪‬‬
‫‪‬‬
‫‪‬‬
‫‪‬‬
‫‪29‬‬
‫‪‬‬
‫קלות השימוש‬
‫שימוש חוזר‬
‫אמינות‬
‫ביצועים‬
‫יעילות‬
‫גמישות (יכולת לתחזק ולעדכן את המערכת)‬
‫השגת המידע לתכנון הדרישות‬
‫‪ ‬שיטות מסורתיות‬
‫‪‬‬
‫‪‬‬
‫‪‬‬
‫‪‬‬
‫תשאול לקוחות ומומחים‬
‫שאלונים‬
‫צפיה‬
‫ניתוח מסמכים ומערכות קיימות‬
‫‪ ‬שיטות מודרניות‬
‫‪‬‬
‫‪‬‬
‫‪‬‬
‫‪30‬‬
‫‪‬‬
‫אב טיפוס (‪)prototype‬‬
‫סיעור מוחות‬
‫‪JAD – Joint Application Development‬‬
‫‪RAD – Rapid Application Development‬‬
‫דרישות – למה נשים לב?‬
‫‪ ‬סתירות‬
‫‪ ‬חפיפות‬
‫‪ ‬תלויות‬
‫‪ ‬סיכונים‬
‫‪ ‬סדרי עדיפות‬
‫‪ ‬מה שייך למערכת ומה לא‬
‫‪‬‬
‫‪31‬‬
‫לא בהכרח כל חלקי המערכת יפותחו במסגרת הפרויקט‬
‫יש להפריד בין חלקים פנימיים למערכת לבין חלקים‬
‫שהמערכת מתמשקת איתם‪ .‬נוח להשתמש ב ‪DFD‬‬
‫ניהול הדרישות‬
‫‪ ‬מציאת הדרישות ותיעוד שלהם‬
‫‪‬‬
‫‪‬‬
‫מתבצע בשפה חופשית‬
‫יש לבצע מספור (או סימון אחר)של כל דרישה‬
‫‪‬‬
‫‪‬‬
‫‪‬‬
‫חד ערכית (‪ ID‬לכל דרישה)‬
‫היררכית (‪)2.6.1‬‬
‫מספור בתוספת סוג הדרישה (פונקציונלי‪ ,‬נתון‪ ,‬ביטחון‪)...‬‬
‫‪ ‬מעקב אחר עדכון‪ ,‬שינוי או ביטול דרישה‬
‫‪‬‬
‫‪‬‬
‫‪‬‬
‫יש לתעד את השינוי‬
‫לשער את השלכות השינוי‬
‫לעקוב אחר השינוי‬
‫‪ ‬מעקב אחר תלויות בין דרישות ובין חלקי המערכת‬
‫‪32‬‬
‫מידול עיסקי‬
‫‪Requirements business modeling‬‬
‫‪ ‬לאחר הגדרת הדרישות מקובל לתאר את המערכת‬
‫מנקודת מבט עיסקית‬
‫‪ ‬תרשימי ‪ UML‬שנראה בהמשך אינם מתאימים כ"כ‬
‫‪ ‬מתאים להשתמש בתרשים ‪DFD‬‬
‫‪‬‬
‫‪‬‬
‫התרשים המתאים נקרא ‪context diagram‬‬
‫נתאר את המערכת‪ ,‬ואת המידע הזורם אליה וממנה‬
‫זרימת מידע ‪2‬‬
‫ישות חיצונית ‪1‬‬
‫‪33‬‬
‫המערכת‬
‫זרימת מידע ‪3‬‬
‫זרימת מידע ‪1‬‬
‫ישות חיצונית ‪1‬‬