مهندسی نرم افزار 2

[Admin]

2. مدلسازی منابع کسب و کار ( Bussiness Resource Modeling )

منابع و ارتباط بین آنها شناخته می شود و لذا قابلیت کنترل به راحتی فراهم می گردد.

البته این تقسیم بندی کلان است و ممکن است در بعضی مکان ها چنین قسمت بندی را نداشته باشیم.

3. مدل سازی نقش های کسب و کار ( (Business Role Modeling

مکانیزه شدن سیستم بانکی را در نظر بگیرید ، در سیستم امنیتی نگهبان بانک حذف شده و به جایش Network Admin داریم.
همچنین نقش ها به راحتی عوض شده و تحولی دار بانک به دستگاه ATM عوض می شود.

گاهی نیز در وظایف و نقش ها با هم در تعارض هستند که در چیدمان سیستم باید سعی در رفع این تعارضات باشیم و در نتیجه باید تمامی نقش ها همگرا باشد.

در همین جهت ممکن است نقش هایی از بین برود و نقش هایی اضافه شوند و یا نقش هایی تغییر کنند.


4. مدل سازی قواعد کسب و کار ( Business Rule Modeling ):

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

به طور مثال:
دو تیم مسابقه ی روبوت ها را در نظر داشته باشید

ربات تیم اول از تکنولوژی کمتری نسبت به تیم دوم برخوردار است.

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

در نتیجه استفاده ی نادرست از قواعد بازی می تواند برای ما مشکل ساز باشد.

5. مدلسازی فرایند های کسب و کار ( Business Proccess Modeling ):

در این مدلسازی فرایند های یک سیستم به ترتیب مدلسازی شده و جزئیات سیستم کاملا مشخص می شود.
به عبارتی روش هایی که سازمان با آن کار انجام میدهد ( از قبیل خروجی ، محصول یا خدمت ) باید مشخص شود.

[samnet]

آقا مصطفی با تشکر از اطلاعات مفیدت.
ولی RUP یک متدلوژی نیست بلکه یک مدل فرآیند است. که بر مبنای متدلوژی شی گرایی است.

RUP=Rational Unified Process

[آبجی]

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

فرایند انجام یک پروژه تعریف می‌کند که چه کسی، چه کاری را در چه هنگام و چگونه برای رسیدن به هدف (انجام پروژه) انجام می‌دهد. در مهندسی نرم‌افزار، هدف ساختن یک محصول نرم‌افزاری و یا بهبود یک نمونه‌ی موجود است. هدف از تعیین فرایند، تضمین کیفیت نرم‌افزار، برآورده شدن نیاز‌های کاربر و قابل تخمین بودن زمان و هزینه‌ی تولید می‌باشد. علاوه بر این، تعیین فرایند، روندی جهت تحویل مصنوعات دوران تولید نرم‌افزار به کارفرما و ناظر پروژه ارائه می‌دهد تا از این طریق اطمینان حاصل کنند که پروژه روند منطقی خود را طی می‌کند و نظارت درست بر انجام پروژه ممکن است و از سوی دیگر، معیاری برای ارزیابی پروژه انجام شده می‌باشد. تا كنون متدولوژی‌های مختلفی برای فرآیند تولید نرم‌افزار ارائه شده‌اند كه یكی از مشهورترین آنها RUP است.
RUP ، متدولوژی ارائه شده توسط شرکت Rational ، پرکاربردترین فرآیند تولید و توسعه نرم افزاری در دنیای کنونی است و به عنوان یک استاندارد صنعتی بالفعل در دنیای IT پذیرفته شده است. به گزارش رویتر در سال 2001 میلادی بیش از ششصد هزار شرکت تولید کننده نرم افزار، از ابزارهای شرکت Rational استفاده می کرده‌اند که این تعداد کماکان هم در حال افزایش است. این متدولوژی، برای انواع پروژه‌های نرم‌افزاری در دامنه‌های مختلف ( مانند سیستم‌های اطلاعاتی، سیستم‌های صنعتی، سیستم‌های بلادرنگ، سیستم‌های تعبیه شده، ارتباطات راه دور، سیستم‌های نظامی و ...) و در اندازه‌های متفاوت، از پروژه‌های بسیار کوچک (یک نفر در یک هفته) تا پروژه‌های بسیار بزرگ (چند صد نفر تولید کننده با پراکندگی جغرافیایی)، کاربرد دارد.
مزیت بزرگ این متدولوژی، استفاده از روش تکرار در تولید و مدیریت تولید نرم‌افزار است که این امر، امکان تولید مبتنی بر کاهش ریسک و مواجه با مشکلات اصلی در ابتدای کار و در نتیجه احتمال موفقیت بیشتر را فراهم می‌کند. از محاسن دیگر این متدولوژی مبنا قرار دادن نرم‌افزار و تولید یک معماری پایدار در ابتدای کار است، که در نتیجه امکان کشف مشکلات عمده ساختاری، تست و مجتمع سازی ممتد را از ابتدای کار فراهم می‌کند. از دیگر مزایای این روش این است که افراد تیم همزمان با پیشرفت پروژه، مطالب جدیدی فرا می‌گیرند و کیفیت فرآیند تولید نیز به طور مرتب افزایش می‌یابد.
همانطور كه در شكل بالا مشاهده می‌شود، RUP دارای دو بعد است:
1. محور افقی نشان دهنده‌ی زمان است و با پیشرفت خود جنبه‌های چرخه‌ی حیات فرآیند و فازهای RUP را نشان می‌دهد.
2. محور عمودی نمایانگر دیسیپلین‌های RUP است كه فعالیت‌ها را با استفاده از ماهیتشان به صورت منطقی دسته‌بندی می‌كند.
در هر فاز ممكن است یك یا چند تكرار وجود داشته باشد و در هر تكرار عملیات دیسپیلین‌های مختلف انجام می‌گیرند
فازهای RUP

فازها و milestone های یك پروژه در RUP
Inception (آغازین)

هدف اصلی این فاز دستیابی به توافق میان كلیه‌ی ذینفعان بر روی اهداف چرخه‌ی حیات پروژه است. فاز Inception به دلیل تلاشهای تولید و توسعه جدید به صورت پایه‌ای اهمیت فراوانی دارد كه در آن ریسك‌های نیازسنجی و تجاری مهمی وجود دارد كه باید پیش از اینكه اجرای پروژه مورد توجه قرار گیرد، بررسی شوند. برای پروژه‌هایی كه بر توسعه سیستم موجود متمركزند، فاز Inception كوتاهتر است، با اینحال این فاز برای حصول اطمینان از اینكه پروژه ارزش انجام دادن دارد و امكان‌پذیر نیز هست، انجام می‌شود. اهداف اصلی فاز آغازین شامل موارد زیر است:
• بدست‌ آوردن محدوده نرم‌افزاری پروژه و محدودیت‌های آن كه شامل یك دید عملیاتی، معیار پذیرش و اینكه چه چیز باید در محصول باشد و چه چیز نباید باشد، می‌شود
• مشخص كردن Use-Case های اساسی سیستم، سناریوهای اصلی عملیات كه مسائل مربوط به طراحی اصلی را ایجاد می‌كند.
• نمایش و شاید توضیح حداقل یك معماری كاندیدا برای بعضی سناریوهای اصلی
• برآورد هزینه و زمان كلی برای كل پروژه
Elaboration (جزییات)

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

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

تمركز این فاز بر این است كه تضمین نماید نرم‌افزار برای كاربران نهایی آماده می‌باشد. فاز Transition می‌تواند به چندین تكرار تقسیم شود، و شامل تست كردن محصول برای آماده‌سازی جهت انتشار و ایجاد تنظیمات كوچك بر اساس بازخورد كاربر می‌باشد. در این نقطه از چرخه‌ی حیات، بازخورد كاربر باید بطور عمده بر تنظیم دقیق محصل، پیكربندی، نصب و نكات مربوط به قابلیت استفاده تمركز یابد، و همه‌ی نكات ساختاری اصلی باید هرچه زودتر در چرخه‌ی حیات پروژه طرح شوند. با به اتمام رسیدن فاز Transition اهداف چرخه‌ی حیات باید برآورده شده باشند و پروژه در موقعیتی باشد كه بتوان آنرا خاتمه داد. در برخی موارد، پایان چرخه‌ی حیات فعلی ممكن است با آغاز چرخه‌ی حیات بعدی در مورد همان محصول همزمان شود و ما را به سمت تولید یا ویرایش دیگری هدایت كند. برای پروژه‌های دیگر، پایان فاز Transition ممكن است با تحویل كامل خروجی‌ها به گروه سومی كه ممكن است مسؤول عملیات نگهداری و پیشرفت سیستم تحویل دهده شده می‌باشند، همزمان شود. این فاز بر اساس نوع محصول در فاصله‌ی بسیار ساده تا بی‌نهایت پیچیده قرار دارد. نصب یك نسخه‌ی جدید از یك بسته نرم‌افزاری موجود ممكن است بسیار ساده باشد، در حالیكه جایگزینی سیستم كنترل ترافیك هوایی یك كشور ممكن است بسیار پیچیده باشد. فعالیت‌هایی كه در طول یك تكرار در فاز Transition انجام می‌گیرد به هدف بستگی دارند. برای مثال معمولاً در هنگام رفع اشكالات، پیاده‌سازی و تست كافی هستند. با این وجود اگر ویژگیهای جدیدی باید اضافه شوند، این تكرار شبیه به تكراری در فاز Construction می‌شود كه نیازمند تحلیل و طراحی و غیره است. فاز Transition زمانی وارد عمل می‌شود كه یك خط مبنا آنقدر بالغ شده كه بتواند در دامنه‌ی كاربر نهایی استقرار یابد. این امر بطور نمونه نیازمند این است كه تعدادی زیر مجموعه‌ی قابل استفاده از سیستم با كیفیت قابل قبول و مستندات كاربر، كامل شده باشند، تا انتقال به كاربر نتایج مثبتی را برای همه‌ی گروه‌ها در بر داشته باشد. اهداف مهم فاز Transition عبارتند از:
• تست بتا برای تشخیص اعتبار سیستم جدید با توجه به انتظارات كاربر
• تست بتا و عملیات موازی همراه با یك سیستم قدیمی كه در حال جایگزینی می‌باشد.
• تبدیل پایگاه‌های داده‌ی عملیاتی
• آموزش كاربران و نگهداری كنندگان
• بازاریابی، توزیع و فروش برای نخستین انتشار محصول
• تنظیم فعالیت‌ها از قبیل رفع اشكال، افزایش كارایی و قابلیت استفاده
• ارزیابی خط مبناهای استقرار در مقایسه با تصویر كلی و معیار قابلیت قابل قبول برای محصول
• دستیابی به موافقت ذینفع در مورد اینكه خط مبناهای استقرار كامل می‌باشند
• دستیابی به موافقع ذینفع در مور اینكه خط مبناهای استقرار با معیار ارزیابی تصویر كلی سازگارند
دیسیپلین‌های 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 سازمان مورد توجه قرار گیرند.
سیستم مدیریت پیكربندی و درخواست تغییر (سیستم CM ) برای یك سازمان اطلاعات كلیدی در مورد تولید محصول را نگهداری می‌كند. این اطلاعات عبارتند از : ‌ترفیع، استقرار و فرآیندهای نگهداری. بعلاوه یك پایگاه داده محصولاتی را كه بصورت بالقوه قابل استفاده مجدد می‌باشند، نگهداری می‌كند.
یك سیستم CM برای كنترل خروجی‌های متعدد تولید شده توسط افراد زیادی كه روی یك پروژه كار می‌كنند، ضروری است. كنترل، به اجتناب از اغتشاشِ پرهزینه كمك می‌كند و تضمین می‌نماید كه خروجی‌های بدست آمده با توجه به برخی انواع مسائل و مشكلاتی كه در زیر آمده‌اند ناسازگار نیستند.
• به روز رسانی همزمان
• توجه دادن محدود شده
• نسخه‌های چندگانه

[آبجی]

مروری بر RUP و قابلیتهای آن در تولید نرمافزار

یك پروسه چابك، پروسهای است كه همیشه آماده در آغوش كشیدن درخواستهای جامعه بوده و این درجه از سازگاری را دارا باشد. بنابراین منظور از سرعت عمل، فقط كاستن از حجم پروسه تولید نرمافزار یا سرعت ارائه آن به بازار نیست؛ بلكه منظور، انعطافپذیری و حفظ کیفیت است.
شكل 1

یك پروسه چابك، پروسهای است كه همیشه آماده در آغوش كشیدن درخواستهای جامعه بوده و این درجه از سازگاری را دارا باشد. بنابراین منظور از سرعت عمل، فقط كاستن از حجم پروسه تولید نرمافزار یا سرعت ارائه آن به بازار نیست؛ بلكه منظور، انعطافپذیری و حفظ کیفیت است. مطلبی كه در این مقاله قصد توضیح آن را داریم این است كه
RUP1 ساختاری پروسهای(چیو ۲۰۰۰)است كه امكان انعطافپذیری را برای تولیدكنندگان نرمافزار فراهم میآورد.
منظور از RUP چیست؟ در این مقاله از چند منظر به RUP خواهیم پرداخت:
RUP یك پروسه تولید نرمافزار است.
RUP مجموعهای از تجربیات بسیار عالی تولید نرمافزار را كه در عمل با آنها برخورد شده است، در خود دارد.
RUP همانند یك محصول نرمافزاری به بازار ارائه شده و به فروش میرسد با این تفاوت كه RUP اولین ساختار تولید نرمافزار را ارائه داده و گام نخست را در این زمینه برداشته است.
۲ )RUPچیست؟
با پیشرفت تكنولوژیهای مرتبط با كامپیوتر، نیاز هر چه بیشتر به گسترش علم نرمافزاری نیز احساس میشد كه با پیدایش متدولوژیهای همانند SSADM ۲ و روش آبشاری۳ (چیو ۲۰۰۰)آغاز شد. در ابتدا، این روشها مناسب بود و جوابگوی نیازهای آن زمان بودند ولی با افزایش دادهها و پیدایش مفاهیمی همچون شبكه، وب و غیره دیگر كارآیی لازم را جهت پیادهسازی و هدایت پروژههای نرمافزاری نداشتند. پس مفاهیم برنامهنویسی شیءگرا پا به عرصه وجود گذاشتند و در سال ۱۹۹۱ بطور جدی مورد مطالعه و بحث قرار گرفتند. استفاده از این روشها و متدهای برنامهنویسی، قدرت و انعطاف بسیاری را به برنامهها داد و شركتهای نرمافزاری توانستند با كاهش هزینهها و بهینهسازی كدهای خود، نرمافزارهای قویتری را به بازار عرضه كنند ولی این روش جدید نیز نیاز به مدیریت و یكپارچگی داشت. پس روشها و متدولوژیهای جدیدی مطرح شد كه شامل Booch، OMT، OSE و ... میباشند. در سال ۲۰۰۰ شركت Rational روشی را تحت عنوان RUP مطرح ساخت (گروه كاسمیك ۲۰۰۳ب) كه بعد از روش MSF شركت مایكروسافت به دنیای نرمافزار عرضه شد و امروزه از طرفداران بسیاری برخوردار است. فرایند یكپارچه Rational در اصل یك متدولوژی است كه در جهت كنترل و انجام پروژههای نرمافزاری در نظر گرفته شده است. در اصل این چارچوبی در جهت انجام صحیح و موفق پروژههای نرمافزاری میباشد كه كلیه مراحل انجام یك پروژه كه با معماری و آنالیز سازمان شروع شده و به تست نرمافزار و ارائه Gold Release ختم میشود را در بر میگیرد (گروه كاسمیك ۲۰۰۳ الف)
چرا RUP را یک فرایند یکپارچه میگویند؟ به سه علت RUP را یكپارچه مینامند:
این متدولوژی از یكپارچهسازی سه متدولوژی معروف دیگر بوجود آمده است كه شامل Booch، OMT و OSE میباشد.
از UML۴ در جهت كارهای خود استفاده میكند. در واقع میتوان گفت UML خود ثمره RUP میباشد و این خود بسیار خوب است كه متدولوژیی با خودش گسترش یابد (گروه كاسمیك ۲۰۰۳الف). مفاهیمی از قبیل Object، Class و ... مفاهیم ساده و ثابتی هستند ولی قبلاً متدولوژیها علامتهای خاصی داشتند كه اكنون همه آنها یكسان شدهاند.
در داخل RUP یك چارچوب تولید نرمافزار است كه ما آنرا برای سازمان و پروژه خود بومی میكنیم و میتوان گفت كه در واقع یك قالب فرایند۵ است.
شكل ۱ ساختار اصلی RUP را مشخص میكند. اگر در بعد زمان به آن نگاه كنیم شامل ۴ فاز میباشد و اگر در هر لحظه به آن نگاه كنیم شامل ۹ قالب خواهد بود

شکل (2)ساختار اصلی RUP

۳ ) خصوصیات RUP چیست؟
RUP مبتنی بر نوعی معماری است كه به اجزاء اصلی میپردازد ولی طراحی به جزئیات نیز وارد میشود. همچنین میتوان گفت معماری یكسری اجزا و ارتباط بین آنها است كه سیستم را میسازد و ما را به سمت توسعه مؤلفهمحور۶ راهنمایی میكند.
ویژگی Usecase Driven: یكی از مشكلات OOA این بود كه میگفتند با هر روشی تبدیل و كار كنند و بعد بتوان آنرا به شیءگرا تبدیل كرد. یعنی مثلاً پروژه SSADM را طراحی كرده و بعداً به شیءگرا تبدیل نمود. ولی آن عقیده اشتباه بود و حتماً تحلیل شیءگرا باید صورت بگیرد. خصوصیت خوب شیءگرا كه در دیگر روشها نمیباشد این است كه نوتاسیونی كه استفاده میشود (بوچ، رامباق و جاكوبسون ۱۹۹۹) در همه مراحل یكی است یعنی مفاهیمی از قبیل شیء، كلاس، روابط كلاسها و ... در تمامی مراحل یكی است. اهمیتی كه Usecase Driven دارد این است كه با زبان مشتری نوشته میشود. مشتری میتواند آنرا بفهمد و بسیار مناسب برای تشخیص نیازمندیهای سیستم میباشد. در بخش تحلیل و طراحی از روی Usecaseها تحلیل و طراحی انجام میدهیم و مسائلی مانند مدیریت پروژه نیز تحت تاثیر Usecaseها هستند كه ما آنها را دستهبندی كرده و مدیریت میكنیم. همچنین راهنماهای سیستم هم تحت تاثیر Usecaseها (كراچتن ۲۰۰۰، ۲۹۸) ایجاد میشوند.
ویژگی Incremental: به معنی آن است که پروژه بصورت چهار مرحله حلقهای جلو میرود ولی در هر مرحله چرخش یك دسته از Usecaseها كامل و آماده استفاده میشود و كلیه این كارها در ۹ جریان كار۷ كه در شكل ۱ مشخص شده بود، قابل مشاهده است.
۴) دیدگاه اولیه درباره RUP
دیدگاهی كه RUP بر اساس آن طراحی شده، به گونهای است كه محدوده وسیعی از اهداف را پوشش دهد تا ضمانت اجرایی جهت انطباق با موارد زیر حاصل شود (كراچتن ۲۰۰۳)
ابعاد پروژه
(حوزه كاربردی برنامه)سیستمهای تجاری یا سیستمهای فنی.
(زمینههای تجارت )توسعه خانگی، توسعه محصولات، فروشندگان نرمافزار مستقل، توسعه قراردادی.
همانند هر ساختار پروسه دیگری، RUP نیز روش سیستماتیكی را برای به دست آوردن، سازماندهی و ارائه راهكارهای مهندسی نرمافزار در اختیارتان قرار میدهد. RUP برای سازماندهی راهكارها، بر یك مدل پروسه ساده و کاملاً زیربنایی استوار شده است كه توضیح این امر در قالب چند مقاله یا كتاب نمیگنجد.
با این وجود، ساختار پروسه مزبور را نمیتوان به یك ظرف خالی تشبیه نمود. این ساختار از قبل توسط حجم عظیمی از پروسههای راهكاری كه قبلاً در پانزده سال گذشته توسط ملیتهای مختلف تحصیل شده است و با شركت Rational ارتباط داشتهاند (افرادی كه قبلاً این شركت آنها را به خود جذب كرده و برخی از شركای این شركت نظیر IBM ، HP و BEA (كراچتن ۲۰۰۳) انباشته گردیده است. RUP مجموعه محدود و بستهای نیست كه به منظور كاربردهای عمومی منتشر شده باشد و پاسخ یا راهحل تمامی مشكلات توسعه نرمافزاری را دربرگیرد؛ بلكه ساختار RUP ساختار بازی است كه به منظور استنتاج باید شاخههای آنرا دنبال كنید و این ساختار سالانه دوبار روزآمد میگردد. ساختار RUP تصفیه شده است و پشتیبانی ابزاری و مندرجات آن نیز توسعه یافتهاند.
از یك سو، گروه توسعه پروسه شركت Rational، امر به روز سازی محتویات RUP را همگام با مقتضیات فنآوری و بازخوردهایی كه كاربران این ساختار ارائه میدهند، به عهده دارند و از سوی دیگر شركای متعدد این شركت و افرادی كه RUP را برای استحصال و سازماندهی فرایندهای راهكاری خود پذیرفتهاند و از آن برای اهداف مربوط به خود استفاده میكنند، ساختار ارائه شده توسط شركت Rational را تبلیغ نموده و آنرا را تكمیل میكنند.
ساختار RUP پیرامون چند منطق ساده و مرتبط به هم سازماندهی شده است:
RUP نقشهایی را تعریف میكند كه باید در پروسه وجود داشته باشد و بر مبنای آن، صلاحیتها، تخصصها و مسئولیتهای افرادی كه باید پیشرفت پروژه را محقق سازند، مشخص میشود.
RUP كارهایی را كه هر یك از افراد باید در عمل انجام دهند، به طور گام به گام تشریح میكند.
این عملیات با استفاده از ابزارهایی واقعی مانند مدلها، كدها، اسناد و گزارشها اداره میشوند.
در RUP به وفور با راهنماییهای مربوط به نقشهایی كه افراد باید به عهده بگیرند، فعالیتهایی كه باید انجام شوند و مصنوعات مورد نیاز برخورد خواهید نمود كه در قالب خطوط راهنما، الگوها، مثالها و معلمهای ابزاری ارائه میشوند كه چگونگی به وقوع پیوستن دستهای از فعالیتها توسط یك ابزار بخصوص را شرح میدهند.
تمامی این المانهای توصیف پروسه در قالب سامانههایی سازماندهی شدهاند.
RUP مقدماتی نه سامانه، بیش از چهل نقش و صد محصول را تعریف میكند و حاوی بیش از هزار صفحه راهنما است. همچنین میتوانید به پروسههای الحاقی متعددی كه وظایف و مندرجات بیشتری را به RUP اضافه میكند، دسترسی پیدا كنید. برخی از منتقدین RUP آنرا پروسهای بسیار سنگین تصور نموده و آنرا به كرگدنی تشبیه میكنند كه توان انجام تعداد نامحدودی عمل غیر معمول را برای شما فراهم میآورد؛ با این وجود نگاه ما به RUP همانند لوح باشكوهی از معارف است كه میتوانید آنچه را كه نیاز دارید، از داخل آن برگزینید.
اجازه بدهید مقایسهای انجام دهیم. اگر فرهنگ لغات مناسبی از ۸۰۰ لغت را انتخاب كرده باشید، میتوانید در خیلی از نقاط دنیا و در بسیاری شرایط، گلیم خود را از آب بیرون بكشید؛ ولی با انتخاب فرهنگ لغات حجیمی چون Webster ، اولاً هیچكس شما را مجبور به استفاده از لغاتی كه در فرهنگ لغات وجود دارد نمیكند، ثانیاً میتوانید سطح لغات محفوظی خود را برای انطباق با وضعیتهای مختلف ارتقا ببخشید و ثالثاً میتوانید فرهنگ لغات خود را بهبود دهید. فرهنگ لغت۸۰۰ لغتی باید فقط زیرمجموعهای از یك فرهنگ لغات باشد.
۵) انعطافپذیری RUP و انطباق با آن
RUP یك اصل عقیدتی یا یك آیین مذهبی نیست. ساختار RUP ساختار خشكی نیست كه بخواهد همه چیز را برای تولید نرمافزار در قالب خود درآورد. نیازی نیست كه حداقل چهل نفر را برای تكمیل پروسهای كه چهل نقش در آن تعریف شده است، به خدمت بگیرید و نیازی ندارید كه بیش از صد محصول مختلف را پرورش دهید. اگر سعی خود را به انجام این كار معطوف سازید، خیلی زود در معرض آشفتگی قرار خواهید گرفت. این المانها در RUP و در فرم الكترونیكی (كراچتن ۲۰۰۳) برای فراهمآوردن انعطافپذیری مورد نیاز برای انطباق با تقاضایی ارائه شدهاند كه به شرایط محیطی كه درآن به سر میبرید، بستگی دارد.
RUP تمرینات تولید نرمافزار ثابت شده فراوانی را در بردارد. شركت Rational میدان دید بالایی را برای موارد زیر، ارائه میدهد:
ـ توسعه مكرر
ـ مدلسازی بصری
ـ مدیریت ملزومات تغییرات كنترل
ـ بازبینی مداوم كیفیت
ـ استفاده از معماری بر مبنای اجزا
همچنین URP بر مبنای دیگر اصول كلیدی دیگری كه كمتر قابل مشاهده هستند و سادهتر به محاق فراموشی سپرده میشوند، استوار شده است كه فقط برای یادآوری اشارهای به آنها مینماییم (جنر ۲۰۰۲) :
ـ منحصراً آنچه را كه مورد نیاز است، پرورش دهید.
ـ روی نتایج ارزشمند تمركز كنید، نه روی چگونگی حصول نتایج
ـ كاغذبازی را به حداقل برسانید.
ـ انعطافپذیر باشید.
ـ از اشتباهات خود عبرت بگیرید.
ـ به طور منظم، مخاطرات محتمل را مورد بازبینی قرار دهید.
ـ برای پروسه موردنظر معیارهای قابل اندازهگیری و علمی را بدون موضعگیری شخصی استوار كنید.
ـ از گروههای كوچك و توانمند استفاده كنید.
ـ طرحی را در ذهن داشته باشید.
ذهنیت كلیدی در سازگار شدن و سازگار كردن RUP قالب توسعه۸ میباشد. یك قالب توسعه نمونهای از RUP است كه برای پروژه ویژهای كه مد نظرتان است، مناسب باشد. با مراجعه به ساختار RUP به توضیح پروسهای دست مییابید كه موارد زیر را تعریف نموده و شناسایی میكند (جنر ۲۰۰۲)
ـ چه چیزی توسعه داده خواهد شد؟
ـ به چه مصنوعاتی واقعاً نیاز داریم؟
ـ چه الگوهایی باید مورد استفاده قرار بگیرند؟
ـ كدام مصنوعات در حال حاضر وجود دارند؟
ـ به چه نقشهایی نیاز داریم؟
ـ چه فعالیتهایی انجام خواهند شد؟
ـ كدام خطوط راهنما، استانداردهای پروژه و ابزارهایی مورد استفاده قرار خواهند گرفت؟
۶) نتیجه گیری
از آنچه گذشت در مییابیم اولاً در حال حاضر تنها روش توسعه نرمافزاری که مورد پذیرش در عرصه جهانی است، RUP میباشد. ثانیاً این روش علاوه بر ساماندهی به فرایند تولید نرمافزار از دو بعد زمان و کیفیت، به لحاظ برخورداری از انعطافپذیری بالا در صورت کاربرد و پیاده سازی صحیح میتواند سبب تسریع فرایند تولید و توسعه نرمافزار و تأمین کیفیت مورد نظر در نرمافزار گردد و نهایتاً این که یکی از مهم ترین ویژگیهای RUP این است که قابلیت توسعه و تغییر نرمافزار ها را بر اساس تغییر نیازهای کاربران و نیز تغییر فناوری، از قبل پیش بینی نموده است.

