مراحل آر.یو.پی
مرحله ۱ - آغازین (Inception)
پایه پروژه و ابعاد آن در این مرحله مشخص می‌شوند. در این مرحله پروژه به طور کلی بررسی شده و هزینه و درآمد ناشی از آن محاسبه می‌گردد. در این مرحله برداشتی اجمالی از ابعاد پروژه بدست می‌آید. در انتهای این مرحله تصمیم برای انجام یا عدم انجام پروژه اتخاذ خواهد شد و تعهد لازم از کارفرما تهیه می‌شود.
مرحله ۲ - تحلیل پیچیدگی (Elaboration)
در این مرحله جزئیات بیشتری از نیازهای سیستم را جمع‌آوری شده و درک بهتری از پروژه صورت می‌پذیرد. بدین ترتیب تحلیل و طراحی سطح بالایی از سیستم صورت گرفته پایه معماری اولیه سیستم بنا می‌شود. در این مرحله نقشه ساخت سیستم تولید شده است.
این مرحله با پرسشهایی نظیر: در حال ساخت چه سیستمی هستیم؟ چه چیزهایی پروژه را به مخاطره می‌اندازد و چه ریسکهایی برای انجام آن وجود دارد. هر چه ریسکها بیشتر و بزرگ‌تر باشند، دقت بیشتری در انجام پروژه باید صورت گیرد.

بررسی ریسک‌ها:
ریسک‌های مرتبط با نیازمندیهای سیستم
هدف رسیدن به سیستمی است که خواسته‌های کاربر را به درستی انجام دهد. مهم است که این نیازمندیها به درستی درک شده باشند. در اینجا استفاده صحیح از یو.ام.ال میتواند بسیار موثر باشد. یوزکیس‌ها ابزارهای مهمی هستند زیرا تقابل کاربر با سیستم را بطور دقیق مشخص می‌کنند و اساس ارتباط کارفرما با تولیدکننده نرم‌افزار هستند. باید مهم‌ترین و پرخطرترین یوزکیس‌ها به طور مشخص تعیین شوند. هر چه بیشتر با کاربران نهایی سیستم مذاکره شود نتایج بهتری حاصل خواهند گشت. لازم است نمونه‌های اولیه برای قسمت‌های پیچیده و حیاتی یوزکیس‌ها باید ساخته شوند.
در همین زمان سایر نمودارهای مدلسازی نظیر نمودارهای کلاس (Class Diagrams)، نمودارهای فعالیت (Activity Diagram) و نمودارهای تقابل (Interaction Diagrams) نیز به کمک کاربران سیستم بخصوص کاربران ارشد که اطلاعات بیشتر و مهم‌تری از عملکرد سیستم دارند باید تهیه شوند.

ریسک‌های تکنولوژیکی:
از خود می‌پرسیم، آیا تکنولوژی لازم برای ساختن این سیستم را در اختیار داریم؟ باید نمونه‌های اولیه‌ای از سیستم ساخته شده و عملکرد آنها تحت سیستم پیش‌بینی شده بررسی گردد. طراحی معماری سیستم در این مرحله صورت می‌گیرد. باید اجزا تشکیل دهنده سیستم، روش ساخت یا تهیه و طریقه اتصال آنها به یکدیگر مشخص شوند. بهتر از قسمت‌هایی که تغییر آنها سخت‌تر (یا غیرممکن) است در این فاز مدنظر قرار گرفته شوند تا در صورت عدم هماهنگی در همین مرحله تصمیمات مناسب اتخاذ شوند.
طراحی سیستم باید بگونه‌ای باشد که در آینده تغییرات و توسعه آن قابل انجام باشد. باید یوزکیس‌ها را بطور دقیق بررسی کنیم تا مسائلی که ممکن است طراحی سیستم را پیچیده‌تر کنند به طور واضح مشخص گردند.
نمودارهای یو.ام.ال زیر در این مرحله بکار می‌آیند:
نمودارهای کلاس و نمودارهای تقابل: اجزاء سیستم (Components) و نحوه تقابل آنها را نشان می‌دهند.
نمودارهای بسته بندی (Package Diagrams): یک دید سطح بالا از اجزاء سیستم فراهم می‌آورند.
نمودارهای گسترش (Deployment Diagrams): تصویری از چگونگی توزیع (پراکندگی) اجزاء سیستم نشان می‌دهند.

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

ریسک‌های سیاسی
هرچند در نگاه اول ممکن است عجیب به نظر برسد، ولی با رشد روزافزون رایانه‌ها و سیستم‌های مبتنی بر رایانه امکان بروز تعارض میان سیستم نرم‌افزاری ساخته شده و مسائل امنیتی وجود دارد. بهتر است در مورد یوزکیس‌هایی که با مردم جامعه یا سازمانها (بخصوص سازمانهای دولتی) تعامل خواهند داشت در همین مرحله سیاستهای واضحی مشخص گردد.

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

