Процес моделювання предметної області. Гайд для бізнес-аналітиків

💡 Усі статті, обговорення, новини про продукти — в одному місці. Приєднуйтесь до Product спільноти!

Привіт, мене звати Ілля, працюю продакт-менеджером в Star.

На цю статтю мене наштовхнула думка, що тема пресейлів стає все більш і більш актуальною, адже український ІТ-аутсорс дещо втратив клієнтів останнім часом і багато компаній налягли на залучення нових. Рано чи пізно, вони почнуть вистрілювати, що створить певне навантаження на пресейл-команди, в тому числі та на бізнес-аналітиків.

Я сподіваюсь, що ця техніка допоможе всім, хто задіяний у пресейлах, а особливо тим, хто не привʼязаний до конкретної індустрії, потребує швидкого занурення у новий для себе чи компанії домен.

Предметна область (домен)

Що ж таке предметна область і навіщо її моделювати? Трохи теорії.

Предметна область, або домен, у загальному сенсі можна визначити як «сфера знань, впливу або активності...», а специфічно для розробки програмного забезпечення «..., навколо якої будується логіка програмного забезпечення». Детальніше тут.

Модель — це спрощений спосіб представлення реальності. У цій статті йтиме мова про концептуальну модель, тобто представлення сукупності обʼєктів, навколо чи за допомогою яких ми будемо будувати нашу майбутню систему.

Коли ми створюємо концептуальну модель, ми аналізуємо домен в цілому, тому не так важливо розділяти поточний і майбутній стани системи.

Створення доменної моделі може бути корисним:

  • для поглиблення вашого власного розуміння, адже сам процес створення стимулює дослідження;
  • як інструмент для виявлення вимог, особливо скритих, очевидних для замовника;
  • як інструмент передачі знань;
  • як інструмент для спілкування з архітектором.

Аналітик в пресейлі

На поточному місці роботи раз на кілька місяців доводиться брати участь у пресейлах.
В залежності від запиту, з яким прийшов замовник, команда пресейлу може мати технічних спеціалістів (як мінімум архітектор), проджект-менеджера (зазвичай у якості пресейл ліда), UX-спеціаліста та спеціаліста, що покриває частину бізнес-аналізу (бізнес-аналітика або продакт-менеджера).

З точки зору бізнес-аналітика, специфіка пресейлу полягає у тому, що потрібно у досить короткий термін сформувати вимоги, які потім має оцінити технічна команда. Також досить часто потрібно доєднатись до пресейлу, домен якого аналітику досконало (чи взагалі) не відомий.

Звідси постає декілька критичних питань:

  • як за короткий час, та ще й не знаючи домену, побудувати якісні вимоги?
  • як показати замовнику, що ми говоримо з ним однією мовою?
  • як ставити релевантні запитання?

Додамо до цього обмеження часу, що заданий рамками пресейл-проєкту, ще й основний проєкт задіяного аналітика та необхідність хоч іноді відпочивати.

Для себе я відповів на це питання, зупинившись на моделюванні предметної області (domain model), як інструменті, що дозволяє в досить стислі терміни з мінімальною інформацією на вході зрозуміти про що йдеться.

Перед тим, як почати

Дотримуюсь підходу, що будь-який інструмент чи техніку є шанс ефективно застосувати, якщо мати на увазі наступні основні елементи: вхідна інформація, цілі, зацікавлені особи, інструменти.

Цілі

Спочатку наведу приклади типових цілей моделювання:

  1. Розібратись самому в новому бізнес домені і на основі цього виконати наступні пункти.
  2. Сформувати перелік питань для інтервʼю замовника.
  3. Сформувати перелік сценаріїв використання.
  4. Пояснити суть предметної області технічним спеціалістам.
  5. Передати знання іншому бізнес-аналітику або цілій команді.

Зацікавлені особи