[آبجی]

مروري كلي بر متدولوژي RUP


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

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

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

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

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

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

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


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



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



- 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)
هدف اصلي اين فاز ساخت و پياده‌سازي بخش طراحي شده در فاز قبل مي‌باشد. در اين فاز نسخه 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)
هدف اين فاز انتقال و تحويل محصول نرم‌افزاري به سازمان مشتري مي‌باشد. زماني‌ كه محصول در اختيار كاربران نهايي قرار گيرد, نظرات و بازخوردهايي از سوي ‎آنها مطرح مي‌شود كه منجر به پياده‌سازي اجزاي جديدي در سيستم شده و يا موجب تصحيح قسمت‌هايي از برنامه مي‌شود. در اين فاز درخواستهاي تغيير كه توسط كاربران سيستم اعلام شده مديريت و در سيستم اعمال مي گردند. در اين فاز نحوه و نيازهاي جهت استقرار سيستم اعلام مي گردد و اسناد آن تحويل داده مي شود.

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



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



- Release Note

- Deployment Plan

- Installation Artifacts

- Training material

- End user Support material

- Product Builder

- Configuration Data

- Software Installation Media

- طرح تكرار Iteration Plan

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

- گزارش ارزيابي تكرار Iteration Assessment Report

[آبجی]

