Проверка и проверка программного обеспечения - Software verification and validation

IEEE жизненный цикл программного обеспечения

В управление программными проектами, тестирование программного обеспечения, и программная инженерия, верификация и валидация (V&V) - это процесс проверки того, что программная система соответствует спецификациям и соответствует своему назначению. Его также можно назвать контроль качества программного обеспечения. Обычно это ответственность тестеры программного обеспечения как часть жизненный цикл разработки программного обеспечения. Проще говоря, проверка программного обеспечения - это: «Предполагая, что мы должны создать X, достигает ли наше программное обеспечение своих целей без каких-либо ошибок или пробелов?» С другой стороны, проверка программного обеспечения заключается в следующем: «Был ли X тем, что мы должны были создать? Соответствует ли X требованиям высокого уровня?»

Определения

Верификация и валидация - это не одно и то же, хотя их часто путают. Бем лаконично выразил разницу как[1]

  • Проверка: правильно ли мы создаем продукт?
  • Валидация: создаем ли мы правильный продукт?

"Правильное создание продукта" проверяет, что технические характеристики правильно реализованы системой, в то время как «создание правильного продукта» относится к потребности пользователя. В некоторых контекстах требуются письменные требования как к формальным процедурам, так и к протоколам для определения соответствия.

Правильное построение продукта подразумевает использование Спецификации требований в качестве входных данных для следующего этапа процесса разработки, процесса проектирования, результатом которого является Спецификация проектирования. Кроме того, это также подразумевает использование Спецификации проекта для поддержки процесса строительства. Каждый раз, когда на выходе процесса правильно реализуется его входная спецификация, программный продукт становится на шаг ближе к окончательной проверке. Если результат процесса неверен, разработчики не создают продукт, который нужен заинтересованным сторонам. Этот вид проверки называется «проверкой артефакта или спецификации».

Создание правильного продукта подразумевает создание Спецификации требований, которая содержит потребности и цели заинтересованных сторон программного продукта. Если такой артефакт неполный или неправильный, разработчики не смогут создать продукт, который хотят заинтересованные стороны. Это форма «проверки артефакта или спецификации».

Примечание. Проверка начинается перед проверкой, а затем они выполняются параллельно до выпуска программного продукта.[требуется разъяснение ]

Проверка программного обеспечения

Это означало бы проверить соответствие спецификациям, запустив программное обеспечение, но это невозможно (например, как кто-нибудь может узнать, правильно ли реализована архитектура / дизайн / и т. Д. При запуске программного обеспечения?). Только просмотрев связанные с ним артефакты, кто-то может сделать вывод, соответствуют ли спецификации.

Проверка артефакта или спецификации

Выходные данные каждой стадии процесса разработки программного обеспечения также могут быть предметом проверки при проверке на соответствие входной спецификации (см. Определение CMMI ниже).

Примеры проверки артефактов:

  • Относительно проектной спецификации к спецификации требований: правильно ли архитектурный проект, подробный проект и спецификации логической модели базы данных реализуют функциональные и нефункциональные спецификации требований?
  • Об артефактах конструкции, противоречащих спецификации проекта: правильно ли исходный код, пользовательские интерфейсы и физическая модель базы данных реализуют спецификацию проекта?

Проверка программного обеспечения

Валидация программного обеспечения проверяет, что программный продукт удовлетворяет или подходит для предполагаемого использования (проверка высокого уровня), т.е.программное обеспечение соответствует требованиям пользователя, а не как артефакты спецификации или как потребности тех, кто будет использовать программное обеспечение только; но, как потребности всех заинтересованных сторон (таких как пользователи, операторы, администраторы, менеджеры, инвесторы и т. д.). Есть два способа выполнить проверку программного обеспечения: внутренний и внешний. Во время внутренней проверки программного обеспечения предполагается, что цели заинтересованных сторон были правильно поняты и что они были точно и всесторонне выражены в артефактах требований. Если программное обеспечение соответствует спецификации требований, оно прошло внутреннюю валидацию. Внешняя проверка происходит, когда она выполняется путем опроса заинтересованных сторон, соответствует ли программное обеспечение их потребностям. Различные методологии разработки программного обеспечения требуют разных уровней участия и обратной связи со стороны пользователей и заинтересованных сторон; Итак, внешняя проверка может быть дискретным или непрерывным событием. Успешная окончательная внешняя валидация происходит, когда все заинтересованные стороны принимают программный продукт и заявляют, что он удовлетворяет их потребности. Такая окончательная внешняя проверка требует использования вступительный тест который является динамический тест.

