Сравнивайте с английским: нажмите на абзац — оригинал откроется в окне. Кнопка EN под абзацем показывает его прямо в тексте.
Содержание
Введение
Процесс в управлении программными проектами, тестировании программного обеспечения и разработке программного обеспечения.
Process in software project management, software testing, and software engineering
В управлении программными проектами, тестировании программного обеспечения и разработке программного обеспечения, верификация и валидация (V&V) – это процесс проверки соответствия программной системы спецификациям и требованиям, чтобы она выполняла свою целевую функцию. Это также может называться контролем качества программного обеспечения. Как правило, ответственность за это лежит на тестировщиках программного обеспечения в рамках жизненного цикла разработки программного обеспечения. Говоря простыми словами, верификация программного обеспечения отвечает на вопрос: "Если мы решили разработать X, достигает ли наше программное обеспечение поставленных целей без ошибок и недочетов?". С другой стороны, валидация программного обеспечения отвечает на вопрос: "Было ли создание X правильным решением? Соответствует ли X высоким требованиям?".
In software project management, software testing, and software engineering, verification and validation (V&V) is the process of checking that a software system meets specifications and requirements so that it fulfills its intended purpose. It may also be referred to as software quality control. It is normally the responsibility of software testers as part of the software development lifecycle. In simple terms, software verification is: "Assuming we should build X, does our software achieve its goals without any bugs or gaps?" On the other hand, software validation is: "Was X what we should have built? Does X meet the high level requirements?"
Проверка программного обеспечения
Это подразумевает проверку соответствия спецификациям путем запуска программного обеспечения, но это невозможно (например, как можно узнать, правильно ли реализованы архитектура, дизайн и т.д., просто запустив программу?). Только путем анализа сопутствующей документации можно сделать вывод о соответствии спецификациям.
It would imply to verify if the specifications are met by running the software but this is not possible (e. g., how can anyone know if the architecture/design/etc. are correctly implemented by running the software?). Only by reviewing its associated artifacts, can someone conclude whether or not the specifications are met.
Валидация программного обеспечения
Валидация программного обеспечения проверяет, соответствует ли программный продукт предполагаемому использованию (проверка верхнего уровня), то есть удовлетворяет ли он потребностям пользователей, а не требованиям, зафиксированным в спецификациях, или потребностям только тех, кто будет эксплуатировать программное обеспечение. Валидация учитывает потребности всех заинтересованных сторон (таких как пользователи, операторы, администраторы, менеджеры, инвесторы и т.д.). Существует два способа выполнения валидации программного обеспечения: внутренний и внешний. Внутренняя валидация предполагает, что цели заинтересованных сторон были правильно поняты и точно и полно отражены в требованиях. Если программное обеспечение соответствует спецификации требований, оно считается внутренне валидированным. Внешняя валидация проводится путем опроса заинтересованных сторон для определения соответствия программного обеспечения их потребностям. Различные методологии разработки программного обеспечения предусматривают разные уровни вовлечения и обратной связи от пользователей и заинтересованных сторон, поэтому внешняя валидация может быть как разовым событием, так и непрерывным процессом. Успешная финальная внешняя валидация происходит, когда все заинтересованные стороны принимают программный продукт и подтверждают, что он удовлетворяет их потребности. Для такой финальной внешней валидации требуется проведение приемочных испытаний – динамического тестирования. Однако можно также проводить внутренние статические тесты для проверки соответствия программного обеспечения спецификации требований, но это относится к области статической верификации, поскольку программное обеспечение не выполняется.
Software validation checks that the software product satisfies or fits the intended use (high level checking), i. e., the software meets the user requirements, not as specification artifacts or as needs of those who will operate the software only; but, as the needs of all the stakeholders (such as users, operators, administrators, managers, investors, etc.). There are two ways to perform software validation: internal and external. During internal software validation, it is assumed that the goals of the stakeholders were correctly understood and that they were expressed in the requirement artifacts precisely and comprehensively. If the software meets the requirement specification, it has been internally validated. External validation happens when it is performed by asking the stakeholders if the software meets their needs. Different software development methodologies call for different levels of user and stakeholder involvement and feedback; so, external validation can be a discrete or a continuous event. Successful final external validation occurs when all the stakeholders accept the software product and express that it satisfies their needs. Such final external validation requires the use of an acceptance test which is a dynamic test. However, it is also possible to perform internal static tests to find out if the software meets the requirements specification but that falls into the scope of static verification because the software is not running.
История
ISVV берет начало в применении IV&V (независимой проверки и валидации) к программному обеспечению. Первое известное применение ISVV относится к началу 1970-х годов, когда армия США профинансировала первую значительную программу, связанную с IV&V для системы противоракетной обороны Safeguard. Другой пример – программа IV&V NASA, созданная в 1993 году. К концу 1970-х годов IV&V быстро набирал популярность. Постоянный рост сложности, масштаба и важности программного обеспечения привел к увеличению спроса на IV&V применительно к программному обеспечению. В то же время IV&V (и ISVV для программных систем) укрепились и теперь широко используются такими организациями, как Министерство обороны, FAA и NASA. IV&V упоминается в DO 178B, ISO/IEC 12207 и формализован в IEEE 1012.
ISVV derives from the application of IV&V (Independent Verification and Validation) to the software. Early ISVV application (as known today) dates back to the early 1970s when the U. S. Army sponsored the first significant program related to IV&V for the Safeguard Anti Ballistic Missile System. Another example is NASA's IV&V Program, which was established in 1993. By the end of the 1970s IV&V was rapidly becoming popular. The constant increase in complexity, size and importance of the software led to an increasing demand on IV&V applied to software. Meanwhile, IV&V (and ISVV for software systems) consolidated and is now widely used by organizations such as the DoD, FAA, NASA IV&V is mentioned in DO 178B, ISO/IEC 12207 and formalized in IEEE 1012.
В ESA
Первоначально в 2004-2005 годах европейский консорциум во главе с Европейским космическим агентством, в состав которого входили DNV, Critical Software SA, Terma и CODA SciSys plc, создал первую версию руководства, посвященного ISVV, под названием "Руководство ESA по независимой проверке и валидации" при поддержке других организаций. В этом руководстве рассматриваются методологии, применимые ко всем этапам разработки программного обеспечения в части ISVV. В 2008 году Европейское космическое агентство выпустило вторую версию, получив отзывы от множества заинтересованных сторон в европейской космической отрасли, занимающихся ISVV, а также промышленных и административных органов. Например, FDA требует валидации версий программного обеспечения и патчей.
Initially in 2004 2005, a European consortium led by the European Space Agency, and composed of DNV, Critical Software SA, Terma and CODA SciSys plc created the first version of a guide devoted to ISVV, called "ESA Guide for Independent Verification and Validation" with support from other organizations. This guide covers the methodologies applicable to all the software engineering phases in what concerns ISVV. In 2008 the European Space Agency released a second version, having received inputs from many different European Space ISVV stakeholders. or industrial administrative authorities. For instance, the FDA requires software versions and patches to be validated.