بخشی از ترجمه فارسی:
فرايند يكپارچه منطقي (RUP) يك اسلوب سيستمهاي اطلاعاتي است كه امروزه در وسيع ترين حالت استفاده ميشود. طراحان اصلي آن سه نفر هستند به نامهاي ايوار ياكوبس، جرادي بوچ و جيمز رامبو، كه همچنين زبان نمونهسازي يكپارچه را هم طرح كردهاند. اين فرايند اساساً مبتني بر خط مشي (روش) اريكسون، ابجكتوري و خط مشي منطقي (عقلاني) است كه در سال ۱۹۹۵ با فرايند ابجكتوري منطقي تركيب شدند. زبان مدل سازي (نمونهسازي) يكپارچه به همراه تجربهاي از شركت Rational، فرايند يكپارچه منطقي را تشكيل داد.
فرايند يكپارچه يك فرايند توسعه نرمافزاري است كه مجموعهاي است از فعاليتهاي مورد نياز براي تبديل نيازمنديهاي كاربران به يك سيستم نرمافزاري، اما به عنوان يك چارچوب كلي فرايند هم ديده ميشود كه ميتواند براي مقاصد مختلف، اختصاصي شود.
سه وجه فرايند يكپارچه عبارتند از:
– حالت كاربري(استفاده)- مورد – حالت متمركز بر ساختار
– و افزايشي
مراحل اصلي براي يك پروژه RUP با توجه به [۲ ] عبارتند از:
گرد هم آوريد تيم (گروه) را
تصميم بگيريد كه كدام سيستم بنا خواهد شد (ظاهراً انتخاب ديگري به جز بناي يك سيستم وجود ندارد)؛
يك مدل استفاده- مورد و يك مدل اوليه UI را بنا كنيد؛
از توسعه هاي فرايند UML براي بناي يك مدل تحليل هدف استفاده كنيد؛
از جنبه هاي ديگر متداول UML براي دياگرامهاي طراحي، دستهبندي، حالت و مرحله و نظاير اينها استفاده كنيد؛
در حين اختصاص دسته ها به واحدها و بسته ها، به معماري آنها توجه دقيق كنيد؛
طرح خود را به وسيله مدل استفاده- مورد آزمايش كنيد اين كار نتايج عالي را خواهد داد؛
طرح را به عمل درآوريد.
عنصر۱:
وضعيت مسئله:
اين روش شناسي به مفهوم، مرتبط است. اين امر به خصوص در دو جريان كاري اصلي يعني نيازمنديها و تحليل، كه مهمترين عوامل در فاز اول (شروع، جزئيات) هستند، ديده ميشود اما همه اينها در طول فرايند قرار دارند به خاطر طبيعت ذاتي آن.
همانگونه كه گفته شد: فرايند يكپارچه يك فرايند پيش رونده از طريق سيستم استفاده- مورد ميباشد. يعني تمام فرايند توسط مسيري كه كاربر با سيستم تعامل ميكند، كنترل ميشود. هر مدل ايجاد شده ميتواند نشاني از يك مورد استفاده را داشته باشد. اينكه فرايند يكپارچه بر معماري متمركز است بدين معناست كه از ابتداي شروع فرايند تاكيد شديدي بر معماري سيستمهاي اطلاعاتي وجود دارد. اين شامل سختافزار و چارچوبهاي مورد استفاده و نيز گسترش و زبانهاي برنامهنويسي هم ميشود.
علاوه براين دو مفهوم اختياري در جريان كاري «نيازمنديها» وجود دارد كه تسلط يافتن بر محيط كاري تجاري را پشتيباني ميكند:
مدل قلمرو: يك دياگرام دسته UML كه مهمترين انواع اهداف را در زمينه سيستم، به دست ميآورد.
مدل تجاري: تكنيك درك فرايندهاي تجاري يك سازمان.
اين مدل يك مدل تجاري را شبيه مدل كاربري- مورد براي سيستم نرمافزاري از منظر استفاده (كاربري) و طرحهاي كلي ارائه ميكند كه چگونه براي كاربران خود، ارزش (بهاء) ميآفريند. همچنين يك مدل هدف تجاري دارد كه نهادهاي تجاري را همانند مدل قلمرو، تشريح ميكند.
اما جدا از آنچه درباره وضعيت مسئله گفته شد، اين يك روش پوزيتوسيستمي (مثبت گرايي) است. به نظر ميرسد كه فقط با مشخصات سيستم مرتبط است. RUP هيچ چيزي براي گفتن درباره نيازمنديهاي تجاري يا مدلسازي فرايند تجارت ندارد به جز اينكه موارد كاربري كافي هستند.
عنصر۲: روش شناسي كاربر (حل كننده مسئله):
RUP، متدولوژي كاربر را با مفهوم كارگر (ايجاد كننده) استفاده ميكند.
ارزيابي ايجاد بناي ذهني: حل كنندگان مسئله و نقشهاي مختلف آنان، كارگران (ايجاد كنندگان) هستند. هر كارگر نوعي انتزاع انساني را به همراه قابليتهاي مورد نياز در مهندسي نرمافزار، از خود نشان ميدهد. وقتي يك پروژه كارمندان خود را جذب ميكند، يك كارگر از خود اطلاعات و قابليتهايي را نشان ميدهد كه يك نفر نياز دارد براي انجام آن كار، همانطور كه آن كارگر در اين پروژه نيازمند آن است. در روششناسي، كارگر در ابتدا در قالب مسئوليتش توصيف ميشود.
سطوح علاقه بناي ذهني: آنچه كه يك كابر بايد بداند، بيشتر به نقش او در انجام فرايند بستگي دارد يعني آنچه كه او هست. هر فرد انجام دهنده كار (كارگر) بايد اطلاعاتي را از UML، تصوير خوبي از فرايند كلي و مسئوليت خاص وي در اين فرايند داشته باشد. عموماً انجام دهندگان كار عبارتند از:
تحليل گران سيستم و مشخص كنندگان استفاده- مورد: انجام دهندگان كار با بالاترين سطح مهارتها، آنان داراي مهارت در تحليل فرايند تجارت و سازمانها و داراي تجربه و قدرت تحليل خوبي هستند.
طراحان واسطه بين كاربر و ابزار: اينان داراي مهارتهاي فني و گرافيكي خوبي هستند.
آرشيتكت: آرشيتكت (معمار) هم نيازمند مهارت است اما بيشتر از جنبه فني. او همچنين نيازمند درك موارد استفاده جهت انجام اهداف خود ميباشد.
مهندس استفاده- مورد، مهندس اجزاء، ايجاد كننده سيستم: اينها در اصل نياز به مهارتهاي فني دارند چون فقط بر اساس موارد- استفاده، طراحي و اجراء ميكنند.
طراح آزمايش: داراي مهارتهاي فني بالا همچنين درك خوب از فرايندها
آزمايش كننده سيستم: مهارتهاي فني
عنصر سوم، مرحله اول: فهم وضعيت ارتباط
اين مرحله ارتباط كاملي با جريان كار هستهاي يعني كسب نيازمنديها دارد و نقاط شروع مختلفي را مانند مدل تجاري، يك مدل قلمرو يا يك مشخصه نيازمندي كامل و مفصل از مشتري فراهم ميكند. بعد از آن چند مرحله ديگر به انجام ميرسند. در ابتدا يك ليست جنبههاي مختلف از موضوع ايجاد ميشود كه در حين فرايند، بخاطر وسيعتر يا كوچكتر ميشود. ثانياً كاربر بايد فهم و دركي از زمينه و متن سيستم داشته باشد. براي بيان زمينه و متن يك سيستم، دو روش وجود دارند كه عبارتند از مدل تجاري و مدل قلمرو. نام نهادن اهداف هم براي ساختن فرهنگي از عبارات استفاده ميشود كه به ارتباط كمك ميكند. سومين مورد، كسب نيازمنديهاي وظيفهاي به كمك “استفاده- مورد“ هاست. نهايتاً نيازمنديهاي غيروظيفه هم كسب ميشوند. اين مورد در طبيعت تكرار گونه فرايند، تاكيد زيادي بر بازتاب-در- عمل دارد. نيازمنديها و مرزهاي سيستم به همراه هر تكرار مجدداً ارزيابي ميشوند.
تكنيكها و مدلهاي بازرسي:
همانطوري كه در بالا گفته شد ليست جنبهها توسعه مييابد، كه ممكن است شامل وضعيت، هزينه تخميني و اولويت باشد. اين امر در مديريت نيازها در خلال فرايند كمك ميكند. در عنصر۱ مدل تجاري و مدل قلمرو توضيح داده شدند كه ميتوانند براي فهم و درك زمينه سيستم و كسب نيازها به كار روند. هنوز در جريان كاري “نيازمنديها“ مدلهاي استفاده- مورد وجود دارند كه توصيف يك تشخيص به كار ميروند. آنها تشريح ميكنند كه چگونه يك كاربر با سيستم كار ميكند. هر نوعي از كاربران به عنوان يك يا بيشتر نقش، عمل ميكند. هر سيستم خارجي كه اين سيستم با آن در تعادل است، هم به عنوان ايفا كننده يك نقش عمل ميكند. جريان رويدادها براي هر مورد استفاده (use- Case) ميتواند به عنوان يك توصيف جداگانه از مراحل عمل مورد استفادهها به كار آيد. همچنين دياگرامهاي وضعيت ميتوانند براي توصيف يك مورد- استفاده به كار گرفته شوند.
عنصر۳، مرحله ۲:
انجام تشخيص: براي انجام تشخيص RUP از دياگرامهايي كه در جريان كاري نيازمنديها توسعه يافته، استفاده ميكند. آنها در يك سطح مفهومي يا منطقي بيشترند و هيچ چيزي درباره سطح فيزيكي گفته نميشود. RUP بيان ميكند كه نيازمنديهايي ميتوانند وجود داشته باشند كه نميتوانند خودكار (اتومات) شوند و به وسيله يك سيستم اطلاعاتي حل ميشوند.
عنصر۳، مرحله۳:
RUP حقيقتاً با اين مرحله به دور از جريان كاري نيازمنديها، ارتباط ندارد اما قبلاً تصميمات، وضعيت مطلوب را ساختهاند. هيچ مقايسهاي بين حالت فعلي و حالت مطلوب وجود ندارد. همچنين هيچ گونه پرسش مستقيمي درباره تمايلات و نيازهاي مشتري وجود ندارد اما RUP بيان ميكند كه آنها بايد در كارگاههايي تحليل گران و مشتريان مشاركت ميكنند، تحت مطالعه و كار قرار گيرند.
|
بخشی از مقاله انگلیسی:
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.
|