Добавил:
Upload Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз: Предмет: Файл:

Разработка ПО (архитект. ис)

.pdf
Скачиваний:
55
Добавлен:
22.03.2016
Размер:
8.27 Mб
Скачать

Вопрос

Артефакт

Что

Диаграмма классов.

 

Набор таблиц в БД и связей между ними.

Как

Спецификация бизнес-процессов на низкоуровневом языке.

 

Контракт классов

Где

Демилитаризованные зоны

 

Технологии общения между ними.

Кто

Спецификация ролей и их результатов работы в терминах выб

 

технологии

Когда

Спецификация механизмов работы с событиями времени

Зачем

 

Technician perspective / Tool components (Техник перспективные компоненты / Инструментальные)

Роль – разработчик ПО

Решаемая задача – написание программного кода

Основной результат – работающая система

Разрабатывают программу на языке программирования

 

Вопрос

Артефакт

Что

Код создания таблиц в БД

Как

Код реализации методов в классе

Где

Протоколы и спецификации каналов связи

Кто

Реализация прав и ограничений пользователей

Когда

Реализация обработки таймеров, событий и т.п.

Зачем

 

Enterprise retrospective/Operations Instances (Предприятие ретроспективные / Операции Экземпляры)

Роль – пользователи КИС

Решаемая задача – достижение бизнес-целей с помощью КИС

Основной результат – артефакты, соответствующие прописанным результатам работы роли

Работают с системой

Вопрос

Артефакт

Что

Данные, как полученные в результате работы, так и справочни

 

системы

Как

Выполняемый модуль (сама программа)

Где

Функционирование реализованной сети

Кто

Обученные пользователи системы

Когда

История функционирования системы

Зачем

 

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

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

В соответствии с TOGAF термин «предприятие» имеет широкую трактовку. Предприятием называется одна или несколько организаций с общими целями. В этом смысле предприятием может считаться как целая корпорация, так и её подразделение; как государственное учреждение, так и коммерческая фирма или, например, несколько фирм с общими владельцами.

TAGAF дает собственное определение архитектуры, в соответствии с которым архитектура ИС— это формальное описание системы или детальные план системы на уровне компонент, на основании которого осуществляется реализация системы».

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

Домены архитектуры

TOGAF является руководящей основой (framework) для разработки и поддержания архитектуры. В соответствии с TOGAF архитектуру предприятия можно представить в виде четырёх основных доменов:

Бизнес архитектура — определяет стратегию предприятия, структуру управления и ключевые бизнес процессы.

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

Архитектура приложений — определяет интерфейсы отдельных приложений и способы их использования в процессе реализации бизнес-процессов в терминах бизнес-сервисов

Технологическая архитектура — описывает аппаратную, программную и сетевую инфраструктуру.

Архитектор уровня предприятия должен успешно работать в каждом из этих доменов.

Основные компоненты TOGAF:

ADM – метод разработки архитектуры

ADM Guidelines and Techniques – руководство и методика проектирования

Architecture Content Framework – фреймворк содержания архитектуры. Представляет собой отдельную модель результатов разработки архитектуры, в терминах артефактов и архитектурные блоки.

Enterprise Continuum And Tools – континуум предприятия, представляющий собой репозиторий архитектурных артефактов и артефактов реализации.

TOGAF Reference Model – эталонная модель TOGAF. Включает в себя техническую эталонную модель и интегрированную модель информационной инфраструктуры.

Architecture Capability Framework – фреймворк возможностей архитектуры.

Описывает структуру организации, персонал, роли и ответственности.

TOGAF основан на итеративной процессной модели, которая предусматривает повторное использование имеющихся архитектурных компонент. TOGAF включает методологию разработки архитектуры под названием Architecture Development Method (ADM).

В процессе работы над корпоративной архитектурой возникают различного вида результаты: диаграммы процессов, требования к архитектуре, планы проектов по переходу из одного состояние в другое, результаты проведения авторского надзора и т. п. Благодаря Architecture Content Framework (ACF), который является частью TOGAF, все эти объекты–результаты чётко определены и представляют собой целостную систему для архитектурного описания.

