[fariba]

اندازه‌گیری نرم‌افزار با استفاده از استاندارد ‌‌ COSMIC FFP 2003

اشاره :
یكی از مهم‌ترین مسائلی كه مدیران پروژه‌های نرم‌افزاری به آن توجه دارند استفاده از ابزارها ، تكنیك‌ها و روش‌های مختلف برای برآورد و كنترل‌‌ ‌راندمان كاری است. این عامل می‌تواند برای برآورد نیروی انسانی، مدت زمان مورد نیاز پروژه‌ها و برنامه‌ریزی بسیار سودمند باشد. دانستن اندازه نرم‌افزار قبل از تولید آن می‌تواند‌ ما را در این برآوردها یاری رساند. روش‌های مختلفی برای به دست آوردن اندازه نرم‌افزار وجود دارد از جمله: شمارش خطوط برنامه LOC) ،‌COCOMO) و ‌MKII. ولی تمام این روش‌ها دارای نقاط ضعف فراوانی هستند كه از آن میان می‌توان به عدم سازگاری با انواع مختلف نرم‌افزار و سختی محاسبه، اشاره كرد. (كه همگی آن‌ها به تفصیل در مقاله <�> در شماره 60‌ ماهنامه شبكه موردبررسی قرارگرفته‌اند.) از این رو بسیاری از متخصصان و استادان نرم‌افزار تلا‌ش‌كرده‌اند روش آسان و استانداردی را برای اندازه گیری نرم‌‌افزارهای امروزی پیدا كنند. ‌‌COSMIC-FFP روش استانداردی است برای اندازه‌گیری انواع مختلف نرم‌افزار با دقت عمل بالا و توانایی محاسبه از مراحل اولیه تولید تا نصب. این مقاله سعی دارد با طرح مثال‌های ساده، این استاندارد را بررسی كند.‌


برآورد نیروی كار موردنیاز و هزینه نرم افزار
یكی از اولین سوالاتی كه در شروع هر پروژه نرم‌افزاری مطرح می‌شود، هزینه تولید نرم‌افزار و اندازه آن است. برای محاسبه هزینه نرم‌افزار باید اندازه نرم‌افزار را پیدا كنیم. روش‌های مختلفی برای اندازه‌گیری اندازه نرم‌افزار وجود دارد؛ مثل اندازه خطوط برنامه. ولی ازآن جایی كه برنامه‌نویسان مختلف روش‌های متفاوتی در نوشتن كد دارند و دو برنامه با اندازه مختلف می‌تواند كارایی مشابهی داشته باشند، این روش استاندارد نیست. روش دیگری كه می‌توان از آن استفاده كرد، مشخص‌كردن كارایی و عملیات نرم‌افزار است. بدین ترتیب كه هر نرم‌افزار را با توجه به كارایی و پیچیدگی فنی آن اندازه‌گیری كنیم.
یكی از روش‌های معمول برای به دست آوردن این مقدار، استفاده از فرمول ‌‌Albrecht است كه با توجه به تعداد عملیات، كارایی و پیچیدگی فنی سیستم مقدار ‌Function Point) FP) را مشخص می كند. مثلا اگر برای یك نرم‌افزاری مقدار 68 به دست آید و فرض كنیم نوشتن هر ‌FP برای هر برنامه نویس به طور متوسط دو روز وقت می‌گیرد، تهیه این نرم افزار 136 روز طول خواهد كشید. در بسیاری از كشورهای جهان ازجمله كشور انگلستان، بیشتر قراردادهای نرم‌افزاری بر اساس‌‌ ‌FP بسته می‌شود و هزینه نرم‌افزار را با توجه به مقدار ‌FP برآورد می كنند. در این‌جا سعی شده است روش بهتری برای اندازه گیری نرم‌افزار بررسی شود. این روش‌ كه ‌COSMIC-FFP نام دارد، استاندارد جدید كشورهای اروپایی و امریكایی است.
نگاهی به استاندارد ‌‌COSMIC-FFP
گروه Common Software International Consortium) ‌‌COSMIC) در سال 1998 با هدف توسعه روش‌های اندازه‌گیری نرم‌افزار تشكیل شد. هدف عمده این گروه، ارائه روشی آسان برای تخمین اندازه و هزینه نرم‌افزار با‌توجه به نیازها و درخواست‌های كاربران است.

