همه ما در پروژه های مهندسی نرم افزاری بودیم و هستیم که هر روز هر فرد تصمیماتی می گیرد. این تصمیمات شاید در کوتاه مدت نتایج خود را نمایان نکنند. ولی بخشی از روند کلی یک پروژه را همین تصمیمات مشخص می کنند.
در اوایل تشکیل روش ها و اصول مهندسی نرم افزار بیشتر این روش ها و اصول، از دیگر رشته های مهندسی و تولیدی اقتباس شدند. به این صورت که سعی می شد تمام یا بخشی از قواعد بخش های تولیدی صنعتی در این رشته نیز پیاده شود. به مرور زمان و گسترش فناوری اطلاعات این روال ها و روش ها، دستخوش تکامل هایی شدند که بیشتر به ذات این نوع مهندسی نزدیک شوند.
این سیر تکاملی به دلیل تفاوت اساسی مهندسی نرم افزار با سایر رشته های مهندسی بود. می توان به طور خلاصه چند تفاوت مهندسی نرم افزار با دیگر رشته های مهندسی را به این صورت مطرح کرد:
- عدم شناخت دقیق نیازمندی ها
- تغییرات همیشگی و عدم قطعیت در نیازمندی ها
- تغییرات ساختاری زیاد در فناوری ها
این پویایی همه جانبه در پروژه های نرم افزاری مانع از این خواهد شد که مهندسین آن، بدون سبک و سنگین (trade off) کردن شرایط و بررسی شرایط هر لحظه یک پروژه، از یک قاعده و روش کلی به صورت کورکورانه تبعیت کنند.
وقتی هر یک از ما در موقعیت تصمیم گیری قرار می گیریم، رفتارهای متفاوتی از خود بروز می دهیم. عده ای از ما تصمیماتی بر پایه طرفداری های خود میگیریم. عده ای بدون در نظر گرفتن شراید و هزینه ها، تصمیم گیری می کنیم و عده ای بلند پروازی و یا محافظه کاری زیادی به خرج می دهیم.
اولین موردی که در اتخاد یک تصمیم خوب (لااقل در مهندسی نرم افزار) باید در نظر گرفته شود این است که همه چیز در این رشته قابل سبک و سنگین کردن است. مخصوصا در زمینه مهندسی فرایندها و مدیریت پروژه. تقریبا هیچ قانون و قاعده و روش جهان شمولی در مهندسی نرم افزار وجود ندارد (شاید برعکس رشته های مانند مهندسی عمران). هیچ کسی نمی تواند ادعا کند که به طور مثال مدیریت پروژه چابک راه حل همه مشکلات است و باید بدون و کم و کاست تمام قواعد آن اجرایی شود. شاید در بعضی فرهنگ ها و سازمان ها و پروژه ها حتی مدل waterfall نیز جواب خوبی داده باشد!!!!
در استفاده از هر چیزی در مهندسی نرم افزار (فناوری، روال، فرایند، روش) بهتر این است که با جمع آوری اطلاعات و تحقیق و بررسی و استدلال، تصمیم گرفته شود که چه بخش هایی از موضوع خاص قابل پیاده سازی در سازمان است. اگر منصفانه به موضوع نگاه کنیم خواهیم دید که نمی توان از هیچ روش خاص مهندسی نرم افزار پیروی کورکورانه کرد. و باید به فرهنگ سازمان، شرایط پروژه و دیگر موضوعات حتما توجه شود.
سبگ و سنگین کردن (trade off) در هر تصمیم روزمره هریک از نیروهای فنی و غیر فنی شاغل در یک پروژه نرم افزاری دخالت دارد.
وقتی یک تصمیم نتیجه تحقیق و بررسی و سبک و سنگین کردن نباشد احتمالا به صورت احساسی گفته شده است. تصمیمات احساسی مشکلات خاص خودشان را دارند که در زیر به چند مورد اشاره شده است.
- قابل بررسی و اندازه گیری از نظر نتایج نیستند. (چون دلایلی و اهداف ملموسی پشت آن ها نبوده است)
- فرد تصمیم گیرنده موضع شخصی در قبال آن تصمیم خواهد گرفت
این موارد بحث و تبادل نظر در مورد تصمیمات اتخاد شده را بسیار مشکل می کنند.
هزینه دیرکرد
یکی از فاکتورهایی که در زمان تصمیم گیری باید به آن دقت کرد هزینه دیرکرد است. هزینه دیرکرد در زبان ساده هزینه ای است که سازمان از دیر رسیدن محصول به دست مشتری متحمل خواهد شد.
این هزینه به صورت دقیق قابل اندازه گیری نیست و الزاما هزینه های مادی را شامل نمی شود. ولی همین که به صورت نسبی به این موضوع دقت شود تاثیر بسیار زیادی در تصمیم گیری ها خواهد داشت.
به طور مثال در موضوعات فنی ممکن است روش انجام دادن درست و صحیح یک کار مدت زمان تحویل آن بخش از محصول را یک ماه عقب بیندازد. اگر در برخورد با مدیریت و تحلیل شرایط، تیم به این نتیجه رسید که هزینه دیر شدن این بخش از سیستم بسیار بیشتر از هزینه انجام غیر مهندسی آن است، تیم می تواند احساسات مهندسی (!) خود را نادیده گرفته و به سریعترین حالت ممکن این امکان را در سیستم ایجاد کند و در ادامه مراحل تولید زمانی برای رفع مشکلات ناشی از آن کنار بگذارد.
البته شایان ذکر است موضوعی که در مثال بالا در مورد تصمیمات فنی مطرح شد، ممکن است تیم و شرکت تولید کننده نرم افزار را به دام خطرناکی بی اندازد. از این جهت است که خیلی از مشاوران و مهندسین نرم افزار به شدت با ایجاد عمدی یا سهوی بدهی فنی در پروژه ها مخالف هستند. این دام همان انجام دادن بی کیفیت کارها به بهانه عجله در ارائه محصول است. اگر تمامی تصمیمات فنی، تحت تاثیر مدیریت و عجله در ارائه محصول گرفته شود، دست آخر با محصولی مواجه خواهید شد که غیر قابل نگهداشت است و عملا به هیچ دردی نمی خورد. به همین دلیل موضوع سبک و سنگین کردن شرایط باید بسیار با دقت پیش برود.
بهتر است در اتخاذ تصمیمات به بار مالی آن نیز توجه کنیم. اکثر مواقع نتیجه تصمیمات بر اساس نتایج مالی آنها سنجیده می شوند. یکی از هنرهای مدیران و مهندسین نر م افزار ایجاد توازن در رسیدن به اهداف کوتاه مدت (مانند ارائه نسخه های مورد نظر جهت جذب سرمایه گذاری و یا قرارداد) و اهداف بلند مدت (قابلیت نگهداشت نرم افزار، هزینه های نگهداشت و …) است. اگر تصمیمات در رده های مختلف سازمانی بدور از احساسات و برداشت های غیر مهندسی باشند این امر به راحتی اتفاق خواهد افتاد.
