מודלים בפיתוח תוכנה
קיימות שיטות רבות לפיתוח תוכנה, לא מתיימרת להביא פה את כולם, אלא את המרכזיות כיום בשוק, וזאת רק כדי להתמקד איך בכל מודל של פיתוח תוכנה, הבודק נכנס לפעולה מתי ובאיזו דרך.
Requirement Analysis
System Design
Implementation
System Testing
System Deployment
System Maintenance
מודל מפל המים:
מודל הפיתוח הותיק ביותר. במודל זה פיתוח התוכנה מתבצע כתהליך טורי ובכל שלב יש משימות עד לשלב פיתוח המוצר:
איסוף וניתוח דרישות, עיצוב תוכנה, תכנות, בדיקות, שילוב, התקנה ותחזוקה.
רק כאשר יש כבר מוצר, נכנסים הבודקים לפעולה, לפני מסירתו ללקוח.
במודל זה, לכל שלב יש את המשימות שלו, מה שהופך את התהליך לארוך ומורכב שלא מתמודד כל כך טוב עם שינויים.
אפשר להגיד שמכיוון שהבודקים נכנסים לעניינים רק לאחר שכבר יש מוצר קיים, עלולים להיווצר בעיות מורכבות שמצריכות להחזיר את המוצר למפתחים, מה שמעלול להכביד בעלויות הפיתוח ובזמן התפוקה.
מודל V
במודל זה יש וידוא (validation) ואימות (verification) בכל שלבי הפיתוח ע"מ לאתר תקלות בשלבים מוקדמים יותר של פיתוח התוכנה:
אמנם בכל שלב יש בדיקה, אך בכל שלב מטרות הבדיקה הן שונות.
בצד השמאלי של המודל, נראה את תהליך אימות המערכת - מקבלת הדרישות, עיצוב הבדיקות ולבסוף כתיבת התוכנה. בשלבים אלו בעיקר נבצע בדיקות סטטיות (static testing) – בדיקות מעבר על הקוד לאישור שאכן התוכנה תבנה בצורה נכונה ובעצם תענה על השאלה: Are you building the thing right?
בצד הימני של המודל, נמצא את תהליך וידוא המערכת בכל רמת בדיקה, שאכן התוכנה מבצעת את מה שהיא אמורה לעשות כפי שנקבעו בדרישות – האם בונים את התוכנה הנכונה ללקוח: Are you building the right thing?
המודל הספיראלי / האיטרטיבי Interative – incremental development model
פיתוח המערכת מתבצע בשלבים קטנים - נקראים גרסאות. לכל גירסה מתייחסים כמו במודל V - עוברת את תהליך הוידוא והאימות בכל שלב בפיתוח.
כיוון שכך, הפיתוח גמיש יותר לשינויים (עדכונים שיכולים להיכנס בגרסה הבאה) וניתן לתת תוצרים באופן מהיר יותר.
בדיקות התקפות והאימות מתבצעים כל הזמן וגם קבלת פידבקים מהלקוח.
במודל זה ישנה חשיבות רבה לבדיקות רגרסיה- בדיקות שמוודאות שכאשר הכנסנו גירסה חדשה, לא הרסנו משהו אחר מגירסה ותיקה יותר.
אג'יל – Agile software development
פיתוח תוכנה זריז – התמקדות בשיפור יכולת הצוות לספק תוצרים במהירות ולהגיב לדרישות העולות תוך כדי הפיתוח. הגישה שמה דגש על יכולת התגובה לשינוי, יעילות ואיכות.
עקרונות הגישה:
פשטות שביעות רצון לקוח ומסירה מהירה ועקבית של תוכנה יעילה.
העובדים בעלי המוטיבציה הם לב הפרוייקט.
שינויים מתקבלים בברכה ויש צורך בהסתגלות תמידית שיתוף פעולה צמוד בין אנשי הביזנס למפתחים.
מומלץ לקרוא בויקיפדיה את הערך "פיתוח תוכנה זריז"
בהתאם לגישה המתפתחת, נוצרו לה תת גישות מעניינות - כל הגישות שואפות לבצע את המשימות ביעילות ובמהירות:
גישת הסקראם – scrum – מבוססת על צוותי פיתוח קטנים בדגש על אינטראקציות שוטפות ואחדות צוותית שבה כל משימה מתבצעת בזמן קצוב, נקרא ספרינט.
גישת הקאנבאן - Kanban -מוותרים על ספרינטים, יודעים שיש משימות ומבצעים, תחת שיפור מתמיד והפצת המדדים.
הבדלים נוספים בין הגישות - מעמד העובדים וסמכויותיהם, פרסום תוצרים ועוד.
בדיקות באג'יל:
בודקים ומפתחים עובדים יחדיו ויש תקשורת ישירה עם הלקוח. הבדיקות יכולות להתחיל עוד לפני שהפיתוח הסתיים - הבודק מסייע למפתח בתהליך הפיתוח באמצעות הבדיקות.
יתרונות השיטה:
זמן פיתוח קצר – TTM – time to market איכות תוכנה גבוהה יותר (ע"י בדיקות אוטומטיות רבות, בדגש על אוטומציה משלב ה unit test), תוצרים יותר צפויים, פרודוקטיביות הפיתוח, עלות נמוכה ושביעות רצון הלקוח גבוהה יותר.