Review on the topic of System Engineering "Architecture management in the system design"

1. Системная инженерия
Управление архитектурой при проектировании систем
Купин Станислав
Симкин Анатолий
Группа 9111
26.11.2009
Вставьте
картинку

2. Вставьте
картинку
1
Содержание
1. Архитектура, ее место в ЖЦ и особенности ее
технического процесса
2. Процесс описания и проектирования архитектуры

3. Что такое архитектура?
2
This is NOT Architecture!
This is the RESULT of Architecture.
Источник: статья Architecture Is Architecture Is Architecture by John A. Zachman

4. Особенности архитектуры
● Архитектура определяет важнейшие компоненты
● Архитектура определяет как компоненты связаны между
собой (структуру) и как они между собой взаимодействуют,
используя эти связи
● Архитектура не рассматриваетинформациюоб устройстве
компонентов безотносительно к их взаимодействию между
собой
● Поведение компонентов является частью архитектуры в той
мере, в которой оно можетбыть заметно, можетощущаться с
точки зрения другого компонента
3

5. V- образная модель проектирования архитектуры
4
User
Requirements &
Concept of
Operations
System
Requirements &
Architecture
Component
Design
Procure, Fabricate,
& Assemble Parts
Component
Integration & Test
System
Integration & Test
System
Demonstration &
Validation
Component
Engineering
Domain
Systems
Engineering
Domain
Источник: презентация Systems Engineering Overview by Karl Arunski and James Martin

6. Уровни архитектурных описаний
5Источник: В.К. Батоврин Лекции по системной инженерии. Процессы ЖЦ систем ч.2

7. Концептуальное, логическое и физическое проектирование
● A conceptual design is an abstract or high level design which includes
only the most important components and entities.
● The main goal of a conceptual design is to provide an understandable
picture of the overall purpose of the proposed solution.
● A logical design is a more detailed design which includes all major
components and entities plus their relationships.
● The data flows and connections are detailed in this stage. The target
audience is typically developers or other systems architects.
6

8. Концептуальное, логическое и физическое проектирование
● A physical design has all major components and entities identified
within specific physical servers and locations or specific software
services, objects, or solutions.
● Include all known details such as operating systems, version numbers,
and even patches that are relevant.
7

9. ISO 15288: «Что делать?»
Обеспечения проектов
• управление описанием
жизненного цикла
• управление инфраструктурой
• управление портфелем
проектов (программой)
• управление персоналом
• управление качеством
Технические
• Cбор требований
• Анализ требований
• Архитектурный дизайн
• Изготовление
• Интеграция
• Проверка (Verification)
• Переход к эксплуатации
• Приёмка (Validation)
• Эксплуатация
• Обслуживание
• Вывод из эксплуатации
Проектные
• Управление проектами
• Планирование проекта
Управление выполнением и
контроль проекта
• Поддержкапроектов
• Управление решениями
• Управление рисками
• Управление конфигурацией
• Управление информацией
• Измерения
8
25 важнейших процессов СИ

10. 9
Архитектурный подход (ISO/IEC 42010, IEEE 1471)
Стандарт IEEE 1471 Института инженеров-электриков и
электронщиков (он же ISO/IEC 42010) предоставляет метамодель для
определения архитектуры.

11. 10
● Каждый участник (он же заинтересованное лицо)
характеризуется набором своих интересов. Интересы разных
участников могут пересекаться.
● Каждое описание архитектуры предназначено для
удовлетворения одного или несколькихинтересов.
● Каждое описание системы входит в какую-либо тематическую
группу описаний (чаще всего в одну такую группу),
порождённую одним методом описания.
● Если какое-то описание входит в разные тематические
группы, то это означает, что способ его получения также
входит в разные методы описания.
Архитектурный подход

12. 11
● К созданию целостного описания системы можно прийти
только в рамках определённого подхода, или совокупности
подходов (frameworks).
● Подход к описанию системы начинается с указания
участников и их интересов, считающихся значимыми в
рамках данного подхода.
● Подход также содержитперечень методов описания,
указывающих на то, что именно следует увидеть в системе
(предметные онтологии системы), и какие нотации (системы
обозначений)и как могут быть применены для описания
системы в терминах этих онтологий.
● Методы описания могут либо уже существовать (браться из
литературы или предыдущих разработок), или
разрабатываться специально для включения в
соответствующий подход.
Архитектурный подход

13. Вставьте
картинку
12
Содержание
1. Архитектура, ее место в ЖЦ и особенности ее
технического процесса
2. Процесс описания и проектирования архитектуры

14. Технические процессы
13
Технические процессы
Определениетребований правообладателей
Анализ требований
Проектированиеархитектуры
Реализация элементов
Комплексирование
Верификация
Передача
Валидация
Функционирование
Обслуживание
Изъятие и списание
Источник: ISO/IEC 15288

