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

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

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

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

На изображении ниже представлен процесс проверки проекта.

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

Благодаря объективным доказательствам этот процесс будет последовательно проверять, соответствует ли продукт заранее определенным требованиям. Этот процесс включает в себя деятельность по тестированию, проверке и анализу и т. д.

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

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

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

Разница между проверкой и валидацией проекта

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

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

Идентификация и подготовка:

• На этапе разработки спецификации параллельно осуществляется идентификация действий по проверке. Это позволяет разработчику убедиться, что спецификация проверяема. Таким образом, инженер по тестированию может приступить к подробному плану и процедурам тестирования. Любые изменения в спецификации должны быть сообщены.
• Определение наилучшего подхода к проведению проверки, определение методов измерения, необходимых ресурсов, инструментов и средств.
• Завершенный план проверки будет рассмотрен командой разработчиков для выявления проблем перед доработкой плана.

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

• Планирование проверки — это одновременная деятельность основной группы и команды разработчиков. Это происходит на протяжении всего жизненного цикла проекта. Он будет обновляться по мере внесения каких-либо изменений во входные данные проекта.
• На этом этапе тестируемое программное обеспечение или система должны быть задокументированы в объеме.
• На этом этапе составляется предварительный план испытаний и его уточнение. План тестирования отражает критический этап, снижающий риск проекта.
• Инструменты, тестовая среда, стратегия разработки и определение требований посредством проверки или анализа.

Разработка:

• Разработка тестового примера будет совпадать с Методика SDLC реализуется командой проекта. На этом этапе определяются различные методы испытаний.
• Исходные данные для проектирования должны быть разработаны, включая простейшие действия по проверке, которые являются однозначными и проверяемыми.
• Время проверки должно быть сокращено, если аналогичные концепции выполняются последовательно. Даже результаты одного теста можно использовать в качестве входных данных для последующих тестов.
• Между тестовыми примерами и соответствующими входными данными проекта создаются связи, обеспечивающие отслеживаемость, чтобы гарантировать, что все требования проверены и выходные данные проекта соответствуют входным данным проекта.

Исполнение:

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

Доклады:

• Это действие выполняется в конце каждого этапа выполнения проверки.
• Отчет о проверке проекта содержит подробную сводку результатов проверки, которая включает в себя управление конфигурацией, результаты тестирования для каждого типа тестирования и проблемы, обнаруженные в ходе проверки.
• Отчет о прослеживаемости проверки проекта создается между требованиями и соответствующими результатами испытаний, чтобы убедиться, что все требования были протестированы и предоставлены соответствующие результаты.
• Любое несоответствие будет документировано и устранено соответствующим образом.
• RevПроекции выполняются после завершения работ по проверке проекта и соответственно утверждаются.

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

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

Пример

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

Преимущества валидации и верификации проекта

• Мы можем постоянно отслеживать проекты, что позволяет нам удовлетворять определенные пользователем требования на каждом этапе.
• Проверка проекта укажет на разницу между тем, как работает функциональность, и тем, как она должна работать.
• Документирование процедур проверки поможет легко понять функциональность на любом этапе в будущем, если могут быть внесены какие-либо изменения или улучшения.
• Время разработки будет последовательно сокращаться, повышая производительность, что позволит доставлять продукт в соответствии с ожиданиями.
• Этот процесс включает диапазон и объем каждого метода проверки, который необходимо использовать.
• Валидацию можно провести с использованием подробных проектных данных, которые отражают конечные требования пользователя.
• Любая разница между результатом и документами, необходимыми пользователю, должна быть зафиксирована.
• Изменения в схеме валидации приводят к повторной валидации.
• Важно документировать каждое действие, происходящее во время проверки, что адекватно доказывает, что проект соответствует требованиям пользователя.