Проектирование контекста ИС

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

Такой отправной точкой является контекст - модель, иллюстрирующая взаимодействие проектируемой системы с внешним миром и основные принципы её функционирования и предназначенная для того, чтобы:

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

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

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

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

Таким образом, контекст является некоторого рода инструментом, моделирующим позицию проектируемой системы в корпоративной архитектуре компании и позволяющим понять ответ на вопрос: как это будет работать?

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

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

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

Это позволит более точно ее понять в первоначальном виде (том, в котором она была поставлена), а затем:

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

Для понимания "ЗАЧЕМ" необходимо найти ответы на следующие основные вопросы (набор и последовательность вопросов определяются тем, в каком срезе корпоративной архитектуры лежит постановка задачи):

• Какие функциональные возможности ожидает Закачзик? 
• Какой информацией должно управлять решение?
• В каких процессах / сервисах оно будет использоваться?
• Какие еще системы используются в этих процессах / сервисах и какой информацией они уже управляют?
• Чего Заказчик хочит добиться внедрением этого решения? 
• Какие еще процессы / сервисы способны влиять на данную цель? Какие системы и какой информацией управляют?
• Какова реальная цель создания конкретно этого решения?

Формирования видение "ЧТО И КАК" - это в большей степени синтез решения, поэтому здесь ответами на возникающие вопросы являются идеи и результаты их тестирования:

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

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