CUSTIS, profile picture
Uploaded byCUSTIS
PDF, PPTX1,388 views

Архитектура в IT: философия и практика

Документ обсуждает архитектуру в IT, подчеркивая ее значение и сложность в разработке корпоративных информационных систем. Архитектура рассматривается как набор решений, которые влияют на успешность проекта, а также как способ согласования действий среди участников процесса. Также в документе упоминаются различные стандарты архитектуры и критерии качества, которые необходимы для эффективного проектирования систем.

Embed presentation

Download as PDF, PPTX
1 / 111
2 / 111
3 / 111
4 / 111
5 / 111
6 / 111
7 / 111
8 / 111
9 / 111
10 / 111
11 / 111
12 / 111
13 / 111
14 / 111
15 / 111
16 / 111
17 / 111
18 / 111
19 / 111
20 / 111
21 / 111
22 / 111
23 / 111
24 / 111
25 / 111
26 / 111
27 / 111
28 / 111
29 / 111
30 / 111
31 / 111
32 / 111
33 / 111
34 / 111
35 / 111
36 / 111
37 / 111
38 / 111
39 / 111
40 / 111
41 / 111
42 / 111
43 / 111
44 / 111
45 / 111
46 / 111
47 / 111
48 / 111
49 / 111
50 / 111
51 / 111
52 / 111
53 / 111
54 / 111
55 / 111
56 / 111
57 / 111
58 / 111
59 / 111
60 / 111
61 / 111
62 / 111
63 / 111
64 / 111
65 / 111
66 / 111
67 / 111
68 / 111
69 / 111
70 / 111
71 / 111
72 / 111
73 / 111
74 / 111
75 / 111
76 / 111
77 / 111
78 / 111
79 / 111
80 / 111
81 / 111
82 / 111
83 / 111
84 / 111
85 / 111
86 / 111
87 / 111
88 / 111
89 / 111
90 / 111
91 / 111
92 / 111
93 / 111
94 / 111
95 / 111
96 / 111
97 / 111
98 / 111
99 / 111
100 / 111
101 / 111
102 / 111
103 / 111
104 / 111
105 / 111
106 / 111
107 / 111
108 / 111
109 / 111
110 / 111
111 / 111
Архитектура в IT: философия и практика Михаил Заборов Архитектор, руководитель стратегических проектов 31 октября 2013 года
занимается разработкой больших (40–100 человеко-лет) корпоративных информационных систем на заказ 2/110
Обо мне   >10 лет в компании  Работаю в одной из групп развития бизнеса Участвовал в существенной части проектов компании в качестве руководителя и архитектора 3/110
Философский блок 4/110
? Понятно ли вам, что такое архитектура? 5/110
Архитектура как Buzzword  Разговоры с упоминанием архитектуры ведутся постоянно и повсеместно   Каждый понимает под этим словом что-то свое Известно несколько сотен формальных определений архитектуры  Многие формулировки носят характер скорее эмоциональных высказываний, чем определений  Многие определения существенно неполны (описывают только один из аспектов)  Существующие стандарты описывают, что такое архитектура, слишком абстрактно и интуитивно 6/110
! Когда у нас слишком абстрактное и интуитивное представление об объекте, мы не можем с ним реально ничего сделать. А если этот объект критически влияет на успех проекта, то мы становимся заложниками случая и стечения обстоятельств. Мы не можем существенно влиять на результат. 7/110
Конфуций: Первейшей задачей управления является выбор правильных названий... Если названия неверны, то язык не будет соответствовать правде. Если язык не будет соответствовать правде, тогда вещи не достигнут совершенства. Если вещи не достигнут совершенства, то церемонии и музыка не будут процветать. Если церемонии и музыка не будут процветать, то наказания не будут справедливыми. Если наказания не будут справедливыми, люди не будут знать, что нужно делать. Поэтому начальник должен давать только такие названия, которые могут быть выражены словами, а приказывать только то, что может быть выполнено на практике.
Термин заимствован из строительства Термин «архитектура» применительно к IT впервые появился в 1960-х, однако начал широко использоваться только в начале 1990-х 9/110
Замечено, что системы с хорошей архитектурой значительно чаще достигают поставленных целей, меньше стоят и дольше «живут» 10/110
Попытка сформулировать понятие «архитектура» более строго      В какой системе находится С чем взаимодействует Как устроена внутри Какие функции выполняет Каковы последствия от ее отсутствия 11/110
Система, в которой находится архитектура i Большая часть терминов заимствована из стандарта ISO/IEC/IEEE 42010 12/110
Архитектура приложения и архитектура предприятия (Enterprise Architecture)     TOGAF Захман FEAF Over 9000  ISO/IEC/IEEE 42010  IEEE 1471:2000 13/110
Stakeholder, который хочет что-то сделать с изделием 14/110
Stakeholder’ов много и у них много разных интересов 15/110
Перейдем к ИТ 16/110
Система производства приложения (простой вариант) Выпуск релизов 17/110
Риски 18/110
Система производства приложения (более сложный вариант) Выпуск релизов
Система представлений о внутреннем устройстве приложения  Состоит из решений1 о внутреннем устройстве (конструкции) приложения  Решения находятся в отношении зависимости 1Мы используем термин утверждение 20/110
Решение B зависит от решения A A Базовое B Зависимое (детализирующее)  Изменение A неизбежно влечет за собой пересмотр B  Бывают ситуации, когда не очевидно, какое решение базовое 21/110
Зависимости между решениями A B C Решения выстраиваются в цепочки A Решение может зависеть от нескольких решений B C D 22/110
Граф решений Сложнее (дороже) пересматривать Более базовые Более детальные Проще (дешевле) пересматривать 23/110
Слои графа решений Граф решений 24/110
Grady Booch, Martin Fowler: Архитектура – это все решения, которые, сделав однажды, затем трудно изменить. 25/110
Вывод У приложения нет архитектуры; она есть у людей, которые его модифицируют 26/110
Соответствие архитектуры и продукта 27/110
! Вывод Что входит в архитектуру, а что нет, – не всегда следствие решения архитектора. Архитектор скорее выявляет архитектурные решения, чем принимает их. Одна из главных задач архитектора – чувствовать последствия решений (что будет действительно важным, а что – нет). 28/110
Решения удобно формировать группой (в виде моделей) 29/110
При этом модель может фиксировать решения разных уровней значимости 30/110
Одна из самых важных моделей – схема функциональных блоков 31/110
Software Engineering Institute: Архитектура – это структура вычислительной системы, которая включает программные компоненты, внешние свойства этих компонентов, а также отношения между ними. 32/110
Архитектура – сложный объект View Аспекты Viewpoint Слои 33/110
Связь технологии и архитектуры  Деятельность архитектора направлена на изготовление конкретного (одного) изделия. Архитектура описывает именно его  Деятельность технолога направлена на повышение эффективности и качества процесса изготовления изделия (обычно для массовых операций)  Технология предоставляет архитектору кирпичи (материал), из которого архитектор может делать все более сложную архитектуру 34/110
Возможность не принимать решение повторно Решения, определяемые технологией 35/110
Функции архитектуры в процессе производства Изменение системы производства Запрос на изменение Δ изменения продукта 36/110
Функции архитектуры 1. Используется как модель приложения 2. Нормирует и технологизирует работы по проектированию 3. Минимизирует риски 4. Используется как контракт в части SCOPE 37/110
1. Архитектура как модель приложения Модель объекта – это что-то, что позволяет отвечать на вопросы об объекте 38/110
Декомпозиция работ по изменению    Разделение работы на независимые части Запуск параллельных потоков работ Интеграция результатов работ Подзадача 1 Исходная задача Подзадача 2 Подзадача 3 Результат 39/110
Анализ зависимостей (что будет, если) Incredible Machine
Оценка масштаба (класса) предлагаемых изменений  Просто или сложно? http://domvsegda.ru/ 41/110
2. Нормирование и технологизация работ по проектированию 42/110
Локализация места модификации приложения 43/110
Минимизация пересмотра принятых ранее решений A’ Приложения с хорошей архитектурой меньше подвержены постоянным переделкам 44/110
Определение с сайта SEI (какой-то индус ): A good architecture is that which is totally secured, which can accommodate future changes without affecting the software as a whole, and which has no redundant functionalities. 45/110
Минимизация пересмотра принятых ранее решений  Возможность посмотреть вперед и представить, как будет выглядеть изделие в целом Continuous Refactoring 46/110
Согласование действий проектировщиков  Архитектурные решения выполняют функцию соглашения между всеми участниками процесса  Минимизация объема проектирования для типовых задач 47/110
Питер Хрущка: Архитектура – способ координировать умы. 48/110
3. Минимизация рисков 49/110
Описание работоспособной конструкции в целом Нарисованная архитектура – гарантия того, что это вообще будет построено 50/110
Андрей Вербицкий: Хорошая архитектура – это удачный компромисс между желаниями и ограничениями. 51/110
Определение ключевых элементов конструкции, обеспечивающих качество продукта Несущие стены 52/110
Анатолий Левенчук: Архитектура – это то, каким образом конструкция поддерживает требуемую функцию/назначение системы. 53/110
4. Архитектура как контракт в части SCOPE 54/110
Фиксация назначения и границ продукта А также задач, которые в принципе могут этим продуктом решаться 55/110
Определение реальных потребительских свойств приложения 56/110
В результате мы получили модель, которая позволяет вести более содержательные разговоры об архитектуре Например, задавать вопросы по конкретным функциям и диагностировать проблемы более точно «С архитектурой все плохо» 57/110
! Качество архитектуры определяется ее способностью выполнять перечисленные функции. 58/110
Оценка качества архитектуры  Не отражает актуальное внутреннее устройство приложения Не работает как модель приложения  Структура модулей – «поперек» возникающих задач Не помогает декомпозировать большие задачи  Внесение изменений приводит к непредсказуемым последствиям Не помогает локализовать изменения  Необходимые изменения в системе требуют постоянного пересмотра базовых решений Не обеспечивает минимизацию пересмотра решений  «Разношерстные» решения типовых задач Не выполняет функцию координации 59/110
Качество процесса управления архитектурой  Случайные решения становятся базовыми Решение приняли походя, а от него теперь многое зависит. Нет осознанного управления архитектурой  Проектировщики нижнего уровня не руководствуются базовыми решениями Не выполняется функция нормирования. Теряется целостное представление об устройстве приложения  Базовые решения не пересматриваются вовремя Воспринимаются как жесткие ограничения. Несмотря на очевидные проблемы при принятии решений на более детальном уровне 60/110
Методологический блок 61/110
Стандарты по архитектуре (предприятия)  Таксономия и образцы моделей  Zachman Framework  FEAF  TEAF  Методы разработки архитектуры  TOGAF (ADM)  FEAF  EAP 62/110
Питер Хрущка arc42.org 63/110
Качество ПО Заказчик обычно не готов платить за качество; он просто ожидает его 64/110
Критерии качества (Quality Goals) – часть замысла        Безопасность Расширяемость Простота использования Надежность (Robustness) Настраиваемость Производительность Гибкость 65/110
Приоритизация критериев качества  Нужно выбрать небольшое (3–5) число ключевых критериев  Приоритизировать их (определить, что в случае конфликта целей мы приносим в жертву) 1 Простота использования 2 Безопасность 3 Расширяемость 66/110
Критерии качества системы «Розничный магазин» Приоритет Цель Описание Магазин должен функционировать во что бы то ни стало 1 Устойчивость к сбоям 2 Магазины находятся в отдаленных точках; нет возможности индивидуально настраивать Настраиваемость и сопровождаемость каждый. Нужно уметь удаленно и просто настраивать систему под особенности магазина 3 Простота использования Для рядовых сотрудников магазина 4 Скорость реакции Интерфейсы должны реагировать достаточно быстро, чтобы не раздражать покупателей 5 Расширяемость Мы должны успевать вносить изменения, которые просит Заказчик 67/110
Критерии качества Функциональность  Пригодность  Точность  Способность к взаимодействию  Защищенность  Расширяемость  Соответствие стандартам и правилам Надежность  Стабильность  Отказоустойчивость  Восстанавливаемость  Соответствие стандартам и правилам DIN/ISO 9126 (++) Потребительские свойства  Понятность  Простота использования  Обучаемость  Пригодность  Привлекательность  Соответствие стандартам и правилам Эффективность  Времяемкость  Производительность  Ресурсоемкость  Соответствие стандартам и правилам Внешнее качество Сопровождаемость  Изменяемость  Устойчивость  Тестируемость  Открытость  Соответствие стандартам и правилам Переносимость  Адаптируемость  Встраиваемость  Cосуществование  Заменяемость  Соответствие стандартам и правилам Внутреннее качество Переносимость  Эффективность  Продуктивность (результативность)  Производительность  Эксплуатационная безопасность  Удовлетворенность заказчика Эксплуатационные качества 68/110
Требования к качеству Функциональные требования Требования к качеству Нефункциональные требования Ограничения 69/110
Дерево качества A B При любом сбое системы нужно иметь возможность продать товар Товар можно продать, даже если его нет в остатках Устойчивость к сбоям Качество системы «Розничный магазин» Настраиваемость и сопровождаемость Простота использования Скорость реакции Возможна временная недоступность каналов связи Цены все равно должны обновляться из офиса A C Настройка новой кассы должна происходить автоматически Большая часть настроек должна производится централизовано из офиса Новый сотрудник должен выполнять большую часть функций через 2-3 дня работы в паре с опытным сотрудником Время обслуживания покупателя не должно увеличиваться из-за взаимодействия с системой Получение заказов из интернет-магазинов Расширяемость Подключение новых типов оборудования Интеграция с системой безопасности 70/110
Состав архитектуры Структура Аспект функциональных блоков Аспект внедрения и инсталляции (Building Block View) (Deployment View) Аспект исполнения (Runtime View) Архитектурные концепции Сохраняемость, пользовательские интерфейсы, эргономика, управление транзакциями, управление сессиями, безопасность, сетевое взаимодействие, распространение, проверка, обработка исключений и ошибок, администрирование и сопровождение, логирование, отчетность, конфигурирование, параллелизация и многопоточность , интернационализация, миграция, тестируемость, масштабируемость, кластеризация, высокая доступность, катастрофоустойчивость. 71/110
Структура Функциональные блоки Внедрение и инсталляция Статическая структура функциональных блоков и их зависимости Инфраструктура ПО Статика Исполнение Динамика   Взаимодействие блоков _ _ _ Структура является «абстракцией кода» Должна отражать его реальное устройство и состояние 72/110
Аспект функциональных блоков (Building Block View) Этот аспект – основной, остальные – вспомогательные (позволяют посмотреть на систему под другим углом). 73/110
Функциональный блок  Building Blocks (функциональные блоки) – это блоки, из которых строится программный код. В разных языках и средах программирования это могут быть:  function, procedure, subroutine, method, array, record  class, unit, table  module, package, library, component, schema  layer, framework, schema  application, subsystem, database Могут быть и другие специфические блоки 74/110
Иерархия блоков Контекстная диаграмма Система Внешние приложения Детализация Система как белый ящик B A Детализация Блок A как белый ящик Детализация Блок B как белый ящик A2 B2 A1 B1 A3 75/110
Количество уровней 10 LOC Метод 100 LOC Класс 1’000 LOC Модуль 10’000 LOC Компонент 100’000 LOC Подсистема 1’000’000 LOC Система Достаточно описания в коде Нужны архитектурные модели 76/110
Контекстная диаграмма Распределительный центр Система товародвижения Система лояльности Каталог товаров Розничный магазин Система безопасности Бухгалтерия Покупатель Администратор Продавец Кладовщик 77/110
Варианты организации блоков       DDD Layers Pipes & Filters Model & View Controler … Over 9000 78/110
DDD .  Основная идея – отделить Блоки Человеко-машинного интерфейса  блоки с предметной областью  от блоков с технологией  Структура Предметной области Это имеет смысл, поскольку различаются:  stakeholder’ы  логика развития  жизненные циклы Сервисы Интерфейсы ввода Другие Сущности Интерфейсы вывода Инфраструктура / Хранение 79/110
DDD: как оно начиналось Концептуальная книга Эрика Эванса   на английском – в 2003 году на русском – только в 2010 году Практическая книга Джимми Нильссона  на английском – в 2006 году  на русском – в 2007 году (почти сразу) 80/110
Основная идея DDD Без DDD Бизнесаналитик Заказчик Системный аналитик, архитектор Разработчик Бизнесмодель Модель приложения Код 81/110
Основная идея DDD Без DDD Бизнесаналитик Заказчик Системный аналитик, архитектор Разработчик Бизнесмодель Модель приложения Код 82/110
Без DDD Бизнесаналитик Заказчик Системный аналитик, архитектор Разработчик Бизнесмодель Модель приложения Код DDD Аналитики и архитектор Заказчик Модель на едином языке Разработчик Код 83/110
Плюсы модели на едином языке  Единое поле коммуникаций для всех участников проекта  Верификация модели заказчиком и выявление наиболее критичных ошибок на этапе постановки  Простота внесения изменений в требования: их не надо «протаскивать» через несколько моделей  Гибкость реагирования на ограничения, выявляемые при разработке: их можно донести до заказчика посредством модели и найти решения 84/110
Проблемы при использовании единой модели  Плохо применима для задач, где основная сложность не в предметной области  Необходимость понимания модели заказчиком ограничивает моделирование  Модель не может служить окончательным проектом для реализации, поскольку опускает технические детали; нужно дополнительное проектирование 85/110
DDD: типы блоков Фукнциональные блоки Сущности Сервисы (Контролеры) Представления Блоки Интерфейсов ввода Инфраструктурные блоки Блоки Интерфейсов вывода Блоки хранения Компоненты/ подсистемы/ Пакеты Блоки ЧМИ (Презентация) 86/110
Схема сущностей Смотрите наш семинар по UML  87/110
Слои    Позволяют отделять области кода с независимой логикой развития В идеале можно заменять слой, не трогая остальные Действия с системой обычно пронизывают все слои насквозь Плюсы: Минусы:     Ухудшение производительности  Сложность анализа и изменений действий над системой в целом Структуризация кода Гибкость Переносимость 88/110
Другие варианты организации блоков Pipes & Filters MVC 89/110
Типы связей между BB на одном уровне 90/110
Диаграммы для описания блоков     UML: диаграмма классов UML: диаграмма пакетов Схема сущностей Другие структурные диаграммы  Диаграмма плана счетов 91/110
Аспект исполнения (Runtime View)  Runtime View – взгляд на систему с точки зрения функционирования в реальном времени  Ключевые функции:  Проверка BBW на адекватность. Выявление новых блоков  Коммуникации с заказчиком и пользователями 92/110
Ограничения использования Runtime View  Runtime View избыточен (дублирует Building Block View):  Не нужно очень сильно увлекаться поддержанием в актуальном состоянии  Достаточно поддерживать 6–7 характерных сценариев использования  Не нужно рисовать все альтернативы, только характерные примеры  Runtime-диаграмм нужно рисовать много, но большая часть из них – одноразового использования (не нужно постоянно поддерживать) 93/110
Различные стили организации потока управления BOSS Delegating 94/110
Пример диаграммы последовательности 95/110
Диаграммы для описания функционирования в реальном времени  UML  Не-UML  Диаграмма деятельности  Диаграмма последовательности  Диаграмма коммуникации  Диаграмма состояний  Диаграмма взаимодействия  Блок схемы  Текстовые сценарии в виде пронумерованного  списка шагов Что угодно еще 96/110
Пример описания процесса 97/110
Аспект внедрения (Deployment View)  Deploy (от военного Deploy groups) – отправлять войска на чужую территорию  В этом аспекте мы рисуем, на каких физических устройствах будет разворачиваться система 98/110
Узлы  Существует два типа узлов  Узел устройства  Узел среды выполнения Базовый элемент аспекта – Node (Узел), что означает «процессор» (физический объект, способный выполнять действия) :Host 99/110
Разделение ответственности между Buliding Block View и Deployment View Программное обеспечение Функциональный блок Среда исполнения приложения Функциональный блок или узел среды выполнения Аппаратный процессор Узел устройства 100/110
Диаграммы для описания аспекта внедрения  UML  Не UML  Диаграмма развертывания  Диаграммы развертывания с использованием иконок (stereotypes) 101/110
Примеры диаграмм развертывания 102/110
Принтер Информацинный киоск Фискальный регистратор Принтер Сервер Системы безопасности счетчик посетителей Арм Администратора Армы Кассира Арм Кассира Дисплей покупателя Сканер ШК Считыватель карт Шина Обмена с офисом Сервер Розничного магазина Мобильный Арм Продавца Автономная касса Принтер Принтер этикеток Сканер ШК Терминал Сбора данных Колонки Арм Продавца Арм Кладовщика Псевдо Оффлайн касса Фискальный регистратор Принтер Принтер этикеток Сканер ШК Дисплей покупателя Сканер ШК Считыватель карт 103/110
Сервер системы безопасности Информационный Киоск АРМ Счетчик Посетителей Администратора АРМ Кассира Шина обмена с офисом Сервер Розничного магазина Автономная касса Мобильный АРМ продавца АРМ Кладовщика АРМ Продавца Псевдо-офлайн касса 104/110
Принтер Этикеток АРМ Продавца Считыватель карт Сканер ШК Принтер Принтер АРМ Кладовщика АРМ Кассира Дисплей покупателя Принтер Этикеток Фискальный регистратор Сканер ШК Терминал сбора данных Сканер ШК Колонки 105/110
Архитектурные концепции  Ориентированы на технологию и определяются ей (Technology-Driven)  Затрагивают больше одного функционального блока  Могут быть повторно использованы в других проектах  Должны порождаться в реальных проектах (нельзя придумать заранее)  Чаще всего рождаются снизу вверх 106/110
Архитектурные концепции Масштабируемость (Scaling, Clustering) Обеспечение доступности сервисов (High Availability) Восстановление после аварий Безопасность (Security) Способы сохранения/работы с БД (Persistency) Интернационализация Пользовательские интерфейсы Эргономика Способы настройки (Configuration) Способы построения отчетов (Reporting) Способы распространение (Distribution) Загрузка данных (Migration) Журналирование (Logging, Tracing) Тестируемость (Testability) Обработка ошибок и исключений Интеграция и взаимодействие (Communication) Управление процессами (Process Control) Параллелизм (Parallelisation and Threading) Сохранность (Safety) Управление транзакциями Управление сессиями Проверки корректности (Validation) Сопровождение, настройка и обслуживание (Administration and Operations)
Первый набросок системы 108/110
      Задачи системы   Ключевая функциональность Важные концепции предметной области Критерии качества Структура системы   Контекстная диаграмма 2-3 уровня Building Block View Как будут устроены потоки управления в системе    фиксированные или переменные процессы будут ли использоваться правила, оркестровка или хореография Внедрение и развертывание системы    Как система будет развертываться Где и когда В какой инфраструктуре Концепции    Способы хранения Технологии разработки Способы доступа (GUI,API, Batch) 109/110
