N u c l e a r Системное проектирование - Процессы жизненного цикла системы Конференция: Управление жизненным циклом АЭС. Системная инженерия 26 марта 2009 г. Докладчик: Стив Ривкин BTech Магистр Наук, Доктор философии Партнер, Отделение Управления

N u c l e a r Вопросы, подлежащие рассмотрению Обзор стандарта ИСО/МЭК 15288:2008 Требования ВНИИАЭС Управление сложностью- каковы общие цели? Различные V-модели и их стандарты Какая V-модель является «драйвером»? Проектирование с выполнением требований Верификация & Валидация Процессы поддержания проекта Несколько примеров крупных проектов

N u c l e a r Стандарт ИСО/МЭК 15288:2008 (1) Цель Обеспечение общей структуры процесса, которая охватывает срок службы человеко-машинных систем Упрощение процесса коммуникации между Покупателями, Поставщиками и другими заинтересованными сторонами –Жизненный цикл Концепция, разработка, производство, утилизация, поддержка и изъятие из эксплуатации Систем, А также приобретение и поставка Систем Обеспечивает Процессы приобретения и поставки систем Структуру оценки и улучшения Проектных процессов

N u c l e a r Стандарт ИСО/МЭК 15288:2008 (2) Режимы использования Организация –Помочь установить среду проведения желаемых процессов Проект –Помочь провести отбор, структурирование и использование элементов установившейся среды и обеспечить продукты и услуги Покупатель & Поставщик –Содействие в разработке соглашения по процессам и мероприятиям Оценщики процесса –Служат как эталонная модель процесса

N u c l e a r Стандарт ИСО/МЭК 15288:2008 (3) Планируемое использование Обеспечивает требования к ряду процессов для их использования во время жизненного цикла Системы Не все процессы могут потребоваться Как правило, использование процессов, пригодных для Организации или Проекта Соответствие Полное соответствие –Демонстрация всех требований заявленного набора процессов, выполняемых при использовании результатов как доказательства Нестандартное соответствие –Подгонка процесса (Приложение A), используемого для улучшения процесса –Только качество для нестандартного соответствия –Нестандартное соответствие Продемонстрировать, что требования для подогнанных процессов выполнены Результаты, используемые как доказательство

N u c l e a r Процессы в ИСО/МЭК 15288:2008 (3) Процессы жизненного цикла системы Процессы для каждой из четырех технологических групп, определенных в Статье 6 ИСО/МЭК 15288:2008 Каждый процесс, определенный с точки зрения: –цели –результатов –Мероприятий и задач. Применение процесса Процессы жизненного цикла могут использоваться любой организацией при получении, использовании, создании или поставке системы Каждый процесс может быть активизирован в любое время в течение жизненного цикла ИСО/МЭК 15288:2008 не предписывает какой-либо конкретный порядок Модель жизненного цикла представляет логическую последовательность Сложная система процессов будет работать в течение жизненного цикла системы, и у них будут согласованные, итеративные, рекурсивные и зависимые по времени характеристики

N u c l e a r Требования ВНИИАЭС (1) Цитата с интернет-сайта: ВНИИАЭС (Всероссийский научно-технический институт по эксплуатации АЭС) был образован в 1979 году по постановлению СМ СССР с целью обеспечения научно-технической поддержки эксплуатации атомных станций на основе выполнения научно- исследовательских и конструкторских работ, направленных на улучшение безопасности, надежности и экономической эффективности, а также осуществление научного руководства запуском новых атомных станций.

N u c l e a r Требования ВНИИАЭС (2) Ключевые аспекты вышеизложенного: Обеспечение научно-технической поддержки Выполнение научно-исследовательских и конструкторских работ Улучшение безопасности, надежности и экономической эффективности Массовое строительство атомных электростанций. ИСО/МЭК 15288:2008 обеспечивает: Процессы приобретения и поставки систем Способность выбора, структурирования и использования элементов установленной среды для обеспечения продуктов и услуг Содействие в разработке соглашения по процессам и мероприятиям Структуру оценки и улучшения проектных процессов Средства верификации полного соответствия через демонстрацию объявленного набора процессов, удовлетворяемых при использовании успешных результатов как доказательства или, там где есть нестандартные процессы, –Нестандартное соответствие путем демонстрации требований к процессам, выполняемым при использовании успешных результатов как доказательства

N u c l e a r Требования ВНИИАЭС (3) ВНИИАЭС является заинтересованной стороной и может использовать процессы реализации соглашения для: Разработки соглашения Обеспечения исходных данных, связанных с жизненным циклом -Может включать массовое производство -Может определять желаемые выходные данные. Два ключевых аспекта по крупным проектам и использованию ИСО/МЭК 15288:2008: Сложность Необходимость верификации Нужен подход, который будет управлять сложностью и позволит проводить верификацию

