کلمات کلیدی: نرمافزار، خطوط برنامه، تخمین زمان، COCOMO ، SLOC
این مقاله به بررسی چرخه حیات نرمافزار پرداخته و فرایندهایی كه جهت ارزیابی حجم پروژههای طراحی شده به كار میروند را مورد مطالعه قرار میدهد.
برآورد بهای نرمافزار
بالغ بر 20000 پروژه تحقیقاتی در زمینه توسعه نرمافزار صورت گرفته و تحقیقات مربوط به این فرایندها تقریباً 18 سال به طور انجامیده است. با مطالعه كلیه این پروژهها میتوان دریافت كه هیچ یك از آنها از ارزش كافی برخوردار نیستند و همواره دچار مشكلات تكنیكی، سیاسی و ضعف توسعه تیمی میباشند. تاكنون شمار اندكی از شرکتها و متخصصان به این نتیجه رسیدهاند كه ارزیابی و بررسی جنبههای گوناگون نرمافزار را میتوان به عنوان یك دانش تلقی كرد.
در این مقاله با ارائه راهكارهایی مؤثر تلاش میكنیم تا برخی ابزارهای مورد نیاز را به منظور ارزیابی ارزش و زمانبندی پروژهها در اختیار شما قرار دهیم. با وجود آنکه ابزارهای فراوانی در زمینه برآورد بهای نرمافزارها وجود دارند، اما ما در این مقاله صرفاً به ذكر مفاهیم و سیستمهای بنیادی اكتفا میكنیم و از بررسی ابزارهای پیشرفتهتر صرفنظر مینماییم.
نخست، بررسی خود را با شیوههای گوناگونی كه جهت ارزیابی اندازه و ابعاد یك برنامه معین به كار میروند، آغاز میکنیم و در راستای آن به ذكر برخی از ابزارهای قدیمی از قبیل Function Points (نقاط تابع) و Lines of code (تعداد خطوط برنامه) به انضمام یك سری دیدگاههای نوین در این زمینه میپردازیم.
در پایان مقاله نیز با استفاده از همین اطلاعات، شما را برای یك ارزیابی خام و مقدماتی آماده میكنیم.
ارزیابی چرخه حیات
پیش از پرداختن به این مقوله ابتدا لازم است، محدودیتهای عمدهای را كه در زمینه برآورد ارزش نرمافزارها وجود دارند مورد بررسی قرار دهیم. همانطور كه در شكل مشاهده می كنید، درجه دقت برآورد ارزشها بر مبنای میزان پیشرفت هر نرمافزار، كاملاً متغیر است.
در ابتدا عدم قطعیت در ارزیابی، به نحو قابل توجهی، متأثر از تفاوتهای پارامترهای ورودی میباشد اما پس از آن، مقدار عدم قطعیت به تفاوت در مدلهای ارزیابی وابسته خواهد شد. در مرحله مفهوم ممكن است با تعریف مبهمی از پروژه مواجه شوید و حتی در ادامه مراحل نیز، امكان عدم درك كامل این مفهوم وجود داشته باشد. اما به هر ترتیب، هدف اصلی نرمافزار جدید، واضح و كاملاً مشخص خواهد بود. در این مرحله، میزان دقت برای یك آمارگیر باتجربه كه از تکنیکهای غیر رسمی استفاده كرده است با تخمین 50% گزارش میشود.
پس از آشنایی و درك كامل مقررات موجود امكان ارائه یك ارزیابی مناسب به شكل یك تابع میسر خواهد بود. در این مرحله ارزیابیها با یك دقت 25٪ برای یك آمارگیر مجرب گزارش میشود.
در نهایت پس از تكمیل جزئیات این طرح امكان ارزیابی مبتنی بر اجرا میسر خواهد بود. میزان دقت این ارزیابی غالباً با رقم 10٪ گزارش میشود.
درك اهمیت برآوردهای مجدد دورهای در طول چرخه حیات پروژه مقوله بسیار مهمی است و شناسایی مشكلات در همان مراحل اولیه سبب انجام اقدامات صحیح گامهای بعدی میشود.
برآورد حجم برنامه
بررسی ابعاد و حجم به عنوان نخستین گام در اجرای یك ارزیابی همه جانبه محسوب میشود. شمارش تعداد خطوط برنامه مبداء یا SLOC یكی از راههای سنجش حجم برنامه میباشد. SLOC تعداد خطوطی است كه توسط انسان نوشته میشود و فاقد خطوط نانوشته و بدون متن است. چنانچه در یك فرایند هر كد چند بار تكرار شود از شمارش خطوط همسان خودداری كنید. معمولاً هنگامی ارزشیابی با هزاران SLOC یا KSLOC سروكار خواهیم داشت. مدل COCMO یا Constructive Cost Model متد SLOC را به عنوان یك استاندارد ارزیابی معرفی می كند. اصول اولیه این مدل به همراه مدل جدید COCOMOII در بسیاری از شیوههای متداول ارزشیابی به كارمیروند.
اكنون كمی به جلوتر میرویم و نحوه بهکارگیری SLOC را در ارزیابی پروژه مورد نظر بررسی مینماییم و در مراحل بعد موارد كاربرد ارزیابی SLOC را در سایر فرایندها برمیشماریم.
مطالعه خود را با سادهترین نوع ارزیابی آغاز میكنیم. اگر از شمار SLOC كه توسط سیستمها آشكار شدهاند، آگاه باشید و تلاش مورد نیاز برای هر SLOC را برآورد نمایید در آن صورت با ضرب این دو عدد در یكدیگر به تعداد ماههایی كه برای تكمیل این پروژه لازم است دست مییابید. (مدت زمانی كه شخص برای كامل كردن پروژه تلاش میکند). در واقع مفهوم فوق به عنوان قلب كلیه مدلهای ارزشیابی تلقی میگردد. در جدول زیر برخی از مهمترین مقادیری را كه در ارتباط با فاكتور خطی بازدهی از سوی محققان گزارش شدهاند، مشاهده میكنید.
Project Type |
Linear Productivity Factor |
COCOMO II Default |
2.94 |
Embedded development |
2.58 |
E-Commerce development |
3.60 |
Web development |
3.30 |
Military development |
2.77 |
فرض كنید كه قصد تأسیس یك سیستم تجاری شامل 15000 خط کد را داریم. اكنون بر اساس معادلات فوق ساخت چنین سیستمی چندماه به طول میانجامد؟
برای پاسخ به سوال مطرح شده میتوان به طریق زیر عمل نمود:
54 ماه تلاش فردی = تلاش مورد نیاز برای تكمیل پروژه = 15 * 60/3 = SLOC * میزان بازدهی برای تكمیل پروژه
اگر كلیه پروژههای شما به همین اندازه كوچك باشند معادله فوق را میتوانید به آنها تعمیم دهید.
محققان دریافتهاند كه میزان بازدهی در ارتباط با ابعاد پروژه است و به صورت متغیری از بزرگی پروژه معرفی میشود. در واقع پروژههای عظیم در مقایسه با طرحهای كوچكتر از بازدهی بسیار كمتری برخوردار هستند. علت این امر را میتوان به افزایش ساعات زمانی جهت ایجاد ارتباط و هماهنگی میان تیمهای تحقیقاتی پروژههای بزرگ و صرف انرژی و وقت بیشتر برای سوء تفاهمهای موجود نسبت داد.
به این ترتیب میزان بازدهی همزمان با افزایش ابعاد پروژه كاهش مییابد و ما شاهد رشد مقدار KSLOC و ارتقا آن به عددی بزرگتر از 1.0 خواهیم بود. این فاكتور نمایی در نهایت موجب جبران بازدهی ضعیف و تنزل یافته پروژههای عظیم میشود. در جدول زیر فاكتورهای نمایی متعلق به انواع مختلف پروژهها درج شده است.
Project Type |
Exponential Size Penalty Factor |
COCOMO II Default |
1.052 |
Embedded development |
1.110 |
E-Commerce development |
1.030 |
Web development |
1.030 |
Military development |
1.072 |
به این ترتیب پس از ایجاد تنظیمات و هماهنگی مورد نیاز كه به نوعی كاهش بازدهی ناشی از ابعاد پروژه را جبران میكند اكنون باید تعداد ماههایی كه صرف تولید 15000 خط کد این سیستم تجاری میشود را به دست آوریم. برای این منظور از روش زیر استفاده میکنیم:
عدد 6/58 بیانگر ماههایی است كه برای تولید خطوط فوق تلاش میكند 58.6 = 16.27 * 3.60 = 15 * 3.60 = تابع نمایی جبران كننده KSLOC * میزان بازدهی.
همانطور كه مشاهده میكنید كلیه مطالب فوق كاملاً شفاف و قابل درك میباشند. اما پرسشی كه مطرح میشود این است كه چگونه میتوان از كامل شدن یك پروژه به صورت SLOC 15.000 اطمینان حاصل نمود؟
دو دیدگاه اساسی برای پاسخ به این سوال وجود دارد كه در ادامه مقاله به آنها اشاره میكنیم. این دو روش عبارتند از :
- ارزیابی و محاسبه مستقیم
- كاركردن با نقاطی كه به طور غیرمستقیم و معكوس ما را به سوی هدف اصلی سوق دهد.
به كار بردن هر یك از دو دیدگاه فوق سبب شناسایی متغیرهای ورودی اصلی از سوی متخصص میشود. مقصود از متخصص شخص یا شركتی است كه نرمافزار خاصی را طراحی میكند. تكنیك دلفی راهكار سودمندی جهت ارزیابی متغیرهای ورودی است.
به طور طبیعی نخستین مرحله از فرایند ارزیابی تعداد خطوط، تفكیك ساختار كلی پروژه به واحدهای كوچكتر یا گروههای منطقی مشخص میباشد. مثلاً این تفكیك میتواند در قالب فرایندهای رابط کاربر، فرایندهای لایه میانی و كدگذاری پایگاهداده انجام گیرد. متخصصانی كه در زمینه طراحی برنامههای نرمافزاری فعالیت میكنند، به كمك تجربه حاصل از تولید سیستمهای مشابه قادر به ارزیابی خطوط مورد نیاز خواهند بود.
انجام سه ارزیابی مجزا برای هر متغیر ورودی اكیداً توصیه میشود. این سه ارزیابی عبارتند از: برآورد بهترین مورد یا best-caseestimate ، برآورد بدترین مورد یا worst-case estimate و ارزیابی مورد پیشبینی شده (مورد انتظار). با دانستن این سه ورودی امكان محاسبه میانگین و انحراف استاندارد میسر خواهد بود:
انحراف معیار میزان انحراف مورد انتظار عدد نهایی را نشان میدهد. مثلاً مقدار میانگین به علاوه 3 برابر انحراف معیار محاسبه شده گویای این نكته است كه پروژه شما به احتمال 99٪ با برآوردهای انجام گرفته مطابقت دارد و تحت این ارزیابیها قابل اجرا میباشد. برای كسب اطلاعات بیشتر به منبع شماره [2] مراجعه کنید.
ارزیابی نقاط تابعی
بهكارگیری نقاط تابعی راهكار مناسبی جهت ارزشیابی مستقیم SLOC میباشد. در این دیدگاه از یك فرایند معكوس یا بازگشتی به منظور تبدیل نقاط تابعی به SLOC استفاده میشود. نقاط تابعی نخستین بار توسط آی بی ام برای بررسی حجم یك برنامه معرفی شد. در این روش عملكرد برنامه بر اساس تعداد راههایی كه برای برقراری ارتباط كاربران با آن وجود دارد مورد ارزیابی قرار میگیرد.
به منظور تعیین شمار نقاط تابعی ابتدا باید تعداد ورودیهای خارجی، فایلهای رابط کاربری خارجی، پرس و جوی خارجی و جداول منطقی درونی را بررسی نمود.
ورودیهای خارجی بخش قابل توجهی از دادههای ثبت شده را به خود اختصاص میدهند. اگر هر یك از صفحات حاوی دادههای ورودی جدول بندی شده باشند در این صورت هر جدول را میتوان به صورت بك ورودی خارجی مستقل شمارش نمود. فایلهای رابط کاربری خارجی به آن دسته از فایلها اطلاق میشود كه بر مبنای دادههای ورودی یا خروجی طراحی میشود. قالب ركورد ثبت شده در فایل XML است و نوع هر داده به عنوان یك فایل رابط کاربری مجزا در نظر گرفته میشود، حتی اگر در فایل یكسانی وجود داشته باشند. خروجیهای ثبت شده نیز به عنوان گزارشهای پروژه محسوب میشوند. پرسوجوی خارجی نوعی تابع یا پیام خارجی هستند كه بر مبنای نوع عملكرد شما اطلاعاتی را به داخل سیستم یا خارج از آن مخابره میكنند. در نهایت جداول درونی منطقی بیانگر تعداد جدولهای واقع در پایگاهداده است با این فرض كه پایگاهداده مورد بررسی در فرم نرمال سوم یا بالاتر میباشد.
به منظور استفاده از مقادیر اولیه جهت نقاط تابعی لازم است آنها را در یك فاكتور تبدیل (كه این مقادیر را به نقاط تابعی تبدیل میكند) ضرب كنیم. در جدول زیر فاكتور تبدیل نقاط تابعی را مشاهده مینمایید:
Raw Type |
Function Point Conversion Factor |
External inputs |
4 |
External interface files |
7 |
External outputs |
5 |
External queries |
4 |
Logical internal tables |
10 |
به این ترتیب اگر سیستمی حاوی 25 صفحه دریافت ورودی، 5 فایل رابط کاربری، 15 گزارش، 10 پرسوجوی خارجی و 20 جدول درونی منطقی داشته باشیم . تعداد نقاط تابعی موجود به قرار زیر خواهد بود:
نقطه تابعی 450=(10*20)+(4*10)+(5*15)+(5*7)+(4*25)
تنها مرحله باقی مانده تبدیل تابعی به یك رقم همارز از SLOC میباشد. برای این منظور از جدولی كه حاوی زبانهای برنامهنویسی و مقدار SLOC همارز هر یك از آنها است استفاده میکنیم. در جدول زیر برخی از مقادیر متداول درج شده است.
Language |
SLOC per Function Point |
C++ default |
53 |
Cobol default |
107 |
Delphi 5 |
18 |
HTML 4 |
14 |
Java 2 default |
46 |
Visual Basic 6 |
24 |
SQL default |
13 |
بنابراین برای اجرای پروژه مذكور (450 نقطه تابعی) با استفاده از زبان برنامهنویسی Java2 تقریباً به 700=46*450 SLOC نیاز داریم. چنانچه این پروژه در قالب یك سیستم تجاری باشد مدت زمانی كه صرف تكمیل اجرای آن میشود به قرار زیر خواهد بود.
82 ماه تلاش برای تكمیل پروژه= زمان تكمیل طرح = 22.67 * 3.60 = 20.7 1.030 * 3.60 = تابع جبران كننده KSLOC * قابلیت بازدهی
همانطور كه پیشتر نیز اشاره شد راهكارهای دیگری برای محاسبه مقدار همارز SLOC از طریق مقادیر دادههای ورودی وجود دارد. از میان این روشها میتوان به شیوه نقاط اینترنتی، نقاط دامنه و نقاط class-method اشاره نمود. كلیه این روش ها در فضایی مشابه با نقاط تابعی عمل میكنند.
منابع:
[1] Estimate Software Costs – Author : William Roetzheim - Cost Xpert Group, Inc
[2]Software Engineering and Project Management, Boehm B.IEEE Press, 1987