استاندارد ارائه‌شده این گروه برای اندازه‌گیری نرم‌افزار، ‌‌COSMIC-FFP است كه می‌توان با آن بسیاری از نرم‌افزارهای مالی (حسابداری، بانكداری و...)، نرم‌افزارهای‌ بلادرنگ (مثل نرم‌افزارهای مخابراتی) و نرم‌افزارهای چند‌منظوره را اندازه‌گیری نمود. با استفاده از این استاندارد امكان اندازه‌گیری نرم‌افزارهای گوناگون وجود ‌دارد. ولی نمی‌توان‌ نرم‌افزارهای بسیار پیچیده فنی را اندازه‌گیری كرد. یكی از نقاط قوت این استاندارد این است كه با استفاده از آن می‌توان اندازه تمامی اجزای نرم‌افزار را همان‌طور كه كاربر می‌بیند، محاسبه كرد.

[img]http://shabakeh-mag.com/data/gallery/s61_size_7.jpg[/img]
شكل 1- نمایش لایه‌ای معماری‌ نرم‌افزار

‌روش ‌‌COSMIC-FFP از دو مرحله تشكیل شده‌است كه شامل تعدادی رویه و اصول می‌باشد و می‌توان با آن اندازه نرم‌افزار را محاسبه نمود. در مرحله اول نیازهای كاربران ‌‌(System Specification) به مدل نرم افزاری ‌COSMIC-FFP تبدیل می‌شود و در مرحله دوم، اجزای این مدل، اندازه‌گیری می‌شوند.
قبل از محاسبه اندازه این اجزا، نرم‌افزار باید به فرم كلی ‌‌‌COSMIC در بیاید. فرم كلی ‌‌COSMIC لایه‌های نرم‌افزاری را مشخص می‌نماید وبهمحاسبه‌كننده كمك می‌كند با استفاده از این لایه‌ها، نیازهای استفاده‌كننده را طبقه‌بندی نماید. همان‌طور كه در شكل 1 مشاهده می‌كنید در این مثال، نیازهای مختلف به لایه های مختلف تعلق دارند.
‌پس از این مرحله، می‌توان این نیازها را به چند رویه‌كاری و چند مدل انتقال اطلاعات (‌خواندن‌، نوشتن‌، ورودی و خروجی‌) تقسیم‌نمود. بعد از این كار، قانون‌های اندازه‌گیری برروی این مدل‌ها اعمال می‌شود و مقدار عددی اندازه نرم‌افزار مشخص می‌شود. این مقدار عددی برحسب ‌‌Cfsu محاسبه می گردد.‌ ناگفته نماند كه ‌واحد اندازه‌گیری در این استاندارد، ‌یك Cosmic functional size unit) Cfsu) است.‌‌‌‌

‌مدل اصلی اندازه گیری در ‌COSMIC
شكل 2 مدل اصلی و روند محاسبه اندازه گیری نرم افزار با استفاده از این استاندارد را نشان می‌دهد. چنان كه دیده می‌شود، در این مدل اصلی محاسبه اندازه نرم‌افزار در استاندارد ‌COSMIC‌ نشان داده‌شده است. در ادامه تمامی اجزای این مدل از آغاز تا انجام با شرح مثال های ساده توضیح داده خواهد شد. ‌

[img]http://shabakeh-mag.com/data/gallery/s61_size_6.jpg[/img]
شكل‌2- مدل اصلی اندازه گیری‌

استخراج نیازهای كاربران
یكی از مهم‌ترین عوامل مورد توجه در اندازه‌گیری نرم‌‌افزار با ‌‌COSMIC امكاناتی است كه سیستم در اختیار استفاده‌كنندگان قرار می‌دهد و در واقع رویه‌ای است كه نرم‌افزار باید در پیش بگیرد تا درخواست‌ها و نیازهای كاربران را تامین كند.
برای استخراج این نیازها اكثر اوقات می‌توان به مستندات اولیه سیستم مراجعه نمود. البته در مواقعی هم كه مستندات برنامه وجود ندارد و نرم‌افزار نصب شده است، باز می‌توان این نیازها را از نرم‌افزار نصب شده استخراج نمود. شكل 3 منابع استخراج نیازهای كاربران از راه های ذكر شده را نشان می‌دهد.
برای مثال اگر سیستم مكانیزه كتابخانه را در‌نظر بگیرید، برخی از نیازهای كاربردی استفاده‌كنندگان را می‌توان به شرح زیر نام برد:

‌‌- كنترل كردن كارت عضویت ‌
- كنترل كردن پرونده امانات برای پیدا كردن كتاب‌هایی كه اعضا به امانت گرفته‌اند و بازنگردانده‌اند.‌

[img]http://shabakeh-mag.com/data/gallery/s61_size_15.jpg[/img]
شكل 3- منابع استخراج نیازهای كاربران در COSMIC ‌

- امانت كتاب
- برگشت كتاب توسط اعضا
همانطور كه مشاهده می‌كنید، استخراج نیازهای كاربران ‌‌‌‌(FUR) و عملیات سیستم كار مشكلی نیست. ولی قبل از هرگونه محاسبه نرم‌افزار (همان‌طور كه در شكل 2 نیز مشخص شده است)، دانستن اهداف اندازه‌گیری و محدوده آن اهمیت دارد.

هدف اندازه‌گیری، دلیل اندازه‌گیری و نوع استفاده از نتایج محاسبه را مشخص می‌كند. به عنوان نمونه در مثال سیستم كتابخانه، هدف از اندازه‌گیری را می توان به شرح زیر تعیین كرد:
‌دلیل اندازه گیری ‌‌
برای اندازه‌گیری‌ نیازهای كاربردی استفاده‌كنندگان (‌برای ورودی فرمول‌) و استفاده در رویه اندازه‌گیری (‌تخمین‌) میزان كوشش كاری برنامه‌نویسان سیستم.‌
محدوده اندازه گیری‌
محدوده اندازه‌گیری در واقع محدودیت‌ها و ملزومات یك اندازه‌گیری را مشخص می كند. برای مثال در سیستم كتابخانه این حدود به شرح زیر است: ‌ ‌- فقط نیازهای كاربران در دسترس است.‌
- زبان برنامه نویسی‌: جاوا‌
- پایگاه اطلاعاتی: اوراكل ‌
- برنامه نویسی شی گرا‌
-لایه‌های نرم‌افزاری: نرم‌افزار و پایگاه اطلاعاتی
‌عامل اولیه دیگری كه قبل از محاسبه اندازه نرم‌افزار الزامی به‌نظر می‌رسد، دید محاسبه‌كننده است. در این‌باره می‌توان دو دیدگاه را مورد‌بررسی‌قرار داد: نظر استفاده كننده سیستم و نظر برنامه‌نویسان و تهیه كنندگان نرم‌افزار.
این مسئله به عنوان نمونه در همان مثال در سیستم كتابخانه به شرح زیر است:
نظر استفاده كنندگان ‌
- استفاده‌كنندگان سیستم: دانشجویان و متصدی كتابخانه می باشند.‌
- این استفاده‌كنندگان فقط از بخشی از توانایی‌های سیستم اطلا‌ع دارند كه با آن كار می كنند. ‌
- اگر اندازه‌گیری نرم‌افزار از نظر این نوع استفاده كنندگان محاسبه شود، باید فقط اندازه اجزای سیستم كه كاربر با آن در تماس مستقیم است، محاسبه گردد.‌
نظر برنامه‌نویسان/ تولید كنندگان نرم‌افزار
دراین دیدگاه باید اندازه تمامی اجزای سیستم محاسبه شود. برای محاسبه و تخمین نیروی مورد‌نیاز و هزینه نرم‌افزار باید دید برنامه‌نویس مد‌نظر قرار می گیرد و تمامی اجزای سیستم در محاسبه در نظر گرفته شوند.

[img]http://www.shabakeh-mag.com/Data/Gallery/s61_size_13_s.jpg[/img]
شكل 4-مرحله‌ Mapping

‌مرحله ‌‌Mapping
‌ ‌همانطور كه در شكل 2 (‌مدل اصلی اندازه گیری) دیده می‌شود، مرحله اول این مدل، مرحله مقدماتی یا تبدیل نیازهای كاربران‌‌ ‌‌(FUR) به مدل عمومی ‌COSMIC است. این مرحله اصطلاحا مرحله‌‌ ‌Mapping نام دارد كه همان‌طور كه در شكل 4 مشاهده می كنید، ‌FURs را به مدل نرم‌افزاری عمومی ‌COSMIC تبدیل می كند.
در این مرحله با استفاده از روش ها و رویه های گوناگون، ورودی ‌‌‌‌(FUR) به مدل عمومی COSMIC كه مدل‌ مناسب‌تری برای محاسبه اندازه نرم‌افزار است، تبدیل می‌شود. در اندازه‌گیری نرم‌افزار سوالاتی مانند <�> ممكن است در ذهن پیش بیاید. به همین جهت ‌‌‌COSMIC پیشنهاد می‌كند كه از مدل‌ CONTEXT ‌استفاده شود. یعنی هر قسمت از سیستم ترسیم گردد و جریان اطلاعات در آن بررسی شود. ساده‌ترین مدل جریان اطلاعات در نرم‌افزار در شكل 5 نمایش داده شده است.‌

