Основные проблемы создания и использования информационных систем организации

Причины такого положения кроются, во-первых, в том, что фирменные методики навязывают с разной степенью настойчивости, фирменную же архитектуру и инфраструктуру (таковы, в частности, Oracle CDM и MSF), а XP фактически отрицает существование архитектуры, что может быть оправданно для некрупных проектов, выполняемых небольшой командой. Во-вторых, традиционные методики:

а) не позволяют оценить качество разработанной архитектуры;

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

в) разделяют процессы технико-экономического обоснования системы, разработки бизнес-процессов и разработки архитектуры системы;

г) не учитывают бизнес-цели и цели использования системы.

В результате осмысления имеющихся методик сформулированы следующие требования к методике выбора архитектуры.

Методика должна:

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

К сожалению, интегральные затраты на систему могут быть полностью известны только после завершения проекта. До завершения проекта интегральные затраты могут быть только оценены.

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

1. Проводится описание бизнес-процессов в организации с ограниченным уровнем детальности (как правило, не пооперационно). Описание бизнес-процесса должно включать его целевые нефункциональные характеристики (частоту возникновения, продолжительность и т. п.). Результатом данного этапа может стать набор вариантов использования (Use case view) описания архитектуры системы.

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

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

3. Определяются возможные вариации бизнес-процессов. На их основе описываются неопределенности.

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

5. Строятся архитектуры-кандидаты с учетом нефункциональных требований к системе и неопределенностей. Различные архитектуры-кандидаты реализуют один и тот же набор функций и функциональных модулей и отличаются только способами физического размещения и реализации этих модулей. Для каждой архитектуры-кандидата описываются: цели; основные характеристики; логическая структура (диаграмма развертывания); физическая структура (схема сети); взаимодействие модулей системы:

  — компоненты и подсистемы ИС и их физическое расположение,

  — синхронность/асинхронность общения между компонентами системы,

  — выбор и определение характеристик каналов связи и т. п.,

  — выбор протоколов и программных интерфейсов,

  — выбор типа ПО промежуточного слоя (middleware),

  — выбор форматов документов, передаваемых в системе.

Например, в проектах достаточно крупных и территориально распределенных систем мы рассматриваем, по крайней мере, три архитектуры-кандидата:

— полностью централизованная система (например, основанная на web-технологиях);

— система, максимально адаптированная к офлайновой работе (основанная на сообщениях);

— система, максимально парирующая риски разработки (двухуровневая клиент-серверная).

6. Выбираются необходимые для реализации архитектуры элементы инфраструктуры — аппаратные средства, операционная система, СУБД, инструментальные средства, прикладные комплексы. Для каждого элемента инфраструктуры рассматриваются варианты его реализации. Оцениваются стоимость владения каждым элементом инфраструктуры архитектуры-кандидата в течение планового периода жизни системы и вероятности возникновения технических рисков в виде отказов элементов инфраструктуры архитектуры-кандидата.

Например, характерными элементами архитектуры являются:

— центральный сервер;

— центральная БД;

— коммуникационный канал между центром и филиалом;

— сервер филиала;

— БД филиала;

— рабочие станции;

7. Строится матрица соответствия элементов архитектуры-кандидата и операций. На основе этой матрицы и матрицы соответствия статических бизнес-рисков и операционных рисков строится матрица соответствия технических рисков и бизнес-рисков. Значения элементов этой матрицы получаются как количество реализаций бизнес-риска на одну реализацию технического риска.

1   2   3

К списку эссе   На главную

Copyright © MeKouD 2009