RUP چیست؟
RUP چیست؟
با پیشرفت تکنولوژی‌های مرتبط با کامپیوتر، نیاز هر چه بیشتر به گسترش علم نرم‌افزاری نیز احساس می‌شد که با پیدایش متدولوژیهای همانند SSADM 2 و روش آبشاری3 (چیو 2000) آغاز شد. در ابتدا، این روشها مناسب بود و جوابگوی نیازهای آن زمان بودند ولی با افزایش داده‌ها و پیدایش مفاهیمی همچون شبکه، وب و غیره دیگر کارآیی لازم را جهت پیاده‌سازی و هدایت پروژه‌های نرم‌افزاری نداشتند. پس مفاهیم برنامه‌نویسی شیءگرا پا به عرصه وجود گذاشتند و در سال 1991 بطور جدی مورد مطالعه و بحث قرار گرفتند. استفاده از این روشها و متدهای برنامه‌نویسی، قدرت و انعطاف بسیاری را به برنامه‌ها داد و شرکتهای نرم‌افزاری توانستند با کاهش هزینه‌ها و بهینه‌سازی کدهای خود، نرم‌افزارهای قویتری را به بازار عرضه کنند ولی این روش جدید نیز نیاز به مدیریت و یکپارچگی داشت. پس روشها و متدولوژیهای جدیدی مطرح شد که شامل Booch، OMT، OSE و ... می‌باشند. در سال 2000 شرکت Rational روشی را تحت عنوان RUP مطرح ساخت (گروه کاسمیک 2003ب) که بعد از روش MSF شرکت مایکروسافت به دنیای نرم‌افزار عرضه شد و امروزه از طرفداران بسیاری برخوردار است. فرایند یکپارچه Rational در اصل یک متدولوژی است که در جهت کنترل و انجام پروژه‌های نرم‌افزاری در نظر گرفته شده است. در اصل این چارچوبی در جهت انجام صحیح و موفق پروژه‌های نرم‌افزاری می‌باشد که کلیه مراحل انجام یک پروژه که با معماری و آنالیز سازمان شروع شده و به تست نرم‌افزار و ارائه Gold Release ختم می‌شود را در بر می‌گیرد (گروه کاسمیک 2003 الف).
چرا RUP را یک فرایند یکپارچه می‌گویند؟ به سه علت RUP را یکپارچه می‌نامند:
این متدولوژی از یکپارچه‌سازی سه متدولوژی معروف دیگر بوجود آمده است که شامل Booch، OMT و OSE می‌باشد.
از UML4 در جهت کارهای خود استفاده می‌کند. در واقع می‌توان گفت UML خود ثمره RUP می‌باشد و این خود بسیار خوب است که متدولوژیی با خودش گسترش یابد (گروه کاسمیک 2003الف). مفاهیمی از قبیل Object، Class و ... مفاهیم ساده و ثابتی هستند ولی قبلاً متدولوژیها علامتهای خاصی داشتند که اکنون همه آنها یکسان شده‌اند.
در داخل RUP یک چارچوب تولید نرم‌افزار است که ما آنرا برای سازمان و پروژه خود بومی می‌کنیم و می‌توان گفت که در واقع یک قالب فرایند5 است.
بخش دوم :
خصوصیات RUP چیست؟
RUP مبتنی بر نوعی معماری است که به اجزاء اصلی می‌پردازد ولی طراحی به جزئیات نیز وارد می‌شود. همچنین می‌توان گفت معماری یکسری اجزا و ارتباط بین آنها است که سیستم را می‌سازد و ما را به سمت توسعه مؤلفه‌محور6 راهنمایی می‌کند.
ویژگی Usecase Driven: یکی از مشکلات OOA این بود که می‌گفتند با هر روشی تبدیل و کار کنند و بعد بتوان آنرا به شیءگرا تبدیل کرد. یعنی مثلاً پروژه SSADM را طراحی کرده و بعداً به شیءگرا تبدیل نمود. ولی آن عقیده اشتباه بود و حتماً تحلیل شیءگرا باید صورت بگیرد. خصوصیت خوب شیءگرا که در دیگر روشها نمی‌باشد این است که نوتاسیونی که استفاده می‌شود (بوچ، رامباق و جاکوبسون 1999) در همه مراحل یکی است یعنی مفاهیمی از قبیل شیء، کلاس، روابط کلاسها و ... در تمامی مراحل یکی است. اهمیتی که Usecase Driven دارد این است که با زبان مشتری نوشته می‌شود. مشتری می‌تواند آنرا بفهمد و بسیار مناسب برای تشخیص نیازمندیهای سیستم می‌باشد. در بخش تحلیل و طراحی از روی Usecaseها تحلیل و طراحی انجام می‌دهیم و مسائلی مانند مدیریت پروژه نیز تحت تاثیر Usecaseها هستند که ما آنها را دسته‌بندی کرده و مدیریت می‌کنیم. همچنین راهنماهای سیستم هم تحت تاثیر Usecaseها (کراچتن 2000، 298) ایجاد می‌شوند.
ویژگی Incremental: به معنی آن است که پروژه بصورت چهار مرحله حلقه‌ای جلو می‌رود ولی در هر مرحله چرخش یک دسته از Usecaseها کامل و آماده استفاده می‌شود و کلیه این کارها در 9 جریان کار7 که در شکل 1 مشخص شده بود، قابل مشاهده است.
دیدگاه اولیه درباره RUP
دیدگاهی که RUP بر اساس آن طراحی شده، به گونه‌ای است که محدوده وسیعی از اهداف را پوشش دهد تا ضمانت اجرایی جهت انطباق با موارد زیر حاصل شود (کراچتن 2003):
ابعاد پروژه
حوزه کاربردی برنامه (سیستمهای تجاری یا سیستمهای فنی)
زمینه‌های تجارت (توسعه خانگی، توسعه محصولات، فروشندگان نرم‌افزار مستقل، توسعه قراردادی).
همانند هر ساختار پروسه دیگری، RUP نیز روش سیستماتیکی را برای به دست آوردن، سازماندهی و ارائه راهکارهای مهندسی نرم‌افزار در اختیارتان قرار می‌دهد. RUP برای سازماندهی راهکارها، بر یک مدل پروسه ساده و کاملاً زیربنایی استوار شده است که توضیح این امر در قالب چند مقاله یا کتاب نمی‌گنجد.
با این وجود، ساختار پروسه مزبور را نمی‌توان به یک ظرف خالی تشبیه نمود. این ساختار از قبل توسط حجم عظیمی از پروسه‌های راهکاری که قبلاً در پانزده سال گذشته توسط ملیت‌های مختلف تحصیل شده است و با شرکت Rational ارتباط داشته‌‌اند (افرادی که قبلاً این شرکت آنها را به خود جذب کرده و برخی از شرکای این شرکت نظیر IBM ، HP و BEA (کراچتن 2003)) انباشته گردیده است. RUP مجموعه محدود و بسته‌ای نیست که به منظور کاربردهای عمومی منتشر شده باشد و پاسخ یا راه‌حل تمامی مشکلات توسعه نرم‌افزاری را دربرگیرد؛ بلکه ساختار RUP ساختار بازی است که به منظور استنتاج باید شاخه‌های آنرا دنبال کنید و این ساختار سالانه دوبار روزآمد می‌گردد. ساختار RUP تصفیه شده است و پشتیبانی ابزاری و مندرجات آن نیز توسعه یافته‌اند.
از یک سو، گروه توسعه پروسه شرکت Rational، امر به روز سازی محتویات RUP را همگام با مقتضیات فن‌آوری و بازخوردهایی که کاربران این ساختار ارائه می‌دهند، به عهده دارند و از سوی دیگر شرکای متعدد این شرکت و افرادی که RUP را برای استحصال و سازماندهی فرایندهای راهکاری خود پذیرفته‌اند و از آن برای اهداف مربوط به خود استفاده می‌کنند، ساختار ارائه شده توسط شرکت Rational را تبلیغ نموده و آنرا را تکمیل می‌کنند.
ساختار RUP پیرامون چند منطق ساده و مرتبط به هم سازماندهی شده است:
RUP نقشهایی را تعریف می‌کند که باید در پروسه وجود داشته باشد و بر مبنای آن، صلاحیتها، تخصصها و مسئولیتهای افرادی که باید پیشرفت پروژه را محقق سازند، مشخص می‌شود.
RUP کارهایی را که هر یک از افراد باید در عمل انجام دهند، به طور گام به گام تشریح می‌کند.
این عملیات با استفاده از ابزارهایی واقعی مانند مدل‌ها، کدها، اسناد و گزارشها اداره می‌شوند.
در RUP به وفور با راهنماییهای مربوط به نقشهایی که افراد باید به عهده بگیرند، فعالیتهایی که باید انجام شوند و مصنوعات مورد نیاز برخورد خواهید نمود که در قالب خطوط راهنما، الگوها، مثالها و معلمهای ابزاری ارائه می‌شوند که چگونگی به وقوع پیوستن دسته‌ای از فعالیتها توسط یک ابزار بخصوص را شرح می‌دهند.
تمامی این المانهای توصیف پروسه در قالب سامانه‌هایی سازماندهی شده‌اند.
RUP مقدماتی نه سامانه، بیش از چهل نقش و صد محصول را تعریف می‌کند و حاوی بیش از هزار صفحه راهنما است. همچنین میتوانید به پروسه‌های الحاقی متعددی که وظایف و مندرجات بیشتری را به RUP اضافه می‌کند، دسترسی پیدا کنید. برخی از منتقدین RUP آنرا پروسه‌ای بسیار سنگین تصور نموده و آنرا به کرگدنی تشبیه می‌کنند که توان انجام تعداد نامحدودی عمل غیر معمول را برای شما فراهم می‌آورد؛ با این وجود نگاه ما به RUP همانند لوح باشکوهی از معارف است که میتوانید آنچه را که نیاز دارید، از داخل آن برگزینید.
اجازه بدهید مقایسه‌ای انجام دهیم. اگر فرهنگ لغات مناسبی از 800 لغت را انتخاب کرده باشید، میتوانید در خیلی از نقاط دنیا و در بسیاری شرایط، گلیم خود را از آب بیرون بکشید؛ ولی با انتخاب فرهنگ لغات حجیمی چون Webster ، اولاً هیچ‌کس شما را مجبور به استفاده از لغاتی که در فرهنگ لغات وجود دارد نمی‌کند، ثانیاً میتوانید سطح لغات محفوظی خود را برای انطباق با وضعیتهای مختلف ارتقا ببخشید و ثالثاً میتوانید فرهنگ لغات خود را بهبود دهید. فرهنگ لغت800 لغتی باید فقط زیرمجموعه‌ای از یک فرهنگ لغات باشد.
انعطاف‌پذیری RUP و انطباق با آن
RUP یک اصل عقیدتی یا یک آیین مذهبی نیست. ساختار RUP ساختار خشکی نیست که بخواهد همه چیز را برای تولید نرم‌افزار در قالب خود درآورد. نیازی نیست که حداقل چهل نفر را برای تکمیل پروسه‌ای که چهل نقش در آن تعریف شده است، به خدمت بگیرید و نیازی ندارید که بیش از صد محصول مختلف را پرورش دهید. اگر سعی خود را به انجام این کار معطوف سازید، خیلی زود در معرض آشفتگی قرار خواهید گرفت. این المانها در RUP و در فرم الکترونیکی (کراچتن 2003) برای فراهم‌آوردن انعطاف‌پذیری مورد نیاز برای انطباق با تقاضایی ارائه شده‌اند که به شرایط محیطی که درآن به سر می‌برید، بستگی دارد.
RUP تمرینات تولید نرم‌افزار ثابت شده فراوانی را در بردارد. شرکت Rational میدان دید بالایی را برای موارد زیر، ارائه می‌دهد:
توسعه مکرر
مدل‌سازی بصری
مدیریت ملزومات تغییرات کنترل
بازبینی مداوم کیفیت
استفاده از معماری بر مبنای اجزا
همچنین URP بر مبنای دیگر اصول کلیدی دیگری که کمتر قابل مشاهده هستند و ساده‌تر به محاق فراموشی سپرده می‌شوند، استوار شده است که فقط برای یادآوری اشاره‌ای به آنها می‌نماییم (جنر 2002):
منحصراً آنچه را که مورد نیاز است، پرورش دهید.
روی نتایج ارزشمند تمرکز کنید، نه روی چگونگی حصول نتایج
کاغذبازی را به حداقل برسانید.
انعطاف‌پذیر باشید.
از اشتباهات خود عبرت بگیرید.
به طور منظم، مخاطرات محتمل را مورد بازبینی قرار دهید.
برای پروسه موردنظر معیارهای قابل اندازه‌گیری و علمی را بدون موضع‌گیری شخصی استوار کنید.
از گروه‌های کوچک و توانمند استفاده کنید.
طرحی را در ذهن داشته باشید.
ذهنیت کلیدی در سازگار شدن و سازگار کردن RUP قالب توسعه8 می‌باشد. یک قالب توسعه نمونه‌ای از RUP است که برای پروژه ویژه‌‌ای که مد نظرتان است، مناسب باشد. با مراجعه به ساختار RUP به توضیح پروسه‌ای دست می‌یابید که موارد زیر را تعریف نموده و شناسایی می‌کند (جنر 2002):
چه چیزی توسعه داده خواهد شد؟
به چه مصنوعاتی واقعاً نیاز داریم؟
چه الگوهایی باید مورد استفاده قرار بگیرند؟
کدام مصنوعات در حال حاضر وجود دارند؟
به چه نقشهایی نیاز داریم؟
چه فعالیتهایی انجام خواهند شد؟
کدام خطوط راهنما، استانداردهای پروژه و ابزارهایی مورد استفاده قرار خواهند گرفت؟
نتیجه گیری
از آنچه گذشت در می‌یابیم اولاً در حال حاضر تنها روش توسعه نرم‌افزاری که مورد پذیرش در عرصه جهانی است، RUP می‌باشد. ثانیاً این روش علاوه بر ساماندهی به فرایند تولید نرم‌افزار از دو بعد زمان و کیفیت، به لحاظ برخورداری از انعطاف‌پذیری بالا در صورت کاربرد و پیاده سازی صحیح می‌تواند سبب تسریع فرایند تولید و توسعه نرم‌افزار و تأمین کیفیت مورد نظر در نرم‌افزار گردد و نهایتاً این که یکی از مهم ترین ویژگی‌های RUP این است که قابلیت توسعه و تغییر نرم‌افزار ها را بر اساس تغییر نیازهای کاربران و نیز تغییر فناوری، از قبل پیش بینی نموده است.
بخش سوم :
معماری و ساختار کلی RUP
نویسنده: سید مصطفی حسینی
فرایند انجام یک پروژه تعریف می‌کند که چه کسی، چه کاری را در چه هنگام و چگونه برای رسیدن به هدف (انجام پروژه) انجام می‌دهد.
در مهندسی نرم‌افزار، هدف ساختن یک محصول نرم‌افزاری و یا بهبود یک نمونه‌ی موجود است. هدف از تعیین فرایند، تضمین کیفیت نرم‌افزار، برآورده شدن نیازهای کاربر و قابل تخمین بودن زمان و هزینه‌ی تولید می‌باشد. علاوه بر این، تعیین فرایند، روندی جهت تحویل مصنوعات دوران تولید نرم‌افزار به کارفرما و ناظر پروژه ارائه می‌دهد تا از این طریق اطمینان حاصل کنند که پروژه روند منطقی خود را طی می‌کند و نظارت درست بر انجام پروژه ممکن است و از سوی دیگر، معیاری برای ارزیابی پروژه انجام شده می‌باشد. تا کنون متدولوژیهای مختلفی برای فرآیند تولید نرم‌افزار ارائه شده‌اند که یکی از مشهورترین آنها RUP است.
RUP، متدولوژی ارائه شده توسط شرکت Rational، پرکاربردترین فرآیند تولید و توسعه نرم افزاری در دنیای کنونی است و به عنوان یک استاندارد صنعتی بالفعل در دنیای IT پذیرفته شده است. به گزارش رویتر در سال 2001 میلادی بیش از ششصد هزار شرکت تولید کننده نرم افزار، از ابزارهای شرکت Rational استفاده می کرده‌اند که این تعداد کماکان هم در حال افزایش است. این متدولوژی، برای انواع پروژه‌های نرم‌افزاری در دامنه‌های مختلف ( مانند سیستمهای اطلاعاتی، سیستمهای صنعتی، سیستمهای بلادرنگ، سیستمهای تعبیه شده، ارتباطات راه دور، سیستمهای نظامی و ...) و در اندازه‌های متفاوت، از پروژه‌های بسیار کوچک (یک نفر در یک هفته) تا پروژه‌های بسیار بزرگ (چند صد نفر تولید کننده با پراکندگی جغرافیایی)، کاربرد دارد.
مزیت بزرگ این متدولوژی، استفاده از روش تکرار در تولید و مدیریت تولید نرم‌افزار است که این امر، امکان تولید مبتنی بر کاهش ریسک و مواجه با مشکلات اصلی در ابتدای کار و در نتیجه احتمال موفقیت بیشتر را فراهم می‌کند. از محاسن دیگر این متدولوژی مبنا قرار دادن نرم‌افزار و تولید یک معماری پایدار در ابتدای کار است، که در نتیجه امکان کشف مشکلات عمده ساختاری، تست و مجتمع سازی ممتد را از ابتدای کار فراهم می‌کند.
از دیگر مزایای این روش این است که افراد تیم همزمان با پیشرفت پروژه، مطالب جدیدی فرا می‌گیرند و کیفیت فرآیند تولید نیز به طور مرتب افزایش می‌یابد.
بخش چهارم :
فازهای RUP
Inception (آغازین)
هدف اصلی این فاز دستیابی به توافق میان کلیه‌ی ذینفعان بر روی اهداف چرخه‌ی حیات پروژه است. فاز Inception به دلیل تلاشهای تولید و توسعه جدید به صورت پایه‌ای اهمیت فراوانی دارد که در آن ریسک‌های نیازسنجی و تجاری مهمی وجود دارد که باید پیش از اینکه اجرای پروژه مورد توجه قرار گیرد، بررسی شوند. برای پروژه‌هایی که بر توسعه سیستم موجود متمرکزند، فاز Inception کوتاه تر است، با این حال این فاز برای حصول اطمینان از اینکه پروژه ارزش انجام دادن دارد و امکان‌پذیر نیز هست، انجام می‌شود. اهداف اصلی فاز آغازین شامل موارد زیر است :
• بدست آوردن محدوده نرم‌افزاری پروژه و محدودیت‌های آن که شامل یک دید عملیاتی، معیار پذیرش و اینکه چه چیز باید در محصول باشد و چه چیز نباید باشد، می‌شود
• مشخص کردن Use-Case های اساسی سیستم، سناریوهای اصلی عملیات که مسائل مربوط به طراحی اصلی را ایجاد می‌کند.
• نمایش و شاید توضیح حداقل یک معماری کاندیدا برای بعضی سناریوهای اصلی
• برآورد هزینه و زمان کلی برای کل پروژه
زینب