مروری بر متدولوژي RUP

1. مروري بر متدولوژي RUP : 1.1. متدولوژي ادبيات تخصصي تجزيه و تحليل و طراحي سيستم ها، هنوز به آن حدي از بلوغ نرسيده است كه واژگان اساسي آن مفاهيم يكساني در نزد دست اندركاران اين رشته داشته باشد. يكي از مشكلات كساني كه به متون طراحي سيستم ها مراجعه مي كنند، آن است كه معناي واژ ه هاي كليدي اين رشته، از متني به متن ديگر تغيير مي يابد. آنچه كه نويسنده اي متدولوژي مي داند، نويسنده ديگر متد )روش (مي نامد و آنچه كه يكي به عنوان روش از آن نام مي برد، ديگري تنها آن را ابزار مي شناسد. "متدولوژي" مجموعه اي از روشها، فنون و ابزارهاي تحليل و طراحي سيستم است كه در چهارچوب يك انگاره مدلسازي مبتني بر يك الگوي مفهومي براي ساماندهي روند توسعه سيستمها به روشي نظام مند به كار بسته مي شود. نمونه اي از متدولوژي هايي كه استفاده مي شوند، از اين قرار مي باشد: 1.1.1. متدولوژي هاي پردازش مدار (Process-Oriented) : · طراحي ساخت يافته SD‌ ( روش Yourdon-Constantine ) · تحليل ساخت يافته SA ( روش DeMarco ) · تحليل ساخت يافته SA (روش Gane-Sarson ) · روش YSM (Yourdon System Method ) 1.1.2. متدولوژي هاي داده مدار (Data-Oriented) : · مهندسي اطلاعات Information Engineering (روش martin ) · روشهاي طراحي شئ گرا OOD ( Object-Oriented Design ) · روش جكسون JSD ( Jackson System Of Design ) · روش وارنير-اور ( Warnier-Orr ) · متدولوژي BSP ( Business System Planing ) 1.1.3. روشهاي نمونه سازي (Prototyping) · روش توسعه سريع RAD · روش توسعه مشاركتي JAD 1.2. شئ گرايي 1.2.1. مقدمه شيء گرايي لغتي است كه امروزه در صنعت نرم افزار باب شده است. شركتها به سرعت حركت مي كنند تا خود را با اين تكنولوژي جديد سازگار كنند و آن را در برنامه هاي موجود خود وارد نمايند در حقيقت بيشتر برنامه ها امروزه با شي گرايي توسعه مي يابند، اما شئ گرايي به چه معنا است؟ متد شئ گرايي (O.O ) يك راه متفاوت مشاهده برنامه هاست. با شئ گرايي شما يك برنامه را به قطعات بسيار كوچك يا Object هايي تقسيم مي كنيد كه تا اندازه اي مستقل از يكديگر باشند. تفاوت متد شئ گرايي با روش سنتي توسعه چيست؟ در روش سنتي، روش توسعه به همراه اطلاعاتي كه سيستم نگهداري خواهد كرد به خودمان وابسته است، بعبارت ديگر ما بر روي اطلاعات متمركز مي شويم و كمتر توجه مي كنيم كه چه كاري با اين اطلاعات انجام شده است يا رفتار سيستم چگونه است اين روش (Data-Centric ) مبتني بر داده ناميده شده است متد شئ گرائي در پاسخ به مشكلات اين روش ايجاد شده است . با متد شئ گرايي هم بر اطلاعات و هم بر رفتار متمركز مي شويم در نتيجه با اين روش مي توانيم سيستم هايي را ايجاد نماييم كه انعطاف پذير شده و يا اطلاعات و يا رفتار را تغيير دهند. فرمت اين انعطاف پذيري با طراحي يك سيستم شئ گرايي به خوبي شناخته شده است . انجام اين متد به شناخت تعدادي از اصول شئ گرايي نياز دارد. 1.2.2. اصول شئ گرايي 1.2.2.1. Encapsulation در يك سيستم شيء گرايي اطلاعات و رفتارها را در يك Object بسته بندي مي كنيم . اين مطلب در قالب اطلاعات پنهان سازي ارجاع داده شده است . يكي از مزاياي پنهان سازي اين است كه تاثيرات اعمال شده به سيستم را محدود مي كند. 1.2.2.2. Inheritanc وراثت دومين مفهوم اساسي شئ گرايي مي باشد .در سيستم هاي شئ گرايي وراثت به شما اجازه مي دهد تا Object هاي جديد را بر پايه Object هاي قديمي ايجاد كنيد. يكي از مزاياي وراثت سهولت در نگهداري است. 1.2.2.3. Polymorphism سومين اصل شئ گرايي چند ريختي است، چند ريختي به اين معني است كه شكلها يا پيامدهاي زيادي از يك تابع ويژه را داشته باشيم . در واقع در يك سيستم شئ گرايي ما مي توانيم بسياري از رخدادها يا پيامدهاي يك عمل ويژه را داشته باشيم. 1.3. Visual Modeling مدل سازي بصري پردازش گرفتن اطلاعات از مدل است و آن را با استفاده از مجموعه اي از عناصر گرافيك استاندارد به صورت گرافيك نمايش مي دهد. يك استاندارد ضروري براي فهميدن يكي از مزاياي مدل سازي بصري، ارتباطات است. هدف اصلي مدل سازي بصري ارتباط ميان كاربران، برنامه نويسان، تحليلگران، آزمايش كننده ها، مديران و هر شخص ديگري كه با يك پروژه درگير شده است مي باشد. با يك مدل بصري مي توانيم نشان دهيم كه چگونه سيستم روي چند سطح كار مي كند ما مي توانيم فعل و انفعالات بين كاربران و يك سيستم را مدل نماييم. يك موضوع مهم در مدل سازي بصري اين است كه از چه نهاد گرافيكي براي نشان دادن چهره هاي مختلف يك سيستم استفاده مي شود. تعدادي نهاد براي مدل سازي بصري وجود دارد. بعنوان مثال Booch ، OMT ، UML مي باشند. 1.4. UML UML به افراد اجازه مي دهد تا چندين نوع مختلف از نمودارهاي بصري را بوجود آورند كه جنبه هاي مختلف سيستم را نمايش دهد. زبان استانداردي براي مشخص كردن، به تصوير كشيدن و مستند كردن مدلهاي سيستم هاي نرم افزاري شامل ساختار و طراحي آنهاست. UML شامل سه مدل به شرح زير است : 1. مدل تابعي (Functional Model ): عملكرد سيستم را از ديد كاربر شرح مي دهد. در UML براي اين مدل سازي از نمودار هاي Use Case استفاده مي شود. 2. مدل شئ (Object Model ) : ساختار سيستم را به صورت مجموعه اي از اشياء ، صفات ، عمليات و ارتباطات شرح مي دهد.در UML براي اين مدل سازي از نمودار كلاس ( Class Diagram ) استفاده مي شود. 3. مدل پويا (Dynamic Model ) : رفتار داخلي سيستم را شرح مي دهد. در UML براي اين مدل سازي از نمودار هاي Activity ، Statechart ، Sequence استفاده مي شود. 1.4.1. نمودار هاي UML 1.4.1.1. نمودار Use Case نمودار Use Case در طول استخراج نياز ها و تحليل سيستم براي مشخص كردن عملكرد برنامه به كار مي رود. Use Case ها روي رفتار سيستم از يك ديدگاه خارج از سيستم تمركز مي كنند . يك Use Case در واقع عملياتي را شرح مي دهد كه توسط سيستم تهيه شده و نتيجه اي مشخص براي يك بازيگر (Actor ) دارد. 1.4.1.2. نمودار Sequence نمودار Sequence (توالي) به صورت منظم و در يك توالي زماني پشت سر هم ارتباطات متقابل اشياء را به ما نشان مي دهد . اين دياگرام براي انجام عمل خاصي در يك UseCase مشخص ، مراحل انجام كار را مرحله به مرحله به شما نشان مي دهد، يعني دنباله اي از رويدادها را براي انجام يك عمل مشخص مي سازد . در مراحل تحليل و طراحي براي فهم نحوه عملكرد سيستم از اين دياگرام استفاده مي شود. اين نمودار در ارتباط مستقيم با نمودار ارتباط ( همكاري ) مي باشد. 1.4.1.3. نمودار Collaboration در طول توسعه نرم افزار به روش شئ گرا هر چيزي كه نرم افزار نهايي نياز داشته باشد به وسيله همكاري اشياء صورت خواهد گرفت . ما مي توانيم نمودار همكاري را براي تشريح چگونگي وضعيت اشياء در حال همكاري ، به كار ببريم . نمودار Collaboratio دقيقا همان اطلاعات نمودار هاي Sequence را نشان مي دهند با اين تفاوت كه Object ها و فعل و انفعالات عامل ها را بدون توجه به زمان نشان مي دهد. 1.4.1.2. نمودار Class اين نمودار به شما كمك مي كند تا نماي ساختاري سيستم تان را به صورت بصري در آوريد. اين نمودار جزييات هر كلاس و ارتباطات بين آنها را نشان مي دهد و پايه و اساس نمودار هاي اجزاء و پياده سازي مي باشد . در يك مدل واحد ممكن است چندين دياگرام كلاس داشته باشيم. 1.4.1.5. نمودارStatechart مي توانيم نمودارهاي حالت را براي مدل كردن رفتار پوياي كلاس ها يا اشياء انفرادي استفاده كنيم . اين نمودارها ترتيب حالاتي كه يك شئ مي تواند داشته باشد ، رويدادهايي كه موجب انتقال از يك حالت يا فعاليت به ديگري مي شوند و نتايجي را كه اين انتقال به وجود مي آورد را نمايش مي دهد. يك نمودار حالت معمولا براي مدل كردن مراحل گسسته ي چرخه حيات يك شئ به كار برده مي شود ، در حاليكه نمودار فعاليت بر توالي فعاليت هايي در يك فرآيند دلالت دارد. 1.4.1.6. نمودارActivity اين نمودار ، جريان كار و همچنين توالي فعاليت ها را در يك فرآيند مشخص مي كند. اين نمودار خيلي شبيه فلوچارت است . زيرا شما مي توانيد جريان كار را از يك فعاليت به فعاليت ديگر يا حالت ديگر دنبال نماييد . نمودار هاي فعاليت همچنين در جاهايي كه مي خواهيد رفتارهاي موازي را توصيف كنيد يا چگونگي نشان دادن عكس العمل در مقابل يك وضعيت چندگانه را مشخص كنيد مفيد هستند. 1.4.1.7. نمودار Component نمودار هاي Component يك ديد فيزيكي از مدلتان را به شما نشان مي دهد يك نمودار Component اجزاي نرم افزاري سيستم شما و روابط بين آنها را به شما نمايش مي دهد. 1.4.1.8. نمودار Deployment نمودارهاي Deployment لايه فيزيكي شبكه و جايي كه Deployment هاي مختلف تقسيم مي شوند را نشان مي دهد. 1.5. مدل سازي بصري و پردازش توليد و توسعه نرم افزار توليد نرم افزار مي تواند به چندين روش انجام گيرد . چندين نوع متفاوت از پردازشهاي توليد شامل هر چيزي از پردازشهاي آبشاري تا شئ گرايي وجود دارد كه پروژه ها آنها را دنبال مي كنند. مدت طولاني برنامه نويسان نرم افزار از مدل آبشاري استفاده مي كردند . در اين مدل ما درخواستها را تجزيه و تحليل مي كرديم. يك سيستم را طراحي مي كرديم، سيستم را آزمايش مي كرديم و سيستم را نصب مي نموديم. يكي از كمبودهاي مدل آبشاري اين است كه بايد از وسط مراحل به خارج از مجموعه يك پروژه كه مدل آبشاري را دنبال مي كند بازگرد نمايند . (Back Track) ما سالها آموخته ايم كه Back Tracking را طراحي نماييم با اين بينش به توليد مكرر (Iteretive Development ) مي رسيم. توليد مكرر فقط بدين معني است كه ما قصد داريم كارها را بارها و بارها انجام دهيم در پردازش شئ گرا ما در سراسر مراحل تجزيه و تحليل، طراحي، توليد در مقاطع كوچك، بارها حركت خواهيم نمود. بنابراين يك پروژه مي تواند به آبشارهاي كوچكتر ديده شود تا Back Tracking را به حداقل برسانند . يك پروژه به چهار فاز تقسيم مي گردد. 1.6. RUP 1.6.1.. مقدمه [1]RUP متدولوژي ارائه شده توسط شركت رشنال، پر كاربرترين فرآيند توليد و توسعه سيستم هاي نرم افزاري در دنياي كنوني مي باشد و به عنوان يك استاندارد صنعتي بالفعل (Defacto) در دنياي IT پذيرفته شده است اين متدولوژي براي انواع پروژه هاي نرم افزاري در دامنه هاي مختلف مانند سيستم هاي اطلاعاتي، سيستم هاي صنعتي، سيستم هاي بلادرنگ .سيستم هاي تعبيه شده، ارتباطات راه دور، سيستم هاي نظامي و .... و در اندازه هاي متفاوت از پروژه هاي سيار كوچك تا پروژه هاي بسيار بزرگ كاربرد دارد. يكي از مزاياي قابل توجه اين متدولوژي استفاده از روش تكرار در توليد و مديريت توليد نرم افزار است. كه اين امكان توليد مبني بر كاهش ريسك و مواجهه با مشكلات اصلي در ابتداي كار و در نتيجه احتمال موفقيت بيشتر را فراهم مي كند . از محاسن ديگر اين متدولوژي مبنا قرار دادن نرم افزار و توليد يك معماري پايدار در ابتداي كار است كه در نتيجه امكان كشف مشكلات عمده ي اختاري، تست و مجتمع سازي ممتد را از ابتداي كار فراهم مي كند و باعث ارتقاع افراد تيم همزمان با پيشرفت پروژه و كيفيت فرآيند توليد مي باشد. 1.6.2. اصول اساسي روش RUP § حمله سريع و مداوم به ريسكهاي اصلي § تضمين توليد محصولي با ارزش به مشتري § تمركز روي محصول اصلي § اعمال سريع تغييرات در پروژه § توليد سيستم بصورت مولفه اي § كاركردن بصورت گروهي § توجه به كيفيت محصول بعنوان يك اصل RUP از يك روش تكراري استفاده مي كند، در هر تكرار مقداري از نيازمنديها و كار تحليل، طراحي، پياده سازي و تست انجام مي شود، هر تكرار براي توليد يك برنامه قابل اجرا كه يك گام به محصول نهايي نزديك تر است و براساس نتايج تكرارهاي قبلي ساخته مي شود. 1.6.3. دلايل برتري روش تكرار بر روش آبشار § روش تكراري با نياز مندي ها متغير سازگار است. § در روش تكراري، مجتمع سازي يك اتفاق بزرگ (Big Bang ) در آخر پروژه نيست. § در روش تكراري ، ريسكها معمولا در مجتمع سازيهاي اوليه كشف مي شوند. § در روش تكراري با مديريت مي توان در محصول ، تغييرات تاكتيكي ايجاد كرد. § در روش تكراري، استفاده مجدد آسان مي شود. § در روش تكراري، نقص ها در طي چندين تكرار كشف و تصحيح مي شوند. § در روش تكراري، از پرسنل پروژه بهتر استفاده مي شود. § در روش تكراري، اعضاء تيم در ضمن انجام كار ، مطالب جديدي را فرا مي گيرند. § در روش تكراري، فرآيند توليد همراه با انجام كار ، اصلاح شده و بهبود مي يابد. 1.6.4. جنبه هاي سازمان دهي شده RUP جنبة ديناميك (افقي) كه چرخه ها، فازها، تكرارها و مراحل مهم را نشان مي دهد. جنبه استاتيك (عمودي) فعاليتها، ديسيپلينها، خروجي ها و نقش ها را نشان مي دهد. 1.6.4.1. جنبه ديناميك ساختار ديناميك با چرخه حيات و بعد زمان پروژه سر و كار دارد. RUP يك روش ساختار بندي شده براي توليد تكراري فراهم مي كند كه يك پروژه را به چهار فاز تقسيم مي كند كه در ادامه به توضيح اين فازها مي پردازيم. 1.6.4.2. جنبه استاتيك ساختار استاتيك با عناصر فرآيند مانند فعاليتها، ديسيپلينها، خروجي ها و نقش ها بطور منطقي و بصورت ديسيپلينهاي اصلي فرآيند دسته بندي شده اند سر و كار دارد. يك فرآيند نشانگر اين است كه چه كسي، چه كاري را چگونه و در چه وقت انجام مي دهد. نقش ها Who فعاليتها How خروجي ها What جريانهاي كار When 1.6.5. فازها در RUP از نظر مديريت، چرخه حيات نرم افزاري RUP در طي زمان به چهار فاز متوالي شكسته مي شود كه هر يك با يك مرحله مهم اصلي پايان مي يابد. هر فاز بطور اساسي، يك مدت زمان معين بين دو مرحله مهم اصل است كه آيا هدف فاز برآورده شده است يا نه. يك ارزيابي رضايت بخش امكان حركت پروژه به فاز بعدي را مهيا مي كند. همه فازها از نظر زمان بندي و تلاش، يكسان نيستند و با توجه به نوع پروژه به طور قابل توجهي تغيير مي كنند. يك چرخه توليد اوليه متعارف براي يك پروژه با اندازه متوسط بايد از توزيعي شبيه در جدول زير بين تلاش مورد نياز و زمانبندي پيروي كند:

	شناخت	مهارت	ساخت	انتقال
تلاش	5%	20%	65%	10%
زمانبندي	10%	30%	50%	10%

<?xml:namespace prefix = w />1.6.5.1. Inception فاز "شناخت" شروع پروژه است، ما اطلاعات را جمع آوري كرده و مفهوم و برداشت كلي را اثبات مي نماييم پايان اين فاز تصميم درباره انجام يا عدم انجام پروژه است. فاز شناخت مخصوص پيدا كردن جوابهاي اين پرسش هاست. ما كشف مي كنيم كه اشكالات سطح بالاي سيستم چه هستند و آنها را مستندسازي مي نماييم .ما كشف مي كنيم كه عاملهاي سيستم چه كساني هستند و Use Case ها را تعيين مي نماييم. ما در اينجا وارد جزييات Use Case ها نمي شويم اما فقط يك يا دو جمله را آماده مي كنيم، همچنين تخميني را فراهم مي كنيم تا مديريت را پيش ببريم. فاز شناخت زماني پايان مي يابد كه تحقيقات انجام شده اند و مديريت، منابع را اختصاص مي دهد تا بر روي پروژه كار كنند. فاز شناخت بطور اساسي دنباله دار و غير تكراري است بدليل اينكه در حقيقت پروژه فقط يك بار مي تواند شروع شود به همين دليل بيش از يك وظيفه در فاز شناخت مي ماند. توليد يك طرح تكراري . يك طرح تكراري طرحي است كه توضيح مي دهد چه Use Case اي در طول تكرار انجام مي شود. خروجي هاي اساسي به ترتيب اهميت در فاز Inception 1. تصوير كلي(Vision) 2. مورد كسب و كار (BUC ) 3. ليست ريسكها (Risk List ) 4. طراح توليد نرم افزار (SDP ) 5. طرح تكرار 6. مورد توليد و توسعه ( Development Case ) 7. ابزارها 8. واژه نامه (Glossary) 9. مدل Use Case ( عامل ها- Use Case ها ) 10. مخزن پروژه و درخواست تغيير (CM ) خروجي هاي انتخابي (Optionall Artifacts 1. رهنمودهاي مدل سازي Use Case 2. مدل دامنه ( Domain Model ) 3. قالب هاي مخصوص پروژه (Project-Specific Templates ) 4. نمونه اوليه (Prototypes ) 1.6.5.2. Elaboration فاز "مهارت" پروژه شامل مقداري طراحي، تجزيه و تحليل و طراحي معماري است همراه با طرح تكرار. فاز مهارت شامل چندين جنبه از يك پروژه است مانند كد كردن، اثبات مفاهيم، توليد نمونه هاي آزمايشي و ايجاد تصميمات طراحي. از كارهاي اصلي فاز مهارت تكميل Use Case ها است و اصلاح تخمين ها ي اوليه، بررسي كيفيت SRS (مشخصات دريافت نرم افزار) و مدل Use Case و بررسي كردن خطر ها. خروجي هاي اساسي به ترتيب اهميت در فاز Elaboration 1. نمونه اوليه 2. ليست ريسكها 3. مورد توليد و توسعه 4. ابزار 5. مستند معماري نرم افزار (SAD) 6. مدل طراحي 7. مدل داده 8. مدل پياده سازي 9. تصوير كلي 10. طرح توليد نرم افزار 11. رهنمودهايي مانند رهنمودهاي طراحي و رهنمودهاي طرح ريزي 12. طرح تكرار 13. مدل Use Case 14. مشخصه هاي تكميلي 15. مجموعه تست 16. معماري اتوماسيون تست خروجي هاي انتخابي 1. مورد كسب و كار 2. مدل تحليل 3. مولد آموزشي 4. قالب خاص پروژه 1.6.5.3. Constraction اين فاز "ساخت" به روند توليد و تست نرم افزار بر مي گردد. كارهاي فاز ساخت شامل مشخص كردن درخواستهاي ثابت توليد نرم افزار و تست نرم افزار مي باشد . اين فاز زماني به پايان مي رسد كه نرم افزار كامل و تست شده باشد. خروجي هاي اساسي به ترتيب اهميت در فاز Constractio 1. سيستم 2. طراح استقرار 3. مدل پياده سازي 4. مجموعه تست 5. مواد آموزشي 6. طرح تكرار 7. مدل طراحي 8. مورد توليد و توسعه 9. ابزار 10. مدل داده خروجي انتخابی 1. قالب هاي مخصوص پروژه 2. مشخصه هاي تكميلي 3. مدل Use Case 1.6.5.4. Transition فاز "انتقال" زماني است كه محصول نرم افزاري كامل شده به سمت اجتماع كاربر بر مي گردد. كارها در اين فاز شامل كامل كردن محصول نرم افزاري نهايي، تكميل تست، تاييد نهايي، كامل كردن مستندات كاربر و فراهم كردن آموزش براي كاربر مي باشند و بروز رساني مدل هايي كه ايجاد شده با نرم افزار توليد شده. خروجي هاي اساسي به ترتيب اهميت در فاز Transition 1. محصول ساخته شده 2. نكات انتشار نرم افزار (Release Note) 3. خروجي هاي نصب نرم افزار (Installation Artifacs) 4. مواد آموزشي 5. مواد حمايتي از كاربر نهايي خروجي هاي اختياري 1. مجموعه تست 2. بسته بندي محصول نهايي 1.6.6. ديسيپلين هاي RUP 1. مدل سازي كسب و كار 2. نيازمنديها 3. تحليل و طراحي 4. پياده سازي 5. تست 6. استقرار 7. مديريت پيكر بندي و تغييرات 8. مديريت پروژه 9. محيط 1.6.6.1. مدل سازي كسب وكار ديسيپلين مدل كسب و كار توضيح مي دهد كه براي رسيدن به اين هدف چگونه مي توان يك تصوير كلي از سازمان را توليد نمود و براساس اين تصوير كلي فرآيندها، نقش ها و مسووليتهاي آن سازمان را در يك مدل Use Case كسب وكار و يك مدل شئ كسب و كار تعريف كرد. اهداف شناخت ساختار و ديناميكهاي سازماني كه در آن يك سيستم بايد استقرار يابد)سازمان هدف(. شناخت مشكلات فعلي در سازمان هدف و تشخيص پتانسيل هاي بهبود. تضمين اينكه مشتري، كاربر نهايي و توليدكنندگان يك شناخت مشترك از سازمان هدف دارند. هدايت نيازمندي ها سيستم كه براي حمايت از سازمان هدف مورد نيازند. خروجي ها مشخصه هاي تكميلي كسب و كار واژه نامه ارتباطات با ساير ديسيپلين ها ديسيپلين نيازمنديها از مدل كسب و كار به عنوان ورودي مهم براي شناخت نيازمنديها در سيستم استفاده مي كند. ديسيپلين تحليل و طراحي از مدل كسب و كار بعنوان ورودي براي تشخيص كلاسها موجوديت در مدل طراحي استفاده مي كند. ديسيپلين محيط خروجيهاي حمايت كننده از قبيل رهنمودهاي مدل سازي كسب و كار را توليد و نگهداري مي كند. 1.6.6.2. ديسيپلين نيازمنديها اهداف تشخيص و نگهداري موارد توافق با مشتريها و ساير ذينفعان در مورد كارهايي كه سيستم بايد انجام دهد. فراهم آوردن شناخت بهتر از نيازمنديهاي سيستم براي توليدكنندگان سيستم تعريف مرزهاي تعيين صدور سيستم فراهم كردن يك پايه براي طرح ريزي مفاهيم تكنيكي تكرارها فراهم كردن يك پايه از جهت تخمين مخارج و زمان براي توليد سيستم تعريف يك واسط كاربر براي سيستم با تمركز بر روي نيازها و اهداف كاربران خروجي ها نياز منديهاي ذينفعان دستور كار Use Case (Use Case Storyboard ) ارتباطات با ساير ديسيپلين ها

ديسيپلين مدل سازي كسب و كار، قوانين كسب و كار، يك مدل Use Case كسب وكار و يك مدل شيء كسب و كار را فراهم مي كند كه شامل يك دامنه و يك زمينه سازماني براي سيستم مي باشد.
ديسيپلين تحليل و طراحي ورودي اوليه خود را (مدل Use Case و واژه نامه) از نيازمنديها دريافت مي كند.
ديسيپلين تست اعتبار سيستم را در مقابل مدل Use Case بررسي مي كند. Use Case ها و مشخصات تكميلي ، ورودي نيازمندي ها را كه در تعريف ماموريت (اهداف) ارزيابي و در فعاليت هاي ارزيابي و تست بعدي استفاده مي شوند فراهم مي كنند.
ديسيپلين پيكربندي و مديريت تغييرات، مكانيزم كنترل تغيير را براي نيازمنديها فراهم مي كند.
ديسيپلين مديريت پروژه، پروژه و تكرار را طرح ريزي مي كند . مدل Use Case و طرح مديريت نيازمنديها، وروديهاي مهم فعاليتها طرح ريزي تكرار مي باشند.
ديسيپلين محيط، خروجيهاي حمايتي را در طول مديريت نيازمنديها و مدل سازي Use Case استفاده مي شوند توليد و نگهداري مي كند.

1.6.6.3. ديسيپلين تحليل و طراحي اهداف 1. تبديل نيازمنديها به طراحي سيستمي كه قرار است به وجود آيد. 2. پيدايش يك معماري مستحكم براي سيستم 3. سازگار ساختن طراحي براي هماهنگ شدن با محيط پياده سازي و طراحي آن براي كارآيي بهتر ارتباطات با ساير ديسيپلين ها 1. ديسيپلين مدل سازي كسب و كار، يك زمينه سازماني را براي سيستم فراهم مي كند. 2. ديسيپلين نيازمنديها، ورودي اوليه براي تحليل و طراحي را فراهم مي آورد. 3. ديسيپلين تست، سيستمي كه در طول تحليل و طراحي، طراحي شده را تست مي كند. 4. ديسيپلين محيط، خروجيها حمايتي كه در طول تحليل و طراحي استفاده مي شوند را توليد و نگهداري مي كند. 5. ديسيپلين مديريت پروژه، پروژه هر تكرار را طرح مي كند. 1.6.6.4. ديسيپلين پياده سازي اهداف 1.تعريف سازمان كه، برحسب زير مجموعه هاي پياده سازي سازمان يافته در لايه ها 2. پياده سازي كلاسها و اشياء بوسيله مولفه ها (فايلهاي منبع، فايل هاي اجرايي و ..) 3. تست اجزاء توليد شده به عنوان واحدها 4. مجتمع سازي نتايج توليد شده توسط پياده سازان فردي (يا تيم) به صورت يك سيستم قابل اجرا. ارتباطات با ساير ديسيپلين ها 1. ديسيپلين نيازمنديها توضيح مي دهد كه چگونه در يك مدل Use Case به نيازمنديهايي كه پياده سازي بايد برآورده سازد دست يابيم. 2. ديسيپلين تحليل و طراحي توضيح مي دهد كه چگونه يك مدل طراحي را توليد نماييم. 3. ديسيپلين تست توضيح مي دهد كه چگونه بر روي هر تركيب مجتمع سازي شده در سيستم،تست مجتمع سازي انجام شود و همچنين توضيح مي دهد كه چگونه سيستم را براي بررسي اينكه همه نيازمنديها برآورده شده اند يا نه تست نمائيم و همچنين اينكه چگونه نقايص ظاهر مي شوند و برطرف مي گردند. 4. ديسيپلين محيط توضيح مي دهد كه چگونه خروجيهاي پشتيباني را توليد و نگهداري نماييم. 5. ديسيپلين استقرار توضيح مي دهد كه چگونه از مدل پياده سازي براي توليد و انتقال كه به مشتري نهايي استفاده نماييم. 6. ديسيپلين مديريت پروژه توضيح مي دهد كه چگونه پروژه را به بهترين وجه طرح ريزي كنيم. 1.6.6.5. ديسيپلين تست اهداف 1. يافتن و مستند كردن نقايص در كيفيت نرم افزار 2. آگاهي دادن در مورد كيفيت نرم افزار بررسي شده 3. اثبات اعتبار فرضياتي كه در طراحي و مشخصات نيازمنديهاي ساخته شدند، از طريق نمايشهاي واقعي 4. تصديق عملكردهاي محصول نرم افزار همانطور كه طراحي شده است. 5. تصديق اينكه نيازمنديها به درستي پياده سازي شده اند. ارتباطات با ساير ديسيپلين ها 1. ديسيپلين نيازمنديها، نيازمنديهايي را براي محصول نرم افزاري در بر مي گيرد. كه اين نيازمنديها از جمله شامل ورودي هاي اصلي براي تشخيص اين است كه چه تستهايي بايد انجام شود. 2. ديسيپلين تحليل و طراحي، طراحي مناسب براي محصول نرم افزاري را تعيين مي كند. 3. ديسيپلين پياده سازي ساختهاي محصول نرم افزاركه توسط ديسيپلين تست معتبر دانسته شده اند را توليد مي كند. 4. ديسيپلين محيط، خروجيهاي پشتيباني را توليد و نگهداري مي كند. 5. ديسيپلين مديريت در هر تكرار، پروژه لازم در آن تكرار را طرح ريزي مي كند. 6. ديسيپلين مديريت پيكربندي و تغييرات ، تغييرات داخل پروژه را كنترل مي كند. 1.6.6.6. ديسيپلين استقرار اهداف ديسيپلين استقرار فعاليتهايي را توضيح مي دهد كه تضمين مي كند محصول نرم افزار براي كاربران نهايي اش در دسترس مي باشد. 1. نصب اختصاصي 2. آماده فروش كردن محصول نهايي 3. دستيابي به نرم افزار از طريق اينترنت ارتباطات با ساير ديسيپلين ها 1. ديسيپلين نيازمنديها، مشخصات نيازمنديهاي نرم افزاري را كه شامل Use Case و نيازمنديهاي غير عملياتي مي باشند تعيين مي كند. 2. ديسيپلين تست، تست گرفتن بخش ضروري و لازم الاجرا استقرار مي باشد. 3. ديسيپلين پيكربندي و مديريت تغيير، براي فراهم آوردن ساخت هاي پايداري و انتشار محصول و مكانيزم هاي اقدام در جهت درخواستهاي تغيير كه به عنوان نتيجه تست و تستهاي پذيرش بوجود مي آيند، مورد مراجعه قرار مي گيرد. 4. ديسيپلين مديريت پروژه، فعاليتهايي كه در جهت توليد يك طرح تكرار و يك طرح توليد نرم افزار مي باشند روي طرح استقرار مؤثرند. 1.6.6.7. ديسيپلين محيط اهداف 1. فراهم آوردن محيط توليد ( فرآيندها) 2. فراهم آوردن محيط توليد ( ابزارهاي پشتيباني ) ارتباطات با ساير ديسيپلين ها ديسيپلين محيط، محيط پشتيباني براي يك پروژه را فراهم مي آورد. در اين راستا اين ديسيپلين همه ديسيپلين هاي ديگر را حمايت مي كند. 1.6.6.8. ديسيپلين مديريت پروژه اهداف 1. فراهم كردن يك چارچوب براي مديريت پروژه هاي صرفاً نرم افزاري 2. فراهم كردن رهنمودهاي عملي براي طرح ريزي، تعيين نيروي انساني، اجرا و نظارت بر پروژه ها 3. فراهم كردن يك چارچوب براي مديريت ريسك ارتباطات با ساير ديسيپلين ها 1. ديسيپلين مدلسازي كسب و كار 2. ديسيپلين تحليل و طراحي 3. ديسيپلين پياده سازي 4. ديسيپلين تست 5. ديسيپلين استقرار 1.6.6.9. ديسيپلين مديريت پيكربندي و تغييرات اهداف 1. به روز رساني همزمان 2. توجه محدود شده 3. نسخه هاي چند گانه ارتباطات با ساير ديسيپلين ها ديسيپلين مديريت پيكربندي و تغييرات به همه ديسيپلين هاي فرآيندي ديگر مرتبط است. 1.7 . Rational Rose چيست ؟ Rational Rose يك ابزار قدرتمند است كه به تجزيه و تحليل و طراحي سيستم هاي نرم افزاري شئ گرا كمك مي كند. اين ابزار كمك خواهد كرد كه قبل از اينكه كدي را بنويسيد سيستم خود را مدل نماييد بنابراين مي توانيد مطمئن شويد كه سيستم از ابتدا معماري معتبري دارد. چه كساني از مدل ايجاد شده مي توانند استفاده نمايند. § مشتريان و مديران پروژه از نمودارهاي Use Case استفاده خواهند كرد تا ديد سطح بالايي را نسبت به سيستم بدست آورند و بر روي محدوده پروژه موافقت مي كنند. § مديران پروژه از نمودارهاي Use Case و مستندات استفاده خواهند نمود تا پروژه را به تكه هاي قابل مديريت بشكنند. § تحليلگران و مشتريان به مستندات Use Case نگاه خواهند كرد تا ببينند كه سيستم چه عملياتي را فراهم خواهد نمود. § نويسندگان تكنيكي به مستندات Use Case نگاه خواهند كرد تا شروع به نوشتن طرحهاي آموزشي و دستي كاربران كنند. § تحليلگران و برنامه نويسان به نمودار Sequence و Collaboration نگاه خواهند كرد تا ببينند كه چگونه در منطق سيستم ، پيغام هاي بين Objectها جريان خواهند داشت. § كارمندان تضمين كيفيت از اسناد Use Case و نمودار هاي Sequence و Collaboration استفاده خواهند كرد تا اطلاعاتي را بدست آورند كه براي تست نياز دارند. § برنامه نويسان از نمودار Class و نمودارهاي State Transition ايتفاده خواهند كرد تا ديد جزيي نسبت به قطعات سيستم و چگونگي ارتباط آنها را بدست آورند. § كارمندان Deployment از نمودار هاي Deployment و Component استفاده خواهند كرد تا ببينند كه چه فايل هاي اجرايي ، فايل هاي DLL يا Component هاي ديگري ايجاد خواهند شد . اين Component در كجا برروي شبكه قرار خواهند گرفت. § كل تيم از مدل استفاده خواهند كرد تا مطمئن شوند كه درخواستها به كد تبديل شده اند و آن كدها مي توانند به درخواستها تبديل شود.

مروری بر متدولوژي RUP

مطالب مشابه :

UML 2.0

Rational Rose

معرفي زبان استاندارد مدلسازي UML

پروژه تحلیل سیستم انتخاب واحد دانشگاه

UML چیست ؟

دانلود گزارش برنامه ریزی پروژه نمونه عملی شهرداری تهران

عناصر اصلي در رسم يک BPD - 2

DFD تاکسی تلفنی با Use Case Diagram

درس مهندسی نرم افزار کنترل - مبحث UML

مروری بر متدولوژي RUP