شما اینجایید
خانه > طراحی و پیاده سازی > برنامه نویسی موبایل > فرایند یکپارچه منطقی یا RUP (قسمت دوم)

فرایند یکپارچه منطقی یا RUP (قسمت دوم)

فرایند یکپارچه منطقی

در قسمت اول مقالۀ «فرایند یکپارچۀ منطقی» یا RUP علاوه بر معرفی این فرایند و شش روش مؤثر در آن، به یکی از این روش‌ها پرداختیم. فهمیدیم که در فرایند یکپارچه منطقی، از یک رویکرد تکرارشونده استفاده می‌شود که موارد با ریسک بالا را در هر مرحله در چرخه حیاتی در نظر می‌گیرد و درک مسأله در روند اصلاحات پی‌درپی و رشد تصاعدی یک راهکار در طی چندین تکرار حاصل می‌شود. در ادامه، ۵ روش دیگر را بررسی می‌کنیم.

دوم: مدیریت نیازمندی‌ها در فرایند یکپارچه منطقی چگونگی استخراج، سازماندهی و مستند کردن کارکرد و محدودیت‌های مورد نیاز؛ پیگیری و مستند کردن مصالحه‌ها (سبک و سنگین کردن‌ها) [۱] و تصمیمات؛ و تجسم و انتقال آسان نیازمندی‌های تجاری تشریح می‌شود. اثبات شده است که ایده‌هایی که معمولاً مذموم‌اند، مانند سناریوها و موارد استفاده در فرایند، راه بسیار مناسبی برای تجسم نیازمندی‌های اساسی و اطمینان از پیشروی طراحی، پیاده‌سازی و آزمودن سیستم برحسب این نیازمندی است تا بدینگونه سیستم نهایی بتواند نیازهای کاربر انتهایی را برآورده کند. این ایده‌ها امکان پیشروی دقیق، قابل‌پیگیری و منسجم را چه در توسعه، و چه در سیستم تحویلی فراهم می‌کند.

سوم: استفاده از معماری‌ها بر پایه بر اجزا در این فرایند تمرکز بر توسعۀ اولیه یک معماری قابل‌اجرا و مقاوم و ایجاد یک خط مبنا [۲] برای آن، قبل از مشارکت منابع در این توسعه همه‌جانبه است. در معماری بر پایۀ اجزا، چگونگی طراحی یک معماری بهبودپذیر و انعطاف‌پذیر که با تغییرات سازگار می‌شود، ملموس و قابل‌فهم است، و موجب می‌شود که بتوان از نرم‌افزار به طور موثری مجدداٌ استفاده کرد تشریح می‌شود. در فرایند یکپارچه منطقی از توسعه نرم افزار بر پایه  اجزا [۳] پشتیبانی می‌شود.

اجزا، ماژول‌هایی مهم و سیستم‌های فرعی هستند که یک عملکرد مشخص را به انجام می‌رسانند. در فرایند یکپارچه منطقی،برای تعریف یک معماری با اجزای موجود و جدید، سامانمندی صورت می‌گیرد. این اجزا در یک معماری با تعریف مناسب پیاده‌سازی می‌شوند، چه به طور  مختص و منحصر به سیستم و چه در یک زیرساخت از اجزا، مانند اینترنت، COBRA، و COM  که در آنها شاهد بر ظهور یک صنعت متشکل از اجزای قابل‌استفادۀ مجدد هستیم.

چهارم: نرم‌افزار مدل‌سازی بصری- فرایند به شما نشان می‌دهد که چگونه نرم‌افزار مدل‌سازی بصری را برای دریافت ساختار و رفتار معماری‌ها و اجزا به‌کار بگیرید. از این طریق می‌توانید جزئیات را پنهان کنید و کد را با  «بلوک‌های سازنده گرافیکی» بسازید. انتزاعات بصری به شما در انتقال جنبه‌های مختلف نرم‌افزارتان؛ مشاهده نحوۀ انطباق مؤلفه‌های سیستم؛ اطمینان از تطابق بلوک‌دیاگرام‌ها با کدتان؛ حفظ سازگاری بین طراحی و پیاده‌سازی آن؛ و بهبود ارتباطات بدون ابهام یاری می‌رساند. اساس یک مدل‌سازی بصری موفق، زبان یکپارچه مدل‌سازی (UML) استاندارد صنعتی است که نرم‌افزار Rational ساخته است.

پنجم: بررسی کیفیت نرم‌افزار- عملکرد ضعیف کاربردها و قابلیت‌اعتماد پایین، عامل‌های مشترکی در نپذیرفتن برنامه‌های کاربردی نرم‌افزاری امروزی هستند. بنابراین کیفیت را باید بر حسب نیازمندی‌ها و بر مبنای قابلیت اعتماد، کارکرد، عملکرد کاربرد و عملکرد سیستم بررسی کرد. فرایند یکپارچه منطقی به شما در برنامه ریزی، طراحی، پیاده‌سازی، اجرا و ارزیابی این نوع آزمون‌ها یاری می‌کند. ارزیابی کیفی در تمام فعالیت‌ها با دخیل کردن تمام مشارکت‌کنندگان و استفاده از معیار و اقدامات هدف‌گرا جزئی از این فرایند است؛ این روش فعالیت یا راه جایگزینی است که یک گروه مجزا اجرا می‌کند.

ششم: کنترل تغییرات اعمالی بر نرم‌افزار در این روش از توانایی در مدیریت تغییر، امکان مطمئن شدن از قابل‌قبول بودن یک تغییر، و توانایی در پیگیری تغییرات در یک محیط که تغییر در آن اجتناب‌ناپذیر است، برخورداریم. در این فرایند به چگونگی کنترل، پیگیری و نظارت بر تغییرات برای موفق ساختن توسعۀ تکرارشونده پرداخته می‌شود. به‌علاوه با جداسازی تغییرات ایجادشده در فضاهای کاری دیگر و کنترل تغییرات تمام مصنوعات نرم‌افزاری (مثل مدل‌ها، کد و مستندات و غیره) شما را راهنمایی می‌کند که چگونه محیط‌های کاری امنی را برای هر کدام از توسعه‌دهنده‌ها ایجاد کنید و با توصیف نحوۀ خودکار کردن یکپارچگی و مدیریت ساخت، تیم را به صورت یک واحد منفرد گردآوری کنید.

حال که  شش روش مؤثر  RUP را بررسی کردیم، در قسمت بعدی این مقاله (قسمت سوم)، به مدل‌ فرایند می‌پردازیم.

در خط دید بخوانید:

فرایند یکپارچۀ منطقی (قسمت اول)

فرایند یکپارچه منطقی (قسمت سوم)


[۱] tradeoff

[۲] baselining

[۳] component-based software development

پاسخ دهید

بالا