مفاهیم متدولوژی RUP

عنوان مقاله: مفاهیم متدولوژی RUP

RUP Methodology Concepts

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

Akbar Gharakhani Bahar

آدرس پست الکترونیکی نویسنده/ مترجم: [email protected]

تاریخ تهیه: 1384

ارسال کننده: همفکران جامعه مجازی - تاریخ ارسال: 1388

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

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

سه کلیدواژه اصلی به ترتیب اهمیت: مبانی RUP، جنبههای عمومی RUP، معماری مبتنی بر جزء

سه کلیدواژه فرعی به ترتیب اهمیت: سند چشمانداز، طرح توليد نرمافزار، مدیریت پروژه نرمافزاری

چکیده مقاله

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

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

مفاهیم متدولوژی RUP

مقدمه

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

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

متدولوژیRUP دارای جنبههایی عمومی است که در صورت کاربرد آن، استفاده از آنها در همه انواع پروژهها توصیه میگردد. هر سازمانی به فراخور نیاز خود میتواند مجموعه منتخبی از امکانات RUPرا که مناسب پروژههای آن سازمان باشد انتخاب و با اعمال برخی تغییرات ( شامل کاستن یا افزودن)، از آن به عنوان ابزار کار در«مطالعه»، «طراحی»، «تولید» و «تحویل» محصولات نرمافزاری خود استفاده کند.

RUPبه عنوان متدولوژی ایجاد نرمافزار، مراحل سه گانه تولید نرمافزار را در 4 فاز به شرح زیر تعریف مینماید:

فاز اول - آغازی – inception: رسیدن به این که چه نرمافزاری میخواهیم بسازیم.
فاز دوم – تکمیلی – elaboration: رسیدن به این که نرمافزار را چگونه باید بسازیم.
فاز سوم - ساخت – construction: ساختن نسخه آزمایشی نرمافزار
فاز چهارم - انتقال – transition: تکمیل و عملیاتی کردن نسخه نهایی نرمافزار

در RUPپایان هر فاز در واقع با «تکمیل و تحویل محصولات فاز» مشخص میشود. در این صورت گفته میشود که «ملاک» (mile stone) برای پایان آن فاز برآورده شده یا به آن رسیده شده است. ملاکهای نشان دهنده پایان هر فاز دارای عناوینی مرتبط با محصولات خود هستند.

مبانی RUP

متدولوژیRUP خود دارای ابعادی مبتنی بر تکنیکهای شیئیگرا است. این گفته بدین معناست که RUP نیز دارای دو بعد «ساختار» و «رفتار» است. یک بعد آن زمان و شامل فاز، تکرار و ملاکهای پایان هر فاز است که جنبههای «پویا» (dynamic) یا رفتار RUP را نمایندگی میکند و «دوره عمر» (life cycle) نرم افزار را در برمیگیرد.

بعد دیگر آن فرایندهای اصلی و به عنوان هسته، شامل فعالیتها، محصولات جانبی کار و قواعد مربوطه است که جنبههای «ایستا» (static) یا ساختار RUP را نمایندگی میکند و با دستهبندی فعالیتهای مهندسی نرمافزار به صورتی منطقی، «جریانهای کار» (work flows) نرمافزار را در برمیگیرد. بعد فرایندهای اصلی یا جریانهای کار به ترتیب شامل موارد زیر است:

مدلسازی کار و فعالیت – Business Modeling
نیازمندیهای منجر به درخواست نرمافزار - Requirements
تجزیه و تحلیل و طراحی – Analysis and Design
پیادهسازی - Implementation
تست و آزمون - Test
انتقال محصول به محیط کاربران - Deployment
مدیریت ترکیببندی و تغییرات – Configuration and Change Management
مدیریت پروژه – Project Management
محیط - Environment

مطالب گفته شده در مورد ساختار و رفتار RUP و میزان پرداختن به گردشکارها در هر فاز، در جدول زیر نشان داده شده است:

