برای کسی که اولین بار با RUP  (که دارای 4 فاز، 9 دیسیپلین، 31 نقش، 103 دست‌آورد، 136 فعالیت، بعلاوه رهنمودها، چک‌ لیست‌ها و راهنمای ابزار می‌باشد) مواجه می‌شود این سؤال پیش می‌آید که ”چطور می‌توان از میان این همه موارد تعیین کنیم که کدام یک برای پروژه ما مورد نیاز است؟“، ”آیا به این یکی نیاز دارم؟“، ”آیا RUP فقط برای پروژه‌های بزرگ است؟“ و پاسخ نیز اغلب به این صورت است : ”خب بستگی دارد به ... “ در این مطلب یک لیست از ده مورد اساسی و ضروری RUP که می‌تواند نقطة شروعی برای چگونگی بکارگیری RUP در هر پروژه باشد معرفی می‌شود. البته ضروری است که چارچوب کلی RUP که یک فرآیند تکراری و تکاملی  است  لحاظ شود.
این ده مورد عبارتند از :

1- تصویر کلی ( Vision) – تولید یک تصویر کلی
داشتن یک تصویر کلی واضح، برای تولید محصولی که نیازهای واقعی ذی‌نفعان را برآورده سازد، کلیدی است. تصویر کلی عصاره‌ای از دیسیپلین نیازمندی‌ها در RUP بدست می‌دهد : تحلیل مسأله، شناخت نیازهای ذی‌نفعان، تعریف سیستم و مدیریت نیازمندی‌ها(زمانی که تغییر می‌کند).
2- طرح (برنامه) – مدیریت طرح
طرح‌ریزی خوب روند تولید محصول تأثیر کاملا مستقیمی بر روی کیفیت خوب محصول خواهد داشت. در RUP، طرح تولید نرم‌افزار (Software Development Plan)، همه اطلاعات مورد نیاز برای مدیریت پروژه را گرد‌آوری می‌کند.
3- لیست مخاطرات- شناسایی و کاهش ریسک‌ها
یک دستور اساسی RUP، شناسایی و رفع هرچه زودتر به ریسک‌های عمده پروژه است. لیست ریسک‌ها، به منظور در نظرگرفتن ریسک‌های شناخته شده در راه موفقیت پروژه است.
4- موارد مهم – تعیین و ردیابی موارد مهم
ارتباط باز و مداوم با داده‌های عینی که مستقیما از فعالیت‌های در حال انجام مشتق می‌شوند، و تکمیل پیکربندی محصول در هر پروژه، اهمیت دارد.
5- طرح تجاری (Business Case)
طرح تجاری، اطلاعات لازم را از نقطه نظر تجاری فراهم می‌کند؛ به منظور تعیین اینکه آیا این پروژه ارزش سرمایه گذاری دارد یا نه؟
6- معماری – طراحی یک معماری بر اساس مؤلفه
در RUP، معماری یک سیستم نرم‌افزاری (در یک مقطع خاص)، سازمان یا ساختار مؤلفه‌های مهم سیستم است که از طریق واسط‌ها با مؤلفه‌های متشکل از مؤلفه‌های کوچکتر و واسط‌های آنها ارتباط دارند. در واقع پاسخ به این سؤال است که تکه‌های اصلی کدامند و چگونه با هم جور می‌شوند؟
7- محصول - ساخت و تست گام به گام (افزایشی) محصول
عصاره جریان کارهای پیاده‌سازی و تست در RUP، کدنویسی، ساخت و تست گام به گام مؤلفه‌های سیستم، با نشرهای قابل اجرا در پایان هر تکرار بعد از فاز آغازین است.
8- ارزیابی (Evaluation)
ارزیابی تکرار، نتایج یک تکرار، میزان برآورده شدن معیار ارزیابی، دروس آموخته شده و تغییرات فرآیند که باید پیاده‌سازی شوند، را دربر می‌گیرد
9- درخواست‌های تغییر (Change Request)
عصاره مدیریت پیکربندی و تغییرات، مدیریت و کنترل محدوده‌ پروژه در هنگامی است که تغییرات در طول چرخه حیات پروژه رخ می‌دهد و زمانیکه باید هدفِ در نظر گرفتن کلیه نیازهای ذی‌نفعان و برآورده کردن آنها، تا حد امکان، مورد نظر باشد.
10- حمایت از کاربر
حمایت از کاربر، باید دست‌ کم، شامل یک راهنمای کاربر باشد که شاید از طریق راهنمای برخط پیاده‌سازی شده و ممکن است شامل یک راهنمای نصب و یادداشت‌های نشر باشد، و بسته به میزان پیچیدگی محصول، ممکن است ابزار آموزشی نیز مورد نیاز باشد و بالاخره یک صورت از مواد همراه (BoM) با هر نوع بسته‌بندی محصول(در صورت وجود بسته‌بندی متنوع محصول).

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

