چرخه عمر توسعه نرم‌افزار به سازمان‌ها یک رویکرد سیستماتیک و مرحله به مرحله برای توسعه نرم‌افزارهای موفق با جمع‌آوری نیازهای اولیه برای محصولات جدید ارائه می‌دهد. این یک فرآیند سیستماتیک برای ساخت نرم‌افزار است تا کیفیت و درستی نرم‌افزار ساخته شده را تضمین کند و انتظارات مشتری را برآورده سازد.
مدل‌های اصلی توسعه شامل مدل آبشاری، مدل افزایشی، مدل حلزونی، مدل چشمه، مدل هوشمند، مدل V، مدل RAD، مدل CBSD، روش پروتوتایپ، روش XP، روش RUP و غیره است.
مدل آبشاری
مدل آبشاری، که به عنوان روش چرخه عمر نیز شناخته می‌شود، رایج‌ترین مدل توسعه در روش چرخه عمر است. این مدل فرآیند توسعه نرم‌افزار را به شش مرحله تقسیم می‌کند: برنامه‌ریزی نرم‌افزار، تحلیل نیازها، طراحی نرم‌افزار، کدنویسی برنامه، تست نرم‌افزار و عملیات و نگهداری. برای دستیابی به ترتیب ثابت خود از بالا به پایین، مانند یک آبشار، آنها به صورت مرحله به مرحله سقوط می‌کنند.
- برنامه نرم‌افزار: عمدتاً اهداف توسعه و قابلیت اجرایی نرم‌افزار را تعیین می‌کند.
- تحلیل نیازها: پس از تأیید اینکه توسعه نرم‌افزار ممکن است، یک تحلیل دقیق از عملکردهای مختلفی که نرم‌افزار باید به آنها دست یابد، انجام دهید. مرحله تحلیل نیازها یک مرحله بسیار مهم است. انجام خوب در این مرحله، پایه‌ای خوب برای موفقیت کل پروژه توسعه نرم‌افزار خواهد بود.
- طراحی نرم‌افزار: طراحی کل سیستم نرم‌افزاری، مانند طراحی چارچوب سیستم، طراحی پایگاه داده و غیره، بر اساس نتایج تحلیل نیازها. طراحی نرم‌افزار به طور کلی به طراحی کلی (طراحی کلی) و طراحی جزئی تقسیم می‌شود.
- کد برنامه: تبدیل نتیجه طراحی نرم‌افزار به کد برنامه‌ای که می‌تواند توسط یک کامپیوتر اجرا شود. در فرآیند برنامه‌نویسی، باید یک مشخصات برنامه‌نویسی یکپارچه و مطابق با استاندارد تدوین شود تا خوانایی برنامه، نگهداری آسان و بهبود کارایی عملیاتی برنامه تضمین شود.
- تست نرم‌افزار: پس از اتمام طراحی نرم‌افزار، باید تحت آزمایش‌های دقیق قرار گیرد تا مشکلات موجود در نرم‌افزار در طول فرآیند طراحی شناسایی و اصلاح شود. در فرآیند تست، لازم است یک برنامه تست دقیق تدوین شود و آزمایش‌ها به طور دقیق مطابق با برنامه تست انجام شود تا خودسرانه بودن تست کاهش یابد. نگهداری نرم‌افزار:
- نگهداری نرم‌افزار طولانی‌ترین دوره در چرخه عمر نرم‌افزار است. پس از توسعه و استفاده از نرم‌افزار، به دلایل مختلف، نرم‌افزار نمی‌تواند به نیازهای کاربران ادامه دهد. برای افزایش عمر مفید نرم‌افزار، باید نگهداری شود.
مدل تحول
مدل تحول (مدل تکاملی) بر اساس توسعه سریع یک پروتوتایپ است. بر اساس بازخورد و پیشنهادات ارائه شده توسط کاربران در فرآیند فراخوانی پروتوتایپ، پروتوتایپ بهبود می‌یابد تا نسخه جدیدی از پروتوتایپ به دست آید و این فرآیند تکرار می‌شود تا به محصول نهایی نرم‌افزار تبدیل شود.
مدل حلزونی
مدل حلزونی مدل آبشاری و مدل تحول را ترکیب می‌کند. این مدل مزایای هر دو را ترکیب کرده و تحلیل ریسک را اضافه می‌کند. این مدل بر اساس پروتوتایپ است و از داخل به خارج در امتداد حلزونی می‌چرخد. هر چرخش نیاز به برنامه‌ریزی، تحلیل ریسک، مهندسی پیاده‌سازی، ارزیابی مشتری و سایر فعالیت‌ها دارد و نسخه جدیدی از پروتوتایپ توسعه می‌یابد. پس از چندین چرخش، سیستم نهایی به دست می‌آید.
مدل چشمه
مدل چشمه از نرم‌افزار برای استفاده مجدد و ادغام فعالیت‌های توسعه متعدد در چرخه عمر پشتیبانی می‌کند و عمدتاً از روش‌های توسعه شی‌گرا پشتیبانی می‌کند. اصطلاح «چشمه» خود ویژگی‌های تکرار و بدون فاصله را تجسم می‌کند. بخشی از سیستم معمولاً کار را چندین بار تکرار می‌کند و عملکردهای مرتبط در هر تکرار به سیستم تکامل‌یافته اضافه می‌شود. به اصطلاح بدون فاصله به این معنی است که هیچ مرز واضحی بین تحلیل، طراحی و کدنویسی در فعالیت‌های توسعه وجود ندارد.
مدل V
در مدل توسعه، تست معمولاً به عنوان یک فکر ثانویه برای اصلاح وضعیت استفاده می‌شود، اما همچنین یک مدل توسعه متمرکز بر تست وجود دارد، یعنی مدل V. مدل V تنها به طور مبهمی در صنعت نرم‌افزار شناخته شده است. مدل V ادعا می‌کند که تست یک فکر ثانویه نیست، بلکه فرآیندی به همان اندازه مهم به عنوان فرآیند توسعه است.
مدل V برخی از سطوح تست مختلف را توصیف می‌کند و مراحل مختلف در چرخه عمر را که به این سطوح مربوط می‌شود، توضیح می‌دهد. در شکل، نزول در سمت چپ مراحل مختلف فرآیند توسعه است و قسمت‌های مربوطه در سمت راست، یعنی مراحل مختلف فرآیند تست است.
لطفاً توجه داشته باشید که نام‌گذاری مرحله تست ممکن است در سازمان‌های مختلف متفاوت باشد. ارزش مدل V این است که به وضوح سطوح مختلفی را که در فرآیند تست وجود دارد نشان می‌دهد و به وضوح تطابق بین این مراحل تست و مراحل مختلف در طول فرآیند توسعه را توصیف می‌کند:
- هدف اصلی تست واحد، رسیدگی به انواع خطاهایی است که ممکن است در فرآیند کدنویسی وجود داشته باشد. به عنوان مثال: کاربر در فرآیند تأیید یک خطا در مقدار مرزی وارد می‌کند.
- هدف اصلی تست یکپارچگی، رسیدگی به مشکلات ممکن در طراحی جزئی است، به ویژه برای بررسی خطاهای ممکن در رابط بین هر واحد و سایر بخش‌های برنامه.
- تست سیستم عمدتاً برای طراحی کلی است، بررسی اینکه آیا سیستم به عنوان یک کل به طور مؤثر عمل می‌کند. به عنوان مثال: آیا عملکرد بالای مورد انتظار در تنظیمات محصول به دست آمده است.
- تست پذیرش معمولاً توسط کارشناسان کسب و کار یا کاربران انجام می‌شود تا تأیید کند که محصول واقعاً می‌تواند نیازهای کسب و کار کاربر را برآورده کند.
مدل افزایشی
مدل‌های افزایشی، مانند مدل‌های پیاده‌سازی پروتوتایپ و سایر روش‌های تکاملی، اساساً تکراری هستند. اما برخلاف پیاده‌سازی پروتوتایپ، مدل افزایشی تأکید می‌کند که هر افزونه یک محصول قابل استفاده را منتشر می‌کند. افزونه‌های اولیه نسخه «قابل جدا شدن» محصول نهایی هستند، اما آنها عملکردهای خدماتی کاربر را ارائه می‌دهند و یک پلتفرم برای ارزیابی کاربران فراهم می‌کنند.
ویژگی مدل افزایشی معرفی مفهوم بسته‌های افزایشی است. شما نیازی به انتظار برای خروج تمام نیازها ندارید، به محض اینکه بسته‌های افزایشی یک نیاز خاص خارج شود، می‌توانید توسعه را آغاز کنید. اگرچه یک بسته افزایشی خاص ممکن است نیاز به سازگاری بیشتر با نیازهای مشتریان و نیاز به تغییر داشته باشد، به شرطی که بسته افزایشی به اندازه کافی کوچک باشد، تأثیر آن می‌تواند برای کل پروژه قابل تحمل باشد.
مدل RAD مدل توسعه نرم‌افزار سریع (RAD) یک مدل فرآیند توسعه نرم‌افزار افزایشی است که بر یک چرخه توسعه بسیار کوتاه تأکید دارد.
مدل RAD یک نوع «سرعت بالا» از مدل آبشاری است که از طریق استفاده گسترده از اجزای قابل استفاده مجدد و یک روش ساخت مبتنی بر اجزا، توسعه سریع را به دست می‌آورد. اگر نیازها به خوبی درک شده و دامنه پروژه محدود باشد، می‌توان از این مدل برای ایجاد سریع یک «سیستم اطلاعاتی» کاملاً کاربردی استفاده کرد.
این فرآیند با مدل‌سازی کسب و کار آغاز می‌شود، سپس مدل‌سازی داده، مدل‌سازی فرآیند، تولید برنامه، تست و تکرار دنبال می‌شود. فرآیند نرم‌افزاری که از مدل RAD استفاده می‌کند در شکل زیر نشان داده شده است.
کارهایی که باید در هر دوره فعالیت مدل RAD انجام شود به شرح زیر است.
مدل‌سازی کسب و کار: چه اطلاعاتی عملیات فرآیند کسب و کار را هدایت می‌کند؟ چه اطلاعاتی باید تولید شود؟ چه کسی آن را تولید کرده است؟ جریان اطلاعات به کجا می‌رود؟ چه کسی آن را مدیریت خواهد کرد؟ می‌تواند با نمودارهای جریان داده تکمیل شود.
مدل‌سازی داده: به منظور پشتیبانی از جریان داده‌های فرآیند کسب و کار، مجموعه‌ای از اشیاء داده را پیدا کنید، ویژگی‌های اشیاء داده را تعریف کنید و مدل داده را با رابطه با سایر اشیاء داده تشکیل دهید که می‌تواند با نمودارهای ER تکمیل شود.
مدل‌سازی فرآیند: به اشیاء داده اجازه می‌دهد تا عملکردهای مختلف کسب و کار را در جریان اطلاعات تکمیل کنند. فرآیند ایجاد توصیف می‌کند که چگونه اشیاء داده اضافه، اصلاح، حذف و جستجو می‌شوند، یعنی تصفیه جعبه پردازش در نمودار جریان داده.
تولید برنامه کاربردی: از زبان نسل چهارم (4GL) برای نوشتن برنامه پردازش استفاده کنید، از اجزای موجود دوباره استفاده کنید یا اجزای جدید قابل استفاده مجدد ایجاد کنید و از ابزارهای ارائه شده توسط محیط برای تولید و ساخت خودکار کل سیستم کاربردی استفاده کنید.
تست و تحویل، به دلیل مقدار زیادی از استفاده مجدد، معمولاً فقط تست کلی انجام می‌شود، اما اجزای تازه ایجاد شده هنوز نیاز به تست دارند.
مدل مبتنی بر اجزا
جزء (Component) یک واحد نرم‌افزاری با ارزش قابل استفاده مجدد و عملکردهای نسبتاً مستقل است. مدل توسعه نرم‌افزار مبتنی بر اجزا (CBSD) استفاده از یک رویکرد مدولار برای مدولار کردن کل سیستم است و با حمایت از یک مدل خاص از اجزا، یک یا چند جزء نرم‌افزاری را در کتابخانه اجزا دوباره استفاده می‌کند و از طریق ترکیب، فرآیند ساخت سیستم‌های نرم‌افزاری کاربردی با کارایی و کیفیت بالا را انجام می‌دهد.
مدل توسعه مبتنی بر اجزا بسیاری از ویژگی‌های مدل حلزونی را در بر می‌گیرد و اساساً تکاملی است و فرآیند توسعه تکراری است. مدل توسعه مبتنی بر اجزا شامل پنج مرحله است: تحلیل و تعریف نیازهای نرم‌افزار، طراحی معماری، تأسیس کتابخانه اجزا، ساخت نرم‌افزار کاربردی، تست و انتشار.
روش پروتوتایپ
پروتوتایپ نرم‌افزار تحقق جزئی از محصول جدید پیشنهادی است. هدف اصلی ایجاد پروتوتایپ حل مشکل تقاضای نامشخص در مرحله اولیه توسعه محصول است. هدف آن روشن کردن و بهبود نیازها، کاوش در گزینه‌های طراحی و توسعه به محصول نهایی است.
راه‌های زیادی برای طبقه‌بندی پروتوتایپ‌ها وجود دارد. از منظر اینکه آیا پروتوتایپ عملکردهای خود را تحقق می‌بخشد یا خیر، پروتوتایپ‌های نرم‌افزاری می‌توانند به دو نوع تقسیم شوند: پروتوتایپ‌های افقی و پروتوتایپ‌های عمودی.
پروتوتایپ‌های افقی همچنین به عنوان پروتوتایپ‌های رفتاری شناخته می‌شوند، که برای کاوش در برخی رفتارهای خاص سیستم مورد انتظار استفاده می‌شوند و هدف آنها تصفیه نیازها است. پروتوتایپ‌های افقی معمولاً فقط ناوبری عملکردها هستند، اما در واقع عملکردها را پیاده‌سازی نمی‌کنند. پروتوتایپ افقی عمدتاً در رابط استفاده می‌شود.
نمونه‌های عمودی همچنین به عنوان نمونه‌های ساختاری شناخته می‌شوند که بخشی از عملکردهای خود را پیاده‌سازی می‌کنند. نمونه‌های عمودی عمدتاً در تحقق الگوریتم‌های پیچیده استفاده می‌شوند.
روش XP
XP یک روش توسعه نرم‌افزار سبک (چابک)، کارآمد، کم‌خطر، انعطاف‌پذیر، قابل پیش‌بینی، علمی و سرگرم‌کننده است. در مقایسه با سایر روش‌ها، بزرگترین تفاوت در:
- بازخورد خاص و مداوم را زودتر در یک دوره کوتاه‌تر ارائه دهید.
- برنامه‌ریزی تکراری، ابتدا تولید یک برنامه اصلی به سرعت در ابتدای کار و سپس توسعه مداوم آن در طول فرآیند توسعه پروژه.
- به رویه‌های تست خودکار برای نظارت بر پیشرفت توسعه و شناسایی نقص‌ها در مراحل اولیه تکیه کنید.
- به ارتباط کلامی، تست و ارتباط برنامه منبع تکیه کنید.
- از طراحی تکاملی مداوم حمایت کنید.
- به همکاری نزدیک درون تیم توسعه تکیه کنید.
- سعی کنید تا حد امکان منافع کوتاه‌مدت برنامه‌نویس و منافع بلندمدت پروژه را متعادل کنید.
روش فرآیند یکپارچه (UP)
فرآیند یکپارچه یک چارچوب فرآیند عمومی است که می‌تواند با دامنه وسیعی از سیستم‌های نرم‌افزاری، زمینه‌های کاربردی مختلف، انواع سازمان‌های مختلف، سطوح عملکرد مختلف و مقیاس‌های پروژه مختلف سازگار باشد. UP مبتنی بر مؤلفه است، به این معنی که سیستم نرم‌افزاری توسعه‌یافته توسط آن از مؤلفه‌ها تشکیل شده و مؤلفه‌ها از طریق رابط‌های به‌خوبی تعریف‌شده به یکدیگر متصل هستند. هنگام تهیه تمام نقشه‌های سیستم نرم‌افزاری، UP از زبان مدل‌سازی یکپارچه UML استفاده می‌کند.
در مقایسه با سایر فرآیندهای نرم‌افزاری، UP دارای سه ویژگی قابل توجه است: مبتنی بر مورد استفاده، متمرکز بر معماری پایه، تکرار و افزایش. فرآیند نرم‌افزار در فرآیند یکپارچه منطقی به چهار مرحله متوالی در زمان تقسیم می‌شود: مرحله اولیه، مرحله تصفیه، مرحله ساخت و مرحله تحویل. در پایان هر مرحله، باید یک بازبینی فنی ترتیب داده شود تا مشخص شود آیا اهداف این مرحله برآورده شده است یا خیر. اگر نتایج بازبینی رضایت‌بخش باشد، پروژه می‌تواند به مرحله بعدی منتقل شود.
بیشتر بیاموزید
- مدل فرآیند نرم‌افزار چیست؟
- برنامه‌ریزی تطبیقی در مقابل پیش‌بینی: چه زمانی چابک؟ چه زمانی آبشاری؟
- چرخه عمر توسعه نرم‌افزار چیست؟
- راهنماهای یادگیری اسکرام
- راهنماهای یادگیری مدیریت پروژه
- UML چیست؟
- توسعه نرم‌افزار چابک چیست؟
- داستان کاربر در مقابل مورد استفاده برای توسعه نرم‌افزار چابک
This post is also available in Deutsch, English, Español, Français, Bahasa Indonesia, 日本語, Polski, Portuguese, Ру́сский, Việt Nam, 简体中文 and 繁體中文.