В управлении программными проектами , тестировании программного обеспечения и программной инженерии верификация и валидация — это процесс проверки того, что система инженера-программиста соответствует спецификациям и требованиям, чтобы она соответствовала своему назначению. Это также может называться контролем качества программного обеспечения . Обычно это ответственность тестировщиков программного обеспечения как часть жизненного цикла разработки программного обеспечения . Проще говоря, верификация программного обеспечения заключается в следующем: «Предполагая, что мы должны построить X, достигает ли наше программное обеспечение своих целей без каких-либо ошибок или пробелов?» С другой стороны, валидация программного обеспечения заключается в следующем: «Было ли X тем, что мы должны были построить? Соответствует ли X требованиям высокого уровня?»
Верификация и валидация — это не одно и то же, хотя их часто путают. Бём лаконично выразил разницу следующим образом: [1]
«Создание правильного продукта» проверяет, что спецификации правильно реализованы системой, в то время как «создание правильного продукта» отсылает к потребностям пользователя . В некоторых контекстах требуется наличие письменных требований для обоих, а также формальных процедур или протоколов для определения соответствия. В идеале формальные методы обеспечивают математическую гарантию того, что программное обеспечение соответствует своим спецификациям.
Правильное построение продукта подразумевает использование спецификации требований в качестве входных данных для следующего этапа процесса разработки, процесса проектирования, выходом которого является спецификация проектирования. Затем, это также подразумевает использование спецификации проектирования для подачи процесса строительства. Каждый раз, когда выход процесса правильно реализует его входную спецификацию, программный продукт становится на один шаг ближе к окончательной проверке. Если выход процесса неверен, разработчики неправильно реализовали какой-то компонент этого процесса. Этот вид проверки называется «проверкой артефакта или спецификации».
Это подразумевало бы проверку соответствия спецификациям путем запуска программного обеспечения, но это невозможно (например, как кто-либо может узнать, правильно ли реализованы архитектура/дизайн/и т. д. путем запуска программного обеспечения?). Только путем просмотра связанных с ним артефактов можно сделать вывод о соответствии спецификациям.
Выходные данные каждого этапа процесса разработки программного обеспечения также могут быть подвергнуты проверке путем сверки с их входными спецификациями (см. определение CMMI ниже).
Примеры проверки артефактов:
Валидация программного обеспечения проверяет, удовлетворяет ли программный продукт предполагаемому использованию или подходит ли он ему (высокоуровневая проверка), т. е. программное обеспечение соответствует требованиям пользователя, а не только как артефактам спецификации или потребностям тех, кто будет эксплуатировать программное обеспечение; но как потребностям всех заинтересованных сторон (таких как пользователи, операторы, администраторы, менеджеры, инвесторы и т. д.). Существует два способа проведения валидации программного обеспечения: внутренняя и внешняя. Во время внутренней валидации программного обеспечения предполагается, что цели заинтересованных сторон были правильно поняты и что они были выражены в артефактах требований точно и всесторонне. Если программное обеспечение соответствует спецификации требований, оно прошло внутреннюю валидацию. Внешняя валидация происходит, когда она выполняется путем опроса заинтересованных сторон, соответствует ли программное обеспечение их потребностям. Различные методологии разработки программного обеспечения требуют разных уровней участия пользователей и заинтересованных сторон и обратной связи; поэтому внешняя валидация может быть дискретным или непрерывным событием. Успешная окончательная внешняя валидация происходит, когда все заинтересованные стороны принимают программный продукт и выражают, что он удовлетворяет их потребностям. Такая окончательная внешняя валидация требует использования приемочного теста , который является динамическим тестом .
Тем не менее, также возможно провести внутренние статические тесты, чтобы выяснить, соответствует ли программное обеспечение требованиям спецификации, но это попадает в область статической проверки, поскольку программное обеспечение не запущено.
Требования должны быть проверены до того, как программный продукт будет готов в целом (каскадный процесс разработки требует, чтобы они были идеально определены до начала проектирования; но итеративные процессы разработки не требуют этого и допускают их постоянное совершенствование).
Примеры проверки артефактов:
Согласно модели зрелости возможностей (CMMI-SW v1.1), [2]
Валидацию в процессе разработки ПО можно рассматривать как форму валидации спецификации требований пользователя; и, что в конце процесса разработки эквивалентно внутренней и/или внешней валидации ПО. Верификация, с точки зрения CMMI, очевидно, относится к артефактному типу.
Другими словами, верификация программного обеспечения гарантирует, что выход каждой фазы процесса разработки программного обеспечения эффективно выполняет то, что указывает соответствующий артефакт ввода (требование -> проектирование -> программный продукт), в то время как валидация программного обеспечения гарантирует, что программный продукт соответствует потребностям всех заинтересованных сторон (следовательно, спецификация требований была правильно и точно выражена изначально). Верификация программного обеспечения гарантирует, что «вы построили его правильно» и подтверждает, что продукт, как он предоставлен, соответствует планам разработчиков. Валидация программного обеспечения гарантирует, что «вы построили правильную вещь» и подтверждает, что продукт, как он предоставлен, соответствует предполагаемому использованию и целям заинтересованных сторон.
В данной статье использовано строгое или узкое определение верификации.
С точки зрения тестирования:
И верификация, и валидация связаны с концепциями качества и обеспечения качества программного обеспечения . Сами по себе верификация и валидация не гарантируют качество программного обеспечения; необходимы планирование, прослеживаемость , управление конфигурацией и другие аспекты разработки программного обеспечения.
В сообществе специалистов по моделированию и имитации (M&S) определения верификации, валидации и аккредитации схожи:
Определение валидации M&S фокусируется на точности, с которой M&S представляет реальное предполагаемое использование(я). Определение степени точности M&S необходимо, поскольку все M&S являются приближениями реальности, и обычно важно определить, приемлема ли степень приближения для предполагаемого использования(й). Это контрастирует с валидацией программного обеспечения.
В критически важных программных системах формальные методы могут использоваться для обеспечения корректной работы системы. Однако эти формальные методы могут оказаться дорогостоящими, составляя до 80 процентов от общей стоимости разработки программного обеспечения.
Независимая проверка и валидация программного обеспечения (ISVV) нацелена на критически важные для безопасности программные системы и направлена на повышение качества программных продуктов, тем самым снижая риски и затраты на протяжении всего срока эксплуатации программного обеспечения. Цель ISVV — предоставить гарантию того, что программное обеспечение работает на указанном уровне уверенности и в пределах его проектных параметров и определенных требований. [4] [5]
Деятельность ISVV выполняется независимыми инженерными командами, не вовлеченными в процесс разработки программного обеспечения, для оценки процессов и полученных продуктов. Независимость команды ISVV осуществляется на трех различных уровнях: финансовом, управленческом и техническом.
ISVV выходит за рамки «традиционных» методов верификации и валидации, применяемых командами разработчиков. В то время как последний направлен на обеспечение того, чтобы программное обеспечение хорошо работало в соответствии с номинальными требованиями, ISVV фокусируется на нефункциональных требованиях, таких как надежность и прочность, а также на условиях, которые могут привести к сбою программного обеспечения.
Результаты и выводы ISVV передаются обратно группам разработчиков для исправления и улучшения.
ISVV происходит от применения IV&V (независимая проверка и валидация) к программному обеспечению. Раннее применение ISVV (как известно сегодня) относится к началу 1970-х годов, когда армия США спонсировала первую значительную программу, связанную с IV&V для системы противоракетной обороны Safeguard . [6] Другим примером является программа IV&V NASA, которая была создана в 1993 году. [7]
К концу 1970-х годов IV&V быстро становился популярным. Постоянное увеличение сложности, размера и важности программного обеспечения привело к увеличению спроса на IV&V, применяемое к программному обеспечению.
Между тем, IV&V (и ISVV для программных систем) консолидировались и теперь широко используются такими организациями, как DoD , FAA , [8] NASA [7] и ESA . [9] IV&V упоминается в DO-178B , ISO/IEC 12207 и формализован в IEEE 1012 .
Первоначально в 2004-2005 годах европейский консорциум во главе с Европейским космическим агентством , в состав которого входили DNV , Critical Software SA , Terma и CODA SciSys plc, при поддержке других организаций создал первую версию руководства, посвященного ISVV, под названием «Руководство ESA по независимой верификации и валидации». [10] В этом руководстве рассматриваются методологии, применимые ко всем этапам разработки программного обеспечения в том, что касается ISVV.
В 2008 году Европейское космическое агентство выпустило вторую версию, получив вклад от многих заинтересованных сторон Европейского космического ISVV. [10]
ISVV обычно состоит из пяти основных этапов, которые могут выполняться последовательно или в результате процесса адаптации.
Программное обеспечение часто должно соответствовать требованиям соответствия юридически регулируемых отраслей, которые часто направляются государственными агентствами [11] [12] или промышленными административными органами. Например, FDA требует, чтобы версии программного обеспечения и исправления были проверены. [13]
Валидация программного обеспечения. Процесс обеспечения того, чтобы программное обеспечение выполняло правильный процесс. Проверка программного обеспечения. Процесс обеспечения того, чтобы программное обеспечение выполняло процесс правильно». Аналогично и там же: «Короче говоря, Бём (3) выразил разницу между проверкой программного обеспечения и валидацией программного обеспечения следующим образом: Проверка: Правильно ли мы создаем продукт? Валидация: Правильно ли мы создаем продукт? .
{{cite web}}: Отсутствует или пусто |url=( помощь )