Разработка ПО (архитект. ис)
.pdfПонятие архитектуры. Отличие архитектуры от архитектурного описания. Точка зрения и представление. Понятие архитектурного фреймворка.
Архитектура - фундаментальные понятия или свойства системы в ее среде, воплощенной в ее элементах, отношения, и в принципах его проекта и развития.
Архитектурное описание - результат проектирования программного обеспечения и систем, описывающий архитектуру.
Контекст архитектурного описания:
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 (Инженер перспектива / Физика Технологии)
•Роль – архитектор ПО
•Решаемая задача – детальный ООП-дизайн приложения
•Основной результат – набор спецификаций
•Требования на реализацию продукта, детальный дизайн ПО