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

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

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

|

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

 پایان نامه

 پایان نامه | پایان نامه مهندسی نرم افزار و روشهای آن


RUP
Rational Unified Process
فهرست مطالب

عنوان                                         صفحه
فصل اول
مهندسی نرم افزار و روشهای آن                        7
1-1 مهندسی نرم افزارچیست ؟                            7    
2-1 ساخت یافتگی ومهندسی نرم افزارساخت یافته                    7
3-1 شیء گرایی ومهندسی نرم افزار شیء گرا                    8
4-1 معرفی Unified Modeling Language                8
5-1 تصورات غلط دررابطه با Rational Unified Process            9
فصل دوم
مقدمه ای بر( RUP)RationalUnified Process                11    
1-2 RUP چیست ؟                                11
2-2 اصول ضروری RationalUnified Process                11
3-2 RUP وچرخه تکرار                            12
4-2 فازها، اهداف ونکات اصلی                             14
- فازشروع ( Inception )                            14
- فازشناخت ( Elaboration )                            15
- فازساخت (Constructin)                            15
- فازانتقال ( Transition )                            15
5-2 نکات اصلی                                    15
- چهارعنصراصلی مدل سازی                               15
6-2 نقش ها، فعالیت ها ومحصولات وجریان های کاری                           16
- نقش ها(Roles )                                     16
- فعالیت ها(Activites)                                 16
- محصولات (Artifacts )                                  17
- جریان های کاری (Workflows )                              17
7-2 عناصردیگرموجود در RUP                                  17
8-2 ساختارایستای RUP                                  18     
9-2 اصول RUP (جریان کاری )                                 18
10-2 تعریف کلی RUP                                            19
11-2 چگونه می توان از RUPنهایت استفاده راکرد                     19
12-2 مواردضروری دریک پروژه RUP                           20
1-12-2 توسعه دید ونگرش                                20
2-12-2 مدیریت برای اهداف                                        21
3-12-2 شناسایی وامکان سنجی ریسک ها                       22
4-12-2 عوامل مورد پیگیری                               22
5-12-2 امتحان کردن حالت تجاری                          22
6-12-2 طراحی معماری قطعات سیستم                            23
7-12-2 مراحل ساخت وآزمایش محصول                           24
8-12-2 تصحیح وبازبینی نتیجه ها                          24
9-12-2 مدیریت وکنترل تغییرات                          24
10-12-2 مهیا کردن پشتیبانی ازکاربر                          25
13-2 چرخه اصلی  Rational Unified Process                25
1-13-2 تصورغلط                                 25
2-13-2 نکته مهم                                 26
3-13-2 جریان های کاری غیرثابت                         27
فصل سوم    
فازهای RUP                                 28
1-3 مقدمه                                     28
2-3 فاز  Inception                                28
1-2-3 فعالیت های لازم وضروری درفاز Inception                        29
2-2-3 حیاتی ترین نکات (گلوگاه ها) درچرخۀ حیات  Inception                  30
3-2-3- ارزیابی معیارها وضوابط                                    30
4-2-3 خروجی های الزامی فاز  Inception                    31
5-2-3 طرح توسعه نرم افزار (Software Development Plan )        31
6-2-3 خروجی های اختیاری فاز  Inception                           33
3-3 فاز  Elaboration                            33
1-3-3 فعالیت های ضروری درفاز  Elaboration                34
2-3-3 ساختارچرخه حیات فاز Elaboration                            35
3-3-3 ارزیابی معیارها                                        35
4-3-3 محصولات وخروجی های الزامی این فاز                           36
5-3-3 خروجی های اختیاری این فاز                               38
4-3 فازساخت   Construction                              39
1-4-3 ذهنیت مقدماتی ازفاز  Constructin                         39
2-4-3 فعالیت های ضروری درفاز Constructin                 40
3-4-3 نکات مهم درفاز Constructin                        40   
4-4-3 معیارارزیابی                                 40
5-4-3 خروجی های الزامی فاز Constructin                           41
6-4-3 خروجی های اختیاری فاز Constructin                   42
5-3 فاز انتقال Transition                            42
1-5-3 فعالیت های ضروری فاز Transition                    44
2-5-3  ارزیابی معیارها                                44
3-5-3  خروجی های فاز Transition                         45
منابع و مأخذ                                     47
 