Відповідно до цілей з прикладу, найголовнішою зацікавленою особою тут у першу чергу є сам аналітик, далі — його наступник з команди розробки, архітектор, дизайнер тощо. Потенційно — всі, хто так чи інакше буде брати участь у пресейлі та у розробці.

Вхідна інформація

На вхід може бути отримано все що завгодно, від незначного брифінгу сейлза до велетенського RFP з переліком функціональностей, яку надіслав потенційний клієнт. Rule of thumb для мене такий — чим менше вхідної інформації, тим більше зростає важливість надати їй форму та розібратись.

Інструменти

Під інструментами я маю на увазі програмне забезпечення (софт) для моделювання та нотації. Але тут все просто — чим краще володієте тим, що доступно або прийнято у вашій компанії — те і використовуєте. Іноді нотації та софт диктуються проєктом, але це рідко буває саме на пресейлах. Сам підхід, який я хочу сьогодні розглянути не залежить від інструментів.

Для себе серед нотацій (UML Class Diagrams, Crow’s foot ERD, ERM) саме для концептуальних моделей я зупинився на нотації Crow’s foot. По софту останнім часом все більше використовую Miro іноді diagrams.net, рідше — PlantUML.

В принципі, для власних потреб, можна швиденько накидати просто стікерів чи квадратиків і не паритись з нотацією (створити такий собі mind map). Але такий підхід погано масштабується. Тож якщо плануєте вашу майбутню модель комусь показувати, щось за допомогою неї пояснювати — варто оформити її як слід.

Процес моделювання

Отже, визначившись із вищеперерахованим і зібравши з доступних джерел інформацію, можна переходити до моделювання. В залежності від складності домену, що в першу чергу задається вашим його початковим рівнем розуміння, процес може трохи відрізнятись, але в середньому можна прийняти наступний порядок дій:
  • Занотувати своє розуміння того, про що проєкт, що має робити застосунок, яку проблему вирішувати.
  • Перерахувати основних користувачів або персон.
  • Продумати ключові сценарії використання чи взяти ті, про які згадав замовник.
  • Визначити процеси, які на вашу думку необхідні для забезпечення діяльності компанії замовника.

Це по суті і буде контекст, який вже можна використовувати для нарощування обсягу інформації: пошуку у Google чи запитів до ChatGPT, чи, в ідеалі, питань до замовника та SME (експерта предметної області).

Цей процес займає від декількох годин до днів і напряму залежить від якості та кількості вхідної інформації. З власного досвіду, після того, як набив руку, максимальний час складає до 8 годин протягом декількох днів. Для чогось зовсім нового (а-ля rocket science) звісно часу потрібно значно більше, зросте кількість ітерацій та уточнень.

Для прикладу візьмемо задачу з реального проєкту, але значно спрощену:

«Побудувати систему для морського вантажного терміналу, що буде відповідати за розвантаження контейнерів із судна та розміщення їх у контейнерному депо.»

Сутності

Не залежно від нотації, яку ми оберемо, наступним кроком моделювання буде запис всіх можливих сутностей (обʼєктів) у нашому домені. Для концептуальної моделі здебільшого це будуть фізичні обʼєкти, які нам потім знадобляться (або ні) у нашій майбутній інформаційній системі.

Ідентифікувати основні обʼєкти можна, розглядаючи процеси та сценарії використання, які ми записали раніше — це щось, над чим виконується операція (фізичні об’єкти, документи й т.д..), і хтось, хто виконує ці операції.


Основні сутності нашого домену

Атрибути

Далі потрібно записати атрибути — характеристики сутностей, що ми обрали. Відрізнити атрибут від сутності (обʼєкту) дуже просто: атрибути самі ніякої роботи не виконують, вони тільки можуть щось описати. Також в атрибутів є значення, наприклад:


Обʼєкт — атрибут — значення

Варто зазначити, що на рівні концепту самі атрибути та їх значення не відіграють вирішальної ролі, в цілому ними можна знехтувати. Проте, якщо ми хочемо скласти краще уявлення про домен, хоча б основні атрибути потрібно записати.

