پروژه تخمین تلاش لازم جهت توسعه نرم افزار



فهرست مطالب
عنوان صفحه
چکیده 1
فصل 1: کلیات تحقیق 3
1-1 مقدمه 3
1-2 بیان مسئله 4
1-3 سوابق و ضرورت انجام تحقیق 5
1-4 اهداف تحقیق 7
1-5 سازماندهی تحقیق 8
فصل دوم: ادبیات تحقیق 11
2-1 مقدمه 11
2-2 متدولوژی و ضرورت توجه به آن 15
2-3 تفاوت روش توسعه نرم افزار و سخت افزار 17
2-4 فرایند توسعه نرم افزار 20
2-4-1 مدلهای توسعه نرم افزار 20
2-4-1-1 اصول شئ گرایی 24
2-4-2 مقایسه متدولوژی های سنگین وزن و سبک وزن 26
2-4-3 فعالیت های پشتیبانی 27
فصل سوم: تخمین تلاش لازم جهت توسعه نرم افزار 29
3-1 مقدمه 29
3-2 مفهوم تخمین هزینه 30
3-3 تخمین هزینه نرم افزار 30
3-4 انواع تخمین 30
3-5 اندازه نرم افزار 32
3-5-1 تعداد خطوط کد 32
3-5-2 علم نرم افزار 32
3-5-3 نقاط کاری 33
3-5-4 نقطه ویژگی 33
3-6 روش های تخمین هزینه 33
3-6-1 روشهای غیرالگوریتمی 33
3-6-1-1 تخمین تجربی 34
3-6-1-2 روش داوری کارشناسانه 34
3-6-1-3 تخمین با قیاس 35
3-6-1-4 روش پارکینسون 35
3-6-1-5 پایین به بالا 36
3-6-1-6 بالا به پایین 36
3-6-2 روشهای الگوریتمی 36
3-6-2-1 مدل های COCOMO 36
3-6-2-2 مدل Putnam 37
3-6-2-3روش های مبتنی بر آنالیز نقطه ی تابعی 37
3-6-2-4رگرسیون 38
3-7 مروری بر کارهای انجام شده 39
3-7-1 مدل تخمین هزینه نرم افزار مبتنی بر منطق فازی 39
3-7-2 تخمین هزینه نرم افزار با استفاده از شبکه های عصبی 41
3-7-3 تخمین نیروی کار نرم افزار بوسیله الگوریتم ژنتیک با پارامترهای تنظیم شده 41
3-7-4 چهارچوب مبتنی بر شبکه عصبی و منطق فازی برای تخمین هزینه توسعه نرم افزار 42
3-7-5 بهینه سازی پارامترها با استفاده از بهینه سازی دسته ذرات 42
3-7-6 شبکه عصبی موجک برای تخمین هزینه 43
3-7-7 پیشگویی عصبی-ژنتیک برای توسعه نیروی کار نرم افزاری 44
3-8 ارزیابی مدل های تخمین 45
فصل چهارم : مدل رهیافتی 48
4-1 مقدمه 48
4-2روش شناسی تحقیق 48
4-3 داده ها و جامعه آماری 49
4-4معیارهای ارزیابی 51
4-5 اصول روش پیشنهادی 51
4-5-1 انتخاب زیر مجموعه ویژگی 52
4-5-2 اندازه گیری شباهت 52
4-5-3 مقیاس گذاری 54
4-5-4 تعداد پروژه های مشابه 54
4-5-5 تطابق تناسبات 54
4-6 شمایی از مدل پیشنهادی 54
نتیجه گیری 59
پیشنهادات آتی 59
منابع 61

فهرست جداول
عنوان صفحه
جدول( 2-1): مقایسه متدولوژی سنگین وزن و سبک وزن 26
جدول(3-1): بررسی مدلهای تخمین الگوریتمی 39
جدول (3-2 ): مقایسه مدلهای الگوریتمی و غیر الگوریتمی 46
جدول(4-1): ویژگیهای رقمی مجموعه دادههای COCOMO ناسا 49
جدول(4-2): تشریح برخی متغیرهای مهم برای تخمین تلاش توسعه 50
جدول(4-3): معیارهای ارزیابی مدلهای تخمین 51
جدول(4-4): انواع متدهای توسعه پروژههای نرمافزاری 55
جدول(4-5): انواع کاربردهای پروژههای نرمافزاری 55

فهرست شکل ها
عنوان صفحه
شکل(1-1): نمودار روند تحقیق 9
شکل(2-1): منحنی نرخ خرابی سختافزار نسبت به زمان 18
شکل(2-2): منحنی نرخ خرابی ایدهآل نرمافزار نسبت به زمان 18
شکل(2-3): منحنی نرخ خرابی ایدهآل نرمافزار نسبت به زمان 19
شکل(2-4): رشد هزینه نرم افزار به سخت افزار 19
شکل(‏3-1): مدل فازی-cocomo تخمین نیروی کار 41
شکل(‏3-2): روند تکامل در الگوریتم پیشنهادی 42
شکل(‏3-3): الف) نمونه ای از شبکه عصبی که با استفاده از الگوریتم ژنتیک ب) نمایش کروموزوم ها 45
شکل(3-4): نمودار مدلهای تخمین تلاش توسعه نرم افزار 46
شکل(4-1): فاصله اقلیدسی وزن دار 53
شکل(4-2): شِمای کلی روش مبتنی بر قیاس 54
شکل (4-3): خوشه بندی بر اساس ویژگی های خاص پروژه های نرم افزاری 56
شکل (4-4): شمای مدل پیشنهادی 57

چکیده
برای هر پروژه نرم افزاری سه عامل متداخل زمان، هزینه و کیفیت موثر است. پرداختن به هریک از عوامل باعث تاثیر در دو عامل دیگر می شود. بالا رفتن زمان انجام کار باعث کیفیت بیشتر و بر افزایش قیمت پروژه تاثیر دارد. از آنجائی که در برنامه ریزی پروژه بایستی منابع مورد نیاز از قبــل، پیش بینی شود، لذا تخمین هزینه و زمان تولید نرم افزار هم برای تولید کننده و هم برای استفاده کننده بسیار حیاتی است. منابع و برنامه دو عامل تعیین کننده برای انجام عملیات پروژه هستند. اگر این دو عامل مشخص باشند،آنگاه زمان و هزینه پروژه تولید نرم افزار می تواند تعیین شود. در پروژه های نرم افزاری قبل از شروع به کد نویسی بایستی پارامترهایی تخمین زده شود، بطوریکه رسیدن به اهداف پروژه تضمین گردد.این پارامترها جهت تصمیم گیری در تعیین زمان ،نیروی انسانی، میزان تلاش هزینه و … کارایی دارد تیم نرم افزاری باید قادر باشند که قبل از شروع به کد نویسی این پارامترها ار برآورد نمایند. یکی از این پارامترها میزان تلاش لازم است که بایستی تخمین درستی از آن در دست داشته باشیم.الگوی های زیادی برای فرایند تخمین ارائه شده از این رو، ما در این تحقیق سعی داریم میزان تلاش لازم برای رسیدن نرم افزار به اهداف خود را در حالت کلی با مدل های ارائه شده پیش بینی و نتایج حاصل با استفاده از روشهای رسمی و ریاضی بررسی نماییم.

واژه های کلیدی
توسعه نرم افزار، هزینه نرم افزار ، تخمین تلاش نرم افزار

فصل 1
" مقدمه "

فصل 1: کلیات تحقیق
در این فصل ابتدا یک مقدمه پیرامون موضوع این تحقیق ارائه می شود سپس بخش تعریف مساله را خواهیم داشت که در آن بیان می شود چه عاملی حاکی از ضرورت این کار تحقیقاتی است یا به بیان بهتر، در این تحقیق چه کاری باید صورت بپذیرد. بامشخص شدن صورت مساله،سابقه کار تحقیقاتی پیرامون موضوع تحقیق ذکر می شود و عنوان می گردد که چه کارهایی از زمان پیدایش مفهوم تخمین هزینه نرم افزار صورت پذیرفته است و نهایتا نیز ساختار این مستند تحقیقاتی(سمینار) ذکر می شود.
1-1 مقدمه
منظور از تخمین تلاش1، پیش بینى مقدار تلاش، زمان و تعداد کارکنان موردنیاز برای توسعه نرمافـزار مىباشد. اجزای اصلی هزینه پروژه، هزینه هاى سخت افزارى، آموزش و هزینه هاى مربوط به تولید و ساخت نرم افزار، شامل: پرداخت دستمزد به مهندسان نرم افزار است. از آن جاکه، بخش اعظم هزینه پروژه، هزینه کارکنان است؛ اصطلاح تخمین هزینه و تخمین تلاش به صورت متقابل استفاده مىشوند. تخمین در ابتدای فرایند ساخت سیستم، که به تخمین مقدماتی معروف است، اغلب دقت کمی دارد؛ زیرا در ابتدا، دانش کمی از پروژه موجود است. تخمین تلاش موردنیاز برای ساخت یک نرمافــزار، یکی از دغدغـــه هاى مهم مدیریت پروژه، تلقی می شود. الگوهاى تخمین هزینه اى که در مراحل اولیه ساخت پروژه، با حداقل اطلاعات موجود از پــروژه، هزینه ساخت سیستم را تخمیــن مى زنند، سودمند و موردنیاز هستند. روش تخمین هزینه مناسب، امکان کنتـرل موثر زمان و هزینه ساخت سیـستم را فـراهم مىنماید (G Kim, 2004) در نتیجه الگوهاى متعددی برای تخمین تلاش سیستم مطرح شده است.
در بررسی بوهم و همکارانش، الگوهاى تخمین تلاش به چهار دسته تقسیم شده اند؛ شامل روش های مبتنی بر: الگو، نظر خبره، یادگیری و پویایی هستند. روش های مبتنی بر الگو، از متداول ترین شیوه تخمین تلاش سیستم مى باشند. (B. Barry, C. Abts, S. Chulani, 2000) بوهـــم، معتقد است که تخمین تلاش ساخت سیستم در مراحل اولیه ساخت سیستم بین 25 تا 400 درصد تلاش واقعی، متغیر است (B.Boehm, 1981)؛ به عبارت دیگر،تخمین تلاش از دقت بسیار کمی برخوردار است؛ زیرا دانش تخمین زننده از پروژه اندک است. این نظر توسط همسترا نیز تایید شده است. (F.Heemstra, 1992)
شبکه عصبی مصنوعی 2که از آن برای تخـمین تلاش توسعـــه نرم افــزارها استفاده مىشود (A.Gray, S. MacDonell, 1997). به طور نسبى، کاربرد شبکه عصبی در تخمین تلاش در یک پژوهش، جدید است. در سال هاى اخیر، تحقیقات متعددی برای استفاده از روش های غیرالگوریتمی نظیر شبکه عصبی مصنوعی، به عنوان جایگزین روش های مبتنی بر الگو، انجام شده است. (A. Idri, 2002)در دو دهه گذشته از شبکه عصبی برای پیش بینى در کاربردهای مختلفی استفاده و نتایج حاصله در مقایسه با روش های معمول بهتر بوده است روش های مبتنی بر الگو، در اوایل پروژه، به دلیل دانش کمى از پروژه، تخمین مناسبی ارائه نمی دهند؛ درحالی که، روش های مبتنی بر شبکه عصبی مصنوعی، مى توانند درصورت وجود اطلاعات از تلاش پروژه هاى کامل شده، تخمین تلاش مناسبی را ارائه دهند. بررسی های صورت گرفته در مورد بیست هزار پروژه نرم افزاری در طول هجده سال نشان داد، که اکثر پروژه های نرم افزاری به دلیل تخمین هزینه غلط و در نتیجه برنامه ریزی و زمان بندی نادرست مدیران با شکست مواجه شده اند. روش های مختلفی در تخمین و برآورد حجم فعالیت های لازم در انجام یک پروژه نرم افزاری در جامعه نرم افزار ارائه شده است. فارغ از اینکه از چه روشی در تخمین یک پروژه نرم افـــزاری استفاده میشود مهم آن است که بدون وجود اطلاعات کافی در زمینه حوزه و دامنه سیستم قابلیت ها و توانایی های آن و همچنین شرایط محیطی و فرهنگی تیم تولید نرم افزار و پیچیدگی های تکنیکی آن، برآورد واقع بینانه پروژه کاری دور از دسترس می نماید.
1-2 بیان مسئله
امروزه تخمین هزینه پروژه های نرم افزاری اهمیت زیادی پیداکرده است امروزه نرم افزار از گران ترین اجزاء یک سیستم کامپیوتری محسوب می گردد. تخمین درست هزینه تولید یک سیستم نرم افزاری، باعث می شود که مدیر پروژه در طول چرخه حیات نرم افزار، از پشتوانه قدرتمندی جهت اتخاذ تصمیمات مختلف برخوردار باشد و مدیر پروژه، تحلیل گر، طراح، برنامه نویس و سایر نیروهای تیم توسعه نرم افزار می دانند که برای تولید یک محصول مناسب به چه میزان تلاش و زمان نیاز دارند. بدون داشتن یک تخمین مناسب از هزینه مورد نیاز، مدیر پروژه نمی تواند تشخیص دهد که به چه میزان زمان و چه حجمی از نیروی انسانی و سایر منابع جهت انجام پروژه نیاز دارد و در صورت تشخیص اشتباه، پروژه در مسیر شکست حتمی حرکت خواهد کرد. سوال این است که چگونه می توان تلاش لازم برای یک پروژه نرم افزاری را تخمین زد.
یکی از روشهای تخمین هزینه های نرم افزار، پیشگویی میزان تلاش لازم برای ساخت نرم افزار و زمان مورد نیاز جهت توسعه ی آن است. یکی از سوالات اساسی که در شروع برنامه نویسی با آن مواجه میشویم این است که میزان تلاش لازم برای انجام پروژه به گونه ای که به اهداف خود برسد چه میزان است؟ به شکل ساده می توان تلاش لازم را برحسب تعداد افرادی که در روز/هفته/ماه و یا حتی سال بر روی پروژه کار می کنند را تخمین زد. (Huang, 2007)
متدها و ابزارها و تکنولوژی های متفاوتی مطرح شده است، همچنین فرمولهایی پیشنهاد شده است که با توجه به سایز و پیچیدگی به عنوان مقادیر ورودی، میزان تلاش لازم را برآورد می نمایند. کار تخمین پروژه های نرم افزاری را به تخمین وظایف در مراحل چرخه حیات یا مراحل فرایند تولید نرم افزار میتوان افراز نمود . میزان تلاش و کار لازم برای انجام هر فعالیت از وظایف تعیین شده معمولا بر اساس کارایی نفر در ماه مشخص می شود . ممکن است هزینه افراد بر اساس نوع عملکرد محوله متفاوت باشد. معمولا به تحلیلگران با سابقه دستمزدی بیشتر از برنامه نویسان تعلق می گیرد. ماهیت خلاق پروژه های نرم افزاری و انتزاعی بودن آن تخمین تلاش لازم برای توسعه نرم افزار را بی نهایت مشکل می کند روشهای متداول تخمین خود اساسا انتزاعی است با این همه هنوز هم تخمین پروژه امری لازم و ضروری محسوب میشود. (اس.پرسمن, 1382)
1-3 سوابق و ضرورت انجام تحقیق
در نخستین روزهای کار با کامپیوتر ، تعداد کامپیوتر ها کم و برنامه های کاربردی اغلب پروژه های کوچک و یک نفره بود . از طرفی هزینه های نرم افزاری درصد کوچکی از کل هزینه سیستم کامپیوتری را تشکیل می داد و قدری خطا در تخمین هزینه های نرم افزاری ، تاثیر اندکی برجای می گذاشت . به تدریج تعداد ، اندازه و اهمیــت برنامه های کاربردی و از طرف دیگر هزینه های ایجاد نرم افزار شروع به رشــد نمود ، به گونه ای که امروزه نرم افزار گران ترین عنصر هر سیستم کامپیوتری به شمار می آید و افزایش بیش از حد هزینه ها برای سازنده نرم افزار مصیبت بار خواهد بود . روش های مبتنی بر الگو، متداول ترین برآورد کننده تلاش ساخت نرم افزار هستند. الگوی COCOMO3 و نقاط وظیفه ای4 یا به اختصار FP مثالهایی از روش های مبتنی بر الگو می باشند.COCOMOمبتنی برتحلیل رگرسیون داده هاى مربوط به 63 پروژه کامل شده است. الگوى اساسی COCOMO به صورت رابطه شماره (1-1) نشان داده شده است. در این رابطه، EF تعداد نفر-ماه یا ساعات مورد نیاز، c مقدار ثایت به اندازه تخمینی 2/3، LOC تعداد خطوط برنامه به هزار و K مقدار ثابت به اندازه تخمینی 05/1 می باشند.
(1-1) EF=c(LOC)K
در الگوی COCOMO تخمین تلاش ، شامل سه مرحله است: مرحله اول مقدار LOC مورد نیاز سیستم اطلاعاتی محاسبه می شود. سپس، تلاش کلی با استفاده از معادله EF=3/2(LOC)1/05 تخمین زده میشود. مرحله دوم، تلاش تخمین زده شده با استفاده از محرک های هزینه 5 یا تنظیم کننده های تلاش دقیق می شود. روش کوکومو دارای سه الگو است که در مراحل مختلف پروژه مورد استفاده قرار می گیرند. برای مثال در الگوی کوکومو میانی، تلاش به صورت تابعی از تعداد خطوط برنامه و 15 تنظیم کننده تلاش، تخمین زده می شود . (B.Boehm, et al, 1995)
بوهم در سال 1981 مدل کوکومو را بر اساس رابطه بین مقادیر ورودی به سیستم و سایز هزینه ها ارائه داد . ورژن جدید آن کوکومو2 بوده که برای شی گرایی و همچنین برای نرم افزارهایی با قابلیت استفاده مجدد مبتنی بر کامپوننت کاربرد دارد (Merlo, WS 2002 / 2003). کوکومو را می توان در سه مدل دسته بندی نمود، مدل متوسط که بعد از مرحله نیازمندیها تخمین می زند و مدل پیشرفته که بعد از طراحی تخمین می زند. هر مدل کوکومو نیز در سه حالت قابل بررسی است، حالت اول حالت سازمان نیافته است، در این حالت با یک تیم کوچک سروکار داریم که کاربردها به خوبی قابل فهم بوده که سخت نیست بلکه که آسان هم هست. حالت دوم حالت تقریبا منفصل است ؛ امکان دارد روش انجام کار واضح نباشد و شبیه به کاربردهای قبلی هم نباشد این حالت سختتر از حالت قبل است و حالت سوم روش کار برای تیم ، غیر معمول است که به این حالت سخت گویند. مدل های دیگری نیز با استفاده از تعداد خطوط برنامه به تخمین تلاش می پردازند مانند: مدل هرینه مبتنی بر رگرسیون، مدل والستونفلیکس6 ، مدل بیلی-بسیلی7، مدل دوتی،مدل آلبرت و گفنی، مدل کرمرر، متسون، یارنت و ملیچمپ که این روشها به صورت کامل در فصل سوم بیان خواهد شد (Laird, Linda M., 2006). همچنین از سری روشهای غیرالگوریتمی تخمین تلاش شبکه عصبی مصنوعی، معمول ترین روش مبتنی بر یادگیری مورد استفاده برای تخمین تلاش توسعه نرم افزار است. شبکه عصبی از عناصر یا واحدهای پردازشی ساده که به صورت موازی عمل مى نمایند، تشکیل شده است (H. Demuth, M. Beale, copyright 1992 – 2002) . و همچمین مدلهای تخمین دیگری مانند مدلهای تخمین مبتنی بر منطق فازی، تخمین بوسیله الگوریتم های ژنتیک، تخمین توسط بهینه سازی دسته ذارات،شبکه عصبی موجک، پیشگویی عصبی-ژنتیک و سایر روشها و پروژه های در حال بررسی نیز ارائه شده که به تفصیل در فصل سوم درمورد آنها بحث خواهد شد.
دقت تخمین تلاش یک عامل مهم در موفقیت پروژه است (G Kim,et al,, 2004). یک عامل اصلی در انتخاب الگوى تخمینِ تلاش، دقت پیش بینى آن در امر تخمین است. به این منظور معیار درصد میانگین مطلق خطا 8برای ارزیابی دقت تخمین مطرح شده است. مقدار خطا از رابطه شماره (2-1) محاسبه مى گردد. در این رابطه N تعداد نمونه هاى استفاده شده در آزمون مقدار واقعی تلاش Vact ، مقدار تلاش تخمین زده شده Vest است. بررسی الگوهای Kemerer روی FP، COCOMO ، SLIM، Esimacsخطای الگوهاى مختلف بالا و مقدار خطاى مشاهده شده بین 57 تا 800 بوده است (Kemerer, 1987). در بررسی سه الگو توسط Ferens وهمکارش با استفاده از پایگاه داده Albrecht و 14 پروژه از مجموعه داده Kemerer معیار بین 46 تا 105 درصد گزارش شده است (D.V. Ferens, R.B. Gumer, 1992). در روش های مبتنی بر نظر خبره معیار بین 32 تا 1107 درصد گزارش شده است. (S.S.Vicinanza, et.al, 1991)
(2-1) MAPE=( (|Vest – Vact|/ Vact)/(N*100))
فرآیندهای مدیریت پروژه با نه توانمندی تعریف می شود که این توانمندی ها عبارتند از مدیریت یکپارچگی پروژه، محدوده، زمان، هزینه، کیفیت، منابع انسانی، ارتباطات، ریسک و برون سپاری و از آنجایی که نقش هر یک از عوامل فوق در تولید یک محصول نرم افزاری کلیدی است توانمندی یک مدیر پروژه در تولید نرم افزار یکی از عوامل مهم و حیاتی در موفقیت پروژه به شمار می رود.دست اندرکاران تولید نرم افزار در کشور ما بیشتر شرکت های کوچک نرم افزاری با پشتوانه های مالی اندک هستند. این شرکت ها عمدتا به دلیل محدودیت منابع از رویکرد توسعه تکنولوژی به منظور آشنایی با ابزار و روش های نوین تولید نرم افزار غافل می شوند. شکست در پروژه های نرم افــــزاری در هر یک از چهار مورد "هزینه"، "زمان"، "کیفیت" و "دستیابی به اهداف" مطرح می شود؛ بدین معنا که اگر پروژه ای با صرف هزینه بیشتر یا زمان بیشتر یا با کیفیت پایین تر انجام شود، علی رغم به پایان رسیدن پروژه، آن را توام با شکست می دانیم (Pressman, 2001). کشور ما هنوز دوران اولیه بلوغ خود را در عرصه IT تجربه می کند، دوره ای سرشار از مسایل و چالش های گوناگون. چالش هایی که برخی از آن ها به سیاست های کلان کشور مرتبط و برخی دیگر زاییده ویژگی های خاص نرم افزار و دست اندرکاران تولید و توسعه آن است. با وجود فنون و ابزارهای مختلف در تخمین هزینه های پروژه بسیاری از برآورد های پروژه های نرم افزاری از دقت کمی برخوردارند .
لذا برای رفع چالش بوجود آمده لازم است پژوهشی برای رسیدن به یک روش جهت تخمین تلاش لازم برای توسعه نرم افزارهای مختلف به صورت واقع بینانه تر انجام گیرد. از این رو در این پژوهش سعی بر این است که با بررسی کلی روشهای موجود تخمین هزینه و تلاش نرم افزار و ارائه روشی توانمند جهت تخمین تلاش لازم برای توسعه نرم افزار، راه را برای پیشگاما ن عرصه تولید نرم افزار در کشور ایران و سایر تولید کنندگان نرم افزار برآوردی واقع بینانه تر برای پروژه های نرم افزاری داشته باشیم تا همچنان پروژه های نرم افزاری با دقت بالا در تخمین های مربوطه در تولید آن داشته باشیم.
1-4 اهداف تحقیق
باتوجه به اینکه تخــمین درست هزینه تولید یک سیستم نرم افزاری دارای اهمیت است و موجب میشود که بتوان به کمک آن تشخیص داد که چه منابعی و به چه میزان برای پیشبرد پروژه مورد نیاز است و اینکه می تواند به طبقه بندی و اولویت بندی صحیح پروژه ها براساس طرح تجاری سازمان9 منجر گردد. همچنین با استفاده از آن می توان استراتژی های برخورد با تغییرات و انجام برنامه ریزی مجدد را به درستی تدوین کرد و زمانی که منابع با نیازهای واقعی متناسب باشند، کنترل و مدیریت پروژه آسان تر است و همانطور هم مشتری انتظار دارد که هزینه واقعی پروژه با هزینه تخمین زده شده تناسب داشته باشد.یک تخمین هزینه درست دارای ویژگی های زیر است :
1. برای مدیر پروژه و تیم توسعه نرم افزار منطقی و قابل قبول است.
2. برای تمام ذینفعان پروژه 10مقبول و قابل درک است.
3. بر اساس یک مدل معتبر و مناسب تهیه شده است.
4. در محاسبه آن، تجربه کسب شده در پروژه های قبلی مشابه، لحاظ شده است.
5. جزئیات آن به گونه ای عنوان می شود که ریسکهای ممکن و احتمال موفقیت آن، قابل ارزیابی است.
هدف اصلی این تحقیق ارائه یک روش ریاضی و جهت تخمین تلاش لازم برای توسعه نرم افزار است چنین روشی حلقه مفقوده ی فاز های تولید پروژه های نرم افزاری است با ارائه چنین روشی انتظار می رود برآوردهای واقع بینانه تری برای تولید پروژه های نرم افزاری خواهیم داشت. در واقع برای تخمین هزینه های نرم افزاری روشهای گوناگونی ،بررسی و استفاده شده که هرکدام مزایا و معایب خود را در برآوردهای مربوطه داشته بنابراین مقصد اصلی این تحقیق بررسی جامع از روشهای موجود تخمین و ارائه روشی ریاضی در جهت پیشگویی های پروژه های نرم افزاری می باشد. برآوردهای پروژه یکی از مهم ترین فعالیت ها برای برنامه ریزی یک پروژه است و شامل مراحل زیر می باشد :
1. تعریف و تدوین اهداف اساسی تخمین
2. تدوین یک طرح پروژه11 برای منابع و داده های مورد نیاز
3. تعیین دقیق نیازمندیهای نرم افزار تا حد امکان
4. بیان جرئیات سیستم نرم افزاری مورد نظر تا حد امکان
5. استفاده از روشهای مختلف تخمین
6. مقایسه تخمین های مختلف و تکرار فرآیند تخمین
7. پیگیری و بررسی دقیق میزان هزینه واقعی پروژه و پیشرفت آن در طول اجرای پروژه
1-5 سازماندهی تحقیق
با عنایت به مطالب گفته شده ساختار سمینار در فصل های بعدی به شرح زیر است:
در فصل دوم ادبیات موضوع و همچنین کلیات مسئله مورد بررسی قرار گرفته است، همچنین در این فصل به متدلوژی توسعه نرم افزار و ضرورت توجه به آن و انواع مختلف متدولوژی های ارائه شده پرداخته می شود. فصل سوم به تعریف تخمین و روشهای مختلف تخمین و بررسی مزایا و معایب و کاربرد آنها اختصاص دارد. همچنین به ارزیابی تکنیک های تخمین تلاش جهت توسعه نرم افزار و بررسی معیارهای تخمین که چقدر به واقع بینانه است برای نشان دادن چگونگی عملکرد روش ارزیابی پرداخته شده است. در فصل چهارم به ارائه روش پیشنهادی به صورت اجمالی پرداخته می شود در نهایت در فصل پنجم به نتیجه گیری و ارائه راهکارهای آینده اختصاص داده شده است. روند انجام تحقیق و همچنین ترتیب مراحل در شکل 1-1 ترسیم شده است.

