Испытания, проверка и приёмка, обоснования
В инженерии вроде бы очевидно, что должны быть какие-то испытания созданной системы, чтобы получить уверенность команды проекта и внешних проектных ролей в её успешности, в том, что проект изменил жизнь к лучшему, а не «хотел как лучше, получилось как всегда».
Тут вопрос о том, уверенность в чём именно обосновывается? Приживается сегодня термин «качество» как удовлетворительные значения архитектурных характеристик, которые называют часто «требованиями качества» (всякие «ости», такие как безопасность, надёжность, доступность, ремонтопригодность и т.д.). Термин «обоснование качества»/qualityassurance[1]для обоснования успешности системы прижился, но он оказался неточен. Обосновывать приходится не только и не столько уверенность в «качестве» системы, то есть уверенность в том, что архитектурные характеристики имеют приемлемые значения, но нужно обосновывать и результативность работы системы, выполнение её функции в надсистеме. К тому же есть некоторое несоответствие между определениями того, чем занимается системная инженерия (созданием успешных систем с расшифровкой, что это учёт интересов самых разных проектных ролей, удовлетворение их ожиданий) и вдруг сведением успешности к просто абстрактному «качеству». Опять же, говорят не про «качественное лечение», а «успешное лечение», не про «качественную жизнь», а «успешную жизнь». Так что мы не будем тут говорить пафосно «обоснование изменения жизни к лучшему», но консервативно будем говорить об инженерных обоснованиях как обоснованиях успешности системы (цель системной инженерии — создание успешных систем, successful systems), а не просто об обоснованиях качества.
Когда мы говорим об инженерных обоснованиях, то чаще всего вспоминается вопрос о безопасности, самый болезненный — и это даже мы не касаемся традиционной путаницы «безопасности» и «защиты» (safety как «система никому не вредит» и security «системе никто не вредит»). Вспоминаются истории о том, что инженер становится под железнодорожный мост, когда по нему едет первый состав, лётчик-испытатель как «инженер-оператор самолёта» (пользователи тут — пассажиры) ассоциируется с повышенным риском и несёт как раз эти «испытания» в своём названии. Испытания — это переход от «голословных заявлений» к evidence-based, то есть заявлениям, основанным на экспериментальных свидетельствах.
Проблема в том, что большинство людей никак не испытывают результаты своей работы**, оставляя испытания пользователям сделанных ими систем****😗*
- у них просто нет культуры это делать, «большинство людей» — это не специально обученные инженеры, которых учат не пропускать испытания! Но иногда об испытаниях забывают даже «специально обученные инженеры», ибо нет письменной культуры планирования и выполнения испытаний — нет чеклистов выполнения испытаний. В проектах мало кто знает, как разрабатывать планы испытаний, как именно эти планы выполнять, и что делать с результатами испытаний (как их трактовать: ожидалось значение характеристики Y как 10, замер показал — 8.3. Это успех или неуспех?!).
- испытания требуют времени, а времени обычно нет, ибо «время — деньги» (и на испытания легко может уйти даже 85% всех затрат проекта). И всегда ведь есть вероятность, что система просто будет успешной, вдруг она реализуется как раз в нашем проекте?!
- испытания ресурсоёмки: расходуются и материалы для переработки системой, и экземпляры системы, а ещё требуется дополнительное испытательное оборудование и агенты, которые эти испытания проводят. В бюджете всего этого нет, менеджерам всё это не объяснить, так что «салюта не было по шестнадцати причинам. Первая: нет пороха!».
- Непонятно, как эти испытания делать. Как испытывать ракету, которая построена в количестве одной штуки и дальше должна лететь на Марс? Этот полёт одновременно и испытывает ракету, и является эксплуатацией ракеты. Как испытывать человека, который заканчивает школу? Ведь испытывать нужно вроде как его готовность к самостоятельной жизни, а проверяется знание математики и литературы, которое мало относится к тому, для чего выполняются испытания. Как испытывать искусственный интеллект, отвечающий на вопросы? Ему ведь наверняка при эксплуатации зададут вопрос, который не предусмотрен на испытании! Как испытывать беспилотный автомобиль? Как испытать сотрудника, которого изготовила для вашего отдела служба найма? Как испытывать общество, которое будет построено по программе правящей партии?
По мере развития инженерии стало понятно, что каких-то испытаний целевой системы недостаточно. Испытанная работоспособная система оказывалась бесполезной, потому как требования с их «испорченным телефоном» недостаточно отражали то, что хотели получить потребители, пользователи, заказчики системы и её сервисов.
Если вы согласились на разработку автомобиля «по требованиям», где указано, что это «автомобиль для торжественных ритуальных сервисов», «плавно трогаться с места и тормозить, ибо речь идёт о крупном городе», то вы вполне можете спроектировать катафалк, когда клиент ожидает от вас свадебный лимузин. Тут помогли бы сценарии использования, прямые контакты разработчика с пользователями, обследование надсистемы разработчиками и архитекторами — и ошибки бы при составлении концепции использования не было.
Проблемы обычно возникают в эксплуатации в составе надсистемы, а не при заводских испытаниях. Такое случается сплошь и рядом: вы покупаете абсолютно работоспособную модную рубашку, которая просто «не смотрится», когда вы её носите. Но она шикарно выглядит, когда висит в шкафу! И даже когда её примеряет сосед! Но носить-то её вам, а она «не смотрится». Нужны ещё испытания, показывающие, что работоспособна надсистема, когда в её составе работает целевая система. Свадьба с автомобилем для торжественных мероприятий, вы с модной рубашкой. Идея, что готовую рубашку можно будет дорабатывать/кастомизировать каждую под конкретный запрос, не приходила в голову: считалось, что это будет запредельно дорого (и при малом уровне автоматизации, плохом управлении конфигурацией это так. Автоматизация делает изменения дешевле).
К этому моменту уже появился системный подход и испытания разбили на два вида: проверку/верификацию/verification и приёмку/валидацию/validation, и оба этих вида начали упоминать вместе вместо слов «испытания», «проверка и приёмка», «verification and validation», сокращённо V&V. Одновременно становилась культура документирования потребностей и требований (до этого формальной дисциплины «инженерия требований» не было, и каждый уж что умел, то умел: документировалось отнюдь не всё). Вместо «испытаний работоспособности» начали проводить два вида испытаний для двух разных систем:
- Проверка — это испытания удовлетворения целевой системы требованиям. На границе целевой системы наружу выдаётся некоторый сервис (поведение по изменению объектов в окружении), он соответствует описанному (например, водяной насос выдаёт воду под давлением 6 атмосфер). «Какой функциональный объект задумали, такой конструктив и сделали!».
- Приёмка — это испытания того, что надсистема удовлетворит потребности. Надсистема требует от системы некоторой функции/сервиса, чтобы смочь дальше выполнить свою функцию/сервис по отношению к над-надсистеме (например, из крана на 6 этаже и высоте этажа 3 метра должна политься вода, она не полилась, давления не хватило — нужен другой насос, «что-то пошло не так»). Тут тонкий момент, что удовлетворение модулем функции так, чтобы была удовлетворена потребность — это гипотеза. Вполне возможно, что нужна была чуть другая функция, другое затребованное поведение. А сервис модуля, актуальное его поведение, оказался другим. Более того, тут проблемы могли возникать со стороны архитектурных характеристик, а не функциональных: всё могло работать, но, например, только в ходе испытаний, один раз, при «демонстрации из рук разработчиков». А дальше? А дальше система могла работать ненадёжно, быть недоступной, плохо масштабироваться и т.д. — но это обнаружится уже после испытаний!
Судьба этой новации с одной стороны была счастливой (стали говорить про V&V вместо просто testing, например в NASA программа интегральной верификации и валидации IV&V начала работать с 1993 года[2]), с другой стороны — мало кто вне аэрокосмической промышленности был знаком с системным подходом. Идея, что проверять нужно работоспособность двух систем (целевой и надсистемы), а не одной только целевой, в массы широко не пошла, пошло только название метода — и мало кто задавался вопросом, почему в названии два разных слова. Автор задавал вопрос участникам крупнейшей российской конференции по тестированию программного обеспечения, чем отличаются verification и validation друг от друга — и внятного ответа не получил, это воспринималось участниками (профессионалами в тестировании софта!) просто как «устойчивое словосочетание», означающее просто «тестирование». То, что разница между проверкой и приёмкой как испытания разных систем прописана во множестве стандартов, даётся в учебниках — это не дошло до массовой практики тестирования.
В водопадной «однократной разработке» деньги платятся обычно по выполнению проверочных испытаний (выполнены требования), а не приёмочных (система успешна), а дальше кто виноват, если проверка проходит, а приёмка нет — это очень спорный вопрос. Переход к непрерывной разработке был, в частности, связан именно с этим: испытывать приходилось неоднократно, вносить исправления в систему приходилось неоднократно, и тут пришлось менять и устройство испытаний (подробно это разбирается в DevOps: как провести минимум испытаний, чтобы после добавления в состав системы каждого инкремента сохранилось высокое качество всей системы) и способы контрактации подрядчиков. Современные контракты на разработку не предусматривают варианта разовой поставки готовой системы, они предусматривают всегда сопровождение, какой-то вариант непрерывной разработки.
И это, заметим, мы не касаемся хода на то, что успешность определяется общим впечатлением, которое получит клиент (customer eXperience, вы можете приготовить шикарный борщ, но если вам придётся его есть в вонючем помещении — общее впечатление клиента будет испорчено, и клиент даже не будет разбираться, это ваш борщ воняет, или помещение, «что-то пошло не так», впечатление испорчено, ожидания не оправдались «от обеда с борщом»). Это очень трудный ход мысли: в инженерном проекте не просто целиться во время эксплуатации системы, которой ещё нет, но и учитывать будущие впечатления/опыт/eXperience тех людей, которые сталкиваются с системой, ибо интересы внешних проектных ролей не совпадают с интересами разработчиков, выпадают из внимания.
Разделение проверки и приёмки, а потом и мониторинг реальных впечатлений пользователей были не последним шагом в развитии метода испытаний. Они оказались только частью того инженерного метода, который должен был давать уверенность в том, что целевая система таки изменяет жизнь к лучшему (сильная формулировка, как мы замечали в первом разделе руководства) или хотя бы является успешной (то есть соответствует ожиданиям проектных ролей, или даже превышает эти ожидания, более слабая формулировка, но пока более распространённая в системной инженерии — и далее с выходом на eXperience). Этот метод получил название инженерного обоснования/assurance— получение аргументированной уверенности в верности каких-то утверждений о свойствах системы (ну, или утверждений о впечатлениях внешних проектных ролей).
В нулевых годах 21 века столкнулись два подхода к инженерным обоснованиям:
- Обоснование на основе свидетельств (evidence-based assurance, доказательные обоснования),
- Обоснование на основе процесса (process-based assurance).
Менеджерам (инженерам предприятия, во внимании которых не столько целевая система, сколько система-создатель целевой) полюбилось обоснование на основе процесса, это было закреплено в стандартах «обеспечения качества» серии ISO 9000, разрабатываемых с 1987 года. Этот тип обоснования стал мощной отраслью по торговле сертификатами соответствия требованиям «стандартов качества». Суть была в том, что надо было документировать рабочие процессы, а затем требовать их выполнения в том виде, в каком они были документированы — и подразумевалось, что соблюдение документированного процесса даст вам отличное качество целевой системы. На деле оказалось, что:
- Использование «стандартов качества» серии ISO 9000 не так уж надёжно в обеспечении качества. Было множество исследований, которые показывали проблемы с результативностью и эффективностью этих стандартов[3].
- Следование процессу совсем необязательно приводит к гарантированному качеству продукта, испытания всё равно оказывались нужными.
- С подобными стандартами были связаны «ступени зрелости». Компании очень быстро проходили эти «ступени зрелости» — и останавливались в улучшении своих методов работы, ибо их текущие методы оказывались хорошо документированными, дисциплина им следования соблюдалась, и это вместо предполагаемого бесконечного совершенствования процессов оказывалось тормозом в развитии, конечной остановкой. Лекарство оказывалось болезнью!
Системные инженеры поэтому пошли по другому пути: обоснований на основе свидетельств/evidence-basedassurance. Это «доказательное обоснование» (по примеру перевода evidence-based medicine как «доказательная медицина», хотя более точный перевод будет «основанная на свидетельствах медицина» и то же верно про инженерные обоснования/assurance) уже было записано в документах по проверке и приёмке. Нет свидетельств, или свидетельства не задокументированы хоть как-то — считаем, что нет обоснований для уверенности в полезности, работоспособности, безопасности, надёжности и т.д. системы.
Ещё один вопрос, как строить на базе свидетельств доказательство того, что с будущей системой (обоснование обычно происходит до момента эксплуатации, это утверждение о будущем!) всё будет в порядке? Для этого лучшим способом оказался метод, похожий на ведение судебного дела: все свидетельства подшиваются в папку «дело»/case и получается документ::«рабочий продукт» «обосновывающее дело»/assurancecase, а само доказательство/обоснование строится так же, как доказательство в суде — на основе аргументирования каких-то промежуточных утверждений (в том числе использующих свидетельства/evidence), ведущих к выводам по поводу верности конечных утверждений. Все найденные свидетельства «подшиваются к делу» (то есть документы в папке реально прошиваются ниткой, чтобы исключить возможность их изъятия и подмены, повышая тем самым уверенность в том, что их учтут при общем выводе суда. Отсюда и выражение «шить дело»). В суде заключением по делу (свидетельствам в папке «Дело №____») будет «виновен» или «не виновен», а в инженерии — система признана «успешной» или «неуспешной».
Этот метод «ведения дела» в обоснованиях успешности системы на сегодняшний день в инженерии считается SoTA, хотя давно уже нет никаких папок, а речь идёт о записях в базах данных инженерной документации.
Инженерное обоснование проектного/design и/или архитектурного решения (время замысла и разработки, rationale) отличалось от обоснования успешности готовой системы (время эксплуатации, assurance). Когда говорили rationale, то обосновывали принятое решение, надеясь, что система сработает после того, как будет изготовлена. Когда говорили про assurance, то обосновывали то, что сработает уже изготовленная система.
Скажем, технико-экономическое обоснование (ТЭО) или инвестиционное обоснование (инвестиционный меморандум) — это обоснование того, что система будет разработана «как надо» и после этого «заработает как надо», будет успешна в будущем, это rationale. Но после изготовления системы мы знаем о ней много больше, чем тогда, когда делали обоснование проектного решения (скажем, выбирали вариант архитектуры). И мы должны дополнительно провести обоснование того, что уже готовая система будет соответствовать нашим (и в этом «мы» собраны самые разные проектные роли) ожиданиям, это assurance, и надо, например, провести испытания (например, воткнуть свежесобранный утюг в розетку и поглядеть: не идёт ли из него дым, нагревается ли он до нужной температуры, не бьёт ли током, не забыли ли при сборке утюга какую-то его деталь, не царапает ли ткань его подошва, и т.д. — то, что в проекте всё это было предусмотрено, и были обоснования проектных решений не отменяет того, что эти обоснования могли не оправдаться). Итак, если вы сделали ТЭО и получили финансирование на проект, не лишним будет проверить, не изменилось ли ваше заключение по ТЭО в середине выполнения проекта, и после того, как система сделана. Поэтому rationale****раньше всегда выделя****ли как отдельный вид обоснований, но в современной эволюционной разработке rationale****часто просто считают его всех обоснований, включая обоснования на основе испытаний**—** это просто будет какая-то частьassurance. Главное, что метод обоснований тут один и т****от же: логика с опорой на эксперимент (evidence-based: измерения, тестирование**, а не чисто «умозрение» и «интуиция»****).**
Инженер отличается от не-инженера тем, что он относится к инженерным обоснованиям всерьёз: обязательно их выполняет в ходе всего проекта**,** постоянно тратит на них ресурсы.