RUP چیست ؟

معماری و ساختار کلی RUP

فرایند انجام یک پروژه تعریف می‌کند که چه کسی، چه کاری را در چه هنگام و چگونه برای رسیدن به هدف (انجام پروژه) انجام می‌دهد. در مهندسی نرم‌افزار، هدف ساختن یک محصول نرم‌افزاری و یا بهبود یک نمونه‌ی موجود است. هدف از تعیین فرایند، تضمین کیفیت نرم‌افزار، برآورده شدن نیاز‌های کاربر و قابل تخمین بودن زمان و هزینه‌ی تولید می‌باشد. علاوه بر این، تعیین فرایند، روندی جهت تحویل مصنوعات دوران تولید نرم‌افزار به کارفرما و ناظر پروژه ارائه می‌دهد تا از این طریق اطمینان حاصل کنند که پروژه روند منطقی خود را طی می‌کند و نظارت درست بر انجام پروژه ممکن است و از سوی دیگر، معیاری برای ارزیابی پروژه انجام شده می‌باشد. تا کنون متدولوژی‌های مختلفی برای فرآیند تولید نرم‌افزار ارائه شده‌اند که یکی از مشهورترین آنها RUP است.
RUP ، متدولوژی ارائه شده توسط شرکت Rational ، پرکاربردترین فرآیند تولید و توسعه نرم افزاری در دنیای کنونی است و به عنوان یک استاندارد صنعتی بالفعل در دنیای IT پذیرفته شده است. به گزارش رویتر در سال 2001 میلادی بیش از ششصد هزار شرکت تولید کننده نرم افزار، از ابزارهای شرکت Rational استفاده می کرده‌اند که این تعداد کماکان هم در حال افزایش است. این متدولوژی، برای انواع پروژه‌های نرم‌افزاری در دامنه‌های مختلف ( مانند سیستم‌های اطلاعاتی، سیستم‌های صنعتی، سیستم‌های بلادرنگ، سیستم‌های تعبیه شده، ارتباطات راه دور، سیستم‌های نظامی و ...) و در اندازه‌های متفاوت، از پروژه‌های بسیار کوچک (یک نفر در یک هفته) تا پروژه‌های بسیار بزرگ (چند صد نفر تولید کننده با پراکندگی جغرافیایی)، کاربرد دارد.
مزیت بزرگ این متدولوژی، استفاده از روش تکرار در تولید و مدیریت تولید نرم‌افزار است که این امر، امکان تولید مبتنی بر کاهش ریسک و مواجه با مشکلات اصلی در ابتدای کار و در نتیجه احتمال موفقیت بیشتر را فراهم می‌کند. از محاسن دیگر این متدولوژی مبنا قرار دادن نرم‌افزار و تولید یک معماری پایدار در ابتدای کار است، که در نتیجه امکان کشف مشکلات عمده ساختاری، تست و مجتمع سازی ممتد را از ابتدای کار فراهم می‌کند. از دیگر مزایای این روش این است که افراد تیم همزمان با پیشرفت پروژه، مطالب جدیدی فرا می‌گیرند و کیفیت فرآیند تولید نیز به طور مرتب افزایش می‌یابد.
همانطور که در شکل بالا مشاهده می‌شود، RUP دارای دو بعد است:
1. محور افقی نشان دهنده‌ی زمان است و با پیشرفت خود جنبه‌های چرخه‌ی حیات فرآیند و فازهای RUP را نشان می‌دهد.
2. محور عمودی نمایانگر دیسیپلین‌های RUP است که فعالیت‌ها را با استفاده از ماهیتشان به صورت منطقی دسته‌بندی می‌کند.

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

فازهای RUP

فازها و milestone های یک پروژه در RUP

Inception (آغازین)

هدف اصلی این فاز دستیابی به توافق میان کلیه‌ی ذینفعان بر روی اهداف چرخه‌ی حیات پروژه است. فاز Inception به دلیل تلاشهای تولید و توسعه جدید به صورت پایه‌ای اهمیت فراوانی دارد که در آن ریسک‌های نیازسنجی و تجاری مهمی وجود دارد که باید پیش از اینکه اجرای پروژه مورد توجه قرار گیرد، بررسی شوند. برای پروژه‌هایی که بر توسعه سیستم موجود متمرکزند، فاز Inception کوتاهتر است، با اینحال این فاز برای حصول اطمینان از اینکه پروژه ارزش انجام دادن دارد و امکان‌پذیر نیز هست، انجام می‌شود. اهداف اصلی فاز آغازین شامل موارد زیر است:
• بدست‌ آوردن محدوده نرم‌افزاری پروژه و محدودیت‌های آن که شامل یک دید عملیاتی، معیار پذیرش و اینکه چه چیز باید در محصول باشد و چه چیز نباید باشد، می‌شود
• مشخص کردن Use-Case های اساسی سیستم، سناریوهای اصلی عملیات که مسائل مربوط به طراحی اصلی را ایجاد می‌کند.
• نمایش و شاید توضیح حداقل یک معماری کاندیدا برای بعضی سناریوهای اصلی
• برآورد هزینه و زمان کلی برای کل پروژه

