Работа выполнена студентами ГИБО-01-14 Воротниковой Светланой и Царьковой Еленой.
Цель работы: создание схемы бизнес-слоя работы аэропорта в программе Archimate.
Описание работы: повторное ознакомление с материалами четвертой лабораторной работы, и на их основе построение схемы работы аэропорта.
Задание: предоставить преподавателю текстовой документ со схемой аэропорта и пояснение каждого вида фрагментов схемы в виде таблицы.
Результат выполнения работы: представлен ниже.
| Название | Описание |
| Открытие рейса | Бизнес событие — открытие рейса |
| Продажа билетов | Бизнес функция следующая за открытием рейса. Выпуск и продажа билетов. |
| Касса | Необходима для произведения оплаты за билеты |
| Обработка платежных данных | Процесс отвечающий за обработку платежей и передающий полученную информацию в модуль обработки платежей |
| Модуль обработки платежей | Объект приложений отвечающий за прием оплаты за билеты, регистрирующий оплату |
| Регистрация | Бизнес процесс подразумевающий получение личной информации от пассажиров, и с их использованием регистрацию пассажиров на рейс |
| Сотрудник регистратуры | Бизнес-исполнитель, обеспечивающий процесс регистрации |
| Распределение мест | Сервис, позволяющий пассажирам самим выбрать свои места в самолете |
| Прием багажа | Получение багажа от пассажиров и его регистрация |
| Сведения о багаже | Данные о багаже, вес, принадлежность, объем |
| Транспортировка багажа до самолетов | Перевоз багажа после регистрации к самолетам |
| Данные о пассажирах | Данные полученные в процессе регистрации пассажиров |
| Сопровождение пассажиров до самолетов | Сервис, позволяющий пассажирам с комфортом доехать до самолетов на автобусе |
| Рассадка по местам и погрузка багажа | Процесс, осуществляемый сотрудниками аэропорта — рассадка пассажиров в соответствии с их местами и погрузка багажа на борт самолета |
| Сотрудники на борту самолета | Бизнес исполнители, а данном случае — стюарты, стюардесы и пилоты |
| Обеспечение безопасности перелета | Бизнес процесс по обеспечению безопасности перелета пассажиров |
| Служба безопасности | Объект, отвечающий за безопасность пассажиров как во время перелета, так и во время ожидания |
| Выделение авиалинии | Процесс резервирования авиалинии для определенного рейса |
| Отдел обеспечения перелетов | Бизнес объект занимающиеся обеспечением авиаперелетов, резервированием маршрутов и авиалиний, отслеживающий перемещение самолетов |
| Общая база данных всех авиалиний | На ее основе происходит выбор авиалинии и маршрута для рейса из возможных и доступных вариантов |
| Файл БД всех авиалиний и маршрутов | Файл с информацией о всех возможных маршрутах и авиалиниях |
| Система видеонаблюдения, проверки и досмотра | Включает в себя комплекс аппаратных средств по обеспечению безопасности в аэропорту, таких как видеокамеры, рамки, и др. |
Лекции по ArchiMate. Лекция 4. Разбираем бизнес слой.
Что такое ArchiMate за 7 минут
Лабораторная работа №6
Работа выполнена студентками ГИБО-01-14 Воротниковой Светланой и Царьковой Еленой.
Цель работы: ознакомление с моделью архитектуры федеральной организации и изучение особенностей ее применения.
Задание:
4. Доклад и презентацию по применению архитектуры FEAF и FEA для правительственных учреждений и ведомств.
5. Развернутый ответ на вопрос: «Почему проект электронная Россия можно отнести к архитектуре FEAF.
Текст доклада.
Архитектура предприятия — это систематизирующая логика основных бизнес-процессов и ИКТ-возможностей организации, зафиксированная в виде набора политик и технических решений. АП является тем набором чертежей бизнес-процессов и систем, которые необходимо подготовить в организации. АП организации описывает платформу делового и технического управления, на которой организация проектирует и создает свои ИТ системы, позволяющие ей быть конкурентоспособной. Как правило, самой крупной организацией почти во всех странах является правительство. Большой размер обычно означает высокий уровень сложности.
АП эффективно поддерживает деятельность компании, стимулирует обмен информацией между отделами и организациями, повышает возможность менеджмента предоставлять услуги более эффективно и своевременно, а также совершенствовать операциональную результативность и исполнительскую дисциплину путем эффективного использования ИКТ.
Электронное правительство подразумевает использование ИКТ для преобразования государственных услуг и административных процессов с целью построения интегрированного правительства. Задача при этом — предоставление необходимых услуг (эффективность) оптимальными и прозрачными методами с высоким уровнем гибкости для удовлетворения потребностей населения и бизнеса.
Основные области взаимодействия для электронного правительства включают «правительство — гражданин» (G2C), «правительство — бизнес» (G2B), «правительство — правительство» (G2G) и «правительство — государственный служащий» (G2E). Для взаимодействий G2C и G2E характерны отношения между органами власти и физическими лицами, тогда как взаимодействия G2G и G2B имеют дело с взаимодействиями органов власти с юридическими лицами.
Страны, реализующие у себя электронное правительство, имеют ряд общих характеристик. Наиболее заметная общая черта — постепенное движение к возрастающей зрелости электронного правительства. Страны проходят различные стадии зрелости, сначала создавая, а затем используя платформу для реализации электронного правительства. На каждом этапе изучаются управленческие процессы и методы применения ИКТ как стратегические возможности.
Архитектура федеральной организации (FEA) — это последняя попытка федерального правительства привести бесчисленное множество агентств к единой и повсеместно используемой архитектуре.
FEA является наиболее полной методологией из всех упомянутых. Она включает и всеобъемлющую таксономию, как в методологии Захмана, и архитектурный процесс, как в модели TOGAF. FEA можно рассматривать и как методологию создания архитектуры предприятия, и как результат применения этой процедуры к конкретной организации.
Архитектура FEA не полностью следует модели Захмана, но тем не менее унаследовала от нее идею формализованного и детализированного описания автоматизированной системы, стадий ее проектирования и внедрения.
Архитектура электронного правительства поддерживается тремя направлениями:
· Эталонные модели Электронного правительства, (Federal Enterprise Architecture (FEA) Consolidated Reference Model Document)
· Методика применения эталонных моделей (A practical guide to Federal Enterprise Architecture)
· Базовая модель оценки состояния архитектуры предприятия. (Enterprise Architecture Assessment Framework)
Эталонные модели задают структуру, методика описывает процесс применения, а модель оценки ориентирована на мониторинг состояния. По каждому из этих направлений есть базовый документ, версии которого периодически обновляются.
Источник: poisk-ru.ru
2. Теоретические сведения, необходимые для выполнения работы
За основное определение архитектуры возьмем определение, данное в стандарте ISO/IEC 15288 [2], где архитектура представляется как фундаментальная организация системы, воплощенная в ее элементах, их взаимоотношениях друг с другом и со средой, а также принципах, направляющих ее проектирование и эволюцию. Во многих монографиях (напр., в [1]) система трактуется в виде набора архитектурных слоев (layers).
В настоящем пособии мы также будем придерживаться этого подхода, так как в большинстве корпоративных приложений прослеживается та или иная форма архитектурного «расслоения», и, хотя в некоторых ситуациях большее значение могут приобретать другие подходы, связанные, например, с организацией каналов (pipes) или фильтров (filters), мы сконцентрируем внимание на архитектуре слоев как на наиболее часто используемой структурной модели. Спецификация ArchiMate [3] выделяет три архитектурных слоя: слой деловой области, слой приложений и технологический слой.
Часто диаграммы для каждого слоя называют, соответственно, архитектурой деловой области, архитектурой приложений и технологической архитектурой. Терминология. Альтернативным термину «деловая область» является термин «бизнес», поэтому в литературе часто можно встретить термины «бизнес-процессы», «бизнес-логика», «бизнес правила» и т.п.
Здесь и в последующих работах мы будем приводить диаграммы для описания деятельности разработчиков учебного проекта с целью более легкого понимания ими своей деятельности и ресурсов, которые потребуются для ее исполнения. Также подобное описание служит основой для разделения работ.
Руководствуясь принятым в данном пособии соглашении об использовании свободно распространяемых средств и технологий разработки, описание каждого вида деятельности, а также описание архитектуры целевой системы мы будем осуществлять в нотации ArchiMate и представлять их в виде диаграмм, сделанных в инструменте поддержки проектирования архитектур Archi. На рис.1.1 представлена диаграмма деятельности по разработке архитектуры системы.
Ниже приведено описание объектов диаграммы. Рис.1.1. Деятельность по разработке архитектуры системы Разработчик 1 – это, так называемый деятель, активный участник проекта. Как было сказано выше, под этим объектом в учебном проекте подразумеваются 2-3 студента-исполнителя проекта. Инженер-архитектор – роль, которую исполняет деятель.
Архитектурная работа – практика уровня деловой области, т.е. набор действий, которые может исполнять деятель для получения нужного результата. Терминология. Процессом обычно называют действие, в результате выполнения которого мы достигаем определенной цели.
Отличительными признаками процесса являются наличие точки старта процесса и конкретный результат по завершении процесса. В отличие от процесса практика не подразумевает ни начала, ни конца, это просто потенциальная деятельность, которую, в том числе, можно использовать для реализации какого-нибудь процесса.
Целевая архитектура – информационный объект уровня деловой области, получаемый в процессе проведения практики «Архитектурная работа» и реализуемый при помощи информационного объекта уровня приложений «Архитектурное описание в ArchiMate». Диаграммы на экране и бумажном носителе – представление информационного объекта «Целевая архитектура».
Для создания архитектуры системы – объект, представляющий смысл данной диаграммы. Создание диаграмм – практика на уровне приложений. Эта практика используется для автоматизации представленной выше практики деловой области «Архитектурная работа».
Архитектурное описание в ArchiMate – информационный объект уровня приложений, представляющий собой совокупность диаграмм, отображающих целевую архитектуру. Редактор ArchiMate – программный компонент, используемый в процессе выполнения практики. Софт Archi 2.0 – артефакт, реализация редактора ApchiMate на технологическом уровне.
Файл ArchiMate (на носителе) и файл ArchiMate (распечатанный) – артефакты технологического уровня, представляющие физическую реализацию информационного объекта «Архитектурное описание в ArchiMate». ПК-1 – узел, включающий в себя стационарный компьютер и системное программное обеспечение (ПО), установленное на нем и представляющее из себя операционную систему MS Windows 7. Замечание.
Раньше отмечалось, что в учебном проекте используются только свободно распространяемые средства. MS Windows 7 не относится к такому роду средств. Тем не менее, по наблюдению авторов на большинстве компьютеров в технических ВУЗах установлена именно эта операционная система, что необходимо учесть. При этом авторы отмечают, что все описанные в пособии подходы, инструменты и механизмы без дополнительных настроек могут быть применены под операционными системами семейства Unix. Ниже представлены рабочие задания, на основе которых будет построена архитектура системы анкетирования слушателей образовательных учреждений в режиме удаленного доступа.
Ограничение
Для продолжения скачивания необходимо пройти капчу:
Источник: studfile.net
Документирование архитектуры: введение (remastered)
Прочел статью Документирование архитектуры: введение и решил описать изложенное с другим подходом.
Диаграммы не буду расписывать в текст, попробуйте прочесть их на языке Archimate. Представьте, что вы расшифровываете египетское иероглифическое письмо. Вот подсказка — набор символов для расшифровки Summary of Language Notation
Описание мотивации и стратегии
Напомню введенное ранее мной определение:
Архитектура – это проектное решение, которое набор проектных решений организует в Систему, соответствующую целевому назначению.
Значит нужно определится с целевым назначением системы. Напрямую цели и требования нам не заданы, но можно рассмотреть всё более масштабно используя подход JTBD.
Слой бизнеса и слой приложений
Допустим, что «Человек» из имеющихся альтернатив выбрал информационный продукт «Блог».
Продукт цифровой, поэтому слой бизнеса (функциональная архитектура) и слой приложений (прикладная архитектура) можно стыковать сразу.
При этом сервисы «Комментирование» и «Управление комментариями» пока не будут использоваться, так как модерация требует ресурсов времени.
Технологический слой (технологическая архитектура)
Для ведения блогов есть много платформ, «с нуля» ничего реализовывать не нужно. Для выбора конкретной платформы нужно на основании требований (которые, увы, не заданы) составить сравнительную таблицу. Можно дополнить ее другими критериями. Тут я думаю всё понятно. Допустим выбрали Ghost CMS, Apache HTTP Server и MySQL.
Теперь нужно разместить это всё в какой-нибудь инфраструктуре, которую тоже выберем по соответствующим критериям. Пусть будет GCP.
Резюме
Ну вот как бы и всё. Да, я понимаю, что мало объяснений.
Какие могут возникнуть вопросы:
1) Можно ли разместить всю информацию на одном изображении?
Ответ: Да, если требуется проконтролировать связанность. Но нужно соблюдать баланс и аккуратно стыковать слои (бизнес, прикладной и технологический и др.). Чем меньше различных диаграмм вы создадите, тем меньше вероятность получить рассогласование. Чем больше элементов на диаграмме, тем сложнее понять смысл. Поэтому нужен баланс.
2) Можно ли использовать концепцию Viewpoint?
Ответ: Да, но следите чтобы диаграммы (Views) непротиворечиво стыковались друг с другом, иначе потом придется согласовывать людей, которые прочли ваши диаграммы. см. п. 1)
- Анализ и проектирование систем
- Проектирование и рефакторинг
Источник: habr.com