Школа
системного анализа
и проектирования
системного анализа
и проектирования
Systems Education
Школа системного анализа
и проектирования
Школа системного анализа
и проектирования
Борис Романов
Роль аналитика
в разработке сложных информационных систем
в разработке сложных информационных систем
Введение
Создание больших сложных информационных систем (ИС) — это долгий, дорогой и часто непростой процесс. Иногда бывает так, что потрачено очень много денег, сил и времени, а система всё равно делает не то, что нужно. В этой статье расскажем, как аналитик может помочь избежать этого, а также:
Статья будет полезна системным и бизнес-аналитикам, а также проектным и продуктовым менеджерам, которые хотят выстроить последовательный процесс разработки систем через аналитические модели.
- в чём основная проблема при разработке сложных информационных систем;
- какие аналитические модели и зачем нужно применять в процессе разработки;
- как и с помощью каких инструментов разрабатывать аналитические модели.
Статья будет полезна системным и бизнес-аналитикам, а также проектным и продуктовым менеджерам, которые хотят выстроить последовательный процесс разработки систем через аналитические модели.
Проблематика разработки
сложных систем
сложных систем
При разработке больших и сложных ИС вы неизбежно наткнётесь на:
Главная сложность — столкновение интересов. Каждый, кто участвует в проекте, хочет «сделать хорошо», но смотрит на задачу чаще всего только со своей точки зрения.
Для разработчика «хорошо» — это красивый код и технологичный стек, для менеджера — соблюдение сроков и бюджетов, дизайнер хочет сделать красиво и «юзерфрендли», бизнесу нужна прибыль, а пользователь хочет использовать удобную систему, желательно бесплатно.
- стейкхолдеров с разными целями;
- много интеграций;
- сложную логика взаимодействия между компонентами и смежными системами;
- запутанные процессы.
Главная сложность — столкновение интересов. Каждый, кто участвует в проекте, хочет «сделать хорошо», но смотрит на задачу чаще всего только со своей точки зрения.
Для разработчика «хорошо» — это красивый код и технологичный стек, для менеджера — соблюдение сроков и бюджетов, дизайнер хочет сделать красиво и «юзерфрендли», бизнесу нужна прибыль, а пользователь хочет использовать удобную систему, желательно бесплатно.
Рис.1 — У всех в процессе разработки своя перспектива рассмотрения задачи
Разные ценности участников процесса неизбежно вызывают конфликты. Нерешённые конфликты могут приводить к проблемам, решение которых требует времени и ресурсов.
Если проблема не решается вовремя, то возникают «пожары» и необходимость их «тушить».
Что же делать? Стараться предупреждать потенциальные конфликты и проблемы до их возникновения, организовать процесс так, чтобы важные проблемы подсвечивались до их возникновения. Тогда о путях решения этих проблем можно будет эффективно договариваться. В этом может помочь применение аналитических моделей и представлений, в которых отражаются разные точки зрения на системы и интересы разных стейкхолдеров.
Если проблема не решается вовремя, то возникают «пожары» и необходимость их «тушить».
Что же делать? Стараться предупреждать потенциальные конфликты и проблемы до их возникновения, организовать процесс так, чтобы важные проблемы подсвечивались до их возникновения. Тогда о путях решения этих проблем можно будет эффективно договариваться. В этом может помочь применение аналитических моделей и представлений, в которых отражаются разные точки зрения на системы и интересы разных стейкхолдеров.
Роль аналитика
в создании сложных систем
в создании сложных систем
Модель — это упрощённое представление объектов реального мира, отображающее свойства этого объекта, важные в контексте решаемой задачи.
Анализ — это исследование через выделение и изучение отдельных частей объекта анализа.
Аналитик, используя навыки анализа, выявляет в окружающем мире структуры данных и фиксирует их в виде набора взаимосвязанных моделей. Именно аналитик отвечает за то, что аналитические модели будут точными, цельными и понятными.
Анализ — это исследование через выделение и изучение отдельных частей объекта анализа.
Аналитик, используя навыки анализа, выявляет в окружающем мире структуры данных и фиксирует их в виде набора взаимосвязанных моделей. Именно аналитик отвечает за то, что аналитические модели будут точными, цельными и понятными.
Важные точки зрения
на информационную систему
на информационную систему
ИС не создаются в вакууме, сами по себе они никому не нужны. Системы создаются для того, чтобы воздействовать на окружающую действительность, изменить ее. Если после внедрения системы в окружении, бизнесе, у пользователей и клиентов ничего не поменялось, значит цели создания не были достигнуты. Решение задач клиентов, ускорение процессов, повышение прибыли могут быть целями создания системы.
Рис.2 — Системы разрабатывают, чтобы повлиять на окружающую реальность
При разработке информационной системы нужно посмотреть на неё с разных сторон, рассмотреть разные аспекты, чтобы учесть интересы всех стейкхолдеров и заранее подсветить возможные точки конфликта их интересов.
При этом нужно учитывать:
a. Функциональная структура системы — с точки зрения набора
функций системы и отношений между ними.
b. Композитная структура системы — с точки зрения набора
конструктивных элементов (сервисов, модулей), из которых
собирается система.
4.Структура поставок системы — инкременты из решённых задач, поставляемых конечным пользователям.
При этом нужно учитывать:
- Надсистему, в которую встроится разрабатываемая система, и её проблемы.
- Саму систему, окружающие её системы, пользователей и других стейкхолдеров.
- Состав, внутреннюю структуру системы в разных разрезах.
a. Функциональная структура системы — с точки зрения набора
функций системы и отношений между ними.
b. Композитная структура системы — с точки зрения набора
конструктивных элементов (сервисов, модулей), из которых
собирается система.
4.Структура поставок системы — инкременты из решённых задач, поставляемых конечным пользователям.
Рис.3 — Аспекты рассмотрения информационной системы
Какие модели нужны
для разработки системы
для разработки системы
Набор нужных для разработки аналитических моделей напрямую связан с перечнем вопросов, на которые нужно ответить в этом процессе.
- Какие внешние проблемы будет решать система?
- Какие пользовательские сценарии должны быть для этого реализованы?
- Какое поведение должно быть реализовано в системе?
- Что и как нужно изменить в уже существующем решении?
Рис.4 — Набор связанных аналитических моделей для разработки систем
Моделирование сценариев
Что такое моделирование сценариев
и для чего оно нужно
и для чего оно нужно
Моделирование сценариев направлено на выявление и перечисление основных кейсов использования системы, её возможностей, которые решают проблемы пользователей. Сценарии должны содержать не описание работы системы и способы реализации, а то, что пользователи будут делать в ней. То есть моделирование сценариев — это моделирование изменений действительности, которая окружает систему.
Для успешного моделирования на входе этого этапа нужно иметь список ролей, их проблем, задач и предпочтений.
Моделирование сценариев несёт в себе много возможностей.
На выходе этого этапа должен быть набор сценариев и их взаимосвязей полный настолько, чтобы складывалась полная картина взаимодействия пользователя с системой. Модель должна содержать набор сценариев, который имеет смысл поставлять целиком.
Для успешного моделирования на входе этого этапа нужно иметь список ролей, их проблем, задач и предпочтений.
Моделирование сценариев несёт в себе много возможностей.
- Снижает риски забыть или пропустить важные возможности системы.
- Помогает заранее договориться о возможностях, которые нужно реализовать, и заложить соответствующие архитектурные и другие ограничения.
- Помогает заранее договориться о сценариях, которые НЕ будут реализованы.
- Упрощает управление проектом, планирование и проведение приемо-сдаточных испытаний, написание документации.
На выходе этого этапа должен быть набор сценариев и их взаимосвязей полный настолько, чтобы складывалась полная картина взаимодействия пользователя с системой. Модель должна содержать набор сценариев, который имеет смысл поставлять целиком.
Инструментарий
Для оформления модели сценариев можно использовать разные техники и инструменты.
Классическая и самая популярная техника — диаграмма вариантов использования (Use Case Diagram) нотации UML. Инструментов для неё существует очень много. Можно использовать Visual Paradigm, PlantUML, Enterprise Architect, даже draw.io.
Не такая популярная, но тоже интересная техника — использовать уровень бизнеса и уровень мотивации нотации Archimate.
В крайнем случае список сценариев можно описать в виде текста, главное зафиксировать их.
Классическая и самая популярная техника — диаграмма вариантов использования (Use Case Diagram) нотации UML. Инструментов для неё существует очень много. Можно использовать Visual Paradigm, PlantUML, Enterprise Architect, даже draw.io.
Не такая популярная, но тоже интересная техника — использовать уровень бизнеса и уровень мотивации нотации Archimate.
В крайнем случае список сценариев можно описать в виде текста, главное зафиксировать их.
Пример
Пример из области умных зданий.
Описание проблемы. У жителя умного здания есть проблема: ему нужно выходить к пункту пропуска и показывать пропуск при въезде во двор. Он хочет не выходить из машины, а хочет попадать во двор бесконтактно.
Потенциальное решение. Открывать шлагбаум автоматически, если в машине есть бесконтактный пропуск.
Описание проблемы. У жителя умного здания есть проблема: ему нужно выходить к пункту пропуска и показывать пропуск при въезде во двор. Он хочет не выходить из машины, а хочет попадать во двор бесконтактно.
Потенциальное решение. Открывать шлагбаум автоматически, если в машине есть бесконтактный пропуск.
Рис.5 — Потенциальное решение проблемы
Эта модель на самом деле не достаточна для реализации, потому что игнорирует вопросы безопасности и требования нормативно-правовых актов, эти вопросы неизбежно возникнут в процессе обсуждения этой диаграммы со стейкхолдерами.
В результате обсуждения модель дополнится кейсами аннулирования пропусков, обработкой ситуации утери пропуска и т.д.
В результате обсуждения модель дополнится кейсами аннулирования пропусков, обработкой ситуации утери пропуска и т.д.
Рис.6 — Расширение потенциального решения
Моделирование
предметной области
предметной области
Что такое моделирование предметной области
и зачем оно нужно
и зачем оно нужно
Моделирование предметной области направлено на выявление терминов и правил, сущностей и связей между ними, характерных для автоматизируемой предметной области. Моделирование предметной области заключается в первую очередь в формировании глоссария.
Оперирование общими понятиями — один из ключевых факторов успешной коммуникации в команде. Без единой системы понятий, единого языка, эффективное однозначное формулирование требований невозможно.
Сущности модели предметной области должны отражаться на всех уровнях моделирования и разработки системы: и сценарии использования и программный код должны оперировать одинаковыми бизнес-понятиями.
Оперирование общими понятиями — один из ключевых факторов успешной коммуникации в команде. Без единой системы понятий, единого языка, эффективное однозначное формулирование требований невозможно.
Сущности модели предметной области должны отражаться на всех уровнях моделирования и разработки системы: и сценарии использования и программный код должны оперировать одинаковыми бизнес-понятиями.
Инструментарий
Модель предметной области можно представить по-разному.
Пример
Пример модели предметной области по нашей проблеме проезда во двор умного здания в виде диаграммы классов.
Рис.7 — Модель поведения предметной области в виде диаграммы классов
Такая диаграмма отражает все сущности нашей предметной области и связи между ними. Модель позволяет сформировать единый глоссарий и понимание физического смысла сущностей.
Моделирование полезных
инкрементов системы
инкрементов системы
Что такое моделирование инкрементов
и зачем оно нужно
и зачем оно нужно
Моделирование инкрементов направлено на фиксацию этапов разработки системы: в какой очередности реализуется функциональность системы. Трудно разработать с нуля систему сразу сложной, необходимо начинать с самой важной функциональности, а затем наращивать её и улучшать.
Моделирование инкрементов позволяет:
Моделирование инкрементов позволяет:
- структурировать порядок поставки новой функциональности;
- приоритизировать работу и сконцентрироваться на наиболее важной функциональности;
- договориться о составах поставок функциональности с Заказчиком
Инструментарий
Одна из самых удобных техник — User Story Mapping. Карту историй можно построить в Miro, draw.io и даже стикерами на доске.
Пример
Вернёмся к нашему примеру с бесконтактным въездом во двор. Выделим MVP с минимальными возможностями:
- даём возможность охранникам выдавать пропуска вручную;
- настраиваем СКУД (система, которая открывает шлагбаум) так, что шлагбаум открывается при подъезде авто с бесконтактным пропуском;
- предоставляем охранникам возможность просматривать списки пропусков и вручную их блокировать.
Рис.8 — User Story Map для примера с бесконтактным въездом во двор
Так наши пользователи могут быстро получить минимально нужный объём функциональности и могут начинать пользоваться бесконтактным въездом.
В рамках следующих релизов мы можем улучшать систему: реализовать самостоятельную регистрацию жителями дома, распознавание номеров, автоматическую блокировку пропусков и т.д.
В рамках следующих релизов мы можем улучшать систему: реализовать самостоятельную регистрацию жителями дома, распознавание номеров, автоматическую блокировку пропусков и т.д.
Моделирование поведения системы
Что такое моделирование поведения
и зачем оно нужно
и зачем оно нужно
Моделирование поведения направлено на определение того, как система будет функционировать и как именно будут реализованы сценарии работы пользователей. Для этого необходимо выявить:
- входящие и исходящие информационные потоки: какая информация и откуда поступает В систему, какая информация и куда передаётся ИЗ системы;
- порты/интерфейсы: точки взаимодействия с внешним миром и другими системами (API, пользовательский интерфейсы, брокеры сообщений, шины и т.д.)
- ключевые функции системы: что именно система делает, за что отвечает, чего ждать от системы и чего не ждать.
Рис.9 — Состав модели поведения системы
Моделирование поведения системы позволяет:
- убедиться, что система в принципе реализуема и нужная для её работы информация доступна;
- определиться с кем/чем и в каких случаях нужно интегрироваться;
- выявить объекты внимания, которые требуют дальнейшего детального проектирования и спецификации;
- верхнеуровнево оценить сложность создания системы.
Инструментарий
Для моделирования поведения системы существует огромное количество инструментов и техник.
- Диаграммы нотации UML: диаграмм последовательности, диаграмма деятельности, диаграмма состояний. В качестве инструмента — любой удобный вам для нотации UML.
- Диаграмма активности нотации SysUML.
- Archimate.
- Нотация C4.
- Event Storming.
- BPMN.
- Фиксация без нотации в формате “квадратики и стрелочки”.
Пример
Можно смоделировать наш пример с бесконтактным въездом во двор в нотации Archimate.
Рис.10 — Модель поведения системы бесконтактного въезда в нотации Archimate
На модели отражены:
b. сама система взаимодействует со СКУД, которая управляет шлагбаумом, через API.
2. Информационные потоки в системе: данные пропусков, события прохода, вызовы различных команд.
3. Функциональность системы: управление пропусками, обогащение событий данными о владельцах, предоставление опций выдачи пропусков и просмотра журнала событий.
- Интерфейсы взаимодействия системы с пользователями и другими системами:
b. сама система взаимодействует со СКУД, которая управляет шлагбаумом, через API.
2. Информационные потоки в системе: данные пропусков, события прохода, вызовы различных команд.
3. Функциональность системы: управление пропусками, обогащение событий данными о владельцах, предоставление опций выдачи пропусков и просмотра журнала событий.
Как применять аналитические модели
в процессе разработки
в процессе разработки
При разработке системы с нуля работа над аналитическими моделями может идти в таком порядке:
- Моделирование сценариев. Договориться с Заказчиком о границах проекта и сценариях работы. Параллельно — моделирование предметной области. Пригодится для формулировки требований к поведению.
- Моделирование полезных инкрементов. Сформировать набор функциональности для MVP.
- Моделирование поведения системы. Описать функциональность и правила работы системы.
Рис.11 — Процесс моделирования и разработки MVP
При развитии уже существующей системы работа над аналитическими моделями входит в цикл.
Рис.12 — Непрерывное развитие системы через моделирование
Доработка системы обязательно должна проходить через модификацию аналитических моделей. Изменения в моделях позволяют предварительно оценивать сложность доработки.
Экспресс-оценка изменений
через аналитические модели
через аналитические модели
Сложность и стоимость вносимых изменений во многом зависит от вида этих изменений. С помощью аналитических моделей можно определить вид предстоящих изменений.
b. меньше рисков.
2. Качественные изменения — придание системе принципиально новых качеств за счёт новых компонентов или архитектурных решения. Пример: добавление нового бизнес-процесса.
a. долгая реализация;
b. стоимость может быть высокой;
c. есть риски.
Качественные изменения в систему вносить намного сложнее, чем количественные. Но без развития, внедрения новых функций система будет стагнировать. Здесь кроется польза аналитических моделей для менеджмента: с помощью моделей можно оценивать изменения и балансировать между качественными и количественными изменениями.
- Количественные изменения — развитие уже существующих функций системы (улучшения, повышение удобства использования). Пример: добавление атрибутов сущности, улучшение UI без изменения бизнес-модели.
b. меньше рисков.
2. Качественные изменения — придание системе принципиально новых качеств за счёт новых компонентов или архитектурных решения. Пример: добавление нового бизнес-процесса.
a. долгая реализация;
b. стоимость может быть высокой;
c. есть риски.
Качественные изменения в систему вносить намного сложнее, чем количественные. Но без развития, внедрения новых функций система будет стагнировать. Здесь кроется польза аналитических моделей для менеджмента: с помощью моделей можно оценивать изменения и балансировать между качественными и количественными изменениями.
Резюме
- Главная проблема при разработке сложных информационных систем — конфликты заинтересованных лиц на стыке их интересов. Среди таких конфликтов потенциальные проблемы могут оставаться незамеченными вплоть до критической точки.
- Разработка связанного набора аналитических моделей, в которых бы учитывались интересы всех заинтересованных лиц, эффективна для качественных коммуникаций и своевременного обнаружения потенциальных проблем.
- Роль аналитика в этом процессе — создание и поддержка в актуальном состоянии аналитических моделей.
- Аналитические модели, которые могут быть разработаны аналитиком:
b. модель полезных инкрементов
c. модель предметной области;
d. модель поведения системы.
5. Инструментарий и подходы аналитического моделирования не так важны. Используйте те инструменты, которыми владеете лучше всего. Главное, чтобы модель содержала корректную информацию.
Шпаргалка
по аналитическим моделям
по аналитическим моделям
Об авторе
Борис Романов
- В ИТ с 1996.
- Разработчик, аналитик, архитектор, менеджер проектов, менеджер продуктов.
- Опыт в сферах систем распознавания, электронного документооборота, информационной безопасности, e-commerce.