Проверки и Приемки — различия между версиями

м (Классическая V&V)
м (Классическая V&V)
Строка 18: Строка 18:
 
* чему учат: [http://www.nafems.org/events/nafems/2014/vandv3/ пример программы курса] ([http://www.tonex.com/training-courses/system-verificationvalidation ещё]);
 
* чему учат: [http://www.nafems.org/events/nafems/2014/vandv3/ пример программы курса] ([http://www.tonex.com/training-courses/system-verificationvalidation ещё]);
 
* [http://www.academia.edu/1745073/Systems_Engineering_MS_Course_Int%20egrated_Product_Verification_and_Validation пример материала (слайдов) для вузовского курса];
 
* [http://www.academia.edu/1745073/Systems_Engineering_MS_Course_Int%20egrated_Product_Verification_and_Validation пример материала (слайдов) для вузовского курса];
* [http://courses.csail.mit.edu/6.141/spring2013/pub/lectures/Lec07-%20SystemEngineering.pdf слайды занятия: что обсуждается в «тестовых стратегиях» (и чуть-чуть про тестирование роботов)].
+
* [http://courses.csail.mit.edu/6.141/spring2013/pub/lectures/Lec07-SystemEngineering.pdf слайды занятия: что обсуждается в «тестовых стратегиях» (и чуть-чуть про тестирование роботов)].
  
 
== TDD ==
 
== TDD ==

Версия 17:31, 16 ноября 2016

Верификация (verification) — это проверка того, что система соответствует какому-то описанию целевой системы (требованиям, архитектуре, неархитектурной части проекта).

Валидация (validation) — это проверка того, что использующая система соответствует желаемому стейкхолдером её описанию, если в её составе работает целевая система.

Очень частая ошибка: забывают о необходимости валидации (приемке). В результате система удовлетворяет инженеров, которые эту систему сделали в соответствии со спецификациями, но не удовлетворяет стейкхолдеров: испытания должны проводиться не только для целевой системы (проверки), но и для использующей системы (приёмка!). Только после приёмки (то есть удостоверения в том, что использующая система работает как надо) системные инженеры могут считать, что их работа выполнена.

Основной тренд: это непрерывное автоматизированное разноуровневое тестирование, на всех этапах жизненного цикла, в том числе в ходе эксплуатации. Практики проверки и приёмки приходят сейчас главным образом из software engineering (как обычно), а потом медленно с лагом 10 лет принимаются системной инженерией. Software_testing - внизу страницы раздел Topics.

На V&V (проверки/приёмки/контроль/тестирование/испытания) приходится до половины всех затрат на разработку!

Как всегда, основной тренд в системной инженерии – это сдвиг всех проверок и приёмок влево на V-диаграмме (см. пост Donald Firesmith – «Four Types of Shift Left Testing»).

Классическая V&V

TDD

TDD (test driven development) - разработка софта, вариант agile методологии разработки

Model-based testing

Model-based testing (и по сопричастности test automation) - приходится разбираться, как устроена предметная область – т.е. что такое испытания как таковые.

Test of Cyber-physical systems (control system engineering)

Моделирование инженерных обоснований

Основная статья: Обоснование заявленных свойств