عناصر RUP
در استفاده از RUP ، مفاهيم و عناصر كليدي اي وجود دارند كه با درك درست و استفاده مناسب از آنها مي توان پروژه را با موفقيت به پايان رساند.

شكل زير، نمايانگر عناصرRUP مي باشد.


فرآيند مهندسي نرم­افزار در RUP، متشكل از مجموعه اي از نظام­ها (disciplines) مي­باشد، كه در شكل زير نشان داده شده­ است.

[samnet]

آبجی خانم
rup یک متدلوژی نیست بلکه یک مدل فرآیند است.

[Admin]

آبجی خانم
rup یک متدلوژی نیست بلکه یک مدل فرآیند است.

متدولوژی یا مدل فرایند ...
می شه گفت ترکیبی از هر دو ... ولی در همه جا rup رو به عنوان متدولوژی ذکر کرده ... البته این از ایرادات و یا مطابق نبودن ترجمه های کنونی با اصطلاحات بکار برده شده است ...

در اصل ...

usdp يک فرايند توليد نرم افزار است

و

rupبعنوان نمونه خاصی از usdp مطرح می گردد.

و منظور اینه که چیزی بین یک متد و یک فرایند تولید نرم افزار...

[Admin]

خب ادامه بحث از پست شماره #11

آزمون نرم افزار ( Software Testing ):
در مباحث آزمون نرم افزار دو نوع روش داریم ...