مرحله ۳ - ساخت (Construction)
این مرحله به روش افزایش-تکرار صورت می‌گیرد. به این معنی که بر خلاف روشهایی مانند توسعه آبشاری (SSADM) که ممکن است در برخی زمانها بعضی از اعضای تیم به دلیل انتظار برای دریافت نتیجه گروهی دیگر از اعضای تیم بیکار بمانند، در آر.یو.پی اساس کار بر تولید قطعات سیستم به صورت مرحله به مرحله است و در هر مرحله عملکرد قطعه تولید شده بهبود می‌یابد. لذا پس از به جریان افتادن فرآیند اعضای تیم بیکار نمانده و به افزایش حجم و دقت عملکرد قطعه تولیدی قبلی خود می‌پردازند.
دقت شود که هر قطعه تولید شده خود یک نرم‌افزار نسبتاً کامل بوده و باید توانایی برآورده کردن نیازهای مشخصی را داشته باشد، بدین معنی که قطعات تولید شده باید قابل استفاده باشند.
برای تولید هر قطعه تمام این چهار مرحله انجام شده است! این نکته مهمی در آر.یو.پی است و میتوان اینگونه در نظر گرفت که محصول نهایی به شکل یک پیاز بوده و دارای لایه هایی است که هم برای تولید هر لایه و هم برای تولید کل پیاز این مراحل چهارگانه صورت گرفته‌اند.
بطور خلاصه نتیجه این فاز کدنویسی و ایجاد نرم افزار است

مرحله ۴ - انتقال (Transition)
مرحله نهایی که شامل تست آزمایشی، بهبود عملکرد و آموزش کاربران است.

مشخصات تئوریRUP نسبت به SSADM متفاوت است:
1- دیدگاه دو بعدی نسبت به تقسیم بندی و پیشبرد مراحل تحلیل.
2- مبنا قرار گرفتن موجودیت(شئ) به جای روال ها و پروسه های کاری.
3- استناد بیشتر فاز طراحی به فازهای اولیه در RUP.
4- نزدیکی کامل مستند سازی سیستم به کلیه فازهای تحلیل.
5- همکامی بیشتر با تکنیکهاو مفاهیم پیاده سازی جدید.
6- کاربری بیشتر در تحلیل سیستمهایی که منجر به ایجاد یک سیستم نرمافزاری نمی شود.
تشابهات:
1- مشخص شدن ساختار(ایستا)سیستم
2- مشخص شدن رفتار (پویا)سیستم
3- مشخص شدن عوامل/ اطلاعات(موجودیتهای اطلاعاتی)در جریان گردش کار سیستم
تشریح فازهای مختلف در تئوری RUP:
بر اساس تئوری RUPدر هر یک از مراحل 6گانه اصلی یک سری مفاهیم قوانین و دستورالعمل های پایه ای وجود دارند.

