תרשימי זרימה (Flow Charts) ותרשימי DFD
Download
Report
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