دانلود مقاله RUP

بخشی از مقاله

چكيده
چه چيز مي‌تواند يك پروسه توليد نرم‌افزار را توصيف كند؟ آيا منظور از پروسه، آماده‌سازي نرم‌افزار صرفاً براي ارائه در بازار است؟ مسلماً در هر كاري وجود يك سامانه و فرايند كاري ضروري است؛ ولي چه چيزي مي‌تواند موجب ايجاد سرعت و كيفيت در فرايند توليد يك نرم‌افزارشود؟ لزوماً طراحي و پياده‌سازي يك فرايند يكپارچه و منطقي مي‌تواند چنين نتيجه‌اي در بر داشته باشد. بدين منظور امروزه از روشي استفاده مي‌شود كه اصطلاحاً RUP ناميده مي‌شود. به حداقل رساندن حجم پروسه توليد يك نرم‌افزار همزمان با حفظ كيفيت و صرفه‌جويي در

زمان از مهمترين ويژگي‌هاي اين روش مي‌باشند. معمولاً براي يك شركت توليد نرم‌افزار، سرعت عمل به موقع براي پاسخ‌گويي به تقاضا و شرايط اجتماعي اهميت دارد، اما گاهي اين شتابزدگي سبب فدا شدن كيفيت مي‌گردد. RUP با ارائه يك چارچوب منطقي علاوه بر تعيين زمانبندي مناسب، كيفيت مورد نظر توليد كننده و استفاده كننده نرم‌افزار را تأمين مي‌نمايد. در اين مقاله ضمن مروري بر RUP به عنوان روش يكپارچه توليد نرم‌افزار، قابليت‌هاي آن در افزايش سرعت توليد نرم‌افزار و حفظ كيفيت آن برشمرده مي‌شوند.
كليدواژه : RUP؛ UML؛ فرايند يكپارچه رشنال؛ Rational Unified Process؛ Unified Modeling Language

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

 RUP يك پروسه توليد نرم‌افزار است.
 RUP مجموعه‌اي از تجربيات بسيار عالي توليد نرم‌افزار را كه در عمل با آنها برخورد شده است، در خود دارد.
 RUP همانند يك محصول نرم‌افزاري به بازار ارائه شده و به فروش مي‌رسد با اين تفاوت كه RUP اولين ساختار توليد نرم‌افزار را ارائه داده و گام نخست را در اين زمينه برداشته است.
RUP چيست؟
با پيشرفت تكنولوژي‌هاي مرتبط با كامپيوتر، نياز هر چه بيشتر به گسترش علم نرم‌افزاري نيز احساس مي‌شد كه با پيدايش متدولوژيهاي همانند SSADM 2 و روش آبشاري3 (چيو 2000) ‎آغاز شد. در ابتدا، اين روشها مناسب بود و جوابگوي نيازهاي آن زمان بودند ولي با افزايش داده‌ها و پيدايش مفاهيمي همچون شبكه، وب و غيره ديگر كارآيي لازم را جهت پياده‌سازي و هدايت پروژه‌هاي نرم‌افزاري نداشتند. پس مفاهيم برنامه‌نويسي شيءگرا پا به عرصه وجود گذاشتند و در سال 1991 بطور جدي مورد مطالعه و بحث قرار گرفتند. استفاده از اين روشها و متدهاي برنامه‌نويسي، قدرت و انعطاف بسياري را به برنامه‌ها داد و شركتهاي نرم‌افزاري توانستند با كاهش هزينه‌ها و بهينه‌سازي كدهاي خود، نرم‌افزارهاي قويتري را به بازار عرضه كنند ولي اين روش جديد نيز نياز به مديريت و يكپارچگي داشت. پس روشها و متدولوژيهاي جديدي مطرح شد كه شامل Booch، OMT، OSE و ... مي‌باشند. در سال 2000 شركت Rational روشي را تحت عنوان RUP مطرح ساخت (گروه كاسميك 2003ب) كه بعد از روش MSF شركت مايكروسافت به دنياي نرم‌افزار عرضه شد و امروزه از طرفداران بسياري برخوردار است. فرايند يكپارچه Rational در اصل يك متدولوژي است كه در جهت كنترل و انجام پروژه‌هاي نرم‌افزاري در نظر گرفته شده است. در اصل اين چارچوبي در جهت انجام صحيح و موفق پروژه‌هاي نرم‌افزاري مي‌باشد كه كليه مراحل انجام يك پروژه كه با معماري و آناليز سازمان شروع شده و به تست نرم‌افزار و ارائه Gold Release ختم مي‌شود را در بر مي‌گيرد (گروه كاسميك 2003 الف).
چرا RUP را يک فرايند يکپارچه مي‌گويند؟ به سه علت RUP را يكپارچه مي‌نامند:

 اين متدولوژي از يكپارچه‌سازي سه متدولوژي معروف ديگر بوجود آمده است كه شامل Booch، OMT و OSE مي‌باشد.

 از UML4 در جهت كارهاي خود استفاده مي‌كند. در واقع مي‌توان گفت UML خود ثمره RUP مي‌باشد و اين خود بسيار خوب است كه متدولوژيي با خودش گسترش يابد (گروه كاسميك 2003الف). مفاهيمي از قبيل Object، Class و ... مفاهيم ساده و ثابتي هستند ولي قبلاً متدولوژيها علامتهاي خاصي داشتند كه اكنون همه آنها يكسان شده‌اند.
 در داخل RUP يك چارچوب توليد نرم‌افزار است كه ما آنرا براي سازمان و پروژه خود بومي مي‌كنيم و مي‌توان گفت كه در واقع يك قالب فرايند5 است.
