РАЗРЕШИТЕ ПРЕДСТАВИТЬСЯ

АЛЕКСЕЙ ПЕТРОВ тренер и консультант, эксперт-практик в области анализа и моделирования бизнес-процессов, системного анализа, архитектуры ПО, системной и программной инженерии

2013 – 2014: докладчик конференций Stratoplan TECH & BUSINESS Summit 2013 (поток «Проектирование и анализ»), Luxoft DEV Labs C++ 2013, Luxoft REQ Labs 2014 и слета IT Campus 2014. Модератор X Международной конференции CEE-SECR 2014

2012 — наст. вр.: преподаватель НИУ МГТУ им. Н.Э. Баумана и совместного проекта НИУ МГТУ им. Н.Э. Баумана и Mail.Ru Group «Технопарк@Mail.Ru»

2011 — наст. вр.: независимый тренер и консультант, автор и ведущий тренингов в Беларуси, Казахстане, Литве, России

2004 — наст. вр.: участник более 10 проектов внедрения корпоративных ИС, моделирования бизнес-процессов и ИТ-аудита организаций

2

О ЧЕМ ПОЙДЕТ РЕЧЬ?

1

2

3

Понятие системы Наивное и целеориентированное определение системы

Система как двуединство. Надсистемы и подсистемы

Система: онтологический статус

Дуализм системы Система: взгляд «сверху» и «снизу»

Композиционное рассмотрение систем: теория GARM

Применения дуализма Системные интерфейсы, ограничения и требования

Функциональные единицы и технические решения

Спецификации и модульность. Повторное использование

3

НА ВРЕМЯ ДОКЛАДА, ПОЖАЛУЙСТА, ПЕРЕВЕДИТЕ ЛИЧНУЮ ТЕХНИКУ

И СРЕДСТВА СВЯЗИ В БЕЗЗВУЧНЫЙ РЕЖИМ. СПАСИБО!

Наивное и целеориентированное

определение системы

Система как двуединство.

Надсистемы и подсистемы

Система: онтологический статус

4

НАИВНОЕ ОПРЕДЕЛЕНИЕ СИСТЕМЫ

Гипотеза Понятие системы (др.-греч. σύστημα), подобно понятию

информации и другим фундаментальным понятиям, неопределимо

Варианты определений Попытки дать такое определение привели к появлению

десятков дескриптивных («как отличить систему от не-системы?») и конструктивных («как построить систему ее выделением из окружения?») определений

Большой Российский энциклопедический словарь (2003) «Система: множество элементов, находящихся в отношениях и

связях друг с другом, которое образует определенную целостность, единство»

5

СИСТЕМА КАК ДВУЕДИНСТВО

Целеориентированное определение В современной программной и системной инженерии система …

• совокупность взаимосвязанных элементов, совместно работающих на достижение общей цели;

• двуединство присущей системе функции и конструкции

Функция системы Поведение и назначение

рассматриваемой системы в системе верхнего уровня

Конструкция системы Структура системы, связанные

процессы и механизмы; элементный состав системы, представленный образующими физическими объектами

6

ЧИТАЕМ ГОСТ Р ИСО/МЭК 15288-2005

Система: авторитетно Согласно ГОСТ Р ИСО/МЭК 15288-2005 (ISO/IEC 15288:2002

“Systems engineering—System life cycle processes”), система есть «комбинация взаимодействующих элементов, организованных для достижения одной или нескольких поставленных целей»

NB: Традиционно любая система рассматривается в составе другой системы, что приводит к идее иерархии в пространстве-времени или по отношению «часть – целое».

7

Мерео-

логия

Система

Над-

система

Под-

система

ОНТОЛОГИЧЕСКИЙ СТАТУС СИСТЕМЫ

Системы? Холоны! Будучи одновременно целым для подсистем и частью для

надсистемы, любая система является холоном (англ. holon, от др.-греч. ὅλος — целый), который как целое не сводится к (предшествует) своим частям и определяет их свойства.

Иерархии? Холархии! Связи «часть — целое» между

холонами отражают холархии (ср.: холархия управления).

8

ОНТОЛОГИЧЕСКИЙ

СТАТУС СИСТЕМЫ: ПРИМЕР

9

Над-

система

Над-

система

Под-

система

Под-

система

РАЗЛИЧНЫЕ ЗАИНТЕРЕСОВАННЫЕ СТОРОНЫ МОГУТ РАССМАТРИВАТЬ СИСТЕМУ

