مروری بر RUP و قابلیت‌های آن در تولید نرم‌افزار

یك پروسه چابك، پروسه‌ای است كه همیشه آماده در آغوش كشیدن درخواستهای جامعه بوده و این درجه از سازگاری را دارا باشد. بنابراین منظور از سرعت عمل، فقط كاستن از حجم پروسه تولید نرم‌افزار یا سرعت ارائه آن به بازار نیست؛ بلكه منظور، انعطاف‌پذیری و حفظ کیفیت است. مطلبی كه در این مقاله قصد توضیح آن را داریم این است كه RUP ۱ ساختاری پروسه‌ای (چیو ۲۰۰۰) است كه امكان انعطاف‌پذیری را برای تولید‌كنندگان نرم‌افزار فراهم می‌آورد.
● منظور از RUP چیست؟ در این مقاله از چند منظر به RUP خواهیم پرداخت:
RUP یك پروسه تولید نرم‌افزار است.
RUP مجموعه‌ای از تجربیات بسیار عالی تولید نرم‌افزار را كه در عمل با آنها برخورد شده است، در خود دارد.
RUP همانند یك محصول نرم‌افزاری به بازار ارائه شده و به فروش می‌رسد با این تفاوت كه RUP اولین ساختار تولید نرم‌افزار را ارائه داده و گام نخست را در این زمینه برداشته است.
۲- RUP چیست؟
با پیشرفت تكنولوژی‌های مرتبط با كامپیوتر، نیاز هر چه بیشتر به گسترش علم نرم‌افزاری نیز احساس می‌شد كه با پیدایش متدولوژیهای همانند SSADM ۲ و روش آبشاری۳ (چیو ۲۰۰۰) ‎آغاز شد. در ابتدا، این روشها مناسب بود و جوابگوی نیازهای آن زمان بودند ولی با افزایش داده‌ها و پیدایش مفاهیمی همچون شبكه، وب و غیره دیگر كارآیی لازم را جهت پیاده‌سازی و هدایت پروژه‌های نرم‌افزاری نداشتند. پس مفاهیم برنامه‌نویسی شیءگرا پا به عرصه وجود گذاشتند و در سال ۱۹۹۱ بطور جدی مورد مطالعه و بحث قرار گرفتند. استفاده از این روشها و متدهای برنامه‌نویسی، قدرت و انعطاف بسیاری را به برنامه‌ها داد و شركتهای نرم‌افزاری توانستند با كاهش هزینه‌ها و بهینه‌سازی كدهای خود، نرم‌افزارهای قویتری را به بازار عرضه كنند ولی این روش جدید نیز نیاز به مدیریت و یكپارچگی داشت. پس روشها و متدولوژیهای جدیدی مطرح شد كه شامل Booch، OMT، OSE و ... می‌باشند. در سال ۲۰۰۰ شركت Rational روشی را تحت عنوان RUP مطرح ساخت (گروه كاسمیك ۲۰۰۳ب) كه بعد از روش MSF شركت مایكروسافت به دنیای نرم‌افزار عرضه شد و امروزه از طرفداران بسیاری برخوردار است. فرایند یكپارچه Rational در اصل یك متدولوژی است كه در جهت كنترل و انجام پروژه‌های نرم‌افزاری در نظر گرفته شده است. در اصل این چارچوبی در جهت انجام صحیح و موفق پروژه‌های نرم‌افزاری می‌باشد كه كلیه مراحل انجام یك پروژه كه با معماری و آنالیز سازمان شروع شده و به تست نرم‌افزار و ارائه Gold Release ختم می‌شود را در بر می‌گیرد (گروه كاسمیك ۲۰۰۳ الف).
چرا RUP را یک فرایند یکپارچه می‌گویند؟ به سه علت RUP را یكپارچه می‌نامند:
این متدولوژی از یكپارچه‌سازی سه متدولوژی معروف دیگر بوجود آمده است كه شامل Booch، OMT و OSE می‌باشد.
از UML۴ در جهت كارهای خود استفاده می‌كند. در واقع می‌توان گفت UML خود ثمره RUP می‌باشد و این خود بسیار خوب است كه متدولوژیی با خودش گسترش یابد (گروه كاسمیك ۲۰۰۳الف). مفاهیمی از قبیل Object، Class و ... مفاهیم ساده و ثابتی هستند ولی قبلاً متدولوژیها علامتهای خاصی داشتند كه اكنون همه آنها یكسان شده‌اند.
در داخل RUP یك چارچوب تولید نرم‌افزار است كه ما آنرا برای سازمان و پروژه خود بومی می‌كنیم و می‌توان گفت كه در واقع یك قالب فرایند۵ است.
۳- خصوصیات RUP چیست؟
RUP مبتنی بر نوعی معماری است كه به اجزاء اصلی می‌پردازد ولی طراحی به جزئیات نیز وارد می‌شود. همچنین می‌توان گفت معماری یكسری اجزا و ارتباط بین آنها است كه سیستم را می‌سازد و ما را به سمت توسعه مؤلفه‌محور۶ راهنمایی می‌كند.
ویژگی Usecase Driven: یكی از مشكلات OOA این بود كه می‌گفتند با هر روشی تبدیل و كار كنند و بعد بتوان آنرا به شیءگرا تبدیل كرد. یعنی مثلاً پروژه SSADM را طراحی كرده و بعداً به شیءگرا تبدیل نمود. ولی آن عقیده اشتباه بود و حتماً تحلیل شیءگرا باید صورت بگیرد. خصوصیت خوب شیءگرا كه در دیگر روشها نمی‌باشد این است كه نوتاسیونی كه استفاده می‌شود (بوچ، رامباق و جاكوبسون ۱۹۹۹) در همه مراحل یكی است یعنی مفاهیمی از قبیل شیء، كلاس، روابط كلاسها و ... در تمامی مراحل یكی است. اهمیتی كه Usecase Driven دارد این است كه با زبان مشتری نوشته می‌شود. مشتری می‌تواند آنرا بفهمد و بسیار مناسب برای تشخیص نیازمندیهای سیستم می‌باشد. در بخش تحلیل و طراحی از روی Usecaseها تحلیل و طراحی انجام می‌دهیم و مسائلی مانند مدیریت پروژه نیز تحت تاثیر Usecaseها هستند كه ما آنها را دسته‌بندی كرده و مدیریت می‌كنیم. همچنین راهنماهای سیستم هم تحت تاثیر Usecaseها (كراچتن ۲۰۰۰، ۲۹۸) ایجاد می‌شوند.
ویژگی Incremental: به معنی آن است که پروژه بصورت چهار مرحله حلقه‌ای جلو می‌رود ولی در هر مرحله چرخش یك دسته از Usecaseها كامل و آماده استفاده می‌شود و كلیه این كارها در ۹ جریان كار۷ قابل مشاهده است.
۴- دیدگاه اولیه درباره RUP
دیدگاهی كه RUP بر اساس آن طراحی شده، به گونه‌ای است كه محدوده وسیعی از اهداف را پوشش دهد تا ضمانت اجرایی جهت انطباق با موارد زیر حاصل شود (كراچتن ۲۰۰۳):
ابعاد پروژه
حوزه كاربردی برنامه (سیستمهای تجاری یا سیستمهای فنی)
زمینه‌های تجارت (توسعه خانگی، توسعه محصولات، فروشندگان نرم‌افزار مستقل، توسعه قراردادی).
همانند هر ساختار پروسه‌ دیگری، RUP نیز روش سیستماتیكی را برای به دست آوردن، سازماندهی و ارائه راهكارهای مهندسی نرم‌افزار در اختیارتان قرار می‌دهد. RUP برای سازماندهی راهكارها، بر یك مدل پروسه‌ ساده و کاملاً زیربنایی استوار شده است كه توضیح این امر در قالب چند مقاله یا كتاب نمی‌گنجد.
با این وجود، ساختار پروسه مزبور را نمی‌توان به یك ظرف خالی تشبیه نمود. این ساختار از قبل توسط حجم عظیمی از پروسه‌های راهكاری كه قبلاً در پانزده سال گذشته توسط ملیت‌های مختلف تحصیل شده است و با شركت Rational ارتباط داشته‌‌اند (افرادی كه قبلاً این شركت آنها را به خود جذب كرده و برخی از شركای این شركت نظیر IBM ، HP و BEA (كراچتن ۲۰۰۳)) انباشته گردیده‌ است. RUP مجموعه محدود و بسته‌ای نیست كه به منظور كاربردهای عمومی منتشر شده باشد و پاسخ یا راه‌حل تمامی مشكلات توسعه نرم‌افزاری را دربرگیرد؛ بلكه ساختار RUP ساختار بازی است كه به منظور استنتاج باید شاخه‌های آنرا دنبال كنید و این ساختار سالانه دوبار روزآمد می‌گردد. ساختار RUP تصفیه شده است و پشتیبانی ابزاری و مندرجات آن نیز توسعه یافته‌اند.
از یك سو، گروه توسعه پروسه شركت Rational، امر به روز سازی محتویات RUP را همگام با مقتضیات فن‌آوری و بازخوردهایی كه كاربران این ساختار ارائه می‌دهند، به عهده دارند و از سوی دیگر شركای متعدد این شركت و افرادی كه RUP را برای استحصال و سازماندهی فرایندهای راهكاری خود پذیرفته‌اند و از آن برای اهداف مربوط به خود استفاده می‌كنند، ساختار ارائه شده توسط شركت Rational را تبلیغ نموده و آنرا را تكمیل می‌كنند.
ساختار RUP پیرامون چند منطق ساده و مرتبط به هم سازمان‌دهی شده است:
RUP نقشهایی را تعریف می‌كند كه باید در پروسه وجود داشته باشد و بر مبنای آن، صلاحیتها، تخصصها و مسئولیتهای افرادی كه باید پیشرفت پروژه را محقق سازند، مشخص می‌شود.
RUP كارهایی را كه هر یك از افراد باید در عمل انجام دهند، به طور گام به گام تشریح می‌كند.
این عملیات با استفاده از ابزارهایی واقعی مانند مدل‌ها، كدها، اسناد و گزارشها اداره می‌شوند.
در RUP به وفور با راهنماییهای مربوط به نقش‌هایی كه افراد باید به عهده بگیرند، فعالیتهایی كه باید انجام شوند و مصنوعات مورد نیاز برخورد خواهید نمود كه در قالب خطوط راهنما، الگوها، مثالها و معلمهای ابزاری ارائه می‌شوند كه چگونگی به وقوع پیوستن دسته‌ای از فعالیتها توسط یك ابزار بخصوص را شرح می‌دهند.
تمامی این المانهای توصیف پروسه در قالب سامانه‌هایی سازماندهی شده‌اند.
RUP مقدماتی نه سامانه، بیش از چهل نقش و صد محصول را تعریف می‌كند و حاوی بیش از هزار صفحه راهنما است. همچنین می‌توانید به پروسه‌های الحاقی متعددی كه وظایف و مندرجات بیشتری را به RUP اضافه می‌كند، دسترسی پیدا كنید. برخی از منتقدین RUP آنرا پروسه‌ای بسیار سنگین تصور نموده و آنرا به كرگدنی تشبیه می‌كنند كه توان انجام تعداد نامحدودی عمل غیر معمول را برای شما فراهم می‌آورد؛ با این وجود نگاه ما به RUP همانند لوح باشكوهی از معارف است كه می‌توانید آنچه را كه نیاز دارید، از داخل آن برگزینید.
اجازه بدهید مقایسه‌ای انجام دهیم. اگر فرهنگ لغات مناسبی از ۸۰۰ لغت را انتخاب كرده باشید، می‌توانید در خیلی از نقاط دنیا و در بسیاری شرایط، گلیم خود را از آب بیرون بكشید؛ ولی با انتخاب فرهنگ لغات حجیمی چون Webster ، اولاً هیچ‌كس شما را مجبور به استفاده از لغاتی كه در فرهنگ لغات وجود دارد نمی‌كند، ثانیاً می‌توانید سطح لغات محفوظی خود را برای انطباق با وضعیتهای مختلف ارتقا ببخشید و ثالثاً می‌توانید فرهنگ لغات خود را بهبود دهید. فرهنگ لغت۸۰۰ لغتی باید فقط زیرمجموعه‌ای از یك فرهنگ لغات باشد.
۵- انعطاف‌پذیری RUP و انطباق با آن
RUP یك اصل عقیدتی یا یك آیین مذهبی نیست. ساختار RUP ساختار خشكی نیست كه بخواهد همه چیز را برای تولید نرم‌افزار در قالب خود درآورد. نیازی نیست كه حداقل چهل نفر را برای تكمیل پروسه‌ای كه چهل نقش در آن تعریف شده است، به خدمت بگیرید و نیازی ندارید كه بیش از صد محصول مختلف را پرورش دهید. اگر سعی خود را به انجام این كار معطوف سازید، خیلی زود در معرض آشفتگی قرار خواهید گرفت. این المانها در RUP و در فرم الكترونیكی (كراچتن ۲۰۰۳) برای فراهم‌آوردن انعطاف‌پذیری مورد نیاز برای انطباق با تقاضایی ارائه شده‌اند كه به شرایط محیطی كه درآن به سر می‌برید، بستگی دارد.
RUP تمرینات تولید نرم‌افزار ثابت شده فراوانی را در بردارد. شركت Rational میدان دید بالایی را برای موارد زیر، ارائه می‌دهد:
توسعه مكرر
مدل‌سازی بصری
مدیریت ملزومات تغییرات كنترل
بازبینی مداوم كیفیت
استفاده از معماری بر مبنای اجزا
همچنین URP بر مبنای دیگر اصول كلیدی دیگری كه كمتر قابل مشاهده هستند و ساده‌تر به محاق فراموشی سپرده می‌شوند، استوار شده است كه فقط برای یادآوری اشاره‌ای به آنها می‌نماییم (جنر ۲۰۰۲):
منحصراً آنچه را كه مورد نیاز است، پرورش دهید.
روی نتایج ارزشمند تمركز كنید، نه روی چگونگی حصول نتایج
كاغذبازی را به حداقل برسانید.
انعطاف‌پذیر باشید.
از اشتباهات خود عبرت بگیرید.
به طور منظم، مخاطرات محتمل را مورد بازبینی قرار دهید.
برای پروسه موردنظر معیارهای قابل اندازه‌گیری و علمی را بدون موضع‌گیری شخصی استوار كنید.
از گروه‌های كوچك و توانمند استفاده كنید.
طرحی را در ذهن داشته باشید.
ذهنیت كلیدی در سازگار شدن و سازگار كردن RUP قالب توسعه۸ می‌باشد. یك قالب توسعه نمونه‌ای از RUP است كه برای پروژه ویژه‌‌ای كه مد نظرتان است، مناسب باشد. با مراجعه به ساختار RUP به توضیح پروسه‌ای دست‌ می‌یابید كه موارد زیر را تعریف نموده و شناسایی می‌كند (جنر ۲۰۰۲):
چه چیزی توسعه داده خواهد شد؟
به چه مصنوعاتی واقعاً نیاز داریم؟
چه الگوهایی باید مورد استفاده قرار بگیرند؟
كدام مصنوعات در حال حاضر وجود دارند؟
به چه نقش‌هایی نیاز داریم؟
چه فعالیتهایی انجام خواهند شد؟
كدام خطوط راهنما، استانداردهای پروژه و ابزارهایی مورد استفاده قرار خواهند گرفت؟
۶- نتیجه گیری
از آنچه گذشت در می‌یابیم اولاً در حال حاضر تنها روش توسعه نرم‌افزاری که مورد پذیرش در عرصه جهانی است، RUP می‌باشد. ثانیاً این روش علاوه بر ساماندهی به فرایند تولید نرم‌افزار از دو بعد زمان و کیفیت، به لحاظ برخورداری از انعطاف‌پذیری بالا در صورت کاربرد و پیاده سازی صحیح می‌تواند سبب تسریع فرایند تولید و توسعه نرم‌افزار و تأمین کیفیت مورد نظر در نرم‌افزار گردد و نهایتاً این که یکی از مهم ترین ویژگی‌های RUP این است که قابلیت توسعه و تغییر نرم‌افزار ها را بر اساس تغییر نیازهای کاربران و نیز تغییر فناوری، از قبل پیش بینی نموده است.