1)     فرم تشریح موجودیتهای خارجی :

 

 

همانطور که در بالا مشاهده می کنید در فرم تشریح موجودیتهای خارجی ما تمامی موجودیتهای خود را تعریف می کنیم .

2)     فرم تشریح خطوط جریان داده :

 

 

فرم تشریح خطوط جریان شامل پنج ستون است که توضیح آن به شرح زیر است :

·        از : مبدا خطوط جریان می باشد . اگر مبدا خود سیستم باشد از " - " استفاده می کنیم .

·        به : مقصد خطوط جریان می باشد . اگر مقصد خود سیستم باشد از " - " استفاده می کنیم .

·        نام خط جریان :کلمه یا کلماتی است که بر روی خط جریان نوشته می شود که هدف خط جریان را در دیاگرام متن تشریح می کند .

·        شرح  خط جریان : شرح کامل خط جریان در این ستون نوشته می شود .

·        مرجع : مرجع در واقع شماره فرمی است که در سیستم دستی از آن استفاده می شود . ما در ابتدای تجزیه و تحلیل خود باید تمامی فرمهایی که در سیستم دستی مورد استفاده قرار می گیرد را جمع آوری کرده و آنها را شماره گذاری کنیم

در متد SSADM   پس از ترسیم دیاگرام متن باید دیاگرام گردش مستندات ترسیم شود .

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

 

نمونه دیگر از دیاگرام گردش مستندات مربوط به یک سیستم ورود و خروج

