Борис Романов

Роль аналитика
в разработке сложных информационных систем

Введение

Создание больших сложных информационных систем (ИС) — это долгий, дорогой и часто непростой процесс. Иногда бывает так, что потрачено очень много денег, сил и времени, а система всё равно делает не то, что нужно. В этой статье расскажем, как аналитик может помочь избежать этого, а также:
  • в чём основная проблема при разработке сложных информационных систем;
  • какие аналитические модели и зачем нужно применять в процессе разработки;
  • как и с помощью каких инструментов разрабатывать аналитические модели.

Статья будет полезна системным и бизнес-аналитикам, а также проектным и продуктовым менеджерам, которые хотят выстроить последовательный процесс разработки систем через аналитические модели.
Проблематика разработки
сложных систем
При разработке больших и сложных ИС вы неизбежно наткнётесь на:
  • стейкхолдеров с разными целями;
  • много интеграций;
  • сложную логика взаимодействия между компонентами и смежными системами;
  • запутанные процессы.

Главная сложность — столкновение интересов. Каждый, кто участвует в проекте, хочет «сделать хорошо», но смотрит на задачу чаще всего только со своей точки зрения.

Для разработчика «хорошо» — это красивый код и технологичный стек, для менеджера — соблюдение сроков и бюджетов, дизайнер хочет сделать красиво и «юзерфрендли», бизнесу нужна прибыль, а пользователь хочет использовать удобную систему, желательно бесплатно.
Рис.1 — У всех в процессе разработки своя перспектива рассмотрения задачи
Разные ценности участников процесса неизбежно вызывают конфликты. Нерешённые конфликты могут приводить к проблемам, решение которых требует времени и ресурсов.

Если проблема не решается вовремя, то возникают «пожары» и необходимость их «тушить».

Что же делать? Стараться предупреждать потенциальные конфликты и проблемы до их возникновения, организовать процесс так, чтобы важные проблемы подсвечивались до их возникновения. Тогда о путях решения этих проблем можно будет эффективно договариваться. В этом может помочь применение аналитических моделей и представлений, в которых отражаются разные точки зрения на системы и интересы разных стейкхолдеров.

Роль аналитика
в создании сложных систем

Модель — это упрощённое представление объектов реального мира, отображающее свойства этого объекта, важные в контексте решаемой задачи.

Анализ — это исследование через выделение и изучение отдельных частей объекта анализа.

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

Важные точки зрения
на информационную систему

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

При этом нужно учитывать:
  1. Надсистему, в которую встроится разрабатываемая система, и её проблемы.
  2. Саму систему, окружающие её системы, пользователей и других стейкхолдеров.
  3. Состав, внутреннюю структуру системы в разных разрезах.
Основные способы декомпозиции:
a. Функциональная структура системы — с точки зрения набора
функций системы и отношений между ними.
b. Композитная структура системы — с точки зрения набора
конструктивных элементов (сервисов, модулей), из которых
собирается система.

4.Структура поставок системы — инкременты из решённых задач, поставляемых конечным пользователям.
Рис.3 — Аспекты рассмотрения информационной системы

Какие модели нужны
для разработки системы

Набор нужных для разработки аналитических моделей напрямую связан с перечнем вопросов, на которые нужно ответить в этом процессе.
  1. Какие внешние проблемы будет решать система?
  2. Какие пользовательские сценарии должны быть для этого реализованы?
  3. Какое поведение должно быть реализовано в системе?
  4. Что и как нужно изменить в уже существующем решении?
Рис.4 — Набор связанных аналитических моделей для разработки систем

Моделирование сценариев

Что такое моделирование сценариев
и для чего оно нужно
Моделирование сценариев направлено на выявление и перечисление основных кейсов использования системы, её возможностей, которые решают проблемы пользователей. Сценарии должны содержать не описание работы системы и способы реализации, а то, что пользователи будут делать в ней. То есть моделирование сценариев — это моделирование изменений действительности, которая окружает систему.

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

Моделирование сценариев несёт в себе много возможностей.
  1. Снижает риски забыть или пропустить важные возможности системы.
  2. Помогает заранее договориться о возможностях, которые нужно реализовать, и заложить соответствующие архитектурные и другие ограничения.
  3. Помогает заранее договориться о сценариях, которые НЕ будут реализованы.
  4. Упрощает управление проектом, планирование и проведение приемо-сдаточных испытаний, написание документации.

