RUP
از ویکیپدیا، دانشنامهٔ آزاد.
در فرهنگ مهندسی نرمافزار، فرآیند یکپارچهٔ رشنال یا آر.یو.پی.
(به انگلیسی: Rational Unified Process و به اختصار: RUP) نام یک فرآیند توسعهٔ نرمافزار است که شرکت آیبیام آنرا تدوین کرده است.
به طور خلاصه آر.یو.پی ارائه دهنده مجموعهای از روشها برای کمک به مدیریت دقیق بر روی مراحل طراحی و پیادهسازی نرمافزارهای رایانهای است.
این فرآیند بستر مناسبی برای تولید و توسعه نرمافزار در اختیار تحلیلگران و طراحان سیستمهای رایانهای قرار میدهد.
آر.یو.پی چیست؟
این فرآیند یک روش نظاممند برای تخصیص کارها و مسئولیتها در یک تیم توسعه نرمافزار ارائه میدهد و هدف آن تولید نرمافزار بصورت بهینه و با کیفیت بالاست که بتواند نیازهای کارفرما را تحت یک برنامه زمانی مشخص و با بودجه قابل پیشبینی برآورده سازد.
آر.یو.پی بهرهوری تیم تولید نرمافزار را با فراهم نمودن دسترسی تمام افراد تیم به یک پایگاه دانش سهلالوصول به همراه راهنماها، الگوها و ابزارهای کمکی برای همه فعالیتهای حیاتی توسعه، افزایش میدهد.
از آنجا که تمام افراد به منابع یکسانی دسترسی دارند، لذا دید مشترکی برای توسعه نرمافزار برخوردار هستند.
آر.یو.پی امکان استفاده موثرتری از زبان یکپارچه مدلسازی (UML) را فراهم میسازد (دقت شود که در عین حال آر.یو.پی و یو.ام.ال کاملاً مستقل از یکدیگر هستند و نباید آنها را با هم یکی فرض کنیم).
به کمک تکنیک های آر.یو.پی بخشهای عمدهای از فرآیند تولید نرمافزار به طور خودکار انجام شده و همچنین استفاده از مدلهای تولید شده در فرآیندهای گذشته در پروژههای جاری به سادگی امکانپذیر است.
این فرآیند با موقعیتهای مختلف تطبیق یافته و برای سازمانهای بزرگ یا حتی کوچک تولید و توسعه نرمافزار قابل استفاده است.
آر.یو.پی کلیه مراحل انجام یک پروژه شامل تحلیل سیستم، برنامهریزی، بررسی ریسکها، تولید و تست نرمافزار را در بر میگیرد و چهارچوبی در جهت انجام صحیح و موفق پروژههای نرم افزاری فراهم میسازد.
چرا آر.یو.پی را یکپارچه نامیدهاند:
1.
این فرآیند از ترکیب و یکپارچهسازی چند فرآیند و متدولوژی شامل Booch، OMT و OSE دیگر ایجاد شده است.
2.
از زبان یکپارچه مدلسازی (UML) به طور موثری بهره میگیرد.
3.
مفاهیمی نظیر کلاس و شیء در متدهای قبلی علائم خاص و مختلفی داشتهاند حال آنکه در آر.یو.پی یکسان شدهاند.
مهمترین مزایای آر.یو.پی
• تسهیل توسعه تکراری نرمافزار
• مدیریت نیازها
• مدل کردن تصویری نرمافزار
• بازبینی کیفیت نرمافزار
• کنترل تغییرات در نرمافزار
• امکان استفاده از طریق وب
ویژگیهای آر.یو.پی
• بر اساس یوزکیسها عمل میکند.(نیازهای کاربر از طریق یوزکیس بیان میشود)
• اساس آن طراحی معماری سیستم است و سیستم تولید شده از معماری استواری برخوردار خواهد بود.
• مبتنی بر تکرار است.
• قابلیت استفاده مجدد را فراهم میسازد زیرا پروژه به قطعات کوچک تقسیم و انجام میشود.
مراحل آر.یو.پی
مرحله ۱ - آغازین (Inception)
پایه پروژه و ابعاد آن در این مرحله مشخص میشوند.
در این مرحله پروژه به طور کلی بررسی شده و هزینه و درآمد ناشی از آن محاسبه میگردد.
در این مرحله برداشتی اجمالی از ابعاد پروژه بدست میآید.
در انتهای این مرحله تصمیم برای انجام یا عدم انجام پروژه اتخاذ خواهد شد و تعهد لازم از کارفرما تهیه میشود.
پایه پروژه و ابعاد آن در این مرحله مشخص میشوند.
در انتهای این مرحله تصمیم برای انجام یا عدم انجام پروژه اتخاذ خواهد شد و تعهد لازم از کارفرما تهیه میشود.
مرحله ۲ - تحلیل پیچیدگی (Elaboration) در این مرحله جزئیات بیشتری از نیازهای سیستم را جمعآوری شده و درک بهتری از پروژه صورت میپذیرد.
بدین ترتیب تحلیل و طراحی سطح بالایی از سیستم صورت گرفته پایه معماری اولیه سیستم بنا میشود.
در این مرحله نقشه ساخت سیستم تولید شده است.
این مرحله با پرسشهایی نظیر: در حال ساخت چه سیستمی هستیم؟
چه چیزهایی پروژه را به مخاطره میاندازد و چه ریسکهایی برای انجام آن وجود دارد.
هر چه ریسکها بیشتر و بزرگتر باشند، دقت بیشتری در انجام پروژه باید صورت گیرد.
بررسی ریسکها ریسکهای مرتبط با نیازمندیهای سیستم هدف رسیدن به سیستمی است که خواستههای کاربر را به درستی انجام دهد.
مهم است که این نیازمندیها به درستی درک شده باشند.
در اینجا استفاده صحیح از یو.ام.ال میتواند بسیار موثر باشد.
یوزکیسها ابزارهای مهمی هستند زیرا تقابل کاربر با سیستم را بطور دقیق مشخص میکنند و اساس ارتباط کارفرما با تولیدکننده نرمافزار هستند.
باید مهمترین و پرخطرترین یوزکیسها به طور مشخص تعیین شوند.
هر چه بیشتر با کاربران نهایی سیستم مذاکره شود نتایج بهتری حاصل خواهند گشت.
لازم است نمونههای اولیه برای قسمتهای پیچیده و حیاتی یوزکیسها باید ساخته شوند.
در همین زمان سایر نمودارهای مدلسازی نظیر نمودارهای کلاس (Class Diagrams)، نمودارهای فعالیت (Activity Diagram) و نمودارهای تقابل (Interaction Diagrams) نیز به کمک کاربران سیستم بخصوص کاربران ارشد که اطلاعات بیشتر و مهمتری از عملکرد سیستم دارند باید تهیه شوند.
ریسکهای تکنولوژیکی از خود میپرسیم، آیا تکنولوژی لازم برای ساختن این سیستم را در اختیار داریم؟
باید نمونههای اولیهای از سیستم ساخته شده و عملکرد آنها تحت سیستم پیشبینی شده بررسی گردد.
طراحی معماری سیستم در این مرحله صورت میگیرد.
باید اجزا تشکیل دهنده سیستم، روش ساخت یا تهیه و طریقه اتصال آنها به یکدیگر مشخص شوند.
بهتر از قسمتهایی که تغییر آنها سختتر (یا غیرممکن) است در این فاز مدنظر قرار گرفته شوند تا در صورت عدم هماهنگی در همین مرحله تصمیمات مناسب اتخاذ شوند.
طراحی سیستم باید بگونهای باشد که در آینده تغییرات و توسعه آن قابل انجام باشد.
باید یوزکیسها را بطور دقیق بررسی کنیم تا مسائلی که ممکن است طراحی سیستم را پیچیدهتر کنند به طور واضح مشخص گردند.
نمودارهای یو.ام.ال زیر در این مرحله بکار میآیند: نمودارهای کلاس و نمودارهای تقابل: اجزاء سیستم (Components) و نحوه تقابل آنها را نشان میدهند.
نمودارهای بسته بندی (Package Diagrams): یک دید سطح بالا از اجزاء سیستم فراهم میآورند.
نمودارهای گسترش (Deployment Diagrams): تصویری از چگونگی توزیع (پراکندگی) اجزاء سیستم نشان میدهند.
ریسکهای منابع انسانی برخی اشتباهات برنامهنویسان به سختی قابل کشف و حل هستند و رفع آنها مستلزم صرف وقت و هزینه بالایی است .
آموزش نقش مهمی در این راستا بازی میکند چرا که پیشگیری بهتر از درمان است.
اگر این امکان فراهم شود که برخی از اعضاء که در مراحل تولید پروژههای مهمتر نقش داشتهاند و تجربه بیشتری دارند، هر چند برای مدتی کوتاه در پروژه همکاری کنند ریسک مشکلات ناشی از نیروی انسانی تا حد زیادی کاهش خواهد یافت.
ریسکهای سیاسی هرچند در نگاه اول ممکن است عجیب به نظر برسد، ولی با رشد روزافزون رایانهها و سیستمهای مبتنی بر رایانه امکان بروز تعارض میان سیستم نرمافزاری ساخته شده و مسائل امنیتی وجود دارد.
بهتر است در مورد یوزکیسهایی که با مردم جامعه یا سازمانها (بخصوص سازمانهای دولتی) تعامل خواهند داشت در همین مرحله سیاستهای واضحی مشخص گردد.
پایان مرحله دوم هنگامی که بتوانیم مدت زمان لازم برای تولید هر یوزکیس را تخمین بزنیم و تمام ریسکهای مهم بررسی و راهحلهای مقابله با آنها برنامهریزی شده باشند، میتوان گفت مرحله دوم خاتمه یافته است.
مرحله ۳ - ساخت (Construction) این مرحله به روش افزایش-تکرار صورت میگیرد.
به این معنی که بر خلاف روشهایی مانند توسعه آبشاری (SSADM) که ممکن است در برخی زمانها بعضی از اعضای تیم به دلیل انتظار برای دریافت نتیجه گروهی دیگر از اعضای تیم بیکار بمانند، در آر.یو.پی اساس کار بر تولید قطعات سیستم به صورت مرحله به مرحله است و در هر مرحله عملکرد قطعه تولید شده بهبود مییابد.
لذا پس از به جریان افتادن فرآیند اعضای تیم بیکار نمانده و به افزایش حجم و دقت عملکرد قطعه تولیدی قبلی خود میپردازند.
دقت شود که هر قطعه تولید شده خود یک نرمافزار نسبتاً کامل بوده و باید توانایی برآورده کردن نیازهای مشخصی را داشته باشد، بدین معنی که قطعات تولید شده باید قابل استفاده باشند.
برای تولید هر قطعه تمام این چهار مرحله انجام شده است!
این نکته مهمی در آر.یو.پی است و میتوان اینگونه در نظر گرفت که محصول نهایی به شکل یک پیاز بوده و دارای لایه هایی است که هم برای تولید هر لایه و هم برای تولید کل پیاز این مراحل چهارگانه صورت گرفتهاند.
بطور خلاصه نتیجه این فاز کدنویسی و ایجاد نرم افزار است مرحله ۴ - انتقال (Transition) مرحله نهایی که شامل تست آزمایشی، بهبود عملکرد و آموزش کاربران است.
ابزار مهندسی نرم افزار RUP یک فرآیند مهندسی نرمافزار بوده که یک روش منظم برای تخصیص کارها و مسئولیتها در درون یک سازمان تولید نرمافزار را ارائه میدهد.
هدفاین روش عبارتست از: اطمینان از تولید یک محصول نرمافزاری با کیفیت بالا که نیازمندیهای کاربر نهایی را با یک زمانبندی و بودجه قابل پیش بینی، برآورده سازد.
شکل زیر معماری کلی RUP را نشان می دهد.
RUP شامل دو بعد است: محور افقی معرف زمان بوده و اجزاء چرخه حیات فرآیند را نشان میدهد.
محور عمودی معرف جریانهای کاری اصلی فرآیند است که فعالیتها را بطور منطقی بسته به طبیعتشان گروه بندی مینماید.
بعد اول، معرف جنبه پویای فرآیند است و با اصطلاحات فازها، تکرارها و مایلستونها بیان میگردد.
بعد دوم، جنبهایستای فرآیند را ارائه میدهد: که با اصطلاحات مولفهها، فعالیتها، جریانهای کاری، فرآوردهها، و نقشها تبیین میشود.
نمودار فوق چگونگی تاکید در هر بخش را طی زمان نشان می دهد.
به عنوان مثال در تکرارهای اولیه بیشتر وقت صرف نیازمندیها شده و در تکرارهای نهایی اکثر صرف پیادهسازی میگردد.
شکل 1) معماری کلی RUP مراحل زیست چرخ پروژه: از نقطه نظر مدیریتی زیست چرخ نرمافزاری RUP به چهار فاز ترتیبی تقسیم شده که هرکدام به یک مایلستون ختم میگردد.
فازهای شروع ، تشریح ، ساخت و انتقال .
هر فاز در واقع یک محدوده زمانی بین دو مایلستون محسوب میشود.
در انتهای هرفاز جهت تعیین برآورده شدن اهداف مربوط به آن فاز، یک ارزیابی انجام میگیرد.
ارزیابی موفقیت آمیز اجازه ورود به فاز بعدی را صادر میکند.
شکل 2) فازها و مایلستونهای یک پروژه تکرار در متدولوژی RUP: پروژهها بصورت قراردادی بگونهای سازماندهی شدهاند که به ترتیب از هر جریان کاری یکبار و تنها یکبار گذر کنند.
این کار منجر به زیست چرخ آبشاری میگردد.
شکل 3) زیست چرخ آبشاری این کار، بعداً در زمان پیادهسازی زمانیکه برای نخستین بار فرآورده ساخته شده و آزمون آغاز گردیده است، منجر به یک سد یکپارچه میگردد.
مشکلات پنهان مانده در سرتاسر تحلیل، طراحی و پیادهسازی ناگهان به سطح آمده و پروژه با شروع یک چرخه طولانی اصلاح خطا، متوقف میگردد.
یک راه قابل انعطافتر (و کم مخاطرهتر) برای تولید، چندین بار گذشتن از جریانهای کاری مختلف، ایجاد درک بهتری از نیازمندیها، ساخت مهندسی یک معماری قوی، ایجاد سریع سازمان تولید، و سرانجام تحویل یک سری پیادهسازیهایی که به تدریج کاملتر میشود، است.
این روش، زیست چرخ تکرار نامیده میشود.
هر گذر از میان دنباله جریانهای کاری فرآیند، تکرار خوانده میشود.
شکل 4) زیست چرخ تکرار بدین ترتیب ازنقطه نظر یک دیدگاه تولید، چرخه حیات نرمافزار، یک توالی از تکرارها میباشد که بواسطه آن نرمافزار تولید میشود.
هر تکرار منجر به یک نشر از یک محصول قابل اجرا میشود.
این محصول ممکن است زیرمجموعهای از یک دیدگاه کامل بوده ولی از برخی از جنبههای مهندسی یا کاربری می تواند مفید باشد.
هر نشر به همراه فرآوردههای پشتیبانی میباشد که عبارتند از: توصیف نشر، مستندات کاربر، طرحها و غیره و مدلهای بروز شده از سیستم.
پی آمد اصلیاین روش تکراری، همانگونه که در نمودار زیر نمایش داده شده، رشد و تکمیل مجموعه فرآوردههایی که پیشتر توضیح داده شده، طی زمان میباشد.
شکل 5) سیر تکاملی اطلاعات در طی مراحل توسعه منابع سایت شرکت آیبیام مشارکتکنندگان ویکیپدیا، «IBM Rational Unified Process»، ویکیپدیای انگلیسی، دانشنامهٔ آزاد.
(بازیابی در ۲۳ آوریل ۲۰۰۷).
component-based software معماری نرمافزار و مهندسی فرآیند فرآیند یکپارچه توسعه چیست؟
برگرفته از «http://fa.wikipedia.org/wiki/RUP»