چکیده
با توجه به نیاز روز افزون به استفاده از کامپیوتر و ضرورت توسعه و فراگیری علوم و فنون مربوط به آن به ویژه در زمینه مهندسی نرم افزار و با توجه به فقدان مطالب  و منابع در این زمینه، بر آن شدیم تا گامی هرچند کوچک اما سازنده در این زمینه برداریم. مطالبی که پیش روی دارید حاصل تحقیقات مطالعات و گردآوری نکات مهم و اساسی در زمینه توسعه مهندسی نرم افزار به روش RUP می باشد. امید است که حاصل تلاش مان موثر و مفید واقع شود.



 
فصل اول
مهندسی نرم افزار وروش های آن
1-1 مهندسی نرم افزار چیست ؟
مهندسی نرم افزار، مدیریت برای به نظم درآوردن وقاعده مند نمودن وابستگی ها وارتباطات همه جنبه های محصول نرم افزاری که درتمامی مراحل سیستم شنا سایی وتعیین می گردد ، می باشد .
درواقع مهندسی نرم افزارفرایند تولید نرم افزار براساس فهم مسائل ومشکلات ، دستیابی به راه حل ها ودستیابی به تئوریها ، روش ها وابزارهای مورد نیاز ودرانتها رسیدن به هدف مطلوب می باشد .
مهندسی نرم افزارباید درطول ساخت ، نگهداری توسعه وانفصال یک نرم افزار برهمه عملکردها نظارت داشته باشد .
2-1 ساخت یافتگی ومهندسی نرم افزارساخت یافته
در رهیافت طراحی نرم افزار بر اساس روش ساحت یافته، ابتدا به مسئله در حالت کلی نگاه می شود، آنگاه مسئله به قسمت های کوچکتر شکسته می شود، این کار آنقدر تکرار می گردد تا مسائل خرد شده به اندازه کافی قابل فهم و ساده باشند. این مراحل  به تجزیه عملیاتی معروف است. بیشتر اجزاء (توابع) در این روش نیاز به داده ها دارند که در سیستم عملیات در بانک های اطلاعاتی نگهداری می شوند. در واقع در این روش داده ها و توابع عملیاتی از هم تفکیک می گردند. پس از حل مسائل کوچکتر و ترکیب آنها با هم، مسئله اصلی قال حل خواهد بود.
مشکل اساسی در این رهیافت این است که اگر مسائل پیچیده باشد، سیستم در نگهداری اطلاعات با مشکل مواجه می شود. اگر در این سیستم ها نیاز باشد که تغییری صورت گیرد، این تغییر در مکان های زیادی باید اعمال گردد. در این صورت مشکلات تقریباً بزرگی به وجود می آید.
مهندسی نرم افزار ساخت یافته نیز بر اصول ذکر شده فوق مبتنی است. از جمله متدلوژی های مهندسی نرم افزار می توان به دو روش
( (structured Systems Analysis & Design Method  SSADM روش تحلیل و طراحی سیستم های ساخت یافته و (Jackson System Development)    JSD توسعه سیستم جکسون، اشاره نمود.
3-1 شی ء گرایی و مهندسی نرم افزار شیء گرا  
از دید شیء گرایی داده ها و توابع به هم  مرتبط  هستند  و  در  یک  ماژول  قرار  می گیرند. در واقع هریک از این ماژول ها که مجموعه داده ها و توابع هستند که شیء نامیده می شوند. اشیاء در دنیای واقعی نیز می توانند به وسیله دو چیز مشخص گردند (مشخصه و رفتار).
اصول بنیادی که در شیء گرایی با آن مواجه هستیم، اشیاء، کلاس ها و وراثت می باشند. ایده شیء گرایی نیز به دنیای مهندسی نرم افزار راه یافته است و بر این اساس روش های مختلف مهندسی نرم افزار به وجود آمده است. که از آن جمله می توان به موارد ذیل اشاره نمود :
-  (object Modeling Technique) OMT
- (Real – time Object – Oriented Modeling ) ROOM
-Object – Oriented  Software Engineering ) OOSE)
-(Unified Modeling Language) UML
بدلیل آنکه از UML در مراحل توسعه نرم افزار (RUP) استفاده می گردد، در این قسمت جا دارد که در مورد UML توضیحات بیشتری بدهیم.
4-1 معرفی Unified Modeling Language
در میانه دهه نود، سه روش وجود داشت که از بقیه قویتر به نظر می رسید. این سه زبان که شروع به همگرایی کرده بودند، هریک دارای عناصری از دو روش دیگر نیز بود و دارای توانایی های منحصر بفردی نیز بودند :
-    Booch برای طراحی و پیاده سازی عالی به نظر می رسید. گرچه روش بوچ خیلی قوی بود ولی علائم زبان به سختی درک می شد.
-    OMT (تکنیک مدل سازی اشیاء) برای تجزیه و تحلیل بسیار عالی بود و بهترین روش برای سیستم های اطلاعاتی دارای داده های حساس به نظر می رسید.
-    OOSE (مهندسی نرم افزار به روش شیء گرا)  به عنوان یک مزیت به مدل Use Case معروف است. Use Case تکنیک توانمندی برای درک رفتار کل سیستم هستند. (محدوده ای که شیء گرایی به طور سنتی در آن ضعیف بود)
     در سال 1994 Gim Rumbaugh تاسیس کننده OMT و در سال 1995 Ivar Jacobson بنیانگذار OOSE هم به گروه Booch در شرکت Rational پیوست. بدین ترتیب گروه سه نفر بوچ ، رامبو و جاکوبسن مدل یکپارچه UML را به وجود آوردند.
