بخشی از مقاله

مقدمه ای بر Rational Unified process


1-1 Rational Unified process چیست؟
هنگامیکه این سئوال پرسیده می شود، معمولاً جوابهای مختلفی شنیده می شود. این پاسخها بسته به اینکه سؤال از چه کسی پرسیده شده و زمینه سؤال چه بوده متفاوتند. آنچه موضوع را عجیب می کند این است که Rational Unified process ( RUP) به سه مورد کاملاً متفاوت اشاره می کند :
• RUP یک روش تولید و توسعه نرم افزار می باشد که تکراری ، معماری محور و Use – Case گر است، و در مقالات و کتابهای مختلفی در مورد آن صحبت شده است. کاملترین اطلاعات در مورد RUP را می توان در خود محصول یافت که شامل راهنمائیهای مشروح، مثالها و قالبهایی است که کل چرخه حیات نرم افزار را شامل می شوند.


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


1-1-1 روش RUP
در این قسمت در مورد اصول اساسی که RUP جهت تسهیل فرآیند تولید و توسعه نرم افزار، از آنها استفاده می کند و همچنین روش تکراری برای بکار بردن این اصول بحث می کنیم.
1-1-1-1 اصول اساسی روش RUP
هسته RUP از چندین اصل اساسی تشکیل شده است که از تولید تکراری4 پشتیبانی کرده و معرف ماهیت آن می باشد.
این اصول از مجموعه ای از پروژه های موفق، جمع آوری شده و چکیده آن به صورت مجموعه ا

ی از رهنمودهای ساده در آمده اند. این اصول در ذیل شرح داده می شوند :
حمله سریع و مداوم به ریسک های اصلی .... در غیر اینصورت آنها به شما حمله خواهند کرد.
تضمین کنید که محصول با ارزشی به مشتری تحویل می دهید.
روی نرم افزار قابل اجرا متمرکز بمانید.
تغییرات را هرچه زودتر در پروژه بگنجانید.
هرچه زودتر معماری قابل اجرایی را مبنا قرار دهید.
سیستم را با مؤلفه ها بسازید.
در قالب یک تیم با هم کار کنید.
کیفیت را بعنوان یک اصل قرار دهید نه یک فرع
1-1-1-2 RUP و تولید تکراری
اکثر تیمهای نرم افزاری هنوز هم از فرآیند آبشاری برای پروژه های تولیدی استفاده می کنند که در آن هر فاز را در یک مرحله کامل می کنند. در این توالی ابتدا شناخت نیازمندیها انجام می شود و سپس تحلیل و طراحی و بعد از آن پیاده سازی یا مجتمع سازی و سپس تست انجام می شود. رایج تر از این روش، یک روش تست آبشاری تغییر یافته است که در آن حلقه های بازخورد به این جریان کلی و اساسی که توضیح داده شد، اضافه می شود. چنین روشهایی، اعضاء کلیدی تیم را برای مدت طولانی بیکار می کند و تست کردن را تا پایان چرخة حیات پروژه، یعنی زمانی که حل کردن مشکلات سخت و پرهزینه است و تهدیدهای جدی برای ضرب الاجلهای انتشار نرم افزار وجود دارد، به تأخیر می اندازد.
برخلاف این روش، RUP از یک روش تکراری استفاده می کند، یعنی یک توالی از گامها افزایشی یا تکرارها. هر تکرار چنانکه در شکل 1-1 می بینید شامل تعداد زیادی دیسیپلین های تولید اس

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

 


شکل 1-1 تولید تکراری در RUP RUP , از یک روش تکراری استفاده می کند. در هر تکرار، مقداری از نیازمندیها و کار تحلیل، طراحی، پیاده سازی و تست انجام می شود. هر تکرار برای تولید یک برنامة قابل اجرا که یک گام به محصول نهائی نزدیک تر است و بر اساس نتایج تکرارهای قبلی ساخته می شود.

