Ландшафт системной инженерии. Появление системной инженерии. Научно-методические основы системной инженерии. Объекты и субъекты системной инженерии. Место системного подхода. Методы моделирования систем. Архитектурный подход. Проектный подход. Ситуационный анализ. Обзор методов ситуационного анализа.

Ландшафт системной Инженерии Появление системной инженерии Причины • Рост масштабов и усложнение способов организации человеческой деятельности по созданию систем, повышение степени ответственности за её результаты, быстрое возрастание сложности возникающих при этом научных, технических и управленческих проблем привели к появлению в середине ХХ века новой прикладной системной методологии – системной инженерии Пример сложных систем • Основной проблемой системной инженерии была и остается сложность создаваемых систем Сложные системы (2) Сложность можно рассматривать с точки зрения: – Объекта разработки (структурная, физическая сложность); – Процесса разработки (деятельностная сложность) – Процесса функционирования (деятельностная сложность) Управленческий и системноинженерный подходы соприкасаются в части работы с деятельностной сложностью. За структурную сложность ответственен системный инженер. Методология для системной инженерии А.Холла В 1965 году А. Холл впервые описал методологию системной инженерии, определив её, как организованную творческую технологию и выделив в качестве основы системной инженерии три положения: 1. Системная инженерия многоаспектна, и этот факт должен быть обязательно отражен при определении её предмета. 2. В основу деятельности системного инженера должно быть положено понимание, что целью всего процесса системной инженерии является оптимальное проведение функциональных границ между человеческими интересами, системой и её окружением. В самом же окружении выделяются три главных составных части: – Физическое и техническое окружение – Деловое и экономическое окружение – Социальное окружение 3. Системная инженерия уделяет первостепенное внимание исследованию потребностей, в основе которого должно лежать использование передовых экономических теорий, учет потребностей рынка и возможность изменения этих потребностей как сейчас, так и в будущем Что такое системная инженерия? • В соответствии с определением стандарта ISO/IEC/IEEE 24765:2010 “Systems and software engineering – Vocabulary” • Системная инженерия – междисциплинарный подход, определяющий полный набор технических и управленческих усилий, которые требуются для того, чтобы преобразовать совокупность потребностей и ожиданий заинтересованных сторон и имеющихся ограничений в эффективные решения и поддержать эти решения на протяжении их жизни Что дает системная инженерия? Минимизация превышения затрат на проект и задержки сроков выполнения проекта Подходы СИ • Являясь междисциплинарной методологией, системная инженерия предполагает комплексное применение основных подходов к созданию сложных систем: системного, интеграционного, подхода жизненного цикла (ЖЦ), процессного подхода Стадии ЖЦ системы Научно-методические основы системной инженерии Книги и периодические издания • В мире ежегодно издаются десятки книг и журналов по системной инженерии, проводятся многочисленные международные конференции • Ведущие интеграторы: – Institute of Electrical and Electronics Engineers (IEEE) – International Council on Systems Engineering (INCOSE) Нормативные основы системной инженерии • Разработкой стандартов и других нормативных документов в области системной инженерии заняты официальные организации стандартизации и некоммерческие консорциумы • Ключевую роль играет Объединенный технический комитет 1 ИСО и МЭК (JTC1/ISO/IEC), седьмым подкомитетом (SC7) которого разработано несколько десятков стандартов системной и программной инженерии • Среди неофициальных организаций, занятых формированием нормативных основ системной инженерии, выделяются: – Институт инженеров электротехники и электроники (The Institute of Electrical and Electronics Engineer – IEEE) – Группа по управлению объектами (The Object Management Group – OMG) – Международный совет по системной инженерии (International Council on Systems Engineering – INCOSE) – Альянс предприятий электронной индустрии (Electronic Industries Alliance – EIA) Объекты и субъекты системной Инженерии Роль системного инженера в проекте • Именно системные инженеры прокладывают курс программе разработки, в которой четко определены виды и сроки проведения испытаний и имитационного моделирования. За ними остается последнее слово в решении вопроса о том, как обеспечить нужные функциональные возможности системы по приемлемой цене. • Когда в ходе разработки возникают неожиданные проблемы – а это неизбежно, – именно системные инженеры решают, как с ними справиться. Они определяют, понадобится ли для устранения проблемы совершенно новый подход или достаточно привлечь больше сил; следует ли для компенсации трудностей внести изменения в какую-то, возможно находящуюся за пределами непосредственного рассмотрения, часть системы или лучше смягчить требования, из-за которых проблема возникла. • Системный инженер приобретает способность управлять разработкой системы не потому, что занимает свою должность, а благодаря превосходному знанию системы в целом, ее назначения, особенностей работы ее частей, а также всех технических факторов, подлежащих учету при разработке. Он приобретает эту возможность еще и потому, что сумел на практике доказать свое умение проводить сложные программы сквозь лабиринт трудностей к успешному финалу. Системы, нуждающиеся в СИ • Система не отвечает понятию «сложности», если технология ее создания устоялась (современные бытовые приборы). СИ для создания такой системы не нужна. • Система, для которой необходима СИ, характеризуется следующими признаками: – инженерная насыщенность 2 изделия и, как следствие, возможность удовлетворения на этой основе определенной потребности; – гетерогенность, то есть система состоит из разнотипных, разнородных компонентов с нетривиальными взаимосвязями и, как следствие, ее создание ведется с использованием мультидисциплинарного подхода, а сама система относительно сложна; – использование передовых технологий так, что именно эти технологии жизненно необходимы для достижения важнейших функциональных возможностей системы и, как следствие, ее создание сопряжено с риском и зачастую обходится относительно дорого. Место системного подхода Системы и закономерности их функционирования и развития 26 • Определение систем, понятия стейкхолдеров, целей, задач, системы, элементов, связей и т.д. • Системы и среда • Структура и процессы, развитие систем, жизненный цикл систем • Иерархия и декомпозиция • Классификация систем (по виду отображаемого объекта, по научному направлению, по сложности, организованности и т.д.) • Закономерности систем (целостность или эмерджентность, систематизация, аддитивность, иерархичность, самоорганизация и т.д.) Методы и модели теории систем и системного анализа • Проблема принятия решений • Подходы к анализу и проектированию систем • Методы моделирования систем • Системный подход в инженерной деятельности • Архитектурный и проектный подходы • Процессный подход Методы формализованного представления систем • Аналитические методы • Статистические методы • Теоретико-множественные представления • Логические методы, или математическая логика • Лингвистические и семиотические представления, или математическая лингвистика и семиотика • Графические представления • Экономико-математические методы представления систем и другие прикладные классификации Методы моделирования систем Методы выработки коллективных решений • Сценарии, мозговые штурмы • Дерево целей • STEP и SWOT анализ • Экспертные оценки. Ранжирование, парные сравнения. Согласование оценок • Методы организации сложных экспертиз. Метод «Дельфи». • Морфологические методы. Применение методов системного анализа при организации производства и управления предприятиями • Анализ целей и функций системы управления организацией • Разработка (корректировка) организационной структуры • Система нормативно-методического обеспечения управлением предприятия • Информационные модели производственных систем • Применение системного анализа при разработке автоматизированных информационных систем Архитектурный подход Проектный подход Проект как система • Границы • Окружение • Функциональная структура • Поведение • Морфология (Элементы, Связи) • Фазовое пространство • Время • Цели • Требования • Процессы и процедуры • Динамика • Области знаний • Модели • Критерии и измерители • Сетевой график Ситуационный анализ Обзор методов ситуационного анализа Подходы к инженерии и управлению требованиями в современной системной инженерии Стандарты и рекомендации Подходы к работе с требованиями на стадиях ЖЦ системы • На каждой стадии и этапах ЖЦ в рамках применения метода системной инженерии • Сквозным образом через все стадии ЖЦ Постадийный подход работы с требованиями • Объект управления – документ с требованиями • ТЗ (или другой документ) делается один раз и остается на своей стадии • Верификация по первоначальному ТЗ невозможна • Приемлемый подход либо при несложных системах, которые не являются частью комплексных систем, либо когда заказчик является конечным пользователем Сквозной подход работы с требованиями • Объект управления – как документ с требованиями, так и сами выражения требований. • ТЗ (или спецификацию) поддерживаем в актуальном состоянии на всех стадиях ЖЦ системы. • ТЗ - основной документ по которому происходит общение с заказчиком по поводу системы. • Программу испытаний делаем четко на основе ТЗ. • Приемлемый подход комплексных системах, где подсистемы исполняются различными поставщиками Корпоративные стандарты • ЕДИНЫЕ ОТРАСЛЕВЫЕ МЕТОДИЧЕСКИЕ УКАЗАНИЯ по формулированию, идентификации, оформлению и оценке качества требований в проектах сооружения АЭС • ЕДИНЫЙ ОТРАСЛЕВОЙ ПОРЯДОК управления требованиями на различных стадиях ЖЦ АЭС для проектов сооружения АЭС за рубежом • ЕДИНЫЙ ОТРАСЛЕВОЙ ПОРЯДОК управления требованиями на различных стадиях ЖЦ АЭС для проектов сооружения АЭС на территории Российской Федерации • ЕДИНЫЕ ОТРАСЛЕВЫЕ МЕТОДИЧЕСКИЕ УКАЗАНИЯ по управлению требованиями в проектах сооружения АЭС за рубежом на этапе предконтрактных работ Свойства хороших требований Свойства формулировок требований ● Необходимость ● Адекватность уровню ● Однозначность ● Полнота ● Простота ● Реализуемость ● Пригодность для верификации ● Соответствие потребности ● Соответствие нормам Что такое атрибуты требований Требование (запись требования) содержит: ● Формулировку требования и Атрибуты Требования Перечень атрибутов В “Руководстве по написанию требований INCOSE” 44 атрибута. В стандарте ISO 29148 - 8 атрибутов: ● Идентификатор ● Номер версии ● Владелец ● Приоритет ● Риск ● Обоснование ● Сложность ● Тип Значения атрибута “Приоритет” ● Числа: 1, 2, 3 ● Слова: ○ Низкий, средний, высокий. ○ MoSCoW: Must, Should, Could, Wouldn’t ● Kano Model ● QFD (Quality Function Deployment) Риск Риск - величина неопределенности, связанной с требованием. Источники риска: ● Требование не обладает желаемыми свойствами ● Реализуемость: ○ Техническая ○ Стоимость ○ Сроки ● Низкий уровень зрелости технологий Обоснование Атрибут “Обоснование” предназначен для указания причины, по которой требование существует. В нем следует пояснять, почему требование было записано и с какой целью. В «Обосновании» также допустимо указывать следующее: ● любые допущения, сделанные во время написания требования; ● работы по проектированию, приведшие к созданию требования; ● источник чисел в требовании. Ссылка на источник/на родительское требование Ссылка на источник - название документа, из которого “пришло” требование. Ссылка на родительское требование - идентификатор требования, на основе которого порождено данное. Вместе с “Обоснованием” позволяет обеспечить свойство “Необходимость”. Обеспечивает прослеживаемость. Сложность Сложность - насколько сложно реализовать данное требование. Примеры значений: ● Легко ● Средне ● Сложно Тип Тип - к какому типу/категории относится данное требование. Почему важно указывать: ● Процедуры работы с требованиями разных типов могут отличаться ● Позволяет сделать выборку требований конкретного типа Типы требований Возможные значения: ● Функциональное ● Характеристика ● Интерфейс ● Качество ● Ограничение ● Физические характеристики Способы документации требований • Use Stories • Use Cases (также уровни, понятие бизнес-Use Cases и т.п.) • Statements (шаблон для выражения треб через языковую конструкцию) Проблемы с документированием • Русскоязычные конструкции не соответствуют английским (Concern, View, Viewpoint). • Иностранцы думают этими словами, а для нас это птичий язык. Нет такой строгой формализации, как в языках программирования. Определение • Требованием является положение, задающее возможность или функцию, наличие которых необходимо в системе для удовлетворения нужд потребителей • Функциональное требование определяет каким образом, насколько хорошо и при каких условиях один или более входов должен быть преобразован в один или более выходов в заданных границах, чтобы удовлетворить нужды потребителей • Нужда потребителя может относиться к следующим типам «решить проблему», «достигнуть цели», «удовлетворить требованиям договора, стандарта или спецификации» Полезного понятия требования не существует Деятельность системного инженера в процессе принятия решений • Systems engineer documents: Problem Situation, Customer Requirements, Derived Requirements, Verification and Validation, Concept Exploration, Use Case Model, Design Model, Mappings and Management, Reviews • Cybernetic model of management, where the threshold requirement is a document quality value, which shows the current project state. • Depending on this value and taking into account the organizational strategy in system lifecycle management the decision is made Основные шаги анализа применения системы Анализ применения включает в себя следующие шаги: 1. Определение списка заинтересованных сторон, их проблем, потребностей и целей. 2. Определение возможностей применения системы. 3. Определение действий по применению системы. 4. Определение критериев достижения целей и ограничений применения системы. Применяемые подходы 53 • Функциональный анализ • Контекстное описание • Сценарии использования • Деревья целей • Ранжирование, взвешивание • Интервьюирование заинтересованных сторон • Моделирование ситуаций • Анализ документов • Обеспечение прослеживаемости Что такое воркшоп по требованиям A workshop is a specialised meeting, structured to bring exactly the right people together to solve a problem using a planned sequence of activities. Those people may be any stakeholders in the project, members of the development team or, if need be, external experts to assist with specific tasks. Workshop = Meeting+Purpose + Planned Activities Specific Workshop = Workshop+Element - specific Activities