Rup شامل 4 فاز مي‌باشد و اگر در هر لحظه به آن نگاه كنيم شامل 9 قالب خواهد بود.

اين فرآيند يک روش نظام‌مند براي تخصيص کارها و مسئوليتها در يک تيم توسعه نرم‌افزار ارائه مي‌دهد و هدف آن توليد نرم‌افزار بصورت بهينه و با کيفيت بالاست که بتواند نيازهاي کارفرما را تحت يک برنامه زماني مشخص و با بودجه قابل پيش‌بيني برآورده سازد. آر.يو.پي بهره‌وري تيم توليد نرم‌افزار را با فراهم نمودن دسترسي تمام افراد تيم به يک پايگاه دانش سهل‌الوصول به همراه راهنماها، الگوها و ابزارهاي کمکي براي همه فعاليت‌هاي حياتي توسعه، افزايش مي‌دهد. از آنجا که تمام افراد به منابع يکساني دسترسي دارند، لذا ديد مشترکي براي توسعه نرم‌افزار برخوردار هستند.

آر.يو.پي امکان استفاده موثرتري از زبان يکپارچه مدلسازي (UML) را فراهم مي‌سازد (دقت شود که در عين حال آر.يو.پي و يو.ام.ال کاملاً مستقل از يکديگر هستند و نبايد آنها را با هم يکي فرض کنيم). به کمک تکنيک هاي آر.يو.پي بخش‌هاي عمده‌اي از فرآيند توليد نرم‌افزار به طور خودکار انجام شده و همچنين استفاده از مدل‌هاي توليد شده در فرآيندهاي گذشته در پروژه‌هاي جاري به سادگي امکان‌پذير است. اين فرآيند با موقعيت‌هاي مختلف تطبيق يافته و براي سازمانهاي بزرگ يا حتي کوچک توليد و توسعه نرم‌افزار قابل استفاده است.
آر.يو.پي کليه مراحل انجام يک پروژه شامل تحليل سيستم، برنامه‌ريزي، بررسي ريسکها، توليد و تست نرم‌افزار را در بر مي‌گيرد و چهارچوبي در جهت انجام صحيح و موفق پروژه‌هاي نرم افزاري فراهم مي‌سازد.

چرا آر.يو.پي را يکپارچه ناميده‌اند:
1. اين فرآيند از ترکيب و يکپارچه‌سازي چند فرآيند و متدولوژي شامل Booch، OMT و OSE ديگر ايجاد شده است.
2. از زبان يکپارچه مدلسازي (UML) به طور موثري بهره مي‌گيرد.
3. مفاهيمي نظير کلاس و شيء در متدهاي قبلي علائم خاص و مختلفي داشته‌اند حال آنکه در آر.يو.پي يکسان شده‌اند.

حرفه ها وتخصص ها
به منظور بررسي(شناخت،آناليز، نياز سنجي،طراحي، پياده سازي و...)فرايندهاي يک سازمان يا يک تيم کاري حرفه ها و تخصص هاي مختلفي بکار ميروند که در بکار گيري آنها عوامل زير مؤثر مي باشد:
ـ تنوع حوزه کاري سازمان يا تيم کاري

