آشنائی با متدولوژی RUP_قسمت چهارم

ویژگی های RUP

- تمرکز بر روی معماری

معماری یک سیستم در واقع نقشه ای برای کاربردها و استفاده از سیستم است که تمام ساختارهای یک کاربرد سیستم را تعریف می کند.

- درک نیازمندیها به وسیله موارد استفاده

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

- بهره مندی از خصوصیت تکراری و تکاملی بودن

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

- استفاده از UML به عنوان ابزار مدلسازی و نمایش

-تمرکز برریسک ها

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

- کنترل پروژه

با این متدولوژی همیشه می دانیم کجا هستیم ، چه می کنیم و چه کاری انجام خواهیم داد.

نتیجه گیری

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

متن کامل این مقاله به همراه یک پاورپوینت برای ارائه رو می تونید از اینجا دانلود کنید.

·         دریافت مقاله

·   دریافت پاورپوینت

آشنائی با متدولوژی RUP_قسمت سوم

تکرار(iteration)

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

Discipline

مدل RUP مشخص می کند که در طول فازهای مختلف،که به تناسب دوره های تکرار در هر فاز طول می کشد چه فعالیت هائی را باید انجام دهیم. کلیه disciplineهائی که در مدل RUP ملزم به انجام آن هستیم به دو دسته کلی discipline های مهندسی و پشتیبانی  تقسیم می شوند. Discipline های مهندسی عبارتند از :

• مدلسازی تجاری(Business Modeling)
• مدیریت نیازمندیها (Requirement Management)
• تحلیل و طراحی (Analysis & Design)
• پیاده سازی (Implementation)
• تست (Test)
• مدل نصب و راه اندازی(Deployment)

و discipline های پشتیبانی عبارتند از :

• مدیریت پروژه (Project management)
• مدیریت ترکیب بندی و تغییرات (Configuration & Change Management)
• مدیریت محیط (Environment Management)

 مدلسازی تجاری

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

مدلسازی تجاری عمدتا در فاز های آغازین و جزئیات نقش بیشتری ایفا می کند.

 مدیریت نیازمندیها

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

• استخراج نیازمندیها
• مدیریت نیازمندیها

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

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

تحلیل و طراحی

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

پیاده سازی

در مدل RUP واحد توسعه و پیاده سازی سیستم موارد استفاده است.بنابراین برای پیاده سازی موارد استفاده به اعضای تیم واگذار می شود و اعضا آن را پیاده سازی می کنند. در این discipline برای تست هر مولفه از روش های تست واحد(Unit Test) استفاده می شود.

تست

تست مولف های نرم افزاری در discipline پیاده سازی انجام می شود . تستی که در این discipline مورد نظر است ، تست یکپارچگی و کارکرد مولفه های مختلف با یکدیگر است. انواع تست هایی که در این جا می تواند مورد استفاده قرار بگیر ، تست موارد استفاده(Use case Test) ، تست یکپارچگی(Integration Test) ، تست انحراف از معیار(Regression Test) ،تست فشار(Stress Test)  ، تست پذیرش (Acceptance Test) و تست سیستم (System Test) می باشد. اهداف discipline تست عبارتند از :

• تمییز و تعیین تعامل ارتباط بین اشیاء مختلف در سیستم
• تمییز و تعیین یکپارچگی بین مولفه های مختلف سیستم یا نرم افزار
• تعیین اینکه آیا تمام نیاز مندیها به طور کامل پیاده سازی شده است یا خیر

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

این discipline عمدتا در فاز تولید نقش دارد.

مدل نصب و راه اندازی

این discipline از درجه اهمیت بالائی در RUP برخوردار است ، چرا که محیط نصب و راه اندازی سیستم را مشخص می کند.در این discipline حداقل نیازمندیهای بستر راه اندازی و کار سیستم مشخص می شود و نرم افزار به صورت بسته های نرم افزاری آماده می شود . .بدین منظور می توان از روش هائی مثل pilot  کردن سیستم و اجرای آزمایشی آن استفاده کرد.  

