[vc_row][vc_column width=”5/6″][vc_empty_space height=”50px”][vc_column_text]

حمیدرضا عباسی

کارشناس نرم افزار

[/vc_column_text][/vc_column][vc_column width=”1/6″][vc_single_image image=”3366″ alignment=”center” style=”vc_box_circle_2″][/vc_column][/vc_row][vc_row][vc_column][vc_empty_space height=”50px”][/vc_column][/vc_row][vc_row][vc_column][thim-heading heading=”هر خط کد چند ؟!”][vc_column_text]

در دره سیلیکون کالیفرنیا، صدها هزار نفر بر روی پروژه های چند میلیارد دلاری کار می کنند و بازار نرم افزار دنیا را می چرخانند، آن ها نرم افزار هایی را تولید می کنند که دارای کمترین میزان خطا و بیشترین میزان کارایی می باشد، بهترین ارتباط را با کاربر نهایی برقرار می کند و تضمین سود چند ده برابری برای تولید کننده و سرمایه گذار دارد. مایکروسافت با وجود رقبای جدی همچون گوگل و اپل، همچنان یکه تاز دنیای نرم افزار است و هرگز در تولید نرم افزارهای با سورس بسته، با وجود نیاز به سرمایه گذاری هایی که برابری با بودجه سالانه یک کشور دارد، به خود تردیدی راه نمی دهد، حتی اگر یکی از رقیبانش شرکت ابر قدرتمندی مثل گوگل باشد که حتی درصد بالایی از نرم افزارهای خود را به صورت رایگان ارائه می دهد. اگر از این دره خارج شویم و کمی به دیگر شهر های آمریکا نگاهی بیاندازیم، خواهیم دید که آنجا کمی سرمایه گذاری کمتر شده است، اما درآمد ها همچنان ثابت است، سودها هم همچنان بالاست، حتی خارج از خاک ایالت متحده نیز، پروژه های نرم افزاری زیادی، پنجه در پنجه دره سیلیکون می اندازند و گاهی هم حتی به آن ها شکست سختی وارد می کنند. نمونه اش سایت نوپای Alibaba.com می باشد که این روزها رقیب جدی برای آمازون و سایت های تجارت الکترونیک آمریکایی محسوب می شود. چه کسی فکر می کرد روزی یک دانشجو، یک پروژه وب سایتیِ دانشگاهی را به یکی از پردرآمد ترین سایت های  جهان و البته مشهور ترینشان تبدیل کند، شاید وقتی زاکربرگ پروژه فیس بوک را شروع کرد، در افق باورش تنها یک شبکه اجتماعی دوستانه، دانشگاهی یا شهری دیده می شد. اما این ابزار چنان مدیریت شد که با وجود اینکه بر پایه گزارشات یک پنجم طلاق های آمریکا پایه فیس بوکی دارند و با وجود افشای دزدی مسئولین سایت از اطلاعات شخصی افراد و جاسوسی برای دولت آمریکا، با این حال باز هم هنوز به کاربران آن اضافه می شود.

[/vc_column_text][vc_empty_space height=”40px”][/vc_column][/vc_row][vc_row][vc_column width=”1/2″][vc_single_image image=”3355″ img_size=”large” alignment=”center”][/vc_column][vc_column width=”1/2″][vc_empty_space height=”85px”][vc_column_text]

چرا در ایران هر چه می دویم، باز هم سرخانه اول هستیم؟! چرا مدیریت پروژه در اینجا ناشناخته است؟! چرا ایرانیان دوست ندارند برای نرم افزار پولی خرج کنند؟! چرا برنامه نویسان ایرانی زود بازنشست می شوند؟! چرا ایده ها اینجا مرده اند؟! چرا …

[/vc_column_text][/vc_column][/vc_row][vc_row][vc_column width=”1/2″][vc_column_text]

تعجب نکنید! جوابی که داده شد از آسمان آورده نشد؛ این نتیجه تحقیقی است که آقای پروفسور بوهم و همکارانشان در سال 1983 داشته اند و اکنون با توجه به نرخ فعلی نگارش شده است. در ادامه ابعاد این موضوع را باز می کنیم.

[/vc_column_text][/vc_column][vc_column width=”1/2″][vc_empty_space height=”25px”][vc_column_text]

حداقل 58 هزار تومان!

[/vc_column_text][/vc_column][/vc_row][vc_row][vc_column][vc_empty_space height=”40px”][/vc_column][/vc_row][vc_row][vc_column width=”1/2″][vc_single_image image=”3356″ img_size=”large” alignment=”center”][vc_column_text]

پروفسور بوهم  (استاد بی بدیل مهندسی نرم افزار با سالها تجربه پیرامون برآورد هزینه های نرم افزاری)

[/vc_column_text][/vc_column][vc_column width=”1/2″][vc_column_text]

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

[/vc_column_text][/vc_column][/vc_row][vc_row][vc_column][vc_column_text]

بر همین اساس و طبق یک معادله ساده، اگر برآورد زمان پروژه پروژه 3 نفر-ماه در نظر گرفته شود و حقوق هر برنامه نویس هم ماهانه 30 میلیون ریال باشد (برای سادگی حقوق تمام اعضای فعال پروژه را نیز مانند حقوق برنامه نویس در نظر می گیریم)، بودجه مورد نیاز برای پروژه 180 میلیون ریال می شود:

B = 3 . (30,000,000) * 2 = 180,000,000 RLS

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

[/vc_column_text][/vc_column][/vc_row][vc_row][vc_column width=”1/2″][vc_column_text]

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

