ده مورد اساسی RUP در مهندسی نرم افزار  

ده مورد اساسی RUP عبارت اند از:

1.تصویر کلی

تصویر کلی ، عصاره ای از جریان کار نیازمندی ها در rup ، بدست می دهد.

2.طرح تولید نرم افزار

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

3.ریسک

لیست ریسک ، به منظور در نظر گرفتن ریسک های شناخته شده در راه موفقیت پروژه است.

4.موارد مهم

شناسایی و ارزیابی موارد مهم باید در تاریخ های معین انجام شود. این گزارشات نبض مدیریت است.

5.مورد کسب وکار

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

6.معماری

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

7.محصول

 جریان کارهای پیاده سازی ، تست ، کد نویسی ، ساخت و تست گام به گام مولفه های سیستم ، با نشر های قابل اجرا در پایان هر تکرار بعد از فاز اول ، است.

8.ارزیابی

- ارزیابی تکرار ، نتایج یک تکرار ، میزان برآورده شدن معیار ارزیابی ، دروس آموخته شده و تغییرات فرایند که باید پیاده سازی شوند ، را در بر می گیرد.

- هرچه زودتر از کار عقب بمانید ، زمان بیشتری را باید جبران کنید.

9.درخواست تغییر

-مدیریت و کنترل محدوده پروژه در هنگامی که تغییرات در طول چرخه حیات پروژه رخ می دهد ، شناسایی اثرات تغییرات و ارایه پیشنهادات.

10.حمایت از کاربر

-عصاره جریان کارهای استقرار ، بسته بندی و تحویل محصول است بعلاوه یک راهنمای کاربر و استفاده از ابزار آموزشی است.

اصول اساسی RUP در مهندسی نرم افزار چیست؟

اصول اساسی RUP عبارت اند از:

حمله سریع و مداوم به ریسک های اصلی.

تضمین کنید که محصول با ارزشی به مشتری می دهید. (تضمین محصول با ارزش)

روی نرم افزار قابل اجرا متمرکز کنید. (می تواند نرم افزاری برای تغییر سازمان باشد ولی باید قابل تکرار باشد.)

تغییرات را هرچه زودتر در پروژه بگنجانید. (گنجاندن هر چه زودتر تغییرات در پروژه)

هرچه سریع تر معماری قابل اجرایی را مبنا قرار دهید.

سیستم را با مؤلفه ها بنا کنید. (ساختن با مولفه ها)

در قالب یک تیم با هم کار کنید. (کار تیمی)

کیفیت را به عنوان یک اصل قرار دهید نه یک فرع. (کیفیت)

متدولوژی Rup چیست؟

متدولوژی (Rup (Rational Unified Process یک فرآیند تولید و توسعه نرم افزاری می باشد که در سال 2000 این متدولوژی توسط شرکت Rational  ارائه گردید .مهم ترین هدف Rup اطمینان از تولید نرم افزار با کیفیت بالا می باشد. 

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



تولید یک محصول نرم افزاری در Rup شامل چهار فاز آغازین (Inception ) ، جزئیات (Elaboration ) ، ساخت (Construction )  و انتقال (Transition ) می باشد . میزان استفاده از نیروی انسانی و زمان صرف شده در هر فاز متفاوت است همان گونه که در شکل زیر مشاهده می کنید  فاز ساخت بیشترین زمان و نیروی انسانی را نیاز دارد.

  
در Rup در ابتدای پروژه یک معماری اولیه تهیه می گردد این امر باعث به حداقل رسیدن ریسک های پروژه در ابتدای کار شده و کیفیت نرم افزار تولیدی را بالا می برد. از دیگر ویژگی های Rup قابلیت توسعه و تغییر نرم افزار براساس سلیقه و نیازهای کاربران و مشتریان می باشد. 

یک فرآیند در Rup  دارای عناصر اصلی زیر می باشد:

نقشها(Roles ):
  رفتارها و مسئوليتهايي هستند كه توسط يك فرد يا افرادی از يك تيم در پروژه انجام می شوند از جمله نقش های موجود در یک  پروژه  می توان به تحلیلگر سیستم ، معمار ، مشتری و کاربر نهایی اشاره کرد. 

فعاليتها(Activities ): كارهايي كه يك نقش در طول پروژه انجام می دهد را فعالیت می گویند . هر فعالیت دارای هدف مشخصی می باشد و تنها به یک نقش منصوب می شود. فعاليتها ممكن است چندين بار در تكرارهاي مختلف پروژه انجام شوند . 

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

به طور کلی روند تولید و توسعه  یک نرم افزار با استفاده از متدولوژی Rup در 2 بعد صورت می پذیرد : 

1.بعد افقی یا بعد زمانی فرآیند که شامل فازهای Rup می باشد.در شکل زیر بعد افقی همان محور افقی است که بیانگر ساختار داینامیک فرآیند می باشد . 
2.بعد عمودی یامحورعمودی، ساختار استاتیک فرآیند را نمایش می دهد که شامل 9  دیسیپلین )مدل سازي کسب و کار، نيازمنديها ، تحليل و طراحي ، پياده سازي ، تست ، استقرار، مديريت پيكر بندي ،مديريت پروژه و محيط) می باشد.