N u c l e a r Управление Сложностью - Многоуровневые жизненные циклы Многоуровневые жизненные циклы могут одновременно выполнять: –ИСО/МЭК … –обеспечение безопасности (с привлечением Регулирующего органа) –61508 (например, программное обеспечение SIL) –Традиционные

N u c l e a r Многоуровневые жизненные циклы Процессы соглашения Организационные и проектные процессы Проектные процессы Технические процессы Заинтересованная сторона Определение требований Анализ требований Архитектурное проектирование Внедрение Интеграция Верификация Переход Валидация Бизнес Цели бизнеса Приобретение системы Приглаше ние для участия в тендере Определение требований Проектировани е высокого уровня Детальное проектирование Осуществление Испытание Блока Интеграция Испытание системы Приемка системы Эксплуата ция и поддержа ние ИСО/МЭК 15288:2008 Жизненный цикл Традицион ный жизненны й цикл Обеспечение безопасности Жизненный цикл Установление требований безопасности заинтересованной стороны И (если есть ранее существующие проекты) Общая оценка проекта (GDA) [от поставщиков] Выбор опции высокого уровня Единый выбор (для общего подхода) Выпуск предварительного отчета по безопасности (PSR) Создание системы безопасности Окончательные требования Предложенный уровень целостности системы (SIL) Вклад выходных данных в безопасность Отчет по безоп-сти перед строит-вом (PCSR) Отчет по безопасности перед эксплуатацией (т.е. Обеспечение Безопасности) Примечание: обзор интерфейсов, и точки безопасности будут установлены при рассмотрении всех жизненных циклов Разработка обучения Выявление требований Руководст ва к подготовке Тестирование целевой группы, проходящей обучение Обучение Справочни ки распределен ия

N u c l e a r Формулирование информации на основе Требований Помимо использования процессов в стандарте, можно сформулировать процессы и информацию, необходимую для их поддержания, с точки зрения предъявляемых Требований.

N u c l e a r Жизненный цикл с одноранговой верификацией и валидацией Требования к акционерам Опытная эксплуатация Приемка Требования к проекту (Фаза спецификации функциональности) Тестирование системы Тестирование под- систем Первичный образец разработки: требования к системе + Требования к акционерам Детальный дизайн + выполнение/строител ьство промежуточный& окончательный образец разработки Разъяснение/выявление Проверка исполнения (в едином ключе) Верификация Тестирование спецификации Тестирование спецификации Интеграция Монтаж и ввод в эксплуатацию Верификация Интеграционное системное тестирование Валидационное тестирование, учитывая критерии приемки Приемочное тестирование Верификация Фаза 1 Фаза 2 Фаза 3 Фаза 4 Существующие требования Объем для планирования Детальные требования руководства для планирования на более низком уровне

N u c l e a r Хороший опыт, принятый в многих отраслях промышленности для разработки требований сверху вниз по каждому этапу жизненного цикла. Стандартное время для выработки требований составляет 20% от времени разработки всего проекта. Основные преимущества Прослеживаемый путь вниз на протяжении жизненного цикла; Понятное определение того, что нужно на последующем этапе жизненного цикла Внесение изменений заблаговременно для обеспечения невысокой стоимости изменения Проектирование на основе требований (1)

N u c l e a r Иерархия требований Стратегии, изучение, архитектура Требования Заинтересованной Стороны Требования, разработанные на основе входных данных 15288, жизненный цикл обеспечения безопасности и т.д. Требован ия к схеме Требования к конструкции на высоком уровне Требования к конструкции на низком уровне Требования к техническому проекту Требования к фазе сбора данных Фаза продолжающегося конструирования Фаза внедрения Информирование о целях проекта Объем поставки технических услуг

N u c l e a r Управление Требованиями - Декомпозиция требований Все дисциплины должны рассматриваться, исходя из требований В идеале: Сверху вниз, стандартная декомпозиция требований в течение срока службы Некоторые элементы снизу вверх обычно необходимы в силу существующих неофициальных стандартов, созданных производителями

N u c l e a r Структурированное декомпозиция и прослеживаемость в ДООСТ Коммерческие требования Требования Спонсоров & Заинтересованных сторон Доказательство соответствия Доказательство выполнения Доказательство соответствия Доказательство выполнения Доказательство соответствия Заявление по вопросу принципов Доказательство выполнения Функциональные требования проекта Спонсоры & Заинт. стороны Сверху вниз Снизу вверхРеверсивноепроектирование Доказательство выполнения Доказательство соответствия Начальные нормированные проектные требования Промежуточные нормированные проектные требования Проект Знания в определенной Области, стандарты и законы