شکل (1-1): نمودار روند تحقیق

فصل 2
" ادبیات تحقیق "

فصل دوم: ادبیات تحقیق
در این فصل به بیان مفاهیم بنیادی در ارتیاط با توسعه نرم افزار ، مدلهای فرایند نرم افزار، متدلوژی و ضرورت توجه به آن ،پیچیدگی ذاتی نرم افزار و تفاوت روش توسعه نرم افزار و سخت افزار پرداخته می شود مجموعه مفاهیمی که به عنوان پایه در فصلهای بعد مورد استفاده قرار میگیرد.
2-1 مقدمه
توسعه نرم افزار در سال های اخیر دچار تحولات گسترده ای شده است بطوریکه امروزه نرم افزار نقش دوگانه ای را بازی می کند .در یک نقش به عنوان محصول نهایی12 محسوب می شود و در نقش دیگر، به عنوان تولید کننده محصول نهایی است. در نقش اول، نرم افزار، پتانسیل بالقوه سخت افزار را به فعلیت می رساند و در این نقش -در کاربردهای گوناگونی مورد استفاده قرار می گیرد از تلفن همراه تا کامپیوترهای بزرگ13- به عنوان تبدیل کننده (تولید،مدیریت، بازیابی، بهنگام سازی و نمایش) اطلاعات عمل می نماید. این اطلاعات می تواند به سادگی یک بیت و به پیچیدگی یک شبیه سازی چندرسانه ای14 باشد. اما در نقش دوم، نرم افزار به عنوان ابزار کنترل سیستم های کامپیوتری(سیستم عامل)، کنترل شبکه های کامپیوتری وطراحی و توسعه نرم افزارهای دیگر(ابزار و محیطهای برنامه نویسی ) عمل می کند. بعقیده صاحبنظران، نرم افزار یکی از نیروهای اصلی و محرک قرن بیست ویکم خواهد بود، زیرا مهمترین محصول قرن که همان اطلاعات است را پردازش می نماید. امروزه، نرم افزار عاملی حیاتی در گردش کار موسسات، کارخانجات، صنعت حمل و نقل، پزشکی، بانکداری، شبیه سازی علمی و صنعتی و دیگر موارد است. همچنین کاربرد های نرم افزار از نمایش بهتر و قابل استفاده تر اطلاعات شخصی گرفته تا مدیریت اطلاعات سازمانهای بزرگ و فراهم نمودن یک بستر اطلاعاتی قوی(همچون اینترنت) که بوسیله آن ایده دهکده جهانی تحقق گردیده، گسترش یافته است. (تیموری, 1388)
در نیمه دوم قـرن بیستم،نقش نــرم افزار دستخوش تغییرات زیادی شده است. پیشرفت شگرف سختافزار، تغییرات اساسی در معماری سیستم های کامپیوتری، افزایش شگفت انگیز ظرفیت حافظه های اصلی و جانبی و ارزان شدم آنها، عواملی بوده اند که باعث افزایش تقاضا برای سیستم های کامپیوتری گردیده اند. این عوامل در کنار ضعف روش های توسعه نرم افزار و ناتوانی این روش ها در کنترل پیچیدگی نرم افزار باعث بوجود آمدن معضلاتی در تولید آن شد، که به آنها اصــطلاح "بحران نرم افــزار"15 اطلاق می شود. علایم و نشانه های این بحران عبارت بودند از:
* ناتوانی نرم افزار در بهره گیری کامل پیشــرفت سریع، قدرت و اطمینانپذیری رو به افزایش سختافزار.
* ناتوانی روشهای توسعه نرمافزار در پاسخگویی به افزایش تقاضای سیستمهای اطلاعاتی پیچیده.
* هزینههای هنگفتی که برای توسعه نرم افزار پرداخته می شد.
* تاخیری (احیانا تا سالها) که در توسعه نرمافزار رخ می داد.
* عدم تامین مشخصات و نیازمندیهای موردنظر کاربر.
* کیفیت پایین،نامطمئن و ناکارا بودن نرمافزار.
* هزینه های هنگفت نگهداری نرمافزار، چرا که قدرت ما در نگهداری سیستم های موجود منوط به کیفیت طراحی و وجود منابع مناسب است. از آنجاییکه-معمولا- سطح اغلب طراحیها پایین بودن و منابع مناسب وجود نداشت، نگهداری پر هزینه میگردد.
متاسفانه یکی از نتایج نامطلوب این بحران، هدر منابع انسانی است که مهمترین و گرانبهاترین سرمایه به شمار می آیند. در واقع، تعداد متخصصان کامپیوتر و برنامهنویسان خوب برای پاسخگویی به نیاز کاربران کافی نیست. از طرف دیگر اهمیت صنعت نرمافزار و نقش آن در کاربردهای علمی، تجاری، صنعتی و دیگر قلمروها روزبهروز برجسته تر میشود. (پرسمن, 1382)
نرم افزار هم مانند هر کالای دیگری باید ساخته شود. فرآیند تولید آن هم مانند همه فرآیند های تولید صنعتی، از "تفکر کارگاهی" تا "تفکر کارخانه ای" را طی کرده است. به فرآیند صنعتی که دقت کنید، می بینید که بعد از آنکه بشر به این صرافت افتاد که خودش نمی تواند همه کار بکند و مثلا یک کلبه را به صورت کامل بسازد، ابتدا به صورت فردی و در مغازه ها و کارگاه های تخصصی کار شروع شد، آهنگری ها، نجاری ها یا در و پنجره سازی و …. و بعد دید که نمی تواند با این روش برج بسازد، نمی تواند خودرو را در حجم انبوه تولید کند ، طرز فکرش را عوض کرد و کارخانه ها را ساخت تا بتوانند در یک خط تولید به صورت انبوه، کالای استاندارد تولید کنند و مشتری ها هم عادت کردند که خود را با کالا تطبیق دهند. همین اتفاق در نرم افزار افتاد، از جایی که به صورت اختصاصی برای هر مشتری پروژه تولید داشتیم، تا بسته های نرم افزاری16 که به صورت انبوه تولید می شد و فروش می رفت و تا ERP که می گوییم استاندارد است و هر مشتری خودش را تطبیق می دهد و یا سیستم به صورت کم، تغییر داده می شود تا نیاز مشتری را فراهم کند.این تولید هم مانند تولید های دیگر نیاز به تحلیل، طراحی و پیاده سازی دارد. مدیریت پروژه می خواهد تولیدش و همان مسائل رادارد. فرآیند مدیریت پروژه (سازماندهی، برنامه ریزی و نظارت) به عنوان یک اصل جدانشدنی از هر پروژه ای در همه صنایع (منجمله نرم افزار) هم وجود دارد. اما نرم افزار به لحاظ عوامل ماهیتیش چنان با بقیه کالاهای صنعتی متفاوت است که می بینیم در روشهای توسعه آن تنوع زیادی وجود دارد و هر روز یک مدل جدید برای توسعه نرم افزار می بینیم. این تفاوت ها را به طور خلاصه می توانیم شامل موارد زیر بدانیم:
* نرم افزار پیچیده17 است: به تعبیری "کاهش پیچیدگی قلب توسعه نرم افزار است." یک برنامه کوچک گاهی هزاران خط فرمان می شود و توسعه آن به هر نحو مشکل است. روشهایی مانند ماژول بنـــدی و …. آمده است، اما هنوز هم پیچیدگی یکی از مهمترین اجزاء جدانشدنی نرم افزار ها و فرآیند تولید آن است.
* نرم افزار انتزاعی18 است: شما نمی توانید به شکل فیزیکی آن را لمس کنید و نشان دهید. نه خودتان واقعا می توانید همه آن را یکجا در دست بگیرید و مشکلتر آنکه مشتری ها عقلشان به چشمشان است! و شما عاجز از نمایش کار خود. نرم افزار انتزاعی ترین جزء تولید است.
* نیازها کامل نیست19 : اغلب موراد، پیش از ساخت واقعی نرم افزار، همه نیازهای مشتری یا استخراج نشده و یا هنوز معلوم نیست. در پایان پروژه، تازه مشتری می فهمد که واقعا چه می خواهد.
* فنآوری به سرعت تغییر می کند:20 سرعت تغییرات در فنآوری های ساخت نرم افزار فوق العاده سریع است. هر روز بستر و سیستم عامل جدید، هر روز تغییر سخت افزار، تغییر زبانهای برنامه سازی و …. کدام فنآوری را می شناسید که به این سرعت تغییر کند.
* تجربه های موفق بالغ نشده اند21 : به خاطر رشد سریع، اغلب تولید کنندگان به خوبی مهارت های تولید را کسب نکرده اند. معمولا در پروژه ها عوامل کیفی کمتر دیده می شود و بنابراین تجربه های موفق کمتر بدست می آیند.حتی در صورت وجود، به دلیل تغییرات سریع فنآوری، کمتر در پروژه های بعدی می توانند الگو باشند.
* فناوری اطلاعات بسیار گسترده است:22 در این که شک ندارید! کسی نیست در این زمینه که همه فن حریف باشد (علامه دهر در نرم افزار نداریم!) بنابراین کسی نمی تواند به تنهایی به همه قسمت های یک پروژه اشراف داشته باشد.
* تجارب فنآوری ناقص هستند :23 فنآوری های جدید و نسخ های جدید ابزارها اغلب آنقدر با نسخه قبلیشان تفاوت دارد که به سرعت تجربه افراد در این زمینه خارج از رده می شود. تجارب اکثر در موقع کار بدست آمده و بعد از آن کمتر به درد می خورند.
* توسعه نرم افزار اکتشافی است24: به دلیل عدم شناسایی نیازها و عدم دانش مشتریان نرم افزار با آن، فرآیند تولید اغلب ماهیت تحقیقاتی و یا اکتشافی به خود می گیرد. ابزارها نیز جدیدند و توسعه دهنده باید آموزش استفاده از آنها را کسب کند. بنابراین فرآیند توسعه نرم افزار فقط ساخت آن نیست، یادگرفتن آن است که با چه راهی می توان به نتیجه رسید.
* کارهای تکراری خودکار هستند25: در نرم افزار و تولید آن، به حدی از خودکار سازی برای فرآیند های تکراری رسیده ایم که در تولید های دیگر هنوز بحث آن هم مطرح نشده است، حجم بالای استفاده مجدد26 از قطعات آماده، برون سپاری تولید27 و…. نمونه هایی از این خودکار سازی است.
* ساختن در واقع طراحی است28 : همه فرآیند های صنعتی مراحل مشخصی دارند (تحلیل، طراحی و اجرا : یک مدل خطی خوش تعریف) اما نرم افزار چنین نیست، در مرحله پیاده سازی و اجرا، نیازها به مرور تشخیص داده می شوند و این باعث می شود طراحی تا پایان ادامه پیدا کند. حتی در زمان نگهداری و پشتیبانی نیز، فرآیند طراحی به شکل جدی مطرح است.
* تغییرات راحت پنداشته می شوند:29 تغییر نیاز در فرآیند های تولید دیگر توسط مشتری بسیار سخت دیده می شود و وی سختی تغییر طراحی را در پایان پیاده سازی می فهمد و بنابراین آن را مطرح نمی کند و یا اگر مطرح کرد هزینه آن را می پذیرد. اما در نرم افزار به خاطر ماهیت انتزاعی بودنش این تغییرات ساده فرض می شوند. چون نرم افزار به سادگی قابل توسعه است، مشتری متوجه نیست که چیزی که می خواهد واقعا چه هزینه ای برتولید کننده تحمیل می کند تا آن را اجرا کند. اغلب تغییرات ساختاری نیز بسیار ساده فرض می شوند و تولید کننده را وادار به ساخت آن.
* تغییرات اجتناب ناپذیرند30: ایا در نرم افزار موقعیتی هست که تغییر نکند. همه چیز از فنآوری تا نیاز مشتری تا تیم تولید تغییر می کند و این تغییرات بسیار سریع و غیر قابل اجتناب می باشند. گریزی نیست که آنها را در نظر بگیریم.به قولی تنها چیز "ثابت" در نرم افزار خود مفهوم "تغییر" است. هیچ نرم افزاری در ابتدا کامل نیست و این تغییرات است که باعث می شود مطابق نیاز در بیاید.
این موارد و موارد دیگری از این دست، تفاوت های ماهوی و سختی و پرخطر بودن تولید نرم افزار را نسبت به سایر تولید های صنعتی نشان می دهد. نتایج یک تحقیق که در سال 2000 انجام شده است نشان می دهد که تنها 28 درصد پروژه های نرم افزاری موفق بوده اند، 23درصد متوقف شده اند و الباقی (یعنی 49%) با مشکلات جدی نظیر تاخیر تحویل، افزایش بودجه و یا عدم برآورده کردن نیازها مواجه بوده اند.
این مشکل است، اما راه حل کجاست؟ طبیعی است در "مدیریت پروژه"! (G.stepanek, 2005)
2-2 متدولوژی و ضرورت توجه به آن
چنانچه بیان نمودیم، یکی از علل اساسی بحران نرمافــزار عدم وجود روش های مناسبی برای توسعه نرمافزار است. با توجه به این مقدمه ضرورت روی آوردن به یک متدلوژی مدون که تا حد زیادی مشکلات فوق را برطرف نماید نظر بسیاری از دستاندرکاران تولید سیستم های نرم افزاری را به خود جلب نموده و در نتیجه متدولوژیهای گوناگون ارائه گردیده است. متدولوژی عبارت است از فرایندی منظم برای تولید مجموعه ای از متدها که در تمام چرخه حیات سیستم نرمافزاری اعمال شده و بر یک نوع نگرش کلی درباره جهان نرمافزار متکی باشند. توجه داشته باشید که تعریف ذکر شده از واژه متدلوژی با تعریف آن در علم و فلسفه تفاوت می نماید. در واقع اینجا مقصود از متدولوژی توسعه نرم افزار است.یک متدولوژی توسعه نرم افزار باید حداقل هفت ویژگی زیر را داشته باشد:
1. ارائه تعاریفی از مفاهیم اولیه بکاررفته در متدولوژی: در واقع، دیدگاهای اصلی یک متدولوژی درباره روش حل مسئله باید روشن باشد . مثلا برای ایجاد یک ساختمان باید مولفههای بکاررفته در آن مانند آجر و آهن تعریف شده باشد. مثال دیگر، هنگامی که متدولوژی شی گرایی نرمافزار را بعنوان مجموعه ای از اشیاء مستقل که با یکدیگر به صورت هوشمندانه همکاری می نماید تلقی می کند، باید بتواند تعریف روشنی از شی ارائه نماید.
2. ارائه مدلی برای فرایند تولید: مدل فرایند31 تولید عبارت از الگوی توسعه نرم افزار است. بعبارت بهتر، مدل فرایند گامهای لازم برای توسعه نرمافزار (همان نحوه و ترتیب استفاده از متدها) و چگونگی انتقال از یک گام به یک گام دیگر را بیان می نماید. انتظار می رود بین متدولوژی و فرآیند تولید سنخیت و سازگاری وجود داشته باشد. برای مثال متدولوژی ساختیافته که نرمافزار را به صورت مجموعهای از گامهای متوالی تعریف مینماید با فرایند تولید"آبشاری" که توسعه نرمافزار را به تعدادی مرحله متوالی(که هر کدام باید خاتمه یابد تا دیگری شروع نماید) تقسیم نموده یک سازگاری وجود دارد. در حالیکه ذات متدولوژی شیگرایی که بر مفهوم "کلاس" متکی بوده با یک فرایند تولید متکی بر تکرار و توسعه افزایشی بیشتر سازگار است. چرا که فرایند کشف کلاس های یک مسئله خود فرایند تکراری و تدریجی می باشد.
3. داشتن مدل زیربنایی(مدل معماری): مشخص نمودن مراحل لازم برای ساختن یک ساختمان امر ضروری است ولی وقتی می توان گفت که این عمل موفق است که بدانیم چه نوع ساختمانی می خواستیم ایجاد نماییم و آیا این ساختمان ایجاد شد یا نه؟ در نرمافزار نیز همینطور است یعنی یک متدولوژی علاوه بر معرفی فرایند تولید باید بتواند توضیح دهد که نرمافزار ساخته شده با این متدولوژی چگونه خواهد بود؟ یعنی ساختارکلی سیستم و نحوه ارتباط مولفههای سیستم با یکدیگر و روشهایی که این ساختار را قادر به تامین کلیه ویژگیهای کلیدی سیستم میسازد که همان معماری نرمافزار است.
4. ارائه یک شیوه علامتگذاری استاندارد32: وجود یک شیوه علامتگذاری استاندارد که با رعایت آن مدلهای گوناگون تولید میشوند برای یکنواختی درک همه دستاندرکاران تلید از سیستم در حال تولید ضروری می باشد.
5. معرفی تکنیکهایی برای پیادهسازی متدولوژی: مقصود همان معرفی روشهی مختلفی است که در مراحل تولید باید اعمال گردند. اهمیت این روشها در چند نکته نهفته است: اولا روشها یک نوع نظم در فرایند ایجاد سیستمهای نرمافزاری پیچیده را بوجود میآورند. همچنین بوسیله روشها، فرآوردههایی تولید شده که بعنوان وسایل ارتباطی بین افراد تیم عمل نمایند و بالاخره بوسیله این روشها میتوان در طول زمان تولید معرفی نمود که در آن مدیریت روند پیشرقت پروژه را ارزیابی کرده و خطرات بالقوه را کنترل می نماید.
6. ارائه معیارهای برای ارزیابی نتایج حاصل از بکارگیری متدولوژی33 : یک متدولـوژی باید معیارهایی در اختیار افراد تیم قرار دهد که بوسیله آن میتوان درباره درستی یا نادرستی نحوه بکارگیری متدولوژی در یک پروژه قضاوت نمود. مثلا از یک متدولوژی شیگرایی انتظار میرود که معیارهای برای مقایسه بین دو مدل کلاس یا تعیین میزان قابلیت استفاده مجدد از یک مولفه را معرفی نماید. وجود این معیارها میتواند بحث استانداردپذیری و قابلیت اعتماد و کارایی را گسترش دهد.
7. وجود ابزار اتوماتیک برای کمک به تولید و اجرای مدلهای مبتنی بر متدولوژی34: این ویژگی جزو متدولوژی نیست ولی برای تضمین بکارگیری کارا و صحیح و تسهیل در امر بهرهبرداری از آن ضروری می باشد.
با توجه به آشنایی نسبتا دیرینه بشر با روشهای مهندسی و اینکه مهندسی سختافزار با مشکلات مهندسی نرمافزار مواجه نشده است، این سوال مطرح میگردد که آیا استفاده از روشهای سنتی مهندسی و توسعه نرمافزار، مشکلات آنرا برطرف نمی سازد؟ درپاسخ بایدگفت که مسلما استفاده از روشهایی کـلی-که بشر تا به امروز شناخته- درکنترل پیچیدگی سیستم های نرمافزاری باید کارساز باشد. ولی این روشها بسیار کلی هستند. به عبارت دیگر اگر جزییات بکاربردن روش بخصوصی را نیز مدنظر داشته باشیم، خواهیم دید که در توسعه نرمافزار به عنوان یک محصول نهایی امکان استفاده از روشهایی است که در ساخت و تولید محصـــولاتی دیگری همچون سختافزار به کار برده میشود، مشکل خواهد بود اما بکارگیری این روشها بعنوان یک ایده در نظر سازندگان نرمافزار هنوز از جلوه خاص برخوردار بوده و زمینه چالش در این مورد فراهم مینماید. (پرسمن, 1382)
2-3 تفاوت روش توسعه نرم افزار و سخت افزار
فرآیند توسعه نرم افزار یک فرایند مهندسی است نه یک فرایند ساختن سنتی. برای بیان تفاوت این دو فرایند باید گفت، در سختافزار می توان باساخت قطعاتی مانند آی سی های استاندارد و مجتمعسازی آنها به محصول نهایی دست یافت که خود حاصل انجام یک فرایند اتوماتیک است. این همان فرایند تولید سنتی است. در مقابل، در توسعه نرمافزار امکان ساخت فیزیکی محصول بر اساس محصولات موجود کوچکتر از طریق سرهم بندی آنها بسادگی وجود ندارد بلکه برای دستیابی به محصول نهایی نرمافزار لازم است یک فرایند مهندسی که برای هر کاربرد جدید منحصر به فرد است را دنبال نمود. این مساله از متفاوت بودن طبیعت نرمافزار بعنوان یک محصول منطقی که بیشتر زاییده فکر انسان بوده در مقابل سختافزار بعنوان یک محصول فیزیکی که مواد اولیه موجود در آن تابع قوانین فیزیکی مشخصی است، ناشی می شود. از سوی دیگر، نرمافزار فرسوده نمی شود، بلکه فاسد میشود . در هنگام تولید یک قطعه سخت افزاری ممکن است مشکلات بیشماری بوجود آید، اما پس از تولید یک نمونه از محصول سختافزاری می توان آن را به تولید انبوه رساند. مدت زمانی که طول میکشد تا یک قطعه سختافزاری فرسوده شود بسته به جنس قطعات بکار رفته در قطعه است و تولید کننده محصول سختافزاری می تواند عمر مفید آن را بصورت تقریبی حدس بزند.
پس از پایان عمر مفید یک قطعه سختافزاری احتمال اینکه این قطعه دچار مشکل و عملکرد نادرستی از خود به نمایش بگذارد، افزایش می یابد تا جاییکه که قطعه کاملا فرسوده می شود این موضوع در شکل(2-1) نشان داده شده است. اما در نرم افزار اینگونه نیست، نرم افزار می تواند مدت ها به کار خود ادامه دهد و هیچگاه فرسوده نمی شود زیرا به جنس قطعات بکار رفته در آن بستگی ندارد. نرم افزار می تواند سالها به کاربر خود جواب دهد و نیاز های کاربران را تامین نماید. اما با پیشرفت تکنولوژی و تغییر نیازمندی های کاربران نرم افزار کهنه میشود و دیگر جوابگوی نیاز کاربران نیست هرچند هنوز هم می تواند کار کند. بنابراین نرم افزار همانند سختافزار دچار فرسایش نمی شود بلکه کهنه یا فاسد میشود.