[img]http://shabakeh-mag.com/data/gallery/s61_size_4.jpg[/img]
شكل 5-مدل‌ اصلی‌جریان‌اطلاعات‌در نرم‌افزار

همانطور كه در شكل 5 مشاهده می كنید، نرم افزار به وسیله سخت افزار (صفحه كلید، نوار خوان و...) از یك سو و پایگاه اطلاعاتی (هارددیسك‌) از طرف دیگر احاطه شده است و دو انتها دارد: ‌انتهای جلویی ‌(Front-end) و انتهای عقبی (Back-end). در قسمت انتهای جلویی دو گروه انتقال اطلاعات وجود دارد: ورودی‌‌ ‌‌(entry) و خروجی‌‌ (exit).

ورودی همان اطلاعات وارد شده از طرف كاربر و خروجی نیز انتقال اطلاعات از سوی سیستم به كاربر است. در قسمت انتهای عقبی نیز دو گروه انتقال اطلاعات وجود دارد: نوشتن اطلاعات در پایگاه اطلاعاتی (‌توسط نرم‌افزار) و خواندن اطلاعات.
‌هدف ‌‌COSMIC اندازه‌گیری نرم‌افزار بر اساس ‌FURهای موجود است. وقتی ‌FURها مشخص شدند، می‌توانیم آن‌ها را به نرم‌افزار/سخت‌افزار موجود در سیستم ربط دهیم. ولی همان‌طور كه قبلا توضیح داده شد،‌‌ COSMIC ‌فقط به ‌FURهایی توجه دارد كه به نرم افزار مربوط می‌شوند. همان‌طور كه در شكل 6 مشاهده می كنید در نرم‌افزارهای بازرگانی امروزی نیازهای كاربران ‌FURها به لایه‌‌ ‌Application (نرم‌افزار) مرتبط می شوند. زیرا این لایه مستقیما با كاربر در ارتباط است.

[img]http://www.shabakeh-mag.com/Data/Gallery/s61_size_12_s.jpg[/img]
شكل 6- مدل جریان اطلاعات در نرم افزار چند لایه‌ای

مرزهای نرم افزار و رویه های كاربردی
تعیین‌كردن مرزهای نرم‌افزار با نوع، هدف و دیدگاه اندازه‌گیری (‌استفاده كننده/‌برنامه‌نویس) ارتباط مستقیم دارد. مرزهای نرم‌افزاری در واقع اینترفیس‌هایی هستند در میان نرم‌افزار و استفاده‌كننده؛ منظور از استفاده‌كننده می‌تواند لایه دیگری از نرم‌افزار یا همان كاربر باشد. برای مشخص‌كردن مرز نرم‌افزاری و رفع ابهام، ‌‌COSMIC پیشنهاد می‌كند دو عامل را در نظر بگیریم: كسی یا قسمتی از نرم‌افزار كه بخشی را فعال می‌كند (باعث رویدادی می‌شود) و قسمتی كه تحت تاثیر قرار می گیرد (‌رویه عملیاتی). مرز نرم‌افزار بین این دو قرار دارد. البته دیدگاه اندازه‌گیری در اینجا مهم است و تفاوت در دیدگاه اندازه‌گیری این مرز را تغییرمی‌دهد. مثلا وقتی از دیدگاه استفاده‌كننده سیستم نگاه می‌كنیم، دو مرز وجود دارد: بین نرم‌افزار و كاربر و بین نرم‌افزار و پایگاه اطلاعاتی ( شكل 5).
برای وضوح بیشتر یك وب‌سایت را از دید كاربر تجسم كنید. كاربر برروی یك لینك كلیك می‌نماید و محتویات صفحه را مشاهده می كند. ولی اگر این وب سایت را از دید یك طراح وب در نظر بگیرید، هر لینك عامل سه حركت اطلاعات می‌گردد. همان‌طور كه قبلا اشاره شد، اطلاعات در هر لایه در حركت هستند (‌خواندن‌، نوشتن‌، ورودی و خروجی) ولی لزوما این امر بدین معنا نیست كه خروج اطلاعات دائما به سمت كاربر باشد.

