האוניברסיטה הפתוחה עבודה סמינריונית בנושא הערכות זמנים בפרויקטי תוכנה באמצעות לוגיקה עמומה (FUZZY LOGIC( סמינר בהנדסת תוכנה מספר הקורס: מדריך: ד

האוניברסיטה הפתוחה עבודה סמינריונית בנושא הערכות זמנים בפרויקטי תוכנה באמצעות לוגיקה עמומה (FUZZY LOGIC( סמינר בהנדסת תוכנה מספר הקורס: 20368 מדריך: ד"ר דן אהרוני מגישת העבודה: יעל הראל מס' סטודנט: 036373587 מאי 200

תקציר עבודה זו עוסקת בהערכת עלויות של פרויקטי תוכנה. עלות של פרויקט תוכנה מורכבת ממספר גורמים, כאשר למשך ההשקעה של אנשי הפיתוח )שמתורגמת לשכר( יש משקל משמעותי בהרכב העלות. ההשקעה מושפעת ממספר רב של גורמים שאינם ניתנים למדידה מדויקת, במיוחד בשלבים המוקדמים של הפרויקט )כגון רמתם המקצועית של אנשי הפיתוח והמנהלים, גודל בסיסי הנתונים, מורכבות האלגוריתמים ועוד( ולכן קיימת לגביה אי וודאות גבוהה. בשנות ה- 80 פותח מודל model) COCOMO (constructive cost שהינו מודל אלגוריתמי להערכת עלות של פרויקטי תוכנה. הבעיה במודל זה היא שהוא מסתמך על קבלת החלטות חד משמעיות בשלב מוקדם מאוד של הפרויקט, כאשר בפועל מרבית המידע אינו וודאי ולא ניתן לקבל תמונה מדויקת של הפרמטרים השונים. בשנות ה- 90 פותח תחום הלוגיקה העמומה במתמטיקה. הרעיון העומד מאחורי לוגיקה זו, הוא שקיימת אמת חלקית. אם בלוגיקה הקלאסית לכל נתון יכול להיות ערך אמת או שקר, בלוגיקה העמומה יכול להתקבל הערך "כמעט אמת". הלוגיקה העמומה יכולה לתת מענה לבעיה המרכזית בהערכת עלויות פרויקטים - אי הוודאות. לוגיקה זו מאפשרת למנהל הפרויקט להגדיר את ערכי המשתנים השונים באמצעי השפה המוכרים לו. למשל, את רמת התוכניתנים הוא יוכל להגדיר כ"נמוכה", "בינונית" או "גבוהה" ואם הוא לא בטוח מהי הרמה המתאימה, הוא יוכל להגדיר אותה גם כ- "בין בינונית לגבוהה". המודלים השונים להערכת עלות פרויקטים באמצעות לוגיקה עמומה נבדלים במספר היבטים הפרמטרים שמיוצגים בלוגיקה עמומה )גודל הפרויקט, מאפייני הארגון, מאפייני הפרויקט או שילוב של כמה פרמטרים(, שיטת ייצוג המספרים בלוגיקה עמומה )ייצוג משולש, טרפזי או אחר( והמודל הבסיסי עליו מבוסס המודל )כגון intermediate COCOMO,COCOMO וכו'(. בעבודה מוצגים באופן מפורט שני מודלים שונים לייצוג גודל הפרויקט באמצעות לוגיקה עמומה ומספרים עמומים )מספר שמיוצג בלוגיקה עמומה ולא קלאסית(. המודל הראשון מבוסס על מספרים עמומים משולשים והשני מבוסס על מספרים עמומים טרפזיים, שבהם קיים מימד נוסף לייצוג אי הוודאות. ממצאי המחקרים השונים הוכיחו כי בהשוואה למודלים הקלאסיים, שימוש בלוגיקה עמומה משפר את הערכות הזמנים של פרויקטי תוכנה. מסתמן כי עתיד המחקר בתחום זה הוא שילוב של הלוגיקה העמומה עם רשתות נוירונים, דבר שיביא לשיפור גדול אף יותר בתחזיות המודלים. 2 מתוך 39

תוכן עניינים 7 8 מבוא הערכת עלות בפרויקטי תוכנה מאמר,][ ממאמר,]2[ Somerville ]4[ 8 ]4[ 8 Somerville הערכת העלות הערכת ההשקעה מאמר Somerville,]2[ ]4[ 0 הערכת עלות מבוססת אלגוריתמים ]4[ Sommerville 0 מודל COCOMO מאמר ]2[ קריטריונים למדידת ביצועים של מודל הערכת איכות 2 3 לוגיקה עמומה logic( )fuzzy מאמר] [ מהי לוגיקה עמומה? 3 מאמר ]2[ מספר עמום number( )fuzzy 3 מאמר ]2[ 4 )fuzzy sets( function( )membership מאמר 5 ]2[ קבוצות עמומות פונקצית שייכות רמת עמימות של מספר עמום )fuzziness( מאמר ]2[ 7 8 8 20 25 כיצד לוגיקה עמומה יכולה לתרום להערכת זמני פיתוח מאמר ][ אורות ערפל מאמר ][ גישות שונות להערכה מבוססת לוגיקה עמומה הערכת גודל הפרויקט )size( באמצעות לוגיקה עמומה כללי 25 25 מאמר ]2[ הערכה באמצעות מספר עמום משולש ( function )triangular membership כללי 25 עמעום גודל הפרויקט )fuzzification( 25 חישוב העלות 26 ממצאים 27 הערכה באמצעות מספר עמום טרפזי ( function )trapezoidal membership 29 כללי 29 עמעום גודל הפרויקט )fuzzification( 30 חישוב העלות 30 ממצאים 3 32 36 37 מאמר ]3[ דיון מאמר ]3[ סיכום 2.. 2.2. 2.2.. 2.3. 2.4. 3.. 3.2. 3.3. 3.4. 3.5. 4.4. 4.5. 4.5.. 4.5.2. 4.5.3. 4.5.4. 4.6. 4.6.. 4.6.2. 4.6.3. 4.6.4.. 2. 3. 4. 4.. 4.2. 4.3. 5. 6. הערות לגבי המאמרים רשימת ביבליוגרפיה 39 3 מתוך 39

טבלת מינוחים וקיצורים )lines of code( מספר שורות קוד LOC )source lines of code( מספר שורות קוד SLOC )equivalent lines of code) מספר שורות קוד שקול ELOC constructive cost model COCOMO מרכיבי M במודל COCOMO II Early Design פרמטר SCED FCIL PREX PDIF RUSE RCPX PERS תיאור מרכיבי M במודל הביניים: לוחות זמנים )schedule( שירותי תמיכה facilities( )support ניסיון הצוות experience) (personnel מגוון הפלטפורמות השונות differential( )platform שימוש חוזר בקוד required( )reuse אמינות ומורכבות המוצר product( )reliability complexity יכולות אנשי הצוות capability( )personnel..2.3.4.5.6 פרמטר RELY DATA CPLX TIME STOR VIRT TURN VEXP ACAP AEXP PCAP LEXP MODP TOOL SCED תיאור אמינות נדרשת reliability( (required system גודל בסיס הנתונים מורכבות המוצר מגבלות זמן ריצה מגבלות אחסון אספקת חשמל לזיכרון וירטואלי )האם נדרשת אספקה רציפה( זמן שחזור נדרש ניסיון עם המכונה הוירטואלית experience) (virtual machine יכולת מנתח המערכת capability) (analysis engineer ניסיון עם האפליקציה experience) (application יכולת אנשי הפיתוח capability) (programmers ניסיון עם שפת הפיתוח experience) (language שיטות פיתוח מודרניות programming) (modern שימוש בכלי פיתוח לו""ז נדרש לפרויקט 4 מתוך 39

)magnitude of relative error( גובה שגיאה יחסית אבסולטית MRE )mean relative error( שגיאה יחסית ממוצעת MARE )prediction( אחוז פרויקטים שאחוז השגיאה שלהם נמוך מ- n PRED(n) (triangular fuzzy number) מספר עמום משולש TFN )trapezoidal fuzzy number( מספר עמום טרפזי TPFN TAMF פונקצית שייכות משולשת TPMF פונקצית שייכות טרפזית.7.8.9.0..2.3 5 מתוך 39

טבלת איורים איור מספר עמום משולש מייצג את המספר "בערך 4"... 3 איור 2 מספר עמום טרפזי מייצג את הערך "בין 4 ל- 9 "... 3 איור 3 מספר עמום משולב מייצג את המספר "בערך 4" וגם "בין 4 ל 9"... 3 איור 4 ייצוג משימה פשוטה בלוגיקה רגילה )לקוח מאתר אינטרנט ]6[(... 4 איור 5 ייצוג הקבוצה "משימה פשוטה" בלוגיקה עמומה )לקוח מאתר אינטרנט ]6[(... 4 איור 6 פונקצית שייכות משולשת... 5 איור 7 פונקצית שייכות טרפזית... 6 איור 8 תרשים "קונוס אי הוודאות" )לקוח מאתר אינטרנט ]5[(... 8 איור 9 ייצוג פרויקט שעלותו גבוהה בלוגיקה קלאסית... 9 איור 0 ייצוג פרויקט שעלותו גבוהה בלוגיקה עמומה... 9 איור השוואת מודל המספרים העמומים המשולשים למודלים הקלאסיים... 28 איור 2 מידול משולש של גדלי פרויקט... 29 איור 3 מידול טרפזי של גודל הפרויקט... 29 איור 4 פונקציות השייכות הטרפזיות של גודל הפרויקט... 30 איור 5 השוואת מודל המספרים העמומים הטרפזיים למודלים מקבילים... 3 טבלת נוסחאות נוסחה נוסחה בסיסית לחישוב השקעה...0 נוסחה 2 חישוב עלות במודל... COCOMO II נוסחה 3 שגיאה יחסית אבסולוטית...2 נוסחה 4 אחוז שגיאה יחסית אבסולוטית... 2 נוסחה 5 שגיאה יחסית ממוצעת... 2 נוסחה 6 אחוז שגיאה יחסית אבסולוטית ממוצעת...2 נוסחה 7 פונקצית שייכות משולשת...5 נוסחה 8 פונקצית שייכות טרפזית...6 נוסחה 9 רמת עמימות...7 נוסחה 0 רמת עמימות במודל המשולש...7 נוסחה רמת עמימות במודל טרפזי...7 נוסחה 2 חישוב נפח בסיס הנתונים היחסי... 2 נוסחה 3 הגדרת 22... M נוסחה 4 גודל פרויקט עמום טרפזי...22 נוסחה 5 הגדרת גודל הפרויקט במודל משולש... 25 נוסחה 6 חישוב הגבולות במודל המשולש...25 נוסחה 7 פונקצית השייכות להשקעה במודל המשולש...26 נוסחה 8 חישוב ההשקעה הממוצעת במודל המשולש...26 נוסחה 9 פונקצית השייכות של גודל הפרויקט במודל הטרפזי...30 6 מתוך 39

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

2. הערכת עלות בפרויקטי תוכנה הערכת העלות מאמר,][ מאמר,]2[ Somerville ]4[..2 כפי שניתן ללמוד ממאמר ][ וממאמר ]2[, כיום התוכנה היא המרכיב היקר ביותר בפרויקטים של מערכות ממוחשבות. נתח העלות הגבוה ביותר הוא שעות העבודה של אנשי הפרויקט. הערכה מדויקת של עלות הפרויקט חשובה הן ללקוח והן למפתחים. ההערכות יכולות לשמש לטובת כתיבת בקשות לקבלת הצעות למימוש ( proposal RFP (request for ומענה להן, לטובת שיפור עמדות במשא ומתן בשלב יצירת החוזה, הגדרת לוחות הזמנים וכן לטובת בקרה ופיקוח על תהליך הפיתוח. הערכה נמוכה מדי עלולה להוביל לאישור של פרויקטים שחורגים מהתקציב שלהם, שלא מממשים את כל הדרישות, שמספקים מוצר באיכות ירודה, וכמובן, לפרויקטים שאינם עומדים בלוחות הזמנים. הערכת זמנים מדויקת תורמת גם לתעדוף נכון של משימות הארגון ומאפשרת למנהלים להקצות את המשאבים באופן יעיל. כפי שמוצע בספרו של ]4[, Sommerville עלות הפרויקט מורכבת משלושה פרמטרים מרכזיים: עלות החומרה והתוכנה בהם עושים שימוש )מחשבים, רכיבי תקשורת, רישיונות פיתוח, רישיונות ריצה וכו'(, עלות התפעול: נסיעות, הכשרות, הוצאות חשמל, אנשי מנהלה והנהלה, אנשי תחזוקה, תקשורת, פנסיה וכדומה ועלות ההשקעה cost( )effort שכוללת בין היתר את שכר המהנדסים. במרבית הפרויקטים הערכת ההשקעה estimation) (effort הינה המרכיב המשמעותי ביותר בהערכת עלות הפרויקט. לכן, על מנת להעריך באופן מדויק את עלות הפרויקט, נדרש לאמוד את ההשקעה הנדרשת להשלמת כל משימה )זמן "נטו"(, וכן את משך הזמן הדרוש לביצועה )זמן "ברוטו"(. עבודה זו תתמקד בהערכת ההשקעה ומשך הזמן הדרושים להשלמת המשימות. ]4[ הערכת ההשקעה Somerville.2.2 זמן הפיתוח של פרויקט תוכנה מושפע מגורמים רבים, שלגבי חלקם הגדול קיימת אי וודאות רבה בשלב בו נדרש לבצע את ההערכה: הטכנולוגיות בהן נדרש לעשות שימוש )חומרה ותוכנה( במקרים רבים אינן מוכרות, כישורי האנשים שמעורבים בפרויקט )לרוחבו( אינם ניתנים למדידה מדויקת ולעיתים אף לא ידועים מראש, הדרישות בדרך כלל אינן מפורטות ומדויקות והשינויים שצפויים במשך הזמן גם הם אינם קלים לחיזוי. יחד עם זאת, לאור חשיבות דיוק הערכת הזמנים, מנהלי פרויקטים נדרשים להעריך את עלות הפיתוח בשלב מוקדם של הפרויקט ולטובת זאת פותחו מספר שיטות אומדנה. מרבית המודלים להערכת עלויות פרויקטים מנסים לייצר הערכה של ההשקעה הנדרשת בפיתוח ( effort )estimate שלאחר מכן מתורגמת לעלות הפרויקט וללו"ז. למרות שההשקעה והעלות קשורים זה בזה, הם בד"כ אינם קשורים באמצעות פונקצית המרה פשוטה אלא באמצעות פונקציה שמושפעת ממורכבות הפרויקט ואיכות המשאבים. ההשקעה נמדדת לעיתים קרובות בחודשי אדם של תוכניתנים, מנתחי מערכת ומנהלי פרויקט. מרבית המודלים להערכת העלות מתמקדים בהערכת העלות הנדרשת בחודשי אדם. ניתן להמיר את ההערכה של השקעה זו לעלות כספית באמצעות חישוב השכר הממוצע ליחידת זמן של כוח האדם בפרויקט והכפלתו בהערכת ההשקעה שהתקבלה. 8 מתוך 39

להלן תיאור של מספר מודלים מרכזיים לאומדן ההשקעה הנדרשת לפיתוח פרויקט תוכנה : א. ב. ג. ד. ה. מידול עלות אלגוריתמי modeling( )algorithmic cost פיתוח מודל שמבוסס על היסטוריה של עלויות פרויקטים ביחס לפרמטר מסוים )בד"כ גודל הפרויקט, אותו ניתן למדוד במספר דרכים, כגון מספר שורות קוד או מספר פונקציות (, הערכת אותו פרמטר לפרויקט שמעוניינים לפתח )למשל הערכת גודל הפרויקט במספר שורות קוד( והפעלת המודל לקבלת ההערכה. שיפוט מומחים היוועצות במספר מומחים בתחום הפרויקט, הטכנולוגיות והייעוד שלו ושקלול ההערכות להערכת עלות אחת. הערכה עפ"י אנאלוגיה כאשר יש פרויקטים באותו תחום שהושלמו, מבצעים הערכת עלות באמצעות אנאלוגיה לפרויקטים דומים. חוק פרקינסון עפ"י התיאוריה של פרקינסון, העבודה נערמת כך שתמלא את הזמן שמוקצה לה. השיטה שמבוססת על חוק זה מגדירה את העלות עפ"י המשאבים הקיימים ולא עפ"י הערכה אובייקטיבית )כלומר אם נדרש להשלים את הפרויקט ב- 2 חודשים ומוקצים לו 5 אנשים, העלות תוערך ב- 60 ח"א(. תמחור עלות הפרויקט מוגדרת בהתאם ליכולת הלקוח לשלם על הפרויקט. למודלים האלגוריתמיים )הכמותיים( יש מספר יתרונות. ראשית, קל יחסית לפתח אותם ולאחר מכן לממשם בתוכנה. החיסרון שלהם הוא שהם דורשים צורה מסוימת של פונקצית החיזוי, בד"כ נוסחה מתמטית. כמו כן, נדרש לכייל אותם מחדש עבור כל פרויקט. ולבסוף, ההתנהגות שלהם אינה תואמת את אופן החשיבה האנושי. לעומת זאת, המודלים הלא-אלגוריתמיים )האיכותיים( מספקים מידול של הקשר המורכב בין הפרמטרים הרבים שמשפיעים על העלות וקל יחסית להבין את התנהגותם משום שהם מבוססים על השפה הטבעית, אולם הפיתוח שלהם מורכב ויישומם באמצעות תוכנה דורש חישובים מאוד מורכבים להערכת העלות. השיטה המיושמת ביותר בפועל היא שיפוט מומחים. חלק ניכר ממנהלי הפרויקטים מסתמכים על ניסיונם האישי, על ניסיונם של אחרים או על נורמות הארגון להערכת ההשקעה הנדרשת. אולם, יש מספר בעיות בגישה זו. קודם כל, האמצעי להשגת ההערכה אינו מפורש ולכן לא ניתן לחזור על שיטה זו. כלומר, אם מנהל פרויקט הצליח להשתמש בשיטה זו והעריך באופן מדויק את ההשקעה הפרויקט, לא ניתן לעשות שימוש ביישום זה בשיטתיות בפרויקטים אחרים, משום שהאופן בו הגיע להערכה אינו ניתן למדידה מדויקת. כמו כן, קשה למצוא אנשים מנוסים מאוד בהערכת זמנים לכל פרויקט חדש. לבסוף, היחס בין גודל הפרויקט לעלות אינו ליניארי ולכן לא מספיק להעריך את גודל הפרויקט אלא נדרש להעריך את עלותו בהתבסס על גודלו. לאור זאת, המודלים הכמותיים תפסו תאוצה בעשורים האחרונים וכל הזמן נעשים ניסיונות לשפר את דיוקם. 9 מתוך 39

מאמר Somerville,]2[ ]4[.2.2. הערכת עלות מבוססת אלגוריתמים שיטה זו modeling( )algorithmic cost עושה שימוש בנוסחאות מתמטיות לחיזוי עלות הפרויקט בהתבסס על גודלו, מספר מהנדסי התוכנה המוקצים לו ומשתנים נוספים שקשורים לתהליך או למוצר עצמו. אלגוריתמים אלו משמשים בעיקר לאומדנה של עלות פיתוח תוכנה אולם יכולים לשמש למטרות נוספות, כגון בחינת חלופות. התבנית הכללית ביותר של הנוסחה מתוארת להלן: Effort נוסחה נוסחה בסיסית לחישוב השקעה A Size B M A קבוע שתלוי בארגון ובסוג התוכנה המפותחת. SIZE גודל הפרויקט )הערכת מספר שורות קוד או הערכת כמות פונקציות או אובייקטים(. עבודה זו מתמקדת במודלים מבוססי הערכת גודל הפרויקט בשורות קוד code( )LOC-lines of בלבד. B משקף את הקשר המעריכי בין גודל התוכנה לעלותה )ההנחה היא שבמקרים רבים ככל שהיקף התוכנה גדול יותר זמן הפיתוח גדל באופן מעריכי ולא ליניארי( ונע בד"כ בין ל-.5. M שילוב מאפייני התהליך, המוצר והפיתוח, כגון מורכבות הממשקים וכישורי המהנדסים. ]4[ Sommerville.3.2 מודל COCOMO קיים מספר מודלים אלגוריתמיים להערכת עלות פרויקטי תוכנה. המודל הנפוץ ביותר הוא COCOMO modeling).(constructive cost מודל זה מציע נוסחה שמקשרת בין גודל הפרויקט ונתונים נוספים לגביו )כפי שיתואר בהמשך( לבין אומדן העלות. הנוסחה פותחה בהתבסס על נתונים שנאספו ממספר רב של פרויקטים שמהם נבנה הקשר בין הפרמטרים השונים. המודל הבסיסי של )982( COCOMO מחלק את הפרויקטים לשלוש קטגוריות על פי מורכבות הפרויקט, כאשר ערך הפרמטרים A,B )ראה סעיף 2.2.( מוגדר בהתאם :. A=2.4. פרויקט פשוט דרישות ברורות, צוותי פיתוח קטנים.05=B פרויקט בינוני דרישות מורכבות יותר, צוותים פחות מנוסים בתחום הנדרש.2=B 3.0=A. פרויקט משובץ תוכנה )embedded(.a=3.4 B=.20 -.2.3 0 מתוך 39

המודל המורחב של COCOMO לוקח בחשבון התפתחויות שחלו בעולם התוכנה כגון שימוש באב- טיפוס, שימוש חוזר בקוד, מערכות מידע מבוססות בסיסי נתונים וכו'. מודל זה ( II )COCOMO מחולק לחמש קטגוריות על פי סוג המידע שקיים בשלב הערכת העלות. נוסחה ייחודית הוגדרה עבור כל קטגוריה. חלק מהקטגוריות מבוסס על הערכת כמות הפונקציות assessment( )function point שאינה רלוונטית לעבודה זו ולפיכך לא אתייחס אליה. הקטגוריות הבאות מבוססות על מספר שורות קוד :)LOC( א. ב. ג. ד. ה. ו. ז. תיכון ראשוני model( )early design מיועד להערכת עלות שמבוצעת לאחר השלמת שלב הגדרת הדרישות. במודל זה A נקבע על סמך נתוני פרויקטים שונים ל 2.94. חישוב הערך של M מבוסס על שבעה מאפיינים של הפרויקט שלכל אחד מהם מוגדרת מידת סיבוכיות. הנוסחה המתקבלת היא: Effort 2. 94 Size B PERS RCPX RUSE PDIF PREX FCIL SCED )personnel capability( יכולות אנשי הצוות PERS )reliability complexity product( אמינות ומורכבות המוצר RCPX )reuse required( שימוש חוזר בקוד RUSE )platform differential( מגוון הפלטפורמות השונות PDIF (personnel experience) ניסיון הצוות PREX )support facilities( שירותי תמיכה FCIL )schedule( לוחות זמנים SCED נוסחה 2 חישוב עלות במודל II שימוש חוזר בקוד model( :)the reuse מודל זה כולל נוסחאות לחישוב ההשקעה הדרושה לפיתוח מבוסס קוד אוטומטי ולפיתוח מבוסס קוד קיים שנדרש לשנות ולשלב במערכת )המודל מחשב ערך גודל שקול, (equivalent lines of code)eloc, שמייצג את מספר שורות הקוד החדשות השקול למספר שורות הקוד הקיימות שנדרש לשנות( לייצר או לשלב בפרויקט.)LOC(. שתי הנוסחאות דורשות הערכה של מספר שורות הקוד שנדרש מודל תיכון מפורט model( )the post-architecture המודל המפורט ביותר שמשמש להערכת העלות בשלב בו תכן העל כבר מוגדר. המודל מתבסס על הנוסחה הכללית, כאשר הפרמטרים שלה מחושבים כדלקמן:..2.3 א. ב. ג. ד. 2.94 :A B: הערך של B מחושב עפ"י חמישה גורמים )ניסיון הארגון בתחום הפרויקט, גמישות המימוש, רמת ניתוח הסיכונים שבוצע, מידת ליכוד הצוות ובשלות התהליך(. :SIZE סכום של מספר שורות הקוד החדשות המתוכננות,LOC מספר שורות הקוד האוטומטי/הקיים ELOC )ראה סעיף א לעיל( ומספר שורות הקוד שנדרש לשנות בעקבות שינויים בדרישות. M: מחושב בדומה למודל התכן הראשוני, פרט לכך שבמודל זה עושים שימוש בשבעה עשר פרמטרים ולא רק בשבעה. קיים בנוסף מודל ביניים של )Intermediate COCOMO( COCOMO. המודל פועל בדומה למודל המפורט אולם הוא מתבסס על 5 פרמטרים ל- M שמחולקים לארבע קטגוריות שונות. מתוך 39

קריטריונים למדידת ביצועים של מודל הערכת איכות מאמר ]2[.4.2 על מנת לבחון את הביצועים של מודל הערכת איכות, נדרש להגדיר מדדים אובייקטיבים שיבחנו את טיב המודל. להלן הקריטריונים בהם עושים שימוש במאמרים עליהם מתבססת עבודה זו: א. שגיאה יחסית אבסולוטית: R E Actualeffort Estimated Actual effort effort ב. )נוסחה 3 שגיאה יחסית אבסולוטית( מדד המגדיר את השגיאה היחסית )יחס בין ההשקעה בפועל להשקעה שנצפתה( של פרויקט באופן אבסולוטי, כלומר, לא ביחס לפרויקטים אחרים. אחוז שגיאה יחסית אבסולוטית MRE(magnitude of relative error) Actualeffort Estimated Actual effort effort 00 ג. MRE )נוסחה 4 שיעור שגיאה יחסית אבסולוטית( שגיאה יחסית אבסולוטית ממוצעת error) MARE (mean relative R E עבור x פרויקטים. MARE Actual Estimated Actual effort x x effort effort )נוסחה 5 שגיאה יחסית ממוצעת( הממוצע של MARE% MARE*00 ד. אחוז שגיאה יחסית אבסולוטית ממוצעת )נוסחה 6 אחוז שגיאה יחסית אבסולוטית ממוצעת( ניבוי ה. pred(n) אחוז הפרויקטים שיש להם שגיאה יחסית אבסולוטית MRE מתחת ל n. כלומר אחוז הפרויקטים עבורם MRE n 2 מתוך 39

.3 לוגיקה עמומה logic( )fuzzy מהי מאמר ][.3. לוגיקה עמומה? לוגיקה עמומה היא הרחבה של הלוגיקה הבוליאנית הקלאסית לטיפול בערכים אמיתיים-חלקית. זוהי טכניקה מתמטית שמתמודדת עם מידע לא מדויק או מידע שיש לו יותר מפתרון אפשרי יחיד. מערכות מבוססות לוגיקה עמומה מנסות לחקות את התהליך הקוגניטיב י, שבו החוקים אינם ברורים ומדויקים. הלוגיקה העמומה מדמה את אופן החשיבה האנושי ולכן היא מתבססת על חוקי-שפה שמתורגמים לנוסחאות מתמטיות. התשובה שתתקבל במערכת לשאלת אמת/שקר מסוימת עשויה לקבל ערך אמת או ערך אמת חלקי, למשל "אולי אמת". מספר עמום number( )fuzzy מאמר ]2[.2.3 מספר עמום הוא הרחבה של מספר רגיל במובן שהוא אינו מייצג ערך בודד, אלא טווח של ערכים שלכל אחד מהם ניתן משקל בין 0 ל. המשקל נקרא "פונקצית שייכות" function(.(membership קיים מספר סוגים של מספרים עמומים; השניים בהם עוסקת עבודה זו הם מספר עמום משולש ( fuzzy TFN triangular :)TPFM- trapezoidal fuzzy number( ומספר עמום טרפזי )number מספר עמום משולש מייצג את המספר "בערך 4" איור 2 מספר עמום טרפזי מייצג את הערך "בין 4 ל- 9 " איור מספר שהוא "בערך 4" וגם "בין 4 ל 8" מיוצג בלוגיקה עמומה באופן הבא: איור 3 מספר עמום משולב מייצג את המספר "בערך 4" וגם "בין 4 ל 9" 3 מתוך 39

ל, מאמר ]2[.3.3 קבוצות עמומות sets( )fuzzy עבור קבוצה קלאסית S כל איבר בקבוצה האוניברסאלית U מוגדר האם הוא נכלל ב S או לא. השייכות לקבוצה S מוגדרת כ 0 אם המספר לא שייך לקבוצה ובתור אם הוא כן שייך לה. בלוגיקה עמומה קבוצת אפשרויות השייכות {0,} מורחבת לקטע הסגור [0,]. כלומר, מספר יכול להיות "שייך חלקית" לקבוצה, כאשר מידת השייכות שלו תוגדר כערך בין 0 ל. קבוצה עמומה מוגדרת באופן הבא: )3( A {( x, A( x)) x X} כאשר X היא קבוצה אוניברסאלית כלשהיא )למשל קבוצת כל ההערכות השונות של מספר שורות קוד למשימות(, ו A(x) היא פונקציה שמבטאת את מידת השייכות של x ל A )כאשר A היא תת קבוצה של X, למשל קבוצת כל ההערכות שמייצגות משימה פשוטה(. לדוגמא, אם הקבוצה הקלאסית S מייצגת הערכות שונות של מספר שורות קוד של משימות פשוטות בפרויקט, אז כל הערכה שבוצעה יכולה להיכלל בקבוצה או לא להיכלל בקבוצה. ניקח לדוגמא את משימת קידוד הדרישה "הצג על המסך שעון עצר". נניח שהתוכניתן מעריך שמספר שורות הקוד הנדרש הוא 20. כמו כן, נניח שמספר שורות קוד למשימה פשוטה נע בין 0 200. בלוגיקה רגילה, המספר 20 אינו נכלל בקבוצה "משימה פשוטה", בעוד שבלוגיקה עמומה ניתן להגדיר שהמספר נמצא חלקית בקבוצה, כלומר המספר מייצג "משימה כמעט פשוטה". א. ייצוג הקבוצה "משימה פשוטה" הוא המלבן האדום ולכן 20 שורות קוד אינו נכלל בקבוצה: איור 4 ייצוג משימה פשוטה בלוגיקה רגילה )לקוח מאתר אינטרנט ]6[( ב. ייצוג הקבוצה "משימה פשוטה" בלוגיקה עמומה היא המשולש האדום ולכן 20 שורות קוד נכלל במידה חלקית בקבוצה: איור 5 ייצוג הקבוצה "משימה פשוטה" בלוגיקה עמומה )לקוח מאתר אינטרנט ]6[( 4 מתוך 39

מאמר ]2[.4.3 פונקצית שייכות function( )membership ( x X ) : X [0,] פונקצית השייכות ממפה את הערכים האפשריים השונים למידת השייכות שלהם : קיים מספר סוגים של פונקציות שייכות. ניתן לחלק אותם לשתי קטגוריות: פונקציות שייכות ליניאריות ופונקציות שייכות גאוסיות. המודלים המתוארים בעבודה זו מבוססים על שתי פונקציות השייכות הליניאריו ת הבאות: א. פונקצית שייכות משולשת (triangular fuzzy membership function( 0 ( x) ( x l) /( m l) ( r x) /( r m) if if if x l or x r x ( l, m) x ( m, r) x הוא המשתנה שעליו מפעילים את פונקצית השייכות )נוסחה 7 פונקצית שייכות משולשת( l מייצג את הגבול השמאלי של טווח הערכים בקבוצה )ערך ציר ה- x של הקודקוד השמאלי של המשולש( r מייצג את הגבול הימני של טווח הערכים בקבוצה )ערך ציר ה- x של הקודקוד הימני של המשולש( m מייצג את חציון טווח הערכים בקבוצה )ערך ציר ה- x של הקודקוד העליון של המשולש( דוגמא: עבור 0=l m=30 r=60 טבלת הערכים: המספר "הרגיל " )ערך הציר האופקי ) מידת השייכות שלו )הגובה במשולש ) מידת השייכות שלו )הגובה במשולש ) המספר "הרגיל " )ערך הציר האופקי ).000.000 0.833 30 35 0.000 0.000 0 5 0.500 0.667 0.500 0.333 40 45 50 0.000 0.250 0.500 0 5 20 0.000 0 5 0 5 20 25 30 35 40 45 50 55 60 0.67 0.000 55 60 0.750 25 איור 6 פונקצית שייכות משולשת 5 מתוך 39

)trapezoidal fuzzy membership function( 0 ( x l) /( s l) ( x) ( r x) /( r t) ב. פונקצית שייכות טרפזית )נוסחה 8 פונקצית שייכות טרפזית( if if if if x l or x r x ( l, s) x ( s, t) x ( t, r) x הוא המשתנה שעליו מפעילים את פונקצית השייכות l מייצג את הגבול השמאלי של טווח הערכים )ערך ציר ה- x של הקודקוד השמאלי-תחתון של הטרפז( r מייצג את הגבול הימני של טווח הערכים )ערך ציר ה- x של הקודקוד הימני-תחתון של הטרפז( s מייצג את הגבול השמאלי של הערכים שמשתייכים באופן מוחלט לקבוצה )ערך ציר ה- x של הקודקוד השמאלי-עליון של הטרפז( t מייצג את הגבול הימני של הערכים שמשתייכים באופן מוחלט לקבוצה )ערך ציר ה- x של הקודקוד הימני-עליון של הטרפז( דוגמא: עבור l=0 r=60 t=40 s=25 טבלת הערכים: המספר מידת "הרגיל " השייכות )ערך הציר שלו )הגובה האופקי ) בטרפז ) 0 0 0 5 0 0 0.333333 5 0.666667 20 25 30 35 40 0.75 45 0.5 50 0.25 55 0 60 0.5 0 0 5 0 5 20 25 30 35 40 45 50 55 60 איור 7 פונקצית שייכות טרפזית * במאמרים. l=a s=b t=c r=d הסימון שונה לטובת מניעת בלבול עם סימוני a,b של נוסחת.COCOMO 6 מתוך 39

