BMSTU/03-system-engineering.tex

\documentclass{article}

\input{../common-preamble}
\input{../bmstu-preamble}
\input{../fancy-listings-preamble}
\author{Девятков Владимир Валентинович}
\title{Системная инженерия}
\date{2022-09-05}

\begin{document}
\maketitle
\tableofcontents
\newpage

\section{Системная инженерия}
Системная инженерия - Полный набор технических и управленческих усилий, необходимых для преобразования совокупности потребностей и ожиданий клиента и имеющихся ограничений в реализацию и поддержку этой реализации на протяжении ее существования. Целостное и согласованное понимание потребностей заинтересованных сторон. Исследование возможностей реализации. Документирование требований к реализации. Синтез, верификация, валидация и развитие решений при при осуществлении реализации во всей полноте от исследования замысла системы до её ликвидации.

Стандартизация
\begin{itemize}
\item International Council on Systems Engineering, INCOSE: развивает междисциплинарный подход и средства для обеспечения реализации успешных систем (см. Guide to the Systems Engineering Body of Knowledge, SEBOK).
\item ISO/IEC/IEEE 24765:2010: междисциплинарный подход - полный набор технических и управленческих усилий, необходимых для преобразования совокупности потребностей и ожиданий клиента и имеющихся ограничений в решение для поддержки этого решения на протяжении его жизни
\end{itemize}

Авторские определения
\begin{itemize}
\item Sage A.P. ... проектирование, производство и сопровождение заслуживающих доверия систем с учетом стоимостных и временных ограничений
\item Д. Хитчинс, бывший президент, INCOSE ... искусство и наука создания эффективных систем на основе целостного подхода к системе и принципам её жизни
\item А. И. Левенчук , президент российского отделения INCOSE ... это про то, как создать что угодно (от зубочистки до марсохода) в соответствии с требованиями заказчика, и при этом соблюсти бюджет и сроки
\item Н. П. Бусленко, Большая советская энциклопедия, 1976 . Научно-техническая дисциплина, охватывающая вопросы проектирования, создания, испытания и эксплуатации сложных систем (больших систем, большого масштаба (large scale systems))
\end{itemize}

Что такое успешная система?
\begin{itemize}
\item Система успешна тогда и только тогда, когда с ее помощью добиваются успеха все ключевые стейкхолдеры (заинтересованные стороны) (Д. Хитчинс)
\item Система успешна тогда и только тогда, когда в выигрыше окажутся все критически важные заинтересованные стороны (стейкхолдеры) (Б. Боэм)
\end{itemize}

В США
\begin{itemize}
\item 1940-е: Появление очень сложных проектов: морские операции на Тихом океане, ядерный проект.
\item 1950-1960-е:
  \begin{itemize}
  \item Увеличение числа сложных проектов: например, космический проект.
  \item Появление первых работ, описывающих подходы к созданию сложных систем
  \item СИ впервые появилась как метод ведения работ в МО США по созданию МБР (межконтинетальных баллисьтических ракет) на базе двух уже сверхсложных инженерных проектов:
    \begin{itemize}
    \item атомного проекта,
    \item проекта создания баллистических ракет.
    \end{itemize}
  \end{itemize}
\item 1965 - А. Д. Холл «Методология системной инженерии» :
  Системная инженерия многоаспектна. Цель процесса СИ является оптимальное проведение границ между человеческими интересами, системой и ее окружением. В окружении выделяются:
  \begin{itemize}
  \item Физическое и техническое окружение.
  \item Деловое и экономическое окружение.
  \item Социальное окружение.
  \item СИ исследует потребности рынка и возможность изменения этих потребностей как в настоящем, так и в будущем.
  \end{itemize}
\end{itemize}