Практический блок. Вариант 1 Управление рейсами в аэропорту 110/110
Спасибо! Вопросы? Михаил Заборов mzaborov@custis.ru 114/110

More Related Content

PPTX
Архитектура - это что?
bySQALab
 
PDF
Жизненный цикл заказного ПО
byCUSTIS
 
PDF
Проектирование программных систем. Занятие 4
byDima Dzuba
 
PPTX
Cистемная архитектура вместо требований
byCUSTIS
 
PDF
INFOSYSTEMS. How to Measure Software Architecture [1.01, RUS]
byAlex V. Petrov
 
PPTX
Ответственность за качество в разных ИТ-проектах: в чем она и как ее разделять
byCUSTIS
 
PPTX
Собираем кубик Рубика
byCEE-SEC(R)
 
PDF
Опыт применения метода ATAM для оценки архитектуры
byCUSTIS
 
Архитектура - это что?
bySQALab
 
Жизненный цикл заказного ПО
byCUSTIS
 
Проектирование программных систем. Занятие 4
byDima Dzuba
 
Cистемная архитектура вместо требований
byCUSTIS
 
INFOSYSTEMS. How to Measure Software Architecture [1.01, RUS]
byAlex V. Petrov
 
Ответственность за качество в разных ИТ-проектах: в чем она и как ее разделять
byCUSTIS
 