همان گونه که در شکل مشاهده می کنید با گذشت  زمان و در هر فاز دیسیپلین های  خاصی اجرا می گردد و میزان استفاده از دیسیپلین ها بسته به نوع فازها متفاوت است. مثلا در فاز آغازین کاربرد دیسپلین استقرارِ(Deployment) صفر می باشد اما در فازهای ساخت و انتقال که پروسه تولید نرم افزار به اتمام رسیده است کاربرد این دیسپلین بسیار بالاست .
  

  
فازهای یك پروژه در RUP 

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

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

فاز جزئیات (Elaboration ) : 
تحليل و بررسی دامنه پروژه و  بدست آوردن یک معماري مناسب براي سيستم در این فاز صورت گرفته و توسعه پروژه و پیشگیری از ریسک های مهم سيستم از اهداف اصلی این فاز می باشد.

فاز ساخت (Construction ) : 
فاز ساخت، عبارتست ازفرآيند توليد صنعتي كه در آن روي مديريت منابع، کنترل عملیات، به حداقل رساندن هزينه‌ها و بدست آوردن یک کیفیت عالی در کوتاه ترین زمان تاكيد مي شود و به تکمیل تولید سیستم بر اساس معماری اولیه می پردازد. این فاز با استقرار یک نسخه کارکردی کامل از سیستم ، شامل نصب مستندات پشتیبانی و ابزارهای آموزشی خاتمه می یابد.

فاز انتقال (Transition ) : 

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

دیسیپلین هاي Rup 
دیسیپلین ها کارهای به هم مرتبطی هستند که برای به نتیجه رسیدن هدف خاصی از یک پروژه انجام می شوند. در هر دیسیپلین یک گردش کار  وجود دارد. متدلوژی Rup از 6 دیسیپلین اصلی که مربوط به تولید محصول و 3 دیسیپلین  پشتیبانی و مدیریت که مربوط به تیم و محیط تولید می باشد تشکیل شده است .

دیسیپلین های اصلی (مربوط به تولید محصول)

مدل سازی کسب و کار (Business Modeling ) :

اهداف اصلی این دیسپلین شناخت ساختار سازمان مورد نظر برای تولید و ارائه سیستم به آن سازمان ، بررسی مشکلات موجود و ارائه راه حل برای رفع مشکلات موجود می باشد و هم چنین با ارائه یک مدل Use-Case کسب وکار به تعریف فرآیندها ، نقش ها و مسئولیت های آن سازمان می پردازد.

نیازمندی ها (Requirements ) :
این دیسیپلین به بررسی نیازمندیهای سیستم براساس توافقات انجام شده با مشتری پرداخته و به تعیین حد و حدود سیستم و تخمین هزینه ها و زمان می پردازد.

تحلیل و طراحی (Analysis and Design ) :
تبدیل نیازمندیهای سیستم به طراحی به طوری که طراحی مورد نظر با محیط پیاده سازی هماهنگ باشد و هم چنین ایجاد یک معماری مستحکم از مهم ترین اهداف این دیسپلین می باشد.

پیاده سازی (Implementation ) :
پیاده سازی طراحی سیستم و تولید یک محصول نرم افزای در این مرحله صورت می پذیرد.

