Rup چيست؟

[ghazal_ak]

با پيشرفت تكنولوژي‌هاي مرتبط با كامپيوتر، نياز هر چه بيشتر به گسترش علم نرم‌افزاري نيز احساس مي‌شد كه با پيدايش متدولوژيهاي همانند 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 چيست؟
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 كارهايي را كه هر يك از افراد بايد در عمل انجام دهند، به طور گام به گام تشريح مي‌كند.
اين عمليات با استفاده از ابزارهايي واقعي مانند مدل‌ها، كدها، اسناد و گزارشها اداره مي‌شوند.
در RUP به وفور با راهنماييهاي مربوط به نقش‌هايي كه افراد بايد به عهده بگيرند، فعاليتهايي كه بايد انجام شوند و مصنوعات مورد نياز برخورد خواهيد نمود كه در قالب خطوط راهنما، الگوها، مثالها و معلمهاي ابزاري ارائه مي‌شوند كه چگونگي به وقوع پيوستن دسته‌اي از فعاليتها توسط يك ابزار بخصوص را شرح مي‌دهند.
تمامي اين المانهاي توصيف پروسه در قالب سامانه‌هايي سازماندهي شده‌اند.


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

اجازه بدهيد مقايسه‌اي انجام دهيم. اگر فرهنگ لغات مناسبي از 800 لغت را انتخاب كرده باشيد، مي‌توانيد در خيلي از نقاط دنيا و در بسياري شرايط، گليم خود را از آب بيرون بكشيد؛ ولي با انتخاب فرهنگ لغات حجيمي چون Webster ، اولاً هيچ‌كس شما را مجبور به استفاده از لغاتي كه در فرهنگ لغات وجود دارد نمي‌كند، ثانياً مي‌توانيد سطح لغات محفوظي خود را براي انطباق با وضعيتهاي مختلف ارتقا ببخشيد و ثالثاً مي‌توانيد فرهنگ لغات خود را بهبود دهيد. فرهنگ لغت800 لغتي بايد فقط زيرمجموعه‌اي از يك فرهنگ لغات باشد.






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

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

توسعه مكرر
مدل‌سازي بصري
مديريت ملزومات تغييرات كنترل
بازبيني مداوم كيفيت
استفاده از معماري بر مبناي اجزا


همچنين URP بر مبناي ديگر اصول كليدي ديگري كه كمتر قابل مشاهده هستند و ساده‌تر به محاق فراموشي سپرده مي‌شوند، استوار شده است كه فقط براي يادآوري اشاره‌اي به آنها مي‌نماييم (جنر 2002):

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


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

چه چيزي توسعه داده خواهد شد؟
به چه مصنوعاتي واقعاً نياز داريم؟
چه الگوهايي بايد مورد استفاده قرار بگيرند؟
كدام مصنوعات در حال حاضر وجود دارند؟
به چه نقش‌هايي نياز داريم؟
چه فعاليتهايي انجام خواهند شد؟
كدام خطوط راهنما، استانداردهاي پروژه و ابزارهايي مورد استفاده قرار خواهند گرفت؟






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

منبع : میکرورایانه

[ghazal_ak]

نویسنده: سید مصطفی حسینی

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

RUP، متدولوژی ارائه شده توسط شرکت Rational، پرکاربردترین فرآیند تولید و توسعه نرم افزاری در دنیای کنونی است و به عنوان یک استاندارد صنعتی بالفعل در دنیای IT پذیرفته شده است. به گزارش رویتر در سال 2001 میلادی بیش از ششصد هزار شرکت تولید کننده نرم افزار، از ابزارهای شرکت Rational استفاده می کرده‌اند که این تعداد کماکان هم در حال افزایش است. این متدولوژی، برای انواع پروژه‌های نرم‌افزاری در دامنه‌های مختلف ( مانند سیستم‌های اطلاعاتی، سیستم‌های صنعتی، سیستم‌های بلادرنگ، سیستم‌های تعبیه شده، ارتباطات راه دور، سیستم‌های نظامی و ...) و در اندازه‌های متفاوت، از پروژه‌های بسیار کوچک (یک نفر در یک هفته) تا پروژه‌های بسیار بزرگ (چند صد نفر تولید کننده با پراکندگی جغرافیایی)، کاربرد دارد.
مزیت بزرگ این متدولوژی، استفاده از روش تکرار در تولید و مدیریت تولید نرم‌افزار است که این امر، امکان تولید مبتنی بر کاهش ریسک و مواجه با مشکلات اصلی در ابتدای کار و در نتیجه احتمال موفقیت بیشتر را فراهم می‌کند. از محاسن دیگر این متدولوژی مبنا قرار دادن نرم‌افزار و تولید یک معماری پایدار در ابتدای کار است، که در نتیجه امکان کشف مشکلات عمده ساختاری، تست و مجتمع سازی ممتد را از ابتدای کار فراهم می‌کند.
از دیگر مزایای این روش این است که افراد تیم همزمان با پیشرفت پروژه، مطالب جدیدی فرا می‌گیرند و کیفیت فرآیند تولید نیز به طور مرتب افزایش می‌یابد.

