Практика формирования требований в ИТ проектах от А до Я. Часть 5. Сущности предметной области. Немного о стратегиях

С частью 4 можно ознакомиться, перейдя по ссылке

VIII Определяем сущности предметной области

Все, что видим мы, — видимость только одна.
Далеко от поверхности мира до дна.
Полагай несущественным явное в мире,
Ибо тайная сущность вещей — не видна
Омар Хайям

Определив абстрактные хранилища продукта, мы получаем костяк для построения детальной модели данных. При проектировании структуры сущностей продукта, удобно использовать канонические диаграммы «Сущность-связь» (ERD), логическую диаграмму (Logic Diagram) или диаграмму классов (Class diagram).

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

Теория проектирования такого типа диаграмм детально изложена в литературе, описывающей работу с UML. Например, эта тема очень удачно представлена в [11]. Поэтому остановлюсь лишь на некоторых аспектах, интересных на мой взгляд,.

На рисунке 8.1 изображен процесс формализации требований к целевой системе, дополненный подпроцессом определения сущностей предметной области.

Рисунок 8.1 — модель процесса определения сущностей предметной области

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

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

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

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

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

1. Используем инкапсуляцию

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

Инкапсуляция, как известно, снижает «хрупкость» системы в целом, благодаря тому, что скрывает реализацию в объекте, локализуя распространение ошибок по всему продукту. Эта тема очень удачно изложена в книге [8]. Системы, построенные на этом принципе, легко модернизировать, безболезненно заменяя цельные конструкции. Также это очень эффективно при разработке отдельных модулей продукта разными командами.

Поэтому, разрабатывая структуру системы, старайтесь делить ее на самодостаточные модули, сервисы и т.п., отвечающие за определенную специализацию. Желательно, чтобы эти конструкции общались друг с другом посредством четко определенных интерфейсов.
Пример дробления модуля (части системы) на самодостаточные сегменты отражен на Рисунке 8.2. Для наглядного восприятия элементов системы и их взаимодействия, удобно пользоваться моделями, построенными на базе диаграммы «Архитектуры приложений».

Рис. 8.2 – Диаграмма фрагмента архитектуры модуля Управление исполнением проекта

Как видно из рисунка, модуль «Управление исполнением проекта» разбит на три сегмента (на диаграмме они изображены зелеными “пазлами”):

• Формирование Шаблонов заданий;
• Управление заданиями;
• Учет выполнения заданий;

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

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

На рисунке 8.3 приведен пример диаграммы классов сегмента «Управление обращениями заинтересованных лиц». Обратите внимание на классы: «Карта заданий» и «Статус карты задания», принадлежащие другому сегменту «Управление заданиями» из модуля «Управление исполнением проекта», рассмотренного нами выше. В данном случае — элементы, спроектированные на других диаграммах, обычно, имеют ссылку (подпись) на диаграмму родитель, она указывается в круглых скобках под названием элемента (класса).

Рис. 8.3 – Диаграмма классов сегмента Управление обращениями заинтересованных лиц

Если забежать вперед и глянуть ниже на Рисунок 8.5, то там приведен пример диаграммы классов для еще одного сегмента, описанного выше — «Формирование Шаблонов заданий».

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

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

2. Эффективно используем декомпозицию бизнес сущностей

Декомпозиция, с точки зрения системного анализа — метод, по которому исследуемая система делится на подсистемы, задача на подзадачи и т.д., каждая из которых решается самостоятельно.

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

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

1. Идентификатор;
2. Дата создания;
3. Заголовок;
4. Описание;
5. Состояние;

В этом примере атрибуты Идентификатор и Дата создания будут изменяться только в момент создания записи. Атрибуты Описание и Заголовок, могут меняться по мере уточнения требования, или при изменении потребностей заказчика. А атрибут Состояние меняется при выставлении заданий по требованию и их выполнении. При этом неплохо бы иметь еще и историю всех изменений. Таким образом, сущность «Требование» можем разделить на три реляционные таблицы: 1) Спецификация требования, 2) Содержание требования, 3) Состояние требования см. Рисунок 8.4

Рис. 8.4 – Диаграмма Классов Требования

Но не забывайте, используя этот прием, поддерживать девятое правило Кодда:

правило 9: Логическая независимость данных (Logical Data Independence):
Представление данных в приложении не должно зависеть от структуры реляционных таблиц. Если в процессе нормализации одна реляционная таблица разделяется на две, представление должно обеспечить объединение этих данных, чтобы изменение структуры реляционных таблиц не сказывалось на работе приложений.

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

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

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

3. Используем адаптивные модели данных

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

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

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

Для снижения неизбежных затрат при проектировании и реализации адаптивных систем, необходимо учитывать следующие аспекты выбора решения:

1. Оптимальный подбор критериев при фиксированном алгоритме;
2. Выбор наилучшего алгоритма адаптации при фиксированных критериях;
3. Варьирование алгоритмов и критериев;

Разберем вкратце пример использования механизма выставления заданий по шаблону см. Рисунок 8.5. На диаграмме голубым цветом обозначены сущности, моделирующие Шаблоны или Типовые сущности, а зеленым – сущности, моделирующие объекты, сформированные на основании этих шаблонов.

Рис. 8.5 – Диаграмма Классов для Формирования Заданий по Шаблонам

Для единого восприятия терминов предметной области, пополняем наш Глоссарий:

Таким образом, типовая сущность «Шаблон карты заданий» (далее используем обозначение ШКЗ), предназначена для формирования на основании своей структуры, экземпляров сущности «Карта заданий». То есть, создав некий набор Шаблонов карт заданий, мы в дальнейшем сможем их использовать для быстрого заполнения новых Карт заданий на выполнение работ в проекте.

