دانلود رایگان ترجمه مقاله بررسی فرآیند یکپارچه رشنال

مقاله انگلیسی رایگان

ترجمه فارسی رایگان 

بخشی از ترجمه فارسی:

فرايند يكپارچه منطقي (RUP) يك اسلوب سيستمهاي اطلاعاتي است كه امروزه در وسيع‏ ترين حالت استفاده مي‏شود. طراحان اصلي آن سه نفر هستند به نامهاي ايوار ياكوبس، جرادي بوچ و جيمز رامبو، كه همچنين زبان نمونه‏سازي يكپارچه را هم طرح كرده‏اند. اين فرايند اساساً مبتني بر خط مشي (روش) اريكسون، ابجكتوري و خط مشي منطقي (عقلاني) است كه در سال 1995 با فرايند ابجكتوري منطقي تركيب شدند. زبان مدل سازي (نمونه‏سازي) يكپارچه به همراه تجربه‏اي از شركت Rational، فرايند يكپارچه منطقي را تشكيل داد.
فرايند يكپارچه يك فرايند توسعه نرم‏افزاري است كه مجموعه‏اي است از فعاليتهاي مورد نياز براي تبديل نيازمنديهاي كاربران به يك سيستم نرم‏افزاري، اما به عنوان يك چارچوب كلي فرايند هم ديده مي‏شود كه مي‏تواند براي مقاصد مختلف، اختصاصي شود.
سه وجه فرايند يكپارچه عبارتند از:
– حالت كاربري(استفاده)- مورد – حالت متمركز بر ساختار
– و افزايشي
مراحل اصلي براي يك پروژه RUP با توجه به [2 ] عبارتند از:
 گرد هم آوريد تيم (گروه) را
 تصميم بگيريد كه كدام سيستم بنا خواهد شد (ظاهراً انتخاب ديگري به جز بناي يك سيستم وجود ندارد)؛
 يك مدل استفاده- مورد و يك مدل اوليه UI را بنا كنيد؛
 از توسعه ‏هاي فرايند UML براي بناي يك مدل تحليل هدف استفاده كنيد؛
 از جنبه ‏هاي ديگر متداول UML براي دياگرامهاي طراحي، دسته‏بندي، حالت و مرحله و نظاير اينها استفاده كنيد؛
 در حين اختصاص دسته‏ ها به واحدها و بسته ‏ها، به معماري آنها توجه دقيق كنيد؛
 طرح خود را به وسيله مدل استفاده- مورد آزمايش كنيد اين كار نتايج عالي را خواهد داد؛
 طرح را به عمل درآوريد.
عنصر1:  

وضعيت مسئله:
اين روش شناسي به مفهوم، مرتبط است. اين امر به خصوص در دو جريان كاري اصلي يعني نيازمنديها و تحليل، كه مهمترين عوامل در فاز اول (شروع، جزئيات) هستند، ديده مي‏شود اما همه اينها در طول فرايند قرار دارند به خاطر طبيعت ذاتي آن.
همانگونه كه گفته شد: فرايند يكپارچه يك فرايند پيش رونده از طريق سيستم استفاده- مورد مي‏باشد. يعني تمام فرايند توسط مسيري كه كاربر با سيستم تعامل مي‏كند، كنترل مي‏شود. هر مدل ايجاد شده مي‏تواند نشاني از يك مورد استفاده را داشته باشد. اينكه فرايند يكپارچه بر معماري متمركز است بدين معناست كه از ابتداي شروع فرايند تاكيد شديدي بر معماري سيستمهاي اطلاعاتي وجود دارد. اين شامل سخت‏افزار و چارچوبهاي مورد استفاده و نيز گسترش و زبانهاي برنامه‏نويسي هم مي‏شود.
علاوه براين دو مفهوم اختياري در جريان كاري «نيازمنديها» وجود دارد كه تسلط يافتن بر محيط كاري تجاري را پشتيباني مي‏كند:
 مدل قلمرو: يك دياگرام دسته UML كه مهمترين انواع اهداف را در زمينه سيستم، به دست مي‏آورد.
 مدل تجاري: تكنيك درك فرايندهاي تجاري يك سازمان.