جریانهای کار	فازها
آغازی	تکمیلی	ساخت	انتقال
مدلسازی کار	خیلی زیاد	خیلی زیاد	زیاد	کم
نیازمندیها	خیلی زیاد	خیلی زیاد	زیاد	کم
تجزیه و تحلیل و طراحی	زیاد	خیلی زیاد	خیلی زیاد	کم
پیادهسازی	کم	خیلی زیاد	خیلی زیاد	زیاد
تست و آزمون	کم	زیاد	خیلی زیاد	کم
انتقال	خیلی کم	کم	زیاد	خیلی زیاد
ترکیببندی و تغییرات	کم	کم	خیلی زیاد	خیلی زیاد
مدیریت پروژه	زیاد	زیاد	زیاد	زیاد
محیط	زیاد	زیاد	زیاد	زیاد

عنوان	فازها
آغازی	تکمیلی	ساخت	انتقال
تعداد تکرارهای قابل انجام	2	2	3	2
درصد تقریبی از کل فرایند	5 الی 10 درصد	20 الی 30 درصد	50 الی 65 درصد	10 الی 15 درصد

متدولوژیRUP همچنین بر مبنای اصول عملیاتی مشخصی در تولید نرمافزار که از آنها تحت عنوان «بهترین اعمال قابل انجام» (best practices) یاد میشود، ارائه شده است. این اعمال را میتوان به صورت زیر برشمرد:

ایجاد نرمافزار در قالب تکرارهای مختلف
مدیریت نیازمندیهای منجر به درخواست نرمافزار
استفاده از معماری موسوم به «مبتنی بر جزء» (component – based) در طراحی نرمافزار
مدلسازی به صورت نموداری
ارتقاء پیوسته کیفیت نرمافزار
کنترل دقیق تغییرات در نرمافزار

در ادامه مطلب به شرح هریک از موارد بالا میپردازیم.

ایجاد نرمافزار در قالب تکرارهای مختلف

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

در روش سنتی تولید نرمافزار یا قالبهای کار مبتنی بر آن که از آن تحت عنوان روش «آبشاری» (waterfall) یاد میشود، شروع یک فاز تا پایان یافتن فاز قبلی ممکن نیست. به بیان دیگر، در این روش، کار تولید نرمافزار از ابتدا تا انتها به صورت مراحل پشت سرهم انجام میشود. مزایای استفاده از روش تکراری به جای روش آبشاری را میتوان به صورت زیر برشمرد:

واقعیت این است که سفارش دهندگان نرمافزار قادر نیستند تمامی نیازمندیهای منجر به درخواست تولید نرمافزار را نظیر آنچه که در روش سنتی عمل میشود، در ابتدای کار عنوان کنند. به بیان دیگر، نیازمندیهای اولیه عنوان شده برای تولید نرمافزار در طول فرایند تولید آن تغییر میکنند. تجربیات نشان میدهند که یکی از دلایل شکست پروژههای نرمافزاری، تغییرات در نیازمندیهای عنوان شده اولیه است که در نهایت به بیاستفاده ماندن محصول نرمافزاری تولید و ارائه شده در انتهای کارمنجر میشود.
در روش سنتی، سفارشدهندگان نرمافزار بعد از دادن سفارش خود، برای تحویل محصول مورد نظر باید تا انتهای کار منتظر بمانند. با این نحوه عمل، به خاطر تغییرات در نیازمندیها، آنان غالبا در انتهای کار با محصولی روبرو میشوند که ممکن است دیگر برای آنان قابل استفاده نباشد. گفته شده که این روش یادآور نظریه «انفجار بزرگ» (big bang) در ایجاد عالم هستی است، که در مورد نرمافزار به «تحویل همه چیز در آخر کار» تعبیر میشود و تولیدکنندگان و استفادهکنندگان را دچار مشکل میکند. متدولوژی RUP برای رفع این مشکل، روش تدریجی در قالب تکرارها را تجویز میکند که ثمره آن تحویل تدریجی محصول و رفع نواقص کار در هر تحویل جدید است. در RUP کل فرایند به 6 الی 9 قطعه کوچکتر تحت عنوان تکرار تقسیم میگردد و سعی میشود در طی هر کدام از آنها بخش مشخصی از محصولات تولید شده و تحویل شوند.
یکی دیگر از عوامل شکست پروژههای نرمافزاری، مخاطراتی است که گاه با وجود کوچک و ناچیز بودن نیز یک پروژه نرمافزاری را به شکست میکشانند. مخاطرات در راه عملیاتی شدن نرمافزار در دست تولید، در طول فرایند تولید به تدریج رخ مینمایند. در RUP هدف این است که این قبیل مخاطرات از ابتدای کار مورد شناسایی قرار گرفته و در زمانهای مناسب تدابیر مناسب برای آنان اتخاذ گردد. با استفاده از مفهوم تکرار، با مخاطرات بهتر میتوان برخورد کرد.
با استفاده از مفهوم تکرار میتوان بخشهای مشترک قابل استفاده مجدد از نرمافزار را بهتر تشخیص داد و در نتیجه به آن نوع معماری از نرمافزار رسید که «استفاده مجدد» (reuse) از بخشهای تهیه شده قبلی را امکانپذیر سازد.
در طول تکرارهای مختلف، خطاهای موجود به تدریج برطرف میشوند. در نتیجه رفع همه خطاها به زمان تست نهایی نرمافزار موکول نمیگردد.
در روش سنتی، بسیاری از منابع انسانی تدارک دیده شده برای تولید نرمافزار، در زمانهایی که هنوز کاری برای انجام ندارند، معطل میمانند. با استفاده از مفهوم تکرار و تاکید بر ارائه یک بخش از محصول نهایی (حتیالامکان بخشی از نرمافزار قابل اجرا) در هر تکرار، تقریبا تمامی افراد با تمامی تخصصها در تمامی طول فرایند تولید نرمافزار به کار مشغول میشوند.
استفاده از مفهوم تکرار باعث میشود که بتوان خود فرایند تولید نرمافزار را نیز به تدریج اصلاح نمود.

مدیریت نیازمندیهای منجر به درخواست نرمافزار

مدیریت نیازمندیهای تولید نرمافزار، عاملی کلیدی در موفقیت هر پروژه نرمافزاری است. نیازمندیها باید شناسایی شده و تغییرات در آنها در فرایند تولید نرمافزار باید به دقت مورد توجه قرار گیرند. درRUP«موارد کاربرد سیستم» (system use cases) به عنوان مبنای کار قرار دارد. موارد کاربرد سیستم وسیلهای برای مستندسازی نیازمندیها و ارتباط با کاربران سیستم جهت رسیدن به درکی مشترک از آنچه که تحویل خواهد شد، میباشد. هر مورد کاربرد از سیستم در واقع به منزله یک نیاز برای درخواست ایجاد سیستم است. معنی این گفته آن است که موارد کاربرد سیستم میتوانند تعیین کننده نحوه عمل در بقیه فرایند تولید نرمافزار نیز باشند. استفاده از این روش، شناخت نیازمندیها و مدیریت تغییرات در آنها را تسهیل میکند.

استفاده از معماری «مبتنی بر جزء» در طراحی نرمافزار

«جزء/ مؤلفه» (component) یک بخش از نرمافزار است که دارای عملکرد در محدوده مشخصی است. هر جزء از نرمافزار به این مفهوم باید بتواند به عنوان عنصری از یک معماری کل نرمافزار عمل نماید. مزایای این رویکرد در تولید نرمافزار را میتوان به صورت زیر بر شمرد:

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

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

مدلسازی به صورت نموداری

