Из Википедии, бесплатной энциклопедии
Перейти к навигации Перейти к поиску
Жизненный цикл программного обеспечения IEEE

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

Определения [ править ]

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Проверка и проверка [ править ]

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

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

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

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

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

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

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

Понятия, связанные с данным [ править ]

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

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

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

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

V&V методы [ править ]

Формально [ править ]

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

Независимый [ править ]

Независимая проверка и проверка программного обеспечения (ISVV) нацелена на критически важные для безопасности программные системы и направлена ​​на повышение качества программных продуктов, тем самым снижая риски и затраты на протяжении всего срока эксплуатации программного обеспечения. Целью ISVV является обеспечение уверенности в том, что программное обеспечение работает с заданным уровнем уверенности, в пределах его заданных параметров и определенных требований. [4] [5]

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

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

Результаты и выводы ISVV возвращаются командам разработчиков для исправления и улучшения.

История [ править ]

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

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

Между тем, IV&V (и ISVV для программных систем) консолидируются и теперь широко используются такими организациями, как Министерство обороны , 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 году Европейское космическое агентство выпустило вторую версию, полученную от многих различных заинтересованных сторон European Space ISVV. [10]

Методология [ править ]

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

Планирование [ править ]

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

Проверка требований [ править ]

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

Проверка дизайна [ править ]

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

Проверка кода [ править ]

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

Проверка [ править ]

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

Нормативная среда [ править ]

Программное обеспечение часто должно соответствовать требованиям регулируемых законодательством отраслей, которыми часто руководят государственные органы [11] [12] или промышленные административные органы. Например, FDA требует проверки версий программного обеспечения и исправлений . [13]

См. Также [ править ]

  • Корректность компилятора
  • Перекрестная проверка
  • Формальная проверка
  • Функциональная спецификация
  • Средство независимой проверки и валидации
  • Международная квалификационная комиссия по тестированию программного обеспечения
  • Проверка программного обеспечения
  • Спецификация требований к программному обеспечению
  • Валидация (производство лекарств)
  • Проверка и валидация - Общие
  • Проверка и подтверждение моделей компьютерного моделирования
  • Системы независимой проверки
  • Тестирование программного обеспечения
  • Программная инженерия
  • Качество программного обеспечения
  • Статический анализ кода
  • Разработка требований
  • Система, критичная для безопасности
  • Кэтрин Джонсон Независимая служба проверки и валидации

Дальнейшее чтение [ править ]

  • 1012-2012 Стандарт IEEE для проверки и валидации системы и программного обеспечения . 2012. DOI : 10,1109 / IEEESTD.2012.6204026 . ISBN 978-0-7381-7268-2.
  • Тран, Э. (1999). «Проверка / Подтверждение / Сертификация» . В Купман, П. (ред.). Темы в надежных встроенных системах . Университет Карнеги-Меллона . Проверено 18 мая 2007 .
  • Menzies, T .; Ю. Ху (2003). «Интеллектуальный анализ данных для очень занятых людей». Компьютер . 36 (1): 22–29. DOI : 10,1109 / MC.2003.1244531 .

Внешние ссылки [ править ]

  • Глава о качестве программного обеспечения (включая VnV) в SWEBOK

Ссылки [ править ]

  1. Перейти ↑ Pham, H. (1999). Надежность программного обеспечения . John Wiley & Sons, Inc. стр. 567. ISBN 9813083840. Проверка программного обеспечения. Процесс обеспечения того, чтобы программное обеспечение выполняло правильный процесс. Проверка программного обеспечения. Процесс обеспечения того, чтобы программное обеспечение правильно выполняло процесс ». Точно так же и здесь:« Вкратце, Бём (3) выразил разницу между проверкой программного обеспечения и валидацией программного обеспечения следующим образом: Проверка: «Правильно ли мы создаем продукт? ? '' Валидация: '' Создаем ли мы правильный продукт? ''.
  2. ^ «CMMI для разработки программного обеспечения, версия 1.1, поэтапное представление (CMMI-SW, V1.1, поэтапное)» . resources.sei.cmu.edu . Проверено 20 марта 2021 .
  3. ^ a b c «Документация Министерства обороны о проверке, валидации и аккредитации (VV&A) для моделей и симуляций». Агентство противоракетной обороны. 2008 г. Цитировать журнал требует |journal=( помощь )
  4. ^ Роджерс, Р. (1981-10-26). «Планирование независимой проверки и валидации программного обеспечения» . 3-я конференция "Компьютеры в аэрокосмической отрасли" . Сан-Диего, Калифорния, США: Американский институт аэронавтики и астронавтики. DOI : 10.2514 / 6.1981-2100 .
  5. ^ Амбросио, Ана; Маттиелло-Франсиско, Фатима; Мартинс, Элиан (2008-05-12). «Независимый процесс проверки и подтверждения программного обеспечения для космических приложений» . Конференция SpaceOps 2008 . Гейдельберг, Германия: Американский институт аэронавтики и астронавтики. DOI : 10.2514 / 6.2008-3517 . ISBN 978-1-62410-167-0.
  6. ^ Льюис, Роберт О. (1992). Независимая проверка и валидация: инженерный процесс жизненного цикла качественного программного обеспечения . Нью-Йорк: Вили. ISBN 0-471-57011-7. OCLC  74908695 .
  7. ^ a b Эсбери, Майкл (2015-03-09). «О программе НАСА IV&V» . НАСА . Проверено 20 марта 2021 .
  8. ^ Balci, О. (2010). «Золотые правила верификации, валидации, тестирования и сертификации приложений моделирования и имитационного моделирования» . не определено . Проверено 20 марта 2021 .
  9. ^ "Секция систем программного обеспечения полета (TEC-SWF)" . www.esa.int . Проверено 20 марта 2021 .
  10. ^ a b lavva.pt. «Новое руководство ISVV для космоса в разработке» . www.criticalsoftware.com . Проверено 20 марта 2021 .
  11. ^ «Общие принципы валидации программного обеспечения; Окончательное руководство для промышленности и персонала FDA» (PDF) . Управление по санитарному надзору за качеством пищевых продуктов и медикаментов . 11 января 2002 . Проверено 12 июля 2009 года .
  12. ^ «Руководство для промышленности: Часть 11, Электронные записи; Электронные подписи - Объем и применение» (PDF) . Управление по санитарному надзору за качеством пищевых продуктов и медикаментов . Август 2003 . Проверено 12 июля 2009 года .
  13. ^ «Руководство для промышленности: кибербезопасность для сетевых медицинских устройств, содержащих готовое программное обеспечение (OTS)» (PDF) . Управление по санитарному надзору за качеством пищевых продуктов и медикаментов . 14 января 2005 . Проверено 12 июля 2009 года .