ИНВЕСТИЦИОННЫЙ ПОРТАЛ ВОЛГОГРАДСКОЙ ОБЛАСТИ

“Поваренная книга” EUROLAB – Документ No. 1
Переведено на русский язык ООО “Профилаб” (Беларусь, г. Минск) (с разрешения EUROLAB)

Выбор, верификация и валидация методов

Скачать в формате PDF 

Основные положения
Определения и требования к выбору, верификации и валидации методов приведены в разделах 3.8, 3.9 и 7.2 ISO/IEC 17025:2017.

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

Валидация:
ISO/IEC 17025:2017 – пункт 7.2.2.1: “Лаборатория должна проводить валидацию нестандартных методов, методов, разработанных лабораторией, и стандартных методов, используемых за пределами их области применения или каким-либо иным образом модифицированных. …”
Для получения дополнительной информации и примеров см. JCGM200:2012 — §2.45

Моменты, которые следует принять во внимание

Выбор:
Заказчик может определить метод, который будет использоваться, в противном случае лаборатория может выбрать подходящий метод и проинформировать заказчика.

Согласие заказчика обычно предоставляется в письменной форме; соглашение может быть частью договора. Если имеет место отступление от метода, заказчик должен быть уведомлен об этом отступлении, если конкретное утверждение уже не было включено как часть договора. Отступление от стандартного метода требует валидации метода.

Верификация:
Верификацию следует задокументировать таким образом, чтобы предоставить доказательства того, что лаборатория способна достигнуть требуемых рабочих характеристик метода; это может включать:

• Оценку повторяемости и/или воспроизводимости
• Характеристики приборов
• Квалификацию оператора (обучение, опыт, компетенции, …)
• Условия окружающей среды
• Материалы или реактивы
• Любые другие характеристики, которые могут повлиять на результат

Общие случаи перечислены ниже:

• Методы, изложенные в национальных и международных стандартах, следует рассматривать как валидированные. Тем не менее, должно быть подтверждено, что при применении (метода) в лаборатории все условия выполнены. Это включает в себя заявленную неопределённость. Если неопределённость результата не упоминается или не устанавливается в национальном или международном стандарте, то лаборатории следует подумать про неопределенность при применении такого стандарта.
• Редко используемые методы. Если метод используется только время от времени, поддержание компетентности персонала или пригодности оборудования могут быть поставлены под сомнение. В данном случае следует привести обоснование, учитывая, например, опыт и образование персонала в областях, близких к рассматриваемому методу, или напрямую самого метода.

Пример: При проведении испытаний на прочность и деформации 24-футовых контейнеров один раз в два года, при верификации следует учитывать, имеет ли персонал достаточную подготовку по механике или механике твёрдых тел и регулярно ли проводятся в лаборатории другие крупномасштабные механические испытания.

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

• Различать метод испытаний и методы получения и подготовки пробы, включая отбор проб.
• Рассмотреть факторы, влияющие на испытания или измерение (оборудование и калибровка, подготовка пробы, методика испытаний или измерений, анализ и способ получения результатов).
• Рассмотреть дополнительные изменяющиеся факторы (окружающая среда, образование и опыт оператора, частота применения метода).

В документации следует чётко описать, какие факторы имеют значение и почему и как они рассматриваются при валидации. Следует описать условия и ограничения.

Примечание: Одним из важных отличительных признаков является то, что метод может быть достоверным, но не обязательно подходящим, например, результат – это то, что заявлено, но не свидетельствует о том, что действительно нужно. Можно найти много примеров в старых, но все еще применяемых стандартах в области испытания продукции.

Два главных принципа валидации:
Валидация может быть проведена с применением следующих принципов, часто в сочетании:

• Использование научных знаний и признанного опыта для описания и демонстрации обоснованности включенных факторов.

Пример: Время для достижения термодинамического равновесия в климатической камере может быть оценено либо с помощью анализа размерностей законов теплового потока, либо по опыту измерений в схожих ситуациях

• Использование, если это возможно, межлабораторных сличений, проверок квалификации или стандартных образцов, чтобы показать, что полная цепочка испытаний или анализа приводит к заявленному результату, включая неопределённость, и в интересующем диапазоне.

Пример: Химический анализ на оборудовании типа «чёрный ящик» может быть валидирован через применение стандартных образцов или участие в проверках квалификации.

Различные виды методов
Процедуру валидации следует выбирать в соответствии с фактическим видом метода.

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

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

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

Пример: Крутящий момент, необходимый для открытия крышки, может быть измерен простым способом с неопределенностью, скажем, 3 %, но достичь неопределенности 1 % может быть достаточно трудно. Если изменение в крутящем моменте между банками обычно составляет 10 %, а цель заключается в проверке возможности открывать банки пожилыми людьми, очевидно, что обоснованной будет (неопределенность) 3 %.

Валидация является относительным понятием, и её объем всегда следует определять с учётом предполагаемого использования результатов. Это подразумевается в указанном выше пункте 7.2.2.