В СССР
\begin{itemize}
\item 1920 - План ГОЭЛРО, описывавший развитие электроэнергетики. К плану были привязаны:
  \begin{itemize}
  \item Проекты по индустриализации.
  \item Проекты по развитию инфраструктуры.
  \item Планы развития территорий.
  \end{itemize}

  Размеры:
  \begin{itemize}
  \item В разработке участвовало более 200 учёных и инженеров.
  \item Период от 10 до 15 лет.
  \end{itemize}
\item 1962 - появляется термин «Системотехника» в результате перевода книги «System Engineering: An Introduction to the Design of Large-scale Systems».
\item 1960-1980:
  \begin{itemize}
  \item Создается научная школа системотехники, включая НИИ, кафедры и дисциплины в ВУЗах.
  \item Ведутся работы по выполнению больших и сверхбольших проектов.
  \end{itemize}
\item Системотехника 80-х

  Теория:
  \begin{itemize}
  \item Научные школы.
  \item Специализированные издания, публикации.
  \item Подготовка специалистов.
  \end{itemize}

  Практика:
  \begin{itemize}
  \item Свелась к разработке ПО для АСУ.
  \item Практически не влияла на управление производством, разработку, внедрение.
  \end{itemize}
\end{itemize}

Поколения СИ
\begin{itemize}
\item Классическая системная инженерия
  \begin{itemize}
  \item Использование диаграмм
  \item Предназначены для чтения и интерпретации только людьми, описание системы нельзя формально проверить
  \end{itemize}
\item Системная инженерия на основе моделей (model-based systems engineering)
  \begin{itemize}
  \item Использование формальных моделей
  \item Модели могут быть непосредственно обработаны (проверены, оптимизированы) компьютером
  \item Позволяет достигать принципиально другой сложности систем
  \end{itemize}
\end{itemize}

\subsection{Системная инженерия как процесс}
\begin{itemize}
\item Формулировка потребностей (требований заказчика)

  Формулировка потребностей включает изложение «принципов» (principles) и «концепций» (concepts), как набора компонентов, взаимодействующих между собой для достижения целей. Этими компонентами могут быть :
  \begin{itemize}
  \item «Железо» hardware, ПО, firmware
  \item Люди (не только пользователи)
  \item Информация (например, структуры БД)
  \item «Техники» (techniques)
  \item Здания, помещения и другая инфраструктура (facilities)
  \item Сервисы (services)
  \end{itemize}

\item Постановка задачи

  Системный инженер поддерживает междисциплинарный подход и переводит потребности заказчика в задания исполнителям, помогает оценивать соответствие результатов разработки этим потребностям. Системный инженер учитывает взаимодействие с окружающей средой, которая может представлять собой:
  \begin{itemize}
  \item другие системы,
  \item пользователей,
  \item физический окружающий мир.
  \end{itemize}

\item Обеспечение реализации системы

  Системные инженеры для обеспечения реализации успешных систем  анализируют выполнение процессов жизненного цикла, начиная с раннего этапа концептуального принятия решений (conceptual design), на всем жизненном цикле системы, включая производство, развертывание/внедрение (deployment) эксплуатацию и вывод из нее. Системный инженер должен анализировать, составлять ТЗ (specify), разрабатывать архитектуру (design) и проверять на соответствие потребностям следующие характеристики системы:
  \begin{itemize}
  \item Функциональность.
  \item Интерфейсы.
  \item Производительность.
  \item Физичекое состояние.
  \item Баланс между ценой и соответствием потребностям
  \end{itemize}

\item Обеспечение взаимодействия компонентов

  Системный инженер помогает обеспечить взаимодействие компонентов системы (fit together) для достижения общих целей системы, а также удовлетворения потребностей заказчиков и других заинтересованных лиц, которые получают (принимают, acquire) систему и далее ее используют.
\end{itemize}

\subsection{Главные свойства системной инженерии}
Целостность (holistic) — это ключевое свойство, отличающее СИ от всех остальных инженерных дисциплин. Целостность включает:
«Междисциплинарность» - полнота охвата всех необходимых дисциплин. Целостность всех действий по созданию системы. Целостность/полнота проблемы. Охват всего жизненного цикла системы «от рождения до смерти».

