‫معرفی متدولوژی ‪RUP‬‬
‫ارديبهشت ‪1384‬‬
‫معرفی ‪RUP‬‬
‫‪ RUP ‬یک فرایند تولید نرم افزار است که توسط‬
‫شرکت ‪ rational‬ایجاد شده است (هم اکنون ‪ )IBM‬و‬
‫هدف آن کمک به تولید کنندگان و مدیران صنعت نرم‬
‫افزار است‪.‬‬
‫‪ RUP ‬برای جنبه های مختلف تولید چیزهایی مانند نقشها‪،‬‬
‫محصوالت‪ ،‬فعالیتها و گردش کار تعریف میکند‬
‫صفحه ‪2‬‬
‫© سپهر مهر فناوری نو ‪383‬‬
‫تاریخچه‬
‫‪‬‬
‫‪‬‬
‫‪‬‬
‫‪‬‬
‫‪‬‬
‫‪‬‬
‫در طی سه ده تکامل یافته است‬
‫روش اریکسون در سال ‪1967‬‬
‫‪ Objectory‬در سال ‪ 1987‬توسط ‪ Jacobson‬عرضه شد‬
‫‪ ‬توسعه روش اریکسون‬
‫شرکت ‪ rational‬در سال ‪ 1995‬متدولوژی ‪ Objectory‬را‬
‫تصاحب کرد و ‪ rational Objectory‬را معرفی کرد‬
‫در سال ‪ UML 1997‬توسط ‪ OMG‬استاندارد شد و شرکت‬
‫‪ rational‬در متدولوژی ‪ rational Objectory‬همه مدلهای‬
‫خود را بر اساس این زبان استاندارد نمود‬
‫متدولوژی ‪ rational Objectory‬برای پوشش جنبه های‬
‫مختلف تولید نرم افزار توسعه داده شد و متدولوژی جدید ‪RUP‬‬
‫نام گرفته شد‪.‬‬
‫صفحه ‪3‬‬
‫© سپهر مهر فناوری نو ‪383‬‬
‫تاریخچه‬
‫صفحه ‪4‬‬
‫© سپهر مهر فناوری نو ‪383‬‬
‫تاریخچه‬
The Unified Software ‘ ‫ با انتشار کتاب‬1999 ‫ در سال‬
Development Process. (Jacobson, Booch,
Rumbaugh)’
.‫به عموم معرفی شد‬
383 ‫© سپهر مهر فناوری نو‬
5 ‫صفحه‬
‫خالصه‬
‫صفحه ‪6‬‬
‫© سپهر مهر فناوری نو ‪383‬‬
‫فازها‬
‫‪‬‬
‫‪‬‬
‫‪‬‬
‫‪‬‬
‫آغاز ( ‪:) Inception‬‬
‫در انتهای این فاز تصمیم گرفته ایم که آیا پروژه را آغاز کنیم یا خیر و این‬
‫تصمیم پس از تولید یک ‪ Business Case‬گرفته می شود‪.‬‬
‫اجرا ( ‪: )Elaboration‬‬
‫در انتهای این فاز اکثر نیازمندیهای باقی مانده شناسایی شده اند و یک‬
‫معماری مانع (‪ )sound architecture‬برای نرم افزار بناشده است‪.‬‬
‫ساخت ( ‪:)Construction‬‬
‫در این فاز با کار روی معماری حاصل از فاز قبل و تولید یک سری‬
‫افزایش بر روی نرم افزار در طی تعدادی تکرار‪ ،‬نسخه اول محصول‬
‫برای اجرا در محیط کاربر ساخته می شود‪.‬‬
‫انتقال ( ‪:)Transition‬‬
‫نرم افزار ساخته شده به سایت مشتری انتقال داده می شود و بررسی‬
‫میگردد که آیا کامال نیازمندیهای مشتری برطرف شده است؟ مستندات‬
‫کاربری نیز تحویل می شود‪.‬‬
‫صفحه ‪7‬‬
‫© سپهر مهر فناوری نو ‪383‬‬
‫دیسیپلینهای فرایند‬
‫‪ ‬مدلسازی تجاری‪:‬‬
‫‪‬‬
‫‪‬‬
‫‪‬‬
‫‪‬‬
‫درک ساختار و فعالیتهای سازمانی که قرار است سیستم در آنجا استقرار‬
‫یابد‬
‫درک مشکالت فعلی در سازمان و شناسایی پتانسیل های بهبود‬
‫حصول اطمینان از اینکه مشتریان‪ ،‬کاربران نهایی و ایجاد کنندگان نرم‬
‫افزار درک یکسان از سازمان مقصد دارند‪.‬‬
‫بیرون کشیدن نیازمندیهای نرم افزاری که برای پشتیبانی سازمان مقصد‬
‫مورد نیاز است‬
‫‪ ‬تشخیص نیازمندیها ‪:‬‬
‫‪‬‬
‫‪‬‬
‫‪‬‬
‫‪‬‬
‫‪‬‬
‫‪‬‬
‫فراهم آوردن اساس تخمین هزینه و زمان ایجاد سیستم‬
‫بستن قرارداد با مشتری بر اساس آنچه سیستم باید انجام دهد‬
‫فراهم کردن درک بهتر از نیازمندیهای سیستم برای تولیدکنندگان‬
‫تعیین مرزهای سیستم‬
‫فراهم آوردن پایه ای برای طرح ریزی بخشهای فنی تکرارها‬
‫واسط کاربر سیستم با تاکید بر نیازها و اهداف کاربران تهیه می شود‬
‫صفحه ‪8‬‬
‫© سپهر مهر فناوری نو ‪383‬‬
‫دیسیپلینهای فرایند‬
‫‪ ‬تحلیل و طراحی‪:‬‬
‫‪ ‬طراحی سیستم نهایی بر اساس نیازمندیها‬
‫‪ ‬ایجاد یک معماری قوی برای سیستم‬
‫‪ ‬تطبیق طراحی و پیاده سازی (وارد ساختن مالحظات خاص‬
‫پیاده سازی )‪ ،‬ایجاد یک طراحی کارآ‬
‫‪ ‬پیاده سازی‪:‬‬
‫‪‬‬
‫‪‬‬
‫‪‬‬
‫‪‬‬
‫الیه بندی زیرسیستم های پیاده سازی‬
‫کالسها و موجودیتها پیاده سازی می شوند (به شکل فایلهای‬
‫‪ ،source‬باینریها‪ ،‬اجرایی ها و ‪)...‬‬
‫انجام آزمون واحد بر روی مولفه ها‬
‫مجتمع کردن مولفه ها و ایجاد یک سیستم اجرایی‬
‫صفحه ‪9‬‬
‫© سپهر مهر فناوری نو ‪383‬‬
‫دیسیپلینهای فرایند‬
‫‪ ‬آزمون‪:‬‬
‫‪‬‬
‫‪‬‬
‫‪‬‬
‫‪‬‬
‫ارزیابی صحت تعامل بین موجودیتها‬
‫ارزیابی مجتمع سازی همه مولفه های نرم افزار‬
‫ارزیابی اینکه همه نیازمندیها بطور صحیح پیاده شده اند‬
‫شناسایی عیب ها و حصول اطمینان از اینکه قبل از استقرار‬
‫مرتفع شده اند‪.‬‬
‫‪ ‬استقرار‪:‬‬
‫‪ ‬استقرار نرم افزار در محیط کاربری ( نصب‪ ،‬دسترسی بر‬
‫روی اینترنت‪ ،‬پیشنهاد بخشی از نرم افزار)‬
‫صفحه ‪10‬‬
‫© سپهر مهر فناوری نو ‪383‬‬
‫دیسیپلینهای پشتیبانی‬
‫‪ ‬مدیریت پروژه‪:‬‬
‫‪ ‬مدیریت ریسک‬
‫‪ ‬طرح ریزی یک پروژه تکرار شونده‬
‫‪ ‬مونیتور کردن پیشرفت پروژه‪ ،‬متریک ها‬
‫‪ ‬مدیریت تغییر و پیکر بندی‪:‬‬
‫‪‬‬
‫‪‬‬
‫‪‬‬
‫‪‬‬
‫‪‬‬
‫پشتیبانی روشهای تولید‬
‫مراقبت از مجتمع بودن نرم افزار‬
‫حصول اطمینان از کامل بودن و صحت محصول پیکربندی شده‬
‫فراهم آوردن یک محیط مناسب برای تولید محصول‬
‫فراهم آوردن قابلیت پاسخ به این سوال‪ :‬یک دستاورد توسط چه کسی‪ ،‬کی و‬
‫چرا تغییر یافته است‪.‬‬
‫‪ ‬آماده سازی محیط‪:‬‬
‫‪ ‬تمرکز اصلی بر پیکربندی فرایند برای یک پروژه است بعالوه تعیین ابزارها‬
‫‪ ‬تولید راهنمایی های برای پشتیبانی یک پروژه‬
‫صفحه ‪11‬‬
‫© سپهر مهر فناوری نو ‪383‬‬
‫تکرار )‪)Iteration‬‬
‫‪ ‬تکرار یک گذر کامل از همه ‪Discipline‬ها شامل‬
‫حداقل تشخیص نیازمندیها‪ ،‬تحلیل و طراحی‪ ،‬پیاده‬
‫سازی و آزمون است‪ .‬تکرار مانند یک پروژه کوچک‬
‫مدل آبشاری است‬
‫صفحه ‪12‬‬
‫© سپهر مهر فناوری نو ‪383‬‬
‫بهترین عملکردها (‪)Best Practices‬‬
‫‪‬‬
‫‪‬‬
‫‪‬‬
‫‪‬‬
‫‪‬‬
‫‪‬‬
‫تولید نرم افزار بروش تکرار شونده‬
‫مدیریت نیازمندیها‬
‫معماری مبتنی بر مولفه‬
‫مدل کردن تصویری نرم افزار‬
‫بررسی مداوم کیفیت‬
‫کنترل تغییرات نرم افزار‬
‫صفحه ‪13‬‬
‫© سپهر مهر فناوری نو ‪383‬‬
‫تولید نرم افزار بروش تکرار شونده‬
‫‪ ‬فرایند آبشاری باعث می شد اعضائ تیم تا مدتی بیکار بمانند مثال آزمونگرها‬
‫‪ ‬با بکارگیری رویکرد تکرار شونده‪:‬‬
‫‪‬‬
‫‪‬‬
‫‪‬‬
‫‪‬‬
‫‪‬‬
‫‪‬‬
‫‪‬‬
‫‪‬‬
‫تغییر کردن نیازمندیها که یک واقعیت است مدنظر قرار می گیرد‬
‫مجتمع سازی بصورت "انفجار عظیم" انجام نمی گیرد‪ .‬فعالیتی که ‪%40‬‬
‫فعالیتهای کل پروژه را شامل می شد به ‪ 6‬تا ‪ 9‬مجتمع سازی با عناصر کمتر‬
‫بدل شده است‬
‫از آنجا که ریسک ها معموال در زمان مجتمع سازی ظاهر می شوند‪ ،‬طبیعتا با‬
‫رویکرد تکرار شونده زودتر یافت می شوند‪ .‬با این رویکرد به سرعت همه‬
‫اجزائ فرایند‪ ،‬ابزارها‪ ،‬نرم افزارهای تجاری‪ ،‬مهارتهای افراد و ‪ ...‬آزمون می‬
‫شوند و ریسکها یافت میگردد‪.‬‬
‫حضور سریع با یک نسخه ابتدایی از محصول در بازار رقابتی تکنولوژی‬
‫قابلیت استفاده مجدد‬
‫هنگامی که خطاها طی تکرارهای مختلف برطرف می شود‪ ،‬پس یک معماری‬
‫قوی (‪ )robust‬داریم‪.‬‬
‫تولید کنندگان سریعا توانایی های خود را بررسی کرده و افزایش می دهند‪.‬‬
‫خود فرایند هم در این مسیر بهبود می یابد‪.‬‬
‫صفحه ‪14‬‬
‫© سپهر مهر فناوری نو ‪383‬‬
‫موارد بیشتر‬
‫‪ RUP ‬فرایندی ‪ use case driven‬است‬
‫‪ RUP ‬فرایندی معماری محور است‬
‫‪ RUP ‬تکرار شونده و افزایشی است‬
‫صفحه ‪15‬‬
‫© سپهر مهر فناوری نو ‪383‬‬
‫‪Use-Case Driven‬‬
‫‪ ‬چند تعریف‬
‫‪‬‬
‫‪‬‬
‫‪‬‬
‫‪‬‬
‫کاربر = کاربر انسانی ‪ +‬دیگر سیستم ها‬
‫مورد کاربرد (‪ = )use case‬قسمتی از عملکرد‬
‫مدل مورد کاربرد = همه موارد کاربرد‬
‫‪ = Use-Case Driven‬جنبه های فرایند تولید از موارد‬
‫کاربرد نشات میگیرند (کالسها‪ ،‬توالیها‪)...،‬‬
‫صفحه ‪16‬‬
‫© سپهر مهر فناوری نو ‪383‬‬
‫‪Use-Case Driven‬‬
‫‪‬‬
‫‪‬‬
‫‪‬‬
‫‪‬‬
‫به این معنی که ابتدا راهنمای کاربر نوشته شود و‬
‫سپس کد برنامه زده شود‪.‬‬
‫به این طریق نرم افزار براساس نیازمندیهای کاربر‬
‫شکل می گیرد‬
‫ارزیابی مداوم اینکه سیستم برای هر کاربری چه کاری‬
‫باید انجام دهد‬
‫پاسخی به بحران نرم افزار دهه ‪60‬‬
‫صفحه ‪17‬‬
‫© سپهر مهر فناوری نو ‪383‬‬
‫معماری محور‬
‫‪ ‬معماری‬
‫‪ ‬مهمترین جنبه ایستا و پویای نرم افزار‬
‫‪ ‬عناصر ساختاری و واسطهایی که رفتار سیستم را در کنار‬
‫هم قرار می دهند‬
‫‪ ‬روح حاکم بر تولید نرم افزار‬
‫‪ ‬نیاز به معماری‬
‫‪‬‬
‫‪‬‬
‫‪‬‬
‫‪‬‬
‫درک سیستم‬
‫ساماندهی توسعه سیستم‬
‫کمک به استفاده مجدد‬
‫محور تکامل سیستم‬
‫صفحه ‪18‬‬
‫© سپهر مهر فناوری نو ‪383‬‬
‫مزایای روش تکرار‪-‬افزایش‬
‫مدیریت زودهنگام ریسکها پروژه‬
‫صفحه ‪19‬‬
‫© سپهر مهر فناوری نو ‪383‬‬
‫مزایای روش تکرار‪-‬افزایش‬
‫‪‬‬
‫‪‬‬
‫‪‬‬
‫‪‬‬
‫‪‬‬
‫کاهش زمان و هزینه مجتمع سازی‬
‫ایجاد معماری پایدار در مراحل اولیه‬
‫مدیریت ساده تر تغییرات‬
‫فرصت آموزش تیم در مورد دیسیپلین ها در تکرارهای‬
‫اولیه‬
‫کیفیت باالتر نرم افزار‬
‫صفحه ‪20‬‬
‫© سپهر مهر فناوری نو ‪383‬‬