- •1. Работа с требованиями при создании систем по стандарту гост 34.601, 602.
- •Более подробно про каждый этап
- •Более подробно про каждый подраздел
- •2. Работа с требованиями при создании систем по стандарту iso/iec/ieee 29148.
- •3. Преобразование потребностей в требования согласно Райану (Ryan, 2013).
- •4. Диаграмма «сущность-связь», описывающая концептуальную схему требований (Ryan and Wheatcraft, 2016).
- •5. Работа с требованиями в V-образной модели жизненного цикла системы.
- •6. Свойства, правила и атрибуты для формулировок требований согласно Руководству по написанию требований incose.
- •7. Свойства, правила и атрибуты для формулировок требований согласно iso/iec/ieee 29148. [Условие] [Субъект] [Действие] [Объект] [Ограничение]
- •[Условие] [Действие или Ограничение] [Значение]
- •[Субъект] [Действие] [Значение]
- •8. Способы документирования требований. Привести пример требования, задокументированного по каждому из способов.
- •9. Взаимосвязь между пользовательскими историями (User Stories), вариантами и сценариями использования (uCs) и спецификацией требований.
- •10. Методы выявления и ранжирования заинтересованных сторон. Выявление потребностей (нужд) заинтересованных сторон. Виды потребностей. Выявление требований заинтересованных сторон. Виды требований.
- •11. Типовой процесс для инженерии требований. Разработка систем. Контекст типового процесса и его информационная модель. Типовой процесс инженерии требований
- •Основные положения типовых процессов разработки требований
- •Разработка системы
- •Процесс разработки системы
- •Информационная модель тпрт
- •12. Входящие и производные требования. Разработка требований в контексте изменений.
- •Определение исходных и производных требований в контексте изменения в типовом процессе
- •Разработка требований в контексте изменений
- •13. Методы моделирования для разработки требований. Диаграммы потоков данных. Диаграммы «сущность-связь». Диаграммы состояний.
- •14. Объектно-ориентированные подходы к управлению требованиями.
- •Диаграммы классов
- •Варианты использования (use cases)
- •15. Описание и проверка требований. Ключевые требования. Использование атрибутов. Обеспечение непротиворечивости требований.
- •16. Структурирование документов, содержащих требования. Критерии для написания текста требований. Связанность и согласованность требований.
- •17. Определение области проблем. Согласование требований с заинтересованными сторонами.
- •18. Определение заинтересованных сторон. Разработка сценариев использования. Определение границ системы. Сбор требований.
- •19. Определение стратегии проверки соответствия. Определение критериев приемки и проверки.
- •20. Инженерия требований в области решений. Получение системных требований из пользовательских. Область решений
- •Получение системных требований из пользовательских
- •21. Разработка архитектурной модели системы.
- •22. Прослеживаемость требований. Простая прослеживаемость. Доказательство выполнения требований. Привязка требований.
- •23. Трассировка требований. Проектная документация. Элементарные связи. Анализ расширенных связей. Параметры анализа связей. Трассировка требований.
- •24. Управленческие аспекты инженерии требований.
- •Контроль за ходом выполнения работ
- •Изменения
- •25. Проблемы управления процессом разработки требований. Планирование. Контроль за ходом выполнения работ. Изменения.
- •26. Что такое верификация и валидация? Основные методы верификации и валидации.
- •27. Понятие системы через способности (capabilities), эмерджентность, процессы управления (Command and Control, c2), показатели результативности, операционную среду.
- •28. Понятия миссии, цели, способности (capability), функции системы.
- •29. Понятия efficacy, efficiency, effectiveness. С примерами количественных оценок.
- •30. Многослойное мышление (Why? What? How? Надсистема, система, подсистемы). Примеры с разными наблюдателями.
- •31. Системы уровня предприятия, инженерные системы, интересующие системы, системы обеспечения, операционное окружение. Графическое изображение циклов управления.
- •32. Системы уровня предприятия, инженерные системы, интересующие системы, системы обеспечения, операционное окружение. Производственный цикл интересующей системы.
- •33. Системы уровня предприятия, инженерные системы, интересующие системы, системы обеспечения, операционное окружение. Архитектурное представление.
- •34. Система целевого назначения/производственная система/проект (Mission System, Producer) и система обеспечения (Enabling System, Supplier). Принцип двойной роли. Примеры.
- •35. Иерархия показателей результативности moe, mop, mos. Что такое эффективность, результативность (Performance), пригодность (Sutability). Примеры.
- •Тут выше что-то было, пусть будет
33. Системы уровня предприятия, инженерные системы, интересующие системы, системы обеспечения, операционное окружение. Архитектурное представление.
Первую часть вопроса смотри вопрос 31.
Левая часть – логическая схема предприятия.
Правая часть – физическая схема предприятия. Схема операционного окружения интересующей системы, представляющая то же самое предприятие.
Induced Systems Environment – совокупность индуцированных (побочных) эффектов от взаимодействия систем.
Natural Systems Environment – обычная физическая среда функционирования систем.
Mission System – производящая система (система, выполняющая функции по превращению материалов в целевой продукт)
Интересующая система
Facilities – здания, сооружения – часть системы обеспечения, производственный процесс осуществляется внутри них, при их использовании. Напр., склад. Процесс происходит внутри склада. Но сам склад не участвует в производственном процессе.
Каждое предприятие и инженерная система SOI — подразделения, отделы, подсистемы, модули, подмодули, составные части – обеспечивают возможности для производства продуктов с добавочной ценностью, которые требуются для пользовательских систем интересов (SOI).
34. Система целевого назначения/производственная система/проект (Mission System, Producer) и система обеспечения (Enabling System, Supplier). Принцип двойной роли. Примеры.
Каждая система, продукт или услуга выполняют две роли, связанные с контекстом: роль системы целевого назначения (Mission System, Producer) и роль системы обеспечения (Enabling System, Supplier). • Системы, созданные человеком— Предприятия и инженерные системы — состоят из интегрированных цепочек поставок систем, в которых предприятие производит системы, продукты или услуги для поддержки другой системы, находящейся ниже по цепочке.
Челнок как система целевого назначения (Mission System): 1. многоразовая доставка продуктов, техники, экипажа на космические станции; 2. доставка спутников на орбиту • Челнок как система обеспечения (Enabling System): 1. обеспечение жизнедеятельности МКС (система целевого назначения – МКС с экипажем); 2. обеспечение спутниковой связи (система целевого назначения – развертывания спутниковой связи); обеспечение научной деятельность (система целевого назначения – организации ученых с постановкой конкретных задач)
В качестве системы целевого назначения (Producer Role), космический челнок NASA выполняет в космосе операции для достижения следующих показателей миссии — размещение спутников; проведение миссий по научным экспериментам; перевозка астронавтов, еды, припасов, отходов, соответственно к и от Международной космической станции.
Enabling System (Supplier Role) Principle • В качестве роли системы обеспечения (Supplier Role), каждая система поставляет продукты и услуги для удовлетворения потребностей и обеспечения пригодности к использованию стандартов для своих заинтересованных сторон – пользователей и конечных пользователей – выполняющих, соответственно, свои роли Mission System. • Системы обеспечения — предприятия и инженерные системы — подтверждают, что операции пользователей годятся для выполнения миссии.
35. Иерархия показателей результативности moe, mop, mos. Что такое эффективность, результативность (Performance), пригодность (Sutability). Примеры.
Эффективность (Википедия) - Достижение определённых результатов с минимально возможными издержками или получение максимально возможного объёма продукции из данного количества ресурсов.
Результативность (Википедия) – степень достижения поставленных целей (запланированных результатов). Чем точнее достигается поставленная цель, тем лучше результативность.Отношение фактического результата к плановому.
Пригодность (Википедия) – качественное соответствие определенным требованиям.
Нужно озаботиться еще одним вопросом : Какая взаимосвязь между MOS и MOEs ? Т.к. MOE является метрикой, характеризующей системную operational effectiveness для достижения показателей миссии , очевидно что operational suitability оказывает влияние на это достижение .
Поэтому MOS является способствующим performance effector (регулятор эффективности деятельности) для одного или более MOEs
Как объективный фактор , system effectiveness представляет физическую надежность выходной производительности и результатов. System effectiveness требует понимания
сопутствующих факторов, таких как надежность, сопровождаемость и производительность
Outcome based performance и результаты появляются в двух основных формах : планируемая ( planned ) и фактическая actual performance. Когда разработка системы стартовала , разработчик зависим от анализа, статических и имитационных моделей для выявления того, как система предполагает работать . Данные используются для:
Ограничить, определить и смоделировать производительность системы или одного из ее компонентов.
Сравнить фактическую и запланированную производительность
или ожидаемые результаты
Для валидации моделей и эффективности симуляторов применяются различные техники, такие как быстрое прототипирование , прототипы апробации концепции , демонстрации технологий.
Это нужно для сбора объективных эмпирических доказательств на ранней стадии для достижения уровня уверенности в том, что система или ее части будут работать как от них ожидалось . Окончательным результатом является верификация и валидация предсказаний эффективности системы.
Когда система или продукт готовы для тестирования в боевых условиях , собираются фактические данные по производительности, чтобы:
Верифицировать выполнение требований
Валидировать модели системы или продукта
36. Принцип Mission Statement, принцип Mission Objectives, Принцип Mission Operating Constraints, Принцип Mission Reliability, принцип User Mission Profile, принцип Mission Phases of Operation.
Выражение миссии (mission statement) должно задавать один и только один выходной результат, который необходимо достигнуть и который определяется одним или несколькими показателями выполнения (performance-based objectives).
Принцип Mission Objectives - Каждая миссия должна быть ограничена и определена одним или несколькими показателями выполнения (performance-based objectives).