اهداف این discipline را می توان در موارد زیر خلاصه کرد :

• تهیه و تولید بسته نرم افزاری
• نصب نرم افزار
• توزیع نرم افزار
• فراهم آوردن راهنما برای کاربران

مدیریت پروژه

در این discipline فازبندی ها ، milestone ها ، زمانی که هر توسعه دهنده باید برای تولید یک مورد استفاده خاص صرف کرده و آن را تبدیل به کد کند ، زمان انضمام مولفه های مختلف و زمان تولید محصول نهائی ، مشخص و برنامه ریزی می شود . همچنین چون می توان از مدل RUP برای انواع پروژه ها ، اعم از پروژه های تولید یا راه اندازی ، نرم افزاری یا غیر نرم افزاری استفاده کرد ، بخشی به نام Tailoring  وجود دارد که در آن مدل RUP را بسته به نیاز مساله متناسب می کند .

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

اهداف اصلی مدیریت پروژه عبارتند از :

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

مدیریت ترکیب بندی و تغییرات

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

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

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

 مدیریت محیط

موقعیت مکانی و محیط نرم افزاری و سازمانی توسعه سیستم و  در discipline مدیریت محیط مشخص و مدیریت می شود. به عنوان مثال می توان از نرم افزار source safe در محیط .NET نام برد و یا سرویس دهنده بانک اطلاعاتی و شناسه کاربری و رمز ورود به آن در این discipline مشخص می شود.

شکل زیر، ارتباط فازها ، تکرار هاو disciplineها را به طور کامل نشان میدهد.

 

آشنائی با متدولوژی RUP – قسمت دوم

فازهای RUP

مدل RUP از چهار فاز تشکیل شده است ، که هر فاز با توجه به حجم و میزان پروژه می تواند از چندین مدل تکرار و توسعه  تشکیل شود. در انتهای هر فاز یا هر تکرار یک مرحله زمانی به نام milestone وجود دارد که در آن زمان تیم توسعه باید به یکسری اهداف کلیدی و از پیش تعیین شده رسیده باشد و خروجی مناسبی برای تحویل به مشتری و متاثرین  سیستم داشته باشد . متاثرین سیستم می توانند هریک از اشخاص مدیر بخش ، مشتری و یا مدیر پروژه باشد.
فازهای RUP عبارتند از :
1.فاز آغازین
2.فاز جزئیات یا برنامه ریزی
3.فاز تولید یا ساخت
4.فاز استقرار

 فاز آغازین

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

فاز جزئیات یا برنامه ریزی

