-
معرفی و بررسی کامل دیسیپلین‌های rup
دیسیپلین مجموعه‌ای از کارهای به هم مرتبطی است که برای انجام جنبه خاصی از یک پروژه انجام میشوند. متدولوژی rup دارای 6 دسیسپلین اصلی (مربوط به تولید محصول) و 3 دیسیپلین كمكی (مربوط به تیم و محیط تولید) است كه در ادامه به ترتیب معرفی خواهند شد.
-
Business Modeling (مدل‌سازی كسب و كار)
اهداف مدل‌سازی كسب و كار عبارتند از:
• شناخت ساختار و دینامیك‌های سازمانی كه در آن یك سیستم باید استقرار یابد(سازمان هدف.)
• شناخت مشكلات فعلی در سازمان هدف و تشخیص پتانسیل‌های بهبود
• تضمین اینكه مشتری، كاربر نهایی و تولید كنندگان یك شناخت مشترك از سازمان هدف دارند.
• هدایت نیازمندی‌های سیستم كه برای حمایت از سازمان هدف مورد نیازند.
دیسیپلین مدل‌سازی كسب و كار توضیح می‌دهد كه برای رسیدن به این هدف چگونه می‌توان یك تصویر كلی از سازمان را تولید نمود، و براساس این تصویر كلی فرآیندها، نقش‌ها و مسؤولیت‌های آن سازمان را در یك مدل Use-case كسب وكار و یك مدل شیء كسب و كار تعریف كرد
-
Requirements (نیازمندی‌ها)
اهداف دیسیپلین نیازمندی‌ها عبارتند از:
• تشخیص و نگهداری موارد توافق با مشتری‌ها و سایر ذینفعان در مورد كارهایی كه سیستم باید انجام دهد.
• فرآهم آوردن شناخت بهتر از نیازمندی‌های سیستم برای تولید كنندگان سیستم
• تعریف مرزهای و حدود سیستم
• فراهم كردن یك پایه برای طرح ریزی مفاهیم تكنیكی تكرارها
• فراهم كردن یك پایه برای تخمین مخارج و زمان تولید سیستم
• تعریف یك واسط كاربر برای سیستم با تمركز بر روی نیازها واهداف كاربران
برای دستیابی به این اهداف، ابتدا فهم تعریف و محدوده‌ی مسأله‌ای كه سعی داریم با این سیستم آن را حل كنیم، حائز اهمیت می‌باشد. قوانین كسب و كارف مدل Use-Case كسب و كار و مدل شیء كسب و كار كه در طول مدل‌سازی كسب و كار تولید شده به عنوان ورودی با ارزشی برای این تلاش خواهند بود. در این راستا ذینفعان تشخیص داده میشوند و درخواستهای ذینفعان استخراج، جمع‌آوری و تجزیه و تحلیل میشوند.
یك مستند تصویر كلی، یك مدل Use-Case ، Use-Case ها و مشخصه‌های تكمیلی برای توضیح كامل سیستم تولید می‌شود. این توضیح درواقع كاری را كه سیستم انجام خواهد داد بیان می‌كند. این مستندات بعنوان منابع مهم اطلاعات تولید می‌شود. در تولید این مستندات باید خواسته‌های همه ذینفعان را در نظر گرفت.
-
Analysis & Design (تحلیل و طراحی)
اهداف تحلیل و طراحی عبارتند از:
• تبدیل نیازمندی‌ها به طراحی سیستم كه قرار است بوجود آید.
• پیدایش یك معماری مستحكم برای سیستم
• سازگار ساختن طراحی برای هماهنگ شدن با محیط پیاده‌سازی و طراحی آن برای كارایی بهتر
در اوایل فاز Elaboration ، بر ایجاد یك معماری ابتدایی برای سیستم تمركز می‌شود، كه یك معماری كاندیدا برای فراهم كردن یك نقطه‌ی شروع برای تحلیل اصلی ارائه شود. اگر معماری قبلا وجود دارد (یا بدلیل اینكه در تكرارهای قبلی، در پروژه‌های قبلی تولید شده یا از یك چارچوب كاربردی بدست آمده)، تمركز كار برای اصلاح معماری، تحلیل رفتار و ایجاد یك مجموعه‌ی اولیه از عناصر است كه رفتار مناسب را فراهم می‌آورند
-
Implementation (پیاده‌سازی)
اهداف پیاده‌سازی عبارتند از:
• تعریف سازمان كد، برحسب زیر مجموعه‌ای از مجموعه‌های پیاده‌سازی سازمان یافته در لایه‌ها
• پیاده‌سازی كلاسها و اشیاء بوسیله مؤلفه‌ها (فایل‌های منبع، باینری‌ها، فایل‌های اجرایی و...)
• تست اجزاء تولید شده به عنوان واحد‌ها
• مجتمع‌سازی نتایج تولید شده توسط پیاده سازان فردی (یا تیم‌ها) به صورت یك سیستم قابل اجرا
دیسیپلین پیاده‌سازی مرز خود با تست را به اینكه تك تك كلاسها چگونه تست واحد میشوند، محدود می‌كند.
تست سیستم و تست مجتمع سازی در دیسیپلین تست انجام می‌گیرد.
-
Test (آزمون)
دیسیپلین تست از بسیاری جهات مانند یك ارائه دهنده خدمات برای سایر دیسیپلین‌ها عمل می‌كند. تمركز اولیه تست كردن بر بررسی و ارزیابی كیفیت‌های محقق شده از طریق كارهای زیر است:
• یافتن و مستند كردن نقایص در كیفیت نرم‌افزار
• آگاهی دادن در مورد كیفیت نرم‌افزار بررسی شده
• اثبات اعتبار فرضیاتی كه در طراحی و مشخصات نیازمندی‌ها ساخته شدند، از طریق نمایش‌های واقعی
• تصدیق عملكردهای محصول نرم‌افزار همانطور كه طراحی شده است.
• تصدیق اینكه نیازمندی‌ها بدرستی پیاده‌سازی شده‌اند
یك تفاوت جالب ولی تاحدی ظریف میان دیسیپلین تست و سایر دیسیپلین‌ها در RUP این است كه تست گرفتن، اساسا وظیفه‌ی یافتن و ارائه ضعف‌ها در محصول نرم‌افزار را داراست. برای اینكه این تلاش موفقیت‌آمیز باشد، لازم است از یك روش نسبتا منفی و مخرب استفاده شود تا روشی سازنده.
مسأله‌ای كه بسیار حائز اهمیت می‌باشد این است كه از دو روش اجتناب كنیم :
یكی روشی كه بطور مناسب و موثر نرم‌افزار را بكار نگیرد و مشكلات و ضعف‌های آن را نشان ندهد
و دیگری روشی كه آنقدر مخرب است كه احتمالا هیچگاه كیفیت محصول نرم‌افزاری را قابل قبول درنظر نمی‌گیرد.
-
Deployment (استقرار)
دیسیپلین استقرار فعالیت‌هایی را توضیح می‌دهد كه تضمین می‌كنند محصول نرم‌افزاری برای كاربران نهایی‌اش در دسترس می‌باشد.
دیسیپلین استقرار سه حالت استقار محصول را توضیح می‌دهد.
• نصب اختصاصی
• آماده فروش كردن محصول نهایی
• دستیابی به نرم‌افزار از طریق اینترنت
در هر نمونه، تأكید روی تست محصول در سایت تولید است و سپس انجام تست بتا، پیش از اینكه محصول نهایتا به مشتری تحویل داده شود. گرچه فعالیت‌های استقرار در فاز Transition به منتها درجه‌ی خود می‌رسند، اما برخی از فعالیت‌ها در فازهای قبلی برای طرح‌ریزی و آمادگی جهت استقرار انجام میشوند.
-
Environment (محیط)
دیسیپلین محیط بر فعالیت‌هایی كه برای پیكربندی فرآیند برای یك پروژه لازم و ضروری‌اند، متمركز می‌شود. این دیسیپلین فعالیت‌های مورد نیاز برای تولید رهنمودهایی كه در جهت پشتیبانی از یك پروژه لازم می‌باشند را توضیح می‌دهد. هدف فعالیت‌هایی محیطی فراهم آوردن محیط تولید (هم فرآیندها و هم ابزاری كه تیم تولید را پشتیبانی می‌كنند) برای سازمان تولید كننده نرم‌افزار می‌باشد.
جعبه ابزار مهندس فرآیند پشتیبانی ابزاری را برای پیكربندی یك فرآیند فراهم می‌كند.
این مورد شامل ابزارها و نمونه‌هایی برای ایجاد سایتهای وب پروژه و سازمان بر اساس RUP می‌شود.
-
Project Management (مدیریت پروژه)
مدیریت پروژه نرم‌افزاری، هنر متوازن ساختن اهداف متقابل، مدیریت ریسك و غلبه بر محدودیت‌ها برای تحویل موفقیت آمیز محصولی است كه هم نیازهای مشتریان ( كسانی كه برای سیستم پول می‌پردازند) و هم نیازهای كاربران را برآورده كند. این حقیقت كه پروژه‌های بسیار كمی هستند كه واقعا موفقیت‌آمیزند برای توضیح سخت بودن این كار، كافی می‌باشد
اهداف این دیسیپلین عبارتند از:
• فراهم كردن یك چارچوب برای مدیریت پروژه‌های صرفاً نرم‌افزاری
• فراهم كردن رهنمودهای عملی برای طرح‌ریزی، تعیین نیروی انسانی، اجرا و نظارت بر پروژه‌ها
• فراهم كردن یك چارچوب برای مدیریت ریسك
• با این وجود، این دیسیپلین از RUP برای پوشش دادن همه‌ی جنبه‌های مدیریت پروژه نیست.
برای مثال این دیسیپلین موارد زیر را پوشش نمی‌دهد :
* مدیریت افراد : استخدام، آموزش، رهبری
* مدیریت بودجه : تعیین، تخصیص و غیره
* مدیریت قراردادها : با پشتیبانی كنندگان و مشتریان
این دیسیپلین بطور عمده روی جنبه‌های مهم یك فرآیند تكراری تمركز می‌كند كه عبارتند از :
* مدیریت ریسك
* طرح ریزی برای یك پروژه‌ی تكراری، از طریق چرخه‌ی حیات و برای یك تكرار بخصوص
* نظارت بر پیشرفت یك پروژه‌ی تكراری و متریك‌ها
-
Configuration & Change Management (مدیریت پیكربندی و تغییرات)
برای تأویل و تفسیر ”مدل بلوغ قابلیت“ انستیتو مهندسی نرم‌افزار( SEI CMM )، مدیریت پیكربندی و درخواست تغییر، تغییرات را به سمت خروجی‌های یك پروژه كنترل می‌كند و همچنین صحت و تمامیت خروجی‌های پروژه را حفظ می‌كند.
مدیریت پیكربندی و درخواست تغییر ( CRM, CM ) شامل موارد زیر می‌باشند:
• تشخیص موارد پیكربندی
• محدود كردن تغییرات آن موارد
• رسیدگی به تغییراتی كه برای آن موارد ساخته شده
• تعریف و مدیریت پیكربندی آن موارد
متدها، فرآیندها و ابزاری كه برای ایجاد تغییر و مدیریت پیكربندی برای یك سازمان استفاده میشوند، می‌توانند بعنوان سیستم CM سازمان مورد توجه قرار گیرند.
برچسب برای این موضوع
مجوز های ارسال و ویرایش
- شما نمی توانید موضوع جدید ارسال کنید
- شما نمی توانید به پست ها پاسخ دهید
- شما نمی توانید فایل پیوست ضمیمه کنید
- شما نمی توانید پست های خود را ویرایش کنید
-
قوانین انجمن
پاسخ با نقل قول