Собираем кубик Рубика
byCEE-SEC(R)
 
Опыт применения метода ATAM для оценки архитектуры
byCUSTIS
 

What's hot

PDF
Проектирование Программных Систем. Лекция 01
byDima Dzuba
 
PPT
тестирование программного обеспечения
byNatalia Zhelnova
 
PDF
Nfr and quality-models
byNatalia Zhelnova
 
PPTX
Agile и управление знаниями в ИТ-проектах
byCUSTIS
 
PDF
Разделение ответственности в заказной разработке
byCUSTIS
 
PDF
Проектирование программных систем. Занятие 1
byDima Dzuba
 
PDF
DEV Labs 2013. Can C++ Code Effeciency Be Comparable to That of Middle-Level ...
byAlex V. Petrov
 
PDF
Объектно-ориентированное программирование. Лекции 11 и 12
byDima Dzuba
 
PPT
Системная инженерия
byAnatoly Levenchuk
 
PDF
Бизнес весна 2014 лекция 3
byTechnopark
 
PPTX
Б.Позин, Е.Горбунова -- развитие ядра Essence для стадии сопровождения
byAnatoly Levenchuk
 
PPTX
Нефункциональные требования, Наталья Желнова
byAlexander Baikin
 
PDF
ISUCT & BSUIR. Successful Communication of the Process Architecture [1.0, RUS]
byAlex V. Petrov
 
