ارزیابی NIMSAD از فرایند یكپارچه منطقی (RUP)

مقدمه:
فرایند یكپارچه منطقی (RUP) یك اسلوب سیستمهای اطلاعاتی است كه امروزه در وسیع‏ترین حالت استفاده می‏شود. طراحان اصلی آن سه نفر هستند به نامهای ایوار یاكوبس، جرادی بوچ و جیمز رامبو، كه همچنین زبان نمونه‏سازی یكپارچه را هم طرح كرده‏اند. این فرایند اساساً مبتنی بر خط مشی (روش) اریكسون، ابجكتوری و خط مشی منطقی (عقلانی) است كه در سال ۱۹۹۵ با فرایند ابجكتوری منطقی تركیب شدند. زبان مدل سازی (نمونه‏سازی) یكپارچه به همراه تجربه‏ای از شركت Rational، فرایند یكپارچه منطقی را تشكیل داد.

فرایند یكپارچه یك فرایند توسعه نرم‏افزاری است كه مجموعه‏ای است از فعالیتهای مورد نیاز برای تبدیل نیازمندیهای كاربران به یك سیستم نرم‏افزاری، اما به عنوان یك چارچوب كلی فرایند هم دیده می‏شود كه می‏تواند برای مقاصد مختلف، اختصاصی شود.
سه وجه فرایند یكپارچه عبارتند از:

– حالت كاربری(استفاده)- مورد – حالت متمركز بر ساختار
– و افزایشی
مراحل اصلی برای یك پروژه RUP با توجه به [۲ ] عبارتند از:
 گرد هم آورید تیم (گروه) را

 تصمیم بگیرید كه كدام سیستم بنا خواهد شد (ظاهراً انتخاب دیگری به جز بنای یك سیستم وجود ندارد)؛
 یك مدل استفاده- مورد و یك مدل اولیه UI را بنا كنید؛

 از توسعه‏های فرایند UML برای بنای یك مدل تحلیل هدف استفاده كنید؛
 از جنبه‏های دیگر متداول UML برای دیاگرامهای طراحی، دسته‏بندی، حالت و مرحله و نظایر اینها استفاده كنید؛
 در حین اختصاص دسته‏ها به واحدها و بسته‏ها، به معماری آنها توجه دقیق كنید؛
 طرح خود را به وسیله مدل استفاده- مورد آزمایش كنید این كار نتایج عالی را خواهد داد؛
 طرح را به عمل درآورید.

عنصر۱: وضعیت مسئله:
این روش شناسی به مفهوم، مرتبط است. این امر به خصوص در دو جریان كاری اصلی یعنی نیازمندیها و تحلیل، كه مهمترین عوامل در فاز اول (شروع، جزئیات) هستند، دیده می‏شود اما همه اینها در طول فرایند قرار دارند به خاطر طبیعت ذاتی آن.

همانگونه كه گفته شد: فرایند یكپارچه یك فرایند پیش رونده از طریق سیستم استفاده- مورد می‏باشد. یعنی تمام فرایند توسط مسیری كه كاربر با سیستم تعامل می‏كند، كنترل می‏شود. هر مدل ایجاد شده می‏تواند نشانی از یك مورد استفاده را داشته باشد. اینكه فرایند یكپارچه بر معماری متمركز است بدین معناست كه از ابتدای شروع فرایند تاكید شدیدی بر معماری سیستمهای اطلاعاتی وجود دارد. این شامل سخت‏افزار و چارچوبهای مورد استفاده و نیز گسترش و زبانهای برنامه‏نویسی هم می‏شود.

علاوه براین دو مفهوم اختیاری در جریان كاری «نیازمندیها» وجود دارد كه تسلط یافتن بر محیط كاری تجاری را پشتیبانی می‏كند:
 مدل قلمرو: یك دیاگرام دسته UML كه مهمترین انواع اهداف را در زمینه سیستم، به دست می‏آورد.
 مدل تجاری: تكنیك درك فرایندهای تجاری یك سازمان.

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

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

