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

2. РАЗРЕШИТЕ ПРЕДСТАВИТЬСЯ
АЛЕКСЕЙ ПЕТРОВ
тренер и консультант, эксперт-практик в области анализа и
моделирования бизнес-процессов, системного анализа,
архитектуры ПО, системной и программной инженерии
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

3. О ЧЕМ ПОЙДЕТ РЕЧЬ?
1
2
3
Понятие системы
Наивное и целеориентированное определение системы
Система как двуединство. Надсистемы и подсистемы
Система: онтологический статус
Дуализм системы
Система: взгляд «сверху» и «снизу»
Композиционное рассмотрение систем: теория GARM
Применения дуализма
Системные интерфейсы, ограничения и требования
Функциональные единицы и технические решения
Спецификации и модульность. Повторное использование
3
НА ВРЕМЯ ДОКЛАДА, ПОЖАЛУЙСТА, ПЕРЕВЕДИТЕ ЛИЧНУЮ ТЕХНИКУ
И СРЕДСТВА СВЯЗИ В БЕЗЗВУЧНЫЙ РЕЖИМ. СПАСИБО!

4. Наивное и целеориентированное
определение системы
Система как двуединство.
Надсистемы и подсистемы
Система: онтологический статус
4

5. НАИВНОЕ ОПРЕДЕЛЕНИЕ СИСТЕМЫ


Гипотеза
Понятие системы (др.-греч. σύστημα), подобно понятию
информации и другим фундаментальным понятиям,
неопределимо
Варианты определений
Попытки дать такое определение привели к появлению
десятков дескриптивных («как отличить систему от не-
системы?») и конструктивных («как построить систему ее
выделением из окружения?») определений

Большой Российский энциклопедический
словарь (2003)
«Система: множество элементов, находящихся в отношениях и
связях друг с другом, которое образует определенную целостность,
единство»
5

6. СИСТЕМА КАК ДВУЕДИНСТВО


Целеориентированное определение
В современной программной и системной инженерии система …
• совокупность взаимосвязанных элементов, совместно
работающих на достижение общей цели;
• двуединство присущей системе функции и конструкции
Функция системы
Поведение и назначение
рассматриваемой системы
в системе верхнего уровня

Конструкция системы
Структура системы, связанные
процессы и механизмы;
элементный состав системы,
представленный образующими
физическими объектами
6

7. ЧИТАЕМ ГОСТ Р ИСО/МЭК 15288-2005

Система: авторитетно
Согласно ГОСТ Р ИСО/МЭК 15288-2005 (ISO/IEC 15288:2002
“Systems engineering—System life cycle processes”), система
есть «комбинация взаимодействующих элементов,
организованных для достижения одной или нескольких
поставленных целей»
NB: Традиционно любая система
рассматривается в составе другой
системы, что приводит к идее
иерархии в пространстве-времени
или по отношению «часть – целое».
7
Мерео-
логия
Система
Над-
система
Под-
система

8. ОНТОЛОГИЧЕСКИЙ СТАТУС СИСТЕМЫ


Системы? Холоны!
Будучи одновременно целым для подсистем и частью для
надсистемы, любая система является холоном (англ. holon, от
др.-греч. ὅλος — целый), который как целое не сводится к
(предшествует) своим частям и определяет их свойства.
Иерархии? Холархии!
Связи «часть — целое» между
холонами отражают холархии
(ср.: холархия управления).
8

9. ОНТОЛОГИЧЕСКИЙ
СТАТУС СИСТЕМЫ: ПРИМЕР
9
Над-
система
Над-
система
Под-
система
Под-
система
РАЗЛИЧНЫЕ ЗАИНТЕРЕСОВАННЫЕ СТОРОНЫ МОГУТ РАССМАТРИВАТЬ СИСТЕМУ
КАК ОТВЕЧАЮЩУЮ ЦЕЛЯМ РАЗНЫХ НАДСИСТЕМ И РЕАЛИЗУЮЩУЮ РАЗНЫЕ ФУНКЦИИ
РАЗНЫЕ ИНТЕРЕСЫ
РАЗНЫЕ ЦЕЛИ
РАЗНЫЕ
ЗАИНТЕРЕСОВАННЫЕ СТОРОНЫ

10. Взгляд со стороны надсистемы:
функция
Взгляд со стороны подсистем:
конструкция
Композиционное рассмотрение
систем: теория GARM
10

11. ВЗГЛЯД СО СТОРОНЫ
НАДСИСТЕМЫ: ФУНКЦИЯ

Функциональное описание системы
Функциональное описание системы суть требования,
выдвигаемые заинтересованными сторонами (находящимися
вне пределов системы). Отвечает на вопросы:
• каково назначение системы? что требуется?
• в чем ценность системы для надсистемы?
Конфликт требований
Требования противоречивы.
Лучшее решение — не всегда «самое производительное
(безопасное, живучее, скоростное, …)», но всегда лучше других
отвечающее требованиям заинтересованных сторон
11