PDF
ITGM #5. System Duality and Its Practical Effect on Business Analysis [1.0, RUS]
byAlex V. Petrov
 
PPTX
Нефункциональные требования
byNatalia Zhelnova
 
PDF
SECON'2017, Мелехова Анна, Архитектура как стихия. Обуздываем энтропию проекта
bySECON
 
PDF
ITGM #5. What Is Enterprise Architecture [1.0, RUS]
byAlex V. Petrov
 
DOC
шаблон технико коммерческого предложения
byNatalia Zhelnova
 
PPTX
Киев, BA Con 2017
byNatalia Zhelnova
 
PDF
Понятие архитектуры ПО и управление архитектурным проектированием
byCUSTIS
 
Проектирование Программных Систем. Лекция 01
byDima Dzuba
 
тестирование программного обеспечения
byNatalia Zhelnova
 
Nfr and quality-models
byNatalia Zhelnova
 
Agile и управление знаниями в ИТ-проектах
byCUSTIS
 
Разделение ответственности в заказной разработке
byCUSTIS
 
Проектирование программных систем. Занятие 1
byDima Dzuba
 
DEV Labs 2013. Can C++ Code Effeciency Be Comparable to That of Middle-Level ...
byAlex V. Petrov
 
Объектно-ориентированное программирование. Лекции 11 и 12
byDima Dzuba
 