كار (كارگر) باید اطلاعاتی را از UML، تصویر خوبی از فرایند كلی و مسئولیت خاص وی در این فرایند داشته باشد. عموماً انجام دهندگان كار عبارتند از:
 تحلیل گران سیستم و مشخص كنندگان استفاده- مورد: انجام دهندگان كار با بالاترین سطح مهارت‏ها، آنان دارای مهارت در تحلیل فرایند تجارت و سازمانها و دارای تجربه و قدرت تحلیل خوبی هستند.

 طراحان واسطه بین كاربر و ابزار: اینان دارای مهارتهای فنی و گرافیكی خوبی هستند.
 آرشیتكت: آرشیتكت (معمار) هم نیازمند مهارت است اما بیشتر از جنبه فنی. او همچنین نیازمند درك موارد استفاده جهت انجام اهداف خود می‏باشد.
 مهندس استفاده- مورد، مهندس اجزاء، ایجاد كننده سیستم: اینها در اصل نیاز به مهارتهای فنی دارند چون فقط بر اساس موارد- استفاده، طراحی و اجراء می‏كنند.
 طراح آزمایش: دارای مهارتهای فنی بالا همچنین درك خوب از فرایندها
 آزمایش كننده سیستم: مهارتهای فنی
عنصر سوم، مرحله اول: فهم وضعیت ارتباط

این مرحله ارتباط كاملی با جریان كار هسته‏ای یعنی كسب نیازمندیها دارد و نقاط شروع مختلفی را مانند مدل تجاری، یك مدل قلمرو یا یك مشخصه نیازمندی كامل و مفصل از مشتری فراهم می‏كند. بعد از آن چند مرحله دیگر به انجام می‏رسند. در ابتدا یك لیست جنبه‏های مختلف از موضوع ایجاد می‏شود كه در حین فرایند، بخاطر وسیعتر یا كوچكتر می‏شود. ثانیاً كاربر باید فهم و دركی از زمینه و متن سیستم داشته باشد. برای بیان زمینه و متن یك سیستم، دو روش وجود دارند كه عبارتند از مدل تجاری و مدل قلمرو. نام نهادن اهداف هم برای ساختن فرهنگی از عبارات استفاده می‏شود كه به ارتباط كمك می‏كند. سومین مورد، كسب نیازمندیهای وظیفه‏ای به كمك “استفاده- مورد“ هاست. نهایتاً نیازمندیهای غیروظیفه هم كسب می‏شوند. این مورد در طبیعت تكرار گونه فرایند، تاكید زیادی بر بازتاب-در- عمل دارد. نیازمندیها و مرزهای سیستم به همراه هر تكرار مجدداً ارزیابی می‏شوند.

تكنیك‏ها و مدلهای بازرسی:
همانطوری كه در بالا گفته شد لیست جنبه‏ها توسعه می‏یابد، كه ممكن است شامل وضعیت، هزینه تخمینی و اولویت باشد. این امر در مدیریت نیازها در خلال فرایند كمك می‏كند. در عنصر۱ مدل تجاری و مدل قلمرو توضیح داده شدند كه می‏توانند برای فهم و درك زمینه سیستم و كسب نیازها به كار روند. هنوز در جریان كاری “نیازمندیها“ مدلهای استفاده- مورد وجود دارند كه توصیف یك تشخیص به كار می‏روند. آنها تشریح می‏كنند كه چگونه یك كاربر با سیستم كار می‏كند. هر نوعی از كاربران به عنوان یك یا بیشتر نقش، عمل می‏كند. هر سیستم خارجی كه این سیستم با آن در تعادل است، هم به عنوان ایفا كننده یك نقش عمل می‏كند. جریان رویدادها برای هر مورد استفاده (use- Case) می‏تواند به عنوان یك توصیف جداگانه از مراحل عمل مورد استفاده‏ها به كار آید. همچنین دیاگرامهای وضعیت می‏توانند برای توصیف یك مورد- استفاده به كار گرفته شوند.

