معرفی متدولوژی RUP

1. معرفی متدولوژی RUP ارديبهشت 1384

2. معرفی RUP • RUP یک فرایند تولید نرم افزار است که توسط شرکت rational ایجاد شده است (هم اکنون IBM) و هدف آن کمک به تولید کنندگان و مدیران صنعت نرم افزار است. • RUP برای جنبه های مختلف تولید چیزهایی مانند نقشها، محصولات، فعالیتها و گردش کار تعریف میکند

3. تاریخچه • در طی سه ده تکامل یافته است • روش اریکسون در سال 1967 • Objectory در سال 1987 توسط Jacobson عرضه شد • توسعه روش اریکسون • شرکت rational در سال 1995 متدولوژی Objectory را تصاحب کرد و rational Objectory را معرفی کرد • در سال 1997 UML توسط OMG استاندارد شد و شرکت rational در متدولوژی rational Objectory همه مدلهای خود را بر اساس این زبان استاندارد نمود • متدولوژی rational Objectory برای پوشش جنبه های مختلف تولید نرم افزار توسعه داده شد و متدولوژی جدید RUP نام گرفته شد.

4. تاریخچه

5. تاریخچه • در سال 1999 با انتشار کتاب ‘The Unified Software Development Process. (Jacobson, Booch, Rumbaugh)’ به عموم معرفی شد.

6. خلاصه

7. فازها • آغاز ( Inception ): در انتهای این فاز تصمیم گرفته ایم که آیا پروژه را آغاز کنیم یا خیر و این تصمیم پس از تولید یک Business Case گرفته می شود. • اجرا ( Elaboration) : در انتهای این فاز اکثر نیازمندیهای باقی مانده شناسایی شده اند و یک معماری مانع (sound architecture) برای نرم افزار بناشده است. • ساخت ( Construction): در این فاز با کار روی معماری حاصل از فاز قبل و تولید یک سری افزایش بر روی نرم افزار در طی تعدادی تکرار، نسخه اول محصول برای اجرا در محیط کاربر ساخته می شود. • انتقال ( Transition): نرم افزار ساخته شده به سایت مشتری انتقال داده می شود و بررسی میگردد که آیا کاملا نیازمندیهای مشتری برطرف شده است؟ مستندات کاربری نیز تحویل می شود.

8. دیسیپلینهای فرایند • مدلسازی تجاری: • درک ساختار و فعالیتهای سازمانی که قرار است سیستم در آنجا استقرار یابد • درک مشکلات فعلی در سازمان و شناسایی پتانسیل های بهبود • حصول اطمینان از اینکه مشتریان، کاربران نهایی و ایجاد کنندگان نرم افزار درک یکسان از سازمان مقصد دارند. • بیرون کشیدن نیازمندیهای نرم افزاری که برای پشتیبانی سازمان مقصد مورد نیاز است • تشخیص نیازمندیها : • فراهم آوردن اساس تخمین هزینه و زمان ایجاد سیستم • بستن قرارداد با مشتری بر اساس آنچه سیستم باید انجام دهد • فراهم کردن درک بهتر از نیازمندیهای سیستم برای تولیدکنندگان • تعیین مرزهای سیستم • فراهم آوردن پایه ای برای طرح ریزی بخشهای فنی تکرارها • واسط کاربر سیستم با تاکید بر نیازها و اهداف کاربران تهیه می شود

9. دیسیپلینهای فرایند • تحلیل و طراحی: • طراحی سیستم نهایی بر اساس نیازمندیها • ایجاد یک معماری قوی برای سیستم • تطبیق طراحی و پیاده سازی (وارد ساختن ملاحظات خاص پیاده سازی )، ایجاد یک طراحی کارآ • پیاده سازی: • لایه بندی زیرسیستم های پیاده سازی • کلاسها و موجودیتها پیاده سازی می شوند (به شکل فایلهای source، باینریها، اجرایی ها و ...) • انجام آزمون واحد بر روی مولفه ها • مجتمع کردن مولفه ها و ایجاد یک سیستم اجرایی

10. دیسیپلینهای فرایند • آزمون: • ارزیابی صحت تعامل بین موجودیتها • ارزیابی مجتمع سازی همه مولفه های نرم افزار • ارزیابی اینکه همه نیازمندیها بطور صحیح پیاده شده اند • شناسایی عیب ها و حصول اطمینان از اینکه قبل از استقرار مرتفع شده اند. • استقرار: • استقرار نرم افزار در محیط کاربری ( نصب، دسترسی بر روی اینترنت، پیشنهاد بخشی از نرم افزار)

