انجام پایان نامه

درخواست همکاری انجام پایان نامه  بانک مقالات رایگان انجام پایان نامه

سفارش پایان نامه

|

انجام پایان نامه ارشد

 پایان نامه 

پایان نامه‏ کامپیوتر

انجام پایان نامه‏ ارشد کامپیوتر

چكيده
  چه چيز مي‌تواند يك پروسه توليد نرم‌افزار را توصيف كند؟ آيا منظور از پروسه، آماده‌سازي نرم‌افزار صرفاً براي ارائه در بازار است؟ مسلماً در هر كاري وجود يك سامانه و فرايند كاري ضروري است؛ ولي چه چيزي مي‌تواند موجب ايجاد سرعت و كيفيت در فرايند توليد يك نرم‌افزارشود؟ لزوماً طراحي و پياده‌سازي يك فرايند يكپارچه و منطقي مي‌تواند چنين نتيجه‌اي در بر داشته باشد.
 فرایند انجام یک پروژه تعریف می‌کند که چه کسی، چه کاری را در چه هنگام و چگونه برای رسیدن به هدف (انجام پروژه) انجام می‌دهد.
در مهندسی نرم‌افزار، هدف ساختن یک محصول نرم‌افزاری و یا بهبود یک نمونه‌ی موجود است. هدف از تعیین فرایند، تضمین کیفیت نرم‌افزار، برآورده شدن نیاز‌های کاربر و قابل تخمین بودن زمان و هزینه‌ی تولید می‌باشد. علاوه بر این، تعیین فرایند، روندی جهت تحویل مصنوعات دوران تولید نرم‌افزار به کارفرما و ناظر پروژه ارائه می‌دهد تا از این طریق اطمینان حاصل کنند که پروژه روند منطقی خود را طی می‌کند و نظارت درست بر انجام پروژه ممکن است و از سوی دیگر، معیاری برای ارزیابی پروژه انجام شده می‌باشد. تا كنون متدولوژی‌های مختلفی برای فرآیند تولید نرم‌افزار ارائه شده‌اند كه یكی از مشهورترین آنها RUP است.
   بدين منظور امروزه از متدولوژی RUP استفاده می کنند. RUP مخفف عبارت( Rational Unified Process) چارچوبي كلي است براي تشريح فرآيند ساخت نرم‌افزار. پس از آنكه تيم سه نفره‌ي شركت Rational ساخت UML را (به عنوان يك شيوه‌ي نمايش   notation/يكتا براي تشريح مدل شيء) به آخر رساند، تلاش خود را متوجه فرآيند توليد نرم‌افزار نمود.
  اساس RUP بر تكرار (iteration) است و اساس تكرار اين است كه هر تكرار به يك محصول قابل اجرا ختم شود. هر تكرار شامل هر هفت مرحله چرخه‌ي حيات در مدل سنتي آبشاري است، يعني: مدلسازي تجاري، تخمين نيازها، تحليل و طراحي، پياده سازي، تست، نگهداري و توسعه.
  به حداقل رساندن حجم پروسه توليد يك نرم‌افزار همزمان با حفظ كيفيت و صرفه‌جويي در زمان از مهمترين ويژگي‌هاي اين روش مي‌باشند. معمولاً براي يك شركت توليد نرم‌افزار، سرعت عمل به موقع براي پاسخ‌گويي به تقاضا و شرايط اجتماعي اهميت دارد، اما گاهي اين شتابزدگي سبب فدا شدن كيفيت مي‌گردد.
   RUP با ارائه يك چارچوب منطقي علاوه بر تعيين زمانبندي مناسب، كيفيت مورد نظر توليد كننده و استفاده كننده نرم‌افزار را تأمين مي‌نمايد. در اين تحقیق ضمن مروري بر RUP به عنوان روش يكپارچه توليد نرم‌افزار، قابليت‌هاي آن در افزايش سرعت توليد نرم‌افزار و حفظ كيفيت آن برشمرده مي‌شوند.  
