فرایند یکپارچه

فرایند توسعه نرم‌افزار یکپارچه یا فرایند یکپارچه یک چارچوب محبوب تکراری و افزایشی فرایند توسعه نرم‌افزار است. شناخته شده‌ترین و به طور گسترده مستندترین پالایش (اصلاحیه) برای فرایند یکپارچه، فرایند توسعه بکپارچه منطقی Rational Unified Process (RUP) است. نمونه‌های دیگر OpenUP و فرایند یکپارچه چالاک چالاک فرایند یکپارچه هستند.
مشخصات یک پروژه معمولی، نمایشگر اندازه نسبی چهار فاز فرایند یکپارچه.
بررسی اجمالی
فرایند یکپارچه، تنها یک فرآیند نیست بلکه یک چارچوب قابل توسعه است که باید برای سازمان‌ها یا پروژه‌های خاص سفارشی شود. فرایند یکپارچه منطقی به طور مشابه یک چارچوب قابل تنظیم است. به عنوان یک نتیجه، اغلب غیرممکن است که بگوییم آیا یک پالایش از فرایند، مشتق شده از UP است یا از RUP، بنابراین این نام‌ها به جای یکدیگر استفاده می‌شوند.
نام فرایند یکپارچه در مقابل نام فرایند یکپارچه منطقی Rational Unified Process به طور کلی برای توصیف فرایند عام (ژنریک) که شامل عناصری است که در بیشتر پالایش‌ها رایج هستند، استفاده می‌شود. نام فرایند یکپارچه همچنین برای جلوگیری از مشکلات احتمالی از نقض قوانین علامت تجاری استفاده می‌شود، زیرا Rational Unified Process و RUP علائم تجاری آی بی‌ام هستند. اولین کتابی که این فرایند را توصیف می‌کند با عنوان فرایند توسعه نرم‌افزار یکپارچه (ISBN 0-201-57169-2) در سال ۱۹۹۹ توسط ایوار جاکوبسون، گردی بوش و جیمز رامباگ منتشر شده‌است. پس از آن نویسندگان مختلف وابسته به نرم‌افزار منطقی کتاب‌ها و مقالاتی با استفاده از نام واحد فرایند یکپارچه منتشر کردند، در حالی که نویسندگان وابسته به نرم‌افزار منطقی به نام فرایند یکپارچه منطقی (Rational Unified Process) علاقه دارند.
در سال ۲۰۱۲ چارچوب تحویل چالاک منظم Disciplined Agile Deliveryمنتشر شد، که یک چارچوب ترکیبی است که استراتژی‌های Unified Process, Scrum, XP, و روش‌های دیگر را اقتباس می‌کند و گسترش می‌دهد.
ویژگی‌های فرایند یکپارچه
تکراری و افزایشی
نمودار نشان می‌دهد که چگونه تاکید نسبی روی روندهای مختلف در طول دوره پروژه تغییر می‌کند
فرایند یکپارچه یک فرایند تکراری و افزایشی توسعه روند. فازهای تحلیل جزئیات، ساخت و ساز و انتقال به یک سری از تکرارهای زمانبندی شده تقسیم می‌شوند. (فاز آغازین نیز در یک پروژه بزرگ ممکن است به تکرارهایی تقسیم شود) هر تکرار منجر به یک افزایش است که این افزایش یک نسخه از سیستم است که شامل عملکرد بهبود یافته یا اضافه شده در مقایسه با نسخه قبلی است.
اگر چه بیشتر تکرارها شامل کار کردن در بسیاری از مراحل فرایند هستند (به عنوان مثال نیازمندی‌ها، طراحی، پیاده‌سازی و تست)، تلاش نسبی و تاکید در طی دوره پروژه تغییر خواهد کرد.
معماری-محور
فرایند یکپارچه اصرار دارد که معماری در قلب تلاش تیم پروژه برای شکل‌دادن به سیستم بنشیند. از آنجایی که هیچ مدلی به تنهایی برای پوشش تمام جنبه‌های یک سیستم کافی نیست، فرایند یکپارچه از چندین مدل معماری و نمایش پشتیبانی می‌کند.
یکی از مهم‌ترین موارد قابل تحویل در این فرایند، اساس معماری قابل اجرا است که در طول فاز تحلیل جزئیات ساخته می‌شود. این پیاده‌سازی جزئی از سیستم برای اعتبارسنجی معماری استفاده می‌شود و به عنوان یک پایه برای باقی مراحل توسعه عمل می‌کند.
متمرکز بر ریسک
فرایند یکپارچه به تمرکز تیم پروژه بر پرداختن به مهم‌ترین ریسک‌های اولیه در چرخه حیات پروژه نیاز دارد. نسخه قابل تحویل در هر تکرار به خصوص در فاز تحلیل جزئیات، باید به منظور اطمینان حاصل کردن از اینکه در ابتدا به بزرگترین ریسک‌ها پرداخته شود، انتخاب شود.
چرخه عمر پروژه (فازهای فرایند یکپارچه)
فرایند یکپارچه پروژه را به چهار مرحله تقسیم می‌کند:
آغاز به کار (آغازین)
تحلیل جزئیات (پیچیدگی) (نقطه عطف) (سنگ نشان)
ساخت و ساز (رهاسازی)
انتقال (انتشار تولید نهایی)
فاز آغازین
آغاز به کار کوچکترین فاز در پروژه است، و در حالت ایدئال بهتر است بسیار کوتاه باشد. اگر فاز آغازین طولانی است، این فاز ممکن است نشانه‌ای از مشخصات بیش از حد بالا باشد که در تضاد با روح فرایند یکپارچه است.
در زیر اهداف معمول فاز آغاز به کار مشخص شده‌اند.
ایجاد یک توجیه یا مورد کسب و کار برای پروژه
ایجاد قلمرو پروژه و شرایط مرزی
طرح کلی موارد کاربری و نیازمندهای کلیدی که مصالحه‌های طراحی را مشخص می‌کند
طرح کلی یک یا چند معماری کاندید
شناسایی خطرات (ریسک‌ها)
آماده‌سازی یک جدول زمان‌بندی اولیه پروژه و برآورد هزینه
امکان‌سنجی
خرید یا توسعه
نقطه عطف (سنگ نشان) جرخه حیات هدف مورد نظر، نشانه پایان فاز آغازین است.
توسعه یک چشم‌انداز تقریبی از سیستم، مورد کسب و کار را مشخص می‌کند، دامنه را تعریف می‌کند، و برآوردی سختگیرانه برای هزینه و زمانبندی ایجاد می‌کند.
فاز تحلیل جزئیات
در طول فاز تحلیل جزئیات از تیم پروژه انتظار می‌رود که یک برآورد درست از اکثریت نیازمندی‌های سیستم به دست بیاورد. اگرچه، اهداف اولیه فاز تحلیل جزئیات، پرداختن به عوامل ریسک شناخته شده و ساخت و اعتبارسنجی معماری سیستم است. فرایندهای معمول انجام شده در این فاز شامل ایجاد دیاگرام موارد کاربری (use case دیاگرام)، دیاگرام مفهومی (کلاس دیاگرام تنها با نمادگذاری پایه) و دیاگرام بسته‌بندی (بسته‌بندی نمودار) (دیاگرام معماری) است.
معماری در درجه اول از طریق پیاده‌سازی یک اساس معماری قابل اجرا اعتبارسنجی می‌شود. این یک پیاده‌سازی جزئی از سیستم است که شامل مهم‌ترین مولفه‌ها از نظر معماری است و در یک سری از تکرارهای با زمانبندی‌های کوچک ساخته می‌شود. در پایان فاز تحلیل جزئیات، معماری سیستم باید تثبیت شده باشد و اساس معماری قابل اجرا باید نشان دهنده پشتیبانی معماری از عملکرد کلیدی سیستم باشد و رفتار درست را از نظر کارایی و مقیاس پذیری و هزینه نمایش دهد.
نسخه نهایی قابل تحویل فاز تحلیل جزئیات یک طرح (شامل تخمین هزینه و زمانبندی) برای فاز ساخت و ساز است. در این مرحله آن طرح باید دقیق و معتبر باشد، چرا که باید مبتنی بر تجربیات فاز تحلیل جزئیات باشد علاوه بر اینکه در فاز ساخت باید به عوامل ریسک مهم و قابل توجه پرداخته شود.
فاز ساخت و ساز
فاز ساخت بزرگترین فاز در پروژه است. در این فاز باقی مانده سیستم بر مبنای بنیان ایجاد شده در فاز تحلیل جزئیات ساخته می‌شود. ویژگی‌های سیستم در یک سری از تکرارهای کوتاه و زمانبندی شده پیاده‌سازی می‌شود. هر تکرار منجر به انتشار یک نسخه قابل اجرا از نرم‌افزار می‌شود. مرسوم است که در فاز ساخت موارد کاربری را به طور کامل می‌نویسند و هر مورد کاربری شروع یک تکرار جدید است. دیاگرام‌های معمول زبان مدلسازی یکپارچه Unified Modeling Language (UML) در این فاز استفاده می‌شوند که عبارتند از: دیاگرام‌های فعالیت، دیاگرام‌های توالی، دیاگرام‌های همکاری، دیاگرام‌های انتقال حالت و دیاگرام‌های تعامل کلی.
پیاده‌سازی تکراری به منظور کاهش ریسک‌ها و داشتن عناصر ساده‌تر انجام می‌شود. نسخه نهایی قابل تحویل فاز ساخت یک نرم‌افزار است که آماده برای استقرار در فاز انتقال است.
فاز انتقال
فاز نهایی پروژه فاز انتقال است. سیستم برای ارائه به کاربران هدف، استقرار می‌یابد. بازخورد دریافت شده از انتشار اولیه (یا انتشارهای اولیه) ممکن است منجر به چندین پالایش شود که در طی دوره‌ای از چندین تکرار در فاز انتقال انجام می‌شوند. فاز انتقال همچنین شامل تغییرات سیستم و آموزش کاربر است.
اصلاحات و تغییرات
اصلاحات (پالایش‌های) فرایند یکپارچه در اینکه چگونه روند و جریان کاری پروژه را دسته‌بندی می‌کنند با یکدیگر متفاوت هستند. فرایند یکپارچه منطقی نه روند را تعریف می‌کند: مدلسازی کسب و کار، نیازمندی‌ها، تجزیه و تحلیل و طراحی، پیاده‌سازی، آزمون، استقرار، پیکربندی و مدیریت تغییر، و مدیریت پروژه و محیط زیست. فرایند یکپارچه تجاری RUP را از طریق هشت روند دیگر علاوه بر روندهای فوق توسعه می‌دهد. پالایش چالاک UP مانند OpenUP/Basic و فرایند یکپارچه چالاک RUP را با کاهش تعداد روندها ساده می‌کند.
اصلاحات همچنین در تاکید قرار داده شده روی مصنوعات مختلف پروژه متفاوت هستند. پالایش‌های چابک RUP را با ساده‌سازی جریان کار و کاهش تعداد مصنوعات مورد انتظار، ساده‌تر و موثرتر می‌کند.
اصلاحات همچنین در مشخصات خود از این نظر که پس از فاز انتقال چه اتفاقی می‌افتد متفاوت هستند. در فرایند یکپارچه منطقی فاز انتقال به طور معمول با یک فاز آغازین جدید دنبال می‌شود. در فرایند یکپارچه تجاری فاز انتقال توسط یک فاز تولید دنبال می‌شود.
تعداد پالایش‌ها و اصلاحات فرایند یکپارچه بی‌شمار است. سازمانهایی که از فرایند یکپارچه استفاده می‌کنند همواره تغییرات و الحاقات خود را در این فرایند انجام می‌دهند. لیست زیر برخی از شناخته شده‌ترین اصلاحات و تغییرات است.
فرایند یکپارچه چالاک (AUP) یک نسخه سبک توسعه یافته توسط Scott W. Ambler
فرایند یکپارچه اساسی (BUP) یک نسخه سبک توسعه یافته توسط آی بی‌ام و پیشرو به OpenUP
فرایند یکپارچه تجاری (EUP) یک گسترش از فرایند یکپارچه منطقی
فرایند یکپارچه ضروری (EssUP) یک نسخه سبک توسعه یافته توسط Ivar Jacobson
فرایند یکپارچه باز (OpenUP) چارچوب فرایند توسعه نرم‌افزار Eclipse
فرایند یکپارچه منطقی (RUP) توسعه یافته توسط آی بی‌ام / Rational Software development process
روش یکپارچه اوراکل (OUM) توسعه و پیاده‌سازی توسط اوراکل
فرایند یکپارچه منطقی-مهندسی سیستم (RUP-SE) یک نسخه از RUP طراحی شده توسط Rational Software برای مهندسی سیستم