اين مدل يك مدل تجاري را شبيه مدل كاربري- مورد براي سيستم نرم‏افزاري از منظر استفاده (كاربري) و طرح‏هاي كلي ارائه مي‏كند كه چگونه براي كاربران خود، ارزش (بهاء) مي‏آفريند. همچنين يك مدل هدف تجاري دارد كه نهادهاي تجاري را همانند مدل قلمرو، تشريح مي‏كند.
اما جدا از آنچه درباره وضعيت مسئله گفته شد، اين يك روش پوزيتوسيستمي (مثبت گرايي) است. به نظر مي‏رسد كه فقط با مشخصات سيستم مرتبط است. RUP هيچ چيزي براي گفتن درباره نيازمنديهاي تجاري يا مدل‏سازي فرايند تجارت ندارد به جز اينكه موارد كاربري كافي هستند.
عنصر2: روش شناسي كاربر (حل كننده مسئله):
RUP، متدولوژي كاربر را با مفهوم كارگر (ايجاد كننده) استفاده مي‏كند.
ارزيابي ايجاد بناي ذهني: حل كنندگان مسئله و نقش‏هاي مختلف آنان، كارگران (ايجاد كنندگان) هستند. هر كارگر نوعي انتزاع انساني را به همراه قابليت‏هاي مورد نياز در مهندسي نرم‏افزار، از خود نشان مي‏دهد. وقتي يك پروژه كارمندان خود را جذب مي‏كند، يك كارگر از خود اطلاعات و قابليتهايي را نشان مي‏دهد كه يك نفر نياز دارد براي انجام آن كار، همانطور كه آن كارگر در اين پروژه نيازمند آن است. در روش‏شناسي، كارگر در ابتدا در قالب مسئوليتش توصيف مي‏شود.
سطوح علاقه بناي ذهني: آنچه كه يك كابر بايد بداند، بيشتر به نقش او در انجام فرايند بستگي دارد يعني آنچه كه او هست. هر فرد انجام دهنده كار (كارگر) بايد اطلاعاتي را از UML، تصوير خوبي از فرايند كلي و مسئوليت خاص وي در اين فرايند داشته باشد. عموماً انجام دهندگان كار عبارتند از:
 تحليل گران سيستم و مشخص كنندگان استفاده- مورد: انجام دهندگان كار با بالاترين سطح مهارت‏ها، آنان داراي مهارت در تحليل فرايند تجارت و سازمانها و داراي تجربه و قدرت تحليل خوبي هستند.
 طراحان واسطه بين كاربر و ابزار: اينان داراي مهارتهاي فني و گرافيكي خوبي هستند.
 آرشيتكت: آرشيتكت (معمار) هم نيازمند مهارت است اما بيشتر از جنبه فني. او همچنين نيازمند درك موارد استفاده جهت انجام اهداف خود مي‏باشد.
 مهندس استفاده- مورد، مهندس اجزاء، ايجاد كننده سيستم: اينها در اصل نياز به مهارتهاي فني دارند چون فقط بر اساس موارد- استفاده، طراحي و اجراء مي‏كنند.
 طراح آزمايش: داراي مهارتهاي فني بالا همچنين درك خوب از فرايندها
 آزمايش كننده سيستم: مهارتهاي فني