شکل(2-1): منحنی نرخ خرابی سختافزار نسبت به زمان

با نکاتی که ذکر گردید، نرم افزار بر خلاف سختافــزار دارای فرسودگی نیست و منحنی خرابی نرمافزار ایدهآل همانند آنچه در شکل2-2 نشان داده شده است.

شکل(2-2): منحنی نرخ خرابی ایدهآل نرمافزار نسبت به زمان

نکته جالب توجه این است که خرابی نرم افزار از منحنی خرابی ایدهآل تبعیت نمیکند، بلکه با توجه به تغییر نیازمندیها و اصلاح نرمافزار برای پوشش این تغییرات، خرابی نرمافزار از منحنی شکل2-3 تبعیت می نماید.

شکل(2-3): منحنی نرخ خرابی ایدهآل نرمافزار نسبت به زمان

در سالهای اخیر با توجه به دستیابی به فناوری های نوین در توسعه سختافزار نسبت به سالهای اولیه ظهور کامپیوتر، نرخ رشد هزینه های نرمافزار به سختافزار افزایش چشمگیری داشته است. بطوریکه در سالهای 2005 نسبت هزینه سخت افزار به نرم افزار یک به 5 برآورد شده است.

شکل (2-4): رشد هزینه نرم افزار به سخت افزار

