Программно-определяемые продукты создаются для того, чтобы сделать нашу жизнь проще, будь то функции автоматического помощника в современных автомобилях, сложные системы управления коммерческими самолетами или интеллектуальное оборудование, оптимизирующее производство на заводском цехе.
По мере того как эти продукты становятся более интуитивными и простыми в использовании, поддерживающее их программное обеспечение неизбежно становится все более сложным. Этот парадокс применим ко многим отраслям: от автомобилестроения, аэрокосмической и оборонной промышленности до промышленного оборудования и энергетических систем.
Естественно, по мере роста сложности увеличиваются и инженерные проблемы. Каждая новая функция влечет за собой целый ряд новых зависимостей, взаимодействий и требований, с которыми необходимо разобраться. Для инженеров задача заключается не только в том, как написать больше программного обеспечения, но и в том, как создавать и проверять его с уверенностью.
Сложность опережает традиционные инженерные практики
Тем не менее инженеры продолжают сталкиваться с одними и теми же трудностями, когда их внимание разрывается между несколькими направлениями. Потребители ожидают больше функций, в то время как компании настаивают на сокращении циклов разработки и снижении затрат. В ответ от инженерных команд ждут значительного масштабирования результатов без ущерба для качества, безопасности и защищенности.
Интеграция становится критической точкой во время разработки, поскольку программное обеспечение должно работать с аппаратным обеспечением, сетями и другими связанными компонентами в ответ на пользовательский ввод и другие факторы окружающей среды. Это привлекает множество команд из различных дисциплин, поставщиков и организаций, работающих с различными инструментами и процессами для выявления проблем с компонентами, которые часто проявляются при их объединении.
Инженерная сложность возрастает по мере того, как в рамках одной системы сходятся воедино все новые функции, зависимости и подключенные технологии.
В таких условиях традиционный, ручной и часто изолированный подход к работе оказывается недостаточным, за чем обычно следуют дефекты на поздних этапах.
«Мы видим, что наши заказчики сталкиваются со все большими трудностями при интеграции программного обеспечения в систему», — говорит Роберт Фей (Robert Fey), директор по развитию бизнеса в Synopsys. — «Мы наблюдаем множество дефектов на поздних стадиях, что для нас является индикатором. И это проблемы, которые люди хотят решить».
Организации реагируют на это внедрением искусственного интеллекта, цифровых двойников, модельно-ориентированного системного проектирования и новых фреймворков тестирования для ускорения инженерных процессов.
Искусственный интеллект может помочь инженерам создавать артефакты, анализировать данные и более эффективно выявлять закономерности. Тем не менее его эффективность во многом зависит от качества, согласованности и структуры потребляемой им инженерной информации. Когда требования, модели и активы валидации фрагментированы, ИИ может усиливать несоответствия так же легко, как и ускорять производительность.
Скорость имеет значение. Но скорость без структуры не масштабируется.
Структура становится инженерной необходимостью
Внедрение структуры в программно-определяемый процесс разработки дает командам возможность осмысливать более сложные задачи, а не просто реагировать на них. Структурированный подход связывает требования с предполагаемым поведением, предполагаемое поведение — с реализацией, а реализация — с доказательствами того, что система была оценена должным образом.
Управляемая требованиями, модельно-ориентированная разработка не опирается на реализацию при определении продукта. Вместо этого команды могут создать модель, определяющую поведение программного обеспечения в соответствии с заданным набором правил. Цель состоит в том, чтобы сделать сложное программное обеспечение более понятным, пригодным для проверки и обслуживания.
«Программное обеспечение Ansys SCADE имеет отношение к этому подходу, поскольку оно предлагает модельно-ориентированный, формально структурированный подход к разработке программного обеспечения», — говорит Венсан Россиньоль (Vincent Rossignol), старший менеджер по управлению продуктами в Ansys, входящей в состав Synopsys. — «Оно было создано специально для поддержки создания инженерного представления, которое сохраняет замысел по мере изменения реализации и эволюции продуктов. Это особенно важно для систем с длительным жизненным циклом».
Сложный, программно-определяемый продукт не обязательно имеет конечный жизненный цикл. Его может потребоваться обновить, исследовать или адаптировать после разработки, чтобы понять, что и зачем было создано, а также как любые будущие изменения могут на него повлиять. Структурированные артефакты (модели) обеспечивают преемственность между командами, создающими продукт, и теми, кто отвечает за него в дальнейшем.
Верификация сталкивается с собственным кризисом сложности
Разработка программно-определяемых продуктов — это лишь половина задачи. Практики верификации и валидации должны масштабироваться вместе с программным обеспечением, которое они призваны оценивать.
Рассмотрим традиционный подход, основанный на требованиях. Он извлекает тестовые сценарии из требований, конструирует ситуацию, применяет входные данные, а затем определяет, соответствует ли наблюдаемый результат ожидаемому поведению. Однако при применении к разработке программного обеспечения его практические ограничения становятся более очевидными по мере увеличения числа условий эксплуатации.
«В этом сценарии одно можно сказать наверняка», — говорит Фей. — «Ни одна команда не может протестировать каждую возможную комбинацию скорости, состояния системы, действий пользователя, условий окружающей среды и взаимодействия компонентов. Временные затраты часто перевешивают преимущества. В этом случае верификация зависит от того, что должно быть расставлено в приоритете для тестирования и когда доказательств становится достаточно для достижения валидации».
Существует также то, что происходит после создания тестовых сценариев.
Эти долговечные инженерные активы должны сохраняться и пересматриваться по мере изменения системы. Их тестирование тесно связано с деталями реализации, что может вызвать каскадный эффект сбоев, если базовые требования не учтены.
Хотя программное обеспечение может быстро изменяться, оценка, устранение и повторный запуск затронутых тестов могут создавать серьезные узкие места. Инженеры обнаруживают, что тратят больше времени на различие между реальными дефектами продукта и обслуживанием тестов, чем на сами проблемы.
От изолированных тестовых сценариев к повторно используемым знаниям о поведении
Более масштабируемая методология валидации разделяет две концепции, которые часто объединены вместе: ситуацию, используемую для стимулирования системы, и поведение, ожидаемое в ответ.
«Тест может включать и выключать свет несколько раз для проверки различных внутренних состояний», — говорит Фей. — «Вместо того чтобы описывать ожидаемый результат каждый раз, когда это действие появляется, инженер может определить правило поведения один раз: всякий раз, когда выключатель включен, свет должен гореть; всякий раз, когда выключатель выключен, свет должен быть выключен. Затем это правило может быть проверено в различных тестовых ситуациях».
Какой эффект этот метод оказывает на валидацию?
«Это разделение превращает ожидаемое поведение в повторно используемые инженерные знания», — говорит Фей. — «Если требование меняется, вместо изменения каждого теста по отдельности можно обновить соответствующее правило и применить его ко всем релевантным тестам. Ценность заключается не просто в меньшем количестве правок. Это более прочное соответствие между требованием, ожидаемым поведением и результатами, полученными в ходе валидации».
Инструмент тестирования встроенного программного обеспечения Ansys TPT отделяет симуляцию тестов от критериев оценки и поддерживающих правил, полученных из требований, позволяя командам фиксировать поведенческие намерения независимо от конкретных сценариев. Эти повторно используемые знания о валидации могут сократить объем повторяющейся работы, облегчить внедрение изменений и помочь организациям, занимающимся тестированием, идти в ногу с разработкой.
Сокращение цикла обратной связи между разработкой и тестированием
Инженерные команды могут извлечь огромную пользу из сочетания структурированной разработки программного обеспечения и валидации. Основа, опирающаяся на требования, обеспечивает общую базу.
Программное обеспечение SCADE предоставляет командам разработчиков структурированное представление программного обеспечения, в то время как TPT дает командам валидации структурированный подход к тестам и правилам поведения. Благодаря их интеграции тестировщики могут работать с элементами на уровне моделей из своей собственной среды, выполнять тесты на основе требований, вычислять покрытие модели и передавать результаты обратно в среду разработки для дальнейшего анализа.
«Используя эту комбинацию инструментов, разработчики могут видеть сбои в терминах требований, ситуаций и соответствующего поведения с течением времени», — говорит Россиньоль (Rossignol). «Повторное использование тестовых данных в среде разработки также снижает усилия, необходимые для воссоздания проблемы. Разработка и тестирование переходят от “сбоя тестирования” к “изменениям поведения в этих конкретных условиях”».
С этой точки зрения тестировщики и разработчики могут сформировать общее понимание поведения системы, что приводит к более глубокому пониманию в процессе разработки.
Взгляд на переход от ручного тестирования на уровне моделей к интегрированной автоматизированной валидации на протяжении всего жизненного цикла разработки.
Взгляд в будущее
В гонке за инновациями, определяемыми программным обеспечением, победителями выйдут те, кто будет рассматривать модели, требования, тесты и правила валидации как многократно используемые (а не одноразовые) знания, поддерживаемые структурированным подходом к разработке.
«Системы, определяемые программным обеспечением, продолжат становиться все более функциональными», — говорит Фей (Fey). «С этим приходит и большая сложность. Проблема больше не сводится только к созданию программного обеспечения. Речь идет о его понимании, валидации и развитии. Организации, занимающиеся разработкой, которые лучше всего подготовлены к будущему, — это те, которые смогут объяснить, что должно делать их программное обеспечение, продемонстрировать, как оно оценивалось, понять, почему оно дало сбой, и безопасно развивать его с течением времени».
Чтобы узнать больше о том, как программное обеспечение SCADE и программное обеспечение TPT могут использоваться для поддержки разработки, определяемой программным обеспечением, обязательно ознакомьтесь с материалами «Внедрение структуры в разработку и тестирование встроенного программного обеспечения управления с помощью SCADE и TPT» (Bringing Structure in the Development and Testing of Embedded Control Software with SCADE and TPT) и «Представляем Ansys TPT — тестирование встроенного программного обеспечения» (Introducing Ansys TPT, Embedded Software Testing).