КАК ОТВЕЧАЮЩУЮ ЦЕЛЯМ РАЗНЫХ НАДСИСТЕМ И РЕАЛИЗУЮЩУЮ РАЗНЫЕ ФУНКЦИИ

РАЗНЫЕ ИНТЕРЕСЫ

РАЗНЫЕ ЦЕЛИ

РАЗНЫЕ ЗАИНТЕРЕСОВАННЫЕ СТОРОНЫ

Взгляд со стороны надсистемы:

функция

Взгляд со стороны подсистем:

конструкция

Композиционное рассмотрение

систем: теория GARM

10

ВЗГЛЯД СО СТОРОНЫ

НАДСИСТЕМЫ: ФУНКЦИЯ

Функциональное описание системы Функциональное описание системы суть требования,

выдвигаемые заинтересованными сторонами (находящимися вне пределов системы). Отвечает на вопросы:

• каково назначение системы? что требуется?

• в чем ценность системы для надсистемы?

Конфликт требований Требования противоречивы.

Лучшее решение — не всегда «самое производительное (безопасное, живучее, скоростное, …)», но всегда лучше других отвечающее требованиям заинтересованных сторон

11

Анализ развилок Поиск лучших решений требует:

• исследования возможных альтернатив;

• широкого спектра технических знаний и экспертных суждений;

• анализа «развилок» (англ. trade-off [analysis]).

ПРИМЕРЫ КОНФЛИКТОВ

Конфликты в НФТ (атрибутах качества) • Гибкость ⟺ Простота

• Безопасность ⟺ Эффективность

• и другие…

The CAP Theorem (E. Brewer, 2000) “You can have at most two of these properties for any shared-

data system: Consistency, Availability, Tolerance to network Partitions”.

12

ACID DNS LDAP

ВЗГЛЯД СО СТОРОНЫ ПОДСИСТЕМ:

КОНСТРУКЦИЯ

Конструктивное описание системы Конструктивное описание системы — это ее архитектура,

разрабатываемая системным архитектором и закрепляемая архитектурным описанием системы. Отвечает на вопрос:

• из чего состоит система?

Архитектурное описание Как документ, архитектурное описание (англ. Architecture

Definition, AD) может отсутствовать или существовать в нескольких вариантах, а также служит основой для постановки задач на разработку и доработку

13

Системы без архитектурного описания Они есть, и факт отсутствия (невозможности построения их AD) и

чаще всего свидетельствует о «подвижности» их конструкции

ISO/IEC 42010:2011

КОМПОЗИЦИОННОЕ

РАССМОТРЕНИЕ СИСТЕМ

14

Функция и конструкция Функция системы обеспечивается

конструкцией

Слоты и модули Единство функции и конструкции

закрепляют понятия слота (для функции) и модуля (для конструкции)

слот

модуль

функция

конструкция

Hamburger

Dr. Wim F.

GIELINGH TU Delft (NL)

2008

ФУНКЦИЯ И КОНСТРУКЦИЯ ЕСТЬ У ЛЮБОЙ СИСТЕМЫ,

СКОЛЬ УГОДНО СЛОЖНОЙ И СКОЛЬ УГОДНО ПРОСТОЙ

ПРОИСХОЖДЕНИЕ «ГАМБУРГЕРА» (1 / 2)

15 ФУНКЦИЯ И КОНСТРУКЦИЯ ЕСТЬ У ЛЮБОЙ СТАТИЧЕСКОЙ И ДИНАМИЧЕСКОЙ

СИСТЕМЫ, ОБЪЕКТА ИЛИ ПРОЦЕССА: ПОДХОД GARM К ВОПРОСУ УНИВЕРСАЛЕН

Общая эталонная модель AEC-приложений Диаграмма-»гамбургер» — одна из наиболее часто цитируемых

и востребованных составных частей Общей эталонной модели программных систем в сфере строительства и архитектуры (англ. General AEC [Architecture, Engineering, & Construction] Reference Model, GARM), разработанной в середине 1980-х гг. в рамках инициативы ISO/STEP (англ. Standard for the Exchange of Product Data)

Отличия GARM GARM не предопределяет классы

объектов, их атрибуты, функции или связи и по сравнению с другими эталонными моделями (библиотеками объектов и таксономиями) служит «метамоделью»

Unit of

Knowl-

edge

Единица знания — объект Элементом модели системы является единица знания о системе

(англ. Unit of Knowledge), содержимым которой является знание любого рода о любом предмете или вопросе

ПРОИСХОЖДЕНИЕ «ГАМБУРГЕРА» (2 / 2)

16

Объект

