معماري و ساختار كلي 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 براي كنترل خروجي‌هاي متعدد توليد شده توسط افراد زيادي كه روي يك پروژه كار مي‌كنند، ضروري است. كنترل، به اجتناب از اغتشاشِ پرهزينه كمك مي‌كند و تضمين مي‌نمايد كه خروجي‌هاي بدست آمده با توجه به برخي انواع مسائل و مشكلاتي كه در زير آمده‌اند ناسازگار نيستند.
• به روز رساني همزمان
• توجه دادن محدود شده
• نسخه‌هاي چندگانه
* ارسال مقاله توسط عضو محترم سايت با نام کاربري : sm1372/خ