مشاهده نسخه کامل
: AK1
13-11-2006, 21:35
می توان طرحی داشت اگر نتوان آن را به درستی اندازه گیری كرد و آغاز پروژه بدون وجود طرح مانند آن است كه شكست پروژه طراحی شده باشد.
[ برای مشاهده لینک ، لطفا با نام کاربری خود وارد شوید یا ثبت نام کنید ]
نمی توان طرحی داشت اگر نتوان آن را به درستی اندازه گیری كرد و آغاز پروژه بدون وجود طرح مانند آن است كه شكست پروژه طراحی شده باشد.
پروژه نرم افزاری موفق، پروژه ای است كه در قالب هزینه و زمانی معین و از پیش تعیین شده به انجام برسد. نرم افزار كاری تولیدی به شمار می رود كه هزینه عمده آن نیروی كارآزموده و متخصص است. بنابراین مهم ترین ابزار یك پروژه نرم افزاری و به طور تقریبی بخش اعظم هزینه های آن به نیروی كار متخصص درگیر در آن مرتبط است. سوال این است كه چگونه می توان زمان و هزینه یك پروژه نرم افزاری را تخمین زد. ماهیت خلاق پروژه های نرم افزاری و انتزاعی بودن آن تخمین هزینه و زمان انجام آن ها را بی نهایت مشكل می كند. روش های متداول تخمین زمان و هزینه خود اساسا انتزاعی است با این همه هنوز هم تخمین پروژه امری لازم و ضروری محسوب می شود.
روش های مختلفی در تخمین و برآورد حجم فعالیت های لازم در انجام یك پروژه نرم افزاری در جامعه نرم افزار ارایه شده است. فارغ از این كه از چه روشی در تخمین زمان و هزینه یك پروژه نرم افزاری استفاده می شود، مهم آن است كه بدون وجود اطلاعات كافی در زمینه حوزه و دامنه سیستم و قابلیت ها و توانایی های آن و همچنین شرایط محیطی و فرهنگی تیم تولید نرم افزار و پیچیدگی های تكنیكی آن، برآورد واقع بینانه پروژه كاری دور از دسترس می نماید.
پس نخست باید اطلاعات ضروری آماده شود.
●نگارنده این اطلاعات را در سه دسته تقسیم كرده است:
۱ـ اطلاعات مربوط به حوزه سیستم و نیازهای كاركردی و غیر كاركردی آن
۲ـ اطلاعات مربوط به محیطی كه سیستم در آن عملیاتی خواهد شد.
۳ـ اطلاعات مربوط به محیط تولید و توسعه سیستم
از این سه دسته اطلاعات گروه اول مهم ترین است. عدم تشخیص درست نیازها و قابلیت های كاركردی و غیر كاركردی سیستم، عموما و به غایت ما را از تخمین درست هزینه و زمان مورد نیاز دور می كند. به همین دلیل لازمه یك برآورد مناسب، تشخیص و تعیین اولیه نیازهای سیستم در فرآیندی سازمان یافته است. در روش های سنتی ساخت یافته به طور معمول بخشی از فعالیت های مرحله امكان سنجی به این امر اختصاص دارد. در فرآیندهای مدرن مهندسی نرم افزار مانند RUP نیز یكی از فعالیت های مهم مرحله اول آن یعنی Inception به تعیین و تخمین نیازهای سیستم و انتظارات اولیه برمی گردد یعنی همان اطلاعات لازم جهت برآورد هزینه و زمان پروژه نرم افزاری.
نكته مهم آن است كه در كشور ما ایران، به طور معمول قبل از انجام چنین مرحله ای و صرفا بر اساس شرح مشخصات بسیار كلی سیستم یعنی بدون داشتن سه بخش اطلاعات كه در بالا به آن اشاره شد، زمان و هزینه پروژه استعلام و برآورد و حتی تعیین می شود. چنین كاری در عمل به شكست پروژه های نرم افزاری منجر می شود. چرا كه در مسیر تولید سیستم به دلیل اختلاف فزاینده ای كه بین برآوردهای اولیه و هزینه های واقعی پروژه ای به وجود می آید دو نتیجه مشخص را غیر قابل اجتناب می كند:
۱- یا هزینه تولید سیستم افزایش می یابد كه این یعنی ضرر تولیدكننده نرم افزار
۲- و یا سیستم با قابلیت ها و انتظارات ناكافی و در كیفیتی نامناسب ارایه می شود و این یعنی ضرر كارفرما یا مشتری پس چه باید كرد؟ چگونه می توان اطلاعات لازم سه گانه فوق را به دست آورد؟ آیا استفاه از RFP گروه اطلاعات اول را فراهم می سازد؟ به این سئوال به سختی می توان پاسخ داد چرا كه بر حسب آن كه RFP را چه گروهی و با چه فرمت و استانداردی تهیه كرده باشد، جواب می تواند متفاوت باشد.
در این میان حلقه گمشده دیگری نیز به نظر می آید. اجرای مرحله اول فرآیند برای تعیین و برآورد واقعی تر پروژه ضروری است، با این همه مشكل در آن است كه مشخص نیست هزینه اجرای این مرحله بر عهده كارفرما خواهد بود یا مجری؟ در صورتی كه پروژه طی قراردادی قبل از اجرای این مرحله واگذار شود، پس برآوردها تفاوت فراوانی با واقعیت خواهد داشت و در صورتی كه قرارداد پس از مرحله اول و جمع آوری اطلاعات بسته شود، در آن صورت هزینه اجرای مرحله اول بر عهده چه كسی خواهد بود؟ به همین دلیل بسیاری از پروژه های نرم افزاری در نیمه راه به دلیل برآوردهای غلط به شكست می انجامند یا در واقع نمی توانند نیازهای كاربران را برآورده نمایند. همان طور كه گفته شد روش های مختلفی برای تخمین و برآورد حجم فعالیت های لازم برای انجام یك پروژه نرم افزاری معرفی شده است. معروف ترین آن ها روش COCOMO است. از آن جا كه قصد این نوشته تشریح این روش نیست فقط به بیان این نكته بسنده می شود كه در این روش اساسا میزان خطوط كد لازم برای تولید برنامه بر اساس مفهوم Function point تخمین زده شده و بر اساس آن حجم فعالیت های لازم برای پروژه تخمین زده می شود.
با فرض این كه نیازهای سیستم در قالب یوزكیس ها شناسایی شده اند، متخصصین RUP نیز روش های گوناگونی را برای تخمین هزینه و برآوردهای واقع بینانه پروژه ارایه كرده اند. روش دیگری كه در میانه دهه ۱۹۹۰ ارایه شد روش Use Case Point است. در این روش با تعریف Use Case Point های سیستم و تخصیص نفر ساعت لازم برای پیاده سازی آن ها حجم فعالیت لازم تخمین زده می شود. هر یوزكیس شامل سناریو یا سناریوهایی است. علاوه بر UseCaseهای سیستم واسطه های ارتباطی یوزكیس با دنیای بیرون ازجمله برای مثال پنجره های ویندوز و یا صفحات وب نیز وجود دارند كه طراحی و پیاده سازی آن خود حجم كار قابل توجهی را می طلبد. بنابر این قدم اول تشخیص یوزكیس ها و تشریح سناریوهای آن هاست. فرآیند تشخیص و تشریح یوزكیس های سیستم هر چه با دقت بیشتری انجام شود، برآوردهای واقعی تری را منتج خواهد بود. اما همان طور كه كارشناسان RUP به خوبی می دانند، یوزكیس ها به عنوان مدلی از فعالیت های سیستم به طور كامل انتزاعی بوده و بسته به آن كه چه كسی و از چه زاویه ای آن را می نویسد سطوح و پیچیدگی های مختلفی می توانند داشته باشند. برای مثال می توان صدور چك را یك یوزكیس تلقی كرد و هم زمان می توان صدور چك را زیرسیستمی معرفی نمود كه خود شامل تعداد مشخصی یوزكیس است. نتیجه آن كه سطوح یوزكیس ها می توانند مختلف باشند و بنابراین در تعیین تعداد یوزكیس پوینت ها باید دقت بیش تری مبذول نمود. به هرحال بهتر است كه سطوح انتزاع در تمامی سیستم از یك روال ثابتی پیروی كند، در غیر این صورت باید ضریب سطح انتزاع نیز در معادلات مربوط به Use Case Point در نظر گرفته شود.
منابع:
systemGroup. net
روزنامه ابرار
[ برای مشاهده لینک ، لطفا با نام کاربری خود وارد شوید یا ثبت نام کنید ]
[ برای مشاهده لینک ، لطفا با نام کاربری خود وارد شوید یا ثبت نام کنید ]
نمی توان طرحی داشت اگر نتوان آن را به درستی اندازه گیری كرد و آغاز پروژه بدون وجود طرح مانند آن است كه شكست پروژه طراحی شده باشد.
پروژه نرم افزاری موفق، پروژه ای است كه در قالب هزینه و زمانی معین و از پیش تعیین شده به انجام برسد. نرم افزار كاری تولیدی به شمار می رود كه هزینه عمده آن نیروی كارآزموده و متخصص است. بنابراین مهم ترین ابزار یك پروژه نرم افزاری و به طور تقریبی بخش اعظم هزینه های آن به نیروی كار متخصص درگیر در آن مرتبط است. سوال این است كه چگونه می توان زمان و هزینه یك پروژه نرم افزاری را تخمین زد. ماهیت خلاق پروژه های نرم افزاری و انتزاعی بودن آن تخمین هزینه و زمان انجام آن ها را بی نهایت مشكل می كند. روش های متداول تخمین زمان و هزینه خود اساسا انتزاعی است با این همه هنوز هم تخمین پروژه امری لازم و ضروری محسوب می شود.
روش های مختلفی در تخمین و برآورد حجم فعالیت های لازم در انجام یك پروژه نرم افزاری در جامعه نرم افزار ارایه شده است. فارغ از این كه از چه روشی در تخمین زمان و هزینه یك پروژه نرم افزاری استفاده می شود، مهم آن است كه بدون وجود اطلاعات كافی در زمینه حوزه و دامنه سیستم و قابلیت ها و توانایی های آن و همچنین شرایط محیطی و فرهنگی تیم تولید نرم افزار و پیچیدگی های تكنیكی آن، برآورد واقع بینانه پروژه كاری دور از دسترس می نماید.
پس نخست باید اطلاعات ضروری آماده شود.
●نگارنده این اطلاعات را در سه دسته تقسیم كرده است:
۱ـ اطلاعات مربوط به حوزه سیستم و نیازهای كاركردی و غیر كاركردی آن
۲ـ اطلاعات مربوط به محیطی كه سیستم در آن عملیاتی خواهد شد.
۳ـ اطلاعات مربوط به محیط تولید و توسعه سیستم
از این سه دسته اطلاعات گروه اول مهم ترین است. عدم تشخیص درست نیازها و قابلیت های كاركردی و غیر كاركردی سیستم، عموما و به غایت ما را از تخمین درست هزینه و زمان مورد نیاز دور می كند. به همین دلیل لازمه یك برآورد مناسب، تشخیص و تعیین اولیه نیازهای سیستم در فرآیندی سازمان یافته است. در روش های سنتی ساخت یافته به طور معمول بخشی از فعالیت های مرحله امكان سنجی به این امر اختصاص دارد. در فرآیندهای مدرن مهندسی نرم افزار مانند RUP نیز یكی از فعالیت های مهم مرحله اول آن یعنی Inception به تعیین و تخمین نیازهای سیستم و انتظارات اولیه برمی گردد یعنی همان اطلاعات لازم جهت برآورد هزینه و زمان پروژه نرم افزاری.
نكته مهم آن است كه در كشور ما ایران، به طور معمول قبل از انجام چنین مرحله ای و صرفا بر اساس شرح مشخصات بسیار كلی سیستم یعنی بدون داشتن سه بخش اطلاعات كه در بالا به آن اشاره شد، زمان و هزینه پروژه استعلام و برآورد و حتی تعیین می شود. چنین كاری در عمل به شكست پروژه های نرم افزاری منجر می شود. چرا كه در مسیر تولید سیستم به دلیل اختلاف فزاینده ای كه بین برآوردهای اولیه و هزینه های واقعی پروژه ای به وجود می آید دو نتیجه مشخص را غیر قابل اجتناب می كند:
۱- یا هزینه تولید سیستم افزایش می یابد كه این یعنی ضرر تولیدكننده نرم افزار
۲- و یا سیستم با قابلیت ها و انتظارات ناكافی و در كیفیتی نامناسب ارایه می شود و این یعنی ضرر كارفرما یا مشتری پس چه باید كرد؟ چگونه می توان اطلاعات لازم سه گانه فوق را به دست آورد؟ آیا استفاه از RFP گروه اطلاعات اول را فراهم می سازد؟ به این سئوال به سختی می توان پاسخ داد چرا كه بر حسب آن كه RFP را چه گروهی و با چه فرمت و استانداردی تهیه كرده باشد، جواب می تواند متفاوت باشد.
در این میان حلقه گمشده دیگری نیز به نظر می آید. اجرای مرحله اول فرآیند برای تعیین و برآورد واقعی تر پروژه ضروری است، با این همه مشكل در آن است كه مشخص نیست هزینه اجرای این مرحله بر عهده كارفرما خواهد بود یا مجری؟ در صورتی كه پروژه طی قراردادی قبل از اجرای این مرحله واگذار شود، پس برآوردها تفاوت فراوانی با واقعیت خواهد داشت و در صورتی كه قرارداد پس از مرحله اول و جمع آوری اطلاعات بسته شود، در آن صورت هزینه اجرای مرحله اول بر عهده چه كسی خواهد بود؟ به همین دلیل بسیاری از پروژه های نرم افزاری در نیمه راه به دلیل برآوردهای غلط به شكست می انجامند یا در واقع نمی توانند نیازهای كاربران را برآورده نمایند. همان طور كه گفته شد روش های مختلفی برای تخمین و برآورد حجم فعالیت های لازم برای انجام یك پروژه نرم افزاری معرفی شده است. معروف ترین آن ها روش COCOMO است. از آن جا كه قصد این نوشته تشریح این روش نیست فقط به بیان این نكته بسنده می شود كه در این روش اساسا میزان خطوط كد لازم برای تولید برنامه بر اساس مفهوم Function point تخمین زده شده و بر اساس آن حجم فعالیت های لازم برای پروژه تخمین زده می شود.
با فرض این كه نیازهای سیستم در قالب یوزكیس ها شناسایی شده اند، متخصصین RUP نیز روش های گوناگونی را برای تخمین هزینه و برآوردهای واقع بینانه پروژه ارایه كرده اند. روش دیگری كه در میانه دهه ۱۹۹۰ ارایه شد روش Use Case Point است. در این روش با تعریف Use Case Point های سیستم و تخصیص نفر ساعت لازم برای پیاده سازی آن ها حجم فعالیت لازم تخمین زده می شود. هر یوزكیس شامل سناریو یا سناریوهایی است. علاوه بر UseCaseهای سیستم واسطه های ارتباطی یوزكیس با دنیای بیرون ازجمله برای مثال پنجره های ویندوز و یا صفحات وب نیز وجود دارند كه طراحی و پیاده سازی آن خود حجم كار قابل توجهی را می طلبد. بنابر این قدم اول تشخیص یوزكیس ها و تشریح سناریوهای آن هاست. فرآیند تشخیص و تشریح یوزكیس های سیستم هر چه با دقت بیشتری انجام شود، برآوردهای واقعی تری را منتج خواهد بود. اما همان طور كه كارشناسان RUP به خوبی می دانند، یوزكیس ها به عنوان مدلی از فعالیت های سیستم به طور كامل انتزاعی بوده و بسته به آن كه چه كسی و از چه زاویه ای آن را می نویسد سطوح و پیچیدگی های مختلفی می توانند داشته باشند. برای مثال می توان صدور چك را یك یوزكیس تلقی كرد و هم زمان می توان صدور چك را زیرسیستمی معرفی نمود كه خود شامل تعداد مشخصی یوزكیس است. نتیجه آن كه سطوح یوزكیس ها می توانند مختلف باشند و بنابراین در تعیین تعداد یوزكیس پوینت ها باید دقت بیش تری مبذول نمود. به هرحال بهتر است كه سطوح انتزاع در تمامی سیستم از یك روال ثابتی پیروی كند، در غیر این صورت باید ضریب سطح انتزاع نیز در معادلات مربوط به Use Case Point در نظر گرفته شود.
منابع:
systemGroup. net
روزنامه ابرار
[ برای مشاهده لینک ، لطفا با نام کاربری خود وارد شوید یا ثبت نام کنید ]