يک مدل در واقع فرم ساده شده و به صورت قابل نمایش در آمده يک چیز واقعی است. در طراحی یک مدل از یک شیئی واقعی معمولا به جنبههایی از آن توجه میشود که در کار مورد نظر ما دارای اهمیت باشند. برای مدل سازی سیستمهای نرمافزاری زبان خاصی تحت عنوان UML(Unified Modeling Language) به وجود آمده است که در RUP نیز از آن استفاده میشود. باید گفت که UML تنها مجموعهای از نمادها و روشها برای ساختن مدلها است و نحوه ساختن نرمافزار را به ما نشان نمیدهد. با استفاده از UML در قالبی نظیر RUP است که نحوه ساختن نرمافزار مشخص میگردد.

ارتقاء پیوسته کیفیت نرمافزار

در RUP سعی شده است که وظیفه کنترل کیفی به جای وظیفه بودن برای یک فرد یا گروهی از افراد خاص، وظیفه همه افراد درگیر در کار نرمافزار باشد. در RUP کنترل کیفی هم در سطح محصول، تحت عنوان «کیفییت محصول» (product quality)، شامل کیفیت محصولی که تولید خواهد شد، به همراه تمامی اجزاء آن و هم در سطح فرایند تحت عنوان «کیفیت فرایند» (process quality)، شامل محصولات جانبی برای تولید نرمافزار نظیر مدلها و غیره مورد توجه قرار دارد.

کنترل دقیق تغییرات در نرمافزار

در روش سنتی تولید نرمافزار، برای اعمال تغییرات محدودیتهایی وجود دارد و زمان اعلام و انجام تغییرات غالبا به اوایل شروع پروژه محدود میشود. در RUP برعکس روش سنتی، این محدودیت دامنه کمتر و زمان بیشتری را در بر میگیرد و به بیان دیگر محدودیت کمتری وجود دارد. فلسفه وجود تکرارها در RUP نیز به خاطر همین موضوع است. با این وجود هر گونه تغییری غالبا هزینهای دارد و RUPمیخواهد این هزینهها را در حد ممکن کم کند.

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

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

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

در نظر داشتن نیازمندیها در هنگام طراحی و در نظر داشتن طراحی در هنگام برنامهنویسی یکی از راههای کاستن از هزینههای تغییرات است. اثر تغییرات روی هزینهها را میتوان درفازهای مختلف کار تولید نرمافزار مورد بررسی قرار داد. یک بررسی عمومی نتایجی به شرح زیر را به دست میدهد:

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

همانطور که دیدیم، در فاز سوم (ساخت)، نوعی «جزء/ مؤلفه» (component) گرایی تجویز شده و بر آن تاکید میشود. بنابراین هزینههای مربوط به تغییرات در مؤلفههای سیستم تا پایان فاز سوم پایین است ولی در فاز چهارم (انتقال) افزایش مییابد. هر جزء یا مؤلفه بخشی برنامهای از سیستم است که کار محدود و معینی را روی یک یا مجموعهای از اشیاء سیستم انجام میدهد. بدین خاطر توصیه میشود که در پایان فاز ساخت نوعی «فریز کردن» تغییرات در سطح مؤلفهها در نظر گرفته شود.
باید توجه کرد که در فاز چهارم (انتقال)، کاستن از برخی امکانات دارای مشکل سیستم و موکول کردن آنها به ترخیص بعدی از نرمافزار، یکی از راههای رسیدن زودتر به نرمافزار قابل اجراست. بنابراین توصیه میشود که در هنگام تحویل گرفتن سیستم، از سیاست «همه چیز یا هیچ چیز» پیروی نشود.

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

جنبههای قابل توصیه عمومی RUP

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

جنبههای قابل توصیه عمومی RUP به شرح زیر قابل بیان است:

تهیه سندی به عنوان چشمانداز از مشخصات کلی نرمافزار در دست تولید
تهیه طرح تولید نرمافزار و مدیریت پروژه با استفاده از آن
شناسایی مخاطرات در راه پروژه و نرمافزار در دست تولید و کوشش در جهت حذف یا تخفیف آنها
ردگیری پیشرفت پروژه
ارزیابی کارهای انجام شده از نظر هزینه
پایبندی به معماری مبتنی بر«جزء/ مؤلفه»
ساخت و تست پیشرونده بخشهای محصول نهایی
تعیین و ارزیابی نتایج میانی
مدیریت و کنترل تغییرات درخواستی
پایبندی به اصول حمایت از کاربران محصول تولیدی

