معماری و ساختار کلی RUP

فرایند انجام یک پروژه تعریف می‌کند که چه کسی، چه کاری را در چه هنگام و چگونه برای رسیدن به هدف (انجام پروژه) انجام می‌دهد. در مهندسی نرم‌افزار، هدف ساختن یک محصول نرم‌افزاری و یا بهبود یک نمونه‌ی موجود است. هدف از تعیین فرایند، تضمین کیفیت

azsoftir.com
09367292276
[e-mail]
azsoftir.com
[e-mail]
azsoftir.com
09367292276

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

RUP، متدولوژی ارائه شده توسط شرکت Rational، پرکاربردترین فرآیند تولید و توسعه نرم افزاری در دنیای کنونی است و به عنوان یک استاندارد صنعتی بالفعل در دنیای IT پذیرفته شده است. به گزارش رویتر در سال 2001 میلادی بیش از ششصد هزار شرکت تولید کننده نرم افزار، از ابزارهای شرکت Rational استفاده می کرده‌اند که این تعداد کماکان هم در حال افزایش است. این متدولوژی، برای انواع پروژه‌های نرم‌افزاری در دامنه‌های مختلف ( مانند سیستم‌های اطلاعاتی، سیستم‌های صنعتی، سیستم‌های بلادرنگ، سیستم‌های تعبیه شده، ارتباطات راه دور، سیستم‌های نظامی و ...) و در اندازه‌های متفاوت، از پروژه‌های بسیار کوچک (یک نفر در یک هفته) تا پروژه‌های بسیار بزرگ (چند صد نفر تولید کننده با پراکندگی جغرافیایی)، کاربرد دارد.
مزیت بزرگ این متدولوژی، استفاده از روش تکرار در تولید و مدیریت تولید نرم‌افزار است که این امر، امکان تولید مبتنی بر کاهش ریسک و مواجه با مشکلات اصلی در ابتدای کار و در نتیجه احتمال موفقیت بیشتر را فراهم می‌کند. از محاسن دیگر این متدولوژی مبنا قرار دادن نرم‌افزار و تولید یک معماری پایدار در ابتدای کار است، که در نتیجه امکان کشف مشکلات عمده ساختاری، تست و مجتمع سازی ممتد را از ابتدای کار فراهم می‌کند. از دیگر مزایای این روش این است که افراد تیم همزمان با پیشرفت پروژه، مطالب جدیدی فرا می‌گیرند و کیفیت فرآیند تولید نیز به طور مرتب افزایش می‌یابد.
همانطور که در شکل بالا مشاهده می‌شود، RUP دارای دو بعد است :
azsoftir.com
09367292276
[e-mail]
azsoftir.com
[e-mail]
azsoftir.com
09367292276
    محور افقی نشان دهنده‌ی زمان است و با پیشرفت خود جنبه‌های چرخه‌ی حیات فرآیند و فازهای RUP را نشان می‌دهد.
    محور عمودی نمایانگر دیسیپلین‌های RUP است که فعالیت‌ها را با استفاده از ماهیتشان به صورت منطقی دسته‌بندی می‌کند.

    در هر فاز ممکن است یک یا چند تکرار وجود داشته باشد و در هر تکرار عملیات دیسپیلین‌های مختلف انجام می‌گیرند.

فازهای RUP

فازهای RUP
RUP Phases
فازها و milestone های یک پروژه در RUP
  Inception (آغازین)
هدف اصلی این فاز دستیابی به توافق میان کلیه‌ی ذینفعان بر روی اهداف چرخه‌ی حیات پروژه است. فاز Inception به دلیل تلاشهای تولید و توسعه جدید به صورت پایه‌ای اهمیت فراوانی دارد که در آن ریسک‌های نیازسنجی و تجاری مهمی وجود دارد که باید پیش از اینکه اجرای پروژه مورد توجه قرار گیرد، بررسی شوند. برای پروژه‌هایی که بر توسعه سیستم موجود متمرکزند، فاز Inception کوتاهتر است، با اینحال این فاز برای حصول اطمینان از اینکه پروژه ارزش انجام دادن دارد و امکان‌پذیر نیز هست، انجام می‌شود. اهداف اصلی فاز آغازین شامل موارد زیر است :‌
azsoftir.com
09367292276
[e-mail]
azsoftir.com
[e-mail]
azsoftir.com
09367292276
    بدست‌ آوردن محدوده نرم‌افزاری پروژه و محدودیت‌های آن که شامل یک دید عملیاتی، معیار پذیرش و اینکه چه چیز باید در محصول باشد و چه چیز نباید باشد، می‌شود
    مشخص کردن Use-Case های اساسی سیستم، سناریوهای اصلی عملیات که مسائل مربوط به طراحی اصلی را ایجاد می‌کند.
    نمایش و شاید توضیح حداقل یک معماری کاندیدا برای بعضی سناریوهای اصلی
    برآورد هزینه و زمان کلی برای کل پروژه

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

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