Параллельность выполнения самых разных практик, а не последовательное выполнение их во времени. Разнесение:
\begin{itemize}
\item Нужд пользователей и требований к реализации.
\item Проверки и приёмки.
\item Синтеза и аналитики.
\end{itemize}

СИ как единое целое это
\begin{itemize}
\item Область применения: Большие (сложные) системы, весь  их жизненный цикл.
\item Философия (мировоззрение): Системный взгляд на все.
\item Средства: Совокупность практик, процессов, методов.
\end{itemize}

\subsection{Будущее системной инженерии}
Поискориентированная системная инженерия (search-based systems engineering) на основе интеллектуального компьютерного рассуждения при поиске и обосновании требований, архитектуры, методов, практик и т.п.:
\begin{itemize}
\item Искусственная интеллектуальная генерация вариантов инженерных решений.
\item Искусственное интелектуальное умение  оценить варианты.
\item Искусственные интеллектуальные гибридные рассуждения при достижении целей.
\end{itemize}

Цели и контракты
\begin{itemize}
\item Формалные синтез и оптимизация архитектуры, соответсвующей контрактам и целям
\item Искусственное воображение
\item Использовние методов ИИ (например, вариации «генетических алгоритмов» или «обучаемых нейронных сетей»)
\item Порождающее проектирование (generative design)
\item Пока больше используется для визуализации данных, но может быть применено для вычисления оптимальной формы объектов
\end{itemize}

\section{Концептуальные аспекты инженерии знаний}
Знания – основа интеллектуальности систем. Знания в системах искусственного интеллекта обычно хранятся в базах знаний. Знания содержат информацию как о конкретных (константных) фактах в той или иной предметной области (среде, мире), так и о более общих законах и свойствах, позволяющих получать (рассуждать, выводить) новые знания. Понятие "знание" имеет два аспекта: декларативный и процедурный.

\textbf{Декларативные знания} не содержат в явном виде описание процедур, которые необходимо выполнить в процессе вывода.
Вывод на основе декларативных знаний осуществляется по определенной стратегии вывода специальной машиной вывода (решателем).
Например, вывод (поиск решения) может быть организован как поиск в пространстве состояний,  и сводится к нахождению последовательности состояний ведущих из начального состояния (начальных) в  целевое состояние.

\textbf{Процедурные знания} - это знания, представляемые в виде процедур, с помощью которых осуществляется вывод. Вывод на основе процедурных  знаний также может осуществляться машиной вывода, организующей вызов процедур в соответствии  с определенной стратегией.

Сочетание преимуществ декларативного и процедурного подхода к представлению знаний по-разному воплощается в различных языках и моделях представления знаний.

ИИ функционирует на основе знаний
ИИ занимается созданием специализированных моделей и языков для представления знаний в ЭВМ,
ИИ занимается созданием специальных средств, позволяющих пополнять и обобщать знания.
ИИ занимается созданием программных и аппаратных средств для работы со знаниями;
ИИ занимается созданием методов формирования планов достижения целей и решения сложных задач, не поддающихся решению другими методами, кроме как на основе использования знаний
ИИ занимается созданием средств восприятия мультимодальной информации (зрительной, слуховой, тактильной и др),
ИИ занимается развитием методов мультимодальной обработки и формирования ответных реакций на воздействия внешней среды,
ИИ занимается развитием методов адаптации искусственных систем к среде путем обучения.

