מחזור החיים של פיתוח תוכנה (SDLC) הוא מודל רוחני המשמש בניהול פרויקטים המגדיר את השלבים הכלולים בפרויקט פיתוח מערכת מידע, החל מבדיקת היתכנות ראשונית ועד לתחזוקה של האפליקציה שהושלמה.
שיטת tostring
ישנם מודלים שונים של מחזור חיים לפיתוח תוכנה המפרטים ומתכננים, אשר עוקבים אחריהם במהלך שלב פיתוח התוכנה. דגמים אלה נקראים גם ' מודלים של תהליך פיתוח תוכנה .' כל מודל תהליך עוקב אחר סדרה של שלבים ייחודיים לסוגו כדי להבטיח הצלחה בשלב של פיתוח תוכנה.
הנה כמה שלבים חשובים של מחזור החיים של SDLC:
דגם מפל
המפל הוא דגם SDLC מקובל בכל העולם. בשיטה זו, כל תהליך פיתוח התוכנה מחולק לשלבים שונים.
מודל המפל הוא מודל פיתוח תוכנה מתמשך בו הפיתוח נתפס כמי שזורם בהתמדה כלפי מטה (כמו מפל) דרך שלבי ניתוח דרישות, תכנון, יישום, בדיקה (וולידציה), אינטגרציה ותחזוקה.
לסדר ליניארי של פעילויות יש כמה השלכות משמעותיות. ראשית, כדי לזהות את סוף השלב ואת תחילתו של הבא, יש להשתמש בכמה טכניקות הסמכה בסוף כל שלב. אימות ואימות מסויים עושים בדרך כלל את זה שיבטיח שהפלט של השלב תואם את הקלט שלו (שהוא הפלט של השלב הקודם), ושהפלט של השלב תואם את הדרישות הכוללות של המערכת.
דגם RAD
תהליך RAD או Rapid Application Development הוא אימוץ של מודל המפל; הוא מכוון לפיתוח תוכנה בתקופה קצרה. מודל ה-RAD מבוסס על התפיסה שניתן לפתח מערכת טובה יותר בזמן קצר יותר על ידי שימוש בקבוצות מיקוד לאיסוף דרישות המערכת.
- דוגמנות עסקית
- מודל נתונים
- מודל תהליכים
- יצירת אפליקציות
- בדיקות ותחלופה
דגם ספירלה
דגם הספירלה הוא א מודל תהליך מונחה סיכונים . מודל SDLC זה עוזר לקבוצה לאמץ אלמנטים של מודל תהליך אחד או יותר כמו מפל מים, אינקרמנטלי, מפל וכו'. טכניקת הספירלה היא שילוב של אב טיפוס מהיר ובמקביל בפעילויות עיצוב ופיתוח.
כל מחזור בספירלה מתחיל בזיהוי היעדים לאותו מחזור, החלופות השונות האפשריות להשגת היעדים והאילוצים הקיימים. זהו הרביע הראשון של המחזור (רביע שמאלי עליון).
השלב הבא במחזור הוא להעריך את החלופות השונות הללו על סמך היעדים והאילוצים. מיקוד ההערכה בשלב זה מבוסס על תפיסת הסיכון עבור הפרויקט.
השלב הבא הוא לפתח אסטרטגיות הפותרות אי ודאויות וסיכונים. שלב זה עשוי לכלול פעילויות כגון השוואת ביצועים, סימולציה ויצירת אב טיפוס.
דגם V
בסוג זה של בדיקת מודל SDLC והפיתוח, השלב מתוכנן במקביל. אז יש שלבי אימות בצד ושלב האימות בצד השני. V-Model מצטרף לפי שלב הקידוד.
מודל אינקרמנטלי
המודל המצטבר אינו מודל נפרד. זוהי בהכרח סדרה של מחזורי מפלים. הדרישות מחולקות לקבוצות בתחילת הפרויקט. עבור כל קבוצה, עוקבים אחר מודל SDLC לפיתוח תוכנה. תהליך ה-SDLC חוזר על עצמו, כאשר כל מהדורה מוסיפה פונקציונליות נוספת עד לעמידה בכל הדרישות. בשיטה זו, כל מחזור משמש כשלב התחזוקה עבור מהדורת התוכנה הקודמת. שינוי במודל המצטבר מאפשר למחזורי פיתוח לחפוף. לאחר אותו מחזור עוקב עשוי להתחיל לפני השלמת המחזור הקודם.
דגם זריז
מתודולוגיה זריזה היא תרגול המקדם אינטראקציה מתמשכת של פיתוח ובדיקות במהלך תהליך SDLC של כל פרויקט. בשיטת Agile, כל הפרויקט מחולק לבניינים מצטברים קטנים. כל הבניינים הללו מסופקים באיטרציות, וכל איטרציה נמשכת בין שבוע לשלושה שבועות.
כל שלב תוכנה זריז מאופיין באופן המתייחס למספר הנחות מפתח לגבי עיקר פרויקטי התוכנה:
- קשה לחשוב מראש אילו דרישות תוכנה ימשיכו ואילו ישתנו. קשה באותה מידה לחזות כיצד ישתנו סדרי העדיפויות של המשתמשים ככל שהפרויקט יתקדם.
- עבור סוגים רבים של תוכנות, עיצוב ופיתוח משתלבים. כלומר, שתי הפעילויות צריכות להתבצע במקביל כך שמודלים עיצוביים יוכחו עם יצירתם. קשה לחשוב כמה עיצוב נחוץ לפני השימוש בבנייה לבדיקת התצורה.
- ניתוח, עיצוב, פיתוח ובדיקות אינם צפויים (מנקודת מבט תכנונית) כפי שאנו עשויים לרצות.
מודל איטרטיבי
זהו יישום מסוים של מחזור חיים לפיתוח תוכנה המתמקד בהטמעה ראשונית ופשוטה, אשר זוכה בהדרגה למורכבות ולמערכת תכונות רחבה יותר עד להשלמת המערכת הסופית. בקיצור, פיתוח איטרטיבי הוא דרך לפרק את פיתוח התוכנה של אפליקציה גדולה לחתיכות קטנות יותר.
דגם המפץ הגדול
מודל המפץ הגדול מתמקד בכל סוגי המשאבים בפיתוח תוכנה ובקידוד, ללא תכנון או מעט מאוד. הדרישות מובנות ומיושמות כשהן מגיעות.
מודל זה עובד בצורה הטובה ביותר עבור פרויקטים קטנים עם צוות פיתוח בגודל קטן יותר שעובד יחד. זה שימושי גם עבור פרויקטי פיתוח תוכנה אקדמיים. זהו דגם אידיאלי שבו הדרישות אינן ידועות או שתאריך השחרור הסופי אינו מצוין.
דגם אב טיפוס
מודל האב-טיפוס מתחיל באיסוף הדרישות. המפתח והמשתמש נפגשים ומגדירים את מטרת התוכנה, מזהים את הצרכים וכו'.
א' עיצוב מהיר לאחר מכן נוצר. עיצוב זה מתמקד באותם היבטים של התוכנה שיהיו גלויים למשתמש. לאחר מכן זה מוביל לפיתוח של אב טיפוס. לאחר מכן הלקוח בודק את אב הטיפוס, וכל השינויים או השינויים הנדרשים מתבצעים באב הטיפוס.
לולאה מתרחשת בשלב זה, ונוצרות גרסאות טובות יותר של אב הטיפוס. אלה מוצגים באופן רציף למשתמש כך שניתן לעדכן כל שינוי חדש באב הטיפוס. תהליך זה נמשך עד שהלקוח מרוצה מהמערכת. ברגע שמשתמש מרוצה, אב הטיפוס מומר למערכת בפועל עם כל השיקולים לאיכות ואבטחה.