تست (Test ) :
تست محصول و بررسی کیفیت و نقایص محصول، بررسی هماهنگ بودن محصول پیاده سازی شده بر اساس طرح  از اهداف اصلی دیسیپلین تست می باشد.

استقرار (Deployment ) :

نصب محصول و آماده کردن محصول برای ارائه و هم چنین امکان استفاده از محصول برای کاربران نهایی در این دیسیپلین انجام می شود.


دیسیپلین های پشتیبانی و مدیریت  (مربوط به تیم و محیط تولید)

مدیریت پروژه (Project Management ) : 

مدیریت پروژه ، مدیریت ریسک ها و از بین بردن محدودیت ها برای ارائه محصولی موفقیت آمیز از اهداف اصلی این دیسپلین می باشد.

مدیریت تغییرات و پیکربندی (Configuration & Change Management ) :
پیکر بندی و اعمال تغییرات لازم با حفظ صحت خروجی های پروژه در این بخش صورت می پذیرد.

مدیریت محیط(Environment ) :
فراهم کردن محیط تولید و ابزارهایی که در جهت پشتیبانی تیم تولید است مانند ایجاد سایت برای سازمان هدف در این بخش صورت می پذیرد .

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

RUP بهتر است يا Agile؟

واقعيت امر اين است که فرآيندها و متدولوژی‌های توليد نرم‌افزار هر يک دارای نکات مثبت و منفی خاص خود هستند و هر کدام با شرايطی، می‌توانند تجارب ديگران به ما منتقل نمايند تا ما چرخ را دوباره اختراع نکنيم و از ياد نبريم که نبايد مسخ آنها شويم و خلاقيتمان را ناديده گرفته و خودباوری‌مان را از دست بدهيم. اما مشکل عمده ما در ايران اين است که خيلی مدگرا هستيم و دانسته‌های ما "ناشی از شنيده‌ها و برداشتهای شخصی است"[اين جمله مال من نيست] و نه بر اساس تجربه و مطالعه. 
من در معرفی يکی از دوره‌هايم متنی را آماده کردم که فکر کنم بد نباشد آن را اينجا بياورم:

 

"در جامعه نرم‌افزاری، هر از چند گاهی، تکنولوژی يا روشی مد روز می‌شود و اين جامعة ذاتاً نوگرا را چون جاذبه‌های عجيب به سمت خود می­کشاند، بدون آن که لزوم استفاده و  مفاهيم بنيادی آن به اين جامعه منتقل گردد، مدتی به کار گرفته می­شود و پس از مدتی به دلايل مختلف از مد خارج شده و با مدی ديگر چايگزين می­گردد. يکی از مهم‌ترين دلايلی که باعث از مد خارج شدن اين ابزارها می‌گردد، برداشت نادرستی است که علاقمندان و استفاده‌کنندگان از آنها دارند و دليل ديگر، کاربری نادرست آنها در کنار بی‌تجربگی استفاده‌کنندگان و مهم­تر از همه عدم وجود توانمندی لازم جهت ساده‌سازی و بومی‌سازی آنها می‌باشد. 
RUP نيز از اين قاعده مستثنی نيست. فرآيند توليد يکپارچه شرکت IBM به دلايل مختلفی در جامعه نرم‌افزاری مد شد و به دلايلی که بخشی از آن را برشمرديم، از مد روز خارج شد، بدون آن که فلسفه و نگرش اين فرآيند به کاربران آن منتقل شود.

هدف اين نيست که از اين فرآيند دفاع نماييم و آن را معجزه قرن بيست و يکم بناميم، بلکه نکته‌ای که بدان پافشاری می‌نماييم اين است که فلسفه و نگرش درون RUP نشأت گرفته از تمامی روشهايی بوده است که تا آن زمان ظهور کرده­اند و هر يک به طريقی سعی در حل مشکلات توليد نرم­افزار داشته­اند. فارغ از اين که اين نام چه باشد – FDD،RUP، ICONIX، Agile، XP – آن چه که جامعه نرم­افزاری بايد فرابگيرد، فلسفه و نگرش و تکنيکهايی است که در اين روشها به صورت ضمنی وجود دارد."

