دسته بندی : توسعه نرم‌افزار - software development

نوشته شده در 1396/03/24

OpenUP چیست؟

OpenUP یک فرایند یکپارچه ساده است که رویکردهای تکراری و افزایشی را در یک چرخه حیات ساخت‌یافته به کار می‌برد. OpenUP یک فلسفه چابک و عملی که روی طبیعت مبتنی بر همکاری توسعه نرم‌افزار تمرکز دارد را می‌پذیرد. این یک فرایند کم تشریفات و مستقل از ابزارها است که می‌تواند برای اداره طیف گسترده‌ای از انواع پروژه توسعه یابد.

OpenUP

لایه‌های OpenUP: ریز افزایش‌ها، چرخه حیات تکرار و چرخه حیات پروژه

تلاش فردی روی یک پروژه OpenUP در ریز افزایش‌ها (micro-increments) سازماندهی می‌شود. این نشان‌دهنده واحدهای کوتاه (کوچک) کار است که یک سرعت ثابت قابل اندازه‌گیری از پیشرفت پروژه تولید می‌کند (معمولاً به ساعت یا چند روز محاسبه می‌شود). این فرایند، همکاری شدیدی را اعمال می‌کند طوری که سیستم توسط یک تیم متعهد خودسازمان‌یافته به تدریج توسعه داده می‌شود. این ریز افزایش‌ها یک حلقه بازخورد بسیار کوتاه را فراهم می‌کند که تصمیمات انطباقی را در هر تکرار هدایت می‌کند.

OpenUP پروژه را به تکرارها تقسیم می‌کند: فواصل زمانی برنامه‌ریزی‌شده معمولاً به هفته اندازه‌گیری می‌شود. تکرارها به شیوه‌ای قابل پیش‌بینی توجه تیم را روی ارائه ارزش افزایشی به ذینفعان متمرکز می‌کند. طرح تکرار تعریف می‌کند که چه چیزی باید در تکرار تحویل داده شود و نتیجه، یک خروجی (build) قابل نمایش (demo-able) یا قابل استفاده (shippable) است. تیم‌های OpenUP پیرامون اینکه چگونه اهداف تکرار را به انجام برسانند و متعد به تحویل نتایج باشند خود را سازماندهی می‌کنند. آن‌ها این کار را با تعریف و بیرون کشیدن وظایف دقیق از یک لیست کار، انجام می‌دهند. OpenUP یک چرخه حیات تکرار را به کار می‌گیرد که چگونگی به کار گرفتن micro-incrementها را برای تحویل خروجی‌های پایدار و منسجم سیستم، سازماندهی می‌کند که به تدریج به سمت اهداف تکرار پیش می‌برد.

OpenUP چرخه حیات پروژه را در چهار مرحله سازماندهی می‌کند: شروع (Inception)، جزئیات (Elaboration)، ساخت (Construction) و انتقال (Transition). چرخه حیات پروژه، نقاط تصمیم‌گیری و دید را در طول پروژه برای ذینفعان و اعضای تیم فراهم می‌کند. این نظارت مؤثر را امکان‌پذیر می‌سازد و به شما اجازه می‌دهد تا در زمان‌های مناسب، تصمیمات «انجام‌دادن یا انجام‌ندادن» را بگیرید. یک طرح (برنامه) پروژه، چرخه حیات را تعریف می‌کند و نتیجه نهایی یک اپلیکیشن منتشرشده است.

 

مرور کلی OpenUP

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

حضور ذینفعان به عنوان اعضای تیم برای پیاده‌سازی موفق OpenUP حیاتی است.

اعضای تیم در جلسات ایستاده روزانه شرکت می‌کنند تا درباره وضعیت و مسائل گفت‌وگو شود. مشکلات خارج از جلسات روزانه رسیدگی می‌شود.

OpenUP روی کاهش قابل توجه ریسک در اوایل چرخه حیات تمرکز دارد. این امر نیاز به جلسات منظم بازبینی ریسک و اجرای دقیق راهبردهای کاهش خطر دارد.

تمام کارها از طریق فهرست موارد کار (لیست کارها) لیست می‌شود، دنبال می‌شود و تخصیص داده می‌شود. اعضای تیم از این مخزن واحد برای تمام وظایفی که نیاز به ثبت‌شدن و پیگیری دارد استفاده می‌کنند. این شامل تمام درخواست‌های تغییر، باگ‌ها و درخواست‌های ذینفع است.