UML یک  زبان  استاندارد برای مدل سازی اشیاء در توسعه سیستم های شی ء گرا می باشد. UML از ترکیب و اتحاد سه متدلوژی و طراحی شیء گرای فوق به وجود آمده است.
هدف اصلی UML ایجاد یک زبان مشترک برای مهندسان و تولیدکنندگان نرم افزار در تحلیل و طراحی سیستم های شیء گراست.
5-1 تصورات غلط در رابطه با Rational Unified Process
علی رغم آنکه اغلب افراد تصور می کنند RUP یک متدلوژی و یا روش مهندسی نرم افزار است، باید اظهار داشت که این تصور و برداشت کاملاً نادرست می باشد.
RUP  خود یک مدل از مهندسی نرم افزار است که بر تکرار و توسعه استوار است و هریک از متدها می تواند در قالب این مدل تکرار و توسعه نقش بگیرد. چنانچه قبلاً اظهار شد UML به  عنوان  زبان  یکپارچه  ساز و روشی شی ء گرا در مدل RUP استفاده می گردد. در واقع RUP استفاده می گردد. در واقع RUP رویکردها، وظایف و مسئولیت ها را در یک سازمان توسعه یافته نظام دهی می کند و هدف آن تضمین تولید محصول نرم افزاری خروجی با کیفیت بالا و منطبق بر نیازمندی های کاربران در زمان و هزینه پیش بینی شده می باشد. در واقع RUP پروسه تولید است و توسط شرکت نرم افزاری Rational پشتیبانی می گردد.
 
فصل دوم

