چه چیز میتواند یک پروسه تولید نرم‌افزار را توصیف کند؟
آیا منظور از پروسه، آماده‌سازی نرم‌افزار صرفاً برای ارائه در بازار است؟
مسلماً در هر کاری وجود یک سامانه و فرایند کاری ضروری است؛ ولی چه چیزی میتواند موجب ایجاد سرعت و کیفیت در فرایند تولید یک نرم‌افزارشود؟
لزوماً طراحی و پیاده‌سازی یک فرایند یکپارچه و منطقی میتواند چنین نتیجه‌ای در بر داشته باشد.
فرایند انجام یک پروژه تعریف می‌کند که چه کسی، چه کاری را در چه هنگام و چگونه برای رسیدن به هدف (انجام پروژه) انجام میدهد.
در مهندسی نرم‌افزار، هدف ساختن یک محصول نرم‌افزاری و یا بهبود یک نمونه‌ی موجود است.
هدف از تعیین فرایند، تضمین کیفیت نرم‌افزار، برآورده شدن نیازهای کاربر و قابل تخمین بودن زمان و هزینه‌ی تولید می‌باشد.
علاوه بر این، تعیین فرایند، روندی جهت تحویل مصنوعات دوران تولید نرم‌افزار به کارفرما و ناظر پروژه ارائه میدهد تا از این طریق اطمینان حاصل کنند که پروژه روند منطقی خود را طی می‌کند و نظارت درست بر انجام پروژه ممکن است و از سوی دیگر، معیاری برای ارزیابی پروژه انجام شده می‌باشد.
تا کنون متدولوژیهای مختلفی برای فرآیند تولید نرم‌افزار ارائه شده‌اند که یکی از مشهورترین آنها RUP است.
بدین منظور امروزه از متدولوژی RUP استفاده می کنند.
RUP مخفف عبارت( Rational Unified Process) چارچوبی کلی است برای تشریح فرآیند ساخت نرم‌افزار.
پس از آنکه تیم سه نفره‌ی شرکت Rational ساخت UML را (به عنوان یک شیوه‌ی نمایش notation/یکتا برای تشریح مدل شیء) به آخر رساند، تلاش خود را متوجه فرآیند تولید نرم‌افزار نمود.
اساس RUP بر تکرار (iteration) است و اساس تکرار این است که هر تکرار به یک محصول قابل اجرا ختم شود.
هر تکرار شامل هر هفت مرحله چرخه‌ی حیات در مدل سنتی آبشاری است، یعنی: مدلسازی تجاری، تخمین نیازها، تحلیل و طراحی، پیاده سازی، تست، نگهداری و توسعه.
به حداقل رساندن حجم پروسه تولید یک نرم‌افزار همزمان با حفظ کیفیت و صرفه‌جویی در زمان از مهمترین ویژگیهای این روش می‌باشند.
معمولاً برای یک شرکت تولید نرم‌افزار، سرعت عمل به موقع برای پاسخ‌گویی به تقاضا و شرایط اجتماعی اهمیت دارد، اما گاهی این شتابزدگی سبب فدا شدن کیفیت می‌گردد.
RUP با ارائه یک چارچوب منطقی علاوه بر تعیین زمانبندی مناسب، کیفیت مورد نظر تولید کننده و استفاده کننده نرم‌افزار را تأمین می‌نماید.
در این تحقیق ضمن مروری بر RUP به عنوان روش یکپارچه تولید نرم‌افزار، قابلیت‌های آن در افزایش سرعت تولید نرم‌افزار و حفظ کیفیت آن برشمرده می‌شوند.
مقدمه
یک پروسه چابک، پروسه‌ای است که همیشه آماده در آغوش کشیدن درخواستهای جامعه بوده و این درجه از سازگاری را دارا باشد.
بنابراین منظور از سرعت عمل، فقط کاستن از حجم پروسه تولید نرم‌افزار یا سرعت ارائه آن به بازار نیست؛ بلکه منظور، انعطاف‌پذیری و حفظ کیفیت است.
مطلبی که در این مقاله قصد توضیح آن را داریم این است که RUP ساختاری پروسه‌ای (چیو 2000) است که امکان انعطاف‌پذیری را برای تولید‌کنندگان نرم‌افزار فراهم می‌آورد.
RUP متدولوژی ارائه شده توسط شرکت Rational، پرکاربردترین فرآیند تولید و توسعه نرم افزاری در دنیای کنونی است و به عنوان یک استاندارد صنعتی بالفعل در دنیای IT پذیرفته شده است.
به گزارش رویتر در سال 2001 میلادی بیش از ششصد هزار شرکت تولید کننده نرم افزار، از ابزارهای شرکت Rational استفاده می کرده‌اند که این تعداد کماکان هم در حال افزایش است.
این متدولوژی، برای انواع پروژه‌های نرم‌افزاری در دامنه‌های مختلف ( مانند سیستمهای اطلاعاتی، سیستمهای صنعتی، سیستمهای بلادرنگ، سیستمهای تعبیه شده، ارتباطات راه دور، سیستمهای نظامی و ...) و در اندازه‌های متفاوت، از پروژه‌های بسیار کوچک (یک نفر در یک هفته) تا پروژه‌های بسیار بزرگ (چند صد نفر تولید کننده با پراکندگی جغرافیایی)، کاربرد دارد.
مزیت بزرگ این متدولوژی، استفاده از روش تکرار در تولید و مدیریت تولید نرم‌افزار است که این امر، امکان تولید مبتنی بر کاهش ریسک و مواجه با مشکلات اصلی در ابتدای کار و در نتیجه احتمال موفقیت بیشتر را فراهم می‌کند.
از محاسن دیگر این متدولوژی مبنا قرار دادن نرم‌افزار و تولید یک معماری پایدار در ابتدای کار است، که در نتیجه امکان کشف مشکلات عمده ساختاری، تست و مجتمع سازی ممتد را از ابتدای کار فراهم می‌کند.
از دیگر مزایای این روش این است که افراد تیم همزمان با پیشرفت پروژه، مطالب جدیدی فرا می‌گیرند و کیفیت فرآیند تولید نیز به طور مرتب افزایش می‌یابد.
منظور از RUP چیست؟
در این تحقیق از چند منظر به RUP خواهیم پرداخت:
RUP یک پروسه تولید نرم‌افزار است.
RUP مجموعه‌ای از تجربیات بسیار عالی تولید نرم‌افزار را که در عمل با آنها برخورد شده است، در خود دارد.
RUP همانند یک محصول نرم‌افزاری به بازار ارائه شده و به فروش می‌رسد با این تفاوت که RUP اولین ساختار تولید نرم‌افزار را ارائه داده و گام نخست را در این زمینه برداشته است.
امید داریم که این تحقیق مورد قبول مخاطبانش قرار گیرد.
بهار 1387
RUP چیست؟
با پیشرفت تکنولوژی‌های مرتبط با کامپیوتر، نیاز هر چه بیشتر به گسترش علم نرم‌افزاری نیز احساس می‌شد که با پیدایش متدولوژیهای همانند SSADM و روش آبشاری (چیو 2000) آغاز شد.
در ابتدا، این روشها مناسب بود و جوابگوی نیازهای آن زمان بودند ولی با افزایش داده‌ها و پیدایش مفاهیمی همچون شبکه، وب و غیره دیگر کارآیی لازم را جهت پیاده‌سازی و هدایت پروژه‌های نرم‌افزاری نداشتند.
پس مفاهیم برنامه‌نویسی شیءگرا پا به عرصه وجود گذاشتند و در سال 1991 بطور جدی مورد مطالعه و بحث قرار گرفتند.
استفاده از این روشها و متدهای برنامه‌نویسی، قدرت و انعطاف بسیاری را به برنامه‌ها داد و شرکتهای نرم‌افزاری توانستند با کاهش هزینه‌ها و بهینه‌سازی کدهای خود، نرم‌افزارهای قویتری را به بازار عرضه کنند ولی این روش جدید نیز نیاز به مدیریت و یکپارچگی داشت.
پس روشها و متدولوژیهای جدیدی مطرح شد که شامل Booch، OMT، OSE و ...
می‌باشند.
در سال 2000 شرکت Rational روشی را تحت عنوان RUP مطرح ساخت (گروه کاسمیک 2003ب) که بعد از روش MSF شرکت مایکروسافت به دنیای نرم‌افزار عرضه شد و امروزه از طرفداران بسیاری برخوردار است.
فرایند یکپارچه Rational در اصل یک متدولوژی است که در جهت کنترل و انجام پروژه‌های نرم‌افزاری در نظر گرفته شده است.
در اصل این چارچوبی در جهت انجام صحیح و موفق پروژه‌های نرم‌افزاری می‌باشد که کلیه مراحل انجام یک پروژه که با معماری و آنالیز سازمان شروع شده و به تست نرم‌افزار و ارائه Gold Release ختم میشود را در بر می‌گیرد (گروه کاسمیک 2003 الف).
همچنین این فرآیند یک روش نظام‌مند برای تخصیص کارها و مسئولیتها در یک تیم توسعه نرم‌افزار ارائه میدهد و هدف آن تولید نرم‌افزار بصورت بهینه و با کیفیت بالاست که بتواند نیازهای کارفرما را تحت یک برنامه زمانی مشخص و با بودجه قابل پیش‌بینی برآورده سازد.
همچنین این فرآیند یک روش نظام‌مند برای تخصیص کارها و مسئولیتها در یک تیم توسعه نرم‌افزار ارائه میدهد و هدف آن تولید نرم‌افزار بصورت بهینه و با کیفیت بالاست که بتواند نیازهای کارفرما را تحت یک برنامه زمانی مشخص و با بودجه قابل پیش‌بینی برآورده سازد.
RUP بهره‌وری تیم تولید نرم‌افزار را با فراهم نمودن دسترسی تمام افراد تیم به یک پایگاه دانش سهل‌الوصول به همراه راهنماها، الگوها و ابزارهای کمکی برای همه فعالیت‌های حیاتی توسعه، افزایش میدهد.
از آنجا که تمام افراد به منابع یکسانی دسترسی دارند، لذا دید مشترکی برای توسعه نرم‌افزار برخوردار هستند.
RUP امکان استفاده موثرتری از زبان یکپارچه مدلسازی (UML) را فراهم می‌سازد (دقت شود که در عین حال RUP و UML کاملاً مستقل از یکدیگر هستند و نباید آنها را با هم یکی فرض کنیم).
به کمک تکنیک های RUPبخش‌های عمده‌ای از فرآیند تولید نرم‌افزار به طور خودکار انجام شده و همچنین استفاده از مدل‌های تولید شده در فرآیندهای گذشته در پروژه‌های جاری به سادگی امکان‌پذیر است.
این فرآیند با موقعیت‌های مختلف تطبیق یافته و برای سازمانهای بزرگ یا حتی کوچک تولید و توسعه نرم‌افزار قابل استفاده است.
RUP کلیه مراحل انجام یک پروژه شامل تحلیل سیستم، برنامه‌ریزی، بررسی ریسکها، تولید و تست نرم‌افزار را در بر می‌گیرد و چهارچوبی در جهت انجام صحیح و موفق پروژه‌های نرم افزاری فراهم می‌سازد.
چرا RUP را یک فرایند یکپارچه می‌گویند؟
به سه علت RUP را یکپارچه می‌نامند: از UML در جهت کارهای خود استفاده می‌کند.
در واقع میتوان گفت UML خود ثمره RUP می‌باشد و این خود بسیار خوب است که متدولوژیی با خودش گسترش یابد .مفاهیمی از قبیل Object، Class و ...
مفاهیم ساده و ثابتی هستند ولی قبلاً متدولوژیها علامتهای خاصی داشتند که اکنون همه آنها یکسان شده‌اند.
در داخل RUP یک چارچوب تولید نرم‌افزار است که ما آنرا برای سازمان و پروژه خود بومی می‌کنیم و میتوان گفت که در واقع یک قالب فرایند است.
این فرآیند از ترکیب و یکپارچه‌سازی چند فرآیند و متدولوژی شامل Booch، OMT و OSE دیگر ایجاد شده است.
شکل 1 ساختار اصلی RUP را مشخص می‌کند.
اگر در بعد زمان به آن نگاه کنیم شامل 4 فاز می‌باشد و اگر در هر لحظه به آن نگاه کنیم شامل 9 قالب خواهد بود.
شکل 1.
ساختار اصلی RUP فازهای RUP در RUP کل فرآیند تولید نرم‌افزار به چهار فاز اصلی تقسیم میشود، که هر فاز میتواند شامل یک یا چند تکرار باشد.
هر فاز شامل مسیری است که بین دو گردنه (milestone) قرار دارد.
این چهار فاز عبارتند از: آغاز (inception) جزییات (elaboration) ساخت (construction) انتقال (transition) فازآغازین (Inception) پایه پروژه و ابعاد آن در این مرحله مشخص می‌شوند.
در این مرحله پروژه به طور کلی بررسی شده و هزینه و درآمد ناشی از آن محاسبه می‌گردد.
در این مرحله برداشتی اجمالی از ابعاد پروژه بدست می‌آید.
در انتهای این مرحله تصمیم برای انجام یا عدم انجام پروژه اتخاذ خواهد شد و تعهد لازم از کارفرما تهیه میشود.
هدف اصلی این فاز دستیابی به توافق میان کلیه‌ی ذینفعان بر روی اهداف چرخه‌ی حیات پروژه است.
فاز Inception به دلیل تلاشهای تولید و توسعه جدید به صورت پایه‌ای اهمیت فراوانی دارد که در آن ریسکهای نیازسنجی و تجاری مهمی وجود دارد که باید پیش از اینکه اجرای پروژه مورد توجه قرار گیرد، بررسی شوند.
برای پروژه‌هایی که بر توسعه سیستم موجود متمرکزند، فاز Inception کوتاه تر است، با این حال این فاز برای حصول اطمینان از اینکه پروژه ارزش انجام دادن دارد و امکان‌پذیر نیز هست، انجام میشود.
در این فاز مدل تجاری سیستم رسم و دورنمای پروژه ترسیم میشود.
برای این کار باید همه‌ی موجودیت‌هایی که سیستم با آنها تعامل دارد(بازیگران )شناخته شوند و نحوه تعاملشان با سیستم مشخص گردد.
این شامل تعیین همه‌ی موارد کاربرد (use case) و توضیح برخی از موارد مهم است.
مدل تجاری شامل شرایط موفقیت، برآورد ریسکها و تخمین منابع مورد نیاز است.
همچنین یک برنامه‌ی کلی که زمانبندی مراحل انجام پروژه را نشان دهد.
اهداف فاز آغاز • بدست آوردن محدوده نرم‌افزاری پروژه و محدودیت‌های آن که شامل یک دید عملیاتی، معیار پذیرش و اینکه چه چیز باید در محصول باشد و چه چیز نباید باشد، میشود • مشخص کردن Use-Case های اساسی سیستم، سناریوهای اصلی عملیات که مسائل مربوط به طراحی اصلی را ایجاد می‌کند.
• نمایش و شاید توضیح حداقل یک معماری کاندیدا برای بعضی سناریوهای اصلی • برآورد هزینه و زمان کلی برای کل پروژه در انتهای این فاز اهداف چرخه‌ی حیات پروژه را تعیین می‌کنید و تصمیم می‌گیرید که آنرا ادامه بدهید یا نه.
در مجموع هدف اصلی این فاز بدست آوردن هماهنگی بین تمام افراد درگیر با پروژه درباره‌ی اهداف پروژه است.
اهداف فرعی دیگرعبارتند از : تعیین حدود و دورنمای پروژه تعیین موارد کاربرد حییاتی سیستم و سناریور اولیه آنها تعیین سناریوهای جایگزین تخمین هزینه و زمان پروژه تخمین ریسکهای احتمالی خروجیهای فاز آغاز سند نمای کلی (vision) : دید کلی به هسته‌ی اصلی نیازهای پروژه، قابلیت‌های کلیدی و حدود اصلی مدل مورد کاربرد: مشخص کردن همه‌ی موارد کاربردی که در این مرحله‌ی مقدماتی می‌توانند شناسایی شوند لغتنامه‌ی اولیه مدل تجاری اولیه، شامل زمینه‌ی تجارت، شرایط موفقیت، الزامات تجاری تخمین خطای اولیه برنامه‌ی اولیه که فازها و تکرارها را نشان میدهد.
فاز جزئیات یا تحلیل پیچیدگی (Elaboration) در این فاز تعریف محصول تصحیح میشود و معماری آن مشخص می‌گردد.
همچنین خلاصه برنامه‌ی توسعه و گسترش محصول تدوین می‌گردد.
در انتهای این فاز اهداف و نمای پروژه دقیقتر تعیین می‌شوند و انتخاب یک معماری و تبیین ریسکهای عمده انجام می‌گیرد.
همچنین در این مرحله جزئیات بیشتری از نیازهای سیستم را جمع‌آوری شده و درک بهتری از پروژه صورت می‌پذیرد.
بدین ترتیب تحلیل و طراحی سطح بالایی از سیستم صورت گرفته پایه معماری اولیه سیستم بنا میشود.
در این مرحله نقشه ساخت سیستم تولید شده است.
این مرحله با پرسشهایی نظیر: در حال ساخت چه سیستمی هستیم؟
چه چیزهایی پروژه را به مخاطره می‌اندازد و چه ریسکهایی برای انجام آن وجود دارد.
هر چه ریسکها بیشتر و بزرگ‌تر باشند، دقت بیشتری در انجام پروژه باید صورت گیرد.
این فاز مهمترین در بین چهار فاز ذکر شده است.
فشار کار مهندسی نرم‌افزار در این فاز است.
در این فاز، در یک یا چند تکرار، یک پیش نمونه (prototype) قابل اجرا از معماری سیستم ساخته میشود.
تعداد تکرارها بستگی به نما، اندازه، ریسک و جدیدبودن پروژه دارد.
بررسی ریسکها ریسکهای مرتبط با نیازمندیهای سیستم هدف رسیدن به سیستمی است که خواسته‌های کاربر را به درستی انجام دهد.
مهم است که این نیازمندیها به درستی درک شده باشند.
در اینجا استفاده صحیح از UML میتواند بسیار موثر باشد.
یوزکیس‌ها ابزارهای مهمی هستند زیرا تقابل کاربر با سیستم را بطور دقیق مشخص می‌کنند و اساس ارتباط کارفرما با تولیدکننده نرم‌افزار هستند.
باید مهمترین و پرخطرترین یوزکیس‌ها به طور مشخص تعیین شوند.
هر چه بیشتر با کاربران نهایی سیستم مذاکره شود نتایج بهتری حاصل خواهند گشت.
لازم است نمونه‌های اولیه برای قسمت‌های پیچیده و حیاتی یوزکیس‌ها باید ساخته شوند.
در همین زمان سایر نمودارهای مدلسازی نظیر نمودارهای کلاس (Class Diagrams)، نمودارهای فعالیت (Activity Diagram) و نمودارهای تقابل (Interaction Diagrams) نیز به کمک کاربران سیستم بخصوص کاربران ارشد که اطلاعات بیشتر و مهم‌تری از عملکرد سیستم دارند باید تهیه شوند.
ریسکهای تکنولوژیکی از خود می‌پرسیم، آیا تکنولوژی لازم برای ساختن این سیستم را در اختیار داریم؟
باید نمونه‌های اولیه‌ای از سیستم ساخته شده و عملکرد آنها تحت سیستم پیش‌بینی شده بررسی گردد.
طراحی معماری سیستم در این مرحله صورت می‌گیرد.
باید اجزا تشکیل دهنده سیستم، روش ساخت یا تهیه و طریقه اتصال آنها به یکدیگر مشخص شوند.
بهتر از قسمت‌هایی که تغییر آنها سخت‌تر (یا غیرممکن) است در این فاز مدنظر قرار گرفته شوند تا در صورت عدم هماهنگی در همین مرحله تصمیمات مناسب اتخاذ شوند.طراحی سیستم باید بگونه‌ای باشد که در آینده تغییرات و توسعه آن قابل انجام باشد.
باید یوزکیس‌ها را بطور دقیق بررسی کنیم تا مسائلی که ممکن است طراحی سیستم را پیچیده‌تر کنند به طور واضح مشخص گردند.
نمودارهای UMLزیر در این مرحله بکار می‌آیند: نمودارهای کلاس و نمودارهای تقابل: اجزاء سیستم (Components) و نحوه تقابل آنها را نشان می‌دهند.
نمودارهای بسته بندی (Package Diagrams): یک دید سطح بالا از اجزاء سیستم فراهم می‌آورند.
نمودارهای گسترش (Deployment Diagrams): تصویری از چگونگی توزیع (پراکندگی) اجزاء سیستم نشان می‌دهند.
ریسکهای منابع انسانی برخی اشتباهات برنامه‌نویسان به سختی قابل کشف و حل هستند و رفع آنها مستلزم صرف وقت و هزینه بالایی است .
آموزش نقش مهمی در این راستا بازی می‌کند چرا که پیشگیری بهتر از درمان است.
اگر این امکان فراهم شود که برخی از اعضاء که در مراحل تولید پروژه‌های مهم‌تر نقش داشتهاند و تجربه بیشتری دارند، هر چند برای مدتی کوتاه در پروژه همکاری کنند ریسک مشکلات ناشی از نیروی انسانی تا حد زیادی کاهش خواهد یافت.
ریسکهای سیاسی هرچند در نگاه اول ممکن است عجیب به نظر برسد، ولی با رشد روزافزون رایانه‌ها و سیستمهای مبتنی بر رایانه امکان بروز تعارض میان سیستم نرم‌افزاری ساخته شده و مسائل امنیتی وجود دارد.
بهتر است در مورد یوزکیس‌هایی که با مردم جامعه یا سازمانها (بخصوص سازمانهای دولتی) تعامل خواهند داشت در همین مرحله سیاستهای واضحی مشخص گردد.
هنگامی که بتوانیم مدت زمان لازم برای تولید هر یوزکیس را تخمین بزنیم و تمام ریسکهای مهم بررسی و راه‌حل‌های مقابله با آنها برنامه‌ریزی شده باشند، میتوان گفت مرحله دوم خاتمه یافته است.
اهداف فاز جزییات هدف فاز جزئیات تعیین معماری کلی سیستم به منظور فراهم آوردن یک زمینه‌ی مناسب برای قسمت عمده‌ی طراحی و پیاده‌سازی در فاز Construction است.
معماری با درنظرگرفتن بیشتر نیازمندیهای مهم (آن دسته از نیازمندیها که تأثیر زیادی بر معمار سیستم دارد) و نیز ارزیابی ریسک کامل میشود.
پایداری معماری از طریق یک یا چند نمونه‌ی اولیه ساختاری ارزیابی میشود.
همچنین هدف این فاز آنالیز دامنه‌ی مساله و ایجاد یک پایه‌ی درست برای معماری، توسعه‌ی برنامه‌ی پروژه و برطرف کردن عمده‌ترین ریسکهای پروژه است.
تصمیم‌ها در مورد معماری باید بر اساس درکی از کل سیستم اتخاذ شوند.
این متضمن آن است که بیشتر موارد کاربرد توصیف شوند.
اهداف اولیه این فاز عبارتند از: تعریف و تصحیح معماری، با بیشترین سرعت ممکن به دست آوردن یک برنامه‌ی درست برای فاز ساخت اثبات اینکه معماری مورد نظر، نیاز پروژه را با هزینه و زمان معقولی تامین می‌کند.
اهداف اصلی فاز جزئیات شامل موارد زیر است : • اطمینان از اینکه معماری، نیازمندیها و طرح‌ها به اندازه‌ی کافی پایدارند و ریسکها به اندازه‌ی کافی کاهش یافته‌اند بطوریکه بتوان هزینه و زمانبندی لازم برای تکمیل تولید را پیش‌بینی کرد.
برای اکثر پروژه‌ها، گذر از این مرحله‌ی مهم مانند انتقال از یک عملیات سبک و سریع و با ریسک پایین به یک عملیات با هزینه و ریسک بالا همراه با اجبار سازمانی است.
• بیان همه‌ی ریسکهای پروژه که از نظر ساختاری اهمیت دارند.
• ایجاد یک معماری پایه، مشتق شده از سناریوهای مهم که از لحاظ ساختاری اهمیت دارند، که این معماری ریسکهای فنی عمده پروژه را نیز مشخص می‌کند.
• تولید یک نمونه‌ی اولیه‌ی تکاملی از مولفه‌های با کیفیت تولیدی خوب، و همچنین یک یا چند نمونه‌ی اولیه‌ی اکتشافی و نمونه‌های اولیه‌ی غیر قابل استفاده جهت کاهش ریسکهای خاص مانند : O سازش‌های مربوط به نیازمندیها یا طراحی O استفاده‌ی مجدد از مؤلفه‌ها O عملی بودن محصول یا توضیحات برای سرمایه گذاران، مشتریان و کاربران نهایی • توضیح اینکه معماری پایه از نیازمندیهای سیستم با هزینه‌ی منطقی و در زمان منطقی پشتیبانی می‌کند .
• ایجاد یک محیط پشتیبانی کننده خروجیهای فاز جزییات مدل مورد کاربرد دیدن نیازهای اضافی و غیرکارکردی که به مورد کاربرد خاصی وابسته نیستند.
یک نسخه‌ی قابل اجرا از معماری و مستندات پیوست (سند معماری نرم‌افزار) شامل طراحی زیر مجموعه‌ای از موارد کاربرد و لغتنامه‌ی اصلاح شده مدل تجاری تجدید نظر شده فهرست ریسکهای تجدید نظر شده برنامه‌ی توسعه‌ی پروژه راهنمای اولیه‌ی کاربر فاز ساخت (Construction) در طول فاز ساخت، به صورت تکراری (iteratively) و افزایشی (incrementally) محصول نهایی کامل تولید میشود، که برای انتقال به کاربر آماده است.
این متضمن تبیین موارد کاربرد باقیمانده و سایر نیازمندیها، تبیین طراحی، تکمیل پیاده سازی، و تست نرم‌افزار است.
در انتهای این مرحله تصمیم می‌گیرید که آیا نرم‌افزار، سایت و کاربران برای شروع بکار سیستم آماده‌اند یا نه.
در طول این مرحله همه‌ی اجزای باقیمانده ساخته می‌شوند و قابلیت‌های کاربردی توسعه یافته به محصول افزوده و تست می‌شوند.
در این مرحله تاکید و توجه بر مدیریت منابع و کنترل عملیات برای بهینه کردن هزینه‌ها، زمانبندی و کیفیت است.
اغلب پروژه‌ها آنقدر بزرگ هستند که کارهای این مرحله بصورت موازی انجام گیرند.
این فعالیت‌های موازی باعث تسریع در تولید می‌شوند، همچنانکه می‌توانند پیچیدگی مدیریت منابع را زیاد کنند.
این مرحله به روش افزایش-تکرار صورت می‌گیرد.
به این معنی که بر خلاف روشهایی مانند توسعه آبشاری (SSADM) که ممکن است در برخی زمانها بعضی از اعضای تیم به دلیل انتظار برای دریافت نتیجه گروهی دیگر از اعضای تیم بیکار بمانند، در RUP اساس کار بر تولید قطعات سیستم به صورت مرحله به مرحله است و در هر مرحله عملکرد قطعه تولید شده بهبود می‌یابد.
لذا پس از به جریان افتادن فرآیند اعضای تیم بیکار نمانده و به افزایش حجم و دقت عملکرد قطعه تولیدی قبلی خود می‌پردازند.
دقت شود که هر قطعه تولید شده خود یک نرم‌افزار نسبتاً کامل بوده و باید توانایی برآورده کردن نیازهای مشخصی را داشته باشد، بدین معنی که قطعات تولید شده باید قابل استفاده باشند.
برای تولید هر قطعه تمام این چهار مرحله انجام شده است!
این نکته مهمی در RUP است و میتوان اینگونه در نظر گرفت که محصول نهایی به شکل یک پیاز بوده و دارای لایه هایی است که هم برای تولید هر لایه و هم برای تولید کل پیاز این مراحل چهارگانه صورت گرفته‌اند.
بطور خلاصه نتیجه این فاز کدنویسی و ایجاد نرم افزار است.
یکی از مهمترین ویژگیهای کیفی یک معماری خوب، سادگی ساخت آن است.
این یکی از دلایل آن است که تعادل میان توسعه‌ی معماری و برنامه‌ریزی در فاز جزییات مورد توجه بود.
اهداف فاز ساخت هدف این فاز واضح سازی نیازمندیهای باقیمانده و تکمیل تولید سیستم بر اساس معماری مبنا می‌باشد.
فاز ساخت به نوعی یک فرآیند ساخت است که در آن تأکید بر مدیریت منابع و کنترل عملیات به منظور بهینه‌سازی هزینه‌ها، زمان‌بندی‌ها و کیفیت است.
در این حالت یک انتقال از تولید یک نمونه‌ی ذهنی در طی فازهای Inception و Elaboration به تولید محصولات قابل استقرار در طی Construction وTransition میشود.
کمینه‌کردن هزینه‌های توسعه با بهینه کردن منابع و اجتناب از ضایعات و دوباره‌کاری‌های غیرلازم بدست آوردن کیفیت کافی در کمترین زمان ممکن بدست آوردن نسخه‌های مورد نیاز (آلفا، بتا و سایر نسخه‌های تستی) در کمترین زمان ممکن کامل کردن تحلیل، طراحی، تولید و تست کارآیی مورد نیاز تولید تکراری و گام به گام یک محصول کامل که آماده‌ی انتقال به محیط کاربران باشد تصمیم در مورد اینکه آیا نرم‌افزار، سایت‌ها و کاربران همه برای استقرار طرح آمادگی دارند دستیابی به میزانی از موازی سازی در کار تیم‌های تولید.
خروجیهای فاز ساخت خروجی فاز ساخت محصولی است که برای قرار گرفتن در دستهای کاربر نهایی‌اش آماده است.
این شامل موارد زیر است: محصول نرم‌افزاری، سوار شده بر سکو راهنمای کاربر و توضیحی درباره‌ی نسخه‌ی فعلی فاز انتقال (Transition) در این مرحله محصول در دستهای کاربر نهایی قرار می‌گیرد.
معمولا در این مرحله مواردی مطرح می‌شوند که نیاز به کار بیشتر برای میزان کردن سیستم و تصحیح مشکلات پیش‌بینی نشده دارد.
این مرحله معمولا با یک نسخه‌ی بتا آغاز میشود.
در پایان این مرحله تصمیم می‌گیرید که آیا اهداف چرخه تولید محقق شده‌اند یا نه، و اینکه آیا باید چرخه‌ی دیگری آغاز شود؟
این فاز خود میتواند شامل چند تکرار (مانند نسخه‌ی بتا، نسخه‌ی نهایی و رفع خطاهای کوچک و ریزه‌کاری‌ها) باشد.
همچنین مسائلی چون آموزش کاربران و تبدیل داده از پایگاه داده‌ی فعلی به جدید مورد توجه قرار می‌گیرند.
فعالیتهایی که در تکرار‌های این فاز انجام می‌شوند، بستگی به هدف آن دارند: برای رفع خطاهای کوچک، کار کدنویسی زیادی لازم نیست، ولی اگر قابلیت جدیدی باید به محصول اضافه شود، تکرار شبیه فاز ساخت خواهد بود.
همچنین تمرکز این فاز بر این است که تضمین نماید نرم‌افزار برای کاربران نهایی آماده می‌باشد.
فاز Transition میتواند به چندین تکرار تقسیم شود، و شامل تست کردن محصول برای آماده‌سازی جهت انتشار و ایجاد تنظیمات کوچک بر اساس بازخورد کاربر می‌باشد.
در این نقطه از چرخه‌ی حیات، بازخورد کاربر باید بطور عمده بر تنظیم دقیق محصول، پیکربندی، نصب و نکات مربوط به قابلیت استفاده تمرکز یابد، و همه‌ی نکات ساختاری اصلی باید هرچه زودتر در چرخه‌ی حیات پروژه طرح شوند.
با به اتمام رسیدن فاز Transition اهداف چرخه‌ی حیات باید برآورده شده باشند و پروژه در موقعیتی باشد که بتوان آنرا خاتمه داد.
در برخی موارد، پایان چرخه‌ی حیات فعلی ممکن است با آغاز چرخه‌ی حیات بعدی در مورد همان محصول همزمان شود و ما را به سمت تولید یا ویرایش دیگری هدایت کند.
برای پروژه‌های دیگر، پایان فاز Transition ممکن است با تحویل کامل خروجی‌ها به گروه سومی که ممکن است مسؤول عملیات نگهداری و پیشرفت سیستم تحویل دهده شده می‌باشند، همزمان شود.
این فاز بر اساس نوع محصول در فاصله‌ی بسیار ساده تا بی‌نهایت پیچیده قرار دارد.
نصب یک نسخه‌ی جدید از یک بسته نرم‌افزاری موجود ممکن است بسیار ساده باشد، در حالیکه جایگزینی سیستم کنترل ترافیک هوایی یک کشور ممکن است بسیار پیچیده باشد.
فعالیتهایی که در طول یک تکرار در فاز Transition انجام می‌گیرد به هدف بستگی دارند.
برای مثال معمولاً در هنگام رفع اشکالات، پیاده‌سازی و تست کافی هستند.
با این وجود اگر ویژگیهای جدیدی باید اضافه شوند، این تکرار شبیه به تکراری در فاز Construction میشود که نیازمند تحلیل و طراحی و غیره است.
فاز Transition زمانی وارد عمل میشود که یک خط مبنا آنقدر بالغ شده که بتواند در دامنه‌ی کاربر نهایی استقرار یابد.
این امر بطور نمونه نیازمند این است که تعدادی زیر مجموعه‌ی قابل استفاده از سیستم با کیفیت قابل قبول و مستندات کاربر، کامل شده باشند، تا انتقال به کاربر نتایج مثبتی را برای همه‌ی گروه‌ها در بر داشته باشد.
اهداف فاز انتقال اهداف مهم فاز Transition عبارتند از : تست بتا برای تشخیص اعتبار سیستم جدید با توجه به انتظارات کاربر تست بتا و عملیات موازی همراه با یک سیستم قدیمی که در حال جایگزینی می‌باشد.
تبدیل پایگاه‌های داده‌ی عملیاتی آموزش کاربران و نگهداری کنندگان بازاریابی، توزیع و فروش برای نخستین انتشار محصول تنظیم فعالیتها از قبیل رفع اشکال، افزایش کارایی و قابلیت استفاده ارزیابی خط مبناهای استقرار در مقایسه با تصویر کلی و معیار قابلیت قابل قبول برای محصول دستیابی به موافقت ذینفع در مورد اینکه خط مبناهای استقرار کامل می‌باشند دستیابی به موافقع ذینفع در مور اینکه خط مبناهای استقرار با معیار ارزیابی تصویر کلی سازگارند.
کسب توانایی خود-پشتیبانی توسط کاربر بدست آوردن و آغاز بکار محصول نهایی با بیشترین سرعت و کمترین هزینه خصوصیات RUP چیست؟
RUP مبتنی بر نوعی معماری است که به اجزاء اصلی می‌پردازد ولی طراحی به جزئیات نیز وارد میشود.
همچنین میتوان گفت معماری یکسری اجزا و ارتباط بین آنها است که سیستم را می‌سازد و ما را به سمت توسعه مؤلفه‌محورراهنمایی می‌کند.
ویژگی Usecase Driven: یکی از مشکلات OOA این بود که می‌گفتند با هر روشی تبدیل و کار کنند و بعد بتوان آنرا به شیءگرا تبدیل کرد.
یعنی مثلاً پروژه SSADM را طراحی کرده و بعداً به شیءگرا تبدیل نمود.
ولی آن عقیده اشتباه بود و حتماً تحلیل شیءگرا باید صورت بگیرد.
خصوصیت خوب شیءگرا که در دیگر روشها نمی‌باشد این است که نوتاسیونی که استفاده میشود (بوچ، رامباق و جاکوبسون 1999) در همه مراحل یکی است یعنی مفاهیمی از قبیل شیء، کلاس، روابط کلاسها و ...
در تمامی مراحل یکی است.
اهمیتی که Usecase Driven دارد این است که با زبان مشتری نوشته میشود.
مشتری میتواند آنرا بفهمد و بسیار مناسب برای تشخیص نیازمندیهای سیستم می‌باشد.
در بخش تحلیل و طراحی از روی Usecaseها تحلیل و طراحی انجام می‌دهیم و مسائلی مانند مدیریت پروژه نیز تحت تاثیر Usecaseها هستند که ما آنها را دسته‌بندی کرده و مدیریت می‌کنیم.
همچنین راهنماهای سیستم هم تحت تاثیر Usecaseها (کراچتن 2000، 298) ایجاد می‌شوند.
ویژگی Incremental: به معنی آن است که پروژه بصورت چهار مرحله حلقه‌ای جلو می‌رود ولی در هر مرحله چرخش یک دسته از Usecaseها کامل و آماده استفاده میشود و کلیه این کارها در 9 جریان کار که در شکل 1 مشخص شده بود، قابل مشاهده است.
و همچنین مبتنی بر تکرار است و قابلیت استفاده مجدد را فراهم می‌سازد زیرا پروژه به قطعات کوچک تقسیم و انجام میشود.
مهمترین مزایای RUP تسهیل توسعه تکراری نرم‌افزار مدیریت نیازها مدل کردن تصویری نرم‌افزار بازبینی کیفیت نرم‌افزار کنترل تغییرات در نرم‌افزار امکان استفاده از طریق وب دیدگاه اولیه درباره RUP دیدگاهی که RUP بر اساس آن طراحی شده، به گونه‌ای است که محدوده وسیعی از اهداف را پوشش دهد تا ضمانت اجرایی جهت انطباق با موارد زیر حاصل شود: ابعاد پروژه حوزه کاربردی برنامه (سیستمهای تجاری یا سیستمهای فنی) زمینه‌های تجارت (توسعه خانگی، توسعه محصولات، فروشندگان نرم‌افزار مستقل، توسعه قراردادی).
همانند هر ساختار پروسه دیگری، RUP نیز روش سیستماتیکی را برای به دست آوردن، سازماندهی و ارائه راهکارهای مهندسی نرم‌افزار در اختیارتان قرار میدهد.
RUP برای سازماندهی راهکارها، بر یک مدل پروسه ساده و کاملاً زیربنایی استوار شده است که توضیح این امر در قالب چند مقاله یا کتاب نمی‌گنجد.
با این وجود، ساختار پروسه مزبور را نمی‌توان به یک ظرف خالی تشبیه نمود.
این ساختار از قبل توسط حجم عظیمی از پروسه‌های راهکاری که قبلاً در پانزده سال گذشته توسط ملیت‌های مختلف تحصیل شده است و با شرکت Rational ارتباط داشتهاند (افرادی که قبلاً این شرکت آنها را به خود جذب کرده و برخی از شرکای این شرکت نظیر IBM ، HP و BEA (کراچتن 2003)) انباشته گردیده است.
RUP مجموعه محدود و بسته‌ای نیست که به منظور کاربردهای عمومی منتشر شده باشد و پاسخ یا راه‌حل تمامی مشکلات توسعه نرم‌افزاری را دربرگیرد؛ بلکه ساختار RUP ساختار بازی است که به منظور استنتاج باید شاخه‌های آنرا دنبال کنید و این ساختار سالانه دوبار روزآمد می‌گردد.
ساختار RUP تصفیه شده است و پشتیبانی ابزاری و مندرجات آن نیز توسعه یافته‌اند.
از یک سو، گروه توسعه پروسه شرکت Rational، امر به روز سازی محتویات RUP را همگام با مقتضیات فن‌آوری و بازخوردهایی که کاربران این ساختار ارائه می‌دهند، به عهده دارند و از سوی دیگر شرکای متعدد این شرکت و افرادی که RUP را برای استحصال و سازماندهی فرایندهای راهکاری خود پذیرفته‌اند و از آن برای اهداف مربوط به خود استفاده می‌کنند، ساختار ارائه شده توسط شرکت Rational را تبلیغ نموده و آنرا را تکمیل می‌کنند.
ساختار RUP پیرامون چند منطق ساده و مرتبط به هم سازماندهی شده است: RUP نقشهایی را تعریف می‌کند که باید در پروسه وجود داشته باشد و بر مبنای آن، صلاحیتها، تخصصها و مسئولیتهای افرادی که باید پیشرفت پروژه را محقق سازند، مشخص میشود.
RUP کارهایی را که هر یک از افراد باید در عمل انجام دهند، به طور گام به گام تشریح می‌کند.
این عملیات با استفاده از ابزارهایی واقعی مانند مدل‌ها، کدها، اسناد و گزارشها اداره می‌شوند.
در RUP به وفور با راهنماییهای مربوط به نقشهایی که افراد باید به عهده بگیرند، فعالیتهایی که باید انجام شوند و مصنوعات مورد نیاز برخورد خواهید نمود که در قالب خطوط راهنما، الگوها، مثالها و معلمهای ابزاری ارائه می‌شوند که چگونگی به وقوع پیوستن دستهای از فعالیتها توسط یک ابزار بخصوص را شرح می‌دهند.
تمامی این المانهای توصیف پروسه در قالب سامانه‌هایی سازماندهی شده‌اند.
RUP مقدماتی نه سامانه، بیش از چهل نقش و صد محصول را تعریف می‌کند و حاوی بیش از هزار صفحه راهنما است.
همچنین می‌توانید به پروسه‌های الحاقی متعددی که وظایف و مندرجات بیشتری را به RUP اضافه می‌کند، دسترسی پیدا کنید.
برخی از منتقدین RUP آنرا پروسه‌ای بسیار سنگین تصور نموده و آنرا به کرگدنی تشبیه می‌کنند که توان انجام تعداد نامحدودی عمل غیر معمول را برای شما فراهم می‌آورد؛ با این وجود نگاه ما به RUP همانند لوح باشکوهی از معارف است که می‌توانید آنچه را که نیاز دارید، از داخل آن برگزینید.
اجازه بدهید مقایسه‌ای انجام دهیم.
اگر فرهنگ لغات مناسبی از 800 لغت را انتخاب کرده باشید، می‌توانید در خیلی از نقاط دنیا و در بسیاری شرایط، گلیم خود را از آب بیرون بکشید؛ ولی با انتخاب فرهنگ لغات حجیمی چون Webster ، اولاً هیچ‌کس شما را مجبور به استفاده از لغاتی که در فرهنگ لغات وجود دارد نمی‌کند، ثانیاً می‌توانید سطح لغات محفوظی خود را برای انطباق با وضعیتهای مختلف ارتقا ببخشید و ثالثاً می‌توانید فرهنگ لغات خود را بهبود دهید.
فرهنگ لغت800 لغتی باید فقط زیرمجموعه‌ای از یک فرهنگ لغات باشد.