Let’s travel together.

 فرآیند یکپارچه رشنال یا RUP چیست؟

زمان مطالعه: 8 دقیقه

فرآیند یکپارچه رشنال یا RUP را می‌توان یک راهنمای نهایی برای واگذاری مسئولیت‌ها و وظایف در یک سازمان توسعه‌یافته دانست؛ از دیگر سو راهنمایی است برای توسعه یک نرم‌افزار باکیفیت که نیازها و خواسته‌های کاربرانش را برآورده می‌کند.

این فرآیند امروزه مورداستفاده گسترده توسط سازمان‌های بزرگ به منظور توسعه نرم‌افزارها قرار گرفته است. در این مطلب قصد داریم شما را بیشتر با این فرآیند و ویژگی‌های آن آشنا کنیم.

تاریخچه

در فرهنگ مهندسی نرم‌افزار، فرآیند یکپارچه رشنال، که معمولا با (Rational Unified Process (RUP شناخته می­‌شود، نام یک فرآیند توسعه نرم‌افزار است که شرکت رشنال IBM، آن را تدوین کرده‌است. IBM این شرکت را در سال ۲۰۰۳ خرید و هم‌اکنون توسعه این فرایند و ابزارهای آن را به‌عهده دارد. به‌طور خلاصه، آریوپی ارائه‌دهنده مجموعه‌ای از روش‌ها برای کمک به مدیریت دقیق بر روی مراحل طراحی و پیاده‌سازی نرم‌افزارهای رایانه‌ای است. این فرآیند، بستر مناسبی برای تولید و توسعه نرم‌افزار در اختیار تحلیل‌گران و طراحان سیستم‌های رایانه‌ای قرار می‌دهد.

هدف از ابداع این فرآیند

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

RUP امکان استفاده مؤثرتری از زبان یکپارچه مدلسازی (UML) را فراهم می‌سازد. به کمک تکنیک‌های RUP، بخش‌های عمده‌ای از فرآیند تولید نرم‌افزار به‌طور خودکار انجام شده و همچنین استفاده از مدل‌های تولید شده در فرآیندهای گذشته در پروژه‌های جاری به سادگی امکان‌پذیر است. این فرآیند، با موقعیت‌های مختلف تطبیق یافته و برای سازمان‌های بزرگ یا حتی کوچک تولید و توسعه نرم‌افزار قابل استفاده‌ است.

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

فرآيند RUP، فرآيندي قابل شكل­‌دهي است. هيچ فرآيند واحدي براي همه نرم‌افزارها مناسب نیست، فرآيند RUP، همانطور كه براي سازمان‌هاي بزرگ توسعه نرم‌افزار مناسب است، براي تيم‌هاي كوچك نيز مفيد است. اين فرآيند مي­‌تواند با موقعيت‌هاي مختلف تطبيق پيدا كند.

به سه علت RUP را يكپارچه مي‌نامند:

  1. اين متدولوژي از يكپارچه‌­سازي سه متدولوژي معروف ديگر به وجود آمده است، كه شامل Booch، OMT و OSE مي‌شود.
  2. از UML در جهت كارهاي خود استفاده مي­‌كند. در واقع مي­‌توان گفت UML، خود ثمره RUP است و اين خود بسيار خوب است كه متدولوژيي با خودش گسترش يابد.
  3. مفاهيمي از قبيل Object، Class و … مفاهيم ساده و ثابتي هستند، ولي متدولوژي‌های قبلی علامت‌هاي خاصي داشتند كه اكنون همه آنها يكسان شده‌اند.

ویژگی­‌های این فرآیند

مبتنی بر موارد قابل کاربرد

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

ممکن است در این توالی فعالیت­‌ها، دگرگونی­‌هائی نیز وجود داشته باشد. کاربر یا سیستم خارجی را «عامل» می‌نامیم­. مدل مورد کاربرد شامل عامل­‌ها، موارد کاربرد و ارتباطات بین آنهاست. این مدل همچنین شرح می­‌دهد که سیستم برای کاربران خود تحت شرایط متفاوت چه عملکردهایی می­‌تواند داشته باشد.

مبتنی بر معماری

معماری نرم‌افزار همانند معماری ساختمان است­. معماری در حوزه‌­ای بر بهره‌مندی از تلفیق علم، هنر و تجربه، تکیه دارد. معماری نرم‌افزار مطابق نظر آقای Kruchen، در معماری 4+1 از دیدگاه‌­های مختلف شامل دیدگاه مورد کاربرد، دیدگاه منطقی، دیدگاه فرآیندها، دیدگاه استقرار و دیدگاه پیاده‌سازی تشکیل شده است.

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

تکرار، یعنی یکبار انجام دادن همه نظام­‌های یک فرآیند توسعه. یک پروژه را به چندین پروژه کوچک (مینی پروژه) تقسیم نموده و در هر تکرار، یکی از مینی پروژه‌ها را تولید می‌­کنیم. RUP از دو بعد قابل بررسی است: فازها و نظام­‌ها (­جریان­‌های کاری­)

rup model

فازهای RUP

فاز 1: آغازین (Inception)

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

فاز 2: تحلیل جزئیات (Elaboration)

در این بخش ما اطمینان حاصل می‌کنیم که معماری، نیازمندی‌ها و طرح‌ها به اندازه‌ی کافی پایدارند و ریسک‌ها به اندازه‌ی کافی کاهش یافته‌اند. به طوری که بتوان هزینه و زمان‌‌بندی لازم برای تکمیل تولید را پیش‌بینی کرد.

فاز 3: ساخت (Construction)

فاز ساخت، در واقع به نوعی یک فرآیند ساخت است که در آن تأکید بر مدیریت منابع و کنترل عملیات به منظور بهینه‌سازی هزینه‌ها، زمان‌بندی‌ها و کیفیت است. به علاوه شامل کامل کردن تحلیل، طراحی، تولید و تست کارآیی مورد نیاز نیز است.

فاز 4: انتقال (Transition)

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

جریان‌های کاری RUP 

مدلسازی فعالیت‌های کسب و کار

هدف این جریان­‌کاری، الگوبرداری از زمینه شغلی، دامنه سیستم شما است. فعالیت‌های مدلسازی متداول، شامل موارد توسعه زیر است:

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

مدیریت خواسته‌­ها

هدف از این جریان کاری، مهندسی شرایط مورد نیاز پروژه شماست که شامل شناسایی، مدل­سازی و مستند­سازی الزامات است. تحویل اصلی این جریان کاری، مشخصات مورد نیاز نرم‌افزار (SRS) است که به آن الگوی مورد نیاز نیز گفته می­‌شود، که شامل الزامات ضبط شده است.

تحلیل و طراحی

هدف از این جریان کاری، تکامل یک معماری مستحکم براساس نیازمندی‌های سیستم شماست، به عبارت دیگر تبدیل الزامات به یک طرح و اطمینان از اینکه مسائل مربوط به محیط اجرا در طراحی شما منعکس شده است.

پیاده سازی

هدف از این جریان کاری:

  • پیاده سازی کلاس‌­ها و اشیاء از نظر مؤلفه‌­ها (پرونده‌­های منابع­، باینری ، اجرایی و …)
  • برای تست اجزای توسعه یافته به عنوان واحد
  • برای ادغام نتایج تولید شده توسط مجریان انفرادی (یا تیم‌ها) در یک سیستم اجرایی

آزمون

هدف از این جریان کاری:

  • بررسی تعامل بین اشیاء
  • بررسی یکپارچه‌سازی مناسب از تمام اجزای نرم‌افزار است
  • تأیید صحت اجرای همه الزامات
  • شناسایی و اطمینان از برطرف شدن نقص­‌ها قبل از استقرار نرم‌افزار

استقرار (Deployment)

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

  • تولید نسخه‌های خارجی نرم‌افزار
  • بسته‌بندی نرم‌افزار
  • توزیع نرم‌افزار
  • نصب نرم‌افزار
  • ارائه کمک و رسیدگی به کاربران

مدیریت پروژه

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

  • چارچوبی برای مدیریت پروژه‌های فشرده نرم‌افزاری.
  • راهنمای عملی برای پروژه‌های برنامه‌ریزی، نیروی انسانی، اجرا، و نظارت.
  • چارچوبی برای مدیریت ریسک.

مدیریت پیکربندی و تغییرات

این جریان کاری، دستورالعمل­‌هایی را برای مدیریت انواع مختلف سیستم‌های نرم‌افزاری در حال تحول، ردیابی نسخه­­‌های مورد استفاده در ساخت نرم‌افزارهای داده شده، اجرای برنامه­‌های فردی یا کل نسخه‌­ها با توجه به مشخصات نسخه تعریف شده توسط کاربر، و اجرای سیاست­‌های توسعه یافته را ارائه می­‌دهد.

آماده‌سازی محیط

هدف از این جریان کاری:

  • هدف از این جریان کاری ، فراهم کردن محیط توسعه نرم‌افزار – هم فرآیندها و هم ابزارها – در سازمان توسعه نرم‌افزار است که برای پشتیبانی از تیم توسعه مورد نیاز است.
  • محیط و شرایط را برای به کارگیری بانک الگو در پروژه آماده می­‌کند.
  • محیط را در طول یک تکرار پشتیبانی می‌­کند.

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

RUP methodology

مزایای اصلی این فرآیند عبارتند از:

به راحتی ریسک‌­ها را حل و فصل می­‌کند

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

تغییرات را کنترل می­‌کند

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

در برگیرنده الگوهای انعطاف‌پذیری است

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

پروژه کارآمدتری را تحویل می­‌دهد

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

از توسعه تکرار شونده حمایت می­‌کند

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

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

در ادامه، تفاوت بین متدولوژی RUP و اسکرام را بیان می­‌کنیم:

فرق بین متدولوژی RUP و اسکرام

هر دو روش از سری روش‌های چابک هستند و در فعالیت‌های پروژه از رویکردی تکرار شونده استفاده می­‌شود. با این حال، متدولوژی RUP  خواستار یک تعریف رسمی از هدف و نقاط عطف پروژه به همراه تاریخ‌های خاص است. ولی روش اسکرام از بک لاگ پروژه به جای هدف استفاده می‌­کند و این اجازه را می‌­دهد تا در پایان هر تکرار (معمولا هر 4 هفته) دوباره تعریف شوند. علاوه بر این، چرخه عمر پروژه‌هایRUP  به 4 فاز اصلی (آغازین، تحلیل جزئیات، ساخت، انتقال) تقسیم می­‌شود. این روش، مشوق جریان‌های کاری همزمان در سراسر چرخه است. در این روش، برخی فعالیت­‌ها در طول برخی مراحل به اوج خود می‌­رسد (به عنوان مثال: تجزیه و تحلیل نیازمندی‌­ها در مرحله تحلیل جزئیات افزایش می‌یابد). در مقابل، اسکرام حکم چرخه عمر “سنتی” متناسب با یک تکرار را دارد. به عبارت دیگر، برای هر تکرار یک حجم کاری در یک زمان تعیین می­‌شود، سپس کل چرخه در یک تکرار رخ می‌­دهد (به عنوان مثال: الزامات مورد نیاز برای یکی از ویژگی‌های خاص جمع‌آوری می­‌شود، مستند به عنوان یک داستان کاربر است که بعد از آن کدگذاری و سپس تست و در آخر، برای کاربر ارائه می‌شود).

سخن آخر

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

مطالب مشابه

ارسال نظر

آدرس ایمیل شما منتشر نخواهد شد.