عنصر۳، مرحله ۲:
انجام تشخیص: برای انجام تشخیص RUP از دیاگرامهایی كه در جریان كاری نیازمندیها توسعه یافته، استفاده می‏كند. آنها در یك سطح مفهومی یا منطقی بیشترند و هیچ چیزی درباره سطح فیزیكی گفته نمی‏شود. RUP بیان می‏كند كه نیازمندیهایی می‏توانند وجود داشته باشند كه نمی‏توانند خودكار (اتومات) شوند و به وسیله یك سیستم اطلاعاتی حل می‏شوند.

عنصر۳، مرحله۳:
RUP حقیقتاً با این مرحله به دور از جریان كاری نیازمندیها، ارتباط ندارد اما قبلاً تصمیمات، وضعیت مطلوب را ساخته‏اند. هیچ مقایسه‏ای بین حالت فعلی و حالت مطلوب وجود ندارد. همچنین هیچ گونه پرسش مستقیمی درباره تمایلات و نیازهای مشتری وجود ندارد اما RUP بیان می‏كند كه آنها باید در كارگاههایی تحلیل گران و مشتریان مشاركت می‏كنند، تحت مطالعه و كار قرار گیرند.
عنصر۳، مرحله۴:

تعریف كردن مسئله‏ها: RUP بر قلمرو سیستمهای اطلاعاتی تمركز می‏كند. مدل‏سازی تجاری فقط برای زمینه سیستم و نه برای متمایزكردن و شناساندن مسائل در تجارت به كار می‏آید.
عنصر۳، مرحله۵:
استنتاج یك سیستم فكری (ذهنی): جریانهای اصلی كاری یعنی نیازمندیها و تحلیل، در این مرحله استفاده می‏شوند. از این مرحله تاثیر زیادی بر فرایند یكپارچه دارد و درباره حالت فعلی و درباره مسائل كمتر می‏گوید اما راهنمایی‏های مستقیمی دربارهایجاد نیازها و چگونگی به عمل آوردن این نیازها دارد.
عنصر۳، مرحله۶: انجام طراحی مفهومی/ منطقی

این مرحله، جریان كاری طراحی را در سیستم یكپارچه در بر می‏گیرد. ورودی این جریان كاری، مدل تحلیلی است و مدل طراحی را ایجاد می‏كند كه طرحی از اجراء دارد. این مرحله از طریق دیاگرام‏های دسته‏ای انجام می‏شود. علاوه براین دیاگرامهای تعاملی هم وجود دارند كه مراحل عمل را در حالت استفاده مدلسازی می‏كنند. این می‏تواند یك دیاگرام همكاری یا یك دیاگرام مرحله‏ای باشد كه این دومی بر سفارش به موقع تاكید می‏كند، همه اینها با توصیف متنی به نام طراحی جریان رویدادها همراه است. اجرای نیازمندیها هم یك توصیف متنی است اما نیازمندیهای غیر وظیفه‏ای را در اختیار می‏گیرد كه باید هنگام اجرا در خاطر سپرده

شوند. این سیستم به دو سیستم زیر مجموعه تقسیم می‏شود و فصل مشتركهای آنان از هم متمایز می‏باشد. آنها در گره‏های متفاوتی در یك مدل آرایش منابع قرار دارند. توصیف معماری نمایی از مدل آرایش منابع است.
برای بعضی از اهداف در مدل، مناسب است كه رفتار از طریق یك دیاگرام وضعیت مدلسازی شود كه انتقال به وضعیت متفاوت را در دسته همطراز طراحی خود، توصیف می‏كند.
عنصر۳، مرحله۷: برنامه ریزی برای طراحی فیزیكی
در حقیقت طراحی فیزیكی از طراحی منطقی در فرایند یكپارچه جدا نیست. این امر از طریق طراحی مستقیم دیاگرامهای دسته‏بندی‏ها به زبانهای برنامه‏ریزی مبتنی بر هدف محقق خواهد شد. علاوه بر این، مهندس اجزاء است كه سیستمهای زیر مجموعه را طراحی و همینطور اجرا می‏كند. بنابراین مرحله ۷ می‏تواند هم در طراحی جریان كاری و هم در انجام آن، قرار بگیرد.
مدل مهم در اجرا، اجزاء (Component) است كه شكل فیزیكی عناصر مدل است و می‏تواند شامل موارد اجرائی، پرونده‏ها، جداول و مدارك باشد. همچنین یك توصیف معماری وجود دارد كه شامل یك نمای معماری از مدل اجراء می‏باشد.
عنصر۳، مرحله۸: اجرای طرح