Системная инженерия
byAnatoly Levenchuk
 
Бизнес весна 2014 лекция 3
byTechnopark
 
Б.Позин, Е.Горбунова -- развитие ядра Essence для стадии сопровождения
byAnatoly Levenchuk
 
Нефункциональные требования, Наталья Желнова
byAlexander Baikin
 
ISUCT & BSUIR. Successful Communication of the Process Architecture [1.0, RUS]
byAlex V. Petrov
 
ITGM #5. System Duality and Its Practical Effect on Business Analysis [1.0, RUS]
byAlex V. Petrov
 
Нефункциональные требования
byNatalia Zhelnova
 
SECON'2017, Мелехова Анна, Архитектура как стихия. Обуздываем энтропию проекта
bySECON
 
ITGM #5. What Is Enterprise Architecture [1.0, RUS]
byAlex V. Petrov
 
шаблон технико коммерческого предложения
byNatalia Zhelnova
 
Киев, BA Con 2017
byNatalia Zhelnova
 
Понятие архитектуры ПО и управление архитектурным проектированием
byCUSTIS
 

Viewers also liked

PPTX
Paradigma km 0
byVladimir Burdaev
 
PPT
Управление знаниями. Роль e-Learning в системе управления знаниями Волков Д....
byguest463a8ad
 