Elaboration (جزییات)

هدف فاز جزئیات تعیین معماری کلی سیستم به منظور فراهم آوردن یک زمینه‌ی مناسب برای قسمت عمده‌ی طراحی و پیاده‌سازی در فاز Construction است. معماری با درنظرگرفتن بیشتر نیازمندی‌های مهم (آن دسته از نیازمندی‌ها که تأثیر زیادی بر معمار سیستم دارد) و نیز ارزیابی ریسک کامل می‌شود. پایداری معماری از طریق یک یا چند نمونه‌ی اولیه ساختاری ارزیابی می‌‌شود. اهداف اصلی فاز جزئیات شامل موارد زیر است:
• اطمینان از اینکه معماری، نیازمندی‌ها و طرح‌ها به اندازه‌ی کافی پایدارند و ریسک‌ها به اندازه‌ی کافی کاهش یافته‌اند بطوریکه بتوان هزینه و زمان‌بندی لازم برای تکمیل تولید را پیش‌بینی کرد. برای اکثر پروژه‌ها، گذر از این مرحله‌ی مهم مانند انتقال از یک عملیات سبک و سریع و با ریسک پایین به یک عملیات با هزینه و ریسک بالا همراه با اجبار سازمانی است.
• بیان همه‌ی ریسک‌های پروژه که از نظر ساختاری اهمیت دارند.
• ایجاد یک معماری پایه، مشتق شده از سناریوهای مهم که از لحاظ ساختاری اهمیت دارند، که این معماری ریسک‌های فنی عمده پروژه را نیز مشخص می‌کند.
• تولید یک نمونه‌ی اولیه‌ی تکاملی از مولفه‌های با کیفیت تولیدی خوب، و همچنین یک یا چند نمونه‌ی اولیه‌ی اکتشافی و نمونه‌های اولیه‌ی غیر قابل استفاده جهت کاهش ریسکهای خاص مانند :
o سازش‌های مربوط به نیازمند‌ی‌ها یا طراحی
o استفاده‌ی مجدد از مؤلفه‌ها
o عملی بودن محصول یا توضیحات برای سرمایه گذاران، مشتریان و کاربران نهایی
• توضیح اینکه معماری پایه از نیازمندی‌های سیستم با هزینه‌ی منطقی و در زمان منطقی پشتیبانی می‌کند
• ایجاد یک محیط پشتیبانی کننده

Construction (ساخت)

هدف این فاز واضح سازی نیازمندی‌های باقیمانده و تکمیل تولید سیستم بر اساس معماری مبنا می‌باشد. فاز ساخت به نوعی یک فرآیند ساخت است که در آن تأکید بر مدیریت منابع و کنترل عملیات به منظور بهینه‌سازی هزینه‌ها، زمان‌بندی‌ها و کیفیت است. در این حالت یک انتقال از تولید یک نمونه‌ی ذهنی در طی فازهای Inception و Elaboration به تولید محصولات قابل استقرار در طی Construction و Transition می‌شود. اهداف اصلی فاز Construction شامل موارد زیر می‌باشد:
• کمینه کردن هزینه‌های تولید با بهینه‌سازی منابع و پرهیز از دور انداختن و دوباره‌کاری غیر ضروری
• دستیابی هرچه سریعتر به کیفیت کافی
• دستیابی هر جه سریعتر به ویرایش‌های مفید (آلفا، بتا و سایر نسخه‌های تست)
• کامل کردن تحلیل، طراحی، تولید و تست کارآیی مورد نیاز
• تولید تکراری و گام به گام یک محصول کامل که آماده‌ی انتقال به محیط کاربران باشد
• تصمیم در مورد اینکه آیا نرم‌افزار، سایت‌ها و کاربران همه برای استقرار طرح آمادگی دارند
• دستیابی به میزانی از موازی سازی در کار تیم‌های تولید

Transition (انتقال)

