چه چیز می‌تواند یک پروسه تولید نرم‌افزار را توصیف کند؟
آیا منظور از پروسه، آماده‌سازی نرم‌افزار صرفاً برای ارائه در بازار است؟
مسلماً در هر کاری وجود یک سامانه و فرایند کاری ضروری است؛ ولی چه چیزی می‌تواند موجب ایجاد سرعت و کیفیت در فرایند تولید یک نرم‌افزارشود؟
لزوماً طراحی و پیاده‌سازی یک فرایند یکپارچه و منطقی می‌تواند چنین نتیجه‌ای در بر داشته باشد.
فرایند انجام یک پروژه تعریف می‌کند که چه کسی، چه کاری را در چه هنگام و چگونه برای رسیدن به هدف (انجام پروژه) انجام میدهد.
در مهندسی نرم‌افزار، هدف ساختن یک محصول نرم‌افزاری و یا بهبود یک نمونه‌ی موجود است.
هدف از تعیین فرایند، تضمین کیفیت نرم‌افزار، برآورده شدن نیازهای کاربر و قابل تخمین بودن زمان و هزینه‌ی تولید می‌باشد.
علاوه بر این، تعیین فرایند، روندی جهت تحویل مصنوعات دوران تولید نرم‌افزار به کارفرما و ناظر پروژه ارائه میدهد تا از این طریق اطمینان حاصل کنند که پروژه روند منطقی خود را طی می‌کند و نظارت درست بر انجام پروژه ممکن است و از سوی دیگر، معیاری برای ارزیابی پروژه انجام شده می‌باشد.
تا کنون متدولوژیهای مختلفی برای فرآیند تولید نرم‌افزار ارائه شده‌اند که یکی از مشهورترین آنها 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) در این فاز تعریف محصول تصحیح میشود و معماری آن مشخص میگردد.
همچنین خلاصه برنامه‌ی توسعه و گسترش محصول تدوین میگردد.
در انتهای این فاز اهداف و نمای پروژه دقیقتر تعیین میشوند و انتخاب یک معماری و تبیین ریسک‌های عمده انجام می‌گیرد.
همچنین در این مرحله جزئیات بیشتری از نیازهای سیستم را جمع‌آوری شده و درک بهتری از پروژه صورت می‌پذیرد.
بدین ترتیب تحلیل و طراحی سطح بالایی از سیستم صورت گرفته پایه معماری اولیه سیستم بنا میشود.
در این مرحله نقشه ساخت سیستم تولید شده است.
این مرحله با پرسشهایی نظیر: در حال ساخت چه سیستمی هستیم؟
چه چیزهایی پروژه را به مخاطره می‌اندازد و چه ریسکهایی برای انجام آن وجود دارد.
هر چه ریسکها بیشتر و بزرگ‌تر باشند، دقت بیشتری در انجام پروژه باید صورت گیرد.
این فاز مهمترین در بین چهار فاز ذکر شده است.
فشار کار مهندسی نرم‌افزار در این فاز است.
در این فاز،