слот

модуль

функция

конструкция

Слот — набор внутренних интерфейсов между системой в

целом и соответствующей частью этой системы

Модуль — объект, отвечающий определяемым слотом

требованиям и граничным условиям

Модель

системы

Системные интерфейсы,

ограничения и требования

Функциональные единицы и

технические решения

Спецификации и модульность

Альтернативные функции и

конструкции

Повторное использование модулей

17

СИСТЕМНЫЕ ИНТЕРФЕЙСЫ,

ОГРАНИЧЕНИЯ И ТРЕБОВАНИЯ

18

слот

модуль

Функция («что?»)

Конструкция («как?»)

Требования и граничные условия (ФТ, НФТ)

Архитектура

Требуемый интерфейс

Атрибуты качества

Ограничения ≠

ФУНКЦИОНАЛЬНЫЕ ЕДИНИЦЫ

И ТЕХНИЧЕСКИЕ РЕШЕНИЯ

19

слот

модуль

Определяет роль в надсистеме

Не зависит от роли подсистемы

Постановка задачи проектирования

Решение задачи проектирования

Абстракция

Реализация

Аналитик [Req. Engineer]

Архитектор ≠ М

ост

[G

oF]

ВЕРХНЯЯ ЧАСТЬ «ГАМБУРГЕРА» — ЭТО АБСТРАКТНАЯ ФУНКЦИОНАЛЬНАЯ

ЕДИНИЦА, А НИЖНЯЯ — КОНКРЕТНОЕ ТЕХНИЧЕСКОЕ РЕШЕНИЕ

СПЕЦИФИКАЦИИ И МОДУЛЬНОСТЬ

Функциональные и технические спецификации Абстрактные функциональные единицы и конкретные

технические решения могут интерпретироваться как функциональные и технические спецификации (материальной) системы, как таковые также являющиеся системами

20

Функциональная спецификация (резюме) Определяет роль «части» в «целом»; вменяет ей требования и

граничные условия; формулирует задачу на проектирование

Техническая спецификация (резюме) Содержит исчерпывающее (на заданном уровне функционального

разбиения, англ. functional breakdown) описание «части» независимо от его роли в «целом»; содержит функциональные спецификации своих «частей», но не технические подробности их организации и работы

Модульность

В РЕАЛЬНОМ МИРЕ ФУНКЦИОНАЛЬНОЙ И ТЕХНИЧЕСКОЙ СПЕЦИФИКАЦИИ МОЖЕТ

СООТВЕТСТВОВАТЬ ОДИН И БОЛЕЕ ФУНКЦИОНАЛЬНЫЙ И КОНСТРУКТИВНЫЙ ОБЪЕКТ

АЛЬТЕРНАТИВНЫЕ КОНСТРУКЦИИ

21

слот

модуль 1

Предпочтительный Запасной Перспективный

модуль 2 модуль 3

Каждой задаче проектирования может соответствовать

одно и более решение [либо ни одного (существующего)]

АЛЬТЕРНАТИВНЫЕ ФУНКЦИИ

22

модуль

слот 1

Предпочтительный Альтернативный Отвергнутый

слот 2 слот 3

Каждый модуль может являться решением одно

и более задачи проектирования [либо не являться

решением ни одной]

ПОВТОРНОЕ ИСПОЛЬЗОВАНИЕ МОДУЛЕЙ

23

слот

модуль 1 модуль 2

модуль 3

Предпочтительный Альтернативный

модуль 4 модуль 5

Отвергнутый

слот

модуль 3

Предпочтительный Альтернативный Отвергнутый

Модуль, отвергнутый при

решении одной задачи

проектирования, может

оказаться востребован

при решении другой

Наши партнеры

Ближайшие мероприятия

Благодарности

Вопросы аудитории

24

НАШИ ПАРТНЕРЫ: ОБУЧЕНИЕ В ОБЛАСТИ

BA/SA И КОРПОРАТИВНОЙ АРХИТЕКТУРЫ

25

Учебный центр Level UP Один из ведущих центров России в области обучения и

консалтинга по направлениям:

• архитектура (вкл. EA), проектирование и тестирование ПО;

• BA/SA и управление проектами;

• разработка (Web, mobile) и администрирование.

Преимущества УЦ Level UP:

• коллектив «играющих тренеров»;

• адаптируемые практико-ориентированные программы и ускоренные методики обучения (в т.ч. онлайн-обучение);

• закрытая база вакансий для лучших выпускников.

Ближайшие тренинги 06 – 10 июля 2015 г. — «Системный и бизнес-анализ в