Анализ развилок
Поиск лучших решений требует:
• исследования возможных альтернатив;
• широкого спектра технических знаний и экспертных суждений;
• анализа «развилок» (англ. trade-off [analysis]).

12. ПРИМЕРЫ КОНФЛИКТОВ

Конфликты в НФТ (атрибутах качества)
• Гибкость ⟺ Простота
• Безопасность ⟺ Эффективность
• и другие…
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

13. ВЗГЛЯД СО СТОРОНЫ ПОДСИСТЕМ:
КОНСТРУКЦИЯ

Конструктивное описание системы
Конструктивное описание системы — это ее архитектура,
разрабатываемая системным архитектором и закрепляемая
архитектурным описанием системы. Отвечает на вопрос:
• из чего состоит система?
Архитектурное описание
Как документ, архитектурное описание (англ. Architecture
Definition, AD) может отсутствовать или существовать в
нескольких вариантах, а также служит основой для постановки
задач на разработку и доработку
13


Системы без архитектурного описания
Они есть, и факт отсутствия (невозможности построения их AD) и
чаще всего свидетельствует о «подвижности» их конструкции
ISO/IEC 42010:2011

14. КОМПОЗИЦИОННОЕ
РАССМОТРЕНИЕ СИСТЕМ
14
Функция и конструкция
Функция системы обеспечивается
конструкцией
Слоты и модули
Единство функции и конструкции
закрепляют понятия слота (для
функции) и модуля (для
конструкции)


слот
модуль
функция
конструкция
Hamburger
Dr. Wim F.
GIELINGH
TU Delft (NL)
2008
ФУНКЦИЯ И КОНСТРУКЦИЯ ЕСТЬ У ЛЮБОЙ СИСТЕМЫ,
СКОЛЬ УГОДНО СЛОЖНОЙ И СКОЛЬ УГОДНО ПРОСТОЙ

15. ПРОИСХОЖДЕНИЕ «ГАМБУРГЕРА» (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), содержимым которой является знание
любого рода о любом предмете или вопросе

16. ПРОИСХОЖДЕНИЕ «ГАМБУРГЕРА» (2 / 2)
16
Объект
слот
модуль
функция
конструкция
Слот — набор внутренних интерфейсов между системой в
целом и соответствующей частью этой системы
Модуль — объект, отвечающий определяемым слотом
требованиям и граничным условиям
Модель
системы

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

18. СИСТЕМНЫЕ ИНТЕРФЕЙСЫ,
ОГРАНИЧЕНИЯ И ТРЕБОВАНИЯ
18
слот
модуль
Функция
(«что?»)
Конструкция
(«как?»)
Требования и граничные
условия (ФТ, НФТ)
Архитектура
Требуемый
интерфейс
Атрибуты
качества
Ограничения
≠

19. ФУНКЦИОНАЛЬНЫЕ ЕДИНИЦЫ
И ТЕХНИЧЕСКИЕ РЕШЕНИЯ
19
слот
модуль
Определяет роль
в надсистеме
Не зависит
от роли подсистемы
Постановка задачи
проектирования
Решение задачи
проектирования
Абстракция
Реализация
Аналитик
[Req. Engineer]
Архитектор
≠
Мост
[GoF]
ВЕРХНЯЯ ЧАСТЬ «ГАМБУРГЕРА» — ЭТО АБСТРАКТНАЯ ФУНКЦИОНАЛЬНАЯ
ЕДИНИЦА, А НИЖНЯЯ — КОНКРЕТНОЕ ТЕХНИЧЕСКОЕ РЕШЕНИЕ

20. СПЕЦИФИКАЦИИ И МОДУЛЬНОСТЬ

Функциональные и технические
спецификации
Абстрактные функциональные единицы и конкретные
технические решения могут интерпретироваться как
функциональные и технические спецификации (материальной)
системы, как таковые также являющиеся системами
20
Функциональная спецификация (резюме)
Определяет роль «части» в «целом»; вменяет ей требования и
граничные условия; формулирует задачу на проектирование

Техническая спецификация (резюме)
Содержит исчерпывающее (на заданном уровне функционального
разбиения, англ. functional breakdown) описание «части»
независимо от его роли в «целом»; содержит функциональные
спецификации своих «частей», но не технические подробности их
организации и работы
Модульность
В РЕАЛЬНОМ МИРЕ ФУНКЦИОНАЛЬНОЙ И ТЕХНИЧЕСКОЙ СПЕЦИФИКАЦИИ МОЖЕТ
СООТВЕТСТВОВАТЬ ОДИН И БОЛЕЕ ФУНКЦИОНАЛЬНЫЙ И КОНСТРУКТИВНЫЙ ОБЪЕКТ

