تخمین هزینه و زمان در پروژه‌های نرم‌افزاری

نويسنده : حميد مشرف (كارشناس مهندسي نرم‌افزار h_moshref@yahoo.com)
ناشر : همكاران سيستم

نمي‌توان طرحي داشت اگر نتوان آن را به درستي اندازه‌گيري کرد و آغاز پروژه بدون وجود طرح مانند آن است که شکست پروژه طراحي شده باشد.
پروژه‌ي نرم‌افزاري موفق، پروژه‌اي است که در قالب هزينه و زماني معين و از پيش تعيين شده به انجام برسد. نرم‌افزار کاري توليدي به شمار مي‌رود که هزينه‌ي عمده‌ي آن نيروي کارآزموده ومتخصص است. بنابراين مهم‌ترين ابزار يک پروژه نرم‌افزاري و به طور تقريبي بخش اعظم هزينه‌هاي آن به نيروي کار متخصص درگير در آن مرتبط است. سوال اين است که چه‌گونه مي‌توان زمان و هزينه‌ي يک پروژه نرم‌افزاري را تخمين زد. ماهيت خلاق پروژه‌هاي نرم‌افزاري و انتزاعي بودن آن تخمين هزينه و زمان انجام آن‌ها را بي‌نهايت مشکل مي‌کند. روش‌هاي متداول تخمين زمان و هزينه خود اساسا انتزاعي است با اين همه هنوز هم تخمين پروژه امري لازم و ضروري محسوب مي‌شود.


روش‌هاي مختلفي در تخمين و برآورد حجم فعاليت‌هاي لازم در انجام يک پروژه نرم‌افزاري در جامعه نرم‌افزار ارايه شده است. فارغ از اين‌که از چه روشي در تخمين زمان و هزينه يک پروژه نرم‌افزاري استفاده مي‌شود، مهم آن است که بدون وجود اطلاعات کافي در زمينه حوزه و دامنه سيستم و قابليت‌ها و توانايي‌هاي آن و هم‌چنين شرايط محيطي و فرهنگي تيم توليد نرم‌افزار و پيچيدگي‌هاي تکنيکي آن، برآورد واقع‌بينانه پروژه کاري دور از دست‌رس مي‌نمايد.



پس نخست بايد اطلاعات ضروري آماده شود. نگارنده اين اطلاعات را در سه دسته تقسيم کرده است:

* اطلاعات مربوط به حوزه سيستم و نيازهاي کارکردي و غير کارکردي آن
* اطلاعات مربوط به محيطي که سيستم در آن عملياتي خواهد شد.
* اطلاعات مربوط به محيط توليد و توسعه سيستم

از اين سه دسته اطلاعات گروه اول مهم‌ترين است. عدم تشخيص درست نيازها و قابليت‌هاي کارکردي و غير کارکردي سيستم، عموما و به‌غايت ما را از تخمين درست هزينه و زمان مورد نياز دور مي‌کند. به همين دليل لازمه يک برآورد مناسب، تشخيص و تعيين اوليه نيازهاي سيستم در فرآيندي سازمان‌يافته است. در روش‌هاي سنتي ساخت‌يافته به طور معمول بخشي از فعاليت‌هاي مرحله‌ي امکان‌سنجي به اين امر اختصاص دارد. در فرآيندهاي مدرن مهندسي نرم‌افزار مانند RUP نيز يکي از فعاليت‌هاي مهم مرحله اول آن يعني Inception به تعيين و تخمين نيازهاي سيستم و انتظارات اوليه برمي‌گردد؛ يعني همان اطلاعات لازم جهت برآورد هزينه و زمان پروژه نرم‌افزاري.

نکته‌ي مهم آن است که در کشور ما ايران، به طور معمول قبل از انجام چنين مرحله‌اي و صرفا بر اساس شرح مشخصات بسيار کلي سيستم؛ يعني بدون داشتن سه بخش اطلاعات كه در بالا به آن اشاره شد، زمان و هزينه پروژه‌ استعلام و برآورد و حتا تعيين مي‌شود. چنين کاري در عمل به شکست پروژه‌هاي نرم‌افزاري منجر مي‌شود. چرا که در مسير توليد سيستم به دليل اختلاف فزاينده‌اي که بين برآوردهاي اوليه و هزينه‌هاي واقعي پروژه‌اي به وجود مي‌آيد دو نتيجه مشخص را غير قابل اجتناب مي‌کند:
- يا هزينه توليد سيستم افزايش مي‌يابد که اين يعني ضرر توليدکننده نرم‌افزار
- و يا سيستم با قابليت‌ها و انتظارات ناکافي و در کيفيتي نامناسب ارايه مي‌شود و اين يعني ضرر کارفرما يا مشتري

