دانلود تحقیق فرآیند یکپارچه رشنال یا آریوپی-Rational Unified Process

چه چیز می‌تواند یک پروسه تولید نرم‌افزار را توصیف کند؟

آیا منظور از پروسه، آماده‌سازی نرم‌افزار صرفاً برای ارائه در بازار است؟

مسلماً در هر کاری وجود یک سامانه و فرایند کاری ضروری است؛ ولی چه چیزی می‌تواند موجب ایجاد سرعت و کیفیت در فرایند تولید یک نرم‌افزارشود؟

لزوماً طراحی و پیاده‌سازی یک فرایند یکپارچه و منطقی می‌تواند چنین نتیجه‌ای در بر داشته باشد.

بدین منظور امروزه از روشی استفاده می‌شود که اصطلاحاً RUP نامیده می‌شود.

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

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

RUP با ارائه یک چارچوب منطقی علاوه بر تعیین زمانبندی مناسب، کیفیت مورد نظر تولید کننده و استفاده کننده نرم‌افزار را تأمین می‌نماید.

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

یک پروسه چابک، پروسه‌ای است که همیشه آماده در آغوش کشیدن درخواستهای جامعه بوده و این درجه از سازگاری را دارا باشد.

بنابراین منظور از سرعت عمل، فقط کاستن از حجم پروسه تولید نرم‌افزار یا سرعت ارائه آن به بازار نیست؛ بلکه منظور، انعطاف‌پذیری و حفظ کیفیت است.

مطلبی که در این مقاله قصد
توضیح آن را داریم این است که RUP 1 ساختاری پروسه‌ای (چیو 2000) است که امکان انعطاف‌پذیری را برای تولید‌کنندگان نرم‌افزار فراهم می‌آورد.
منظور از RUP چیست؟

در این مقاله از چند منظر به RUP خواهیم پرداخت:
 RUP یک پروسه تولید نرم‌افزار است.

 RUP مجموعه‌ای از تجربیات بسیار عالی تولید نرم‌افزار را که در عمل با آنها برخورد شده است، در خود دارد.

 RUP همانند یک محصول نرم‌افزاری به بازار ارائه شده و به فروش می‌رسد با این تفاوت که RUP اولین ساختار تولید نرم‌افزار را ارائه داده و گام نخست را در این زمینه برداشته است.
RUP چیست؟
با پیشرفت تکنولوژی‌های مرتبط با کامپیوتر، نیاز هر چه بیشتر به گسترش علم نرم‌افزاری نیز احساس می‌شد که با پیدایش متدولوژیهای همانند SSADM 2 و روش آبشاری3 (چیو 2000) ‎آغاز شد.

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

پس مفاهیم برنامه‌نویسی شیءگرا پا به عرصه وجود گذاشتند و در سال 1991 بطور جدی مورد مطالعه و بحث قرار گرفتند.

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

پس روشها و متدولوژیهای جدیدی مطرح شد که شامل Booch، OMT، OSE و ...

می‌باشند.

در سال 2000 شرکت Rational روشی را تحت عنوان RUP مطرح ساخت (گروه کاسمیک 2003ب) که بعد از روش MSF شرکت مایکروسافت به دنیای نرم‌افزار عرضه شد و امروزه از طرفداران بسیاری برخوردار است.

فرایند یکپارچه Rational در اصل یک متدولوژی است که در جهت کنترل و انجام پروژه‌های نرم‌افزاری در نظر گرفته شده است.

در اصل این چارچوبی در جهت انجام صحیح و موفق پروژه‌های نرم‌افزاری می‌باشد که کلیه مراحل انجام یک پروژه که با معماری و آنالیز سازمان شروع شده و به تست نرم‌افزار و ارائه Gold Release ختم می‌شود را در بر می‌گیرد (گروه کاسمیک 2003 الف).
با پیشرفت تکنولوژی‌های مرتبط با کامپیوتر، نیاز هر چه بیشتر به گسترش علم نرم‌افزاری نیز احساس می‌شد که با پیدایش متدولوژیهای همانند SSADM 2 و روش آبشاری3 (چیو 2000) ‎آغاز شد.

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

