درباره وبلاگ ![]() آرشیو وبلاگ
لینک های ویژه لوگو ![]() آمار وبلاگ
آقاشیر صلوات صلوات صلوات علی محمد و ال محمد و عجل فرجهم
روشRational Unified Process) RUP) در این بخش یکی از معروفترین رویههای تولید نرمافزار که توسط شرکت آیبیام طراحی گردیدهاست را معرفی میکنیم. این روش با نام Rational Unified Process) RUP) در بسیاری از پروژههای نرمافزاری به کار گرفته میشود. در حقیقت هدف اصلی RUP مطمئنشدن از این موضوع مهم است که آیا نرمافزار تولیدشده نیازهای کاربرانش را به صورت کامل، با کیفیت بالا، در زمان معین و با بودجه مشخص برآورده کرده است یا خیر. مطابق تحقیقات انجام شده، از آن جایی که RUP به تمامی اعضای تیم، اطلاعاتی مشترک میدهد و تمامی اعضای گروه با یک زبان مشترک با هم مرتبط هستند، بازده کاری گروه را بالا میبرد. RUP دارای سه جزء اصلی است. جزء اول از مجموع راهحلهای خوب که در رویه میتواند مورد استفاده قرار گیرد تشکیل شده است. جزء دوم همان مراحل تهیه نرمافزار است و جزء آخر قسمتهای تشکیلدهنده این رویه می باشد. RUP شش راهحل خوب که میتواند در مراحل مختلف این رویه به ما کمک کند را معرفی کرده است. از آن جمله: 1- استفاده از USE CASEها که میتوانند در جمعآوری نیازهای کاربران مفید باشند. 2- استفاده از معماری نرمافزار قابل تغییر (component reuse) 3- استفاده از روشهای تکمیلی و Iterative برای کنترل بهتر و آسان پروژه نرمافزاری 4- استفاده از نمودارهای UML 5- کنترل تغییرات در نرمافزار 6- کنترل کیفیت نرمافزار با توجه به درخواستهای اولیه کاربران شکل 3 رویه RUP را نمایش میدهد. همانطور که در این شکل مشخص شده است چرخه تولید نرمافزار به چهار قسمت اصلی تقسیم شده است: الف: Inception phase یا مرحله آغازین: در این مرحله اهداف پروژه مشخص شده و درخواستهای اولیه کاربران تعریف میشود. از خروجیهای این مرحله میتوان به مدل اولیه Use Case، آزمون ریسک در پروژه و برنامه زمانبندی پروژه اشاره کرد. ب: Elaboration phase یا مرحله مقدماتی: در این مرحله نیازهای کاربران تحلیل و بررسی شده و راهحل کلی طراحی سیستم ترسیم میشود. از خروجیهای این مرحله میتوان از مدل کامل شده Use Case، فهرست نیازهای کامل کاربران و طرح کلی سیستم نام برد. ج: Construction phase: یا مرحله ساخت و توسعه: در این مرحله نرمافزار طراحی شده ساخته میشود و به اصطلاح، کد برنامه نوشته شده و قسمتهای مرتبط به هم ارتباط داده میشوند. از خروجی این مرحله میتوان از نرمافزار، راهنمای استفاده از نرمافزار و مستندات سیستم نام برد. د: Transition phase یا مرحله تغییرات: در این مرحله اگر نرمافزار به وجود آمده در مرحله ساخت دچار مشکل شود، مشکل رفع خواهد شد. تمامی مراحل توسط خطوط عمودی از همدیگر جدا شدهاند و هر مرحله با یک milestone یا نقطه مهم تمام میشود. روش RUP با استفاده از مدلهای مختلف همچنین مشخص میکند چه کسی، چگونه و چه وقت چه کاری را انجام خواهد داد. همانطور که در این قسمت ذکر شد، روش RUP روشی انعطاف پذیر، قابل تغییر و پیشرفته است که میتواند در صورت استفاده صحیح، باعث افزایش کارایی و کیفیت نرمافزار تولیدی گردد. اما آیا RUP میتواند رویه خوبی برای تولید نرمافزارهای کوچک باشد؟ در جواب باید گفت که RUP را طوری طراحی کردهاند که بتواند برای انواع پروژههای نرمافزاری در هر اندازه مفید باشد و از آن جایی که از ابزارهای خوبی مثل UML نیز استفاده میکند، UML) در گروههای کوچک که نرمافزارهای کوچک طراحی میکنند ابزار مدلی خوبی است) میتواند باعث همکاری و هماهنگی بیشتر گروه گردد. اما همانطور که در ادامه این بحث خواهید دید، اگر بتوانیم رویههای سادهتر را با یکدیگر ادغام کنیم، شاید بتوانیم راه حلی با کارایی بالاتری داشته باشیم. روش های PSP و TSP PSP یا Personal Software Process در حقیقت روش تولید نرمافزار نیست بلکه روشی است نوین که با ملزم نمودن اعضای گروه پروژههای نرمافزاری به رعایت اصولی مشخص و استفاده از فرمها و تکالیفی مشخص به آنها کمک میکند کارایی و بهرهوری کاری خود را بالا ببرند. این روش همچنین حاوی تکنیکهای خوبی برای کنترل، اندازهگیری و تشخیص اشکالات میباشد که میتواند به شخص (مثلاً برنامهنویس) کمک کند تا مثلاً با اندازهگیری نرمافزار، یادداشت میزان فعالیت روزانه و ساعات هدر رفته، و اشکالات به وجود آمده، مشکلات را حل کند و در نتیجه بهرهوری خود را بالاتر ببرد. TSP یا Team Software Process مانند PSP است، ولی برای یک تیم طراحی شده و با طرح روشهای منظم جهت کنترل و جمعآوری اطلاعات روزانه به اعضای تیم کمک میکند تا کارایی خود را بالا ببرند. راهحلهای پیشنهادی تا این قسمت با برخی از روشهای تولید نرمافزار آشنا شدیم. اگر دقت کنید تمامی این روشها و رویهها میتوانستند برای تولید نرمافزارهای کوچک مورداستفاده قرار گیرند، اما در ادامه مقاله با چند روش جدید آشنا خواهید شد که در چندین گروه نرمافزاری کوچک مورد آزمایش قرار گرفتهاند و در تمامی موارد بازدهی درخور داشتهاند. در واقع نمیتوان گفت تمامی روشهای زیر روشهای جدیدی هستند، بلکه برخی از آنها از ادغام روشهای بالا به وجود آمدهاند. روش RUP + Scrum همانطور که قبلاً اشاره شد، روش Scrum روشی آسان برای تولید نرمافزار است که مدیریت پروژه و نظم موجود در آن میتواند بسیار کارگشا باشد. حال تجسم کنید که روش RUP را اجرا و قسمتهایی از Scrum را در آن ادغام کنیم. پس از این کار متوجه خواهید شد که روش RUP میتواند از مدل Scrum کمک بگیرد و با ادغام این دو میتوان پروسهای منظم برای تولید نرمافزارهای کوچک سازماندهی کرد. اما همانطور که میدانید نمیتوان دو رویه ناهمگون را با هم ترکیب نمود. آیا RUP و Scrum با هم شباهتهایی دارند؟ همانطور که قبلاً بیان شد، هر دو رویه ساخت نرمافزار روش حلقهای تکرارکننده یا Iterative را خط مشی خود قرار دادهاند(البته در RUP تعریف بهتر و کاملتری از Iterative شده است). در Scrum تعریف نیازهای کاربران توسط اعضای تیم انجام میپذیرد، اما در RUP تنها یک شخصRequirement Engineer) یا مهندس مسئول نیازهای کاربران) است که این مسئولیت را برعهده دارد. در زمینه مدل سیستم اگر چه Scrum مسئولیت انجام این کار را به تمامی اعضای گروه داده است، اما هر دو روش از مدل UML پشتیبانی میکنند و استفاده از آن را پیشنهاد میدهند. ضمناً هر دوی این روشها روشهای هوشمند و Iterative هستند که مدیریت و اندازه گیری کیفیت نرمافزار در تمامی مراحل این رویهها به خوبی دیده میشود. همچنین هر دوی این روشها انجام تغییرات را در طول پروژه مجاز میدانند. البته همانطور که در قسمت Scrum توضیح داده شد، این روش تغییرات را در طول مراحل Sprint مجاز نمیداند، اما مدیر Scrum میتواند تغییرات درخواستی توسط کاربران را جمعآوری و در جلسه بعدی مطرح نماید. به تازگی RUP نیز ابزارهای جدیدی مانند RUP Builder و RUP modeller را عرضه کرده که به مدیران پروژهها اجازه میدهد تا برخی از اصول Scrum را درRUP اجرا کنند. در نتیجه این دو پروسه تولید نرمافزار میتوانند به کمک بیایند و روشی مناسب برای تولید نرمافزارها بهخصوص در اندازه کوچک باشند. موضوع مطلب : |
||