همانطور كه در شكل بالا مشاهده می‌شود، RUP دارای دو بعد است :
1. محور افقی نشان دهنده‌ی زمان است و با پیشرفت خود جنبه‌های چرخه‌ی حیات فرآیند و فازهای RUP را نشان می‌دهد.
2. محور عمودی نمایانگر دیسیپلین‌های RUP است كه فعالیت‌ها را با استفاده از ماهیتشان به صورت منطقی دسته‌بندی می‌كند.
در هر فاز ممكن است یك یا چند تكرار وجود داشته باشد و در هر تكرار عملیات دیسپیلین‌های مختلف انجام می‌گیرند.

منبع : میکرورایانه

[ghazal_ak]

Inception (آغازین)

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

• بدست‌ آوردن محدوده نرم‌افزاری پروژه و محدودیت‌های آن كه شامل یك دید عملیاتی، معیار پذیرش و اینكه چه چیز باید در محصول باشد و چه چیز نباید باشد، می‌شود
• مشخص كردن Use-Case های اساسی سیستم، سناریوهای اصلی عملیات كه مسائل مربوط به طراحی اصلی را ایجاد می‌كند.
• نمایش و شاید توضیح حداقل یك معماری كاندیدا برای بعضی سناریوهای اصلی
• برآورد هزینه و زمان كلی برای كل پروژه

(جزییات)

هدف فاز جزئیات تعیین معماری كلی سیستم به منظور فراهم آوردن یك زمینه‌ی مناسب برای قسمت عمده‌ی طراحی و پیاده‌سازی در فاز Construction است. معماری با درنظرگرفتن بیشتر نیازمندی‌های مهم (آن دسته از نیازمندی‌ها كه تأثیر زیادی بر معمار سیستم دارد) و نیز ارزیابی ریسك كامل می‌شود. پایداری معماری از طریق یك یا چند نمونه‌ی اولیه ساختاری ارزیابی می‌‌شود. اهداف اصلی فاز جزئیات شامل موارد زیر است :

• اطمینان از اینكه معماری، نیازمندی‌ها و طرح‌ها به اندازه‌ی كافی پایدارند و ریسك‌ها به اندازه‌ی كافی كاهش یافته‌اند بطوریكه بتوان هزینه و زمان‌بندی لازم برای تكمیل تولید را پیش‌بینی كرد. برای اكثر پروژه‌ها، گذر از این مرحله‌ی مهم مانند انتقال از یك عملیات سبك و سریع و با ریسك پایین به یك عملیات با هزینه و ریسك بالا همراه با اجبار سازمانی است.
• بیان همه‌ی ریسك‌های پروژه كه از نظر ساختاری اهمیت دارند.
• ایجاد یك معماری پایه، مشتق شده از سناریوهای مهم كه از لحاظ ساختاری اهمیت دارند، كه این معماری ریسك‌های فنی عمده پروژه را نیز مشخص می‌كند.

• تولید یك نمونه‌ی اولیه‌ی تكاملی از مولفه‌های با كیفیت تولیدی خوب، و همچنین یك یا چند نمونه‌ی اولیه‌ی اكتشافی و نمونه‌های اولیه‌ی غیر قابل استفاده جهت كاهش ریسكهای خاص مانند :
O سازش‌های مربوط به نیازمند‌ی‌ها یا طراحی
O استفاده‌ی مجدد از مؤلفه‌ها
O عملی بودن محصول یا توضیحات برای سرمایه گذاران، مشتریان و كاربران نهایی
• توضیح اینكه معماری پایه از نیازمندی‌های سیستم با هزینه‌ی منطقی و در زمان منطقی پشتیبانی می‌كند
• ایجاد یك محیط پشتیبانی كننده

(ساخت)