На выходе этого этапа должен быть набор сценариев и их взаимосвязей полный настолько, чтобы складывалась полная картина взаимодействия пользователя с системой. Модель должна содержать набор сценариев, который имеет смысл поставлять целиком.
Инструментарий
Для оформления модели сценариев можно использовать разные техники и инструменты.

Классическая и самая популярная техника — диаграмма вариантов использования (Use Case Diagram) нотации UML. Инструментов для неё существует очень много. Можно использовать Visual Paradigm, PlantUML, Enterprise Architect, даже draw.io.

Не такая популярная, но тоже интересная техника — использовать уровень бизнеса и уровень мотивации нотации Archimate.

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

Описание проблемы. У жителя умного здания есть проблема: ему нужно выходить к пункту пропуска и показывать пропуск при въезде во двор. Он хочет не выходить из машины, а хочет попадать во двор бесконтактно.

Потенциальное решение. Открывать шлагбаум автоматически, если в машине есть бесконтактный пропуск.
Рис.5 — Потенциальное решение проблемы
Эта модель на самом деле не достаточна для реализации, потому что игнорирует вопросы безопасности и требования нормативно-правовых актов, эти вопросы неизбежно возникнут в процессе обсуждения этой диаграммы со стейкхолдерами.

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

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

Сущности модели предметной области должны отражаться на всех уровнях моделирования и разработки системы: и сценарии использования и программный код должны оперировать одинаковыми бизнес-понятиями.
Инструментарий
Модель предметной области можно представить по-разному.
  1. Текст.
  2. Табличное представление
  3. Диаграмма классов (Class Diagram) нотации UML.
  4. Archimate.
  5. ER-диаграмма. Стоит использовать аккуратно, потому что есть сильная привязка к структуре базы данных.
  6. GraphQL как язык запросов. Удобен для описания сущностей и атрибутов предметной области.
Пример
Пример модели предметной области по нашей проблеме проезда во двор умного здания в виде диаграммы классов.
Рис.7 — Модель поведения предметной области в виде диаграммы классов
Такая диаграмма отражает все сущности нашей предметной области и связи между ними. Модель позволяет сформировать единый глоссарий и понимание физического смысла сущностей.
Моделирование полезных
инкрементов системы
Что такое моделирование инкрементов
и зачем оно нужно
Моделирование инкрементов направлено на фиксацию этапов разработки системы: в какой очередности реализуется функциональность системы. Трудно разработать с нуля систему сразу сложной, необходимо начинать с самой важной функциональности, а затем наращивать её и улучшать.

Моделирование инкрементов позволяет:
  • структурировать порядок поставки новой функциональности;
  • приоритизировать работу и сконцентрироваться на наиболее важной функциональности;
  • договориться о составах поставок функциональности с Заказчиком
Инструментарий
Одна из самых удобных техник — User Story Mapping. Карту историй можно построить в Miro, draw.io и даже стикерами на доске.
Пример
Вернёмся к нашему примеру с бесконтактным въездом во двор. Выделим MVP с минимальными возможностями:
  • даём возможность охранникам выдавать пропуска вручную;
  • настраиваем СКУД (система, которая открывает шлагбаум) так, что шлагбаум открывается при подъезде авто с бесконтактным пропуском;
  • предоставляем охранникам возможность просматривать списки пропусков и вручную их блокировать.
Рис.8 — User Story Map для примера с бесконтактным въездом во двор
Так наши пользователи могут быстро получить минимально нужный объём функциональности и могут начинать пользоваться бесконтактным въездом.

В рамках следующих релизов мы можем улучшать систему: реализовать самостоятельную регистрацию жителями дома, распознавание номеров, автоматическую блокировку пропусков и т.д.
Моделирование поведения системы
Что такое моделирование поведения
и зачем оно нужно
Моделирование поведения направлено на определение того, как система будет функционировать и как именно будут реализованы сценарии работы пользователей. Для этого необходимо выявить:
  • входящие и исходящие информационные потоки: какая информация и откуда поступает В систему, какая информация и куда передаётся ИЗ системы;
  • порты/интерфейсы: точки взаимодействия с внешним миром и другими системами (API, пользовательский интерфейсы, брокеры сообщений, шины и т.д.)
  • ключевые функции системы: что именно система делает, за что отвечает, чего ждать от системы и чего не ждать.