به عنوان مثال مفهوم معماری. در روشهای مدرن، معماری به عنوان يکی از مبانی اصلی شمرده می‌شود (the architecture is first). با اين که همه در کوی و برزن اين نام را بر سر زبان می‌آورند، واقعاً به اندازه انگشتان يک دست نمی‌توانيد متخصصينی را پيدا کنيد که اين مفهوم را لمس کرده باشند و نه آن که جملات کتابها را از بر برايتان بخوانند.

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

يا مفهوم روشهای تکراری-افزايشی. يکی از دوستان عزيزم که ديگر اکنون در ايران نيست، می‌گفت من پس از سالها پروژه خراب کردن! فهميدم که مفهوم و هدف از روشهای تکراری-افزايشی چيست. بعد همه ادعای استفاده از اين تکنيک را دارند و وقتی خوب دقت می‌کنيد می‌بينيد روشهای آبشاری را تحت نامهای مدرن در حال انجام هستند. وحشتناک‌تر آن که بی‌دانشی و بی‌تجربگی باعث شده خيلی‌ها فکر کنند که RUP مجموعه مستندات است و آن را با کتابهای آيين نگارش  اشتباه می‌گيرند.
سخن قشنگ ديگری که از همه می‌شنويد اين است که RUP برای پروژه‌های بزرگ است. حتی اين جمله هم ناشی از مطالعه نکردن و بی‌اطلاعی و تحت تأثير شنيده‌ها بودن است. 

هفته پيش من جايی بودم و در مورد پروژه‌ای مشاوره می‌دادم. تأکيد من بر اين بود که می‌شود سيستم را بدون بازنويسی، با Refactoring در سطح مطلوبی بازسازی کرد. يکی از دوستان که در جلسه بود گفت: فکر می‌کردم که شما به جای RUP متمايل به XP method شده‌ايد و من هم هاج واج نگاه به همکارم کردم. تأکيد من برگرفته از تجربه و نيز تکنيکی بود که در يکی از روشها تجربه کرده بودم و نه اينکه علاقه‌ای به اسامی داشته باشم.

سالها علاقه من بررسی و به کارگيری تکنيکهايی است که در متدولوژی‌های مختلف وجود داشته و هميشه اين موضوع ناراحتم می‌کند که چرا ما که درياهاي به عمق يک سانت (شايد کمتر) هستيم، درباره اين موضوعات مطالعه نمی‌کنيم و چرا بدون مطالعه به خودمان اجازه اظهار نظرهای عجيب و غريب می‌دهيم.

سخن آخر:بر اساس خصوصيات پروژه، محيط انجام، تيم توليد و چندين پارامتر ديگر شما روش انجام کارتان را بايد انتخاب کنيد، مهم نيست که اسمش چه باشد. با مطالعه از تجربه ديگران در حوزه متدولوژی آشنا شويد و اين مطالعات کمک می‌کند تا تفکرتان را نسبت به توليد نرم‌افزار عوض کنيد.

اگر به موضوع تفاوت متدولوژی از ديدگاه کاربردی علاقمند هستيد پيشنهاد می‌کنيم که حتما مقاله The New Methodoloyرا از آقای مارتین فولر مطالعه نمایید.

تفاوت فرایند و متدولوژی تولید نرم افزار

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

بسیاری از بزرگان دنیای نرم افزار (مانند Ian Sommerville) و برداشت عمومی مهندسان نرم افزار، تفاوتی بین متدولوژی تولید نرم افزار و فرایند تولید نرم افزار قائل نمی شوند و برای مثال RUP و مدل حلزونی را متفاوت نمی دانند و هر دو را متدولوژی تولید نرم افزار یا فرایند تولید نرم افزار می دانند، اما بعضی دیگر مانند Roger Pressman متدولوژی های تولید نرم افزار را تلفیقی از فرایندهای تولید نرم افزار و ابزارهای آنها می دانند و در حقیقت فرایندهای تولید نرم افزار را بعنوان زیرساخت متدولوژی های تولید نرم افزار می دانند. از نظر معنایی هر دو تعریف در نهایت تقریبا به یک معنی کلی می رسند، البته همانطور که در ابتدا ذکر شد تقریبا تمامی مهندسان نرم افزار تفاوتی بین متدولوژی تولید نرم افزار و فرایند تولید نرم افزار قائل نمی شوند.

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

ادامه موضوع در ادامه مطلب مطالعه فرمایید...

ادامه نوشته