Фокусирование определений системы

перекладины символизируют соответствие определения и воплощения друг другу (должно быть так: «что определяли, то и воплотили» -- это обеспечивают практики проверки и приёмки).

Говорят, что потребности стейкхолдеров фокусируют требования, требования фокусируют архитектуру, архитектура фокусирует неархитектурную часть проекта («рабочую документацию», «рабочку»). Это нужно понимать так, что из свободы творить что угодно (свободы инженерных решений) потребности стейкхолдеров оставляют только то, что нужно стейкхолдерам. Если стейкхолдерам нужно лазерное медицинское оборудование, то вряд ли им нужны требования для автомобиля. Если требования определяют автомобиль, то архитектура должна быть именно автомобиля — и не расплываться, архитектура должна быть сфокусирована на автомобиле, свобода архитектора в выборе инженерных решений на каждом уровне фокусирования уменьшается. Минимальная свобода — у конструктора или проектанта, который разрабатывает рабочую документацию (детальные чертежи, по которым будет изготавливаться изделие или сооружаться сложный инженерный объект типа атомной электростанции). Каждое определение системы ограничивает/фокусирует последующее: определяемая требованиями функция отвечает нуждам стейкхолдеров — не больше и не меньше, определяемая архитектурой структура системы отвечает функции — не больше и не меньше, определяемая неархитектурными (рабочими) инженерными решениями часть проекта отвечает архитектуре, технологическая документация (определяющая технологию изготовления — какие инструменты, обработки этими инструментами и последовательность операций по изготовлению и сборке нужно использовать для воплощения системы) входит в рабочую документацию и подчинена рабочим инженерным решениям.

Но “отвечать” и “фокусироваться” вовсе не означает последовательности во времени: так, ограничения в технологии (например, политика чучхе — “опоры на собственные силы”, ограничивающая импорт нужных инструментов) вполне могут повлиять на архитектурные решения, или даже на саму возможность выполнить требования — и тогда получаемая в конце цепочки фокусирования новая информация заставляет менять определения, вплоть до изменения требований или признания невозможности инженерного проекта.

Практики проверки и приёмки

Проверка (verification) и приёмка (validation) — это важнейшие практики системной инженерии. Важно отличать их друг от друга.

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

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

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

Вузовский курс проверки и приёмки вполне объёмист. Вот, например, 3 кредитный курс US SanDiego этого года http://extension.ucsd.edu/studyarea/index.cfm?vAction=singleCourse&vCourse=BUSA40414, или всё то же самое в компактном режиме производственного двухдневного тренинга — http://www.tonex.com/training-courses/system-verification-validation/. Product integrated verification and validation – 200 страниц слайдов для «военных системных инженеров»: http://www.academia.edu/1745073/Systems_Engineering_MS_Course_Integrated_Prod uct_Verification_and_Validation

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

Обычно для больших систем (авиация, космос, атомная промышленность, медицина) проверка и приёмка жёстко регламентируются «обязательными стандартами». Если велика угроза возврата продукции (серийный выпуск изделий), то есть огромный стимул проверять продукт перед продажей – там тоже уровень проверки довольно высок. В остальных случаях проверка и приёмка проходят «по вкусу» (а о вкусах, понятно, не спорят), в мерах приверженности участников разработки тем или иным практикам.

Основной тренд – это непрерывное автоматизированное разноуровневое

тестирование, на всех этапах жизненного цикла, в том числе в ходе эксплуатации. Сегодня даже принтер может напечатать тестовую страницу в любой момент времени, не только в момент заводских испытаний. Раньше автомобиль мог быть протестирован только на станции обслуживания, сейчас автомобиль по максимуму тестирует себя сам (ибо весь напичкан датчиками и контроллерами).

Практики проверки и приёмки приходят сейчас главным образом из software engineering (как обычно), а потом медленно с лагом 10 лет принимаются системной инженерией. Поглядите на http://en.wikipedia.org/wiki/Portal:Software_testing (там внизу страницы topics, вам неплохо бы понимать, что скрывается за этими словами). Это хорошая точка для разбирательства с предметной областью.

Очень интересно смотреть на то, что происходит в плане автоматизации испытаний: ибо для того, чтобы что-то автоматизировать, нужно глубоко изучить предметную область. Размахивание руками не подходит как способ объяснить «автоматизаторам», что же им нужно сделать – приходится для этого как-то структурировать предметную область V&V.

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

Когда речь идёт об «аналитике» (человеке, который ни на что не влияет, но систему описывает), то он не заботится об испытаниях сделанного по его описаниям. Инженер, если описывает систему, то заботится о том, чтобы проверить сделанное по этим описаниям, он не «аналитик», он «синтетик». Когда «аналитик» что-то описывает, игнорируя испытания/тестирование, то он вполне может ошибиться вдвое в части определения объёма работ и стоимости проекта.

Вот некоторое количество ссылок на материалы по проверкам и приёмкам:

Классика жанра (классические определения и общее понимание предмета):

oместо проверки и приёмки в ходе воплощения системы (водопад): http://sebokwiki.org/wiki/System_Realization

o проверка: http://sebokwiki.org/wiki/System_Verification o приёмка: http://sebokwiki.org/wiki/System_Validation

o что делает инженер по испытаниям (hardware test engineer):

http://www.nafems.org/events/nafems/2014/vandv3/, ещё вариант программы — http://www.tonex.com/training-courses/system-verification- validation/, а вот пример материала (слайдов) для вузовского курса — http://www.academia.edu/1745073/Systems_Engineering_MS_Course_Int egrated_Product_Verification_and_Validation).

oслайды занятия: что обсуждается в «тестовых стратегиях» (и чуть-чуть про тестирование роботов): http://courses.csail.mit.edu/6.141/spring2013/pub/lectures/Lec07SystemEngineering.pdf

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

odriven против based — http://ailev.livejournal.com/1015692.html