این بخشی از جریان كاری اجراء است كه در آن اجرای واقعی انجام می‏شود. مدلهای انجام كار در “عمل” قرار داده می‏شوند و زیر مجموعه‏های سیستم كامل می‏شوند. نهایتاً اجزاء در گره‏ها می‏شوند. فرایند یكپارچه تاكیدی بر آزمایش سیستم هم دارد. یك جریان كاری هسته‏ای به نام آزمایش وجود دارد كه در حین هر تعاملی اجراء می‏شود و مدلهای آزمایش را ایجاد می‏كند كه بر مبنای “استفاده- مورد” های جریانهای كاری قبلی می‏باشد. برای هر مورد آزمایش، یك یا بیشتر روند، توسعه داده می‏شود. بعضی آزمایش‏ها می‏توانند توسط اجزاء آزمایش بطور خودكار (اتومات) درآیند.
عنصر۴: ارزیابی:

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

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

خلاصه:
RUP دارای چندین جنبه مثبت در مقایسه با روش‏های قدیمی است و از UML استفاده می‏كند و چندین تكنیك خاص OO را شامل می‏شود. مهمترین این موارد، استفاده این سیستم از “موارد- استفاده” ها جهت شناسایی و آزمایش است. این سیستم كاملاً پیشرونده تدریجی است و برای یك كاربر ابزار، بخوبی مناسبت دارد. RUP گفته می‏شود كه بر مبنای معماری پیش می‏رود، همچنین جنبه‏ای مثبت دارد و باید گفت كه دارای نهای محدودی از معماری به عنوان ساختار صرف است. RUP هیچ چیزی برای گفتن درباره نیازمندیهای تجاری و یا مدل‏سازی فرایند تجاری ندارد به جز اینكه موارد- استفاده‏ها كافی است. یك مزیت RUP هم یك عیب آن محسوب می‏شود. وابسته بودن آن به ابزار یك پشتیبان، بسیاری از سازمانها را در استفاده از آن مشكل می‏كند. همچنین هیچ چیزی در RUP درباره طراحی GUI وجود ندارد. مقادیر در RUP اختصاصی نیستند اگرچه انتظار می‏رود كه جمع‏آوری شده‏اند. شاید بدترین جنبه RUP به عنوان یك فرایند مدرن، اندازه زیاد آن باشد كه بیش از ۱۷۰۰ صفحه است كه وزن كمی نیست.

فهرست:
• مقدمه
• عنصر۱: وضعیت مسئله
• عنصر۲: روش شناسی كاربر (حل كننده مشكل یا مسئله)
• عنصر ۳، مرحله۱: درك وضعیت
• عنصر۳، مرحله۲: انجام تشخیص
• عنصر ۳، مرحله۳: تعریف كردن طرح كلی تشخیص
• عنصر۳، مرحله۴: تعریف كردن مسائل
• عنصر۳، مرحله۵: استنتاج یك سیستم فكری
• عنصر۳، مرحله۶: انجام طراحی مصنوعی/منطقی
• عنصر۳، مرحله۷: انجام طراحی فیزیكی
• عنصر۳، مرحله۸: اجرای طرح
• عنصر۴: ارزیابی
• خلاصه

