- •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). Примеры.
- •Тут выше что-то было, пусть будет
30. Многослойное мышление (Why? What? How? Надсистема, система, подсистемы). Примеры с разными наблюдателями.
31. Системы уровня предприятия, инженерные системы, интересующие системы, системы обеспечения, операционное окружение. Графическое изображение циклов управления.
Я думаю, что можно эту часть вопроса можно описать только здесь, а в билетах 32 и 33 ссылаться сюда
Системы уровня предприятия (Enterprise Systems) — формальные и неформальные промышленные, академические, правительственные, профессиональные, некоммерческие организации, такие как корпорации, подразделения корпораций, функциональные подразделения – отделы (departments), напр., расчетный, инженерный отделы; проекты и т.д.
Инженерные системы (Engineered Systems) — физические системы или продукты, производимые для внутреннего использования, коммерческих продаж на рынке или по заказу (контракту), для чего требуется одна или более инженерных дисциплин и наборы навыков для применения математических и научных принципов для осуществления решений по проектированию и разработке.Инженерные системы, в основном, состоят из оснащения (equipment), которое включает аппаратную и/или программную часть, материальные потоки – fluids (lubricants, coolants, etc.), газообразные вещества и другие сущности: • Аппаратные сущности (Hardware entities), например, состоят из нескольких уровней вложенности, таких как Продукты→ Подсистемы→ Сборки (Assemblies) → Подсборки→ Части; • ПО (Software entities) включает в себя Computer Software Configuration Items (CSCIs) состоящие из → Computer Software Components (CSCs) → Computer Software Units (CSUs).
Инженерная система- это открытая система, которая состоит из технических и социо-технических элементов и предназначена для практических нужд.
SOI, как сущность исполнения, состоит из нескольких типов системных элементов (System Elements)—Personnel, Equipment, Mission Resources, Procedural Data, System Responses).
На протяжении выполнения целенаправленной деятельности интересующей системы — система целевого назначения (Mission System) или система обеспечения (Enabling System) — взаимодействуют с внешними системами в среде штатной эксплуатации/среде применения (Operating Environment). • Эти внешние системы могут включать в себя дружественные, благоприятные, враждебные, вредные, угрозы, столкновения, взаимодействия, условия окружающей среды, которые могут варьироваться от благоприятных до агрессивных.
Система обеспечения – система, которая служит дополнением к целевой системе на протяжении ее ЖЦ, но необязательно вносит непосредственный вклад в ее функционирование. – Система обеспечения может обеспечивать часть, например, стадию ЖЦ целевой системы, или полный ЖЦ. – В течение стадии ЖЦ целевую систему и системы обеспечения можно рассматривать, вследствие их высокой взаимозависимости, как одну систему. – Диапазон ответственности проекта для стадии ЖЦ целевой системы расширяется до ответственности за услуги, предоставляющие соответствующей системой обеспечения. – Если подходящей системы обеспечения не существует, проект, который отвечает за целевую систему, может также непосредственно отвечать за создание и использование системы обеспечения.
32. Системы уровня предприятия, инженерные системы, интересующие системы, системы обеспечения, операционное окружение. Производственный цикл интересующей системы.
Первую часть вопроса смотри вопрос 31.
Целенаправленная деятельность начинается с начальной точки (point of origination) и заканчивается в точке назначения (point of destination). Учитывая ограничения на всех стадиях, вопрос состоит в том, как нам перейти от point of origination (Point A), к point of destination (Point B)?
Системы уровня предприятия и инженерные системы — Enterprise and Engineered Systems — имеют, по крайней мере, три основных фазы применения: Подготовительная (Pre-Mission), Исполнение (Mission), Завершающая (Post-Mission). Для некоторые систем требуется назначить дополнительные промежуточные фазы, например, Storage.
