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

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

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

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

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

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

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


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

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


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


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

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


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

  • Какие функциональные возможности ожидает Закачзик? 
  • Какой информацией должно управлять решение?
  • В каких процессах / сервисах оно будет использоваться?
  • Какие еще системы используются в этих процессах / сервисах и какой информацией они уже управляют?
  • Чего Заказчик хочит добиться внедрением этого решения? 
  • Какие еще процессы / сервисы способны влиять на данную цель? Какие системы и какой информацией управляют?
  • Какова реальная цель создания конкретно этого решения?
Формирования видение "ЧТО И КАК" - это в большей степени синтез решения, поэтому здесь ответами на возникающие вопросы являются идеи и результаты их тестирования:
  • Уточнить бизнес-потребности, определить бизнес-функции и границы использования решения в бизнесе. Определить оргструктуру
  • Сформулировать идею использования решения в бизнесе
  • Определить сегмент информационной архитектуры, который является зоной ответственности решения. Определить взаимосвязь этого сегмента с остальной информационной архитектурой
  • Определить смежные системы и их роль в решении бизнес-потребностях / управлении информацией
  • Определить границы проектируемого решения и его взаимосвязь со смежными системами
В качестве итога хочу сказать следующее: у любой задачи есть контекст. Правильное его понимание является залогом эффективного решения поставленной задачи. Зачастую анализ и глубокое понимание контекста приводят к изменению первоначальной формулировки задачи или трактовки ожидаемых результатов. Это знают все, это очевидно. Но проблема заключается в том, что большинство провалов анализа на проектах вызвано именно непониманием контекста поставленной задачи.

Популярные сообщения из этого блога

Карта компетенции аналитика

Оценка эффективности работы аналитика – а чем он занимается и чего можно померить?

Оценка эффективности работы руководителя проектов