Новый метод
В соответствии с вышеизложенным, каждый новый метод перед его применением должен быть валидирован или верифицирован. И валидация, и/или верификация должны быть задокументированы и утверждены.

Соответствующая цели неопределённость, как часть процедуры валидации
Оценивание неопределённости может показаться сложным и не всегда возможным. Чаще всего существуют простые способы получения надёжных оценок неопределённости. Постоянно обновляемый список подходящих документов доступен на сайте EUROLAB (www.eurolab.org) (для справочной информации используйте GUM).

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

Можно привести следующие некоторые практические правила:

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

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

Понятием, связанным с этим, является воспроизводимость, которая описывает, как правило, для некоторого количества лабораторий и операторов возможность получения схожих результатов с течением времени, применяя один метод.

Примечание: В стандарте ISO/IEC 17025 упоминается ряд рабочих характеристик метода испытаний, таких как робастность, чувствительность, предел обнаружения и т.д.; эти термины являются характерными для конкретных областей, и при необходимости их следует рассматривать через определения, приведенные в VIM.

Смотрите также:
JCGM 100 (GUM)
JCGM 200 (VIM)

За перевод настоящей CookBook и любые дополнительные правки несет ответственность ООО «Профилаб» (Беларусь, г. Минск).

Документ, размещенные на сайте компании ООО «Профилаб», не могут быть распространены и тиражированы без официального разрешения ООО «Профилаб».

РАЗРАБОТКА/ВАЛИДАЦИЯ МЕТОДИК

Выполним работы по разработке Методик измерений

ПОДРОБНЕЕ ОБ УСЛУГЕ

РАЗРАБОТКА  Методик оценивания неопределенности

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

ПОДРОБНЕЕ ОБ УСЛУГЕ

Валидация и верификация | Securelist

Безопасная система – и в особенности система, которая используется для обеспечения безопасности – должны быть доверенной. Однако что лежит в основе этого доверия? Что придает уверенность в том, что основные компоненты системы реализованы правильно и не подведут в критический момент? В предыдущей статье, посвященной безопасной ОС, этот вопрос вскользь упоминался, и, как и обещали, мы возвращаемся этой теме.

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

• Верификация – это процесс оценки того, насколько система (программа, устройство) по итогам некоторого этапа ее разработки соответствует условиям, заданным в начале этапа.
• Валидация – процесс оценки того, насколько система (программа, устройство) соответствует требованиям по ее назначению.

Если говорить еще проще, верификация задается вопросом, строим ли мы систему правильно, а валидация – строим ли мы правильную систему. И если для ответа на второй вопрос существенную играет роль экспертная оценка (от валидации собственно требований к системе до тестирования конечного продукта), то уверенный ответ на первый вопрос способны дать только формальные методы.

Конечно, каждый из этих процессов не дает полной уверенности без другого. Система может быть верифицирована только относительно конкретного критерия, к примеру, относительно гарантии отсутствия ситуации взаимной блокировки при доступе к ресурсам. Тривиальный способ такой верификации возможен при запрете синхронизируемого доступа к общим ресурсам — однако при этом могут быть нарушены свойства целостности ресурсов. Поэтому адекватность условий, согласно которым система верифицируется, тоже должна быть валидирована, а некоторых случаях и сами условия подвергаются верификации, если экспертные требования можно соответствующим образом формализовать.

Когда говорят про верификацию программы, чаще всего представляют некий магический вычислитель, который принимает на вход программный код и по нажатию кнопки – хоп – выдает вердикт: код верен или неверен, безопасен или нет. При малейшем рассмотрении этой идеальной картинки возникает множество вопросов. Первый из них, а что мы, собственно, хотим доказать? На какие вопросы способна дать ответ верификация системы? Корректность, полнота, непротиворечивость, неизбыточность данных, безошибочность и безопасность функционирования… Немного сухих фактов: некоторое время назад было доказано, что все множество свойств системы можно представить как композицию двух базовых:

• Свойство безопасности формулируется как недостижение системой при любом ее исполнении некоторого (небезопасного) состояния. Иными словами, свойство гарантирует, что ничего «плохого» не произойдет (NB: именно в этом значении словосочетание «свойство безопасности» и используется до конца статьи).
• Свойство живости, напротив, гарантирует, что после конечного числа шагов система придет в некоторое определенное состояние – то есть непременно случится что-то «хорошее».

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

Для формализации описанных таким образом критериев часто используется аппарат классической или темпоральной логики, а для верификации – соответствующие языки. В частности, для классических условий довольно популярен Prolog, для темпоральных – языки Promela, SPIN. Но это далеко не единственный способ. Описание формальных условий поведения компьютерных программ и верификация относительно этих правил настолько специфичная и востребованная проблема, что в 1969 году была создана специальная формальная теория – алгоритмическая логика Хоара, предназначенная для дедуктивного доказательства правильности программ и способная приблизить сухие спецификации к семантике программ на императивных языках. В настоящее время выработан еще более жизненный подход к описанию критериев – в виде контрактных спецификаций программных интерфейсов.