مقدمه ای بر Rational Unified Process(RUP)
1-2- RUP چیست؟
با پرسیدن این سوال، بنابر اینکه چه کسی و در چه موقعیتی می باشد، پاسخ های متفاوتی خواهید شنید. RUP دارای سه مشخصه بارز می باشد، که عبارتند از :
•    RUP عاملی است برای  توسعه  نرم افزار  که  دارای  تکرار  معماری و Use case می باشد و بهترین منبع در ارتباط با RUP خود نرم افزار Rational Rose می باشد که شامل راهنما، مثال و ... می باشد.
•    RUP  یک فرآیند مهندسی نرم افزار خوش ساختار و خوش تعریف می باشد. و به وضوح معین می کند که چه کسی مسئول چه کاری می باشد و چگونه و در چه زمانی مسئولیت خود را باید انجام دهد به کمک RUP مراحل مهم پروژه و نکات اصلی به سرعت شناخته می شود.
•    RUP یک فرآیند تولید است که به شما امکان تغییرات دلخواه و منطقی را می دهد. RUP  شامل فرآیندهای گوناگونی است و با تنظیمات RUP می توان تیم های بزرگ  و  یا کوچک را توسعه داد. RUP افراد ذیل را در انجام پروژه ها یاری می کند :
الف) تحلیل گران Analysts
ب) توسعه دهندگان Developer
پ) تست کنندگان Testers
ت) مدیران پروژه و اعضای دیگر تیم   project Managers
2-2 اصول ضروری Rational Unified Process
• بر مشکلات غلبه کنید و در غیر این صورت آنها بر شما غلبه خواهند کرد.
• مطمئن شوید که شما ارزش ها را به مشتریان می فهمانید.
• به نرم افزارهای اجرایی توجه کنید.
• تغییرات را با پروژه وفق دهید.
• یک معماری ثابت بنا کنید.
• پروژه را به اجزای مختلف ( Componets) تبدیل کنید.
• همه با هم یک تیم را تشکیل دهید.
• کیفیت را برای همیشه بخواهید و نه برای یک لحظه
3-2 RUP  و چرخه تکرار
امروزه تیم های نرم افزاری نیز وجود دارند که از روش آبشاری (waterfall) استفاده می کنند، بدین معنا که در هر مرحله ترکیبی از نیازمندی ها را تشخیص می دهند، سپس آن ها را تجزیه و تحلیل ، طراحی و بعد پیاده سازی و در نهایت آزمایش می کنند و یا از روش  رایج تر  که  همان  روش  آبشاری است ولی با بازخورد (feedback) استفاده می کنند. در این روش ممکن است با کناره گیری یک عضو از تیم خسارت هایی به سیستم وارد شود.
برخلاف سیستم های فوق، RUP از روش تکرار ( Iterative) استفاده می کند، که به معنای یکسری گام ها برای رسیدن به هدف می باشد و هر تکرار ) Iteration ) شامل اصول توسعه (نیازمندی Requirements ، تحلیل Analysis طراحی Design پیاده سازی Implementation و ...) می باشد در تصویر زیر این مفاهیم را مشاهده می کنید :

 

هر Iteration بر اساس عملکرد Iteration قبلی عمل می کند و لذا در هر مرحله و با جلو رفتن، پروژه اصلاح می شود، تا آنکه نسخه نهاییت سیستم ارائه شود.
Iteration های اولیه بیشتر تأکید بر روی نیازمندی ها (Requirements) ، تحلیل  (Analysis) و طراحی Design) ) دارند و Iteration  های بعدی اصرار بیشتری بر روی پیاده سازی Implementation)) و آزمایش Testing) ) دارند.
با توجه به مطالب ذکر شده این سئوال به وجود می آید که به چه علت روش Iterative بهتر از Waterfall است؟ بعضی از این علت ها عبارتند از :
-    تطبیق تغییرات با نیازمندی ها
تغییرات و معایب موجود در تکنولوژی روز از منابع اصلی مشکلات پروژه می باشد که باعث می شود بجای آن که به تیم و اجرایی بودن نرم افزار توجه شود، در طی گذشت چند هفته به این معایب توجه گردد.
- ایجاد اتحاد و یکپارچگی در ابتدای پروژه نه در لحظات آخر
بدون توجه به نتیجه های بدست آمده از تلاش هر گروه، در لحظات آخر هر پروژه زمان زیادی تا حدود 40 درصد تلف می شود تا آن یکپارچگی لازم اتخاذ شود. برای اجتناب از این موضوع می بایستی Iteration ها را به قسمت های کوچکتر تقسیم کرد و نتایج را گام به گام به یکدیگر متصل نمود.
-    مشکلات معمولاً کشف می شوند.
بعد از آن که پروژه را به Iteration های کوچکتر تقسیم گردید، لذا با توجه به داشتن افراد در هر قسمت به سرعت می توانید مشکلات را در همان اوایل کشف نمایید.
مدیریت به معنای ایجاد تغییرات تاکتیکی در محصول است
بعد از انجام هر Iteration به سرعت شما می توانید یک معماری قابل اجرا را پیاده سازی کنید نسخه های اولیه سریعاً تهیه و قابل اجرا خواهند بود.
تیم فرصت پیشرفت دارد
اعضای پروژه فرصت های فراوانی دارند تا بتوانند از اشتباهات خود عبرت بگیرند و به مهارت های خود بیافزایند.
RUP یک فرآیند مهندسی نرم افزاری است
در طراحی خود RUP از تکنیک های طراحی نرم افزار استفاده شده است. به ویژه توسط فرآیند مهندسی متا مدل نرم افزاری برای تهیه آن، استفاده شده است و کاملاً بر پایه UML است.
Software Process Engineering  Metamodel (SPEM)
Unified Modeling language (UML)
 