تمرکز این فاز بر این است که تضمین نماید نرم‌افزار برای کاربران نهایی آماده می‌باشد. فاز Transition می‌تواند به چندین تکرار تقسیم شود، و شامل تست کردن محصول برای آماده‌سازی جهت انتشار و ایجاد تنظیمات کوچک بر اساس بازخورد کاربر می‌باشد. در این نقطه از چرخه‌ی حیات، بازخورد کاربر باید بطور عمده بر تنظیم دقیق محصل، پیکربندی، نصب و نکات مربوط به قابلیت استفاده تمرکز یابد، و همه‌ی نکات ساختاری اصلی باید هرچه زودتر در چرخه‌ی حیات پروژه طرح شوند. با به اتمام رسیدن فاز Transition اهداف چرخه‌ی حیات باید برآورده شده باشند و پروژه در موقعیتی باشد که بتوان آنرا خاتمه داد. در برخی موارد، پایان چرخه‌ی حیات فعلی ممکن است با آغاز چرخه‌ی حیات بعدی در مورد همان محصول همزمان شود و ما را به سمت تولید یا ویرایش دیگری هدایت کند. برای پروژه‌های دیگر، پایان فاز Transition ممکن است با تحویل کامل خروجی‌ها به گروه سومی که ممکن است مسؤول عملیات نگهداری و پیشرفت سیستم تحویل دهده شده می‌باشند، همزمان شود. این فاز بر اساس نوع محصول در فاصله‌ی بسیار ساده تا بی‌نهایت پیچیده قرار دارد. نصب یک نسخه‌ی جدید از یک بسته نرم‌افزاری موجود ممکن است بسیار ساده باشد، در حالیکه جایگزینی سیستم کنترل ترافیک هوایی یک کشور ممکن است بسیار پیچیده باشد. فعالیت‌هایی که در طول یک تکرار در فاز Transition انجام می‌گیرد به هدف بستگی دارند. برای مثال معمولاً در هنگام رفع اشکالات، پیاده‌سازی و تست کافی هستند. با این وجود اگر ویژگیهای جدیدی باید اضافه شوند، این تکرار شبیه به تکراری در فاز Construction می‌شود که نیازمند تحلیل و طراحی و غیره است. فاز Transition زمانی وارد عمل می‌شود که یک خط مبنا آنقدر بالغ شده که بتواند در دامنه‌ی کاربر نهایی استقرار یابد. این امر بطور نمونه نیازمند این است که تعدادی زیر مجموعه‌ی قابل استفاده از سیستم با کیفیت قابل قبول و مستندات کاربر، کامل شده باشند، تا انتقال به کاربر نتایج مثبتی را برای همه‌ی گروه‌ها در بر داشته باشد. اهداف مهم فاز Transition عبارتند از:
• تست بتا برای تشخیص اعتبار سیستم جدید با توجه به انتظارات کاربر
• تست بتا و عملیات موازی همراه با یک سیستم قدیمی که در حال جایگزینی می‌باشد.
• تبدیل پایگاه‌های داده‌ی عملیاتی
• آموزش کاربران و نگهداری کنندگان
• بازاریابی، توزیع و فروش برای نخستین انتشار محصول
• تنظیم فعالیت‌ها از قبیل رفع اشکال، افزایش کارایی و قابلیت استفاده
• ارزیابی خط مبناهای استقرار در مقایسه با تصویر کلی و معیار قابلیت قابل قبول برای محصول
• دستیابی به موافقت ذینفع در مورد اینکه خط مبناهای استقرار کامل می‌باشند
• دستیابی به موافقع ذینفع در مور اینکه خط مبناهای استقرار با معیار ارزیابی تصویر کلی سازگارند

دیسیپلین‌های RUP

دیسیپلین مجموعه‌ای از کارهای به هم مرتبطی است که برای انجام جنبه خاصی از یک پروژه انجام می‌شوند. متدولوژی RUP دارای 6 دسیسپلین اصلی (مربوط به تولید محصول) و 3 دیسیپلین کمکی (مربوط به تیم و محیط تولید) است که در ادامه به ترتیب معرفی خواهند شد.

Business Modeling (مدل‌سازی کسب و کار)

