Мегаобучалка Главная | О нас | Обратная связь


Основные аспекты построения архитектур



2019-12-29 254 Обсуждений (0)
Основные аспекты построения архитектур 0.00 из 5.00 0 оценок




 

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

─ цели, бизнес-правила (мотивация того, почему функционирует система);

─ участники процесса (кто осуществляет процесс);

─ функции (как осуществляется преобразование в системе);

─ объекты – данные (что проходит процесс преобразования);

─ место (где осуществляется процесс);

─ время (графики событий, временные требования к выполнению процесса).

Виды моделей и их отображение в различных архитектурах показаны в таблице

3.1.

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

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

· бизнес среда системы,

· концептуальная модель,

· логическая модель,

· технологическая, «физическая модель»,

· детальная реализация (часто поблочная),

· представление пользователя (эксплуатация).

 

Таблица 3.1. Матрица согласованных моделей в архитектурах.

Виды моделей и их реализация Цели (почему?) Дерево целей Люди (кто?) Архитек-тура орган-изации Функции (как?) Архитек-тура прило-жений Объекты--данные (что?) Архитек- тура данных Коммуникации (где?) Архитек- тура  техноло-гическая Время (когда?)
1 Укрупненная модель организации (планировщик, пользователь)   Список целей и задач   Список организа-ций (подразде-лений)   Список процессов   Список сущностей   Список узлов   Список основных событий
2 Корпоративная модель организации (пользователь) Стратеги-ческая модель: цель – стратегия. Структур-ные модели: подразде-ления – работа Функци-ональные модели: процесс – ресурс. Информаци-онно-логические модели: ER-диаг-раммы   Модель топологии узлов   Модель корпора-тивных событий
3 Системная модель ИС (консультант-проекти-ровщик) Критерии достиже-ния целей   Роли персонала Диаграм-мы потоков данных Логическая модель данных Логическая модель сетей организации Модель системных событий
4 Технологическая модель (разработчик ИС) Модель «состояние-действие» Модель интер-фейса   Модель приложе- ний Модель внутреннего представ- ления Физическая модель комму-никаций Модель технических событий
5 Компоненты (разработчик ИС, субподрядчик)   Шаг/задача   Пользо-ватель – транзакция Програм- мные модули   Базы данных   Протоколы   Компонент-ные события
6 Функциони-рующая система (эксплуата-ционщики)   Варианты исполнения   Сеансы работы   Проце- дуры Ограниче- ния целост- ности   Клиент – сервер   Операцион-ные события

 

 

Описанные разделы и уровни схемы Захмана являются классификацией сущностей предприятия и его информационной системы.

Участники проекта.

 

Организация работ по проектированию определяется порядком взаимодействия между всеми сторонами-участниками. Так при проектировании информационной системы (ИС) участниками процесса являются: инициатор проекта, пользователи, заказчики и разработчики.

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

Пользователь - это административно-управленческий аппарат, для которого создаётся эта система.

Заказчик - это ответственное лицо (организация, подразделение), которое выполняет функции:

─ формулирует требования к системе и её частям;

─ выдает (утверждает) техническое задание;

─ финансирует разработку информационной системы;

─ обеспечивает проведение комплекса мероприятий по её созданию;

─ проводит приём проекта ИС и внедрение.

Разработчик – это ответственное лицо (организация, подразделение), которое выполняет следующие функции:

─ разрабатывает ИС по техническому заданию заказчика;

─ принимает участие во внедрении;

─ осуществляет сдачу проекта заказчику;

─ осуществляет авторское сопровождение проекта.

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

С другой стороны, заказчик отслеживает, контролирует - осуществляет мониторинг:

─ правильности реализации требований технического задания на ИС;

─ научно - технического уровня разработок;

─ сроков проведения работ;

─ качества проектной документации;

─ правильности расхода денежных ресурсов - выполняемых разработчиком.

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

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

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

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

Этот подход не определяет собственно методы построения моделей проблемной области, однако методологии моделирования проблемных областей предполагают реализацию принципов последовательной детализации абстрактных категорий: целей, объектов, функций, организационных единиц, и т.д. на уровнях определения требований к системе, их спецификации и реализации.

 

Процессный подход.

 

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

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

