מודל מחזור חיי פיתוח תוכנה (SDLC)

מְחַבֵּר: Lewis Jackson
תאריך הבריאה: 10 מאי 2021
תאריך עדכון: 23 יוני 2024
Anonim
מחזור חיים של פיתוח מוצר תוכנה
וִידֵאוֹ: מחזור חיים של פיתוח מוצר תוכנה

תוֹכֶן

הגדרה - מה המשמעות של מודל מחזור החיים של פיתוח תוכנה (SDLC)?

מודל מחזור חיי פיתוח תוכנה (SDLC) הוא מסגרת רעיונית המתארת ​​את כל הפעילויות בפרויקט פיתוח תוכנה מתכנון ועד תחזוקה. תהליך זה משויך למספר דגמים, שכל אחד מהם כולל מגוון משימות ופעילויות.

פיתוח תוכנה היא פעילות מסורבלת המחייבת זיהוי נכון של הדרישות, יישומן ופריסת התוכנה. עם זאת, הפעילויות לא מסתיימות שם. לאחר הפצת התוכנה, יש לספק תחזוקה נאותה בזמן.

מונח זה ידוע גם כמודל תהליכי פיתוח תוכנה.


מבוא ל- Microsoft Azure ו- Microsoft Cloud | במהלך מדריך זה תוכלו ללמוד על אודות מיחשוב ענן וכיצד Microsoft Azure יכולה לעזור לכם להעביר ולנהל את העסק שלכם מהענן.

Techopedia מסביר מודל מחזור חיים לפיתוח תוכנה (SDLC)

פעילויות פיתוח התוכנה העיקריות כוללות:

  • מיצוי דרישות: ללקוח יש מושג מעורפל מה נדרש. לאחר ניתוח מעמיק של הדרישות ושלבי התכנון כדי להגיע ליעד, רעיון הלקוח המופשט מיושם על ידי קבוצה של מהנדסי תוכנה.
  • תיאור תוכנה: מתאר שהתוכנה היא השלב הבא בתהליך.
  • ייצוג מערכת מופשט: נוצר כדי לאשר שהוא עומד בדרישות המוצר ומתממשק עם מוצרי תוכנה אחרים יחד עם החומרה שבבסיס.
  • דרישות הלקוח: מיושם באמצעות הקוד שתוכנת על ידי מהנדסי תוכנה.
  • בדיקת קוד: הקוד נבדק כדי לוודא שהוא נקי מבאגים ודואג לדרישות הלקוח.
  • תיעוד של העיצוב הפנימי: לתחזוקה עתידית ושיפור המוצר.
  • תחזוקה: זה מבוצע כדי לשנות את ארכיטקטורת המערכת בהתאם לצרכים העתידיים. זה עשוי לדרוש הוספת קוד או שינוי של הקוד הקיים.

תהליך הפיתוח שלעיל מתייעל על ידי סדרת דגמים. צוות הפיתוח בוחר את הדגם המתאים ביותר. הדגמים השונים הם:


  • מודל מפל מים: המפתחים מציינים את הדרישות, מנתחים אותם, קובעים פתרון ומסגר ארכיטקטורת תוכנה, ייצוג ממשק ופרטים אלגוריתמיים. ואז הם מפתחים את הקוד, בודקים את הקוד, פורסים את התוכנה ומתחזקים אותו. אמנם קל להבין את שיטת המפל וקובעת יציבות דרישה, אך היא עשויה ליצור רושם כוזב של לא לספק הרבה השתתפות של לקוחות. הבעיה העיקרית במודל זה היא שידוע מראש על הדרישה לתיקון שגיאות ובשלב מוקדם. אחרת, כל התהליך עשוי להימשך בכיוון לא נכון, מה שעלול להשפיע לרעה על עלות הייצור.
  • דגם בצורת V: הוא וריאציה של מודל המפל. זה מדגיש אימות ואימות של המוצר. ניתן לבחון את כל התוצרים וההתקדמות במעקב אחר אבני דרך. הבדיקה מיושמת במקביל לשלב הפיתוח.
  • דגם אב-טיפוס: אב-טיפוס מפותח בשלב הדרישות ומוערך על ידי משתמשי קצה. בהתבסס על משוב של משתמשים, מפתחים משנים את אב הטיפוס כדי לספק את דרישות המשתמש. בעוד שמודל זה מסיים את הדרישות בקלות, השימוש בו בסביבת הייצור עשוי לגרום לבעיות איכות ובכך לגרום לתהליך התיקון להימשך לנצח.
  • דגם ספיראלי: עושה שימוש במודלים של מפל וגם של דגמי אב-טיפוס. הוא מוסיף שפות תכנות מהדור הרביעי, טיפוס מהיר של פיתוח יישומים וניתוח סיכונים למודל המפלים. דרישות המערכת מתוכננות ונוצר תכנון ראשוני של המערכת. אב טיפוס ראשוני מתוכנן ונבדק. על סמך הערכת תוצאות הבדיקה, נוצר אב-טיפוס שני. אבות טיפוס עוקבים בנויים על מנת להבטיח שביעות רצון לקוחות. המערכת נוצרת בהתבסס על אב הטיפוס הסופי. המערכת הסופית מוערכת ונבדקת. אף על פי שמודל זה מפחית סיכון במידה רבה, יתכן שהוא אינו עומד בתקציב והוא מיושם באופן שונה עבור כל יישום.
  • מודל SDLC איטרטיבי ומצטבר: מציין ומיישם חלק מהתוכנה, אשר נבדקת ואז דרישות נוספות נוספו ומיושמות בקבוצות. כל מהדורה מספקת מוצר תפעולי המציג ללקוחות קודם כל פונקציות חשובות, ומוריד את עלויות המסירה הראשוניות. הסיכון לשינוי דרישות מופחת מאוד והלקוחות רשאים להגיב לכל בנייה. למרות חוזקותיו, מודל זה דורש תכנון טוב והגדרה מוקדמת של המערכת השלמה והפונקציונאלית המלאה. זה דורש גם ממשקי מודול מוגדרים היטב.
  • מודל פיתוח זריז: משמש ליישומים קריטי זמן בארגונים המשתמשים בשיטות ממושמעות. זה מזרז את שלבי מחזור החיים וצמצם את היקפו.
  • מודל תיבת הקסמים: הוא מודל פיתוח אפליקציות אינטרנט. זוהי הדרך המהירה ביותר לסיים את הפרויקט במינימום באגים מכיוון שהוא מספק את ההזדמנות לשנות את מבני הקוד ואת מסד הנתונים.