PPTX
150115 CSIS - Russia and the new reality
byIlya Ponomarev
 
PPT
Концепция технополиса Сколково
byIlya Ponomarev
 
PPT
Современные технологии управления знаниями (ECM). Возможности и перспективы
bySergey Poltev
 
PDF
Ukraine National Municipal Survey, March 2015 by IRI
byIlya Ponomarev
 
PDF
Управление знаниями в организациях Knowledge Management KM
byTOR
 
PDF
Организационная Архитектура EA Enterprise Architecture
byTOR
 
Paradigma km 0
byVladimir Burdaev
 
Управление знаниями. Роль e-Learning в системе управления знаниями Волков Д....
byguest463a8ad
 
150115 CSIS - Russia and the new reality
byIlya Ponomarev
 
Концепция технополиса Сколково
byIlya Ponomarev
 
Современные технологии управления знаниями (ECM). Возможности и перспективы
bySergey Poltev
 
Ukraine National Municipal Survey, March 2015 by IRI
byIlya Ponomarev
 
Управление знаниями в организациях Knowledge Management KM
byTOR
 
Организационная Архитектура EA Enterprise Architecture
byTOR
 

Similar to Архитектура в IT: философия и практика

PPTX
Архитектура - что это?
byМихаил Заборов
 
PPTX
Архитектура ПО: управляя самым важным
byCUSTIS
 
