معماری و ساختار كلی 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 برای كنترل خروجی‌های متعدد تولید شدهتوسط افراد زیادی كه روی یك پروژه كار می‌كنند، ضروری است. كنترل، به اجتناب ازاغتشاشِ پرهزینه كمك می‌كند و تضمین می‌نماید كه خروجی‌های بدست آمده با توجه بهبرخی انواع مسائل و مشكلاتی كه در زیر آمده‌اند ناسازگار نیستند.
• به روز رسانیهمزمان
• توجه دادن محدود شده
• نسخه‌های چندگانه

منبع:سایت آفتاب