کارگروه
Rational Unified Process (RUP)

درباره کارگروه

در این انجمن در مورد RUP بحث و گفتگو می شود

موسس کارگروه

رضا علیمددی

علیمددی

ماساژی	قاسمی
الف	mojtabavi
ذوالفقاری	dehghan
جمالی فرد	jahanbini

ثبت نام اینترنتی نمایشگاه - جانمائی آنلاین غرفه

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

صفحه اصلی کارگروهها >> Rational Unified Process (RUP) >> تخمین هزینه و زمان در پروژه‌های نرم‌افزاری

ارسال پاسخ

it innovators

در کارگروه: Rational Unified Process (RUP)
تعداد ارسالي: 19

بیوگرافی و سوابق کارگروههای من پروفایل من

17 سال پیش در تاریخ: پنجشنبه, تير 28, 1386 10:35

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

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

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

اطلاعات مربوط به حوزه سیستم و نیازهای کارکردی و غیر کارکردی آن

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

اطلاعات مربوط به محیط تولید و توسعه سیستم

از این سه دسته اطلاعات گروه اول مهم‌ترین است. عدم تشخیص درست نیازها و قابلیت‌های کارکردی و غیر کارکردی سیستم، عموما و به‌غایت ما را از تخمین درست هزینه و زمان مورد نیاز دور می‌کند. به همین دلیل لازمه یک برآورد مناسب، تشخیص و تعیین اولیه نیازهای سیستم در فرآیندی سازمان‌یافته است. در روش‌های سنتی ساخت‌یافته به طور معمول بخشی از فعالیت‌های مرحله‌ی امکان‌سنجی به این امر اختصاص دارد. در فرآیندهای مدرن مهندسی نرم‌افزار مانند 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 درصد روی تخمین انجام شده تاثیر گذار باشد. روش و الگویی که در این‌جا ارایه می‌شود، تنها الگو نبوده و تنها برای تشریح مساله‌ی بالا ارایه شده است.