واژه‌های کلیدی: RUP® ، EUP® ، فرآیند، روشگان

کلیات
این مقاله مروری است بر روشگانEUP® كه اولین بار توسط اسکات امبلر در سال 1999 عرضه گردید و بعدها توسط تیمی‌ متشکل از جان نالبون و مایکل ویزدوس، در شرکت Ranin International Inc. مورد پشتیبانی و توسعه قرار گرفت. در حقیقت EUP® توسعه یافته دانش‌های نهفته در محصول ®RUP شرکت Rational IBM می‌باشد. هم ®RUP و هم EUP® یک نمونه از UP (فرایند یکنواخت) هستند و UP خود روش یکنواختی است که در روشگان USDP به آن اشاره شده است و آن فرایند سیستماتیکی است که نقش انسان‌ها را در چگونگی انجام عملیات، فعالیت‌هایی که انجام می‌دهند، محصولاتی که حین انجام عملیات به‌دست می‌آورند تعریف می‌کند و در نهایت به چگونگی پشتیبانی از این محصولات در گستره شبکه عملیاتی آن اشاره دارد. در طی سال‌های گذشته تمرکز اصلی شرکت Rational IBM درگیری در ®RUP بوده است. از آن جایی که ®RUP یک روشگان ایجاد و توسعه سیستم‌های نرم‌افزاری است، EUP® ، توسعه یافته آن برای پوشش بی‌عیب چرخه حیات فناوری اطلاعات می‌باشد. EUP® توسعه یافته ®RUP ، شامل عملیات و پشتیبانی‌های لازم برای یک سیستم پس از تولید و عملیاتی شدن و حتی در بعضی مواقع از رده خارج شدن می‌باشد. EUP® همچنین با فرآیندهای تعاملی بین سیستم‌ها از قبیل مدیریت سبد اقلام اطلاعاتی، معماری سازمانی و راهبردهای استفاده مجدد نیز سروکار دارد. اگرچه ®RUP فرایند تولید نرم‌افزار را به‌خوبی تشریح نموده است ولی فقط برای شروع است و شما به EUP® برای یک چرخه حیات بی‌نقص فناوری اطلاعات و مکانیزمی‌ برای نظارت و ارزیابی پروژه‌های ®RUP نیاز خواهید داشت. شکل زیر یک چرخه حیات کامل سیستم را به نمایش می‌گذارد:

در حقیقت انواع فرایندها به چهار دسته تقسیم می‌شوند:
1- چرخه حیات ایجاد و توسعه سیستم: فعالیت‌های مورد نیازی را که منجر به ایجاد و توسعه سیستم شده و حاصل آن محصول می‌باشد دربرمی‌گیرد. ®RUP از این نوع است.
2- چرخه حیات سیستم: توسعه یافته نوع یک است که در آن فعالیت‌های مورد نیاز چگونگی عملیاتی شدن و پشتیبانی سیستم نیز اضافه شده است. استاندارد ISO 12207 از جمله این دسته از فرآیندها می‌باشد.
3- چرخه حیات فناوری اطلاعات: این چرخه حیات فعالیت‌های دپارتمان فناوری اطلاعات و ارتباطات را دربرمی‌گیرد و برای مدیریت مناسب سبد ابزار سازمان اصولی را رعایت می‌نماید. این نوع نگرش با نگرش سنتی حاکم بر انجام فعالیت‌ها کاملا متفاوت می‌باشد. EUP® از جمله این نوع فرآیندهاست
4- چرخه حیات سازمان / کسب و کار: این نوع چرخه حیات کلیه فعالیت‌های داخل سازمان شامل هم فناوری اطلاعات و هم جنبه‌های کسب و کار را دربرمی‌گیرد. اگر بخواهید چرخه حیات فناوری اطلاعات شما به‌طور موثر انجام شود بایستی متناسب با چرخه حیات سازمان / کسب و کار شما باشد.
در یک نمایش نمادین می‌توان گفت که چهار حالت فوق به‌صورت زیر به هم وابسته هستند:

تاریخچه EUP® :
برای درک بیشتر تاریخچه EUP® بایستی هم به تاریخچه UP و هم ®RUP به دقت نگاه کنیم. ®RUP که توسط بخش Rational شرکت IBM اداره می‌شود به‌طور رسمی ‌توسط شرکت Rational عرضه گردیده است. Rational شناخته شده ترین و بهترین شرکت توسعه‌دهنده ابزار‌های مهندسی نرم‌افزار است. محصولاتی از قبیل Requisit Pro, Rational Rose/XDE, Rational ClearQuest از جمله این محصولات هستند. زبان مدل‌سازی UML که توسط شرکت OMG عرضه گردیده نیز در راستای مدل‌سازی سیستم‌های مبتنی بر شیء تلاش‌های عمده‌ای نموده است به‌طوری که کسانی که با مفاهیم ®RUP و UML آشنا هستند به سختی می‌توانند این دو را از هم متمایز بدانند. در هر صورت اگرچه محصولات فوق در توسعه مفاهیم UP نقش اساسی به عهده داشته‌اند ولیکن سیر تکاملی UP را می‌توان به‌طور کاملا مجزا از این دو مقوله مورد بررسی قرار داد. برای درک بیشتر UP به خط تاریخی و سیر تکاملی آن نظر می‌اندازیم:
1988: Objectory روایت 1.5 در شرکت AB توسط جاکوبسون عرضه شد. این محصول هسته اصلی ®RUP و EUP® را تشکیل داد.
1995: Objectory روایت 3.8 منتشر شد. این اولین نسخه برخط بوده است.
1995: شرکت Rational محصول Objectory را خرید
1996: ROP(Rational Objectory Process) روایت 4.0 توسعه داده شد. در این روایت شرکت Rational با طراحی معماران داخلی خود و اضافه نمودن مفهوم توسعه تدریجی به محصول قبلی، ROP را عرضه نمود.
جون 1998: ®RUP روایت 0/5 انتشار یافت. این محصول که تغییر نام یافته محصول ROP بود با محصولات دیگری که شرکت Rational خریداری نموده بود یکپارچه شد. این عمل به رهبری «فیلیپ کروچتن» انجام شد. در این روایت چگونگی کاربری علائم UML برای سیستم‌های مبتنی بر شیء، عنوان گردید.
فوریه 1999: USDP توسط «جاکوبسون»، «بوچ» و «رامبو» منتشر شد. این کتاب به‌طور جزئی چارچوب فرایند یکنواخت را شرح داده است.  
جون 1999: ®RUP روایت 5/.5 منتشر شد. اساسی ترین تمرکز این روایت توسعه بر مبنای «وب» و زمان واقعی می‌باشد.
اکتبر 1999: در یک چرخه حیات توسعه یافته برای ®RUP ، امبلر، فاز تولید و قاعده مدیریت زیر ساخت را به فازها و قاعده‌های ®RUP اضافه نمود.
فوریه 2000: ®RUP نسخه 2000 منتشر شد تفاوت‌های اصلی این روایت با روایت قبلی اضافه شدن تکنیک‌های مهندسی کسب و کار (جاکوبسون، اریکسون و جاکوبسون 1994) به قاعده مدل‌سازی کسب و کار و رویکرد عمیق تر به نیازمندی‌ها بود.
2000-2002: سری کتاب‌های UP (امبلر و کنستانتین 2000-2002) منتشر شد که مبنای توسعه چرخه حیات ®RUP تحت عنوان EUP® گردید. این کتاب‌ها بارها تجدید چاپ شد و در وبگاه www.sdmagazine.com نسبت به توصیف عناوینی که توسط®RUP بیان نشده بود اقدام شد.برخی ازعناوین این مطالب عبارتنداز: بهبودآزمون وچابکی که بایستی به®RUP اضافه شود.
مارس 2002: مدل سازی چابک (امبلر 2002) نشر یافت که نشانگر این مسئله بود که می‌توان با یک رویکرد چابک به مدل سازی در پروژه ®RUP نگریست.
آگوست 2002: IBM ، شرکت PriceWaterhouseCooper(PWC) را که توسعه‌دهنده روشگان Summit بود خریداری نمود. مطالب مربوط به این روشگان بعدها با ®RUP تطبیق داده شد
دسامبر 2002: IBM ، کمپانی Rational را خرید.
می‌2003: ®RUP2003 منتشر شد. برخی از مطالب عنوان شده در سری‌های UP و خصوصا اصل آزمون توسعه یافته و برخی مفاهیم چابکی توسط این نسخه از ®RUP ، پوشش داده شد.
بهار 2003: سایت EUP® (www.enterpriseunifiedprocess.com( و فهرست پست الکترونیکی EUP® منتشر شد. کلیه مطالب مربوط به EUP® به‌وسیله شرکت بین المللی «Ranin » در این وبگاه منتشر می‌شود.
ژانویه 2004: EUP® روایت 2004 منتشر شد. موارد اضافه شده عبارتند از فاز بازنشستگی و توسعه اصل مدیریت سازمان در قالب هفت اصل جزیی‌تر.
بهار 2005: ®RUP روایت 2005 منتشر شد. اساسی‌ترین تغییر آن نسبت به روایت قبلی تطبیق فرایندهای روشگانSummit شرکت  PWC و بخشی ازپشتیبانی محصول مرتبط بافعالیت‌ها بود.
مقدمه
گروه EUP® مستقل از IBMRational است و فقط برای آن‌دسته از فعالیت‌هایی که ®RUP برایشان راه حل ندارد و یا ضعیف است، راه حل ارائه داده است. آن‌ها معتقدند EUP® یک نسخه  توسعه یافته ®RUP است بدین منظور با اضافه نمودن 2 فاز و 7 قاعده نسبت به این مهم اقدام نموده‌اند و معتقدند ®RUP با این تغییرات به یک روشگان کامل منطبق بر دنیای واقعی پروژه‌های فناوری اطلاعات بدل می‌شود. بدین منظور گروه EUP® یک کتاب با همین نام ارائه نموده است.
روح حاکم بر مطالب کتاب مربوط به پروژه‌های جامع فناوری اطلاعات است و نه یک سیستم خاص که این نوع پروژه‌ها عمدتا تحت مدیریت و مسئولیت دپارتمان فناوری اطلاعات و ارتباطات (ICT) قرار دارد. درسرتاسرکتاب سعی شده است تا با ارائه تصاویر روشن از آنچه که باید انجام شود تصویر روشنی از چه باید کرد ارائه گردد. بنا بر دلایل زیر کتاب مذکور، منبع مناسبی به شمار  می‌آید:

• کاربردی است
• پوشاننده پیامد‌های حیاتی است
• سازگار با ®RUP است
• شامل موارد کاربردی است
• دارای بخشی است که در آن آنچه که خواننده کسب می‌کند را تشریح می‌نماید
• شامل منابع پیشنهادی است

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

شکل 1: چرخه حیات®RUP

و اصول حاکم براین فرسنگ شمارها،شامل9 اصل هستند که اهداف آن‌ها در جدول زیر بیان شده است:

خلاصه این‌که ®RUP محصولی است که توسط IBM Rational ارائه شده است. فرایند ایجاد و توسعه سیستم درگیر هم شیء گرایی و هم مولفه محوری است. شامل چهار فاز آغازین، تشریح، ساخت و انتقال است که به ترتیب با حفظ 6 قاعده اصلی شامل مدل سازی کسب و کار، نیازمندی‌ها، تحلیل و طراحی، پیاده‌سازی، آزمون و استقرار به همراه 3 قاعده پشتیبانی کننده شامل: مدیریت پیکر بندی و تغییر، مدیریت پروژه و پشتیبانی، اجرا می‌شود. ®RUP نه تنها فرایند توسعه سیستم بلکه یک چارچوب فرایند توسعه سیستم که می‌تواند با توجه به نیازهای یک سازمان بومی‌شود نیز هست.

مقدمه‌ای بر EUP®

• EUP® توسعه داده شده ®RUP با دو فاز«تولید» و«از رده خارج شدن» می‌باشد.
• EUP® قواعد عملیات و پشتیبانی را به قواعد موجود در ®RUP اضافه نموده است.
• EUP® ، 7 قاعده به قواعد مدیریت بنگاه اضافه نموده است. این قواعد شامل: «مدل سازی کسب و کار بنگاه»، «مدیریت سبد اقلام فناوری اطلاعات »، «معماری بنگاه»، «راهبرداستفاده مجدد»، «مدیریت افراد»، «اداره بنگاه»، و «بهبود فرایند نرم‌افزار» در تعامل بین سیستمی‌ بوده که در جریان چرخه حیات فناوری اطلاعات سازمان مورد استفاده قرار می‌گیرد.
• اول بر استفاده از ®RUP تسلط یابید و سپس به تدریج در یک برنامه اولویت‌دار مبتنی بر نیاز نسبت به تطبیق فرایند‌های EUP® در سازمان اقدام نمایید

( به تصویر زیر دقت نمایید: (

که در آن فازها و فرسنگ شمارهای EUP® به‌صورت زیر بیان می‌شود:

شکل 2: چرخه حیات EUP®

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

همه این نیازمندی‌هامی‌تواند با پایه قراردادن ®RUP پاسخ داده شوند. این توانمندی با در نظر گرفتن مطالبی که در EUP® گنجانده شده امکان پذیر است.

از چرخه ایجاد و توسعه تا چرخه حیات سیستم
 جزئیات چرخه حیات ®RUP (شکل 1) را می‌توان در کتاب‌های مربوط به ®RUP مطالعه نمود.®RUP به‌طور واضح نسبت به ایجاد و توسعه سیستم ها راه حل‌های واضح و روشنی دارد. بررسی ها نشان می‌دهد ( بر اساس گزارش موسسه گارتنر سال 2000) که در مقیاس بزرگ بالغ بر 75% هزینه و تلاش پروژه‌ها، پس از استقرار آن‌ها رخ می‌دهد. این شامل فعالیت‌هایی نظیر پشتیبانی از محصول، استوار نمودن نگهداشت، و  از رده خارج شدن‌های احتمالی است. تجربه نشان داده است مردم به فرایندهای روش مندی جهت انجام عملیات فوق نیاز دارند. هر سازمان که بخواهد در پروژه‌های فناوری اطلاعات خود موفق باشد، نیاز دارد تا به فعالیت‌های فراسوی چرخه حیات پیاده‌سازی نرم‌افزار توجه ویژه‌ای داشته باشد به‌طوری‌که این فعالیت‌ها را بخشی از فرایند چرخه حیات بداند.
EUP® توسعه یافته چرخه حیات ®RUP شامل قواعد پشتیبانی و عملیات همراه دو فاز جدید تولید و از رده خارج شدن می‌باشد. در شکل 2 فازها و قواعد®RUP و مفاهیم توسعه یافته توسط EUP® ارائه گردیده است.
فاز تولید

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

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

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

تمرکز این فاز بر برداشتن محصول از تولید می‌باشد. سیستم‌های نرم‌افزاری برای همیشه قابلیت اجرا ندارند. سرانجام از رده خارج شده یا تحت فشار یک سیستم دیگر برداشته خواهند شد. یک سیستم، بنا بر دو دلیل اصلی زیر برداشته می‌شود:
1- سیستم در هر حال مورد نیاز نباشد
2- سیستم جدیدی جایگزین شده باشد
بعضی مواقع یک سیستم تحت الزام سیاست‌های دولت یا مجموعه بالاسری ، عملیاتی می‌شود. به همین خاطر به محض این‌که این سیاست عوض شود، یا فشار مدیریت ارشد کاهش یابد، سیستم مذکور نیز برداشته خواهد شد. در بعضی مواقع ما سیستم‌های توسعه یافته در درون سازمان خود را با نرم‌افزارهای آماده شده موجود در بازار جایگزین می‌کنیم. بعضی مواقع نیاز است تا یک سیستم قدیمی‌بنا بر دلایل رقابتی یا افزایش درآمد توسط یک سیستم موجود در بازار، جایگزین شود. دلایل از رده خارج شدن سیستم ها ، هم به دلیل کمرنگ شدن، ازتولید برداشته می‌شود و هم به دلیل مطرح شدن یک پروژه جدید برای رسیدن به نیازهای جدید. واقعیت همین است. کمرنگ شدن یک سیستم باعث برداشتن آن از خط تولید می‌شود – چنانچه طی سال 2000 بحران (Y2K) را به خاطر داریم که تعداد زیادی از سیستم‌ها از رده خارج شدند – واین روند ممکن است دوباره اتفاق بیافتد.
از رده خارج شدن سیستم معمولا پیچیده و با ریسک بالایی مواجه است. سیستم موجود می‌تواند هزاران و یا حتی میلیون‌ها کاربر داشته باشد ممکن است تعدادی از آن‌ها را نشناسید یا نتوانید با آن‌ها ارتباط برقرار کنید. لذا جهت کنار گذاشتن یک سیستم، شما به بررسی بسیار عمیقی نیاز دارید و به تخصص‌های خاصی برای تحلیل تبعات ناشی ازکنارگذاشتن سیستم برای کاهش ریسک، نیازمند هستید.
در طی فاز از رده خارج شدن، به ذینفعان مبنی بر برداشتن سیستم (و آماده بودن سیستم جایگزین) (اختیاری است) اطلاع داده خواهد شد و کلیه بقایای سیستم نیز برداشته خواهد شد. از رده خارج شدگی برای نشرهایی از سیستم که به‌صورت گسترده‌ای صورت پذیرفته است ممکن است به تلاش پیچیده‌ای نیاز داشته باشد و شناسایی تاثیرات سیستم در گستره عملیاتی برای پیاده‌سازی سیستم جدید حیاتی است.

قاعده پشتیبانی و عملیات

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

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

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

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

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

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

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

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

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

• موفقیت در باز به کارگیری بسیار مشکل است.
• شما می‌توانید از محدوده وسیعی از دارائی‌های سازمان از قبیل: کدها، مولفه‌ها و قالب‌ها، استفاده مجدد کنید.
• شما این واقعیت را که چیزهایی برای باز به کارگیری در اختیارتان قرار دارد باید به مشارکت گذاشته و حتی بازاریابی کنید.

 این قاعده، ایجاد و توسعه را ترقی داده و استفاده مجدد از دارایی‌ها را در طول انجام پروژه‌ها امکان‌پذیر می‌سازد. همچنین در بهبود کیفیت نیز موثر است به این صورت که به شما اجازه می‌دهد از محصولاتی که در جریان کار تولید شده و مورد آزمون قرار گرفته اند، مجددا استفاده نمایید.
خلاصه این‌که محدوده وسیعی از دارائی‌های سازمان – از کدهای برنامه گرفته تا قالب‌ها و چارچوب‌ها - قابلیت باز به کارگیری را دارا می‌باشند. اما موفقیت در این امر نیازمند نگرش به فرا سوی محدوده یک پروژه است. قاعده باز به کارگیری راهبردی بیانگر توصیف چگونگی افزایش سطح استفاده مجدد می‌باشد که در پروژه‌های EUP® به‌وسیله رویکرد تعاملی بین سیستم ها امکان پذیر می‌گردد. برای موفقیت به طرح ریزی برای اعمال و پایش برنامه باز به کارگیری در سر تاسر سازمان، نیاز دارید. چندین راه برای استفاده مجدد از دارائی‌های قوی و محکم که بالقوه دارای این قابلیت هستند وجود دارد. این راه ها شامل: برداشت از دارائی‌های داخلی، بارگذاری دارائی‌های خریداری شده از خارج از سازمان و توسعه دارائی‌های از رده خارج شده می‌باشد. تلاش‌های باز به کارگیری شما بایستی پشتیبانی شود، استفاده مجدد از اشیاء شانس بیشتری به سازمان خواهد داد. همچنین شما توانایی دارید تا میزان موفقیت تلاش در راه استفاده مجدد را برای اطمینان از این‌که پشتیبانی مدیریت را برای تداوم این کار به همراه خود داشته باشید، اندازه‌گیری نمایید.
قاعده مدیریت افراد

• طرح‌ریزی برای نیروهای انسانی مورد نیاز مشارکت – و انعطاف پذیری – بین سازمان‌های فناوری اطلاعات و منابع انسانی.
• ایجاد تعادل بین نیروهای تمام وقت و پیمانکاران در پروژه‌های متفاوت بر اساس نیاز‌های خاص جاری.
• راهنمایی مشاغل وابسته به سازمان فناوری اطلاعات و منابع انسانی و همکاری‌های فردی بین هم در مواقع رخداد واقعه
• طرح‌ریزی برای موفقیت کارکنان در زمانی که سازمان فاقد رهبر است / یا سیستم‌هایی که در آینده قابل نگهداشت نیستند.

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

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

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

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

 این قاعده به نیازهای مدیریت، بهبود و پشتیبانی فرایندهای چندگانه‌ای که در طول سازمان شما استفاده می‌شود، اشاره دارد. به خاطر داشته باشید که یک فرایند پاسخ گوی همه چیز نیست.
خلاصه این‌که یک فرایند بهبود نرم‌افزار موفق، سعی و تلاش بین پروژه‌ای است که بایستی در سطح بنگاه مدیریت شود. قاعده بهبود فرایند نرم‌افزار تعریف کننده فعالیت‌های مورد نیاز برای تعیین و پشتیبانی فرایندهای نرم‌افزار بنگاه شماست که چگونگی تعیین نیازهای فرایندهای شما، چگونگی کسب مهارت در فرایند جدید یا بومی‌شده یک فرایند موجود و چگونگی استقرار و مدیریت یک فرایند جدید را توصیف می‌کند. فرایند بهبود نرم‌افزار یک فرایند تکراری است که مستلزم تطبیق بر مبنای بازخوردها و نتایج واقعی است.
EUP® و چارچوب زکمن
سوال پایه‌ای که مردم متناوبا در باره مدل‌سازی بنگاه و مدل‌سازی به مفهوم عام آن می‌پرسند این است که چگونه رویکردهایی نظیر مدل‌سازی کسب و کار بنگاه، مدل‌سازی معماری بنگاه و مدل‌سازی طراحی که برای تنها یک پروژه انجام می‌شود با یکدیگر مرتبط می‌شوند. چارچوب زکمن (ZIFA 2002 ) توصیف شده در سال 1980 توسط جان زکمن به بسیاری از سوالات فوق پاسخ داده است. چارچوب زکمن که در شکل زیر ارائه شده است مجموعه‌ای از توصیفات مورد نیاز را ارائه داده است. سطرهای چارچوب، نمایانگر دیدگاه‌های ذینفعان و ستون‌ها نمایشگر جنبه‌های مختلف معماری شما می‌باشد. به‌طور سنتی هر ستون، یا سلول‌های مختلفی از هر ستون دیدگاه‌ها و رویکردهای روشگانی از قبیل رویکرد داده‌گرا، رویکرد فرایندگرا و... را تداعی می‌کند. چارچوب زکمن نقاط قوت بسیار زیادی دارد. اول این‌که در پذیرش تجمیع داده‌ها در یک چارچوب استاندارد معماری بنگاه، بسیار موفق بوده است. ثانیا و مهم‌تر این‌که ابعادی را تعریف می‌کند که مدل‌های بنگاه شما بایستی احاطه کند تا توانایی شما را در مدیریت پروژه‌های فناوری اطلاعات امکان‌پذیر سازد. این نکته در EUP® هم نهفته است. با همه این تفاصیل چارچوب زکمن نقطه ضعف‌هایی هم دارد. اول این‌که رویکرد سنگینی از مستند سازی بر آن حاکم است (اگرچه با ابزارها این مسئله قدری حل شده است). 36 سلول وجود دارد که هرکدام از آن‌ها بایستی توسط یک یا چند مدل مورد پشتیبانی قرار گیرد، ثانیا رویکرد سنگینی در ایجاد و توسعه فرایندها دارد (این امر انرژی بسیار زیادی را طلب می‌کند). سوم این‌که به‌خوبی در بین توسعه دهندگان به‌طور مشترک مورد قبول واقع نمی‌شود و به نظر توسعه دهندگان خصوصا در بین تولید کنندگان نرم‌افزار از استقبال مناسبی برخوردار نشده است. چهارم این‌که در ارائه مدل از آنجایی‌که رویکرد از بالا به پایین برآن حاکم است بیشتر مردم فکر می‌کنند که شما باید از سطر یک شروع کنید سپس به سطر دو مدل بروید و نظیر آن در صورتی که در واقع شما توانایی شروع از هر سلول را دارا خواهید بود و سپس تکرارهای بعدی را می‌توانید از همان سلول آغاز کنید. پنجم این‌که طرفداری از نگرش سنتی گذشته (تکنیک‌های مبتنی بر داده) بر آن حاکم است.

تجربه گروه EUP® با توجه به تمرکز بر نقاط قوت و در نظر گرفتن نقاط ضعف توانایی پیاده‌سازی موفقیت آمیز چارچوب زکمن را در داخل EUP® نهفته است. در جدول زیر به چگونگی توسعه این رویکرد توسط EUP® اشاره شده است.

توسعه چارچوب زکمن برای EUP®

 

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

 

منابع
The Enterprise Unified Process: Extending the Rational Unified Process – Book
www.enterpriseunifiedprocess.com