N u c l e a r Проектирование на основе требований с использованием ДООСТ Что такое ДООСТ 1 ? (Динамическая Объектно- Ориентированная Система Требований) База данных специалиста для управления требованиями Многопользовательская среда Легкая навигация в пределах базы данных Редактирование возможностей с помощью контрольной записи Преимущества ДООСТ Создание отслеживаемости через простое перетаскивание и опускание элементов. Определение влияния предложенных изменений на основе анализа влияния. Валидация спецификаций на основе анализа отслеживаемости. Определение нерассмотренных требований на основе анализа пробела. Базовая законченная информация с электронными подписями. Просмотр информации в содержательном документо- ориентированном формате DOORS – поставляет именно то, что вы хотите построить 1 DOORS Database, Telelogic AB, PO Box 4128, Kungsgatan 6, SE Malmö, Sweden (now IBM as of 1 November 2008)

N u c l e a r Проектно-ориентированные требования при использовании сложной отслеживаемости Структуры требований и верификации в ДООСТ («сложная отслеживаемость» Требования к схеме Требования бизнеса Требования акционеров Соответствующ ие документы Модуль споров в выполнении требований Модуль согласования Требования к дизайну высокого уровня Требования к дизайну низкого уровня Требования концессионера к техническому проекту Проверенные и проанализированные требования к схеме Данные Дорс Соответствующ ее обсуждение модуль (СА) 4 проекта Конструирование, выполняющее требования Верификация дизайна, модуль согласования Регистрация документа Составление документации Модуль согласования Верификация дизайна, модуль согласования Регистрация документа Составление документации Верификация дизайна, модуль согласования Регистрация документа Составление документации Соответствующ ее обсуждение модуль (СА) Соответствующ ие документы Внутренние знания, правовые вопросы, стандарты

N u c l e a r Модули требований в ДООСТ

N u c l e a r Управление требованиями - Пример доказательства выполнения (2)

N u c l e a r Управление требованиями - Моментальный снимок экрана верификации ДООСТ

N u c l e a r Стратегия проектно- ориентированных требований Общая стратегия требований Создание плана управления требованиями -Определяет общую стратегию Осуществление стратегии на двух этапах для каждого уровня Требований/Проекта: 1.Этап определения требований -Обеспечивает набор требований 2.Этап проектирования -Проектно-ориентированные требования, обеспечивающие Проектные элементы, связанные с соответствующими требованиями

N u c l e a r Управление требованиями (1) - процессы Цель: –Создать набор требований Пути достижения цели: –Создание плана управления требованиями - Определение процессов для создания ряда требований:- Сбор и рассмотрение требований Анализ требований Обзор требований Верификация требований Линия отсчета требований

N u c l e a r Проектирование на основе требований (2) - процессы Сбор требований Поток вниз по уровням Требований Выявление зависит от качества исходного материала (например, модели рисков и производительности) & опыт и знания инженеров в конкретной области Основанный на интернет технологии доступ к ДООСТ (для работающих дистанционно) Анализ требований Обеспечение Хорошего Требования на правильном уровне Обзор требований Анализ просчетов в проектировании в сравнении с требованиями к выравниванию Проверка междисциплинарных, интерфейсных и общих требований Верификация требований Вертикальный поток вниз через SA, поддерживаемый CA (когда это необходимо) Верификация проекта Обеспечение базиса требований и определение критерий приемки

N u c l e a r Формулирование и стиль требований Что делает требование «здравым»? Каждое требование должно: –Быть выдающимся –Недвусмысленно и четко определять, что в нем заложено –Должно быть верифицируемым –Должно быть необходимым –Должно быть достижимым и контролируемым. Должно находиться на правильном уровне Должно быть хорошо сформулированным –Каждое требование должно быть написано в официальном стиле Например, общий уровень риска вследствие всех опасностей под непосредственным контролем Контроллера Инфраструктуры не должен превышать 0.01 эквивалентных несчастных случаев в год.

N u c l e a r Анализ требований (1) Оценка требований на основе моделирования

N u c l e a r Анализ требований (2) Метод валидации Мероприятие, которое обеспечивает информацию для оценки требования и подтверждения его правильной формулировки. Мероприятиями по валидации для оценки требования являются: обзоры инспекции анализ на основе моделирования. Метод испытания Любое действие, позволяющее выявить дефект там, где дефект является результатом нарушения требований. Действия после завершения испытания: Уровень компонента Уровень подсистемы Уровень системы

N u c l e a r Анализ требований (3)

N u c l e a r Анализ требований Проектные группы проводят анализ своих требований: Анализ структуры требований Группы Проверка требований в сравнении с критериями «Хорошего требования» - Недвусмысленное, верифицируемое, необходимое, контролируемое, на правильном уровне и хорошо сформулированное Проверка того, что каждое требование может быть испытано - Что является методом испытания? Испытание, анализ, демонстрация, инспекция – все это должно быть уточнено на более позднем этапе проектирования Есть ли какие-либо допущения? –На чем они основаны ? Риск (риск? риск ID?) Вопрос (поднят вопрос? Вопрос касательно ID?) Ожидание информации (RFI ? Уточнен RFI Ref?)

N u c l e a r Дисциплинарные и междисциплинарные требования, требования заинтересованной стороны и анализ доказательства выполнения требований Анализ требований + доказательства их выполнения Проведение анализа дисциплины Обновление требований и доказательств выполнения согласно замечаниям Выполнение междисциплинарных анализов Обновление требований и доказательств выполнения согласно замечаниям Выполнение анализа требований заинтересованной стороны Обновление требований и доказательств выполнения согласно замечаниям

N u c l e a r Проектирование и анализ доказательства верификации Анализ доказательства верификации проекта (ДВП) + проект Проведение анализов дисциплины –Обновление ДВП и/или требований и проекта согласно замечаниям Выполнение междисциплинарных анализов –Обновление ДВП и/или требований и проекта согласно замечаниям Выполнение анализа стимулирующего фактора –Обновление ДВП и/или требований и проекта согласно замечаниям Выполнение анализа требований заинтересованной стороны –Обновление ДВП и/или требований и проекта согласно замечаниям Создание набора критериев требований к системе

N u c l e a r Анализ требований Проведение междисциплинарных анализов требований - Выполнение анализа общей структуры требований - Проверка всех требований, включая Общие Требования - Проверка взаимозависимостей между двумя или большим количеством дисциплинарных требований - Проверка конфликтов между двумя или большим числом дисциплинарных требований - Проверка интерфейсных требований между двумя или большим числом дисциплин и между дисциплиной и заинтересованной стороной или 3-ьей стороной. Выпуск требований для проведения анализа Командой Заинтересованной Стороны

N u c l e a r Анализ требований заинтересованных сторон и создание базиса Анализ требований заинтересованной стороны Анализ набора требований более низкого уровня в сравнении с требованиями заинтересованной стороны Обеспечение обратной связи заинтересованной стороны Создание основных требований Создание базиса требований в ДООСТ

N u c l e a r Проектирование на основе требований (2) Преимущества подхода на основе требований Этот подход дает ряд ключевых преимуществ: Проект тщательно разрабатывается на основе требований заинтересованной стороны Сводка Проекта будет ясной, и никакой итерации Проекту не потребуется Большие команды инженеров не будут подключаться к определенному этапу проектирования на длительный период времени Иерархия требований и каждый элемент каждого уровня проектирования полностью прослеживается Доступность требований каждого покупателя/заинтересованной стороны позволяет проводить изменения в такое время (после месяцев изучения проекта), когда проектные изменения потребовали бы большой переделки и, соответственно, высоких затрат Широкая доступность проекта и использование родного языка позволяют обеспечить лучшее понимание со стороны инженеров всех дисциплин Подтверждение верификации на каждом этапе делает ощутимый вклад в Обеспечение Безопасности

N u c l e a r Интегрированные процессы поддержки проекта

N u c l e a r Процессы поддержания проекта- Управление риском

N u c l e a r Процессы поддержания проекта – Контроль за изменениями

N u c l e a r Несколько примеров крупных проектов при использовании ДООСТ Вот примеры, где Mott MacDonald успешно использует Управление Требованиями Поперечное железнодор ожное сообщение Лондон Терминал 5 Хитроу Линия Восточ ный Лондон

N u c l e a r Краткие выводы (1) Краткие выводы Мы рассмотрели Потребность ВНИИАЭС в стандарте ИСО/МЭК 15288:2008 –Обеспечивает структуру процессов для Проекта с рассмотрением: Соглашений между Покупателем и Поставщиком Организацию проекта Поддержку проекта Техническую поддержку –Структура может быть использована для оказания содействия в получении успешных результатов верификации Признается, что есть многоуровневые жизненные циклы, что вызывает большую сложность

N u c l e a r Краткие выводы (2) Краткие выводы (продолжение) Для управления сложностью предложен подход на основе Требований, который обеспечивает –Структурированное сверху-вниз разбиение сложности на блоки управляемых размеров, что сопоставимо с подходом Система/Система-Элемент в стандарте ИСО/МЭК 15288:2008 –Полная прослеживаемость от самых нижних элементов Проектирования/Реализации до основы стандарта ИСО/МЭК 15288:2008 –Механизмы верификации являются неотъемлемой частью механизмов, используемых в подходе –Подход на основе Требований поддерживается интегрированным набором Проектных процессов, которые также жестко привязаны к специальным модулям и атрибутам в Базе данных ДООСТ.