Cocomo II

מתוך המכלול, האנציקלופדיה היהודית
קפיצה לניווט קפיצה לחיפוש

Cocomo II ‏(COnstructive COst MOdel II) הוא מודל עלויות קונסטרוקטיבי השני, הוא מודל אלגוריתמי הנועד להערכת עלויות, מאמץ ותכנון זמנים, בעת תכנון של פיתוח תוכנה חדשה. המודל משתמש בנוסחת נסיגה בסיסית עם פרמטרים שנגזרו מפרויקטי עבר ומהפרויקט העכשווי. פותח על ידי בארי בם, פרופסור בהנדסת תוכנה, בעל תואר דוקטור במתמטיקה ובעל תרומה רבה לתחום הנדסת התוכנה. מבין פיתוחיו נמנים: Wideband Delphi,‏ COCOMO.

היסטוריה

Cocomo II פותח לראשונה בשנת 1997 ופורסם בספרו של בארי בוהם "Software Cost Estimation With COCOMO II" בשנת 2000. המודל הוא פיתוח של המודל הקודם Cocomo81 שפורסם בשנת 1981 בספרו של בארי בוהם "Software Engineering Economics". ישנם מספר טכניקות הערכה מקובלות ביניהן:

  • מודל עלויות אלגוריתמי
  • שיפוט על ידי מומחים
  • הערכה באמצעות דמיון
  • חוק פרקינסון
  • עלות לניצחון- Pricing to win

Cocomo II נמנה אחד מבין המודלים האלגוריתמיים.

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

תתי המודלים

למעשה המודל Cocomo II מורכב משלושה תתי מודלים:

  • Application-Composition Model- מודל יצירת האפליקציה

מודל המערב את המאמץ ליצירת אב טיפוס המיועד לפתרון בעיות מורכבות כגון- ממשק משתמש, ביצועים או בגרות הטכנולוגיה. המודל מבוסס על application points (לדוגמה- מספר המסכים השונים במערכת). הנחת הבסיס היא שהמערכת נוצרה מקוד שכבר היה קיים בעבר.

  • Early Design Model- מודל עיצוב מוקדם

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

  • Post-Architecture Model- מודל שלאחר הארכיטקטורה

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

הנוסחה

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

  • הנוסחה הבסיסית של COCOMO II:
Effort Applied (E) = A(Size)B [person-month]s
  • Size= הערכת גודל התוכנה, ביחידות של KSLOC, כמות שורות הקוד הנדרשת באלפים (תלוי בשפת התכנות).

יכול להיות גם כהערכה של (unadjusted function points (UFP לאחר המרה לשורות קוד וחילוק ב-1000.

  • Effort Factor = A -קבוע, גורם התאמת המאמץ (לפי סוג הפרויקט).
  • Scaling Factor = B - גורם מעריכי המסביר חיסכון או חוסר חיסכון. אם B<1 הפרויקט מציג יתרונות לגודל- כאשר גודל המוצר הוכפל ב-2, כמות המאמץ גדלה בפחות מכך. אם B=1 זהו מצב מאוזן, זהו מצב שכיח עבור פרויקטים קטנים ומשתמשים ב Application-Composition Model במצב זה. אם B>1 ישנו חיסרון לגודל, בדרך כלל בשל צמיחה של פרויקטים גדולים.

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

מתי נשתמש במודל

  1. כאשר החלטה פיננסית או כלכלית תלויה בפיתוח תוכנה
  2. תכנון זמנים ותקציבים של פרויקט
  3. כאשר קיימת החלטה לגבי העלויות של כל חלק בפרויקט
  4. כאשר קיימת החלטה מתי לפתח/לעדכן תוכנה

לקריאה נוספת

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

הערך באדיבות ויקיפדיה העברית, קרדיט,
רשימת התורמים
רישיון cc-by-sa 3.0

28674526Cocomo II