Теперь более детально о структуре ШКЗ. ШКЗ включает в себя, как агрегат, типовую сущность «Шаблон задний» и связывает ее экземпляры в один бизнес сценарий. В ШКЗ указывается Штатная позиция (должность) для определения лица, ответственного за процесс. Этот реквизит, при формировании на основании ШКЗ — новой Карты заданий, позволит автоматически определить пользователя, назначенного в текущий момент на должность в организации и претендующего на роль куратора группы заданий.

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

Рассмотрим теперь то, ради чего мы затевали всю эту типизацию — сущности, экземпляры которых формируются на основании Типовых сущностей. Например, «Карта заданий» формируется на основании ШКЗ и предназначена для группировки заданий, выставляемых исполнителям, как связанных, пошаговых операций. Следующая такая Сущность — «Задания», которая формируются по типовой сущности – «Шаблон задания». Для Карты заданий автоматически может определиться ответственное лицо (об этом упоминалось выше при описании ШКЗ). По штатной позиции, при выставлении Задания, автоматически определяется исполнитель, назначенный для ее выполнения, в том числе может использоваться «агент-робот» системы. По виду задания, для робота или человека, может быть идентифицирована процедура, которую необходимо выполнить.

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

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

4. Используем паттерны проектирования

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

Очень важно, чтобы аналитик, встретив необходимость преодоления некой проблемы, схожей с той которую уже решали, старался универсализировать это решение при помощи шаблона. Подобные шаблоны должны разрабатываться и утверждаться совместно с проектной группой. Тогда вся группа и разработчиков, и проектировщиков будет “невольно” следить за необходимостью их использования и правильностью применения.

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

Приведу его описание:
Технологическая линия (Production Line)

Пример реализации структуры данных для шаблона «Технологическая Линия» представлен на Рисунке 8.6.

Как видно из диаграммы, структура данных почти полностью повторяет диаграмму «Формирования Задний по шаблонам» см. Рисунок 8.4. Описание механизмов, определяющих работу шаблона, большей частью аналогично процессу «Формирования Заданий по шаблонам», представленному в предыдущем разделе. Остановимся подробнее лишь на тех моментах, которые не были освещены выше, в частности – механизм определения и формирования Параметров действия.

Рис. 8.6 – Диаграмма Классов шаблона Технологическая линия

Для каждого Шаблона действия определяется перечень параметров, на основании «Вида задания» назначенного для шаблона. Параметр может быть либо “Основанием” для выполнения задания, либо “Результатом” его выполнения. Каждый параметр имеет тип, который определяет сущность “Продукта” (в нашем случае документ проектирования), обрабатываемого Технологической линией. На основании параметров, определенных для шаблона, при формировании действия будет идентифицирован конкретный экземпляр сущности, и ссылка на него будет записана в виде параметра “Основания” для действия. После выполнения действия, если для него определен параметр “Результат” (действие формирует или изменяет документ), ссылка на конкретный его экземпляр будет сохранена в этом параметре.

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

5. Не забываем о стратегии развития линейки продуктов

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

1. наличие технологий уже используемого продукта, опыт его внедрения и проблемы эксплуатации;
2. сложившиеся привычки и традиции пользователей, длительное время взаимодействующих с заменяемым ПО;
3. необходимость переноса данных из старой системы в новую, а возможно и синхронизацию работы обоих систем на какое-то время.

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

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

• Изменение внешних, по отношению к системе, условий, влияющих на ее функционирование. Например, изменения в законодательстве;
• Борьба с дезорганизацией в системе, связанная с быстрым накоплением информации и изменениям требований к ее качеству;
• Борьба с «усталостью», «хрупкостью» и «избыточностью» ПО, вызванной частыми изменениями, которые вступают в конфликт с его изначальным дизайном;
• Качественное изменение инфраструктуры системы. Например, ужесточение требований к безопасности;

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

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

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

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

Для привлечения как можно большего числа людей к процессу изменения, необходимо дать им возможность наглядно и эмоционально-привлекательно представлять контекст этих изменений. А именно: перечень изменяемых процессов, соответствие старых процессов новым, шаги и условия перехода и т.п. Используйте для визуализации модели стратегии перехода от старой системы к целевой, уже упомянутую выше, диаграмму «Архитектуры приложений». Пример представления стратегии для рассматриваемого нами проекта, изображен на Рисунке 8.7.

Рис. 8.7 – Диаграмма представления стратегии перехода от используемой архитектуры к целевой

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

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

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

Поскольку процесс замены старого ПО на новое длительный и сопряжен с проявлением множества трудно прогнозируемых рисков, необходимо постоянно следить за прогрессом перехода. При постоянном откладывании своевременного внесения необходимых изменений в программное обеспечение, резко обостряется проблема его стагнации. Поскольку зависимость ресурсов, выделяемых на модификацию ПО от их объема нелинейная, то и стоимость модификации стагнирующего ПО возрастает также нелинейно. Когда стоимость модификации возрастает настолько, что заказчик становится не в состоянии дальше изменять ПО, то оно становится условно «неизменным». Об этом очень доходчиво изложено в [8].

Для борьбы с подобными проблемами, можно заранее определить вехи проекта и четко отслеживать их наступление (или не наступление). Затягивание процесса изменений, с большой вероятностью, может привести к срыву всего проекта. Ведь внедрение каждого этапа чаще всего еще и связано со стрессом для пользователей и дополнительной нагрузкой на них. Если выполнение какого-либо из этапов не увенчалось успехом, то может возникнуть необходимость «откатиться» на предыдущий этап. Два-три таких «отката» и заказчик может отказаться от дальнейшего перехода на новое ПО, поскольку стоимость изменений становится критической.

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

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

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

В следующей части мы будем определять поведение системы.

Автор: Алексей Радзишевский

Источник