Какое представление знаний нам необходимо?
Насколько представление знаний должно быть понятным и ясным?
Насколько представление знаний должен быть лаконичным?
Насколько оно должно быть вычислительно эффективным (способным порождать новые знания)?
Насколько оно должно быть модульным?
Насколько  оно должно быть доступным из разных мест?
Какова должна быть охватываемая область представления?
Какова должна быть неделимая часть?
Каков должен быть уровень детализации?
Должен ли быть базовый словарь?
Насколько легко можно знания модифицировать?
Могут ли быть изменены отдельные элементы без влияния на другие?
Как представлять отдельные модули?
Каков  должен быть механизм извлечения знаний?
Каковы должны быть отношения между старыми и новыми знаниями?
Какова должна быть форма обобщения и специализации знаний?
Какова должна быть процедура поиска необходимых знаний?
Как знания должны быть организованы: иерархически, на базе отношений, ассоциативно?
Какие отношения возможны между группами знаний?
Нужны ли оба механизма работы со знаниями: синтаксический и семантический?
Какой нужен механизм вывода?
Нужно ли поддерживать дедуктивный, индуктивный и абдуктивный выводы?
Нужно ли продолжать вывод, если информация стала неопределенной?
Нужно ли продолжать вывод, если информация отсутствует?
Должны ли все знания быть явно представленными или решатель может дополнять их?
Какие знания должны быть представлены обязательно явно?
Может ли структура представления знаний расширяться и модифицироваться?
Может ли решатель модифицироваться?

\subsection{Дедукция, абдукция, индукция}
\begin{table}[H]
  \centering
  \begin{tabular}{|r|c|c|c|} 
    \hline
    Последовательность логических действий & Дедукция & Абдукции & Индукция \\ [0.5ex] 
    \hline\hline
Логический шаг №1 & Анализ заранее заданной гипотезы & Анализ и точная оценка фактов & Анализ и точная оценка частных фактов \\
Логический шаг №2 & Вывод следствий из гипотезы и их сопоставление с фактами & Выбор гипотезы для объяснения фактов & Движение мысли от частного к общему\\
    \hline
  \end{tabular}
  \caption{Table to test captions and labels.}
  \label{table:1}
\end{table}

Абдукция – это «обратная» дедукция, так сказать, дедукция, поставленная с ног на голову. Если в дедукции рассуждение развивается от посылки к следствию, то в случае абдукции – в противоположном направлении, то есть от следствия к посылке. Нормальное дедуктивное рассуждение таково «Все люди смертны, Сократ – человек, следовательно, Сократ смертен». Здесь налицо логически необходимый вывод. 
В случае абдукции силлогизм приобретает следующую форму: «Все люди смертны, Сократ смертен, следовательно, Сократ человек». Может показаться, что здесь все нормально, но если вдуматься, то становится ясно, что вывод неправильный: из того, что Сократ смертен, вовсе не следует, что Сократ человек, ведь смертны и кошки, и собаки, и бабочки, и, может быть, деревья.

Трудности обмена знаниями
Представление знаний даже об одних и тех же вещах и на одном и том же языке может быть различным.
Это приводит к трудностям обмена знаниями между людьми, организациями и программами, и, в частности, к трудностям формирования однозначно понимаемых требований и спецификаций для сложных систем.
Несмотря на достаточно продвинутый уровень развития сложных систем, возможности повторного использования и распространения знаний ограничены.
Это приводит к повторным усилиям по извлечению и необходимых знаний.

\begin{verbatim}
Источник -> Структурирование -> Представление
файлы      графы               Модели
Хаос        Извлечение          Формализация
\end{verbatim}

\subsection{Стандартизация знаний}
Ответ на многие из поставленных вопросов может быть получен путем стандартизации знаний? 
Стандартизация устранит или сведет к минимуму концептуальную и терминологическую путаницу и установит однозначное понимание языка, используемого для представления знаний
Такой язык должен служить средством 
стандартизации представления знаний, 
коммуникации между людьми, имеющими различный взгляд на одни и те же вещи,
взаимодействия между программными системами путем трансляции в него и из него, 
обеспечения возможности повторного использования благодаря формальной спецификации, 
автоматизации проверки корректности знаний, 
адекватного представления других языков представления знаний.