پس چه بايد کرد؟ چه‌گونه مي‌توان اطلاعات لازم سه گانه فوق را به دست آورد؟ آيا استفاه از RFP گروه اطلاعات اول را فراهم مي‌سازد؟ به اين سئوال به سختي مي‌توان پاسخ داد؛ چرا که بر حسب آن که RFP را چه گروهي و با چه فرمت و استانداردي تهيه کرده باشد، جواب مي‌تواند متفاوت باشد.

در اين ميان حلقه‌ي گمشده‌ي ديگري نيز به نظر مي‌آيد. اجراي مرحله اول فرآيند براي تعيين و برآورد واقعي‌تر پروژه ضروري است، با اين همه مشکل در آن است که مشخص نيست هزينه‌ي اجراي اين مرحله بر عهده کارفرما خواهد بود يا مجري؟ در صورتي که پروژه طي قراردادي قبل از اجراي اين مرحله واگذار شود، پس برآوردها تفاوت فراواني با واقعيت خواهد داشت و در صورتي که قرارداد پس از مرحله‌ي اول و جمع‌آوري اطلاعات بسته شود، در آن صورت هزينه‌ي اجراي مرحله اول بر عهده چه کسي خواهد بود؟ به همين دليل بسياري از پروژه‌هاي نرم‌افزاري در نيمه‌ي راه به دليل برآوردهاي غلط به شکست مي‌انجامند يا در واقع نمي‌توانند نيازهاي کاربران را برآورده نمايند.

همان طور که گفته شد روش‌هاي مختلفي براي تخمين و برآورد حجم فعاليت‌هاي لازم براي انجام يک پروژه نرم‌افزاري معرفي شده است. معروف‌ترين آن‌ها روش COCOMO است. از آن‌جا که قصد اين نوشته تشريح اين روش نيست فقط به بيان اين نكته بسنده مي‌شود که در اين روش اساسا ميزان خطوط کد لازم براي توليد برنامه بر اساس مفهوم Function point تخمين زده شده و بر اساس آن حجم فعاليت‌هاي لازم براي پروژه تخمين زده مي‌شود.

با فرض اين‌که نيازهاي سيستم در قالب يوزکيس‌ها شناسايي شده اند، متخصصين RUP نيز روش‌هاي گوناگوني را براي تخمين هزينه و برآوردهاي واقع بينانه پروژه ارايه کرده‌اند. روش ديگري که در ميانه‌ي دهه‌ي 1990 ارايه شد روش Use Case Point است. در اين روش با تعريف Use Case Point هاي سيستم و تخصيص نفر ساعت لازم براي پياده‌سازي آن‌ها حجم فعاليت لازم تخمين زده مي‌شود. هر يوزکيس شامل سناريو يا سناريوهايي است. علاوه بر UseCaseهاي سيستم واسطه‌هاي ارتباطي يوزکيس با دنياي بيرون ازجمله براي مثال پنجره‌هاي ويندوز و يا صفحات وب نيز وجود دارند که طراحي و پياده‌سازي آن خود حجم کار قابل توجهي را مي‌طلبد. بنابر اين قدم اول تشخيص يوزکيس‌ها و تشريح سناريوهاي آن‌هاست. فرآيند تشخيص و تشريح يوزکيس‌هاي سيستم هر چه با دقت بيش‌تري انجام شود، برآوردهاي واقعي‌تري را منتج خواهد بود. اما همان‌طور که کارشناسان RUP به خوبي مي‌دانند، يوزکيس‌ها به عنوان مدلي از فعاليت‌هاي سيستم به طور كامل انتزاعي بوده و بسته به آن‌که چه کسي و از چه زاويه‌اي آن‌ را مي‌نويسد سطوح و پيچيدگي‌هاي مختلفي مي‌توانند داشته باشند. براي مثال مي‌توان صدور چک را يک يوزکيس تلقي کرد و هم‌زمان مي‌توان صدور چک را زيرسيستمي معرفي نمود که خود شامل تعداد مشخصي يوزکيس است. نتيجه آن که سطوح يوزکيس‌ها مي‌توانند مختلف باشند و بنابراين در تعيين تعداد يوزکيس پوينت‌ها بايد دقت بيش‌تري مبذول نمود. به هرحال بهتر است که سطوح انتزاع در تمامي سيستم از يک روال ثابتي پيروي کند، در غير اين صورت بايد ضريب سطح انتزاع نيز در معادلات مربوط به Use Case Point در نظر گرفته شود


يوزکيس پوينت روشي در ارزيابي و تخمين هزينه و زمان پروژه هاي نرم‌افزاري

قبل از تشريح دقيق‌تر اين روش اصطلاحات خاص اين روش را بهتر بشناسيم:

آن‌چه خواننده بايد بداند:



1. خواننده بايد اطلاعات پايه را در مورد نوشتن يوزکيس داشته باشد. اين مقاله توصيفي در مورد يوزکيس‌ها ارايه نداده و تنها نحوه تخمين زمان انجام را معرفي مي‌کند. بنابراين اگر اين نوشته را بدون اطلاع مکفي در مورد مفهوم بازيگر، نقش ، سناريو مي‌خوانيد از آن استفاده‌ي زيادي نخواهيد برد.

2. ساختار يوزکيس‌ها از سازمان به سازمان و از پروژه به پروژه متفاوت است. چيزي که اساسا در تخمين و ارزيابي موثر است. اين نوشته بر مبناي ساختار ارايه شده توسط Allister Mac Lin در کتاب How To Write Effective Use Case نوشته شده است. مطالعه اين کتاب را به خواننده توصيف مي‌کنيم.


محدوده:
اين مقاله صرفا در مورد درکUse Case Point بوده و اطلاعاتي درمورد نحوه نوشتن يوزکيس‌ها به خواننده نمي‌دهد. نوشته‌ها و مقالات بسياري در اين باب نوشته شده و در اينترنت نيز قابل دسترس است.
تاريخچه:

روش Use Case Point مبتني بر کارustav karner که در سال 1993 به عنوان تز دانشگاهي ارايه شد. اين روش امروزه به عنوان روش تخمين زمان و هزينه در برخي از ابزارهاي مهندسي نرم‌افزار که از UML براي مدل‌سازي استفاده مي‌کنند، پيش‌بيني شده است که از آن جمله مي‌توان به ابزار نرم‌افزاري خوش‌دست Sparx System Enterprise Architect اشاره کرد.


مراحل روش يوزکيس پروينت براي تخمين


1. تعيين UAW) Unadjusted Actor Weight ): اولين قدم دسته‌بندي همه بازيگران سيستم است. در جدول زير دسته‌بندي بازيگران آمده است. ستون دوم راهنماي تصميم گيري در مورد نوع بازيگر بوده و نشان ميدهد که بازيگر بايد در کدام دسته قرار مي‌شود. آخرين ستون نيز عامل پيچيدگي آن را نشان مي‌دهد.
2. تعيين UUCW ( Unadjusted Use Case Point ). مرحله دوم شمارش يوزکيس‌ها و تعيين وزن آن‌ها بر حسب تعداد سناريوها و تعداد تراکنش‌هاي آن‌هاست.
3. تعيين مجموع UUCP (Unadjusted Use Case Point ): براي محاسبه اين مقدار از فرمول روبه‌رو استفاده مي‌شود: مجموع UAW + مجموع UUCW = UUCP
4. محاسبه عوامل تکنيکي و محيطي: آخرين قدم براي محاسبه پيچيدگي، تعيين و اندازه‌گيري عوامل تکنيکي و محيطي سيستم است. عوامل تکنيکي 13 مورد شناخته شده دارند هر چند مي‌توان عوامل ديگري را نيز به آن اضافه نمود. به هر يک عوامل تکنيکي مقادير 0 تا 5 نسبت داده مي‌شود. مجموع عوامل تکنيکي فاکتور پيچيدگي تکنيکي پروژه را تعيين کرده و با ضرب آن در ضريب پيچيدگي، ميزان پيچيدگي پروژه محاسبه مي‌شود. هر عامل تکنيکي وزني نيز دارد که ميزان تاثير آن را مشخص مي‌کند.


1. محاسبه فاکتور تکنيکي
براي محاسبه فاکتور تکنيکي پروژه از معادله Tfactor =T1 +T2 + …….T12+T13 استفاده مي‌گردد.

2. محاسبه ميزان پيچيدگي تكنيكي پروژه:
ميزان پيچيدگي تکنيکي پروژه با فرمول TCF= 0.6 +(0.01* Tfactor)محاسبه مي‌شود.

3. عامل محيطي:
عوامل ديگري نيز هستند که بايد در نظر گرفته شوند از جمله عوامل محيط توليد نرم‌افزار که اثر مستقيم بر روي زمان و هزينه‌ي پروژه خواهد داشت.

4.مجموع عوامل محيطي از جمع مقادير بالا محاسبه مي‌شود:
يعني:Efactor=SUM(e1….e8)

5.براي محاسبه ضريب عامل محيطي از معادله EF=1.4+(-0.03 * Efactor)استفاده مي‌شود.

6. د رنهايت مقدارAUCP (Adjusted Use Case Points ) با استفاده از فرمول زير محاسبه مي‌شود؛ يعني AUCP=UUCP * TCF * EF