Use Caseها برای استخراج و توصیف نیازها استفاده می‌شود؛ بنابراین اعضای تیم نیاز به توسعه مهارت‌ها در نوشتن Use Caseهای خوب دارند. ذینفعان مسئول بازبینی و تأیید درست‌بودن نیازها هستند. Use Caseها به صورت مشارکتی توسعه داده می‌شوند.

نیازهای مهم معماری باید در فاز جزئیات شناسایی و تثبیت شوند، بنابراین یک معماری قوی می‌تواند به عنوان هسته سیستم ایجاد شود. یک تغییر نیاز مهم معماری که نیاز به رسیدگی دارد، ممکن است بعداً در توسعه به وجود آید اما ریسک این اتفاق به طور قابل توجهی در تکرار جزئیات (فاز جزئیات) کاهش می‌یابد.

در هر تکرار، چندین بار تست انجام می‌شود، هر زمان که راه‌حل با توسعه یک نیازمندی، تغییر یا رفع باگ افزایش (رشد) می‌یابد. این تست‌ها به تضمین ایجاد یک خروجی پایدار و همیشه در دسترس به عنوان پیشرفت‌های توسعه کمک می‌کند.

OpenUP شامل استقرار، مدیریت پیکربندی یا محیط توسعه (مانند سفارشی‌سازی این فرایند یا راه‌اندازی محیط‌های توسعه) نیست. OpenUP روی یک تیم واحد تمرکز دارد و این حوزه‌ها به طور کلی در سطح سازمانی یا شرکت پرداخته شده است. افزونه‌های OpenUP را که به این حوزه‌های گسترده‌تر می‌پردازد ببینید.

OpenUP یک فرایند توسعه نرم‌افزار کمینه، کامل و توسعه‌پذیر است. این فرایند توسط چهار اصل اساسی اداره می‌شود:

  • همکاری برای پشتیبانی از منافع و درک مشترک

  • متعادل‌کردن اولویت‌های در حال رقابت برای حداکثرکردن نفع ذینفعان

  • تمرکز بر معماری زودهنگام برای حداقل‌کردن ریسک‌ها و سازماندهی توسعه

  • توسعه تدریجی برای بدست‌آوردن مداوم بازخورد و بهبود

چرخه حیات توسعه نرم‌افزار OpenUP

OpenUP یک فرایند تکراری است که در سراسر چهار فاز توزیع شده است: شروع، جزئیات، ساخت و انتقال. هر فاز شامل یک یا چند تکرار است که در آن، نسخه‌های پایدار و اجرایی از نرم‌افزار، توسعه داده و منتشر می‌شود؛ با تکمیل هر تکرار یک مرحله جزئی از پروژه ارائه می‌شود و به دستیابی موفقیت‌آمیز به مرحله مهم فاز که در آن اهداف فاز برآورده می‌شوند کمک می‌کند.

نمودار زیر چرخه حیات OpenUP را به تصویر می‌کشد.

 

چگونه شروع کنیم؟

چهارمین اصل اساسی OpenUP، «توسعه تدریجی برای بدست‌آوردن مداوم بازخورد و بهبود»، یک رویکرد تکراری و افزایشی برای به‌کارگیری OpenUP ارائه می‌کند.

  • شروع با اصول اساسی و درک اهداف پشت OpenUP

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

  • شروع به استفاده از OpenUP کنید تا ابتدا این نواحی را بهبود دهید.

  • در تکرارها یا چرخه‌های توسعه بعدی، در دیگر نواحی پیشرفت‌های تدریجی (بهبودهای افزایشی) ایجاد کنید.

  • اگر شما در فرایندهای یکپارچه یا دیگر فرایندهای تکراری تجربه‌ای ندارید یا کم‌تجربه هستید، از OpenUP در یک پروژه آزمایشی کوچک استفاده کنید، شاید تنها با سه تا چهار نفر که فقط برای دو تا سه ماه کار می‌کنند.

 

اصول اساسی

چهار اصل اساسی، اهداف کلی پشت OpenUP را در بر دارد. آن‌ها پایه و اساس را برای تفسیر نقش‌ها و محصولات کار و برای انجام وظایف ایجاد می‌کنند.

متعادل‌کردن اولویت‌های در حال رقابت برای حداکثرکردن نفع ذینفعان

