تحقیق در مورد ارزیابی NIMSAD از فرایند یکپارچه منطقی (RUP) دارای 13 صفحه می باشد و دارای تنظیمات در microsoft word می باشد و آماده پرینت یا چاپ است
فایل ورد تحقیق در مورد ارزیابی NIMSAD از فرایند یکپارچه منطقی (RUP) کاملا فرمت بندی و تنظیم شده در استاندارد دانشگاه و مراکز دولتی می باشد.
این پروژه توسط مرکز مرکز پروژه های دانشجویی آماده و تنظیم شده است
توجه : در صورت مشاهده بهم ریختگی احتمالی در متون زیر ،دلیل ان کپی کردن این مطالب از داخل فایل ورد می باشد و در فایل اصلی تحقیق در مورد ارزیابی NIMSAD از فرایند یکپارچه منطقی (RUP)،به هیچ وجه بهم ریختگی وجود ندارد
بخشی از متن تحقیق در مورد ارزیابی NIMSAD از فرایند یکپارچه منطقی (RUP) :
ارزیابی NIMSAD از فرایند یکپارچه منطقی (RUP)
فهرست1a
• مقدمه
• عنصر1: وضعیت مسئله
• عنصر2: روش شناسی کاربر (حل کننده مشکل یا مسئله)
• عنصر 3، مرحله1: درک وضعیت
• عنصر3، مرحله2: انجام تشخیص
• عنصر 3، مرحله3: تعریف کردن طرح کلی تشخیص
• عنصر3، مرحله4: تعریف کردن مسائل
• عنصر3، مرحله5: استنتاج یک سیستم فکری
• عنصر3، مرحله6: انجام طراحی مصنوعی/منطقی
• عنصر3، مرحله7: انجام طراحی فیزیکی
• عنصر3، مرحله8: اجرای طرح
• عنصر4: ارزیابی
• خلاصه
مقدمه:
فرایند یکپارچه منطقی (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 بیان میکند که آنها باید در کارگاههایی تحلیل گران و مشتریان مشارکت میکنند، تحت مطالعه و کار قرار گیرند.
عنصر3، مرحله4:
تعریف کردن مسئلهها: RUP بر قلمرو سیستمهای اطلاعاتی تمرکز میکند. مدلسازی تجاری فقط برای زمینه سیستم و نه برای متمایزکردن و شناساندن مسائل در تجارت به کار میآید.
عنصر3، مرحله5:
استنتاج یک سیستم فکری (ذهنی): جریانهای اصلی کاری یعنی نیازمندیها و تحلیل، در این مرحله استفاده میشوند. از این مرحله تاثیر زیادی بر فرایند یکپارچه دارد و درباره حالت فعلی و درباره مسائل کمتر میگوید اما راهنماییهای مستقیمی دربارهایجاد نیازها و چگونگی به عمل آوردن این نیازها دارد.
عنصر3، مرحله6: انجام طراحی مفهومی/ منطقی
این مرحله، جریان کاری طراحی را در سیستم یکپارچه در بر میگیرد. ورودی این جریان کاری، مدل تحلیلی است و مدل طراحی را ایجاد میکند که طرحی از اجراء دارد. این مرحله از طریق دیاگرامهای دستهای انجام میشود. علاوه براین دیاگرامهای تعاملی هم وجود دارند که مراحل عمل را در حالت استفاده مدلسازی میکنند. این میتواند یک دیاگرام همکاری یا یک دیاگرام مرحلهای باشد که این دومی بر سفارش به موقع تاکید میکند، همه اینها با توصیف متنی به نام طراحی جریان رویدادها همراه است. اجرای نیازمندیها هم یک توصیف متنی است اما نیازمندیهای غیر وظیفهای را در اختیار میگیرد که باید هنگام اجرا در خاطر سپرده
شوند. این سیستم به دو سیستم زیر مجموعه تقسیم میشود و فصل مشترکهای آنان از هم متمایز میباشد. آنها در گرههای متفاوتی در یک مدل آرایش منابع قرار دارند. توصیف معماری نمایی از مدل آرایش منابع است.
برای بعضی از اهداف در مدل، مناسب است که رفتار از طریق یک دیاگرام وضعیت مدلسازی شود که انتقال به وضعیت متفاوت را در دسته همطراز طراحی خود، توصیف میکند.
عنصر3، مرحله7: برنامه ریزی برای طراحی فیزیکی
در حقیقت طراحی فیزیکی از طراحی منطقی در فرایند یکپارچه جدا نیست. این امر از طریق طراحی مستقیم دیاگرامهای دستهبندیها به زبانهای برنامهریزی مبتنی بر هدف محقق خواهد شد. علاوه بر این، مهندس اجزاء است که سیستمهای زیر مجموعه را طراحی و همینطور اجرا میکند. بنابراین مرحله 7 میتواند هم در طراحی جریان کاری و هم در انجام آن، قرار بگیرد.
مدل مهم در اجرا، اجزاء (Component) است که شکل فیزیکی عناصر مدل است و میتواند شامل موارد اجرائی، پروندهها، جداول و مدارک باشد. همچنین یک توصیف معماری وجود دارد که شامل یک نمای معماری از مدل اجراء میباشد.
عنصر3، مرحله8: اجرای طرح
این بخشی از جریان کاری اجراء است که در آن اجرای واقعی انجام میشود. مدلهای انجام کار در “عمل” قرار داده میشوند و زیر مجموعههای سیستم کامل میشوند. نهایتاً اجزاء در گرهها میشوند. فرایند یکپارچه تاکیدی بر آزمایش سیستم هم دارد. یک جریان کاری هستهای به نام آزمایش وجود دارد که در حین هر تعاملی اجراء میشود و مدلهای آزمایش را ایجاد میکند که بر مبنای “استفاده- مورد” های جریانهای کاری قبلی میباشد. برای هر مورد آزمایش، یک یا بیشتر روند، توسعه داده میشود. بعضی آزمایشها میتوانند توسط اجزاء آزمایش بطور خودکار (اتومات) درآیند.
عنصر4: ارزیابی:
RUP هیچگونه فاز ارزیابی ندارد اما ارزیابی را در تمام فازها انجام میدهد. فاز انتقال برای ارزیابی تمام پروژه است. در پایان فاز انتقال که البته پایان پروژه در اصطلاح بودجهریزی هم هست، مدیر پروژه یک گروه را گرد هم میآورد تا جدول واقعی زمان، نفر- ساعت، هزینه، نرخهای نقص و سایر موارد را در رابطه با موارد زیر بررسی کنند که:
آیا پروژه به اهداف از قبل برنامه ریزی شده رسیده است؟
اطمینان حاصل کنند که چرا به اهداف خود نرسیده است (در صورت نرسیدن)
یافتهها و دادههای پروژه را به پایگاه دادههای شرکت، جهت استفادههای آینده، اضافه نمایند.
موفقیت اقتصادی هم با استفاده از طرح تجارتی ارزیابی میشود و مدیر پروژه یک گروه کوچک را گرد هم میآورد تا فاز انتقالی را ایجاد و به مراحل بعدی منتقل سازند.
خلاصه:
RUP دارای چندین جنبه مثبت در مقایسه با روشهای قدیمی است و از UML استفاده میکند و چندین تکنیک خاص OO را شامل میشود. مهمترین این موارد، استفاده این سیستم از “موارد- استفاده” ها جهت شناسایی و آزمایش است. این سیستم کاملاً پیشرونده تدریجی است و برای یک کاربر ابزار، بخوبی مناسبت دارد. RUP گفته میشود که بر مبنای معماری پیش میرود، همچنین جنبهای مثبت دارد و باید گفت که دارای نهای محدودی از معماری به عنوان ساختار صرف است. RUP هیچ چیزی برای گفتن درباره نیازمندیهای تجاری و یا مدلسازی فرایند تجاری ندارد به جز اینکه موارد- استفادهها کافی است. یک مزیت RUP هم یک عیب آن محسوب میشود. وابسته بودن آن به ابزار یک پشتیبان، بسیاری از سازمانها را در استفاده از آن مشکل میکند. همچنین هیچ چیزی در RUP درباره طراحی GUI وجود ندارد. مقادیر در RUP اختصاصی نیستند اگرچه انتظار میرود که جمعآوری شدهاند. شاید بدترین جنبه RUP به عنوان یک فرایند مدرن، اندازه زیاد آن باشد که بیش از 1700 صفحه است که وزن کمی نیست.
