МЕТОДИКИ ОПИСАНИЯ АРХИТЕКТУР

Модели жизненного цикла информационной системы

Существующие модели ЖЦ:

1. Каскадная модель. Весь объем работ разбивается на этапы (рис. 18). Переход на следующий этап разработки только после окончания работ на предыдущем этапе. Этап заканчивается формированием полного комплекта документов [28].

Рис. 18. Каскадная модель разработки

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

2. Спиральная модель. Основное внимание направлено на начальные этапы ЖЦ: анализ требований к системе, спецификации, предварительное проектирование (рис. 19). Технические решения, создаваемые на этих этапах, проверяются. Уточняются цели и характеристики проекта, уточняются детали. Каждый виток спирали создает свою версию системы. Далее работа уточняется, углубляются и поэтапно конкретизируются детали проекта. В итоге выбирается наиболее приемлемый вариант системы, который доводится до реализации [28].

Рис. 19. Спиральная модель жизненного цикла системы

Модель Захмана

IT-архитектура компании -единое описание важнейших направлений организации, которые имеют связь с информационной средой, прикладными системами и технологиями, при этом учитывается воздействие на основные функции и процессы компании [14].

ИсследованиеГГ-архитектуры компании несет в себе составляющие, связанные с многофункциональной архитектурой, IT-технологиями и управлением. IT-структура компании- целостное описание главных стратегий и целей организации, связанных с технологиями, прикладными системами и информацией. И с воздействием их на бизнес-функции и бизнес-процессы организации [6].

Рассмотрение IT-архитектуры компании производится в определенном контексте имеющихся в компании текстур управления и взаимодействия.

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

• методики аналитических компаний: Gartner, Giga, МЕТА и др.;

• • модель Захмана;
• • методика TOGAF;
• • методика POSIX 1003.23i и др.

Методика - инструмент для создания широкого диапазона разнообразных архитектур [32]. Она включает в себя определение методов проектирования IT- структуры в понятиях использования определенных "строительных блоков”, описание того, как эти "строительные блоки" связаны между собой, набор средств для определения частей архитектуры. Методики включают в себя список рекомендуемых стандартов и совместимых продуктов, которые могут использоваться для воплощения разнообразных частей структуры. Методики конкретизируют, как все эти элементы описания связаны между собой [26]. Определены индустриальные стандарты, чтобы описать ИТ-архитектуру предприятия. Отдельно друг от друга эти стандарты не могут дать разработчикам IT-архитектуры полного набора незаменимых инструментов с точки зрения этой методики и с точки зрения стандартов, которые нужны, чтобы описать архитектуру.

Отображение IT-архитектуры служит детальным руководством, определяющим первоначальные, стандартные или типовые элементы IT- систем, взаимодействие между собой, а также процессы управления информационными системами. Можно сформулировать такие требования [26]:

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

Для правильного описания ГГ-архитектуры организации могут применять разные форматы. Принципиально, чтоб организация употребляла такой формат описания, который бы давал простой для понимания метод руководства по развитию всех качеств IT в компании [35].

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

Схема Захмана [4, 11] основывается на предмете традиционной

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

Модель архитектуры, которую предложил Захман, преследует две главные цели [4, 11]:

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

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

Ученый внес предложение вместо стандартного подхода, опирающегося на рассмотрение отдельных аспектов работы системы как бы в разные факторы времени, рассматривать системы с разных точек зрения [4, 11].

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

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

Модель предприятия задается в виде матрицы (рис. 20). Фактически модель изображается в виде таблицы, имеющей 5 строчек и 6 столбцов. Именно модель, которая соответствует уровню описания архитектуры, содержит точно 5 строк. Строки отражают категории специалистов, которые участвуют в деятельности предприятия. Столбцы отражают основные аспекты производственной деятельности. Шестая строка в данной модели соответствует уровню работающей системы.

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

Рис. 20. Модель Захмана

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

• • входные данные (что?);
• • процессы и функции (как?);
• • место реализации данных процессов (где?);
• • участники (кто?);
• • события (когда?);
• • цели и ограничения работы системы (почему?).

Основные правила при заполнении таблицы:

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

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

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

Диаграмма на рис. 21 иллюстрирует несколько методов моделирования [31]. Пересечение методов используется для формирования матрицы Захмана.

В табл. 6 приведено, какие модели на каких стадиях описания систем рекомендуется использовать.

Рис. 21. Методы моделирования

Таблица 6

Модели развития систем

Джон Захман предложил использование методов моделирования для различных уровней описания архитектуры [4] (табл. 7).

Таблица 7

Использование методов моделирования

О - обязательное использование

Н - необязательное использование