<div><img src="https://mc.yandex.ru/watch/26690535" style="position:absolute; left:-9999px;" alt="" /></div>

Mind Map в проектировании

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

Мы используем Mind Map как для предварительного проектирования, так и для чистового структурирования материала.

Предварительное проектирование

Мы используем Mind Map для детализации требуемых в информационной системе разделов. При этом корневые ветки первого уровня — это разделы.

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

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

В ходе детализации всплывает потребность в новых корневых разделах.

В ходе совместного обсуждения с заказчиком при составлении Mind Map приходит понимание состава проекта, всегда всплывают те вещи, о которых не было известно при составлении видения системы “в голове”. Именно поэтому, даже в случае, если заказчик находится на стадии выбора подрядчика путем обзвона профильных компаний по разработке программного обеспечения, мы всё равно рекомендуем встретиться и обсудить состав системы, произвести предварительное проектирование. Это бесплатная, но очень полезная процедура.

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

Данный инструмент используется не только при проектировании CRM, ERP, XRM или MES систем, но и при разработке сайтов. В этом случае основными ветками являются разделы сайта, отдельной ветвью делается система управления и её ветками разделы CMS-системы.

Техническое проектирование

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

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

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

Не упустить деталей

Подход разделения на интерфейсы и сущности с постепенной детализацией при проектировании позволяет заметить нестыковки и дополнить сущности или интерфейсы. Например, в интерфейс добавляется необходимый для системы элемент, при этом менеджер проекта сразу находит соответствующий элемент в сущности, и если замечает его отсутствие, то дополняет соответствующую ветку. То же самое и с функциями. Например — необходимо реализовать обмен данными с 1С, однако, в случае сбоя естественно возникнет вопрос — почему он произошел. Для будущего оперативного решения подобной задачи необходимо вести лог обмена данными, а для него необходимо создать таблицу сущности (базу данных для хранения истории обмена). Кроме того, как будет система работать через год или пять? Если не предусмотреть в функциях очистку лога, например, по сроку записей больше года, то база рано или поздно переполнится. Это необходимо занести в функции.

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

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

Чем дальше происходит проработка проекта, тем детальней становиться Mind Map и в его конечном варианте он учитывает все поля и кнопки интерфейсов, фильтры списков, все поля с данными, которые должны быть в информационной системе.

Зачем детализировать

Прототипы интерфейсов и детальный Mind Map являются основой для итогового документа — Технического Задания на разработку ERP-системы. Элементы интерфейсов дублируются в прототипах и ветке интерфейсов карты. Сущности соотносятся с интерфейсами и функциями. Функции соотносятся и с интерфейсами. Такой подход позволяет избегать ситуаций, когда что-то упущено. А упущение чего-то, это необъективная оценка стоимости продукта, что приводит к дополнительным затратам заказчика, это срыв сроков разработки, так как для получения итогового результата необходимо делать незапланированные действия и это ошибки в информационной системе, вызванные ошибками проектирования и несогласованностью данных. 

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