وجود تکنیک هایی جهت پیاده سازی متدولوژی که قابلیت کنترل پیچیدگی های سیستم را داشته باشد نیز مورد دیگری است که از یک متدولوژی توسعه انتظار می رود. 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 : این رویه از طریق ساختهای مختلف از یک سیستم در سطوح سیستم و زیرسیستم در یک تکرار حمایت می کند. واحد های تست شده با هم مجتمع شده و دوباره تست می شوند.