تکرارهای اولیه بر نیازمندیها، تحلیل و طراحی و تکرارهای بعدی بر پیاده سازی و تست تأکید دارند. روش تکراری به دلایل زیر نسبت به روش آبشاری برتری دارد:
روش تکراری با نیازمندیهای متغییر سازگار است.
در روش تکراری ، مجتمع سازی یک اتفاق بزرگ در آخر پروژه نیست.
در روش تکراری، ریسکها معمولاً در مجتمع سازیهای اولیه کشف می شوند
در روش تکراری، مدیریت می تواند در محصول، تغییرات تاکتیکی ایجاد کند.
در روش تکراری، استفادة مجدد آسان می شود.
در روش تکراری ، نقص ها در طی چندین تکرار کشف و تصحیح می شوند.
در روش تکراری، از پرسنل پروژه بهتر استفاده می شود.
در روش تکراری، اعضاء تیم در ضمن انجام کار، مطالب جدیدی فرا می گیرند.
در روش تکراری، خود فرآیند تولید نیز همراه با انجام کار ، اصلاح شده و بهبود می یابد.
1-1-2 یک فرآیند مهندسی نرم افزار خوش تعریف
متدولوژی RUP با تکنیکهای طراحی نرم افزار، طراحی شده است. RUP مخصوصا ً با استفاده از متامدل مهندسی فرآیند نرم افزار ( SPEM) طراحی می شود که استانداردیست برای مدلسازی فرآیند بر اساس UML . شکل 2-1 ، معماری کلی RUP را نشان می دهد.
این فرآیند ، دارای دو ساختار یا بعد است :
• ساختار دینامیک ( پویا) . بعد از افقی، ساختار دینامیک یا بعد زمانی فرآیند را نشان می دهد. این ساختار نشان می دهد که فرآیند چگونه در قالب چرخه ها، فازها، تکرارها و مراحل مهم، موجود در چرخة حیات یک پروژه ، بیان می شود.
• ساختار استاتیک . بعد عمودی ساختار استاتیک فرآیند را نشان می دهد. این ساختار توضیح می دهد که عناصر فرآیند (فعالیت ها، دیسیپلینها ، خروجی ها و نقشها) چگونه به طور منطقی و به صورت دیسیپلینهای اصلی فرآیند ( با جریان کارها) دسته بندی می شوند.

شکل 1-2 دو بعد RUP , RUP یا دو بعد سازماندهی شده: جنبة دینامیک (افقی) ، چرخه ه

ا، فازها، تکرارها و مراحل مهم را نشان می دهد و جنبة استاتیک (عمودی) ، فعالیت ها، دیسپلینها، خروجیها و نقش ها را نشان می دهد.
ساختار دینامیک RUP
ساختار دینامیک با چرخة حیات و بعد زمان پروژه سرو کار دارد . RUP ، یک روش ساختار بندی شده برای تولید تکراری فراهم می کند که یک پروژه را به 4 فاز تقسیم می کند. Transition

Constuction , Elabortion , Inception .
هر فاز شامل یک یا چند تکرار است که با تولید خروجی های تکنیکی لازم در نهایت به اهداف تجاری آن فاز را برآورده سازند. (شکل 1-3) تعداد تکرارها به اندازة مورد نیاز، برای رسیدن به اهداف فاز باشد، نه بیشتر. اگر اهدافی که برای در فاز طرح ریزی شده، مورد توجه قرار نگیرند، یک تکرار دیگر نیز باید به فاز اضافه شود که پروژه را به تأخیر می اندازد. برای اجتناب از اینکار مطمئن شوید که هر تکرار، دقیقاً بر روی عملیاتی که برای دستیابی به اهداف تجار آن فاز مورد نیاز است، متمرکز شده است. برای مثال، تمرکز زیاد بر نیازمندیها در Inception مناسب است.
• Inception در این فاز با شناخت سطح بالای کلیة نیازمندیها و ایجاد محدودة سیستم، مشخص می شود که چه سیستمی را باید ساخت. در این راستا باید بسیاری از ریسکهای تجاری را کاهش داد. مورد کسب و کار را برای ساخت سیستم فراهم کرد و از کلیة ذی نفعان در مورد اینکه آیا این پروژه انجام شود یا نه، موافق گرفت.
• Elaboration در این فاز باید مراقب بسیاری از تکالیف مشکل تکنیکی باشید، مانند طراحی ، پیاده سازی، تست و تعیین خط مبنای معماری قابل اجرا که خود شامل زیر سیستم ها و واسط های آنها، مؤلفه های کلیدی و مکانیسم های معمای (مانند چگونگی برخورد با ارتباط بین فرآیندی یا پایداری) ، می باشد . همچنین ریسکهای تکنیکی عمده مانند ریکسهای مجادله بر سر منابع ، ریسکهای عملکردی و ریسکهای امنیت داده را با پیاده سازی و تعیین اعتبار کد واقعی مورد توجه قرار دهید.
• Construction بخش عمدة پیاده سازی را در حین حرکت از معماری قابل اجرا به نسخة اول عملیاتی سیستم انجام دهید. برای تضمین اینکه سیستم قابل استفاده است و نیازهای کاربر را برآورده می کند، چندین نسخه داخلی و آلفا مستقر کنید. این فاز را با استقرار یک نسخه کارکردی کامل از سیستم شامل نصب و مستندات پشتیبانی حمایتی و ابزار آموزشی خاتمه دهید ( هرچند سیستم احتمالاً هنوز نیازمند تنظیم کارآیی، عملکرد و کیفیت کلی است).
• Transition تضمین کنید که نرم افزار، نیازهای کاربر خود را برآورده می کند. این کار شامل تست محصول به منظور آمادگی برای انتشار و انجام تنظیمات جزئی بر اساس بازخورد کاربر است. در این مقطع از چرخة حیات، بازخورد کاربر به طور عمده بر تنظیم مناسب محصول، پیکربندی، نصب و قابلیت های استفاده متمرکز است. همة این موارد عمدة ساختاری باید در چرخة حیات پروژه به دست آید.


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


