تیم های توسعه در سالهای اخیر مسئولیت بیشتری را به دست آورده اند: به عنوان تیم های متقاطع یا تیم های محصول ، آنها معماری نرم افزاری را طراحی می کنند و الزامات را تعیین می کنند. برای انجام این کار ، آنها برای درک ذینفعان خود ، برای تصمیم گیری در مورد طراحی و برقراری ارتباط با آنها ، به ایدز احتیاج دارند. روشهای کارگاه مناسب برای این اهداف با اصطلاح “مدل سازی مشترک” (“بیشتر” COMO “) خلاصه می شود. COMO همچنین در موارد ابزار تجزیه و تحلیل های تجاری و مهندسان مورد نیاز متعلق است زیرا می توانند از آن برای روشن شدن فرآیندهای تجاری و الزامات استفاده کنند.

آیا مدل سازی همکاری IST بود؟

مدل سازی الزامات ، معماری و فرآیندهای تجاری – این همان چیزی است که COMO مشخص می شود. “با هم” اغلب فقط بیش از اعضای یک تیم توسعه را شامل می شود. از آنجا که نیازی به دانش علوم رایانه برای شرکت در کارگاه های COMO نیست ، متخصصانی که مدیریت و سایر افراد بدون پیشینه IT را می توانند به طور فعال در مدل سازی نقش داشته باشند. این نیز ضروری است ، زیرا تیم های توسعه باید دامنه را درک کنند ، یعنی وظایف و فرآیندهای کاری کاربران خود را می شناسند. این تنها راه توسعه برنامه های با ارزش حرفه ای است. COMO در نظر گرفته شده است تا دانش تخصصی را از روسای متخصصان به روسای توسعه دهندگان ، آزمایش کنندگان ، صاحبان محصول ، مدیران محصول و تحلیلگران تجارت برای همه کسانی که در توسعه نرم افزار درگیر هستند ، منتقل کند. بازخورد مستقیم بین همه افراد درگیر بسیار مهم است. این روش های COMO را از تکنیک های کلاسیک تجزیه و تحلیل نیاز ، که در آن مصاحبه ها رهبری می شوند و اسناد مورد نیاز ایجاد می شود ، متمایز می کند.

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

مفاهیم اساسی مدل سازی مشترک

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

• کار گروهی از همه شرکت کنندگان: طرفین درگیر در صفحه متخصص و توسعه ، به طور مشترک فرایندها و الزامات را به جای آن متخصصان خاص روشن می کنند ، این مباحث را بر اساس مصاحبه ها و تجزیه و تحلیل اسناد مشخص می کنند. روشهای COMO کارگاه های مشترک را فراهم می کند. بعضی اوقات در گروه های بزرگ ، گاهی اوقات با تعداد کمی از نمایندگان طرف های مختلف.
• داستان ها می گویند: در کارگاه ها ، شرکت کنندگان به جای فرآیندهای انتزاعی ، سناریوهای خاص را مورد بحث قرار می دهند. سناریوها مانند داستان ها گفته می شود. اگر همه افراد درگیر سناریوها را درک کرده باشند ، ایجاد انتزاع لازم برای توسعه نرم افزار به دنبال و – تا حد امکان کامل – تصاویر قوانین و اختلافات موردی است.
• برای درک متقابل در مورد یک زبان مشترک تلاش کنید: تمام روشهای COMO روی زبان فنی تمرکز می کنند. تکنیک های مختلف کارگاه باید به افراد درگیر در درک آنها کمک کند. تاخیر و ابهامات پاک می شوند.
• مدل های بصری را با هم ایجاد کنید: شرکت کنندگان نه تنها داستانهایی را به صورت شفاهی می گویند بلکه آنها را در مدل های بصری ضبط می کنند. نمادها ساده هستند ؛ (دیجیتالی) تخته های سفید و پس از آن به عنوان ابزار خدمت می کنند. مدل ها وضعیت بحث را نشان می دهند و دیدگاه مشترک موضوع را مستند می کنند.

روشهای کومو در پرتره کوتاه

یک مقاله مروری مانند این فقط می تواند به چند روش محدود شود و همچنین آنها را به طور کامل توصیف نمی کند. او باید شما را ترغیب کند تا با روش های COMO نگاه دقیق تری داشته باشید. این به دنبال توصیف روشها و اهداف آنها و همچنین نمونه هایی از دامنه “فرودگاه” است ، جایی که مردم منتظر اتوبوس به هواپیما (یا از هواپیما به ترمینال) هستند. مثالها نشان می دهد که سازماندهی انتقال اتوبوس و چه الزاماتی برای یک سیستم دفع تازه توسعه یافته می تواند قرار گیرد.