در ادامه مطلب به شرح هریک از موارد بالا میپردازیم.

سند چشمانداز

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

سند چشمانداز باید موارد زیر را در بر گیرد:

· مفاهیم کلیدی در قالب «اصطلاحات» (glossary)

· مسئلهای که به کمک نرمافزار میخواهیم آن را حل کنیم در قالب «بیان مسئله» (problem statement)

· طرفهای کار و کاربران نهایی و نیازهای آنان از درخواست سیستم

· جنبههای مختلف محصول تولیدی

· نیازهای عملکردی در قالب «موارد استفاده» (use cases) از سیستم

· نیازهای غیر عملکردی

· محدودیتهای طراحی

طرح تولید نرمافزار

طرح تولید برای یک محصول به اندازه خود محصول دارای اهمیت است. در RUP سندی تحت عنوان «طرح تولید نرمافزار» (Software Development Plan = SDP) تهیه میشود که در آن جنبههای مختلف تولید نرمافزار مورد شرح و بسط قرار میگیرد. نسخه اولیه این سند از محصولات فاز آغازی است و در تمامی طول فرایند ایجاد نرم افزا از فاز آعازی تا فاز انتقال باید مورد تجدید نظر قرار گرفته و بههنگام شود.

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

از SDP همچنین برای پیگیری عملیات در مطابقت با برنامه و ایجاد هماهنگی با اجزاء دیگر پروژه استفاده میشود. بنابراین SDPباید شامل سایر اطلاعات مورد نیاز در این زمینهها از قبیل سازمان پروژه، تغییرات در محصول تولیدی، طرحهای تست و آزمون، ترکیببندی، تضمین کیفیت، ارزیابی و پذیرش نرمافزار نیز باشد.

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

مقدمه، خلاصهای از کل سند شامل:

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

مرور پروژه شامل:

اهداف و دامنه پروژه
فرضهای اولیه و محدودیتها
محصولات پروژه
تکامل طرح تولید نرمافزار

سازمان پروژه شامل:

ساختار سازمانی اعضای تیم پروژه
روابط بیرونی پروژه
نقشها و مسئولیتهای افراد

مدیریت پروژه شامل:

تخمینهای به عمل آمده
طرح عملیاتی و تقسیم کار پروژه شامل طرح هر فاز، اهداف تکرارها، ترخیص محصولات هر فاز و غیره
نظارت بر پروژه و نحوه کنترل آن

ضمائم

شناسایی و کم اثرکردن مخاطرات

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

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

اکثر مخاطرات به معماری سیستم مربوط میشوند. یکی از دلایلی که سعی میشود موضوع معماری سیستم در طی فاز دوم (تکمیلی) کامل گردد در همین نکته نهفته است. علت عدم اکتفا به طراحی تنها و سعی در ارائه یک نمونه اولیه قابل آزمودن از سیستم توسط کاربران نهایی سیستم نیز همین است.

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

ردگیری پیشرفت پروژه

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

باید گفت که بهترین راه تعیین میزان پیشرفت کار در واقع تعیین میزان نرمافزار آماده شده و قابل اجرا است. اگرچه تهیه انواع مستندات اعم از معمولی یا الکترونیکی جزء ضروریات کار تولید نرمافزار هستند و پرداختن به آنها نیزلازم است، ولی مستندات جدای از نرمافزار غالبا معیار خوبی برای ارزیابی میزان پیشرفت یک پروژه نرمافزاری نیست. متاسفانه یکی از خطاهای رایجی که در استفاده از RUP وجود دارد، تهیه انواعی از مستندات غیر ضرور است، تنها به این دلیل که در RUPگفته شده است که چگونه میتوانند تهیه شوند.

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

ارزیابی کار از نظر هزینه

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

