| **הנדסת תוכנה** |
| --- |
| ערך זה שייך לקטגוריית הנדסת תוכנה |
| **פעילויות** ו**שלבים** |
| דרישות • ניתוח • אפיון • ארכיטקטורה • עיצוב • תכנות • דיבוג • בדיקה • אימות • בנייה • פריסה • תפעול • תחזוקה |
| **מתודולוגיות** |
| זריזות • מפל המים • תכנת ותקן • Crystal Clear • Scrum • Unified Process • Extreme Programming • אינטגרציה רציפה • DevOps |
| **תחומים תומכים** |
| ניהול פרויקטים • ניהול תצורה • תיעוד • הבטחת איכות • Profiling |
| **כלים** |
| מהדר • מקשר • מפרש • IDE • ניהול גרסאות • אוטומציית בנייה |

בהנדסת תוכנה, **מתודולוגיית פיתוח תוכנה** או **תפישת פיתוח** היא סט מוסכם של עקרונות, תהליכים, פרקטיקות וכלים על פיהם מפותחות ומתוחזקות מערכות תוכנה. בהנדסת תוכנה יש כיום כתריסר מתודולוגיות עיקריות (קרי, שפורסמו ברבים וזכו לקבלה מסוימת בתעשייה), וכן מאות אחרות, משניות. המתודולוגיות נבדלות ביחסן למקצוע הנדסת התוכנה ("מהי הנדסת תוכנה?"), עקרונות היסוד, המיקוד (ניהול פרויקט, ארכיטקטורה, עיצוב ותכנות, הבטחת איכות), הטכניקות ובהיבטים נוספים. בשל גילו הצעיר של הענף ובשל ריבוי המתודולוגיות, אין עדיין הסכמה באשר למידת התאמתן של מתודולוגיות מסוימות לבעיות מסוימות, אם כי מקובל לחלק את המתודולוגיות למשפחות נפרדות. כלי עזר מקובל לבחירת מתודולוגיה מתאימה לפרויקט הוא סקלת קוֹבּרן.

מתודולוגיות קוויות
------------------

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

### תַכנת ותַקן

 ערך מורחב – **מתודולוגיית תכנת ותקן**  

תכנת ותקן (ידועה גם בשם "מהר ומלוכלך") היא המתודולוגיה המקובלת ביותר לתחזוקת מערכות תוכנה כיום,[דרוש מקור] ובמידה מסוימת, גם לפיתוח מערכות חדשות. מתודולוגיה זו שמה דגש רב על המהירות שבה נעשים שינויים ותיקונים למערכת התוכנה, תוך התעלמות מודעת מנושאי התחזוקתיות והאיכות הפנימית של התוכנה. מתודולוגיה זו מאפשרת הוספה מהירה של פונקציונליות חדשה למערכת, אך מחייבת חיזוק של המבנים הפנימיים של התוכנה מעת לעת וערכת בדיקות מקיפה. ללא האחרונים, שימוש עקבי במתודולוגיה זו יגרום בהכרח לשחיקה מעריכית באיכות הפנימית של התוכנה, עד לנקודה שבה עלות הוספת פונקציונליות חדשה תהיה שווה או גדולה לעלות בניית התוכנה כולה מחדש, שלאחריה אין הצדקה כלכלית להמשיך לתחזק את התוכנה.

### מפל־המים

 ערך מורחב – **מודל מפל-המים**  

מפל-המים היא מתודולוגיה ותיקה ורווחת לפיתוח מערכות תוכנה. המתודולוגיה מיוחסת בטעות לווינסטון רויס, שהציע את הגרסה המקורית של המתודולוגיה במאמר שפורסם בשנת 1970. עם השנים, נשתרשה פרשנות מוטעית למאמרו, והיא זו שמכונה כיום "מודל מפל-המים". בהקשרה ההיסטורי, המתודולוגיה נתפסה כתגובה לשיטות אד הוק של "תַכנת-ותַקן", שרווחו מאוד בשנות השישים של המאה ה-20 (ועדיין רווחות). במודל מפל-המים, פיתוח התוכנה מתבצע בתהליך שיטתי ולוגי, המורכב משלבים מוגדרים היטב, שאין לפסוח עליהם. השלבים מבוצעים באופן קווי, אחד אחרי השני, ובכל שלב יש מיקוד במשימה עיקרית אחת בלבד. יש דגש רב על איסוף וניתוח של הדרישות לפני תחילת הפיתוח, ואין חזרה לאחור בתהליך לאחר ששלב מסוים בו הסתיים. השלבים העיקריים בשיטה זו הם: איסוף וניתוח דרישות תוכנה, עיצוב תוכנה, מימוש (תכנות), בדיקות תוכנה, שילוב מערכות (אינטגרציה), התקנת תוכנה ותחזוקת תוכנה.

### מודל ה-V