مفاهیم:
Activity:
فعالیت هایی که اریوپی برای درست انجام شدن هر مرحله پیشنهاد می کند.
Artifcat:
هر سند،محصول و ... که در هر مرحله از انجام کار تولید می شود.
Worker:
افرادی که در هر مرحله فعالیت میکنندو یک سری سند با محصول محسوس تولید می کنند.
Guide Line:
راهبرد انجام کار که نحوه انجام و ممیزی هر کاری را مشخص می کند.برای خیلی ازARTIFACTها به خصوص در مرحله تحلیل و طراحیGUIDLINE وجود دارد.
Checkpoint:
سندی است که جهت ارزیابی هرARTIFACT بکار می رود.
TOOLMENTOR:
سندی است که نحوه انجام هر را با ابزار مشخصی توضیح می دهد(فعالیت های که ابزار مکانیزه دارند).
Business Modeling:
این فرایند ممکن است با اهداف زیر صورت گیرد:
1- استخراج ماژول ها و سازماندهی کاری(چارت سازمانی)
2- Domain Modelingشناخت دامنه کاری سازمان
3- One Business many System
شناخت اجزا سازمان(واحد ها، پروسه ها. پروژه ها، شغل ها، نقش ها ، جریانهای گردش کار،جریانهای گردش اسناد و...) جهت مکانیزه نمودن سیستم با طراحی سیستم های کامپیوتر و غیر کامپیوتری مختلف.
4-Business Generation
وقتی هدف تولید بسته های نرم افزاری چند کاربره برای سازمانهای مختلف می باشند.
5-New Business
سازمان می خواهد از فن آوری جدید، شغل جدید و هر چیز تازه ای که به سیستم و روال کاری جاری اضافه شود،استفاده کند.
6-Reorganization
هنگامی که یک سازمان بخواهد در جهت شناخت مشکلات سیستم جاری/ ایجاد تحول در سیستم جاری/ آزمایش سیستم جدید فعالیت نماید
در این بخش وضعیت سیستم از دیدگاه درون سیستم(Business Use case Modeling) و بیرون از سیستم Business Object Modeling)) مورد بررسی قرار می گیرد.
RUP یک متدولژی هست وUML زبان مدلسازی. و قیاس این دو مع الفارق است .
میشه متدولژی RUP رو با سایر متدولژی ها مثل SSADM یا XP مقایسه کرد گرچه معمولا در مباحث مهندسی نرم افزار (SE) هم بحث uml هست هم rup .ولی این دو کاملا مستقل هستند یعنی شما برای رسم دیاگرامهای UML احتیاجی نیست حتما از متدولژی RUP استفاده کنید .فقط کافیست متدولژی و طراحی شما باید OO (شی گرا) باشد.
شاید هم این خلط به خاطر این باشه که تو ایران از ابزارهای رشنال فقط rose جا افتاده در حالی که ابزارهای مختلفی برای BM , requirement management , analyse ,... توی پک کامل Rational Suite هست .
به طور خلاصه میشه گفت که RUP مجموعه روشها و دیدگاههای شناختی لازم برای شناخت ، نیاز سنجی ، تحلیل ، طراحی ، پیاده سازی و تست و نصب یه محصول نرم افزاری رو ارائه میده . ولی UML (متشکل از تعدادی دیاگرام) مربوط به زمانی هست که Business شنا خته شده و حال برای مدلسازی view ما از سیستم متوسل به این دیاکرامها می شویم .
در واقع برای هرکدام از فازهای RUP دو یا سه دیاگرام UML می تواند کار ساز باشد .(بیشتر از همه طراحی ) اما فقط برای ترسیم یک مدل به آنچه از سیستم رسیده ایم :idea: یعنی UML چگونگی رسیدن به این شناختها و تشخیص ها را قرار نیست مشخص کند ولی RUP سعی در ارائه چنین ساز و کاری دارد . البته برای مدلینگ آنچه RUP در هر فاز ارایه میدهد نیز بهترین استاندارد مدلسازی شاید UML باشد.

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

مراجع و منابع
________________________________________
Booch, G., J. Rumbaugh and I. Jacobson. 1999. The Unified Modeling Language User Guide. Addison- Wesley.
COSMIC Group. 2003a. Valve Control System - Cosmic Group Case Study. École de technologie supérieure, Université du Québec, Montréal, Canada, January 25, 2003 version http://www.lrgl.uqam.ca/cosmic-ffp/casestudies/
COSMIC Group. 2003b. Rice Cooker - Cosmic Group Case Study. École de technologie supérieure, Université du Québec, Montréal, Canada, Janua ry 26, 2003 version http://www.lrgl.uqam.ca/cosmic-ffp/casestudies/
Jenner, M. 2002. Automation of Counting of Functional Size Using COSMIC-FFP in UML. 12th International Workshop on Software Measurement - IWSM 2002, Magdeburg, Germany, Oct. 7-9, 43-51.
Kruchten, P. 2000. The Rational Unified Process, an introduction. Addison Wesley.
Kruchten, P. 2003. The RUP platform. Montréal-SPIN . November, 33.
Schewe, K.D. 2000. UML: A Modern Dinosaur? A Critical Analysis of the Unified Modeling Language. Proc. 10th European-Japanese Conf. on Information Modeling and Knowledge Bases. Saariselk/Finland.
سایت شرکت آی‌بی‌ام
مشارکت‌کنندگان ویکی‌پدیا، «IBM Rational Unified Process»، ویکی‌پدیای انگلیسی، دانشنامهٔ آزاد. (بازیابی در ۲۳ آوریل ۲۰۰۷).
component-based software
کتاب الکترونیکی مروری بر آر.یو.پی (RUP Overview)
معماری نرم‌افزار و مهندسی فرآیند
فرآیند یکپارچه توسعه چیست؟
• آکادمی نرم‌افزار (Software Academy)

پی‌نوشت‌ها
________________________________________
• 1. Rational Unified Process
• 2. Structured System Analysis and Design Method
• 3. waterfall
• 4. Unified Modeling Language
• 5. Process Framework
• 6. Component Base Development (CBD)
• 7. workflow
• 8. Development case

http://www.parsianstar.com/2010-04-01-09-50-22/40-downlod-computer/158-rational-unified-process?start=1