 |
Профессия системного инженера
|
|
|
|
НИТУ «МИСиС»
Институт ИТАСУ
Кафедра инженерной кибернетики
Квалификация (степень): магистр
Направление подготовки: 230700 «Прикладная информатика»
Курс: «Системная инженерия»
ПРОГРАММА КУРСА
«СИСТЕМНАЯ ИНЖЕНЕРИЯ»
I семестр 2 курс
Лектор / Заманский Б. И. /
подпись должность, уч. степ., Фамилия И.О.
Г. Москва, 2016
СОДЕРЖАНИЕ
1. Содержание лекционного материала. 4
#Лекция №1 (2 часа) 4
1.1. Введение в системную инженерию.. 4
1.1.1. Предмет системной инженерии. 4
1.1.2. Профессия системного инженера. 5
1.1.3. Инженерный проект. 6
1.1.4. Системный подход. 7
1.2. Воплощение системы.. 8
#Лекция №2 (2 часа) 9
1.3. Определение системы.. 9
1.3.1. Описание системы.. 9
1.3.2. Требования к системе. 10
1.3.3. Архитектура системы.. 11
1.3.4. Неархитектурная часть проекта. 12
1.4. Жизненный цикл системы.. 12
1.4.1. Определение жизненного цикла. 12
#Лекция №3 (2 часа) 13
1.4.2. Управление жизненным циклом.. 13
1.4.3. Практики жизненного цикла. 15
1.4.4. Стили разработки «водопад» и «agile». 17
1.4.5. Диаграмма основного жизненного цикла. 21
1.4.6. Практики жизненного цикла по ISO 15288. 21
1.5. Методы управления проектами Scrum и Kanban. 23
1.5.1. Принципы Scrum.. 23
1.5.2. Внедрение метода Scrum в организации. 28
1.5.3. Сходства и отличия Scrum и Kanban. 29
1.6. Практика контрольных вопросов. 30
1.6.1. Чеклисты и их место в ходе жизненного цикла. 30
1.6.2. Контрольные вопросы к испостасям инженерного проекта. 32
#Лекция №4 (2 часа) 35
1.7. Инженерия предприятия. 35
1.7.1. Виды дисциплин инженерии предприятий. 35
1.7.2. Сущности предпринятия. 36
1.7.3. Архитектура предпринятия. 39
1.7.4. Матрица Захмана. 40
1.7.5. Бизнес-архитектура. 41
1.7.6. Органиграмма предприятия. 41
1.7.7. Управляющие и информационные связи. 42
|
|
|
1.7.8. Системный подход в архитектуре предпринятий. 43
1.7.9. Стратегический план организации. 43
1.8. Управление операциями. 44
1.8.1. Основы операционного управления. 44
#Лекция №5 (2 часа) 45
1.8.2. Проектное управление. 45
1.8.3. Управление процессами. 46
1.8.4. Ведение дел. 46
1.8.5. Отличия управления проектами и жизненным циклом.. 47
1.8.6. Управление знаниями, НСИ, данными. 48
2. Тематика, объемы и виды работ. 50
2.1. Объем курса по видам работ. 50
2.2. Разделы курса. 50
2.3. Содержание по темам и видам занятий. 51
2.4. Проведение лабораторных занятий. 53
2.5. Задания на самостоятельные работы.. 53
3. Экзаменационные задания. 55
3.1. Теоретические вопросы.. 55
3.2. Экзаменационные задачи. 55
3.3. Содержание экзаменационных билетов. 56
4. Список литературы.. 58
5. Список иллюстраций. 59
6. Список таблиц. 60
Содержание лекционного материала
#Лекция №1 (2 часа)
Введение в системную инженерию
Предмет системной инженерии
Системная инженерия – это междисциплинарный подход и способы обеспечения воплощения успешной системы.
· «Успешная» - система должна удовлетворить нужды стейкхолдеров (те, кого затрагивает система или кто затрагивает систему: заказчики, пользователи и т.д.).
· «Система» - слово из системного подхода. Автоматически влечет за собой разговор про стейкхолдеров, их интересы и требования, архитектуру, жизненный цикл и т.п.
· «Междисциплинарный» - системная инженерия претендует на работу с другими специальностями, прежде всего – инженерными.
· «Подход» - наработки в одной предметной области, которые можно перенести на другие предметные области.
· «Воплощение» - создание материальной успешной системы.
Системноинженерное мышление - это использование системного подхода в инженерии.
Англоязычный термин systems engineering (раньше было system engineering) – перевод именно как «системная инженерия», а не «инженерия систем». Т.е., подразумевается именно системный подход, а не объект для солидности обзывается «системой».
|
|
|
Более длинное определение системной инженерии включает еще одну фразу: «…Она фокусируется на целостном и одновременном/параллельном понимании нужд стейкхолдеров; исследовании возможностей; документировании требований; и синтезировании, проверке, приёмке и постепенном появлении инженерных решений, в то время как в расчёт принимается полная проблема, от исследования концепции системы до вывода системы из эксплуатации».
Системная инженерия предполагает параллельность выполнения самых разных практик, а не их последовательность.
Системные инженеры (в отличие от других инженеров) отвечают за весь проект целиком сразу во всех его деталях.
Системная инженерия нужна, чтобы победить сложность. Инженерная сложность определяется как число различных элементов, взаимодействие которых должно обеспечить воплощение целевой системы.
Основная задача системной инженерии – снизить зависимость разработки от наличия «гениев», дать в руки обычных людей инструмент для решения задач высокой сложности.
Профессия системного инженера
Системный инженер – инженер, отвечающий за успешность системы в целом. Это – технический лидер в инженерном коллективе. Аналог термина «системный инженер» - «инженер-конструктор», главный системный инженер часто называется «главный (генеральный) конструктор».
Наиболее значимая профессиональная организация системных инженеров - INCOSE (International Counsil of Systems Engineering, http://incose.org).
Классификация системных инженеров по интересам в системной инженерии (автор – технический директор INCOSE Билл Миллер):
· Технические практики всего жизненного цикла (работа с требованиями, архитектурой, проверкой и приёмкой, и т.д.)
· Системноинженерный менеджмент, который тоже озабочен практиками, только практики о другом (управление конфигурацией, управление информацией, и т.д.).
· Моделеориентированная системная инженерия, которая пытается трансформировать практику использования неявных (и часто запертых в сером веществе инженеров) описательных и вторичных по отношению к спецификациям моделей в практику использования явных первичных и богатых выразительными возможностями моделей.
|
|
|
· Нетрадиционные промышленные экосистемы (то есть за пределами аэрокосмической инженерии), часто включают и «местные» практики.
· «Мягкие системы» системное мышление и системная наука, которые имеют дело со сложными, вероятностными или недетерминистскими системами.
· Системноинженерое лидерство, заинтересовано объединить практики всех остальных и катализировать их дружную совместную работу.
Цели INCOSE - распространять знания по системной инженерии, обеспечивать международное сотрудничество и обмен опытом системных инженеров, устанавливать стандарты профессионального мастерства и проводить сертификацию системных инженеров на соответствие этим стандартам, обеспечивать поддержку корпоративных и правительственных образовательных программ в области системной инженерии.
Начиная с советского времени и до сих пор, генеральный или главный конструктор часто совмещает конструкторскую и административную деятельности. Это противоречит системному подходу и предъявляет сверхвысокие требования к главному конструктору. Во главе любого подразделения или проекта должны стоять «две головы», одна из которых занимается административной деятельностью (главная компетенция – работа с людьми и ресурсами), а другая – принятием конструктивных и инженерных решений, определением используемых технологий и проектированием архитектуры системы.
Менеджменты, связанные с инженерией:
· Инженерный менеджмент, в основе которого лежит операционный менеджмент (исследования операций, логистика, проектное и процессное управление)
· Технологический менеджмент, можно перевести и как «технологичный менеджмент» и «менеджмент технологий» в зависимости от проставляемого акцента) — cтратегирование (предпринимательство, инновации) и маркетинг (продажи). Сюда же часто относят работу CTO и CIO.
· Системноинженерный менеджмент или в российской традиции «управление жизненным циклом»: часть системной инженерии, обеспечивающая целостность и преемственность в выполнении всех необходимых работ по мере того, как система проходит стадии замысла, проектирования, воплощения в жизнь, использования и вывода из эксплуатации.
|
|
|
Важная часть работы системного инженера – управление рисками.
Инженерный проект
На рисунке 1.1.1 приведена диаграмма инженерного проекта. На ней определены основные компоненты и связи проекта. По сути это – диаграмма основ системной инженерии.
1.1.1 Диаграмма инженерного проекта
По схеме инженерного проекта мы обсуждаем:
· О чём в проекте нельзя забывать?
· Где границы инженерного проекта, отделяющие его от других проектов?
· Кто в проекте за что ответственен?
· Какие максимальные риски, которые на себя может взять команда и её отдельные члены?
· В каком состоянии сейчас проект, что уже сделано, и что нужно ещё сделать для получения успешной системы?
· … многое другое, ибо эта диаграмма отражает основные изменяющиеся в ходе проекта сущности и основные связи этих сущностей.
Дисциплины (области интереса) проекта:
· Технологический менеджмент, упор на маркетинг/стратегирование.
· Инженерия.
· Инженерный менеджмент, упор на операционный менеджмент и лидерство.
Практика - это описание того, как справиться с каким-то отдельным аспектом (но не всеми!) дисциплин инженерного проекта.
Метод - это сочетание дисциплины и набора практик для достижения какой-то цели. В инженерии бывают методы разработки, методы сопровождения, методы интеграции систем, методы проведения испытаний, в операционном менеджменте бывают методы управления проектами, методы обеспечения цепочки поставок и т.д.
Цель метода должна быть сформулирована отдельно как короткое предложение, к ней возможны дополнительные описания. Эта цель должна учитывать нужды стейкхолдеров, условия ситуации и желаемую целевую систему.
Метод содержит дисциплину и набор практик, чтобы выразить технологию работы команды для достижения цели метода.
Системный подход
«Подход» - это когда разработанные в рамках одной дисциплины приёмы работы (в том числе приёмы мышления) переносят в какие-то другие области.
Системный подход - это когда наработанное где-то (в данном случае уже неважно где) системное мышление переносится в другие дисциплины - например, в (системную) инженерию.
Системный подход с его вниманием не только к частям, но и целому (холизм) противопоставляется прежде всего редукционистскому подходу. В редукционистском подходе (часто неявно) утверждается, что мы должны дать детальное «научное» (то есть в рамках определённого научного предмета) описание любого объекта, просто повышая уровень его детальности при любых встречающихся затруднениях, сводя изучение целого к изучению его отдельных частей. Но почему представители системного мышления называют это «редукционистским» подходом? Потому как доктрина редукционизма полагала, что любое “высшее проявление” можно свести к «низшему, в частях системы», если постараться.
|
|
|
Системный подход, в отличие от редукционистского утверждает, что «сводимости» одних дисциплин к другим нет, мир нужно описывать мультидисциплинарно, «полинаучно».
Системный подход сразу оговаривает многодисциплинарность (в отличие от монодисциплинарности редукционистского подхода – «наша дисциплина объяснит всё многообразие явлений») рассмотрения системы.
Системное мышление - это приложение системного подхода к решению практических задач. Так, системная инженерия - это приложение системного подхода к решению инженерных задач.
Варианты слова «система»:
· Структурное образование (разбиение часть-целое). Примеры: самолет, солнечная система, система охлаждения.
· Классификация (членство в классе элементов). Примеры: периодическая система химических элементов, система СИ, классификатор изделий и т.д.
· Набор практик и/или правил. Примеры: система Станиславского, политическая система.
Воплощение системы
Воплощение системы – сама система, состоящая из вещества и полей, т.е., ее материальная реализация.
При работе с воплощением необходимо получить ответ на вопросы:
· Что это за система? (черный ящик)
· Из чего состоит эта система? (прозрачный ящик)
Для разных стейкхолдеров система будет представляться в разных аспектах (ипостасях), но при этом оставаться целостной.
Система имеет минимально 3 ипостаси:
· Компоненты
· Модули
· Размещения
В каждой ипостаси система рассматривается как целое, состоящее из частей, и сама является частью целого.
Компоненты – ипостаси системы, в которых она выполняет какую-либо функцию. Компоненты имеют соединения между собой. Диаграмма, показывающая соединении компонент – принципиальная схема.
Модуль – физический объект, элемент конструкции. Он необходим для изготовления. Модули могут быть зависимы друг от друга. Функции модуля в системе не обсуждаются. Модули связываются друг с другом через интерфейсы. Модули взаимозаменяемы на своих интерфейсах.
Размещение – место, которое занимает система. Основное назначение – логистические аспекты.
Иерархия частей системы называется разбиением. Разбиений – множество (функциональные, работ, документов), они представляются графами. Иногда используется вариант «лесенкой», что также есть часть графа.
Старинные наборы стандартов часто определяли «жесткие» разбиения на фиксированное количество уровней с различными названиями. Например, ЕСКД – Единая Система Конструкторской Документации:
· Деталь — это изделие, выполненное из однородного материала без применения сборочных операций (например, болт, гайка, вал, втулка).
· Сборочная единица — изделие, составные части которого соединяются между собой в процессе сборки с помощью резьбы, пайки, сварки и т. п. (например, редуктор).
· Комплекс — два и более изделия, предназначенных для выполнения взаимосвязанных функций (например, технологическая линия).
· Комплект — это набор из двух и более изделий, имеющих общее эксплуатационное назначение вспомогательного характера (комплект запасных частей, комплект инструментов и принадлежностей).
Современные системы обозначений учитывают:
· Аспектность – различные ипостаси, не выпячивая отдельные: модульность или компонентность.
· Произвольность числа уровней системы.
#Лекция №2 (2 часа)
Определение системы
Определение системы – набор описаний, которые определяют систему перед ее воплощением. Основные ипостаси здесь:
· Требования (определение системы как черного ящика).
· Архитектура (инженерные решения, определяющие систему как «прозрачный ящик).
· Неархитектурная часть проекта (рабочие решения).
Проект системы есть совокупность архитектурных и неархитектурных частей.
Описание системы
Описания – рабочие продукты, выражающие определение системы.
Воплощение системы должно соответствовать описанию системы.
Группа описаний группирует отдельные описания, соответствующие определенному аспекту системы. Каждая группа описаний обязательно имеет стейкхолдера, заинтересованного в этой группе. Если нет стейкхолдера- описание никому не нужно. Если есть стейкхолдер, но нет описания для него – существует риск создания неуспешной системы.
Метод описания – методология, позволяющая создавать описания. Включает теорию)дисциплину), инструменты, форматы документов (модели данных, реквизиты документов, системы обозначений), методические указания по написанию (стайл гайд). Метод описания явно должен быть указан до начала составления описаний.
Обозначения описаний, как правило, состоят из имени системы в системной иерархии с добавлением имени описания.
Конфигурация системы – состояние системы в конкретный момент времени. Если конфигурация определения системы соответствует конфигурации воплощения системы, то конфигурация находится под контролем.
Контроль конфигурации обеспечивается тем, что конфигурация может быть собрана в любой момент. Для обеспечения контроля используется практика управления конфигурацией. Сейчас для этого используют системы управления версиями.
Важнейшие практики системной инженерии – практики проверки и приемки.
Проверка – проверка соответствия целевой системы какому-то описанию целевой системы (требованиям, архитектуре и т.д.).
Приемка – проверка на соответствие желаемому стейкхолдером описанию использующей системы, если в ее составе работает целевая система.
Практики описания системы включают в себя знания языка, нотаций, инструментов и т.д. Ни в коем случае при описании нельзя придумывать определения, только их описывать. Определения создаются в практиках инженерии, а практики описания создают рабочие продукты, описывающие создаваемую систему.
Требования к системе
В системной инженерии термин «требования» используется как определение системы в качестве «черного ящика», а не вообще в смысле «любые требования». Поэтому основными требованиями являются требования стейкхолдеров и системные требования, а все остальные «требования» не являются «требованиями» с точки зрения системной инженерии.
Требования жестко связаны с инженерными обоснованиями.
Рабочие продукты требований не всегда называются «требования». К ним относятся: разделы «технические требования» технических заданий, «опросные листы», стандарты, технические условия и т.п.
Требования стейкхолдеров – описания «черного ящика», которые создаются для разных стейкхолдеров. Они могут противоречить друг другу, соответствуя различным нуждам. Системный инженер должен задокументировать требования стейкхолдеров, а потом завизировать у них.
Конкретные инженерные решения, предлагаемые стейкхолдерами, не являются «требованиями», а являются ограничениями. Требования и ограничения надо отличать друг от друга. Требования должны быть удовлетворены, ограничения иногда можно отменять, согласуя это со стейкхолдерами. Ограничения могут носить нетехнический характер (политические, на базе предыдущего опыта и т.д.).
Системные требования – синтез требований стейкхолдеров в процессе системного анализа последних. Важно – не пропустить требования стейкхолдеров. Системные требования должны отвечать другим «требованиям»: непротиворечиувости, полноты, проверяемости и т.д.
Инженерия требований – поддисциплина системной инженерии. Главная часть инженерии требований — это реверс-инжиниринг использующей (над)системы (using system) для того, чтобы получить описания “чёрного ящика”. Инженеры по требованиям (это вид системных инженеров) выявляют стейкхолдеров, узнают их потребности, разрабатывают требования стейкхолдеров, проводят переговоры между стейкхолдерами в тех случаях, когда их требования противоречивы, или когда команда проекта оказывается не в состоянии их выполнить и требования нуждаются в коррекции, согласуют требования стейкхолдеров между собой, готовят требования к системе.
Управление требованиями – часть инженерного менеджмента, направленного на предоставление средств хранения требований и сообщения о ней нуждающимся.
Самые распространенные требования – функциональные. Это – описание поведения системы, они возникают из различных сценариев использования системы. Нефункциональные требования – надежность, ремонтопригодность, доступность, безопасность и т.д.
Общая логика разработки системных требований приведена на рисунке 1.3.1.
1.3.1 Разработка системных требований
Архитектура системы
Архитектура системы – набор структур, необходимых для определения системы, элементов структур, их отношений и свойств.
Архитектура – основные описания «прозрачного ящика». Они показывают, из каких частей состоит система, как эти части взаимодействуют между собой, как они реализуют функции «черного ящика».
Важно, какие именно типы структур документируются, какие принципы проектирования/конструирования документируются.
Архитектурные описания нужны, прежде всего, команде проекта для обсуждения проекта.
Практика создания системной архитектуры называется «инженерия системной архитектуры». Системный архитектор – одна из основных специализаций системных инженеров.
Минимальная архитектура состоит из трех наборов рабочих компонентов и моделей:
· Структуры компонент и соединений (логическая архитектура).
· Структуры модулей (физическая архитектура).
· Указаний на размещение частей системы в пространстве.
Архитектура должна показывать, как увязанные между собой рабочие наборы (описания) дают на выходе выполнение функций системы. Этим архитектура неразрывно связана с требованиями.
Архитектура субъективна и относительна. Ее «придумывают», а не «выявляют». Поэтому лучшей практикой принято считать рассмотрение вариантов («развилок»), которые потом оцениваются для выявления лучшего варианта. Эта практика отражена в ГОСТ 34. Стадия эскизного проектирования именно для этих целей и введена.
Четкой границы между архитектурными и неархитектурными решениями нет. Более того, неархитектурные решения в системе часто становятся архитектурными для ее частей. Ибо для архитектора «второго уровня» подсистема становится целевой системой.
Критерий точки, где системный инженер прекращает углубление: когда ему кажется, что уже нет важных решений, либо работа уже поделена между исполнителями – разработчиками модулей, и дальше идут уже их решения.
Есть два подхода к конструированию групп описаний из отдельных моделей (диаграмм, наборов формул и т.д.):
· Синтетический подход: являются отдельными моделями, но к ним добавляется список соответствующих друг другу элементов. Пример: отдельная таблица в базе данных для каждой модели.
· Прожекторный (проекторный) подход: вся информация о разных моделях хранится в общей базе данных, а отдельные модели получаются отфильтровыванием. Пример: одна таблица для всех элементов с отдельным столбцом, идентифицирующим модель.
В архитектурных описаниях сейчас принято использовать формализованные (понимаемые компьютером) модели. К ним добавляются архитектурные текстовые эссе и инфографика. Также в описания включают еще и обоснования, по которым приняты те или иные архитектурные решения. Тем самым, архитектурные описания – это документированные важные инженерные решения.
|
|
|
