تجزیه و تحلیل نرم افزار با مدل های UML و RUP


تجزیه وتحلیل نرم افزار بامدل های RUPوUML

استاد محترم:

توسط:

نام درس:

عنوان رشته تحصیلی: کامپیوتر گرایش (نرم افزار)

گروه آموزشی کامپیوتر

زمستان

فهرست

عنوان صفحه
فصل اول :مهندسی نرم افزار………………………………………….. 1
درخت تحقیق فصل اول ……………………………………………………………. 2
بخش 1: مقدمه ………………………………………………………………….. 3
بخش 2: تعریف مهندسی نرم افزار………………………………………………..4
بخش 3: فرایند تولید نرم افزار…………………………………………………………6
بخش4: روشهای تولید نرم افزار………………………………………………………….9
بخش5 : راهکارهای موفق مهندسی نرم افزار در تولید نر م افزار ومعرفی rup………….13
فصل دوم: آر.یو.پی چیست؟………………………………….16
درخت تحقیق فصل دوم:…………………………………………………………17
بخش1: مقدمه ی بر معماری نرم افزار…………………………………………..18
بخش2: معماری rup چیست ؟……………………………………………….19
بخش3: اهداف و ویژگی های rup………………………………………………28
فصل سوم: زبان یکپارچه مدل سازی UMLچیست؟…………….31
درخت تحقیق سوم: ……………………………………………………………………..32
بخش1: مقدمه ای بر uml ………………………………………………………..34
بخش2: ویژگی های ونمودارهای در uml …………………………………….37
پیوست:……………………………………………………………………………………..41
فهرست منابع وماخذ:…………………………………………………………………………43

مقدمه پروژه :
یکی از مباحث مهم در علم کامپیوتر بحث مهندسی نرم افزار می باشد که متاسفانه در ایران سایت ها کمتر به آن پرداخته می شود . در حالیکه امروزه شرکت ها بدون داشتن اصول مشخص مهندسی نرم افزار هیچگاه تصمیم به ایجاد سیستم های نرم افزاری نمی گیرند.
طراحی و تولید سیستم های نرم افزاری دارای یک چرخه حیات می باشد که در علم مهندسی نرم افزار به بررسی این چرخه حیات و عوامل مرتبط با آن پرداخته می شود . به طور کلی مراحل این چرخه به شرح زیر می باشد :
* فعالیت جمع آوری نیازمندی های و مشخص کردن آنها . این نیازمندی ها کاری را که سیستم می بایست انجام دهد را مشخص می کنند .
* فعالیت تحلیل نیازمندی ها برای درک بهتر آنها .
* فعالیت طراحی برای اینکه مشخص شود که سیستم چگونه نیازمندی ها را برآورده می کند .
* فعالیت ساخت سیستم .
* آزمایش سیستم برای تایید اینکه آیا سیستم نیازمندی ها را برآورده کرده است یانه ؟
* ودرنهایت تحویل سیستم می باشد.
معماری نرم افزار:
معماری یعنی ارایه توصیفی فنی از یک سیستم که نشان دهنده ساختار اجزاء آن، ارتباط بین آنها، و اصول و قواعد حاکم بر طراحی آن، و تکامل آنها در گذر زمان باشد.
از بدو مطرح شدن نرم افزار تاکنون ، معماری های متفاوتی بمنطور طراحی و پیاده سازی ارائه شده است .که یکی از این معماری های نرم افزار معماری یا متدلوژی rupمی باشد.
یک پروسه چابک، پروسه ای است که همیشه آماده در آغوش کشیدن درخواستهای جامعه بوده و این درجه از سازگاری را دارا باشد. بنابراین منظور از سرعت عمل، فقط کاستن از حجم پروسه تولید نرم افزار یا سرعت ارائه آن به بازار نیست؛ بلکه منظور، انعطاف پذیری و حفظ کیفیت است. مطلبی که در این مقاله قصد توضیح آن را داریم این است که RUP ساختاری پروسه ای (چیو 2000) است که امکان انعطاف پذیری را برای تولید کنندگان نرم افزار فراهم می آورد.
منظور از RUP چیست؟
در این اینجا از چند منظر به RUP خواهیم پرداخت:
RUP یک پروسه تولید نرم افزار است.
RUP مجموعه ای از تجربیات بسیار عالی تولید نرم افزار را که در عمل با آنها برخورد شده است، در خود دارد.
همانند یک محصول نرم افزاری به بازار ارائه شده و به فروش می رسد با این تفاوت که RUP اولین ساختار تولید نرم افزار را ارائه داده و گام نخست را در این زمینه برداشته است.

مدل سازس سیستمهای نرم افزاری(uml):
برای چینش اجزاء مختلف سیستم نرم افزاری و نمایش روابط بین آنها و سایر موجودیتهای سیستم نرم افزاری . برای اینکه طراحی مدل برای سیستمهای نرم افزاری قالبی یکدست و یکپارچه و جهان شمول داشته باشد و تبادل اطلاعات بین مدلهای طراحی شده توسط افراد مختلف امکان پذیر باشد تلاشهای متعددی صورت گرفته است که UML یکی از آنهاست ، که در حال حاضر متداولترین استاندارد تولید مدل برای سیستمهای نرم افزاری در سراسر دنیاست . UML مخفف Unified Modeling Language است . UML برای مدل سازی سیستمهای نرم افزاری و تسهیل طراحی شیء گرای سیستم 9 دیاگرام ( و استانداردهای مرتبط با هرکدام ) را ارائه مینماید . قبل از توضیح بیشتر و ارائه تعاریف مقدماتی به نکته ذیل توجه کنید اغلب سوال میکنند که چرا UML مهم است و این روزها مانور زیادی روی آن میشود ؟ آیا لزومی دارد که به UML مسلط شویم ؟ آیا اصولا" این جانور به درد ما میخورد در جواب باید گفت: تا حالا دیده اید که کسی یک ساختمان بزرگ با پیچیدگیهای مختلف را "بدون نقشه" و الگوی از پیش معین شده بسازد و این پروژه موفقیت آمیز باشد ؟ آیا تا کنون شنیده اید که هیچ کدام از کارخانه های تلوزیون سازی بودن هیچ نقشه و پیش بینی فنی موفق به ساخت تلوزیونی شوند که کار کند ؟ یا اصلا" ساخته شود ؟ آیا تا کنون دیده اید کشوری بدون سیاستهای کلان و بدون سنجش جوانب امر ، موفق به مدیریت امور داخلی خود شود ؟ و ده ها سوال از این دست ! خواندن این سوالها بدون اینکه حتی ثانیه ای به جواب انها فکر کنید ، خود ، جواب به سوالات است. UML به عنوان استانداردی برای طراحی و پیش بینی جزئیات فنی سیستم نرم افزاری ، نحوه ارتباط اجزاء ، نوع و نحوه کارکرد قسمتهای مختلف و … یکی از ملزومات تولید کنندگان نرم افزار در دنیای امروز است . حتی اگر مستقل کار میکنید و نرم افزارهای کوچک تولید میکنید با استفاده از UML در "اغلب" موارد به بالاترین حد بهینگی مراحل طراحی و تولید نرم افزارتون خواهید رسید و نکته آخر این که UML و استانداردهای آن و ابزارهای آن ها که آنقدر ساده و سهل هستند که صرف هزینه و وقت برای یادگیری و تسلط بر آنها نسبت به مزایائی که در قبال آن کسب خواهید کرد تقریبا غیر قابل توجه است

فصل اول:

مهندسی نرم افزار چیست؟

(SOFTWARE ENGINEERING)

درخت تحقیق (ساختار تحقیق فصل اول):

بخش 1:مقدمه
بخش 2: تعریف مهندسی نرم افزار
بخش3: فرایند تولید نرم افزار
بخش4:روشهای تولید نرم افزار
بخش 5: راهکارهای موفق مهندسی نرم افزار در تولید نر م افزار ومعرفی rup