هدف این فاز واضح سازی نیازمندی‌های باقیمانده و تكمیل تولید سیستم بر اساس معماری مبنا می‌باشد. فاز ساخت به نوعی یك فرآیند ساخت است كه در آن تأكید بر مدیریت منابع و كنترل عملیات به منظور بهینه‌سازی هزینه‌ها، زمان‌بندی‌ها و كیفیت است. در این حالت یك انتقال از تولید یك نمونه‌ی ذهنی در طی فازهای Inception و Elaboration به تولید محصولات قابل استقرار در طی Construction وTransition می‌شود. اهداف اصلی فاز Construction شامل موارد زیر می‌باشد :

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

Transition (انتقال)

تمركز این فاز بر این است كه تضمین نماید نرم‌افزار برای كاربران نهایی آماده می‌باشد. فاز Transition می‌تواند به چندین تكرار تقسیم شود، و شامل تست كردن محصول برای آماده‌سازی جهت انتشار و ایجاد تنظیمات كوچك بر اساس بازخورد كاربر می‌باشد. در این نقطه از چرخه‌ی حیات، بازخورد كاربر باید بطور عمده بر تنظیم دقیق محصول، پیكربندی، نصب و نكات مربوط به قابلیت استفاده تمركز یابد، و همه‌ی نكات ساختاری اصلی باید هرچه زودتر در چرخه‌ی حیات پروژه طرح شوند.
با به اتمام رسیدن فاز Transition اهداف چرخه‌ی حیات باید برآورده شده باشند و پروژه در موقعیتی باشد كه بتوان آنرا خاتمه داد. در برخی موارد، پایان چرخه‌ی حیات فعلی ممكن است با آغاز چرخه‌ی حیات بعدی در مورد همان محصول همزمان شود و ما را به سمت تولید یا ویرایش دیگری هدایت كند. برای پروژه‌های دیگر، پایان فاز Transition ممكن است با تحویل كامل خروجی‌ها به گروه سومی كه ممكن است مسؤول عملیات نگهداری و پیشرفت سیستم تحویل دهده شده می‌باشند، همزمان شود.
این فاز بر اساس نوع محصول در فاصله‌ی بسیار ساده تا بی‌نهایت پیچیده قرار دارد. نصب یك نسخه‌ی جدید از یك بسته نرم‌افزاری موجود ممكن است بسیار ساده باشد، در حالیكه جایگزینی سیستم كنترل ترافیك هوایی یك كشور ممكن است بسیار پیچیده باشد. فعالیت‌هایی كه در طول یك تكرار در فاز Transition انجام می‌گیرد به هدف بستگی دارند. برای مثال معمولاً در هنگام رفع اشكالات، پیاده‌سازی و تست كافی هستند. با این وجود اگر ویژگیهای جدیدی باید اضافه شوند، این تكرار شبیه به تكراری در فاز Construction می‌شود كه نیازمند تحلیل و طراحی و غیره است. فاز Transition زمانی وارد عمل می‌شود كه یك خط مبنا آنقدر بالغ شده كه بتواند در دامنه‌ی كاربر نهایی استقرار یابد. این امر بطور نمونه نیازمند این است كه تعدادی زیر مجموعه‌ی قابل استفاده از سیستم با كیفیت قابل قبول و مستندات كاربر، كامل شده باشند، تا انتقال به كاربر نتایج مثبتی را برای همه‌ی گروه‌ها در بر داشته باشد.

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


منبع : میکرورایانه

[ghazal_ak]

دیسیپلین‌های RUP

دیسیپلین مجموعه‌ای از کارهای به هم مرتبطی است که برای انجام جنبه خاصی از یک پروژه انجام می‌شوند. متدولوژی RUP دارای 6 دسیسپلین اصلی (مربوط به تولید محصول) و 3 دیسیپلین كمكی (مربوط به تیم و محیط تولید) است كه در ادامه به ترتیب معرفی خواهند شد.

1- Business Modeling (مدل‌سازی كسب و كار)
2- Requirements (نیازمندی‌ها)
3- Analysis & Design (تحلیل و طراحی)
4- Implementation (پیاده‌سازی)
5- Test (آزمون)
6- Deployment (استقرار)
7- Environment (محیط)
8- Project Management (مدیریت پروژه)
9- Configuration & Change Management (مدیریت پیكربندی و تغییرات)

1- Business Modeling (مدل‌سازی كسب و كار)

اهداف مدل‌سازی كسب و كار عبارتند از:

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

