فرایند توسعه نرم‌افزار
این مقاله نیازمند تمیزکاری است. لطفاً تا جای امکان آنرا از نظر املا، انشا، چیدمان و درستی بهتر کنید، سپس این برچسب را بردارید. محتویات این مقاله ممکن است غیر قابل اعتماد و نادرست یا جانبدارانه باشد یا قوانین حقوق پدیدآورندگان را نقض کرده باشد. |
فرایند تولید نرم‌افزار که با عنوان «چرخهٔ حیات تولید نرم‌افزار» نیز شناخته می‌شود، ساختاری است که روی توسعه و تولید محصولات نرم‌افزاری اعمال می‌شود. عبارت‌های مشابهی چون «چرخهٔ حیات نرم‌افزار» و «فرایند نرم‌افزار» در این رابطه استفاده می‌شود. الگوهای گوناگونی نظیر فرایندهای خاص وجود دارند که هر کدام خط مشی مختص (آن فرایندها) برای انجام کارها و فعالیت‌های متنوع در طول فرایندها را مشخص می‌کنند. برخی عنوان می‌کنند که «طرح چرخهٔ حیات» یک عبارت بسیار عمومی بوده و «فرایند تولید نرم‌افزار» عبارت تخصصی‌تر است. برای مثال خیلی از فرایندهای تولید نرم‌افزار ویژه‌ای هستند که خود زیر مجموعه چرخهٔ حیات مارپیچ به‌شمار می‌روند.[۱][۲]
فعالیت‌های تولید نرم‌افزار
ویرایشبرنامهریزی (امکان‌سنجی)
ویرایشاز مهم‌ترین کارها در تولید نرم‌افزار استخراج نیازمندی‌ها یا تحلیل نیازمندی‌های آن سامانه است. مشتریان عمومی معمولاً تصور مفهومی، انتزاعی و مبهمی از نتیجه نهایی خواسته‌هایشان دارند و نمی‌دانند به درستی نرم‌افزار مورد نظرشان چه کاری باید انجام دهد. در این مرحله نیازمندی‌های ناتمام، پیچیده و مبهم، و حتی متضاد توسط مهندسان نرم‌افزار ماهر شناسایی می‌شوند. در این برهه تکه نرم‌افزارهای آماده، تجربه‌شده و فعال ممکن است برای پایین آوردن ریسک (و مشکلات) نیازمندی‌ها کمک کنند. نخست نیازمندی‌های عمومی از کاربران جمع‌آوری شده و دامنه توسعه و تولید نرم‌افزار که باید تولید شود شناسایی و تحلیل می‌شود، سپس مستندات به صورت شفاف نوشته می‌شوند. معمولاً به این مستند، مستند دامنه یا محدوده سامانه گفته می‌شود.
برخی قابلیت‌ها ممکن است در ابتدای پروژه به خاطر مسائل مالی یا نیازمندی‌های غیر شفاف و نامشخص خارج از محدوده پروژه باشند. اگر تولید و توسعه نرم‌افزار برون‌سپاری شود (یعنی به شرکت‌های خارجی محول شود) این مستندات به عنوان مستندات قانونی و حقوقی در نظر گرفته می‌شود؛ بنابراین در صورت اتفاق هرگونه دعوای حقوقی یا ابهام در مورد تعهدات داده‌شده به کاربر، این مسائل قابل شفاف‌سازی خواهد بود.
پیاده‌سازی، آزمون و مستندسازی
ویرایشپیادهسازی آن قسمت از فرایند تولید نرم‌افزار به‌شمار می‌رود که مهندسان نرم‌افزار در دنیای واقعی تمام کدهای پروژه را می‌نویسند و به قول معروف برنامه‌نویسی می‌کنند.
آزمون نرم‌افزار بخش لاینفک و مهم از فرایند تولید نرم‌افزار است. این قسمت از فرایندها کمک می‌کند تا مشکلات سامانه به صورت سریع شناسایی شوند.
مستندسازی در تمام مراحل پروژه چون طراحی داخلی نرم‌افزار برای تعیین اهداف سیستم، نگهداری آینده و ارتقاء و بهبود سامانه هرچند پروژه پایان یافته باشد انجام می‌شود. همچنین ممکن است این مستندسازی شامل نوشتن ساختار تکه‌های برنامه ظاهر برنامه کاربردی داخلی و خارجی هم باشند. این مطلب خیلی مهم است که همه چیز پروژه مستندسازی شود.
استقرار و نگهداری سامانه
ویرایشاستقرار و تحویل سامانه پس از اینکه آزمون مناسب را گذراند و برای انتشار، فروش یا هر نوع توزیع برای محیط کار نهایی تأیید شد انجام خواهد شد.
آموزش نرم‌افزار و پشتیبانی خیلی مهم است و خیلی از تولیدکنندگان و توسعه‌دهندگان نرم‌افزارها اهمیت آن را درک نمی‌کنند. مهم نیست که چقدر زمان و برنامه‌ریزی توسط تیم تولید و توسعه نرم‌افزار برای ایجاد نرم‌افزار مصرف کرده‌اند اگر در آخر کار کاربری در سازمان نباشد تا از نرم‌افزار استفاده کند. مردم معمولاً در برابر تغییرات مقاومت نشان می‌دهند و از ماجراجویی در محیط ناآشنا اجتناب می‌کنند، برای همین در فاز استقرار این خیلی مهم است کلاس‌های آموزشی برای کاربران جدیدِ نرم‌افزار گذاشته شود.
نگهداری و ارتقای نرم‌افزاری برای پوشش، مسائل پوشش داده‌نشده یا نیازمندی‌های تازه‌ای که ممکن است به وجود آیند مدت خیلی زیادی حتی بیشتر از زمان اولیه تولید نرم‌افزار زمان بگیرد. این مرحله ممکن است نیاز باشد تا کدهای برنامه‌نویسی تازه‌ای که در طراحی اصلی برنامه نیز دیده نشده اضافه شود تا مسائل و مشکلات دیده‌نشده حل شوند یا ممکن است کاربر درخواست عملیات اصلی دیگری کند و برنامه‌نویسی‌های تازه‌ای برای برآورده کردن نیازهای جدید انجام گیرد. اگر هزینه کار فاز نگهداری از ۲۵ درصد هزینه فاز قبلی (پیاده‌سازی) بیشتر باشد، این احتمال وجود دارد که کیفیت کلی فاز قبلی خیلی ضعیف بوده باشد. در این صورت مدیران پروژه باید گزینهٔ ایجاد مجدد سامانه (یا بخشی از سامانه) را قبل از اینکه هزینه‌های نگهداری غیرقابل کنترل شود را مطرح کنند.
الگوهای تولید نرم‌افزار
ویرایشالگو آبشاری
ویرایش
الگوی آبشاری فرایندها را به گونه‌ای نشان می‌دهد که کجا تولیدکنندگان نرم‌افزار (برنامه‌نویسان) فازهای زیر را به ترتیب انجام دهند:
- مشخصات مورد نیاز (تحلیل نیازمندی‌ها)
- طراحی نرم‌افزار
- پیاده‌سازی و یکپارچه سازی
- تست نرم‌افزار (یا اعتبارسنجی)
- گسترش نرم‌افزار (یا نصب)
- نگهداری نرم‌افزار
در این مدل فعالیت‌های تولید نرم‌افزار در قالب فازهای با توالی مشخص و به ترتیب، برنامه‌ریزی و اجرا می‌شوند. اشکال عمده این روش این است که بازبینی و تجدید نظر در فازهای انجام شده امکان‌پذیر نیست لذا خطای تخمین ابعاد پروژه، ریسک اشتباه در فهم درست و تحلیل نیازمندی‌ها و نیز امکان انتخاب نابجای معماری بسیار بالا می‌باشد. در سختگیرانه‌ترین حالت آبشاری، بعد از اینکه هر فاز کاملاً پایان پذیرفت، به مرحله بعدی می‌رویم. بازبینی که اجازه ایجاد تغییرات در سامانه را بدهد (که ممکن است شامل تغییرات فرایندهای کنترل رسمی باشد) فقط قبل از رفتن به مرحله بعد امکان‌پذیر است. همچنین بازبینی ممکن است جهت اطمینان از پایان قطعی این فاز (مرحله) بکار گرفته شود. فازی که معیارهای تکمیل آن کامل شده، معمولاً با عنوان دروازه گفته می‌شود که نشان می‌دهد پروژه از فاز فعلی به فاز بعدی منتقل شده‌است. الگو آبشاری از بازبینی و تجدید نظر فازهای قبلی که کامل شده‌اند، جلوگیری می‌کند. این عدم انعطاف‌پذیری مفصل در الگو آبشاری محض، دستمایه انتقاد پشتیبانی کنندگان الگوهای انعطاف‌پذیر است.
الگو ی مارپیچ (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.