بخش ا ول : مقد مه ی بر مهندسی نرم افزار
بی گمان، نرم افزار یکی پیچیده ترین و در عین حال قابل انعطاف ترین دستاوردهای بشر می باشد. با وجودی که بیش از چند دهه از پیدایش نرم افزار نمی گذرد. این پدیده ی شگفت آور قرن بیستم،به عنوان یکی از مولفه های کلیدی فناوری های نوین اطلاعات و ارتباطات، تاثیر شگرفی بر کلیه ی جوانب زندگی بشر داشته است امروزه نرم افزار، سوخت لازم برای راه اندازی و به حرکت درآوردن موتورهای اقتصاد نوین تلقی می شود. هیچ سازمان و کسب وکار نوینی، نمی تواند بدون نرم افزار به حرکت و تکامل خود ادامه دهد.
در طول چند دهه ی اخیر، با کمک رایانه ها و نرم افزارهای مختلف، حجم دانش بشری چندین برابر شده است. در آینده ی بسیار نزدیک، هر یک از ما شاهد بکارگیری نرم افزار در منزل، خودرو، تلویزیون، ساعت مچی ، کتاب، و حتی لباس های خود خواهیم بود.
اما به واسطه ی تغییرات بسیار سریع و غافل گیرکننده ی فناوری های نوین اطلاعاتی و ارتباطی و به طور خاص نرم افزار، و به موازات آن، تغییر نیازها، خواسته ها، و انتظارات استفاده کنندگان از نرم افزار و قابلیت های آن، طراحی و تولید نرم افزار، بسیار پیچیده می باشد. عوامل دیگری مانند رقابت شدید، کمبود نیروی متخصص و حرفه ای، عدمِ دسترسی به دانش و تجربه ی موفق دیگران، لزوم تولید سریع، لزوم تولید مقرون به صرفه، نیاز روز افزون به همکاری میان رشته های مختلف، و مهم تر از همه ، عدم استفاده ی مناسب از اصول و مبانی مهندسی در طراحی تولید نرم افزار، این صنعت را با چالش های بسیاری روبرو نموده است. حدود 50 سال پیش،یعنی در اوایل پیدایش نرم افزار استفاده کنند گان این فراورده ی نوین همان طراحان و تولید کنندگان بودند.دران زمان نرم افزار عمدتا برای محاسبات و حل مسائل ریاضی استفاده می شد. وجود زبان های سطح پایین ٣ و محدودیت های سخت افزاری(کمبود حافظه و سرعت پردازش کم) از دیگر مشخصه های دوران اولیه ی پیدایش نرم افزار است در آن روزهای اولیه، نرم افزار چیزی جدا از سخت افزار نبود و حتی برای فروش سخت افزار، بطور رایگان در آن تعبیه می شد اما با گسترش دامنه ی کاربرد رایانه و به تب ِ ع آن نرم افزار در زمینه های مختلف، به مرور شرایطی به وجود آمد که استفاده کنندگان و کاربران نرم افز صرفاً تولید نرم افزار بود. حالا دیگر نرم افزار قیمت داشت و اتفاقا برخلاف روند کاهش قیمت در سخت افزارها از طراحان و تولید کنندگان آن جدا شدند؛ سازمان ها و شرکت هایی به وجود آمدند که کارشان روز به روز بر قیمت نرم افزار افزوده می شد. نیازهای جدید استفاده کنندگان فراتر از محاسبات(رایانش) بود آنها به مدیریت اطلاعات نیاز داشتند. پیدایش زبان های سطح بالا و رفع محدودیت های سخت افزاری، از دیگر مشخصه های عصر جدید نرم افزار می باشد. درست در همین زمان است که اولین شکست ها و مشکلات نیز خود را نشان دادند. مشکلات و چالش ها به قدری جدی و پر هزینه بود که از آن به بحران نرم افزار یاد می شد.
سرانجام برای اولین بار، در سال ۱۹۶۸ و در یک کنفرانس که توسط ناتودر کشور آلمان برگزار شده بود، بر لزوم مهندسی این دستاورد جدید بشر، یعنی نرم افزار، تاکید شد. از آن زمان به بعد، تکنیک های مهندسی، ابزارها، و دانش و تجربه، صنعت نرم افزار به یکی از صنایع برتر جهانی تبدیل شده است
در این جا، مهندسی نرم افزار را به شکل زیر تعریف می نماییم:
مهندسی نرم افزار، شاخه ای است از مهندسی، که با بهره گیری از دانشِ علمی، به ارائه ی راه حل هایی مقرون به صرفه ، در قالب دستاوردهای نرم افزاری و به منظور حل مسائل و مشکلات عملی و خدمت جامعه ی بشری، اقدام می نماید.
یک پروژه ی موفق نرم افزاری، پروژه ای است که در یک محدوده ی زمانی از قبل برنامه ریزی شده و با بودجه ای از قبل پیش بینی شده ، یک فراورده ی نرم افزاری دارای کیفیت مطلوب (یعنی کیفیتی مطابق با خواسته ها و نیازهای واقعی کاربران ( در آن تولید می گردد.
به زبان ساده، یک فراورده ی نرم افزاریعبارتست از یک برنامه ی نرم افزاری قابل اجرابه علاوه ی مجموعه ی مستندات و دست نامه های کاربران آن البته گاها مجموعه ی کد های برنامه نیز در قالب فراورده ی نهایی ارائه می گردد.دراین مورد در جای خودش بیشتر توضیح خواهم داد.
بخش دوم : تعریف مهندسی نرم افزار
با گسترش تکنیک های مهندسی، ابزارها، و دانش و تجربه، صنعت نرم افزار به یکی از صنایع برتر جهانی تبدیل شده است.
همانطور که در مقدمه ی مهندسی نرم افزار اشاره شد مهندسی نرم افزارشاخه ای است از مهندسی، که با بهره گیری از دانشِ علمی ، به ارائه ی راه حل هایی مقرون به صرفه ، در قالب دستاوردهای نرم افزاری و به منظور حل مسائل و مشکلات عملی و خدمت به جامعه ی بشری، اقدام می نماید.
مهندسی نرم افزار یک حرفه است نه یک شغل بلکه حرفه گسترده تر از شغل است و در آن فرد به یادگیری و گسترش دانسته های خود می پردازد. شغل از پیش تعریف شده و محدود است؛ بستن پیچ های یک دستگاه و نوشتن یک تکه از برنامه برای اتصال به بانک اطلاعاتی. حرفه بر گرداگرد فرد به وجود می آید. در حالی که، شغل متعلق به کارفرماست .
از دید کلّی، سه واژه ویژگی های کار حرفه ای را روشن و آشکار می کنند: مشتری ، فرایند، و نتیجه مهندسی نرم افزار نیز یک کار حرفه ای به شمار می آید. بنابراین، مهندس نرم افزار فردی است حرفه ای، که خود را در برابر مشتری مسئول می داند و همواره در پی دستیابی به ارزش مورد نیاز اوست. رسالت و ماموریت یک مهند س نرم افزار، حل مشکل مشتری است. بنابراین بایستی سراسر فرایند کار را اجرا نماید و به نتیجه ی دلخواه مشتری دست یابد.
فعالیت های مهندسی، عمدتا دو گونه اند: ۱- طراحی روتین که شامل ارائه ی راه حل برای مسائلی آشنا واستفاده ی مجدد از راه حل های قبلی می باشد و ۲- طراحی نوآورانه که عبارت است از ارائه ی راه حل هایی نو و بدیع برای مسائلی نا آشنا. مهندسی نرم افزار،اغلب با فعالیت های دسته ی دوم یعنی طراحی نوآورانه سر وکار دارد.
یک مهندس نرم افزار باید علاوه بر آشنایی با برنامه نویسی ، دارای دانش و تخصص هایی نظیر مهارت های فنی، مدیریت پروژه، مهارت های شناختی درک سازما نها در سطح گسترده ، توانایی کار تیمی یادگیری، و کسب دانش در زمینه ی حوزه ی فعالیت خود باشد. متاسفانه، دور ههای آموزشی مهندسی نرم افزار، کمتر به این مفاهیم پرداخته اند و بنابراین لازم است بازنگری عمیقی در ساختار و محتوای دوره های آموزشی مهندسی نرم افزار صورت پذیرد.
با توجه به ویژگی های خاص نرم افزار، مهندسی آن نیز تفاوت هایی با سایر زمینه ها و شاخه های مهندسی دارد. درک این تفاوت ها برای به دست آوردن نگرشی مناسب نسبت به مهندسی و تولید نرم افزار، ضروری است. برخی از این تفاوت ها، عبارتند از:
– مهندسی نرم افزار هنوز در حال بکارگیری (و آموزش) به روشی غیر اصولی می باشد
– نسبت به سایر تخصص های مهندسی، از سازماندهی کمتری برخوردار می باشد.
– نسبت به برخی از رشته های مهندسی، استانداردهای کمتری برای طراحی نرم افزار وجود دارد.
– ی جوانی در بسیاری از رشته ها و تخصص های مهندسی، در مقطعی از زمان، طراحی کامل شده و اصطلاحا تر از دیگر رشته های مهندسی است.
بسته می شود؛ بعد از آن، پیمانکار کمتر در طراحی مذکور، دخل و تصرف خواهد داشت. در صورتی که در مهندسی نرم افزار، بستن طراحی و کامل شدن آن، تا انتهای پروژه به طول می انجامد
– در مهندسی و تولید نرم افزار، فرآیندهای استاندارد، کمتر استفاده می شود
– معمولاً، دستاوردهایی مانند ساختمان ها و پل ها با هزینه ی پیش بینی شده و سر موعد مقرر ساخته می شوند؛ در حالی که نرم افزار به ندرت، سر موقع و با هزینه ی از قبل پیش بینی شده ایجاد می گردد.
– فراورده و دستاورد اصلی مهندسی نرم افزار(یعنی فراورده ی نرم افزاری)، دارای ماهیتی غیرقابل لمس می باشد
اثرات ناشی از شکست یک پروژه ی نرم افزاری برای همگان قابل لمس نیست. در مقابل اثرات ناشی
این تفاوت ها از یک طرف و پیچیده تر شدن سیستم ها، بزرگ تر شدن اندازه ی آنها، و افزایش روز افزون ز فرو ریختن یک پل یا خرابی یک اتوموبیل را همه می توانند درک نمایند
اهمیت نرم افزار از سوی دیگر، مهندسین نرم افزار را با چالش ها و معضلات زیادی روبرو نموده است. در واقع، علیرغم اهمیت و نقش کلیدی نرم افزار در اقتصاد نوین و جایگاه منحصر به فرد آن در سایر دستاوردها و مصنوعات بشری)اعم از سخت افزار، کسب و کار، و یا سازمان ( و نیز تاثیر آن بر سایر صنایع، هر روز خبرهایی از عدم موفقیت در طیف وسیعی از پروژه های نرم افزاری )پروژه هایی که محصول آنها یک سیستم نرم افزاری می باشد( به گوش می رسد.
یک پروژه ی موفق نرم افزاری، پروژه ای است که در یک محدوده ی زمانی از قبل برنامه ریزی شده و با بودجه ای از قبل پیش بینی شده ، یک فراورده ی نرم افزاری دارای کیفیت مطلوب (
باید توجه داشت که یک فراورده ی نرم افزاری باید به اصطلاح، قابلیت خودپشتیبانی داشته باشد؛ بر اساس این قابلیت، همه ی کاربران یک سیستم نرم افزاری،اعم از کاربران ساده، مدیران سیستم ، و یا مسئولین نگهداری و به روز رسانی آن، باید قادر باشند بدون نیاز به حضور تولیدکنندگان و پدیدآورندگان آن، تمام انتظاراتشان را از سیستم برآورده نمایند.
بخش سوم : فرایند تولید نرم افزار
نرم افزار چیست؟
تعریف نرم افزار:برنامه +مستندات +راهنمایی کاربر
نرم افزار شامل برنامه های کامپیوتری همراه است با مستندات و داده های پیکربندی است که برای درست ‏کارکردن برنامه ضروری است.
مشخصه های یک نرم افزار خوب عبارتند از: 1-نیازهای مشتری رامی بایستی برآورده سازد 2-با عملکرد صحیح نیازهای مشتری را براورده سازد.3- بدون هدر دادن منابع سیستم این کار انجام دهد.4- برای کاربر به سهولت قابل انجام باشد.5-اعمال تغییرات به آسانی انجام گیرد.
عوامل موفقعیت در تولید یک نرم افزار خوب عبارتند از :زمان ،کیفیت و هزینه که برای مفهوم کیفیت یک نرم افزار تعاریف زیر را ارئه می نماییم.
کیفیت مفهوم بسیار پیچیده ای است. مسلم است که همه کیفیت را می پسندند. اما شاید کمتر کسی بتواند تعریف کاملی از آن ارائه نماید. دو تعریف کلی مفهوم کیفیت، عبارتند از: تطابق با نیازمندی ها و متناسب بودن برای استفاده. این دو تعریف که تا حد زیادی به هم مرتبط می باشند، تفاوت کوچکی نیز دارند؛ متناسب بودن برای استفاده، تاکید بیشتری بر نقشِ نیازمندی ها و انتظارات مشتری و کاربر دارد. شاید از خود بپرسید که حد و اندازه های کیفیت چه میزان است و یا چگونه می توان کیفیت را سنجید؟ در دیدگاه مورد پذیریش امروزی از این مفهوم، کیفیت مطلوب و کافی است و نه بهترین کیفیت. داشتن معیارهای برای سنجش کیفیت، شرط اطمینان از موفقیت یک پروژه می باشد.
شکل 3-1
مثلث موفقیت پروژه

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

شکل 3-2
فرایند تولیدمحصول نرم افزاری

باید توجه داشته باشید که امروزه، تولید نرم افزار کاری است تیمی و در تولید یک فراورده ی نرم افزاری موفق، صرف نظر از اندازه و ابعاد آن، تنها یک تیم شرکت می نماید؛ این تیم بدون داشتن یک فرهنگ کاری مشترک، که همان فرایند تولید می باشد، هرگز نمی تواند موفق باشد. در واقع این طور به نظر می آید که با جمع شدن چند نفر برنامه نویس، مدیر پروژه، تحلیل گر، و طراح در کنار هم و تشکیل یک گروه، می توان یک پروژه ی نرم افزاری را انجام داد و یا ممکن است شما پیش از این، خود به تنهایی یک پروژه را به طور موفق انجام داده باشید و برایتان اهمیت و جایگاه فرایند چندان آشکار نباشد کافی است از خود بپرسید که چند درصد احتمال دارد دوباره یک پروژه ی موفقِ دیگر انجام دهید؟ یا اینکه آیا پروژه ای وجود دارد که بتوان به تنهایی انجام داد؟ آن گروه نرم افزاری، چقدر در کارشان دوباره کاری داشته اند؟ آیا نرم افزار به موقع تحویل شد؟ کیفیت آن چگونه بود؟ آیا هزینه ها را درست پیش بینی کرده بودند؟ آیا فراورده ی ارائه شده مورد قبول همه ی مشتریان و کاربران بود؟ آیا در نگهداری نرم افزار مشکلی ندارید؟ اینها و بسیاری سوالات دیگر، باید شما را به تامل واداشته باشد .
هر پروژه ای چه موفق و چه ناموفق، دارای فرایند خاص خود می باشد. اما هر فرایندی، دارای فرایند خاص خود می باشد. اما هر فرایندی، قالب مناسبی برای موفق شدن فراهم نمی کند. زیرا مسلم است کیفیت نرم افزاربر کیفیت فراورده ی خروجی آن تاثیرگذار می باشد. یک فرایند مطلوب و با کیفیت، فرایندی است که به کمک آن، یک پروژه ی تولید نرم افزار، قابل پیش بینی و تجارب موفقِ کسب شده در طی آن، قابلِ تکرار مجدد باشد. بنابراین، فرایند باید به خوبی سازمان دهی و مستندسازی شده باشد. شکل 3-3 نشان دهنده ی ارتباط میان فرایند، پروژه، افراد تولیدکنندگان و استفاده کنندگان، فراورده و ابزارها نشان داده شده است. توجه داشته باشید که در این مدل، منظور از ابزارها، مجموعه ی ابزارهای به اصطلاح کمک به مهندسی نر م افزار یا کی س تولزمی باشد. به عنوان نمونه، می توان ابزارهایی مانند ابزارهای مدل سازی نظیر رشنال رز، محیط های مجتمع تولید نظیر محیط دات نت (.net)، ای.کلیپس)، ابزارهای تست (مانند رشنال تست سویت، ابزارهای مستند سازی نظیر رشنال سودا ) و ابزارهای مدیریت پروژه (نظیر ام. اس.پی را نام برد.
شکل3-3
مدل ارتباط میان مفاهیم پروژه، فرایند، فراورده (محصول)، ابزار، و افراد

در این مقاله، سعی نموده ایم که یکی از موفق ترین فرایندهای تولید نرم افزار، یعنی آر.یو.پی، را معرفی نماییم. خواهید دید که بسیاری از مفاهیم و اصول آر.یو.پی، بسیار منطقی و در تطابق با تعریف ها و نیازهای امروزی تولید نرم افزار می باشد. در واقع، آر.یو.پی نه یک فرایند، بلکه چارچوبی است برای تعریف فرایندهای طیف وسیعی از پروژه ها در اندازه ها، پیچیدگی ها، و ملاحظات مختلف. اکنون فرصت مناسبی است تا نگاهی به برخی از آمارهای مرتبط با موفقیت و شکست در پروژه های نرم افزاری، داشته باشیم. در شکل های 3-4و 3-5و3-6 برخی از این آمارها نشان داده شده است .

شکل 3-4
آمار مربوط به وضعیت پروژه های نرم افزاری در سال 1979 میلادی

شکل3-5
آمارهای مربوط به وضعیت پروژه های نرم افزاری در سال ۱۹۹۵ میلادی

شکل 3-6
آمارهای مربوط به وضعیت پروژه های نرم افزاری در سال 2000 میلادی

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

شکل 4-1
سازماندهی فرایند آر.یو.پی در دوبعد زمانی و محتوایی (دینامیک و استاتیک)

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

برای مثال، نقصِ یک طراحی ممکن است از نقصِ یک نیازمندی متناظر با آن ناشی شده باشد. این مشکل تنها در زمان پیاده سازی و تست آشکار می شود، یعنی زمانی که ممکن است تصحیح آن باعث افزایش هزینه ها و طولانی تر شدن پروژه و یا حتی بسته شدن و شکست کامل آن شود.
رویکرد2:مدل تکرار مبنی بر حلزونی
در طول سال های گذشته، بسیاری از افراد در دانشگاه ها و نیز شرکت های پیشروی صنعت نرم افزار،تلاش زیادی برای ارائه و معرفی رویکردهای دیگری که جایگزین رویکرد منسوخ آبشاری باشد، انجام داده اند. حاصل این تلاش ها، ارائه ی ده ها رویکرد و فرایند دیگر بوده است. از جمله: روش حلزونی ، تولید پیش الگو DSDM ، SCRUM ، RAD ،یکی از راهکارها و تجارب موفق، رویکردی است تحت عنوان تکرارشونده. این روش که عمدتاً براسا س مدلِ حلزونی ایجاد شده است، توانایی قابل توجهی در مدیریت ریسک دارد اسا س مدلِ حلزونی ایجاد شده است، توانایی قابل توجهی در مدیریت ریسک دارد. شکل 5- 2الگوی یک تکرار را که پایه و مبنای رویکرد تکرار شونده می باشد، نشان می دهد. شکل 5-3بیانگر شمایی کلی از فرایند مبتنی بر رویکرد حلزونی می باشد.

شکل4-3

یک تکرار، توالی مجموعه ی فعالیت های فرایند در یک بازه ی زمانی کوتاه

شکل 4-4

روشِ حلزونی، مبنای رویکرد تکرارشونده

در واقع، یک تکرار عبارتست از انجام متوالی مجموعه فعالیت های لازم در یک بازه ی زمانی کوتاه وانجام چندین باره ی آن در طول بازه ی زمانی یک پروژه. بنابراین، به جای انجام یک بار و به صورت متوالی فعالیت ها، چندین بار و در بازه های کوچکتری این مجموعه فعالیت ها را تکرار می نماییم.

درشکل 4-5 مقایسه ی میان ریسک ها در رویکردهای آبشاری و تکرارشونده

رویکرد تکرارشونده یکی از مهم ترین راهکارهای موفق در صنعت نرم افزار می باشد. اصول و مبنای اصلی فرآیندهای به اصطلاح چابک نیز بر مبنای همین رویکرد بنا شده است.
تولید نرم افزار با کمک رویکرد تکرارشونده، نقش موثری در از میان برداشتن برخی از دلایل وو عواملِ ریشه ای مشکلات در پروژه های نرم افزاری دارد. از جمله ی این تاثیرات، می توان موارد زیر را بیان نمود:
– امکان دریافت بازخوردهای مستمر از کاربران و به تبعِ آن بهبود مدیریت نیازمندی های و اطمینان از جلب مشارکت مشتری و کاربر در فرایند تولید
– امکان شناسایی زودهنگام مشکلات و نواقص کلیدی در همان تکرارهای ابتدای پروژه فراهم شده و می توان با هزینه ی کمتری نسبت به رفع آنها اقدام نمود.
رویکرد 6:مدل حلزونی
هدف از مدل حلزونی کاهش ریسک در فرایند تولید نرم افزار می باشد. ریسکها مجموعه ی از عواملی هستند که بعضا ممکن است ،به عنوان مسائل جانبی مطرح می باشد. دراین مدل سیتم از یک
نقطه شروع به بزرگ شدن می کند.وچنانچه برنامه ریزی در فرایند تولید نرم افزار ،درست انجام نشده نشده باشد.بزرگ شدن سیستم ممکن است غیر قابل کنترل باشد.
مزایایی این مدل :
1-توجه خاص به ریسک ها دارد 2-توجه خاص به توسعه جزئیات دارد.معایب: 1-استفاده از این مدل احتیاج به تجربه بالای دارد. 2-استفاده از این مدل نیاز به هزینه ی بالای دارد.

شکل 4-6
مدل حلزونی

رویکرد 7:مدل ساخت وترمیم:
مدل ساخت و ترمیم فرایند تولید نرم افزار را به این صورت مدل می کند که هدف تنها ساختن مجدد سازه بوده تا ان هنگام که نیاز مورد نظر برطرف شود .این روش فاقد فاز شناخت وطراحی است از این رو برای هر نوع سیستم نرم افزاری مناسب نیست.
رویکرد8:مدل افزایشی
در این مدل عمر یا رویکرذد تولید نرم افزار مراحل مهم فرایند تولید نر افزار مانند طراحی و پیاده سازی ممکن است چندین مرحله تکرار شود .ودر بدترین حالت شروع مجدد ممکن است دیده شود.
مزایا :1-تغییرات می تواند به مرحله ی ساخت بعدی کنترل شود.2-نرم افزار ریسک کمتری می پذیرد.3-نیازهای می توانند براساس اولویت و اهمیت طبقه بندی شود.
معایب : 1-اندازه ی مرحله وتعیین آن نیاز به تجربه دارد. 2-حرکت از یک مرحله به مرحله بعدی مبهم استیا به عبارتی رابطه ی بین مراحل مبهم است.
بخش 5: راهکارهای موفق مهندسی نرم افزار در تولید نرم افزار ومعرفی rup
راهکار موفق1: ارزیابی مستمرِ کیفیت نرم افزار
هزینه ی بهبود و تصحیح مشکلات و نواقص یک سیستم نرم افزاری در طول زمان و با پیشرفت پروژه به صورت نمایی زیاد می شود. به گونه ای که هزینه ی رفع یک خطا بعد از اینکه سیستم در محیط مشتری و کاربران نصب و راه اندازی گردید، در حدود صد تا هزار برابر بیشتر از هزینه ی رفع همین مشکل در اوایل فرایند تولید می باشد. بنابراین، لازم است که به صورت مستمر، کیفیت سیستم را از جنبه های مختلفی مانند کارکردها ، قابلیت اعتماد ، کارایی نرم افزار، و کارایی سیستم، ارزیابی نماییم. تجربه ی پروژه های موفق، حاکی است که داشتن یک رویکرد مناسب برای بررسی و مدیریت کیفیت فراورده در طولِ چرخه ی تولید آن، تاثیر بسیار زیادی بر موفقیت پروژه دارد. ارزیابی مستمر کیفیت، راهکارهایی را برای رفع برخی از مشکلات و دلایلِ ریشه ای مرتبط با آن ها در پروژه های نرم افزاری فراهم می نماید، از جمله: – امکان ارزیابی مقصودگرا و کمی وضعیت پروژه فراهم م یگردد و بنابراین از اظهارنظرهای شخصی فاصله خواهیم گرفت. در واقع نتایج انجام تست های مکرر، معیارها و اعداد و ارقامِ مناسبی از پیشرفت یا عدم پیشرفت پروژه فراهم می نمایند – ناسازگاری میان نیازمندی ها، طراحی ها، و پیاده سازی ها آشکار می گردد. و….
راهکار موفق 2 – بهره گیری از معماری های مبتنی بر مولفهRUP) ):
توصیف ساخت و مستندسازی یک سیستمِ نرم افزاری، مستلزمِ داشتنِ منظرهای مختلفی از سیستم و از جنبه های مختلف می باشد. هر یک از ذینفعان، اعم از کاربر ، مشتری ، تحلیل گر، و مدیر پروژه، نگاه خاصی به پروژه دارند. معماری نرم افزار، مهم ترین چیزی است که به منظور مدیریت دیدگاها و انتظارات مختلف ذینفعان استفاده می شود و به کمک آن، توسعه ی مبتنی بر رویکرد تکرارشونده و تکاملِ تدریجی سیستم در طول چرخه ی تولید، کنترل می شود. معماری نرم افزار، موجودیتی است بیانگر تصمیم گیری های کلیدی درباره ی ملاحظات مختلف سیستم، از جمله:
– چگونگی سازماندهی اجزای سیستم
– انتخاب اجزای ساختاری و واسط میان این اجزاء
– رفتار سیستم در قالب همکاری میان اجزاء و عناصر ساختاری
– شیوه ی معماری که راهنما چگونگی سازماندهی می باشد
استفاده از معماری های مبتنی بر مولفه، راهکارهایی برای از بین بردن برخیاز دلایل و عواملِ ریشه ای مشکلات تولید نر م افزار، فراهم می نماید. از جمله: – یک معماری مبتنی بر مولفه، قابلیت
انعطاف بیشتری دارد. – معماری مبتنی بر مولفه با تفکیک ملاحظات و نگرانی های مختلف در میان عناصر و مولف های مختلف سیستم، مدیریت تغییرات را تسهیل می نمایند.
– امکان استفاده ی مجدد و بهره گیری از چارچوب های استانداردی مانند COM: ، CORBA مولفه های آماده فراهم می شود. ، EJB
– مولفه ها، مبنایی برای مدیریت پیکربندی فراهم می نمایند
– ابزارهای مدل سازی بصری به خودکارسازی تولید مبتنی بر مولفه ی سیستم، کمک می کنند
راهکار موفق3- مدل سازی بصری(UML)
بررسی پروژه های موفق نشان می دهد که یکی از مهم ترین دلایل و عواملِ موفقیت پروژه، مدل سازی بصری (تصویری) می باشد. ارائه مدل های بصری از جنبه های مختلف سیستم، می تواند ما را در درک بهتر سیستم، غلبه بر پیچیدگی، و برقراری ارتباطات موثر، یاری داده و موجبات رفع بسیاری از دلایل و ریشه های بروز شکست و عدم موفقیت پروژه را فراهم نماید.

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

فهرست منابع مورد استفاده در این فصل

1- نام منبع : rup چیست و مراحل ان ، برگرفته از سایت : p30world.com www. و منبع اصلی این سایت میکرو رایانه می باشد.
2-معرفی rup (چارچوپ فرایند تولید سیستم های نرم افزاری )،نویسنده : محمد بدری ، برگرفته از سایت: www.safware-acadmay (آکادمی نرم افزار)
آدرس: تهران، خ آزادی، بلوار شهید اکبری، خ شهید قاسمی، کوی تیموری، پلاک 3

فصل دوم:

آر.یو.پی چیست؟

(RATIONAL UNIFED POROCSESS)

درخت تحقیق فصل دوم :

بخش1: مقدمه ی بر معماری نرم افزار
بخش 2:معماری rup چیست ؟
بخش 3:اهداف و ویژگی های rup

مقدمه معماری نرم افزار:
معماری، که در یک نگاه کلی نحوه ی گردآوری و اثر متقابل اجزا را بیان می کند، اساسی ترین مساله در طراحی و ساخت هر سیستم بزرگ نرم افزاری به شمار می رود. یک معماری خوب می تواند این اطمینان را به وجود آورد که سیستم به درستی پاسخ گوی نیازهایی از قبیل کارآیی، قابلیت اطمینان، قابلیت جابه جایی، مقیاس پذیری و تعامل متقابل است و در عوض یک معماری بد می تواند سردرگمی و گرفتاری به وجود آورد.
در چند دهه ی گذشته با توجه زیادی به اهمیت معماری نرم افزار، تولیدکنندگان حرفه ای نرم افزار به خوبی دریافته اند که دست یابی به یک معماری درست، بزرگ ترین عامل موفقیت در طراحی و توسعه ی سیستم است. از این رو در توسعه ی محصولات جدید، همواره سعی کرده اند ارزش گزینه های جدید معماری را با بررسی نحوه ی ارتقای طرح های معماری گذشته، تشخیص دهند. امروزه کتاب های بسیاری در زمینه ی "طراحی بر اساس معماری" نوشته شده است. گردهمایی ها و کارگاه های متعددی در این راستا برگزار شده است. ابزارهای تجاری بسیاری به منظور پاسخ گویی به این نیاز تولید شده و پروژه های دولتی و صنعتی عظیمی با تمرکز بر روی معماری نرم افزار تعریف شده است تا از میان آن ها تعدادی استانداردهای معماری به صورت رسمی انتشار یابد. تدوین اصول، شیوه ها و تجربیات در این زمینه به هدایت شیوه هایی تکرارپذیر از طراحی، با نیم نگاهی بر استانداردهای مستندسازی، بازنگری و پیاده سازی آن ها منجر می شود.
با وجود پیش رفت های صورت گرفته، از دید نظام مهندسی، شاخه ی معماری نرم افزار هنوز نابالغ به شمار می آید. در حالی که با روشن شدن هر چه بیش تر محدوده ی این شاخه، بر تعداد مشکلات و عوامل بررسی نشده اضافه می شود. از این رو در آینده ای نزدیک با پیش رفتی قابل توجه، هم در دانش و هم در عمل، در این زمینه روبه رو خواهیم بود. بخشی از این توسعه ها در حقیقت گسترش طبیعی مسیرهای کنونی است و تعداد زیادی از این فرصت های جدید نیز هم گام با تغییرات فناوری ارایه می شوند.
معماری نرم افزار مانند پلی ارتباطی میان نیازمندی ها و پیاده سازی، نقشی کلیدی بازی می کند و در حالی که بسیاری از ویژگی ها را نشان می دهد، با ارایه یک توصیف انتزاعی از سیستم، تعدادی از ویژگی ها را از نظر دور می دارد. در مطلوب ترین حالت، این نمایش دستورالعملی قابل اجرا را در اختیار کل سیستم قرار می دهد تا به طراحان امکان دهد، درباره ی توانایی سیستم در پاسخ گویی به نیازمندی های مشخص و ارایه ی نمونه ی اولیه برای ساخت و ترکیب سیستم تفکر کنند. برای مثال، معماری یک نرم افزار کاربردی پردازش سیگنال ممکن است از یک شبکه ی گردش داده تشکیل شده باشد که در آن گره ها اطلاعات ورودی را دریافت، تبدیل و به خروجی ارسال می کنند. از این رو طراحان باید با تجزیه ی چنین ساختاری و با در اختیار داشتن مقادیر برآورد شده ی ورودی گردش اطلاعات، هزینه های محاسباتی و ظرفیت های ذخیره سازی، درباره ی مسایل محتمل از جمله گلوگاه ها، نیازمندی های منابع و ترتیب عملیات محاسباتی چاره اندیشی کنند.
سه امتیاز طراحی و مستند سازی معماری نرم افزار :‏1-ارتباط با واگذارندگان
۲- تحلیل سیستم
3- استفاده مجدد در مقیاس بالا
معماری نرم افزار می تواند دست کم در شش زمینه از توسعه ی نرم افزار که در زیر آورده شده است .
نقش کلیدی ایفا کند: 1- ادراک 2- استفاده ی مجدد 3- ساخت 4- تکامل 5- تحلیل 6- مدیریت
بخش 2: rup چیست؟
موضوعات مورد مطالعه
1- تعاریف و مفاهیم کلیدی آر.یو.پی
2- ساختار آر.یو.پی
3- ساختار پویا(دینامیک)
4-ساختار ایستا(استاتیک یا محتوایی)

در این پروژه مروری اجمالی و در عین حال جامع بر ساختار و مفاهیم کلیدی آر . یو . پی خواهیم داشت.
تاریخچه ی مختصری از آر.یو.پی:
آر.یو.پی نتیجه ی گردآوری تجارب موفق شرکت ها و تیم های زیادی در طول چندین دهه می باشد. برخی از ریشه های اصلی آر.یو.پی به مدل حلزونی ارائه شده توسط آقای بِری بوهم ، برمی گردد. این مدل، با داشتن رویکردی تکرارشونده و مشتق از ریسک، کارشناسان برجسته ی شرکت رشنال، یعنی افرادی نظیر فیلیپ کراچِن(Philippe Kruchten) ، گْردی بووچ(Grady Booch) ، مایک دولین(Mike Devlin) ، ریچ ریت من ( Rich Reitman) و وکر ریس( Walker Royce) ، را تحت تاثیر قرار داد.
ریس و بوهم در زمینه ی تحقیقات و نیز یکسری پروژه، همکاری های مشترکی داشتند. یکی از کارهای موفق و شناخته شده ی آقای بوهم، مفهوم نقاط لنگرگاه می باشد که ایشان در سال ۱۹۹۶ در مقاله ای آن را معرفی نمودند. همین مفهوم، امروزه در آر.یو.پی تحت عنوان نقاط تصمیم گیری سازمانی یا نقاط کلیدی اصلی مطرح می باشد.
تیمِ مستقر در شرکت رشنال، آر.یو.پی را در مشارکت با مشتریان و با شروع از فرایندی تحت عنوان رویکرد رشنال که در طی سال های دهه ی هشتاد و ابتدای دهه ی نود میلادی در این شرکت تهیه شده بود، ایجاد نمود. این تیم از فرایندی تحت عنوان آبجِکثری که متعلق به آقای ایوار جکوب سن va) (Jacobson می باشد نیز درایجاد و تکمیل آر.یو.پی، استفاده نمود. ایشان نیز بعدها (در سال ۱۹۹۵ ) به شرکت رشنال پیوست. بخش اصلی پروژه ی ایجاد آر.یو.پی در سال های ۱۹۹۵ تا ۱۹۹۸ میلادی انجام شد. معمار ارشد آر.یو.پی، آقای فیلیپ کراچِن(Philippe Kruchten) بود. ایشان شخصی بسیار فعال و با تجربه در معماری و راهبری فرایند در سیستم های بزرگی مانند سیستم جدید کنترل ترافیک در کانادا و نیز یکی از متفکرین برجسته در زمینه ی معماری می باشد. با وجودیکه از همان ابتدای کار ایده ی ایجاد آر.یو.پی به عنوان یک محصول و راهکار تجاری مطرح بود، اما شرکت رشنال به ترویج این فرایند به صورتی آزاد و قابل دسترس برای عموم نیز مبادرت نمود. در این راستا، مفهوم فرایند یکپارچه مطرح گردید. در کنار این مفهوم، زبان مدل سازی استانداردی نیز تحت عنوان زبان یکپارچه ی مدل سازی با هدف متحدالشکل کردن رو شها و تکنیک های نمادگذاری و مدل سازی ایجاد گردید. آقای جکوب سن ، ایده ی یک فرایند آزاد و باز را با نوشتن کتابی تحت عنوان فرایند تولید(توسعه ی) یکپارچه ی نرم افزار در سال ۱۹۹۹ میلادی و با کار روی نسخه ی پیش نویسی از محصول آر.یو.پی، تحقق بخشید. از آن موقع، کتاب های زیادی درباره ی فرایند یکپارچه و با هدف ترویج راهکارهای موفق، مفاهیم جدید فازها، دیسیپلین ها، و موارد مشابه آن، به رشته ی تحریر درآمد. شرکت رشنال در سال ۱۹۹۵ ، شرکت آبجکتوری(Objectory) را که متعلق به آقای جکوب سن بود، در خود ادغام نمود. با ادغام این شرکت، فرایندی تحت عنوان فرایند رشنال آبجکتوری (Ivar Jacobson) ایجاد گردید. در نسخه ی چهارم ازنمود. با ادغام این شرکت، فرایندی تحت عنوان فرایند رشنال آبجکتوری ایجاد گردید. در نسخه چهارم ازاین فرایند جدید، بحث های مدیریت نیازمندی ها براساس دستاوردها و تجارب موفقِ شرکت به نام رکووی زیتRequisite Inc) )به آن اضافه شد. مباحث مربوط به تست نیز از شرکت اس.کیو. ای که در شرکت رشنال ادغام گردید، به فرایند رشنال آبجکتوری افزوده شد آر.یو.پی نتیجه ی مستقیم نسخه ی چهارم از فرایند رشنال آبجکتوری می باشد. درسال ۱۹۹۷ میلادی، شرکت رشنال، شرکت پیور آت ریا را که در زمینه ی مباحث مرتبط با پیکربندی پیشرو بود، در خود ادغام نمود و این مباحث را نیز به فرایند آر.یو.پی اضافه نمود. سرانجام در فوریه ی سال ۲۰۰۳ میلادی، یک ادغام دیگر هم انجام شد. ولی این بار نوبت خود شرکت رشنال بود که در یکی از تحول های بزرگ صنعت نرم افزار جهان، یعنی در شرکت آی.بی. ام ادغام گردد. دراین زمان، شرکت رشنال، شرکتی با حدود بیست سال قدمت و ارزشی معادل چند میلیارد دلار بود. امروزه شرکت رشنال به عنوان قلب مهندسی نرم افزار در شرکت آی.بی. ام فعالیت خود را ادامه می دهد آر.یو.پی، یک محصول از شرکت رشنال(و اکنون آی.بی. ام) می باشد. این محصول تقریبا دو بار در طول سال (یعنی هر شش ماه یک بار) به روز رسانی می شود برخلاف یو. ام. ال، آر.یو.پی یک استاندارد نمی باشد. اما اگر روزی صنعت نرم افزار به ضرورت وجود فرایند یا الگوی فرایندهایی استاندارد برخورد نماید، بی گمان فرایند یا چارچوب فرایندی شبیه آر.یو.پی (با داشتن ویژگی های منحصر به فردی مانند مدل سازی شده، کاملاً مستند شده، قالب تحت وب، قابل گسترش و به روز رسانی، و قابلیت پیکربندی( کاندید اصلی خواهد بود. امید است بتوانیم به یاری ایزد منان و همکاری نزدیک کارشناسان و متخصصان دلسوز،رویکردی مشابه را در کشور پایه ریزی نماییم.
شکل 2-1
تاریخچه ی تکامل آر.یو.پی

فرایند یکپارچه ی رشنال(یا به اختصار، آر.یو.پی( چیست؟
اجازه دهید پیش از تعریف آر.یو.پی و آشنایی با معنای دقیق آن، به معنای لغوی آن اشاره ای داشته باشیم حر ف اولِ این واژه )یعنی حر ف آر( مخفف کلمه ی رشنال می باشد. رشنال نام یکی از شرکت های بزرگ در صنعت نرم افزار است. این شرکت نقش مهمی در توسعه ی صنعت نرم افزار ایفا نموده است. این شرکت در سال ۲۰۰۳ رسما توسط شرکت آی.بی. ام خریداری شد. بنابراین در حال حاضر، مالکیت آر.یو.پی (به عنوان یک محصول در اختیار شرکت آی.بی. ام می باشد. حرف دوم در واژه ی آر.یو.پی )یعنی حرف یو( مخفف کلمه ی یونی فاید و به معنای تلفیق شده، یکی شده، و متحدالشکل می باشد با وجودیکه در این جا ازواژه ی یکپارچه استفاده میکنیم اما توجه داشته باشید که اصطلاح یکپارچه در اینجا به معنای یکی شده بکار می رود و در واقع، یکپارچگی معادل واژه ی Integrated مورد نظر نیست.
حرف سوم واژه آر.یو.پی )یعنی حرف پی( مخفف واژه ی پروسس به معنای فرایند می باشد. البته ممکن است مفهوم فرایند، موضوعات مختلفی را در ذهن شما تداعی نماید. توجه داشته باشید که در این کتاب، مفهوم فرایند، به طور خلاصه به جای عبارت فرایند تولید، استفاده می شودد مجموعه ای از فعالیت های مشخص و دارای ترتیبی معین که به منظور تولید یک محصول با توجه به یک نیاز و درخواست مشخص، تعریف نماییم. فرایند تولید،را تعریف می نماید.
حال می توانیم تعریف دقیق تری از آر.یو.پی داشته باشیم. آر.یو.پی، سه مفهوم و معنای تا حدی متفاوت را در بر می گیرد:
۱- آر.یو.پی یک رویکرد و روش برای تولید نر م افزار می باشد. این رویکرد، دارای ویژگی های
برجسته ای مانند تکرارشونده بودن، تمرکز بر معماری و مبتنی بودن بر موارد کاربرد(یا به عبارت ساده تر، مبتنی بر خواسته های مشتری) می باشد.
2-آر.یو.پی یک فرایند به خوبی تعریف شده و سازماندهی شده ی مهندسی نرم افزار می باشد. نقش
فعالیت ها، دستاوردها، و جریان های کارترتیب و توالی فعالیت ها) تعریف شده در آر.یو.پی، عناصر اصلی یک فرایند (یعنی چه کسی ، چه کاری ، چگونه ، و چه موقع را تعریف و تبیین می نماید. آر.یو.پی ساختار مناسبی برای کنار هم گذاشتن این مولفه ها فراهم نموده است. نحوه ی سازماندهی این ساختار به دو بعد دینامیک و استاتیک، یکی از ویژگی های کم نظیر آر.یو.پی می باشد
آر.یو.پی محصولی است دربرگیرنده ی چارچوب و قالب کلی فرایند های تولید سیستم های نرم افزاری. از این منظر، آر.یو.پی یک فرایند نیست که بتوان آن را مستقیما به عنوان قالب تعریف یک پروژه ی تولید نرم افزار بکار گرفت، بلکه مفهوم است بسیار فراتر و جامع تر. در واقع آر.یو.پی،مانند یک میز پر از غذاهای متنوع در یک رستوران می یباشد؛ مسلماً، هیچ یک از مهمان های این رستوران قادر نخواهد بود همه ی غذاها را میل نماید. در عوض، هر کس با توجه به ذائقه و نیازش (و البته موجودی داخل جیبش) گلچینی از غذاها را انتخاب و میل م ینماید. آر.یو.پی مخزن یا بانک دانشِ بزرگی از راهکارها و تجارب موفق برای شرایط و طیف گسترده ای از پروژه های مختلف،فراهم نموده است. هیچ پروژه ای در جهان نمی تواند منطقاً (و البته مادامی که بتوان آن را پروژه نامید) از همه ی این راهکارهای موفق، فعالیت های تعریف شده، راهنمایی ها و دستاوردهای مختلف،آنگونه که در آر.یو.پی تعریف شده، استفاده نماید. هر پروژه ای با توجه به ذائقه، نیازها، محدودی تها و امکانات خاصش، به گونه ی متفاوتی از این بانک دانش استفاده می نماید. آر.یو.پی به عنوان چارچوب فرایند، دارای قابلیت سفارشی سازی و پیکربندی برای طیف وسیعی از پروژه ها می باشد. به کمک آر.یو.پی، می توان فرایندی مناسب برای تولید یک محصول نرم افزاری بسیار کوچک پروژه ای در ابعاد یک نفر و دو هفته زمان) یا یک پروژه ی نرم افزاری بزرگ (مثلاً پروژه ای چند ملیتی در طول ۵ سال و با بیش از ۱۰ هزار نفر نیروی انسانی را تعریف و باموفقیت اجرا نمود .این ویژگی که آن را مقیاس پذیری می نامند. یکی دیگر از ویژگی های آر.یو .پی می باشد.
آر.یو.پی به عنوان یک رویکرد مهندسی نرم افزا:
از این منظر، آر.یو.پی همانند یک بانک دانش و گنجینه ای از تجارب، الگوها، و راهکارهای موفق در صنعت نرم افزار می باشد. ویژگی های کلیدی آر.یو.پی که آن را از سایر رویکردهای مهندسی نرم افزار متمایز می نماید، عبارتند از:
– توسعه و تولید با رویکرد تکرارشونده در مقابلِ رویکرد توسعه به روش آبشاری و یا سایررویکردهای دیگرمانند حلزونی توسعه ی سریع سیستمِ کاربردی ، پیش الگوسازی و …
– تمرکز بر معماری محوریت معماری در فرایند
– توسعه مبتنی بر موارد کاربرد مشتری مداری
آر.یو.پی به عنوان یک فرایند به خوبی تعریف شده ی تولید نرم افزار:
آر.یو.پی خود به عنوان یک فرایند تولید و مهندسی نرم افزار، با استفاده از تکنیک های طراحی و مدل سازی نرم افزار، طراحی شده است. تعریف کامل این فرایند به وسیله ی َابر مدلی تحت عنوان مدلِ مهندسی فرایند نرم افزار که استانداردی برای مدل سازی فرایند مبتنی بر زبان مدل سازی استاندارد یو. ام. ال می باشد، صورت پذیرفته است این مدل مرجع، در شکل 2- 2نشان داده شده است.
شکل 2-2
معماری آر.یو.پی: (سازماندهی فرایند آر.یو.پی در دو بعد زمانی و محتوایی(دینامیک و استاتیک)
مدل مهندسی فرایند نرم افزار :ارائه شده توسط OMG

شکل 2-3
سازماندهی فرایند آر.یو.پی در دوبعد زمانی و محتوایی (دینامیک و استاتیک)

ساختاری متعامد آر.یو.پی، عبارتند از:
– ساختار دینامیک(پویا 🙁 ساختار دینامیک آر.یو.پی، بعد افقی نشان داده شده در شکل2-3و بیانگر
ساختار پویا و ملاحظات مرتبط با زمان در فرایند می باشد. در این بعد، ملاحظاتی مانند چرخه های
توسعه (یا چرخه های تولید)، فازها ، تکرارها ، و نقا ط تصمیم گیری کلیدی مطرح می باشد. این مفاهیم در کنار هم، چرخه ی عمر یک پروژه ی نرم افزاری (پروژه ی تولید یک محصول نرم افزاری را تعریف می نمایند.
– ساختار محتوایی(استاتیک: (همانگونه که در شکل 2-3 نشان داده شده است، ساختار آر.یو.پی دارای یک بعد عمودی نیز می باشد که بیانگر ساختار استاتیک یا محتوایی آن است. در این بعد، توصیفی از چگونگی دسته بندی و سازماندهی عناصر محتوایی فرایند یعنی مجموعه ی فعالیت ها راهنمایی ها ، دستاوردها و نقش ها ٦ در قالب دیسیپلین ها یا جریان های منظم و منطقی مجموعه ی کارها می باشد.
اهداف معماری نرم افزار:
هدف آن اطمینان از تولید با کیفیت بالا نرم افزاری است ، درون یک جدول زمانی قابل پیش بینی و بودجه می باشد. فرایند یکپارچه عقلانی(rup) را محصول فرایند ، توسعه یافته است و rupعرضه نرم افزار توسط تیم توسعه برای فریند یکپارچه عقلانی می باشد با همکاری نزدیک با مشتریان ، شرکای تجاری ،محصول و همچنین گروه های سازمان مشاوره عقلانی می کند، تا اطمینان حاصل شود و این فرآیند به طور مداوم به روز شده و پس از بهبود به منعکس کننده تجارب اخیردر حال تکامل و به اثبات رسیده می باشد .فرایند عقلانی یکپارچه rup برای افزایش بهره روی تیم یک پایگاه دانش برای ارئه دسترسی همه ی اعضای تیم به ان را فراهم می آورد وتمام اعضاد و مربیان با داشتن الگوی از این برای توسعه تمام فعالیتها به مدیریت ،، طراحی ، تست پروژه اقدام می کنند.
فرایند یکپارچه عقلانی توسط ابزار به طور خودکار بخش های بزرگی از این فرایندتوسعه نرم افزار را حمایت ازجمله : مدل سازی ، برنامه نویسی ، تست ، مدیریت تنظیمات ،از اهدف مهم rup برای توسعه نرم افزار:
1- توسعه مکرر نرم افزار
2-الزامات مدیریت
3- استفاده از اجزاء مبتنی بر معماری
4- مدل بصری نرم افزار
5- نگارش دوباره با کیفیت نرم افزار
6- کنترل تغییرات نرم افزار
استفاده از معماری مبتنی بر مولفه فرایند توسعه زودهنگام و baselining از قویترین معماری اجرایی ، قبل از ارتکاب منابع برای توسعه تمام عیار. این توصیف چگونه برای طراحی قابل انعطاف و accommodates قابل تغییر است ، به طور مستقیم قابل درک است ، و ترویج استفاده بیشتر ومجدد از نرم افزار موثر است. پشتیبانی از کامپوننت یکپارچه فرایند توسعه مبتنی بر نرم افزار است. واجزای غیر ماژول ها و بی اهمیت در subsystems که تحقق یک تابع روشن است. یکپارچه فرایند عقلانی را فراهم می کند. دید مدل نرم افزار فرایند به شما نشان می دهد که چگونه مدل را به صورت بصری نرم افزار به تصرف خود در ساختار و رفتار و اجزای معماری. این به شما اجازه می دهد تا برای مخفی کردن جزئیات و نوشتن کد با استفاده از "گرافیکی بلوک ساختمانی ". انتزاعی تجسمی کمک جنبه های مختلف از نرم افزار خود را به شما و ارتباط ؛ دید که چگونه عناصر سیستم متناسب با هم مطمئن شوید که بلوک های ساختمان با کد شما مطابقت دارند ؛ حفظ هماهنگی بین طراحی و پیاده سازی آن ؛ و ترویج ارتباطات بدون ابهام. industrystandard
زبان یکپارچه مدلسازی (UML) ایجاد شده توسط نرم افزار عقلانی را ، شالوده ای برای دیداری موفقیت آمیز است .
چهار فاز یک پروژه در آر.یو.پی و مراحل مهندسی و فرآوری:
چرخه یا فرایند پروژه در rupشمامل چهار فاز یا چهار چرخه است .که عبارتند از:
فاز آغازین (شناخت)
فازتشریح (معماری)
فاز ساخت
فاز انتقال
دو فازِ اول را مرحله ی مهندسی و دو فاز آخر را مرحله ی فرآوری می نامند. همانگونه که در شکل نرم افزار در طول چهار فاز آر.یو.پی، روندی تکاملی را پشت سر می گذارد
در این فرایند، تکامل فراورده ی نرم افزاری را می توان به بزرگ شدن یک گلوله ی کوچک برف که ازبالای یک کوه به سمت پایین سرازیر شده است، تشبیه نمود. البته اگر در مسیر این گلوله ی برف موانع پیش بینی نشده اییا همان ریسک ها وجود داشته باشد، گلوله متلاشی خواهد شد و احتمالاً به جای یک گلوله ی کامل برف که معادل یک فراورد هی نرم افزاری با کیفیت مطلوب می باشد، چندین قطعه ی کوچک نصیبمان خواهد شد. بنابراین یک جایی در این مسیر باید آگاهی و اطلاع خوبی از موانع احتمالی و همچنین استحکام مناسب گلوله ی برف داشته باشیم و البته این کار با نشستن بالای کوه و نقشه و طرح ریختن ممکن نیست این ملاحظات در مورد نرم افزار یعنی تثبیت و استحکام معماری آن. آر.یو.پی که بر اساس تجربه ی موفق پروژه های مختلف ایجاد شده، به دلیل اهیمت موضوع معماری و تثبیت هر چه سریعتر آن، یک فاز را به معماری اختصاص داده است در انتهای هر یک از فازهای چهارگانه ی آر.یو.پی، یک نقطه ی تصمیم گیری کلیدی یا سازمانی، وجود دارد. در واقع، بر خلاف فازهای فرایند آبشاری که ماهیت فعالیت و کار را در بر دارند، مفهوم فازهای آر.یو.پی رسید ن به یک نقطه ی تصمیم گیری کلیدی و اتخاذ تصمیم مناسب می باشد به عنوان مثال، فاز شناخت دررویکرد آبشاری، بازه ی زمانی است که در آن مجموعه ی فعالیت های مرتبط با شناخت انجام شده و پایان این فاز منوط به انجام شدن کاملِ این مجموعه فعالیت ها می باشد. بدین ترتیب برگشت از یک فاز به فاز قبلی در فرایند آر.یو.پی معنایی ندارد. در صورتی که داشتن برگشت های مکرر از یک فاز به فاز یا فازهای قبلی، از ویژگی های فرایندهای مبتنی بر رویکرد آبشاری می باشد. توجه داشته باشید که فرایند آبشاری با داشتن ویژگی برگشت های مکرر و عمدتاً غیر قابل پیش بینی، دیگر جایگاهی در صنعت نرم افزار ندارد.
آر.یو.پی به عنوان محصولی دربرگیرنده ی چارچوب فرایند:
هر سازمان و یا پروژه ی خاص، نیازمند به داشتن فرایند خاصی متناسب با نیازها، ضروریات، و ملاحظات مختص خودش می باشد. بنابراین، فرایند تولید در پروژه های مختلف، متفاوت است و یک فرایند مناسب، باید دارای قابلیت تطبیق با شرایط و موقعیت های خاصِ هر پروژه و یا سازمان باشد. یکی از ویژگی های برجسته و کم نظیر آر.یو.پی این است که آر.یو.پی محصولی است که چارچوب کاملی را برای الگوبرداری و تعریف فرایندهای مختلف در طیف گسترده ای از پروژه های با ابعا د متنوع (کوچک، متوسط و بزرگ) و در زمینه ها و موضوعات مختلف (حتی پروژه های غیر نرم افزاری) فراهم می آورد در واقع، آر.یو.پی یک فرایند نیست که بتوان آن را به همان شکلی که ارایه شده، در یک پروژه بکار گرفت. آر.یو.پی گنجینه ای است غنی از راهکارهای موفق برای گستره ی وسیعی از پروژه ها. بنابراین، آر.یو.پی یک بانک دانش و چارچوب فرایند است نه صرفاً یک فرایند

شکل 2-4
چارچوب فرایند)سمت چپ( و فرایند حاصل (سمت راست(

ابزارهای تالیف و پیکربند آر.یو.پی:
آر.یو.پی فرایندی است که نمی توان آن را به همان صورتی که هست، در یک پروژه بکار گرفت. متاسفانه درطول سال های اخیر، سازمان ها و تیم های زیادی در کشور ما به این نکته توجه نداشته و سعی نموده اند که مثلا تمام دستاوردهای مطرح در آر.یو.پی را به همان شکل اولیه ی نها تولید نموده و فعالیت های مطرح شده را انجام دهند. این کار تنها موجب انجام کارهای اضافی و زائد شده و در پایان، با مجموع هی حجیمی از دستاوردهایی غیر ضروری با ارزش افزود هی بسیار کم، حاصل می شود.
شکل 2-5
نمایی از روش های مختلف پیکربندی آر.یو.پی

بخش سوم: ویژگی ها و روحِ آر.یو.پی
ویژگی های کلیدی آر.یو.پی، که آن را به عنوان یک فرآیند بالغ و تکامل یافته برای تولید فراورده های نرم افزاری مطرح نموده است، عبارتند از:
داشتنِ رویکرد مبتنی بر توسعه ی تکرارشونده و تکامل تدریجی متمرکز بر معماری
توسعه بر مبنای موارد کاربرد بر اساس نیازها و خواست ههای مشتری
مدل معماری rup:
آر . یو . پی مدلی از معماری تحت عنوان معماری را معرفی می نماید . معماری که در آن حداقل 1+4 دیدگاه (منظر)را معرفی می نماید معماری که در آن حداقل ۵ منظرمختلف از معماری فراهم می گردد .
شکل 3-1
مدلِ معماری1 +4در آر.یو.پی

منظرمنطقی:
در این منظر از معماری، ملاحظات مربوط به نیازمندی های وظیفه مندی و کارکردی سیستم مطرح می گردد به عبارت دیگر، این منظر به چیستی های سیستم یا مجموعه ی بایدها و نبایدهای مورد انتظار کاربران نهایی مرتبط می باشد. این منظر، سطح تجریدی ( سطحی با حذف جزئیات غیر ضروری ) از مدلِ طراحی می باشد ودر آن بسته ها ، زیرسیستم ها، و کلاس های اصلی طراحی، دیده می شود.
منظرِ پیاده سازی:
این منظر از معماری، به منظورِ توصیف چگونگی سازماندهی مولفه ها و ماجول های نرم افزاری کدها، داده ها،مولفه ها، نسخه های اجرایی، و دیگر دستاوردهای مرتبط ) در قالب بسته ها ، لایه ها ، و ملاحظات مرتبط با مدیریت پیکربندی ارائه می گردد . مسائلی مانند سهولت تولید، مدیریت دارایی ها، استفاده ی مجدد پیمانکاران جزء ، و مولفه های آماده در این منظر مورد بررسی قرار می گیرد.
منظرِ پردازه ای:
ملا حظات مرتبط با جنبه های همرندی سیستم در زمان اجرا، مانند وظیفه های سیستمی، نخ کشی ها ، یا پردازه ها ، و نیز تعاملِ میان آنها، در این منظر بررسی می شود . همروندی و توازی، ملاحظات مرتبط با بالاآوردن و پایین بردن سیستم ، میزان تحمل پذیری نسبت به خطا ، و توزیع شدگی ، از مهم ترین مسائلِ مورد بررسی در این منظر می باشند . نقاط بار زیاد و بن بست ها ، زمان پاسخ، ظرفیت ورودی و خروجی سیستم ، و نیز مقیاس پذیری ، از دیگر ملاحظات مورد بررسی در این منظر می باشند
منظرِ استقرار:
در این منظر از معماری، چگونگی استقرار مولفه های زمان اجرا، مانند فایل های اجرایی و بانک های اطلاعاتی،روی گره های بستر سخت افزاری پیش بینی شده، بررسی می شود . در این منظر از معماری است که مهندسی ِنرم افزار و مهند س سیستم با هم همکاری می نمایند . مسائلی مانند استقرار، نصب، و کارایی در این منظرمورد بررسی قرار می گیرند.
منظرِ مورد کاربرد:
این منظر، نقش خاصی در معماری نرم افزار ایفا می نماید . این منظر، شاملِ یکسری از کلیدی ترین سناریو ها یا مواردکاربرد می باشد . این مجموعه سناریوها یا مواردکاربرد، در فازهای آغازین شناخت و تشریح معماری برای کشف، طراحی، و ایجاد معماری مناسب و در فازهای بعدی، برای اعتبارسنجی منظرهای مختلف بکار می رود.
اهداف کلیدی هر یک از فازهای آر.یو.پی به شرح زیر می باشد:
– فاز آغازین )شناخت:( اثبات درک صورت مساله و مشکلات موجود، تسکین ٢ و فرونشانی ریسک ها مخاطرات سازمانی، و جلب نظرِ موافق تمام ذینفعان نسبت به مقرون به صرفه بودن و نیز امکان پذیر بودن ادامه ی پروژه
– فاز تشریح (معماری: (غلبه بر ریسک های فنی با تثبیت یک معماری قابل اجرا ٥ ، دقیق تر نمودن
برنامه ی اجرایی پروژه
– فاز ساخت: ایجاد سیستمی با تمام قابلیت های مورد توافقنسخه ی بِتا
– فاز انتقال : کسب اطمینان نسبت به اینکه سیستم نرم افزاری حاصل، تمام خواسته ها و نیازهای
تثبیت شده ی کاربران را برآورده می کند و انتقال کامل محصول به محیط کاربران نهایی آن.
در روش سنتی برنامه ریزی پروژه (یعنی روش آبشاری (، سازماندهی برنامه ی اجرایی، عمدتاً به صورت بالا به پایین و مبتنی بر اجزاء محصول انجام می شد. به عبارت دیگر، برنامه ریزی پروژه بر اساس تجزیه ی سیستم به مولفه ها و انواع دستاوردهای مختلف مربوط به محصول نهایی مانند توصیف ها، طرح ها و نقشه ها، صورت می گرفت. این شیوه ی برنامه ریزی، از صنایع ساخت و تولید به ارث رسیده است. در آر.یو.پی، برنامه ریزی مبتنی بر شکستنِ فرایند می باشد. این بدان معناست که برنامه ی اجرایی یک پروژه بر اساس الگوی تعریف شده در آر.یو.پی، بیانگر اینست که برای دستیابی به یکسری اهداف و مقصودهای مشخص در طول زمان، چه کارهایی باشد انجام شود. البته توجه داشته باشید که در آر.یو.پی، برنامه ریزی با هر دو رویکرد بالا به پایین و نیز پایین به بالا انجام می شود. در مرحله ی مهندسی)یعنی فازهای آغازین و تشریح)، رویکرد غالب، بالا به پایین می باشد و در مرحله ی فرآوری(یعنی فازهای ساخت و انتقال)، از رویکرد پایین به بالا، برای برنامه ریزی استفاده می شود. رویکرد پایین به بالا، از دستاوردهای تعریف شده و نیز مبنایی که بر اساس معماری شکل گرفته، استفاده می نماید
چه کسانی از آر.یو.پی استفاده می نمایند؟
متاسفانه آمار دقیقی از تعداد استفاده کنندگان و مشتریان آر.یو.پی در دست نمی باشد. بر اساس آخرین اطلاعات موجود، در سال ۲۰۰۳ میلادی، بیش از ده هزار شرکت و سازمان در سرتاسر جهان از محصول آر.یو.پی استفاده می کردند. البته این اعدام و ارقام، بیانگر تعداد رسمی استفاده کنندگان می باشد. اما تعداد بسیار زیادی از شرکت ها و موسسات کوچک و متوسط، به صورت غیر رسمی بدون خرید محصولِ آر.یو.پی و یا مشارکت رسمی در دوره های تخصصی شرکت رشنال از این فرایند استفاده می ینمایند. مجموعِ آمارهای رسمی و غیر رسمی، نشان می دهد که تا انتهای سال ۲۰۰۳ ، تعداد استفاده کنندگان از آر.یو.پی در جهان، بیش از بیست هزار مورد می باشد . این شرکت ها و سازمان ها، آر.یو.پی را به منظور تولید سیستم ها و نرم افزارهای کاربردی در زمینه ها و حوزه های مختلف و در طیف وسیعی از پروژه های بزرگ و کوچک بکار می گیرند. برخی از همین شرکت ها، آر.یو.پی را در توسعه ی سیستم های غیر نرم افزاری بکار گرفته اند.
برخی از مهم ترین صنایع استفاده کننده از آر.یو.پی عبارتند از:
– صنعت مخابرات
– صنعت حمل و نقل ، هوافضا و صنایع دفاعی
– صنعت ساخت و تولید
– خدمات مالی
– یکپارچه سازی سیستم ها
پذیرش آر.یو.پی در حوزه ی وسیعی از صنایع در طی سال های گذشته، بیانگر نوعی تغییر و تحول جالب توجه در صنعت نرم افزار می باشد. با افزایش فشار زمانی ورود به بازار و همچنین تقاضاهای روزافزون برای تولید سیستم های کاربردی با کیفیت برتر، شرکت های مختلف را به سمت بهره گیری بیش از پیش از تجارب و راهکارهای موفق سوق داده است؛ آر.یو.پی نیز گنجینه ای است از راهکارها و تجارب موفق.

فهرست منابع مورد استفاده در این فصل

1-معرفی rup (چارچوپ فرایند تولید سیستم های نرم افزاری )،نویسنده : محمد بدری ، برگرفته از سایت: www.safware-acadmay (آکادمی نرم افزار)
آدرس: تهران، خ آزادی، بلوار شهید اکبری، خ شهید قاسمی، کوی تیموری، پلاک 3
2-منبع لاتین :
Rational unified processd for soft war development teams
برگرفته ازسایت :www.rational..com

فصل سوم :

زبان یکپارچه مدل سازی UMLچیست؟

(UNIFIED MODELLING LANGUAGE)

درخت تحقیق فصل سوم:

بخش 1: مقدمه ای بر uml
بخش 2: ویژگی های ونمودارهای در uml

بخش 1: مقدمه ای بر uml یک زبان مشترک در توسعه نرم افزار
موضوعات مورد مطالعه در این بخش : umlچیست
یک زبان مشترک :
تمام صنعتها برای خود یک زبان مشخصی دارند مثلا انتگرال در ریاضیات شکل خا صی دارد تمام ریاضی دانان جهان بادیدن این شکل متوجه میشوند که من انتگرال را نشان داده
ام بنابراین این نمادسازی بسیار ساده است وتمام ریاضی دانان جهان میتوانندبه وضوح و بدون هیچ گونه ابهامی با این شکل رابطه برقرار کنند. ریاضی دانان زبان مشترکی برای انتقال مفاهیم دارند درست مثل موسیقی دانان ،مهندسان الکترونیک ،مهندسین ساختمان وبرخی دیگراز حرفه ها . تا امروز زبان مشترک بین مهندسین نرم افزار ناقص است .ازسال 1989تاسال 1994دوره ای بود که به آن جنگ متدها می گفتند.بیشتر از 50 زبان مدل سازی نرم افزار وجود داشت که هر کدام شکل وشمایل مخصوص به خودرا داشتند و هیچ کدام از انها کامل نبود.در اواسط سال 1990 سه متد مدل سازی نرم افزار به عنوان قویترین متدها معرفی شدند.که هرکدام از این متد ها مزیتهای متفاوتی نسبت به دو متد دیگر داشت.این سه متد و مزیتهای آنها عبارتند از:
Booch:برای طراحی مدلسازی عالی بود ،ابداع کننده این متد یعنی Gradybooch با زبان adaکار می کرد وباعث شد این متد را ابداع کند.اگر چه این متد قوی بود ولی علامتها و نشانه گذاری بسیار ضعیفی داشت .(تعداد زیادی از شکلها شبیه به توده ابر بئدند که خیلی زیباهم ودند. )
OMT (objct modlling technique):برای تحلیل سیستمهای اطلاعاتی بهتر بود .
OOSE:(object oriented softwareengineering) :یک مدل شبیه به مدل مورد کاربرد (use cases) بود. موارد کاربرد تکنیک قدرتمندی برای فهم رفتار کل سیستم است.در سال 1994سازنده متد omtیعنی jim rumhagh وقتی الکترونیک را رها کرد و به grady boochدر شرکت Rtionalپیوست جامعه مهندسین نرم افزار حیرت زده شدند هدف مشارکت این دونفر این بود که ایدهایشان را ترکیب کنند و در قالب یک متد متحد ارائه دهند.که دراتن زمان به متدی که این دونفر ابداع کردند نام method unified را اختصاص دادند.
در سال 1995سازنده oose یعنی jvar jacobsonنیز به retionalپیوست وایده های او نیز به خورد متد unified method داده شد ونهایتا متد بوجود آمده unified modeling languageنام گرفت .(این گروه سه نفره که بنیان گذار ان uml هستند به سه تفنگدار معروف هستند.)رفته رفته این متد جدید در صنعت نرم افزارمحبوبیت پیدا کرد.وکنسر سیوم umlرسمیت پیداکرد.که شرکتهای oracl,Microsoft,hewlelt-packardعضو این کنسر سیوم هستند.
Uml چیست :
برای چینش اجزاء مختلف سیستم نرم افزاری و نمایش روابط بین آنها و سایر موجودیتهای سیستم نرم افزاری . برای اینکه طراحی مدل برای سیستمهای نرم افزاری قالبی یکدست و یکپارچه و جهان شمول داشته باشد و تبادل اطلاعات بین مدلهای طراحی شده توسط افراد مختلف امکان پذیر باشد تلاشهای متعددی صورت گرفته است که UML یکی از آنهاست ، که در حال حاضر متداولترین استاندارد تولید مدل برای سیستمهای نرم افزاری در سراسر دنیاست . UML مخفف Unified Modeling Language است . UML برای مدل سازی سیستمهای نرم افزاری و تسهیل طراحی شیء گرای سیستم دیاگرام ( و استانداردهای مرتبط با هرکدام ) را ارائه مینماید . قبل از توضیح بیشتر و ارائه تعاریف مقدماتی به نکته ذیل توجه کنید : دوستان کم تجربه اغلب سوال میکنند که چرا UML مهم است و این روزها مانور زیادی روی آن میشود ؟ آیا لزومی دارد که به UML مسلط شویم ؟ آیا اصولا" این جانور به درد ما میخورد ؟ درجواب باید گفت: تا حالا دیده اید که کسی یک ساختمان بزرگ با پیچیدگیهای مختلف را "بدون نقشه" و الگوی از پیش معین شده بسازد و این پروژه موفقیت آمیز باشد ؟ آیا تا کنون شنیده اید که هیچ کدام از کارخانه های تلوزیون سازی بودن هیچ نقشه و پیش بینی فنی موفق به ساخت تلوزیونی شوند که کار کند ؟ یا اصلا" ساخته شود ؟ آیا تا کنون دیده اید کشوری بدون سیاستهای کلان و بدون سنجش جوانب امر ، موفق به مدیریت امور داخلی خود شود ؟ و ده ها سوال از این دست خواندن این سوالها بدون اینکه حتی ثانیه ای به جواب انها فکر کنید ، خود ، جواب به سوالات اولی است UML به عنوان استانداردی برای طراحی و پیش بینی جزئیات فنی سیستم نرم افزاری ، نحوه ارتباط اجزاء ، نوع و نحوه کارکرد قسمتهای مختلف و … یکی از ملزومات تولید کنندگان نرم افزار در دنیای امروز است . حتی اگر مستقل کار میکنید و نرم افزارهای کوچک تولید میکنید با استفاده از UML در "اغلب" موارد به بالاترین حد بهینگی مراحل طراحی و تولید نرم افزارتون خواهید رسید و نکته آخر این که UML و استانداردهای آن ( که در موردشون صحبت خواهم کرد ) و ابزارهای آن ( CASE Tool ها که موضوع مقاله بعدی هستند ) آنقدر ساده و سهل هستند که صرف هزینه و وقت برای یادگیری و تسلط بر آنها نسبت به مزایائی که در قبال آن کسب خواهید کرد تقریبا غیر قابل توجه است
تعریف کلمات کلیدی و عناصر اصلی UML :
مدل : ، مدل از تعدادی "شیء" تشکیل شده است .
شیء : هر یک از اجزاء نرم افزار یک "شیء" نام دارد .
کلاس: مشخصه ها و تعاریف عمومی یک "شیء" در کلاس مربوط به آن تعریف میشود . هر شیء نمونه ساخته شده از یک کلاس است . کلاس ، وظایف ، قابلیتها ، خصوصیتهای آن موجودیت نرم افزاری را تعریف میکند و طراح با ساختن یک نمونه از کلاس ( شیء ) و ارائه مقادیر مرتبط با محل خاص استفاده آن یا قرار دادن آن در مسیر وقایع لازم ، محیط مورد نظر خود را طراحی میکند . نمونه های مختلفی از یک کلاس در قالب اشیاء مختلف ساخته میشوند ، ضمن اینکه میتوان یک شیء را بطور همزمان از دو یا تعداد بیشتری کلاس ساخت . یعنی شی مذکور تمام مشخصه های کلاسهای فوق خود را به "ارث" خواهد برد .
در یک مدل شیء گرا ، شیء ها از طریق Message ها با یک دیگر ارتباط برقرار میکنند . یک نمونه Message ، فشرده شدن کلید چپ ماوس وقتی اشاره گر آن روی یک Button ، میباشد . اینجا ماوس ( به عنوان یکی از اشیاء موجود در هر سیستم نرم افزاری ) به شیء دیگری بنام Button ( که مثلا" از CButton یا TButton که کلاسهای فوق آن هستند ساخته شده است ) یک Message ارسال نموده است.
اهداف uml :
Umlبه عنوان زبان مشترک نرم افزاری برای مدلسازی و پیاده سازی نر افزار می توانند اهداف زیر را داشته باشد.
گردش کار: گردش کار می تواند به عنوان نمودار ، نمودار همکاری یا نمودار فعالیت های بیان شود.
گردش هسته : گردش هسته در فرایند عقلانی را یکپارچه فرایند ، که نمایانگر پارتیشن بندی از همه فعلیتها در تیم مهندسی نرم افزار است . گردش فرایند هسته ای را به شش هسته تقسیم می شوند : "مهندسی" گردش : 1. مدل سازی کسب و کار گردش 2. گردش مورد نیاز 3. تجزیه و تحلیل و طراحی گردش کار 4. گردش کار اجرایی 5. گردش کار تست 6. گردش گسترش
مدل کسب و کار :
یکی از مشکلات عمده ای با اکثر تلاش مهندسی کسب و کار ، این است که مهندسی نرم افزار و کسب و کار جامعه مهندسی انجام و ارتباط لازم را نمی کند با یکدیگر. این منجر به خروجی از کسب و کار مهندسی است که نمی مناسب را به عنوان ورودی به تلاش های توسعه نرم افزار استفاده می شود و معاون بر عکس .
نیازمندیها:
هدف از گردش مورد نیاز است برای توصیف آنچه را که سیستم باید انجام دهید و اجازه می دهد تا
توسعه دهندگان و مشتری به توافق در آن توضیحات. برای رسیدن به این ، ما جلب ، سازماندهی و کارکردهای مورد نیاز و سند محدودیت ؛ آهنگ و tradeoffs سند و تصمیم گیری. و…
پیاده سازی:
هدف از پیاده سازی می باشد :
• به تعریف سازمان از کد ، از لحاظ subsystems پیاده سازی سازمان یافته در لایه های.
• پیاده سازی کلاس ها و اشیاء در شرایط از اجزای سازنده (فایل های منبع ، باینری ، اجرایی ، و دیگران).
• برای تست اجزای توسعه به عنوان واحد.
• ادغام نتایج تولید شده توسط مجری فردی (یا تیمها) ، به یک سیستم قابل اجرا.
سیستم را از طریق پیاده سازی اجزای سازنده قطعی می باشد. یکپارچه فرایند عقلانی را چگونه توصیف می کنید
استفاده مجدد از قطعات موجود ، پیاده سازی و یا قطعات جدید با مسئولیت به خوبی تعریف شده ، ایجاد سیستم آسان تر برای حفظ ، و افزایش امکانات خود را به استفاده مجددتست:
هدف از تست عبارتند از :
• برای تایید اثر متقابل بین اشیاء.
• برای تایید ادغام مناسب همه اجزای سازنده نرم افزار است.
• برای تایید است که همه شرایط را به درستی اجرا شده است.
• شناسایی و اطمینان از نقص هستند خطاب قبل از استقرار نرم افزار است.
گویا پیشنهاد یکپارچه فرایند روش iterative ، که بدان معنی است که شما را در سراسر پروژه تست. این اجازه می دهد تا شما را به یافتن نقص چه زودتر ، که ریشه ای را کاهش می دهد هزینه های رفع نقص. امتحان عبارتند از به اجرا درآمدخارج همراه سه کیفیت قابل اعتماد بودن ابعاد ، کارکرد ، عملکرد بهتر ، نرم افزار و عملکرد سیستم. برای هر یک از ابعاد کیفیت این ، فرایند توصیف می چرخه که چگونه شما را از طریق آزمون برنامه ریزی ، طراحی بروید ، پیاده سازی ، اجرا و ارزیابی است
بخش 2: ویژگی های ونمودارهای در uml
قبل از اینکه به سراغ خود زبان umlبرویم مفاهیمی کلی از این زبان را شرح خواهیم داد.زبان umlاز چند نمودار (مدل)تشکیل شده است که به واسطه ای این نمودارها ما قادر خواهیم بوداز چند جهت یک سیستم را ببینیم یا بسازیم در توسعه نرم افزار چندین نقش وجود دارد.برای مثال :
تحلیگران
طراحان
کدکنندگانcooder) )
مشتری
پشتیبانی فنی
هرکدام ازاین نقشها وابسته به یک جتبه از سیستم هستند وهرکدام سطح متفاوتی از جزئیات نیاز دارند .برای مثال کدکنندگان سیستم باید بفهمند تا قادر باشند آن را به کد تبدیل کنند .ولی مشتری به چنین جزئیاتی نیاز د.پس باید یک دید دیگری از سسیستم را به مشتری نشان داد.تا بفهمد کل سیستم جه کار انجام می دهد. به طور حتم انتظاری نیست که طراحی کلاسهای سیستم را برای مشتری که هیچ اطلاعتی از برنامه نویسی نداردبفرستید وبگویید که این سیستم این کارها را انجام می دهد. Umlزبانی است که به واسطه نمودارهای مختلف خود ،غهم سیستم را برای تمام نقشهای یک پروژه مقدور کرده است .
نمودارهای مورد استفاده در uml:
نمودار مورد کاربرد (use case diagram)
(شکل2-1)

strat up
operator
shutdown

produce report

View order stauts Order system

نمودار مورد کاربرد رفتار سیستم را از نظر کاربر شرح می دهد.این نمودار در هنگام تحلیل سیستم بسیار باارزش است .توسعه موارد کاربرد به ما کمک می کند که نیازمندیهای سیستم را درک کنیم این نمدار به راحتی قابل فهم است واین موضوع موجب می شود که هم توسعه دهندگان سیستم (تحلیل گرا-کدنویس – امتحانگر) وهم مشتری بتواند با این نمودرا کار کنند. درست است که نمودار مورد کاربرد بسیتذر مفید است اما نباید ازآن چشم پوشی کرد.چون به واسطه ای این نمودار است که فرایند توسعه سیستم از فاز دریافت به فاز جزئیات می رود.
نمودار کلاس (class diagram):
از نمودار کلاس برای طرح ریزی مفاهیم عمده ای که مشتری آنها را می فهمد استفاده می شود.(وبه همین دلیل به ان مدل مفهومی نیز می گویند.) مدل مفهومی یک تکنیک بسیار قدرتمند در تحلیل نیازمنذیها است.

رسم نمودار کلاس:
(شکل 2-2)

ISWRITTENBY

has achieved

Is tuagt by is satisfied by
Is hosted at

نمودار همکاری (coallboration diagram) :
در نرم افزارهای شی گرا تمام کارهای که برنامه باید انجام دهد. توسط عهمکاری اشیاء برنامه صورت می گیرد .درزبان uml ما می توانیم نمودارهمکاری اشیاء را رسم کنیمکه نحوه ی اشیاء برنامه را شرح دهد. Umlرا مثل حروف الفبا فرض کنید .حروف افبا فقط به شما می گویند که چطور کلمات وجملات رابنویسید.ولی هرگز به شمانمی گویند چطور یک کتاب بنویسید.درست است که درک نشانهای umlآسان است .مثلا برای معرفی یک کلاس یا یک شی از یک مربع که به سه قسمت تقسیم میشود استفاده میشود. ولی طراحی همکاری وارتباط بین اشیاء سخت است که به این قسمت طراحی نرم افزار می گویند.که باید قوی و محکم باشدتا توسعه نرم افزار ساده باشد.
نمودارترتیبdigram) (sequenc:
نمودار ترتیب کاملا به نمودار همکاری وابسته است وهردوی انها یک اطلاعات را نشان میدهند.بعضی از ابزارهای زبان uml مثل Rtional Rose به صورت خودکارمی توانند نمودار ترتیب رااز نمودار همکاری تولید کنند.

نمودار وضعیت (state diagram):
بعضی از اشیاء در هر زمان میتواند در هرزمان میتواند در یک وضعیت خاصی باشند .مثلا چراغ راهنما میتئانر به یکی از وضعتهای خاموش،قرمز، زرد،ویا سبز داشته باشد.بعضی از وقتها ترتیب انتقال بین وضعیتهای خیلی پیچیده است.با اینکه چراغ راهنما یک مثال بسیار ساده است ولی رعایت همین نکات ساده ونامنظم بودن تغییر وضعیت ها موجب به وجود امدن مشکلات اساسی در یک سیستم نرم افزاری میشود.برای مثال درشهری یک صورت حساب گاز برای یک شخصی که چهار سال قبل در گذشته فرستاده شده بود..این اتفاق واقعا افتاده است وفقط به این دلیل که یک برنامه نویسی در یک جا دقت کافی در تغییر وضعیتها نداشته وموجب ارسال این صورت حساب شده است.پس چون انتقال وضعیتها بسیار پیچیده هستند.زبان umlنمودار وضعیت را به وجود اورده است تا به واسطه این نمودارنحوه تغییر وضعییت اشیاء رابه دقت مدل کنیم .
نمودار بسته یا بسته بندی( package diagram):
سیستمعهای بزرگ برای اینکه بهتر درک شوند ،باید به قسمتهای کوچکتری تقسیم شوند. ونمودار بسته بندی در umlمارا قادر می سازدتا این تقسیم را به طور کارامدی مدل کنیم
نمودار اجزاء:
نمودار اجزا شبیه به نمودار بسته بندی است .ومشخص می کند که سیتم مااز چه قسکتهای تشکیل شده است .وهمچنین وابستگی هی بین هر ماژول رامعین می کند .برخلاف نمودار بسته بندی که تاکید آن برقسمت بندی نرم افزار است .تاکید نمودار اجزا براجزای فیزیکی تشکیل دهنده نرم افزار (فایلها ،هدرها ،و فایلهای اجرایی و…) است.

نمودار گسترش (deployment diagram):
زبان umlنموداری برای مشخص کردن اینکه نرم افزار چگونه گسترش داده می شود به وجود آورده است .

فهرست منابع مورد استفاده در این فصل

1- کاربرد UML و تحلیل و طراحی شی گرا با استفاده از UML مترجم :ایمان رحیمی نیا سال انتشار 1385
2 – منبع لاتین : Systems Engineering with SysML/ uml
نویسنده: TIM WEILKIENSS

پیوست

نمونه ی از یک فرایند سفارشی شده در آر.یو .پی :

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

استفاده از راهنمای گسترش یافته ی آر.یو.پی در سایر ابزارها :

فهرست شکلها

عنوان صفحه

فصل اول :
شکل 3-1:مثلث موفقعیت پروژه……………………………………..6
شکل3-2:فرایند تولید محصول …………………………………..7
بخش سوم: شکل3-3:مدل ارتباط مفاهیم پروژه و فرایند محصول………………..8
شکل3-4:امار مربوط به موفقعیت پروزهای نرم افزاری در سال1979……9
شکل3-5: امار مربوط به موفقعیت پروزهای نرم افزاری در سال1995..9
شکل3-6: امار مربوط به موفقعیت پروزهای نرم افزاری درسال2000…10

شکل 4-1:سازماندهی فرایند آر.یو.پی در دوبعد……………………….. ..11
شکل4-2:افزایش هزینه و مدیریت ریسک ………………………………11
بخش چهارم : شکل4-3:مدل تکرار……………………………………………………..11
شکل4-4:مدل حلزونی ……………………………………………….11
شکل 4-5:مقایسه ریسکها در رویکرد آبشاری ……………………………12

شکل4-6:مدل حلزونی …………………………………………….13
فصل دوم: RUP

شکل 2-1:تاریخچه آر.یو.پی…………………………………..21
شکل2-2:معماری آر.یو.پی………………………………..23
بخش دوم : شکل2 -3:فرایند آر.یو.پی……………………………………24
شکل2-4:چارچوب فرایند آر.یو.پی……………………………27
شکل2-5:روشهای مختلف پیکربندی آر.یو.پی……………………27

بخش سوم:شکل 3-1: مدل معماری1+4rup……………………………28

فصل سوم:uml
شکل 2-1:نمودار مورد کاربرد ………………………………38
بخش دوم: شکل2-2: نمودار کلاس ……………………………………. 39

منبع اصلی ترجمهای استفاده شده در پروژه
Rup:
What is the Rational Unified Process?
The Rational Unified Process(r) is a Software Engineering Process. It provides a disciplined approach to assigning
tasks and responsibilities within a development organization. Its goal is to ensure the production of high-quality
software that meets the needs of its end-users, within a predictable schedule and budget.
The Rational Unified Process is a process product, developed and maintained by Rational(r) Software. The
development team for the Rational Unified Process are working closely with customers, partners, Rational's product
groups as well as Rational's consultant organization, to ensure that the process is continuously updated and
improved upon to reflect recent experiences and evolving and proven best practices.
The Rational Unified Process enhances team productivity, by providing every team member with easy access to a
knowledge base with guidelines, templates and tool mentors for all critical development activities. By having all
team members accessing the same knowledge base, no matter if you work with requirements, design, test, project
management, or configuration management, we ensure that all team members share a common language, process
and view of how to develop software.
The Rational Unified Process activities create and maintain models. Rather than focusing on the production
of large amount of paper documents, the Unified Process emphasizes the development and maintenance of
models-semantically rich representations of the software system under development. The Rational Unified Process is a guide for how to effectively use the Unified Modeling Language
(UML). The UML is an industry-standard language that allows us to clearly communicate requirements,
architectures and designs. The UML was originally created by Rational Software, and is now maintained by the
standards organization Object Management Group (OMG).
The Rational Unified Process is supported by tools, which automate large parts of the process. They are used to
create and maintain the various artifacts-models in particular-of the software engineering process: visual
modeling, programming, testing, etc. They are invaluable in supporting all the bookkeeping associated with the
change management as well as the configuration management that accompanies each iteration.
The Rational Unified Process is a configurable process. No single process is suitable for all software development.
The Unified Process fits small development teams as well as large development organizations. The Unified Process
is founded on a simple and clear process architecture that provides commonality across a family of processes. Yet, it
can be varied to accommodate different situations. It contains a Development Kit, providing support for configuring
the process to suit the needs of a given organization.
The Rational Unified Process captures many of the best practices in modern software development in a form that is
suitable for a wide range of projects and organizations. Deploying these best practices using the Rational Unified
Process as your guide offers development teams a number of key advantages. In next section, we describe the six
fundamental best practices of the Rational Unified Process.
Effective Deployment of 6 Best Practices
The Rational Unified Process describes how to effectively deploy commercially proven approaches to software
development for software development teams. These are called "best practices" not so much because you can
precisely quantify their value, but rather, because they are observed to be commonly used in industry by successful
organizations. The Rational Unified Process provides each team member with the guidelines, templates and tool
mentors necessary for the entire team to take full advantage of among others the following best practices:
1. Develop software iteratively
2. Manage requirements
3. Use component-based architectures
Rational Unified Process: Best Practices for Software development Teams
4. Visually model software
5. Verify software quality
6. Control changes to software
Develop Software Iteratively Given today's sophisticated software systems, it is not possible to sequentially
first define the entire problem, design the entire solution, build the software and then test the product at the end. An
iterative approach is required that allows an increasing understanding of the problem through successive
refinements, and to incrementally grow an effective solution over multiple iterations. The Rational Unified Process
supports an iterative approach to development that addresses the highest risk items at every stage in the lifecycle,
significantly reducing a project's risk profile. This iterative approach helps you attack risk through demonstrable
progress frequent, executable releases that enable continuous end user involvement and feedback. Because each
iteration ends with an executable release, the development team stays focused on producing results, and frequent
status checks help ensure that the project stays on schedule. An iterative approach also makes it easier to
accommodate tactical changes in requirements, features or schedule.
Manage Requirements The Rational Unified Process describes how to elicit, organize, and document required
functionality and constraints; track and document tradeoffs and decisions; and easily capture and communicate
business requirements. The notions of use case and scenarios proscribed in the process has proven to be an excellent
way to capture functional requirements and to ensure that these drive the design, implementation and testing of
software, making it more likely that the final system fulfills the end user needs. They provide coherent and traceable
threads through both the development and the delivered system.
Use Component-based Architectures The process focuses on early development and baselining of a robust
executable architecture, prior to committing resources for full-scale development. It describes how to design a
resilient architecture that is flexible, accommodates change, is intuitively understandable, and promotes more
effective software reuse. The Rational Unified Process supports component-based software development.
Components are non-trivial modules, subsystems that fulfill a clear function. The Rational Unified Process provides
a systematic approach to defining an architecture using new and existing components. These are assembled in a
well-defined architecture, either ad hoc, or in a component infrastructure such as the Internet, CORBA, and COM,
for which an industry of reusable components is emerging
Visually Model Software The process shows you how to visually model software to capture the structure and
behavior of architectures and components. This allows you to hide the details and write code using "graphical
building blocks." Visual abstractions help you communicate different aspects of your software; see how the
elements of the system fit together; make sure that the building blocks are consistent with your code; maintain
consistency between a design and its implementation; and promote unambiguous communication. The industrystandard
Unified Modeling Language (UML), created by Rational Software, is the foundation for successful visual
modeling.
Verify Software QualityPoor application performance and poor reliability are common factors which
dramatically inhibit the acceptability of today's software applications. Hence, quality should be reviewed with
respect to the requirements based on reliability, functionality, application performance and system performance. The
Rational Unified Process assists you in the planning, design, implementation, execution, and evaluation of these test
types. Quality assessment is built into the process, in all activities, involving all participants, using objective
measurements and criteria, and not treated as an afterthought or a separate activity performed by a separate group.
Control Changes to Software  The ability to manage change is making certain that each change is acceptable,
and being able to track changes is essential in an environment in which change is inevitable. The process describes
how to control, track and monitor changes to enable successful iterative development. It also guides you in how to
establish secure workspaces for each developer by providing isolation from changes made in other workspaces and
by controlling changes of all software artifacts (e.g., models, code, documents, etc.). And it brings a team together to
work as a single unit by describing how to automate integration and build management.
Rational Unified Process: Best Practices for Software development Teams
Process Overview
Two Dimensions
The process can be described in two dimensions, or along two axis:
• the horizontal axis represents time and shows the dynamic aspect of the process as it is enacted, and it is
expressed in terms of cycles, phases, iterations, and milestones.
• the vertical axis represents the static aspect of the process: how it is described in terms of activities,
artifacts, workers and workflows.
The Iterative Model graph shows how the process is structured along two dimensions
Phases and Iterations – The Time Dimension
This is the dynamic organization of the process along time.
The software lifecycle is broken into cycles, each cycle working on a new generation of the product. The
Rational Unified Process divides one development cycle in four consecutive phases
Inception phase
Elaboration phase
Construction phase
Transition phase
Each phase is concluded with a well-defined milestone-a point in time at which certain critical decisions must be
made, and therefore key goals must have been achieved
The phases and major milestones in the process.
Rational Unified Process: Best Practices for Software development Teams
Each phase has a specific purpose.
Inception Phase
During the inception phase, you establish the business case for the system and delimit the project scope. To
accomplish this you must identify all external entities with which the system will interact (actors) and
define the nature of this interaction at a high-level. This involves identifying all use cases and describing a
few significant ones. The business case includes success criteria, risk assessment, and estimate of the
resources needed, and a phase plan showing dates of major milestones.
The outcome of the inception phase is:
A vision document: a general vision of the core project's requirements, key features, and main constraints.
A initial use-case model (10% -20%) complete).
An initial project glossary (may optionally be partially expressed as a domain model).
An initial business case, which includes business context, success criteria (revenue projection, market
recognition, and so on), and financial forecast.
An initial risk assessment.
A project plan, showing phases and iterations.
A business model, if necessary.
One or several prototypes.
Milestone : Lifecycle Objectives
At the end of the inception phase is the first major project milestone: the Lifecycle Objectives Milestone.
The evaluation criteria for the inception phase are:
Stakeholder concurrence on scope definition and cost/schedule estimates.
Requirements understanding as evidenced by the fidelity of the primary use cases.
Credibility of the cost/schedule estimates, priorities, risks, and development process.
Depth and breadth of any architectural prototype that was developed.
Actual expenditures versus planned expenditures.
The project may be cancelled or considerably re-thought if it fails to pass this milestone.
Elaboration Phase
The purpose of the elaboration phase is to analyze the problem domain, establish a sound architectural foundation,
develop the project plan, and eliminate the highest risk elements of the project. To accomplish these objectives, you
must have the "mile wide and inch deep" view of the system. Architectural decisions have to be made with an
understanding of the whole system: its scope, major functionality and nonfunctional requirements such as
performance requirements.
It is easy to argue that the elaboration phase is the most critical of the four phases. At the end of this phase, the hard
"engineering" is considered complete and the project undergoes its most important day of reckoning: the decision on
whether or not to commit to the construction and transition phases. For most projects, this also corresponds to the
transition from a mobile, light and nimble, low-risk operation to a high-cost, high-risk operation with substantial
inertia. While the process must always accommodate changes, the elaboration phase activities ensure that the
architecture, requirements and plans are stable enough, and the risks are sufficiently mitigated, so you can
predictably determine the cost and schedule for the completion of the development. Conceptually, this level of
fidelity would correspond to the level necessary for an organization to commit to a fixed-price construction phase.
Rational Unified Process: Best Practices for Software development Teams
5
In the elaboration phase, an executable architecture prototype is built in one or more iterations, depending
on the scope, size, risk, and novelty of the project. This effort should at least address the critical use cases identified
in the inception phase, which typically expose the major technical risks of the project. While an evolutionary
prototype of a production-quality component is always the goal, this does not exclude the development of one or
more exploratory, throwaway prototypes to mitigate specific risks such as design/requirements trade-offs,
component feasibility study, or demonstrations to investors, customers, and end-users.
The outcome of the elaboration phase is:
A use-case model (at least 80% complete) – all use cases and actors have been identified, and most usecase
descriptions have been developed.
Supplementary requirements capturing the non functional requirements and any requirements that are not
associated with a specific use case.
A Software Architecture Description.
An executable architectural prototype.
A revised risk list and a revised business case.
A development plan for the overall project, including the coarse-grained project plan, showing iterations"
and evaluation criteria for each iteration.
An updated development case specifying the process to be used.
A preliminary user manual (optional).
Milestone : Lifecycle Architecture
At the end of the elaboration phase is the second important project milestone, the Lifecycle Architecture
Milestone. At this point, you examine the detailed system objectives and scope, the choice of architecture, and the
resolution of the major risks.
The main evaluation criteria for the elaboration phase involves the answers to these questions:
Is the vision of the product stable?
Is the architecture stable?
Does the executable demonstration show that the major risk elements have been addressed and credibly
resolved?
Is the plan for the construction phase sufficiently detailed and accurate? Is it backed up with a credible
basis of estimates?
Do all stakeholders agree that the current vision can be achieved if the current plan is executed to develop
the complete system, in the context of the current architecture?
Is the actual resource expenditure versus planned expenditure acceptable?
The project may be aborted or considerably re-thought if it fails to pass this milestone.
Rational Unified Process: Best Practices for Software development Teams
6
Construction Phase
During the construction phase, all remaining components and application features are developed and integrated into
the product, and all features are thoroughly tested. The construction phase is, in one sense, a manufacturing process
where emphasis is placed on managing resources and controlling operations to optimize costs, schedules, and
quality. In this sense, the management mindset undergoes a transition from the development of intellectual property
during inception and elaboration, to the development of deployable products during construction and transition.
Many projects are large enough that parallel construction increments can be spawned. These parallel activities can
significantly accelerate the availability of deployable releases; they can also increase the complexity of resource
management and workflow synchronization. A robust architecture and an understandable plan are highly correlated.
In other words, one of the critical qualities of the architecture is its ease of construction. This is one reason why the
balanced development of the architecture and the plan is stressed during the elaboration phase. The outcome of the
construction phase is a product ready to put in hands of its end-users. At minimum, it consists of:
The software product integrated on the adequate platforms.
The user manuals.
A description of the current release.
Milestone : Initial Operational Capability
At the end of the construction phase is the third major project milestone (Initial Operational Capability Milestone).
At this point, you decide if the software, the sites, and the users are ready to go operational, without exposing the
project to high risks. This release is often called a "beta" release.
The evaluation criteria for the construction phase involve answering these questions:
Is this product release stable and mature enough to be deployed in the user community?
Are all stakeholders ready for the transition into the user community?
Are the actual resource expenditures versus planned expenditures still acceptable?
Transition may have to be postponed by one release if the project fails to reach this milestone.
Transition Phase
The purpose of the transition phase is to transition the software product to the user community. Once the product has
been given to the end user, issues usually arise that require you to develop new releases, correct some problems, or
finish the features that were postponed.
The transition phase is entered when a baseline is mature enough to be deployed in the end-user domain.
This typically requires that some usable subset of the system has been completed to an acceptable level of quality
and that user documentation is available so that the transition to the user will provide positive results for all parties.
This includes:
"beta testing" to validate the new system against user expectations
parallel operation with a legacy system that it is replacing
conversion of operational databases
training of users and maintainers
roll-out the product to the marketing, distribution, and sales teams

خلاصه منبع اصلی ترجمه شده uml در پروژه

Preliminaries
" Things had been much simpler in the past. You had been able to put something
up and get it running with just a handful of people. Today the number of people
you need quickly runs up to a hundred to develop a decent system. And even
then they don ' t normally get things right … With all those experts from all kinds
of disciplines … "
I hear such and similar talk increasingly often. As a trainer and consultant, I
meet a lot of people from most different industries. But the tone is always the
same. What ' s the reason? Very simple: progress.
We have reached a point where what ' s needed are complex and distributed
systems, but where conventional development methods are not yet ready to make
such systems available fast enough and at acceptable cost.
We cannot expect to develop increasingly progressive, larger, and better systems
while continue using the same tools. Our approach, the modeling languages
we use, and the development environments have to be part of this progress and
In software development, e.g., this evolution can be seen quite clearly.
Development tools have known increasingly larger components (from to
classes/objects) from the times we used punch cards, and then Assembler, and
then procedural programming languages, and eventually object-oriented languages,
thus facilitating the description of complex systems. The evolution to the
next generation has already begun: The graphical Unifi ed Modeling Language
( UML ) has become increasingly popular for developing software systems, and it
is being used to solve more and more tasks that had been previously done with
conventional programming languages ( Figure 1.1 ).
In systems engineering (system development) the boundaries between the different
disciplines continue to blur. Especially software is used in more and more
fi elds. These hybrid systems represent a particular challenge to the development.
We can use proven methods to effi ciently develop individual components of a
complete system. However, the complete system is more than the sum of its components.
The interplay between all the elements can be extremely complex and
hard to control.
The need for a holistic line of thinking is particularly strong in the software
development fi eld. Embedding a piece of software in a system is a critical complexity
factor. The consequence is that both approach models and notations are
required to be able to develop these systems effectively. Otherwise the development
cost will rise out of proportion compared with an acceptable price in the
near future.
Systems engineering has been dealing with this problem for quite some time.
The development of large systems in which many different disciplines participate
requires holistic lines of thinking. This means that the requirements and structures
of a system are looked at totally detached from the knowledge of specifi c details.
The entire lifecycle from the idea to the disposal is planned to develop a system
that fulfi lls the wishes of all participants.
Software development can learn a lot from systems engineering. But there
is no taking without giving. Systems engineering can also learn.

فهرست منابع و مراجع

1-نام منبع : rup چیست و مراحل ان ، برگرفته از سایت : p30world.com www. و منبع اصلی این سایت میکرو رایانه می باشد.
2.معرفی rup (چارچوپ فرایند تولید سیستم های نرم افزاری )،نویسنده : محمد بدری ، برگرفته از سایت: www.safware-acadmay (آکادمی نرم افزار)
آدرس: تهران، خ آزادی، بلوار شهید اکبری، خ شهید قاسمی، کوی تیموری، پلاک 3
3.کاربرد UML و تحلیل و طراحی شی گرا با استفاده از UML مترجم :ایمان رحیمی نیا سال انتشار 1385
4. Systems Engineering with SysML/uml
نویسنده: TIM WEILKIENSS
5. Rational unified processd for soft war development teams
برگرفته ازسایت :www.rational..com