ارزیابی NIMSAD از فرایند یكپارچه منطقی (RUP)

مقدمه:
فرایند یكپارچه منطقی (RUP) یك اسلوب سیستمهای اطلاعاتی است كه امروزه در وسیع‏ترین حالت استفاده می‏شود. طراحان اصلی آن سه نفر هستند به نامهای ایوار یاكوبس، جرادی بوچ و جیمز رامبو، كه همچنین زبان نمونه‏سازی یكپارچه را هم طرح كرده‏اند. این فرایند اساساً مبتنی بر خط مشی (روش) اریكسون، ابجكتوری و خط مشی منطقی (عقلانی) است كه در سال ۱۹۹۵ با فرایند ابجكتوری منطقی تركیب شدند. زبان مدل سازی (نمونه‏سازی) یكپارچه به همراه تجربه‏ای از شركت Rational، فرایند یكپارچه منطقی را تشكیل داد.

فرایند یكپارچه یك فرایند توسعه نرم‏افزاری است كه مجموعه‏ای است از فعالیتهای مورد نیاز برای تبدیل نیازمندیهای كاربران به یك سیستم نرم‏افزاری، اما به عنوان یك چارچوب كلی فرایند هم دیده می‏شود كه می‏تواند برای مقاصد مختلف، اختصاصی شود.
سه وجه فرایند یكپارچه عبارتند از:

– حالت كاربری(استفاده)- مورد – حالت متمركز بر ساختار
– و افزایشی
مراحل اصلی برای یك پروژه RUP با توجه به [۲ ] عبارتند از:
 گرد هم آورید تیم (گروه) را

 تصمیم بگیرید كه كدام سیستم بنا خواهد شد (ظاهراً انتخاب دیگری به جز بنای یك سیستم وجود ندارد)؛
 یك مدل استفاده- مورد و یك مدل اولیه UI را بنا كنید؛

 از توسعه‏های فرایند UML برای بنای یك مدل تحلیل هدف استفاده كنید؛
 از جنبه‏های دیگر متداول UML برای دیاگرامهای طراحی، دسته‏بندی، حالت و مرحله و نظایر اینها استفاده كنید؛
 در حین اختصاص دسته‏ها به واحدها و بسته‏ها، به معماری آنها توجه دقیق كنید؛
 طرح خود را به وسیله مدل استفاده- مورد آزمایش كنید این كار نتایج عالی را خواهد داد؛
 طرح را به عمل درآورید.

عنصر۱: وضعیت مسئله:
این روش شناسی به مفهوم، مرتبط است. این امر به خصوص در دو جریان كاری اصلی یعنی نیازمندیها و تحلیل، كه مهمترین عوامل در فاز اول (شروع، جزئیات) هستند، دیده می‏شود اما همه اینها در طول فرایند قرار دارند به خاطر طبیعت ذاتی آن.

همانگونه كه گفته شد: فرایند یكپارچه یك فرایند پیش رونده از طریق سیستم استفاده- مورد می‏باشد. یعنی تمام فرایند توسط مسیری كه كاربر با سیستم تعامل می‏كند، كنترل می‏شود. هر مدل ایجاد شده می‏تواند نشانی از یك مورد استفاده را داشته باشد. اینكه فرایند یكپارچه بر معماری متمركز است بدین معناست كه از ابتدای شروع فرایند تاكید شدیدی بر معماری سیستمهای اطلاعاتی وجود دارد. این شامل سخت‏افزار و چارچوبهای مورد استفاده و نیز گسترش و زبانهای برنامه‏نویسی هم می‏شود.

علاوه براین دو مفهوم اختیاری در جریان كاری «نیازمندیها» وجود دارد كه تسلط یافتن بر محیط كاری تجاری را پشتیبانی می‏كند:
 مدل قلمرو: یك دیاگرام دسته UML كه مهمترین انواع اهداف را در زمینه سیستم، به دست می‏آورد.
 مدل تجاری: تكنیك درك فرایندهای تجاری یك سازمان.

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

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