[/vc_column_text][/vc_column][vc_column width=”1/2″][vc_empty_space height=”25px”][vc_single_image image=”3354″ img_size=”large” alignment=”center”][/vc_column][/vc_row][vc_row][vc_column][vc_column_text]

فرمول های بالا برگرفته از مدل ابتدایی سیستم برآورد نرم افزار کوکومو2 و در واقع ماحصل زحمات آقای بوهم هست، همانطور که مشاهده می کنید، برای هر دسته نرم افزاری یک ثابت ضربی و یک ثابت توانی در نظر گرفته شده است و KDSI که در واقع کیلو خط کد می باشد، نتیجه محاسبه تعداد خطوط برآوردی برنامه بر اساس آمار و احتمالات و تجربیات تقسیم بر 1000 می باشد، یعنی هر 1000 خط کد، یک کیلو کد می باشد.

به عنوان یک مثال ساده و با فرض فرمول اول، اگر به طور مثال وبسایتی دارای 4000 خط کد باشد، به این معنی است که اندازه پروژه 10 نفر-ماه می باشد:

PM = 2.4 * (4)^1.05 = 10.2 (به عدد 10 رند می شود)

اما آیا این بدان معناست که با داشتن هفت برنامه نویس این وب سایت ظرف مدت یک ماه به اتمام می رسد؟ در واقع جواب منفی است، زیرا تازه عدد PM را باید با متغیرهای تضمین خطای دیگری محاسبه کنیم تا زمان واقعی توسعه نرم افزار بدست بیاید. جدول بالا را کمی کاملتر می کنیم:

ستون سمت راست جدول فرمولی است که زمان توسعه را برحسب ماه محاسبه می نماید، یعنی ابتدا ستون میانی محاسبه می شود و بر اساس آن در ستون سوم، زمان توسعه به دست می آید:

PM = 2.5 (10)^0.38= 5.9 ماه

فرض کنید، تنها دو توسعه دهنده داریم، به این صورت نتیجه زمان پروژه اینطور به دست می آید:

PM = 2.5 (2)^0.38*  5 =  16.2 ماه

همانطور که مشاهده کردید، ما نیرو را 5 برابر کم کردیم، اما زمان پروژه 5 برابر بیشتر نشد! این مسئله به این دلیل است که وقتی تعداد اعضای تیم کم می شوند، تعامل بین نفرات بالاتر می رود و این سرعت توسعه در واحد تعداد نفرات – ماه بیشتر می کند. در واقع عکس این موضوع نیز صادق است و در واقع وقتی برای یک پروژه وقت کمی داریم، الزاماً با تزریق نیرو سرعت کدنویسی بالاتر نمی رود و حتی گاهی با این کار سرعت پروژه را کندتر نیز کرده ایم.

در واقع هدف مان از این بررسی ها و محاسبات، ریز شدن بر روی برآوردهای نرم افزاری نیست – و در واقع به هیچ عنوان این مقوله در یک مقاله کوتاه نمی گنجد -، هدف این است که نشان دهیم محاسبات بالا بهترین حالت ممکن می باشد، در حقیقت توسعه نرم افزار شامل چالش های بسیاری می باشد و ممکن است با تأخیر های فراونی روبرو شود که بودجه را با مشکل جدی روبرو کند، برای مثال عدم هماهنگی در یک تیم حرفه ای، زمان توسعه را به مقداری قابل توجهی زیاد می کند و یا یک اتفاق غیر منتظره برای یکی از اعضای کلیدی تیم، که منجر به کاهش روحیه وی شود، ممکن است نظم را به طور کلی از تیم دور کند.

حالا که یکی از حالات برآوردی را محاسبه کردیم و گفتیم که این تازه بهترین حالت است، بر گردیم به سوالی که در این نگاه مطرح کردیم: «هر خط کد چند؟»

بر اساس مطالعاتی که آقای پروفسور بوهم در سال 1995 به همراه همکاران خود و با بررسی پروژه های بسیار انجام دادند، مشخص شد که توان تولید به ازای هر نفر-ماه رقمی در حدود 4 تا 50 نقطه شیء است که این معادل 30 تا 900 خط کد می باشد، یعنی برای برنامه های بسیار پیچیده عدد 30 و برای برنامه های معمولی عدد 900 ارائه شد.

به خاطر دارید که در پاسخ به سوال این نگاه، مبلغ 58  هزار تومان را بیان کردیم. بیایید به این عدد پایه علمی بدهیم، بر اساس مطالعات آماری حقوق یک برنامه نویس در ایالات متحده به طور متوسط سالانه 75000 دلار می باشد، به عبارت دیگر، برنامه نویس ها ماهانه 6250 دلار حقوق دریافت می کنند (در نگاه های بعدی این رقم ها را بیشتر بررسی میکنیم)، حالا رقم 6250 را به کمترین میزان خروجی کد در محاسبات آقای بوهم، یعنی 900 خط در ماه تقسیم می کنیم:

 6.9$ = 900 / 6250$  = هر خط کد

اگر 6.9 دلار را در معادل ریالی امروز 17 مرداد 1397، که 92000 ریال می باشد، ضرب کنیم، به رقم 634.800 ریال می رسیم که می بینیم کمی از جواب ما هم بیشتر شده است.

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

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

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

در واقع در مهندسی نرم افزار، برآورد هزینه نرم افزار و برآورد ارزش و همچنین برآورد درآمد برنامه نویسی، فرآیندی کاملاً تکرار پذیر است.

فایل صوتی این مقاله را گوش دهید:

[/vc_column_text][/vc_column][/vc_row]