هداف مدل‌سازی کسب و کار عبارتند از:
• شناخت ساختار و دینامیک‌های سازمانی که در آن یک سیستم باید استقرار یابد(سازمان هدف.)
• شناخت مشکلات فعلی در سازمان هدف و تشخیص پتانسیل‌های بهبود
• تضمین اینکه مشتری، کاربر نهایی و تولید کنندگان یک شناخت مشترک از سازمان هدف دارند.
• هدایت نیازمندی‌های سیستم که برای حمایت از سازمان هدف مورد نیازند.
• دیسیپلین‌ مدل‌سازی کسب و کار توضیح می‌دهد که برای رسیدن به این هدف چگونه می‌توان یک تصویر کلی از سازمان را تولید نمود، و براساس این تصویر کلی فرآیندها، نقش‌ها و مسؤولیت‌های آن سازمان را در یک مدل Use-case کسب وکار و یک مدل شیء کسب و کار تعریف کرد

Requirements (نیازمندی‌ها)

اهداف دیسیپلین نیازمندی‌ها عبارتند از:
• تشخیص و نگهداری موارد توافق با مشتری‌ها و سایر ذینفعان در مورد کارهایی که سیستم باید انجام دهد.
• فرآهم آوردن شناخت بهتر از نیازمندی‌های سیستم برای تولید کنندگان سیستم
• تعریف مرزهای و حدود سیستم
• فراهم کردن یک پایه برای طرح ریزی مفاهیم تکنیکی تکرارها
• فراهم کردن یک پایه برای تخمین مخارج و زمان تولید سیستم
• تعریف یک واسط کاربر برای سیستم با تمرکز بر روی نیازها واهداف کاربران
برای دستیابی به این اهداف، ابتدا فهم تعریف و محدوده‌ی مسأله‌ای که سعی داریم با این سیستم آن را حل کنیم، حائز اهمیت می‌باشد. قوانین کسب و کارف مدل Use-Case کسب و کار و مدل شیء کسب و کار که در طول مدل‌سازی کسب و کار تولید شده به عنوان ورودی با ارزشی برای این تلاش خواهند بود. در این راستا ذینفعان تشخیص داده می‌شوند و درخواستهای ذینفعان استخراج، جمع‌آوری و تجزیه و تحلیل می‌شوند. یک مستند تصویر کلی، یک مدل Use-Case ، Use-Case ها و مشخصه‌های تکمیلی برای توضیح کامل سیستم تولید می‌شود. این توضیح درواقع کاری را که سیستم انجام خواهد داد بیان می‌کند. این مستندات بعنوان منابع مهم اطلاعات تولید می‌شود. در تولید این مستندات باید خواسته‌های همه ذینفعان را در نظر گرفت.

Analysis & Design (تحلیل و طراحی)

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

Implementation (پیاده‌سازی)

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

Test (آزمون)

دیسیپلین تست از بسیاری جهات مانند یک ارائه دهنده خدمات برای سایر دیسیپلین‌ها عمل می‌کند. تمرکز اولیه تست کردن بر بررسی و ارزیابی کیفیت‌های محقق شده از طریق کارهای زیر است:
• یافتن و مستند کردن نقایص در کیفیت نرم‌افزار
• آگاهی دادن در مورد کیفیت نرم‌افزار بررسی شده
• اثبات اعتبار فرضیاتی که در طراحی و مشخصات نیازمندی‌ها ساخته شدند، از طریق نمایش‌های واقعی
• تصدیق عملکردهای محصول نرم‌افزار همانطور که طراحی شده است.
• تصدیق اینکه نیازمندی‌ها بدرستی پیاده‌سازی شده‌اند
یک تفاوت جالب ولی تاحدی ظریف میان دیسیپلین تست و سایر دیسیپلین‌ها در RUP این است که تست گرفتن، اساسا وظیفه‌ی یافتن و ارائه ضعف‌ها در محصول نرم‌افزار را داراست. برای اینکه این تلاش موفقیت‌آمیز باشد، لازم است از یک روش نسبتا منفی و مخرب استفاده شود تا روشی سازنده. مسأله‌ای که بسیار حائز اهمیت می‌باشد این است که از دو روش اجتناب کنیم : یکی روشی که بطور مناسب و موثر نرم‌افزار را بکار نگیرد و مشکلات و ضعف‌های آن را نشان ندهد و دیگری روشی که آنقدر مخرب است که احتمالا هیچگاه کیفیت محصول نرم‌افزاری را قابل قبول درنظر نمی‌گیرد.

Deployment (استقرار)

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

Environment (محیط)