azsoftir.com
09367292276
[e-mail]
azsoftir.com
[e-mail]
azsoftir.com
09367292276

        عملی بودن محصول یا توضیحات برای سرمایه گذاران، مشتریان و کاربران نهایی

    توضیح اینکه معماری پایه از نیازمندی‌های سیستم با هزینه‌ی منطقی و در زمان منطقی پشتیبانی می‌کند
    ایجاد یک محیط پشتیبانی کننده

  Construction (ساخت)
هدف این فاز واضح سازی نیازمندی‌های باقیمانده و تکمیل تولید سیستم بر اساس معماری مبنا می‌باشد. فاز ساخت به نوعی یک فرآیند ساخت است که در آن تأکید بر مدیریت منابع و کنترل عملیات به منظور بهینه‌سازی هزینه‌ها، زمان‌بندی‌ها و کیفیت است. در این حالت یک انتقال از تولید یک نمونه‌ی ذهنی در طی فازهای Inception و Elaboration به تولید محصولات قابل استقرار در طی Construction وTransition می‌شود. اهداف اصلی فاز Construction شامل موارد زیر می‌باشد :

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

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

azsoftir.com
09367292276
[e-mail]
azsoftir.com
[e-mail]
azsoftir.com
09367292276

دهده شده می‌باشند، همزمان شود. این فاز بر اساس نوع محصول در فاصله‌ی بسیار ساده تا بی‌نهایت پیچیده قرار دارد. نصب یک نسخه‌ی جدید از یک بسته نرم‌افزاری موجود ممکن است بسیار ساده باشد، در حالیکه جایگزینی سیستم کنترل ترافیک هوایی یک کشور ممکن است بسیار پیچیده باشد. فعالیت‌هایی که در طول یک تکرار در فاز Transition انجام می‌گیرد به هدف بستگی دارند. برای مثال معمولاً در هنگام رفع اشکالات، پیاده‌سازی و تست کافی هستند. با این وجود اگر ویژگیهای جدیدی باید اضافه شوند، این تکرار شبیه به تکراری در فاز Construction می‌شود که نیازمند تحلیل و طراحی و غیره است. فاز Transition زمانی وارد عمل می‌شود که یک خط مبنا آنقدر بالغ شده که بتواند در دامنه‌ی کاربر نهایی استقرار یابد. این امر بطور نمونه نیازمند این است که تعدادی زیر مجموعه‌ی قابل استفاده از سیستم با کیفیت قابل قبول و مستندات کاربر، کامل شده باشند، تا انتقال به کاربر نتایج مثبتی را برای همه‌ی گروه‌ها در بر داشته باشد. اهداف مهم فاز Transition عبارتند از :

    تست بتا برای تشخیص اعتبار سیستم جدید با توجه به انتظارات کاربر
    تست بتا و عملیات موازی همراه با یک سیستم قدیمی که در حال جایگزینی می‌باشد.
    تبدیل پایگاه‌های داده‌ی عملیاتی
    آموزش کاربران و نگهداری کنندگان
    بازاریابی، توزیع و فروش برای نخستین انتشار محصول
    تنظیم فعالیت‌ها از قبیل رفع اشکال، افزایش کارایی و قابلیت استفاده
    ارزیابی خط مبناهای استقرار در مقایسه با تصویر کلی و معیار قابلیت قابل قبول برای محصول
    دستیابی به موافقت ذینفع در مورد اینکه خط مبناهای استقرار کامل می‌باشند
    دستیابی به موافقع ذینفع در مور اینکه خط مبناهای استقرار با معیار ارزیابی تصویر کلی سازگارند.
azsoftir.com
09367292276
[e-mail]
azsoftir.com
[e-mail]
azsoftir.com
09367292276

انجام پروژه های rup - مهندسی نرم افزار - خدمات آموزشی