چرا RUP را یک فرایند یکپارچه می‌گویند؟

به سه علت RUP را یکپارچه می‌نامند: این متدولوژی از یکپارچه‌سازی سه متدولوژی معروف دیگر بوجود آمده است که شامل Booch، OMT و OSE می‌باشد.

از UML4 در جهت کارهای خود استفاده می‌کند.

در واقع می‌توان گفت UML خود ثمره RUP می‌باشد و این خود بسیار خوب است که متدولوژیی با خودش گسترش یابد (گروه کاسمیک 2003الف).

مفاهیمی از قبیل Object، Class و ...

مفاهیم ساده و ثابتی هستند ولی قبلاً متدولوژیها علامتهای خاصی داشتند که اکنون همه آنها یکسان شده‌اند.

در داخل RUP یک چارچوب تولید نرم‌افزار است که ما آنرا برای سازمان و پروژه خود بومی می‌کنیم و می‌توان گفت که در واقع یک قالب فرایند5 است.

Rup شامل 4 فاز می‌باشد و اگر در هر لحظه به آن نگاه کنیم شامل 9 قالب خواهد بود.

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

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

از آنجا که تمام افراد به منابع یکسانی دسترسی دارند، لذا دید مشترکی برای توسعه نرم‌افزار برخوردار هستند.

آر.یو.پی امکان استفاده موثرتری از زبان یکپارچه مدلسازی (UML) را فراهم می‌سازد (دقت شود که در عین حال آر.یو.پی و یو.ام.ال کاملاً مستقل از یکدیگر هستند و نباید آنها را با هم یکی فرض کنیم).

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

این فرآیند با موقعیت‌های مختلف تطبیق یافته و برای سازمانهای بزرگ یا حتی کوچک تولید و توسعه نرم‌افزار قابل استفاده است.

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

چرا آر.یو.پی را یکپارچه نامیده‌اند: این فرآیند از ترکیب و یکپارچه‌سازی چند فرآیند و متدولوژی شامل Booch، OMT و OSE دیگر ایجاد شده است.

از زبان یکپارچه مدلسازی (UML) به طور موثری بهره می‌گیرد.

مفاهیمی نظیر کلاس و شیء در متدهای قبلی علائم خاص و مختلفی داشته‌اند حال آنکه در آر.یو.پی یکسان شده‌اند.

حرفه ها وتخصص ها به منظور بررسی(شناخت،آنالیز، نیاز سنجی،طراحی، پیاده سازی و...)فرایندهای یک سازمان یا یک تیم کاری حرفه ها و تخصص های مختلفی بکار میروند که در بکار گیری آنها عوامل زیر مؤثر می باشد: ـ تنوع حوزه کاری سازمان یا تیم کاری هر چه حوزه فعالیت های مورد بررسی وسیعتر باشد ونوع کارها متفاوت تر باشد تخصص های بررسی کننده نیاز بایستی متنوع تر باشند.از طرفیتخصص ها و دانشهایی که در مورد کلیت فعالیت ها و پروسه ها اظهار نظر می نماید نیز وابسته به تنوع حوزه فعالیت پروسه های مورد مطالعه می باشند.از نظر تعداد اعضا شرکت کننده در تیم امکان سنجی،نیاز سنجی،طراحی،پیاده سازی نیز بستگی به تنوع حوزه کاری مورد مطالعه دارد.

ـمیزان شناخت و متعاقب آن تغییرات مورد انتظار در سیستم سازمان ها و تیم های کاری با اهداف مختلفی به مطالعه وامکان سنجی پروسه های خود می پردازند عمده این اهداف عبارتند از: *شناخت ساختار و مدل ایستای سازمان یا تیم کاری مو جود یا در حال شکل گیری.

