מהם השלבים
- פותח הנושא ניר טייב
- פורסם בתאריך
לפני התחלת הפיתוח עצמו חשוב
לסגור את התהליכים הבאים: 1. הגדרת הדרישות - זיהוי דרישות הלקוח והחתמת הלקוח על הדרישות (הגדרת החוזה) 2. אפיון המערכת - חיבור הדרישות ביחד והגדרת אופן צורת עבודת המערכת (מסכים, מחלקות, DB, אבטחת מידע נדרשת וכל מה שקשור להגדרה של איך המערכת עובדת) 3. עיצוב המערכת - קביעת ארכיט' הפיתוח, הגדרת המחלקות הפיזיות, הקשרים ביניהם (dynamic model) והאחריות שמוטלת על כל מחלקה. משם אני מניח שאפשר לעבור לפיתוח. זו הצורה ה"סטנדרטית", אבל יש עוד הרבה צורות, הכל בהתאם למתודולוגיה בה אתה בוחר להשתמש (תסתכל בפורום, היו כמה דיונים בנושאי מתודולוגיה)
לסגור את התהליכים הבאים: 1. הגדרת הדרישות - זיהוי דרישות הלקוח והחתמת הלקוח על הדרישות (הגדרת החוזה) 2. אפיון המערכת - חיבור הדרישות ביחד והגדרת אופן צורת עבודת המערכת (מסכים, מחלקות, DB, אבטחת מידע נדרשת וכל מה שקשור להגדרה של איך המערכת עובדת) 3. עיצוב המערכת - קביעת ארכיט' הפיתוח, הגדרת המחלקות הפיזיות, הקשרים ביניהם (dynamic model) והאחריות שמוטלת על כל מחלקה. משם אני מניח שאפשר לעבור לפיתוח. זו הצורה ה"סטנדרטית", אבל יש עוד הרבה צורות, הכל בהתאם למתודולוגיה בה אתה בוחר להשתמש (תסתכל בפורום, היו כמה דיונים בנושאי מתודולוגיה)
מחזור חיי תוכנה
קודם כל חשוב לציין שאחד הרעיונות בחלוקה לשלבים הוא שהם יבוצעו ע"י אנשים שונים בעלי התמחויות מתאימות. בעולם האמיתי יש אנשים שאחראיים על יותר משלב אחד והשלבים לפעמים מתערבבים. הנה השלבים. התוצר של כל שלב הוא מסמך שבו משתמשים עבור השלב הבא. יזום - הלקוח מחליט שהוא צריך/רוצה מערכת. יכול להיות שמדובר במערכת חדשה ויכול להיות שמדובר בשדרוג של מערכת קיימת. תוצר השלב הוא רשימת דרישות הלקוח. חקר מצב קיים - מבוצע ע"י מנתח מערכות ביחד עם הלקוח. בשלב הזה בכלל לא מדברים תכנותית/טכנולוגית, אלא בודקים את התהליכים הקיימים/רצויים בארגון ואיך המערכת אמורה לעזור לבצע אותם. תוצר השלב הוא תיק ניתוח שמהווה חוזה בין הארגון לבין הגוף שמפתח את המערכת - כל מה שהמערכת אמורה לעשות צריך להיות מתועד בתיק הזה בצורה ברורה לשני הצדדים. אפיון - בשלב הזה מתחילים להתעסק עם טכנולוגיה. בודקים מה הטכנולוגיה הקיימת בארגון, האם היא מתאימה למערכת המבוקשת, עלויות שדרוג לטכנולוגיה, משך פיתוח משוער, איך מסכים יראו באופן כללי, מבנה של בסיסי נתונים באופן כללי ועוד דברים כאלה. כאן ללקוח יש חלק בשיקולים - הוא צריך להחליט כמה כסף הוא מוכן להשקיע, כמה זמן הוא מוכן לחכות, כמה זמן הוא מוכן להקצות להכשרה של המשתמשים וכו'. התוצר הוא תיק אפיון שאומר למעצב: "אלה הכלים שיש לך, אלה התהליכים שהמערכת אמורה לבצע ואלה המשאבים שיש לך". עיצוב - בשלב הזה הלקוח יוצא מהתמונה, כי כל מה שהיה לו להגיד אמור להיות מתועד בפירוט בתיק האפיון. בשלב העיצוב מחליטים על חלוקה לשכבות ולמודולים, מבנה מפורט של בסיסי נתונים, מסכים, שפות וטכנולוגיות (מתוך מה שאפשרי ע"פ תיק האפיון). יש תחום אפור בין העיצוב לקידוד שבו צריך להחליט כמה חופש אתה נותן לתוכניתן - האם החלוקה למודולים שבעיצוב סופית ומחייבת? האם לכתוב את האלגוריתם בעברית מבנית ואם כן עד איזו רמת פירוט? התוצר בשלב הזה הוא תיק עיצוב שבעצם אמור לענות על כל שאלה של התוכניתן. קידוד - כתיבת הקוד בהתאם לתיק העיצוב. בסופו יש לך את המערכת. בדיקות - כתיבת תרחישים ובדיקתם. אחרי ביצוע השלב הזה אתה חוזר לקוד ומתקן. אז אתה מבצע עוד סבב בדיקות וחוזר חלילה עד שאתה לא מוצא יותר באגים או עד שנגמר לך הזמן. לפעמים ידוע שיש באגים שלא נפתרו, ובמקרה כזה צריך לתעד אותם במסמך שהלקוח יקבל. שינויים ושיפורים - אחרי שהמערכת ניתנה ללקוח ונכנסה לשימוש, יעלו דרישות נוספות. כל דרישה צריכה לעבור את כל השלבים לפני שמשנים את המערכת כמובן. אלה השלבים של חיי התוכנה. שים לב שהם לא עונים לחלוטין על שאלתך המדוייקת לגבי תכנות נכון - זו שאלה ספציפית לשלבי העיצוב והקידוד, ולזה דרוש ידע בנושאי אלגוריתמיקה וסיבוכיות (כדי שתכתוב אלגוריתמים יעילים), הכרה של כלים קיימים בשוק או ברשת (כדי לקצר ולהקל את הקידוד עצמו) ולדעת איך לכתוב קוד יפה (הערות, הזחות, שמות משתנים ופונקציות משמעותיים, חלוקה לפונקציות ומודולים).
קודם כל חשוב לציין שאחד הרעיונות בחלוקה לשלבים הוא שהם יבוצעו ע"י אנשים שונים בעלי התמחויות מתאימות. בעולם האמיתי יש אנשים שאחראיים על יותר משלב אחד והשלבים לפעמים מתערבבים. הנה השלבים. התוצר של כל שלב הוא מסמך שבו משתמשים עבור השלב הבא. יזום - הלקוח מחליט שהוא צריך/רוצה מערכת. יכול להיות שמדובר במערכת חדשה ויכול להיות שמדובר בשדרוג של מערכת קיימת. תוצר השלב הוא רשימת דרישות הלקוח. חקר מצב קיים - מבוצע ע"י מנתח מערכות ביחד עם הלקוח. בשלב הזה בכלל לא מדברים תכנותית/טכנולוגית, אלא בודקים את התהליכים הקיימים/רצויים בארגון ואיך המערכת אמורה לעזור לבצע אותם. תוצר השלב הוא תיק ניתוח שמהווה חוזה בין הארגון לבין הגוף שמפתח את המערכת - כל מה שהמערכת אמורה לעשות צריך להיות מתועד בתיק הזה בצורה ברורה לשני הצדדים. אפיון - בשלב הזה מתחילים להתעסק עם טכנולוגיה. בודקים מה הטכנולוגיה הקיימת בארגון, האם היא מתאימה למערכת המבוקשת, עלויות שדרוג לטכנולוגיה, משך פיתוח משוער, איך מסכים יראו באופן כללי, מבנה של בסיסי נתונים באופן כללי ועוד דברים כאלה. כאן ללקוח יש חלק בשיקולים - הוא צריך להחליט כמה כסף הוא מוכן להשקיע, כמה זמן הוא מוכן לחכות, כמה זמן הוא מוכן להקצות להכשרה של המשתמשים וכו'. התוצר הוא תיק אפיון שאומר למעצב: "אלה הכלים שיש לך, אלה התהליכים שהמערכת אמורה לבצע ואלה המשאבים שיש לך". עיצוב - בשלב הזה הלקוח יוצא מהתמונה, כי כל מה שהיה לו להגיד אמור להיות מתועד בפירוט בתיק האפיון. בשלב העיצוב מחליטים על חלוקה לשכבות ולמודולים, מבנה מפורט של בסיסי נתונים, מסכים, שפות וטכנולוגיות (מתוך מה שאפשרי ע"פ תיק האפיון). יש תחום אפור בין העיצוב לקידוד שבו צריך להחליט כמה חופש אתה נותן לתוכניתן - האם החלוקה למודולים שבעיצוב סופית ומחייבת? האם לכתוב את האלגוריתם בעברית מבנית ואם כן עד איזו רמת פירוט? התוצר בשלב הזה הוא תיק עיצוב שבעצם אמור לענות על כל שאלה של התוכניתן. קידוד - כתיבת הקוד בהתאם לתיק העיצוב. בסופו יש לך את המערכת. בדיקות - כתיבת תרחישים ובדיקתם. אחרי ביצוע השלב הזה אתה חוזר לקוד ומתקן. אז אתה מבצע עוד סבב בדיקות וחוזר חלילה עד שאתה לא מוצא יותר באגים או עד שנגמר לך הזמן. לפעמים ידוע שיש באגים שלא נפתרו, ובמקרה כזה צריך לתעד אותם במסמך שהלקוח יקבל. שינויים ושיפורים - אחרי שהמערכת ניתנה ללקוח ונכנסה לשימוש, יעלו דרישות נוספות. כל דרישה צריכה לעבור את כל השלבים לפני שמשנים את המערכת כמובן. אלה השלבים של חיי התוכנה. שים לב שהם לא עונים לחלוטין על שאלתך המדוייקת לגבי תכנות נכון - זו שאלה ספציפית לשלבי העיצוב והקידוד, ולזה דרוש ידע בנושאי אלגוריתמיקה וסיבוכיות (כדי שתכתוב אלגוריתמים יעילים), הכרה של כלים קיימים בשוק או ברשת (כדי לקצר ולהקל את הקידוד עצמו) ולדעת איך לכתוב קוד יפה (הערות, הזחות, שמות משתנים ופונקציות משמעותיים, חלוקה לפונקציות ומודולים).
כמה תשובות
שלב היזום זו ההחלטה של הלקוח שהוא צריך מערכת חדשה או שדרוג למערכת קיימת. נגיד שבחודש האחרון אחראי התוכנה בארגון קיבל 20 תלונות מהמשתמשים שבכל פעם שהם מנסים לסגור חלון מסויים במערכת, היא עפה. הוא שולח אימייל לאיש הקשר שלו בבית התוכנה שפיתח לו את המערכת הזאת ומספר לו על הבעיה. זה היה שלב היזום. אחר כך נציג של בית התוכנה מגיע לארגון וביחד עם המשתמשים או נציג שלהם בודק איך הם עובדים. אולי הם מבצעים פעולות בלתי חוקיות? אולי הם מנסים להריץ את המערכת על מחשבים חלשים מדי? אולי המערכת לא בנויה לעבוד עם כמות נתונים מעבר לגודל מסויים? את כל זה בודקים בשלב חקר המצב הקיים. הסיפור יכול להיגמר כאן - פשוט מחליטים להוציא הוראה למשתמשים לא לבצע יותר את הפעולה שגורמת לתעופה (אם אפשר). החלטה אחרת יכולה להיות שדרוג החומרה בארגון. אם מחליטים שהולכים לתקן את הבאג הזה במערכת, צריך לראות בדיוק מה המשתמשים עושים שגורם לזה, ולוודא גם שהתיקון לא יגרום לבעיות במקומות אחרים. צריך לחשוב האם מתקנים את זה עכשיו או שמחכים לגירסה הבאה של המוצר. לסיכום, בחקר המצב הקיים אנשי מקצוע בודקים לעומק את טענות הלקוח ומציגים נקודות שהוא לא חשב עליהם. הנקודות האלה מתועדות בתיק הניתוח שאמור להוביל לפיתוח מסודר של המערכת בהתאם למה שהלקוח רוצה/מסכים. לפעמים ראוי שללקוח תהיה אמירה בדבר מבנה בסיס הנתונים. מכיר את המושגים Data Warehouse ומחוללי דו"חות? לפעמים הלקוח פשוט מקבל כלים שאיתם הוא יוכל להריץ כל מני דו"חות וסטטיסטיקות על הנתונים שלו במקום שיפתחו בשביל זה מערכת יעודית (וזה בהחלט רעיון טוב). בשביל זה הוא צריך לדבת גם את סוג בסיס הנתונים וגם את המבנה שלו. שים לב שסוג בסיס הנתונים הוא תת-סעיף נפרד ממבנה בסיס הנתונים, והוא נכלל בסעיף הטכנולוגיות באפיון (ביחד עם תשתיות תקשורת, מערכת הפעלה, חומרה של שרת ועמדות קצה וכו') כיוון שהוא קשור לחומרה ולמערכת ההפעלה, וגם היכולות שלו רלוונטיות (יש הבדל קטנטן בין היכולות של Oracle ושל Access למשל).
שלב היזום זו ההחלטה של הלקוח שהוא צריך מערכת חדשה או שדרוג למערכת קיימת. נגיד שבחודש האחרון אחראי התוכנה בארגון קיבל 20 תלונות מהמשתמשים שבכל פעם שהם מנסים לסגור חלון מסויים במערכת, היא עפה. הוא שולח אימייל לאיש הקשר שלו בבית התוכנה שפיתח לו את המערכת הזאת ומספר לו על הבעיה. זה היה שלב היזום. אחר כך נציג של בית התוכנה מגיע לארגון וביחד עם המשתמשים או נציג שלהם בודק איך הם עובדים. אולי הם מבצעים פעולות בלתי חוקיות? אולי הם מנסים להריץ את המערכת על מחשבים חלשים מדי? אולי המערכת לא בנויה לעבוד עם כמות נתונים מעבר לגודל מסויים? את כל זה בודקים בשלב חקר המצב הקיים. הסיפור יכול להיגמר כאן - פשוט מחליטים להוציא הוראה למשתמשים לא לבצע יותר את הפעולה שגורמת לתעופה (אם אפשר). החלטה אחרת יכולה להיות שדרוג החומרה בארגון. אם מחליטים שהולכים לתקן את הבאג הזה במערכת, צריך לראות בדיוק מה המשתמשים עושים שגורם לזה, ולוודא גם שהתיקון לא יגרום לבעיות במקומות אחרים. צריך לחשוב האם מתקנים את זה עכשיו או שמחכים לגירסה הבאה של המוצר. לסיכום, בחקר המצב הקיים אנשי מקצוע בודקים לעומק את טענות הלקוח ומציגים נקודות שהוא לא חשב עליהם. הנקודות האלה מתועדות בתיק הניתוח שאמור להוביל לפיתוח מסודר של המערכת בהתאם למה שהלקוח רוצה/מסכים. לפעמים ראוי שללקוח תהיה אמירה בדבר מבנה בסיס הנתונים. מכיר את המושגים Data Warehouse ומחוללי דו"חות? לפעמים הלקוח פשוט מקבל כלים שאיתם הוא יוכל להריץ כל מני דו"חות וסטטיסטיקות על הנתונים שלו במקום שיפתחו בשביל זה מערכת יעודית (וזה בהחלט רעיון טוב). בשביל זה הוא צריך לדבת גם את סוג בסיס הנתונים וגם את המבנה שלו. שים לב שסוג בסיס הנתונים הוא תת-סעיף נפרד ממבנה בסיס הנתונים, והוא נכלל בסעיף הטכנולוגיות באפיון (ביחד עם תשתיות תקשורת, מערכת הפעלה, חומרה של שרת ועמדות קצה וכו') כיוון שהוא קשור לחומרה ולמערכת ההפעלה, וגם היכולות שלו רלוונטיות (יש הבדל קטנטן בין היכולות של Oracle ושל Access למשל).
more on methodologies
It looks like you mentioned the old software process (methodology) - waterfall. (was first introduced in the 80') here are a short summery of others, categorized into two groups: non-agile ----------- waterfall cmm spiral cleanroom prototyping agile ----- xp - extreme programming scrum - focuses on project management Crystal - focuses on Use Cases open source aop - aspect-oriented programming DSDM - Dynamic System Development Method can be agile or non-agile ------------------------- rup - rational unified process
Copyright©1996-2021,Tapuz Media Ltd. Forum software by XenForo® © 2010-2020 XenForo Ltd.