XP یک پروژه نرم افزاری را در چهار وجه ، ارتباطات (Communication) ، سادگی (Simplicity) ، بازخورد ها (Feedback ) و شجاعت (Courage ) بهبود می بخشد: 1-برنامه نویس XP ابتدا با مشتری ارتباط بر قرار می کند، سپس برنامه سازی را دنبال می کند. 2- آنها طراحی خود را ساده و تمیز نگه می دارند. 3- با آزمایش نرم افزارهای خود ار روز اول بازخورد می گیرند. 4- سیستم را در اولین فرصت به مشتری تحویل می دهند و تغییرات را به محض پیشنهاد دادن انجام می دهند. بر پایه XP، برنامه نویسان قادر خواهند بود که شجاعانه به تغییرات نیازها و فنآوری پاسخ دهند.
XP شامل اجزا زیاد کوچکی است که در نگاه اول هر کدام معنی خاصی نمی دهد اما وقتی بایکدیگر ترکیب شدند یک تصویر کامل می سازند. این یک فاصله اساسی با توسعه سنتی نرم افزارها ایجاد می کند. در یک کلام XP متفاوت است.
مطلب بالا خلاصه است از ادعاهایی که طراحان XP در مورد روش خودشان مطرح کرده اند. در سلسله مطالبی، به مرور این روش خواهیم پرداخت.
اعضای تیم در پروژه
در روش اکس‌پی مشتری نرم‌افزار باید جزئی از تیم اجرایی پروژه باشد و برنامه‌نویس و مشتری باید با هم کار کنند و از مشکلات و نیازهای هم مطلع باشند. در اکس‌پی مشتری به کسی یا گروهی گفته می‌شود که نیازهای برنامه و اولویت‌های آن نیازها را خوب می‌داند. در این روش مشتری و برنامه‌نویسان باید در یک اتاق کار کنند (البته تبصره‌ای نیز در این قسمت وجود دارد که می‌گوید مشتری می‌تواند تا حداکثر پنجاه متر از برنامه‌نویسان دور باشد).
داستان‌های کاربران یا User Stories
برای این‌که بتوانیم برای پروژه‌ای برنامه‌ریزی کنیم، باید از نیازهای کاربران مطلع باشیم. البته نیازی نیست که همه چیز را از همان اول بدانیم و از جزئیات نیازهای کاربران اطلاعاتی کسب کنیم؛ زیرا آن جزئیات به احتمال زیاد در طول پروژه تغییر پیدا می‌کنند. در اکس‌پی باید در مورد هر نیاز کاربر یا Requirement مقداری با مشتری صحبت کنیم و از مشتری بخواهیم چند کلمه‌ای در مورد هر یک از نیازها روی فیش یا کاغذهای یادداشت چسب‌دار (Post-it) بنویسد‌.‌ همزمان برنامه‌نویس نیز می‌تواند برداشت خود را از آن موضوع روی کاغذی مشابه بنویسد و هر دو برگه را روی دیوار اتاق بچسبانند. این برگه‌ها می‌توانند باعث یادآوری اعضای تیم از نیازهای اولیه و همچنین سهولت در تخمین زمان و هزینه پروژه شوند.
دوره‌های زمانی کوتاه
پروژه اکس‌پی هر دوهفته یک ‌بار یک قسمت از نرم‌افزار که کارایی بالایی دارد و قسمتی از نیازهای اولیه مشتری بوده است را تحویل می‌دهد و از مشتری در مورد آن قسمت نظرخواهی می‌شود و اگر نیاز بود، نظر مشتری سریعاً اعمال می‌گردد. به این دوره دو هفته‌ای Iteration نیز می‌گویند. هر Iteration قسمتی از نرم‌افزار را با توجه به User Storiesها تولید می‌کند که چند نیاز کاربر را برآورده می‌سازد. وقتی یک Iteration شروع شد، دیگر مشتری حق عوض کردن نیازهایی که بر سر آن‌ها توافق کرده است را ندارد.
تست های قبول شده
جزئیات نیازهای کاربران که در ‌User Stories وجود دارد، در قالب Acceptance Tests) AT) که مشتری تعیین می‌کند برداشت می‌شود. این تست همزمان با Iteration می‌تواند انجام گردد و در قالب زبان‌های اسکریپتی نوشته می‌شود تا بتوان آن را چندین بار تکرار کرد. هدف اصلی ATها تست کردن برنامه و حصول اطمینان از این است که آن قسمت از برنامه نوشته می‌شود که صددرصد نیاز مشتری را برآورده می‌سازد.
این تست‌ها هر وقت که قسمت جدیدی به برنامه اضافه می‌شود و برنامه کامپایل می‌گردد، دوباره اجرا می‌شوند و اگر اشکالی داشته باشند، پیغام خطا می‌دهند. در نتیجه وقتی سیستم به اتمام رسید، می‌توان مطمئن بود که سیستم بدون خطا است.
به علا‌وه، در اکس‌پی تمامی کدها به روش Test-Driven Development تولید می‌شوند. یعنی قبل از نوشتن هر قطعه کد، باید تست آن تولید شود و کاری کرد که کد در پاس کردن Unit Test ناتوان باشد. بدین‌معنی که اول یک قطعه کد مثلاً برای افزودن دانشجوی جدید به فهرست دانشجویان می‌نویسیم، ولی چون در آن کد قطعه‌ای از کد کلاسی که insert را انجام می‌دهد وجود ندارد، برنامه اشکال می‌گیرد. حال کار گروه اکس‌پی این است که برنامه را طوری درست کنند که این تست پاس شود و به قدری روی برنامه کار کنند تا برنامه دلخواه به دست آید.
برنامه نویسی دوتایی
معمولاً در اکس‌پی برنامه‌نویسان در گروه‌های دوتایی قرار می‌گیرند و وظیفه تکمیل قسمتی از برنامه را به عهده می‌گیرند. هر دو برنامه‌نویس در مورد هر کدام از نیازهای کاربران با هم بحث می‌کنند و قدم به قدم کلاس‌های برنامه را آماده می‌کنند. بدین ترتیب که در ابتدا کلاسی را به صورت خیلی ابتدایی و بدون هیچ طراحی اولیه به وجود میآورند و این کلاس را امتحان می کنند و در صورتی که این کلاس فاقد هر گونه اشکال باشد، کد اصلی برنامه را بر اساس این امتحان کلاس می‌نویسند. وقتی یکی از برنامه‌نویسان مشغول نوشتن قسمتی از برنامه است، برنامه‌نویس دیگر وظیفه کنترل صحت این کدها را عهده‌دار است و در صورت مشاهده هر گونه اشکال، نویسنده کد را مطلع می کند.
تیم همه کاره
در اکس‌پی همه اعضای تیم همه کار می‌کنند. همه روی GUI، پایگاه اطلاعات و ... کار می کنند. این بدین منظور نیست که اعضای تیم نمی‌توانند در کار مشخصی حرفه‌ای باشند، بلکه همکاری در تمامی بخش‌های پروژه باعث خواهد شد که تجربه جدیدی کسب کنند. این تیم حق دارد کدهایی که دیگران نوشته‌اند را بارها چک کند، اشکالات آن را مشخص نماید و اگر اصلاحی دارد، آن را متذکر شود.
محیط کاری باز
تیم باید در مکانی باز کار کند. در اتاق پروژه باید میزهایی فراهم شوند که روی آن چند کامپیوتر قرار دارد. در جلوی هر کامپیوتر هم باید دو صندلی برای اعضای Pair تعبیه شود. دیوارهای اتاق باید از نقشه‌ها و طرح‌های نرم‌افزاری به همراه UML مملو باشد. صدای اتاقی که در آن کار انجام می‌شود، معمولاً پر از زمزمه‌های اعضای تیم است. شاید بگویید که در محیطی پر زمزمه که نمی‌شود کار کرد. در جواب این سؤال باید گفت طبق تحقیقاتی که در دانشگاه میشیگان انجام شده است، راندمان کار در محیط‌های کاری‌ای که در آن زمزمه باشد و سکوت محض نباشد، به دو برابر حالت عادی می‌رسد.
طراحی ساده نرم‌افزار
در اکس‌پی تیم سعی می کند طراحی نرم‌افزار را تا حد ممکن ساده انجام دهد. اعضای تیم تمام انرژی خود را فقط روی نیازهای فعلی کاربران می‌گذارند و نگران نیازهای جدیدی که ممکن است در آینده مطرح شوند، نیستند. در ابتدای کار تمرکز برنامه‌نویسان تیم به انتخاب پایگاه اطلاعاتی، انتخاب معماری نرم‌افزار و ... نیست و تمام سعی تیم این است که قسمتی از نرم‌افزار را به ساده ترین راه ممکن تحویل مشتری دهد و وقتی واقعاً به تغییرات نیاز پیدا شد، می‌توانند تغییرات لازم را اعمال نمایند.
در اکس‌پی اعضای گروه می‌توانند روند تکمیلی تولید نرم‌افزار را مشاهده کنند و در جریان کار قرار گیرند. اکس‌پی روش مناسبی برای پروژه‌های کوچک است که اعضای تیم از دو تا دوازده برنامه‌نویس تشکیل شده است؛ هرچند اصولاً اکس‌پی هیچ رویه خاص و مراحل پیوسته‌ای را مشخص نکرده است. می‌توان گفت که اکس‌پی چهار مرحله اصلی دارد:
●‌‌مرحله زمانبندی پروژه
‌‌●‌‌طراحی ابتدایی
‌‌●‌‌نوشتن کدهای برنامه
‌‌●‌‌امتحان کدهای نوشته شده
طبق تحقیقات انجام شده مشخص شده است که اکس‌پی تنها در پروژه‌های کوچک نرم‌افزاری می‌تواند مفید باشد و در پروژه‌های بزرگ، اصلاً موفق نخواهد بود. شاید به این دلیل که در این روش مستندات چندانی برای نرم‌افزار وجود ندارد و چند نفر بیشتر نمی‌توانند در مورد قسمتی از نرم‌افزار اطلاعاتی داشته باشند. همچنین نرم‌افزار تولید شده با این روش هیچ‌گونه طراحی سازمان یافته‌ای ندارد و این امر می‌تواند برای مراحل پس از نصب، یعنی تعمیرات و نگهداری سیستم، باعث بروز مشکلاتی گردد.
از جمله مزایای اکس‌پی این است که از آن جایی که یک برنامه‌نویس به صورت مستقیم کدهای برنامه را چک می‌کند، کیفیت نرم‌افزارهای تولیدی بالاتر می‌رود. همچنین از آن جایی که دو برنامه‌نویس با هم کار می‌کنند، آموزش کمتری نیاز است و در نتیجه هزینه تولید نرم‌افزار پایین میآید، اما این روش مشکلات خاصی نیز دارد. مثلاً تصور کنید اگر در یک گروه یک برنامه‌نویس تمایلی برای کار با دیگر برنامه‌نویسان نداشته باشد، چه اتفاقی خواهد افتاد؟!
متخصصان نرم‌افزار پس از تحقیقات زیاد روی این روش به این نتیجه رسیده‌اند که وقتی برنامه‌نویسی در کدهای برنامه به دنبال اشکال می‌گردد، حداکثر می‌تواند پانزده درصد از اشکالات برنامه را پیدا کند، ولی در روش‌هایی مانند اکس‌پی که دو برنامه‌نویس با هم کار می‌کنند و یکی از این برنامه‌نویسان کدها را چک می‌کند، تا چهل درصد از اشکالات ساختاری برنامه مشخص می‌شود.