разработке ПО» (С.-Петербург, очно / удаленно)

13 – 14 июля 2015 г. — «Моделирование корпоративной архитектуры на языке ArchiMate» (С.-Петербург, очно / удаленно)

НЕ ЗАБУДЬТЕ ПОЛУЧИТЬ ПРОМОКОД,

ДАЮЩИЙ ПРАВО НА ПОЛУЧЕНИЕ СКИДКИ В РАЗМЕРЕ 10%!

БЛИЖАЙШИЕ ВЫСТУПЛЕНИЯ

26

❶ Мастер-класс на ЛАФ-2015

Место, дата, время: Иваново, 20 июня 2015 г., 14:10

Тема: «Личная эффективность системного аналитика»

• На мастер-классе наше внимание будет сосредоточено на эффективной коммуникации. В ходе 90-минутной сессии мы поделимся личными секретами мастерства, заглянем в те области человеческой деятельности, где во главе угла также стоит общение, и уясним, что ценного для ежедневной практики системного и бизнес-анализа можно в них почерпнуть

• Количество мест ограничено!

❷ Тренинги в Санкт-Петербурге • Системный и бизнес-анализ в разработке ПО

• Моделирование корпоративной архитектуры на языке ArchiMate

БЛАГОДАРНОСТИ

Автор доклада выражает свою искреннюю

признательность за содействие в организации

его участия в IT Global Meetup #5:

• лично г-же Анне Горбатенко и г-ну Михаилу

Рыжикову;

• учебному центру Level UP (г. Санкт-Петербург)

и лично г-ну Алексею Ханько;

• а также магистрантам кафедры

«Информационные системы и

телекоммуникации» (ИУ-3) факультета

«Информатика и системы управления» (ИУ)

НИУ МГТУ им. Н.Э. Баумана, выбравшим в

2013/2014 и 2014/2015 уч. гг. элективную

дисциплину «Системная инженерия», за

многочисленные обсуждения и «правильные»

вопросы

27

СПАСИБО ЗА ВНИМАНИЕ!

❶ Собственные источники

В ходе подготовки семинара использовались

материалы авторского тренинга А.В. Петрова

«Мастерская по разработке и управлению

требованиями» и учебного курса по

дисциплине «Системная инженерия»

(НИУ МГТУ им. Н.Э. Баумана, 2013 – 2014)

❷ Контакты

28

Piter United / ITGM

Профиль ведущего

в сети LinkedIn

СПАСИБО ЗА ВНИМАНИЕ!

29

ЧТО ИЗУЧИТЬ [ENG]? (1 / 2)

Brewer, E. A. Towards Robust Distributed Systems. In Proc. of the XIX

Annual ACM Symposium on Principles of Distributed Computing

(Portland, OR: ACM, 2000). Vol. 19, No. 7. URL:

http://www.cs.berkeley.edu/~brewer/cs262b-2004/PODC-

keynote.pdf

Gielingh, W. A Theory for the Modelling of Complex and Dynamic

Systems. In ITcon, Vol. 13, 2008, pp. 421–475. URL:

15926.info/functional-physical-object/GARM-paper.pdf

Gielingh, W. General AEC Reference Model (GARM). In Construction

Informatics Digital Library, 1988, paper w78-1988-165б, pp.

165-178. URL: http://itc.scix.net/cgi-bin/works/Show?w78-

1988-165

ISO/IEC 15288:2002. Systems Engineering—System life cycle

processes.

30

ЧТО ИЗУЧИТЬ [ENG]? (2 / 2)

ISO/IEC 15288:2008. Systems and software engineering—System

life cycle processes.

ISO/IEC 42010:2007. Systems and Software Engineering—

Recommended practice for architectural description of software-

intensive systems.

ISO/IEC/IEEE 42010:2011. Systems and software engineering—

Architecture description.

Varzi, A.C. Spatial Reasoning and Ontology: Parts, Wholes, and

Locations. In: Aiello, M., Pratt-Hartmann, I., and Benthem, J. van

(eds.), Handbook of Spatial Logics (Berlin, Springer-Verlag, 2007,

pp. 945-1038).

31

ЧТО ИЗУЧИТЬ [РУС]?

ГОСТ Р ИСО/МЭК 15288-2005. Информационная технология.

Системная инженерия. Процессы жизненного цикла систем.

Косяков А., Свит У. и др. Системная инженерия. Принципы и

практика / Пер. с англ. — М.: ДМК Пресс, 2014. — 636 с.: ил.

32