عنصر سوم، مرحله اول: فهم وضعيت ارتباط
اين مرحله ارتباط كاملي با جريان كار هسته‏اي يعني كسب نيازمنديها دارد و نقاط شروع مختلفي را مانند مدل تجاري، يك مدل قلمرو يا يك مشخصه نيازمندي كامل و مفصل از مشتري فراهم مي‏كند. بعد از آن چند مرحله ديگر به انجام مي‏رسند. در ابتدا يك ليست جنبه‏هاي مختلف از موضوع ايجاد مي‏شود كه در حين فرايند، بخاطر وسيعتر يا كوچكتر مي‏شود. ثانياً كاربر بايد فهم و دركي از زمينه و متن سيستم داشته باشد. براي بيان زمينه و متن يك سيستم، دو روش وجود دارند كه عبارتند از مدل تجاري و مدل قلمرو. نام نهادن اهداف هم براي ساختن فرهنگي از عبارات استفاده مي‏شود كه به ارتباط كمك مي‏كند. سومين مورد، كسب نيازمنديهاي وظيفه‏اي به كمك “استفاده- مورد“ هاست. نهايتاً نيازمنديهاي غيروظيفه هم كسب مي‏شوند. اين مورد در طبيعت تكرار گونه فرايند، تاكيد زيادي بر بازتاب-در- عمل دارد. نيازمنديها و مرزهاي سيستم به همراه هر تكرار مجدداً ارزيابي مي‏شوند.
تكنيك‏ها و مدلهاي بازرسي:
همانطوري كه در بالا گفته شد ليست جنبه‏ها توسعه مي‏يابد، كه ممكن است شامل وضعيت، هزينه تخميني و اولويت باشد. اين امر در مديريت نيازها در خلال فرايند كمك مي‏كند. در عنصر1 مدل تجاري و مدل قلمرو توضيح داده شدند كه مي‏توانند براي فهم و درك زمينه سيستم و كسب نيازها به كار روند. هنوز در جريان كاري “نيازمنديها“ مدلهاي استفاده- مورد وجود دارند كه توصيف يك تشخيص به كار مي‏روند. آنها تشريح مي‏كنند كه چگونه يك كاربر با سيستم كار مي‏كند. هر نوعي از كاربران به عنوان يك يا بيشتر نقش، عمل مي‏كند. هر سيستم خارجي كه اين سيستم با آن در تعادل است، هم به عنوان ايفا كننده يك نقش عمل مي‏كند. جريان رويدادها براي هر مورد استفاده (use- Case) مي‏تواند به عنوان يك توصيف جداگانه از مراحل عمل مورد استفاده‏ها به كار آيد. همچنين دياگرامهاي وضعيت مي‏توانند براي توصيف يك مورد- استفاده به كار گرفته شوند.
عنصر3، مرحله 2:
انجام تشخيص: براي انجام تشخيص RUP از دياگرامهايي كه در جريان كاري نيازمنديها توسعه يافته، استفاده مي‏كند. آنها در يك سطح مفهومي يا منطقي بيشترند و هيچ چيزي درباره سطح فيزيكي گفته نمي‏شود. RUP بيان مي‏كند كه نيازمنديهايي مي‏توانند وجود داشته باشند كه نمي‏توانند خودكار (اتومات) شوند و به وسيله يك سيستم اطلاعاتي حل مي‏شوند.
عنصر3، مرحله3:
RUP حقيقتاً با اين مرحله به دور از جريان كاري نيازمنديها، ارتباط ندارد اما قبلاً تصميمات، وضعيت مطلوب را ساخته‏اند. هيچ مقايسه‏اي بين حالت فعلي و حالت مطلوب وجود ندارد. همچنين هيچ گونه پرسش مستقيمي درباره تمايلات و نيازهاي مشتري وجود ندارد اما RUP بيان مي‏كند كه آنها بايد در كارگاههايي تحليل گران و مشتريان مشاركت مي‏كنند، تحت مطالعه و كار قرار گيرند.

فهرست مطالب این مقاله:

• مقدمه
• عنصر1: وضعيت مسئله
• عنصر2: روش شناسي كاربر (حل كننده مشكل يا مسئله)
• عنصر 3، مرحله1: درك وضعيت
• عنصر3، مرحله2: انجام تشخيص
• عنصر 3، مرحله3: تعريف كردن طرح كلي تشخيص
• عنصر3، مرحله4: تعريف كردن مسائل
• عنصر3، مرحله5: استنتاج يك سيستم فكري
• عنصر3، مرحله6: انجام طراحي مصنوعي/منطقي
• عنصر3، مرحله7: انجام طراحي فيزيكي
• عنصر3، مرحله8: اجراي طرح
• عنصر4: ارزيابي
• خلاصه

بخشی از مقاله انگلیسی:

Introduction The Rational Unified Process is the information systems methodolgy most widely in use today. The main contributers are the three amigos Ivar Jacobson, Grady Booch and James Rumbaugh who also designed the Unified Modeling Language. It is mainly based on the Ericsson Approach, Objectory and the Rational Approach, which were combined 1995 to the Rational Objectory Process. The Unified Modeling Language together with the expirience of from Rational Inc. acquired software tool companies formed the Rational Unified Process. The Unified Process is a software development process, that is the set of activities needed to transform a users’s requirements into a software system, but it is also seen as process framework, which can be specialised for different purposes. The three main aspects of the Unified Process are that it is • use-case driven • architecture-centric • iterative and incremental The basic sequence of an RUP project according to [2]: • Get the team together. • Decide what system will be built (there is apparently no other option than to build a system). • Build a use case model and UI prototype. • Use the UML process extensions to build an analysis object model. • Segue into the more conventional UML stuff to do the design – class, state, sequence diagrams and the like. • Think hard about architecture while you assign the designed classes to modules and packages • Test against the use case model. RUP provides some excellent guidance on testing. • Transition to live system and do the post mortem. Element 1: The Problem Situation The methodolgy is concered about the context. This is especially seen in the two core workflows Requirements and Analysis which are mostly important in the first to phases (Inception, Elaboration), but come all along the process, because of it’s iterative nature. As mentioned above the Unified Process is use-case driven. It means that the whole process is controlled by the way the users interact with the system. Every produced model can be traced back to a use case. That the Unified Process is architecture-centric means that also from the beginning of the process there is a strong emphasis on the architecture of the information systems. This includes hardware and frameworks used, distribution and programming languages.