Верификация и валидация программного обеспечения
В управлении проектами программного обеспечения , тестировании программного обеспечения и разработке программного обеспечения верификация и валидация — это процесс проверки того, что система инженера-программиста соответствует спецификациям и требованиям и выполняет свое предназначение. Его также можно назвать контролем качества программного обеспечения . Обычно это входит в обязанности тестировщиков программного обеспечения в рамках жизненного цикла разработки программного обеспечения . Проще говоря, проверка программного обеспечения заключается в следующем: «Предполагая, что мы создадим X, достигнет ли наше программное обеспечение своих целей без каких-либо ошибок или пробелов?» С другой стороны, проверка программного обеспечения заключается в следующем: «Было ли X тем, что мы должны были создать? Соответствует ли X требованиям высокого уровня?»
Определения [ править ]
Верификация и валидация — это не одно и то же, хотя их часто путают. Бём кратко выразил разницу так: [1]
- Проверка: правильно ли мы создаем продукт?
- Проверка: создаем ли мы правильный продукт?
«Правильное создание продукта» проверяет, что спецификации правильно реализованы системой, а «создание правильного продукта» относится к потребностям пользователя . В некоторых случаях требуется иметь письменные требования для обоих, а также формальные процедуры или протоколы для определения соответствия. В идеале формальные методы обеспечивают математическую гарантию того, что программное обеспечение соответствует своим спецификациям.
Правильное создание продукта подразумевает использование спецификации требований в качестве входных данных для следующего этапа процесса разработки, процесса проектирования, результатом которого является спецификация проекта. Кроме того, это также подразумевает использование проектной спецификации для обеспечения процесса строительства. Каждый раз, когда выходные данные процесса правильно соответствуют входным спецификациям, программный продукт становится на шаг ближе к окончательной проверке. Если выходные данные процесса неверны, разработчики неправильно создают продукт, который нужен заинтересованным сторонам. Этот вид проверки называется «проверкой артефакта или спецификации».
выпущен программный продукт; [ нужны разъяснения ] хотя это не всегда так. [а]
Проверка программного обеспечения [ править ]
Это означало бы проверку соответствия спецификациям путем запуска программного обеспечения, но это невозможно (например, как кто-либо может узнать, правильно ли реализована архитектура/проектирование и т. д. при запуске программного обеспечения?). Только просмотрев связанные с ним артефакты, можно сделать вывод, соответствуют ли спецификации.
Проверка артефакта или спецификации [ править ]
Выходные данные каждого этапа процесса разработки программного обеспечения также могут подлежать проверке при сравнении с входными спецификациями (см. определение CMMI ниже).
Примеры проверки артефактов:
- Сопоставление спецификации проекта со спецификацией требований: правильно ли архитектурное проектирование, детальное проектирование и спецификации логической модели базы данных реализуют спецификации функциональных и нефункциональных требований?
- Из артефактов конструкции, противоречащих проектной спецификации: правильно ли исходный код, пользовательские интерфейсы и физическая модель базы данных реализуют проектную спецификацию?
Проверка программного обеспечения [ править ]
Проверка программного обеспечения проверяет, что программный продукт удовлетворяет или подходит для предполагаемого использования (проверка высокого уровня), т. е. программное обеспечение соответствует требованиям пользователя, а не как артефакты спецификации или потребности только тех, кто будет использовать программное обеспечение; но и потребности всех заинтересованных сторон (таких как пользователи, операторы, администраторы, менеджеры, инвесторы и т. д.). Существует два способа выполнения проверки программного обеспечения: внутренний и внешний. Во время внутренней проверки программного обеспечения предполагается, что цели заинтересованных сторон были правильно поняты и что они были точно и всесторонне выражены в артефактах требований. Если программное обеспечение соответствует техническим требованиям, оно прошло внутреннюю проверку. Внешняя проверка происходит, когда она выполняется путем опроса заинтересованных сторон, соответствует ли программное обеспечение их потребностям. Различные методологии разработки программного обеспечения требуют разных уровней участия пользователей и заинтересованных сторон и обратной связи; таким образом, внешняя проверка может быть дискретным или непрерывным событием. Успешная окончательная внешняя проверка происходит, когда все заинтересованные стороны принимают программный продукт и заявляют, что он удовлетворяет их потребностям. Такая окончательная внешняя проверка требует использования приемочное испытание , которое является динамическим испытанием .
Однако также возможно выполнить внутренние статические тесты, чтобы выяснить, соответствует ли программное обеспечение спецификациям требований, но это входит в объем статической проверки, поскольку программное обеспечение не работает.
Проверка артефакта или спецификации [ править ]
Требования должны быть проверены до того, как программный продукт в целом будет готов (каскадный процесс разработки требует, чтобы они были четко определены до начала проектирования; но итеративные процессы разработки не требуют этого и допускают их постоянное улучшение).
Примеры проверки артефактов:
- Проверка спецификации требований пользователя: требования пользователя, изложенные в документе, называемом «Спецификация требований пользователя», проверяются путем проверки, действительно ли они отражают волю и цели заинтересованных сторон. Это можно сделать, опросив заинтересованные стороны и задав им прямой вопрос (статическое тестирование) или даже выпустив прототипы и попросив пользователей и заинтересованные стороны оценить их (динамическое тестирование).
- Проверка пользовательского ввода: Пользовательский ввод (собираемый любым периферийным устройством, например, клавиатурой, биометрическим датчиком и т. д.) проверяется путем проверки того, соответствует ли ввод, предоставленный операторами программного обеспечения или пользователями, правилам и ограничениям домена (например, тип данных, диапазон и формат).
Валидация против верификации [ править ]
Согласно модели зрелости возможностей (CMMI-SW v1.1), [3]
- Проверка программного обеспечения: процесс оценки программного обеспечения во время или в конце процесса разработки, чтобы определить, удовлетворяет ли оно заданным требованиям. [IEEE-STD-610]
- Верификация программного обеспечения: процесс оценки программного обеспечения для определения того, удовлетворяют ли продукты данного этапа разработки условиям, наложенным в начале этого этапа. [IEEE-STD-610]
Валидацию в процессе разработки программного обеспечения можно рассматривать как форму проверки спецификации требований пользователя; и что в конце процесса разработки эквивалентно внутренней и/или внешней проверке программного обеспечения. Верификация, с точки зрения CMMI, очевидно, является артефактом.
Другими словами, верификация программного обеспечения гарантирует, что результаты каждого этапа процесса разработки программного обеспечения эффективно соответствуют тому, что указывает соответствующий входной артефакт (требование -> проектирование -> программный продукт), в то время как проверка программного обеспечения гарантирует, что программный продукт отвечает потребностям все заинтересованные стороны (следовательно, техническое задание было сформулировано правильно и точно). Проверка программного обеспечения гарантирует, что «вы построили его правильно» и подтверждает, что продукт в том виде, в котором он предоставлен, соответствует планам разработчиков. Проверка программного обеспечения гарантирует, что «вы создали правильную вещь», и подтверждает, что продукт в том виде, в котором он предоставлен, соответствует предполагаемому использованию и целям заинтересованных сторон.
В этой статье использовано строгое или узкое определение проверки.
С точки зрения тестирования:
- Ошибка – неправильная или отсутствующая функция в коде.
- Неудача – проявление ошибки во время исполнения. Программное обеспечение оказалось неэффективным. Он не делает «того», что должен делать.
- Неисправность – согласно спецификации система не соответствует заданной функциональности. Программное обеспечение было неэффективным (оно занимало слишком много ресурсов, таких как циклы ЦП, использовало слишком много памяти, выполняло слишком много операций ввода-вывода и т. д.), было непригодным для использования, оно не было надежным и т. д. что-то «как» это должно быть сделано.
Связанные понятия [ править ]
И верификация, и валидация связаны с концепциями качества и обеспечения качества программного обеспечения . Сами по себе верификация и валидация не гарантируют качество программного обеспечения; планирование, отслеживаемость необходимы , управление конфигурацией и другие аспекты разработки программного обеспечения.
В сообществе моделирования и симуляции (M&S) определения верификации, валидации и аккредитации аналогичны:
- Проверка M&S — это процесс определения того, что компьютерная модель , моделирование или объединение моделей и реализаций моделирования и связанных с ними данных точно представляют концептуальное описание и спецификации разработчика. [4]
- Валидация M&S — это процесс определения степени, в которой модель, симуляция или объединение моделей и симуляций и связанные с ними данные являются точным представлением реального мира с точки зрения предполагаемого использования. [4]
- Аккредитация — это формальная сертификация того, что модель или моделирование можно использовать для определенной цели. [4]
Определение валидации M&S фокусируется на точности, с которой M&S представляет реальное предполагаемое использование. Определение степени точности МиО необходимо, поскольку все МиО являются аппроксимациями реальности, и обычно очень важно определить, приемлема ли степень аппроксимации для предполагаемого использования(й). Это контрастирует с проверкой программного обеспечения.
Методы верификации и верификации [ править ]
Формальный [ править ]
В критически важных программных системах могут использоваться формальные методы для обеспечения правильной работы системы. Однако эти формальные методы могут оказаться дорогостоящими, составляя до 80 процентов общей стоимости разработки программного обеспечения.
Независимый [ править ]
Независимая проверка и валидация программного обеспечения (ISVV) ориентирована на критически важные для безопасности программные системы и направлена на повышение качества программных продуктов, тем самым снижая риски и затраты на протяжении всего срока эксплуатации программного обеспечения. Цель ISVV — обеспечить уверенность в том, что программное обеспечение работает с заданным уровнем уверенности, в пределах заданных параметров и определенных требований. [5] [6]
Деятельность ISVV осуществляется независимыми инженерными группами, не участвующими в процессе разработки программного обеспечения, для оценки процессов и конечных продуктов. Независимость команды ISVV осуществляется на трех разных уровнях: финансовом, управленческом и техническом.
ISVV выходит за рамки «традиционных» методов проверки и проверки, применяемых командами разработчиков. В то время как последний направлен на обеспечение хорошей работы программного обеспечения в соответствии с номинальными требованиями, ISVV фокусируется на нефункциональных требованиях, таких как надежность и надежность, а также на условиях, которые могут привести к сбою программного обеспечения.
Результаты и выводы ISVV передаются командам разработчиков для исправления и улучшения.
История [ править ]
ISVV основан на применении IV&V (независимой проверки и валидации) к программному обеспечению. Раннее применение ISVV (как известно сегодня) относится к началу 1970-х годов, когда армия США спонсировала первую значительную программу, связанную с IV&V для системы противоракетной обороны Safeguard . [7] Другим примером является программа НАСА IV&V, созданная в 1993 году. [8]
К концу 1970-х годов IV&V быстро стала популярной. Постоянное увеличение сложности, размера и важности программного обеспечения привело к увеличению спроса на IV&V, применяемое к программному обеспечению.
Между тем, IV&V (и ISVV для программных систем) консолидировалась и теперь широко используется такими организациями, как Министерство обороны , Федеральное управление гражданской авиации (FAA ), [9] НАСА [8] и ЕКА . [10] IV&V упоминается в DO-178B , ISO/IEC 12207 и формализовано в IEEE 1012 .
В ЕКА [ править ]
Первоначально в 2004-2005 годах европейский консорциум во главе с Европейским космическим агентством в составе DNV , Critical Software SA , Terma и CODA SciSys plc создал первую версию руководства, посвященного ISVV, под названием «Руководство ESA по независимой проверке и валидации». "при поддержке других организаций. [11] В этом руководстве рассматриваются методологии, применимые на всех этапах разработки программного обеспечения, касающихся ISVV.
В 2008 году Европейское космическое агентство выпустило вторую версию, получив предложения от многих различных европейских заинтересованных сторон ISVV в области космоса. [11]
Методология [ править ]
ISVV обычно состоит из пяти основных этапов, эти этапы могут выполняться последовательно или в результате процесса адаптации.
Планирование [ править ]
- Планирование деятельности ISVV
- Анализ критичности системы: идентификация критических компонентов с помощью комплекса мероприятий RAMS (соотношение цены и качества)
- Выбор подходящих методов и инструментов
Проверка требований [ править ]
- Проверка на предмет: полноты, правильности, тестируемости.
Проверка проекта [ править ]
- Адекватность дизайна и соответствие требованиям к программному обеспечению и интерфейсам
- Внутренняя и внешняя согласованность
- Проверка осуществимости и техническое обслуживание
Проверка кода [ править ]
- Проверка на предмет: полноты, правильности, последовательности.
- метрик кода Анализ
- стандартам кодирования Проверка соответствия
Проверка [ править ]
- Идентификация нестабильных компонентов/функций
- Валидация ориентирована на обработку ошибок: дополнительная (не одновременная) проверка, выполняемая командой разработчиков.
- Соответствие программным и системным требованиям.
- Методы тестирования «черного ящика» и тестирования белого ящика» « методы
- Техники, основанные на опыте
Нормативно-правовая база [ править ]
Программное обеспечение часто должно соответствовать требованиям законодательно регулируемых отраслей, которыми часто руководствуются государственные органы. [12] [13] или промышленные административные органы. Например, FDA версий программного обеспечения и исправлений . требует проверки [14]
См. также [ править ]
- Корректность компилятора
- Перекрестная проверка
- Формальная проверка
- Функциональная спецификация
- Независимый центр проверки и валидации
- Международный квалификационный совет по тестированию программного обеспечения
- Проверка программного обеспечения
- Спецификация требований к программному обеспечению
- Валидация (производство лекарств)
- Верификация и валидация – Общие сведения
- Верификация и валидация компьютерных имитационных моделей
- Независимые системы проверки
- Тестирование программного обеспечения
- Программная инженерия
- Качество программного обеспечения
- Статический анализ кода
- Разработка требований
- Критическая система безопасности
- Независимый центр проверки и валидации Кэтрин Джонсон
Дальнейшее чтение [ править ]
- 1012-2012 Стандарт IEEE для проверки и валидации систем и программного обеспечения . 2012. doi : 10.1109/IEESTD.2012.6204026 . ISBN 978-0-7381-7268-2 .
- Тран, Э. (1999). «Верификация/Валидация/Сертификация» . Купман, П. (ред.). Темы «Надежные встраиваемые системы» . Университет Карнеги Меллон . Проверено 18 мая 2007 г.
- Мензис, Т.; Ю. Ху (2003). «Интеллектуальный анализ данных для очень занятых людей». Компьютер . 36 (1): 22–29. дои : 10.1109/MC.2003.1244531 .
Внешние ссылки [ править ]
- Глава о качестве программного обеспечения (включая VnV). Архивировано 8 декабря 2014 г. на Wayback Machine в SWEBOK.
Ссылки [ править ]
- ^ Фам, Х. (1999). Надежность программного обеспечения . John Wiley & Sons, Inc. с. 567. ИСБН 9813083840 .
Проверка программного обеспечения. Процесс проверки того, что программное обеспечение выполняет правильный процесс. Проверка программного обеспечения. Процесс проверки того, что программное обеспечение выполняет процесс правильно». Аналогично и здесь: «Короче говоря, Бем (3) выразил разницу между проверкой программного обеспечения и проверкой программного обеспечения следующим образом: Верификация: Правильно ли мы создаем продукт? Проверка: создаем ли мы правильный продукт? .
- ^ Снодерли, Джон; Фейзандье, Алан. «Проверка системы» . ИСО/МЭК/ИИЭР 15288 . Архивировано из оригинала 26 июня 2023 года . Проверено 18 мая 2022 г.
- ^ «CMMI для разработки программного обеспечения, версия 1.1, поэтапное представление (CMMI-SW, V1.1, поэтапное)» . resources.sei.cmu.edu . Проверено 20 марта 2021 г.
- ^ Перейти обратно: а б с Документация Министерства обороны по проверке, валидации и аккредитации (VV&A) для моделей и моделирования , Агентство противоракетной обороны, 2008 г.
- ^ Роджерс, Р. (26 октября 1981 г.). «Планирование независимой проверки и валидации программного обеспечения» . 3-я конференция «Компьютеры в аэрокосмической отрасли» . Компьютеры в аэрокосмической конференции. Сан-Диего, Калифорния, США: Американский институт аэронавтики и астронавтики. дои : 10.2514/6.1981-2100 .
- ^ Амбросио, Ана; Маттиелло-Франциско, Фатима; Мартинс, Элиан (12 мая 2008 г.). «Независимый процесс проверки и валидации программного обеспечения для космических приложений» . Конференция SpaceOps 2008 . Гейдельберг, Германия: Американский институт аэронавтики и астронавтики. дои : 10.2514/6.2008-3517 . ISBN 978-1-62410-167-0 .
- ^ Льюис, Роберт О. (1992). Независимая проверка и валидация: процесс проектирования жизненного цикла качественного программного обеспечения . Нью-Йорк: Уайли. ISBN 0-471-57011-7 . OCLC 74908695 .
- ^ Перейти обратно: а б Эсбери, Майкл (9 марта 2015 г.). «О программе НАСА IV&V» . НАСА . Проверено 20 марта 2021 г.
- ^ Балчи, О. (2010). «Золотые правила проверки, валидации, тестирования и сертификации приложений моделирования». S2CID 61476570 .
{{cite web}}: Отсутствует или пусто|url=( помощь ) - ^ «Секция летных программных систем (TEC-SWF)» . www.esa.int . Проверено 20 марта 2021 г.
- ^ Перейти обратно: а б лавва.пт. «Новое руководство ISVV по космосу в разработке» . www.criticalsoftware.com . Проверено 20 марта 2021 г.
- ^ «Общие принципы проверки программного обеспечения; Заключительное руководство для представителей промышленности и персонала FDA» (PDF) . Управление по контролю за продуктами и лекарствами . 11 января 2002 года . Проверено 12 июля 2009 г.
- ^ «Руководство для промышленности: Часть 11, Электронные записи; Электронные подписи. Область применения и применение» (PDF) . Управление по контролю за продуктами и лекарствами . Август 2003 года . Проверено 12 июля 2009 г.
- ^ «Руководство для промышленности: кибербезопасность сетевых медицинских устройств, содержащих стандартное программное обеспечение (OTS)» (PDF) . Управление по контролю за продуктами и лекарствами . 14 января 2005 года . Проверено 12 июля 2009 г.
Примечания [ править ]
- ^ Термин верификация часто ассоциируется с термином валидация и понимается как единое понятие V&V . Валидация используется для того, чтобы убедиться, что человек решает правильную задачу , тогда как верификация используется для того, чтобы убедиться, что проблема решена правильно (Мартин, 1997). В фактическом и этимологическом значении термин «проверка» происходит от латинского verus , что означает «истина», и facere , что означает «делать/выполнять». Таким образом, проверка означает доказательство того, что что-то истинно или правильно (свойство, характеристика и т. д.). Термин «валидация» происходит от латинского « valere» , что означает «стать сильным», и имеет тот же этимологический корень, что и слово « ценность» . Таким образом, валидация означает доказательство того, что что-то обладает характеристиками, необходимыми для достижения ожидаемых результатов. (Адаптировано из книги «Проверка и подтверждение на простом английском языке» (Lake INCOSE, 1999). [2]