نویسنده: سید علیرضا حجازی
پی‌نوشت‌ها
۱. Rational Unified Process
۲. Structured System Analysis and Design Method
۳. waterfall
۴. Unified Modeling Language
۵. Process Framework
۶. Component Base Development (CBD)
۷. workflow
۸. Development case
مراجع
Booch, G., J. Rumbaugh and I. Jacobson. ۱۹۹۹. The Unified Modeling Language User Guide. Addison- Wesley.
COSMIC Group. ۲۰۰۳a. Valve Control System – Cosmic Group Case Study. École de technologie supérieure, Université du Québec, Montréal, Canada, January ۲۵, ۲۰۰۳ version http://www.lrgl.uqam.ca/cosmic-ffp/casestudies/
COSMIC Group. ۲۰۰۳b. Rice Cooker – Cosmic Group Case Study. École de technologie supérieure, Université du Québec, Montréal, Canada, Janua ry ۲۶, ۲۰۰۳ version http://www.lrgl.uqam.ca/cosmic-ffp/casestudies/
Jenner, M. ۲۰۰۲. Automation of Counting of Functional Size Using COSMIC-FFP in UML. ۱۲th International Workshop on Software Measurement – IWSM ۲۰۰۲, Magdeburg, Germany, Oct. ۷-۹, ۴۳-۵۱.
Kruchten, P. ۲۰۰۰. The Rational Unified Process, an introduction. Addison Wesley.
Kruchten, P. ۲۰۰۳. The RUP platform. Montréal-SPIN . November, ۳۳.
Schewe, K.D. ۲۰۰۰. UML: A Modern Dinosaur? A Critical Analysis of the Unified Modeling Language. Proc. ۱۰th European-Japanese Conf. on Information Modeling and Knowledge Bases. Saariselk/Finland.

منبع : راهکار مدیریت