Тем не менее, также можно выполнить внутренние статические тесты, чтобы выяснить, соответствует ли он требованиям спецификации, но это относится к сфере статической проверки, поскольку программное обеспечение не работает.

Проверка артефакта или спецификации

Требования должны быть подтверждены до того, как программный продукт в целом будет готов (процесс каскадной разработки требует, чтобы они были полностью определены до начала проектирования; но для итеративных процессов разработки это не требуется и позволяет их непрерывное улучшение).

Примеры проверки артефактов:

  • Проверка спецификации требований пользователя: требования пользователя, изложенные в документе под названием «Спецификация требований пользователя», проверяются путем проверки, действительно ли они отражают волю и цели заинтересованных сторон. Это можно сделать, опросив их и спросив их напрямую (статическое тестирование) или даже выпуская прототипы и попросив пользователей и заинтересованных лиц оценить их (динамическое тестирование).
  • Проверка пользовательского ввода: пользовательский ввод (собранный любым периферийным устройством, таким как клавиатура, биометрический датчик и т. Д.) подтверждено проверяя, соответствуют ли входные данные, предоставленные операторами или пользователями программного обеспечения, правилам и ограничениям домена (таким как тип данных, диапазон и формат).

Проверка и проверка

Согласно Модель зрелости возможностей (CMMI-SW v1.1),

  • Проверка программного обеспечения: процесс оценки программного обеспечения во время или в конце процесса разработки, чтобы определить, удовлетворяет ли оно указанным требованиям. [IEEE-STD-610]
  • Проверка программного обеспечения: процесс оценки программного обеспечения для определения того, удовлетворяют ли продукты данной фазы разработки условиям, установленным в начале этой фазы. [IEEE-STD-610]

Валидацию в процессе разработки программного обеспечения можно рассматривать как форму валидации Спецификации требований пользователя; и что в конце процесса разработки это эквивалентно внутренней и / или внешней проверке программного обеспечения. Верификация, с точки зрения CMMI, явно артефактная.

Другими словами, проверка программного обеспечения гарантирует, что выходные данные каждой фазы процесса разработки программного обеспечения эффективно выполняют то, что указывает соответствующий входной артефакт (требование -> дизайн -> программный продукт), в то время как проверка программного обеспечения гарантирует, что программный продукт соответствует потребностям все заинтересованные стороны (следовательно, техническое задание было изначально правильно и точно выражено). Проверка программного обеспечения гарантирует, что «вы построили его правильно», и подтверждает, что предоставленный продукт соответствует планам разработчиков. Проверка программного обеспечения гарантирует, что «вы создали правильную вещь», и подтверждает, что продукт в том виде, в котором он был предоставлен, соответствует предполагаемому использованию и целям заинтересованных сторон.

В этой статье используется строгий или узкий определение проверки.

С точки зрения тестирования:

  • Неисправность - неправильная или отсутствующая функция в коде.
  • Неудача - проявление неисправности при исполнении. Программное обеспечение не было эффективным. Он не делает того, «что» должен делать.
  • Неисправность - согласно спецификации система не соответствует заданной функциональности. Программное обеспечение было неэффективным (требовалось слишком много ресурсов, таких как циклы ЦП, использовалось слишком много памяти, выполнялось слишком много операций ввода-вывода и т. Д.), Его нельзя было использовать, оно было ненадежным и т. Д. что-то «как» он должен это делать.

Связанные понятия

И верификация, и валидация связаны с концепциями качественный и из Гарантия качества программного обеспечения. Сами по себе проверка и валидация не гарантируют качества программного обеспечения; планирование прослеживаемость, требуется управление конфигурацией и другие аспекты разработки программного обеспечения.