اولین دیاگرام SSADM دیاگرام متن می باشد . این دیاگرام کلیات سیستم را منعکس می کند و از بیان جزئیات در این دیاگرام جداً خودداری می کنیم .

در دیاگرام متن ما سیستم را درون مربع در وسط فرم قرار می دهیم . هر فرد ، سازمان و یا ارگانی که به نحوی با سیستم در تعامل است و ما قصد داریم تعامل آن را میکانیزه کنیم را به عنوان موجودیت خارجی در نظر گرفته و درون بیضی دور سیستم قرار می دهیم . در SSADM ما می توانیم حاکثر 12 موجودیت خارجی داشته باشیم . اگر تعداد موجودیت های خارجی ما بیشتر از 12 موجودیت باشد ، سیستم را به چند بخش تقسیم کرده و برای هر بخش یک دیاگرام متن ترسیم می کنیم . به هر موجودیت یک کد نسبت می دهیم که با حروف M1,M2,M3,… مشخص می کنیم . اگر چند موجودیت تعامل یکسانی با سیستم دارند می توان آنها را با هم ترکیب کرد و تحت عنوان یک موجودیت تعامل آنها را با سیستم مشخص نمود . می توان فقط برای گزارشگیری موجودیتی که درون سیستم قرار دارد را به عنوان موجودیت خارجی در نظر گرفت . تعامل میان موجودیت های خارجی و سیستم را از طریق خطوط جریان داده ( Data Flow ) به تصویر می کشیم . این خطوط می بایست حتماً جهت دار باشند و مستقیم یا شکسته ترسیم شوند . بر روی خطوط جریان داده تعامل موجودیت خارجی و سیستم نوشته می شود . نکته اینکه از نوشتن فعل بر خط داده باید اجتناب کرد ، زیرا جهت خط نشان دهنده فعل است . در دیاگرام متن هیچ گاه تعامل میان موجودیت های خارجی را ترسیم نمی کنیم . در مواقع خاص اگر نیاز به ترسیم رابطه میان موجودیت های خارجی باشد این کار را با نقطه چین انجام می دهیم .