دیسیپلین‌ مدل‌سازی كسب و كار توضیح می‌دهد كه برای رسیدن به این هدف چگونه می‌توان یك تصویر كلی از سازمان را تولید نمود، و براساس این تصویر كلی فرآیندها، نقش‌ها و مسؤولیت‌های آن سازمان را در یك مدل Use-case كسب وكار و یك مدل شیء كسب و كار تعریف كرد.

2- Requirements (نیازمندی‌ها)اهداف دیسیپلین نیازمندی‌ها عبارتند از :

• تشخیص و نگهداری موارد توافق با مشتری‌ها و سایر ذینفعان در مورد كارهایی كه سیستم باید انجام دهد.
• فرآهم آوردن شناخت بهتر از نیازمندی‌های سیستم برای تولید كنندگان سیستم
• تعریف مرزهای و حدود سیستم
• فراهم كردن یك پایه برای طرح ریزی مفاهیم تكنیكی تكرارها
• فراهم كردن یك پایه برای تخمین مخارج و زمان تولید سیستم
• تعریف یك واسط كاربر برای سیستم با تمركز بر روی نیازها واهداف كاربران

برای دستیابی به این اهداف، ابتدا فهم تعریف و محدوده‌ی مسأله‌ای كه سعی داریم با این سیستم آن را حل كنیم، حائز اهمیت می‌باشد. قوانین كسب و كار، مدل Use-Case كسب و كار و مدل شیء كسب و كار كه در طول مدل‌سازی كسب و كار تولید شده به عنوان ورودی با ارزشی برای این تلاش خواهند بود. در این راستا ذینفعان تشخیص داده می‌شوند و درخواستهای ذینفعان استخراج، جمع‌آوری و تجزیه و تحلیل می‌شوند.
یك مستند تصویر كلی، یك مدل Use-Case، Use-Case ها و مشخصه‌های تكمیلی برای توضیح كامل سیستم تولید می‌شود. این توضیح در واقع كاری را كه سیستم انجام خواهد داد بیان می‌كند. این مستندات بعنوان منابع مهم اطلاعات تولید می‌شود. در تولید این مستندات باید خواسته‌های همه ذینفعان را در نظر گرفت.

3- Analysis & Design (تحلیل و طراحی)اهداف تحلیل و طراحی عبارتند از:

• تبدیل نیازمندی‌ها به طراحی سیستم كه قرار است بوجود آید.
• پیدایش یك معماری مستحكم برای سیستم
• سازگار ساختن طراحی برای هماهنگ شدن با محیط پیاده‌سازی و طراحی آن برای كارایی بهتر

در اوایل فاز Elaboration، بر ایجاد یك معماری ابتدایی برای سیستم تمركز می‌شود، كه یك معماری كاندیدا برای فراهم كردن یك نقطه‌ی شروع برای تحلیل اصلی ارائه شود. اگر معماری قبلا وجود دارد (یا بدلیل اینكه در تكرارهای قبلی، در پروژه‌های قبلی تولید شده یا از یك چارچوب كاربردی بدست آمده)، تمركز كار برای اصلاح معماری، تحلیل رفتار و ایجاد یك مجموعه‌ی اولیه از عناصر است كه رفتار مناسب را فراهم می‌آورند.

4- Implementation (پیاده‌سازی)اهداف پیاده‌سازی عبارتند از :
• تعریف سازمان كد، برحسب زیر مجموعه‌ای از مجموعه‌های پیاده‌سازی سازمان یافته در لایه‌ها
• پیاده‌سازی كلاس‌ها و اشیاء بوسیله مؤلفه‌ها (فایل‌های منبع، باینری‌ها، فایل‌های اجرایی و ...)
• تست اجزاء تولید شده به عنوان واحد‌ها
• مجتمع‌سازی نتایج تولید شده توسط پیاده سازان فردی‌ (یا تیم‌ها) به صورت یك سیستم قابل اجرا.
دیسیپلین پیاده‌سازی مرز خود با تست را به اینكه تك تك كلا‌س‌ها چگونه تست واحد می‌شوند، محدود می‌كند. تست سیستم و تست مجتمع سازی در دیسیپلین تست انجام می‌گیرد.

5- Test (آزمون)
دیسیپلین تست از بسیاری جهات مانند یك ارائه دهنده خدمات برای سایر دیسیپلین‌ها عمل می‌كند. تمركز اولیه تست كردن بر بررسی و ارزیابی كیفیت‌های محقق شده از طریق كارهای زیر است :
• یافتن و مستند كردن نقایص در كیفیت نرم‌افزار
• آگاهی دادن در مورد كیفیت نرم‌افزار بررسی شده
• اثبات اعتبار فرضیاتی كه در طراحی و مشخصات نیازمندی‌ها ساخته شدند، از طریق نمایش‌های واقعی
• تصدیق عملكردهای محصول نرم‌افزار همانطور كه طراحی شده است.
• تصدیق اینكه نیازمندی‌ها بدرستی پیاده‌سازی شده‌اند.

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