مقدمه
يك پروسه چابك، پروسه‌اي است كه هميشه آماده در آغوش كشيدن درخواستهاي جامعه بوده و  اين درجه از سازگاري را دارا باشد.
 بنابراين منظور از سرعت عمل، فقط كاستن از حجم پروسه توليد نرم‌افزار يا سرعت ارائه آن به بازار نيست؛ بلكه منظور، انعطاف‌پذيري و حفظ کيفيت است. مطلبي كه در اين مقاله قصد توضيح آن را داريم اين است كه RUP  ساختاري پروسه‌اي (چيو 2000) است كه امكان انعطاف‌پذيري را براي توليد‌كنندگان نرم‌افزار فراهم مي‌آورد.
 RUP متدولوژی ارائه شده توسط شرکت Rational، پرکاربردترین فرآیند تولید و توسعه نرم افزاری در دنیای کنونی است و به عنوان یک استاندارد صنعتی بالفعل در دنیای IT پذیرفته شده است. به گزارش رویتر در سال 2001 میلادی بیش از ششصد هزار شرکت تولید کننده نرم افزار، از ابزارهای شرکت Rational استفاده می کرده‌اند که این تعداد کماکان هم در حال افزایش است. این متدولوژی، برای انواع پروژه‌های نرم‌افزاری در دامنه‌های مختلف ( مانند سیستم‌های اطلاعاتی، سیستم‌های صنعتی، سیستم‌های بلادرنگ، سیستم‌های تعبیه شده، ارتباطات راه دور، سیستم‌های نظامی و ...) و در اندازه‌های متفاوت، از پروژه‌های بسیار کوچک (یک نفر در یک هفته) تا پروژه‌های بسیار بزرگ (چند صد نفر تولید کننده با پراکندگی جغرافیایی)، کاربرد دارد.
 مزیت بزرگ این متدولوژی، استفاده از روش تکرار در تولید و مدیریت تولید نرم‌افزار است که این امر، امکان تولید مبتنی بر کاهش ریسک و مواجه با مشکلات اصلی در ابتدای کار و در نتیجه احتمال موفقیت بیشتر را فراهم می‌کند. از محاسن دیگر این متدولوژی مبنا قرار دادن نرم‌افزار و تولید یک معماری پایدار در ابتدای کار است، که در نتیجه امکان کشف مشکلات عمده ساختاری، تست و مجتمع سازی ممتد را از ابتدای کار فراهم می‌کند.
از دیگر مزایای این روش این است که افراد تیم همزمان با پیشرفت پروژه، مطالب جدیدی فرا می‌گیرند و کیفیت فرآیند تولید نیز به طور مرتب افزایش می‌یابد.
منظور از RUP  چيست؟ در اين تحقیق از چند منظر به RUP خواهيم پرداخت:
    RUP يك پروسه توليد نرم‌افزار است.
    RUP مجموعه‌اي از تجربيات بسيار عالي توليد نرم‌افزار را كه در عمل با آنها برخورد شده است، در خود دارد.
    RUP همانند يك محصول نرم‌افزاري به بازار ارائه شده و به فروش مي‌رسد با اين تفاوت كه RUP اولين ساختار توليد نرم‌افزار را ارائه داده و گام نخست را در اين زمينه برداشته است.
امید داریم که این تحقیق مورد قبول مخاطبانش قرار گیرد.
                                                                      بهار 1387
 
RUP چيست؟