در انتهای دیاگرام متن نموداری تحت عنوان چارت عملیاتی ترسیم می شود که عملکرد بخشهای داخلی سیستم را به تصویر می کشد . برای شکست پروژه در SSADM قائم به فرد نیستیم بلکه قائم به عملیات هستیم .

در زیر دیاگرام متن سیستم ارزشیابی اساتید را برای نمونه ترسیم می کنیم .

 

 

 

 

 

 

 

 

 

 

 

 

 

فرم دیاگرام متن سیستم ارزشیابی اساتید

فرم دیاگرام متن سیستم ورود و خروج پاسارگاد(یک نمونه دیاگرام متن دیگر)

هدف از طرح مسئله در چرخه حیات سیستم ، تعیین دلایلی است که موجب تقاضا برای یک سیستم اطلاعاتی جدید شده است .

در فرم تقاضای سیستم میکانیزه مسئله و تقاضای تائید پروژه تولید سیستم کامپیوتری درج شده است .

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

متقاضی : شخصی حقیقی یا حقوقی که در خواست سیستم میکانیزه کرده .

واحد مربوطه : اگر پروژه بخشی از یک ارگان باشد واحد مربوطه زیر بخش آن سیستم است .

نوع سیستم :

سیستم جدید : سیستم دستی کار می کرده و ما می خواهیم سیستم را میکانیزه کنیم .