دیسیپلین محیط بر فعالیت‌هایی که برای پیکربندی فرآیند برای یک پروژه لازم و ضروری‌اند، متمرکز می‌شود. این دیسیپلین فعالیت‌های مورد نیاز برای تولید رهنمودهایی که در جهت پشتیبانی از یک پروژه لازم می‌باشند را توضیح می‌دهد. هدف فعالیت‌هایی محیطی فراهم آوردن محیط تولید (هم فرآیندها و هم ابزاری که تیم تولید را پشتیبانی می‌کنند) برای سازمان تولید کننده نرم‌افزار می‌باشد.
جعبه ابزار مهندس فرآیند پشتیبانی ابزاری را برای پیکربندی یک فرآیند فراهم می‌کند. این مورد شامل ابزارها و نمونه‌هایی برای ایجاد سایتهای وب پروژه و سازمان بر اساس RUP می‌شود.

Project Management (مدیریت پروژه)

مدیریت پروژه نرم‌افزاری، هنر متوازن ساختن اهداف متقابل، مدیریت ریسک و غلبه بر محدودیت‌ها برای تحویل موفقیت آمیز محصولی است که هم نیازهای مشتریان ( کسانی که برای سیستم پول می‌پردازند) و هم نیازهای کاربران را برآورده کند. این حقیقت که پروژه‌های بسیار کمی هستند که واقعا موفقیت‌آمیزند برای توضیح سخت بودن این کار، کافی می‌باشد
اهداف این دیسیپلین عبارتند از:
• فراهم کردن یک چارچوب برای مدیریت پروژه‌های صرفاً نرم‌افزاری
• فراهم کردن رهنمودهای عملی برای طرح‌ریزی، تعیین نیروی انسانی، اجرا و نظارت بر پروژه‌ها
• فراهم کردن یک چارچوب برای مدیریت ریسک
• با این وجود، این دیسیپلین از RUP برای پوشش دادن همه‌ی جنبه‌های مدیریت پروژه نیست. برای مثال این دیسیپلین موارد زیر را پوشش نمی‌دهد :
* مدیریت افراد : استخدام، آموزش، رهبری
* مدیریت بودجه : تعیین، تخصیص و غیره
* مدیریت قراردادها :‌ با پشتیبانی کنندگان و مشتریان
این دیسیپلین بطور عمده روی جنبه‌های مهم یک فرآیند تکراری تمرکز می‌کند که عبارتند از :
* مدیریت ریسک
* طرح ریزی برای یک پروژه‌ی تکراری، از طریق چرخه‌ی حیات و برای یک تکرار بخصوص
* نظارت بر پیشرفت یک پروژه‌ی تکراری و متریک‌ها

Configuration & Change Management (مدیریت پیکربندی و تغییرات)

برای تأویل و تفسیر ”مدل بلوغ قابلیت“ انستیتو مهندسی نرم‌افزار( SEI CMM )، مدیریت پیکربندی و درخواست تغییر، تغییرات را به سمت خروجی‌های یک پروژه کنترل می‌کند و همچنین صحت و تمامیت خروجی‌های پروژه را حفظ می‌کند.
مدیریت پیکربندی و درخواست تغییر ( CRM, CM ) شامل موارد زیر می‌باشند:
• تشخیص موارد پیکربندی
• محدود کردن تغییرات آن موارد
• رسیدگی به تغییراتی که برای آن موارد ساخته شده
• تعریف و مدیریت پیکربندی آن موارد
متدها، فرآیندها و ابزاری که برای ایجاد تغییر و مدیریت پیکربندی برای یک سازمان استفاده می‌شوند، می‌توانند بعنوان سیستم CM سازمان مورد توجه قرار گیرند.
سیستم مدیریت پیکربندی و درخواست تغییر (سیستم CM ) برای یک سازمان اطلاعات کلیدی در مورد تولید محصول را نگهداری می‌کند. این اطلاعات عبارتند از : ‌ترفیع، استقرار و فرآیندهای نگهداری. بعلاوه یک پایگاه داده محصولاتی را که بصورت بالقوه قابل استفاده مجدد می‌باشند، نگهداری می‌کند.
یک سیستم CM برای کنترل خروجی‌های متعدد تولید شده توسط افراد زیادی که روی یک پروژه کار می‌کنند، ضروری است. کنترل، به اجتناب از اغتشاشِ پرهزینه کمک می‌کند و تضمین می‌نماید که خروجی‌های بدست آمده با توجه به برخی انواع مسائل و مشکلاتی که در زیر آمده‌اند ناسازگار نیستند.
• به روز رسانی همزمان
• توجه دادن محدود شده
• نسخه‌های چندگانه

http://www.rasekhoon.net/Article/Show-51336.aspx

www.pcdoc.blogsky.com