با پيشرفت تكنولوژي‌هاي مرتبط با كامپيوتر، نياز هر چه بيشتر به گسترش علم نرم‌افزاري نيز احساس مي‌شد كه با پيدايش متدولوژيهاي همانند SSADM  و روش آبشاري (چيو 2000) ‎آغاز شد. در ابتدا، اين روشها مناسب بود و جوابگوي نيازهاي آن زمان بودند ولي با افزايش داده‌ها و پيدايش مفاهيمي همچون شبكه، وب و غيره ديگر كارآيي لازم را جهت پياده‌سازي و هدايت پروژه‌هاي نرم‌افزاري نداشتند. پس مفاهيم برنامه‌نويسي شيءگرا پا به عرصه وجود گذاشتند و در سال 1991 بطور جدي مورد مطالعه و بحث قرار گرفتند.
 استفاده از اين روشها و متدهاي برنامه‌نويسي، قدرت و انعطاف بسياري را به برنامه‌ها داد و شركتهاي نرم‌افزاري توانستند با كاهش هزينه‌ها و بهينه‌سازي كدهاي خود، نرم‌افزارهاي قويتري را به بازار عرضه كنند ولي اين روش جديد نيز نياز به مديريت و يكپارچگي داشت. پس روشها و متدولوژيهاي جديدي مطرح شد كه شامل Booch، OMT، OSE و ... مي‌باشند. در سال 2000 شركت Rational روشي را تحت عنوان RUP  مطرح ساخت (گروه كاسميك 2003ب) كه بعد از روش MSF شركت مايكروسافت به دنياي نرم‌افزار عرضه شد و امروزه از طرفداران بسياري برخوردار است.
 فرايند يكپارچه Rational در اصل يك متدولوژي است كه در جهت كنترل و انجام پروژه‌هاي نرم‌افزاري در نظر گرفته شده است. در اصل اين چارچوبي در جهت انجام صحيح و موفق پروژه‌هاي نرم‌افزاري مي‌باشد كه كليه مراحل انجام يك پروژه كه با معماري و آناليز سازمان شروع شده و به تست نرم‌افزار و ارائه Gold Release ختم مي‌شود را در بر مي‌گيرد (گروه كاسميك 2003 الف).
همچنین این فرآیند یک روش نظام‌مند برای تخصیص کارها و مسئولیتها در یک تیم توسعه نرم‌افزار ارائه می‌دهد و هدف آن تولید نرم‌افزار بصورت بهینه و با کیفیت بالاست که بتواند نیازهای کارفرما را تحت یک برنامه زمانی مشخص و با بودجه قابل پیش‌بینی برآورده سازد.
RUP بهره‌وری تیم تولید نرم‌افزار را با فراهم نمودن دسترسی تمام افراد تیم به یک پایگاه دانش سهل‌الوصول به همراه راهنماها، الگوها و ابزارهای کمکی برای همه فعالیت‌های حیاتی توسعه، افزایش می‌دهد. از آنجا که تمام افراد به منابع یکسانی دسترسی دارند، لذا دید مشترکی برای توسعه نرم‌افزار برخوردار هستند.
RUP امکان استفاده موثرتری از زبان یکپارچه مدلسازی (UML) را فراهم می‌سازد (دقت شود که در عین حال RUP و UML کاملاً مستقل از یکدیگر هستند و نباید آنها را با هم یکی فرض کنیم). به کمک تکنیک های RUPبخش‌های عمده‌ای از فرآیند تولید نرم‌افزار به طور خودکار انجام شده و همچنین استفاده از مدل‌های تولید شده در فرآیندهای گذشته در پروژه‌های جاری به سادگی امکان‌پذیر است.
 این فرآیند با موقعیت‌های مختلف تطبیق یافته و برای سازمانهای بزرگ یا حتی کوچک تولید و توسعه نرم‌افزار قابل استفاده است.