ترمیم سیستم : سیستم میکانیزه وجود دارد ، اما بخشهایی از آن صحیح کار نمی کند .

توسعه سیستم :  سیستم میکانیزه وجود دارد ، سیستم دارای هیچ گونه اشکالی نیست ، اما می خواهیم بخشهایی به آن اضافه کنیم .

شرح مسئله : در شرح مسئله سعی در بیان مشکلات و نیازمندی ها می باشد .

تقاضا : درخواست برای ایجاد سیستم میکانیزه با توجه به مشکلات و نیازهای سیستم موجود .

تصمیم هیئت مدیره : تصمیم هیئت مدیره در مورد تقاضای سیستم میکانیزه .

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

دوستان در تحلیل سیستم به روش SSADM ابتدا ما باید فرمهای مربوط به آن سیستمی که می خواهیم تحلیل کنیم جمع آوری کنیم .

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

سناریو بانک اطلاعاتی ارزشیابی اساتید

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

ü      دسترسی سهل و آسان به این اطلاعات غیر ممکن است.

ü      جهت پیداکردن استاد مورد نظر زمان زیادی نیاز می باشد.

ü      نگهداری این پاسخ برگها دشوار می باشد.

ü      قابل دسترسی همگان نیست.

ü      همراه با کاغذ بازی فراوانی می باشد.

ü      و غیره

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

 فرم سناریو سیستم ورود و خروج پاسارگاد ( یک مثال دیگر )

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

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

در فرایند مهندسی معکوس ، Rose نسبت به خواندن بسته ، Component ها ، کلاسها رابطه ها ، صفات و عملیات از کد اقدام خواهد کرد . هنگامی که این مدل در یک مدل Rose قرار می گیرد ، می توانید هر تغییر لازمی را ایجاد کرده سپس کد را از طریق امکانات مهندسی مستقیم Rose مجدداً تولید کنید .