4-2 فازها، اهداف و نکات اصلی
فاز شروع (Inception)
اهداف :
الف ) شناخت حوضه و قلمرو پروژه
ب) ساخت حالت تجاری (Business Cases)
- فاز شناخت (Elaboration)
اهداف :
الف) کاهش خطرات تکنیکی
ب) ساخت معماری پایه سیستم
پ) فهم نحوه ساخت سیستم
نکته اصلی : مهماری پروژه LCA ( Lifecycle Architecture Milestone)
فاز ساخت (  (Construction
هدف :
الف) ساخت اولین نسخه عملیاتی
فاز انتقال (Transition)
هدف :
الف) ساخت نسخه نهایی و انتقال به مشتریان
5-2 نکات اصلی
ساختار ایستایی RUP
ساختار ایستا در نحوه کنار یکدیگر قرار گرفتن منطقی فعالیت ها (Activity) ، اصول  Disciplines)) ، محصولات(Artifacts) و نقش ها Roles) ( دخالت دارد. در واقع در این پروسه معین می شود که ، چه کسی، چه کاری را چگونه و در  چه  زمانی  انجام  می دهد.  در  RUP از چهار عنصر مدل سازی استفاده می شود.
چهار عنصر اصلی مدل سازان
•    نقش ها (Roles) : چه کسی؟
•    فعالیت ها (Activities) :   چگونه عمل می کند؟
•    محصولات )َArtifacts) : چه چیزی را ؟
•    جریان کار (Workflows) : در چه زمان؟
6-2 نقش ها، فعالیت ها و محصولات و جریان های کاری
- نقش ها Roles))
یک نقشه کاملاً شبیه به یک کلاه است که ممکن است یک نفر و یا گروهی از آن استفاده کنند. در RUP نقش ها معین کننده وظایف فردها هستند و این نقش ها هستند که گویای وظایف افراد هستند. یک شخص معمولاً یک یا چند نقش دارد و تعدادی از افراد فقط یک نقش دارند.
فعالیت ها (Activities)
یک فعالیت   از  نقش  خاص ،  به عنوان یک واحد کاری مستقل برای انجام آن عملیات می باشد. معمولاً یک فعالیت هدف کاملاً واضحی دارد و هر فعالیت به یک نقش نسبت داده می شود و یک فعالیت به طور کلی در چند ساعت تا چند روز به طول می انجامد و معمولاً شامل یک نفر است و معمولاًَ روی یک و یا چند محصول تأثیر می گذارد، ممکن است یک فعالیت خاص چندین بار برای یک محصول خاص اتفاق بیافتد، بویژه اگر از یک Iteration به Iteration دیگری برویم و یا سیستم را توسط همان نقش اصلاح و یا توسعه دهیم، اما لزوماً این کار برعهده همان شخص قبلی نیست، فعالیت ها به چند گام تقسیم شده اند که عبارتند از :
•    فکر کردن باید فرد مجری نقش ، وظایف خود را درک کند. و بر اساس محصولات ورودی ، خروجی ها را تنظیم نماید.
•    انجام کار، که محصولات را ایجاد یا اصلاح می کند.
•    مرور، نتایج موجود برای نقش خاص، بازبینی می گردد.
محصولات ( Artifacts)
یک محصول قطعه اطلاعاتی است که تولید، اصلاح یا استفاده شده است. محصولات عناصر قابل لمس و حیاتی پروژه هستند. محصولات توسط نقش ها شروع به ایجاد شدن می نمایند و نتایج را بصورت خروجی به فعالیت های دیگری می دهند.
محصولات ممکن است حالات گوناگونی داشته باشند، که عبارتند از :
الف) یک مدل، مثل مدل  Use case یا Design
ب) یک عنصر مدل، مثل کلاس Use case (UC)    یا زیر سیستم
پ) یک مستند، مثل Vision یا Business
ت) اصل برنامه
ث ) موارد اجرای مثل Prototype
- جریان های کاری (Workflows )
علی رغم وجود نقش ها، فعالیت ها و محصولات، شما به مورد دیگری نیز، نیاز خواهید داشت، شما باید بتوانید نتایجی مناسب و ارزشمند برای نقش ها ایجاد کنید که این همان معنای جریان کاری (Workflow ) است.
جریان های کاری در طرح ها و اشکال مختلف هستند، که رایج ترین آن ها اصول (Discpline)  است که از سطح بالایی جریان های کاری می باشند، جزئیات کاری نیز به همراه این اصول هستند. در UML برای نمایش جریان کاری می توان از سه دیاگرام زیر استفاده کرد:
الف) دیاگرام    Sequencd
ب) دیاگرام    Collaboration
ج) دیاگرام     Activity
7-2 عناصر دیگر موجودRUP
 نقش ها، فعالیت ها و محصولات از اصلی ترین ساختار لیست RUP هستند. اما عناصر دیگری نیز وجود دارد که به فهم بیشتر کمک می کنند. این عناصر اشافه شده عبارتند از :