که این دو نوع روش هر کدام به سه نوع آزمون مجزا نیز تقسیم می شوند ...

1. روش های مبتنی بر White Box
- آزمون مسیرهای پایه ( Basic Path Testing )
- آزمون شرط ( Condition Testing )
- آزمون حلقه ها ( Loop Testing )

2. روش های مبتنی بر Black Box
- افراز به مجموعه های معادل ( Equivalent Partitioning )
- تحلیل مقادیر مرزی ( Boundry Value Analysis )
- آزمون مقایسه ای ( Compairison Testing )

در روش مبتنی بر White Box ما فرض می کنیم کل سیستم در یک جعبه ی شیشه ای قرار دارد که تمامی جزئیات سیستم برای ما قابل مشاهده و لمس است. ( در این روش هزینه ، زمان و دانش بالائی نیاز است )

در روش مبتنی بر Black Box ما فرض می کنیم تمامی سیستم در داخل جعبه ی تاریک قرار دارد و هیچ کدام از جزئیات آن قابل مشاهده نیست و ما برای تست تنها باید با توجه به دادن ورودی های بخصوص و دریافت خروجی ها بررسی کنیم که ورودی مربوطه با خروجی دریافتی یکسان است یا نه ...! ( در این ورش هزینه ، زمان و دانش پائینی نیاز دارد )

