Процесс проверки и валидации проекта
Томас Гамильтон
⚡ Умное резюме
Проверка проекта подтверждает, что результат проектирования соответствует задокументированным исходным данным, а валидация проекта подтверждает, что готовый продукт удовлетворяет реальным потребностям пользователей. Оба процесса проводятся на протяжении всего процесса разработки, никогда не завершаясь в самом конце.
Проверка дизайна
Проверка дизайна Это метод подтверждения, посредством проверки и предоставления доказательств, того, что результат разработанного программного продукта соответствует его входным спецификациям. Цель процесса верификации проекта в процессе разработки программного обеспечения состоит в том, чтобы гарантировать, что разработанный программный продукт соответствует заданным параметрам.
Входные данные для проектирования — это любые физические и эксплуатационные требования, используемые в качестве основы для проектирования. Выходные данные для проектирования — это результат каждой фазы проектирования и всех усилий, затраченных на проектирование. В регулируемых отраслях, таких как производство медицинских изделий, окончательные результаты проектирования становятся основой для основного документа по устройству, поэтому терминология, используемая в управлении проектированием, так часто встречается в документации по верификации.
На практике проверка сопоставляет два набора документов: технические условия, стандарты и ограничения, которые были использованы при разработке, с чертежами, нормами и инструкциями по испытаниям, которые были получены в результате разработки. Каждое несоответствие между ними является результатом проверки.
Проверка дизайна
Верификация доказывает внутреннюю согласованность. Валидация же задает более сложный вопрос: действительно ли спецификация изначально описывала правильный продукт?
Проверка дизайна Проверка проекта — это процесс оценки программного продукта на соответствие точным требованиям конечных пользователей или заинтересованных сторон. Цель проверки проекта — протестировать программный продукт после разработки, чтобы подтвердить, что он соответствует этим требованиям при использовании в собственной среде пользователя.
Валидация направлена на демонстрацию соответствия и полноты проекта потребностям пользователей. На этом этапе фактически создается версия продукта и проверяется ее соответствие требованиям пользователей.
На баннере ниже обозначены две части работы, как они обычно представлены в проектной документации.
На следующей диаграмме показан сам процесс проверки проекта, начиная с потребностей пользователя и заканчивая проверенным продуктом.
Цель состоит в том, чтобы с помощью объективных доказательств доказать, что продукт удовлетворяет задокументированным потребностям пользователя. Объективные доказательства — это просто физические подтверждения результата — изображение, текстовый файл, аудиофайл или подписанный отчет — которые показывают, что процедура действительно была выполнена.
На основе этих объективных данных процесс последовательно проверяет, соответствует ли продукт заранее определенным требованиям. Он включает в себя тестирование, инспекцию, анализ и аналогичные методы, поэтому валидация обычно опирается на тестирование системы и приемочное тестирование пользователя а не на уровне подразделений.
Разница между проверкой и валидацией проекта
Между проверкой и валидацией всегда существуют разногласия. Это разные виды деятельности, и оба выполняются на каждом этапе процесса разработки, а не на одной конечной точке.
| Проверка дизайна | Проверка дизайна |
|---|---|
| Проверка проектных характеристик используется в тех случаях, когда фактический результат проектирования должен совпадать с ожидаемым результатом проектирования, то есть соответствовать техническим характеристикам продукта. | Проверка соответствия проекта требованиям используется для того, чтобы убедиться, что окончательный проект отвечает ожиданиям и потребностям пользователя. |
| Проверка правильности проекта предполагает вопрос: правильно ли вы спроектировали продукт? | В ходе проверки правильности проекта задается вопрос: правильно ли вы разработали продукт? |
| Проверка проекта включает в себя проверку как отдельных блоков, так и основных компонентов. тестирование на уровне интеграции. | Проверка проекта включает в себя интеграцию вторичного или более высокого уровня и тестирование на уровне системы. |
| Некоторые аспекты проверки проекта могут быть выполнены в ходе его верификации, но верификация проекта не заменяет проверку проекта. | Проверка проекта следует за успешной проверкой проекта. |
| Проверка проектной документации может проводиться как на отдельном модуле, так и на готовой системе при любых условиях. | Валидация проекта должна проводиться при определенных условиях в соответствии с требованиями пользователя. |
| Для проверки проекта могут использоваться статические методы. Она включает в себя инспекцию системы, анализ и формальную верификацию. | Проверка проекта включает в себя составление окончательного отчета о результатах выполнения испытаний, который рассматривается, утверждается и подписывается. Эти документы сохраняются для дальнейшего использования. |
Полезный способ упрощения: проверка в основном статическая работа по отношению к документам, в то время как проверка в основном осуществляется динамическое тестирование против работающей сборки.
Процесс проверки проекта
Процесс верификации состоит из пяти этапов, и на каждом из них создается артефакт, от которого зависит следующий этап.
Идентификация и подготовка:
- В процессе разработки спецификации параллельно определяется необходимость ее проверки. Это позволяет разработчику убедиться в том, что спецификация действительно поддается проверке, чтобы инженер по тестированию мог приступить к разработке подробных планов и процедур тестирования. О любых изменениях в спецификации необходимо сообщать.
- Определите оптимальный подход к проведению верификации и определите методы измерений, необходимые ресурсы, инструменты и оборудование.
- Завершенный план проверки рассматривается совместно с проектной группой для выявления проблем до окончательного утверждения плана.
Планирование:
- Планирование верификации осуществляется параллельно с основной командой и командой разработчиков. Оно происходит на протяжении всего жизненного цикла проекта и обновляется всякий раз, когда изменяются исходные данные для проектирования.
- На этом этапе проводится документирование области применения тестируемого программного обеспечения или системы.
- Составляется предварительный план тестирования, который затем уточняется. План включает в себя ключевые этапы, снижающие риски проекта.
- Выбираются инструменты, среда тестирования и стратегия разработки, а также определяются требования, которые необходимо подтвердить посредством проверки или анализа.
Девелоping:
- Прецедент развитие совпадает с Методика SDLC Проектная группа реализовала проект. На данном этапе определены различные методы тестирования.
- Исходные данные для проектирования должны быть разработаны таким образом, чтобы даже самые простые действия по проверке были однозначными и поддающимися проверке.
- Время проверки сокращается, когда аналогичные концепции проверяются последовательно, поскольку результаты одного теста могут быть повторно использованы в качестве входных данных для последующего теста.
- TracМежду тестовыми примерами и соответствующими им входными данными для проектирования создаются связи, обеспечивающие проверку каждого требования и соответствие выходных данных проекта входным данным.
Исполнение:
- Разработанные на этапе разработки процедуры тестирования выполняются в соответствии с планом тестирования и строго соблюдаются в ходе верификационных работ.
- В случае получения некорректных результатов или необходимости внесения изменений в процедуру, эти изменения должны быть задокументированы и официально утверждены.
- Любая обнаруженная проблема регистрируется как дефект в соответствии со стандартной процедурой. процесс управления дефектами.
- A tracматрица возможностей Он создан для проверки того, что каждый параметр проектирования, указанный в плане верификационных испытаний, был протестирован, и для определения процента прохождения испытаний.
Доклады:
- Это действие выполняется в конце каждого этапа выполнения проверки.
- Отчет о проверке проекта содержит подробное резюме результатов проверки, включая управление конфигурацией, результаты каждого типа тестирования и проблемы, выявленные в ходе проверки.
- Проверка конструкции tracОтчет о практической применимости составляется на основе сопоставления требований и соответствующих результатов тестирования, чтобы подтвердить, что все требования были протестированы и что соответствующие результаты были зафиксированы.
- Любые несоответствия документируются и надлежащим образом устраняются.
- RevПроверки проводятся по завершении работ по подтверждению проектной документации, и результаты официально утверждаются.
Процесс проверки проекта
Процесс валидации не имеет столь же жесткой последовательности. Вместо этого он опирается на небольшой набор общепринятых методов, и в проекте обычно используется более одного из них.
- Сравнение с аналогичными конструкциями. Некоторые конструкции могут быть проверены путем сравнения с аналогичным оборудованием, выполняющим схожие функции. Это особенно актуально при проверке изменений конфигурации существующей инфраструктуры или стандартных конструкций, которые интегрируются в новую систему или приложение.
- Демонстрация и осмотр. Для проверки соответствия требованиям и функциональности продукта можно использовать один или оба метода.
- Анализ. Анализ конструкции может проводиться с помощью математического моделирования или симуляции, воспроизводящей требуемую функциональность.
- Тестирование. Проводятся испытания окончательной версии конструкции для подтверждения способности системы функционировать в соответствии с заданными характеристиками, и именно здесь... функциональное тестирование и нефункциональное тестирование соответствовать требованиям пользователя.
- Документация. План тестирования, его выполнение и результаты должны быть задокументированы и храниться в рамках проектной документации. Валидация, в конечном счете, представляет собой совокупность результатов всех мероприятий по валидации.
- Обоснование эквивалентности. При использовании эквивалентных изделий в процессе окончательной проверки конструкции производитель должен документально подтвердить сходство и любые различия с исходным производством.
Пример
На простом примере это различие становится очевидным.
- Возьмем простой товар: водонепроницаемые часы.
- В документе с требованиями к продукту может быть указано, что «часы должны быть водонепроницаемыми во время плавания». Это потребность пользователя, и именно по этому критерию оценивается проверка качества.
- В технической документации может быть указано, что «часы должны функционировать даже при длительном плавании». Это исходные данные для проектирования, и именно по ним оценивается проверка качества.
- Результаты испытаний должны подтвердить, что часы соответствуют этим требованиям. Если это не так, доработка дизайна будет продолжаться до тех пор, пока часы не будут соответствовать требованиям.
Обратите внимание, как часы могут пройти проверку, но при этом не пройти валидацию. Если в спецификации длительное плавание определяется как пятнадцать минут, а реальные пловцы находятся в воде в течение часа, то выходные данные конструкции идеально соответствуют входным, но всё равно не удовлетворяют требованиям пользователя.
Преимущества валидации и верификации проекта
Непрерывное выполнение обоих процессов, а не их завершение в виде контрольной точки, обеспечивает преимущества, описанные ниже.
- Процесс проектирования можно непрерывно контролировать, что позволяет удовлетворять заданным пользователем требованиям на каждом этапе.
- Проверка проекта выявляет разницу между тем, как работает функциональность, и тем, как она должна работать.
- Документирование процедур проверки позволяет легко понять функциональность в дальнейшем, при внесении изменений или улучшений.
- Время разработки постоянно сокращается, а производительность повышается, что помогает поставлять продукт в соответствии с ожиданиями.
- Данный процесс определяет диапазон и область применения каждого метода проверки, который необходимо использовать.
- Проверка может быть проведена с использованием подробных проектных данных, отражающих конечные требования пользователя.
- Любые расхождения между результатом и документами, описывающими потребности пользователя, фиксируются, а не теряются.
- Изменения в проверенной конструкции запускают процесс повторной проверки, поэтому данные никогда не отклоняются от реального продукта.
- Документирование каждого действия, происходящего в процессе валидации, является достаточным доказательством того, что проект соответствует требованиям пользователя.
Поэтому проверку и подтверждение правильности проекта лучше всего планировать в рамках более широкого процесса. жизненный цикл тестирования программного обеспечения и сопоставлены с другими виды тестирования ПОа не рассматривать это как отдельную процедуру соблюдения требований.