كار (كارگر) باید اطلاعاتی را از UML، تصویر خوبی از فرایند كلی و مسئولیت خاص وی در این فرایند داشته باشد. عموماً انجام دهندگان كار عبارتند از:
 تحلیل گران سیستم و مشخص كنندگان استفاده- مورد: انجام دهندگان كار با بالاترین سطح مهارت‏ها، آنان دارای مهارت در تحلیل فرایند تجارت و سازمانها و دارای تجربه و قدرت تحلیل خوبی هستند.

 طراحان واسطه بین كاربر و ابزار: اینان دارای مهارتهای فنی و گرافیكی خوبی هستند.
 آرشیتكت: آرشیتكت (معمار) هم نیازمند مهارت است اما بیشتر از جنبه فنی. او همچنین نیازمند درك موارد استفاده جهت انجام اهداف خود می‏باشد.
 مهندس استفاده- مورد، مهندس اجزاء، ایجاد كننده سیستم: اینها در اصل نیاز به مهارتهای فنی دارند چون فقط بر اساس موارد- استفاده، طراحی و اجراء می‏كنند.
 طراح آزمایش: دارای مهارتهای فنی بالا همچنین درك خوب از فرایندها
 آزمایش كننده سیستم: مهارتهای فنی
عنصر سوم، مرحله اول: فهم وضعیت ارتباط

این مرحله ارتباط كاملی با جریان كار هسته‏ای یعنی كسب نیازمندیها دارد و نقاط شروع مختلفی را مانند مدل تجاری، یك مدل قلمرو یا یك مشخصه نیازمندی كامل و مفصل از مشتری فراهم می‏كند. بعد از آن چند مرحله دیگر به انجام می‏رسند. در ابتدا یك لیست جنبه‏های مختلف از موضوع ایجاد می‏شود كه در حین فرایند، بخاطر وسیعتر یا كوچكتر می‏شود. ثانیاً كاربر باید فهم و دركی از زمینه و متن سیستم داشته باشد. برای بیان زمینه و متن یك سیستم، دو روش وجود دارند كه عبارتند از مدل تجاری و مدل قلمرو. نام نهادن اهداف هم برای ساختن فرهنگی از عبارات استفاده می‏شود كه به ارتباط كمك می‏كند. سومین مورد، كسب نیازمندیهای وظیفه‏ای به كمك “استفاده- مورد“ هاست. نهایتاً نیازمندیهای غیروظیفه هم كسب می‏شوند. این مورد در طبیعت تكرار گونه فرایند، تاكید زیادی بر بازتاب-در- عمل دارد. نیازمندیها و مرزهای سیستم به همراه هر تكرار مجدداً ارزیابی می‏شوند.

تكنیك‏ها و مدلهای بازرسی:
همانطوری كه در بالا گفته شد لیست جنبه‏ها توسعه می‏یابد، كه ممكن است شامل وضعیت، هزینه تخمینی و اولویت باشد. این امر در مدیریت نیازها در خلال فرایند كمك می‏كند. در عنصر۱ مدل تجاری و مدل قلمرو توضیح داده شدند كه می‏توانند برای فهم و درك زمینه سیستم و كسب نیازها به كار روند. هنوز در جریان كاری “نیازمندیها“ مدلهای استفاده- مورد وجود دارند كه توصیف یك تشخیص به كار می‏روند. آنها تشریح می‏كنند كه چگونه یك كاربر با سیستم كار می‏كند. هر نوعی از كاربران به عنوان یك یا بیشتر نقش، عمل می‏كند. هر سیستم خارجی كه این سیستم با آن در تعادل است، هم به عنوان ایفا كننده یك نقش عمل می‏كند. جریان رویدادها برای هر مورد استفاده (use- Case) می‏تواند به عنوان یك توصیف جداگانه از مراحل عمل مورد استفاده‏ها به كار آید. همچنین دیاگرامهای وضعیت می‏توانند برای توصیف یك مورد- استفاده به كار گرفته شوند.