مثلا اگر بخواهیم اطلاعاتی را برروی پایگاه‌اطلاعاتی ذخیره كنیم (‌نوشتن یا‌ Write)، در واقع این عمل نوشتن به‌وسیله لایه نرم‌افزار یك ورودی ‌‌‌(Entry) اطلاعات به لایه پایگاه اطلاعاتی است. ولی در مورد خواندن اطلاعات ‌(Read) ‌از پایگاه اطلاعاتی، مسئله پیچیده‌تر از خواندن اطلاعات می‌شود. همانطور كه در شكل 7 می‌بینید وقتی یك جستجو از طرف لایه ‌‌Application درخواست می‌شود، این درخواست در واقع یك ورودی است از طرف لایه و خواندن‌‌‌اطلاعات، در واقع توسط لایه ‌‌ ‌Device Driver هدایت و كنترل می‌گردد.

[img]http://shabakeh-mag.com/data/gallery/s61_size_11.jpg[/img]
شكل 7- جستجو توسط‌ لایه
‌
‌ همانطور كه در شكل 7 مشاهده می‌كنید، یك ورودی ‌‌‌‌(E: Entry) باعث به وجود آمدن دو حركت می‌شود: خواندن
‌‌‌(R: Read)‌ از پایگاه اطلاعاتی از لایه ‌Device Driver و خروج ‌‌‌(X: Exit) به لایه‌‌ Application.

پس از شناسایی مرزهای نرم‌افزار (همان‌طور كه در شكل 2 مشخص شده) مرحله شناسایی رویه‌های كاربردی قراردارد. شناسایی یك رویه كاربردی یا ‌‌Functional process كار سختی نیست.
در واقع یك رویه كاربردی قسمتی از نیازهای كاربران است كه توسط آنان از سیستم در‌خواست می‌شود و باعث حركت اطلاعات می‌شود و تا وقتی تمام نیازهای كاربر را فراهم نكند، این رویه ادامه دارد.

یك رویه كاربردی حداقل شامل دو حركت اطلاعات می باشد (‌یك ورودی: ‌ ‌E و یك خروجی:‌‌ X) نوشتن اطلاعات (W)، فقط متعلق به یك لایه می باشد و دارای تعدادی رویداد‌‌ ‌Events است. مثلا در سیستم كتابخانه اگر فرض كنیم كه هدف یك رویه كاربردی، ایجاد یك عضو جدید است، می توان رویدادهای زیر را در نظر گرفت:

[img]http://www.shabakeh-mag.com/Data/Gallery/s61_size_8_s.jpg[/img]
شكل 8- مدل كنترل‌كردن كارت عضویت كتابخانه

یك ورودی: ‌‌ 1 X Entry(اطلاعات عضو جدید)‌
یك نوشتن: ‌‌ 1X Write(نوشتن اطلاعات عضو در پایگاه اطلاعاتی) ‌
یك خروجی: ‌‌ ‌1X Exit(پیغام خطا یا تایید ثبت اطلاعات عضو) ‌‌ ‌‌
‌یكی دیگر از نیازهای كاربران در سیستم كتابخانه، كنترل‌كردن كارت عضویت است. اگر بخواهیم این رویه را به صورت مدل نشان دهیم، شكل 8 را می توانیم ترسیم كنیم. ‌
مراحل زیر را می توانید در شكل 8 به وضوح مشاهده كنید:
‌‌ 1X Entry- (از كاربر به لایه‌Application )
1X Exit - ‌از لایه (‌Application ‌به سیستم مدیریت پایگاه اطلاعاتی رابطه ای یا‌ ‌RDBMS)
‌‌ 1X Entry- (به‌‌ ‌RDBMS)
- 1X Read (از پایگاه اطلاعاتی) ‌
‌-‌‌ 1X Exit (از ‌‌RDBMS به لایه‌ Application)
- 1X Entry (به لایه‌ Application)
-‌‌ 1X Exit (پیغام به كاربر) ‌

[img]http://www.shabakeh-mag.com/Data/Gallery/s61_size_9_s.jpg[/img]
شكل 9- مدل‌‌ ‌ERD سیستم كتابخانه

