Приложение А (справочное). Процесс разработки IDM

Приложение А
(справочное)

Процесс разработки IDM

А.1 Внесение предложения о разработке IDM

А.1.1 Общие сведения

Внесение предложения о разработке IDM - это предварительный этап, который задает необходимые условия для выполнения работы. На данном этапе:

- определяется область действия;

- устанавливается подход к разработке;

- определяются ресурсы;

- устанавливается план проекта.

А.1.2 Определение области действия

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

При подготовке необходимо ответить на следующие вопросы:

- Каковы бизнес-потребности в обмене информацией?

- Кто может описать эти потребности?

- Кто будет акторами, каковы их роли и интересы?

- Как может быть подготовлен и осуществлен обмен информацией?

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

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

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

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

А.1.3 Выработка подхода к разработке IDM

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

А.1.4 Выявление ресурсов

Ресурсы - это люди, которым необходимо участвовать в разработке IDM. Ресурсы должны быть правильно сбалансированы между управлением проектами, разработкой компонентов IDM и отраслевыми знаниями, чтобы можно было осуществлять руководство как разработкой компонентов, так и разработкой программных решений. Баланс требуемых ресурсов будет зависеть от выбранного пути разработки.

А.1.5 План работы

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

А.2 Разработка IDM

А.2.1 Общие сведения

Существует три подхода к разработке IDM:

- выявление процесса;

- настройка информационных ограничений;

- воспроизведение недокументированного изделия.

А.2.2 Выявление процесса

А.2.2.1 Общие сведения

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

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

А.2.2.2 Процесс выявления

Существуют две альтернативные предлагаемые методологии: составление технологической карты и составление карты взаимодействий. Необходимо принять решение о наиболее применимом подходе для данного бизнес-контекста.

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

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

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

А.2.2.3 Создание требования к обмену

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

А.2.3 Настройка информационных ограничений

А.2.3.1 Определение информационных ограничений

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

А.2.3.2 Локализация информационных ограничений

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

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

А.2.4 Обратное проектирование

А.2.4.1 Общие сведения

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

А.2.4.2 Определение сценария

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

А.2.4.3 Идентификация требуемых данных

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

А.2.4.4 Создание требования к обмену

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

А.2.4.5 Определение информационных ограничений

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

А.2.4.6 Процесс захвата

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

А.2.5 Реализация и использование IDM

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

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

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