Концепция управления бизнес-процессами в различной степени реализована в следующих подходах: MRP (Manufacturing Resource Planning) – планирование ресурсов производства; TQM (Total Quality Management) - всеобщее управление качеством; BPR (Business Process Reengineering) – реинжиниринг бизнес-процессов.

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

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

Система управления бизнес – процессом предприятия включает действия по преобразованию входов в выходы, систему сбора информации о показателях процесса, систему анализа полученной информации и принятия управленческих решений лицом, ответственным за эффективность процесса, систему непрерывного улучшения показателей процесса и корректирующих действий по устранению причин отклонений в ходе бизнес-процесса. Как и любая система управления, система процессного управления предприятием состоит из компонентов: «Процесс» - объект управления, «Владелец процесса» - субъект управления рис.3.3.

 

 

Рис.3.3. Концептуальная схема управления процессом.

 

 

Владелец процесса – это должностное лицо, наделённое правами и полномочиями, а также ресурсами, необходимыми для выполнения процесса, и несущее ответственность за результат процесса.

Ресурс – это материальный или информационный объект, постоянно используемый для выполнения бизнес – процесса, но не являющийся его входом. К ресурсам относят информацию, персонал, оборудование, программное обеспечение, инфраструктуру, транспорт, связь и др.

Ресурсы находятся под управлением владельца, и их объём планируется на большое количество циклов, т.е. на длительный период работы.

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

Примерами выходов бизнес – процессов являются такие объекты как: готовая продукция, документация, информация (в частности отчётная), услуги и т.п.

Таким образом, выход (продукт) – материальный или информационный объект или услуга, являющийся результатом выполнения бизнес – процесса и потребляемый внешними по отношению к процессу клиентами.

Вход бизнес–процесса – продукт, который при выполнении бизнес – процесса преобразуется в выход и должен иметь своего поставщика. К входам бизнес – процесса могут относиться такие составляющие как сырьё и материалы, полуфабрикаты и комплектующие изделия, документация и информация, персонал (в системе «Кадры»), услуги и т.п.

Выходы, входы и ресурсы – являются материальными объектами.

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

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

Если рассматривать деятельность предприятия или организации в целом, то для описания используются укрупненные процессы. Примером процесса верхнего уровня может быть процесс закупок сырья и материалов для производства, который включает такие функции, как: планирование закупок, заключение договоров, оформление заказов, получение товарно-материальных ценностей (ТМЦ), оплату ТМЦ, отпуск ТМЦ в производство. Число уровней декомпозиции процессов определяется задачами проекта, и не должно быть слишком большим - более 7 уровней. При определении бизнес – процессов, существующих на предприятии, целесообразно начинать описание с верхнего уровня. Одним из важнейших вопросов, возникающих при моделировании бизнес – процессов, является определение необходимой глубины описания. При проведении декомпозиции моделей количество объектов на диаграмме растет в геометрической прогрессии. Важно изначально определить практически целесообразную степень детализации описания.

Верхний уровень описания бизнес – процессов соответствует процессам, которыми управляют заместители генерального директора. Второй уровень процессов, как правило, рассматривается на уровне крупных функциональных подразделений предприятия. Третий уровень – уровень функций подразделений и отделов. Четвертый уровень – функции, выполняемые на рабочих местах, и т.д.



2019-12-29 254 Обсуждений (0)
Основные аспекты построения архитектур 0.00 из 5.00 0 оценок









Обсуждение в статье: Основные аспекты построения архитектур

Обсуждений еще не было, будьте первым... ↓↓↓

Отправить сообщение

Популярное:
Как вы ведете себя при стрессе?: Вы можете самостоятельно управлять стрессом! Каждый из нас имеет право и возможность уменьшить его воздействие на нас...
Генезис конфликтологии как науки в древней Греции: Для уяснения предыстории конфликтологии существенное значение имеет обращение к античной...
Как распознать напряжение: Говоря о мышечном напряжении, мы в первую очередь имеем в виду мускулы, прикрепленные к костям ...



©2015-2024 megaobuchalka.ru Все материалы представленные на сайте исключительно с целью ознакомления читателями и не преследуют коммерческих целей или нарушение авторских прав. (254)

Почему 1285321 студент выбрали МегаОбучалку...

Система поиска информации

Мобильная версия сайта

Удобная навигация

Нет шокирующей рекламы



(0.01 сек.)