انجام پروژه های rup - پروژه مهندسی نرم افزار این یک سایت آزمون می باشد که در این سایت به صورت آن لاین امتحانی برگزار می شود و همچنین در سایت اعلام نتایخ خواهد شد. این برنامه یک سایت آزمون می باشد. که دارای امکانات ثبت کاربر ، اساتید ، آزمون ، ارتباط ، پیشنهادات ، صندوق پیام و ... می باشد. با قابلت مدیریت بر کلیه صفحات توسط مدیر می باشد همچنین افزودن دوره ، امتحانات ، سئوالات و ... می باشد. این برنامه برای پروژه فارغ التحصیلی یا درس پایگاه داده یا مهندسی نرم افزارمناسب می باشد . این پروژه برای شما قابل سفارشی سازی و تبدیل به زبان های دیگر می باشد . (در صورت نیاز تهیه می شود)مستندات کامل شامل use case diagram , activity diagram , dfd ,sequence diagram , ERD ,... به همراه مستندات اینترفیس برنامه و توضیحات زبان برنامه نویسی و پایگاه داده. ============================================== azsoft.ir [e-mail] ( ساعات تماس : 8 الی 13 ---- 16 الی 21

مروری کلی بر متدولوژی RUP

یک متدولوژی تکرارشونده (iterative) برای انجام فرایند مهندسی نرم افزار و تولید نرم افزار می باشد. در این روش کاربر سیستم همواره درگیر در آماده‌سازی سیستم می‌باشد و در تمام مراحل بر تولید سیستم نظارت دارد. در این روش سیستم نرم‌افزاری بصورت یکجا تحویل نمی‌گردد.

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

در انتهای هر یک از فازهای RUPنقاط کنترلی (Milestone) برای ارزیابی وضعیت پروژه وجود دارند. در این نقاط است که وضعیت پیشرفت پروژه و موفقیت تیم پروژه سنجیده می شود و تصمیم‌گیری‌های مهم جهت بهبود روند انجام پروژه اتخاذ می‌گردد.

در طول هر یک از فازها ممکن است یک یا چند تکرار صورت گیرد. همانطور که در نمودار معروف RUP نیز مشخص است تکرارهایی که در آغاز پروژه صورت می‌گیرد بیشتر بر روی نیازمندی‌ها و سرویس‌‌های مورد نیاز سیستم تأکید دارند و تکرارهایی که در انتهای پروژه صورت می‌گیرند بیشتر بر پیاده ‌سازی سیستم تمرکز می‌کنند.

azsoftir.com
09367292276
[e-mail]
azsoftir.com
[e-mail]
azsoftir.com
09367292276

در ابتدای پروژه  زمان های شروع و پایان و تعداد تکرارهای هر فاز را پیش بینی و تعیین نمایید و در کل پروژه آن را در نظر داشته باشید. در پایان هر تکرار نیز برای تکرار بعدی برنامه ریزی کنید. اگر نتوانستید طبق زمانبندی تمامی کارها را انجام دهید هیچ گاه زمان فاز (یا تکرار) را اضافه نکنید بلکه در فاز (یا تکرار)  بعد ابتدا برای انجام کم کاری ها برنامه ریزی کنید و با از بین بردن علل به تعویق افتادن کارها در تکرار قبل و با زمانبندی واقع بینانه سعی کنید که دقیقا طبق برنامه پیش بروید.

متدولوژی 9 روند یا نظام (حرکت افقی در نمودار) را نیز پیشنهاد می دهد. که در هر فاز موجب تولید فراورده هایی می گردند. فراورده هایی که تولید می شوند در هر فازی که ایجاد شوند امکان به روز آوری آنها در فازهای دیگر وجود دارد. در هر پروژه با توجه به بزرگی سیستم ممکن است تعدادی از این فراورده ها تولید گردند. در تمامی فازها، به مدیریت پروژه و محیط پرداخته می شود و فرآورده های آن تولید یا به روز می شوند.

حال به شرح مختصری در مورد کارهایی که در هر فاز انجام می گردد و مهم ترین فراورده هایی که بر اساس هر نظام در هر فاز تولید می گردد می پردازیم.

1.      فاز آغازین (Inception phase)

در این فاز تمرکز بر روی تعیین اهداف و محدوده پروژه، هماهنگی افراد پروژه (کارفرما- پیمانکار و ....)، برآورد منابع مورد نیاز پروژه، شناسایی ریسک های پروژه، مدل کردن کسب و کار و شناخت نیازمندی های سازمان می باشد. در پایان  این فاز حداقل باید 85 – 90% نیازمندی های سازمان شناخته شده باشد.

فراورده های این فاز می تواند موارد زیر باشد:

azsoftir.com
09367292276
[e-mail]
azsoftir.com
[e-mail]
azsoftir.com
09367292276

-    Software Development Plan و Phase Plan

-  طرح مدیریت پیکربندیSystem Configuration Management Plan

-    قالب کاری Business Case

-    سند چشم انداز Vision Document

-    سند واژه نامه Glossary Document

-    قالب تولید Development Case

-    فهرست مخاطرات  Risk List

-    مدل موارد کاربرد  Use case model (( Use  cases  and Actors

-    طرح تکرار Iteration Plan

-    گزارش ارزیابی وضعیت  Status Assessment Report

-    گزارش ارزیابی تکرار Iteration Assessment Report

2.      فاز تفصیل (Elaboration phase)

در این فاز طراحی منطقی سیستم با توجه به قواعد و ساختار سازمان متولی پروژه انجام می‌پذیرد و در انتهای فاز با تکنولوژی در نظر گرفته شده برای سیستم, ترکیب ‌می‌شود.

هدف از این فاز تحلیل همه‌جانبه مسایل مطرح در سیستم  است. عواملی که بیشترین درصد ریسک پروژه را به خود اختصاص می‌دهند, بر طرف می‌گردند.در این فاز یک معماری مناسب و پایدار برای سیستم پایه‌ریزی می شود. شناخت نیازمندی ها کامل می گردد و تحلیل و طراحی شروع می شود.

فراورده های این فاز می تواند موارد زیر باشد:

-    UI Proto type  

-    مشخصات موارد کاربرد Use Case Specification

-    Proof of concept  

-    Domain Model

-     Design mode

-    Data  model

-    Implementation model

-    نمونه اولیه معماری Architectural Prototype

-    طرح آزمون Test Plan

-    طرح تکرار Iteration Plan

-    گزارش ارزیابی وضعیت  Status Assessment Report

-    گزارش ارزیابی تکرار Iteration Assessment Report

3.      فاز ساخت (Construction phase

azsoftir.com
09367292276
[e-mail]
azsoftir.com
[e-mail]
azsoftir.com
09367292276

)

هدف اصلی این فاز ساخت و پیاده‌سازی بخش طراحی شده در فاز قبل می‌باشد. در این فاز نسخه a نرم‌افزار ارایه می‌شود. نسخه a, نسخه‌ای از محصول است که نشان‌دهنده انجام 60% از کار ‌بوده و شامل قسمتهای مختلف سیستم است که پس از پیاده‌سازی توسط تیم تست, مورد بانگری و ارزیابی قرار می‌گیرد.

در انتهای این فاز و معمولاً فاز بعد, نسخه b ارایه می‌شود که 90% از کار انجام شده را در برمی‌گیرد. بعبارت دیگر 90% از ویژگی‌ها و نیازهای نرم‌افزاری دیده و پیاده‌سازی شده است.

فراورده های این فاز می تواند موارد زیر باشد:

-    Build

-    Product

-    سند معماری نرم افزار Software Architecture Plan

-      Implementation  model

-    Data model

-    ‏Test Suite

-    Test Evaluation Report

-    طرح تکرار Iteration Plan

-    گزارش ارزیابی وضعیت  Status Assessment Report

-    گزارش ارزیابی تکرار Iteration Assessment Report

-    طرح تکرار Iteration Plan

-    گزارش ارزیابی وضعیت  Status Assessment Report

-    گزارش ارزیابی تکرار Iteration Assessment Report

4.      فاز انتقال (Transition phase)

هدف این فاز انتقال و تحویل محصول نرم‌افزاری به سازمان مشتری می‌باشد. زمانی‌ که محصول در اختیار کاربران نهایی قرار گیرد, نظرات و بازخوردهایی از سوی ‎آنها مطرح می‌شود که منجر به پیاده‌سازی اجزای جدیدی در سیستم شده و یا موجب تصحیح قسمت‌هایی از برنامه می‌شود. در این فاز درخواستهای تغییر که توسط کاربران سیستم اعلام شده مدیریت و در سیستم اعمال می گردند. در این فاز نحوه و نیازهای جهت استقرار سیستم اعلام می گردد و اسناد آن تحویل داده می شود.

در این فاز ممکن است چندین تکرار لازم باشد و تست‌های مختلفی جهت ارایه نسخه نهایی صورت ‌گیرد. در انتهای این فاز پروژه آماده تحویل می‌باشد, ولی گاهاً نیز بر حسب نیاز یک چرخه دیگر که شامل همین چهار فاز می‌باشد جهت تولید ویرایش جدید یا اعمال درخواست‌های جدید کاربر صورت می‌گیرد.

 azsoftir.com
09367292276
[e-mail]
azsoftir.com
[e-mail]
azsoftir.com
09367292276

فراورده های این فاز می تواند موارد زیر باشد:

-    Release Note

-    Deployment Plan

-    Installation  Artifacts

-     Training  material

-     End user Support material

-     Product  Builder

-    Configuration Data

-    Software Installation Media

-    طرح تکرار Iteration Plan

-    گزارش ارزیابی وضعیت  Status Assessment Report

-    گزارش ارزیابی تکرار

azsoftir.com
09367292276
[e-mail]
azsoftir.com
[e-mail]
azsoftir.com
09367292276

Iteration Assessment Report

متدولوژی RUP و آزمون پذیرش سیستم

گسترش دانش و اعتلای زبان با ارائه مطالب علمی به زبان فارسی روان در محیط اینترنت
متدولوژی RUP و آزمون پذیرش سیستم
azsoftir.com
09367292276
[e-mail]
azsoftir.com
[e-mail]
azsoftir.com
09367292276
عنوان مقاله: متدولوژی RUP و آزمون پذیرش سیستم

RUP Methodology and System Acceptance Test

نویسنده/ مترجم: اکبر قراخانی بهار

Akbar Gharakhani Bahar







آدرس­ پست الکترونیکی ارسال کننده:

موضوع اصلی: تولید نرم­افزار - موضوع فرعی: متدولوژی­های نرم­افزار

سه کلیدواژه اصلی به ترتیب اهمیت: unit test، integration test، system test

سه کلیدواژه فرعی به ترتیب اهمیت: acceptance test،alpha test ، beta test

 
azsoftir.com
09367292276
[e-mail]
azsoftir.com
[e-mail]
azsoftir.com
09367292276
چکیده مقاله

در RUP، کار انتقال سیستم از محیط ایجاد کننده به محیط استفاده کننده آن، در طی«فاز انتقال» که آخرین فاز از فازهای چهارگانه RUP است، صورت می­گیرد. با توجه به وجود «تکرار» در فازهای RUP، سیستم نهایی غالبا در طی تکرارهای مختلف و در هر تکرار نسخه کامل­تری از سیستم به محیط استفاده کننده منتقل می­گردد. قبل از اجرای فاز انتقال در RUP، لازم است که مراحل آزمون اولیه نرم­افزار توسط ایجاد کننده آن انجام شده و «معیار» مربوط به پایان «فاز ساخت» به عنوان فاز سوم پیش از فاز انتقال نیز محقق شده باشد. مفهوم معیار مربوط به پایان فاز ساخت این است که نرم­افزار به مرحله عملیاتی شدن رسیده و می­تواند به صورت آزمایشی توسط استفاده کنندگان مورد استفاده قرار گیرد. مفهوم تکرار در RUP متضمن شکستن پروژه اصلی به چند پروژه فرعی است. انجام پروژه­های فرعی با شروع از پروژه فرعی اول در قالب یک تکرار و ادامه کار با پروژه­های فرعی در قالب تکرارهای بعدی، به صورتی پیش­رونده ما را در نهایت با محصول کل پروژه و نرم­افزار نهایی همراه می­کند. در این نگرش، «پیش­رونده» به این مفهوم است که با هر تکرار در واقع نسخه جدیدی از نرم­افزار که نسبت به نسخه قبلی «کامل­تر» و نیز «بی­­عیب­تر» است، به استفاده کنندگان ارائه می­شود. به بیان دیگر در پایان پروژه فرعی n، نسخه­های جدید محصولات پروژه­های فرعی 1 تا 1- n (ضمن رفع مشکلات نسخ پیشین آن­ها) به علاوه محصول پروژه فرعی n ارائه می­شود. به همین خاطر گفته می­شود که در RUP آزمون­های پذیرش در طول فرایند ایجاد نرم­افزار در قالب تکرارهای RUP از طرف استفاده کنندگان نهایی همواره می­توانند انجام ­شوند. بدین ترتیب در RUP به جای یک آزمون پذیرش در روش سنتی، می­توان n آزمون پذیرش ترتیب داد که به صورتی پیش­رونده از بخش اول سیستم شروع و با انباشت بخش­های بعدی سیستم بر روی هم، در نهایت به آزمون پذیرش کل سیستم ختم ­شود.

دریافت فایل PDF مقاله

متدولوژی RUP و آزمون پذیرش سیستم

مقدمه

هر سیستم نرم­افزاری بعد از آماده شدن برای اجرا، در محیط استفاده کنندگان نهایی آن نصب و آماده اجراهای آزمایشی توسط استفاده کنندگان می­گردد. در RUP، کار انتقال سیستم از محیط ایجاد کننده به محیط استفاده کننده آن، در طی« فاز انتقال» (Transition Phase) که آخرین فاز از فازهای چهارگانه RUP است، صورت می­گیرد. البته با توجه به وجود «تکرار» (iteration) در فازهای RUP، سیستم نهایی غالبا در طی تکرارهای مختلف و در هر تکرار نسخه کامل­تری از سیستم به محیط استفاده کننده منتقل می­گردد. بدین خاطر در عمل ممکن است فاز انتقال چندین تکرار یا مرحله را شامل شود.
azsoftir.com
09367292276
[e-mail]
azsoftir.com
[e-mail]
azsoftir.com
09367292276
 

بدیهی است که قبل از اجرای فاز انتقال در RUP، لازم است که مراحل آزمون اولیه نرم­افزار توسط ایجاد کننده آن انجام شده و «معیار» (milestone) مربوط به پایان «فاز ساخت» (Construction Phase) به عنوان فاز سوم پیش از فاز انتقال نیز محقق شده باشد. لازم به یادآوری است که معیار مربوط به پایان فاز ساخت Initial Operative Capability (IOC) است و مفهوم آن این است که نرم­افزار به مرحله عملیاتی شدن رسیده و می­تواند به صورت آزمایشی توسط استفاده کنندگان مورد استفاده قرار گیرد.

 

باید اضافه شود که RUP دارای ابزارهای متعددی برای انجام آزمون یا مدیریت آن است. در این زمینه ClearQuest، ClearCase، RequisitePro، Purify، PureCoverage،   Robotو غیره می­توانند به کار گرفته شوند. در این مطلب به ابعاد مختلف آزمون پذیرش یک سیستم نرم­افزاری اشاره خواهد شد.

 

انواع آزمون سیستم

آزمون یک سیستم نرم­افزاری از نظر انجام دهنده یا محل انجام آزمون، در دو وجه مختلف زیر قابل طرح است:

    آزمون­های ایجاد کننده / Developer's Tests
    آزمون­های استفاده کننده / User's Tests

آزمون­های ایجاد کننده که غالبا برای کشف و رفع «خطاها/ اشتباهات» (faults) و «قصور/ کمبودها» (failures) اجرایی در سیستم ایجادی انجام می­شوند، شامل انجام آزمون­های شناخته شده در صنعت نرم­افزار است. این آزمون­ها موارد زیر را شامل می­شوند:
azsoftir.com
09367292276
[e-mail]
azsoftir.com
[e-mail]
azsoftir.com
09367292276
    آزمون تک تک واحدها/ Unit Test شامل آزمون مربوط به تک تک واحدهای نرم­افزاری که مجموع آن­ها کل سیستم نرم­افزاری را به وجود می­آورند.
    آزمون واحدهای تجمیع شده به صورت سیستم/ Integration Test شامل آزمون مربوط به کل سیستم که از تجمیع یا یک پارچه کردن واحدهای نرم­افزاری قبلا آزموده شده به دست آمده است.
    آزمون سیستم/ System Test شامل آزمون مربوط به سیستم حاصل از تجمیع واحدها در تعامل با سایر سیستم­های مرتبط با این سیستم

 

آزمون سیستم غالبا طی دو مرحله جداگانه به شرح زیر صورت می­گیرد:

    آزمون آلفا/ Alpha Test شامل آزمون سیستم به صورت «درونی» (internal) و از طریق مجموعه­ای کوچک از «آزمون کنندگان» (testers) در محیط ایجاد کننده
    آزمون بتا/ Beta Test شامل آزمون سیستم به صورت «بیرونی» (external) و از طریق مجموعه نسبتا بزرگی از«استفاده کنندگان» (users) در خارج از محیط ایجاد کننده و حتی عموم. از نرم­افزار عرضه شده برای این منظور غالبا به عنوان «نسخه بتا» (Beta Version) نیز یاد می­شود. همان­طور که دیده می­شود، معیار پایان فاز ساخت در RUP نیز در واقع شامل تهیه نسخه بتا از نرم­افزار است.

 

آزمون­های مربوط به استفاده کننده، در عمل تحت عنوان «آزمون پذیرش» (Acceptance Test) یا «آزمون عملکرد» (Functional Test) انجام می­شود. همچنین بعد از انجام هر گونه تغییرات در سیستم، آزمونی تحت عنوان «آزمون برگشتی» (Regression Test) انجام می­شود تا اطمینان حاصل شود که تغییرات انجام شده باعث ایجاد خطا و قصور یا اثرات جانبی نامطلوب در سیستم نشده­است. این آزمون ممکن است توسط هر دو طرف ایجاد کننده و استفاده کننده از سیستم انجام شود. به عنوان سفارش دهنده یا تحویل گیرنده یک سیستم نرم­افزاری، ما در این مطلب به وجوه آزمون پذیرش یا عملکرد که متولی انجام آن استفاده کنندگان نهایی سیستم هستند، خواهیم پرداخت.

 
azsoftir.com
09367292276
[e-mail]
azsoftir.com
[e-mail]
azsoftir.com
09367292276
مفهوم آزمون پذیرش

آزمون پذیرش وسیله­ای است که استفاده کنندگان نهایی سیستم با انجام آن از کارکرد درست سیستم از نظر خود، اطمینان حاصل می­کنند. اگر آزمون­های قابل انجام توسط ایجاد کننده را وسیله­ای برای کسب اطمینان از «انجام درست کارها» (Doing Things Right) در مورد «آنچه که ایجاد شده­است» در نظر بگیریم، در این صورت آزمون پذیرش که از طرف استفاده کننده انجام می­شود، به عنوان وسیله­ای برای کسب اطمینان از «انجام کارهای درست» (Doing Right Things) در مورد «آنچه که خواسته شده­است»، خواهد بود.

 

ذی­نفع اصلی در آزمون پذیرش، استفاده کننده سیستم است. اهداف استفاده کننده از سیستم از انجام آزمون پذیرش کسب اطمینان از موارد زیر است:

    برآورده کردن نیازهای استفاده کننده/ Capturing User Requirements
    اجرای بری از خطا و قصور سیستمFault and Failure Free / Running

آزمون پذیرش به عنوان «قرارداد»ی بین ایجاد کننده و استفاده کننده از سیستم تلقی می­شود. با این تعبیر، وقتی یک آزمون پذیرش با موفقیت انجام شود، می­توان گفت که با این عمل در واقع پروژه مربوط به ایجاد سیستم پایان یافته است.

 

مفاد آزمون پذیرش باید بر اساس درخواست­های استفاده کنندگان تهیه شود. این گفته بدین معناست که مفاد باید مستقل از سیستم بوده و بدون توجه به سیستم ایجادی باشد و حتی­الامکان پیش از تحویل گرفتن و حتی پیش از ایجاد سیستم تهیه شود تا این که از آنچه که در سیستم تدارک دیده شده است، تاثیر نپذیرفته باشد. مفاد آزمون پذیرش همچنین باید حتی­الامکان توسط خود استفاده کنندگان (در صورت لزوم با کمک ایجاد کنندگان سیستم) و به زبان استفاده کنندگان که ممکن است از واژه­های فنی نیز بدور باشد، تهیه شود.

 azsoftir.com
09367292276
[e-mail]
azsoftir.com
[e-mail]
azsoftir.com
09367292276

چگونگی انجام آزمون پذیرش

آزمون پذیرش در بخش برآورده کردن نیازهای استفاده کننده، باید برآورده شدن یا نشدن نیازهای استفاده کننده را مشخص نماید. این کار می­تواند با اجرای آزمایشی سیستم و بررسی اجزاء و مؤلفه­های کل سیستم و تطابق آن با نیازمندی­های عنوان شده در مستندات پیشین، صورت گیرد. آزمون پذیرش در بخش اجرای بری از خطا و قصور سیستم نیز باید وجود یا عدم وجود خطا و قصور در اجزاء و مؤلفه­های سیستم  را مشخص کند. این کار نیز می­تواند با اجرای آزمایشی سیستم و ثبت موارد خطا و قصور و گزارش آن به ایجاد کننده سیستم صورت گیرد.

 

همان­طور که خود سیستم حول «موارد کاربرد» (Use Cases) قابل شکل­گیری است، آزمون پذیرش سیستم نیز در حول «موارد آزمون» (Test Cases) قابل انجام است. به تعبیر استاندارد IEEE 829-1998 ، یک «مورد آزمون» شامل «ورودی­های معین» و «خروجی­های مورد انتظار» است. همان­طور که یک سیستم می­تواند شامل چندین مورد کاربرد باشد، یک آزمون پذیرش سیستم نیز می­تواند شامل چندین مورد آزمون باشد. با این تعبیر، هر مورد کاربرد می­تواند شامل یک یا چند مورد آزمون پذیرش باشد.

 
azsoftir.com
09367292276
[e-mail]
azsoftir.com
[e-mail]
azsoftir.com
09367292276
مطالب قابل بیان در باره یک مورد آزمون پذیرش شامل اقلامی نظیر شماره شناسایی آزمون، شماره ترتیب انجام و سایر نیازمندی­های آن است. این نیازمندی­ها می­تواند شامل پیش­شرط/ پیش­نیازهای آزمون، ورودی، رویه عملیاتی مورد آزمون در سیستم و خروجی مورد انتظار باشد. کل یک آزمون پذیرش را می­توان به صورت یک جدول «صفحه گسترده» (Spread Sheet) و یک مورد آزمون را  نیز می­توان به صورت سطری از این جدول سازمان داد. در این صورت باید برای نتیجه واقعی که از طریق آزمون به دست آمده است، نام انجام دهنده آزمون، تاریخ و محل انجام آزمون و غیره نیز ستون­هایی در نظر گرفته شود.

 

آزمون­ پذیرش ممکن است به صورت دستی، نیمه دستی+نیمه اتوماتیک و یا اتوماتیک صورت گیرد. بسته به مورد، آزمون­های پذیرش ممکن است با عناوینی از قبیل Test Specification، Test Suite یا  Test Script نیز مورد خطاب قرار گیرند. در این صورت عنوان به کار رفته ممکن است به نوعی نشان دهنده نوع آزمون ازقبیل دستی، نیمه دستی+نیمه اتوماتیک و یا اتوماتیک نیز باشد.

 

توصیه­های RUP در انجام آزمون پذیرش

یکی از نقاط قوت RUP در ایجاد سیستم­های نرم­افزاری، ایجاد نرم­افزار در طی «تکرار» های مختلف است. همان­طور که می­دانیم مفهوم تکرار در RUP متضمن شکستن پروژه اصلی به چند پروژه فرعی است. انجام پروژه­های فرعی با شروع از پروژه فرعی اول در قالب یک تکرار و ادامه کار با پروژه­های فرعی در قالب تکرارهای بعدی، به صورتی پیش­رونده ما را در نهایت با محصول کل پروژه و نرم­افزار نهایی همراه می­کند. در این نگرش، «پیش­رونده» به این مفهوم است که با هر تکرار در واقع نسخه جدیدی از نرم­افزار که نسبت به نسخه قبلی «کامل­تر» و نیز «بی­­عیب­تر» است، به استفاده کنندگان ارائه می­شود.

 azsoftir.com
09367292276
[e-mail]
azsoftir.com
[e-mail]
azsoftir.com
09367292276

به بیان دیگر در پایان پروژه فرعی n، نسخه­های جدید محصولات پروژه­های فرعی 1 تا 1- n (ضمن رفع مشکلات نسخ پیشین آن­ها) به علاوه محصول پروژه فرعی n ارائه می­شود. به همین خاطر گفته می­شود که در RUP آزمون­های پذیرش در طول فرایند ایجاد نرم­افزار در قالب تکرارهای RUP از طرف استفاده کنندگان نهایی همواره می­توانند انجام ­شوند. بدین ترتیب در RUP به جای یک آزمون پذیرش در روش سنتی، می­توان n آزمون پذیرش ترتیب داد که به صورتی پیش­رونده از بخش اول سیستم شروع و با انباشت بخش­های بعدی سیستم بر روی هم، در نهایت به آزمون پذیرش کل سیستم ختم ­شود.