Назначение: Типизация артефактов, Описание артефактов, Связь артефактов с ADM

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

Назначение: Управление архитектурными артефактами, Архитектурный репозиторий – что это, как с этим работать; Инструменты для разработки архитектуры

Architecture Capability Framework(Фреймворк архитектурных возможностей). Показывает, с чего надо начинать работу по созданию архитектуры. Какие ключевые действия нужно сделать при создании архитектуры.

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

Если сравнить TOGAF с Захманом, о просматривается различие в подходах. Захман ориентирован на описание некоторой конкретной архитектуры и в его основе лежит таксономия, то в основе TOGAFлежит понятие архитектурного континиума, т.е.

архитектура постоянно находится в процессе изменения, отслеживая изменения бизнестребований, поэтому на первый план выходит ADM.

Значимость управления требованиями(изменениями):

Цели:

Убедитесь, что процесс управления требованиями поддерживается и работает для всех соответствующих этапов ADM

Архитектура управления требованиями, определена при выполнении в любого цикла ADM или фазы

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

При определении требований архитектор должен учитывать:

Предположения для требований

Ограничения для требований

Предметно-ориентированные принципы, которыми управляют требования

Политика влияния на требования

Стандарты, которые должны отвечать требованиям

Организация руководящих принципов для требований

Технические характеристики требований

Шаги:

Определение исходных требований и приоритетов.

Слежение за основными требованиями

Определение изменений требований и приоритетов записей

Обновление информации в хранилище требований

Артефакты:

Требования по оценке воздействия

Обновленная архитектура спецификаций требований

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

TOGAF. ADM. Фазы подготовки (Предварительная фаза и А. Разработка общего представления). Используемые в работе артефакты, ключевые шаги и ключевые артефакты результата.

В соответствии с ADM разработка системной архитектуры состоит из следующих фаз:

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

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

Предварительная фаза.

Цель:

Выявить запросы на архитектурные возможности

Установить архитектурные возможности

Не архитектурные требования

Архитектурные требования

бизнес-модель компании, ее цели

Организационная модель корп.

 

архитектуры:

Главные операционные подходы ведения

 

 

бизнеса(проектная/продуктовая)

Граница задействованных

 

 

организаций

Правовое поле функционирования

Роли и ответственность

 

 

архитектурной команды

компании

Бюджетные ограничения

 

Стратегия управления и поддержки

Архитектурные возможности

 

 

Существующее фреймворки.

Партнерские отношения, заключенные

 

контакты.

 

Шаги:

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

Утверждение фреймворков управления и поддержки

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

Идентификация и установка архитектурных принципов

«Сшивание» TOGAF и других арх. фреймоврков

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

Артефакты:

Организационная модель корпоративной архитектуры:

Задействованные организации

Роли и обязанности архитектурной команды

Ограничение, накладываемые на разработку архитектуры

Бюджетные ограничения

Стратегия управления и поддержки

Адаптированный архитектурный фреймворк

Подготовленный архитектурный репозиторий

Связь с бизнес-принципами, бизнес-целями, бизнес-драйверами

Фреймворк управления архитектурой.

Фаза А. Архитектурное видение.

Цели:

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

Получить подтверждение по плану разработки, описанной в архитектурном виденью.

 

Не архитектурные требования

Архитектурные требования

 

Принципы компании, бизнес-цели и

Артефакты, разработанные на

 

бизнес-драйверы

предыдущем шаге.

 

Запрос на разработку архитектуры (из

 

 

предыдущего шага)

 

Шаги:

 

Учредить архитектурный проект

Выявить стейкхолдеров, их пожелания и бизнес требования

Утвердить и тщательно проработать бизнес-цели, бизнес-драйверы и ограничения.

Оценить возможности бизнеса

Оценить готовность бизнеса к изменениям

Установить границы

Утвердить и тщательно проработать Архитектурные принципы, включая бизнеспринципы

Разработать архитектурное видение

Определить ценностные предложения целевой архитектуры

Выявить бизнес-риски и преобразования и способы их уменьшения