ترویج اقداماتی که به شرکت‌کنندگان در پروژه و ذینفعان اجازه می‌دهد تا راه‌حلی را توسعه دهند که منافع ذینفعان را حداکثر می‌کند و با محدودیت‌های قرارداده‌شده روی پروژه سازگار است.

همکاری برای پشتیبانی از منافع و درک مشترک

ترویج اقداماتی که یک محیط تیمی سالم را پرورش می‌دهد، همکاری را امکان‌پذیر می‌سازد و درک مشترکی از پروژه را توسعه می‌دهد.

تمرکز بر معماری زودهنگام برای حداقل‌کردن ریسک‌ها و سازماندهی توسعه

ترویج اقداماتی که به تیم اجازه می‌دهد تا برای حداقل‌کردن ریسک‌ها و سازماندهی توسعه روی معماری تمرکز کنند.

توسعه تدریجی برای بدست‌آوردن مداوم بازخورد و بهبود

ترویج اقداماتی که به تیم اجازه می‌دهد تا از ذینفعان بازخورد مداوم و زودهنگام بگیرد و محصول در حال پیشرفت (ارزش افزایشی) را به آن‌ها نشان دهد.
 

مفاهیم پایه فرایند

تمام کاربران یک فرایند باید با این مفاهیم اساسی فرایند آشنا باشند.

عناصر پایه

محصول کار: چیزی که تولید می‌شود

وظیفه: چگونه کار را انجام دهیم

نقش: چه کسی کار را انجام می‌دهد

فرایند: برای تعریف زیرشاخه‌های کار و جریان کار استفاده می‌شود

راهنما: قالب‌ها، چک‌لیست‌ها، مثال‌ها، دستورالعمل‌ها، مفاهیم و …

جزئیات و مثال‌ها

محصول کار (Work Product)

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

  • اسناد، مانند یک دید یا یک طرح پروژه

  • یک مدل، مانند یک مدل Use Case یا یک مدل طراحی. این‌ها می‌توانند شامل عناصر مدل (زیرفراورده‌ها) مانند کلاس‌های طراحی، Use Caseها و زیرسیستم‌های طراحی باشند.

  • پایگاه داده‌ها، صفحه‌گسترده‌ها و دیگر مخازن اطلاعات

  • کد منبع و فایل‌های قابل اجرا

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

نقش

یک نقش، رفتار و مسئولیت‌های یک فرد یا یک مجموعه از افراد را که باهم به عنوان یک تیم کار می‌کنند تعریف می‌کند.

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

مثال:

تحلیل‌گر – نماینده مشتریان و کاربران نهایی است، اطلاعات را از ذینفعان جمع‌آوری می‌کند و نیازها را تعریف می‌کند.

توسعه‌دهنده – بخشی از سیستم را توسعه می‌دهد، شامل طراحی، پیاده‌سازی، تست واحد و یکپارچه‌سازی (ادغام).

 

نقش‌های اساسی

ذینفع (Stakeholder) نشان‌دهنده گروه‌های ذینفع است؛ کسانی که نیازهایشان باید توسط پروژه برآورده شود. این نقشی است که ممکن است توسط هر کسی که به طور قابل توجهی تحت تأثیر نتیجه پروژه قرار می‌گیرد (یا به طور بالقوه قرار خواهد گرفت) ایفا شود.

تحلیل‌گر (Analyst) دغدغه‌های مشتری و کاربر نهایی را با جمع‌آوری اطلاعات از ذینفعان برای درک و حل مشکل و با گرفتن و تعیین اولویت نیازمندی‌ها ارائه می‌کند.

مدیر پروژه (Project Manager) برنامه‌ریزی پروژه را رهبری می‌کند، تعاملات با ذینفعان را هماهنگ می‌کند و تمرکز تیم پروژه را روی برآورده ساختن اهداف پروژه نگه می‌دارد.

معمار (Architect) مسئول تعریف معماری نرم‌افزار که شامل گرفتن تصمیمات کلیدی فنی است که طرح و پیاده‌سازی کلی سیستم را محدود می‌کند.

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

تستر (Tester) مسئول فعالیت‌های اصلی اقدامات (تلاش) تست است. این فعالیت‌ها شامل شناسایی، تعریف، پیاده‌سازی و انجام تست‌های لازم است، همچنین واقعه‌نگاری خروجی‌های تست و تحلیل نتایج.

هر نقشی (Any Role)؛ در یک تیم هر کسی می‌تواند این نقش از انجام وظایف عمومی را داشته باشد.

نظرات 0

ارسال نظر