عنصر۳، مرحله ۲:
انجام تشخیص: برای انجام تشخیص RUP از دیاگرامهایی كه در جریان كاری نیازمندیها توسعه یافته، استفاده می‏كند. آنها در یك سطح مفهومی یا منطقی بیشترند و هیچ چیزی درباره سطح فیزیكی گفته نمی‏شود. RUP بیان می‏كند كه نیازمندیهایی می‏توانند وجود داشته باشند كه نمی‏توانند خودكار (اتومات) شوند و به وسیله یك سیستم اطلاعاتی حل می‏شوند.

عنصر۳، مرحله۳:
RUP حقیقتاً با این مرحله به دور از جریان كاری نیازمندیها، ارتباط ندارد اما قبلاً تصمیمات، وضعیت مطلوب را ساخته‏اند. هیچ مقایسه‏ای بین حالت فعلی و حالت مطلوب وجود ندارد. همچنین هیچ گونه پرسش مستقیمی درباره تمایلات و نیازهای مشتری وجود ندارد اما RUP بیان می‏كند كه آنها باید در كارگاههایی تحلیل گران و مشتریان مشاركت می‏كنند، تحت مطالعه و كار قرار گیرند.
عنصر۳، مرحله۴:

تعریف كردن مسئله‏ها: RUP بر قلمرو سیستمهای اطلاعاتی تمركز می‏كند. مدل‏سازی تجاری فقط برای زمینه سیستم و نه برای متمایزكردن و شناساندن مسائل در تجارت به كار می‏آید.
عنصر۳، مرحله۵:
استنتاج یك سیستم فكری (ذهنی): جریانهای اصلی كاری یعنی نیازمندیها و تحلیل، در این مرحله استفاده می‏شوند. از این مرحله تاثیر زیادی بر فرایند یكپارچه دارد و درباره حالت فعلی و درباره مسائل كمتر می‏گوید اما راهنمایی‏های مستقیمی دربارهایجاد نیازها و چگونگی به عمل آوردن این نیازها دارد.
عنصر۳، مرحله۶: انجام طراحی مفهومی/ منطقی

این مرحله، جریان كاری طراحی را در سیستم یكپارچه در بر می‏گیرد. ورودی این جریان كاری، مدل تحلیلی است و مدل طراحی را ایجاد می‏كند كه طرحی از اجراء دارد. این مرحله از طریق دیاگرام‏های دسته‏ای انجام می‏شود. علاوه براین دیاگرامهای تعاملی هم وجود دارند كه مراحل عمل را در حالت استفاده مدلسازی می‏كنند. این می‏تواند یك دیاگرام همكاری یا یك دیاگرام مرحله‏ای باشد كه این دومی بر سفارش به موقع تاكید می‏كند، همه اینها با توصیف متنی به نام طراحی جریان رویدادها همراه است. اجرای نیازمندیها هم یك توصیف متنی است اما نیازمندیهای غیر وظیفه‏ای را در اختیار می‏گیرد كه باید هنگام اجرا در خاطر سپرده

شوند. این سیستم به دو سیستم زیر مجموعه تقسیم می‏شود و فصل مشتركهای آنان از هم متمایز می‏باشد. آنها در گره‏های متفاوتی در یك مدل آرایش منابع قرار دارند. توصیف معماری نمایی از مدل آرایش منابع است.
برای بعضی از اهداف در مدل، مناسب است كه رفتار از طریق یك دیاگرام وضعیت مدلسازی شود كه انتقال به وضعیت متفاوت را در دسته همطراز طراحی خود، توصیف می‏كند.
عنصر۳، مرحله۷: برنامه ریزی برای طراحی فیزیكی
در حقیقت طراحی فیزیكی از طراحی منطقی در فرایند یكپارچه جدا نیست. این امر از طریق طراحی مستقیم دیاگرامهای دسته‏بندی‏ها به زبانهای برنامه‏ریزی مبتنی بر هدف محقق خواهد شد. علاوه بر این، مهندس اجزاء است كه سیستمهای زیر مجموعه را طراحی و همینطور اجرا می‏كند. بنابراین مرحله ۷ می‏تواند هم در طراحی جریان كاری و هم در انجام آن، قرار بگیرد.
مدل مهم در اجرا، اجزاء (Component) است كه شكل فیزیكی عناصر مدل است و می‏تواند شامل موارد اجرائی، پرونده‏ها، جداول و مدارك باشد. همچنین یك توصیف معماری وجود دارد كه شامل یك نمای معماری از مدل اجراء می‏باشد.
عنصر۳، مرحله۸: اجرای طرح

