مروري بر rup و قابليت‌هاي آن در توليد نرم‌افزار

[آبجی]

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

بدين منظور امروزه از روشي استفاده مي‌شود كه اصطلاحاً RUP ناميده مي‌شود. به حداقل رساندن حجم پروسه توليد يك نرم‌افزار همزمان با حفظ كيفيت و صرفه‌جويي در زمان از مهمترين ويژگي‌هاي اين روش مي‌باشند.

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

كليدواژه : RUP؛ UML؛ فرايند يكپارچه رشنال؛ Rational Unified Process؛ Unified Modeling Language

[آبجی]

1- مقدمه

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


منظور از rup چیست؟

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

[آبجی]

2- RUP چیست؟

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

فرایند یكپارچه Rational در اصل یك متدولوژی است كه در جهت كنترل و انجام پروژه‌های نرم‌افزاری در نظر گرفته شده است. در اصل این چارچوبی در جهت انجام صحیح و موفق پروژه‌های نرم‌افزاری می‌باشد كه كلیه مراحل انجام یك پروژه كه با معماری و آنالیز سازمان شروع شده و به تست نرم‌افزار و ارائه Gold Release ختم می‌شود را در بر می‌گیرد (گروه كاسمیك 2003 الف)


چرا RUP را یک فرایند یکپارچه می‌گویند؟

به سه علت RUP را یكپارچه می‌نامند:
• این متدولوژی از یكپارچه‌سازی سه متدولوژی معروف دیگر بوجود آمده است كه شامل Booch، OMT و OSE می‌باشد.
• از UMLدر جهت كارهای خود استفاده می‌كند. در واقع می‌توان گفت UML خود ثمره RUP می‌باشد و این خود بسیار خوب است كه متدولوژیی با خودش گسترش یابد (گروه كاسمیك 2003الف). مفاهیمی از قبیل Object، Class و ... مفاهیم ساده و ثابتی هستند ولی قبلاً متدولوژیها علامتهای خاصی داشتند كه اكنون همه آنها یكسان شده‌اند.
• در داخل RUP یك چارچوب تولید نرم‌افزار است كه ما آنرا برای سازمان و پروژه خود بومی می‌كنیم و می‌توان گفت كه در واقع یك قالب فرایند است.

[آبجی]

http://www.forum.microrayaneh.com/styles/etech/imageset/icon_topic_latest.gif (http://www.forum.microrayaneh.com/viewtopic.php?p=1414#p1414) 3- خصوصيات RUP چيست؟
 معماریRUP مبتني بر نوعي معماري است كه به اجزاء اصلي مي‌پردازد ولي طراحي به جزئيات نيز وارد مي‌شود. همچنين مي‌توان گفت معماري يكسري اجزا و ارتباط بين آنها است كه سيستم را مي‌سازد و ما را به سمت توسعه مؤلفه‌محور راهنمايي مي‌كند.

ويژگي Usecase Driven: يكي از مشكلات OOA اين بود كه مي‌گفتند با هر روشي تبديل و كار كنند و بعد بتوان آنرا به شيءگرا تبديل كرد. يعني مثلاً پروژه SSADM را طراحي كرده و بعداً به شيءگرا تبديل نمود. ولي آن عقيده اشتباه بود و حتماً تحليل شيءگرا بايد صورت بگيرد.

خصوصيت خوب شيءگرا كه در ديگر روشها نمي‌باشد اين است كه نوتاسيوني كه استفاده مي‌شود (بوچ، رامباق و جاكوبسون 1999) در همه مراحل يكي است يعني مفاهيمي از قبيل شيء، كلاس، روابط كلاسها و ... در تمامي مراحل يكي است. اهميتي كه Usecase Driven دارد اين است كه با زبان مشتري نوشته مي‌شود.

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

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

[آبجی]

4- ديدگاه اوليه درباره RUP

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

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

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

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

[آبجی]

انعطاف‌پذيري RUP و انطباق با آن

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

RUP تمرينات توليد نرم‌افزار ثابت شده فراواني را در بردارد. شركت Rational ميدان ديد بالايي را براي موارد زير، ارائه مي‌دهد:
توسعه مكرر
مدل‌سازي بصري
مديريت ملزومات تغييرات كنترل
بازبيني مداوم كيفيت
استفاده از معماري بر مبناي اجزا

همچنين URP بر مبناي ديگر اصول كليدي ديگري كه كمتر قابل مشاهده هستند و ساده‌تر به محاق فراموشي سپرده مي‌شوند، استوار شده است كه فقط براي يادآوري اشاره‌اي به آنها مي‌نماييم (جنر 2002):
منحصراً آنچه را كه مورد نياز است، پرورش دهيد.
روي نتايج ارزشمند تمركز كنيد، نه روي چگونگي حصول نتايج
كاغذبازي را به حداقل برسانيد.
انعطاف‌پذير باشيد.
از اشتباهات خود عبرت بگيريد.
به طور منظم، مخاطرات محتمل را مورد بازبيني قرار دهيد.
براي پروسه موردنظر معيارهاي قابل اندازه‌گيري و علمي را بدون موضع‌گيري شخصي استوار كنيد.
از گروه‌هاي كوچك و توانمند استفاده كنيد.
طرحي را در ذهن داشته باشيد.

ذهنيت كليدي در سازگار شدن و سازگار كردن RUP قالب توسعه8 مي‌باشد. يك قالب توسعه نمونه‌اي از RUP است كه براي پروژه ويژه‌‌اي كه مد نظرتان است، مناسب باشد. با مراجعه به ساختار RUP به توضيح پروسه‌اي دست‌ مي‌يابيد كه موارد زير را تعريف نموده و شناسايي مي‌كند (جنر 2002):
چه چيزي توسعه داده خواهد شد؟
به چه مصنوعاتي واقعاً نياز داريم؟
چه الگوهايي بايد مورد استفاده قرار بگيرند؟
كدام مصنوعات در حال حاضر وجود دارند؟
به چه نقش‌هايي نياز داريم؟
چه فعاليتهايي انجام خواهند شد؟
كدام خطوط راهنما، استانداردهاي پروژه و ابزارهايي مورد استفاده قرار خواهند گرفت؟

[آبجی]

6- نتيجه گيري

از آنچه گذشت در مي‌يابيم اولاً در حال حاضر تنها روش توسعه نرم‌افزاري که مورد پذيرش در عرصه جهاني است، rup مي‌باشد.

ثانياً اين روش علاوه بر ساماندهي به فرايند توليد نرم‌افزار از دو بعد زمان و کيفيت، به لحاظ برخورداري از انعطاف‌پذيري بالا در صورت کاربرد و پياده سازي صحيح مي‌تواند سبب تسريع فرايند توليد و توسعه نرم‌افزار و تأمين کيفيت مورد نظر در نرم‌افزار گردد

و نهايتاً اين که يکي از مهم ترين ويژگي‌هاي rup اين است که قابليت توسعه و تغيير نرم‌افزار ها را بر اساس تغيير نيازهاي کاربران و نيز تغيير فناوري، از قبل پيش بيني نموده است.