Другая проблема – выбор и формализация объекта верификации. И несмотря на то, что верификация, казалось бы, процедура, состоящая в точном вычислении, при этом выборе нужно ориентироваться на требуемую степень уверенности в результате.

К примеру, для верификации может быть выбрана статическая конфигурация системы – значения системных параметров, информация об установленных приложениях и разрешения политики безопасности. Эти данные подаются на вход решателю, который на основе заранее заданных экспертом логических правил производит вычисления, иногда довольно сложные, и сообщает результат. К примеру, такой решатель может определить, возможен ли в системе некоторый вид атаки, или может ли пользователь получить неавторизованный доступ к каким-либо ресурсам.

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

В реальных системах дело чаще всего обстоит не так, а значит, необходимо подвергать верификации собственно программное обеспечение². Здесь снова приходится принимать не одно решение. Что подвергать верификации – высокоуровневый программный или машинный код, принимать ли во внимание влияние программного окружения и как моделировать это окружение, рассматривать ли специфические зависимости выполнения низкоуровневых операций от аппаратной платформы. Выбор снова зависит от цели верификации и от требуемой степени доверия к результатам. Предположим, нужно показать отсутствие уязвимостей определенного вида (этот пример выбран потому, что условие вероятнее всего сводится к свойству безопасности). Тестирование и статический анализ кода путем поиска типовых опасных конструкций в высокоуровневом коде обычно не относят к методам формальной верификации, т.к. как правило они не позволяют добиться полноты анализа³. Для решения такой задачи методы верификации производят над конструкциями программного кода логические вычисления, целью которых является доказательство того факта, что на графе передачи управления программы ни один из возможных исполняемых фрагментов (с учетом всех нелинейных переходов) не является уязвимым к указанному способу эксплуатации. Дело за малым – сформировать соответствующий критерий в достаточно общем виде и выполнить эффективное вычисление всем объеме кода программы.

При недостатке доказательств того, что компилятор сохранит доказанные для высокоуровневого представления свойства и для машинного кода, или если нужно гарантировать свойства, сформулированные для машинного кода, работа еще более усложняется. Именно из-за сложности верификации программного кода ее методы применяются к коду как можно более простому и меньшего объема, используемому в ядре безопасности ОС и низкоуровневых компонентах, на которых основано исполнение менее доверенных сервисов и приложений.

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

Другой подход к обеспечению верифицируемости кода при его создании – использование парадигмы контрактного программирования. В этом случае перед созданием кода определяются точные формальные (контрактные) спецификации интерфейсов, задающие предусловия (обязательства со стороны клиентов интерфейсов), постусловия (обязательства поставщика) и инварианты (обязательства по выполнению конкретных свойств). Контрактное программирование поддерживается многими языками, в том числе расширениями Java и C.

Верификация программного кода «в лабораторных условиях» может вызывать нарекания в том случае, если поведение кода в большой степени определяется его окружением. Неплохо, конечно, если система построена из слабо связанных компонентов с хорошо документированными интерфейсами – однако в реальных системах достаточно сложно предсказать влияние окружения на поведение отдельно взятого компонента. В этих случаях для оценки корректности системы приходится прибегать к анализу поведения параллельно работающих компонентов. Формальная проверка того, выполняется ли заданная логическая формула на модели системы, описывается в рамках метода, известного как Model checking. Этот метод аккумулирует существующие достижения в верификации систем и широко применяется по всему миру для проверки сложных аппаратных и программных комплексов. За работы, внесшие существенный вклад в его развитие, дважды вручалась премия Тьюринга (первый раз – в 1996 году Амиру Пнуели за «плодотворную работу по внедрению темпоральной логики в вычислительные науки, и за выдающийся вклад в верификацию программ и систем», и второй в 2007 году – ученым Кларку, Эмерсону и Сифакису «за их роль в развитии проверки на модели — высокоэффективную технику верификации программ, широко применяемую при разработке как программного, так и аппаратного обеспечения»). В настоящее время методы model checking применяются и за пределами верификации технических систем, для которых этот метод был изначально разработан.

При вручении премии Тьюринга президент ACM Стьюарт Фельдман сказал и методе Model checking: «Это великий пример того, как технология, изменившая промышленность, родилась из чисто теоретических исследований». Можно с уверенностью утверждать, что если будущее во всех областях жизни от устройств бытового назначения до критических инфраструктур за развитыми, умными и безопасными во всех смыслах технологиями, то методы V&V обеспечивают путь в это будущее.

В одной статье невозможно охватить все вопросы. Для заинтересовавшихся рекомендуем прочитать:

• Статью одного из отцов-основателей метода проверки на модели Эдмунда Кларка (Edmund M. Clarke «The Birth of Model Checking»).
• Глубже погрузиться в формальные основы метода можно при помощи замечательной книги профессора Ю.Г. Карпова «Model Checking».
• Изучить вопросы, связанные с формализацией требований безопасности и живости лучше всего на основе оригинальных работ, обзор которых можно найти в статье Ekkart Kindler «Safety and Liveness Properties: A Survey».
• Монография Ж.Теля «Введение в распределенные алгоритмы» представляет потрясающий по объему и содержанию труд по формальному представлению протоколов в сложных системах и обеспечению их корректной и надежной работы.

¹Это как раз тот случай, когда механизм валидации (на основе знаний об уязвимости ПО) помог бы или отвергнуть меры анализа конфигурации, или ввести компенсационные меры (своевременное обновление потенциально проблемного ПО) с принятием остаточных рисков. >>

²Заметим, что верификация конфигурации и верификация программного обеспечения — не взаимозаменяемые меры. Если проверка программного кода гарантирует ожидаемое поведение программных компонентов, то проверка конфигурации обеспечивает выполнение политики безопасности при работе этих компонентов. >>

³Однако они могут служить для валидации программного кода. >>

Об интеграции формальных методов в задачах верификации операционных систем | Петренко

1. Proceedings of the 1st International Conference on Integrated Formal Methods. Edited by K. Araki, A. Galloway, K. Taguchi, York, 28-29 June 1999. Springer-Verlag, 1999. ISBN:1-85233-107-0.

2. L. De Moura, N. Bjørner. Z3: an Efficient SMT Solver. Proceedings of TACAS’2008. LNCS 4963:337-340, Springer-Verlag, 2008.

3. http://github.com/Z3Prover/z3

4. C. Barret, C. L. Conway, M. Deters, L. Hadarean, D. Jovanović, T. King, A. Reynolds, C. Tinelli. CVC4. Proceedings of CAV’2011, LNCS 6806:171-177, Springer, 2011.

5. http://cvc4.cs.nyuedu/web

6. M. Veanes, C. Campbell, W. Grieskamp, W. Schulte, N. Tillmann, L. Nachmanson. Model-based Testing of Object-oriented Reactive Systems with SpecExplorer. Proceedings of FORTEST’2008, LNCS 4949:39-76, Springer-Verlag, 2008.

7. N. Tillmann, J. de Halleux. Pex — White Box Test Generation for.NET. Proceedings of TAP’2008, LNCS 4966:134-153, Springer-Verlag, 2008.

8. P. Godefroid. Random Testing for Security: Blackbox vs. Whitebox Fuzzing. Proceedings of 2-nd International Workshop on Random Testing, p. 1-1, ACM, 2007.

9. T. A. Henzinger, R. Jhala, R. Majumdar, G. Sutre. Software Verification with BLAST. Proceedings of SPIN’2003, Model Checking Software, LNCS 2648:235-239, Springer-Verlag, 2003.

10. T. Ball, B. Cook, V. Levin, S. K. rajamani. SLAM and Static Driver Verifier: Technology Transfer of Formal Methods inside Microsoft. Proceedings of IFM’2004, LNCS 2999:1-20, Springer-Verlag, 2004.

11. D. Beyer, M. E. Keremoglu. CPAchecker: a Tool for Configurable Software Verification. Proceedings of CAV’2011, LNCS 6806:184-190, Springer, 2011.

12. G. Canet, P. Cuoq, B. Monate. A Value Analysis for C Programs. Proceedings of SCAM’2009, p. 123-124, IEEE, 2009.

13. J.-R. Abrial, M. Butler, S. Hallerstede, L. Voisin. An Open Extensible Tool Environment for Event-B. Proceedings of ICFEM’2006, Formal Methods and Software Engineering, LNCS 4260:588-605, Springer-Verlag, 2006.

14. А. К. Петренко. Унификация в автоматизации тестирования. Позиция UniTESK. Труды Института системного программирования РАН 14(1):7-22, 2008.

15. В. В. Кулямин. Интеграция методов верификации программных систем. Программирование, 35(4):41-55, 2009.