گزینه هایی که در اختیار شما قرار خواهند گرفت به نسخه مورد استفاده شما بستگی خواهد داشت .

• Rose Modeler : شامل هیچ گونه عملیات مهندسی معکوس نخواهد بود .
• Rose Professional : شامل قابلیت های مهندسی معکوس به یک زبان است .
• Rose Enterprise : شامل مهندسی معکوس C++ ،  Visual C++ ، Visual Basic و جاوا خواهد بود .همانطور مهندسی معکوس شمای Oracle 8 را نیز شامل خواهد بود .
• Add_ins : متعلق به Rose قابلیتهای مهندسی معکوس در زبانهای دیگر نظیر PowerBuilder یا Forte را به شما خواهند داد .

عناصر مدل ایجاد شده در طول مهندسی معکوس :

در طول مهندسی معکوس ، Rose به جمع آوری اطلاعاتی درباره موارد زیر خواهد پرداخت .

• کلاسها
• صفات
• روابط
• عملیات
• بسته ها
• component ها

با استفاده از این اطلاعات ، Rose اقدام به ایجاد یا ارتقاء یک مدل Object خواهد کرد .

دوستان بخش اول مستندات Use Case جهت استفاده شما آماده شده است . با توجه به این که این متن توسط مدیر ترجمه شده ، به دلیل اشکالات احتمالی در جمله بندی از شما عزیزان پوزش می طلبیم .

هر یک از مستندات Use Case برای نمایش ضمیمه ها بکار می روند . در این بخش شرح کاملی از هر یک از بخشهای الگوی Use case آماده شده است .

  تعیین هویت Use Case

        ·        شماره Use Case  : هر یک از Use Case ها باید توسط یک عدد   صحیح بی همتا مشخص شود . برای شماره گذاری متناوب Use Case هایی که در یک گروه قرار دارند از شکل X:Y استفاده می شود .

·        نام Use Case  : توضیح مختصری برای نامی که برای Use Case انتخاب شده است . این نام ها وظیفه های مورد نیاز که برای انجام نیازهای سیستم که شامل یک کار یا اسمی که شبیه مثالهای زیر است را منعکس می کند .

1)     نمایش اطلاعات قسمت عددی

2)     نشانه گذاری دستی منابع و فرامتنها و ایجاد لینک به مقصد

3)     مکان یک دستورالعمل برای CD با بروز شدن نسخه نرم افزار

·        تاریخچه Use Case  :

1)     چه کسی Use Case را ایجاد کرده است .

2)     در جه تاریخی Use Case ایجاد شده است .

3)     آخرین بار توسط چه کسی به روز شده است .

4)     تاریخ آخرین به روز رسانی چه موقع بوده است

برای کسی که اولین بار با RUP  (که دارای 4 فاز، 9 دیسیپلین، 31 نقش، 103 دست‌آورد، 136 فعالیت، بعلاوه رهنمودها، چک‌ لیست‌ها و راهنمای ابزار می‌باشد) مواجه می‌شود این سؤال پیش می‌آید که ”چطور می‌توان از میان این همه موارد تعیین کنیم که کدام یک برای پروژه ما مورد نیاز است؟“، ”آیا به این یکی نیاز دارم؟“، ”آیا RUP فقط برای پروژه‌های بزرگ است؟“ و پاسخ نیز اغلب به این صورت است : ”خب بستگی دارد به ... “ در این مطلب یک لیست از ده مورد اساسی و ضروری RUP که می‌تواند نقطة شروعی برای چگونگی بکارگیری RUP در هر پروژه باشد معرفی می‌شود. البته ضروری است که چارچوب کلی RUP که یک فرآیند تکراری و تکاملی  است  لحاظ شود.
این ده مورد عبارتند از :
ادامه مطلب ...