این بخشی از جریان كاری اجراء است كه در آن اجرای واقعی انجام می‏شود. مدلهای انجام كار در “عمل” قرار داده می‏شوند و زیر مجموعه‏های سیستم كامل می‏شوند. نهایتاً اجزاء در گره‏ها می‏شوند. فرایند یكپارچه تاكیدی بر آزمایش سیستم هم دارد. یك جریان كاری هسته‏ای به نام آزمایش وجود دارد كه در حین هر تعاملی اجراء می‏شود و مدلهای آزمایش را ایجاد می‏كند كه بر مبنای “استفاده- مورد” های جریانهای كاری قبلی می‏باشد. برای هر مورد آزمایش، یك یا بیشتر روند، توسعه داده می‏شود. بعضی آزمایش‏ها می‏توانند توسط اجزاء آزمایش بطور خودكار (اتومات) درآیند.
عنصر۴: ارزیابی:

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

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

خلاصه:
RUP دارای چندین جنبه مثبت در مقایسه با روش‏های قدیمی است و از UML استفاده می‏كند و چندین تكنیك خاص OO را شامل می‏شود. مهمترین این موارد، استفاده این سیستم از “موارد- استفاده” ها جهت شناسایی و آزمایش است. این سیستم كاملاً پیشرونده تدریجی است و برای یك كاربر ابزار، بخوبی مناسبت دارد. RUP گفته می‏شود كه بر مبنای معماری پیش می‏رود، همچنین جنبه‏ای مثبت دارد و باید گفت كه دارای نهای محدودی از معماری به عنوان ساختار صرف است. RUP هیچ چیزی برای گفتن درباره نیازمندیهای تجاری و یا مدل‏سازی فرایند تجاری ندارد به جز اینكه موارد- استفاده‏ها كافی است. یك مزیت RUP هم یك عیب آن محسوب می‏شود. وابسته بودن آن به ابزار یك پشتیبان، بسیاری از سازمانها را در استفاده از آن مشكل می‏كند. همچنین هیچ چیزی در RUP درباره طراحی GUI وجود ندارد. مقادیر در RUP اختصاصی نیستند اگرچه انتظار می‏رود كه جمع‏آوری شده‏اند. شاید بدترین جنبه RUP به عنوان یك فرایند مدرن، اندازه زیاد آن باشد كه بیش از ۱۷۰۰ صفحه است كه وزن كمی نیست.

فهرست:
• مقدمه
• عنصر۱: وضعیت مسئله
• عنصر۲: روش شناسی كاربر (حل كننده مشكل یا مسئله)
• عنصر ۳، مرحله۱: درك وضعیت
• عنصر۳، مرحله۲: انجام تشخیص
• عنصر ۳، مرحله۳: تعریف كردن طرح كلی تشخیص
• عنصر۳، مرحله۴: تعریف كردن مسائل
• عنصر۳، مرحله۵: استنتاج یك سیستم فكری
• عنصر۳، مرحله۶: انجام طراحی مصنوعی/منطقی
• عنصر۳، مرحله۷: انجام طراحی فیزیكی
• عنصر۳، مرحله۸: اجرای طرح
• عنصر۴: ارزیابی
• خلاصه