16. В. В. Кулямин. Методы верификации программного обеспечения. Статья-победитель конкурса обзорно-аналитических статей по направлению «Информационно-телекоммуникационные системы», 2008 (http://www.ispras.ru/publications/2008/methods_of_software_verification/).

17. E. Clarke, O. Grumberg, S. Jha, Y. Lu, H. Veith. Counterexample-Guided Abstraction Refinement. Proceedings of CAV’2000, LNCS 1855:154-169, Springer-Verlag, 2000.

18. М. У. Мандрыкин, В. С. Мутилин, А. В. Хорошилов. Введение в метод CEGAR — уточнение абстракции по контрпримерам. Труды Института системного программирования РАН 24: 219-292, 2013. DOI: 10.15514/ISPRAS-2013-24-12

19. В. В. Кулямин, А. К. Петренко. Развитие подхода к разработке тестов UniTESK. Труды Института системного программирования РАН 26(1):9-26, 2014. DOI: 10.15514/ISPRAS-2014-26(1)-1

20. И.С. Захаров, М.У. Мандрыкин, В.С. Мутилин, Е.М. Новиков, А.К. Петренко, А.В. Хорошилов. “Конфигурируемая система статической верификации модулей ядра операционных систем”. Труды Института Системного Программирования РАН, Том 26(2):5-42, 2014. DOI: 10.15514/ISPRAS-2014-26(2)-1

21. Е. М. Новиков. Развитие метода контрактных спецификаций для верификации модулей ядра операционной системы Linux. Диссертация на соискание ученой степени к.ф.-м.н., Москва, 2013.

22. И.С. Захаров, В.С. Мутилин, А.В. Хорошилов. “Моделирование окружения с использованием шаблонов для статической верификации модулей ядра Linux”. // Программирование, Том 41, 2015, №3, сс. 3-19.

23. P. N. Devyanin, A. V. Khoroshilov, V. V. Kuliamin, A. K. Petrenko, and I. V. Shchepetkov. Using Refinement in Formal Development of OS Security Model. Proceedings of PSI’2015.

24. П. Н. Девянин. Ролевая ДП-модель управления доступом и информационными потоками в операционных системах семейства Linux. ПДМ, 2012, № 1, 69-90.

Морфологические методы верификации и количественной оценки апоптоза | Манских

1. Белушкина И.И., Северин С.Е. Молекулярные основы патологии апоптоза // Арх. пат. 2001. Т. 63. ‹ 1. С. 51—60.

2. Бережков Н.В. Апоптоз — управляемая смерть клетки // Арх. анат., гистол. и эмбриол. 1990. Т. 99. ‹ 12. С. 68—75.

3. Владимирская Е.Б., Масчан А.А., Румянцев А.Г. Апоптоз и его роль в развитии опухолевого роста // Гематол. и трансфузиол. 1997. Т. 42. С. 4—9.

4. Гилберт С. Биология развития. М.: Мир, 1993. 235 с.

5. Гинкул Л.Б., Александрова С.А., Арцабашева И.В., Швембергер И.Н. Клональный анализ гетерогенности опухолевых гепатоцитов // Вопр. онкол. 1998. Т. 47. ‹ 4. С. 456—460.

6. Гистология // Ю.И. Афанасьев, Н.А. Юрина, В.Ф. Котовский и др. / Под ред. Ю.И. Афанасьева, Н.А. Юриной. М.: Медицина, 2001. 744 с.

7. Дудич Е.И., Семенкова Л.Н., Дудич И.В. и др. Изучение апоптоза раковых клеток, индуцированного α-фетопротеином // Бюлл. эксперим. биол. и мед. 2000. Т. 130. ‹ 12. С. 604—612.

8. Зарецкая А.И. Электронно-микроскопический анализ апоптоза рака прямой кишки до и после облучения // Арх. пат. 1988. Т. 50. ‹ 1. С. 46—52.

9. Квачева Ю.Е. Морфологические типы радиационноиндуцированной гибели клеток кроветворной ткани, ее биологическая суть и значимость на различных этапах развития острого радиационного поражения // Радиационная биология. Радиоэкология. 2002. Т. 42. ‹ 10. С. 287—292.

10. Коган Е.А. Некроз. Лекции по общей патологической анатомии / Под ред. В.В. Серова, М.А. Пальцева. М.: Медицина, 1996. С. 78—90.

11. Лонская И.А., Чернова О.А., Чернов В.М. Два различных типа апоптоза в тимоцитах // Цитология. 2001. Т. 43. ‹ 3. С. 244—249.

12. Лукьянова К.Ю., Кулик Г.И., Чехун В.Ф. Роль генов р53 и bcl-2 в апоптозе и лекарственной резистентности опухолей // Вопр. онкол. 2000. Т. 46. ‹ 2. С. 121—128.

13. Лянгузова М.С., Поспелов В.А., Кислякова Т.В. Дифференцированные клетки тератокарциномы мыши линии F9 вступают в апоптоз при разрыве контакта с субстратом // Цитология. 2001. Т. 42. ‹ 10. С. 955—962.

14. Маянский Н.А., Заславская М.И., Маянский А.Н. Апоптоз экссудативных нейтрофилов человека // Иммунология. 2000. Т. 22. ‹ 2. С. 11—13.

15. Маянский Н.А. Субклеточное перераспределение bax и его слияние с митохондриями при спонтанном апоптозе нейтрофилов // Иммунология. 2001. Т. 22. ‹ 6. С. 29—31.

16. Маянский Н.А. Действие липополисахаридов и УФ-облучения на регуляцию апоптоза нейтрофилов человека // Иммунология. 2001. Т. 22. ‹ 2. С. 25—27.

17. Маянский Н.А. Состояние каспазы 3 при подавлении апоптоза нейтрофилов гранулоцитарно-макрофагальным КС // Иммунология. 2001. Т. 22. ‹ 2. С. 22—25.

18. Маянский Н.А. Каспазозависимый механизм апоптоза нейтрофилов: апоптогенный эффект туморо-некротического фактора α // Иммунология. 2002. Т. 23. ‹ 1. С. 15—18.

19. Михайлов В.М., Комаров С.А., Нилов В.К. и др. Ультраструктурный и морфометрический анализ стадий апоптоза кардиомиоцитов мышей MDХ // Цитология. 2001. Т. 43. ‹ 8. 729—735.

20. Мошникова А.Б., Мошников С.А., Афанасьев В.Н. и др. Диметилсуберимат как специфический индуктор апоптоза трансформированных клеточных культур // Цитология. 2001. Т. 43. ‹ 8. С. 747—753.

21. Никонова М.Ф., Литвина М.М., Варфоломеева М.И., Ярилина А.А. Апоптоз и пролиферация как альтернативные формы ответа Т-лимфоцитов на стимуляцию // Иммунология. 1999. Т. 21. ‹ 2. С. 20—23.

22. Пальцев М.А. Морфология повреждения. Лекции по общей патологической анатомии / Под ред. В.В. Серова, М.А. Пальцева. М.: Медицина, 1996. С. 17—29.

23. Райхлин Н.Т., Райхлин А.Н. Регуляция и проявления апоптоза в физиологических условиях и в опухолях // Вопр. онкол. 2002. Т. 48. ‹ 2. С. 159—171.

24. Фридлянская И.И., Демидов О.Н., Булатова М.М. Индукция апоптоза в клетках мышиной миеломы NS0/1, трансформированной геном основного белка теплового шока // Цитология. 2000. Т. 42. ‹ 11. С. 1053—1509.

25. Фильченков А.А. Стойка Р.С. Апоптоз: краткая история, молекулярные механизмы, методы выявления и возможное значение в онкологии // Эксперим. онкол. 1995. ‹ 18. С. 435—448.

26. Хавинсон В.Х., Южаков В.В., Кветной И.М., Малинин В.В. Влияние эпиталона на кинетику роста и функциональную морфологию саркомы М.1 // Вопр. онкол. 2001. Т. 47. ‹ 4. С. 461—466.

27. Хавинсон В.Х., Кветной И.М. Пептидные биорегуляторы ингибируют апоптоз // Бюлл. эксперим. биол. и мед. 2000. Т. 130. ‹ 12. С. 657—659.

28. Хансон К.П., Имянитов Е.Н., Посохов В.С., Розенберг О.А. Модификация чувствительности к апоптозу клеток асцитной карциномы Эрлиха путем трансфекции ДНК из тимоцитов // Вопр. онкол. 1998. Т. 44. ‹ 6. С. 701—703.

29. Цинзерлинг А.В., Цинзерлинг В.П. Патологическая анатомия. М.: Медицина, 1996. 370 с.

30. Шаповалов В.Д., Михалева Л.М. Апоптоз и ультраструктурные изменения плазматических клеток собственно слизистой оболочки десны больных парадонтозом // Иммунология. 2002. Т. 23. ‹ 2. С. 83—86.

31. Afanasev V.N., Korol B.A., Mantsygin Yu.A. et al. Flow cytometry and biochemical analisis of DNA degradation charachteristic of two types of cell death // FEBS Lett. 1986. V. 194. P. 347—350.

32. Arends M.J., Morris R.G., Wyllie A. Apoptois. The role of endonuclease // Amer. J. Path. 1990. V. 136. P. 593—608.

33. Bonkhoff H., Fixemer T., Hansicker I., Remberger K. Simultaneous detection of DNA fragmentation (apoptosis), cell proliferation (MIB-1), and phenotype markers in routinely processed tissue sections // Virchows Archiv. 1999. V. 434. ‹ 1. P. 71—73.

34. Columbano A. Cell death: current difficulties in discrining apoptosis from necrosis in the context of pathological processes in vivo // J. Cell. Biochem. 1995. V. 58. P. 181—190.

35. Horton J., Milner A., Horton T. et al. Apoptosis-specific protein (ASP) identified in apoptotic Xenopus thymus tumor cells //Dev. Immunol. 1998. V. 5. ‹ 4. P. 333—348.

36. Kochx M. Apoptosis in the ateroma // Arteriosclerosis, Tromb. and Vasc. Biol. 1998. ‹ 18. P. 1519—1522.

37. Majno G., Joris I. Apoptosis, oncosis and necrosis //Amer. J. Path. 1995. V. 146. P. 3—15.

38. McMahan R., Jonson R.O., Ruben L.N., Clothier R.H. Apoptosis and the cell cycle in Xenopus laevis: PHA and PMA exposure of splenocytes // Immynol. Lett. 1999. V. 70. ‹ 3. P. 179—183.

39. Moser B. Silver stain for the detection of apoptosis at the light microscopy // Micr. Anat. 1995. V. 37. 27—29.

40. Sarnaf C.E., Bowen I.D. Kinetic stadies on a murine sarcoma and analisis of apoptosis // Brit. J. Cancer. 1986. V. 54. P. 989—998.

41. Steller H. Mechanisms and genes of cellular suicide // Science. 1995. V. 267. P. 1445—1449.

42. Walker P.R. Sikorska M. Endonuclease activities and DNA – degradation in apoptosis // Biochim. Cell Biol. 1994. V. 72. P. 615—623.

43. Weedon D., Searl J., Kerr J.F. Apoptosis. Its nature and implications for dermatopathology // Am. J. Dermatopathol. 1979. V. 1. ‹ 2. P. 133—144.

Морфологическая верификация опухолей| Блог UNIM

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

— Соскобы и мазки-отпечатки. Являются распространенным способом диагностики поверхностных изъязвленных опухолей.

— Пункция. Выполняется при поверхностно расположенных узловых образованиях. При малых размерах подозрительных в отношении опухолевого роста образований возможно выполнение пункции под контролем УЗИ.  В неясных случаях прибегают к проведению иммуногистохимических, электронно-микроскопических исследований, иногда выявляющих дополнительные морфологические признаки, позволяющие сопоставить опухоль с исходной тканью.В настоящее время при обнаружении опухоли внутренних органов возможно осуществить морфологическое исследование практически в любой части тела.

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

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

— Трепан-биопсия. Гистологическая верификация может быть получена при использовании специальной иглы или трепана, при этом изымается столбик измененной ткани, пригодный для гистологического исследования. Особенно важным в плане адекватной диагностики распространенности опухолей бывает исследование сомнительных по клиническим данным образований в зонах регионарного метастазирования. В большинстве же случаев сопоставление клинических проявлений опухоли с ее симптомами вне основного очага не требует верификации всех обнаруженных метастазов. Производят морфологическое исследование наиболее доступных вторичных опухолей, что само по себе делает ясным представление об истинной распространенности заболевания. Верификация диагноза осуществляется путем чрезкожной пункции метастаза или забора материала при лапаро- или торакоскопии.

Методы и средства верификации параметров радиочастотных локаторов | Ибрагимова

1. Тревого И. С. Геодезический полигон для метрологической аттестации приборов и апробации технологий // Геопрофи. 2009. № 1. С. 6–11.

2. Патент 2596194 Российская Федерация, МПК B64F 1/22. Космический аппарат для калибровки радиолокационных станций / Полуян А. П.; заявитель и патентообладатель ОАО «Корпорация космических систем специального назначения «Комета». Заявл. 07.04.15, опубл. 27.08.16. 18 с.

3. Патент 2460091 Российская Федерация, МПК G01S13/95. Способ оценки точности доплеровского радиолокатора профилей ветра / Сагитов В. В. [и др.]; заявитель и патентообладатель РФ, от имени которой выступает Минобороны России, АО ЦКБА. Заявл. 02.03.11, опубл. 27.08.12. 11 с.

4. Высотная метеорологическая мачта. Федеральная служба по гидрометеорологии и мониторингу окружающей среды Научно-производственное объединение «Тайфун». [Электронный ресурс]. URL: http://typhoon-tower.obninsk.org/ru/ index.html (дата обращения 21.04.2020).

5. Когерентные допплеровские лидары для мониторинга ветровой обстановки / М. Андреев, Д. Васильев, М. Пенкин, С. Смоленцев, А. Борейшо, Д. Клочков, М. Коняев, А. Орлов, А. Чугреев // Фотоника. 2014. № 6. –. 20–29.

6. Патент 1840999 СССР, МПК G01S7/40. Имитатор движущейся цели / Каретников В. Г. [и др.]; заявитель и патентообладатель НИИ «Квант». Заявл. 02.01.84, опубл. 10.12.14. 7 с.

7. Патент 2498338 Российская Федерация, МПК G01S7/40. Устройство контроля дальномерного канала радиолокационных систем / Горшков С. Н.; заявитель и патентообладатель ОАО МНИИ «Агат». Заявл. 10.07.13, опубл. 10.11.13, 11 с.

8. Патент 2687071 Российская Федерация, МПК G01S7/40. Имитатор пространственного радиолокационного сигнала / Першин В. А. и др.; заявитель и патентообладатель ФГУП «ГосНИИАС». Заявл. 07.09.18, опубл. 07.05.19. 13 с.

9. Патент 186130 Российская Федерация, МПК G01S7/40. Многофункциональный имитатор радиолокационных целей / Боков А. С. и др.; заявитель и патентообладатель ФГАОУ ВО «УРФУ имени первого Президента России Б. Н. Ельцина. Заявл. 04.06.18, опубл. 10.01.19. 7 с.

10. Патент 2502083 Российская Федерация, МПК G01S7/40. Способ калибровки и поверки доплеровского радиолокатора профилей ветра / Хомяков А. В. и др.; заявитель и патентообладатель ОАО ЦКБА. Заявл. 28.04.11, опубл. 20.12.13. 11 с.

11. Patent 0565663 The United States of America, Int Cl. G01S7/40. Programmable fiber optic delay line, and radar target simulation system incorporating the same / Wang, Harry T. et all, proprietor Hughes Aircraft Company Los Angeles, California 90045–0066, filing: 25.09.92, publ. 20.10.93, 11 p.

Использование нескольких методов проверки — обновление

Мы получили следующий вопрос через нашу страницу «Задайте вопрос экспертам»:

« Может (должно) требование иметь более одного метода проверки ?»

Короткий ответ: нет, вы должны указать основной метод проверки, который вы будете использовать, чтобы показать, что интересующая система соответствует заявленным требованиям.

Однако это общий вопрос, и я видел организации, которые перечисляли несколько методов проверки для одного и того же требования.Причины такой практики связаны с непониманием каждого из методов проверки, использованием одних и тех же терминов в разных контекстах, а также с ограничениями английского языка.

Каждая организация должна четко определить каждый из четырех основных методов проверки: тестирование, демонстрация, проверка и анализ. (Я часто вижу подкатегории анализа, которые включают «по моделированию», «по модели», «по сходству» и т. Д.)

Некоторые организации говорят, что они находятся на этапе «Тестирование» проекта, когда на самом деле имеют в виду, что они находятся на этапе проверки, а тестирование — лишь один из четырех основных методов.

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

Дело в том, что тестирование как «действие» является частью методов проверки, таких как Тестирование, Демонстрация и Анализ.

Проверка посредством испытаний включает специальное испытательное оборудование и / или приборы.Это также включает в себя выполнение нескольких «тестов» (действий) для сбора данных в системе, которые продемонстрируют, что требование было выполнено. Поскольку существует несколько наборов собранных данных, мы затем должны проанализировать (активность) данные, чтобы определить, были ли выполнены критерии успешности проверки, чтобы сказать, что проверка с помощью теста (метода) была успешной. Перед запуском этих тестов (действий) мы можем проверить (действие) результаты проверки (метода) требований дочерних элементов к этому требованию.В этом случае метод проверки — Test.

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

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

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

Слово «проверка» часто используется не по назначению («действие против метода»), когда необходимо изучить документы из других действий проверки в качестве предварительного условия для выполнения одного из других методов проверки.Например, я могу проверять, соответствует ли система требованию, которое включает взаимодействие двух подсистем. Перед запуском теста (действия) как части проверки с помощью Test (метода) я могу захотеть изучить документы проверки для каждого из требований дочерних подсистем, чтобы убедиться, что каждая подсистема соответствует требованиям соответствующего интерфейса до интеграции двух подсистемы вместе, а затем проверка того, что интегрированная система соответствует родительскому требованию.В этом случае, даже если я проверил (изучил) (активность) документы проверки нижнего уровня, метод проверки — Тест (или один из других методов проверки).

Однако, если я определю, что родительское требование выполнено, если все действия по проверке были завершены и показываю, что подсистемы выполнили требования к дочерним элементам и никакие другие действия по проверке не требуются, тогда возникает вопрос, каков был метод проверки этого родительское требование? Осмотр, потому что я изучил документы о проверке требований детей? Или, возможно, анализ, потому что на основе моих знаний об успешном завершении действий по проверке требований дочерних элементов и общего знания системы я могу сделать вывод, что набор требований дочерних элементов был необходим и достаточен, так что их реализация приводит к выполнению родительского требования? Для меня в этом случае методом проверки был бы Анализ.В конце концов, вы должны принять решение, а затем быть последовательным в своей организации.

Заключение

Хотя тема кажется сбивающей с толку, именно английский язык доставляет нам неприятности, особенно когда мы используем одни и те же слова, чтобы иметь разные значения. Путаница уйдет, как только мы примем тот факт, что слова, связанные с проверкой системы и ее валидацией, могут относиться либо к «методу» проверки, либо к «деятельности», выполняемой как часть доказательства соответствия системы требованиям (проверка).

Проводя различие между «методом» проверки и «деятельностью» и отделяя методы проверки от действий, сопутствующих выполнению конкретного метода, на самом деле используется только один метод проверки, хотя для предоставления данных может потребоваться несколько видов деятельности. и предоставить доказательства того, что система соответствует или будет соответствовать требованиям.

Также важно понимать, что означают термины «верификация» и «валидация» в зависимости от контекста, в котором они используются.Чтобы понять это, прочтите мой блог, состоящий из двух частей: «В чем разница между верификацией и валидацией?»

Я написал исчерпывающий документ под названием «Забегая вперед к верификации и валидации», в котором содержится более подробная информация. Если вам нужна копия статьи, напишите мне по адресу [email protected], и я пришлю вам копию.

Если у вас есть другие вопросы по требованиям, не стесняйтесь задавать свой вопрос на нашей странице «Задайте вопрос экспертам», и мы сделаем все возможное, чтобы дать своевременный ответ.