В рамках моделирование и симуляция (M&S), определения верификации, валидации и аккредитации аналогичны:

  • M&S Verification - это процесс определения того, что компьютерная модель, моделирование или объединение моделей и реализаций имитаций и связанных с ними данных точно представляют концептуальное описание и спецификации разработчика.[2]
  • M&S Validation - это процесс определения степени, в которой модель, имитация или объединение моделей и имитаций и связанных с ними данных являются точными представлениями реального мира с точки зрения предполагаемого использования.[2]
  • Аккредитация это формальное свидетельство того, что модель или симуляция приемлемы для использования в определенных целях.[2]

Определение валидации модели и модели фокусируется на точности, с которой модель модели и модели представляет предполагаемое использование в реальном мире. Определение степени точности модели и моделирования требуется, поскольку все модели и модели являются приближениями к реальности, и обычно очень важно определить, является ли степень приближения приемлемой для предполагаемого использования. Это контрастирует с проверкой программного обеспечения.

Классификация методов

В критически важный программные системы, где безупречная работа абсолютно необходима, формальные методы может использоваться для обеспечения правильной работы системы.[3] Однако эти формальные методы могут оказаться дорогостоящими и составляют до 80% от общей стоимости разработки программного обеспечения.[4]

Тестовые примеры

Основная статья: Прецедент

Тестовый пример - это инструмент, используемый в процессе. Тестовые примеры могут быть подготовлены для проверки программного обеспечения и проверки программного обеспечения, чтобы определить, был ли продукт построен в соответствии с требованиями пользователя. Другие методы, такие как обзоры, могут использоваться на ранних этапах жизненного цикла для обеспечения валидации программного обеспечения.

Независимая проверка и подтверждение

ISVV означает Независимая проверка и проверка программного обеспечения. ISVV ориентирован на критически важные для безопасности программного обеспечения систем и направлен на повышение качества программных продуктов, тем самым снижая риски и затраты на протяжении всего срока службы программного обеспечения. ISVV обеспечивает уверенность в том, что программное обеспечение работает с заданным уровнем уверенности, в рамках своих проектных параметров и определенных требований.

Действия ISVV выполняются независимыми инженерными группами, не участвующими в процессе разработки программного обеспечения, для оценки процессов и конечных продуктов. Независимость команды ISVV осуществляется на трех разных уровнях: финансовом, управленческом и техническом.

ISVV выходит далеко за рамки «традиционных» методов проверки и валидации, применяемых командами разработчиков. В то время как последние нацелены на обеспечение хорошей работы программного обеспечения в соответствии с номинальными требованиями, ISVV сосредоточен на нефункциональных требованиях, таких как устойчивость и надежность, а также на условиях, которые могут привести к сбою программного обеспечения. Результаты и выводы ISVV передаются командам разработчиков для исправления и улучшения.

История ISVV

ISVV является производным от применения IV&V (независимой проверки и подтверждения) к программному обеспечению. Раннее приложение ISVV (известное сегодня) восходит к началу 1970-х годов, когда Армия США спонсировал первую значительную программу, связанную с IV&V для Safeguard Противоракетная ракета Система.

К концу 1970-х годов IV&V быстро стал популярным. Постоянное увеличение сложности, размера и важности программного обеспечения приводит к увеличению спроса на IV&V, применяемые к программному обеспечению (ISVV).

Между тем, IV&V (и ISVV для программных систем) консолидируются и теперь широко используются такими организациями, как DoD, FAA, НАСА и ЕКА. IV&V упоминается в DO-178B, ISO / IEC 12207 и оформлено в IEEE 1012.

Первоначально в 2004-2005 годах европейский консорциум во главе с Европейское космическое агентство, и состоит из DNV, Critical Software SA, Terma и CODA SciSys plc создал первую версию руководства, посвященного ISVV, под названием «Руководство ESA по независимой проверке и валидации» при поддержке других организаций, например SoftWcare SL,[5] и Т. Д.

