اطلاعیه

Collapse
No announcement yet.

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

Collapse
X
 
  • Filter
  • زمان
  • Show
Clear All
new posts

  • تخمین هزینه Ùˆ زمان در پروژه های نرم افزاری

    به نقل از :http://www.developercenter.ir/Forum/...read.php?t=485
    نمیدونم این ممد چیکار کرده با این ادیتور که وقتی کپی پیست( چه عمل کثیفی) میکنی فاصله ها * میخورن ! چشمتون اذیت شد به ممد فحش بدین یا برین سراغ لینک مرجع )

    نويسنده : حميد مشرف (كارشناس مهندسي نرم*افزار [email protected])
    ناشر : همكاران سيستم

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


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



    پس نخست باید اطلاعات ضروری آماده شود. نگارنده این اطلاعات را در سه دسته تقسیم کرده است:
    • اطلاعات مربوط به حوزه سیستم Ùˆ نیازهای کارکردی Ùˆ غیر کارکردی آن
    • اطلاعات مربوط به محیطی Ú©Ù‡ سیستم در آن عملیاتی خواهد شد.
    • اطلاعات مربوط به محیط تولید Ùˆ توسعه سیستم
    از این سه دسته اطلاعات گروه اول مهم*ترین است. عدم تشخیص درست نیازها و قابلیت*های کارکردی و غیر کارکردی سیستم، عموما و به*غایت ما را از تخمین درست هزینه و زمان مورد نیاز دور می*کند. به همین دلیل لازمه یک برآورد مناسب، تشخیص و تعیین اولیه نیازهای سیستم در فرآیندی سازمان*یافته است. در روش*های سنتی ساخت*یافته به طور معمول بخشی از فعالیت*های مرحله*ي امکان*سنجی به این امر اختصاص دارد. در فرآیندهای مدرن مهندسی نرم*افزار مانند 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 درصد روی تخمین انجام شده تاثیر گذار باشد. روش و الگویی که در این*جا ارايه می*شود، تنها الگو نبوده و تنها برای تشریح مساله*ي بالا ارايه شده است.




Working...
X