Деякі важливі атрибути наших сутностей

Звʼязки

Тепер можна переходити до звʼязків. Знову таки, абстрагуючись від нотації, зв’язок — це те, яким чином сутності асоціюються одна з одною. Зв’язок можна схарактеризувати:

  • дією, що поєднує дві сутності,
  • співвідношенням сутностей одна до одної (Cardinality).
  • Звʼязок в основному встановлюють, керуючись загальною логікою, та іноді його можуть продиктувати атрибути: У наведеному прикладі:
    • один оператор маніпулює декількома кранами,
    • декілька кранів розташовані на одному причалі,
    • щонайменше одна зона розміщення контейнерів розташована на одному причалі,
    • один кран може розвантажити декілька контейнерів,
    • багато або жодного контейнера може бути перевезено на кораблі,
    • один корабель може бути пришвартовано в одному доці.
    Жирним виділено приклад атрибута, який є посиланням на іншу сутність.Кардинальність не відіграє великої ролі при моделюванні концепту. Щоб засвоїти предметну область на рівні, достатньому для проведення пресейлу, це не завжди потрібно, скоріше бажано.

    Оформлення

    Після того, як ми все зʼєднали і описали настає час «причісувати» нашу модель. Деякі утиліти справляються з цим краще, деякі, наприклад PlantUML, візуально менш апетитні. В загальному, щоб вашу модель було легше сприймати, раджу звернути увагу на наступне:
    • будьте консистентними (наприклад, якщо вказуєте кардинальність, робіть це всюди, використовуйте однаковий шрифт та формат фігур);
    • на скільки це можливо, уникайте перехрещень зв’язків та не робіть їх надто довгими;
    • в ідеалі, підписи звʼязків мають читатись зліва направо та згори вниз.
    Я вживаю «бажано» і «в ідеалі», тому що через велику кількість сутностей це може бути досить складно, потрібно буде робити компроміси між розміром діаграми і «читабельністю». Сам процес моделювання у мене, сукупно, займає десь в районі 8 годин. Але протяжність може бути від декількох днів до тижня, знов таки, в залежності від складності домену, доступності SME або клієнта. Тож на весь процес створення я б закладав до чотирьох днів чистого часу і до двох тижнів по календарю для прям великих і комплексних RFP у практично невідомій сфері.

    Наступні кроки

    Немає, принаймні у мене, конкретних метрик, щоб визначити, коли пора завершувати процес. Поки що я не придумав кращого ніж «має бути достатньо». В залежності від масштабу (галузь знань в цілому, бізнес замовника, конкретний продукт) кількість сутностей і деталізація будуть різними. Тож і «достатньо» в кожному випадку буде інакшим, наприклад:
    • у вас закінчився час на виконання задачі,
    • ви не можете сформулювати нових висновків з існуючої моделі,
    • можете пояснити, про що ваша модель непідготовленій людині, і її питання не ставлять у вас у глухий кут.
    Іноді зупинитись важко через власний інтерес до предметної області. Але пресейли зазвичай досить обмежені у часі і задачі стоять дуже конкретні, тому я не бачу в цьому ризиків. У найгіршому випадку — ви ще краще розберетесь. Отже, після того, як ваша концептуальна модель зазнає декількох ітерацій, її можна використати для:
    • формулювання якісних питань до замовника,
    • комунікації меж відповідальності або scope проєкту,
    • виявлення сценаріїв використання та вимог,
    • у випадку успіху пресейлу потрібен ще й інструмент для передачі знань іншому аналітику та і всій команді розробки.

    Логічна модель

    Для того, щоб якісно деталізувати вимоги вже після успішного завершення пресейлу, потрібно опуститись на рівень нижче і створити логічну модель. Процес її створення аналогічний до концептуальної: можна використовувати ті самі інструменти, але вже критичну роль відіграють якісно і детально прописані звʼязки та атрибути сутностей. На цьому етапі у нас, як правило, буде краще розуміння вимог, цілей та обсягу проєкту, що дозволить виокремити з усього домену саме ті сутності, з якими буде працювати наша майбутня система.

    Замість висновку

    У цьому контексті знання техніки допомагає нам поглибити знання домену, тож у вічному холіварному питанні про «важлівіше техніка чи домен?» я схиляюсь до технік. Буду радий змістовним коментарям та питанням. Сподіваюсь, було корисно 🙂