21. АЛЬТЕРНАТИВНЫЕ КОНСТРУКЦИИ
21
слот
модуль 1
Предпочтительный Запасной Перспективный
модуль 2 модуль 3
Каждой задаче проектирования может соответствовать
одно и более решение [либо ни одного (существующего)]

22. АЛЬТЕРНАТИВНЫЕ ФУНКЦИИ
22
модуль
слот 1
Предпочтительный Альтернативный Отвергнутый
слот 2 слот 3
Каждый модуль может являться решением одно
и более задачи проектирования [либо не являться
решением ни одной]

23. ПОВТОРНОЕ ИСПОЛЬЗОВАНИЕ МОДУЛЕЙ
23
слот
модуль 1 модуль 2
модуль 3
Предпочтительный Альтернативный
модуль 4 модуль 5
Отвергнутый
слот
модуль 3
Предпочтительный Альтернативный Отвергнутый
Модуль, отвергнутый при
решении одной задачи
проектирования, может
оказаться востребован
при решении другой

24. Наши партнеры
Ближайшие мероприятия
Благодарности
Вопросы аудитории
24

25. НАШИ ПАРТНЕРЫ: ОБУЧЕНИЕ В ОБЛАСТИ
BA/SA И КОРПОРАТИВНОЙ АРХИТЕКТУРЫ
25
Учебный центр Level UP
Один из ведущих центров России в области обучения и
консалтинга по направлениям:
• архитектура (вкл. EA), проектирование и тестирование ПО;
• BA/SA и управление проектами;
• разработка (Web, mobile) и администрирование.
Преимущества УЦ Level UP:
• коллектив «играющих тренеров»;
• адаптируемые практико-ориентированные программы и
ускоренные методики обучения (в т.ч. онлайн-обучение);
• закрытая база вакансий для лучших выпускников.
Ближайшие тренинги
06 – 10 июля 2015 г. — «Системный и бизнес-анализ в
разработке ПО» (С.-Петербург, очно / удаленно)
13 – 14 июля 2015 г. — «Моделирование корпоративной
архитектуры на языке ArchiMate» (С.-Петербург, очно /
удаленно)
НЕ ЗАБУДЬТЕ ПОЛУЧИТЬ ПРОМОКОД,
ДАЮЩИЙ ПРАВО НА ПОЛУЧЕНИЕ СКИДКИ В РАЗМЕРЕ 10%!

26. БЛИЖАЙШИЕ ВЫСТУПЛЕНИЯ
26
❶ Мастер-класс на ЛАФ-2015
Место, дата, время:
Иваново, 20 июня 2015 г., 14:10
Тема: «Личная эффективность системного аналитика»
• На мастер-классе наше внимание будет
сосредоточено на эффективной коммуникации.
В ходе 90-минутной сессии мы поделимся
личными секретами мастерства, заглянем в те
области человеческой деятельности, где во главе
угла также стоит общение, и уясним, что ценного
для ежедневной практики системного
и бизнес-анализа можно в них почерпнуть
• Количество мест ограничено!
❷ Тренинги в Санкт-Петербурге
• Системный и бизнес-анализ в разработке ПО
• Моделирование корпоративной архитектуры на
языке ArchiMate

27. БЛАГОДАРНОСТИ
Автор доклада выражает свою искреннюю
признательность за содействие в организации
его участия в IT Global Meetup #5:
• лично г-же Анне Горбатенко и г-ну Михаилу
Рыжикову;
• учебному центру Level UP (г. Санкт-Петербург)
и лично г-ну Алексею Ханько;
• а также магистрантам кафедры
«Информационные системы и
телекоммуникации» (ИУ-3) факультета
«Информатика и системы управления» (ИУ)
НИУ МГТУ им. Н.Э. Баумана, выбравшим в
2013/2014 и 2014/2015 уч. гг. элективную
дисциплину «Системная инженерия», за
многочисленные обсуждения и «правильные»
вопросы
27

28. СПАСИБО ЗА ВНИМАНИЕ!
❶ Собственные источники
В ходе подготовки семинара использовались
материалы авторского тренинга А.В. Петрова
«Мастерская по разработке и управлению
требованиями» и учебного курса по
дисциплине «Системная инженерия»
(НИУ МГТУ им. Н.Э. Баумана, 2013 – 2014)
❷ Контакты
28
Piter United / ITGM
Профиль ведущего
в сети LinkedIn

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

30. ЧТО ИЗУЧИТЬ [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

31. ЧТО ИЗУЧИТЬ [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

32. ЧТО ИЗУЧИТЬ [РУС]?
ГОСТ Р ИСО/МЭК 15288-2005. Информационная технология.
Системная инженерия. Процессы жизненного цикла систем.
Косяков А., Свит У. и др. Системная инженерия. Принципы и
практика / Пер. с англ. — М.: ДМК Пресс, 2014. — 636 с.: ил.
32