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

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

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

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

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

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

Контекст архитектурного описания:

Stakeholders – любая группа внутри или вне организации, заинтересованная в результатах ее работы(собственник, работник, покупатель, гос-во, поставщик …).

Архитектурное описание:

Представление - выражение и описание системы с точки зрения интереса стейкхолдера.

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

Архитектурный фреймворк - Определенный взгляд на разработку архитектуры (Набор viewpoints)

Модель бизнеса с точки зрения IT (по GRAAL)

GRAAL - Architecture IT and Business alignment framework Модель предприятия с точки зрения ИТ:

Бизнес-окружение предприятия (business environment)

Бизнес предприятия (business)

КИС (enterprise software system)

Информационная инфраструктура (software infrastructure)

Физическая инфраструктура (physical infrastructure)

Представления системы: системный аспекты, композиция системы (разделение на подсистемы), жизненный цикл.

Примеры:

Системные аспекты:

Композиция:

Жизненный цикл:

------------------------------------------------------------------------------------------------------------------------------------------

Пример матрицы объединяющие все это (вроде как).

Роль архитектора. Типы архитекторов. Понятие фреймворка компетенций. Требование, предъявляемые к архитектору.

Роль архитектора – поддержка бизнеса с помощью информационных технологий.

роль архитектора предприятия EA — осуществлять надзор за выполнением программы на стратегическом уровне. Программа — это несколько связанных друг с другом проектов, объединенных в один пакет. Для управления программами, как правило, требуется специалист, способный рассматривать проект в нескольких аспектах одновременно.

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

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

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

Жизненные циклы технологий - Эта функция определяет порядок изменения и смены версий отдельных технологий и стандартов

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

Архитектурная стратегия - охватывает все стратегические области ИТ

Поддержка стратегических проектов - обеспечивает грамотное проектирование.

Типы архитекторов:

Главная задачи ИТ-архитектора: В соответствии с бизнес-моделью предприятия увеличивать значимость полезных эмерджентных свойств и уменьшать влияние негативных эмерджентных свойств.

Эмердже́нтность в теории систем — наличие у какой-либо системы особых свойств, не присущих её элементам, а также сумме элементов, не связанных особыми системообразующими связями; несводимость свойств системы к сумме свойств её компонентов; синоним — «системный эффект».

Архитектор ПО - Часто имеет полные права и ответственность за проектное решение и качество КИС.

Фреймворк компетенция :

Компетенция

Фреймворк компетенций – состоит из пирамиды компетенций Пирамида компетенций:

И Профессиональные компетенции:

Общие навыки Менеджерские:

Устное общение

Письменное общение

Лидерство

Управление проектами

Управление программами

Управление портфолио

Управления изменениями Консультирования:

Обучаемость

Умение вести переговоры

Наставничество

Культурные:

Ориентация на бизнес

Ориентация за заказчика Группы характеристик:

Экстравертированность

Общительный

Инициативный, энергичный

Готовый браться за вызовы

Убедительный

Приятность в общении

Командный игрок

Чуткий

Умеет слушать

Заслуживающий доверия

Добросовестность

Аналитический склад ума

Организованный и систематичный

Ориентированный на результат

Надежный

Решительный

Внимательный к деталям, тщательный

Упорный

Эмоциональная стабильность

Открытость к творчеству

Творческий

Умение абстрактно мыслить

Умение учится на опыте

Фреймворк Захмана. Правила использования, достоинства и недостатки. Значимость фреймворка.

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

Примеры фреймворков:

Zachman framework (Фреймворк Захман)

Department of Dependence Architecture Framework

Federal Agency Architecture Framework

Tele Management Forum Frameworx

The Open Group Architecture Framework

Структура фреймворка

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

Перспектива: Точка зрения, относительно которой описывается организация. Можно считать – роль, которая отвечает на вопросы исходя из своих интересов к системе.

6вопросов:

Что – данные

Как – процессы/функции

Где – сетевое взаимодействие

Кто – участники процесса

Когда – временные характеристики

Зачем – мотивация

Правила работы:

Колонки можно переставлять, но их состав должен быть неизменным (фреймворк сбалансирован)

Каждой колонке соответствует собственная модель

Каждому столбцу соответствует уникальная модель

Каждая строка – точка зрения одного стейкхолдера системы

Каждая из ячеек уникальна

Заполнение производится сверху вниз по столбцу

Ограничения фреймворка:

Нет четкого описания

Нет конкретной методики

Отсутствие возможности описать переход из текущего состояние в требуемое состояние

Есть решение, добавляющее третье измерение - время

Нет механизма отслеживания структуры изменений

Какие ячейки нужно изменить после изменений X

Нет привязки к языкам моделирования/описания

Есть сторонние исследования на эту тему

Недостатки:

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

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

Достоинства:

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

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

------------------------------------------------------------------------------------------------------------------------------------------

Модель предприятия с точки зрения ИТ:

Бизнес-окружение предприятия (business environment)

Бизнес предприятия (business)

КИС (enterprise software system)

Информационная инфраструктура (software infrastructure)

Физическая инфраструктура (physical infrastructure)

Executive perspective /Scope context (Исполнительный перспектива / контекст Сфера)

Роль – аналитики

Решаемая задача – идентификация

Основной результат – списки

Описывают контекст, выявляют основные объекты (в широком смысле слова), с которым затем будет происходит работа

Вопрос

Артефакт

Что

Опись сущностей (объектов)

Как

Список бизнес-процессов

Где

Список месторасположений

Кто

Список лиц и организаций (стейкхолдеров)

Когда

Список бизнес-циклов (цикл продаж, цикл разработки и т.п.)

 

Список важных событий

Зачем

Список бизнес-целей (увеличение доли на рынке, повышение

 

лояльности и т.п.) Может быть на уровне миссии

Business management perspective / Business concepts (Управления бизнесперспектива / бизнесконцепции)

Роль – собственники бизнеса

Решаемая задача – определение

Основной результат – бизнес-модель компании

Описывают бизнес компании

Вопрос

Артефакт

Что

Сущности бизнеса (сущность = класс в ООП)

 

Взаимоотношения между сущностями

Как

Определение бизнес-процессов

Где

Месторасположения и их взаимоотношения

Кто

Определение обязанностей: определение бизнес-ролей и

 

результатов их работы

Когда

Время выполнения бизнес-циклов и процедур

 

Даты событий.

Зачем

Конкретные бизнес-цели, зависимости друг от друга.

Architect perspective /System Logic (Архитектор перспектива / системной логики)

Роль – IT-архитектор

Решаемая задача – построение IT-архитектуры

Основной результат – архитектурное описание

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

Вопрос

Артефакт

Что

Системное описание сущностей и связей между ними

Как

Системное представление процессов

Где

Месторасположения и логические связи между ними

Кто

Роли в информационное системе

 

Интерфейсы пользователя

Когда

Представление времени в системе. Например – справочник

 

событий, справочник нормативов выполнения работ.

Зачем

Цель создания и работы системы

 

Значимость системы

Business management vs Architecture (Бизнес Управленческий против архитектуры)

Бизнес управление

Взгляд со стороны специалиста в предметной области (т.е. бизнеса)

Например – схемы БД не нормализованы

Роли выражены описаны по организационным документам компании

Архитектор

Взгляд со стороны разработчиков ПО

Например –схема БД нормализованы

Роли описаны с точки рения RBAC или других систем понятий

Engineer perspective /Technology Physics (Инженер перспектива / Физика Технологии)

Роль – архитектор ПО

Решаемая задача – детальный ООП-дизайн приложения

Основной результат – набор спецификаций

Требования на реализацию продукта, детальный дизайн ПО