11. دیسیپلینهای پشتیبانی • مدیریت پروژه: • مدیریت ریسک • طرح ریزی یک پروژه تکرار شونده • مونیتور کردن پیشرفت پروژه، متریک ها • مدیریت تغییر و پیکر بندی: • پشتیبانی روشهای تولید • مراقبت از مجتمع بودن نرم افزار • حصول اطمینان از کامل بودن و صحت محصول پیکربندی شده • فراهم آوردن یک محیط مناسب برای تولید محصول • فراهم آوردن قابلیت پاسخ به این سوال: یک دستاورد توسط چه کسی، کی و چرا تغییر یافته است. • آماده سازی محیط: • تمرکز اصلی بر پیکربندی فرایند برای یک پروژه است بعلاوه تعیین ابزارها • تولید راهنمایی های برای پشتیبانی یک پروژه

12. تکرار Iteration)) • تکرار یک گذر کامل از همه Disciplineها شامل حداقل تشخیص نیازمندیها، تحلیل و طراحی، پیاده سازی و آزمون است. تکرار مانند یک پروژه کوچک مدل آبشاری است

13. بهترین عملکردها (Best Practices) • تولید نرم افزار بروش تکرار شونده • مدیریت نیازمندیها • معماری مبتنی بر مولفه • مدل کردن تصویری نرم افزار • بررسی مداوم کیفیت • کنترل تغییرات نرم افزار

14. تولید نرم افزار بروش تکرار شونده • فرایند آبشاری باعث می شد اعضائ تیم تا مدتی بیکار بمانند مثلا آزمونگرها • با بکارگیری رویکرد تکرار شونده: • تغییر کردن نیازمندیها که یک واقعیت است مدنظر قرار می گیرد • مجتمع سازی بصورت "انفجار عظیم" انجام نمی گیرد. فعالیتی که 40% فعالیتهای کل پروژه را شامل می شد به 6 تا 9 مجتمع سازی با عناصر کمتر بدل شده است • از آنجا که ریسک ها معمولا در زمان مجتمع سازی ظاهر می شوند، طبیعتا با رویکرد تکرار شونده زودتر یافت می شوند. با این رویکرد به سرعت همه اجزائ فرایند، ابزارها، نرم افزارهای تجاری، مهارتهای افراد و ... آزمون می شوند و ریسکها یافت میگردد. • حضور سریع با یک نسخه ابتدایی از محصول در بازار رقابتی تکنولوژی • قابلیت استفاده مجدد • هنگامی که خطاها طی تکرارهای مختلف برطرف می شود، پس یک معماری قوی (robust) داریم. • تولید کنندگان سریعا توانایی های خود را بررسی کرده و افزایش می دهند. • خود فرایند هم در این مسیر بهبود می یابد.

15. موارد بیشتر • RUP فرایندی use case driven است • RUP فرایندی معماری محور است • RUP تکرار شونده و افزایشی است

16. Use-Case Driven • چند تعریف • کاربر = کاربر انسانی + دیگر سیستم ها • مورد کاربرد (use case) = قسمتی از عملکرد • مدل مورد کاربرد = همه موارد کاربرد • Use-Case Driven = جنبه های فرایند تولید از موارد کاربرد نشات میگیرند (کلاسها، توالیها،...)

17. Use-Case Driven • به این معنی که ابتدا راهنمای کاربر نوشته شود و سپس کد برنامه زده شود. • به این طریق نرم افزار براساس نیازمندیهای کاربر شکل می گیرد • ارزیابی مداوم اینکه سیستم برای هر کاربری چه کاری باید انجام دهد • پاسخی به بحران نرم افزار دهه 60

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

19. مزایای روش تکرار-افزایش مدیریت زودهنگام ریسکها پروژه

20. مزایای روش تکرار-افزایش • کاهش زمان و هزینه مجتمع سازی • ایجاد معماری پایدار در مراحل اولیه • مدیریت ساده تر تغییرات • فرصت آموزش تیم در مورد دیسیپلین ها در تکرارهای اولیه • کیفیت بالاتر نرم افزار