PPTX
02 Архитектура информационных систем. Основы
byEdward Galiaskarov
 
PDF
Архитектура: естественное и искуственное
byCUSTIS
 
PPT
Present architect
byviktor viktorov
 
PDF
Процесс проектирования ИТ-решений
byМаксим Смирнов
 
PPTX
ПиАПС, Лекция №1а - Роль архитектора, гибкая архитектура
byPavel Shalagin
 
PDF
Бизнес и системный анализ весна 2013 лекция 7
byTechnopark
 
PPTX
Enterprise Architecture - Sergey Orlik (Microsoft Platforma 2011)
bySergey Orlik
 
PPTX
Клуб Архитекторов 22.04.2010
bySergey Orlik
 
PPTX
itSMF: Solution architecture
byМаксим Смирнов
 
PPT
Архитектура в Agile проекте
byLuxoftTraining
 
PPT
2013-04-06 01 Максим Юнусов. Архитектура в agile-проекте
byОмские ИТ-субботники
 
PPTX
06 Архитектура информационных систем. Паттерны и фреймворки
byEdward Galiaskarov
 
PDF
Общие темы. Тема 01.
byIgor Shkulipa
 
PPTX
Система управления архитектурой предприятия
bySQALab
 
PDF
MA EA -Архитектура ИТ v 4VR
byVictor Rud
 
PDF
MA EA -Архитектура ИТ v 4VR
byOlga Kovalchuk
 
PPTX
Software People 2010
bySergey Orlik
 
PDF
Тимур Лукин - Архитектура и проектирование ПО
byYandex
 
Архитектура - что это?
byМихаил Заборов
 
Архитектура ПО: управляя самым важным
byCUSTIS
 
02 Архитектура информационных систем. Основы
byEdward Galiaskarov
 
Архитектура: естественное и искуственное
byCUSTIS
 
Present architect
byviktor viktorov
 
Процесс проектирования ИТ-решений
byМаксим Смирнов
 
ПиАПС, Лекция №1а - Роль архитектора, гибкая архитектура
byPavel Shalagin
 