6- Deployment (استقرار)
دیسیپلین استقرار فعالیت‌هایی را توضیح می‌دهد كه تضمین می‌كنند محصول نرم‌افزاری برای كاربران نهایی‌اش در دسترس می‌باشد. دیسیپلین استقرار سه حالت استقار محصول را توضیح می‌دهد.

• نصب اختصاصی
• آماده فروش كردن محصول نهایی
• دستیابی به نرم‌افزار از طریق اینترنت

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

7- Environment (محیط)
دیسیپلین محیط بر فعالیت‌هایی كه برای پیكربندی فرآیند برای یك پروژه لازم و ضروری‌اند، متمركز می‌شود. این دیسیپلین فعالیت‌های مورد نیاز برای تولید رهنمودهایی كه در جهت پشتیبانی از یك پروژه لازم می‌باشند را توضیح می‌دهد. هدف فعالیت‌هایی محیطی فراهم آوردن محیط تولید (هم فرآیندها و هم ابزاری كه تیم تولید را پشتیبانی می‌كنند) برای سازمان تولید كننده نرم‌افزار می‌باشد.
جعبه ابزار مهندس فرآیند پشتیبانی ابزاری را برای پیكربندی یك فرآیند فراهم می‌كند. این مورد شامل ابزارها و نمونه‌هایی برای ایجاد سایتهای وب پروژه و سازمان بر اساس RUP می‌شود.

8- Project Management (مدیریت پروژه)
مدیریت پروژه نرم‌افزاری، هنر متوازن ساختن اهداف متقابل، مدیریت ریسك و غلبه بر محدودیت‌ها برای تحویل موفقیت آمیز محصولی است كه هم نیازهای مشتریان ( كسانی كه برای سیستم پول می‌پردازند) و هم نیازهای كاربران را برآورده كند. این حقیقت كه پروژه‌های بسیار كمی هستند كه واقعا موفقیت‌آمیزند برای توضیح سخت بودن این كار، كافی می‌باشد.
اهداف این دیسیپلین عبارتند از :
• فراهم كردن یك چارچوب برای مدیریت پروژه‌های صرفاً نرم‌افزاری
• فراهم كردن رهنمودهای عملی برای طرح‌ریزی، تعیین نیروی انسانی، اجرا و نظارت بر پروژه‌ها
• فراهم كردن یك چارچوب برای مدیریت ریسك
• با این وجود، این دیسیپلین از RUP برای پوشش دادن همه‌ی جنبه‌های مدیریت پروژه نیست. برای مثال این دیسیپلین موارد زیر را پوشش نمی‌دهد :

مدیریت افراد : استخدام، آموزش، رهبری
مدیریت بودجه : تعیین، تخصیص و غیره
مدیریت قراردادها : با پشتیبانی كنندگان و مشتریان
این دیسیپلین بطور عمده روی جنبه‌های مهم یك فرآیند تكراری تمركز می‌كند كه عبارتند از :
مدیریت ریسك
طرح ریزی برای یك پروژه‌ی تكراری، از طریق چرخه‌ی حیات و برای یك تكرار بخصوص
نظارت بر پیشرفت یك پروژه‌ی تكراری و متریك‌ها

9- Configuration & Change Management (مدیریت پیكربندی و تغییبرای تأویل و تفسیر ”مدل بلوغ قابلیت“ انستیتو مهندسی نرم‌افزار(SEI CMM)، مدیریت پیكربندی و درخواست تغییر، تغییرات را به سمت خروجی‌های یك پروژه كنترل می‌كند و همچنین صحت و تمامیت خروجی‌های پروژه را حفظ می‌كند.
مدیریت پیكربندی و درخواست تغییر (CRM, CM) شامل موارد زیر می‌باشند :
• تشخیص موارد پیكربندی
• محدود كردن تغییرات آن موارد
• رسیدگی به تغییراتی كه برای آن موارد ساخته شده
• تعریف و مدیریت پیكربندی آن موارد

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

• به روز رسانی همزمان
• توجه دادن محدود شده
• نسخه‌های چندگانه



منبع : میکرورایانه