شناسایی جهت انتقال اطلاعات
اولین قدم برای شناسایی جهت انتقال اطلاعات در سیستم، طراحی Entity Relationship Diagram) ‌‌ERD) یا مدل
پایگاه اطلاعاتی رابطه‌ای است. (شكل 9 )

در ‌‌COSMIC جهت انتقال اطلاعات، براساس نیاز رویه كاربردی به انتقال اطلاعات تعیین می‌گردد.

مثلا اگر فرض كنید یك رویه ‌‌‌‌(Functional Process) به گرفتن اطلاعات از بانك اطلاعاتی امانات نیاز دارد، شكل 10 را می‌توان ترسیم نمود.


[img]http://shabakeh-mag.com/data/gallery/s61_size_3.jpg[/img]
شكل 10- جهت انتقال اطلاعات‌

مرحله آخر
وقتی جهت حركت اطلاعات مشخص گردید، طبق مدل اصلی اندازه گیری (شكل 2) باید از توابع اندازه‌گیری استفاده نماییم و مجموع اندازه ها را محاسبه كنیم. در این مرحله ما درقبال یك حركت اطلاعات یك واحد Cfsu را در نظر می گیریم. در نتیجه
1X data movment (E/X/R/W) = 1 CFSU
مثلا اگر در قسمتی، پنج‌ حركت اطلاعات وجود دارد، پنج واحد‌Cfsu داریم. پس فرمول كلی اندازه‌گیری یك رویه كاربردی را می توان به صورت زیر در نظر گرفت:
[img]http://www.shabakeh-mag.com/Data/Gallery/s61_vv_1_s.jpg[/img]

[img]http://www.shabakeh-mag.com/Data/Gallery/s61_size_17_s.jpg[/img]
شكل 11-بانك‌های‌ اطلاعاتی‌ مورد نیاز

اندازه یك لایه نرم‌افزاری را نیز می‌توان از حاصل جمع اندازه رویه های كاربردی‌ ( Functional Process) ‌به دست آورد. پس اگر در لایه نرم‌افزاری ما، دو رویه ‌‌A و ‌B وجود داشته باشد و هر كدام‌ 4Cfsu باشند، اندازه لایه 8‌Cfs می‌باشد.

برای یادگیری هر چه بیشتر این استاندارد به مثال زیر توجه كنید: در قسمتی از مستندات سیستم كتابخانه ذكر شده، سیستم باید قادر باشد برگشت كتاب‌ها به كتابخانه و حذف این كتاب‌ها از فهرست امانات را ثبت كند.

[img]http://shabakeh-mag.com/data/gallery/s61_size_20.jpg[/img]
شكل 12- مدل اصلی سیستم در ‌‌COSMIC