15. Применение технических процессов
14Источник: ISO/IEC TR 19760

16. Процесс проектирования архитектуры
15
Действия
•Определение логической
архитектуры
• Детализация требований к
системе
•Оценка потребности в покупных
элементах
•Оценка альтернативных
проектных решений
•Документирование
интерфейсов
Ресурсы
•Инфраструктура предприятия
• Политики, процессы и
стандарты предприятия
Выходы
•Исходная версия
проекта архитектуры
•Описания
элементов системы
•Требования к
интерфейсам
•Стратегия
верификации
•План
комплексирования
(сборки) системы
•Следующая версия
RVTM
Входы
•Функциональные
требования и
показатели
•Ограничения на
архитектуру
• Исходная RVTM
•Описание
взаимодействий в
системе
Управление
•Соглашения и договоры
•Проектные процессы и
процедуры
Источник: SYSTEMS ENGINEERING HANDBOOK version 3.1

17. Логическая и физическая архитектура
16
● The logical architecture is a more detailed structure defines what
has to be done to support the user services. It defines the
processes that perform functionsand the information or data
flows that are shared between these processes. Logical
architecturedo not include physical server names or addresses.
They do include any business services, application namesand
details, and other relevant information for developmentpurposes.
● A physical architecture has all major components and entities
identified within specific physical servers and locations or
specific software services, objects, or solutions. Include all
known details such as operating systems, version numbers, and
even patches that are relevant. Any physical constraints or
limitations should also be identified within the server
components, data flows, or connections. This design usually
precludes or may be included and extended by the final
implementation team into an implementation design.

18. 17
Логическая архитектура системы
●Логическая архитектура представляет
собой функциональную структуру, которая
в течение ЖЦ дает возможность системе
для реализации всех заданных сценариев
функционирования.
●Сценарии функционирования ставят в
соответствие целям системы цепочки
выполняемых задач.
Источник: В.К. Батоврин Лекции по системной инженерии. Процессы ЖЦ систем .

19. 18
Физическая архитектура системы
●Физическая архитектура системы представляет
собой совокупность физических элементов,
которые поддерживают функционирование
системы.
●Физические элементы взаимодействуют между
собой с использованием входов и выходов и
управления физическими соединениями.
●Конкретные характеристики элементов
определяются их природой (программа, человек,
оборудование, аппаратное средство…), в
абстрактном смысле элемент характеризуется
своим назначением и своими целями.
Источник: В.К. Батоврин Лекции по системной инженерии. Процессы ЖЦ систем .

20. Логическая и физическая архитектура
19

21. Источник: ITAG - Information Technology Architecture Group. MIT Architecture
Пример логической архитектуры
20
SAP DB
(Oracle)
Users
SAP ITS
SAP Client
Browser
Client
(SAP WEB)
System
Component
Key:
Related
System
Other MIT
System
SAP Application Server
Kerberos
Server
Authentication
forSAPClients
External
Systems
Other MIT Systems
Incoming:
Data Warehouse
Roles DB
SAP - Lincoln Lab
Mainframe
COEUS
MIT ID
Broad Institute
Outgoing:
 Data Warehouse
 Archive (IX0S)
Server
 Broad Institute
 MIT ID (Real Time)
External Systems
Incoming:
 Benefit Providers
 Financial Institutions
 EDI
Outgoing:
ECAT Vendors
Financial Institutions
Benefits Providers
Financial
Accounting
Materials
Management
Controlling
Sales and
Distribution
ProfitCenter
Account
Classification
System
Human
Resources
Payroll
Labor
Distribution
Cross
Application
X509Certificates
Drop
Box
SAP Web
Classic
Plant
Maintenance
TrainingEvents
Management

22. Пример физической архитектуры
21Источник: ITAG - Information Technology Architecture Group. MIT Architecture

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

24. Этапы логического проектирования
a. блок-схема функционального потока, отражающая декомпозицию главных
функций в их подфункции;
b. диаграмма информационного потока, которая раскладывает функции на
составные части, явно демонстрируя данные, необходимые для каждой функции;
c. структура данных с соответствующими им функциями и потоки обработки данных,
относящиеся к данным и связанные с назначенными техническими требованиями;
d. диаграмма режима работы, которая описывает входные воздействия и
результаты посредством функцией и включает в себя порядок
функционирования, соответствующий критериям входа или выхода;
e. диаграмма управления, которая показывает факторы управления функции и
результирующее поведение;
f. состояния и режимы системы;
g. график времени, который предъявляет требование времени к набору функций;
h. режимы функционального сбоя и таблица эффектов, которая указывает
возможные эффекты режима функционального сбоя, например, невыполнение
того, что предназначено для выполнения, или выполнение функции, выполнения
которой не ожидалось. Следует сформировать возможные решения для каждого
режима сбоя;
i. цели, которые формируют разбиение и отображение технических требований и
характеризуются услугами (режимы работы, функции и операции),
предоставляемыми скрытыми атрибутами (значения, характеристики и данные);
j. набор алгоритмов, полученных из контекстуальных диаграмм.
23