מודל ה-V (אנ') שבו לכל שלב במהלך פיתוח התוכנה קיים שלב מקביל של בדיקות.

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

המודל מגדיר 4 רמות פיתוח כאשר לכל רמת פיתוח קיימת רמת בדיקות אשר מתאימה לה.

רמות הפיתוח ורמות הבדיקה בהתאמה הן:

* ניתוח הדרישות מצד הפיתוח אל מול בדיקות קבלה בצד הבדיקות.
* עיצוב המערכת מצד הפיתוח אל מול בדיקות המערכת בצד הבדיקות.
* עיצוב הארכיטקטורה מצד הפיתוח אל מול בדיקות האינטגרציה בצד הבדיקות.
* עיצוב היחידות הבודדות/ מודולים וקידוד מצד הפיתוח אל מול בדיקות היחידה בצד הבדיקות.

בפועל, יכולות להיות יותר מ-4 רמות פיתוח אל מול 4 רמות בדיקה והדבר תלוי בארגון ובמתודולוגיה ויכול להשתנות בין פרויקט לפרויקט, אולם, הנפוץ ביותר הוא הבחנה בין 4 רמות.

**יתרונות שימוש במודל מנקודת מבט של הבדיקות ושל הפרויקט בכלל:**

* תחילת תהליך הבדיקות בשלב מוקדם של הפרויקט- חסכון בכסף ובמשאבים לאורך זמן וכן תכנון זמן נכון.
* מבנה נכון של בדיקות וכיסוי רב- כך שלכל שלב בפיתוח יש שלב מקביל בבדיקות. להשיג כיסוי בדיקות מקסימלי הוא רב.

מתודולוגיות איטרטיביות
----------------------

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

### Unified Process

 ערך מורחב – **Unified Process**  

Unified Process (או בקיצור "UP") היא מתודולוגיה, ששורשיה בעבודתו של בארי בם, והורחבה על ידי פיליפ קרוצ'טן, גריידי בוץ', ואחרים. המתודולוגיה הוצגה לראשונה בין השנים 1995–1998. UP אינה מתודולוגיה במובנה הקלאסי, אלא מסגרת מתודולוגית, שניתן להרחיבה ויש להתאימה לארגון או פרויקט מסוים. UP היא מתודולוגיה איטרטיבית, המורה על פיתוח תוכנה בתהליך מחזורי רב-שלבי. המתודולוגיה שמה דגש על ניהול הפרויקט, ניהול השינויים, הארכיטקטורה ותהליכי המידול של התוכנה. ייחודה של UP הוא בדרכים המובְנות בה, המאפשרות להתאימה לסוגים וגדלים רבים של פרויקטים לפיתוח תוכנה, החל מפרויקטים קטנים ולא-קריטיים ועד לפרויקטי-ענק לפיתוח מערכות קריטיות תומכות-חיים. הטכניקות העיקריות של המתודולוגיה כוללות פיתוח מחזורי תָחוּם-בזמן, ניהול השינויים באמצעות כלי ניהול שינויים ובקרת תצורה, ניהול הדרישות ומידול ויזואלי באמצעות UML.

מתודולוגיות זריזות
------------------

 ערך מורחב – **פיתוח תוכנה זריז**  

מתודולוגיה זריזה (באנגלית: Agile) לפיתוח תוכנה היא מתודולוגיה איטרטיבית, שהותאמה לפיתוח תוכנה בצוותים קטנים, תוך שימת דגש על יעילות, זריזות ואיכות. משפחה זו מקבלת בברכה שינויים במפרטי התוכנה, ומתייחסת לפיתוח כאל משחק של שיתוף פעולה מוּכְוון-מטרה (בדומה לטיפוס הרים). המתודולוגיות במשפחה זו שמות דגש רב על סביבת עבודה מתאימה, זרימת מידע אוסמוטית בין חברי הצוות, ותקורה פורמלית־טקסית נמוכה. עקרונות היסוד של משפחה זו נקבעו במשותף על ידי רבים מהמובילים בחקר וביישום מערכות תוכנה, ופורסמו ברבים במנשר לפיתוח תוכנה זריז.

### Extreme Programming

 ערך מורחב – **Extreme Programming**  

eXtreme Programming (או בקיצור "XP") היא מתודולוגיה, שפותחה על ידי קנט בק, ומתוארת בספרו eXtreme Programming Explained, שיצא לאור בשנת 2000, ובספרים נוספים שצצו בעקבותיו. שמהּ ניתן לה בשל העובדה, שהשיטות המשמשות אותה הן מחמירות מאוד, ובעת פרסומה, נחשבו כקיצוניות יחסית לשיטות שהיו קיימות בתעשייה. המתודולוגיה, כפי שרומז שמהּ, מפרטת שורה של טכניקות בתחום התכנות, ופחות בתחומים אחרים של הנדסת תוכנה. מערכות המפותחות לפיה הן גמישות מאוד לשינויים, וניתן להרחיבן בקלות ובאופן בטוח. כדי להשיג גמישות זו, XP משתמשת בשיטת פיתוח מונחה-בדיקות, שעיקריה הם כתיבת דרישות המערכת כסט של בדיקות הניתנות להרצה, ופיתוח הבדיקות קודם לפיתוח הפונקציונליות. שיטה זו דורשת הבנה טובה של עקרונות תכנות מונחה-עצמים ומשמעת עצמית גבוהה.

### Crystal Clear

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

### Scrum

 ערך מורחב – **Scrum**  

Scrum היא מתודולוגיה זריזה לניהול פרויקטים לפיתוח תוכנה, שפותחה על ידי קן שוואבר ואחרים. המונח "Scrum" מקורו במשחק הרוגבי, שם הוא מתאר את הדרך שבה המשחק מתחיל מחדש, לאחר שהכדור יצא מהמגרש. הטכניקה של "התחלה מחדש" היא אחת מאבני היסוד של השיטה – פרויקט Scrum מתחיל את תהליך הפיתוח כל חודש מחדש. כלומר, פעם בחודש מסופקת תוכנה עובדת למשתמשים, והערותיהם, כמו גם הדרישות החדשות, מיושמות במחזורי הפיתוח העוקבים. כיום מקובל להשתמש ב־Scrum כמעטפת לניהול פרויקטים המפותחים במתודולוגיית XP ומתודולוגיות זריזות אחרות.

השוואה בין המשפחות
------------------

| נושא | מתודולוגיות קוויות | מתודולוגיות איטרטיביות | מתודולוגיות זריזות |
| --- | --- | --- | --- |
| תגובה לשינויים | גרועה | בינונית | טובה מאוד |
| משמעת נדרשת | נמוכה | בינונית | גבוהה מאוד |
| רמה מקצועית נדרשת | נמוכה | נמוכה עד בינונית | בינונית עד גבוהה |
| דגש על מסמכים (תיעוד) | כן | חלקי | לא |
| דגש על קוד עובד | לא | חלקי | כן |
| דגש על בדיקות אוטומטיות | לא | לא | כן |
| דגש על פיתוח מקצה-לקצה | לא | חלקי | כן |
| גודל צוות | אין מגבלה תאורטית | עד מאות | עד 14, ניתן להגדיל בשילוב עקרונות נוספים |
| קלות הטמעה | קל מאוד | בינוני עד קשה | קשה עד קשה מאד |
| מידת השימוש בתעשייה | רבה מאוד | נמוכה עד בינונית | מועטה |
| ותק | משנות ה-70 | משנות ה-90 | מתחילת המאה ה-21 |

ראו גם
------

* סקלת קוברן
* ניהול מחזור חיי יישום

לקריאה נוספת
------------

* Kruchten, Philip, Kroll Per (2003). The Rational Unified Process Made Easy, Addison-Wesley, מסת"ב 0321166094
* Larman, Craig (2003). Agile and Iterative Development: A Manager's Guide, Addison-Wesley, מסת"ב 0131111558

קישורים חיצוניים
----------------

ויקישיתוף מדיה וקבצים בנושא **מתודולוגיית פיתוח תוכנה** בוויקישיתוף

| תחומים במדעי המחשב |
| --- |
| יסודות מתמטים | לוגיקה מתמטית • תורת הקבוצות • תורת המספרים • תורת הגרפים • תורת הטיפוסים • תורת הקטגוריות • אנליזה נומרית • תורת האינפורמציה |
| תורת החישוביות | תורת האוטומטים • תורת הרקורסיה • תורת הסיבוכיות • מחשוב קוונטי |
| אלגוריתמים ומבנה נתונים | אנליזה של אלגוריתמים • גאומטריה חישובית |
| שפות תכנות ומהדרים | מפרש • פרדיגמת תכנות (תכנות פרוצדורלי • תכנות מונחה עצמים • תכנות פונקציונלי • תכנות לוגי) |
| חישוב מבוזר ועיבוד מקבילי | עיבוד מקבילי • מחשוב סריגי • בקרת מקביליות |
| הנדסת תוכנה | ניתוח מערכות מידע • עיצוב תוכנה • תכנות מחשבים • שיטות פורמליות • בדיקות תוכנה • מתודולוגיית פיתוח תוכנה |
| תקשורת | ניתוב • טופולוגיית רשת • קריפטוגרפיה |
| מסד נתונים | מסד נתונים יחסי • SQL • תנועה • אינדקסים • כריית מידע • CAP theorem |
| בינה מלאכותית | חשיבה אוטומטית • בלשנות חישובית • ראייה ממוחשבת • עיבוד שפה טבעית • בינה חישובית • מערכת מומחה • למידה חישובית • רובוטיקה |
| גרפיקה | הדמיה ממוחשבת • הנפשה ממוחשבת • עיבוד תמונה |
| שפות פורמליות | שפה רגולרית • שפה חסרת הקשר • שפה תלוית הקשר • ההיררכיה של חומסקי |
| שימושים במדע | ביואינפורמטיקה • מדעים קוגניטיביים • כימיה חישובית • פיזיקה חישובית • אנליזה נומרית |