Роль тестирования в сертификации ПО систем с высокими требованиями к надежности и безопасности
•Download as PPTX, PDF•
1 like•1,600 views
Презентация Алексея Николаева на SQA Days-16 14-15 ноября 2014, Санкт-Петербург, Россия www.sqadays.com
Recommended
Recommended
More Related Content
What's hot
Viewers also liked
Viewers also liked (15)
Similar to Роль тестирования в сертификации ПО систем с высокими требованиями к надежности и безопасности
Similar to Роль тестирования в сертификации ПО систем с высокими требованиями к надежности и безопасности (20)
More from SQALab
More from SQALab (20)
Роль тестирования в сертификации ПО систем с высокими требованиями к надежности и безопасности
- 1. Роль тестирования в сертификации ПО систем с высокими требованиями к надежности и безопасности Алексей Николаев. ООО НПП «ЭКРА»
- 2. Кратко о себе Алексей Николаев С 2006 г. – кандидат технических наук Более 10 лет работы в области IT 4 года в тестировании ПО На текущий момент – ведущий инженер ООО НПП «ЭКРА» E-mail: nl-79@mail.ru
- 3. Системы с высокими требованиями к надежности и безопасности Это системы, в которых сбой или крах могут: • Привести к смерти либо серьезному ущербу для здоровья людей; • Привести к разрушению либо серьезным повреждениям дорогостоящего оборудования; • Нанести ущерб окружающей среде.
- 4. Основные причины ошибок в ПО Причина Частота появления, % Неполное или ошибочное техническое задание (ТЗ) 28 Отклонение от ТЗ 12 Ошибочная логика или последовательность операций 12 Пренебрежение правилами программирования 10 Ошибочная выборка данных 10 Ошибочные арифметические операции 9 Неточная запись 8 Нехватка времени на решение 4 Неправильная обработка прерываний 4 Неправильные данные 3
- 5. Управление рисками Разработка программного обеспечения (ПО) — явно не детерминированный процесс. Один из приемов, повышающих вероятность успеха в данном процессе — использование методов управления рисками. Управление рисками — это процедуры и действия, которые позволяют менеджеру выявлять, оценивать, отслеживать и устранять риски до или во время их превращения в проблемы.
- 6. Задачи управления рисками при сертификации • Как быстро можно изучить требования нормативных документов? • Будет ли необходимость в адаптации существующих процессов ЖЦ ПО к требованиям нормативных документов? • Как изменится комплект документов на каждом из этапов ЖЦ ПО? • Как изменятся время и стоимость разработки? • Как изменятся ресурсы на тестирование ПО? • Позволит ли имеющийся бюджет решить поставленную задачу?
- 7. Как быстро можно изучить требования нормативных документов?
- 8. Стандарты на жизненный цикл ПО в каждой из отрасли Стандарты в отраслях: • Транспорт • Автомобильный (ISO 26262) • Авиационный (DO-178) • Медицина (IEC 62304) • Атомная энергетика (IEC 60880, IEC 62138) • Космос (ECSS-E-ST-40C)
- 9. Общие черты для большинства стандартов жизненного цикла ПО Базовым стандартом для ПО такого класса является: • IEC 61508 «Функциональная безопасность систем электрических, электронных, программируемых электронных, связанных с безопасностью» Если в какой-то отрасли еще не созданы специфические для нее стандарты, то используется IEC 61508.
- 10. Управление качеством разрабатываемого ПО • Высокая функциональная безопасность и надежность ПО достигается и определяется преимущественно за счет технологий обеспечения качества на всех этапах жизненного цикла (ЖЦ) ПО. • Во всех стандартах значительное внимание уделяется технологическим процессам и инструментальным системам обеспечения безопасности и качества ЖЦ ПО.
- 11. Взаимосвязь наиболее признанных и применяемых в мире стандартов в области разработки ПО
- 12. Совокупность нормативных документов и методических руководств для программных средств
- 13. Стандарты оценки качества и надежности ПО Определяют характеристики ПО (метрики), используемые для качественной и количественной оценки надежности: • ISO/IEC 9126 • IEEE 982 • IEEE 1061 и др.
- 14. Будет ли необходимость в адаптации существующих процессов ЖЦ ПО к требованиям нормативных документов?
- 15. Типовая V-модель разработки ПО и этапы
- 17. Основные проблемы Этапы • Изучение нормативной документации (ГОСТ) • Составление плана и оценка объема работ • Перечень документов, предоставляемых в орган сертификации • Адаптирование процессов разработки и тестирования
- 18. Иерархическая взаимосвязь между документами МАГАТЭ и МЭК • Высший уровень: документы МАГАТЭ по безопасности; • Первый уровень: стандарт МЭК 61513 «Общие требования к системам, важным для безопасности АЭС»; • Второй уровень: детализация требований по общим вопросам (имеются ссылки в документе первого уровня); • Третий уровень: требования к конкретному оборудованию, техническим методам или конкретной деятельности.
- 19. Атомная энергетика – стандарты и требования к сертификации ПО МЭК 61513 следующим образом устанавливает классы систем, важных для безопасности Функции безопасности Класс 1 Класс 2 Класс 3 Категория А + Категория В + + Категория С + + + Не классифицированные + + +
- 20. Функции безопасности и их соответствие ГОСТ Функции безопасности ГОСТ Категория А ГОСТ Р МЭК 60880-2011 Категория В ГОСТ Р МЭК 62138-2010 Категория С ГОСТ Р МЭК 62138-2010
- 21. Российские стандарты (требования к ПО) Российские нормативные документы: • ГОСТ Р МЭК 61226-2011. Атомные станции. Системы контроля и управления, важные для безопасности. Классификация функций контроля и управления • ГОСТ Р МЭК 61513-2011. Атомные станции. Системы контроля и управления, важные для безопасности. Общие требования • ГОСТ Р МЭК 60880-2011. Атомные электростанции. Системы контроля и управления, важные для безопасности. Программное обеспечение компьютерных систем, выполняющих функции категории А • ГОСТ Р МЭК 62138-2010. Атомные электростанции. Системы контроля и управления, важные для безопасности. Программное обеспечение компьютерных систем, выполняющих функции категорий В и С
- 22. Российские стандарты (требования к ПО) Российские нормативные документы: • РД-03-17-2001. «Положение об аттестации программных средств, применяемых при обосновании безопасности объектов использования атомной энергии» • ГОСТ 28195-89. «Оценка качества программных средств. Общие положения» • ГОСТ Р ИСО/МЭК 9126-93. «Оценка программной продукции. Характеристики качества и руководства по их применению» • ГОСТ Р ИСО/МЭК 12207-2010. «Информационные технологии. Процессы жизненного цикла программных средств» • ГОСТ 34.ххх. «Стандарты информационной технологии» • ГОСТ 19.ххх. «Единая система программной документации» (ЕСПД)
- 23. Как изменится комплект документов на каждом из этапов ЖЦ ПО?
- 24. Требования к выходным документам ЖЦ ПО Стандартами рекомендуется подготовить и утвердить содержание следующих планов: • Разработки и реализации всего ЖЦ ПО (модель ЖЦ ПО, компоненты, внешняя и технологическая среда проектирования) • Верификации и тестирования (методы и средства устранения дефектов и достижения необходимых показателей качества) • Реализации процессов интеграции компонентов • Управления конфигурацией и сопровождения • Тиражирования, адаптации и внедрения версий ПО, включая подготовку и обучение пользователей • Документирования процессов и результатов ЖЦ ПО, включая создание и выпуск эксплуатационной документации • Управления и обеспечения безопасности ПО (методы и средства гарантирования требуемой безопасности)
- 25. Циклы разработки ПО и выходные результаты каждого этапа Комплекс стандартов ГОСТ 34 можно считать более общим по сравнению со стандартом ЕСПД. Иерархия стандартов: • комплекс стандартов ГОСТ 34 • ГОСТ Р ИСО/МЭК 12207-2010 • ГОСТ 19 Ресурсы Internet • http://www.rugost.com/ • http://www.gosthelp.ru/
- 26. Как изменятся время и стоимость разработки?
- 27. Понятие качества программного обеспечения Качество программного обеспечения • способность программного продукта при заданных условиях удовлетворять установленным или предполагаемым потребностям (ISO/IEC 25000:2014); • весь объем признаков и характеристик программ, который относится к их способности удовлетворять установленным или предполагаемым потребностям (ГОСТ Р ИСО/МЭК 9126- 93, ISO 8402:94); • степень, в которой система, компонент или процесс удовлетворяют потребностям или ожиданиям заказчика или пользователя (IEEE Std 610.12-1990).
- 28. Надежность – одна из характеристик качества ПО согласно ГОСТ Р ИСО/МЭК 9126-93
- 29. Надежность аппаратная и программная Надежность - это свойство системы выполнять заданные функции, сохраняя во времени значение эксплуатационных показателей в установленных пределах, соответствующих режимам и условиям эксплуатации. Надежность ПО - сохранение своего статуса качества функционирования за установленный промежуток времени. Параметр Аппаратная Программная Зависимость от входных данных не зависит зависит Характер появления ошибок случайный постоянный Составные элементы блоки код
- 30. Взаимосвязь характеристик качества ПО Источник: С. Макконнелл
- 31. Как изменятся ресурсы на тестирование ПО?
- 32. Дополнительные задачи перед группой тестирования Испытания надежности и функциональной безопасности ставят перед группой тестирования следующие задачи: • Составление плана и программы проведения испытаний функциональной безопасности • Разработка тестовых сценариев и динамических моделей внешней среды для генерации тестов • Отладка тестовых сценариев и генераторов динамических тестов • Верификация, проверка, выявление и исправление дефектов генераторов динамических тестов • Определение качества тестов и степени реализации функций и характеристик безопасности • Пересмотр и корректировка эксплуатационной документации
- 33. Изменения в процессах ЖЦ ПО Основные изменения в процессах ЖЦ ПО • Создание комплекта документов на каждом этапе ЖЦ ПО • Необходимость адаптации процессов ЖЦ ПО к выбранной методологии разработки • Увеличение ресурсов на тестирование • Увеличение времени и стоимости разработки
- 34. Заключение Сертификация программного обеспечения – это длительный и трудоемкий процесс, который не может быть бесплатным. Наличие сертификата соответствия значительно расширяет рынок сбыта продукта заявителя и увеличивает количество продаж. Сертификация • один из способов обеспечения и повышения надежности ПО. • это обязательная часть регистрации продукции в России, чтобы ее можно было продавать. Ресурсы Internet • http://www.rugost.com/ • http://www.gosthelp.ru/
Editor's Notes
- Доклад призван помочь всем заинтересованным лицам: менеджерам, тестировщикам, разработчикам разобраться в множестве требований существующих стандартов к процессам ЖЦ ПО при прохождении такого ответственного этапа, как сертификация ПО. Приводятся рекомендации по применению стандартов. Описываются этапы и выходные документы каждого из них. Перечисляются основные различия этапов работ от этапов при разработке ПО общего назначения.
- Краткая информация о себе. Информация о личном опыте: в настоящее время – тестирование настольных приложений Windows.
- Надежность и безопасность – одни из характеристик качества ПО. ПО рассматривается как один из компонентов системы. Системы с высокими требованиями к надежности и безопасности накладывают дополнительные ограничения на процессы ЖЦ ПО. Отличительная особенность таких систем: 1. Известный заказчик, 2. Относительно узкая сфера применения, 3. Присутствует управление планами поставки, 4. Ограничения в сроках поставки готовых испытанных продуктов заказчику, 5. Изменения в коде, как правило, выполняются с санкции заказчика, 6. Производство таких систем с соблюдением определенных стандартов и правил, 7. Оформление на них достаточно полной технологической документации
- Перечислены основные причины ошибок в ПО общего назначения.
- Новизна используемых технологий, сложность заданий, отсутствие у разработчиков необходимой квалификации — из-за этих и многих других факторов проекты часто идут не так, как планировалось. Один из приемов, повышающих вероятность успеха в таких условиях — использование методов управления рисками. Управление рисками — это процедуры и действия, которые позволяют менеджеру выявлять, оценивать, отслеживать и устранять риски до или во время их превращения в проблемы. Риски желательно выявить как можно раньше и заведомо еще до того, как они превратились в проблему (обычно в этом случае принятие мер требует меньших ресурсов). После выявления риска необходимо принять решение об ответных действиях. Задача руководителя проекта — выбрать такие действия, которые позволят снизить вероятность неблагоприятного события или уменьшить его последствия в случае реализации риска. При этом желательно, чтобы расход ресурсов был минимальным.
- Перечислены основные задачи управления рисками при разработке ПО для систем подобного рода. Главное в процессе – необходимость представлять решение поставленной задачи в общем виде еще на начальном этапе сертификации.
- Сертификация ПО подразумевает выполнение этапов ЖЦ ПО в соответствии с требованиями тех или иных нормативных документов. Закономерно, что эти нормативные документы должны быть изучены.
- В каждой отрасли существуют свои утвержденные стандарты. Каждый из них содержит требования к разрабатываемому ПО в своей отрасли промышленности.
- Базовым стандартом для ПО такого класса является IEC 61508. В тех отраслях, где в настоящий момент еще не существует утвержденного стандарта разработки ПО, должен применяться стандарт IEC 61508.
- Полное устранение негативных воздействий и дефектов, отражающихся на функциональной безопасности и надежности ПО, принципиально невозможно. Проблема состоит в выявлении факторов, от которых они зависят, в создании методов и средств уменьшения их влияния на функциональную пригодность и эффективном распределении ограниченных ресурсов для обеспечения необходимого качества. Комплексное применение этих методов и средств позволяет исключать проявления ряда негативных факторов или значительно ослаблять их влияние. Это позволяет управлять качеством разрабатываемого ПО.
- Надежность и безопасность любого разрабатываемого ПО напрямую связана с используемым стандартом разработки. Говорить о том, что существует один универсальный стандарт для программных систем любого вида, не приходится.
- Систематично и подробно процессы ЖЦ сложных программных комплексов описаны в базовом стандарте ISO 12207-2010 и в свыше десяти сопутствующих ему стандартах. Процессы делятся на три базовых типа: основные, вспомогательные, организационные. Изучение нормативной документации – львиная доля затрат на начальном этапе работы. У нас данный период занял примерно полгода.
- Априори невозможно обеспечить абсолютное отсутствие дефектов проектирования сложного ПО, вследствие чего надежность их функционирования всегда имеет конечное, ограниченное значение. Существуют также стандарты оценки показателей качества ПО.
- Предлагаемая стандартами V-модель разработки ПО позволяет эффективно отслеживать и поддерживать непрерывную взаимосвязь между разработкой и тестированием. Если ПО и аппаратная часть разрабатываются и сертифицируются в связке, V-модель выглядит сложнее (в этом случае букву V образуют аппаратная и программная части). Это строго управляемый процесс разработки, нацеленный на минимизацию рисков внесения ошибки в требования, ПО и тесты. Выход каждого этапа, как правило, это определенный перечень документов жизненного цикла ПО. Количество и перечень этих документов зависит от разрабатываемого ПО (требований к его функционалу, в том числе надежности и безопасности). Адаптация существующего процесса разработки в организации прошла достаточно гладко.
- Все, что говорилось ранее о стандартах ЖЦ ПО, актуально и для отрасли «Атомная энергетика». При этом к процессам ЖЦ ПО предъявляются дополнительные требования в виде документов МАГАТЭ и МЭК.
- Основные проблемы, которые пришлось решать. Все, что говорилось ранее о стандартах ЖЦ ПО, актуально и для отрасли «Атомная энергетика». При этом к процессам ЖЦ ПО предъявляются дополнительные требования в виде документов МАГАТЭ и МЭК. Ни один из стандартов не устанавливает конкретный комплект документации, а скорее определяет информацию, которая должна быть оформлена документально. Конкретные иерархия и формат принятой документации могут изменяться при условии соблюдения принципов, изложенных в стандарте.
- Иерархия нормативных документов условно позволяет разделить их на 4 уровня: высший, первый, второй и третий.
- МЭК 61513 устанавливает классы систем (1, 2, 3), важных для безопасности (при этом используется своя классификация). Класс системы определяет не только объем выполняемых работ, но и комплект состава программных документов, предоставляемых в сертифицирующий орган.
- Требования к системам, выполняющим функции той или иной категории безопасности, описаны в соответствующих документах МЭК.
- Все перечисленные ГОСТ – переведенные на русский язык зарубежные стандарты. Стандарт ГОСТ Р МЭК 60880-2011 практически не содержит принципиальных или существенных положений, которые не отражены в совокупности современных международных и национальных стандартов.
- Указанные стандарты применимы в том числе к ПО, разрабатываемому для атомной энергетики (и не только).
- Стандарты рекомендуют иметь утвержденную на предприятии «Программу обеспечения качества ПО». Одним из обязательных условий является независимость группы тестирования от группы разработчиков ПО. Количество этапов (планов) определяет минимальное количество выходных документов ЖЦ ПО. Основная нагрузка в выполнении данных этапов ложится, как правило, на группы тестирования и аттестации.
- Выходные документы каждого этапа ЖЦ ПО определены в ГОСТ 34 и ГОСТ 19 и могут применяться также для систем такого рода. Как это было у нас: перечень основных документов, разрабатываемых в процессах жизненного цикла ПО, уже присутствовал. Большую помощь в оформлении недостающего комплекта документации оказали ресурсы Internet. Шаблоны документов доступны по следующим ссылкам. Они позволяют сократить объем работ по подготовке всей необходимой документации (не изобретать велосипед). Данный этап у нас занял около 6 месяцев.
- Время и стоимость разработки напрямую связаны с требованиями к качеству разрабатываемого ПО. Чем выше требования к качеству ПО, тем большее время необходимо на его реализацию.
- Управление рисками и качество ПО – неразрывно связанные понятия. Требования к качеству (в частности, к характеристикам надежности и безопасности) указанных систем в целом более жесткие, чем к тем же системам общего назначения. Приводятся определения качества ПО согласно нормативным документам. ПО рассматривается как один из компонентов системы. Системы с высокими требованиями к надежности и безопасности накладывают дополнительные ограничения на процессы ЖЦ ПО.
- Надежность и безопасность – всего лишь одни из характеристик качества ПО. Надежность – одна из характеристик качества ПО согласно ГОСТ Р ИСО/МЭК 9126-93. Надежность — набор атрибутов, относящихся к способности ПО сохранять свой уровень качества функционирования в установленных условиях за определенный период времени. Детализируется следующими подхарактеристиками (субхарактеристиками): уровнем завершенности (отсутствия ошибок), устойчивостью к дефектам, восстанавливаемостью, доступностью, готовностью. Надежность функционирования программ – динамическое понятие. Оно отличается от понятия корректности ПО. Крупные затраты на разработку ПО такого вида приходятся на верификацию и тестирование программных компонентов.
- Понятия надежности для аппаратных и программных средств отличаются. ПО не деградирует, как аппаратные компоненты. Надежность ПО - сохранение своего статуса качества функционирования за установленный промежуток времени. Основные средства повышения надежности: Введение избыточности: 1. временной, 2. программной, 3. информационной. Методы оперативного рестарта
- Увеличение надежности ПО в целом положительно влияет и на остальные характеристики качества (за исключением живучести).
- Приводится список дополнительных задач перед группой тестирования. Испытания надежности и функциональной безопасности – виды работ по тестированию, которые являются обязательными для систем такого вида (в системах общего назначения такие виды работ могут проводиться в значительно меньшем объеме). Степень покрытия тестами структуры функциональных компонентов и комплекса программ в целом может служить ориентиром для прогнозирования их потенциальной надежности. Увеличение затрат для получения высокой надежности трудно обеспечить практически. Испытания функциональной безопасности могут базироваться на методах тестирования надежности.
- В настоящий момент комплект основных документов на сертификацию предоставлен для дальнейшей работы с экспертами. Что дальше? А дальше, смею предположить, оставшаяся половина пути этого продолжительного процесса, работа и исправление замечаний и т.д.
- Сертификация программного обеспечения – это длительный и трудоемкий процесс, который не может быть бесплатным. Необходимо подстроить существующие процессы жизненного цикла ПО под требования стандартов, разработать и утвердить определенный комплект программной документации, оценить дополнительные затраты, возможные риски и т.д. Этот процесс – не что-то заоблачное и невыполнимое. В то же время большая часть его – рутинная работа. Сертификация – один из способов обеспечения и повышения надежности ПО. Грамотное построение процессов ЖЦ ПО позволяет успешно пройти такой ответственный этап, как «Сертификация».