👍ПодобаєтьсяСподобалось19
До обраногоВ обраному9
LinkedIn
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

А чому це називається у вас бізнес аналізом — а не архітектурою програмного забезпечення ? З іншого боку дати чітку лінію де закінчується одне і починається інше особисто мені складно, це занадто близькі теми.

Думаю критичність взаємодії архітектора і аналітика важко применшити. А модель — це прсто інструмент, не думаю, що є велика різниця в тому, хто саме його використовує, головне щоб розшарив :) Просто висновки з тієї самої моделі у бізнес аналітика будуть у одному напрямку (в першу чергу вимоги, сценарії), а у архітектора — трохи в іншому (технічне рішення, структура даних).

так, ERD — непогана альтернатива тій же concept model
єдине, що я не зрозумів — навіщо так глибоко моделювати структуру даних? (тобто є ERD логічна, значно простіша, а тут вже прямо з філдами у БД; на практиці це забере час, не кожен замовник її зрозуміє, розробникам ще рано туди занурюватися (та й прісейл може і не продатися) і в цілому краще приділити увагу логіці, адже зазвичай диявол — у її деталях, аніж у структурі і буде в нагоді для оцінки (як базис декомпозиції)

Дякую за коментар) Спробую відповісти.

навіщо так глибоко моделювати структуру даних?

Мені здалося, що я тут навпаки — не глибоко :)
Можливо, існують деякі розбіжності в тому, як ми розуміємо рівні моделей. (Але може мені здалося 🤷‍♂️) В моєму розумінні існує:

  1. Концептуальний — найбільш абстрактний і найменьш вимогливий (на мою думку) до дотрримання нотації. Це той, про який іде мова у статті. Може охоплювати весь домен або бізнес замовника в цілому.
  2. Логічний — коли вже детально потрібно прописувати атрибути, звязки ітп. Він вже тільки про вашу систему.
  3. Фізичний — модель бази даних, з визначенням ключів, індексів, тощо.
на практиці це забере час

Це підтримка на випадок, якщо треба розібратись саме у чомусь новому, тобто все одно треба витрачати час на discovery домену і якимось чином своє discovery оформляти.
У випадку пресейлу — замовник, це останній з ким я б шарив таку модель, але вона може допомогти нагенерувати питань до нього, саме для прояснення логіки.

Можливо малась на увазі конкретна нотація? якщо так, то мені особисто її просто важко сприймати у порівнянні з ERD.

рівні моделей

— тут я маю на увазі саме рівні, кожен з цих рівнів можна представити різними нотаціями.

можливо) я зрозумів чому — у статті Ви говорите про conceptual model як про частину Data Modeling, але є окрема техніка — Concept Modeling і як раз вона проводиться для моделювання предметної області (домену) через використання noun/verb concepts
і різниця між цима техніками у тому, що як раз ці noun/verb concepts виходять за межі потенційних об’єктів даних — наприклад, Ви не зможете описати зв’язки компанії з індустрією (постачальники, регулятори), якщо вони не передбачені як об’єкти даних (точніше можете, але сенсу у цьому не буде, бо буде повно концепцій, які не будуть сутностями даних і їх потім доведеться видаляти)

в цілому, можна поєднувати Concept Modeling та conceptual data model, але у такому випадку є сенс робити це саме у такому порядку, щоб не попасти у пастку, де ми описали солюшн, а контекст постраждав (БА не зрозумів домен)

ERD — непогана альтернатива тій же concept model