هر چه حوزه فعاليت هاي مورد بررسي وسيعتر باشد ونوع کارها متفاوت تر باشد تخصص هاي بررسي کننده نياز بايستي متنوع تر باشند.از طرفيتخصص ها و دانشهايي که در مورد کليت فعاليت ها و پروسه ها اظهار نظر مي نمايد نيز وابسته به تنوع حوزه فعاليت پروسه هاي مورد مطالعه مي باشند.از نظر تعداد اعضا شرکت کننده در تيم امکان سنجي،نياز سنجي،طراحي،پياده سازي نيز بستگي به تنوع حوزه کاري مورد مطالعه دارد.
ـميزان شناخت و متعاقب آن تغييرات مورد انتظار در سيستم

سازمان ها و تيم هاي کاري با اهداف مختلفي به مطالعه وامکان سنجي پروسه هاي خود مي پردازند عمده اين اهداف عبارتند از:
*شناخت ساختار و مدل ايستاي سازمان يا تيم کاري مو جود يا در حال شکل گيري.
*شناخت(ايجاد شناسنامه) پروسه هاي موجود/در حال شکل گيري/امکان کشف در سازمان يا تيم کاري.
*شناخت روشها و متد هاي مديريت پروژه بهينه.

*شناخت مستندات جاري يا در حال شکل گيري سازمان يا تيم کاري ودر نهايت بززسي گردش اسناد.
*شناخت گردش کار پروسه هاي موجود(DFD)
*شناخت موجوديت هاي سيستم و رسيدن به ERD متناسب با ساختار سيستم.
*شناخت مدل کامل سيستم که بيانگر وضعيت جاري/مناسب/مورد نظر باشد.

*زسيدن به مدلي که در طراحي سيستم کارا/قابل اطمينان/معقول و مقرون/ راحت و متناسب(اصول مهندسي نرم افزار) مؤثر باشد.
*رسيدن به مدلي که در پياده سازي سيستم کارا/ قابل اطمينان/معقول و مقرون/ راحت و متناسب(اصول مهندسي نرم افزار) مؤثر باشد.
با توجه به اهداف نوع تخصص و سطح خروجي تخصص که همان پيشنهاد هاي مؤثر براي ابقا/ تغيير/ايجاد سيستم جايگزين براي سيستم جاري مي باشد، مشخص مي گردد.مي توان گفت خروجي تخصص مي تواند يکي از موارد زير باشد:

_ مستندات واقعي/ استاندارد/ بهينه سيستم موجود يا در حال شکل گيري
_ ابزار هاي کمکي مؤثر در بهبود/ ايجاد سيستم موجود يا در حال شکل گيري
_ سيستم کاملاً جديد که در حوزه موضوع مورد نظر ايفاي نقش خواهد کرد
_ پيشنهادات دستورالعملي ، سازماني،آيين نامه اي و... براي سيستم موجود يا در حال شکل گيري
در انتخاب نوع خروجي بايد موارد پيشنهادي را بر اساس( شاخص گذاري/ در نظر داشتن)موارد زير ارائه کرد:

_ فرهنگ کاري و مسائل محيطي
_ ميزان هزينه و منابع مورد نياز ديگر مانند زمان
_ ميزان انعطاف پذيري و علاقه مندي به تغيير

و.......
- سطح فن آوري و تکنيکي بکار رفته در شناخت و تغيير
در فاز امکان سنجي و کشف نيازمند يها وآناليز:
OOPيا SSADM ؟
در فازطراحي سيستم جديد:

Tier3 يا؟
در فاز پياده سازي و گذار به سيستم جديد:
Desktop يا Client/Server يا Web Base يا توزيعي؟چند کاره ؟ در چه محدوده هايي؟ با چه امنيتو سطح دسترسي؟

خصوصيات RUP چيست؟
 RUP مبتني بر نوعي معماري است كه به اجزاء اصلي مي‌پردازد ولي طراحي به جزئيات نيز وارد مي‌شود. همچنين مي‌توان گفت معماري يكسري اجزا و ارتباط بين آنها است كه سيستم را مي‌سازد و ما را به سمت توسعه مؤلفه‌محور6 راهنمايي مي‌كند.
 ويژگي Usecase Driven: يكي از مشكلات OOA اين بود كه مي‌گفتند با هر روشي تبديل و كار كنند و بعد بتوان آنرا به شيءگرا تبديل كرد. يعني مثلاً پروژه SSADM را طراحي كرده و بعداً به شيءگرا تبديل نمود. ولي آن عقيده اشتباه بود و حتماً تحليل شيءگرا بايد صورت بگيرد. خصوصيت خوب شيءگرا كه در ديگر روشها نمي‌باشد اين است كه نوتاسيوني كه استفاده مي‌شود (بوچ، رامباق و جاكوبسون 1999) در همه مراحل يكي است يعني مفاهيمي از قبيل شيء، كلاس، روابط كلاسها و ... در تمامي مراحل يكي است. اهميتي كه

