چگونه يک پروژه نرم افزاري را با موفقيت انجام دهيم!؟

در دوران دانشجويي و حتی قبل از دانشجویی برای من خیلی پیش آمد که برای کسی برنامه بنویسم و پروژه نرم افزاری انجام بدم. بعضی هایش را قبول کردم و برخی را به علت هایی رد کردم. اوایل که جوگیر شده بودم و فکر میکردم خیلی برنامه نویسم، اگر هر پروژه ای به من واگذار میشد، نه نمی گفتم. خوشبختانه آن اوایل به جز یک برنامه، پیشنهاد دیگری به من نشد! به هر حال، در این اواخر رویه ای را پیش گرفتم در پروژه گرفتن و پروژه انجام دادن، که فکر میکنم رویه درستی است و از آن نتیجه های خوبی هم گرفتم. اگر دانشجو هستید و مثل من کم تجربه، حتماً قبل از گرفتن پروژه مسائلی که در این مطلب ذکر کردم را در نظر داشته باشید.

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

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

حتماً قرارداد ببنديد

هر چقدر هم پروژه مورد نظر کوچک باشد، شما بايد با طرف مقابل قرارداد محکمي ببنديد و حتماً امضا و احتمالاً مهر کارفرما را زير آن قرارداد داشته باشيد. حتماً فاکتور زمان و استثناهايي که ممکن است در طول انجام پروژه پيش بيايد را در بندهاي قرارداد جاي دهيد. هزينه انجام پروژه را به صراحت در قرارداد ذکر کنيد و بندي قرار دهيد که مثلاً 50 درصد هزينه را کارفرما در طي انجام پروژه پرداخت کند و بقيه را حداکثر تا 10 روز پس از تحويل پروژه بپردازد. اگر کارفرما به پشتيباني نياز دارد، حتماً و تاکيد مي کنم حتمآً چند بند را در قرارداد براي خدمات پشتيباني و استثناهاي مربوط به آن کنار بگذاريد. به طور مثال شما مي توانيد با همان هزينه انجام پروژه، يک سال به صورت رايگان پشتيباني را انجام دهيد. در اين صورت بطور دقيق تاريخ اتمام يک سال خدمات پشتيباني رايگان را ذکر کنيد. براي استفاده از خدمات پشتيباني نرخي را در قرارداد ذکرکنيد و بندي هم قرار دهيد که ممکن است در سال هاي بعد اين نرخ افزايش يابد. حتماً مشخص کنيد که اين خدمات پشتيباني فقط مربوط به مشکلات مربوط به نرم افزار شماست نه چيز ديگر. مثلاً ذکر کنيد که شما در قبال مشکلات سخت افزاري و نصب ويندوز و اين جور چيزها مسئوليتي نداريد.

پروژه را تحليل کنيد

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

فاز طراحي را جدي بگيريد

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

پياده سازي

اگر فازهاي قبلي را به درستي انجام داده باشيد، در پياده سازي با مشکل حادي برخورد نخواهيد کرد. مستندات دو فاز قبلي مشخصات پياده سازي را تعيين مي کنند. اگر پروژه شما نياز به يک پايگاه داده براي ذخيره اطلاعات دارد (که در اکثر پروژه ها همينطور است)،ابتدا داده هايي که قرار است ذخيره کنيد را بر اساس مستندات فازهاي قبلي شناسايي کنيد. اگر مي توانيد نمودار روابط بين موجوديت ها يا ERD و Data Model را براي درک بهتر بانک اطلاعاتي سيستم رسم کنيد. براي بانک اطلاعاتي خود يک RDBMS مناسب انتخاب کنيد. وقتي به طور مثال SQLite يا Access نياز شما را برطرف مي کنند، بيخودي خود را درگير پيچيدگي هاي SQL Server يا Oracle نکنيد.

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

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

در آخر

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

اگر سئوال یا ابهامی دارید در کامنت های همین مطلب ذکر کنید تا به آن پاسخ داده شود.

مهندسی خواسته ها

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

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

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

خواسته های غیر عملکردی
خواسته هایی هستند که مستقیماً به عملکردهای مشخص شده سیستم نرم افزاری مربوط نمی شوند. وجود یا عدم وجود هر کدام از خواسته های غیرعملکردی در ماهیت اصلی پروژه و هدف کلی آن تاثیر گذار نخواهد بود اما این جمله معنیش این نیست که این خواسته ها اهمیت ندارند. به طور مثال ممکن است رابط کاربری برای یک نرم افزار به عنوان خواسته های غیر عملکردی مطرح شود اما اگر رابط کاربری نداشته باشد استفاده از آن بسیار مشکل خواهد بود (مانند سیستم عامل یونیکس/لینوکس). در برخی مواقع ممکن است برآورده نکردن یک خواسته غیر عملکردی به فلج شدن کل سیستم منجر شود.

در کل تمایز میان انواع مختلف خواسته ها کار آسانی نیست و برای این کار باید با راه حل های کارشناسی و مهندسی نرم افزار خواسته های یک سیستم نرم افزاری را مشخص و سپس دسته بندی نمود.

پ.ن : یکی از دوستان باگ کوچکی در برنامه Darkpad پیدا کرده بود که خوشبختانه رفع شد. (با تشکر از امیرحسین عزیز) بنده به اشتباه کتابخانه Qt را در برنامه include کرده بودم که Darkpad هیچ نیازی به آن نداشت. به همین خاطر در هنگام اجرا با خطایی مبنی بر یافت نشدن فایل qtintf70.dll دریافت می کردید. نسخه جدید (0.5 آزمایشی) چنین مشکلی ندارد و در همه سیستم عامل های ویندوز بدون نیاز به نصب اجرا خواهد شد. Darkpad 0.5 را از اینجا دریافت کنید.

farasun.wordpress.com

Subcribe to Farasun feedمشترک فراسان شويد

farasun.wordpress.com

مطالب مرتبط :

نوشته های دیگر من درباره مهندسی نرم افزار