מתודולוגיית פיתוח תוכנה
מתוך ויקיפדיה, האנציקלופדיה החופשית
הנדסת תוכנה |
---|
מאמר זה הוא חלק מקטגוריית הנדסת תוכנה |
פעילויות ושלבים |
דרישות | ניתוח | ארכיטקטורה | עיצוב | תכנות | בדיקה | אימות | בניה | הצבה | תחזוקה |
מתודולוגיות |
מפל המים | תכנת ותקן |
תחומים תומכים |
ניהול פרויקטים | ניהול תצורה | תיעוד |
בהנדסת תוכנה, מתודולוגיית פיתוח תוכנה (או תפיסת פיתוח או בקיצור מתודולוגיה) היא סט מוסכם של עקרונות, תהליכים, פעילויות וכלים על פיהם מפותחות ומתוחזקות מערכות תוכנה. בהנדסת תוכנה יש כיום כתריסר מתודולוגיות עיקריות (קרי, שפורסמו ברבים וזכו לקבלה מסוימת בתעשיה). המתודולוגיות נבדלות ביחסן למקצוע הנדסת התוכנה ("מהי הנדסת תוכנה?") ועקרונות היסוד, המיקוד (ניהול פרויקט, ארכיטקטורה, עיצוב ותכנות, הבטחת איכות), הטכניקות ובהיבטים נוספים. בשל גילו הצעיר של הענף ובשל ריבוי המתודולוגיות אין עדיין הסכמה באשר למידת התאמתן של מתודולוגיות מסוימות לבעיות מסוימת, אם כי מקובל לחלק את המתודולוגיות למשפחות נפרדות. כלי עזר מקובל לבחירת מתודולוגיה מתאימה לפרויקט הוא סקלת קוֹבֶּרן.
תוכן עניינים |
[עריכה] מתודולוגיות קוויות
זוהי משפחה נאיבית של מתודולוגיות המבלבלות בין התוצר ההנדסי לפיתוחו. משפחה זו מבקשת לייחס את איכות התוצר ההנדסי לתהליכי הפיתוח של התוכנה. דהיינו, כשם שהתוצר ההנדסי (לדוגמה מטוס) עומד בקריטריונים מחמירים של יעילות, עמידות ודיוק, כך גם תהליכי פיתוח התוכנה עצמם חייבים לעמוד בקריטריונים דומים. החברה הבולטת במשפחה זו היא מתודולוגיית מפל־המים המורה על פיתוח תוכנה בתהליך קווי, חד־כיווני הדומה לפס־ייצור של מוצר הנדסי.
[עריכה] תכנת ותקן
תכנת ותתקן (ידועה גם בשם מהר ומלוכלך) היא המתודולוגיה המקובלת ביותר לתחזוקת מערכות תוכנה כיום, ובמידה מסוימת גם לפיתוח מערכות חדשות. מתודולוגיה זו שמה דגש רב על המהירות שבה נעשים שינויים ותיקונים למערכת התוכנה, תוך התעלמות מודעת מנושאי התחזוקתיות והאיכות הפנימית של התוכנה. מתודולוגיה זו מאפשרת הוספה מהירה של פונקציונליות חדשה למערכת, אך מחייבת חיזוק של המבנים הפנימיים של התוכנה מעת לעת וערכת בדיקות מקיפה. ללא האחרונים, שימוש עקבי במתודולוגיה זו יגרום בהכרח לשחיקה מעריכית באיכות הפנימית של התוכנה, עד לנקודה שבה עלות הוספת פונקציונליות חדשה שווה או גדולה לעלות בניית התוכנה כולה מחדש, שלאחריה אין הצדקה כלכלית להמשיך לתחזק את התוכנה.
[עריכה] מפל־המים
מפל-המים (ידועה גם בשם מודל מפל-המים) היא מתודולוגיה ותיקה ורווחת לפיתוח מערכות תוכנה. המתודולוגיה מיוחסת (בטעות) לוינסטון רויס, שהציע את הגרסה המקורית של המתודולוגיה במאמר שפורסם בשנת 1970. עם השנים נשתרשה פרשנות מוטעית למאמרו, והיא זו שמכונה כיום "מודל מפל-המים". בהקשרה ההיסטורי, המתודולוגיה נתפסה כתגובה לשיטות אד הוק של 'תכנת-ותקן' שרווחו מאוד בשנות השישים של המאה ה־20 (ועדיין רווחות). במודל מפל-המים, פיתוח התוכנה מתבצע בתהליך שיטתי ולוגי המורכב משלבים מוגדרים־היטב שאין לפסוח עליהם. השלבים מבוצעים בטור, אחד אחרי השני, ובכל שלב יש מיקוד במשימה עיקרית אחת בלבד. יש דגש רב על איסוף וניתוח של כל הדרישות כולן קודם לתחילת הפיתוח, ואין חזרה לאחור בתהליך לאחר ששלב מסוים בו הסתיים. השלבים העיקריים בשיטה זו הם איסוף וניתוח דרישות, עיצוב, מימוש, בדיקות, שילוב, התקנה ותחזוקה.
- ערך מורחב – מודל מפל-המים
[עריכה] מתודולוגיות איטרטיביות
זוהי משפחה של מתודולוגיות הרואות בפיתוח התוכנה תהליך מחזורי או ספירלי, שבו התוכנה נבנית בהדרגה, נדבך אחר נדבך. המתודולוגיות האיטרטיביות מייחסות חשיבות רבה לכלים, ארכיטקטורה וניהול התצורה, ושמות דגש על פיתוח החלקים המורכבים יותר מוקדם ככל האפשר, כדי להפחית את הסיכון בפיתוח.
[עריכה] Unified Process
Unified Process (או בקיצור UP) היא מתודולוגיה ששורשיה בעבודתו של בארי בם והורחבה על ידי פיליפ קרוצ'טן, גריידי בוץ' ואחרים. המתודולוגיה הוצגה לראשונה בין השנים 1995 - 1998. UP אינה מתודולוגיה במובן הקלאסי, אם כי מסגרת מתודולוגית שניתן להרחיבה ויש להתאימה לארגון או פרויקט מסוים. UP היא מתודולוגיה איטרטיבית המורה על פיתוח תוכנה בתהליך מחזורי רב-שלבי. המתודולוגיה שמה דגש על ניהול הפרויקט, ניהול השינוי, הארכיטקטורה ותהליכי המידול של התוכנה. ייחודה של UP הוא בדרכים המובנות בה המאפשרות להתאימה לסוגים וגדלים רבים של פרויקטים לפיתוח תוכנה, החל מפרויקטים קטנים ולא-קריטיים ועד לפרויקטי-ענק לפיתוח מערכות קריטיות תומכות-חיים. הטכניקות העיקריות של המתודולוגיה כוללות פיתוח מחזורי תחום-בזמן, ניהול השינוי באמצעות כלי ניהול שינויים ובקרת תצורה, ניהול הדרישות ומידול ויזואלי באמצעות UML.
[עריכה] מתודולוגיות זריזות
מתודולוגיה זריזה (באנגלית: Agile) לפיתוח תוכנה היא מתודולוגיה איטרטיבית שהותאמה לפיתוח תוכנה בצוותים קטנים תוך שימת דגש על יעילות, זריזות ואיכות. משפחה זו מקבלת בברכה שינויים במפרטי התוכנה, ומתייחסת לפיתוח כאל משחק של שיתוף פעולה מוכוון-מטרה (בדומה לטיפוס הרים). המתודולוגיות במשפחה זו שמות דגש רב על סביבת עבודה מתאימה, זרימת מידע אוסמוטית בין חברי הצוות, ותקורה פורמלית־טקסית נמוכה. עקרונות היסוד של משפחה זו נקבעו במשותף על־ידי רבים מהמובילים בחקר וביישום מערכות תוכנה, ופורסמו ברבים במנשר לפיתוח תוכנה זריז.
- ערך מורחב – פיתוח תוכנה זריז
[עריכה] Extremem Programming
eXtreme Programming (או בקיצור XP) היא מתודולוגיה שפותחה על ידי קנט בק, ומתוארת בספרו eXtreme Programming Explained שיצא לאור בשנת 2000, ובספרים נוספים שצצו בעקבותיו. שמה ניתן לה בשל העבודה שהשיטות המשמשות אותה הן מחמירות מאד, ובעת פרסומה נחשבו כקיצוניות יחסית לשיטות הקיימות בתעשיה. המתודולוגיה, כפי שרומז שמה, מפרטת שורה של טכניקות בתחום התכנות ופחות בתחומים אחרים של הנדסת תוכנה. מערכות המפותחות לפיה הן גמישות מאוד לשינויים, וניתן להרחיבן בקלות ובאופן בטוח. כדי להשיג גמישות זו, XP משתמשת בשיטת תכנות מונחה-בדיקות שעיקריה הם כתיבת דרישות המערכת כסט של בדיקות הניתנות להרצה, ופיתוח הבדיקות קודם לפיתוח הפונקציונליות. שיטה זו דורשת הבנה טובה של עקרונות תכנות מוכוון עצמים ומשמעת עצמית גבוהה.
- ערך מורחב – Extreme Programming
[עריכה] Crystal Clear
Crystal Clear היא מתודולוגיה שפותחה על ידי אליסטר קוברן ועקרונותיה מתוארים בספרים שפרסם החל משנת 1998. מתודולוגיה זו שמה דגש על יעילות בפיתוח ומפגינה סגלתנות רבה לשוני בדרכי העבודה האנושיות כפי שאלה מתבטאות בפיתוח תוכנה על ידי מתכנתים. המתודולוגיה מפרטת עקרונות לתכנות נכון אך מתמקדת יותר בעיצוב התוכנה וניהול הפרויקט. המתודולוגיה מתאימה לצוותים קטנים המפתחים תוכנה שאינה תומכת-חיים. ייחודה של Crystal Clear הוא בקלות היחסית שניתן להתאימה לאילוצים המופיעים פעמים רבות בפרויקטים לפיתוח תוכנה (לדוגמה, העדרו של לקוח), ובמסגרת נוחה להרחיבה גם לצוותים גדולים יותר.
[עריכה] Scrum
Scrum היא מתודולוגיה זריזה לניהול פרויקטים לפיתוח תוכנה שפותחה על ידי קן שוואבר ואחרים. המונח "Scrum" מקורו במשחק הרוגבי, שם הוא מתאר את הדרך שבה המשחק מתחיל מחדש לאחר שהכדור יצא מהמגרש. הטכניקה של "התחלה מחדש" היא אחת מאבני היסוד של השיטה - פרויקט Scrum מתחיל את תהליך הפיתוח כל חודש מחדש. כלומר, פעם בחודש מסופקת תוכנה עובדת למשתמשים, והערותיהם, כמו גם הדרישות החדשות, מיושמות במחזורי הפיתוח העוקבים. כיום מקובל להשתמש ב־Scrum כמעטפת לניהול פרויקטים המפותחים במתודולוגיית XP ומתודולוגיות זריזות אחרות.
- ערך מורחב – Scrum
[עריכה] השוואה בין המשפחות
נושא | מתודולוגיות קוויות | מתודולוגיות איטרטיביות | מתודולוגיות זריזות |
---|---|---|---|
תגובה לשינויים | גרועה | בינונית | טובה מאד |
משמעת נדרשת | נמוכה | בינונית | גבוהה מאד |
רמה מקצועית נדרשת | נמוכה | נמוכה עד בינונית | בינונית עד גבוהה |
דגש על מסמכים | כן | בינוני עד גבוה | לא |
דגש על קוד עובד | לא | בינוני | כן |
דגש על בדיקות אוטומטיות | לא | לא | כן |
דגש על פיתוח מקצה-לקצה | לא | בינוני | כן |
גודל הצוות | אין מגבלה תיאורטית | עד מאות | עד 14, ניתן להגדיל בשילוב עקרונות נוספים |
קלות הטמעה | קל מאד | בינוני עד קשה | קשה עד קשה מאד |
מידת השימוש בתעשיה | רבה מאד | בינוני-נמוך | מועטה |
ותק | משנות ה-70 | משנות ה-90 | מתחילת המאה ה-21 |
[עריכה] ראו גם
[עריכה] לקריאה נוספת
- Kruchten, Philip, Kroll Per (2003). The Rational Unified Process Made Easy, Addison-Wesley, ISBN 0321166094
- Larman, Craig (2003). Agile and Iterative Development: A Manager's Guide, Addison-Wesley, ISBN 0131111558