- •Методические указания по проведению учебной практики
- •Раздел 1. Способы представления алгоритмов………………………………………………...4
- •Раздел 2. Архитектура предприятия…………………………………………………………..21
- •Раздел 3. Система управления архитектурой предприятия…………………………………40
- •Раздел 4. Системы управления контентом……………………………………………………53
- •Введение
- •Раздел 1. Способы представления алгоритмов
- •Линейные программы структура программы
- •Понятие массива данных
- •Одномерные массивы
- •Многомерные массивы
- •ДвумерныЕ массивЫ
- •Действия над элементами массивов
- •1.5. Контроль ошибок при работе с массивами
- •Решение задач - примеров
- •Раздел 2. Архитектура предприятия
- •2.1. Понятие и общее представление об архитектуре предприятия
- •2.2. Цели создания архитектуры предприятия
- •2.3. Методические принципы создания архитектуры
- •2.4. Корпоративная архитектура предприятия
- •Корпоративная архитектура
- •2.5. Детализация в формировании архитектуры
- •Подходы при построении архитектуры
- •Компоненты архитектуры предприятия
- •Комплексная архитектура предприятия Модельные и организационные подходы
- •Матрица согласованных моделей в архитектурах
- •Примеры заполнения ячеек схемы
- •Требования к «3д-модели»
- •Раздел 3. Система управления архитектурой предприятия
- •3.1. Приемы процессно-ориентированной архитектуры предприятия
- •3.2. Изменения архитектуры
- •Изменения и улучшения организационной структуры
- •Изменения и улучшения систем управления
- •3.3. Идентификация и описание бизнес-процессов
- •Менеджмент бизнес-процессов
- •Управление операционными улучшениями бизнес-процессов
- •3.4. Моделирование организации деятельности предприятия
- •Раздел 4. Системы управления контентом
- •4.1. Объектная модель
- •4.2. Сетевая модель
- •4.3. Модульная модель
- •4.5. Коммерческие системы
- •Задание для самостоятельной работы
- •Контрольные вопросы
- •9. Схема «3д-предприятие».
- •Учебно-методическое обеспечение
Компоненты архитектуры предприятия
Выделяют следующий набор компонентов архитектуры.
Двигатели архитектуры (Architecture Drivers) отражают внешние стимулы изменения архитектуры: бизнес-стимулы и технические стимулы.
В качестве бизнес - стимулов может выступать новое законодательство, новые инициативы администрации, ассигнования для ускорения развития отдельных сфер, рыночные силы.
В роли технических двигателей могут выступать новое и улучшенное программное обеспечение, аппаратные средства ЭВМ и их комбинации.
Стратегическое направление (Strategic Direction) - руководство для разработки целевой архитектуры, которое содержит видение миссии предприятия, принципы его построения, цели и объекты предприятия.
Текущая архитектура (Carrent Architecture) определяет архитектуры предприятия "как есть" и состоит из двух частей: текущая бизнес-архитектура и техническая архитектура (данные, приложения и технологии). Она отражает текущие возможности и технологии, а также служит объектом для дальнейшего расширения.
Целевая архитектура (Target Architecture) определяет архитектуру предприятия "как должно быть построено" и состоит из двух частей: целевая бизнес-архитектура и техническая архитектура (т.е. данные, приложения и технологии). Она представляет будущие возможности и технологии, которые являются результатом улучшения проекта поддержки изменяющихся бизнес - потребностей.
Переходные процессы (Transitional Processes) поддерживают переход от текущей архитектуры к целевой архитектуре. Критические переходные процессы для предприятия включают планирование инвестиций в сферу ИТ, планирование перехода, управление конфигурацией, контроль и управление проектом.
Архитектурные сегменты (Architectural Segments) отражают ориентацию отдельных частей общей архитектуры на главные бизнес - области.
Архитектурные модели (Architectural Models) определяют бизнес - модели и конструкторские (технические) модели, которые отражают все необходимые сегменты для полного описания предприятия.
Стандарты (Standards) включают все стандарты, руководящие принципы (руководящие материалы), а также передовой опыт. Примерами стандартов являются:
- стандарты безопасности;
- стандарты данных относятся к данным, метаданным и другим связанным структурам;
- стандарты приложений относятся к прикладному ПО;
- стандарты технологий относятся к операционным системам и аппаратным платформам.
Комплексная архитектура предприятия Модельные и организационные подходы
Свойство моделей, описаний, проектов, имеющих статус стандартизованного образца, характеризует их как шаблоны, которые могут быть использованы в разработках различных конкретных систем.
При описании процесса разработки и использовании архитектуры конкретного предприятия рассматривается схема движения от архитектуры «как есть» к архитектуре «как должно быть».
Вышесказанное имеет особое значение для предприятия, включенного в программу трансформации.
Матрица согласованных моделей в архитектурах
Сложные системы характеризуются выполняемыми процессами (функциями), структурой и поведением во времени. Для адекватного моделирования этих аспектов в автоматизированных информационных системах различают организационные, функциональные, информационные и поведенческие модели пересекающиеся друг с другом.
Функциональная модель системы описывает совокупность выполняемых системой функций, характеризует морфологию системы (ее построение)- состав функциональных подсистем, их взаимосвязи.
Информационная модель отражает отношения между элементами системы в виде структур данных (состав и взаимосвязи).
Поведенческая (событийная) модель описывает информационные процессы (динамику функционирования). В ней фигурируют такие категории, как состояние системы, событие, переход из одного состояния в другое, условия перехода, последовательность событий.
Организационная модель описывает подразделения из которых состоит предприятие.
Все эти модели должны быть соединены в единую систему понятным и непротиворечивым образом. Поэтому даже вопросов «простого» согласования компонентов системы достаточно для того, чтобы прилагать специальные усилия на уровне формирования архитектуры.
Идея такого согласования состоит в том, что его надо начинать с самых главных характеристик предприятия, рассматривая важнейшие содержательные аспекты. В идеальном случае согласование начинают с конструирования системы управления предприятием, а именно с создания сбалансированной системы целей и планов. В эту сбалансированную систему целей и планов входят: миссия предприятия, стратегические цели, индикаторы достижения целей и их целевые значения; мероприятия по достижению целей, включая архитектуру информационной системы и информационно-технологическую платформу, а также обновленные бизнес – процессы и оргструктуры; система мотивации работников и планы их профессионального обучения и т.д. Согласование проводят на явно изложенных описаниях предприятия, которые позволяют видеть все существенные взаимосвязи, т.е. на его моделях.
Суть этого метода сводится к формализованному представлению предприятия в виде матрицы (Таблица 2).
Строки таблицы отражают уровни представления системы, к ним относятся уровни моделирования, уровни решения проектных задач. Более детально это следующие представления:
бизнес среда системы,
концептуальная модель,
логическая модель,
технологическая, «физическая модель»,
детальная реализация (часто поблочная),
представление пользователя (эксплуатация).
Выделенные аспекты, столбцы таблицы, фактически отражают разделы обеспечения системы:
информационное обеспечение (данные),
функциональное обеспечение (функции),
коммуникационное обеспечение (сеть),
организационное обеспечение (структура организации) и т.д.
Описанные разделы обеспечения и уровни представления являются классификацией сущностей предприятия и его информационной системы.
В строках этой матрицы описываются модели предметной (проблемной) области с позиции различных категорий участников процесса проектирования, к которым относятся представители будущих пользователей системы (заказчиков), проектировщики (консультанты), участвующие в процессе получения и формирования знаний о проблемной области и формулирующие требования к ИС; разработчики и эксплуатационщики ИС.
Проектировщики вместе с заказчиками должны формировать модели предметной (проблемной) области, отражающие содержательную сторону функционирования системы, при этом проектировщики закладывают технологические требования к реализации системы, скрытые от взгляда пользователей.
Таблица 2. Матрица согласованных моделей в архитектурах.
|
Виды моделей и их реализация |
Цели (почему?)
Дерево целей |
Люди (кто?) Архитектура организации |
Функции (как?) Архитек-тура прило-жений |
Объекты-данные (что?) Архитек- тура данных |
Коммуникации (где?) Архитек- тура технологи-ческая |
Время события (когда?) |
1 |
Укрупненная модель организации (планировщик, пользователь) |
Список целей и задач |
Список организаций (подразделе- ний) |
Список процесс-сов |
Список сущностей |
Список узлов |
Список основных событий |
2 |
Концептуальная модель организации (проектировщик, пользователь) |
Стратегичес-кая модель: цель – стратегия. |
Структурные модели: подразделе-ния – работа |
Функцио-нальные модели: процесс – ресурс. |
Информацион-но-логические модели: ER-диаг-раммы |
Модель топологии узлов |
Модель корпоратив-ных событий |
3 |
Системная модель ИС (консультант-проектировщик) |
Критерии достижения целей |
Роли персонала |
Диаграммы потоков данных |
Логическая модель данных |
Логическая модель сетей организации |
Модель системных событий |
4 |
Технологическая модель (разработчик ИС) |
Модель «состояние-действие» |
Модель интерфейса |
Модель приложе- ний |
Модель внутреннего представления |
Физическая модель коммуникаций |
Модель технических событий |
5 |
Компоненты (разработчик ИС, субподрядчик) |
Шаг/задача |
Пользователь – транзакция |
Програм- мные модули |
Базы данных |
Протоколы |
Компонент-ные события |
6 |
Функционирую-щая система (эксплуатацион-щики) |
Варианты исполнения |
Сеансы работы |
Проце- дуры |
Ограничения целостности |
Клиент – сервер |
Операцион-ные события |
На основе модели требований разработчики ИС проводят технологическую детализацию проекта и его последующую реализацию. На основе сформированной рабочей документации и полученного конечного продукта системы эксплуатационщики осуществляют поддержку функционирования системы в новых условиях.
Архитектуры рассматривают систему в разрезе одних и тех же аспектов, но под разными углами зрения.
В качестве основных аспектов построения архитектур рассматриваются следующие:
– цели, бизнес-правила (мотивация того, почему функционирует система);
– объекты (что проходит преобразования);
– функции (как осуществляется преобразование в процессе);
– участники (субъекты) процесса (кто осуществляет процесс);
– место (где выполняется процесс);
– время (временные требования к выполнению процесса, событиям).
В двух первых строках представлены модели, относящиеся к точке зрения будущих пользователей системы, третья строка соответствует взгляду консультанта-проектировщика, четвертая и пятая строки – точке зрения разработчика ИС, шестая строка – точке зрения эксплуатационных служб.