RUP کلیه مراحل انجام یک پروژه شامل تحلیل سیستم، برنامه‌ریزی، بررسی ریسکها، تولید و تست نرم‌افزار را در بر می‌گیرد و چهارچوبی در جهت انجام صحیح و موفق پروژه‌های نرم افزاری فراهم می‌سازد.
 چرا RUP را يک فرايند يکپارچه مي‌گويند؟  به سه علت RUP را يكپارچه مي‌نامند:
    از UML در جهت كارهاي خود استفاده مي‌كند. در واقع مي‌توان گفت UML خود ثمره RUP  مي‌باشد و اين خود بسيار خوب است كه متدولوژيي با خودش گسترش يابد .مفاهيمي از قبيل Object، Class و ... مفاهيم ساده و ثابتي هستند ولي قبلاً متدولوژيها علامتهاي خاصي داشتند كه اكنون همه آنها يكسان شده‌اند.
    در داخل RUP يك چارچوب توليد نرم‌افزار است كه ما آنرا براي سازمان و پروژه خود بومي مي‌كنيم و مي‌توان گفت كه در واقع يك قالب فرايند است.
       این فرآیند از ترکیب و یکپارچه‌سازی چند فرآیند و متدولوژی شامل Booch، OMT و OSE دیگر ایجاد شده است.
 
شكل 1 ساختار اصلي RUP را مشخص مي‌كند. اگر در بعد زمان به آن نگاه كنيم شامل 4 فاز مي‌باشد و اگر در هر لحظه به آن نگاه كنيم شامل 9 قالب خواهد بود.

 

            شکل 1. ساختار اصلي RUP
فازهای RUP
در RUP كل فرآيند توليد نرم‌افزار به چهار فاز اصلي تقسيم مي‌شود، كه هر فاز مي‌تواند شامل يك يا چند تكرار باشد. هر فاز شامل مسيري است كه بين دو گردنه (milestone) قرار دارد. اين چهار فاز عبارتند از:
•آغاز (inception)
•جزييات (elaboration)
•ساخت (construction)
•انتقال (transition)
فازآغازین (Inception)
پایه پروژه و ابعاد آن در این مرحله مشخص می‌شوند. در این مرحله پروژه به طور کلی بررسی شده و هزینه و درآمد ناشی از آن محاسبه می‌گردد. در این مرحله برداشتی اجمالی از ابعاد پروژه بدست می‌آید. در انتهای این مرحله تصمیم برای انجام یا عدم انجام پروژه اتخاذ خواهد شد و تعهد لازم از کارفرما تهیه می‌شود.
هدف اصلی این فاز دستیابی به توافق میان كلیه‌ی ذینفعان بر روی اهداف چرخه‌ی حیات پروژه است. فاز Inception به دلیل تلاشهای تولید و توسعه جدید به صورت پایه‌ای اهمیت فراوانی دارد كه در آن ریسك‌های نیازسنجی و تجاری مهمی وجود دارد كه باید پیش از اینكه اجرای پروژه مورد توجه قرار گیرد، بررسی شوند. برای پروژه‌هایی كه بر توسعه سیستم موجود متمركزند، فاز Inception كوتاه تر است، با این حال این فاز برای حصول اطمینان از اینكه پروژه ارزش انجام دادن دارد و امكان‌پذیر نیز هست، انجام می‌شود.
  در اين فاز مدل تجاري سيستم رسم و دورنماي پروژه ترسيم مي‌شود. براي اين كار بايد همه‌ي موجوديت‌هايي كه سيستم با آنها تعامل دارد(بازيگران )شناخته شوند و نحوه تعاملشان با سيستم مشخص گردد.
 اين شامل تعيين همه‌ي موارد كاربرد (use case) و توضيح برخي از موارد مهم است. مدل تجاري شامل شرايط موفقيت، برآورد ريسك‌ها و تخمين منابع مورد نياز است. همچنين يك برنامه‌ي كلي كه زمانبندي مراحل انجام پروژه را نشان دهد.
اهداف فاز آغاز
 • بدست‌ آوردن محدوده نرم‌افزاری پروژه و محدودیت‌های آن كه شامل یك دید عملیاتی، معیار پذیرش و اینكه چه چیز باید در محصول باشد و چه چیز نباید باشد، می‌شود