* نقشها – کار را چه کسی انجام می دهد. ( Who)
* فعالیت ها – کار چگونه می شود. ( HOW)
* خروجی ها – حاصل کار چه باید باشد. (What)
* جریانهای کار – کار در چه زمانی باید انجام شود ( When)
دیسیپلین ها
نهایتاً همة عناصر فرآیند (نقشها، فعالیت ها، خروجیها و مفاهیم مربوطه، رهنمودها و قالبها) بصورت منطقی در درون ظرفی قرار می گیرند که دیسیپلین نام دارد. در RUP استاندارد 9 دیسیپلین وجود دارد.
این لیست قطعی نیست و هر کمپانی که محصول RUP را توسعه می دهد می تواند دیسیپلین های بیشتری را معرفی نماید.
دیسیپلین های RUP
• مدلسازی کسب و کار
• نیازمندیها
• تحلیل و طراحی
• پیاده سازی
• استقرار
• تست
• مدیریت پروژه
• مدیریت پیکربندی و تغییرات
• محیط
1-1-3 RUP – یک فرآیند با قابلیت سفارشی شدن
هر پروژه و سازمانی نیازهایی مخصوص به خود را دارد، و به فرآیندی که با شرایط خاصشان وفق داده شود نیازمند است. برای پاسخ گفتن به این نیازمندیها، محصول RUP یک چارچوب فرآیند کامل را ایجاد می کند که از تلفیق قسمت های مختلف، ساخته می شود :
• بهترین تجربه ها : RUP دارای یک کتابخانه از بهترین تجربه ها می باشد که توسط بخش نرم افزار IBM و شرکای آن تولید شده است. این کارکردهای عالی بطور پیوسته در حال تکامل می باشند و از حوصلة این کتاب خارجند. بهترین تجربه ها بصورت فازها، نقش ها، فعالیت ها، خروجیها و جریانهای کار بیان می شوند.


• ابزار تحویل فرآیند . RUP تحت کنترل تولید کننده است زیرا بصورت Online و با استفاده از تکنولوژی وب تحویل داده می شود نه کتا و صحافی . این نوع تحویل، فرآیند را قادر می سازد که با بسیاری از ابزار تولید و توسعه نرم افزار در Rational Suite و هر ابزار دیگری تلفیق شود تا تولیدکنندگان بتوانند فرآیند را در داخل ابزاری که مورد استفاده قرار می دهند. هدایت کنند.
• ابزار پیکربندی. پیمانه ای بودن RUP و شکل الکترونیکی ، آنرا قادر می سازد که متناسب سازی و پیکربندی شود تا با نیازهای خاص یک سازمان تولید کننده متناسب شود. این مسأله بصورت مختصر در بخش پیکربندی و ابزار تألیف فرآیند توضیح داده شده است.
• ابزار تألیف فرآیند. RPW یک ابزار تألیف فرآیند است که ایجاد بهترین تجربه ها را در قالب RUP امکان پذیر می سازد (برای جزئیات بیشتر به مستندات RUP مراجعه کنید.)
• اتحادیه / بازار : اتحادیه Online شبکه توسعه دهندگان رشنال (RDN) این امکان را برای کاربر فراهم می کند تا با همتاها و افراد ماهر تبادل تجربیات نموده و با استفاده از خروجیها، مقالات یا محتوای اضافی RUP به جدیدترین اطلاعات دست یابند.
1-6 چه کسی از محصول RUP استفاده می کند؟
تقریباً 10.000 کمپانی در حال استفاده از محصول RUP می باشند. رویتر گزارش داد که در سال 2001 بیش از ششصد هزار شرکت تولید کنندة نرم افزار از محصولات Rational استفاده می کردند. این کمپانی ها از محصول RUP در قلمروهای کاربردی گوناگون استفاده می کنند، که بصورت یکنواخت شامل پروژه های بزرگ و کوچک می شوند. این گوناگونی، تطبیق پذیری و قابلیت کاربرد وسیع محصول RUP را نشان می دهد. در اینجا نمونه هایی از صنایع گوناگون در سراسر دنیا که RUP استفاده می کنند آمده است :
• ارتباطات راه دور
• حمل و نقل ، هوا – فضا، صنایع دفاع
• ساخت و تولید