а і забираю свої слова назад)

На моделі не позначена різниця для типу зв«язків «один і лише один» та «нуль або один». Для всіх випадків позначка «dash». А має бути або «dash and dash», або «ring and dash»
Чи може існувати кран без оператора? Якщо так, то з боку оператора має бути «ring and dash»
Чи може бути оператор без закріпленого за ним крану? Якщо так, то з боку крану — «ring and dash».
У крана тільки один причал, тому з боку причалу «dash and dash»

Дякую, валідне зауваження. З точки зору нотації без цієї інформації модель не завершена (або не правильна), і сосбливо це було б критично, якби це була логічна модель. Ідея в тому, що на рівні концепту можна ще не знати, як саме сутності будуть відноситись у конкретній системі (нуль або один або один і тільки один) і взагалі cardinality не вказувати. Але той факт, що сутності існують і повʼязані між собою, без моделі взагалі може бути не очевидним.

якщо я правильно розумію на діаграмі корабель і причал мають взаємнозалежні відносини. тобто кораблю відповідає причал, а причалу відповідає корабель.
але якщо у причала є атрибут is_occupied то тоді або від завжді true, або правильніше так:
«не більше одного корабля може бути пришвартовано в одному доці» плюс має бути якось позначено на діаграмі той факт, що у причала може не бути корабля.
але можливо я помиляюся, ігноруйте.

Good spot, дякую. Відношеня має бути «один або 0 кораблів може бути пришвартовано до одного причалу». "Cargo ship" 0..1 --docked in-- 1 "Berth" Оновлю діаграму.

Дуже гарна змістовна стаття.
Хочу запропонувати ще один спосіб моделювання близький до ООП.
Наприклад, візьмемо вантажний човен. Це буде об’єкт контейнер об’єктів.
Наприклад, є бізнес-мета, дізнатися, скільки проплив цей човен?
Спочатку запропонуємо об’єкт лічільник та функцію, яка використовує якісь вхідні дані та повертає якесь значення.
І ось мені здається, що ця функція є запит до реляційної таблиці, яка заховалася у функції.
Тобто залежність зміни значення лічільника то є функція, а ця функція є якась реляційна таблиця. Ця таблиця може бути і зі значеннями, що розраховуються — один раз, а тоді кешуються і повертаються.
І ось що головне, що я хотів сказати: нам неначе достатньо для вичерпного ООП моделювання всього декілька речей: об’єктів, контейнерів об’єктів, функцій які не належать до якихось там об’єктів але встановлюють залежності між об’єктами, які можна навіть звести у реляційні таблиці.
Тобто, є такі завдання для моделювання:
1. Відношення — is
Це гіперонімічні, гіпонімічні відношення.
2. Відношення — have
Це контейнерні відношення.
3. Відношення між об’єктами, які не is і не have, але можуть бути зведені до запиту до якоїсь реляційної таблиці.
Ось, наприклад, графік залежності Y від X Це якась таблиця. Вона розраховується або зберігається, або і те і друге.
Таким чином, щоб щось промоделювати, нам достатньо відтворити це у ООП схемі, але із тим фактом, що функції будемо виконувати над об’єктами, але ці функції це щось окреме від об’єктів. Я ще розглядаю якесь походження більш спеціальних функцій від менш спеціальних тобто наслідування.

Гарна стаття.
На початку ви згадали про моделювання бізнес-процесів, але потім нічого про це не написали. Як ви моделюєте бізнес-процеси та бізнес-рішення замовника?

Привіт, дякую! В рамках цієї статті згадував бізнес-процеси і сценарії використання тільки як інпут для моделювання домену.
Щодо того, як саме: в контексті приісейлу, це завжди щось дуже високорівневе і просте з уваги на обмеженість часу. Досить часто обмежуюсь просто переліком процесів і юзкейсів в текстовому вигляді або простими блоксхемами.

Хороша і структурована стаття, дякую!

Підписатись на коментарі