ولی باید یك ركورد از این امانت در بانك اطلاعاتی دیگری نیز ذخیره‌گردد تا متصدی كتابخانه بتواند در آینده به آن مراجعه كند. به نظر شما چند‌‌ Cfsu ‌در این قسمت از مستندات سیستم وجود دارد ( از نظر برنامه‌نویس)؟
جواب: قبل از هر چیز لایه‌های نرم‌افزاری را مشخص می‌كنیم. سپس رویه‌های كاربردی و حركت اطلاعات را مشخص و برای حركت هر كدام یك‌‌ ‌Cfsu در نظر می گیریم. در قسمت اول مسئله گروه های اطلاعاتی (‌بانك‌های اطلاعاتی ) كه در این قسمت موردنیاز است، مشخص می كنیم. (‌شكل 11)
همان‌طور كه در شكل 11 مشاهده می‌كنید، دو بانك‌اطلاعاتی وجود دارد كه برای حذف اطلاعات امانات و افزودن ركورد اطلاعات امانات در تاریخچه امانات مستقیما با آن‌ها در ارتباط هستیم. اگر فرض كنیم دو لایه اصلی
‌‌(Application و RDBMS) در این نرم‌افزار وجود دارد، مدل ما چیزی شبیه شكل 12 خواهد بود. حال حركات اطلاعات را در این مدل دنبال می‌كنیم :
- كاربر اطلاعات عضو را وارد می‌كند. یك حركت از كاربر به لایه اول، در نتیجه:‌ ‌‌.1X Entry
- یك خروج اطلاعات از لایه اول به لایه دوم. در نتیجه: 1X Exit.
- یك ورود به ‌ ‌RDBMS برای حذف اطلاعات امانات. در نتیجه: 1X Entry.
‌- یك نوشتن در بانك اطلاعاتی امانات ( در واقع حذف را می توان یك نوع Write ‌دانست). در نتیجه: 1X Write ‌
- یك نوشتن در بانك اطلاعاتی تاریخچه امانات. در نتیجه: 1X Write.
- خروج از لایه دوم به لایه اول‌. در نتیجه: ‌‌1X Exit.
- ورود به لایه اول. در نتیجه:1X Entry.
- خروج از لایه اول و نمایش تایید حذف اطلاعات به كاربر. در نتیجه: 1X Exit.
حال می توانیم مقادیر بالا را در فرمول‌ ‌COSMIC-FFP قرار دهیم و اندازه‌‌ ‌‌ Cfsu را برای این قسمت از سیستم محاسبه كنیم:
= (1+1) + (0) + (1+1+1) + (1+1+Size (Cfsu) of Functional process A= (1
‌(8Cfsu (COSMIC-FFP v2.2
نتیجه ‌‌8Cfsu شد كه با ذكر نسخه ‌‌COSMIC-FFP استفاده شده در محاسبه نوشته می شود. حال كه اندازه نرم‌افزار در واحد ‌‌Cfsu به دست آمد، می‌توانیم اندازه كار مورد نیاز برای تهیه این قسمت از نرم‌افزار را محاسبه كنیم. برای محاسبه كار ‌‌(Effort) به یك عامل دیگر نیز نیاز داریم و آن درصد راندمان نیروی كار است. برای محاسبه این عامل بهترین مرجع را می‌توان اطلاعات پروژه های قبلی دانست. ولی به طور متوسط این مقدار بین 5/0 تا 7/0 از حداكثر 1 (100 درصد) است. مثلا در پروژهای قبلی هر برنامه‌نویس برای نوشتن یك‌ ‌20Cfsu ساعت (‌2 روز) وقت صرف كرده‌است. پس اگر همان برنامه‌نویس بخواهد نرم‌افزاری را با مجموع ‌‌‌ 36Cfsu تهیه كند، در 720 ساعت این نرم‌افزار به اتمام خواهد رسید.
نتیجه‌گیری‌
اندازه‌گیری نرم‌افزار به روش ‌COSMIC-FFP یكی از ساده‌ترین و استانداردترین روش‌های موجود در مهندسی نرم‌افزار است. با این روش می‌توان بسیاری از نرم‌افزارهای امروزی از وب سایت تا نرم‌افزاری ‌بلا‌درنگ را اندازه گیری نمود. از جمله مزایای این استاندارد می‌توان به آسانی، درستی محاسبه و توانایی كار با آن از ابتدایی‌ترین مرحله چرخه تولید نرم‌افزار اشاره كرد. اضافه بر این، می‌توان با این روش حتی قسمت كوچكی از نرم افزار را هم اندازه‌گیری نمود. اگرچه این استاندار امروزه بسیار مورد استقبال قرار گرفته و بسیاری از شركت‌های نرم‌افزاری دنیا از آن استفاده می كنند، برخی از قسمت های آن هنوز مبهم به نظر می‌رسد.
از آن جمله می‌توان از تشخیص لایه‌های نرم‌افزاری یا تعیین مرز بین لایه‌ها نام برد كه محاسبه كننده را ملزم به آشنایی كامل با اجزای تشكیل دهنده نرم افزار قبل از محاسبه می كند. اشتباه در انتخاب لایه ها و مرز بین آن‌ها باعث خواهد شد اندازه نرم‌افزار به اشتباه محاسبه شود. با این حال استفاده‌كنندگان از این استاندارد هر روز بیشتر می شوند. آموزش اندازه‌گیری نرم افزار با ‌‌COSMIC از سال 2004 در اكثر رشته‌های مهندسی نرم‌افزار دانشگاه‌های اروپا در كنار روش‌های قدیمی مثل ‌MKII‌ و ‌COCOMO تدریس می‌شود و امید است روزی این استاندارد جای خود را به روش‌های قدیمی متداول بدهد.
مطالعه منابع معرفی‌شده نیز به شما كمك خواهد كرد مبانی اندازه‌گیری نرم‌افزار با ‌COSMIC-FFP را كه در این مقاله بحث شد، بهتر یاد بگیرید. ‌
منابع :
‌www.cosmicon.com
‌www.cosmicon.com/overview.asp

-- ماهنامه شبکه