Войти
В управлении проектами программного обеспечения, тестирование программного обеспечения и программное обеспечение инженерная, проверка и валидация (VV ) - это процесс проверки того, что программная система соответствует спецификациям и соответствует своему назначению. Это также может называться контроль качества программного обеспечения. Обычно это входит в обязанности тестировщиков программного обеспечения в рамках жизненного цикла разработки программного обеспечения. Проще говоря, проверка программного обеспечения - это: «Предполагая, что мы должны создать X, достигает ли наше программное обеспечение своих целей без каких-либо ошибок или пробелов?» С другой стороны, проверка программного обеспечения заключается в следующем: «Был ли X тем, что мы должны были создать? Соответствует ли X требованиям высокого уровня?»
Верификация и валидация - это не одно и то же, хотя их часто путают. Бём лаконично выразил разницу как
«Создание продукта правильно» проверяет, что спецификации правильно реализованы системой, в то время как «создание правильного продукта» относится к потребностям пользователя. В некоторых случаях требуется наличие письменных требований как к формальным процедурам, так и к протоколам для определения соответствия.
Создание правильного продукта подразумевает использование Спецификации требований в качестве входных данных для следующего этапа процесса разработки, процесса проектирования, результатом которого является Спецификация дизайна. Кроме того, это также подразумевает использование Спецификации проекта для поддержки процесса строительства. Каждый раз, когда на выходе процесса правильно реализуется его входная спецификация, программный продукт становится на шаг ближе к окончательной проверке. Если результат процесса неверен, разработчики неправильно создают продукт, который хотят заинтересованные стороны. Этот вид проверки называется «проверкой артефакта или спецификации».
Создание правильного продукта подразумевает создание Спецификации требований, которая содержит потребности и цели заинтересованных сторон программного продукта. Если такой артефакт неполный или неправильный, разработчики не смогут создать продукт, который хотят заинтересованные стороны. Это форма «проверки артефакта или спецификации».
Примечание. Проверка начинается перед проверкой, а затем они выполняются параллельно, пока не будет выпущен программный продукт.
Это подразумевает проверку соответствия спецификациям запуск программного обеспечения, но это невозможно (например, как кто-нибудь может узнать, правильно ли реализована архитектура / дизайн / и т. д. при запуске программного обеспечения?). Только просмотрев связанные с ним артефакты, кто-то может сделать вывод, соответствуют ли спецификации.
Выходные данные каждой стадии процесса разработки программного обеспечения также могут быть предметом проверки при проверке на соответствие входной спецификации (см. Определение CMMI ниже).
Примеры проверки артефактов:
Проверка программного обеспечения проверяет, удовлетворяет ли программный продукт или подходит ли он предполагаемое использование (проверка высокого уровня), т. е. программное обеспечение соответствует требованиям пользователя, а не как артефакты спецификации или только как потребности тех, кто будет использовать программное обеспечение; но, как потребности всех заинтересованных сторон (таких как пользователи, операторы, администраторы, менеджеры, инвесторы и т. д.). Есть два способа выполнить проверку программного обеспечения: внутренний и внешний. Во время внутренней проверки программного обеспечения предполагается, что цели заинтересованных сторон были правильно поняты и что они были точно и всесторонне выражены в артефактах требований. Если программное обеспечение соответствует спецификации требований, оно прошло внутреннюю проверку. Внешняя проверка происходит, когда она выполняется путем опроса заинтересованных сторон, соответствует ли программное обеспечение их потребностям. Различные методологии разработки программного обеспечения требуют разных уровней участия и обратной связи со стороны пользователей и заинтересованных сторон; Итак, внешняя проверка может быть дискретным или непрерывным событием. Успешная окончательная внешняя валидация происходит, когда все заинтересованные стороны принимают программный продукт и заявляют, что он удовлетворяет их потребности. Такая окончательная внешняя проверка требует использования приемочного теста, который является динамическим тестом.
. Однако также можно выполнить внутренние статические тесты, чтобы выяснить, соответствует ли он требованиям спецификации, но что попадает в сферу статической проверки, потому что программное обеспечение не запущено.
Требования должны быть проверены до того, как программный продукт в целом будет готов (процесс каскадной разработки требует, чтобы они были полностью определены до начала проектирования; но итеративные процессы разработки это делают не требовать, чтобы это было так, и допускать их постоянное улучшение).
Примеры проверки артефактов:
Согласно модели зрелости возможностей (CMMI-SW v1.1),
Валидация в процессе разработки программного обеспечения может рассматриваться как форма валидации Спецификации требований пользователя; и что в конце процесса разработки это эквивалентно внутренней и / или внешней проверке программного обеспечения. Верификация, с точки зрения CMMI, явно артефактная.
Другими словами, проверка программного обеспечения гарантирует, что выходные данные каждой фазы процесса разработки программного обеспечения эффективно выполняют то, что указывает соответствующий входной артефакт (требование ->дизайн ->программный продукт), в то время как проверка программного обеспечения гарантирует, что программный продукт удовлетворяет потребности всех заинтересованных сторон (следовательно, спецификация требований изначально была правильно и точно выражена). Проверка программного обеспечения гарантирует, что «вы построили его правильно», и подтверждает, что предоставленный продукт соответствует планам разработчиков. Проверка программного обеспечения гарантирует, что «вы создали правильную вещь», и подтверждает, что продукт в том виде, в котором он был предоставлен, соответствует предполагаемому использованию и целям заинтересованных сторон.
В этой статье использовано строгое или узкое определение проверки.
С точки зрения тестирования:
И верификация, и валидация связаны с концепциями качества и обеспечения качества программного обеспечения. Сами по себе проверка и валидация не гарантируют качества программного обеспечения; требуется планирование, прослеживаемость, управление конфигурацией и другие аспекты разработки программного обеспечения.
В сообществе моделирования и моделирования (MS) определения верификации, валидации и аккредитации аналогичны:
В определении валидации модели и модели основное внимание уделяется точности, с которой модель и модель представляет предполагаемое использование в реальном мире. Определение степени точности модели и моделирования требуется, поскольку все модели и модели являются приближениями к реальности, и обычно очень важно определить, является ли степень приближения приемлемой для предполагаемого использования. Это контрастирует с проверкой программного обеспечения.
В критически важных программных системах, где безупречная производительность абсолютно необходима, формальные методы могут использоваться для обеспечения правильного работа системы. Однако эти формальные методы могут оказаться дорогостоящими и составляют до 80 процентов от общей стоимости разработки программного обеспечения.
Тестовый пример - это инструмент, используемый в процессе. Тестовые примеры могут быть подготовлены для проверки программного обеспечения и проверки программного обеспечения, чтобы определить, был ли продукт построен в соответствии с требованиями пользователя. Другие методы, такие как обзоры, могут использоваться на ранних этапах жизненного цикла для обеспечения валидации программного обеспечения.
ISVV означает Независимая проверка и проверка программного обеспечения . ISVV нацелен на критичные к безопасности программные системы и нацелен на повышение качества программных продуктов, тем самым снижая риски и затраты на протяжении всего срока службы программного обеспечения. ISVV обеспечивает уверенность в том, что программное обеспечение работает с заданным уровнем уверенности, в рамках своих проектных параметров и определенных требований.
Действия независимых разработчиков ПО выполняются независимыми инженерными группами, не участвующими в процессе разработки программного обеспечения, для оценки процессов и конечных продуктов. Независимость команды ISVV осуществляется на трех разных уровнях: финансовом, управленческом и техническом.
ISVV выходит далеко за рамки «традиционных» методов проверки и валидации, применяемых группами разработчиков. В то время как последние нацелены на обеспечение хорошей работы программного обеспечения в соответствии с номинальными требованиями, ISVV сосредоточен на нефункциональных требованиях, таких как устойчивость и надежность, а также на условиях, которые могут привести к сбою программного обеспечения. Результаты и выводы ISVV передаются командам разработчиков для исправления и улучшения.
ISVV является производным от применения IVV (независимой проверки и подтверждения) в программном обеспечении. Раннее приложение ISVV (известное сегодня) восходит к началу 1970-х годов, когда США Армия спонсировала первую значительную программу, связанную с IVV для системы Safeguard Anti-Ballistic Missile.
К концу 1970-х годов IVV быстро стали популярными. Постоянное увеличение сложности, размера и важности программного обеспечения приводит к увеличению спроса на IVV, применяемые к программному обеспечению (ISVV).
Между тем, IVV (и ISVV для программных систем) консолидируются и теперь широко используются такими организациями, как Министерство обороны, FAA, NASA и ESA. IVV упоминается в [DO-178B], [ISO / IEC 12207] и формализовано в [IEEE 1012].
Первоначально в 2004-2005 годах европейский консорциум, возглавляемый Европейским космическим агентством, в состав которого входили DNV (N), Critical Software SA (P), Terma (DK) и CODA Scisys (Великобритания) разработала первую версию руководства, посвященного ISVV, под названием «ESA Guide for Independent Verification and Validation» при поддержке других организаций, например SoftWcare SL (E) () и т. Д.
В 2008 году Европейское космическое агентство выпустило вторую версию, поскольку SoftWcare SL была вспомогательным редактором, получив комментарии от многих различных заинтересованных сторон European Space ISVV. В этом руководстве описаны методологии, применимые ко всем этапам разработки программного обеспечения в том, что касается ISVV.
ISVV обычно состоит из пяти основных фаз, эти фазы могут выполняться последовательно или как результат процесса адаптации.
Планирование ISVV
Проверка требований
Проверка проекта
Проверка кода
Проверка
Верификация и валидация должны соответствовать требованиям регулируемых законодательством отраслей, а именно: часто руководствуется государственными учреждениями или промышленными административными органами. Например, FDA требует проверки версий программного обеспечения и исправлений.
