وجود تکنیک هایی جهت پیاده سازی متدولوژی که قابلیت کنترل پیچیدگی های سیستم را داشته باشد نیز مورد دیگری است که از یک متدولوژی توسعه انتظار می رود.
RUP این تکنیک ها را در قالبworkflow که برای هر تنظم(discipline ) ارائه میدهد، لحاظ کرده است.
هرworkflow شامل یکسری work flow detalie می باشد که در حقیقت یک گروه activity ها و role های انجام دهنده آنها و فرآورده های حاصل از هر activity می باشد.
معیار های ارزیای نتایج بکارگیری متدولوژی RUP در قالب فرسنگ شمارهای(mile stone ) دیده شده که در پایان هر فاز و هر تکرار( Iteration ) به فرآورده های حاصل اعمال می شوند تا میزان تطابق این فرآورده ها را با نتایج مطلوب ارزیابی کند.
RUPیکسری ابزارهای اتوماتیک جهت تولید و استخراج مدلها در اختیار طراحان قرار می دهد از قبیل: Rational Robot ,Rational SODA, Rational Rose, Rational XDE, Rational RUP RUPامکام رسیدن CMM سطح CMM,2(Repeatable) سطح (Defined)3 را دارد.
انطباق خصوصیات CMM سطح 2 با مدل RUP : KPA1 – Requorment , Nanaaement بمنظور انجام مدیریت نیازمندیها باید رابطه ای بین طرح سیستم و مشتریان صورت گیرد و همچینن در نظم Configuration ، Management مدیریت تغییر نیازمندیها صورت می گیرد یکی ا زموارد مفید RUP در تأمین این KPA موارد کاربردی هستند.
فرآورده های RUP که نیازها را جمع آوری می کنند عبارتند از: 1- مدل های موارد کاربردی( Use case model ) ها که شامل موارد کاربردی و بسته های(Package ) های تشکیل شده از آنها هستند.
2- مشخصات مکمل غیرکاربردی(Non0 functional, Supplementary Specification ) 3- مطالعات مربوط به موارد کاربردی(Use Case Model survey ) 4- گزارشات مربوط به موارد کاربردی(Use case Report ) 5- glossary : که این فرآورده ها و مواد کاربری از داخل فرآورده های زیر قابل استخراج هستند.
1- lteration plan 2- Integration Build plan 3- Project plan 4- Soft wore plan development Soft ware project planning KPA2 مقصود ایجاد یک طرح معقول جهت انجام اعمال مهندسی نرم افزار و مدیریت پروژه می باشد.
بدون یک طرح تحقیق پذیر عملاً مدیریت پروژه کارآیی قابل پیاده سازی نمی باشد.
این اهداف نیازمند ایجاد یکسری تخمینها مستندسازی شده جهت استفاده از برنامه ریزی(planning ) و ردیابی جریان پیشرفت پروژه که این تخمینها توسط معیارها(metric ) های زیر در RUP قابل محاسبه هستند.
میزان پیشرفت(Progress ): که براساس میزان کدتولید شده- تعداد کلاسهای ساخته شده – میزان دوباره کلاسها و تغییرات rework ها و function point ها در هر تکرار پایداری Stability ( براساس نوع تغییرات rework ) نیازهای بوجود آمده در طول پروژه و تغییرات غیرقابل اجتناب در پیاده سازی محاسبه می شود) میزان وفق پذیری(adaptivity )که براساس هزینه تغییرات محاسبه می شود.
میزان Modularity (که براساس میزان پیچیدگی لازم جهت اعمال تغییرات محاسبه می شود) Quality ( که براساس نرخ کشف عیب، فشردگی و چگالی خطا) میزان بلوغ Maturity ( میزان ساعات تست انجام شده جهت کشف خطا) همچنین می توان طرح کلی پروژه را از مستندات زیر در RUP بدست آورد: Business case ها Software development plan Measurement plan Risk list Project plan Ltration plan Ltration Assessment(s) Status Assessment Software project tracking –KPA3 and Over sight منظور ایجاد تصویر کافی از روند پیشرفت پروژه است تا مدیر پروژه با توجه به آن بتواد تصمیماتی اساسی را در هنگامی که پروژه از مسیر خود منحرف می شود ا تخاذ نماید تا پروژه را به مسیر حقیقی اش بازگرداند.
برای دستیابی به این KPA می توان از milestone ها در RUP استفاده کرد.
در پایان هر فاز یا تکرار با توجه به این فرسنگ شمارها می توان متوجه شد که تا چه حد پروژه در راستای اهداف تعریف شده اش پیشرفته است.
درصورت مشاهده انحرافات اساسی می توان با استفاده از Chang request های موجود در RUP تقاضای تغییرات لازم جهت حصول نتایج دلخواه را داد.
Software subcontract Management – KPA4 : منظور انتخاب پیمانکاران تأئید شده و دارای صلاحیت لازم جهت انجام بخشهای مختلف پروژه است.
این KPA ورای حیطه کاری RUP است.
Software Quality Assurance KPA5 : مقصود تأمین یک نوع مدیریت کیفی بر روی فرآیندی که برای انجام پروژه استفاده شده و محصولات تولیدشده می باشد.
که این عمل توسط فعالیت quality Assurance در RUP مشخص می شود.
موارد دیگری که در RUP جهت تأمین کیفیت فرآیند تولید توسعه می توان از آنها استفاده کرد miles stone ها هستند.
همچنین از معیارهای(metric ) های بیان شده در KPA2 نیز می توان استفاده کرد.
Software Configuration –KPA6 management : مقصود حفظ یکپارچگی و نگهداری پروژه د رطول دوره فرآیند توسعه می باشد که شامل مدیریت تغییر نیازمندیها و مدیریت نسخه های مختلف در طول جریان توسعه و ......
می باشد این KPA در RUP توسط نظم Configuration & change management قابل تأمین می باشد.
انطباق خصوصیات سطح 3 با مدل RUP : Organization KPA1 : مقصود از ایجاد یک مسئولیت سازمانی برای هر فعالیت(activity ) موجود در پروسه process focus توسعه نرم افزار است.
در حقیقت با این کار سعی می شود تا جای ممکن پروسه نرم افزار با ساختار سازمان نظیر شود.همانطور که می دانیم می توانیم برشهای(tailor ) متفاوتی ازز RUP را جهت فرآیند توسعه نرم افزاری انتخاب می کنیم که این کار را با استفاده از نظم environment انجام میدهیم.
Organization process: KPA2 Definition :مقصود تعریف سازمان در قالب پروسه نرم افزار است که این امر باعث استخراج یکسری ارزشهای(asset ) برای پروسه نرم افزار می گردد که کارآیی فرآیند توسعه را بالا می برد و همچنین در هنگام مرحله آموزش نیز بکار می رود اینکار نیز توسط مفهوم tailoring در RUP قابل انجام است.
Training Program KPA3 : مقصود تربیت افراد به گونه ای است که توانایی انجام نقش های خود را بصورت کارآ و مؤثر داشته باشد.
آموزش یک مسئولیت سازمانی است اما در مواردی که نیازهای پروژه مختص به آن پروژه خاص است این وظیفه در راستای پروژه نیز قابل تعریف است.
در این راستا خود RUP یک منبع کامل آموزشی است.
-Integrade software Management :KPA4 : مقصود مجتمع سازی فعالیت های مهندسی و مدیریت نرم افزار بصورت منسجم جهت تعریف یک فرآیند نرم افزاری برش خورده(tailored) برای سازمان است که این امر توسط جریان کاری Environment قابل انجام است.
-software product Engineering : KPA 5 : مقصود یک فرآیند مهندسی خوش تعریف است که تمام فعالیت های مهندسی نرم افزار گزینش شده را جهت تولید محصولاتی کارا مؤثر، صحیح و پایدار مجتمع کند.
این کار توسط RUP بصورت اتوماتیک صورت گرفته و تعریفی که از نقشها و فعالیت ها و فرآورده ها در هر فاز و نظم صورت گرفته و ارتباطات بین آنها ین KPA کاملاً تأمین نموده است.
Intergroup coordination: KPA 6 : مقصود ایجاد ابزارهایی جهت تعامل گروههای مختلف مؤثر در تولید نرم افزار است د رحقیقت این ارتباط ها در قالب مفهوم software Integration در RUP تعریف شده است که تنها مفهوم مجتمع سازی زیر سیستمیها را بیان می کند بلکه مفهوم مجتمع سازی گروههای کاری را نیز دربرمی گیرد که بوسیله Configuration and change management تا حد زیادی قابل پیاده سازی است.
Peer Riviews : KPA7 : مقصود برطرف کردن نقصهای پروژه زود و به صورت کارآ می باشد در RUP این کار به اینصورت، صورت می گیرد که اشخاصی که فرآورده های پروسه را مورد بازنگری انجام می دهند مشخص می کنند که آیا فرآورده ها آماده انتقال به مرحله بعد هستند یا خیر.
در صورتی که فرآورده در گذر از این مرحله شکست بخورد تغییرات موردنظر توسط change request ها برطرف می شود.
RUP یک متدولوژی قابل انطباق است بگونه ای که می توان کلاض آنرا برای پیاده سازی یک سیستم خاص برش داد.
(tailor ) معماری RUP بگونه ای طراحی شده تا هم قابلیت طراحی سیستم های در مقیاس بزرگ(large Scale ) را داشته باشد و هم طراحی سیستم کوچک و سریع در سالهای اخیر یک دسته متدولوژی های معروف به متدولوژیهای چابک(agile ) جهت طراحی سیستم های کوچکتر پدید آمده اند.
که از جمله آنها می توان از (XP) extream Programming ،SCRUM ،Feature-Driven(Development) (FDD ) ، Crystal Clear Methodology نام برد.
بطورکلی چه RUP چه متدهای Agile سعی کرده اند ویژگی های ضروری و کلیدی توسعه نرم افزار، را جهت تولید نرم افزارهای با کیفیت بالا به مهمترین نحوه ممکن پیاده سازی می کنند.
دیدی که RUP و فرآیندهای چابک نسبت به این موضوع دارند نیز تا حد زیادی با هم همسو می باشند.
که از جمله آن می توان به توسعه تکراری و توجه به فاکتورهای محیط توسعه(Business Model ) و......
می باشد اشاره کرد.
XP از چهار فعالیت(activity ) اصلی حمایت می کند( کدنویسی، آزمون، شنیدن، طراحی) که مشابه نظمهای RUP هستند.
این فعالیت های XP در قالب یکسری رویه ها مدون می شوند که عبارتند از: The planning game : تعیین محدوده نسخه بعدی با ترکیبی از اولیت های کاری و تخمینهای تکنیکی صورت گرفته.
Small release : تولید سریع یک سیستم ساده و سپس تولید نسخه های جدید در دوره های(cycle ) های کوتاه.
Metaphore : هدایت کل فرآیند توسعه بوسیله یک داستان مشترک از چگونگی عملکرد سیستم.
Simple Design : سیستم باید در نهایت سادگی طراحی شود و پیچیدگی های اضافی باید تا حد امکان حذف شوند.
Testing : برنامه نویسان بطور پیوسته آزمونهای واحدی جهت تست تولید می کنندکه باید اجرا شوند تا توسعه ادامه پیدا کند.
مشتری ها نیز آزمونهایی می نویسند که نشان می دهند آیا ویژگیهای مورد انتظارشان از سیستم برآورده شده یا خیر.
Re factoring : توسعه دهندگان برای حذف تکرار ها و بدون تغییر رفتار آن از نو سازماندهی می کنند و به این ترتیب ارتباطات را ارتقاء داده و سیستم را انعطاف پذیرتر می نمایند.
Pair programming : تولید که بوسیله دو برنامه نویس در قالب تیم دو نفره در یک ماشین انجام می گیرد.
Collective Ownership : هر کسی می تواند هر کدی را در هر جایی از سیستم در هر زمانی تغییر دهد.
Continious integration : تجمع و ساخت سیستم چندین بار در روز انجام می شود که در هر بار یک وظیفه کامل می شود.
40-hours week : :بیش از 40 ساعت در هفته نباید کار کرد.
On-Site Customer : حضور یک کاربر واقعی در تیم که بصورت full-time حاضر است و می تواند به سئوالات پاسخ دهد.
Coding standards : قواعد کدنویسی باید توسط برنامه نویسان رعایت شود و ارتباط بین کدها مورد توجه قرار گیرد.
مثلاً فعالیت های انجام شده در نتیجه رویه planning game با نظم مدیریت پروژه RUP متناظر است در عوض بعضی مفاهیم نیز در RUP وجود دارند که در مدل چابک به دلیل اهمیت سرعت کار کنار گذاشته شده اند مانند مدل سازی کاری(Business Modeling ) و نظم می نماید.
همچنین XP به دلیل اینکه یک متدولوژی چابک و سریع است چندان درگیر مباحثی مانند مدیریت پیکره بندی و تغییرات و نظم محیط که درRUP به تفضیل بررسی شده نمی شود.
تطبیق XP با RUP : رویه های زیر از متدولوژی XP در RUP نیز پیش بینی شده اند.
-The planning game : بر ای انجام این رویه در RUP می توان از نظم مدیریت پروژه استفاده کرد مخصوصاً در پروژه های با رسمیت پائین.
Test- first design and re factoring : این دو تکنیک، تکنیک های خوبی هستندکه می توان آنها را در نظم پیاده سازی(implementation ) در RUP بکار گرفت.
رویه آزمون در(test –first design ) یک روش عالی جهت استخراج نیازمندیها بصورت جزیی است.
اما re factoring در سیستم های بزرگ بخوبی قابل اندازه گیری نیست.
RUP: Continus integration : این رویه از طریق ساختهای مختلف از یک سیستم در سطوح سیستم و زیرسیستم در یک تکرار حمایت می کند.
واحد های تست شده با هم مجتمع شده و دوباره تست می شوند.
On Site Customer : اغلب فعالیت های RUP از یک مشتری بعنوان یکی از اعضای تیم توسعه دهنده بهره می برند.
Coding Standards : دارای یک فرآورده به نام راهنمای برنامه سازی است که اغلب بصورت اختیاری مورد استفاده قرار می گیرد.
40-hour week : در RUP نیز فرآیند XP نباید بیش از حد خاصی کار کرد.
XP: Pair Programming ادعا می کند که Pair Programming برای کفیت کد بسیار سودمند است.
RUP با این رویه به صورت مکانیکی برخورد نمی کند.
با این حال در RUP نیز می توان از این رویه در تولید کد بهره گرفت.( نگاشت فرآورده های XP با RUP در پروژه کدچک) بکارگیری رویه های XP با استفاده از RUP : متدولوژی Agile یک روش توسعه کامل نیست اما از مستندسازی و مدلسازی حمایت می کند و می توان آنرا با فرآیند های توسعه نرم افزار بکار گرفت.
برای استفاده از این مدل یک متدولوژی را انتخاب کرده و آنرا برای استفاده از متد Agile پیکره بندی می کنیم.
با توجه به این نکته می توان RUP را نیز برای استفاده از AM برش(tailor ) داد.
حال به بررسی ویژگی های هفتگانه یک متدولوژی در قالب متدهای چابک در RUP می پردازیم: 1- ارایه تعاریفی از مفاهیم اولیه بکاررفته در متدولوژی: مفاهیم اولیه در این متدولوژی در مدل چابک و نیز RUP شرح داده شده است.
2- ارائه مدلی برای فرایند تولید: در تولید سیستم های نرم افزاری در مقیاس کوچک براساس مدل Agile توسط RUP از مدل فرآیند RUP که در 4 فاز و 7 نظم تعریف شده استفاده می شود.
3- داشتن مدل معماری: در مدل چابکی مانند XP از Metaphor بعنوان یک مدل زیربنایی جایگزینی برای مدل معماری بکار می رود.
برای پروژه های بزرگتر و پیچیده تر که Metaphor به تنهایی پاسخگو نمی باشد میتوان مدل معماری تعریف شده در RUP استفاده نمود.
4- ارائه یک شیوه علامتگذاری استاندارد: در مدل چابکی مانندXP می توان از مدلهای UML استفاده کرد.
برای استفاده از مدل چابک در RUP و طراحی آن با مدل UML در RUP از Design model استفاده می شود.
5 – معرفی تکنیک هایی برای پیاده سازی متدولوژی: از تکنیک های test- first Design و re factoring می توان در نظم پیاده سازی RUP استفاده کرد.
6- ارائه معیارهایی جهت ارزیابی نتایج حاصل از بکارگیری متدولوژی: بمنظور تعیین معیارهایی جهت ارزیابی نحوه پیشرفت پروژه می توان از فرسنگ شمار در RUP استفاده کرد همچنین جهت ارزیابی نحوه بکارگیری متدلوژی نیز می توان از Status Assessment ، Iteration Assessment و Review Record ها استفاده کرد.
7- وجود ابزار اتوماتیک برای کمک به تولید و اجرای مدلها: همانطور که قبلاً در جدول بحث شد معادل ابزارهای Code management وWork Space testing در Project repository ، work space ، Case development ، test environment configuration استفاده می شود.
معما ردر RUP نقشی زیربنایی است که مسئولیت آغاز تصمیمات مهم و فنی را بر عهده دارد که در قالب معماری نرم افزار بیان می شود.
اینکار شامل مستندسازی و شناسایی جنبه های مهم سیستم از دیدگاه معماری است که حاوی نیازمندی های طراحی، پیاده سازی و نحوه استقرار(Development ) سیستم می باشد.
معمار نرم افزار سعی در ایجاد توازن در انتظارات دینفعان مختلف، کاهش ریسک های فنی و تضمین اینکه تصمیمات اتخاذشده در قالب معماری به صورت کارآ مورد بررسی و توافق قرار گرفته است را برعهده دارد.
معمار نرم افزار باید فردی توانا و تیزبین و مجرب باشد که دارای قوه ادراک و استمتاج قوی باشد.
خصوصیات کلی معمار یا اعضای تیم معماری را می توان در قالب زیر بیان نمود: تجربه: هم در حوزه مهندسی نرم افزار و هم در حوزه مسأله در جهت درک نیازمندیهای سازمان مورد بررسی.
رهبری: چون کار توسعه نرم افزار در قالب تیم نرم افزار صورت می گیرد معمار باید توانایی واردکردن تیم های مختلف به تلاشی فنی و اخذ تصمیمات مهم در مواجهه با فشارها و پایدارنمودن تصمیمات اتخاذشده را دارا باشد رهبری مؤثر است از آنجائیکه مدیر پروژه و معمار همکاری نزدیکی با هم دارند بدین صورت که معمار مباحث فنی و مدیر پروژه مباحث مدیریتی را رهبری می کند.
معمار نرم افزار باید توانایی اتخاذ تصمیمات فنی را داشته باشد.
ارتباطات: معمار نرم افزار باید قادر به ایجاد ارتباطی کارآ و مؤثر با اعضای تیم های مختلف جهت ایجاد انگیزه و راهبری فعالیتها را داشته باشد زیرا تنها با کسب همدلی اعضای گروه می تواند بصورت کارآ مدیریت نماید نه با استفاده از زور.
هدف گرا و حرفه ای: معمار نرم افزار نیروی راهبر پروژه است که نباید خیالباف و رؤیایی باشد و باید تنها به هدف قابل اجرایی که تعیین شده بیاندیشد و بتواند در مواقع فشار و با توجه به عدم قطعیت موجود تصمیمات راهبردی موجود را به صورت حرفه ای اتخاذ نماید.
علاوه بر این معمار نرم افزار باید قابلیت های نقش طراح را نیز دارا باشد.
با این حال برخلاف یک طراح معمار باید: بجای اینکه در یک زمینه خاص دانش و اطلاعات داشته باشد در زمینه های متعددی دانش و مهارت کافی داشته باشد.
باید تصمیمات فنی وسیع تری را اتخاذ نماید پس باید دارای تجربه و دانش در حیطه وسیع تری باشد.
در RUP فرآورده های معماری زیر تولید می شود: مدل استقرار: نحوه قرار گرفتن پیکره بندی گروههای پردازشی در زمان اجرا و ارتباطات میان آنها و نمونه هایی از مؤلفه ها و اشیایی که در آنها قرار می گیرند را نشان می دهد.
این مدل شامل گره ها( عناصر پردازشی با حداقل یک CPU ، حافظه و سایر تجهیزات مورد لزوم، دستگاه ها( گره های کلیشه ای که قدرت پردازش ندارند) اتصال دهنده ها.
نحوه تولید: برای تولید این مدل متنی کوتاه و خلاصه بعنوان مقدمه در مورد مدل تولید می شود عناصر بصورت گروههایی با ویژگی های زیر نمایش داده می شوند: نام یک توصیف که اطلاعاتی در مورد پردازش گره، گنجایش حافظه، یا هر اطلاعات دیگری در مورد دستگاه - لیستی از فرایندها و (thread ) ها که روی پردازشگر اجرا می شوند.
در حقیقت این لیست مؤلفه های نرم افزاری را که در هر فرآیند اجرا می شوند را مشخص می کند.
لیستی از واحدهای مستقر شده که روی آن گره نصب می شوند.
دستگاه های فیزیکی بصورت گره هایی کلیشه ای( Stereo typed ) بازنمایی می شوند که هیچ قدرت پردازشی ندارند و دارای مشخصات زیر می باشند: نام توصیفی که اطلاعات در مورد قابلیتهای دستگاه در اختیار قرار میدهند.
اتصال دهنده های میان گره ها و نیز میان گره ها و دستگاه ها نیز با association هایی که ممکن است کلیشه(Stereotype ) داشته باشند نمایش داده می شوند.
این مدل نمودار های بسته ها(package ) ها را نیز دارا می باشد.
مدل تحلیلی: تشخیص user case و نیز اینکه چه موارد اساسی در مدل طراحی باید طراحی گردد را مشخص می کند برخلاف مدل طراحی در مدل تحلیل به جزئیات کنترلی پیاده سازی ها کاری نداریم.
این مدل شامل نتایج تحلیل use case ها درقالب کلاسهای فرآوری شده می باشد.
این مدل یک فرآورده موقتی بمنظور حصول یک مدل طراحی کارآ می باشد.
نحوه تولید: برای تولید این مدل نیز از یک مقدمه متنی کوتاه که مدل را بصورت خلاصه معرفی می کند استفاده می شود که به نام short tex معروف است.
بسته های تحلیل از طریق بست های دارای سلسله مراتب که دارای روابط Association با برچسب represents و aggregation با برچسب owns نمایش داده می شوند.
کلاسهای هر بسته با استفاده از رابطه تجمعی(Aggregation ) مشخص می شوند.
مدل طراحی: یک مدل براساس اشیاء و کلاسهاست که از روی use case استخراج می شود و نحوه تحقق آنها را مشخص می کند و بعنوان یک ورودی اصلی به فعالیت های پیاده سازی و آزمون به شمار می رود.
نحوه تولید: برای تولید این مدل نیز مانند تحلیل ابتدا از یک مقدمه متنی کوتاه که حاوی خلاصه مدل است استفاده می شود.
هراسها، واسط ها، پروتکل ها و رخ داد ها(event ) نیز برای user case با استفاده از روابط تجمعی بیان می شوند.
معماری ارجاع: در حقیقت یک الگوی معماری است که از قبل تعریف شده و در دسترس است یا مجموعه ای از این الگوهاست که تا حدی نمونه سازی شده اند و برای استفاده در دامنه های خاص کاری طراحی و استخراج شده اند، این فرآورده با توجه به پروژه های قبلی انجام شده استخراج می شود.
نحوه تولید: با استفاده از نتایج و تجربیات پروژه ها و تکرار های قبلی بدست می آید و در قالب مدل هایی بصورت use case ، Logical ، Deployment ، Data ، پیاده سازی، Process مشخص می شود.
مدل پیاده سازی: نحوه پیاده سازی سیستم از جمله، زیرسیستم ها و عناصر پیاده سازی شده ( راهنماها، کدمنبع، فایلها، داده ها، فایلهای اجرایی) را مدل می کند.
نحوه تولید: مثل مدل طراحی است با این تفاوت که به جای کلاسها از زیرسیستم ها یا عناصر پیاده سازی کننده آن کلاسها و زیرسیستمها و روابط بینشان استفاده می شود.
مستندسازی نرم افزار: (Software architecture Document) : این فرآورده خلاصه جامعی از سیستم ارائه می کند این فرآورده معماری سیستم را از دیدگاههای Use case View ، logical View ، Process View ، Deployment View ،Implementation View ، Data View ، مورد بررسی قرار می دهد.
نحوه تولید: پروتکل: یک توصیف برای مجموعه ای از پورت های یک کپسول.
نحوه تولید: نام پروتکل و توصیف کودهای از نقش و هدف آن تولید می شود.
واسط: یک عنصر مدل که مجموعه از رفتارهای یک classifier ( کلاس، زیرسیستم، مؤلفه) که قابل دسترسی است را مشخص می کند.
نحوه تولید: برای تولید آن نام واسط و توصیف کوتاهی از عملکرد آن بصورت مجموعه ای از attribute و operation ها نمایش داده می شوند.
رخداد: توصیفی را که یک رویداد در یک زمان مشخص رویداد چیزی است که یک سیستم باید در برابر آن پاسخ دهد.
هدف از این فرآورده تشخیص ویژگی های رخ داد مانند فرکانس، وقوع، اولویت، و نیاز مند یهای پاسخ می باشد.
نحوه تولید: برای تولید این فرآورده از دیاگرام های حالت(stat ) یا فعالیت(activity ) استفاده می شود که هر رخداد در آن با یک trigger برای یک گذر حالت نمایش داده می شود.
سیگنال: یک محرک آسنکرون از یک شیء یا نمونه به شیء یا نمونه دیگر است.
نحوه تولید: برای تولید این فرآورده نام آن بصورت یک attribute و توصیف آن به صورت یک توضیح متنی کوتاه مشخص می گردد.
Architectural proof-of- concept : راه حلی که می تواند به سادگی برای نیازمندیهای مهم معماری پیشنهاد شود و در اوایل فاز Inception استخراج می شود.
نحوه تولید: این فرآورده چندین فرم برای نمایش دارد: لیستی از تکنولوژیهای شناخته شده که برای راه حل موردنظر مناسب به نظر می رسند.
طراحی از مدل انتزاعی و کلی یک راه حل با استفاده از نمودارهای UML .
طراحی و توسعه سیستم های نرم افزاری در مقیاس بزرگ با استفاده از متدولوژی RUP در حقیقت در ابتدا این سیستمها را به یکسری زیرسیستم های کوچکتر می شکنیم که تا حد امکان از یکدیگر مستقل باشند و دارای انسجام کافی نیز باشند.
سپس می توانیم پروسه توسعه نرم افزاری RUP ( چهارفاز توسعه به همراه 9 نظم موجود) را برای هر یک از این زیرسیستمها پیاده سازی می کنیم و از کنار هم قراردادن این زیرسیستم ها به زیرسیستم اصلی می رسیم.
ریسکها و خطراتی که در هنگام شکستن یک سیستم در مقیاس بزرگ به زیرسیستم های کوچکتری وجود دارد: 1- اگر سیستم را خیلی خرد کنیم و تعداد این زیرسیستم ها زیاد شود ممکن است که خیلی از جزئیات کلیدی سیستم نادیده گرفته شود.
2- بوسیله شکستن سیستم بصورت فیزیکی به تیم های مجزای فیزیکی ممکن است هرگونه امکان استفاده مجدد از محصولات هر تیم از بین برود.
پس بمنظور جلوگیری از این خطرات و بخاطر اینکه تبدیل یک سیتستم بزرگ به زیرسیستم ها تا حدی حساب شده صورت گیرد.
ابتدا یک تیم طراحی استخراج معماری کلی سیستم بزرگ می شوند این کار با استفاده از نظمهای requirement model , Business model و Analysis & Design صورت می گیرد .
در مرحله طراحی بجای استفاده از کلاسها، از یکسری زیرسیستمها که در حقیقت از شکستن پروژه اصلی بدست آمده اند و توسط یک تیم نرم افزاری معمولی قابل اجرا هستند استفاده می کنیم.
در این طراحی سیستم بزرگ در این مرحله هیچگونه پیاده سازی وجود ندارد.
سپس فرآیند توسعه نرم افزار را با استفاده از مدل RUP برای هر یک از زیرسیتسمها انجام میدهیم.
در این قسمت هر زیرسیستم برای زیرسیستم های دیگر به منزله یک Actor عمل می کند که از طریق interface آن زیر سیستم با آن در ارتباط است.
در حقیقت هر زیرسیستم برای زیرسیستم های دیگر بصورت یک جعبه سیاه عمل می کند که تنها از طریق واسط اش قابل دسترسی است.
در پایان از کنار هم قراردادن این زیرسیستم ها در قالب معماری طراحی شده برای سیستم بزرگ به طراحی لازم برای آن سیستم در مقیاس برزگ دست می یابیم.
1- Development : این نوع از تست توسط توسعه دهندگان نرم افزار صورت می گیرد که معمولاً این نوع تست در هنگام تست واحدهای نرم افزار (unit testing) صورت می گیرد و به جهت برطرف کردن باگها و خطاهایی است که ممکن است در هنگام پیاده سازی صورت گرفته باشد.
2- Independent testing : این نوع تست توسط اشخاص خارج از تیم نرم افزاری صورت می گیرد.
دراین حالت نرم افزار در محیط واقعی تری نسبت به محیط اصلی استقرار تست می شود و یکسری خطاهایی که ممکن است در این محیط ها خود را نشان دهد کشف می شود.
3- Independent Stockholder testing : در قسمت نوعی تست مستقل است سفارش دهندگان نرم افزار صورت می گیرد.
4- Unit testing : در این مرحله کوچکترین واحد قابل تست نرم افزار تست می شود.
در این مرحله سعی می شود تا تمام بخشهای کنترلی واحد و تمام داده های قابل اعمای تا حد امکان تست شوند تا صحت عملکرد واحد کاملاً تأئید شود.
5- Integration testing : هدف از این تست حصول اطمینان از این موضوع است که واحدهای پروژه در کنار هم به درستی کار می کنند و هنگامی که جهت پیاده سازی یک مورد کاربری کنار یکدیگر قرار می گیرند عاری از خطا می باشند.
معمولاً این نوع تست از Independent را جهت تشخیص خطا استفاده می شود و در اکثر موارد از تکنیک Black box برای تست استفاده می گردد.
6- System testing : این تست در هنگامی که محصول نهایی تولیدشده بمنظور بررسی کارکرد سیستم صورت می گیرد وجود تکرار های مختلف در یک فرآیند باعث می شود بتوان این تست را زودتر از موعد مورد انتظار انجام داد.
7- Acceptance test : این تست در حقیقت آخرین تستی است که قبل از استقرار نرم افزار صورت می گیرد.
و هدف از آن بررسی این موضوع است که آیا نرم افزار حاصل آمادگی پاسخگویی به خواسته های کاربران در محیط حقیقی را دارد و بوسیله آنها قابل استفاده است یا خیر.