هدف این مرحله آنالیز دقیق مساله ، شناخت سایر جزئیات سیستم و ساخت یک بنیان معماری برای توسعه و پیاده سازی و حذف عناصر با ریسک بالا از سیستم است. بدین منظور باید دید دقیق و کامل از هر یک از مولفه ها ، با در نظرگرفتن سایر مولفه ها و اجزای سیستم داشته باشیم.
در انتهای این فاز محاسبات مهندسی کامل شده و تصمیم گیری برای سپردن پروژه به فاز تولید انجام می شود.این محاسبات باید به گونه ای دقیق انجام شود که در فاز بعدی که فاز تولید و پیاده سازی سیستم است ، نقطه ابهامی برای پیاده سازی وجود نداشته باشد. همچنین در این فاز باید عناصر مهم ریسکی رفع شود و برای راه حل آن چاره اندیشی شود.
خروجی های این فاز عبارتند از:
- لیست دقیق ریسک ها و ارائه راه حل بهینه و راه حل های جایگزین به ازای هرریسک
- مستند معماری نرم افزار (Software Architecture Document)
این مستند شامل تحلیل و طراحی کلان سیستم و آنالیز دقیق کلیه مولفه های سیستم است که مواردی از قبیل ساخت نمونه اولیه  ،مدل موارد استفاده ، مدل تجربه کاربر (User Experience Model) ، معماری سیستم، مدل آنالیز (Analysis Model) ، مدل داده ای سیستم  ( Data Base Model)و نحوه نصب و راه اندازی ( Deployment Model)را دربرمی گیرد.
- اولویت بندی موارد استفاده
موارد استفاده سیستم را بر حسب  
• موارد استفاده ریسکی
• موارد استفاده تاثیرگذار بر معماری سیستم
• موارد استفاده مهم برای مشتری
• موارد استفاده ای که پیش نیاز موارد استفاده دیگر هستند
اولویت بندی کرده ، برای واگذاری به تیم های توسعه در مستندی آماده می شود.
- تنظیم برنامه زمان بندی
برنامه ریزی مربوط به زمانبندی فاز ها ، milestone ها و فعالیت های مربوط به هریک از اعضای تیم با توجه به اولویت و زمان لازم به ازای هر مورد استفاده  در این فاز آماده می شود.
معیارهای ارزیابی موفقیت این فاز به شرح زیر است:
• کامل بودن معماری انتخاب شده برای سیستم
معماری سیستم باید برای تمام نیاز های سیستم مناسب بوده وپاسخگوی توسعه و گسترش سیستم در آینده و نیازهای آتی سیستم نیز باشد.
• شناسائی کامل ریسک ها و مناسب بودن راه حل های ارائه شده به ازای هر ریسک
• کامل بودن طرح و برنامه ریزی ارائه شده برای پروژه ، به گونه ای که موفقیت پروژه را تضمین کند.
• قابل قبول بودن هزینه واقعی در مقابل هزینه تخمین زده شده

 فاز ساخت یا تولید

در این فاز با استفاده از خروجی های فاز قبلی تمامی مولفه و موارد استفاده بر حسب اولویت ها به تیم های توسعه واگذار شده و هر تیم موظف به آنالیز ، طراحی ، پیاده سازی و تست آن است.پس از اتمام پیاده سازی هر رده از موارد استفاده ، آن را به مشتری و متاثرین سیستم تحویل داده و نظر آن ها را درباره سیستم و روند پیاده سازی جویا می شویم. مهمترین مزایای این روش کشف و رفع هر گونه خطا و اشتباه در مراحل ابتدائی و آغازین پیاده سازی است و همچنین مشتری در روند انجام و پیشرفت پروژه قرار می گیرد.
می توان تولید بسیاری از موارد استفاده را در تیم های مختلف و به طور موازی با هم انجام داد و از این طریق پیشرفت پروژه را تسریع بخشید.
خروجی های این فاز شامل موارد زیر می باشد :
- نسخه بتا  ( Beta Release) محصول
  نسخه بتا ، نسخه ای از محصول است که برای انجام عمل تست بتا ( Beta Testing) در اختیار کاربران قرار می گیرد.
- راهنمای کاربران
از آن جا که نسخه بتا برای تست بتا در اختیار کاربران قرار می گیرد ، در این مرحله باید راهنمائی برای کاربران آماده شده و در اختیار آن ها قرار گیرد.
در این مرحله سیستم ، جوانب کار و کاربران آن بررسی می شود که آیا محصول می تواند بدون احساس هیچ ریسک جدی در اختیار کاربر قرار گیرد.
مهمترین معیارهای ارزیابی این فاز ، شامل پاسخ به سوالات زیر است:
• آیا محصول تا آ ن جا که ممکن است توسعه پیدا کرده تـا در معـرض ارتباط با کاربر قرار گیرد؟
• آیا متاثرین سیستم برای قراردادن محصول به دست کاربران آماده هستند؟
• آیا هزینه واقعی در مقابل هزینه تخمین زده شده برای پروژه قابل قبول است؟

فاز استقرار

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