آشنایی با شروع برنامه نویسی یک برنامه و نوشتن نرم افزار

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

امکان سنجی

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

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

پیاده سازی، آزمایش و مستندسازی

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

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

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

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

کاربران بطور معمول در برابر تغییرات مقاومت نشان می دهند و از ماجراجویی در محیط ناآشنا اجتناب می کنند، برای همین در فاز استقرار مهم است کلاس های آموزشی برای کاربران جدید نرم افزار گذاشته شود. نگهداری و ارتقای نرم افزاری برای پوشش، مسائل پوشش داده ‌نشده یا نیازمندی های تازه ای که ممکن است به وجود آیند مدت خیلی زیادی حتی بیشتر از زمان اولیه تولید نرم افزار زمان بگیرد. این مرحله ممکن است نیاز باشد تا کدهای برنامه نویسی تازه ای که در طراحی اصلی برنامه نیز دیده نشده اضافه شود تا مسائل و مشکلات دیده نشده حل شوند یا ممکن است کاربر درخواست عملیات اصلی دیگری کند و برنامه نویسی های تازه ای برای برآورده کردن نیازهای جدید انجام گیرد. اگر هزینه کار فاز نگهداری از ۲۵ درصد هزینه فاز قبلی که پیاده سازی بود، بیشتر باشد، این احتمال وجود دارد که کیفیت کلی فاز قبلی خیلی ضعیف بوده باشد. در این صورت مدیران پروژه باید گزینه ایجاد مجدد سامانه (یا بخشی از سامانه) را قبل از اینکه هزینه های نگهداری غیرقابل کنترل شود را مطرح کنند.

روندهای ساخت نرم افزار

نرم افزارهای بطور معمول بر مبنای الگوهای مختلفی همچون آبشاری، برنامه نویسی مفرط، چابک، اسکرام و... ساخته می شوند که هریک مزایا و معایب خاص خود را دارند.

الگوی آبشاری

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

• مشخصات مورد نیاز یا تحلیل نیازمندی ها
• طراحی نرم افزار
• پیاده سازی و یکپارچه سازی
• تست نرم افزار یا اعتبارسنجی
• گسترش نرم افزار یا نصب
• نگهداری نرم افزار

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

الگوی چرخشی یا مارپیچ Spiral Model

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

• تدوین و فرموله کردن برنامه ریزی خوب است برای شناسایی اهداف سیستم، قسمت های انتخاب شده جهت پیاده سازی برنامه، محدودیت های واضح و مشخص پروژه
• تحلیل ریسک و مشکلات سامانه: ارزیابی تحلیلی برنامه های انتخاب شده، جهت مشخص کردن چگونگی شناسایی و از بین بردن ریسک‌ها
• پیاده سازی پروژه: پیاده سازی تولید نرم افزار و تأیید کارایی سامانه

الگو مارپیچ مبتنی بر ریسک، بر اختیار انتخاب گزینه ها و محدودیت ها در سفارش ها برای پشتیبانی استفاده مجدد نرم افزار و اینکه کیفیت نرم افزار می‌تواند در ادغام اهداف ویژه در تولید نرم افزار کمک می کند، تأکید می کند.

از مهمترین معایب الگوی مارپیچی به موارد زیر می توان اشاره کرد:

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

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

الگوی تکرارشونده و افزایشی

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

الگوی توسعه سریع نرم افزار RAD

روش توسعه سریع نرم افزار(RAD) روش تکراری را به عنوان پایه کار استفاده می کند اما طرفداری نظریه سبکتر و محبوبیت بیشتر از روش سنتی است. روش سریع از بازخوردها به جای برنامه ریزی به عنوان سازوکار اصلی کنترل پروژه استفاده می کند. بازخوردها به وسیله آزمون های مرتب و انتشار پیاپی در بازه های زمانی کوتاه نرم افزارهای در حال تکامل تولید می شوند. روش‌های گوناگونی از فرایند سریع برای تولید نرم افزار استفاه می شود:

الگوی اسکرام

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

الگوی تکامل قابلیت یکپارچه سازی CMMI

الگوی تکامل قابلیت یکپارچه‌سازی (CMMI) یکی از الگوهای پیشنهادی و تکنیک های پیشتاز است. ارزیابی سازمان های مستقل و رتبه‌بندی در مورد کیفیت چگونگی تعریف فرایندهای آن سازمان ها را دنبال می کند، نه بر کیفیت خود فرایندها یا نرم افزار تهیه شده است. الگوی CMMI جایگزین الگوی CMM شده‌است.

استاندارد بررسی بهبود قابلیت نرم افزار

ایزو 15504 که با عنوان فرایند تشخیص و تعیین بهبود قابلیت نرم افزار (SPICE) سرنام Software Process Improvement and Capability Determination شناخته می شود، چارچوبی برای ارزیابی فرایندهای نرم افزار است. این استاندارد تنظیمات قالب روشنی برای مقایسه فرایندها به‌شمار می‌رود. SPICE خیلی شبیه CMMI استفاده می شود. فرایندهای این الگو برای مدیریت، کنترل، راهنمایی و نظارت تولید نرم افزار است. این الگو جهت سنجش سازماندهی تولید و توسعه یا تیم پروژه به صورت واقعی در طول مدت تولید نرم افزار استفاده می شود. تجزیه و تحلیل این اطلاعات برای شناسایی نقاط ضعف و حرکت به سمت بهبود پروژه استفاه می شود. همچنین برای تشخیص نقاط قوت پروژه که می‌تواند برای سازمان یا تیم پروژه ادامه پیدا کند یا برای امور مشترک یکپارچه شود.