Описать разработку архитектуры и защитить оценку.

Артефакты:

Утверждение описание разработки архитектуры

Уточнение описание бизнес-принципов, бизнес-целей и бизнес-драйверов.

Оценка возможностей

Адаптированный архитектурный фреймворк

Видение архитектуры

Черновой вариант документов определения архитектуры

План коммуникации

TOGAF. ADM. Фазы разработки архитектур (Фазы B – D). Используемые в работе артефакты, ключевые шаги и ключевые артефакты результата.

Фаза B: Бизнес архитектура предусматривает разработку архитектуры деятельности предприятия в соответствии с ранее утвержденным видением. Определение общих принципов функционированияия организации в терминах бизнес-процессов, принципов управления проектов и анализ того, в какой степени результаты деятельности организации соответствуют бизнес-целям. Основные артефакты: структура организации, бизнес-цели, бизнес-функции, бизнес-сервисы, бизнес процессы, основные роли, взаимосвязи между организационной структурой организации и реализуемой функциями.

Фаза C: Архитектура информационных систем. С точки зрения теории, сначала следует разрабатывать архитектуру данных, а затем архитектуру приложений, однако на практике не всегда удается реализовать такой подход, и обычно на данной фазе требуется выполнить несколько итераций.

Фаза D: Технологическая архитектура. Выбор аппаратных средств и сетевой инфраструктуры и механизмов их взаимодействия.

Фаза B:

Цель:

Разработать целевую бизнес-архитектуру

Выявить возможные компоненты «дорожной карты»

Не архитектурные требования

Архитектурные требования

Запрос на разработку архитектуры

Организационная модель корп. арх-ры

Бизнес-принципы, бизнес-цели, бизнес-

Адаптированный архитектурный

драйверы

фреймворк

 

Утвержденный план разработки

Оценка возможностей

архитектуры

План взаимодействия

Архитектурные принципы

 

Корпоративный континуум

 

Репозиторий архитектуры

 

Видение архитектуры

 

Черновики документов

 

 

Шаги:

Выбрать модели для примера, точки зрения и инструменты

Разработать архитектурное описание текущей архитектуры

Разработать архитектурное описание целевой архитектуры

Выполнить анализ расхождений

Определить кандидатов в «дорожную карту(roadmap)»

Организовать формальное ревью стейкхолдеров

Закончить бизнес-архитектуру

Создать документ с архитектурным описанием Артефакты:

Уточненная и обновленная версия видения архитектуры

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

Черновик спецификации требований к архитектуре, включая:

Анализ расхождений

Технические требования

Обновленные бизнес-требования

Фаза С

Цель:

Разработать и обосновать целевую архитектуру данных

С помощью GAPанализа выявить кандидатов на включение в план работ.

Не архитектурные требования

Архитектурные требования

Запрос на архитектурную работу

Организационная модель корп. арх-ры

Оценка возможностей

Адаптированный архитектурный

 

фреймворк

План коммуникаций

 

Принципы данных

Описание архитектурной работы

Видение архитектуры

Черновики определения архитектуры

Черновик спецификации требований к арх:

Результат gap-анализа

Технические требования, относящиеся к этой фазе

Шаги:

Выбрать рефересную модель, точки зрения и инструменты

Разработать описание текущей архитектуры

Разработать описание целевой архитектуры данных

Осуществить gap – анализ

Определить кандидатов в план работ

Разрешить влияние на архитектурный ландшафт

Осуществить формальное ревью стейкхолдеров

Закончить архитектуры данных

Создать документ определения архитектуры данных.

Артефакты:

Уточненная и обновленная версия видения архитектуры

Черновой документ определить архитектуры

Черновой вариант спецификации требований к архитектуре

Компоненты архитектуры данных в плане работ

Фаза D

Цель:

Разработать целевую технологическую архитектуру

С помощью GAPанализа выявить кандидатов на включение в план работ.

Не архитектурные требования

Архитектурные требования

Запрос на архитектурную работу

Организационная модель корп. арх-ры

Оценка возможностей

Адаптированный архитектурный

 

фреймворк

План коммуникаций