*شناخت(ایجاد شناسنامه) پروسه های موجود/در حال شکل گیری/امکان کشف در سازمان یا تیم کاری.

*شناخت روشها و متد های مدیریت پروژه بهینه.

*شناخت مستندات جاری یا در حال شکل گیری سازمان یا تیم کاری ودر نهایت بززسی گردش اسناد.

*شناخت گردش کار پروسه های موجود(DFD) *شناخت موجودیت های سیستم و رسیدن به ERD متناسب با ساختار سیستم.

*شناخت مدل کامل سیستم که بیانگر وضعیت جاری/مناسب/مورد نظر باشد.

*زسیدن به مدلی که در طراحی سیستم کارا/قابل اطمینان/معقول و مقرون/ راحت و متناسب(اصول مهندسی نرم افزار) مؤثر باشد.

*رسیدن به مدلی که در پیاده سازی سیستم کارا/ قابل اطمینان/معقول و مقرون/ راحت و متناسب(اصول مهندسی نرم افزار) مؤثر باشد.

با توجه به اهداف نوع تخصص و سطح خروجی تخصص که همان پیشنهاد های مؤثر برای ابقا/ تغییر/ایجاد سیستم جایگزین برای سیستم جاری می باشد، مشخص می گردد.می توان گفت خروجی تخصص می تواند یکی از موارد زیر باشد: _ مستندات واقعی/ استاندارد/ بهینه سیستم موجود یا در حال شکل گیری _ ابزار های کمکی مؤثر در بهبود/ ایجاد سیستم موجود یا در حال شکل گیری _ سیستم کاملاً جدید که در حوزه موضوع مورد نظر ایفای نقش خواهد کرد _ پیشنهادات دستورالعملی ، سازمانی،آیین نامه ای و...

برای سیستم موجود یا در حال شکل گیری در انتخاب نوع خروجی باید موارد پیشنهادی را بر اساس( شاخص گذاری/ در نظر داشتن)موارد زیر ارائه کرد: _ فرهنگ کاری و مسائل محیطی _ میزان هزینه و منابع مورد نیاز دیگر مانند زمان _ میزان انعطاف پذیری و علاقه مندی به تغییر و.......

- سطح فن آوری و تکنیکی بکار رفته در شناخت و تغییر در فاز امکان سنجی و کشف نیازمند یها وآنالیز: OOPیا SSADM ؟

در فازطراحی سیستم جدید: Tier3 یا؟

در فاز پیاده سازی و گذار به سیستم جدید: Desktop یا Client/Server یا Web Base یا توزیعی؟چند کاره ؟

در چه محدوده هایی؟

با چه امنیتو سطح دسترسی؟

خصوصیات 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): چه چیزی توسعه داده خواهد شد؟

به چه مصنوعاتی واقعاً نیاز داریم؟

چه الگوهایی باید مورد استفاده قرار بگیرند؟

کدام مصنوعات در حال حاضر وجود دارند؟

به چه نقش‌هایی نیاز داریم؟

چه فعالیتهایی انجام خواهند شد؟

کدام خطوط راهنما، استانداردهای پروژه و ابزارهایی مورد استفاده قرار خواهند گرفت؟

فرآیند یکپارچه رشنال در فرهنگ مهندسی نرم‌افزار، فرآیند یکپارچهٔ رشنال یا آر.یو.پی.

(Rational Unified Process و به اختصار: RUP) نام یک فرآیند توسعهٔ نرم‌افزار است که شرکت آی‌بی‌ام آنرا تدوین کرده است.

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

این فرآیند بستر مناسبی برای تولید و توسعه نرم‌افزار در اختیار تحلیل‌گران و طراحان سیستم‌های رایانه‌ای قرار می‌دهد.

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

مبتنی بر تکرار است.

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

مراحل آر.یو.پی مرحله ۱ - آغازین (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.

2003.

The RUP platform.

Montréal-SPIN .

November, 33.

Schewe, K.D.

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