فرایند توسعه نرم‌افزار: تفاوت میان نسخه‌ها
جز ربات: + {{تداخل میان‌ویکی}} |
بدون خلاصۀ ویرایش |
||
| (۳۴ نسخهٔ میانی ویرایش شده توسط ۲۳ کاربر نشان داده نشد) | |||
| خط ۱: | خط ۱: | ||
{{تمیزکاری}} |
|||
{{تمیزکاری}}{{منبع}}{{فرایند توسعه نرم‌افزار}}'''فرایند تولید نرم‌افزار''' که با عنوان «چرخهٔ حیات تولید نرم‌افزار» نیز شناخته میشود، ساختاری است که روی توسعه و تولید محصولات نرم‌افزاری اعمال میشود. عبارت‌های مشابهی چون «چرخهٔ حیات نرم‌افزار» و «فرایند نرم‌افزار» در این رابطه استفاده میشود.الگوهای گوناگونی نظیر فرایندهای (خاص) وجود دارند که هر کدام خط مشی مختص (آن فرایندها) برای انجام کارها و فعالیت‌های متنوع در طول فرایندها را مشخص می‌کنند. برخی عنوان می‌کنند که «طرح چرخهٔ حیات» یک عبارت بسیار عمومی بوده و «فرایند تولید نرم‌افزار» عبارت تخصصی‌تر است. برای مثال خیلی از فرایندهای تولید نرم‌افزار ویژه‌ای هستند که خود زیر مجموعه چرخهٔ حیات حلزونی به شمار می‌روند.[[پرونده:UnifiedProcessProjectProfile20060708.png|بندانگشتی|الگو آر یو پی]][[پرونده:420px-Systems Engineering Process farsi.png|بندانگشتی|الگو وی]]== فعالیت‌های تولید نرم‌افزار ===== برنامه‌ریزی (امکان‌سنجی) ==={{اصلی|برنامه‌ریزی}}از مهمترین کارها در تولید نرم‌افزار استخراج نیازمندی‌ها یا تحلیل نیازمندی‌های آن سامانه است. مشتریان عمومی معمولاً تصور مفهومی، انتزاعی و مبهمی از نتیجه نهایی خواسته‌هایشان دارند و نمی‌دانند به درستی نرم‌افزار مورد نظرشان چه کاری باید انجام دهد. در این مرحله نیازمندی‌های ناتمام، پیچیده و مبهم، و حتی متضاد توسط مهندسان نرم‌افزار ماهر شناسایی می‌شوند. در این برهه تکه نرم‌افزارهای آماده، تجربه‌شده و فعال ممکن است برای پایین آوردن ریسک (و مشکلات) نیازمندی‌ها کمک کنند.نخست نیازمندی‌های عمومی از کاربران جمع‌آوری شده و دامنه توسعه و تولید نرم‌افزار که باید تولید شود شناسایی و تحلیل میشود، سپس مستندات بصورت شفاف نوشته می‌شوند. معمولاً به این مستند، مستند دامنه یا محدوده سامانه اطلاق میشود.برخی قابلیت‌ها ممکن است در ابتدای پروژه به خاطر مسائل مالی یا نیازمندی‌های غیر شفاف و نامشخص خارج از محدوده پروژه باشند. اگر تولید و [[توسعه نرم‌افزار]] [[برون‌سپاری]] شود (یعنی به شرکت‌های خارجی محول شود) این مستندات به عنوان مستندات قانونی و حقوقی در نظر گرفته میشود؛ بنابراین در صورت اتفاق هرگونه دعوای حقوقی یا ابهام در مورد تعهدات داده‌شده به کاربر، این مسائل قابل شفاف‌سازی خواهد بود.=== پیاده‌سازی، آزمون و مستندسازی ===پیاده‌سازی آن قسمت از فرایند تولید نرم‌افزار به شمار می‌رود که مهندسان نرم‌افزار در دنیای واقعی تمام کدهای پروژه را می‌نویسند و به قول معروف [[برنامه‌نویسی]] می‌کنند.آزمون نرم‌افزار بخش لاینفک و مهم از فرایند تولید نرم‌افزار است. این قسمت از فرایندها کمک می‌کند تا مشکلات سامانه بصورت سریع شناسایی شوند.مستندسازی در تمام مراحل پروژه چون [[طراحی داخلی]] نرم‌افزار برای تعیین اهداف سیستم، نگهداری آینده و ارتقاء و بهبود سامانه هرچند پروژه پایان یافته باشد انجام میشود. همچنین ممکن است این مستندسازی شامل نوشتن ساختار تکه‌های برنامه ظاهر برنامه کاربردی داخلی و خارجی هم باشند. این مطلب خیلی مهم است که همه چیز پروژه مستندسازی شود.=== استقرار و نگهداری سامانه ===استقرار و تحویل سامانه پس از اینکه آزمون مناسب را گذراند و برای انتشار، فروش یا هر نوع توزیع برای محیط کار نهایی تأیید شد انجام خواهد شد.آموزش نرم‌افزار و پشتیبانی خیلی مهم است و خیلی از تولیدکنندگان و توسعه‌دهندگان نرم‌افزارها اهمیت آن را درک نمی‌کنند. مهم نیست که چقدر زمان و برنامه‌ریزی توسط تیم تولید و توسعه نرم‌افزار برای ایجاد نرم‌افزار مصرف کرده‌اند اگر در آخر کار کاربری در سازمان نباشد تا از نرم‌افزار استفاده کند. مردم معمولاً در برابر تغییرات مقاومت نشان می‌دهند و از ماجراجویی در محیط ناآشنا اجتناب می‌کنند، برای همین در فاز استقرار این خیلی مهم است کلاس‌های آموزشی برای کاربران جدیدِ نرم‌افزار گذاشته شود.نگهداری و ارتقای نرم‌افزاری برای پوشش، مسائل پوشش داده‌نشده یا نیازمندی‌های تازه‌ای که ممکن است بوجود آیند مدت خیلی زیادی حتی بیشتر از زمان اولیه تولید نرم‌افزار زمان بگیرد. این مرحله ممکن است نیاز باشد تا کدهای برنامه‌نویسی تازه‌ای که در طراحی اصلی برنامه نیز دیده نشده اضافه شود تا مسائل و مشکلات دیده‌نشده حل شوند یا ممکن است کاربر درخواست عملیات اصلی دیگری کند و برنامه‌نویسی‌های تازه‌ای برای برآورده کردن نیازهای جدید انجام گیرد. اگر هزینه کار فاز نگهداری از ۲۵ درصد هزینه فاز قبلی (پیاده‌سازی) بیشتر باشد، این احتمال وجود دارد که کیفیت کلی فاز قبلی خیلی ضعیف بوده باشد. در این صورت مدیران پروژه باید گزینهٔ ایجاد مجدد سامانه (یا بخشی از سامانه) را قبل از اینکه هزینه‌های نگهداری غیر قابل کنترل شود را مطرح کنند.== الگوهای تولید نرم‌افزار ===== الگو آبشاری ===[[پرونده:Waterfall_model.svg|بندانگشتی|الگو آبشاری]]{{اصلی|الگو آبشاری}}الگو آبشاری فرایندها را به گونه‌ای نشان می‌دهد که کجا تولید کنندگان نرم‌افزار (برنامه‌نویسان) فازهای زیر را به ترتیب انجام دهند:# [[مشخصات مورد نیاز نرم‌افزار|مشخصات مورد نیاز]] ([[تحلیل نیازمندی‌ها]])# [[طراحی نرم‌افزار]]# [[یکپارچه‌سازی سامانه|پیاده‌سازی و یکپارچه‌سازی]]# [[تست نرم‌افزار]] (یا اعتبارسنجی)# [[گسترش نرم‌افزار]] (یا نصب)# [[نگهداری نرم‌افزار]]در سختگیرانه‌ترین حالت آبشاری، بعد از اینکه هر فاز کاملاً پایان پذیرفت، به مرحله بعدی می‌رویم. بازبینی که اجازه ایجاد تغییرات در سامانه را بدهد (که ممکن است شامل تغییرات فرایندهای کنترل رسمی باشد) فقط قبل از رفتن به مرحله بعد امکان‌پذیر است. همچنین بازبینی ممکن است جهت اطمینان از پایان قطعی این فاز (مرحله) بکار گرفته شود. فازی که معیارهای تکمیل آن کامل شده، معمولاً با عنوان دروازه اطلاق میشود که نشان می‌دهد پروژه از فاز فعلی به فاز بعدی منتقل شده است. الگو آبشاری از بازبینی و تجدید نظر فازهای قبلی که کامل شده‌اند، جلوگیری می‌کند. این عدم [[انعطاف‌پذیری مفصل]] در الگو آبشاری محض، دست مایه انتقاد، پشتیبانی کنندگان الگوهای انعطاف پذیر است.=== الگو حلزونی ===[[پرونده:Spiral model (Boehm, 1988).svg|بندانگشتی|الگو حلزونی (باری بوهم، ۱۹۸۸)]]خصوصیت کلیدی الگو حلزونی [[مدیریت ریسک]] در تمام مراحل چرخهٔ تولید نرم‌افزار است. در سال ۱۹۸۸ میلادی بری بوهم به صورت رسمی الگو حلزونی فرایند تولید نرم‌افزار را منتشر کرد، که ترکیبی از بعضی کلیدهای تایید شده متدولوژی الگو آبشاری و [[نمونه‌سازی سریع]] است، اما احساس میشود الگو ارائه شده تاکید در ناحیه های کلیدی (الگو آبشاری) را با متدهای دیگری همچون بررسی دقیق و تحلیل دائمی ریسک‌ها، سیستم‌های خاص مناسب برای [[سامانه پیچیده]] و بزرگ، کوتاه تر کرده است.الگو حلزونی این روش را با چهار نمودار که نشان دهند فعالیت های زیر است، به تصویر می کشد که فرایندها در چند مرحله تکرار انجام میشود:# تدوین و فرموله کردن برنامه ریزی خوب است برای شناسایی اهداف سیستم، قسمت های انتخاب شده جهت پیاده سازی برنامه، محدودیت‌های واضح و مشخص پروژه.# تحلیل ریسک و مشکلات سامانه: ارزیابی تحلیلی برنامه های انتخاب شده، جهت مشخص کردن چگونگی شناسایی و از بین بردن ریسک‌ها.# پیاده سازی پروژه: پیاده سازی تولید نرم‌افزار و تایید کارایی سامانه. الگو حلزونی مبتنی بر ریسک، بر اختیارانتخاب گزینه ها و محدودیت‌ها در سفارش‌ها برای پشتیبانی استفاده مجدد نرم‌افزار و اینکه [[کیفیت نرم‌افزار]] می‌تواند در ادغام اهداف ویژه در تولید نرم‌افزار کمک می‌کند، تاکید می‌کند.به هر حال الگو حلزونی شرایط محدود کننده زیر را دارا می باشد: # الگو حلزونی تحلیل ریسک‌ها را تاکید می‌کند و بنابراین کاربران باید این تحلیل را قبول کنند و فکری برایش کنند (این مطالب را در نظر داشته باشند). این مسئله نیازمند اعتماد متقابل و همچنین تمایل به هزینه کردن برای رفع ایرادات، در هنگام تولید نرم‌افزار است و این دلیل استفاده شدن این الگو تولید نرم‌افزار پروژه های بزرگ است.# درصورتیکه در هنگام پیاده‌سازی تحلیل ریسک‌ها تاثیر منفی روی سود پروژه زیاد باشد نبایستی از الگو حلزونی استفاده گردد.# تولید و توسعه دهندگان نرم‌افزار بصورت فعال حواسشان به ریسک‌های قابل حل خواهد بود و به دقت آنها را در الگو حلزونی تحلیل می‌کنند.مرحله اول تدوین و فرموله کردن یک برنامه برای رسیدن به اهداف با این محدودیت‌ها، و پس از آن تلاش برای پیدا کردن و حذف تمام خطرات بالقوه (ریسک‌های بالقوه) از طریق تجزیه و تحلیل دقیق و در صورت لزوم، با ساخت نمونه اولیه است. اگر برخی ریسک‌ها قابل حل نبودند در این صورت مشتریان باید تصمیم بگیرند که آیا می‌خواهند انجام پروژه را خاتمه دهند یا از ریسک‌های مورد نظر چشم پوشی کنند و به هر ترتیب ادامه دهند. در نهایت، نتایج ارزیابی شده و طراحی مرحله بعدی آغاز میشود.در حالت کلی یک الگو تکاملی است که به صورت مجموعه‌ای از نسخه‌های افزایشی توسعه میابد و همچنین در طی تکرارهای اولیه ممکن است یک الگو کاغذی یا یک نمونه اولیه باشد ولی در طول تکرارهای بعدی هر بار نسخه کامل‌تری از سامانه تولید میشود و این الگو به ۳ تا ۶ نواحی کاری تقسیم میشود.=== روش تکرارشونده و افزایشی ===[[پرونده:Development-iterative.gif|بندانگشتی|توسعه تکرارشونده]][[پرونده:Iterative development model.svg|بندانگشتی|یک الگو توسعه تکرارشونده]]روشی تکراری تولید نرم‌افزار اجازه ی ایجاد که پروژه در ابتدا از بخشهای کوچک شروع شود و به مرور زمان سامانه رشد کند تا کمک کند در این درگیری مشکلات مهم پیدا شوند قبل از اینکه فرضیات اشتباه باعث خراب شدن سامانه شوند. الگو تکرار فرایند ها بوسیله تولید کنندگان نرم‌افزارهای تجاری انتخاب و استفاده میشود چون این الگو اجازه می دهد تا نیازهای کاربرانی که در زمان طراحی دقیقاً نمی‌دانند چگونه نیازمندی‌هایشان از سامانه را معرفی کنند بصورت بالقوه برآورده شود.=== روش توسعه سریع نرم‌افزار ===[[پرونده:RADModel.JPG|بندانگشتی|روش توسعه سریع نرم‌افزار (RAD)]]روش توسعه سریع نرم‌افزار {{به انگلیسی|Rapid application development}}{{مخفف انگلیسی|RAD}} روش تکراری را بعنوان پایه کار استفاده می‌کند اما طرفداری نظریه سبک‌تر و محبوبیت بیشتر از روش سنتی است. روش سریع از بازخوردها به جای برنامه‌ریزی بعنوان [[سازوکار]] اصلی کنترل پروژه استفاده می‌کند. بازخوردها بوسیله آزمون‌های مرتب و انتشار پیاپی در بازه‌های زمانی کوتاه نرم‌افزارهای در حال تکامل تولید می‌شوند.روش‌های گوناگونی از فرایند سریع برای تولید نرم‌افزار استفاه میشود:==== روش برنامه‌سازی مفرط ===={{اصلی|برنامه‌سازی مفرط}}[[پرونده:Extreme Programming.svg|بندانگشتی|برنامه‌ریزی و حلقه‌های بازخورد در برنامه‌سازی مفرط.]]تولید نرم‌افزار به روش [[برنامه‌سازی مفرط]] {{به انگلیسی|Extreme programming}}{{مخفف انگلیسی|XP}} در فازهای خیلی کوچک (یا مداوم) انجام و با فرایندهای دسته‌ای قدیمی‌تر تطبیق داده می‌شوند. فاز اول (که عمداً کامل نشده) در طول مراحل ممکن است به جای اینکه ماه‌ها و سال‌ها در روش آبشاری طول بکشد تا کامل شود، یک روز یا یک هفته وقت بگیرد. ابتدا یک آزمون خودکار برای ایجاد اهداف اساسی تولید نرم‌افزار نوشته میشود. سپس (توسط دو برنامه‌نویس) برنامه‌نویسی انجام می‌گیرد که وقتی تمام آزمون‌ها را پشت سر گذاشته و دیگر هیچ آزمون مورد نیازی به ذهن برنامه‌نویسان نرسد کامل میشود. کار طراحی و [[معماری سیستم]] بعد از اینکه نه آزمونی وجود دارد و نه برنامه‌نویسی‌شده انجام میشود.طراحی توسط برنامه‌نویسان انجام میشود. (فقط مشخصات نهایی و ترکیب طراحی و کد در تمام فرایندها در روش سریع مشترک هستند) عملیات اصلی ناقص سامانه (توسط دست کم یکی از افراد گروه تولیدکننده و برنامه‌نویس) برای کاربران (یا برخی از کاربران) نصب یا نمایش داده می‌شوند. در اینجا تمام عوامل پروژه دوباره شروع به نوشتن آزمون برای قسمت‌های مهم سامانه خواهند کرد.==== الگو اسکرام ===={{اصلی|اسکرام (توسعه نرم‌افزار)}}[[پرونده:Scrum_process.svg|بندانگشتی|فرایند اسکرام]]اسکرام یک روش چابکِ تکرارشونده و افزایشی برای [[مدیریت پروژه]] است که معمولاً در الگوی تولید نرم‌افزار چابک به عنوان نوعی متدولوژی توسعه نرم‌افزار دیده میشود. با اینکه روش اسکرام در واقع برای مدیریت محصولات تولید و توسعه پروژه‌ها پیشنهاد شده بود، اما استفاده آن در مدیریت پروژه‌های تولید نرم‌افزار متمرکز شد؛ همچنین امکان دارد جهت [[مدیریت تیم]] نگهداری نرم‌افزار، مدیریت پروژه‌ها یا برنامه‌های عمومی مدیریت خط مشی‌ها استفاده شود.== الگوهای بهبودسازی ===== الگوی تکامل قابلیت یکپارچه سازی (CMMI) ===الگوی تکامل قابلیت یکپارچه‌سازی (CMMI) یکی از الگوهای پیشنهادی و تکنیک‌های پیشتاز است. ارزیابی سازمان‌های مستقل و رتبه‌بندی در مورد کیفیت چگونگی تعریف فرایندهای آن سازمان‌ها را دنبال می‌کند، نه بر کیفیت خود فرایندها یا نرم‌افزار تهیه شده است. الگوی CMMI جایگزین الگوی CMM شده است.=== ایزو ۹۰۰۰ ===[[ایزو ۹۰۰۰]] یک استاندارد رسمی سازماندهی فراینده ساخت محصولات و روشی برای مدیریت و نظارت پیشرفت کارهاست. در اصل این استاندارد برای بخش تولید وساخت(صنعتی) ایجاد شد.ایزو ۹۰۰۰ همچنین برای فرایند تولید نرم‌افزار نیز به خوبی استفاده شده.مانند الگو CMMI مدرک ایزو ۹۰۰۰ هیچ تضمینی راجع به کیفیت نتایج نهایی ندارد و فقط فرایندهای کاری را فرموله و قالب استاندارد رسمی می دهد.=== ایزو ۱۵۵۰۴ ===ایزو ۱۵۵۰۴ که با عنوان فرایند تشخیص و تعیین بهبود قابلیت نرم‌افزار {{به انگلیسی|Software Process Improvement and Capability Determination}}{{مخفف انگلیسی|SPICE}} نیز شناخته میشود، چارچوبی برای ارزیابی فرایندهای نرم‌افزار است. این استاندارد تنظیمات قالب روشنی برای مقایسه فرایندها به شمار می‌رود. SPICE خیلی شبیه CMMI استفاده میشود. فرایندهای این الگو برای مدیریت، کنترل، راهنمایی و نظارت تولید نرم‌افزار است. این الگو جهت سنجش سازماندهی تولید و توسعه یا تیم پروژه بصورت واقعی در طول مدت تولید نرم‌افزار استفاده میشود. تجزیه و تحلیل این اطلاعات برای شناسایی نقاط ضعف و حرکت به سمت بهبود پروژه استفاه میشود. همچنین برای تشخیص نقاط قوت پروژه که می تواند برای سازمان یا تیم پروژه ادامه پیدا کند یا برای امور مشترک یکپارچه شود.== جستارهای وابسته =={{چندستون}}=== روش‌های توسعه ===* [[برنامه‌سازی مفرط]]* [[آیکونیکس]]* [[مدل وی]]* [[اعتبار و درستی‌سنجی]]=== مباحث مرتبط ===* [[فهرست فلسفه‌های توسعه نرم‌افزار]]* [[فرایند (رایانه)]]* [[پارادایم برنامه‌نویسی]]* [[پروژه]]{{چندستون-پایان}}== پانویس =={{انبار-رده}}{{پانویس}}{{مهندسی نرم‌افزار}}[[رده:فرایند تولید نرم‌افزار]][[رده:رایانه]][[رده:روش‌شناسی]][[رده:روش‌های صوری]][[رده:مهندسی نرم‌افزار]][[رده:نرم‌افزار]][[cs:Proces vývoje softwaru]][[da:Softwareudviklingsproces]][[de:Vorgehensmodell zur Softwareentwicklung]][[es:Proceso para el desarrollo de software]][[gl:Ciclo de desenvolvemento]][[hi:सॉफ्टवेयर डेवलपमेंट प्रक्रिया डेवेलपमेंट]][[id:Proses pengembangan perangkat lunak]][[jv:Prosès pangembangan piranti alus komputer]][[lt:Programų kūrimo gyvavimo ciklo modelis]][[nl:Softwareontwikkelmethode]][[no:Programvareutviklingsprosess]][[pl:Proces wytwórczy oprogramowania]][[sq:Procesi i zhvillimit të softuerit]][[sv:Programutvecklingsmetodik]][[tr:Yazılım geliştirme süreci]] |
|||
{{فرایند توسعه نرم‌افزار|فعالیت‌های اصلی}} |
|||
{{تداخل میان‌ویکی}} |
|||
'''فرایند تولید نرم‌افزار''' که با عنوان «چرخهٔ حیات تولید نرم‌افزار» نیز شناخته میشود، ساختاری است که روی توسعه و تولید محصولات نرم‌افزاری اعمال میشود. عبارت‌های مشابهی چون «چرخهٔ حیات نرم‌افزار» و «فرایند نرم‌افزار» در این رابطه استفاده میشود. الگوهای گوناگونی نظیر فرایندهای خاص وجود دارند که هر کدام خط مشی مختص (آن فرایندها) برای انجام کارها و فعالیت‌های متنوع در طول فرایندها را مشخص می‌کنند. برخی عنوان می‌کنند که «طرح چرخهٔ حیات» یک عبارت بسیار عمومی بوده و «فرایند تولید نرم‌افزار» عبارت تخصصی‌تر است. برای مثال خیلی از فرایندهای تولید نرم‌افزار ویژه‌ای هستند که خود زیر مجموعه چرخهٔ حیات مارپیچ به‌شمار می‌روند.<ref name="CMS08">{{cite web|website=Centers for Medicare & Medicaid Services (CMS) Office of Information Service|url=http://www.cms.gov/Research-Statistics-Data-and-Systems/CMS-Information-Technology/XLC/Downloads/SelectingDevelopmentApproach.pdf|title=Selecting a development approach|publisher=United States Department of Health and Human Services (HHS)|orig-date=Original Issuance: February 17, 2005|date=March 27, 2008|access-date=October 27, 2008|archive-url=https://web.archive.org/web/20120620212919/http://www.cms.gov/Research-Statistics-Data-and-Systems/CMS-Information-Technology/XLC/Downloads/SelectingDevelopmentApproach.pdf|archive-date=June 20, 2012|url-status=dead}}</ref><ref name="Ell04">{{cite book|author=Geoffrey Elliott|date=2004|title=Global Business Information Technology: an integrated systems approach|publisher=Pearson Education|page=87}}</ref> |
|||
[[پرونده:UnifiedProcessProjectProfile20060708.png|بندانگشتی|الگو آر یو پی]] |
|||
[[پرونده:420px-Systems Engineering Process farsi.png|بندانگشتی|الگو وی]] |
|||
== فعالیت‌های تولید نرم‌افزار == |
|||
=== برنامه‌ریزی (امکان‌سنجی) === |
|||
{{اصلی|برنامه‌ریزی}} |
|||
از مهمترین کارها در تولید نرم‌افزار استخراج نیازمندی‌ها یا تحلیل نیازمندی‌های آن سامانه است. مشتریان عمومی معمولاً تصور مفهومی، انتزاعی و مبهمی از نتیجه نهایی خواسته‌هایشان دارند و نمی‌دانند به درستی نرم‌افزار مورد نظرشان چه کاری باید انجام دهد. در این مرحله نیازمندی‌های ناتمام، پیچیده و مبهم، و حتی متضاد توسط مهندسان نرم‌افزار ماهر شناسایی می‌شوند. در این برهه تکه نرم‌افزارهای آماده، تجربه‌شده و فعال ممکن است برای پایین آوردن ریسک (و مشکلات) نیازمندی‌ها کمک کنند. نخست نیازمندی‌های عمومی از کاربران جمع‌آوری شده و دامنه توسعه و تولید نرم‌افزار که باید تولید شود شناسایی و تحلیل میشود، سپس مستندات به صورت شفاف نوشته می‌شوند. معمولاً به این مستند، مستند دامنه یا محدوده سامانه گفته میشود. |
|||
برخی قابلیت‌ها ممکن است در ابتدای پروژه به خاطر مسائل مالی یا نیازمندی‌های غیر شفاف و نامشخص خارج از محدوده پروژه باشند. اگر تولید و [[توسعه نرم‌افزار]] [[برون‌سپاری]] شود (یعنی به شرکت‌های خارجی محول شود) این مستندات به عنوان مستندات قانونی و حقوقی در نظر گرفته میشود؛ بنابراین در صورت اتفاق هرگونه دعوای حقوقی یا ابهام در مورد تعهدات داده‌شده به کاربر، این مسائل قابل شفاف‌سازی خواهد بود. |
|||
=== پیاده‌سازی، آزمون و مستندسازی === |
|||
پیاده‌سازی آن قسمت از فرایند تولید نرم‌افزار به‌شمار می‌رود که مهندسان نرم‌افزار در دنیای واقعی تمام کدهای پروژه را می‌نویسند و به قول معروف [[برنامه‌نویسی]] می‌کنند. |
|||
آزمون نرم‌افزار بخش لاینفک و مهم از فرایند تولید نرم‌افزار است. این قسمت از فرایندها کمک می‌کند تا مشکلات سامانه به صورت سریع شناسایی شوند. |
|||
مستندسازی در تمام مراحل پروژه چون [[طراحی داخلی]] نرم‌افزار برای تعیین اهداف سیستم، نگهداری آینده و ارتقاء و بهبود سامانه هرچند پروژه پایان یافته باشد انجام میشود. همچنین ممکن است این مستندسازی شامل نوشتن ساختار تکه‌های برنامه ظاهر برنامه کاربردی داخلی و خارجی هم باشند. این مطلب خیلی مهم است که همه چیز پروژه مستندسازی شود. |
|||
=== استقرار و نگهداری سامانه === |
|||
استقرار و تحویل سامانه پس از اینکه آزمون مناسب را گذراند و برای انتشار، فروش یا هر نوع توزیع برای محیط کار نهایی تأیید شد انجام خواهد شد. |
|||
آموزش نرم‌افزار و پشتیبانی خیلی مهم است و خیلی از تولیدکنندگان و توسعه‌دهندگان نرم‌افزارها اهمیت آن را درک نمی‌کنند. مهم نیست که چقدر زمان و برنامه‌ریزی توسط تیم تولید و توسعه نرم‌افزار برای ایجاد نرم‌افزار مصرف کرده‌اند اگر در آخر کار کاربری در سازمان نباشد تا از نرم‌افزار استفاده کند. مردم معمولاً در برابر تغییرات مقاومت نشان می‌دهند و از ماجراجویی در محیط ناآشنا اجتناب می‌کنند، برای همین در فاز استقرار این خیلی مهم است کلاس‌های آموزشی برای کاربران جدیدِ نرم‌افزار گذاشته شود. |
|||
نگهداری و ارتقای نرم‌افزاری برای پوشش، مسائل پوشش داده‌نشده یا نیازمندی‌های تازه‌ای که ممکن است به وجود آیند مدت خیلی زیادی حتی بیشتر از زمان اولیه تولید نرم‌افزار زمان بگیرد. این مرحله ممکن است نیاز باشد تا کدهای برنامه‌نویسی تازه‌ای که در طراحی اصلی برنامه نیز دیده نشده اضافه شود تا مسائل و مشکلات دیده‌نشده حل شوند یا ممکن است کاربر درخواست عملیات اصلی دیگری کند و برنامه‌نویسی‌های تازه‌ای برای برآورده کردن نیازهای جدید انجام گیرد. اگر هزینه کار فاز نگهداری از ۲۵ درصد هزینه فاز قبلی (پیاده‌سازی) بیشتر باشد، این احتمال وجود دارد که کیفیت کلی فاز قبلی خیلی ضعیف بوده باشد. در این صورت مدیران پروژه باید گزینهٔ ایجاد مجدد سامانه (یا بخشی از سامانه) را قبل از اینکه هزینه‌های نگهداری غیرقابل کنترل شود را مطرح کنند. |
|||
== الگوهای تولید نرم‌افزار == |
|||
=== الگو آبشاری === |
|||
[[پرونده:Waterfall_model.svg|بندانگشتی|الگو آبشاری]] |
|||
{{اصلی|الگو آبشاری}} |
|||
الگوی آبشاری فرایندها را به گونه‌ای نشان می‌دهد که کجا تولیدکنندگان نرم‌افزار (برنامه‌نویسان) فازهای زیر را به ترتیب انجام دهند: |
|||
# [[مشخصات مورد نیاز نرم‌افزار|مشخصات مورد نیاز]] ([[تحلیل نیازمندی‌ها]]) |
|||
# [[طراحی نرم‌افزار]] |
|||
# [[یکپارچه‌سازی سامانه|پیاده‌سازی و یکپارچه سازی]] |
|||
# [[تست نرم‌افزار]] (یا اعتبارسنجی) |
|||
# [[گسترش نرم‌افزار]] (یا نصب) |
|||
# [[نگهداری نرم‌افزار]] |
|||
در این مدل فعالیت‌های تولید نرم‌افزار در قالب فازهای با توالی مشخص و به ترتیب، برنامه‌ریزی و اجرا می‌شوند. اشکال عمده این روش این است که بازبینی و تجدید نظر در فازهای انجام شده امکان‌پذیر نیست لذا خطای تخمین ابعاد پروژه، ریسک اشتباه در فهم درست و تحلیل نیازمندی‌ها و نیز امکان انتخاب نابجای معماری بسیار بالا می‌باشد. در سختگیرانه‌ترین حالت آبشاری، بعد از اینکه هر فاز کاملاً پایان پذیرفت، به مرحله بعدی می‌رویم. بازبینی که اجازه ایجاد تغییرات در سامانه را بدهد (که ممکن است شامل تغییرات فرایندهای کنترل رسمی باشد) فقط قبل از رفتن به مرحله بعد امکان‌پذیر است. همچنین بازبینی ممکن است جهت اطمینان از پایان قطعی این فاز (مرحله) بکار گرفته شود. فازی که معیارهای تکمیل آن کامل شده، معمولاً با عنوان دروازه گفته میشود که نشان می‌دهد پروژه از فاز فعلی به فاز بعدی منتقل شده‌است. الگو آبشاری از بازبینی و تجدید نظر فازهای قبلی که کامل شده‌اند، جلوگیری می‌کند. این عدم [[انعطاف‌پذیری مفصل]] در الگو آبشاری محض، دستمایه انتقاد پشتیبانی کنندگان الگوهای انعطاف‌پذیر است. |
|||
=== الگو ی مارپیچ (Spiral Model) === |
|||
[[پرونده:Spiral model (Boehm, 1988).svg|بندانگشتی|الگو مارپیچ (باری بوهم، ۱۹۸۸)]] |
|||
خصوصیت کلیدی الگوی مارپیچ [[مدیریت ریسک]] در تمام مراحل چرخهٔ تولید نرم‌افزار است. در سال ۱۹۸۸ میلادی بری بوهم به صورت رسمی الگو مارپیچ فرایند تولید نرم‌افزار را منتشر کرد، که ترکیبی از بعضی کلیدهای تأیید شده متدولوژی الگو آبشاری و [[نمونه‌سازی سریع]] است، اما احساس میشود الگو ارائه شده تأکید در ناحیه‌های کلیدی (الگو آبشاری) را با متدهای دیگری همچون بررسی دقیق و تحلیل دائمی ریسک‌ها، سیستم‌های خاص مناسب برای [[سامانه پیچیده]] و بزرگ، کوتاه‌تر کرده‌است. |
|||
الگو مارپیچ این روش را با چهار نمودار که نشان دهند فعالیت‌های زیر است، به تصویر می‌کشد که فرایندها در چند مرحله تکرار انجام میشود: |
|||
# تدوین و فرموله کردن برنامه‌ریزی خوب است برای شناسایی اهداف سیستم، قسمت‌های انتخاب شده جهت پیاده‌سازی برنامه، محدودیت‌های واضح و مشخص پروژه. |
|||
# تحلیل ریسک و مشکلات سامانه: ارزیابی تحلیلی برنامه‌های انتخاب شده، جهت مشخص کردن چگونگی شناسایی و از بین بردن ریسک‌ها. |
|||
# پیاده‌سازی پروژه: پیاده‌سازی تولید نرم‌افزار و تأیید کارایی سامانه. |
|||
الگو مارپیچ مبتنی بر ریسک، بر اختیار انتخاب گزینه‌ها و محدودیت‌ها در سفارش‌ها برای پشتیبانی استفاده مجدد نرم‌افزار و اینکه [[کیفیت نرم‌افزار]] می‌تواند در ادغام اهداف ویژه در تولید نرم‌افزار کمک می‌کند، تأکید می‌کند. |
|||
به هر حال الگوی مارپیچ شرایط محدودکننده زیر را دارا می‌باشد: |
|||
# الگو مارپیچ تحلیل ریسک‌ها را تأکید می‌کند و بنابراین کاربران باید این تحلیل را قبول کنند و فکری برایش کنند (این مطالب را در نظر داشته باشند). این مسئله نیازمند اعتماد متقابل و همچنین تمایل به هزینه کردن برای رفع ایرادات، در هنگام تولید نرم‌افزار است و این دلیل استفاده شدن این الگو تولید نرم‌افزار پروژه‌های بزرگ است. |
|||
# درصورتیکه در هنگام پیاده‌سازی تحلیل ریسک‌ها تأثیر منفی روی سود پروژه زیاد باشد نبایستی از الگو مارپیچ استفاده گردد. |
|||
# تولید و توسعه دهندگان نرم‌افزار به صورت فعال حواسشان به ریسک‌های قابل حل خواهد بود و به دقت آنها را در الگو مارپیچ تحلیل می‌کنند. |
|||
مرحله اول تدوین و فرموله کردن یک برنامه برای رسیدن به اهداف با این محدودیت‌ها، و پس از آن تلاش برای پیدا کردن و حذف تمام خطرات بالقوه (ریسک‌های بالقوه) از طریق تجزیه و تحلیل دقیق و در صورت لزوم، با ساخت نمونه اولیه است. اگر برخی ریسک‌ها قابل حل نبودند در این صورت مشتریان باید تصمیم بگیرند که آیا می‌خواهند انجام پروژه را خاتمه دهند یا از ریسک‌های مورد نظر چشم پوشی کنند و به هر ترتیب ادامه دهند. در نهایت، نتایج ارزیابی شده و طراحی مرحله بعدی آغاز میشود. |
|||
در حالت کلی یک الگو تکاملی است که به صورت مجموعه‌ای از نسخه‌های افزایشی توسعه می‌یابد و همچنین در طی تکرارهای اولیه ممکن است یک الگو کاغذی یا یک نمونه اولیه باشد ولی در طول تکرارهای بعدی هر بار نسخه کامل‌تری از سامانه تولید میشود و این الگو به ۳ تا ۶ نواحی کاری تقسیم میشود. |
|||
=== روش تکرارشونده و افزایشی === |
|||
[[پرونده:Development-iterative.png|بندانگشتی|توسعه تکرارشونده]] |
|||
[[پرونده:Iterative development model.svg|بندانگشتی|یک الگوی توسعه تکرارشونده]] |
|||
روشی تکراری تولید نرم‌افزار اجازهٔ ایجاد که پروژه در ابتدا از بخشهای کوچک شروع شود و به مرور زمان سامانه رشد کند تا کمک کند در این درگیری مشکلات مهم پیدا شوند قبل از اینکه فرضیات اشتباه باعث خراب شدن سامانه شوند. الگو تکرار فرایندها به وسیلهٔ تولیدکنندگان نرم‌افزارهای تجاری انتخاب و استفاده میشود چون این الگو اجازه می‌دهد تا نیازهای کاربرانی که در زمان طراحی دقیقاً نمی‌دانند چگونه نیازمندی‌هایشان از سامانه را معرفی کنند به صورت بالقوه برآورده شود. |
|||
=== روش توسعه سریع نرم‌افزار === |
|||
[[پرونده:RADModel.JPG|بندانگشتی|روش توسعه سریع نرم‌افزار (RAD)]] |
|||
روش توسعه سریع نرم‌افزار {{به انگلیسی|Rapid application development}}{{مخفف انگلیسی|RAD}} روش تکراری را به عنوان پایه کار استفاده می‌کند اما طرفداری نظریه سبک‌تر و محبوبیت بیشتر از روش سنتی است. روش سریع از بازخوردها به جای برنامه‌ریزی به عنوان [[سازوکار]] اصلی کنترل پروژه استفاده می‌کند. بازخوردها به وسیلهٔ آزمون‌های مرتب و انتشار پیاپی در بازه‌های زمانی کوتاه نرم‌افزارهای در حال تکامل تولید می‌شوند. |
|||
روش‌های گوناگونی از فرایند سریع برای تولید نرم‌افزار استفاده میشود: |
|||
==== روش برنامه‌سازی مفرط ==== |
|||
{{اصلی|برنامه‌سازی مفرط}} |
|||
[[پرونده:Extreme Programming.svg|بندانگشتی|برنامه‌ریزی و حلقه‌های بازخورد در برنامه‌سازی مفرط.]] |
|||
تولید نرم‌افزار به روش [[برنامه‌سازی مفرط]] {{به انگلیسی|Extreme programming}}{{مخفف انگلیسی|XP}} در فازهای خیلی کوچک (یا مداوم) انجام و با فرایندهای دسته‌ای قدیمی‌تر تطبیق داده می‌شوند. فاز اول (که عمداً کامل نشده) در طول مراحل ممکن است به جای اینکه ماه‌ها و سال‌ها در روش آبشاری طول بکشد تا کامل شود، یک روز یا یک هفته وقت بگیرد. ابتدا یک آزمون خودکار برای ایجاد اهداف اساسی تولید نرم‌افزار نوشته میشود. سپس (توسط دو برنامه‌نویس) برنامه‌نویسی انجام می‌گیرد که وقتی تمام آزمون‌ها را پشت سر گذاشته و دیگر هیچ آزمون مورد نیازی به ذهن برنامه‌نویسان نرسد کامل میشود. کار طراحی و [[معماری سیستم]] بعد از اینکه نه آزمونی وجود دارد و نه برنامه‌نویسی‌شده انجام میشود. |
|||
طراحی توسط برنامه‌نویسان انجام میشود. (فقط مشخصات نهایی و ترکیب طراحی و کد در تمام فرایندها در روش سریع مشترک هستند) عملیات اصلی ناقص سامانه (توسط دست کم یکی از افراد گروه تولیدکننده و برنامه‌نویس) برای کاربران (یا برخی از کاربران) نصب یا نمایش داده می‌شوند. در اینجا تمام عوامل پروژه دوباره شروع به نوشتن آزمون برای قسمت‌های مهم سامانه خواهند کرد. |
|||
==== الگو اسکرام ==== |
|||
{{اصلی|اسکرام (توسعه نرم‌افزار)}} |
|||
[[پرونده:Scrum_process.svg|بندانگشتی|فرایند اسکرام]] |
|||
اسکرام یک روش چابکِ تکرارشونده و افزایشی برای [[مدیریت پروژه]] است که معمولاً در الگوی تولید نرم‌افزار چابک به عنوان نوعی متدولوژی توسعه نرم‌افزار دیده میشود. |
|||
با اینکه روش اسکرام در واقع برای مدیریت محصولات تولید و توسعه پروژه‌ها پیشنهاد شده بود، اما استفاده آن در مدیریت پروژه‌های تولید نرم‌افزار متمرکز شد؛ همچنین امکان دارد جهت [[مدیریت تیم]] نگهداری نرم‌افزار، مدیریت پروژه‌ها یا برنامه‌های عمومی مدیریت خط مشی‌ها استفاده شود. |
|||
== الگوهای بهبودسازی == |
|||
=== الگوی تکامل قابلیت یکپارچه‌سازی (CMMI) === |
|||
الگوی تکامل قابلیت یکپارچه‌سازی (CMMI) یکی از الگوهای پیشنهادی و تکنیک‌های پیشتاز است. ارزیابی سازمان‌های مستقل و رتبه‌بندی در مورد کیفیت چگونگی تعریف فرایندهای آن سازمان‌ها را دنبال می‌کند، نه بر کیفیت خود فرایندها یا نرم‌افزار تهیه شده‌است. الگوی CMMI جایگزین الگوی CMM شده‌است. |
|||
=== ایزو ۹۰۰۰ === |
|||
[[ایزو ۹۰۰۰]] یک استاندارد رسمی سازماندهی فرایند ساخت محصولات و روشی برای مدیریت و نظارت پیشرفت کارهاست. در اصل این استاندارد برای بخش تولید و ساخت (صنعتی) ایجاد شد. ایزو ۹۰۰۰ همچنین برای فرایند تولید نرم‌افزار نیز به خوبی استفاده شده. مانند الگوی CMMI مدرک ایزو ۹۰۰۰ هیچ تضمینی راجع به کیفیت نتایج نهایی ندارد و فقط فرایندهای کاری را فرموله و قالب استاندارد رسمی می‌دهد. |
|||
=== ایزو ۱۵۵۰۴ === |
|||
ایزو ۱۵۵۰۴ که با عنوان فرایند تشخیص و تعیین بهبود قابلیت نرم‌افزار {{به انگلیسی|Software Process Improvement and Capability Determination}}{{مخفف انگلیسی|SPICE}} نیز شناخته میشود، چارچوبی برای ارزیابی فرایندهای نرم‌افزار است. این استاندارد تنظیمات قالب روشنی برای مقایسه فرایندها به‌شمار می‌رود. SPICE خیلی شبیه CMMI استفاده میشود. فرایندهای این الگو برای مدیریت، کنترل، راهنمایی و نظارت تولید نرم‌افزار است. این الگو جهت سنجش سازماندهی تولید و توسعه یا تیم پروژه به صورت واقعی در طول مدت تولید نرم‌افزار استفاده میشود. تجزیه و تحلیل این اطلاعات برای شناسایی نقاط ضعف و حرکت به سمت بهبود پروژه استفاده میشود. همچنین برای تشخیص نقاط قوت پروژه که می‌تواند برای سازمان یا تیم پروژه ادامه پیدا کند یا برای امور مشترک یکپارچه شود. |
|||
== جستارهای وابسته == |
|||
* [[برنامه‌سازی مفرط]] |
|||
* [[آیکونیکس]] |
|||
* [[مدل وی]] |
|||
* [[اعتبار و درستی‌سنجی]] |
|||
* [[فهرست فلسفه‌های توسعه نرم‌افزار]] |
|||
* [[فرایند (رایانه)]] |
|||
* [[پارادایم برنامه‌نویسی]] |
|||
* [[پروژه]] |
|||
== پانویس == |
|||
{{انبار-رده}} |
|||
{{پانویس}} |
|||
{{مهندسی نرم‌افزار}} |
|||
{{علوم رایانه}} |
|||
{{ادسخر دیکسترا}} |
|||
[[رده:روش‌شناسی]] |
|||
[[رده:روش‌های صوری]] |
|||
[[رده:فرایند تولید نرم‌افزار]] |
|||
[[رده:مهندسی نرم‌افزار]] |
|||
نسخهٔ کنونی تا ۳ اکتبر ۲۰۲۴، ساعت ۰۹:۳۸
 | این مقاله نیازمند تمیزکاری است. لطفاً تا جای امکان آنرا از نظر املا، انشا، چیدمان و درستی بهتر کنید، سپس این برچسب را بردارید. محتویات این مقاله ممکن است غیر قابل اعتماد و نادرست یا جانبدارانه باشد یا قوانین حقوق پدیدآورندگان را نقض کرده باشد. |
| توسعه نرم‌افزار |
|---|
فرایند تولید نرم‌افزار که با عنوان «چرخهٔ حیات تولید نرم‌افزار» نیز شناخته میشود، ساختاری است که روی توسعه و تولید محصولات نرم‌افزاری اعمال میشود. عبارت‌های مشابهی چون «چرخهٔ حیات نرم‌افزار» و «فرایند نرم‌افزار» در این رابطه استفاده میشود. الگوهای گوناگونی نظیر فرایندهای خاص وجود دارند که هر کدام خط مشی مختص (آن فرایندها) برای انجام کارها و فعالیت‌های متنوع در طول فرایندها را مشخص می‌کنند. برخی عنوان می‌کنند که «طرح چرخهٔ حیات» یک عبارت بسیار عمومی بوده و «فرایند تولید نرم‌افزار» عبارت تخصصی‌تر است. برای مثال خیلی از فرایندهای تولید نرم‌افزار ویژه‌ای هستند که خود زیر مجموعه چرخهٔ حیات مارپیچ به‌شمار می‌روند.[۱][۲]
فعالیت‌های تولید نرم‌افزار
[ویرایش]برنامه‌ریزی (امکان‌سنجی)
[ویرایش]از مهمترین کارها در تولید نرم‌افزار استخراج نیازمندی‌ها یا تحلیل نیازمندی‌های آن سامانه است. مشتریان عمومی معمولاً تصور مفهومی، انتزاعی و مبهمی از نتیجه نهایی خواسته‌هایشان دارند و نمی‌دانند به درستی نرم‌افزار مورد نظرشان چه کاری باید انجام دهد. در این مرحله نیازمندی‌های ناتمام، پیچیده و مبهم، و حتی متضاد توسط مهندسان نرم‌افزار ماهر شناسایی می‌شوند. در این برهه تکه نرم‌افزارهای آماده، تجربه‌شده و فعال ممکن است برای پایین آوردن ریسک (و مشکلات) نیازمندی‌ها کمک کنند. نخست نیازمندی‌های عمومی از کاربران جمع‌آوری شده و دامنه توسعه و تولید نرم‌افزار که باید تولید شود شناسایی و تحلیل میشود، سپس مستندات به صورت شفاف نوشته می‌شوند. معمولاً به این مستند، مستند دامنه یا محدوده سامانه گفته میشود.
برخی قابلیت‌ها ممکن است در ابتدای پروژه به خاطر مسائل مالی یا نیازمندی‌های غیر شفاف و نامشخص خارج از محدوده پروژه باشند. اگر تولید و توسعه نرم‌افزار برون‌سپاری شود (یعنی به شرکت‌های خارجی محول شود) این مستندات به عنوان مستندات قانونی و حقوقی در نظر گرفته میشود؛ بنابراین در صورت اتفاق هرگونه دعوای حقوقی یا ابهام در مورد تعهدات داده‌شده به کاربر، این مسائل قابل شفاف‌سازی خواهد بود.
پیاده‌سازی، آزمون و مستندسازی
[ویرایش]پیاده‌سازی آن قسمت از فرایند تولید نرم‌افزار به‌شمار می‌رود که مهندسان نرم‌افزار در دنیای واقعی تمام کدهای پروژه را می‌نویسند و به قول معروف برنامه‌نویسی می‌کنند.
آزمون نرم‌افزار بخش لاینفک و مهم از فرایند تولید نرم‌افزار است. این قسمت از فرایندها کمک می‌کند تا مشکلات سامانه به صورت سریع شناسایی شوند.
مستندسازی در تمام مراحل پروژه چون طراحی داخلی نرم‌افزار برای تعیین اهداف سیستم، نگهداری آینده و ارتقاء و بهبود سامانه هرچند پروژه پایان یافته باشد انجام میشود. همچنین ممکن است این مستندسازی شامل نوشتن ساختار تکه‌های برنامه ظاهر برنامه کاربردی داخلی و خارجی هم باشند. این مطلب خیلی مهم است که همه چیز پروژه مستندسازی شود.
استقرار و نگهداری سامانه
[ویرایش]استقرار و تحویل سامانه پس از اینکه آزمون مناسب را گذراند و برای انتشار، فروش یا هر نوع توزیع برای محیط کار نهایی تأیید شد انجام خواهد شد.
آموزش نرم‌افزار و پشتیبانی خیلی مهم است و خیلی از تولیدکنندگان و توسعه‌دهندگان نرم‌افزارها اهمیت آن را درک نمی‌کنند. مهم نیست که چقدر زمان و برنامه‌ریزی توسط تیم تولید و توسعه نرم‌افزار برای ایجاد نرم‌افزار مصرف کرده‌اند اگر در آخر کار کاربری در سازمان نباشد تا از نرم‌افزار استفاده کند. مردم معمولاً در برابر تغییرات مقاومت نشان می‌دهند و از ماجراجویی در محیط ناآشنا اجتناب می‌کنند، برای همین در فاز استقرار این خیلی مهم است کلاس‌های آموزشی برای کاربران جدیدِ نرم‌افزار گذاشته شود.
نگهداری و ارتقای نرم‌افزاری برای پوشش، مسائل پوشش داده‌نشده یا نیازمندی‌های تازه‌ای که ممکن است به وجود آیند مدت خیلی زیادی حتی بیشتر از زمان اولیه تولید نرم‌افزار زمان بگیرد. این مرحله ممکن است نیاز باشد تا کدهای برنامه‌نویسی تازه‌ای که در طراحی اصلی برنامه نیز دیده نشده اضافه شود تا مسائل و مشکلات دیده‌نشده حل شوند یا ممکن است کاربر درخواست عملیات اصلی دیگری کند و برنامه‌نویسی‌های تازه‌ای برای برآورده کردن نیازهای جدید انجام گیرد. اگر هزینه کار فاز نگهداری از ۲۵ درصد هزینه فاز قبلی (پیاده‌سازی) بیشتر باشد، این احتمال وجود دارد که کیفیت کلی فاز قبلی خیلی ضعیف بوده باشد. در این صورت مدیران پروژه باید گزینهٔ ایجاد مجدد سامانه (یا بخشی از سامانه) را قبل از اینکه هزینه‌های نگهداری غیرقابل کنترل شود را مطرح کنند.
الگوهای تولید نرم‌افزار
[ویرایش]الگو آبشاری
[ویرایش]
الگوی آبشاری فرایندها را به گونه‌ای نشان می‌دهد که کجا تولیدکنندگان نرم‌افزار (برنامه‌نویسان) فازهای زیر را به ترتیب انجام دهند:
- مشخصات مورد نیاز (تحلیل نیازمندی‌ها)
- طراحی نرم‌افزار
- پیاده‌سازی و یکپارچه سازی
- تست نرم‌افزار (یا اعتبارسنجی)
- گسترش نرم‌افزار (یا نصب)
- نگهداری نرم‌افزار
در این مدل فعالیت‌های تولید نرم‌افزار در قالب فازهای با توالی مشخص و به ترتیب، برنامه‌ریزی و اجرا می‌شوند. اشکال عمده این روش این است که بازبینی و تجدید نظر در فازهای انجام شده امکان‌پذیر نیست لذا خطای تخمین ابعاد پروژه، ریسک اشتباه در فهم درست و تحلیل نیازمندی‌ها و نیز امکان انتخاب نابجای معماری بسیار بالا می‌باشد. در سختگیرانه‌ترین حالت آبشاری، بعد از اینکه هر فاز کاملاً پایان پذیرفت، به مرحله بعدی می‌رویم. بازبینی که اجازه ایجاد تغییرات در سامانه را بدهد (که ممکن است شامل تغییرات فرایندهای کنترل رسمی باشد) فقط قبل از رفتن به مرحله بعد امکان‌پذیر است. همچنین بازبینی ممکن است جهت اطمینان از پایان قطعی این فاز (مرحله) بکار گرفته شود. فازی که معیارهای تکمیل آن کامل شده، معمولاً با عنوان دروازه گفته میشود که نشان می‌دهد پروژه از فاز فعلی به فاز بعدی منتقل شده‌است. الگو آبشاری از بازبینی و تجدید نظر فازهای قبلی که کامل شده‌اند، جلوگیری می‌کند. این عدم انعطاف‌پذیری مفصل در الگو آبشاری محض، دستمایه انتقاد پشتیبانی کنندگان الگوهای انعطاف‌پذیر است.
الگو ی مارپیچ (Spiral Model)
[ویرایش].svg)
خصوصیت کلیدی الگوی مارپیچ مدیریت ریسک در تمام مراحل چرخهٔ تولید نرم‌افزار است. در سال ۱۹۸۸ میلادی بری بوهم به صورت رسمی الگو مارپیچ فرایند تولید نرم‌افزار را منتشر کرد، که ترکیبی از بعضی کلیدهای تأیید شده متدولوژی الگو آبشاری و نمونه‌سازی سریع است، اما احساس میشود الگو ارائه شده تأکید در ناحیه‌های کلیدی (الگو آبشاری) را با متدهای دیگری همچون بررسی دقیق و تحلیل دائمی ریسک‌ها، سیستم‌های خاص مناسب برای سامانه پیچیده و بزرگ، کوتاه‌تر کرده‌است.
الگو مارپیچ این روش را با چهار نمودار که نشان دهند فعالیت‌های زیر است، به تصویر می‌کشد که فرایندها در چند مرحله تکرار انجام میشود:
- تدوین و فرموله کردن برنامه‌ریزی خوب است برای شناسایی اهداف سیستم، قسمت‌های انتخاب شده جهت پیاده‌سازی برنامه، محدودیت‌های واضح و مشخص پروژه.
- تحلیل ریسک و مشکلات سامانه: ارزیابی تحلیلی برنامه‌های انتخاب شده، جهت مشخص کردن چگونگی شناسایی و از بین بردن ریسک‌ها.
- پیاده‌سازی پروژه: پیاده‌سازی تولید نرم‌افزار و تأیید کارایی سامانه.
الگو مارپیچ مبتنی بر ریسک، بر اختیار انتخاب گزینه‌ها و محدودیت‌ها در سفارش‌ها برای پشتیبانی استفاده مجدد نرم‌افزار و اینکه کیفیت نرم‌افزار می‌تواند در ادغام اهداف ویژه در تولید نرم‌افزار کمک می‌کند، تأکید می‌کند.
به هر حال الگوی مارپیچ شرایط محدودکننده زیر را دارا می‌باشد:
- الگو مارپیچ تحلیل ریسک‌ها را تأکید می‌کند و بنابراین کاربران باید این تحلیل را قبول کنند و فکری برایش کنند (این مطالب را در نظر داشته باشند). این مسئله نیازمند اعتماد متقابل و همچنین تمایل به هزینه کردن برای رفع ایرادات، در هنگام تولید نرم‌افزار است و این دلیل استفاده شدن این الگو تولید نرم‌افزار پروژه‌های بزرگ است.
- درصورتیکه در هنگام پیاده‌سازی تحلیل ریسک‌ها تأثیر منفی روی سود پروژه زیاد باشد نبایستی از الگو مارپیچ استفاده گردد.
- تولید و توسعه دهندگان نرم‌افزار به صورت فعال حواسشان به ریسک‌های قابل حل خواهد بود و به دقت آنها را در الگو مارپیچ تحلیل می‌کنند.
مرحله اول تدوین و فرموله کردن یک برنامه برای رسیدن به اهداف با این محدودیت‌ها، و پس از آن تلاش برای پیدا کردن و حذف تمام خطرات بالقوه (ریسک‌های بالقوه) از طریق تجزیه و تحلیل دقیق و در صورت لزوم، با ساخت نمونه اولیه است. اگر برخی ریسک‌ها قابل حل نبودند در این صورت مشتریان باید تصمیم بگیرند که آیا می‌خواهند انجام پروژه را خاتمه دهند یا از ریسک‌های مورد نظر چشم پوشی کنند و به هر ترتیب ادامه دهند. در نهایت، نتایج ارزیابی شده و طراحی مرحله بعدی آغاز میشود. در حالت کلی یک الگو تکاملی است که به صورت مجموعه‌ای از نسخه‌های افزایشی توسعه می‌یابد و همچنین در طی تکرارهای اولیه ممکن است یک الگو کاغذی یا یک نمونه اولیه باشد ولی در طول تکرارهای بعدی هر بار نسخه کامل‌تری از سامانه تولید میشود و این الگو به ۳ تا ۶ نواحی کاری تقسیم میشود.
روش تکرارشونده و افزایشی
[ویرایش]
روشی تکراری تولید نرم‌افزار اجازهٔ ایجاد که پروژه در ابتدا از بخشهای کوچک شروع شود و به مرور زمان سامانه رشد کند تا کمک کند در این درگیری مشکلات مهم پیدا شوند قبل از اینکه فرضیات اشتباه باعث خراب شدن سامانه شوند. الگو تکرار فرایندها به وسیلهٔ تولیدکنندگان نرم‌افزارهای تجاری انتخاب و استفاده میشود چون این الگو اجازه می‌دهد تا نیازهای کاربرانی که در زمان طراحی دقیقاً نمی‌دانند چگونه نیازمندی‌هایشان از سامانه را معرفی کنند به صورت بالقوه برآورده شود.
روش توسعه سریع نرم‌افزار
[ویرایش]
روش توسعه سریع نرم‌افزار (به انگلیسی: Rapid application development)(مخفف انگلیسی: RAD) روش تکراری را به عنوان پایه کار استفاده می‌کند اما طرفداری نظریه سبک‌تر و محبوبیت بیشتر از روش سنتی است. روش سریع از بازخوردها به جای برنامه‌ریزی به عنوان سازوکار اصلی کنترل پروژه استفاده می‌کند. بازخوردها به وسیلهٔ آزمون‌های مرتب و انتشار پیاپی در بازه‌های زمانی کوتاه نرم‌افزارهای در حال تکامل تولید می‌شوند.
روش‌های گوناگونی از فرایند سریع برای تولید نرم‌افزار استفاده میشود:
روش برنامه‌سازی مفرط
[ویرایش]
تولید نرم‌افزار به روش برنامه‌سازی مفرط (به انگلیسی: Extreme programming)(مخفف انگلیسی: XP) در فازهای خیلی کوچک (یا مداوم) انجام و با فرایندهای دسته‌ای قدیمی‌تر تطبیق داده می‌شوند. فاز اول (که عمداً کامل نشده) در طول مراحل ممکن است به جای اینکه ماه‌ها و سال‌ها در روش آبشاری طول بکشد تا کامل شود، یک روز یا یک هفته وقت بگیرد. ابتدا یک آزمون خودکار برای ایجاد اهداف اساسی تولید نرم‌افزار نوشته میشود. سپس (توسط دو برنامه‌نویس) برنامه‌نویسی انجام می‌گیرد که وقتی تمام آزمون‌ها را پشت سر گذاشته و دیگر هیچ آزمون مورد نیازی به ذهن برنامه‌نویسان نرسد کامل میشود. کار طراحی و معماری سیستم بعد از اینکه نه آزمونی وجود دارد و نه برنامه‌نویسی‌شده انجام میشود. طراحی توسط برنامه‌نویسان انجام میشود. (فقط مشخصات نهایی و ترکیب طراحی و کد در تمام فرایندها در روش سریع مشترک هستند) عملیات اصلی ناقص سامانه (توسط دست کم یکی از افراد گروه تولیدکننده و برنامه‌نویس) برای کاربران (یا برخی از کاربران) نصب یا نمایش داده می‌شوند. در اینجا تمام عوامل پروژه دوباره شروع به نوشتن آزمون برای قسمت‌های مهم سامانه خواهند کرد.
الگو اسکرام
[ویرایش]
اسکرام یک روش چابکِ تکرارشونده و افزایشی برای مدیریت پروژه است که معمولاً در الگوی تولید نرم‌افزار چابک به عنوان نوعی متدولوژی توسعه نرم‌افزار دیده میشود.
با اینکه روش اسکرام در واقع برای مدیریت محصولات تولید و توسعه پروژه‌ها پیشنهاد شده بود، اما استفاده آن در مدیریت پروژه‌های تولید نرم‌افزار متمرکز شد؛ همچنین امکان دارد جهت مدیریت تیم نگهداری نرم‌افزار، مدیریت پروژه‌ها یا برنامه‌های عمومی مدیریت خط مشی‌ها استفاده شود.
الگوهای بهبودسازی
[ویرایش]الگوی تکامل قابلیت یکپارچه‌سازی (CMMI)
[ویرایش]الگوی تکامل قابلیت یکپارچه‌سازی (CMMI) یکی از الگوهای پیشنهادی و تکنیک‌های پیشتاز است. ارزیابی سازمان‌های مستقل و رتبه‌بندی در مورد کیفیت چگونگی تعریف فرایندهای آن سازمان‌ها را دنبال می‌کند، نه بر کیفیت خود فرایندها یا نرم‌افزار تهیه شده‌است. الگوی CMMI جایگزین الگوی CMM شده‌است.
ایزو ۹۰۰۰
[ویرایش]ایزو ۹۰۰۰ یک استاندارد رسمی سازماندهی فرایند ساخت محصولات و روشی برای مدیریت و نظارت پیشرفت کارهاست. در اصل این استاندارد برای بخش تولید و ساخت (صنعتی) ایجاد شد. ایزو ۹۰۰۰ همچنین برای فرایند تولید نرم‌افزار نیز به خوبی استفاده شده. مانند الگوی CMMI مدرک ایزو ۹۰۰۰ هیچ تضمینی راجع به کیفیت نتایج نهایی ندارد و فقط فرایندهای کاری را فرموله و قالب استاندارد رسمی می‌دهد.
ایزو ۱۵۵۰۴
[ویرایش]ایزو ۱۵۵۰۴ که با عنوان فرایند تشخیص و تعیین بهبود قابلیت نرم‌افزار (به انگلیسی: Software Process Improvement and Capability Determination)(مخفف انگلیسی: SPICE) نیز شناخته میشود، چارچوبی برای ارزیابی فرایندهای نرم‌افزار است. این استاندارد تنظیمات قالب روشنی برای مقایسه فرایندها به‌شمار می‌رود. SPICE خیلی شبیه CMMI استفاده میشود. فرایندهای این الگو برای مدیریت، کنترل، راهنمایی و نظارت تولید نرم‌افزار است. این الگو جهت سنجش سازماندهی تولید و توسعه یا تیم پروژه به صورت واقعی در طول مدت تولید نرم‌افزار استفاده میشود. تجزیه و تحلیل این اطلاعات برای شناسایی نقاط ضعف و حرکت به سمت بهبود پروژه استفاده میشود. همچنین برای تشخیص نقاط قوت پروژه که می‌تواند برای سازمان یا تیم پروژه ادامه پیدا کند یا برای امور مشترک یکپارچه شود.
جستارهای وابسته
[ویرایش]پانویس
[ویرایش]
- ↑ "Selecting a development approach" (PDF). Centers for Medicare & Medicaid Services (CMS) Office of Information Service. United States Department of Health and Human Services (HHS). March 27, 2008 [Original Issuance: February 17, 2005]. Archived from the original (PDF) on June 20, 2012. Retrieved October 27, 2008.
- ↑ Geoffrey Elliott (2004). Global Business Information Technology: an integrated systems approach. Pearson Education. p. 87.
| حوزهها | |||||||
|---|---|---|---|---|---|---|---|
| مفاهیم | |||||||
| گرایشات | |||||||
| مدل‌ها |
| ||||||
مهندسان نرم‌افزار سرشناس | |||||||
| حوزههای مرتبط | |||||||
Note: This template roughly follows the 2012 ACM Computing Classification System. | |
| سخت‌افزار | |
| سازمان سامانه‌های رایانه | |
| شبکه رایانه‌ای | |
| سازمان نرم‌افزار | |
| نظریه زبان‌های برنامه‌نویسی و ابزار توسعه نرم‌افزار | |
| توسعه نرم‌افزار | |
| نظریه محاسبات | |
| الگوریتمها | |
| ریاضیات رایانه | |
| سامانه اطلاعاتی | |
| امنیت رایانه | |
| تعامل انسان و رایانه | |
| همروندی | |
| هوش مصنوعی | |
| یادگیری ماشین | |
| گرافیک رایانه‌ای | |
| رایانش کاربردی | |
توجه: بنا بر سامانه رده‌بندی رایانش ای‌سی‌ام علم رایانه همچنین می‌تواند به موضوع‌ها یا زمینه‌های گوناگون تقسیم شود.
| |
