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

Процесс разработки РКД на основе технического проекта обычно включает следующие типовые шаги:

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

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

3. Уточнение конфигурации продукта для подсистем более низкого уровня вплоть до уровня компонентов.

4. Определение всех интерфейсов (между системами и их нижестоящими системами и компонентами) и разработка требований ко всем интерфейсам (глава 3.6).

5. Создание чертежей и пространственных моделей деталей, узлов и сборочных единиц. На практике приходилось проверять 3-Д сборочные узлы объемом до пятидесяти тысяч входящих единиц деталей.

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

7. Выполнение анализа видов и последствий отказов перед запуском проекта в производство.

8. Сборка проверенных компонентов в модули и подсистемы более низкого уровня и проведение испытаний для проверки соответствия собранных подсистем и компонентов заданным требованиям.

9. Выполнение финальной сборки для создания продукта в целом.

10. Проведение валидации продукта, чтобы убедиться, что он соответствует всем заявленным требованиям, прежде чем будет запущен в производство.

11. Документирование набора технических данных продукта.

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

• Документ должен быть написан на языке заказчика или пользователя.

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

• Информация в документе должна быть упорядочена в соответствии с утвержденным общим шаблоном.

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

• Все определения должны быть однозначными.

• Все формулировки должны быть четкими и краткими.

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

• Документ не должен содержать избыточной или копируемой информации.

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

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