•    راهنما (Guideline ) : برای آن که بتوان از نقش ها، نظریه ها یا ابتکارها پشتیبانی کرد، نیاز به این عنصر می باشد.
•    قالب ها  Templates)) : برای هر محصول یک قالب نمونه وجود دارد.
•    ابزار راهنما (Tool mentors) : برای ایجاد ارتباط بین راهنما Guidelines) ) و ابزار توسعه از این عنصر استفاده می شود.
•    مفاهیم (Concepts) : برای معرفی نکات کلیدی و اصولی استفاده می شود.
•    نقشه (Roadmaps) : جهت نمایش حرکت کاری در RUP استفاده می شود.
در نهایت ، در تمامی عناصر گفته شده، (نقش ها، فعالیت ها، محصولات ، مفاهیم ، راهنما و قالب ها) بصورت منطقی در کنار یکدیگر قرار می گیرند و به نام اصول (Disciplines) شناخته می شوند. در RUP اصول استاندارد وجود دارد. ولی ممکن است یک شرکتی بنابر موقعیت ها اصولی را نیز به سیستم اضافه کند.
8-2 ساختار ایستایی RUP
در ساختار ایستاییRUP ،  فعالیت ها،  قوانین  یا  اصول RUP)) و محصولات در جریان های کاری جای دارند.
9-2 اصول RUP (جریان های کاری)
- مدل سازی تجاری             Business Modeling
- نیازمندی ها                Requirements
- تحلیل و طراحی                Analysis and Design
- پیاده سازی                Implementation
- توسعه                    Deployment
- تست                     Test
- مدیریت تغییرات و تنظیمات        Configuration and change managemen
- مدیریت پروژه                Management   Project
- محیط                  Enviroment