پایبندی به معماری مبتنی برجزء/ مؤلفههای نرمافزاری

همانطورکه دیدیم، در RUP استفاده از معماری مبتنی بر جزءهای نرمافزاری و این نکته که قطعات اصلی نرمافزاری چه هستند و چگونه باهم مرتبط میگردند تا محصول نهایی را به وجود آورند، دارای اهمیت زیادی است. به منظور بحث در این زمینهها ابتدا باید نمایشی از معماری نرمافزار که در آن جنبههای کلی نرمافزار مورد شرح قرار گیرد، تهیه شود. این مطالب در سندی تحت عنوان «سند معماری نرمافزار» (software architecture document) آورده میشود.

منظور از معماری سیستم، اجزاء و مؤلفههای مهم آن نظیر سیستمهای فرعی تحت آن و رابطهای کاربران آنها و رابط کاربران خود سیستم است.معماری سیستم شامل اسکلتی از ساختمان سیستماست که معادل 10 الی 20 درصد برنامه یا کد نهایی تهیه شده برای سیستم را در برمیگیرد. از آنجا که رسیدن به یک معماری درست در ابتدای کار مشکل است، بنابراین ضرورت دارد که افراد خبرهتری برای تهیه آن درگیر شوند.

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

یکی از معایب روشهای قبلی تجزیه کار برنامهنویسی که از آن میتوان با عنوان «تجزیه عملکردی» (functional decomposition) یاد کرد، جدا بودن دادهها از رویههای عملیاتی به کارگیرنده آنها است. این کار باعث هزینهبر شدن انجام اصلاحات و یا توسعه سیستم میشود. به عنوان مثال، در این روش، تغییر در نوع یک داده ممکن است چندین رویه عملیاتی را متاثر کند. در استفاده از این روشها، آنچه که مهم است مشکل بودن تعیین رویههای عملیاتی است که ممکن است از چنین تغییری متاثر شوند. این وضعیت عامل عمده بحران سال 2000 در مورد سیستمهای نرمافزاری بود که به بحران Y2K شهرت یافت.

در مقابل، پایبندی به معماری موسوم به اجزاء/ مؤلفههای نرمافزاری که در واقع بیان دیگری از مفهوم «شیئی» (object) است، باعث مجتمع شدن دادهها با رویههای عملیاتی به کار گیرنده آنها شده و آن را به صورت یک جزء برنامهای مستقل در میآورد. بنابراین اعمال تغییرات در دادهها اعم از نوع یا انجام عملیات روی آنها، در این جزء مستقل محدود میشود. این وضعیت به نوبه خود باعث استحکام سیستم و تسهیل اعمال تغییرات بدون نگرانی از تاثیرات جانبی آن میشود. استفاده از این ایده به تدریج به تشکیل مجموعههایی از اجزاء با «قابلیت استفاده مجدد» (reusable) منجر میشود.

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

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

ساخت و تست پیشرونده بخشهای محصول نهایی

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

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

تعیین و ارزیابی نتایج

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

مدیریت و کنترل تغییرات در محصول تولیدی

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

پایبندی به حمایت از کاربران از محصول تولیدی

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

منابع

در تهيه اين مقاله از نوشتههای افراد زير که مبتنی بر تجربيات عملی نامبردگان و به صورت الکترونيکی بودهاند، استفاده شده است:

*سمت حرفهای*	*نام*
Director, RUP Development and Product Management Teams	Kroll, Per
Rational Fellow, Rational Software Canada	Kruchten, Philippe
Development Manager, RUP, Rational Software Canada	Probasco, Leslee
Project Management Consultant	Wideman, Max
RUP Implementation Workshop Group	...

مفاهیم متدولوژی RUP

مطالب مشابه :

آموزش (The Universal Modelling language) UML

فرآیند یکپارچه رشنال ( RUP ) - Rational Unified Process

مفاهیم متدولوژی RUP

پایان نامه کامپیوتر تحقیق کامپیوتر