Читать книгу Инновации от идеи до рынка - Виктор Юрьевич Николенко - Страница 9

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

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

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

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

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

Основные особенности этапа синтеза:

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

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

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

• Выполняют анализ проекта системы для подтверждения соответствия результатов предварительного проектирования системным требованиям.

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

В рамках системного подхода к разработке важно раннее рассмотрение всех целей и ограничений:

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

• Стоимость. Напомним, что дизайн определяет более трех четвертей стоимости продукта.

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

• Качество и надежность. Эти потребительские свойства определяются конструкцией, количеством и конфигурацией деталей. Разработчики несут ответственность за чувствительность допусков. Качество и надежность обсуждаются далее в главах 5.1 и 5.2 соответственно.

• Простота сборки. Представленные в главе 4.3 рекомендации по ПЗС оптимизируют простоту сборки благодаря конструкции, независимо от объемов производства.

• Простота обслуживания и ремонта. Конструкция должна допускать, чтобы было легко обслуживать и ремонтировать продукт. ТОиР в полевых условиях могут потребовать проектирования дополнительного оборудования. Подробности изложены в главе 5.4.

• Управление цепочками поставок. Его можно значительно упростить за счет стандартизации деталей и заготовок, выбора деталей на основе их адекватной доступности с течением времени.

• Доставка и распространение. Распространение продукции зависит от прогнозов спроса рынка. Хранение запасов стоит денег, иногда до 25% от их стоимости в год. Экологически чистые упаковочные материалы и переработанная упаковка становятся все более важными.

• Безопасность продукта для пользователей. Необходимо использовать моделирование, чтобы предотвратить проблемы безопасности до того, как они проявятся. Детали можно посмотреть в главе 5.5.

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

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

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

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

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

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

1) что окончательный проект соответствует требованиям и общей намеченной цели проекта;

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

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

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

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