Бизнес и системный анализ весна 2013 лекция 7
byTechnopark
 
Enterprise Architecture - Sergey Orlik (Microsoft Platforma 2011)
bySergey Orlik
 
Клуб Архитекторов 22.04.2010
bySergey Orlik
 
itSMF: Solution architecture
byМаксим Смирнов
 
Архитектура в Agile проекте
byLuxoftTraining
 
2013-04-06 01 Максим Юнусов. Архитектура в agile-проекте
byОмские ИТ-субботники
 
06 Архитектура информационных систем. Паттерны и фреймворки
byEdward Galiaskarov
 
Общие темы. Тема 01.
byIgor Shkulipa
 
Система управления архитектурой предприятия
bySQALab
 
MA EA -Архитектура ИТ v 4VR
byVictor Rud
 
MA EA -Архитектура ИТ v 4VR
byOlga Kovalchuk
 
Software People 2010
bySergey Orlik
 
Тимур Лукин - Архитектура и проектирование ПО
byYandex
 

More from CUSTIS

PDF
Три истории микросервисов, или MSA для Enterprise
byCUSTIS
 
PPTX
Долгоживущие ИТ в динамичном ритейле
byCUSTIS
 
PDF
Будущее уже наступило: от Agile к бирюзовым организациям
byCUSTIS
 
PDF
Как выбрать для проекта практики проектирования и работы с требованиями
byCUSTIS
 
PDF
Диаграммы учета как средство для наглядного и целостного отображения правил у...
byCUSTIS
 
PPTX
Сотрудничество с корпорациями: рецепты из практики
byCUSTIS
 
PPTX
Agile — ответ на вызовы третьей промышленной революции
byCUSTIS
 
PPTX
Опыт построения микросервисной архитектуры в цифровом банке
byCUSTIS
 
PDF
Золотая лихорадка MSA: почему нам не подошли микросервисы?
byCUSTIS
 
PPT
Барьеры микросервисной архитектуры
byCUSTIS
 
PPTX
Три истории микросервисов
byCUSTIS
 
PPTX
От монолитных моделей предметной области — к модульным
byCUSTIS
 
PPTX
Проблемы управления правами доступа к информационным системам крупной торгово...
byCUSTIS
 
PDF
Будущее omni-channel маркетинга: инструменты, кейсы и цифры
byCUSTIS
 
PDF
State of the .Net Performance
byCUSTIS
 
PPTX
Гибридный подход к управлению правами доступа: когда стандартного IDM не хватает
byCUSTIS
 
PPTX
Собираем кубик Рубика: восстановление архитектурного описания корпоративной р...
byCUSTIS
 
PPTX
Process и Case Management в информационной системе: от автоматизации As Is к ...
byCUSTIS
 
PDF
RBAC & ABAC: гибридное решение для управления правами доступа
byCUSTIS
 
PDF
Омниканальная модель в ритейле: решения и кейсы
byCUSTIS
 
Три истории микросервисов, или MSA для Enterprise
byCUSTIS
 
Долгоживущие ИТ в динамичном ритейле
byCUSTIS
 
Будущее уже наступило: от Agile к бирюзовым организациям
byCUSTIS
 
Как выбрать для проекта практики проектирования и работы с требованиями
byCUSTIS
 
Диаграммы учета как средство для наглядного и целостного отображения правил у...
byCUSTIS
 
Сотрудничество с корпорациями: рецепты из практики
byCUSTIS
 
Agile — ответ на вызовы третьей промышленной революции
byCUSTIS
 
Опыт построения микросервисной архитектуры в цифровом банке
byCUSTIS
 
Золотая лихорадка MSA: почему нам не подошли микросервисы?
byCUSTIS
 
Барьеры микросервисной архитектуры
byCUSTIS
 
Три истории микросервисов
byCUSTIS
 
От монолитных моделей предметной области — к модульным
byCUSTIS
 
Проблемы управления правами доступа к информационным системам крупной торгово...
byCUSTIS
 
Будущее omni-channel маркетинга: инструменты, кейсы и цифры
byCUSTIS
 
State of the .Net Performance
byCUSTIS
 
Гибридный подход к управлению правами доступа: когда стандартного IDM не хватает
byCUSTIS
 
Собираем кубик Рубика: восстановление архитектурного описания корпоративной р...
byCUSTIS
 
Process и Case Management в информационной системе: от автоматизации As Is к ...
byCUSTIS
 
RBAC & ABAC: гибридное решение для управления правами доступа
byCUSTIS
 
Омниканальная модель в ритейле: решения и кейсы
byCUSTIS
 

Архитектура в IT: философия и практика