מאמר ]2[ 5.3. רמת עמימות של מספר עמום )fuzziness( רמת העמימות, או מידת הערפול, מוגדרת כיחס בין גבולות פונקצית השייכות לבין ערך המודל )m(: )נוסחה 9 רמת עמימות( F 2 m כאשר היא הגבול השמאלי ו הגבול הימני. F )נוסחה 0 רמת עמימות במודל המשולש( במספר עמום משולש: r l ולכן L r 2 m במספר עמום טרפזי: F )נוסחה רמת עמימות במודל טרפזי( r t s l 2 m ( r l) ( t s) 2 m s l ולכן r t 7 מתוך 39

כיצד לוגיקה עמומה יכולה לתרום להערכת זמני פיתוח.4 מאמר ][.4. אורות ערפל בתחילת הפרויקט, ישנה תמונה מעורפלת בלבד של המוצר שנדרש לפתח. ככל שהפרויקט מתקדם, התמונה מתבהרת ונעשית ברורה יותר. מכיוון שהמידע על הפרויקט שעומדים לפתח הינו מעורפל בשלב בו נדרש להעריך את העלות, הערכת ההשקעה והלו"ז הנדרשים לפיתוח מעורפלת גם היא. רק כאשר המידע לגבי התוכנה המפותחת מתבהר, ההערכה יכולה להיות מדויקת יותר. התרשים הבא מתאר את חוסר הדיוק בהערכת ההשקעה הנדרשת בשלבים השונים בפרויקט. העקומה העליונה מתארת הערכות יתר )בכפולות אל מול ההערכה המקורית( והעקומה התחתונה מתארת את הערכות חסר: איור 8 תרשים "קונוס אי הוודאות" )לקוח מאתר אינטרנט ]5[( התרשים מרמז שלא רק שקשה להעריך את עלות הפרויקט באופן מדויק בשלבים המוקדמים שלו, אלא שזה בלתי אפשרי. ניתן לראות שרק לקראת סיום הפרויקט ההערכות מתכנסות ותואמות למציאות. לכן, כל המודלים הקלאסיים להערכת זמני פיתוח מתמודדים עם מכשול משמעותי המידע מעורפל ולא ברור בשלב בו נדרש לעשות בו שימוש. מרבית המודלים להערכת עלות הפרויקט פותחו במהלך שנות ה- 80, בעוד הלוגיקה העמומה פותחה בתחילת שנות ה- 90. לפיכך, מרבית המודלים עושים שימוש בלוגיקה "קלאסית". כלומר, הערכה של פרמטר מסוים יכולה להיות "נכונה" או "שקרית" בלבד. הנחה זו מגבילה מאוד את המודלים משום שהיא לא מתירה אי דיוקים בתהליך ההערכה והם אינם מותאמים למצבים בהם מרבית המשתנים שמשפיעים על העלות הם איכותיים ולא כמותיים. למשל, אחד הפרמטרים של מודל COCOMO שתואר במבוא, הוא רמת התוכניתנים. רמה זו יכולה להיות "טובה מאוד", "טובה" או "בינונית" אולם המודלים הקלאסיים מאפשרים לקבוע רמה אחת בלבד. לכן, אם לא ידוע האם רמת התוכניתן היא "טובה מאוד" או "טובה" )כי היא נמצאת על הגבול בין שתי הרמות(, יהיה קשה לייצג זאת במודל. ייצוג קלאסי זה של הערכים יוצר בעיה מהותית במודלים הקלאסיים ומשפיע במידה רבה על מידת דיוקם. לוגיקה עמומה יכולה לצמצם בעיות אלו משום שהיא מתמודדת עם המרת קלטים מעורפלים לפלטים מדויקים יותר. המחקרים שמתוארים במאמרים ][ ]2[ ]3[, ]5[ ]3[, ומחקרים נוספים בתחום, בוחנים את התועלת ביישום מספר רעיונות מהלוגיקה הקלאסית במודלים להערכת עלות פרויקטי תוכנה. 8 מתוך 39

המחקרים מציעים שיטות שונות ל "ערפול" המודלים הקלאסיים, כלומר הפיכתם ממודלים שמבוססים על הלוגיקה הקלאסית למודלים שמבוססים על הלוגיקה העמומה. המודלים מציעים ייצוג עמום של הפרמטרים השונים במודל )=חוקי השפה בלוגיקה עמומה( במקום הייצוג הקלאסי. היישומים שבהם מתמקדת עבודה זו מרחיבים את מודל.COCOMO הם מציעים ייצוג של הערכים הלשוניים של הפרמטרים שמרכיבים את הקבוע M )כגון "תוכניתן מעט טוב"( ושל ערך גודל הפרויקט )SIZE( באמצעות סדרות עמומות במקום הייצוג הרגיל. נבהיר כיצד הלוגיקה העמומה יכולה לתרום להערכת עלות הפרויקט באמצעות דוגמא. נניח ש- X היא קבוצה שמכילה עלויות פרויקטים ו- A היא קבוצה עמומה שמכילה את הפרויקטים שעלותם גבוהה. נגדיר פרויקטים שעלותם גבוה כפרויקטים שההשקה בהם נעה בין 25 ח"א )חודשי-אדם( ל- 30 ח"א. ניקח פרויקט שההשקעה בו 24 ח"א ופרויקט שההשקעה בו 0 ח"א. נניח שפונקצית השייכות של הפרויקט. A ( (0 ופונקצית השייכות של הפרויקט השני היא 0.0 A הראשון לקבוצה A היא 24) 0.8 ( בלוגיקה הקלאסית, הפרויקט הראשון לא ייכלל בקבוצת הפרויקטים שעלותם גבוהה, משום שמידת השייכות שלו לקבוצה יכולה להיות רק 0 או : 20 24 25 30 35 איור 9 ייצוג פרויקט שעלותו גבוהה בלוגיקה קלאסית לעומת זאת, בלוגיקה עמומה הפרויקט כן ייכלל בקבוצת הפרויקטים שעלותם גבוהה, כפרויקט שעלותו "כמעט גבוהה", כלומר במידת שייכות 0.8: 0.8 20 24 25 30 35 איור 0 ייצוג פרויקט שעלותו גבוהה בלוגיקה עמומה נשים לב, שהפרויקט שעלותו היא 0 ח"א לא ייכלל בקבוצת הפרויקטים שעלותם גבוהה באף אחת מהלוגיקות. הדוגמא ממחישה את תרומתה של הלוגיקה העמומה להתמודדות עם מצבים של חוסר וודאות או של חוסר מוחלטות. 9 מתוך 39

מאמר ][ 2.4. גישות שונות להערכה מבוססת לוגיקה עמומה אחד המחקרים המרכזיים בנושא יישום לוגיקה עמומה במודלים להערכת איכות הינו המחקר של ]6[, MacDonnel שהציע שימוש בלוגיקה עמומה להערכת המדדים השונים של התוכנה. מטרת המחקר הייתה לבחון שיטות שונות להתמודדות עם הבעיות במודלים הקלאסיים. במחקר נבחנו מספר שיטות: פונקציות גישה ( point,)function רגרסיה ליניארית, רשת נוירונים ולוגיה עמומה. בשיטת הלוגיקה העמומה המחקר אפשר למנהלי הפרויקטים להגדיר את המדדים במונחים של שפת דיבור במקום בערכים כמותיים. למשל, המודל שמציע המחקר מאפשר למנהל הפרויקט לתת למשתנה "מספר המסכים" את הערך "מספר גדול של מסכים" במקום ערך מספרי מדויק. במחקר זה נמצא שלוגיקה עמומה מביאה לשיפור משמעותי בדיוק וששימוש בשיטה זו מביא לאחוז שגיאה נמוך יותר מכל המודלים המקבילים, פרט לרשתות נוירונים. הטבלה הבאה מתארת את ממצאי המחקר על פי הקריטריונים למדידת איכות של מודל הערכה: FPA function point analysis שימוש בהיסטוריה של ממוצעי או חציוני ההשקעה הנדרשת לפונקציות דומות LS least square LMS least median squares שימוש ברשתות נוירונים- neural regression ניתן לראות שאחוז השגיאה הממוצעת בלוגיקה עמומה הוא הנמוך ביותר )0.44( פרט לרשתות נוירונים. )הערת המחברת נתוני PRED לעומת זאת אינם מצביעים על לוגיקה עמומה כשיטה המדויקת ביותר( בעקבות מחקר זה פותח כלי למנהלי פרויקטים, FULSOME שמאפשר הגדרת הפרמטרים באמצעות לוגיקה עמומה. הכלי מאפשר למנהלי פרויקטים להגדיר בעצמם תכונות שעשויות להשפיע על עלות הפרויקט אך הוא דורש בסיס נתונים שכולל מידע היסטורי, או לחלופין מומחה שיספק את המידע למערכת על סמך ניסיונו. ניסיונות רבים לשימוש בלוגיקה עמומה לשיפור מודלים אלגוריתמיים קיימים בוצעו במשך הזמן. הניסיון הראשון להוסיף את המימד העמום למודל הנפוץ ביותר,,COCOMO בוצע ע"י ]7[ Fei and Liu. הם ביצעו את ההבחנה שהערכה מדויקת של מספר שורות הקוד ושל מרבית הפרמטרים האחרים במודל אינן יכולות להתבצע לפני תחילתו והציעו מודל מבוסס לוגיקה עמומה, f-cocomo שמאפשר מתן ערכים לא מדויקים לפרמטרים השונים. בהמשך נעשתה ע"י ]8[ Musflek עבודה נוספת שמטרתה להוסיף את מימד הלוגיקה העמומה למודל.COCOMO ההיבט הראשון בעבודה זו עסק בייצוג גודל הפרויקט באמצעות לוגיקה עמומה בעוד המקדמים נותרו בייצוג רגיל )מודל זה נקרא גם כן f-cocomo אך זהו אינו אותו המודל שתואר קודם לכן(. ההיבט השני בעבודה הוסיף לראשון את מימד מאפייני התוכנה )mode( קרי הפרמטרים A ו- B בנוסחה. המודל מקבל כפרמטר את מספר שורות הקוד ואת 20 מתוך 39 הפרמטרים A ו- B ולכן תומך בסוגים רבים של פרויקטים.

כ) בשלב הבא, Idri ו- ]5[ Abran פיתחו מודל מבוסס intermediate COCOMO שמאפשר הערכה של משתני העלות )M )cost driver באמצעות לוגיקה עמומה. מודל זה מעניין לדעתי במיוחד, משום שבניגוד למודלים האחרים הוא מיישם את הלוגיקה העמומה עבור כל אחד מהפרמטרים של נוסחת COCOMO ולא רק למשתנה הגודל. המודל מתייחס ל- 5 הפרמטרים שמאפיינים את הפרויקט, כלומר למרכיב M בנוסחה. להלן מובאים לדוגמא הנתונים של הפרמטר DATA ש, מייצג את השפעת גודל בסיס הנתונים על עלות הפרויקט במודל COCOMO הקלאסי: פרמטר תיאור נמוך מאד נמוך בינוני גבוה מאד גבוה גבוה במיוחד.65.6.08 0.94 DATA גודל בסיס הנתונים כפי שניתן לראות בטבלה, במודל הקלאסי 5 הפרמטרים נמדדים באמצעות סולם סידורי שמורכב משישה ערכים מבוססי שפה: "נמוך מאוד", "נמוך", "בינוני", "גבוה", "גבוה מאוד", "גבוה במיוחד". למשל, הפרמטר DATA שבדוגמא, נמדד באופן הבא: מחשבים את היחס D database size in bytes or characters )נוסחה 2 חישוב נפח בסיס הנתונים היחסי( P program size in DSI מבטאים את DATA באמצעות אחד ממשתני השפה באופן הבא: נמוך בינוני גבוה גבוה מאוד D/P>000 00<=D/P<000 0<=D/P<00 D/P<0 D/P הבעייתיות בשיטה זו היא שלפרויקטים שהפרמטר DATA שלהם נמצא בגבולות שבין משתני השפה יכולות להיות שגיאות גדולות בהערכה. כאשר משקללים את כל הפרמטרים, ניתן להגיע למצב בו שני פרויקטים שההשקעה הנומינלית שלהם זהה יהיה פער גדול בהערכת ההשקעה בגלל היותם קרובים לגבולות, למשל: ) B A Size ( בפרויקט הראשון הפרמטרים שמגדילים את הערכת העלות נמצאים בדיוק מתחת לגבול בין "נמוך" ל"בינוני" )כלומר יוגדרו כנמוכים( ואילו הפרמטרים שמצמצמים אותה נמצאים בדיוק מעל לגבול בין "בינוני" ל"גבוה" )כלומר יוגדרו כגבוהים( ולכן העלות תוגדר כנמוכה. בפרויקט השני הפרמטרים שמגדילים את הערכת העלות נמצאים בדיוק מעל לגבול בין "נמוך" ל"בינוני" לומר יוגדרו כבינוניים( ואילו הפרמטרים שמצמצמים אותה נמצאים בדיוק מתחת לגבול בין "בינוני" ל"גבוה" )כלומר יוגדרו כבינוניים( ולכן העלות תוגדר כבינונית. הערכת הזמנים של הפרויקט השני תהיה גדולה באופן משמעותי מזו של הראשון, כאשר למעשה הערכת הזמנים הייתה צריכה להיות דומה. כפתרון לבעיה, המודל מציע לייצג את משתני השפה )רשימת הגורמים שבטבלה( כקבוצה עמומה במקום הייצוג שתואר לעיל. היתרון המרכזי של הצגה זו הוא שהיא מחקה את אופן הפרשנות של האדם לערכים אלו ושהמעבר ממשתנה שפה אחד למשנהו הוא הדרגתי ולא מקוטע. להלן דוגמא של ייצוג הפרמטר DATA באמצעות סדרת מספרים עמומים. לכל 2 מתוך 39

משתנה שפה הוגדר מספר עמום עם פונקצית שייכות : המודל מגדיר באופן דומה מתוך 5 הפרמטרים בייצוג עמום. השלב האחרון שמבצע המודל בתהליך הוא הגדרת מכפלת ההשקעה M בנוסחה הבסיסית )( באמצעות הסדרות העמומות שהוגדרו עבור כל אחד מהפרמטרים. )M 3 הגדרת )נוסחה M 5 C i הקבוע M בנוסחה הבסיסית )( מוגדר באופן הבא: ij כאשר C ij הוא מכפלת ההשקעה המתאימה למשתנה השפה ה- j שנבחר עבור הפרמטר ה- i )למשל C 2,3 מייצג את הקטגוריה "בינוני" שנבחרה לפרמטר.)DATA הפונקציה F הוגדרה כליניארית לטובת הפשטות: F _ C )נוסחה 4 גודל פרויקט עמום טרפזי( ij k i j ( P) C Vi A j i, j.v i A j V j כאשר i A היא פונקצית השייכות של הקבוצה העמומה, שמייצגת את המספרים העמומים המשויכים לפרמטר K i מייצג את מספר הקטגוריות הקיימות עבור הפרמטר P V. i הוא הערך שניתן לאותו פרמטר. F _ C DATA Alow 2 j 4 j ( P) C DATA Aj DATA, LOW לדוגמא, אם נתייחס לפרמטר השני, DATA )שיש לו ארבעה משתני שפה כפי שראינו קודם לכן(: ( P) C 2, j DATA Aint ermediate ( P) C DATA, INTEMEDIATE DATA Ahigh ( P) C DATA, HIGH DATA Avery _ high ( P) C DATA, VERY _ HIGH נניח שהערך שבחרנו הוא 56 )ניתן לראות את מידת השייכות שלו לכל תחום בתרשים לעיל(. נחשב את מידת השייכות שלו לכל ערך לפי פונקצית השייכות הטרפזית )ראה נוסחה 8(: LOW HIGH 0 VERYHIGH (00 56) /(00 55) 0.98 ונקבל : (56 55) /(00 55) 0.022 INTERMEDIATE 0 F _ C2 0.97 C DATA, INTEMEDIATE 0. 022 CDATA, HIGH את נתוני משתנה השפה )משקל השפעתם על הערך M( ניקח מטבלה 3 במאמר ]5[: גבוה במיוחד מאד גבוה גבוה בינוני נמוך נמוך מאד.65.6.08 0.94 גודל בסיס הנתונים DATA F _ C j 44 ( ) ( ).08 ונקבל:.0078 45 45 ערך זה מייצג נאמנה את הביטוי העמום "בין בינוני לגבוה, אבל קרוב יותר לבינוני". 22 מתוך 39 כלומר התרומה של הפרמטר DATA ל- M תהיה.0078 שזה

לבסוף, ניתוח המודל בוצע באמצעות שלושה בסיסי נתונים שנגזרים מבסיס הנתונים של.COCOMO כל אחד משלושת בסיסי הנתונים מכיל נתונים לגבי 63 פרויקטים, כאשר נתוני הפרויקטים נבחרו באופן אקראי מתוך הטווח המותר כפי שמוגדר בבסיס הנתונים של.COCOMO הטבלה הבאה מציגה השוואה בין איכות המודל המוצע למודל COCOMO עפ"י קריטריוני האיכות PRED ו- MARE עבור כל אחד מבסיסי הנתונים: DB # DB #2 DB #3 COCOMO Pred(20)% 6.4/68 46.86/68 4.27/68 68/68 MARE(%) 22.5/8.52 78.45/8.52 30.8/8.52 8.52/8.52 הממצאים של המודל הקלאסי )טקסט אדום( זהים עבור כל אחד מארבעת בסיסי הנתונים. לעומת זאת, הממצאים של מודל הלוגיקה העמומה )טקסט כחול( משתנים בהתאם לשינויים בכל אחד מבסיסי הנתונים. מכאן ניתן להסיק שמודל COCOMO הקלאסי אינו מתמודד טוב עם אי דיוקים קטנים בקלט. הוא מפיק הערכה זהה עבור שני קלטים "כמעט זהים" או במקרה החמור יותר, מפיק הערכה שונה באופן משמעותי. לעומת זאת, המודל שמתבסס על לוגיקה עמומה מתמודד טוב יותר עם אי דיוקים בקלט ומייצר הערכות עלות שונות בהתאם. המודל הבא פותח ע"י ]9[. Ahmed, M.A., Omolade Sailu המודל מציע תשתית לחיזוי עלות פרויקט מבוססת לוגיקה עמומה. התשתית מאפשרת הערכה של עלות הפרויקט באמצעות ייצוג עמום של ערך גודל הפרויקט ושל הפרמטרים שמרכיבים את המשתנה M. למודל נלווה פיתוח של תוכנה שתומכת בביצוע הערכת העלות מבוססת לוגיקה עמומה. המודל והתוכנה סתגלניים לשיפורים באמצעות הרחבת בסיס הנתונים לאורך זמן, בעקבות שימוש מומחים בתוכנה. באימות המודל נמצא, כי אחוז הפרויקטים שאחוז השגיאה שלהם קטן מ- 25% כאשר מכווננים את ערך גודל הפרויקט באמצעות המודל הוא 72% )ערך זה גבוה ביחס לנתונים שמתקבלים במודלים הקלאסיים(. בהמשך בוצע מחקר ע"י ]0[ Marcio Rodrige Braz שמטרתו הייתה ליישם לוגיקה עמומה במודלים להערכת עלות של פרויקטים מונחי עצמים. המחקר ניסה להרחיב את מודל (USP) use case size point כך שהוא יהיה מבוסס על לוגיקה עמומה, אולם בחלק מהפרויקטים המודל הביא לתוצאות פחות טובות מאלו של המודלים הקודמים. שימוש נוסף בלוגיקה עמומה שולב במודל האנאלוגיות. מודל זה, שהינו מודל איכותי הינו נפוץ מאוד. אחד המודלים שהוצעו ליישום הלוגיקה העמומה בתהליך האנאלוגיה לפרויקטים דומים הוצע ע "י ][. Idri מודל זה נועד לתמוך בפרויקטים שניתנים לתיאור במדדים איכותיים )קטגוריות( ו/או כמותיים )ערכים מספריים( ובכך הוא משפר את המודלים האנלוגיים הקלאסיים שתומכים רק במדדים כמותיים. הוספת מימד השפה להשוואה בין פרויקטים, מאפשרת למנהלי הפרויקטים להגדיר את פרמטרי ההשוואה בצורה מדויקת יותר. ]2[ Cuauhtmoc Lopez Martin מימשו יישום של הערכת עלות פרויקט תוכנה באמצעות לוגיקה עמומה. במחקר בוצעה השוואה של תוצאות ההערכות באמצעות היישום אל מול תוצאות הערכה באמצעות רגרסיה. התוצאות היו פחות או יותר זהות בשתי השיטות )ואחוז השגיאה היחסית האבסולוטית אף היה מעט גבוה יותר בשימוש בלוגיקה עמומה( אולם אחוז הפרויקטים בהם אחוז השגיאה היה נמוך מ- 20% היה גבוה יותר במודל מבוסס לוגיקה עמומה. כמו כן, באמצעות לוגיקה עמומה התקבלו הערכות מדויקות להפליא )0% שגיאה( עבור שישה מתוך 4 הפרויקטים שנבחנו. גישה נוספת ליישום הלוגיקה העמומה במודלים להערכות זמנים היא זו שהוצעה ע "י ]3[. Nonika Bajaj גישה זו מתבססת על ההערכה מלמטה למעלה.)bottom-up( המודל מציע ביצוע הערכה של המשימות הפרטניות ועיבוד של 23 מתוך 39

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

הערכת גודל הפרויקט )size( באמצעות לוגיקה עמומה כללי.3.4.4.4 המודל שתואר בפרק הקודם מיישם את הלוגיקה העמומה עבור מאפייני הפרויקט )הפרמטר M בנוסחה )((. שני המודלים שיתוארו בפרק זה מיישמים את הלוגיקה העמומה עבור פרמטר הגודל )SIZE( בנוסחה זו. פרמטר זה הינו מרכיב מהותי בנוסחה הבסיסית להערכת עלות הפרויקטים, אולם קשה מאוד להפיק עבורו הערכה מדויקת בשלבים המוקדמים של הפרויקט. המודלים הבאים מציעים שימוש בלוגיקה עמומה לשיפור ההערכה של פרמטר זה. הערכה באמצעות מספר עמום משולש מאמר ]2[ )triangular membership function (.5.4.5.4. כללי, Effort כאשר אין A Size B M המודל שמוצע במאמר ]2[ מציע גרסה משופרת של הנוסחה הבסיסית. Effort התייחסות לקבוע M )הוא נותר ללא שינוי(. כלומר המודל מציע גרסה משופרת לנוסחה A Size B המודל מציע להגדיר את גודל הפרויקט Size כמספר עמום במקום כמספר רגיל, כאשר המספר העמום מורכב משלושה ערכים: ההערכה הפסימית, ההערכה הממוצעת וההערכה האופטימית. לכל אחת מההערכות ניתן משקל בתחום הסגור [0,] בהתאם למידת הסבירות שהיא נכונה. 2.5.4. עמעום גודל הפרויקט )fuzzification( המודל עושה שימוש בפונקצית השייכות המשולשת )ראה )TFN להערכת גודל הפרויקט S: 0 ( S) ( S l) /( m l) ( r S) /( r m) )זוהי נוסחה 7, השימוש באותיות שונות בפרק זה הוא לטובת תאימות למאמר] 2 [( if if if S l or S r x ( l, m) x ( m, r) בפונקציה (S) מגדירים את m כחלוקה של בסיס המשולש ביחס k )קבוע כלשהו( ומתקבל: l k r m k )נוסחה 5 הגדרת גודל הפרויקט במודל משולש( ומנוסחה (9) מתקבל: 2kF l m k 2F r m k )נוסחה 6 חישוב הגבולות במודל המשולש( 25 מתוך 39

תועצמאב הנכות יטקיורפב םינמז תכרעה הנכות תסדנהב תינוירנימס הדובע דומע FUZZY LOGIC 26 39 ךותמ E לש תוכיישה תיצקנופ תא םירידגמ תעכ (ה המאתהב )טקיורפל תשרדנה העקשה םיעובקה םה A,B-ש ריכזנ( :)שלושמה ידוקדוק לש x-ה יכרע םה l,r,m,cocomo לש תיסיסבה החסונב ), ( ) ( ), ( ) ( 0 ) ( / / B B B B B B B B r A m A x if m r A E r m A l A x if l m l A E r A E or l A E if E 7 החסונ שלושמה לדומב העקשהל תוכיישה תיצקנופ.3.5.4 תולעה בושיח רתויב תימיספה,רתויב תימיטפואה הכרעהה לש ללקושמ עצוממ איה E לש המומעה הכרעהה,עצומה לדומב :תעצוממה הכרעההו 3 2 3 2 ) ( ) ( ) ( ) ( W W W r A W m A W l A W E Effort B B B 8 החסונ( שלושמה לדומב תעצוממה העקשהה בושיח ) W i חווטב ךרע לכל ןתינש לקשמה אוה.)ינמיה r-ו ןויצחה m,ילאמשה לובגה אוה l(

4.5.4. ממצאים. F מנוסחה )6( מתקבל: 0.3 הערכים שנלקחו עבור המודל הם k A=6 B=0.665 כוילו באמצעות ניסויים ונקבעו כ- B,A הערכים l 0.7m r. 3m להלן תוצאות המודל ל- 3 הפרויקטים שנתוניהם נבחנו בהשוואה למודל COCOMO הבסיסי. COCOMOעפ"י 2.4 המודל הבסיסי לפרויקטים קטנים KLOC.05 החישוב עבור מודל COCOMO הוא: )ראה הערה/תיקון לנתוני הטבלה בפרק ההערות למאמרים(: Project No. S.No KLOC (kilo LOC) Actual Effort Model* COCOMO 253.6 287 22.22 802.72 2 2 40.5 82.5 62.65 6.96 3 3 450 07.3 30.75 465.83 4 4 24.4 86.9 89.79 672.97 5 5 449.9 336.3 30.70 465.49 6 6 50 84 72.08 45.92 8 7 200 30.3 8.22 625.59 9 8 289 6 23.48 920.77 0 9 39 72 6.0 2.4 0 254.2 258.7 22.55 804.72 2 28.6 230.7 35.0 393.47 3 2 6.4 57 57.3 499.47 4 3 64.8 246.9 59.33 50.524 27 מתוך 39

התרשים הבא מתאר את תוצאות המודל אל מול תוצאות של מודלים אחרים, כולל :COCOMO איור השוואת מודל המספרים העמומים המשולשים למודלים הקלאסיים ניתן לראות בתרשים, שתוצאות המודל קרובות יותר במרבית המקרים לגודל הפרויקט בפועל מאלו של יתר המודלים )ובפרט של מודל.)COCOMO הטבלה הבאה משווה את הביצועים של מספר מודלים לעומת המודל המוצע: Model type COCOMO Model Baily-Basili Model Doty Model Halstead Model Model MARE% 234.485028 0.9224455 629.6780956 823.4806 39.29572958 Pred (40) 0 46.538465 0 0 69.23076923 מהטבלה ניתן להסיק שבניסוי שבוצע נמצא שהמודל המוצע נותן הערכות מדויקות יותר מהמודלים האחרים, משום שמספר הפרויקטים שאחוז השגיאות בהם נמוך גבוה יותר וממוצע אחוז השגיאות בכלל הפרויקטים נמוך יותר. 28 מתוך 39

