מחזור פיתוח התוכנה
הוצג| English | משמעות |
|---|---|
| requirements/rɪˈkwaɪəmənts/ | דרישות |
| development life cycle/dɪˈveləpmənt laɪf ˈsaɪkl/ | מחזור חיי פיתוח |
| waterfall/ˈwɔːtəfɔːl/ | מודל מפל |
| maintenance/ˈmeɪntənəns/ | תחזוקה |
| iterative model/ˈɪtərətɪv ˈmɒdl/ | מודל איטרטיבי |
| rapid application development/ˈræpɪd ˌæplɪˈkeɪʃn dɪˈveləpmənt/ | פיתוח אפליקציות מהיר (RAD) |
| prototype/ˈprəʊtəʊtaɪp/ | דגם ראשוני |
| agile/ˈædʒaɪl/ | אג'ייל |
| implementation/ˌɪmplɪmənˈteɪʃn/ | יישום |
נמל התעופה שנפתח שש עשרה חודשים מאוחר יותר
- נמל התעופה החדש בדנוור צפוי להיפתח באוקטובר 1993 עם מערכת המזוודות החסודה ביותר שנבנתה לעולם: 4,000 עגלות אוטומטיות, 35 ק"מ מסילה, ללא מגע אנושי. הוא נפתח בפברואר 1995, $560 מיליון מעל התקציב, כאשר העגלות קטלו מזוודות במבחני ביצוע.
- הטבל זמן נקבע לפני שאף אחד ניתח מה שהמערכת צריכה לבצע. הדרישות המשיכו להשתנות בזמן שבנייה. הבדיקות החלו כשאין עוד זמן לתקן מה שמצאו.
- לכל כשל כזה יש שם בלקציה זו. מחזור חיי פיתוח קיים כך שפרויקט יתוכנן, ינוהל ויבוקר במקום להתגלות.
- לקציה זו היא מה שמועדון חיים עבור, שלושת המודלים שתיבת הבחינה מונה, וחמישת השלבים שעובר כל תוכנית.
מדוע נדרש מחזור חיים
- מחזור חיי פיתוח הוא סט השלבים מהרעיון ועד לתוכנה מוגמרת ומתוחזקת. מטרתו היא לתכנן, לנהל ולבקר בפרויקט: המוצר הנכון, בזמן, עם איכות טובה.
- הוא מנהל מורכבות על ידי פיצול תוכנית גדולה לפאזים, מתאם צוות, ועוקב אחר התקדמות מול נקודות קיבוץ.
- הוא בונה בדיקות בתוך התהליך ולא משאיר אותן לסוף, מתעד החלטות עיצוב למי שישמור על התוכנית מאוחר יותר, ומנהל סיכונים.
מחזור חיים של פיתוח משמש ל:
Difficulty 1/5 · 100 coins + a small bonus on first completion today
הוא מארגן את העבודה לשלבים כך שהצוות יבנה את המוצר הנכון, בזמן, עם איכות.
מהם המטרות של מחזור חיים של פיתוח? סמן את כולם החלים.
Difficulty 2/5 · 140 coins + a small bonus on first completion today
מחזור חיים מתכנן, מנהל ובוקר. הוא אינו מבטיח נכונות; הוא הופך למציאת תקון ולתיקון טעויות חלק מהתוכנית.
מדוע יש יותר מאחד
- אין מחזור חיים אחד שמתאים לכל פרויקט, לכן קיימים מספר רבים והבחינה דורשת ממך לבחור.
- הבחירה תלויה בגודל ובמורכבות של התוכנית, כמה ברורות ה-דרישות בהתחלה, כמה שינויים מצופים, הסיכון אם זה נכשל, הצוות, והמועד הסופי.
- מערכת משכורות עם חוקים משפטיים קבועים ומשחק שבהם השחקנים עדיין לא יודעים מה הם רוצים הם פרויקטים שונים. הם ראויים למחזור חיים שונה.
מפלל
- מודל המפלל הוא רצף ליני: ניתוח, עיצוב, כתיבת קוד, בדיקה, תחזוקה. כל שלב מושלם, מתועד ומאושר לפני שמתחיל השלב הבא.
- יתרונות: מבנה ברור, קל לניהול ולתכנון, תיעוד מקיף בכל שלב, מתאים היטב ל-דרישות יציבות.
- חסרונות: שינוי בדרישות באמצע הפרויקט אומר לחזור למעלה במפלל; הלקוח לא רואה דבר פעיל עד הסוף; שגיאות בניתוח מופיעות רק בבדיקות.
המים אינם זורמים חזרה למעלה
מודל מפלול מתאים ביותר לפרויקטים שבהם:
Difficulty 1/5 · 100 coins + a small bonus on first completion today
המודל Waterfall הוא ליניארי, כאשר כל שלב מושלם לפני שמתחיל השלב הבא — מתאים מאוד לדרישות יציבות, אך לא מתאים לשינויים במהלך הפרויקט.
במודל Waterfall הלקוח רואה גרסה פועלת של התוכנה בשלב מוקדם בפרויקט.
Difficulty 1/5 · 100 coins + a small bonus on first completion today
דבר לא פועל עד שלב הכתיבה והבדיקה, הקרוב לסוף. ראיה מוקדמת לתוכנה פועלת היא חוזקו של המודל האיטרטיבי ושל RAD.
איטרטיבי
- המודל האיטרטיבי מבצע מעברים חוזרים. כל מעבר מייצר גרסה עובדת חלקית שנבדקת על ידי המשתמש ומשופרת במעבר הבא.
- יתרונות: בעיות נתפסות מוקדם יותר; המשתמש רוא תוכנה עובדת מוקדם ובמרווחים קצרים; טוב כאשר הדרישות נתגלות לאורך זמן.
- חסרונות: קשה יותר להעריך את העלות והזמן הכוללים; בדיקות חוזרות דורשות תשומת לב מהמשתמש; העיצוב עלול לסט מהמסלול ללא משמעת.
בנייה, הצגה, שיפור, חזרה לתהליך
פיתוח אפליקציות מהיר
- פיתוח אפליקציות מהיר (RAD) בונה מודל ראשוני במהירות, מציג אותו בפני המשתמשים ומבנה אותו מחדש בהתאם למשוב שלהם עד שהפכך למוצר. צוותים לעיתים קרובות עובדים על חלקים במקביל.
- יתרונות: אספקה ראשונית מהירה מאוד; דרישות משתנות נבלעות כפי שהן מופיעות; המשתמשים מעצבים את המוצר ישירות.
- חסרונות: הוא תלוי בזמינות המשתמשים לאורך כל התהליך; קיצורי הדרך במודל הראשוני עלולים להישאר במוצר הסופי; מתאים יותר למערכות קטנות מאשר למערכות גדולות הקריטיות לבטיחות. שיטות אג'ایل לוקחות את הרעיון הזה צעד אחד קדימה, עם ספרינטים קצרים ובדיקות מתמשכות.
מודל ראשוני, משוב, מודל ראשוני שוב
במודל Waterfall כל שלב מושלם לפני שמתחיל השלב הבא, בעוד ש-Agile עובד בספרינטים איטרטיביים קצרים עם משוב מתמיד.
Difficulty 1/5 · 100 coins + a small bonus on first completion today
Waterfall הוא ליניארי (מתאים לדרישות יציבות); Agile משתמש באינטראקציות קצרות עם שיתוף פעולה ובדיקות מתמשכות עם הלקוח.
התאם כל מודל לעיקרון המרכזי שלו.
Difficulty 2/5 · 140 coins + a small bonus on first completion today
Waterfall = ליניארי; איטרטיבי = שיפור חוזר; RAD = מונע-פרוטוטיפ ומהיר.
התפתחות אפליקציות מהירה בונה ____ שמשתמשים מנסים ומעניקים משוב עליו, ולאחר מכן בונים אותו מחדש.
Difficulty 1/5 · 100 coins + a small bonus on first completion today
הפרוטוטיפ הוא תכונת המגדירה של RAD; משוב משתמשים עליו הוא האופן שבו הדרישות נתגלות.
דוגמה פותרת: בחירת מחזור חיים והסברתו
- חברה זקוקה לתוכנה לחישוב השכר של עובדים בהתאם לחוקי מס הקבועים בחוק. איזה מחזור חיים, ולמה? מודל מפל המים: הדרישות יציבות וידועות לחלוטין בתחילה, החוקים ניתנים לתיעוד מלא בשלב ההצלחה, והתיעוד המפורט חשוב למערכת שחייבת להיות נכונה ועוברת ביקורת.
- סטארט-אפ רוצה אפליקציה לסוג חדש של אירוע חברתי; המשתמשים שלו אינם בטוחים אילו תכונות הם רוצים. פיתוח אפליקציות מהיר: הדרישות לא ברורות ומשתנות, לכן מודל ראשוני שמשתמשים ניסו ועורכים לו תגובה מגלה אותן במהירות, והמערכת הקטנה מתאימה לבנייה חוזרת מהירה.
- קראו את שם המודל, ולאחר מכן קשרו שניים מתכונותיו לשני עובדות מהתרחיש.
צוות קטן צריך לבנות אפליקציה שהמשתמשים שלה לא בטוחים מה הם רוצים, והמשתמשים יכולים לנסות גרסאות כל שבוע. איזו מחזור חיים מתאים ביותר?
Difficulty 1/5 · 100 coins + a small bonus on first completion today
דרישות לא ברורות ומשתנות בשילוב עם נגישות משתמשים היא המקרה של RAD. במודל מפל מים הדרישות חייבות להיות קבועות בהתחלה.
חמישת השלבים
- הצלחה: למצוא מה התוכנה חייבת לעשות; לאסוף ותיעד את הדרישות מהמשתמשים.
- עיצוב: קביעת איך: מבני נתונים, אלגוריתמים, מודולים, ממשק משתמש, פריסת קבצים, המוצגים בתרשימי מבנה, תרשימי זרימה ופסדו-קוד.
- כתיבת קוד (יישום): כתיבת קוד המקור בהתאם לעיצוב. בדיקה: הרצה נגד נתוני בדיקה מתוכננים ותיקון שגיאות שנמצאו.
- תחזוקה: לאחר השחרור, שמירה על תפקודיות ושימושיות, תיקון תקלות, התאמה לשינויים ושדרוג.
מחזור פיתוח התוכנה
עבורו בשלבים שעובר כל פרויקט. קבלת הדרישות הנכונה במחקר היא הקריטית ביותר — טעות שנמצאת בבדיקה יקרה הרבה יותר לתקון מאשר זו שנמצאת מוקדם.
שלב הניתוח עוסק בעיקר בקביעת:
Difficulty 1/5 · 100 coins + a small bonus on first completion today
ניתוח אוסף דרישות (ה"מה"); עיצוב קובע את ה"איך".
סדרו את שלבי מחזור חיי הפיתוח בתוכנה בסדר הנכון.
Difficulty 3/5 · 200 coins + a small bonus on first completion today
מה, איך, בניה, בדיקה, שמירה על פעילות. במודל האיטרטיבי השלבים האמצעיים חוזרים על עצמם, אך הסדר בתוך כל סיבוב נשאר זהה.
דוגמה עבודה: מה קורה בשלב ניתוח ועיצוב
- הסבר מה קורה במהלך שלבי הניתוח והעיצוב של מחזור חיי הפיתוח. [4]
- ניתוח: המתפתחים מראיינים ומצפים למשתמשים כדי להבין מה התוכנה צריכה לבצע; הם מזהים את הקלט, הפלט והעיבוד הנדרש, וכותבים תיעוד דרישות שאותו הלקוח מאשר.
- עיצוב: המתפתחים מחליטים איך התוכנה תענה לדרישות אלו: הם בוחרים את מבני הנתונים והאלגוריתמים, מפצלים את התוכנה למודולים בתרשים מבנה, מעצבים מסכים וקבצים, וכותבים פסדו-קוד.
- שני פעולות ותוצר לכל שלב. "הםנתחים את הבעיה" היא פשוט חזרה על הכותרת ואינה נחשבת לתשובה.
סימונים נופלים מהיד
- הניתוח הוא מה, העיצוב הוא איך. "החלטה על האלגוריתמים" שייכת לעיצוב.
- Waterfall אינו "הרע". חוזקו הוא בדרישות יציבות ומתועדות; חולשתו היא שינויים. יש לציין גם את היתרונות וגם את החסרונות כאשר נשאלים על שניהם.
- RAD אינו רק "מהיר". המאפיין המגדיר שלו הוא המודל הראשוני (פרוטוטייפ) ומשוב המשתמשים לגבילו.
- תחזוקה היא שלב ולא מחשבה נוספת: רוב עלות מחזור החיים של תוכנה מושקעת בשלב זה.
הבנתך מושלמת
- מחזור חיים מתכנן, מנהל ושולט בפרויקט: שלבים, נקודות ציון, בדיקות מובנות, תיעוד החלטות, ניהול סיכונים.
- Waterfall: ליניארי, כל שלב מאושר, מתאים לדרישות יציבות, לא מתאים לשינויים · Iterative: גרסאות חוזרות ומשופרות, זיהוי בעיות מוקדם, קשה יותר להעריך · RAD: פרוטוטייפ עם משוב משתמשים, מהיר וגמיש, דורש משתמשים זמינים.
- בחירה לפי ברירות הדרישות, שינויים צפויים, גודל וסיכון, עם הסבר בהתאם לתרחיש.
- השלבים: ניתוח (מה) → עיצוב (איך) → כתיבת קוד → בדיקה → תחזוקה.