تبلیغات
تبلیغات متنی
محبوبترینها
قیمت انواع دستگاه تصفیه آب خانگی در ایران
نمایش جنگ دینامیت شو در تهران [از بیوگرافی میلاد صالح پور تا خرید بلیط]
9 روش جرم گیری ماشین لباسشویی سامسونگ برای از بین بردن بوی بد
ساندویچ پانل: بهترین گزینه برای ساخت و ساز سریع
خرید بیمه، استعلام و مقایسه انواع بیمه درمان ✅?
پروازهای مشهد به دبی چه زمانی ارزان میشوند؟
تجربه غذاهای فرانسوی در قلب پاریس بهترین رستورانها و کافهها
دلایل زنگ زدن فلزات و روش های جلوگیری از آن
خرید بلیط چارتر هواپیمایی ماهان _ ماهان گشت
سیگنال در ترید چیست؟ بررسی انواع سیگنال در ترید
بهترین هدیه تولد برای متولدین زمستان: هدیههای کاربردی برای روزهای سرد
صفحه اول
آرشیو مطالب
ورود/عضویت
هواشناسی
قیمت طلا سکه و ارز
قیمت خودرو
مطالب در سایت شما
تبادل لینک
ارتباط با ما
مطالب سایت سرگرمی سبک زندگی سینما و تلویزیون فرهنگ و هنر پزشکی و سلامت اجتماع و خانواده تصویری دین و اندیشه ورزش اقتصادی سیاسی حوادث علم و فناوری سایتهای دانلود گوناگون
مطالب سایت سرگرمی سبک زندگی سینما و تلویزیون فرهنگ و هنر پزشکی و سلامت اجتماع و خانواده تصویری دین و اندیشه ورزش اقتصادی سیاسی حوادث علم و فناوری سایتهای دانلود گوناگون
آمار وبسایت
تعداد کل بازدیدها :
1833430670
Rup چيست؟
واضح آرشیو وب فارسی:سایت ریسک: ghazal_ak24-02-2008, 11:32 AMبا پيشرفت تكنولوژيهاي مرتبط با كامپيوتر، نياز هر چه بيشتر به گسترش علم نرمافزاري نيز احساس ميشد كه با پيدايش متدولوژيهاي همانند 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_ak24-02-2008, 11:40 AMنویسنده: سید مصطفی حسینی فرایند انجام یک پروژه تعریف میکند که چه کسی، چه کاری را در چه هنگام و چگونه برای رسیدن به هدف (انجام پروژه) انجام میدهد. در مهندسی نرمافزار، هدف ساختن یک محصول نرمافزاری و یا بهبود یک نمونهی موجود است. هدف از تعیین فرایند، تضمین کیفیت نرمافزار، برآورده شدن نیازهای کاربر و قابل تخمین بودن زمان و هزینهی تولید میباشد. علاوه بر این، تعیین فرایند، روندی جهت تحویل مصنوعات دوران تولید نرمافزار به کارفرما و ناظر پروژه ارائه میدهد تا از این طریق اطمینان حاصل کنند که پروژه روند منطقی خود را طی میکند و نظارت درست بر انجام پروژه ممکن است و از سوی دیگر، معیاری برای ارزیابی پروژه انجام شده میباشد. تا كنون متدولوژیهای مختلفی برای فرآیند تولید نرمافزار ارائه شدهاند كه یكی از مشهورترین آنها RUP است. RUP، متدولوژی ارائه شده توسط شرکت Rational، پرکاربردترین فرآیند تولید و توسعه نرم افزاری در دنیای کنونی است و به عنوان یک استاندارد صنعتی بالفعل در دنیای IT پذیرفته شده است. به گزارش رویتر در سال 2001 میلادی بیش از ششصد هزار شرکت تولید کننده نرم افزار، از ابزارهای شرکت Rational استفاده می کردهاند که این تعداد کماکان هم در حال افزایش است. این متدولوژی، برای انواع پروژههای نرمافزاری در دامنههای مختلف ( مانند سیستمهای اطلاعاتی، سیستمهای صنعتی، سیستمهای بلادرنگ، سیستمهای تعبیه شده، ارتباطات راه دور، سیستمهای نظامی و ...) و در اندازههای متفاوت، از پروژههای بسیار کوچک (یک نفر در یک هفته) تا پروژههای بسیار بزرگ (چند صد نفر تولید کننده با پراکندگی جغرافیایی)، کاربرد دارد. مزیت بزرگ این متدولوژی، استفاده از روش تکرار در تولید و مدیریت تولید نرمافزار است که این امر، امکان تولید مبتنی بر کاهش ریسک و مواجه با مشکلات اصلی در ابتدای کار و در نتیجه احتمال موفقیت بیشتر را فراهم میکند. از محاسن دیگر این متدولوژی مبنا قرار دادن نرمافزار و تولید یک معماری پایدار در ابتدای کار است، که در نتیجه امکان کشف مشکلات عمده ساختاری، تست و مجتمع سازی ممتد را از ابتدای کار فراهم میکند. از دیگر مزایای این روش این است که افراد تیم همزمان با پیشرفت پروژه، مطالب جدیدی فرا میگیرند و کیفیت فرآیند تولید نیز به طور مرتب افزایش مییابد. http://www.forum.microrayaneh.com/download/file.php?id=175&t=1 همانطور كه در شكل بالا مشاهده میشود، RUP دارای دو بعد است : 1. محور افقی نشان دهندهی زمان است و با پیشرفت خود جنبههای چرخهی حیات فرآیند و فازهای RUP را نشان میدهد. 2. محور عمودی نمایانگر دیسیپلینهای RUP است كه فعالیتها را با استفاده از ماهیتشان به صورت منطقی دستهبندی میكند. در هر فاز ممكن است یك یا چند تكرار وجود داشته باشد و در هر تكرار عملیات دیسپیلینهای مختلف انجام میگیرند. منبع : میکرورایانه ghazal_ak24-02-2008, 11:45 AMhttp://www.forum.microrayaneh.com/download/file.php?id=176&t=1 Inception (آغازین) هدف اصلی این فاز دستیابی به توافق میان كلیهی ذینفعان بر روی اهداف چرخهی حیات پروژه است. فاز Inception به دلیل تلاشهای تولید و توسعه جدید به صورت پایهای اهمیت فراوانی دارد كه در آن ریسكهای نیازسنجی و تجاری مهمی وجود دارد كه باید پیش از اینكه اجرای پروژه مورد توجه قرار گیرد، بررسی شوند. برای پروژههایی كه بر توسعه سیستم موجود متمركزند، فاز Inception كوتاه تر است، با این حال این فاز برای حصول اطمینان از اینكه پروژه ارزش انجام دادن دارد و امكانپذیر نیز هست، انجام میشود. اهداف اصلی فاز آغازین شامل موارد زیر است : • بدست آوردن محدوده نرمافزاری پروژه و محدودیتهای آن كه شامل یك دید عملیاتی، معیار پذیرش و اینكه چه چیز باید در محصول باشد و چه چیز نباید باشد، میشود • مشخص كردن Use-Case های اساسی سیستم، سناریوهای اصلی عملیات كه مسائل مربوط به طراحی اصلی را ایجاد میكند. • نمایش و شاید توضیح حداقل یك معماری كاندیدا برای بعضی سناریوهای اصلی • برآورد هزینه و زمان كلی برای كل پروژه (جزییات) هدف فاز جزئیات تعیین معماری كلی سیستم به منظور فراهم آوردن یك زمینهی مناسب برای قسمت عمدهی طراحی و پیادهسازی در فاز Construction است. معماری با درنظرگرفتن بیشتر نیازمندیهای مهم (آن دسته از نیازمندیها كه تأثیر زیادی بر معمار سیستم دارد) و نیز ارزیابی ریسك كامل میشود. پایداری معماری از طریق یك یا چند نمونهی اولیه ساختاری ارزیابی میشود. اهداف اصلی فاز جزئیات شامل موارد زیر است : • اطمینان از اینكه معماری، نیازمندیها و طرحها به اندازهی كافی پایدارند و ریسكها به اندازهی كافی كاهش یافتهاند بطوریكه بتوان هزینه و زمانبندی لازم برای تكمیل تولید را پیشبینی كرد. برای اكثر پروژهها، گذر از این مرحلهی مهم مانند انتقال از یك عملیات سبك و سریع و با ریسك پایین به یك عملیات با هزینه و ریسك بالا همراه با اجبار سازمانی است. • بیان همهی ریسكهای پروژه كه از نظر ساختاری اهمیت دارند. • ایجاد یك معماری پایه، مشتق شده از سناریوهای مهم كه از لحاظ ساختاری اهمیت دارند، كه این معماری ریسكهای فنی عمده پروژه را نیز مشخص میكند. • تولید یك نمونهی اولیهی تكاملی از مولفههای با كیفیت تولیدی خوب، و همچنین یك یا چند نمونهی اولیهی اكتشافی و نمونههای اولیهی غیر قابل استفاده جهت كاهش ریسكهای خاص مانند : O سازشهای مربوط به نیازمندیها یا طراحی O استفادهی مجدد از مؤلفهها O عملی بودن محصول یا توضیحات برای سرمایه گذاران، مشتریان و كاربران نهایی • توضیح اینكه معماری پایه از نیازمندیهای سیستم با هزینهی منطقی و در زمان منطقی پشتیبانی میكند • ایجاد یك محیط پشتیبانی كننده (ساخت) هدف این فاز واضح سازی نیازمندیهای باقیمانده و تكمیل تولید سیستم بر اساس معماری مبنا میباشد. فاز ساخت به نوعی یك فرآیند ساخت است كه در آن تأكید بر مدیریت منابع و كنترل عملیات به منظور بهینهسازی هزینهها، زمانبندیها و كیفیت است. در این حالت یك انتقال از تولید یك نمونهی ذهنی در طی فازهای Inception و Elaboration به تولید محصولات قابل استقرار در طی Construction وTransition میشود. اهداف اصلی فاز Construction شامل موارد زیر میباشد : • كمینه كردن هزینههای تولید با بهینهسازی منابع و پرهیز از دور انداختن و دوبارهكاری غیر ضروری • دستیابی هرچه سریعتر به كیفیت كافی • دستیابی هر جه سریعتر به ویرایشهای مفید (آلفا، بتا و سایر نسخههای تست) • كامل كردن تحلیل، طراحی، تولید و تست كارآیی مورد نیاز • تولید تكراری و گام به گام یك محصول كامل كه آمادهی انتقال به محیط كاربران باشد • تصمیم در مورد اینكه آیا نرمافزار، سایتها و كاربران همه برای استقرار طرح آمادگی دارند • دستیابی به میزانی از موازی سازی در كار تیمهای تولید. Transition (انتقال) تمركز این فاز بر این است كه تضمین نماید نرمافزار برای كاربران نهایی آماده میباشد. فاز Transition میتواند به چندین تكرار تقسیم شود، و شامل تست كردن محصول برای آمادهسازی جهت انتشار و ایجاد تنظیمات كوچك بر اساس بازخورد كاربر میباشد. در این نقطه از چرخهی حیات، بازخورد كاربر باید بطور عمده بر تنظیم دقیق محصول، پیكربندی، نصب و نكات مربوط به قابلیت استفاده تمركز یابد، و همهی نكات ساختاری اصلی باید هرچه زودتر در چرخهی حیات پروژه طرح شوند. با به اتمام رسیدن فاز Transition اهداف چرخهی حیات باید برآورده شده باشند و پروژه در موقعیتی باشد كه بتوان آنرا خاتمه داد. در برخی موارد، پایان چرخهی حیات فعلی ممكن است با آغاز چرخهی حیات بعدی در مورد همان محصول همزمان شود و ما را به سمت تولید یا ویرایش دیگری هدایت كند. برای پروژههای دیگر، پایان فاز Transition ممكن است با تحویل كامل خروجیها به گروه سومی كه ممكن است مسؤول عملیات نگهداری و پیشرفت سیستم تحویل دهده شده میباشند، همزمان شود. این فاز بر اساس نوع محصول در فاصلهی بسیار ساده تا بینهایت پیچیده قرار دارد. نصب یك نسخهی جدید از یك بسته نرمافزاری موجود ممكن است بسیار ساده باشد، در حالیكه جایگزینی سیستم كنترل ترافیك هوایی یك كشور ممكن است بسیار پیچیده باشد. فعالیتهایی كه در طول یك تكرار در فاز Transition انجام میگیرد به هدف بستگی دارند. برای مثال معمولاً در هنگام رفع اشكالات، پیادهسازی و تست كافی هستند. با این وجود اگر ویژگیهای جدیدی باید اضافه شوند، این تكرار شبیه به تكراری در فاز Construction میشود كه نیازمند تحلیل و طراحی و غیره است. فاز Transition زمانی وارد عمل میشود كه یك خط مبنا آنقدر بالغ شده كه بتواند در دامنهی كاربر نهایی استقرار یابد. این امر بطور نمونه نیازمند این است كه تعدادی زیر مجموعهی قابل استفاده از سیستم با كیفیت قابل قبول و مستندات كاربر، كامل شده باشند، تا انتقال به كاربر نتایج مثبتی را برای همهی گروهها در بر داشته باشد. اهداف اهداف مهم فاز Transition عبارتند از : • تست بتا برای تشخیص اعتبار سیستم جدید با توجه به انتظارات كاربر • تست بتا و عملیات موازی همراه با یك سیستم قدیمی كه در حال جایگزینی میباشد. • تبدیل پایگاههای دادهی عملیاتی • آموزش كاربران و نگهداری كنندگان • بازاریابی، توزیع و فروش برای نخستین انتشار محصول • تنظیم فعالیتها از قبیل رفع اشكال، افزایش كارایی و قابلیت استفاده • ارزیابی خط مبناهای استقرار در مقایسه با تصویر كلی و معیار قابلیت قابل قبول برای محصول • دستیابی به موافقت ذینفع در مورد اینكه خط مبناهای استقرار كامل میباشند • دستیابی به موافقع ذینفع در مور اینكه خط مبناهای استقرار با معیار ارزیابی تصویر كلی سازگارند. منبع : میکرورایانه ghazal_ak24-02-2008, 11:53 AMدیسیپلینهای 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 (مدلسازی كسب و كار) اهداف مدلسازی كسب و كار عبارتند از: - شناخت ساختار و دینامیكهای سازمانی كه در آن یك سیستم باید استقرار یابد(سازمان هدف). - شناخت مشكلات فعلی در سازمان هدف و تشخیص پتانسیلهای بهبود - تضمین اینكه مشتری، كاربر نهایی و تولید كنندگا� سایت ما را در گوگل محبوب کنید با کلیک روی دکمه ای که در سمت چپ این منو با عنوان +1 قرار داده شده شما به این سایت مهر تأیید میزنید و به دوستانتان در صفحه جستجوی گوگل دیدن این سایت را پیشنهاد میکنید که این امر خود باعث افزایش رتبه سایت در گوگل میشود
این صفحه را در گوگل محبوب کنید
[ارسال شده از: سایت ریسک]
[مشاهده در: www.ri3k.eu]
[تعداد بازديد از اين مطلب: 672]
-
گوناگون
پربازدیدترینها