Usecase Driven دارد اين است كه با زبان مشتري نوشته مي‌شود. مشتري مي‌تواند آنرا بفهمد و بسيار مناسب براي تشخيص نيازمنديهاي سيستم مي‌باشد. در بخش تحليل و طراحي از روي Usecaseها تحليل و طراحي انجام مي‌دهيم و مسائلي مانند مديريت پروژه نيز تحت تاثير Usecaseها هستند كه ما آنها را دسته‌بندي كرده و مديريت مي‌كنيم. همچنين راهنماهاي سيستم هم تحت تاثير Usecaseها (كراچتن 2000، 298) ايجاد مي‌شوند.

 ويژگي Incremental: به معني آن است که پروژه بصورت چهار مرحله حلقه‌اي جلو مي‌رود ولي در هر مرحله چرخش يك دسته از Usecaseها كامل و آماده استفاده مي‌شود و كليه اين كارها در 9 جريان كار7 كه در شكل 1 مشخص شده بود، قابل مشاهده است.

ديدگاه اوليه درباره RUP
ديدگاهي كه RUP بر اساس آن طراحي شده، به گونه‌اي است كه محدوده وسيعي از اهداف را پوشش دهد تا ضمانت اجرايي جهت انطباق با موارد زير حاصل شود (كراچتن 2003):
 ابعاد پروژه

 حوزه كاربردي برنامه (سيستمهاي تجاري يا سيستمهاي فني)
 زمينه‌هاي تجارت (توسعه خانگي، توسعه محصولات، فروشندگان نرم‌افزار مستقل، توسعه قراردادي).
همانند هر ساختار پروسه‌ ديگري، RUP نيز روش سيستماتيكي را براي به دست آوردن، سازماندهي و ارائه راهكارهاي مهندسي نرم‌افزار در اختيارتان قرار مي‌دهد. RUP براي سازماندهي راهكارها، بر يك مدل پروسه‌ ساده و کاملاً زيربنايي استوار شده است كه توضيح اين امر در قالب چند مقاله يا كتاب نمي‌گنجد.

با اين وجود، ساختار پروسه مزبور را نمي‌توان به يك ظرف خالي تشبيه نمود. اين ساختار از قبل توسط حجم عظيمي از پروسه‌هاي راهكاري كه قبلاً در پانزده سال گذشته توسط مليت‌هاي مختلف تحصيل شده است و با شركت Rational ارتباط داشته‌‌اند (افرادي كه قبلاً اين شركت آنها را به خود جذب كرده و برخي از شركاي اين شركت نظير IBM ، HP و BEA (كراچتن 2003)) انباشته گرديده‌ است. RUP مجموعه محدود و بسته‌اي نيست كه به منظور كاربردهاي عمومي منتشر شده باشد و پاسخ يا راه‌حل تمامي مشكلات توسعه نرم‌افزاري را دربرگيرد؛ بلكه ساختار RUP ساختار بازي است كه به منظور استنتاج بايد شاخه‌هاي آنرا دنبال كنيد و اين ساختار سالانه دوبار روزآمد مي‌گردد. ساختار RUP تصفيه شده است و پشتيباني ابزاري و مندرجات آن نيز توسعه يافته‌اند.

از يك سو، گروه توسعه پروسه شركت Rational، امر به روز سازي محتويات RUP را همگام با مقتضيات فن‌آوري و بازخوردهايي كه كاربران اين ساختار ارائه مي‌دهند، به عهده دارند و از سوي ديگر شركاي متعدد اين شركت و افرادي كه RUP را براي استحصال و سازماندهي فرايندهاي راهكاري خود پذيرفته‌اند و از آن براي اهداف مربوط به خود استفاده مي‌كنند، ساختار ارائه شده توسط شركت Rational را تبليغ نموده و آنرا را تكميل مي‌كنند.
ساختار RUP پيرامون چند منطق ساده و مرتبط به هم سازمان‌دهي شده است:
 RUP نقشهايي را تعريف مي‌كند كه بايد در پروسه وجود داشته باشد و بر مبناي آن، صلاحيتها، تخصصها و مسئوليتهاي افرادي كه بايد پيشرفت پروژه را محقق سازند، مشخص مي‌شود.
 RUP كارهايي را كه هر يك از افراد بايد در عمل انجام دهند، به طور گام به گام تشريح مي‌كند.