چون معمولا توانایی این رو نداریم که سیستم رو کاملا به صورت White Box تست کنیم بنابراین بخش هایی رو به صورت White Box و بخش هایی رو با روش Black Box تست می کنیم که به آن روش Hybrid می گویند.

مقوله ی 80-20: مقوله ای در مهندسی نرم افزار هست که می گوید معمولا همیشه 20 در صد از بخش های نرم افزار 80 درصد از خطاها را دارند و 80 درصد باقیمانده تنها 20 درصد از خطاها را دارند.

در مباحث بعدی به ترتیب آزمون های Black Box و White Box را به ترتیب تک تک بررسی و نحوه ی تست نرم افزاری را آموزش می دهیم ...

[Admin]

آزمون های مبتنی بر White Box

1. آزمون های مسیرهای پایه:

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

در ادامه یک مثال می زنیم ...
فرض کنید برنامه زیر را داریم با توجه به برنامه ی زیر گراف مربوطه در مقابل برنامه رسم می شود ...

برای پیدا کردن تعداد مسیرهای پایه در گراف بدست آمده سه روش موجود است ...

1. تعداد مسیرهای پایه = تعداد یالها - تعداد گره ها +2

در مثال بالا بدست می آید ...
9-8+2 = 3

2. تعداد مسیرهای پایه = تعداد گره های شرطی +1

در مثال بالا بدست می آید ...
2 + 1 = 3

3. تعداد مسیرهای پایه = تعداد مسیرهای بسته + 1

در مثال بالا بدست می آید ...
2 + 1 = 3

در گام بعدی باید هر یک از n مسیر محاسبه شده در گام قبلی را توصیف کنیم ...

آدرس مسیر اول : 1 --> 2 --> 3 --> 8
آدرس مسیر دوم : 1 --> 2 --> 3 --> --> 4 --> 5 --> 7 --> 3 --> 8
آدرس مسیر سوم: 1 --> 2 --> 3 --> 4 --> --> 6 --> 7 --> 3 -->8

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

همچنین مسیر های جدید با توجه به یالهای پیمایش نشده حساب می شود. ( یعنی تا زمانی که یال پیمایش نشده موجود باشد یعنی مسیر جدید باید داشته باشیم ).

پس با توجه به فرمولهای بالا و با توجه روش عملی دیدیم که تعداد مسیرهای پایه در گراف بدست آمده به راحتی با توجه به سه فرمول ارائه شده قابل محاسبه است ...