به دلیل این تفاوت ذاتی بین نرمافزار و سختافزار پیچیدگی های خاصی در ابعاد مختلف از جمله در تعریف نرم افزار،طراحی، پیادهسازی، تست و نگهداری آن وجود دارد که لازم است از ابزاری و روشهایی برای مقابله با این پیچیدگیها استفاده نمود. در این راستا متدولوژی های مختلف، هریک روشهایی و ابزار خاصی را برای کنترل و فائق آمدن بر این پیچیدگی مطرح نمودهاند . (شمس, 1387)
2-4 فرایند توسعه نرم افزار
در ساخت یک سیستم نرم افزاری سه فرآیند مهم تاثیر گذار می باشند:
* فرآیند توسعه35: سازماندهی فعالیت ها است برای ساخت یک سیستم
* فرآیند مدیریت36: انتخاب افراد، تجهیزات و فرآیند هاست برای توسعه یک سیستم و کنترل و نظارت بر روند اجرای پروژه (مدیریت پروژه)
* فرآیند پشتیبانی37: کنترل و پشتیبانی نرم افزار پس از تولید آن
در این بین در فرآیند توسعه هدف آن است که یک سیستم با مشخصات خواسته شده تولید شود و بنابراین برای تولید هر نوع سیستم متفاوت است.فرآیند توسعه از مرحله طرح یک راه حل مفهومی برای مساله خواسته شده (امکان سنجی) آغاز شده، پس از دریافت خواسته ها و تحلیل سیستم طراحی صورت گرفته و در نهایت این طراحی با کمک ابزارهای پیاده سازی تبدیل به یک سیستم واقعی می شود. هدف این فرآیند آن است که از یک سو برآورده ساختن نیازهای کاربران و از سوی دیگر کیفیت مناسب عملکرد سیستم تضمین گردد و بنابراین بایستی حاوی مکانیسم هایی برای اعتبار سنجی: خروجی مطابق با خواسته ها 38 و وارسی پذیری: صحت عملکرد خروجی 39باشد. فرآیند توسعه ضمن دادن آزادی به تحلیل گر باید تضمین کند که زمانبندی رعایت شود.
2-4-1 مدلهای توسعه نرم افزار
روشهای مختلفی برای فرآیند توسعه سیستم وجود دارد که در این میان می توان گفت روشهای زیر مطرحتر از همه هستند که عبارتند از:
* ساده ترین روش40: تبدیل فرآیند توسعه سیستم در قالب دنباله ای از وظایف مشخص و ترسیم یک نمودار از تمام فعالیت ها
* فرایند توسعه خطی: 41به ترتیب مراحل انتخاب پروژه، تعریف مفهومی (تعریف مساله، امکان سنجی) ، تعریف مشخصات (خواسته ها ، تعریف مساله) ، طراحی (طراحی معماری، تفصیلی) ، توسعه (ساخت سیستم، تست ، ارزیابی و درنهایت تعریف پروژه جدید) این روش برای پروژه های کوچک کاراست که در آن تعریف صورت مساله به راحتی انجام می گیرد.
* مدل آبشاری42 : مدل آبشاری ساده است. در پروژه های بزرگ، مدت زمان انجام پروژه طولانی است و بنابراین نیازها تغییر می یابد. لذا بدیهی است از این مدل در پروژه های بزرگ استفاده نگردد. تقسیم وظائف توسعه سیستم در قالب یک مدل آبشاری از تعریف مساله، امکان سنجی، تحلیل (سیستم، خواسته ها)، طراحی ، پیاده سازی و تست ، یکپارچه سازی و تست، نصب و تست ، نگهداری و مرور , با امکان برگشت از یک مرحله به مرحله قبل. مشکلات این روش عبارتند از: 1- برگشت به عقب 2- عدم بیان نیازها توسط مشتری 3- منتظر ماندن طولانی مدت مشتری(در این مرحله در ابتدا با مشتری ارتباط برقرار کرده و بعد از دریافت نیازهای مشتری برای مدت طولانی با مشتری تماس نداریم.
* توسعه مرحله ای، افزایشی و یا نموی 43: تقسیم یک مساله به مسائل کوچکتر و انجام هر زیر سیستم (مساله کوچکتر) و انجام هر یک به صورت جداگانه و در صورت امکان اجرا به صورت همزمان. در هر مرحله مدل از مرحله قبل کاملتر می گردد در نسخه بعدی امکانات جدیدی به نسخه قبلی اضافه می گردد. حسن این روش در این است که در عین روش نمونه سازی نسخه ها دور ریخته نمی شود و نرم افزار بروز می گردد به طوری که هزینه کمتری در بر داشته باشد. و عیب آن، زمانی استفاده می گردد که یا نیروی انسانی متخصص و یا سخت افزار کافی در اختیار نباشد.
* الگو سازی 44 :ایجاد یک الگو برای کاربران برای اینکه درک بهتری از سیستم داشته باشند و درنهایت پیاده سازی سیستم بر اساس این نمونه. به نوعی تولید مجدد محسوب می گردد(دوباره کاری). مزایای این روش بر این است که در تمام طول کار با مشتری ارتباط برقرار است و تغییر نیازها امکان پذیر است. و عیب این روش بر این است که مشتری کل نرم افزار را نمی بیند و ملاحظات کلی از نرمافزار را نمیتواند داشته باشد مثل قابلیت نگهداری، همچنین، تغییر زاید ممکن است باب میل مشتری نباشد و همینطور سرعت انجام کار باعث اثرات جانبی میگردد.
* توسعه سریع سیستم:45 این روش تاکید بر تولید سریع نرمافزار است که در هر قسمت مشابه روش خطی و یا هر مدل دیگر استفاده می شود. ادغام برخی مراحل با یکدیگر و استفاده از زبانهای نسل چهارم برای توسعه سیستم (مراحل: برنامه ریزی، طراحی و تست). تاکید در این مدل تولید نرم افزار در عرض 90 روز می باشد. در این روش سیستم در قالب کارکردهای(ماژولها) مختلف شکسته میشود و تیمهای مختلف همزمان روی هریک ازآنها کار میکنند و نتیجه کار با هم ترکیب میشود. مشکل این روش مدیریت پیچیده، در سیستمهایی میتوان از ازین روش استفاده کرد که ماژولار باشند، در پروژههای بزرگ نیاز به افراد زیادی است، عدم اطمینان مناسب از تعهد کاری افراد در تیم. مزیت این روش توسعه در زمان کوتاه و تاکید بر قابلیت استفاده مجدد46 آن است.
* طراحی تکاملی به صورت حلزونی و یا مارپیچی47: توسعه سیستم به صورت افزایشی به صورت بازگشتی48 صورت میگیرد. در این مـــدل فعالیت های مربوط به مهندسی نرم افزار به شش زمینه کاری تقسیم میشود که عیارتند از: 1-ارتباط با مشتری49 (قراردادها و کل توافقات انجام میگیرد و اطلاعات جمعآوری میشود). 2- برنامه ریزی50 (بر اساس نتایج بدست آمده از شناخت کلان، اعضای تیم شناسایی و تیمهای کاری تشکیل و برای هر تیم تخصیص کار شده و برنامه کنترل و نظــارت بر پروژه را تدوین میکنیم ). 3-تحلیل ریسک51 (پیش بینی مخاطرات غیرمنتظره مثل تغییرات تکنولوژی سختافزار و نرمافزار، عدم تعهد بعضی از افراد، تغییرات مدیریتی، تغییر خواسته مشتری(عوامل محیطی) و … که این تغییرات باعث ایجاد تغییر در برآوردهای هزینه و زمان می گردند که در واقع یک هزینه ریســک محسوب می شود). 4-مهندسی و طراحی52 (فعالیت موردنیاز برای طراحی و ساخت نمونههایی از برنامه کاربردی). 5-ساختو تحویل53 (برنامه نویس، پیاده سازی، تست و کنترل کیفیت). 6-ارزیابی مشتری54. حسن این روش آن است که در هر دور تحلیل ریسک را انجام می دهیم که کیفیت نرم افزار تولید شده بیشتر می گردد و تعداد دورهای این روش به توافق با مشتری و هزینهایی که پرداخت میکند بستگی دارد همچنین مدیریت پروژه بهتر خواهد بود.
* توسعه سیستم مبتنی بر مولفه ها55: این مدل برنامه ها را با استفاده از ترکیب و سرهم کردن قطعات نرمافزاری از پیش ساخته شده و از پیش بسته بندی شده56 میسازد. این مدل از بسیاری از خصوصیات روش حلزونی استفاده می کند . این مدل، از نظر ماهیت، مدل تکاملی است و ساختاری تکرارشونده را برای توسعه نرمافزار درپیش میگیرد. از جمله مزایای استفاده مجدد در نرمافزار عبارتند از: 70% کاهش زمان توسعه، 84% کاهش هزینه پروژه و شاخص تولید 2/26 می باشد.
* توسعه همزمان 57 : توسعه به صورت یک فرآیند سیستماتیک و مرحله بندی و لیبل گذاری هر بخش در هر مرحله. تقسیم سیستم به بخش های مختلف و تقسیم نیروها در بین پروژه های مختلف برای اجرای این بخش ها به صورت همزمان. در حالت موازی، زمان کاهش می یابد ولی ممکن است بعضی پارامترهای دیگر مثل دوبارهکاری و مدیریت پروژه و … افزایش یابد. این مدل معمولا برای توسعه کاربردهای مشتری/کارگزار58 استفاده میشود که این مــدل را در دو جنبه میتواند منجر به موازی سازی کارها گردد:1- فعالیتهای اجزای سیستم، که هر فعالیت دارای وضعیت خاص خود است و همه به صورت همزمان اجرا میشوند و 2-هر سیستم مشتری/کارگزار از اجزای زیادی تشکیل میشود که آنها را میتوان به صورت موازی به هم توسعه داد. مدل فرآیند همزمان در توسعه تمامی انواع نرمافزارها کاربرد دارد و همچنین در این مدل بجای تعریف ترتیبی از واقعی در فعالیتهای مهندسی نرمافزار شبکه ای از فعالیتها خواهیم داشت.
* روشهای فرمال59 : بکارگیری مدل ها و مفاهیم ریاضی در توسعه سیستم نرمافزاری.(طراحی مدل ریاضی است) با این مدل می توان خطاهای زیادی را که در زمان اجرا غیرقابل تشخیص هستند در مراحل اولیه برطرف نمود. یکی از مهمترین جنبه های استفاده از این روشها در ساخت سیستمهای حساس و امن است همانند ساخت نرمافزارهای کنترلی هواپیما و ابزار پزشکی. مزایا عبارتند از: بدیع، سازگار، بدون ابهام و … با توجه به اینکه این مدل فرایندی عاری از خطا را ارئه می کند اما دارای معایبی نیز هست از جمله: وقتگیر و پرهزینه، کاربرد محدود، نیاز به آموزش جامع،مشکل ارتباط با مشتری و … است.
* روشهای نسل چهارم60: بگارگیری از ابزارهای گرافیکی و ابزارهای مهندسی نرم افزارمحدودهی وسیعی از ابزارهای نرم افزاری است که قادر به تعیین و مشخص کردن بعضی از خصوصیات و ویژگی های نرم افزار در سطح بالاست و میتواند کدی بر مبنای مشخصات تولید شده بطور اتوماتیک ایجاد نماید. مزایای آن عبارتند از: 1- قابلیت استفاده برای مستند سازی 2- قابلیت استفاده برای مدلسازی سیستم 3- قابلیت تولید گزارشات 4- قابلیت استفاده آسان از امکانات محیط برنامه سازی 5- قابلیت مدیریت آسان پایگاهدادهها و عیب آن: تکنیکها و ابزارهای موجود در حال حاضر خیلی عام نیست و دارای کاربردهای خاص است. ترکیب این مدل با روش توسعه مبتنی بر اجزا روش بسیار قوی و غالب را در توسعه نرمافزار ایجاد خواهد کرد.
* با اضافه کردن مفاهیم برنامه سازی شی گرایی (OOP) به روش حلزونی و تبدیل به صورت موازی بازگشتی61 : شیء گرایی لغتی است که امروزه در صنعت نرم افزار باب شده است. شرکتها به سرعت حرکت می کنند تا خود را با این تکنولوژی جدید سازگار کنند و آن را در برنامه های موجود خود وارد نمایند در حقیقت بیشتر برنامه ها امروزه با شی گرایی توسعه می یابند، اما شئ گرایی به چه معنا است؟متد شئ گرایی (O.O ) یک راه متفاوت مشاهده برنامه هاست. با شئ گرایی شما یک برنامه را به قطعات بسیار کوچک یا Object هایی تقسیم می کنید که تا اندازه ای مستقل از یکدیگر باشند.تفاوت متد شئ گرایی با روش سنتی توسعه چیست؟در روش سنتی، روش توسعه به همراه اطلاعاتی که سیستم نگهداری خواهد کرد به خودمان وابسته است، بعبارت دیگر ما بر روی اطلاعات متمرکز می شویم و کمتر توجه می کنیم که چه کاری با این اطلاعات انجام شده است یا رفتار سیستم چگونه است این روش (Data-Centric ) مبتنی بر داده نامیده شده است متد شئ گرائی در پاسخ به مشکلات این روش ایجاد شده است. با متد شئ گرایی هم بر اطلاعات و هم بر رفتار متمرکز می شویم در نتیجه با این روش می توانیم سیستم هایی را ایجاد نماییم که انعطاف پذیر شده و یا اطلاعات و یا رفتار را تغییر دهند. فرمت این انعطاف پذیری با طراحی یک سیستم شئ گرایی به خوبی شناخته شده است . انجام این متد به شناخت تعدادی از اصول شئ گرایی نیاز دارد (اس.پرسمن, 1382).
2-4-1-1 اصول شئ گرایی
1. کپسوله سازی62: در یک سیستم شیء گرایی اطلاعات و رفتارها را در یک Object بسته بندی می کنیم . این مطلب در قالب اطلاعات پنهان سازی ارجاع داده شده است .یکی از مزایای پنهان سازی این است که تاثیرات اعمال شده به سیستم را محدود می کند.
2. وراثت63: دومین مفهوم اساسی شئ گرایی می باشد .در سیستم های شئ گرایی وراثت به شما اجازه می دهد تا Object های جدید را بر پایه Objectهای قدیمی ایجاد کنید.یکی از مزایای وراثت سهولت در نگهداری است.
3. چندریختی64 : سومین اصل شئ گرایی چند ریختی است، چند ریختی به این معنی است که شکلها یا پیامدهای زیادی از یک تابع ویژه را داشته باشیم . در واقع در یک سیستم شئ گرایی ما می توانیم بسیاری از رخدادها یا پیامدهای یک عمل ویژه را داشته باشیم.
یکی از دسته بندی های مرسوم متدولوژی های شی گرا :
* متدولوژی های اولیه65:در متدولوژی های اولیه که engineering methodologies یا plan-driven methodologies نامیده می شوند، هدف جداسازی کامل طراحی از ساخت و ایجاد یک طرح و زمان بندی دقیق و قابل پیش بینی است که قابل استفاده توسط افراد با توانایی های کمتر باشد. این روش ها کاملا موفق نبوده اند. بزرگترین مشکل بروکراتیک بودن آنهاست. برای پیروی از متدولوژی ها جزئیات زیادی باید دنبال شود که منجر به کند شدن روند تولید می گردد.
Shlaer-Mellor ، Coad-Youdon ، RDD ، Booch ، OMT ، OSA ، OOSE ، BON ، Hodge-Mock ، Fusion ، Syntropy

* متدولوژی های مجتمع شده66: متدولوژی های ساخت یافته ، طی سال ها برای انجام انواع پروژه ها مورد استفاده قرارگرفته بود.مهمترین مشکل این متدولوژی ها ،پیاده سازی آن در محیط واقعی و دنیای شی گرا است و مشتری تا انتهای کار، نمی تواند نسخه عملی و کاربردی از سیستم را ببیند. در RUP که مبتنی بر تحلیل و طراحی شیء گراست ، دوره زندگی یک نرم افزار به چندین سیکل شکسته می شود کـه هـر سـیکل بـر روی یک نسل جدید از محصول کار می کند و در طول پروژه چندین نسخه از محصول را مشاهده کرده و درباره آن نظر می دهد .مهمترین مزیت تکراری و تکاملی بودن RUP کاهش ریسک انجام پروژه است ، چرا که ریسک ها در ابتدای پروژه شناسایی شده و تیم درصدد رفع آن بر می آید و از این جهت برای پروژه های بزرگ و با امکان ریسک بالا مناسب است، البته برای پروژه های کوچک نیز می توان آن را سفارشی کرده و مورد استفاده قرار داد.

OPM، Catalysis ، OPEN ، RUP/USDP ، EUP ، FOOM

* متدولوژی های چابک67:روش های agile تطبیقی هستند و نه قابل پیش بینی. روش های plan-driven می کوشند کل پروسه تولید را با جزئیات کامل، برای مدت طولانی طرح یزی نمایند. این روش تنها تا زمانی که تغییراتی پدید نیامده کاراست. ذات این متدها در مقابل تغییرات مقاوم است. در حالی که agileاز تغییرات استقبال کرده و می کوشد که سیستم و حتی روند تولید را تطبیق دهد. – agile، people-oriented است و نه process-oriented
DSDM ، SCRUM ، XP ، ASD ، Xd ، Crystal ، FDD
* مدل سازی بصری68: پردازش گرفتن اطلاعات از مدل است و آن را با استفاده از مجموعه ای از عناصر گرافیک استاندارد به صورت گرافیک نمایش می دهد. یک استاندارد ضروری برای فهمیدن یکی از مزایای مدل سازی بصری، ارتباطات است. هدف اصلی مدل سازی بصری ارتباط میان کاربران، برنامه نویسان، تحلیلگران، آزمایش کننده ها، مدیران و هر شخص دیگری که با یک پروژه درگیر شده است می باشد. با یک مدل بصری می توانیم نشان دهیم که چگونه سیستم روی چند سطح کار می کند ما می توانیم فعل و انفعالات بین کاربران و یک سیستم را مدل نماییم.یک موضوع مهم در مدل سازی بصری این است که از چه نهاد گرافیکی برای نشان دادن چهره های مختلف یک سیستم استفاده می شود.تعدادی نهاد برای مدل سازی بصری وجود دارد. بعنوان مثال Booch ، OMT ، UML می باشند.
2-4-2 مقایسه متدولوژی های سنگین وزن و سبک وزن
در حالت کلی متدولوژی های توسعه ی نرم افزار به دو دسته تقسیم می شوند :
* متدولوژی های سنگین وزن69: محور اصلی متدولوژی های سنگین وزن مانند RUP برنامه ریزی جامع و مستند سازی از ابتدا تا انتها وطراحی کامل و گسترده می باشد. به عبارتی روشهایسنگین وزن بصورت پیشگویانه یا Predictive عمل می کنند یعنی در آغاز همه چیز را پیش بینی می کنند.
* متدولوژی های سبک وزن70 که شامل روشهای چابک71 نیز می شوند: مسلما در ابتدای فازهای تحلیل به دلیل تغییر نیازها نمی توان همه چیز را پیش بینی کرد بنابراین متدولوژی های سبک وزن بوجود آمدند. تمرکز این روش ها بیشتر بر روی سادگی و سرعت است . این متدولوژی ها را می توان با توجه به معیارهای زیر در یک جدول مقایسه نمود :
جدول(2-1): مقایسه متدولوژی سنگین وزن و سبک وزن
روش های سنگین
روش های چابک
معیار مقایسه
پیشگویانه
سازگار
روش
بزرگ
کوچک
اندازه پروژه
استبدادی
آزاد وغیر متمرکز
مدیریت
سنگین
محدود و بسته به نیاز پروژه
نحوه مستندسازی
محدود
متعدد
چرخه های توسعه
تطبیق با طرح اولیه
ارزش کاری
معیار موفقیت
بزرگ
کوچک
اندازه تیم
فقط در انتهای پروژه
سریع ودر طول پروژه
برگشت سرمایه
فرآیندهای از پیش تعیین شده
مشتری مداری
تاکید بر

با توجه به تعدد روشها و مدل های فرآیند توسعه باید در یک پروژه انتخاب صورت بگیرد. این انتخاب بر اساس موارد زیر می تواند باشد:1-درجه ساختاری سیستم2-آشنایی با فنآوری3- اندازه پروژه
برای مثال چرخه های خطی برای پروژه های آسان و ساختیافته و یا زمانی که با فنآوری کاملا آشنا هستیم مناسب می باشند و برای پروژه های بزرگ و ناشناخته روشهای افزایشی بهتر می باشند.اما نمی توان انتظار داشت یک گروه تولید کننده نرم افزار در هر پروژه یک معیار را انتخاب کند. چون این کار بسیار هزینه بر است و به لحاظ مختلف ناصواب. دلایل انتخاب یک روش استاندارد برای یک تیم و استفاده در همه پروژه ها آنست که:
* طراحان برای یادگیری تکنیک های جدید وقت زیاد تلف نمی کنند.
* مستند سازی بهتر صورت می گیرد
* کاهش هزینه آموزش کاربران سیستم ها

2-4-3 فعالیت های پشتیبانی72
فعالیتهای پشتیبانی در کلیه مراحل تعریف، توسعه و نگداری سیستم انجام می گردد:
1. کنترل و نظارت بر برنامه ریزی پروژه
2. بازنگری های مستمر فنی و رسمی73
3. اطمینان مرغوبیت نرم افزار(شامل تمام مراحل)74
4. مدیریت پیگربندی نرم افزار75
5. تهیه و تدوین مستندات
6. اندازه گیری(مقیاسهای اندازه گیری)76
7. مدیریت ریسک(پیامدهایی که برآورد زمان و هزینه را تغییر دهد) 77

فصل 3
" تخمین تلاش نرم افزار"

فصل سوم: تخمین تلاش لازم جهت توسعه نرم افزار
در این فصل به بیان مفاهیم اساسی تخمین هزینه پرداخته میشود، مجموعه مفاهیمی که به عنوان پایه در فصل بعد مورد استفاده قرار میگیرد. از جمله به تعریف تخمین، تخمین هزینه نرمافزار، عوامل موثر در مسئله تخمین، انواع روشهای تخمین هزینه اعم از نوین و سنتی و روشهای الگوریتمی و غیر الگوریتمی موجود میتوان اشاره و ارزیابی کرد.
3-1 مقدمه
دقت برآوردنرم افزاریکی ازدشوارترین کارها برای توسعه دهندگان نرم افزاراست. برآورد هزینه نرمافزار برآوردمیزان احتمالی از سطوح تلاش،مدت زمان ونیروی انسانی مورد نیازبرای ایجاد یک سیستم نرمافزاراست. دقت برآورد تلاش لازم جهت توسعه نرم افزارهمیشه کار دشواری بوده برای هردو، توسعه دهندگان نرم افزارو مشتریان درگیر درتوسعه است.شاخص ترین شکل برآورد تلاش نرم افزار در مراحل ابتدایی ساخت پروژه است، از شروع در درجه اول ازامکان سنجی پروژه و اسناد و مدارک خصوصیات مورد نیاز. با این حال،برآوردتلاش دردر مراحل اولیه توسعه سخت ترین کار برای به دست آوردن است و اغلب آنها کمترین دقت را دارند، زیرا جزئیات بسیار کمی در موردپروژه واندازه محصول، طول مدت توسعه وامکانات مورد نیازدرشروع آن شناخته شده است (S. Sandhu, P. Bassi, 2008) . درسال های اخیر،توسعه پروژه های نرم افزاری در مقیاس بزرگ در حال کسب طیف گسترده ای ازمنافع است (Bailey, J. W. and V. R. Basili, 1981). برآورددقیق تلاش نرم افزارمیتواندکمک های قدرتمند برای تصمیم گیری های مدیریت نرم افزارفراهم می کند. مدیر پروژه به طور قابل توجهی نیاز به شناسایی برآورد هزینه دارد،به طوری که او می تواند پیشرفت پروژه را ارزیابی واستفاده بهتری از منابع را داشته باشد (Boehm, 2000). مشخص شد که برآوردکننده اصلی هزینه،تاثیر عمده ای بر برآورد هزینه نرم افزار داشته است. عنصر اصلی تاثیرگذار بر تخمین تلاش خطوط توسعه یافته ازکد(DLOC) است. DLOCشامل تمامی دستورالعمل ها وعبارات صوری برنامه است. (B.Boehm, 1981)
امروزه، بسیاری ازمدل های برآورد هزینه نرم افزارتوسعه داده شده است. بسیاری از این مدل هادراندازه گیری اندازه،از جمله خط های کد(LOC)و عملکردنقطه(FP) است. کاملا واضح استکه دقت برآورداندازه تاثیر مستقیم را بردقت برآورد هزینه دارد.با توجه به این زمینه،روش های جایگزین جدید الگوریتم های تکاملی ازقبیل الگوریتم ژنتیک باینری می تواند یک انتخاب خوب برای برآوردتلاش کاردر توسعه نرم افزار باشد.
3-2 مفهوم تخمین هزینه
تعریف کلی که برای تخمین ارائه شده است عبارتند از:" تهیه یک تقریب یا برآورد از هزینهها ،منابع و زمان مورد نیاز برای انجام یک پروژه". (لاودن جین پرایس، مترجم رضایی نژاد, 1377)
عوامل گوناگونی وجود دارند که بر عدم قطعیت تخمین تاثیر دارند. یکی از این عوامل ،پیچیدگی نرمافزار است. اما پیچیدگی یک میزان نسبی است که از آشنایی با کارهای قبلی تاثیر میپذیرد. سازندهای که برای اولین بار یک برنامه کاربردی پیچیده جهت تجارت الکترونیکی میسازد،ممکن است اینکار برایش بسیار پیچیده باشد. ولی تیمی که دهمین مورد از یک سایت وب تجارتی را میسازد، اینکار برایش بسیار آسان است. یکی از عوامل تاثیرگذار بر صحت برآوردها، اندازه پروژه است . برای تعیین اندازه از دو واحد ،شمارش تعداد خطوط کد و یا محاسبه نقاط تابعی استفاده میشود.
3-3 تخمین هزینه نرمافزار
در یک تعریف جامع میتوان مسئله تخمین هزینه را به این صورت بیان نمود که: تخمین هزینه، فرآیند تخمین تلاش مورد نیاز برای توسعه و ساخت سیستم نرم افزاری میباشد.تخمین دقیق هزینه مهم است زیرا:
– برای تعیین منابع پروژه و اینکه چگونه این منابع استفاده شوند بکار میرود.
– برای طبقهبندی و اولویتبندی پروژههای تحت توسعه کمک میکند.
– کنترل و مدیریت پروژه ها آسانتر است زمانیکه منابع با نیازهای واقعی هماهنگ شوند.
امروزه سرمایه گذاری اصلی و عمده بسیاری از سازمانها روی توسعه نرمافزار متمرکز شده است. مدلهای دقیق و درست پیش بینی و برآورد هزینه نرم افزار، نیازمند یک پیش بینی موثر و کارا، کنترل و ارزیابی توسعه و بسط نرمافزار هستند. و یکی از مهم ترین مراحل در توســعه نرمافـزار، تخمین هزینه نرمافزار است که بیانگر میزان تلاش مورد نیاز برای توسعه سیستم است که به صورت نفر-ماه اندازه گیری میشود.
3-4 انواع تخمین
تخمین احتمالاً ابتدایترین روش " اندازه گیری " میباشد . مردم همیشه از تجربه گذشته خود برای پیشبینی حوادث آینده استفاده میکنند . هرچند طبیعی است . تخمینهای ساده جهت برنامهریزی و کنترل موثر نمیتوانند قابل اطمینان باشند . دقت تخمین به تجربه تخمین زننده در زمینهای که او در حال تخمین است، بستگی دارد .
* تخمین ساخت یافته 78
روشهای تخمین ساختیافته ، تلاشی برای استفاده از این واقعیت تجربی و در عین حال وارد نمودن ساختار و انضباط برفرآیند تخمین میباشد، به نحوی که نتایج حاصله از آن را بتوان با اطمینان استفاده نمود. مزایای تخمین به قرار زیر میباشد . (سامرویل, 1381) روشی ارزان است و بنابراین تنها روشی است که برای مشاغل یک بار تکرار مناسب میباشد . این روش میتواند برای پیش بینی زمانهای کاری که دیده نشده است و بنابراین به عنوان مبنایی برای تخمین قیمت برای کارهای یک بار تکرار بزرگ استفاده شود.
به طورطبیعی در مواردی که مقادیرزمانی با جزئیات زیاد مورد نیاز نمی باشند، تخمین قابل استفاده میباشد . بنابراین چنین روشهایی برای کار با سیکل طولانی و در موقعیت هایی که داده زمانی انباشته برای برنامه ریزی ، کنترل یا پرداخت در طول پریودهای طولانی مدت مورد نیاز است . مفید میباشد .
* تخمین تحلیلی 79
تخمین تحلیلی ، مجموعه تخمین ترتیب داده استاندارد میباشد . این تکنیک براین واقعیت استوار است که مشاغل را می توان به جزء متشکله آن تقسیم نمود و عناصر به طور مجزا قابل اندازهگیری یا تخمین میباشند. خطای این زمانهای منفصله تصادفی بوده و همدیگر را جبران میکنند به نحوی که زمان کل در محیط قابل قبول قرار خواهد گرفت. به طور مشابه هنگامی که تعدادی کار در طول یک زمان بزرگتر ترتیب میشوند ( مانند میزان کار یک هفته ) خطاهای منفصله در زمان های مشاغل ، تصادفی خواهد بود و همدیگر را جبران خواهند کرد به نحوی که زمان کل قابل قبول میباشد. بدیهی است تخمین توسط کارگری که درمحدوده کار مورد اندازهگیری باتجربه میباشد و در زمینه روشهای کار آموزش دیده، صورت میپذیرد. بنابراین تخمین زننده به صورت زیر عمل میکند. کار را به عناصر تقسیم می کند، داده استاندارد یا ترکیبی را به کار می گیرد ، عناصری که ارزش تلاش و صرف وقت دارند را مورد اندازه گیری قرار می دهد مابقی عناصر را با استفاده از تجربه خود و اطلاعات مربوط به شرایط کاری، عوامل ایمنی و مانند آن تخمین می زند . ممکن است زمان های عناصری که تخمین زده شده اند برای استفاده بعدی به صورت داده استاندارد نگهداری شوند. البته دراین حالت لازم است در فواصل مشخصی آنها را از نظر قابل قبول بودن مورد بررسی قرار داد.
* تخمین مقایسه ای80
تخمین مقایسه ای براساس شناسایی و اندازهگیری کارهای با محتوی کاری معین که سایر کارها را بتوان در مقایسه با آن اندازهگیری نمود استوار است. کارهای شاخص به نحوی انتخاب میشوند که نماینده کل محدوده کاری مورد نظر بوده و نشانگر نقاط متوسط مقیاس کل کار باشد. این مشاغل شاخص با دقت قابل قبولی توسط تکنیکهای اندازه گیری زمان سنجی میشوند . مرحله بعدی شناسایی نوارها یا شیارهای زمانی است که به کمک تحلیل آماری تعیین میشوند. حال شاید این سوال مطرح شود که در پروژههای نرمافزاری کدام نوع تخمین استفاده میشود .در پاسخ به این سوال باید گفت که روش تخمین تحلیلی در پروژه های ذکر شده کاربرد بیشتری دارد.
3-5 اندازه نرمافزار
یکی از مهمترین فاکتورها در تخمین هزینه یک سیستم نرم افزاری، اندازه و حجم آن است. برای تخمین اندازه یک سیستم نرم افزاری یکی از معیارهای زیر مورد استفاده قرار می گیرد :
3-5-1 تعداد خطوط کد81
تعداد خطوط کد منبع برنامهای است، که به کاربر ارائه می شود، به استثناء توضیحات و خطوط خالی که به LOC معروف است و از زبان برنامه نویسی مستقل است (اس.پرسمن, 1382). اندازه دقیق LOC پس از پایان پروژه مشخص می شود. یک روش معمول برای تخمین LOC، استفاده از تجربه به همراه تکنیک PERT میباشد. در این روش سه متغیر L برای کمترین اندازه ممکن، H برای بیشترین اندازه ممکن و M برای اندازه معمول کد برنامه در نظر گرفته میشوند. اندازه کد S از فرمول زیر تخمین زده میشود :
(3-1)

3-5-2 علم نرمافزار82
در این روش از معیارهای طول کد وحجم برای تخمین اندازه نرم افزار استفاده می شود (سامرویل, 1381). طول کد، برای محاسبه طول کد منبع برنامه است و با فرمول زیر محاسبه می شود :
(3-2)

که P تعداد کل عملگرها و Q تعداد کل عملوندها در برنامه است. حجم بیانگر میزان فضای مورد استفاده است و به شکل زیر محاسبه می شود :
(3-3)

3-5-3 نقاط کاری83
این روش تخمین براساس کاربرد نرم افزار میباشد. نوع داده های زیر در سیستم بررسی میشوند :
– نوع داده ورودی کاربر
– نوع داده خروجی برای کاربر
– پرس و جوهای انجام شده توسط کاربر
– فایل های داخلی سیستم
– فایل های خارجی (فایل هایی که با سیستم های بیرونی به اشتراک گذاشته شده و یا به آنها تحویل می شود)
به هر یک از انواع فوق یکی از کلاسهای پیچیدگی 1 (ساده )، 2 (متوسط)، 3 (پیچیده) و یک مقدار وزنی از 3 (برای نوع داده ورودی ساده) تا 15 (فایل داخلی پیچیده) اختصاص می یابد. مزیت این روش در این است که بر اساس نیازمندیهای سیستم و در همان گامهای اولیه پروژه قابل استفاده است. (K.Ramesh and P.Karunanidhi , 2013)
3-5-4 نقطه ویژگی84
این روش هم برنامه را به عنوان یک کلاس جدید به موارد پنج گانه در روش نقاط کاری اضافه میکند و آن را توسعه میدهد. به هر یک از الگوریتمهای استفاده شده وزنی از 1 (برای الگوریتمهای ساده) تا 10 (برای الگوریتمهای پیچیده) اختصاص میدهیم. این روش برای برنامههایی که ورودی و خروجی کم و پیچیدگی الگوریتمی بالا دارند مناسب است. (K.Ramesh and P.Karunanidhi , 2013)
3-6 روشهای تخمین هزینه
روش های تخمین هزینه نرم افزار به دو دسته کلی الگوریتمی و غیر الگوریتمی تقسیم می شوند :
3-6-1 روشهای غیرالگوریتمی
روشهای غیر الگوریتمی براساس مقایسههای تحلیلی میباشند. برای استفاده از روشهای غیرالگوریتمی یکسری از اطلاعات در مورد پروژههای قبلی که مشابه به پروژه تخمین زده شده، میباشند ،مورد نیاز است و معمولا فرایند تخمین در این روشها بر اساس تحلیل پایگاه دادههای قبلی انجام میشود. هیچ رابطه یا معادلهای در روشهای غیر الگوریتمی وجود ندارد. و استنباط برای تخمین هزینه نرمافزار بکار برده میشود.
3-6-1-1 تخمین تجربی85
در روش تخمین هزینه تجربی، از تجربه عملی که در یک یا چند پروژه مشابه پیشین کسب شده است، استفاده شده و بر اساس آنها تخمین هزینه پروژه جدید انجام می شود. این روش را می توان در سطح کل پروژه و یا در سطح زیر سیستم ها به کار گرفت. در حالت اول تمام اجزاء از نظر هزینه بررسی می شوند و در حالت دوم ارزیابی بیشتری از شباهت ها و تفاوت های سیستم فعلی با سیستم های قبلی صورت می گیرد و بنابراین تخمین دقیق تر خواهد بود. مزیت این روش این است که بر اساس تجربه های واقعی انجام می شود و عیب آن در این است که سیستم های پیشین کاملا منطبق با سیستم فعلی نیستند و مقایسه ناآگاهانه و غلط آنها می تواند تخمین را منحرف کند.
3-6-1-2 روش داوری کارشناسانه86
قضاوت کارشناسانه نیازمند همفکری با کارشناس تخمین هزینهی نرمافزاری یا گروهی از کارشناسان برای استفاده از تجربیات آنان و درک پروژهی پیشنهادی برای رسیدن به یک تخمین از هزینه است. عموما گفته میشود که تکنیک رضایت گروهی، تکنیک دلفی بهترین راهی است که میتوان از آن استفاده کرد. نقاط قوت و ضعف آنها، مکمل نقاط قوت و ضعف روشهای الگوریتمی هستند. برای فراهم کردن پهنای باند ارتباطی با گستردگی کافی برای کارشناسان و به منظور تبادل حجم اطلاعات مورد نیاز برای تنظیم تخمینها توسط کارشناسان دیگر، از یک تکنیک دلفی پهن باند که براساس تکنیک دلفی استاندارد معرفی شده است، استفاده میشود (B.Boehm, 1981). گام های تخمین مورد استفاده در این مدل عبارتند از:1 هماهنگسازها هر کارشناس را با یک مشخصه و یک فرم تخمین نشان میدهند.2- هماهنگسازها یک جلسه گروهی را فراخوانی میکنند که طی آن کارشناسان در مورد مباحث تخمین با هماهنگسازها و با یکدیگر صحبت می کنند.3- کارشناسان با نام های مستعار، فرم ها را تکمیل می کنند.4- هماهنگ سازها خلاصه ای از تخمین را در هر فرم تکرار تهیه و توزیع می کنند.5- هماهنگسازها یک جلسه گروهی را فراخوانی میکنند و تمرکز ویژهای بر نقاط بحث کارشناسان در تغییرات گستردهی تخمینها دارند.6- کارشناسان مجددا با استفاده از نامهای مستعار، فرمها را تکمیل میکنند و گام های 4 تا 6 در چندین دور به اندازهی مورد نیاز تکرار میشود.مزایای این روش عبارتند از:1- کارشناسان میتوانند اختلافات میان تجربیات پروژه ی پیشین و نیازهای پروژهی پیشنهادی را محاسبه کنند.2- کارشناسان میتوانند تاثیرات ایجاد شده به دلیل تکنولوژیهای جدید، معماری ها، برنامههای کاربردی و زبان های درگیر در پروژهی آتی را محاسبه کنند و نیز مشخصههای شخصی در حالات خاص و تعاملات و غیره را ثبت نمایند.معایب این روش عبارتند از : 1- در این روش کمیتها تعیین نمیشوند. 2- به سختی میتوان محـاسبات انجامشده توسط کارشناسان یا گروه کارشناس را مستندسازی کرد.3- کارشناسان ممکن است دارای گرایش خاص، خوش بین، بدبین باشند و یا نظر آنها تحت نظر گروه تغییر کند.
3-6-1-3 تخمین با قیاس87
تخمین با استفاده از قیاس به معنای مقایسهی پروژه ی پیشنهادی با پروژههای مشابه تکمیل شدهی قبلی است که اطلاعات توسعه این پروژهها موجود است. دادههای واقعی پروژههای تکمیلی با تخمین پروژه پیشنهادی قیاس میشوند. میتوان این روش را در سطح سیستم یا سطح مولفهها مورد استفاده قرار داد. تخمین با استفاده از قیاس نسبتا سرراست است. در واقع در برخی جنبهها، یک فرم منظم از داوری کارشناسانه استفاده میشود، زیرا کارشناسان اغلب به دنبال وضعیتهای قیاسی هستند تا نظریات خود را بیان کنند (سامرویل, 1381). گامهای مورد استفاده در تخمین با استفاده از قیاس عبارتند از: تعیین مشخصات پروژهی پیشنهادی ؛ انتخاب شبیهترین پروژههای تکمیل شدهای که مشخصات آنها در پایگاه داده تاریخی ذخیره شده است؛به دست آوردن تخمین پروژههای پیشنهادی از شبیهترین پروژههای تکمیل شده با استفاده از قیاس. مهمترین مزایای این روش عبارتند از:1- این تخمین مبتنی بر دادههای مشخصهی پروژههای واقعی است.2- تجربه قبلی تخمینزننده و دانش را میتوان مورد استفاده قرار داد که این کمیتها به سادگی تعیین نمیشوند.3- اختلاف میان پروژههای تکمیل شده و پیشنهادی را میتوان تعیین کرد و عوامل موثر بر تخمین را مشخص نمود. هرچند که این روش دارای برخی مشکلات است:1- با استفاده از این روش بهترین توصیف پروژهها را تعیین میکنیم. برای انتخاب متغیرهای محدود به اطلاعات در دسترس به پیشگویی نیاز است.2- حتی هنگامی که مشخصه های پروژه تعیین میشود، میزان شباهت و اطمینان از طریق قیاس مشخص میشود.
3-6-1-4 روش پارکینسون88
در این روش هزینه نرم افزار تخمین زده نمیشود، بلکه با توجه به منابع موجود (بدون توجه به اهداف پروژه) تعیین میشود. به طور مثال اگر مدت زمان اجری پروژه 12 ماه و تعداد نیروهای موجود 5 نفر باشد، میزان 60 نفر- ماه تخمین زده میشود. اگر چه این روش در برخی موارد تخمین قابل قبولی را ارائه میدهد، ولی تکنیک مناسبی برای تخمین هزینه پروژه نیست.
3-6-1-5 پایین به بالا
در این روش هر یک از اجزاء سیستم به طور مجزا تخمین زده میشوند. سپس مجموع این تخمینها به عنوان تخمین هزینه کلی پروژه در نظر گرفته میشود. برای استفاده از این روش لازم است که در ابتدا یک طراحی اولیه از سیستم انجام دهیم تا ساختار اجزاء را بدست آوریم.
3-6-1-6 بالا به پایین
این روش بر خلاف روش قبلی است و هزینه پروژه با استفاده از روشهای الگوریتمی یا غیر الگوریتمی به شکل یکجا و براساس معیارهای کلی تخمین زده میشود. در گامهای بعدی این هزینه میتواند بین اجزاء مختلف سیستم توزیع شود.
3-6-2 روشهای الگوریتمی
روشهای الگوریتمی از مدلهای ریاضی برای تخمین هزینه پروژه استفاده میکنند. هر مدل الگوریتمی به صورت تابعی از فاکتورهای هزینه تعریف میشود. روشهای الگوریتمی موجود در دو جنبه با یکدیگر متفاوت هستند، یکی انتخاب فاکتورهای هزینه و دیگری تعریف تابع محاسبه هزینه. ابتدا فاکتورهای هزینه بررسی میشود و سپس روشها را با توجه به تعریف تابع محاسبه عنوان کرده و تحلیلی89 یا تجربی بودن90 آنها بیان میشود (سامرویل, 1381). قابلیت انعطاف روشهای الگوریتمی بسیار پایین بوده و آنها نمیتوانند در پروژههای بزرگ و پیچیده تخمینهای قابل قبولی ارائه دهند. روشهای الگوریتمی مشهور شامل دو روش کوکومو91 (سامرویل, 1381) و مدیریت چرخه نرمافزار92 (L. Putnam and W Myers, 1992) هستند.
3-6-2-1 مدل های COCOMO
یکی از مدل های بسیار پرکاربرد برای تخمین هزینهی نرم افزاری به صورت الگوریتمی، مدل هزینه سازنده کوکومو است. مدل اولیه ی کوکومو فرم بسیار ساده ای دارد:
MAN-MONTHS (4-3) = K1 * (هزاران دستور منبع که تحویل داده شده اند)K2
که K1, K2 دو پارامتر وابسته به محیط توسعه و برنامه ی کاربردی هستند.
در صورتی که فاکتورهای دیگر مرتبط با مشخصه های مورد نیاز نرم افزار در حال توسعه، میزان مهارت و تجربه تیم توسعه دهنده و محیط توسعه نرم افزار نیز در نظر گرفته شوند، تخمینهای مدل اولیه COCOMO می تواند دقیق تر شود. بسیاری از این فاکتورها متاثر از تعداد ماه های کاری یا حجم کار هستند. COCOMO فرض می کند که نیازهای نرم افزاری و سیستمی قبلا تعریف شده اند و این نیازها ثابت هستند. در حالی که اغلب چنین نیست. مدل COCOMO یک مدل رگرسیونی است و مبتنی بر آنالیز 63 پروژه ی انتخابی است. ورودی اصلی آن KDSI است. مشکلات این روش عبارتند از:1- در فازهای اولیه ی چرخه حیات سیستم، میزان اندازه با استفاده از یک مقدار بسیار مبهم تخمین زده می شود. بنابراین تخمین هزینه ی دقیقی نداریم. 2- معادله ی تخمین هزینه با استفاده از 63 پروژه ی انتخابی به دست آمده است و معمولا در خارج از محیط خاص خود با برخی مشکلات مواجه است. بدین منظور به تنظیمات مجدد نیاز دارد.
3-6-2-2 مدل Putnam
مدل محبوب دیگر در تخمین هزینه نرم افزاری، مدل Putnam است. فرم این مدل به صورت زیر است:
ثابت صنعتی C = اندازه * B1/3 * T4/3 (5-3)
(3-6) مجموع تعداد ماه های افراد B= 1 / T4 * (اندازه / C) 3
T = زمان توسعه ی مورد نیاز در واحد سال
میزان اندازه در واحد LOC تخمین زده می شود. که C پارامتر وابسته به محیط توسعه است و بر اساس داده های پیشین موجود از پروژه های قبلی تعیین می شود.
تعیین نرخ: C=2'000 (ضعیف)، C=8'000 (خوب)، C=12'000 (عالی).
مدل Putnam به زمان توسعه بسیار حساس است: کاهش زمان توسعه سبب افزایش بسیار تعداد ماه های مورد نیاز افراد درگیر در توسعه می شود.
3-6-2-3روش های مبتنی بر آنالیز نقطه ی تابعی
آنالیز نقطه تابعی روش دیگری است که به منظور تعیین اندازه و پیچیدگی عملکردهای تحویلی سیستم نرم افزاری به کاربر مورد استفاده قرار میگیرد. برخی از مدل های اختصاصی برای تخمین هزینه با نوعی از رویه ی نقطه تابعی سازگار هستند. روش اندازه گیری نقطه تابعی توسط آلن آلبرت در IBM ارائه شد و در سال 1979 انتشار یافت. وی اعتقاد داشت که نقطه ی تابعی در قیاس با شمارش SLOC اندازه دارای مزایای مهمی است. شمارش نقاط تابعی دارای دو گام است:
1. شمارش توابع کاربر. تابع اولیه با بررسی ترکیب خطی پنج مولفه ی نرم افزاری اصلی، عمل شمارش را انجام می دهد: ورودی های خروجی، خروجی های خارجی، درخواست های خارجی، فایل های منطقی داخلی و فاصل های خارجی، هر کدام در سه سطح پیچیدگی: ساده، متوسط یا پیچیده. مجموع این اعداد براساس سطح پیچیدگی وزن دار می شوند که برابر است با تعداد شمارش های تابع (FC).
2. تنظیم پیچیدگی پردازش محیطی. نقاط تابعی نهایی با ضرب FC در فاکتور تنظیم به دست میآیند که با بررسی 14 جنبه ی پیچیدگی پردازش تعیین می شود. با استفاده از این فاکتور تنظیم می توان FC را تا حداکثر 35درصد تغییر داد.
مجموعه داده های نقاط تابعی دارای دو انگیزه ی اصلی هستند. انگیزه ی اول برای مدیران مطلوب است و نظارت بر سطوح بهره وری را شامل می شود. استفاده ی دیگر در تخمین هزینه ی توسعه ی نرم افزار است.
تعدادی روش برای تخمین هزینه داریم که مبتنی بر نوع نقاط تابعی اندازه گیری هستند، همچون ESTIMACS, SPQR/20. SPQR/20 مبتنی بر یک روش نقطه تابعی اصلاح شده است. در حالی که آنالیز نقطه تابعی سنتی مبتنی بر ارزیابی 14 فاکتور است، اما پیچیدگی SPQR/20 به سه دسته تقسیم می شود: پیچیدگی الگوریتم ها، پیچیدگی کد و پیچیدگی ساختارهای داده. ESTIMACS یک سیستم مرسوم است که به منظور تخمین هزینه ی توسعه در مرحله ی ادراک یک پروژه طراحی شده است و حاوی ماجولی است که نقاط تابعی را به صورت ورودی های اصلی برای تخمین هزینه مورد استفاده قرار می دهد.
مزایای مدل آنالیز نقطه تابعی عبارتند از:
* نقاط تابعی را می توان با استفاده از مشخصه های نیازها یا مشخصه های طراحی تخمین زد. بنابراین می توان هزینه ی توسعه را در فازهای اولیه ی توسعه تخمین زد.
* نقاط تابعی مستقل از زبان، ابزار یا روش های مورد استفاده در پیاده سازی هستند.
* کاربران غیرتخصصی درک بهتری از نحوه ی اندازه گیری نقاط تابعی دارند، زیرا نقاط تابعی مبتنی بر دیدگاه خارجی کاربر سیستم هستند.
3-6-2-4رگرسیون
مدل هزینه مبتنی بر رگرسیون همانطور که در فرمول شماره (3-7) نشان داده شده است برای پیشبینی میزان تلاش لازم بر اساس نفر، ماه از پارامتر سایز بر اساس خطوط برنامه یا تعداد توابع استفاده می کند.

E= a+b × Sc (7-3)

a و b و c ثابتهای تجربی هستند و s سایز است فرمولهای دیگری همچون مدل والستون فیلکس، بیلی بسیلی، دوتی، آلبرت کفنی، کرمرر متسون، نیز با استفاده از تعداد خطوط برنامه به تخمین تلاش میپردازند که در جدول زیر آورده شده اند. (Laird, Linda M., 2006)
جدول(3-1): بررسی مدلهای تخمین الگوریتمی
Adjust
Year
Model
Name-Reference

–
1977
E = 0.7(KLOC)0.91
Walston-Felix
(Walston and Felix, 1977)
1
–
1977
(for KLOC > 9) E = 5.288(KLOC)1.047
Doty model
(Herd, et al., 1977)
2
–
1977
5.2(KLOC)1.50
Halstead (Halstead, 1977)
3
*
1978
(D 4/7 × E -9.7) ×S 9/7
SLIM(Putnam, 1978)
4
*
1980
K=D 0.4× (Se/cte)1.2
SEER-SEM(Galorath Inc 1980)
5
–
1981
E = 5.5 + 0.73(KLOC)1.16
Bailey-Basili
(Bailey and Basili, 1981)
6
*
1981
Effort = a (KDSI)b
Basic
COCOMO81(Boehm, 1981)
7

E=a (KDSI) b.EAF
Intermediate

E=a (KDSI)b.EAF
Detailed

–
1983
E(man-months) = 0.0545×FP – 13.39
Albrecht-Gaffney
(Albrecht and Gaffney,
1983)
8
–
1987
E(man-months) = 60.62×7.728×10-8×FP3
Kemerer (Kemerer, 1987)
9
–
1994
E(work hours) = 585.7 + 15.12×FP
Matson, Barrett and
Mellichamp
(Matson, et al., 1994)
10
*
2000
PM=A×Size E ×Π i=1 15 EMi
COCOMO II (Boehm, 2000)
11

3-7 مروری بر کارهای انجام شده
3-7-1 مدل تخمین هزینه نرمافزار مبتنی بر منطق فازی
منطق فازی یک ابزار ارزشمند است که میتواند به منظور حل مسایل پیچیده مورد استفاده قرار گیرد، مسایلی که دارای مدل ریاضی پیچیده هستند یا طراحی آنها غیرممکن است. همچنین از منطق فازی به منظور کاهش پیچیدگی راهکارهای موجود و افزایش دسترس پذیری تئوری کنترل استفاده میشود (Razaz, M. And King, J, 2004). توسعه ی نرم افزار همواره با پارامترهایی توصیف می شود که دارای سطوح فازی خاصی هستند. بررسی ها نشان می دهد که مدل منطق فازی در تخمین نیروی کار نرم افزاری جایگاه خاصی دارد. با استفاده از منطق فازی می توان بر برخی مسایل ذاتی تکنیک های موجود برای تخمین نیروی کار غلبه کرد. منطق فازی نه تنها برای پیشگویی نیروی کار مفید است، بلکه همچنین به منظور بهبود کیفیت مدل های تخمین فعلی نیز ضروری است (T. S. Moon , et.al, 2007) . منطق فازی میتواند نمایش زبان شناختی از ورودی و خروجی یک مدل را به منظور تحمل پذیری عدم دقت ارائه دهد. این روش به ویژه برای تخمین نیروی کار مناسب است و ویژگی های نرم افزاری بر اساس نوع مقیاس معمولی یا اسمی اندازه گیری می شوند که حالت خاصی از مقادیر زبان شناختی هستند. پیشنهاد دیگر استفاده از الگوریتم انتخاب زیرمجموعه براساس منطق فازی برای مدل های تخمین نیروی کار نرمافزاری به روش قیاسی است. ارزیابی با استفاده از دو مجموعه داده ی موجود (ISBSG, Desharnais) نشان می دهد که استفاده از الگوریتم انتخاب زیرمجموعه ویژگی های فازی در تخمین نیروی کار نرم افزاری به روش قیاسی، نتایج خوبی را در مقابل پیشنهاد دیگر ارائه شده توسط همین در پی دارد. همچنین منطق فازی سبب بهبود قابلیت تفسیر مدل می شود و کاربر می تواند مدل را ببیند، ارزیابی کند، مورد انتقاد قرار دهد و سازگار نماید. مدل دیگری برای بهینه سازی نیروی کار برای کاربردهای خاص ارائه شده است که به جای استفاده از یک عدد، مبتنی بر برآورد اندازه منطق فازی (KLOC) است که به صورت یک عدد مثلثی است. بررسی تجربی نه تنها بر روی 10 پروژه ی ناسا انجام شده است، بلکه نتایج آن نیز با مدل های موجود مورد قیاس قرار گرفته است. بررسی مقایسه ای نتایج بهتری را نشان می دهد و بنابراین روش پیشنهادی تا حد کافی عمومی است که بتوان از آن در مدلهای دیگر مبتنی بر روش های نقطه تابعی و نیز در نواحی دیگر مهندسی نرم افزار کمّی استفاده کرد.
این افراد با هدف بهبود دقت تخمین نیروی کار از منطق فازی بهره بردند. این منطق برای فازیسازی پارامترهای مدل COCOMO و عکس فازیسازی برای تعیین خروجی نهایی و نیروی کار مورد نیاز استفاده میشود. ساختار مدل پیشنهادی در شکل ‏3-1 نشان داده شده است. براساس این مدل ورودیهای سه گانه شامل: 17 ضریب نیروی کار(EM)93، 5 فاکتور مقیاس (SF)94 و اندازه LOC بهمراه یک خروجی که نیروی کار (هزینه نرمافزار) میباشد. فازیساز ورودیهای مربوطه را به متغییرهای فازی تبدیل میکند. موتور استنتاج براساس قوانین فازی و پایگاه داده خروجی فازی را بدست میآورد. و در نهایت غیرفازیساز مقادیر فازی موجود را به مقادیر قطعی تبدیل میکند (Ziauddi, et.al, 2013)

شکل(‏3-1): مدل فازی-cocomo تخمین نیروی کار
3-7-2 تخمین هزینه نرمافزار با استفاده از شبکههای عصبی
استفاده از شبکههای عصبی پس انتشار بوسیله (A.Kaushik, et al, 2013) پیشنهاد شد (سامرویل, 1381). عملکرد شبکههای عصبی وابسته به معماری و پارامترهای آن میباشد، این پارامترها شامل تعداد گرهها، لایهها، نوع توابع انتقال و غیره است. در این روش از تابع همانی در لایه ورودی و تابع تک قطبی حلقوی در لایههای مخفی و خروجی استفاده میشود. مراحل این الگوریتم بصورت زیر است:
1-مقداردهی اولیه وزنها در بازه .(0,1]2- مراحل 3 تا 9 تا وقوع شرط توقف تکرار شود. 3- هر ورودی از لایه ورودی به لایه مخفی ارسال شود.4- برای هر گره لایه مخفی مجموع حاصلضرب وزنها در ورودیها محاسبه شود.5- برای گره خروجی این مجموع بدست میآید.6- نرخ خطا محاسبه و تصحیح خطا رو به عقب انتشار پیدا میکند. 7- وزنهای بین لایههای خروجی و مخفی براساس خـــطا به روز میشوند. 8- وزنهای بین لایههای مخفی و ورودی براساس خطا به روز میشوند. 9- شرایط توقف بررسی میشود.
این روش روی سه مجموعه داده پیادهسازی شده، نتایج این روش نسبت به روش COCOMO بهتر میباشد.
3-7-3 تخمین نیروی کار نرمافزار بوسیله الگوریتم ژنتیک با پارامترهای تنظیمشده
(Singh et al,2012) با استفاده از الگوریتم ژنیک یک روش جدید برای تخمین هزینه نرمافزار ارائه کردند. در الگوریتم پیشنهادی آنها از روش COCOMO به عنوان مدل الگوریتمی و یک هدف برای ارزیابی پاسخهای الگوریتم ژنتیک استفاده میشود. هدف اصلی این تحقیق بررسی تاثیر ورودیهای قطعی و تکنیک الگوریتم ژنتیک بر روی خروجیهای سیستم، همراه با استفاده از مـدل اصلاح شده COCOMO بر روی دادههای NASA میباشد. (B.K. Singh and A.K.Misra, 2012)
فرایند تکامل با ایجاد جمعیت اولیه شروع میشود. راهحلهای کاندید به عنوان بردارهای n بعدی شامل پارامترهای میباشد، که هر کدام به عنوان یک کروموزوم نمایش داده میشود. الگوریتم ژنتیک قابیلت انواع متفاوتی از نمایشها را دارد. عناصر موجود در جمعیت اولیه بایستی ارزیابی شوند. بعد از این ارزیابی، تولید نسل بوسیله مکانیزم انتخاب صورت میگیرد. تولید فرزندان با استفاده از عملگرهای جهش و تقاطع انجام میشود ، احتمال انجام هر عملگر براساس کاربرد آن تعیین میشود. روند تکامل تا پیدا کردن یک راهحل بهینه ادامه مییابد. ساختار تکامل در شکل ‏3-2 نمایش داده شده است. نتایج خروجی این روش نشان دهنده بهبود نتایج روش COCOMO اصلاحشده نسبت به نوع کلاسیک آن است.

شکل (‏3-2): روند تکامل در الگوریتم پیشنهادی
3-7-4 چهارچوب مبتنی بر شبکه عصبی و منطق فازی برای تخمین هزینه توسعه نرمافزار
به منظور ادغام شبکه عصبی مصنوعی در پروسه های استنتاج فازی و به دست آوردن تخمین نیروی کار نرم افزاری، رویه ای تحت عنوان شبکه ی عصبی فازی (FNN) پیشنهاد شده است. از شبکه عصبی فازی برای تعیین قوانین مهم فازی در پروسه های استنتاج فازی استفاده میشود. ترکیبی از چهارچوب بهینهشده منطق فازی و مدل نو شبکه عصبی برای تخمین هزینه نرمافزار توسط ( Kumar et al,2013) پیشنهاد شد (Sh.Kumar, V. Chopra, May 2013). این مدل نیروی انسانی را به عنوان تابعی از اندازه برنامه و تعداد زیادی از محرکهای هزینه ، مانند ویژگیهای سختافزاری و ویژگیهای پروژه محاسبه میکند. به منظور تخمین با دقت بالا مدل شبکههای عصبی با ساختار یادگیر و چهارچوب منطق فازی با هم مقایسه میشوند. میانگین خطای نسبی (MMRE) و دقت پیشبینی (Pred) حاصل از این روش ترکیبی نسبت به مقادیر مشابه حاصل از شبکه عصبی و منطق فازی کمتر است.
3-7-5 بهینهسازی پارامترها با استفاده از بهینه سازی دسته ذرات
بهینه سازی دسته ذرات (PSO) یک روش محاسباتی است که با تلاش تکرارشونده میتواند یک راهکار کاندید را با توجه به میزان کیفیت مورد نظر، بهبود بخشد. چنین روشهایی عموما تحت عنوان "ابر اکتشافات"95 شناخته میشوند و میتوانند فضای داده ی بسیار بزرگ از راهکارهای کاندید را جستجو کنند. PSO دارای شباهتهای بسیاری با تکنیکهای محاسبات تکاملی همچون الگوریتم های ژنتیک است. این سیستم با جمعیتی از راهکارهای تصادفی مقداردهی اولیه میشود و با به روز رسانی تولیدها به دنبال نقطه ی بهینه میگردد. هرچند که در این روش برخلاف GA، هیچ عملگر تکاملی همچون تقاطع و جهش وجود ندارد. در PSO، راه حل های بالقوه که ذرات نامیده میشوند، با تبعیت از ذرات بهینه فعلی در فضای مساله حرکت میکنند. برای استفاده از PSO و به منظور تنظیم مدل هزینه سازنده (COCOMO) برای تخمین بهتر نیروی کار، ارائه شده است (Sh.Wang ,L. Chen, 2009). کارایی مدلهای ارائه شده با استفاده از PSO بر روی داده های پروژه ی نرم افزاری ناسا در (B.K. Singh and A.K.Misra, 2012) تست شده است. همچنین مقایسه ای میان COCOMO با PSO ی تنظیم شده، انجام شده است. مدل های پیشنهادی در قیاس با ساختار مدل های سنتی، قابلیت تخمین خوبی نشان داده اند. در (Reddy, 2010) الگوریتمی تحت عنوان الگوریتم بهینه سازی دسته ذرات (PSOA) ارائه شده است تا تخمین فازی را برای توسعه پروژه نرم افزاری به خوبی تنظیم کند. مفهوم اولیه ی PSO، تسریع حرکت ذرات به سمت مکان های Pbest, Gbest با توجه به شتاب وزنی تصادفی در هر زمان است. با استفاده از معادلات زیر می توان تغییر مکان ذرات را از نظر ریاضی مدل سازی کرد:
(8-3)

که نقطه ی جستجوی فعلی است، نقطه ی جستجوی اصلاح شده است و Vik سرعت فعلی است و Vik+1 سرعت تغییر یافته و W تابع وزن دار و Cj فاکتورهای وزنی و Rand() اعداد تصادفی دارای توزیع یکنواخت در محدوده ی 0 و 1 هستند. مراحل این الگوریتم به این صورت است:1- بصورت تصادفی 40 ذره تولید و به آنها سرعت اولیه در فضای دو بعدی تخصیص داده میشود. 2-شایستگی هر کدام از ذرات محاسبه میشود.3- برای هر کدام از ذرات Pbest بروز میشود. 4-سرعت ذرات بوسیله معادله بالا بروز میشود. 5- مراحل بالا تا وقوع شرط توقف ادامه مییابد
3-7-6 شبکه عصبی موجک برای تخمین هزینه
در مقاله (K. Vinay Kumar,et al, 2008) از شبکه عصبی موجک 96(WNN) برای توسعه نرم افزار استفاده شده است. در این تحقیق از دو نوع WNN استفاده میشود. بطوریکه توابع انتقال آنها، توابع مارلت97 و گاوسی هستند و همچنین یک الگوریتم آموزشی پذیرش آستانه برای شبکه عصبی موجک پیشنهاد میشود 98(TAWNN). کارایی WNN در زمینه اندازهگیری خطا در قیاس با دیگر تکنیکها همچون پرسپترون چند لایه ای 99(MLP)، شبکه تابع شعاع گرا 100(RBNF)، رگرسیون خطی چندگانه 101(MLR)، سیستم استنتاج فازی عصبی تکاملی پویا 102(DENFIS) و ماشین بردار پشتیبان (SVM)103 متفاوت است. میزان خطا به معنای اندازه ی خطای نسبی متوسط 104(MMRE) است که از طریق داده های مجموعه داده مالی کانادا (CF)105 و مجموعه داده سرویسهای پردازش داده IBM 106(IBMDPS) به دست آمده است. از آزمایشات انجام شده مشخص است که WNN-Morlet برای مجموعه داده ی CF و نیز WNN-Guassian برای IBMDPS بهتر از دیگر تکنیک ها عمل میکنند. همچنین TAWNN به جز WNN، از تمامی تکنیک های دیگر عملکرد بهتری دارد.
3-7-7 پیشگویی عصبی-ژنتیک برای توسعه نیروی کار نرم افزاری
(Shukla, 2000)برای پیشگویی نیروی کار از یک شبکه ی عصبی رو به جلو با 39 نرون ورودی استفاده کرد. لایههای مخفی نرونها برای نمایش نگاشت مطلوب مورد استفاده قرار میگیرند و هر نرون خروجی متناظر با نیروی کار پیش بینی شده در چندین ماه است. این مدل شبکه عصبی از بردار وزن W و کمان های اندیس گذاری شده A بر روی شبکه ی N=(V, A) استفاده میکند که هیچ چرخه مستقیمی در آن وجود ندارد. در این جا V, A به ترتیب مجموعه ی راس ها و کمان های تعریف شده در شبکه عصبی هستند. وزن ها، آستانه ها و نمونه های واقعی را در نظر می گیریم و از تابع فعالسازی حلقوی107 استفاده شده است. شبکه عصبی باید آموزش ببیند تا بتواند نگاشت بردار به بردار H(., W) را انجام دهد.

شکل(‏3-3) : الف) نمونه ای از شبکه عصبی که با استفاده از الگوریتم ژنتیک آموزش داده شده ب) نمایش کروموزوم های شبکه ی عصبی
3-8 ارزیابی مدل های تخمین
Briand and Wieczorek,2002) ) تقسیم بندی کلی از روشهای تخمین در دو دسته ی الگوریتمی و غیر الگوریتمی را در بالاترین سطح ارائه دادند. این مدل برای تخمین تلاش لازم برای توسعه نرم افزار ارائه شد که بعدها این مدل پیشنهادی برای تخمین تلاش لازم برای توسعه نرم افزار به صورت درخت سلسله مراتبی کامل و ارائه شد که در شکل 3-4 مشاهده می شود.
شکل(3-4): نمودار مدلهای تخمین تلاش توسعه نرم افزار
در جدول3-2 خلاصه ای از مقایسه بین روشهای الگوریتمی و غیر الگوریتمی بر اساس ده نقطه نظر بیان شده است.
جدول (3-2 ): مقایسه مدلهای الگوریتمی و غیر الگوریتمی
الگوریتمی
غیر الگوریتمی
انعطاف پذیری بالا
انعطاف پذیری پایین
مبتنی بر یادگیری
مبتنی بر الگو
بعضی خصوصیات پروژه کافی است
به اطلاعات بیشتری نیاز دارد
پویا
ایستا
تخمین پیچیده
تخمین آسان
بروز رسانی خودکار
نیازمند بروز رسانی
اغلب زمان تخمین تحلیل می رود
تخمین سریع
تنظیم روش توسط متخصصان
رابط مدل میتواند انسان نباشد
تخمین دقیق در مراحل اولیه
تخمین نادرست در مراحل اولیه پروژه
قابلیت استفاده با پارانترهای مختلف
قابلیت استفاده با پارامترهای خاص

