تحقیق در مورد ارزیابی NIMSAD از فرایند یکپارچه منطقی (RUP)

توجه : به همراه فایل word این محصول فایل پاورپوینت (PowerPoint) و اسلاید های آن به صورت هدیه ارائه خواهد شد

 تحقیق در مورد ارزیابی NIMSAD از فرایند یکپارچه منطقی (RUP) دارای ۱۷ صفحه می باشد و دارای تنظیمات در microsoft word می باشد و آماده پرینت یا چاپ است

فایل ورد تحقیق در مورد ارزیابی NIMSAD از فرایند یکپارچه منطقی (RUP)  کاملا فرمت بندی و تنظیم شده در استاندارد دانشگاه  و مراکز دولتی می باشد.

توجه : در صورت  مشاهده  بهم ریختگی احتمالی در متون زیر ،دلیل ان کپی کردن این مطالب از داخل فایل ورد می باشد و در فایل اصلی تحقیق در مورد ارزیابی NIMSAD از فرایند یکپارچه منطقی (RUP)،به هیچ وجه بهم ریختگی وجود ندارد

بخشی از متن تحقیق در مورد ارزیابی NIMSAD از فرایند یکپارچه منطقی (RUP) :

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

فهرست۱a
• مقدمه
• عنصر۱: وضعیت مسئله
• عنصر۲: روش شناسی کاربر (حل کننده مشکل یا مسئله)
• عنصر ۳، مرحله۱: درک وضعیت
• عنصر۳، مرحله۲: انجام تشخیص
• عنصر ۳، مرحله۳: تعریف کردن طرح کلی تشخیص
• عنصر۳، مرحله۴: تعریف کردن مسائل
• عنصر۳، مرحله۵: استنتاج یک سیستم فکری
• عنصر۳، مرحله۶: انجام طراحی مصنوعی/منطقی
• عنصر۳، مرحله۷: انجام طراحی فیزیکی
• عنصر۳، مرحله۸: اجرای طرح
• عنصر۴: ارزیابی
• خلاصه
مقدمه:
فرایند یکپارچه منطقی (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 به عنوان یک فرایند مدرن، اندازه زیاد آن باشد که بیش از ۱۷۰۰ صفحه است که وزن کمی نیست.