با ضرب مقدار به دست آمده در نفر ساعت لازم براي انجام هر يوزکيس پوينت نفر ساعت کل لازم براي انجام پروژه به دست مي‌آيد. براي ميزان نفر ساعت لازم براي هر Use Case Point مقادير متفاوتي پيشنهاد شده از جمله 10، 15 و 20 و حتا 30 تا 40 نفر ساعت براي هرUse Case Point در نظر گرفته شده است. با اين همه بعضي از متخصصان بيان کرده‌اند که اين عدد خود به فاکتورهاي محيطي مرتبط است. تجربه عملي نگارنده نشان داده که ميزان 10 تا 15 نفر ساعت در محيط‌هاي کاري ما مناسب است.


مثال عملي براي تخمين زمان يک پروژه

براي نشان دادن چگونگي تخمين هزينه يک پروژه از يک مثال ساده استفاده مي‌کنيم. ابتدا حوزه مساله:

شرکت راپيران در حال حاضر از روش دستي براي ثبت و ويرايش اطلاعات مشتريان خود و ميزان اعتبار آن‌ها استفاده مي‌کند. اطلاعات مشتريان به همراه اطلاعات کارت‌هاي اعتباري آنها در دفاتري ثبت ميگردد و سپس اطلاعات کارت اعتباري آن‌ها از طريق سيستم کارت خوان که توسط بانک در اختيار شرکت گذاشته شده کنترل مي‌گردد. اطلاعات مشتريان عبارت است از:

- کد مشتري

- نام مشتري

- آدرس مشتري

- تلفن مشتري

- اطلاعات معتبر کارت اعتباري مشتري

کد مشتري براي هر مشتري يکتا بوده بنا بر اين کارمند پذيرش مشتريان بصورت دستي اطلاعات را کنترل و در دفتر ثبت مينمايد . راپيران ميخواهد فعاليتها و کنترلهاي زير در ثبت و ويرايش اطلاعات مشتريانش بصورت مکانيزه انجام شود:

- کنترل يکتايي کد مشتري

- کد مشتري نبايد از 8 حرف و عدد بيشتر باشد

- کنترل کارت اعتباري مشتري بايد از طريق ارتباط سيستم با سيستم کارت خوان بانک بصورت اتوماتيک انجام شود

- طول شماره کارت اعتباري نبايد بيش از 10 حرف يا عدد باشد

- اپراتور بايد بتواند اطلاعات مشتري جديدي را اضافه کرده و اطلاعات مشتري موجود را تغيير داده ويا آنرا حذف کند

- بانک اطلاعاتي در دفتر اطلاعات شرکت نصب شده و تنها ورود و ويرايش و حذف اطلاعات توسط اپراتور سيستم انجام ميشود

- نرم افزار در ميحيط ويندوز اجرا خواهد شد و سيستم عامل ويندوز XP به اينمظور استنفاده خواهد شد

يوزکيس ورود اطلاعات مشتري در سيستم مشتريان شرکت راپيران

الگوي تشريح و توصيف يوزکيس از شخص به شخص و از پروژه به پروژه و از سازمان به سازمان متفاوت است . موضوع اصلي در ترتيب و مراحلي است که در سناريو مي‌آيد.


تراکنش يوزکيس:تراکنش يوزکيس، واحد مجموعه فعاليت‌هايي است که به طور کامل انجام مي‌شود. براي تشخيص تراکنش يوزکيس بايد ديد که آيا تراکنش ارزشي توليد مي‌کند. در صورتي که يک فعاليت ارزشي را توليد نمي‌کند نبايد آن را به عنوان تراکنش يوزکيس در نظر گرفت؛ براي مثال اين‌که کاربر کامپيوتر خود را روشن مي‌کند و يا اين‌ که کاربر روي کليد ايجاد مشتري و يا هر کليد ديگري در پنجره ارتباطي خود کليک مي‌کند تراکنش محسوب نمي‌شود، اما کارت اعتباري مشتري توسط يک تراکنش کنترل اعتبار بررسي مي‌گردد. تعدادUse Case Point ها به طور كامل بستگي به چگونگي تعريف بازيگران و تراکنش‌هاي تعريف شده دارد . بنا براين تشريح وتوصيف يوزکيس ها بايد ازطريق الگوها و سرخطهاي مشخصي انجام شود . بهترين راه برگزاري جلسه با تمامي اعضاي تيم مسئول انجام پروژه قبل از نوشتن شرح يوزکيس است. عمق تشريح يوزکيس مي‌تواند تا 40 درصد روي تخمين انجام شده تاثير گذار باشد. روش و الگويي که در اين‌جا ارايه مي‌شود، تنها الگو نبوده و تنها براي تشريح مساله‌ي بالا ارايه شده است.