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

Введение

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

• в чём основная проблема при разработке сложных информационных систем;

• какие аналитические модели и зачем нужно применять в процессе разработки;

• как и с помощью каких инструментов разрабатывать аналитические модели. 

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

Проблематика разработки сложных систем

При разработке больших и сложных ИС, вы неизбежно наткнетесь на:

• много стейкхолдеров с разными целями;

• много интеграций;

• сложная логика взаимодействия между компонентами и смежными системами;

• запутанные процессы.

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

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

Рис. 1 — У всех в процессе разработки своя перспектива рассмотрения задачи

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

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

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

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

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

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

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

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

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

Рис. 2 — Системы разрабатывают, чтобы повлиять на окружающую реальность

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

При этом нужно учитывать:

1. Надсистему, в которую встроится разрабатываемая система, и её проблемы.

2. Саму систему, окружающие её системы, пользователей и других стейкхолдеров.

3. Состав, внутреннюю структуру системы в разных разрезах.
   Основные способы декомпозиции:

   1. Функциональная структура системы — с точки зрения набора функций системы и отношений между ними. 

   2. Композитная структура системы — с точки зрения набора конструктивных элементов (сервисов, модулей), из которых собирается система. 

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

Рис. 3 — Аспекты рассмотрения информационной системы

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

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

1. Какие внешние проблемы будет решать система?  

2. Какие пользовательские сценарии должны быть для этого реализованы?  

3. Какое поведение должно быть реализовано в системе?

4. Что и как нужно изменить в уже существующем решении?

Рис. 4 — Набор связанных аналитических моделей для разработки систем

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

Что такое моделирование сценариев и для чего оно нужно

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

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

Моделирование сценариев несёт в себе много возможностей.

1. Снижает риски забыть или пропустить важные возможности системы.

2. Помогает заранее договориться о возможностях, которые нужно реализовать, и заложить соответствующие архитектурные и другие ограничения.

3. Помогает заранее договориться о сценариях, которые НЕ будут реализованы.

4. Упрощает управление проектом, планирование и проведение приемо-сдаточных испытаний, написание документации. 

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

Инструментарий

Для оформления модели сценариев можно использовать разные техники и инструменты. 

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

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

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

Пример

Пример из области умных зданий.

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

Потенциальное решение. Открывать шлагбаум автоматически, если в машине есть бесконтактный пропуск.

Рис. 5 — Потенциальное решение проблемы

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

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

Рис. 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. Интерфейсы взаимодействия системы с пользователями и другими системами:

   1. охранник взаимодействует с системой через UI;

   2. сама система взаимодействует со СКУД, которая управляет шлагбаумом, через API. 

2. Информационные потоки в системе: данные пропусков, события прохода, вызовы различных команд.

3. Функциональность системы: управление пропусками, обогащение событий данными о владельцах, предоставление опций выдачи пропусков и просмотра журнала событий.

Как применять аналитические модели в процессе разработки

При разработке системы с нуля работа над аналитическими моделями может идти в таком порядке:

1. Моделирование сценариев. Договориться с Заказчиком о границах проекта и сценариях работы. Параллельно — моделирование предметной области. Пригодится для формулировки требований к поведению.

2. Моделирование полезных инкрементов. Сформировать набор функциональности для MVP.

3. Моделирование поведения системы. Описать функциональность и правила работы системы.

Рис. 11 — Процесс моделирования и разработки MVP 

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

Рис. 12 — Непрерывное развитие системы через моделирование

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

Экспресс-оценка изменений через аналитические модели

Сложность и стоимость вносимых изменений во многом зависит от вида этих изменений. С помощью аналитических моделей можно определить вид предстоящих изменений.

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

   1. изменения предсказуемы по срокам и ресурсам;

   2. меньше рисков.

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

   1. долгая реализация;

   2. стоимость может быть высокой;

   3. есть риски.

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

Резюме

1. Главная проблема при разработке сложных информационных систем — конфликты заинтересованных лиц на стыке их интересов. Среди таких конфликтов потенциальные проблемы могут оставаться незамеченными вплоть до критической точки.

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

3. Роль аналитика в этом процессе — создание и поддержка в актуальном состоянии аналитических моделей.

4. Аналитические модели, которые могут быть разработаны аналитиком:

   1. модель сценариев;

   2. модель полезных инкрементов

   3. модель предметной области;

   4. модель поведения системы.

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

Шпаргалка по аналитическим моделям

Автор — Борис Романов

© Habrahabr.ru