Почему требования к бизнес и системному аналитику пересекаются. Часть 2

В прошлый раз мы рассмотрели 2 пункта из 4-х почему в описании вакансий требования к бизнес и системным аналитикам пересекаются. Продолжаем наш разбор:

При описании это пункта я буду неоригинально использовать термины «Библия аналитика». Пожалуй, не сильно ошибусь, если скажу, что BABOK принято считать «библией» бизнес-аналитика, а книгу Вигерса и Битти «Спецификация требований к ПО» - «библией» системного аналитика. А любой уважающий себя аналитик старше 40 хорошо знает и умеет писать по ГОСТ 34 и 19.

На первый взгляд кажется, что эти «руководства» предназначены для разной аудитории читателей, а кто-то даже вспомнит, что ГОСТы носят рекомендательный характер и могут считаться морально устаревшими.

Позволю себе немного отвлечься и расскажу историю. Однажды руководитель проекта, на котором я выступала в роли аналитика, просил меня разобраться в каком-то процессе, который не был связан с проектом, аргументируя свою просьбу словами «ну ты же аналитик». Конечно он имел ввиду, что при наличии большого опыта работы аналитиком мне будет не сложно заняться и этой смежной (нецелевой) работой и фактически просил помощи. Обдумав ситуацию, я пришла к выводу, что аналитик это не должность, не профессия, это мироощущение. Хэштег #нутыжаналитик с тех пор со мной. К чему это я? А вот к чему:

Прочтите все три «руководства», найдите общие моменты – они будут. Найдите лучшие советы, которые начнете применять в работе и в ежедневной жизни. Потратьте время на ГОСТы, подумайте, зачем они могут пригодиться и как вплести их в "модные" западные системы рекомендаций. Составьте свою систему рекомендаций и начните ей следовать.

Уже скоро в отдельной статье я расскажу какая система сформировалась у меня и как я применяю ее в ежедневной работе уже достаточно давно и в разных компаниях.

За 20 лет в профессии я не встречала информационных систем, которые не использовали бы реляционные базы данных. Возможно такие системы существуют, но это скорее исключение, чем правило.

Реляционные базы данных основаны на реляционной модели — интуитивно понятном, наглядном табличном способе представления данных. Каждая строка, содержащая в таблице такой базы данных, представляет собой запись с уникальным идентификатором, который называют ключом. Столбцы таблицы это атрибуты данных, а каждая запись обычно содержит значение для каждого атрибута, что дает возможность легко устанавливать взаимосвязь между элементами данных.

Поэтому, выбирая профессию аналитика, примите, что работать с реляционными базами данных вам придется. Чтобы определиться на каком уровне с ними работают бизнес-аналитики, а на каком системные, немного отвлечемся на термины.

Сущность — это понятия/термины в бизнес-среде, о которых мы хотим хранить данные, например, клиенты, обращения и т.д.

Атрибуты – данные, которые нужны для описания сущностей. Например, для сущности клиент атрибутами будут – Имя, Фамилия, номер телефона. Для сущности обращение атрибутами будут – дата и время обращения, автор обращения, тема обращения, текст обращения.

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

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

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

Физическая модель данных включает в себя все необходимые таблицы, столбцы, связи, свойства базы данных для физической реализации баз данных. Производительность базы данных, стратегия индексации, физическое хранилище и денормализация — важные параметры физической модели.

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

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

Бизнес-аналитик должен продумать как пользователь будет вводить данные о новой книге в системе. Для сокращения количества ошибок ручного ввода (Пцшкин вместо Пушкин) выбор автора лучше сделать в виде выпадающего списка. А значит нам нужен справочник авторов, который будет подгружаться в эту выпадашку. Автор – первая сущность, книга – вторая сущность. Так же бизнес аналитик должен продумать какой вариант связи между сущностями нам нужен и почему. Правильный ответ вы увидите на схемах, но подумайте почему выбран именно этот тип связи? Напишите свои варианты ответа в комментариях к статье или в обсуждении этой статьи в Телеграм-канале.

ER-диаграмма концептуальной модели данных может представлять собой единственный квадратик с надписью «Книги» при поверхностной проработке, либо при более глубокой проработке будет выглядеть следующим образом:

ER-диаграмма логической модели данных должна уже содержать список параметров для каждой сущности и значит выглядит так:

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

На основе такой схемы и описания системный аналитик (иногда эту работу выполняют аналитики БД или разработчики) создаст физическую модель данных. ER-диаграмма физической модели приведена на следующем рисунке:

Из двух элементов логической модели образовались три таблицы БД, т.к. связь многие ко многим в БД реализуется за счет дополнительной таблицы, называемой сводной таблицей (join table) или таблицей-связкой (junction table).

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

Как делят между собой работу бизнес-аналитики и системные аналитики при проектировании БД мы немного разобрались. Теперь перейдем к моменту, когда разработка завершена и идет тестирование системы, либо когда система передана заказчику и находится на сопровождении.

В этом случае могут возникать ситуации, когда аналитику необходимо подключиться к разбору бага или инцидента и для разбора необходимо посмотреть какие данные используются, оценить их валидность, а тут понадобится SQL. Бизнес-аналитику достаточно простых select-ов, системному аналитику понадобится знание SQL на продвинутом уровне. В некоторых командах роль аналитика БД не выделяется и все задачи по проектированию баз, по разбору инцидентов, по составлению скриптов на доработку БД, разработку хранимых процедур и индексацию решает системный аналитик.

Завтра продолжим и поговорим про full-stack аналитику, обсудим плюсы и минусы совмещения ролей.