فصل 4
"ارائه چهارچوب پیشنهادی"

فصل چهارم : مدل رهیافتی
در این فصل به بررسی روش پیشنهادی به صورت کلی پرداخته می شود تا اینکه ببینیم به چه میزان روش پیشنهادی دقت تخمین را به واقعیت نزدیک و افزایش می دهد لذا از این جهت روش موجود رامورد بررسی و مزایا و معایب آن بیان خواهد شد.
4-1 مقدمه
تخمین نیروی کار در توسعه ی نرمافزار یکی از مهمترین فعالیتها در مدیریت پروژهی نرمافزاری است. تاکنون به منظور ایجاد ارتباط میان اندازه نرمافزار و نیروی کار، تعدادی مدل پیشنهاد شده است، اما این مدلها دارای مشکلاتی هستند. به این دلیل که دادههای پروژه در مراحل اولیه آن اغلب ناکامل، ناسازگار، غیرقابل اعتماد و غیرواضح هستند. میتوان از تخمینهای نیروی کار به عنوان ورودی طرح های پروژه، طرحهای تکرار، بودجه، آنالیز سرمایه و پروسه های تعیین قیمت استفاده کرد و بنابراین دقت این تخمینها دارای اهمیت بالایی است. به شکلی که شرح داده شد، مدلهای پیشگوی نیروی کار نرم افزاری در دو دسته اصلی الگوریتمی و غیرالگوریتمی قرار میگیرند. این مدل ها همچنین در مدل سازی روابط پیچیده ذاتی میان فاکتورهای همکار دارای مشکلاتی هستند و نمیتوانند دادههای گروهی را به دلـیل فقدان قابلیتهای منطقی مدیریت نمایند.
4-2روش شناسی تحقیق
روش ما برای انجام این تحقیق تجربی ریاضی است که با استفاده از مطالعه روشهای موجود و بررسی آنها به عملیاتی کردن روش جدید خود برسیم. به دلیل تنوع و تعدد بالای پروژه های نرم افزاری در این نوشتار از چندین دیتاست واقعی و بزرگ استفاده خواهد شد، رایجترین روش برای انجام تحقیقات تخمینی، اثبات درستی کار و آزمایش و مشاهده نتایج آماری هر تغییر و مقایسه با مقادیر واقعی است. داده های ورودی در شرایط مختلف و با توجه به نیاز ما تغییر میکنند (با ثابت نگه داشتن یک یا چند پارامتر و تغییر بقیه معیارها). علاوه بر این موارد روش تحقیق بصورت بررسی و تحلیل روشهای موجود و کشف نقاط ضعف و شکافها و تلاش برای ارائه یک روش جدید با الهام از مدل های ریاضی و آماری است. فازهای تحقیق به شرح زیر می باشد:
فاز A: جمعآوری اولیه داده ها و تجزیه و تحلیل آنها
فاز B: فیلتر کردن و تایید و اعتبارسنجی دادهها، ورود به ویژگیهای خاص پروژههای نرم افزاری
فاز C: ساخت اولین مدل تخمین بر اساس تعیین و وزن دهی موثرترین خواص پروژهها
فاز D: تولید دومین مدل تخمین تلاش با استفاده از الگوریتمها و روشهای آماری و بهینه سازی
فاز E: استفاده از روش CART به عنوان روش تخمین تلاش در جهت توسعه مدل جدید
فاز F: جمع بندی و ایجاد یک مدل تخمین جدید بر اساس سه فاز آماده سازی قبلی
4-3 داده ها و جامعه آماری
برای ارزیابی روش و استخراج نتایج از مجموعه دادههای استاندارد استفاده میشود. هر پایگاه داده توسط چندین پروژه نرمافزاری و ویژگیهای آنها توصیف میشود. تعداد پروژه ها و تعداد ویژگیهای آنها از مهمترین موارد در هر پایگاه داده بشمار میآیند. از جمله پایگاه دادههای استاندارد میتوان به پایگاه دادههای COCOMO2 NASA و COCOMO 81 اشاره کرد. پایگاه داده COCOMO81 در سال 1981 توسط بوهم در موسسه NASA جمعآوری شد. این مجموعه شامل 63 نمونه پروژه با 17 ویژگی که 15 عدد از این ویژگیها، ویژگیهای استاندارد و رقمی و ستون باقیمانده از ویژگیها مربوط به تعداد خطوط برنامه و هزینه واقعی توسعه نرمافزار (برحسب نفر-ماه) میباشد پایگاه داده COCOMO2 NASA بین سالهای 1971 تا 1987 بوسیله جاریون هین در موسسه NASA جمعآوری شد. این مجموعه متشکل از 93 نمونه پروژه با 24 ویژگی، که 15 عدد از این ویژگیها، ویژگیهای استاندارد رقمی و 7 عدد از آنها ویژگیهای تشریحی نمونهها میباشند؛ دو ستون باقیمانده نیز مربوط به تعداد خطوط برنامه و هزینه واقعی توسـعه نرمافزار (برحسب نفر-ماه) است. جدول شماره 4 ویژگیهای رقمی این مجموعه دادهها را نشان میدهد. (Boehm, 2000).
جدول(4-1): ویژگیهای رقمی مجموعه دادههای COCOMO ناسا
معنا
نام کامل
نام اختصاری
قابلیت اطمینان نرمافزار
required software reliability
Rely
اندازه پایگاه داده
data base size
Data
پیچیدگی پردازش
process complexity
Cplx
محدودیت زمانی پردازنده
time constraint for cpu
Time
محدودیت حافظه اصلی
main memory constraint
Stor
تغییرپذیری ماشین
machine volatility
Virt
زمان بازگشت
turnaround time
Turn
توانایی تحلیلگر
analysts capability
Acap
تحربه کاربردی
application experience
Aexp
قابلیت برنامهنویس
programmers capability
Pcap
آزمون ماشین مجازی
virtual machine experience
Vexp
زبان آموزی
language experience
lexp
شیوه برنامهنویسی پیشرفته
modern programing practices
Modp
ابزارهای نرمافزاری
use of software tools
Tool
محدودیتهای زمانبند
schedule constraint
Sced