הערכה באמצעות מספר עמום טרפזי מאמר ]3[ )trapezoidal membership function (.6.4.6.4. כללי המודל שמתואר במאמר ]3[ מציע גם הוא הרחבה של מודל COCOMO ללוגיקה עמומה ע"י ייצוג גודל הפרויקט כמספר עמום. אולם, מודל זה עושה שימוש בפונקצית שייכות טרפזית במקום משולשת. הבעיה בהרחבת המודל באמצעות מספר עמום משולש היא שהמעבר בין המקטעים השונים הוא מקוטע יותר ופחות הדרגתי. על מנת להגיע למעבר חלק יותר, המודל מציע שימוש בפונקצית שייכות טרפזית להערכת גודל הפרויקט. לדוגמא, אם נייצג את גודל הפרויקט עפ"י הטבלה הבאה: קטן בינוני גדול ענק KLOC >=000 00<= KLOC <000 0<= KLOC <00 KLOC<0 KLOC אם נייצג את משתני השפה "קטן", "בינוני", "גדול" ו "ענק" באמצעות קבוצת מספרים עמומים משולשים, נקבל את המעברים הבאים בין הקבוצות: איור 2 00 0 000 מידול משולש של גדלי פרויקט לעומת זאת, אם נייצג את משתני השפה במודל הטרפזי נקבל מעברים חלקים יותר: 0 00 000 איור 3 מידול טרפזי של גודל הפרויקט 29 מתוך 39

2.6.4. עמעום גודל הפרויקט )fuzzification( לפרמטר "גודל הפרויקט" מוסיפים מימד עמום במקום ערך יחיד, המודל מגדיר את גודל הפרויקט בהתאם להתפלגות הערכים האפשריים שלו. גודל הפרויקט מוגדר באמצעות הקבוצה העמומה הבאה: (P F _ Size ) )נוסחה 9 פונקצית השייכות של גודל הפרויקט במודל הטרפזי ) Size כאשר (P) היא פונקצית השייכות הטרפזית. הגודל מיוצג באמצעות פונקציות שייכות המותאמות לגודל הפרויקט. 3.6.4. חישוב העלות חישוב העלות מבוצע באמצעות תהליך החזרת הנתונים מלוגיקה עמומה ללוגיקה קלאסית.)defuzziation( המודל מתבסס על מודל התיכון המפורט של.COCOMO גודל הפרויקט שמוזן לנוסחה הינו גודל הפרויקט העמום שתואר בסעיף הקודם. פונקצית השייכות מוגדרת בהתאם לסדר גודל הפרויקט: איור 4 פונקציות השייכות הטרפזיות של גודל הפרויקט תוצאת הנוסחה של COCOMO עם הפרמטר F_SIZE היא ההערכה המתקבלת לעלות הפרויקט. 30 מתוך 39

4.6.4. ממצאים במחקר נבחן מאגר הפרויקטים של COCOMO שכולל עשרה פרויקטים. עבור כל אחד מהפרויקטים חושבה הערכת העלות באמצעות.COCOMO העלות באמצעות המודל המשולש והעלות שצפה מודל, F _ Size המחקר בחן את קריטריוני איכות המודל של כל אחד מהמודלים. נמצא ששימוש בפונקצית שייכות טרפזית מביא לשיפור לעומת שימוש בפונקציה משולשת ומביא לתוצאות מדויקות יותר ביחס למודלים אחרים. הטבלה הבאה מציגה את ממצאי הניסוי. חישוב PRED הוא תוספת של מחברת העבודה לחישובים שהוצגו במאמר, לטובת השוואה באמצעות פרמטרים זהים לניתוח שבוצע עבור פונקצית השייכות המשולשת ועבור המודל לעמעום M. Project ID Actuval Effort COCOMO TAFM TPFM COCOMO MRE TAFM MRE TPFM MRE 6 45.63 52.53 55.39 0.2596723 0.38852459 0.0996723 2 237 24. 249.6 234.52 0.096624473 0.0530807 0.0046435 3 599 539.6 575.44 580.8 0.09965275 0.03933222 0.030383973 4 603 553.43 578.2 589.36 0.082205638 0.04260365 0.022620232 5 702 335. 253.9 46.2 0.9085852 0.78682336 0.632763533 6 523 278.86 34.4 365.57 0.466806883 0.398852772 0.3003384 7 075 66.3 739.63 806.34 0.384837209 0.3972093 0.24996279 8 2455 945.4 206.9 2096.3 0.207576375 0.7845238 0.460998 9 958 408.33 476.6 563.65 0.573768267 0.50250529 0.463883 0 063 275.9 209.6 64.4 0.20028222 0.37957 0.095390405 MARE 0.32650854 0.25866299 0.99226796 MARE% 32.65085406 25.8662992 9.92267965 PRED(40) 70 80 80 PRED(30) 60 60 70 * במאמר אין התייחסות לערכי B ו- M שנלקחו עבור החישובים השונים. הגרף הבא משווה בין האומדנים שהתקבלו ע"י המודלים השונים: איור 5 השוואת מודל המספרים העמומים הטרפזיים למודלים מקבילים ממצאי מחקר זה מראים ששימוש במודל שמבוסס על מספר עמום טרפזי משפר את דיוק הערכת עלות הפרויקט אל מול המודל הקודם )מבוסס מספר עמום משולש( ואל מול מודל COCOMO הקלאסי. 3 מתוך 39

5. דיון מהמחקרים השונים שבוצעו התמונה נראית ברורה שילוב היבטים שונים של לוגיקה עמומה במודלים להערכת עלויות פרויקטי תוכנה תורמת משמעותית לדיוק ההערכות. מסקנה זו תואמת לציפיות, משום שהמודלים הקלאסיים להערכת עלויות של פרויקטי תוכנה דורשים ממנהלי הפרויקט לנב א באופן מדויק את גודל הפרויקט כבר בשלב התכנון, כאשר בשלב זה אפילו הדרישות לא מגובשות ושלמות. כמו כן, הם דורשים ממנהל הפרויקט להבין כבר בשלב ראשוני מאוד, את כל הסיכונים וההשפעות על עלות הפרויקט בצורה מאוד טובה ולהכריע באופן חד משמעי עבור כל סיכון האם הוא ישפיע על העלות או לא. הלוגיקה העמומה "מרככת" את המודלים ומצפה ממנהל הפרויקט לבצע הערכות פחות נוקשות. השיטה דומה בהרבה לתהליך המחשבתי שמבוצע בשלב הערכת העלויות ולכן מאפשרת למנהל הפרויקט להתמודד עם ההחלטות בצורה טבעית יותר ולכן להגיע לתוצאות מדויקות יותר. אולם יחד עם זאת, עדיין ראוי לשאול מספר שאלות. השאלה הראשונה היא האם המודלים עובדים לא רק בתיאוריה, כאשר עושים שימוש בבסיסי נתונים קיימים ו"נקיים" מטעויות אדם, אלא גם במציאות, כאשר בני אנוש מזינים את הנתונים? יש לזכור, שכל המודלים פרט למודל המשולש נבחנו באמצעות בסיס הנתונים של COCOMO שמכיל נתוני פרויקטים ישנים יחסית ושנאספו לטובת המחקר של.COCOMO אין במרבית מאמרים )פרט ל-] 9 [( התייחסות לשימוש יישומי במודלים ע"י מנהלי פרויקטים ותוצאותיו. על מנת לקבל מענה )גם אם לא שלם( לשאלה זו, הפעלתי את המודל המשולש על שני פרויקטים שנתוניהם מוכרים לי. אמנם לא מדובר בניסוי מדעי, אך ניתן לקבל ממנו מדד איכותי לגבי המודל משום שמרבית מנהלי הפרויקטים אינם מפעילים את המודלים באופן מדעי אלא באופן דומה למה שבוצע על ידי. לטובת הפשטות, הפעלתי את המודל עם הפרמטרים 2.94=A, )B =B נבחר ל- משום שמדובר בפרויקטים קטנים יחסית, עם רמת מורכבות שאינה מושפעת מגודלם( ראשית, חישבתי את הערכת העלות באמצעות COCOMO II המורחב. לבסוף, הפעלתי את המודל המשולש עם הקבועים B,A שצוינו לעיל ועם הפרמטר M המחושב, כאשר המימד העמום נוסף בשלב זה לגודל הפרויקט.SIZE גודל הפרויקט שהוזן הוא מספר שורות הקוד הקיימות בפועל )שני הפרויקטים כבר הושלמו(. הערכת העלות שהתקבלה במודל המשולש קרובה מאוד להשקעה בפועל בפרויקטים. הממצאים עבור המודל הטרפזי אינם חד משמעיים משום שלא כל הפרמטרים בהם נעשה שימוש במודל מתוארים במאמר ולכן הפעלת המודל לא הייתה מדויקת ובחרתי שלא להציג נתונים אלו בעבודה. ניתן להפעיל גם את מודל עמעום הפרמטרים )עמעום הערך M( בנוסף למודל המשולש, אולם מכיוון שמדובר בפרויקטים שהושלמו, בחירת הערכים בטבלת הפרמטרים ידועה לי ואין משמעות לבחירת ערך בגבול בין שני משתני שפה )ברור שזה לא ישפר את המודל כאשר ההערכה מבוצעת בדיעבד ולכן באפשרותי לבחור את הערך המתאים ביותר ולא "לנחש"(. לכן ערכי M נקבעו בלוגיקה הקלאסית ולא בלוגיקה עמומה. 32 מתוך 39

להלן הממצאים עבור המודל המשולש: פרויקט א' פרויקט קטן ופשוט )פרויקט עבור סדנה באוניברסיטה הפתוחה(. חישוב M. טבלת בחירת משתני השפה ונתוניה נלקחו מ-] 5 [: נמוך מאוד נמוך בינוני גבוה גבוה מאוד גבוה במיוחד.66.3.5 0.85 0.7 CPLX מורכבות המוצר.56.3. TIME מגבלות זמן ריצה.2.06 STOR מגבלות אחסון.3.5 0.87 אספקת חשמל לזיכרון וירטואלי )האם VIRT נדרשת אספקה רציפה(.5.07 0.87 TURN זמן שחזור נדרש 0.9. VEXP ניסיון עם המכונה הוירטואלית 0.7 0.86.9.46 ACAP יכולת מנתח המערכת 0.82 0.9.3.29 AEXP ניסיון עם האפליקציה 0.7 0.86.7.42 PCAP יכולת אנשי הפיתוח 0.95.07.4 LEXP ניסיון עם שפת הפיתוח 0.82 0.9..24 MODP שיטות פיתוח מודרניות 0.83 0.9..24 TOOL שימוש בכלי פיתוח..04.08.23 SCED לו""ז נדרש לפרויקט 0.497 0.76 77 0.80 036 M=0.3030 size KLOC A 2.94 B W W 2 W 3 4 0.7.3 2.94 0.7 2.94 4.3 F _ Size.02 6 עלות הפרויקט בפועל הייתה בדיוק ח"א. כלומר.MRE=2% במודל COCOMOII התוצאה שהתקבלה היא 0.89 ח"א, כלומר.MRE=% 33 מתוך 39

פרויקט ב' פרויקט קטן-בינוני אך מורכב מאוד )מערכת עבור צה"ל(. ונתוניה נלקחו מ-] 5 [: חישוב M. טבלת בחירת משתני השפה פרמטר תיאור נמוך מאד נמוך בינונ י גבוה מאד גבוה גבוה במיוחד.4.5 0.88 0.75 RELY אמינות נדרשת.65.6.08 0.94 DATA גודל בסיס הנתונים.66.3.5 0.85 0.7 CPLX מורכבות המוצר.56.3. TIME מגבלות זמן ריצה.2.06 STOR מגבלות אחסון.3.5 0.87 אספקת חשמל לזיכרון וירטואלי )האם נדרשת VIRT אספקה רציפה(.5.07 0.87 TURN זמן שחזור נדרש 0.9. VEXP ניסיון עם המכונה הוירטואלית 0.7 0.86.9.46 ACAP יכולת מנתח המערכת 0.82 0.9.3.29 AEXP ניסיון עם האפליקציה 0.7 0.86.7.42 PCAP יכולת אנשי הפיתוח 0.95.07.4 LEXP ניסיון עם שפת הפיתוח 0.82 0.9..24 MODP שיטות פיתוח מודרניות 0.83 0.9..24 TOOL שימוש בכלי פיתוח..04.08.23 SCED לו""ז נדרש לפרויקט.56.858 0.8899.67 2 0 size 20KLOC A 2.94 B W W 2 W 3 4 0.7.3 M.6984.6984 (2.94 0.7 20 2.94 20 4 2.94.3 20) F _ Size 4.5 6 עלות הפרויקט בפועל הייתה 20 ח"א.)MRE=4.6%( במודל COCOMOII ההערכה שהתקבלה היא 99 ח"א,.MRE=7.5% לסיכום, הממצאים שקיבלתי בבדיקה הפשוטה טובים מאוד ומנבאים את עלות הפרויקט בצורה טובה יותר. אמנם הבדיקה אינה מדעית ולא ניתן להסיק ממנה מסקנות חד משמעיות אולם היא מחזקת את התחושה שהמודלים אכן משפרים את הערכת העלות הקלאסית. 34 מתוך 39

השאלה השנייה שעדיין נשאלת, היא האם אכן המודלים האלגוריתמיים, גם לאחר שילוב הלוגיקה העמומה, מהווים שיטה יעילה להערכת עלויות הפרויקט? יש לזכור שהלוגיקה העמומה אינה מבטלת לחלוטין את הצורך בהערכת הפרמטרים השונים של הפרויקט בשלב מאוד מוקדם שלו. היא רק תורמת לתהליך ההערכה עצמו, אך עדיין למנהל הפרויקט צריך להיות מושג טוב לגבי האומדנים השונים. התשובה לשאלה זו אינה חד משמעית. הטבלה הבאה מרכזת את נתוני אחוז השגיאה היחסית האבסולוטית של המחקרים השונים שהוצגו בפרקים הקודמים: MacDonnel IDRI & ABRAN Mittal, Parkash & Mittal Reddy & Raju MARE% 54% 22.5% 39.29% 9.92% Pred(0)% 7% --- 5.38% 40% Pred(20)% --- 4.27% 38.46% 60% Pred(25)% 30% --- 46.5% 60% Pred(40)% ---- --- 69.23% 80% מהטבלה ניתן לראות שהנתונים הטובים ביותר התקבלו במודל שמבוסס על פונקצית שייכות טרפזית. אולם, אפילו במודל זה אחוז השגיאה היחסית הממוצעת הוא כ- 20%. כמו כן, ל- 60% מהפרויקטים שנמדדו במודל זה ההערכה שהתקבלה שונה ב- 0% מהעלות בפועל. השאלה הנשאלת היא מהו אחוז שגיאה ש-"אפשר לחיות איתו"? האם בפרויקט שעלותו הוערכה ב- 0 מיליון דולר, טעות של 20%, כלומר 2 מיליון דולר, מתקבלת על הדעת? האם בארגון בו עלותו הממוצעת של פרויקט עומדת על חצי מיליון דולר, מתקבל על הדעת שב- 60% מהפרויקטים תהיה שגיאה של יותר מ- 0%, כלומר 50K דולר לפרויקט )בהנחה שמדובר בעיקר בהערכות חסר(? בארגון שמייצר 50 פרויקטים בשנה, המשמעות היא שלפחות 30 מנהלי פרויקטים מציגים הערכה שגויה בלפחות 50K דולר לפרויקט בשנה. העלות לארגון היא לפחות.5 מיליון דולר בשנה! מסתמן שאכן נדרש עדיין לתת מענה לסוגיות שהלוגיקה העמומה לא נתנה להן מענה מלא. 35 מתוך 39

מאמר ]3[ 6. סיכום עבודה זה תיארה מספר מחקרים שמטרתם להביא לשיפור הערכות ההשקעה הנדרשת בפרויקטי תוכנה. ממצאי המחקרים אכן הראו שיפור אל מול מודל הערכת העלות הבסיסי.COCOMO יחד עם זאת, אין ספק שעבודת המחקר בתחום הערכת העלות לא תמה. הלוגיקה העמומה היא רק שלב אחד בדרך למודלים שמספקים הערכת עלות שניתן להסתמך עליה ללא חשש. מסתמן ממסקנות המחקרים השונים, שעתידו של תחום זה הוא בניסיון לשלב את הלוגיקה העמומה עם מודלים מבוססי רשתות נוירונים ובכך לנצל את היתרונות של שני המודלים היכולת ללימוד עצמי והפרשנות הטובה של רשתות נוירונים והיכולת לספק הערכות מבוססות חוקי שפה של לוגיקה עמומה. לדעתי, לאור העובדה שתהליך הערכת ההשקעה הנדרשת בפרויקטי תוכנה מתבצע על ידי אנשים בעלי תפיסות סובייקטיביות של הפרמטרים השונים )למשל, איך אדם מפרש את הביטוי "משימה קשה"?(, חשוב מאוד לבצע במחקרים בנושא זה ניסויים גם מחוץ למעבדה - ניסויים שקרובים יותר לאלו המבוצעים בתחום מדעי החברה. דוגמא למחקר שנתן מענה להיבט זה הוא המודל שפותח ע"י ]9[. Ahmed, M.A., Omolade Sailu יישום של כל מודל תיאורטי ע"י מדגם מייצג של מנהלי פרויקטים ובעלי תפקידים אחרים ששותפים לתהליך ההערכה ובדיקת דיוק ההערכה שבוצעה ע"י המודלים השונים אל מול ההשקעה בפועל, כפי שתימדד לאחר גמר הפרויקט, תיתן לדעתי האישית תמונה מדויקת יותר של נכונות המודלים וכדאיות השימוש בהם. "Time is the most indefinable yet paradoxical of things; the past is gone, the future is not come, and the present becomes the past even while we attempt to define it, and, like the flash of lightning, at once exists and expires." ~Charles Caleb Colton 36 מתוך 39

הערות לגבי המאמרים במאמר ]2[ נמצאו מספר טעויות: תוצאות הפעלת הנוסחה הבאה על הנתונים בע"מ 5 )במאמר( בטבלה אינה תואמות את החישובים שבוצעו על ידי: W Effort( E) B B B ( A ) W2 ( Am ) W3 ( A ) W W W 2 3 2kF m k 2F m k F 0.3 ולכן בהתאמה, הבאים: 0.7m.3m כלומר עבור הפרויקט הראשון 253.6=m. KLOC מייצג את גודל הפרויקט ב- m המשקלים שנלקחו במאמר הם = W3 W= W2 =4 B=0.665 כמו כן הוגדר ש- 6=A לפי הנוסחה מקבלים: 0.665 (6 ) 4(6 m ) (6 Effort( E) 4 0.7*253.6 77.52.3* 253.6 329.68 (6 77.52 Effort( E) 0.665 0.665 ) 4(6 253.6 4 0.665 0.665 ) ) (6 329.68 0.665 ) 237.3675 ולא כפי שמופיע הטבלה. השגיאה זהה בכל הפרויקטים והיא פי 0.8495 מהערך המחושב. ייתכן ומקור הטעות הוא בערך B, עבור 0.645=B מקבלים תוצאות דומות. ייתכן ומקור הטעות הוא בערך A, עבור 5.36253=A מקבלים תוצאות דומות. ע"מ 4 הנוסחה של MARE לא שלמה. חסרה החלוקה ב- n )מספר הפרויקטים(. ע"מ 4 הגדרת PREDICTION גם היא לא מדויקת. PRED הוא אחוז הפרויקטים שאחוז השגיאה היחסית האבסולוטית הוא מתחת ל- n ולא כפי שכתוב. 37 מתוך 39