Берём в работу новую задачу или проект. Начинаем со сбора бизнес-требований. Затем переходим к проработке функциональных и нефункциональных требований. Потом архитектура системы и влияние требований на нее, БД, API, интеграции. И вот, в процессе разработки выясняется, что в требованиях опять что-то не учли. Что может быть хуже?
Может, коллеги! Когда через пол года вам же приходится возвращаться к задаче и вы понимаете, что требования к развитию системы по словам разработчиков нереализуемы. Или реализуемы, но они кривят лица: мы этого не ожидали, проще всё с нуля переделать, либо "костылями подопрем".
Меня, как начинающего системного аналитика, это выводило из себя. Как так?! Элементарная же задача! А потом мне показывают БД. И тут я всё понимаю. Да, действительно, пришло время делать выбор: дорого переделывать или "костыли" подойдут.
Один раз столкнувшись с такой ситуацией, больше не хочется оставлять без внимания базу данных. Даже если проектирование БД в компании находится в зоне ответственности разработчиков.
В этой статье:
1. Рассмотрим ситуацию с хранением ФИО в системе.
Изначально было решено хранить ФИО одной строкой.
Прошло время. Появилась необходимость интегрироваться с системами электронного документооборота (ЭДО), в которых по единому информционному протоколу это всегда три отдельных поля: имя, отчество и фамилия.
Кажется, что всё просто. Но нет.
Это простое изменение породило множество сложностей:
2. Еще один пример - думали, что у машины может быть только один владелец в автосервисе.
Проблемы со связями в базах данных. Сначала была связь "один ко многим", где у одной машины был один владелец, и у одного владельца много машин. Но со временем эксплуатации системы в продакшн оказалось нормальной ситуацией, что иногда два человека приезжают обслуживать одну машину. Иногда даже три.
Структура БД меняется: для правильного поддержания процесса нужна связь "многие ко многим". И в одну задачу это изменение не сделать.
Важно проработать цепочку задач, которые обеспечат совместимые изменения. Если хорошо не продумать порядок перехода к новой структуре хранения данных, то можно встретить огромное количество ошибок по функциональности всей системы, так как машина и клиент главные сущности в системе автосервиса.
Простые изменения и требования? Да, если подумать логически, на верхнем уровне. Но из-за того, что "под капотом" системы огромный мир данных и механизмов по их хранению, получению и обработке, то иногда мы попадаем на серьезные работы по развитию.
Так и получается, что мы с разработчиками садимся обсуждать: проще сделать "костыли" или лучше переделать с нуля сейчас, чтобы через год опять не пожалеть о принятом решении.
Важно учиться искать баланс и на старте работ найти грань: не допустить овер-инжиниринга, и при этом сделать модель БД гибкой. Это нужно постигать.
Каждое действие, каждый клик — это запрос к базе данных. И в этой базе данных хранятся сведения, которые предстоит собирать и обрабатывать, чтобы обеспечиать выполнение бизнес-процессов и функций в ней.
Базовые определения и примеры, прежде чем читать далее
Сущности — реальные объекты этого мира. Например: стол, стул, машина, тарелка, цветок и другие.
Свойства (атрибуты) — характеристики сущностей, которые для каждого из объектов сущностей могут быть уникальны.
Например:- машина - сущность.- Tesla Model X 2023 г., Porsche 911 2023 г., Toyota Camry 2022 - конкретные объекты сущности "машина". - цвет, производитель, модель, год, объем двигателя - свойства (атрибуты) сущности "машина".
ER-диаграмма (Entity-Relationship) — графическое представление сущностей БД и связей. Нотация моделирования баз данных.
Мне в этом плане особенно нравится устаревшая нотация моделирования IDEF0, потому что она не только отражает все шаги процесса, но и показывает какие входные и выходные данные нужны для реализации каждого их них.
В результате прочтения требований к медицинской системе, получаю список сущностей и свойств - основа для логической модели БД.
Прежде чем смотреть что получилось, попробуйте сами быстро выделить список сущностей и свойств. Совпадём?
Сущности и свойства медицинской информационной системы на основе описания процесса записи на прием к врачу
Этот пример подхода был для проекта с нуля. Также можно работать с существующей базой данных в вашем проекте и смотреть, как новые требования повлияют на неё, какие задачи по её изменению поставите на разработчиков.
Этот подход помогает не упускать из требований важные детали, и до передачи работ разработчикам сразу же собрать полные требования по системе, а иногда даже увидеть противоречивые.
Результат:
habr.com
Может, коллеги! Когда через пол года вам же приходится возвращаться к задаче и вы понимаете, что требования к развитию системы по словам разработчиков нереализуемы. Или реализуемы, но они кривят лица: мы этого не ожидали, проще всё с нуля переделать, либо "костылями подопрем".
Меня, как начинающего системного аналитика, это выводило из себя. Как так?! Элементарная же задача! А потом мне показывают БД. И тут я всё понимаю. Да, действительно, пришло время делать выбор: дорого переделывать или "костыли" подойдут.
Один раз столкнувшись с такой ситуацией, больше не хочется оставлять без внимания базу данных. Даже если проектирование БД в компании находится в зоне ответственности разработчиков.
В этой статье:
- Как в разработке систем возникают ситуации "костыли" или "переделываем", и почему обычно это связано с непродуманной структурой БД.
- Как проектирование БД на ранних стадиях работы с проектом влияет на качество требований.
- Дам пошаговый план проектирования БД.
- SQL-запросы: почему нужно уметь читать.
"Костылями" подпираем или переделываем?
Главное отличие системного аналитика от других участников проекта заключается в его способности смотреть широко. Работая над конкретной задачей, аналитик видит не только её, но и весь проект в целом, как он функционирует сейчас и как будет развиваться в будущем. |
Изначально было решено хранить ФИО одной строкой.
Прошло время. Появилась необходимость интегрироваться с системами электронного документооборота (ЭДО), в которых по единому информционному протоколу это всегда три отдельных поля: имя, отчество и фамилия.
Кажется, что всё просто. Но нет.
Это простое изменение породило множество сложностей:
- Создание алгоритма деления строки на части, который не для всех случаев с отчеством "Гаджи оглы" хорошо отработают.
- Модификация API-методов. Минимум 1, максимум - все, если данные ФИО этой роли в системе везде.
- Изменение пользовательского интерфейса (UI) всех мобильных и веб-приложений, где есть ФИО, и доработка взаимодействия по API с сервером.
- Доработка существующих интеграций.
2. Еще один пример - думали, что у машины может быть только один владелец в автосервисе.
Проблемы со связями в базах данных. Сначала была связь "один ко многим", где у одной машины был один владелец, и у одного владельца много машин. Но со временем эксплуатации системы в продакшн оказалось нормальной ситуацией, что иногда два человека приезжают обслуживать одну машину. Иногда даже три.
Структура БД меняется: для правильного поддержания процесса нужна связь "многие ко многим". И в одну задачу это изменение не сделать.
Важно проработать цепочку задач, которые обеспечат совместимые изменения. Если хорошо не продумать порядок перехода к новой структуре хранения данных, то можно встретить огромное количество ошибок по функциональности всей системы, так как машина и клиент главные сущности в системе автосервиса.
Простые изменения и требования? Да, если подумать логически, на верхнем уровне. Но из-за того, что "под капотом" системы огромный мир данных и механизмов по их хранению, получению и обработке, то иногда мы попадаем на серьезные работы по развитию.
Так и получается, что мы с разработчиками садимся обсуждать: проще сделать "костыли" или лучше переделать с нуля сейчас, чтобы через год опять не пожалеть о принятом решении.
Важно учиться искать баланс и на старте работ найти грань: не допустить овер-инжиниринга, и при этом сделать модель БД гибкой. Это нужно постигать.
База данных - фундамент системы
БД — это фундамент системы, который влияет на реализацию всех требований. Все бизнес-процессы и функции сводятся к одному – обработке данных.Каждое действие, каждый клик — это запрос к базе данных. И в этой базе данных хранятся сведения, которые предстоит собирать и обрабатывать, чтобы обеспечиать выполнение бизнес-процессов и функций в ней.
Базовые определения и примеры, прежде чем читать далее
Сущности — реальные объекты этого мира. Например: стол, стул, машина, тарелка, цветок и другие.
Свойства (атрибуты) — характеристики сущностей, которые для каждого из объектов сущностей могут быть уникальны.
Например:- машина - сущность.- Tesla Model X 2023 г., Porsche 911 2023 г., Toyota Camry 2022 - конкретные объекты сущности "машина". - цвет, производитель, модель, год, объем двигателя - свойства (атрибуты) сущности "машина".
ER-диаграмма (Entity-Relationship) — графическое представление сущностей БД и связей. Нотация моделирования баз данных.
Пример про медицинскую систему
Рассмотрим медицинскую информационную систему для частной поликлиники.- Пациент хочет сделать запись на прием онлайн: система отображает пациенту данные о доступных услугах, врачей и время для записи.
- Пациент записывается на прием: система обрабатывает информацию о пациенте, докторе, времени приема, кабинете.
- Регистратура звонит пациенту и подтверждает запись на прием: система меняет в базе данных статус записи с "новая" на "подтверждена".
- Когда пациент приходит на прием, то в регистратуре делают отметку о том, что пациент ожидает - опять смена статуса.
- И это только начало! Процессов в поликлинике много, особенно связанных с приемом пациента
Мне в этом плане особенно нравится устаревшая нотация моделирования IDEF0, потому что она не только отражает все шаги процесса, но и показывает какие входные и выходные данные нужны для реализации каждого их них.
В результате прочтения требований к медицинской системе, получаю список сущностей и свойств - основа для логической модели БД.
Прежде чем смотреть что получилось, попробуйте сами быстро выделить список сущностей и свойств. Совпадём?
Сущности и свойства медицинской информационной системы на основе описания процесса записи на прием к врачу
Проверка требований на полноту и непротиворечивость с помощью проектирования БД
Заметили, что в тексте я выделила жирным отдельные слова? Это я, каждый раз работая с требованиями, повторяю одну и ту же процедуру:- Выделяю слова в тексте, обычно двумя цветами: сущности и их свойства.
- Т.к. я за ускорение процесса, то выделяю слова мысленно и сразу же начинаю строить ER-модель базы данных на логическом уровне: создаю список таблиц (сущностей в базе данных) и добавляю в них свойства.
- После того, как таблицы созданы, проверяю, всё ли логично и всего ли хватает.
Обычно, в процессе такой проверки, я понимаю, что половина данных в описании бизнес-процесса упущена, т.к. в их описании такой уровень детализации не требовался.
Глядя на список таблиц, дополняю их свойствами на основе вопросов к Google, ChatGPT с 2023 года и жизненного опыта. Всё, что вызывает вопросы, выношу на обсуждение с владельцем IT-продукта (заказчиком) о хранении информации про его бизнес сущности. - Теперь можно строить связи и проставлять кратности (полезная картинка по кратностям). Т.к. требования я уже написала и прочитала (и выучила), то делаю это интуитивно.
Если вы будете пользоваться моей стратегией, то лучше читать требования еще раз и проставлять связи. - На ER-диаграмме ищу связи "многие-ко-многим" и убираю их. Дополняю БД внешними ключами, где их нет. Довожу до состояния полноценной логической модели данных, иногда даже сразу до физической.
- Тестирую требования: беру каждую функцию в системе и проверяю, как она будет работать с моей базой данных на запись и получение данных.
Если я могу простыми словами объяснить разработчику в какие таблицы писать данные или из каких забирать, то всё хорошо. А если нет, то плохо. - Проверяю масштабируемость: смотрю на список запланированных задач на следующих этап разработки или придумываю потенциально возможные сценарии к реализации. Здесь важно не фантазировать о чём-то невозможном, а продумать, что в ближайшие 3-5 лет работы системы вообще возможно по функциональности и в целом может уже работает в отрасли в других системах, у конкурентов.
Не всегда можно всё предугадать, но как правило, эта проверка на потенциальное будущее поднимает новые вопросы на обсуждение с владельцем IT-продукта (заказчиком) о потенциальном развитии проекта.
Что получилось после чтения требований? Логическая модель базы данных, связанной с задачей. На её основе ставлю задачи на разработчиков Backend, а также разработчикам мобильных и десктоп приложений, когда нужно сделать локальную базу данных, например, на SQLite.Системный аналитик должен смотреть на систему в трех измерениях:
- как работает сейчас (AS IS),
- что просят сделать (текущие требования на разработку),
- во что это может перерасти в будущем (потенциальное развитие).
Это поможет сделать разработку качественной.
Екатерина Ананьева
Этот пример подхода был для проекта с нуля. Также можно работать с существующей базой данных в вашем проекте и смотреть, как новые требования повлияют на неё, какие задачи по её изменению поставите на разработчиков.
Этот подход помогает не упускать из требований важные детали, и до передачи работ разработчикам сразу же собрать полные требования по системе, а иногда даже увидеть противоречивые.
Результат:
- требования полные,
- меньше вопросов от разработчиков,
- система масштабируема и спроектирована с учетом потенциального развития.
Пошаговый план проектирования БД
- После завершения работы над описанием бизнес-процессов или требований, прочесть их и выделить по тексту список сущностей (таблиц БД) и свойств (полей таблиц).
- Спроектировать логическую модель данных - ER-диаграмма:
- таблицы (сущности),
- поля (свойства),
- связи между таблицами,
- кратности связей между таблицами.
- Связи типа "многие-ко-многим" убрать.
*Дополнительно, перед логической, можно сделать концептуальную, но она не всегда имеет практическую ценность.
- Прочесть требования еще раз и проверить, что всех данных хватает.
Недостающие данные дополнить на основе Google, ChatGPT, доступных документов и вопросов заказчику. - Дополнить логическую модель требованиями к типам данных, обязательности, уникальности, значениям по умолчанию и индексам свойств таблиц. Получена физическая модель БД.
- Ставить задачи на разработчиков по их созданию, выстраивая последовательность и зависимости. Часто задачи можно делать параллельно нескольким разработчикам.
SQL для системных аналитиков
Для системного аналитика, владение SQL не просто "буквы для резюме", это ключевой навык, который:- Усиливает логическое мышление.
SQL требует строгого и последовательного подхода к структурированию данных. Такой подход улучшает логические навыки, что в свою очередь помогает быстрее и точнее анализировать требования. - Позволяет понимать язык разработчиков и что "под капотом" системы.
Когда аналитик знает, как устроена база данных, он может разрабатывать требования, учитывающие эту структуру, что уменьшает количество ошибок и доработок в дальнейшем. То же, что и с умением проектировать БД. - Помогает обращать внимание на "узкие места" в системе, где важно продумать нефункциональные требования по нагрузке, ограничения.
Понимая, как устроен запрос и какие ресурсы он потребляет, можно заранее предусмотреть необходимые ограничения. - Позволяет с ходу оценивать реализуемость требований.
Зная SQL, аналитик может сразу определить, насколько реализуемы требования, которые предлагает заказчик, и как они повлияют на производительность и структуру БД.
Заключение
Навык проектирования БД и понимание SQL-запросов выводит качество требований и постановок задач от аналитика на новый уровень. С его знанием аналитик точно осознает к каким техническим задачам ведет очередное бизнесовое требование. Кстати, для менеджеров проектов это тоже полезно.
Проектирование БД и почему важен SQL для системного аналитика: гайд по улучшению качества требований
Берём в работу новую задачу или проект. Начинаем со сбора бизнес-требований. Затем переходим к проработке функциональных и нефункциональных требований. Потом архитектура системы и влияние требований...
habr.com