25. Концептуальная модель БЗ IBS
24

26. Концептуальная модель БЗ IBS
25

27. Общая схема навигации
26

28. 27
Модель двух пиков
Источник: В.К. Батоврин Лекции по системной инженерии. Процессы ЖЦ систем .

29. Существующие методологии описания АП
● RUP (4+1)
● DODAF
● Zachman AF
● FEAF
● TEAF
● …
28

30. Что такое Framework?
● «Architecture frameworks address what it means to
define and document an architecture» (http://www.software.org)
● Это различные подходы или рамочныемодели, методики
● Методики задают классификацию основных областей
архитектуры и единые принципы для их взаимосвязного
описания
● Описания используются для определения различных
элементов архитектуры на разных уровнях абстракции
29

31. Зачем нужен Framework?
● «Fundamentally, the problem is communication»
● Они позволяют решить проблему плохого взаимопонимания
между вовлеченными в этот процесс людьми, поскольку
задают некий общий, одинаково понимаемый набор понятий
и моделей для описания элементов архитектуры в интересах
различных категорий заинтересованных сторон.
● Методики не только задают набор документов и планов,
необходимых для описания предприятия, но и определяют,
как все эти элементы описания связаны между собой.
30

32. Три компонента Frameworks
● Views
 Provides the mechanisms for communicating information about the
relationships that are important in your architecture
● Methods
 Provides the discipline to gather and organize the data and
construct the views in a way that helps insure integrity, accuracy
and completeness
● Training/Experience
 Supports the application of method and use of tools
31

33. Три компонента Frameworks
32
Complexity
Training&
Experience
Views
Methods

34. Zachman EF
33

35. FEAF
34

36. DoDAF
35

37. DoDAF in Zachman
36

38. -103-
В TOGAF v. 9.0 сохранился: Метод разработки
архитектуры (Architecture Development Method)
Архитектурное
видение
Архитектура
бизнеса
Архитектуры
ИС
Технологическая
архитектура
Возможности и
решения
Планирование
перехода
Управление
внедрением
Управление
изменениями
Предварительная
стадия
Управление
требованиями
• Предварительная стадия (Preliminary Phase) описывает
инициацию процесса и подготовительную деятельность,
необходимую для подготовки бизнеса, включая определение
специфической для организации архитектурной структуры и
основных принципов.
• Стадия A: Архитектурное видение (Architecture Vision)
описывает начальную стадию цикла разработки архитектуры
и включает определение границ описания, заинтересованных
лиц, формирование архитектурного видения и получение
одобрения со стороны менеджмента.
• Стадия B: Архитектура бизнеса (Business Architecture)
описывает процесс разработки Архитектуры Бизнеса на
основе согласованного Архитектурного видения.
• Стадия C: Архитектуры Информационных систем
(Information Systems Architectures) описывает процесс
разработки архитектур информационных систем, включая
архитектуры данных и приложений для архитектурного
проекта.
• Стадия D: Технологическая архитектура (Technology
Architecture) описывает процесс разработки
Технологической архитектуры для архитектурного проекта.
• Стадия E: Возможности и решения (Opportunities &
Solutions) определяет план и способы внедрения
архитектурных процессов предыдущих стадий.
• Стадия F: Планирование перехода (Migration Planning)
занимается формализацией системы последовательности
переходных архитектур, включая поддержку внедрения и
планы переходов.
• Стадия G: Управление внедрением (Implementation
Governance) обеспечивает архитектурный надзор за
внедрением.
• Стадия H: Управление изменениями архитектуры
(Architecture Change Management) устанавливает
процедуры для управления изменениями архитектуры.
• Управление требованиями (Requirements Management)
контролирует осуществление управления требованиями
сквозь весь процесс ADM.
TOGAF
37

39. TOGAF and ArchiMate
● Business Architecture Views, which address the concerns of the
users of the system, and describe the flows of business information
between people and business processes (e.g. People View, Process
View, Function View, Business Information View, Usability View,
Performance View).
● Information Systems Architecture views, comprising Data
Architecture views and Applications Architecture views, address the
concerns of the database designers and administrators, and the
system and software engineers of the system. They focus on how the
system is implemented from the perspective of different types of
engineers (security, software, data, computing components,
communications), and how that affects its properties. Systems and
software engineers are typically concerned with modifiability, re-
usability, and availability of other services.
● Technology Architecture views address the concerns of the
acquirers, operators, communications engineers, administrators, and
managers of the system.
● Composite views, such as the Enterprise Manageability Views,
addressing the concerns of systems administrators, operators and
managers, and Enterprise security view
38

40. Примеры: Business Layer Concepts
● The main structural concepts at the business layer are business roles and
business actors, an entity that performs behavior such as business processes
or functions. A business role signifies responsibility for one or more business
processes or business functions. A business function denotes the high-level
capabilities of an organization, and offers functionality that may be used in
business processes to realize the products and services of the organization.
Business functions can be connected through flows that describe the
information or goods exchanged.
39

41. Примеры: Business Layer Concepts
● A businessrole is typically assignedto a businessactor.Business actors may be individual
persons(e.g. customersor employees),but also groupsof people and resourcesthathave a
permanent(or at leastlong-term)status within the organizations.Businessprocesses,which
may be triggeredby events and manipulatebusinessobjects,describethe business behaviour
of a role. The externally visible behaviour ofa business processis modelled bythe conceptof
business service,which representsa unit of functionality thatis meaningfulfrom the pointof
view of the environment.Not shown in the example is thatservicescan be grouped to form
(financialor information)products,togetherwith a contractthat specifies the associated
characteristics,rights and requirements.
40

42. Примеры: Application Layer Concepts
● The main structuralconceptfor the applicationlayer is the application component.This
conceptcan be used to modelany structuralentity in the applicationlayer:notjust (reusable)
software componentsthatcan be part of one or more applications,butalso complete software
applicationsor information systems.Behaviour in the application layercan be describedin a
way that is very similar to businesslayer behaviour.Again,we make a distinction between the
externally visible behaviour of application componentsin terms of application services,and
the internalbehaviour, application functions, that realise theseservices1.Servicesare offered
throughthe applicationinterfaces of an application.Data objects are used in the same way as
data objects (or objecttypes)in well-knowndata modellingapproaches,mostnotably the
‘class’conceptin UML class diagrams.
41

43. Примеры: Application Layer Concepts
42

44. Спасибо за внимание!
Купин Станислав
Симкин Анатолий
Группа 9111
26.11.2009
Вставьте
картинку

45. Системная инженерия. Управление архитектурой при проектировании систем
Учебный процесс Магистратуры IBS. Академия IBS.
Дата вступления в силу: 26.11.2009 Версия: 4 Стр: 1/10
Реферат по курсу
«Системная инженерия»
«Управление архитектурой при проектировании
систем»
Подготовил: Анатолий Симкин, Станислав Купин
Проверил: Батоврин Виктор Константинович
Содержание
Введение в понятие Архитектуры ................................................................................................................................................................1
Что такое архитектура?...............................................................................................................................................................................1
Особенности архитектуры.........................................................................................................................................................................1
Введение в терминологию и понятийную область .............................................................................................................................2
Процесс проектирования архитектуры .......................................................................................................................................................4
Технические процессы ISO/IEC 15288...................................................................................................................................................4
Применение технических процессов ......................................................................................................................................................5
Процесс проектирования архитектуры ..................................................................................................................................................6
Логическая и физическая архитектура...................................................................................................................................................8
Проектирование логической архитектуры............................................................................................................................................9
Введение в понятие Архитектуры
Что такое архитектура?
Колизей в Риме – не есть архитектура (см. рисунок Рисунок 1). Это Результат архитектуры.
Результат это следствие архитектуры. Этот тезис доказывает следующим примером: если бы
архитектор не создал описательную модель (архитектуру) в каком-либо из видов, то римляне не
смогли бы построить само здание. Они бы даже не смогли заказать камни для его постройки. Вывод
в том, что создание сложных систем без создания их архитектуры занятие практически
невозможное. А если и возможное, то это существенным образом повлияет на процесс создания,
качество системы и ее стоимость.
Особенности архитектуры
Архитектура обладает некоторыми особенностями:
o Архитектура определяет важнейшие компоненты
o Архитектура определяет, как компоненты связаны между собой (структуру) и как они
между собой взаимодействуют, используя эти связи

46. Системная инженерия. Управление архитектурой при проектировании систем
Учебный процесс Магистратуры IBS. Академия IBS.
Дата вступления в силу: 26.11.2009 Версия: 4 Стр: 2/10
o Архитектура не рассматривает информацию об устройстве компонентов
безотносительно к их взаимодействию между собой
o Каждая система имеет архитектуру (даже в том случае, когда система состоит из одного
компонента)
o Архитектура определяет логическое обоснование связи между компонентами и
структурой
o Определение архитектуры не подразумевает определения того, что из себя представляет
компонент
o Архитектура это не только взаиморасположение частей системы – сведения о взаимном
расположении частей системы не задают архитектуру
o Поведение компонентов является частью архитектуры в той мере, в которой оно может
быть заметно, может ощущаться с точки зрения другого компонента
Рисунок 1. Колизей
Введение в терминологию и понятийную область
Теоретически, человек может начать создавать требуемую ему систему в натуральную
величину, непосредственно в металле и камне, методом проб и ошибок. Для больших систем это
происходит крайне редко (говорят, так строил великий архитектор Гауди). В основном люди
начинают работать с описаниями системы (текстами, чертежами, макетами, симуляторами) и даже
после создания самой системы (построенного дома, корабля, АЭС) работа с описаниями занимает у
них существенное время. Поэтому особое внимание мы посвятим разным способам описания, для
чего введем некоторые строгие определения для вольно использующихся в этой сфере слов,
постаравшись обеспечить их соответствие терминологии, используемой в международных
стандартах.
Некая система может выступать в роли модели целевой системы, если она может быть
использована для получения информации о целевой системе без непосредственного контакта с
целевой системой. Модели могут быть как материальными (макеты, прототипы), так и знаковыми,
то есть состоящими из слов, чисел, формул, рисунков. Знаковую систему-модель целевой системы
мы будем называть описанием целевой системы.

47. Системная инженерия. Управление архитектурой при проектировании систем
Учебный процесс Магистратуры IBS. Академия IBS.
Дата вступления в силу: 26.11.2009 Версия: 4 Стр: 3/10
Описание целевой системы - знаковая система, составленная из совокупности фактов
(утверждений) о целевой системе (бывшей, нынешней, будущей), которая может быть использована
для получения данных о целевой системе без доступа к ней.
Все элементы описания системы являются фактами (утверждениями) – о её элементах, о
связях между ними и их связях с внешним миром. Эти факты могут иметь разную природу: они
могут относиться к целевой системе, как она есть сейчас, к тому, какой она была в прошлом, какой
она должна быть в будущем, или какой она, скорее всего, будет в будущем. Описание системы
включает всю информацию, которая когда-либо была (или будет) порождена о системе.
Описания систем часто существуют как разрозненные наборы сведений в разных шкафах и в
разных компьютерах, разнесённых на тысячи километров друг от друга. «Хорошим» описанием
может считаться только такое описание, в котором каждый факт появления новой информации
учитывается, то есть в едином месте можно узнать о том, что появлениеили изменениеинформации
произошло, кто и когда его произвёл, какой его статус (предложение, одобренное предложение,
утверждённый вариант), как его найти.
Информационная модель – датацентрическое описание системы, являющееся в то же время
единой учётной системой.
Метод описания – состоящий из онтологии и нотации способ получения тематических
описаний системы, позволяющих удовлетворить определённые интересы определённых
стейкхолдеров.
Тематическая группа описаний – группа взаимосвязанных описаний, получение которых
описывается одним методом описания.
Подытоживая, можно указать важнейшие связи между понятиями:
Каждый стейкхолдер характеризуется набором своих интересов. Интересы разных
стейкхолдеров могут пересекаться. Каждое описание системы предназначено для удовлетворения
одного или нескольких интересов. Каждое описание системы входит в какую-либо тематическую
группу описаний (чаще всего в одну такую группу), порождённую одним методом описания. Если
какое-то описаниевходит в разные тематические группы, то это означает, что способ его получения
также входит в разные методы описания.
Понятия стейкхолдер (stakeholder), интерес (concern), метод описания (viewpoint),
тематическая группа описаний (view), отдельное описание (model) и их связи соответствуют
основным понятиям и связям, введённым международным стандартом ISO/IEC 42010:2007 Systems
and software engineering - Recommended practice for architectural description of software-intensive
systems.
Подход (framework) - способ создания, интерпретации и использования в качестве норм
описаний системы. Подход включает:
 набор стейкхолдеров и их интересов к системе;
 методы рассмотрения и описания систем и правила их применения, включающие:
o предметную (тематическую) онтологию метода;
o нотации для графического или текстового представления соответствующих
предметной онтологии метода фактов о системе;
Определение подхода позволяет говорить о наличии подхода при наличии минимального
набора элементов (набора интересов и согласованных методов получения описаний для адресации
этих интересов), позволяющего создать осмысленный набор описаний системы, пригодный для
применения какими-то стейкхолдерами. Подход системной инженерии ISO/IEC 15288:2008
основан более широком системном подходе, содержит ссылки на архитектурный подход, включает
элементы процессного подхода и проектного подхода, подробнее о которых будет рассказано ниже.
Описание системы может быть выполнено с разной степенью абстракции. Мы будем говорить о
разных уровнях абстракции при описании системы.
Уровни описания системы:
• опорный (в основном функциональный);

48. Системная инженерия. Управление архитектурой при проектировании систем
Учебный процесс Магистратуры IBS. Академия IBS.
Дата вступления в силу: 26.11.2009 Версия: 4 Стр: 4/10
• принципиальный (в основном конструкционный);
• выполняемый (инструкции);
• исторический (измерения, временные ряды, отчёты):
• актуальные (измеренные)
• прогностические (прогнозные данные)
• нормативные (показатели эффективности)
Подход, предписывающий составление только архитектурных описаний, но зато
удовлетворяющих интересам всех известных на момент описания стейкхолдеров, называется
архитектурным подходом. В рамках архитектурного подхода, естественно, должны быть
применены все методы описания, позволяющие учесть интересы этих стейкхолдеров.
Архитектурный подход - подход к получению множества архитектурных описаний системы,
отвечающих всем известным интересам всех известных стейкхолдеров. Стандарт - это описание,
используемое как норма, то есть предполагающее проверку соответствия целевой системы этому
описанию.
Процесс проектирования архитектуры
Технические процессы ISO/IEC 15288
Рисунок 2. Технические процессы ISO/IEC 15288
Технические процессы используются для определения требований к системе, преобразования
этих требований в эффективный продукт, позволяющий осуществлять, при необходимости,
устойчивое воспроизводство этого продукта, использовать его для обеспечения требуемых услуг,
поддерживать обеспечение этими услугами и удалять продукт, когда он изымается из обращения.
Технические процессы определяют совокупность работ, которые позволяют в рамках задач
предприятия и проекта оптимизировать прибыли и уменьшать риски, возникающие вследствие
принятия технических решений и осуществления соответствующих действий. Эти работы
обеспечивают условия для того, чтобы продукция и услуги были нужными и полезными,
экономически выгодными, функциональными, надежными, пригодными к обслуживанию,
производству и использованию и обладали другими качествами, необходимыми для того, чтобы

49. Системная инженерия. Управление архитектурой при проектировании систем
Учебный процесс Магистратуры IBS. Академия IBS.
Дата вступления в силу: 26.11.2009 Версия: 4 Стр: 5/10
удовлетворить требования, как приобретающих организаций, так и организаций-поставщиков. Они
также обеспечивают условия для того, чтобы продукция и услуги соответствовали ожиданиям или
законодательным требованиям общества, включая требования к факторам здоровья, безопасности,
защиты и экологии.
Применение технических процессов
Рисунок 3. Модель применения технических процессов
Рисунок Рисунок 3 дает модель для применения технических процессов. Эта модель включает
в себя только технические процессы, которые используются, прежде всего, для того, чтобы
проектировать интересующую систему. В данной модели изображены не всетехнические процессы,
которые используются для определения входных данных к процессу определения требований,
которые могут быть в форме требований покупателя или в форме требований других
заинтересованных сторон.
Процесс определения требований заинтересованных сторон, Процесс анализа требований и
Процесс проектирования архитектуры используются для того, чтобы проектировать решение
каждой системы в системной структуре. Применение этих процессов может быть в высшей степени

50. Системная инженерия. Управление архитектурой при проектировании систем
Учебный процесс Магистратуры IBS. Академия IBS.
Дата вступления в силу: 26.11.2009 Версия: 4 Стр: 6/10
итеративным, чтобы достичь требуемого решения проекта (см. п. 5.5.3.3 ISO/IEC TR 19760).
Процесс реализации, Процесс интеграции, Процесс переноса и Процесс валидации используются
для того, чтобы реализовать решение проектирования архитектуры для каждой системы в
системной структуре. Применение всех этих процессов может быть очень в высшей степени
итеративным. Первые три процесса рекурсивно применяются к интересующей системе, а затем к ее
системам сверху вниз до тех пор, пока системный элемент не сможет быть реализован (например,
сформирован, приобретен, использован повторно) с использованием Процесса реализации. Это
происходит, когда не надо разрабатывать никаких дальнейших систем. После того, как все
системные элементы системной структуры реализованы, Процесс интеграции, Процесс
верификации, Процесс переноса и Процесс валидации рекурсивно выполняются для каждой
системы снизу вверх, включая интересующую систему на верхнем уровне.
Процесс проектирования архитектуры
Рисунок 4. Контекстная диаграмма процесса проектирования архитектуры
Цель процесса проектирования архитектуры
Цель процесса проектирования архитектуры состоит в синтезе решения, которое бы
удовлетворяло системным требованиям.
Общая характеристика процесса проектирования архитектуры
Этот процесс выделяет и устанавливает области решения, представленные в виде набора
различных проблем управленческого, концептуального и, наконец, реализационного характера. В
рамках процесса определяются и исследуются одна или несколько стратегий реализации системы
со степенью детализации, соответствующей техническим и коммерческим требованиям и рискам.
Исходя из этого выбирается решение о проектировании архитектуры. Оно определяется на основе
требований к набору системных элементов, из которых компонуется система. Конкретные
требования, формируемые в результате этого процесса, являются основой для проведения
верификации реализованной системы и для разработки стратегий комплексирования и
верификации.
Описание процесса проектирования архитектуры

51. Системная инженерия. Управление архитектурой при проектировании систем
Учебный процесс Магистратуры IBS. Академия IBS.
Дата вступления в силу: 26.11.2009 Версия: 4 Стр: 7/10
Процесс проектирования архитектуры требует участия системных инженеров совместно с
соответствующими специалистами в системных областях. Когда появляются альтернативные
решения, для идентификации набора элементов системы в рамках этого процесса применяется
технический анализ и принимаются решения. Интеграция определяется для системы в целом, а не
для отдельных ее компонентов. Рисунок Рисунок 4 представляет собой контекстную диаграмму для
процесса проектирования архитектуры.
Входы
Проектирование архитектуры начинается с функциональных и технических требований
базовой линии, архитектурных ограничений и Матрицы Отслеживания Требований (Requirements
Verification and Traceability Matrix – RVTM). Спецификации обеспечивающих систем используются
для управления проектированием интерфейсов. Спецификации для повторно используемых
элементов системы используются при проектировании продуктовых линеек.
Выходы
Результатом этого процесса является проект архитектуры, который помещается в управление
конфигурацией. Эта исходная конфигурация (baseline) включает:
 Детальные описания элементов системы с задокументированным обоснованием выбора
концепции
 Требования, предъявленные к элементам системы и задокументированные в Матрице
Отслеживания Требований
 Требования к интерфейсам, план интеграции системы и стратегия верификации
Действия в процессе
Следующие процессы вносят вклад в разработку архитектуры:
 Определить непротиворечивую логическую архитектуру – зафиксируйте логический
порядок следования и взаимодействие функций системы или логических элементов
 Разделить системные требования и распределить их по элементам системы и подсистемам с
соответствующими требованиями к производительности – оценить существующие
коммерческие решения
 Оценить альтернативные архитектурные решения, среди следующих критериев выбора:
o Мера способности системы выполнять свои цели в соответствии с требованиями.
o Способность функционировать в пределах ограничений на ресурсы
o Согласованность ее интерфейсов
o Цены, экономические и прочие, внедрения и функционирования системы в течение
всего жизненного цикла
o Побочные эффекты, как благоприятные, так и негативные, ассоциирующиеся с
вариантами архитектурных решений
 Выделить интерфейсы и взаимодействия между элементами системы (включая человеческие
элементы системы) и с внешними и обеспечивающими системами
 Определить стратегию и план интеграции системы (включая интеграцию с человеческими
элементами системы)
 Задокументировать и поддерживать результат архитектурного проектирования и
соответствующие решения, принятые, чтобы достичь соглашения по архитектуре в базовой
линии
 Установить и поддерживать отслеживаемость между требованиями и элементами системы
 Определить критерии верификации и валидации элементов системы
Результат процесса
В результате успешного осуществления процесса проектирования архитектуры:

52. Системная инженерия. Управление архитектурой при проектировании систем
Учебный процесс Магистратуры IBS. Академия IBS.
Дата вступления в силу: 26.11.2009 Версия: 4 Стр: 8/10
 устанавливается порядок, в соответствии с которым выполняется проектирование
архитектуры;
 задается реализуемый набор описаний системных элементов, которые удовлетворяют
требованиям, предъявляемым к системе;
 требования к интерфейсу включаются в решение по проектированию архитектуры;
 устанавливается связь между проектированием архитектуры и системными требованиями;
 определяется основа для верификации системных элементов;
 устанавливается основа комплексирования системных элементов.
Распространенные подходы и советы:
 При выводе логической архитектуры полезны такие техники моделирования как SysML.
 Используйте группу разработки продукта для анализаи проверки; работа в команде помогает
сломать коммуникативные барьеры и способствует принятию решений.
 Шаблоны архитектуры и проектирования могут оказаться полезными для определения
структуры (framework) системы.
 Элементы системы могут быть разработаны при помощи вертикального разбиения, которое
ставит в соответствие функциональным элементам физические или виртуальные элементы
системы. В идеале, требования к интерфейсам между этими элементами минимальны. В то
же время, коммерческие или разработанные ранее элементы системы рассматриваются в
пределах ограничений на стратегию заключения контрактов.
 Во время этого процесса рассматривайте возникающие свойства, взаимосвязь между
характеристиками, и взаимодействие с человеческими системами.
Логическая и физическая архитектура
Рисунок 5. Пример взаимосвязи логической и физической архитектуры NATO

53. Системная инженерия. Управление архитектурой при проектировании систем
Учебный процесс Магистратуры IBS. Академия IBS.
Дата вступления в силу: 26.11.2009 Версия: 4 Стр: 9/10
Логическая архитектура
 Логическая архитектура представляет собой функциональную структуру, которая в течение
ЖЦ дает возможность системе для реализации всех заданных сценариев функционирования.
 Сценарии функционирования ставят в соответствие целям системы цепочки выполняемых
задач.
Физическая архитектура
 Физическая архитектура системы представляет собой совокупность физических элементов,
которые поддерживают функционирование системы.
 Физические элементы взаимодействуют между собой с использованием входов и выходов и
управления физическими соединениями.
 Конкретные характеристики элементов определяются их природой (программа, человек,
оборудование, аппаратное средство…), в абстрактном смысле элемент характеризуется
своим назначением и своими целями
Проектирование логической архитектуры
Состав
Данное действие включает идентификацию и определение производных требований для
описания функциональных и эксплуатационных требований, функциональных возможностей и
свойств, требований к своевременности, к потокам данных и т.д. в соответствии с логической
архитектурой. Перед разделением логической архитектуры на физические элементы, противоречия
внутри и между различными логическими описаниями должны быть разрешены и каждая
логическая архитектура должна быть представлена в завершенном и непротиворечивом виде
посредством проведения проверок совместимости с заданными системными требованиями.
Применение
Логическое проектирование архитектуры включает в себя обращение к различным
логическим декомпозициям и другим представлениям требований. Нет никакого установленного
формата или формы для различныхпредставлений.Выбранная формат или форма — это те, которые
лучше всего определяют функциональную структуру, структуру режима работы, потока данных или
данных, по обстановке, а также позволяют осуществить лучшее назначение на потенциальные
физические элементы, средства ручного управления или вспомогательные системы для того, чтобы
генерировать альтернативные решения проектирования архитектуры на физическом уровне.
Определенные технические требования надлежащим образом распределяются между
созданными представлениями логического проектирования архитектуры. Из различных
представлений создается набор производных технических требований, который используется для
проектирования архитектуры. После того, как это распределение будет завершено, могут остаться
нераспределенные технические требования. Они назначаются непосредственно на альтернативные
решения проектирования архитектуры на физическом уровне.
Этапы логического проектирования
Первым шагом следует преобразовать набор технических требований к более
детализированному набору производных (derived) технических требований, которые были
получены из набора моделей логического проектирования архитектуры [см. п. 5.5.4.3 a)
Международного стандарта ISO/IEC 15288]. Это может быть достигнуто путем выполнения
деятельности по логическому проектированию архитектуры Процесса проектирования
архитектуры.
Модели логического проектирования архитектуры могут принимать одну или несколько
форм, как те, которые описаны ниже:
a) блок-схема функционального потока, отражающая декомпозицию главных функций в их
подфункции;

