Первые шаги в онтологию (разработка ПО)

Посты студентов Рациональная работа
1

Идея

Мне видится, что первое улучшение, которое можно привнести в мою компанию это синхронизация моделей мира коллег через описание онтологии, единого языка по DDD.

Начну с пропитки, наведения внимания на проблемы и возможные перспективы. То есть пока просто обсудить, поговорить, обменяться мнениями.

План минимум: Создать документ с онтологией нашей предметной области для себя. Уточнять его, находить противоречия в моделях коллег и разрешать их.
План максимум: Создать документ с онтологией нашей предметной области для всех. Встроить практику, как норму, в компанию.

Контекст

Вероятно Мета-У-Модель будет взята из фреймворка TOGAF, потому что он уже внедрен в нашу компанию. Мета-мета-модель беру из системного подхода МИМ, для корректировки коллег.

Понятия первого шага пропитки

Пропитку на первом шаге буду делать по понятиям:

  • Индивид, Понятие, Термин
  • Тип, Отношение
  • Модель, Мета-модель, Домен

Идея разогревающих вопросов

Есть идея, провести небольшой опрос, который будет доказывать, что модели коллег в компании сейчас не синхронизированы, а значит может привести к проблемам с нашими системами или к замедлению коммуникации. Вопросы закрытого типа, которые подразумевают ответ Да или Нет.

Вопросы

  • Команда разработки провела онлайн-конференцию, на которой были озвучены требования к фиче. Являются ли озвученные требования описаниям будущей фичи?
  • Системный аналитик создал BPMN-диаграмму процесса формирования заключения и разместил ее в wiki. Является ли эта BPMN-диаграмма бизнес-процессом?
  • Менеджер продукта разместил в wiki описание инициативы, где написал, что по нажатию кнопки получить промокод система должна отправлять смс с промокодом на номер телефона пользователя. Является ли это описание бизнес-требованиями?
  • Когда пользователь болеет простудой, тогда он может запланировать в системе запись к терапевту. Является ли это высказывание критерием приемки фичи?
  • Когда пользователь нажимает кнопку записаться к конкретному врачу, тогда ему показывается список временных слотов для записи к этому врачу. Является ли это высказывание критерием приемки фичи?
2

А вы понимаете, что единый язык и онтологию нужно делать для предметной области и это область не разработка ПО? У вас там что-то из медицины/здравоохранения вроде как.

Давайте так. Общее понимание важно, но это как раз чаще про единый язык и язык этот бизнесовый. Но ещё важнее - заземление.

Подумайте какое тут можно сделать заземление. Как проверить, что если фичу сделать по описанию, у живого человека в реальном мире изменится что-то, что принесёт ему ожидаемую пользу?

Описанием бизнес процесса. И снова как это заземлить?

Вы use case/сценарии использования не пишите? Как будто вопрос об этом. И снова “как заземлить”. Что делает реальный человек в реальном мире, что меняется. Для чего ему промокод?

Общие высказывания критерием приёмки фичи не являются. Пишите подробный Definition of Done и снова заземляете. То что человек может понажимать на кнопки в вашем приложении и увидеть на экране какую-то информацию не значит, что фичу можно принять. Что в реальном мире должно измениться…

Тоже самое. Слоты на экране это не фича. Как и еда, которую вы можете выбрать в доставке, а съесть не сможете)

1 лайк
3

Я думаю что онтологию нужно делать как минимум для двух доменов - домен создателей и домен в котором работает наша система. Я хочу начать с создателей, потому что это для меня сейчас проще и думаю будет полезнее, а потом уже на базе этого языка описать и язык предментой области нашей системы. Я бы сказал, что это реверс инжиниринг.

Я не могу сказать, что понял замечаний по заземлению и по проверочным вопросам. Проверочные вопросы они нужны лишь для того, чтобы продемонстрировать, что у нас разное понимание понятий, которые мы используем.