Трудности извлечения знаний
организационные неувязки;
неудачный метод извлечения, не совпадающий со структурой знаний в данной области;
неадекватная модель (язык) для представления знаний.
неумение наладить контакт с источником знаний;
терминологический разнобой;
отсутствие целостной системы знаний в результате извлечения только «фрагментов»;
упрощение «картины мира» и др.

Концептуальные графы
Авторы идеи - Новак и Говин (Novak and Gowin). 1960-ые. Большой вклад внес David Ausubel.
Этапы
выделение концептов — базовых понятий данной предметной области(обычно не более 15-20 понятий);
определение отношений и взаимодействий базовых понятий;
уточнение, удаление лишних связей, снятие противоречий.
Типичные ошибки:
•    Целые предложения вместо отдельных концептов
•    Линейность
•    Слишком много пересекающихся отношений
•    Слишком много концептов
•    Неверно определенные типы отношений
“Хороший” граф обычно получается после 2-3 итераций.
Software: CmapTools

Основные виды отношений
родо-видовые ("класс-подкласс", "элемент-множество", "часть - целое" и т.п.),
•    функциональные (определяемые обычно глаголами, ’’производит”, “влияет”...),
•    атрибутивные (иметь свойство, иметь значение),
•    причинно-следственные (если-то)
•    количественные (больше, меньше, равно...),
•    пространственные (далеко от , близко от, за, под, над),
•    временные (раньше, позже, в течение...),
•    логические  (и, или, не),
•    лингвистические (синонимия, антонимия) и др.

\subsection{Формализация}
Теория
Это тройка ℜ = {L, S, С}, где 
L – язык формальной модели с присущими ему синтаксисом, т.е. L = {T, G}, 
S – совокупность начальных знаний, сформулированных на языке L;  
C – абстрактная машина или машина вывода, которая, используя правила вывода P и определенную стратегию вывода, осуществляет формирование в  языке L новых знаний, начиная с начальных. 
Таким образом машина вывода является двойкой С = {P, Ω}, где Ω - стратегия вывода, согласно которой абстрактная машина C, используя правила вывода P осуществляет вывод. 
Правила вывода не обязательно являются правилами логического вывода, поскольку формальные модели могут быть не только логическими.

Язык
Формальный язык L в соответствии с современными представлениями требует рассмотрения двух его неотъемлемых частей: синтаксиса и семантики. 
Синтаксис языка описывает допустимые в языке предложения, состоящие из цепочек терминальных символов, принадлежащих определенному терминальному алфавиту. 
Синтаксис языка позволяет отличать предложения, принадлежащие языку, от предложений, ему не принадлежащих. 
Семантика языка определяет смысл предложений языка. 
Без семантики предложения языка являются ничего незначащими цепочками символов

Формализацией задачи будем называть создание для ее решения формальной модели.
Формальным решением задачи будем называть осуществление решения задачи с помощью формальной модели. 

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

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

Этапы формирования Онтологии
Определение цели и постановка задачи. На этом этапе особенно важно понять зачем нужна онтология, как и кем она будет использоваться.
Построение. Этот этап разбивается на три подэтапа: формализация понятий, кодирование и интеграция. 
Процесс формализации понятий: 1) выявление основных объектов и отношений предметной области, 2) текстовое описание этих объектов и отношений, 3) сопоставление этим объектам и отношениям термов.
Процесс кодирования в каком-либо формальном языке результатов предыдущего подэтапа. Обычно кодирование включает 1) описание с использованием введенных термов необходимых утверждений, 2) выбор формального языка для кодирования, 3) кодирование в выбранном языке. 
Процесс интеграции выполняется параллельно двум упомянутым и требует тщательного обдумывания, каким образом вновь создаваемая онтология будет интегрироваться с уже существующими.
Оценка. На этом этапе осуществляется обдумывание и формирование вопросов, на которые онтология должна давать ответы, выбирается программная среда для реализации онтологии.
Документирование. На этом этапе осуществляется тщательное составление руководства к онтологии на естественном языке.

