Анна Сергеева. Измерение качества тестирования встраиваемых приложений с Atollic TrueANALYZER // Компоненты и технологии. 2015. № 7. С. 78-83
В статье рассмотрены возможности современных инструментов и методологий точного измерения качества тестирования программных приложений для встраиваемых систем. Представлен обзор функциональных возможностей Atollic TrueANALYZER для измерения качества покрытия кода встраиваемых приложений. Одно из основных преимуществ его применения — выполнение всего тестирования непосредственно на целевых отладочных платах.
Опубликовано в разделе "Встраиваемые системы"
Эта же статья на сайте журнала
Введение
В последние годы все большее число разработчиков встраиваемых систем уделяют внимание вопросам тестирования и качества выпускаемых программных продуктов. И интерес этот вполне закономерен, поскольку существует достаточно широкий ряд громких примеров, когда конечные потребители приобретенной продукции обнаруживали в ней значительные дефекты уже в процессе эксплуатации. И, как выяснилось, эти дефекты оказались обусловлены именно программными ошибками.
Современные встраиваемые системы, как правило, содержат на порядок больше строк кода по сравнению с тем, как это было всего лишь несколько лет назад. И, поскольку число ошибок прямо пропорционально возрастает с увеличением объема строк кода, то проблемы риска обнаружения программных ошибок, а также вопросы улучшения тестирования, необходимого для устранения этих ошибок, становятся важнее, чем когда-либо [1].
Но, помимо внедрения тестирования программного кода в процессе его разработки, необходимо также понимать, насколько тщательно это тестирование проведено, и насколько можно доверять полученным результатам и гарантировать высокий уровень качества созданного приложения.
Для ответа на эти вопросы служит измерение качества тестирования. Однако, здесь возникает проблема выбора подходящих методик измерения, достаточно удобных в понимании и использовании, а также гарантирующих достоверные результаты измерений.
К сожалению, практика показывает, что в большинстве случаев тестирование проводится неформально, и практически не предоставляет никаких количественных показателей, которые могли бы помочь в определении уровня тестового покрытия и, соответственно, уровня качества приложения в целом.
В статье рассматриваются возможности современных инструментов и методологий измерения тестирования, которые способны предоставить достаточно точную информацию о качестве проведенного тестирования, причем проводимого при работе приложений на встраиваемых отладочных платах.
Ключевые аспекты тестирования и необходимость автоматизации
Зачастую источником проблем с качеством продукции в области встраиваемых систем являются именно неисправности программного обеспечения. Таким образом, производителям следует уделять как можно больше внимания тестированию разрабатываемого программного обеспечения. Ведь в значительной мере это помогает компаниям своевременно обеспечивать высокое качество продукции своим клиентам.
Традиционный подход с использованием ручных методов тестирования программного обеспечения уже не успевает за постоянно растущим объемом кода в современных встраиваемых приложениях.
Вот перечень наиболее важных аспектов, которые необходимо учитывать в процессе организации и выполнения тестирования [2].
В большинстве случаев, для установления причин возникновения ошибок в коде разработчики пользуются отладчиками. Но, прежде чем исправить ошибку, нужно сначала ее еще обнаружить. При этом важно понимать, что ошибки, обнаруженные до начала тестирования и тем более эксплуатации, обойдутся гораздо дешевле. Поэтому команды разработчиков должны стремиться к тому, чтобы находить и исправлять ошибки на как можно более ранних этапах цикла разработки.
Кроме того, обычно в процессе тестирования выявляется множество самых разнообразных ошибок. Но для получения уверенности в том, что тестирование действительно вызвало улучшение качества программного обеспечения, необходимо также понимать и качество самих проводимых тестовых процедур.
Не меньшую важность имеет и ответ на вопрос, покрывают ли имеющиеся тесты 100% всего исходного кода приложения. Ведь если тестовые процедуры затрагивают лишь незначительную часть общего объема кода, что встречается на практике не так уж и нередко, то необходимо установить, что именно было протестировано в действительности, а что только еще предстоит проверить. К сожалению, методы ручного тестирования зачастую не в состоянии дать ответы на эти вопросы [3].
Теперь для эффективного выполнения тестов, лучшего контроля, отчетности и анализа тестовых воздействий становятся востребованными методики и средства уже совершенно другого уровня.
Среди наиболее успешно применяемых на практике средств автоматизации тестирования программных приложений для встраиваемых систем можно назвать пакет Atollic TrueANALYZER. Он содержит набор мощных профессиональных инструментов автоматизации для проведения целевого тестирования встраиваемых систем на отладочных платах. Возможности Atollic TrueANALYZER в полной мере отвечают требованиям, предъявляемым к тестированию современных встраиваемых приложений [4].
В следующих разделах приводится более подробная информация о методиках измерения качества тестирования встраиваемых систем и о путях автоматизации этой работы с помощью подходящих инструментов.
Как измерить качество тестирования
По завершению этапов разработки и тестирования кода, внимание смещается к количественному пониманию объема и качества работы, выполненной в действительности во время тестирования.
При подготовке и исполнении наборов тестов необходимо учитывать важный момент. Не так уж велика польза от достижения 100% успеха прохождения тестов, если они покрывают лишь незначительную часть кода, в то время как большая часть кода остается совершенно не охваченной тестированием и потенциально содержит множество не обнаруженных (и, как следствие, не исправленных) ошибок.
И здесь совершенно неправомерно считать, что тестирование завершилось с успешными результатами, если исследованию подверглась только лишь часть кода программного обеспечения. Так, при применении одного лишь ручного тестирования, которое не в состоянии охватить полностью весь объем кода, в результате исследований будет получен код, который “работает случайным образом”. И при проведении более тщательного анализа, дальнейшее тестирование участков кода, которые ранее оказались не проверенными, вполне может привести к неуспешным результатам.
Так что, понимание качества выполняемых тестовых процедур становится критичным при оценке того, достаточно ли тщательно разрабатываемый программный продукт протестирован до выпуска в готовом виде на рынок.
Анализ тестового покрытия для измерения качества тестирования
Хорошим средством измерения качества тестов является анализ тестового покрытия исходного кода приложения. В ходе такого анализа исследуется динамический поток выполнения программ.
Чаще всего такое измерение покрытия кода применяется для исследования, какие части кода были протестированы, а какие остались без внимания. Таким образом, эта оценка является прямым показателем качества тестирования [5], [6].
Как будет наглядно показано далее, даже самые простые участки кода бывает очень сложно протестировать тщательно. И чтобы обеспечить достаточно тщательное тестирование, должны быть исполнены все блоки кода, должны быть пройдены все ветви и должны быть проверены все вложенные выражения всех ветвей условных операторов.
И вместе с тем, как разработчики все более усложняют свой код, стремительно растет и число возможных подстановок и их комбинаций. То есть, тестирование становится все более и более сложным.
Существует общепринятая формальная классификация методов анализа тестового покрытия, начиная от самых примитивных до наиболее строгих по требованиям к качеству покрытия. Разумеется, более строгие методы анализа покрытия потребуют больше усилий и больше тестов, но именно за счет этого можно выявить больше потенциальных проблем в коде.
Кстати говоря, среди инженеров-тестировщиков программного обеспечения очень распространено заблуждение, что достаточно и самого простого анализа, поскольку это не так уж сложно и не требует значительных усилий и времени. Но на самом же деле, для определения, действительно ли разрабатываемый продукт протестирован достаточно тщательно и должным образом, зачастую требуются куда более сложные методы анализа.
И вот здесь у руководства проекта возникает мысль, что сложный анализ потребует больших усилий тестировщиков, займет много их рабочего времени, и не лучшим образом скажется на сроках поставки готовой продукции. Возможно, руководство даже принимает решение отказаться от этой идеи вовсе.
Но это лишь заблуждение. Ведь существуют специальные инструменты, такие как Atollic TrueANALYZER. Он способен оказать разработчикам и тестировщикам существенную помощь и поддержку. Atollic TrueANALYZER поддерживает самые строгие виды анализа покрытия кода, которые могут быть использованы разработчиками и тестировщиками без заметных дополнительных усилий, и в автоматическом режиме.
Важность тщательного тестирования сложными методами для критичных систем
Для критичных по безопасности встраиваемых систем качество тестирования до запуска в эксплуатацию имеет решающее, а в ряде случаев даже жизненно важное значение.
В качестве достаточно серьезного примера, можно привести стандарт RTCA DO-178B [7]. Он применяется для разработки критичного по безопасности ПО для летательных аппаратов. И требует для всех наиболее критичных компонентов авиационного бортового ПО, где программная ошибка может привести к катастрофическим последствиям вплоть до потери воздушного судна и человеческих жизней, проводить тестирование по модифицированному методу MC/DC (суть его будет подробно рассмотрена в следующих разделах).
И такой подход применим далеко не только к авиационно-космической отрасли.
Он прекрасно подходит для всех компаний, поставляющих продукцию в крупных объемах. Ведь если с дефектами от программных ошибок столкнется достаточно большое число клиентов, то и исправление этих проблем обойдется весьма недешево.
Также подход хорош и для разработчиков систем, обновлять которые уже в ходе их практической эксплуатации окажется слишком трудоемким или дорогостоящим процессом (например, критичные к остановке и отключению системы или работающие на значительно удаленных объектах).
И, конечно, во всех случаях, когда поставщики стремятся сохранить свою хорошую репутацию, любые дефекты предлагаемого ими программного обеспечения могут дорого обойтись компании, снижая репутацию в отрасли, степень доверия клиентов к компании и долю на рынке.
Все эти доводы указывают на необходимость применения анализа покрытия кода для выяснения, достаточно ли хорошо протестирован код разработанного ПО. И проводить эти работы нужно непременно до завершения разработки программных продуктов и уж тем более до поставки клиентам.
Обзор типов анализа покрытия кода
Итак, перейдем к более детальному знакомству с применяемыми на практике методами анализа покрытия кода.
В качестве исследуемого участка кода рассмотрим такой пример (рис. 1).
Рис. 1. Исследуемый участок кода
Как видно из рисунка, даже относительно простые конструкции кода приводят к возникновению множества возможных путей исполнения. В данном случае, имеем три блока кода. Красный блок исполняется всегда. Зеленый блок исполняется в зависимости от некоторых условий, выполняемых или нет при обработке выражения IF. Синий блок, опять же, исполняется всегда.
Структуру этого исследуемого участка кода можно представить в виде диаграммы потока выполнения (на рисунке справа). Из диаграммы наглядно видно, что существует два возможных пути выполнения кода: один из красного блока сразу в синий, и второй с прохождением зеленого блока. Выбор того или иного пути выполнения кода осуществляется при обработке выражения IF.
Рассмотрим, как работают наиболее распространенные методы анализа кода на примере этого конкретного участка кода.
Метод покрытия по выражениям или блокам кода
Данный метод предоставляет только возможность определить, какое количество выражений языка C или блоков кода было выполнено на протяжении данного сеанса тестирования (поскольку каждый блок кода имеет фиксированный набор выражений, то суть у этих двух измерений одна и та же). Принцип метода показан на рис. 2.
При этом, метод покрытия по выражениям или блокам кода не дает возможности оценивать, каким образом ветви, встречающиеся в потоке выполнения, влияют на то, какие выражения или блоки кода будут выполнены.
Рис. 2. Применение метода покрытия по выражениям и блокам кода
Этот вид анализа покрытия кода является наименее строгим, так как способен только лишь определять, какие части кода были выполнены, но без учета сопутствующих обстоятельств. Как правило, для обеспечения приемлемого качества тестирования единственное применение данного метода не будет достаточным.
Метод покрытия функций кода
Данный метод позволяет оценить, какие именно С-функции были вызваны на протяжении данного сеанса тестирования, и какую часть от общего числа С-функции, содержащихся в коде, они составляют. Суть метода показана на рис. 3.
Рис. 3. Применение метода покрытия функций кода
Тем не менее, этот метод не позволяет определить, какие именно вызовы функций были выполнены фактически, а также оценивать качество тестирования самих этих функций.
Метод покрытия функций кода также не относится к числу строгих, и в большинстве случаев, его применение не достаточно, чтобы претендовать на высокий уровень качества тестирования.
Метод покрытия вызовов функций
Этот метод дает возможность оценить, какие вызовы функций фактически были выполнены на протяжении данного сеанса тестирования, а также понять, каким образом эти вызовы осуществлялись (рис. 4).
Рис. 4. Применение метода покрытия вызовов функций
Конечно, метод покрытия вызовов функций не стоит причислять к числу наиболее прогрессивных видов анализа покрытия кода. Тем не менее, он является достаточно хорошим средством оценки числа выполненных вызовов функций.
Метод покрытия ветвей кода
Метод покрытия ветвей кода позволяет оценить, все ли ветви, из числа возможных по ходу выполнения, были пройдены в процессе тестирования.
Метод покрытия ветвей требует, чтобы исследуемый участок кода был выполнен достаточное число раз, чтобы протестировать все возможные альтернативные ветви в пути выполнения этого кода. Соответственно, при обходе всех ветвей выполняются и все используемые в них блоки кода.
Рис. 5. Применение метода покрытия ветвей
Результатами исследуемого выражения, подсвеченного на рис. 5 желтым цветом, являются логические значения TRUE (1) и FALSE (0). Однако, при этом остается неизвестным, какие результаты вложенных выражений повлияли на принятие решения о выборе той или иной ветви в пути выполнения кода. Таким образом, для получения результатов TRUE и FALSE данное выражение должно быть протестировано, по меньшей мере, 2 раза.
Модифицированный метод покрытия по ветвям/условиям (MC/DC)
Модифицированный метод покрытия по ветвям/условиям (Modified Condition/Decision Coverage или MC/DC) является очень качественным средством анализа покрытия исходного программного кода. Он широко применяется для приложений, в которых необходимо обеспечить наиболее высокий уровень надежности.
По сути, это усовершенствованный метод покрытия ветвей с дополнительным требованием: все вложенные выражения, задействованные в принятии комплексного решения по конкретной ветви (например, в случае составного выражения IF), должны оказывать влияние на принятие этого решения вне зависимости друг от друга.
Это означает, что исследуемый участок кода должен быть выполнен большее число раз, чем при применении менее строгих методов анализа. Причина здесь в том, что необходимо обрабатывать различные комбинации входных значений, за счет которых вложенные выражения влияют на прохождение кода по различным путям выполнения.
Рис. 6. Применение модифицированного метода покрытия по ветвям/условиям
В приведенном примере (рис. 6) выражение проверяется таким образом, что учитываются все результаты обработки вложенных выражений (a, b, c) во всех ветвях кода. При этом, каждое из вложенных выражений каждый раз оказывает влияние на ход выполнения кода вне зависимости от других вложенных выражений. Все блоки кода будут выполнены, и все ветви обойдены. Так что, данное выражение должно быть протестировано, по меньшей мере, 4 раза.
Опять же, число возможных путей выполнения программы в значительной мере зависит от результатов обработки условных выражений. И, разумеется, этот факт довольно сложно адекватно учитывать при ручном тестирования.
Модифицированный метод покрытия по ветвям/условиям (MC/DC) — это чрезвычайно строгий тип анализа тестового покрытия кода. И на практике он широко применяется для оценки качества тестирования самых разнообразных программных приложений, критичных по безопасности. Так, например, требование к обеспечению качества по методу MC/DC распространено при тестировании ПО для бортовых систем управления в летательных аппаратах.
Проблема выбора инструментов для измерения качества тестирования
До сих пор было достаточно трудно подобрать инструменты для измерения качества тестирования программного обеспечения, подходящие для встраиваемых систем. Те немногие инструменты, которые существовали, имели одно или несколько из следующих ограничений:
-
Поддержка только слабых типов анализа кодового покрытия.
-
Тестирование возможно только на симуляторах на базе настольных персональных компьютеров, но не на целевых встраиваемых отладочных платах.
-
Высокая стоимость инструментов.
-
Сложность использования.
-
Отсутствие возможности интегрирования с другими инструментами разработки встраиваемых систем.
Преимущества Atollic TrueANALYZER
Теперь пришло время новых усовершенствованных средств, среди которых можно назвать Atollic TrueANALYZER. Он поддерживает широкий диапазон всевозможных типов анализа покрытия кода, от слабых до самых строгих, что так важно в случае разработки ПО для критичных встраиваемых систем. Кроме того, он превосходно интегрируется с другими инструментами разработчиков встраиваемых приложений, что делает их работу легче, удобнее и эффективнее. И, разумеется, это положительно влияет на качество разрабатываемых программных продуктов.
Одним из наиболее существенных преимуществ Atollic TrueANALYZER является то, что анализ проводится непосредственно на целевых встраиваемых системах. Этот достаточно мощный инструмент очень прост в использовании и при этом поддерживает широкий ряд полезных функциональных возможностей для измерения качества тестирования кода:
-
Метод покрытия по выражениям или блокам кода;
-
Метод покрытия функций кода;
-
Метод покрытия вызовов функций;
-
Метод покрытия ветвей кода;
-
Модифицированный метод покрытия по ветвям/условиям (MC/DC).
На рис. 7 показано, как Atollic TrueANALYZER сочетает применение всех этих методов для достижения лучших результатов и для наиболее эффективного измерения качества тестового покрытия.
Рис. 7. Atollic TrueANALYZER сочетает несколько методов для повышения эффективности оценки
Кроме того, некоторые инструменты покрытия кода используют для анализа данные буферизации, полученные в ходе трассировки JTAG-инструкций.
Однако, в ходе такой трассировки, даже в случаях кратковременного запуска выполнения, генерируется огромное количество данных. И, как правило, могут быть записаны данные только лишь о считанных секундах функционирования исследуемых систем. Так что, зачастую применять подобные инструменты для полномасштабного тестирования не представляется возможным.
Вот несколько типичных примеров. Испытания микроволновой печи, пока она размораживает курицу. Или исследование поведения какого-либо человеко-машинного интерфейса, который требует многократного взаимодействия с пользователем. Или управление некоторым подвижным механизмом, который передвигается очень медленно и в течение длительного периода времени.
Конечно, для таких случаев необходимы качественно другие инструменты.
Atollic TrueANALYZER использует относительно небольшой объем памяти, который не возрастает с увеличением времени выполнения тестов. И поэтому этот инструмент с успехом используется для исследований, требующих нескольких минут или даже часов выполнения.
Принципы работы с Atollic TrueANALYZER
Работа с Atollic TrueANALYZER осуществляется следующим образом (рис. 8). Данный инструмент подключается к целевой плате в режиме JTAG-отладки и взаимодействует с ней точно так же, как и в процессе системного программирования. Исследуемое встраиваемое приложение запускается непосредственно на целевой плате, и вся собранная информация о покрытии кода записывается для последующего изучения и количественного анализа.
Рис. 8. Схема работы с Atollic TrueANALYZER для измерения качества тестового покрытия на целевой плате
Тот факт, что анализ покрытия кода выполняется как приложение, запускаемое на целевой системе, является критически важным. Ведь нет никакой гарантии, что тесты, выполняемые на ПК, в среде симуляции, будут достоверным образом эмулировать взаимодействие целевой системы со всеми внешними факторами, встречающимися в реальности. А это значит, что один и тот же тест, который успешно проходит на симуляторе, может завершиться неуспехом при запуске на целевой отладочной плате.
Таким образом, однозначно достоверное тестирование возможно только на целевых системах, со всеми их потоками ввода/вывода, включая интерфейс пользователя, пакеты передачи данных, показания датчиков и сенсоров и т.д.
В процессе работы возможно привлечение оператора или внешней системы, предоставляющей стимулирующие воздействия для того, чтобы код тестируемого приложения проходил различные пути выполнения.
Применяя такой подход, Atollic TrueANALYZER имеет значительное преимущество по сравнению с другими средствами тестирования, доступными в настоящее время для разработчиков встраиваемых систем.
Отображение результатов измерения тестирования
По завершению очередного сеанса тестирования Atollic TrueANALYZER загружает полученную информацию о покрытии (качестве тестирования) кода исследуемого приложения и отображает результаты своей работы на трех доступных уровнях абстракции:
-
Общее покрытие в пределах всего разрабатываемого проекта.
-
Покрытие по каждой из C-функций.
-
Покрытие по каждой из строк кода.
В первых двух случаях, результаты представлены в виде таблиц, а в последнем случае информация о покрытии отображается с помощью цветовой подсветки исходного кода в редакторе (рис. 9).
Рис. 9. Отображение результатов измерения тестирования в Atollic TrueANALYZER
В секции Coverage result > Summary приводится общая информация об измерении покрытия всего проекта всеми поддерживаемыми методами: покрытия функций (Function coverage), блоков кода (Block coverage), ветвей (Branch coverage), вызовов функций (Call coverage) и по методу MCDC. Значения представлены в процентном и абсолютном выражении.
Ниже следует таблица результатов измерений покрытия по C-функциям. Указываются имя функции (Function Name) и значения, полученные при расчете по каждому из методов.
При нажатии в этом окне на имени конкретной функции, в нижней панели открывается соответствующий файл исходного кода, и в редакторе отображается исходный код данной функции. Для наглядности, строки протестированного и невыполненного кода имеют разную цветовую подсветку.
Но такой вид отображения показателей измерения качества тестирования предоставляет только информацию о достигнутом уровне качества тестирования, а это еще не все.
Также Atollic TrueANALYZER позволяет наглядно увидеть, где и почему тестовые процедуры не обеспечивают достаточное покрытие. Таким образом, поддерживается хорошая возможность отлаживать и совершенствовать тестовые случаи, чтобы они покрывали больше частей разрабатываемого кода.
В частности, в результате измерений по методу MC/DC отображаются все решения, принятые по всем ветвям для каждой из C-функций, а также информация о покрытии для каждого из условий в этих ветвях (рис. 10).
Рис. 10. Отображение результатов измерений по методу MC/DC
Здесь приводится порядковый номер каждой записи (No.), принятое решение (Decision), условие принятия решения (Condition), соответствующее выражение (Expression). В колонке Covered указывается признак покрытия данного варианта, то есть, все ли условия в данной ветви принятия решений удовлетворяют требованиям покрытия по методу MC/DC.
Кроме того, для всех составных решений по ветвям отображается таблица истинностей, так что можно наглядно видеть, какие комбинации условий не обработаны и, таким образом, не сыграли в пользу улучшения тестового покрытия.
Здесь указываются порядковый номер каждого тестового случая (Case No.), общий результат его обработки (Result), а также результаты обработки каждого из вложенных условий (в примере, C0, C1 и C2).
Другими словами, средства просмотра результатов измерений по методу MC/DC выступают в качестве отладчика тестовых случаев, позволяя разработчикам быстро понять, почему имеющийся набор тестовых случаев не обеспечивает достаточно высокое покрытие.
Стоит дополнить, что совместное использование информации с этих двух форм (рис. 9 и 10) позволяет получить ясную однозначную картину того, какой уровень тестового покрытия (а значит, и уровень качества тестирования) был достигнут, а также, какие конкретные тестовые случаи обработаны не лучшим образом и по какой причине.
Подводя итоги, можно утверждать, что использование Atollic TrueANALYZER позволяет разработчикам измерять качество тестирования и проводить отладку процедур тестирования, а значит, и находить больше ошибок в программном коде до момента передачи готового ПО клиентам для эксплуатации. Это хорошее средство для точного определения уровня достигнутого качества тестирования, и, следовательно, для уверенности в качестве предоставляемых программных продуктов.
Заключение
Программное обеспечение для встраиваемых систем становится все более объемным и сложным с каждым годом. И необходимы улучшенные методы тестирования и отображения результатов, которые способны оказать существенную помощь в создании целесообразных наборов тестов для обнаружения и исправления ошибок и ненадлежащей реализации.
И все же, нередко команды разработчиков пренебрегают необходимостью проведения количественных измерений качества выполняемого тестирования, поскольку считают этот этап работ слишком трудоемким или затруднительным для их понимания.
Однако, инструмент Atollic TrueANALYZER является простым и удобным в ежедневном применении для большинства разработчиков встраиваемых систем. При этом, он с успехом справляется с задачей измерения качества тестирования, проводимого непосредственно на отладочных целевых платах.
Возможности Atollic TrueANALYZER позволяют применять достаточно высокую степень строгости оценки, на уровне программных приложений для бортовых систем управления полетами. А это является существенным определяющим фактором для гарантированной успешной разработки критичных по безопасности встраиваемых систем.
Литература
[1] А. Сергеева. Возможности статического анализатора Atollic TrueINSPECTOR для повышения качества встраиваемых приложений. // Компоненты и технологии. 2015. № 4.
[2] А. Сергеева. Тестирование работоспособности промышленного компьютера. // Компоненты и технологии. 2014. № 2.
[3] А. Сергеева. Автоматизация модульного тестирования с Atollic TrueVERIFIER для повышения качества встраиваемых приложений // Компоненты и технологии. 2015. № 5.
[4] Об инструменте Atollic TrueANALYZER. http://www.atollic.com/trueanalyzer/
[5] А. Сергеева. Применение реинжиниринга при проектировании встраиваемых систем. Часть 1 // Компоненты и технологии. 2014. № 9.
[6] А. Сергеева. Применение реинжиниринга при проектировании встраиваемых систем. Часть 2 // Компоненты и технологии. 2014. № 10.
[7] О стандарте RTCA. http://www.rtca.org/