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.. مقدمه

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%

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 )

ارتباطات با سایر دیسیپلین ها

1.دیسیپلین مدل سازی كسب و كار، قوانین كسب و كار، یك مدل Use Case كسب وكار و یك مدل شیء كسب و كار را فراهم می كند كه شامل یك دامنه و یك زمینه سازمانی برای سیستم می باشد.

2.دیسیپلین تحلیل و طراحی ورودی اولیه خود را (مدل Use Case و واژه نامه) از نیازمندیها دریافت می كند.

3.دیسیپلین تست اعتبار سیستم را در مقابل مدل Use Case بررسی می كند. Use Case ها و مشخصات تكمیلی، ورودی نیازمندی ها را كه در تعریف ماموریت (اهداف) ارزیابی و در فعالیت های ارزیابی و تست بعدی استفاده می شوند فراهم می كنند.

4.دیسیپلین پیكربندی و مدیریت تغییرات، مكانیزم كنترل تغییر را برای نیازمندیها فراهم می كند.

5.دیسیپلین مدیریت پروژه، پروژه و تكرار را طرح ریزی می كند. مدل Use Case و طرح مدیریت نیازمندیها، ورودیهای مهم فعالیتها طرح ریزی تكرار می باشند.

6.دیسیپلین محیط، خروجیهای حمایتی را در طول مدیریت نیازمندیها و مدل سازی 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 در كجا برروی شبكه قرار خواهند گرفت.

• كل تیم از مدل استفاده خواهند كرد تا مطمئن شوند كه درخواستها به كد تبدیل شده اند و آن كدها می توانند به درخواستها تبدیل شود.

 www.smsm.ir

نوع مطلب : مهندسی کامپيوتر - نرم افزار
نوشته شده در دوشنبه ۲۵ بهمن ۱۳۸۹ توسط SMSM |           |