מילון מונחים - להתחיל לשרשר
- פותח הנושא עידו פ
- פורסם בתאריך
UML
שפה גרפית המשתמשת לבניית מודל גרפי של תוכנה. השפה מאפשרת מידול בכל רמות ההפשטה של המערכת. 1.נקודת מבט של משתמש חיצוני. 2.התת-מערכות והקשרים(תקשורת) ביניהם. 3.אובייקטים והקשרים(תקשורת) ביניהם. 4.אלגוריתמים. UML מאפשרת לתאר את המערכת הן מבחינה סטטית והן מבחינה התנהגותית. צירפתי פעם בקומונה מצגת שהכנתי בנושא UML. הנה זה שוב למעוניינים. לינק תעשו שימוש חופשי - רק בקשה אחת אם אתם מוצאים טעויות נא לידע אותי
שפה גרפית המשתמשת לבניית מודל גרפי של תוכנה. השפה מאפשרת מידול בכל רמות ההפשטה של המערכת. 1.נקודת מבט של משתמש חיצוני. 2.התת-מערכות והקשרים(תקשורת) ביניהם. 3.אובייקטים והקשרים(תקשורת) ביניהם. 4.אלגוריתמים. UML מאפשרת לתאר את המערכת הן מבחינה סטטית והן מבחינה התנהגותית. צירפתי פעם בקומונה מצגת שהכנתי בנושא UML. הנה זה שוב למעוניינים. לינק תעשו שימוש חופשי - רק בקשה אחת אם אתם מוצאים טעויות נא לידע אותי
eXtreme Programming
מתודולגיית פיתוח שהמציא קנט בק אשר מעמידה במרכז תהליך הפיתוח את הדברים הבאים: - סיפוק צרכי הלקוח - עמידה בלוחות זמנים - עיצוב תוכנה נקי ופשוט - אמינות המוצר המתודולוגייה מתמודדת עם הנושאים הנ"ל על ידי התווית מסלול פיתוח בשלבים קטנים (הנקראים "איטרציות"). כל שלב כולל הכנה עיצובית והתאמה ל"סיפורי לקוח", כתיבה, בניה ובדיקות - ולבסוף שחרור מיני גרסה וקבלת היזון חוזר מהלקוח. ישנם תהליכים וסטנדרטים נוספים המוגדרים תחת eXtreme Programming ועוסקים בתהליך הפיתוח באופן יותר ספציפי - עבודת צוות, חתירה לתוצאות וזיהוי נקודות חולשה בעיצוב שדורשות התמודדות.
מתודולגיית פיתוח שהמציא קנט בק אשר מעמידה במרכז תהליך הפיתוח את הדברים הבאים: - סיפוק צרכי הלקוח - עמידה בלוחות זמנים - עיצוב תוכנה נקי ופשוט - אמינות המוצר המתודולוגייה מתמודדת עם הנושאים הנ"ל על ידי התווית מסלול פיתוח בשלבים קטנים (הנקראים "איטרציות"). כל שלב כולל הכנה עיצובית והתאמה ל"סיפורי לקוח", כתיבה, בניה ובדיקות - ולבסוף שחרור מיני גרסה וקבלת היזון חוזר מהלקוח. ישנם תהליכים וסטנדרטים נוספים המוגדרים תחת eXtreme Programming ועוסקים בתהליך הפיתוח באופן יותר ספציפי - עבודת צוות, חתירה לתוצאות וזיהוי נקודות חולשה בעיצוב שדורשות התמודדות.
תקרא שם באתר (משם לקוח האיור)
יש ב XP נטיה מסויימת לעבור מהר מאוד לפיתוח. בניגוד לתפיסות שטוענות שניתוח ועיצוב מוקדם של כל המערכת הכרחי לפני תחילת העבודה, XP מציג תפיסה ששוללת את נכונות הדבר. אנשי XP טוענים שלמעשה לא ניתן לצפות את היקפה הכולל של המערכת מבעוד מועד ולא ניתן למכור ללקוח מוצר מוגמר לפני שנכתבה שורת קוד אחת. הפיתוח הוא באיטרציות קצרות על מנת לתת ללקוח "להרגיש" את המערכת ולקבל היזון חוזר שעוזר לקבוע את המשך הדרך. אגב, זה לא נכון שאין ממש עיצוב. אם אינני טועה מדובר על שני שלבי עיצוב בכל איטרציה: עיצוב לפני האיטרציה ועיצוב "חוזר" אחריה (Refactoring). כאשר בשלב העיצוב השני משפרים את הקוד הקיים ומכינים אותו לאיטרציה הבאה.
יש ב XP נטיה מסויימת לעבור מהר מאוד לפיתוח. בניגוד לתפיסות שטוענות שניתוח ועיצוב מוקדם של כל המערכת הכרחי לפני תחילת העבודה, XP מציג תפיסה ששוללת את נכונות הדבר. אנשי XP טוענים שלמעשה לא ניתן לצפות את היקפה הכולל של המערכת מבעוד מועד ולא ניתן למכור ללקוח מוצר מוגמר לפני שנכתבה שורת קוד אחת. הפיתוח הוא באיטרציות קצרות על מנת לתת ללקוח "להרגיש" את המערכת ולקבל היזון חוזר שעוזר לקבוע את המשך הדרך. אגב, זה לא נכון שאין ממש עיצוב. אם אינני טועה מדובר על שני שלבי עיצוב בכל איטרציה: עיצוב לפני האיטרציה ועיצוב "חוזר" אחריה (Refactoring). כאשר בשלב העיצוב השני משפרים את הקוד הקיים ומכינים אותו לאיטרציה הבאה.
spike and user story
In order to understand 'spike' you need to know another term in extreme programming (xp) - 'user stories' user storiesis the xp way to deal with requirements (instead of use cases). each user story consist one or two sentence identification of how a user may use the system. In each xp iteration You should complete a few user stories. Typically ,a user stories is written on index cards (e.g. A5-sized), this Card can also store estimated time to implement, priority, and on back a list of acceptance tests(tests done by the customer). Now, lets move to the other term - 'spike'. a spikeis an accurate estimation of how long a user story will take to implement. it may consist of anything relevant to that purpose - some prototype code, research, test scenarios, talking to people, etc..
In order to understand 'spike' you need to know another term in extreme programming (xp) - 'user stories' user storiesis the xp way to deal with requirements (instead of use cases). each user story consist one or two sentence identification of how a user may use the system. In each xp iteration You should complete a few user stories. Typically ,a user stories is written on index cards (e.g. A5-sized), this Card can also store estimated time to implement, priority, and on back a list of acceptance tests(tests done by the customer). Now, lets move to the other term - 'spike'. a spikeis an accurate estimation of how long a user story will take to implement. it may consist of anything relevant to that purpose - some prototype code, research, test scenarios, talking to people, etc..
מנסה ליישר לשמאל...
In order to understand 'spike' you need to know another term in extreme programming (xp) - 'user stories' user storiesis the xp way to deal with requirements (instead of use cases). each user story consist one or two sentence identification of how a user may use the system. In each xp iteration You should complete a few user stories. Typically ,a user stories is written on index cards (e.g. A5-sized), this Card can also store estimated time to implement, priority, and on back a list of acceptance tests(tests done by the customer). Now, lets move to the other term - 'spike'. a spikeis an accurate estimation of how long a user story will take to implement. it may consist of anything relevant to that purpose - some prototype code, research, test scenarios, talking to people, etc..
Constant refactoring
המתודולוגיה הזאת מצריכה ממך לבצע שפצוב* מתמיד. אם כל פעם שאתה צריך הוסיף פיצ'ר חדש למערכת אתה קודם כך משנה את העיצוב שלה כדי שהתוספת תהיה קלה, אז תיאורטית המערכת תמיד נמצאת במצב של עיצוב אופטימלי. אני ממליץ על שימוש בשיטה הזאת גם כשאתה יודע מראש את הדרישות, פשוט בגלל הנטייה שלנו לעשות עיצוב יתר. ככה אני נמנע מהתפרעות - כל פעם אני מעצב את המינימום שצריך, ומשפצב לפי הצורך. אזהרה: אם אתה לא עושה שימוש נרחב ב-unit tests, אל תחשוב אפילו על הכיוון של שפצוב מתמיד. זה מאד מפחיד לבצע שינויים בקוד בלי לדעת מה הרסת... --- * שפצוב - כדי שלא אצטרך להעביר שפה כל פעם שאני רוצה לכתוב refactoring... אני ממליץ על המילה הזאת כתרגום העברי הרשמי
המתודולוגיה הזאת מצריכה ממך לבצע שפצוב* מתמיד. אם כל פעם שאתה צריך הוסיף פיצ'ר חדש למערכת אתה קודם כך משנה את העיצוב שלה כדי שהתוספת תהיה קלה, אז תיאורטית המערכת תמיד נמצאת במצב של עיצוב אופטימלי. אני ממליץ על שימוש בשיטה הזאת גם כשאתה יודע מראש את הדרישות, פשוט בגלל הנטייה שלנו לעשות עיצוב יתר. ככה אני נמנע מהתפרעות - כל פעם אני מעצב את המינימום שצריך, ומשפצב לפי הצורך. אזהרה: אם אתה לא עושה שימוש נרחב ב-unit tests, אל תחשוב אפילו על הכיוון של שפצוב מתמיד. זה מאד מפחיד לבצע שינויים בקוד בלי לדעת מה הרסת... --- * שפצוב - כדי שלא אצטרך להעביר שפה כל פעם שאני רוצה לכתוב refactoring... אני ממליץ על המילה הזאת כתרגום העברי הרשמי
Unit Tests
תוכניות אשר נועדו לבצע בדיקת נכונות על "יחידות" תוכנה (מתודות ומחלקות). הרעיון הוא לכתוב תוכנית אשר מבצעת את הבדיקות ומחזירה תשובה ברורה - "נכון" או "שגוי". בד"כ זה מתבצע ע"י תוכנית אשר מזינה קלט ליחידה אותה אתה רוצה לבדוק, ולאחר מכן בודקת את נכונות הפלט שמתקבל. Unit Tests נכתבות בד"כ על ידי המפתחים עצמם (ולא, למשל, ע"י אנשי ה-QA). המהדרין אף כותבים את תוכנית הבדיקה עוד לפני שהם כתבו את הקוד הנבדק (Test driven development). Unit Tests הן אמצעי הכרחי אם מתכוונים לבצע refactoring.
תוכניות אשר נועדו לבצע בדיקת נכונות על "יחידות" תוכנה (מתודות ומחלקות). הרעיון הוא לכתוב תוכנית אשר מבצעת את הבדיקות ומחזירה תשובה ברורה - "נכון" או "שגוי". בד"כ זה מתבצע ע"י תוכנית אשר מזינה קלט ליחידה אותה אתה רוצה לבדוק, ולאחר מכן בודקת את נכונות הפלט שמתקבל. Unit Tests נכתבות בד"כ על ידי המפתחים עצמם (ולא, למשל, ע"י אנשי ה-QA). המהדרין אף כותבים את תוכנית הבדיקה עוד לפני שהם כתבו את הקוד הנבדק (Test driven development). Unit Tests הן אמצעי הכרחי אם מתכוונים לבצע refactoring.
Copyright©1996-2021,Tapuz Media Ltd. Forum software by XenForo® © 2010-2020 XenForo Ltd.