داستان پردازی دامنه

در داستان پردازی دامنه ، فرآیندهای تجاری نمونه شرکت کننده می گوید. یک مجری جمله را با جمله با یک تصویر تجسم می کند (شکل 1 را ببینید). از آنجا که هر داستان یک مورد خاص را توصیف می کند ، به عنوان مثال یک “مسیر شاد” ساده یا یک مورد خاص مهم ، زبان بصری به هیچ عباراتی بدون نماد نیاز ندارد. تعداد کمی از داستان های دامنه برای درک خود فرآیندهای پیچیده تجاری کافی است. داستانهای دامنه به ویژه برای بحث مناسب هستند ، در بود با چه با چه کسی وت به چه دلیلی ممکن است

اهداف شامل:

• تجزیه و تحلیل فرآیند و طراحی
• جداسازی سیستم های یکپارچه
• نیازهای معجزه
• طراحی یک مدل دامنه
• برقراری ارتباط بین فرآیندهای واقعی و هدف

طوفان رویداد

در رویداد طوفانی ، کسانی که درگیر با یادداشت های چسب کار می کنند و تصویری از یک فرایند تجاری را اهدا می کنند. این تصویر “از پایین به بالا” به عنوان نتیجه حوادث دامنه ، رویدادهای فنی مانند “فرود هواپیما” یا “دستور پذیرفته شده” ایجاد شده است. یادداشت های چسب داستانی را بیان می کنند. احزاب درگیر می توانند به سرعت و با اطمینان ناسازگاری ها و نقاط اصطکاک را کشف کنند و ببینند که چگونه درک مشترک دیوار بر روی دیوار ایجاد می شود. نام طوفان رویداد این است که در این کارگاه همه درگیر (مانند طوفان مغزی) در ابتدا “طوفان” از آنچه در دامنه اتفاق می افتد. برای انجام این کار ، یادداشت های چسب زرد را بنویسید و رویدادهای دامنه را به یک دیوار وصل کنید (شکل 2 را ببینید). بسته به هدف کارگاه ، مجری به تدریج رنگ های دیگری مانند صورتی را برای نقاط داغ (مشکلات ، درگیری ها ، سؤالات) و بنفش برای سیاست ها (قوانین تجاری) معرفی می کند.

اهداف شامل:

• تجزیه و تحلیل فرآیند و طراحی
• جداسازی سیستم های یکپارچه
• طراحی یک مدل دامنه
• سیستم پیش نویس

نقشه برداری مثال

نقطه شروع به عنوان مثال نقشه برداری مورد نیاز بزرگ است ، به عنوان مثال در قالب داستانهای کاربر. استفاده از مثال ، کارشناسان و اعضای یک تیم توسعه ، قوانین فنی یا شرایط مرزی یک شرط را به منظور استخراج تست های پذیرش روشن می کنند. برای انجام این کار ، الزامات (زرد) ، قوانین/معیارهای پذیرش (آبی) ، نمونه های بتونی (سبز) و سؤالات باز (نارنجی) را در رنگ های مختلف بنویسید (شکل 3 را ببینید). نمونه ها به قوانین اختصاص داده می شوند (انگلیسی “نقشه برداری” – از این رو نام روش). این کار را می توان هر دو از بالا به پایین (یعنی یک قاعده با مثال) و همچنین از پایین به بالا (یعنی قوانین جدید از مثالها) انجام داد.

اهداف شامل:

• شفاف سازی و کاهش الزامات ، به عنوان مثال به عنوان بخشی از پالایش پس زمینه
• معیارهای پذیرش و موارد آزمایش
• آماده سازی برای اتوماسیون تست با زبان توصیف gherkin

نقشه برداری داستان کاربر

نقشه برداری داستان کاربر از جامعه چابک است. یک داستان کاربر در دو بعد نیازهای ساختاری دارد – هم در افقی و هم در عمودی:

• بعد افقی از کارتهایی با مراحل تقریباً فرموله شده تشکیل شده است. از چپ به راست ، آنها یک داستان منسجم را از منظر کاربر برنامه ای که باید توسعه یابد ایجاد می کنند.
• داستانهای کاربر در بعد عمودی اعمال می شوند – که بیشتر با اولویت طبقه بندی می شوند (شکل 4 را ببینید). داستانهای کاربر که در اینجا به مراحل فرآیند خشن (“نقشه برداری”) اختصاص داده می شود نیز برای این روش ناشناس بود.

اهداف شامل:

• روشن کردن الزامات یا پالایش عقب مانده
• توسعه حداقل یک محصول قابل دوام
• برنامه ریزی نسخه های محصول