یکی از مراحل اسـاسی در اینگونه مجموعه دادهها نرمالسازی آنها در محدودههای نرمال شامل [0,1] یا [-1,1] میباشد. نرمالسازی دادههای ورودی مطابق فرمول زیر، برای اطمینان از حذف واحدهای اندازهگیری و ایجاد محدوده یکسان108 برای تمام صفات انجام میشود:
((1)()(4-1)

که xmin, xmax مقدار بیشینه و کمینه متغیر ورودی را نشان می دهند. بنابراین بعد از تاثیر این تبدیل، تمام متغیرها فاقد بعد میشوند. همانگونه که اشاره شد متغیرها و پارامترهای مختلفی در مجموع دادههای نرمافزاری وجود دارد که در جدول شماره 5 متغیرها در مجموعه داده های ماکسول بعنوان نمونه تشریح شده اند (Maxwell, 2002).
جدول(4-2): تشریح برخی متغیرهای مهم برای تخمین تلاش توسعه
برخی از ویژگیهای مهم پروژههای نرم افزاری
سال شروع پروژه
استفاده از ابزار
مهارت تیمی کارکنان
نوع برنامه
پیچیدگی منطقی نرم افزار
مدت زمان تحویل پروژه
پلتفرم سخت افزاری
نوسانات نیازمندیها
انداره برنامه
پایگاه داده
الزامات کیفی
سال تحویل نرم افزار
رابط کاربری
الزامات کارائی
میزان تلاش به کار رفته
محل توسعه
نیازمندیهای نصب
کیفیت محیط توسعه
استفاده از تولید کننده کد
مهارت کارکنان تحلیلگری
در دسترس بودن کارکنان
تعداد زبان ها
دانش کاربردی کارکنان
استفاده از استاندارد
مشارکت مشتری
مهارت ابزاری کارکنان
استفاده از متدولوژی

4-4معیارهای ارزیابی109
برای ارزیابی کارایی تکنیکهای مختلف تخمین تلاش، از معیارهای متفاوتی استفاده میشود و ارزیابی یکی از موارد بسیار مهم در اثبات درستی تکنیکهای برآورد بشمار میرود. مهمترین و پرکاربردترین معیارهای ارزیابی در جدول شماره 4-3 بیان شدهاند. در این جدول علاوه بر شکل اختصاری هر یک از معیارها، نام کامل، فرمول و معنای آنها نیز آورده شده است (Benala et al., 2013; Benala et al., 2014; BouNassif, 2013).
جدول(4-3): معیارهای ارزیابی مدلهای تخمین
معنا
فرمول
نام کامل
نماد
خطای نسبی

Relative Error
RE
اندازه خطای نسبی

Magnitude of
Relative Error
MRE
میانگین اندازه خطای نسبی

Mean Magnitude
of Relative Error
MMRE
درصد تخمین

Percentage of the
Prediction
PRED

میانگین قدرمطلق خطای نسبی

Mean Absolute
Relative Error
MARE

در این فرمولها A بیانگر تعداد پروژه ها با MRE کمتر یا مساوی با X و N تعداد کل پروژههای بررسیشده است. سطح قابل قبول X در روشهای تخمین تلاش نرم افزار 25% است و روشهای مختلف براساس این سطح مقایسه میشوند.Estimation بیانگر مقدار تلاش تخمین زده شده توسط روشهای مختلف تخمین ومتغیر Actual مقدار تلاش واقعی هر یک از پروژه ها است.
4-5 اصول روش پیشنهادی
منطق روش مبتنی بر قیاس، استفاده از اطلاعات تاریخی پروژه های تکمیل شده و با تلاش شناخته شده است. این امر شامل موارد زیر است (Angelis and Stamelos, 2000):
مشخص کردن یک پروژه فعال جدید p که برآورد برای آن لازم است و بررسی بیشترین صفات (ویژگی های) مشترک به پروژه های تکمیل شده موجود در پایگاه آماری. ارزش و وزن ویژگی ها به طور معمول استاندارد شده است (بین 0 و 1) به طوری که درجه یکسانی از تاثیر بر نتیجه را داشته باشند.استفاده از این مشخصهها به عنوان پایه ای برای پیدا کردن پروژه های تکمیل شده مشابه که برای آنها تلاش واقعی شناخته شده است. این فرآیند را می توان با اندازه گیری فاصله بین دو پروژه، بر اساس ارزش ویژگیها به دست آورد. اگر چه تکنیک های متعددی را میتوان برای اندازهگیری شباهت استفاده کرد، الگوریتم های نزدیک ترین مجاور با استفاده از فاصله اقلیدسی110 به طور گسترده در مهندسی نرم افزار استفاده شده اند.ایجاد مقدار پیش بینی شده تلاش برای پروژه p بر اساس تلاش آن دسته از پروژه های انجام شده که مشابه p هستند. تعداد پروژه های مشابه معمولاً به اندازه مجموعه داده بستگی دارد. برای مجموعه داده های کوچک مقادیر معمول یک، دو و سه نزدیک ترین مجاور است. هنگام استفاد از این استراتژی باید در مورد چندین پارامتر تصمیم گیری کرد:
* انتخاب زیر مجموعه ویژگیها111
* اندازه گیری شباهت112
* مقیاس گذاری
* تعداد پروژهای مشابه113
* تطابق تناسبات
هر پارامتر به نوبه خود می تواند به جزئیات بیشتری تقسیم شود و ممکن است چندین پیکربندی را ممکن سازد. پارامترها در زیر توضیح داده شده اند.
4-5-1 انتخاب زیر مجموعه ویژگی
انتخاب زیر مجموعه ویژگی شامل تعیین زیر مجموعه بهینه ویژگی هایی است که دقیق ترین برآورد را بدسـت می دهند. یـک راه حل ناکارآمد این است که به صورت اختیاری همه زیر مجموعه های ممکن این ویژگیها را ارائه دهند.
4-5-2 اندازه گیری شباهت
اندازه گیری شباهت، سطح تشابه و نزدیکی میان موارد را اندازه گیری میکند. تا کنون چندین مقیاس شباهت در مطالعات پیشین مطرح شده است؛ با این حال، مشهورترین آنها فاصله اقلیدسی بی وزن، فاصله اقلیدسی وزن دار و فاصله حداکثر هستند. فاصله اقلیدسی بی وزن، فاصله اقلیدسی (خط مستقیم) d بین نقاط (x0,y0) و (x1,y1) را اندازه گیری میکند با توجه به این فرمول:

این اندازه گیری یک معنی هندسی دارد به عنوان فاصله دو نقطه در فضای اقلیدسی nبعدی. شکل شماره 12 این فاصله را با در نظر گرفتن مختصات نشان می دهد. همانگونه که مشخص است تعداد ویژگی های به کار رفته، تعداد ابعاد را تعیین می کند.

شکل(4-1): فاصله اقلیدسی وزن دار

فاصله اقلیدسی وزن دار هنگامی استفاده شده است که به بردارهای ویژگی وزن داده شده است که منعکس کننده اهمیت نسبی هر یک از ویژگی ها در میزان تلاش لازم است. فاصله اقلیدسی وزن دار d بین نقاط (xo,yo) و (x1,y1) با توجه به این فرمول داده شده:

که در آن و وزنهای x و y هستند.
مقیاس حداکثر بیشترین شباهت ویژگیها را محاسبه می کند و تعریف کننده نزدیک ترین تناسب است. برای دو نقطه (x0,y0) و (x1,y1)، مقیاس حداکثر d معادل فرمول زیر است:
(4-4)

این امر به طور موثر اندازه گیری شباهت را به یک ویژگی کاهش می دهد، اگر چه ویژگی حداکثر ممکن است برای هر قسمت بازیابی متفاوت باشد.
4-5-3 مقیاس گذاری
مقیاس گذاری و یا وزن دهی ویژگیها به معنی مشخص کردن میزان تاثیر هر یک از خصوصیات بر روی میزان تلاش است. تحقیقات زیادی تا کنون با استفاده از روشهای مختلف انجام شده تا بهترین و تاثیرگذارترین ویژگیها انتخاب شوند. واضح است که میزان تلاش لازم برای توسعه یک نرمافزار بطور یکسان از ویژگیهای مختلف پروژه متاثر نمیشود.
4-5-4 تعداد پروژههای مشابه
تعداد تناسبات اشاره دارد به تعداد موارد و پروژههای مشابهی که برای تولید برآورد استفاده می شوند. زمانی که مجموعه داده های کوچک استفاده می شوند در نظر گرفتن تنها تعداد کمی از شباهتها منطقی است. اما در پایگاه دادههای واقعی و بزرگ تعداد تناسب بیشتر شانس تخمین بهتر را بیشتر میکند.
4-5-5 تطابق تناسبات
پس از انتخاب مشابه ترین مورد، گام بعدی این است که تصمیم بگیرید که چگونه برای پروژه جدید p برآورد تولید کنید. روشهای مختلفی همچون نزدیکترین فاصله، میانه و یا میانگین مقادیر وجود دارد که میتوان هر یک وزنی را نیز نسبت داد. شکل زیر شِمای کلی از این گامها را نشان میدهد.

شکل(4-2) : شِمای کلی روش مبتنی بر قیاس
4-6 شمایی از مدل پیشنهادی
با توجه به توضیحات بخشهای قبل، هدف ما استفاده از روشهای ریاضی آماری برای تخمین تلاش لازم جهت توسعه نرم افزار می باشد یک مساله مهم و جدید در مدل پیشنهادی وجود دارد:
1. ایجاد یک خوشه و محلی سازی114 بر اساس خواص و ویژگیهای خاص پروژه نرم افزاری. نظر به اینکه روش مبتنی بر قیاس کامل ترین نوع تخمین است نیاز به یک نوآوری و بهبود جدی در این استراتژی میباشد. تمامی روشهای فعلی بر مبنای تکنیکهای هوش مصنوعی و داده کاوی به حل این مساله پرداختهاند و کمتر به ماهیت نرمافزاری کار توجه شده است. هدف این بخش در نظر گرفتن ویژگیهای نرم افزار در حال توسعه است. دو پارامتر مهم نوع برنامه و متد توسعه پروژه نـرم افزاری پیشنهاد خواهد شد که توسط آنها می توان کار تخمین را توسط روش های ریاضی و آماری شروع کرد.
2. اجرای متد تخمین بروی یکسری از خوشه ها و یا بعبارتی چیدن خوشه هایی و اجرای شیوه تخمین پیشنهادی بروی خوشه ها با توجه به اینکه به نظر می رسد متد پیشنهادی قابل پیاده سازی بروی تنها یکسری از پروژه ها باشد.
جدول(4-4): انواع متدهای توسعه پروژههای نرمافزاری
Waterfall
1
Traditional
2
Data modeling
3
Process modeling
4
Business area modeling
5
Event modeling
6
Standards (ISO 9000; CMM, CMMI)
7
Joint Application Development
8
Rapid Application Development
9
Prototyping
10
Object Oriented Analysis/Design, UML
11
Multifunction teams
12
Timeboxing, RUP, Agile
13
Reviews, inspections, walkthroughs
14
Specific testing techniques
15
جدول(4-5): انواع کاربردهای پروژههای نرمافزاری
Financial Transaction-Process/Accounting
1
Transaction/Production System
2
Management Information System
3
Process control, sensor control, real time
4
Financial
5
Executive information system, Decision support system
6
Billing
7
Network Management, Communications
8
Web, E-Business
9
Sales & Marketing
10
Ordering
11
Document management
12
Electronic Data Interchange
13

شکل (4-3): خوشه بندی بر اساس ویژگی های خاص پروژه های نرم افزاری
از این رو شمای مدل پیشنهادی را می توان با توجه به مطالب گفته شده به گونه ای در قالب فازهای زیر بیان کرد و در شکل 4-4 نشان داد.
فاز A: جمعآوری اولیه داده ها و تجزیه و تحلیل آنها و دلایل تخمینهای نامعتبر تلاش
فاز B: خوشه بندی پروژهها بر اساس نوع برنامه و متد توسعه (ویژگیهای نرم افزاری)
فاز C: استخراج ویژگیهای مهم و وزن دهی به آنها و قضاوت کارشناسان115 (ایجاد مدل اول)
فاز D: ارزیابی و محک مدلهای بدست آمده در قالب یک مدل کلی و تکنیکهای آماری

فصل 5
"نتیجه گیری و پیشنهادات آتی"

نتیجه گیری
در این پژوهش سعی کردیم تا به کمک محلی سازی برنامه و استفاده از روشهای ریاضی و آماری پیش بینی واقع بینانه تری برای تخمین تلاش داشته باشیم تا با کمک آن میزان تلاش لازم برای رسیدن پروژه به اهداف خود را با دقت بیشتری تخمین بزنیم. در کارهای گذشته متریکهای متفاوتی برای تخمین میزان تلاش نرمافزارها بیان شده بود ما تلاش کردیم تا با تخمین این متریک دقت را افزایش و توانایی کنترل مدیر را بالا ببریم. در این پژوهش سعی شد تا با در نظرگرفتن متریکهایی همچون نوع برنامه و متد توسعه نوعی خوشه سازی بین برنامه ها قرار داده و با استفاده از مدل پیشنهادی تخمین کار پیشبینی تلاش را بروی مواردی از پروژه ها انجام دهیم.
پیشنهادات آتی
با وجود فنون و ابزارهای مختلف در تخمین هزینه های پروژه بسیاری از برآورد های پروژه های نرم افزاری از دقت کمی برخوردارند . تام دی مارکو یکی از نویسندگان معروف توسعه نرم افزار 4 پیشنهاد برای این گونه بی دقتی ها و چگونگی چیره شدن برآنها را ارائه می دهد .
1 ـ تهیه و توسعه یک برآورد برای یک پروژه نرم افزاری بزرگ فعالیتی پیچیده است که کار زیادی را می طلبد . بسیاری از برآوردها باید به سرعت و پیش از تکمیل تعیین نیازمندی های کاربران تهیه شود .
2 ـ افرادی که براوردهای هزینه ای توسعه نرم افزار را تهیه می کنند تجربه کافی در این زمینه و بخصوص در پروژه های بزرگ را ندارند . استفاده از افراد مجرب در این زمینه و نیز نگهداری سوابق برآوردهای مالی پروژه های قبلی راه حل مناسبی برای حل این مشکل است .
3 ـ انسان ها گرایش به سمت برآورد مقدار کمتر ار دارند همچنین گاهی برآورد کننده ها برخی از هزینه های اضافی همچون یک پارچه سازی و آزمایش را فراموش می کنند .
4 ـ هرچندمدیران ممکن است بخواهندیک برآورد تهیه کنند امادرحقیقت به دنبال ارائه عددی هستند که آنها را در یک قرار داد برنده کنند. یا سرمایه داخلی را جذب کنند . دراین شرایط تهیه و ارائه برنامه زمانی و هزینه های فعالیت های نرم افزاری راهکارمناسبی به شمار می آید .
برآورد تلاش نرم افزار یک موضوع مهم برای تقریبا همه در صنعت نرم افزار در برخی از نقاط بوده است. اغلب اوقات شما می توانید برآورد های تلاش دقیق تر پس از تجزیه و تحلیل مورد نیاز را داشته باشید. با این حال، برآورد تلاش های اولیه در مراحل اولیه پروژه گاهی مهم تر است . بنابراین یک برآورد خوب از همان ابتدا مهم است بسیاری از تحقیقات در ساخت و ساز از مدل های برآورد تلاش نرم افزار رسمی متمرکز شده است. مدل های اولیه به طور معمول در تجزیه و تحلیل رگرسیون استوار بود و یا ریاضی را از تئوری های از حوزه های دیگر مشتق شده است. از آن زمان تعداد زیادی از روش های مدل سازی ارزیابی شده اند ، از جمله روشهای مبتنی بر مورد استدلال ، طبقه بندی و رگرسیون درختان، شبیه سازی، شبکه های عصبی ، آمار بیزی ، تجزیه و تحلیل واژگانی از مشخصات مورد نیاز ، برنامه نویسی ژنتیک ، برنامه ریزی خطی ، تولید اقتصادی تاسیس مدل ، محاسبات نرم، مدل سازی منطق فازی ، بوت استرپ آماری، و ترکیبی از دو یا بیشتر از این مدل . شاید روش های برآورد امروزه متداول هستند.
از این رو تخمین تلاش لازم جهت توسعه نرم افزار با استفاده از روش های ریاضی و آماری یکی از پیشنهادات برای انجام فرایند تخمین و بالا بردن افزیش دقت تخمین در این زمینه می باشد.

"اگر بتوانی چیزی را اندازه گیری کنی می توانی آن را مدیریت کنی!"
(If you can mesure it you can manage it!)

منابع
1. اس.پرسمن, پ. ر. (1382). مهندسی نرم افزار. تهران: گسترش علوم پایه.
2. پرسمن, ر. ا. (1382). مهندسی نرم افزار. تهران: گسترش علوم پایه.
3. تیموری, پ. (1388). مهندسی نرم افزار. تهران: پوران پژوهش.
4. سامرویل, ی. (1381). مهندسی نرم افزار. نشر علوم پایه: بابل.
5. شمس, ف. (1387). جزوه درسی مهندسی نرم افزار. تهران: دانشگاه شهید بهشتی دانشکده کامپیوتر.
6. لاودن جین پرایس، مترجم رضایی نژاد. (1377). نظام های اطلاعاتی مدیریت . تهران: خدمات فرهنگی سبا.

7. A. Idri, e. a. (2002). "Estimating Software Project Effort By Analogy Based On Linguistic Values,". Proceedings of the Eighth IEEE Symposium on SoftwareMetrics (METRICS.02)0-7695-1339-5 .
8. A.Gray, S. MacDonell. (1997). "A Comparison Of Techniques For Developing Predictive Models Of Software Metrics". Information and Software Technology , 39.
9. A.Kaushik, et al. (2013). "A Simple Neural Network Approach to Software Cost Estimation". Global Journal of Computer Science and Technology Neural & Artificial Intelligence , 22-31.
10. B. Barry, C. Abts, S. Chulani. (2000). "Software Development Cost Estimation Approaches-A Survey". Annals of Software Engineering .
11. B.Boehm. (1981). Software Engineering Economics. NJ: Englewood Clifs.
12. B.Boehm, et al. (1995). "Cost Model For Future Software Life Cycle Processes:Cocomo2,". Annals of software Engineering .
13. B.K. Singh and A.K.Misra. (2012). "Software Effort Estimation by Genetic Algorithm Tune Parameters of Modified Constructive Cost Model for NASA Software Projects". International Journal of Computer Applications , 22-26.
14. Bailey, J. W. and V. R. Basili. (1981). " A meta model for software development resource expenditure. Software Engineering (pp. 107-115). Intel.
15. Boehm, B. (2000). " Software Cost Estimation with COCOMO II". Upper Saddle Rive. New Jersey: Prentice Hall PTR.
16. D.V. Ferens, R.B. Gumer. (1992). "An Evaluation For Three Function Point ModelsOf Estimation Of Software Effort". IEEE National Aerospace and Electronics. IEEE .
17. F.Heemstra. (1992). Software cost estimation. Information and Software Technology , 627-639.
18. G Kim, e. a. (2004). Comparison Of Construction Cost Estimating Models BasedOn Regression Analysis, Neural Networks, And Case-Based Reasoning,". Elsevier , -.
19. G Kim,et al,. (2004). "Comparison Of Construction Cost Estimating Models Based On Regression Analysis, Neural Networks, And Case-Based Reasoning,". Elsevier .
20. G.stepanek. (2005). "Software Project Secrets: Why Software Projects Fail". Apress .
21. H. Demuth, M. Beale. (copyright 1992 – 2002). "Neural network toolbox for use with MATLAB,user's guide version 4, neural network toolbox user's guide,". Inc: MathWorks.
22. Huang, G. (2007, August 9). "Cost Modeling Based on Support Vector Regression for Complex roducts During the Early Design Phases". Requirements for the Degree of Doctor of Philosophy in Industrial and Systems Engineering .
23. Huang, G. (2007, August 9). Cost Modeling Based on Support Vector Regression for Complex roducts During the Early Design Phases. Requirements for the Degree of Doctor of Philosophy in Industrial and Systems Engineering .
24. K. Vinay Kumar,et al. (2008). "Software development cost estimation using wavelet neural networks" . The Journal of Systems and Software , 1853-1867.
25. K.Ramesh and P.Karunanidhi . (2013, March 3). " Literature Survey On Algorithmic And Non- Algorithmic Models For Software Development Effort Estimation" . International Journal Of Engineering And Computer Science(IJECS) , pp. 623-632.
26. Kemerer, C. (1987). "An Empirical Validation Of Software Cost Estimation Models". Communications of the ACM 30 , 416-429.
27. L. Putnam and W Myers. ( 1992). "Measures for Excellence". Yourdon Press Computing Series .
28. Laird, Linda M. (2006). Software Measurement and estimation apractical approach. John Wiley.
29. Merlo, N. (WS 2002 / 2003). COCOMO (Constructive Cost Model). Seminar on Software Cost Estimation.
30. Pressman, R. S. (2001). Software Engineering. McGraw-Hill Series in Computer Science.
31. Razaz, M. And King, J. (2004). "Introduction to Fuzzy Logic" . Information Systems – Signal and Image ProcessingGroup .
32. Reddy, P. (2010). "Particle Swarm Optimization in the fine-tuning of Fuzzy Software Cost Estimation Models" . International Journal of Software Engineering (IJSE) , 12-23.
33. S. Sandhu, P. Bassi. (2008). " Software Effort Estimation Using Soft Computing Techniques". World Academy of Science, Engineering and Technology , 46.
34. S.S.Vicinanza, et.al. (1991, December 12). "Software-Effort Estimation:An Exploratory Study Of Expert Performance". Information Systems , pp. 243-262.
35. Sh.Kumar, V. Chopra. (May 2013). "Neural Network and Fuzzy Logic based framework for Software Development Effort Estimation". International Journal of Advanced Research in Computer Science and Software Engineering , 759-763.
36. Sh.Wang ,L. Chen. (2009). "A PSO Algorithm Based on Orthogonal Test Design" . Fifth International Conference (pp. 190-194). ICNC 09: Natural Computation.
37. Shukla, K. ( 2000). " Neuro-genetic prediction of software development effort" . Information and Software Technology , 701-713.
38. T. S. Moon , et.al. (2007). "Enhanced Software Development Effort And Cost Estimation Using Fuzzy Logic Model". Malaysian Journal of Computer Science , 199-207.
39. Ziauddi, et.al. (2013, March 2). "A Fuzzy Logic Based Software Cost Estimation Model ". International Journal of Software Engineering and Its Applications , pp. .7-18.

1 -Effort estimation
2 – Artificial Neural Network
3 – Constructive Cost Model
4- Function Points
5 – Cost drivers
6 – Walston-Felix Model
7 – Bailey-Basili Model
8 – Mean Absolute Percentage Error (MAPE)
9 – Plan Business
10 – Stakeholder
11 – Project Plan
12 -End product
13 -Mainframes
14 -Multimedia simulation
15 – Software crisis
16 – Package
17 – Complexity
18 – abstraction
19 – Uncomplete requirements
20 – Technology changes rapidly
21 – Immature best practices
22 – Technology is a vast domain
23 – Incomplete technology experience
24 – Software Development is Research
25 – Automated Repetetive works
26 – reuseability
27 – Outsourcing
28 – Construction is Actually Design
29 – Changes considered easy
30 – Inevitable changes
31 – Process model
32 – Standard notation
33 – Software metrics
34 – CASE tools
35 – Development process
36 – Management process
37 – Maintenance process
38 – Validation
39 – Verification
40 – Critical Path Model(CPM)
41 -the linear Sequential Model
42 – Water Fall Model
43 – Incremental Methods
44 – Prototyping
45 – Rapid Application Development (RAD)
46 -Reusability
47 – Spiral Model
48 – Recursive
49- Customer communication
50 -planing
51 -Risk analysis
52 -Enginnering
53 -Construction & Release
54 -Costumer evaluation
55 – Component Based Software Development(CBSD)
56 -prepackaged
57 – Concurrent Development
58 -Client/Sever
59 -formal methods
60 -4GT-Forth Generation Tool
61 – Parallel Recursive Method
62 – Encapsulation
63 – Inheritac
64 – Polymorphism
65 – Seminal Methodology
66 – Integrated Methodology
67 – Agile methodology
68 – Visual Modeling
69 – Heavy Weight
70 – Light Weight
71 – Agile
72 -Amberella activiteis
73 -Quality Control
74 – Quality Assurance
75 -Configuration/Change Managment
76 – Software Measurements
77 – Risk management
78 -Structured estimation
79- Analytical estimation
80- Comparative estimation
81- Line of Code
82- Software Science
83 -Function points
84 -Feature Point
85 – Analogy costing
86 – Expert Judgment
87- Estimating by Analogy
88 -Parkinson
89 -Analytical
90- Empirical
91- Constructive Cost Model(COCOMO)
92- Software Life Cycle Management(SLIM)
93 -Effort Multiplier
94 -Scale Factors
95- Meta Heuristic
96- Wavelet neural network
97- Morlet
98- Training algorithm for wavelet neural network
99- Multilayer perceptron
100- Radial basis function network
101- Multi linear regression
102- Dynamic evolving neuro-fuzzy inference system
103- Support vector machine
104- Mean magnitude relative error
105- Canadian financial
106 -IBM data processing service
107- sigmoid
108 -Uniform range
109 – Evaluation criteria
110 -Euclidean Distance
111- Feature subset selection
112 -Similarity measure
113 -Number of analogies
114 -Localization
115- Expert judgment
—————

————————————————————

—————

————————————————————

60