تولید نرم افزار

تولید نرم افزار

تولید نرم افزار

    • تاریخ انتشار :
    • ساعت : ۱۹:۰۰
    • تعداد نظرها : 0
    • تعداد بازدید : ۶۸۲
  • این مطلب پسندیدم: ۰
  • انتشار این مطلب:
فرایند تولید نرم‌افزار که با عنوان «چرخهٔ حیات تولید نرم‌افزار» نیز شناخته می‌شود، ساختاری است که روی توسعه و تولید محصولات نرم‌افزاری اعمال می‌شود. عبارت‌های مشابهی چون «چرخهٔ حیات نرم‌افزار» و «فرایند نرم‌افزار» در این رابطه استفاده می‌شود. الگوهای گوناگونی نظیر فرایندهای (خاص) وجود دارند که هر کدام خط مشی مختص (آن فرایندها) برای انجام کارها و فعالیت‌های متنوع در طول فرایندها را مشخص می‌کنند. برخی عنوان می‌کنند که «طرح چرخهٔ حیات» یک عبارت بسیار عمومی بوده و «فرایند تولید نرم‌افزار» عبارت تخصصی‌تر است. برای مثال خیلی از فرایندهای تولید نرم‌افزار ویژه‌ای هستند که خود زیر مجموعه چرخهٔ حیات مارپیچ به‌شمار می‌روند.

الگو آبشاری
الگوی آبشاری فرایندها را به گونه‌ای نشان می‌دهد که کجا تولید کنندگان نرم‌افزار (برنامه‌نویسان) فازهای زیر را به ترتیب انجام دهند:
مشخصات مورد نیاز (تحلیل نیازمندی‌ها)
طراحی نرم‌افزار
پیاده‌سازی و یکپارچه سازی
تست نرم‌افزار (یا اعتبارسنجی)
گسترش نرم‌افزار (یا نصب)
نگهداری نرم‌افزار
در این مدل فعالیت‌های تولید نرم‌افزار در قالب فازهای با توالی مشخص و به ترتیب، برنامه‌ریزی و اجرا می‌شوند. اشکال عمده این روش این است که بازبینی و تجدید نظر در فازهای انجام شده امکان‌پذیر نیست لذا خطای تخمین ابعاد پروژه، ریسک اشتباه در فهم درست و تحلیل نیازمندی‌ها و نیز امکان انتخاب نابجای معماری بسیار بالا می‌باشد.در سختگیرانه‌ترین حالت آبشاری، بعد از اینکه هر فاز کاملاً پایان پذیرفت، به مرحله بعدی می‌رویم. بازبینی که اجازه ایجاد تغییرات در سامانه را بدهد (که ممکن است شامل تغییرات فرایندهای کنترل رسمی باشد) فقط قبل از رفتن به مرحله بعد امکان‌پذیر است. همچنین بازبینی ممکن است جهت اطمینان از پایان قطعی این فاز (مرحله) بکار گرفته شود. فازی که معیارهای تکمیل آن کامل شده، معمولاً با عنوان دروازه اطلاق می‌شود که نشان می‌دهد پروژه از فاز فعلی به فاز بعدی منتقل شده‌است. الگو آبشاری از بازبینی و تجدید نظر فازهای قبلی که کامل شده‌اند، جلوگیری می‌کند. این عدم انعطاف‌پذیری مفصل در الگو آبشاری محض، دست مایه انتقاد پشتیبانی کنندگان الگوهای انعطاف‌پذیر است.
الگو ی مارپیچ (Spiral Model)
الگو مارپیچ(باری بوهم، ۱۹۸۸)
خصوصیت کلیدی الگوی مارپیچ مدیریت ریسک در تمام مراحل چرخهٔ تولید نرم‌افزار است. در سال ۱۹۸۸ میلادی بری بوهم به صورت رسمی الگو مارپیچ فرایند تولید نرم‌افزار را منتشر کرد، که ترکیبی از بعضی کلیدهای تأیید شده متدولوژی الگو آبشاری و نمونه‌سازی سریع است، اما احساس می‌شود الگو ارائه شده تأکید در ناحیه‌های کلیدی (الگو آبشاری) را با متدهای دیگری همچون بررسی دقیق و تحلیل دائمی ریسک‌ها، سیستم‌های خاص مناسب برای سامانه پیچیده و بزرگ، کوتاه‌تر کرده‌است.
الگو مارپیچ این روش را با چهار نمودار که نشان دهند فعالیت‌های زیر است، به تصویر می‌کشد که فرایندها در چند مرحله تکرار انجام می‌شود:
تدوین و فرموله کردن برنامه‌ریزی خوب است برای شناسایی اهداف سیستم، قسمت‌های انتخاب شده جهت پیاده‌سازی برنامه، محدودیت‌های واضح و مشخص پروژه.
تحلیل ریسک و مشکلات سامانه: ارزیابی تحلیلی برنامه‌های انتخاب شده، جهت مشخص کردن چگونگی شناسایی و از بین بردن ریسک‌ها.
پیاده‌سازی پروژه: پیاده‌سازی تولید نرم‌افزار و تأیید کارایی سامانه.
الگو مارپیچ مبتنی بر ریسک، بر اختیار انتخاب گزینه‌ها و محدودیت‌ها در سفارش‌ها برای پشتیبانی استفاده مجدد نرم‌افزار و اینکه کیفیت نرم‌افزار می‌تواند در ادغام اهداف ویژه در تولید نرم‌افزار کمک می‌کند، تأکید می‌کند.

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

روش توسعه سریع نرم‌افزار (RAD)


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


روش برنامه‌سازی مفرط


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


الگو اسکرام

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

برچسب ها :

  • این مطلب پسندیدم: ۰
  • انتشار این مطلب:

میزان رضایت مندی از این سفارش : از 3 رای ثبت شده

نظرات ثبت شده