\section{Методологии разработки мультиагентных систем}
методологии рмас сравнительно новая область
терминология не всегда однозначна, первоисточник в английском
поведение формируется описанием не действий, но целями
достижение связано с рассуждениями и планированием

интеллектуальное поведение
каждый агент способен на своё собственное ип, вместе достигая цели.
разработчику не нужно описывать поведение

инструментальные средства развиваются с конца 20в.

\begin{itemize}
\item Методология Gaia
  Гайя это некая энергетическая всеобъемлющая сущность. система имеет микро и макро уровни, но минус в том, что она не развивалась. два этапа - выделение роли и налаживание взаимодействия

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

\item Методология MaSE
  формирование целей
  разработка сценариев

\item Методология UML
  используется для моделирования базового уровня агентных систем
  Диаграммы архитектуры, ролей и протоколов, онтологий.
  сложностью считается сложность точного описания модели на языке.

\item Методология, основанная на графовых представлениях
  компоненты, сообщения. каналы связи. недостатком является чрезмерная вычислительная затрата на обработку графа.
\end{itemize}

\subsection{Тенденции}
\begin{enumerate}
\item концептуализация
\item структуризация
\item бихевиоризация
\item формализация
\item реализация
\end{enumerate}

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

Структуризация - определение ролей и моделируются компоненты системы

бихевиоризация - определение активности ролей, создаются взаимодействия объектов, диаграммы поведений и состояний.

на этапах формализации и реализации - создаются или принимается решение об использовании исчислений, переход к программированию.

\section{Онтологизация}
Онтология - часто общепринятое и общедоступное, однозначно понимаемое описание знаний на естественном или частично формализованном языке. Создаются для уменьшения путаницы и неоднозначности. Используют декларативные языки, например OWL. Большинство логик для описания декларативных знаний могут быть переведены в логику предикатов первого порядка. В каждом случае разрабатывают свой метод рассуждений. Помимо самого языка нас всегда интересуют исчисления (язык, знания, правила рассуждения). Для описания используются Т-бокс и А-бокс. Термины, ограничения. Высказывания, утверждения.

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

\subsection{Доказательства}
помимо обычных логик (модус поненс, дедукция, абдукция, итд) есть метод табло, в котором в процессе описываются секвенты, объединяющиеся в табло. Годится для доказательства в любых декларативных системах.

\section{Извлечение знаний в языке нитей}
интеллектуальное поведение может быть представлено без явного использования символического представления, предлагаемого ИИ.
ИП может быть реализовано без явного абстрактного вывода (рассуждения) того типа, которое предлагает символическое представление ИИ.

КА - это множеств входов, множество выходов, множество состояний и функции перехода и выхода.

ИП  - это процесс непрерывного анализа (восприятия) и отображения его в реакцию (выходное действие). Пара вход(анализ) реакция(выход) то есть кортеж действий называются нитями. выполнение нити - это порядок действий. Агент определяется множеством нитей. Процесс выполнения агентом нити - это поведение.

Множество пар входных и выходных действий должно удовлетворять:
\begin{itemize}
\item для любой нити из множества S начало такой нити также должно принадлежать множеству S.
\item если нити одинаковые, то реакции на них также должны быть одинаковые
\item нити находятся в отношении R, если нити удовлетворяют первым двум пунктам.
\end{itemize}

Процессные выражения нитей возможно представить в виде графа переходов (автоматы Мура). Отношение R разбивает множество нитей на классы эквивалентности.

Любые две нити восприятия находятся в отношении R если реакции на эти нити одинаковы и обе они принадлежат множеству S.

\section{Извлечение знаний в языке процессных графов переходов}
Стратегии поиска (на графах возможно осуществлять поиск). Оценить стратегию возможно по некоторым критериям (время, сложность, итд.)

