Y@SiN
08-13-2009, 03:50 PM
تخمین هزینه و زمان در پروژه‌های نرم‌افزاری (بخش نخست)
نمی‌توان طرحی داشت اگر نتوان آن را به درستی اندازه‌گیری کرد و آغاز پروژه بدون وجود طرح مانند آن است که شکست پروژه طراحی شده باشد.
پروژه‌ي نرم‌افزاری موفق، پروژه‌ای است که در قالب هزینه و زمانی معین و از پیش تعیین شده به انجام برسد. نرم‌افزار کاری تولیدی به شمار می‌رود که هزینه‌ي عمده‌ي آن نیروی کارآزموده ومتخصص است. بنابراین مهم‌ترین ابزار یک پروژه نرم‌افزاری و به طور تقريبي بخش اعظم هزینه‌های آن به نیروی کار متخصص درگیر در آن مرتبط است. سوال این است که چه‌گونه می‌توان زمان و هزینه‌ي یک پروژه نرم‌افزاری را تخمین زد. ماهیت خلاق پروژه‌های نرم‌افزاری و انتزاعی بودن آن تخمین هزینه و زمان انجام آن‌ها را بي‌نهايت مشکل می‌کند. روش‌های متداول تخمین زمان و هزینه خود اساسا انتزاعی است با این همه هنوز هم تخمین پروژه امری لازم و ضروری محسوب می‌شود.
روش‌های مختلفی در تخمین و برآورد حجم فعالیت‌های لازم در انجام یک پروژه نرم‌افزاری در جامعه نرم‌افزار ارايه شده است. فارغ از این‌که از چه روشی در تخمین زمان و هزینه یک پروژه نرم‌افزاری استفاده می‌شود، مهم آن است که بدون وجود اطلاعات کافی در زمینه حوزه و دامنه سیستم و قابلیت‌ها و توانایی‌های آن و هم‌چنین شرایط محیطی و فرهنگی تیم تولید نرم‌افزار و پیچیدگی‌های تکنیکی آن، برآورد واقع‌بینانه پروژه کاری دور از دست‌رس می‌نماید.
پس نخست باید اطلاعات ضروری آماده شود. نگارنده این اطلاعات را در سه دسته تقسیم کرده است:
اطلاعات مربوط به حوزه سیستم و نیازهای کارکردی و غیر کارکردی آن
اطلاعات مربوط به محیطی که سیستم در آن عملیاتی خواهد شد.
اطلاعات مربوط به محیط تولید و توسعه سیستم
از این سه دسته اطلاعات گروه اول مهم‌ترین است. عدم تشخیص درست نیازها و قابلیت‌های کارکردی و غیر کارکردی سیستم، عموما و به‌غایت ما را از تخمین درست هزینه و زمان مورد نیاز دور می‌کند. به همین دلیل لازمه یک برآورد مناسب، تشخیص و تعیین اولیه نیازهای سیستم در فرآیندی سازمان‌یافته است. در روش‌های سنتی ساخت‌یافته به طور معمول بخشی از فعالیت‌های مرحله‌ي امکان‌سنجی به این امر اختصاص دارد. در فرآیندهای مدرن مهندسی نرم‌افزار مانند RUP نیز یکی از فعالیت‌های مهم مرحله اول آن یعنی Inception به تعیین و تخمین نیازهای سیستم و انتظارات اولیه برمی‌گردد؛ یعنی همان اطلاعات لازم جهت برآورد هزینه و زمان پروژه نرم‌افزاری.
نکته‌ي مهم آن است که در کشور ما ایران، به طور معمول قبل از انجام چنین مرحله‌ای و صرفا بر اساس شرح مشخصات بسیار کلی سیستم؛ یعنی بدون داشتن سه بخش اطلاعات كه در بالا به آن اشاره شد، زمان و هزینه پروژه استعلام و برآورد و حتا تعیین می‌شود. چنین کاری در عمل به شکست پروژه‌های نرم‌افزاری منجر می‌شود. چرا که در مسیر تولید سیستم به دلیل اختلاف فزاینده‌ای که بین برآوردهای اولیه و هزینه‌های واقعی پروژه‌ای به وجود می‌آید دو نتیجه مشخص را غیر قابل اجتناب می‌کند:
-یا هزینه تولید سیستم افزایش می‌یابد که این یعنی ضرر تولیدکننده نرم‌افزار
-و یا سیستم با قابلیت‌ها و انتظارات ناکافی و در کیفیتی نامناسب ارايه می‌شود و این یعنی ضرر کارفرما یا مشتری
پس چه باید کرد؟ چه‌گونه می‌توان اطلاعات لازم سه گانه فوق را به دست آورد؟ آیا استفاه از RFP گروه اطلاعات اول را فراهم می‌سازد؟ به این سئوال به سختی می‌توان پاسخ داد؛ چرا که بر حسب آن که RFP را چه گروهی و با چه فرمت و استانداردی تهیه کرده باشد، جواب می‌تواند متفاوت باشد.
در این میان حلقه‌ي گمشده‌ی دیگری نیز به نظر می‌آید. اجرای مرحله اول فرآیند برای تعیین و برآورد واقعی‌تر پروژه ضروری است، با این همه مشکل در آن است که مشخص نیست هزینه‌ي اجرای این مرحله بر عهده کارفرما خواهد بود یا مجری؟ در صورتی که پروژه طی قراردادی قبل از اجرای این مرحله واگذار شود، پس برآوردها تفاوت فراوانی با واقعیت خواهد داشت و در صورتی که قرارداد پس از مرحله‌ي اول و جمع‌آوری اطلاعات بسته شود، در آن صورت هزینه‌ي اجرای مرحله اول بر عهده چه کسی خواهد بود؟ به همین دلیل بسیاری از پروژه‌های نرم‌افزاری در نیمه‌ي راه به دلیل برآوردهای غلط به شکست می‌انجامند یا در واقع نمی‌توانند نیازهای کاربران را برآورده نمایند.
همان طور که گفته شد روش‌های مختلفی برای تخمین و برآورد حجم فعالیت‌های لازم برای انجام یک پروژه نرم‌افزاری معرفی شده است. معروف‌ترین آن‌ها روش COCOMO است. از آن‌جا که قصد این نوشته تشریح این روش نیست فقط به بيان این نكته بسنده می‌شود که در این روش اساسا میزان خطوط کد لازم برای تولید برنامه بر اساس مفهوم Function point تخمین زده شده و بر اساس آن حجم فعالیت‌های لازم برای پروژه تخمین زده می‌شود.
با فرض این‌که نیازهای سیستم در قالب یوزکیس‌ها شناسایی شده اند، متخصصین RUP نیز روش‌های گوناگونی را برای تخمین هزینه و برآوردهای واقع بینانه پروژه ارايه کرده‌اند. روش دیگری که در میانه‌ي دهه‌ي 1990 ارايه شد روش Use Case Point است. در این روش با تعریف Use Case Point های سیستم و تخصیص نفر ساعت لازم برای پیاده‌سازی آن‌ها حجم فعالیت لازم تخمین زده می‌شود. هر یوزکیس شامل سناریو یا سناریوهایی است. علاوه بر UseCaseهای سیستم واسطه‌های ارتباطی یوزکیس با دنیای بیرون ازجمله برای مثال پنجره‌های ویندوز و یا صفحات وب نیز وجود دارند که طراحی و پیاده‌سازی آن خود حجم کار قابل توجهی را می‌طلبد. بنابر این قدم اول تشخیص یوزکیس‌ها و تشريح سناريوهای آن‌هاست. فرآیند تشخیص و تشریح یوزکیس‌های سیستم هر چه با دقت بیش‌تری انجام شود، برآوردهای واقعی‌تری را منتج خواهد بود. اما همان‌طور که کارشناسان RUP به خوبی می‌دانند، یوزکیس‌ها به عنوان مدلی از فعالیت‌های سیستم به طور كامل انتزاعی بوده و بسته به آن‌که چه کسی و از چه زاویه‌ای آن را می‌نویسد سطوح و پیچیدگی‌های مختلفی می‌توانند داشته باشند. برای مثال می‌توان صدور چک را یک یوزکیس تلقی کرد و هم‌زمان می‌توان صدور چک را زیرسیستمی معرفی نمود که خود شامل تعداد مشخصی یوزکیس است. نتیجه آن که سطوح یوزکیس‌ها می‌توانند مختلف باشند و بنابراین در تعیین تعداد یوزکیس پوینت‌ها باید دقت بیش‌تری مبذول نمود. به هرحال بهتر است که سطوح انتزاع در تمامی سیستم از یک روال ثابتی پیروی کند، در غیر این صورت باید ضریب سطح انتزاع نیز در معادلات مربوط به Use Case Point در نظر گرفته شود.
منبع: http://www.systemgroup.net (http://www.systemgroup.net/)
نمی‌توان طرحی داشت اگر نتوان آن را به درستی اندازه‌گیری کرد و آغاز پروژه بدون وجود طرح مانند آن است که شکست پروژه طراحی شده باشد.
پروژه‌ي نرم‌افزاری موفق، پروژه‌ای است که در قالب هزینه و زمانی معین و از پیش تعیین شده به انجام برسد. نرم‌افزار کاری تولیدی به شمار می‌رود که هزینه‌ي عمده‌ي آن نیروی کارآزموده ومتخصص است. بنابراین مهم‌ترین ابزار یک پروژه نرم‌افزاری و به طور تقريبي بخش اعظم هزینه‌های آن به نیروی کار متخصص درگیر در آن مرتبط است. سوال این است که چه‌گونه می‌توان زمان و هزینه‌ي یک پروژه نرم‌افزاری را تخمین زد. ماهیت خلاق پروژه‌های نرم‌افزاری و انتزاعی بودن آن تخمین هزینه و زمان انجام آن‌ها را بي‌نهايت مشکل می‌کند. روش‌های متداول تخمین زمان و هزینه خود اساسا انتزاعی است با این همه هنوز هم تخمین پروژه امری لازم و ضروری محسوب می‌شود.
روش‌های مختلفی در تخمین و برآورد حجم فعالیت‌های لازم در انجام یک پروژه نرم‌افزاری در جامعه نرم‌افزار ارايه شده است. فارغ از این‌که از چه روشی در تخمین زمان و هزینه یک پروژه نرم‌افزاری استفاده می‌شود، مهم آن است که بدون وجود اطلاعات کافی در زمینه حوزه و دامنه سیستم و قابلیت‌ها و توانایی‌های آن و هم‌چنین شرایط محیطی و فرهنگی تیم تولید نرم‌افزار و پیچیدگی‌های تکنیکی آن، برآورد واقع‌بینانه پروژه کاری دور از دست‌رس می‌نماید.
پس نخست باید اطلاعات ضروری آماده شود. نگارنده این اطلاعات را در سه دسته تقسیم کرده است:
اطلاعات مربوط به حوزه سیستم و نیازهای کارکردی و غیر کارکردی آن
اطلاعات مربوط به محیطی که سیستم در آن عملیاتی خواهد شد.
اطلاعات مربوط به محیط تولید و توسعه سیستم
از این سه دسته اطلاعات گروه اول مهم‌ترین است. عدم تشخیص درست نیازها و قابلیت‌های کارکردی و غیر کارکردی سیستم، عموما و به‌غایت ما را از تخمین درست هزینه و زمان مورد نیاز دور می‌کند. به همین دلیل لازمه یک برآورد مناسب، تشخیص و تعیین اولیه نیازهای سیستم در فرآیندی سازمان‌یافته است. در روش‌های سنتی ساخت‌یافته به طور معمول بخشی از فعالیت‌های مرحله‌ي امکان‌سنجی به این امر اختصاص دارد. در فرآیندهای مدرن مهندسی نرم‌افزار مانند RUP نیز یکی از فعالیت‌های مهم مرحله اول آن یعنی Inception به تعیین و تخمین نیازهای سیستم و انتظارات اولیه برمی‌گردد؛ یعنی همان اطلاعات لازم جهت برآورد هزینه و زمان پروژه نرم‌افزاری.
نکته‌ي مهم آن است که در کشور ما ایران، به طور معمول قبل از انجام چنین مرحله‌ای و صرفا بر اساس شرح مشخصات بسیار کلی سیستم؛ یعنی بدون داشتن سه بخش اطلاعات كه در بالا به آن اشاره شد، زمان و هزینه پروژه استعلام و برآورد و حتا تعیین می‌شود. چنین کاری در عمل به شکست پروژه‌های نرم‌افزاری منجر می‌شود. چرا که در مسیر تولید سیستم به دلیل اختلاف فزاینده‌ای که بین برآوردهای اولیه و هزینه‌های واقعی پروژه‌ای به وجود می‌آید دو نتیجه مشخص را غیر قابل اجتناب می‌کند:
-یا هزینه تولید سیستم افزایش می‌یابد که این یعنی ضرر تولیدکننده نرم‌افزار
-و یا سیستم با قابلیت‌ها و انتظارات ناکافی و در کیفیتی نامناسب ارايه می‌شود و این یعنی ضرر کارفرما یا مشتری
پس چه باید کرد؟ چه‌گونه می‌توان اطلاعات لازم سه گانه فوق را به دست آورد؟ آیا استفاه از RFP گروه اطلاعات اول را فراهم می‌سازد؟ به این سئوال به سختی می‌توان پاسخ داد؛ چرا که بر حسب آن که RFP را چه گروهی و با چه فرمت و استانداردی تهیه کرده باشد، جواب می‌تواند متفاوت باشد.
در این میان حلقه‌ي گمشده‌ی دیگری نیز به نظر می‌آید. اجرای مرحله اول فرآیند برای تعیین و برآورد واقعی‌تر پروژه ضروری است، با این همه مشکل در آن است که مشخص نیست هزینه‌ي اجرای این مرحله بر عهده کارفرما خواهد بود یا مجری؟ در صورتی که پروژه طی قراردادی قبل از اجرای این مرحله واگذار شود، پس برآوردها تفاوت فراوانی با واقعیت خواهد داشت و در صورتی که قرارداد پس از مرحله‌ي اول و جمع‌آوری اطلاعات بسته شود، در آن صورت هزینه‌ي اجرای مرحله اول بر عهده چه کسی خواهد بود؟ به همین دلیل بسیاری از پروژه‌های نرم‌افزاری در نیمه‌ي راه به دلیل برآوردهای غلط به شکست می‌انجامند یا در واقع نمی‌توانند نیازهای کاربران را برآورده نمایند.
همان طور که گفته شد روش‌های مختلفی برای تخمین و برآورد حجم فعالیت‌های لازم برای انجام یک پروژه نرم‌افزاری معرفی شده است. معروف‌ترین آن‌ها روش COCOMO است. از آن‌جا که قصد این نوشته تشریح این روش نیست فقط به بيان این نكته بسنده می‌شود که در این روش اساسا میزان خطوط کد لازم برای تولید برنامه بر اساس مفهوم Function point تخمین زده شده و بر اساس آن حجم فعالیت‌های لازم برای پروژه تخمین زده می‌شود.
با فرض این‌که نیازهای سیستم در قالب یوزکیس‌ها شناسایی شده اند، متخصصین RUP نیز روش‌های گوناگونی را برای تخمین هزینه و برآوردهای واقع بینانه پروژه ارايه کرده‌اند. روش دیگری که در میانه‌ي دهه‌ي 1990 ارايه شد روش Use Case Point است. در این روش با تعریف Use Case Point های سیستم و تخصیص نفر ساعت لازم برای پیاده‌سازی آن‌ها حجم فعالیت لازم تخمین زده می‌شود. هر یوزکیس شامل سناریو یا سناریوهایی است. علاوه بر UseCaseهای سیستم واسطه‌های ارتباطی یوزکیس با دنیای بیرون ازجمله برای مثال پنجره‌های ویندوز و یا صفحات وب نیز وجود دارند که طراحی و پیاده‌سازی آن خود حجم کار قابل توجهی را می‌طلبد. بنابر این قدم اول تشخیص یوزکیس‌ها و تشريح سناريوهای آن‌هاست. فرآیند تشخیص و تشریح یوزکیس‌های سیستم هر چه با دقت بیش‌تری انجام شود، برآوردهای واقعی‌تری را منتج خواهد بود. اما همان‌طور که کارشناسان RUP به خوبی می‌دانند، یوزکیس‌ها به عنوان مدلی از فعالیت‌های سیستم به طور كامل انتزاعی بوده و بسته به آن‌که چه کسی و از چه زاویه‌ای آن را می‌نویسد سطوح و پیچیدگی‌های مختلفی می‌توانند داشته باشند. برای مثال می‌توان صدور چک را یک یوزکیس تلقی کرد و هم‌زمان می‌توان صدور چک را زیرسیستمی معرفی نمود که خود شامل تعداد مشخصی یوزکیس است. نتیجه آن که سطوح یوزکیس‌ها می‌توانند مختلف باشند و بنابراین در تعیین تعداد یوزکیس پوینت‌ها باید دقت بیش‌تری مبذول نمود. به هرحال بهتر است که سطوح انتزاع در تمامی سیستم از یک روال ثابتی پیروی کند، در غیر این صورت باید ضریب سطح انتزاع نیز در معادلات مربوط به Use Case Point در نظر گرفته شود.
منبع: http://www.systemgroup.net (http://www.systemgroup.net/)