• مشخص كردن Use-Case های اساسی سیستم، سناریوهای اصلی عملیات كه مسائل مربوط به طراحی اصلی را ایجاد می‌كند.
• نمایش و شاید توضیح حداقل یك معماری كاندیدا برای بعضی سناریوهای اصلی
• برآورد هزینه و زمان كلی برای كل پروژه
 در انتهاي اين فاز اهداف چرخه‌ي حيات پروژه را تعيين مي‌كنيد و تصميم مي‌گيريد كه آنرا ادامه بدهيد يا نه.
 در مجموع هدف اصلي اين فاز بدست آوردن هماهنگي بين تمام افراد درگير با پروژه درباره‌ي اهداف پروژه است. اهداف فرعي ديگرعبارتند از :
•تعيين حدود و دورنماي پروژه
•تعيين موارد كاربرد حيياتي سيستم و سناريور اوليه آنها
•تعيين سناريوهاي جايگزين
•تخمين هزينه و زمان پروژه
•تخمين ريسك‌هاي احتمالي
خروجيهاي فاز آغاز
•سند نماي كلي (vision) : ديد كلي به هسته‌ي اصلي نيازهاي پروژه، قابليت‌هاي كليدي و حدود اصلي
•مدل مورد كاربرد: مشخص كردن همه‌ي موارد كاربردي كه در اين مرحله‌ي مقدماتي مي‌توانند شناسايي شوند
•لغتنامه‌ي اوليه
•مدل تجاري اوليه، شامل زمينه‌ي تجارت، شرايط موفقيت، الزامات تجاري
•تخمين خطاي اوليه
•برنامه‌ي اوليه كه فازها و تكرارها را نشان مي‌دهد.
 فاز جزئيات یا تحلیل پیچیدگی (Elaboration)
  در اين فاز تعريف محصول تصحيح مي‌شود و معماري آن مشخص مي‌گردد. همچنين خلاصه برنامه‌ي توسعه و گسترش محصول تدوين مي‌گردد. در انتهاي اين فاز اهداف و نماي پروژه دقيقتر تعيين مي‌شوند و انتخاب يك معماري و تبيين ريسك‌هاي عمده انجام مي‌گيرد.
  همچنین در این مرحله جزئیات بیشتری از نیازهای سیستم را جمع‌آوری شده و درک بهتری از پروژه صورت می‌پذیرد. بدین ترتیب تحلیل و طراحی سطح بالایی از سیستم صورت گرفته پایه معماری اولیه سیستم بنا می‌شود. در این مرحله نقشه ساخت سیستم تولید شده است.
این مرحله با پرسشهایی نظیر: در حال ساخت چه سیستمی هستیم؟ چه چیزهایی پروژه را به مخاطره می‌اندازد و چه ریسکهایی برای انجام آن وجود دارد. هر چه ریسکها بیشتر و بزرگ‌تر باشند، دقت بیشتری در انجام پروژه باید صورت گیرد.
   اين فاز مهمترين در بين چهار فاز ذكر شده است. فشار كار مهندسي نرم‌افزار در اين فاز است.
  در اين فاز، در يك يا چند تكرار، يك پيش نمونه (prototype) قابل اجرا از معماري سيستم ساخته مي‌شود. تعداد تكرارها بستگي به نما، اندازه، ريسك و جديدبودن پروژه دارد.
بررسی ریسک‌ها
ریسک‌های مرتبط با نیازمندیهای سیستم
هدف رسیدن به سیستمی است که خواسته‌های کاربر را به درستی انجام دهد.
 مهم است که این نیازمندیها به درستی درک شده باشند. در اینجا استفاده صحیح از UML میتواند بسیار موثر باشد.
 یوزکیس‌ها ابزارهای مهمی هستند زیرا تقابل کاربر با سیستم را بطور دقیق مشخص می‌کنند و اساس ارتباط کارفرما با تولیدکننده نرم‌افزار هستند. باید مهم‌ترین و پرخطرترین یوزکیس‌ها به طور مشخص تعیین شوند. هر چه بیشتر با کاربران نهایی سیستم مذاکره شود نتایج بهتری حاصل خواهند گشت. لازم است نمونه‌های اولیه برای قسمت‌های پیچیده و حیاتی یوزکیس‌ها باید ساخته شوند.