В 2008 году Европейское космическое агентство выпустило вторую версию, SoftWcare SL был вспомогательным редактором, получив комментарии от многих различных заинтересованных сторон European Space ISVV. В этом руководстве описаны методологии, применимые ко всем этапам разработки программного обеспечения в том, что касается ISVV.

Методология ISVV

ISVV обычно состоит из пяти основных фаз, которые могут выполняться последовательно или как результат процесса адаптации.

Планирование ISVV

  • Планирование деятельности ISVV
  • Анализ критичности системы: идентификация критических компонентов с помощью набора действий RAMS (соотношение цены и качества)
  • Выбор подходящих методов и инструментов

Проверка требований

  • Проверка на полноту, правильность, тестируемость

Проверка дизайна

  • Адекватность дизайна и соответствие требованиям к программному обеспечению и интерфейсам
  • Внутренняя и внешняя согласованность
  • Проверка выполнимости и техническое обслуживание

Проверка кода

  • Проверка на полноту, правильность, согласованность
  • Анализ метрик кода
  • Проверка соответствия стандартам кодирования

Проверка

  • Выявление нестабильных компонентов / функций
  • Валидация сосредоточена на обработке ошибок: дополнительная (не одновременная!) Валидация в отношении той, которая выполняется командой разработчиков (больше за деньги, больше пока)
  • Соответствие программным и системным требованиям
  • Тестирование черного ящика и Тестирование белого ящика техники
  • Техники, основанные на опыте

Нормативно-правовая база

Верификация и валидация должны соответствовать требованиям регулируемых законодательством отраслей, которыми часто руководствуются государственные органы.[6][7] или промышленные административные органы. Например, FDA требует версий программного обеспечения и патчи подлежит проверке.[8]

Смотрите также

Примечания и ссылки

  1. ^ Фам, Х. (1999). Надежность программного обеспечения. John Wiley & Sons, Inc. стр. 567. ISBN  9813083840. Проверка программного обеспечения. Процесс обеспечения правильного выполнения программным обеспечением. Проверка программного обеспечения. Процесс обеспечения того, чтобы программное обеспечение правильно выполняло процесс ». Точно так же и здесь:« Вкратце, Бём (3) выразил разницу между проверкой программного обеспечения и валидацией программного обеспечения следующим образом: Проверка: «Правильно ли мы создаем продукт ? '' Валидация: '' Создаем ли мы правильный продукт? ''.
  2. ^ а б c «Документация Министерства обороны по проверке, валидации и аккредитации (VV&A) для моделей и симуляций». Агентство противоракетной обороны. 2008 г. Цитировать журнал требует | журнал = (помощь)
  3. ^ Wang, C.-W .; Ostroff, J.S .; Худон, С. (2014). «Точная документация и подтверждение требований». In Artho, C .; Ölveczky, P.C. (ред.). Формальные методы для систем, критических для безопасности. Springer. С. 262–279. ISBN  9783319054162. Получено 18 мая 2018.
  4. ^ Купман, П. "Надежность, безопасность и защищенность в повседневных встроенных системах". В Bondavelli, A .; Brasileiro, F .; Rajsbaum, S. (ред.). Надежные вычисления. Springer. Дои:10.1007/978-3-540-75294-3_1. ISBN  978-3-540-75294-3.
  5. ^ Веб-сайт SoftWcare SL
  6. ^ «Общие принципы валидации программного обеспечения; Окончательное руководство для сотрудников отрасли и FDA» (PDF). Управление по контролю за продуктами и лекарствами. 11 января 2002 г.. Получено 12 июля 2009.
  7. ^ «Руководство для промышленности: часть 11, Электронные записи; электронные подписи - сфера применения и применение» (PDF). Управление по контролю за продуктами и лекарствами. Август 2003 г.. Получено 12 июля 2009.
  8. ^ «Руководство для промышленности: кибербезопасность сетевых медицинских устройств, содержащих готовое программное обеспечение (OTS)» (PDF). Управление по контролю за продуктами и лекарствами. 14 января 2005 г.. Получено 12 июля 2009.

внешняя ссылка