Прекратите перерывать документы в поисках причин выбора этой детали

Adam J. Fleischer
|  Создано: 16 Января, 2025
Прекратите перерывать документы в поисках причин выбора этой детали

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

Скрытые затраты утраченной истории проекта

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

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

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

Документация требований в новом измерении

Так же, как археологам необходимо тщательно каталогизировать и организовывать свои находки, инженерам нужны эффективные способы управления большим количеством требований в сложных проектах. Altium 365 Requirements & Systems Portal (RSP) преобразует способ документирования и отслеживания решений по компонентам. Через панель требований как в Altium Designer, так и в веб-интерфейсе Altium 365, команды работают с требованиями непосредственно в своей среде разработки. Каждое требование отображает свою информацию, настройки валидации и прямые ссылки на его экземпляр в RSP, обеспечивая работу всех с актуальной информацией.

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

RSP интегрируется с проектами проектирования печатных плат через диалоговое окно "Связать требования", где команды устанавливают связи между проектами в рабочем пространстве и блоками системного проектирования. Это сопоставление может управляться через панель требований Altium Designer для прямого взаимодействия с дизайном или через веб-интерфейс Altium 365 для более широкого управления проектом. 

Проверка и управление задачами

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

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

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

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

Совместная работа в реальном времени в контексте

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

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

Практическая реализация и управление

Перенос существующих требований к компонентам в RSP не означает начало с нуля. Система предлагает простые возможности импорта для файлов Excel через простой процесс перетаскивания, позволяя командам быстро переходить с систем, основанных на таблицах. Другие форматы документации, такие как Word, могут требовать дополнительного форматирования.

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

Документация с поддержкой ИИ

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

AI-Assisted Documentation

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

Прекратите копаться и начните инновации

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

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

Заинтересованы в управлении требованиями и системной инженерии на основе ИИ? Откройте для себя Altium 365 RSP сегодня!

Об авторе

Об авторе

Adam Fleischer is a principal at etimes.com, a technology marketing consultancy that works with technology leaders – like Microsoft, SAP, IBM, and Arrow Electronics – as well as with small high-growth companies. Adam has been a tech geek since programming a lunar landing game on a DEC mainframe as a kid. Adam founded and for a decade acted as CEO of E.ON Interactive, a boutique award-winning creative interactive design agency in Silicon Valley. He holds an MBA from Stanford’s Graduate School of Business and a B.A. from Columbia University. Adam also has a background in performance magic and is currently on the executive team organizing an international conference on how performance magic inspires creativity in technology and science. 

Связанные ресурсы

Связанная техническая документация

Вернуться на главную
Thank you, you are now subscribed to updates.