Слепой и направленный поиск. Самый простой - это слепой поиск в ширину. Возможен также монотонный поиск в ширину.

Поиск в глубину, итеративный поиск в глубину. У поисков в глубину нет полноты.

Все стратегии слепого поиска экспоненциальны по сложности, поэтому нужно вводить критерий выбора

двунаправленный поиск.


\newpage
\appendix
\setcounter{secnumdepth}{2}
\setcounter{tocdepth}{2}
\section*{Приложения}
\addcontentsline{toc}{section}{Приложения}
\renewcommand{\thesubsection}{\Asbuk{subsection}}
\subsection{Семинар 1 (2022-09-06)}
что-то тут точно было

\subsection{Литература}
Батоврин В. К. Толковый словарь по системной и программной инженерии. — М.:ДМК Пресс.— 2012 г. — 280 с. ISBN 978 -5-94074 94074-818 -2
Лоусон , Гарольд «Бад». Путешествие по системному ландшафту / Пер. с англ. В. Батоврин . — М.: ДМК Пресс — 2013. ISBN 978-5-94074-923-3
Косяков А., Свит У., Сеймур С., Бимер С. Системная инженерия. Принципы и практика / Пер. с англ. В. Батоврин. — М.: ДМК Пресс, 2014. — 636 с.
Шамие Кетлин. Системная инженерия для «чайников»: ограниченная серия от IBM. — John Wiley \& Sons, Inc., 2014. — 69 с. (NB! Скачивается официально)

На английском
-    INCOSE (International Council on Systems Engineering) http://www.incose.org
-    The Guide to the Systems Engineering Body of Knowledge (SEBoK) http://www.sebokwiki.org
На русском языке
-    Systems Engineering Thinking Wiki http://sewiki.ru
-    Российское отделение INCOSE http://incose-ru.liveiournal.com
-    А. И. Левенчук , президент/директор по исследованиям Российского отделения INCosE http://ailev.liveiournal.com
-    А. И. Левенчук . Системноинженерное мышление http://techinvestlab.ru/files/systems engineering thinking/thin king 2015.pdf
-    В. Мизгулин. Системная инженерия требований http://urse.ru/wp-content/uploads/2017/02/Системная-инженерия-требований.pdf

\subsection{Альфа}
abstract level progress health attribute
всего Альф 8.
\begin{frm}
  Альфа - это некоторый элемент, который требуется для отслеживания успешности системы.\end{frm}
Альф помогает отслеживать

\begin{itemize}
\item альфа стейкхолдеров - это некоторые роли в нашем проекте. лица, чьи действия могут влиять на успешность системы. именно с ними нужно согласовывать требования к системе.
  \begin{itemize}
  \item внешние - заказчик или пользователи
  \item внутренние - разработчики системы
  \end{itemize}
  для анализа стейкхолдеров понадобится их определить, то есть явно в проект не будет входить бухгалетрия и юридический отдел. Будет по большей части влиять на успешность проекта в целом. Выделение механизмов вовлечения стейкхолдеров в проект (4 стратегии - полноценное партнёрство, временная консультация, поддержка, временные работники.) анкета и луковая диаграмма
\item возможностей зависит от временн\'{о}го интервала и показывает всё, что возможно сделать с системой.
\item определения системы - воплощение системы, архитектурное и неархитектурное описание, требоваиня ТЗ. финансовая группа может формировать баланс и отчётность
\item воплощения системы - 4д модели всей системы, изготовление отдельных частей, сборка, верификация и валидация
\item альфа команды - сотрудничество между людьми с определёнными компетенциями.
\item альфа работы - системы отслеживания задач
\item альфа технологий - практика на рабочих продуктах, раскладывается как в жизненных циклах.
\end{itemize}
все альфы можно описать на схеме OMG Essence.
\end{document}