Архитектура продукта
Принято определять архитектуру продукта как:
- расположение функциональных элементов, составляющих продукт
- отображение функциональных элементов на физические компоненты
- спецификация интерфейсов между взаимодействующими физическими компонентами.
Есть утверждение, что архитектура продукта влияет на то, как дизайн должен быть проверен . Например, модульная архитектура может помочь снизить общую стоимость тестирования. Способствующими факторами является то, что интерфейсы, как правило, более четкие, а взаимодействие между подсистемами, как правило, проще в модульной конструкции.
Стратегия тестирования и план тестирования также могут быть разработаны для использования модульности архитектуры продукта . Как следует из вышесказанного, необходимо соблюдать осторожность при сосредоточении тестирования на модулях, поскольку сокращение тестирования на системном уровне, вероятно, представляет повышенный риск обнаружения неисправностей на более поздних этапах использования .
Еще одна архитектурная проблема, влияющая на тестирование, - это общность модулей в продукте или в семействе продуктов. Например, увеличение общности уменьшает количество уникальных частей и интерфейсов и, следовательно, может уменьшить количество необходимых испытаний.
С другой стороны, общность также увеличивает количество условий, при которых каждая деталь должна работать, что может увеличить потребность в тестировании.
Степень новизны
Испытание, которое должно быть выполнено, также зависит от степени, в которой проект является инновационным или дополнительным. Проекты, включающие важные инновационные элементы, часто требуют тестов для экспериментов, изучения и совершенствования новых технологий .
В принципе, это должно произойти в начале проекта развития. Информация, полученная в результате таких испытаний, может существенно повлиять на эволюцию процесса проектирования. Это также относится и к подходам, ориентированным на пользователя, когда ожидается, что пользовательские тесты новой разработки будут определять будущие итерации.
С другой стороны, когда продукт разрабатывается поэтапно по сравнению с предыдущей версией, в рамках проекта, как правило, требуется меньше технологических разработок, тесты с большей вероятностью будут сосредоточены на проверке, а не на обучении, и, как ожидается, такое тестирование приведет к меньшему нарушению работы. планируемая работа.
Кроме того, части или подсистемы, которые перенесены из предыдущего проекта и не изменены, могут быть легко проверены без повторного тестирования их на уровне устройства. Можно описать это как «проверку путем сравнения» повторно используемой подсистемы с ранее проверенной идентичной конструкцией.
В контексте поэтапно разработанных сложных продуктов, идеи и установленные процессы из предыдущих проектов, как правило, сообщают план тестирования и действия по тестированию. Таким образом, постепенное развитие и знакомство с технологией могут быть полезны для повышения качества верификации, валидации и тестирования (VVT)
Сроки тестирования
VVT должен проводиться «на постоянной основе, начиная как можно раньше в жизненном цикле продукта» и должен «включать различные методы, поскольку потребности этих задач меняются на протяжении жизненного цикла разработки».
Можно различать два типа тестов, которые происходят в разное время: аналитические тесты выполняются на ранних этапах процесса разработки для устранения рисков, а валидационные тесты, сделанные позже, направлены на подтверждение существующих прогнозов того, что продукт будет работать так, как задумано.
Проведенные исследования подтверждают важность правильного позиционирования различных тестов на временной шкале проекта разработки продукта (PD). Например, Томке сообщает эмпирическое исследование интеграции тестирования в процесс разработки, основанное на тематическом исследовании и обзоре разработки интегральных схем.
Он сосредотачивается на том моменте в проекте, когда компания переходит от смоделированных испытаний к физическому тестированию. Он утверждает, что когда физическое тестирование отнимает много времени и средств, дизайнеры стараются решить как можно больше проблем с помощью моделирования до создания физического прототипа.
С другой стороны, когда физическое тестирование обходится дешевле, дизайнеры используют его раньше в процессе проектирования. Связанная проблема заключается в том, что тесты высокой точности часто могут быть невозможны на ранних этапах процесса проектирования, поскольку необходимая информация о проекте еще не доступна .
При тестировании сложных продуктов на системном уровне потребность в подробной информации о конструкции и высокой стоимости тестирования означает, что значительные тесты обычно планируются очень поздно, чтобы убедиться, что прототип ведет себя так, как предсказывают дизайнеры. Это может вызвать значительные проблемы для проекта, если в ходе испытаний будут обнаружены серьезные недостатки проекта.
Сторонники основанного на множестве параллельного проектирования (SBCE) утверждают, что физическое или виртуальное тестирование должно проводиться как можно раньше в процессе, чтобы узнать о пространстве проектирования и принять обоснованные решения, чтобы избежать дорогостоящей переделки, которая происходит, если тестирование выявляет недостатки в конце процесс проектирования.
Эта стратегия получила название «тест-потом-проектирование» и ориентирована не на проверку и валидацию, а на использование тестов для систематического выявления компромиссов и ограничений, присущих выбранной технологии, до принятия проектных решений.
В этом контексте стоимость тестирования может быть уменьшена, если тесты тщательно спроектированы, чтобы позволить быстрое исследование проектного пространства, например, с реконфигурируемым устройством.
Восприимчивость к изменению конструкции
Как уже упоминалось выше, многие инженерные проекты представляют собой дополнительные модификации существующего продукта. В таких случаях не все должно быть проверено. С необходимыми изменениями, известными с самого начала, соответствующие действия по тестированию в принципе могут быть определены и встроены в планы тестирования.
Тем не менее, изменения также возникают неожиданно во время проекта, из-за измененных требований или сбоев, которые сами могут быть выявлены путем тестирования.
С точки зрения требований, учитывая, что планы испытаний V & V предназначены для проверки соответствия проекта определенным техническим требованиям, часто меняющиеся требования могут оказать существенное влияние на план испытаний.
На качество VVT также негативно влияют неясные, неоднозначные или нестабильные требования. С точки зрения неисправностей, выявленных в ходе испытаний, недостаток должен быть исправлен, что требует изменения конструкции.
Независимо от того, как инициируется изменение, поскольку каждая часть проекта связана по меньшей мере с одной другой частью, изменение в одной части может распространяться и требовать изменений в других, так что части могут продолжать работать вместе . Распространение изменений может потребоваться при создании или пересмотре плана тестирования, чтобы обеспечить надлежащее качество для всех потенциально затронутых частей и взаимодействий .