10 – 2 تعریف کلی RUP
•    RUP یک نرم افزار است برای توسعه پروژه ها
• RUP یک نرم افزار مهندسی است.
• RUP فرآیند تولید محصول است.
11 – 2 چگونه می توان RUP نهایت استفاده را کرد
برای آنکه از RUP بتوانیم نهایت استفاده را نماییم، لازم است تا موضوعات کلیدی آن را درک نماییم و بدانیم که چرا هر کدام از موارد اهمیت خاصی دارد و در مجموع با یکدیگر چگونه به یاری تیم توسعه سیستم می آیند و چگونه می توان Stakeholder (صاحبان اصلی پروژه) را  راضی تر نگه داشت.
اغلب، چنین سئوالاتی پرسیدهن می شود:
« چه مواردی در پروژه ما ضرورت بیشتری دارد؟»
« RUP برای پروژه های بزرگ است، می توان در پروژه های کوچک نیز از آن استفاده کرد؟»
تمام چیزهایی که احتیاج این پرسشگران است، در ده مورد خلاصه می شود.
توجه کنید! نیازهای مدیریت (یا use case ها اندازه پروژه ها، پیکره بندی مدیریت، یا استفاده از ابزار ناقص یا جلسات ارزیابی) از سرعت کار کم می کند!
با استفاده از این موارد ضروری که ذکر خواهیم کرد دید اعضای سیستم را به دید سیستمی نزدیک می کنیم ، به این ترتیب در معماری اولیه پروژه، اعضای تیم متوجه نقاط حیاتی سیستم و نیازمندی های آن خواهند شد. از همه مهم تر مشکلات سیستم را می توانند اولویت بندی نمایند.
12-2 موارد ضروری در یک پروژه RUP
1- توسعه دید و نگرش
2- مدیریت برای هدف
3- شناسایی و امکان سنجی ریسک ها
4- عوامل مورد پیگیری
5- امتحان کردم حالت تجاری
6- طراحی معماری قطعات سیستم
7- مراحل ساخت و آزمایش محصول
8- تصحیح و باز بینی نتیجه ها
9- مدیریت و کنترل تغییرات
10- مهیا کردن پشتیبانی از کاربر
1-12-2 توسعه دید و نگرش
دارا بودن دید  باز ، یک امتیاز برای توسعه احتیاجات خود در مقابل Stakeholder می باشد Stakeholder به افرادی گفته می شود که از عاملین پروژه هستند). توسعه دید و نگرش، اساس نیازهای جریان کاری را در     RUP معین می سازد، همچون تحلیل مسئله، فهمیدن خواسته های Stakeholder ، تعریف سیستم و مدیریت نیازها.
نحوه دید به سیستم گاهی اوقات مهیا کننده یک سطح بسیار بالا خواهد بود، به این معنا که به محض دریافت تقاضا به راحتی می توان سیستم را پیاده سازی کرد.
در این قسمت با طراحی Constraint ها (نقاط مسئله ساز) این فرصت را برای توسعه سیستم مهیا می کنیم و همچنین ورودی های تجاری را شناسایی می کنیم و بالاخره آنکه دید و یا نگرش (Vision) بر پایه چراها و چه چیزهایی پروژه می باشد. برای ساختن دید باید به سوالات زیر با جزئیات بیشتر پرداخت.
•    کلیدهای اصلی پروژه چه چیزهایی هستند؟ (Glossary)
•    به دنبال حل چه مسائلی هستیم؟ ( Problem Statement)
•    Stakeholder چه کسانی هستند؟ کاربران چه کسانی هستند؟ نیازهای آنها به ترتیب چیست؟
•    خصیصه های محصول چه خواهد بود؟
•    نیازهای اجرایی کدامند ؟ (Use Case)
•    نیازهای غیر – اجرایی کدامند؟
•    نقاط مسئله ساز کدامند؟
2-12-2 مدیریت برای هدف
خوبی یک محصول بستگی به خوبی هدف دارد.
در PUR ، SDP (Software Development Plan ) تمام اطلاعات لازم را برای مدیریت پروژه جمع آوری می کند و ممکن است به تعدادی موارد اشاره کنند که در فاز شناخت Inception توسعه داده شوند. این موارد تا انتهای پروژه باید نگهداری و بروز رسانی شوند.
SDP زمانبندی پروژه و نیاز به منابع را تعریف می کند و تا انتهای پروژه این زمان بندی استفاده خواهد شد. SDP، زمان بندی پروژه ، مدیریت نیازهای هدف، مدیریت پیکره بندی هدف، حل  مسئله هدف، تست هدف، تست حالت ها، ارزیابی هدف و تأیید محصول هدف را در بر می گیرد.
در یک پروژه ساده، تمام این ضرورت ها در یک یا دو جمله خلاصه شده است، یک مدیریت پیکره بندی هدف به این حالت خلاصه می شود : « در انتهای هر روز، محتویات فایل های پروژه باید Zip شود و در دیسک های دیگری ذخیره و در مکانی نگهداری شود.»
3-12-2 شناسایی و امکان سنجی ریسک ها
ضروری ترین امر   RUP شناسایی ریسک ها در اوایل پروژه می باشد. هر ریسک که توسط تیم پروژه شناسایی می شود، باید یک هدف مربوط داشته باشد، یعنی ریسک مورد نظر باید هر و ابزار برنامه ریزی و پایه های شناسایی را در برداشته باشد.
4-12-2 عوامل مورد پیگیری
تحلیل ادامه وار از داده ها مستقیماً از فعالیت های مهم در پروژ] مشتق می شود. در RUP ، وضعیت ارزیابی منظم مهیا کننده مکانیزمی برای آدرس دهی، ارتباطات و مدیریت عملکرد، عملکردهای تکنیکی و ریسک های پروژه می باشد.
هنگامی که تیم مورد نظر موانع را شناسایی نمودند. باید یک شخص را معین کرد و سپس به او مهلتی داد تا بتواند آن مسئله را حل و فصل نماید. به طور منظم باید سیستم کنترل شود و به روز رسانی ها در هر زمانی که لازم است اید انجام شود. موارد گفته شده احتیاج به توجه بیشتری دارد؛ یعنی در گذشت زمان این حالات مدیریتی نیز تغییر می کند.
5-12-2 امتحان کردن حالت تجاری
در حالت تجاری پروژه، اطلااعاتی جمع آوری می شود تا معین شود که آیا پروژه ارزش سرمایه گذاری را دارد یا خیر؟ در ضمن حالت تجاری در توسعه اهداف اقتصادی و بهتر فهمیدن دید و نگرش پروژه کمک شایانی می کند. همچنین توجه خاصی را برای پروژه مهیا می کند و بنیانگذار مسائل اقتصادی خواهد شد. با گسترش پروژه ، تحلیل گران از حالت تجاری برای تعیین سود و خروجی سرمایه گذاری Return On Inyestment ) ) استفاده می نمایند.
ترجیحاً کاوش به صورت عمقی در مسائل مشخص باعث می شود تا حالت تجاری به صورت خلاصه تر در آید اما به صورتی که تمام اعضای تیم بتوانند به راحتی آن را درک کنند و به یاد داشته باشند . در نقاط بحرانی تحلیل، مدیران باید با استفاده از حالت  تجاری قیمت های واقعی را پیدا کنند و تصمیم بگیرند که آیا پروژه را ادامه دهند یا خیر؟


6-12-2 طراحی معماری قطعات سیستم
در Rational Unified Process معماری سیستم نرم افزار به عنوان سازمان و یا ساختار قطعات سیستم مشخص تعریف شده است. بنابراین این سؤالات مطرح می گردد که قطعات اصلی چیست و چگونه در کنار یکدیگر قرار می گیرند؟
RUP مهیا کننده یک راه  برای  طراحی  به  صورت  سیستماتیک  و  توسعه معماری  می باشد و گام هایی که در جریان کاری طراحی و تحلیل  Analysis and Design Workflow) )  می باشند عبارتند از :
-    تعریف معماری مشخص
-    تصحیح معماری
-    تحلیل رفتارها
-    طراحی قطعات سیستم
برای صحبت در ارتباط با معماری نرم افزار، باید اول نمایی از معماری ساخته شود که در آن درباره ابعاد مهم سیستم صحبت شده باشد. در RUP این مسئله در قسمت  Architecture Document  Software  آماده می شود که ابعاد مختلف معماری را در خود گنجانده است. در هر قسمت از این معمای افراد خاصی دارای وظیفه خواهند بود مثل : کاربران نهایی، طراحان، مدیران، مهندسین سیستم، Admin های سیستم و ...


پایان نامه

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

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

نقشه