54. Системная инженерия. Управление архитектурой при проектировании систем
Учебный процесс Магистратуры IBS. Академия IBS.
Дата вступления в силу: 26.11.2009 Версия: 4 Стр: 10/10
b) диаграмма информационного потока, которая раскладывает функции на составные части,
явно демонстрируя данные, необходимые для каждой функции;
c) структура данных с соответствующими им функциями и потоки обработки данных,
относящиеся к данным и связанные с назначенными техническими требованиями;
d) диаграмма режима работы, которая описывает входные воздействия и результаты
посредством функцией и включает в себя порядок функционирования, соответствующий
критериям входа или выхода;
e) диаграмма управления, которая показывает факторы управления функции и результирующее
поведение;
f) состояния и режимы системы;
g) график времени, который предъявляет требование времени к набору функций;
h) режимы функционального сбоя и таблица эффектов, которая указывает возможные эффекты
режима функционального сбоя, например, невыполнение того, что предназначено для
выполнения, или выполнение функции, выполнения которой не ожидалось. Следует
сформировать возможные решения для каждого режима сбоя;
i) цели, которые формируют разбиение и отображение технических требований и
характеризуются услугами (режимы работы, функции и операции), предоставляемыми
скрытыми атрибутами (значения, характеристики и данные);
j) набор алгоритмов, полученных из контекстуальных диаграмм.
Рисунок 6. Пример логической архитектуры MIT: Information Technology Architecture Group
Каждую модель логического проектированияархитектуры следует оценить,чтобы определить
воздействие модели на качество системы.
SAP DB
(Oracle)
Users
SAP ITS
SAP Client
Browser
Client
(SAP WEB)
System
Component
Key:
Related
System
Other MIT
System
SAP Application Server
Kerberos
Server
Authentication
forSAPClients
External
Systems
Other MIT Systems
Incoming:
Data Warehouse
Roles DB
SAP - Lincoln Lab
Mainframe
COEUS
MIT ID
Broad Institute
Outgoing:
 Data Warehouse
 Archive (IX0S)
Server
 Broad Institute
 MIT ID (Real Time)
External Systems
Incoming:
 Benefit Providers
 Financial Institutions
 EDI
Outgoing:
ECAT Vendors
Financial Institutions
Benefits Providers
Financial
Accounting
Materials
Management
Controlling
Sales and
Distribution
ProfitCenter
Account
Classification
System
Human
Resources
Payroll
Labor
Distribution
Cross
Application
X509Certificates
Drop
Box
SAP Web
Classic
Plant
Maintenance
TrainingEvents
Management