در همین زمان سایر نمودارهای مدلسازی نظیر نمودارهای کلاس (Class Diagrams)، نمودارهای فعالیت (Activity Diagram) و نمودارهای تقابل (Interaction Diagrams) نیز به کمک کاربران سیستم بخصوص کاربران ارشد که اطلاعات بیشتر و مهم‌تری از عملکرد سیستم دارند باید تهیه شوند.
 ریسک‌های تکنولوژیکی
از خود می‌پرسیم، آیا تکنولوژی لازم برای ساختن این سیستم را در اختیار داریم؟ باید نمونه‌های اولیه‌ای از سیستم ساخته شده و عملکرد آنها تحت سیستم پیش‌بینی شده بررسی گردد. طراحی معماری سیستم در این مرحله صورت می‌گیرد. باید اجزا تشکیل دهنده سیستم، روش ساخت یا تهیه و طریقه اتصال آنها به یکدیگر مشخص شوند. بهتر از قسمت‌هایی که تغییر آنها سخت‌تر (یا غیرممکن) است در این فاز مدنظر قرار گرفته شوند تا در صورت عدم هماهنگی در همین مرحله تصمیمات مناسب اتخاذ شوند.طراحی سیستم باید بگونه‌ای باشد که در آینده تغییرات و توسعه آن قابل انجام باشد. باید یوزکیس‌ها را بطور دقیق بررسی کنیم تا مسائلی که ممکن است طراحی سیستم را پیچیده‌تر کنند به طور واضح مشخص گردند.
نمودارهای UMLزیر در این مرحله بکار می‌آیند:
•    نمودارهای کلاس و نمودارهای تقابل: اجزاء سیستم (Components) و نحوه تقابل آنها را نشان می‌دهند.
•    نمودارهای بسته بندی (Package Diagrams): یک دید سطح بالا از اجزاء سیستم فراهم می‌آورند.
•    نمودارهای گسترش (Deployment Diagrams): تصویری از چگونگی توزیع (پراکندگی) اجزاء سیستم نشان می‌دهند.
 ریسک‌های منابع انسانی
برخی اشتباهات برنامه‌نویسان به سختی قابل کشف و حل هستند و رفع آنها مستلزم صرف وقت و هزینه بالایی است .
 آموزش نقش مهمی در این راستا بازی می‌کند چرا که پیشگیری بهتر از درمان است. اگر این امکان فراهم شود که برخی از اعضاء که در مراحل تولید پروژه‌های مهم‌تر نقش داشته‌اند و تجربه بیشتری دارند، هر چند برای مدتی کوتاه در پروژه همکاری کنند ریسک مشکلات ناشی از نیروی انسانی تا حد زیادی کاهش خواهد یافت.
 ریسک‌های سیاسی
هرچند در نگاه اول ممکن است عجیب به نظر برسد، ولی با رشد روزافزون رایانه‌ها و سیستم‌های مبتنی بر رایانه امکان بروز تعارض میان سیستم نرم‌افزاری ساخته شده و مسائل امنیتی وجود دارد. بهتر است در مورد یوزکیس‌هایی که با مردم جامعه یا سازمانها (بخصوص سازمانهای دولتی) تعامل خواهند داشت در همین مرحله سیاستهای واضحی مشخص گردد.








انجام پایان نامه

انجام پایان نامه کامپیوتر، انجام پایان نامه ارشد کامپیوتر، انجام پایان نامه، پایان نامه

برای دیدن ادامه مطلب از لینک زیر استفاده نمایید

 

سفارش پایان نامه