Рис.9 — Состав модели поведения системы
Моделирование поведения системы позволяет:
  • убедиться, что система в принципе реализуема и нужная для её работы информация доступна;
  • определиться с кем/чем и в каких случаях нужно интегрироваться;
  • выявить объекты внимания, которые требуют дальнейшего детального проектирования и спецификации;
  • верхнеуровнево оценить сложность создания системы.
Инструментарий
Для моделирования поведения системы существует огромное количество инструментов и техник.
  1. Диаграммы нотации UML: диаграмм последовательности, диаграмма деятельности, диаграмма состояний. В качестве инструмента — любой удобный вам для нотации UML.
  2. Диаграмма активности нотации SysUML.
  3. Archimate.
  4. Нотация C4.
  5. Event Storming.
  6. BPMN.
  7. Фиксация без нотации в формате “квадратики и стрелочки”.
Пример
Можно смоделировать наш пример с бесконтактным въездом во двор в нотации Archimate.
Рис.10 — Модель поведения системы бесконтактного въезда в нотации Archimate
На модели отражены:
  1. Интерфейсы взаимодействия системы с пользователями и другими системами:
a. охранник взаимодействует с системой через UI;
b. сама система взаимодействует со СКУД, которая управляет шлагбаумом, через API.

2. Информационные потоки в системе: данные пропусков, события прохода, вызовы различных команд.
3. Функциональность системы: управление пропусками, обогащение событий данными о владельцах, предоставление опций выдачи пропусков и просмотра журнала событий.
Как применять аналитические модели
в процессе разработки
При разработке системы с нуля работа над аналитическими моделями может идти в таком порядке:
  1. Моделирование сценариев. Договориться с Заказчиком о границах проекта и сценариях работы. Параллельно — моделирование предметной области. Пригодится для формулировки требований к поведению.
  2. Моделирование полезных инкрементов. Сформировать набор функциональности для MVP.
  3. Моделирование поведения системы. Описать функциональность и правила работы системы.
Рис.11 — Процесс моделирования и разработки MVP
При развитии уже существующей системы работа над аналитическими моделями входит в цикл.
Рис.12 — Непрерывное развитие системы через моделирование
Доработка системы обязательно должна проходить через модификацию аналитических моделей. Изменения в моделях позволяют предварительно оценивать сложность доработки.
Экспресс-оценка изменений
через аналитические модели
Сложность и стоимость вносимых изменений во многом зависит от вида этих изменений. С помощью аналитических моделей можно определить вид предстоящих изменений.

  1. Количественные изменения — развитие уже существующих функций системы (улучшения, повышение удобства использования). Пример: добавление атрибутов сущности, улучшение UI без изменения бизнес-модели.
a. изменения предсказуемы по срокам и ресурсам;
b. меньше рисков.

2. Качественные изменения — придание системе принципиально новых качеств за счёт новых компонентов или архитектурных решения. Пример: добавление нового бизнес-процесса.
a. долгая реализация;
b. стоимость может быть высокой;
c. есть риски.

Качественные изменения в систему вносить намного сложнее, чем количественные. Но без развития, внедрения новых функций система будет стагнировать. Здесь кроется польза аналитических моделей для менеджмента: с помощью моделей можно оценивать изменения и балансировать между качественными и количественными изменениями.
Резюме
  1. Главная проблема при разработке сложных информационных систем — конфликты заинтересованных лиц на стыке их интересов. Среди таких конфликтов потенциальные проблемы могут оставаться незамеченными вплоть до критической точки.
  2. Разработка связанного набора аналитических моделей, в которых бы учитывались интересы всех заинтересованных лиц, эффективна для качественных коммуникаций и своевременного обнаружения потенциальных проблем.
  3. Роль аналитика в этом процессе — создание и поддержка в актуальном состоянии аналитических моделей.
  4. Аналитические модели, которые могут быть разработаны аналитиком:
a. модель сценариев;
b. модель полезных инкрементов
c. модель предметной области;
d. модель поведения системы.

5. Инструментарий и подходы аналитического моделирования не так важны. Используйте те инструменты, которыми владеете лучше всего. Главное, чтобы модель содержала корректную информацию.
Шпаргалка
по аналитическим моделям
Об авторе