گمان میرود که این مقاله ناقض حق تکثیر باشد، اما بدون داشتن منبع امکان تشخیص قطعی این موضوع وجود ندارد. اگر میتوان نشان داد که این مقاله حق نشر را زیر پا گذاشته است، لطفاً مقاله را در ویکیپدیا:مشکلات حق تکثیر فهرست کنید. اگر مطمئنید که مقاله ناقض حق تکثیر نیست، شواهدی را در این زمینه در همین صفحهٔ بحث فراهم آورید. خواهشمندیم این برچسب را بدون گفتگو برندارید. |
برای تأییدپذیری کامل این مقاله به منابع بیشتری نیاز است. |
در فرهنگ مهندسی نرمافزار، فرایند یکپارچهٔ گویا یا آریوپی (به انگلیسی: Rational Unified Process و به اختصار: RUP) نام یک فرایند توسعهٔ نرمافزار است که شرکت رشنال آیبیام آن را تدوین کردهاست. آیبیام این شرکت را در سال ۲۰۰۳ خرید و هماکنون توسعهٔ این فرایند و ابزارهای آن را بهعهده دارد. بهطور خلاصه آریوپی ارائه دهنده مجموعهای از روشها برای کمک به مدیریت دقیق بر روی مراحل طراحی و پیادهسازی نرمافزارهای رایانهای است. این فرایند بستر مناسبی برای تولید و توسعه نرمافزار در اختیار تحلیلگران و طراحان سیستمهای رایانهای قرار میدهد.
آریوپی چیست؟
این فرایند یک روش نظاممند برای تخصیص کارها و مسئولیتها در یک تیم توسعه نرمافزار ارائه میدهد و هدف آن تولید نرمافزار به صورت بهینه و با کیفیت بالاست که بتواند نیازهای کارفرما را تحت یک برنامه زمانی مشخص و با بودجه قابل پیشبینی برآورده سازد. آر یو پی بهرهوری تیم تولید نرمافزار را با فراهم نمودن دسترسی تمام افراد تیم به یک پایگاه دانش سهلالوصول به همراه راهنماها، الگوها و ابزارهای کمکی برای همه فعالیتهای حیاتی توسعه، افزایش میدهد. از آنجا که تمام افراد به منابع یکسانی دسترسی دارند، لذا از دید مشترکی برای توسعه نرمافزار برخوردار هستند.
آریوپی امکان استفاده مؤثرتری از زبان یکپارچه مدلسازی (UML) را فراهم میسازد (دقت شود که در عین حال آریوپی و یوامال کاملاً مستقل از یکدیگر هستند و نباید آنها را با هم یکی فرض کنیم). به کمک تکنیکهای آریوپی بخشهای عمدهای از فرایند تولید نرمافزار بهطور خودکار انجام شده و همچنین استفاده از مدلهای تولید شده در فرایندهای گذشته در پروژههای جاری به سادگی امکانپذیر است. این فرایند با موقعیتهای مختلف تطبیق یافته و برای سازمانهای بزرگ یا حتی کوچک تولید و توسعه نرمافزار قابل استفادهاست.
آریوپی کلیه مراحل انجام یک پروژه شامل تحلیل سیستم، برنامهریزی، بررسی ریسکها، تولید و تست نرمافزار را در بر میگیرد و چهارچوبی در جهت انجام صحیح و موفق پروژههای نرمافزاری فراهم میسازد.
چرا آریوپی را یکپارچه نامیدهاند:
- این فرایند از ترکیب و یکپارچهسازی چند فرایند و متدولوژی دیگر شامل Booch، OMT و OSE ایجاد شدهاست.
- از زبان یکپارچه مدلسازی (UML) بهطور مؤثری بهره میگیرد.
- مفاهیمی نظیر کلاس و شیء در متدهای قبلی علائم خاص و مختلفی داشتهاند حال آنکه در آریوپی یکسان شدهاند.
مهمترین مزایای آریوپی
- تسهیل توسعه تکراری نرمافزار
- مدیریت نیازها
- مدل کردن تصویری نرمافزار
- بازبینی کیفیت نرمافزار
- کنترل تغییرات در نرمافزار
- امکان استفاده از طریق وب
ویژگیهای آریوپی
- بر اساس موردهای کاربری ( موردهای استفاده ) عمل میکند.(نیازهای کاربر از طریق موارد کاربری بیان میشود)
- اساس آن طراحی معماری سیستم است و سیستم تولید شده از معماری استواری برخوردار خواهد بود.
- مبتنی بر تکرار است.
- قابلیت استفاده مجدد را فراهم میسازد زیرا پروژه به قطعات کوچک تقسیم و انجام میشود.
مراحل آریوپی
مرحله ۱: آغازین (Inception)
پروژه ساخته میشود و هدایت میشود توسط خود شخص
مرحله ۲: تحلیل جزئیات(Elaboration)
در این مرحله جزئیات بیشتری از نیازهای سیستم جمعآوری شده و درک بهتری از پروژه صورت میپذیرد. بدین ترتیب تحلیل و طراحی سطح بالایی از سیستم صورت گرفته و پایه معماری اولیه سیستم بنا میشود. در این مرحله نقشه ساخت سیستم تولید شدهاست.
این مرحله با پرسشهایی نظیر: در حال ساخت چه سیستمی هستیم؟ چه چیزهایی پروژه را به مخاطره میاندازد و چه ریسکهایی برای انجام آن وجود دارد. هر چه ریسکها بیشتر و بزرگتر باشند، دقت بیشتری در انجام پروژه باید صورت گیرد.
بررسی ریسکها
ریسکهای مرتبط با نیازمندیهای سیستم
هدف رسیدن به سیستمی است که خواستههای کاربر را به درستی انجام دهد. مهم این است که نیازمندیها به درستی درک شده باشند. در اینجا استفاده صحیح از یوامال میتواند بسیار مؤثر باشد. نمونههای کاربردی ابزارهای مهمی هستند که تقابل کاربر با سیستم را بهطور دقیق مشخص میکنند و اساس ارتباط کارفرما با تولیدکننده نرمافزار هستند. باید مهمترین و پرخطرترین نمونههای کاربردی بهطور مشخص تعیین شوند. هر چه بیشتر با کاربران نهایی سیستم مذاکره شود نتایج بهتری حاصل خواهند شد. لازم است نمونههای اولیه برای قسمتهای پیچیده و حیاتی نمونههای کاربردی ساخته شوند.
در همین زمان باید سایر نمودارهای مدلسازی نظیر نمودارهای کلاس (Class Diagrams)، نمودارهای فعالیت (Activity Diagram) و نمودارهای تقابل (Interaction Diagrams) به کمک کاربران سیستم به خصوص کاربران ارشد که اطلاعات بیشتر و مهمتری از عملکرد سیستم دارند، تهیه شوند.
ریسکهای تکنولوژیکی
از خود میپرسیم، آیا تکنولوژی لازم برای ساختن این سیستم را در اختیار داریم؟ باید نمونههای اولیهای از سیستم ساخته شده و عملکرد آنها تحت سیستم پیشبینی شده بررسی گردد. طراحی معماری سیستم در این مرحله صورت میگیرد. باید اجزا تشکیل دهنده سیستم، روش ساخت یا تهیه و طریقه اتصال آنها به یکدیگر مشخص شوند. بهتر است قسمتهایی که تغییر آنها سختتر (یا غیرممکن) است در این فاز مدنظر قرار گرفته شوند تا در صورت عدم هماهنگی در همین مرحله تصمیمات مناسب اتخاذ شوند.
طراحی سیستم باید به گونهای باشد که در آینده تغییرات و توسعه آن قابل انجام باشد. باید موردکاربردها را بهطور دقیق بررسی کنیم تا مسائلی که ممکن است طراحی سیستم را پیچیدهتر کنند بهطور واضح مشخص گردند.
نمودارهای یوامال زیر در این مرحله بکار میآیند:
- نمودارهای کلاس و نمودارهای تقابل: اجزاء سیستم (Components) و نحوه تقابل آنها را نشان میدهند.
- نمودارهای بسته بندی (Package Diagrams): یک دید سطح بالا از اجزاء سیستم فراهم میآورند.
- نمودارهای گسترش (Deployment Diagrams): تصویری از چگونگی توزیع (پراکندگی) اجزاء سیستم نشان میدهند.
ریسکهای منابع انسانی
برخی اشتباهات برنامهنویسان به سختی قابل کشف و حل هستند و رفع آنها مستلزم صرف وقت و هزینه بالایی است. آموزش نقش مهمی در این راستا بازی میکند چرا که پیشگیری بهتر از درمان است. اگر این امکان فراهم شود که برخی از اعضاء که در مراحل تولید پروژههای مهمتر نقش داشتهاند و تجربه بیشتری دارند، هر چند برای مدتی کوتاه در پروژه همکاری کنند ریسک مشکلات ناشی از نیروی انسانی تا حد زیادی کاهش خواهد یافت.
ریسکهای سیاسی
هرچند در نگاه اول ممکن است عجیب به نظر برسد، ولی با رشد روزافزون رایانهها و سیستمهای مبتنی بر رایانه امکان بروز تعارض میان سیستم نرمافزاری ساخته شده و مسائل امنیتی وجود دارد. بهتر است در مورد موردکاربردهایی که با مردم جامعه یا سازمانها (بخصوص سازمانهای دولتی) تعامل خواهند داشت در همین مرحله سیاستهای واضحی مشخص گردد.
هنگامی که بتوانیم مدت زمان لازم برای تولید هر یوزکیس را تخمین بزنیم و تمام ریسکهای مهم بررسی و راهحلهای مقابله با آنها برنامهریزی شده باشند، میتوان گفت مرحله دوم خاتمه یافتهاست.
مرحله ۳: ساخت (Construction)
این مرحله به روش افزایش-تکرار صورت میگیرد. به این معنی که بر خلاف روشهایی مانند توسعه آبشاری (SSADM) که ممکن است در برخی زمانها بعضی از اعضای تیم به دلیل انتظار برای دریافت نتیجه گروهی دیگر از اعضای تیم بیکار بمانند، در آریو پی اساس کار بر تولید قطعات سیستم به صورت مرحله به مرحلهاست و در هر مرحله عملکرد قطعه تولید شده بهبود مییابد. لذا پس از به جریان افتادن فرایند اعضای تیم بیکار نمانده و به افزایش حجم و دقت عملکرد قطعه تولیدی قبلی خود میپردازند.
- دقت شود که هر قطعه تولید شده خود یک نرمافزار نسبتاً کامل بوده و باید توانایی برآورده کردن نیازهای مشخصی را داشته باشد، بدین معنی که قطعات تولید شده باید قابل استفاده باشند.
- برای تولید هر قطعه تمام این چهار مرحله انجام شده است! این نکته مهمی در آر یو پی است و میتوان اینگونه در نظر گرفت که محصول نهایی به شکل یک پیاز بوده و دارای لایههایی است که هم برای تولید هر لایه و هم برای تولید کل پیاز این مراحل چهارگانه صورت گرفتهاند.
بطور خلاصه نتیجه این فاز کدنویسی و ایجاد نرمافزار است.
مرحله ۴: انتقال (Transition)
مرحله نهایی که شامل تست آزمایشی، بهبود عملکرد و آموزش کاربران است.
محدودیتها
از نظر بسیاری از افراد این متودولوژی بسیار پیچیده و سنگین است و یادگیری آن بسیار طولانی میباشد و از طرفی یک فرد که کاملاً به این متودولوژی آشنا میباشد باید آن را برای هر پروژه تنظیم نماید. البته شرکت آیبیام یک ابزار به نام Rational Method Composer را به همین منظور تولید نمودهاست. ولی باز هم موفقیت در استفاده از این متودولوزی بستگی به این فرد دارد. در حال حاضر یک نسخه ساده از این متودولوژی به نام OpenUP توسط شرکت Eclipse تهیه شدهاست و به صورت Open Source میباشد. OpenUP یک مرجع بسیار مناسب برای کسانی میباشد که تازه میخواهند با RUP آشنا شوند و از آن در پروژههای خود برای بار اول استفاده کنند.[نیازمند منبع]
منابع
- مشارکتکنندگان ویکیپدیا. «IBM Rational Unified Process». در دانشنامهٔ ویکیپدیای انگلیسی، بازبینیشده در ۲۳ آوریل ۲۰۰۷.