Прослеживаемость (трассировка) и иерархия требований также являются важными компонентами для проверки происхождения и правильности формулировки. После декомпозиции требований верхнего уровня на нижние уровни свойство прослеживаемости идентифицирует отношения и связи между требованиями разных уровней и их источниками. Очень важно отслеживать, где были введены требования, уточнением какого требования они являются, а также обоснование этого действия. Это важно для отслеживания развития системы, и значительно упрощает управление конфигурацией.
Можно изложить некоторые полезные правила формирования требований, как набор рекомендаций, чего следует избегать в предложении для ОКР:
• хаоса, необходимо сконцентрироваться на самом важном, требование не должно быть похоже на роман;
• лазеек, выражений типа «если это необходимо», поскольку они делают требование бесполезным;
• помещать больше одного требования в один параграф, это можно определить по наличию предлогов «и»;
• неконкретных рассуждений;
• нечетких слов, таких как «обычно», «в основном», «часто», «нормально», «типично»;
• использования неопределенных терминов («удобный в использовании», «универсальный», «гибкий»);
• принятия желаемого за требуемое («100% надежный», «приятный для всех пользователей», «безопасный», «подходящий для всех платформ», «не должен никогда ломаться», «быть готов к модернизациям для любых ситуаций, которые могут возникнуть в будущем»).
При написании детальных требований к системе используют, в частности, функцию развертывания качества (quality function deployment, QFD). Она переводит потребительские качества, желаемые пользователем, в технические функции и средства для их реализации и развертывания доступных ресурсов при создании продукта или услуги [2]. Метод QFD основан на экспертном построении фигурных матриц «домов качества», в которые заносится информация о качестве продукта и принимаемых решениях. Каждая часть «дома» содержит необходимые потребительские или технические характеристики. Процесс включает четыре последовательных этапа, на каждом из которых строится свой «дом качества». Сначала потребительские характеристики преобразуют в технические. Технические характеристики преобразуют в характеристики компонентов, далее в характеристики процессов и, в завершение, в характеристики контроля продукта. Термин «развертывание» относится к распределению требований от верхнего уровня системы на подсистемы, модули, компоненты, программное обеспечение и материалы, а также на процессы их изготовления и сборки в производстве.
Допустим, при создании легкового автомобиля потребителю нужна тишина в салоне авто. Для технической реализации требуется снизить уровень шума внутри салона от различных источников, включая мотор и коробку передач, систему выхлопа, применить шумопоглощающие уплотнения и материалы в перегородке салона, дверях, окнах, элементах кузова, и др. При этом для разработчика каждого компонента формируют специфичные требования к реализации.
Следующей итерацией создания требований является спецификация или «Технические характеристики». Требования описывают действия и цели, а спецификация детализирует количество и качество этих действий и целей. В ней указаны количественные фактические размеры, допуски и грузоподъемность, условия эксплуатации, необходимые для выполнения поставленной задачи. Документы со спецификациями имеют значение для строительства и производства, особенно при тестировании и оценке. Спецификация также важна, когда продукт или услуга поступают на рынок. При выборе технологических решений используют «Технические характеристики» для определения критериев выбора, требований к интеграции, эксплуатационной осуществимости и задач обслуживания, включая стоимость и риски.
При рассмотрении вышеуказанных вопросов важным является уточнение набора интерфейсов системы. Интерфейс описывает связь между двумя функциями или процессами, фактически отражая часть требований к системе. Интерфейсы в системе появляются в ходе ее декомпозиции при распределении работ, либо при разделении элементов конструкции на модули и компоненты в зоне ответственности конкретного субподрядчика. Возможны интерфейсы при сопряжении системы с другими (внешними) системами, например, для соединения двигателя автомобиля с бортовыми агрегатами. Существуют разные типы интерфейсов: механические, электропитание (напряжение и токи между подсистемами), электронные (характеристики электрических сигналов между системами), данные (формат и содержание информации, передаваемой между подсистемами), программное обеспечение (связь модулей или оборудования). Появление интерфейсов также может быть связано с наличием группы проектных команд, участием разных производителей агрегатов и поставщиков, использованием нескольких сборочных площадок, разделением работ внутри отдельных команд.
Требования к интерфейсам, как часть системных требований, должны быть идентифицированы во время определения системных решений. Основным источником информации об интерфейсах является задаваемая схема потоков рабочих сред, где каждая стрелка представляет собой интерфейс и связь между функциями. Для систем высокой сложности интерфейсы можно структурировать путем размещения их в матрице входов и выходов системы (строк и столбцов) N
, где каждый квадрат представляет собой технический или системный интерфейс для управления, а по диагонали расположены функции.
Требования к интерфейсам должны удовлетворять определенным правилам для исполнения задаваемых функций.
1. Интерфейсы возникают как между подсистемами, так и между подсистемами и системой.
2. Функции, характеристики, ограничения и допущения этих интерфейсов должны быть определены и зафиксированы в требованиях к интерфейсам.
3. Должен быть определен один владелец каждого интерфейса, даже если это очевидно.
4. Требования к интерфейсу определяют функциональные, физические, характеристические, электрические, экологические, человеческие требования и ограничения, которые существуют на общей границе между двумя или более функциями, элементов системы, элементов конфигурации или систем.
5. Требования к интерфейсу включают логические и физические интерфейсы.
Также на этапе разработки требований необходимо определить методы их верификации. Целесообразно для безусловного выполнения требований проекта организовать поэтапную верификацию исполнения требований к системе, начиная с момента появления предварительного облика разрабатываемой системы (на контрольном рубеже с обзором предварительного проекта системы).
Валидация требований входит в один из этапов принятия решений. В процессе валидации требуется проверить, что системные требования полны, непротиворечивы, и каждое требование достижимо и проверяемо. Валидацию требований проводят эксперты по конкретным вопросам, организация-разработчик и уполномоченные представители заказчика.
В результате процесса разработки формируется набор требований, который должен быть выполнен при создании продукта или системы. Этот завершающий комплект требований содержится в документах контракта, спецификациях или технических заданиях на выполнение работ (statement of work, SOW). Характеристики этого набора будут идентичны вышеописанным пунктам отдельных требований и удовлетворяют двум условиям. Набор должен быть полным, то есть не нуждается в дополнительных пунктах требований. Входящие в него требования должны быть согласованными, то есть не содержат противоречий, дублирований, и др. Далее на всех этапах разработки системы выполняется процесс управления требованиями (см. раздел 2.2).
Идеальным случаем, не встречающимся в практике, является вариант, что все требования, созданные до того, как проект будет начат, останутся такими же после его завершения. Отслеживание их изменений имеет первостепенное значение в работе менеджера для отображения прогресса, модификаций, запросов на финансирование или на другие ресурсы, которые могут меняться по мере продвижения процесса разработки.
1.4 Организация команды проекта и синтез системы
При создании новых изделий и систем важнейшей задачей является формирование команды управленцев и компетентных исполнителей по разным направлениям. Далее необходимо выполнить распределение ролей, налаживание коммуникаций внутри интегрированной команды проекта, с соисполнителями и со стейкхолдерами программы. Нужно организовать эффективное принятие коллегиальных решений и исполнение ряда других процессов системной инженерии для успешной реализации поставленных задач проекта или программы. Декомпозиция задач проекта по ролям для персонала команды обеспечивает эффективность системно-инженерного подхода, упрощает цели участников работ.
Сегодня большинство сложных проектных работ делают в рамках матричной организации команд проекта. Матричная модель представляет собой структуру отношений полномочий и отчетности, созданную наложением проектной команды на традиционную функциональную организацию (подробности в разделе 3.2.1). Под конкретный проект необходимо создавать междисциплинарную интегрированную команду проекта (ИКП). Ее формируют на ранней стадии проекта и наделяют ресурсами и полномочиями для принятия решений, влияющих не только на проект, но и на полный жизненный цикл конечного продукта или системы. Лидер и участники команды выбираются менеджером, ответственным за проект.
Важную роль играют внешние по отношению к ИКП представители заинтересованных лиц программы. Можно выделить для них типичные группы и характерные интересы.
• Пользователь: функциональность, удобство использования.
• Клиент, спонсор, руководство: корпоративные цели, видение, выгода.
• Законодатели: стандарты, руководящие принципы, этические, моральные и правовые условия.
• Заказчик, покупатель: стоимость лицензии, условия контракта, цена.
• Поставщик, продавец: маржа, объем функций, условия контракта.
• Маркетинг, продажи: набор функций, цена, срок поставки, доступность.
• Противники и сторонники проекта: корректировка целей проекта.
• Ремонтный и обучающий персонал: техническое обслуживание, обучение.
При этом важно помнить, что у таких разнородных групп одной программы могут быть конфликтующие интересы.
В проекте следует определить и задокументировать роли и обязанности в области СИ для членов проектной команды и функциональных руководителей. На большой программе или при наличии у организации филиалов, расположенных в разных географических точках, команд может быть несколько.
Концептуальное проектирование является первым, и наиболее важным шагом в процессе проектирования системной инженерии. Чтобы объективно оценить возможность успеха реализации проекта, изучают потенциальный рынок и группы клиентов, учитывают факторы окружающей среды, доступ к необходимым ресурсам, готовность персонала, и наличие текущих или разрабатываемых технологий. На предыдущем этапе фиксируют системные потребности и эксплуатационные требования, которые собирают в один всеобъемлющий документ. На основе требований к системе изучаются концепции проектирования в сочетании с анализом осуществимости системы. На этой стадии рассматривают наиболее широкий спектр потенциально возможных решений, которые могут дать значительные преимущества для будущего продукта. Анализ осуществимости проекта дает ответы на вопросы «Выгодно ли проектировать систему?» и «Сможем ли мы это сделать?» Критериями при оценке осуществимости ОКР выбирают стоимость проекта и ценности для организации, полученные при проектировании.
Рассматривают три взаимосвязанных компонента осуществимости, технический, эксплуатационный и экономический. Техническая осуществимость оценивает доступность технических ресурсов, готовность и зрелость существующих и новых технологий. Также при разработке системы следует учесть законы, нормативные акты, стандарты и кодексы, которым должна удовлетворять новая разработка, включая стандарты безопасности и характеристик. В них указаны требования по охране труда, управлению качеством, экологии, и так далее.
Эксплуатационная осуществимость показывает, насколько хорошо предлагаемая система удовлетворяет заданным требованиям. Для анализа этого фактора разработчикам необходимо ответить на ряд вопросов. Хорошо ли эта система работает с существующей средой? Как система удовлетворяет потребности клиентов? Есть ли у разработчиков необходимые резервы для создания такой системы, включая возможности организации, готовность ресурсов, навыков и обучения персонала? По ответам оценивают потенциальные плюсы и минусы эксплуатационной эффективности системы.
Экономическая осуществимость, также называемая анализом затрат и выгод, измеряется рентабельностью предлагаемой системы в течение проектного срока службы. Нужно оценить, в какие сроки окупятся затраты на разработку, так как конечной целью организации, инициирующей выпуск нового продукта, является получение прибыли.
По результатам определения архитектуры и концептуального анализа осуществимости выполняют функциональный анализ системы, с описанием того, что она должна делать для выполнения требований. В него входит определение функций системы, их иерархической структуры и последовательности операций. Результаты анализа гарантируют, что все необходимые компоненты перечислены и ненужные элементы исключены.
Функциональный анализ применяется к каждому этапу процесса проектирования. Процесс сфокусирован на том, что реализует решение, а не на том, как оно это делает. В процессе функционального анализа исследуют функции, подфункции и интерфейсы, которые выполняют работу или задачи системы. Функция выполняется одним или несколькими элементами системы, состоящими из оборудования (аппаратного, программного обеспечения), людей и процедур для обеспечения работы системы. Элементы системы можно разделить на три основных типа.
1. Аппаратные или физические элементы для построения системы, статические или динамические, такие как объект, рама системы, детали, провода, и так далее.
2. Программные элементы, включая компьютерные коды и программы, которые служат для управления физическими компонентами системы. Результатом разработки является конфигурация программного обеспечения для каждого компонента.
3. Человеческие элементы, куда входят системные операторы, пользователи и специалисты по обслуживанию. Результатами распределения функций системы по человеческим элементам являются процедуры эксплуатации и технического обслуживания, включая взаимодействие человека с системой, а также требования к навыкам и обучению персонала.
При анализе разлагают системные функции на функции более низких уровней, которым будут удовлетворять элементы конструкции системы. Полезно использовать некоторые принципы функциональной декомпозиции системы.
• Разбиение системы на компоненты, сформированная архитектура и инженерные идеи имеют решающее значение для успеха проекта.
• При разбиении характеристик и ресурсов системы принцип равномерного нагружения подсистем исполнением основных требований продукта позволяет заметно улучшить общие характеристики системы.
• Реализацию каждой конкретной функции рекомендуется связывать с каким-то одним модулем системы.
• В процессе разбиения для каждой функциональной подсистемы выбор и принятие альтернативных решений основываются на маркетинговых исследованиях и прогнозе конкурентоспособности разрабатываемой системы.
Аналогичные функции группируются или разбиваются на логические подразделения или пакеты. Например, все блоки потребляемой мощности можно сгруппировать вместе, имея общий источник питания. Моделирование функций системы имитирует, какие функции необходимо выполнять и как они соответствуют целям эксплуатации системы.
Основными результатами анализа являются функциональное дерево и дерево компонентов системы. Первое определяет основные функции, которые должна выполнять система. Второе выделяет все физические компоненты системы, которые могут выполнять основные функции. При определении количественных целевых значений основных параметров системы, ее характеристики являются функцией двух типов переменных.
1. Независимые от конструкции параметры, которые включают внешние атрибуты или переменные, не зависящие от проекта системы. Например, условия окружающей среды и ограничения для работы систем, такие как стоимость ресурсов, предпочтения клиентов, процентная ставка по кредитам, стандарты напряжения электроэнергии, и так далее.
2. Параметры, зависящие от проекта, включают переменные, которые проектировщики могут выбирать и изменять для достижения оптимальной производительности системы. Например, стоимость жизненного цикла, выходную мощность, скорость, вес, среднее время наработки на отказ системы, размеры, цвет, и так далее.
Следующим этапом процесса разработки является синтез системы, в ходе которого конструктор переводит функциональную архитектуру системы в физическую архитектуру. Разрабатываемая система должна быть представлена в виде конструкции, которая покажет конкретную реализацию сформулированных требований. Например, будет ли автомобиль использовать бензиновый, дизельный или электродвигатель. Конструкция выстраивается по иерархическому принципу. Сначала для системы в целом, далее для основных подсистем и компонентов, узлов и деталей. Решение разрабатывают снизу вверх на основе интегрируемых компонентов. Для обоснования выбора решений определяют соответствующие затраты, графики, показатели эффективности и риски.
Чтобы завершить разработку архитектуры системы, необходимо определить основные данные системы, массу, электрическую мощность, и так далее. Для выполнения этой задачи нужно задокументировать режимы работы системы, которые являются частью требований к эксплуатации. Они могут быть определены только после идентификации подсистем и их оборудования. Для синтеза проекта системы может потребоваться несколько итераций. Далее технический лидер принимает решение о «заморозке» базовой версии проекта системы, останавливая внесение изменений в проект.
В процессе синтеза нужно будет решить, могут ли требования к системе быть удовлетворены с использованием существующих готовых покупных комплектующих изделий и компонентов, или должны быть использованы заново созданные конструкции или технологии. Преимущество использования покупных деталей в том, что большинство поставщиков специализируются на производстве деталей, соответствующих установленным промышленным нормам и спецификациям, таким как ISO 9001. Также эти детали часто производятся в больших объемах, по относительно низкой цене за единицу. При отсутствии покупных модулей создание и валидация новой конструкции, отвечающей требованиям, может быть очень дорогостоящим, рискованным или трудоемким делом.
При принятии проектных решений следует начинать с выбора критериев оценки влияния решений на ход реализации проекта:
• когда решение связано с умеренным или высоким риском по результату;
• когда результат решения может привести к значительным задержкам графика работ или перерасходам;
• учитывать, что при закупке ПКИ есть 20% комплектующих, которые составляют 80% от общей стоимости объема ПКИ.
Полезно использовать проверенные принципы для выработки проектных решений ОКР:
• Лучше продвигаться по проекту, имея несколько запасных стандартных решений, чем опоздать с графиком в поисках одного «совершенного» варианта. Здесь лучшее будет врагом хорошего.
• В проекте надо использовать принцип «сделай это проще», чтобы снизить риски, стоимость разработки и эксплуатации.
При принятии любого решения следует помнить, что подавляющее большинство технических задач имеют множество решений. Поэтому не следует сожалеть о результате после принятия решения. Поправки возможно рассматривать только по данным последующего технического обзора, если выяснится, что при принятии решения не были учтены какие-то существенные факторы. Большинство концепций и проектов есть полезные, с низким риском, модификации предыдущих решений с относительно малой новизной. С них рекомендуется начинать разработку.
Для повышения эффективности формирования системы многие компании используют процедуру коллективного экспертного выбора конструкторских решений будущих изделий. Этап выбора базовых проектных решений, например, в компании Airbus, может длиться от 3 месяцев до 1,5 лет. В этом процессе участвуют эксплуатационники, конструкторы, технологи, производственники, закупщики, риск-разделенные партнеры. Предпочтительно работы проводятся при личном общении участников на единой площадке. В ходе этапа определяют перечень позиций, по которым должны быть приняты общие заключения, обсуждение и утверждение базовых конструкторских решений. Детально расписан процесс принятия решений и их количество на данном этапе. Примерами критериев принятия оптимальных решений могут быть масса системы, прочность, новизна технологии, стоимость, варианты конструкции, унификация, и др. Согласованный перечень проектных решений далее является руководством к действиям разработчиков на этапах предварительного и детального проектирования системы. Составляют соглашения об используемых в программе инструментах, формате данных, требований, критериев, коммуникации и др. Набор этих результатов должен быть задокументирован и является опорным при дальнейшей разработке сложных систем. Так повышается качество разработки, потому что за облик конструкции отвечают совместно эксперты разных направлений. Нет места ошибкам, типа недавно озвученной каким-то самолетостроителем РФ, что проблемы при работе одной из систем нового изделия связаны с тем, что ее проектирование поручили молодому специалисту.
Основной целью детального проектирования системы является интеграция всех компонентов в единую систему. Технический проект уточняет, как будет выглядеть реальная система и ее компоненты (размеры, формы и взаимное расположение). Он включает формирование и документирование подсистем, узлов, частей основной системы, и вспомогательных элементов. Здесь принимаются решения о том, будут ли подсистемы и компоненты функционировать вручную или автоматически, будут ли компоненты электронными, механическими, или гидравлическими, и так далее. На чертежах и моделях должны быть показаны все детали, необходимые для последующего изготовления, сборки и обслуживания системы.
Ранее при создании систем собирали все части вместе, и затем проводили испытания системы. Часто оказывалось, что система, включающая множество отдельных частей и большой объем программного обеспечения, слишком сложна для успешного объединения всего и сразу. Постепенно была внедрена фаза между сборкой и испытаниями, которую сегодня называют системной интеграцией. Это процесс, при котором пошагово объединяют все компоненты и подсистемы в одну систему, и обеспечивают их работу и функционирование как единого целого. Интеграция определяет координацию усилий по сборке функционирующей системы.
Управление интеграцией объединяет все области знаний в программе и связывает план разработки в одно целое, координируя различные процессы и действия в рамках программы. В число ключевых элементов управления интеграцией входят назначение системы, время, стоимость, контроль качества, персонал, коммуникации, риски, материально-техническое снабжение.
Конечной целью интеграции является обеспечение функционирования системных элементов в соответствии с указанными требованиями, конфигурационной документацией, требованиями к интерфейсу, применимыми стандартами, последовательностью и процедурами интеграции. Должны быть разработаны проектные спецификации для всех компонентов и элементов нижнего уровня, включая аппаратное обеспечение, программное обеспечение, пользователей, сборки и пакеты. Далее определяют, закупают и интегрируют компоненты в окончательную конфигурацию системы. Выполняют критический анализ системы, выявляют возможные проблемы с конфигурацией в отношении требований к системе, и, при необходимости, вносят в нее изменения.
При интеграции сначала последовательно собирают части в небольшие компоненты. Затем интегрируют крупные подсборки для объединения всей системы. Проводят проверку работоспособности отдельных компонентов и подсистем, чтобы заставить элементы системы работать правильно. Сравнивают результаты испытаний с ожидаемыми. При отклонениях отслеживают источник несоответствия и вносят необходимые коррективы в реализацию элемента. Процесс повторяется до достижения заданных результатов для каждой из подсистем. При этом заметно уменьшается количество ошибок, которые остаются в системе (скрытые дефекты). Также подтверждается, что система завершена, и готова к валидации. Сборку системы на основании разработанной документации может выполнить группа независимых команд, каждая из которых будет отвечать за одну или несколько входящих частей.
В ходе интеграции подключают новый компонент к системе так, чтобы ее не повредить. Компонент будет проверяться индивидуально в изолированных средах. Сначала подтверждается, что он функционирует так, как предполагалось, а затем проверяют, что он не причиняет вреда окружающим модулям и не приводит к их нежелательному поведению. После такой проверки компонент можно интегрировать в состав системы. По сути, вводится безопасное пространство для отказа, позволяющее инженеру принимать решения с реальными последствиями в гораздо меньшем масштабе, чтобы учиться на собственном опыте.
В результате процесса должны быть получены: интегрированный продукт со всеми системными взаимодействиями, документация и руководства, включая модели, данные и отчеты системного анализа, подтверждающие обоснование готовности системы. Формируют отчеты по интеграции продуктов (для поддержки процесса управления техническими данными), чертежи сборки, результаты верификации, требования к эмулятору (где приложимо).
Важным вопросом интеграции является применение правила копирования, то есть использования готовых компонентов, модулей, подсистем, покупаемых на рынке. При любом применении заимствованные части изделия должны проверяться на качество и верифицироваться так же, как новое оборудование.
Процесс интеграции продукта применяется не только к аппаратным и программным системам, но также к сервис-ориентированным решениям, спецификациям, планам и концепциям.
На этапе синтеза продукта эффективно применяют интеграционную методологию параллельного инжиниринга (подробности в разделе 3.2.2). Так названа совместная работа различных специалистов, сотрудничающих одновременно в общей среде, реальной или виртуальной, для создания общего дизайна, достигая сокращения времени цикла разработки продукта за счет лучшей интеграции мероприятий и процессов.
Важнейшим инструментом в процессе развития параллельного инжиниринга стало освоение трехмерного электронного макета изделия (ЭМИ), используемого командами проекта 24 часа в сутки. Работа с ЭМИ существенно снижает время проектирования и затраты. Электронный цифровой макет изделия становится средоточием информации о продукте, определения можно найти в ГОСТ 2.051…2.058.
Электронный макет в процессе разработки включает обычно три уровня.
Начальный макет ЭМИ-1 используется для предварительных компоновочных решений по продукту и включает: все внешние формы системы или секции, основные геометрические сведения о силовом наборе, важные интерфейсы, все системы координат, необходимые для позиционирования подсборок между собой, общие виды и внешние границы.
Данные решения проверяются на следующей стадии макета ЭМИ-2 (space allocation mock-up), макет распределения внутренних объемов продукта под компоненты и агрегаты, который развивает мастер-геометрию и служит для проработки использования допустимого пространства внутри изделия при его заполнении конструктивными элементами, определения расположения подсистем и частей оборудования, проверки их взаимной увязки. На базе 3D-моделей макета второго этапа ЭМИ-2 после «замораживания» всех проектных решений конструкции выпускается рабочая документация (РКД), которая передается намеченным производителям для согласования и доработки технологий производства.
Разработанная и скорректированная рабочая документация служит основой для финальной модели (макета) изделия ЭМИ-3 (справочная геометрия, сертификация). Этот макет строится в завершающей стадии конструирования на основании производственных чертежей и служит источником для стадий производства, эксплуатации, при разработке модификаций. Также ЭМИ-3 включает базу сертификационных расчетов на прочность, сборник требований по установке систем и оборудования.
В результате в ЭМИ включены технические данные системы, трехмерные (3-D) модели, документы и обеспечивающие процессы, необходимые для использования при дальнейших этапах работ. Сюда входят трехмерная модель системы, набор и система управления техническими документами проекта, система управления составом изделия, система управления жизненным циклом изделия, технологические данные, содержащие необходимые указания для производства, результаты расчетов, производственные данные для проектирования и изготовления оснастки, технологические процессы, библиотеки операций и переходов.
