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

[s.sepehrvand]

نويسنده : حميد مشرف (كارشناس مهندسي نرم‌افزار 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 درصد روی تخمین انجام شده تاثیر گذار باشد. روش و الگویی که در این‌جا ارايه می‌شود، تنها الگو نبوده و تنها برای تشریح مساله‌ي بالا ارايه شده است.

[.مهدی فهمیده.]

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

سوالی که دارم اینه که انجام این مرحله یعنی براورد اندازه UC ها که باید در فاز INCEPTION انجام شود بایستی قبل از بستن قرار داد که شامل هزینه انجام پروژه و مدت زمان انجام آن می باشد صورت گیرد؟
که در این صورت تیم نرم افزاری تا مدتی با هزینه شخصی خود این برآورد را انجام دهد!
این مرحله براورد دقیقا چه موقع انجام میشه و هزینه آن به عهده چه افرادی هست؟

[saeed_zarandi]

سلام مطلب مفيدي بود. همانطور كه شما و سايرين اشاره كرده ايد مشكل تا rfpاست كه مخصوصا در جاهاي دولتي هزينه اي جدا نمي توانند ببينند.اكثرا از بخش خصوصي مي خواهند رايگان بيايد تا مرحله اول را انجام دهند بعد تخمين هزينه كنند كه بخش خصوصي هم از انجام پروژه مطمئن نيست درست انجام نمي دهد .

[hassani_azad]

با سلام خدمت همه دوستان مخصوصا ارائه دهنده مقاله بنده در همين زمينه چند مورد اختلاف بين كار فرما و مجري برخورد كردم كه بدليل عدم شناخت كارفرما از جئيات پروژه به وجود آمده است و درخواست شده تا قيمت گذاري براي پروژه تكميل شده صورت گرفته انجام شود. متاسفانه هيچ كدام از طرفين نظر طرف مقابل را قبول نمي كند

[s.bashari]

بر اساس سال 1387

1- فرمول محاسبه :


2- جدول ضریب های شغلی


3- جدول هزینه ها
http://s3.tinypic.com/2emkhp1.jpg

4- فرمول نرمال سازی قیمت بر اساس کارفرما
http://s3.tinypic.com/nvvbfc.jpg

[rezaIGJ]

سلام دوستان
علوم کامپیوتر برای جلوگیری از این مشکلات یک راه حل مفید ارائه داده شما اگه از متدولوژی مناسب استفاده کنی و قبل از شروع کار اصلی گروه تحلیل پروژت کارشون رو درست انجام بدن و شما هم قبل از بستن قرار داد DFD , FHD و موجودیت ها رو به اونا نشون بدی هم خودت به قیمت واقعی پروژت می رسی و هم کارفرما متوجه کار واقعی شما می شه و در ضمن وقتی قرار دادی رو درست تنضمیم کنید دیگه کسی نمی تونه زیرش بزنه.
یه نکته ای که می خوام تو پرانتز بگم اینه که : یادتون باشه از ابتدا قرار داد ببندید چون اغلب شرکت ها اول یه چیزی می خوان بعد هی به سفارششون چیزای جدید اضافه می شه و ما باید برای هر کدوم از اینها پول اضافه بگیریم چون گروه تحلیلمون باید دوباره مسیر رو برگرده و گروه کد نویس و طراحمون هم باید یه سری بازسازی ها رو انجام بده

[shahbazi]

این برنامه هرینه ی ساخت هر بخش و کل پروژه را طبق فرمول شورای عالی انفورماتیک محاسبه می کند.

[Sardabir]

کلیه پستهای غیر مفید این تاپیک در راستای عملیات پاکسازی و خانه تکانی انجمن ها حذف گردید.

[اسفندياري]

مدير محترم انجمن/سايت: عكسهاي متن اصلي ديده نمي شوند.
FYI

[admin]

صنعت نرم‌افزار در سال‌های اخیر شکوفایی قابل توجهی داشته و به سمت "دست‌یابی" روش‌مند به اهداف و "مهندسی" در حرکت بوده است. مدیریت پروژه‌های نرم‌افزاری و محیطی که این پروژه‌ها در آن اجرا می‌شوند، نیازمند دانش مجرد است؛ حقایقی که از طریق مشاهده و اندازه‌گیری به دست می‌آیند.Tom DeMarco در این باره می‌گوید: "آن‌چه را که قابل اندازه‌گیری نیست، نمی‌توان کنترل و مدیریت کرد."

برآورد اندازه‌ی پروژه به 3 دلیل عمده، ضروری به نظر می‌رسد:

1- به منظور تعدیل پروژه: مقایسه‌ی هزینه و سود پروژه و ارزیابی‌های "اگر –آن‌گاهی" برای انتخاب بین گزینه‌های کارکردی، محیطی و تکنیکی مختلف.

2- به عنوان بخش جدا نشدنی نظم مهندسی نرم‌افزار. در پروژه‌های تولید نرم‌افزار بر خلاف سایر پروژه‌ها (برای مثال پروژه‌های ساختمانی) در هر زمان از کار ممکن است که اجزای بنیادین پروژه تغییر کند، در نتیجه باید روشی برای کنترل این تغییرات و اثرات آن‌ها وجود داشته باشد. به گونه‌ای که در نهایت این تغییرات به شکست پروژه منجر نشوند.

3- بهبود فرآیندهای تولید نرم‌افزار و ارزیابی تاثیرهای بهبود فرآیند بر کیفیت محصول.

آیا پروژه‌های نرم‌افزاری، مشابه سایر پروژه‌ها قابل تخمین هستند؟

مطابق نظر [1]Paul Coombs دوازده قانون کور ولی بدیهی در تخمین وجود دارد، اولین و مهم‌ترین این قانون‌ها، به شرح زیر است:

قانون 1: تخمین‌های شما اشتباه خواهند بود.

چه‌گونه می‌تواند غیر از این باشد وقتی شما قرار است آینده را پیش‌گویی کنید! به ویژه در پروژه‌های نرم‌افزاری که عوامل تاثیرگذار بر آن‌ها بسیار زیاد است. بنابراین مدیران، مشتریان یا کارفرمایان هرگز نباید انتظار داشته باشند که تمام برآوردها دقیق و بی‌نقص باشند.

اما می‌توان با واقع‌بینی در کار احتمال اشتباه در برآوردها را به حداقل رساند. هرگز نباید در برآوردها بسیار بدبین یا بسیار خوش‌بین بود. یادآوری این نکته ضروری است که هر دونوع تخمین خوش‌بینانه (Under Estimation) و بدبینانه (Over Estimation) معایبی مانند دست‌ نیافتن به بازار (در حالت بدبینانه) و از دست دادن بازار (در حالت خوش بینانه) را به همراه دارند که در در بازار رقابتی پذیرفته نیست.

چه کسی باید تخمین را انجام دهد؟

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

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

بهترین زمان برای تخمین پروژه چه موقعی است؟

دومین قانون تخمین به این سوال پاسخ خواهد داد:

قانون 2: اندازه‌ی پروژه در هر زمان قابل تخمین است.

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


تکنیک‌های تخمین:

به چهار روش می‌توان تخمین را انجام داد:

1- قضاوت افراد با تجربه: استفاده از افراد خبره در ارایه‌ی تخمین فعالیت‌ها.

2- مقایسه: مقایسه پروژه‌ی مورد نظر با سایر پروژه‌های مشابه.

3- پایین به بالا: شکستن کار به اجزای کوچک‌تر، تخمین هریک از اجزا و سپس جمع زدن تخمین‌ها با هم.

4- محاسبه ریاضی: استفاده از مدل‌های محاسباتی برای به دست آوردن برآورد اندازه‌ی کار. در این روش مقادیری که نشان دهنده‌ی ویژگی‌های پروژه هستند، در معادلاتی وارد می‌شوند که نتیجه‌ی این معادلات تخمین اندازه پروژه در قالب زمان یا هزینه است.

نکته مهم استفاده از ضرایب تعدیل در تخمین‌هاست. هر تخمینی از دو بخش تشکیل شده است؛ عدد پایه و ضریب تعدیل. برای مثال تخمین پایه‌ی 20 روز و ضریب تعدیل 50% برای یک فعالیت؛ به این معناست که این فعالیت دست پایین (در بهترین حالت) در مدت 20 روز انجام خواهد شد و بیش‌ترین زمان لازم برای انجام آن 30 روز خواهد بود. مقوله‌ی "ریسک" در ضریب تعدیل لحاظ خواهد شد، نه در عدد پایه. به عبارت دیگر یکی از عوامل موثر در تعریف ضریب تعدیل، ریسک‌های اجراست.

قانون 3: هر تخمینی باید ضریب تعدیل داشته باشد.

به طور منطقی در هر تخمین باید گام‌های زیر پیموده شود:

1- تهیه فهرستی از فعالیت‌هایی که باید تخمین زده شوند.

2- تخمین هر یک از فعالیت‌های فهرست‌بندی شده.

3- جمع کردن تمام آن تخمین‌ها.

4- اضافه کردن ضریب تعدیل.

برای انجام تخمین درست ابتدا باید مواردی که نیازمند تخمین هستند مشخص و تعریف شوند. ریسک تخمین نه فقط اشکال در محاسبه تخمین است بلکه در اکثر مواقع اشکال در تخمین به علت فراموش کردن تخمین بعضی فعالیت ها یا ریسک هاست. بنابراین:

قانون 4: تهیه‌ی فهرستی از اقلام نیازمند تخمین به مراتب مشکل‌تر از تخمین آن‌هاست.

اقلام نیازمند تخمین می‌توانند نرم‌افزار، مدیریت پروژه، مدیریت فنی، سخت‌افزار، گواهی‌نامه‌ها و پیمان‌کاران یا به عبارت دیگر تمام عوامل هزینه‌ی سیستم باشند. بنابراین آشنایی با پروژه اهمیت زیادی دارد.


قانون 5:کیفیت تخمین به آشنایی با پروژه مورد نظر وابستگی زیادی دارد.


قانون6: هر چه‌قدر جزییات اقلام نیازمند تخمین را بیش‌تر کنید، دیرتر به عدد مشخص تخمین می‌رسید.

اقلام نیازمند تخمین باید تا سطح معناداری شکسته شوند. نه آن‌قدر جزیی باشند که برای تخمین به زمان زیادی نیاز داشته باشند و نه آن‌قدر کلی که دقت تخمین را کاهش دهند.

بعضی فعالیت‌های پشتیبانی که به طور مستقیم در تولید وارد نمی‌شوند، در حالت عادی فراموش می‌شوند و باید در این باره بسیار دقت کرد.

پس از تهیه‌ی فهرست اقلام نیازمند تخمین نوبت انجام تخمین است. برای انجام عمل تخمین ابتدا:


قانون 7: مفروضات خود را ثبت کنید.

با نوشتن مفروضات لحاظ شده، دقت و شرایط تخمین معلوم می‌شود. مفروضات می‌توانند به دسته‌ای خاص از فعالیت‌ها مربوط و یا در کل پروژه حاکم باشند، مانند دست‌رسی به منابع در زمان‌های مشخص یا ثبات نیازمندی‌های مورد نظر پروژه.

حال باید ریسک‌های پروژه هم تعریف شوند تا بتوان ضریب تعدیل را تعریف کرد.


قانون 8: ضریب تخمین به صورت نسبتی با استفاده از ریسک‌ها تعریف می‌شود.

اکنون تخمین اقلامی که به همراه مفروضات و ریسک‌ها به دقت شناسایی و فهرست شده‌اند، امکان‌پذیر است. به خاطر داشتن این نکته بسیار ضروری است که:


قانون 9: هیچ روش کامل و جامعی وجود ندارد.

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

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

تخمین براساس یک فعالیت پایه‌ی روش دیگر تخمین است. در این روش زمانی مشخص برای نوع خاصی از فعالیت در نظر گرفته می‌شود و تخمین اندازه‌ی سایر فعالیت‌ها در مقایسه با آن فعالیت تعریف می‌شود.

برای تخمین اندازه‌ی پروژه می‌توان از مدل‌های محاسباتی مانند Function Point Analysis ,COCOMO و ابزارهایی که بر پایه‌ی این روش‌ها تهیه شده‌اند، استفاده کرد.

مرحله‌ی بعدی تخمین مدت زمان یا طول پروژه و به عبارت دیگر برنامه‌ریزی پروژه است.


قانون 10: طول پروژه به ماه باید بزرگ‌تر از متوسط تعداد افراد تیم باشد.

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

قبل از ارسال تخمین‌ها برای مرور، باید یکپارچگی و هم‌خوانی آن‌ها با یکدیگر دوباره کنترل و از درستی آن‌ها اطمینان حاصل شود.


قانون 11: کسی غیر از تخمین‌زننده‌ی اول باید تخمین‌ها را مرور کند.

اگر برای مرور شخص دیگری با مسوولیت مستقل وجود ندارد، باید ریسکی به سایر ریسک‌ها اضافه شود.

در نهایت پس از اجرای پروژه باید تخمین‌ها نگه‌داری شوند تا در تحلیل‌های بعدی مورد استفاده قرار گیرند.


قانون 12: اطلاعات پروژه‌ی خاتمه یافته باید نگه‌داری شوند.

به عبارت دیگر گزارش انجام یک پروژه می‌تواند راه‌گشای اجرای پروژه‌های بعدی باشد.

این مقاله به طور عمده از کتاب - IT Project Estimation-A Practical Guide to the Costing of Software اقتباس شده است و سعی بر ارائه کلیاتی از تجربه و توصیه یک برآورد کننده حرفه ای، دارد.

منبع