• خدمات مالی
• مجتمع سازان سیستم ها
تکمیل می شود، اما هر بار با تأکید متفاوتی بر فازهای مختلف چرخه های بعدی، که چرخه های تکامل نامیده می شوند. هنگامی که محصول از چندین چرخه می گذرد، نسلهای جدیدی ایجاد می شود.
فاز Inception
3-1 اهداف
* بدست آوردن محدوده نرم افزاری پروژه و محدودیت های آن که شامل یک دید عملیاتی ، معی

ار پذیرش و اینکه چه چیز باید در محصول باشد و چه چیز نباید باشد، می شود.
* مشخص کردن Case – Use های اساسی سیستم، سناریوهای اصلی عملیات که مسائل مربوط به طراحی اصلی را ایجاد می کند.
* نمایش و شاید توضیح حداقل یک معماری کاندیدا برای بعضی سناریوهای اصلی.
* برآورد هزینه و زمانی کلی برای کل پروژه ( و برآوردهای تفضیلی برای فاز Elaboration که بلافاصله به دنبال آن خواهید بود)
فاز Elaboration
4-1 اهداف
اهداف اصلی فاز Elaboration شامل موارد زیر است :
• به منظور اطمینان از اینکه معیاری، نیازمندیها و طرح ها به اندازة کافی پایدارند و ریسکها به اندازة کافی کاهش یافته اند بطوریکه بتوان هزینه و زمان بندی لازم برای تکمیل تولید را پیش بینی کرد. برای اکثر پروژه ها، گذر از این مرحله مهم مانند انتقال از یک عملیات سبک و سریع و با ریسک پایین به یک عملیات با هزینه و ریسک بالا همراه با اجبار سازمانی است.
• به منظور بیان همة ریسکهای پروژه که از نظر ساختاری اهمیت دارند.
• به منظور ایجاد یک معماری پایه، مشتق شده از سناریوهای مهم که از لحاظ ساختاری اهمیت دارند، که این معماری ریسکهای فنی عمده پروژه را نیز مشخص می کند.
• به منظور تولید یک نمونة اولیة تکاملی از مؤلفه های با کیفیت تولیدی خوب و همچنین یک یا چند نمونة اولیة اکتشافی و نمونه ها اولیة غیرقابل استفاده جهت کاهش ریسکهای خاص مانند :
• سازش های مربوط به نیازمندیها یا طراحی
• استفادة مجدد از مؤلفه ها
• عملی بودن محصول یا توضیحات برای سرمایه گذاران ، مشتریان و کاربران نهایی
• به منظور توضیح اینکه معماری پایه از نیازمندیهای سیستم با هزینة منطقی و در زمان منطقی پشتیبانی می کند.
• به منظور ایجاد یک محیط پشتیبانی کنندهو
برای دستیبای به این اهداف اصلی، راه اندازی محیط پشتیبان برای پروژه نیز به همین اندازه اهمیت دارد. این کار شامل ایجاد یک مورد تولید و توسعه، ایجاد قالب ها، رهنمودها و راه اندازی ابزار می شود.

در متن اصلی مقاله به هم ریختگی وجود ندارد. برای مطالعه بیشتر مقاله آن را خریداری کنید